Acx 2100

Junos® OS
ACX Series Universal Access Router Configuration

Guide
Modified: 2017-08-31
Copyright © 2017, Juniper Networks, Inc.

Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. and/or its affiliates in
the United States and other countries. All other trademarks may be 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.
®
Junos OS ACX Series Universal Access Router Configuration Guide
Copyright © 2017 Juniper Networks, Inc. All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the
year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
http://www.juniper.net/support/eula/. By downloading, installing or using such software, you agree to the terms and conditions of that
EULA.
ii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . liii
Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . liii
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . liii
Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . liii
Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . liv
Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . liv
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lv
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lvii
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lvii
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . lvii
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lviii
Part 1 Overview
Chapter 1 ACX Series Universal Access Router Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
ACX Series Universal Access Router Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
ACX Series Router Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Junos Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Protocols and Applications Supported by ACX Series Routers . . . . . . . . . . . . . . . . 5
Hardware Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Hardware Overview (ACX Series, M Series, MX Series, T Series, and TX Matrix
Routers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
System Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Storage Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ACX500 Routers Hardware and CLI Terminology Mapping . . . . . . . . . . . . . . . . . . 25
ACX500 Indoor Routers Hardware and CLI Terminology Mapping . . . . . . . . . 25
ACX500 Outdoor Routers Hardware and CLI Terminology Mapping . . . . . . . 27
ACX500 Outdoor Routers with PoE Hardware and CLI Terminology
Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
ACX1000 and ACX1100 Routers Hardware and CLI Terminology Mapping . . . . . . 30
ACX1000 and ACX1100 Routers Hardware and CLI Terminology
Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
ACX1100 Routers Hardware and CLI Terminology Mapping . . . . . . . . . . . . . . . 31
ACX2000 and ACX2100 Routers Hardware and CLI Terminology Mapping . . . . . 33
ACX2000 Hardware and CLI Terminology Mapping . . . . . . . . . . . . . . . . . . . . 33
ACX2100 Hardware and CLI Terminology Mapping . . . . . . . . . . . . . . . . . . . . . 35
ACX2200 Routers Hardware and CLI Terminology Mapping . . . . . . . . . . . . . . . . . 36
Copyright © 2017, Juniper Networks, Inc. iii

ACX Series Universal Access Router Configuration Guide

ACX5048 Router Hardware and CLI Terminology Mapping . . . . . . . . . . . . . . 39
ACX5096 Router Hardware and CLI Terminology Mapping . . . . . . . . . . . . . . 40
Part 2 Installing and Upgrading ACX Series Routers

Chapter 2 Installing and Upgrading Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Routing Engines and Storage Media Names (ACX Series, M Series, MX Series,
PTX Series, T Series, TX Matrix, TX Matrix Plus, and JCS 1200 Routers) . . . . 45
Boot Sequence on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Dual-Root Partitioning ACX Series Routers Overview . . . . . . . . . . . . . . . . . . . . . . 48
Boot Media and Boot Partition on the ACX Series Routers . . . . . . . . . . . . . . . 48
Important Features of the Dual-Root Partitioning Scheme . . . . . . . . . . . . . . 49
Understanding How the Primary Junos OS Image with Dual-Root Partitioning
Recovers on the ACX Series Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Junos OS Release 12.2 or Later Upgrades with Dual-Root Partitioning on ACX
Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Installing Junos OS Using a USB Storage Device on ACX Series Routers . . . . . . . 52
Installing Junos OS Upgrades from a Remote Server on ACX Series Routers . . . . 52
Example: Installing Junos OS and Configuring a Dual-Root Partition on ACX
Series Routers Using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Upgrading Software Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Loading and Committing the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Checking the Current Configuration and Candidate Software Compatibility . . . . 61
Unattended Boot Mode in ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Understanding System Snapshot on an ACX Series Router . . . . . . . . . . . . . . . . . 64
Example: Taking a Snapshot of the Software and Configuration . . . . . . . . . . . . . 65
Understanding In-Service Software Upgrade (ISSU) in ACX5000 Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
In-Service Software Upgrade Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Performing an In-Service Software Upgrade (ISSU) in ACX5000 Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Preparing the Router for Software Installation . . . . . . . . . . . . . . . . . . . . . . . . 69
Upgrading the Software Using ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Verifying a Unified ISSU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Chapter 3 Configuring Autoinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
ACX Series Autoinstallation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Supported Autoinstallation Interfaces and Protocols . . . . . . . . . . . . . . . . . . . 76
Typical Autoinstallation Process on a New Router . . . . . . . . . . . . . . . . . . . . . 76
Before You Begin Autoinstallation on an ACX Series Universal Access Router . . . 77
Autoinstallation Configuration of ACX Series Universal Access Routers . . . . . . . . 78
Verifying Autoinstallation on ACX Series Universal Access Routers . . . . . . . . . . . . 79
USB Autoinstallation on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Autoinstallation on ACX Series Routers in Hybrid Mode Overview . . . . . . . . . . . . . 81
Prerequisites for Autoinstallation on ACX Series Routers in Hybrid Mode . . . . . . . 83
Autoinstallation Process on a New ACX Series Router in Hybrid Mode . . . . . . . . . 84
Configuring Autoinstallation of ACX Series Routers in Hybrid Mode . . . . . . . . . . . 87
iv Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Part 3 Configuring Interfaces and Chassis on ACX Series Routers

Chapter 4 Configuring Interfaces and Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Understanding Interfaces on ACX Series Universal Access Routers . . . . . . . . . . . 94
T1 and E1 Time-Division Multiplexing (TDM) Interfaces . . . . . . . . . . . . . . . . . 95
Inverse Multiplexing for ATM (IMA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Gigabit Ethernet interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Configuring the Media MTU on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . 97
Media MTU Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
How to Configure the Media MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Encapsulation Overhead by Encapsulation Type . . . . . . . . . . . . . . . . . . . . . . 98
Media MTU Sizes by Interface Type for ACX Series Routers . . . . . . . . . . . . . . 99
Understanding the Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Configuring the Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Configuring the Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Example: Configuring Two Addresses on the Loopback Interface with Host
Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Example: Configuring Two Addresses on the Loopback Interface with
Subnetwork Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Example: Configuring an IPv4 and an IPv6 Address on the Loopback Interface
with Subnetwork Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Understanding Encapsulation on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Gigabit Ethernet Autonegotiation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
BERT Support on CT1 and CE1 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
16-Port Channelized E1/T1 Circuit Emulation MIC Overview . . . . . . . . . . . . . . . . . 106
Synchronous Ethernet Overview on the ACX Series Universal Access Routers . . 107
TDM CESoPSN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Configuring TDM CESoPSN on ACX Series Routers Overview . . . . . . . . . . . . . . . 108
Channelization up to the DS0 Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Protocol Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Packet Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
CESoPSN Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
CESoPSN Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
CESoPSN Pseudowires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
SAToP Emulation on T1 and E1 Interfaces Overview . . . . . . . . . . . . . . . . . . . . . . . 110
Ethernet Ring Protection Switching Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Understanding Ethernet Ring Protection Switching Functionality . . . . . . . . . . . . 112
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Ring Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Ring Node States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Default Logging of Basic State Transitions on EX Series Switches . . . . . . . . 114
Failure Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Logical Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
FDB Flush . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Traffic Blocking and Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
RPL Neighbor Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Copyright © 2017, Juniper Networks, Inc. v

RAPS Message Blocking and Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Dedicated Signaling Control Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
RAPS Message Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Revertive and Non-revertive Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Multiple Rings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Node ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Ring ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Bridge Domains with the Ring Port (MX Series Routers Only) . . . . . . . . . . . . 117
Wait-to-Block Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Adding and Removing a Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Configuring Ethernet Ring Protection Switching . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Example: Ethernet Ring Protection Switching Configuration on ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Example: Viewing Ethernet Ring Protection Status—Normal Ring Operation . . . 127
Example: Viewing Ethernet Ring Protection Status—Ring Failure Condition . . . . 129
Guidelines for Ethernet Ring Protection Switching on ACX Series Routers . . . . . . 131
Dual-Rate SFP+ Optic Modules for ACX Series Routers . . . . . . . . . . . . . . . . . . . . 134
Dual Rate SFP+ Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Tri-Rate SFP for ACX5000 Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Configuring Logical Tunnel Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Connecting Logical Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Guidelines for Configuring Logical Tunnels on ACX Series Routers . . . . . . . . . . . . 137
Configuring an Interface in the VRF Domain to Receive Multicast Traffic . . . . . . 140
Configuring a Proxy Logical Interface in the Global Domain . . . . . . . . . . . . . 140
Associating the Proxy Logical Interface to a Logical Interface in a VRF
Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Understanding PoE on ACX Series Universal Access Routers . . . . . . . . . . . . . . . . 142
ACX2000 PoE Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
PoE Classes and Power Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
PoE Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Example: Configuring PoE on ACX2000 Routers . . . . . . . . . . . . . . . . . . . . . . . . . 144
Example: Disabling a PoE Interface on ACX2000 Routers . . . . . . . . . . . . . . . . . . 149
Configuring a Service Package to be Used in Conjunction with PTP . . . . . . . . . . 150
Checklist for Monitoring Fast Ethernet and Gigabit Ethernet Interfaces . . . . . . . 150
Checklist for Monitoring T1 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Understanding Ethernet Link Aggregation on ACX Series Routers . . . . . . . . . . . . 152
Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
LACP Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Link Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Configuring Link Protection for Aggregated Ethernet Interfaces . . . . . . 156
Disabling Link Protection for Aggregated Ethernet Interfaces . . . . . . . . 156
Understanding the Algorithm Used to Hash LAG Bundle . . . . . . . . . . . . . . . 156
User-Defined Alarm Relay Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Alarm Contact Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Alarm Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Alarm Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Configuring Chassis Alarm Relays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Configuring Chassis Alarm Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
vi Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Configuring Chassis Alarm Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Chassis Definitions for Router Model MIB for ACX Series Routers . . . . . . . . . . . . 162
Chapter 5 Configuring E1 and T1 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Configuring E1 BERT Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Configuring E1 Loopback Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Configuring T1 BERT Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Configuring T1 Loopback Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Chapter 6 Configuring ATM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
ATM Pseudowire Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Understanding ATM IMA Configuration on ACX Series Router . . . . . . . . . . . . . . . 174
IMA Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
IMA Frame Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Transmit Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
IMA Group Symmetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Minimum Active Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
State Transition Variables: Alpha, Beta, and Gamma . . . . . . . . . . . . . . . . . . 176
IMA Link Addition and Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
IMA Test Pattern Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
IMA Group Alarms and Group Defects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
IMA Link Alarms and Link Defects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
IMA Group Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
IMA Link Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
IMA Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Differential Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Configuring ATM IMA on ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Creating an IMA Group (ATM Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Configuring Group ID for an IMA Link on a T1 Interface or an E1 Interface . . . 182
Configuring ATM Encapsulation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Configuring IMA Group Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Inverse Multiplexing for ATM (IMA) Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Configuring Inverse Multiplexing for ATM (IMA) . . . . . . . . . . . . . . . . . . . . . . . . . . 185
ATM OAM F4 and F5 Cells on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . 185
Defining the ATM OAM F5 Loopback Cell Period . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Configuring the ATM OAM F5 Loopback Cell Threshold . . . . . . . . . . . . . . . . . . . . 188
Configuring the Timeout for Bundling of Layer 2 Circuit Cell-Relay Cells . . . . . . 188
Configuring the Layer 2 Circuit Cell-Relay Cell Maximum Overview . . . . . . . . . . . 189
Class-Based Cell Bundling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chapter 7 Configuring SAToP Support on Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Configuring SAToP Emulation on Channelized T1 and E1 Interfaces . . . . . . . . . . . 191
Setting the T1/E1 Emulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Configuring One Full T1 or E1 Interface on Channelized T1 and E1
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Setting the SAToP Encapsulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Copyright © 2017, Juniper Networks, Inc. vii

Configure the Layer 2 Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Configuring SAToP Emulation on T1/E1 Interfaces on 12-Port Channelized T1/E1
Circuit Emulation PICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Setting the Emulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Configuring SAToP Emulation on T1/E1 Interfaces . . . . . . . . . . . . . . . . . . . . . 197
Setting the Encapsulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Configuring Loopback for a T1 Interface or an E1 Interface . . . . . . . . . . . 198
Setting the SAToP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Configuring the Pseudowire Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Configuring SAToP on 16-Port Channelized E1/T1 Circuit Emulation MIC . . . . . . . 201
Configuring T1/E1 Framing Mode at the MIC Level . . . . . . . . . . . . . . . . . . . . . 201
Configuring CT1 Ports Down to T1 Channels . . . . . . . . . . . . . . . . . . . . . . . . . 202
Configuring CT1 Ports Down to DS Channels . . . . . . . . . . . . . . . . . . . . . . . . 202
Chapter 8 Configuring CESoPSN Support on Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 205
Configuring CESoPSN Encapsulation on DS Interfaces . . . . . . . . . . . . . . . . . . . . 205
Configuring CESoPSN on Channelized OC3/STM1 (Multi-Rate) Circuit Emulation
MIC with SFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Configuring SONET/SDH Rate-Selectability . . . . . . . . . . . . . . . . . . . . . . . . . 206
Configuring SONET/SDH Framing Mode at the MIC Level . . . . . . . . . . . . . . 207
Configuring CESoPSN Encapsulation on DS Interfaces on CT1 Channels . . 208
Configuring COC3 Ports Down to CT1 Channels . . . . . . . . . . . . . . . . . . 208
Configuring CT1 Channels Down to DS Interfaces . . . . . . . . . . . . . . . . . 209
Configuring CESoPSN on DS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 210
Configuring CESoPSN Encapsulation on DS Interfaces on CE1 Channels . . . 211
Configuring CSTM1 Ports Down to CE1 Channels . . . . . . . . . . . . . . . . . . . 211
Configuring CSTM4 Ports Down to CE1 Channels . . . . . . . . . . . . . . . . . . 212
Configuring CE1 Channels Down to DS Interfaces . . . . . . . . . . . . . . . . . . 213
Configuring CESoPSN on DS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 214
Configuring CESoPSN Encapsulation on DS Interfaces . . . . . . . . . . . . . . . . . . . . 215
Setting the Encapsulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Setting the CESoPSN Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Configuring the Pseudowire Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Configuring CE1 Channels Down to DS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 218
Configuring CESoPSN on Channelized E1/T1 Circuit Emulation MIC . . . . . . . . . . 220
Configuring T1/E1 Framing Mode at the MIC Level . . . . . . . . . . . . . . . . . . . . 220
Configuring CT1 Interface Down to DS channels . . . . . . . . . . . . . . . . . . . . . . 221
Configuring CESoPSN on DS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Chapter 9 Configuring Timing and Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Automatic Clock Selection Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Clock Source Selection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Clock Selection and Quality Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Selection Mode for the Incoming ESMC Quality . . . . . . . . . . . . . . . . . . . . . . 225
Clock Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
External Clock Synchronization Overview for ACX Series Routers . . . . . . . . . . . . 226
Automatic Clock Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Clock Source Selection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Configuring External Clock Synchronization for ACX Series Routers . . . . . . . . . . 228
viii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
IEEE 1588v2 PTP Boundary Clock Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

IEEE 1588v2 PTP Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Clock Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
IEEE 1588v2 Precision Timing Protocol (PTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
PTP over Ethernet on ACX Series Routers Overview . . . . . . . . . . . . . . . . . . . . . . 238
Guidelines for Configuring PTP over Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Configuring Precision Time Protocol Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Configuring a PTP Master Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Configuring the PTP Master Boundary Clock Parameters . . . . . . . . . . . . . . 245
Configuring a PTP Master Boundary Clock Interface . . . . . . . . . . . . . . . . . . 246
Example: Configuring a PTP Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Example: Configuring a PTP Boundary Clock With Unicast Negotiation . . . . . . . 250
Configuring a PTP Slave Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Configuring the PTP Slave Clock Parameters . . . . . . . . . . . . . . . . . . . . . . . . 255
Configuring the PTP Slave Clock Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Example: Configuring an Ordinary Slave Clock With Unicast-Negotiation . . . . . 257
Example: Configuring an Ordinary Slave Clock Without Unicast-Negotiation . . . 261
Configuring Precision Time Protocol Over Integrated Routing and Bridging . . . . 264
Understanding Transparent Clocks in Precision Time Protocol . . . . . . . . . . . . . . 267
Configuring Transparent Clock Mode for Precision Time Protocol . . . . . . . . . . . 269
Configuring a PTP Transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Configuring PHY Timestamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Enabling PHY Timestamping for Ordinary Clock Slave . . . . . . . . . . . . . . . . . 271
Enabling PHY Timestamping for Boundary Clock . . . . . . . . . . . . . . . . . . . . . 272
Enabling PHY Timestamping for Grandmaster Clock . . . . . . . . . . . . . . . . . . 272
Configuring PHY Timestamping on ACX2200 Routers . . . . . . . . . . . . . . . . . . . . . 273
Enabling PHY Timestamping for Boundary Clock . . . . . . . . . . . . . . . . . . . . . 273
G.703 2.048MHz Signal Type for BITS Interfaces Overview . . . . . . . . . . . . . . . . . 274
Configuring PTP Multicast Master and Slave Ports for Ethernet
Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Configuring the PTP over Ethernet Master Boundary Clock Parameters . . . 275
Configuring the PTP over Ethernet Master Boundary Clock Interface . . . . . . 277
Configuring the PTP over Ethernet Slave Clock Parameters . . . . . . . . . . . . . 277
Configuring the PTP over Ethernet Slave Clock Interface . . . . . . . . . . . . . . . 279
Configuring PTP Dynamic Ports for Ethernet Encapsulation . . . . . . . . . . . . . . . . 280
Example: Configuring PTP over Ethernet for Multicast Master, Slave, and Dynamic
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Hybrid Mode on ACX Series Routers Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Hybrid Mode Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Supporting Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Guidelines for Configuring Hybrid Mode on ACX Series Routers . . . . . . . . . . . . . 290
Configuring Hybrid Mode and ESMC Quality Level Mapping on ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Configuring the Router in Hybrid Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Configuring Hybrid Mode with Mapping of the PTP Clock Class to the ESMC
Quality Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Configuring Hybrid Mode with a User-Defined Mapping of the PTP Clock
Class to the ESMC Quality Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Example: Configuring Hybrid Mode and ESMC Quality Level Mapping . . . . . . . . 295
Copyright © 2017, Juniper Networks, Inc. ix

Understanding Timing Defects and Event Management on ACX Series . . . . . . . 301

Understanding SNMP MIB for Timing on ACX Series . . . . . . . . . . . . . . . . . . . . . . 303
Global Positioning System (GPS) and the ACX Series Routers . . . . . . . . . . . . . . 306
Integrated Global Navigation Satellite System (GNSS) on ACX500 Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Assisted Partial Timing Support on ACX500 Routers Overview . . . . . . . . . . . . . 308
Part 4 Configuring DHCP on ACX Series Routers

Chapter 10 Configuring DHCP Client and DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Extended DHCP Local Server Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Interaction Among the DHCP Client, Extended DHCP Local Server, and
Address-Assignment Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Minimal Configuration for Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
DHCP Local Server and Address-Assignment Pools . . . . . . . . . . . . . . . . . . . 316
Address-Assignment Pools Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Configuring Address-Assignment Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Configuring an Address-Assignment Pool Name and Addresses . . . . . . . . . . . . . 319
Configuring a Named Address Range for Dynamic Address Assignment . . . . . . 320
Configuring Static Address Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
DHCP Attributes for Address-Assignment Pools . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Configuring How the Extended DHCP Local Server Determines Which
Address-Assignment Pool to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Use of DHCP Option 50 to Request a Specific IP Address . . . . . . . . . . . . . . . . . . 324
Configuring DHCP Client-Specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Grouping Interfaces with Common DHCP Configurations . . . . . . . . . . . . . . . . . . 326
Guidelines for Configuring Interface Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Group-Specific DHCP Local Server Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Overriding Default DHCP Local Server Configuration Settings . . . . . . . . . . . . . . 329
Deleting DHCP Local Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Specifying the Maximum Number of DHCP Clients Per Interface . . . . . . . . . . . . 331
Disabling ARP Table Population . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
DHCP Auto Logout Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Auto Logout Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
How DHCP Identifies and Releases Clients . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Option 60 and Option 82 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Automatically Logging Out DHCP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
DHCP Local Server Handling of Client Information Request Messages . . . . . . . 335
Enabling Processing of Client Information Requests . . . . . . . . . . . . . . . . . . . . . . 336
Subscriber Binding Retention During Interface Delete Events . . . . . . . . . . . . . . . 337
Configuring the Router to Maintain DHCP Subscribers During Interface Delete
Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Verifying and Managing the DHCP Maintain Subscribers Feature . . . . . . . . . . . . 339
Preserving Subscriber Binding Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Configuring DHCP Local Server to Preserve Subscriber Binding Information . . . 340
Understanding Dynamic Reconfiguration of Extended DHCP Local Server
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Default Client/Server Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Dynamic Client/Server Interaction for DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 342
x Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Dynamic Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Configuring Dynamic Reconfiguration of DHCP Clients to Avoid Extended Outages
Due to Server Configuration Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Configuring Dynamic Reconfiguration Attempts for DHCP Clients . . . . . . . . . . . 345
Configuring Deletion of the Client When Dynamic Reconfiguration Fails . . . . . . 346
Requesting DHCP Local Server to Initiate Reconfiguration of Client Bindings . . 347
Clearing DHCP Bindings for Subscriber Access . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Verifying and Managing DHCP Local Server Configuration . . . . . . . . . . . . . . . . . 349
Enabling MAC Address Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Tracing General Authentication Service Processes . . . . . . . . . . . . . . . . . . . . . . . . 351
Configuring the General Authentication Service Processes Trace Log
Filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Configuring the Number and Size of General Authentication Service
Processes Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Configuring Access to the Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Configuring a Regular Expression for Lines to Be Logged . . . . . . . . . . . . . . . 353
Configuring the Trace Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Tracing Extended DHCP Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Configuring the Extended DHCP Log Filename . . . . . . . . . . . . . . . . . . . . . . . 354
Configuring the Number and Size of Extended DHCP Log Files . . . . . . . . . . 355
Configuring Access to the Extended DHCP Log File . . . . . . . . . . . . . . . . . . . 355
Configuring a Regular Expression for Extended DHCP Messages to Be
Logged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Configuring the Extended DHCP Tracing Flags . . . . . . . . . . . . . . . . . . . . . . . 356
Configuring the Severity Level to Filter Which Extended DHCP Messages
Are Logged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Tracing Extended DHCP Operations for Specific Interfaces . . . . . . . . . . . . . 358
Understanding DHCP Client Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Configuring a DHCP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Minimum DHCP Client Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Configuring Optional DHCP Client Attributes . . . . . . . . . . . . . . . . . . . . . . . . 360
Verifying and Managing DHCP Client Configuration . . . . . . . . . . . . . . . . . . . 361
DHCP Duplicate Client Differentiation Using Client Subinterface Overview . . . . 362
Guidelines for Configuring Support for DHCP Duplicate Clients . . . . . . . . . . . . . 363
Configuring DHCP Duplicate Client Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Chapter 11 Configuring DHCP and DHCPv6 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . 367
DHCP Relay Agent on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
DHCPv6 Relay Agent on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Inserting the DHCPv6 Interface Identifier into DHCPv6 Packets . . . . . . . . . . . . . 371
Configuring Group-Specific DHCP Relay Options . . . . . . . . . . . . . . . . . . . . . . . . . 372
Overriding the Default DHCP Relay Configuration Settings . . . . . . . . . . . . . . . . . 373
Changing the Gateway IP Address (giaddr) Field to the giaddr of the DHCP Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Replacing the DHCP Relay Request and Release Packet Source Address . . . . . 376
Overriding Option 82 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Using Layer 2 Unicast Transmission for DHCP Packets . . . . . . . . . . . . . . . . . . . . . 377
Trusting Option 82 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Specifying the Maximum Number of DHCP Clients Per Interface . . . . . . . . . . . . 378
Copyright © 2017, Juniper Networks, Inc. xi

Automatically Logging Out DHCP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Sending Release Messages When Clients Are Deleted . . . . . . . . . . . . . . . . . . . . . 381
Disabling Automatic Binding of Stray DHCP Requests . . . . . . . . . . . . . . . . . . . . . 381
Using DHCP Relay Agent Option 82 Information . . . . . . . . . . . . . . . . . . . . . . . . . 383
Configuring Option 82 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Including a Prefix in DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Including a Textual Description in DHCP Options . . . . . . . . . . . . . . . . . . . . . 388
Using DHCP Option Information to Selectively Process DHCP Client Traffic . . . 390
Understanding DHCP Option 82 for Protecting Switching Devices Against
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
DHCP Option 82 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Suboption Components of Option 82 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Switching Device Configurations That Support Option 82 . . . . . . . . . . . . . . 394
Switching Device, DHCP Clients, and the DHCP Server Are on the Same
VLAN or Bridge Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Switching Device Acts as a Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . . 394
DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Configuring DHCP Option 82 to Help Protect the Switching Devices Against
Attacks (CLI Procedure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Configuring Named Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Configuring Active Server Groups to Apply a Common DHCP Relay Agent
Configuration to Named Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Disabling DHCP Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Part 5 Configuring Protocols on ACX Series Routers

Chapter 12 Configuring Layer 2 Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Layer 2 Control Protocol on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . 404
Bridge Priority for Election of Root Bridge and Designated Bridge . . . . . . . . . . . 406
Maximum Age for Awaiting Arrival of Hello BPDUs . . . . . . . . . . . . . . . . . . . . . . . 406
Hello Time for Root Bridge to Transmit Hello BPDUs . . . . . . . . . . . . . . . . . . . . . . 407
Forward Delay Before Ports Transition to Forwarding State . . . . . . . . . . . . . . . . 407
Spanning-Tree Instance Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Spanning-Tree Instance Interface Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Spanning-Tree Instance Interface Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Spanning-Tree Instance Interface Point-to-Point Link Mode . . . . . . . . . . . . . . . 409
Configuring a Spanning-Tree Instance Interface as an Edge Port for Faster
Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Spanning-Tree Protocol Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Configuring Rapid Spanning-Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Configuring Multiple Spanning-Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Configuring MST Instances on a Physical Interface . . . . . . . . . . . . . . . . . . . . . . . 415
Disabling MSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Configuring VLAN Spanning-Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
RSTP or VSTP Forced to Run as IEEE 802.1D STP . . . . . . . . . . . . . . . . . . . . . . . . 420
Reverting RSTP or VSTP from Forced IEEE 802.1D STP . . . . . . . . . . . . . . . . . . . 420
Tracing Spanning-Tree Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Understanding BPDU Protection for Spanning-Tree Instance Interfaces . . . . . . 423
Configuring BPDU Protection for Spanning-Tree Instance Interfaces . . . . . . . . . 424
xii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Configuring BPDU Protection on All Edge Ports . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Understanding Loop Protection for Spanning-Tree Instance Interfaces . . . . . . . 426
Loop Protection for a Spanning-Tree Instance Interface . . . . . . . . . . . . . . . . . . . 427
Configuring Loop Protection for a Spanning-Tree Instance Interface . . . . . . . . . 428
Example: Enabling Loop Protection for Spanning-Tree Protocols . . . . . . . . . . . . 429
Understanding Root Protection for Spanning-Tree Instance Interfaces in a Layer
2 Switched Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Root Protect for a Spanning-Tree Instance Interface . . . . . . . . . . . . . . . . . . . . . . 430
Enabling Root Protection for a Spanning-Tree Instance Interface . . . . . . . . . . . 430
LLDP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Configuring LLDP in ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
LLDP Operational Mode Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Chapter 13 Configuring Layer 2 Protocol Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Layer 2 Protocol Tunneling on ACX Series Overview . . . . . . . . . . . . . . . . . . . . . . 437
Enabling Layer 2 Protocol Tunneling on ACX Series . . . . . . . . . . . . . . . . . . . . . . . 439
Configuring a Layer 2 Protocol Tunnel Interface in ACX Series . . . . . . . . . . . . . . 439
Configuring a Layer 2 Protocol to be Tunneled in ACX Series . . . . . . . . . . . . . . . 440
Configuring Layer 2 Protocol Tunneling on ACX Series . . . . . . . . . . . . . . . . . . . . . 441
Checking for a MAC Rewrite Error Condition Blocking Layer 2 Interface in ACX
Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Clearing a MAC Rewrite Error Condition Blocking a Spanning-Tree Instance
Interface in ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Chapter 14 Configuring Internet Group Management Protocol . . . . . . . . . . . . . . . . . . . 445
Understanding IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Enabling IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Configuring IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Disabling IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Modifying the IGMP Host-Query Message Interval . . . . . . . . . . . . . . . . . . . . . . . 450
Modifying the IGMP Query Response Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Specifying Immediate-Leave Host Removal for IGMP . . . . . . . . . . . . . . . . . . . . . 452
Filtering Unwanted IGMP Reports at the IGMP Interface Level . . . . . . . . . . . . . . 453
Accepting IGMP Messages from Remote Subnetworks . . . . . . . . . . . . . . . . . . . . 454
Modifying the IGMP Last-Member Query Interval . . . . . . . . . . . . . . . . . . . . . . . . 455
Modifying the IGMP Robustness Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Limiting the Maximum IGMP Message Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Changing the IGMP Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Enabling IGMP Static Group Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Recording IGMP Join and Leave Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Limiting the Number of IGMP Multicast Group Joins on Logical Interfaces . . . . . 467
Tracing IGMP Protocol Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Disabling IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Chapter 15 Configuring Internet Group Management Protocol Snooping . . . . . . . . . . 473
Understanding IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
IGMP Snooping Interfaces and Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
IGMP Snooping and Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Multicast-Router Interfaces and IGMP Snooping Proxy Mode . . . . . . . . . . . . . . . 476
Host-Side Interfaces and IGMP Snooping Proxy Mode . . . . . . . . . . . . . . . . . . . . 477
Copyright © 2017, Juniper Networks, Inc. xiii

IGMP Snooping and Bridge Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

Configuring IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Configuring VLAN-Specific IGMP Snooping Parameters . . . . . . . . . . . . . . . . . . . 478
Example: Configuring IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Configuring IGMP Snooping Trace Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Chapter 16 Configuring Point-to-Point Protocol (PPP) . . . . . . . . . . . . . . . . . . . . . . . . . 489
Supported PPP Interface Standards on ACX Series . . . . . . . . . . . . . . . . . . . . . . 489
Configuring PPP Address and Control Field Compression . . . . . . . . . . . . . . . . . 490
Configuring the PPP Restart Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Configuring PPP CHAP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Configuring the PPP Clear Loop Detected Timer . . . . . . . . . . . . . . . . . . . . . . . . . 492
Configuring Dynamic Profiles for PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Configuring the PPP Challenge Handshake Authentication Protocol . . . . . . . . . 493
PPP Challenge Handshake Authentication Protocol . . . . . . . . . . . . . . . . . . 493
Configuring the PPP Challenge Handshake Authentication Protocol . . . . . 494
Displaying the Configured PPP Challenge Handshake Authentication
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Configuring the PPP Password Authentication Protocol On a Physical
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Understanding PPP Password Authentication Protocol . . . . . . . . . . . . . . . 496
Configuring the PPP Password Authentication Protocol On a Physical
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Configuring the PPP Password Authentication Protocol On a Logical
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Configuring the PPP Authentication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
PPP Encapsulation on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Configuring Interface Encapsulation on Physical Interfaces in ACX Series . . . . . 501
Configuring the Encapsulation on a Physical Interface . . . . . . . . . . . . . . . . . 502
Encapsulation Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Example: Configuring the Encapsulation on a Physical Interface . . . . . 505
Chapter 17 Configuring MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Understanding MLPPP Bundles on ACX Series Routers . . . . . . . . . . . . . . . . . . . . 507
Guidelines for Configuring MLPPP With LSQ Interfaces on ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Configuring Encapsulation for Multilink and Link Services Logical Interfaces . . . 514
Configuring the Minimum Number of Active Links on Multilink and Link Services
Logical Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Configuring MRRU on Multilink and Link Services Logical Interfaces . . . . . . . . . . 516
Configuring the Sequence Header Format on Multilink and Link Services Logical
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Configuring Multiclass MLPPP on LSQ Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 518
Configuring LSQ Interfaces as NxT1 or NxE1 Bundles Using MLPPP on ACX
Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Example: Configuring an LSQ Interface as an NxT1 Bundle Using MLPPP . . 523
Example: Configuring an MLPPP Bundle on ACX Series . . . . . . . . . . . . . . . . . . . 525
xiv Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Chapter 18 Configuring Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

IPv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
IPv6 Packet Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Header Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Extension Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Address Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Address Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Address Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
IPv6 Support on ACX Series Universal Access Routers . . . . . . . . . . . . . . . . . . . . 533
IS-IS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
IS-IS Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
ISO Network Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
IS-IS Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Persistent Route Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
IS-IS Support for Multipoint Network Clouds . . . . . . . . . . . . . . . . . . . . . . . . 540
Installing a Default Route to the Nearest Routing Device That Operates at
Both IS-IS Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Understanding IS-IS Flood Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
OSPF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
OSPF Default Route Preference Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
OSPF Routing Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
OSPF Three-Way Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
OSPF Version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Remote LFA over LDP Tunnels in OSPF Networks Overview . . . . . . . . . . . . . . . . 547
Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network . . . . . . 548
Example: Configuring Remote LFA over LDP Tunnels in OSPF Networks . . . . . . 550
Understanding Remote LFA over LDP Tunnels in IS-IS Networks . . . . . . . . . . . . 564
Configuring Remote LFA Backup over LDP Tunnels in an IS-IS Network . . . . . . 566
Example: Configuring Remote LFA over LDP Tunnels in IS-IS Networks . . . . . . . 568
Chapter 19 Configuring Generic Routing Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . 581
Understanding Generic Routing Encapsulation on ACX Series . . . . . . . . . . . . . . 581
Overview of GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
GRE Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Encapsulation and De-Encapsulation on the Router . . . . . . . . . . . . . . . 582
Number of Source and Destination Tunnels Allowed on a Router . . . . 582
Configuration Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Configuring Generic Routing Encapsulation Tunneling on ACX Series . . . . . . . . 584
Configuring a GRE Tunnel Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Configuring Tunnels to Use Generic Routing Encapsulation . . . . . . . . . . . . 584
Configuring Unicast Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Chapter 20 Configuring MPLS and Pseudowires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
MPLS Overview for ACX Series Universal Access Routers . . . . . . . . . . . . . . . . . . 587
TTL Processing on Incoming MPLS Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Pseudowire Overview for ACX Series Universal Access Routers . . . . . . . . . . . . . 590
Copyright © 2017, Juniper Networks, Inc. xv

ATM Pseudowire Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592

Example: ATM Pseudowire Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Ethernet Pseudowire Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Example: Ethernet Pseudowire Base Configuration . . . . . . . . . . . . . . . . . . . . . . . 597
TDM Pseudowires Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Example: TDM Pseudowire Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 600
Redundant Pseudowires for Layer 2 Circuits and VPLS . . . . . . . . . . . . . . . . . . . . 604
Types of Redundant Pseudowire Configurations . . . . . . . . . . . . . . . . . . . . . 604
Pseudowire Failure Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Configuring Redundant Pseudowires for Layer 2 Circuits and VPLS . . . . . . . . . . 606
Configuring Pseudowire Redundancy on the PE Router . . . . . . . . . . . . . . . . 606
Configuring the Switchover Delay for the Pseudowires . . . . . . . . . . . . . . . . 607
Configuring a Revert Time for the Redundant Pseudowire . . . . . . . . . . . . . . 607
Configuring the Pseudowire Status TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Example: Configuring the Pseudowire Status TLV . . . . . . . . . . . . . . . . . . . . . . . . 609
Automatic Bandwidth Allocation for LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Configuring Automatic Bandwidth Allocation for LSPs . . . . . . . . . . . . . . . . . . . . . 611
Configuring Automatic Bandwidth Allocation on LSPs . . . . . . . . . . . . . . . . . 612
Configuring the Automatic Bandwidth Allocation Interval . . . . . . . . . . . 613
Configuring the Maximum and Minimum Bounds of the LSP’s
Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Configuring the Automatic Bandwidth Adjustment Threshold . . . . . . . 614
Configuring a Limit on Bandwidth Overflow and Underflow
Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Configuring Passive Bandwidth Utilization Monitoring . . . . . . . . . . . . . . 617
Requesting Automatic Bandwidth Allocation Adjustment . . . . . . . . . . . . . . 617
Configuring Reporting of Automatic Bandwidth Allocation Statistics for
LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Understanding Pseudowire Redundancy Mobile Backhaul Scenarios . . . . . . . . 623
Sample Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Benefits of Pseudowire Redundancy Mobile Backhaul . . . . . . . . . . . . . . . . . 624
Layer 2 Virtual Circuit Status TLV Extension . . . . . . . . . . . . . . . . . . . . . . . . . 624
How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Example: Configuring Pseudowire Redundancy in a Mobile Backhaul
Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Chapter 21 Configuring Virtual Router Redundancy Protocol (VRRP) . . . . . . . . . . . . . 651
Understanding VRRP on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Configuring Basic VRRP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
Configuring the Advertisement Interval for the VRRP Master Router . . . . . . . . . 655
Modifying the Advertisement Interval in Seconds . . . . . . . . . . . . . . . . . . . . . 655
Modifying the Advertisement Interval in Milliseconds . . . . . . . . . . . . . . . . . 655
Configuring a Backup Router to Preempt the Master Router . . . . . . . . . . . . . . . . 656
Modifying the Preemption Hold-Time Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Configuring Asymmetric Hold Time for VRRP Routers . . . . . . . . . . . . . . . . . . . . . 657
Configuring an Interface to Accept Packets Destined for the Virtual IP
Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Configuring a Logical Interface to Be Tracked . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Configuring a Route to Be Tracked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
xvi Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Configuring the Silent Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

Tracing VRRP Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
Example: Configuring VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Configuring VRRP for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Chapter 22 Configuring Multicast Listener Discovery and Protocol-Independent
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Understanding MLD in ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Enabling MLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
PIM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Basic PIM Network Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Designated Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Understanding PIM Sparse Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Rendezvous Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
RP Mapping Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
PIM Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Changing the PIM Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Modifying the PIM Hello Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
PIM on Aggregated Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Enabling PIM Sparse Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Configuring BFD for PIM in ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Configuring PIM Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Disabling PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Disabling the PIM Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Disabling PIM on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Disabling PIM for a Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Disabling PIM for a Rendezvous Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Chapter 23 Configuring Path Computation Element Protocol (PCEP) . . . . . . . . . . . . . 691
PCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
PCEP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
Support of the Path Computation Element Protocol for RSVP-TE
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Understanding MPLS RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Current MPLS RSVP-TE Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
Use of an External Path Computing Entity . . . . . . . . . . . . . . . . . . . . . . . 695
Components of External Path Computing . . . . . . . . . . . . . . . . . . . . . . . 696
Interaction Between a PCE and a PCC Using PCEP . . . . . . . . . . . . . . . 698
LSP Behavior with External Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Configuration Statements Supported for External Computing . . . . . . . 702
PCE-Controlled LSP Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
PCE-Controlled LSP ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
PCE Controlled Point-to-Multipoint RSVP-TE LSPs . . . . . . . . . . . . . . . 704
Auto-Bandwidth and PCE-Controlled LSP . . . . . . . . . . . . . . . . . . . . . . 705
TCP-MD5 Authentication for PCEP Sessions . . . . . . . . . . . . . . . . . . . . . 705
Copyright © 2017, Juniper Networks, Inc. xvii

Impact of Client-Side PCE Implementation on Network

Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Configuring PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Example: Configuring the Path Computation Element Protocol for MPLS
RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Example: Configuring Path Computation Element Protocol for MPLS
RSVP-TE with Support of PCE-Initiated LSPs . . . . . . . . . . . . . . . . . . . . . 721
Configuring Path Computation Element Protocol for MPLS RSVP-TE with
Support of PCE-Initiated LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
Example: Configuring Path Computation Element Protocol for MPLS
RSVP-TE with Support for PCE-Controlled Point-to-Multipoint
LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Part 6 Configuring Layer 2 and Layer 3 Features on ACX Series Routers

Chapter 24 Configuring Layer 2 Bridging and Q-in-Q Tunneling . . . . . . . . . . . . . . . . . . . 755
Layer 2 Bridge Domains on ACX Series Overview . . . . . . . . . . . . . . . . . . . . . . . . . 755
Layer 2 Learning and Forwarding for Bridge Domains Overview . . . . . . . . . . . . . 759
Configuring a Bridge Domain on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . 760
Configuring Integrated Routing and Bridging in ACX Series . . . . . . . . . . . . . . . . . 761
Configuring VLAN Identifiers for Bridge Domains in ACX Series . . . . . . . . . . . . . 764
Disabling MAC Learning for Bridge Domains on ACX Series . . . . . . . . . . . . . . . . . 765
Configuring Static MAC Addresses for Logical Interfaces in a Bridge Domain in
ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Configuring the Size of the MAC Address Table for Bridge Domains in ACX
Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Configuring MAC Address Limits on a Logical Interface . . . . . . . . . . . . . . . . . . . . 767
Configuring MAC Address limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Configuring MAC Address Limits for VLANs . . . . . . . . . . . . . . . . . . . . . . . . . 768
Configuring MAC Address Limits for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
CLI Commands to Configure MAC Address Limits . . . . . . . . . . . . . . . . . . . . 769
Preventing Communication Among Customer Edge Devices as ACX Routers . . 770
Q-in-Q Tunneling on ACX Series Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Configuring Q-in-Q Tunneling on ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Chapter 25 Configuring Layer 2 and Layer 3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Configuring Interfaces for Layer 2 Circuits Overview . . . . . . . . . . . . . . . . . . . . . . . 774
Configuring the Address for the Neighbor of the Layer 2 Circuit . . . . . . . . . . . . . . 774
Configuring the Neighbor Interface for the Layer 2 Circuit . . . . . . . . . . . . . . . . . . 774
Configuring a Community for the Layer 2 Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Configuring the Control Word for Layer 2 Circuits . . . . . . . . . . . . . . . . . . . . . . . . . 775
Configuring the Encapsulation Type for the Layer 2 Circuit Neighbor Interface . . 777
Configuring the MTU Advertised for a Layer 2 Circuit . . . . . . . . . . . . . . . . . . . . . . 777
Configuring the Protect Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Configuring the Virtual Circuit ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Configuring the Interface Encapsulation Type for Layer 2 Circuits . . . . . . . . . . . . 779
Configuring Layer 2 Circuits over Both RSVP and LDP LSPs . . . . . . . . . . . . . . . . . 779
Enabling the Layer 2 Circuit When the MTU Does Not Match . . . . . . . . . . . . . . . 780
xviii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Enabling the Layer 2 Circuit When the Encapsulation Does Not Match . . . . . . . 780
Configuring Local Interface Switching in Layer 2 Circuits . . . . . . . . . . . . . . . . . . . 781
Configuring the Interfaces for the Local Interface Switch . . . . . . . . . . . . . . . 781
Enabling Local Interface Switching When the MTU Does Not Match . . . . . . 782
Example: Configuring Layer 2 Circuit Switching Protection . . . . . . . . . . . . . . . . . 783
Accepting Route Updates with Unique Inner VPN Labels in Layer 3 VPNs . . . . . 785
Accepting Up to One Million Layer 3 VPN Route Updates . . . . . . . . . . . . . . 786
Accepting More Than One Million Layer 3 VPN Route Updates . . . . . . . . . . 787
Enabling Chained Composite Next Hops for IPv6 Labeled Unicast
Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Understanding Per-Packet Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Configuring Per-Packet Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Per-Packet Load Balancing Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Configuring Load Balancing Based on MPLS Labels on ACX Series Routers . . . . 793
Configuring Load Balancing for Ethernet Pseudowires . . . . . . . . . . . . . . . . . . . . . 797
Configuring Load Balancing Based on MAC Addresses . . . . . . . . . . . . . . . . . . . . 798
ECMP Flow-Based Forwarding on ACX Series Routers . . . . . . . . . . . . . . . . . . . . 799
Sample Scenario of H-VPLS on ACX Series Routers for IPTV Services . . . . . . . 800
Sample Configuration Scenario of H-VPLS for IPTV Services . . . . . . . . . . . 800
Guidelines for H-VPLS on ACX Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
Guidelines for Configuring Unicast RPF on ACX Series Routers . . . . . . . . . . . . . 803
Configuring Unicast RPF on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . 804
Interworking of Unicast RFF With Different System Conditions . . . . . . . . . . 805
Configuring Unicast RPF Strict Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
Configuring Unicast RPF Loose Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
Unicast RPF and Default Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
Unicast RPF Behavior with a Default Route . . . . . . . . . . . . . . . . . . . . . . 807
Unicast RPF Behavior Without a Default Route . . . . . . . . . . . . . . . . . . . 807
Configuring Unicast RPF on a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
Example: Configuring Unicast RPF on a VPN . . . . . . . . . . . . . . . . . . . . 808
Configuring Unicast RPF Fail Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
Verifying Unicast RPF Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
Chapter 26 Configuring Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Layer 3 VPN Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Understanding Layer 3 VPN Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Understanding VPN-IPv4 Addresses and Route Distinguishers . . . . . . . . . . . . . . 815
Understanding Virtual Routing and Forwarding Tables . . . . . . . . . . . . . . . . . . . . 818
Understanding IPv4 Route Distribution in a Layer 3 VPN . . . . . . . . . . . . . . . . . . . 822
Distribution of Routes from CE to PE Routers . . . . . . . . . . . . . . . . . . . . . . . . 822
Distribution of Routes Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . . 823
Distribution of Routes from PE to CE Routers . . . . . . . . . . . . . . . . . . . . . . . . 825
Understanding Layer 3 VPN Forwarding Through the Core . . . . . . . . . . . . . . . . . 826
Understanding Routing Instances for Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . 827
Copyright © 2017, Juniper Networks, Inc. xix

Configuring a VPN Tunnel for VRF Table Lookup . . . . . . . . . . . . . . . . . . . . . . . . . 828

Introduction to Configuring Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
Configuring Routing Between PE and CE Routers in Layer 3 VPNs . . . . . . . . . . . 830
Configuring BGP Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . . . 831
Configuring OSPF Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . 832
Configuring OSPF Version 2 Between the PE and CE Routers . . . . . . . . 832
Configuring OSPF Version 3 Between the PE and CE Routers . . . . . . . . 832
Configuring OSPF Sham Links for Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . 833
OSPF Sham Links Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Configuring OSPF Sham Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
OSPF Sham Links Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Configuring an OSPF Domain ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Hub-and-Spoke Layer 3 VPNs and OSPF Domain IDs . . . . . . . . . . . . . . 837
Configuring RIP Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . . . 838
Configuring Static Routes Between the PE and CE Routers . . . . . . . . . . . . . 840
Limiting the Number of Paths and Prefixes Accepted from CE Routers in Layer 3
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Understanding IPv6 Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Layer 3 VPNs for IPv4 and IPv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Configuring Layer 3 VPNs to Carry IPv6 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . 844
Configuring IPv6 on the PE Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
Configuring the Connection Between the PE and CE Routers . . . . . . . . . . . 845
Configuring BGP on the PE Router to Handle IPv6 Routes . . . . . . . . . . 845
Configuring BGP on the PE Router for IPv4 and IPv6 Routes . . . . . . . . 846
Configuring OSPF Version 3 on the PE Router . . . . . . . . . . . . . . . . . . . . 846
Configuring Static Routes on the PE Router . . . . . . . . . . . . . . . . . . . . . . 847
Configuring IPv6 on the Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
Configuring EBGP Multihop Sessions Between PE and CE Routers in Layer 3
VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
Configuring Layer 3 VPNs to Carry IBGP Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . 849
Configuring a Label Allocation and Substitution Policy for VPNs . . . . . . . . . . . . 850
Configuring Protocol-Independent Load Balancing in Layer 3 VPNs . . . . . . . . . 852
Configuring Load Balancing for Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . 852
Configuring Load Balancing and Routing Policies . . . . . . . . . . . . . . . . . . . . . 854
Configuring the Algorithm That Determines the Active Route to Evaluate AS
Numbers in AS Paths for VPN Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Accepting Route Updates with Unique Inner VPN Labels in Layer 3 VPNs . . . . . 855
Accepting Up to One Million Layer 3 VPN Route Updates . . . . . . . . . . . . . . 856
Accepting More Than One Million Layer 3 VPN Route Updates . . . . . . . . . . 857
Enabling Chained Composite Next Hops for IPv6 Labeled Unicast
Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Part 7 Configuring Class of Service on ACX Series Routers

Chapter 27 Configuring Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
CoS on ACX Series Universal Access Routers Features Overview . . . . . . . . . . . . 864
Understanding CoS CLI Configuration Statements on ACX Series Universal
Access Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
Configuring CoS on ACX Series Universal Access Routers . . . . . . . . . . . . . . . . . . 866
xx Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Classifiers and Rewrite Rules at the Global, Physical and Logical Interface Levels
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
Configuring Classifiers and Rewrite Rules at the Global and Physical Interface
Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Understanding Schedulers Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
Configuring Shared and Dedicated Buffer Memory Pools . . . . . . . . . . . . . . . . . . 876
CoS for PPP and MLPPP Interfaces on ACX Series Routers . . . . . . . . . . . . . . . . . 877
Limitations That are Common for CoS on PPP and MLPPP Interfaces . . . . 878
Limitations for CoS on PPP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Guidelines for Configuring CoS on PPP and MLPPP Interfaces . . . . . . . . . . 879
Limitations for CoS on MLPPP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
CoS Functionalities for IPv4 Over PPP Interfaces . . . . . . . . . . . . . . . . . . . . . 881
CoS Functionalities for IPv4 Over MLPPP Interfaces . . . . . . . . . . . . . . . . . . 883
CoS for NAT Services on ACX Series Universal Access Routers . . . . . . . . . . . . . . 887
Configuring the IEEE 802.1p Field for CoS Host Outbound Traffic in ACX
Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Configuring a Global Default IEEE 802.1p Value for All Host Outbound Traffic in
ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Applying Egress Interface Rewrite Rules to the IEEE 802.1p Field for All Host
Outbound Traffic on the Interface in ACX Series . . . . . . . . . . . . . . . . . . . . . 890
Overview of Assigning Service Levels to Packets Based on Multiple Packet
Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Configuring Multifield Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
Understanding CoS on ATM IMA Pseudowire Interfaces Overview . . . . . . . . . . . 895
Cell-Based ATM Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
Cell-Based ATM Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
Fixed Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
Configuring Fixed Classification on an ATM IMA Pseudowire . . . . . . . . . . . . . . . 897
Example: Configuring Fixed Classification on an ATM IMA Pseudowire . . . . . . . 898
Configuring Shaping on an ATM IMA Pseudowire . . . . . . . . . . . . . . . . . . . . . . . . . 901
Example: Configuring Shaping on an ATM IMA Pseudowire . . . . . . . . . . . . . . . . 902
Understanding RED Drop Profiles Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Configuring RED Drop Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Controlling Network Access Using Traffic Policing Overview . . . . . . . . . . . . . . . 908
Congestion Management for IP Traffic Flows . . . . . . . . . . . . . . . . . . . . . . . . 908
Traffic Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Traffic Color Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Forwarding Classes and PLP Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Policer Application to Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Configuring Policing on an ATM IMA Pseudowire . . . . . . . . . . . . . . . . . . . . . . . . . 912
Configuring an Input Policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Configuring the ATM IMA Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Example: Configuring Policing on an ATM IMA Pseudowire . . . . . . . . . . . . . . . . . 915
Hierarchical Policers on ACX Series Routers Overview . . . . . . . . . . . . . . . . . . . . 920
Guidelines for Configuring Hierarchical Policers on ACX Routers . . . . . . . . . . . . . 921
Hierarchical Policer Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Guarantee Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Peak Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
Hybrid Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
Copyright © 2017, Juniper Networks, Inc. xxi

Processing of Hierarchical Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928

Actions Performed for Hierarchical Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Instantiation Methods for Child and Aggregate Policers . . . . . . . . . . . . . . . . 929
Instantiation Methods for Child Policers or Normal Policers . . . . . . . . . . . . 929
Instantiation Methods for Aggregate Policers . . . . . . . . . . . . . . . . . . . . . . . . 929
Configuring Aggregate Parent and Child Policers on ACX Series Routers . . . . . . 931
Hierarchical Class of Service Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933
Hierarchical Class of Service in ACX5000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936
Hierarchical Scheduling on the Physical Interface . . . . . . . . . . . . . . . . . . . . 936
Traffic Control Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
Schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
Drop Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Scheduler Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Applying the Traffic Control Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Subscriber Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Configuring hierarchical class of service for Layer 3 VPN Service . . . . . 939
Configuring hierarchical class of service for Layer 2 VPN (Ethernet
Pseudowires) Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Configuring hierarchical class of service for VPLS Service . . . . . . . . . . . 941
Verifying the hierarchical class of service configurations . . . . . . . . . . . . 942
Chapter 28 Configuring Behavior Aggregate Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . 949
Understanding How Behavior Aggregate Classifiers Prioritize Trusted Traffic . . 950
Default Behavior Aggregate Classification Overview in ACX Series . . . . . . . . . . . 953
Default IP Precedence Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Default MPLS EXP Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Default IEEE 802.1p Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
Default IEEE 802.1ad Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
Default DSCP and DSCP IPv6 Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
Applying DSCP and DSCP IPv6 Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Part 8 Configuring Network Management and Administration on ACX

Series Routers
Chapter 29 Understanding Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Real-Time Performance Monitoring on ACX Series Routers . . . . . . . . . . . . . . . . 963
TWAMP on ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
Storm Control on ACX Series Routers Overview . . . . . . . . . . . . . . . . . . . . . . . . . 966
Standard SNMP MIBs Supported by Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Enterprise-Specific MIBs and Supported Devices . . . . . . . . . . . . . . . . . . . . . . . . 984
Chapter 30 Configuring IP and MAC Address Validation . . . . . . . . . . . . . . . . . . . . . . . . . 995
IP and MAC Address Validation in ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
Trusted Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Types of IP and MAC Address Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Configuring IP and MAC Address Validation for Static Interfaces . . . . . . . . . . . . 997
xxii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Chapter 31 Configuring Network Address Translation (NAT) and Stateful Firewall

Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Network Address Translation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Network Address Port Translation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
Network Address Translation Address Overload in ACX Series . . . . . . . . . . . . . 1001
Network Address Translation Constraints on ACX . . . . . . . . . . . . . . . . . . . . . . . 1003
Network Address Translation Rules Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
Configuring Match Direction for NAT Rules . . . . . . . . . . . . . . . . . . . . . . . . . 1005
Configuring Match Conditions in NAT Rules . . . . . . . . . . . . . . . . . . . . . . . . 1005
Configuring Actions in NAT Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
Configuring Translation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
Configuring Address Pools for Network Address Port Translation (NAPT)
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
Endpoint Independent Flow for NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
Enabling Inline Services Interface on ACX Series . . . . . . . . . . . . . . . . . . . . . . . . 1008
ALGs Available by Default for Junos OS Address Aware NAT on ACX500
Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
ALG Support Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Basic TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
Basic UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
UNIX Remote-Shell Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
Junos Network Secure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
Stateful Firewall Support for Application Protocols . . . . . . . . . . . . . . . . . . . 1021
Stateful Firewall Anomaly Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
Configuring Stateful Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Configuring Match Direction for Stateful Firewall Rules . . . . . . . . . . . . . . . 1024
Configuring Match Conditions in Stateful Firewall Rules . . . . . . . . . . . . . . . 1025
Configuring Actions in Stateful Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . 1026
Configuring IP Option Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Understanding Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
Configuring Service Sets for Network Address Translation . . . . . . . . . . . . . . . . 1030
Configuring Service Sets to Be Applied to Services Interfaces . . . . . . . . . . . . . . 1031
Configuring Services Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
Configuring Next-Hop Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
Determining Traffic Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
Interface-Style Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
Next-Hop-Style Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
Service Filters in ACX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Guidelines for Applying Service Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
Restrictions for Inline Services Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
Statement Hierarchy for Applying Service Filters . . . . . . . . . . . . . . . . . . . . 1036
Associating Service Rules with Inline Services Interfaces . . . . . . . . . . . . . . 1037
Filtering Traffic Before Accepting Packets for Service Processing . . . . . . . . 1037
Service Filter Match Conditions for IPv4 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Service Filter Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Copyright © 2017, Juniper Networks, Inc. xxiii

Configuring Queuing and Scheduling on Inline Services Interface . . . . . . . . . . . 1040

Chapter 32 Configuring Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
Supported Standards for Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
Guidelines for Configuring Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044
Statement Hierarchy for Configuring Firewall Filters . . . . . . . . . . . . . . . . . . 1044
Firewall Filter Protocol Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045
Firewall Filter Names and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
Firewall Filter Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
Firewall Filter Match Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
Firewall Filter Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
Guidelines for Applying Standard Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . 1049
Applying Firewall Filters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
Statement Hierarchy for Applying Firewall Filters . . . . . . . . . . . . . . . . . . . . 1050
Protocol-Independent Firewall Filters on MX Series Routers . . . . . . . 1050
All Other Firewall Filters on Logical Interfaces . . . . . . . . . . . . . . . . . . . . 1051
Restrictions on Applying Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
Number of Input and Output Filters Per Logical Interface . . . . . . . . . . 1051
MPLS and Layer 2 CCC Firewall Filters in Lists . . . . . . . . . . . . . . . . . . . 1052
Layer 2 CCC Firewall Filters on MX Series Routers and EX Series
Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Standard Firewall Filter Match Conditions and Actions on ACX Series Routers
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Standard Firewall Filter Match Conditions for IPv4 Traffic on ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054
Standard Firewall Filter Match Conditions for IPv6 Traffic on ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
Standard Firewall Filter Match Conditions for MPLS Traffic on ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
Standard Firewall Filter Terminating Actions on ACX Series Routers . . . . . . . . 1063
Standard Firewall Filter Nonterminating Actions on ACX Series Routers . . . . . 1064
Standard Firewall Filter Match Conditions for CCC Firewall Family Filters on ACX
Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Standard Firewall Filter Match Conditions for CCC Family Firewall Filters
on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Standard Firewall Filter Match Conditions for Bridge Family Firewall Filters on
ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068
Standard Firewall Filter Match Conditions for Bridge Family Firewall Filters
on ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068
Firewall Filter Match Conditions for VPLS Traffic . . . . . . . . . . . . . . . . . . . . . . . . 1070
Firewall Filter Support on Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 1080
Filter-Based Forwarding for Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
Forwarding Table Filters for Routing Instances on ACX Series Routers . . . . . . . 1083
Configuring Forwarding Table Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
Chapter 33 Configuring IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087
IPsec for ACX Series Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088
Security Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088
xxiv Copyright © 2017, Juniper Networks, Inc.

Table of Contents
IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088
Enabling Inline Services Interface on ACX Series . . . . . . . . . . . . . . . . . . . . . . . . 1089
Understanding Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
Configuring Service Sets to Be Applied to Services Interfaces . . . . . . . . . . . . . . 1092
Configuring Services Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1092
Configuring Next-Hop Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093
Determining Traffic Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093
Interface-Style Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Next-Hop-Style Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Configuring IPsec Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095
Configuring the Local Gateway Address for IPsec Service Sets . . . . . . . . . 1095
IKE Addresses in VRF Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
Configuring IKE Access Profiles for IPsec Service Sets . . . . . . . . . . . . . . . . 1096
Configuring or Disabling Antireplay Service . . . . . . . . . . . . . . . . . . . . . . . . . 1097
Configuring IPsec Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
Configuring the Authentication Algorithm for an IPsec Proposal . . . . . . . . 1098
Configuring the Description for an IPsec Proposal . . . . . . . . . . . . . . . . . . . 1099
Configuring the Encryption Algorithm for an IPsec Proposal . . . . . . . . . . . 1099
Configuring the Lifetime for an IPsec SA . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Configuring the Protocol for a Dynamic SA . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Configuring IKE Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
Configuring the Authentication Algorithm for an IKE Proposal . . . . . . . . . . 1100
Configuring the Authentication Method for an IKE Proposal . . . . . . . . . . . . 1100
Configuring the Encryption Algorithm for an IKE Proposal . . . . . . . . . . . . . . 1101
Configuring the Lifetime for an IKE SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101
Example: Configuring an IKE Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102
Configuring IPsec Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102
Configuring the Description for an IPsec Policy . . . . . . . . . . . . . . . . . . . . . . 1103
Configuring Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1103
Configuring the Proposals in an IPsec Policy . . . . . . . . . . . . . . . . . . . . . . . . 1103
Configuring IKE Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Configuring the Proposals in an IKE Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Configuring the Preshared Key for an IKE Policy . . . . . . . . . . . . . . . . . . . . . . 1104
Configuring IPsec Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
Configuring Match Direction for IPsec Rules . . . . . . . . . . . . . . . . . . . . . . . . . 1106
Configuring Match Conditions in IPsec Rules . . . . . . . . . . . . . . . . . . . . . . . . 1107
Configuring Actions in IPsec Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Configuring Destination Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Configuring IPsec Rule Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Tracing IPsec Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Chapter 34 Configuring Operations, Administration, and Management (OAM) . . . . . . 1111
Understanding Ethernet OAM Link Fault Management for ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Configuring Ethernet Local Management Interface on ACX Series . . . . . . . . . . . 1113
Ethernet Local Management Interface Overview . . . . . . . . . . . . . . . . . . . . . 1113
Configuring the Ethernet Local Management Interface . . . . . . . . . . . . . . . . . 1115
Configuring an OAM Protocol (CFM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Assigning the OAM Protocol to an EVC . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Copyright © 2017, Juniper Networks, Inc. xxv

Enabling E-LMI on an Interface and Mapping CE VLAN IDs to an

EVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116
Ethernet Frame Delay Measurements Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 1117
ITU-T Y.1731 Frame Delay Measurement Feature . . . . . . . . . . . . . . . . . . . . . . 1117
Ethernet Frame Delay Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
Two-Way Ethernet Frame Delay Measurement . . . . . . . . . . . . . . . . . . . . . . . 1118
DMM Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
DMR Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
DMR Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
Two-Way ETH-DM Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
Two-Way ETH-DM Frame Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
Restrictions for Ethernet Frame Delay Measurement . . . . . . . . . . . . . . . . . . 1120
Ethernet Frame Loss Measurement Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
Proactive Mode for SLA Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
Ethernet Delay Measurements and Loss Measurement by Proactive
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
On-Demand Mode for SLA Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125
Configuring MEP Interfaces to Support Delay Measurement . . . . . . . . . . . . . . . 1125
Ethernet OAM Connectivity Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . 1126
IEEE 802.1ag OAM Connectivity Fault Management in ACX Series Overview . . . 1128
Connectivity Fault Management Key Elements . . . . . . . . . . . . . . . . . . . . . . 1128
Configuring Maintenance Association Intermediate Points in ACX Series . . . . . 1129
Configuring the Maintenance Domain Bridge Domain . . . . . . . . . . . . . . . . . 1130
Configuring the Maintenance Domain MIP Half Function . . . . . . . . . . . . . . 1130
Configuring the Maintenance Association Intermediate Points with Bridge
Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1131
Configuring the Maintenance Association Intermediate Points with Circuit
Cross-Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1131
Configuring the Maintenance Association Intermediate Points with Bridge
Domain when Maintenance Association End Point is Configured . . . . . 1131
Configuring the Maintenance Intermediate Points with Circuit Cross-Connect
when Maintenance Association End Point is Configured . . . . . . . . . . . . 1132
Example: Configuring IEEE 802.3ah OAM Support for an Interface . . . . . . . . . . 1133
Enabling Dying Gasp Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135
Ethernet Alarm Indication Signal Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136
Configuring Alarm Indication Signal on ACX Series Routers . . . . . . . . . . . . . . . . 1138
Ethernet Synthetic Loss Measurement Overview . . . . . . . . . . . . . . . . . . . . . . . . 1140
Transmission of ETH-SLM Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141
Initiation and Transmission of SLM Requests . . . . . . . . . . . . . . . . . . . . . . . . 1142
Reception of SLMs and Transmission of SLRs . . . . . . . . . . . . . . . . . . . . . . . 1142
Reception of SLRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
Computation of Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
Format of ETH-SLM Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144
SLM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144
SLR PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
Data Iterator TLV Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
Guidelines for Configuring ETH-SLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
xxvi Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Scenarios for Configuration of ETH-SLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147

Upstream MEP in MPLS Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Downstream MEP in Ethernet Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
Managing ETH-SLM Statistics and ETH-SLM Frame Counts . . . . . . . . . . . . . . . 1148
Displaying ETH-SLM Statistics Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
Displaying ETH-SLM Statistics and Frame Counts . . . . . . . . . . . . . . . . . . . 1149
Displaying ETH-SLM Frame Counts for MEPs by Enclosing CFM Entity . . . 1150
Displaying ETH-SLM Frame Counts for MEPs by Interface or Domain
Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
Clearing ETH-SLM Statistics and Frame Counts . . . . . . . . . . . . . . . . . . . . . . 1151
Clearing Iterator Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Starting a Proactive ETH-SLM Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
Configuring MEP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
Configuring an Iterator Profile for ETH-SLM . . . . . . . . . . . . . . . . . . . . . . . . . 1154
Associating the Iterator Profile with MEPs for ETH-SLM . . . . . . . . . . . . . . . 1155
Starting an On-Demand ETH-SLM Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156
Dynamic Ternary Content Addressable Memory Overview . . . . . . . . . . . . . . . . . 1157
Understanding Dynamic Ternary Content Addressable Memory . . . . . . . . . 1157
Applications using Dynamic TCAM Infrastructure . . . . . . . . . . . . . . . . . . . . 1158
Features Using TCAM Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158
Monitoring TCAM Resource Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
Example: Monitoring and Troubleshooting the TCAM Resource . . . . . . . . . 1162
Service Scaling on ACX5048 and ACX5096 Routers . . . . . . . . . . . . . . . . . . . . . 1167
Understanding Layer 2 Next Generation Mode on ACX5048 and ACX5096
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Understanding and Configuring the Unified Forwarding Table . . . . . . . . . . . . . . 1169
Using the Unified Forwarding Table to Optimize Address Storage . . . . . . . 1169
Configuring the Unified Forwarding Table to Optimize Address Storage
Using Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1170
Interpreting the Enterprise-Specific Service OAM MIB . . . . . . . . . . . . . . . . . . . . . 1171
Service OAM MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1171
Managed Objects for jnxSoamPmMepTable . . . . . . . . . . . . . . . . . . . . . . . . . 1172
Managed Objects for jnxSoamLmCfgTable . . . . . . . . . . . . . . . . . . . . . . . . . 1174
Managed Objects for jnxSoamLmMeasuredStatsTable . . . . . . . . . . . . . . . 1184
Managed Objects for jnxSoamLmCurrentStatsTable . . . . . . . . . . . . . . . . . 1185
Managed Objects for jnxSoamLmHistoryStatsTable . . . . . . . . . . . . . . . . . . 1188
Managed Objects for jnxSoamDmCfgTable . . . . . . . . . . . . . . . . . . . . . . . . . 1191
Managed Objects for jnxSoamDmMeasuredStatsTable . . . . . . . . . . . . . . . 1205
Managed Objects for jnxSoamDmCurrentStatsTable . . . . . . . . . . . . . . . . . 1207
Managed Objects for jnxSoamDmHistoryStatsTable . . . . . . . . . . . . . . . . . . 1211
Managed Objects for jnxSoamLmThresholdCfgTable . . . . . . . . . . . . . . . . . 1216
Managed Objects for jnxSoamDmThresholdCfgTable . . . . . . . . . . . . . . . . . 1219
Managed Objects for jnxSoamPmNotificationObj Table . . . . . . . . . . . . . . . 1226
Managed Objects for jnxSoamPmNotifications Table . . . . . . . . . . . . . . . . . 1227
Copyright © 2017, Juniper Networks, Inc. xxvii

Chapter 35 Configuring Virtual Private LAN Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235

Introduction to VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235
Introduction to Configuring VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236
VPLS Multihoming Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
Configuring VPLS Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239
Configuring BGP Signaling for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Configuring the VPLS Site Name and Site Identifier . . . . . . . . . . . . . . . 1241
Configuring Automatic Site Identifiers for VPLS . . . . . . . . . . . . . . . . . . 1242
Configuring the Site Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243
Configuring the VPLS Site Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245
Configuring the VPLS Site Preference . . . . . . . . . . . . . . . . . . . . . . . . . . 1245
Configuring LDP Signaling for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246
Configuring LDP Signaling for the VPLS Routing Instance . . . . . . . . . . 1247
Configuring LDP Signaling on the Router . . . . . . . . . . . . . . . . . . . . . . . 1248
Configuring VPLS Routing Instance and VPLS Interface Connectivity . . . . 1249
Configuring the VPLS Encapsulation Type . . . . . . . . . . . . . . . . . . . . . . . . . . 1249
Configuring the MPLS Routing Table to Leak Routes a Nondefault Routing
Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250
Configuring the VPLS MAC Table Timeout Interval . . . . . . . . . . . . . . . . . . . . 1251
Configuring the Size of the VPLS MAC Address Table . . . . . . . . . . . . . . . . . 1251
Limiting the Number of MAC Addresses Learned from an Interface . . . . . . 1252
Removing Addresses from the MAC Address Database . . . . . . . . . . . . . . . 1253
Configuring Interfaces for VPLS Routing in ACX Series . . . . . . . . . . . . . . . . . . . . 1255
Configuring the VPLS Interface Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256
Configuring VPLS Interface Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . 1256
Enabling Flexible VLAN Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
Configuring VLAN IDs for Logical Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 1259
Sample Scenario of Hierarchical Virtual Private LAN Service on Logical
Tunnel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259
Configuring Aggregated Ethernet Interfaces for VPLS . . . . . . . . . . . . . . . . . 1261
Configuring VLAN Identifiers for VLANs and VPLS Routing Instances in ACX
Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1262
Configuring Static Pseudowires for VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266
Configuring VPLS Without a Tunnel Services PIC . . . . . . . . . . . . . . . . . . . . . . . . 1267
Configuring VPLS Multihoming (FEC 128) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268
VPLS Multihomed Site Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269
Specifying an Interface as the Active Interface . . . . . . . . . . . . . . . . . . . 1270
Configuring Multihoming on the PE Router . . . . . . . . . . . . . . . . . . . . . . 1270
VPLS Single-Homed Site Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1271
Configuring Firewall Filters and Policers for VPLS in ACX Series . . . . . . . . . . . . . 1271
Configuring a VPLS Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1271
Configuring an Interface-Specific Counter for VPLS . . . . . . . . . . . . . . . 1272
Configuring an Action for the VPLS Filter . . . . . . . . . . . . . . . . . . . . . . . . 1272
Applying a VPLS Filter to an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 1272
Configuring a VPLS Policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1273
Configuring Interoperability Between BGP Signaling and LDP Signaling in
VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274
LDP BGP Interworking Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275
Configuring FEC 128 VPLS Mesh Groups for LDP BGP Interworking . . . . . . 1275
xxviii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
Configuring FEC 129 VPLS Mesh Groups for LDP BGP Interworking . . . . . . 1275
Configuring Switching Between Pseudowires Using VPLS Mesh Groups . . 1276
Configuring Integrated Routing and Bridging Support for LDP BGP
Interworking with VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277
Configuring Inter-AS VPLS with MAC Processing at the ASBR . . . . . . . . . . 1277
Inter-AS VPLS with MAC Operations Configuration Summary . . . . . . . 1277
Configuring the ASBRs for Inter-AS VPLS . . . . . . . . . . . . . . . . . . . . . . . 1278
Interoperability Between BGP Signaling and LDP Signaling in VPLS . . . . . . . . . 1279
LDP-Signaled and BGP-Signaled PE Router Topology . . . . . . . . . . . . . . . . 1279
Flooding Unknown Packets Across Mesh Groups . . . . . . . . . . . . . . . . . . . . . 1281
Unicast Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1281
PE Router Mesh Groups for VPLS Routing Instances . . . . . . . . . . . . . . . . . . . . . . 1281
Example: Configuring BGP-Based H-VPLS Using Different Mesh Groups for Each
Spoke Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282
Example: Configuring LDP-Based H-VPLS Using a Single Mesh Group to
Terminate the Layer 2 Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304
Example: Configuring H-VPLS With VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1310
Part 9 Monitoring and Troubleshooting ACX Series Routers

Chapter 36 Diagnosing Cable States Using Time Domain Reflectometry (TDR) . . . . 1327
Time Domain Reflectometry on ACX Series Routers Overview . . . . . . . . . . . . . . 1327
Diagnosing a Faulty Twisted-Pair Cable on ACX Series Routers . . . . . . . . . . . . 1330
Chapter 37 Configuring RFC 2544-Based Benchmarking Tests . . . . . . . . . . . . . . . . . . 1335
RFC 2544-Based Benchmarking Tests Overview . . . . . . . . . . . . . . . . . . . . . . . . 1335
Layer 2 and Layer 3 RFC 2544-Based Benchmarking Test Overview . . . . . . . . . 1338
Configuring RFC 2544-Based Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . . 1341
Configuring a Test Profile for an RFC 2544-Based Benchmarking Test . . . 1346
Configuring a Test Name for an RFC 2544-Based Benchmarking Test . . . 1348
Starting and Stopping the RFC 2544-Based Benchmarking Test . . . . . . . . 1354
Copying an RFC 2544-Based Benchmarking Test Result . . . . . . . . . . . . . . 1354
Configuring Ethernet Loopback for RFC 2544-Based Benchmarking Tests . . . . 1355
RFC 2544-Based Benchmarking Test States . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358
Example: Configuring an RFC 2544-Based Benchmarking Test for Layer 3 IPv4
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359
Example: Configuring an RFC 2544-Based Benchmarking Test for NNI Direction
of Ethernet Pseudowires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1367
Example: Configuring an RFC 2544-Based Benchmarking Test for UNI Direction
of Ethernet Pseudowires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375
Chapter 38 Configuring Port, VLAN, and Flow Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . 1385
Port, VLAN, and Flow Mirroring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385
Port, VLAN, and Flow Mirroring on ACX5000 Series Routers . . . . . . . . . . . . . . . 1386
Configuring Port, VLAN, and Flow Mirroring on ACX5000 Series Routers . . . . . 1388
Configuring Port Mirroring on ACX5000 Series Routers . . . . . . . . . . . . . . . 1388
Configuring the Input as Logical Interface and the Output as Logical
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389
Configuring the Input as a Logical Interface and the Ouput as VLAN . . 1389
Copyright © 2017, Juniper Networks, Inc. xxix

Configuring the Input as Logical Interface and the Output as Next-hop

IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389
Configuring the Input as Logical Interface and Output as VLAN with the
no-tag Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390
Configuring VLAN Mirroring on ACX5000 Series Routers . . . . . . . . . . . . . . 1390
Configuring the Input as VLAN and the Output as Logical Interface . . 1390
Configuring the Input and the Ouput as VLAN . . . . . . . . . . . . . . . . . . . 1391
Configuring the Input as VLAN and the Output as Next-hop IP
Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1391
Configuring the Input as VLAN and Output as VLAN with the no-tag
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1391
Configuring Flow Mirroring on ACX5000 Series Routers . . . . . . . . . . . . . . . 1392
Configuring the Family as ethernet-switching and Specifying the Output
as Layer 2 Logical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1392
Configuring the Family as ethernet-switching and Specifying the Output
as VLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393
Configuring the Output as VLAN with the no-tag Option . . . . . . . . . . 1394
Configuring the Family as inet and Specifying the Output as Next-Hop
IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Chapter 39 Configuring sFlow Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397
Overview of sFlow Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397
Configuring sFlow Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1399
Chapter 40 Troubleshooting ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1401
CT1 and CE1 Interfaces Alarms, Errors, and Defects . . . . . . . . . . . . . . . . . . . . . . . 1401
Troubleshooting PoE Interfaces on ACX2000 Universal Access Routers . . . . . 1402
Troubleshooting and Monitoring TCAM Resource in ACX Series Routers . . . . . 1403
Part 10 Configuration Statements and Operational Commands on ACX

Series Routers
Chapter 41 Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1407
access-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417
active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1418
address (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419
aggregate (Routing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
aggregate (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1422
aggregate-policing (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423
aggregated-devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
alarm (chassis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
alarm (chassis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427
allow-any-vci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428
announce-interval (Slave Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1429
announce-interval (Master Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430
as-path (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1431
as-path-compare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1433
asymmetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434
asymmetric-hold-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1435
atm-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
xxx Copyright © 2017, Juniper Networks, Inc.

Table of Contents
atm-policer (Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438

atm-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439
auto-export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1440
autoinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442
autoinstallation (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
autonomous-system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444
backup-neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1447
bandwidth-kbps (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
bandwidth (Tunnel Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449
bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1450
bpdu-block-on-edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1451
bpdu-timeout-action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1452
brief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1453
bridge-domains (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1455
bridge-options (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456
bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456
cdvt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1457
cell-bundle-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1457
cell-bundle-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1458
cesopsn-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1459
classifiers (Definition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1460
classifiers (Physical Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1461
clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1461
clock-class-to-quality-level-mapping (ACX Series) . . . . . . . . . . . . . . . . . . . . . 1462
clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463
clock-client (Master Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464
clock-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1465
clock-mode (Chassis Synchronization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466
clock-source (PTP Unicast Slave Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1467
color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1468
copy-tos-from-inner-ip-header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
copy-ttl-from-inner-ip-header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1469
community (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1470
confederation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1472
continue-network-mode (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473
convert-clock-class-to-quality-level (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . 1474
delay-buffer-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1474
delete-upon-commit (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1475
delegation-cleanup-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1476
delegation-priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477
description (Routing Instances) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478
destination (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1479
destination-ipv4-address (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . 1480
destination-ipv4-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1481
destination-port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1481
destination-mac-address (RFC2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . 1482
destination-udp-port (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . 1483
destination-networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1484
direction (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485
Copyright © 2017, Juniper Networks, Inc. xxxi

disable (Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1486

disable (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487
disable-signature-check (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . 1488
discard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1489
dhcp-relay (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1491
dhcpv6 (DHCPv6 Relay Agent on ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . 1493
domain-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494
domain-vpn-tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1495
domain-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1495
dscp (CoS Classifiers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496
dscp (CoS Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496
dscp (Rewrite Rules on Physical Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497
dscp-code-points (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
dscp-ipv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1500
dynamic-tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1502
e1-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1503
e1-options (BITS Interfaces Signal Type) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504
e2e-transparent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1505
ethernet-switch-profile (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506
encapsulation (Logical Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1507
encapsulation (Physical Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1511
esmc-transmit (Chassis Synchronization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1512
export (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1513
family (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514
family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515
family inet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1516
family mpls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518
family multiservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1521
flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1524
flow-map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526
force switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
forwarding-cache (Multicast) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
forwarding-class (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
forwarding-class (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1529
forwarding-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1530
fragment-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1531
framing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532
framing (E1 Options for BITS Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533
framing (T1 Options for BITS Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
generate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535
gigether-options (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536
global-arp-prefix-limit (Host Fast Reroute) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1537
global-mac-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538
global-mac-table-aging-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1539
global-no-mac-learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1540
global-supplementary-blackout-timer (Host Fast Reroute) . . . . . . . . . . . . . . . 1541
gps (Chassis Synchronization Source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1542
graceful-restart (Enabling Globally) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
xxxii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
grant-duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1544
gre (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1545
group (Origin Validation for BGP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1546
halt-on-prefix-down (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . 1547
hash-key (Forwarding Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1548
hold-interval (Chassis Synchronization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1551
host-fast-reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1552
hybrid (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
ieee-802.1 (Classifier on Physical Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1554
ieee-802.1 (Rewrite Rules on Physical Interface) . . . . . . . . . . . . . . . . . . . . . . . . 1554
igmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
ima-group-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557
ima-link-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559
independent-domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
inline-services (PIC level) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1561
inet-precedence (CoS Classifiers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1562
inet-precedence (Classifier on Physical Interface) . . . . . . . . . . . . . . . . . . . . . . . 1563
inet-precedence (Rewrite Rules on Physical Interface) . . . . . . . . . . . . . . . . . . . 1563
inet6-vpn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564
ingress (Chained Composite Next Hop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565
input (Chassis Alarm Relay) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1566
input-relay (Alarm Relay Output Port) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567
in-service (RFC2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1569
interface-mac-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1570
interface (Master Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1572
interface (PTP Slave) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573
interface-routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574
interface-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576
interfaces (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577
interfaces bits (Chassis Synchronization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
interfaces (Chassis Synchronization Source) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1580
ipv4-dscp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
ip-swap (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
ivlan-cfi (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1582
ivlan-id (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1582
ivlan-priority (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1583
l3vpn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1584
label-switched-path-template (Multicast) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1586
link-protection (Host Fast Reroute) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587
local-gateway (IPSec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1587
local-ip-address (PTP Slave Clock Source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1588
logical-interface-policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1589
lsp-external-controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1590
mac-table-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1591
mac-validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593
management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1594
manual (Master Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1595
manual switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596
Copyright © 2017, Juniper Networks, Inc. xxxiii

martians . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597
master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
match-direction (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1600
max-announce-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1601
max-burst-size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602
max-delay-response-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1603
max-sync-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1604
max-unknown-messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605
maximum-paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606
maximum-prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608
med-igp-update-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610
media-type (Dual-Purpose Uplink Ports) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611
metric (Aggregate, Generated, or Static Route) . . . . . . . . . . . . . . . . . . . . . . . . . . 1612
message-rate-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1613
min-announce-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614
min-delay-response-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1615
min-sync-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616
minimum-links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617
mld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1618
mode (Chassis Alarm Relay Input and Output) . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
mode (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1620
mode (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1621
mrru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1622
mtu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1623
multicast (Virtual Tunnel in Routing Instances) . . . . . . . . . . . . . . . . . . . . . . . . . 1627
multicast-mode (PTP Master and Slave Interfaces) . . . . . . . . . . . . . . . . . . . . . 1628
multilink-max-classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
multilink-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1630
multipath (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1631
native-vlan-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1632
network-option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
no-bfd-triggered-local-repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635
no-mac-learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636
no-local-switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637
no-local-switching (VPLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
no-partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639
no-root-port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
no-vrf-advertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1641
no-vrf-propagate-ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1642
oam-liveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1643
oam-period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644
options (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
output (Chassis Alarm Relay) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646
outer-tag-protocol-id (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . 1646
overrides (DHCP Relay Agent) for ACX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1647
ovlan-cfi (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
ovlan-id (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648
packet-action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1649
ovlan-priority (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1652
xxxiv Copyright © 2017, Juniper Networks, Inc.

Table of Contents
packet-loss-priority (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . 1652

packet-size (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1653
partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654
passive (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654
pce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1655
pcep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657
pce-group (PCE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1658
pce-group (Protocols PCEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659
pce-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1660
peak-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1661
pim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1662
policing-action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666
policy (Aggregate and Generated Routes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667
port (Alarm Relay Input) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1668
port (Alarm Relay Output) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669
ppm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1670
ppp-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1672
preference (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674
primary (Virtual Tunnel in Routing Instances) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
priority-hold-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1677
profiles (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678
protect core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1679
protection-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1680
promiscuous-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1682
propagate-settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1683
priority (Chassis Synchronization Source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684
psn-vci (ATM CCC Cell-Relay Promiscuous Mode VPI/VCI Swapping) . . . . . . . 1685
psn-vpi (ATM CCC Cell-Relay Promiscuous Mode VPI/VCI Swapping) . . . . . . 1686
quality-level (Chassis Synchronization Source Interface) . . . . . . . . . . . . . . . . . 1687
quality-level (Clock Class Mapping PTP Slave) . . . . . . . . . . . . . . . . . . . . . . . . . 1689
quality-mode-enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1690
querier (performance-monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1691
receive-failure-threshold (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . 1692
relay (Chassis Alarm) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693
request (Chassis Synchronization Source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1694
rewrite-rules (Physical Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1695
reflect-etype (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696
reflect-mode (RFC2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
rfc2544-benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698
rib (General) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1699
rib-group (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1701
rpf-check (interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1702
route-distinguisher-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1703
route-record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1704
router-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705
routing-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706
rule (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
selection-mode (Chassis Synchronization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709
service-set (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1710
Copyright © 2017, Juniper Networks, Inc. xxxv

service-filter (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712

service-filter (Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713
service-package (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714
service-type (RFC2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715
satop-options (Physical Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716
service-plane-recovery (Inline Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717
short-sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1718
signal-type (BITS Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1719
slave (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1720
source (Chassis Synchronization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1721
source-address (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1722
skip-arp-iteration (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723
source-ipv4-address (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . 1724
source-mac-address (RFC2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . 1725
source-udp-port (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726
source-routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1727
speed (10-Gigabit Ethernet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1728
standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729
static-mac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1730
stateful (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1731
static (Protocols Layer 2 Circuit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732
static (Origin Validation for BGP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
step-percent (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734
sustained-rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1735
switchover-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736
sync-interval (Slave) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737
sync-interval (Master) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738
synchronization (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739
system-defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1740
tag (Routing Options) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1741
t1-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
t1-options (BITS Interfaces Signal Type) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
temperature (Alarm Relay Output) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
test-finish-wait-duration (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . 1744
test-interface (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1744
test-iterator-duration (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . 1745
test-iterator-pass-threshold (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . 1745
test-name (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746
test-profile (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1747
test-type (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1748
tests (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1749
timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1750
timestamp-format (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . 1750
tos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1751
traceoptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1752
traceoptions (PCE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1755
traceoptions (Protocols PCEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757
traffic-control-profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758
translation-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1759
xxxvi Copyright © 2017, Juniper Networks, Inc.

Table of Contents
transport ipv4 (PTP Unicast Master and Slave Interface) . . . . . . . . . . . . . . . . . . 1761

transport 802.3 (PTP Multicast Master and Slave) . . . . . . . . . . . . . . . . . . . . . . 1762
transmit-failure-threshold (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . 1763
trigger (Chassis Alarm Relay Input) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1763
ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764
ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764
tunnel-services (Chassis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765
udp-tcp-port-swap (RFC 2544 Benchmarking) . . . . . . . . . . . . . . . . . . . . . . . . . 1766
unicast (Virtual Tunnel in Routing Instances) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767
unicast-mode (Master Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768
unicast-mode (PTP Slave Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1769
unicast-reverse-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1770
update-rate-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1771
validation (Origin Validation for BGP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772
vci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1773
vlan-id (Bridge Domain in ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1774
vpi (Logical Interface and Interworking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1775
vpi (ATM CCC Cell-Relay Promiscuous Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . 1776
vpi (Define Virtual Path) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1777
vrf-propagate-ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1778
vrf-table-label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1779
wait-to-restore (Chassis Synchronization Source) . . . . . . . . . . . . . . . . . . . . . . . 1780
Chapter 42 Operational Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1781
clear bridge mac-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786
clear oam ethernet connectivity-fault-management sla-iterator-statistics . . . 1787
clear oam ethernet connectivity-fault-management
synthetic-loss-measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788
clear dhcp relay statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789
clear dhcp relay binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1792
clear path-computation-client statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795
monitor ethernet synthetic-loss-measurement . . . . . . . . . . . . . . . . . . . . . . . . . 1796
restart chassis-control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1800
request chassis feb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1802
request diagnostics tdr (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804
request path-computation-client active-pce . . . . . . . . . . . . . . . . . . . . . . . . . . . 1806
request system snapshot (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1807
show bgp neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1810
show bgp replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1828
show bgp summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1831
show bridge domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1837
show bridge mac-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1839
show chassis alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1845
show chassis beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1863
show chassis craft-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1865
show chassis environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1883
show chassis environment fpc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1956
show chassis environment pem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1994
show chassis environment routing-engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2006
Copyright © 2017, Juniper Networks, Inc. xxxvii

show chassis feb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2013

show chassis firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2017
show chassis fpc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2032
show chassis fan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2077
show chassis hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2092
show chassis led . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2315
show chassis mac-addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2326
show chassis pic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2333
show chassis routing-engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2358
show chassis synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2386
show chassis temperature-thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2393
show class-of-service interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2421
show class-of-service system-defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2450
show dhcp relay statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2451
show dhcp relay binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2455
show diagnostics tdr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2461
show filter aggregate policer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2466
show filter policer template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2469
show interfaces (ATM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2471
show interfaces (T1, E1, or DS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2506
show interfaces statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2531
show interfaces queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2544
show interfaces (Link Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2586
show interfaces (10-Gigabit Ethernet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2599
show interfaces (Gigabit Ethernet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2624
show interfaces (Fast Ethernet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2649
show interfaces (Aggregated Ethernet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2666
show isis database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2677
show isis hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2691
show isis interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2693
show isis overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2698
show isis route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2702
show isis spf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2706
show isis statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2711
show l2-learning global-information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2714
show l2-learning global-mac-count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2716
show l2-learning instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2717
show l2-learning interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2719
show lacp interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2721
show lacp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2726
clear lldp neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2728
clear lldp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2729
show lldp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2730
show lldp local-information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2733
show lldp neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2736
show lldp remote-global-statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2742
show lldp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2744
show multicast snooping route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2747
show multicast snooping next-hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2751
xxxviii Copyright © 2017, Juniper Networks, Inc.

Table of Contents
show igmp snooping interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2754

show igmp snooping membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2759
show igmp snooping statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2763
show oam ethernet connectivity-fault-management interfaces . . . . . . . . . . . 2768
show oam ethernet connectivity-fault-management mep-statistics . . . . . . . . 2779
show oam ethernet connectivity-fault-management mep-database . . . . . . . . 2791
show oam ethernet connectivity-fault-management sla-iterator-statistics . . 2802
show oam ethernet connectivity-fault-management
synthetic-loss-statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2807
show oam ethernet connectivity-fault-management server-mep . . . . . . . . . . 2810
show ospf database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2812
show ospf3 database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2823
show (ospf | ospf3) interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2834
show (ospf | ospf3) io-statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2840
show (ospf | ospf3) log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2842
show (ospf | ospf3) neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2845
show (ospf | ospf3) overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2852
show (ospf | ospf3) route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2857
show (ospf | ospf3) statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2863
show pfe tcam app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2868
show pfe tcam usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2869
show pfe tcam errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2877
clear pfe tcam-errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2882
show path-computation-client active-pce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2884
show path-computation-client statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2888
show poe controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2893
show poe telemetries interface (ACX2000 Routers) . . . . . . . . . . . . . . . . . . . . 2896
show ppp interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2898
show ppp summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2907
show ppp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2909
show protection-group ethernet-ring aps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2916
show protection-group ethernet-ring interface . . . . . . . . . . . . . . . . . . . . . . . . . 2920
show protection-group ethernet-ring node-state . . . . . . . . . . . . . . . . . . . . . . . 2923
show protection-group ethernet-ring statistics . . . . . . . . . . . . . . . . . . . . . . . . . 2927
show protection-group ethernet-ring vlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2932
show ptp clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2936
show ptp global-information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2939
show ptp hybrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2943
show ptp lock-status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2945
show ptp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2948
show route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2951
show route active-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2972
show route advertising-protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2977
show route all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2982
show route aspath-regex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2984
show route best . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2986
show route brief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2989
show route community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2991
show route community-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2993
Copyright © 2017, Juniper Networks, Inc. xxxix

show route damping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2995

show route detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3000
show route exact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3020
show route export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3022
show route extensive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3025
show route flow validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3043
show route forwarding-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3045
show route hidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3062
show route inactive-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3065
show route inactive-prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3069
show route instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3071
show route next-hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3079
show route no-community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3085
show route output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3088
show route protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3093
show route receive-protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3106
show route table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3115
show route terse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3153
show services rpm rfc2544-benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3156
show services rpm rfc2544-benchmarking test-id . . . . . . . . . . . . . . . . . . . . . . . 3161
show system autoinstallation status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3178
show system storage partitions (ACX Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3180
show validation database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3182
show validation group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3184
show validation replication database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3186
show validation session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3188
show validation statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3191
show version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3193
test interface e1-bert-start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3207
test interface e1-bert-stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3208
test interface t1-bert-start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3209
test interface t1-bert-stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3210
test services rpm rfc2544-benchmarking test . . . . . . . . . . . . . . . . . . . . . . . . . . . 3211
xl Copyright © 2017, Juniper Networks, Inc.

List of Figures
Part 1 Overview
Figure 1: ACX Series Router Packet Forwarding and Data Flow . . . . . . . . . . . . . . . . 4
Figure 2: Routing Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 3: ACX500 Indoor Router Interface Port Mapping—DC and AC Chassis . . . 27
Figure 4: ACX500 Outdoor Router Interface Port Mapping . . . . . . . . . . . . . . . . . . 28
Figure 5: ACX500 Outdoor Router Interface Port Mapping . . . . . . . . . . . . . . . . . . 30
Figure 6: ACX1000 Interface Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 7: ACX1100 Interface Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 8: ACX2000 Interface Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 9: ACX2100 Interface Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Figure 14: Pseudowire Encapsulation with SAToP . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Figure 15: Protocol Packets from the Network to the Router . . . . . . . . . . . . . . . . . 115
Figure 16: Protocol Packets from the Router or Switch to the Network . . . . . . . . . 115
Figure 17: Example of a Three-Node Ring Topology . . . . . . . . . . . . . . . . . . . . . . . 120
Chapter 5 Configuring E1 and T1 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Figure 18: Remote and Local E1 Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Figure 19: Remote and Local T1 Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Chapter 7 Configuring SAToP Support on Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Figure 20: Pseudowire Encapsulation with SAToP . . . . . . . . . . . . . . . . . . . . . . . . . 191
Figure 21: Boundary Clocks in a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Chapter 11 Configuring DHCP and DHCPv6 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . 367
Figure 22: DHCP Clients, Switching Device, and the DHCP Server Are All on the
Same VLAN or Bridge Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Figure 23: Switching Device Acting as an Extended Relay Server . . . . . . . . . . . . 395
Copyright © 2017, Juniper Networks, Inc. xli


Chapter 15 Configuring Internet Group Management Protocol Snooping . . . . . . . . . . 473
Figure 24: Networks Without IGMP Snooping Configured . . . . . . . . . . . . . . . . . . 482
Figure 25: Networks with IGMP Snooping Configured . . . . . . . . . . . . . . . . . . . . . 483
Figure 26: Install Default Route to Nearest Routing Device That Operates at
Both Level 1 and Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Figure 27: OSPF Three-Way Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Figure 28: Example Remote LFA over LDP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . 551
Figure 29: Configuring Remote LFA over LDP Tunnels in IS-IS Networks . . . . . . 569
Figure 30: TTL Processing on Incoming MPLS Packets . . . . . . . . . . . . . . . . . . . . 590
Figure 31: Pseudowire Redundancy Mobile Backhaul Sample Topology . . . . . . . 623
Figure 32: Pseudowire Redundancy Mobile Backhaul Solution . . . . . . . . . . . . . . 625
Figure 33: Pseudowire Redundancy in a Mobile Backhaul Example Topology . . 628
Figure 34: Basic VRRP for IPv4 Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
Chapter 22 Configuring Multicast Listener Discovery and Protocol-Independent
Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Figure 35: Rendezvous Point As Part of the RPT and SPT . . . . . . . . . . . . . . . . . . 678
Figure 36: PCEP Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Figure 37: Example MPLS Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Figure 38: PCC and RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Figure 39: Example PCE for MPLS RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Figure 40: Configuring PCEP for MPLS RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 710
Figure 41: Example PCE-Initated LSP for MPLS RSVP-TE . . . . . . . . . . . . . . . . . . 723
Figure 42: Example PCE-Controlled Point-to-Multipoint LSPs . . . . . . . . . . . . . . 736

Figure 43: Connection Protection Using a Pseudowire Configured through Router
PE3 as the Protection Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Figure 44: Simple Load Balancing Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Figure 45: VPN Attributes and Route Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 815
Figure 46: Overlapping Addresses Among Different VPNs . . . . . . . . . . . . . . . . . . 816
Figure 47: Route Distinguishers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
Figure 48: VRF Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Figure 49: Route Distribution Within a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Figure 50: Distribution of Routes from CE Routers to PE Routers . . . . . . . . . . . . 823
Figure 51: Distribution of Routes Between PE Routers . . . . . . . . . . . . . . . . . . . . . 824
Figure 52: Distribution of Routes from PE Routers to CE Routers . . . . . . . . . . . . 826
Figure 53: Using MPLS LSPs to Tunnel Between PE Routers . . . . . . . . . . . . . . . . 827
xlii Copyright © 2017, Juniper Networks, Inc.

List of Figures
Figure 54: Label Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827

Figure 55: OSPF Sham Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833

Figure 56: How a Classifier Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
Figure 57: Network Traffic and Burst Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Figure 58: Hierarchical Scheduling Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 934
Figure 59: How a Classifier Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950

Series Routers
Figure 60: Scope of the E-LMI Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Figure 61: Relationship Among MEPs, MIPs, and Maintenance Domain Levels . . 1128
Figure 62: Relationship Among Bridges, Maintenance Domains, Maintenance
Associations, and MEPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129
Figure 63: CE Device Multihomed to Two PE Routers . . . . . . . . . . . . . . . . . . . . . 1237
Figure 64: BGP and LDP Signaling for a VPLS Routing Instance . . . . . . . . . . . . 1280
Figure 65: Physical Topology of H-VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283
Figure 66: Logical Topology of H-VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284
Figure 67: Physical Topology of H-VPLS using a Single Mesh Group . . . . . . . . . 1305
Figure 68: Basic H-VPLS With One MTU and Two PE-r Devices . . . . . . . . . . . . . 1311

Figure 69: RFC 2544-Based Benchmarking Test Methodology . . . . . . . . . . . . . 1336
Figure 70: Testing End-to-End Service in Ethernet Loopback Mode . . . . . . . . . 1355
Figure 71: RFC 2544-Based Benchmarking Test for a Layer 3 IPv4 Service . . . . 1360
Figure 72: RFC 2544-Based Benchmarking Test for NNI Direction of an Ethernet
Pseudowire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
Figure 73: RFC 2544-Based Benchmarking Test for UNI Direction of an Ethernet
Pseudowire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1376
Copyright © 2017, Juniper Networks, Inc. xliii

xliv Copyright © 2017, Juniper Networks, Inc.

List of Tables
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . liii
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lv
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lvi
Part 1 Overview
Table 3: Protocols and Applications Supported by ACX Series Routers . . . . . . . . . 6
Table 4: CLI Equivalents of Terms Used in Documentation for ACX500 Indoor
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Table 5: CLI Equivalents of Terms Used in Documentation for ACX500 Outdoor
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Routers with PoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Table 7: CLI Equivalents of Terms Used in Documentation for ACX1000
Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Table 13: CLI Equivalents of Terms Used in Documentation for an ACX5048
Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Table 14: CLI Equivalents of Terms Used in Documentation for an ACX5096
Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Part 2 Installing and Upgrading ACX Series Routers

Chapter 2 Installing and Upgrading Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Table 15: Routing Engines and Storage Media Names (ACX Series, M Series, MX
Series, T Series, TX Matrix, TX Matrix Plus, and JCS 1200 Routers) . . . . . . . . 46

Table 16: Encapsulation Overhead by Encapsulation Type . . . . . . . . . . . . . . . . . . 98
Copyright © 2017, Juniper Networks, Inc. xlv

Table 17: Media MTU Sizes by Interface Type for ACX Series Routers . . . . . . . . . . 99
Table 18: Platform Support for Channelized OC3/STM1 (Multi-Rate) Circuit
Emulation MIC with SFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Table 19: PoE Specifications for the ACX2000 Routers . . . . . . . . . . . . . . . . . . . . 142
Table 20: ACX2000 Universal Access Router PoE Specifications . . . . . . . . . . . . 143
Table 21: PoE Configuration Options and Default Settings . . . . . . . . . . . . . . . . . . 143
Table 22: Components of the PoE Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 145
Table 23: Checklist for Monitoring Fast Ethernet and Gigabit Ethernet
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Table 24: Checklist for Monitoring T1 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Table 25: Hashing Behavior for Pseudowire (Layer 2 Circuit) and Bridging
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Table 26: Hashing Behavior for IP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Table 27: Router Models and Their sysObjectIds for ACX Series Routers . . . . . . . 162
Chapter 6 Configuring ATM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Table 28: IMA Frame Synchronization Link State Transition Variables . . . . . . . . . 176
Table 29: IMA Group Alarms with IMA Standard Requirement Numbers . . . . . . . 177
Table 30: IMA Group Defects with IMA Standard Requirement Numbers . . . . . . 178
Table 31: IMA Link Alarms with IMA Standard Requirement Numbers . . . . . . . . . 178
Table 32: IMA Link Defects with IMA Standard Requirement Numbers . . . . . . . . 179
Table 33: IMA Link Statistics with IMA Standard Requirement Numbers . . . . . . 180
Table 34: SNMP trap notifications for timing defects and events . . . . . . . . . . . . 301
Table 35: SNMP MIB Objects for get, get-next, and walk management . . . . . . . 304

Chapter 10 Configuring DHCP Client and DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Table 36: DHCP Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Table 37: ARP Table in Trusted Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Table 38: ARP Table in Distrusted Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Table 39: Action Taken for Events That Occur During a Reconfiguration . . . . . . 343

Chapter 12 Configuring Layer 2 Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Table 40: LLDP Operational Mode Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Chapter 13 Configuring Layer 2 Protocol Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Table 41: Protocol Destination MAC Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Chapter 14 Configuring Internet Group Management Protocol . . . . . . . . . . . . . . . . . . . 445
Table 42: IGMP Event Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Chapter 17 Configuring MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Table 43: Multilink Bundles Supported by ACX Series Routers . . . . . . . . . . . . . . 508
Table 44: Default Route Preference Values for OSPF . . . . . . . . . . . . . . . . . . . . . 544
xlvi Copyright © 2017, Juniper Networks, Inc.

List of Tables
Table 45: Pseudowire Status Code for the Pseudowire Status TLV . . . . . . . . . . 624
Table 46: Interface State and Priority Cost Usage . . . . . . . . . . . . . . . . . . . . . . . . 661
Table 47: Applicability of MPLS and Existing LSP Configurations to a
PCE-Controlled LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

Chapter 24 Configuring Layer 2 Bridging and Q-in-Q Tunneling . . . . . . . . . . . . . . . . . . . 755
Table 48: Statement Usage and Input Rewrite Operations for VLAN Identifiers
for a Bridge Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Table 49: Statement Usage and Output Rewrite Operations for VLAN Identifiers
for a Bridge Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Table 50: MPLS LSP Load Balancing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Table 51: How a PE Router Redistributes and Advertises Routes . . . . . . . . . . . . 836

Table 52: Policer Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Table 53: Resources for Learning More About HCoS . . . . . . . . . . . . . . . . . . . . . . 935
Table 54: Default IP Precedence (ipprec-compatibility) Classifier . . . . . . . . . . . 954
Table 55: Default IP Precedence (ipprec-default) Classifier . . . . . . . . . . . . . . . . 955
Table 56: Default MPLS Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Table 57: Default IEEE 802.1p Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
Table 58: Default IEEE 802.1ad Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
Table 59: Default DSCP Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958

Series Routers
Chapter 29 Understanding Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Table 60: Standard MIBs supported by Junos OS . . . . . . . . . . . . . . . . . . . . . . . . 967
Table 61: Enterprise-Specific MIBs and Supported Devices . . . . . . . . . . . . . . . . 985
Chapter 30 Configuring IP and MAC Address Validation . . . . . . . . . . . . . . . . . . . . . . . . . 995
Table 62: Comparison of MAC Address Validation Modes . . . . . . . . . . . . . . . . . 996
Chapter 31 Configuring Network Address Translation (NAT) and Stateful Firewall
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Table 63: ALGs Available by Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Table 64: IP Option Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Table 65: Service Filter Match Conditions for IPv4 Traffic . . . . . . . . . . . . . . . . . 1038
Table 66: Terminating Actions for Service Filters . . . . . . . . . . . . . . . . . . . . . . . . 1039
Copyright © 2017, Juniper Networks, Inc. xlvii

Table 67: Nonterminating Actions for Service Filters . . . . . . . . . . . . . . . . . . . . . 1039

Chapter 32 Configuring Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
Table 68: Firewall Filter Match Conditions by Protocol Family . . . . . . . . . . . . . . 1047
Table 69: Firewall Filter Action Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
Table 70: Firewall Filter Behavior by Filter Attachment Point . . . . . . . . . . . . . . . 1049
Table 71: Standard Firewall Filter Match Conditions by Protocol Family for ACX
Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053
Table 72: Standard Firewall Filter Action Categories for ACX Series Routers . . . 1053
Table 73: Standard Firewall Filter Match Conditions for IPv4 Traffic on ACX
Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054
Table 74: Firewall Filter Match Conditions for IPv6 Traffic . . . . . . . . . . . . . . . . . 1058
Table 75: Standard Firewall Filter Match Conditions for MPLS Traffic on ACX
Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
Table 76: Terminating Actions for Standard Firewall Filters on ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
Table 77: Nonterminating Actions for Standard Firewall Filters on ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065
Table 78: CCC Family Firewall Filter Match Conditions for ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068
Table 79: Bridge Family Firewall Filter Match Conditions for ACX Series
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1069
Table 80: Bridge Family Firewall Filter Action Fields for ACX Series Routers . . . 1070
Table 81: Firewall Filter Match Conditions for VPLS Traffic . . . . . . . . . . . . . . . . . 1071
Table 82: Features Using TCAM Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
Table 83: Show and Clear Commands to Monitor and Troubleshoot Dynamic
TCAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
Table 84: Differences in CLI Hierarchy for Layer 2 Features in Layer 2 Next
Generation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
Table 85: Differences in show Commands for Layer 2 Features in Layer 2 Next
Generation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168
Table 86: Unified Forwarding Table Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Table 87: Layer 3 Host Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1170
Table 88: Layer 3 LPM Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1170
Table 89: Managed Objects for Service OAM MIB . . . . . . . . . . . . . . . . . . . . . . . . 1172
Table 90: jnxSoamPmMepTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1173
Table 91: jnxSoamLmCfgTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1174
Table 92: jnxSoamLmMeasuredStatsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
Table 93: jnxSoamLmCurrentStatsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185
Table 94: jnxSoamLmHistoryStatsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189
Table 95: jnxSoamDmCfgTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
Table 96: jnxSoamDmMeasuredStatsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206
Table 97: jnxSoamDmCurrentStatsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207
Table 98: jnxSoamDmHistoryStatsTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
Table 99: jnxSoamLmThresholdCfgTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216
Table 100: jnxSoamDmThresholdCfgTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1220
Table 101: jjnxSoamPmNotificationObj Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226
Table 102: jjnxSoamPmNotifications Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
xlviii Copyright © 2017, Juniper Networks, Inc.

List of Tables

Table 103: Supported Input and Output VLAN Map Configurations . . . . . . . . . 1264
Table 104: Statement Usage and Input Rewrite Operations for VLAN Identifiers
for a VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265
Table 105: Statement Usage and Output Rewrite Operations for VLAN Identifiers
for a VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265

Table 106: Parameters for test-profile Configuration . . . . . . . . . . . . . . . . . . . . . . 1341
Table 107: Parameter for test-name configuration . . . . . . . . . . . . . . . . . . . . . . . 1342
Chapter 40 Troubleshooting ACX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1401
Table 108: CT1 and CE1 Interface Alarms and Error Definitions . . . . . . . . . . . . . . 1401
Table 109: Troubleshooting a PoE Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
Table 110: Commands to Monitor and Troubleshoot TCAM Resource in ACX
Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1403
Part 10 Configuration Statements and Operational Commands on ACX

Series Routers
Chapter 42 Operational Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1781
Table 111: clear dhcp relay statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . 1790
Table 112: monitor ethernet synthetic-loss-measurement Output Fields . . . . . 1798
Table 113: request diagnostics tdr Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 1805
Table 114: show bgp neighbor Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811
Table 115: show bgp replication Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 1829
Table 116: show bgp summary Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 1832
Table 117: show bridge mac-table Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 1840
Table 118: show chassis alarms Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 1852
Table 119: show chassis led Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1864
Table 120: show chassis craft-interface Output Fields . . . . . . . . . . . . . . . . . . . . 1867
Table 121: show chassis environment Output Fields . . . . . . . . . . . . . . . . . . . . . . 1891
Table 122: show chassis environment fpc Output Fields . . . . . . . . . . . . . . . . . . 1960
Table 123: show chassis environment pem Output Fields . . . . . . . . . . . . . . . . . 1997
Table 124: show chassis environment routing-engine Output Fields . . . . . . . . 2009
Table 125: show chassis feb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2013
Table 126: show chassis firmware Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 2020
Table 127: show chassis fpc Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2041
Table 128: show chassis fan Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2080
Table 129: Routing Engines Displaying DIMM Information . . . . . . . . . . . . . . . . . 2096
Table 130: show chassis hardware Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 2101
Table 131: show chassis led Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2317
Table 132: show chassis mac-addresses Output Fields . . . . . . . . . . . . . . . . . . . 2329
Table 133: show chassis pic Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2338
Table 134: show chassis routing-engine Output Fields . . . . . . . . . . . . . . . . . . . . 2361
Table 135: show chassis synchronization Output Fields . . . . . . . . . . . . . . . . . . . 2387
Table 136: show chassis temperature-thresholds Output Fields . . . . . . . . . . . . 2395
Table 137: show class-of-service interface Output Fields . . . . . . . . . . . . . . . . . . 2422
Copyright © 2017, Juniper Networks, Inc. xlix

Table 138: show class-of-service system-defaults Output Fields . . . . . . . . . . . 2450

Table 139: show dhcp relay statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . 2452
Table 140: show dhcp relay binding Output Fields . . . . . . . . . . . . . . . . . . . . . . . 2456
Table 141: show diagnostics tdr Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 2462
Table 142: show filter aggregate policer Output Fields . . . . . . . . . . . . . . . . . . . 2466
Table 143: show filter policer template Output Fields . . . . . . . . . . . . . . . . . . . . 2469
Table 144: ATM show interfaces Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 2472
Table 145: T1 or E1 show interfaces Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 2507
Table 146: Layer 2 Overhead and Transmitted Packets or Byte Counts . . . . . . 2545
Table 147: show interfaces queue Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 2548
Table 148: Byte Count by Interface Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 2552
Table 149: Link Services show interfaces Output Fields . . . . . . . . . . . . . . . . . . . 2587
Table 150: show interfaces Gigabit Ethernet Output Fields . . . . . . . . . . . . . . . 2600
Table 151: Gigabit Ethernet IQ PIC Traffic and MAC Statistics by Interface
Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2614
Table 152: show interfaces (Gigabit Ethernet) Output Fields . . . . . . . . . . . . . . 2625
Table 153: Gigabit Ethernet IQ PIC Traffic and MAC Statistics by Interface
Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2640
Table 154: show interfaces Fast Ethernet Output Fields . . . . . . . . . . . . . . . . . . 2649
Table 155: Aggregated Ethernet show interfaces Output Fields . . . . . . . . . . . . 2666
Table 156: show isis database Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2678
Table 157: show isis hostname Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2691
Table 158: show isis interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2694
Table 159: show isis overview Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2698
Table 160: show isis route Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2703
Table 161: show isis spf Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2707
Table 162: show isis statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2712
Table 163: show l2-learning global-information Output Fields . . . . . . . . . . . . . . 2714
Table 164: show l2-learning instance Output Fields . . . . . . . . . . . . . . . . . . . . . . 2717
Table 165: show l2-learning interfaceOutput Fields . . . . . . . . . . . . . . . . . . . . . . 2719
Table 166: show lacp interfaces Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2721
Table 167: show lacp statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2726
Table 168: show lldp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2730
Table 169: show lldp local-information Output Fields . . . . . . . . . . . . . . . . . . . . 2733
Table 170: show lldp neighbors Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2736
Table 171: show lldp remote-global-statistics Output Fields . . . . . . . . . . . . . . . 2742
Table 172: show lldp statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2744
Table 173: show multicast snooping route Output Fields . . . . . . . . . . . . . . . . . . 2748
Table 174: show multicast snooping next-hops Output Fields . . . . . . . . . . . . . . 2751
Table 175: show igmp snooping interface Output Fields . . . . . . . . . . . . . . . . . . 2754
Table 176: show igmp snooping membership Output Fields . . . . . . . . . . . . . . . 2760
Table 177: show igmp snooping statistics Output Fields . . . . . . . . . . . . . . . . . . 2763
Table 178: show oam ethernet connectivity-fault-management interfaces Output
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2769
Table 179: show oam ethernet connectivity-fault-management delay-statistics
and mep-statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2780
Table 180: show oam ethernet connectivity-fault-management mep-database
Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2792
l Copyright © 2017, Juniper Networks, Inc.

List of Tables
Table 181: show oam ethernet connectivity-fault-management

sla-iterator-statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2803
Table 182: show oam ethernet connectivity-fault-management
synthetic-loss-statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2808
Table 183: show oam ethernet connectivity-fault-management server-mep
Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2810
Table 184: show ospf database Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 2813
Table 185: show ospf3 database Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 2825
Table 186: show (ospf | ospf3) interface Output Fields . . . . . . . . . . . . . . . . . . . 2835
Table 187: show (ospf | ospf3) io-statistics Output Fields . . . . . . . . . . . . . . . . 2840
Table 188: show (ospf | ospf3) log Output Fields . . . . . . . . . . . . . . . . . . . . . . . 2843
Table 189: show (ospf | ospf3) neighbor Output Fields . . . . . . . . . . . . . . . . . . . 2846
Table 190: show ospf overview Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 2853
Table 191: show (ospf | ospf3) route Output Fields . . . . . . . . . . . . . . . . . . . . . . 2858
Table 192: show (ospf | ospf3) statistics Output Fields . . . . . . . . . . . . . . . . . . . 2864
Table 193: show pfe tcam usage Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 2870
Table 194: show pfe tcam usage Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 2878
Table 195: show path-computation-client active-pce Output Fields . . . . . . . . 2884
Table 196: show path-computation-client statistics Output Fields . . . . . . . . . 2888
Table 197: show poe controller Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2893
Table 198: show poe telemetries interface Output Fields . . . . . . . . . . . . . . . . . 2896
Table 199: show ppp interface Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2898
Table 200: show ppp summary Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 2907
Table 201: show ppp statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2909
Table 202: show protection-group ethernet-ring aps Output Fields . . . . . . . . . 2916
Table 203: MX Series Routers show protection-group ethernet-ring interface
Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2920
Table 204: show protection-group ethernet-ring node-state Output Fields . . 2923
Table 205: show protection-group ethernet-ring statistics Output Fields . . . . 2928
Table 206: show protection-group ethernet-ring statistics detail Output Fields
(for MX Series Routers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2929
Table 207: show protection-group ethernet-ring vlan Output Fields . . . . . . . . 2932
Table 208: show ptp clock Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2936
Table 209: show ptp global-information Output Fields . . . . . . . . . . . . . . . . . . 2939
Table 210: show ptp hybrid Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2943
Table 211: show ptp lock-status Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 2945
Table 212: show ptp statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 2948
Table 213: show route Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2952
Table 214: show route advertising-protocol Output Fields . . . . . . . . . . . . . . . . . 2978
Table 215: show route damping Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 2996
Table 216: show route detail Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3000
Table 217: Next-hop Types Output Field Values . . . . . . . . . . . . . . . . . . . . . . . . . 3006
Table 218: State Output Field Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3008
Table 219: Communities Output Field Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 3010
Table 220: show route export Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 3023
Table 221: show route extensive Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 3025
Table 222: show route flow validation Output Fields . . . . . . . . . . . . . . . . . . . . . 3043
Table 223: show route forwarding-table Output Fields . . . . . . . . . . . . . . . . . . . 3048
Table 224: show route instance Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 3072
Copyright © 2017, Juniper Networks, Inc. li

Table 225: show route receive-protocol Output Fields . . . . . . . . . . . . . . . . . . . . 3107

Table 226: show route table Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3116
Table 227: Next-hop Types Output Field Values . . . . . . . . . . . . . . . . . . . . . . . . . 3122
Table 228: State Output Field Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3123
Table 229: Communities Output Field Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 3125
Table 230: show route terse Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3153
Table 231: show services rpm rfc2544-benchmarking Output Fields . . . . . . . . . 3157
Table 232: show services rpm rfc2544-benchmarking test-id Output Fields . . 3162
Table 233: show system autoinstallation status Output Fields . . . . . . . . . . . . . 3179
Table 234: show system storage partitions Output Fields . . . . . . . . . . . . . . . . . 3180
Table 235: show validation database Output Fields . . . . . . . . . . . . . . . . . . . . . . 3183
Table 236: show validation group Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 3184
Table 237: show validation replication database Output Fields . . . . . . . . . . . . . 3187
Table 238: show validation session Output Fields . . . . . . . . . . . . . . . . . . . . . . . 3188
Table 239: show validation statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . 3191
lii Copyright © 2017, Juniper Networks, Inc.

About the Documentation
• Documentation and Release Notes on page liii

• Supported Platforms on page liii
• Using the Examples in This Manual on page liii
• Documentation Conventions on page lv
• Documentation Feedback on page lvii
• Requesting Technical Support on page lvii
Documentation and Release Notes

®
To obtain the most current version of all Juniper Networks technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/.
If the information in the latest release notes differs from the information in the
documentation, follow the product Release Notes.
Juniper Networks Books publishes books by Juniper Networks engineers and subject
matter experts. These books go beyond the technical documentation to explore the
nuances of network architecture, deployment, and administration. The current list can
be viewed at http://www.juniper.net/books.
Supported Platforms
For the features described in this document, the following platforms are supported:
• ACX Series
Using the Examples in This Manual
If you want to use the examples in this manual, you can use the load merge or the load
merge relative command. These commands cause the software to merge the incoming
configuration into the current candidate configuration. The example does not become
active until you commit the candidate configuration.
If the example configuration contains the top level of the hierarchy (or multiple
hierarchies), the example is a full example. In this case, use the load merge command.
Copyright © 2017, Juniper Networks, Inc. liii

If the example configuration does not start at the top level of the hierarchy, the example
is a snippet. In this case, use the load merge relative command. These procedures are
described in the following sections.
Merging a Full Example

To merge a full example, follow these steps:
1. From the HTML or PDF version of the manual, copy a configuration example into a
text file, save the file with a name, and copy the file to a directory on your routing
platform.
For example, copy the following configuration to a file and name the file ex-script.conf.
Copy the ex-script.conf file to the /var/tmp directory on your routing platform.
system {
scripts {
commit {
file ex-script.xsl;
}
}
}
interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
}
2. Merge the contents of the file into your routing platform configuration by issuing the
load merge configuration mode command:
[edit]
user@host# load merge /var/tmp/ex-script.conf
load complete
Merging a Snippet
To merge a snippet, follow these steps:
1. From the HTML or PDF version of the manual, copy a configuration snippet into a text
file, save the file with a name, and copy the file to a directory on your routing platform.
For example, copy the following snippet to a file and name the file
ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory
on your routing platform.
commit {
file ex-script-snippet.xsl; }
liv Copyright © 2017, Juniper Networks, Inc.

2. Move to the hierarchy level that is relevant for this snippet by issuing the following
configuration mode command:
[edit]
user@host# edit system scripts
[edit system scripts]
3. Merge the contents of the file into your routing platform configuration by issuing the
load merge relative configuration mode command:
[edit system scripts]

user@host# load merge relative /var/tmp/ex-script-snippet.conf
load complete
For more information about the load command, see CLI Explorer.
Documentation Conventions
Table 1 on page lv defines notice icons used in this guide.
Table 1: Notice Icons

Icon Meaning Description
Informational note Indicates important features or instructions.
Caution Indicates a situation that might result in loss of data or hardware damage.
Warning Alerts you to the risk of personal injury or death.
Laser warning Alerts you to the risk of personal injury from a laser.
Tip Indicates helpful information.
Best practice Alerts you to a recommended use or implementation.
Table 2 on page lvi defines the text and syntax conventions used in this guide.
Copyright © 2017, Juniper Networks, Inc. lv

Table 2: Text and Syntax Conventions

Convention Description Examples
Bold text like this Represents text that you type. To enter configuration mode, type the
configure command:
user@host> configure
Fixed-width text like this Represents output that appears on the user@host> show chassis alarms
terminal screen.
No alarms currently active
Italic text like this • Introduces or emphasizes important • A policy term is a named structure
new terms. that defines match conditions and
• Identifies guide names. actions.
• • Junos OS CLI User Guide

Identifies RFC and Internet draft titles.
• RFC 1997, BGP Communities Attribute
Italic text like this Represents variables (options for which Configure the machine’s domain name:
you substitute a value) in commands or
configuration statements. [edit]
root@# set system domain-name
domain-name
Text like this Represents names of configuration • To configure a stub area, include the
statements, commands, files, and stub statement at the [edit protocols
directories; configuration hierarchy levels; ospf area area-id] hierarchy level.
or labels on routing platform • The console port is labeled CONSOLE.
components.
< > (angle brackets) Encloses optional keywords or variables. stub <default-metric metric>;
| (pipe symbol) Indicates a choice between the mutually broadcast | multicast

exclusive keywords or variables on either
side of the symbol. The set of choices is (string1 | string2 | string3)
often enclosed in parentheses for clarity.
# (pound sign) Indicates a comment specified on the rsvp { # Required for dynamic MPLS only
same line as the configuration statement
to which it applies.
[ ] (square brackets) Encloses a variable for which you can community name members [
substitute one or more values. community-ids ]
Indention and braces ( { } ) Identifies a level in the configuration [edit]

hierarchy. routing-options {
static {
route default {
; (semicolon) Identifies a leaf statement at a
nexthop address;
configuration hierarchy level.
retain;
}
}
}
GUI Conventions
lvi Copyright © 2017, Juniper Networks, Inc.

Table 2: Text and Syntax Conventions (continued)

Convention Description Examples
Bold text like this Represents graphical user interface (GUI) • In the Logical Interfaces box, select
items you click or select. All Interfaces.
• To cancel the configuration, click
Cancel.
> (bold right angle bracket) Separates levels in a hierarchy of menu In the configuration editor hierarchy,
selections. select Protocols>Ospf.
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 Partner Support Service
support contract, or are covered under warranty, and need post-sales technical support,
you can access our tools and resources online or open a case with JTAC.
• JTAC policies—For a complete understanding of our JTAC procedures and policies,

review the JTAC User Guide located at
http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.
• 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:
Copyright © 2017, Juniper Networks, Inc. lvii

• 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: 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, see

http://www.juniper.net/support/requesting-support.html.
lviii Copyright © 2017, Juniper Networks, Inc.

PART 1
Overview
• ACX Series Universal Access Router Overview on page 3
Copyright © 2017, Juniper Networks, Inc. 1

2 Copyright © 2017, Juniper Networks, Inc.

CHAPTER 1
ACX Series Universal Access Router

Overview

• Protocols and Applications Supported by ACX Series Routers on page 5
• Hardware Architecture Overview on page 21
• Hardware Overview (ACX Series, M Series, MX Series, T Series, and TX Matrix
Routers) on page 22
• ACX500 Routers Hardware and CLI Terminology Mapping on page 25
• ACX1000 and ACX1100 Routers Hardware and CLI Terminology Mapping on page 30
ACX Series Universal Access Router Overview
The ACX Series Universal Access Router is principally designed to provide superior
management for rapid provisioning to the access network. The ACX Series routers support
rich Gigabit Ethernet and 10-Gigabit Ethernet capabilities for uplink, along with support
for legacy interfaces and Gigabit Ethernet interfaces for radio and NodeB connectivity in
a compact form factor that is environmentally hardened and passively cooled. Seamless,
end-to-end MPLS can be used to address legacy and emerging requirements to provide
the foundation for a converged network that utilizes the same mobile backhaul
infrastructure for business or residential services.
• ACX Series Router Architecture on page 4

• Junos OS on page 4
• Interfaces on page 4
• Mobile Backhaul on page 4
• Junos Space on page 5

ACX Series Router Architecture

The ACX Series router is a single-board router with a built-in Routing Engine and one
Packet Forwarding Engine that has two “pseudo” Flexible PIC Concentrators (FPC 0 and
FPC 1). Because there is no switching fabric, the single Packet Forwarding Engine takes
care of both ingress and egress packet forwarding.
• Routing Engine—Provides Layer 3 routing services and network management.
• Packet Forwarding Engine—Performs Layer 2 and Layer 3 packet switching, route

lookups, and packet forwarding.
The general architecture for ACX Series routers is shown in Figure 1 on page 4.
Figure 1: ACX Series Router Packet Forwarding and Data Flow

Ingress classification
In order of
decreasing precedence:
Incoming packet MF classification (DFW) Outgoing packet
Fixed classification Buffering Queuing Scheduling Egress rewrite
g006408
BA classification
Junos OS
The ACX Series router is powered by Junos OS, supporting extensive L2 and L3 features,
IP/MPLS with traffic engineering, rich network management, fault management, service
monitoring and Operation, Administration, and Maintenance (OAM) capabilities, and an
open software development kit (SDK) system that allows providers to customize and
integrate operations with their own management systems. For a list of related Junos OS
documentation, see http://www.juniper.net/techpubs/software/junos/
As part of the mobile backhaul, the ACX Series router at the cell site and the MX Series
router at the aggregation layer provide comprehensive end-to-end Ethernet, MPLS, and
OAM features with the one Junos OS running on both platforms.
Interfaces
The ACX Series routers support time-division multiplexing (TDM) T1 and E1 interfaces
and Gigabit Ethernet (10GbE, 100GbE, 1000GbE copper, and 1GbE and 10GbE fiber)
interfaces to support both the legacy and evolution needs of the mobile network. Support
for Power over Ethernet Plus (PoE+) at 65 watts per port mitigates the need for additional
electrical cabling for microwaves or other access interfaces.
Mobile Backhaul
In the mobile backhaul scenario, the ACX Series router is primarily used in the access
layer as the cell site router and the MX Series router is used as the edge and aggregation
router. As the cell site router, the ACX Series router connects the base station (BS) to
the packet network. Several cell site routers can be connected in a ring or hub-and-spoke
fashion to the upstream preaggregation and aggregation routers (MX Series routers).

Chapter 1: ACX Series Universal Access Router Overview
The ACX Series router meets and often exceeds the key requirements for a cell site router.
A one-rack unit (U) tall router, the ACX Series router is compliant with the European
Telecommunications Standardization Institute (ETSI) 300, as well as environmentally
hardened and passively cooled for easy deployment where space and cooling are limited
as at the cell site.
Timing and synchronization are key elements in cell site router deployment. To deliver
the highest quality of experience, the ACX Series router supports multiple high-precision
timing options—for example, Synchronous Ethernet, 1588v2, and Precision Time Protocol
(PTP).
NOTE: ACX Series routers cannot be used as a first hop router.
Junos Space
Junos Space is a suite of comprehensive Web-based tools for operational management
and administration of Juniper Networks routers, including the ACX Series and MX Series
platforms. With the unified Junos Space network management system, network
provisioning and operations can be streamlined. Juniper Networks has extended Junos
Space with powerful new features designed to address the demanding requirements of
mobile backhaul.
Related • ACX2000 and ACX2100 Routers Hardware and CLI Terminology Mapping on page 33
Documentation
• Understanding Interfaces on ACX Series Universal Access Routers on page 94
• Protocols and Applications Supported by ACX Series Routers on page 5
Protocols and Applications Supported by ACX Series Routers
Table 3 on page 6 contains the first Junos OS Release support for protocols and
applications on ACX Series routers. A dash indicates that the protocol or application is
not supported.
NOTE:
• The [edit logical-systems logical-system-name] hierarchy level is not
supported on ACX Series routers.
• The ACX Series routers does not support per-family maximum transmission
unit (MTU) configuration. The MTU applied to family inet gets applied to
other families as well, even though it can be configured though CLI and
visible in show interface extensive output. The only way to use higher MTU
for a family is to manipulate the MTU, apply at interface or family inet levels,
and let it calculate for each family automatically. For more information,
see the Knowledge Base (KB) article KB28179 at:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB28179.

Table 3: Protocols and Applications Supported by ACX Series Routers

Protocol or Application ACX1000 ACX1100 ACX2000 ACX2100 ACX4000 ACX5048 ACX5096 ACX500
Interface and Encapsulation Types

Ethernet interfaces—1G, 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
10G -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Ethernet interfaces—40G – – – – – 15.1X54 15.1X54 –

–D20 –D20
ATM interfaces (IMA only) 12.2 – 12.2 12.2R2 – – – –
E1 interfaces 12.2 – 12.2 12.2R2 – – – –
T1 interfaces 12.2 – 12.2 12.2R2 – – – –
Circuit emulation interfaces 12.2 – 12.2 12.2R2 12.3x51 – – –

(SAToP, CESoP) -D10
SONET/SDH interfaces – – – – 12.3x51 – – –

-D10
(requires
a MIC)
Layer 3
Static routes 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
OSPF 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
IS-IS 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)

Table 3: Protocols and Applications Supported by ACX Series Routers (continued)

BGP 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Internet Control Message 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
Protocol (ICMP) -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Address Resolution 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
Protocol (ARP) -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Bidirectional Forwarding 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
Detection (BFD) protocol -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Dynamic Host 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
Configuration Protocol -D10 –D20 –D20 –D20
(DHCP) (Indoor)
12.3X54
–D25
(Outdoor)
IP fast reroute (FRR) 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
(OSPF, IS-IS) -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Maximum transmission unit 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
(MTU) 1518 -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


Layer 3 VPNs 12.3R1 12.3R1 12.3R1 12.3R1 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
RSVP 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
LDP (targeted and direct) 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
MPLS, VPLS, VPNs

Static label-switched path 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
(LSP) -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
FRR 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Traffic engineering 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


E-LINE 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Pseudowire Emulation 12.2 – 12.2 12.2R2 12.3x51 15.1X54 15.1X54 –

Edge to Edge (PWE3 -D10 –D20 –D20
[signaled])
Static Ethernet PWs 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Layer 2 circuits 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
IEE802.1ag CC monitoring 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
on active and standby -D10 –D20 –D20 –D20
pseudowires (Indoor)
12.3X54
–D25
(Outdoor)
VPLS – – – – – 15.1X54 15.1X54 –

–D20 –D20
Ethernet Layer 2
Ethernet in the first mile 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
(EFM 802.3ah) -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


802.1ag connectivity fault 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
management (CFM) -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
IEE802.1ag interface-status 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
type, length, and value -D10 –D20 –D20 –D20
(TLV) (Indoor)
12.3X54
–D25
(Outdoor)
QoS
“Firewall filters (access 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
control -D10 –D20 –D20 –D20
lists—ACLs)—family inet” (Indoor)
on page 1054
12.3X54
–D25
(Outdoor)
“Standard firewall filter 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
match conditions for MPLS -D10 –D20 –D20 –D20
traffic” on page 1062 (Indoor)
12.3X54
–D25
(Outdoor)
Firewall filters—family 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
ccc/any -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Policing—per logical 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
interface -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


Policing—per physical 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
interface -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Policing—per family 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
TrTCM (color aware, color 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
blind) -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
SrTCM (color aware, color 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
blind) -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Host protection 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Eight queues per port 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Priority queuing 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


Rate control 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Scheduling with two 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
different priorities -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Low-latency queue (LLQ) 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Weighted random early 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
detection (WRED) drop -D10 –D20 –D20 –D20
profile (DP) (Indoor)
12.3X54
–D25
(Outdoor)
Classification—DSCP 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Classification—MPLS EXP 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Classification—IEEE 802.1p 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


Rewrite—DSCP 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Rewrite MPLS EXP 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Rewrite 802.1p 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Rewrite MPLS and DSCP to 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
different values -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Timing
Timing-1588-v2, 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54
1588-2008–backup clock -D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Synchronous Ethernet 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

-D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


Building-integrated timing 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

supply (BITS) -D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Clock synchronization 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

-D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Redundant clock (multiple – – – – – – – –

1588 masters)
Transparent clock – – – – – 15.1X54 15.1X54 –

–D20 –D20
Grand Master Clock – – – – – – – 12.3X54

–D20
and
17.3R1
(Indoor)
12.3X54
–D25
(Outdoor)
OAM, Troubleshooting, Manageability, Lawful Intercept

Network Time Protocol 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
(NTP) -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
SNMP 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


802.1ag CFM 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
802.3ah LFM 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Y.1731 Fault and 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
Performance Management -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
MPLS OAM 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
RMON 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Layer 2 traceroute 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
DNS 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


TFTP for software 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
downloads -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Port mirroring (local port 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54
mirroring) -D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Interface loopback 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Ethernet loopback 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

-D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Interface byte and packet 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
stats -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Interface queue stats 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Drop packet stats 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


Distinguish each 802.1ag 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
connection by VLAN-ID -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Interface 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

passive-monitor-mode -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Multipacket mirror – – – – – – – 12.3X54

–D20
(Indoor)
12.3X54
–D25
(Outdoor)
Security
TACACS AAA 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
RADIUS authentication 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Control plane DOS 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
prevention -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
High Availability


MPLS FRR 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
BFD 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54

-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
ATM Transport
ATM over PWE3 12.2 – 12.2 12.2R2 12.3x51 – – –
-D10
RFC4717 ATM 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

encapsulation: S6.1 ATM N -D10 –D20
to one cell mode (required (Indoor)
as per standard)
12.3X54
–D25
(Outdoor)
RFC4717: S6.3—ATM AAL5 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

SDU encapsulation -D10 –D20
(optional) (Indoor)
12.3X54
–D25
(Outdoor)
ATM PWE3 control word 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54
-D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
ATM PWE3 by means of 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

dynamic labels -D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)


ATM VPI/VCI swapping 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

-D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
ATM idle/unassigned cell 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

suppression -D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
ATM support for N to 1 PW 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

promiscuous mode: 1 PW -D10 –D20
per port and 1 PW per VPI (Indoor)
12.3X54
–D25
(Outdoor)
Cell concatenation (1 to 30 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

cells per packet) -D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Packet/byte counters per 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

VP and VC -D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Inverse multiplexing over 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

ATM (IMA) -D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
ATM Encapsulation


AAL5 SDU (n-to-1 cell 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54
relay) -D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
ATM Queuing
ATM service categories 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54
(CBR, nrt-VBR, UBR) to the -D10 –D20
UNI (Indoor)
12.3X54
–D25
(Outdoor)
MAP ATM service 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

categories to PW EXP bits -D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Input policing per VC 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

-D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
VC output shaping 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

-D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Early packet discard 12.2 12.2R2 12.2 12.2R2 12.3x51 – – 12.3X54

-D10 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
MIBs


Standard SNMP MIBs 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
-D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Juniper Networks 12.2 12.2R2 12.2 12.2R2 12.3x51 15.1X54 15.1X54 12.3X54
enterprise-specific MIBs -D10 –D20 –D20 –D20
(Indoor)
12.3X54
–D25
(Outdoor)
Related • ACX Series Universal Access Routers

Documentation
Hardware Architecture Overview
Juniper Networks routing platforms are made up of two basic routing components:
• Routing Engine—The Routing Engine controls the routing updates and system
management.
• Packet Forwarding Engine (PFE)—The Packet Forwarding Engine performs Layer 2

and Layer 3 packet switching, route lookups, and packet forwarding.
From a system administration perspective, you install the software onto the Routing
Engine and during the installation, the appropriate software is forwarded to other
components as necessary. Most Routing Engines include a CompactFlash card that
stores Junos OS. On M Series Multiservice Edge Routers; MX240, MX480, and MX960
3D Universal Edge Routers; T Series Core Routers; and TX Matrix routers, the system also
includes a hard disk or solid-state drive (SSD) that acts as a backup boot drive. PTX
Series Packet Transport Routers and the TX Matrix Plus router include a solid-state drive
as a backup boot drive.
NOTE: The MX80 router is a single-board router with a built-in Routing Engine
and single Packet Forwarding Engine. On an MX80 router, Junos OS is stored
on dual, internal NAND flash devices. These devices provide the same
functionality as a CompactFlash card and hard disk or solid-state drive (SSD).

NOTE: The ACX Series router is a single board router with a built-in Routing
Engine and one Packet Forwarding Engine. The ACX router supports dual-root
partitioning, which means that the primary and backup Junos OS images are
kept in two independently bootable root partitions. If the primary partition
becomes corrupted, the system remains fully functional by booting from the
backup Junos OS image located in the other root partition.
On routing platforms with dual Routing Engines, each Routing Engine is independent
with regard to upgrading the software. To install new software on both Routing Engines,
you need to install the new software on each Routing Engine. On platforms with dual
Routing Engines configured for high availability, you can use the unified in-service software
upgrade procedure to upgrade the software. For more information about this procedure,
see the High Availability Feature Guide for Routing Devices.
Related • Dual-Root Partitioning ACX Series Routers Overview on page 48

Documentation
Hardware Overview (ACX Series, M Series, MX Series, T Series, and TX Matrix Routers)
Figure 2 on page 23 shows examples of Routing Engines.

Figure 2: Routing Engines
The ACX Series, M Series, MX Series, PTX Series, T Series, TX Matrix, and TX Matrix Plus
routers include the following:
• System Memory on page 23

• Storage Media on page 24
System Memory
Starting with Junos OS Release 9.0, all routing platforms require a minimum of 512 MB
of system memory on each Routing Engine. All M7i and M10i routers delivered before
December 7, 2007, had 256 MB of memory. These routers require a system memory
upgrade before you install Junos OS Release 9.0 or a later release. To determine the
amount of memory currently installed on your system, use the show chassis routing-engine
command in the command-line interface (CLI).

For more information about upgrading your M7i or M10i router, see the Customer Support
Center JTAC Technical Bulletin PSN-2007-10-001:
https://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2007-10-001&actionBtn=Search.
ACX2000 routers are shipped with 2 GB of memory and ACX1000 routers with 1 GB of
memory.
Storage Media
Except for the ACX Series, MX80 routers, and MX104 routers, the M Series, MX Series,
PTX Series, T Series, TX Matrix, and TX Matrix Plus routers use the following media
storage devices:
• CompactFlash card—The CompactFlash card is typically the primary storage device

for most routers.
NOTE: M7i and M10i routers using RE-400 are not delivered from the factory
with the CompactFlash card installed. In this case, the hard disk is the
primary and only boot device. The M7i and M10i routers with RE-400 can
be upgraded to include the CompactFlash card.
• Hard disk or solid -state drive—For most routers, a hard disk or solid-state drive is the
secondary boot device. When the CompactFlash card is not installed on the router,
the hard disk or the solid-state drive becomes the primary boot device. The hard disk
or solid-state drive is also used to store system log files and diagnostic dump files.
• Emergency boot device—Depending on the router, the emergency boot device can be
a PC card, a USB storage device, or an LS-120 floppy disk.
On MX80 routers, the internal NAND flash devices (first da0, then da1) act as the primary
and secondary boot devices.
On ACX Series routers, the internal NAND flash devices (first da0s1, then da0s2) act as
the primary and secondary boot devices.
Emergency boot devices can be used to revive a routing platform that has a damaged
Junos OS. When an emergency boot device is attached to the router, the router attempts
to boot from that device before it boots from the CompactFlash card, solid-state drive
(SSD), or hard disk.
On an ACX Series router, the emergency boot device is a USB storage device.
On MX104 routers, the internal NAND flash device (da0) mounted on the internal eUSB
card acts as the primary boot and storage device. On MX104 routers, the emergency boot
device is a USB storage device that is plugged into one of the USB ports in the front plate.
When booting from an emergency boot device, the router requests a boot
acknowledgment on the console interface. If you enter yes, the emergency boot device
repartitions the primary boot device and reloads Junos OS onto the primary boot device.
After the loading is complete, the routing platform requests that you remove the

emergency boot device and reboot the system. After the reboot is complete, you must
perform an initial configuration of the router before it can be used on your network.
NOTE: For routers with RE-MX-X6, RE-MX-X8, and RE-PTX-X8 Routing

Engines, a set of two 64-GB SSDs are available for storage and redundancy.
For more information see Storage Partitioning and Redundancy topic in
Salient Features of the RE-MX-X6, RE-MX-X8, and RE-PTX-X8 Routing Engines
section.
ACX500 Routers Hardware and CLI Terminology Mapping
• ACX500 Indoor Routers Hardware and CLI Terminology Mapping on page 25

• ACX500 Outdoor Routers Hardware and CLI Terminology Mapping on page 27
• ACX500 Outdoor Routers with PoE Hardware and CLI Terminology Mapping on page 28
ACX500 Indoor Routers Hardware and CLI Terminology Mapping

Table 4 on page 25 describes the hardware terms used in ACX500 indoor router
documentation and the corresponding terms used in the Junos OS CLI. Figure 3 on page 27
shows the port locations of the interfaces.
Table 4: CLI Equivalents of Terms Used in Documentation for ACX500 Indoor Routers
Hardware
Item (as
Displayed Description (as Value (as Displayed
in the CLI) Displayed in the CLI) in the CLI) Item in Documentation Additional Information
Chassis ACX500 – Router chassis Chassis Physical

Specifications for ACX500
Routers
FPC (n) Abbreviated name of the Value of n is always 0. The router does not have Interface Naming
Flexible PIC Concentrator actual FPCs. In this case, Conventions Used in the
(FPC) FPC refers to the router Junos OS Operational
itself. Commands
PIC (n) Abbreviated name of the n is a value in the range The router does not have Interface Naming
Physical Interface Card of 0–1. actual PIC devices; see Conventions Used in the
(PIC) entries for PIC 0 through Junos OS Operational
PIC 1 for the equivalent Commands
item on the router.
2x 1GE (SFP) PIC 0 Built-in uplink ports on ACX500 Universal Access

the front panel of the Router Overview
router

Table 4: CLI Equivalents of Terms Used in Documentation for ACX500 Indoor

Routers (continued)
Hardware
Item (as
Displayed Description (as Value (as Displayed
in the CLI) Displayed in the CLI) in the CLI) Item in Documentation Additional Information
One of the following PIC 1 Built-in uplink ports on ACX500 Universal Access
(COMBO PIC): the front panel of the Router Overview
router
• 4x 1GE (RJ-45 with PoE+
support)
• 4x 1GE (SFP)
Xcvr (n) Abbreviated name of the n is a value equivalent Optical transceivers Uplink Ports on ACX500
transceiver to the number of the Routers
port in which the
transceiver is installed.
Power Built-in power supply Value of n is always 0. DC power supply ACX500 Power Overview
supply (n)
Fan Fan ACX500 Universal

Access Router Overview
NOTE: ACX500 routers
are fanless models.
Xcvr (n) Abbreviated name of the n is a value equivalent Optical transceivers Uplink Ports on ACX500
transceiver to the number of the Routers
port in which the
Power Built-in power supply Value of n is always 0. DC power supply ACX500 Power Overview
supply (n)
Fan Fan – Fan Cooling System and Airflow

in ACX500 Routers
are fanless.

Figure 3: ACX500 Indoor Router Interface Port Mapping—DC and AC

Chassis
ACX500-DC
1 2
POWER MGMT TOD CONSOLE GE
g000699
0/0/0 0/0/1 0/1/0 0/1/1 0/1/2 0/1/3
GPS ANTENNA
IN OUT ALARM GPS 1PPS 0/1/0 PoE++ 0/1/1 PoE+ 0/1/2 PoE+ 0/1/3
SYS
COMBO
1 2 3
1— FPC 0, PIC 0: 0/0/0–0/0/1 (2x1GE SFP) 3— FPC 0, PIC 1: 0/1/0 PoE++, 0/1/1 PoE+,
0/1/2 PoE+, and 0/1/3 (4x1GE RJ-45)
2—FPC 0, PIC 1: 0/1/0–0/1/3 (4x1GE SFP)
ACX500 Outdoor Routers Hardware and CLI Terminology Mapping

Table 5 on page 27 describes the hardware terms used in ACX500 outdoor router
documentation and the corresponding terms used in the Junos OS CLI. Figure 4 on page 28
shows the port locations of the interfaces.
Table 5: CLI Equivalents of Terms Used in Documentation for ACX500 Outdoor Routers
Hardware
Item (as Value (as
Displayed Description (as Displayed in the
in the CLI) Displayed in the CLI) CLI) Item in Documentation Additional Information
Chassis ACX500 – Router chassis Chassis Physical Specifications

for ACX500 Routers
FPC (n) Abbreviated name of Value of n is always The router does not have Interface Naming Conventions
the Flexible PIC 0. actual FPCs. In this case, Used in the Junos OS
Concentrator (FPC) FPC refers to the router Operational Commands
itself.
PIC (n) Abbreviated name of n is a value in the The router does not have Interface Naming Conventions
the Physical Interface range of 0–1. actual PIC devices; see Used in the Junos OS
Card (PIC) entries for PIC 0 through PIC Operational Commands
1 for the equivalent item on
the router.
3x 1GE (SFP) PIC 0 Built-in uplink ports on the ACX500 Universal Access
front panel of the router Router Overview
3x 1GE (RJ-45) PIC 1 Built-in uplink ports on the ACX500 Universal Access


Routers (continued)
Hardware
Item (as Value (as
Xcvr (n) Abbreviated name of n is a value Optical transceivers Uplink Ports on ACX500
the transceiver equivalent to the Routers
number of the port
in which the
transceiver is
installed.
Power Built-in power supply Value of n is always DC power supply ACX500 Power Overview
supply (n) 0.
Fan Fan – Fan Cooling System and Airflow in

ACX500 Routers
are fanless.
Figure 4: ACX500 Outdoor Router Interface Port Mapping
1— GPS LED 3— FPC 0, PIC 1: 0/1/0–0/1/2 (3x1GE RJ-45)
2—FPC 0, PIC 0: 0/0/0–0/0/2 (3x1GE SFP)
ACX500 Outdoor Routers with PoE Hardware and CLI Terminology Mapping
Table 6 on page 29 describes the hardware terms used in ACX500 outdoor router with
PoE documentation and the corresponding terms used in the Junos OS CLI.
Figure 5 on page 30 shows the port locations of the interfaces.

Table 6: CLI Equivalents of Terms Used in Documentation for ACX500 Outdoor Routers with
PoE
Hardware
Item (as Value (as

Specifications for ACX500
Routers
FPC (n) Abbreviated name of the Value of n is always The router does not have Interface Naming Conventions
Flexible PIC Concentrator 0. actual FPCs. In this case, Used in the Junos OS
(FPC) FPC refers to the router Operational Commands
itself.
PIC (n) Abbreviated name of the n is a value in the The router does not have Interface Naming Conventions
Physical Interface Card range of 0–1. actual PIC devices; see Used in the Junos OS
(PIC) entries for PIC 0 through PIC Operational Commands
the router.
3x 1GE (SFP) PIC 0 Built-in uplink ports on the ACX500 Universal Access
3x 1GE (RJ-45 with PoE+ PIC 1 Built-in uplink ports on the ACX500 Universal Access
support) front panel of the router Router Overview
Xcvr (n) Abbreviated name of the n is a value Optical transceivers Uplink Ports on ACX500
transceiver equivalent to the Routers
number of the port
in which the
transceiver is
installed.
Power Built-in power supply Value of n is always DC power supply ACX500 Power Overview
supply (n) 0.

ACX500 Routers
are fanless.

Figure 5: ACX500 Outdoor Router Interface Port Mapping
1— GPS LED 3— FPC 0, PIC 1: 0/1/0–0/1/2 (3x1GE RJ-45

with PoE+ support)
2—FPC 0, PIC 0: 0/0/0–0/0/2 (3x1GE SFP)
Related • ACX500 Universal Access Router Overview

Documentation
• ACX500 Router Models
ACX1000 and ACX1100 Routers Hardware and CLI Terminology Mapping

Table 7 on page 30 describes the hardware terms used in ACX1000 router documentation
and the corresponding terms used in the Junos OS command line interface (CLI).
Table 7: CLI Equivalents of Terms Used in Documentation for ACX1000 Router

Hardware
Item (as Value (as
displayed Description (as displayed in the
in the CLI) displayed in the CLI) CLI) Item in Documentation Additional Information

for ACX1000 and ACX1100
Routers
FPC (n) Abbreviated name of Value of n is The router does not have Interface Naming Conventions
the Flexible PIC always 0. actual FPCs. In this case, Used in the Junos OS Operational
Concentrator (FPC) FPC refers to the router Commands
itself.

Table 7: CLI Equivalents of Terms Used in Documentation for ACX1000 Router (continued)
Hardware
Item (as Value (as
the Physical Interface range of 0–2. actual PIC devices; see Used in the Junos OS Operational
Card (PIC) entries for PIC 0 through PIC Commands
the router.
8x T1/E1 (RJ-48) PIC 0 Built-in network ports on the ACX1000 and ACX1100 Universal
front panel of the router Access Router Overview
8x 1GE (RJ-45) PIC 1 Built-in uplink ports on the ACX1000 and ACX1100 Universal
One of the following: PIC 2 Built-in uplink ports on the ACX1000 and ACX1100 Universal
• 4x 1GE (RJ-45)
• 4x 1GE (SFP)
Xcvr (n) Abbreviated name of n is a value Optical transceivers Uplink Ports on ACX1000 and
the transceiver equivalent to the ACX1100 Routers
number of the port
in which the
transceiver is
installed.
Power Built-in power supply Value of n is DC power supply ACX1000 and ACX1100 Power
supply (n) always 0. Overview
Fan Fan – Fan Cooling System and Airflow in an

ACX1000 and ACX1100 Router
Figure 6: ACX1000 Interface Port Mapping

FPC 0, PIC 0 FPC 0, PIC 2
T1/E1 0/0/0-0/0/7 GE 0/2/0-0/2/3
T1/E1 GE GE COMBO
ACX1000 0/0/4 0/0/5 0/0/6 0/0/7 0/1/4 0/1/5 0/1/6 0/1/7 0/2/2 (Cu) 0/2/3 (Cu)
MGMT
g006413
ALARM
CONSOLE/AUX
GE COMBO
1PPS 10MHz
IN OUT IN OUT
SYS 0 0/0/0 0/0/1 0/0/2 0/0/3 0/1/0 0/1/1 0/1/2 0/1/3 0/2/0 (Cu) 0/2/1 (Cu)
0/2/0 (SFP) 0/2/1 (SFP) 0/2/2 (SFP) 0/2/3 (SFP)

GE 0/1/0-0/1/7 GE 0/2/0-0/2/3


Table 8: CLI Equivalents of Terms Used in Documentation for ACX1100 Routers

Hardware
Item (as Value (as

Routers
FPC (n) Abbreviated name of the Value of n is always The router does not have Interface Naming Conventions
Flexible PIC Concentrator 0. actual FPCs. In this case, Used in the Junos OS
(FPC) FPC refers to the router Operational Commands
itself.
Physical Interface Card range of 0–1. actual PIC devices; see Used in the Junos OS
(PIC) entries for PIC 0 through Operational Commands
PIC 2 for the equivalent
item on the router.
8x 1GE (RJ-45) PIC 0 Built-in uplink ports on the ACX1000 and ACX1100
front panel of the router Universal Access Router
Overview
One of the following: PIC 1 Built-in uplink ports on the ACX1000 and ACX1100
front panel of the router Universal Access Router
• 4x 1GE (RJ-45) Overview
• 4x 1GE (SFP)
Xcvr (n) Abbreviated name of the n is a value Optical transceivers Uplink Ports on ACX1000 and
transceiver equivalent to the ACX1100 Routers
number of the port
in which the
transceiver is
installed.
Power Built-in power supply Value of n is always AC or DC power supply ACX1000 and ACX1100 Power
supply (n) 0. Overview

an ACX1000 and ACX1100
NOTE: ACX1100 routers Router
are fanless models.


GE 0/0/0-0/0/7 GE 0/1/0-0/1/3
GE
0/0/4 0/0/5 0/0/6 0/0/7 0/1/2 0/1/3
g017874
CONSOLE/AUX
0/0/0 0/0/1 0/0/2 0/0/3 0/1/0 0/1/1

COMBO PORTS 0/1/0 0/1/1 0/1/2 0/1/3
Related • ACX1000 and ACX1100 Universal Access Router Overview

Documentation
• ACX2000 Hardware and CLI Terminology Mapping on page 33

• ACX2100 Hardware and CLI Terminology Mapping on page 35
ACX2000 Hardware and CLI Terminology Mapping


Hardware
Item (as Value (as

Routers
FPC (n) Abbreviated name of the Value of n is The router does not have Interface Naming Conventions
Flexible PIC always 0. actual FPCs. In this case, FPC Used in the Junos OS Operational
Concentrator (FPC) refers to the router itself. Commands

Table 9: CLI Equivalents of Terms Used in Documentation for ACX2000 Routers (continued)
Hardware
Item (as Value (as
Physical Interface Card range of 0–3. actual PIC devices; see Used in the Junos OS Operational
(PIC) entries for PIC 0 through PIC Commands
the router.
16x T1/E1 (RJ-48) PIC 0 Built-in network ports on the ACX2000 and ACX2100 Universal
One of the following: PIC 1 Built-in network ports on the ACX2000 and ACX2100 Universal
• 6x 1GE (RJ-45)
• 2x 1GE (POE RJ-45)
2x 1GE (SFP) PIC 2 Built-in uplink ports on the ACX2000 and ACX2100 Universal
2x 10GE (SFP+) PIC 3 Built-in uplink ports on the ACX2000 and ACX2100 Universal
Xcvr (n) Abbreviated name of the n is a value Optical transceivers Uplink Ports on ACX2000 and
transceiver equivalent to the ACX2100 Routers
number of the
port in which the
transceiver is
installed.
Power Built-in power supply Value of n is DC power supply ACX2000 and ACX2100 Power
supply (n) always 0. Overview

are fanless models.

T1/E1 0/0/0-0/0/15 GE 0/1/0-0/1/7
T1/E1 GE
ACX2000 0/0/8 0/0/9 0/0/10 0/0/11 0/0/12 0/0/13 0/0/14 0/0/15 0/1/4 0/1/5 0/1/6 0/1/7 POE
MGMT CONSOLE/AUX
g006414
ALARM
GE XE
1PPS 10MHz
IN OUT IN OUT
SYS 0 1 EXT REF CLK IN 0/0/0 0/0/1 0/0/2 0/0/3 0/0/4 0/0/5 0/0/6 0/0/7 0/1/0 0/1/1 0/1/2 0/1/3 POE
0/2/0 0/2/1 0/3/0 0/3/1

GE 0/2/0-0/2/1 XE 0/3/0-0/3/1

ACX2100 Hardware and CLI Terminology Mapping

Hardware
Item (as Value (as

Routers
FPC (n) Abbreviated name of n is a value in the The router does not have Interface Naming Conventions
the Flexible PIC range of 0–1. actual FPCs. In this case, FPC Used in the Junos OS Operational
Concentrator (FPC) refers to the router itself. Commands
the Physical Interface range of 0–3. actual PIC devices; see Used in the Junos OS Operational
Card (PIC) entries for PIC 0 through PIC Commands
the router.
16x T1/E1 (RJ-48) PIC 0 on FPC 0 Built-in network ports on the ACX2000 and ACX2100 Universal
4x 1GE (RJ-45) PIC 0 on FPC 1 Built-in network ports on the ACX2000 and ACX2100 Universal
One of the following: PIC 1 on FPC 1 Built-in uplink ports on the ACX2000 and ACX2100 Universal
• 4x 1GE (RJ-45)
• 4x 1GE (SFP)
2x 1GE (SFP) PIC 2 on FPC 1 Built-in uplink ports on the ACX2000 and ACX2100 Universal
2x 10GE (SFP+) PIC 3 on FPC 1 Built-in uplink ports on the ACX2000 and ACX2100 Universal
Xcvr (n) Abbreviated name of n is a value Optical transceivers Uplink Ports on ACX2000 and
the transceiver equivalent to the ACX2100 Routers
number of the port
in which the
transceiver is
installed.
Power Built-in power supply Value of n is always AC or DC power supply ACX2000 and ACX2100 Power
supply (n) 0. Overview

Hardware
Item (as Value (as

NOTE: ACX2100
routers are fanless
models.

FPC 0, PIC 0 FPC 1, PIC 0 FPC 1, PIC 2
T1/E1 0/0/0-0/0/15 GE 1/0/0-1/0/3 GE 1/2/0-1/2/1
T1/E1 GE
0/0/8 0/0/9 0/0/10 0/0/11 0/0/12 0/0/13 0/0/14 0/0/15 1/0/2 1/0/3 1/1/2 1/1/3
ACX2100
MGMT CONSOLE/AUX
g017849
ALARM
1/1/2 1/1/3 1/2/1
1PPS 10MHz
IN OUT IN OUT
0 1 EXT REF CLK IN 0/0/0 0/0/1 0/0/2 0/0/3 0/0/4 0/0/5 0/0/6 0/0/7 1/0/0 1/0/1 1/1/0 1/1/1
SYS
COMBO PORTS 1/1/0 1/1/1 GE 1/2/0 1/3/0 XE 1/3/1

GE 1/1/0-1/1/3 XE 1/3/0-1/3/1
Related • ACX2000 and ACX2100 Universal Access Router Overview

Documentation
Hardware Item (as Description (as Value (as displayed Item in Additional
displayed in the CLI) displayed in the CLI) in the CLI) Documentation Information

Specifications for
ACX2200 Routers
FPC (n) Abbreviated name of Value of n is always 0. The router does not Interface Naming
the Flexible PIC have actual FPCs. In Conventions Used in the
Concentrator (FPC) this case, FPC refers to Junos OS Operational
the router itself Commands
ACX2200
PIC (n) Abbreviated name of n is a value in the range The router does not Interface Naming
the Physical Interface of 0–3. have actual PIC Conventions Used in the
Card (PIC) devices; see entries for Junos OS Operational
PIC 0 through PIC 3 for Commands
the equivalent item on
the router

Hardware Item (as Description (as Value (as displayed Item in Additional
displayed in the CLI) displayed in the CLI) in the CLI) Documentation Information
4x 1GE (RJ-45) PIC 0 Built-in uplink ports on ACX2200 Universal

the front panel of the Access Router Overview
router
One of the following: PIC 1 Built-in uplink ports on ACX2200 Universal

• 4x 1GE (RJ-45) router
• 4x 1GE (SFP)
2x 1GE (SFP) PIC 2 Built-in uplink ports on ACX2200 Universal

router
2x 10GE (SFP+) PIC 3 Built-in uplink ports on ACX2200 Universal

router
Xcvr (n) Abbreviated name of n is a value equivalent Optical transceivers Uplink Ports on
the transceiver to the number of the ACX2200 Routers
port in which the
Power supply (n) Built-in power supply Value of n is always 0. DC power supply ACX2200 Power
Overview
Fan Fan – Fan Cooling System and

Airflow in an ACX2200
NOTE: ACX2200 Router
routers are fanless
models.

GE 0/0/0-0/0/3 GE 0/2/0-0/2/1
GE
0/0/2 0/0/3 0/1/2 0/1/3
ACX2200
MGMT CONSOLE/AUX
g017872
ALARM
0/1/2 0/1/3 0/2/1
1PPS 10MHz
IN OUT IN OUT
0 1 EXT REF CLK IN
SYS 0/0/0 0/0/1 0/1/0 0/1/1
COMBO PORTS 0/1/0 0/1/1 GE 0/2/0 0/3/0 XE 0/3/1

GE 0/1/0-0/1/3 XE 0/3/0-0/3/1

Documentation

Hardware
Item (as
displayed Description (as Value (as displayed
in the CLI) displayed in the CLI) in the CLI) Item in Documentation Additional Information

Specifications for
ACX4000 Routers
FPC (n) Abbreviated name of Value of n is a value The router does not have actual Interface Naming
the Flexible PIC in the range of 0–1. FPC devices; see entries for Conventions Used in the
Concentrator (FPC) FPC 0 and FPC 1 for the Junos OS Operational
equivalent item on the router. Commands
ACX4000
FPC BUILTIN FPC 0 Refers to the built-in FPC that

houses the built-in network ports.
FPC BUILTIN FPC 1 Slots in which one or two MICs

are installed
PIC (n) Abbreviated name of n is a value in the The router supports up to two Interface Naming
the Modular Interface range of 0–2. MICs and has built-in interfaces, Conventions Used in the
Cards (MICs) or built-in both represented as PIC in the Junos OS Operational
interfaces CLI; see entries for PIC 0 through Commands
PIC 2 for the equivalent item on
the router.
8x 1GE(LAN) SFP, RJ45 FPC 0, PIC 0 Built-in network ports on the ACX4000 Uplink Ports
front panel of the router Overview
2x 1GE(LAN) SFP FPC 0, PIC 1 Built-in network ports on the ACX4000 Uplink Ports
2x 10GE(LAN) SFP+ FPC 0, PIC 2 Built-in network ports on the ACX4000 Uplink Ports
<MIC 0 description> FPC 1, PIC 0 MIC installed in slot 0 ACX4000 Modular

Interface Card (MIC)
Overview
<MIC 1 description> FPC 1, PIC 1 MIC installed in slot 1
Xcvr (n) Abbreviated name of n is a value equivalent Optical transceivers

the transceiver to the number of the
port in which the
transceiver is
installed.
PEM (n) Power supply Value of n is a value AC or DC power supply ACX4000 Power Overview
in the range of 0–1.

Hardware
Item (as
displayed Description (as Value (as displayed
in the CLI) displayed in the CLI) in the CLI) Item in Documentation Additional Information
Fan Tray Fan Tray Value of n is always Fan tray module Cooling System and
(n) 0. Airflow in an ACX4000
Router

1 2 3
g006541
5 4

Documentation
• ACX5048 Router Hardware and CLI Terminology Mapping on page 39

• ACX5096 Router Hardware and CLI Terminology Mapping on page 40
ACX5048 Router Hardware and CLI Terminology Mapping

Table 13 on page 39 describes the hardware terms used in an ACX5048 router
documentation and the corresponding terms used in the Junos OS command line interface
(CLI). Figure 12 on page 40 shows the port locations of the interfaces.
Table 13: CLI Equivalents of Terms Used in Documentation for an ACX5048 Router
Hardware
Item (as
displayed in Description (as Value (as displayed
the CLI) displayed in the CLI) in the CLI) Item in Documentation Additional Information

for an ACX5000 Router

Table 13: CLI Equivalents of Terms Used in Documentation for an ACX5048 Router (continued)
Hardware
Item (as
FPC (n) Abbreviated name of Value of n is always 0. The router does not have Interface Naming Conventions
the Flexible PIC actual FPCs. In this case, Used in the Junos OS
itself.
PIC (n) Abbreviated name of Value of n is always 0. The router does not have Interface Naming Conventions
the Physical Interface actual PIC devices; see Used in the Junos OS
Card (PIC) entries for PIC 0 for the Operational Commands
equivalent item on the
router.
48x10G–6x40G PIC 0 Built-in network ports on ACX5000 Universal Access

router
Xcvr (n) Abbreviated name of n is a value equivalent Optical transceivers Port and Interface Specifications
the transceiver to the number of the
port in which the
transceiver is
installed.
Power Power supply n is a value in the AC power supply AC Power Supply for an
supply (n) range of 0-1. ACX5000 Router
DC power supply
DC Power Supply for an
ACX5000 Router
Fan Fan n is a value in the Fan Cooling System and Airflow in

range of 0-4. an ACX5000 Router

1 2 3
g0008 0 9
1— Electrostatic Discharge (ESD) terminal 3— 40 Gigabit Ethernet ports (6)
2—10 Gigabit Ethernet ports (48)
ACX5096 Router Hardware and CLI Terminology Mapping

Table 14 on page 41 describes the hardware terms used in an ACX5096 router
documentation and the corresponding terms used in the Junos OS command line interface
(CLI). Figure 13 on page 41 shows the port locations of the interfaces.

Table 14: CLI Equivalents of Terms Used in Documentation for an ACX5096 Router
Hardware
Item (as

for an ACX5000 Router
FPC (n) Abbreviated name of Value of n is always 0. The router does not have Interface Naming Conventions
the Flexible PIC actual FPCs. In this case, Used in the Junos OS
itself.
PIC (n) Abbreviated name of Value of n is always 0. The router does not have Interface Naming Conventions
the Physical Interface actual PIC devices; see Used in the Junos OS
Card (PIC) entries for PIC 0 for the Operational Commands
equivalent item on the
router.
96x10G–8x40G PIC 0 Built-in network ports on ACX5000 Universal Access

router
Xcvr (n) Abbreviated name of n is a value equivalent Optical transceivers Port and Interface
the transceiver to the number of the Specifications
port in which the
Power Built-in power supply n is a value in the AC power supply AC Power Supply for an
supply (n) range of 0-1. ACX5000 Router
DC power supply
DC Power Supply for an
ACX5000 Router
Fan Fan n is a value in the Fan Cooling System and Airflow in

range of 0-2 for an ACX5000 Router
ACX5096
1— Electrostatic Discharge (ESD) terminal 3— 40 Gigabit Ethernet ports (8)
2—10 Gigabit Ethernet ports (96)


Documentation

PART 2
Installing and Upgrading ACX Series

Routers
• Installing and Upgrading Junos OS on page 45
• Configuring Autoinstallation on page 75


CHAPTER 2
Installing and Upgrading Junos OS
• Routing Engines and Storage Media Names (ACX Series, M Series, MX Series, PTX
Series, T Series, TX Matrix, TX Matrix Plus, and JCS 1200 Routers) on page 45
• Boot Sequence on ACX Series Routers on page 48
• Dual-Root Partitioning ACX Series Routers Overview on page 48
• Understanding How the Primary Junos OS Image with Dual-Root Partitioning Recovers
on the ACX Series Router on page 49
• Junos OS Release 12.2 or Later Upgrades with Dual-Root Partitioning on ACX Series
Routers on page 51
• Installing Junos OS Using a USB Storage Device on ACX Series Routers on page 52
• Installing Junos OS Upgrades from a Remote Server on ACX Series Routers on page 52
• Example: Installing Junos OS and Configuring a Dual-Root Partition on ACX Series
Routers Using the CLI on page 53
• Upgrading Software Packages on page 57
• Loading and Committing the Configuration File on page 60
• Checking the Current Configuration and Candidate Software Compatibility on page 61
• Unattended Boot Mode in ACX Series on page 61
• Understanding System Snapshot on an ACX Series Router on page 64
• Example: Taking a Snapshot of the Software and Configuration on page 65
• Understanding In-Service Software Upgrade (ISSU) in ACX5000 Series
Routers on page 68
• Performing an In-Service Software Upgrade (ISSU) in ACX5000 Series
Routers on page 69
Routing Engines and Storage Media Names (ACX Series, M Series, MX Series, PTX
Series, T Series, TX Matrix, TX Matrix Plus, and JCS 1200 Routers)
Table 15 on page 46 specifies the storage media names by Routing Engine. The storage
media device names are displayed when the router boots.

Table 15: Routing Engines and Storage Media Names (ACX Series, M
Series, MX Series, T Series, TX Matrix, TX Matrix Plus, and JCS 1200
Routers)
Removable
Media
CompactFlash Solid-State Emergency
Routing Engine Card Hard Disk Drive Boot Device
RE-400-768 (RE5) ad0 ad1 No ad3
RE-600-2048 (RE3) ad0 ad1 No ad3
RE-850-1536 ad0 ad1 No ad3

(RE-850)
RE-A-1000-2048 ad0 ad2 No da0

(RE-A-1000)
RE-A-1800x2 ad0 No Yes da0

(RE-A-1800)
SSD1: ad1
SSD2: ad2
RE-S-1300-2048 ad0 ad2 No da0

(RE-S-1300)
RE-S-1800x2 ad0 No Yes da0

RE-S-1800x4
(RE-S-1800) SSD1: ad1
SSD2: ad2
RE-B-1800X1-4G-S ad0 No Yes da0
SSD1: ad1
RE-1600-2048 (RE4) ad0 ad1 No ad3 and ad4
RE-A-2000-4096 ad0 ad2 No da0

(RE-A-2000)
RE-S-2000-4096 ad0 ad2 No da0

(RE-S-2000)
RE-MX-104 No da0 No da1 and da2
RE-DUO-C2600-16G ad0 No ad1 da0

(RE-DUO-2600)
RE-DUO-C1800-8G- ad0 No ad1 da0

(RE-DUO-1800)
RE-DUO-C1800-16G ad0 No ad1 da0

Chapter 2: Installing and Upgrading Junos OS
Table 15: Routing Engines and Storage Media Names (ACX Series, M
Series, MX Series, T Series, TX Matrix, TX Matrix Plus, and JCS 1200
Routers) (continued)
Removable
Media
CompactFlash Solid-State Emergency
Routing Engine Card Hard Disk Drive Boot Device
RE-JCS1200-1x2330 da0 da1 No da2
RE-PTX-X8-64G No No SSD1 USB
SSD2
RE-S-X6-64G No No SSD1 USB
SSD2
REMX2K-X8-64G No No SSD1 USB
SSD2
NOTE: On MX80 routers, the Routing Engine is a built-in device and has no
model number. The dual internal NAND flash devices are da0 and da1. The
USB storage device is da2.
NOTE: On ACX Series routers, the Routing Engine is a built-in device which
does not have a model number. The dual internal NAND flash devices are
da0s1 and da0s2. The USB storage device is da0s2a. Use the show chassis
hardware models command to obtain the field-replaceable unit (FRU) model
number—for example, ACX2000BASE-DC for the ACX2000 router.
To view the storage media currently available on your system, use the CLI show system
storage command. For more information about this command, see the CLI User Guide.
Related • Supported Routing Engines by Router

Documentation
• Routing Engine Specifications
• RE-S-1300 Routing Engine Description
• RE-S-2000 Routing Engine Description
• RE-S-1800 Routing Engine Description for MX Series
• JCS1200 Routing Engine Description

Boot Sequence on ACX Series Routers
The router attempts to boot from the storage media in the following order:
1. USB storage media device.
2. Dual, internal NAND flash device (first da0s1, then da0s2).

Documentation
Dual-Root Partitioning ACX Series Routers Overview
Dual-root partitioning allows the ACX Series router to remain functional even if there is
file system corruption and to facilitate easy recovery of the file system. Dual-root
partitioning means that the primary and backup Junos OS images are kept in two
independently bootable root partitions. If the primary root partition becomes corrupted,
the system can still boot from the backup Junos OS image located in the other root
partition and remain fully functional.
NOTE: ACX5048 and ACX5096 routers do not support dual-root partitioning.

All other ACX routers run with dual-root partitioning.
This section contains the following topics:
• Boot Media and Boot Partition on the ACX Series Routers on page 48
• Important Features of the Dual-Root Partitioning Scheme on page 49
Boot Media and Boot Partition on the ACX Series Routers

With dual-root partitioning, the ACX Series router first tries to boot the Junos OS from
the primary root partition and then from the backup root partition on the internal NAND
flash. If both primary and backup root partitions of the internal NAND flash fail to boot,
you must insert a USB storage media with a copy of the Junos OS from which to boot.
The following is the storage media available on the ACX Series router:
• USB media emergency boot device
NOTE: The USB media device is not dual-root partitioned.
• Dual, internal NAND flash device (first daOs1, then daOs2)

Important Features of the Dual-Root Partitioning Scheme

The dual-root partitioning scheme has the following important features:
• The primary and backup copies of Junos OS images reside in separate partitions. The
partition containing the backup copy is mounted only when required. With the
single-root partitioning scheme, there is one root partition that contains both the
primary and the backup Junos OS images.
• The request system software add command for a Junos OS package erases the contents
of the other root partition. The contents of the other root partition will not be valid
unless software installation is completed successfully.
• Add-on packages, such as jais or jfirmware, can be reinstalled as required after a new
Junos OS image is installed.
• The request system software rollback command does not delete the current Junos OS
image. It is possible to switch back to the image by issuing the rollback command again.
Related • Understanding How the Primary Junos OS Image with Dual-Root Partitioning Recovers
Documentation on the ACX Series Router on page 49

Understanding How the Primary Junos OS Image with Dual-Root Partitioning Recovers
on the ACX Series Router
If the ACX Series Universal Access router is unable to boot from the primary Junos OS
image and boots up from the backup Junos OS image in the backup root partition, a
message appears on the console at the time of login indicating that the device has booted
from the backup Junos OS image.
login: user
Password:
***********************************************************************
** **
** WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE **

** **
** It is possible that the active copy of JUNOS failed to boot up **
** properly, and so this device has booted from the backup copy. **
** **
** Please re-install JUNOS to recover the active copy in case **
** it has been corrupted. **
** **
***********************************************************************
Because the system is left with only one functional root partition, you should immediately
restore the primary Junos OS image using one of the following methods:
• Install a new image using the CLI. When you install the new image, the new image is
installed on only one partition–the alternate partition, meaning the router is now running
two images. When you reboot, the router boots from the newly installed image, which
becomes the primary image. So now there are two different images running on the
router. Run the installation process again to update the other partition.
• Use a snapshot of the backup root partition by entering the request system snapshot
slice alternate command. After the primary root partition is recovered using this method,
the device will successfully boot from the primary root partition on the next reboot.
After the procedure, the primary root partition will contain the same version of Junos
OS as the backup root partition.
NOTE: You can use the CLI command request system snapshot slice
alternate to back up the currently running root file system (primary or
secondary) to the other root partition on the system.
You can use this command to:
• Save an image of the primary root partition in the backup root partition
when the system boots from the primary root partition.
• Save an image of the backup root partition in the primary root partition
when the system boots from the backup root partition.
WARNING: The process of restoring the alternate root by using the CLI
command request system snapshot slice alternate takes several minutes
to complete. If you terminate the operation before completion, the alternate
root might not have all required contents to function properly.


Documentation

Junos OS Release 12.2 or Later Upgrades with Dual-Root Partitioning on ACX Series
Routers
NOTE: If you are upgrading to Junos OS Release 12.2 without transitioning

to dual-root partitioning, use the conventional CLI installation method.
To format the media with dual-root partitioning while upgrading to Junos OS Release
12.2 or later, use either of the following installation methods:

All other ACX routers run with dual-root partitioning.
• Installation using a USB storage device. We recommend this method if console access
to the system is available and the system can be physically accessed to plug in a USB
storage device. See Installing Junos OS Using a USB Storage Device on ACX Series
Routers.
• Installation from the CLI. We recommend this method only if console access is not
available. This installation can be performed remotely. See Installing Junos OS Upgrades
from a Remote Server on ACX Series Routers.

Documentation


Installing Junos OS Using a USB Storage Device on ACX Series Routers
To install the Junos OS image on ACX Series routers using a USB storage device, you
must have access to the USB port physically and you must also have console access.
Perform the following steps to install the Junos OS image:
1. Insert the USB storage device that has a valid installation image into the USB port.
2. Reboot the router by either pressing the power button on the chassis or switching off
and turning on the power button behind the Routing Engine, or by entering the request
system reboot command from the CLI. The system LED starts blinking in green.
On the console, a message is displayed stating that your flash memory device (NAND
Flash device) will be formatted and you will lose all the data. You are prompted to
confirm the formatting of the flash memory device.
3. Press y to confirm and proceed with the formatting process. The flash memory device
is formatted and the image is installed on both the partitions.
After the installation is completed, a message is displayed on the console prompting

you to eject the USB storage device and to press Enter to reboot the device.
4. After you remove the USB port and press Enter, the reboot begins. After the router is
rebooted, the new Junos OS version is loaded and functional. The LED glows steadily
in green.
NOTE: If an installation error occurs, the LEDs turn red. You must have console
access to the router to troubleshoot an installation error.

Documentation
Routers on page 51

Installing Junos OS Upgrades from a Remote Server on ACX Series Routers
You can use the CLI to install Junos OS packages that are downloaded with FTP or HTTP
from the specified location on internal media, such as the NAND Flash device.

Before you begin:
• Verify the available space on the NAND Flash device.
• Download the Junos OS package.
To install Junos OS upgrades from a remote server, enter the following command from
operational mode:
user@host>request system software add junos-juniper-12.2R1.9-domestic.tgz no-copy

no-validate reboot
The new Junos OS image is installed on the router and the device is rebooted.
NOTE: On ACX5048 and ACX5096 routers, use the force-host option to force
installing the latest version of the Host OS.
user@host> request system software

jinstall-acx5k-15.1X54-D20.6-domestic-signed.tgz force-host add validate
reboot

Documentation
Routers on page 51

Example: Installing Junos OS and Configuring a Dual-Root Partition on ACX Series

Routers Using the CLI
This example shows how to install Junos OS Release 12.2 or later and configure a dual-root
partition on ACX Series routers with the CLI.
• Requirements on page 53
• Overview on page 54
• Configuration on page 54
• Verification on page 56
Requirements
This example requires an ACX Series router. Before you begin, back up any important
data.

Overview
This example formats the NAND Flash device and installs the new Junos OS image on
the media with dual-root partitioning. Install the Junos OS Release 12.2 or later image
from the CLI by using the request system software add command. Partitions are
automatically created on ACX Series routers and no option needs to be manually entered
for creating partitions. This command copies the image to the device, and then reboots
the device for installation. The device boots with the Release 12.2 or later image installed
with the dual-root partitioning scheme. The formatting and installation process is
scheduled to run on the next reboot. Therefore, we recommend that this option be used
together with the reboot option.
NOTE: The process might take 15 to 20 minutes. The system is not accessible
over the network during this time.
WARNING: Using the request system software add command erases the
existing contents of the media. Only the current configuration is preserved.
You should back up any important data before starting the process.
NOTE: Dual, internal NAND Flash device (first daOs1, then daOs2) and USB
storage device are the storage media available on the ACX Series router. The
USB storage device is not dual-root partitioned.
In this example, add the software package junos-juniper-12.2R1.9-domestic.tgz with the

following options:
• no-copy option to install the software package. However, do not save the copies of
the package files. You should include this option if you do not have enough space on
the internal media to perform an upgrade that keeps a copy of the package on the
device.
• no-validate option to bypass the compatibility check with the current configuration
before installation starts.
• reboot option to reboot the device after installation is completed.
Configuration
CLI Quick To install Junos OS Release 12.2 or later and configure dual-root partitioning on ACX
Configuration Series routers, copy the following command, paste it in a text file, remove any line break,
and then copy and paste the command into the CLI.
From operational mode, enter:
user@host>request system software add junos-juniper-12.2R1.9-domestic.tgz no-copy

no-validate reboot

Step-by-Step To install Junos OS Release 12.2 or later and configure a dual-root partition:
Procedure
1. Upgrade the ACX Series router to Junos OS Release 12.2 or later using the CLI. See
“Upgrading Software Packages” on page 57.
2. Install Junos OS Release 12.2 or later and configure the dual-root partition.
user@host>request system software add junos-juniper-12.2R1.9-domestic.tgz

no-copy no-validate reboot
Copying package junos-juniper-12.2R1.9-domestic.tgz to var/tmp/install
Rebooting ...
Results In operational mode, confirm your configuration by entering the show system storage
command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.
Sample output on a system with dual-root partitioning that displays information about
the root partition that is mounted (only one root partition is mounted at a point in time):
user@host> show system storage
Filesystem Size Used Avail Capacity Mounted on

/dev/da0s1a 872M 150M 713M 17% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/md0 41M 41M 0B 100% /packages/mnt/jbase
/dev/md1 183M 183M 0B 100%
/packages/mnt/jkernel-ppc-12.2I20121026_1217_sranjan
/dev/md2 30M 30M 0B 100%
/packages/mnt/jpfe-ACX-12.2I20121026_1217_sranjan
/dev/md3 9.1M 9.1M 0B 100%
/packages/mnt/jdocs-12.2I20121026_1217_sranjan
/dev/md4 55M 55M 0B 100%
/packages/mnt/jroute-ppc-12.2I20121026_1217_sranjan
/dev/md5 12M 12M 0B 100%
/packages/mnt/jcrypto-ppc-12.2I20121026_1217_sranjan
/dev/md6 1.0G 8.0K 951M 0% /tmp
/dev/md7 1.0G 448K 950M 0% /mfs
/dev/da0s1e 92M 18K 91M 0% /config
procfs 4.0K 4.0K 0B 100% /proc
/dev/da0s3f 3.9G 3.6G 30M 99% /var
/dev/da0s3d 447M 2.8M 409M 1% /var/log
If you are done configuring the device, enter commit in configuration mode.
You can issue the fdisk command from the Junos prompt to display information about
the entire partition format on the NAND Flash device. All ACX Series routers run with
dual-root partitioning. The following example displays the partition details on an ACX
Series router with dual-root partitions:
user@host% fdisk
******* Working on device /dev/da0 *******

parameters extracted from in-core disklabel are:
cylinders=487 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:

cylinders=487 heads=255 sectors/track=63 (16065 blks/cyl)
Media sector size is 512

Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 567, size 1011528 (493 Meg), flag 80 (active)
beg: cyl 0/ head 9/ sector 1;
end: cyl 62/ head 254/ sector 63
start 1012662, size 1011528 (493 Meg), flag 0
In the preceding example, partition 1 and 2 contain two partitions each internally, a root
partition and a configuration partition.
Verification
Confirm that the configuration is working properly.
• Verifying the Partitioning Scheme Details on page 56
Verifying the Partitioning Scheme Details
Purpose Verify that the partitioning scheme details on the ACX Series router were configured.
Action In operational mode, enter the show system storage command. For details about the
output of this command and the descriptions of the output fields, see show system
storage.
Related • Junos OS Release 12.2 or Later Upgrades with Dual-Root Partitioning on ACX Series
Documentation Routers on page 51
• Installation and Upgrade Guide

Upgrading Software Packages
NOTE: When you install individual software packages, the following notes
apply:
• When upgrading from Junos OS Release 8.2 or earlier to Junos OS Release

8.5, use the system software add <image> no-validate command option.
• Only use the jinstall Junos OS image when upgrading or downgrading to or

from Junos OS Release 8.5. Do not use the jbundle image.
• Before upgrading to Junos OS Release 8.5, ensure that the routing

platform’s CompactFlash card is 256 MB or larger to avoid disk size
restrictions. (M7i routers without a CompactFlash card are excluded.)
NOTE: If you are upgrading a Routing Engine on a PTX Series router to run
Junos OS Release 13.2R2 and later, and then make that Routing Engine the
master Routing Engine, then the master Routing Engine reports a major alarm
CB 0/1 ESW PFE Port Fail even though the Control Board’s Ethernet switch
links are up and running on both the master and the backup Routing Engines.
This is because the backup Routing Engine is still on Junos OS Release 13.2R1
or earlier. The alarm is cleared after you have completed the upgrade of Junos
OS on the backup Routing Engine.
User@router# show chassis alarms

2 alarms currently active
Alarm time Class Description
2014-10-15 00:44:31 BST Major CB 0 ESW PFE Port Fail
2014-10-15 00:42:42 BST Minor Backup RE Active
To upgrade an individual Junos OS package:
1. Download the software packages you need from the Juniper Networks Support Web
site at http://www.juniper.net/support/. For information about downloading software
packages, see Downloading Software.
NOTE: We recommend that you upgrade all individual software packages

using an out-of-band connection from the console or management
Ethernet interface, because in-band connections can be lost during the
upgrade process.
2. Back up the currently running and active file system so that you can recover to a known,
stable environment in case something goes wrong with the upgrade:
user@host> request system snapshot

The root file system is backed up to /altroot, and /config is backed up to /altconfig.
The root and /config file systems are on the router’s CompactFlash card, and the
/altroot and /altconfig file systems are on the router’s hard disk or solid-state drive
(SSD).
NOTE: After you issue the request system snapshot command, you cannot
return to the previous version of the software, because the running copy
and the backup copy of the software are identical.
NOTE: SRX5000-line devices, the root file system is backed up to /altroot,

and /config is backed up to /altconfig. The root and /config file systems
are on the router’s CompactFlash card, and the /altroot and /altconfig file
systems are on the router’s hard disk or solid-state drive (SSD).
NOTE: This step is optional for SRX300, SRX320, SRX340, SRX345, and
SRX550M; for these devices, ensure that a USB flash drive is plugged into
the USB port of the device.
3. If you are copying multiple software packages to the router, copy them to the /var/tmp
directory on the hard disk or solid-state drive (SSD):
user@host> file copy ftp://username :prompt@ftp.hostname

.net/filename/var/tmp/filename
4. Add the new software package:
• To add an individual software package:
user@host> request system software add/var/tmp/ installation-package validate
installation-package is the full URL to the file.
NOTE: For SRX5800, SRX5600, and SRX5400 devices, do not include

the re0 | re1 option when you install a package using the request system
software add command, if the Routing Engine on which the package is
located and the Routing Engine on which you want to install the package
is the same. In such cases, the package gets deleted after a successful
upgrade.
If you are upgrading more than one package at the same time, add jbase first. If you
are using this procedure to upgrade all packages at once, add them in the following
order:
user@host> request system software add /var/tmp/jbase-release-signed.tgz
user@host> request system software add /var/tmp/jkernel-release-signed.tgz

user@host> request system software add /var/tmp/jpfe-release-signed.tgz
user@host> request system software add /var/tmp/jdocs-release- signed.tgz
user@host> request system software add /var/tmp/jweb-release- signed.tgz
user@host> request system software add /var/tmp/jroute-release-signed.tgz
user@host> request system software add /var/tmp/jcrypto-release-signed.tgz
• For M Series, MX Series, and T Series routers running Junos OS Release 12.2 and
later, you can add more than one software package at the same time. To add
multiple software packages:
user@host> request system software add set /var/tmp/

installation-package/var/tmp/ installation-package validate
installation-package can be any of the following:
• A list of installation packages, each separated by a blank space. For example:
user@host> request system software add set /var/tmp/

jinstall-10.2R1.8–domestic-signed.tgz /var/tmp/ jtools*.tgz validate
• The full URL to the directory or tar file containing the list of installation packages.
Use the request system software add set command to retain any SDK configuration
by installing the SDK add-on packages along with the core Junos OS installation
package.
WARNING: Do not include the re0 | re1 option when you install a package
using the request system software add command, if the Routing Engine on
which the package is located and the Routing Engine on which you want
to install the package are the same. In such cases, the package gets
deleted after a successful upgrade.
The system might display the following message:
pkg_delete: couldn’t entirely delete package
This message indicates that someone manually deleted or changed an item that was
in a package. You do not need to take any action; the package is still properly deleted.
For more information about the request system software add command, see the CLI
Explorer.
5. Reboot the router to start the new software:
user@host> request system reboot
6. After you have upgraded or downgraded the software and are satisfied that the new
software is successfully running, issue the request system snapshot command to back
up the new software:

NOTE: On an ACX router, you must issue the request system snapshot slice
alternate command.
The root file system is backed up to /altroot, and /config is backed up to /altconfig.
The root and /config file systems are on the router’s CompactFlash card, and the
/altroot and /altconfig file systems are on the router’s hard disk or solid-state drive
(SSD).
NOTE: After you issue the request system snapshot command, you cannot
return to the previous version of the software, because the running copy
and backup copy of the software are identical.
NOTE: To install the Junos OS software package and host software package
on routers with RE-MX-X6, RE-MX-X8, and RE-PTX-X8 Routing Engines, see
VM Host Installation
Related • VM Host Installation

Documentation
Loading and Committing the Configuration File
Once the saved configuration file is copied to the router, you load and commit the file:
1. Start the CLI configuration mode.

user@routername> configure
Entering configuration mode
[edit]
user@host#
2. Load the file into the current configuration. You should override the existing file.
user@host#
load override /var/tmp/filename
load complete
3. Commit the file.
user@host# commit
commit complete
4. Exit the CLI configuration mode.
user@host# exit
user@host>
5. Back up Junos OS.

After you have installed the software on the router, committed the configuration, and
are satisfied that the new configuration is successfully running, issue the request
system snapshot command to back up the new software to the /altconfig file system.
If you do not issue the request system snapshot command, the configuration on the
alternate boot drive will be out of sync with the configuration on the primary boot
drive.
The request system snapshot command causes the root file system to be backed up
to /altroot, and /config to be backed up to /altconfig. The root and /config file systems
are on the router’s CompactFlash card, and the /altroot and /altconfig file systems
are on the router’s hard disk or solid-state drive (SSD).
Checking the Current Configuration and Candidate Software Compatibility
When you upgrade or downgrade Junos OS, we recommend that you include the validate
option with the request system software add command to check that the candidate
software is compatible with the current configuration. By default, when you add a package
with a different release number, the validation check is done automatically.
NOTE: On an ACX Series router, you must ensure that the primary and backup
partitions are synchronized after an upgrade by issuing the request system
snapshot command.
Related • Preparing Your SRX Series Device for Junos OS Upgrades

Documentation
• Downloading Software Packages from Juniper Networks
• Example: Installing Junos OS Upgrade Packages on SRX Series Devices
• Installing Junos OS Upgrade Packages on SRX Series Devices from a Remote Server
• request system snapshot (Maintenance)
• request system software add (Maintenance)
Unattended Boot Mode in ACX Series
Junos operating system (Junos OS) for ACX series router supports unattended boot
mode. Unattended boot mode feature blocks any known methods to get access to the
router from CPU reset till Junos OS login prompt, thereby preventing a user to make any
unauthorized changes on the router such as viewing, modifying, or deleting configuration
information.
NOTE: Unattended boot mode is not supported on ACX5048 and ACX5096

routers.

To enable unattended boot mode, you need to configure a bootloader password.

Bootloader password can be either in plain-text as entered by the user, or an encrypted
string as provided in the input configuration file. The unattended-boot mode is disabled,
by default.
To enable unattended boot mode, enter a bootloader password, commit the changes,
and then enable unattended boot mode:
1. Use the following command to set a bootloader password using plain-text-password

option:
[edit]
user@host# set system boot-loader-authentication plain-text-password
New Password: type password here
Retype new password: retype password here
2. Use the following command to set a bootloader password using encrypted-password

option:
[edit]
user@host# set system boot-loader-authentication encrypted-password password
NOTE: When you set a bootloader password using encrypted-password

option, you should use the encryption type as MD5.
3. Commit the changes:
[edit]
user@host# commit
4. Exit from configuration mode:
[edit]
user@host#exit
user@host>
NOTE: After the router reboots, you need to enter the bootloader password
at the bootloader login prompt.
5. To enable unattended boot mode, use the following command:
[edit]
user@host#set system unattended-boot
[edit]
user@host#commit

A warning message appears as Please take snapshot to alternate slice after

unattended-boot enable is successfully committed. commit complete
[edit]
user@host# exit
user@host>
For information on taking system snapshot, see “Understanding System Snapshot on

an ACX Series Router” on page 64 and “Example: Taking a Snapshot of the Software and
Configuration” on page 65.
To disable unattended boot mode, delete the bootloader password and then delete the
unattended boot mode:
1. Use the following command to delete the bootloader password:
[edit]
user@host# delete system boot-loader-authentication
2. Use the following command to delete unattended boot mode:
[edit]
user@host# delete system unattended-boot
[edit]
user@host# commit
A warning message appears as Please take snapshot to alternate slice after

unattended-boot enable is successfully committed. commit complete
For information on taking system snapshot, see “Understanding System Snapshot

on an ACX Series Router” on page 64 and “Example: Taking a Snapshot of the Software
and Configuration” on page 65.
[edit]
user@host# exit
root@>
If unattended mode is enabled or configured, the USB mode of booting is disabled. If you
want to boot from an external USB device, you need use the bootfrom USB CLI command
at the bootloader prompt.
Related • Understanding System Snapshot on an ACX Series Router on page 64

Documentation
• Example: Taking a Snapshot of the Software and Configuration on page 65

Understanding System Snapshot on an ACX Series Router
The system snapshot feature enables you to create copies of the software running on
an ACX Series router. You can use the system snapshot feature to take a “snapshot” of
the files currently used to run the router—the complete contents of the root (/) and
/config directories, which include the running Juniper Networks Juniper operating system
(Junos OS) and the active configuration—and copy all of these files to another media,
such as a universal serial bus (USB) storage device, the active slice of a dual-root
partitioned router, or the alternate slice of a dual-root partitioned router.
NOTE: Junos OS automatically uses the backup software if the currently

running software goes bad. For example, if the da0s1 slice goes bad, Junos
OS automatically comes up using the da0s2 slice, and takes a snapshot of
the da0s2 slice and copies it to the da0s1 slice if the auto snapshot
functionality is configured, which is disabled by default. However, you can
also do this manually using the system snapshot feature.
NOTE: In ACX5048 and ACX5096 routers, the system snapshot feature is

applicable only when a USB storage device is used.
Typically, you can take a snapshot prior to the upgrade of an image on the dual internal
NAND flash device (da0s1 or da0s2), or to remedy a bad image, thereby preventing the
bad image from rendering the system useless. A snapshot to another media ensures that
the device can boot from the other media in case the system does not boot up from the
current image.
You can take a snapshot of the currently running software and configuration on a router
in the following situations:
• The router's active slice (for example, da0s1) is updated with a new Junos OS image
(using the jinstall package). In such a case, you must update the other slice (da0s2)
with the new image.
NOTE: The active slice can be da0s1 or da0s2.
• The router's active slice (for example, da0s1) is corrupted and the router is rebooted
from the backup slice (that is, from da0s2). Therefore, you must restore a new image
on the active slice—that is, on da0s1.
• Both slices of the router's dual internal NAND flash device are corrupted and the router
continues trying to reboot. In this situation, you can insert a USB storage device, boot
the router from that device, and restore the NAND flash device slices—da0s1 and da0s2.

NOTE: Before you attempt to take a snapshot from the USB storage device,
ensure that the USB storage device contains an image of Junos OS from
which the router can boot up.
Related • Example: Taking a Snapshot of the Software and Configuration on page 65

Documentation
• request system snapshot (ACX Series) on page 1807
Example: Taking a Snapshot of the Software and Configuration
This example includes six scenarios in which you can take a snapshot of the currently
running software and configuration on an ACX Series router, prior to the upgrade of an
image or to remedy a bad image, thereby preventing the bad image from rendering the
system useless.
• Taking a Snapshot on page 66
Requirements
This example uses the following hardware and software components:
• One ACX Series router
• Junos OS Release 12.2 or later
Overview
In this example, the request system snapshot command is used to take a copy of the
currently running software and configuration on another media—for example, a universal
serial bus (USB) storage device, the active slice (da0s1 or da0s2) of a dual-root partitioned
router, or the alternate slice (da0s1 or da0s2) of a dual-root partitioned router. A snapshot
to another media ensures that the device can boot from the other media in case the
system does not boot up from the current image.
CAUTION: After you run the request system snapshot command, you cannot
return to the previous version of the software, because the running and backup
copies of the software are identical.

Taking a Snapshot
Scenario: To take a snapshot from a NAND flash device slice to a USB storage device:
1. Boot up the router from the NAND flash device and make sure that a formatted USB
storage device is plugged in to the router’s USB port. The USB storage device must
be formatted for the root (/) and /config directories.
2. Issue the request system snapshot command.

Verifying compatibility of destination media partitions...
Running newfs (254MB) on usb media / partition (da1s1a)...
Running newfs (47MB) on usb media /config partition (da1s1e)...
Copying '/dev/da0s2a' to '/dev/da1s1a' .. (this may take a few minutes)
Copying '/dev/da0s2e' to '/dev/da1s1e' .. (this may take a few minutes)
The following filesystems were archived: / /config
The root (/) and /config directories from the currently mounted NAND flash slice are
copied to the USB storage device.
Scenario: To take a snapshot from a NAND flash device slice to a USB storage device
with formatting:
1. Boot up the router from the NAND flash device and make sure that a USB storage
device is plugged in to the router’s USB port.
NOTE: Formatting a USB storage device deletes all the data on the USB
storage device.
2. Issue the request system snapshot partition command.
user@host> request system snapshot partition

clearing current label...
Partitioning usb media (da1) ...
Partitions on snapshot:
Partition Mountpoint Size Snapshot argument

a / 312MB root-size
e /config 47MB config-size
f /var 620MB var-size
Running newfs (312MB) on usb media / partition (da1s1a)...
Running newfs (47MB) on usb media /config partition (da1s1e)...
Running newfs (620MB) on usb media /var partition (da1s1f)...
After the USB storage device is formatted, the root (/) and /config directories from
the currently mounted NAND flash slice are copied to the USB storage device.

Scenario: To take a snapshot from the active slice of the NAND flash device to the
alternate slice:
1. Boot up the router from the NAND flash device.
2. Issue the request system snapshot slice alternate command.
user@host> request system snapshot slice alternate

Running newfs (439MB) on internal media / partition (da0s1a)...
Running newfs (46MB) on internal media /config partition (da0s1e)...
The root (/) and /config directories from the currently mounted NAND flash slice are
copied to the other slice.
Scenario: To take a snapshot from an active slice of the NAND flash device to the alternate
slice after partitioning:
1. Boot up the router from the NAND flash device.
2. Issue the request system snapshot partition slice alternate command.
user@host> request system snapshot partition slice alternate

The BSD label (disk partitioning information) for the active flash slice is installed and
then the root (/) and /config directories from the currently mounted NAND flash slice
are copied to the other slice.
Scenario: To take a snapshot from a USB storage device to the active slice of the NAND
flash device:
1. Boot up the router from a USB storage device containing the required Junos OS image.
2. Issue the request system snapshot command.


The root (/) and /config directories from the USB storage device are copied to the
active NAND flash slice.
Scenario: To take a snapshot from a USB storage device to the active slice of the NAND
flash device after partitioning:
1. Boot up the router from a USB storage device containing the required Junos OS image.
2. Issue the request system snapshot partition command.
user@host> request system snapshot partition

The BSD label (disk partitioning information) for the active flash slice is installed and
then the root (/) and /config directories from the USB storage device are copied to
the active NAND flash slice.
Related • Understanding System Snapshot on an ACX Series Router on page 64

Documentation
• request system snapshot (ACX Series) on page 1807
Understanding In-Service Software Upgrade (ISSU) in ACX5000 Series Routers
An in-service software upgrade (ISSU) enables you to upgrade between two different
Junos OS releases with minimal disruption on the control plane and with minimal
disruption of traffic. During an ISSU, the Junos OS runs in two separate virtual machines
(VMs)—one VM is in the master role acting as the master Routing Engine, and the other
VM is in the backup role acting as the backup Routing Engine. The Junos OS is upgraded
on the backup VM. After a successful software upgrade, the backup VM then becomes
the master VM, and the original master VM is no longer needed and is shut down.
NOTE: ISSU is supported in Junos OS Release 15.1X54–D60 or later for

ACX5000 Series routers.
ISSU provides the following benefits:
• Eliminates network downtime during software image upgrades
• Reduces operating costs, while delivering higher service levels
• Allows fast implementation of new features
• In-Service Software Upgrade Process on page 69

In-Service Software Upgrade Process

When you request an ISSU on a standalone device:
1. The management process (mgd) verifies that non-stop routing (NSR), graceful Routing
Engine switchover (GRES), and non-stop bridging (NSB) are enabled.
2. The router downloads and validates the software package.
3. The ISSU state machine spawns the backup Routing Engine (RE) with the newer
software.
4. The ISSU state machine checks to see if the backup RE has synchronized all of the
data with the master RE.
5. The ISSU state machine moves the devices (for example, forwarding ASIC, FPGA,
management port and serial console) from the master RE to the backup RE.
6. The mastership is switched between the REs, so the backup RE becomes the master
RE.
7. The old master RE is shut down.
Related
Documentation
Performing an In-Service Software Upgrade (ISSU) in ACX5000 Series Routers
You can use an in-service software upgrade to upgrade the software running on the router
with minimal traffic disruption during the upgrade.
NOTE: ISSU is supported in Junos OS Release 15.1X54–D60 and later on

ACX5000 Series routers.
This topic covers:
1. Preparing the Router for Software Installation on page 69

2. Upgrading the Software Using ISSU on page 71
3. Verifying a Unified ISSU on page 73
Preparing the Router for Software Installation

Before you begin software installation using ISSU:
NOTE: Before you perform an in-service software upgrade, if applicable,

remove the set system internet-options no-tcp-reset drop-all-tcp command
from the configuration, otherwise the upgrade will fail and an error message
will be displayed.

• Ensure that nonstop active routing (NSR) and nonstop bridging (NSB) are enabled. If
enabled, disable graceful restart (GR), because NSR and GR cannot be enabled
simultaneously. NSB and GR enable NSB-supported Layer 2 protocols to synchronize
protocol information between the master and backup Routing Engines.
• If NSR is not enabled (Stateful Replication is Disabled), then enable NSR. NSR requires
you to configure graceful Routing Engine switchover (GRES). By default, NSR is disabled.
• To enable graceful Routing Engine switchover, include the graceful-switchover

statement at the [edit chassis redundancy] hierarchy level as user@host#set chassis
redundancy graceful-switchover.
• To enable NSR, include the nonstop-routing statement at the [edit routing-options]

hierarchy level as user@host#set routing-options nonstop-routing.
• Enable nonstop bridging (NSB). Nonstop bridging requires you to configure graceful
Routing Engine switchover (GRES). By default, NSB is disabled.
• To enable graceful Routing Engine switchover, include the graceful-switchover

statement at the [edit chassis redundancy] hierarchy level as user@host#set chassis
redundancy graceful-switchover.
• To enable NSB, include the nonstop-bridging statement at the [edit protocols

layer2-control] hierarchy level as user@host#set protocols layer2-control
nonstop-bridging.
• (Optional) Back up the system software—Junos OS, the active configuration, and log
files—on the router to an external storage device with the request system snapshot
command.
On ACX5000 line of routers, you need to consider the following feature before performing
ISSU:
• ISSU supports link fault management (LFM) timeout sessions of 1 second interval.
During ISSU, you may notice LFM flaps for sessions having timeout interval of less than
1 second.
• Bidirectional Forwarding Detection (BFD) sessions having timeout interval of less than
1 second need to be reconfigured to 1 second before starting the ISSU process. You
can restore the timeout interval to its original value after completing the ISSU process.
• ISSU supports interval slow (every 30 seconds) for periodic transmission of Link
Aggregation Control Protocol (LACP) packets.
• ISSU supports Virtual Router Redundancy Protocol (VRRP) version 3.
ISSU do not support the following ACX5000 features:.
• Downgrade to an earlier version of Junos OS software. If you want to install an earlier

version of Junos OS software, use the request system software add CLI command.
• Upgrade of Host OS software.
• Connectivity fault management (CFM).
• TWAMP, RPF, RFC2544, and clocksyncd daemon (timing functionality).

• Mirroring and pseudowire cross connect.
• IPv6 firewall, IPv6 COS (classification and rewrite), IPv6 VPN, and VPLS mesh group.
• Virtual Router Redundancy Protocol (VRRP) version 1 and 2.
• Interval fast (every second) for periodic transmission of Link Aggregation Control
Protocol (LACP) packets. If the periodic interval fast is configured, then you may notice
traffic drops because of LACP links going down during ISSU. ACX5000 line of routers
can support LACP with fast hello by configuring the fast-hello-issu option (user@host#
set protocols lacp fast-hello-issu) on the main router and peer routers before starting
ISSU.
NOTE: The peer router must have Junos OS software to support this
functionality.
Upgrading the Software Using ISSU

This procedure describes how to upgrade the software running on a standalone router:
NOTE: If the Host OS software needs to be updated, you cannot perform an

ISSU. Instead, perform a standard software upgrade.
It is recommended to cleanup any unwanted data from the /var directory

(/var/log, /var/tmp) before initiating the ISSU process.
To upgrade the router using ISSU:
1. Download the software package from the Juniper Networks Support website
http://www.juniper.net/support/downloads/junos.html .
NOTE: To access the download site, you must have a service contract
with Juniper Networks and an access account. If you need help obtaining
an account, complete the registration form at the Juniper Networks website
https://www.juniper.net/registration/Register.jsp .
2. Go to ACX Series section and select the ACX5000 Series platform software you want
to download.
3. Copy the software package or packages to the router. We recommend that you copy
the file to the /var/tmp directory.
4. Log in to the console connection. Using a console connection allows you to monitor
the progress of the upgrade.
5. Start the ISSU:
• On the router, enter:

user@host> request system software in-service-upgrade

/var/tmp/package-name.tgz
where package-name.tgz is, for example,

jinstall-acx5k-15.1X54-D60.9-domestic-signed.tgz.
NOTE: During the upgrade, you will not be able to access the Junos OS
CLI.
The router displays status messages similar to the following messages as the upgrade
executes:
PRE ISSU CHECK:

---------------
PFE Status : Online
BFD minimum-interval check done : Valid
GRES enabled : Valid
NSR enabled : Valid
drop-all-tcp not configured : Valid
OVSDB not configured : Valid
warning: Do NOT use /user during ISSU. Changes to /user during ISSU may get
lost!
[Oct 24 00:25:37]:ISSU: Validating Image
[Oct 24 00:25:44]:ISSU: Preparing Backup RE
Prepare for ISSU
[Oct 24 00:25:49]:ISSU: Backup RE Prepare Done
Extracting jinstall-acx5k-15.1X54-D60.3-domestic ...
Install jinstall-acx5k-15.1X54-D60.3-domestic completed
Spawning the backup RE
Spawn backup RE, index 0 successful
GRES in progress
GRES done in 0 seconds
Waiting for backup RE switchover ready
GRES operational
Copying home directories
Copying home directories successful
Initiating Chassis In-Service-Upgrade
Chassis ISSU Started
[Oct 24 00:31:56]:ISSU: Preparing Daemons
[Oct 24 00:32:57]:ISSU: Daemons Ready for ISSU
[Oct 24 00:33:02]:ISSU: Starting Upgrade for FRUs
[Oct 24 00:33:23]:ISSU: FPC Warm Booting
[Oct 24 00:34:41]:ISSU: FPC Warm Booted
[Oct 24 00:34:51]:ISSU: Preparing for Switchover
[Oct 24 00:34:57]:ISSU: Ready for Switchover
Checking In-Service-Upgrade status
Item Status Reason
FPC 0 Online (ISSU)
Send ISSU done to chassisd on backup RE
Chassis ISSU Completed
[Oct 24 00:35:18]:ISSU: IDLE
Console and management sessions will be disconnected. Please login again.

NOTE: An ISSU might stop instead of abort if the FPC is at the warm boot
stage. Also, any links that go down and up will not be detected during a
warm boot of the Packet Forwarding Engine (PFE).
NOTE: If the ISSU process stops, you can look at the log files to diagnose
the problem. The log files are located at /var/log/vjunos-log.tgz.
6. Log in after the router reboots. To verify that the software has been upgraded, enter
the following command:
user@host> show version
7. Disable or delete the configuration done to enable the ISSU. This includes disabling
nonstop active routing (NSR), nonstop bridging (NBR) and graceful Routing Engine
(GRES).
Verifying a Unified ISSU

Verify the status of FPCs and their corresponding PICs after the most recent unified ISSU.
Issue the show chassis in-service-upgrade command on the master Routing Engine.
user@host> show chassis in-service-upgrade

Item Status Reason
FPC 0 Online
Display the unified ISSU process messages by using the show log messages command.
Related
Documentation


CHAPTER 3
Configuring Autoinstallation
• ACX Series Autoinstallation Overview on page 75

• Before You Begin Autoinstallation on an ACX Series Universal Access Router on page 77
• Autoinstallation Configuration of ACX Series Universal Access Routers on page 78
• Verifying Autoinstallation on ACX Series Universal Access Routers on page 79
• USB Autoinstallation on ACX Series Routers on page 80
• Autoinstallation on ACX Series Routers in Hybrid Mode Overview on page 81
• Prerequisites for Autoinstallation on ACX Series Routers in Hybrid Mode on page 83
• Autoinstallation Process on a New ACX Series Router in Hybrid Mode on page 84
• Configuring Autoinstallation of ACX Series Routers in Hybrid Mode on page 87
ACX Series Autoinstallation Overview
Autoinstallation provides automatic configuration for a new router that you connect to
the network and turn on, or for a router configured for autoinstallation. The autoinstallation
process begins anytime a router is powered on and cannot locate a valid configuration
file in the CompactFlash (CF) card. Typically, a configuration file is unavailable when a
router is powered on for the first time, or if the configuration file is deleted from the CF
card. The autoinstallation feature enables you to deploy multiple routers from a central
location in the network.
For the autoinstallation process to work, you must store one or more host-specific or
default configuration files on a configuration server in the network and have a service
available—typically Dynamic Host Configuration Protocol (DHCP)—to assign an IP address
to the router.
Autoinstallation takes place automatically when you connect an Ethernet on a new

Juniper Networks router to the network and power on the router. To simplify the process,
you can explicitly enable autoinstallation on a router and specify a configuration server,
an autoinstallation interface, and a protocol for IP address acquisition.
This topic describes:
• Supported Autoinstallation Interfaces and Protocols on page 76

• Typical Autoinstallation Process on a New Router on page 76

Supported Autoinstallation Interfaces and Protocols

Before autoinstallation on a router can take place, the router must acquire an IP address
or a USB key. The protocol or protocols you choose for IP address acquisition determine
the router interface to connect to the network for autoinstallation. The router detects
the connected interface and requests an IP address with a protocol appropriate for the
interface. Autoinstallation is supported over an Ethernet LAN interface. For IP address
acquisition, the ACX Series router uses DHCP, BOOTP, or Reverse Address Resolution
Protocol (RARP) on an Ethernet LAN interface.
If the server with the autoinstallation configuration file is not on the same LAN segment
as the new router, or if a specific router is required by the network, you must configure
an intermediate router directly attached to the new router, through which the new router
can send HTTP, FTP, Trivial File Transfer Protocol (TFTP), BOOTP, and Domain Name
System (DNS) requests. In this case, you specify the IP address of the intermediate router
as the location to receive HTTP, FTP, or TFTP requests for autoinstallation.
Typical Autoinstallation Process on a New Router

When a router is powered on for the first time, it performs the following autoinstallation
tasks:
1. The new router sends out DHCP, BOOTP, or RARP requests on each connected
interface simultaneously to obtain an IP address.
If a DHCP server responds, it provides the router with some or all of the following
information:
• An IP address and subnet mask for the autoinstallation interface.
• The location of the TFTP (typically), Hypertext Transfer Protocol (HTTP), or FTP
server on which the configuration file is stored.
• The name of the configuration file to be requested from the HTTP, FTP, or TFTP
server.
• The IP address or hostname of the HTTP, FTP, or TFTP server.
If the DHCP server provides only the hostname, a DNS server must be available on
the network to resolve the name to an IP address.
• The IP address of an intermediate router if the configuration server is on a different

LAN segment from the new router.
2. After the new router acquires an IP address, the autoinstallation process on the router
attempts to download a configuration file in the following ways:
a. If the configuration file is specified as a URL, the router fetches the configuration
file from the URL by using HTTP, FTP, or TFTP depending on the protocol specified
in the URL.
b. If the DHCP server specifies the host-specific configuration file (boot file)
hostname.conf, the router uses that filename in the TFTP server request. (In the
filename, hostname is the hostname of the new router.) The autoinstallation process

Chapter 3: Configuring Autoinstallation
on the new router makes three unicast TFTP requests for hostname.conf. If these
attempts fail, the router broadcasts three requests to any available TFTP server
for the file.
c. If the new router cannot locate hostname.conf, the autoinstallation process unicasts
or broadcasts TFTP requests for a default router configuration file called
network.conf, which contains hostname-to-IP address mapping information, to
attempt to find its hostname.
d. If network.conf contains no hostname entry for the new router, the autoinstallation
process sends out a DNS request and attempts to resolve the new router’s IP
address to a hostname.
e. If the new router can determine its hostname, it sends a TFTP request for the
hostname.conf file.
f. If the new router is unable to map its IP address to a hostname, it sends TFTP
requests for the default configuration file router.conf.
3. After the new router locates a configuration file on a TFTP server, autoinstallation
downloads the file, installs the file on the router, and commits the configuration.
Related • Before You Begin Autoinstallation on an ACX Series Universal Access Router on page 77
Documentation
• autoinstallation on page 1442
• show system autoinstallation status on page 3178
Before You Begin Autoinstallation on an ACX Series Universal Access Router
To configure a router for autoinstallation, complete the following tasks:
• Make sure you have a DHCP server on your network to meet your network requirements.
• Create one of the following configuration files and store it on an HTTP, FTP, or TFTP
server in the network:
• A host-specific file with the name hostname.conf for each router undergoing
autoinstallation. Replace hostname with the name of a router. The hostname.conf
file typically contains all the configuration information necessary for the router with
this hostname.
• A default configuration file named router.conf with the minimum configuration

necessary to enable you to telnet into the new router for further configuration.

• Physically attach the router to the network using a Gigabit Ethernet interface.
• If you configure the DHCP server to provide only the HTTP, FTP, or TFTP server
hostname, add an IP address-to-hostname mapping entry for the HTTP, FTP, or TFTP
server to the DNS database file on the DNS server in the network.
• If the new router is not on the same network segment as the DHCP server (or other
router providing IP address resolution), configure an existing router as an intermediate
to receive HTTP, FTP, or TFTP and DNS requests and forward them to the HTTP, FTP,
or TFTP and DNS servers. You must configure the LAN on the intermediate router with
the IP addresses of the hosts providing HTTP, FTP, or TFTP and DNS service. Connect
this interface to the new router.
• If you are using hostname.conf files for autoinstallation of host-specific configuration

files, you must also complete the following tasks:
• Configure the DHCP server to provide a hostname.conf filename to each new router.
Each router uses its hostname.conf filename to request a configuration file from the
TFTP server. Copy the necessary hostname.conf configuration files to the TFTP server.
• Create a default configuration file named network.conf and copy it to the TFTP server.
This file contains IP address-to-hostname mapping entries. If the DHCP server does
not send a hostname.conf filename to a new router, the router uses network.conf to
resolve its hostname based on its IP address.
Alternatively, you can add the IP address-to-hostname mapping entry for the new
router to a DNS database file.
The router uses the hostname to request a hostname.conf file from the server.
Related • ACX Series Autoinstallation Overview on page 75

Documentation
Autoinstallation Configuration of ACX Series Universal Access Routers
No configuration is required on a router on which you are performing autoinstallation

because it is an automated process. However, to simplify the process, you can specify
one or more interfaces, protocols, and configuration servers to be used for autoinstallation.
To configure autoinstallation:
1. Specify the URL address of one or more servers from which to obtain configuration
files.
[edit system]

user@host# set autoinstallation configuration-servers tftp://tftpconfig.sp.com
NOTE: You can also use an HTTP or FTP address—for example,

http://user:password@httpconfig.sp.com or
ftp://user:password@sftpconfig.sp.com.
2. Configure one or more Ethernet interfaces to perform autoinstallation and IP address

acquisition protocols for each interface. The router uses the protocols to send a request
for an IP address for the interface:
[edit system]
user@host# set autoinstallation interfaces ge-0/0/0 bootp

Documentation
Verifying Autoinstallation on ACX Series Universal Access Routers
Purpose After you have configured autoinstallation, display the status of autoinstallation on an
ACX Series router.
Action From the CLI, enter the show system autoinstallation status command.
Sample Output
user@host> show system autoinstallation status

Autoinstallation status:
Master state: Active
Last committed file: None
Configuration server of last committed file: 10.25.100.1
Interface:
Name: ge-0/1/0
State: Configuration Acquisition
Acquired:
Address: 192.168.124.75
Hostname: host-ge-000
Hostname source: DNS
Configuration filename: router-ge-000.conf
Configuration filename server: 10.25.100.3
Address acquisition:
Protocol: DHCP Client
Acquired address: None

Protocol: RARP Client

Interface:
Name: ge-0/1/1
State: None
Protocol: DHCP Client
Meaning The output shows the settings configured for autoinstallation. Verify that the values
displayed are correct for the router when it is deployed on the network.

Documentation
USB Autoinstallation on ACX Series Routers
If you have a new ACX Series router, you can use a Disk-on-Key USB memory stick (“USB
key”) to configure the router.
This configuration method has the following requirements:
• A management device (PC or laptop).
• A Disk-on-Key device with one of the following 16-bit or 32-bit file allocation table
(FAT) file systems:
• DOS 3.0+ 16-bit FAT (up to 32 MB)
• DOS 3.31+ 16-bit FAT (over 32 MB)
• FAT32
• FAT32, LBA-mapped
• 16-bit FAT, LBA-mapped
• An ACX Series router with the factory configuration. If other Junos OS configuration
files exist on the router, the router cannot read the juniper-config.txt file from the
Disk-on-Key device.

NOTE: The USB-based autoinstallation process overrides the

network-based autoinstallation process. If the ACX Series router detects
a USB Disk-on-Key device containing a valid configuration file during
autoinstallation, it configures the router using the configuration file on
Disk-on-Key instead of fetching the configuration from the network.
To configure an ACX Series router using Disk-on-Key:
1. Using a text editor on a PC or laptop, create the configuration file, named

juniper-config.txt, as a sequence of configuration commands (“set” commands). To
reuse configuration from another ACX Series router, the configuration can be saved
in configuration mode as a sequence of configuration commands on the router using
the “show | display set | save <filename>” command and then copying the <filename>
to the PC or router as juniper-config.txt.
2. Copy the juniper-config.txt file to a Disk-on-Key device.
3. Plug the Disk-on-Key device into the USB port on the new ACX Series router.
4. Power on the router by pressing the POWER button on the front panel. Wait for the
router to start and access the Disk-on-Key device (observe the LEDs on the Disk-on-Key
device).
The router reads the juniper-config.txt file from the Disk-on-Key device and commits
the configuration.
5. Remove the Disk-on-Key device from the router.
6. The configuration of the router is complete.

Documentation
Autoinstallation on ACX Series Routers in Hybrid Mode Overview
The ACX Series router has an autoinstallation mechanism that allows the router to
configure itself out-of-the-box with no manual intervention, using the configuration

available either on the network, locally through a removable media, or a combination of

both.
Autoinstallation process delivers the following benefits:
• The router can be sent from the warehouse to the deployment site without any
pre-configuration steps.
• The procedure required to deploy the device at the cell site is simplified, resulting in
reduced operational and administrative costs.
• You can roll out large numbers of these devices in a very short time.
ACX Series routers support the retrieval of partial configuration from an external USB
storage device plugged into the router’s USB port during the autoinstallation process.
This partial configuration in turn facilitates the network mode of autoinstallation to
retrieve the complete configuration file from the network. This method is called hybrid
mode of autoinstallation.
Autoinstallation process operates in three modes:
• USB mode—Autoinstallation obtains the required configuration from the configuration

file saved in an external USB storage device plugged into the router.
• Network Mode—Autoinstallation triggers IP address acquisition mechanism (the router

sends out DHCP or RARP requests on each connected interface simultaneously) to
obtain an IP address. Once the router has an IP address, it sends a request to the
specified configuration server and downloads and installs the configuration.
• Hybrid mode—Autoinstallation obtains partial configuration from an external USB

storage device and uses that configuration to obtain the complete configuration file
in network mode. This mode is a combination of USB mode and Network mode.
On the different ACX Series routers, autoinstallation is supported on the following Gigabit
Ethernet (ge) and 10- Gigabit Ethernet (xe) interfaces:
• On ACX1000 routers, interfaces ge-0/1/0 through ge-0/1/7, and ge-0/2/0 through

ge-0/2/3
• On ACX1100 routers, interfaces ge-0/0/0 through ge-0/0/7, and ge-0/1/0 through

ge-0/1/3
• On ACX2000 routers, interfaces ge-0/1/0 through ge-0/1/7, ge-0/2/0 through ge-0/2/1,

and xe-0/3/0 through xe-0/3/1
• On ACX2100 routers, interfaces ge-1/0/0 through ge-1/0/3, ge-1/1/0 through ge-1/1/3,

ge-1/2/0 through ge-1/2/1, and xe-1/3/0 through xe-1/3/1
• On ACX2200 routers, interfaces ge-0/0/0 through ge-0/0/3, ge-0/1/0 through

ge-0/1/3, ge-0/2/0 through ge-0/2/1, and xe-0/3/0 through xe-0/3/1
• On ACX4000 routers, interfaces ge-0/0/0 through ge-0/0/7, ge-0/1/0 through

ge-0/1/1, ge-1/0/0 through ge-1/0/5, ge-1/1/0 through ge-1/1/5 , and xe-0/2/0 through
xe-0/2/1


Documentation
Prerequisites for Autoinstallation on ACX Series Routers in Hybrid Mode
Before you perform autoinstallation on a router in hybrid mode, complete the following
tasks:
Using a text editor on a PC or laptop, create the configuration file, named juniper-config.txt,
as a sequence of configuration commands (“set” commands). To reuse configuration
from another ACX Series router, the configuration can be saved in configuration mode
as a sequence of configuration commands on the router using the “show | display set |
save <filename>” command and then copying the <filename> to the PC or router as
juniper-config.txt.
You must copy the juniper-config.txt file to an external USB storage device. Plug the USB
device into the USB port on the new ACX Series router. When you power on the router,
the router first attempts to access the external USB storage device. The router reads the
juniper-config.txt file from the external USB storage device and commits the configuration.
NOTE: For autoinstallation process to switch to the network mode, the

continue-network-mode statement must be present in the autoinstallation
stanza at the [edit system autoinstallation] hierarchy level of the
juniper-config.txt configuration file. The presence of the
continue-network-mode statement in the juniper-config.txt file causes the
router to consider it as a partial configuration. Otherwise, if the
continue-network-mode statement is not present in the juniper-config.txt file,
the router considers the configuration on the external USB storage device as
the complete configuration and it will not switch to the network mode.
Perform all of the steps described in the “Before You Begin Autoinstallation on an ACX
Series Universal Access Router” on page 77 section, which prepares the router for
network-based autoinstallation.


Documentation
Autoinstallation Process on a New ACX Series Router in Hybrid Mode
You can perform autoinstallation on a new ACX Series router in hybrid mode, which is a
combination of the USB-based autoinstallation process and the network-based
autoinstallation process.
This configuration method has the following requirements:
• A management device (PC or laptop).
• An external USB storage device with one of the following 16-bit or 32-bit file allocation
table (FAT) file systems:
• DOS 3.0+ 16-bit FAT (up to 32 MB)
• DOS 3.31+ 16-bit FAT (over 32 MB)
• FAT32
• FAT32, LBA-mapped
• 16-bit FAT, LBA-mapped
BOOTP, RARP and DHCP are the supported protocols for acquisition of IP address of
the router and TFTP, FTP, and HTTP are the supported protocols for downloading the
configuration file from an external server URL on which the configuration file is stored.
The following operations occur during autoinstallation in hybrid mode on ACX Series
routers:

1. When a new ACX Series router is powered on for the first time, the router performs
the following autoinstallation tasks: The router boots the Junos OS image. The
management process (mgd) is invoked and it determines whether a valid configuration
exists on the router’s Flash memory. If a valid configuration is not present on the router,
it loads and commits the factory-default configuration.
2. If the factory-default configuration contains the autoinstallation configuration stanza

at the [edit system] hierarchy level, the autoinstallation process is triggered.
3. The autoinstallation process detects whether an external USB storage device is

connected to the router and examines whether the USB device contains a valid
configuration file. If the USB storage device contains a configuration file named
juniper-config.txt, the router reads the juniper-config.txt file and commits the
configuration.
4. If the juniper-config.txt file on the external USB storage device contains

continue-network-mode statement, the configuration is treated as partial configuration.
The autoinstallation process uses this partial configuration to obtain the complete
configuration file from a server on the network. At this stage, the router completes
the USB mode of the autoinstallation procedure and switches to the network mode
of the autoinstallation procedure.
NOTE: The continue-network-mode statement must be present in the

autoinstallation stanza at the [edit system autoinstallation] hierarchy level
of the juniper-config.txt file.
5. After acquiring the partial configuration from the juniper-config.txt file, the configuration
discovery procedure is initiated. For all physical Ethernet interfaces that transition to
the up state, the autoinstallation process verifies whether autoinstallation is configured
on that Ethernet interface. The autoinstallation process starts IP address acquisition
mechanism to obtain IP address of the server followed by the configuration file retrieval
mechanism.
6. For the interfaces that take part in the autoinstallation process, the IPv4 address
discovery procedure is triggered. The new ACX Series router sends out DHCP, or
BOOTP, or RARP requests on each connected interface simultaneously to obtain an
IP address. The interfaces statement in the autoinstallation configuration stanza at
the [edit system] hierarchy level in the factory-default configuration also specify the
protocols to be used for IPv4 address discovery. If the interfaces statement is not
configured, all the applicable protocols for an interface are used to send out requests
on each connected Ethernet interface.
7. If an IPv4 address cannot be retrieved, the autoinstallation process starts the DHCP
server on all participating interfaces (assigns static IP address in the form of 192.168.x.1
to allow a management station to connect to the router for manual configuration)
and terminates the autoinstallation procedure.
8. If a DHCP server responds, it provides the router with some or all of the following
information:

• An IP address and subnet mask for the autoinstallation interface.
• The location of the TFTP server on which the configuration file is stored.
• The name of the configuration file to be requested from the TFTP server.
• The IP address or hostname of the TFTP server.
• If the DHCP server provides configuration server hostname, a DNS server must be
available on the network to resolve the name to an IP address.
• The IP address of an intermediate router if the configuration server is on a different

LAN segment from the new router.
NOTE: To use HTTP or FTP server, you need to specify the URL of the
configuration server under the [edit system autoinstallation
configuration-servers] hierarchy level.
9. After an IPv4 address is retrieved for an interface, the interface is configured with that
address and the autoinstallation process starts the configuration file discovery
procedure. The autoinstallation process on the router attempts to download a
configuration file in the following methods:
a. If the configuration file is specified as a URL, the router fetches the configuration
file from the URL by using HTTP, FTP, or TFTP depending on the protocol specified
in the URL.
b. If the DHCP server specifies the host-specific configuration file (either through file
field option or boot file option or host name), the router uses that filename in the
TFTP server request. In case of host name, the configuration filename is
hostname.conf. The autoinstallation process on the new router makes unicast
TFTP request for hostname.conf. If this attempt fails, the router broadcasts the
request to any available TFTP server for the configuration file.
c. If the new router is unable locate the configuration file, the autoinstallation process
unicasts or broadcasts TFTP requests for a default router configuration file called
network.conf, which contains hostname-to-IP address mapping information, to
attempt to find its hostname.
d. If network.conf contains no hostname entry for the new router, the autoinstallation
process sends out a DNS request and attempts to resolve the new router’s IP
address to a hostname.
e. If the new router can determine its hostname, it sends a TFTP request for the
hostname.conf file.
f. If the new router is unable to map its IP address to a hostname, it sends TFTP
requests for the default configuration file router.conf.

NOTE: The autoinstallation process makes a maximum of three

attempts to retrieve the configuration file by repeating the methods
listed above (b to f). In case the autoinstallation process fails to retrieve
the configuration file after three attempts, the autoinstallation process
goes to start state.
g. After the new router locates a configuration file on a TFTP server, autoinstallation
downloads the file, installs the file on the router, and commits the configuration.

Documentation
Configuring Autoinstallation of ACX Series Routers in Hybrid Mode
To configure the router for autoinstallation in hybrid mode, perform the following tasks:
Create a configuration file as juniper-config.txt.
1. Using a text editor on a PC or laptop, create the configuration file, named

juniper-config.txt. This configuration file must contain a sequence of configuration
commands (“set” commands).
NOTE: To reuse a configuration from another ACX Series router, save the
configuration in configuration mode as a sequence of configuration
commands on the router using the “show | display set | save <filename>”
command and then copying the <filename> to the PC or router as
juniper-config.txt.
2. Include the continue-network-mode statement at the [edit system autoinstallation]

hierarchy level in the juniper-config.txt configuration file. The presence of the
continue-network-mode statement causes the router to consider it as a partial

configuration and the autoinstallation process switches to network mode to retrieve

the complete configuration from a network server.
[edit system]
user@host# set autoinstallation continue-network-mode
3. Specify the URL address of one or more network servers from which to obtain the
complete configuration.
[edit system]
user@host# set autoinstallation configuration-servers
tftp://username:password@tftpconfig.sp.com/filename.conf
NOTE: You can also use an HTTP or FTP address—for example,

http://user:password@httpconfig.sp.com/filename.conf or
ftp://user:password@sftpconfig.sp.com/filename.conf.
4. Specify the root authentication password.
[edit system]
user@host# set root-authentication encrypted-password “password”;
5. Configure one or more Ethernet interfaces to perform autoinstallation and IP address

acquisition protocols for each interface. The router uses the protocols to send a request
for an IP address for the interface:
[edit system]
user@host# set autoinstallation interfaces ge-0/0/0 bootp
NOTE: Configuring an interface is optional. If an interface is configured,

then autoinstallation process is triggered on the configured interface only.
If an interface is not configured, then autoinstallation process is triggered
on all the interfaces that are physically in link up state.
6. Copy the juniper-config.txt file to an external USB storage device.
7. Plug the external USB storage device to the router’s USB port.
From configuration mode, confirm your configuration by entering the show system
autoinstallation status command. If the output does not display the intended configuration,
repeat the configuration instructions in this example to correct it.
user@host> show system autoinstallation status
Autoinstallation status:
Master state: Active
Last committed file: None

Configuration server of last committed file: 10.25.100.1

Interface:
Name: ge-0/0/0
State: Configuration Acquisition
Acquired:
Address: 192.168.124.75
Hostname: host-ge-000
Hostname source: DNS
Configuration filename: router-ge-000.conf
Configuration filename server: 10.25.100.3
Protocol: BOOTP Client

Documentation


PART 3
Configuring Interfaces and Chassis on ACX

Series Routers
• Configuring Interfaces and Chassis on page 93
• Configuring E1 and T1 Interfaces on page 165
• Configuring ATM Interfaces on page 173
• Configuring SAToP Support on Interfaces on page 191
• Configuring CESoPSN Support on Interfaces on page 205
• Configuring Timing and Synchronization on page 223


CHAPTER 4
Configuring Interfaces and Chassis

• Configuring the Media MTU on ACX Series Routers on page 97
• Understanding the Loopback Interface on page 100
• Configuring the Loopback Interface on page 101
• Understanding Encapsulation on an Interface on page 104
• Gigabit Ethernet Autonegotiation Overview on page 104
• BERT Support on CT1 and CE1 Interfaces on page 105
• Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP
Overview on page 106
• 16-Port Channelized E1/T1 Circuit Emulation MIC Overview on page 106
• Synchronous Ethernet Overview on the ACX Series Universal Access Routers on page 107
• TDM CESoPSN Overview on page 108
• Configuring TDM CESoPSN on ACX Series Routers Overview on page 108
• SAToP Emulation on T1 and E1 Interfaces Overview on page 110
• Ethernet Ring Protection Switching Overview on page 111
• Understanding Ethernet Ring Protection Switching Functionality on page 112
• Configuring Ethernet Ring Protection Switching on page 118
• Example: Ethernet Ring Protection Switching Configuration on ACX Series
Routers on page 119
• Example: Viewing Ethernet Ring Protection Status—Normal Ring Operation on page 127
• Example: Viewing Ethernet Ring Protection Status—Ring Failure Condition on page 129
• Guidelines for Ethernet Ring Protection Switching on ACX Series Routers on page 131
• Dual-Rate SFP+ Optic Modules for ACX Series Routers on page 134
• Tri-Rate SFP for ACX5000 Series Routers on page 135
• Configuring Logical Tunnel Interfaces on page 136
• Guidelines for Configuring Logical Tunnels on ACX Series Routers on page 137
• Configuring an Interface in the VRF Domain to Receive Multicast Traffic on page 140
• Understanding PoE on ACX Series Universal Access Routers on page 142

• Example: Configuring PoE on ACX2000 Routers on page 144

• Example: Disabling a PoE Interface on ACX2000 Routers on page 149
• Configuring a Service Package to be Used in Conjunction with PTP on page 150
• Checklist for Monitoring Fast Ethernet and Gigabit Ethernet Interfaces on page 150
• Checklist for Monitoring T1 Interfaces on page 151
• Understanding Ethernet Link Aggregation on ACX Series Routers on page 152
• User-Defined Alarm Relay Overview on page 158
• Configuring Chassis Alarm Relays on page 159
• Configuring Chassis Alarm Input on page 160
• Configuring Chassis Alarm Output on page 161
• Chassis Definitions for Router Model MIB for ACX Series Routers on page 162
Understanding Interfaces on ACX Series Universal Access Routers
The ACX Series routers support time-division multiplexing (TDM) T1 and E1 interfaces
and Ethernet (1 GbE copper, 1GbE, 10 GbE, and 40 GbE fiber) interfaces to support both
the legacy and evolution needs of the mobile network. Support for Power over Ethernet
(PoE+) at 65 watts per port mitigates the need for additional electrical cabling for
microwaves or other access interfaces.
The ACX Series routers support the following:
• TDM T1 and E1 ports:
• The ACX1000 router contains eight T1 or E1 ports.
• The ACX2000 router contains 16 T1 or E1 ports.
• Inverse Multiplexing for ATM (IMA)
NOTE: ACX5048 and ACX5096 routers do not support T1 or E1 ports and

Inverse Multiplexing for ATM (IMA).
• Gigabit Ethernet ports:
• The ACX1000 router contains eight Gigabit Ethernet ports. The ACX1000 router also
supports either four RJ45 (Cu) ports or installation of four Gigabit Ethernet small
form-factor pluggable (SFP) transceivers.
• The ACX2000 router contains 16 Gigabit Ethernet ports and two PoE ports. The
ACX2000 router also supports installation of two Gigabit Ethernet SFP transceivers
and two 10-Gigabit Ethernet SFP+ transceivers.
NOTE: 40GbE is supported only on ACX5048 and ACX5096 routers.

Chapter 4: Configuring Interfaces and Chassis
T1 and E1 Time-Division Multiplexing (TDM) Interfaces

On the ACX Series routers, existing Junos OS TDM features are supported without changes
to statements or functionality. The following key TDM features for T1 (ct1) interfaces and
E1 (ce1) interfaces are supported:
• T1 and E1 channelization
• T1 and E1 encapsulation
• Alarms, defects, and statistics
• External and internal loopback
• TDM class of service (CoS)
T1 and E1 mode selection is at the PIC level. To set the T1 or E1 mode at the PIC level,
include the framing statement with the t1 or e1 option at the [chassis fpc slot-number pic
slot-number] hierarchy level. All ports can be T1 or E1. Mixing T1s and E1s is not supported.
T1 or E1 BITS Interface (ACX2000)
The ACX2000 router has a T1 or E1 building-integrated timing supply (BITS) interface

that you can connect to an external clock. After you connect the interface to the external
clock, you can configure the BITS interface so that the BITS interface becomes a candidate
source for chassis synchronization to the external clock. The frequency of the BITS
interface depends on the Synchronous Ethernet equipment slave clock (EEC) selected
with the network-option statement at the [edit chassis synchronization] hierarchy level.
NOTE: The ACX1000 router does not support the BITS interface.
Inverse Multiplexing for ATM (IMA)

Defined by the ATM Forum, IMA specification version 1.1 is a standardized technology
used to transport ATM traffic over a bundle of T1 and E1 interfaces, also known as an IMA
group. Up to eight links per bundle and 16 bundles per PIC are supported. The following
key IMA features are supported:
• IMA Layer 2 encapsulation
• ATM CoS
• ATM policing and shaping
• Denied packets counter in the output for the show interfaces at-fpc/pic/port extensive
command
Gigabit Ethernet interfaces

On the ACX Series routers, existing Junos OS Ethernet features are supported without
changes to statements or functionality. The following key features are supported:

• Media type specification (ACX1000 router with Gigabit Ethernet SFP and RJ45
interfaces)
• Autonegotiation for RJ45 Gigabit Ethernet interfaces
• Event handling of SFP insertion and removal
• Explicit disabling of the physical interface
• Flow control
NOTE: The ACX Series router does not support flow control based on
PAUSE frames.
• Loopback
• Loss of signal (LOS) alarm
• Media access control (MAC) layer features
• Maximum transmission unit (MTU)
• Remote fault notification for 10-Gigabit Ethernet interfaces
• Statistics collection and handling
• Power over Ethernet (PoE) (ACX2000 router)
• High power mode
The Gigabit Ethernet ports on the router have the capacity to work as a 1 or 10-Gigabit
Ethernet interface, depending on the type of small form-factor pluggable (SFP)
transceiver inserted. When you insert an SFP+ transceiver, the interface works at the
10-Gigabit speed. When you insert an SFP transceiver, the interface works at the 1-Gigabit
speed. Configuration is not required because the speed is determined automatically
based on the type of inserted SFP transceiver. The dual-speed interface is automatically
created with the xe prefix, for example, xe-4/0/0.
The same configuration statements are used for both speeds and CoS parameters are
scaled as a percentage of the port speed. To configure a dual-speed Gigabit Ethernet
interface, include the interface xe-fpc/pic/port statement at the [edit interfaces] hierarchy
level. To display the interface speed and other details, issue the show interfaces command.
NOTE: You need to use industrial grade of SFP below 0dC for ACX 1100 and
ACX 2100 boards.
Related • Understanding Encapsulation on an Interface on page 104

Documentation
• Configuring Inverse Multiplexing for ATM (IMA) on page 185
• Interface Names for ACX Series Universal Access Routers

Configuring the Media MTU on ACX Series Routers
• Media MTU Overview on page 97

• How to Configure the Media MTU on page 98
• Encapsulation Overhead by Encapsulation Type on page 98
• Media MTU Sizes by Interface Type for ACX Series Routers on page 99
Media MTU Overview

The default media MTU size used on a physical interface depends on the encapsulation
used on that interface. In some cases, the default IP Protocol MTU depends on whether
the protocol used is IP version 4 (IPv4) or International Organization for Standardization
(ISO).
The default media MTU is calculated as follows:
Default media MTU = Default IP MTU + encapsulation overhead
When you are configuring point-to-point connections, the MTU sizes on both sides of the
connections must be the same. Also, when you are configuring point-to-multipoint
connections, all interfaces in the subnet must use the same MTU size. For details about
encapsulation overhead, see “Encapsulation Overhead by Encapsulation Type” on page 98.
NOTE: The actual frames transmitted also contain cyclic redundancy check
(CRC) bits, which are not part of the media MTU. For example, the media
MTU for a Gigabit Ethernet Version 2 interface is specified as 1514 bytes, but
the largest possible frame size is actually 1518 bytes; you need to consider
the extra bits in calculations of MTUs for interoperability.
The physical MTU for Ethernet interfaces does not include the 4-byte frame
check sequence (FCS) field of the Ethernet frame.
If you do not configure an MPLS MTU, the Junos OS derives the MPLS MTU
from the physical interface MTU. From this value, the software subtracts the
encapsulation-specific overhead and space for the maximum number of
labels that might be pushed in the Packet Forwarding Engine. Currently, the
software provides for three labels of four bytes each, for a total of 12 bytes.
In other words, the formula used to determine the MPLS MTU is the following:
MPLS MTU = physical interface MTU – encapsulation overhead – 12
If you configure an MTU value by including the mtu statement at the [edit
interfaces interface-name unit logical-unit-number family mpls] hierarchy level,
the configured value is used.

How to Configure the Media MTU

To modify the default media MTU size for a physical interface, include the mtu statement
at the [edit interfaces interface-name] hierarchy level:
[edit interfaces interface-name]

mtu bytes;
If you change the size of the media MTU, you must ensure that the size is equal to or
greater than the sum of the protocol MTU and the encapsulation overhead.
NOTE: Changing the media MTU or protocol MTU causes an interface to be

deleted and added again.
You configure the protocol MTU by including the mtu statement at the following hierarchy
levels:
• [edit interfaces interface-name unit logical-unit-number family inet]
• [edit interfaces interface-name unit logical-unit-number family inet6]
If you configure the protocol MTU at any of these hierarchy levels, the configured value
is applied to all families that are configured on the logical interface.
NOTE: If you are configuring the protocol MTU for both inet and inet6 families
on the same logical interface, you must configure the same value for both
the families. It is not recommended to configure different MTU size values
for inet and inet6 families that are configured on the same logical interface.
Encapsulation Overhead by Encapsulation Type
Table 16: Encapsulation Overhead by Encapsulation Type

Interface Encapsulation Encapsulation Overhead (Bytes)
802.1Q/Ethernet 802.3 21
802.1Q/Ethernet Subnetwork Access Protocol (SNAP) 26
802.1Q/Ethernet version 2 18
ATM Cell Relay 4
ATM permanent virtual connection (PVC) 12
Cisco HDLC 4
Ethernet 802.3 17

Table 16: Encapsulation Overhead by Encapsulation Type (continued)

Interface Encapsulation Encapsulation Overhead (Bytes)
Ethernet circuit cross-connect (CCC) and virtual private 4

LAN service (VPLS)
Ethernet over ATM 32
Ethernet SNAP 22
Ethernet translational cross-connect (TCC) 18
Ethernet version 2 14
Extended virtual local area network (VLAN) CCC and 4

VPLS
Extended VLAN TCC 22
Frame Relay 4
PPP 4
VLAN CCC 4
VLAN VPLS 4
VLAN TCC 22
Media MTU Sizes by Interface Type for ACX Series Routers
Table 17: Media MTU Sizes by Interface Type for ACX Series Routers
Default Media Maximum MTU Default IP Protocol
Interface Type MTU (Bytes) (Bytes) MTU (Bytes)
Gigabit Ethernet 1514 9192 1500 (IPv4),

1497 (ISO)
10-Gigabit Ethernet 1514 9192 1500 (IPv4),

1497 (ISO)
Related • Configuring Interface Encapsulation on Physical Interfaces

Documentation
• Setting the Protocol MTU

Understanding the Loopback Interface
The loopback address (lo0) has several uses, depending on the particular Junos feature
being configured. It can perform the following functions:
• Device identification—The loopback interface is used to identify the device. While any
interface address can be used to determine if the device is online, the loopback address
is the preferred method. Whereas interfaces might be removed or addresses changed
based on network topology changes, the loopback address never changes.
When you ping an individual interface address, the results do not always indicate the
health of the device. For example, a subnet mismatch in the configuration of two
endpoints on a point-to-point link makes the link appear to be inoperable. Pinging the
interface to determine whether the device is online provides a misleading result. An
interface might be unavailable because of a problem unrelated to the device's
configuration or operation.
• Routing information—The loopback address is used by protocols such as OSPF to

determine protocol-specific properties for the device or network. Further, some
commands such as ping mpls require a loopback address to function correctly.
• Packet filtering—Stateless firewall filters can be applied to the loopback address to

filter packets originating from, or destined for, the Routing Engine.
The Internet Protocol (IP) specifies a loopback network with the (IPv4) address
127.0.0.0/8. Most IP implementations support a loopback interface (lo0) to represent
the loopback facility. Any traffic that a computer program sends on the loopback network
is addressed to the same computer. The most commonly used IP address on the loopback
network is 127.0.0.1 for IPv4 and ::1 for IPv6. The standard domain name for the address
is localhost.
The device also includes an internal loopback address (lo0.16384). The internal loopback
address is a particular instance of the loopback address with the logical unit number
16384. Junos OS creates the loopback interface for the internal routing instance. This
interface prevents any filter on lo0.0 from disrupting internal traffic.
NOTE: Starting with Junos OS Release 15.1X49-D10, the special loopback

interface is no longer supported on SRX300, SRX320, SRX340, SRX345, and
SRX550HM devices. Refer Special Interfaces for more details on special
loopback interface.

Release History Table Release Description
15.1X49-D10 Starting with Junos OS Release 15.1X49-D10, the special loopback interface
is no longer supported on SRX300, SRX320, SRX340, SRX345, and
SRX550HM devices. Refer Special Interfaces for more details on special
loopback interface.
Related • Configuring a Loopback Interface

Documentation
• Understanding Interfaces
• Understanding Management Interfaces
• Understanding the Discard Interface
Configuring the Loopback Interface
• Configuring the Loopback Interface on page 101

• Example: Configuring Two Addresses on the Loopback Interface with Host
Routes on page 102
• Example: Configuring Two Addresses on the Loopback Interface with Subnetwork
Routes on page 103
• Example: Configuring an IPv4 and an IPv6 Address on the Loopback Interface with
Subnetwork Routes on page 103
Configuring the Loopback Interface

When specifying the loopback address, do not include a destination prefix. Also, in most
cases, do not specify a loopback address on any unit other than unit 0.
NOTE: For Layer 3 virtual private networks (VPNs), you can configure multiple
logical units for the loopback interface. This allows you to configure a logical
loopback interface for each virtual routing and forwarding (VRF) routing
instance. For more information, see the Junos OS VPNs Library for Routing
Devices.
For some applications, such as SSL for Junos XML protocol, the address for
the interface lo0.0 must be 127.0.0.1.
You can configure loopback interfaces using a subnetwork address for both inet and
inet6 address families. Many protocols require a subnetwork address as their source
address. Configuring a subnetwork loopback address as a donor interface enables these
protocols to run on unnumbered interfaces.
If you configure the loopback interface, it is automatically used for unnumbered interfaces.
If you do not configure the loopback interface, the router chooses the first interface to
come online as the default. If you configure more than one address on the loopback

interface, we recommend that you configure one to be the primary address to ensure
that it is selected for use with unnumbered interfaces. By default, the primary address is
used as the source address when packets originate from the interface.
For more information about unnumbered interfaces, see Configuring an Unnumbered

Interface. For more information about primary addresses, see Configuring the Interface
Address.
On the router, you can configure one physical loopback interface, lo0, and one or more
addresses on the interface.
1. To configure the physical loopback interface, include the following statements at the
[edit interfaces] hierarchy level:
[edit interfaces]
lo0 {
unit 0 {
family inet {
address loopback-address;
address <loopback-address2>;
...
}
family inet6 {
address loopback-address;
}
}
}
Example: Configuring Two Addresses on the Loopback Interface with Host Routes
To configure two addresses on the loopback interface with host routes:
[edit]
user@host# edit interfaces lo0 unit 0 family inet
[edit interfaces lo0 unit 0 family inet]
user@host# set address 172.16.0.1
user@host# set address 10.0.0.1
user@host# top
[edit]
user@host# show
interfaces {
lo0 {
unit 0 {
family inet {
10.0.0.1;
127.0.0.1;
172.16.0.1;
}
}
}
}

Example: Configuring Two Addresses on the Loopback Interface with Subnetwork Routes
To configure two addresses on the loopback interface with subnetwork routes:
[edit]
user@host# set address 192.16.0.1/24
user@host# top
[edit]
user@host# show
interfaces {
lo0 {
unit 0 {
family inet {
10.2.0.1/16;
127.0.0.1/32;
192.16.0.1/24;
}
}
}
}
Example: Configuring an IPv4 and an IPv6 Address on the Loopback Interface with Subnetwork
Routes
To configure an IPv4 and an IPv6 address on the loopback interface with subnetwork
routes:
[edit]
user@host# up
[edit interfaces lo0 unit 0 family]
user@host# edit interfaces lo0 unit 0 family inet6
[edit interfaces lo0 unit 0 family inet6]
user@host# set address 3ffe::1:200:f8ff:fe75:50df/64
[edit interfaces lo0 unit 0 family inet6]
user@host# top
[edit]
user@host# show
interfaces {
lo0 {
unit 0 {
family inet {
127.0.0.1/32;
192.16.0.1/24;
}
family inet6 {

3ffe::1:200:f8ff:fe75:50df/64;
}
}
}
}
Related • Junos OS VPNs Library for Routing Devices

Documentation
• Configuring an Unnumbered Interface
• Configuring the Interface Address
Understanding Encapsulation on an Interface
Encapsulation is the process by which a lower-level protocol accepts a message from a

higher-level protocol and places it in the data portion of the lower-level frame. As a result,
datagrams transmitted through a physical network have a sequence of headers: the first
header for the physical network (or Data Link Layer) protocol, the second header for the
Network Layer protocol (for example, IP), the third header for the Transport Layer protocol,
and so on.
The following topics are general topics about the way encapsulation works on interfaces
and the Junos OS. For the ACX Series routers, keep the following points in mind when
referring to these topics:
• The [edit logical-systems logical-system-name interfaces interface-name unit

logical-unit-number] hierarchy level is not supported on the ACX Series routers.
• Not all encapsulation types or features are supported on the ACX Series routers, refer
to the documentation about the specific statement or feature for support details.
Related • Configuring Interface Encapsulation on Logical Interfaces

Documentation
• Configuring Interface Encapsulation on Physical Interfaces
• encapsulation (Physical Interface) on page 1511
• encapsulation (Logical Interface) on page 1507
Gigabit Ethernet Autonegotiation Overview
Autonegotiation is enabled by default on all Gigabit Ethernet and Tri-Rate Ethernet

copper interfaces. However, you can explicitly enable autonegotiation to configure remote
fault options manually.

NOTE:
• When you configure the Tri-Rate Ethernet copper interface to operate at
1 Gbps, autonegotiation must be enabled.
• On ACX Series Universal Access Routers, when the autonegotiation is

disabled, the speed has to be explicitly configured to 10–100 Mbps.
• On T4000 routers, the auto-negotiation command is ignored for interfaces

other than Gigabit Ethernet.
Related • Configuring Gigabit Ethernet Autonegotiation

Documentation
• Ethernet Interfaces Feature Guide for Routing Devices
BERT Support on CT1 and CE1 Interfaces
For ACX Series routers, BERT is supported on ct1 and ce1 interfaces. The following BERT
algorithms are supported:
• all-ones-repeating
• all-zeros-repeating
• alternating-double-ones-zeros
• alternating-ones-zeros
• repeating-1-in-4
• pseudo-2e11-o152
NOTE: User-defined BERT patterns are not supported.
Related • Configuring E1 BERT Properties on page 165

Documentation
• Configuring T1 BERT Properties on page 168

Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP Overview
The Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP is a channelized
circuit emulation MIC with rate-selectability. Its port speed can be specified as
COC3-CSTM1 or COC12-CSTM4. The default port speed is COC3-CSTM1.
Table 18: Platform Support for Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC with
SFP
Interface Name Model Number Platform Supported Junos OS Release
Channelized OC3/STM1 MIC-3D-4COC3-1COC12-CE MX Series routers 12.2R1

(Multi-Rate) Circuit
Emulation MIC with SFP
ACX-MIC-4COC3-1COC12CE ACX4000 router 12.3X51
The following features are supported on this MIC:
• Per-MIC SONET/SDH framing
• Internal and loop clocking
• Structure-Agnostic TDM over Packet (SAToP)
• Pseudowire Emulation Edge to Edge (PWE3) control word for use over an MPLS
packet-switched network (PSN)
• Asynchronous Transfer Mode (ATM) inverse multiplexing for ATM (IMA)
Related • Configuring SAToP on Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC with
Documentation SFP
• Inverse Multiplexing for ATM (IMA) Overview on page 184
• Understanding ATM IMA Configuration on ACX Series Router on page 174
• Configuring ATM IMA on ACX Series on page 181
16-Port Channelized E1/T1 Circuit Emulation MIC Overview
The Channelized E1/T1 Circuit Emulation MIC (ACX-MIC-16CHE1-T1-CE) is a channelized

MIC with 16 E1/T1 ports. The following features are supported on this MIC:
• Each MIC can be separately configured in either T1 or E1 framing mode
• Each T1 port supports the following framing modes:
• Superframe (D4)
• Extended superframe (ESF)
• Each E1 port supports the following framing modes:
• G704 with CRC4

• G704 without CRC4
• Unframed
• Clear channel and NxDS0 channelization. For T1 the value of N ranges from 1 through
24 and for E1 the value of N ranges from 1 through 31.
• Diagnostic features:
• T1/E1
• T1 facilities data link (FDL)
• Channel service unit (CSU)
• Bit error rate test (BERT)
• Juniper Integrity Test (JIT)
• T1/E1 alarm and performance monitoring (a Layer 1 OAM function)
• External (loop) timing and internal (system) timing
• TDM circuit emulation services CESoPSN and SAToP
• ATM encapsulation—Only the following ATM encapsulations are supported on this

MIC:
• ATM CCC cell relay
• ATM CCC VC multiplex
• ATM pseudowires
• ATM quality-of-service (QoS) features—traffic shaping, scheduling, and policing
• ATM Operation, Administration, and Maintenence
• ATM (IMA) protocol at the T1/E1 level with up to 4 IMA groups. Each group can have 1
to 8 IMA links.
NOTE: ACX5048 and ACX5096 routers do not support T1/E1 interfaces and
related features.
Related • Configuring SAToP Emulation on Channelized T1 and E1 Interfaces on page 191

Documentation
• Configuring CESoPSN on Channelized E1/T1 Circuit Emulation MIC on page 220
Synchronous Ethernet Overview on the ACX Series Universal Access Routers
Synchronous Ethernet is supported on the ACX Series routers with Gigabit Ethernet and
10-Gigabit Ethernet SFP and SFP+ transceivers and is compliant with ITU-T
Recommendation G.8261: Timing and synchronization aspects in packet networks and
ITU-T Recommendation G8264: Distribution of timing through packet
networks.Synchronous Ethernet is a physical layer frequency transfer technology modeled

after synchronization in SONET/SDH. Traditional Ethernet nodes, which do not support

Synchronous Ethernet, do not carry synchronization from one node link to another.
Synchronous Ethernet–capable nodes however can synchronize their chassis clock to a
clock recovered from an interface connected to an upstream clock master. After this,
the clock is used to time data sent to downstream clock slaves, forming a synchronization
trail from a Primary Reference Clock (PRC) to Ethernet equipment clocks (EECs) and
transferring frequency synchronization along the trail.
The ITU-T G.8264 specification defines the Synchronization Status Message (SSM)
protocol and its format for Synchronous Ethernet to ensure interoperability between
Synchronous Ethernet equipment used for frequency transfer—for example, SONET/SDH.
Synchronous Ethernet provides stable frequency synchronization to a PRC and is not
affected by load on the network. However, it requires that all the nodes from the PRC to
the last downstream node are Synchronous Ethernet capable. Synchronous Ethernet is
a recommended technology for mobile networks that require frequency-only
synchronization—for example, 2G or 3G base stations.
Related • Synchronous Ethernet Overview

Documentation
TDM CESoPSN Overview
Circuit Emulation Service over Packet-Switched Network (CESoPSN) is an encapsulation

layer intended to carry NxDS0 services over a packet-switched network (PSN). CESoPSN
enables pseudowire emulation of some properties of structure-aware time division
multiplexed (TDM) networks.
Particularly, CESoPSN enables the deployment of bandwidth-saving fractional

point-to-point E1 or T1 applications as follows:
• A pair of customer edge (CE) devices operate as though they were connected by an
emulated E1 or T1 circuit, which reacts to the alarm indication signal (AIS) and remote
alarm indication (RAI) states of the devices’ local attachment circuits.
• The PSN carries only an NxDS0 service, where N is the number of actually used time
slots in the circuit connecting the pair of CE devices, thus saving bandwidth.
Related • Configuring TDM CESoPSN on ACX Series Routers Overview on page 108
Documentation
• Configuring CESoPSN Encapsulation on DS Interfaces on page 205
• Configuring CE1 Channels Down to DS Interfaces on page 218
Configuring TDM CESoPSN on ACX Series Routers Overview
Structure-aware time division multiplexed (TDM) Circuit Emulation Service over

Packet-Switched Network (CESoPSN) is a method of encapsulating TDM signals into
CESoPSN packets, and in the reverse direction, decapsulating CESoPSN packets back
into TDM signals. This method is also termed as Interworking Function (IWF). The following

CESoPSN features are supported on Juniper Networks ACX Series Universal Access
Routers:
• Channelization up to the DS0 Level on page 109

• Protocol Support on page 109
• Packet Latency on page 109
• CESoPSN Encapsulation on page 109
• CESoPSN Options on page 110
• show Commands on page 110
• CESoPSN Pseudowires on page 110
Channelization up to the DS0 Level

The following numbers of NxDS0 pseudowires are supported for 16 T1 and E1 built-in
ports and 8 T1 and E1 built-in ports, where N represents the time slots on the T1 and E1
built-in ports.
16 T1 and E1 built-in ports support the following number of pseudowires:
• Each T1 port can have up to 24 NxDS0 pseudowires, which add up to a total of up to

384 NxDS0 pseudowires.
• Each E1 port can have up to 31 NxDS0 pseudowires, which add up to a total of up to

8 T1 and E1 built-in ports support the following number of pseudowires:
• Each T1 port can have up to 24 NxDS0 pseudowires, which add up to a total of up to

• Each E1 port can have up to 31 NxDS0 pseudowires, which add up to a total of up to

Protocol Support
All protocols that support Structure-Agnostic TDM over Packet (SAToP) support
CESoPSN NxDS0 interfaces.
Packet Latency
The time required to create packets (from 1000 through 8000 microseconds).
CESoPSN Encapsulation
The following statements are supported at the [edit interfaces interface-name] hierarchy
level:
• ct1-x/y/z partition partition-number timeslots timeslots interface-type ds
• ds-x/y/z:n encapsulation cesopsn

CESoPSN Options
The following statements are supported at the [edit interfaces interface-name
cesopsn-options] hierarchy level:
• excessive-packet-loss-rate (sample-period milliseconds)
• idle-pattern pattern
• jitter-buffer-latency milliseconds
• jitter-buffer-packets packets
• packetization-latency microseconds
show Commands
The show interfaces interface-name extensive command is supported for t1, e1, and at
interfaces.
CESoPSN Pseudowires
CESoPSN pseudowires are configured on the logical interface, not on the physical
interface. So the unit logical-unit-number statement must be included in the configuration
at the [edit interfaces interface-name] hierarchy level. When you include the unit
logical-unit-number statement, circuit cross-connect (CCC) for the logical interface is
created automatically.
Related • Setting the CESoPSN Options on page 216

Documentation
SAToP Emulation on T1 and E1 Interfaces Overview
Structure-Agnostic time-division multiplexing (TDM) over Packet (SAToP), as defined

in RFC 4553, Structure-Agnostic TDM over Packet (SAToP) is supported on the ACX Series
Universal Access routers with built-in T1 and E1 interfaces. SAToP is used for pseudowire
encapsulation for TDM bits (T1, E1). The encapsulation disregards any structure imposed
on the T1 and E1 streams, in particular the structure imposed by standard TDM framing.
SAToP is used over packet-switched networks, where the provider edge (PE) routers do
not need to interpret TDM data or participate in the TDM signaling.
NOTE: ACX5048 and ACX5096 routers do not support SAToP.
Figure 14 on page 111 shows a packet-switched network (PSN) in which two PE routers
(PE1 and PE2) provide one or more pseudowires to customer edge (CE) routers (CE1 and
CE2), establishing a PSN tunnel to provide a data path for the pseudowire.

Figure 14: Pseudowire Encapsulation with SAToP

Emulated Service
g016956
Attachment Circuit PSN tunnel Attachment Circuit
Pseudowire 1
CE1 PE1 PE2 CE2
Pseudowire 2
Native service Native service
Pseudowire traffic is invisible to the core network, and the core network is transparent
to the CEs. Native data units (bits, cells, or packets) arrive via the attachment circuit, are
encapsulated in a pseudowire protocol data unit (PDU), and carried across the underlying
network via the PSN tunnel. The PEs perform the necessary encapsulation and the
decapsulation of the pseudowire PDUs and handle any other function required by the
pseudowire service, such as sequencing or timing.
Related • Configuring SAToP Emulation on Channelized T1 and E1 Interfaces on page 191

Documentation
Ethernet Ring Protection Switching Overview
Ethernet ring protection switching (ERPS) helps achieve high reliability and network
stability. Links in the ring will never form loops that fatally affect the network operation
and services availability. The basic idea of an Ethernet ring is to use one specific link to
protect the whole ring. This special link is called a ring protection link (RPL). If no failure
happens in other links of the ring, the RPL blocks the traffic and is not used. The RPL is
controlled by a special node called an RPL owner. There is only one RPL owner in a ring.
The RPL owner is responsible for blocking traffic over the RPL. Under ring failure conditions,
the RPL owner is responsible for unblocking traffic over the RPL. A ring failure results in
protection switching of the RPL traffic. An automatic protection switching (APS) protocol
is used to coordinate the protection actions over the ring. Protection switching blocks
traffic on the failed link and unblocks the traffic on the RPL. When the failure clears,
revertive protection switching blocks traffic over the RPL and unblocks traffic on the link
on which the failure is cleared.
NOTE: ERPS on AE interfaces is not supported on ACX Series routers.
The following standards provide detailed information on Ethernet ring protection

switching:
• IEEE 802.1Q - 1998
• IEEE 802.1D - 2004
• IEEE 802.1Q - 2003
• ITU-T Recommendation G.8032/Y.1344 version 1 and 2, Ethernet Ring protection

switching
• ITU-T Y.1731, OAM functions and mechanisms for Ethernet-based networks

For additional information on configuring Ethernet ring protection switching on EX Series

switches, see Example: Configuring Ethernet Ring Protection Switching on EX Series
Switches.
For additional information on configuring Ethernet ring protection switching on MX Series

routers, see the Layer 2 Configuration Guide for a complete example of Ethernet rings and
information about STP loop avoidance and prevention.
Related • Understanding Ethernet Ring Protection Switching Functionality on page 112

Documentation
• Example: Ethernet Ring Protection Switching Configuration on MX Routers
• Example: Configuring Ethernet Ring Protection Switching on EX Series Switches
Understanding Ethernet Ring Protection Switching Functionality
• Acronyms on page 113

• Ring Nodes on page 113
• Ring Node States on page 113
• Default Logging of Basic State Transitions on EX Series Switches on page 114
• Failure Detection on page 114
• Logical Ring on page 114
• FDB Flush on page 114
• Traffic Blocking and Forwarding on page 115
• RPL Neighbor Node on page 115
• RAPS Message Blocking and Forwarding on page 115
• Dedicated Signaling Control Channel on page 116
• RAPS Message Termination on page 116
• Revertive and Non-revertive Modes on page 117
• Multiple Rings on page 117
• Node ID on page 117
• Ring ID on page 117
• Bridge Domains with the Ring Port (MX Series Routers Only) on page 117
• Wait-to-Block Timer on page 117
• Adding and Removing a Node on page 118

Acronyms
The following acronyms are used in the discussion about Ethernet ring protection switching
(ERPS):
• MA—Maintenance association
• MEP—Maintenance association end point
• OAM—Operations, administration, and management (Ethernet ring protection switching

uses connectivity fault management daemon)
• FDB—MAC forwarding database
• STP—Spanning Tree Protocol
• RAPS—Ring automatic protection switching
• WTB—Wait to block
• WTR—Wait to restore
• RPL—Ring protection link
Ring Nodes
Multiple nodes are used to form a ring. There are two different node types:
• Normal node—The node has no special role on the ring.
• RPL owner node—The node owns the RPL and blocks or unblocks traffic over the RPL.
Ring Node States

The following are the different states for each node of a specific ring:
• init—Not a participant of a specific ring.
• idle—No failure on the ring; the node is performing normally. For a normal node, traffic
is unblocked on both ring ports. For the RPL owner or RPL neighbor, traffic is blocked
on the ring port that connects to the RPL and unblocked on the other ring port.
• protection—A failure occurred on the ring. For a normal node, traffic is blocked on the
ring port that connects to the failing link and unblocked on working ring ports. For the
RPL owner, traffic is unblocked on both ring ports if they connect to non-failure links.
• pending—The node is recovering from failure or its state after a clear command is used
to remove the previous manual command. When a protection group is configured, the
node enters the pending state. When a node is in pending state, the WTR or WTB timer
will be running. All nodes are in pending state till WTR or WTB timer expiry.
• force switch—A force switch is issued. When a force switch is issued on a node in the
ring all nodes in the ring will move into the force switch state.
• manual switch—A manual switch is issued. When a manual switch is issued on a node
in the ring all nodes in the ring will move into the manual switch state.

There can be only one RPL owner for each ring. The user configuration must guarantee
this, because the APS protocol cannot check this.
Default Logging of Basic State Transitions on EX Series Switches

Starting with Junos OS Release 14.1X53-D15, EX Series switches automatically log basic
state transitions for the ERPS protocol. No configuration is required to initiate this logging.
Basic state transitions include ERPS interface transitions from up to down, and down to
up; and ERPS state transitions from idle to protection, and protection to idle.
The basic state transitions are logged in a single file named erp-default, which resides in
the /var/log directory of the switch. The maximum size of this file is 15 MB.
Default logging for ERPS can capture initial ERPS interface and state transitions, which
can help you troubleshoot issues that occur early in the ERPS protocol startup process.
However, if more robust logging is needed, you can enable traceoptions for ERPS by
entering the traceoptions statement in the [edit protocols protection-group] hierarchy.
Be aware that for ERPS, only default logging or traceoptions can be active at a time on
the switch. That is, default logging for ERPS is automatically enabled and if you enable
traceoptions for ERPS, the switch automatically disables default logging. Conversely, if
you disable traceoptions for ERPS, the switch automatically enables default logging.
Failure Detection
Ethernet ring operation depends on quick and accurate failure detection. The failure
condition signal failure (SF) is supported. For SF detection, an Ethernet continuity check
MEP must be configured for each ring link. For fast protection switching, a 10-ms
transmission period for this MEP group is supported. OAM monitors the MEP group's MA
and reports SF or SF clear events to the Ethernet ring control module. For this MEP group,
the action profile must be configured to update the interface device IFF_LINKDOWN flag.
OAM updates the IFF_LINKDOWN flag to notify the Ethernet ring control module.
Logical Ring
You can define multiple logical-ring instances on the same physical ring. The logical ring
feature currently supports only the physical ring, which means that two adjacent nodes
of a ring must be physically connected and the ring must operate on the physical interface,
not the VLAN. Multiple ring instances are usually defined with trunk mode ring interfaces.
FDB Flush
When ring protection switching occurs, normally an FDB flush is executed. The Ethernet
ring control module uses the same mechanism as the STP to trigger the FDB flush. The
Ethernet ring control module controls the ring port physical interface's default STP index
to execute the FDB flush.
Starting with Junos OS Release 14.2, the FDB flush depends on the RAPS messages
received on the both the ports of the ring node.

Traffic Blocking and Forwarding

Ethernet ring control uses the same mechanism as the STP to control forwarding or
discarding of user traffic. The Ethernet ring control module sets the ring port physical
interface default STP index state to forwarding or discarding in order to control user
traffic.
RPL Neighbor Node

Starting with Junos OS Release 14.2, ring protection link neighbor nodes are supported.
An RPL neighbor node is adjacent to the RPL and is not the RPL owner. If a node is
configured with one interface as the protection-link-end and no protection-link-owner
is present in its configuration, the node is an RPL neighbor node.
RAPS Message Blocking and Forwarding

The router or switch treats the ring automatic protection switching (RAPS) message the
same as it treats user traffic for forwarding RAPS messages between two ring ports. The
ring port physical interface default STP index state also controls forwarding RAPS
messages between the two ring ports. Other than forwarding RAPS messages between
the two ring ports, as shown in Figure 15 on page 115, the system also needs to forward
the RAPS message between the CPU (Ethernet ring control module) and the ring port.
This type of forwarding does not depend on the ring port physical interfaces’ STP index
state. The RAPS message is always sent by the router or switch through the ring ports,
as shown in Figure 16 on page 115. A RAPS message received from a discarding ring port
is sent to the Ethernet ring control module, but is not sent to the other ring port.
Figure 15: Protocol Packets from the Network to the Router

other ring port
(STP index state applies on this port and the incoming ring port)
Incoming ring port, R_APS multicast MAC address
g017271
(01-19-a7-00-00-01)
CPU (Ethernet ring module)

(STP index state does not apply on the incoming ring port)
Figure 16: Protocol Packets from the Router or Switch to the Network
east ring port (STP index state does not apply)
CPU, R_APS multicast MAC address

(01-19-a7-00-00-01)
g017270
west ring port (STP index state does not apply)
Juniper Networks switches and Juniper Networks routers use different methods to achieve
these routes.
The switches use forwarding database entries to direct the RAPS messages. The
forwarding database entry (keyed by the RAPS multicast address and VLAN) has a
composite next hop associated with it—the composite next hop associates the two ring
interfaces with the forwarding database entry and uses the split horizon feature to prevent
sending the packet out on the interface that it is received on. This is an example of the
forwarding database entry relating to the RAPS multicast MAC (a result of the show
ethernet-switching table detail command):

VLAN: v1, Tag: 101, MAC: 01:19:a7:00:00:01, Interface: ERP

Interfaces: ge-0/0/9.0, ge-0/0/3.0
Type: Static
Action: Mirror
Nexthop index: 1333
The routers use an implicit filter to achieve ERP routes. Each implicit filter binds to a
bridge domain. Therefore, the east ring port control channel and the west ring port control
channel of a particular ring instance must be configured to the same bridge domain. For
each ring port control channel, a filter term is generated to control RAPS message
forwarding. The filter number is the same as the number of bridge domains that contain
the ring control channels. If a bridge domain contains control channels from multiple
rings, the filter related to this bridge domain will have multiple terms and each term will
relate to a control channel. The filter has command parts and control-channel related
parts, as follows:
• Common terms:
• term 1: if [Ethernet type is not OAM Ethernet type (0x8902)

] { accept packet }
• term 2: if [source MAC address belongs to this bridge]

{ drop packet, our packet loop through the ring and come back
to home}
• term 3: if [destination is the RAPS PDU multicast address(0x01,0x19,0xa7,

0x00,0x00,0x01] AND[ring port STP status is DISCARDING]
{ send to CPU }
• Control channel related terms:
• if [destination is the RAPS PDU multicast

address(0x01,0x19,0xa7,0x00,0x00,
0x01] AND[ring port STP status is FORWARDING] AND [Incoming
interface
IFL equal to control channel IFL]
{ send packet to CPU and send to the other ring port }
default term: accept packet.
Dedicated Signaling Control Channel

For each ring port, a dedicated signaling control channel with a dedicated VLAN ID must
be configured. In Ethernet ring configuration, only this control logical interface is configured
and the underlying physical interface is the physical ring port. Each ring requires that two
control physical interfaces be configured. These two logical interfaces must be configured
in a bridge domain for routers (or the same VLAN for switches) in order to forward RAPS
protocol data units (PDUs) between the two ring control physical interfaces. If the router
control channel logical interface is not a trunk port, only control logical interfaces will be
configured in ring port configuration. If this router control channel logical interface is a
trunk port, in addition to the control channel logical interfaces, a dedicated VLAN ID must
be configured for routers. For switches, always specify either a VLAN name or VLAN ID
for all links.
RAPS Message Termination

The RAPS message starts from the originating node, travels through the entire ring, and
terminates in the originating node unless a failure is present in the ring. The originating

node must drop the RAPS message if the source MAC address in the RAPS message
belongs to itself. The source MAC address is the node's node ID.
Revertive and Non-revertive Modes

In revertive operation, once the condition causing a switch has cleared, traffic is blocked
on the RPL and restored to the working transport entity. In nonrevertive operation, traffic
is allowed to use the RPL if it has not failed, even after a switch condition has cleared.
Multiple Rings
The Ethernet ring control module supports multiple rings in each node (two logical
interfaces are part of each ring). The ring control module also supports the interconnection
of multiple rings. Interconnection of two rings means that two rings might share the same
link or share the same node. Ring interconnection is supported only using
non-virtual-channel mode. Ring interconnection using virtual channel mode is not
supported.
Node ID
For each node in the ring, a unique node ID identifies each node. The node ID is the node's
MAC address.
For routers only, you can configure this node ID when configuring the ring on the node or
automatically select an ID like STP does. In most cases, you will not configure this and
the router will select a node ID, like STP does. It should be the manufacturing MAC address.
The ring node ID should not be changed, even if you change the manufacturing MAC
address. Any MAC address can be used if you make sure each node in the ring has a
different node ID. The node ID on switches is selected automatically and is not
configurable.
Ring ID
The ring ID is used to determine the value of the last octet of the MAC destination address
field of the RAPS protocol data units (PDUs) generated by the ERP control process. The
ring ID is also used to discard any RAPS PDU, received by this ERP control process with
a non-matching ring ID. Ring ID values 1 through 239 are supported.
Bridge Domains with the Ring Port (MX Series Routers Only)
On the routers, the protection group is seen as an abstract logical port that can be
configured to any bridge domain. Therefore, if you configure one ring port or its logical
interface in a bridge domain, you must configure the other related ring port or its logical
interface to the same bridge domain. The bridge domain that includes the ring port acts
as any other bridge domain and supports the IRB Layer 3 interface.
Wait-to-Block Timer
The RPL owner node uses a delay timer before initiating an RPL block in revertive mode
of operation or before reverting to IDLE state after clearing manual commands. The
Wait-to-Block (WTB) timer is used when clearing force switch and manual switch
commands. As multiple force switch commands are allowed to coexist in an Ethernet
ring, the WTB timer ensures that clearing of a single force switch command does not

trigger the re-blocking of the RPL. When clearing a manual switch command, the WTB
timer prevents the formation of a closed loop due to a possible timing anomaly where
the RPL Owner Node receives an outdated remote manual switch request during the
recovery process.
When recovering from a manual switch command, the delay timer must be long enough
to receive any latent remote force switch, signal failure, or manual switch commands.
This delay timer is called the WTB timer and is defined to be 5 seconds longer than the
guard timer. This delay timer is activated on the RPL Owner Node. When the WTB timer
expires, the RPL Owner Node initiates the reversion process by transmitting an RAPS
(NR, RB) message. The WTB timer is deactivated when any higher-priority request
preempts it.
Adding and Removing a Node

Starting with Junos OS Release 14.2, you can add or remove a node between two nodes
in an Ethernet ring. Nodes are added or removed using the force switch command.
14.2 Starting with Junos OS Release 14.2, the FDB flush depends on the RAPS
messages received on the both the ports of the ring node.
14.2 Starting with Junos OS Release 14.2, ring protection link neighbor nodes are
supported.
14.2 Starting with Junos OS Release 14.2, you can add or remove a node between
two nodes in an Ethernet ring.
14.1X53-D15 Starting with Junos OS Release 14.1X53-D15, EX Series switches automatically

log basic state transitions for the ERPS protocol.
Related • Ethernet Ring Protection Switching Overview on page 111

Documentation
• Configuring Ethernet Ring Protection Switching (CLI Procedure)
Configuring Ethernet Ring Protection Switching
The inheritance model follows:
protection-group {
ethernet-ring ring-name (
node-id mac-address;
ring-protection-link-owner;

east-interface {
control-channel channel-name {
ring-protection-link-end;
}
west-interface {
node-id mac-address;
control-channel channel-name {
}
data-channel {
vlan number;
}
guard-interval number;
restore-interval number;
}
}
For each ring, a protection group must be configured. There may be several rings in each
node, so there should be multiple protection groups corresponding to the related Ethernet
rings.
Three interval parameters (restore-interval, guard-interval, and hold-interval) can be

configured at the protection group level. These configurations are global configurations
and apply to all Ethernet rings if the Ethernet ring doesn't have a more specific
configuration for these values. If no parameter is configured at the protection group level,
the global configuration of this parameter uses the default value.

Documentation
Example: Ethernet Ring Protection Switching Configuration on ACX Series Routers
This example describes how to configure Ethernet ring protection switching on an ACX
Series router:

• Ethernet Ring Overview and Topology on page 120
• Configuring a Three-Node Ring on page 120
Requirements
• Router node 1 running Junos OS with two Gigabit Ethernet interfaces.

Ethernet Ring Overview and Topology

This section describes a configuration example for a three-node ring. The ring topology
is shown in Figure 17 on page 120.
Figure 17: Example of a Three-Node Ring Topology
ge-1/2/4 ge-1/0/1 ge-1/2/1 ge-1/0/2

node 1 node 2
ge-1/0/4 ge-1/0/3
g017272
node 3
The configuration in this section is only for the RAPS channel. The bridge domain for user
traffic is the same as the normal bridge domain. The only exception is if a bridge domain
includes a ring port, then it must also include the other ring port of the same ring.
Configuring a Three-Node Ring

To configure Ethernet Ring Protection Switching on a three-node ring, perform these
tasks:
• Configuring Ethernet Ring Protection Switching on a Three-Node Ring on page 120
Configuring Ethernet Ring Protection Switching on a Three-Node Ring
Step-by-Step 1. Configuring Node 1

Procedure interfaces {
ge-1/0/1 {
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 1 {
encapsulation vlan-bridge;
vlan-id 1;
}
unit 100 {
vlan-id 100;
}
}
ge-1/2/4 {
vlan-tagging;
unit 1 {
vlan-id 1;
}
unit 100 {
vlan-id 100;
}

}
vlans {
vlan1 {
interface ge-1/2/4.1;
}
vlan100 {
}
}
protocols {
protection-group {
ethernet-ring pg101 {
ring-id 101;
compatibility-version 2;
node-id 00:01:01:00:00:01;
ring-protection-link-owner;
east-interface {
control-channel ge-1/0/1.1;
}
west-interface {
}
data-channel vlan 100;
}
}
}
protocols {
oam {
ethernet {
connectivity-fault-management {
action-profile rmep-defaults {
default-action {
interface-down;
}
}
maintenance-domain d1 {
level 0;
maintenance-association 100 {
mep 1 {
interface ge-1/0/1;
remote-mep 2 {
action-profile rmep-defaults;
}
}
}
}
level 0;
mep 1 {
interface ge-1/2/4;
remote-mep 2 {
}
}
}

}
}
}
}
}
}
2. Configuring Node 2
interfaces {
ge-1/0/2 {
vlan-tagging;
unit 1 {
vlan-id 1;
}
unit 100 {
vlan-id 100;
}
}
ge-1/2/1 {
vlan-tagging;
unit 1 {
vlan-id 1;
}
unit 100 {
vlan-id 100;
}
}
vlans {
vlan1 {
}
vlan100 {
}
}
protocols {
protection-group {
ring-id 102;
node-id 00:01:01:00:00:01;
east-interface {
}
west-interface {
}
}
}
}
protocols {

oam {
ethernet {
default-action {
interface-down;
}
}
level 0;
mep 1 {
interface ge-1/0/2;
remote-mep 2 {
}
}
}
}
level 0;
mep 1 {
interface ge-1/2/1;
remote-mep 2 {
}
}
}
}
}
}
}
}
}
3. Configuring Node 3
interfaces {
ge-1/0/4 {
vlan-tagging;
unit 1 {
vlan-id 1;
}
unit 100 {
vlan-id 100;
}
}
ge-1/0/3 {
vlan-tagging;
unit 1 {
vlan-id 1;
}
unit 100 {

vlan-id 100;
}
}
vlans {
vlan1 {
}
vlan100 {
}
}
protocols {
protection-group {
ring-id 104;
node-id 00:01:01:00:00:01;
east-interface {
}
west-interface {
}
}
}
}
protocols {
oam {
ethernet {
default-action {
interface-down;
}
}
level 0;
mep 1 {
interface ge-1/0/4;
remote-mep 2 {
}
}
}
}
level 0;
mep 1 {
interface ge-1/0/3;
remote-mep 2 {
}
}

}
}
}
}
}
}
}
Examples: Ethernet This section provides output examples based on the configuration shown above. The
RPS Output show commands used in these examples can help verify configuration and correct
operation.
Normal Situation—RPL Owner Node
If the ring has no failure, the show command will have the following output for Node 1:
user@node1> show protection-group ethernet-ring aps
Ethernet Ring Name Request/state No Flush Ring Protection Link Blocked

pg101 NR No Yes
Originator Remote Node ID

Yes
user@node1> show protection-group ethernet-ring interface

Ethernet ring port parameters for protection group pg101
Interface Control Channel Forward State Ring Protection Link End

ge-1/0/1 ge-1/0/1.1 discarding Yes
ge-1/2/4 ge-1/2/4.1 forwarding No
Signal Failure Admin State

Clear IFF ready
Clear IFF ready
user@node1> show protection-group ethernet-ring node-state

Ethernet ring APS State Event Ring Protection Link Owner
pg101 idle NR-RB Yes
Restore Timer Quard Timer Operation state

disabled disabled operational
user@node1> show protection-group ethernet-ring statistics group-name pg101

Ethernet Ring statistics for PG pg101
RAPS sent : 1
RAPS received : 0
Local SF happened: : 0
Remote SF happened: : 0
NR event happened: : 0
NR-RB event happened: : 1
Normal Situation—Other Nodes
For Node 2 and Node 3, the outputs should be the same:

pg102 NR No Yes


No 00:01:01:00:00:01



Clear IFF ready
Clear IFF ready

pg102 idle NR-RB No


RAPS sent : 0
RAPS received : 1
Failure Situation—RPL Owner Node
If the ring has a link failure between Node 2 and Node 3, the show command will have
the following outputs for Node 1:

pg101 SF NO No

No 00:01:02:00:00:01


ge-1/0/1 ge-1/0/1.1 forwarding Yes

Clear IFF ready
Clear IFF ready

pg101 protected SF Yes


RAPS sent : 1

RAPS received : 1
Failure Situation—Other Nodes
For Node 2 and Node 3, the outputs should be the same:

pg102 SF No No

Yes 00:00:00:00:00:00


ge-1/0/2 ge-1/0/2.1 discarding No

Clear IFF ready
set IFF ready

pg102 idle NR-RB No


RAPS sent : 1
RAPS received : 1

Documentation
Example: Viewing Ethernet Ring Protection Status—Normal Ring Operation
Under normal operating conditions, when Ethernet ring protection is configured correctly,
the ring protection link (RPL) owner (Router 1 in the configuration example) will see the
following:

Router 1 Operational Commands (Normal Ring Operation)

user@router1> show protection-group ethernet-ring aps
pg101 NR No Yes

Yes
Note that the ring protection link is blocked and the node is marked as the originator of
the protection.
user@router1> show protection-group ethernet-ring interface


ge-1/0/1 ge-1/0/1.1 discarding Yes

Clear IFF ready
Clear IFF ready
Note that the protection interface is discarding while the other interface is forwarding.
user@router1> show protection-group ethernet-ring node-state

pg101 idle NR-RB Yes

Note that Router 1 is the owner and timers are disabled.
user@router1> show protection-group ethernet-ring statistics group-name pg101

RAPS sent : 1
RAPS received : 0
Note that only minimal RAPS messages have been sent to establish the ring.
Under normal operating conditions, the other routers on the ring (Router 2 and Router
3) will see the following similar output:
Router 2 and Router 3 Operational Commands (Normal Ring Operation)

pg102 NR No Yes

No 00:01:01:00:00:01

Router 3 will see almost identical information.



Clear IFF ready
Clear IFF ready
Note that both interfaces are forwarding. Router 3 will see almost identical information.

pg102 idle NR-RB No

Note that Router 2 is not the owner. Router 3 will see almost identical information.

RAPS sent : 0
RAPS received : 1
Router 3 will see almost identical information.
Related • Ethernet Interfaces Feature Guide for Routing Devices

Documentation
• Ethernet Ring Protection
• Example: Configuring Ethernet Ring Protection for MX Series Routers
• Example: Viewing Ethernet Ring Protection Status—Ring Failure Condition on page 129
Example: Viewing Ethernet Ring Protection Status—Ring Failure Condition
This section assumes that Ethernet ring protection is configuring correctly, that Router
1 is the ring protection link (RPL) owner, and that there is a link failure between Router 2
and Router 3 in the configuration example.
Router 1 Operational Commands (Ring Failure Condition)

pg101 SF NO No


No 00:01:02:00:00:01
Note that the ring protection link is no longer blocked and the node is no longer marked
as originator.


ge-1/0/1 ge-1/0/1.1 forwarding Yes

Clear IFF ready
Clear IFF ready
Note that the protection interface is now forwarding (so is the other interface).

how protection-group ethernet-ring node-state
pg101 protected SF Yes

Note that Router 1 has recorded the span failure (SF).

RAPS sent : 1
RAPS received : 1
Note that the R-APS messages have recorded the remote failure.
Under a failure condition, the other routers on the ring (Router 2 and Router 3) will see
the following similar output:
Router 2 and Router 3 Operational Commands (Failure Condition)

pg102 SF No No

Yes 00:00:00:00:00:00
Note the failure event (SF). Router 3 will see almost identical information.


ge-1/0/2 ge-1/0/2.1 discarding No

Clear IFF ready
set IFF ready
Note that the failed interface (ge-1/0/2.1) is not forwarding. Router 3 will see almost
identical information.

pg102 idle NR-RB No

Note that Router 2 is not the owner. Router 3 will see almost identical information.

RAPS sent : 1
RAPS received : 1
Note that the R-APS messages have recorded the remote failure. Router 3 will see almost
identical information.
Related • Ethernet Interfaces Feature Guide for Routing Devices

Documentation
• Ethernet Ring Protection
• Example: Configuring Ethernet Ring Protection for MX Series Routers
• Example: Viewing Ethernet Ring Protection Status—Normal Ring Operation on page 127
Guidelines for Ethernet Ring Protection Switching on ACX Series Routers
You can configure Ethernet ring protection switching (ERPS) on ACX Series routers to
achieve high reliability and network stability. Links in the ring will never form loops that
fatally affect the network operation and services availability. The basic idea of an Ethernet
ring is to use one specific link to protect the whole ring. This special link is called a ring
protection link (RPL). If no failure happens in other links of the ring, the RPL blocks the
traffic and is not used. The RPL is controlled by a special node called an RPL owner.
A ring with only one port is supported. In such a scenario, only one port is configured for
a ring when two nodes are present. Use the interface-none statement to designate a port

to be not used for Ethernet ring protection. You can configure a ring port over LAG
interfaces.
NOTE: ERPS on aggregated Ethernet interface is supported on ACX5000

line of routers.
ITU G.8031 Ethernet automatic protection switching (APS) and ERPS version 2 are not
supported. Also, you cannot configure ACX Series routers as trunk ports or access ports
in an Ethernet ring.
Multiple Ethernet ring instances that share the same physical ring are supported. Each
ring instance will have its own control channel and a specific data channel. You can
configure the data channel with a set of data VLAN IDs that belong to a ring instance.
Each ring instance can follow a different path to perform load balancing in the physical
ring. If you do not specify a data channel, ERPS operates on the VLAN ID associated with
the control channel. There is no limit to the number of VLAN IDs that you can configure
for a data channel.
Keep the following points in mind when you configure ERPS for ACX Series routers:
• The logical interfaces that you define for a control channel must be part of the same
bridge domain.
• Each VLAN that you configure in a data channel signifies an independent bridge domain.
• The traffic that is blocked on a ring port is the same for all the bridge domains that are
associated with the same control channel. When a topology change happens, the
forwarding databases of all these bridge domains are cleared.
• You cannot configure spanning-tree protocol (STP) (such as MSTP, RSTP, VSTP and
STP) and ERP on the same set of interfaces. However, ERP and Per-VLAN Spanning
Tree (PVST) can be configured on the same topology as long as PVST does not share
the same VLAN with any Ethernet ring instance configured on the physical port.
• You cannot configure STP and ERPS in the same bridge domain. Consider a sample
scenario in which a dual-homed customer edge (CE) router is connected to two ACX
Series routers, which function as provider edge (PE) devices. In such a topology, you
can configure either STP or an ERPS open ring to enable dual-homing functionality.
You can configure STP between the CE and the user-to-network interface (UNI) ports
of the two PE devices. Alternatively, if the CE router supports ERPS, you can configure
an open ring in the CE network.
• In the event of a single failure, switching times on all ACX routers is less than 100
milliseconds.
• The following parameters can impact the performance of the system based on your
network configuration:
• Number of protocols (Layer 2, Layer 3, or MPLS) affected by a certain network failure
• Number of ring instances corresponding to the ring that is impacted by the failure

• Number of bridge domains associated with each ring instance
• Number of forwarding database entries associated with each bridge domain
• The ERPS control packets are copied to the CPU (Ethernet ring control module) only
when the VLAN ID and destination address of the packet matches with the values of
the RAPS message. Otherwise, the control packet is treated as a regular service frame
and forwarded accordingly. The packets that are copied to the CPU are queued in the
specified CPU queue, which is rate-limited. This mechanism ensures that a possible
Denial-of-Service (DoS) attack does not significantly impact the system. If a DoS
attack is detected, a firewall filter on the affected logical interfaces can be configured
in the bridge domain.
• For fast detection required for switchover within 50 milliseconds, we recommend that
you configure connectivity fault management (CFM) link-level MEPs with an interval
of 10 milliseconds for the duration between the transmission of CFM messages. This
link-level MEP can be used to trigger switchovers for all ring instances that share a
physical ring.
• Forwarding and flush mechanisms are common for STP and ERP.
• We recommend that you configure link-level maintenance association endpoints

(MEPs) with 10ms on physical interfaces. If link-level MEPs are not configured on
physical interfaces, fast switching (less than 100ms) might not occur.
• The maximum number of physical rings supported on different ACX Series routers is
as follows:
• 4 physical rings on ACX1000, ACX1100, ACX2000, and ACX2100 routers
• 8 physical rings on ACX4000 routers
• 24 physical rings on ACX5048 and ACX5096 routers
• The maximum number of ring instances supported on different ACX Series routers is
as follows:
• 8 ring instances on ACX1000, ACX1100, ACX2000, and ACX2100 routers
• 16 ring instances on ACX4000 routers
• 96 ring instances on ACX5048 and ACX5096 routers

Documentation

Dual-Rate SFP+ Optic Modules for ACX Series Routers
ACX2000, ACX2100, and ACX4000 routers support the Dual Rate SFP+ optic modules.
These modules operate at either 1 Gbps or 10 Gbps speeds. When you plug in the module
to the small form-factor pluggable plus (SFP+) slot, the module can be set at either 1
Gbps or 10 Gpbs. Such a module support on ACX routers enables users to provision ACX
devices in network topologies utilising their existing 1 GE infrastructure and when the
network circuits are upgraded to a speed of 10 Gbps, a configuraiton change can be
performed without the need to extensively, separately maintain and configure every
single site device that requires an upgrade. Using Dual Rate SFP+ modules, you can
perform a seamless, smooth transition in such upgraded networks, thereby negating the
need to perform a bulk change in the networking gear of multiple service operators
(MSOs) that require upgrade to operate at 10 GE speed. Dual Rate SFP+ Support is
applicable only for 10-Gigabit Ethernet (xe) fiber ports and not for 1-Gigabit Ethernet
(ge) fiber (SFP) and copper ports.
NOTE: ACX5048 and ACX5096 routers do not support the Dual Rate SFP+
optic modules.
ACX routers use 2-port 10-Gigabit Ethernet (LAN) SFP+ MIC (2x 10GE(LAN) SFP+) in
the following two combinations:
• 2x 10GE(LAN) SFP+ uses BCM84728 PHY on ACX 2100/ACX4000 routers.
• 2x 10GE(LAN) SFP+ uses BCm8728/8747 on ACX2000 routers.
To configure an xe port in 1GE mode , use the set interfaces xe-x/y/z speed 1g statement.
To configure an xe port in 10GE mode, use the set interfaces xe-x/y/z speed 10g statement.
To unconfigure an xe port in 1GE mode, use the delete interfaces xe-x/y/z speed 1g
statement. To unconfigure an xe port in 10GE mode, use the delete interfaces xe-x/y/z
speed 10g statement. The default speed mode of 1GE is used when you plug in a dual-rate
SFP+ module. You must use set interfaces xe-x/y/z speed (1g | 10g) statement to configure
1GE or 10GE speed mode only for dual-rate SFP+ optic modules. You must not use the
speed (1g | 10g) option with other optics of fixed speed plugged into the xe port.
The following dual-rate SFP+ modules are supported:
Product Number Description Finisar Part Number
740-051414 SFP+, 10GE-SR/GE-SX, MMF 300m, 850nm, 0~70C, 1.0W, FTLX8571D3BCV-J1 (0–70°)
DDM, Beige Latch, 2xLC
740-051415 SFP+, 10GE-LR/GE-LX, SMF 10Km, 1310nm, -5~70C, 1.0W, FTLX1471D3BCV-J1 (-5–70°)
DDM, Blue Latch, 2xLC

Dual Rate SFP+ Capabilities

The following are the design specifications and component details, and the supported
interfaces for network scenarios:
• 740-051414(FTLX8571D3BCV-J1)—This module supports rate selectable 1.25Gb/s or

9.95 to 10.3 Gb/s bit rates. The power dissipation is less than 1 watt. The commercial
temperature range is from 0° C to 70° C. The maximum link length is 300 meters on
2000 MHZ-km MMF. It contains built-in digital diagnostic functions. This module is
compatible with Gigabit Ethernet 1000BASE-SX Optical Interface (1000BASE-SX 1G
Ethernet) and 10-Gigabit Ethernet 10GBASE Optical Interface (10GBASE-SR 10G
Ethernet).
• 740-051415(FTLX1471D3BCV-J1)—This module supports rate selectable 1.25Gb/s or

9.95 to 10.3 Gb/s bit rates. The power dissipation is less than 1W. The operating
temperature range is -5° C to 70° C. The maximum link length is 10 km. It contains
built-in diagnostic functions. It is compatible with Gigabit Ethernet 1000BASE-LX
Optical Interface (1000BASE-LX 1G Ethernet) and 10GBASE-LR 10G Ethernet interfaces.
You can configure the SFP+ ports with the requested speed (1 GE or 10 GE) by using the
set interfaces xe-x/y/z speed (1g | 10g) statement at the [edit] hierarchy level. Dual Rate
SFP+ registers are preprogrammed with the autonegotiation settings and the underlying
physical layer (PHY) is defined with the required settings for the mode it is selected (1GE
or 10GE). You must unconfigure the speed that was defined earlier on Dual Rate SFP+
plugged into the XE port before replacing the optics in the port with a different type of
optic. Default speed of XE ports is changed from 10GE to 1GE (1000m Mbps) during a
Link Down state.
Related • speed on page 1728

Documentation
Tri-Rate SFP for ACX5000 Series Routers
Junos OS for ACX5000 Universal Access Routers supports 10 Mbps, 100 Mbps and 1
Gbps speeds for SFP-FE-ET model.
To configure the speed on the interfaces with these tri-rate SFPs, include the speed CLI
statement at the [edit interfaces interface-name] hierarchy level. Auto speed not supported
in ACX5000 Series routers.
To verify the speed set for a configured interface, use the show interfaces interface-name
extensive | grep speed command.
The following is a sample output for show interfaces interface-name extensive | grep speed
command:
Link-level type: Ethernet, MTU: 9192, LAN-PHY mode, Link-mode: Full-duplex, Speed:
100mbps, BPDU Error: None,
Link mode: Full-duplex, Flow control: Symmetric/Asymmetric, Remote fault: OK,
Link partner Speed: 100 Mbps

Related • speed on page 1728

Documentation
Configuring Logical Tunnel Interfaces
Logical tunnel (lt-) interfaces provide quite different services depending on the host
router:
• On M Series, MX Series, and T Series routers, logical tunnel interfaces allow you to
connect logical systems, virtual routers, or VPN instances. M Series and T Series routers
must be equipped with a Tunnel Services PIC or an Adaptive Services Module (only
available on M7i routers). MX Series routers must be equipped with a Trio MPC/MIC
module. For more information about connecting these applications, see the Junos OS
VPNs Library for Routing Devices.
• On SRX Series Services Gateways, the logical tunnel interface is used to interconnect
logical systems. See the Junos OS Logical Systems Configuration Guide for Security
Devices.
• On ACX Series routers, logical tunnel interfaces allow you to connect a bridge domain
and a pseudowire. Logical systems are not supported on ACX Series routers.
For M Series, MX Series, and T Series routers, see the following section:
• Connecting Logical Systems on page 136
Connecting Logical Systems

To connect two logical systems, you configure a logical tunnel interface on both logical
systems. Then you configure a peer relationship between the logical tunnel interfaces,
thus creating a point-to-point connection.
To configure a point-to-point connection between two logical systems, configure the

logical tunnel interface by including the lt-fpc/pic/port statement:
lt-fpc/pic/port {
unit logical-unit-number {
encapsulation encapsulation;
peer-unit unit-number; # peering logical system unit number
dlci dlci-number;
family (inet | inet6 | iso | mpls);
}
}
You can include this statement at the following hierarchy levels:
• [edit interfaces]
• [edit logical-systems logical-system-name interfaces]

When configuring logical tunnel interfaces, note the following:
• You can configure each logical tunnel interface with one of the following encapsulation
types: Ethernet, Ethernet circuit cross-connect (CCC), Ethernet VPLS, Frame Relay,
Frame Relay CCC, VLAN, VLAN CCC, or VLAN VPLS.
• You can configure the IP, IPv6, International Organization for Standardization (ISO),
or MPLS protocol family.
• Do not reconfigure a logical tunnel interface that is an anchor point with pseudowire
devices stacked above it unless you first deactivate all broadband subscribers that are
using the pseudowire subscriber interface.
• The peering logical interfaces must belong to the same logical tunnel interface derived
from the Tunnel Services PIC or Adaptive Services Module.
• You can configure only one peer unit for each logical interface. For example, unit 0
cannot peer with both unit 1 and unit 2.
• To enable the logical tunnel interface, you must configure at least one physical interface
statement.
• Logical tunnels are not supported with Adaptive Services, Multiservices, or Link Services
PICs (but they are supported on the Adaptive Services Module on M7i routers, as noted
above).
• On M Series routers other than the M40e router, logical tunnel interfaces require an
Enhanced Flexible PIC Concentrator (FPC).
• On MX Series routers, logical tunnel interfaces require Trio MPC/MIC modules. They
do not require a Tunnel Services PIC in the same system.
For more information about configuring logical systems, see the Junos OS Routing
Protocols Library.
Related • Tunnel Services Overview

Documentation
• Example: Configuring Logical Tunnels
Guidelines for Configuring Logical Tunnels on ACX Series Routers
Observe the following guidelines while configuring logical tunnel (lt-) interfaces on ACX
Series routers:
• You can use a logical tunnel interface to connect only bridge domains and pseudowires.
• Logical tunnel interfaces cannot interconnect the following links:
• Pesudowire and a routing instance (Pseudowire terminating on a VRF)
• Two routing instances
• VPLS instance and a routing instance
• Two VPLS instances

• Two Bridge domains
• Bridge domain and a VPLS instance
• Only one logical tunnel (physical interface) per bandwidth type (1 Gbps or 10 Gbps)
can be configured on ACX routers. However, you can specify up to two logical tunnel
interfaces (one with 1 Gb bandwidth and another with 10 Gb bandwidth) on ACX routes.
• Guaranteed bandwidth for logical tunnels is 1 Gbps and certain platforms support up
to an additional 10 Gbps bandwidth. All the services configured using logical tunnel
interfaces share this bandwidth.
The bandwidth configured on the logical tunnel interface is shared between upstream
and downstream traffic on that interface. The effective bandwidth available for the
service is half the configured bandwidth.
• Multiple logical tunnel interfaces to enable configuration of separate services on each

logical interface to obtain increased bandwidth for each individual interface separately
or the bundling of individual logical tunnel interfaces is not supported.
• You can configure Ethernet VLAN, Ethernet CCC, VLAN bridge on Ethernet interfaces,
and VLAN on circuit cross-connects (CCC) as encapsulation types on logical tunnel
interfaces. Other encapsulation types such as Ethernet, VLAN, Ethernet VPLS, or VLAN
VPLS are not supported.
• When the encapsulation configured on the logical interface units is one of the supported
types such as Ethernet VLAN or VLAN bridge, you can enable only bridge domains or
CCC protocols on logical tunnel interfaces. Other address families or protocols such
as IPv4, IPv5, MPLS, or OSPF are not supported.
• Classifier, rewrite and ingress policer configuration are supported on logical tunnel
interfaces. Fixed, BA-based, and multifield classifiers are supported on the lt- interfaces
at the physical interface-level.
802.1p, 802.1ad, TOS and DSCP based BA classifiers are supported. Remarking rules
can be configured at the port level on the LT interface. 802.1p, 802.1ad, TOS and DSCP
fields in the packet can be rewritten in the LT interface. Ingress policers are supported.
Simple, Single-rate tricolor marking (srTCM), two-rate tricolor marking (trTCM) policers
are supported. Egress policers are not supported.
• Default classifiers do not work properly when lt- interfaces are configured on
non-Ethernet PICs.
• Port-level queuing is supported; up to eight queues per lt- interface are supported.
These eight queues are shared between the upstream and downstream traffic traversing
through the lt- interface. If the configured bandwidth on the lt- interface is not adequate
for the upstream and downstream traffic of the services configured on the interface,
a failure occurs with traffic propagation because multiple lt- interfaces are not
supported.
• Eight forwarding classes (0-7) are mapped to the eight queues based on the global
system configuration. The remainder of the scheduler configuration, buffer-size,
transmit-rate, shaping-rate, priority and WRED or drop profiles maps can be configured
on the lt- interface queues.

• The following firewall filter types are supported on lt- interfaces:
• Logical interface-level filters
• Bridge family filters
• CCC family filters
All firewall configurations are supported. The scaling limitation with such filters is the
same as the existing firewall filter restrictions.
• OAM is not supported on lt- interfaces.
• Similar to other physical interfaces, the number of logical interfaces that can be
supported on logical tunnel physical interfaces is 30.
• When a bridge domain is configured with a VLAN ID (bridge domain has normalized
VLANs), the difference is behavior between MX and ACX Series routers is that the MX
router does not match the user-vlan-id in output filter, whereas the ACX router matches
the user-vlan-id specified in the output filter.
• If the logical tunnel interface is created using non Ethernet PICs, then default classifier
is not bound to the interface.
To create logical tunnel interfaces and the bandwidth in gigabits per second to reserve
for tunnel services, include the tunnel-services bandwidth (1g | 10g) statement at the [edit
chassis fpc slot-number pic number] hierarchy level:
[edit interfaces]
lt-fpc/pic/port {
peer-unit unit-number; # peering logical system unit number
dlci dlci-number;
family (inet | inet6 | iso | mpls);
}
}
The ACX5048 and ACX5096 routers support ethernet-vpls and vlan-vpls encapsulations.
These encapsulations are supported only on logical tunnel interface and are required for
configuring hierarchial VPLS.
You can use any unused physical port on the ACX5048 and ACX5096 routers to create
a logical tunnel interface as shown below:
user@host# edit chassis

fpc 0 {
pic 0 {
tunnel-services {
port port-number;
}
}
}
The following sample configuration allows you to encapsulate vlan-ccc to vlan-vpls using
LT interface in ACX5048 and ACX5096 routers:


lt-0/0/1 {
unit 0 {
encapsulation vlan-ccc;
vlan-id 1;
peer-unit 1;
}
unit 1 {
encapsulation vlan-vpls;
vlan-id 1;
peer-unit 0;
}
}
Related • Configuring Logical Tunnel Interfaces on page 136

Documentation
Configuring an Interface in the VRF Domain to Receive Multicast Traffic
You can configure an ACX Series router to receive multicast traffic in a VRF domain. In
an IPTV solution, IPTV sources and receivers can be spread across different end points
of a network in a VRF domain. To receive the multicast traffic at the receiver’s side, it is
necessary for the multicast traffic to be tunneled across the network to reach the end
receiving device or the subscriber. This tunneling is usually done using the Multicast Virtual
Private Network (MVPN) technology.
ACX Series routers do not support MVPN technology. An alternate method for receiving
the multicast traffic in the VRF domain in ACX Series router is by associating a global
logical interface to a logical interface in the VRF domain. The global logical interface acts
as a proxy for receiving the multicast traffic on the logical interface in the VRF domain.
To associate a global logical interface to a logical interface in the VRF domain, you need
to configure an IRB interface in a global domain to act as a proxy for the logical interface
in the VRF domain.
• Configuring a Proxy Logical Interface in the Global Domain on page 140

• Associating the Proxy Logical Interface to a Logical Interface in a VRF
Domain on page 141
• Limitations on page 141
Configuring a Proxy Logical Interface in the Global Domain

To configure a proxy logical interface in the global domain, you need to create logical
tunnel (lt-) interface and IRB interface and then associate the IRB interface to a bridge
domain. The following is a example to configure a proxy logical interface in the global
domain:
1. Create an logical tunnel (lt-) interface.
[edit]
user@host# set chassis aggregated-devices ethernet device-count 1
user@host# set chassis fpc 0 pic 0 tunnel-services bandwidth 1g

user@host# set interfaces lt-0/0/10 unit 0 encapsulation vlan-bridge

user@host# set interfaces lt-0/0/10 unit 0 vlan-id 101
user@host# set interfaces lt-0/0/10 unit 0 peer-unit 1
user@host# set interfaces lt-0/0/10 unit 1 encapsulation vlan-ccc
user@host# set interfaces lt-0/0/10 unit 1 vlan-id 101
user@host# set interfaces lt-0/0/10 unit 1 peer-unit 0
2. Create an IRB interface.
[edit]
user@host# set interfaces irb unit 0 family inet address 192.168.1.2/24
3. Associate the IRB interface to a bridge domain.
[edit]
user@host# set bridge-domains b1 vlan-id 101
user@host# set bridge-domains b1 interface lt-0/0/10.0
user@host# set bridge-domains b1 routing-interface irb.0
Associating the Proxy Logical Interface to a Logical Interface in a VRF Domain

To associate the proxy logical interface to a logical interface in a VRF domain, you need
to run the following PFE commands:
• test pfe acx vrf-mc-leak enable—Enables proxy association.
• test pfe acx entry add VRF-logical-interface-name logical-tunnel-logical-interface-name

IRB-logical-interface-name IRB-IP-address + 1—Creates an association between proxy
logical interface and the logical interface in a VRF domain.
• test pfe acx vrf-mc-leak disable—Disables proxy association.
• test pfe acx entry del VRF-logical-interface-name logical-tunnel-logical-interface-name

IRB-logical-interface-name IRB-IP-address + 1—Deletes the association between the
proxy logical interface and the logical interface in a VRF domain.
• show pfe vrf-mc-leak—Displays the association entries between proxy logical interface
and the logical interface in a VRF domain.
NOTE: When the router or PFE is rebooted, the proxy associations of logical
interfaces is removed and you need to once again create the proxy
associations of logical interface.
Limitations
The following limitations need to be considered for receiving multicast traffic in a VRF
domain:
• Maximum of 5 proxy associations of logical interfaces can be configured.
• VRF IPv6 multicast is not supported.

• AE interface as a VRF interface (requesting multicast traffic) is not be supported.
• Multicast traffic cannot be forwarded from the logical interface in a VRF domain if the
first hop router is an ACX router.
Related
Documentation
Understanding PoE on ACX Series Universal Access Routers
Power over Ethernet (PoE) is the implementation of the IEEE 802.3af and IEEE 802.3at
standards that allows both data and electrical power to pass over a copper Ethernet
LAN cable.
Juniper Networks provides PoE on ACX2000 Universal Access Routers that allows power
delivery up to 65 W per PoE port. PoE ports transfer electrical power and data to remote
devices over standard twisted-pair cables in an Ethernet network. Using the PoE ports,
you can plug in devices that require both network connectivity and electrical power, such
as voice over IP (VoIP) and wireless LAN access points.
You can configure the ACX2000 Universal Access Router to act as a power sourcing
equipment (PSE), supplying power to powered devices that are connected on designated
ports.
This topic contains the following sections: :
• ACX2000 PoE Specifications on page 142

• PoE Classes and Power Ratings on page 143
• PoE Options on page 143
ACX2000 PoE Specifications

Table 19 on page 142 lists the PoE specifications for the ACX2000 routers.
Table 19: PoE Specifications for the ACX2000 Routers

Specifications For ACX2000 Universal Access Routers
Supported standards • IEEE 802.3 AF

• IEEE 802.3 AT (PoE+)
• Legacy (pre-standards)
Supported ports Supported on only two Gigabit Ethernet ports (ge-0/1/3

and ge-0/1/7).
Total PoE power sourcing capacity 130 W
Default per port power limit 32 W
Maximum per port power limit 65 W

Table 19: PoE Specifications for the ACX2000 Routers (continued)

Specifications For ACX2000 Universal Access Routers
Power management modes • class—Power allocated for each interface can be

configured.
• static—Power allocated for interfaces is based on the
class of powered device connected.
• high-power—Power allocated for interfaces up to 65 W
per port.
PoE Classes and Power Ratings

A powered device is classified based on the maximum power that it draws across all
input voltages and operational modes. When class-based power management mode is
configured on the ACX2000 routers, power is allocated taking into account the maximum
power ratings defined for the different classes of devices.
Table 20 on page 143 lists the classes and their power ratings as specified by the IEEE
standards.
Table 20: ACX2000 Universal Access Router PoE Specifications

Minimum Power Levels
Class Usage Output from PoE Port
0 Default 15.4 W
1 Optional 4.0 W
2 Optional 7.0 W
3 Optional 15.4 W
4 Reserved Class 4 power devices are

eligible to receive power up to
30 W according to the IEEE
standards.
PoE Options
For ACX2000 Universal Access Routers that support PoE ports, the factory default
configuration enables PoE on the PoE-capable ports, with default settings in effect. You
might not have to do any additional configuration if the default settings work for you.
Table 21 on page 143 shows the PoE configuration options and their default settings for
the PoE controller and for the PoE interfaces.
Table 21: PoE Configuration Options and Default Settings

Option Default Description
PoE Controller Options

Table 21: PoE Configuration Options and Default Settings (continued)

Option Default Description
guard-band 0W Reserves up to 19 W power from the PoE power budget to be used in

the case of a spike in PoE power consumption.
management static Sets the PoE power management mode for the router. The power
management mode determines how power to a PoE interface is
allocated:
• class—Power allocated for each interface can be configured.

• static—Power allocated for interfaces is based on the class of powered
device connected.
• high-power—Power allocated for interfaces up to 65 W per port.
Interface Options
disable (Power over Not included in default When included in the configuration, disables PoE on the interface. The
Ethernet) configuration interface maintains network connectivity but no longer supplies power
to a connected powered device. Power is not allocated to the interface.
priority (Power over low Sets an interface’s power priority to either low or high. If power is
Ethernet) insufficient for all PoE interfaces, the PoE power to low-priority interfaces
is shut down before power to high-priority interfaces is shut down. Among
interfaces that have the same assigned priority, the power priority is
determined by port number, with lower-numbered ports having higher
priority.
telemetries Not included in default When included in the configuration, enables the logging of power
configuration consumption records on an interface. Logging occurs every 5 minutes
for 1 hour unless you specify a different value for interval (Power over
Ethernet) or duration.
Related • Example: Configuring PoE on ACX2000 Routers on page 144

Documentation
• Example: Disabling a PoE Interface on ACX2000 Routers on page 149
Example: Configuring PoE on ACX2000 Routers
Power over Ethernet (PoE) ports supply electric power over the same ports that are used
to connect network devices. These ports allow you to plug in devices that need both
network connectivity and electric power, such as voice over IP (VoIP) phones, wireless
access points, and IP cameras.
This example shows how to configure PoE to deliver power up to 65 W on ACX2000

interfaces:



Requirements
This example uses the following software and hardware components:
• Junos OS Release 12.2 or later for ACX Series routers
• An ACX2000 router that supports PoE
Before you configure PoE, be sure you have:
• Performed the initial router configuration. See “ACX Series Autoinstallation Overview”
on page 75,“Verifying Autoinstallation on ACX Series Universal Access Routers” on
page 79, and “Boot Sequence on ACX Series Routers” on page 48 for details.
Overview
This example consists of a router that has eight ports. Only two ports—ge-0/1/3 and
ge-0/1/7—support PoE, which means they provide both network connectivity and electric
power for powered devices such as VoIP telephones, wireless access points, and IP
security cameras that require power up to 65 W. The remaining six ports provide only
network connectivity. You use the standard ports to connect devices that have their own
power sources, such as desktop and laptop computers, printers, and servers.
Table 22 on page 145 details the topology used in this configuration example.
Table 22: Components of the PoE Configuration
Property Settings
Hardware ACX2000 router with 8 Gigabit Ethernet ports: Two PoE
interfaces (ge-0/1/3 and ge-0/1/7) and 6 non-PoE interfaces
(ge-0/1/0, ge-0/1/1, ge-0/1/2, ge-0/1/4, ge-0/1/5, ge-0/1/6).
VLAN name default
Connection to a wireless access point (requires PoE) ge-0/1/7
Power port priority high
Maximum power available to PoE port 65 W
PoE management mode high-power
Direct connections to desktop PCs, file servers, integrated ge-0/1/0 through ge-0/1/2
printer/fax/copier machines (no PoE required)
Unused ports (for future expansion) ge-0/1/4 through ge-0/1/6

Configuration
To configure PoE on an ACX2000 router:
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.
set poe management high-power guard-band 19

set poe interface ge-0/1/3 priority high maximum-power 65 telemetries
Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.
To configure PoE:
1. Set the PoE management mode to high-power.
[edit]
user@host# set poe management high-power
NOTE:
• Set the PoE management mode to high-power only when the power
requirement is more than 32 W and up to 65 W. If the power

requirement is less than or equal to 32 W, then you do not need to set
the PoE management mode to high-power.
• The default management mode is static. In this mode, the power

sourcing equipment can deliver power up to 32 W.
2. Reserve power wattage in case of a spike in PoE consumption.
[edit]
user@host# set poe guard-band 19
3. Enable PoE.
[edit]
user@host# edit poe interface ge-0/1/3
4. Set the power port priority.
[edit poe interface ge-0/1/3]

user@host# set priority high
5. Set the maximum PoE power for a port.


user@host# set maximum-power 65
NOTE: Set the maximum PoE power for a port only when the power
requirement is more than 32 W and up to 65 W. If the power requirement
is less than or equal to 32 W, then you do not need to configure the
maximum PoE power.
6. Enable the logging of PoE power consumption.

user@host# set telemetries
Results
In configuration mode, confirm your configuration by entering the show poe interface
ge-0/1/3 command. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.
[edit]
user@host# show poe interface ge-0/1/3
priority high;
maximum-power 65;
telemetries;
If you are done configuring the device, enter commit in configuration mode.
Verification
To confirm that the configuration is working properly, perform these tasks:
• Verifying the Status of PoE Interfaces on page 147

• Verifying the Telemetry Data (History) for the Specified Interface on page 148
• Verifying PoE Global Parameters on page 148
Verifying the Status of PoE Interfaces
Purpose Verify that the PoE interfaces are enabled and set to the desired priority settings.
Action In operational mode, enter the show poe interface ge-0/1/3 command.
user@host> show poe interface ge-0/1/3

PoE interface status:
PoE interface : ge-0/1/3
Administrative status : Enabled
Operational status : Powered-up
Power limit on the interface : 65 W
Priority : High

Power consumed : 6.6 W

Class of power device : 0
Meaning The show poe interface ge-0/1/3 command lists PoE interfaces configured on the
ACX2000 router, with their status, priority, power consumption, and class.
Verifying the Telemetry Data (History) for the Specified Interface
Purpose Verify the PoE interface's power consumption over a specified period.
Action In operational mode, enter the show poe telemetries interface command.
For all records:
user@host> show poe telemetries interface ge-0/1/3 all

Interface Sl No Timestamp Power Voltage
1 Mon May 14 00:45:05 2012 14.2 W 53.9 V
2 Mon May 14 00:44:04 2012 14.2 W 53.9 V
3 Mon May 14 00:43:03 2012 14.2 W 53.9 V
For a specific number of records:
user@host> show poe telemetries interface ge-0/1/3 2

Interface Sl No Timestamp Power Voltage
1 Mon May 14 00:45:05 2012 14.2 W 53.9 V
2 Mon May 14 00:44:04 2012 14.2 W 53.9 V
Meaning The telemetry status displays the power consumption history for the specified interface,
provided telemetry has been configured for that interface.
Verifying PoE Global Parameters
Purpose Verify global parameters such as guard band, power limit, and power consumption.
Action In operational mode, enter the show poe controller command.
user@host> show poe controller

Controller Maximum Power Guard Management Status Lldp
index power consumption band Priority
0 130.0 W 14.2 W 0 W high-power UP
Meaning The show poe controller command lists the global parameters configured on the router.
Related • Understanding PoE on ACX Series Universal Access Routers on page 142
Documentation

Example: Disabling a PoE Interface on ACX2000 Routers
This example shows how to disable PoE on all interfaces or on a specific interface.

Requirements
Before you begin:
• Configure PoE on all interfaces. See “Example: Configuring PoE on ACX2000 Routers”
on page 144.
Overview
In this example, you disable PoE on all interfaces and on a specific interface, which in
this case is ge-0/1/3.
Configuration
Step-by-Step • Disable PoE on all interfaces.

Procedure
[edit]
user@host# set poe interface all disable
• Disable PoE on a specific interface.
[edit]
user@host# set poe interface ge-0/1/3 disable
Verification
To verify the configuration is working properly, enter the show poe interface command.
user@host> show poe interface
Interface Admin Oper Max Priority Power Class

status status power consumption
ge-0/1/3 Disabled Disabled 32.0W Low 0.0W 0
ge-0/1/7 Disabled Disabled 32.0W Low 0.0W 0
user@host> show poe interface ge-0/1/3
PoE interface status:

PoE interface : ge-0/1/3
Administrative status : Disabled
Operational status : Disabled
Power limit on the interface : 32.0 W
Priority : Low

Power consumed : 0.0 W

Class of power device : 0
Documentation
Configuring a Service Package to be Used in Conjunction with PTP
On ACX1100 routers, you can configure a service package on the router for the RFC
2544-based benchmarking test, or for NAT and IPsec applications. When you configure
the service package for the RFC 2544-based benchmarking test or for the NAT and IPsec
applications, a reboot of the Forwarding Engine Board (FEB) occurs to apply the service
package selection. By default, the service package for RFC 2544 benchmarking test is
selected. The selection of a service package is needed on ACX1100 routers when you
configure such routers for IEEE 1588v2 Precision Time Protocol (PTP) because both RFC
2544-based benchmarking tests and a combination of NAT and IPsec protocols are not
supported simultaneously; you can configure only PTP and RFC 2544-based tests, or
PTP and the combination of NAT and IPsec at a point in time.
You need to specify the service package to be RFC 2544-based or NAT and IPsec-based
only for ACX1100-AC routers. The selection of a service package is not needed on ACX
Series routers other than the ACX1100-AC and ACX500 routers because on such routers,
only the RFC 2544-based benchmarking tests are supported; NAT and IPsec applications
are not supported on those routers.
To configure the RFC 2544-based service package on a particular FPC, include the
service-package bundle-rfc2544 statement at the [edit chassis fpc slot-number] hierarchy
level.
[edit chassis]
fpc slot-number {
service-package bundle-rfc2544;
}
To configure the NAT and IPsec applications service package on a particular FPC, include
the service-package bundle-nat-ipsec statement at the [edit chassis fpc slot-number]
hierarchy level.
[edit chassis]
fpc slot-number {
service-package bundle-nat-ipsec;
}
Related • service-package on page 1714

Documentation
Checklist for Monitoring Fast Ethernet and Gigabit Ethernet Interfaces
Purpose To monitor Fast Ethernet and Gigabit Ethernet interfaces and begin the process of isolating
interface problems when they occur.

Action Table 23 on page 151 provides links and commands for monitoring Fast Ethernet and
Gigabit Ethernet interfaces.
Table 23: Checklist for Monitoring Fast Ethernet and Gigabit Ethernet
Interfaces
Tasks Command or Action
Monitor Fast Ethernet and Gigabit Ethernet Interfaces

1. Display the Status of Fast Ethernet Interfaces show interfaces terse (fe* | ge*)
2. Display the Status of a Specific Fast Ethernet or Gigabit show interfaces (fe-fpc/pic/port | ge-fpc/pic/port)
Ethernet Interface
3. Display Extensive Status Information for a Specific Fast show interfaces (fe-fpc/pic/port | ge-fpc/pic/port) extensive
Ethernet or Gigabit Ethernet Interface
4. Monitor Statistics for a Fast Ethernet or Gigabit Ethernet monitor interface (fe-fpc/pic/port | ge-fpc/pic/port)
Interface
5. Fiber-Optic Ethernet Interface Specifications
Meaning You can use the above described commands to monitor and to display the configurations
for Fast Ethernet and Gigabit Ethernet interfaces.
Related • Display the Status of Gigabit Ethernet Interfaces

Documentation
• Display the Status of Fast Ethernet Interfaces
Checklist for Monitoring T1 Interfaces
Purpose To monitor T1 interfaces and begin the process of isolating T1 interface problems when
they occur.
Action Table 24 on page 151 provides the links and commands for monitoring T1 interfaces.
Table 24: Checklist for Monitoring T1 Interfaces

Tasks Command or Action
Monitor T1 Interfaces
1. Display the Status of T1 Interfaces show interfaces terse t1*
2. Display the Status of a Specific T1 Interface show interfaces t1-fpc/pic/port
3. Display Extensive Status Information for a Specific T1 show interfaces t1-fpc/pic/port extensive
Interface
4. Monitor Statistics for a T1 Interface monitor interface t1-fpc/pic/port

Related • T1 Interfaces Overview

Documentation
•
Understanding Ethernet Link Aggregation on ACX Series Routers
Ethernet link aggregation is mechanism for increasing the bandwidth linearly and
improving the resiliency of Ethernet links by bundling or combining multiple full-duplex
same-speed point-to-point Ethernet links into a single virtual link. The virtual link interface
is referred to as link aggregation group (LAG) or aggregated Ethernet (AE) interface. The
LAG balances traffic across the member links within an aggregated Ethernet bundle and
effectively increases the uplink bandwidth. Another advantage of link aggregation is
increased availability, because the LAG is composed of multiple member links. If one
member link fails, the LAG continues to carry traffic over the remaining links.
NOTE: ACX Series routers support connectivity fault management (CFM)

on aggregated Ethernet interfaces with continuity check interval of 100
milliseconds or higher.
NOTE: ACX5048 and ACX5096 routers support connectivity fault

management (CFM) on aggregated Ethernet interfaces with continuity check
interval of 1 second or higher.
NOTE: The Ethernet options configurations for ACX5048 and ACX5096

routers differ compared to other ACX Series routers. For more information,
see “Understanding Layer 2 Next Generation Mode on ACX5048 and ACX5096
Routers” on page 1167.
On ACX Series routers, up to 128 AE interfaces can be created with each AE interface
having up to 8 physical interfaces. AE interfaces can be created across PICs and
fixed-ports on the chassis.
NOTE: On ACX5048 and ACX5096 routers, up to 64 AE interfaces can be

created with each AE interface having up to 16 physical interfaces.
ACX Series routers do not support statistics for aggregated Ethernet interface. However,
statistics can be retrieved for member interface.

To configure aggregated Ethernet interface:
1. Specify the number of aggregated Ethernet interfaces to be created:
[edit chassis]
user@host# set aggregated-devices ethernet device-count number
2. Specify the minimum number of links for the aggregated Ethernet interface (aex),
that is, the defined bundle, to be labeled “up”:
NOTE: By default only one link must be up for the bundle to be labeled
“up”.
[edit interfaces]
user@host# set ae0 aggregated-ether-options minimum-links number (1 — 8)
3. Specify the link speed for the aggregated Ethernet bundle:
[edit interfaces]
user@host# set ae0 aggregated-ether-options link-speed speed (10g | 1g | 100m)
4. Specify the members to be included within the aggregated Ethernet bundle:
[edit interfaces]
user@host# set ge-1/0/0 gigether-options 802.3ad ae0
user@host# set ge-1/0/1 gigether-options 802.3ad ae0
5. Specify an interface family for the aggregated Ethernet bundle:
[edit interfaces]
user@host# set ae0 unit 0 family inet address ip-address
The above procedure creates an AE interface and they would be up and ready for running
the services defined on AE logical interfaces.
AE interfaces can be VLAN-tagged or untagged. You can configure flexible-vlan-tagging,

native-vlan-id, and dual-tagging on AE interfaces.
NOTE: Whenever there is a configuration change (AE interface to Gigabit

Ethernet interfaces or vice versa), you need to remove the existing
configuration, perform a commit, then add the new configuration and again
commit the configuration.
To delete an aggregated Ethernet interface:
1. Delete the aggregated Ethernet configuration.
This step changes the interface state to down and removes the configuration
statements related to aex.
[edit]

user@host#delete interfaces aex
2. Delete the interface from the device count.
[edit]
user@host#delete chassis aggregated-devices ethernet device-count
For aggregated Ethernet interfaces, you can configure the Link Aggregation Control
Protocol (LACP). LACP is one method of bundling several physical interfaces to form
one logical interface. You can configure both VLAN-tagged and untagged aggregated
Ethernet with or without LACP enabled.
Load Balancing
JUNOS load-balances traffic across member links in an AE bundle based on the Layer 3
information in the packet. You can globally configure what fields are used for
load-balancing for inet and MPLS
On ACX Series Routers, the inet family knobs are available at PIC level. You can configure
inet family Layer 3 and Layer 4 fields to be used for load-balancing. For bridge family,
Layer 2, layer 3 and Layer 4 fields to be used for load-balancing.
ACX Series routers also support load balancing across the member links using Layer 2
source MAC addresses, destination MAC addresses, or both. This can be configured at
the [edit forwarding-options hash-key family multiservice] hierarchy level. Layer 2 source
MAC addresses and destination MAC addresses are used as hash-keys for load balancing.
[edit]
forwarding-options {
hash-key {
family multiservice {
destination-mac;
source-mac;
}
}
}
NOTE:
• For IP Layer 2 packets, only IP fields are used for load balancing across
member links. Source MAC address and destination MAC address are not
be used for load balancing.
• For non-IP Layer 2 packets, either Source MAC address or destination MAC
address is used as hash-keys for load balancing.
• If you want to hash based on layer 2 fields, then you need to configure
multiservice.
• If you want to hash based on layer 3 and layer 4 fields, then you need to
configure family (inet | inet6)

LACP Monitoring
LACP exchanges are made between actors and partners. An actor is the local interface
in an LACP exchange. A partner is the remote interface in an LACP exchange.
LACP is defined in IEEE 802.3ad, Aggregation of Multiple Link Segments.
LACP is designed to achieve the following:
• Automatic addition and deletion of individual links to the aggregate bundle without
user intervention
• Link monitoring to check whether both ends of the bundle are connected to the correct
group
The Junos OS implementation of LACP provides link monitoring but not automatic addition
and deletion of links.
LACP monitoring can be either distributed or centralized. The default is distributed and
it can be overriden by configuring the centralized knob under LACP protocols. LACP
exchanges are made between actors and partners. An actor is the local interface in an
LACP exchange. A partner is the remote interface in an LACP exchange.
By default, LACP does not initiate a LACP PDU exchange. LACP packets can be configured
to exchange LACP PDUs at a rate of 1 packet per second, or a slower rate of 1 packet for
30 seconds.
The LACP mode can be active or passive. If the actor and partner are both in passive
mode, they do not exchange LACP packets, which results in the aggregated Ethernet
links not coming up. If either the actor or partner is active, they do exchange LACP packets.
By default, LACP is turned off on aggregated Ethernet interfaces. If LACP is configured,
it is in passive mode by default. To initiate transmission of LACP packets and response
to LACP packets, you must configure LACP in active mode.
To enable LACP active mode, include the lacp statement at the [edit interfaces
interface-name aggregated-ether-options] hierarchy level, and specify the active option:
[edit interfaces interface-name aggregated-ether-options]

lacp {
active;
}
NOTE: The LACP process exists in the system only if you configure the system
in either active or passive LACP mode.
To restore the default behavior, include the lacp statement at the [edit interfaces
interface-name aggregated-ether-options] hierarchy level, and specify the passive option:
[edit interfaces interface-name aggregated-ether-options]

lacp {
passive;
}

Link Protection
Link protection can be configured on AE interfaces to provide 1:1 link resiliency using LACP.
Primary and backup links can be configured within an AE bundle. The primary link is used
for all transit traffic and host generated traffic. The backup link is used when the primary
link fails.
Link protection is supported only when the AE bundles have no more than 2 member
links, one primary and another backup. LACP works in revertive link-protection mode by
default and can be configured to work in non-revertive mode.
NOTE: Link protection without LACP (static link protection on AE interfaces)

is not supported on all ACX Series routers. Link protection works as expected
with LACP configured on the AE bundle.
• Configuring Link Protection for Aggregated Ethernet Interfaces on page 156

• Disabling Link Protection for Aggregated Ethernet Interfaces on page 156
Configuring Link Protection for Aggregated Ethernet Interfaces
Aggregated Ethernet interfaces support link protection to ensure QoS on the interface.
To configure link protection:
1. Configure the options for an aggregated Ethernet interface.
user@host# edit interfaces aex aggregated-ether-options
2. Configure the link protection mode.
[edit interfaces aex aggregated-ether-options]

user@host# set link-protection
Disabling Link Protection for Aggregated Ethernet Interfaces
To disable link protection, issue the delete interface revert aex configuration command.
user@host# delete interfaces aex aggregated-ether-options link-protection
Understanding the Algorithm Used to Hash LAG Bundle

ACX Series routers use a hashing algorithm to determine how to forward traffic over a
link aggregation group (LAG) bundle.
The hashing algorithm makes hashing decisions based on values in various packet fields,
as well as on some internal values like source port ID and source device ID. You can
configure some of the fields that are used by the hashing algorithm.
The hashing algorithm is used to make traffic-forwarding decisions for traffic entering a
LAG bundle.

For LAG bundles, the hashing algorithm determines how traffic entering a LAG bundle is
placed onto the bundle’s member links. The hashing algorithm tries to manage bandwidth
by evenly load-balancing all incoming traffic across the member links in the bundle.
The hashing algorithm makes hashing decisions based on values in various packet fields,
as well as on some internal values like source port ID and source device ID. The packet
fields used by the hashing algorithm varies by the packet’s EtherType and, in some
instances, by the configuration on the router. The hashing algorithm recognizes the
following EtherTypes:
• IPv4
• MPLS
Traffic that is not recognized as belonging to any of these EtherTypes is hashed based
on the Layer 2 header. IP and MPLS traffic are also hashed based on the Layer 2 header
when a user configures the hash mode as Layer 2 header.
You can configure some fields that are used by the hashing algorithm to make traffic
forwarding decisions. You cannot, however, configure how certain values within a header
are used by the hashing algorithm.
Note the following points regarding the hashing algorithm:
• The fields selected for hashing are based on the packet type only. The fields are not
based on any other parameters, including forwarding decision (bridged or routed) or
egress LAG bundle configuration (Layer 2 or Layer 3).
• The same fields are used for hashing unicast and multicast packets. Unicast and
multicast packets are, however, hashed differently.
Table 25 on page 157 describes the fields used for hashing by Layer 2 services. The table
explains the default behavior and the configurable fields based on the type of traffic
received on the Layer 2 service
Table 25: Hashing Behavior for Pseudowire (Layer 2 Circuit) and Bridging Services
Traffic Type Default Hash Fields Configurable Fields (Hash keys)
Layer 2 None Source MAC Address
Destination MAC
Source MAC and Destination MAC
IP Source IP and Destination IP Source MAC Address
Destination MAC
MPLS MPLS label 1 and MPLS label 2 Source MAC Address
Destination MAC

Table 26 on page 158 describes the fields used for hashing by Layer 3 services. The table
explains the default behavior and the configurable fields based on the type of traffic
received on the Layer 3 service
Table 26: Hashing Behavior for IP Services

Traffic Type Default Hash Fields Configurable Fields (Hash keys)
IP Source IP and Destination IP Layer 3 (Source IP and/or| destination IP)
Layer 4 (UDP/TCP source port andr UDP/TCP destination port)
Related • CoS on ACX Series Universal Access Routers Features Overview on page 864
Documentation
• Controlling Network Access Using Traffic Policing Overview on page 908
• Standard Firewall Filter Match Conditions and Actions on ACX Series Routers Overview
on page 1052
User-Defined Alarm Relay Overview
The ACX Series router alarm contact port—labeled ALARM on the front panel—allows
you to manage sensors and external devices connected to the router in remote unstaffed
facilities.
NOTE: Alarm contact port is not applicable on ACX5048 and ACX5096

routers.
• Alarm Contact Port on page 158

• Alarm Input on page 158
• Alarm Output on page 159
Alarm Contact Port

The ACX Series router alarm contact port is a 15-pin D-type dry contact connector for
alarms. The alarm contact port is used to generate LED alarms on the router and to turn
external devices on or off. You can connect up to four input alarms and two output alarms.
The alarm setting is open or closed.
Alarm Input
Alarm input provides dry contacts to connect to security sensors such as door or window
monitors. The alarm input—open or closed—is sensed and reported to the management
software. You can configure up to four alarm input relay ports (0 through 3) to operate
as normally open or normally closed, and to trigger a red alarm condition or a yellow
alarm condition or to ignore alarm conditions.

Alarm Output
Alarm output provides dry contacts to connect to external equipment, such as an audible
or visual alarm that switches on or off–for example, a bell or a light. The four alarm output
relay ports—0 through 3—are set up as follows:
• Ports 0 and 1—These ports can be configured to trigger an alarm when the system
temperature goes to the red alarm status and when an alarm input port is triggered.
• Ports 2 and 3—These ports are not configured. They are used to indicate system major
and minor alarms and are normally open. When a condition triggers an alarm, an alarm
message is displayed.
To view the alarm input and output relay information, issue the show chassis craft-interface
command from the Junos OS command line interface.
Related • Alarm Contact Port on the ACX2000 Router (Hardware topic)

Documentation
• Configuring Chassis Alarm Relays on page 159
• Configuring Chassis Alarm Input on page 160
• Configuring Chassis Alarm Output on page 161
• relay (Chassis Alarm) on page 1693
Configuring Chassis Alarm Relays
On ACX Series routers, you can configure alarm relays that can trigger alarms and turn
external devices on or off. For example, if the router heats up to more than the critical
temperature, the output port is activated and a device connected to the output port—such
as a fan—is turned on.
To configure conditions that trigger alarms, include the relay statement with the input
and output options at the [edit chassis alarm] hierarchy level.
[edit chassis alarm]

relay
input {
port port-number {
mode (close | open);
trigger (ignore | red | yellow);
}
}
output{
port port-number {
input-relay input-relay;
temperature;
}
}

The following output shows an example configuration of a chassis relay alarm:
[edit chassis alarm]

user@host# show
relay {
input {
port 1 {
mode close;
trigger red;
}
}
output {
port 0 {
temperature;
}
}
}
Related • User-Defined Alarm Relay Overview on page 158

Documentation
• input on page 1566
• output on page 1646
• show chassis craft-interface on page 1865
• show chassis alarms on page 1845
Configuring Chassis Alarm Input
facilities. You can configure up to four alarm input ports (0 through 3) to operate as
normally open or normally closed, and to trigger a red alarm condition or a yellow alarm
condition or to ignore alarm conditions.
To configure an input alarm:
1. Configure the input port:
[edit chassis alarm relay input port port-number]
For example, to configure input port zero (0):
user@host# edit chassis alarm relay input port 0
2. Configure the mode in which the input alarm is not active:
[edit chassis alarm relay input port port-number mode (close | open)]
For example, to configure open mode:
[edit chassis alarm relay input port 0]

user@host# set mode open
3. Configure the trigger to set off the alarm:

[edit chassis alarm relay input port port-number trigger (ignore | red | yellow)]
For example, to set off the yellow alarm:

user@host# set trigger yellow
4. Verify the configuration with the show command:

user@host# show
mode open;
trigger yellow;
5. Commit the configuration with the commit command.
To view the alarm input relay information, issue the show chassis alarms or show chassis
craft-interface commands from the Junos OS command line interface.

Documentation
• output on page 1646
Configuring Chassis Alarm Output
facilities. You can configure up to two alarm output relay ports (0 and 1) to operate as
normally open or normally closed, and to trigger an alarm when the system temperature
goes to the red alarm status and when an alarm input port is triggered.
NOTE: Ports 2 and 3 are not configured. They are used to indicate system
major and minor alarms and are normally open. When a condition triggers
an alarm, an alarm message is displayed, and the corresponding LED turns
on.
To configure an output alarm:
1. Configure the output port:
[edit chassis alarm relay output port port-number]
For example, to configure output port zero (0):
user@host# edit chassis alarm relay output port 0
2. Configure the trigger to set off the alarm:

[edit chassis alarm relay output port port-number (input-relay | mode | temperature)]
For example, to set off the alarm when the system temperature goes into the red
status:
[edit chassis alarm relay output port 0]

user@host# set temperature
3. Verify the configuration with the show command:
[edit chassis alarm relay output port 0]

user@host# show
temperature;
4. Commit the configuration with the commit command.
To view the alarm output relay information, issue the show chassis alarms or show chassis
craft-interface command from the Junos OS command line interface.

Documentation
• input on page 1566
Chassis Definitions for Router Model MIB for ACX Series Routers
The enterprise-specific Chassis Definitions for Router Model MIB contain the OIDs that
are used by the Chassis MIB to identify platform and chassis components. The Chassis
Definitions for Router Model MIB provide information that changes less often.
The last number in each sysObjectId, shown in Table 27 on page 162, corresponds to the
router model and therefore does not change. This table displays the different ACX router
model numbers, their jnxProductName object names, and the associated sysObjectId
values.
Table 27: Router Models and Their sysObjectIds for ACX Series Routers
Model SysObjectID jnxProductName
ACX1000 1.3.6.1.4.1.2636.1.1.1.1.113 jnxProductNameACX1000

Table 27: Router Models and Their sysObjectIds for ACX Series
Routers (continued)
Model SysObjectID jnxProductName
For a downloadable version of the Chassis Definitions for Router Model MIB, see
http://www.juniper.net/techpubs/en_US/junos15.1/topics/reference/mibs/mib-jnx-chas-defines.txt.
Related • Chassis MIBs

Documentation
• Chassis MIB Textual Conventions
• Chassis Traps


CHAPTER 5
Configuring E1 and T1 Interfaces
• Configuring E1 BERT Properties on page 165

• Configuring E1 Loopback Capability on page 167
• Configuring T1 BERT Properties on page 168
• Configuring T1 Loopback Capability on page 170
Configuring E1 BERT Properties
This topic discusses BERT properties for the E1 interface specifically. For general
information about the Junos OS implementation of the BERT procedure, see Configuring
Interface Diagnostics Tools to Test the Physical Layer Connections.
You can configure an E1 interface or a CE1 or E1 partition on a channelized PIC to execute

a bit error rate test (BERT) when the interface receives a request to run this test. You
specify the duration of the test and the error rate to include in the bit stream by including
the bert-period and bert-error-rate statements at the [edit interfaces interface-name
e1-options] hierarchy level:
[edit interfaces interface-name e1-options]

bert-error-rate rate;
bert-period seconds;
By default, the BERT period is 10 seconds. You can configure the BERT period to last
from 1 through 239 seconds on some PICs and from 1 through 240 seconds on other PICs.
Standard CE1, standard E1, E1 IQ, and E1 IQE interfaces, and PICs partitioned to CE1 and
E1 channels, support an extended BERT period range, up to 86,400 seconds (24 hours),
and have a default BERT period value of 240 seconds.
NOTE: When configuring E1 and CE1 interfaces on 10-port Channelized E1/T1

IQE PICs, you must include the bert-period statement at the [edit interfaces
ce1-fpc/pic/port] hierarchy level.
NOTE: When configuring CE1 interfaces on the 16-port Channelized E1/T1

Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE), you must include BERT
configuration options at the [edit interfaces ce1-fpc/pic/port] hierarchy level.

rate is the bit error rate. This can be an integer from 0 through 7, which corresponds to a
–0 –7
bit error rate from 10 (0, which corresponds to no errors) to 10 (1 error per 10 million
bits). The default is 0.
NOTE: The bit-error-rate statement in BERT procedure is not supported on

the 16-port Channelized E1/T1 Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE).
Individual concatenated E1 interfaces do not support the bert-algorithm configuration

statement. For individual concatenated E1 interfaces, the bert-algorithm statement at
the [edit interfaces interface-name e1-options] hierarchy level is ignored. The algorithm
15
for the E1 BERT procedure is pseudo-2e15-o151 (pattern is 2 –1, as defined in the CCITT/ITU
O.151 standard).
For channelized E1 intelligent queuing (IQ and IQE) interfaces, you can configure the
BERT algorithm by including the bert-algorithm statement at the [edit interfaces
ce1-fpc/pic/port e1-options] or [edit interfaces e1-fpc/pic/port e1-options] hierarchy level:
[edit interfaces ce1-fpc/pic/port e1-options]

bert-algorithm algorithm;
[edit interfaces e1-fpc/pic/port e1-options]
For a list of supported algorithms, enter a ? after the bert-algorithm statement; for
example:
[edit interfaces ce1-0/0/0 e1-options]

user@host# set bert-algorithm ?
Possible completions:
pseudo-2e11-o152 Pattern is 2^11 -1 (per O.152 standard)
pseudo-2e15-o151 Pattern is 2^15 - 1 (per O.151 standard)
For specific hierarchy information, see individual interface types. For information about
running the BERT procedure, see the CLI Explorer.
Related • Configuring T1 BERT Properties on page 168

Documentation
• Configuring Interface Diagnostics Tools to Test the Physical Layer Connections

Chapter 5: Configuring E1 and T1 Interfaces
Configuring E1 Loopback Capability
You can configure loopback capability between the local E1 interface and the remote
channel service unit (CSU), as shown in Figure 18 on page 167. You can configure the
loopback to be local or remote. With local loopback, the E1 interface can transmit packets
to the CSU, but receives its own transmission back again and ignores data from the CSU.
With remote loopback, packets sent from the CSU are received by the E1 interface,
forwarded if there is a valid route, and immediately retransmitted to the CSU.
Figure 18: Remote and Local E1 Loopback
To exchange BERT patterns between a local router and a remote router, include the
loopback remote statement in the interface configuration at the remote end of the link.
From the local router, you issue the test interface command.
For more information about configuring BERT, see Configuring Interface Diagnostics Tools
to Test the Physical Layer Connections. For more information about using operational
mode commands to test interfaces, see the CLI Explorer.
To configure E1 Loopback capability on an E1 interface:
1. In the configuration mode go to the [edit interfaces interface-name e1-options] hierarchy

level.
[edit]
user@host# edit interfaces interface-name fpc/pic/port e1-options
2. Include the loopback statement. Note that the loopback local statement causes the
interface to loop within the PIC just before the data reaches the transceiver.
[edit interfaces interface-name fpc/pic/port e1-options ]

user@host# set loopback (local | remote)
3. To determine whether a problem is internal or external, loop packets on both the local
and the remote router. Include the no-keepalives and encapsulation cisco-hdlc
statements at the [edit interfaces interface name] hierarchy level. With this
configuration, the link stays up, so you can loop ping packets to a remote router.

user@host# set no-keepalives
user@host# set encapsulation cisco-hdlc

4. Check the error counters in the output of the show interface interface-name extensive
to determine whether there is an internal problem or an external problem.
user@host# show interfaces interface-name extensive
5. View the configuration by issuing the show command at the [edit interfaces
e1-fpc/pic/port ] hierarchy level.
[edit interfaces]
user@host# show
e1-1/0/0 {
no-keepalives;
encapsulation cisco-hdlc;
e1-options {
loopback local;
}
unit 0 {
family inet {
address 10.100.100.1/24;
}
}
}
NOTE:
• You can turn off the loopback capability by removing the loopback
statement from the configuration
[edit]
user@host# delete interfaces e1-fpc/pic/port e1-options loopback
• You can configure the CE1 loopback capability on the 16-port Channelized
E1/T1 Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE), by including the
loopback statement at the [edit interfaces ce1-fpc/pic/port] hierarchy level.
Related • Configuring T1 Loopback Capability on page 170

Documentation
• Performing a Loopback Test on an Interface
Configuring T1 BERT Properties
This section discusses BERT properties for the T1 interface specifically. For general
information about the Junos implementation of the BERT procedure, see Configuring
Interface Diagnostics Tools to Test the Physical Layer Connections.
You can configure a T1 interface or partitioned CT1 or T1 channel to execute a bit error
rate test (BERT) when the interface receives a request to run this test. You specify the
duration of the test and the error rate to include in the bit stream by including the
bert-period and bert-error-rate statements at the [edit interfaces interface-name t1-options]
hierarchy level:

[edit interfaces interface-name t1-options]

bert-error-rate rate;
bert-period seconds;
seconds is the duration of the BERT procedure. The test can last from 1 through
239 seconds; the default is 10 seconds. Standard CT1, standard T1, T1 IQ, and T1 IQE
interfaces, and PICs partitioned to CT1 and T1 channels, support an extended BERT period
range, up to 86,400 seconds (24 hours), and have a default BERT period value of 240
seconds.
NOTE: When configuring T1 and CT1 interfaces on 10-port Channelized E1/T1

IQE PICs, the bert-period statement must be included at the [edit interfaces
ct1-fpc/pic/port] hierarchy level.
NOTE: When configuring CT1 interfaces on the 16-port Channelized E1/T1

Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE), you must include BERT
configuration options at the [edit interfaces ct1-fpc/pic/port] hierarchy level.
rate is the bit error rate. This can be an integer from 0 through 7, which corresponds to a
–0 –7
bit error rate from 10 (1 error per bit) to 10 (1 error per 10 million bits).
algorithm is the pattern to send in the bit stream. On T1 interfaces, you can also select
the pattern to send in the bit stream by including the bert-algorithm statement at the
[edit interfaces interface-name interface-options] hierarchy level:
[edit interfaces interface-name interface-options]

For a list of supported algorithms, enter a ? after the bert-algorithm statement; for
example:
[edit interfaces t1-0/0/0 t1-options]

user@host# set bert-algorithm ?
Possible completions:
pseudo-2e11-o152 Pattern is 2^11 -1 (per O.152 standard)
NOTE: The bit-error-rate statement in BERT procedure is not supported on

the 16-port Channelized E1/T1 Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE).
For specific hierarchy information, see individual interface types. For information about
running the BERT procedure, see the CLI Explorer.
Related • Configuring E1 BERT Properties on page 165

Documentation

• Configuring Interface Diagnostics Tools to Test the Physical Layer Connections
Configuring T1 Loopback Capability
You can configure loopback capability between the local T1 interface and the remote
channel service unit (CSU), as shown in Figure 19 on page 170. You can configure the
loopback to be local or remote. With local loopback, the T1 interface can transmit packets
to the CSU, but receives its own transmission back again and ignores data from the CSU.
With remote loopback, packets sent from the CSU are received by the T1 interface,
forwarded if there is a valid route, and immediately retransmitted to the CSU.
Figure 19: Remote and Local T1 Loopback
To configure loopback capability on a T1 interface, include the loopback statement at

the [edit interfaces interface-name t1-options] hierarchy level:
[edit interfaces interface-name t1-options]

loopback (local | payload | remote);
Packets can be looped on either the local router or the remote CSU. Local and remote
loopback loop back both data and clocking information.
To exchange BERT patterns between a local router and a remote router, include the
loopback remote statement in the interface configuration at the remote end of the link.
From the local router, issue the test interface command.
For more information about configuring BERT, see Configuring Interface Diagnostics Tools
to Test the Physical Layer Connections. For more information about using operational
mode commands to test interfaces, see the CLI Explorer.
For channelized T3, T1, and NxDS0 intelligent queuing (IQ) interfaces only, you can include
the loopback payload statement in the configuration to loop back data only (without
clocking information) on the remote router’s PIC. In payload loopback, overhead is
recalculated. For T3 IQ interfaces, you can include the loopback payload statement at
the [edit interfaces ct3-fpc/pic/port] and [edit interfaces t3-fpc/pic/port:channel] hierarchy
levels. For T1 interfaces, you can include the loopback payload statement in the
configuration at the [edit interfaces t1-fpc/pic/port:channel] hierarchy level; it is ignored
if included at the [edit interfaces ct1-fpc/pic/port] hierarchy level. For NxDS0 interfaces,
payload and remote loopback are the same. If you configure one, the other is ignored.
NxDS0 IQ interfaces do not support local loopback.

To determine whether a problem is internal or external, you can loop packets on both
the local and the remote router. To do this, include the no-keepalives and encapsulation
cisco-hdlc statements at the [edit interfaces interface-name] hierarchy level and the
loopback local statement at the [edit interfaces interface-name t1-options] hierarchy level,
as shown in the following example:
[edit interfaces]
t1-1/0/0 {
no-keepalives;
encapsulation cisco-hdlc;
t1-options {
loopback local;
}
unit 0 {
family inet {
address 10.100.100.1/24;
}
}
}
NOTE: To configure the CT1 loopback capability on the 16-port Channelized

E1/T1 Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE), use the loopback
statement at the [edit interfaces ct1-fpc/pic/port] hierarchy level.
With this configuration, the link stays up, so you can loop ping packets to a remote router.
The loopback local statement causes the interface to loop within the PIC just before the
data reaches the transceiver.
To turn off the loopback capability, remove the loopback statement from the configuration:
[edit]
user@host# delete interfaces t1-fpc/pic/port t1-options loopback
You can determine whether there is an internal problem or an external problem by

checking the error counters in the output of the show interface interface-name extensive
command, for example:
user@host> show interfaces t1-fpc/pic/port extensive
Related • Configuring E1 Loopback Capability on page 167

Documentation
• Performing a Loopback Test on an Interface


CHAPTER 6
Configuring ATM Interfaces
• ATM Pseudowire Overview on page 173

• Understanding ATM IMA Configuration on ACX Series Router on page 174
• Configuring ATM IMA on ACX Series on page 181
• ATM OAM F4 and F5 Cells on ACX Series Routers on page 185
• Defining the ATM OAM F5 Loopback Cell Period on page 187
• Configuring the ATM OAM F5 Loopback Cell Threshold on page 188
• Configuring the Timeout for Bundling of Layer 2 Circuit Cell-Relay Cells on page 188
• Configuring the Layer 2 Circuit Cell-Relay Cell Maximum Overview on page 189
ATM Pseudowire Overview
An Asynchronous Transfer Mode (ATM) pseudowire acts as a Layer 2 circuit or service,

which allows the migration of ATM services to an MPLS packet-switched network without
having to provision the ATM subscriber or customer edge (CE) device. When you configure
an ATM pseudowire, the network between the customer edge (CE) routers appears
transparent to the CE routers, making it seem that the CE routers are directly connected
across a time-division multiplex (TDM) leased line. ATM pseudowires are primarily used
in an ATM service provider’s network to connect existing ATM switches across a higher
speed packet-switched network or to provide ATM backhaul services for remote access
to existing ATM networks.
On ACX series routers, you configure an ATM pseudowire with Layer 2 encapsulation for

Documentation
• Pseudowire Overview for ACX Series Universal Access Routers on page 590
• TDM Pseudowires Overview on page 600
• Ethernet Pseudowire Overview on page 596

Understanding ATM IMA Configuration on ACX Series Router
IMA involves inverse multiplexing and demultiplexing of ATM cells in a round-robin

sequence among links grouped to form a higher-bandwidth logical link whose rate is the
sum of all the link rates. This group of links is called an IMA group. An IMA group can also
be defined as a group of links at the transmitting end that is used to establish an IMA
virtual link to the receiving end. The IMA virtual link is a virtual link that is established
between two IMA units or routers over a number of physical links (in an IMA group). IMA
groups terminate at each end of the IMA virtual link.
You can configure 42 IMA groups. Each group can contain from 1 through 32 links.
You can configure a maximum of 16 IMA groups on the 16-port Channelized E1/T1 Circuit
Emulation MIC (ACX-MIC-16CHE1-T1-CE) and each group can have from 1 through 8 IMA
links. Port numbers starting from 0 through 15 are used for T1/E1 ports; therefore, IMA
port numbers start from 16 onward.
You can configure a maximum of 16 IMA groups on the Channelized OC3/STM1

(Multi-Rate) Circuit Emulation MIC with SFP (ACX-MIC-4COC3-1COC12CE).
To configure an IMA group, execute the set chassis fpc fpc-slot pic pic-slot aggregated
devices ima device-count count configuration command, where count results in the
creation of interfaces from at-x/y/g through at-x/y/g+count-1. The variable g is picked
from 16 onward. For example, if the count variable is set to 4, then the new ATM interfaces
are created from at-x/y/16 through at-x/y/19.
You can implement inverse multiplexing for ATM (IMA) on Juniper Networks ACX Series
routers by configuring an IMA group and its options. The following sections explain the
various options that can be set for an IMA group:
• IMA Version on page 175

• IMA Frame Length on page 175
• Transmit Clock on page 175
• IMA Group Symmetry on page 175
• Minimum Active Links on page 176
• State Transition Variables: Alpha, Beta, and Gamma on page 176
• IMA Link Addition and Deletion on page 176
• IMA Test Pattern Procedure on page 177
• IMA Group Alarms and Group Defects on page 177
• IMA Link Alarms and Link Defects on page 178
• IMA Group Statistics on page 179
• IMA Link Statistics on page 180
• IMA Clocking on page 181
• Differential Delay on page 181

Chapter 6: Configuring ATM Interfaces
IMA Version
Either IMA 1.0 (af-phy-0086.000-IMA) or IMA 1.1 (af-phy-0086.001-IMA) can be selected
through the CLI. To choose the IMA specification version, execute the set interfaces
interface-name ima-group-options (1.0|1.1) configuration command. Note that, if you do
not specify the version, IMA 1.1 is selected by default.
NOTE: IMA 1.0 and IMA 1.1 do not interoperate.
The IMA v1.1 specification increments the operations and maintenance (OAM) label value
used in the IMA OAM cells in order to differentiate v1.1 from v1.0 IMA units.
IMA Frame Length

An IMA frame consists of ATM cells, an ICP cell, and filler cells (if required). When you
configure an IMA group, you can choose a frame length of 32, 64, 128, or 256. The frame
length can be selected independently in each direction and in each group. To set the
frame length, execute the set interface interface-name frame-length (32 |64 |128 |256)
configuration command. Note that if the frame length is not specified, the frame length
value of 128 is selected by default.
Transmit Clock
When you create an IMA group, you can configure a common transmit clock timing mode
or an independent transmit clock timing mode to reflect the primary reference source
(PRS) of the clock for each link in a group. By default, the common mode is selected. To
select the transmit clock timing mode, execute the set interface interface-name
ima-group-options transmit-clock (common | independent) configuration command.
IMA Group Symmetry

You can configure an IMA group to allow symmetric or asymmetric cell rate transfer over
an IMA virtual link. You can configure the IMA group with one of the following modes:
• Symmetrical configuration and operation—In this mode, on the ATM IMA device, an
IMA link must be configured in each direction for all physical links that the ATM IMA
device is configured to use. In this mode, the ATM IMA device can transmit and receive
ATM layer cells over the physical links on which the IMA links running in both directions
are Active.
• Symmetrical configuration and asymmetrical operation—In this mode, on the ATM

IMA device, an IMA link must be configured in each direction for all physical links that
the ATM IMA device is configured to use. In this mode, the ATM IMA device can transmit
ATM layer cells over the physical links on which the IMA links in the transmit direction
are Active, while the IMA links in the receive direction are not Active or contrariwise.
Asymmetrical configuration and operation are not supported.
The mode can be configured through the CLI when an IMA group is created. To select
the symmetry option, execute the set interface interface-name ima-group-options symmetry

(symmetrical-config-and-operation | symmetrical-config-asymmetrical-operation)
configuration command. By default, symmetrical configuration and operation is selected.
Minimum Active Links

You can set the minimum active links for an IMA group from 1 through 32.
• P is the minimum number of links required to be active in the transmit direction for
Tx
the IMA group to move into the operational state.
• P is the minimum number of links required to be active in the receive direction for the
Rx
IMA group to move into the operational state.
You configure P and P through the CLI when an IMA group is created. By default, 1 is
Tx Rx
selected.
For a symmetrical configuration, P is equal to P .

Tx Rx
To set minimum links, execute the set interface interface-name ima-group-options

minimum-links links configuration command. By default, symmetrical configuration and
operation is selected.
State Transition Variables: Alpha, Beta, and Gamma

Frame synchronization is a process of recovery of the aggregated frames. The frame
synchronization states form a basis for the different error and maintenance states. You
can configure the IMA frame synchronization link state transition variables as alpha, beta,
and gamma. The valid ranges and default values are shown in Table 28 on page 176.
Table 28: IMA Frame Synchronization Link State Transition Variables

Setting Range Default Description
alpha 1–2 2 Consecutive invalid ICP cells
beta 1–5 2 Consecutive errored ICP cells
gamma 1–5 1 Consecutive valid ICP cells
To set the frame synchronization option, execute the set interface interface-name
ima-group-options frame-synchronization alpha number beta number gamma number
configuration command.
IMA Link Addition and Deletion

When an IMA group is up, you can add links to or delete links from the group without
dropping cells.
To create an IMA link, you must:
• Configure the encapsulation as ima at the [edit interfaces interface-name encapsulation]

hierarchy level.

• Configure an ATM interface with one T1 link or one E1 link with the set interfaces
interface-name ima-link-options group-id g configuration command.
The interface-name variable refers to the T1 or E1 interface to be set as an IMA interface

link and the variable g refers to the port in the at-x/y/g interface.
To delete the configured IMA link, you must execute the following configuration
commands:
• delete interfaces interface-name encapsulation ima
• delete interfaces interface-name ima-link-options group g
IMA Test Pattern Procedure

A test pattern procedure is supported for IMA to test the ATM, T1, and E1 interfaces for
irregularities. You can use the CLI to start and end the test pattern procedure.
The following options can be set according to the requirement at the [edit interface
interface-name ima-group-options test-procedure] hierarchy level:
• interface interface-name—Interface name of the IMA link to test.
• pattern number—IMA test pattern that can be set from 1 through 254
• period number—Length of the IMA test pattern that can be set from 1 second through
4,294,967,294 seconds. Default is 10 seconds.
To perform the test pattern procedure, execute the test interface interface-name
ima-test-start and test interface interface-name ima-test-stop operational mode
commands to start and to stop the IMA test, respectively.
IMA Group Alarms and Group Defects

Table 29 on page 177 shows the supported IMA group alarms and their associated IMA
standard requirement numbers. This is displayed in the group status and control field of
an ICP cell.
Table 29: IMA Group Alarms with IMA Standard Requirement Numbers
Alarm IMA Standard Requirement Number
Start-up-FE R-145
Config-Aborted R-146
Config-Aborted-FE R-147
Insufficient-Links R-148
Insufficient-Links-FE R-149
Blocked-FE R-150

Table 29: IMA Group Alarms with IMA Standard Requirement Numbers (continued)
Alarm IMA Standard Requirement Number
Timing-Mismatch R-151
Blocked
Version-Mismatch
Table 30 on page 178 shows the supported IMA group defects and their associated IMA
standard requirement numbers. This is displayed in the group status and control field of
an ICP cell.
Table 30: IMA Group Defects with IMA Standard Requirement Numbers
Defects IMA Standard Requirement Number
Start-up-FE R-145
Config-Aborted R-146
Config-Aborted-FE R-147
Insufficient-Links R-148
Insufficient-Links-FE R-149
Blocked-FE R-150
Timing-Mismatch R-151
Blocked
Version-Mismatch
IMA Link Alarms and Link Defects

Table 31 on page 178 shows the supported IMA link alarms that are reported to the IMA
unit management with their associated IMA standard requirement numbers.
Table 31: IMA Link Alarms with IMA Standard Requirement Numbers
IMA Standard Requirement
Alarm Number Description
LIF R-138 Loss of IMA frame
LODS R-139 Link out of delay synchronization
RFI-IMA R-140 Remote defect/failure

Table 31: IMA Link Alarms with IMA Standard Requirement Numbers (continued)
Alarm Number Description
Tx-Mis-Connected R-141 Transmit misconnected
Rx-Mis-Connected R-142 Receive misconnected
Tx-Unusable-FE R-143 Transmit unusable far end
Rx-Unusable-FE R-144 Receive unusable far end
Link Fault Link fault
An IMA unit management is defined by SNMP MIBs.
Table 32 on page 179 shows the supported IMA link defects that are reported to the unit
management with their associated IMA standard requirement numbers.
Table 32: IMA Link Defects with IMA Standard Requirement Numbers
Defect Number Description
LIF R-138 Loss of IMA frame
LODS R-139 Link out of delay synchronization
RFI-IMA R-140 Remote defect/failure
Tx-Mis-Connected R-141 Transmit misconnected
Rx-Mis-Connected R-142 Receive misconnected
Tx-Unusable-FE R-143 Transmit unusable far end
Rx-Unusable-FE R-144 Receive unusable far end
Link Fault Link fault
IMA Group Statistics

You can use the show interfaces command to display the following IMA group statistics:
• Near-end failure count
• Far-end failure count
• Receive end (R ) faulty cells due to address mismatch

x

• Running seconds
• Unavailable seconds
For more information about IMA group statistics, see the show interfaces command
description in the CLI Explorer.
IMA Link Statistics

Table 33 on page 180 shows the IMA link statistics.
Table 33: IMA Link Statistics with IMA Standard Requirement Numbers
Performance Parameter IMA Standard Requirement Number
Rx LIF –
Rx ICP cells –
Rx errored ICP cells R-106
Rx LODS R-106
Rx ICP violation R-107
Rx stuff O-17
Near-end Rx SES R-108
Near-end Rx UAS R-110
Near-end Rx UUS R-113
Near-end Rx failure R-117
Near-end Tx failure –
Far-end Rx SES R-109
Far-end Rx UAS R-111
Far-end Rx UUS R-115
Far-end defects –
Far-end Rx failure –
Tx ICP cells –
Tx stuff O-16
Near-end Tx UUS R-112

Table 33: IMA Link Statistics with IMA Standard Requirement Numbers (continued)
Performance Parameter IMA Standard Requirement Number
Far-end Tx UUS R-114
Far-end Tx failure –
IMA Clocking
Interface clock source is applicable only to IMA links.
You can set the interface clock source as external or internal with the set interfaces
at-x/y/z clocking (external | internal) configuration command. Note that the clocking
statement is not applicable to the at-x/y/g interface because the IMA group it represents
is a virtual interface.
Differential Delay
You can set the maximum differential delay from 1 millisecond through 56 milliseconds
among links in an IMA group. By default, a differential delay of 25 milliseconds is set.
Execute the set interfaces interface-name ima-group-options differential-delay delay
configuration command to set the differential delay.
Related • Configuring ATM IMA on ACX Series on page 181

Documentation
Configuring ATM IMA on ACX Series
The following sections explain how to create an ATM IMA group and to configure it
according to your requirements:
• Creating an IMA Group (ATM Interfaces) on page 181

• Configuring Group ID for an IMA Link on a T1 Interface or an E1 Interface on page 182
• Configuring ATM Encapsulation Options on page 182
• Configuring IMA Group Options on page 183
Creating an IMA Group (ATM Interfaces)

To create an IMA group, perform the following steps:
1. In configuration mode, go to the [edit chassis] hierarchy level:
[edit]
2. Configure the Flexible Port Concentrator (FPC) slot and the Physical Interface Card
(PIC) slot as needed.
[edit chassis]
user@host# set fpc fpc-slot pic pic-slot

3. Configure the device count. The device count can be set starting from 1 through 42 in
the aggregated device options for inverse multiplexing for ATM at the [edit chassis
fpc fpc-slot pic pic-slot] hierarchy level.
[edit chassis fpc fpc-slot pic pic-slot]

user@host# set aggregated-devices ima device-count count
This results in the creation of interfaces from at-x/y/g through at-x/y/g+count–1, where
the variable count is the number of interfaces and the variable g is picked from 16 onwards.
The PIC is automatically rebooted when a configuration that changes the IMA group
count is committed.
Configuring Group ID for an IMA Link on a T1 Interface or an E1 Interface

A group ID is assigned to all links in an IMA group.
To assign a group ID to a T1 or an E1 interface:
1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level, where

the interface name is t1-fpc/pic/port:m:n, e1-fpc/pic/port:n, or t1|e1-fpc/pic/port.
[edit]
user@host# edit interface interface-name
2. Configure the encapsulation as ima.
[edit interface interface-name]

user@host# set encapsulation ima
3. Configure the IMA group ID from 16 through 57. Note that this group ID is the same for
all T1/E1 interfaces for a particular ATM IMA interface.

user@host# set ima-link-options group-id number
Implement the aforementioned procedure to apply a group ID for all applicable T1 or E1

interfaces.
Configuring ATM Encapsulation Options

To configure the logical link-layer encapsulation for an ATM interface to support IMA:
1. In configuration mode, go to the [edit interfaces interface-name] hierarchy level, where

the interface name is at-fpc/pic/port.
[edit]
2. Configure the logical interface (unit) as 0 and set the encapsulation for this logical
interface as either ATM cell relay for CCC or ATM VC for CCC.

user@host# set unit 0 encapsulation (atm-ccc-cell-relay | atm-ccc-vc-mux)

Configuring IMA Group Options

To configure the various options for an IMA group on an ATM interface:
1. In configuration mode, go to the [edit interfaces interface-name ima-group-options]

hierarchy level, where the interface name is at-fpc/pic/port.
[edit]
user@host# edit interface interface-name ima-group-options
2. Configure the maximum differential delay between the links in the IMA group. You
can configure the maximum differential delay from 1 millisecond through 56
milliseconds. By default, 25 milliseconds is set.
[edit interface interface-name ima-atm-options]

user@host# set differential-delay delay
3. Configure the frame length of the ICP cell as 32, 64, 128, or 256. By default, 128 is set.

user@host# set frame-length length
4. Configure the IMA group frame synchronization state parameters alpha, beta, and
gamma.

user@host# set alpha number beta number gamma number
For the default values and parameter range for alpha, beta, and gamma, see
“Understanding ATM IMA Configuration on ACX Series Router” on page 174.
5. Configure IMA group minimum active links. You can configure between 1 to 16 links. 1
is set by default.

user@host# set minimum-links links
6. Configure the symmetry of the IMA group as either symmetrical configuration and
operation or symmetrical configuration and asymmetrical operation.

user@host# set symmetry (symmetrical-config-and-operation |
symmetrical-config-asymmetrical-operation)
For information about symmetry, see “Understanding ATM IMA Configuration on ACX
Series Router” on page 174.
7. Configure a test procedure to start and end the test pattern procedure.

user@host# set ima-test-start
user@host# ima-test-stop
user@host# interface interface-name

user@host# pattern number

user@host# period number
For information about test procedure, see “Understanding ATM IMA Configuration on
ACX Series Router” on page 174.
8. Configure a transmit clock to reflect the primary reference source (PRS) of the clock
for each link in a group either in common timing mode or independent timing mode.
By default, common timing mode is selected.

user@host# set transmit-clock (common | independent)
9. Configure the IMA specification version as either version 1.0 or version 1.1. By default,
IMA version 1.1 is selected.

user@host# set version (1.0|1.1)
Related • Understanding ATM IMA Configuration on ACX Series Router on page 174
Documentation
Inverse Multiplexing for ATM (IMA) Overview
Inverse multiplexing for ATM is a technique of transporting ATM traffic over a bundle of
T1 or E1 interfaces. Inverse multiplexing is the opposite of multiplexing. Multiplexing is a
technique of combining multiple signals into a single signal. Inverse multiplexing is a
technique that divides a data stream into multiple concurrent streams that are transmitted
at the same time across separate channels (such as T1 or E1 interfaces) and then
reconstructed at the other end back into the original data stream. Inverse multiplexing
is used to speed up the flow of data across a slower interface, such as a T1 or E1 interface,
by load balancing the data stream across multiple T1 or E1 interfaces, increasing the line
capacity.
With ATM inverse multiplexing, an ATM cell stream is transported over a bundle of T1 or
E1 interfaces called an IMA group. The ATM cells are inverse multiplexed and
demultiplexed cyclically across the IMA group to create a higher-bandwidth logical link
whose rate is approximately the sum of all the interfaces in the group.
Related • Configuring Inverse Multiplexing for ATM (IMA) on page 185

Documentation

Configuring Inverse Multiplexing for ATM (IMA)
Inverse multiplexing for ATM (IMA) is a standardized technology used to transport ATM
traffic over a bundle of T1 or E1 interfaces, also known as an IMA Group, allowing for an
increase in the bandwidth capacity. When you configure IMA on ACX Series routers, you
must configure the following:
• The aggregated device count—The device count is the number of IMA group interfaces
created on the CT1 or CE1 interfaces. The logical ATM interface that is part of the IMA
group has the following naming format: at-fpc/pic/port with the port number taken
from the last port on the MIC plus 1. For example, on the ACX2000 router with a 16-port
built-in T1/E1 TDM MIC, the IMA group interface numbering starts with at-0/0/16 and
increments by 1 to at-0/0/17, and so on. On the ACX1000 router with an 8-port built-in
T1/E1 TDM MIC, the IMA group interface numbering starts with at-0/0/8 and increments
by 1 to at-0/0/9, and so on
• The framing mode—Emulation is a mechanism that duplicates the essential attributes

of a service, such as T1 or E1, over a packet-switched network. The built-in channelized
T1 and E1 interfaces (CT1 and CE1) on the ACX Series routers can be configured to work
in either T1 or E1 mode, and these child T1 and E1 interfaces can be configured to carry
ATM services over the packet-switched network.
• One full T1 or E1 interface on the channelized CT1 or CE1 interface—The built-in

channelized interface is a non-configurable interface that requires a child T1 or E1 or
ATM interface on which you configure the parameters.
• The T1 or E1 interface as a member of the IMA group of the respective IMA link—Each
child T1 or E1 interface of a channelized CT1 or CE1 interface is the physical interface
over which the ATM signals are carried. This T1 or E1 interface must be specified as a
member of an IMA group so that the IMA link will work.
• IMA group interface configuration—Each IMA group interface (at-fpc/pic/port) must

be configured with all ATM properties for it to work properly: logical link-layer
encapsulation type, the circuit cross-connect protocol suite, and the entire ATM device
must be dedicated to the ATM cell relay circuit.
Configure IMA on built-in channelized T1 and E1 interfaces:
1. Configure the framing mode:

“Configuring SAToP Emulation on Channelized T1 and E1 Interfaces” on page 191
ATM OAM F4 and F5 Cells on ACX Series Routers
Circuit Emulation PICs on ACX Series routers provide Asynchronous Transfer Mode (ATM)
support for the following Operations, Administration, and Maintenance (OAM) fault
management cell types:

• F4 alarm indication signal (AIS) (end-to-end)
• F4 remote defect indication (RDI) (end-to-end)
• F4 loopback (end-to-end)
• F5 loopback
• F5 AIS
• F5 RDI
ATM OAM is supported on ACX1000, ACX2000, and ACX2200 routers, and on Channelized
E1/T1 Circuit Emulation MICs on ACX4000 routers.
The following methods of processing OAM cells that traverse through pseudowires with
circuit cross-connect (CCC) encapsulation are supported:
• Virtual path (VP) pseudowires (CCC encapsulation)—In the case of ATM VP

pseudowires (all virtual circuits in a VP are transported over a single N-to-one mode
pseudowire), all F4 and F5 OAM cells are forwarded through the pseudowire.
• Port pseudowires (CCC encapsulation)—Similar to VP pseudowires, with port

pseudowires, all F4 and F5 OAM cells are forwarded through the pseudowire.
• Virtual circuit (VC) pseudowires (CCC encapsulation)—In the case of VC pseudowires,

F5 OAM cells are forwarded through the pseudowire, while F4 OAM cells are terminated
at the Routing Engine.
For ATM pseudowires, the F4 flow cell is used to manage the VP level. On ACX Series
routers with ATM pseudowires (CCC encapsulation), you can configure OAM F4 cell
flows to identify and report virtual path connection (VPC) defects and failures. Junos OS
supports three types of OAM F4 cells in end-to-end F4 flows:
• Virtual path AIS
• Virtual path RDI
• Virtual path loopback
For OAM F4 and F5 cells, IP termination is not supported. Also, Junos OS does not support
segment F4 flows, VPC continuity check, or VP performance management functions.
The maximum number of ATM VCs that you can configure on ACX Series routers is 1000.
ACX Series routers do not support the transmission and reception of OAM F5 loopback
cells. Therefore, for ATM1 and ATM2 IQ interfaces with an ATM encapsulation, you cannot
configure the OAM F5 loopback cell period on virtual circuits on ACX Series routers.
For OAM F4 cells, on each VP, you can configure an interval during which to transmit
loopback cells by including the oam-period statement at the [edit interfaces interface-name
atm-options vpi vpi-identifier] hierarchy level. To modify OAM liveness values on a VP,
include the oam-liveness statement at the [edit interfaces interface-name atm-options
vpi vpi-identifier] hierarchy level.
For interfaces that are configured for ATM cell-relay promiscuous virtual path identifier
(VPI) mode, the show interfaces command output does not display the OAM F4 cell

statistics. Also, the Input OAM cell no buffers field is not displayed to indicate the number
of received OAM cells or raw cells dropped because of non-availability of buffers in the
output of the show interfaces command for ATM interfaces. You cannot configure a fiber
channel separately for OAM cells than the one used for other packets.
Layer 2 cell-relay encapsulation supports the concatenation (aggregation) of multiple

ATM cells in a single encapsulated packet that is transmitted on a pseudowire. By default,
each frame contains one cell. For ATM interfaces with Layer 2 circuit cell-relay transport
mode configured, you can configure the time threshold (in microseconds) that the router
uses to concatenate ATM cells and transmit the cells in a single frame on the pseudowire.
To set the period for which the ATM cells must be collected to be bundled in a single
frame being transmitted on the pseudowire, include the cell-bundle-timeout statement
at the [edit interfaces at-fpc/pic/port atm-options] or the [edit interfaces at-fpc/pic/port
unit logical-unit-number] hierarchy level.
You can also configure the maximum number of ATM cells per frame on the physical or
logical interface. To set the maximum number of cells per frame, include the
cell-bundle-size statement at the [edit interfaces at-fpc/pic/port atm-options] and the
[edit interfaces at-fpc/pic/port unit logical-unit-number] hierarchy levels. The cell bundle
size can be from 1 through 26.
Related • Defining the ATM OAM F5 Loopback Cell Period on page 187
Documentation
• Configuring the ATM OAM F5 Loopback Cell Threshold on page 188
• Configuring the Timeout for Bundling of Layer 2 Circuit Cell-Relay Cells on page 188
• Configuring the Layer 2 Circuit Cell-Relay Cell Maximum Overview on page 189
Defining the ATM OAM F5 Loopback Cell Period
For ATM1 and ATM2 IQ interfaces with an ATM encapsulation, you can configure the OAM
F5 loopback cell period on virtual circuits. This is the interval at which OAM F5 loopback
cells are transmitted.
By default, no OAM F5 loopback cells are sent. To send OAM F5 loopback cells, include
the oam-period statement:
oam-period (disable | seconds);
For a list of hierarchy levels at which you can include this statement, see oam-period.
The period can be from 1 through 900 seconds. You can also choose the disable option
to disable the OAM loopback cell transmit feature.
OAM VC-AIS and VC-RDI defect indication cells are used for identifying and reporting
VC defects end-to-end. When a physical link or interface failure occurs, intermediate
nodes insert OAM AIS cells into all the downstream VCs affected by the failure. Upon
receiving an AIS cell on a VC, the router marks the logical interface down and sends an
RDI cell on the same VC to notify the remote end of the error status. When an RDI cell is
received on a VC, the router sets the logical interface status to down. When no AIS or

RDI cells are received for 3 seconds, the router sets the logical interface status to up. You
do not need to configure anything to enable defect indication.
Configuring the ATM OAM F5 Loopback Cell Threshold
For ATM1 and ATM2 IQ interfaces with an ATM encapsulation, you can configure the
OAM F5 loopback cell threshold on VCs. This is the minimum number of consecutive
OAM F5 loopback cells received before a VC is declared up, or the minimum number of
consecutive OAM F5 loopback cells lost before a VC is declared down.
By default, when five consecutive OAM F5 loopback cells are received, the VC is considered
to be up, and when five consecutive cells are lost, the VC is considered to be down. To
modify these values, include the oam-liveness statement:
oam-liveness {
up-count cells;
down-count cells;
}
For a list of hierarchy levels at which you can include this statement, see oam-liveness.
The cell count can be a value from 1 through 255.
Configuring the Timeout for Bundling of Layer 2 Circuit Cell-Relay Cells
Layer 2 cell-relay encapsulation supports the concatenation (aggregation) of multiple

ATM cells in a single encapsulated packet that is transmitted on a pseudowire. By default,
each packet contains one cell. For ATM interfaces with Layer 2 circuit cell-relay transport
mode configured, you can configure the time threshold (in microseconds) that the router
uses to concatenate ATM cells and transmit the cells in a single frame on the pseudowire.
To set the period for which the ATM cells must be collected to be bundled in a single
frame being transmitted on the pseudowire, include the cell-bundle-timeout statement
at the [edit interfaces interface-name atm-options] or the [edit interfaces interface-name
unit logical-unit-number] hierarchy level.
Based on this configuration, the router attempts to collect and concatenate ATM cells
in a single ATM cell relay-encapsulated packet and transmit the packet on a pseudowire
connection. When the router detects that the allotted time interval has expired, the router
forwards the packet even if it contains fewer than the specified maximum number of
aggregated cells per packet. The cell concatenation or bundling functionality is controlled
by the timeout value and the maximum number of cells to be concatenated.
To configure the period for which the ATM cells are aggregated and bundled before they
are transmitted in a single frame on a pseudowire connection:
• Specify the number of microseconds for which the ATM cells must be bundled before
the timer expires and the cells are transmitted in a single frame.
[edit interfaces interface-name atm-options]

user@host# set cell-bundle-timeout microseconds

When the router detects that the allotted time interval has expired, the router forwards
the MPLS packet even if it contains fewer than the specified maximum number of
aggregated cells per packet.
Related • Configuring the Layer 2 Circuit Cell-Relay Cell Maximum Overview on page 189
Documentation
• cell-bundle-timeout
Configuring the Layer 2 Circuit Cell-Relay Cell Maximum Overview
By default, each frame contains one cell. For ATM interfaces with Layer 2 circuit cell-relay
transport mode configured, you can configure the maximum number of ATM cells per
frame on the physical or logical interface. To set the maximum number of cells per frame,
include the cell-bundle-size statement:
cell-bundle-size cells;
• [edit interfaces interface-name atm-options]
• [edit interfaces interface-name unit logical-unit-number]
• [edit logical-systems logical-system-name interfaces interface-name unit

logical-unit-number]
The cell bundle size can be from 1 through 176.
After 125 microseconds, cell bundling times out. This means that after 125 microseconds
if the frame does not contain the configured value, the frame is transmitted anyway.
If you include the cell-bundle-size statement at the [edit interfaces interface-name

atm-options] hierarchy level, then the configured value becomes the default for all the
logical interface units configured for that physical interface. If you include the
cell-bundle-size statement for a logical interface, the logical interface configuration
overrides the value configured at the physical interface level.
The transmit rates you configure on the routers at each end of the connection must be
the same value.
Class-Based Cell Bundling

For Layer 2 circuit trunk mode only, cell bundling is enhanced by a set of CoS and traffic
shaping rules, as follows:
• CBR and real-time variable bit rate (RTVBR) cells are not bundled. They are always
sent as single-cell packets.
• Cells with the same CLP bits are bundled together. This means all the cells in a bundle
contain the same CLP value.

• Cells with the same CoS bits are bundled together. This means all the cells in a bundle
belong to the same class of service.
• As alluded to in the previous rules, several triggers cause early packet transmission,
meaning that the packet is transmitted before the number of cells received is equal to
the value configured with the cell-bundle-size statement. These triggers are as follows:
• The next cell is of type CBR or RTVBR.
• The next cell has a different CLP bit.
• The next cell has different CoS bits.
• The 125-microsecond timer expires.
CoS-based cell bundling optimizes the release of a bundle by sending out the cell that
triggers early packet transmission as a single-cell packet. This means that when a cell
triggers early packet transmission, that cell is not bundled. Consequently, certain input
data patterns might cause primarily single-cell packets to be transmitted. For example,
say the output interface receives a steady pattern of two cells from a non-RTVBR queue,
followed by two cells from a UBR queue. In this case, all transmitted packets contain a
single cell because the first cell triggers a transition and is transmitted by itself. The
second cell is also transmitted by itself because the third cell triggers another transition,
and so on. This effect might not be dramatic with a mix of traffic; it is most evident with
steady traffic patterns, as generated by ATM test equipment programmed to emit regular
sequences of CoS queue transitions.

CHAPTER 7
Configuring SAToP Support on Interfaces
• Configuring SAToP Emulation on Channelized T1 and E1 Interfaces on page 191

• Configuring SAToP Emulation on T1/E1 Interfaces on 12-Port Channelized T1/E1 Circuit
Emulation PICs on page 196
• Configuring SAToP on 16-Port Channelized E1/T1 Circuit Emulation MIC on page 201
Configuring SAToP Emulation on Channelized T1 and E1 Interfaces
This configuration is the base configuration of SAToP on an ACX Series router as described
in RFC 4553, Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP).
When you configure SAToP on built-in channelized T1 and E1 interfaces, the configuration
results in a pseudowire that acts as a transport mechanism for the T1 and E1 circuit signals
across a packet-switched network.
The network between the customer edge (CE) routers appears transparent to the CE
routers, making it seem that the CE routers are directly connected. With the SAToP
configuration on the provider edge (PE) router’s T1 and E1 interfaces, the interworking
function (IWF) forms a payload (frame) that contains the CE router’s T1 and E1 Layer 1
data and control word. This data is transported to the remote PE over the pseudowire.
The remote PE removes all the Layer 2 and MPLS headers added in the network cloud
and forwards the control word and the Layer 1 data to the remote IWF, which in turn
forwards the data to the remote CE.
Figure 20: Pseudowire Encapsulation with SAToP

Emulated Service
g016956
Attachment Circuit PSN tunnel Attachment Circuit
Pseudowire 1
CE1 PE1 PE2 CE2
Pseudowire 2
Native service Native service
In Figure 20 on page 191 the Provider Edge (PE) router represents the ACX Series router
that is being configured in these steps. The result of these steps is the pseudowire from
PE1 to PE2. Topics include:
• Setting the T1/E1 Emulation Mode on page 192

• Configuring One Full T1 or E1 Interface on Channelized T1 and E1 Interfaces on page 193

• Setting the SAToP Encapsulation Mode on page 195

• Configure the Layer 2 Circuit on page 196
Setting the T1/E1 Emulation Mode

Emulation is a mechanism that duplicates the essential attributes of a service (such as
T1 or E1) over a packet-switched network. You set the emulation mode so that the built-in
channelized T1 and E1 interfaces on the ACX Series router can be configured to work in
either T1 or E1 mode. This configuration is at the PIC level, so all ports operate as either
T1 interfaces or E1 interfaces. A mix of T1 and E1 interfaces is not supported. By default
all the ports operate as T1 interfaces.
• Configure the emulation mode:

user@host# set framing (t1 | e1)
For example:
[edit chassis fpc 0 pic 0]

user@host# set framing t1
After a PIC is brought online and depending on the framing option used (t1 or e1), on
the ACX2000 router, 16 CT1 or 16 CE1 interfaces are created, and on the ACX1000
router, 8 CT1 or 8 CE1 interfaces are created.
The following output shows this configuration:
user@host# show chassis

fpc 0 {
pic 0 {
framing t1;
}
}
The following output from the show interfaces terse command shows the 16 CT1
interfaces created with the framing configuration.
user@host# run show interfaces terse

Interface Admin Link Proto Local Remote
ct1-0/0/0 up down
ct1-0/0/1 up down
ct1-0/0/2 up down
ct1-0/0/3 up down
ct1-0/0/4 up down
ct1-0/0/5 up down
ct1-0/0/6 up down
ct1-0/0/7 up down
ct1-0/0/8 up down
ct1-0/0/9 up down
ct1-0/0/10 up down
ct1-0/0/11 up down
ct1-0/0/12 up down
ct1-0/0/13 up down
ct1-0/0/14 up down
ct1-0/0/15 up down

Chapter 7: Configuring SAToP Support on Interfaces
NOTE: If you set the framing option incorrectly for the PIC type, the commit
operation fails.
If you change the mode, the router will reboot the built-in T1 and E1 interfaces.
Bit error rate test (BERT) patterns with all ones received by T1 and E1
interfaces configured for SAToP do not result in an alarm indication signal
(AIS) defect. As a result, the T1 and E1 interfaces remain up.
Configuring One Full T1 or E1 Interface on Channelized T1 and E1 Interfaces

You must configure a child T1 or E1 interface on the built-in channelized T1 or E1 interface
created because the channelized interface is not a configurable interface and SAToP
encapsulation must be configured (in the next step) for the pseudowire to function. The
following configuration creates one full T1 interface on the channelized ct1 interface. You
can follow the same process to create one E1 interface on the channelized ce1 interface.
• Configure one full T1/E1 interface:
[edit interfaces ct1-fpc/pic /port]

user@host# set no-partition interface-type (t1 | e1)
For example:
[edit interfaces ct1-0/0/0

user@host# set no-partition interface-type t1
The following output shows this configuration:
[edit]
user@host# show interfaces
ct1-0/0/0 {
no-partition interface-type t1;
}
The preceding command creates the t1-0/0/0 interface on the channelized ct1-0/0/0
interface. Check the configuration with the show interfaces interface-name extensive
command. Run the command to display output for the channelized interface and the
newly created T1 or E1interface. The following output provides an example of the output
for a CT1 interface and the T1 interface created from the preceding example configuration.
Notice that ct1-0/0/0 is running at T1 speed and that the media is T1.
user@host> show interfaces ct1-0/0/0 extensive

Physical interface: ct1-0/0/0, Enabled, Physical link is Up
Interface index: 152, SNMP ifIndex: 780, Generation: 1294
Link-level type: Controller, Clocking: Internal, Speed: T1, Loopback: None,
Framing: ESF, Parent: None
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps Internal: 0x0
Link flags : None
Hold-times : Up 0 ms, Down 0 ms
CoS queues : 8 supported, 4 maximum usable queues
Last flapped : 2012-04-03 06:27:55 PDT (00:13:32 ago)

Statistics last cleared: 2012-04-03 06:40:34 PDT (00:00:53 ago)

DS1 alarms : None
DS1 defects : None
T1 media: Seconds Count State
SEF 0 0 OK
BEE 0 0 OK
AIS 0 0 OK
LOF 0 0 OK
LOS 0 0 OK
YELLOW 0 0 OK
CRC Major 0 0 OK
CRC Minor 0 0 OK
BPV 0 0
EXZ 0 0
LCV 0 0
PCV 0 0
CS 0 0
CRC 0 0
LES 0
ES 0
SES 0
SEFS 0
BES 0
UAS 0
Line encoding: B8ZS
Buildout : 0 to 132 feet
DS1 BERT configuration:
BERT time period: 10 seconds, Elapsed: 0 seconds
Induced Error rate: 0, Algorithm: 2^15 - 1, O.151, Pseudorandom (9)
Packet Forwarding Engine configuration:
Destination slot: 0 (0x00)
In the following output for the T1 interface, the parent interface is shown as ct1-0/0/0
and the link level type and encapsulation are TDM-CCC-SATOP.
user@host> show interfaces t1-0/0/0 extensive

Physical interface: t1-0/0/0, Enabled, Physical link is Up
Link-level type: TDM-CCC-SATOP, MTU: 1504, Speed: T1, Loopback: None, FCS:
16, Parent: ct1-0/0/0 Interface index 152
Link flags : None
Last flapped : 2012-04-03 06:28:43 PDT (00:01:16 ago)
Statistics last cleared: 2012-04-03 06:29:58 PDT (00:00:01 ago)
Egress queues: 8 supported, 4 in use
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 0 0 0
1 expedited-fo 0 0 0
2 assured-forw 0 0 0
3 network-cont 0 0 0
Queue number: Mapped forwarding classes

0 best-effort

1 expedited-forwarding
2 assured-forwarding
3 network-control
DS1 alarms : None
DS1 defects : None
SAToP configuration:
Payload size: 192
Idle pattern: 0xFF
Octet aligned: Disabled
Jitter buffer: packets: 8, latency: 7 ms, auto adjust: Disabled
Excessive packet loss rate: sample period: 10000 ms, threshold: 30%
Destination slot: 0
CoS information:
Direction : Output
CoS transmit queue Bandwidth Buffer Priority
Limit
% bps % usec
0 best-effort 95 1459200 95 0 low
none
3 network-control 5 76800 5 0 low
none
Logical interface t1-0/0/0.0 (Index 308) (SNMP ifIndex 789) (Generation 11238)
Flags: Point-To-Point SNMP-Traps Encapsulation: TDM-CCC-SATOP

CE info Packets Bytes Count
CE Tx 0 0
CE Rx 0 0
CE Rx Forwarded 0
CE Strayed 0
CE Lost 0
CE Malformed 0
CE Misinserted 0
CE AIS dropped 0
CE Dropped 0 0
CE Overrun Events 0
CE Underrun Events 0
Protocol ccc, MTU: 1504, Generation: 13130, Route table: 0
Setting the SAToP Encapsulation Mode

The built-in T1 and E1 interfaces must be configured with SAToP encapsulation at the
PE router so that the interworking function (IWF) can segment and encapsulate TDM
signals into SAToP packets, and in the reverse direction, to decapsulate the SAToP
packets and reconstitute them into TDM signals.
1. On the PE router, configure SAToP encapsulation on the physical interface:
[edit interfaces (t1 | e1)–fpc/pic /port]

user@host# set encapsulation satop
For example:
[edit interfaces t1-0/0/0

user@host# set encapsulation satop
2. On the PE router, configure the logical interface:

[edit interfaces ]
user@host# set (t1 | e1)–fpc/pic/port unit logical-unit-number
For example:
[edit interfaces]
user@host# set t1-0/0/0 unit 0
It is not necessary to configure the circuit cross-connect (CCC) family because it is

automatically created for the preceding encapsulation. The following output shows
this configuration.
[edit interfaces]
user@host# show t1-0/0/0
encapsulation satop;
unit 0;
Configure the Layer 2 Circuit

When you configure the Layer 2 circuit, you designate the neighbor for the provider edge
(PE) router. Each Layer 2 circuit is represented by the logical interface connecting the
local PE router to the local customer edge (CE) router. All the Layer 2 circuits that use a
particular remote PE router, designated for remote CE routers, are listed under the neighbor
statement. Each neighbor is identified by its IP address and is usually the end-point
destination for the label-switched path (LSP) tunnel that transports the Layer 2 circuit.
Configure the Layer 2 circuit:
• [edit protocols l2circuit neighbor address]

user@host# set interface interface-name virtual-circuit-id identifier
For example, for a T1 interface:
[edit protocols l2circuit neighbor 2.2.2.2

user@host# set interface t1-0/0/0.0 virtual-circuit-id 1
The preceding configuration is for a T1 interface. To configure an E1 interface, use the

E1 interface parameters. The following output shows this configuration.
[edit protocols l2circuit]

user@host# show neighbor 2.2.2.2
interface t1-0/0/0.0 {
virtual-circuit-id 1;
}
Configuring SAToP Emulation on T1/E1 Interfaces on 12-Port Channelized T1/E1 Circuit

Emulation PICs
The following sections describes configuring SAToP on the 12-port Channelized T1/E1
Circuit Emulation PICs:
• Setting the Emulation Mode on page 197

• Configuring SAToP Emulation on T1/E1 Interfaces on page 197

Setting the Emulation Mode

To set the framing emulation mode, include the framing statement at the [edit chassis
fpc fpc-slot pic pic-slot] hierarchy level:

user@host# set framing (t1 | e1);
After a PIC is brought online, interfaces are created for the PIC’s available ports according
to the PIC type and the framing option used:
• If you include the framing t1 statement (for a T1 Circuit Emulation PIC), 12 CT1 interfaces
are created.
• If you include the framing e1 statement (for an E1 Circuit Emulation PIC), 12 CE1 interfaces
are created.
NOTE: If you set the framing option incorrectly for the PIC type, the commit
operation fails.
Circuit Emulation PICs with SONET and SDH ports require prior channelization
down to T1 or E1 before you can configure them. Only T1/E1 channels support
SAToP encapsulation or SAToP options.
Bit error rate test (BERT) patterns with all ones received by T1/E1 interfaces
on Circuit Emulation PICs configured for SAToP do not result in an alarm
indication signal (AIS) defect. As a result, the T1/E1 interfaces remain up.
Configuring SAToP Emulation on T1/E1 Interfaces

• Setting the Encapsulation Mode on page 197
• Configuring Loopback for a T1 Interface or an E1 Interface on page 198
• Setting the SAToP Options on page 198
• Configuring the Pseudowire Interface on page 199
Setting the Encapsulation Mode
E1 channels on Circuit Emulation PICs can be configured with SAToP encapsulation at

the provider edge (PE) router, as follows:
NOTE: The below mentioned procedure can be used to configure T1 channels

on circuit emulation PICs with SAToP encapsulation at the PE router.
1. In the configuration mode, go to [edit interfaces e1-fpc-slot/pic-slot/port] hierarchy

level.
[edit]
user@host# [edit interfaces e1 fpc-slot/pic-slot/port]

For example:
[edit]
[edit interfaces e1-1/0/0]
2. Configure SAToP encapsulation and the logical interface for E1 interface

user@host# set encapsulation encapsulation-typeunit interface-unit-number;
For example:

user@host# set encapsulation satop unit 0;
You do not need to configure any cross-connect circuit family because it is automatically
created for the above encapsulation.
Configuring Loopback for a T1 Interface or an E1 Interface
To configure loopback capability between the local T1 interface and the remote channel
service unit (CSU), see “Configuring T1 Loopback Capability” on page 170. To configure
loopback capability between the local E1 interface and the remote channel service unit
(CSU), see “Configuring E1 Loopback Capability” on page 167.
NOTE: By default, no loopback is configured.
Setting the SAToP Options
To configure SAToP options on T1/E1 interfaces:
1. In configuration mode, go to the [edit interfaces e1-fpc-slot/pic-slot/port] hierarchy

level.
[edit]
user@host# edit interfaces e1-fpc-slot/pic-slot/port
For example:
[edit]
user@host# edit interfaces e1-1/0/0
2. Use the edit command to go to the satop-options hierarchy level.
[edit]
user@host# edit satop-options
3. In this hierarchy level, using the set command you can configure the following SAToP
options:
• excessive-packet-loss-rate—Set packet loss options. The options are groups,

sample-period, and threshold.
• groups—Specify groups.

• sample-period—Time required to calculate excessive packet loss rate (from 1000

through 65,535 milliseconds).
• threshold—Percentile designating the threshold of excessive packet loss rate

(1–100 percent).
• idle-pattern—An 8-bit hexadecimal pattern to replace TDM data in a lost packet

(from 0 through 255).
• jitter-buffer-auto-adjust—Automatically adjust the jitter buffer.
NOTE: The jitter-buffer-auto-adjust option is not applicable on MX Series

routers.
• jitter-buffer-latency—Time delay in the jitter buffer (from 1 through 1000

milliseconds).
• jitter-buffer-packets—Number of packets in the jitter buffer (from 1 through 64

packets).
• payload-size—Configure the payload size, in bytes (from 32 through 1024 bytes).
NOTE: In this section, we are configuring only one SAToP option. You can
follow the same method to configure all the other SAToP options.
[edit interfaces e1-1/0/0 satop-options]

user@host# set excessive-packet-loss-rate sample-period sample-period
For example:
[edit interfaces e1-1/0/0 satop-options]

user@host# set excessive-packet-loss-rate sample-period 4000
To verify this configuration, use the show command at the [edit interfaces e1-1/0/0]
hierarchy level:

user@host# show
satop-options {
excessive-packet-loss-rate {
sample-period 4000;
}
}
Configuring the Pseudowire Interface
To configure the TDM pseudowire at the provider edge (PE) router, use the existing
Layer 2 circuit infrastructure, as shown in the following procedure:
1. In the configuration mode, go to [edit protocols l2circuit] hierarchy level.
[edit]
user@host# edit protocol l2circuit

2. Configure the IP address of the neighboring router or switch, interface forming the
layer 2 circuit and the identifier for the layer 2 circuit.
[edit protocol l2circuit]

user@host# set neighbor ip-address interface
interface-name-fpc-slot/pic-slot/port.interface-unit-number virtual-circuit-id
virtual-circuit-id;
NOTE: To configure T1 interface as the layer 2 circuit, replace e1 with t1 in

the below statement.
For example:

user@host# set neighbor 10.255.0.6 interface e1-1/0/0.0 virtual-circuit-id 1
3. To verify the configuration use the show command at the [edit protocols l2circuit]
hierarchy level.

user@host# show
neighbor 10.255.0.6 {
interface e1-1/0/0.0 {
}
}
After the customer edge (CE)-bound interfaces (for both PE routers) are configured with
proper encapsulation, payload size, and other parameters, the two PE routers try to
establish a pseudowire with Pseudowire Emulation Edge-to-Edge (PWE3) signaling
extensions. The following pseudowire interface configurations are disabled or ignored
for TDM pseudowires:
• ignore-encapsulation
• mtu
The supported pseudowire types are:
• 0x0011 Structure-Agnostic E1 over Packet
• 0x0012 Structure-Agnostic T1 (DS1) over Packet
When the local interface parameters match the received parameters, and the pseudowire
type and control word bit are equal, the pseudowire is established.
For detailed information about configuring TDM pseudowire, see the Junos OS VPNs
Library for Routing Devices.
For detailed information about PICs, see the PIC Guide for your router.

NOTE: When T1 is used for SAToP, the T1 facility data-link (FDL) loop is not
supported on the CT1 interface device. The is because SAToP does not analyze
T1 framing bits.
Related • Understanding Mobile Backhaul

Documentation
• Understanding Circuit Emulation Services and the Supported PIC Types
• Configuring SAToP on 4-Port Channelized OC3/STM1 Circuit Emulation MICs
Configuring SAToP on 16-Port Channelized E1/T1 Circuit Emulation MIC
The following sections describes configuring SAToP on the 16-Port Channelized E1/T1
Circuit Emulation MIC (MIC-3D-16CHE1-T1-CE).
• Configuring T1/E1 Framing Mode at the MIC Level on page 201

• Configuring CT1 Ports Down to T1 Channels on page 202
• Configuring CT1 Ports Down to DS Channels on page 202
Configuring T1/E1 Framing Mode at the MIC Level

To configure the framing emulation mode at the MIC level.
1. Go to the [edit chassis fpc fpc-slot pic pic-slot] hierarchy level.
[edit]
2. Configure the framing emulation mode as E1 or T1.

user@host# set framing (t1 | e1)
After a MIC is brought online, interfaces are created for the MIC’s available ports on the
basis of the MIC type and the framing option used:
• If you include the framing t1 statement, 16 channelized T1 (CT1) interfaces are created.
• If you include the framing e1 statement, 16 channelized E1 (CE1) interfaces are created.
NOTE: If you set the framing option incorrectly for the MIC type, the commit
operation fails.
By default, t1 framing mode is selected.
Circuit Emulation PICs with SONET and SDH ports require prior channelization
down to T1 or E1 before you can configure them. Only T1/E1 channels support
SAToP encapsulation or SAToP options.

Bit error rate test (BERT) patterns with all binary 1s (ones) received by CT1/CE1 interfaces
on Circuit Emulation MICs configured for SAToP do not result in an alarm indication signal
(AIS) defect. As a result, the CT1/CE1 interfaces remain up.
Configuring CT1 Ports Down to T1 Channels

To configure a CT1 port down to a T1 channel, use the following procedure:
NOTE: To configure a CE1 port down to the E1 channel, replace ct1 with ce1
and t1 with e1 in the procedure.
1. In configuration mode, go to the [edit interfaces ct1-mpc-slot/mic-slot/port-number]

hierarchy level.
[edit]
user@host# edit interfaces ct1-mpc-slot/mic-slot/port-number
For example:
[edit]
user@host# edit interfaces ct1-1/0/0
2. On the CT1 interface, set the no-partition option and then set the interface type as T1.
[edit interfaces ct1-mpc-slot/mic-slot/port-number]

In the following example, the ct1-1/0/1 interface is configured to be of type T1 and to

have no partitions.
[edit interfaces ct1-1/0/1]

Configuring CT1 Ports Down to DS Channels

To configure a channelized T1 (CT1) port down to a DS channel, include the partition
statement at the [edit interfaces ct1-mpc-slot/mic-slot/port-number] hierarchy level:
NOTE: To configure a CE1 port down to a DS channel, replace ct1 with ce1 in
the following procedure.

hierarchy level.
[edit]
For example:
[edit]

2. Configure the partition, the time slot, and the interface type.

user@host# set partition partition-number timeslots timeslots interface-type ds
In the following example, the ct1-1/0/0 interface is configured as a DS interface with

one partition and three time slots:

user@host# set partition 1 timeslots 1-4,9,22-24 interface-type ds
To verify the configuration of the ct1-1/0/0 interface, use the show command at the [edit
interfaces ct1-1/0/0] hierarchy level.

user@host# show
partition 1 timeslots 1-4,9,22-24 interface-type ds;
An NxDS0 interface can be configured from channelized T1 interface. Here N represents

the time slots on the CT1 interface. The value of N is:
• 1 through 24 when a DS0 interface is configured from a CT1 interface.
• 1 through 31 when a DS0 interface is configured from a CE1 interface.
After you partition the DS interface, configure the SAToP options on it. See “Setting the
SAToP Options” on page 198.
Related • Understanding Circuit Emulation Services and the Supported PIC Types
Documentation
• Setting the SAToP Options on page 198


CHAPTER 8
Configuring CESoPSN Support on

Interfaces

• Configuring CESoPSN on Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC
with SFP on page 206
• Configuring CESoPSN on Channelized E1/T1 Circuit Emulation MIC on page 220
Configuring CESoPSN Encapsulation on DS Interfaces
Circuit Emulation Service over Packet-Switched Network (CESoPSN) is an encapsulation

layer intended to carry NxDS0 services over a packet-switched network (PSN).
To configure CESoPSN encapsulation on a DS interface:
1. Create the DS interface.
[edit interfaces]
user@host# edit interface ds-fpc/pic/port:partition
For example:
[edit interfaces]
user@host# edit interface ds-0/0/1:1
2. Configure the encapsulation.
[edit interfaces ds-fpc/pic/port:partition]

user@host# set encapsulation cesopsn
3. Configure the logical interface.

user@host# set unit logical-unit-number
For example:
[edit interfaces ds-0/0/1:1]

user@host# set unit 0

When you are finished configuring CESoPSN encapsulation on the DS0 interface, enter
the commit command from configuration mode.
From configuration mode, confirm your configuration by entering the show command.
for example:
[edit interfaces]
user@host# show
ds-1/0/0:1:1 {
encapsulation cesopsn;
unit 0;
}

Documentation
Configuring CESoPSN on Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC

with SFP
To configure CESoPSN options on a Channelized OC3/STM1 (Multi-Rate) Circuit

Emulation MIC with SFP, you must configure the speed and framing mode at MIC level
and configure the encapsulation as CESoPSN on DS interfaces.
• Configuring SONET/SDH Rate-Selectability on page 206

• Configuring SONET/SDH Framing Mode at the MIC Level on page 207
• Configuring CESoPSN Encapsulation on DS Interfaces on CT1 Channels on page 208
• Configuring CESoPSN Encapsulation on DS Interfaces on CE1 Channels on page 211
Configuring SONET/SDH Rate-Selectability

You can configure rate-selectability on the Channelized OC3/STM1 (Multi-Rate) MICs
with SFP(MIC-3D-4COC3-1COC12-CE) by specifying the port speed. The Channelized
OC3/STM1 (Multi-Rate) Circuit Emulation MIC with SFP is rate-selectable and its port
speed can be specified as COC3-CSTM1 or COC12-CSTM4.
To configure port speed to select a speed option of coc3-cstm1 or coc12-cstm4:
1. In configuration mode, go to the [edit chassis fpc slot pic slot port slot] hierarchy level.
[edit]
user@host# edit chassis fpc slot pic slot port slot
For example:
[edit]
user@host# edit chassis fpc 1 pic 0 port 0
2. Set the speed as coc3-cstm1 or coc12-cstm4.
[edit chassis fpc slot pic slot port slot]

user@host# set speed (coc3-cstm1 | coc12-cstm4)

Chapter 8: Configuring CESoPSN Support on Interfaces
For example:
[edit chassis fpc 1 pic 0 port 0]

user@host# set speed coc3-cstm1
NOTE: When the speed is set as coc12-cstm4, instead of configuring COC3

ports down to T1 channels and CSTM1 ports down to E1 channels, you
must configure COC12 ports down to T1 channels and CSTM4 channels
down to E1 channels.
Configuring SONET/SDH Framing Mode at the MIC Level

To set the framing mode at the MIC (MIC-3D-4COC3-1COC12-CE) level, for all four ports
on the MIC, include the framing statement at the [edit chassis fpc slot pic slot] hierarchy
level.
[edit chassis fpc slot pic slot]

user@host# set framing (sonet | sdh) # SONET for COC3/COC12 or SDH for CSTM1/CSTM4
basis of the MIC type and the framing option used.
• If you include the framing sonet statement, four COC3 interfaces are created when the
speed is configured as coc3-cstm1.
• If you include the framing sdh statement, four CSTM1 interfaces are created when the
• If you include the framing sonet statement, one COC12 interface is created when the
• If you include the framing sdh statement, one CSTM4 interface is created when the
• If you do not specify framing at the MIC level, then the default framing is SONET for
all the ports.
operation fails.
Bit error rate test (BERT) patterns with all binary 1s (ones) received by CT1/CE1
interfaces on Circuit Emulation MICs configured for CESoPSN do not result
in an alarm indication signal (AIS) defect. As a result, the CT1/CE1 interfaces
remain up.

Configuring CESoPSN Encapsulation on DS Interfaces on CT1 Channels

This topic includes the following tasks:
1. Configuring COC3 Ports Down to CT1 Channels on page 208

2. Configuring CT1 Channels Down to DS Interfaces on page 209
3. Configuring CESoPSN on DS Interfaces on page 210
Configuring COC3 Ports Down to CT1 Channels
When configuring COC3 ports down to CT1 channels, on any MIC configured for SONET
framing (numbered 0 through 3), you can configure three COC1 channels (numbered 1
through 3). On each COC1 channel, you can configure a maximum of 28 CT1 channels
and a minimum of 1 CT1 channel based on the time slots.
When configuring COC12 ports down to CT1 channels on a MIC configured for SONET
framing, you can configure 12 COC1 channels (numbered 1 through 12). On each COC1
channel, you can configure 24 CT1 channels (numbered 1 through 28).
To configure COC3 channelization down to COC1 and then down to CT1 channels, include
the partition statement at the [edit interfaces (coc1 | coc3)-mpc-slot/mic-slot/port-number]
hierarchy level:
NOTE: To configure COC12 ports down to CT1 channels, replace coc3 with
coc12 in the following procedure.
1. In configuration mode, go to the [edit interfaces coc3-mpc-slot/mic-slot/port-number]

hierarchy level.
[edit]
user@host# edit interfaces coc3-mpc-slot/mic-slot/port-number
For example:
[edit]
user@host# edit interfaces coc3-1/0/0
2. Configure the sublevel interface partition index and the range of SONET/SDH slices,
and set the sublevel interface type as coc1.
[edit interfaces coc3-mpc-slot/mic-slot/port-number]

user@host# set partition partition-number oc-slice oc-slice interface-type coc1
For example:
[edit interfaces coc3-1/0/0]

user@host# set partition 1 oc-slice 1 interface-type coc1
3. Enter the up command to go to the [edit interfaces] hierarchy level.
[edit interfaces coc3-mpc-slot/mic-slot/port-number]

user@host# up

For example:
[edit interfaces coc3-1/0/0]

user@host# up
4. Configure the channelized OC1 interface and the sublevel interface partition index,
and set the interface type as ct1.
[edit interfaces]
user@host# set coc1-1/0/0:1 partition partition-number interface-type ct1
For example:
[edit interfaces]
user@host# set coc1-1/0/0:1 partition 1 interface-type ct1
To verify the configuration, use the show command at the [edit interfaces] hierarchy
level.
[edit interfaces]
user@host# show
coc3-1/0/0 {
partition 1 oc-slice 1 interface-type coc1;
}
coc1-1/0/0:1 {
partition 1 interface-type ct1;
}
Configuring CT1 Channels Down to DS Interfaces
To configure CT1 channels down to a DS interface, include the partition statement at the
[edit interfaces ct1-mpc-slot/mic-slot/port-number:channel:channel] hierarchy level:
1. In configuration mode, go to the [edit interfaces

ct1-mpc-slot/mic-slot/port-number:channel:channel] hierarchy level.
[edit]
user@host# edit interfaces ct1-mpc-slot/mic-slot/port-number:channel:channel
For example:
[edit]
user@host# edit interfaces ct1-1/0/0:1:1
2. Configure the partition, the time slots, and the interface type.
[edit interfaces ct1-mpc-slot/mic-slot/port-number:channel:channel]

For example:
[edit interfaces ct1-1/0/0:1:1]

user@host# set partition 1 timeslots 1-4 interface-type ds

NOTE: You can assign multiple time slots on a CT1 interface. In the set
command, separate the time slots by commas and do not include spaces
between them. For example:

To verify this configuration, use the show command at the [edit interfaces ct1-1/0/0:1:1]
hierarchy level.

user@host# show
partition 1 timeslots 1-4 interface-type ds;
An NxDS0 interface can be configured from channelized T1 interface (ct1). Here N

represents the time slots on the CT1 interface.
The value of N is 1 through 24 when a DS0 interface is configured from a CT1 interface.
After you partition the DS interface, configure the CESoPSN options on it. See “Setting
the CESoPSN Options” on page 216.
Configuring CESoPSN on DS Interfaces
To configure CESoPSN encapsulation on a DS interface, include the encapsulation

statement at the [edit interfaces
ds-mpc-slot/mic-slot/port-number:channel:channel:channel] hierarchy level.

[edit]
user@host# edit interfaces ds-mpc-slot/mic-slot/ port-number:channel:channel:channel
For example:
[edit]
user@host# edit interfaces ds-1/0/0:1:1:1
2. Configure CESoPSN as the encapsulation type and the logical interface for the DS
interface.
[edit interfaces ds-mpc-slot/mic-slot/port-number:channel:channel:channel]

user@host# set encapsulation cesopsn unit interface-unit-number
For example:
[edit interfaces ds-1/0/0:1:1:1 ]

user@host# set encapsulation cesopsn unit 0
To verify this configuration, use the show command at the [edit interfaces ds-1/0/0:1:1:1]
hierarchy level.
[edit interfaces ds-1/0/0:1:1:1]

user@host# show
unit 0;
Configuring CESoPSN Encapsulation on DS Interfaces on CE1 Channels

• Configuring CSTM1 Ports Down to CE1 Channels on page 211

• Configuring CSTM4 Ports Down to CE1 Channels on page 212
• Configuring CESoPSN on DS Interfaces on page 214
Configuring CSTM1 Ports Down to CE1 Channels
On any port configured for SDH framing (numbered 0 through 3), you can configure one
CAU4 channel. On each CAU4 channel, you can configure 31 CE1 channels (numbered 1
through 31).
To configure CSTM1 channelization down to CAU4 and then down to CE1 channels,
include the partition statement at the [edit interfaces (cau4 |
cstm1)-mpc-slot/mic-slot/port-number] hierarchy level, as shown in the following example:
1. In configuration mode, go to the [edit interfaces cstm1-mpc-slot/mic-slot/port-number]

hierarchy level.
[edit]
user@host# edit interfaces cstm1-mpc-slot/mic-slot/port-number
For example:
[edit]
user@host# edit interfaces cstm1-1/0/1
2. On the CSTM1 interface, set the no-partition option, and then set the interface type
as cau4.
[edit interfaces cstm1-mpc-slot/mic-slot/port-number]

user@host# set no-partition interface-type cau4
For example:
[edit interfaces cstm1-1/0/1]

user@host# set no-partition interface-type cau4

user@host# up
For example:

user@host# up

4. Configure the MPC slot, the MIC slot, and the port for the CAU4 interface. Set the
sublevel interface partition index and set the interface type as ce1.
[edit interfaces]
user@host# set cau4-mpc-slot/mic-slot/port-number partition partition-number
interface-type ce1
For example:
[edit interfaces]
user@host# set cau4-1/0/1 partition 1 interface-type ce1
To verify this configuration, use the show command at the [edit interfaces] hierarchy
level.
[edit interfaces]
user@host# show
cstm1-1/0/1 {
no-partition interface-type cau4;
}
cau4-1/0/1 {
partition 1 interface-type ce1;
}
Configuring CSTM4 Ports Down to CE1 Channels
NOTE: When the port speed is configured as coc12-cstm4 at the [edit chassis
fpc slot pic slot port slot] hierarchy level, you must configure CSTM4 ports
down to CE1 channels.
On a port configured for SDH framing, you can configure one CAU4 channel. On the CAU4
channel, you can configure 31 CE1 channels (numbered 1 through 31).
To configure CSTM4 channelization down to CAU4 and then down to CE1 channels,
include the partition statement at the [edit interfaces
(cau4|cstm4)-mpc-slot/mic-slot/port-number] hierarchy level.
1. In configuration mode, go to the [edit interfaces cstm4-mpc-slot/mic-slot/port-number]

hierarchy level.
[edit]
user@host# edit interfaces cstm4-mpc-slot/mic-slot/port-number
For example:
[edit]
user@host# edit interfaces cstm4-1/0/0
2. Configure the sublevel interface partition index and the range of SONET/SDH slices,
and set the sublevel interface type as cau4.

user@host# set partition partition-number oc-slice oc-slice interface-type cau4

For oc-slice, select from the following ranges: 1–3, 4–6, 7–9, and 10–12.
For partition, select a value from 1 through 4.
For example:

user@host# set partition 1 oc-slice 1-3 interface-type cau4

user@host# up
For example:

user@host# up
4. Configure the MPC slot, the MIC slot, and the port for the CAU4 interface. Set the
sublevel interface partition index and set the interface type as ce1.
[edit interfaces]
user@host# set cau4-mpc-slot/mic-slot/port-number:channel partition
partition-number interface-type ce1
For example:
[edit interfaces]
user@host# set cau4-1/0/0:1 partition 1 interface-type ce1
To verify this configuration, use the show command at the [edit interfaces] hierarchy
level.
[edit interfaces]
user@host# show
cstm4-1/0/0 {
partition 1 oc-slice 1-3 interface-type cau4;
}
cau4-1/0/0:1 {
partition 1 interface-type ce1;
}
Configuring CE1 Channels Down to DS Interfaces
To configure CE1 channels down to a DS interface, include the partition statement at the
[edit interfaces ce1-mpc-slot/mic-slot/port:channel] hierarchy level.
1. In configuration mode, go to the [edit interfaces ce1-mpc-slot/mic-slot/port:channel]

hierarchy level.
[edit]
user@host# edit interfaces ce1-mpc-slot/mic-slot/port:channel
[edit]
user@host# edit interfaces ce1-1/0/0:1:1

2. Configure the partition and the time slots, and set the interface type as ds.
[edit interfaces ce1-1/0/0:1:1]

For example:

NOTE: You can assign multiple time slots on a CE1 interface. In the set

To verify this configuration, use the show command at the [edit interfaces ce1-1/0/0:1:1
hierarchy level.
[edit interfaces ce1-1/0/0:1:1 ]

user@host# show
An NxDS0 interface can be configured from a channelized E1 interface (CE1). Here N

represents the number of time slots on the CE1 interface.
The value of N is 1 through 31 when a DS0 interface is configured from a CE1 interface.
After you partition the DS interface, configure the CESoPSN options.

statement at the [edit interfaces

[edit]
user@host# edit interfaces ds-mpc-slot/mic-slot/port-number:channel:channel:channel
For example:
[edit]
2. Configure CESoPSN as the encapsulation type and then set the logical interface for
the ds interface.

user@host# set encapsulation cesopsn unit interface-unit-number

For example:

hierarchy level.

user@host# show
unit 0;

Documentation
Configuring CESoPSN Encapsulation on DS Interfaces
This configuration applies to the mobile backhaul application shown in Mobile Backhaul
Application.
1. Setting the Encapsulation Mode on page 215

2. Setting the CESoPSN Options on page 216
3. Configuring the Pseudowire Interface on page 217
Setting the Encapsulation Mode

To configure a DS interface on Circuit Emulation MICs with CESoPSN encapsulation at
the provider edge (PE) router:
1. In configuration mode, go to the [edit interfaces ds-mpc-slot/mic-slot/port<:channel>]

hierarchy level.
[edit]
user@host# edit interfaces ds-mpc-slot/mic-slot/port<:channel>
For example:
[edit]
2. Configure CESoPSN as the encapsulation type and set the logical interface for the
DS interface.
[edit interfaces ds-mpc-slot/mic-slot/port<:channel>]

user@host# set encapsulation cesopsn unit logical-unit-number
For example:


hierarchy level:

user@host# show
unit 0;
You do not need to configure any circuit cross-connect family because it is automatically
created for the CESoPSN encapsulation.
Setting the CESoPSN Options

To configure CESoPSN options:
1. In configuration mode, go to the [edit interfaces ds-fpc-slot/pic-slot/port:channel]

hierarchy level.
[edit]
user@host# edit interfaces ds-fpc-slot/pic-slot/port:channel
For example:
[edit]
2. Use the edit command to go to the [edit cesopsn-options] hierarchy level.
[edit]
user@host# edit cesopsn-options
3. At this hierarchy level, using the set command you can configure the following
CESoPSN options:
NOTE: When you stitch pseudowires by using interworking (iw) interfaces,

the device stitching the pseudowire cannot interpret the characteristics
of the circuit because the circuits originate and terminate in other nodes.
To negotiate between the stitching point and circuit endpoints, you need
to configure the following options.
• excessive-packet-loss-rate—Set packet loss options. The options are sample-period

and threshold.
• sample-period—Time required to calculate excessive packet loss rate (from 1000

through 65,535 milliseconds).
• threshold—Percentile designating the threshold of excessive packet loss rate

(1–100 percent).
• idle-pattern—An 8-bit hexadecimal pattern to replace TDM data in a lost packet

(from 0 through 255).
• jitter-buffer-latency—Time delay in the jitter buffer (from 1 through 1000

milliseconds).

• jitter-buffer-packets—Number of packets in the jitter buffer (from 1 through 64

packets).
• packetization-latency—Time required to create packets (from 1000 through 8000

microseconds).
• payload-size—Payload size for virtual circuits that terminate on Layer 2 interworking

(iw) logical interfaces (from 32 through 1024 bytes).
NOTE: This topic shows the configuration of only one CESoPSN option.
You can follow the same method to configure all the other CESoPSN
options.
[edit interfaces ds-fpc-slot/pic-slot/port:channel cesopsn-options]

user@host# set excessive-packet-loss-rate sample-period sample-period
For example:
[edit interfaces ds-1/0/0:1:1:1 cesopsn-options]

user@host# set excessive-packet-loss-rate sample-period 4000
To verify the configuration using the values shown in the examples, use the show
command at the [edit interfaces ds-1/0/0:1:1:1] hierarchy level:

user@host# show
cesopsn-options {
sample-period 4000;
}
}
Configuring the Pseudowire Interface

To configure the TDM pseudowire at the provider edge (PE) router, use the existing
Layer 2 circuit infrastructure, as shown in the following procedure:
1. In configuration mode, go to the [edit protocols l2circuit] hierarchy level.
[edit]
user@host# edit protocol l2circuit
2. Configure the IP address of the neighboring router or switch, the interface forming the
Layer 2 circuit, and the identifier for the Layer 2 circuit.

user@host# set neighbor ip-address interface
interface-name-fpc-slot/pic-slot/port.interface-unit-number virtual-circuit-id
virtual-circuit-id
For example:

user@host# set neighbor 10.255.0.6 interface ds-1/0/0:1:1:1 virtual-circuit-id 1

To verify this configuration, use the show command at the [edit protocols l2circuit]
hierarchy level.

user@host# show
neighbor 10.255.0.6 {
interface ds-1/0/0:1:1:1 {
}
}
After the customer edge (CE)-bound interfaces (for both PE routers) are configured with
proper encapsulation, packetization latency, and other parameters, the two PE routers
try to establish a pseudowire with Pseudowire Emulation Edge-to-Edge (PWE3) signaling
extensions. The following pseudowire interface configurations are disabled or ignored
for TDM pseudowires:
• ignore-encapsulation
• mtu
The supported pseudowire type is 0x0015 CESoPSN basic mode.
When the local interface parameters match the received parameters, and the pseudowire
type and control word bit are equal, the pseudowire is established.
For detailed information about configuring TDM pseudowire, see the Junos OS VPNs
For detailed information about PICs, see the PIC Guide for your router.
Related • Configuring CESoPSN on Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC

Documentation with SFP on page 206
• Understanding Mobile Backhaul
Configuring CE1 Channels Down to DS Interfaces
You can configure a DS interface on a channelized E1 interface (CE1) and then apply
CESoPSN encapsulation for the pseudowire to function. An NxDS0 interface can be
configured from a channelized CE1 interface, where N represents the time slots on the
CE1 interface. The value of N is 1 through 31 when a DS0 interface is configured from a
CE1 interface.
To configure CE1 channels down to a DS interface, include the partition statement at the
[edit interfaces ce1-fpc/pic/port] hierarchy level, as shown in the following example:
[edit interfaces]
user@host# show
ce1-0/0/1 {
}

After you partition the DS interface, configure the CESoPSN options on it. See “Setting
the CESoPSN Options” on page 216.
To configure CE1 channels down to a DS interface:
1. Create the CE1 interface.
[edit interfaces]
user@host# edit interfaces ce1-fpc/pic/port
For example:
[edit interfaces]
user@host# edit interface ce1-0/0/1
2. Configure the partition, the time slot, and the interface type.
[edit interfaces ce1-fpc/pic/port]

user@host# set partition partition-number timeslots timeslots interface-type ds;
For example:
[edit interfaces ce1-0/0/1]

user@host# set partition 1 timeslots 1-4 interface-type ds;
NOTE: You can assign multiple time slots on a CE1 interface; in the
configuration, separate the time slots by comma without spaces. For
example:
[edit interfaces ce1-0/0/1]

user@host# set partition 1 timeslots 1-4,9,22–31 interface-type ds;
3. Configure the CESoPSN encapsulation for the DS interface.

user@host# set encapsulation encapsulation-type
For example:

4. Configure the logical interface for the DS interface.

user@host# set unit logical-unit-number;
For example:

When you are finished configuring CE1 channels down to a DS interface, enter the commit
command from configuration mode.

From configuration mode, confirm your configuration by entering the show command.
For example:
[edit interfaces]
user@host# show
ce1-0/0/1 {
}
ds-0/0/1:1 {
unit 0;
}

Documentation
Configuring CESoPSN on Channelized E1/T1 Circuit Emulation MIC
This configuration applies to the mobile backhaul application shown in Mobile Backhaul
Application.
• Configuring T1/E1 Framing Mode at the MIC Level on page 220

• Configuring CT1 Interface Down to DS channels on page 221
• Configuring CESoPSN on DS Interfaces on page 222
Configuring T1/E1 Framing Mode at the MIC Level

To set the framing mode at the MIC (ACX-MIC-16CHE1-T1-CE) level, for all four ports on
the MIC, include the framing statement at the [edit chassis fpc slot pic slot] hierarchy
level.
[edit chassis fpc slot pic slot]

basis of the MIC type and the framing option used.
• If you include the framing t1 statement, 16 CT1 interfaces are created.
• If you include the framing e1 statement, 16 CE1 interfaces are created.
operation fails.
Bit error rate test (BERT) patterns with all binary 1s (ones) received by CT1/CE1
interfaces on Circuit Emulation MICs configured for CESoPSN do not result
in an alarm indication signal (AIS) defect. As a result, the CT1/CE1 interfaces
remain up.

Configuring CT1 Interface Down to DS channels

To configure a channelized T1 (CT1) interface down to DS channels, include the partition
statement at the [edit interfaces ct1-mpc-slot/mic-slot/port-number] hierarchy level:
NOTE: To configure a CE1 interface down to DS channels, replace ct1 with

ce1 in the following procedure.

hierarchy level.
[edit]
For example:
[edit]
2. Configure the sublevel interface partition index and the time slots, and set the interface
type as ds.

For example:

NOTE: You can assign multiple time slots on a CT1 interface. In the set

To verify this configuration, use the show command at the [edit interfaces ct1-1/0/0]
hierarchy level.

user@host# show
An NxDS0 interface can be configured from a CT1 interface. Here N represents the number
of time slots on the CT1 interface. The value of N is:
• 1 through 24 when a DS0 interface is configured from a CT1 interface.
• 1 through 31 when a DS0 interface is configured from a CE1 interface.

After you partition the DS interface, configure CESoPSN options on it. See “Setting the
CESoPSN Options” on page 216.

statement at the [edit interfaces ds-mpc-slot/mic-slot/port-number:channel] hierarchy
level.

ds-mpc-slot/mic-slot/port-number:channel] hierarchy level.
[edit]
user@host# edit interfaces ds-mpc-slot/mic-slot/ port-number:channel
For example:
[edit]
user@host# edit interfaces ds-1/0/0:1
2. Configure CESoPSN as the encapsulation type.
[edit interfaces ds-mpc-slot/mic-slot/port-number:partition ]

For example:
[edit interfaces ds-1/0/0:1 ]

3. Configure the logical interface for the DS interface.
[edit interfaces ds-mpc-slot/mic-slot/port-number:partition ]

uset@host# set unit interface-unit-number
For example:
[edit interfaces ds-1/0/0:1 ]

To verify this configuration, use the show command at the [edit interfaces ds-1/0/0:1]
hierarchy level.

user@host# show
unit 0;
Related • 16-Port Channelized E1/T1 Circuit Emulation MIC Overview on page 106
Documentation

CHAPTER 9
Configuring Timing and Synchronization
• Automatic Clock Selection Overview on page 224

• Clock Sources on page 225
• External Clock Synchronization Overview for ACX Series Routers on page 226
• Configuring External Clock Synchronization for ACX Series Routers on page 228
• IEEE 1588v2 PTP Boundary Clock Overview on page 234
• IEEE 1588v2 Precision Timing Protocol (PTP) on page 237
• PTP over Ethernet on ACX Series Routers Overview on page 238
• Guidelines for Configuring PTP over Ethernet on page 240
• Configuring Precision Time Protocol Clocking on page 243
• Configuring a PTP Master Boundary Clock on page 244
• Example: Configuring a PTP Boundary Clock on page 248
• Example: Configuring a PTP Boundary Clock With Unicast Negotiation on page 250
• Configuring a PTP Slave Clock on page 254
• Example: Configuring an Ordinary Slave Clock With Unicast-Negotiation on page 257
• Example: Configuring an Ordinary Slave Clock Without Unicast-Negotiation on page 261
• Configuring Precision Time Protocol Over Integrated Routing and Bridging on page 264
• Understanding Transparent Clocks in Precision Time Protocol on page 267
• Configuring Transparent Clock Mode for Precision Time Protocol on page 269
• Configuring a PTP Transparent Clock on page 270
• Configuring PHY Timestamping on page 270
• Configuring PHY Timestamping on ACX2200 Routers on page 273
• G.703 2.048MHz Signal Type for BITS Interfaces Overview on page 274
• Configuring PTP Multicast Master and Slave Ports for Ethernet Encapsulation on page 274
• Configuring PTP Dynamic Ports for Ethernet Encapsulation on page 280
• Example: Configuring PTP over Ethernet for Multicast Master, Slave, and Dynamic
Ports on page 281
• Hybrid Mode on ACX Series Routers Overview on page 288
• Guidelines for Configuring Hybrid Mode on ACX Series Routers on page 290

• Configuring Hybrid Mode and ESMC Quality Level Mapping on ACX Series
Routers on page 292
• Example: Configuring Hybrid Mode and ESMC Quality Level Mapping on page 295
• Understanding Timing Defects and Event Management on ACX Series on page 301
• Understanding SNMP MIB for Timing on ACX Series on page 303
• Global Positioning System (GPS) and the ACX Series Routers on page 306
• Integrated Global Navigation Satellite System (GNSS) on ACX500 Series
Routers on page 307
• Assisted Partial Timing Support on ACX500 Routers Overview on page 308
Automatic Clock Selection Overview
Automatic clock selection is the selection of the best quality clock source by the clock
source selection algorithm based on the Ethernet Synchronization Message Channel
(ESMC) Synchronization Status Message (SSM) quality level, the configured quality
level, and the priority.
• Clock Source Selection Algorithm on page 224

• Clock Selection and Quality Level on page 224
• Selection Mode for the Incoming ESMC Quality on page 225
Clock Source Selection Algorithm

The clock source selection algorithm is triggered by the following events:
• Changes in the received ESMC SSM quality level (QL)
• Configuration changes. For example, the addition or deletion of a clock source, a change
to the QL mode, and so on.
• Signal failure detected on the currently selected source.
When the router is configured with automatic clock selection, the system chooses up to
two best upstream clock sources. The system then uses the clock recovered from one
of the sources to lock the chassis clock. If an upstream clock with acceptable good quality
is not available or if the system is configured in free-run mode, the system uses the internal
oscillator.
Clock Selection and Quality Level

Automatic clock selection supports two modes: QL enabled and QL disabled.
• QL disabled— In this mode, the best clock is selected based on the configured ESMC
SSM QL. If the QL of the configured clocks are equal, the clock selection is based on
the configured priority. If both the configured QL and priority are equal, one of the
sources is randomly selected. Absence of the quality-mode-enable statement at the
[edit chassis synchronization] hierarchy level means that QL is disabled.

Chapter 9: Configuring Timing and Synchronization
NOTE: The default setting is QL disable.
• QL enabled—In this mode, the best clock is selected based on the incoming ESMC
SSM QL as long as the incoming QL is at least as good as the source’s configured QL.
If the QLs are equal, the clock selection is based on the configured priority. If both the
received QL and the priority are equal, one of the sources is selected randomly.
Selection Mode for the Incoming ESMC Quality

Depending on the configuration, the clock source selection algorithm uses the configured
or received ESMC SSM quality level for clock selection. In both configured and received
selection modes, the interface qualifies for clock source selection only when the received
ESMC SSM quality level on the interface is equal to or greater than the configured ESMC
SSM quality level for the interface.
Related • External Clock Synchronization Overview for ACX Series Routers on page 226
Documentation
• synchronization on page 1739
Clock Sources
Clocking is an important feature on the ACX Series routers. The ACX Series routers can
be directly connected to different types of base stations (for example, base transceiver
station (BTS) in 2G, NodeB in 3G, and eNodeB in 4G networks) and different types of
routers that hand off time-division multiplexing (TDM, ATM, and Ethernet traffic to the
base station controller. ACX Series routers must extract the network clock from these
sources and pass on synchronization information to the base stations to help the routers
synchronize with the base station controller.
The ACX Series router timing hardware includes two external clock inputs (BITS and
GPS), T1 and E1 ports (FPC 0, PIC 0), Gigabit Ethernet ports (RJ45), Gigabit Ethernet
ports (SFP), and 10-Gigabit Ethernet ports.
NOTE: ACX500 routers do not support TDM, BITS, ATM, T1 or E1, SONET,
and 10-Gigabit Ethernet interfaces.
ACX Series router hardware and software support various clocking options:
• The ACX series has an OCXO (Stratum 3E) type of oscillator.
• External clocking includes PPS, a choice of GPS-based clock recovery (10 MHz), or
BITS-T1 or E1 line synchronization (1.544 MHz and 2.048 MHz).

NOTE: ACX500 routers do not support 10 MHz in and out. ACX500 routers
supports GPS input through SubMiniature version A (SMA) connector.
• ACX500 routers contain integrated GPS receiver, pulse-per-second (PPS) in and out,
and Gigabit Ethernet ports (RJ45 and SFP).
• Synchronous Ethernet (SyncE) is supported based on the ITU G.8261, G.8262, and
G.8264 specifications with line timing for ge and xe ports.
Synchronous Ethernet is a key requirement for circuit (emulation) services and mobile
radio access technologies. Synchronous Ethernet supports sourcing and transfer of
frequency for synchronization purposes for both wireless and wireline services and is
primarily used for mobile backhaul and converged transport.
• The Precision Time Protocol (PTP) 1588v2—compliant ordinary slave clock estimates
the time offset from the PTP master clock and tries to align its own time and frequency
with that of the master. PTP supports sourcing, transfer of frequency, and phase
synchronization. Also, PTP can be used for mobile backhaul when phase synchronization
is required, such as in Long Term Evolution-Time Division Duplex (LTE-TDD)
infrastructures.
Related • Global Positioning System (GPS) and the ACX Series Routers on page 306
Documentation
• Synchronous Ethernet Overview on the ACX Series Universal Access Routers on page 107
• IEEE 1588v2 Precision Timing Protocol (PTP) on ACX Series Universal Access Routers
on page 237
External Clock Synchronization Overview for ACX Series Routers
The ACX Series Universal Access routers support external clock synchronization and
automatic clock selection for Synchronous Ethernet, T1 or E1 line timing sources, and
external inputs. Configuring external clock synchronization and automatic clock selection
requires making clock selection, quality level (QL), and priority considerations. The clock
source selection algorithm is used to pick the two best upstream clock sources from
among all the various sources, based on system configuration and execution criteria such
as QL, priority, and hardware restrictions.
Automatic Clock Selection

With automatic clock selection, the system chooses up to two best upstream clock
sources. The system then uses the clock recovered from one of the sources to lock the
chassis clock. If an upstream clock with acceptable good quality is not available or if the
system is configured in free-run mode, the system uses the internal oscillator. The
following automatic clock selection features are supported for Synchronous Ethernet,
T1 or E1 line timing sources, and external inputs:

NOTE: Automatic clock selection does not apply to the IEEE 1588v2 recovered
clock.
Automatic clock selection is supported on the ACX Series routers. Automatic clock
selection of the best quality clock source is based on the Ethernet Synchronization
Message Channel (ESMC) Synchronization Status Message (SSM) quality level, the
configured quality level, and the priority. To configure automatic clock selection, include
the auto-select option at the [edit chassis synchronization] hierarchy level. You can also
configure the chassis to lock to the free-running local oscillator, which is the Stratum 3E
oscillator, by including the free-run option at the [edit chassis synchronization] hierarchy
level. The auto-select option enables the clock source selection algorithm to run. The
clock source selection algorithm is triggered by the following events:
• Signal failure detected on the currently selected source
• Changes in the received Ethernet Synchronization Message Channel (ESMC)

Synchronization Status Message (SSM) quality level (QL)
• Configuration changes. For example, the addition or deletion of a clock source, a change
to the QL mode, and so on.
Automatic clock selection supports two modes on the ACX Series router: QL enabled
and QL disabled. To configure QL mode, include the quality-mode-enable statement at
the [edit chassis synchronization] hierarchy level.
• QL disabled—The default setting is disable, which means that when the

quality-mode-enable statement is not configured, QL is disabled. In this mode, the best
clock is selected based on the configured ESMC SSM QL. If the QL of the best clocks
are equal, the clock selection is based on the configured priority. If both the configured
QL and priority are equal, one of the sources is randomly selected.
• QL enabled—In this mode, the best clock is selected based on the incoming ESMC
SSM QL as long as the incoming QL is at least as good as the source’s configured QL.
If the QLs are equal, the clock selection is based on the configured priority. If both the
received QL and the priority are equal, one of the sources is selected randomly.
Clock Source Selection Algorithm
The clock source selection algorithm uses the following logic and restrictions:
• QL must be configured for non-external clocks, whether or not QL is enabled.
• For network-option option-1, QL must be configured for external clocks (gps or bits)
whether or not QL is enabled.
• In the case of network-option option-2, the default QL for the external clocks is QL_STU,
whether or not QL is enabled.

• Configuring priority is optional. When not specified, gps has a higher default priority
than bits, and bits has a higher default priority than Gigabit Ethernet, 10-Gigabit Ethernet,
and T1 or E1 clock, which have the lowest default priority.
• When QL is enabled, the received QL must be equal to or better than the configured
QL for that particular source or else that source will not be considered for clock
selection. This is so that a downstream client is guaranteed clock quality of a certain
level (that “certain level” being the configured QL).
During clock selection:
• The active source with the highest QL is selected.
• If QL is the same for two or more sources, then the source with the highest priority is
selected.
• If two or more sources have the same QL and priority, then the currently active source,
if any, among these sources is selected.
• If two or more sources have the same QL and priority, and none of these is currently
active, then any one of these may be selected.
• If selection-mode is configured quality, then the configured (or default) QL of the

selected clock source is used for transmitting ESMC. If selection-mode is received
quality, then the received QL of the selected clock source is used for ESMC transmit.
• In order to receive or transmit ESMC messages out of an interface, at least one logical
interface should be configured on that interface. If the interface is currently not
configured with a logical interface, you may do so using the set interfaces interface-name
unit 0 statement at the edit hierarchy level.
Related • Configuring External Clock Synchronization for ACX Series Routers on page 228
Documentation
Configuring External Clock Synchronization for ACX Series Routers
The ACX Series Universal Access Routers support external clock synchronization for
Synchronous Ethernet, T1 or E1 line timing sources, and external inputs. Configuring
external clock synchronization requires making clock selection, quality level (QL), and
priority considerations. The clock source selection algorithm is used to pick the two best
upstream clock sources from among all the various sources, based on system
configuration and execution criteria such as QL, priority, and hardware restrictions.
To configure external synchronization on the router, include the synchronization statement

at the [edit chassis] hierarchy level.
Setting the Ethernet equipment clock (EEC) network type
The network type options set the frequency of the configured clock. When bits is
configured with option-1 on the ACX router, the Synchronous Ethernet equipment is
optimized for 2048 Kbps, the speed of an E1 interface. When bits is configured with

option-2 on the ACX router, the Synchronous Ethernet equipment is optimized for 1544
Kbps, the speed of a T1 interface. To set the clock type, use the following command:
set chassis synchronization network-option (option-1 | option-2)

For option-1, QL must be configured for external clocks (gps or bits) whether or not QL
is enabled. For option-2, the default QL for external clocks is QL_STU whether or not QL
is enabled.
The following output shows an example of the configuration of the network type with
option-1:
[edit]
synchronization {
network-option option-1;
}
Setting the clock mode
Clock mode sets the selection of the clock source from a free-running local oscillator or
from an external qualified clock. The default clock mode is auto-select, which uses the
best clock source. To set the clock mode, use the following command:
set chassis synchronization clock-mode (free-run | auto-select)

The following output shows an example of the configuration of the free-run option:
[edit]
synchronization {
clock-mode free-run;
}
NOTE: Automatic clock selection does not apply to the IEEE 1588v2 recovered
clock.
Setting the quality mode
Specify the expected quality of the incoming clock on this source. The default is disable.
To set the synchronization quality mode, use the following command:
set chassis synchronization quality-mode-enable

The following output shows the configuration of the quality-mode-enable statement:
[edit]
synchronization {
quality-mode-enable;
}
Setting the selection mode
The selection mode specifies whether the clock source selection algorithm should use
the configured or received ESMC SSM quality level for clock selection. In both selection

modes (configured-quality and received-quality), the interface qualifies for clock source
selection only when the received ESMC SSM quality level on the interface is equal to or
greater than the configured ESMC SSM quality level for the interface. To configure the
ESMC SSM quality-based clock source selection mode, use the following command:
set chassis synchronization selection-mode (configured-quality | received-quality)

The following output shows the configuration of the selection-mode statement with the
configured-quality option and the mandatory quality-mode-enable statement:
[edit]
synchronization {
selection-mode configured-quality;
quality-mode-enable;
}
NOTE: For the selection-mode statement configuration to take effect, you

must set the quality-mode-enable statement at the [edit chassis
synchronization] hierarchy level.
Setting the time interval before a new clock source is selected
For routers operating with Synchronous Ethernet , set the time interval to wait before the
router selects a new clock source. After a change in the configuration, the time to wait
is between 15 and 60 seconds. After a reboot (restart), the time to wait is from 60 to 180
seconds. After clock recovery (switchover), the time to wait is from 30 to 60 seconds.
The default switchover time is 30 seconds and cold boot time is 120 seconds. To set the
time interval before a new clock source is selected, use the following command:
set chassis synchronization hold-interval (configuration-change | restart |

switchover) seconds
The following output shows the configuration of the hold-interval statement with the
configuration-change option:
[edit]
synchronization {
hold-interval {
configuration-change 20;
}
}
Setting the synchronization switching mode
The configured switching mode determines the clock source used. In revertive mode, the
system switches from a lower to a higher quality clock source whenever the higher clock
source becomes available. In non-revertive mode, the system continues to use the current
clock source as long as it is valid. The default mode is revertive. To set the synchronization
switchover mode, use the following command:
set chassis synchronization switchover-mode (revertive | non-revertive)

The following output shows the configuration of the switchover-mode statement with
the non-revertive option:
[edit]
synchronization {
switchover-mode non-revertive;
}
Setting the clock source
The configured clock source is the candidate for selection by the clock selection algorithm.
The clock source can be the router’s BITS T1 or E1 interface, GPS, or an interface with an
upstream clock source. To set the clock source, use the following command:
set chassis synchronization source (bits | gps | interfaces interface-name)

The following output shows the configuration of the source statement with the bits option
and the mandatory network-option statement. When bits is configured with option-1 on
the ACX2000 router, the Synchronous Ethernet equipment is optimized for 2048 Kbps,
the speed of an E1 interface.
[edit]
synchronization {
source {
bits;
}
}
NOTE: For the source statement configuration to take effect, you must set
the network-option (option-1 | option-2) statement at the [edit chassis
The bits option is not supported on the ACX1000 router.
Setting ESMC transmit interface
The ESMC transmit interface is the interface on which ESMC transmit messages are
permitted. To enable ESMC packet transmit, use the following command:
set chassis synchronization esmc-transmit interfaces interface-name

The following output shows the configuration of the esmc-transmit statement:
[edit]
synchronization {
esmc-transmit {
interfaces ge-0/1/0;
}
}

You can also enable ESMC on all interfaces with the interfaces all statement at the
preceding hierarchy level.
Setting the synchronization source quality level
Specify the expected quality of the incoming clock on this source. Specific quality-level
options are valid depending on the configured network-option; option-1 or option-2. Both
option-1 and option-2 SSM quality levels are supported. To set the synchronization source
quality level, use the following command:

quality-level (prc | prs |sec | smc | ssu-a | ssu-b | st2 | st3 | st3e | st4 |
stu | tnc)
The following output shows the configuration of the quality-level statement configured
with the prc option:
[edit]
synchronization {
source {
bits {
quality-level prc;
}
}
}
Setting the synchronization source priority
Specify a priority level between 1 and 5. When not specified, gps has a higher priority than
bits,and bits has a higher default priority than other Gigabit Ethernet or 10 Gigabit Ethernet
clock sources, which have the lowest priority. To set the synchronization source priority,
use the following command:

priority number
The following output shows the configuration of the priority statement:
[edit]
synchronization {
source {
bits {
priority 2;
}
}
}
Setting the synchronization source wait to restore time
A wait-to-restore time can be configured for each port. When a port’s signal transitions
out of the signal fail state, it must be fault free for the wait-to-restore time before it is
again considered by the selection process. The range is from 0 through 12 minutes. The
default time is 5 minutes.
To set the synchronization source wait-to-restore time, use the following command:

set chassis synchronization source interfaces interface-name wait-to-restore

minutes
The following output shows the configuration of the wait-to-restore statement:
[edit]
synchronization {
source {
interfaces ge-0/1/0 {
wait-to-restore 2;
}
}
}
Setting the synchronization source lockout
A lockout may be configured for any source. When a lockout is configured for a source,
that source will not be considered by the selection process. To set the synchronization
source lockout, use the following command:

request lockout
The following output shows the configuration of the request lockout statement:
[edit]
synchronization {
source {
bits {
request lockout;
}
}
}
Setting the forced switch
Force a switch to the source provided that the source is enabled and not locked out. Only
one configured source may be force-switched. To set the forced switch, use the following
command:

request force-switch
The following output shows the configuration of the request force-switch statement:
[edit]
synchronization {
source {
bits {
request force-switch;
}
}
}

Documentation
• synchronization on page 1739
• Interface and Router Clock Sources Overview
IEEE 1588v2 PTP Boundary Clock Overview
The IEEE 1588v2 standard defines the Precision Time Protocol (PTP), which is used to
synchronize clocks throughout a network. The standard describes the PTP boundary
clock’s hierarchical master/slave architecture for the distribution of time-of-day.
• IEEE 1588v2 PTP Boundary Clock on page 234

• Clock Clients on page 236
IEEE 1588v2 PTP Boundary Clock

Starting with Junos OS Release 17.3R1, IEEE 1588v2 boundary clock is supported on
QFX10002 switches. An IEEE 1588v2 boundary clock has multiple network connections
and can act as a source (master) and a destination (slave or client) for synchronization
messages. It synchronizes itself to a best master clock through a slave port and supports
synchronization of remote clock clients to it on master ports. Boundary clocks can improve
the accuracy of clock synchronization by reducing the number of 1588v2-unaware hops
between the master and the client. Boundary clocks can also be deployed to deliver
better scale because they reduce the number of sessions and the number of packets per
second on the master.
The boundary clock intercepts and processes all PTP messages and passes all other
traffic. The best master clock algorithm (BMCA) is used by the boundary clock to select
the best configured acceptable master clock that a boundary slave port can see. To
configure a boundary clock, include the boundary statement at the [edit protocols ptp
clock-mode] hierarchy level and at least one master with the master statement and at
least one slave with the slave statement at the [edit protocols ptp] hierarchy level.
Figure 21 on page 235 illustrates two boundary clocks in a network in which the clock flow
is from the upstream node (BC-1) to the downstream node (BC-2).
NOTE: This figure also applies to MX Series routers and QFX Series switches.

Figure 21: Boundary Clocks in a Network

BC-1 BC-2
ACX Series Router Remote M ACX Series Router
OC-5
Grandmaster
P-1 P-2 P-3 P-4 P-1 P-2 P-3

S M M S S M M
Remote M Remote S Remote S Remote S

OC-1 OC-2 OC-3 OC-4
Grandmaster
BC - Boundary Clock M- Master P - Ports on an ACX Series router

OC - Ordinary Clock S - Slave
g017867
The first boundary clock—BC-1—has four ports. Each port is configured as follows:
• BC-1 P-1 and BC-1 P-4 are boundary slave ports connected to two grandmaster
clocks—OC-1 and OC-5. The grandmasters are included as the clock sources in the
slave port configurations. From the packets received on the slave ports, BC-1 selects
the best master, synchronizes its clock, and generates PTP packets, which are sent
over the master ports—BC-1 P-2 and BC-1 P-3—to the downstream clients.
• BC-1 P-2, a master port, is connected to OC-2, an ordinary remote slave. OC-2 is included
as a clock client in BC-1 P-2’s master configuration, and so receives PTP packets from
BC-1 P-2.
• BC-1 P-3, a master port, is connected to BC-2 P-1, a remote boundary slave port. In this
situation, the master port—BC-1 P-3—is included as a clock source in the configuration
of the boundary slave port—BC-2 P-1. In addition, the boundary slave port—BC-2 P-1—is
included as a clock client in the configuration of the master port—BC-1 P-3. With this
configuration, the boundary slave—BC-2 P1—receives PTP packets from BC-1 P3.
The second boundary clock—BC-2—has three ports. Each port is configured as follows:
• BC-2 P-1 is a boundary slave port connected to the upstream master port—BC-1 P3.
As described previously, BC-2 P-1 receives PTP packets from BC-1 P3. The master
ports—BC-2 P-2 and BC-2 P-3—synchronize their time from the packets received from
BC-2 P1.
• BC-2 P-2 and BC-2 P-3, boundary master ports, are connected to ordinary remote
slaves—OC-3 and OC-4. OC-3 and OC-4 are included as clock clients in the
configuration of the master ports—BC-2 P2 and BC-2 P-3. Both slaves receive PTP
packets from the master boundary port to which they are connected.
In this example, the boundary clock synchronizes its clock from the packets received on
its slave ports from the upstream master. The boundary clock then generates PTP packets,
which are sent over the master port to downstream clients. These packets are
timestamped by the boundary clock by using its own time, which is synchronized to the
selected upstream master.

Clock Clients
A clock client is the remote PTP host, which receives time from the PTP master and is in
a slave relationship to the master.
NOTE: The term slave is sometimes used to refer to the clock client.
An device acting as a master boundary clock supports the following types of downstream
clients:
• Automatic client—An automatic client is configured with an IP address, which includes

the subnet mask, indicating that any remote PTP host belonging to that subnet can
join the master clock through a unicast negotiation. To configure an automatic client,
include the subnet mask in the clock-client ip-address statement at the [edit protocols
ptp master interface interface-name unicast-mode] hierarchy level.
• Manual client—A manual client is configured with the manual statement at the [edit
protocols ptp master interface interface-name unicast-mode clock-client ip-address
local-ip-address local-ip-address] hierarchy level. A manual client does not use unicast
negotiation to join the master clock. The manual statement overrides the unicast
negotiation statement configured at the [edit protocols ptp] hierarchy level. As soon
as you configure a manual client, it starts receiving announce and synchronization
packets.
• Secure client—A secure client is configured with an exact IP address of the remote PTP
host, after which it joins a master clock through unicast negotiation. To configure a
secure client, include the exact IP address in the clock-client ip-address statement at
the [edit protocols ptp master interface interface-name unicast-mode] hierarchy level.
NOTE: You can configure the maximum number of clients (512 ) in the
following combination:
• Automatic clients 256.
• Manual and secure clients 256—Any combination of manual and secure

clients is allowed as long as the combined total amounts to 256.
17.3R1 Starting with Junos OS Release 17.3R1, IEEE 1588v2 boundary clock is
supported on QFX10002 switches.
Related • IEEE 1588v2 Precision Timing Protocol (PTP) on ACX Series Universal Access Routers
Documentation on page 237
• Precision Time Protocol Overview

• Supported IPv4, TCP, and UDP Standards
IEEE 1588v2 Precision Timing Protocol (PTP)
The IEEE 1588v2 standard defines the Precision Time Protocol (PTP), which is used to
synchronize clocks throughout a packet-switched network. This synchronization is
achieved through packets that are transmitted and received in a session between a
master clock and a slave clock or remote clock client. The clocks used for the distribution
of accurate time are in an hierarchical master/slave architecture, which includes boundary
clocks, ordinary clocks, and grandmaster clocks. A boundary clock is both a clock source
and a clock client. An ordinary clock is either a clock source or a clock client. However, a
grandmaster clock is always a clock source. An ordinary clock on a device is always a
clock client. In addition, User UDP over IPv4 and unicast mode are used to transport PTP
messages.
NOTE: In ACX Series routers, the grandmaster functionality is supported only

on ACX500 router.
The following key PTP features are supported:
• Boundary clock—A boundary clock has multiple network connections and can act as
a source (master) and a destination (slave or clock client) for synchronization messages.
It synchronizes itself to a best master clock through a slave port and supports
synchronization of clients to it on master ports. Boundary clocks can improve the
accuracy of clock synchronization by reducing the number of 1588v2-unaware hops
between the master and the client. Boundary clocks can also be deployed to deliver
better scale because they reduce the number of sessions and the number of packets
per second on the master.
• Ordinary clock—The PTP ordinary clock has a single network connection and can act
as a source (master) or destination (slave or clock client) for synchronization messages.
On devices, the ordinary clock is a slave, which receives synchronization reference
messages from a master, either a grandmaster or a master boundary clock. You cannot
configure an ordinary master on a device. However, a boundary clock can provide time
to the ordinary slave.
• PTP grandmaster clock—The PTP grandmaster clock communicates time information

to destination or slave ports. The grandmaster clock is an external device to which the
boundary or ordinary clock synchronizes. You cannot configure a grandmaster clock
on a device. However, a boundary clock slave or an ordinary clock slave can receive
time from a grandmaster clock.
• Clock source—A clock source is the PTP master clock to which the slave synchronizes.
The clock source is included in the configuration of the slave clock.

NOTE: The term master is sometimes used to refer to the clock source.
• Clock client—A clock client is the remote PTP host, which receives time from the PTP
master. The clock client is included in the configuration of the master clock.
NOTE: The term slave is sometimes used to refer to the clock client.
• PTP over UDP over IPv4—The IEEE1588v2 standard specifies different transport
protocols for carrying PTP packets. For example, PTP over Ethernet, PTP over UDP
over IPv4, and PTP over UDP over IPv6. ACX Series routers support PTP over UDP over
IPv4.
• Unicast mode (IPv4 on Gigabit Ethernet interfaces only)—Unicast mode is a user-to-user

protocol used to send a datagram to a single recipient. Unicast mode is used for
transporting PTP messages.
Related • Precision Time Protocol Overview

Documentation
• Supported IPv4, TCP, and UDP Standards
PTP over Ethernet on ACX Series Routers Overview
Precision Time Protocol (PTP) is supported over IEEE 802.3 or Ethernet links on ACX
Series routers. This functionality is supported in compliance with the IEEE 1588-2008
specification. PTP over Ethernet enables effective implementation of packet-based
technology that enables the operator to deliver synchronization services on packet-
based mobile backhaul networks that are configured in Ethernet rings. Deployment of
PTP at every hop in an Ethernet ring by using the Ethernet encapsulation method enables
robust, redundant, and high-performance topologies to be created that enables a highly
precise time and phase synchronization to be obtained.
The ACX Series routers can be directly connected to different types of base stations (for
example, base transceiver station (BTS) in 2G, NodeB in 3G, and eNodeB in 4G networks)
and different types of routers that hand off time- division multiplexing (TDM), ATM, and
Ethernet traffic to the base station controller. ACX Series routers must extract the network
clock from these sources and pass on synchronization information to the base stations
to help the routers synchronize with the base station controller.
Most of the network deployments that use Ethernet contain a minimum of two Ethernet
rings, while some of the network topologies might also contain up to three Ethernet rings.
Consider a scenario in which the first ring contains aggregation routers (MX Series routers)
and the second ring contains access routers (ACX Series routers). In such a network,

about 10 or 12 nodes of MX Series routers and ACX Series routers are present in the
aggregation and access Ethernet rings.
Some of the 4G base stations that are connected to ACX Series routers need to receive
the timing and synchronization information in a packet-based form. Such base station
vendors support only packet interfaces that use Ethernet encapsulation for PTP packets
for time and phase synchronization. Therefore, any node (an ACX Series router) that is
directly connected to a 4G base station must be able to use the Ethernet encapsulation
method for PTP on a master port to support a packet-based timing capability.
PTP over Ethernet encapsulation also facilitates an easier, optimal network deployment
model than PTP over IPv4. Using IPv4, the nodes (master and slave devices) participate
in unicast negotiation in which the slave node is provisioned with the IP address of the
master node and requests unicast messages to be sent to it from the master node. A
master node is the router that functions as the PTP server where the master clock is
located and a slave node is the router that functions as the PTP client where the slave
clock is located. Because PTP over Ethernet uses multicast addresses, the slave node
automatically learns about the master nodes in the network. Also, the slave node is able
to immediately receive the multicast messages from the master node and can begin
sending messages to the master node without the need for any provisioning configuration.
An interface on which the master clock is configured is called a master interface and an
interface on which the slave clock is configured is called a slave interface. A master
interface functions as the master port and a slave interface functions as the slave port.
For PTP over Ethernet, apart from configuring a port or a logical interface to operate as
a master clock or a slave clock, you can also configure a port or a logical interface to
function as both a master clock and a slave clock. This type of port is called a dynamic
port, stateful port, or a bidirectional port. Such a stateful port enables the network to more
efficiently adapt to the introduction and failure of timing sources by forming the shortest
synchronization trees from a particular source. This behavior is implemented as defined
by the best master clock algorithm (BMCA) in the ITU-T G.8265.1 Precision time protocol
telecom profile for frequency synchronization specification.
On both MX Series and ACX Series routers, you can achieve the highest quality
performance if you configure every node in a synchronization chain as a PTP boundary
clock. In Ethernet ring-based topologies, you can configure a port or a logical interface
to function either as a master port or as a slave port to enable redundancy when a node
or link failure occurs. This dynamic port or dual-port functionality is in accordance with
the IEEE 1588-2008 standard and enables the implementation of PTP in data center or
financial applications.
Apart from enabling every node to be available for configuration as a PTP boundary clock,
it is also necessary to enable a logical interface to be configured either as a master port
or a slave port. When you configure a logical interface or even a shared IP address to be
a master port or a slave port, a PTP protocol stack can represent dynamic ports and the
PTP application selects the correct state (master or slave) for any specific port in the
system based on the output of the default PTP BMCA and the states of other ports in
the system.
While an ACX Series router supports the PTP over Ethernet functionality, a Brilliant Grand
Master such as an MX Series router or a TCA Series Timing Client does not support PTP

over Ethernet. In such a scenario, the ACX Series router functions as a boundary clock
with a PTP slave port using IPv4 as the encapsulation mode and master ports using
Ethernet as the encapsulation mode for PTP traffic. For example, consider an ACX Series
router named ACX1 to have two potential slave interfaces, one that is fixed as a slave-only
port using IPv4 on the link toward an MX Series router named MX1, and a dynamic port
that functions as a slave port using PTP over Ethernet on the link toward another ACX
Series router named ACX2. In addition, ACX1 also contains a port that is a master-only
port using PTP over Ethernet and connects to the base station.
Because PTP over Ethernet uses multicast addresses, a slave port can automatically
start receiving the multicast announce messages transmitted by the master ports on a
network and can also start communication with the master node with minimal or no
configuration. Unlike PTP over IPv4 where IP addresses are used to identify the master
and slave ports, with PTP over Ethernet, multicast MAC addresses are used in the
forwarding of PTP traffic. The IEEE 1588 standard defines two types of multicast MAC
addresses 01-80-C2-00-00-0E (link local multicast) and 01-1B-19-00-00-00 (standard
Ethernet multicast) for PTP over Ethernet operations.
Related • Guidelines for Configuring PTP over Ethernet on page 240

Documentation
• Configuring PTP Multicast Master and Slave Ports for Ethernet Encapsulation on
page 274
Ports on page 281
Guidelines for Configuring PTP over Ethernet
Keep the following points in mind when you configure PTP over Ethernet for multicast
mode of transmission of PTP traffic:
• You can configure a port or a logical interface to be a master clock for PTP over Ethernet
to provide packet-based synchronization to base stations that support time and phase
alignment; this configuration is compliant with Annexure F of the IEEE 1588-2008
specification.
• Two multicast MAC addresses are used for PTP over Ethernet: 01-1B-19-00-00-00
and 01-80-C2-00-00-0E. The first address is a more standard Ethernet MAC address
that is expected to be flooded by all types of Ethernet bridges and switches and also
by a large number of base station vendors. A node with this MAC address can be a
node that does not process PTP packets. The second address is a reserved address in
the IEEE 802.1Q standard for Ethernet encapsulation that is required to be filtered and
not forwarded. This MAC address is used to ensure complete end-to-end support of
PTP, instead of transmission of packets through any network element that does not
support PTP. This address is the default address for G.8275.1 (PTP Profile for time or
phase distribution) and a node with this MAC address is a node that supports processing
of PTP packets.

• Both of the MAC addresses, 01-1B-19-00-00-00 and 01-80-C2-00-00-0E, are

supported on multiple ports simultaneously to enable maximum flexibility and extension
of existing networks for future deployments. A single PTP port is configured for one of
the MAC addresses at a time.
• PTP packets are sent with the unique MAC address assigned to each port as the MAC
source address. In the PTP packet, the Ethernet frame portion of the packet contains
the Destination MAC field. This field contains either of the two MAC addresses,
01-1B-19-00-00-00 or 01-80-C2-00-00-0E. Also, the Ethernet frame portion contains
the Source MAC field that contains the MAC address of the source port and the
Ethertype field that contains the PTP Ethertype value of 0x88F7. Apart from the
Ethernet frame, the PTP packet contains the PTP payload.
• When you configure a port for PTP over Ethernet to be a slave port, a master port, or
both by having a dynamic port that can be either a master port or a slave port depending
on the states of the other ports in the PTP application, it is possible to build an easily
provisioned, redundant PTP service in an Ethernet ring where every node is configured
as a boundary clock.
• A boundary clock can function as a slave clock to a device using IP (such as a TCA
Series Timing Client or an MX Series router) on one port and can also function as a
slave clock, a master clock, or both on other ports using Ethernet as the encapsulation
method. This behavior occurs within a single PTP domain number.
• Best Master Clock Algorithm (BMCA) and the port state machine are supported to
determine the states of all the ports in a system and the correct state (master or slave)
for a certain port to process PTP packets.
• PTP over Ethernet supports fully redundant and resilient ring-based configurations of
up to 10 nodes for a form of fourth-generation (4G) evolution known as Long-Term
Evolution-Time Division Duplex (LTE-TDD). ACX Series routers support a single node
or link failure and all nodes maintain a phase accuracy of plus or minus 1.5 microseconds
matching a common source.
• You can configure the asymmetry value between the master port and the slave port,
which indicates a value to be added to the path delay value to make the delay
symmetric and equal to the path from the master port to the slave port, on either a
dynamic-state port or a slave-only port.
• You cannot enable PTP over Ethernet on Ethernet interfaces that are configured with
802.1Q VLAN tags or contain a user-configured MAC address.
• While you can configure unique PTP slave interfaces or slave ports with different
encapsulation mechanisms (such as IPv4 and Ethernet), the boundary clock can use
only a single encapsulation method for all of the master ports. Therefore, you must
define either IPv4 or Ethernet encapsulation for all the ports or logical interfaces that
can possibly function as boundary clock masters. Master ports select the link-local
flag based on each port.
• The following limitations apply to the maximum number of ports that you can configure
when you use PTP over Ethernet:

• You can configure a maximum of four slave ports on a router. A slave port or logical
interface is defined as any slave-only port configured for IPv4 or Ethernet, or any
dynamic port configured for Ethernet.
• You can configure up to 29 master ports on a router. A master port or logical interface
is defined as any master-only port configured for IPv4 or Ethernet, or any dynamic
port configured for Ethernet.
• Any logical interface that you configure as a dynamic port is considered to be both
a slave port and a master port, even if it functions only as a slave port or a master
port in a network, when the total number of slave ports and master ports on a router
is computed.
• In PTP over IPv4 deployment, it is necessary to configure certain basic settings on a

PTP master port before the PTP slave ports to connect to the master port. PTP over
Ethernet offers a plug-and-play service because any PTP client starts receiving packets
and can request delay-response packets from the master port after you configure an
interface to be a master.
• PTP over Ethernet is compatible with Junos OS releases earlier than Release 12.3X51.
When you perform an upgrade to Release 12.3X51 and later from a previous release on
an ACX Series router, you can modify the slave and master ports previously configured
for IPv4 to enable PTP over Ethernet based on your network needs.
• You cannot configure a fully redundant PTP ring using IP. A fully redundant PTP ring
is supported only when Ethernet encapsulation is used.
• Configuration of dynamic ports in conjunction with Synchronous Ethernet to enable

hybrid mode is not supported.
• Multiple PTP timing domains are not supported for PTP over Ethernet, similar to PTP
over IPv4. Although a single node can contain interfaces configured for PTP over IPv4
and PTP over Ethernet, both of these interfaces must be part of the same PTP domain.
• SONET/SDH networks define the ability to configure a local priority to a synchronization

source in the ITU G.781 standard. Addition of such locally configured priorities to PTP
sources to influence BMCA to determine a particular path for PTP packets is not
supported.
• Although you can configure a slave port to use either IP or Ethernet simultaneously, a
single slave port is selected based on the announce messages it receives from the
master port and the PTP event packets are exchanged only with a single master port.
• The IPv4 unicast implementation of PTP enables you to limit the number of slave ports
that can be supported simultaneously in the system. With multicast Ethernet-based
implementation, in which the master port is not provisioned with the slave port
information, the master port cannot limit the number of slave ports that it services.
This control must be exercised with proper networking planning and design.
Related • PTP over Ethernet on ACX Series Routers Overview on page 238
Documentation
page 274

Ports on page 281
Configuring Precision Time Protocol Clocking
In a distributed network, you can configure Precision Time Protocol (PTP) master and
slave clocks to help synchronize the timing across the network. The synchronization is
achieved through packets that are transmitted and received in a session between the
master clock and the slave clock or clock client.
To configure Precision Time Protocol (PTP) options:
1. In configuration mode, go to the [edit protocols ptp] hierarchy level.
[edit]
user@host# edit protocols ptp
2. Specify the clock as a boundary or ordinary clock. The boundary option signifies that
the clock can be both a master clock and a slave clock. The ordinary option signifies
that the clock is a slave clock.
[edit protocols ptp]

user@host# set clock-mode (boundary | ordinary)
3. (Optional) Enable PHY Timestamping. The PHY timestamping is disabled by default.

user@host# set transparent-clock
4. (Optional) Configure the PTP domain with values from 0 through 127. The default
value is 0.

user@host# set domain domain-value
5. (Optional) Specify the DiffServ code point (DSCP) value (0 through 63) for all PTP
IPv4 packets originated by the router. The default value is 56.

user@host# set ipv4-dscp number
6. Specify the master clock parameters.

user@host# set master
For details about configuring the master clock parameters, see “Configuring a PTP
Master Boundary Clock” on page 244.

7. (Optional) Configure the priority value of the clock (0 through 255). This value is used
in selecting the best master clock. The priority1-value is advertised in the master clock’s
announce message to clock clients. The default value is 128.

user@host# set priority1 priority1-value
8. (Optional) Configure the tie-breaker in selecting the best master clock (0 through
255). The priority2 value differentiates and prioritizes the master clock to avoid
confusion when the priority1-value is the same for different master clocks in a network.
The default value is 128.

user@host# set priority2 priority2-value
9. Specify the PTP slave clock parameters.

user@host# set slave
For information about configuring the slave clock options, see “Configuring a PTP
Slave Clock” on page 254.
10. (Optional) Enable unicast negotiation. Unicast negotiation is a method by which the
announce, synchronization, and delay response packet rates are negotiated between
the master clock and the clock client before a PTP session is established.

user@host# set unicast-negotiation
NOTE: Unicast negotiation, when enabled, does not allow you to commit
packet rate–related configurations.
Related • IEEE 1588v2 PTP Boundary Clock Overview on page 234

Documentation
Configuring a PTP Master Boundary Clock
A Precision Time Protocol (PTP) master boundary clock sends PTP messages to the
clients (ordinary and boundary) so that they can establish their relative time offset from
this master’s clock or clock reference. You cannot configure an ordinary master clock on
a device. The master boundary clock synchronizes time through a boundary slave port.
To configure a master boundary clock, you must include the boundary statement at the

[edit protocols ptp clock-mode] hierarchy level and at least one master with the master
statement and at least one slave with the slave statement at the [edit protocols ptp]
hierarchy level.
NOTE: ACX5048 and ACX5096 routers do not support ordinary and boundary
clock.
To configure a PTP master boundary clock, complete the following tasks:
• Configuring the PTP Master Boundary Clock Parameters on page 245

• Configuring a PTP Master Boundary Clock Interface on page 246
Configuring the PTP Master Boundary Clock Parameters

To configure the parameters of a PTP master boundary clock:
1. Configure the clock mode.

user@host# set clock-mode boundary
2. Configure the master clock.

user@host# edit master
3. (Optional) Specify the log mean interval between announce messages—from 0

through 4. By default, one announce message is sent every two seconds. This
configuration is used for manual clock clients. The master boundary clock sends
announce messages to manual clock clients as specified in the announce-interval
value.
[edit protocols ptp master]

user@host# set announce-interval announce-interval-value
4. Configure the interface on which to respond to downstream PTP clients and slaves.

For details about configuring the parameters for the master boundary clock interface,
see “Configuring a PTP Master Boundary Clock Interface” on page 246
5. (Optional) Specify the maximum log mean interval between announce

messages—from 0 through 4. The default value is 4.

user@host# set max-announce-interval max-announce-interval-value
6. (Optional) Specify the maximum log mean interval between delay-response

messages—from –7 through 4. The default value is 4.


user@host# set max-delay-response-interval max-delay-response-interval-value
7. (Optional) Specify the maximum log mean interval between synchronization


user@host# set max-sync-interval max-sync-interval-value
8. (Optional) Specify the minimum log mean interval between announce messages—from
–0 through 4. The default value is 0.

user@host# set min-announce-interval min-announce-interval
9. (Optional) Specify the minimum log mean interval between delay-response

messages—from –7 through 4. The default value is –7.

user@host# set min-delay-response-interval min-delay-response-interval
10. (Optional) Specify the minimum log mean interval between synchronization

user@host# set min-sync-interval min-sync-interval-value
11. (Optional) Specify the log mean interval between synchronization messages—from
–7 through 4. The default value is –6. This configuration is used for manual clock
clients. The master boundary clock sends synchronization messages to manual clock
clients as specified in the syn-interval-value statement.

user@host# set sync-interval sync-interval-value
After you have configured the PTP master boundary clock parameters, enter the commit
command from configuration mode. To complete the configuration of the master
boundary clock, complete “Configuring a PTP Master Boundary Clock Interface” on
page 246.
Configuring a PTP Master Boundary Clock Interface

After you have configured the master boundary clock parameters, complete the
configuration of the master boundary clock by configuring an interface to act in the role
of the master clock.
To configure a PTP master boundary clock interface:
1. Configure the interface on which to respond to downstream PTP slaves or clients.


NOTE: For the configuration to work, the interface you specify must be
configured at the [edit interfaces interface-name] hierarchy level.
2. On this interface, configure downstream PTP clients.
[edit protocols ptp master interface interface-name]

user@host# edit unicast-mode
3. Configure the IP address of the remote PTP host, or configure a subnet mask so that
any host belonging to that subnet can join the master clock. You can configure up to
512 clients for each master boundary clock.
[edit protocols ptp master interface interface-name unicast-mode]

user@host# edit clock-client ip-address
NOTE: You can configure the maximum number of clients (512 ) in the
following combination:
• Automatic clients 256.
• Manual and secure clients 256—Any combination of manual and secure

clients is allowed as long as the combined total amounts to 256.
NOTE: When you toggle from a secure slave to an automatic slave or vice
versa in the PTP configuration of a boundary clock, you need to delete the
existing PTP configuration and issue the commit command, and then you
add a new PTP configuration and issue the commit command.
4. Configure the IP address of the interface acting as the local PTP master.
[edit protocols ptp master interface interface-name unicast-mode clock-client

ip-address]
user@host# set local-ip-address local-ip-address
5. (Optional) When the unicast-negotiation statement is configured at the [edit protocols

ptp] hierarchy level, configure a clock client to immediately receive announce and
synchronization messages from the master boundary clock without unicast negotiation.
[edit protocols ptp master interface interface-name unicast-mode clock-client ip-address

local-ip-address local-ip-address]
user@host# set manual
6. Specify the encapsulation type for PTP packet transport—IPv4. This statement is
mandatory.
[edit protocols ptp master interface interface-name unicast-mode]

user@host# set transport ipv4

After you have configured the PTP master clock interface, enter the commit command
from configuration mode.
Example: Configuring a PTP Boundary Clock
This example shows how to configure a Precision Timing Protocol (PTP) boundary clock.
A boundary clock must include the configuration of at least one master and at least one
slave. The boundary master receives time from a remote master through the slave, and
in turn passes that time on to clock clients, which are in a slave relationship to the
boundary master. In this example, you configure a master, slave, clock source, and clock
client.
NOTE: ACX5048 and ACX5096 routers do not support boundary clock.

Requirements
NOTE: This example also applies to QFX Series switches. QFX Series switches
do not support Gigabit Ethernet interfaces. Instead, configure PTP boundary
clock parameters on 10-Gigabit Ethernet interfaces.
• An ACX Series router
Overview
In this example, the slave clock or clock client immediately receives announce and
synchronization packets after completion of the configuration.
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them in a text
level:
set protocols ptp clock-mode boundary

set protocols ptp slave interface ge-1/3/9.0 unicast-mode transport ipv4
set protocols ptp slave interface ge-1/3/9.0 unicast-mode clock-source 192.1.1.2
local-ip-address 192.1.1.1
set protocols ptp master interface ge-1/0/0.0 unicast-mode transport ipv4

set protocols ptp master interface ge-1/0/0.0 unicast-mode clock-client 20.20.20.2/32

Procedure hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration
To configure a boundary clock without unicast negotiation:

2. Configure the slave interface.

user@host# edit slave interface ge-1/3/9.0
3. Configure the upstream unicast PTP master clock source parameters.
[edit protocols ptp slave interface ge-1/3/9.0]

4. Configure the encapsulation type for PTP packet transport.
[edit protocols ptp slave interface ge-1/3/9.0 unicast-mode ]

5. Configure the IP address of the master interface.

user@host# edit master interface ge-1/0/0.0
6. Specify the IP address and subnet of the remote PTP host, and the IP address of
the local PTP master interface.
[edit protocols ptp master interface ge-1/0/0.0 ]

user@host# set protocols ptp master interface ge-1/0/0.0 unicast-mode clock-client
20.20.20.2/32 local-ip-address 20.20.20.1
NOTE: For the configuration to work, the master interface you specify
must be configured with this IP address at the [edit interfaces
interface-name] hierarchy level.
[edit protocols ptp master interface ge-1/0/0.0 unicast-mode]


Results From configuration mode, confirm your configuration by entering the show command. If
the output does not display the intended configuration, repeat the configuration
instructions in this example to correct it.

user@host# show
clock-mode boundary;
slave {
interface ge-1/3/9.0 {
unicast-mode {
transport ipv4;
clock-source 192.1.1.2 local-ip-address 192.1.1.1;
}
}
}
master {
unicast-mode {
transport ipv4;
clock-client 20.20.20.2/32 local-ip-address 20.20.20.1;
}
}
}
After you have configured the device, enter the commit command from configuration
mode.

Documentation
Example: Configuring a PTP Boundary Clock With Unicast Negotiation
This example shows how to configure a boundary clock with unicast negotiation turned
on and a mixture of manual, secure and automatic clock clients, which have a slave
relationship to the master boundary clock. The unicast negotiation applies to clock
sources, which are configured on the slave or clock client. Clock clients, configured on
the master, are not affected by unicast negotiation.
NOTE: ACX5048 and ACX5096 routers do not support boundary clock.

In this example, unicast-negotiation is applicable only to clock-sources. For clock clients,

the statement unicast-negotiation at the [edit protocols ptp] hierarchy level is not effective.

Requirements
Overview
A PTP slave clock or clock client can join a master clock with and without unicast
negotiation. With unicast negotiation, the announce, synchronization, and delay response
packet rates are negotiated between the master and the slave or client before a PTP
session is established. Without unicast negotiation and after it is configured, the slave
or client immediately receives announce and synchronization packets.
A clock client is the remote PTP host, which receives time from the PTP master. The
following clock clients are configured in this example:
• Secure client—A secure client is configured with an exact IP address, after which, it
joins a master clock through unicast negotiation. In this example, the clock client
clock-client 117.117.117.117/32 local-ip-address 109.109.109.53 is a secure client, which
means that only this specific host from the subnet can join the master clock through
a unicast negotiation .
• Automatic client—An automatic client is configured with an IP address, which includes

a subnet mask, indicating that any PTP host belonging to that subnet, can join the
master clock through a unicast negotiation. In this example, the clock client clock-client
109.109.109.0/24 local-ip-address 109.109.109.53 is an automatic client. Additionally,
this automatic client is configured on the same master clock
interface—109.109.109.53—as the secure client.
• Manual client—A manual client does not use unicast negotiation to join the master
clock. The manual statement overrides the unicast-negotiation statement configured
at the [edit protocols ptp] hierarchy level. As soon as you configure a manual client, it
starts receiving announce and synchronization packets. In this example, the clock client
clock-client 7.7.7.7 local-ip-address 7.7.7.53 manual is the manual client and is configured
on a second master clock interface.

Configuration
A boundary clock must include the configuration of at least one master and at least one
slave. The boundary master receives time from a remote master through the slave, and
in turn passes that time on to clock clients, which are in a slave relationship to the
boundary master. In this example, you configure a boundary slave, two Precision Time
Protocol (PTP) boundary masters with three different kinds of clock clients—automatic,
manual, and secure. Two of the clock clients are configured on the same boundary master.
level:

set protocols ptp unicast-negotiation
local-ip-address 7.7.7.53 manual
To configure a boundary clock with unicast negotiation:

2. Enable unicast negotiation.

user@host# set unicast-negotiation
3. Configure the local slave interface from which the boundary master receives time
and passes it on to the configured clock clients.




6. Configure the PTP master parameters by specifying the IP address of the PTP
master clock and the IP address of the local interface.

user@host# set clock-source 10.10.10.50 local-ip-address 10.10.10.53
7. Configure the first master interface in this example.

8. On the first master interface, configure the downstream PTP clock clients.
[edit protocols ptp master interface ge-0/1/3.0 ]

9. On the first master interface, configure the encapsulation type for PTP packet
transport.

10. On the first master interface, configure the PTP master parameters by specifying
the exact IP address of the remote PTP host and the IP address of the local PTP
master interface.

user@host# set clock-client 117.117.117.117 local-ip-address 109.109.109.53
11. On the first master interface, configure a second PTP master by specifying the IP
address and subnet of the second remote PTP host and the IP address of the local
PTP master interface.

user@host# set clock-client 109.109.109.0/24 local-ip-address 109.109.109.53
12. Configure the second master interface with the following parameters: the
encapsulation type, the downstream PTP host, the IP address of the local PTP
master interface, and the manual statement so that this client does not use unicast
negotiation.

user@host# set interface ge-0/1/5.0 unicast-mode transport ipv4
user@host# set interface ge-0/1/5.0 unicast-mode clock-client 7.7.7.7
local-ip-address 7.7.7.53 manual

Results From configuration mode, confirm your configuration by entering the show command. If

user@host# show
unicast-negotiation;
slave {
unicast-mode {
transport ipv4;
}
}
}
master {
unicast-mode {
transport ipv4;
}
}
unicast-mode {
transport ipv4;
clock-client 7.7.7.7/32 local-ip-address 7.7.7.53 {
manual;
}
}
}
}
After you have configured the device, enter the commit command from configuration
mode.

Documentation
Configuring a PTP Slave Clock
The slave port that you configure can be a Precision Time Protocol (PTP) boundary or
ordinary clock, depending on the configuration of the clock-mode statement at the [edit
protocols ptp] hierarchy level. An ordinary or boundary slave clock performs frequency

and phase recovery based on received and requested timestamps from a master clock—a
grandmaster or a boundary clock master.

on ACX500 router.
To configure a PTP slave clock, complete the following tasks:
• Configuring the PTP Slave Clock Parameters on page 255

• Configuring the PTP Slave Clock Interface on page 257
Configuring the PTP Slave Clock Parameters

To configure a PTP slave clock.
NOTE: The clock-class-to-quality-level-mapping quality-level,

convert-clock-class-to-quality-level, and grant-duration statements are not
supported on the QFX10002 switch.
1. Configure the clock mode:

2. Configure the slave clock.

user@host# edit slave
3. (Optional) Specify the rate of announce messages that a PTP slave requests from
the master during a unicast-negotiation session—from 0 through 4. The default value
is 1.
[edit protocols ptp slave]

NOTE: The configuration of the announce-interval statement is effective

only when the unicast-negotiation statement is also configured at the [edit
protocols ptp] hierarchy level.
4. (Optional) Specify the number of announce messages that a slave—configured on

an ACX Series router—must miss before an announce timeout is declared—from 2
through 10. The default value is 3.

user@host# set announce-timeout announce-timeout-value

5. (Optional) Override the default PTP clock class to Ethernet Synchronization Message
Channel (ESMC) mapping and specify the quality level for the PTP timing source.

user@host# set clock-class-to-quality-level-mapping quality-level (prc | prs |sec |
smc | ssu-a | ssu-b | st2 | st3 | st3e | st4 | stu | tnc)
6. (Optional) Enable retrieval of ESMC information from the PTP clock class.

user@host# set convert-clock-class-to-quality-level
7. (Optional) Specify the logarithmic mean interval in seconds between the delay request
messages sent by the slave to the master—from –6 through 3. The default value is
0.

user@host# set delay-request delay-request-value
8. (Optional) Specify the grant duration value. When unicast negotiation is enabled, the
local PTP slave requests announce, synchronization, and delay-response messages
from the master. In each request, the slave asks for the packets to be sent at a specified
rate and the slave provides a duration for which the rate is valid. The grant-duration
value is specified in seconds. The default grant duration is 300 seconds.

user@host# set grant-duration interval
9. Configure the interface for the slave.

For details about configuring the slave interface, see “Configuring the PTP Slave Clock
Interface” on page 257.
10. (Optional) Configure the log mean interval between synchronization messages—from
–6 through -3. The default value is –6 or 64 synchronous interval messages sent per
second

After you have configured the PTP slave clock parameters, enter the commit command
from configuration mode. To complete the configuration of the slave clock, complete
“Configuring the PTP Slave Clock Interface” on page 257.

Configuring the PTP Slave Clock Interface

The slave clock interface responds to the upstream PTP master clock.
To configure the PTP slave clock interface:
1. Configure the interface for the slave clock.

[edit protocols ptp slave interface interface-name]

3. Configure the IP address of the master, which acts as a source of time for this slave.
[edit protocols ptp slave interface interface-name unicast-mode]

user@host# edit clock-source ip-address
NOTE: To configure additional master clock sources for the slave, include
the clock-source statement up to four times. However, synchronization is
to only one master clock.
4. Specify the IP address of the interface acting as the local PTP slave port.
[edit protocols ptp slave interface interface-name unicast-mode clock-source ip-address]

user@host# set local-ip-address local-ip-address
configured with this IP address at the [edit interfaces interface-name]
hierarchy level.
5. Configure the encapsulation type for PTP packet transport. This statement is
mandatory.
[edit protocols ptp slave interface interface-name unicast-mode]

After you have configured the PTP slave clock interface, enter the commit command
Example: Configuring an Ordinary Slave Clock With Unicast-Negotiation
This example shows the base configuration of a Precision Time Protocol (PTP) ordinary
slave clock with unicast-negotiation on an ACX Series router.

NOTE: ACX5048 and ACX5096 routers do not support ordinary clock.

Requirements
Overview
In this configuration, the ordinary slave clock uses unicast-negotiation and compensates
for some network asymmetry.
NOTE: The values in this example are for illustration purposes only. You can
set the values for each parameter according to your requirements.
Configuration
To configure an ordinary slave clock with unicast-negotiation, perform these tasks:
• Configuring an ordinary slave clock with unicast-negotiation on page 259

• Results on page 260

CLI Quick set ptp clock-mode ordinary

Configuration set ptp domain 110
set ptp unicast-negotiation
set ptp slave delay-request -6
set ptp slave announce-timeout 2
set ptp slave announce-interval 3
set ptp slave sync-interval -5
set ptp slave grant-duration 7200
set ptp slave interface ge-0/1/0.0 unicast-mode transport ipv4
set ptp slave interface ge-0/1/0.0 unicast-mode clock-source 10.10.10.50
local-ip-address 10.10.10.75 asymmetry -4500
Configuring an ordinary slave clock with unicast-negotiation
Step-by-Step 1. Configure the clock mode, domain, and unicast-negotiation:

Procedure
user@host# set clock-mode ordinary domain 110 unicast-negotiation
2. Configure the announce timeout and the announce interval:

user@host# set slave announce-timeout 2 announce-interval 3
3. Configure the synchronization interval and the grant duration:

user@host# set slave sync-interval -5 grant-duration 7200
4. Configure the slave interface:

5. Configure the unicast transport mode:

user@host# set unicast-mode transport ipv4
6. Configure the clock source:

user@host# edit unicast-mode clock-source 10.10.10.50 local-ip-address 10.10.10.75
7. Configure the asymmetric path:
[edit protocols ptp slave interface ge-0/1/0.0 unicast-mode clock-source 10.10.10.50

local-ip-address 10.10.10.75]
user@host# set asymmetry -4500
8. Verify the configuration:

[edit protocols ptp slave interface ge-0/1/0.0 unicast-mode clock-source 10.10.10.50

local-ip-address 10.10.10.75]
user@host# top
[edit]
user@host# edit protocols
[edit protocols]
user@host# show
See the output for the show command in the Results section.
Results
The following output shows the configuration of unicast-negotiation and compensation

for some network asymmetry. The unicast-negotiation statement includes the parameters
for the delay request, announce interval, synchronization interval, and grant duration
values. Interface ge-0/1/0.0 is configured to compensate for an asymmetric path to the
PTP master by subtracting 4.5 microseconds from the slave-to-master direction delay
calculations.
[edit protocols]
user@host# show
ptp {
clock-mode ordinary;
domain 110;
slave {
delay-request -6;
announce-timeout 2;
announce-interval 3;
sync-interval -5;
grant-duration 7200;
unicast-mode {
transport ipv4;
clock-source 10.10.10.50 local-ip-address 10.10.10.75 {
asymmetry -4500;
}
}
}
}
}
• slave
• unicast-mode

Example: Configuring an Ordinary Slave Clock Without Unicast-Negotiation
This example shows the base configuration of a Precision Time Protocol (PTP) ordinary
slave clock without unicast-negotiation on an ACX Series router.
NOTE: ACX5048 and ACX5096 routers do not support ordinary clock.

Requirements
Overview
In this configuration, unicast-negotiation is not configured, so the PTP slave has no control
over the rate of the negotiation. The PTP master (a Brilliant Grand Master or an MX Series
router) must be configured with the parameters of the PTP slave, such as announce,
synchronization, and delay-response packets to control the rate of the negotiation.
NOTE: The values in this example are for illustration purposes only. You can
set the values for each parameter according to your requirements.
Configuration
To configure an ordinary slave clock without unicast-negotiation, perform these tasks:
NOTE: The ipv4-dscp statement is not supported on the QFX10002 switch.
• Configuring an ordinary slave clock without unicast-negotiation on page 262


CLI Quick set protocols ptp clock-mode ordinary

Configuration set protocols ptp ipv4-dscp 46
Configuring an ordinary slave clock without unicast-negotiation
Step-by-Step 1. Configure the clock mode:

Procedure
user@host# set clock-mode ordinary
2. Configure the Differentiated Services code point (DSCP) value for all PTP IPv4
packets originated by the device:
NOTE: The ipv4-dscp 46 statement is not supported on QFX Series

switches.

user@host# set ipv4-dscp 46
3. Configure the slave interface:

4. Configure the unicast transport mode:

user@host# set unicast-mode transport ipv4
5. Configure the clock source:

user@host# unicast-mode clock-source 12.1.1.4 local-ip-address 12.1.1.5

user@host# top
[edit]
[edit protocols]
user@host# show
See the output for the show command in the Results section.

Results
In this example, the PTP slave on the local interface ge-0/2/0 is assigned a local IP
address of 12.1.1.5. Unicast-negotiation is not configured so the PTP master must be
explicitly configured with the details of the PTP slave (12.1.1.5).
[edit protocols]
user@host# show
ptp {
clock-mode ordinary;
ipv4-dscp 46;
slave {
unicast-mode {
transport ipv4;
}
}
}
}
• slave
• unicast-mode

Configuring Precision Time Protocol Over Integrated Routing and Bridging
Junos OS for ACX Series router supports configuring precision time protocol (PTP) over
integrated routing and bridging (IRB). You can configure a boundary clock node with PTP
(IPv4) over IRB in a master-only mode across single or multiple IRB logical interfaces.
To configure Precision Time Protocol (PTP) over IRB:
1. Configure physical interfaces with Layer 2 encapsulation and create logical units with
VLANs.
[edit interfaces ge-0/2/1]

flexible-vlan-tagging;
native-vlan-id 130;
unit 615 {
vlan-id 615;
}

unit 615 {
vlan-id 615;
}

unit 615 {
vlan-id 615;
}

native-vlan-id 130;
2. Configure physical interfaces on a bridge domain.
[edit bridge-domains]
bd-615 {
vlan-id 615;
}
3. Configure a routing instance for the bridge domain where physical interfaces are
members of the bridge domain.
bd-615 {

vlan-id 615;
routing-interface irb.615;
}
4. Configure an IRB logical interface with IPv4 address.
[edit interfaces irb]

unit 615 {
family inet {
address 10.255.210.130/27;
}
}
5. Configure PTP boundary clock master on IRB logical interface.

priority2 210;
slave {
unicast-mode {
transport ipv4;
clock-source 122.25.1.4 local-ip-address 122.25.1.5 {
asymmetry 680;
}
}
}
master {
unicast-mode {
transport ipv4;
}
}
interface irb.615 {
unicast-mode {
transport ipv4;
}
}
}
You can use the following commands to monitor and troubleshoot the configuration:
• show interfaces irb—View the configured logical IRB interface details.
• show ptp master detail—View the configured master and its status along with local
and remote client details.
• show bridge domain—View the configured bridge domain and the associated physical
interfaces and IRB routing instance details.
• show ptp lock-status detail—View the PTP lock status details.

• show ptp port detail—View the PTP port details.
• show ptp global-information—View the configured PTP parameters.
• show ptp clock—View the PTP clock information.

Documentation

Understanding Transparent Clocks in Precision Time Protocol

The Precision Time Protocol (PTP) standardized by IEEE 1588 improves the current
methods of synchronization used within a distributed network. You can use PTP across
packet-based networks including, but not limited to, Ethernet networks. Queuing and
buffering delays in the switch can cause variable delay to packets, which affects path
delay measurements. Queuing delays vary based on the network load and also depend
on the architecture of the switch or the router.
Transparent clocks measure and adjust for packet delay. The transparent clock computes
the variable delay as the PTP packets pass through the switch or the router. The switch
(QFX5100 or EX4600) or the router (ACX5048, or ACX5096 routers) acts as a transparent
clocks only and operates between the master and slave clocks in a distributed network.
Transparent clocks improve synchronization between the master and slave clocks and
ensure that the master and slave clocks are not impacted by the effects of packet delay
variation.
The transparent clock measures the residence time (the time that the packet spends
passing through the switch or the router), and adds the residence time into the correction
field of the PTP packet. The slave clock accounts for the packet delay by using both the
timestamp of when it started and the information in the correction field.
ACX5048 and ACX5096 routers support end-to-end transparent clocks. With an

end-to-end transparent clock, only the residence time is included in the correction field
of the PTP packets. The residence timestamps are sent in one packet as a one-step
process. In a two-step process, estimated timestamps are sent in one packet, and
additional packets contain updated timestamps.
NOTE: ACX5048 and ACX5096 routers support only the one-step process,
which means that the timestamps are sent in one packet.
You can enable or disable a transparent clock globally for the switch or router. With a
global configuration, the same configuration is applied to each interface. If the transparent
clock is disabled, PTP packet correction fields are not updated. If the transparent clock
is enabled, the PTP packet correction fields are updated.
PTP over Ethernet, IPv4, IPv6, unicast, and multicast for transparent clocks are supported.
NOTE: ACX5048 and ACX5096 routers do not support PTP over IPv6 for
transparent clocks.
ACX5048 and ACX5096 routers do not support the following:
• Boundary clock
• Ordinary clock
• Transparent clock over MPLS switched path
• Transparent clock with more than two VLAN tags

NOTE: ACX Series routers do not support transparent clock over MPLS
switched path.
NOTE: You might notice higher latency when you use copper SFP ports
instead of fiber SFP ports. In this case, you must compensate the latency
introduced by the copper SFP ports for the accurate CF (correction factor)
measurement.
Related • Configuring Transparent Clock Mode for Precision Time Protocol on page 269
Documentation
• e2e-transparent on page 1505
Configuring Transparent Clock Mode for Precision Time Protocol
In a distributed network, you can configure transparent clock for Precision Time Protocol
(PTP) for synchronizing the timing across the network. Junos OS supports the
e2e-transparent CLI statement at the [edit protocols ptp] hierarchy level to configure
transparent clock for Precision Time Protocol (PTP).
NOTE: Starting in Junos OS Release 17.2 onwards, to configure PTP

transparent clock, include the e2e-transparent CLI command at the [edit
protocols ptp] hierarchy level. The transparent-clock CLI command to configure
transparent clock at the [edit protocols ptp] hierarchy level is supported only
in Junos OS Release 12.3X54.
To configure the transparent clock mode for Precision Time Protocol (PTP):
1. In configuration mode, go to the [edit protocols ptp] hierarchy level.
[edit]
user@host# edit protocols ptp
2. Specify transparent clock mode:

user@host# set e2e-transparent
Related • Understanding Transparent Clocks in Precision Time Protocol on page 267

Documentation
• show ptp global-information

Configuring a PTP Transparent Clock
ACX Series routers supports transparent clock functionality. A Precision Time Protocol
(PTP) Transparent clock measures the residence time of PTP packets as they pass
through router. This residence time is added to the Correction Field of the PTP packet.
NOTE: Starting in Junos OS Release 17.1 onwards, to configure transparent

clock, include the e2e-transparent CLI command at the [edit protocols ptp]
hierarchy level. Prior to Junos OS Release 17.1, to configure transparent clock,
include the transparent-clock CLI command at the [edit protocols ptp]
hierarchy level.
The following points need to be considered while configuring a PTP transparent clock in
ACX routers:
• Domain numbers—Transparent clock functionality would compute the residence time

for PTP packets belonging to all domains.
• PTP-over-MPLS—Transparent clock functionality do not support PTP carried over

MPLS in ACX routers.
The PTP transparent clock functionality is supported on PTP-over-IP and

PTP-over-Ethernet (PTPoE).
NOTE: ACX routers do not support PTPoE over VLANs when it works in
ordinary clock or boundary clock mode.
To configure a PTP transparent clock:

2. Configure the transparent clock:

3. (Optional) Enable PHY Timestamping. The PHY timestamping is disabled by default.

Configuring PHY Timestamping
The PHY timestamping refers to the timestamping of the IEEE 1588 event packets at the
1-Gigabit Ethernet and 10-Gigabit Ethernet PHY. Timestamping the packet in the PHY

results in higher stability of recovered clock. The PHY timestamping on ACX updates the
correction field of the packet. ACX supports PHY timestamping in ordinary clock and
boundary clock modes.
NOTE: PHY timestamping is supported only on ACX500 line of routers.
The following points need to be considered while configuring PHY timestamping in ACX
routers:
• PHY timestamping is enabled or disabled on all the PHYs. You cannot selectively
enable or disable PHY timestamping on a particular interface.
• When PHY timestamping is enabled, the transparent clock functionality is also enabled.
NOTE: The PHYs on ACX do not support transparent clock functionality for
PTP-over-MPLS. You should not enable transparent clock or PHY
timestamping if PTP is transported over MPLS.
In ACX2000 router, the transparent clock operation is not supported on the

10-Gigabit Ethernet port.
To enable PHY timestamping on ACX routers, configure clock-mode (ordinary clock or

boundary clock) along with the transparent-clock CLI statement at the [edit protocols
ptp] hierarchy.

NOTE: Starting in Junos OS Release 17.1 onwards, to configure transparent

clock, include the e2e-transparent CLI command at the [edit protocols ptp]
hierarchy level. Prior to Junos OS Release 17.1, to configure transparent clock,
include the transparent-clock CLI command at the [edit protocols ptp]
hierarchy level.
• Enabling PHY Timestamping for Ordinary Clock Slave on page 271

• Enabling PHY Timestamping for Boundary Clock on page 272
• Enabling PHY Timestamping for Grandmaster Clock on page 272
Enabling PHY Timestamping for Ordinary Clock Slave

The following procedure enables you to configure PHY timestamping for ordinary clock
slave in ACX:
1. Configure the clock mode as ordinary.


2. Configure the transparent clock.

3. Configure the interface for slave clock. For information on configuring PTP slave clock
interface, see “Configuring a PTP Slave Clock” on page 254.

user@host# set slave interface interface-name...
Enabling PHY Timestamping for Boundary Clock

The following procedure enables you to configure PHY timestamping for boundary clock
in ACX:
NOTE: PHY timestamping is supported only on ACX500 line of routers.
1. Configure the clock mode as boundary.



4. Configure the interface for master clock. For information on configuring PTP master
boundary clock, see “Configuring a PTP Master Boundary Clock” on page 244.

user@host# set master interface interface-name...
Enabling PHY Timestamping for Grandmaster Clock

The following procedure enables you to configure PHY timestamping for grandmaster
clock in ACX:

on ACX500 router.
1. Configure the clock mode as ordinary.




Configuring PHY Timestamping on ACX2200 Routers
The PHY timestamping refers to the timestamping of the IEEE 1588 event packets at the
1-Gigabit Ethernet and 10-Gigabit Ethernet PHY. Timestamping the packet in the PHY
results in higher stability of recovered clock. The PHY timestamping on ACX updates the
correction field of the packet. ACX2200 supports PHY timestamping in boundary clock
mode.
The following points need to be considered while configuring PHY timestamping in ACX
routers:
• PHY timestamping is enabled or disabled on all the PHYs. You cannot selectively
enable or disable PHY timestamping on a particular interface.
• When PHY timestamping is enabled, the transparent clock functionality is also enabled.
NOTE: The PHYs on ACX do not support transparent clock functionality for
PTP-over-MPLS. You should not enable transparent clock or PHY
timestamping if PTP is transported over MPLS.
To enable PHY timestamping on ACX2200 routers, configure boundary clock along with
e2e-transparent CLI statement at the [edit protocols ptp] hierarchy.

• Enabling PHY Timestamping for Boundary Clock on page 273
Enabling PHY Timestamping for Boundary Clock

The following procedure enables you to configure PHY timestamping for boundary clock
in ACX2200 routers:
1. Configure the clock mode as boundary.

user@host# set boundary

2. Enable Phy timestamping on boundary clock.



G.703 2.048MHz Signal Type for BITS Interfaces Overview
The ITU-T Recommendation G.703, Physical/electrical characteristics of hierarchical

digital interfaces, is a standard method for encoding clock and data signals into a single
signal. This signal is then used to synchronize various data communications devices, such
as switches, routers and multiplexers at a data rate of 2.048 MHz. Both directions of the
G.703 signal must use the same signal type. To configure signal type parameters for a
building-integrated timing supply (BITS) interface, include the following statements at
the [edit chassis synchronization ] hierarchy level:
interfaces bits {
signal-type (2048khz | e1 | t1);
e1-options {
framing (g704 | g704-no-crc4);
}
t1-options {
framing (esf | sf);
}
}
}
Related • synchronization (ACX Series) on page 1739

Documentation
• show chassis synchronization on page 2386
Configuring PTP Multicast Master and Slave Ports for Ethernet Encapsulation
On an ACX Series router, you can configure a Precision Time Protocol (PTP) master
boundary clock with IEEE 802.3 or Ethernet encapsulation of PTP messages to the clients
(ordinary and boundary) so that they can establish their relative time offset from this
master's clock or clock reference. PTP over Ethernet uses multicast addresses for
communication of PTP messages between the slave clock and the master clock. The
slave clock automatically learns of master clocks in the network, is immediately able to

receive the multicast messages from the master clock, and can begin sending messages
to the master clock without any pre-provisioning. The master boundary clock synchronizes
time through a slave boundary port.
To configure PTP over Ethernet with multicast master and slave ports, you must include
the multicast-mode transport ieee-802.3 statement at the [edit protocols ptp master
interface interface-name] and [edit protocols ptp slave interface interface-name] hierarchy
levels, respectively.
To configure a PTP over Ethernet master boundary clock and slave boundary clock for
multicast transmission, complete the following tasks:
• Configuring the PTP over Ethernet Master Boundary Clock Parameters on page 275
• Configuring the PTP over Ethernet Master Boundary Clock Interface on page 277
• Configuring the PTP over Ethernet Slave Clock Parameters on page 277
• Configuring the PTP over Ethernet Slave Clock Interface on page 279
Configuring the PTP over Ethernet Master Boundary Clock Parameters

To configure the parameters of a PTP over Ethernet master boundary clock:

2. Configure the master clock.

user@host# edit master
3. (Optional) Specify the log mean interval between announce messages—from 0

through 4. By default, one announce message is sent every two seconds. This
configuration is used for manual clock clients. The master boundary clock sends
announce messages to manual clock clients as specified in the announce-interval
value.

4. Configure the interface on which to respond to downstream PTP clients or slave ports.

For details about configuring the parameters for the master boundary clock interface,
see “Configuring the PTP over Ethernet Master Boundary Clock Interface” on page 277
5. (Optional) Specify the maximum log mean interval between announce

messages—from 0 through 4. The default value is 4.

user@host# set max-announce-interval max-announce-interval-value
6. (Optional) Specify the maximum log mean interval between delay-response


user@host# set max-delay-response-interval max-delay-response-interval-value
7. (Optional) Specify the maximum log mean interval between synchronization


user@host# set max-sync-interval max-sync-interval-value
8. (Optional) Specify the minimum log mean interval between announce messages—from
0 through 4. The default value is 0.

user@host# set min-announce-interval min-announce-interval
9. (Optional) Specify the minimum log mean interval between delay-response


user@host# set min-delay-response-interval min-delay-response-interval
10. (Optional) Specify the minimum log mean interval between synchronization

user@host# set min-sync-interval min-sync-interval-value
11. (Optional) Specify the log mean interval between synchronization messages—from
–7 through 4. The default value is –6. This configuration is used for manual clock
clients. The master boundary clock sends synchronization messages to manual clock
clients as specified in the syn-interval-value statement.

After you have configured the PTP master boundary clock parameters, enter the commit
command from configuration mode. To complete the configuration of the master
boundary clock, complete “Configuring the PTP over Ethernet Master Boundary Clock
Interface” on page 277.

Configuring the PTP over Ethernet Master Boundary Clock Interface

After you configured the master boundary clock parameters for PTP over Ethernet with
multicast transmission of PTP traffic, complete the configuration of the master boundary
clock by configuring an interface to act in the role of the master clock.
To configure a PTP over Ethernet master boundary clock interface:
1. Configure the interface on which to respond to downstream PTP slave ports or clients.

2. On this interface, configure multicast as the transmission mode of traffic for PTP
clients.
[edit protocols ptp master interface interface-name]

user@host# edit multicast-mode
3. Specify the encapsulation type for PTP packet transport as Ethernet or IEEE 802.3.
This statement is mandatory.
[edit protocols ptp master interface interface-name multicast-mode]

user@host# set transport ieee-802.3
Alternatively, specify the encapsulation type as Ethernet with the link-local multicast
address to be used in the sending of PTP messages. If you specify the link-local
attribute, the master clock chooses either of the two MAC addresses defined in the
IEEE 1588-2008 standard. When you configure this option, the system attempts to
use the 01 -80-C2-00-00-0E MAC address (link-local multicast MAC address) for
multicast transmission. If this MAC address is not available, the 01-1B-19-00-00-00
address (standard Ethernet multicast address) is used as the second priority. The
standard Ethernet multicast address is used by default. You need to explicitly configure
the link-local multicast address.

user@host# set transport ieee-802.3 link-local
After you have configured the PTP over Ethernet master clock interface, enter the commit
Configuring the PTP over Ethernet Slave Clock Parameters

An interface on which the master clock is configured is called a master interface and an
interface on which the slave clock is configured is called a slave interface. A master
interface functions as the master port and a slave interface functions as the slave port.
Because PTP over Ethernet uses multicast addresses, a slave port can automatically

start receiving the multicast announce messages transmitted by the master ports on a
network and can also start communication with the master port with minimal or no
configuration. You can optionally configure these settings for a slave port that
communicates with the master ports using PTP over Ethernet.
To configure a PTP over Ethernet slave clock.

2. Configure the slave clock.

user@host# edit slave
3. (Optional) Specify the number of announce messages that a slave clock or

port—configured on an ACX Series router—must miss before an announce timeout is
declared—from 2 through 10. The default value is 3.

user@host# set announce-timeout announce-timeout-value
4. (Optional) Specify the logarithmic mean interval in seconds between the delay request
messages sent by the slave port to the master port—from –6 through 3. The default
value is 0.

user@host# set delay-request delay-request-value

6. (Optional) Configure the log mean interval between synchronization messages—from

–6 through -3. The default value is –6, which means by default, 64 synchronous
interval messages sent per second.

After you have configured the PTP slave clock parameters, enter the commit command
in configuration mode. To complete the configuration of the slave clock, complete
“Configuring the PTP over Ethernet Slave Clock Interface” on page 279

Configuring the PTP over Ethernet Slave Clock Interface

The slave clock interface responds to the upstream PTP master clock.
To configure the PTP slave clock interface:

2. Configure the upstream multicast PTP master clock source parameters.
[edit protocols ptp slave interface interface-name]

[edit protocols ptp slave interface interface-name multicast-mode]

[edit protocols ptp slave interface interface-name multicast-mode]

After you have configured the PTP over Ethernet slave clock interface, enter the commit
command in configuration mode.
Documentation
Ports on page 281

Configuring PTP Dynamic Ports for Ethernet Encapsulation
For PTP over Ethernet, you can also configure a port to function as both a slave port and
a master port. This type of port is called a dynamic port, a stateful port, or a bidirectional
port. Such a dynamic port enables the transfer of frequency for synchronization services,
in addition to time and phase alignment, when PTP functionality is not hop-by-hop and
you have provisioned master and slave roles or interfaces.
To configure PTP over Ethernet with dynamic or bidirectional ports for multicast mode
of transmission, you must include the multicast-mode statement at the [edit protocols
ptp stateful interface interface-name] hierarchy level.
To enable a node to function as both a master and a slave port in PTP over Ethernet
networks:
1. Configure the interface on which to respond to downstream PTP slave ports or clients.
[edit protocols ptp stateful]

2. Configure the upstream multicast PTP dynamic clock source parameters.
[edit protocols ptp stateful interface interface-name]

[edit protocols ptp stateful interface interface-name multicast-mode]

[edit protocols ptp stateful interface interface-name multicast-mode]

After you have configured the PTP over Ethernet slave clock interface, enter the commit

Documentation
page 274
Ports on page 281
Example: Configuring PTP over Ethernet for Multicast Master, Slave, and Dynamic
Ports
In PTP over Ethernet networks, the master sends the announce, synchronization, and
delay-response packets using the multicast method. If any unicast delay-request message
is received, the master disregards the message and does not send delay-response
messages to the slave. A PTP slave receives the multicast announce packets from the
master or multiple masters and determines the best master using Best Master Clock
Algorithm (BMCA). A slave receives and processes the synchronization from the selected
master clock. The slave sends delay-request messages to this master using the multicast
method and processes the delay-response messages from the master to establish
synchronization.
Both the link-local MAC address and the standard 802.3 multicast MAC address can be
present in a system. However, a PTP interface supports only one of the following at a
point in time:
• Layer 2 multicast with link-local MAC address
• Layer 2 multicast with standard multicast MAC address
• PTP over IPv4
When you configure both IPv4 and Ethernet encapsulation, the unicast-negotiation
configuration applies only to IPv4 encapsulation. It is not effective for PTP over Ethernet
operation.
When you configure a logical interface by using the stateful statement at the [edit
protocols ptp] hierarchy level, each interface that you configure as a stateful or dynamic
port is considered to be both a master and a slave port. Although an ACX Series router
supports up to 32 master ports and 4 slave ports, you can configure only 4 unique logical
interfaces as potential PTP masters by using the stateful statement because the interface
is treated as both a slave and a master interface. You cannot configure the interface that
you specify to be a stateful or dynamic port with the master or slave statements.
This example shows how to configure a master port, slave port, and a dynamic port for
PTP over Ethernet and PTP over IPv4 encapsulation, and how to configure unicast and
multicast mode of transmission of PTP traffic among the master and slave nodes.



• Verifying the PTP over Ethernet Multicast Dynamic, Master, and Slave
Settings on page 286
Requirements
• Junos OS Release 12.3X51 or later
Overview
While an ACX Series router supports the PTP over Ethernet functionality, a Brilliant Grand
Master such as an MX Series router or a TCA Series Timing Client does not support PTP
over Ethernet. Consider a sample deployment in which an ACX Series router named ACX1
functions as a boundary clock with a PTP slave port using IPv4 as the encapsulation
mode and master ports using Ethernet as the encapsulation mode for PTP traffic. ACX1
contains two potential slave interfaces, one that is fixed as a slave-only port using IPv4
on the link toward an MX Series router named MX2, and a dynamic port that functions
as a slave using PTP over Ethernet on the link toward another ACX Series router named
ACX2. In addition, ACX1 also contains a port that is a master-only port using PTP over
Ethernet and connects to the base station.
In this example, the router uses either interface ge-0/2/0.0 or ge-0/2/1.0 as the selected
slave interface based on the announce messages received from the master and the port
that was selected using the Best Master Clock Algorithm (BMCA). The interface ge-0/1/4.0
is always in the master state. According to the IEEE 1588 specification, if port ge-0/2/0.0
is selected as the slave interface, interface ge-0/2/1.0 transitions to the master state. If
interface ge-0/2/1.0is selected as the slave port, interface ge-0/2/0.0 transitions to the
listening state. You can also configure the interface ge-0/1/4.0 as a slave only interface
for PTP over Ethernet, if necessary, for completeness of the configuration.
Configuration
In this example, you configure a master port, a slave port, and a dynamic port for PTP
over Ethernet and PTP over IPv4 encapsulation. You can also configure unicast and
multicast modes of transmission of PTP traffic among the master and slave nodes.
• Configuring PTP over Ethernet for Multicast Master, Slave, and Dynamic
Ports on page 283
level:
set interfaces ge-0/1/4 description “to base-station”

set interfaces ge-0/1/4 unit 0 family inet address 7.1.1.37/24

set interfaces ge-0/2/0 description “to MX2”

set interfaces ge-0/1/4 description “to ACX2”
set protocols ptp domain 110
set protocols ptp master interface ge-0/1/4.0 multicast-mode transport ieee-802.3
set protocols ptp stateful interface ge-0/2/1.0 multicast-mode transport ieee-802.3
Configuring PTP over Ethernet for Multicast Master, Slave, and Dynamic Ports
To configure the master, slave, and dynamic interfaces, and a boundary clock with unicast
and multicast mode of transmission of PTP packets in PTP over IPv4 and PTP over
Ethernet topologies:
1. Configure the master interface, and enter edit mode for the interface.
[edit interfaces]
user@host#edit ge-0/1/4
2. Configure a description for the interface.

user@host#set description to base-station
3. Configure a logical unit and specify the protocol family.

user@host#set unit 0 family inet
4. Specify the address for the logical interface
[edit interfaces ge-0/1/4 unit 0 family inet]

user@host#set address 7.1.1.37/24
5. Configure the slave interface, and enter edit mode for the interface.
[edit interfaces]

user@host#set description to-MX2



9. Configure the stateful interface, and enter edit mode for the interface.
[edit interfaces]

user@host#set description to-ACX2


13. Configure the clock mode as boundary clock.

14. Specify the PTP domain value.

user@host# set domain 110
15. Configure the local slave interface from which the boundary master receives time
and passes it on to the configured clock clients.


[edit protocols ptp slave interface ge-0/2/0.0 unicast-mode]


18. Configure the PTP master parameters by specifying the IP address of the PTP
master clock and the IP address of the local interface.
[edit protocols ptp slave interface ge-0/1/0.0 unicast-mode]

user@host# set clock-source 110.1.1.250 local-ip-address 110.1.1.2
19. Configure the master interface in this example.

20. On the master interface, configure multicast transmission for downstream PTP
clock clients.
[edit protocols ptp master interface ge-0/1/4.0]

21. On the master interface, configure the encapsulation type as Ethernet for PTP
packet transport.
[edit protocols ptp master interface ge-0/2/1.0 multicast-mode]

22. Configure the dynamic or stateful interface in this example.

user@host# edit stateful interface ge-0/2/1.0
23. On the dynamic interface, configure multicast transmission for downstream PTP
clock clients.
[edit protocols ptp stateful interface ge-0/2/1.0 ]

24. On the dynamic interface, configure the encapsulation type as Ethernet for PTP
packet transport and the link-local multicast address to be used.
[edit protocols ptp stateful interface ge-0/2/1.0 multicast-mode]

Results
In configuration mode, confirm your configuration by entering the show command. If the
output does not display the intended configuration, repeat the configuration instructions
in this example to correct it.

user@host# show
domain 110;
slave {

unicast-mode {
transport ipv4;
}
}
}
master {
multicast-mode {
transport ieee-802.3;
}
}
}
stateful {
multicast-mode {
transport ieee-802.3 link-local;
}
}
}
After you have configured the device, enter the commit command in configuration mode.
Verifying the PTP over Ethernet Multicast Dynamic, Master, and Slave Settings
• Verifying the PTP Clock Details on page 286

• Verifying the Lock Status of the Slave on page 287
• Verifying the PTP Options on the Slave on page 287
• Verifying the PTP Options and the Current Status of the Master on page 287
• Verifying the Number and Status of the PTP Ports on page 287
• Verifying PTP Statistics on page 288
Verifying the PTP Clock Details
Purpose Verify that the PTP clock is working as expected.
Action In operational mode, enter the run show ptp clock command to display comprehensive,
globally configured clock details.
Meaning The output displays the clock details, such as the encapsulation method used for
transmission of PTP traffic and the number of configured stateful or dynamic ports.
Although a dynamic port functions as either a slave or a master port, the value displayed
in the Stateful Ports field denotes the dynamic ports that you explicitly configured. The
number of dynamic ports is not computed and displayed in the fields that display the
explicitly configured master and slave ports. For more information about the run show
ptp clock operational command, see show ptp clock in the CLI Explorer.

Verifying the Lock Status of the Slave
Purpose Verify that the slave clock is aligned to the master clock by checking the lock status of
the slave.
Action In operational mode, enter the run show ptp lock-status command to display the lock
status of the slave.
Meaning The output displays information about the lock status of the slave. The output shows
whether the slave is aligned to the master clock or not, and the interface name configured
for PTP on the slave. The Master Source Port field displays the address of the master
clock when PTP over IPv4 is configured and the multicast MAC address of the source
when PTP over Ethernet is configured. For more information about the run show ptp
lock-status operational command, see show ptp lock-status in the CLI Explorer.
Verifying the PTP Options on the Slave
Purpose Verify the PTP options that are set on the slave and the current status of the master.
Action In operational mode, enter the run show ptp slave command to display the configured
slave.
Meaning The output displays information about the configured slave and the status of the slave.
For more information about the show ptp slave operational command, see show ptp slave
in the CLI Explorer.
Verifying the PTP Options and the Current Status of the Master
Purpose Verify the PTP options that are set for the master and its current status.
Action In operational mode, enter the run show ptp master command to display the configured
options for the master.
Meaning The output displays information about the configured master and the current status of
the master. For more information about the run show ptp master operational command,
see show ptp master in the CLI Explorer.
Verifying the Number and Status of the PTP Ports
Purpose Verify the number of PTP ports and their current status.
Action In operational mode, enter the run show ptp port command to display the configured
ports.

Meaning The output displays information about the number of ports created according to the
configuration and their current status. The name of the interface configured for PTP and
the number of times a stateful port transitioned from the slave to the master state and
vice versa is displayed. For more information about the run show ptp port operational
command, see show ptp port in the CLI Explorer.
Verifying PTP Statistics
Purpose Verify the statistical details of the PTP configuration.
Action In operational mode, enter the run show ptp statistics command to display the statistical
information regarding the configured PTP clocks.
Meaning The output displays brief or detailed information about the operation of configured PTP
clocks. Statistical parameters include information such as the total number of PTP
packets transmitted or received by a master or slave interface and the number of various
messages (such as announce and synchronization messages) that are sent between a
master and a slave. For more information about the show ptp statistics operational
command, see show ptp statistics in the CLI Explorer.
Documentation
page 274
Hybrid Mode on ACX Series Routers Overview
The combined operation of Synchronous Ethernet and Precision Time Protocol (PTP) is
also known as hybrid mode. The following sections explain hybrid mode in detail:
• Hybrid Mode Overview on page 288

• Supporting Platforms on page 289
Hybrid Mode Overview

In hybrid mode, the synchronous Ethernet equipment clock (EEC) on the Modular Port
Concentrator (MPC) derives the frequency from Synchronous Ethernet and the phase
and time of day from PTP. Time synchronization includes both phase synchronization
and frequency synchronization.
Synchronous Ethernet is a physical layer–based technology that functions regardless of

the network load. Synchronous Ethernet supports hop-by-hop frequency transfer, where
all interfaces on the trail must support Synchronous Ethernet. PTP (also known as IEEE
1588v2) synchronizes clocks between nodes in a network, thereby enabling the distribution

of an accurate clock over a packet-switched network. This synchronization is achieved

through packets that are transmitted and received in a session between a master clock
(commonly called the master) and a slave clock (also known as the slave in PTP
terminology). PTP synchronizes both frequency and phase including time of day. The
accuracy of clock synchronization depends on factors such as packet delay variation,
quality of oscillator used, network asymmetry, and so on.
Synchronous Ethernet and PTP provide frequency and phase synchronization; however,
the accuracy in the order of nanoseconds is difficult to achieve through PTP or
Synchronous Ethernet and they do not support a large number of network hops. Hybrid
mode resolves these issues by extending the number of network hops and also provides
clock synchronization accuracy in the order of tens of nanoseconds.
Hybrid mode is configured on the slave. On the slave, you can configure one or more
interfaces as Synchronous Ethernet source interfaces.
NOTE: Router clocks are categorized based on the role of the router in the
network. They are broadly categorized into ordinary clocks and boundary
clocks. The master clock and the slave clock are known as ordinary clocks.
The boundary clock can operate as either a master clock or a slave clock.
In hybrid mode, the following show commands display information regarding the hybrid
status configuration:
• The show ptp status details command displays the time and phase plane status.
• The show chassis synchronization extensive command displays the frequency plane
status.
• The show ptp hybrid status command displays the hybrid (combined status of frequency
and phase plane) status.
• In hybrid mode, the show ptp hybrid status and show ptp lock-status commands indicate
the lock status as Phase Aligned in the output.
For information about configuring hybrid mode, see Configuring Hybrid Mode and ESMC
Quality Level Mapping. You can use the show ptp hybrid status operational command to
find the current operating mode.
Supporting Platforms
Hybrid mode is supported on the Juniper Networks ACX Series Universal Access Routers.
The combined operation is possible only when the PTP client and the Synchronous
Ethernet source are on the same device and are traceable to the same primary reference
clock (also known as PRC).
When acting as PTP slaves, the ACX Series routers can accept any external Synchronous
Ethernet clock as reference and do not support building-integrated timing supply (BITS)
input as frequency source in hybrid mode of operation. Only Synchronous Ethernet sources

are allowed in hybrid mode. Note that when the selected Synchronous Ethernet reference
fails, the router continues to work in PTP mode.
Unified in-service software upgrade (unified ISSU) is not supported when clock
synchronization is configured for hybrid mode.
NOTE: To switch between PTP and Synchronous Ethernet modes, you must
first deactivate the configuration for the current mode and then commit the
configuration. Wait for 30 seconds, configure the new mode and its related
parameters, and then commit the configuration.
Related • Guidelines for Configuring Hybrid Mode on ACX Series Routers on page 290
Documentation
• Configuring Hybrid Mode and ESMC Quality Level Mapping on ACX Series Routers on
page 292
Guidelines for Configuring Hybrid Mode on ACX Series Routers
Keep the following points in mind while configuring hybrid mode on ACX Series routers:
• In a Hybrid Operation, the Frequency Module derives frequency from the Synchronous
Ethernet or BITS (T1/E1) clock or 10 MHz clock and Phase from the IEEE-1588v2
(PTPv2). The current deployments are all LTE-TDD based and require a phase accuracy
of only 1.5us and it is expected that this performance can be achieved without requiring
frequency assist.
• Frequency Plane (Synchronous Ethernet, BITS (T1/E1), 10 MHz) is not impacted by the
phase or time plane. The frequency plane derives the frequency from Synchronous
Ethernet, BITS (T1/E1) and 10 MHz.
• Phase/Time Plane uses the Frequency which is derived locally from the equipment
(Synchronous Ethernet, BITS (T1/E1), 10 MHz). To achieve phase accuracy of less than
1.5us, both Frequency Input source and PTP sources traceable to a primary reference
source (PRS) or primary reference clock (PRC). Hybrid mode is supported in a ring
topology.
• You can configure the following frequency sources for hybrid node:
• Synchronous Ethernet 1G, 10G with/without ESMC
• BITS T1 Clock
• BITS E1 Clock
• 10 MHz Clock
• T1 Interface
• E1 Interface
• You can configure the following phase sources for hybrid node:

• PTP IPv4 with or without unicast negotiation
• PTPoE with or without stateful port
• By enabling the hybrid mode, the convergence time period is reduced and locking
happens quickly.
• You can configure the PTP Source as phase or time source for hybrid mode.
• You can configure Layer 2 rings for PTPoE with stateful ports and Synchronous Ethernet
with ESMC for Layer 2 ring topologies.
• When you enable hybrid mode, each node generates a phase error of or plus or minus
100 nanoseconds (without Phy Timestamping) or plus or minus 50 nanoseconds with
Phy timestamping feature. This phenomenon requires Frequency (SyncE/BITS/10
MHz) source and PTP source must be traceable to same PRC/PRS source.
• Fully redundant and resilient ring based configurations of up to 10 nodes are supported,
targeting the 1 microsecond phase requirement for a form of 4G known as Long-Term
Evolution-Time Division Duplex (LTE-TDD). A single node or link failure is
accommodated and all nodes are able to maintain phase accuracy to be +/- 1us
accurate to a common source.
• Hybrid mode for PTP IPv4 rings is not supported.
• Dynamic switchover from Hybrid to PTP mode is not supported in ACX routers.
• BITS T1 Clock with SSM is not supported. BITS E1 Clock with SSM is not supported.
• Hybrid Mode: Time Of Day (TOD) as Phase and Frequency as SyncE/BITS/10 MHz is
not supported. Simultaneous PTP IPv4 Ring and SyncE Hybrid Mode are not supported.
• Hybrid Mode with Phy Timestamping feature is not supported only on ACX500 series
routers.
• Dynamic Switchover from Hybrid to PTP Mode feature is not supported.
• Hybrid Feature on aggregated Ethernet (ae-) interfaces is not supported.
• When you configure hybrid mode, the following processes take place.
• The best of the configured PTP time sources is selected by the PTP Best Master
Clock Algoritm (BMCA).
• The best of configured chassis synchronization sources is selected by the

synchronization source selection algorithm.
• During the boot-up process, if valid sources are configured at the [edit chassis
synchronization] hierarchy level and chassis synchronization mode in free-running
mode, valid PTP source available case, system continues to operate in hybrid mode
( In this case, chassis synchronization is in free-run mode, whereas PTP is in locked
mode). When both primary and secondary frequency sources fail, system still works
under hybrid mode ( In this case, chassis synchronization is in hybrid mode and PTP
is in locked mode).
Related • Hybrid Mode on ACX Series Routers Overview on page 288

Documentation

page 292
Configuring Hybrid Mode and ESMC Quality Level Mapping on ACX Series Routers
You can configure hybrid mode (that is, the combined operation of Synchronous Ethernet
and Precision Time Protocol (PTP)) on ACX Series routers. The combined operation is
possible only when the PTP client and the Synchronous Ethernet source are on the same
device and are traceable to the same master. When acting as a PTP slave, the router can
accept any external Synchronous Ethernet clock as reference. Note that when the selected
Synchronous Ethernet reference fails, the router continues to work in PTP mode.
In hybrid mode, the synchronous Ethernet equipment clock (EEC) on the MPC derives
the frequency from Synchronous Ethernet and the phase and time of day from PTP.
The hybrid mode is configured on the slave. On the slave, one or more interfaces are
configured as Synchronous Ethernet source interfaces.
The ESMC quality level value is mapped to the clock class value either by mapping the
PTP clock class to the ESMC quality level or by configuring a user-defined mapping of
PTP clock class to ESMC quality level. The following procedures explain configuring
hybrid mode with either of the modes in detail.
• Configuring the Router in Hybrid Mode on page 292

• Configuring Hybrid Mode with Mapping of the PTP Clock Class to the ESMC Quality
Level on page 293
• Configuring Hybrid Mode with a User-Defined Mapping of the PTP Clock Class to the
ESMC Quality Level on page 293
Configuring the Router in Hybrid Mode

To configure the router in hybrid mode, you must:
1. Configure Synchronous Ethernet options at the [edit chassis synchronization] hierarchy

level:
• Configure the auto-select mode of operation. You can select the clock source either
from a free-run local oscillator or from an external qualified clock.
When the router is configured with the auto-select option, the router chooses up to
two best upstream clock sources. It then uses the clock recovered from one of the
sources to lock the chassis clock. If an upstream clock with acceptable quality is
not available or if the router is configured in free-run mode, the router uses the
internal oscillator.
• Configure the esmc-transmit and network-option options at the [edit chassis

synchronization hierarchy level.
• Configure one or more interfaces at the [edit chassis synchronization] hierarchy level
as Synchronous Ethernet sources as needed.

2. Configure PTP options at the [edit protocols ptp] hierarchy level.
3. Configure hybrid mode options at the [edit protocols ptp slave] hierarchy level.
Configuring Hybrid Mode with Mapping of the PTP Clock Class to the ESMC Quality Level
To configure hybrid mode options with mapping of the PTP clock class to the ESMC
quality level, perform the following steps:
1. In configuration mode, go to the [edit protocols ptp slave] hierarchy level:
[edit]
user@host# edit protocols ptp slave
2. Configure the convert-clock-class-to-quality-level option to set the default mapping

between the ESMC SSM quality level and the PTP clock class.

3. Configure the hybrid mode option on the slave.

user@host# edit hybrid
4. Configure the upstream unicast PTP master interface and IP address of the clock
source.

user@host# set interface interface-name clock-source ip-address
5. Configure one or more Synchronous Ethernet source interfaces for the slave as needed.
[edit protocols ptp slave ]

user@host# set interface interface1-name unicast-mode clock-source ip-address
NOTE: You must first configure these interfaces at the [edit chassis
synchronization] hierarchy level as Synchronous Ethernet sources. For
information about configuring these interfaces, see synchronization (ACX
Series).
Configuring Hybrid Mode with a User-Defined Mapping of the PTP Clock Class to the ESMC
Quality Level
To configure hybrid mode options with a user-defined mapping of the PTP clock class
to the ESMC quality level, perform the following steps:
1. In configuration mode, go to the [edit protocols ptp slave] hierarchy level:
[edit]

user@host# edit protocols ptp slave
2. To override the default mapping option, perform the following steps:
a. Configure the clock-class-to-quality-level-mapping option with one of the quality

level values. The quality level values are prc, prs, sec, smc, ssu-a, ssu-b, st2, st3,
st3e, st4, stu, and tnc.

user@host# edit clock-class-to-quality-level-mapping quality-level prc | prs | sec
| smc | ssu-a | ssu-b | st2 | st3 | st3e | st4 | stu | tnc
b. Configure the clock-class option for the set quality level. The clock class value
ranges from 80 through 109.
[edit protocols ptp slave clock-class-to-quality-level-mapping quality-level

quality-level-value]
user@host# set clock-class clock-class
3. Configure the hybrid mode option on the slave.

4. Configure the upstream PTP master interface and the IP address of the clock source.

user@host# set interface interface-name unicast-mode clock-source ip-address
5. Configure one or more Synchronous Ethernet source interfaces for the slave as needed.
[edit protocols ptp slave ]

NOTE: You must first configure these interfaces at the [edit chassis
synchronization] hierarchy level as Synchronous Ethernet sources. For
information about configuring these interfaces, see synchronization (ACX
Series).
Documentation

Example: Configuring Hybrid Mode and ESMC Quality Level Mapping
This example shows the configuration of hybrid mode by mapping the PTP clock class
to the ESMC quality level and also by configuring a user-defined mapping of the PTP
clock class to the ESMC quality level on ACX Series Routers.
• Requirements for Hybrid Mode Configuration on page 295

Requirements for Hybrid Mode Configuration

• One ACX Series router.
• Junos OS Release 12.2R2 or later.
Overview
The combined operation of Synchronous Ethernet and Precision Time Protocol (PTP) is
also known as hybrid mode. In hybrid mode, the synchronous Ethernet equipment clock
(EEC) on the Modular Port Concentrator (MPC) derives the frequency from Synchronous
Ethernet and the phase and time of day from PTP.
You can configure hybrid mode on ACX Series routers. On these routers, the combined
operation is possible only when the PTP slave and the Synchronous Ethernet source are
on the same device and are traceable to the same master. When acting as a PTP slave,
the router can accept any external Synchronous Ethernet clock as reference. Note that
when the selected Synchronous Ethernet reference fails, the router continues to work in
PTP mode.
Hybrid mode is configured on the slave. On the slave, one or more interfaces are configured
as Synchronous Ethernet source interfaces.
NOTE: You can set the values for each parameter according to your
requirement. The values given in this example are for illustration purposes
only.
The ESMC quality level value is mapped to the clock class value either by
mapping the PTP clock class to the ESMC quality level or by configuring a
user-defined mapping of the PTP clock class to the ESMC quality level. The
following examples explain configuring hybrid mode with either of the modes
in detail.

To configure the router in hybrid mode, you must:
1. Configure Synchronous Ethernet options at the [edit chassis synchronization] hierarchy

level:
• Configure the auto-select mode of operation. You can select the clock source either
from a free-run local oscillator or from an external qualified clock.
When the router is configured with the auto-select option, the router chooses up to
two best upstream clock sources. It then uses the clock recovered from one of the
sources to lock the chassis clock. If an upstream clock with acceptable quality is
not available or if the router is configured in free-run mode, the router uses the
internal oscillator.
• Configure the esmc-transmit and network-option options at the [edit chassis

• Configure one or more interfaces at the [edit chassis synchronization] hierarchy level
as Synchronous Ethernet sources as needed.
2. Configure PTP options at the [edit protocols ptp] hierarchy level.
3. Configure hybrid mode options at the [edit protocols ptp slave] hierarchy level.
The following example requires you to navigate various levels in the configuration
hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode.
Configuration
• Hybrid Mode with Mapping of the PTP Clock Class to the ESMC Quality Level on page 296
• Hybrid Mode with a User-Defined Mapping of the PTP Clock Class to the ESMC Quality
Level on page 297
Hybrid Mode with Mapping of the PTP Clock Class to the ESMC Quality Level
CLI Quick To quickly configure hybrid mode on the ge-1/2/3.0 interface with the clock source IP
Configuration address as 2.2.2.2, copy the following commands, paste them in a text file, remove any
line breaks, and then copy and paste the commands into the CLI.
[edit]
set protocols ptp slave hybrid

set protocols ptp slave convert-clock-class-to-quality-level
Step-by-Step To configure hybrid mode on an ACX Series router with mapping of the PTP clock class
Procedure to the ESMC quality level, perform the following steps:
1. Configure the convert-clock-class-to-quality-level option on the slave at the [edit

protocols ptp slave] hierarchy level.

2. Configure hybrid mode on the slave.

3. Configure the Synchronous Ethernet mapping option, IP address of the master clock
as 2.2.2.2, and the interface ge-1/2/3.0 for hybrid mode on the slave.

user@host# set interface ge-1/2/3.0 unicast-mode clock-source 2.2.2.2
Results Display the results of the configuration of hybrid mode with the mapping of the PTP clock
class to the ESMC quality level:

user@host# show
convert-clock-class-to-quality-level
interface ge-1/2/3.0 unicast-mode clock-source 2.2.2.2
hybrid
Hybrid Mode with a User-Defined Mapping of the PTP Clock Class to the ESMC
Quality Level
CLI Quick To quickly configure hybrid mode on the interface ge-1/2/3.0, copy the following
Configuration commands, paste them in a text file, remove any line breaks, and then copy and paste
the commands into the CLI.
[edit]

set protocols ptp slave interface unicast-mode ge-1/2/3.0 clock-source 2.2.2.2
set protocols ptp slave clock-class-to-quality-level-mapping quality-level prc clock-class
80
Step-by-Step To configure hybrid mode with a user-defined mapping of the PTP clock class to the
Procedure ESMC quality level on an ACX Series router, perform the following steps:
1. Configure the quality-level option for the clock-class-to-quality-level-mapping

statement on the slave at the [edit protocols ptp slave] hierarchy level and then
configure the clock-class option for the set quality level if you want to manually
override the mapping of the ESMC quality level to the clock class.

user@host# set clock-class-to-quality-level-mapping quality-level prc clock-class
80
2. Configure hybrid mode on the slave.


3. Configure the IP address of the master clock as 2.2.2.2 , and the interface ge-1/2/3.0
for hybrid mode on the slave.

user@host# set interface ge-1/2/3.0 unicast-mode clock-source 2.2.2.2
Results Display the results of the configuration of hybrid mode with a user-defined mapping of
the PTP clock class to the ESMC quality level:

user@host# show
clock-class-to-quality-level-mapping {
quality-level prc {
clock-class 80;
}
}
interface ge-1/2/3.0 unicast-mode clock-source 2.2.2.2
hybrid
Verification
• Verifying That the Router Is Operating in Hybrid Mode on page 298
• Verifying the Quality Level Change on the Transmit Side on page 299
• Verifying Global Information Parameters After Mapping of the PTP Clock Class to the
ESMC Quality Level in Hybrid Mode on page 299
• Verifying Global Information Parameters After Configuring User-Defined Mapping of
the PTP Clock Class to the ESMC Quality Level in Hybrid Mode on page 300
Verifying That the Router Is Operating in Hybrid Mode
Purpose Verify the current mode of operation of the slave.
Action In operational mode, enter the run show ptp hybrid command to display the current
configuration and current mode of operation of the slave.
In operational mode, enter the run show ptp hybrid config command to display the PTP
source to Synchronous Ethernet interface mappings.
In operational mode, enter the run show ptp hybrid status command to display the current
hybrid mode operational status.
Meaning The output displays the current configuration and current mode of operation of the slave.
For information about the run show ptp hybrid operational command, see show ptp
hybrid.

Verifying the Quality Level Change on the Transmit Side
Purpose Verify the quality level change on the transmit side of the router.
Action In operational mode, enter the run show synchronous-ethernet esmc transmit detail
command to display the ESMC transmit interface details.
Meaning The output displays the ESMC SSM quality level transmitted out of various Ethernet
interfaces. For information about the run show synchronous-ethernet esmc transmit detail
operational command, see show synchronous-ethernet esmc transmit.
Verifying Global Information Parameters After Mapping of the PTP Clock Class
to the ESMC Quality Level in Hybrid Mode
Purpose Verify the global information parameters after mapping of the PTP clock class to the
ESMC quality level in hybrid mode by enabling the convert-clock-class-to-quality-level
option.
Action In operational mode, enter the run show ptp global-information command to display the
following output:
user@host> run show ptp global-information

PTP Global Configuration:
Domain number : 0
Transport Encapsulation : IPv4
Clock mode : Ordinary
Priority Level1 : 128
Unicast Negotiation : Disabled
ESMC QL From Clock Class: Enabled
Clock Class/ESMC QL : 84 / (QL SSU-A/SSM 0x4)
Slave Parameters:
Sync Interval : -
Delay Request Interval: -6 (64 packets per second)
Announce Interval : -
Announce Timeout : 3
Master Parameters:
Sync Interval : -6 (64 packets per second)
Delay Request Interval: -
Announce Interval : 1 (1 packet every 2 seconds)
Clock Step : one-step
Number of Slaves : 1
Number of Masters : 0
In operational mode, enter the run show ptp quality-level-mapping command to display
the following output:
user@host> run show ptp quality-level-mapping

quality level ptp clock class
PRC 84
SSU-A 92

SSU-B 96
SEC 104
Meaning The output for run show ptp global-information displays the parameters set in Synchronous
Ethernet mode and the parameters set for the master and the slave.
The output of run show ptp quality-level-mapping displays the default mapping of the
clock class to the ESMC quality level.
Verifying Global Information Parameters After Configuring User-Defined Mapping

of the PTP Clock Class to the ESMC Quality Level in Hybrid Mode
Purpose Verify the global information parameters after configuring a user-defined mapping of
the PTP clock class to the ESMC quality level in hybrid mode by disabling the
convert-clock-class-to-quality-level option.
Action In operational mode, enter the run show ptp global-information command to display the
following output:
user@host> run show ptp global-information

PTP Global Configuration:
Domain number : 0
Transport Encapsulation : IPv4
Clock mode : Ordinary
Unicast Negotiation : Disabled
ESMC QL From Clock Class: Disabled
Clock Class/ESMC QL : -
Slave Parameters:
Sync Interval : -
Delay Request Interval: -6 (64 packets per second)
Announce Interval : -
Announce Timeout : 3
Master Parameters:
Sync Interval : -6 (64 packets per second)
Delay Request Interval: -
Announce Interval : 1 (1 packet every 2 seconds)
Clock Step : one-step
Meaning The output displays the parameters set in Synchronous Ethernet mode and the
parameters set for the master and the slave.
Documentation
page 292

Understanding Timing Defects and Event Management on ACX Series
Junos OS for ACX Universal Access Routers supports defect and event management
capabilities for timing features. Defects and events are notified in the form of SNMP traps
and these SNMP traps are logged into the system log-file (var/log/snmpd). For each of
the SNMP traps (timing defects and timing events) that are generated, a message is
logged in the clksyncd file (var/log/clksyncd).
Table 34 on page 301 shows the list of SNMP trap notifications for timing defects and
events supported in ACX Universal Access Routers.
Table 34: SNMP trap notifications for timing defects and events
Notification
SNMP Trap Type Description
jnxTimingFaultLOS Defects Denotes loss of signal
jnxTimingFaultEFD Defects Denotes exceeded frequency deviation
jnxTimingFaultLOESMC Defects Denotes loss of Ethernet Synchronization Message Channel

(ESMC)
jnxTimingFaultQLFailed Defects Denotes failure in quality level
jnxTimingFaultLTI Defects Denotes loss of timing information
jnxTimingFaultPriSrcFailed Defects Denotes the failure of primary source
jnxTimingFaultSecSrcFailed Defects Denotes the failure of secondary source
jnxTimingFaultPtpUniNegRateReject Defects When acting as master, this SNMP trap denotes failure or
rejects clients for signaling messages. When acting as a slave,
this SNMP trap denotes failure or client stops receiving
signaling messages
jnxTimingEventPriSrcRecovered Events Denotes the recovery of primary source
jnxTimingEventSecSrcRecovered Events Denotes the recovery of secondary source
jnxTimingEventPriRefChanged Events Denotes a change in primary reference such as a change in

logical interface or a change from SyncE to BITS/external
interface)
jnxTimingEventSecRefChanged Events Denotes a change in secondary reference such as a change

in logical interface
jnxTimingEventQLChanged Events Denotes a change in quality level
jnxTimingEventDpllStatus Events Denotes the DPLL status (SyncE, BITS, Hybrid)

Table 34: SNMP trap notifications for timing defects and events (continued)
Notification
SNMP Trap Type Description
jnxTimingEventPtpServoStatus Events Denotes the following PTP Servo states:
• INITIALIZING
• ACQUIRING (Master is elected and servo starts acquiring
lock)
• PHASE ALIGNED (Locked to Master)
• FREERUN (no PTP source available)
• HOLDOVER (Slave locked to PTP for more than 12 hours
and then loses all the PTP sources)
jnxTimingEventPtpClockClassChange Events Denotes a change in PTP clock class
jnxTimingEventPtpClockAccuracyChange Events Denotes a change in PTP accuracy
jnxTimingEventPtpGMChange Events Denotes a change in PTP grandmaster clock
jnxTimingEventHybridStatus Events Denotes the following hybrid states:
• INITIALIZING
• ACQUIRING (Master is elected and servo starts acquiring
lock)
• FREQUENCY LOCKED (Frequency locked but acquiring
phase)
• PHASE ALIGNED (Frequency and phase locked)
To configure and generate timing defects and events trap notifications, include the
timing-events statement at the [edit snmp trap-group trap-group-name categories]
hierarchy level as shown below:
[edit]
snmp {
trap-group <group-name> {
categories {
timing-events;
}
}
}
The following is a sample configuration for SNMP timing in ACX Series routers:
snmp {
trap-options {
source-address 10.216.66.139;
}
trap-group timingGroup {
version v2;
destination-port 8999;
categories {
timing-events;
}

targets {
192.168.120.129;
}
}
traceoptions {
flag all;
}
}
Related • show chassis synchronization on page 2386

Documentation
• source on page 1721
• Understanding SNMP MIB for Timing on ACX Series on page 303
Understanding SNMP MIB for Timing on ACX Series
Junos OS for ACX Universal Access Routers supports SNMP get, get-next, and walk
management capabilities for timing features. These capabilities are enabled through the
PTP MIB, SyncE MIB and GPS MIB timing objects.
NOTE: The PTP MIB and SyncE MIB timing objects are grouped under the
jnxTimingNotfObjects SNMP MIB object.
Table 35 on page 304 shows the list of SNMP MIB objects supported for SNMP get, get-next,
and walk management on ACX Universal Access Routers.

Table 35: SNMP MIB Objects for get, get-next, and walk management
SNMP
MIB Object Description
PTP MIB jnxPtpServoState Denotes the following PTP Servo states:
• INITIALIZING
• ACQUIRING
• PHASE ALIGNED
• FREERUN
• HOLDOVER
• FREQUENCY LOCKED
jnxPtpServoStateStr Denotes the PTP Servo state string:
• INITIALIZING
• ACQUIRING (Master is elected and servo starts acquiring lock)
• PHASE ALIGNED (Locked to Master)
• FREERUN (no PTP source available)
• HOLDOVER (Slave locked to PTP for more than 12 hours and then loses
all the PTP sources)
jnxPtpClass Denotes the class of the PTP grandmaster clock.
jnxPtpGmId Denotes the PTP grandmaster clock identifier.
SyncE MIB jnxClksyncQualityCode Denotes the SSM/ESMC quality level of the locked source in decimal format.
jnxClksyncQualityCodeStr Denotes the SSM/ESMC quality level of the locked source in string format
jnxClksyncIfIndex Denotes the interface index of the locked source in decimal format.
jnxClksyncIntfName Denotes the interface name of the locked source in string format.
GPS MIB jnxGpsRecvStatus Displays the status of the GPS receiver.
NOTE:
• The SNMP get and walk management are supported only for scalar objects.
• For SyncE objects, the jnxClksyncQualityCode, jnxClksyncQualityCodeStr,

jnxClksyncIfIndex, and jnxClksyncIntfName objects displays only for locked
source.
You can use the show chassis synchronization extensive, show ptp lock-status detail, show
snmp mib get <MIB-timing-objects>, and show snmp mib walk jnxTimingNotfObjects show
commands for monitoring and troubleshooting purposes.
The following are the sample show command outputs for reference:

show chassis synchronization extensive

user@host> show chassis synchronization extensive
Current clock status : Locked

Clock locked to : Primary
SNMP trap status : Enabled
Configured sources:
Interface : ge-0/0/7
Status : Secondary Index : 136
Clock source state : Clk qualified Priority : Default(8)
Configured QL : SEC ESMC QL : PRC
Clock source type : ifd Clock Event : Clock qualified
Interface State : Up,sec,ESMC Rx(SSM 0x2),ESMC TX(QL SEC/SSM 0xb),
Interface : ge-0/1/1
Status : Primary Index : 138
Clock source state : Clk qualified Priority : Default(8)
Configured QL : PRC ESMC QL : PRC
Clock source type : ifd Clock Event : Clock locked
Interface State : Up,pri,ESMC Rx(SSM 0x2),ESMC TX(QL DNU/SSM 0xf)
show chassis synchronization extensive

user@host> show chassis synchronization extensive
Configured ports:
Name : auxiliary
Rx status : active
Rx message : TL000001433759011353
Current ToD : Mon Jun 8 10:23:31 2015
Last ToD update : Mon Jun 8 10:23:30 2015
GPS receiver status : Lost Sync
UTC Pending : FALSE
UTC Offset : 35
One PPS status : Active
Configured sources:
Interface : gps
Status : Primary Index : 1
Clock source state : Clk failed Priority : Default(6)
Configured QL : PRC ESMC QL : DNU
Clock source type : extern Clock Event : Clock failed
Interface State : Up,pri
show ptp lock-status detail

user@host> show ptp lock-status detail
Lock Status:
Lock State : 1 (FREERUN)

Phase offset : 0.000000000 sec

State since : 2015-05-04 03:13:49 PDT (00:01:45 ago)
Selected Master Details:

Upstream Master address : 61.1.1.2
Slave interface : ge-0/1/1.0
Parent Id : 40:b4:f0:ff:fe:42:f5:00
GMC Id : 40:b4:f0:ff:fe:42:d5:00
show snmp mib get <MIB-timing-objects>

user@host> show snmp mib get jnxGpsRecvStatus.0
jnxGpsRecvStatus.0 = Lost Sync
show snmp mib walk jnxTimingNotfObjects

user@host> show snmp mib walk jnxTimingNotfObjects
jnxClksyncIfIndex.0 = 138
jnxClksyncIntfName.0 = ge-0/1/1
jnxClksyncQualityCode.0 = 2
jnxPtpServoState.0 = 1
jnxPtpClass.0 = 6
jnxPtpGmId.0 = 40:b4:f0:ff:fe:42:d5:00
jnxClksyncQualityCodeStr.0 = PRC
jnxPtpServoStateStr.0 = FREERUN

Documentation
• Understanding Timing Defects and Event Management on ACX Series on page 301
Global Positioning System (GPS) and the ACX Series Routers
Global Positioning System (GPS) is a navigation aid system that uses signals from
satellites to calculate the actual position of a GPS-capable receiver. These signals are
not only used for determining the position of the receiver on Earth but also as a very
accurate time base. There are GPS receivers with 10-MHz clock frequency output
synchronized to a GPS satellite. The ACX Series router has a SubMiniature version B
(SMB) connector that can take 10-MHz sine-wave input from a GPS receiver. To configure
this 10-MHz clock from a GPS receiver as a candidate clock source for chassis
synchronization, include the gps statement and options at the [edit chassis synchronization
source] hierarchy level.
NOTE: ACX500 routers do not require an external GPS receiver because the
GPS receiver is integrated into the system.
Documentation

Integrated Global Navigation Satellite System (GNSS) on ACX500 Series Routers
Global Navigation Satellite System (GNSS) is a navigation aid system that uses signals
from satellites to calculate the actual position of a GPS-capable receiver. These signals
are not only used for determining the position of the receiver on Earth but also as a very
accurate time base.
The ACX500 series router has the GNSS receiver integrated into the system. This
eliminates the need to have an external GPS receiver. However, you will need a GPS
antenna. The ACX500 series routers support GNSS input through SubMiniature version
A (SMA) connector. You can configure the GNSS port and its associated parameters at
the [edit chassis synchronization] hierarchy level.
You can configure the GNSS port by including the constellation gps] CLI statement at
the [edit chassis synchronization port gnss] hierarchy level. If you do not specify a
constellation option, then the gps constellation option is considered by default.
The following is the [edit chassis synchronization port gnss] hierarchy level:
[edit chassis synchronization]

port gnss client {
cable-length-compensation {
time delay-in-nanoseconds;
}
constellation [gps];
anti-jamming;
}
NOTE:
• The range for cable-length-compensation is from 0 to 50000000
nanoseconds.
• The integrated GNSS receiver in the ACX500 series routers do not support
10-MHz frequency input and output.
ACX500 series routers support grandmaster clock functionality with the integrated GNSS
receiver.
Use the show chassis synchronization gnss command to check the status of the GNSS
receiver. For more information, see show chassis synchronization.

Documentation

Assisted Partial Timing Support on ACX500 Routers Overview
The assisted partial timing support (APTS), which is a Global Navigation Satellite System
(GNSS) backed by Precision Time Protocol (PTP), delivers accurate timing and
synchronization in mobile backhaul networks.
NOTE: The APTS feature is supported only on the Junos OS Release

12.3X54–D25 for ACX500 router.
On the ACX500 router, the APTS feature helps you to configure PTP slave ports on a
GNSS grandmaster serving as the PTP master.
APTS uses GNSS as the primary time reference at cell site locations, or at an aggregation
point close to the cell sites. APTS uses network-based timing distribution to assist and
maintain the timing during holdover periods when GNSS is unavailable.
To support this feature, you need an APTS node with GNSS source configured at the
[edit chassis synchronization] hierarchy level and PTP boundary clock configured at the
[edit protocols ptp] hierarchy level as shown below:
GNSS configuration [edit chassis]

synchronization {
network-option <option-1 | option-2>;
port gnss {
client {
constellation <constellation-type>;
anti-jamming;
}
}
esmc-transmit {
interface <interfaces-name>;
}
}
PTPoE Configuration [edit protocols]

ptp {
slave {
interface <slave-ptp-ifl> {
multicast-mode {
transport ieee-802.3 [ link-local ] ;
}
}
}
master {
interface <master-ptp-ifl> {
multicast-mode {
transport ieee-802.3 [ link-local ] ;
}
}
}

PTPoIP Configuration [edit protocols]

slave {
interface <logical-interface-name> {
unicast-mode {
transport ipv4;
clock-source <remote-master-ip-address> local-ip-address
<local-slave-ip-address>;
}
}
}
master {
interface <logical-interface-name>{
unicast-mode {
transport ipv4;
clock-client <remote-slave-ip> local-ip-address
<local-master-ip>;
}
}
}
}
The priority of clock source would be GNSS first and then PTP.
You can use the show ptp lock-status detail, show chassis synchronization extensive, and
show chassis synchronization gnss extensive show commands to monitor and troubleshoot
the configurations.

Documentation


PART 4
Configuring DHCP on ACX Series Routers

• Configuring DHCP Client and DHCP Server on page 313
• Configuring DHCP and DHCPv6 Relay Agent on page 367


CHAPTER 10
Configuring DHCP Client and DHCP Server
• Extended DHCP Local Server Overview on page 315

• Address-Assignment Pools Overview on page 317
• Configuring Address-Assignment Pools on page 318
• Configuring an Address-Assignment Pool Name and Addresses on page 319
• Configuring a Named Address Range for Dynamic Address Assignment on page 320
• Configuring Static Address Assignment on page 320
• DHCP Attributes for Address-Assignment Pools on page 321
• Configuring How the Extended DHCP Local Server Determines Which
Address-Assignment Pool to Use on page 322
• Use of DHCP Option 50 to Request a Specific IP Address on page 324
• Configuring DHCP Client-Specific Attributes on page 325
• Grouping Interfaces with Common DHCP Configurations on page 326
• Guidelines for Configuring Interface Ranges on page 327
• Group-Specific DHCP Local Server Options on page 328
• Overriding Default DHCP Local Server Configuration Settings on page 329
• Deleting DHCP Local Server Settings on page 330
• Specifying the Maximum Number of DHCP Clients Per Interface on page 331
• Disabling ARP Table Population on page 332
• DHCP Auto Logout Overview on page 333
• Automatically Logging Out DHCP Clients on page 335
• DHCP Local Server Handling of Client Information Request Messages on page 335
• Enabling Processing of Client Information Requests on page 336
• Subscriber Binding Retention During Interface Delete Events on page 337
• Configuring the Router to Maintain DHCP Subscribers During Interface Delete
Events on page 338
• Verifying and Managing the DHCP Maintain Subscribers Feature on page 339
• Preserving Subscriber Binding Information on page 339
• Configuring DHCP Local Server to Preserve Subscriber Binding Information on page 340

• Understanding Dynamic Reconfiguration of Extended DHCP Local Server

Clients on page 341
• Configuring Dynamic Reconfiguration of DHCP Clients to Avoid Extended Outages Due
to Server Configuration Changes on page 344
• Configuring Dynamic Reconfiguration Attempts for DHCP Clients on page 345
• Configuring Deletion of the Client When Dynamic Reconfiguration Fails on page 346
• Requesting DHCP Local Server to Initiate Reconfiguration of Client Bindings on page 347
• Clearing DHCP Bindings for Subscriber Access on page 348
• Verifying and Managing DHCP Local Server Configuration on page 349
• Enabling MAC Address Filtering on page 350
• Tracing General Authentication Service Processes on page 351
• Tracing Extended DHCP Operations on page 353
• Understanding DHCP Client Operation on page 359
• Configuring a DHCP Client on page 360
• DHCP Duplicate Client Differentiation Using Client Subinterface Overview on page 362
• Guidelines for Configuring Support for DHCP Duplicate Clients on page 363
• Configuring DHCP Duplicate Client Support on page 364

Chapter 10: Configuring DHCP Client and DHCP Server
Extended DHCP Local Server Overview
You can enable a router to function as an extended Dynamic Host Configuration Protocol
(DHCP) local server and configure the extended DHCP local server options on the router.
The extended DHCP local server provides an IP address and other configuration
information in response to a client request.
The extended DHCP local server enhances traditional DHCP server operation by utilizing
centralized address-assignment pools. The address-assignment pools are managed
independently of the DHCP local server and can be shared by different client applications.
NOTE: You cannot configure the extended DHCP local server, DHCP client
and extended DHCP relay on the same interface.
To configure the extended DHCP local server on the router, you include the
dhcp-local-server statement at the [edit system services] hierarchy level.
To configure the extended DHCP local server in a routing instance, include the
dhcp-local-server statement at the [edit routing-instances routing-instance-name system
services] hierarchy level.
To configure the extended DHCPv6 server on the router, you include the dhcpv6 statement
at the [edit system services dhcp-local-server] hierarchy level.
To configure the extended DHCPv6 server in a routing instance, include the dhcpv6
statement at the [edit routing-instances routing-instance-name system services
dhcp-local-server] hierarchy level.
This overview covers:
• Interaction Among the DHCP Client, Extended DHCP Local Server, and
Address-Assignment Pools on page 315
• Minimal Configuration for Clients on page 316
• DHCP Local Server and Address-Assignment Pools on page 316
Interaction Among the DHCP Client, Extended DHCP Local Server, and Address-Assignment
Pools
In a typical carrier edge network configuration, the DHCP client is on the subscriber’s
computer, and the DHCP local server is configured on the router. The following steps
provide a high-level description of the interaction among the extended DHCP local server,
DHCP client, and address-assignment pools:
1. The DHCP client sends a discover packet to one or more DHCP local servers in the
network to obtain configuration parameters and an IP address for the subscriber.
2. Each DHCP local server that receives the discover packet then searches its
address-assignment pool for the client address and configuration options. Each local

server creates an entry in its internal client table to keep track of the client state, then
sends a DHCP offer packet to the client.
3. On receipt of the offer packet, the DHCP client selects the DHCP local server from
which to obtain configuration information and sends a request packet indicating the
DHCP local server selected to grant the address and configuration information.
4. The selected DHCP local server sends an acknowledgment packet to the client that
contains the client address lease and configuration parameters. The server also installs
the host route and Address Resolution Protocol (ARP) entry, and then monitors the
lease state.
Minimal Configuration for Clients

The extended DHCP local server provides a minimal configuration to the DHCP client if
the client does not have DHCP option 55 configured. The server provides the subnet mask
of the address-assignment pool that is selected for the client. In addition to the subnet
mask, the server provides the following values to the client if the information is configured
in the selected address-assignment pool:
• router—A router located on the client’s subnet. This statement is the equivalent of
DHCP option 3.
• domain name—The name of the domain in which the client searches for a DHCP server
host. This is the default domain name that is appended to hostnames that are not fully
qualified. This is equivalent to DHCP option 15.
• domain name server—A Domain Name System (DNS) name server that is available to
the client to resolve hostname-to-client mappings. This is equivalent to DHCP option
6.
DHCP Local Server and Address-Assignment Pools

In the traditional DHCP server operation, the client address pool and client configuration
information reside on the DHCP server. With the extended DHCP local server, the client
address and configuration information reside in centralized address-assignment pools,
which are managed independently of the DHCP local server and which can be shared by
different client applications.
The extended DHCP local server also supports advanced pool matching and the use of
named address ranges. You can also configure the local server to use DHCP option 82
information in the client PDU to determine which named address range to use for a
particular client. The client configuration information, which is configured in the
address-assignment pool, includes user-defined options, such as boot server, grace
period, and lease time.
Configuring the DHCP environment that includes the extended DHCP local server requires
two independent configuration operations, which you can complete in any order. In one
operation, you configure the extended DHCP local server on the router and specify how
the extended DHCP local server determines which address-assignment pool to use. In

the other operation, you configure the address-assignment pools used by the extended
DHCP local server. The address-assignment pools contain the IP addresses, named
address ranges, and configuration information for DHCP clients. See Configuring
Address-Assignment Pools for details about creating and using address-assignment
pools.
NOTE: The extended DHCP local server and the address-assignment pools
used by the server must be configured in the same routing instance.
NOTE: You can apply DHCP configurations on Integrated Routing and Bridging
(IRB) interfaces.
Related • DHCP Local Server Handling of Client Information Request Messages on page 335
Documentation

Address-Assignment Pools Overview
The address-assignment pool feature supports subscriber management functionality

by enabling you to create IPv4 address pools that different client applications can share.
For example, multiple client applications, such as Dynamic Host Configuration Protocol
(DHCP), can use an address-assignment pool to provide addresses for their particular
clients.
Address-assignment pools support both dynamic and static address assignment. In

dynamic address assignment, a client is automatically assigned an address from the
address-assignment pool. In static address assignment, which is supported for IPv4 pools
only, you reserve an address that is then always used by a particular client. Addresses
that are reserved for static assignment are removed from the dynamic address pool and
cannot be assigned to other clients.
You can configure named address ranges within an address-assignment pool. A named
range is a subset of the overall address range. A client application can use named ranges
to manage address assignment based on client-specific criteria. For example, for IPv4
address-assignment pools, you might create a named range that is based on a specific
DHCP option 82 value. Then, when a DHCP client request matches the specified option
82 value, an address from the specified range is assigned to the client.

You can link address-assignment pools together to provide backup pools for address
assignment. When the primary pool is fully allocated, the router or switch automatically
switches to the linked, or secondary, pool and begins allocating addresses from that
pool.
Related • Extended DHCP Local Server Overview on page 315

Documentation

Configuring Address-Assignment Pools
The address-assignment pool feature supports subscriber management functionality

by enabling you to create address pools that can be shared by different client applications.
An address-assignment pool in ACX Series routers supports both IPv4 and IPv6 addresses.
To configure an address-assignment pool:
1. Configure the address-assignment pool name and specify the addresses for the pool.
See “Configuring an Address-Assignment Pool Name and Addresses” on page 319.
2. (Optional) Configure named ranges (subsets) of addresses.
See “Configuring a Named Address Range for Dynamic Address Assignment” on

page 320.
3. (Optional) Create static address bindings.
See “Configuring Static Address Assignment” on page 320.
4. (Optional) Configure attributes for DHCP clients.
See “Configuring DHCP Client-Specific Attributes” on page 325.

Related • Address-Assignment Pools Overview on page 317

Documentation

Configuring an Address-Assignment Pool Name and Addresses
To configure an address-assignment pool, you must specify the name of the pool and
configure the addresses for the pool.
To configure an IPv4 address-assignment pool:
1. Configure the name of the pool and specify the IPv4 family.
[edit access]
user@host# edit address-assignment pool pool-name family inet
2. Configure the network address and the prefix length of the addresses in the pool.
[edit access address-assignment pool pool-name family inet]

user@host# set network address
To configure an IPv6 address-assignment pool:
1. Configure the name of the pool and specify the IPv6 family.
[edit access]
user@host# edit address-assignment pool pool-name family inet6
2. Configure the network address and the prefix length of the addresses in the pool.
[edit access address-assignment pool pool-name family inet6]

user@host# set network address

Documentation


Configuring a Named Address Range for Dynamic Address Assignment
You can optionally configure multiple named ranges, or subsets, of addresses within an
address-assignment pool. During dynamic address assignment, a client can be assigned
an address from a specific named range. To create a named range, you specify a name
for the range and define the address range.
To create a named range within an IPv4 address-assignment pool:
1. Specify the name of the address-assignment pool and the IPv4 family.
[edit access]
user@host# edit address-assignment pool isp_1 family inet
2. Configure the name of the range and the lower and upper boundaries of the addresses
in the range.
[edit access address-assignment pool isp_1 family inet]

user@host# set range southeast low address high address
To create a named range within an IPv6 address-assignment pool:
1. Specify the name of the address-assignment pool and the IPv6 family.
[edit access]
user@host# edit address-assignment pool isp_1 family inet6
2. Configure the name of the range and the lower and upper boundaries of the addresses
in the range.
[edit access address-assignment pool isp_1 family inet6]

user@host# set range southeast low address high address

Documentation

Configuring Static Address Assignment
You can optionally create a static IPv4 address binding by reserving a specific address
for a particular client. The address is removed from the address-assignment pool so that
it is not assigned to another client. When you reserve an address, you identify the client
host and create a binding between the client MAC address and the assigned IP address.

To configure a static binding for an IPv4 address:
1. Specify the name of the IPv4 address-assignment pool containing the IP address you
want to reserve for the client.
[edit access]
user@host# edit address-assignment pool pool-name family inet
2. Specify the name of the client for the static binding, the client MAC address, and the
IP address to reserve for the client.
This configuration specifies that the client with MAC address 90:00:00:01:00:01 is
always assigned IP address 192.168.44.12.

user@host# set host svale6_boston_net hardware-address 90:00:00:01:00:01
ip-address 192.168.44.12

Documentation

DHCP Attributes for Address-Assignment Pools
Table 36 on page 321 describes the DHCP client attributes that you can use with the
dhcp-attributes statement when you configure address-assignment pools.
Table 36: DHCP Attributes

DHCP
Attribute Description Option
boot-file Boot filename advertised to the client, and used by the 67

client to complete configuration.
boot-server Boot server containing the boot file. 66
domain-name Domain in which clients search for a DHCP server host. 15
grace-period Grace period offered with the lease. –
maximum-lease-time Maximum lease time allowed by the DHCP server. 51
name-server IP address of DNS server to which clients can send DNS 6

queries.

Table 36: DHCP Attributes (continued)

DHCP
Attribute Description Option
netbios-node-type NetBIOS node type. 46
option User-defined options. –
option-match Maps option 82 value to named address range. –
router IP address for routers on the subnetwork. 3
server-identifier IP address used as the DHCP source address 54
tftp-server Trivial File Transfer Protocol (TFTP) server that the client 150
uses to obtain the client configuration file.
wins-server IP address of the Windows NetBIOS name server. 44
propagate-settings Specifies the interface (acting as DHCP client) from which

the DHCP options can be propagated from and used by
the DHCP local server. This should match the logical
interface name.

Documentation

Configuring How the Extended DHCP Local Server Determines Which

Address-Assignment Pool to Use
You can specify the match order in which the extended DHCP local server uses the client
data to determine the address-assignment pool that provides the IP address and
configuration for a DHCP client. You use the pool-match-order statement to specify the
match order. If you do not specify the pool-match-order, the router uses the default
ip-address-first matching to select the address pool. After the DHCP local server
determines the address assignment pool to use, the server performs the matching based
on the criteria you specified in the pool configuration.

In the default ip-address-first matching, the server selects the address-assignment pool
to use by matching the IP address in the client DHCP request with the network address
of the address-assignment pool. If the client request contains the gateway IP address
(giaddr), the local server matches the giaddr to the address-assignment pool’s address.
If there is no giaddr in the request, then the DHCP local server matches the IP address of
the receiving interface to the address of the address-assignment pool.
For IPv4 address-assignment pools, you can optionally configure the extended DHCP
local server to match the DHCP relay agent information option (option 82) in the client
DHCP packets to a named range in the address-assignment pool used for the client.
Named ranges are subsets within the overall address-assignment pool address range,
which you can configure when you create the address-assignment pool.
NOTE: To use the DHCP local server option 82 matching feature with an IPv4
address-assignment pool, you must ensure that the option-82 statement is
included in the dhcp-attributes statement for the address-assignment pool.
You can optionally include the option-82-strict method in the pool-match-order statement
for matching the address-assignment pool. If you include the option-82-strict method,
the extended DHCP local server applies the ip-address-first matching method first and
then uses the option-82 method to select the address-assignment pool. The
ip-address-first method must be specified before the option-82-strict method in the
pool-match-order list.
NOTE: If the option-82-strict method is configured in the pool-match-order

list, any DHCP discover packet with either unknown or no option-82
information will be denied with an IP address. A DHCP client is allocated with
an IP address only when the DHCP packet matches the option-82 information
configured as a part of the dhcp-attributes statement. If dhcp-attributes to
match for specific option-82 value is not configured as a part of the selected
pool configuration, the option-82-strict match order option will have no effect
and IP addresses are allocated by the DHCP local server by matching the
subnet of the incoming interface.
To configure the matching order the extended DHCP local server uses to determine the
address-assignment pool used for a client:
1. Access the pool-match-order configuration.
[edit system services dhcp-local-server]

user@host# edit pool-match-order

2. Specify the pool matching methods in the order in which the router performs the
methods. You can specify the methods in any order. All methods are optional—the
router uses the ip-address-first method by default.
• Configure the router to use the ip-address-first method.
[edit system services dhcp-local-server pool-match-order]

user@host# set ip-address-first
• (IPv4 address-assignment pools only) Specify the option-82 matching method.

user@host# set option-82
• (IPv4 address-assignment pools only) Specify the option-82-strict matching

method.

user@host# set option-82-strict

Documentation
Use of DHCP Option 50 to Request a Specific IP Address
Subscriber management enables you to specify that DHCP local server assign a particular
address to a client. For example, if a client is disconnected, you might use this capability
to assign the same address that the client was using prior to being disconnected. If the
requested address is available, DHCP assigns it to the client. If the address is unavailable,
the DHCP local server offers another address, based on the address allocation process.
DHCP local server supports the specific address request feature. DHCP local server uses
DHCP option 50 in DHCP DISCOVER messages to request a particular address.

Documentation

• Configuring the Router to Maintain DHCP Subscribers During Interface Delete Events
on page 338
• Understanding Dynamic Reconfiguration of Extended DHCP Local Server Clients on

page 341

Configuring DHCP Client-Specific Attributes
You use the address-assignment pool feature to include application-specific attributes

when clients obtain an address. The client application, such as DHCP, uses the attributes
to determine how addresses are assigned, and to also provide optional application-specific
characteristics to the client. For example, the DHCP application might specify that a
client that matches certain prerequisite information is dynamically assigned an address
from a particular named range. Based on which named range is used, DHCP specifies
additional DHCP attributes such as the boot file that the client uses, the lease grace
period, and the maximum lease time.
You use the dhcp-attributes statement to configure DHCP client-specific attributes for
address-assignment pools. DHCP Attributes for Address-Assignment Pools describes the
supported attributes you can configure for IPv4 address-assignment pools.
To configure address-assignment pool attributes for DHCP clients:
1. Specify the name and IP family of the address-assignment pool.
[edit access]
user@host# edit address-assignment pool isp_1 family inet
2. Configure optional DHCP client attributes. For example,

user@host# set dhcp-attributes boot-server 192.168.200.100 grace-period 3600
maximum-lease-time 18000

Documentation


Grouping Interfaces with Common DHCP Configurations
You use the group feature to group together a set of interfaces and then apply a common
DHCP configuration to the named interface group. The extended DHCP local server
supports interface groups.
The following steps create a DHCP local server group.
To configure a DHCP local server interface group:
1. Specify that you want to configure a DHCP local server.
[edit system services]

user@host# edit dhcp-local-server
2. Create the group and assign a name.

user@host# edit group boston
3. Specify the names of one or more interfaces on which the extended DHCP application
is enabled. You can repeat the interface interface-name statement to specify multiple
interfaces within the group, but you cannot use the same interface in more than one
group.
[edit system services dhcp-local-server group boston]

user@host# set interface ge-1/0/1.1
4. (Optional) You can use the upto option to specify a range of interfaces for a group.

user@host# set interface ge-1/0/1.3 upto ge-1/0/1.9
5. (Optional) You can use the exclude option to exclude a specific interface or a specified
range of interfaces from the group. For example:

user@host# set interface ge-1/0/1.1 upto ge-1/0/1.102
user@host# set interface ge-1/0/1.6 exclude
user@host# set interface ge-1/0/1.70 upto ge-1/0/1.80 exclude

Documentation


Guidelines for Configuring Interface Ranges
This topic describes guidelines to consider when configuring interface ranges for named
interface groups for a DHCP local server. The guidelines refer to the following configuration
statement:
user@host# set interface interface-name upto upto-interface-name
• The start subunit, interface interface-name, serves as the key for the stanza. The
remaining configuration settings are considered attributes.
• If the subunit is not included, an implicit .0 subunit is enforced. The implicit subunit is
applied to all interfaces when autoconfiguration is enabled. For example, interface
ge-2/2/2 is treated as interface ge-2/2/2.0.
• Ranged entries contain the upto option, and the configuration applies to all interfaces
within the specified range. The start of a ranged entry must be less than the end of the
range. Discrete entries apply to a single interface, except in the case of
autoconfiguration, in which a 0 (zero) subunit acts as a wildcard.
• Interface stanzas defined within the same router context are dependent and can
constrain each other—both DHCP local server and DHCP relay are considered. Interface
stanzas defined across different router contexts are independent and do not constrain
one another.
• Each interface stanza, whether discrete or ranged, has a unique start subunit across a
given router context. For example, the following configuration is not allowed within
the same group because ge-1/0/0.10 is the start subunit for both.
interface ge-1/0/0.10 upto ge-1/0/0.30

interface ge-1/0/0.10
• Two groups cannot share interface space. For example, the following configuration is
not allowed because the three stanzas share the same space and interfere with one
another—interface ge-1/0/0.26 is common to all three.
dhcp-relay group diamond interface ge-1/0/0.10 upto ge-1/0/0.30

dhcp-local-server group ruby interface ge-1/0/0.26

dhcp-relay group sapphire interface ge-1/0/0.25 upto ge-1/0/0.35
• Two ranges cannot overlap, either within a group or across groups. Overlapping occurs
when two interface ranges share common subunit space but neither range is a proper
subset of the other. The following ranges overlap:

• A range can contain multiple nested ranges. A nested range is a proper subset of
another range. When ranges are nested, the smallest matching range applies.
In the following example, the three ranges nest properly:

interface ge-1/0/0.12 upto ge-1/0/0.15 exclude
• Discrete interfaces take precedence over ranges. In the following example, interface
ge-1/0/0.20 takes precedence and enforces an interface client limit of 5.

interface ge-1/0/0.20 overrides interface-client-limit 5

Documentation
Group-Specific DHCP Local Server Options
You can include the interface and overrides statements at the [edit system services
dhcp-local-server group group-name] hierarchy level to set group-specific DHCP local
server configuration options, and at the [edit system services dhcp-local-server] hierarchy
level to set global DHCP local server configuration options. Statements configured at
the [edit system services dhcp-local-server group group-name] hierarchy level apply only
to the named group of interfaces, and override any global DHCP local server settings
configured with the same statements at the [edit system services dhcp-local-server]
hierarchy level.
In a routing instance, include the interface and overrides statement at the [edit
routing-instances <routing-instance-name> system services dhcp-local-server group
group-name] hierarchy level.
• interface—Specify one or more interfaces, or a range of interfaces, that are within the
specified group.
• overrides—Override the default configuration settings for the extended DHCP local
server. For information, see Overriding Default DHCP Local Server Configuration Settings.


Documentation
Overriding Default DHCP Local Server Configuration Settings
Subscriber management enables you to override certain default DHCP local server
configuration settings. You can override settings at the global level or in a routing instance
level, for a named group of interfaces, or for a specific interface within a named group.
• To override global default DHCP local server configuration options, include the overrides
statement and its subordinate statements at the [edit system services dhcp-local-server]
hierarchy level. In a routing instance, include the overrides statement and its subordinate
statements at the [edit routing-instances routing-instance-name system services
• To override DHCP local server configuration options for a named group of interfaces,
include the statements at the [edit system services dhcp-local-server group group-name]
hierarchy level. In a routing instance, include the statements at the [edit
routing-instances <routing-instance-name> system services dhcp-local-server group
• To override DHCP local server configuration options for a specific interface within a
named group of interfaces, include the statements at the [edit system services
dhcp-local-server group group-name interface] hierarchy level. In a routing instance,
include the statements at the [edit routing-instances routing-instance-name system
services dhcp-local-server group group-name interface] hierarchy level.
To override default DHCP local server configuration settings:
1. Specify that you want to configure override options.
Global override:

user@host# edit overrides
Group level override:

user@host# edit group boston overrides
Per-interface override:

user@host# edit group boston overrides interface ge-1/0/1.1

2. (Optional) Override the maximum number of DHCP clients allowed per interface.
See “Specifying the Maximum Number of DHCP Clients Per Interface” on page 331.
3. (Optional) Configure DHCP client auto logout.
See “Automatically Logging Out DHCP Clients” on page 335.
4. (Optional) Enable processing of information requests from clients.
See “Enabling Processing of Client Information Requests” on page 336.
5. (Optional) Delete DHCP override settings.
See “Deleting DHCP Local Server Settings” on page 330.

Documentation

• Deleting DHCP Local Server Settings on page 330

Deleting DHCP Local Server Settings
You can delete override settings for DHCP local server globally or at a routing instance,
for a named group, or for a specific interface within a named group. You can delete a
specific override setting or all overrides.

To delete a specific DHCP override setting at a particular hierarchy level, include the
overrides statement with the appropriate subordinate statements. For example, to delete
the DHCP local server override no-arp setting for a group named marin20:

user@host# delete group marin20 overrides no-arp
In a routing instance, you can delete a specific DHCP override setting at the [edit
routing-instances routing-instance-name system services dhcp-local-server] hierarchy
level.

Documentation
Specifying the Maximum Number of DHCP Clients Per Interface
By default, there is no limit to the number of DHCP local server clients allowed on an
interface. However, you can override the default setting and specify the maximum number
of clients allowed per interface, in the range 1 through 500,000. When the number of
clients on the interface reaches the specified limit, no additional DHCP Discover PDUs
are accepted. When the number of clients subsequently drops below the limit, new clients
are again accepted.
To configure the maximum number of DHCP clients allowed per interface:
• For DHCP local server:

2. Configure the maximum number of clients allowed per interface.
[edit system services dhcp-local-server overrides]

user@host# set interface-client-limit number
In a routing instance, you can configure the maximum number of DHCP clients allowed
per interface at the [edit routing-instances routing-instance-name system services
dhcp-local-server overrides] hierarchy level.

Documentation

Disabling ARP Table Population
By default, DHCP populates the ARP table with the MAC address of a client when the
client binding is established. However, you might choose to use the DHCP no-arp
statement to hide the subscriber MAC address information, as it appears in ARP table
entries.
When running in a trusted environment (that is, when not using the no-arp statement),
DHCP populates the ARP table with unique MAC addresses contained within the DHCP
PDU for each DHCP client:
Table 37: ARP Table in Trusted Environment

IP Address MAC Address
Client 1 IP Address MAC A
Client 2 IP Address MAC B
Client 3 IP Address MAC C
In distrusted environments, you can specify the no-arp statement to hide the MAC
addresses of clients. When you specify the no-arp statement, DHCP does not
automatically populate the ARP table with MAC address information from the DHCP
PDU for each client. Instead, the system performs an ARP to obtain the MAC address of
each client and obtains the MAC address of the immediately attached device (for example,
a DSLAM). DHCP populates the ARP table with the same interface MAC address (for
example, MAC X from a DSLAM interface) for each client:
Table 38: ARP Table in Distrusted Environment

Client 1 IP Address MAC X

Table 38: ARP Table in Distrusted Environment (continued)

To disable ARP table population:

2. Disable ARP table population with client-specific information.

user@host# set no-arp
In a routing instance, you can disable ARP table population at the [edit routing-instances
<routing-instance-name> system services dhcp-local-server overrides] hierarchy level.

Documentation
DHCP Auto Logout Overview
This topic provides an introduction to the optional Dynamic Host Configuration Protocol
(DHCP) auto logout feature and includes the following sections:
• Auto Logout Overview on page 333

• How DHCP Identifies and Releases Clients on page 334
• Option 60 and Option 82 Requirements on page 334
Auto Logout Overview

Auto logout is an optional configuration for a DHCP local server that improves the
efficiency of DHCP IP address assignment. Auto logout enables IP addresses to be
immediately released and returned to the address pool when the addresses are no longer
used by DHCP clients. DHCP can then assign the addresses to other clients. Without auto
logout, an IP address is blocked for the entire lease period, and DHCP must wait until the
address lease time expires before reusing the address.

Auto logout is particularly useful when DHCP uses long lease times for IP address
assignments and to help avoid allocating duplicate IP addresses for a single client. For
example, you might have an environment that includes set-top boxes (STBs) that are
often upgraded or replaced. Each time an STB is changed, the new STB repeats the DHCP
discover process to obtain client configuration information and an IP address. DHCP
views the new STB as a completely new client and assigns a new IP address—the previous
IP address assigned to the client (the old STB) remains blocked and unavailable until
the lease expires. If auto logout is configured in this situation, DHCP recognizes that the
new STB is actually the same client and then immediately releases the original IP address.
How DHCP Identifies and Releases Clients

The auto logout feature requires that DHCP explicitly identify clients. By default, the
DHCP local server identifies clients based on the MAC address or client identifier. However,
in some cases, this type of identification might not be sufficient. For example, in the
previous STB example, each STB has a different MAC address, so DHCP incorrectly
assumes that an upgraded or replacement STB is a new client.
To explicitly identify clients, auto logout uses a secondary identification method when
the primary identification method is unsuccessful—the primary method is considered
unsuccessful if the MAC address or client identifier does not match that of an existing
client. The secondary identification method is based on the DHCP option 60 and option
82 information in DHCP discover messages.
Both the primary and secondary identification methods use subnet information to
differentiate between clients. The primary identification method differentiates between
two clients with the same MAC address (or the same client identifier) if the clients are
on different subnets. Similarly, the secondary identification method considers two clients
as different if they have the same option 60 and option 82 information, but different
subnets.
The DHCP local server immediately releases the existing address when auto logout is
enabled and the secondary identification method identifies a duplicate client (that is,
the discover packet is from an existing client).
Option 60 and Option 82 Requirements

The DHCP local server requires that the received discover packet include both DHCP
option 60 and option 82. If either option is missing, the DHCP local server cannot perform
the secondary identification method and auto logout is not used.

Documentation

Automatically Logging Out DHCP Clients
You can configure the extended DHCP local server to automatically log out DHCP clients.
Auto logout immediately releases an existing client when DHCP receives a discover
packet that has the same DHCP option 60 and DHCP option 82 information as the existing
client. DHCP then releases the existing client IP address without waiting for the normal
lease expiration.
NOTE: When the existing client is released, the new client undergoes the
normal discovery process. The new client might not receive the same IP
address as the original client.
To configure DHCP client auto logout:

2. Enable auto logout.

user@host# set client-discover-match
In a routing instance, you can configure DHCP client auto logout at the [edit
routing-instances routing-instance-name system services dhcp-local-server overrides]
hierarchy level.
NOTE: If you change the auto logout configuration, existing clients continue
to use the auto logout setting that was configured when they logged in. New
clients use the new setting.

Documentation
DHCP Local Server Handling of Client Information Request Messages
Dynamic Host Configuration Protocol (DHCP) clients that already have externally provided
addresses might solicit further configuration information from a DHCP server by sending
a DHCP information request that indicates what information is desired. By default, DHCP

local servers ignore any DHCP information requests that they receive. You can override
this default behavior to enable processing of these messages. Include the process-inform
statement at the [edit system services dhcp-local-server overrides] hierarchy level.
In a routing instance, include the process-inform statement at the [edit routing-instances

routing-instance-name system services dhcp-local-server overrides] hierarchy level.
The information requested by the clients has typically been configured with the
dhcp-attributes statement for an address pool defined by the address-assignment pool
pool-name statement at the [edit access] hierarchy level.
When you enable processing of DHCP information requests, you can optionally specify
the name of the pool from which the local server retrieves the requested configuration
information for the client.
DHCP local server responds to the client with a DHCP acknowledgment message that
includes the requested information—if it is available. No subscriber management is
applied as a result of the DHCP information request message.

Documentation
Enabling Processing of Client Information Requests
By default, DHCP local server do not respond to information request messages from the
client. You can enable DHCP local server to process these messages and respond to
them with an acknowledgment (ack or reply message, respectively) and the requested
information.
Configure one or more local address pools. See “Configuring an Address-Assignment

Pool Name and Addresses” on page 319. For processing information request messages,
the address configuration is not necessary. For DHCP local server, you must specify the
IPv4 family.
See “Configuring DHCP Client-Specific Attributes” on page 325 for details about how to
configure the information sought by clients that send information request messages.
To enable processing of DHCP client information request messages:

user@host# set process-inform

2. (Optional) Specify a pool name from which DHCP information is returned to the client.
[edit system services dhcp-local-server overrides process-inform]

user@host# set pool pool-name
In a routing instance, you can enable processing of DHCP client information request
messages at the [edit routing-instances routing-instance-name system services
dhcp-local-server overrides] hierarchy level.

Documentation
Subscriber Binding Retention During Interface Delete Events
You can configure the router to maintain DHCP subscribers when an event occurs that
normally results in the router deleting the subscriber. For example, by default, the router
logs out DHCP subscribers when a Packet Forwarding Engine reboot or crash occurs.
However, if you configure the router to maintain subscribers, the router identifies each
subscriber that was on the deleted interface, and resumes normal packet processing for
the subscriber when the interface is restored.
NOTE: Subscribers are logged off as usual when their lease expires, even If
the router is configured to maintain subscribers and the subscriber is on a
deleted interface that has not yet been restored.
You configure the router to maintain subscribers on a global basis— the configuration
applies to DHCP local server in all routing instances. When you enable the maintain
subscribers feature, the router applies the feature to existing subscribers as well as
subscribers who later connect.
If the maintain subscribers feature is enabled on the router, you can explicitly delete a
subscriber binding and log out the subscriber by either specifying a lease expiration
timeout or by using the following command:
clear dhcp server binding

Related • Use of DHCP Option 50 to Request a Specific IP Address on page 324

Documentation
on page 338

page 341

Configuring the Router to Maintain DHCP Subscribers During Interface Delete Events
You can specify a configuration in which the router does not log out a subscriber when
the subscriber’s interface is deleted.
To configure the router to maintain DHCP subscribers when the subscriber interface is
deleted:
1. Specify that you want to configure subscriber management.

user@host# edit subscriber-management
2. Configure the router to support the maintain-subscriber feature.
[edit system services subscriber-management]

user@host# edit maintain-subscriber
3. Configure the router to enable the maintain-subscriber feature when an

interface-delete event occurs.
[edit system services subscriber-management maintain-subscriber]

user@host# set interface-delete
In a routing instance, you can configure subscriber management at the [edit

routing-instances routing-instance-name system services subscriber-management] hierarchy
level.

Related • Subscriber Binding Retention During Interface Delete Events on page 337
Documentation
page 341

Verifying and Managing the DHCP Maintain Subscribers Feature
Purpose Display information related to the DHCP maintain-subscribers feature and explicitly log
out maintained clients.
Action • To display DHCP local server binding information for the DHCP maintain subscribers
feature:
user@host>show dhcp server binding detail
• To explicitly log out a DHCP local server subscriber when the maintain subscriber
feature is enabled:
user@host>clear dhcp server binding binding-type
Related • Verifying and Managing DHCP Local Server Configuration on page 349
Documentation
Preserving Subscriber Binding Information
When ACX series router functioning as a DHCP local server reboots, by default, all the
subscriber binding information is lost. You can configure ACX series router to preserve
the subscriber binding information to a file in /var/preserve and when the router reboots,
the DHCP local server reads the file and restores the subscriber binding information and
resumes normal packet processing for the subscriber.
The persistent-storage statement under the [edit system services dhcp-local-server]

hierarchy level enables you to store subscriber binding information. The persistent-storage
statement is configured for each routing instance.
The persistent-storage statement under the [edit system processes dhcp-service] hierarchy
level allows you to assign a name for the file. By default, the file is named as
jdhcpd_client_data. The persistent-storage statement under the [edit system processes
dhcp-service] hierarchy level allows you to configure the frequency (between 1 to 48

hours) to backup the file. By default, a new file is generated every 24 hours from the
commit time. On committing the persistent-storage statement, the existing file will be
renamed with a new file in the /var/preserve directory.
NOTE: A commit error will be shown if you try to configure the file with a
name that is already present in the /var/preserve directory.
Related • Use of DHCP Option 50 to Request a Specific IP Address on page 324

Documentation
on page 338

page 341

• Configuring DHCP Local Server to Preserve Subscriber Binding Information on page 340
Configuring DHCP Local Server to Preserve Subscriber Binding Information
You can configure a DHCP local server to preserve subscriber binding information so that
subscriber information is not lost upon router reboot. The configuration is a global setting
for each routing instance.
To configure the DHCP local server to store subscriber binding information:
1. Specify that you want to configure the DHCP local server.

2. Enable persistent storage.

user@host# set persistent-storage automatic

The following is a sample configuration example:
system services {
dhcp-local-server {
persistent-storage automatic
}
}
}
To configure a file to store subscriber binding information:
1. Specify a filename for storing subscriber binding information.
[edit system processes dhcp-service]

user@host# set persistent-storage file-name
2. Specify a frequency to backup the file.

user@host# set persistent-storage backup time
The following is a sample configuration example:
system processes {
dhcp-service {
persistent-storage {
file-name;
backup;
}
}
}

Documentation
• Preserving Subscriber Binding Information on page 339
Understanding Dynamic Reconfiguration of Extended DHCP Local Server Clients
Dynamic reconfiguration of clients enables the extended DHCP local server to initiate a
client update without waiting for the client to initiate a request.

Default Client/Server Interaction

Typically the DHCP client initiates all of the basic DHCP client/server interactions. The
DHCP server sends information to a client only in response to a request from that client.
In subscriber management scenarios, this behavior does not enable a client to be quickly
updated with its network address and configuration in the event of server changes.
For example, suppose a service provider restructured its addressing scheme or changed
the server IP addresses that it provided to clients. Without dynamic reconfiguration, the
service provider typically clears the DHCP server binding table, but cannot inform the
DHCP clients that their bindings have been cleared. Consequently, the DHCP client
operates as though its IP address is still valid, but it is now unable to communicate over
the access network, resulting in an outage. The DHCP local server has to wait for the
client to send a message to renew its lease or rebind to the server. In response, the server
sends a NAK message to the client to force it to begin the DHCP connection process
again. Alternatively, the provider can wait for customers to make a service call about the
network failures and then instruct them to power cycle their customer premises equipment
to reinitiate the connection. Neither of these actions is timely or convenient for customers.
Dynamic Client/Server Interaction for DHCPv4

Dynamic reconfiguration for DHCPv4 is available through a partial implementation of
RFC 3203, DHCP Reconfigure Extension for DHCPv4. It enables the DHCPv4 local server
to send a message to the client to force reconfiguration.
The server sends a forcerenew message to a DHCPv4 client, initiating a message

exchange. In response, DHCPv4 clients that support the forcerenew message then send
a lease renewal message to the server. The server rejects the lease renewal request and
sends a NAK to the client, causing the client to reinitiate the DHCP connection. A
successful reconnection results in the reconfiguration of the DHCP client. Only the
exchange of forcerenew, renew, and NAK messages is supported from RFC 3202.
When the local server state machine starts the reconfiguration process on a bound client,
the client transitions to the reconfiguring state and the local server sends a forcerenew
message to the client. Because the client was in the bound state before entering the
reconfiguring state, all subscriber services, such as forwarding and statistics, continue
to work. Client statistics are not maintained in the interval between a successful
reconfiguration and the subsequent client binding. When the server responds to the client
renewal request with a NAK, the client entry is removed from the binding table and final
statistics are reported. New statistics are collected when the client sends a discover
message to establish a new session.
Dynamic Configuration Options

You can enable dynamic reconfiguration for all DHCP clients or only the DHCP clients
serviced by a specified group of interfaces, and you can modify the behavior accordingly.
• To enable dynamic reconfiguration with default reconfiguration values for all DHCP
clients, include the reconfigure statement at the [edit system services dhcp-local-server]
hierarchy level for DHCPv4 clients. In a routing instance, include the reconfigure

statement at the [edit routing-instances routing-instance-name system services

• Alternatively, to enable dynamic reconfiguration for only the DHCP clients serviced by
a specified group of interfaces, include the reconfigure statement at the [edit system
services dhcp-local-server group group-name] hierarchy level for DHCPv4 clients. In a
routing instance, include the reconfigure statement at the [edit routing-instances
routing-instance-name system services dhcp-local-server group group-name] hierarchy
level
You can optionally modify the behavior of the reconfiguration process by including the
appropriate statements at the [edit system services dhcp-local-server reconfigure]
hierarchy level for all DHCPv4 clients. To override this global configuration for only the
DHCP clients serviced by a specified group of interfaces, you can include the statements
with different values at the [edit system services dhcp-local-server group group-name
reconfigure] hierarchy level for DHCPv4 clients.
In a routing instance, you can optionally modify the behavior of the reconfiguration process
by including the appropriate statements at the [edit routing-instances
<routing-instance-name> system services dhcp-local-server reconfigure] hierarchy level
for all DHCPv4 clients. To override this global configuration for only the DHCP clients
serviced by a specified group of interfaces, you can include the statements with different
values at the [edit routing-instances <routing-instance-name> system services
dhcp-local-server group group-name reconfigure] hierarchy level for DHCPv4 clients.
Include the attempts statement to specify how many times the local server sends the
forcerenew or reconfigure message to initiate client reconfiguration. Include the timeout
statement to set the interval between the first and second attempts. The interval between
each subsequent attempt doubles the previous value. For example, if the first value is 2,
the first retry is attempted 2 seconds after the first attempt fails. The second retry is
attempted 4 seconds after the first retry fails. The third retry is attempted 8 seconds
after the second retry fails, and so on.
By default, the DHCP client’s original configuration is restored if all of the reconfiguration
attempts fail. Include the clear-on-abort statement to delete the client instead.
You can force the local server to initiate the reconfiguration process for clients by issuing
the request dhcp server reconfigure command for DHCPv4 clients. Command options
determine whether reconfiguration is then attempted for all clients or specified clients.
Events that take place while a reconfiguration is in process take precedence over the
reconfiguration. Table 39 on page 343 lists the actions taken in response to several different
events.
Table 39: Action Taken for Events That Occur During a Reconfiguration
Event Action
Server receives a discover message from the client. Server drops packet and deletes client.
Server receives a request, renew, rebind, or init-reboot DHCPv4—Server sends NAK message and
message from the client. deletes client.

Table 39: Action Taken for Events That Occur During a

Reconfiguration (continued)
Event Action
Server receives a release or decline message from Server deletes client.

the client.
The client lease times out. Server deletes client.
The clear dhcp server binding command is issued. Server deletes client.
The request dhcp server reconfigure (DHCPv4) Command is ignored.

command is issued.
DHCP restart occurs. Reconfiguration process is halted.
Related • Configuring Dynamic Reconfiguration of DHCP Clients to Avoid Extended Outages Due
Documentation to Server Configuration Changes on page 344
Configuring Dynamic Reconfiguration of DHCP Clients to Avoid Extended Outages Due

to Server Configuration Changes
The DHCP local server can initiate reconfiguration of its clients to avoid extended outages
because of server configuration changes. In addition to requesting that the DHCP local
server initiate reconfiguration, you can specify the reconfiguration behavior.
To configure dynamic reconfiguration of DHCP clients:
1. Enable dynamic reconfiguration with default values for all clients.

user@host# set reconfigure
2. (Optional) Override the global configuration for a particular group of clients.
[edit system services dhcp-local-server group-name]

user@host# set reconfigure
3. (Optional) Configure how the server attempts reconfiguration.
See “Configuring Dynamic Reconfiguration Attempts for DHCP Clients” on page 345.
4. (Optional) Configure the response to a failed reconfiguration.

See “Configuring Deletion of the Client When Dynamic Reconfiguration Fails” on

page 346.
5. (Optional) Initiate reconfiguration of some or all client bindings.
See “Requesting DHCP Local Server to Initiate Reconfiguration of Client Bindings” on

page 347.
In a routing instance, you can configure dynamic reconfiguration of DHCP clients at the
[edit routing-instances routing-instance-name system services dhcp-local-server] hierarchy
level.
Related • Configuring the Router to Maintain DHCP Subscribers During Interface Delete Events

page 341
Configuring Dynamic Reconfiguration Attempts for DHCP Clients
You can configure how many attempts the local server makes to initiate reconfiguration
of the DHCP client by sending forcerenew messages. You can also specify how long the
server waits between attempts. By default, eight attempts are made and the initial interval
is two seconds.
Each successive attempt doubles the interval between attempts. For example, if the first
value is 2, the first retry is attempted 2 seconds after the first attempt fails. The second
retry is attempted 4 seconds after the first retry fails. The third retry is attempted 8
seconds after the second retry fails, and so on. A group configuration takes precedence
over a DHCP local server configuration.
(Optional) To configure DHCP local server reconfiguration behavior for all DHCP clients:
1. Specify the number of reconfiguration attempts.
[edit system services dhcp-local-server reconfigure]

user@host# set attempts 5
2. Specify the interval between reconfiguration attempts.

user@host# set timeout 8

To override the global configuration for a particular group of clients, include the
statements at the [edit system services dhcp-local-server group group-name reconfigure]
hierarchy level.
In a routing instance, you can configure reconfiguration attempts for all DHCP clients at
the [edit routing-instances <routing-instance-name> system services dhcp-local-server
reconfigure] hierarchy level.

page 341

Configuring Deletion of the Client When Dynamic Reconfiguration Fails
You can configure the local server to delete the client when the maximum number of
reconfiguration attempts has been made without success. By default, the client’s original
configuration is restored.
(Optional) To configure the DHCP local server to delete the client when reconfiguration
is not successful, for all clients:
• Specify the client deletion.

user@host# set clear-on-abort
To override the global configuration for a particular group of clients, include the statement
at the [edit system services dhcp-local-server group group-name reconfigure] hierarchy
level.
To override the configuration for a particular group of clients in a routing instance, include
the statement at the [edit routing-instances routing-instance-name system services
dhcp-local-server group group-name reconfigure] hierarchy level.

page 341


Requesting DHCP Local Server to Initiate Reconfiguration of Client Bindings
You can request that the DHCP local server initiate reconfiguration of all of clients or only
specified clients.
To request reconfiguration of all clients:
• Specify the all option.
user@host> request dhcp server reconfigure all
You can use any of the following methods to request reconfiguration of specific clients:
• Specify the IP address of the DHCP client.
user@host> request dhcp server reconfigure 192.168.27.3
• Specify the MAC address of a DHCPv4 client.
user@host> request dhcp server reconfigure 12:23:34:45:56:67
• Specify an interface; reconfiguration is attempted for all clients on this interface.
user@host> request dhcp server reconfigure interface ge-0/0/0.100
• Specify a routing instance; reconfiguration is attempted for all clients or the specified
clients in this routing instance.
user@host> request dhcp server reconfigure all routing-instance ri-boston

page 341


Clearing DHCP Bindings for Subscriber Access
This topic provides the procedure you use to display current DHCP bindings, clear selected
bindings, and verify that the specified bindings are successfully cleared.
Subscriber management enables you to clear DHCP bindings at several different levels
for DHCP local server. For example, you can clear the DHCP bindings on all interfaces, a
group of interfaces, or a specific interface. You can also clear DHCP bindings based on
IP address, MAC address, session-ID, port, or VLAN.
This topic includes examples to show several variations of the clear DHCP binding feature.
To clear bindings and verify the results for a specific IP address:
1. Display current bindings. Issue the appropriate variation of the show dhcp server binding
command.
user@host> show dhcp server binding

IP address Session Id Hardware address Expires State
Interface
192.168.2.91 882 84:18:88:c0:5b:3b 482 BOUND
ge-0/1/1.42
To display the current bindings in a routing instance, issue the show dhcp server binding
routing-instance name
2. Clear the binding you want to remove.
user@host> clear dhcp server binding 192.168.32.1
To clear current bindings in a routing instance, issue the clear dhcp server binding
3. Verify that the binding has been cleared.
user@host> show dhcp server binding

IP address Session Id Hardware address Expires State
Interface
192.168.2.91 882 84:18:88:c0:5b:3b 482 BOUND
ge-0/1/1.42
To verify the current bindings in a routing instance, issue the show dhcp server binding
The following examples show variations of the clear DHCP binding feature. The examples
use the DHCP local server version of the commands.
To clear all bindings:
user@host> clear dhcp server binding all

To clear bindings on a specific interface:
user@host> clear dhcp server binding interface ge-0/0/2
To clear all bindings over an interface. This example uses the wildcard option.
user@host> clear dhcp server binding ge-1/0/0. *
To clear bindings on top of a specific VLAN. This example clears all bindings on top of
VLAN 100.
user@host> clear dhcp server binding ge-1/0/0:100
To clear all bindings on a port. This example uses the wildcard feature and clears all
DHCP bindings on FPC 1, PIC 0, port 0.
user@host> clear dhcp server binding ge-1/0/0.*

Documentation
on page 338

page 341

Verifying and Managing DHCP Local Server Configuration
Purpose View or clear information about client address bindings and statistics for the extended
DHCP local server.
NOTE: If you delete the DHCP server configuration, DHCP server bindings
might still remain. To ensure that DHCP bindings are removed, issue the clear
dhcp server binding command before you delete the DHCP server configuration.
Action • To display the address bindings in the client table on the extended DHCP local server:

user@host> show dhcp server binding routing-instance customer routing instance
• To display extended DHCP local server statistics:
user@host> show dhcp server statistics routing-instance customer routing instance
• To clear the binding state of a DHCP client from the client table on the extended DHCP
local server:
user@host> clear dhcp server binding routing-instance customer routing instance
• To clear all extended DHCP local server statistics:
user@host> clear dhcp server statistics routing-instance customer routing instance
Related • CLI Explorer

Documentation
Enabling MAC Address Filtering
To support source MAC address filtering for blocking unknown DHCP clients, specify the
list of MAC addresses in the source-address-filter statement:
source-address-filter {
mac-address;
}
If you want to enable source address filtering, use the source-filtering statement.
If you don’t want to enable source address filtering, use the no-source-filtering statement.
You can include these statements at the following hierarchy levels:
• [edit interfaces interface-name gigether-options]
To check packets dropped due to source MAC filtering, use the run show interfaces
interface-name extensive show command.
NOTE: Source MAC filtering is implemented using ternary content addressable

memory (TCAM) space. The allocated TCAM space for this feature is shared
by the filter-based forwarding (FBF) filter, which redirects the matched flow
to the configured routing instance. On the logical interface, if these features
are enabled, then source MAC filter takes higher precedence over the FBF
filter. These features work independently on different logical interfaces
without any limitation. From a scaling perspective, the allocated 125 hardware
TCAM entries are shared by these features and the allocation of TCAM entries
work on a first-come-first-serve basis mode. Source MAC filtering can be
scaled up to 125 TCAM entries without the presence of the FBF filter. In
general, if the ACX Series router has N physical ports, then it can support
(125–N) source MAC addresses at the system level.


Documentation
Tracing General Authentication Service Processes
The Junos OS trace operations feature tracks general authentication service operations
and records events in a log file. By default, the tracing operation is inactive. To trace
general authentication service processes, you specify flags in the traceoptions statement
at the [edit system processes general-authentication-service] hierarchy level. The default
tracing behavior is the following:
• Important events are logged in a file located in the /var/log directory. By default, the
router uses the filename authd. You can specify a different filename, but you cannot
change the directory (/var/log) in which trace files are located.
• When the trace log file filename reaches 128 kilobytes (KB), it is compressed and
renamed filename.0.gz. Subsequent events are logged in a new file called filename,
until it reaches capacity again. At this point, filename.0.gz is renamed filename.1.gz and
filename is compressed and renamed filename.0.gz. This process repeats until the
number of archived files reaches the maximum file number. Then the oldest trace
file—the one with the highest number—is overwritten.
You can optionally specify the number of trace files to be from 2 through 1000. You
can also configure the maximum file size to be from 10 KB through 1 gigabyte (GB). For
more information about how log files are created, see the System Log Explorer.
• By default, only the user who configures the tracing operation can access log files. You
can optionally configure read-only access for all users.
The general authentication service tracing operations are described in the following
sections:
• Configuring the General Authentication Service Processes Trace Log

Filename on page 351
• Configuring the Number and Size of General Authentication Service Processes Log
Files on page 352
• Configuring Access to the Log File on page 352
• Configuring a Regular Expression for Lines to Be Logged on page 353
• Configuring the Trace Operation on page 353
Configuring the General Authentication Service Processes Trace Log Filename

By default, the name of the file that records trace output for general authentication
service is authd. You can specify a different name by including the file statement at the
[edit system processes general-authentication-service] hierarchy level:

To configure the filename for general authentication service tracing operations:
• Specify the name of the file used for the trace output.
[edit system processes general-authentication-service traceoptions]

user@host# set file aap_logfile_1
Configuring the Number and Size of General Authentication Service Processes Log Files
You can optionally specify the number of compressed, archived trace log files to be from
2 through 1000. You can also configure the maximum file size to be from 10 KB through
1 gigabyte (GB); the default size is 128 kilobytes (KB).
The archived files are differentiated by a suffix in the format .number.gz. The newest
archived file is .0.gz and the oldest archived file is .(maximum number)-1.gz. When the
current trace log file reaches the maximum size, it is compressed and renamed, and any
existing archived files are renamed. This process repeats until the maximum number of
archived files is reached, at which point the oldest file is overwritten.
For example, you can set the maximum file size to 2 MB, and the maximum number of
files to 20. When the file that receives the output of the tracing operation, filename,
reaches 2 MB, filename is compressed and renamed filename.0.gz, and a new file called
filename is created. When the new filename reaches 2 MB, filename.0.gz is renamed
filename.1.gz and filename is compressed and renamed filename.0.gz. This process repeats
until there are 20 trace files. Then the oldest file, filename.19.gz, is simply overwritten
when the next oldest file, filename.18.gz is compressed and renamed to filename.19.gz.
To configure the number and size of trace files:
• Specify the name, number, and size of the file used for the trace output, by including
the files and size options with the traceoptions statement.

user@host# set file aap_logfile_1 files 20 size 2097152
Configuring Access to the Log File

By default, log files can be accessed only by the user who configures the tracing operation.
You can allow all users to read the log file and you can explicitly set the default behavior
of the log file.
To specify that all users can read the log file:
• Configure the log file to be world-readable.

user@host# set file aap_logfile_1 world-readable
To explicitly set the default behavior, in which the log file can only be read by the user
who configured tracing:
• Configure the log file to be no-world-readable.

user@host# set file aap_logfile_1 no-world-readable
Configuring a Regular Expression for Lines to Be Logged

By default, the trace operation output includes all lines relevant to the logged events.
You can refine the output by including regular expressions (regex) that will be matched.
To configure regular expressions to match:
• Configure the regular expression.

user@host# set file aap_logfile_1 match regular-expression
Configuring the Trace Operation

By default, only important events are logged. You can specify which trace operations are
logged by including specific tracing flags. The following table describes the flags that
you can include.
Flag Description
address-assignment Trace all address-assignment pool events.
all Trace all tracing operations.
configuration Trace configuration events.
To configure the flags for the event to be logged:
• Configure the flags.

user@host# set flag address-assignment
Tracing Extended DHCP Operations
The extended DHCP local server supports tracing operations. DHCP tracing operations
track extended DHCP operations and record them in a log file. The error descriptions
captured in the log file provide detailed information to help you solve problems.
You can configure DHCP trace operations at the global level and at the interface level.
Global DHCP tracing logs all DHCP-related events, whereas interface-level tracing logs
only interface-specific DHCP events. If you configure interface-level trace operations,
you can specify tracing for a range of interfaces or an individual interface. However, only
a single interface-level log file is supported. That is, you cannot specify different
interface-level log files for different interfaces or groups of interfaces.
By default, nothing is traced. When you enable the tracing operation, the default tracing
behavior is as follows:

• Important events for both global and per-interface tracing are logged in a file located
in the /var/log directory. By default, the router uses the filename, jdhcpd. You can
specify a different filename, but you cannot change the directory in which trace files
are located.
• When the trace log file filename reaches 128 kilobytes (KB), it is compressed and
renamed filename.0.gz. Subsequent events are logged in a new file called filename,
until it reaches capacity again. At this point, filename.0.gz is renamed filename.1.gz and
filename is compressed and renamed filename.0.gz. This process repeats until the
number of archived files reaches the maximum file number. Then the oldest trace
file—the one with the highest number—is overwritten.
You can optionally specify the number of trace files to be from 2 through 1000. You
can also configure the maximum file size to be from 10 KB through 1 gigabyte (GB).
(For more information about how log files are created, see the System Log Explorer.)
• By default, only the user who configures the tracing operation can access log files. You
can optionally configure read-only access for all users.
To configure global DHCP tracing operations.
• Specify tracing operations for DHCP local server:

user@host# edit traceoptions
The tracing configuration is applied globally to DHCP local server in every LS:RI.
Configuration of event tracing on a per-LS:RI basis is not supported. DHCP tracing is
configurable only in the default LS:RI. However, the DHCP local server do not have to be
configured in the default LS:RI.
For information about configuring per-interface tracing options, see “Tracing Extended
DHCP Operations for Specific Interfaces” on page 358.
The extended DHCP traceoptions operations are described in the following sections:
• Configuring the Extended DHCP Log Filename on page 354

• Configuring the Number and Size of Extended DHCP Log Files on page 355
• Configuring Access to the Extended DHCP Log File on page 355
• Configuring a Regular Expression for Extended DHCP Messages to Be Logged on page 356
• Configuring the Extended DHCP Tracing Flags on page 356
• Configuring the Severity Level to Filter Which Extended DHCP Messages Are
Logged on page 357
• Tracing Extended DHCP Operations for Specific Interfaces on page 358
Configuring the Extended DHCP Log Filename

By default, the name of the file that records trace output is jdhcpd. You can specify a
different name by including the file option. DHCP local server supports the file option for
the traceoptions statement and the interface-traceoptions statement.

To change the filename:
• Specify a filename for global tracing operations.
[edit system processes dhcp-service traceoptions]

user@host# set file filename
• Specify a filename for per-interface tracing operations.
[edit system processes dhcp-service interface-traceoptions]

user@host# set file filename
Configuring the Number and Size of Extended DHCP Log Files

You can optionally specify the number of compressed, archived trace log files to be from
2 through 1000. You can also configure the maximum file size to be from 10 KB through
1 gigabyte (GB); the default size is 128 kilobytes (KB).
The archived files are differentiated by a suffix in the format .number.gz. The newest
archived file is .0.gz and the oldest archived file is .(maximum number)-1.gz. When the
current trace log file reaches the maximum size, it is compressed and renamed, and any
existing archived files are renamed. This process repeats until the maximum number of
archived files is reached, at which point the oldest file is overwritten.
For example, you can set the maximum file size to 2 MB, and the maximum number of
files to 20. When the file that receives the output of the tracing operation, filename,
reaches 2 MB, filename is compressed and renamed filename.0.gz, and a new file called
filename is created. When the new filename reaches 2 MB, filename.0.gz is renamed
filename.1.gz and filename is compressed and renamed filename.0.gz. This process repeats
until there are 20 trace files. Then the oldest file, filename.19.gz, is simply overwritten
when the next oldest file, filename.18.gz is compressed and renamed to filename.19.gz.
DHCP local server supports the files and size options for the traceoptions statement and
the interface-traceoptions statement. To configure the number and size of trace files:
• Specify the name, number, and size of the file used for the trace output for global
tracing operations.

user@host# set file filename files number size maximum-file-size
• Specify the name, number, and size of the file used for the trace output for per-interface
tracing operations.

user@host# set file filename files number size maximum-file-size
Configuring Access to the Extended DHCP Log File

By default, only the user who configures the tracing operation can access the log files.
You can enable all users to read the log file and you can explicitly set the default behavior
of the log file.

DHCP local server supports the world-readable option and the no-world-readable option
for the traceoptions statement and the interface-traceoptions statement. To specify that
all users can read the log file:
• Configure the log file to be world-readable for global tracing operations.

user@host# set file filename world-readable
• Configure the log file to be world-readable for per-interface tracing operations.

user@host# set file filename world-readable
To explicitly set the default behavior, in which the log file can only be read by the user
who configured tracing:
• Configure the log file to be no-world-readable for global tracing operations.

user@host# set file filename no-world-readable
• Configure the log file to be no-world-readable for per-interface tracing operations.

user@host# set file filename no-world-readable
Configuring a Regular Expression for Extended DHCP Messages to Be Logged

By default, the trace operation output includes all messages relevant to the logged
events. You can refine the output by including regular expressions to be matched.
DHCP local server supports the match option for the traceoptions statement and the
interface-traceoptions statement. To configure regular expressions to be matched:
• Specify the regular expression for global tracing operations.

user@host# set file filename match regular-expression
• Specify the regular expression for per-interface tracing operations.

user@host# set file filename match regular-expression
Configuring the Extended DHCP Tracing Flags

By default, only important events are logged. You can specify which events and operations
are logged by specifying one or more tracing flags.
DHCP local server supports the flag option for the traceoptions statement and the
interface-traceoptions statement. A smaller set of flags is supported for interface-level
tracing than for global tracing. To configure the flags for the events to be logged:
• Specify the flags for global tracing operations.

user@host# set flag flag

• Specify the flags for per-interface tracing operations.

user@host# set flag flag
Configuring the Severity Level to Filter Which Extended DHCP Messages Are Logged
The messages associated with a logged event are categorized according to severity level.
You can use the severity level to determine which messages are logged for the event
type. A low severity level is less restrictive—filters out fewer messages—than a higher
level. When you configure a severity level, all messages at that level and all higher (more
restrictive) levels are logged.
The following list presents severity levels in order from lowest (least restrictive) to highest
(most restrictive). This order also represents the significance of the messages; for
example, error messages are of greater concern than info messages.
• verbose
• info
• notice
• warning
• error
The severity level that you configure depends on the issue that you are trying to resolve.
In some cases you might be interested in seeing all messages relevant to the logged
event, so you specify all. You can also specify verbose with the same result, because
verbose is the lowest (least restrictive) severity level; it has nothing to do with the
terseness or verbosity of the messages. Either choice generates a large amount of output.
You can specify a more restrictive severity level, such as notice or info to filter the
messages. By default, the trace operation output includes only messages with a severity
level of error.
DHCP local server supports the level option for the traceoptions statement and the
interface-traceoptions statement. To configure the flags for the events to be logged:
• Specify the severity level for global tracing operations.

user@host# set level severity
• Specify the severity level for per-interface tracing operations.

user@host# set level severity

Tracing Extended DHCP Operations for Specific Interfaces

In addition to the global DHCP tracing operations, subscriber management enables you
to trace extended DHCP operations for a specific interface or for a range of interfaces.
Configuring per-interface tracing is a two-step procedure. In the first step, you specify
the tracing options that you want to use, such as file information and flags. In the second
step, you enable the tracing operation on the specific interfaces.
To configure per-interface tracing operations:
1. Specify the tracing options you want to use.
NOTE: Per-interface tracing uses the same default tracing behavior as

the global extended DHCP tracing operation. The default behavior is
described in “Tracing Extended DHCP Operations” on page 353.
a. Specify that you want to configure per-interface tracing options.

user@host# edit interface-traceoptions
b. (Optional) Specify the tracing file options.
• Configure the name for the file used for the trace output.
See “Configuring the Extended DHCP Log Filename” on page 354.
• Configure the number and size of the log files.
See “Configuring the Number and Size of Extended DHCP Log Files” on page 355.
• Configure access to the log file.
See “Configuring Access to the Extended DHCP Log File” on page 355.
• Configure a regular expression to filter logging events.
See “Configuring a Regular Expression for Extended DHCP Messages to Be

Logged” on page 356.
c. (Optional) Specify tracing flag options.
See “Configuring the Extended DHCP Tracing Flags” on page 356.
d. (Optional) Configure a severity level for messages to specify which event messages
are logged.
See “Configuring the Severity Level to Filter Which Extended DHCP Messages Are
Logged” on page 357.
2. Enable tracing on an interface or interface range.
The following examples show a DHCP local server configuration.

• Enable tracing on a specific interface.

user@host# set group group-name interface interface-name trace
• Enable tracing on a range of interfaces.

user@host# set group group-name interface interface-name upto interface
interface-name trace
Understanding DHCP Client Operation
A Dynamic Host Configuration Protocol (DHCP) client can obtain its TCP/IP settings and
the IP address from a DHCP local server. The DHCP server provides the configuration
parameters to requesting DHCP clients in the form of an address-lease offer.
For a router to operate as a DHCP client, you configure a logical interface on the router
to obtain an IP address from the DHCP server in the network. You can configure the
vendor class ID, lease time, DHCP server address, retransmission attempts, and retry
interval configuration attributes. You can also renew DHCP client releases.
An ACX Series router acting as a DHCP client obtains IP address and other configuration
parameters from a DHCP local server. Upon receiving an IP address from the DHCP server,
the DHCP client automatically adds an access internal default route. Unless specific
server is configured in client configuration, DHCP client accepts the PDUs from the first
DHCP server response.
In a routing instance, if there multiple interfaces acting as DHCP client, default route and
domain name server configured in the system will be the one created by last DHCP client.
DHCP client options and address pools are configured in a centralized address pool
server. For DHCP clients connected though Ethernet interfaces, the DHCP server
automatically adds an access internal host route once the DHCP client obtains an address,
specifying the interface as the outbound interface. The route is automatically removed
once the DHCP client lease time expires or when the DHCP client releases the address.
Typically, a DHCP server uses the client and option 82 information from DHCP PDUs to
assign IP addresses and send other client configuration information.

Documentation

Configuring a DHCP Client
• Minimum DHCP Client Configuration on page 360

• Configuring Optional DHCP Client Attributes on page 360
• Verifying and Managing DHCP Client Configuration on page 361
Minimum DHCP Client Configuration

The following sample output shows the minimum configuration you must use to configure
an ACX Series router as a DHCP client. In this output, the interface is ge-0/0/0 and the
logical unit is 0.
[edit interfaces]
ge-0/0/0 {
unit 0 {
family inet {
dhcp-client
}
}
}
NOTE: To configure a DHCP client in a routing instance, add the interface in

a routing instance using the [edit routing-instances] hierarchy.
Configuring Optional DHCP Client Attributes

For an ACX Series router to operate as a DHCP client, you configure a logical interface
on the router to obtain an IP address from the DHCP local server in the network. You can
then set the client-identifier, lease time, retransmission attempts, retransmission interval,
preferred DHCP local server address, vendor class ID, and update server.
To configure optional DHCP client attributes:
1. Configure the DHCP client identifier as the routing instance name.
• DHCP client identifier as a user ID.
[edit interfaces ge-0/0/1 unit 0 family inet dhcp-client]

user@host# set client-identifier user-id {ascii ascii | hexadecimal hexadecimal}
• DHCP client identifier as the description of an interface.

user@host# set client-identifier use-interface-description {logical | device}
• DHCP client identifier as a prefix:

user@host# set client-identifier prefix [host-name logical-system-name
routing-instance-name]
2. Configure the DHCP client identifier prefix as the routing instance name.

user@host# set client-identifier prefix [host-name logical-system-name

routing-instance-name]
3. Set the DHCP lease time.

user@host# set lease-time 86400
4. Set the number of attempts allowed to retransmit a DHCP packet.

user@host# set retransmission-attempts 6
5. Set the interval (in seconds) allowed between retransmission attempts. The range
is 4 through 64. The default is 4 seconds.

user@host# set retransmission-interval 5
6. Set the IPv4 address of the preferred DHCP local server.

user@host# set server 10.1.1.1
7. Set the vendor class ID for the DHCP client.

user@host# set vendor-id ether
8. Propagate DHCP options received from an external DHCP server to a local DHCP
server. By default, this option is not turned on.

user@host# set update-server
NOTE: To configure the DHCP client in a routing instance, configure the

interface in the [edit routing-instances] hierarchy.
Verifying and Managing DHCP Client Configuration

You can view or clear information about client address bindings and statistics for the
DHCP client.
• To display the address bindings in the client table on the DHCP client:
user@host> show dhcp client binding
• To display DHCP client statistics:
user@host> show dhcp client statistics
• To clear the binding state of a DHCP client from the client table on the DHCP client:

user@host> clear dhcp client binding
• To clear all DHCP client statistics:
user@host> clear dhcp client statistics
• To renew a DHCP client lease time:
user@host> request dhcp client renew interface-name
NOTE: To clear or view information about client bindings and statistics in a

routing instance, run the following commands:
• show dhcp client binding routing-instance routing-instance name
• show dhcp client statistics routing-instance routing-instance name
• clear dhcp client binding routing-instance routing-instance name
• clear dhcp client statistics routing-instance routing-instance name

Documentation
• Tracing General Authentication Service Processes on page 351
• Tracing Extended DHCP Operations on page 353
DHCP Duplicate Client Differentiation Using Client Subinterface Overview
In some network environments, client IDs and MAC addresses might not be unique,
resulting in duplicate clients. For example, two network adapters might be manufactured
with the same hardware address, resulting in a duplicate MAC address among the DHCP
clients attached to the router. A duplicate DHCP client occurs when a client attempts to
get a lease, and that client has the same client ID or the same MAC address as an existing
DHCP client.
When an extended DHCP local server receives a request from a new client that has a
duplicate ID or MAC address, the DHCP server terminates the address lease for the existing
client and returns the address to its original address pool. The DHCP server then assigns
a new address and lease to the new client.

By default, a DHCP local server uses the subnet information to differentiate between
duplicate clients. However, in some cases, this level of differentiation is not adequate.
For example, when multiple subinterfaces share the same underlying loopback interface
with the same preferred source address, the interfaces appear to be on the same subnet.
In this situation, the default configuration prevents duplicate clients.
You can provide greater differentiation between duplicate clients by configuring DHCP
to consider the client subinterface when duplicate clients occur. In this optional
configuration, DHCP uniquely identifies:
• The subnet on which the client resides
• The subinterface on which the client resides
• The client within the subnet

Documentation
Guidelines for Configuring Support for DHCP Duplicate Clients
This topic describes the guidelines for configuring Dynamic Host Configuration Protocol
(DHCP) to include the client subinterface in order to distinguish between duplicate clients
(clients with the same MAC address or client ID) in a subscriber access environment.
When configuring DHCP duplicate client support, consider the following guidelines:
• The optional DHCP duplicate client support feature is used for DHCPv4 clients. For
DHCPv6, client identification is independent of MAC address.
• For DHCP relay agent configuration:
• DHCP relay must be configured to insert option 82, regardless of whether or not the
incoming packet has option 82.
• Option 82 must include the Agent Circuit ID suboption (suboption 1).
• Option 82 must be the interface name, not the interface description.
• The DHCP server must echo option 82 in the server’s reply. This is required because
of the following:
• The giaddr inserted by DHCP relay is the same for duplicate clients on different
subinterfaces. The DHCP local server uses option 82 when allocating the IP address.
• DHCP relay uses the echoed option 82 to learn the client subinterface and to
construct the client key.


Documentation
Configuring DHCP Duplicate Client Support
You can optionally configure a DHCP local server to include a client subinterface when
distinguishing between two clients that have the same MAC address or client ID. The
configuration is a global setting for each routing instance.
To configure the DHCP local server to include the client subinterface:
1. Specify that you want to configure the DHCP local server.

2. Configure the optional duplicate client support.

user@host# set duplicate-clients-on-interface

Documentation



CHAPTER 11
Configuring DHCP and DHCPv6 Relay

Agent
• DHCP Relay Agent on ACX Series Routers on page 368

• DHCPv6 Relay Agent on ACX Series Routers on page 370
• Inserting the DHCPv6 Interface Identifier into DHCPv6 Packets on page 371
• Configuring Group-Specific DHCP Relay Options on page 372
• Overriding the Default DHCP Relay Configuration Settings on page 373
• Changing the Gateway IP Address (giaddr) Field to the giaddr of the DHCP Relay
Agent on page 376
• Replacing the DHCP Relay Request and Release Packet Source Address on page 376
• Overriding Option 82 Information on page 377
• Using Layer 2 Unicast Transmission for DHCP Packets on page 377
• Trusting Option 82 Information on page 378
• Sending Release Messages When Clients Are Deleted on page 381
• Disabling Automatic Binding of Stray DHCP Requests on page 381
• Using DHCP Relay Agent Option 82 Information on page 383
• Using DHCP Option Information to Selectively Process DHCP Client Traffic on page 390
• Understanding DHCP Option 82 for Protecting Switching Devices Against
Attacks on page 392
• Configuring DHCP Option 82 to Help Protect the Switching Devices Against Attacks
(CLI Procedure) on page 396
• Configuring Named Server Groups on page 398
• Configuring Active Server Groups to Apply a Common DHCP Relay Agent Configuration
to Named Server Groups on page 398
• Disabling DHCP Relay on page 399

DHCP Relay Agent on ACX Series Routers
You can configure extended DHCP relay options on the ACX Series router and enable
the router to function as a DHCP relay agent. A DHCP relay agent forwards DHCP request
and reply packets between a DHCP client and a DHCP server. DHCP relay agents are
used to forward requests and replies between clients and servers that do not reside in
the same physical subnet. The forwarding of DHCP packets that the DHCP relay agent
performs differs from the normal forwarding of IP packets that a router performs. Unlike
IP forwarding in which IP datagrams are switched between networks in a slightly
transparent manner, a DHCP relay agent receives DHCP messages and generates a new
DHCP message to send out on another interface. The DHCP relay agent sets the gateway
address (giaddr field of the DHCP packet), adds the DHCP relay agent information option
(option 82) in the packet, if it is present, and forwards it to the DHCP server.
The DHCP relay agent information option (option 82) enables you to include additional
useful information in the client-originated DHCP packets that the DHCP relay forwards
to a DHCP server. When the DHCP relay agent information option is enabled, the DHCP
relay adds the option 82 information to packets it receives from clients, then forwards
the packets to the DHCP server. The DHCP server uses the option 82 information to
decide which IP address to assign to the client—the DHCP server might also use
information in the option 82 field for additional purposes, such as determining which
services to grant to the client. The DHCP server sends its reply back to the DHCP relay,
which removes the option 82 information field from the message, and then forwards the
packet to the client.
DHCP relay agents eliminate the need to configure a DHCP server in each physical network.
In mobile backhaul networks, most of the base station vendors might use DHCP as the
address assignment protocol for different types of base stations (for example, base
transceiver station (BTS) in 2G, NodeB in 3G, and eNodeB in 4G networks). In such
networks, you can configure ACX Series routers to operate as a DHCP relay agent to
forward DHCP requests and acknowledgements between the base station and the DHCP
server.
To configure the DHCP relay agent on the router for IPv4 packets, include the dhcp-relay
statement at the [edit forwarding-options] hierarchy level. You can also include the
dhcp-relay statement at the [edit routing-instances routing-instance-name
forwarding-options] hierarchy level.
NOTE: DHCP relay is supported on Integrated Routing and Bridging (IRB)

interfaces.
To verify and manage DHCP relay agent settings: you can use the following operational
commands:
• clear dhcp relay binding
• clear dhcp relay statistics

Chapter 11: Configuring DHCP and DHCPv6 Relay Agent
• show dhcp relay binding
• show dhcp relay statistics
The following DHCP functionalities are not supported on ACX Series routers:
• Authentication for DHCP relay agents.
• DHCP server configuration.
• DHCP snooping to enable the router differentiate between trusted and untrusted
interfaces.
• DHCP liveness detection.
• DHCPv6 relay agent in IPv6 networks.
• Dynamic profiles for DHCP.
• DHCP relay agent in an L2VPN (dhcp-relay statement at the [edit routing-instances

routing-instance-name protocols l2vpn] hierarchy level)
• The DHCP relay agent does not add VPN identifiers to the incoming DHCP requests
before it relays them to the DHCP server. Therefore, transmission of DHCP packets
between different virtual routing and forwarding (VRF) instances is not supported.
• DHCP relay agent does not support the following operations:
• DHCP relay agent authentication by including the authentication statement at the

[edit forwarding-options dhcp- relay] hierarchy level for global configuration, and
similarly for a named group of interfaces
• DHCP relay agent snooping by including the allow-snooped-clients option in the

overrides statement at the [edit forwarding-options dhcp-relay] hierarchy level for
global configuration, and similarly for a named group of interfaces or a specific
interface
• DHCP snooped packet forwarding by including the forward-snooped-clients statement

at the [edit forwarding-options dhcp-relay] hierarchy level for global configuration,
and similarly for a named group of interfaces or a specific interface
• Overriding default DHCP relay agent configuration options by including the overrides
statement and its subordinate statements at the [edit forwarding-options dhcp-relay],
[edit forwarding-options dhcp-relay group group-name], and [edit forwarding-options
dhcp-relay group group-name interface] hierarchy levels.
The DHCP functionality supports the DHCP vendor class identifier option (option 60).
This support allows DHCP relay to compare option 60 strings in received DHCP client
packets against strings that you configure on the router. You can use the DHCP relay
option 60 feature when providing converged services in your network environment—option
60 support enables DHCP relay to direct client traffic to the specific DHCP server (the
vendor-option server) that provides the service that the client requires. Otherwise, as
another option, you can configure option 60 strings to direct traffic to the DHCP local
server in the current virtual router.

For example, you might have an environment in which some DHCP clients require only
Internet access, while other clients require IPTV service. The clients that need Internet
access get their addresses assigned by the DHCP local server on the router (in
equal-access mode). Clients requiring IPTV must be relayed to a specific DHCP server
that provides the service. To support both types of clients, you configure two option 60
strings on the DHCP relay. Now, when any DHCP client packets are received with option
60 strings configured, the strings are matched against all strings configured on the DHCP
relay. If the client string matches the first string you configured, that client is directed to
the DHCP local server and gains Internet access. Client traffic with an option 60 string
that matches your second string is relayed to the DHCP server that provides the IPTV
service. In addition, you can configure a default action, which DHCP relay performs when
a client option 60 string does not match any strings you have configured—for example,
you might specify that all clients with non-matching strings be dropped.
Related • dhcp-relay on page 1491

Documentation
• overrides on page 1647
DHCPv6 Relay Agent on ACX Series Routers
The DHCPv6 relay agent enhances the extended DHCP relay agent by providing DHCP
support in an IPv6 network. DHCPv6 relay agents eliminate the necessity of having a
DHCPv6 server on each physical network. An ACX Series router configured as a DHCPv6
relay agent passes messages between the DHCPv6 client and the DHCPv6 server, similar
to the way a DHCP relay agent supports an IPv4 network.
The DHCPv6 relay agent is compatible with the extended DHCP local server and the
extended DHCP relay agent, and can be enabled on the same interface as either the
extended DHCP local server or DHCP relay agent.
To configure a DHCPv6 relay agent on the ACX Series routers, include the dhcpv6
statement at the [edit forwarding-options dhcp-relay] hierarchy level. You can also include
the dhcpv6 statement at the [edit routing-instances routing-instance-name
forwarding-options] hierarchy level.
Use the following operational commands to verify and manage DHCPv6 relay agent
settings:
• clear dhcpv6 relay binding
• clear dhcpv6 relay binding routing-instance routing-instance-name
• clear dhcpv6 relay statistics
• clear dhcpv6 relay statistics routing-instance routing-instance-name
• show dhcpv6 relay binding
• show dhcpv6 relay binding routing-instance routing-instance-name
• show dhcpv6 relay statistics
• show dhcpv6 relay statistics routing-instance routing-instance-name

The following DHCPv6 functionalities are not supported on ACX Series routers:
• Subscriber authentication for DHCPv6 relay agents
• DHCP snooping
• DHCPv6 client
• Liveness detection
• Dynamic profiles
• Option 37 support for remote ID insertion
• Bidirectional Forwarding Detection (BFD) for DHCPv6 relay
• DHCPv6 relay persistence on router reboot, or crash, or power failure
Related • dhcp-relay on page 1491

Documentation
• dhcpv6 on page 1493
• overrides on page 1647
Inserting the DHCPv6 Interface Identifier into DHCPv6 Packets
You can configure DHCPv6 relay agent to insert the DHCPv6 interface identifier, using
option 18, in the packets that the relay sends to a DHCPv6 server. You can configure the
option 18 support at either the DHCPv6 global level or the DHCPv6 group level.
When you configure option 18 support, you can optionally include the following additional
information:
• Prefix—Specify the prefix option to add a prefix to the interface identifier. The prefix
can be any combination of hostname and routing instance name.
• Interface description—Specify the use-interface-description option to include the textual

interface description instead of the interface identifier. You can include either the device
interface description or the logical interface description.
NOTE: If you specify one of the optional configurations, and the specified
information does not exist (for example, if there is no interface description),
DHCPv6 relay ignores the optional configuration and inserts the default
interface identifier in the packets.
To insert the DHCPv6 interface identifier (option 18) in DHCPv6 packets:
1. Configure the DHCPv6 relay to include option 18.
[edit forwarding-options dhcp-relay dhcpv6]

user@host# edit relay-agent-interface-id
2. (Optional) Specify the prefix to include in option 18.

[edit forwarding-options dhcp-relay dhcpv6 relay-agent-interface-id]

user@host# set prefix prefix
3. (Optional) Specify that option 18 use the textual description of the interface. You can
specify the device interface description.

user@host# set use-interface-description (device)
Related • DHCPv6 Relay Agent on ACX Series Routers on page 370

Documentation
• dhcpv6 (DHCPv6 Relay Agent on ACX Series) on page 1493
Configuring Group-Specific DHCP Relay Options
You can include the following statements at the [edit forwarding-options dhcp-relay
group group-name] hierarchy level to set group-specific DHCP relay agent configuration
options. Group-specific statements apply only to the named group of interfaces, and
override any global DHCP relay agent settings for the same statement.
Include the statements at the [edit forwarding-options dhcp-relay dhcpv6 group

group-name] hierarchy level to configure group-specific options for DHCPv6 relay agent.
• active-server-group—Configure an active server group to apply a common DHCP relay

agent configuration to a named group of DHCP server addresses. For information, see
“Configuring Active Server Groups to Apply a Common DHCP Relay Agent Configuration
to Named Server Groups” on page 398.
• authentication—Configure the parameters the router (or switch) sends to the external
AAA server.
• dynamic-profile—Specify the dynamic profile that is attached to a group of interfaces.
• interface—Specify one or more interfaces, or a range of interfaces, that are within the
specified group.
• liveness-detection—Configure bidirectional failure detection timers and authentication

criteria for static routes. For more information, see DHCP Liveness Detection Overview.
• overrides—Override the default configuration settings for the extended DHCP relay
agent. For information, see “Overriding the Default DHCP Relay Configuration Settings”
on page 373.
• relay-agent-interface-id—(DHCPv6 only) Insert the DHCPv6 Relay Agent Interface-ID

option (option 18) in DHCPv6 packets destined for the DHCPv6 server.
• relay-agent-remote-id—(DHCPv6 only) Insert the DHCPv6 Relay Agent Remote-ID

option (option 37) in DHCPv6 packets destined for the DHCPv6 server.
• relay-option—Configure selective processing, which uses DHCP options in client packets

to identify and filter client traffic, and to specify the action DHCP relay agent takes
with the traffic. For more information, see “Using DHCP Option Information to Selectively
Process DHCP Client Traffic” on page 390.

• relay-option-82—(DHCPv4 only) Enable or disable the insertion of option 82 information

in packets destined for a DHCP server. For information, see “Using DHCP Relay Agent
Option 82 Information” on page 383.
• service-profile—Specify the default subscriber service, (or default profile) which is

activated when the subscriber (or DHCP client) logs in and no other service is activated
by a RADIUS server or a provisioning server. For more information, see Default Subscriber
Service Overview.
Related • Grouping Interfaces with Common DHCP Configurations

Documentation
Overriding the Default DHCP Relay Configuration Settings
You can override the default DHCP relay configuration settings at the global level, for a
named group of interfaces, or for a specific interface within a named group.
• To override global default DHCP relay agent configuration options, include the overrides
statement and its subordinate statements at the [edit forwarding-options dhcp-relay]
hierarchy level.
• To override DHCP relay configuration options for a named group of interfaces, include
the statements at the [edit forwarding-options dhcp-relay group group-name] hierarchy
level.
• To override DHCP relay configuration options for a specific interface within a named
group of interfaces, include the statements at the [edit forwarding-options dhcp-relay
group group-name interface interface-name] hierarchy level.
• To configure overrides for DHCPv6 relay at the global level, group level, or per-interface,
use the corresponding statements at the [edit forwarding-options dhcp-relay dhcpv6]
hierarchy level.

To override default DHCP relay agent configuration settings:
1. (DHCPv4 and DHCPv6) Specify that you want to configure override options.
• DHCPv4 overrides.
Global override:
[edit forwarding-options dhcp-relay]

Group-level override:

user@host# edit group group-name overrides

user@host# edit group group-name interface interface-name overrides
• DHCPv6 overrides.
Global override:

Group-level override:

user@host# edit group group-name overrides

user@host# edit group group-name interface interface-name overrides
2. (DHCPv4 only) Enable DHCP relay proxy mode.
See Enabling DHCP Relay Proxy Mode.
3. (DHCPv4 only) Overwrite the giaddr in DHCP packets that the DHCP relay agent
forwards.
See “Changing the Gateway IP Address (giaddr) Field to the giaddr of the DHCP Relay
Agent” on page 376.
4. (DHCPv4 only) Replace the IP source address in DHCP relay request and release
packets with the gateway IP address (giaddr).
See “Replacing the DHCP Relay Request and Release Packet Source Address” on
page 376.
5. (DHCPv4 only) Override the DHCP relay agent information option (option 82) in DHCP
packets.
See “Overriding Option 82 Information” on page 377.

6. (DHCPv4 only) Override the setting of the broadcast bit in DHCP request packets and
use the Layer 2 unicast transmission method.
See “Using Layer 2 Unicast Transmission for DHCP Packets” on page 377.
7. (DHCPv4 only) Trust DHCP client packets that have a giaddr of 0 and that contain
option 82 information.
See “Trusting Option 82 Information” on page 378.
8. (DHCPv4 and DHCPv6) Override the maximum number of DHCP clients allowed per
interface.
See “Specifying the Maximum Number of DHCP Clients Per Interface” on page 378.
9. (DHCPv4 only) Configure client auto logout.
See DHCP Auto Logout Overview.
10. (DHCPv4 and DHCPv6) Enable or disable support for DHCP snooped clients on
interfaces.
See Enabling and Disabling DHCP Snooped Packets Support for DHCP Relay Agent.
11. (DHCPv4 and DHCPv6) Delay authentication of subscribers until the DHCP client
sends a Request packet.
See the delay-authentication.
12. (DHCPv4 and DHCPv6) Send release messages to the DHCP server when clients are
deleted.
See “Sending Release Messages When Clients Are Deleted” on page 381.
13. (Optional) Specify that when the DHCP or DHCPv6 relay agent receives a Discover
or Solicit message that has a client ID that matches the existing client entry, the relay
agent deletes the existing client entry.
See DHCP Behavior When Renegotiating While in Bound State.
14. (DHCPv6 only) Automatically log out existing client when new client solicits on same
interface.
See Automatically Logging Out DHCPv6 Clients.
15. (DHCPv4 only) Disable the DHCP relay agent on specific interfaces.
See “Disabling DHCP Relay” on page 399.
16. (DHCPv4 and DHCPv6) Disable automatic binding of stray DHCP requests.

See “Disabling Automatic Binding of Stray DHCP Requests” on page 381.
17. (DHCPv4 and DHCPv6) Assign a single-session DHCP dual-stack group to a specified
group of subscribers. You must assign the group to both legs of the DHCP dual stack.
See Configuring Single-Session DHCP Dual-Stack Support.
18. (Optional, DHCPv4 and DHCPv6l) Specify that a short lease be sent to the client.
See Configuring DHCP Asymmetric Leasing.
Related • Configuring Group-Specific DHCP Relay Options on page 372

Documentation
• Deleting DHCP Local Server and DHCP Relay Override Settings
Changing the Gateway IP Address (giaddr) Field to the giaddr of the DHCP Relay Agent
You can configure the DHCP relay agent to change the gateway IP address (giaddr) field
in packets that it forwards between a DHCP client and a DHCP server.
To overwrite the giaddr of every DHCP packet with the giaddr of the DHCP relay agent
before forwarding the packet to the DHCP server:

2. Specify that the giaddr of DHCP packets is overwritten.
[edit forwarding-options dhcp-relay overrides]

user@host# set always-write-giaddr
Related • Extended DHCP Relay Agent Overview

Documentation
Replacing the DHCP Relay Request and Release Packet Source Address
You can configure the DHCP relay agent to replace request and release packets with the
gateway IP address (giaddr) before forwarding the packet to the DHCP server.
To replace the source address with giaddr:


2. Specify that you want to replace the IP source address in DHCP relay request and
release packets with the gateway IP address (giaddr).

user@host# set replace-ip-source-with giaddr

Documentation
Overriding Option 82 Information
You can configure the DHCP relay agent to add or remove the DHCP relay agent
information option (option 82) in DHCP packets.
This feature causes the DHCP relay agent to perform one of the following actions,
depending on the configuration:
• If the DHCP relay agent is configured to add option 82 information to DHCP packets,
it clears the existing option 82 values from the DHCP packets and inserts the new
values before forwarding the packets to the DHCP server.
• If the DHCP relay agent is not configured to add option 82 information to DHCP packets,
it clears the existing option 82 values from the packets, but does not add any new
values before forwarding the packets to the DHCP server.
To override the default option 82 information in DHCP packets destined for a DHCP
server:

2. Specify that the option 82 information in DHCP packets is overwritten.

user@host# set always-write-option-82

Documentation
Using Layer 2 Unicast Transmission for DHCP Packets
You can configure the DHCP relay agent to override the setting of the broadcast bit in
DHCP request packets. DHCP relay agent then instead uses the Layer 2 unicast
transmission method to send DHCP Offer reply packets and DHCP ACK reply packets
from the DHCP server to DHCP clients during the discovery process.

To override the default setting of the broadcast bit in DHCP request packets:

2. Specify that the DHCP relay agent uses the Layer 2 unicast transmission method.

user@host# set layer2-unicast-replies

Documentation
Trusting Option 82 Information
By default, the DHCP relay agent treats client packets with a giaddr of 0 (zero) and
option 82 information as if the packets originated at an untrusted source, and drops them
without further processing. You can override this behavior and specify that the DHCP
relay agent process DHCP client packets that have a giaddr of 0 (zero) and contain
option 82 information.
To configure DHCP relay agent to trust option 82 information:

2. Specify that the DHCP relay agent process DHCP client packets with a giaddr of 0
and that contain option 82 information.

user@host# set trust-option-82

Documentation
Specifying the Maximum Number of DHCP Clients Per Interface
By default, there is no limit to the number of DHCP local server or DHCP relay clients
allowed on an interface. However, you can override the default setting and specify the
maximum number of clients allowed per interface, in the range 1 through 500,000. When
the number of clients on the interface reaches the specified limit, no additional DHCP
Discover PDUs or DHCPv6 Solicit PDUs are accepted. When the number of clients
subsequently drops below the limit, new clients are again accepted.

NOTE: The maximum number of DHCP (and DHCPv6) local server clients
or DHCP (and DHCPv6) relay clients can also be specified by Juniper Networks
VSA 26-143 during client login. The VSA-specified value always takes
precedence if the interface-client-limit statement specifies a different number.
If the VSA-specified value differs with each client login, DHCP uses the largest
limit set by the VSA until there are no clients on the interface.
To configure the maximum number of DHCP clients allowed per interface:

• For DHCPv6 local server:
[edit system services dhcp-local-server dhcpv6]

• For DHCP relay agent:

• For DHCPv6 relay agent:

2. Configure the maximum number of clients allowed per interface. (DHCP local server,
DHCPv6 local server, DHCP relay agent and DHCPv6 relay agent all support the
interface-client-limit statement.)

user@host# set interface-client-limit number
NOTE: For DHCP local server and DHCP relay agent, you can use either the
interface-client-limit statement or the client-discover-match incoming-interface
statement to set a limit of one client per interface. The interface-client-limit
statement with a value of 1 retains the existing client and rejects any new
client connections. The client-discover-match incoming-interface statement
deletes the existing client and allows a new client to connect.
Related • Overriding Default DHCP Local Server Configuration Settings

Documentation
• Allowing Only One DHCP Client Per Interface
• Extended DHCP Local Server Overview

• Extended DHCP Relay Agent Overview
Automatically Logging Out DHCP Clients
You can configure the extended DHCP local server and extended DHCP relay to
automatically log out DHCP clients. Auto logout immediately releases an existing client
when DHCP receives a discover packet from a client whose identity matches an existing
client. DHCP then releases the existing client IP address without waiting for the normal
lease expiration.
NOTE: When the existing client is released, the new client undergoes the
normal authentication process. The new client might not receive the same
IP address as the original client.
To configure DHCP client auto logout:


2. Enable auto logout and specify the secondary identification method you want to use
when the primary identification method is unsuccessful.
• For example, to configure DHCP local server to use the incoming interface method:

user@host# set client-discover-match incoming-interface
• For example, to configure DHCP relay agent to use the option 60 and option 82
method:

user@host# set client-discover-match option60-and-option82
NOTE: If you change the auto logout configuration, existing clients continue
to use the auto logout setting that was configured when they logged in. New
clients use the new setting.
Related • DHCP Auto Logout Overview

Documentation
• How DHCP Relay Agent Uses Option 82 for Auto Logout
• Allowing Only One DHCP Client Per Interface

• Extended DHCP Local Server Overview
• Extended DHCP Relay Agent Overview
Sending Release Messages When Clients Are Deleted
By default, when DHCP relay and relay proxy delete a client, they do not send a release
message to the DHCP server. You can override the default behavior and configure DHCP
relay and relay proxy to send a release message whenever they delete a client. The release
message sent by DHCP relay and relay proxy includes option 82 information.
NOTE: You must include the send-release-on-delete statement to configure

DHCP relay and relay proxy to send the release message when the
client-discover-match statement is included.
You can use the [edit forwarding-options dhcp-relay dhcpv6] hierarchy level to override
the default behavior for DHCPv6 relay agent.
To send a release message:

• For DHCPv6 relay agent:

2. Specify that you want DHCP relay and relay proxy (or DHCPv6 relay agent) to send
a release message when clients are deleted.

user@host# set send-release-on-delete

Documentation
Disabling Automatic Binding of Stray DHCP Requests
DHCP requests that are received but have no entry in the database are known as stray
requests. By default, DHCP relay, DHCP relay proxy, and DHCPv6 relay agent attempt
to bind the requesting client by creating a database entry and forwarding the request to
the DHCP server. If the server responds with an ACK, the client is bound and the ACK is
forwarded to the client. If the server responds with a NAK, the database entry is deleted

and the NAK is forwarded to the client. This behavior occurs regardless of whether
authentication is configured.
You can override the default configuration at the global level, for a named group of
interfaces, or for a specific interface within a named group. Overriding the default causes
DHCP relay, DHCP relay proxy, and DHCPv6 relay agent to drop all stray requests instead
of attempting to bind the clients.
NOTE: Automatic binding of stray requests is enabled by default.
• To disable automatic binding behavior, include the no-bind-on-request statement when

you configure DHCP overrides at the global, group, or interface level.

user@host# set no-bind-on-request
• To override the default behavior for DHCPv6 relay agent, configure the override at the
[edit forwarding-options dhcp-relay dhcpv6] hierarchy level.
[edit forwarding-options dhcp-relay dhcpv6 overrides]

The following two examples show a configuration that disables automatic binding of
stray requests for a group of interfaces and a configuration that disables automatic
binding on a specific interface.
To disable automatic binding of stray requests on a group of interfaces:
1. Specify the named group.

2. Specify that you want to configure overrides.
[edit forwarding-options dhcp-relay group boston]

3. Disable automatic binding for the group.
[edit forwarding-options dhcp-relay group boston overrides]

To disable automatic binding of stray requests on a specific interface:
1. Specify the named group of which the interface is a member.

2. Specify the interface on which you want to disable automatic binding.
[edit forwarding-options dhcp-relay group boston]

user@host# edit interface fe-1/0/1.2
3. Specify that you want to configure overrides.
[edit forwarding-options dhcp-relay group boston interface fe-1/0/1.2]

4. Disable automatic binding on the interface.
[edit forwarding-options dhcp-relay group boston interface fe-1/0/1.2 overrides]


Documentation
Using DHCP Relay Agent Option 82 Information
Subscriber management enables you to configure the DHCP relay agent to include
additional option 82 information in the DHCP packets that the relay agent receives from
clients and forwards to a DHCP server. The DHCP server uses the additional information
to determine the IP address to assign to the client. The server might also use the
information for other purposes—for example, to determine which services to grant the
client, or to provide additional security against threats such as address spoofing. The
DHCP server sends its reply back to the DHCP relay agent, and the agent removes the
option 82 information from the message and forwards the packet to the client.
To configure support for the DHCP relay agent information option 82, you use the
relay-option-82 statement. You can configure the DHCP relay agent to include the
following suboptions in the packet the relay agent sends to the DHCP server:
• Agent Circuit ID (suboption 1)—An ASCII string that identifies the interface on which
the client DHCP packet is received.
• Agent Remote ID (suboption 2)—An ASCII string assigned by the DHCP relay agent
that securely identifies the client.
You can configure the option 82 support globally or for a named group of interfaces.
To restore the default behavior, in which option 82 information is not inserted into DHCP
packets, you use the delete relay-option-82 statement.

NOTE: The DHCPv6 relay agent provides similar Agent Circuit ID and Agent
Remote ID support for DHCPv6 clients. For DHCPv6, subscriber management
uses DHCPv6 option 18 to include the circuit ID in the packets that the relay
agent sends to a DHCPv6 server, and option 37 to include the remote ID in
the packets. See DHCPv6 Relay Agent Options.
The following sections describe the option 82 operations you can configure:
• Configuring Option 82 Information on page 384

• Including a Prefix in DHCP Options on page 386
• Including a Textual Description in DHCP Options on page 388
Configuring Option 82 Information

You use the relay-option-82 statement to configure the DHCP relay agent to insert option
82 information in DHCP packets that the relay agent receives from clients and forwards
to a DHCP server. When you configure option 82, you can include one of the suboption
statements to specify the type of information you want to include in the DHCP packets.
If you configure option 82 without including one of the suboption statements, the Agent
Circuit ID option is included by default. Use the circuit-id statement to include the Agent
Circuit ID (suboption 1) in the packets, or the remote-id statement to include the Agent
Remote ID (suboption 2).
You can optionally configure DHCP relay agent to include a prefix or the interface
description as part of the suboption information. If you specify the circuit-id or remote-id
statement without including any of the optional prefix, use-interface-description,
use-vlan-id, include-irb-and-l2, or no-vlan-interface-name statements, the format of the
Agent Circuit ID or Agent Remote ID information for Fast Ethernet (fe), Gigabit Ethernet
(ge), and integrated routing and bridging (irb) interfaces is one of the following, depending
on your network configuration:
• For Fast Ethernet or Gigabit Ethernet interfaces that do not use VLANs, stacked VLANs
(S-VLANs), or bridge domains:
(fe | ge)-fpc/pic/port.subunit
NOTE: For remote systems, the subunit is required and is used to

differentiate an interface.
• For Fast Ethernet or Gigabit Ethernet interfaces that use VLANs:
(fe | ge)-fpc/pic/port:vlan-id
• For Fast Ethernet or Gigabit Ethernet interfaces that use S-VLANs:
(fe | ge)-fpc/pic/port:svlan-id-vlan-id

NOTE: Integrated routing and bridging (IRB) provides simultaneous support

for Layer 2 bridging and Layer 3 IP routing on the same interface. IRB enables
you to route local packets to another routed interface or to another bridging
domain that has a Layer 3 protocol configured.
The interface to bridge domain relationship might be implicit (the interface

is mapped to the bridge domain by the system based on the VLAN tag) or
explicit (the interface is mapped to the bridge domain by configuring it in the
bridge domain definition). For the explicit case, tagging might not be relevant
for the mapping.
In the case of an IRB interface, the format displays the Layer 2 interface instead of the
IRB interface along with the bridge domain name. For IRB interfaces (or other pseudo
devices) the default format is as follows:
• IRB interfaces that use bridge domains but do not use VLANs or S-VLANs:
(fe | ge)-fpc/pic/port.subunit:bridge-domain-name
• IRB interfaces that use VLANs:
(fe | ge)-fpc/pic/port.subunit:vlan-name
To include the IRB interface name with the Layer 2 interface name, configure the
include-irb-and-l2 statement. The format is as follows:
• IRB interfaces that use bridge domains but do not use VLANs or S-VLANs:
(fe | ge)-fpc/pic/port:bridge-domain-name+irb.subunit
• IRB interfaces that use VLANs:
(fe | ge)-fpc/pic/port:vlan-name+irb.subunit
To include only the IRB interface name without the Layer 2 interface and bridge domain
or VLAN, configure the no-vlan-interface-name statement. The format is as follows:
irb.subunit
To enable insertion of option 82 information:
1. Specify that you want to configure option 82 support.

user@host# edit relay-option-82
2. Configure the DHCP relay agent to insert the Agent Circuit ID suboption, the Agent
Remote ID suboption, or both.
• To insert the Agent Circuit ID:
[edit forwarding-options dhcp-relay relay-option-82]

user@host# set circuit-id
• To insert the Agent Remote ID:


user@host# set remote-id
• To insert both, configure both set commands.
3. (Optional) Configure a prefix that is used in the option 82 information in the DHCP
packets.
See “Including a Prefix in DHCP Options” on page 386.
4. (Optional) Configure the DHCP relay agent to include the interface’s textual description
instead of the interface identifier in the option 82 information.
See “Including a Textual Description in DHCP Options” on page 388.
Including a Prefix in DHCP Options

When you configure the DHCP relay agent to include DHCP options in the packets that
the relay agent sends to a DHCP server, you can specify that the relay agent add a prefix
to the DHCP option. You can add a prefix to the following DHCP options:
• DHCPv4 option 82 Agent Circuit ID (suboption 1)
• DHCPv4 option 82 Agent Remote ID (suboption 2)
• DHCPv6 option 18 Relay Agent Interface-ID
• DHCPv6 option 37 Relay Agent Remote-ID
The prefix is separated from the DHCP option information by a colon (:), and it can include
any combination of the host-name, logical-system-name, and routing-instance-name
options. The DHCP relay agent obtains the values for the host-name, logical-system-name,
and routing-instance-name as follows:
• If you include the host-name option, the DHCP relay agent uses the hostname of the
device configured with the host-name statement at the [edit system] hierarchy level.
• If you include the logical-system-name option, the DHCP relay agent uses the logical
system name configured with the logical-system statement at the [edit logical-system]
hierarchy level.
• If you include the routing-instance-name option, the DHCP relay agent uses the routing
instance name configured with the routing-instance statement at the [edit
routing-instances] hierarchy level or at the [edit logical-system logical-system-name
routing-instances] hierarchy level.
If you include the hostname and either or both of the logical system name and the routing
instance name in the prefix, the hostname is followed by a forward slash (/). If you include
both the logical system name and the routing instance name in the prefix, these values
are separated by a semicolon (;).

The following examples show several possible formats for the DHCP option information
when you specify the prefix statement for Fast Ethernet (fe) or Gigabit Ethernet (ge)
interfaces with S-VLANs.
• If you include only the hostname in the prefix for Fast Ethernet or Gigabit Ethernet
interfaces with S-VLANs:
hostname:(fe | ge)-fpc/pic/port:svlan-id-vlan-id
• If you include only the logical system name in the prefix for Fast Ethernet or Gigabit
Ethernet interfaces with S-VLANs:
logical-system-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-id
• If you include only the routing instance name in the prefix for Fast Ethernet or Gigabit
Ethernet interfaces with S-VLANs:
routing-instance-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-id
• If you include both the hostname and the logical system name in the prefix for Fast
Ethernet or Gigabit Ethernet interfaces with S-VLANs:
host-name/logical-system-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-id
• If you include both the logical system name and the routing instance name in the prefix
for Fast Ethernet or Gigabit Ethernet interfaces with S-VLANs:
logical-system-name;routing-instance-name:(fe | ge)-fpc/pic/port:svlan-id-vlan-id
• If you include the hostname, logical system name, and routing instance name in the
prefix for Fast Ethernet or Gigabit Ethernet interfaces with S-VLANs:
host-name/logical-system-name;routing-instance-name:(fe |
ge)-fpc/pic/port:svlan-id-vlan-id
For Fast Ethernet or Gigabit Ethernet interfaces that use VLANs but not S-VLANs, only
the vlan-id value appears in the DHCP option format.
(DHCPv4) To configure a prefix with the option 82 information:

2. Configure DHCP relay agent to insert the Agent Circuit ID, the Agent Remote ID, or
both.
• To configure the Agent Circuit ID:

user@host# edit circuit-id
• To configure the Agent Remote ID:

user@host# edit remote-id
3. Specify that the prefix be included in the option 82 information. In this example, the
prefix includes the hostname and logical system name.

• To include the prefix with the Agent Circuit ID:
[edit forwarding-options dhcp-relay relay-option-82 circuit-id]

user@host# set prefix host-name logical-system-name
• To include the prefix with the Agent Remote ID:
[edit forwarding-options dhcp-relay relay-option-82 remote-id]

(DHCPv6) To use a prefix with the DHCPv6 option 18 or option 37 information:
1. Specify that you want to configure DHCPv6 relay agent support.

user@host# edit dhcpv6
2. Configure DHCPv6 relay agent to insert option 18 (Relay Agent Interface-ID), option
37 (Relay Agent Remote-ID), or both.
• To configure option 18:


user@host# edit relay-agent-remote-id
3. Specify that the prefix is included in the option information. In this example, the prefix
includes the hostname and logical system name
• To include the prefix with option 18:

• To include the prefix with option 37:
[edit forwarding-options dhcp-relay dhcpv6 relay-agent-remote-id]

Including a Textual Description in DHCP Options

By default, when DHCP relay agent inserts option information in the packets sent to a
DHCP server, the options include the interface identifier. However, you can configure the
DHCP relay agent to include the textual description that is configured for the interface
instead of the interface identifier. You can use the textual description for either the logical
interface or the device interface.
You can include the textual interface description in the following DHCP options:
• DHCPv4 option 82 Agent Circuit ID (suboption 1)
• DHCPv4 option 82 Agent Remote ID (suboption 2)
• DHCPv6 option 18 Relay Agent Interface-ID
• DHCPv6 option 37 Relay Agent Remote-ID

The textual description is configured separately, using the description statement at the
[edit interfaces interface-name] hierarchy level. If you specify that the textual description
is used and no description is configured for the interface, DHCP relay defaults to using
the Layer 2 interface name.
In the case of integrated routing and bridging (IRB) interfaces, the textual description of
the Layer 2 interface is used instead of the textual description of the IRB interface. If there
is no description configured, the Layer 2 logical interface name is used.
NOTE: For IRB interfaces, the option 82 field must be able to uniquely identify
the incoming interface based on either the Agent Circuit ID or Agent Remote
ID . You can modify the information in the textual interface description to
match the raw IFD (physical interface without a subunit) name and configure
the option 82 field to use the interface description.
You can use the textual description with the following DHCP options:
• DHCPv4 Option 82 Agent Circuit ID (suboption 1)
• DHCPv4 Option 82 Agent Remote ID (suboption 2)
• DHCPv6 Relay Agent Interface-ID (option 18)
• DHCPv6 Relay Agent Remote-ID (option 37)
(DHCPv4) To configure the DHCP relay option 82 suboption to include the textual
interface description:

2. Configure DHCP relay agent to insert the Agent Circuit ID, Agent Remote ID, or both.

user@host# edit circuit-id
3. Specify that the textual description is included in the option 82 information. In this
example, the option 82 information includes the description used for the device
interface.
[edit forwarding-options dhcp-relay relay-option-82 circuit-id]

user@host# set use-interface-description device
(DHCPv6) To configure the DHCPv6 option 18 or option 37 to include the textual interface
description:
1. Specify that you want to configure DHCPv6 relay agent support.

user@host# edit dhcpv6

2. Configure DHCPv6 relay agent to insert option 18 (Relay Agent Interface-ID), option
37 (Relay Agent Remote-ID), or both.


user@host# edit relay-agent-remote-id
3. Specify that the textual description is included in the option information. In the
following example, the option information includes the description used for the device
interface.
• To include the textual description in option 18:

• To include the textual description in option 37:
[edit forwarding-options dhcp-relay dhcpv6 relay-agent-remote-id]

Using DHCP Option Information to Selectively Process DHCP Client Traffic
Starting in Junos OS Release 15.1, you can configure the DHCP relay agent to selectively
process client traffic. Selective processing uses DHCP or DHCPv6 option information to
identify, filter, and process client traffic. To configure DHCPv6 support you use the
procedure at the [edit forwarding-options dhcp-relay dhcpv6] hierarchy level.
To configure DHCP relay agent to use option information to selectively process DHCP
client traffic:
1. Specify that you want to configure DHCP relay agent support.
[edit forwarding-options]
user@host# edit dhcp-relay
2. Specify that you want to use the DHCP option feature to selectively process incoming
DHCP traffic.

user@host# edit relay-option
3. Specify the DHCP or DHCPv6 option number DHCP relay uses to identify and process
the client traffic. You can specify options 60 and 77 for DHCP relay agent, and options
15 and 16 for DHCPv6 relay agent.
[edit forwarding-options dhcp-relay relay-option]

user@host# set option-number option-number
For example, to identify traffic that has DHCP option 60 information:


user@host# set option-number 60
4. (Optional) Configure the default action that DHCP relay uses when the incoming
client traffic does not satisfy any configured match or partial match criteria.
For example, to configure DHCP relay to drop traffic by default:

user@host# set default-action drop
5. (Optional) Configure an exact match condition that filters the client traffic and specifies
the associated action for DHCP relay agent to take.
For example, to select traffic that has an option 60 (configured in the previous step)
ASCII string of video25, and then forward that traffic to a named local server group:

user@host# set equals ascii video25 local-server-group servergroup-east-video
6. (Optional) Configure a partial match condition that filters the client traffic and specifies
the associated action.
For example, to select traffic that has an option 60 hexadecimal string that starts
with 766964656F (left to right), and then forward that traffic without creating a new
session:

user@host# edit starts-with hexadecimal 766964656F forward-only
15.1 Starting in Junos OS Release 15.1, you can configure the DHCP relay agent
to selectively process client traffic.
Related • DHCP Options and Selective Traffic Processing Overview

Documentation
• Example: Configuring DHCP Relay Agent Selective Traffic Processing Based on DHCP
Option Strings
• Example: Configuring DHCP and DHCPv6 Relay Agent Group-Level Selective Traffic
Processing

Understanding DHCP Option 82 for Protecting Switching Devices Against Attacks
You can use DHCP option 82, also known as the DHCP relay agent information option,
to help protect Juniper Networks EX Series Ethernet Switches and MX Series 3D Universal
Edge Routers against attacks such as spoofing (forging) of IP addresses and MAC
addresses, and DHCP IP address starvation. Hosts on untrusted access interfaces on an
Ethernet LAN switching device send requests for IP addresses to access the Internet. The
switching device forwards or relays these requests to DHCP servers, and the servers send
offers for IP address leases in response. Attackers can use these messages to penetrate
the network by address spoofing.
Option 82 provides information about the network location of a DHCP client, and the
DHCP server uses this information to implement IP addresses or other parameters for
the client. The Junos OS implementation of DHCP option 82 supports RFC 3046, DHCP
Relay Agent Information Option, at http://tools.ietf.org/html/rfc3046.
This topic covers:
• DHCP Option 82 Overview on page 392

• Suboption Components of Option 82 on page 393
• Switching Device Configurations That Support Option 82 on page 394
• DHCPv6 Options on page 395
DHCP Option 82 Overview

If DHCP option 82 is enabled on a VLAN or bridge domain, then when a network device—a
DHCP client—that is connected to the VLAN or bridge domain on an untrusted interface
sends a DHCP request, the switching device inserts information about the client's network
location into the packet header of that request. The switching device then sends the
request to the DHCP server. The DHCP server reads the option 82 information in the
packet header and uses it to implement the IP address or another parameter for the
client. See “Suboption Components of Option 82” on page 393 for more information about
option 82.
NOTE: On EX4300 switches, DHCP option 82 information is added to DHCP

packets received on trusted interfaces as well as untrusted interfaces.
If option 82 is enabled on a VLAN or bridge domain, the following sequence of events

occurs when a DHCP client sends a DHCP request:
1. The switching device receives the request and inserts the option 82 information in the
packet header.
2. The switching device forwards (or relays) the request to the DHCP server.
3. The server uses the DHCP option 82 information to formulate its reply and sends a
response to the switching device. It does not alter the option 82 information.

4. The switching device strips the option 82 information from the response packet.
5. The switching device forwards the response packet to the client.
To use the DHCP option 82 feature, you must ensure that the DHCP server is configured
to accept option 82. If the DHCP server is not configured to accept option 82, then when
it receives requests containing option 82 information, it does not use the information for
setting parameters and it does not echo the information in its response message.
NOTE: If your switching device is an EX Series switch and uses Junos OS with
Enhanced Layer 2 Software (ELS) configuration style, you can enable DHCP
option 82 only for a specific VLAN. See Setting Up DHCP Option 82 on the
Switch with No Relay Agent Between Clients and DHCP Server (CLI Procedure).
If your switching device is an EX Series switch and does not use Junos OS
with Enhanced Layer 2 Software (ELS) configuration style, you can enable
DHCP option 82 either for a specific VLAN or for all VLANs. See Setting Up
DHCP Option 82 on the Switch with No Relay Agent Between Clients and DHCP
Server (CLI Procedure).
Suboption Components of Option 82

Option 82 as implemented on a switching device comprises the suboptions circuit ID,
remote ID, and vendor ID. These suboptions are fields in the packet header:
• circuit ID—Identifies the circuit (interface or VLAN) on the switching device on which
the request was received. The circuit ID contains the interface name and VLAN name,
with the two elements separated by a colon—for example, ge-0/0/10:vlan1, where
ge-0/0/10 is the interface name and vlan1 is the VLAN name. If the request packet is
received on a Layer 3 interface, the circuit ID is just the interface name—for example,
ge-0/0/10.
Use the prefix option to add an optional prefix to the circuit ID. If you enable the prefix
option, the hostname for the switching device is used as the prefix; for example,
device1:ge-0/0/10:vlan1, where device1 is the hostname.
You can also specify that the interface description be used rather than the interface
name or that the VLAN ID be used rather than the VLAN name.
• remote ID—Identifies the remote host. See remote-id for details.
• vendor ID—Identifies the vendor of the host. If you specify the vendor-id option but do
not enter a value, the default value Juniper is used. To specify a value, you type a
character string.

Switching Device Configurations That Support Option 82

Switching device configurations that support option 82 are:
• Switching Device, DHCP Clients, and the DHCP Server Are on the Same VLAN or Bridge
Domain on page 394
• Switching Device Acts as a Relay Agent on page 394
Switching Device, DHCP Clients, and the DHCP Server Are on the Same VLAN or
Bridge Domain
If the switching device, the DHCP clients, and the DHCP server are all on the same VLAN
or bridge domain, the switching device forwards the requests from the clients on untrusted
access interfaces to the server on a trusted interface. See Figure 22 on page 394.
Figure 22: DHCP Clients, Switching Device, and the DHCP Server Are All
on the Same VLAN or Bridge Domain
Switching Device Acts as a Relay Agent
The switching device functions as a relay agent (extended relay server) when the DHCP
clients or the DHCP server is connected to the switching device through a Layer 3 interface.
On the switching device, these interfaces are configured as routed VLAN interfaces (RVIs).
Figure 23 on page 395 illustrates a scenario for the switching device acting as an extended
relay server; in this instance, the switching device relays requests to the server. This figure
shows the relay agent and server on the same network, but they can also be on different
networks–that is, the relay agent can be external.

Figure 23: Switching Device Acting as an Extended Relay Server
DHCPv6 Options
NOTE: MX Series routers do not support DHCPv6.
DHCPv6 provides several options that can be used to insert information into the DHCPv6
request packets that are relayed to a server from a client. These options are equivalent
to the sub-options of DHCP option 82.
• Option 37—Identifies the remote host. Option 37 is equivalent to the remote-id

sub-option of DHCP option 82.
• Option 18—Identifies the interface on which the DHCP request packet was received
from the client. Option 18 is equivalent to the circuit-id sub-option of DHCP option 82.
• Option 16—Identifies the vendor of the hardware on which the client is hosted. Option
16 is equivalent to the vendor-id sub-option of DHCP option 82.
DHCPv6 options are not enabled automatically when DHCPv6 snooping is enabled on
a VLAN. They must be configured using the dhcpv6-options statement.
Related • Configuring DHCP Option 82 to Help Protect the Switching Devices Against Attacks
Documentation (CLI Procedure) on page 396
• Setting Up DHCP Option 82 on the Switch with No Relay Agent Between Clients and
DHCP Server (CLI Procedure)

Configuring DHCP Option 82 to Help Protect the Switching Devices Against Attacks
(CLI Procedure)
You can use DHCP option 82, also known as the DHCP relay agent information option,
to help protect the switching device against attacks such as spoofing (forging) of IP
addresses and MAC addresses, and DHCP IP address starvation. Option 82 provides
information about the network location of a DHCP client, and the DHCP server uses this
information to implement IP addresses or other parameters for the client.
You can configure the DHCP option 82 feature in two topologies:
• The switching device, DHCP clients, and DHCP server are all on the same bridge domain.
The switching device forwards the clients' requests to the server and forwards the
server's responses to the clients. This topic describes this configuration.
• The switching device functions as a relay agent when the DHCP clients or the DHCP
server are connected to the switching device through a Layer 3 interface. On the
switching device, these interfaces are configured as integrated routing and bridging
(IRB) interfaces. The switching device relays the clients' requests to the server and
then forwards the server's responses to the clients.
Before you configure DHCP option 82 on the switching device, perform these tasks:
• Connect and configure the DHCP server.
NOTE: Your DHCP server must be configured to accept DHCP option 82.
If the server is not configured for DHCP option 82, the server does not use
the DHCP option 82 information in the requests sent to it when it formulates
its reply messages.
• Configure a bridge domain on the switching device and associate the interfaces on
which the clients and the server connect, to the switch with that bridge domain.
To configure DHCP option 82:
1. Specify DHCP option 82 for the bridge domain that you configured:
[edit bridge-domains bridge-domain-name forwarding-options dhcp-security]

user@device# set option-82
NOTE: If you want to enable DHCP option 82 on all bridge domains, you
must configure it separately for each specific bridge domain.
The remaining steps are optional.
2. Configure the prefix for the circuit ID suboption to include the hostname or the routing
instance name for the bridge domain:

[edit bridge-domains bridge-domain-name forwarding-options dhcp-security

option-82]
user@device# set circuit-id prefix (host-name | routing-instance-name)
3. Specify that the circuit ID suboption value contains the interface description rather
than the interface name (the default):

option-82]
user@device# set circuit-id use-interface-description
4. Specify that the circuit ID suboption value contains the VLAN ID rather than the VLAN
name (the default):

option-82]
user@device# set circuit-id use-vlan-id
5. Specify that the remote ID suboption is included in the DHCP option 82 information:

option-82]
user@device# set remote-id
NOTE: If you do not specify a keyword after remote-id, the default value
for the remote-id suboption is the interface name.
6. Specify that the remote ID suboption is the hostname of the switch:

option-82]
user@device# set remote-id host-name
7. Specify that the remote ID suboption value contains the interface description:

option-82]
user@device# set remote-id use-interface-description
8. Specify that the remote ID suboption value contains a character string:

option-82]
user@device# set remote-id use-string mystring
9. Configure a vendor ID suboption:
• To use the default value (the default value is Juniper), do not type a character string
after the vendor-id option keyword:

option-82]
user@device# set vendor-id

• To configure it so that the vendor ID suboption value contains a character string

value that you specify rather than Juniper (the default):

option-82]
user@device# set vendor-id use-string mystring
Related • Understanding DHCP Option 82 for Protecting Switching Devices Against Attacks on
Documentation page 392
• Understanding DHCP Snooping for Monitoring DHCP Messages Received from Untrusted
Devices
Configuring Named Server Groups
You can configure a named group of DHCP servers for use by the extended DHCP relay
agent on the router or switch.
You specify the name of the DHCP server group and the IP addresses of one or more
DHCP servers that belong to this group. You can configure a maximum of five IP addresses
per named server group.
To configure a named server group:
1. Specify the name of the server group.

user@host# set server-group myServerGroup
2. Add the IP addresses of the DHCP servers belonging to the group.
[edit forwarding-options dhcp-relay server-group myServerGroup]

user@host# set 192.168.100.50
user@host# set 192.168.100.75

Documentation
Configuring Active Server Groups to Apply a Common DHCP Relay Agent Configuration
to Named Server Groups
You can configure an active server group. Using an active server group enables you to
apply a common DHCP relay agent configuration to a named group of DHCP server
addresses.
Use the statement at the [edit ... dhcpv6] hierarchy levels to configure DHCPv6 support.
To configure an active server group:
• Specify the name of the active server group.


user@host# set active-server-group myServerGroup
To create an active server group as a global DHCP relay agent configuration option,
include the active-server-group statement at the [edit forwarding-options dhcp-relay]
hierarchy level. To have the group apply only to a named group of interfaces, include the
active-server-group statement at the [edit forwarding-options dhcp-relay group
Including the active-server-group statement at the [edit forwarding-options dhcp-relay

group group-name] hierarchy level (as a group-specific option) overrides the effect of
including the active-server-group statement at the [edit forwarding-options dhcp-relay]
hierarchy level as a global option.

Documentation
• Grouping Interfaces with Common DHCP Configurations
Disabling DHCP Relay
You can disable DHCP relay on all interfaces or a group of interfaces.
To disable DHCP relay agent:

2. Disable the DHCP relay agent.

user@host# set disable-relay

Documentation


PART 5
Configuring Protocols on ACX Series

Routers
• Configuring Layer 2 Control Protocol on page 403
• Configuring Layer 2 Protocol Tunneling on page 437
• Configuring Internet Group Management Protocol on page 445
• Configuring Internet Group Management Protocol Snooping on page 473
• Configuring Point-to-Point Protocol (PPP) on page 489
• Configuring MLPPP on page 507
• Configuring Routing Protocols on page 529
• Configuring Generic Routing Encapsulation on page 581
• Configuring MPLS and Pseudowires on page 587
• Configuring Virtual Router Redundancy Protocol (VRRP) on page 651
• Configuring Multicast Listener Discovery and Protocol-Independent Multicast on page 669
• Configuring Path Computation Element Protocol (PCEP) on page 691


CHAPTER 12
Configuring Layer 2 Control Protocol
• Layer 2 Control Protocol on ACX Series Routers on page 404

• Bridge Priority for Election of Root Bridge and Designated Bridge on page 406
• Maximum Age for Awaiting Arrival of Hello BPDUs on page 406
• Hello Time for Root Bridge to Transmit Hello BPDUs on page 407
• Forward Delay Before Ports Transition to Forwarding State on page 407
• Spanning-Tree Instance Interface on page 407
• Spanning-Tree Instance Interface Priority on page 408
• Spanning-Tree Instance Interface Cost on page 408
• Spanning-Tree Instance Interface Point-to-Point Link Mode on page 409
• Configuring a Spanning-Tree Instance Interface as an Edge Port for Faster
Convergence on page 409
• Spanning-Tree Protocol Trace Options on page 410
• Configuring Rapid Spanning-Tree Protocol on page 411
• Configuring Multiple Spanning-Tree Protocol on page 413
• Configuring MST Instances on a Physical Interface on page 415
• Disabling MSTP on page 417
• Configuring VLAN Spanning-Tree Protocol on page 417
• RSTP or VSTP Forced to Run as IEEE 802.1D STP on page 420
• Reverting RSTP or VSTP from Forced IEEE 802.1D STP on page 420
• Tracing Spanning-Tree Operations on page 421
• Understanding BPDU Protection for Spanning-Tree Instance Interfaces on page 423
• Configuring BPDU Protection for Spanning-Tree Instance Interfaces on page 424
• Configuring BPDU Protection on All Edge Ports on page 425
• Understanding Loop Protection for Spanning-Tree Instance Interfaces on page 426
• Loop Protection for a Spanning-Tree Instance Interface on page 427
• Configuring Loop Protection for a Spanning-Tree Instance Interface on page 428
• Example: Enabling Loop Protection for Spanning-Tree Protocols on page 429

• Understanding Root Protection for Spanning-Tree Instance Interfaces in a Layer 2

Switched Network on page 429
• Root Protect for a Spanning-Tree Instance Interface on page 430
• Enabling Root Protection for a Spanning-Tree Instance Interface on page 430
• LLDP Overview on page 431
• Configuring LLDP in ACX Series on page 432
• LLDP Operational Mode Commands on page 434
Layer 2 Control Protocol on ACX Series Routers
On ACX Series routers in a Layer 2 environment, you can configure various spanning-tree
protocol versions to create a loop-free topology in Layer 2 networks.
A spanning-tree protocol is a Layer 2 control protocol (L2CP) that calculates the best
path through a switched network containing redundant paths. A spanning-tree protocol
uses bridge protocol data unit (BPDU) data frames to exchange information with other
switches. A spanning-tree protocol uses the information provided by the BPDUs to elect
a root bridge, identify root ports for each switch, identify designated ports for each physical
LAN segment, and prune specific redundant links to create a loop-free tree topology.
The resulting tree topology provides a single active Layer 2 data path between any two
end stations.
NOTE: In discussions of spanning-tree protocols, the terms bridge and switch

are often used interchangeably.
The ACX Series Universal Access Routers support Spanning-Tree Protocol (STP), Rapid
Spanning-Tree Protocol (RSTP), Multiple Spanning-Tree Protocol (MSTP), and VLAN
Spanning-Tree Protocol (VSTP).
• The original STP is defined in the IEEE 802.1D 1998 specification. A newer version called
RSTP was originally defined in the IEEE 802.1w draft specification and later incorporated
into the IEEE 802.1D-2004 specification. A recent version called MSTP was originally
defined in the IEEE 802.1s draft specification and later incorporated into the
IEEE 802.1Q-2003 specification. The VSTP is compatible with the Per-VLAN Spanning
Tree Plus (PVST+) and Rapid-PVST+ protocols supported on Cisco Systems routers
and switches.
• RSTP provides faster reconvergence time than the original STP by identifying certain
links as point to point and by using protocol handshake messages rather than fixed
timeouts. When a point-to-point link fails, the alternate link can transition to the
forwarding state without waiting for any protocol timers to expire.
• MSTP provides the capability to logically divide a Layer 2 network into regions. Every
region has a unique identifier and can contain multiple instances of spanning trees. All
regions are bound together using a Common Instance Spanning Tree (CIST), which is
responsible for creating a loop-free topology across regions, whereas the Multiple

Chapter 12: Configuring Layer 2 Control Protocol
Spanning-Tree Instance (MSTI) controls topology within regions. MSTP uses RSTP as
a converging algorithm and is fully interoperable with earlier versions of STP.
• VSTP maintains a separate spanning-tree instance for each VLAN. Different VLANs
can use different spanning-tree paths. When different VLANs use different
spanning-tree paths, the CPU processing resources being consumed increase as more
VLANs are configured. VSTP BPDU packets are tagged with the corresponding VLAN
identifier and are transmitted to the multicast destination media access control (MAC)
address 01-00-0c-cc-cc-cd with a protocol type of 0x010b. VSTP BPDUs are tunneled
by pure IEEE 802.1q bridges.
ACX Series routers can support up to 128 STP instances, which includes all instances of
VSTP, MSTP, RSTP and STP.
• Maximum number of VSTP instances supported is 128.
• Maximum number of MSTP instances supported is 64.
• Maximum number of RSTP instances supported is 1.
• Maximum number of STP instances supported is 1.
The ACX Series routers supports enabling Spanning-Tree Protocol (STP), Rapid
Spanning-Tree Protocol (RSTP), Multiple Spanning-Tree Protocol (MSTP), and VLAN
Spanning-Tree Protocol (VSTP) on aggregated Ethernet interface .
For more information about the various versions of spanning-tree protocols, see the
appropriate IEEE specification.
Related • Layer 2 Protocol Tunneling on ACX Series Overview on page 437

Documentation
• Bridge Priority for Election of Root Bridge and Designated Bridge on page 406
• Spanning-Tree Instance Interface on page 407
• Spanning-Tree Instance Interface Priority on page 408
• Spanning-Tree Instance Interface Cost on page 408
• Spanning-Tree Instance Interface Point-to-Point Link Mode on page 409
• Configuring a Spanning-Tree Instance Interface as an Edge Port for Faster Convergence

on page 409
• Spanning-Tree Protocol Trace Options on page 410

Bridge Priority for Election of Root Bridge and Designated Bridge
Use the bridge priority to control which bridge is elected as the root bridge and also to
control which bridge is elected the root bridge when the initial root bridge fails.
The root bridge for each spanning-tree protocol instance is determined by the bridge ID.
The bridge ID consists of a configurable bridge priority and the MAC address of the bridge.
The bridge with the lowest bridge ID is elected as the root bridge. If the bridge priorities
are equal or if the bridge priority is not configured, the bridge with the lowest MAC address
is elected the root bridge.
The bridge priority can also be used to determine which bridge becomes the designated
bridge for a LAN segment. If two bridges have the same path cost to the root bridge, the
bridge with the lowest bridge ID becomes the designated bridge.
The bridge priority can be set only in increments of 4096.
Consider a sample scenario in which a dual-homed customer edge (CE) router is

connected to two other provider edge (PE) routers, which function as the VPLS PE routers,
with MTSP enabled on all these routers, and with the CE router operating as the root
bridge. Integrated Routing and Bridging (IRB) interface is configured for the VPLS routing
instances on the routers. In such a network, the MAC addresses that are learned in the
VPLS domain continuously move between the LSI or virtual tunnel (VT) interfaces and
the VPLS interfaces on both the PE routers. To avoid the continuous movement of the
MAC addresses, you must configure root protection by including the no-root-port
statement at the [edit routing-instances routing-instance-name protocols mstp interface
interface-name] hierarchy level and configure the bridge priority as zero by including the
bridge priority 0 statement at the [edit routing-instances routing-instance-name protocols
mstp] hierarchy level on the PE routers. This configuration on the PE routers is required
to prevent the CE-side facing interfaces from becoming the root bridge.
Related • Configuring Rapid Spanning Tree Protocol

Documentation
• Configuring Multiple Spanning Tree Protocol
• Configuring VLAN Spanning Tree Protocol
• bridge-priority
Maximum Age for Awaiting Arrival of Hello BPDUs
The maximum age timer specifies the maximum expected arrival time of hello BPDUs.
If the maximum age timer expires, the bridge detects that the link to the root bridge has
failed and initiates a topology reconvergence. The maximum age timer should be longer
than the configured hello timer.

Documentation

• max-age
Hello Time for Root Bridge to Transmit Hello BPDUs
The hello timer specifies the time interval at which the root bridge transmits configuration
BPDUs.

Documentation
• hello-time
Forward Delay Before Ports Transition to Forwarding State
The forwarding delay timer specifies the length of time a spanning-tree protocol bridge
port remains in the listening and learning states before transitioning to the forwarding
state. Setting the interval too short could cause unnecessary spanning-tree reconvergence.
Before changing this parameter, you should have a thorough understanding of
spanning-tree protocols.

Documentation
• forward-delay
Spanning-Tree Instance Interface
STP and RSTP are limited to a single instance on any physical interface. Use the interface
statement to configure which interfaces participate in the STP or RSTP instance.
MSTP supports multiple instances on a single physical interface. Use the interface
statement to configure which logical interfaces participate in MSTP.
For VSTP, interfaces can be configured at the global level or at the VLAN level. Interfaces
configured at the global VSTP level will be enabled for all the configured VLANs. If an
interface is configured at both the global and VLAN levels, the configuration at the VLAN
level overrides the global configuration.

Documentation

• cost
• edge
• interface (Spanning Tree)
• mode
• priority
Spanning-Tree Instance Interface Priority
The root port is the interface on the nonroot bridge with the lowest path cost to the root
bridge. When multiple interfaces have the same path cost to the root bridge, the interface
with the lowest interface priority is selected as the root port.
If the interface priority is not configured and multiple interfaces have the same path cost
to the root bridge, the interface with the lowest interface identifier is selected as the root
port.
If the interface priority is configured under the MSTP protocol, this becomes the default
value for all interfaces. If the interface priority is configured under the MSTI interface, the
value overrides the default for that interface.
If the interface priority is configured at both the VSTP global and VLAN levels, the
configuration at the VLAN level overrides the global configuration.

Documentation
• priority
Spanning-Tree Instance Interface Cost
The path cost used to calculate the root path cost from any given LAN segment is
determined by the total cost of each link in the path. By default, the link cost is determined
by the speed of the link. The interface cost can be configured to override the default cost
and control which bridge is the designated bridge and which port is the designated port.
In MSTP the CIST external path cost is determined by the link speed and the number of
hops.
If the interface cost is not configured, the cost is determined by the speed of the interface.
For example, a 100-Mbps link has a default path cost of 19, a 1000-Mbps link has a default
path cost of 4, and a 10-Gbps link has a default path cost of 2.

If the interface cost is configured under MSTP, this becomes the default value for all
interfaces. If the interface cost is configured under the MSTI interface, the value overrides
the default for that interface.
If the interface cost is configured at both the VSTP global and VLAN levels, the
The interface cost should be set the same for all interfaces connected to the same LAN
segment.

Documentation
• cost
Spanning-Tree Instance Interface Point-to-Point Link Mode
The interface mode allows RSTP, MSTP, and VSTP to converge faster than the original
STP on point-to-point links. The protocol does not need to wait for timers on
point-to-point links. Configure interfaces that have a point-to-point link to another Layer 2
bridge as p2p. This parameter is ignored if the STP is configured to run the original
spanning-tree version.
If the interface mode is configured at both the VSTP global and VLAN levels, the

Documentation
• mode
Configuring a Spanning-Tree Instance Interface as an Edge Port for Faster Convergence
RSTP, MSTP, and VSTP instance interfaces configured as edge ports enable the protocol
to converge faster than the original IEEE 802.1D STP version. Edge ports transition directly
to the forwarding state, and so the protocol does not need to wait for BPDUs to be
received on edge ports.
The Junos OS supports automatic detection of edge ports as described in the RSTP
standard. Layer 2 bridges do not expect to receive BPDUs for edge ports. If a BPDU is
received for an edge port, the port becomes a non-edge port.

Keep the following guidelines in mind when configuring spanning-tree instance interfaces
as edge ports:
• Do not configure a spanning-tree instance interface as an edge port if it is connected

to any Layer 2 bridge. An instance interface connected to Layer 2 bridges but configured
as an edge port can cause physical loops.
• if the spanning-tree protocol is configured to run the original IEEE 802.1D spanning-tree
version, the edge-port option (if configured) is ignored.
• If edge ports are configured at both the VSTP global and VLAN levels, the configuration
at the VLAN level overrides the global configuration.
Related • Example: Configuring BPDU Protection on Edge Interfaces to Prevent STP Miscalculations
Documentation
• Configuring Rapid Spanning Tree Protocol
• edge
• Configuring RSTP (CLI Procedure)
• Configuring MSTP
Spanning-Tree Protocol Trace Options
In order to trace spanning-tree protocol operations, you can set spanning-tree

protocol-specific trace options in the spanning-tree protocol configuration.
For general information about tracing and global tracing options, see the statement
summary for the global traceoptions statement in the Junos OS Routing Protocols Library.

Documentation
• Example: Tracing Spanning-Tree Protocol Operations
• traceoptions (Spanning Tree)

Configuring Rapid Spanning-Tree Protocol
You can configure Rapid Spanning-Tree Protocol (RSTP) under the following hierarchy
level:
• [edit protocols]
To configure the Rapid Spanning-Tree Protocol:
1. Enable RSTP as the version of spanning-tree protocol to be configured:
[edit]
user@host@ edit ... protocols rstp
2. Configure the interfaces that participate in the RSTP instance.
a. Enable configuration of the interface:
[edit ... protocols rstp]

b. Configure the interface priority:
[edit ... protocols rstp interface interface-name]

user@host# set priority interface-priority
c. (Optional) By default, the interface link cost is determined by the link speed. You
can configure the interface link cost to control which bridge is the designated bridge
and which port is the designated port:

user@host# set cost interface-link-cost
d. (Optional) Configure the interface as an edge port:

user@host# set edge
Edge ports do not expect to receive bridge protocol data unit (BPDU) packets. If
a BPDU packet is received for an edge port, the port becomes a nonedge port
3. Configure the bridge priority

user@host# set bridge-priority bridge-priority
For more information, see “Bridge Priority for Election of Root Bridge and Designated
Bridge” on page 406.

4. Configure hello BPDU timers.
a. Configure the maximum expected arrival time of hello BPDUs:

user@host# set max-age seconds
b. Configure the time interval at which the root bridge transmits configuration BPDUs:

user@host# set hello-time seconds
5. (Optional) By default, the bridge port remains in the listening and learning states for
15 seconds before transitioning to the forwarding state. You can specify a delay from
4 through 20 seconds instead:

user@host# set forward-delay seconds
6. Verify the RSTP configuration:
[edit]
protocols {
rstp {
force-version stp; # Optional.
bpdu-destination-mac-address provider-bridge-group; # Optional
extended-system-id identifier; # Optional.
interface interface-name {
priority interface-priority;
cost interface-link-cost; # Optional.
mode (p2p | shared);
edge; # Optional.
}
bridge-priority bridge-priority;
max-age seconds;
hello-time seconds;
forward-delay seconds; # Optional.
}
}
}
Related • Layer 2 Control Protocol on ACX Series Routers on page 404

Documentation

Configuring Multiple Spanning-Tree Protocol
You can configure the Multiple Spanning-Tree Protocol (MSTP) under the following
hierarchy level:
To configure the Multiple Spanning-Tree Protocol:
1. Enable RSTP as the version of spanning-tree protocol to be configured:
[edit]
user@host@ edit ... protocols mstp
2. Configure the interfaces that participate in the MSTP instance.
[edit ... protocols mstp]

[edit ... protocols mstp interface interface-name]

c. (Optional) By default, the interface link cost is determined by the link speed. You
can configure the interface link cost to control which bridge is the designated bridge
and which port is the designated port:

user@host# set cost interface-link-cost
d. (Optional) Configure the interface as an edge port:

user@host# set edge





6. Configure MSTP-specific options.
a. Configure the MSTP region configuration name:

user@host# set configuration-name configuration-name
b. Configure the MSTP revision level:

user@host# set revision-levelrevision-level revision-level
c. Configure the maximum number of hops a BPDU can be forwarded in the MSTP
region:

user@host# set max-hops hops
7. Verify the MSTP configuration:
[edit]
protocols {
mstp {
bpdu-destination-mac-address provider-bridge-group; # Optional
edge; # Optional.
}
max-age seconds;
hello-time seconds;
configuration-name configuration-name; # MST region configuration name.
revision-level revision-level; # MST revision number.
max-hops hops; # MST maximum hops.

}
}
}

Documentation
Configuring MST Instances on a Physical Interface
You can configure a Multiple Spanning-Tree Instance (MSTI) under the following hierarchy
levels:
• [edit protocols mstp]
Before you begin, configure Multiple Spanning-Tree Protocol. For configuration details,
see “Configuring MSTP” on page 413.
1. Enable configuration of a MST instance:
[edit]
user@host# edit ... protocols mstp msti msti-id
The msti-id value must be from 1 through 64.
2. Configure the interfaces that participate in the MST instance.
[edit ... protocols mstp msti msti-id]

[edit ... protocols mstp msti msti-id interface interface-name]

c. (Optional) Configure the interface as an edge port:
[edit ... protocols mstp msti msti-id interface interface-name]

user@host# set edge
[edit ... protocols mstp msti msti-id]


4. (Optional) An MSTI can map to a range of VLANs just as a logical port can map to a
range of VLANs. The MSTP VLAN specifies the VLAN or VLAN range to which this
MSTI is mapped. The vlan-id is configured under the logical interface. Configure the
VLAN or VLAN range of the MSTI instance:
[edit]
user@host# set vlan (vlan-id | vlan-id-range)
5. Verify the MST interface configuration.
[edit]
protocols {
mstp {
...basic-mstp-configuration...
msti msti-id { # Instance identifier 1 – 64.
bridge-priority priority;
vlan vlan-id; # Optional
cost cost;
edge;
}
}
}
}
NOTE: All STP ports on a bridge domain must belong to the same MST
(multiple spanning tree) instance.

Documentation

Disabling MSTP
To disable the entire MSTP instance:
• Include the disable statement. You can include this statement at the following hierarchy
levels:
• [edit protocols mstp]

Documentation
Configuring VLAN Spanning-Tree Protocol
You can configure the VLAN Spanning-Tree Protocol (VSTP) under the following hierarchy
level:
To configure the VLAN Spanning-Tree Protocol:
1. Enable VSTP as the version of spanning-tree protocol to be configured:
[edit]
user@host@ edit ... protocols vstp
2. (Optional) For compatibility with older bridges that do not support VSTP, you can run
force VSTP to run as the original IEEE 802.1D Spanning-Tree Protocol (STP) version:
[edit ... protocols vstp]

user@host# set force-version stp
NOTE: If VSTP has been forced to run as the original STP version, you can
revert back to VSTP by first removing the force-version statement from
the configuration and then entering the clear spanning-tree
protocol-migration configuration mode command.

3. Configure the interfaces that participate in the VSTP instance.

[edit ... protocols vstp interface interface-name]

[edit ... protocols vstp interface interface-name]

user@host# set edge
4. Enable configuration of a VLAN instance:

user@host# edit vlan vlan-id
[edit ... protocols vstp vlan vlan-id]





8. Configure the interfaces that participate in the VSTP instance.

[edit ... protocols vstp vlan vlan-id interface interface-name]

[edit ... protocols vstp vlan vlan-id interface interface-name]

user@host# set edge
9. Verify the VSTP configuration:
[edit]
protocols {
vstp {
force-version stp; # Optional.
edge; # Optional.
}
vlan vlan-id {
max-age seconds;
hello-time seconds;
edge; # Optional.
}
}
}
}
}

Documentation

RSTP or VSTP Forced to Run as IEEE 802.1D STP
In a Layer 2 environment, you can force the configured Rapid Spanning-Tree Protocol
(RSTP) or VLAN Spanning-Tree Protocol (VSTP) to run as the original IEEE 802.1D
Spanning-Tree Protocol (STP) version. Configure this option for compatibility with older
bridges that do not support RSTP or VSTP.
To configure RSTP or VSTP to run as IEEE 802.1D STP, you need to add force-version
statement to the RSTP or VSTP configuration:
user@host #set force-version
Keep the following limitations in mind when RSTP or VSTP are run as the original STP
version:
• If you configure an instance interface as an edge port, the configuration statement is

ignored.
• If you configure point-to-point link mode for an instance interface, the configuration
statement is ignored.

Documentation
• Reverting RSTP or VSTP from Forced IEEE 802.1D STP on page 420
• force-version
Reverting RSTP or VSTP from Forced IEEE 802.1D STP
On ACX Series routers on which Rapid Spanning-Tree Protocol (RSTP) or VLAN

Spanning-Tree Protocol (VSTP) has been forced to run as the original IEEE 802.1D
Spanning-Tree Protocol (STP) version, you can revert to RSTP or VSTP.
To revert from the forced instance of the original IEEE 802.1D STP version to the configured
RSTP or VSTP version:
1. Remove the force-version statement from the RSTP or VSTP configuration:
user@host# delete force-version
Include this statement under the RSTP or VSTP hierarchy level:
• [edit protocols rstp]
• [edit protocols vstp]
• [edit routing-instances routing-instance-name protocols rstp]
• [edit routing-instances routing-instance-name protocols vstp]

2. Revert the forced IEEE 802.1D STP to run as the configured RSTP or VSTP:
user@host# clear spanning-tree protocol-migration <interface interface-name>

<routing-instance routing-instance-name>
To revert the STP protocol for the specified interface only, specify the
interface interface-name option.
To revert the STP protocol for a particular routing instance only, specify the
routing-instance routing-instance-name option.

Documentation
• RSTP or VSTP Forced to Run as IEEE 802.1D STP on page 420
• force-version
Tracing Spanning-Tree Operations
You can enable global routing protocol tracing options at the [edit routing-options]
Hierarchy Level. For general information about tracing and global tracing options, see the
statement summary for the global traceoptions statement in the Junos OS Routing
Protocols Library.
In addition, you can enable STP-specific trace options at the following hierarchy levels:
• [edit protocols (mstp | rstp | vstp)]
To enable tracing of spanning-tree protocol operations:
1. Enable configuration of the spanning-tree protocol whose operations are to be traced:
[edit]
user@host# edit ... protocols (mstp | rstp | vstp)
2. Enable configuration of spanning-tree protocol-specific trace options:
[edit ... protocols (mstp | rstp | vstp)]

user@host# edit traceoptions
3. Configure the files that contain trace logging information:

user@host# set file filename <files number> <size bytes>
<world-readable | no-world-readable>

4. Configure spanning-tree protocol-specific options.
a. To enable a spanning-tree protocol-specific option, include the flag statement:

user@host# set flag flag <flag-modifier> <disable>
You can specify the following spanning-tree protocol-specific flag options:
• all—Trace all operations.
• all-failures—Trace all failure conditions.
• bpdu—Trace BPDU reception and transmission.
• bridge-detection-state-machine—Trace the bridge detection state machine.
• events—Trace events of the protocol state machine.
• port-information-state-machine—Trace the port information state machine.
• port-migration-state-machine—Trace the port migration state machine.
• port-receive-state-machine—Trace the port receive state machine.
• port-role-transit-state-machine—Trace the port role transit state machine.
• port-role-select-state-machine—Trace the port role selection state machine.
• port-transmit-state-machine—Trace the port transmit state machine.
• port-state-transit-state-machine—Trace the port state transit state machine.
• ppmd—Trace the state and events for the ppmd process.
• state-machine-variables—Trace when the state machine variables change.
• timers—Trace protocol timers.
• topology-change-state-machine—Trace the topology change state machine.
NOTE: Use the trace flag all with caution. This flag may cause the CPU
to become very busy.
b. To disable an individual spanning-tree protocol-specific option, include the disable

option with the flag statement.
5. Verify the spanning-tree protocol-specific trace options.
[edit]
...
routing-options {
traceoptions {
...global-trace-options-configuration...
}
}

}
protocols {
(mstp | rstp | vstp) {
traceoptions { # Spanning-tree protocol-specific.
file filename <files number> <size bytes> <world-readable | no-world-readable>;
flag flag <flag-modifier> <disable>;
}
}
}
...

Documentation
Understanding BPDU Protection for Spanning-Tree Instance Interfaces
By default, if a bridge protocol data unit (BPDU) data frame is received on a blocked
interface, the system will disable the interface and stop forwarding frames out the
interface until the interface is explicitly cleared.
The Spanning Tree Protocol (STP) family is designed to break possible loops in a Layer 2
bridged network. Loop prevention avoids damaging broadcast storms that can potentially
render the network useless. STP processes on bridges exchange BPDUs to determine
the LAN topology, decide the root bridge, stop forwarding on some ports, and so on.
However, a misbehaving user application or device can interfere with the operation of
the STP protocols and cause network problems.
On the ACX Series routers, MX Series routers, and EX Series switches only, you can
configure BPDU protection to ignore BPDUs received on interfaces where none should
be expected (for example, a LAN interface on a network edge with no other bridges
present). If a BPDU is received on a blocked interface, the interface is disabled and stops
forwarding frames. By default, all BPDUs are accepted and processed on all interfaces.
You can configure BPDU protection on interfaces with the following encapsulation types:
• ethernet-bridge
• ethernet-vpls
• extended-vlan-bridge
• vlan-vpls
• vlan-bridge
• extended-vlan-vpls

You can configure BPDU protection on individual interfaces or on all the edge ports of
the bridge.
Related • Configuring BPDU Protection for Spanning-Tree Instance Interfaces on page 424
Documentation
• Understanding Root Protection for Spanning-Tree Instance Interfaces in a Layer 2

Switched Network on page 429
• Understanding VPLS Multihomed Layer 2 Ring and MPLS Infrastructure
Configuring BPDU Protection for Spanning-Tree Instance Interfaces
On the ACX Series routers, MX Series routers, and EX Series switches, you can configure
BPDU protection to ignore BPDU received on interfaces where none should be expected.
If a BPDU is received on a blocked interface, the interface is disabled and stops forwarding
frames. By default, all BPDUs are accepted and processed on all interfaces.
To configure BPDU protection for individual spanning-tree instance interfaces:
1. Enable BPDU protection on a specific spanning-tree instance interface:
[edit]
user@host# edit protocols layer2-control bpdu-block
user@host# set interface interface (aex | (ge-fpc/pic/port | xe-fpc/pic/port)
If a BPDU is received on the interface, the system will disable the interface and stop
forwarding frames out the interface until the bridging process is restarted.
2. (Optional) Configure the amount of time the system waits before automatically
unblocking this interface after it has received a BPDU:
[edit protocols layer2-contorl bpdu-block interface interface-name]

user@host# set disable-timeout seconds
The range of the seconds option value is from 10 through 3600 seconds (one hour).
A seconds option value of 0 is allowed, but this results in the default behavior (the
interface is blocked until the interface is cleared).
3. Verify the configuration of BPDU blocking for individual interfaces:
[edit]
interfaces {
ge-fpc/pic/port { # VLAN encapsulation on a Gigabit Ethernet.
encapsulation (ethernet-bridge | ethernett-vpls | extended-vlan-bridge |
extended-vlan-vpls | vlan-bridge| vlan-vpls);
}
xe-fpc/pic/port { # VLAN encapsulation on 10-Gigabit Ethernet.
encapsulation (ethernet-bridge | ethernett-vpls | extended-vlan-bridge |
extended-vlan-vpls | vlan-bridge| vlan-vpls);
}

ae-X { # VLAN encapsulation

encapsulation (ethernet-vpls vlan-vpls); # on aggregated Ethernet.
...
}
ae-X { # Extended VLAN encapsulation
vlan-tagging; # on aggregated Ethernet.
encapsulation extended-vlan-vpls;
vlan-id number;
......
}
......
}
}
protocols
layer2-control {
bpdu-block
interface interface-name;
disable-timeout seconds;
}
}
Related • Understanding Root Protection for Spanning-Tree Instance Interfaces in a Layer 2

Documentation Switched Network on page 429
• BPDU Protection for Individual Spanning-Tree Instance Interfaces
Configuring BPDU Protection on All Edge Ports
On ACX Series routers, MX Series routers, and EX Series switches, you can configure
BPDU protection to ignore BPDU received on interfaces where none should be expected.
If a BPDU is received on a blocked interface, the interface is disabled and stops forwarding
frames. By default, all BPDUs are accepted and processed on all interfaces.
To configure BPDU protection for all edge ports for a particular spanning-tree protocol:
1. Enable edge port blocking for a particular spanning-tree protocol:
[edit]
user@host# set protocols (STP Type) (mstp | rstp | vstp) bpdu-block-on-edge
2. Verify BPDU protection for edge ports:
[edit]
protocols (STP Type) {
(mstp | rstp | vstp) {
bpdu-block-on-edge;
}
}


• BPDU Protection on All Edge Ports of the Bridge
Understanding Loop Protection for Spanning-Tree Instance Interfaces
Spanning-tree protocol loop protection enhances the normal checks that spanning-tree
protocols perform on interfaces. Loop protection performs a specified action when BPDUs
are not received on a nondesignated port interface. You can choose to block the interface
or issue an alarm when bridge protocol data units (BPDUs) are not received on the port.
The spanning-tree protocol family is responsible for breaking loops in a network of bridges
with redundant links. However, hardware failures can create forwarding loops (STP
loops) and cause major network outages. Spanning-tree protocols break loops by blocking
ports (interfaces). However, errors occur when a blocked port transitions erroneously to
a forwarding state.
Ideally, a spanning-tree protocol bridge port remains blocked as long as a superior

alternate path to the root bridge exists for a connected LAN segment. This designated
port is determined by receiving superior BPDUs from a peer on that port. When other
ports no longer receive BPDUs, the spanning-tree protocol considers the topology to be
loop free. However, if a blocked or alternate port moves into a forwarding state, this
creates a loop.
By default (that is, without spanning-tree protocol loop protection configured), an

interface that stops receiving BPDUs will assume the designated port role and possibly
result in a spanning-tree protocol loop.
By default, a spanning-tree protocol interface that stops receiving bridge protocol data
unit (BPDU) data frames will transition to the designated port (forwarding) state, creating
a potential loop. To prevent a spanning-tree instance interface from interpreting a lack
of received BPDUs as a “false positive” condition for assuming the designated port role,
you can configure one of the following loop protection options:
• Configure the router to raise an alarm condition if the spanning-tree instance interface
has not received BPDUs during the timeout interval.
• Configure the router to block the spanning-tree instance interface if the interface has
not received BPDUs during the timeout interval.
NOTE: Spanning-tree instance interface loop protection is enabled for all

spanning-tree instances on the interface, but blocks or alarms only those
instances that stop receiving BPDUs.
You can configure spanning-tree protocol loop protection to improve the stability of
Layer 2 networks. We recommend you configure loop protection only on non-designated

interfaces such as the root or alternate interfaces. Otherwise, if you configure loop
protection on both sides of a designated link, then certain STP configuration events (such
as setting the root bridge priority to an inferior value in a topology with many loops) can
cause both interfaces to transition to blocking mode.
You configure spanning-tree protocol loop protection to prevent selected interfaces from
interpreting the lack of received BPDUs as a “false positive” condition for making the
interface the designated port.
Related • Configuring Loop Protection for a Spanning-Tree Instance Interface on page 428
Documentation
Loop Protection for a Spanning-Tree Instance Interface
By default, a spanning-tree protocol interface that stops receiving Bridge Protocol Data
Unit (BPDU) data frames will transition to the designated port (forwarding) state, creating
a potential loop. To prevent a spanning-tree instance interface from interpreting a lack
of received BPDUs as a “false positive” condition for assuming the designated port role,
you can configure one of the following loop protection options:
• Configure the router to raise an alarm condition if the spanning-tree instance interface
has not received BPDUs during the timeout interval.
• Configure the router to block the spanning-tree instance interface if the interface has
not received BPDUs during the timeout interval.
NOTE: Spanning-tree instance interface loop protection is enabled for all

spanning-tree instances on the interface, but blocks or alarms only those
instances that stop receiving BPDUs.
We recommend you configure loop protection only on non-designated interfaces such

as the root or alternate interfaces. Otherwise, if you configure loop protection on both
sides of a designated link, then certain STP configuration events (such as setting the root
bridge priority to an inferior value in a topology with many loops) can cause both interfaces
to transition to blocking mode.
Related • Understanding Loop Protection for Spanning-Tree Instance Interfaces on page 426
Documentation
• bpdu-timeout-action on page 1452

Configuring Loop Protection for a Spanning-Tree Instance Interface
Before you begin, you must fully configure the spanning-tree protocol, including instance
interfaces. You can configure RSTP, MSTP, or VSTP at the following hierarchy levels:
• [edit routing-instances routing-instance-name protocols]
To configure enhanced loop protection:
1. Include the bpdu-timeout-action statement with either the block or log option for the
spanning-tree protocol interface.
• For the STP or RSTP instance on a physical interface:
[edit]
protocols {
rstp {
bpdu-timeout-action (log | block);
}
}
}
• For all MSTP instances on a physical interface:
[edit]
protocols {
mstp {
}
}
}
• For all VSTP instances on a physical interface configured at the global level or a
the VLAN level:
[edit]
protocols {
vstp {
}
vlan vlan-id {
}
}
}
}
2. To display the spanning-tree protocol loop protection characteristics on an interface,

use the show spanning-tree interface operational command.

Documentation
• Loop Protection for a Spanning-Tree Instance Interface on page 427
Example: Enabling Loop Protection for Spanning-Tree Protocols
This example blocks and logs the non-designated RSTP port ge-1/2/0 after the BPDU
timeout interval expires:
[edit]
protocols {
rstp {
interface ge-1/2/0 {
bpdu-timeout-action block;
}
}
}
NOTE: This is not a complete configuration. You must also fully configure
RSTP, including the ge-1/2/0 interface.
Related • Loop Protection for a Spanning-Tree Instance Interface on page 427

Documentation
• Understanding Loop Protection for Spanning-Tree Instance Interfaces on page 426
Understanding Root Protection for Spanning-Tree Instance Interfaces in a Layer 2

Switched Network
Root protect helps to enforce the root bridge placement in a Layer 2 switched network.
Enable root protect on interfaces that should not receive superior bridge protocol data
units (BPDUs) from the root bridge. Typically, these ports are spanning tree
protocol-designated ports on an administrative boundary. Enabling root protect ensures
the port remains a spanning-tree designated port.
When root protect is enabled on an interface, it is enabled for all spanning-tree protocol
instances on that interface. The interface is blocked only for those instances that receive
superior BPDUs.
By default, root protect is disabled.
If the bridge receives superior BPDUs on a port that has root protect enabled, that port
transitions to a root-prevented STP state and the interface is blocked. This prevents a
bridge that should not be the root bridge from being elected the root bridge.
After the bridge stops receiving superior BPDUs on the port with root protect enabled
and the received BPDUs time out, that port transitions back to the STP-designated port
state.


Root Protect for a Spanning-Tree Instance Interface
When root protect is enabled on an interface, it is enabled for all spanning-tree protocol
instances on that interface. The interface is blocked only for those instances that receive
superior BPDUs.
By default, root protect is disabled.

• no-root-port on page 1640
Enabling Root Protection for a Spanning-Tree Instance Interface
To enable root protect for a spanning-tree instance interface:
1. Enable configuration of the spanning-tree protocol:
[edit]
user@host# edit protocols (mstp | rstp | vstp <vlan vlan-id>)
2. Enable configuration of the spanning-tree instance interface:
[edit ... protocols (mstp | rstp | vstp <vlan vlan-id>)]

3. Enable root protection on the interface:
[edit ... protocols (mstp | rstp | vstp <vlan vlan-id>) interface interface-name]
user@host# set no-root-port
4. Verify the configuration of root protect for the spanning-tree instance interface:
[edit ... protocols (mstp | rstp | vstp <vlan vlan-id>) interface interface-name]
user@host# top
user@host# show ... protocols
...
(mstp | rstp | vstp <vlan vlan-id>) {
no-root-port;
}

NOTE: This is not a complete configuration.

LLDP Overview
The Link Layer Discovery Protocol (LLDP) is an industry-standard, vendor-neutral method

to allow networked devices to advertise capabilities, identity, and other information onto
a LAN. The Layer 2 protocol, detailed in IEEE 802.1AB-2005, replaces several proprietary
protocols implemented by individual vendors for their equipment.
LLDP allows network devices that operate at the lower layers of a protocol stack (such
as Layer 2 bridges and switches) to learn some of the capabilities and characteristics of
LAN devices available to higher layer protocols, such as IP addresses. The information
gathered through LLDP operation is stored in a network device and is queried with SNMP.
Topology information can also be gathered from this database.
Some of the information that can be gathered by LLDP (only minimal information is
mandatory) is:
• System name and description
• Port name and description
• VLAN name and identifier
• IP network management address
• Capabilities of the device (for example, switch, router, or server)
• MAC address and physical layer information
• Power information
• Link aggregation information
NOTE: LLDP media endpoint discovery (LLDP-MED) is not supported on T

Series routers.
LLDP frames are sent at fixed intervals on each port that runs LLDP. LLDP protocol data
units (LLDP PDUs) are sent inside Ethernet frames and identified by their destination
Media Access Control (MAC) address (01:80:C2:00:00:0E) and Ethertype (0x88CC).
Mandatory information supplied by LLDP is chassis ID, port ID, and a time-to-live value
for this information.

LLDP is a powerful way to allow Layer 2 devices to gather details about other
network-attached devices.
Related • Configuring LLDP

Documentation
• Configuring LLDP in ACX Series on page 432
• Tracing LLDP Operations
• Example: Configuring LLDP
Configuring LLDP in ACX Series
You configure LLDP by including the lldp statement and associated parameters at the
[edit protocols] hierarchy level. The complete set of LLDP statements follows:
lldp {
advertisement-interval seconds;
disable;
hold-multiplier number;
interface (all | interface-name) {
disable;
}
lldp-configuration-notification-interval seconds;
port-id-subtype {
interface-name;
locally-assigned;
}
ptopo-configuration-maximum-hold-time seconds;
ptopo-configuration-trap-interval seconds;
traceoptions {
file filename <files number> <size size> <world-readable | no-world-readable>;
}
transmit-delay seconds
}
The following statements have default values:
• advertisement-interval—The default value is 30 seconds. The allowable range is from 5

through 32768 seconds.
• hold-multiplier—The default values is 4. The allowable range is from 2 through 10.
• ptopo-configuration-maximum-hold-time—The default value is 300 seconds. The

allowable range is from 1 through 2147483647 seconds.
• transmit-delay—The default values is 2 seconds. The allowable range is from 1 through

8192 seconds.

The following statements must be explicitly configured:
• lldp-configuration-notification-interval—The allowable range is from 0 through

3600 seconds. There is no default value.
• ptopo-configuration-trap-interval—The allowable range is from 1 through

2147483647 seconds. There is no default value.
To disable LLDP on all or a particular interface, include the interfaces statement at the
[edit protocols lldp] hierarchy level:
interface (all | interface-name) {

disable;
}
To disable LLDP on all interfaces, use the all option. To disable LLDP on a particular
interface, include the disable statement with the interface name.
NOTE: The interface-name must be the physical interface (for example,

ge-1/0/0) and not a logical interface (unit).
The advertisement interval determines the frequency that an LLDP interface sends LLDP
advertisement frames. The default value is 30 seconds. The allowable range is from 5
through 32768 seconds. You adjust this parameter by including the advertisement-interval
statement at the [edit protocols lldp] hierarchy level.
The hold multiplier determines the multiplier to apply to the advertisement interval. The
resulting value in seconds is used to cache learned LLDP information before discard. The
default value is 4. When used with the default advertisement interval value of 30 seconds,
this makes the default cache lifetime 120 seconds. The allowable range of the hold
multiplier is from 2 through 10. You adjust this parameter by including the hold-multiplier
The transmit delay determines the delay between any two consecutive LLDP
advertisement frames. The default value is 2 seconds. The allowable range is from 1
through 8192 seconds. You adjust this parameter by including the transmit-delay
The physical topology configuration maximum hold time determines the time interval
for which an agent device maintains physical topology database entries. The default
value is 300 seconds. The allowable range is from 1 through 2147483647 seconds. You
adjust this parameter by including the ptopo-configuration-maximum-hold-time statement
at the [edit protocols lldp] hierarchy level.
The LLDP configuration notification interval determines the period for which trap
notifications are sent to the SNMP Master Agent when changes occur in the database
of LLDP information. This capability is disabled by default. The allowable range is from 0
(disabled) through 3600 seconds. You adjust this parameter by including the
lldp-configuration-notification-interval statement at the [edit protocols lldp] hierarchy
level.

The physical topology configuration trap interval determines the period for which trap
notifications are sent to the SNMP Master Agent when changes occur in the global
physical topology statistics. This capability is disabled by default. The allowable range
is from 0 (disabled) through 3600 seconds. The LLDP agent sends traps to the SNMP
Master Agent if this interval has a value greater than 0 and there is any change during
the lldp-configuration-notification-interval trap interval. You adjust this parameter by
including the ptopo-configuration-trap-interval statement at the [edit protocols lldp]
hierarchy level.
By default, LLDP generates the SNMP index of the interface for the port ID Type, Length,
and Value (TLV). Starting with Junos OS Release 12.3R1, you can generate the interface
name as the port ID TLV by including the interface-name statement at the [edit protocols
lldp port-id-subtype] hierarchy level. When configure the interface-name, statement on
the remote LLDP neighbor, the show lldp neighbors command displays the interface
name in the Port ID field rather than the SNMP index of the interface, which is displayed
by default. If you change the default behavior of generating the SNMP index of the
interface as the Port ID TLV, you can reenable the default behavior by including the
locally-assigned statement at the [edit protocols lldp port-id-subtype hierarchy level.
Related • LLDP Overview on page 431

Documentation
LLDP Operational Mode Commands
Table 40 on page 434 summarizes the command-line interface (CLI) commands you can
use to monitor and troubleshoot the Link Layer Discovery Protocol (LLDP) protocol.
Commands are listed in alphabetical order.
Table 40: LLDP Operational Mode Commands

Task Command
Clear LLDP neighbor information. clear lldp neighbors
Clear LLDP statistics. clear lldp statistics
Display basic LLDP information. show lldp
Display LLDP local information. show lldp local-information
Display LLDP neighbor information. show lldp neighbors
Display LLDP remote global statistics. show lldp remote-global-statistics
Display LLDP statistics. show lldp statistics
Related • LLDP Overview on page 431

Documentation

• Configuring LLDP
• Tracing LLDP Operations
• Example: Configuring LLDP


CHAPTER 13
Configuring Layer 2 Protocol Tunneling
• Layer 2 Protocol Tunneling on ACX Series Overview on page 437

• Enabling Layer 2 Protocol Tunneling on ACX Series on page 439
• Configuring a Layer 2 Protocol Tunnel Interface in ACX Series on page 439
• Configuring a Layer 2 Protocol to be Tunneled in ACX Series on page 440
• Configuring Layer 2 Protocol Tunneling on ACX Series on page 441
• Checking for a MAC Rewrite Error Condition Blocking Layer 2 Interface in ACX
Series on page 442
• Clearing a MAC Rewrite Error Condition Blocking a Spanning-Tree Instance Interface
in ACX Series on page 442
Layer 2 Protocol Tunneling on ACX Series Overview
Layer 2 protocol tunneling (L2PT) allows Layer 2 protocol data units (PDUs) to be
tunneled through a network.
L2PT on ACX Series routers supports tunneling the following Layer 2 PDUs:
• Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), and Multiple
Spanning Tree Protocol (MSTP)
• Cisco Discovery Protocol (CDP)
• VLAN Trunk Protocol (VTP)
• IEEE 802.1X authentication
• IEEE 802.3ah Operation, Administration, and Maintenance (OAM) link fault

management (LFM)
• Ethernet local management interface (E-LMI)
• Link Aggregation Control Protocol (LACP)
• Link Layer Discovery Protocol (LLDP)
• Multiple MAC Registration Protocol (MMRP)
• Multiple VLAN Registration Protocol (MVRP)

When a Layer 2 control PDU is received on a service provider edge port configured for
L2PT, the multicast destination MAC address is rewritten with the predefined multicast
tunnel MAC address of 01:00:0c:cd:cd:d0. The packet is transported across the provider
network transparently to the other end of the tunnel and the original multicast destination
MAC address is restored when the packet is transmitted.
If a packet is received on a tunnel interface that already has a destination multicast MAC
address of 01:00:0c:cd:cd:d0, the port enters an error state and is shut down. To clear
the error condition, the administrator must enter the clear error mac-rewrite
interface interface-name command.
L2PT can be configured on the customer edge aggregated Ethernet interface using
mac-rewrite CLI command at the [edit protocols layer2-control] hierarchy level.
The destination MAC address used by different protocols is listed in Table 41 on page 438:
Table 41: Protocol Destination MAC Addresses

Protocol Ethernet Encapsulation MAC Address
802.1X Ether (0x888E) 01:80:C2:00:00:03
802.3ah Ether (0x8809) 01:80:C2:00:00:02
Cisco Discovery Protocol (CDP) LLC (0xAAAA03) 01:00:0C:CC:CC:CC
Ethernet local management interface (E-LMI) Ether (0x88EE) 01:80:C2:00:00:07
MVRP VLAN Registration Protocol (MVRP) Ether (0x88F6) 01:80:c2:00:00:21
Link Aggregation Control Protocol (LACP) Ether (0x8809) 01:80:C2:00:00:02
Spanning Tree Protocol (STP), Rapid Spanning Tree LLC (0x424203) 01:80:C2:00:00:00
Protocol (RSTP), and Multiple Spanning Tree
Protocol (MSTP)
Link Layer Discovery Protocol (LLDP) Ether (0x88CC) 01:80:C2:00:00:0E
Multiple MAC Registration Protocol (MMRP) Ether (0x88F5) 01:80:C2:00:00:20
VLAN Trunking Protocol (VTP) LLC (0xAAAA03) 01:00:0C:CC:CC:CC

Documentation
• Checking for a MAC Rewrite Error Condition Blocking Layer 2 Interface in ACX Series
on page 442


Chapter 13: Configuring Layer 2 Protocol Tunneling
Enabling Layer 2 Protocol Tunneling on ACX Series
To enable L2PT, include the mac-rewrite statement at the [edit protocols layer2-control]
hierarchy level.
For configuring MAC address rewriting for Layer 2 protocol tunneling, the following
guidelines apply:
• You can enable Layer 2 protocol tunneling for untagged interfaces.
• You can enable Layer 2 protocol tunneling for single VLAN tagged ports. If a logical
port is tagged, then native VLAN ID must be configured to enable Layer 2 protocol
tunneling on that logical port.
NOTE: Native VLAN ID value set to 0 is not supported.
You cannot enable Layer 2 protocol tunneling for double identifier tagged interfaces.

Documentation
on page 442

Configuring a Layer 2 Protocol Tunnel Interface in ACX Series
To configure the interface where Layer 2 protocol tunneling is enabled, include the
interface ge-fpc/pic/port statement at the [edit protocols layer2-control] hierarchy level.
Keep the following guidelines in mind when configuring Layer 2 protocol tunneling:
• Layer 2 protocol tunneling must be configured on the interfaces at each end of the
tunnel.
• You can enable Layer 2 protocol tunneling for untagged interfaces and single VLAN
tagged interfaces only.
• For single VLAN tagged interfaces, configure a logical interface with the native VLAN
identifier. This configuration associates the untagged control packets with a logical
interface.
• You cannot enable Layer 2 protocol tunneling for double identifier tagged interfaces.


Documentation
• Layer 2 Control Protocol on ACX Series Routers on page 404
Configuring a Layer 2 Protocol to be Tunneled in ACX Series
You can configure L2PT only on Layer 2 ports. To configure L2PT, you must specify any
of the following protocols that is to be tunneled:
• cdp—Cisco Discovery Protocol.
• stp—All versions of the spanning-tree protocol.
• vtp—Tunnel the VLAN trunk protocol.
• ieee802.1x—Tunnel the IEEE 802.1X authentication
• ieee802.3ah—Tunnel the IEEE 802.3ah Operation, Administration, and Maintenance

(OAM) link fault management (LFM)
• elmi—Tunnel the Ethernet local management interface protocol
• lacp—Tunnel the Link Aggregation Control Protocol
• lldp—Tunnel the Link Layer Discovery Protocol
• mmrp—Tunnel the Multiple MAC Registration Protocol
• mvrp—Tunnel the Multiple VLAN Registration Protocol
To specify the protocol that will be tunneled by the Layer 2 protocol tunneling, you can
include the protocol (cdp | stp | vtp | ieee802.1x | ieee802.3ah | elmi | lacp | lldp | mmrp |
mvrp) statement at the [edit protocols layer2-control mac-rewrite interface ge-fpc/pic/port]
hierarchy level.
NOTE: When CDP, STP, VTP, IEEE 802.1x, IEEE 802.3ah, E-LMI, LACP, LLDP,
MMRP, or MVRP is configured for tunneling on a customer-facing port in a
provider bridge, the corresponding protocol should not be enabled for
operation on that interface.

Documentation

on page 442

Configuring Layer 2 Protocol Tunneling on ACX Series
To configure Layer 2 protocol tunneling:
1. Enable MAC address rewriting for Layer 2 protocol tunneling:
[edit]
user@host# edit protocols layer2-control mac-rewrite
2. Configure the Layer 2 protocol tunnel interface:
[edit ... protocols layer2-control mac-rewrite]

user@host# edit interface ge-fpc/pic/port
3. Configure the Layer 2 protocol to be tunneled:
[edit protocols layer2-control mac-rewrite interface ge-fpc/pic/port]

user@host# set protocol (cdp | stp | vtp | ieee802.1x | ieee802.3ah | elmi | lacp | lldp | mmrp
| mvrp)
user@host# show protocols

layer2-control {
mac-rewrite {
interface ge-fpc/pic/port {
protocol (cdp | stp | vtp | ieee802.1x | ieee802.3ah | elmi | lacp | lldp | mmrp |
mvrp);
}
}
}

Documentation
on page 442


Checking for a MAC Rewrite Error Condition Blocking Layer 2 Interface in ACX Series
To check whether an interface is blocked due to a MAC rewrite error condition:
1. Use the show interfaces operational mode command:
user@host> show interfaces interface-name
2. You can determine the status of the interface as follows:
• If the value in the Physical interface includes Enabled, Physical link is Up and the
value of the MAC-REWRITE Error field is None, the interface is enabled
• If the value in the Physical interface field is Enabled, Physical link is Down and the
value in the MAC-REWRITE Error field is Detected, the interface is blocked.

Documentation

Clearing a MAC Rewrite Error Condition Blocking a Spanning-Tree Instance Interface

in ACX Series
If a packet is received on a tunnel interface that already has a destination multicast MAC
address of 01:00:0c:cd:cd:d0, the port enters an error state and is shut down. To clear
the error condition, the administrator must enter the clear error mac-rewrite interface
interface-name command.
To clear the blocked status of an interface:
• Use the clear error mac-rewrite operational mode command.
user@host> clear error mac-rewrite interface interface-name

Documentation

on page 442


CHAPTER 14
Configuring Internet Group Management

Protocol
• Understanding IGMP on page 445

• Enabling IGMP on page 447
• Configuring IGMP on page 448
• Disabling IGMP on page 450
• Modifying the IGMP Host-Query Message Interval on page 450
• Modifying the IGMP Query Response Interval on page 451
• Specifying Immediate-Leave Host Removal for IGMP on page 452
• Filtering Unwanted IGMP Reports at the IGMP Interface Level on page 453
• Accepting IGMP Messages from Remote Subnetworks on page 454
• Modifying the IGMP Last-Member Query Interval on page 455
• Modifying the IGMP Robustness Variable on page 456
• Limiting the Maximum IGMP Message Rate on page 457
• Changing the IGMP Version on page 458
• Enabling IGMP Static Group Membership on page 459
• Recording IGMP Join and Leave Events on page 466
• Limiting the Number of IGMP Multicast Group Joins on Logical Interfaces on page 467
• Tracing IGMP Protocol Traffic on page 469
Understanding IGMP
The Internet Group Management Protocol (IGMP) manages the membership of hosts
and routing devices in multicast groups. IP hosts use IGMP to report their multicast group
memberships to any immediately neighboring multicast routing devices. Multicast routing
devices use IGMP to learn, for each of their attached physical networks, which groups
have members.

IGMP is also used as the transport for several related multicast protocols (for example,
Distance Vector Multicast Routing Protocol [DVMRP] and Protocol Independent Multicast
version 1 [PIMv1]).
A routing device receives explicit join and prune messages from those neighboring routing
devices that have downstream group members. When PIM is the multicast protocol in
use, IGMP begins the process as follows:
1. To join a multicast group, G, a host conveys its membership information through IGMP.
2. The routing device then forwards data packets addressed to a multicast group G to
only those interfaces on which explicit join messages have been received.
3. A designated router (DR) sends periodic join and prune messages toward a
group-specific rendezvous point (RP) for each group for which it has active members.
One or more routing devices are automatically or statically designated as the RP, and
all routing devices must explicitly join through the RP.
4. Each routing device along the path toward the RP builds a wildcard (any-source)
state for the group and sends join and prune messages toward the RP.
The term route entry is used to refer to the state maintained in a routing device to
represent the distribution tree.
A route entry can include such fields as:
• source address
• group address
• incoming interface from which packets are accepted
• list of outgoing interfaces to which packets are sent
• timers
• flag bits
The wildcard route entry's incoming interface points toward the RP.
The outgoing interfaces point to the neighboring downstream routing devices that
have sent join and prune messages toward the RP as well as the directly connected
hosts that have requested membership to group G.
5. This state creates a shared, RP-centered, distribution tree that reaches all group
members.
IGMP is also used as the transport for several related multicast protocols (for example,
Distance Vector Multicast Routing Protocol [DVMRP] and Protocol Independent Multicast
version 1 [PIMv1]).
Starting in Junos OS Release 15.2, PIMv1 is not supported.
IGMP is an integral part of IP and must be enabled on all routing devices and hosts that
need to receive IP multicast traffic.

Chapter 14: Configuring Internet Group Management Protocol
For each attached network, a multicast routing device can be either a querier or a
nonquerier. The querier routing device periodically sends general query messages to
solicit group membership information. Hosts on the network that are members of a
multicast group send report messages. When a host leaves a group, it sends a leave
group message.
IGMP version 3 (IGMPv3) supports inclusion and exclusion lists. Inclusion lists enable
you to specify which sources can send to a multicast group. This type of multicast group
is called a source-specific multicast (SSM) group, and its multicast address is 232/8.
IGMPv3 provides support for source filtering. For example, a routing device can specify
particular routing devices from which it accepts or rejects traffic. With IGMPv3, a multicast
routing device can learn which sources are of interest to neighboring routing devices.
Exclusion mode works the opposite of an inclusion list. It allows any source but the ones
listed to send to the SSM group.
IGMPv3 interoperates with versions 1 and 2 of the protocol. However, to remain compatible
with older IGMP hosts and routing devices, IGMPv3 routing devices must also implement
versions 1 and 2 of the protocol. IGMPv3 supports the following membership-report record
types: mode is allowed, allow new sources, and block old sources.
15.2 Starting in Junos OS Release 15.2, PIMv1 is not supported.
Related • Supported IP Multicast Protocol Standards

Documentation
• Configuring IGMP
Enabling IGMP
The Internet Group Management Protocol (IGMP) manages multicast groups by

establishing, maintaining, and removing groups on a subnet. Multicast routing devices
use IGMP to learn which groups have members on each of their attached physical
networks. IGMP must be enabled for the router to receive IPv4 multicast packets. IGMP
is only needed for IPv4 networks, because multicast is handled differently in IPv6 networks.
IGMP is automatically enabled on all IPv4 interfaces on which you configure PIM and on
all IPv4 broadcast interfaces when you configure DVMRP.
If IGMP is not running on an interface—either because PIM and DVMRP are not configured
on the interface or because IGMP is explicitly disabled on the interface—you can explicitly
enable IGMP.

To explicitly enable IGMP:
1. If PIM and DVMRP are not running on the interface, explicitly enable IGMP by including
the interface name.
[edit protocols igmp]

user@host# set interface fe-0/0/0.0
2. See if IGMP is disabled on any interfaces. In the following example, IGMP is disabled
on a Gigabit Ethernet interface.

user@host# show
interface fe-0/0/0.0;
disable;
}
3. Enable IGMP on the interface by deleting the disable statement.

delete interface ge-1/0/0.0 disable
4. Verify the configuration.

user@host# show
5. Verify the operation of IGMP on the interfaces by checking the output of the show
igmp interface command.
Related • Understanding IGMP on page 445

Documentation
• show igmp interface
Configuring IGMP
Before you begin:
1. Determine whether the router is directly attached to any multicast sources. Receivers
must be able to locate these sources.
2. Determine whether the router is directly attached to any multicast group receivers. If
receivers are present, IGMP is needed.
3. Determine whether to configure multicast to use sparse, dense, or sparse-dense mode.

Each mode has different configuration considerations.
4. Determine the address of the RP if sparse or sparse-dense mode is used.

5. Determine whether to locate the RP with the static configuration, BSR, or auto-RP
method.
6. Determine whether to configure multicast to use its own RPF routing table when
configuring PIM in sparse, dense, or sparse-dense mode.
7. Configure the SAP and SDP protocols to listen for multicast session announcements.
See Configuring the Session Announcement Protocol.
To configure the Internet Group Management Protocol (IGMP), include the igmp
statement:
igmp {
accounting;
disable;
(accounting | no-accounting);
group-policy [ policy-names ];
immediate-leave;
oif-map map-name;
promiscuous-mode;
ssm-map ssm-map-name;
static {
group multicast-group-address {
exclude;
group-count number;
group-increment increment;
source ip-address {
source-count number;
source-increment increment;
}
}
}
version version;
}
query-interval seconds;
query-last-member-interval seconds;
query-response-interval seconds;
robust-count number;
traceoptions {
}
}
• [edit logical-systems logical-system-name protocols]
By default, IGMP is enabled on all interfaces on which you configure Protocol Independent
Multicast (PIM), and on all broadcast interfaces on which you configure the Distance
Vector Multicast Routing Protocol (DVMRP).

NOTE: You can configure IGMP on an interface without configuring PIM. PIM
is generally not needed on IGMP downstream interfaces. Therefore, only one
“pseudo PIM interface” is created to represent all IGMP downstream
(IGMP-only) interfaces on the router. This reduces the amount of router
resources, such as memory, that are consumed. You must configure PIM on
upstream IGMP interfaces to enable multicast routing, perform reverse-path
forwarding for multicast data packets, populate the multicast forwarding
table for upstream interfaces, and in the case of bidirectional PIM and PIM
sparse mode, to distribute IGMP group memberships into the multicast routing
domain.
Disabling IGMP
To disable IGMP on an interface, include the disable statement:
disable;
• [edit protocols igmp interface interface-name]
• [edit logical-systems logical-system-name protocols igmp interface interface-name]
NOTE: ACX Series routers do not support [edit logical-systems

logical-system-name protocols] hierarchy level.

Documentation
Modifying the IGMP Host-Query Message Interval
The objective of IGMP is to keep routers up to date with group membership of the entire
subnet. Routers need not know who all the members are, only that members exist. Each
host keeps track of which multicast groups are subscribed to. On each link, one router is
elected the querier. The IGMP querier router periodically sends general host-query
messages on each attached network to solicit membership information. The messages
are sent to the all-systems multicast group address, 224.0.0.1.
The query interval, the response interval, and the robustness variable are related in that
they are all variables that are used to calculate the group membership timeout. The
group membership timeout is the number of seconds that must pass before a multicast
router determines that no more members of a host group exist on a subnet. The group
membership timeout is calculated as the (robustness variable x query-interval) +
(query-response-interval). If no reports are received for a particular group before the

group membership timeout has expired, the routing device stops forwarding
remotely-originated multicast packets for that group onto the attached network.
By default, host-query messages are sent every 125 seconds. You can change this interval
to change the number of IGMP messages sent on the subnet.
To modify the query interval:
1. Configure the interval.

user@host# set query-interval 200
The value can be from 1 through 1024 seconds.
2. Verify the configuration by checking the IGMP Query Interval field in the output of the
show igmp interface command.
3. Verify the operation of the query interval by checking the Membership Query field in
the output of the show igmp statistics command.

Documentation
• show igmp statistics
Modifying the IGMP Query Response Interval
The query response interval is the maximum amount of time that can elapse between
when the querier router sends a host-query message and when it receives a response
from a host. Configuring this interval allows you to adjust the burst peaks of IGMP
messages on the subnet. Set a larger interval to make the traffic less bursty. Bursty traffic
refers to an uneven pattern of data transmission: sometimes a very high data transmission
rate, whereas at other times a very low data transmission rate.
The query response interval, the host-query interval, and the robustness variable are
related in that they are all variables that are used to calculate the group membership
timeout. The group membership timeout is the number of seconds that must pass before
a multicast router determines that no more members of a host group exist on a subnet.
The group membership timeout is calculated as the (robustness variable x query-interval)
+ (query-response-interval). If no reports are received for a particular group before the
group membership timeout has expired, the routing device stops forwarding remotely
originated multicast packets for that group onto the attached network.

The default query response interval is 10 seconds. You can configure a subsecond interval
up to one digit to the right of the decimal point. The configurable range is 0.1 through 0.9,
then in 1-second intervals 1 through 999,999.
To modify the query response interval:
1. Configure the interval.

user@host# set query-response-interval 0.4
2. Verify the configuration by checking the IGMP Query Response Interval field in the
output of the show igmp interface command.
3. Verify the operation of the query interval by checking the Membership Query field in
the output of the show igmp statistics command.

Documentation
• Modifying the IGMP Host-Query Message Interval on page 450
Specifying Immediate-Leave Host Removal for IGMP
The immediate leave setting is useful for minimizing the leave latency of IGMP
memberships. When this setting is enabled, the routing device leaves the multicast group
immediately after the last host leaves the multicast group.
The immediate-leave setting enables host tracking, meaning that the device keeps track
of the hosts that send join messages. This allows IGMP to determine when the last host
sends a leave message for the multicast group.
When the immediate leave setting is enabled, the device removes an interface from the
forwarding-table entry without first sending IGMP group-specific queries to the interface.
The interface is pruned from the multicast tree for the multicast group specified in the
IGMP leave message. The immediate leave setting ensures optimal bandwidth
management for hosts on a switched network, even when multiple multicast groups are
being used simultaneously.
When immediate leave is disabled and one host sends a leave group message, the routing
device first sends a group query to determine if another receiver responds. If no receiver
responds, the routing device removes all hosts on the interface from the multicast group.
Immediate leave is disabled by default for both IGMP version 2 and IGMP version 3.

NOTE: Although host tracking is enabled for IGMPv2 and MLDv1 when you
enable immediate leave, use immediate leave with these versions only when
there is one host on the interface. The reason is that IGMPv2 and MLDv1 use
a report suppression mechanism whereby only one host on an interface sends
a group join report in response to a membership query. The other interested
hosts suppress their reports. The purpose of this mechanism is to avoid a
flood of reports for the same group. But it also interferes with host tracking,
because the router only knows about the one interested host and does not
know about the others.
To enable immediate leave on an interface:
1. Configure immediate leave on the IGMP interface.
[edit protocols IGMP]

user@host# set interface ge-0/0/0.1 immediate-leave
2. Verify the configuration by checking the Immediate Leave field in the output of the

Documentation
Filtering Unwanted IGMP Reports at the IGMP Interface Level
Suppose you need to limit the subnets that can join a certain multicast group. The
group-policy statement enables you to filter unwanted IGMP reports at the interface
level. When this statement is enabled on a router running IGMP version 2 (IGMPv2) or
version 3 (IGMPv3), after the router receives an IGMP report, the router compares the
group against the specified group policy and performs the action configured in that policy
(for example, rejects the report if the policy matches the defined address or network).
You define the policy to match only IGMP group addresses (for IGMPv2) by using the
policy's route-filter statement to match the group address. You define the policy to match
IGMP (source, group) addresses (for IGMPv3) by using the policy's route-filter statement
to match the group address and the policy's source-address-filter statement to match
the source address.
CAUTION: On MX Series platforms, IGMPv2 and IGMPv3 can or cannot be

configured together on the same interface, depending on the Junos OS release
at your installation. Configuring both together can cause unexpected behavior
in multicast traffic forwarding.

To filter unwanted IGMP reports:
1. Configure an IGMPv2 policy.
[edit policy-statement reject_policy_v2]

user@host# set from route-filter 233.252.0.1/32 exact
user@host# set from route-filter 239.0.0.0/8 orlonger
user@host# set then reject
2. Configure an IGMPv3 policy.
[edit policy-statement reject_policy_v3]

user@host# set from route-filter 233.252.0.1/32 exact
user@host# set from route-filter 239.0.0.0/8 orlonger
user@host# set from source-address-filter 10.0.0.0/8 orlonger
user@host# set from source-address-filter 127.0.0.0/8 orlonger
user@host# set then reject
3. Apply the policies to the IGMP interfaces on which you prefer not to receive specific
group or (source, group) reports. In this example, ge-0/0/0.1 is running IGMPv2, and
ge-0/1/1.0 is running IGMPv3.

user@host# set interface ge-0/0/0.1 group-policy reject_policy_v2
user@host# set interface ge-0/1/1.0 group-policy reject_policy_v3
4. Verify the operation of the filter by checking the Rejected Report field in the output
of the show igmp statistics command.

Documentation
• Example: Configuring Policy Chains and Route Filters
Accepting IGMP Messages from Remote Subnetworks
By default, IGMP interfaces accept IGMP messages only from the same subnet. Including
the promiscuous-mode statement enables the routing device to accept IGMP messages
from indirectly connected subnets.
NOTE: When you enable IGMP on an unnumbered Ethernet interface that

uses a /32 loopback address as a donor address, you must configure IGMP
promiscuous mode to accept the IGMP packets received on this interface.

NOTE: When enabling promiscuous-mode, all routers on the ethernet

segment must be configured with the promiscuous mode statement.
Otherwise, only the interface configured with lowest IPv4 address acts as
the querier for IGMP for this Ethernet segment.
To enable IGMP promiscuous mode on an interface:
1. Configure the IGMP interface.

user@host# set interface ge-0/1/1.0 promiscuous-mode
2. Verify the configuration by checking the Promiscuous Mode field in the output of the
3. Verify the operation of the filter by checking the Rx non-local field in the output of the
show igmp statistics command.

Documentation
• Configuring the Loopback Interface on page 101 in the Junos OS Network Interfaces
Library for Routing Devices
Modifying the IGMP Last-Member Query Interval
The last-member query interval is the maximum amount of time between group-specific
query messages, including those sent in response to leave-group messages. You can
configure this interval to change the amount of time it takes a routing device to detect
the loss of the last member of a group.
When the routing device that is serving as the querier receives a leave-group message
from a host, the routing device sends multiple group-specific queries to the group being
left. The querier sends a specific number of these queries at a specific interval. The number
of queries sent is called the last-member query count. The interval at which the queries
are sent is called the last-member query interval. Because both settings are configurable,
you can adjust the leave latency. The IGMP leave latency is the time between a request
to leave a multicast group and the receipt of the last byte of data for the multicast group.
The last-member query count x (times) the last-member query interval = (equals) the
amount of time it takes a routing device to determine that the last member of a group
has left the group and to stop forwarding group traffic.
The default last-member query interval is 1 second. You can configure a subsecond
interval up to one digit to the right of the decimal point. The configurable range is 0.1
through 0.9, then in 1-second intervals 1 through 999,999.

To modify this interval:
1. Configure the time (in seconds) that the routing device waits for a report in response
to a group-specific query.

user@host# set query-last-member-interval 0.1
2. Verify the configuration by checking the IGMP Last Member Query Interval field in the
output of the show igmp interfaces command.
NOTE: You can configure the last-member query count by configuring the
robustness variable. The two are always equal.
Related • Modifying the IGMP Robustness Variable on page 456

Documentation
• show pim interfaces
Modifying the IGMP Robustness Variable
Fine-tune the IGMP robustness variable to allow for expected packet loss on a subnet.
The robust count automatically changes certain IGMP message intervals for IGMPv2 and
IGMPv3. Increasing the robust count allows for more packet loss but increases the leave
latency of the subnetwork.
When the query router receives an IGMP leave message on a shared network running
IGMPv2, the query router must send an IGMP group query message a specified number
of times. The number of IGMP group query messages sent is determined by the robust
count.
The value of the robustness variable is also used in calculating the following IGMP
message intervals:
• Group member interval—Amount of time that must pass before a multicast router
determines that there are no more members of a group on a network. This interval is
calculated as follows: (robustness variable x query-interval) + (1 x
query-response-interval).
• Other querier present interval—The robust count is used to calculate the amount of
time that must pass before a multicast router determines that there is no longer another
multicast router that is the querier. This interval is calculated as follows: (robustness
variable x query-interval) + (0.5 x query-response-interval).
• Last-member query count—Number of group-specific queries sent before the router

assumes there are no local members of a group. The number of queries is equal to the
value of the robustness variable.
In IGMPv3, a change of interface state causes the system to immediately transmit a

state-change report from that interface. In case the state-change report is missed by

one or more multicast routers, it is retransmitted. The number of times it is retransmitted

is the robust count minus one. In IGMPv3, the robust count is also a factor in determining
the group membership interval, the older version querier interval, and the other querier
present interval.
By default, the robustness variable is set to 2. You might want to increase this value if
you expect a subnet to lose packets.
The number can be from 2 through 10.
To change the value of the robustness variable:
1. Configure the robust count.
When you set the robust count, you are in effect configuring the number of times the
querier retries queries on the connected subnets.

user@host# set robust-count 5
2. Verify the configuration by checking the IGMP Robustness Count field in the output
of the show igmp interfaces command.
Related • Modifying the IGMP Host-Query Message Interval on page 450

Documentation
• Modifying the IGMP Last-Member Query Interval on page 455
• RFC 2236, Internet Group Management Protocol, Version 2
Limiting the Maximum IGMP Message Rate
This section describes how to change the limit for the maximum number of IGMP packets
transmitted in 1 second by the router.
Increasing the maximum number of IGMP packets transmitted per second might be
useful on a router with a large number of interfaces participating in IGMP.
To change the limit for the maximum number of IGMP packets the router can transmit
in 1 second, include the maximum-transmit-rate statement and specify the maximum
number of packets per second to be transmitted.
Related • maximum-transmit-rate (Protocols IGMP)

Documentation

Changing the IGMP Version
By default, the routing device runs IGMPv2. Routing devices running different versions of
IGMP determine the lowest common version of IGMP that is supported by hosts on their
subnet and operate in that version.
To enable source-specific multicast (SSM) functionality, you must configure version 3

on the host and the host’s directly connected routing device. If a source address is specified
in a multicast group that is statically configured, the version must be set to IGMPv3.
If a static multicast group is configured with the source address defined, and the IGMP
version is configured to be version 2, the source is ignored and only the group is added.
In this case, the join is treated as an IGMPv2 group join.
BEST PRACTICE: If you configure the IGMP version setting at the individual
interface hierarchy level, it overrides the interface all statement. That is, the
new interface does not inherit the version number that you specified with the
interface all statement. By default, that new interface is enabled with version
2. You must explicitly specify a version number when adding a new interface.
For example, if you specified version 3 with interface all, you would need to
configure the version 3 statement for the new interface. Additionally, if you
configure an interface for a multicast group at the [edit interface interface-name
static group multicast-group-address] hierarchy level, you must specify a version
number as well as the other group parameters. Otherwise, the interface is
enabled with the default version 2.
If you have already configured the routing device to use IGMP version 1 (IGMPv1) and then
configure it to use IGMPv2, the routing device continues to use IGMPv1 for up to 6 minutes
and then uses IGMPv2.
To change to IGMPv3 for SSM functionality:
1. Configure the IGMP interface.

user@host# set interface ge-0/0/0 version 3
2. Verify the configuration by checking the version field in the output of the show igmp
interfaces command. The show igmp statistics command has version-specific output
fields, such as V1 Membership Report, V2 Membership Report, and V3 Membership
Report.
CAUTION: On MX Series platforms, IGMPv2 and IGMPv3 can or cannot be

configured together on the same interface, depending on the Junos OS release
at your installation. Configuring both together can cause unexpected behavior
in multicast traffic forwarding.


Documentation
Enabling IGMP Static Group Membership
You can create IGMP static group membership to test multicast forwarding without a
receiver host. When you enable IGMP static group membership, data is forwarded to an
interface without that interface receiving membership reports from downstream hosts.
The router on which you enable static IGMP group membership must be the designated
router (DR) for the subnet. Otherwise, traffic does not flow downstream.
When enabling IGMP static group membership, you cannot configure multiple groups
using the group-count, group-increment, source-count, and source-increment statements
if the all option is specified as the IGMP interface.
Class-of-service (CoS) adjustment is not supported with IGMP static group membership.
In this example, you create static group 233.252.0.1.
1. On the DR, configure the static groups to be created by including the static statement
and group statement and specifying which IP multicast address of the group to be
created. When creating groups individually, you must specify a unique address for
each group.

user@host# set interface fe-0/1/2 static group 233.252.0.1
2. After you commit the configuration, use the show configuration protocol igmp command
to verify the IGMP protocol configuration.
user@host> show configuration protocol igmp
interface fe-0/1/2.0 {
static {
group 233.252.0.1 ;
}
}
3. After you have committed the configuration and the source is sending traffic, use the
show igmp group command to verify that static group 233.252.0.1 has been created.
user@host> show igmp group

Interface: fe-0/1/2
Group: 233.252.0.1
Source: 10.0.0.2
Last reported by: Local
Timeout: 0 Type: Static

NOTE: When you configure static IGMP group entries on point-to-point links
that connect routing devices to a rendezvous point (RP), the static IGMP
group entries do not generate join messages toward the RP.
When you create IGMP static group membership to test multicast forwarding on an
interface on which you want to receive multicast traffic, you can specify that a number
of static groups be automatically created. This is useful when you want to test forwarding
to multiple receivers without having to configure each receiver separately.
In this example, you create three groups.
1. On the DR, configure the number of static groups to be created by including the
group-count statement and specifying the number of groups to be created.

user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3
static {
group 233.252.0.1 {
group-count 3;
}
}
}
3. After you have committed the configuration and after the source is sending traffic,
use the show igmp group command to verify that static groups 233.252.0.1, 233.252.0.2,
and 233.252.0.3 have been created.

Interface: fe-0/1/2
Group: 233.252.0.1
Source: 10.0.0.2
Group: 233.252.0.2
Source: 10.0.0.2
Group: 233.252.0.3
Source: 10.0.0.2

interface on which you want to receive multicast traffic, you can also configure the group
address to be automatically incremented for each group created. This is useful when
you want to test forwarding to multiple receivers without having to configure each receiver
separately and when you do not want the group addresses to be sequential.
In this example, you create three groups and increase the group address by an increment
of two for each group.
1. On the DR, configure the group address increment by including the group-increment
statement and specifying the number by which the address should be incremented
for each group. The increment is specified in dotted decimal notation similar to an
IPv4 address.

user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3
group-increment 0.0.0.2
version 3;
static {
group 233.252.0.1 {
group-increment 0.0.0.2;
group-count 3;
}
}
}
use the show igmp group command to verify that static groups 233.252.0.1, 233.252.0.3,
and 233.252.0.5 have been created.

Interface: fe-0/1/2
Group: 233.252.0.1
Source: 10.0.0.2
Group: 233.252.0.3
Source: 10.0.0.2
Group: 233.252.0.5
Source: 10.0.0.2

interface on which you want to receive multicast traffic, and your network is operating
in source-specific multicast (SSM) mode, you can also specify that the multicast source
address be accepted. This is useful when you want to test forwarding to multicast
receivers from a specific multicast source.
If you specify a group address in the SSM range, you must also specify a source.
If a source address is specified in a multicast group that is statically configured, the IGMP
version on the interface must be set to IGMPv3. IGMPv2 is the default value.
In this example, you create group 233.252.0.1 and accept IP address 10.0.0.2 as the only
source.
1. On the DR, configure the source address by including the source statement and
specifying the IPv4 address of the source host.

user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2
version 3;
static {
group 233.252.0.1 {
source 10.0.0.2;
}
}
}
show igmp group command to verify that static group 233.252.0.1 has been created
and that source 10.0.0.2 has been accepted.

Interface: fe-0/1/2
Group: 233.252.0.1
Source: 10.0.0.2

interface on which you want to receive multicast traffic, you can specify that a number
of multicast sources be automatically accepted. This is useful when you want to test
forwarding to multicast receivers from more than one specified multicast source.
In this example, you create group 233.252.0.1 and accept addresses 10.0.0.2, 10.0.0.3,
and 10.0.0.4 as the sources.
1. On the DR, configure the number of multicast source addresses to be accepted by

including the source-count statement and specifying the number of sources to be
accepted.

user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count
3
version 3;
static {
group 233.252.0.1 {
source 10.0.0.2 {
source-count 3;
}
}
}
}
show igmp group command to verify that static group 233.252.0.1 has been created
and that sources 10.0.0.2, 10.0.0.3, and 10.0.0.4 have been accepted.

Interface: fe-0/1/2
Group: 233.252.0.1
Source: 10.0.0.2
Group: 233.252.0.1
Source: 10.0.0.3
Group: 233.252.0.1
Source: 10.0.0.4

When you configure static groups on an interface on which you want to receive multicast
traffic, and specify that a number of multicast sources be automatically accepted, you
can also specify the number by which the address should be incremented for each source
accepted. This is useful when you want to test forwarding to multiple receivers without
having to configure each receiver separately and you do not want the source addresses
to be sequential.
In this example, you create group 233.252.0.1 and accept addresses 10.0.0.2, 10.0.0.4,
and 10.0.0.6 as the sources.
1. Configure the multicast source address increment by including the source-increment

statement and specifying the number by which the address should be incremented
for each source. The increment is specified in dotted decimal notation similar to an
IPv4 address.

user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count
3 source-increment 0.0.0.2
version 3;
static {
group 233.252.0.1 {
source 10.0.0.2 {
source-count 3;
source-increment 0.0.0.2;
}
}
}
}
use the show igmp group command to verify that static group 233.252.0.1 has been
created and that sources 10.0.0.2, 10.0.0.4, and 10.0.0.6 have been accepted.

Interface: fe-0/1/2
Group: 233.252.0.1
Source: 10.0.0.2
Group: 233.252.0.1
Source: 10.0.0.4
Group: 233.252.0.1
Source: 10.0.0.6

When you configure static groups on an interface on which you want to receive multicast
traffic and your network is operating in source-specific multicast (SSM) mode, you can
specify that certain multicast source addresses be excluded.
By default the multicast source address configured in a static group operates in include
mode. In include mode the multicast traffic for the group is accepted from the source
address configured. You can also configure the static group to operate in exclude mode.
In exclude mode the multicast traffic for the group is accepted from any address other
than the source address configured.
If a source address is specified in a multicast group that is statically configured, the IGMP
version on the interface must be set to IGMPv3. IGMPv2 is the default value.
In this example, you exclude address 10.0.0.2 as a source for group 233.252.0.1.
1. On the DR, configure a multicast static group to operate in exclude mode by including
the exclude statement and specifying which IPv4 source address to exclude.

user@host# set interface fe-0/1/2 static group 233.252.0.1 exclude source 10.0.0.2
version 3;
static {
group 233.252.0.1 {
exclude;
source 10.0.0.2;
}
}
}
show igmp group detail command to verify that static group 233.252.0.1 has been
created and that the static group is operating in exclude mode.
user@host> show igmp group detail

Interface: fe-0/1/2
Group: 233.252.0.1
Group mode: Exclude
Source: 10.0.0.2
Related • Enabling MLD Static Group Membership

Documentation
• group (Protocols IGMP)
• group-count (Protocols IGMP)

• group-increment (Protocols IGMP)
• source-count (Protocols IGMP)
• source-increment (Protocols IGMP)
• static (Protocols IGMP)
Recording IGMP Join and Leave Events
To determine whether IGMP tuning is needed in a network, you can configure the routing
device to record IGMP join and leave events. You can record events globally for the routing
device or for individual interfaces.
Table 42 on page 466 describes the recordable IGMP events.
Table 42: IGMP Event Messages

ERRMSG Tag Definition
RPD_IGMP_JOIN Records IGMP join events.
RPD_IGMP_LEAVE Records IGMP leave events.
RPD_IGMP_ACCOUNTING_ON Records when IGMP accounting is enabled on an IGMP interface.
RPD_IGMP_ACCOUNTING_OFF Records when IGMP accounting is disabled on an IGMP interface.
RPD_IGMP_MEMBERSHIP_TIMEOUT Records IGMP membership timeout events.
To enable IGMP accounting:
1. Enable accounting globally or on an IGMP interface. This example shows both options.

user@host# set accounting
user@host# set interface fe-0/1/0.2 accounting
2. Configure the events to be recorded and filter the events to a system log file with a
descriptive filename, such as igmp-events.
[edit system syslog file igmp-events]

user@host# set any info
user@host# set match “.*RPD_IGMP_JOIN.* | .*RPD_IGMP_LEAVE.* |
.*RPD_IGMP_ACCOUNTING.* | .*RPD_IGMP_MEMBERSHIP_TIMEOUT.*”
3. Periodically archive the log file.
This example rotates the file size when it reaches 100 KB and keeps three files.
[edit system syslog file igmp-events]

user@host# set archive size 100000
user@host# set archive files 3

user@host# set archive archive-sites “ftp://user@host1//var/tmp” password

“anonymous”
user@host# set archive archive-sites “ftp://user@host2//var/tmp” password “test”
user@host# set archive transfer-interval 24
user@host# set archive start-time 2011-01-07:12:30
4. You can monitor the system log file as entries are added to the file by running the
monitor start and monitor stop commands.
user@host> monitor start igmp-events
*** igmp-events ***

Apr 16 13:08:23 host mgd[16416]: UI_CMDLINE_READ_LINE: User 'user', command
'run monitor start igmp-events '
monitor

Documentation
• Specifying Log File Size, Number, and Archiving Properties
Limiting the Number of IGMP Multicast Group Joins on Logical Interfaces
The group-limit statement enables you to limit the number of IGMP multicast group joins
for logical interfaces. When this statement is enabled on a router running IGMP version 2
(IGMPv2) or version 3 (IGMPv3), the limit is applied upon receipt of the group report.
Once the group limit is reached, subsequent join requests are rejected.
When configuring limits for IGMP multicast groups, keep the following in mind:
• Each any-source group (*,G) counts as one group toward the limit.
• Each source-specific group (S,G) counts as one group toward the limit.
• Groups in IGMPv3 exclude mode are counted toward the limit.
• Multiple source-specific groups count individually toward the group limit, even if they
are for the same group. For example, (S1, G1) and (S2, G1) would count as two groups
toward the configured limit.
• Combinations of any-source groups and source-specific groups count individually

toward the group limit, even if they are for the same group. For example, (*, G1) and
(S, G1) would count as two groups toward the configured limit.
• Configuring and committing a group limit on a network that is lower than what already
exists on the network results in the removal of all groups from the configuration. The
groups must then request to rejoin the network (up to the newly configured group
limit).
• You can dynamically limit multicast groups on IGMP logical interfaces using dynamic
profiles.
Starting in Junos OS Release 12.2, you can optionally configure a system log warning
threshold for IGMP multicast group joins received on the logical interface. It is helpful to

review the system log messages for troubleshooting purposes and to detect if an excessive
amount of IGMP multicast group joins have been received on the interface. These log
messages convey when the configured group limit has been exceeded, when the
configured threshold has been exceeded, and when the number of groups drop below
the configured threshold.
The group-threshold statement enables you to configure the threshold at which a warning
message is logged. The range is 1 through 100 percent. The warning threshold is a
percentage of the group limit, so you must configure the group-limit statement to configure
a warning threshold. For instance, when the number of groups exceed the configured
warning threshold, but remain below the configured group limit, multicast groups continue
to be accepted, and the device logs the warning message. In addition, the device logs a
warning message after the number of groups drop below the configured warning threshold.
You can further specify the amount of time (in seconds) between the log messages by
configuring the log-interval statement. The range is 6 through 32,767 seconds.
You might consider throttling log messages because every entry added after the
configured threshold and every entry rejected after the configured limit causes a warning
message to be logged. By configuring a log interval, you can throttle the amount of system
log warning messages generated for IGMP multicast group joins.
NOTE: On ACX Series routers, the maximum number of multicast routes is

1024.
To limit multicast group joins on an IGMP logical interface:
1. Access the logical interface at the IGMP protocol hierarchy level.
[edit]
user@host# edit protocols igmp interface interface-name
2. Specify the group limit for the interface.
[edit protocols igmp interface interface-name]

user@host# set group-limit limit
3. (Optional) Configure the threshold at which a warning message is logged.

user@host# set group-threshold value
4. (Optional) Configure the amount of time between log messages.

user@host# set log-interval seconds
To confirm your configuration, use the show protocols igmp command. To verify the
operation of IGMP on the interface, including the configured group limit and the optional
warning threshold and interval between log messages, use the show igmp interface
command.

12.2 Starting in Junos OS Release 12.2, you can optionally configure a system log
warning threshold for IGMP multicast group joins received on the logical
interface.
Related • Enabling IGMP Static Group Membership on page 459

Documentation
Tracing IGMP Protocol Traffic
Tracing operations record detailed messages about the operation of routing protocols,
such as the various types of routing protocol packets sent and received, and routing policy
actions. You can specify which trace operations are logged by including specific tracing
flags. The following table describes the flags that you can include.
Flag Description
all Trace all operations.
client-notification Trace notifications.
general Trace general flow.
group Trace group operations.
host-notification Trace host notifications.
leave Trace leave group messages (IGMPv2 only).
mtrace Trace mtrace packets. Use the mtrace command to

troubleshoot the software.
normal Trace normal events.
packets Trace all IGMP packets.
policy Trace policy processing.
query Trace IGMP membership query messages, including

general and group-specific queries.
report Trace membership report messages.
route Trace routing information.
state Trace state transitions.
task Trace task processing.

Flag Description
timer Trace timer processing.
In the following example, tracing is enabled for all routing protocol packets. Then tracing
is narrowed to focus only on IGMP packets of a particular type. To configure tracing
operations for IGMP:
1. (Optional) Configure tracing at the routing options level to trace all protocol packets.
[edit routing-options traceoptions]

user@host# set file all-packets-trace
user@host# set flag all
2. Configure the filename for the IGMP trace file.
[edit protocols igmp traceoptions]

user@host# set file igmp-trace
3. (Optional) Configure the maximum number of trace files.

user@host# set file files 5
4. (Optional) Configure the maximum size of each trace file.

user@host# set file size 1m
5. (Optional) Enable unrestricted file access.

user@host# set file world-readable
6. Configure tracing flags. Suppose you are troubleshooting issues with a particular
multicast group. The following example shows how to flag all events for packets
associated with the group IP address.

user@host# set flag group | match 233.252.0.2
7. View the trace file.
user@host> file list /var/log

user@host> file show /var/log/igmp-trace

Documentation
• Tracing and Logging Junos OS Operations
• mtrace

Disabling IGMP
To disable IGMP on an interface, include the disable statement:
disable;
• [edit protocols igmp interface interface-name]
• [edit logical-systems logical-system-name protocols igmp interface interface-name]
NOTE: ACX Series routers do not support [edit logical-systems

logical-system-name protocols] hierarchy level.

Documentation


CHAPTER 15
Configuring Internet Group Management

Protocol Snooping
• Understanding IGMP Snooping on page 473

• IGMP Snooping Interfaces and Forwarding on page 475
• IGMP Snooping and Proxies on page 475
• Multicast-Router Interfaces and IGMP Snooping Proxy Mode on page 476
• Host-Side Interfaces and IGMP Snooping Proxy Mode on page 477
• IGMP Snooping and Bridge Domains on page 477
• Configuring IGMP Snooping on page 477
• Configuring VLAN-Specific IGMP Snooping Parameters on page 478
• Example: Configuring IGMP Snooping on page 479
• Configuring IGMP Snooping Trace Operations on page 486
Understanding IGMP Snooping
Snooping is a general way for Layer 2 devices, such as Juniper Networks MX Series Ethernet
Services Routers, to implement a series of procedures to “snoop” at the Layer 3 packet
content to determine which actions are to be taken to process or forward a frame. More
specific forms of snooping, such as Internet Group Membership Protocol (IGMP ) snooping
or Protocol Independent Multicast (PIM) snooping, are used with multicast.
Layer 2 devices (LAN switches or bridges) handle multicast packets and the frames that
contain them much in the same way the Layer 3 devices (routers) handle broadcasts.
So, a Layer 2 switch processes an arriving frame having a multicast destination media
access control (MAC) address by forwarding a copy of the packet (frame) onto each of
the other network interfaces of the switch that are in a forwarding state.
However, this approach (sending multicast frames everywhere the device can) is not the
most efficient use of network bandwidth, particularly for IPTV applications. IGMP snooping
functions by “snooping” at the IGMP packets received by the switch interfaces and building
a multicast database similar to that a multicast router builds in a Layer 3 network. Using
this database, the switch can forward multicast traffic only onto downstream interfaces
with interested receivers, and this technique allows more efficient use of network
bandwidth.

You configure IGMP snooping for each bridge on the router. A bridge instance without
qualified learning has just one learning domain. For a bridge instance with qualified
learning, snooping will function separately within each learning domain in the bridge.
That is, IGMP snooping and multicast forwarding will proceed independently in each
learning domain in the bridge.
This discussion focuses on bridge instances without qualified learning (those forming
one learning domain on the device). Therefore, all the interfaces mentioned are logical
interfaces of the bridge or VPLS instance.
Several related concepts are important when discussing IGMP snooping:
• Bridge or VPLS instance interfaces are either multicast-router interfaces or host-side

interfaces.
• IGMP snooping supports proxy mode or without-proxy mode.
NOTE: When integrated routing and bridging (IRB) is used, if the router is an
IGMP querier, any leave message received on any Layer 2 interface will cause
a group-specific query on all Layer 2 interfaces (as a result of this practice,
some corresponding reports might be received on all Layer 2 interfaces).
However, if some of the Layer 2 interfaces are also router (Layer 3) interfaces,
reports and leaves from other Layer 2 interfaces will not be forwarded on
those interfaces.
If an IRB interface is used as an outgoing interface in a multicast forwarding cache entry

(as determined by the routing process), then the output interface list is expanded into a
subset of the Layer 2 interface in the corresponding bridge. The subset is based on the
snooped multicast membership information, according to the multicast forwarding cache
entry installed by the snooping process for the bridge.
If no snooping is configured, the IRB output interface list is expanded to all Layer 2
interfaces in the bridge.
The Junos OS does not support IGMP snooping in a VPLS configuration on a virtual switch.
This configuration is disallowed in the CLI.
NOTE: IGMP snooping is supported on AE interfaces, however, it is not

supported on AE interfaces in combination with IRB interfaces.
Related • Multicast Overview

Documentation
• Understanding Multicast Snooping
• Example: Configuring IGMP Snooping on page 479
• IGMP Snooping in MC-LAG Active-Active Mode

Chapter 15: Configuring Internet Group Management Protocol Snooping
IGMP Snooping Interfaces and Forwarding
IGMP snooping divides the device interfaces into multicast-router interfaces and host-side
interfaces. A multicast-router interface is an interface in the direction of a multicasting
router. An interface on the bridge is considered a multicast-router interface if it meets at
least one of the following criteria:
• It is statically configured as a multicast-router interface in the bridge instance.
• IGMP queries are being received on the interface.
All other interfaces that are not multicast-router interfaces are considered host-side
interfaces.
Any multicast traffic received on a bridge interface with IGMP snooping configured will
be forwarded according to following rules:
• Any IGMP packet is sent to the Routing Engine for snooping processing.
• Other multicast traffic with destination address 224.0.0/24 is flooded onto all other
interfaces of the bridge.
• Other multicast traffic is sent to all the multicast-router interfaces but only to those
host-side interfaces that have hosts interested in receiving that multicast group.

Documentation
IGMP Snooping and Proxies
Without a proxy arrangement, IGMP snooping does not generate or introduce queries
and reports. It will only “snoop” reports received from all of its interfaces (including
multicast-router interfaces) to build its state and group (S,G) database.
Without a proxy, IGMP messages are processed as follows:
• Query—All general and group-specific IGMP query messages received on a

multicast-router interface are forwarded to all other interfaces (both multicast-router
interfaces and host-side interfaces) on the bridge.
• Report—IGMP reports received on any interface of the bridge are forwarded toward
other multicast-router interfaces. The receiving interface is added as an interface for
that group if a multicast routing entry exists for this group. Also, a group timer is set for
the group on that interface. If this timer expires (that is, there was no report for this
group during the IGMP group timer period), then the interface is removed as an interface
for that group.
• Leave—Any IGMP leave message received on any interface of the bridge. The Leave
Group message reduces the time it takes for the multicast router to stop forwarding
multicast traffic when there are no longer any members in the host group.

Proxy snooping reduces the number of IGMP reports sent toward an IGMP router.
NOTE: With proxy snooping configured, an IGMP router is not able to perform
host tracking.
As proxy for its host-side interfaces, IGMP snooping in proxy mode replies to the queries
it receives from an IGMP router on a multicast-router interface. On the host-side interfaces,
IGMP snooping in proxy mode behaves as an IGMP router and sends general and
group-specific queries on those interfaces.
NOTE: Only group-specific queries are generated by IGMP snooping directly.

General queries received from the multicast-router interfaces are flooded to
host-side interfaces.
All the queries generated by IGMP snooping are sent using 0.0.0.0 as the source address.
Also, all reports generated by IGMP snooping are sent with 0.0.0.0 as the source address
unless there is a configured source address to use.
Proxy mode functions differently on multicast-router interfaces than it does on host-side

interfaces.

Documentation
Multicast-Router Interfaces and IGMP Snooping Proxy Mode
On multicast-router interfaces, in response to IGMP queries, IGMP snooping in proxy

mode sends reports containing aggregate information on groups learned on all host-side
interfaces of the bridge.
Besides replying to queries, IGMP snooping in proxy mode forwards all queries, reports,
and leaves received on a multicast-router interface to other multicast-router interfaces.
IGMP snooping keeps the membership information learned on this interface but does
not send a group-specific query for leave messages received on this interface. It simply
times out the groups learned on this interface if there are no reports for the same group
within the timer duration.
NOTE: For the hosts on all the multicast-router interfaces, it is the IGMP
router, not the IGMP snooping proxy, that generates general and
group-specific queries.

Documentation

Host-Side Interfaces and IGMP Snooping Proxy Mode
No reports are sent on host-side interfaces by IGMP snooping in proxy mode. IGMP
snooping processes reports received on these interfaces and sends group-specific queries
onto host-side interfaces when it receives a leave message on the interface. Host-side
interfaces do not generate periodic general queries, but forwards or floods general queries
received from multicast-router interfaces.
If a group is removed from a host-side interface and this was the last host-side interface
for that group, a leave is sent to the multicast-router interfaces. If a group report is received
on a host-side interface and this was the first host-side interface for that group, a report
is sent to all multicast-router interfaces.

Documentation
IGMP Snooping and Bridge Domains
IGMP snooping on a VLAN is only allowed for the legacy vlan-id all case. In other cases,
there is a specific bridge domain configuration that determines the VLAN-specific
configuration for IGMP snooping.

Documentation
Configuring IGMP Snooping
To configure Internet Group Management Protocol (IGMP) snooping, include the

igmp-snooping statement:
igmp-snooping {
immediate-leave;
group-limit limit;
host-only-interface;
immediate-leave;
multicast-router-interface;
static {
group ip-address {
source ip-address;
}
}
}
proxy {
source-address ip-address;
}

vlan vlan-id {
immediate-leave;
group-limit limit;
immediate-leave;
static {
group ip-address {
source ip-address;
}
}
}
proxy {
}
}
}
• [edit bridge-domains bridge-domain-name protocols]
• [edit routing-instances routing-instance-name bridge-domains bridge-domain-name

protocols]
By default, IGMP snooping is not enabled. Statements configured at the VLAN level apply
only to that particular VLAN.

Documentation
Configuring VLAN-Specific IGMP Snooping Parameters
All of the IGMP snooping statements configured with the igmp-snooping statement, with
the exception of the traceoptions statement, can be qualified with the same statement
at the VLAN level. To configure IGMP snooping parameters at the VLAN level, include
the vlan statement:
vlan vlan-id;
immediate-leave;
group-limit limit;
static {
group ip-address {

source ip-address;
}
}
}
proxy {
}
}
• [edit bridge-domains bridge-domain-name protocols igmp-snooping]
• [edit routing-instances routing-instance-name bridge-domains bridge-domain-name

protocols igmp-snooping]

Documentation
Example: Configuring IGMP Snooping
This example shows how to configure IGMP snooping. IGMP snooping can reduce
unnecessary traffic from IP multicast applications.

• Overview and Topology on page 480
Requirements
This example uses the following hardware components:
• One MX Series router
• One Layer 3 device functioning as a multicast router
Before you begin:
• Configure the interfaces. See the Interfaces Feature Guide for Security Devices.
• Configure an interior gateway protocol. See the Junos OS Routing Protocols Library.
• Configure a multicast protocol. This feature works with the following multicast
protocols:
• DVMRP
• PIM-DM

• PIM-SM
• PIM-SSM
Overview and Topology

IGMP snooping controls multicast traffic in a switched network. When IGMP snooping is
not enabled, the Layer 2 device broadcasts multicast traffic out of all of its ports, even
if the hosts on the network do not want the multicast traffic. With IGMP snooping enabled,
a Layer 2 device monitors the IGMP join and leave messages sent from each connected
host to a multicast router. This enables the Layer 2 device to keep track of the multicast
groups and associated member ports. The Layer 2 device uses this information to make
intelligent decisions and to forward multicast traffic to only the intended destination
hosts.
This example includes the following statements:
• proxy—Enables the Layer 2 device to actively filter IGMP packets to reduce load on the
multicast router. Joins and leaves heading upstream to the multicast router are filtered
so that the multicast router has a single entry for the group, regardless of how many
active listeners have joined the group. When a listener leaves a group but other listeners
remain in the group, the leave message is filtered because the multicast router does
not need this information. The status of the group remains the same from the router's
point of view.
• immediate-leave—When only one IGMP host is connected, the immediate-leave

statement enables the multicast router to immediately remove the group membership
from the interface and suppress the sending of any group-specific queries for the
multicast group.
When you configure this feature on IGMPv2 interfaces, ensure that the IGMP interface
has only one IGMP host connected. If more than one IGMPv2 host is connected to a
LAN through the same interface, and one host sends a leave message, the router
removes all hosts on the interface from the multicast group. The router loses contact
with the hosts that properly remain in the multicast group until they send join requests
in response to the next general multicast listener query from the router.
When IGMP snooping is enabled on a router running IGMP version 3 (IGMPv3) snooping,
after the router receives a report with the type BLOCK_OLD_SOURCES, the router
suppresses the sending of group-and-source queries but relies on the Junos OS
host-tracking mechanism to determine whether or not it removes a particular source
group membership from the interface.
• query-interval—Enables you to change the number of IGMP messages sent on the

subnet by configuring the interval at which the IGMP querier router sends general
host-query messages to solicit membership information.
By default, the query interval is 125 seconds. You can configure any value in the range
1 through 1024 seconds.
• query-last-member-interval—Enables you to change the amount of time it takes a

device to detect the loss of the last member of a group.

The last-member query interval is the maximum amount of time between group-specific
query messages, including those sent in response to leave-group messages.
By default, the last-member query interval is 1 second. You can configure any value in
the range 0.1 through 0.9 seconds, and then 1-second intervals from 1 through 1024
seconds.
• query-response-interval—Configures how long the router waits to receive a response

from its host-query messages.
By default, the query response interval is 10 seconds. You can configure any value in
the range 1 through 1024 seconds. This interval should be less than the interval set in
the query-interval statement.
• robust-count—Provides fine-tuning to allow for expected packet loss on a subnet. It is

basically the number of intervals to wait before timing out a group. You can wait more
intervals if subnet packet loss is high and IGMP report messages might be lost.
By default, the robust count is 2. You can configure any value in the range 2 through 10
intervals.
• group-limit—Configures a limit for the number of multicast groups (or [S,G] channels
in IGMPv3) that can join an interface. After this limit is reached, new reports are ignored
and all related flows are discarded, not flooded.
By default, there is no limit to the number of groups that can join an interface. You can
configure a limit in the range 0 through a 32-bit number.
• host-only-interface—Configure an IGMP snooping interface to be an exclusively host-side

interface. On a host-side interface, received IGMP queries are dropped.
By default, an interface can face either other multicast routers or hosts.
• multicast-router-interface—Configures an IGMP snooping interface to be an exclusively

router-facing interface.
By default, an interface can face either other multicast routers or hosts.
• static—Configures an IGMP snooping interface with multicast groups statically.
By default, the router learns about multicast groups on the interface dynamically.
Figure 24 on page 482 shows networks without IGMP snooping. Suppose host A is an IP
multicast sender and hosts B and C are multicast receivers. The router forwards IP
multicast traffic only to those segments with registered receivers (hosts B and C).
However, the Layer 2 devices flood the traffic to all hosts on all interfaces.

Figure 24: Networks Without IGMP Snooping Configured
g040612
Figure 25 on page 483 shows the same networks with IGMP snooping configured. The
Layer 2 devices forward multicast traffic to registered receivers only.

Figure 25: Networks with IGMP Snooping Configured
g040613
Configuration
configuration, copy and paste the commands into the CLI at the [edit] hierarchy level,
and then enter commit from configuration mode.
set bridge-domains domain1 domain-type bridge

set bridge-domains domain1 interface ge-0/0/1.1
set bridge-domains domain1 protocols igmp-snooping query-interval 200
set bridge-domains domain1 protocols igmp-snooping query-response-interval 0.4
set bridge-domains domain1 protocols igmp-snooping query-last-member-interval 0.1
set bridge-domains domain1 protocols igmp-snooping robust-count 4
set bridge-domains domain1 protocols igmp-snooping immediate-leave
set bridge-domains domain1 protocols igmp-snooping proxy
set bridge-domains domain1 protocols igmp-snooping interface ge-0/0/1.1
host-only-interface
set bridge-domains domain1 protocols igmp-snooping interface ge-0/0/1.1 group-limit
50
set bridge-domains domain1 protocols igmp-snooping interface ge-0/0/3.1 static group
225.100.100.100
set bridge-domains domain1 protocols igmp-snooping interface ge-0/0/2.1
multicast-router-interface

To configure IGMP snooping:
1. Configure the bridge domain.
[edit bridge-domains domain1]

user@host# set domain-type bridge
2. Enable IGMP snooping and configure the router to serve as a proxy.

user@host# set protocols igmp-snooping proxy
3. Configure the limit for the number of multicast groups allowed on the ge-0/0/1.1
interface to 50.

user@host# set protocols igmp-snooping interface ge-0/0/1.1group-limit 50
4. Configure the router to immediately remove a group membership from an interface

when it receives a leave message from that interface without waiting for any other
IGMP messages to be exchanged.

user@host# set protocols igmp-snooping immediate-leave
5. Statically configure IGMP group membership on a port.

user@host# set protocols igmp-snooping interface ge-0/0/3.1 static group
225.100.100.100
6. Configure an interface to be an exclusively router-facing interface (to receive

multicast traffic).

user@host# set protocols igmp-snooping interface ge-0/0/2.1
multicast-router-interface
7. Configure an interface to be an exclusively host-facing interface (to drop IGMP

query messages).

user@host# set protocols igmp-snooping interface ge-0/0/1.1 host-only-interface

8. Configure the IGMP message intervals and robustness count.

user@host# set protocols igmp-snoopingrobust-count 4
user@host# set protocols igmp-snooping query-last-member-interval 0.1
user@host# set protocols igmp-snooping query-interval 200
user@host# set protocols igmp-snooping query-response-interval 0.4
9. If you are done configuring the device, commit the configuration.
user@host# commit
Results Confirm your configuration by entering the show bridge-domains command.
user@host# show bridge-domains

domain1 {
domain-type bridge;
protocols {
igmp-snooping {
query-interval 200;
query-response-interval 0.4;
query-last-member-interval 0.1;
robust-count 4;
immediate-leave;
proxy;
group-limit 50;
}
static {
group 225.100.100.100;
}
}
}
}
}
}
Verification
To verify the configuration, run the following commands:
• show igmp snooping interface
• show igmp snooping membership
• show igmp snooping statistics

Related • Understanding IGMP Snooping on page 473

Documentation
• Host-Side Interfaces and IGMP Snooping Proxy Mode on page 477
• Multicast-Router Interfaces and IGMP Snooping Proxy Mode on page 476
Configuring IGMP Snooping Trace Operations
Flag Description
client-notification Trace notifications.
general Trace general flow.
group Trace group operations.
host-notification Trace host notifications.
leave Trace leave group messages (IGMPv2 only).
packets Trace all IGMP packets.
policy Trace policy processing.
query Trace IGMP membership query messages.
report Trace membership report messages.
task Trace routing protocol task processing.
You can configure tracing operations for IGMP snooping globally or in a routing instance.
The following example shows the global configuration.

To configure tracing operations for IGMP snooping:
1. Configure the filename for the trace file.
[edit bridge-domains domain1 protocols igmp-snooping traceoptions]

user@host# set file igmp-snoop-trace



5. Configure tracing flags. Suppose you are troubleshooting issues with a policy related
to received packets on a particular logical interface with an IP address of 192.168.0.1.
The following example shows how to flag all policy events for received packets
associated with the IP address.

user@host# set flag policy receive | match 192.168.0.1

user@host> file show /var/log/igmp-snoop-trace
Related • Tracing and Logging Junos OS Operations

Documentation
• Configuring IGMP Snooping on page 477


CHAPTER 16
Configuring Point-to-Point Protocol (PPP)
• Supported PPP Interface Standards on ACX Series on page 489

• Configuring PPP Address and Control Field Compression on page 490
• Configuring the PPP Restart Timers on page 491
• Configuring PPP CHAP Authentication on page 492
• Configuring the PPP Clear Loop Detected Timer on page 492
• Configuring Dynamic Profiles for PPP on page 493
• Configuring the PPP Challenge Handshake Authentication Protocol on page 493
• Configuring the PPP Password Authentication Protocol On a Physical
Interface on page 496
• Configuring the PPP Authentication Protocol on page 499
• PPP Encapsulation on ACX Series Routers on page 500
• Configuring Interface Encapsulation on Physical Interfaces in ACX Series on page 501
Supported PPP Interface Standards on ACX Series
Junos OS substantially supports the following RFCs, which define standards for
Point-to-Point Protocol (PPP) interfaces.
• RFC 1332, The PPP Internet Protocol Control Protocol (IPCP)
• RFC 1334, PPP Authentication Protocols
• RFC 1661, The Point-to-Point Protocol (PPP)
Related • Accessing Standards Documents on the Internet

Documentation

Configuring PPP Address and Control Field Compression
For interfaces with PPP, PPP CCC, or PPP TCC encapsulation, you can configure
compression of the Data Link Layer address and control fields, as defined in RFC 1661,
The Point-to-Point Protocol (PPP). By default, the address and control fields are not
compressed. This means PPP-encapsulated packets are transmitted with two 1-byte
fields (0xff and 0x03). If you configure address and control field compression (ACFC)
and ACFC is successfully negotiated with the local router's peer, the local router transmits
packets without these 2 bytes. ACFC allows you to conserve bandwidth by transmitting
less data.
On M320, M120, and T Series routers, ACFC is not supported for any ISO family protocols.
Do not include the acfc statement at the [edit interfaces interface-name ppp-options
compression] hierarchy level when you include the family iso statement at the [edit
interfaces interface-name unit logical-unit-number] hierarchy level.
NOTE: The address and control fields cannot be compressed in Link Control
Protocol (LCP) packets.
The PPP session restarts when you configure or modify compression options.
To configure ACFC:
1. In configuration mode, go to the [edit interfaces interface-name ppp-options] hierarchy

level.
[edit ]
user@host# edit interfaces interface-name ppp-options
2. Include the compression statement at the [edit interfaces interface-name ppp-options]

hierarchy level, and specify acfc.
[edit interfaces interface-name ppp-options]

compression acfc;
To monitor the configuration, issue the show interfaces interface-name command.

Configured options are displayed in the link flags field for the physical interface.
Successfully negotiated options are displayed in the flags field for the logical interface.
In this example, both ACFC and PFC are configured, but neither compression feature has
been successfully negotiated.
user@router# run show interfaces so-0/1/1

Physical interface: so-0/1/1, Enabled, Physical link is Up
Interface index: 133, SNMP ifIndex: 27
Link-level type: PPP, MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3,
Loopback: None, FCS: 16
Payload scrambler: Enabled
Interface flags: Point-To-Point SNMP-Traps 16384
Link flags : No-Keepalives ACFC PFC

Chapter 16: Configuring Point-to-Point Protocol (PPP)
LCP state: Opened

NCP state: inet: Opened, inet6: Not-configured, iso: Not-configured, mpls:
Not-configured
CHAP state: Not-configured
CoS queues : 4 supported
Last flapped : 2004-12-29 10:49:32 PST (00:18:35 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
SONET alarms : None
SONET defects : None
Logical interface so-0/1/1.0 (Index 68) (SNMP ifIndex 169)
Flags: Point-To-Point SNMP-Traps ACFC Encapsulation: PPP
Protocol inet, MTU: 4470
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 3.3.3/24, Local: 3.3.3.2, Broadcast: 3.3.3.255
This configuration causes the local router to try to negotiate ACFC with its peer. If ACFC
is successfully negotiated, the local router sends packets with compressed address and
control fields. When you include the compression acfc statement in the configuration,
the PPP session restarts, and the local router sends the ACFC option in the LCP
Configure-Request packet. The ACFC option informs the local router's peer that the local
router can receive packets with compression. If the peer indicates that it, too, can receive
packets with compression, then ACFC is negotiated. If ACFC is successfully negotiated,
the local router can receive packets with or without the address and control bytes included.
Related • ppp-options on page 1672

Documentation
• compression
• acfc
Configuring the PPP Restart Timers
You can configure a restart timer for the Link Control Protocol (LCP) and Network Control
Protocol (NCP) components of a PPP session. You can configure the LCP restart timer
on interfaces with PPP, PPP TCC, PPP over Ethernet, PPP over ATM, and PPP over Frame
Relay encapsulations. You can configure the NCP restart timer on interfaces with PPP
and PPP TCC encapsulations and on multilink PPP bundle interfaces.
To configure the restart timer for the NCP component of a PPP session, include the
ncp-restart-timer statement, and specify the number of milliseconds.
To configure the restart timer for the LCP component of a PPP session, include the
lcp-restart-timer statement, and specify the number of milliseconds:
lcp-restart-timer milliseconds;
ncp-restart-timer milliseconds;
• [edit interfaces interface-name unit logical-unit-number ppp-options]


logical-unit-number ppp-options]

Configured options are displayed in the PPP parameters field for the physical interface.
user@host> run show interfaces t1-0/0/0:1:1.0 detail

Logical interface t1-0/0/0:1:1.0 (Index 67) (SNMP ifIndex 40)
(Generation 156)
Flags: Hardware-Down Device-Down Point-To-Point SNMP-Traps 0x4000
Encapsulation: PPP
PPP parameters:
LCP restart timer: 2000 msec
NCP restart timer: 2000 msec
Protocol inet, MTU: 1500, Generation: 163, Route table: 0
Flags: Protocol-Down
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Destination: 1.1.1/24, Local: 1.1.1.2, Broadcast: 1.1.1.255,
Configuring PPP CHAP Authentication
For interfaces with PPP encapsulation, you can configure interfaces to support the PPP
Challenge Handshake Authentication Protocol (CHAP), as defined in RFC 1994,
PPP Challenge Handshake Authentication Protocol (CHAP). When you enable CHAP on
an interface, the interface can authenticate its peer and can be authenticated by its peer.
For information about configuring CHAP, see “Configuring the PPP Challenge Handshake
Authentication Protocol” on page 493.
Configuring the PPP Clear Loop Detected Timer
When a Point-to-Point Protocol (PPP) session detects a loop, the loop detected flag is
set. If the flag is not cleared by the protocol after the loopback is cleared, the clear loop
detected timer clears the flag after the specified time has elapsed.
To configure the clear loop detected timer for the LCP component of a PPP session,
include the loopback-clear-timer statement, and specify the number of seconds.
loopback-clear-timer seconds;
• [edit interfaces interface-name unit logical-unit-number ppp-options]

logical-unit-number ppp-options]
To monitor the configuration, issue the show interfaces interface-name extensive command.

Configuring Dynamic Profiles for PPP
A dynamic profile acts as a template that enables you to create, update, or remove a
configuration that includes attributes for client access (for example, interface or protocol)
or service (for example, IGMP). Using these profiles you can consolidate all of the common
attributes of a client (and eventually a group of clients) and apply the attributes
simultaneously.
After they are created, the profiles reside in a profile library on the router. You can then
use the dynamic-profile statement to attach profiles to interfaces. To assign a dynamic
profile to a PPP interface, you can include the dynamic-profile statement at the [edit
interfaces interface-name unit logical-unit-number ppp-options] hierarchy level:
[edit interfaces interface-name unit logical-unit-number ppp-options]

dynamic-profile profile-name;
For information about dynamic profiles, see Dynamic Profiles Overview in the Junos
Subscriber Access Configuration Guide.
For information about creating dynamic profiles, see Configuring a Basic Dynamic Profile
in the Junos Subscriber Access Configuration Guide.
For information about assigning a dynamic profile to a PPP interface, see Attaching
Dynamic Profiles to Static PPP Subscriber Interfaces in the Junos Subscriber Access
Configuration Guide.
NOTE: Dynamic profiles for PPP subscribers are supported only on PPPoE
interfaces for this release.
Related • Configuring Dynamic Authentication for PPP Subscribers

Documentation
Configuring the PPP Challenge Handshake Authentication Protocol
• PPP Challenge Handshake Authentication Protocol on page 493

• Configuring the PPP Challenge Handshake Authentication Protocol on page 494
• Displaying the Configured PPP Challenge Handshake Authentication
Protocol on page 495
PPP Challenge Handshake Authentication Protocol

For interfaces with PPP encapsulation, you can configure interfaces to support the PPP
Challenge Handshake Authentication Protocol (CHAP), as defined in RFC 1994, PPP
Challenge Handshake Authentication Protocol (CHAP). When you enable CHAP on an
interface, the interface can authenticate its peer and can be authenticated by its peer.
By default, PPP CHAP is disabled. If CHAP is not explicitly enabled, the interface makes

no CHAP challenges and denies all incoming CHAP challenges. To enable CHAP, you
must create an access profile, and you must configure the interfaces to use CHAP.
Configuring the PPP Challenge Handshake Authentication Protocol

When you configure an interface to use CHAP, you must assign an access profile to the
interface. When an interface receives CHAP challenges and responses, the access profile
in the packet is used to look up the shared secret, as defined in RFC 1994. If no matching
access profile is found for the CHAP challenge that was received by the interface, the
optionally configured default CHAP secret is used. The default CHAP secret is useful if
the CHAP name of the peer is unknown, or if the CHAP name changes during PPP link
negotiation.
To enable CHAP, you must create an access profile, and you must configure the interfaces
to use PAP. For more information on how to configure access profile, see Configuring
Access Profiles for L2TP or PPP Parameters.
To configure the PPP challenge handshake authentication protocol, on each physical

interface with PPP encapsulation, perform the following steps.
1. To assign an access profile to an interface, include the access-profile statement at

the [edit interfaces interface-name ppp-options chap] hierarchy level.
[edit interfaces interface-name ppp-options chap]

user@host# set access-profile name
NOTE: You must include the access-profile statement when you configure
the CHAP authentication method. If an interface receives a CHAP challenge
or response from a peer that is not in the applied access profile, the link
is immediately dropped unless a default CHAP secret has been configured.
2. The default CHAP secret is used when no matching CHAP access profile exists, or if
the CHAP name changes during PPP link negotiation. To configure a default CHAP
secret for an interface, include the default-chap-secret statement at the [edit interfaces
interface-name ppp-options chap] hierarchy level.

user@host# set default-chap-secret name
3. To configure the name the interface uses in CHAP challenge and response packets,
include the local-name statement at the [edit interfaces interface-name ppp-options
chap] hierarchy level:

user@host# set local-name name

NOTE:
• The local name is any string from 1 through 32 characters in length,
starting with an alphanumeric or underscore character, and including

only the following characters:
a-z A-Z 0-9 % @ # / \ . _ -
• By default, when CHAP is enabled on an interface, the interface uses

the router’s system hostname as the name sent in CHAP challenge and
response packets.
4. You can configure the interface not to challenge its peer, and only respond when
challenged. To configure the interface not to challenge its peer, include the passive
statement at the [edit interfaces interface-name ppp-options chap] hierarchy level:

user@host# set passive;
NOTE: By default, when CHAP is enabled on an interface, the interface

always challenges its peer and responds to challenges from its peer.
Displaying the Configured PPP Challenge Handshake Authentication Protocol
Purpose To display the configured PPP CHAP at the [edit access] and [edit interfaces] hierarchy
levels.
• Access profile—pe-A-ppp-clients
• default CHAP secret data—"$ABC123"
• hostname for the CHAP challenge and response packets—"pe-A-so-1/1/1"
• Interface—so-1/1/2
Action • Run the show command at the [edit access] hierarchy level.
profile pe-A-ppp-clients;
client cpe-1 chap-secret "$ABC123";
# SECRET-DATA
[edit interfaces so-1/2/0]
encapsulation ppp;
ppp-options {
chap {
access-profile pe-A-ppp-clients;
default-chap-secret "$ABC123";
local-name "pe-A-so-1/1/1";
}
}
• Run the show command at the [edit interfaces s0-1/1/2] hierarchy level.

ppp-options {
chap {
access-profile pe-A-ppp-clients;
default-chap-secret "$ABC123";
local-name “pe-A-so-1/1/2";
}
}
Meaning The configured CHAP and its associated set options are displayed as expected.
Configuring the PPP Password Authentication Protocol On a Physical Interface
• Understanding PPP Password Authentication Protocol on page 496

• Configuring the PPP Password Authentication Protocol On a Physical
• Configuring the PPP Password Authentication Protocol On a Logical
Understanding PPP Password Authentication Protocol

For interfaces with PPP encapsulation, you can configure interfaces to support the
Password Authentication Protocol (PAP), as defined in RFC 1334, PAP Authentication
Protocols. If authentication is configured, the PPP link negotiates using CHAP or PAP
protocol for authentication during the Link Control Protocol (LCP) negotiation phase.
PAP is only performed after the link establishment phase (LCP up) portion of the
authentication phase.
During authentication, the PPP link sends a PAP authentication-request packet to the
peer with an ID and password. The authentication-request packet is sent every 2 seconds,
similar to the CHAP challenge, until a response is received (acknowledgment packet,
nonacknowledgment packet). If an acknowledgment packet is received, the PPP link
transitions to the next state, the network phase. If a nonacknowledgment packet is
received, an LCP terminate request is sent, and the PPP link goes back to the link
establishment phase. If no response is received, and an optional retry counter is set to
true, a new request acknowledgment packet is resent. If the retry counter expires, the
PPP link transitions to the LCP negotiate phrase.
You can configure the PPP link with PAP in passive mode. By default, when PAP is enabled
on an interface, the interface expects authenticate-request packets from the peer.
However, the interface can be configured to send authentication request packets to the
peer by configuring PAP to operate in passive mode. In PAP passive mode, the interface
sends the authenticate-request packets to the peer only if the interface receives the PAP
option from the peer during LCP negotiation—in passive mode, the interface does not
authenticate the peer.

Configuring the PPP Password Authentication Protocol On a Physical Interface

When you configure an interface to use PAP, you must assign an access profile to the
interface. When an interface receives PAP authentication requests, the access profile in
the packet is used to look up the password.
To enable PAP, you must create an access profile, and you must configure the interfaces
to use PAP. For more information on how to configure access profile, see Configuring
Access Profiles for L2TP or PPP Parameters.
To configure the PPP password authentication protocol, on each physical interface with
PPP encapsulation, perform the following steps.
1. To assign an access profile to an interface, include the access-profile statement at

the [edit interfaces interface-name ppp-options pap] hierarchy level.
[edit interfaces interface-name ppp-options pap]

user@host# set access-profilename
2. To configure the name the interface uses in PAP request and response packets, include
the local-name statement at the [edit interfaces interface-name ppp-options pap]
hierarchy level:

3. You need to configure the password to be used for authentication. To configure the
host password for sending PAP requests, include the local-password statement at
the [edit interfaces interface-name ppp-options pap] hierarchy level:

user@host# set local-password password
NOTE: By default, when PAP is enabled on an interface, the interface uses

the router’s system hostname as the name sent in PAP request and
response packets.
4. To configure the interface to authenticate with PAP in passive mode, include the
passive statement at the [edit interfaces interface-name ppp-options pap] hierarchy
level:

user@host# set passive

NOTE: By default, when PAP is enabled on an interface, the interface

expects authenticate-request packets from the peer. However, the
interface can be configured to send authentication request packets to the
peer by configuring PAP to operate in passive mode. In PAP passive mode,
the interface sends the authenticate-request packets to the peer only if
the interface receives the PAP option from the peer during LCP
negotiation—in passive mode, the interface does not authenticate the
peer.
Configuring the PPP Password Authentication Protocol On a Logical Interface

When you configure an interface to use PAP, you must assign an access profile to the
interface. When an interface receives PAP authentication requests, the access profile in
the packet is used to look up the password. If no matching access profile is found for the
PAP authentication request that was received by the interface, the optionally configured
default PAP password is used.
To configure the PPP password authentication protocol, on each logical interface with
PPP encapsulation, perform the following steps.
1. To configure the default PAP password, include the pap-password statement at the
[edit interfaces interface-name unit logical-unit-number ppp-options pap] hierarchy
level:
[edit interfaces interface-name unit logical-unt-number ppp-options pap]

user@host# set default-pap-password password
2. To configure the name the interface uses in PAP request and response packets, include
the local-name statement at the [edit interfaces interface-name unit logical-unt-number
ppp-options pap] hierarchy level:

3. You need to configure the password to be used for authentication. To configure the
host password for sending PAP requests, include the local-password statement at
the [edit interfaces interface-name ppp-options pap] hierarchy level:

user@host# set local-password password
NOTE: By default, when PAP is enabled on an interface, the interface uses

the router’s system hostname as the name sent in PAP request and
response packets.

4. To configure the interface to authenticate with PAP in passive mode, include the
passive statement at the [edit interfaces interface-name unit
logical-unt-numberppp-options pap] hierarchy level:

user@host# set passive
NOTE: By default, when PAP is enabled on an interface, the interface

expects authenticate-request packets from the peer. However, the
interface can be configured to send authentication request packets to the
peer by configuring PAP to operate in passive mode. In PAP passive mode,
the interface sends the authenticate-request packets to the peer only if
the interface receives the PAP option from the peer during LCP
negotiation—in passive mode, the interface does not authenticate the
peer.
Configuring the PPP Authentication Protocol
The Point-to-Point Protocol (PPP) is an encapsulation protocol for transporting IP traffic

across point-to-point links. To configure PPP, you can configure the Challenge Handshake
Authentication Protocol (CHAP). CHAP allows each end of a PPP link to authenticate
its peer, as defined in RFC 1994. The authenticator sends its peer a randomly-generated
challenge that the peer must encrypt using a one-way hash; the peer must then respond
with that encrypted result. The key to the hash is a secret known only to the authenticator
and authenticated. When the response is received, the authenticator compares its
calculated result with the peer’s response. If they match, the peer is authenticated.
Each end of the link identifies itself to its peer by including its name in the CHAP challenge
and response packets it sends to the peer. This name defaults to the local hostname, or
you can explicitly set it using the local-name option. When a host receives a CHAP
challenge or CHAP response packet on a particular interface, it uses the peer identity to
look up the CHAP secret key to use.
To configure CHAP, include the profile statement at the [edit access] hierarchy level:
[edit access]
profile profile-name {
client client-name chap-secret chap-secret;
}
Then reference the CHAP profile name at the [edit interfaces] hierarchy level.
You can configure multiple CHAP profiles, and configure multiple clients for each profile.
Definitions:
• profile is the mapping between peer identifiers and CHAP secret keys. The identity of
the peer contained in the CHAP challenge or response queries the profile for the secret
key to use.
• client is the peer identity.

• chap-secret is the secret key associated with that peer.
Related • Example: Configuring PPP CHAP

Documentation
• Example: Configuring CHAP Authentication with RADIUS
PPP Encapsulation on ACX Series Routers
You can configure Point-to-Point Protocol (PPP) encapsulation on physical interfaces

on ACX Series routers. PPP provides a standard method for transporting multiprotocol
datagrams over a point-to-point link. PPP uses the High-Speed Data Link Control (HDLC)
protocol for its physical interface and provides a packet- oriented interface for the
network-layer protocols.
PPP is supported on the following MICs on ACX Series routers:
• On ACX1000 routers with 8-port built-in T1/E1 TDM MICs.
• On ACX2000, ACX2100, ACX2200, and ACX4000 routers with 16-port built-in T1/E1
TDM MICs.
• On ACX4000 routers with 16-Port Channelized E1/T1 Circuit Emulation MICs.
Starting with Release 12.3X54, you can configure Point-to-Point Protocol (PPP)
encapsulation on physical interfaces on Channelized OC3/STM1 (Multi-Rate) Circuit
Emulation MIC with SFP on ACX4000 Series routers
On ACX Series routers, E1, T1, and NxDS0 interfaces support PPP encapsulation.
PPP is the default encapsulation type for physical interfaces. You need not configure
encapsulation for any physical interfaces that support PPP encapsulation. If you do not
configure encapsulation, PPP is used by default. For physical interfaces that do not
support PPP encapsulation, you must configure an encapsulation to use for packets
transmitted on the interface.
To configure the encapsulation on a physical interface, include the encapsulation ppp

statement at the [edit interfaces interface-name] hierarchy level.
IP class of service (CoS) is not supported on PPP interfaces. All the traffic is sent to the
best effort queue (queue 0) and CoS code points are not processed. Also, fixed classifiers
are not supported. Circuit cross-connect (CCC) version of PPP (ppp-ccc option) and
translational cross-connect (TCC) version of PPP (ppp-tcc option) are not supported
for configuration with the encapsulation statement.
PPP is supported only for IPv4 networks. If you configure PPP encapsulation, you can
configure an INET family by including the family inet statement at the [edit interfaces
interface-name unit logical-unit-number] hierarchy level. MPLS family is not supported
on logical interfaces if you configured PPP encapsulation. On interfaces with PPP
encapsulation, configure PPP-specific interface properties by including the ppp-options
statement at the [edit interfaces interface-name] hierarchy level. For interfaces with PPP

encapsulation, you can configure interfaces to support the PPP Challenge Handshake
Authentication Protocol (CHAP) and Password Authentication Protocol (PAP).
For full T1/E1 interfaces on which PPP encapsulation needs to be enabled, create the
T1/E1 interfaces out of channelized T1/E1 interfaces (CT1/CE1) by including the framing
statement at the [edit chassis fpc fpc-slot pic pic-slot] hierarchy level:

Configure a CT1 port down to a T1 channel. On the CT1 interface, set the no-partition
option and then set the interface type as T1.

Configure a CE1 port down to an E1 channel. On the CE1 interface, set the no-partition
option and then set the interface type as E1.
[edit interfaces ce1-mpc-slot/mic-slot/port-number]

For NxDS0 interfaces on which PPP encapsulation needs to be enabled, partition the
CE1 and CT1 interfaces by including the ce1-x/y/z partition partition-number timeslots
timeslots interface-type ds and ct1-x/y/z partition partition-number timeslots timeslots
interface-type ds statements at the [edit interfaces interface-name] hierarchy level.
The following operational mode commands can be used to view PPP configuration
settings and statistical details:
• The show ppp address-pool command is used to display PPP address pool information.
• The show ppp interface command is used to display PPP session information for an
interface.
• The show ppp statistics command is used to display PPP session statistics.
• The show ppp summary command is used to display summary information about
PPP-configured interfaces.
• The show interfaces e1-fpc/pic/port, show interfaces t1-fpc/pic/port, and show interfaces
ds-fpc/pic/port commands are used to display the PPP settings of a specific E1, T1, and
DS interface, respectively.
Related • Configuring Interface Encapsulation on Physical Interfaces in ACX Series on page 501
Documentation
• encapsulation on page 1511
• ppp-options on page 1672
Configuring Interface Encapsulation on Physical Interfaces in ACX Series
Point-to-Point Protocol (PPP) encapsulation is the default encapsulation type for physical
interfaces. You need not configure encapsulation for any physical interfaces that support

PPP encapsulation. If you do not configure encapsulation, PPP is used by default. For
physical interfaces that do not support PPP encapsulation, you must configure an
encapsulation to use for packets transmitted on the interface.
You can optionally configure an encapsulation on a logical interface, which is the

encapsulation used within certain packet types. For more information about logical
interface encapsulation, see Configuring Interface Encapsulation on Logical Interfaces.
• Configuring the Encapsulation on a Physical Interface on page 502

• Encapsulation Capabilities on page 504
Configuring the Encapsulation on a Physical Interface

By default, PPP is the encapsulation type for physical interfaces. To configure the
encapsulation on a physical interface, include the encapsulation statement at the [edit
interfaces interface-name] hierarchy level:

encapsulation (atm-ccc-cell-relay | atm-pvc | cisco-hdlc | cisco-hdlc-ccc | cisco-hdlc-tcc
| ethernet-ccc | ethernet-over-atm | ethernet-tcc | ethernet-vpls |
extended-frame-relay-ccc | extended-frame-relay-ether-type-tcc |
extended-frame-relay-tcc | extended-vlan-ccc | extended-vlan-tcc | extended-vlan-vpls
| flexible-ethernet-services | flexible-frame-relay | frame-relay | frame-relay-ccc |
frame-relay-ether-type | frame-relay-ether-type-tcc | frame-relay-port-ccc |
frame-relay-tcc | multilink-frame-relay-uni-nni | ppp | ppp-ccc | ppp-tcc | vlan-ccc |
vlan-vpls);
NOTE: ACX Series routers do not support cisco-hdlc encapsulation.
The physical interface encapsulation can be one of the following:
• ATM CCC cell relay—Connects two remote virtual circuits or ATM physical interfaces
with a label-switched path (LSP). Traffic on the circuit is ATM cells.
For more information, see the Junos OS Administration Library.
• ATM PVC—Defined in RFC 2684, Multiprotocol Encapsulation over ATM Adaptation

Layer 5. When you configure physical ATM interfaces with ATM PVC encapsulation, an
RFC 2684-compliant ATM Adaptation Layer 5 (AAL5) tunnel is set up to route the
ATM cells over a Multiprotocol Label Switching (MPLS) path that is typically established
between two MPLS-capable routers using the Label Distribution Protocol (LDP).
• Ethernet cross-connect—Ethernet interfaces without VLAN tagging can use

Ethernet CCC encapsulation. Two related versions are supported:
• CCC version (ethernet-ccc)—Ethernet interfaces with standard Tag Protocol ID

(TPID) tagging can use Ethernet CCC encapsulation. When you use this encapsulation
type, you can configure the ccc family only.
• TCC version (ethernet-tcc)—Similar to CCC, but used for circuits with different media
on either side of the connection.

For 8-port, 12-port, and 48-port Fast Ethernet PICs, TCC is not supported.
• VLAN CCC (vlan-ccc)—Ethernet interfaces with VLAN tagging enabled can use VLAN
CCC encapsulation. VLAN CCC encapsulation supports TPID 0x8100 only. When you
use this encapsulation type, you can configure the ccc family only.
• Extended VLAN cross-connect—Gigabit Ethernet interfaces with VLAN 802.1Q tagging

enabled can use extended VLAN cross-connect encapsulation. (Ethernet interfaces
with standard TPID tagging can use VLAN CCC encapsulation.) Two related versions
of extended VLAN cross-connect are supported:
• CCC version (extended-vlan-ccc)—Extended VLAN CCC encapsulation supports

TPIDs 0x8100, 0x9100, and 0x9901. When you use this encapsulation type, you can
configure the ccc family only.
• TCC version (extended-vlan-tcc)—Similar to CCC, but used for circuits with different
media on either side of the connection.
For 8-port, 12-port, and 48-port Fast Ethernet PICs, extended VLAN CCC is not
supported. For 4-port Gigabit Ethernet PICs, extended VLAN CCC and extended
VLAN TCC are not supported.
NOTE: In ACX Series routers, VPLS is supported only on ACX5048 and

ACX5096 routers.
• Ethernet VPLS (ethernet-vpls)—Ethernet interfaces with VPLS enabled can use

Ethernet VPLS encapsulation. For more information about VPLS, see the Junos OS
VPNs Library for Routing Devices.
• Ethernet VLAN VPLS (vlan-vpls)—Ethernet interfaces with VLAN tagging and VPLS
enabled can use Ethernet VLAN VPLS encapsulation. For more information about
VPLS, see the Junos OS VPNs Library for Routing Devices.
• Extended VLAN VPLS (extended-vlan-vpls)—Ethernet interfaces with VLAN 802.1Q

tagging and VPLS enabled can use Ethernet Extended VLAN VPLS encapsulation.
(Ethernet interfaces with standard TPID tagging can use Ethernet VLAN VPLS
encapsulation.) Extended Ethernet VLAN VPLS encapsulation supports TPIDs 0x8100,
0x9100, and 0x9901. For more information about VPLS, see the Junos OS VPNs Library
for Routing Devices.
• Flexible Ethernet services (flexible-ethernet-services)—Gigabit Ethernet and Gigabit

Ethernet IQ and IQE PICs with SFPs (except the 10-port Gigabit Ethernet PIC and the
built-in Gigabit Ethernet port on the M7i router) can use flexible Ethernet services
encapsulation. Aggregated Ethernet bundles can use this encapsulation type. You use
this encapsulation type when you want to configure multiple per-unit Ethernet
encapsulations. This encapsulation type allows you to configure any combination of
route, TCC, CCC, Layer 2 virtual private networks (VPNs), and VPLS encapsulations
on a single physical port. If you configure flexible Ethernet services encapsulation on

the physical interface, VLAN IDs from 1 through 511 are no longer reserved for normal
VLANs.
• PPP—Defined in RFC 1661, The Point-to-Point Protocol (PPP) for the Transmission of
Multiprotocol Datagrams over Point-to-Point Links. PPP is the default encapsulation
type for physical interfaces. E1, E3, SONET/SDH, T1, and T3 interfaces can use PPP
encapsulation.
NOTE: When the encapsulation type is set to Cisco-compatible Frame Relay

encapsulation, ensure that the LMI type is set to ANSI or Q933-A.
In ACX Series routers, VPLS is supported only on ACX5048 and ACX5096

routers.
Encapsulation Capabilities
When you configure a point-to-point encapsulation (such as PPP or Cisco HDLC) on a
physical interface, the physical interface can have only one logical interface (that is, only
one unit statement) associated with it. When you configure a multipoint encapsulation
(such as Frame Relay), the physical interface can have multiple logical units, and the
units can be either point-to-point or multipoint.
Ethernet CCC encapsulation for Ethernet interfaces with standard TPID tagging requires
that the physical interface have only a single logical interface. Ethernet interfaces in VLAN
mode can have multiple logical interfaces.
For Ethernet interfaces in VLAN mode, VLAN IDs are applicable as follows:
• VLAN ID 0 is reserved for tagging the priority of frames.
• For encapsulation type vlan-ccc, VLAN IDs 1 through 511 are reserved for normal VLANs.
VLAN IDs 512 and above are reserved for VLAN CCCs.
When you configure Ethernet virtual LAN (VLAN) encapsulation on CCC circuits (by
using the encapsulation vlan-ccc statement at the [edit interfaces interface-name]
hierarchy level), you can bind a list of VLAN IDs to the interface by using the vlan-id-list
[ vlan-id-numbers ] statement to configure a CCC for multiple VLANs. Configuring this
statement creates a CCC for:
• Each VLAN listed—for example, vlan-id-list [ 100 200 300 ]
• Each VLAN in a range—for example, vlan-id-list [ 100-200 ]
• Each VLAN in a list and range combination—for example, vlan-id-list [ 50, 100-200,
300 ]
• For encapsulation type vlan-vpls, VLAN IDs 1 through 511 are reserved for normal VLANs,
and VLAN IDs 512 through 4094 are reserved for VPLS VLANs. For 4-port Fast Ethernet
interfaces, you can use VLAN IDs 512 through 1024 for VPLS VLANs.
• For Gigabit Ethernet interfaces and Gigabit Ethernet IQ and IQE PICs with SFPs (except
the 10-port Gigabit Ethernet PIC and the built-in Gigabit Ethernet port on the M7i router),

you can configure flexible Ethernet services encapsulation on the physical interface.
For interfaces with flexible-ethernet-services encapsulation, all VLAN IDs are valid.
VLAN IDs from 1 through 511 are not reserved.
• For encapsulation types extended-vlan-ccc and extended-vlan-vpls, all VLAN IDs are
valid.
The upper limits for configurable VLAN IDs vary by interface type.
When you configure a TCC encapsulation, some modifications are needed to handle
VPN connections over unlike Layer 2 and Layer 2.5 links and terminate the Layer 2 and
Layer 2.5 protocol locally.
The router performs the following media-specific change:
• ATM—Operation, Administration, and Maintenance (OAM) and Interim Local

Management Interface (ILMI) processing is terminated at the router. Cell relay is not
supported. The Junos OS strips all ATM encapsulation data from incoming frames
before forwarding them. For output, the next hop is changed to ATM encapsulation.
Example: Configuring the Encapsulation on a Physical Interface
Configure PPP encapsulation on a SONET/SDH interface. The second and third family
statements allow Intermediate System-to-Intermediate System (IS-IS) and MPLS to
run on the interface.
[edit interfaces]
so-7/0/0 {
encapsulation ppp;
unit 0 {
point-to-point;
family inet {
address 192.168.1.113/32 {
destination 192.168.1.114;
}
}
family iso;
family mpls;
}
}
Related • Configuring Interface Encapsulation on Logical Interfaces

Documentation


CHAPTER 17
Configuring MLPPP
• Understanding MLPPP Bundles on ACX Series Routers on page 507

• Guidelines for Configuring MLPPP With LSQ Interfaces on ACX Series
Routers on page 509
• Configuring Encapsulation for Multilink and Link Services Logical Interfaces on page 514
• Configuring the Minimum Number of Active Links on Multilink and Link Services Logical
Interfaces on page 515
• Configuring MRRU on Multilink and Link Services Logical Interfaces on page 516
• Configuring the Sequence Header Format on Multilink and Link Services Logical
• Configuring Multiclass MLPPP on LSQ Interfaces on page 518
• Configuring LSQ Interfaces as NxT1 or NxE1 Bundles Using MLPPP on ACX
Series on page 520
• Example: Configuring an MLPPP Bundle on ACX Series on page 525
Understanding MLPPP Bundles on ACX Series Routers
ACX Series routers support MLPPP encapsulations. MLPPP enables you to bundle multiple
PPP links into a single multilink bundle. Multilink bundles provide additional bandwidth,
load balancing, and redundancy by aggregating low-speed links, such as T1 and E1 links.
You configure multilink bundles as logical units or channels on the link services interface.
With MLPPP, multilink bundles are configured as logical units on the link service
interface—for example, lsq-0/0/0.0,lsq-0/0/0.1. MLPPP is supported on ACX1000,
ACX2000, ACX2100 routers, and with Channelized OC3/STM1 (Multi-Rate) MICs with
SFP and 16-port Channelized E1/T1 Circuit Emulation MIC on ACX4000 routers.
After creating multilink bundles, you add constituent links to the bundle. The constituent
links are the low-speed physical links that are to be aggregated. The following table
shows the maximum number of multilink bundles you can create on ACX Series routers:

Table 43: Multilink Bundles Supported by ACX Series Routers

Maximum Links Per
ACX Platform Maximum Bundles Maximum Links Bundle
ACX2000 16 16 16
ACX2100
ACX4000 16 16 16
ACX-MIC-16CHE1-T1-CE
ACX4000 50 336 16
ACX-MIC-4COC3-1COC12CE
ACX1000 8 8 8
The following rules apply when you add constituent links to a multilink bundle:
• On each multilink bundle, add only interfaces of the same type. For example, you can
add either T1 or E1, but not both.
• Only interfaces with a PPP encapsulation can be added to an MLPPP bundle.
• If an interface is a member of an existing bundle and you add it to a new bundle, the
interface is automatically deleted from the existing bundle and added to the new
bundle.
With multilink PPP bundles, you can use PPP Challenge Handshake Authentication
Protocol (CHAP) and Password Authentication Protocol (PAP) for secure transmission
over the PPP interfaces. For link services IQ (lsq) interfaces only, the maximum number
of multilink classes to be negotiated when a link joins the bundle that you can specify by
using the multilink-max-classes statement at the [edit interfaces interface-name unit
logical-unit-number] hierarchy level is limited to 4. Fragmentation size is not specified
under fragmentation map; instead, fragmentation size configured on the bundle is used.
Compressed Real-Time Transport Protocol (RTP) is not supported. HDLC address and
control field compression (ACFC) and PPP protocol field compression (PFC) are not
supported.
Related • Link and Multilink Services Overview

Documentation
• Multilink Interfaces on Channelized MICs Overview

Chapter 17: Configuring MLPPP
Guidelines for Configuring MLPPP With LSQ Interfaces on ACX Series Routers
You can configure MLPPP bundle interfaces with T1/E1 member links. The traffic that is
transmitted over the MLPPP bundle interface is spread over the member links in a
round-robin manner. If the packet size is higher than the fragmentation size configured
on the MLPPP interface, the packet are fragmented. The fragments are also sent over
member links in a round-robin pattern. The PPP control packets received on the interface
are terminated on the router. The fragmentation size is configured at the MLPPP
bundle-level. This fragmentation size is applied to all the packets on the bundle, regardless
of the multilink class.
Multiclass MLPPP segregates the multilink protocol packets in to multiple classes. ACX
routers support up to a maximum of four classes. One queue is associated with each of
the four classes of multiclass MLPPP (MCML). The packets can be classified to be part
of one of the classes. These packets take the queue associated with the class. The
packets inside a queue are served in first-in first-out (FIFO) sequence.
Multiclass MLPPP is required to provide preferential treatment to high-priority,

delay-sensitive traffic. The delay-sensitive smaller real-time frames are classified such
that they end up in higher priority queue. While a lower priority packet is being fragmented,
if a higher priority packet is enqueued, the lower priority fragmentation is suspended, the
higher priority packet is fragmented and enqueued for transmission, and then the lower
priority packet fragmentation is resumed.
Traditional LSQ interfaces (anchored on PICs) are supported to combine T1/E1 interfaces
in an MLPPP bundle interface. Inline services (si-) interfaces and inline LSQ interfaces
are not supported in MLPPP bundles. On ACX routers, MLPPP bundling is performed on
the TDM MICs and traditional LSQ model is most effective mechanism. You can configure
channelized OC interfaces (t1-x/y/z:n:m, e1-x/y/z:n) as members of an MLPPP bundle
interface. A maximum of 16 member links per bundle is supported. The MPLS, ISO, and
inet address families are supported. The ISO address family is supported only for IS-IS.
You can configure MLPPP bundles on network-to-network interface (NNI) direction of
an Ethernet pseudowire. Interleaving using multiclass MLPPP is supported.
Keep the following points in mind when you configure MLPPP bundles on ACX routers:
• The physical links must be of the same type and bandwidth.
• Round-robin packet distribution is performed over the member links.
• To add a T1 or E1 member link to the MLPPP bundle as link services LSQ interfaces,
include the bundle statement at the [edit interfaces t1-fpc/pic/port unit
logical-unit-number family mlppp] hierarchy level:
[edit interfaces t1-fpc/pic/port unit logical-unit-number family mlppp]

bundle lsq-fpc/pic/port.logical-unit-number;
• To configure the link services LSQ interface properties, include the following statements
at the [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hierarchy level:
[edit interfaces lsq-fpc/pic/port unit logical-unit-number]

encapsulation multilink-ppp;

fragment-threshold bytes;
minimum-links number;
mrru bytes;
short-sequence;
family inet {
address address;
}
You can configure the address family as MPLS for the LSQ interfaces in an MLPPP
bundle.
• PPP control protocol support depends on the processing of the PPP application for
MLPPP bundle interfaces IPv4, Internet Protocol Control Protocol (IPCP), PPP Challenge
Handshake Authentication Protocol (CHAP), and Password Authentication Protocol
(PAP) applications are supported for PPP.
• Drop timeout configuration is not applicable to ACX routers
• The member links across MICs cannot be bundled. Only physical interfaces on the
same MIC can be bundled.
• Fractional T1 and E1 interfaces are not supported. CoS is supported only for full T1 and
E1 interfaces. Selective time slots of T1/E1 cannot be used and full T1/E1 interfaces
must be used.
• Detailed statistics displayed depend on the parameters supported by the hardware.

The counters that are supported by the hardware are displayed with appropriate values
in the output of the show interfaces lsq-fpc/pic/port detail command. In the following
sample output, the fields that are displayed with a value of 0 denote the fields that
are not supported for computation by ACX routers. In the lsq- interface statistics, non-
fragment statistics of the bundle are not accounted. Non-fragments are typically
treated as single-fragment frames and counted in the fragment statistics.
user@host# show interfaces lsq-1/1/0 detail

Physical interface: lsq-1/1/0, Enabled, Physical link is Up
Description: LSQ-interface
Link-level type: LinkService, MTU: 1504
Last flapped : 2015-06-22 19:01:47 PDT (2d 04:56 ago)
Statistics last cleared: 2015-06-23 05:01:49 PDT (1d 18:56 ago)
Traffic statistics:
Input bytes : 108824 208896 bps
Output bytes : 90185 174080 bps
Input packets: 1075 256 pps
Output packets: 1061 256 pps
IPv6 transit statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Frame exceptions:
Oversized frames 0
Errored input frames 0
Input on disabled link/bundle 0
Output for disabled link/bundle 0
Queuing drops 0

Buffering exceptions:
Packet data buffer overflow 0
Fragment data buffer overflow 0
Assembly exceptions:
Fragment timeout 0
Missing sequence number 0
Out-of-order sequence number 0
Out-of-range sequence number 0
Hardware errors (sticky):
Data memory error 0
Control memory error 0
Logical interface lsq-1/1/0.0 (Index 326) (SNMP ifIndex 599) (Generation 177)
Flags: Up Point-To-Point SNMP-Traps 0x0 Encapsulation: Multilink-PPP

Last flapped: 2015-06-24 23:57:34 PDT (00:00:51 ago)
Bandwidth: 6144kbps
Bundle links information:
Active bundle links 4
Removed bundle links 0
Disabled bundle links 0
Bundle options:
MRRU 2000
Remote MRRU 2000
Drop timer period 0
Inner PPP Protocol field compression enabled
Sequence number format short (12 bits)
Fragmentation threshold 450
Links needed to sustain bundle 3
Multilink classes 4
Link layer overhead 4.0 %
Bundle status:
Received sequence number 0x0
Transmit sequence number 0x0
Packet drops 0 (0 bytes)
Fragment drops 0 (0 bytes)
MRRU exceeded 0
Fragment timeout 0
Missing sequence number 0
Out-of-order sequence number 0
Out-of-range sequence number 0
Packet data buffer overflow 0
Fragment data buffer overflow 0
Statistics Frames fps Bytes bps
Bundle:
Multilink:
Input : 1076 256 484200 921600
Output: 1061 256 477450 921600
Network:
Input : 2182 256 201812 208896
Output: 2168 256 192029 174080
IPV6 Transit Statistics Packets Bytes
Network:
Input : 0 0
Output: 0 0
Multilink class 0:
Multilink:
Input : 1075 256 483750 921600
Output: 1061 256 477450 921600
Network:
Input : 1061 256 477450 921600

Output: 1075 256 483750 921600

Multilink class 1:
Multilink:
Input : 0 0 0 0
Output: 0 0 0 0
Network:
Input : 0 0 0 0
Output: 0 0 0 0
Multilink class 2:
Multilink:
Input : 0 0 0 0
Output: 0 0 0 0
Network:
Input : 0 0 0 0
Output: 0 0 0 0
Multilink class 3:
Multilink:
Input : 0 0 0 0
Output: 0 0 0 0
Network:
Input : 0 0 0 0
Output: 0 0 0 0
Link:
t1-1/1/1.0
Up time: 00:00:51
Input : 280 64 126000 230400
Output: 266 64 119700 230400
t1-1/1/2.0
Up time: 00:00:51
Input : 266 64 119700 230400
Output: 265 64 119250 230400
t1-1/1/3.0
Up time: 00:00:51
Input : 265 64 119250 230400
Output: 265 64 119250 230400
t1-1/1/4.0
Up time: 00:00:51
Input : 265 64 119250 230400
Output: 265 64 119250 230400
Multilink detail statistics:
Bundle:
Fragments:
Input : 1076 256 484200 921600
Output: 1061 256 477450 921600
Non-fragments:
Input : 0 0 0 0
Output: 0 0 0 0
LFI:
Input : 0 0 0 0
Output: 0 0 0 0
Multilink class 0:
Fragments:
Input : 1076 256 484200 921600
Output: 1061 256 477450 921600
Non-fragments:
Input : 0 0 0 0
Output: 0 0 0 0
Multilink class 1:
Fragments:
Input : 0 0 0 0
Output: 0 0 0 0

Non-fragments:
Input : 0 0 0 0
Output: 0 0 0 0
Multilink class 2:
Fragments:
Input : 0 0 0 0
Output: 0 0 0 0
Non-fragments:
Input : 0 0 0 0
Output: 0 0 0 0
Multilink class 3:
Fragments:
Input : 0 0 0 0
Output: 0 0 0 0
Non-fragments:
Input : 0 0 0 0
Output: 0 0 0 0
NCP state: inet: Opened, inet6: Not-configured, iso: Opened, mpls: Opened
Protocol inet, MTU: 1500, Generation: 232, Route table: 0
Flags: Sendbcast-pkt-to-re
Destination: 9.1.9/24, Local: 9.1.9.18, Broadcast: Unspecified,
Generation: 212
Protocol iso, MTU: 1500, Generation: 233, Route table: 0
Flags: Is-Primary
Protocol mpls, MTU: 1488, Maximum labels: 3, Generation: 234, Route table:
0
Flags: Is-Primary
• For modifying the frame checksum (FCS) in the set of T1 options or E1 options on a
MLPPP bundle member link, you must remove the member link out of the bundle by
deactivating the link or unconfiguring it as a bundle member, and add the link back to
the bundle after FCS modification. You must first remove the link from the bundle and
modify FCS. If you are configuring FCS for the first time on the member link, specify
the value before it is added to the bundle.
The following MLPPP functionalities are not supported:
• Member links across MICs.
• Fragmentation per class (only configurable at bundle level)
• IPv6 address family header compression (no address and control field compression
[ACFC] or protocol field compression [PFC])
• Prefix elision as defined in RFC 2686, The Multi-Class Extension to Multi-Link PPP
• A functionality that resembles link fragmentation and interleaving (LFI) can be achieved
using multiclass MLPPP (RFC 2686), which interleaves the high priority packets
between lower priority packets. This methodology ensures that the delay desitive
packets are sent as soon as they arrive. While LFI-classified packets are sent to a
specific member link as PPP packets, the ACX implementation of interleaving contains
multilink PPP (also referred to as PPP Multilink, MLP, and MP) headers and fragments
that are sent on all member links in a round-robin manner.
• PPP over MLPPP bundle interfaces

Related •
Documentation
Configuring Encapsulation for Multilink and Link Services Logical Interfaces
NOTE: Only MLPPP is supported on ACX Series routers. MLFR is not supported
on ACX Series routers.
Multilink and link services interfaces support the following logical interface encapsulation
types:
• MLPPP
• MLFR end-to-end
By default, the logical interface encapsulation type on multilink interfaces is MLPPP. The
default logical interface encapsulation type on link services interfaces is MLFR end-to-end.
For general information on encapsulation, see the Junos OS Network Interfaces Library
You can also configure physical interface encapsulation on link services interfaces. For
more information, see Configuring Encapsulation for Link Services Physical Interfaces.
To configure multilink or link services encapsulation, include the encapsulation statement:
encapsulation type;

You must also configure the T1, E1, or DS0 physical interface with the same encapsulation
type.
NOTE: ACX Series routers do not support DS0 physical interface as member
links.
CAUTION: When you configure the first MLFR encapsulated unit or delete
the last MLFR encapsulated unit on a port, it triggers an interface
encapsulation change on the port, which causes an interface flap on the other
units within the port that are configured with generic Frame Relay.

Documentation

• Configuring the Drop Timeout Period on Multilink and Link Services Logical Interfaces
• Limiting Packet Payload Size on Multilink and Link Services Logical Interfaces
• Example: Configuring a Link Services Interface with MLPPP
• encapsulation (Logical Interface)
Configuring the Minimum Number of Active Links on Multilink and Link Services Logical
Interfaces
You can set the minimum number of links that must be up for the multilink bundle as a
whole to be labeled up. By default, only one link must be up for the bundle to be labeled
up. A member link is considered up when the PPP Link Control Protocol (LCP) phase
transitions to open state.
The minimum-links value should be identical on both ends of the bundle.
To set the minimum number, include the minimum-links statement:

For link services interfaces, you also can configure the minimum number of links at the
physical interface level by including the minimum-links statement at the [edit interfaces
ls-fpc/pic/port:channel mlfr-uni-nni-bundle-options] hierarchy level:
The number can be from 1 through 8. The maximum number of links supported in a bundle
is 8. When 8 is specified, all configured links of a bundle must be up.

Documentation

Configuring MRRU on Multilink and Link Services Logical Interfaces
The maximum received reconstructed unit (MRRU) is similar to a maximum transmission

unit (MTU), but applies only to multilink bundles; it is the maximum packet size that the
multilink interface can process. By default, the MRRU is set to 1500 bytes; you can
configure a different MRRU value if the peer equipment allows this. The MRRU accounts
for the original payload, for example the Layer 3 protocol payload, but does not include
the 2-byte PPP header or the additional MLPPP or MLFR header applied while the
individual multilink packets are traversing separate links in the bundle.
To configure a different MRRU value, include the mrru statement:
mrru bytes;

NOTE: ACX Series routers do not support logical systems.
For link services interfaces, you also can configure a different MRRU at the physical
interface level by including the mrru statement at the [edit interfaces
ls-fpc/pic/port:channel mlfr-uni-nni-bundle-options] hierarchy level:
mrru bytes;
The MRRU size can range from 1500 through 4500 bytes.
NOTE: If you set the MRRU on a bundle to a value larger than the MTU of the
individual links within it, you must enable a fragmentation threshold for that
bundle. Set the threshold to a value no larger than the smallest MTU of any
link included in the bundle.
Determine the appropriate MTU size for the bundle by ensuring that the MTU
size does not exceed the sum of the encapsulation overhead and the MTU
sizes for the links in the bundle.
You can configure separate family mtu values on the following protocol families under
bundle interfaces: inet, inet6, iso, and mpls. If not configured, the default value of 1500
is used on all except for mpls configurations, in which the value 1488 is used.

NOTE: ACX Series routers do not support family inet6 on MLPPP interfaces.
NOTE: The effective family MTU might be different from the MTU value
specified for MLPPP configurations, because it is adjusted downward by the
remote MRRU’s constraints. The remote MRRU configuration is not supported
on M120 routers.

Documentation
Configuring the Sequence Header Format on Multilink and Link Services Logical
Interfaces
For MLPPP, the sequence header format is set to 24 bits by default. You can configure
an alternative value of 12 bits, but 24 bits is considered the more robust value for most
networks.
To configure a different sequence header value, include the short-sequence statement:
short-sequence;

For MLFR FRF.15, the sequence header format is set to 24 bits by default. This is the only
valid option.

Documentation

• Configuring DLCIs on Link Services Logical Interfaces
Configuring Multiclass MLPPP on LSQ Interfaces
For link services LSQ (lsq-) interfaces with MLPPP encapsulation, you can configure
multiclass MLPPP (MCML). If you do not configure MCML, fragments from different
classes cannot be interleaved. All fragments for a single packet must be sent before the
fragments from another packet are sent. Nonfragmented packets can be interleaved
between fragments of another packet to reduce latency seen by nonfragmented packets.
In effect, latency-sensitive traffic is encapsulated as regular PPP traffic, and bulk traffic
is encapsulated as multilink traffic. This model works as long as there is a single class of
latency-sensitive traffic, and there is no high-priority traffic that takes precedence over
latency-sensitive traffic. This approach to LFI, used on the Link Services PIC, supports
only two levels of traffic priority, which is not sufficient to carry the four-to-eight forwarding
classes that are supported by M Series and T Series routers. For more information about
the Link Services PIC support of LFI, see Configuring Delay-Sensitive Packet Interleaving
on Link Services Logical Interfaces.
NOTE: ACX Series routers do not support link fragmentation interleaving

(LFI).
For link services LSQ interfaces only, you can configure MCML, as defined in RFC 2686,
The Multi-Class Extension to Multi-Link PPP. MCML makes it possible to have multiple
classes of latency-sensitive traffic that are carried over a single multilink bundle with
bulk traffic. In effect, MCML allows different classes of traffic to have different latency
guarantees. With MCML, you can map each forwarding class into a separate multilink
class, thus preserving priority and latency guarantees.
NOTE: Configuring both LFI and MCML on the same bundle is not necessary,
nor is it supported, because multiclass MLPPP represents a superset of
functionality. When you configure multiclass MLPPP, LFI is automatically
enabled.
The Junos OS implementation of MCML does not support compression of

common header bytes, which is referred to in RFC 2686 as “prefix elision.”
MCML greatly simplifies packet ordering issues that occur when multiple links are used.
Without MCML, all voice traffic belonging to a single flow is hashed to a single link to
avoid packet ordering issues. With MCML, you can assign voice traffic to a high-priority
class, and you can use multiple links. For more information about voice services support
on link services IQ interfaces (lsq), see Configuring Services Interfaces for Voice Services.

To configure MCML on a link services IQ interface, you must specify how many multilink
classes should be negotiated when a link joins the bundle, and you must specify the
mapping of a forwarding class into an MCML class.
To specify how many multilink classes should be negotiated when a link joins the bundle,
include the multilink-max-classes statement:
multilink-max-classes number;
• [edit logical-systems logical-system-name interfaces interface-name

unit logical-unit-number]
The number of multilink classes can be 1 through 8. The number of multilink classes for
each forwarding class must not exceed the number of multilink classes to be negotiated.
NOTE: In ACX Series routers, the multilink classes can be 1 through 4.
To specify the mapping of a forwarding class into a MCML class, include the multilink-class
statement at the [edit class-of-service fragmentation-maps map-name forwarding-class
class-name] hierarchy level:
[edit class-of-service fragmentation-maps map-name forwarding-class class-name]

multilink-class number;
The multilink class index number can be 0 through 7. The multilink-class statement and
no-fragmentation statements are mutually exclusive.
NOTE: In ACX Series routers, the multilink class index number can be 0
through 3. ACX Series routers do not support the no-fragmentation statement
for fragmentation map.
To view the number of multilink classes negotiated, issue the show interfaces
lsq-fpc/pic/port.logical-unit-number detail command.
Related • Layer 2 Service Package Capabilities and Interfaces

Documentation
• Configuring LSQ Interfaces as NxT1 or NxE1 Bundles Using MLPPP
• Configuring LSQ Interfaces for ATM2 IQ Interfaces Using MLPPP
• Configuring LSQ Interfaces for T3 Links Configured for Compressed RTP over MLPPP
• Link Services Configuration for Junos Interfaces

Configuring LSQ Interfaces as NxT1 or NxE1 Bundles Using MLPPP on ACX Series
To configure an NxT1 bundle using MLPPP, you aggregate N different T1 links into a bundle.
The NxT1 bundle is called a logical interface, because it can represent, for example, a
routing adjacency. To aggregate T1 links into a an MLPPP bundle, include the bundle
statement at the [edit interfaces t1-fpc/pic/port unit logical-unit-number family mlppp]
hierarchy level:
[edit interfaces t1-fpc/pic/port unit logical-unit-number family mlppp]

bundle lsq-fpc/pic/port.logical-unit-number;
NOTE: LSQ interfaces support both T1 and E1 physical interfaces. These

instructions apply to T1 interfaces, but the configuration for E1 interfaces is
similar.
To configure the LSQ interface properties, include the following statements at the [edit
interfaces lsq-fpc/pic/port unit logical-unit-number] hierarchy level:
[edit interfaces lsq-fpc/pic/port unit logical-unit-number]

drop-timeout milliseconds;
fragment-threshold bytes;
link-layer-overhead percent;
mrru bytes;
short-sequence;
family inet {
address address;
}
NOTE: ACX Series routers do not support drop-timeout and

link-layer-overhead properties.
The logical link services IQ interface represents the MLPPP bundle. For the MLPPP bundle,
there are four associated queues on M Series routers and eight associated queues on
M320 and T Series routers. A scheduler removes packets from the queues according to
a scheduling policy. Typically, you designate one queue to have strict priority, and the
remaining queues are serviced in proportion to weights you configure.
For MLPPP, assign a single scheduler map to the link services IQ interface (lsq) and to
each constituent link. The default schedulers for M Series and T Series routers, which
assign 95, 0, 0, and 5 percent bandwidth for the transmission rate and buffer size of
queues 0, 1, 2, and 3, are not adequate when you configure LFI or multiclass traffic.
Therefore, for MLPPP, you should configure a single scheduler with nonzero percent
transmission rates and buffer sizes for queues 0 through 3, and assign this scheduler to
the link services IQ interface (lsq) and to each constituent link, as shown in “Example:
Configuring an LSQ Interface as an NxT1 Bundle Using MLPPP” on page 523.

NOTE: For M320 and T Series routers, the default scheduler transmission
rate and buffer size percentages for queues 0 through 7 are 95, 0, 0, 5, 0, 0,
0, and 0 percent.
If the bundle has more than one link, you must include the per-unit-scheduler statement
at the [edit interfaces lsq-fpc/pic/port] hierarchy level:
[edit interfaces lsq-fpc/pic/port]

per-unit-scheduler;
To configure and apply the scheduling policy, include the following statements at the
[edit class-of-service] hierarchy level:
[edit class-of-service]
interfaces {
t1-fpc/pic/port unit logical-unit-number {
scheduler-map map-name;
}
}
forwarding-classes {
queue queue-number class-name;
}
scheduler-maps {
map-name {
forwarding-class class-name scheduler scheduler-name;
}
}
schedulers {
scheduler-name {
buffer-size (percent percentage | remainder | temporal microseconds);
priority priority-level;
transmit-rate (rate | remainder) <exact>;
}
}
For link services IQ interfaces, a strict-high-priority queue might starve the other three
queues because traffic in a strict-high priority queue is transmitted before any other
queue is serviced. This implementation is unlike the standard Junos CoS implementation
in which a strict-high-priority queue does round-robin with high-priority queues, as
described in the Class of Service Feature Guide for Routing Devices.
After the scheduler removes a packet from a queue, a certain action is taken. The action
depends on whether the packet came from a multilink encapsulated queue (fragmented
and sequenced) or a nonencapsulated queue (hashed with no fragmentation). Each
queue can be designated as either multilink encapsulated or nonencapsulated,
independently of the other. By default, traffic in all forwarding classes is multilink
encapsulated. To configure packet fragmentation handling on a queue, include the
fragmentation-maps statement at the [edit class-of-service] hierarchy level:
fragmentation-maps {
map-name {
forwarding-class class-name {
multilink-class number;

}
}
}
For NxT1 bundles using MLPPP, the byte-wise load balancing used in
multilink-encapsulated queues is superior to the flow-wise load balancing used in
nonencapsulated queues. All other considerations are equal. Therefore, we recommend
that you configure all queues to be multilink encapsulated. You do this by including the
fragment-threshold statement in the configuration. You use the multilink-class statement
to map a forwarding class into a multiclass MLPPP (MCML). For more information about
MCML, see “Configuring Multiclass MLPPP on LSQ Interfaces” on page 518. For more
information about fragmentation maps, see Configuring CoS Fragmentation by Forwarding
Class on LSQ Interfaces.
When a packet is removed from a multilink-encapsulated queue, the software gives the
packet an MLPPP header. The MLPPP header contains a sequence number field, which
is filled with the next available sequence number from a counter. The software then
places the packet on one of the N different T1 links. The link is chosen on a
packet-by-packet basis to balance the load across the various T1 links.
If the packet exceeds the minimum link MTU, or if a queue has a fragment threshold
configured at the [edit class-of-service fragmentation-maps map-name forwarding-class
class-name] hierarchy level, the software splits the packet into two or more fragments,
which are assigned consecutive multilink sequence numbers. The outgoing link for each
fragment is selected independently of all other fragments.
If you do not include the fragment-threshold statement in the fragmentation map, the
fragmentation threshold you set at the [edit interfaces interface-name unit
logical-unit-number] hierarchy level is the default for all forwarding classes. If you do not
set a maximum fragment size anywhere in the configuration, packets are fragmented if
they exceed the smallest MTU of all the links in the bundle.
Even if you do not set a maximum fragment size anywhere in the configuration, you can
configure the maximum received reconstructed unit (MRRU) by including the mrru
statement at the [edit interfaces lsq-fpc/pic/port unit logical-unit-number] hierarchy level.
The MRRU is similar to the MTU, but is specific to link services interfaces. By default the
MRRU size is 1500 bytes, and you can configure it to be from 1500 through 4500 bytes.
For more information, see “Configuring MRRU on Multilink and Link Services Logical
Interfaces” on page 516.
When a packet is removed from a nonencapsulated queue, it is transmitted with a plain

PPP header. Because there is no MLPPP header, there is no sequence number information.
Therefore, the software must take special measures to avoid packet reordering. To avoid
packet reordering, the software places the packet on one of the N different T1 links. The
link is determined by hashing the values in the header. For IP, the software computes the
hash based on source address, destination address, and IP protocol. For MPLS, the
software computes the hash based on up to five MPLS labels, or four MPLS labels and
the IP header.
For UDP and TCP the software computes the hash based on the source and destination
ports, as well as source and destination IP addresses. This guarantees that all packets

belonging to the same TCP/UDP flow always pass through the same T1 link, and therefore
cannot be reordered. However, it does not guarantee that the load on the various T1 links
is balanced. If there are many flows, the load is usually balanced.
The N different T1 interfaces link to another router, which can be from Juniper Networks
or another vendor. The router at the far end gathers packets from all the T1 links. If a
packet has an MLPPP header, the sequence number field is used to put the packet back
into sequence number order. If the packet has a plain PPP header, the software accepts
the packet in the order in which it arrives and makes no attempt to reassemble or reorder
the packet.
Example: Configuring an LSQ Interface as an NxT1 Bundle Using MLPPP

[edit interfaces]
lsq-1/1/0 {
per-unit-scheduler;
unit 0 {
mrru 2000;
multilink-max-classes 4;
family inet {
address 20.1.1.1/24;
}
family mpls;
}
}
ct1-1/1/4 {
enable;
}
t1-1/1/4 {
encapsulation ppp;
unit 0 {
family mlppp {
bundle lsq-1/1/0.0;
}
}
}
ct1-1/1/5 {
enable;
}
t1-1/1/5 {
encapsulation ppp;
unit 0 {
family mlppp {
bundle lsq-1/1/0.0;
}
}
}
}
class-of-service {
classifiers {
inet-precedence myIPv4 {
forwarding-class best-effort {

loss-priority low code-points 000;

}
forwarding-class expedited-forwarding {
}
forwarding-class assured-forwarding {
}
forwarding-class network-control {
}
}
}
drop-profiles {
dp1 {
fill-level 50 drop-probability 0;
}
dp2 {
}
}
interfaces {
lsq-1/1/0 {
unit 0 {
scheduler-map sm;
fragmentation-map frag;
rewrite-rules {
inet-precedence myRRIPv4;
}
}
}
}
rewrite-rules {
inet-precedence myRRIPv4 {
forwarding-class best-effort {
loss-priority low code-point 111;
}
}
}
}
}
}
scheduler-maps {
sm {
forwarding-class best-effort scheduler new;
forwarding-class network-control scheduler new_nc;
forwarding-class assured-forwarding scheduler new_af;
forwarding-class expedited-forwarding scheduler new_ef;

}
}
frag {
forwarding-class {
best-effort {
multilink-class 3;
}
network-control {
multilink-class 0;
}
assured-forwarding {
multilink-class 2;
}
expedited-forwarding {
multilink-class 1;
}
}
}
}
schedulers {
new {
transmit-rate 32k;
shaping-rate 3m;
priority low;
drop-profile-map loss-priority low protocol any drop-profile dp1;
drop-profile-map loss-priority high protocol any drop-profile dp2;
}
new_nc {
transmit-rate 32k;
shaping-rate 3m;
priority strict-high;
}
new_af {
transmit-rate 32k;
shaping-rate 3m;
priority medium-low;
}
new_ef {
transmit-rate 32k;
shaping-rate 3m;
priority medium-high;
}
}
}
Example: Configuring an MLPPP Bundle on ACX Series
The following is a sample for configuring an MLPPP bundle on ACX Series routers:
[edit]
user@host# show interfaces
lsq-1/1/0 {
description LSQ-interface;
per-unit-scheduler;

unit 0 {
mrru 2000;
short-sequence;
fragment-threshold 450;
minimum-links 3;
multilink-max-classes 4;
family inet {
address 9.1.9.18/24
}
family iso;
family mpls;
}
}
ct1-1/1/1 {
enable;
}
t1-1/1/1 {
encapsulation ppp;
unit 0 {
family mlppp {
bundle lsq-1/1/0.0;
}
}
}
ct1-1/1/2 {
enable;
}
t1-1/1/2 {
encapsulation ppp;
unit 0 {
family mlppp {
bundle lsq-1/1/0.0;
}
}
}
ct1-1/1/3 {
enable;
}
t1-1/1/3 {
encapsulation ppp;
unit 0 {
family mlppp {
bundle lsq-1/1/0.0;
}
}
}
ct1-1/1/4 {
enable;
}
t1-1/1/4 {
encapsulation ppp;

unit 0 {
family mlppp {
bundle lsq-1/1/0.0;
}
}
}


CHAPTER 18
Configuring Routing Protocols
• IPv6 Overview on page 530

• IPv6 Support on ACX Series Universal Access Routers on page 533
• IS-IS Overview on page 536
• Understanding IS-IS Flood Group on page 541
• OSPF Overview on page 542
• Remote LFA over LDP Tunnels in OSPF Networks Overview on page 547
• Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network on page 548
• Example: Configuring Remote LFA over LDP Tunnels in OSPF Networks on page 550
• Understanding Remote LFA over LDP Tunnels in IS-IS Networks on page 564
• Configuring Remote LFA Backup over LDP Tunnels in an IS-IS Network on page 566
• Example: Configuring Remote LFA over LDP Tunnels in IS-IS Networks on page 568

IPv6 Overview
IP version 6 (IPv6) is the latest version of IP. IP enables numerous nodes on different
networks to interoperate seamlessly. IP version 4 (IPv4) is currently used in intranets
and private networks, as well as the Internet. IPv6 is the successor to IPv4, and is based
for the most part on IPv4.
IPv4 has been widely deployed and used to network the Internet today. With the rapid
growth of the Internet, enhancements to IPv4 are needed to support the influx of new
subscribers, Internet-enabled devices, and applications. IPv6 is designed to enable the
global expansion of the Internet.
IPv6 builds upon the functionality of IPv4, providing improvements to addressing,

configuration and maintenance, and security.
IPv6 offers the following benefits:
• Expanded addressing capabilities—IPv6 provides a larger address space. IPv6 addresses

consist of 128 bits, while IPv4 addresses consist of 32 bits. 128-bit addressing increases
the address space by approximately 1029 unique addresses, enough to last for the
forseeable future.
• Header format simplification—IPv6 packet header format is designed to be efficient.

IPv6 standardizes the size of the packet header to 40 bytes, divided into 8 fields.
• Improved support for extensions and options—Extension headers carry Internet-layer

information and have a standard size and structure.
• Flow labeling capability—Flow labels provide consistent handling of packets belonging

to the same flow.
• Improved privacy and security—IPv6 supports extensions for authentication and data
integrity, which enhance privacy and security.
This section discusses the following topics:
• IPv6 Packet Headers on page 530

• IPv6 Addressing on page 531
IPv6 Packet Headers

IPv6 headers are different from IPv4 headers.
This section discusses the following topics that provide background information about
IPv6 headers:
• Header Structure on page 531

• Extension Headers on page 531

Chapter 18: Configuring Routing Protocols
Header Structure
IPv6 packet headers contain many of the fields found in IPv4 packet headers; some of
these fields have been modified from IPv4. The 40-byte IPv6 header consists of the
following 8 fields:
• Traffic class—Class-of-service (CoS) priority of the packet. Previously the

type-of-service (ToS) field in IPv4. However, the semantics of this field (for example,
DiffServ code points) are identical to IPv4.
• Destination address—Final destination node address for the packet.
• Flow label—Packet flows requiring a specific class of service. The flow label identifies
all packets belonging to a specific flow, and routers can identify these packets and
handle them in a similar fashion.
• Hop limit—Maximum number of hops allowed. Previously the time-to-live (TTL) field
in IPv4.
• Next header—Next extension header to examine. Previously the protocol field in IPv4.
• Payload length—Length of the IPv6 payload. Previously the total length field in IPv4.
• Source address—Address of the source node sending the packet.
• Version—Version of IP.
Extension Headers
In IPv6, extension headers are used to encode optional Internet-layer information.
Extension headers are placed between the IPv6 header and the upper layer header in a
packet.
Extension headers are chained together using the next header field in the IPv6 header.
The next header field indicates to the router which extension header to expect next. If
there are no more extension headers, the next header field indicates the upper layer
header (TCP header, User Datagram Protocol [UDP] header, ICMPv6 header, an
encapsulated IP packet, or other items).
IPv6 Addressing
IPv6 uses a 128-bit addressing model. This creates a much larger address space than
IPv4 addresses, which are made up of 32 bits. IPv6 addresses also contain a scope field
that categorizes what types of applications are suitable for the address. IPv6 does not
support broadcast addresses, but instead uses multicast addresses to serve this role. In
addition, IPv6 also defines a new type of address called anycast.
NOTE: You cannot configure a subnet zero IPv6 address because RFC 2461
reserves the subnet-zero address for anycast addresses, and Junos OS
complies with the RFC.

This section discusses the following topics that provide background information about
IPv6 addressing:
• Address Representation on page 532

• Address Types on page 532
• Address Scope on page 532
• Address Structure on page 533
Address Representation
IPv6 addresses consist of 8 groups of 16-bit hexadecimal values separated by colons

(:). The IPv6 address format is as follows:
aaaa:aaaa:aaaa:aaaa:aaaa:aaaa:aaaa:aaaa
aaaa is a 16-bit hexadecimal value, and a is a 4-bit hexadecimal value. Following is an

example of an actual IPv6 address:
3FFE:0000:0000:0001:0200:F8FF:FE75:50DF
You can omit the leading zeros, as shown:
3FFE:0:0:1:200:F8FF:FE75:50DF
You can compress 16-bit groups of zeros to the notation :: (two colons), as shown here,
but only once per address:
3FFE::1:200:F8FF:FE75:50DF
Address Types
There are three types of IPv6 addresses:
• Unicast—For a single interface.
• Multicast—For a set of interfaces on the same physical medium. A packet is sent to all
of the interfaces associated with the address.
• Anycast—For a set of interfaces on different physical mediums. A packet is sent to only

one of the interfaces associated with this address, not to all the interfaces.
Address Scope
IPv6 addresses have scope, which identifies the application suitable for the address.
Unicast and multicast addresses support scoping.
Unicast addresses support two types of scope: global scope and local scope. There are
two types of local scope: link-local addresses and site-local addresses. Link-local unicast
addresses are used within a single network link. The first ten bits of the prefix identify the
address as a link-local address. Link-local addresses cannot be used outside a network
link. Site-local unicast addresses are used within a site or intranet. A site consists of
multiple network links, and site-local addresses identify nodes inside the intranet.
Site-local addresses cannot be used outside the site.

Multicast addresses support 16 different types of scope, including node, link, site,
organization, and global scope. A 4-bit field in the prefix identifies the scope.
Address Structure
Unicast addresses identify a single interface. The address consists of n bits for the prefix,
and 128 – n bits for the interface ID.
Multicast addresses identify a set of interfaces. The address is made up of the first 8 bits
of all ones, a 4-bit flags field, a 4-bit scope field, and a 112-bit group ID:
11111111 | flags | scope | group ID
The first octet of ones identifies the address as a multicast address. The flags field
identifies whether the multicast address is a well-known address or a transient multicast
address. The scope field identifies the scope of the multicast address. The 112-bit group
ID identifies the multicast group.
Similar to multicast addresses, anycast addresses identify a set of interfaces. However,

packets are sent to only one of the interfaces, not to all interfaces. Anycast addresses
are allocated from the normal unicast address space and cannot be distinguished from
a unicast address in format.
IPv6 Support on ACX Series Universal Access Routers
IPv6 builds upon the functionality of IPv4, providing improvements to addressing,

configuration and maintenance, and security. The following IPv6 features are supported
on ACX Series routers:
• IPv6 path maximum transmission unit (MTU) discovery
Path MTU Discovery is used by single-source devices to determine the correct size of
fragments. Path MTU Discovery is enabled for IPv6 packets by default.
• Dynamic routes distribution through IS-IS and OSPF for IPv6
Routers learn routes through different routing protocols such as OSPF, BGP, or IS-IS.
Learned routes are put in the routing table to enable IPv6 traffic forwarding.
• Dual stacking (IPv4 and IPv6)
Dual stacking allows a device to run both IPv4 and IPv6 at the same time. End nodes,
routers, and switches run both protocols and use IPv6 as the preferred protocol.
• IPv6 forwarding
The ACX Series port forwarding engine software supports unicast IPv6 routes and next
hops. This includes basic route infrastructure, next-hop support, network infrastructure,
and exception packet processing.
• IPv6 over MPLS (6PE)
ACX Series Universal Access Routers can interconnect IPv6 islands over an
MPLS-enabled IPv4 network. IPv6 information is sent over the MPLS core using MG-BGP
with IPv4. The BGP Next Hop field conveys the IPv4 address of the router so that MPLS
LSPs can be used without explicit tunnel configuration.

• Neighbor Discovery
The Neighbor Discovery protocol facilitates a substantial number of functions related

to local network connectivity, datagram routing, and configuration. Both regular hosts
and routers in an IPv6 environment count on the Neighbor Discovery protocol to
facilitate the important exchanges of information that are necessary for proper
internetwork operations. Neighbor Discovery is a messaging protocol similar to ICMP.
The following functions are performed by the protocol:
• Router discovery—How a host locates routers residing on an attached link.
• Prefix discovery—How a host discovers address prefixes for destinations residing on

an attached link. Nodes use prefixes to distinguish between destinations that reside
on an attached link and those destinations that it can reach only through a router.
• Parameter discovery—How a node learns various parameters (link parameters or

Internet parameters) that it places in outgoing packets.
• Address resolution—How a node uses only a destination IPv6 address to determine

a link-layer address for destinations on an attached link.
• Next-hop determination—The algorithm that a node uses for mapping an IPv6

destination address into a neighbor IPv6 address (either the next router hop or the
destination itself) to which it plans to send traffic for the destination.
• Neighbor unreachability detection—How a node determines that it can no longer

reach a neighbor.
• Duplicate address detection—How a node determines whether an address is already

in use by another node.
• Internet Control Message Protocol v6 (ICMPv6)
ICMP sends error messages and information messages related to IP operations. ICMPv6
defines additional error messages and informational messages specific to IPv6.
There are four different ICMPv6 error messages:
• Destination Unreachable—A packet cannot be delivered due to an inherent problem

with how it is being sent. Includes a code that indicates the nature of the problem
that caused the packet not to be delivered
• Packet Too Big—Sent when a packet is too large to be delivered.
• Time Exceeded—A packet cannot be delivered because it has exceeded the hop
count specified in the basic header hop-by-hop field.
• Parameter Problem—Indicates a problem with a field in the IPv6 header or extension

headers that makes it impossible to process the packet.
ICMPv6 information messages are used for sharing the information required to
implement various test, diagnostic, and support functions that are critical to the
operation of IPv6. There are a total of eight different ICMPv6 informational messages:
• Echo Request—
• Echo Reply—

• Router Advertisement—
• Router Solicitation—
• Neighbor Advertisement—
• Neighbor Solicitation—
• Redirect—
• Router Renumbering—
• Static routes for IPv6
Routing information can be configured statically. Whenever a route is configured

statically, the routing information base (RIB) is updated with routes specified through
the static route. These routes should be configured statically in the “routing-options”
hierarchy. The following configuration is used for enabling static routes for IPv6:
interfaces {
fe/0/1/0 {
unit 0 {
family inet6 {
address fec0:0:0:3::1/64;
}
}
}
}
routing-options {
rib inet6.0 {
static {
route fec0:0:0:4::/64 next-hop fec0:0:0:3::ffff;
}
}
}
user@router> show route table inet6.0

inet6.0: 3 destination, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
fec0:0:0:3::/64 *[Direct/0] 00:01:34
> via fe-0/1/0.0
fec:0:0:0:3::1/128 *[Local/0] 00:01:34
Local
fec0:0:0:4::/64 *[Static/5] 00:01:34
> to fec0:0:03:ffff via fe-0/1/0.0
Related • IPv6 Overview on page 530

Documentation
• Understanding Dual Stacking of IPv4 and IPv6 Unicast Addresses
• IS-IS Overview on page 536
• OSPF Overview on page 542

• ICMP Router Discovery Overview
• MPLS Overview for ACX Series Universal Access Routers on page 587
• Configuring Junos OS for IPv6 Path MTU Discovery
• IPv6 Neighbor Discovery Overview
IS-IS Overview
The IS-IS protocol is an interior gateway protocol (IGP) that uses link-state information
to make routing decisions.
IS-IS is a link-state IGP that uses the shortest-path-first (SPF) algorithm to determine
routes. IS-IS evaluates the topology changes and determines whether to perform a full
SPF recalculation or a partial route calculation (PRC). This protocol originally was
developed for routing International Organization for Standardization (ISO) Connectionless
Network Protocol (CLNP) packets.
Like OSPF routing, IS-IS uses hello packets that allow network convergence to occur
quickly when network changes are detected. IS-IS uses the SPF algorithm to determine
routes. Using SPF, IS-IS evaluates network topology changes and determines if a full or
partial route calculation is required.
NOTE: Because IS-IS uses ISO addresses, the configuration of IP version 6

(IPv6) and IP version 4 (IPv4) implementations of IS-IS is identical.
NOTE: See Platforms/FPCs That Cannot Forward TCC Encapsulated ISO

Traffic to find a list of those devices and FPC configurations that cannot pass
ISO traffic when encapsulated in TCC format.
• IS-IS Terminology on page 536

• ISO Network Addresses on page 537
• IS-IS Packets on page 539
• Persistent Route Reachability on page 540
• IS-IS Support for Multipoint Network Clouds on page 540
• Installing a Default Route to the Nearest Routing Device That Operates at Both IS-IS
Levels on page 540
IS-IS Terminology
An IS-IS network is a single autonomous system (AS), also called a routing domain, that
consists of end systems and intermediate systems. End systems are network entities that
send and receive packets. Intermediate systems send and receive packets and relay

(forward) packets. (Intermediate system is the Open System Interconnection [OSI] term
for a router.) ISO packets are called network PDUs.
In IS-IS, a single AS can be divided into smaller groups called areas. Routing between
areas is organized hierarchically, allowing a domain to be administratively divided into
smaller areas. This organization is accomplished by configuring Level 1 and Level 2
intermediate systems. Level 1 systems route within an area; when the destination is
outside an area, they route toward a Level 2 system. Level 2 intermediate systems route
between areas and toward other ASs. No IS-IS area functions strictly as a backbone.
Level 1 routers share intra-area routing information, and Level 2 routers share interarea
information about IP addresses available within each area. Uniquely, IS-IS routers can
act as both Level 1 and Level 2 routers, sharing intra-area routes with other Level 1 routers
and interarea routes with other Level 2 routers.
The propagation of link-state updates is determined by the level boundaries. All routers
within a level maintain a complete link-state database of all other routers in the same
level. Each router then uses the Dijkstra algorithm to determine the shortest path from
the local router to other routers in the link-state database.
ISO Network Addresses

IS-IS uses ISO network addresses. Each address identifies a point of connection to the
network, such as a router interface, and is called a network service access point (NSAP).
IS-IS supports multiple NSAP addresses on the loopback lo0 interface.
An end system can have multiple NSAP addresses, in which case the addresses differ
only by the last byte (called the n-selector). Each NSAP represents a service that is
available at that node. In addition to having multiple services, a single node can belong
to multiple areas.
Each network entity also has a special network address called a network entity title (NET).
Structurally, an NET is identical to an NSAP address but has an n-selector of 00. Most
end systems and intermediate systems have one NET. Intermediate systems that
participate in multiple areas can have multiple NETs.
The following ISO addresses illustrate the IS-IS address format:
49.0001.00a0.c96b.c490.00
49.0001.2081.9716.9018.00
NETs take several forms, depending on your network requirements. NET addresses are
hexadecimal and range from 8 octets to 20 octets in length. Generally, the format consists
of an authority and format Identifier (AFI), a domain ID, an area ID, a system identifier,
and a selector. The simplest format omits the domain ID and is 10 octets long. For
example, the NET address 49.0001.1921.6800.1001.00 consists of the following parts:
• 49—AFI
• 0001—Area ID

• 1921.6800.1001—System identifier
• 00—Selector
The system identifier must be unique within the network. For an IP-only network, we
recommend using the IP address of an interface on the router. Configuring a loopback
NET address with the IP address is helpful when troubleshooting is required on the
network.
The first portion of the address is the area number, which is a variable number from 1
through 13 bytes. The first byte of the area number (49) is the authority and format
indicator (AFI). The next bytes are the assigned domain (area) identifier, which can be
from 0 through 12 bytes. In the examples above, the area identifier is 0001.
The next six bytes form the system identifier. The system identifier can be any six bytes
that are unique throughout the entire domain. The system identifier commonly is the
media access control (MAC) address (as in the first example, 00a0.c96b.c490) or the
IP address expressed in binary-coded decimal (BCD) (as in the second example,
2081.9716.9018, which corresponds to IP address 208.197.169.18). The last byte (00) is
the n-selector.
NOTE: The system identifier cannot be 0000.0000.0000. All 0s is an illegal

setting, and the adjacency is not formed with this setting.
®
To provide help with IS-IS debugging, the Junos operating system (Junos OS) supports
dynamic mapping of ISO system identifiers to the hostname. Each system can be
configured with a hostname, which allows the system identifier-to-hostname mapping
to be carried in a dynamic hostname type, length, and value (TLV) tuple in IS-IS link-state
PDUs. This enables intermediate systems in the routing domain to learn about the ISO
system identifier of a particular intermediate system.

IS-IS Packets
Each IS-IS PDU shares a common header. IS-IS uses the following PDUs to exchange
protocol information:
• IS-IS hello (IIH) PDUs—Broadcast to discover the identity of neighboring IS-IS systems
and to determine whether the neighbors are Level 1 or Level 2 intermediate systems.
IS-IS hello PDUs establish adjacencies with other routers and have three different
formats: one for point-to-point hello packets, one for Level 1 broadcast links, and one
for Level 2 broadcast links. Level 1 routers must share the same area address to form
an adjacency, while Level 2 routers do not have this limitation. The request for adjacency
is encoded in the Circuit type field of the PDU.
Hello PDUs have a preset length assigned to them. The IS-IS router does not resize
any PDU to match the maximum transmission unit (MTU) on a router interface. Each
interface supports the maximum IS-IS PDU of 1492 bytes, and hello PDUs are padded
to meet the maximum value. When the hello is sent to a neighboring router, the
connecting interface supports the maximum PDU size.
• Link-state PDUs—Contain information about the state of adjacencies to neighboring

IS-IS systems. Link-state PDUs are flooded periodically throughout an area.
Also included is metric and IS-IS neighbor information. Each link-state PDU must be
refreshed periodically on the network and is acknowledged by information within a
sequence number PDU.
On point-to-point links, each link-state PDU is acknowledged by a partial sequence

number PDU (PSNP), but on broadcast links, a complete sequence number PDU
(CSNP) is sent out over the network. Any router that finds newer link-state PDU
information in the CSNP then purges the out-of-date entry and updates the link-state
database.
Link-state PDUs support variable-length subnet mask addressing.
• Complete sequence number PDUs (CSNPs)—Contain a complete list of all link-state

PDUs in the IS-IS database. CSNPs are sent periodically on all links, and the receiving
systems use the information in the CSNP to update and synchronize their link-state
PDU databases. The designated router multicasts CSNPs on broadcast links in place
of sending explicit acknowledgments for each link-state PDU.
Contained within the CSNP is a link-state PDU identifier, a lifetime, a sequence number,
and a checksum for each entry in the database. Periodically, a CSNP is sent on both
broadcast and point-to-point links to maintain a correct database. Also, the
advertisement of CSNPs occurs when an adjacency is formed with another router. Like
IS-IS hello PDUs, CSNPs come in two types: Level 1 and Level 2.
When a device receives a CSNP, it checks the database entries against its own local
link-state database. If it detects missing information, the device requests specific
link-state PDU details using a partial sequence number PDU (PSNP).
• Partial sequence number PDUs (PSNPs)—Sent multicast by a receiver when it detects

that it is missing a link-state PDU (when its link-state PDU database is out of date).
The receiver sends a PSNP to the system that transmitted the CSNP, effectively

requesting that the missing link-state PDU be transmitted. That routing device, in turn,
forwards the missing link-state PDU to the requesting routing device.
A PSNP is used by an IS-IS router to request link-state PDU information from a

neighboring router. A PSNP can also explicitly acknowledge the receipt of a link-state
PDU on a point-to-point link. On a broadcast link, a CSNP is used as implicit knowledge.
Like hello PDUs and CSNPs, the PSNP also has two types: Level 1 and Level 2.
When a device compares a CSNP to its local database and determines that a link-state
PDU is missing, the router issues a PSNP for the missing link-state PDU, which is returned
in a link-state PDU from the router sending the CSNP. The received link-state PDU is
then stored in the local database, and an acknowledgment is sent back to the originating
router.
Persistent Route Reachability

IPv4 and IPv6 route reachability information in IS-IS link-state PDUs is preserved when
you commit a configuration. IP prefixes are preserved with their original packet fragment
upon link-state PDU regeneration.
IS-IS Support for Multipoint Network Clouds

IS-IS does not support multipoint configurations. Therefore, when configuring Frame
Relay or Asynchronous Transfer Mode (ATM) networks, you must configure them as
collections of point-to-point links, not as multipoint clouds.
Installing a Default Route to the Nearest Routing Device That Operates at Both IS-IS Levels
When a routing device that operates as both a Level 1 and Level 2 router (Router B)
determines that it can reach at least one area other than its own (for example, in Area
Y), it sets the ATTACHED bit in its Level 1 link-state PDU. Thereafter, the Level 1 router
(Router A) introduces a default route pointing to the nearest attached routing device
that operates as both a Level 1 and Level 2 router (Router B). See Figure 26 on page 540.
Figure 26: Install Default Route to Nearest Routing Device That Operates
at Both Level 1 and Level 2

Related • Understanding IS-IS Configuration

Documentation
• Example: Configuring IS-IS
Understanding IS-IS Flood Group
IS-IS supports flood-group. This feature limits link-state packet data unit (PDU) flooding
over IS-IS interfaces.
A link-state packet (LSP) that is not self-originated will be flooded only through the
interface belonging to the flood group that has the configured area ID in the LSP. This
helps minimize the routes and topology information, thus ensuring optimal convergence.
You can segregate both Level 1 and Level 2 IS-IS routers into flood groups by using area
IDs as tags to identify a flood group. Configure interfaces with specific area IDs to modify
the flooding behavior as per your requirements. To enable IS-IS flood group, include the
flood-group flood-group-area-ID statement at the [edit protocols isis interface] hierarchy
level.
Related • IS-IS Overview on page 536

Documentation
• Example: Configuring IS-IS Flood Group

OSPF Overview

OSPF is an interior gateway protocol (IGP) that routes packets within a single autonomous
system (AS). OSPF uses link-state information to make routing decisions, making route
calculations using the shortest-path-first (SPF) algorithm (also referred to as the Dijkstra
algorithm). Each router running OSPF floods link-state advertisements throughout the
AS or area that contain information about that router’s attached interfaces and routing
metrics. Each router uses the information in these link-state advertisements to calculate
the least cost path to each network and create a routing table for the protocol.
Junos OS supports OSPF version 2 (OSPFv2) and OSPF version 3 (OSPFv3), including
virtual links, stub areas, and for OSPFv2, authentication. Junos OS does not support
type-of-service (ToS) routing.
OSPF was designed for the Transmission Control Protocol/Internet Protocol (TCP/IP)
environment and as a result explicitly supports IP subnetting and the tagging of externally
derived routing information. OSPF also provides for the authentication of routing updates.
OSPF routes IP packets based solely on the destination IP address contained in the IP
packet header. OSPF quickly detects topological changes, such as when router interfaces
become unavailable, and calculates new loop-free routes quickly and with a minimum
of routing overhead traffic.
NOTE: On SRX Series devices, when only one link-protection is configured

under the OSPF interface, the device does not install an alternative route in
the forwarding table. When the per-packet load-balancing is enabled as a
workaround, the device does not observe both the OSPF metric and sending
the traffic through both the interfaces.
An OSPF AS can consist of a single area, or it can be subdivided into multiple areas. In a
single-area OSPF network topology, each router maintains a database that describes
the topology of the AS. Link-state information for each router is flooded throughout the
AS. In a multiarea OSPF topology, each router maintains a database that describes the
topology of its area, and link-state information for each router is flooded throughout that
area. All routers maintain summarized topologies of other areas within an AS. Within
each area, OSPF routers have identical topological databases. When the AS or area
topology changes, OSPF ensures that the contents of all routers’ topological databases
converge quickly.
All OSPFv2 protocol exchanges can be authenticated. OSPFv3 relies on IPsec to provide
this functionality. This means that only trusted routers can participate in the AS’s routing.
A variety of authentication schemes can be used. A single authentication scheme is
configured for each area, which enables some areas to use stricter authentication than
others.
Externally derived routing data (for example, routes learned from BGP) is passed
transparently throughout the AS. This externally derived data is kept separate from the
OSPF link-state data. Each external route can be tagged by the advertising router, enabling
the passing of additional information between routers on the boundaries of the AS.

NOTE: By default, Junos OS is compatible with RFC 1583, OSPF Version 2. In

Junos OS Release 8.5 and later, you can disable compatibility with RFC 1583
by including the no-rfc-1583 statement. For more information, see Example:
Disabling OSPFv2 Compatibility with RFC 1583.
This topic describes the following information:
• OSPF Default Route Preference Values on page 544

• OSPF Routing Algorithm on page 544
• OSPF Three-Way Handshake on page 545
• OSPF Version 3 on page 546
OSPF Default Route Preference Values

The Junos OS routing protocol process assigns a default preference value to each route
that the routing table receives. The default value depends on the source of the route.
The preference value is from 0 through 4,294,967,295 (232 – 1), with a lower value
indicating a more preferred route. Table 44 on page 544 lists the default preference values
for OSPF.
Table 44: Default Route Preference Values for OSPF

How Route Is Learned Default Preference Statement to Modify Default Preference
OSPF internal route 10 OSPF preference
OSPF AS external routes 150 OSPF external-preference
OSPF Routing Algorithm

OSPF uses the shortest-path-first (SPF) algorithm, also referred to as the Dijkstra
algorithm, to determine the route to each destination. All routing devices in an area run
this algorithm in parallel, storing the results in their individual topological databases.
Routing devices with interfaces to multiple areas run multiple copies of the algorithm.
This section provides a brief summary of how the SPF algorithm works.
When a routing device starts, it initializes OSPF and waits for indications from lower-level
protocols that the router interfaces are functional. The routing device then uses the OSPF
hello protocol to acquire neighbors, by sending hello packets to its neighbors and receiving
their hello packets.
On broadcast or nonbroadcast multiaccess networks (physical networks that support

the attachment of more than two routing devices), the OSPF hello protocol elects a
designated router for the network. This routing device is responsible for sending link-state
advertisements (LSAs) that describe the network, which reduces the amount of network
traffic and the size of the routing devices’ topological databases.
The routing device then attempts to form adjacencies with some of its newly acquired
neighbors. (On multiaccess networks, only the designated router and backup designated

router form adjacencies with other routing devices.) Adjacencies determine the distribution
of routing protocol packets. Routing protocol packets are sent and received only on
adjacencies, and topological database updates are sent only along adjacencies. When
adjacencies have been established, pairs of adjacent routers synchronize their topological
databases.
A routing device sends LSA packets to advertise its state periodically and when its state
changes. These packets include information about the routing device’s adjacencies,
which allows detection of nonoperational routing devices.
Using a reliable algorithm, the routing device floods LSAs throughout the area, which
ensures that all routing devices in an area have exactly the same topological database.
Each routing device uses the information in its topological database to calculate a
shortest-path tree, with itself as the root. The routing device then uses this tree to route
network traffic.
The description of the SPF algorithm up to this point has explained how the algorithm
works within a single area (intra-area routing). For internal routers to be able to route to
destinations outside the area (interarea routing), the area border routers must inject
additional routing information into the area. Because the area border routers are
connected to the backbone, they have access to complete topological data about the
backbone. The area border routers use this information to calculate paths to all
destinations outside its area and then advertise these paths to the area’s internal routers.
Autonomous system (AS) boundary routers flood information about external autonomous
systems throughout the AS, except to stub areas. Area border routers are responsible
for advertising the paths to all AS boundary routers.
OSPF Three-Way Handshake

OSPF creates a topology map by flooding LSAs across OSPF-enabled links. LSAs
announce the presence of OSPF-enabled interfaces to adjacent OSPF interfaces. The
exchange of LSAs establishes bidirectional connectivity between all adjacent OSPF
interfaces (neighbors) using a three-way handshake, as shown in Figure 27 on page 545.
Figure 27: OSPF Three-Way Handshake
In Figure 27 on page 545, Router A sends hello packets out all its OSPF-enabled interfaces
when it comes online. Router B receives the packet, which establishes that Router B can
receive traffic from Router A. Router B generates a response to Router A to acknowledge
receipt of the hello packet. When Router A receives the response, it establishes that
Router B can receive traffic from Router A. Router A then generates a final response
packet to inform Router B that Router A can receive traffic from Router B. This three-way
handshake ensures bidirectional connectivity.

As new neighbors are added to the network or existing neighbors lose connectivity, the
adjacencies in the topology map are modified accordingly through the exchange (or
absence) of LSAs. These LSAs advertise only the incremental changes in the network,
which helps minimize the amount of OSPF traffic on the network. The adjacencies are
shared and used to create the network topology in the topological database.
OSPF Version 3
OSPFv3 is a modified version of OSPF that supports IP version 6 (IPv6) addressing.
OSPFv3 differs from OSPFv2 in the following ways:
• All neighbor ID information is based on a 32-bit router ID.
• The protocol runs per link rather than per subnet.
• Router and network link-state advertisements (LSAs) do not carry prefix information.
• Two new LSA types are included: link-LSA and intra-area-prefix-LSA.
• Flooding scopes are as follows:
• Link-local
• Area
• AS
• Link-local addresses are used for all neighbor exchanges except virtual links.
• Authentication is removed. The IPv6 authentication header relies on the IP layer.
• The packet format has changed as follows:
• Version number 2 is now version number 3.
• The db option field has been expanded to 24 bits.
• Authentication information has been removed.
• Hello messages do not have address information.
• Two new option bits are included: R and V6.
• Type 3 summary LSAs have been renamed inter-area-prefix-LSAs.
• Type 4 summary LSAs have been renamed inter-area-router-LSAs.
Related • Understanding OSPF Areas and Backbone Areas

Documentation
• Understanding OSPF Configurations
• Example: Disabling OSPFv2 Compatibility with RFC 1583

Remote LFA over LDP Tunnels in OSPF Networks Overview
In an OSPF network, a loop free alternate (LFA) is a directly connected neighbor that
provides precomputed backup paths to the destinations reachable through the protected
link on the point of local repair (PLR). A remote LFA is not directly connected to the PLR
and provides precomputed backup paths using dynamically created LDP tunnels to the
remote LFA node. The PLR uses this remote LFA backup path when the primary link fails.
The primary goal of the remote LFA is to increase backup coverage for the OSPF networks
and provide protection for Layer 1 metro-rings.
LFAs do not provide full backup coverage for OSPF networks. This is a major setback for
metro Ethernet networks that are often shaped as ring topologies. To overcome this
setback, Resource Reservation Protocol - Traffic Engineering (RSVP-TE) backup tunnels
are commonly used to extend the backup coverage. However, a majority of network
providers have already implemented LDP as the MPLS tunnel setup protocol and do not
want to implement the RSVP-TE protocol merely for backup coverage. LDP automatically
brings up transport tunnels to all potential destinations in an OSPF network and hence
is the preferred protocol. The existing LDP implemented for the MPLS tunnel setup can
be reused for protection of OSPF networks and subsequent LDP destinations, thereby
eliminating the need for RSVP-TE backup tunnels for backup coverage.
To calculate the remote LFA backup path, the OSPF protocol determines the remote
LFA node in the following manner:
1. Calculates the reverse shortest path first from the adjacent router across the protected
link of a PLR. The reverse shortest path first uses the incoming link metric instead of
the outgoing link metric to reach a neighboring node.
The result is a set of links and nodes, which is the shortest path from each leaf node
to the root node.
2. Calculates the shortest path first (SPF) on the remaining adjacent routers to find the
list of nodes that can be reached without traversing the link being protected.
The result is another set of links and nodes on the shortest path from the root node
to all leaf nodes.
3. Determines the common nodes from the above results. These nodes are the remote
LFAs.
OSPF listens to the advertised labels for the LDP routes. For each advertised LDP route,
OSPF checks whether it contains an LDP supplied next hop. If the corresponding OSPF
route does have a backup next hop, then OSPF runs the backup policy and adds an
additional tracking route with the corresponding LDP label-switched path next hop as
the backup next hop. If there are no backup next hops, LDP builds a dynamic LDP tunnel
to the remote LFA, and LDP establishes a targeted adjacency between the remote LFA
node and the PLR node. This backup route has two LDP labels. The top label is the OSPF
route, which denotes the backup path from the PLR to the remote LFA route. The bottom
label is the LDP MPLS label-switched path that denotes the route for reaching the ultimate

destination from the remote LFA. When an LDP session goes down and a remote tunnel
is no longer available, OSPF changes all the routes that have been using this backup LDP
tunnel.
NOTE: Currently, Junos OS supports only IPv4 transport LSPs. If you need to
reuse IPv4 transport LSPs for IPv6 IGP networks, add an IPv6 explicit NULL
label to the label stack of the tracking route. The system automatically
converts the IPv4 LSP to an IPv6 LSP.
LDP might be vulnerable by an automatically targeted adjacency, and these threats can
be mitigated using all or some of the following mechanisms:
• Remote LFAs that are several hops away use extended hello messages to indicate
willingness to establish a targeted LDP session. A remote LFA can reduce the threat
of spoofed extended hello messages by filtering them and accepting only those
originating at sources permitted by an access or filter list.
• There is a need to authenticate with TCP-MD5 all auto-targeted LDP sessions in the
given IGP/LDP domain using apply groups or LDP global-level authentication.
• As an added security measure, the repair or remote tunnel endpoint routers should be
assigned from a set of addresses that are not reachable from outside of the routing
domain.
Related • Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks
Documentation
• auto-targeted-session
• no-eligible-remote-backup
• remote-backup-calculation
Configuring Remote LFA Backup over LDP Tunnels in an OSPF Network
The primary goal of a remote loop free alternate (LFA) is to increase backup coverage
for OSPF routes and provide protection especially for Layer 1 metro-rings. The existing
LDP implemented for the MPLS tunnel setup can be reused for protection of OSPF
networks and subsequent LDP destinations. The OSPF protocol creates a dynamic LDP
tunnel to reach the remote LFA node from the point of local repair (PLR). The PLR uses
this remote LFA backup path when the primary link fails.
Before you configure remote LFA over LDP tunnels in an OSPF network, you must do the
following:
1. Enable LDP on the loopback interface.
Configure a loopback interface because an LDP targeted adjacency cannot be formed

without a loopback interface. LDP targeted adjacency is essential for determining
remote LFA backup paths.

2. Make sure that remote LFA allows asymmetric remote neighbor discovery—that is, it
must send periodic targeted hello messages to the router that initiated the remote
neighbor for LDP auto-targeted adjacency.
3. Configure link protection or node-link protection on the PLR.
To configure remote LFA backup over LDP tunnels in an OSPF network:
1. Enable remote LFA backup to determine the backup next hop using dynamic LDP
label-switched path.
[edit protocols ospf backup-spf-options]

user@host# set remote-backup-calculation
2. Enable automatically targeted LDP sessions using the loopback addresses between
the PLR and the remote LFA node.
[edit protocols ldp]

user@host# set auto-targeted-session
3. Specify a time interval for which the targeted LDP sessions are kept up even after the
remote LFA node goes down.
[edit protocols ldp auto-targeted-session]

user@host# set teardown-delay seconds
For example, to set a teardown delay value of 60 seconds:

user@host# set teardown-delay 60
4. Specify the maximum number of automatically targeted LDP sessions to optimize

memory usage.

user@host# set maximum-sessions number of sessions
For example, to set a maximum sessions allowed to 20:

user@host# set maximum-sessions 20
Related • Remote LFA over LDP Tunnels in OSPF Networks Overview on page 547
Documentation
• Example: Configuring Remote LFA Over LDP Tunnels in OSPF Networks
• backup-spf-options

Example: Configuring Remote LFA over LDP Tunnels in OSPF Networks
In an OSPF network, a loop free alternate(LFA) is a directly connected neighbor that

The primary goal of the remote LFA is to increase backup coverage for the OSPF networks
and provide protection for Layer 1 metro-rings. This example shows how to configure
remote LFA for LDP tunnels in an OSPF network for extending backup protection.

Requirements
• One ACX5000 router and eight other routers with OSPF protocol and LDP enabled on
the connected interfaces.
• Junos OS Release 15.1X54–D60 running on ACX5000 routers.
• Junos OS Release 14.2 or later running on other supporting devices.
Before you configure remote LFA over LDP tunnels in an OSPF networks, make sure of
the following:
• LDP is enabled on the loopback interface. Without a loopback interface, LDP targeted
adjacency cannot be formed. Remote LFA cannot be configured without LDP targeted
adjacency.
• Remote LFA must allow asymmetric remote neighbor discovery—that is, it must send
periodic targeted hello messages to the router that initiated the remote neighbor for
LDP auto targeted adjacency.
• Link protection or node-link protection must be configured on the point of local repair
(PLR).
Overview
The example includes one ACX5000 router and eight other routers in a ring topology.
Configure the OSPF protocol on the directly connected interfaces. Device R0 is the
ACX5000 router and Device R6 is the PLR. This example verifies that Junos OS updates
the routing table of Device R6 with LDP next-hop routes as the backup route.
Topology
In the topology Figure 28 on page 551 shows the remote LFA over LDP tunnels in OSPF
networks is configured on Device R6.

Figure 28: Example Remote LFA over LDP Tunnels
Configuration
R0 set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24

set interfaces ge-0/0/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set interfaces lo0 unit 0 family mpls
set routing-options static route 88.88.88.88/32 discard
set routing-options router-id 1.1.1.1
set routing-options forwarding-table export per-packet
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface lo0.0
set protocols ospf backup-spf-options remote-backup-calculation
set protocols ospf export static
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0

set protocols ospf area 0.0.0.0 interface lo0.0

set protocols ldp auto-targeted-session teardown-delay 20
set protocols ldp auto-targeted-session maximum-sessions 60
set protocols ldp egress-policy static
set protocols ldp interface ge-0/0/0.0
set protocols ldp interface lo0.0
set policy-options policy-statement per-packet then load-balance per-packet
set policy-options policy-statement per-packet then accept
set policy-options policy-statement static from protocol static
set policy-options policy-statement static then accept

set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 link-protection

set protocols ospf area 0.0.0.0 interface all
set protocols ospf area 0.0.0.0 interface fxp0.0 disable







set protocols ospf topology default backup-spf-options remote-backup-calculation



Configuring Device R6
Step-by-Step The following example requires that you navigate various levels in the configuration
To configure Device R6:
1. Configure the interfaces.
[edit interfaces]
user@R6# set ge-0/0/0 unit 0 family inet address 60.1.1.2/24
user@R6# set ge-0/0/0 unit 0 family mpls


2. Assign the loopback addresses to the device.
[edit lo0 unit 0 family]

user@R6# set address 7.7.7.7/32
user@R6# set mpls
3. Configure the router ID. Apply the policy to the forwarding table of the local router
with the export statement.
[edit routing-options]
user@R6# set router-id 7.7.7.7

user@R6# set forwarding-table export per-packet
4. Enable remote LFA backup, which calculates the backup next hop using dynamic
LDP label-switched path.
[edit protocols ospf]

user@R6# set topology default backup-spf-options remote-backup-calculation
user@R6# set backup-spf-options remote-backup-calculation
5. Configure the traffic engineering and the link protection for the interfaces in the
OSPF area.
[edit protocols ospf]

user@R6# set traffic-engineering
user@R6# set area 0.0.0.0 interface ge-0/0/0.0 link-protection
user@R6# set area 0.0.0.0 interface lo0.0
6. Specify a time interval for which the targeted LDP sessions are kept up when the
remote LFA goes down, and specify a maximum number of automatically, targeted
LDP sessions to optimize the use of memory.

user@R6# set auto-targeted-session teardown-delay 20
user@R6# set auto-targeted-session maximum-sessions 60
7. Configure the LDP protocols on the interfaces.

user@R6# set interface ge-0/0/0.0
user@R6# set interface lo0.0
8. Configure the policy options to load-balance the per-packet of the policy-statement

routing policy.
[edit policy-options policy-statement]

user@R6# set per-packet then load-balance per-packet
user@R6# set per-packet then accept
Results
From configuration mode, confirm your configuration by entering the show interfaces,
show protocols, show policy-options, and show routing-options commands. If the
output does not display the intended configuration, repeat the instructions in this example
to correct the configuration.
user@R6# show interfaces

ge-0/0/0 {
unit 0 {

family inet {
address 60.1.1.2/24;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 70.1.1.1/24;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 80.1.1.2/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 7.7.7.7/32;
}
family mpls;
}
}
user@R6# show protocols

ospf {
topology default {
backup-spf-options {
remote-backup-calculation;
}
}
inactive: per-prefix-calculation all;
}
traffic-engineering;
area 0.0.0.0 {
link-protection;
}
link-protection;
}
link-protection;
}
interface lo0.0;
}
}

ldp {
auto-targeted-session {
teardown-delay 20;
maximum-sessions 60;
}
interface lo0.0;
}
user@R6# show policy-options

policy-statement per-packet {
then {
load-balance per-packet;
accept;
}
}
user@R6# show routing-options

router-id 7.7.7.7;
forwarding-table {
export per-packet;
}
If you are done configuring the device, enter commit from the configuration mode.
Verification
• Verifying the Routes on page 558

• Verifying the LDP Routes on page 560
• Verifying the OSPF Routes on page 560
• Verifying the Designated Backup Path Node on page 562
• Verifying the Backup Neighbors on page 563
Verifying the Routes
Purpose Verify that the expected routes are learned.
Action On Device R6, from operational mode, run the show route 6.6.6.6/24 command to display
the routes in the routing table.
user@R6> show route 6.6.6.6/24
inet.0: 75 destinations, 75 routes (75 active, 0 holddown, 0 hidden)

6.6.6.6/32 *[OSPF/10] 02:21:07, metric 1

> to 60.1.1.1 via ge-0/0/0.0
to 80.1.1.1 via ge-0/0/2.0, Push 299872

6.6.6.6/32 *[LDP/9] 02:21:07, metric 1

> to 60.1.1.1 via ge-0/0/0.0
to 80.1.1.1 via ge-0/0/2.0, Push 299792, Push 299872(top)

6.6.6.6/32 (1 entry, 1 announced)
State: <FlashAll>
*OSPF Preference: 10
Next hop type: Router, Next hop index: 1048585
Address: 0x9df2690
Next-hop reference count: 10
Next hop: 60.1.1.1 via ge-0/0/0.0 weight 0x1, selected
Session Id: 0x141
Next hop: 80.1.1.1 via ge-0/0/2.0 weight 0x101 uflags Remote
neighbor path
Label operation: Push 299872
Label TTL action: prop-ttl
Load balance label: Label 299872: None;
Label element ptr: 0x9dc27a0
Label parent element ptr: 0x0
Label element references: 6
Label element child references: 4
Label element lsp id: 0
Session Id: 0x142
State: <Active Int>
Age: 2:22:40 Metric: 1
Validation State: unverified
Area: 0.0.0.0
Task: OSPF
Announcement bits (2): 0-KRT 4-LDP
AS path: I

State: <FlashAll>
*LDP Preference: 9
Address: 0x9df2a90
Next hop: 60.1.1.1 via ge-0/0/0.0 weight 0x1, selected
Label element ptr: 0x9dc0dc0
Label parent element ptr: 0x0
Session Id: 0x0
Next hop: 80.1.1.1 via ge-0/0/2.0 weight 0x101 uflags Remote
neighbor path
Label operation: Push 299792, Push 299872(top)
Label TTL action: prop-ttl, prop-ttl(top)
Load balance label: Label 299792: None; Label 299872: None;
Label element ptr: 0x9dc1ba0
Label parent element ptr: 0x9dc27a0
Session Id: 0x0

State: <Active Int>

Age: 2:22:40 Metric: 1
Task: LDP
Announcement bits (1): 0-Resolve tree 1
AS path: I
Meaning The output shows all the routes in the routing table of Device R6.
Verifying the LDP Routes
Purpose Verify the automatically targeted LDP routes.
Action From operational mode, enter the show ldp session auto-targeted detail command.
user@R6> show ldp session auto-targeted detail
Address: 4.4.4.4, State: Operational, Connection: Open, Hold time: 28

Session ID: 7.7.7.7:0--4.4.4.4:0
Next keepalive in 8 seconds
Active, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
Neighbor types: auto-targeted
Keepalive interval: 10, Connect retry interval: 1
Local address: 7.7.7.7, Remote address: 4.4.4.4
Up for 02:28:28
Capabilities advertised: none
Capabilities received: none
Protection: disabled
Session flags: none
Local - Restart: disabled, Helper mode: enabled
Remote - Restart: disabled, Helper mode: enabled
Local maximum neighbor reconnect time: 120000 msec
Local maximum neighbor recovery time: 240000 msec
Local Label Advertisement mode: Downstream unsolicited
Remote Label Advertisement mode: Downstream unsolicited
Negotiated Label Advertisement mode: Downstream unsolicited
MTU discovery: disabled
Nonstop routing state: Not in sync
Next-hop addresses received:
4.4.4.4
30.1.1.2
40.1.1.1
128.92.25.37
Verifying the OSPF Routes
Purpose Display all the LDP backup routes in the OSPF routing table of Device R6.

Action On Device R6, from operational mode, run the show ospf route command to display the
routes in the OSPF routing table.
user@R6> show ospf route

Topology default Route Table:
Prefix Path Route NH Metric NextHop Nexthop

Type Type Type Interface Address/LSP
1.1.1.1 Intra AS BR IP 2 ge-0/0/2.0 80.1.1.1
Bkup LSP LDP->4.4.4.4
2.2.2.2 Intra Router IP 1 ge-0/0/2.0 80.1.1.1
ge-0/0/2.0 80.1.1.1
1.1.1.1/32 Intra Network IP 2 ge-0/0/2.0 80.1.1.1
ge-0/0/2.0 80.1.1.1
7.7.7.7/32 Intra Network IP 0 lo0.0
Bkup IP ge-0/0/0.0 60.1.1.1
Bkup IP ge-0/0/2.0 80.1.1.1
60.1.1.0/24 Intra Network IP 1 ge-0/0/0.0
88.88.88.88/32 Ext2 Network IP 0 ge-0/0/2.0 80.1.1.1


128.92.19.176/32 Intra Network IP 0 lo0.0
ge-0/0/2.0 80.1.1.1
Meaning The output shows all the LDP backup routes in the OSPF routing table of Device R6.
Verifying the Designated Backup Path Node
Purpose Display the remote LFA next hop determined for a given destination.

Action From operational mode, enter the show ospf backup spf results command.
user@R6> show ospf backup spf results
Topology default results:
Area 0.0.0.0 results:
6.6.6.6
Self to Destination Metric: 1
Parent Node: 60.1.1.2
Primary next-hop: ge-0/0/0.0 via 60.1.1.1
Backup next-hop: LDP->4.4.4.4 via ge-0/0/2.0
Backup Neighbor: 6.6.6.6 via: Direct
Neighbor to Destination Metric: 0, Neighbor to Self Metric: 1
Self to Neighbor Metric: 1, Backup preference: 0x0
Not eligible, Reason: Primary next-hop link fate sharing
Not eligible, Reason: Path loops
Not eligible, Reason: Path loops
Backup Neighbor: 4.4.4.4 via: LDP (LSP endpoint)
Eligible, Reason: Contributes backup next-hop
Meaning The output indicates whether a specific interface or node has been designated as a
remote backup path and why.
Verifying the Backup Neighbors
Purpose Display the backup neighbors for the Device R6

Action From operational mode, enter the show ospf backup neighbor command.
user@R6>show ospf backup neighbor
Topology default backup neighbors:
Area 0.0.0.0 backup neighbors:
6.6.6.6 via: Direct

Neighbor to Self Metric: 1
Self to Neighbor Metric: 1
Direct next-hop: ge-0/0/0.0 via 60.1.1.1
8.8.8.8 via: Direct

2.2.2.2 via: Direct

4.4.4.4 via: LDP (LSP endpoint)

Direct next-hop: LDP->4.4.4.4 via ge-0/0/2.0
Direct next-hop: LDP->4.4.4.4 via ge-0/0/0.0
Neighbors Protected: 2
Meaning The output displays the backup neighbors available for area 0.0.0.0.
Related • Remote LFA over LDP Tunnels in OSPF Networks Overview on page 547
Documentation
Understanding Remote LFA over LDP Tunnels in IS-IS Networks
In an IS-IS network, a loop free alternate (LFA) is a directly connected neighbor that
The primary goal of the remote LFA is to increase backup coverage for the IS-IS networks
and provide protection for Layer 1 metro-rings.
LFAs do not provide full backup coverage for IS-IS networks. This is a major setback for
metro Ethernet networks that are often shaped as ring topologies. To overcome this
setback, Resource Reservation Protocol - Traffic Engineering (RSVP-TE) backup tunnels
are commonly used to extend the backup coverage. However, a majority of network
providers have already implemented LDP as the MPLS tunnel setup protocol and do not
want to implement the RSVP-TE protocol merely for backup coverage. LDP automatically

brings up transport tunnels to all potential destinations in an IS-IS network and hence is
the preferred protocol. The existing LDP implemented for the MPLS tunnel setup can be
reused for protection of IS-IS networks and subsequent LDP destinations, thereby
eliminating the need for RSVP-TE backup tunnels for backup coverage.
To calculate the remote LFA backup path, the IS-IS protocol determines the remote LFA
node in the following manner:
1. Calculates the reverse shortest path first from the adjacent router across the protected
link of a PLR. The reverse shortest path first uses the incoming link metric instead of
the outgoing link metric to reach a neighboring node.
The result is a set of links and nodes, which is the shortest path from each leaf node
to the root node.
2. Calculates the shortest path first (SPF) on the remaining adjacent routers to find the
list of nodes that can be reached without traversing the link being protected.
The result is another set of links and nodes on the shortest path from the root node
to all leaf nodes.
3. Determines the common nodes from the above results, These nodes are the remote
LFAs.
IS-IS listens to the advertised labels for the LDP routes. For each advertised LDP route,
IS-IS checks whether it contains an LDP supplied next hop. If the corresponding IS-IS
route does have a backup next hop, then IS-IS runs the backup policy and adds an
additional tracking route with the corresponding LDP label-switched path next hop as
the backup next hop. If there are no backup next hops, LDP builds a dynamic LDP tunnel
to the remote LFA, and LDP establishes a targeted adjacency between the remote LFA
node and the PLR node. This backup route has two LDP labels. The top label is the IS-IS
route, which denotes the backup path from the PLR to the remote LFA route. The bottom
label is the LDP MPLS label-switched path that denotes the route for reaching the ultimate
destination from the remote LFA. When an LDP session goes down and a remote tunnel
is no longer available, IS-IS changes all the routes that have been using this backup LDP
tunnel.
NOTE: Currently, Junos OS supports only IPv4 transport LSPs. If you need to
reuse IPv4 transport LSPs for IPv6 IGP networks, add an IPv6 explicit NULL
label to the label stack of the tracking route. The system automatically
converts the IPv4 LSP to an IPv6 LSP.
LDP might be vulnerable by an automatically targeted adjacency, and these threats can
be mitigated using all or some of the following mechanisms:
• Remote LFAs that are several hops away use extended hello messages to indicate
willingness to establish a targeted LDP session. A remote LFA can reduce the threat

of spoofed extended hellos by filtering them and accepting only those originating at
sources permitted by an access or filter list.
• There is a need to authenticate with TCP-MD5 all auto-targeted LDP sessions in the
given IGP/LDP domain using apply groups or LDP global-level authentication.
• As an added security measure, the repair or remote tunnel endpoint routers should be
assigned from a set of addresses that are not reachable from outside of the routing
domain.
Related • auto-targeted-session
Documentation
• Configuring Remote LFA Backup over LDP Tunnels in an IS-IS Network on page 566
• Example: Configuring Remote LFA over LDP Tunnels in IS-IS Networks
Configuring Remote LFA Backup over LDP Tunnels in an IS-IS Network
Starting in Junos OS Release 14.2, the primary goal of a remote loop-free alternate (LFA)
is to increase backup coverage for IS-IS routes and provide protection especially for Layer
1 metro-rings. The existing LDP implemented for the MPLS tunnel setup can be reused
for protection of IS-IS networks and subsequent LDP destinations. The IS-IS protocol
creates a dynamic LDP tunnel to reach the remote LFA node from the point of local repair
(PLR). The PLR uses this remote LFA backup path when the primary link fails.
Before you configure remote LFA over LDP tunnels in an IS-IS network, you must do the
following:
1. Enable LDP on the loopback interface.
Configure a loopback interface because an LDP targeted adjacency cannot be formed

without a loopback interface. LDP targeted adjacency is essential for determining
remote LFA backup paths.
2. Make sure that remote LFA allows asymmetric remote neighbor discovery—that is, it
must send periodic targeted hello messages to the router that initiated the remote
neighbor for LDP auto-targeted adjacency.
3. Configure link protection or node-link protection on the PLR.
To configure remote LFA backup over LDP tunnels in an IS-IS network:
1. Enable remote LFA backup to determine the backup next hop using dynamic LDP
label-switched path.
[edit protocols isis backup-spf-options]

user@host# set remote-backup-calculation

2. (Optional) Include the node-link-degradation statement even if node-link protection

is not configured for a given interface.
The device uses the configured link protection LFA as the backup for the primary link.
[edit protocols isis backup-spf-options]

user@host# set node-link-degradation
3. Enable automatically targeted LDP sessions using the loopback addresses between
the PLR and the remote LFA node.

user@host# set auto-targeted-session
4. Specify a time interval for which the targeted LDP sessions are kept up even after the
remote LFA node goes down.

user@host# set teardown-delay seconds
For example, to set a teardown delay value of 60 seconds:

user@host# set teardown-delay 60
5. Specify the maximum number of automatically targeted LDP sessions to optimize

memory usage.

user@host# set maximum-sessions number of sessions
For example, to set a maximum sessions allowed to 20:

user@host# set maximum-sessions 20
14.2 Starting in Junos OS Release 14.2, the primary goal of a remote loop-free
alternate (LFA) is to increase backup coverage for IS-IS routes and provide
protection especially for Layer 1 metro-rings.
Related • auto-targeted-session
Documentation
• Example: Configuring Remote LFA over LDP Tunnels in IS-IS Networks
• Understanding Remote LFA over LDP Tunnels in IS-IS Networks on page 564

Example: Configuring Remote LFA over LDP Tunnels in IS-IS Networks
This example shows how to configure remote LFA for LDP tunnels in an IS-IS network
for extending backup protection.

Requirements
• One ACX5000 router and five other supporting routers with IS-IS protocol and LDP
enabled on the connected interfaces. If the other supporting routers are also ACX5000
routers, then interfaces should be of type em instead of fxp as shown in this example.
• Junos OS Release 15.1X54–D60 running on ACX5000 router.
• Junos OS Release 14.2 or later running on other supporting devices.
Before you configure remote LFA over LDP tunnels in IS-IS networks, make sure of the
following:
• LDP is enabled on the loopback interface. Without a loopback interface, LDP targeted
adjacency cannot be formed. Remote LFA cannot be configured without LDP targeted
adjacency.
• Remote LFA must allow asymmetric remote neighbor discovery—that is, it must send
periodic targeted hello messages to the router that initiated the remote neighbor for
LDP auto targeted adjacency.
• Link protection or node-link protection must be configured on the point of local repair
(PLR).
Overview
The example includes one ACX5000 router and five other supporting routers in a ring
topology. Configure the IS-IS protocol on the directly connected interfaces. Device R1 is
the ACX5000 router. This example verifies that Junos OS updates the routing table of
Device R1 with LDP next-hop routes as the backup route.
Topology
Figure 29 on page 569 shows the topology used in this example.

Figure 29: Configuring Remote LFA over LDP Tunnels in IS-IS Networks
Configuration
Router R1 set interfaces ge-1/0/0 unit 1 description R1->R2

set interfaces ge-1/0/0 unit 1 family iso
set interfaces ge-1/5/0 unit 12 description R1->R6
set interfaces lo0 unit 10 family iso address 49.0001.1720.1600.1010.00
set protocols isis interface ge-1/0/0.1
set protocols isis interface ge-1/5/0.12 link-protection
set protocols isis interface lo0.12 passive
set protocols isis interface all level 2 metric 10

set protocols isis interface em0.0 disable

set protocols isis spf-options delay 1000
set protocols isis interface all node-link-protection
set protocols isis backup-spf-options remote-backup-calculation
set protocols isis backup-spf-options node-link-degradation
set protocols mpls interface all
set protocols mpls interface em0.0 disable
set protocols ldp interface all
set protocols ldp interface em0.0 disable
set protocols ldp auto-targeted-session
set protocols ldp deaggregate
set policy-options policy-statement ecmp term 1 then load-balance per-packet
set routing-options forwarding-table export ecmp
Router R2 set interfaces ge-1/0/1 unit 2 description R2>R1

set protocols isis interface fxp0.0 disable
set protocols mpls interface fxp0.0 disable
set protocols ldp interface fxp0.0 disable







set ldp auto-targeted-session
set ldp auto-targeted-session teardown-delay 60
set ldp auto-targeted-session maximum-sessions 20

Configuring Device R1
Step-by-Step The following example requires that you navigate various levels in the configuration
NOTE: Repeat this procedure except Step 4 and Step 5 for every Juniper
Networks router in the IGP domain, modifying the appropriate interface
names, addresses, and any other parameters.
To configure Device R1:
[edit interfaces]
user@R1# set ge-1/0/0 unit 1 description R1->R2
user@R1# set ge-1/0/0 unit 1 family iso

user@R1# set ge-1/5/0 unit 12 description R1->R6

user@R1# set ge-1/5/0 unit 12 family iso
2. Assign a loopback address to the device.
[edit interfaces lo0 unit 10]

user@R1# set family inet address 10.255.102.128/32
user@R1# set family iso address 49.0001.1720.1600.1010.00
3. Configure the IS-IS interface for level 2 and the metric value on all the interfaces,
and enable link protection on the protected interface.
[edit protocols isis]

user@R1# set interface all level 2 metric 10
user@R1# set interface lo0.12 passive
user@R1# set interface em0.0 disable
user@R1# set interface ge-1/5/0.12 link-protection
4. Enable IS-IS node-link protection, which also automatically extends backup coverage
to all LDP label-switched paths.

user@R1# set spf-options delay 1000
user@R1# set interface all node-link-protection
5. Enable remote LFA backup, which calculates the backup next hop using dynamic
LDP label-switched path.
(Optional) When you include the node-link-degradation statement even if node

protection LFA is not configured for a given destination, the device uses the
configured link protection LFA as the backup for the primary link.

user@R1# set backup-spf-options remote-backup-calculation
user@R1# set backup-spf-options node-link-degradation
6. Configure MPLS to use LDP label-switched paths for all interfaces on the device.
[edit protocols]
user@R1# set mpls interface all
user@R1# set mpls interface em0.0 disable
user@R1# set ldp interface all
user@R1# set ldp interface em0.0 disable
7. Specify a time interval for which the targeted LDP sessions are kept up when the
remote LFA goes down, and specify a maximum number of automatically, targeted
LDP sessions to optimize the use of memory.

user@R1# set auto-targeted-session
user@R1# set auto-targeted-session teardown-delay 60

user@R1# set auto-targeted-session maximum-sessions 20
8. (Optional) Enable forwarding equivalence class (FEC) deaggregation, which results

in faster global convergence.

user@R1# set deaggregate
9. To enable Packet Forwarding Engine local repair, establish a policy that forces the
routing protocol process to install all the next hops for a given route.
This policy ensures that the backup route is installed in the forwarding table used
by the Packet Forwarding Engine to forward traffic to a given destination.
[edit policy-options]
user@R1# set policy-options policy-statement ecmp term 1
user@R1# set then load-balance per-packet
10. Apply the policy to the forwarding table of the local router with the export statement.
[edit routing-options forwarding-table]

user@R1# set export ecmp
Results
From configuration mode, confirm your configuration by entering the show interfaces,
show protocols, show policy-options, and show routing-options commands. If the
user@R1# show interfaces

ge-1/0/0 {
unit 1 {
description R1->R2;
family inet {
address 1.1.1.1/24;
}
family iso;
family mpls;
}
}
ge-1/5/0 {
unit 12 {
description R1->R6;
family inet {
address 1.1.6.12/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 10 {

family inet {
address 10.255.102.128/32;
}
family iso {
address 49.0001.1720.1600.1010.00;
}
}
}
user@R1# show protocols

mpls {
interface all;
interface em0.0 {
disable;
}
}
isis {
spf-options delay 1000;
node-link-degradation;
}
interface ge-1/5/0.12; {
link-protection;
}
interface all {
node-link-protection;
level 2 metric 10;
}
interface em0.0 {
disable;
}
interface lo0.12 {
passive;
}
}
ldp {
auto-targeted-session {
teardown-delay 60;
maximum-sessions 20;
}
deaggregate;
interface all;
interface em0.0 {
disable;
}
}
user@R1# show policy-options

policy-options {
policy-statement ecmp {
term 1 {
then {
}
}

}
}
user@R1# show routing-options

forwarding-table {
export ecmp;
}
If you are done configuring the device, enter commit from the configuration mode.
Verification
• Verifying the Routes on page 576

• Verifying the IS-IS Routes on page 577
• Verifying the LDP Routes on page 578
• Verifying the Designated Backup Path Node on page 578
Verifying the Routes
Purpose Verify that the expected routes are learned.
Action On Device R1, from operational mode, run the show route command to display the routes
in the routing table.
user@R1> show route 1.1.4/24

1.1.4.0/24 *[IS-IS/15] 11:37:58, metric 30

> to 1.1.6.11 via ge-1/5/0
to 1.1.1.2 via ge-1/0/0, Push 299824
user@R1> show route 1.1.4/24 detail

State: <FlashAll>
*IS-IS Preference: 15
Level: 1
Address: 0x98047cc
Next hop: 1.1.6.11 via ge-1/5/0 weight 0x1, selected
Session Id: 0x14b
Next hop: 1.1.1.2 via ge-1/0/0 weight 0x101 uflags Remote neighbor path
Label operation: Push 299824

Label TTL action: prop-ttl
Load balance label: Label 299824: None;
Session Id: 0x142
State:<Active Int>
Age: 11:38:00
Metric: 30


Task: IS-IS
Announcement bits (3): 0-LDP 1-IS-IS 3-KRT
AS path: I
Meaning The output shows all the routes in the routing table of Device R1.
Verifying the IS-IS Routes
Purpose Display all the LDP backup routes in the IS-IS routing table of Device R1.
Action On Device R1, from operational mode, run the show isis route command to display the
routes in the IS-IS routing table.
user@R1> show isis route

IS-IS routing table Current version: L1: 558 L2: 564
IPv4/IPv6 Routes
----------------
Prefix L Version Metric Type Interface NH Via
Backup Score
1.1.2.0/24 1 558 20 int lt-1/2/0.1 IPV4 tp3-R2
1.1.3.0/24 1 558 30 int lt-1/2/0.1 IPV4 tp3-R2
1.1.4.0/24 1 558 30 int lt-1/2/0.12 IPV4 tp3-R6
lt-1/2/0.1 LSP
LDP->tp3-R4(10.255.102.156)
1.1.5.0/24 1 558 20 int lt-1/2/0.12 IPV4 tp3-R6
lt-1/2/0.1 LSP
LDP->tp3-R4(10.255.102.156)
10.255.102.136/32 1 558 10 int lt-1/2/0.12 IPV4 tp3-R6
lt-1/2/0.1 LSP
LDP->tp3-R4(10.255.102.156)
10.255.102.146/32 1 558 20 int lt-1/2/0.1 IPV4 tp3-R2
10.255.102.156/32 1 558 30 int lt-1/2/0.1 IPV4 tp3-R2
lt-1/2/0.12 IPV4 tp3-R6
10.255.102.166/32 1 558 20 int lt-1/2/0.12 IPV4 tp3-R6
lt-1/2/0.1 LSP
LDP->tp3-R4(10.255.102.156)
10.255.102.178/32 1 558 10 int lt-1/2/0.1 IPV4 tp3-R2
Meaning The output shows all the LDP backup routes in the IS-IS routing table of Device R1.

Verifying the LDP Routes
Purpose Verify the automatically targeted LDP routes.
Action From operational mode, enter the show ldp session auto-targeted detail command.
user@R1> show ldp session auto-targeted detail
Address: 10.255.102.156, State: Operational, Connection: Open, Hold time: 21

Session ID: 10.255.102.128:0--10.255.102.156:0
Next keepalive in 1 seconds
Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
Neighbor types: auto-targeted
Keepalive interval: 10, Connect retry interval: 1
Local address: 10.255.102.128, Remote address: 10.255.102.156
Up for 11:38:23
Capabilities advertised: none
Capabilities received: none
Protection: disabled
Session flags: none
Local - Restart: disabled, Helper mode: enabled
Remote - Restart: disabled, Helper mode: enabled
Local maximum neighbor reconnect time: 120000 msec
Local maximum neighbor recovery time: 240000 msec
Local Label Advertisement mode: Downstream unsolicited
Remote Label Advertisement mode: Downstream unsolicited
Negotiated Label Advertisement mode: Downstream unsolicited
MTU discovery: disabled
Nonstop routing state: Not in sync
Next-hop addresses received:
1.1.3.6
1.1.4.7
10.255.102.156
Meaning The output shows automatically targeted LDP next hops.
Verifying the Designated Backup Path Node
Purpose Display the remote LFA next hop determined for a given destination.
Action From operational mode, enter the show isis backup spf results command.
user@R1> show isis backup spf results R6

IS-IS level 1 SPF results:
R6.00
Primary next-hop: ge-1/5/0, IPV4, R6, SNPA: 0:5:85:88:f0:bc
Root: R6, Root Metric: 10, Metric: 0, Root Preference: 0x0
Not eligible, IPV4, Reason: Primary next-hop link fate sharing
track-item: R6.00-00
Not eligible, IPV4, Reason: Path loops

Eligible, Backup next-hop: ge-1/0/0, LSP, LDP->R4(10.255.102.156), Prefixes: 2
1 nodes
IS-IS level 2 SPF results:

R6.00
Primary next-hop: ge-1/5/0, IPV4, R6, SNPA: 0:5:85:88:f0:bc
Not eligible, IPV4, Reason: Primary next-hop link fate sharing
Not eligible, IPV4, Reason: Path loops
Eligible, Backup next-hop: ge-1/0/0, LSP, LDP->R4(10.255.102.156), Prefixes: 0
1 nodes
Meaning The output indicates whether a specific interface or node has been designated as a
remote backup path and why.
Related • Understanding Remote LFA over LDP Tunnels in IS-IS Networks on page 564
Documentation


CHAPTER 19
Configuring Generic Routing Encapsulation
• Understanding Generic Routing Encapsulation on ACX Series on page 581

• Configuring Generic Routing Encapsulation Tunneling on ACX Series on page 584
• Configuring Unicast Tunnels on page 585
Understanding Generic Routing Encapsulation on ACX Series
Generic routing encapsulation (GRE) provides a private, secure path for transporting
packets through an otherwise public network by encapsulating (or tunneling) the packets.
• Overview of GRE on page 581

• GRE Tunneling on page 582
• Configuration Limitations on page 583
Overview of GRE
GRE encapsulates data packets and redirects them to a device that de-encapsulates
them and routes them to their final destination. This allows the source and destination
routers to operate as if they have a virtual point-to-point connection with each other
(because the outer header applied by GRE is transparent to the encapsulated payload
packet). For example, GRE tunnels allow routing protocols such as RIP and OSPF to
forward data packets from one router to another router across the Internet. In addition,
GRE tunnels can encapsulate multicast data streams for transmission over the Internet.
GRE is described in RFC 2784 (obsoletes earlier RFCs 1701 and 1702). The routers support
RFC 2784, but not completely. (For a list of limitations, see “Configuration Limitations”
on page 583.)
As a tunnel source router, the router encapsulates a payload packet for transport through
the tunnel to a destination network. The payload packet is first encapsulated in a GRE
packet, and then the GRE packet is encapsulated in a delivery protocol. The router
performing the role of a tunnel remote router extracts the tunneled packet and forwards
the packet to its destination.

NOTE: Service chaining for GRE, NAT, and IPSec services on ACX1100-AC
and ACX500 routers is not supported.
GRE Tunneling
Data is routed by the system to the GRE endpoint over routes established in the route
table. (These routes can be statically configured or dynamically learned by routing
protocols such as RIP or OSPF.) When a data packet is received by the GRE endpoint, it
is de-encapsulated and routed again to its destination address.
GRE tunnels are stateless-–that is, the endpoint of the tunnel contains no information
about the state or availability of the remote tunnel endpoint. Therefore, the router
operating as a tunnel source router cannot change the state of the GRE tunnel interface
to down if the remote endpoint is unreachable.
For details about GRE tunneling, see:
• Encapsulation and De-Encapsulation on the Router on page 582

• Number of Source and Destination Tunnels Allowed on a Router on page 582
Encapsulation and De-Encapsulation on the Router
Encapsulation—A router operating as a tunnel source router encapsulates and forwards

GRE packets as follows:
1. When a router receives a data packet (payload) to be tunneled, it sends the packet
to the tunnel interface.
2. The tunnel interface encapsulates the data in a GRE packet and adds an outer IP
header.
3. The IP packet is forwarded on the basis of the destination address in the outer IP
header.
De-encapsulation—A router operating as a tunnel remote router handles GRE packets

as follows:
1. When the destination router receives the IP packet from the tunnel interface, the outer
IP header and GRE header are removed.
2. The packet is routed based on the inner IP header.
Number of Source and Destination Tunnels Allowed on a Router
ACX routers support as many as 64 GRE tunnels between routers transmitting IPv4 or
IPv6 payload packets over GRE.

Chapter 19: Configuring Generic Routing Encapsulation
Configuration Limitations
Some GRE tunneling features are not currently available on ACX Series routers. Be aware
of the following limitations when you are configuring GRE on an ACX router:
• Unsupported features—GRE on the ACX routers does not support the following features:
• Virtual routing over GRE
• Bidirectional Forwarding Detection (BFD) protocol over GRE distributed mode
• MPLS over GRE tunnels
• GRE keepalives
• GRE keys, payload packet fragmentation, and sequence numbers for fragmented
packets
• BGP dynamic tunnels
• RFC 1701 and RFC 1702
• RFC 2890—Key and sequence number extensions to GRE
• IPv6 as delivery header
• GRE path MTU discovery
• Load balancing when NNI is ECMP
• Interface statistics on GRE interfaces
• Class of service and firewall on GRE tunnel
• Routing Protocol—ACX routers do not support routing protocols on GRE interfaces.

You need to disable routing on GRE interfaces under the [edit protocols] hierarchy. For
example,
[edit]
user@host# show protocols
ospf {
area 0.0.0.0 {
interface all;
interface gr-0/0/10.0 {
disable;
}
}
}
NOTE: This limitation is applicable for all routing protocols (such as OSPF,
ISIS).
Related • Configuring Generic Routing Encapsulation Tunneling on ACX Series on page 584
Documentation

Configuring Generic Routing Encapsulation Tunneling on ACX Series
Tunneling provides a private, secure path for transporting packets through an otherwise
public network by encapsulating packets inside a transport protocol known as an IP
encapsulation protocol. Generic routing encapsulation (GRE) is an IP encapsulation
protocol that is used to transport packets over a network. Information is sent from one
network to the other through a GRE tunnel.
GRE tunneling is accomplished through routable tunnel endpoints that operate on top
of existing physical and other logical endpoints. GRE tunnels connect one endpoint to
another and provide a clear data path between them.
1. Configuring a GRE Tunnel Port on page 584

2. Configuring Tunnels to Use Generic Routing Encapsulation on page 584
Configuring a GRE Tunnel Port

To configure GRE tunnels on a router, you convert a network port or uplink port on the
router to a GRE tunnel port for tunnel services. Each physical tunnel port, named
gr-fpc/pic/port, can have one or more logical interfaces, each of which is a GRE tunnel.
After conversion to a GRE tunnel port, the physical port cannot be used for network traffic.
To configure a GRE tunnel port on an ACX router, you need to create logical tunnel
interfaces and the bandwidth in gigabits per second to reserve for tunnel services. Include
the tunnel-services bandwidth (1g | 10g) statement at the [edit chassis fpc slot-number
pic number] hierarchy level.
To configure a GRE tunnel port on the ACX5000 line of routers, use any unused physical
port on the router to create a logical tunnel interface as shown below:

fpc 0 {
pic 0 {
tunnel-services {
port port-number;
}
}
}
This also creates a gr- interface.
Configuring Tunnels to Use Generic Routing Encapsulation

Normally, a GRE tunnel port comes up as soon as it is configured and stays up as long
as a valid tunnel source address exists or an interface is operational. Each logical interface
you configure on the port can be configured as the source or as the endpoint of a GRE
tunnel.
To configure a tunnel port to use GRE:

Chapter 19: Configuring Generic Routing Encapsulation
1. Configure a physical GRE port with a logical interface name and address:
• For IPv4 over GRE, specify the protocol family inet:
[edit interfaces]
user@host# set gr-fpc/pic/port unit number family inet address
• For IPv6 over GRE, specify the protocol family inet6:
[edit interfaces]
user@host# set gr-fpc/pic/port unit number family inet6 address
2. Specify the tunnel source address for the logical interface:
[edit interfaces]
user@host# set gr-fpc/pic/port unit number tunnel source source-address
3. Specify the destination address:
[edit interfaces]
user@host# set gr-fpc/pic/port unit number tunnel destination destination-address
Related • Understanding Generic Routing Encapsulation on ACX Series on page 581

Documentation
Configuring Unicast Tunnels
To configure a unicast tunnel, you configure a gr- interface (to use GRE encapsulation)
and include the tunnel and family statements:
gr-fpc/pic/port {
tunnel {
destination destination-address;
routing-instance {
destination routing-instance-name;
}
source address;
ttl number;
}
family family {
address address {
destination address;
}
}
}
}
You can configure these statements at the [edit interfaces] hierarchy level.
You can configure multiple logical units for each GRE interface, and you can configure
only one tunnel per unit.
You must specify the tunnel’s destination and source addresses. The remaining
statements are optional.

To set the time-to-live (TTL) field that is included in the encapsulating header, include
the ttl statement. If you explicitly configure a TTL value for the tunnel, you must configure
it to be one larger than the number of hops in the tunnel. For example, if the tunnel has
seven hops, you must configure a TTL value of 8.
You must configure at least one family on the logical interface.
A configured tunnel cannot go through Network Address Translation (NAT) at any point
along the way to the destination. For more information, see Examples: Configuring Unicast
Tunnels and the MPLS Applications Feature Guide.
Related • Understanding Generic Routing Encapsulation on ACX Series on page 581

Documentation
• Configuring Generic Routing Encapsulation Tunneling on ACX Series on page 584

CHAPTER 20
Configuring MPLS and Pseudowires
• MPLS Overview for ACX Series Universal Access Routers on page 587
• TTL Processing on Incoming MPLS Packets on page 588
• Example: ATM Pseudowire Base Configuration on page 592
• Example: Ethernet Pseudowire Base Configuration on page 597
• Example: TDM Pseudowire Base Configuration on page 600
• Redundant Pseudowires for Layer 2 Circuits and VPLS on page 604
• Configuring Redundant Pseudowires for Layer 2 Circuits and VPLS on page 606
• Configuring the Pseudowire Status TLV on page 608
• Example: Configuring the Pseudowire Status TLV on page 609
• Automatic Bandwidth Allocation for LSPs on page 611
• Configuring Automatic Bandwidth Allocation for LSPs on page 611
• Configuring Reporting of Automatic Bandwidth Allocation Statistics for LSPs on page 619
• Understanding Pseudowire Redundancy Mobile Backhaul Scenarios on page 623
• Example: Configuring Pseudowire Redundancy in a Mobile Backhaul Scenario on page 627
MPLS Overview for ACX Series Universal Access Routers
Multiprotocol Label Switching (MPLS) provides a mechanism for engineering network

traffic patterns that is independent of routing tables by assigning short labels to network
packets, which describe how to forward them through the network. MPLS is independent
of any routing protocol and can be used for unicast packets. On the ACX Series routers,
the following MPLS features are supported:
• The configuration of a label-switching router (LSR) for processing of label-switched

packets and forwarding of packets based on their labels.
• The configuration of an ingress label edge router (LER) where IP packets are
encapsulated within MPLS packets and forwarded to the MPLS domain, and as an

egress LER where MPLS packets are decapsulated and the IP packets contained within
the MPLS packets are forwarded using information in the IP forwarding table.
Configuring MPLS on the LER is the same as configuring an LSR.
• Uniform and pipe mode configuration providing different types of visibility in the MPLS
network. Uniform mode makes all the nodes that a label-switched path (LSP) traverses
visible to nodes outside the LSP tunnel. Uniform mode is the default. Pipe mode makes
only the LSP ingress and egress points visible to nodes outside the LSP tunnel. Pipe
mode acts like a circuit and must be enabled with the global no-propagate-ttl statement
at the [edit protocols mpls] hierarchy level on each router that is in the path of the LSP.
The no-propagate-ttl statement disables time-to-live (TTL) propagation at the router
level and affects all RSVP-signalled or LDP-signalled LSPs. Only the global configuration
of TTL propagation is supported.
• Exception packet handling of IP packets not processed by the normal packet flow
through the Packet Forwarding Engine. The following types of exception packet handling
are supported:
• Router alert
• Time-to-live (TTL) expiry value
• Virtual circuit connection verification (VCCV)
• LSP hot standby for secondary paths configuration to maintain a path in a hot-standby
state enabling swift cut over to the secondary path when downstream routers on the
current active path indicate connectivity problems.
• Redundancy for a label-switched path (LSP) path with the configuration of fast reroute.
• Configuration of link protection to ensure that traffic traversing a specific interface

from one router to another can continue to reach its destination in the event that this
interface fails.
Related • MPLS Applications Feature Guide

Documentation
• Disabling Normal TTL Decrementing
• Fast Reroute Overview
• Configuring Fast Reroute
• MPLS and Traffic Protection
• Configuring Link Protection on Interfaces Used by LSPs
• Configuring Hot Standby of Secondary Paths for LSPs
TTL Processing on Incoming MPLS Packets
The flow chart on Figure 30 on page 590 illustrates TTL processing on incoming MPLS
packets. On a transit LSR or an egress LER, MPLS pops one or more labels and can push
one or more labels. The incoming TTL of the packet is determined by the configured TTL
processing tunnel model.

Chapter 20: Configuring MPLS and Pseudowires
When all of the following conditions are met, the incoming TTL is set to the TTL value
found in the immediate inner header:
• The outer label is popped as opposed to being swapped
• The TTL processing model is configured to pipe
• The inner header is MPLS or IP
If any of those conditions is not met, then the incoming TTL is set to the TTL value found
in the outermost label. In all cases, the TTL values of any further inner labels are ignored.
When an IP packet is exposed after MPLS pops all the labels that should be popped,
MPLS passes the packet to IP for further processing, including TTL checking. When the
uniform tunnel model for TTL processing is in effect, MPLS sets the TTL value of the IP
packet to the incoming TTL value that was just set. In other words, the TTL value is copied
from the outermost label to the IP packet. When the pipe model for TTL processing is in
effect, the TTL value in the IP header is left unchanged.
If an IP packet is not exposed by the label popping, then MPLS performs the TTL validation.
If the incoming TTL is less than 2, the packet is dropped. If innermost packet is IP, an
ICMP packet is built and sent. If the TTL does not expire and the packet needs to be sent
out, the outgoing TTL is determined by the rules for outgoing MPLS packets.

Figure 30: TTL Processing on Incoming MPLS Packets
Related • Disabling Normal TTL Decrementing

Documentation
• no-propagate-ttl
Pseudowire Overview for ACX Series Universal Access Routers
A pseudowire is a Layer 2 circuit or service, which emulates the essential attributes of a

telecommunications service— such as a T1 line, over an MPLS packet-switched network.
The pseudowire is intended to provide only the minimum necessary functionality to
emulate the wire with the required degree of faithfulness for the given service definition.

On the ACX Series routers, Ethernet, Asynchronous Transfer Mode (ATM), and
time-division multiplexing (TDM) pseudowires are supported. The following pseudowire
features are supported:
• Pseudowire transport service carrying Layer 1 and Layer 2 information over an IP and
MPLS network infrastructure. Only similar end points are supported on the ACX
Series—for example, T1 to T1, ATM to ATM, and Ethernet to Ethernet.
• Redundant pseudowires backup connections between PE routers and CE devices,

maintaining Layer 2 circuits and services after certain types of failures. Pseudowire
redundancy improves the reliability of certain types of networks (metro for example)
where a single point of failure could interrupt service for multiple customers. The
following pseudowire redundancy features are supported:
• Maintenance of Layer 2 circuit services after certain types of failures with a standby
pseudowire, which backs up the connection between PE routers and CE devices.
• In case of failure, a protect interface, which backs up the primary interface. Network
traffic uses the primary interface only so long as the primary interface functions. If
the primary interface fails, traffic is switched to the protect interface.
• Hot and cold standby enabling swift cut over to the backup or standby pseudowire.
• Ethernet connectivity fault management (CFM), which can be used to monitor the
physical link between two routers. The following major features of CFM for Ethernet
pseudowires only are supported:
• Connection protection using the continuity check protocol for fault monitoring. The
continuity check protocol is a neighbor discovery and health check protocol that
discovers and maintains adjacencies at the VLAN or link level.
• Path protection using the linktrace protocol for path discovery and fault verification.
Similar to IP traceroute, the linktrace protocol maps the path taken to a destination
MAC address through one or more bridged networks between the source and
destination.
Related • Layer 2 Circuits Overview

Documentation
• Configuring a MEP to Generate and Respond to CFM Protocol Messages
• IEEE 802.1ag OAM Connectivity Fault Management Overview
• Configuring a CFM Action Profile to Specify CFM Actions for CFM Events
• Configuring Interfaces for Layer 2 Circuits

ATM Pseudowire Overview
An Asynchronous Transfer Mode (ATM) pseudowire acts as a Layer 2 circuit or service,

which allows the migration of ATM services to an MPLS packet-switched network without
having to provision the ATM subscriber or customer edge (CE) device. When you configure
an ATM pseudowire, the network between the customer edge (CE) routers appears
transparent to the CE routers, making it seem that the CE routers are directly connected
across a time-division multiplex (TDM) leased line. ATM pseudowires are primarily used
in an ATM service provider’s network to connect existing ATM switches across a higher
speed packet-switched network or to provide ATM backhaul services for remote access
to existing ATM networks.
On ACX series routers, you configure an ATM pseudowire with Layer 2 encapsulation for

Documentation
Example: ATM Pseudowire Base Configuration

• Overview of an ATM Pseudowire With Cell Mode Base Configuration on page 592
• Configuring an ATM Pseudowire on page 593
Requirements
The following is a list of the hardware and software requirements for this configuration.
Overview of an ATM Pseudowire With Cell Mode Base Configuration

The configuration shown here is the base configuration of an ATM pseudowire with ATM
cell-relay encapsulation on an ACX Series router. This configuration is for one provider
edge router. To complete the configuration of an ATM pseudowire, you need to repeat
this configuration on an other provider edge router in the MPLS network.

Configuring an ATM Pseudowire
level:
set interfaces at-0/0/0 atm-options vpi 0

set interfaces at-0/0/0 unit 0 encapsulation atm-ccc-cell-relay
set interfaces at-0/0/0 unit 0 vci 0.64
set interfaces ct1-0/0/0 no-partition interface-type at
set protocols rsvp interface ge-0/2/0.0
set protocols mpls no-cspf
set protocols mpls label-switched-path PE1-to-PE2 to 40.1.1.1
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols l2circuit neighbor 40.1.1.1 interface at-0/0/0.0 virtual-circuit-id
1
NOTE: To configure an ATM pseudowire with ATM virtual circuit (VC)

multiplex encapsulation on CCC circuits, include the atm-ccc-vc-mux
statement at the [edit interfaces at-0/0/0 unit 0 encapsulation] hierarchy
level instead of the atm-ccc-cell-relay statement shown in this example.
Step-by-Step 1. Create an ATM interface on a channelized T1 interface (ct1) and enable full
Procedure channelization with the no-partition statement. On the ATM interface, set the ATM
virtual circuit identifier (VCI), the virtual path identifier (VPI), and set the
encapsulation cell mode.
[edit]
user@host# edit interfaces
[edit interfaces]
user@host# set ct1-0/0/0 no-partition interface-type at
user@host# set at-0/0/0 unit 0 vci 0.64
user@host# set at-0/0/0 atm-options vpi 0
user@host# set at-0/0/0 unit 0 encapsulation atm-ccc-cell-relay
2. Create a Gigabit Ethernet interface and enable MPLS on that interface. Create the
loopback (lo0) interface:
[edit interfaces]
user@host# set ge-0/2/0 unit 0 family inet address 20.1.1.2/24
user@host# set ge-0/2/0 unit 0 family mpls

user@host# set lo0 unit 0 family inet address 70.1.1.1/32
3. Enable the MPLS and RSVP protocols on the MPLS interface—ge-0/2/0.0:
[edit]
[edit protocols]
user@host# set rsvp interface ge-0/2/0.0
user@host# set mpls interface ge-0/2/0.0
4. Configure LDP. If you configure RSVP for a pseudowire, you must also configure
LDP:
[edit protocols]
user@host# set protocols ldp interface ge-0/2/0.0
user@host# set protocols ldp interface lo0.0
5. Configure a point-to-point label-switched path (LSP) and disable constrained-path

LSP computation:
[edit protocols]
user@host# set mpls label-switched-path PE1-to-PE2 to 40.1.1.1
user@host# set mpls no-cspf
6. Configure OSPF and enable traffic engineering on the MPLS interface—ge-0/2/0.0,

and on the loopback (lo0) interface:
[edit protocols]
user@host# set ospf traffic-engineering
user@host# set ospf area 0.0.0.0 interface ge-0/2/0.0
user@host# set ospf area 0.0.0.0 interface lo0.0 passive
7. Uniquely identify a Layer 2 circuit for the ATM pseudowire:
[edit protocols]
user@host# set l2circuit neighbor 40.1.1.1 interface at-0/0/0.0 virtual-circuit-id 1
Results
[edit]
user@host# show
interfaces {
at-0/0/0 {
atm-options {
vpi 0;
}
unit 0 {
encapsulation atm-ccc-cell-relay;
vci 0.64;
}
}
ct1-0/0/0 {

no-partition interface-type at;

}
ge-0/2/0 {
unit 0 {
family inet {
address 20.1.1.2/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 70.1.1.1/32;
}
}
}
}
protocols {
rsvp {
}
mpls {
no-cspf;
label-switched-path PE1-to-PE2 {
to 40.1.1.1;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
ldp {
interface lo0.0;
}
l2circuit {
neighbor 40.1.1.1 {
interface at-0/0/0.0 {
}
}
}
}
Related • Pseudowire Overview for ACX Series Universal Access Routers on page 590
Documentation

Ethernet Pseudowire Overview
Starting in Junos OS Release 14.1X53 and Junos OS Release 16.1, an Ethernet pseudowire
is used to carry Ethernet or 802.3 Protocol Data Units (PDUs) over an MPLS network
enabling service providers to offer emulated Ethernet services over existing MPLS
networks. Ethernet or 802.3 PDUs are encapsulated within the pseudowire to provide a
point-to-point Ethernet service. For the point-to-point Ethernet service, the following
fault management features are supported:
• The IEEE 802.3ah standard for Operation, Administration, and Management (OAM).
You can configure IEEE 802.3ah OAM link-fault management on Ethernet point-to-point
direct links or links across Ethernet repeaters.
Ethernet OAM link-fault management can be used for physical link-level fault detection
and management. It uses a new, optional sublayer in the data link layer of the OSI
model. Ethernet OAM can be implemented on any full-duplex point-to-point or
emulated point-to-point Ethernet link. A system-wide implementation is not required;
OAM can be deployed on particular interfaces of a router. Transmitted Ethernet OAM
messages or OAM PDUs are of standard length, untagged Ethernet frames within the
normal frame length limits in the range 64–1518 bytes.
• Ethernet connectivity fault management (CFM) to monitor the physical link between
two routers.
• Connection protection using the continuity check protocol for fault monitoring . The
continuity check protocol is a neighbor discovery and health check protocol that
discovers and maintains adjacencies at the VLAN or link level.
• Path protection using the linktrace protocol for path discovery and fault verification
. Similar to IP traceroute, the linktrace protocol maps the path taken to a destination
MAC address through one or more bridged networks between the source and
destination.
14.1X53 Starting in Junos OS Release 14.1X53 and Junos OS Release 16.1, an Ethernet
pseudowire is used to carry Ethernet or 802.3 Protocol Data Units (PDUs) over
an MPLS network enabling service providers to offer emulated Ethernet services
over existing MPLS networks.
Related • Configuring IEEE 802.3ah OAM Link-Fault Management

Documentation

Example: Ethernet Pseudowire Base Configuration

• Overview of an Ethernet Pseudowire Base Configuration on page 597
• Configuring an Ethernet Pseudowire on page 597
Requirements
Overview of an Ethernet Pseudowire Base Configuration

The configuration shown here is the base configuration of an Ethernet pseudowire with
Ethernet cross-connect for physical interface encapsulation on an ACX Series router.
This configuration is for one provider edge router. To complete the configuration of an
Ethernet pseudowire, you need to repeat this configuration on an other provider edge
router in the Multiprotocol Label Switched (MPLS) network.
Configuring an Ethernet Pseudowire
level:
set interfaces ge-0/1/1 encapsulation ethernet-ccc

set interfaces ge-0/1/1 unit 0
set protocols l2circuit neighbor 40.1.1.1 interface ge-0/1/1.0 virtual-circuit-id
1
NOTE: To configure an Ethernet pseudowire with 802.1Q tagging for

cross-connect logical interface encapsulation, include the vlan-ccc statement
at the [edit interfaces ge-0/1/1 unit 0 encapsulation] hierarchy level instead
of the ethernet-ccc statement shown in this example.

Step-by-Step 1. Create two Gigabit Ethernet interfaces, set the encapsulation mode on one interface
Procedure and MPLS on the other interface. Create the loopback (lo0) interface:
[edit]
[edit interfaces]
user@host# set ge-0/1/1 encapsulation ethernet-ccc
user@host# set ge-0/1/1 unit 0
2. Enable the MPLS and RSVP protocols on the interface configured with
MPLS—ge-0/2/0.0:
[edit]
[edit protocols]
LDP:
[edit protocols]
user@host# set protocols ldp interface ge-0/2/0.0
user@host# set protocols ldp interface lo0.0

LSP computation:
[edit protocols]

[edit protocols]
6. Uniquely identify a Layer 2 circuit for the Ethernet pseudowire:
[edit protocols]
user@host# set l2circuit neighbor 40.1.1.1 interface ge-0/1/1.0 virtual-circuit-id 1

Results
[edit]
user@host# show
interfaces {
ge-0/1/1 {
encapsulation ethernet-ccc;
unit 0;
}
ge-0/2/0 {
unit 0 {
family inet {
address 20.1.1.2/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 70.1.1.1/32;
}
}
}
}
protocols {
rsvp {
}
mpls {
no-cspf;
to 40.1.1.1;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
ldp {
interface lo0.0;
}
l2circuit {
neighbor 40.1.1.1 {
}
}
}
}

Documentation
TDM Pseudowires Overview
A TDM pseudowire acts as Layer 2 circuit or service for T1 and E1 circuit signals across an
MPLS packet-switched network. On ACX Series routers, you configure a TDM pseudowire
with Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) on the
ACX Series built-in channelized T1 and E1 interfaces. When you configure a TDM
pseudowire, the network between the customer edge (CE) routers appears transparent
to the CE routers, making it seem that the CE routers are directly connected. With the
SAToP configuration on the provider edge (PE) router’s T1 and E1 interfaces, the
interworking function (IWF) forms a payload (frame) that contains the CE router’s T1
and E1 Layer 1 data and control word. This data is transported to the remote PE over the
pseudowire. The remote PE removes all the Layer 2 and MPLS headers added in the
network cloud and forwards the control word and the Layer 1 data to the remote IWF,
which in turn forwards the data to the remote CE router.

Documentation
• SAToP Emulation on T1 and E1 Interfaces Overview on page 110
• Configuring SAToP Emulation on Channelized T1 and E1 Interfaces on page 191
Example: TDM Pseudowire Base Configuration

• Overview of a TDM Pseudowire Base Configuration on page 600
• Configuring an TDM Pseudowire on page 601
Requirements
Overview of a TDM Pseudowire Base Configuration

The configuration shown here is the base configuration of an TDM pseudowire with T1
framing on an ACX Series router. This configuration is for one provider edge router. To
complete the TDM pseudowire configuration, you need to repeat this configuration on
an other provider edge router in the Multiprotocol Label Switched (MPLS) network.

Configuring an TDM Pseudowire
level:
set chassis fpc 0 pic 0 framing t1

set interfaces ct1-0/0/0 no-partition interface-type t1
set interfaces t1-0/0/0 encapsulation satop
set interfaces t1-0/0/0 unit 0
set protocols l2circuit neighbor 40.1.1.1 interface t1-0/0/0.0 virtual-circuit-id
1
NOTE: To configure a TDM pseudowire with E1 framing, include the e1

statement at the [edit chassis fpc 0 pic 0 framing] hierarchy level instead of
the t1 statement shown in this example.
Step-by-Step 1. Configure the framing format:

Procedure
[edit]
[edit chassis]
user@host# set fpc 0 pic 0 framing t1
2. Create a T1 interface on a channelized T1 interface (ct1) and enable full

channelization with the no-partition statement. On the logical T1 interface, set the
Structure-Agnostic TDM over Packet (SAToP) encapsulation mode.
[edit]
[edit interfaces]
user@host# set ct1-0/0/0 no-partition interface-type t1
user@host# set t1-0/0/0 encapsulation satop
user@host# set t1-0/0/0 unit 0

3. Create a Gigabit Ethernet interface and enable MPLS on that interface. Create the
loopback (lo0) interface:
[edit interfaces]
4. Enable the MPLS and RSVP protocols on the MPLS interface—ge-0/2/0.0:
[edit]
[edit protocols]
LDP:
[edit protocols]
user@host# set ldp interface ge-0/2/0.0
user@host# set ldp interface lo0.0

LSP computation:
[edit protocols]

[edit protocols]
8. Uniquely identify a Layer 2 circuit for the TDM pseudowire:
[edit protocols]
user@host# set l2circuit neighbor 40.1.1.1 interface t1-0/0/0.0 virtual-circuit-id 1
Results
[edit]
user@host# show
chassis {
fpc 0 {
pic 0 {
framing t1;
}

}
}
interfaces {
ct1-0/0/0 {
}
t1-0/0/0 {
encapsulation satop;
unit 0;
}
ge-0/2/0 {
unit 0 {
family inet {
address 20.1.1.2/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 70.1.1.1/32;
}
}
}
}
protocols {
rsvp {
}
mpls {
no-cspf;
to 40.1.1.1;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
ldp {
interface lo0.0;
}
l2circuit {
neighbor 40.1.1.1 {
}
}
}
}

Documentation
Redundant Pseudowires for Layer 2 Circuits and VPLS
A redundant pseudowire can act as a backup connection between PE routers and CE

devices, maintaining Layer 2 circuit and VPLS services after certain types of failures. This
feature can help improve the reliability of certain types of networks (metro for example)
where a single point of failure could interrupt service for multiple customers. Redundant
pseudowires cannot reduce traffic loss to zero. However, they provide a way to gracefully
recover from pseudowire failures in such a way that service can be restarted within a
known time limit.
NOTE: VPLS is not supported on ACX Series routers.
When you configure redundant pseudowires to remote PE routers, you configure one to
act as the primary pseudowire over which customer traffic is being transmitted and you
configure another pseudowire to act as a backup in the event the primary fails. You
configure the two pseudowires statically. A separate label is allocated for the primary
and backup neighbors.
For information about how to configure redundant pseudowires, see “Configuring

Redundant Pseudowires for Layer 2 Circuits and VPLS” on page 606.
The following sections provide an overview of redundant pseudowires for Layer 2 circuits
and VPLS:
• Types of Redundant Pseudowire Configurations on page 604

• Pseudowire Failure Detection on page 605
Types of Redundant Pseudowire Configurations

You can configure redundant pseudowires for Layer 2 circuits and VPLS in either of the
following manners:
• You can configure a single active pseudowire. The PE router configured as the primary
neighbor is given preference and this connection is the one used for customer traffic.
For the LDP signalling, labels are exchanged for both incoming and outgoing traffic
with the primary neighbor. The LDP label advertisement is accepted from the backup
neighbor, but no label advertisement is forwarded to it, leaving the pseudowire in an
incomplete state. The pseudowire to the backup neighbor is completed only when the
primary neighbor fails. The decision to switch between the two pseudowires is made
by the device configured with the redundant pseudowires. The primary remote PE

router is unaware of the redundant configuration, ensuring that traffic is always switched
using just the active pseudowire.
• Alternatively, you can configure two active pseudowires, one to each of the PE routers.
Using this approach, control plane signalling is completed and active pseudowires are
established with both the primary and backup neighbors. However, the data plane
forwarding is done only over a one of the pseudowires (designated as the active
pseudowire by the local device). The other pseudowire is on standby. The active
pseudowire is preferably established with the primary neighbor and can switch to the
backup pseudowire if the primary fails.
The decision to switch between the active and standby pseudowires is controlled by
the local device. The remote PE routers are unaware of the redundant connection, and
so both remote PE routers send traffic to the local device. The local device only accepts
traffic from the active pseudowire and drops the traffic from the standby. In addition,
the local device only sends traffic to the active pseudowire. If the active pseudowire
fails, traffic is immediately switched to the standby pseudowire.
The two configurations available for pseudowire redundancy have the following
limitations:
• For the single active pseudowire configuration, it takes more time (compared to the
two active pseudowire configuration) to switchover to the backup pseudowire when
a failure is detected. This approach requires additional control plane signalling to
complete the pseudowire with the backup neighbor and traffic can be lost during the
switchover from primary to backup.
• If you configure two active pseudowires, bandwidth is lost on the link carrying the
backup pseudowire between the remote PE router and the local device. Traffic is always
duplicated over both the active and standby pseudowires. The single active pseudowire
configuration does not waste bandwidth in this fashion.
Pseudowire Failure Detection

The following events are used to detect a failure (control and data plane) of the
pseudowire configured between a local device and a remote PE router and initiates the
switch to a redundant pseudowire:
• Manual switchover (user initiated)
• Remote PE router withdraws the label advertisement
• LSP to the remote PE router goes down
• LDP session with the remote PE router goes down
• Local configuration changes
• Periodic pseudowire OAM procedure fails (Layer 2 circuit-based MPLS ping to the PE
router fails)
When you configure a redundant pseudowire between a CE device and a PE router, a

periodic (once a minute) ping packet is forwarded through the active pseudowire to

verify data plane connectivity. If the ping fails, traffic is automatically switched to the
redundant pseudowire.
When a failure is detected, traffic is switched from the failed active pseudowire to the
redundant pseudowire. The redundant pseudowire is then designated as the active
pseudowire. The switch is nonreversible, meaning that once the redundant pseudowire
assumes the role of the active pseudowire at the time of a failover, it remains as the
active pseudowire even though the previously active pseudowire comes up again.
For example, a primary pseudowire has failed and traffic has been successfully switched
to the redundant pseudowire. After a period of time, the cause of the failure of the primary
pseudowire has been resolved and it is now possible to reestablish the original connection.
However, traffic is not switched back to the original pseudowire unless a failure is detected
on the currently active pseudowire.
Related • Example: Configuring H-VPLS Without VLANs

Documentation
• VPLS Feature Guide for EX9200 Switches
Configuring Redundant Pseudowires for Layer 2 Circuits and VPLS
A redundant pseudowire can act as a backup connection between PE routers and CE

devices, maintaining Layer 2 circuit and VPLS services after certain types of failures. This
feature can help improve the reliability of certain types of networks (metro for example)
where a single point of failure could interrupt service for multiple customers. Redundant
pseudowires cannot reduce traffic loss to zero. However, they provide a way to gracefully
recover from pseudowire failures in such a way that service can be restarted within a
known time limit.
For an overview of how redundant pseudowires work, see “Redundant Pseudowires for
Layer 2 Circuits and VPLS” on page 604.
To configure pseudowire redundancy for Layer 2 circuits and VPLS, complete the
procedures in the following sections:
• Configuring Pseudowire Redundancy on the PE Router on page 606

• Configuring the Switchover Delay for the Pseudowires on page 607
• Configuring a Revert Time for the Redundant Pseudowire on page 607
Configuring Pseudowire Redundancy on the PE Router

You configure pseudowire redundancy on the PE router acting as the egress for the
primary and standby pseudowires using the backup-neighbor statement.

To configure pseudowire redundancy on the PE router, include the backup-neighbor

statement:
backup-neighbor {
community name;
psn-tunnel-endpoint address;
standby;
virtual-circuit-id number;
}
For a list of hierarchy levels at which you can include this statement, see the statement
summary for this statement.
The backup-neighbor statement includes the following configuration options:
• community—Specifies the community for the backup neighbor.
• psn-tunnel-endpoint—Specifies the endpoint address for the packet switched network

(PSN) tunnel on the remote PE router. The PSN tunnel endpoint address is the
destination address for the LSP on the remote PE router.
• standby—Configures the pseudowire to the specified backup neighbor as the standby.

When you configure this statement, traffic flows over both the active and standby
pseudowires to the CE device. The CE device drops the traffic from the standby
pseudowire, unless the active pseudowire fails. If the active pseudowire fails, the CE
device automatically switches to the standby pseudowire.
• virtual-circuit-id—Uniquely identifies the primary and standby Layer 2 circuits. This

option is configurable for Layer 2 circuits only.
Configuring the Switchover Delay for the Pseudowires

To configure the time the router waits before switching traffic from the failed primary
pseudowire to a backup pseudowire, include the switchover-delay statement:
switchover-delay milliseconds;
Configuring a Revert Time for the Redundant Pseudowire

You can specify a revert time for redundant Layer 2 circuit and VPLS pseudowires. When
you have configured redundant pseudowires for Layer 2 circuits or VPLS, traffic is switched
to the backup pseudowire in the event that the primary pseudowire fails. If you configure
a revert time, when the configured time expires traffic is reverted back to the primary
pseudowire, assuming the primary pseudowire has been restored.
To configure a revert time for redundant pseudowires, specify the time in seconds using
the revert-time statement:
revert-time (Protocols Layer 2 Circuits) seconds maximum seconds;
With the maximum option, specify a maximum reversion interval to add after the
revert-time delay. If a revert-time delay is defined but a maximum timer is not defined,
VCs are restored upon the revert-timer's expiration.

To reduce as much as possible the amount of traffic discarded, and potential data-path
asymmetries observed during primary-to-backup transition periods, you can use this
restoration timer. This restoration timer is activated when the backup path is performing
as active, and then the primary path is restored. The goal is to avoid moving traffic back
to the primary path right away, to make sure that the control plane's related tasks (such
as IGP, LDP, RSVP, and internal BGP) have enough time to complete their updating cycle.
By enabling a gradual return of traffic to the primary path, you can ensure that the
relatively-slow control-plane processing and updating does not have a negative impact
on the restoration process.
The maximum option extends the revert timer’s functionality to provide a jittered interval
over which a certain number of circuits can be transitioned back to the primary path. By
making use of this maximum value, you can define a time interval during which circuits
are expected to switch over. As a consequence, circuits’ effective transitions are scattered
during restoration periods.
When making use of revert-time x maximum y statement, you can ensure that the
corresponding circuit that is active is moved to the primary path within a time-slot (t1)
such as that: x <= t1 <= y. In other words, by activating this statement, you can ensure
the following:
• VCs stay in the backup path for at least x seconds after the primary path comes back
up.
• VCs are moved back to the primary path before y seconds have elapsed.
• y maximum value = x maximum value * 2 = 1200 seconds.
The ideal values for x and y will are conditioned to internal aspects of your network. For
this reason, there are no default values for these settings. If no revert-time is set, the
default behavior is non-revertive. That is, circuits are not returned to the primary path
upon restoration. They are kept on the backup path.
Related • Example: Configuring Pseudowire Redundancy in a Mobile Backhaul Scenario

Documentation
• Example: Configuring H-VPLS Without VLANs
• VPLS Feature Guide for EX9200 Switches
Configuring the Pseudowire Status TLV
The pseudowire status type length variable (TLV) is used to communicate the status of
a pseudowire back and forth between two provider edge (PE) routers. For Layer 2 circuit
configurations, you can configure the PE router to negotiate the pseudowire with its
neighbor using the pseudowire status TLV. The pseudowire status TLV is configurable
for each pseudowire connection and is disabled by default. The pseudowire status
negotiation process assures that a PE router reverts back to the label withdraw method

for pseudowire status if its remote PE router neighbor does not support the pseudowire
status TLV.
Unlike the control word, a PE router’s ability to support the pseudowire status TLV is
communicated when the initial label mapping message is sent to its remote PE router.
Once the PE router transmits its support for the pseudowire status TLV to its remote PE
router, it includes the pseudowire status TLV in every label mapping message sent to
the remote PE router. If you disable support for the pseudowire status TLV on the PE
router, a label withdraw message is sent to the remote PE router and then a new label
mapping message without the pseudowire status TLV follows.
To configure the pseudowire status TLV for the pseudowire to the neighbor PE router,
include the pseudowire-status-tlv statement at an appropriate hierarchy level.
For a list of the hierarchy levels at which you can include this statement, see the statement
summarysection for this statement.
Related • Example: Configuring the Pseudowire Status TLV on page 609

Documentation
• pseudowire-status-tlv
• Configuring Interfaces for Layer 2 Circuits
Example: Configuring the Pseudowire Status TLV
Requirements
• One ACX Series Universal Access router
Overview
The configuration shown here is the base configuration of a pseudowire with
pseudowire-status-tlv enabled. The pseudowire-status-tlv is used to communicate the
status of a pseudowire between PE routers.
Configuration
level:
edit protocols l2circuit

set neighbor 10.255.64.26
set neighbor 10.255.64.26 interface xe-0/0/0
set neighbor 10.255.64.26 interface xe-0/0/0 pseudowire-status-tlv
set neighbor 10.255.64.26 interface xe-0/0/0 virtual-circuit-id 1024

Configuring the Pseudowire Status TLV
Step-by-Step 1. Navigate to the [edit protocols l2circuit] hierarchy level to configure Layer 2 circuits
Procedure over MPLS.
[edit]
user@host# edit protocols l2circuit
2. Set the address for the neighbor provider edge router;, this example uses a fictitious
address, 10.255.64.26.

user@host# set neighbor 10.255.64.26
3. Specify the name of the interface forming the Layer 2 circuit; this example uses
xe-0/0/0.

user@host# set neighbor 10.255.64.26 interface xe-0/0/0
4. Enter the pseudowire-status-tlv statement.

user@host# set neighbor 10.255.64.26 interface xe-0/0/0 pseudowire-status-tlv
NOTE: You need to configure the virtual-circuit-id statement in order

for pseudowire-status-tlv to work.
5. Set the virtual-circuit-id statement to identify the pseudowire as regular or

redundant. The identifier value can range from 1 through 4,294,967,295.

user@host# set neighbor 10.255.64.26 interface xe-0/0/0 virtual-circuit-id 1024
6. Check your configuration by entering the show command.
Results

user@host# show
neighbor 10.255.64.26 {
interface xe-0-0-0 {
pseudowire-status-tlv;
}
}

Documentation
• Configuring the Pseudowire Status TLV on page 608
Automatic Bandwidth Allocation for LSPs
Automatic bandwidth allocation allows an MPLS tunnel to automatically adjust its

bandwidth allocation based on the volume of traffic flowing through the tunnel. You can
configure an LSP with minimal bandwidth; this feature can dynamically adjust the LSP’s
bandwidth allocation based on current traffic patterns. The bandwidth adjustments do
not interrupt traffic flow through the tunnel.
You set a sampling interval on an LSP configured with automatic bandwidth allocation.
The average bandwidth is monitored during this interval. At the end of the interval, an
attempt is made to signal a new path for the LSP with the bandwidth allocation set to
the maximum average value for the preceding sampling interval. If the new path is
successfully established and the original path is removed, the LSP is switched over to
the new path. If a new path is not created, the LSP continues to use its current path until
the end of the next sampling interval, when another attempt is made to establish a new
path. Note that you can set minimum and maximum bandwidth values for the LSP.
During the automatic bandwidth allocation interval, the router might receive a steady
increase in traffic (increasing bandwidth utilization) on an LSP, potentially causing
congestion or packet loss. To prevent this, you can define a second trigger to prematurely
expire the automatic bandwidth adjustment timer before the end of the current
adjustment interval.
Configuring Automatic Bandwidth Allocation for LSPs

configure an LSP with minimal bandwidth, and this feature can dynamically adjust the
LSP’s bandwidth allocation based on current traffic patterns. The bandwidth adjustments
do not interrupt traffic flow through the tunnel.
At the end of the automatic bandwidth allocation time interval, the current maximum
average bandwidth usage is compared with the allocated bandwidth for the LSP. If the
LSP needs more bandwidth, an attempt is made to set up a new path where bandwidth
is equal to the current maximum average usage. If the attempt is successful, the LSP’s
traffic is routed through the new path and the old path is removed. If the attempt fails,
the LSP continues to use its current path.
NOTE: In calculating the value for Max AvgBW (relative to the ingress LSP),
the sample collected during make before break (MBB) is ignored to prevent
inaccurate results. The first sample after a bandwidth adjustment, or after
a change in the LSP ID (regardless of path change), is also ignored.

If you have configured link and node protection for the LSP and traffic has been switched
to the bypass LSP, the automatic bandwidth allocation feature continues to operate and
take bandwidth samples from the bypass LSP. For the first bandwidth adjustment cycle,
the maximum average bandwidth usage taken from the original link and node-protected
LSP is used to resignal the bypass LSP if more bandwidth is needed. (Link and node
protection are not supported on QFX Series switches.)
If you have configured fast-reroute for the LSP, you might not be able to use this feature
to adjust the bandwidth. Because the LSPs use a fixed filter (FF) reservation style, when
a new path is signaled, the bandwidth might be double-counted. Double-counting can
prevent a fast-reroute LSP from ever adjusting its bandwidth when automatic bandwidth
allocation is enabled. (Fast reroute is not supported on QFX Series switches.)
To configure automatic bandwidth allocation, complete the steps in the following

sections:
• Configuring Automatic Bandwidth Allocation on LSPs on page 612

• Requesting Automatic Bandwidth Allocation Adjustment on page 617
NOTE: On the QFX10000 switches, you can only configure automatic

bandwidth allocation at the edit protocols mpls hierarchy level. Logical
systems are not supported.
Configuring Automatic Bandwidth Allocation on LSPs

To enable automatic bandwidth allocation on an LSP, include the auto-bandwidth
statement:
auto-bandwidth (MPLS Tunnel) {

adjust-interval seconds;
adjust-threshold percent;
adjust-threshold-overflow-limit number;
adjust-threshold-underflow-limit number;
maximum-bandwidth bps;
minimum-bandwidth bps;
minimum-bandwidth-adjust-interval
minimum-bandwidth-adjust-threshold-change
minimum-bandwidth-adjust-threshold-value
monitor-bandwidth;
}
• [edit protocols mpls label-switched-path lsp-name]
• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
If an LSP has an automatic bandwidth configuration, you can disable automatic bandwidth
adjustments on a particular path (either primary or secondary) by configuring a static
bandwidth value and by disabling the CSPF computation (using the no-cspf statement).

For example:
user@host> show protocols mpls

label-switched-path primary-path {
to 192.168.0.1;
ldp-tunneling;
optimize-timer 3571;
least-fill;
link-protection;
adaptive;
auto-bandwidth {
adjust-interval 7177;
adjust-threshold 5;
minimum-bandwidth 1m;
maximum-bandwidth 2500000000;
adjust-threshold-overflow-limit 2;
resignal-minimum-bandwidth;
}
primary primary-path;
secondary secondary-path {
bandwidth 0;
no-cspf;
priority 0 0;
}
}
The statements configured at the [edit protocols mpls label-switched-path

label-switched-path-name auto-bandwidth] hierarchy level are optional and explained in
the following sections:
• Configuring the Automatic Bandwidth Allocation Interval on page 613

• Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth on page 614
• Configuring the Automatic Bandwidth Adjustment Threshold on page 614
• Configuring a Limit on Bandwidth Overflow and Underflow Samples on page 615
• Configuring Passive Bandwidth Utilization Monitoring on page 617
Configuring the Automatic Bandwidth Allocation Interval
At the end of the automatic bandwidth allocation interval, the automatic bandwidth
computation and new path setup process is triggered.
NOTE: To prevent unnecessary resignaling of LSPs, it is best to configure an

LSP adjustment interval that is at least three times longer than the MPLS
automatic bandwidth statistics interval. For example, if you configure a value
of 30 seconds for the MPLS automatic bandwidth statistics interval (interval
statement at the [edit protocols mpls statistics] hierarchy level), you should
configure a value of at least 90 seconds for the LSP adjustment interval
(adjust-interval statement at the [edit protocols mpls label-switched-path
label-switched-path-name auto-bandwidth] hierarchy level). See also
“Configuring Reporting of Automatic Bandwidth Allocation Statistics for
LSPs” on page 619.

To specify the bandwidth reallocation interval in seconds for a specific LSP, include the
adjust-interval statement:
adjust-interval seconds;
• [edit protocols mpls label-switched-path lsp-name auto-bandwidth (MPLS Tunnel)]
• [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name

auto-bandwidth (MPLS Tunnel)]
Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth
You can maintain the LSP’s bandwidth between minimum and maximum bounds by
specifying values for the minimum-bandwidth and maximum-bandwidth statements.
To specify the minimum amount of bandwidth allocated for a specific LSP, include the
minimum-bandwidth statement:
minimum-bandwidth bps;

To specify the maximum amount of bandwidth allocated for a specific LSP, include the
maximum-bandwidth statement:
maximum-bandwidth bps;

Configuring the Automatic Bandwidth Adjustment Threshold
Use the adjust-threshold statement to specify the sensitivity of the automatic bandwidth
adjustment of an LSP to changes in bandwidth utilization. You can set the threshold for
when to trigger automatic bandwidth adjustments. When configured, bandwidth demand
for the current interval is determined and compared to the LSP’s current bandwidth
allocation. If the percentage difference in bandwidth is greater than or equal to the
specified adjust-threshold percentage, the LSP’s bandwidth is adjusted to the current
bandwidth demand.
For example, assume that the current bandwidth allocation is 100 megabits per second
(Mbps) and that the percentage configured for the adjust-threshold statement is 15
percent. If the bandwidth demand increases to 110 Mbps, the bandwidth allocation is not
adjusted. However, if the bandwidth demand increases to 120 Mbps (20 percent over

the current allocation) or decreases to 80 Mbps (20 percent under the current allocation),
the bandwidth allocation is increased to 120 Mbps or decreased to 80 Mbps, respectively.
To configure the threshold for automatic bandwidth adjustment, include the

adjust-threshold statement:
adjust-threshold percent;

Configuring a Limit on Bandwidth Overflow and Underflow Samples
The automatic bandwidth adjustment timer is a periodic timer which is triggered every
adjust interval to determine whether any bandwidth adjustments are required on the
LSP's active path. This interval is typically configured as a long period of time, usually
hours. If, at the end of adjust interval, the change in bandwidth is above a certain adjust
threshold, the LSP is resignaled with the new bandwidth.
During the automatic bandwidth adjustment interval, the router might receive a steady
increase in traffic (increasing bandwidth utilization) on an LSP, potentially causing
congestion or packet loss. To prevent this, you can define a second trigger to prematurely
expire the automatic bandwidth adjustment timer before the end of the current
adjustment interval.
Every statistics interval, the router samples the average bandwidth utilization of an LSP
and if this has exceeded the current maximum average bandwidth utilization, the
maximum average bandwidth utilization is updated.
During each sample period, the following conditions are also checked:
• Is the current average bandwidth utilization above the active bandwidth of the path?
• Has the difference between the average bandwidth utilization and the active bandwidth
exceeded the adjust threshold (bandwidth utilization has changed significantly)?
If these conditions are true, it is considered to be one bandwidth overflow sample. Using
the adjust-threshold-overflow-limit statement, you can define a limit on the number of
bandwidth overflow samples such that when the limit is reached, the current automatic
bandwidth adjustment timer is expired and a bandwidth adjustment is triggered. Once
this adjustment is complete, the normal automatic bandwidth adjustment timer is reset
to expire after the periodic adjustment interval.
To specify a limit on the number of bandwidth overflow samples before triggering an

automatic bandwidth allocation adjustment, configure the adjust-threshold-overflow-limit
statement:
adjust-threshold-overflow-limit number;

Similarly, if the current average bandwidth utilization is below the active bandwidth of
the path by the configured adjusted threshold (meaning that bandwidth utilization has
gone down significantly), the sample is considered to be an underflow sample. The
adjusted (new signaling) bandwidth after an adjustment due to underflow is the maximum
average bandwidth among the underflow samples. Starting in Junos OS Release 14.1R9,
15.1R7, 16.1R5, 16.2R3, and 17.2R2, all zero value bandwidth samples are considered as
underflow samples, except for the zero value samples that arrive after an LSP comes up
for the first time, and the zero value samples that arrive first after a Routing Engine
switchover.
You can specify a limit on the number of bandwidth underflow samples before triggering
an automatic bandwidth allocation adjustment by configuring the adjust
threshold-underflow-limit statement:
adjust-threshold-underflow-limit number;
These statements can be configured at the following hierarchy levels:

You must configure the adjust-threshold and minimum-bandwidth statements whenever

you configure the adjust-threshold-underflow-limit statement. You must configure the
adjust-threshold and maximum-bandwidth statements whenever you configure the
adjust-threshold-overflow-limit statement
• You must configure a nonzero value for the adjust-threshold statement if you configure
the adjust-threshold-overflow-limit or adjust-threshold-underflow-limit statement.
• Any bandwidth increase or decrease below the value configured for the adjust-threshold
statement does not constitute an overflow or underflow condition.
• To prevent unlimited increases in LSP bandwidth (to limit overflow beyond a certain
bandwidth), you must also configure the maximum-bandwidth statement when you
configure the adjust-threshold-overflow-limit statement.
The following describes the other aspects of the adjust-threshold-overflow-limit

statement:
• It only applies to bandwidth overflows. If the bandwidth is decreasing, the normal

automatic bandwidth adjustment interval is used.
• It does not affect manually triggered automatic bandwidth adjustment.
• It applies to single-class DiffServ-TE LSPs.
• Because the adjust-threshold-overflow-limit statement can trigger a bandwidth

adjustment, it cannot be enabled at the same time as the monitor-bandwidth statement
(for information about that statement, see “Configuring Passive Bandwidth Utilization
Monitoring” on page 617).
• You cannot configure automatic bandwidth adjustments to occur more often than
every 300 seconds. The adjust-threshold-overflow-limit statement is subject to the

same minimum value with regard to the minimum frequency of adjustment allowed.
Overflow condition based adjustments can occur no sooner than 300 seconds from
the start of the overflow condition. Therefore it is required that:
sample interval x adjust-threshold-overflow-limit >= 300s
These values are checked during the commit operation. An error is returned if the value
is less than 300 seconds.
• If you change the value of the adjust-threshold-overflow-limit statement on a working

router, you can expect the following behavior:
• If you increase the current value of the adjust-threshold-overflow-limit statement,

the old value is replaced with the new one.
• If you decrease the current value of the adjust-threshold-overflow-limit statement

and the current bandwidth overflow count is less than the new value, the old value
is replaced with the new one.
• If you decrease the current value of the adjust-threshold-overflow-limit statement

and the current bandwidth overflow count is greater than the new value, the
adjustment timer is immediately expired and a bandwidth adjustment is initiated.
Configuring Passive Bandwidth Utilization Monitoring
Use the monitor-bandwidth statement to switch to a passive bandwidth utilization

monitoring mode. In this mode, no automatic bandwidth adjustments are made, but the
maximum average bandwidth utilization is continuously monitored and recorded.
To configure passive bandwidth utilization monitoring, include the monitor-bandwidth

statement:
monitor-bandwidth;

If you have configured an LSP with primary and secondary paths, the automatic bandwidth
allocation statistics are carried over to the secondary path if the primary path fails. For
example, consider a primary path whose adjustment interval is half complete and whose
maximum average bandwidth usage is currently calculated as 50 Mbps. If the primary
path suddenly fails, the time remaining for the next adjustment and the maximum average
bandwidth usage are carried over to the secondary path.
Requesting Automatic Bandwidth Allocation Adjustment

For MPLS LSP automatic bandwidth allocation adjustment, the minimum value for the
adjustment interval is 5 minutes (300 seconds). You might find it necessary to trigger a
bandwidth allocation adjustment manually, for example in the following circumstances:
• When you are testing automatic bandwidth allocation in a network lab.

• When the LSP is configured for automatic bandwidth allocation in monitor mode (the
monitor-bandwidth statement is included in the configuration as described in
“Configuring Passive Bandwidth Utilization Monitoring” on page 617), and want to initiate
an immediate bandwidth adjustment.
To use the request mpls lsp adjust-autobandwidth command, the following must be true:
• Automatic bandwidth allocation must be enabled on the LSP.
• The criteria required to trigger a bandwidth adjustment have been met (the difference
between the adjust bandwidth and the current LSP path bandwidth is greater than
the threshold limit).
A manually triggered bandwidth adjustment operates only on the active LSP path. Also,
if you have enabled periodic automatic bandwidth adjustment, the periodic automatic
bandwidth adjustment parameters (the adjustment interval and the maximum average
bandwidth) are not reset after a manual adjustment.
For example, suppose the periodic adjust interval is 10 hours and there are currently
5 hours remaining before an automatic bandwidth adjustment is triggered. If you initiate
a manual adjustment with the request mpls lsp adjust-autobandwidth command, the
adjust timer is not reset and still has 5 hours remaining.
To manually trigger a bandwidth allocation adjustment, you need to use the request mpls
lsp adjust-autobandwidth command. You can trigger the command for all affected LSPs
on the router, or you can specify a particular LSP:
user@host> request mpls lsp adjust-autobandwidth
Once you execute this command, the automatic bandwidth adjustment validation process
is triggered. If all the criteria for adjustment are met, the LSP’s active path bandwidth is
adjusted to the adjusted bandwidth value determined during the validation process.
14.1R9 Starting in Junos OS Release 14.1R9, 15.1R7, 16.1R5, 16.2R3, and 17.2R2, all zero
value bandwidth samples are considered as underflow samples, except for the
zero value samples that arrive after an LSP comes up for the first time, and the
zero value samples that arrive first after a Routing Engine switchover.
Related • Configuring MPLS to Gather Statistics

Documentation
• Configuring Reporting of Automatic Bandwidth Allocation Statistics for LSPs on page 619
• request mpls lsp adjust-autobandwidth
• show mpls lsp
• show mpls lsp autobandwidth

Configuring Reporting of Automatic Bandwidth Allocation Statistics for LSPs

configure the device to collect statistics related to automatic bandwidth allocation by
completing the following steps:
1. To collect statistics related to automatic bandwidth allocation, configure the

auto-bandwidth option for the statistics statement at the [edit protocols mpls]
hierarchy level. These settings apply to all LSPs configured on the router on which
you have also configured the auto-bandwidth statement at the [edit protocols mpls
label-switched-path label-switched-path-name] hierarchy level.
statistics {
auto-bandwidth (MPLS Statistics);
interval seconds;
no-transit-statistics;
transit-statistics-polling;
}
2. Specify the filename for the files used to store the MPLS trace operation output using
the file option. All files are placed in the directory /var/log. We recommend that you
place MPLS tracing output in the file mpls-log.
3. Specify the maximum number of trace files using the files number option. When a
trace file named trace-file reaches its maximum size, it is renamed trace-file.0, then
trace-file.1, and so on, until the maximum number of trace files is reached. Then the
oldest trace file is overwritten.
4. Specify the interval for calculating the average bandwidth usage by configuring a time
in seconds using the interval option. You can also set the adjustment interval on a
specific LSP by configuring the interval option at the [edit protocols mpls
label-switch-path label-switched-path-name statistics] hierarchy level.
NOTE: To prevent unnecessary resignaling of LSPs, it is best to configure

an LSP adjustment interval that is at least three times longer than the
MPLS automatic bandwidth statistics interval. For example, if you
configure a value of 30 seconds for the MPLS automatic bandwidth
statistics interval (interval statement at the [edit protocols mpls statistics]
hierarchy level), you should configure a value of at least 90 seconds for
the LSP adjustment interval (adjust-interval statement at the [edit
protocols mpls label-switched-path label-switched-path-name
auto-bandwidth] hierarchy level).

5. To trace automatic bandwidth allocation, include the autobw-state flag for the MPLS
traceoptions statement at the [edit protocols mpls] hierarchy level.
The following configuration enables the MPLS traceoptions for automatic bandwidth
allocation. The trace records are stored in a file called auto-band-trace (the filename
is user configurable):
[edit protocols mpls]

traceoptions {
file auto-band-trace size 10k files 10 world-readable;
flag autobw-state;
}
6. Using the show log command, you can display the automatic bandwidth allocation
statistics file generated when you configure the auto-bandwidth (MPLS Statistics)
statement. The following shows sample log file output taken from an MPLS statistics
file named auto-band-stats on a router configured with an LSP named E-D. The log
file shows that LSP E-D is operating over its reserved bandwidth limit initially. Before
Oct 30 17:14:57, the router triggered an automatic bandwidth adjustment (you might
see two sessions for an LSP undergoing an automatic bandwidth adjustment). By Oct
30 17:16:57, the LSP has been reestablished at a higher bandwidth and is now shown
using less than 100 percent of its Reserved Bw (reserved bandwidth).
user@host> show log auto-band-stats

E-D (LSP ID 5, Tunnel ID 6741) 209 pkt 17094 Byte 1 pps 90 Bps Util
240.01% Reserved Bw 37 Bps
decr nh 0x952c224, type 4, flags 0x0, n_gw 1, nhid 0 to refcount 1Oct 30 17:13:57 Total 1 sessions: 1
success, 0 fail, 0 ignored
decr nh 0x952c224, type 4, flags 0x0, n_gw 1, nhid 0 to refcount 1decr nh 0x952c308, type 4, flags 0x0,
n_gw 1, nhid 0 to refcount 1Oct 30 17:15:27 Total 2 sessions: 2 success, 0 fail, 0 ignored

7. Issue the show mpls lsp autobandwidth command to display current information about
automatic bandwidth allocation. The following shows sample output from the show
mpls lsp autobandwidth command taken at about the same time as the log file shown
previously:
user@host> show mpls lsp autobandwidth

Lspname Last Requested Reserved Highwater AdjustTime LastAdjust
BW BW BW mark Left (sec)
E-D 300bps 812.005bps 812bps 1.56801kbps 294 sec Wed Oct 30 17:15:26 2013
8. Issue the file show command to display the MPLS trace file. You need to specify the
file location and file name (the file is located in /var/log/. The following shows sample
trace file output is taken from an MPLS trace file named auto-band-trace.0.gz on a
router configured with an LSP named E-D. The trace file shows that LSP E-D is
operating over its reserved bandwidth limit initially. At Oct 30 17:15:26, the router
triggers an automatic bandwidth adjustment (you might see two sessions for an LSP
undergoing an automatic bandwidth adjustment). By Oct 30 17:15:57, the LSP has
been reestablished at a higher bandwidth and is now shown using less than 100
percent of its Reserved Bw (reserved bandwidth).
user@host> file show /var/log/auto-band-trace.0.gz

Oct 30 17:13:57 trace_on: Tracing to "/var/log/E/auto-band-trace" started
Oct 30 17:13:57.466825 LSP E-D (id 5) new bytes arrived 2714 in 29
sec
Oct 30 17:14:27.466713 E-D (LSP ID 5, Tunnel ID 6741) 241
pkt 19737 Byte 1 pps 88 Bps Util 234.67% Reserved Bw
37 Bps
Oct 30 17:14:27.466962 LSP E-D (id 5, old id 5); sampled bytes 19737 >
bytes recorded 17094
sec
37 Bps
bytes recorded 19737
sec
Oct 30 17:15:26.265816 Adjust Autobw: LSP E-D (id 5) curr adj bw 300bps updated
with 812.005bps
Oct 30 17:15:26.266064 mpls LSP E-D Autobw change 512.005bps >= threshold 75bps
Oct 30 17:15:26.363372 Autobw Success: LSP E-D () (old id 5 new id 6) update
prev active bw 300 bps with 812 bps
Oct 30 17:15:26.363686 RPD_MPLS_PATH_BANDWIDTH_CHANGE: MPLS path (lsp E-D)
bandwidth changed, path bandwidth 812 bps
Oct 30 17:15:27.364751 RPD_MPLS_LSP_BANDWIDTH_CHANGE: MPLS LSP E-D bandwidth
changed, lsp bandwidth 812 bps
37 Bps
101 Bps

37 Bps
101 Bps
Oct 30 17:15:57.467201 LSP E-D (id 6, old id 5); LSP up after autobw adjustment
and active for 30 sec
Oct 30 17:15:57.467398 LSP E-D (id 6) psb bytes 2695 < bytes recorded
22607 total bytes 2695 in 30 sec
Oct 30 17:15:57.467461 First sample of the adjust interval after automatic bw
adjustment
Oct 30 17:15:57.467594 Update curr max avg bw 0bps of LSP E-D with new bw
716.225bps
37 Bps
101 Bps
bytes recorded 2695
sec
101 Bps
bytes recorded 5338
Related • Configuring Automatic Bandwidth Allocation for LSPs on page 611

Documentation
• show mpls lsp autobandwidth

Understanding Pseudowire Redundancy Mobile Backhaul Scenarios
With the rising demand for mobile broadband services, telecommunication providers are
seeing a sharp increase in bandwidth requirements. To keep pace with demand, operators
are deploying packet-based backhaul networks that offer increased capacity at a lower
cost, while providing the necessary service reliability and quality of experience that users
expect.
Most of the legacy backhaul infrastructure has been traditionally built over PDH
microwave, TDM T1/E1, or ATM-over-DSL links. Service providers have traditionally added
subsequent TDM links to their base stations when needed to deal with bandwidth
constraint scenarios. This expansion model has proven to be inefficient for the
unprecedented traffic demands required by 3G and Long Term Evolution (LTE) services.
As a direct consequence, operators are gradually migrating to an Ethernet-based higher
capacity infrastructure in the backhaul portion of 3G and LTE topologies. Modern base
stations now provide Ethernet backhaul connectivity, allowing pseudowire technologies
to transport end-user content to the desired destination. As part of this Ethernet transition,
service providers are increasingly demanding better resiliency mechanisms to cover the
existence gap with those features provided by previous legacy technologies. With that
goal in mind, Junos OS provides efficient pseudowire redundancy capabilities to those
topologies where Layer 2 and Layer 3 segments are interconnected.
• Sample Topology on page 623

• Benefits of Pseudowire Redundancy Mobile Backhaul on page 624
• Layer 2 Virtual Circuit Status TLV Extension on page 624
• How It Works on page 625
Sample Topology
Figure 31 on page 623 shows a sample topology.
Figure 31: Pseudowire Redundancy Mobile Backhaul Sample Topology
An A5
CE2
A1 PE1 PE3
Metro MPLS Core MPLS

ring cloud
A2 PE2 PE4
A4 CE3
A3
g041420
Layer 2 domain Layer 3 domain

Benefits of Pseudowire Redundancy Mobile Backhaul

Junos OS pseudowire redundancy capabilities are as follows:
• Redundant loop-free paths to interconnect Layer 2 and Layer 3 domains.
• Layer 2 and Layer 3 domains are synchronized with regard to the elected data path.
• Traffic disruption is minimal for the following possible scenarios:
• Access link failures
• Node failures
• Control-plane failures
• Traffic interruption is minimal after the failure’s restoration is completed.
Layer 2 Virtual Circuit Status TLV Extension

The pseudowire status TLV is used to communicate the status of a pseudowire between
provider edge (PE) routers. To avoid potential primary-path discrepancies, there must
be a mechanism that allows all network elements to be synchronized with respect to
the primary path over which traffic needs to be sent. With this goal in mind, the status
TLV is extended to address this requirement.
NOTE: The pseudowire status TLV is not supported by ACX5000 line of

routers.
By having the active and standby states being defined by the access routers, Junos OS
mitigates potential primary path collisions, as there is a unique network element dictating
the preferable forwarding path to be elected. As an added value, this allows network
operators to switch forwarding paths on demand, which is quite useful for troubleshooting
and network maintenance purposes.
The active and standby states are communicated to the aggregation routers by making
use of an additional pseudowire state flag.
Table 45 on page 624 includes a list of the pseudowire state flags.
Table 45: Pseudowire Status Code for the Pseudowire Status TLV
Flag Code
L2CKT_PW_STATUS_PW_FWD 0x00000000
L2CKT_PW_STATUS_PW_NOT_FWD 0x00000001
L2CKT_PW_STATUS_AC_RX_FAULT 0x00000002
L2CKT_PW_STATUS_AC_TX_FAULT 0x00000004

Table 45: Pseudowire Status Code for the Pseudowire Status

TLV (continued)
Flag Code
L2CKT_PW_STATUS_PSN_RX_FAULT 0x00000008
L2CKT_PW_STATUS_PSN_TX_FAULT 0x00000010
L2CKT_PW_STATUS_PW_FWD_STDBY 0x00000020
Indicates the standby state.
L2CKT_PW_STATUS_SWITCH_OVER 0x00000040
In multichassis LAG (MC-LAG)-based scenarios, this same PW_FWD_STDBY flag is used

to advertise to remote PE devices which attachment circuit (AC) is being used as the
active one. Upon arrival of this flag, the receiving PE device drops any pseudowire built
toward the router originating this state. As we can see, this behavior denotes a slightly
different semantic for the PW_FWD_STDBY flag. As a consequence, you can configure
the hot-standby-vc-on statement to control whether the pseudowire must be constructed
upon arrival of the PW_FWD_STDBY flag (in the hot-standby pseudowire scenario), or
simply destroy it (in the MC-LAG scenario).
How It Works
The solution uses logical tunnel (lt-) paired interfaces for stitching the Layer 2 and Layer
3 domains.
Figure 32 on page 625 shows a diagram depicting how pseudowire redundancy in a mobile
backhaul scenario works.
Figure 32: Pseudowire Redundancy Mobile Backhaul Solution

LT ifl(y) INET
10.1.1.1.1/24
LT ifl(x) CCC (shared VIP)
CE2
PE1 PE3
10.1.1/24
Metro MPLS L3VPN Core MPLS
A1
ring VRF cloud
PE2 PE4
CE3
Primary virtual circuit

g041421
Standby virtual circuit

A Layer 2 pseudowire terminates on one of the logical tunnel interfaces (x), defined with
the circuit cross-connect (CCC) address family configured. A Layer 3 VPN (RFC 2547)
terminates the second logical tunnel interface (y), defined with the IPv4 (inet) address
family. Logical tunnel interface (x) and (y) are paired. Layer 2 pseudowires established
between each access router and its corresponding aggregation PE devices terminate on
the logical tunnel interface defined within each PE device. This logical tunnel interface
is used to establish a Layer 2 virtual circuit (VC) toward the remote end. In consequence,
the CCC address family needs to be configured on it. The same applies to the remote
end, where an equivalent interface needs to be defined with CCC capabilities.
This CCC logical tunnel interface created in the aggregation PE devices is paired with a
second logical tunnel interface on which the INET address family is enabled. This second
logical tunnel interface is configured within the context of an RFC 2547 Layer 3 VPN.
Within the scope of this document, we refer to the CCC and INET logical tunnel interfaces
as LT(x) and LT(y), respectively.
The Junos OS routing protocol process (rpd) enables the stitching required to interconnect
the Layer 2 VC ending in LT(x) and the associated LT(y).
In the aggregation PE routers, the routing process builds a pseudowire toward access
routers, and this happens regardless of the active or standby state of the pseudowire.
The same occurs in access routers, where the control and forwarding state is
preestablished in both the Routing Engine and the Packet Forwarding Engine to mitigate
traffic disruption during convergence periods.
An attachment circuit (AC) is a physical or virtual circuit (VC) that attaches a CE device
to a PE device. Local preference is used to provide better information than the multiple
exit discriminator (MED) value provides for a packet's path selection. You can configure
the local preference attribute so that it has a higher value for prefixes received from a
router that provides a desired path than prefixes received from a router that provides a
less desirable path. The higher the value, the more preferred the route. The local
preference attribute is the metric most often used in practice to express preferences for
one set of paths over another.
If the Layer 2 circuit is primary, the corresponding PE device advertises the AC’s subnet
with the higher local preference. All aggregation PE devices initially advertise the AC’s
subnet with the same local preference. You can configure a routing policy to allow a
higher local preference value to be advertised if the Layer 2 VC is active.
If a pseudowire is down, LT(x) is tagged with the CCC_Down flag. When this happens,
the corresponding PE device withdraws the AC subnet that was initially advertised. The
LT(y) address is shared between the aggregation PE devices as a virtual instance port
(VIP). No VRRP hello messages are exchanged. Both PE devices assume mastership.
Both primary and standby Layer 2 VCs are kept open to reduce traffic disruption in
backup-to-primary transitions. The hot-standby-vc-on configuration statement allows
manual activation.

Resiliency in the Layer 2 domain is provided through plain pseudowire redundancy for
back-to-back connections. For other topologies, pseudowire virtual circuit connectivity
verification (VCCV) is used.
Resiliency in the Layer 3 domain is provided by MPLS fast reroute and end-to-end service
restoration. A restoration timer prevents having VCs in the secondary path from being
switched back to the primary path immediately after the master PE device is restored.
Access routers can indicate to the aggregation routers which Layer 2 VC is considered to
be active. Upon arrival at LT(x) of a status TLV message communicating a standby state,
the routing process decreases the BGP's local preference value of the direct subnet
represented by the LT(y) IPv4 address. At this point, BGP proceeds to advertise this local
preference change to the rest of the members within the Layer 3 domain, which will then
reelect the designated forwarder PE device by relying on BGP's path selection
mechanisms.
A similar behavior occurs upon arrival of a status TLV message indicating a Layer 2 VC
active state. In this case, the receiving PE device changes the local preference
corresponding to the LT(y)'s subnet. The value to be used to either decrease or increase
the subnet's local preference value is manually configured using a policy.
Related • Example: Configuring Pseudowire Redundancy in a Mobile Backhaul Scenario

Documentation
Example: Configuring Pseudowire Redundancy in a Mobile Backhaul Scenario
This example shows how to configure pseudowire redundancy where Layer 2 and Layer
3 segments are interconnected in a mobile backhaul scenario.

Requirements
This example can be configured using the following software and hardware components:
• Junos OS Release 15.1X54–D60 or later
• ACX5000 routers as the access (A) routers
• MX Series routers acting as PE routers and transit label-switched routers
• T Series routers as the core routers

NOTE: The PE routers could also be T Series Core Routers but that is not
typical. Depending on your scaling requirements, the core routers could also
be MX Series 3D Universal Edge Routers or M Series Multiservice Edge Routers.
The customer edge (CE) devices could be other routers or switches from
Juniper Networks or another vendor.
No special configuration beyond device initialization is required before configuring this

example.
Overview
Device CE1 is a simple edge router with an IPv4 interface and a static route pointing to
the PE devices. Device A1 establishes two virtual circuits (VCs) toward Device PE1 and
Device PE2 by making use of the hot-standby statement. Device PE1 and Device PE2
terminate these VCs and enforce a policy condition over the logical tunnel IPv4 subnet.
Device PE3 performs as a Layer 3 VPN provider edge device by having an IPv4 interface
in a Layer 3 VPN shared with Device PE1 and Device PE2.
“CLI Quick Configuration” on page 628 shows the configuration for all of the devices in
Figure 33 on page 628.
The section “Step-by-Step Procedure” on page 634 describes the steps on Device A1 and
Device PE1.
Figure 33: Pseudowire Redundancy in a Mobile Backhaul Example

Topology
Metro MPLS Core MPLS

Layer 2 Domain Layer 3 Domain
10.10.0.101 10.31.0.101
PE1
ge-0/1/3 ge-0/1/2
10.21.0.101 ge-0/1/1
lt-1/2/0.600 lt-1/2/0.601
10.41.0.101
10.10.0.100 ge-1/3/1 ge-2/1/8 10.31.0.103
10.41.0.104/24 ge-1/3/2 10.53.0.103 10.53.0.105/24

A1 PE3
ge-1/3/3.600 ge-2/0/5 ge-2/0/8
CE1 CE2
10.20.0.100 ge-1/3/0 ge-2/0/3 10.32.0.103
lt-1/2/0.601
lo0: lt-1/2/0.600 10.41.0.102
CE1 192.168.0.104
CE2 192.168.0.105 10.21.0.102 ge-0/3/1
A1 192.166.0.100
g041423
PE1 192.168.0.101 ge-0/3/0 ge-0/3/3

PE2 192.168.0.102 PE2
10.20.0.102 10.32.0.102
PE3 192.168.0.103
Configuration

level.
Device CE1 set interfaces ge-1/3/3 vlan-tagging

set interfaces ge-1/3/3 unit 600 vlan-id 600
set interfaces lo0 unit 0 family inet address 192.168.0.104/32 primary
set routing-options static route 192.168.0.0/8 next-hop 10.41.0.1
set routing-options static route 10.53.0.0/16 next-hop 10.41.0.1
Device A1 set interfaces ge-1/3/0 unit 0 family inet address 10.20.0.100/24

set interfaces ge-1/3/2 vlan-tagging
set interfaces ge-1/3/2 encapsulation vlan-ccc
set interfaces ge-1/3/2 unit 600 encapsulation vlan-ccc
set interfaces ge-1/3/2 unit 600 family ccc
set routing-options autonomous-system 64510
set routing-options forwarding-table export pplb
set protocols rsvp interface lo0.0
set protocols isis interface lo0.0
set protocols l2circuit neighbor 192.168.0.101 interface ge-1/3/2.600 virtual-circuit-id 1
set protocols l2circuit neighbor 192.168.0.101 interface ge-1/3/2.600 pseudowire-status-tlv
set protocols l2circuit neighbor 192.168.0.101 interface ge-1/3/2.600 revert-time 10
maximum 60
set protocols l2circuit neighbor 192.168.0.101 interface ge-1/3/2.600 backup-neighbor
192.168.0.102 virtual-circuit-id 2
192.168.0.102 hot-standby
set policy-options policy-statement pplb then load-balance per-packet
Device PE1 set interfaces ge-0/1/1 unit 0 family inet address 10.21.0.101/24


set interfaces lt-1/2/0 unit 600 encapsulation vlan-ccc
set interfaces lt-1/2/0 unit 600 vlan-id 600
set interfaces lt-1/2/0 unit 600 peer-unit 601
set interfaces lt-1/2/0 unit 601 encapsulation vlan
set interfaces lt-1/2/0 unit 601 family inet filter input icmp_inet
set interfaces lt-1/2/0 unit 601 family inet filter output icmp_inet
set interfaces lt-1/2/0 unit 601 family inet address 10.41.0.101/24 vrrp-group 0
virtual-address 10.41.0.1
set interfaces lt-1/2/0 unit 601 family inet address 10.41.0.101/24 vrrp-group 0 accept-data
set protocols mpls label-switched-path to_PE3 to 192.168.0.103
set protocols bgp local-address 192.168.0.101
set protocols bgp group ibgp family inet-vpn any
set protocols bgp group ibgp peer-as 64511
set protocols bgp group ibgp neighbor 192.168.0.102
set protocols l2circuit neighbor 192.168.0.100 interface lt-1/2/0.600 virtual-circuit-id 1
set protocols l2circuit neighbor 192.168.0.100 interface lt-1/2/0.600 pseudowire-status-tlv
hot-standby-vc-on
set policy-options policy-statement l3vpn_export term primary from condition primary
set policy-options policy-statement l3vpn_export term primary then local-preference
add 300
set policy-options policy-statement l3vpn_export term primary then community set l3vpn
set policy-options policy-statement l3vpn_export term primary then accept
set policy-options policy-statement l3vpn_export term standby from condition standby
set policy-options policy-statement l3vpn_export term standby then local-preference
add 30
set policy-options policy-statement l3vpn_export term standby then community set l3vpn

set policy-options policy-statement l3vpn_export term standby then accept

set policy-options policy-statement l3vpn_export term default then community set l3vpn
set policy-options policy-statement l3vpn_export term default then accept
set policy-options policy-statement l3vpn_import term 1 from community l3vpn
set policy-options policy-statement l3vpn_import term 1 then accept
set policy-options policy-statement l3vpn_import term default then reject
set policy-options policy-statement ospf_export term 0 from community l3vpn
set policy-options policy-statement ospf_export term 0 then accept
set policy-options community l3vpn members target:64511:600
set policy-options condition primary if-route-exists address-family ccc lt-1/2/0.600
set policy-options condition primary if-route-exists address-family ccc table mpls.0
set policy-options condition primary if-route-exists address-family ccc peer-unit 601
set policy-options condition standby if-route-exists address-family ccc lt-1/2/0.600
set policy-options condition standby if-route-exists address-family ccc table mpls.0
set policy-options condition standby if-route-exists address-family ccc standby
set policy-options condition standby if-route-exists address-family ccc peer-unit 601
set firewall family inet filter icmp_inet interface-specific
set firewall family inet filter icmp_inet term 0 from source-address 10.41.0.101/32 except
set firewall family inet filter icmp_inet term 0 from source-address 10.0.0.0/8
set firewall family inet filter icmp_inet term 0 from protocol icmp
set firewall family inet filter icmp_inet term 0 then count icmp_inet
set firewall family inet filter icmp_inet term 0 then log
set firewall family inet filter icmp_inet term 0 then accept
set routing-instances l3vpn instance-type vrf
set routing-instances l3vpn interface lt-1/2/0.601
set routing-instances l3vpn interface lo0.1
set routing-instances l3vpn route-distinguisher 192.168.1.101:64511
set routing-instances l3vpn vrf-import l3vpn_import
set routing-instances l3vpn vrf-export l3vpn_export
set routing-instances l3vpn vrf-table-label
set routing-instances l3vpn protocols ospf export ospf_export
set routing-instances l3vpn protocols ospf area 0.0.0.0 lt-1/2/0.601
set routing-instances l3vpn protocols ospf area 0.0.0.0 lo0.1
set interfaces lt-1/2/0 unit 600 encapsulation vlan-ccc
set interfaces lt-1/2/0 unit 601 encapsulation vlan
set interfaces lt-1/2/0 unit 601 family inet filter input icmp_inet
set interfaces lt-1/2/0 unit 601 family inet filter output icmp_inet
set interfaces lt-1/2/0 unit 601 family inet address 10.41.0.102/24 vrrp-group 0
virtual-address 10.41.0.1
set interfaces lt-1/2/0 unit 601 family inet address 10.41.0.102/24 vrrp-group 0 accept-data


set protocols l2circuit neighbor 192.168.0.100 interface lt-1/2/0.600 virtual-circuit-id 2
set protocols l2circuit neighbor 192.168.0.100 interface lt-1/2/0.600 pseudowire-status-tlv
hot-standby-vc-on
set policy-options policy-statement l3vpn_export term primary from condition primary
set policy-options policy-statement l3vpn_export term primary then local-preference
add 300
set policy-options policy-statement l3vpn_export term primary then community set l3vpn
set policy-options policy-statement l3vpn_export term primary then accept
set policy-options policy-statement l3vpn_export term standby from condition standby
set policy-options policy-statement l3vpn_export term standby then local-preference
add 30
set policy-options policy-statement l3vpn_export term standby then community set l3vpn
set policy-options policy-statement l3vpn_export term standby then accept
set policy-options policy-statement l3vpn_export term default then community set l3vpn
set policy-options policy-statement l3vpn_export term default then accept
set policy-options policy-statement l3vpn_import term 1 from community l3vpn
set policy-options policy-statement l3vpn_import term 1 then accept
set policy-options policy-statement l3vpn_import term default then reject
set policy-options condition primary if-route-exists address-family ccc lt-1/2/0.600
set policy-options condition primary if-route-exists address-family ccc table mpls.0
set policy-options condition primary if-route-exists address-family ccc peer-unit 601
set policy-options condition standby if-route-exists address-family ccc lt-1/2/0.600
set policy-options condition standby if-route-exists address-family ccc table mpls.0
set policy-options condition standby if-route-exists address-family ccc standby
set policy-options condition standby if-route-exists address-family ccc peer-unit 601
set firewall family inet filter icmp_inet interface-specific

set firewall family inet filter icmp_inet term 0 from source-address 10.41.0.102/32 except
set firewall family inet filter icmp_inet term 0 from source-address 10.0.0.0/8
set firewall family inet filter icmp_inet term 0 from protocol icmp
set firewall family inet filter icmp_inet term 0 then count icmp_inet
set firewall family inet filter icmp_inet term 0 then log
set routing-instances l3vpn interface lt-1/2/0.601
set routing-instances l3vpn vrf-import l3vpn_import
set routing-instances l3vpn vrf-export l3vpn_export
set routing-instances l3vpn protocols ospf area 0.0.0.0 interface lt-1/2/0.601
set routing-instances l3vpn protocols ospf area 0.0.0.0 interface lo0.1
set policy-options policy-statement l3vpn_ospf_export term 0 from protocol direct
set policy-options policy-statement l3vpn_ospf_export term 0 then accept
set policy-options policy-statement l3vpn_ospf_import term 0 from protocol bgp
set policy-options policy-statement l3vpn_ospf_import term 0 from community l3vpn
set policy-options policy-statement l3vpn_ospf_import term 0 then accept


set routing-instances l3vpn interface ge-2/0/5.0
set routing-instances l3vpn vrf-target target:64511:600
set routing-instances l3vpn protocols ospf area 0.0.0.0 interface ge-2/0/5.0
set routing-instances l3vpn protocols ospf area 0.0.0.0 interface lo0.1
Device CE2 set interfaces ge-2/0/8 unit 0 family inet address 10.53.0.105/24
To configure Device A1:
Enable MPLS on the core-facing interfaces. The ISO address family is also enabled,
because IS-IS is used as the interior gateway protocol (IGP) in the provider network.
On the customer-facing interface, you do not need to enable MPLS. On this interface,
enable CCC encapsulation and address family CCC.
[edit interfaces]
user@A1# set ge-1/3/0 unit 0 family inet address 10.20.0.100/24
user@A1# set ge-1/3/0 unit 0 family iso
user@A1# set ge-1/3/0 unit 0 family mpls
user@A1# set ge-1/3/1 unit 0 family inet address 10.10.0.100/24

user@A1# set ge-1/3/1 unit 0 family iso
user@A1# set ge-1/3/1 unit 0 family mpls
user@A1# set ge-1/3/2 vlan-tagging

user@A1# set ge-1/3/2 encapsulation vlan-ccc
user@A1# set ge-1/3/2 unit 600 encapsulation vlan-ccc
user@A1# set ge-1/3/2 unit 600 vlan-id 600
user@A1# set ge-1/3/2 unit 600 family ccc
user@A1# set lo0 unit 0 family inet address 192.168.0.100/32 primary

user@A1# set lo0 unit 0 family iso address 49.0002.0192.0168.0100.00
2. Configure the RSVP on the core-facing interfaces and on the loopback interface.
RSVP is used in the Layer 3 domain.

[edit protocols rsvp]

user@A1# set interface ge-1/3/0.0
user@A1# set interface lo0.0
3. Configure LDP on the core-facing interfaces and on the loopback interface.
LDP is used in Layer 2 domain.

4. Configure MPLS on the core-facing interfaces.

5. Configure an interior gateway protocol, such as IS-IS or OSPF, on the core-facing

interfaces and on the loopback interface.

6. On the interface that faces the customer edge, configure the Layer 2 circuit.
Configure the hot-standby statement on those routers with both active and standby
virtual circuits (VCs) (Device A1 in our topology). You must include the
pseudowire-status-tlv statement on access routers. Without the status TLV signaling,
the standby flag cannot be advertised to remote provider edge (PE) devices.
The revert-time statement and the maximum option must also be configured on
access routers. Without the revert-time statement, traffic of all the VCs will not be
transitioned to the primary path upon completion of the restoration. If a revert-time
delay is defined but a maximum delay is not, then VCs are restored immediately
upon the revert timer's expiration. The maximum option allows the VCs to be
restored in a scattered fashion rather than all at once.
[edit protocols l2circuit neighbor 192.168.0.101 interface ge-1/3/2.600]

user@A1# set virtual-circuit-id 1
user@A1# set pseudowire-status-tlv
user@A1# set revert-time 10 maximum 60
user@A1# set backup-neighbor 192.168.0.102 virtual-circuit-id 2
user@A1# set backup-neighbor 192.168.0.102 hot-standby
7. To have the unilist next hop get pushed to other access routers, configure per-packet
load balancing.
[edit policy-options policy-statement pplb]

user@A1# set then load-balance per-packet

8. Apply the per-packet load balancing policy.
[edit routing-options forwarding-table]

user@A1# set export pplb
9. Configure the autonomous system (AS) ID and the router ID.
user@A1# set router-id 192.168.0.100
user@A1# set autonomous-system 64510
Similarly, configure any other access devices.
To configure Device PE1:
Enable MPLS on the core-facing interfaces.
[edit interfaces]
user@PE1# set ge-0/1/1 unit 0 family inet address 10.21.0.101/24
user@PE1# set ge-0/1/1 unit 0 family iso
user@PE1# set ge-0/1/1 unit 0 family mpls


user@PE1# set lo0 unit 0 family inet address 192.168.0.101/32 primary

user@PE1# set lo0 unit 0 family iso address 49.0002.0192.0168.0003.00
user@PE1# set lo0 unit 1 family inet address 192.168.1.101/32
2. On Device PE1 and Device PE2, which are aggregation routers, configure a pair of
logical tunnel interfaces to represent LT(x) and LT(y).
The solution uses logical tunnel (lt-) paired interfaces for stitching the Layer 2 and
Layer 3 domains.
A Layer 2 pseudowire terminates on one of the logical tunnel interfaces, LT(x),

defined with the circuit cross-connect (CCC) address family. A Layer 3 VPN
terminates the second logical tunnel interface, LT(y), defined with the IPv4 (inet)
address family. LT(x) and LT(y) are paired.
[edit interfaces]
user@PE1# set lt-1/2/0 unit 600 encapsulation vlan-ccc
user@PE1# set lt-1/2/0 unit 600 vlan-id 600

user@PE1# set lt-1/2/0 unit 600 peer-unit 601
user@PE1# set lt-1/2/0 unit 601 encapsulation vlan

user@PE1# set lt-1/2/0 unit 601 vlan-id 600
user@PE1# set lt-1/2/0 unit 601 peer-unit 600
user@PE1# set lt-1/2/0 unit 601 family inet filter input icmp_inet
user@PE1# set lt-1/2/0 unit 601 family inet filter output icmp_inet
3. (Optional) Associate a unique VRRP address with both Device PE1 and Device PE2.
In this case, both Device PE1 and Device PE2 assume the mastership state for the
defined VIP IPv4 address, so no VRRP hello message are exchanged between the
routers.
[edit interfaces lt-1/2/0 unit 601 family inet address 10.41.0.101/24]

user@PE1# set vrrp-group 0 virtual-address 10.41.0.1
user@PE1# set vrrp-group 0 accept-data
4. Configure IS-IS or another IGP.

user@PE1# set interface ge-0/1/1.0
user@PE1# set interface lo0.0
5. Configure the MPLS on the core-facing interfaces.

6. Configure label-switched paths to the other PE devices.
BGP is a policy-driven protocol, so also configure and apply any needed routing
policies. For example, you might want to export static routes into BGP.

user@PE1# set label-switched-path to_PE3 to 192.168.0.103
user@PE1# set label-switched-path to_PE2 to 192.168.0.102
7. Configure LDP on the core-facing interfaces and on the loopback interface.

8. Configure RSVP on the core-facing interfaces and on the loopback interface.
[edit protocols rsvp]



9. Configure internal BGP (IBGP).
[edit protocols bgp]

user@PE1# set local-address 192.168.0.101
user@PE1# set group ibgp family inet-vpn any
user@PE1# set group ibgp peer-as 64511
user@PE1# set group ibgp neighbor 192.168.0.102
user@PE1# set group ibgp neighbor 192.168.0.103
10. Configure the Layer 2 circuit on the logical tunnel interface.
Configure the hot-standby-vc-on statement if you want a hot standby pseudowire

to be established upon arrival of PW_FWD_STDBY status TLV.
[edit protocols l2circuit neighbor 192.168.0.100 interface lt-1/2/0.600]

user@PE1# set virtual-circuit-id 1
user@PE1# set pseudowire-status-tlv hot-standby-vc-on
11. Define a pair of conditions to be applied to the egress policy defined within the Layer
3 VPN instance.
In both condition primary and condition standby, the matching route corresponds
to the interface lt-1/2/0.600 (y), as this is the format in which egress routes appear
in routing table mpls.0 to represent any given pseudowire.
The difference between these conditions is in the standby attribute. Upon arrival of
the PW_FWD_STDBY status TLV to Device PE1 or Device PE2, Junos OS matches
condition standby, and in consequence, only term standby within the l3vpn policy
will be executed. On the other hand, if the PW_FWD_STDBY status TLV is not
present, the policy matches only condition primary, which then executes term primary
in the l3vpn policy. Also, for logical tunnel-based CCC services, you must specify
the logical tunnel interface, LT(y), that is associated with the logical tunnel CCC
interface, LT(x). (See “Understanding Pseudowire Redundancy Mobile Backhaul
Scenarios” on page 623.)
Finally, for CCC-based conditions, Junos OS allows only mpls.0 as the matching
routing table. For the address attribute, Junos OS allows only strings with a logical
interface unit format (for example, lt-0/0/0.0).
[edit policy-options condition primary if-route-exists address-family ccc]

user@PE1# set lt-1/2/0.600
user@PE1# set table mpls.0
user@PE1# set peer-unit 601
[edit policy-options condition standby if-route-exists address-family ccc]

user@PE1# set lt-1/2/0.600
user@PE1# set table mpls.0
user@PE1# set standby
user@PE1# set peer-unit 601

12. Configure the Layer 3 VPN export policy.
If the Layer 2 virtual circuit (VC) is primary, the corresponding provider edge (PE)
routing device advertises the attachment circuit’s (AC’s) subnet with the higher
local preference. All aggregation PE devices initially advertise the AC’s subnet with
the same local preference.
This routing policy allows a higher local preference value to be advertised if the
Layer 2 VC is active.
[edit policy-options policy-statement l3vpn_export]

user@PE1# set term primary from condition primary
user@PE1# set term primary then local-preference add 300
user@PE1# set term primary then community set l3vpn
user@PE1# set term primary then accept
user@PE1# set term standby from condition standby

user@PE1# set term standby then local-preference add 30
user@PE1# set term standby then community set l3vpn
user@PE1# set term standby then accept
user@PE1# set term default then community set l3vpn

user@PE1# set term default then accept
13. Configure the Layer 3 VPN community members.
[edit policy-options community l3vpn]

user@PE1# set members target:64511:600
14. Configure the Layer 3 VPN import policy, based on the Layer 3 VPN community.
[edit policy-options policy-statement l3vpn_import]

user@PE1# set term 1 from community l3vpn
user@PE1# set term 1 then accept
user@PE1# set term default then reject
15. Configure OSPF export policy, based on the Layer 3 VPN community.
[edit policy-options policy-statement ospf_export term 0]

user@PE1# set from community l3vpn
user@PE1# set then accept
16. (Optional) Configure a firewall filter to check the path taken by traffic.
[edit firewall family inet filter icmp_inet]

user@PE1# set interface-specific
user@PE1# set term 0 from source-address 10.41.0.101/32 except
user@PE1# set term 0 from source-address 10.0.0.0/8
user@PE1# set term 0 from protocol icmp
user@PE1# set term 0 then count icmp_inet
user@PE1# set term 0 then log

17. Configure the routing instance.
This routing instance is in the Layer 2 domain where Device PE1 and Device PE2 are
interconnected to the metro ring over multiaccess media (Ethernet). You must
include the vrf-table-label statement on Device PE1 and Device PE2 to enable
advertisement of the direct subnet prefix corresponding to the logical tunnel (lt-)
interface toward the Layer 3 domain.
Device PE1 and Device PE2 use OSPF for Layer 3 VPN communication with Device
CE1.
[edit routing-instances l3vpn]

user@PE1# set instance-type vrf
user@PE1# set interface lt-1/2/0.601
user@PE1# set route-distinguisher 192.168.1.101:64511
user@PE1# set vrf-import l3vpn_import
user@PE1# set vrf-export l3vpn_export
user@PE1# set vrf-table-label
user@PE1# set protocols ospf export ospf_export
user@PE1# set protocols ospf area 0.0.0.0 interface lt-1/2/0.601
user@PE1# set protocols ospf area 0.0.0.0 interface lo0.1
18. Configure the autonomous system (AS) ID and router ID.
user@PE1# set router-id 192.168.0.101
user@PE1# set autonomous-system 64511
Similarly, configure Device PE2.
Results From configuration mode, confirm your configuration by entering the show interfaces,
show firewall, show protocols, show policy-options, show routing-options, and show
routing-instances commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
Device A1 user@A1# show interfaces

ge-1/3/0 {
unit 0 {
family inet {
address 10.20.0.100/24;
}
family iso;
family mpls;
}
}
ge-1/3/1 {
unit 0 {
family inet {
address 10.10.0.100/24;
}
family iso;
family mpls;
}

}
ge-1/3/2 {
vlan-tagging;
unit 600 {
vlan-id 600;
family ccc;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.100/32 {
primary;
}
}
family iso {
address 49.0002.0192.0168.0100.00;
}
}
}
user@A1# show protocols

rsvp {
interface lo0.0;
}
mpls {
}
isis {
interface lo0.0;
}
ldp {
interface lo0.0;
}
l2circuit {
neighbor 192.168.0.101 {
backup-neighbor 192.168.0.102 {
hot-standby;
}
}
}
}

user@A1# show policy-options

policy-statement pplb {
then {
}
}
user@A1# show routing-options

autonomous-system 64510;
router-id 192.168.0.100;
forwarding-table {
export pplb;
}
Device PE1 user@PE1# show interfaces

ge-0/1/1 {
unit 0 {
family inet {
address 10.21.0.101/24;
}
family iso;
family mpls;
}
}
ge-0/1/2 {
unit 0 {
family inet {
address 10.31.0.101/24;
}
family iso;
family mpls;
}
}
ge-0/1/3 {
unit 0 {
family inet {
address 10.10.0.101/24;
}
family iso;
family mpls;
}
}
lt-1/2/0 {
unit 600 {
vlan-id 600;
peer-unit 601;
}
unit 601 {
encapsulation vlan;
vlan-id 600;
peer-unit 600;
family inet {
filter {
input icmp_inet;
output icmp_inet;

}
address 10.41.0.101/24 {
vrrp-group 0 {
virtual-address 10.41.0.1;
accept-data;
}
}
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.101/32 {
primary;
}
}
family iso {
address 49.0002.0192.0168.0003.00;
}
}
unit 1 {
family inet {
address 192.168.1.101/32;
}
}
}
user@PE1# show firewall

family inet {
filter icmp_inet {
interface-specific;
term 0 {
from {
source-address {
10.41.0.101/32 except;
10.0.0.0/8;
}
protocol icmp;
}
then {
count icmp_inet;
log;
accept;
}
}
term 1 {
then accept;
}
}
}
user@PE1# show protocols

rsvp {

interface lo0.0;
}
mpls {
label-switched-path to_PE3 {
to 192.168.0.103;
}
label-switched-path to_PE2 {
to 192.168.0.102;
}
}
bgp {
local-address 192.168.0.101;
group ibgp {
family inet-vpn {
any;
}
peer-as 64511;
neighbor 192.168.0.102;
neighbor 192.168.0.103;
}
}
isis {
interface lo0.0;
}
ldp {
interface lo0.0;
}
l2circuit {
neighbor 192.168.0.100 {
interface lt-1/2/0.600 {
pseudowire-status-tlv hot-standby-vc-on;
}
}
}
user@PE1# show policy-options

policy-statement l3vpn_export {
term primary {
from condition primary;
then {
local-preference add 300;
community set l3vpn;
accept;
}
}

term standby {
from condition standby;
then {
local-preference add 30;
accept;
}
}
term default {
then {
accept;
}
}
}
policy-statement l3vpn_import {
term 1 {
from community l3vpn;
then accept;
}
term default {
then reject;
}
}
policy-statement ospf_export {
term 0 {
from community l3vpn;
then accept;
}
}
community l3vpn members target:64511:600;
condition primary {
if-route-exists {
address-family {
ccc {
lt-1/2/0.600;
table mpls.0;
peer-unit 601;
}
}
}
}
condition standby {
if-route-exists {
address-family {
ccc {
lt-1/2/0.600;
table mpls.0;
standby;
peer-unit 601;
}
}
}
}
user@PE1# show routing-options

router-id 192.168.0.101;
user@PE1# show routing-instances

l3vpn {
instance-type vrf;
interface lt-1/2/0.601;
interface lo0.1;
route-distinguisher 192.168.1.101:64511;
vrf-import l3vpn_import;
vrf-export l3vpn_export;
vrf-table-label;
protocols {
ospf {
export ospf_export;
area 0.0.0.0 {
interface lt-1/2/0.601;
interface lo0.1;
}
}
}
}
If you are done configuring the devices, enter commit from configuration mode.
Verification
• Checking Layer 2 Circuits on page 646

• Checking the Policy Conditions on page 648
Checking Layer 2 Circuits
Purpose Upon Layer 2 virtual circuit (VC) establishment, the output of the show l2circuit
connections command shows the active and the hot-standby VC. In addition, control-plane
details are shown for the hot-standby VC.
Action From operational mode, enter the show l2circuit connections extensive command.
user@A1> show l2circuit connections extensive
Layer-2 Circuit Connections:
Legend for connection status (St)

EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad SP -- Static Pseudowire
LD -- local site signaled down RS -- remote site standby

RD -- remote site signaled down HS -- Hot-standby Connection

XX -- unknown
Legend for interface status

Up -- operational
Dn -- down
Neighbor: 192.168.0.101
Interface Type St Time last up # Up trans
ge-1/3/2.600(vc 1) rmt Up Jan 24 11:00:26 2013 1
Remote PE: 192.168.0.101, Negotiated control-word: Yes (Null)
Incoming label: 299776, Outgoing label: 299776
Negotiated PW status TLV: Yes
local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
Local interface: ge-1/3/2.600, Status: Up, Encapsulation: VLAN
Connection History:
Jan 24 11:00:26 2013 status update timer
Jan 24 11:00:26 2013 PE route changed
Jan 24 11:00:26 2013 Out lbl Update 299776
Jan 24 11:00:26 2013 In lbl Update 299776
Jan 24 11:00:26 2013 loc intf up ge-1/3/2.600
Neighbor: 192.168.0.102
ge-1/3/2.600(vc 2) rmt HS ----- ----
user@PE1> show l2circuit connections extensive

XX -- unknown

Up -- operational
Dn -- down
Neighbor: 192.168.0.100
lt-1/2/0.600(vc 1) rmt Up Jan 24 11:06:36 2013 1
Local interface: lt-1/2/0.600, Status: Up, Encapsulation: VLAN
Connection History:

Jan 24 11:06:36 2013 In lbl Update 299776

Jan 24 11:06:36 2013 loc intf up lt-1/2/0.600
user@PE2> show l2circuit connections extensive

XX -- unknown

Up -- operational
Dn -- down
Neighbor: 192.168.0.100
lt-1/2/0.600(vc 2) rmt Up Jan 24 10:55:31 2013 1
Local interface: lt-1/2/0.600, Status: Up, Encapsulation: VLAN
Connection History:
Jan 24 10:55:31 2013 In lbl Update 299776
Jan 24 10:55:31 2013 loc intf up lt-1/2/0.600
Meaning From the perspective of Device PE1 and Device PE2, a single Layer 2 circuit is established
toward access routers, so there is no standby device information in the CLI output of the
show l2circuit connections command. Note that no timing and flapping information is
provided for the VC acting as the hot-standby. Junos OS allows only these counters to
be tracked for the active VC.
Checking the Policy Conditions
Purpose On the PE devices, verify the state of the different conditions defined as part of the Layer3
VPN's egress policy, where 10.41.0.0/24 corresponds to the logical tunnel (y) subnet.
Action From operational mode, enter the show policy conditions detail command.
user@PE1> show policy conditions detail

Configured conditions:
Condition primary (static), event: Existence of a route in a specific routing
table
Dependent routes:
10.41.0.0/24, generation 8
192.168.0.104/32, generation 8
Condition standby (static), event: Existence of a route in a specific routing

table
Dependent routes:
None
Condition tables:
Table mpls.0, generation 0, dependencies 0, If-route-exists conditions: primary
(static) standby (static)
Table l3vpn.inet.0, generation 12, dependencies 2
user@PE2> show policy conditions detail

Configured conditions:
Condition primary (static), event: Existence of a route in a specific routing
table
Dependent routes:
10.41.0.0/24, generation 18
Condition standby (static), event: Existence of a route in a specific routing

table
Dependent routes:
10.41.0.0/24, generation 18
Condition tables:
Table mpls.0, generation 0, dependencies 0, If-route-exists conditions: primary
(static) standby (static)
Table l3vpn.inet.0, generation 367, dependencies 2
Related • Understanding Pseudowire Redundancy Mobile Backhaul Scenarios on page 623

Documentation


CHAPTER 21
Configuring Virtual Router Redundancy

Protocol (VRRP)
• Understanding VRRP on ACX Series Routers on page 651

• Configuring Basic VRRP Support on page 653
• Configuring the Advertisement Interval for the VRRP Master Router on page 655
• Configuring a Backup Router to Preempt the Master Router on page 656
• Modifying the Preemption Hold-Time Value on page 657
• Configuring Asymmetric Hold Time for VRRP Routers on page 657
• Configuring an Interface to Accept Packets Destined for the Virtual IP
Address on page 658
• Configuring a Logical Interface to Be Tracked on page 659
• Configuring a Route to Be Tracked on page 661
• Configuring the Silent Period on page 663
• Tracing VRRP Operations on page 664
• Example: Configuring VRRP on page 665
• Configuring VRRP for IPv6 on page 667
Understanding VRRP on ACX Series Routers
For Ethernet, Fast Ethernet, Gigabit Ethernet, 10-Gigabit Ethernet, and logical interfaces,
you can configure Virtual Router Redundancy Protocol (VRRP). VRRP enables hosts on
a LAN to make use of redundant routers on that LAN without requiring more than the
static configuration of a single default route on the hosts. The routers running VRRP share
the IP address corresponding to the default route configured on the hosts. At any time,
one of the routers running VRRP is the master (active) and the others are backups. If the
master fails, one of the backup routers becomes the new master router, providing a virtual
default router and enabling traffic on the LAN to be routed without relying on a single
router. Using VRRP, a backup router can take over a failed default router within a few
seconds. This is done with minimum VRRP traffic and without any interaction with the
hosts.

NOTE: You can configure VRRP on Integrated Routing and Bridging (IRB)
interfaces.
Routers running VRRP dynamically elect master and backup routers. You can also force
assignment of master and backup routers using priorities from 1 through 255, with 255
being the highest priority. In VRRP operation, the default master router sends
advertisements to backup routers at regular intervals. The default interval is 1 second. If
a backup router does not receive an advertisement for a set period, the backup router
with the next highest priority takes over as master and begins forwarding packets.
NOTE: To minimize network traffic, VRRP is designed in such a way that only
the router that is acting as the master sends out VRRP advertisements at
any given point in time. The backup routers do not send any advertisement
until they take over mastership.
Figure 34 on page 652 illustrates a basic VRRP topology for IPv4 family. In this example,
Routers A, B, and C are running VRRP and together they make up a virtual router. The IP
address of this virtual router is 10.10.0.1 (the same address as the physical interface of
Router A).
Figure 34: Basic VRRP for IPv4 Family
Because the virtual router uses the IP address of the physical interface of Router A, Router
A is the master VRRP router, while Routers B and C function as backup VRRP routers.
Clients 1 through 3 are configured with the default gateway IP address of 10.10.0.1. As the
master router, Router A forwards packets sent to its IP address. If the master virtual router
fails, the backup router configured with the higher priority becomes the master virtual
router and provides uninterrupted service for the LAN hosts. When Router A recovers, it
becomes the master virtual router again.
NOTE: ACX Series routers support VRRP version 3 for IPv6 addresses.
ACX routers can support up to 64 VRRP group entries. These can be a combination of
IPv4 or IPv6 families. If either of the family (IPv4 or IPv6) is solely configured for VRRP,

Chapter 21: Configuring Virtual Router Redundancy Protocol (VRRP)
then 64 unique VRRP group identifiers are supported. If both IPv4 and IPv6 families share
the same VRRP group, then only 32 unique VRRP identifiers are supported.
Related • Configuring Basic VRRP Support on page 653

Documentation
• Configuring an Interface to Accept Packets Destined for the Virtual IP Address on

page 658
• Example: Configuring VRRP for IPv6
Configuring Basic VRRP Support
An interface can be a member of one or more VRRP groups. To configure basic VRRP
support, configure VRRP groups on interfaces by including the vrrp-group statement:
vrrp-group group-id {
priority number;
virtual-address [ addresses ];
}
You can include this statement at the following hierarchy level:
• [edit interfaces interface-name unit logical-unit-number family inet address address]
Within a VRRP group, the master virtual router and the backup virtual router must be
configured on two different routers.
For each VRRP group, you must configure the following:
• Group identifier—Assign a value from 0 through 255.
• Address of one or more virtual routers that are members of the VRRP group—Normally,
you configure only one virtual IP address per group. However, you can configure up to
eight addresses. Do not include a prefix length in a virtual IP address. The following
considerations apply to configuring a virtual IP address:
• The virtual router IP address must be the same for all routers in the VRRP group.
• If you configure a virtual IP address to be the same as the physical interface’s address,
the interface becomes the master virtual router for the group. In this case, you must
configure the priority to be 255, and you must configure preemption by including the
preempt statement.
• If the virtual IP address you choose is not the same as the physical interface’s address,
you must ensure that the virtual IP address does not appear anywhere else in the

router’s configuration. Verify that you do not use this address for other interfaces,
for the IP address of a tunnel, or for the IP address of static ARP entries.
• You cannot configure the same virtual IP address on interfaces that belong to the
same logical system and routing instance combination. However, you can configure
the same virtual IP address on interfaces that belong to different logical system and
routing instance combinations.
• Priority for a router to become the master virtual router—Configure the value used to
elect the master virtual router in the VRRP group. It can be a number from 1 through
255. The default value for backup routers is 100. A larger value indicates a higher priority.
The router with the highest priority within the group becomes the master router.
NOTE: If there are two or more backup routers with the same priority, the
router that has the highest primary address becomes the master.
NOTE: Mixed tagging (configuring two logical interfaces on the same Ethernet
port, one with single-tag framing and one with dual-tag framing) is supported
only for interfaces on Gigabit Ethernet IQ2 and IQ PICs. If you include the
flexible-vlan-tagging statement at the [edit interfaces interface-name] hierarchy
level for a VRRP-enabled interface on a PIC that does not support mixed
tagging, VRRP on that interface is disabled. In the output of the show vrrp
summary command, the interface status is listed as Down.
NOTE: If you enable MAC source address filtering on an interface, you must
include the virtual MAC address in the list of source MAC addresses that you
specify in the source-address-filter statement at the [edit interfaces
interface-name] hierarchy level. MAC addresses ranging from 00:00:5e:00:01:01
through 00:00:5e:00:01:ff are reserved for VRRP, as defined in RFC 2378. For
IPv6, the MAC addresses range from 00:00:5e:00:02:01 through
00:00:5e:00:02:ff. The VRRP group number must be the decimal equivalent
of the last hexadecimal byte of the virtual MAC address.
NOTE: For faster convergence, RFC recommends better difference of priorities

for VRRP routers. For example, if you have three routers in a VRRP group, it
is recommended to assign the router priority as:
• Priority of master router as 254.
• Priority of backup router 1 as 200.
• Priority of backup router 2 as 150.

Related • Understanding VRRP on ACX Series Routers on page 651

Documentation

page 658
• Example: Configuring VRRP for IPv6
Configuring the Advertisement Interval for the VRRP Master Router
By default, the master router sends VRRP advertisement packets every second to all
members of the VRRP group. These packets indicate that the master router is still
operational. If the master router fails or becomes unreachable, the backup router with
the highest priority value becomes the new master router.
You can modify the advertisement interval in seconds or in milliseconds. The interval
must be the same for all routers in the VRRP group.
This topic contains the following sections:
• Modifying the Advertisement Interval in Seconds on page 655

• Modifying the Advertisement Interval in Milliseconds on page 655
Modifying the Advertisement Interval in Seconds

To modify the time, in seconds, between the sending of VRRP advertisement packets,
include the advertise-interval statement:
advertise-interval seconds;
The interval can be from 1 through 255 seconds.
• [edit interfaces interface-name unit logical-unit-number family inet address address

vrrp-group group-id]
Modifying the Advertisement Interval in Milliseconds

To modify the time, in milliseconds, between the sending of VRRP advertisement packets,
include the fast-interval statement:
fast-interval milliseconds;


The range of values is from 100 through 40,950 milliseconds (ms).

Documentation

page 658
Configuring a Backup Router to Preempt the Master Router
By default, a higher-priority backup router preempts a lower-priority master router. To

explicitly enable the master router to be preempted, include the preempt statement:
preempt;

To prohibit a higher-priority backup router from preempting a lower-priority master router,

include the no-preempt statement:
no-preempt;

Documentation

page 658

Modifying the Preemption Hold-Time Value
The hold time is the maximum number of seconds that can elapse before a higher-priority
backup router preempts the master router. You might want to configure a hold time so
that all Junos OS components converge before preemption.
By default, the hold-time value is 0 seconds. A value of 0 means that preemption can
occur immediately after the backup router comes online.
NOTE: The hold time is counted from the time the backup router comes
online. The hold time is only valid when the VRRP router is just coming online.
To modify the preemption hold-time value, include the hold-time statement:
hold-time seconds;
The hold time can be from 0 through 3600 seconds.

vrrp-group group-id preempt]

Documentation

page 658
Configuring Asymmetric Hold Time for VRRP Routers
The asymmetric-hold-time statement at the [edit protocols vrrp] hierarchy level enables
you to configure a VRRP master router to switch over to the backup router
immediately—that is, without waiting for the priority hold time to expire—when a tracked
interface or route goes down or when the bandwidth of a tracked interface decreases.
Such events can cause an immediate reduction in the priority based on the configured
priority cost for the event, and trigger a mastership election.
However, when the tracked route or interface comes up again, or when the bandwidth
for a tracked interface increases, the backup (original master) router waits for the hold

time to expire before it updates the priority and initiates the switchover if the priority is
higher than the priority for the VRRP master (original backup) router.
If the asymmetric-hold-time statement is not configured, the VRRP master waits for the
hold time to expire before it initiates a switchover when a tracked route goes down.
Here is an example for configuring asymmetric hold time:
[edit]
user@host# set protocols vrrp asymmetric-hold-time
[edit]
user@host# show protocols vrrp
asymmetric-hold-time;

Documentation

page 658
Configuring an Interface to Accept Packets Destined for the Virtual IP Address
In VRRP implementations where the router acting as the master router is not the IP
address owner—the IP address owner is the router that has the interface whose actual
IP address is used as the virtual router’s IP address (virtual IP address)—the master router
accepts only the Address Resolution Protocol (ARP) packets from the packets that are
sent to the virtual IP address. Junos OS enables you to override this limitation with the
help of the accept-data configuration. When the accept-data statement is included in
the configuration, the master router accepts all packets sent to the virtual IP address
even when the master router is not the IP address owner.
NOTE: If the master router is the IP address owner or has its priority set to
255, the master router, by default, accepts all packets addressed to the virtual
IP address. In such cases, the accept-data configuration is not required.
To configure an interface to accept all packets sent to the virtual IP address, include the
accept-data statement:
accept-data;


To prevent a master router that is the IP address owner or has its priority set to 255 from
accepting packets other than the ARP packets addressed to the virtual IP address, include
the no-accept-data statement:
no-accept-data;
NOTE:
• If you want to restrict the incoming IP packets to ICMP packets only, you
must configure firewall filters to accept only ICMP packets.
• If you include the accept-data statement, your router configuration does

not comply with RFC 3768 (see section 6.4.3 of RFC 3768, Virtual Router
Redundancy Protocol (VRRP).

Documentation
Configuring a Logical Interface to Be Tracked
VRRP can track whether a logical interface is up, down, or not present, and can also
dynamically change the priority of the VRRP group based on the state of the tracked
logical interface, triggering a new master router election. VRRP can also track the
operational speed of a logical interface and dynamically update the priority of the VRRP
group when the speed crosses a configured threshold.
When interface tracking is enabled, you cannot configure a priority of 255 (a priority of
255 designates the master router). For each VRRP group, you can track up to 10 logical
interfaces.
To configure a logical interface to be tracked, include the following statements:
track {
bandwidth-threshold bits-per-second priority-cost priority;
priority-cost priority;

}
priority-hold-time seconds;
}
You can include these statements at the following hierarchy level:

The interface specified is the interface to be tracked for the VRRP group. The priority hold
time is the minimum length of time that must elapse between dynamic priority changes.
A tracking event, such as an interface state change (up or down) or a change in bandwidth,
triggers one of the following responses:
• The first tracking event initiates the priority hold timer, and also initializes the pending
priority based on the current priority and the priority cost. However, the current priority
remains unchanged.
• A tracking event or a manual configuration change that occurs while the priority hold
timer is on triggers a pending priority update. However, the current priority remains
unchanged.
This ensures that Junos OS does not initiate mastership elections every time a tracked
interface flaps.
When the priority hold time expires, the current priority inherits the value from the pending
priority, and the pending priority ceases.
NOTE: If you have configured asymmetric-hold-time, VRRP does not wait for
the priority hold time to expire before initiating mastership elections if a
tracked interface fails (state changes from up to down), or if the available
bandwidth for a tracked interface decreases. For more information about
asymmetric-hold-time, see Configuring the Asymmetric Hold Time for VRRP
Routers.
The bandwidth threshold specifies a threshold for the tracked interface. When the
bandwidth of the tracked interface drops below the configured bandwidth threshold
value, the VRRP group uses the bandwidth threshold priority cost. You can track up to
five bandwidth threshold statements for each tracked interface.
The priority cost is the value to be subtracted from the configured VRRP priority when
the tracked logical interface goes down, forcing a new master router election. The value
can be from 1 through 254. The sum of the costs for all tracked logical interfaces or routes
must be less than or equal to the configured priority of the VRRP group.
If you are tracking more than one interface, the router applies the sum of the priority costs
for the tracked interfaces (at most, only one priority cost for each tracked interface) to
the VRRP group priority. However, the interface priority cost and bandwidth threshold
priority cost values for each VRRP group are not cumulative. The router uses only one
priority cost to a tracked interface as indicated in Table 46 on page 661:

Table 46: Interface State and Priority Cost Usage

Tracked Interface State Priority Cost Usage
Down priority-cost priority
Not down; media speed below one or more Priority-cost of the lowest applicable bandwidth
bandwidth thresholds threshold
You must configure an interface priority cost only if you have configured no bandwidth
thresholds. If you have not configured an interface priority cost value, and the interface
is down, the interface uses the bandwidth threshold priority cost value of the lowest
bandwidth threshold.

Documentation

page 658
Configuring a Route to Be Tracked
VRRP can track whether a route is reachable (that is, the route exists in the routing table
of the routing instance included in the configuration) and dynamically change the priority
of the VRRP group based on the reachability of the tracked route, triggering a new master
router election.
To configure a route to be tracked, include the following statements:
track {
priority-hold-time seconds;
route prefix/prefix-length routing-instance instance-name priority-cost priority;
}

You can include these statements at the following hierarchy level:

The route prefix specified is the route to be tracked for the VRRP group. The priority hold
time is the minimum length of time that must elapse between dynamic priority changes.
A route tracking event, such as adding a route to or removing a route from the routing
table, might trigger one or more of the following:
• The first tracking event initiates the priority hold timer, and also initializes the pending
priority based on the current priority and the priority cost. However, the current priority
remains unchanged.
• A tracking event or a manual configuration change that occurs while the priority hold
timer is on triggers a pending priority update. However, the current priority remains
unchanged.
When the priority hold time expires, the current priority inherits the value from the pending
priority, and the pending priority ceases. This ensures that Junos OS does not initiate
mastership elections every time a tracked route flaps.
NOTE: If you have configured asymmetric-hold-time, VRRP does not wait for
the priority hold time to expire before initiating mastership elections if a
tracked route is removed from the routing table. For more information about
asymmetric-hold-time, see Configuring the Asymmetric Hold Time for VRRP
Routers.
The routing instance is the routing instance in which the route is to be tracked. If the route
is in the default, or global, routing instance, specify the instance name as default.
NOTE: Tracking a route that belongs to a routing instance from a different

logical system is not supported.
The priority cost is the value to be subtracted from the configured VRRP priority when
the tracked route goes down, forcing a new master router election. The value can be
from 1 through 254. The sum of the costs for all tracked logical interfaces or routes must
be less than or equal to the configured priority of the VRRP group.

Documentation


page 658
Configuring the Silent Period
The silent period starts when the interface state is changed from down to up. During this
period, the Master Down Event is ignored. Configure the silent period interval to avoid
alarms caused by the delay or interruption of the incoming VRRP advertisement packets
during the interface startup phase.
To configure the silent period interval that the Master Down Event timer ignores, include
the startup-silent-period statement at the [edit protocols vrrp] hierarchy level:
[edit protocols vrrp]

startup-silent-period seconds;
NOTE: During the silent startup period, the show vrrp detail command output
shows a value of 0 for Master priority and your IP address for Master router.
These values indicate that the selection of the master router is not completed
yet, and these values can be ignored.
When you have configured startup-silent-period, the Master Down Event is ignored until
the startup-silent-period expires.
For example, configure a VRRP group, vrrp-group1, with an advertise interval of 1 second,
startup silent period of 10 seconds, and an interface interface1 with a priority less than
255.
When interface1 transitions from down to up:
• The vrrp-group1 group moves to the backup state, and starts the Master Down Event
timer (3 seconds; three times the value of the advertise interval, which is 1 second in
this case).
• If no VRRP PDU is received during the 3-second period, the startup-silent-period (10
seconds in this case) is checked, and if the startup silent period has not expired, the
Master Down Event timer is restarted. This is repeated until the startup-silent-period
expires. In this example, the Master Down Event timer runs four times (12 seconds) by
the time the 10-second startup silent period expires.
• If no VRRP PDU is received by the end of the fourth 3-second cycle, vrrp-group1 takes
over mastership.


Documentation

page 658
Tracing VRRP Operations
To trace VRRP operations, include the traceoptions statement at the [edit protocols vrrp]
hierarchy level.
By default, VRRP logs the error, data carrier detect (DCD) configuration, and routing
socket events in a file in the /var/log directory. By default, this file is named /var/log/vrrpd.
The default file size is 1 megabyte (MB), and three files are created before the first one
gets overwritten.
To change the configuration of the logging file, include the traceoptions statement at the
[edit protocols vrrp] hierarchy level:
[edit protocols vrrp]

traceoptions {
file <filename> size <size> ;
flag flag;
no-remote-trace;
}
flag flag;
You can specify the following VRRP tracing flags:
• all—Trace all VRRP operations.
• database—Trace all database changes.
• general—Trace all general events.
• interfaces—Trace all interface changes.
• normal—Trace all normal events.
• packets—Trace all packets sent and received.

• state—Trace all state transitions.
• timer—Trace all timer events.

Documentation

page 658
Example: Configuring VRRP
Configure one master (Router A) and one backup (Router B) router running VRRP. The
address configured in the virtual-address statements differs from the addresses configured
in the address statements. When you configure multiple VRRP groups on an interface,
you configure one to be the master virtual router for that group.
On Router A [edit interfaces]

ge-0/0/0 {
unit 0 {
family inet {
address 192.168.1.20/24 {
vrrp-group 27 {
priority 254;
}
}
}
}
}
On Router B [edit interfaces]

ge-4/2/0 {
unit 0 {
family inet {
address 192.168.1.24/24 {
vrrp-group 27 {

priority 200;
}
}
}
}
}
Configuring One [edit interfaces]

Router to Be the ge-0/0/0 {
Master Virtual Router unit 0 {
family inet {
for the Group
address 192.168.1.20/24 {
vrrp-group 2 {
priority 255;
advertise-interval 3;
preempt;
}
vrrp-group 10 {
priority 201;
}
vrrp-group 1 {
priority 22;
}
}
}
}
}
Configuring VRRP and The VRRP group number is the decimal equivalent of the last byte of the virtual MAC
MAC Source Address address.
Filtering
[edit interfaces]
ge-5/2/0 {
gigether-options {
source-filtering;
source-address-filter {
00:00:5e:00:01:0a; # Virtual MAC address
}
}
unit 0 {
family inet {
address 192.168.1.10/24 {
vrrp-group 10; # VRRP group number
priority 255;
preempt;
}
}
}
}


Documentation

page 658
Configuring VRRP for IPv6
Configure VRRP properties for IPv6 in one master (Router A) and one backup (Router B).
On Router A [edit interfaces]

ge-1/0/0 {
unit 0 {
family inet6 {
address fe80::5:0:0:6/64;
address fec0::5:0:0:6/64 {
vrrp-inet6-group 3; # VRRP inet6 group number
virtual-inet6-address fec0::5:0:0:7;
virtual-link-local-address fe80::5:0:0:7;
priority 200;
preempt;
}
}
}
}
[edit protocols]
router-advertisement {
prefix fec0::/64;
max-advertisement-interval 4;
}
}
On Router B [edit interfaces]

ge-1/0/0 {
unit 0 {
family inet6 {
address fe80::5:0:0:8/64;
address fec0::5:0:0:8/64 {
vrrp-inet6-group 3; # VRRP inet6 group number
virtual-inet6-address fec0::5:0:0:7;
virtual-link-local-address fe80::5:0:0:7;
priority 100;
preempt;

}
}
}
}
[edit protocols]
router-advertisement {
prefix fec0::/64;
max-advertisement-interval 4;
}
}
Related • Understanding VRRP

Documentation
• Configuring VRRP
• Configuring VRRP Route Tracking

CHAPTER 22
Configuring Multicast Listener Discovery

and Protocol-Independent Multicast
• Understanding MLD in ACX Series on page 669

• Enabling MLD on page 671
• PIM Overview on page 672
• Designated Router on page 675
• Understanding PIM Sparse Mode on page 675
• PIM Configuration Statements on page 678
• Changing the PIM Version on page 680
• Modifying the PIM Hello Interval on page 681
• PIM on Aggregated Interfaces on page 682
• Enabling PIM Sparse Mode on page 682
• Configuring BFD for PIM in ACX Series on page 683
• Configuring PIM Trace Options on page 685
• Disabling PIM on page 687
Understanding MLD in ACX Series
The Multicast Listener Discovery (MLD) Protocol manages the membership of hosts and
routers in multicast groups. IP version 6 (IPv6) multicast routers use MLD to learn, for
each of their attached physical networks, which groups have interested listeners. Each
router maintains a list of host multicast addresses that have listeners. The router provides
addresses to the multicast routing protocol, which ensures that multicast packets are
delivered to interested listeners. In this way, MLD is used as the transport for the Protocol
Independent Multicast (PIM) Protocol.
MLD is an integral part of IPv6 and must be enabled on all IPv6 routers and hosts that
need to receive IP multicast traffic. The Junos OS supports MLD versions 1 and 2. Version
2 is supported for source-specific multicast (SSM) include and exclude modes.
In include mode, the receiver specifies the source or sources it is interested in receiving
the multicast group traffic from. Exclude mode works the opposite of include mode. It

allows the receiver to specify the source or sources it is not interested in receiving the
multicast group traffic from.
For each attached network, a multicast router can be either a querier or a nonquerier. A
querier router, usually one per subnet, solicits group membership information by
transmitting MLD queries. When a host reports to the querier router that it has interested
listeners, the querier router forwards the membership information to the rendezvous
point (RP) router by means of the receiver's (host's) designated router (DR). This builds
the rendezvous-point tree (RPT) connecting the host with interested listeners to the RP
router. The RPT is the initial path used by the sender to transmit information to the
interested listeners. Nonquerier routers do not transmit MLD queries on a subnet but can
do so if the querier router fails.
NOTE: ACX Series routers do not support MLD snooping.
To configure MLD version 1, include the mld statement at the [edit protocols] hierarchy
level as shown below:
[edit protocols]
mld {
interface <interface-name> {
}
}
To configure MLD version 2, include the mld statement at the [edit protocols] hierarchy
level as shown below:
[edit protocols]
mld {
interface <interface-name> {
version 2;
}
}
NOTE: If a version is not specified, then MLD version 1 is considered by default.
Related • mld on page 1618

Documentation
• Enabling MLD on page 671
• show mld group
• show mld interface
• show mld statistics
• clear mld membership
• clear mld statistics

Chapter 22: Configuring Multicast Listener Discovery and Protocol-Independent Multicast
Enabling MLD
The Multicast Listener Discovery (MLD) Protocol manages multicast groups by

establishing, maintaining, and removing groups on a subnet. Multicast routing devices
use MLD to learn which groups have members on each of their attached physical networks.
MLD must be enabled for the router to receive IPv6 multicast packets. MLD is only needed
for IPv6 networks, because multicast is handled differently in IPv4 networks. MLD is
enabled on all IPv6 interfaces on which you configure PIM and on all IPv6 broadcast
interfaces when you configure DVMRP.
MLD specifies different behaviors for multicast listeners and for routers. When a router
is also a listener, the router responds to its own messages. If a router has more than one
interface to the same link, it needs to perform the router behavior over only one of those
interfaces. Listeners, on the other hand, must perform the listener behavior on all interfaces
connected to potential receivers of multicast traffic.
If MLD is not running on an interface—either because PIM and DVMRP are not configured
on the interface or because MLD is explicitly disabled on the interface—you can explicitly
enable MLD.
To explicitly enable MLD:
1. If PIM and DVMRP are not running on the interface, explicitly enable MLD by including
the interface name.
[edit protocols mld]

user@host# set interface fe-0/0/0.0
2. Check to see if MLD is disabled on any interfaces. In the following example, MLD is
disabled on a Gigabit Ethernet interface.

user@host# show
disable;
}
3. Enable MLD on the interface by deleting the disable statement.

delete interface ge-0/0/0.0 disable

user@host# show
5. Verify the operation of MLD by checking the output of the show mld interface command.

Related • Understanding MLD

Documentation
• Disabling MLD
• show mld interface in the CLI Explorer
• RFC 2710, Multicast Listener Discovery (MLD) for IPv6
• RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6
• RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6
PIM Overview
The predominant multicast routing protocol in use on the Internet today is Protocol
Independent Multicast, or PIM. The type of PIM used on the Internet is PIM sparse mode.
PIM sparse mode is so accepted that when the simple term “PIM” is used in an Internet
context, some form of sparse mode operation is assumed.
PIM emerged as an algorithm to overcome the limitations of dense-mode protocols such

as the Distance Vector Multicast Routing Protocol (DVMRP), which was efficient for
dense clusters of multicast receivers, but did not scale well for the larger, sparser, groups
encountered on the Internet. The Core Based Trees (CBT) Protocol was intended to
support sparse mode as well, but CBT, with its all-powerful core approach, made
placement of the core critical, and large conference-type applications (many-to-many)
resulted in bottlenecks in the core. PIM was designed to avoid the dense-mode scaling
issues of DVMRP and the potential performance issues of CBT at the same time.
Starting in Junos OS Release 15.2, only PIM version 2 is supported. In the CLI, the command
for specifying a version (1 or 2) is removed.
PIMv1 and PIMv2 can coexist on the same routing device and even on the same interface.
The main difference between PIMv1 and PIMv2 is the packet format. PIMv1 messages
use Internet Group Management Protocol (IGMP) packets, whereas PIMv2 has its own
IP protocol number (103) and packet structure. All routing devices connecting to an IP
subnet such as a LAN must use the same PIM version. Some PIM implementations can
recognize PIMv1 packets and automatically switch the routing device interface to PIMv1.
Because the difference between PIMv1 and PIMv2 involves the message format, but not
the meaning of the message or how the routing device processes the PIM message, a
routing device can easily mix PIMv1 and PIMv2 interfaces.
PIM is used for efficient routing to multicast groups that might span wide-area and
interdomain internetworks. It is called “protocol independent” because it does not depend
on a particular unicast routing protocol. Junos OS supports bidirectional mode, sparse
mode, dense mode, and sparse-dense mode.
NOTE: ACX Series routers supports only sparse mode. Dense mode on ACX
series is supported only for control multicast groups for auto-discovery of
rendezvous point (auto-RP).

PIM operates in several modes: bidirectional mode, sparse mode, dense mode, and
sparse-dense mode. In sparse-dense mode, some multicast groups are configured as
dense mode (flood-and-prune, [S,G] state) and others are configured as sparse mode
(explicit join to rendezvous point [RP], [*,G] state).
PIM drafts also establish a mode known as PIM source-specific mode, or PIM SSM. In
PIM SSM there is only one specific source for the content of a multicast group within a
given domain.
Because the PIM mode you choose determines the PIM configuration properties, you first
must decide whether PIM operates in bidirectional, sparse, dense, or sparse-dense mode
in your network. Each mode has distinct operating advantages in different network
environments.
• In sparse mode, routing devices must join and leave multicast groups explicitly.
Upstream routing devices do not forward multicast traffic to a downstream routing
device unless the downstream routing device has sent an explicit request (by means
of a join message) to the rendezvous point (RP) routing device to receive this traffic.
The RP serves as the root of the shared multicast delivery tree and is responsible for
forwarding multicast data from different sources to the receivers.
Sparse mode is well suited to the Internet, where frequent interdomain join messages
and prune messages are common.
NOTE: On all the EX series switches (except EX4300 and EX9200),

QFX5100 switches, and OCX series switches, the rate limit is set to 1pps
per SG to avoid overwhelming the rendezvous point (RP), First hop router
(FHR) with PIM-sparse mode (PIM-SM) register messages and cause CPU
hogs. This rate limit helps in improving scaling and convergence times by
avoiding duplicate packets being trapped, and tunneled to RP in software.
(Platform support depends on the Junos OS release in your installation.)
• Bidirectional PIM is similar to sparse mode, and is especially suited to applications that
must scale to support a large number of dispersed sources and receivers. In bidirectional
PIM, routing devices build shared bidirectional trees and do not switch to a source-based
tree. Bidirectional PIM scales well because it needs no source-specific (S,G) state.
Instead, it builds only group-specific (*,G) state.
• Unlike sparse mode and bidirectional mode, in which data is forwarded only to routing
devices sending an explicit PIM join request, dense mode implements a flood-and-prune
mechanism, similar to the Distance Vector Multicast Routing Protocol (DVMRP). In
dense mode, a routing device receives the multicast data on the incoming interface,
then forwards the traffic to the outgoing interface list. Flooding occurs periodically and
is used to refresh state information, such as the source IP address and multicast group
pair. If the routing device has no interested receivers for the data, and the outgoing
interface list becomes empty, the routing device sends a PIM prune message upstream.

Dense mode works best in networks where few or no prunes occur. In such instances,
dense mode is actually more efficient than sparse mode.
• Sparse-dense mode, as the name implies, allows the interface to operate on a per-group
basis in either sparse or dense mode. A group specified as “dense” is not mapped to
an RP. Instead, data packets destined for that group are forwarded by means of PIM
dense mode rules. A group specified as “sparse” is mapped to an RP, and data packets
are forwarded by means of PIM sparse-mode rules. Sparse-dense mode is useful in
networks implementing auto-RP for PIM sparse mode.
NOTE: On SRX Series devices, PIM does not support upstream and
downstream interfaces across different virtual routers in flow mode.
Basic PIM Network Components

PIM dense mode requires only a multicast source and series of multicast-enabled routing
devices running PIM dense mode to allow receivers to obtain multicast content. Dense
mode makes sure that all multicast traffic gets everywhere by periodically flooding the
network with multicast traffic, and relies on prune messages to make sure that subnets
where all receivers are uninterested in that particular multicast group stop receiving
packets.
PIM sparse mode is more complicated and requires the establishment of special routing
devices called rendezvous points (RPs) in the network core. These routing devices are
where upstream join messages from interested receivers meet downstream traffic from
the source of the multicast group content. A network can have many RPs, but PIM sparse
mode allows only one RP to be active for any multicast group.
If there is only one RP in a routing domain, the RP and adjacent links might become
congested and form a single point of failure for all multicast traffic. Thus, multiple RPs
are the rule, but the issue then becomes how other multicast routing devices find the RP
that is the source of the multicast group the receiver is trying to join. This RP-to-group
mapping is controlled by a special bootstrap router (BSR) running the PIM BSR mechanism.
There can be more than one bootstrap router as well, also for single-point-of-failure
reasons.
The bootstrap router does not have to be an RP itself, although this is a common
implementation. The bootstrap router's main function is to manage the collection of RPs
and allow interested receivers to find the source of their group's multicast traffic. PIM
bootstrap messages are sourced from the loopback address, which is always up. The
loopback address must be routable. If it is not routable, then the bootstrap router is
unable to send bootstrap messages to update the RP domain members. The show pim
bootstrap command displays only those bootstrap routers that have routable loopback
addresses.
PIM SSM can be seen as a subset of a special case of PIM sparse mode and requires no
specialized equipment other than that used for PIM sparse mode (and IGMP version 3).

Bidirectional PIM RPs, unlike RPs for PIM sparse mode, do not need to perform PIM
Register tunneling or other specific protocol action. Bidirectional PIM RPs implement no
specific functionality. RP addresses are simply a location in the network to rendezvous
toward. In fact, for bidirectional PIM, RP addresses need not be loopback interface
addresses or even be addresses configured on any routing device, as long as they are
covered by a subnet that is connected to a bidirectional PIM-capable routing device and
advertised to the network.
15.2 Starting in Junos OS Release 15.2, only PIM version 2 is supported. In the
CLI, the command for specifying a version (1 or 2) is removed.
Related • Supported IP Multicast Protocol Standards

Documentation
Designated Router
In a PIM sparse mode (PIM-SM) domain, there are two types of designated routers to
consider:
• The receiver DR sends PIM join and PIM prune messages from the receiver network
toward the RP.
• The source DR sends PIM register messages from the source network to the RP.
Neighboring PIM routers multicast periodic PIM hello messages to each other every
30 seconds (the default). The PIM hello message usually includes a holdtime value for
the neighbor to use, but this is not a requirement. If the PIM hello message does not
include a holdtime value, a default timeout value (in Junos OS, 105 seconds) is used. On
receipt of a PIM hello message, a router stores the IP address and priority for that neighbor.
If the DR priorities match, the router with the highest IP address is selected as the DR.
If a DR fails, a new one is selected using the same process of comparing IP addresses.
NOTE: In PIM dense mode (PIM-DM), a DR is elected by the same process

that PIM-SM uses. However, the only time that a DR has any effect in PIM-DM
is when IGMPv1 is used on the interface. (IGMPv2 is the default.) In this case,
the DR also functions as the IGMP Query Router because IGMPv1 does not
have a Query Router election mechanism.
Understanding PIM Sparse Mode
A Protocol Independent Multicast (PIM) sparse-mode domain uses reverse-path

forwarding (RPF) to create a path from a data source to the receiver requesting the data.
When a receiver issues an explicit join request, an RPF check is triggered. A (*,G) PIM join
message is sent toward the RP from the receiver's designated router (DR). (By definition,

this message is actually called a join/prune message, but for clarity in this description, it
is called either join or prune, depending on its context.) The join message is multicast
hop by hop upstream to the ALL-PIM-ROUTERS group (224.0.0.13) by means of each
router’s RPF interface until it reaches the RP. The RP router receives the (*,G) PIM join
message and adds the interface on which it was received to the outgoing interface list
(OIL) of the rendezvous-point tree (RPT) forwarding state entry. This builds the RPT
connecting the receiver with the RP. The RPT remains in effect, even if no active sources
generate traffic.
NOTE: State—the (*,G) or (S,G) entries—is the information used for

forwarding unicast or multicast packets. S is the source IP address, G is the
multicast group address, and * represents any source sending to group G.
Routers keep track of the multicast forwarding state for the incoming and
outgoing interfaces for each group.
When a source becomes active, the source DR encapsulates multicast data packets into
a PIM register message and sends them by means of unicast to the RP router.
If the RP router has interested receivers in the PIM sparse-mode domain, it sends a PIM
join message toward the source to build a shortest-path tree (SPT) back to the source.
The source sends multicast packets out on the LAN, and the source DR encapsulates
the packets in a PIM register message and forwards the message toward the RP router
by means of unicast. The RP router receives PIM register messages back from the source,
and thus adds a new source to the distribution tree, keeping track of sources in a PIM
table. Once an RP router receives packets natively (with S,G), it sends a register stop
message to stop receiving the register messages by means of unicast.
In actual application, many receivers with multiple SPTs are involved in a multicast traffic
flow. To illustrate the process, we track the multicast traffic from the RP router to one
receiver. In such a case, the RP router begins sending multicast packets down the RPT
toward the receiver’s DR for delivery to the interested receivers. When the receiver’s DR
receives the first packet from the RPT, the DR sends a PIM join message toward the
source DR to start building an SPT back to the source. When the source DR receives the
PIM join message from the receiver’s DR, it starts sending traffic down all SPTs. When
the first multicast packet is received by the receiver’s DR, the receiver’s DR sends a PIM
prune message to the RP router to stop duplicate packets from being sent through the
RPT. In turn, the RP router stops sending multicast packets to the receiver’s DR, and
sends a PIM prune message for this source over the RPT toward the source DR to halt
multicast packet delivery to the RP router from that particular source.
If the RP router receives a PIM register message from an active source but has no
interested receivers in the PIM sparse-mode domain, it still adds the active source into
the PIM table. However, after adding the active source into the PIM table, the RP router
sends a register stop message. The RP router discovers the active source’s existence and
no longer needs to receive advertisement of the source (which utilizes resources).

NOTE: If the number of PIM join messages exceeds the configured MTU, the
messages are fragmented in IPv6 PIM sparse mode. To avoid the
fragmentation of PIM join messages, the multicast traffic receives the
interface MTU instead of the path MTU.
The major characteristics of PIM sparse mode are as follows:
• Routers with downstream receivers join a PIM sparse-mode tree through an explicit
join message.
• PIM sparse-mode RPs are the routers where receivers meet sources.
• Senders announce their existence to one or more RPs, and receivers query RPs to find
multicast sessions.
• Once receivers get content from sources through the RP, the last-hop router (the router
closest to the receiver) can optionally remove the RP from the shared distribution tree
(*,G) if the new source-based tree (S,G) is shorter. Receivers can then get content
directly from the source.
The transitional aspect of PIM sparse mode from shared to source-based tree is one
of the major features of PIM, because it prevents overloading the RP or surrounding
core links.
There are related issues regarding source, RPs, and receivers when sparse mode multicast
is used:
• Sources must be able to send to all RPs.
• RPs must all know one another.
• Receivers must send explicit join messages to a known RP.
• Receivers initially need to know only one RP (they later learn about others).
• Receivers can explicitly prune themselves from a tree.
• Receivers that never transition to a source-based tree are effectively running Core
Based Trees (CBT).
PIM sparse mode has standard features for all of these issues.
Rendezvous Point
The RP router serves as the information exchange point for the other routers. All routers
in a PIM domain must provide mapping to an RP router. It is the only router that needs
to know the active sources for a domain—the other routers just need to know how to
reach the RP. In this way, the RP matches receivers with sources.
The RP router is downstream from the source and forms one end of the shortest-path
tree. As shown in Figure 35 on page 678, the RP router is upstream from the receiver and
thus forms one end of the rendezvous-point tree.

Figure 35: Rendezvous Point As Part of the RPT and SPT
The benefit of using the RP as the information exchange point is that it reduces the
amount of state in non-RP routers. No network flooding is required to provide non-RP
routers information about active sources.
RP Mapping Options
RPs can be learned by one of the following mechanisms:
• Static configuration
• Anycast RP
• Auto-RP
• Bootstrap router
We recommend a static RP mapping with anycast RP and a bootstrap router (BSR) with
auto-RP configuration, because static mapping provides all the benefits of a bootstrap
router and auto-RP without the complexity of the full BSR and auto-RP mechanisms.
Related • Understanding Static RP

Documentation
• Understanding RP Mapping with Anycast RP
• Understanding the PIM Bootstrap Router
• Understanding PIM Auto-RP
PIM Configuration Statements
To configure Protocol Independent Multicast (PIM), include the pim statement:
pim {
disable;
default-vpn-source {
interface-name interface-name;
}
assert-timeout seconds;
dense-groups {
addresses;
}
dr-election-on-p2p;
export;
graceful-restart {
disable;
no-bidirectional-mode;
restart-duration seconds;

}
idle-standby-path-switchover-delay seconds;
import [ policy-names ];
family (inet | inet6) {
bfd-liveness-detection {
authentication {
algorithm algorithm-name;
key-chain key-chain-name;
loose-check;
}
detection-time {
threshold milliseconds;
}
minimum-interval milliseconds;
minimum-receive-interval milliseconds;
multiplier number;
no-adaptation;
transmit-interval {
minimum-interval milliseconds;
threshold milliseconds;
}
version (0 | 1 | automatic);
}
disable;
}
import;
hello-interval seconds;
mode ( sparse | sparse-dense);
neighbor-policy [ policy-names ];
override-interval milliseconds;
priority number;
propagation-delay milliseconds;
reset-tracking-bit;
version version;
}
join-prune-timeout;
nonstop-routing {
disable;
}
override-interval milliseconds;
propagation-delay milliseconds;
reset-tracking-bit;
rp {
auto-rp {
(discovery | mapping);
(mapping-agent-election | no-mapping-agent-election);
}
bootstrap {
export [ policy-names ];
import [ policy-names ];
priority number;
}
}
bootstrap-export [ policy-names ];

bootstrap-import [ policy-names ];
bootstrap-priority number;
dr-register-policy [ policy-names ];
static {
address address {
override;
version version;
group-ranges {
destination-ip-prefix</prefix-length>;
}
spt-threshold {
infinity [ policy-names ];
}
traceoptions {
}
}
}
}
}
By default, PIM is disabled.
NOTE: You cannot configure PIM within a nonforwarding instance. If you try
to do so, the router displays a commit check error and does not complete the
configuration commit process.
NOTE: You can configure PIM on Integrated Routing and Bridging (IRB)
interfaces.
NOTE: ACX Series routers do not support source DR functionality
Changing the PIM Version
Starting in Junos OS Release 15.2, it is no longer necessary to configure the PIM version.
Support for PIM version 1 has been removed and the remaining, default, version is PIM 2.
PIM version 2 is the default for both rendezvous point (RP) mode (at the [edit protocols
pim rp static address address] hierarchy level) and for interface mode (at the [edit protocols
pim interface interface-name] hierarchy level).

15.2 Starting in Junos OS Release 15.2, it is no longer necessary to configure

the PIM version.
Modifying the PIM Hello Interval
Routing devices send hello messages at a fixed interval on all PIM-enabled interfaces.
By using hello messages, routing devices advertise their existence as PIM routing devices
on the subnet. With all PIM-enabled routing devices advertised, a single designated router
for the subnet is established.
When a routing device is configured for PIM, it sends a hello message at a 30-second
default interval. The interval range is from 0 through 255. When the interval counts down
to 0, the routing device sends another hello message, and the timer is reset. A routing
device that receives no response from a neighbor in 3.5 times the interval value drops
the neighbor. In the case of a 30-second interval, the amount of time a routing device
waits for a response is 105 seconds.
If a PIM hello message contains the hold-time option, the neighbor timeout is set to the
hold-time sent in the message. If a PIM hello message does not contain the hold-time
option, the neighbor timeout is set to the default hello hold time.
To modify how often the routing device sends hello messages out of an interface:
1. This example shows the configuration for the routing instance. Configure the interface
globally or in the routing instance.
[edit routing-instances PIM.master protocols pim interface fe-3/0/2.0]

user@host# set hello-interval 255
2. Verify the configuration by checking the Hello Option Holdtime field in the output of
the show pim neighbors detail command.
user@host> show pim neighbors detail

Instance: PIM.master
Interface: fe-3/0/2.0
Address: 192.168.195.37, IPv4, PIM v2, Mode: Sparse
Hello Option Holdtime: 255 seconds
Hello Option DR Priority: 1
Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
Join Suppression supported
Rx Join: Group Source Timeout
225.1.1.1 192.168.195.78 0
225.1.1.1 0
Interface: lo0.0

Interface: pd-6/0/0.32768
Related • show pim neighbors

Documentation
PIM on Aggregated Interfaces
You can configure several Protocol Independent Multicast (PIM) features on an interface
regardless of its PIM mode (bidirectional, sparse, dense, or sparse-dense mode).
NOTE: ACX Series routers supports only sparse mode. Dense mode on ACX
series is supported only for control multicast groups for auto-discovery of
rendezvous point (auto-RP).
If you configure PIM on an aggregated (ae- or as-) interface, each of the interfaces in the
aggregate is included in the multicast output interface list and carries the single stream
of replicated packets in a load-sharing fashion. The multicast aggregate interface is
“expanded” into its constituent interfaces in the next-hop database.
Related • Junos OS Network Interfaces Library for Routing Devices

Documentation
Enabling PIM Sparse Mode
In PIM sparse mode (PIM-SM), the assumption is that very few of the possible receivers
want packets from a source, so the network establishes and sends packets only on
branches that have at least one leaf indicating (by message) a desire for the traffic.
WANs are appropriate networks for sparse-mode operation.
Starting in Junos OS Release 16.1, PIM is disabled by default. When you enable PIM, it
operates in sparse mode by default. You do not need to configure Internet Group
Management Protocol (IGMP) version 2 for a sparse mode configuration. After you enable
PIM, by default, IGMP version 2 is also enabled.
Junos OS uses PIM version 2 for both rendezvous point (RP) mode (at the [edit protocols
pim rp static address address] hierarchy level) and interface mode (at the [edit protocols
pim interface interface-name] hierarchy level).
All systems on a subnet must run the same version of PIM.

You can configure PIM sparse mode globally or for a routing instance. This example
shows how to configure PIM sparse mode globally on all interfaces. It also shows how
to configure a static RP router and how to configure the non-RP routers.
To configure the router properties for PIM sparse mode:
1. Configure the static RP router.
[edit protocols pim]

user@host# set rp local family inet address 192.168.3.253
2. Configure the RP router interfaces. When configuring all interfaces, exclude the fxp0.0
management interface by including the disable statement for that interface.

user@host# set interface all mode sparse
user@host# set interface fxp0.0 disable
3. Configure the non-RP routers. Include the following configuration on all of the non-RP
routers.

user@host# set rp static address 192.168.3.253
user@host# set interface all mode sparse
user@host# set interface fxp0.0 disable
4. Monitor the operation of PIM sparse mode.
• show pim join
• show pim neighbors
• show pim rps
16.1 Starting in Junos OS Release 16.1, PIM is disabled by default. When you
enable PIM, it operates in sparse mode by default.
Related • Understanding PIM Sparse Mode on page 675

Documentation
Configuring BFD for PIM in ACX Series
The Bidirectional Forwarding Detection (BFD) Protocol is a simple hello mechanism that
detects failures in a network. BFD works with a wide variety of network environments
and topologies. A pair of routing devices exchanges BFD packets. Hello packets are sent
at a specified, regular interval. A neighbor failure is detected when the routing device
stops receiving a reply after a specified interval. The BFD failure detection timers have

shorter time limits than the Protocol Independent Multicast (PIM) hello hold time, so
they provide faster detection.
The BFD failure detection timers are adaptive and can be adjusted to be faster or slower.
The lower the BFD failure detection timer value, the faster the failure detection and vice
versa. For example, the timers can adapt to a higher value if the adjacency fails (that is,
the timer detects failures more slowly). Or a neighbor can negotiate a higher value for a
timer than the configured value. The timers adapt to a higher value when a BFD session
flap occurs more than three times in a span of 15 seconds. A back-off algorithm increases
the receive (Rx) interval by two if the local BFD instance is the reason for the session
flap. The transmission (Tx) interval is increased by two if the remote BFD instance is the
reason for the session flap. You can use the clear bfd adaptation command to return BFD
interval timers to their configured values. The clear bfd adaptation command is hitless,
meaning that the command does not affect traffic flow on the routing device.
You must specify the minimum transmit and minimum receive intervals to enable BFD
on PIM.
To enable failure detection:
1. Configure the interface globally.
This example shows the global configuration.

user@host# edit interface fe-1/0/0.0 family inet bfd-liveness-detection
2. Configure the minimum transmit interval.
This is the minimum interval after which the routing device transmits hello packets
to a neighbor with which it has established a BFD session. Specifying an interval smaller
than 300 ms can cause undesired BFD flapping.
[edit protocols pim interface fe-1/0/0.0 bfd-liveness-detection]

user@host# set transmit-interval 350
3. Configure the minimum interval after which the routing device expects to receive a
reply from a neighbor with which it has established a BFD session.
Specifying an interval smaller than 300 ms can cause undesired BFD flapping.
[edit protocols pim interface fe-1/0/0.0 family inet bfd-liveness-detection]

user@host# set minimum-receive-interval 350
4. (Optional) Configure other BFD settings.
As an alternative to setting the receive and transmit intervals separately, configure

one interval for both.

user@host# set minimum-interval 350

5. Configure the threshold for the adaptation of the BFD session detection time.
When the detection time adapts to a value equal to or greater than the threshold, a
single trap and a single system log message are sent.

user@host# set detection-time threshold 800
6. Configure the number of hello packets not received by a neighbor that causes the
originating interface to be declared down.

user@host# set multiplier 50
7. Configure the BFD version.

user@host# set version 1
8. Specify that BFD sessions should not adapt to changing network conditions.
We recommend that you not disable BFD adaptation unless it is preferable not to
have BFD adaptation enabled in your network.

user@host# set no-adaptation
9. Verify the configuration by checking the output of the show bfd session command.
Related • show bfd session in the CLI Explorer

Documentation
Configuring PIM Trace Options
Flag Description
assert Trace assert messages, which are used to resolve which

of the parallel routers connected to a multiaccess LAN is
responsible for forwarding packets to the LAN.
autorp Trace bootstrap, RP, and auto-RP messages.
bidirectional-df-election Trace bidirectional PIM designated-forwarder (DF)

election events.

Flag Description
bootstrap Trace bootstrap messages, which are sent periodically

by the PIM domain's bootstrap router and are forwarded,
hop by hop, to all routers in that domain.
general Trace general events.
graft Trace graft and graft acknowledgment messages.
hello Trace hello packets, which are sent so that neighboring

routers can discover one another.
join Trace join messages, which are sent to join a branch onto
the multicast distribution tree.
mdt Trace messages related to multicast data tunnels.
nsr-synchronization Trace nonstop routing synchronization events
packets Trace all PIM packets.
policy Trace poison-route-reverse packets.
prune Trace prune messages, which are sent to prune a branch

off the multicast distribution tree.
register Trace register and register-stop messages. Register

messages are sent to the RP when a multicast source first
starts sending to a group.
rp Trace candidate RP advertisements.
task Trace task processing.
In the following example, tracing is enabled for all routing protocol packets. Then tracing
is narrowed to focus only on PIM packets of a particular type.
To configure tracing operations for PIM:
1. (Optional) Configure tracing at the [routing-options hierarchy level to trace all protocol
packets.
[edit routing-options traceoptions]

user@host# set file all-packets-trace

2. Configure the filename for the PIM trace file.
[edit protocols pim traceoptions]

user@host# set file pim-trace



6. Configure tracing flags.

Suppose you are troubleshooting issues with PIM version 1 control packets that are
received on an interface configured for PIM version 2. The following example shows
how to trace messages associated with this problem.

user@host# set flag packets | match “Rx V1 Require V2”

user@host> file show /var/log/pim-trace
Related • PIM Overview on page 672

Documentation
• Tracing and Logging Junos OS Operations
Disabling PIM
By default, when you enable the PIM protocol it applies to the specified interface only.
To enable PIM for all interfaces, include the all parameter (for example, set protocol pim
interface all). You can disable PIM at the protocol, interface, or family hierarchy levels.
The hierarchy in which you configure PIM is critical. In general, the most specific
configuration takes precedence. However, if PIM is disabled at the protocol level, then
any disable statements with respect to an interface or family are ignored.

For example, the order of precedence for disabling PIM on a particular interface family
is:
1. If PIM is disabled at the [edit protocols pim interface interface-name family] hierarchy
level, then PIM is disabled for that interface family.
2. If PIM is not configured at the [edit protocols pim interface interface-name family]
hierarchy level, but is disabled at the [edit protocols pim interface interface-name]
hierarchy level, then PIM is disabled for all families on the specified interface.
3. If PIM is not configured at either the [edit protocols pim interface interface-name family]
hierarchy level or the [edit protocols pim interface interface-name] hierarchy level, but
is disabled at the [edit protocols pim] hierarchy level, then the PIM protocol is disabled
globally for all interfaces and all families.
The following sections describe how to disable PIM at the various hierarchy levels.
• Disabling the PIM Protocol on page 688

• Disabling PIM on an Interface on page 689
• Disabling PIM for a Family on page 689
• Disabling PIM for a Rendezvous Point on page 690
Disabling the PIM Protocol

You can explicitly disable the PIM protocol. Disabling the PIM protocol disables the
protocol for all interfaces and all families. This is accomplished at the [edit protocols
pim] hierarchy level:
[edit protocols]
pim {
disable;
}
To disable the PIM protocol:
1. Include the disable statement.
user@host# set protocols pim disable
2. (Optional) Verify your configuration settings before committing them by using the
show protocols pim command.
user@host# run show protocols pim

Disabling PIM on an Interface

You can disable the PIM protocol on a per-interface basis. This is accomplished at the
[edit protocols pim interface interface-name] hierarchy level:
[edit protocols]
pim {
disable;
}
}
To disable PIM on an interface:
user@host# set protocols pim interface fe-0/1/0 disable
Disabling PIM for a Family

You can disable the PIM protocol on a per-family basis. This is accomplished at the [edit
protocols pim family] hierarchy level:
[edit protocols]
pim {
family inet {
disable;
}
family inet6 {
disable;
}
}
To disable PIM for a family:
user@host# set protocols pim family inet disable

user@host# set protocols pim family inet6 disable

Disabling PIM for a Rendezvous Point

You can disable the PIM protocol for a rendezvous point (RP) on a per-family basis. This
is accomplished at the [edit protocols pim rp local family] hierarchy level:
[edit protocols]
pim {
rp {
local {
family inet {
disable;
}
family inet6 {
disable;
}
}
}
}
To disable PIM for an RP family:
1. Use the disable statement.
user@host# set protocols pim rp local family inet disable

user@host# set protocols pim rp local family inet6 disable

CHAPTER 23
Configuring Path Computation Element

Protocol (PCEP)
• PCEP Overview on page 691

• Configuring PCEP on page 707
PCEP Overview
• PCEP Overview on page 691

• Support of the Path Computation Element Protocol for RSVP-TE Overview on page 692
PCEP Overview
A Path Computation Element (PCE) is an entity (component, application, or network
node) that is capable of computing a network path or route based on a network graph
and applying computational constraints. A Path Computation Client (PCC) is any client
application requesting a path computation to be performed by a PCE. The Path
Computation Element Protocol (PCEP) enables communications between a PCC and
a PCE, or between two PCEs (defined in RFC 5440).
PCEP is a TCP-based protocol defined by the IETF PCE Working Group, and defines a
set of messages and objects used to manage PCEP sessions and to request and send
paths for multidomain traffic engineered LSPs (TE LSPs). It provides a mechanism for
a PCE to perform path computation for a PCC’s external LSPs. The PCEP interactions
include LSP status reports sent by the PCC to the PCE, and PCE updates for the external
LSPs.
Figure 36 on page 692 illustrates the role of PCEP in the client-side implementation of a
stateful PCE architecture in an MPLS RSVP-TE enabled network.

Figure 36: PCEP Session
PCE
PCEP
PCEP
RSVP-TE
PCEP Network
g040939
PCC
A TCP-based PCEP session connects a PCC to an external PCE. The PCC initiates the
PCEP session and stays connected to the PCE for the duration of the PCEP session.
During the PCEP session, the PCC requests LSP parameters from the stateful PCE. On
receiving one or more LSP parameters from the PCE, the PCC re-signals the TE LSP.
When the PCEP session is terminated, the underlying TCP connection is closed
immediately, and the PCC attempts to re-establish the PCEP session.
Thus, the PCEP functions include:
• LSP tunnel state synchronization between a PCC and a stateful PCE—When an active
stateful PCE connection is detected, a PCC tries to delegate all LSPs to this PCE in a
procedure called LSP state synchronization. PCEP enables synchronization of the PCC
LSP state to the PCE.
• Delegation of control over LSP tunnels to a stateful PCE—An active stateful PCE
controls one or more LSP attributes for computing paths, such as bandwidth, path
(ERO), and priority (setup and hold). PCEP enables such delegation of LSPs for path
computation.
• Stateful PCE control of timing and sequence of path computations within and across
PCEP sessions–An active stateful PCE modifies one or more LSP attributes, such as
bandwidth, path (ERO), and priority (setup and hold). PCEP communicates these new
LSP attributes from the PCE to the PCC, after which the PCC re-signals the LSP in the
specified path.
Related • Support of the Path Computation Element Protocol for RSVP-TE Overview on page 692
Documentation
Support of the Path Computation Element Protocol for RSVP-TE Overview

• Understanding MPLS RSVP-TE on page 693

• Current MPLS RSVP-TE Limitations on page 694
• Use of an External Path Computing Entity on page 695
• Components of External Path Computing on page 696

Chapter 23: Configuring Path Computation Element Protocol (PCEP)
• Interaction Between a PCE and a PCC Using PCEP on page 698

• LSP Behavior with External Computing on page 701
• Configuration Statements Supported for External Computing on page 702
• PCE-Controlled LSP Protection on page 703
• PCE-Controlled LSP ERO on page 703
• PCE Controlled Point-to-Multipoint RSVP-TE LSPs on page 704
• Auto-Bandwidth and PCE-Controlled LSP on page 705
• TCP-MD5 Authentication for PCEP Sessions on page 705
• Impact of Client-Side PCE Implementation on Network Performance on page 706
Understanding MPLS RSVP-TE
Traffic engineering (TE) deals with performance optimization of operational networks,

mainly mapping traffic flows onto an existing physical topology. Traffic engineering
provides the ability to move traffic flow away from the shortest path selected by the
interior gateway protocol (IGP) and onto a potentially less congested physical path
across a network.
For traffic engineering in large, dense networks, MPLS capabilities can be implemented
because they potentially provide most of the functionality available from an overlay
model, in an integrated manner, and at a lower cost than the currently competing
alternatives. The primary reason for implementing MPLS traffic engineering is to control
paths along which traffic flows through a network. The main advantage of implementing
MPLS traffic engineering is that it provides a combination of the traffic engineering
capabilities of ATM, along with the class-of-service (CoS) differentiation of IP.
In an MPLS network, data plane information is forwarded using label switching. A packet
arriving on a provider edge (PE) router from the customer edge (CE) router has labels
applied to it, and it is then forwarded to the egress PE router. The labels are removed at
the egress router and it is then forwarded out to the appropriate destination as an IP
packet. The label-switching routers (LSRs) in the MPLS domain use label distribution
protocols to communicate the meaning of labels used to forward traffic between and
through the LSRs. RSVP-TE is one such label distribution protocol that enables an LSR
peer to learn about the label mappings of other peers.
When both MPLS and RSVP are enabled on a router, MPLS becomes a client of RSVP.
The primary purpose of the Junos OS RSVP software is to support dynamic signaling
within label-switched paths (LSPs). RSVP reserves resources, such as for IP unicast and
multicast flows, and requests quality-of-service (QoS) parameters for applications. The
protocol is extended in MPLS traffic engineering to enable RSVP to set up LSPs that can
be used for traffic engineering in MPLS networks.
When MPLS and RSVP are combined, labels are associated with RSVP flows. Once an
LSP is established, the traffic through the path is defined by the label applied at the
ingress node of the LSP. The mapping of label to traffic is accomplished using different
criteria. The set of packets that are assigned the same label value by a specific node
belong to the same forwarding equivalence class (FEC), and effectively define the RSVP
flow. When traffic is mapped onto an LSP in this way, the LSP is called an LSP tunnel.

LSP tunnels are a way to establish unidirectional label-switched paths. RSVP-TE builds
on the RSVP core protocol by defining new objects and modifying existing objects used
in the PATH and RESV objects for LSP establishment. The new objects—LABEL-REQUEST
object (LRO), RECORD-ROUTE object (RRO), LABEL object, and EXPLICIT-ROUTE object
(ERO)—are optional with respect to the RSVP protocol, except for the LRO and LABEL
objects, which are both mandatory for establishing LSP tunnels.
In general, RSVP-TE establishes a label-switched path that ensures frame delivery from
ingress to egress router. However, with the new traffic engineering capabilities, the
following functions are supported in an MPLS domain:
• Possibility to establish a label-switched path using either a full or partial explicit route
(RFC 3209).
• Constraint-based LSP establishment over links that fulfill requirements, such as

bandwidth and link properties.
• Endpoint control, which is associated with establishing and managing LSP tunnels at
the ingress and egress routers.
• Link management, which manages link resources to do resource-aware routing of

traffic engineering LSPs and to program MPLS labels.
• MPLS fast reroute (FRR), which manages the LSPs that need protection and assigns
backup tunnel information to these LSPs.
Current MPLS RSVP-TE Limitations
Although the RSVP extensions for traffic engineering enable better network utilization
and meet requirements of classes of traffic, today’s MPLS RSVP-TE protocol suite has
several issues inherent to its distributed nature. This causes a number of issues during
contention for bisection capacity, especially within an LSP priority class where a subset
of LSPs share common setup and hold priority values. The limitations of RSVP-TE include:
• Lack of visibility of individual per-LSP, per-device bandwidth demands—The ingress

routers in an MPLS RSVP-TE network establish LSPs without having a global view of
the bandwidth demand on the network. Information about network resource utilization
is only available as total reserved capacity by traffic class on a per interface basis.
Individual LSP state is available locally on each label edge router (LER) for its own
LSPs only. As a result, a number of issues related to demand pattern arise, particularly
within a common setup and hold priority.
• Asynchronous and independent nature of RSVP signaling—In RSVP-TE, the constraints

for path establishment are controlled by an administrator. As such, bandwidth reserved
for an LSP tunnel is set by the administrator and does not automatically imply any
limit on the traffic sent over the tunnel. Therefore, bandwidth available on a traffic
engineering link is the bandwidth configured for the link, excluding the sum of all
reservations made on the link. Thus, the unsignaled demands on an LSP tunnel lead
to service degradation of the LSP requiring excess bandwidth, as well as the other
LSPs that comply with the bandwidth requirements of the traffic engineering link.
• LSPs established based on dynamic or explicit path options in the order of

preference—The ingress routers in an MPLS RSVP-TE network establish LSPs for

demands based on the order of arrival. Because the ingress routers do not have a global
view of the bandwidth demand on the network, using the order of preference to
establish LSPs can cause traffic to be dropped or LSPs not being established at all
when there is an excess of bandwidth demand.
As an example, Figure 37 on page 695 is configured with MPLS RSVP-TE, in which A and
G are the label edge routers (LERs). These ingress routers establish LSPs independently
based on the order of demands and have no knowledge or control over each other’s LSPs.
Routers B, C, and D are intermediate or transit routers that connect to the egress routers
E and F.
Figure 37: Example MPLS Traffic Engineering
The ingress routers establish LSPs based on the order in which the demands arrive. If
Router G receives two demands of capacity 5 each for G-F, then G signals two LSPs –
LSP1 and LSP2 – through G-B-D-F. In the same way, when Router A receives the third
demand of capacity 10 for A-E, then it signals an LSP, LSP3, through A-B-C-E. However,
if the demand on the A-E LSP increases from 10 to 15, Router A cannot signal LSP3 using
the same (A-B-C-E) path, because the B-C link has a lower capacity.
Router A should have signaled the increased demand on LSP3 using the A-B-D-C-E path.
Since LSP1 and LSP2 have utilized the B-D link based on the order of demands received,
LSP3 is not signaled.
Thus, although adequate max-flow bandwidth is available for all the LSPs, LSP3 is subject
to potentially prolonged service degradation. This is due to Router A’s lack of global
demand visibility and the lack of systemic coordination in demand placement by the
ingress routers A and G.
Use of an External Path Computing Entity
As a solution to the current limitations found in the MPLS RSVP-TE path computation,
an external path computing entity with a global view of per-LSP, per-device demand in
the network independent of available capacity is required.

Currently, only online and real-time constraint-based routing path computation is provided
in an MPLS RSVP-TE network. Each router performs constraint-based routing calculations
independent of the other routers in the network. These calculations are based on currently
available topology information—information that is usually recent, but not completely
accurate. LSP placements are locally optimized, based on current network status. The
MPLS RSVP-TE tunnels are set up using the CLI. An operator configures the TE LSP,
which is then signaled by the ingress router.
In addition to the existing traffic engineering capabilities, the MPLS RSVP-TE functionality
is extended to include an external path computing entity, called the Path Computation
Element (PCE). The PCE computes the path for the TE LSPs of ingress routers that have
been configured for external control. The ingress router that connects to a PCE is called
a Path Computation Client (PCC). The PCC is configured with the Path Computation
Client Protocol (PCEP) to facilitate external path computing by a PCE.
For more information, see “Components of External Path Computing” on page 696.
To enable external path computing for a PCC’s TE LSPs, include the lsp-external-controller
pccd statement at the [edit mpls] and [edit mpls lsp lsp-name] hierarchy levels.
Components of External Path Computing
The components that make up an external path computing system are:
• Path Computation Element on page 696

• Path Computation Client on page 697
• Path Computation Element Protocol on page 698
Path Computation Element
A Path Computation Element (PCE) can be any entity (component, application, or

network node) that is capable of computing a network path or route based on a network
graph and applying computational constraints. However, a PCE can compute the path
for only those TE LSPs of a PCC that have been configured for external control.
A PCE can either be stateful or stateless.
• Stateful PCE—A stateful PCE maintains strict synchronization between the PCE and
network states (in terms of topology and resource information), along with the set of
computed paths and reserved resources in use in the network. In other words, a stateful
PCE utilizes information from the traffic engineering database as well as information
about existing paths (for example, TE LSPs) in the network when processing new
requests from the PCC.
A stateful PCE is of two types:
• Passive stateful PCE—Maintains synchronization with the PCC and learns the PCC
LSP states to better optimize path calculations, but does not have control over them.
• Active stateful PCE—Actively modifies the PCC LSPs, in addition to learning about
the PCC LSP states.

NOTE: In a redundant configuration with main and backup active stateful

PCEs, the backup active stateful PCE cannot modify the attributes of
delegated LSPs until it becomes the main PCE at the time of a failover.
There is no preempting of PCEs in the case of a switchover. The main
PCE is backed by a backup PCE, and when the main PCE goes down, the
backup PCE assumes the role of the main PCE and remains the main
PCE even after the PCE that was previously the main PCE is operational
again.
A stateful PCE provides the following functions:
• Offers offline LSP path computation.
• Triggers LSP re-route when there is a need to re-optimize the network.
• Changes LSP bandwidth when there is an increase in bandwidth demand from an

application.
• Modifies other LSP attributes on the router, such as ERO, setup priority, and hold
priority.
A PCE has a global view of the bandwidth demand in the network and maintains a
traffic-engineered database to perform path computations. It performs statistics
collection from all the routers in the MPLS domain using SNMP and NETCONF. This
provides a mechanism for offline control of the PCC’s TE LSPs. Although an offline
LSP path computation system can be embedded in a network controller, the PCE acts
like a full-fledged network controller that provides control over the PCC’s TE LSPs, in
addition to computing paths.
Although a stateful PCE allows for optimal path computation and increased path
computation success, it requires reliable state synchronization mechanisms, with
potentially significant control plane overhead and the maintenance of a large amount
of data in terms of states, as in the case of a full mesh of TE LSPs.
• Stateless PCE—A stateless PCE does not remember any computed path, and each
set of requests is processed independently of each other (RFC 5440).
Path Computation Client
A Path Computation Client (PCC) is any client application requesting a path computation
to be performed by a PCE.
A PCC can connect to a maximum of 10 PCEs at one time. The PCC to PCE connection
can be a configured static route or a TCP connection that establishes reachability. The
PCC assigns each connected PCE a priority number. It sends a message to all the
connected PCEs with information about its current LSPs, in a process called LSP state
synchronization. For the TE LSPs that have external control enabled, the PCC delegates
those LSPs to the main PCE. The PCC elects, as the main PCE, a PCE with the lowest
priority number, or the PCE that it connects to first in the absence of a priority number.

The PCC re-signals an LSP based on the computed path it receives from a PCE. When
the PCEP session with the main PCE is terminated, the PCC elects a new main PCE, and
all delegated LSPs to the previously main PCE are delegated to the newly available main
PCE.
Path Computation Element Protocol
The Path Computation Element Protocol (PCEP) is used for communication between
PCC and PCE (as well as between two PCEs) (RFC 5440). PCEP is a TCP-based protocol
defined by the IETF PCE Working Group, and defines a set of messages and objects used
to manage PCEP sessions and to request and send paths for multidomain TE LSPs. The
PCEP interactions include PCC messages, as well as notifications of specific states
related to the use of a PCE in the context of MPLS RSVP-TE. When PCEP is used for
PCE-to-PCE communication, the requesting PCE assumes the role of a PCC.
Thus, the PCEP functions include:
• LSP tunnel state synchronization between PCC and a stateful PCE.
• Delegation of control over LSP tunnels to a stateful PCE.
Interaction Between a PCE and a PCC Using PCEP
Figure 38 on page 698 illustrates the relationship between a PCE, PCC, and the role of
PCEP in the context of MPLS RSVP-TE.
Figure 38: PCC and RSVP-TE
The PCE to PCC communication is enabled by the TCP-based PCEP. The PCC initiates
the PCEP session and stays connected to a PCE for the duration of the PCEP session.

NOTE: Starting with Junos OS Release 16.1, you can secure a PCEP session
using TCP-MD5 authentication as per RFC 5440. To enable the MD5 security
mechanism for a PCEP session, it is recommended that you define and bind
the MD5 authentication key at the [edit protocols pcep pce pce-id] hierarchy
level for a PCEP session. You can, however, also use a predefined keychain
from the [edit security authentication-key-chains key-chain] hierarchy level to
secure a PCEP session. In this case, you should bind the predefined keychain
into the PCEP session at the [edit protocols pcep pce pce-id] hierarchy level.
The PCE and PCC use the same key to verify the authenticity of each segment
sent on the TCP connection of the PCEP session, thereby securing the PCEP
communication between the devices, which might be subject to attacks and
can disrupt services on the network.
For more information on securing PCEP sessions using MD5 authentication,

see “TCP-MD5 Authentication for PCEP Sessions” on page 705.
Once the PCEP session is established, the PCC performs the following tasks:
1. LSP state synchronization—The PCC sends information about all the LSPs (local and
external) to all connected PCEs. For external LSPs, the PCC sends information about
any configuration change, RRO change, state change, and so on, to the PCE.
For PCE-initiated LSPs, there is no LSP configuration present on the PCC. The PCE
initiating the LSP sends the LSP parameters to the PCC that has indicated its capability
of supporting PCE-initiated LSPs.
NOTE: Support for PCE-initiated LSPs is provided in Junos OS Release

13.3 and later releases.
2. LSP delegation—After the LSP state information is synchronized, the PCC then
delegates the external LSPs to one PCE, which is the main active stateful PCE. Only
the main PCE can set parameters for the external LSP. The parameters that the main
PCE modifies include bandwidth, path (ERO), and priority (setup and hold). The
parameters specified in the local configuration are overridden by the parameters that
are set by the main PCE.
NOTE: When the PCEP session with the main PCE is terminated, the PCC
elects a new main PCE, and all delegated LSPs to the previously main PCE
are delegated to the newly available main PCE.
In the case of PCE-initiated LSPs, the PCC creates the LSP using the parameters
received from the PCE. The PCC assigns the PCE-initiated LSP a unique LSP-ID, and
automatically delegates the LSP to the PCE. A PCC cannot revoke the delegation for
the PCE-initiated LSPs for an active PCEP session.

When a PCEP session terminates, the PCC starts two timers without immediately
deleting the PCE-initiated LSPs – delegation cleanup timeout and lsp cleanup timer –
to avoid disruption of services. During this time, an active stateful PCE can acquire
control of the LSPs provisioned by the failed PCE, by sending a create request for the
LSP.
Control over PCE-initiated LSPs reverts to the PCC at the expiration of the delegation
cleanup timeout. When the delegation cleanup timeout expires, and no other PCE has
acquired control over the LSP from the failed PCE, the PCC takes local control of the
non-delegated PCE-initiated LSP. Later, when the original or a new active stateful
PCE wishes to acquire control of the locally controlled PCE-initiated LSPs, the PCC
delegates these LSPs to the PCE and the lsp cleanup timer timer is stopped.
A PCE may return the delegation of the PCE-initiated LSP to the PCC to allow LSP
transfer between PCEs. This triggers the lsp cleanup timer for the PCE-initiated LSP.
The PCC waits for the LSP cleanup timer to expire before removing the non-delegated
PCE-initiated LSPs from the failed PCE.
When the lsp cleanup timer expires, and no other PCE has acquired control over the
LSPs from the failed PCE, the PCC deletes all the LSPs provisioned by the failed PCE.
3. LSP signaling—On receiving one or more LSP parameters from the main active stateful
PCE, the PCC re-signals the TE LSP based on the PCE provided path. If the PCC fails
to set up the LSP, it notifies the PCE of the setup failure and waits for the main PCE
to provide new parameters for that LSP, and then re-signals it.
When the PCE specifies a path that is incomplete or has loose hops where only the
path endpoints are specified, the PCC does not perform local constraint-based routing
to find out the complete set of hops. Instead, the PCC provides RSVP with the PCE
provided path, as it is, for signaling, and the path gets set up using IGP hop-by-hop
routing.
Considering the topology used in Figure 37 on page 695, Figure 39 on page 701 illustrates
the partial client-side PCE implementation in the MPLS RSVP-TE enabled network. The
ingress routers A and G are the PCCs that are configured to connect to the external
stateful PCE through a TCP connection.
The PCE has a global view of the bandwidth demand in the network and performs external
path computations after looking up the traffic engineering database. The active stateful
PCE then modifies one or more LSP attributes and sends an update to the PCC. The PCC
uses the parameters it receives from the PCE to re-signal the LSP.

Figure 39: Example PCE for MPLS RSVP-TE
This way, the stateful PCE provides a cooperative operation of distributed functionality
used to address specific challenges of a shortest interdomain constrained path
computation. It eliminates congestion scenarios in which traffic streams are inefficiently
mapped onto available resources, causing overutilization of some subsets of network
resources, while other resources remain underutilized.
LSP Behavior with External Computing
• LSP Types on page 701

• LSP Control Mode on page 702
LSP Types
In a client-side PCE implementation, there are three types of TE LSPs:
• CLI-controlled LSPs—The LSPs that do not have the lsp-external-controller pccd

statement configured are called CLI-controlled LSPs. Although these LSPs are under
local control, the PCC updates the connected PCEs with information about the
CLI-controlled LSPs during the initial LSP synchronization process. After the initial LSP
synchronization, the PCC informs the PCE of any new and deleted LSPs as well.
• PCE-controlled LSPs—The LSPs that have the lsp-external-controller pccd statement

configured are called PCE-controlled LSPs. The PCC delegates the PCC-initiated LSPs
to the main PCE for external path computation.
The PCC informs the PCE about the configured parameters of a PCE-controlled LSP,
such as bandwidth, ERO, and priorities. It also informs the PCE about the actual values
used for these parameters to set up the LSP including the RRO, when available.
The PCC sends such LSP status reports to the PCE only when a reconfiguration has
occurred or when there is a change in the ERO, RRO, or status of the PCE-controlled
LSPs under external control.

There are two types of parameters that come from the CLI configuration of an LSP for
a PCE:
• Parameters that are not overridden by a PCE, and that are applied immediately.
• Parameters that are overridden by a PCE. These parameters include bandwidth,

path, and priority (setup and hold values). When the control mode switches from
external to local, the CLI-configured values for these parameters are applied at the
next opportunity to re-signal the LSP. The values are not applied immediately.
• Externally-provisioned LSPs (or PCE-initiated LSPs)—The LSPs that have the

lsp-provisioning statement configured are called PCE-initiated LSPs. A PCE-initiated
LSP is dynamically created by an external PCE; as a result, there is no LSP configuration
present on the PCC. The PCC creates the PCE-initiated LSP using the parameters
provided by the PCE, and automatically delegates the LSP to the PCE.
NOTE: Support for PCE-initiated LSPs is provided in Junos OS Release 13.3

and later releases.
The CLI-controlled LSPs, PCE-controlled LSPs, and PCE-initiated LSPs can coexist on
a PCC.
The CLI-controlled LSPs and PCE-controlled LSPs can coexist on a PCC.
LSP Control Mode
In a client-side PCE implementation, there are two types of control modes for a
PCC-controlled LSP:
• External—By default, all PCE-controlled LSPs are under external control. When an LSP
is under external control, the PCC uses the PCE-provided parameters to set up the
LSP.
• Local—A PCE-controlled LSP can come under local control. When the LSP switches
from external control to local control, path computation is done using the CLI-configured
parameters and constraint-based routing. Such a switchover happens only when there
is a trigger to re-signal the LSP. Until then, the PCC uses the PCE-provided parameters
to signal the PCE-controlled LSP, although the LSP remains under local control.
A PCE-controlled LSP switches to local control from its default external control mode
in cases such as no connectivity to a PCE or when a PCE returns delegation of LSPs back
to the PCC.
For more information about CLI-controlled LSPs and PCE-controlled LSPs, see “LSP
Types” on page 701.
Configuration Statements Supported for External Computing
Table 47 on page 703 lists the MPLS and existing LSP configuration statements that apply
to a PCE-controlled LSP.

Table 47: Applicability of MPLS and Existing LSP Configurations to a

PCE-Controlled LSP
Applicable LSP Applicable MPLS
Configuration Configuration
Support for PCE-Controlled LSP Statements Statements
These configuration statements can be • admin-group • admin-group

configured along with the PCE configuration. • auto-bandwidth • admin-groups
However, they take effect only when the local
• hop-limit • admin-group-extended
configuration is in use. During PCE control, these
configuration statements remain inactive. • least-fill • hop-limit
• most-fill • no-cspf
• random • smart-optimize-timer
These configuration statements can be • bandwidth • priority

configured along with the PCE configuration, • primary
but are overridden by the PCE-controlled LSP
• priority
attributes. However, when the local
configuration is in use, the configured values for
these configuration statements are applied.
NOTE: Changes to the local configuration using

the CLI while the LSP is under the control of a
stateful PCE do not have any effect on the LSP.
These changes come into effect only when the
local configuration is applied.
These configuration statements cannot be • p2mp • p2mp-lsp-next-hop

configured along with the PCE configuration. • template
The rest of the LSP configuration statements are applicable in the same way as for
existing LSPs. On configuring any of the above configuration statements for a
PCE-controlled LSP, an MPLS log message is generated to indicate when the configured
parameters take effect.
PCE-Controlled LSP Protection
The protection paths, including fast reroute and bypass LSPs, are locally computed by
the PCC using constraint-based routing. A stateful PCE specifies the primary path (ERO)
only. A PCE can also trigger a non-standby secondary path, even if the local configuration
does not have a non-standby secondary path for LSP protection.
PCE-Controlled LSP ERO
For PCE-controlled LSPs (PCC-delegated LSPs and PCE-initated LSPs), only a full-blown
Explicit Route Object (ERO) object has to be sent from the PCE to the PCC; otherwise
the PCC rejects the PCUpdate or PCCreate message for that PCEP session.
Starting in Junos OS Release 17.2, in addition to external cspf, two new path computation
types are introduced for the PCE-controlled LSPs: local cspf and no cspf.
• local cspf—A PCC uses the local cspf computation type only when the PCE sends in a
Juniper Vendor TLV (enterprise number: 0x0a4c) of type 5.

• no cspf—Neither the PCE nor the PCC performs a constrained path calculation. The
endpoints and constraints are given to the RSVP module for setting up the LSP with
the IGP path.
A PCC uses no cspf computation type in the following cases:
• When the PCE sends local cspf TLV, and when the Junos OS configuration or matching
template for this LSP included no-cspf in the PCC-delegated LSP.
• When the PCE sends local cspf TLV, and when the Junos OS configuration template
for this LSP included no-cspf in the PCE-initiated LSP.
• When the PCE does not send local cspf TLV with an empty ERO or loose ERO (with
loose bit set in the ERO object).
With these new computation types, a PCC can accept an ERO object either as a loose
ERO, or as an empty ERO. An external path computing entity that is not capable of
computing a path can modify parameters such as bandwidth and color, based on the
analytics. In such cases, an empty ERO object or loose ERO is used and the path to be
taken is decided by the PCC.
PCE Controlled Point-to-Multipoint RSVP-TE LSPs
After a PCEP session is established between a PCE and a PCC, the PCC reports all the
LSPs in the system to the PCE for LSP state synchronization. This includes PCC-controlled,
PCE-delegated, and PCE-initiated point-to-point LSPs. Starting with Junos OS Release
15.1F6 and 16.1R1, this capability is extended to report point-to-multipoint LSPs as well.
For a PCE, the point-to-multipoint LSP is similar to that of RSVP point-to-multipoint
LSP, where the point-to-multipoint LSP is treated as collection of point-to-point LSPs
grouped under a point-to-multipoint identifier.
By default, PCE control of point-to-multipoint LSPs is not supported on a PCC. To add

this capability, include the p2mp-lsp-report-capability statement at the [edit protocols
pcep pce pce-name] or [edit protocols pcep pce-group group-id] hierarchy levels. After
the point-to-multipoint report capability is configured on a PCC, the PCC advertises this
capability to the PCE. If the PCE advertises the same point-to-multipoint report capability
in return, then the PCC reports the complete point-to-multipoint LSP tree to the PCE for
LSP state synchronization.
A PCC with the point-to-multipoint TE LSP capability supports reporting of

point-to-multipoint TE LSPs for stateful PCEs, point-to-multipoint update, and LSP
database supporting point-to-multipoint LSP name as key. However, the following
features and functions are not supported for Junos OS Release 15.1F6 and 16.1:
• Static point-to-multipoint LSPs
• PCE-delegated and PCE-initiated point-to-multipoint LSPs
• Auto-bandwidth
• TE++
• PCE request and reply message
• Creation of point-to-multipoint LSPs using templates

• Configuring forward entry on the PCE-initiated point-to-multipoint LSPs
• Configuring forward entry on the router pointing to a provisioned LSP.
Auto-Bandwidth and PCE-Controlled LSP
Starting in Junos OS Release 14.2R4, support of auto-bandwidth is provided for

PCE-controlled LSPs. In earlier releases, the auto-bandwidth option did not apply to
PCE-controlled LSPs, although LSPs under the control of auto-bandwdith and
constraint-based routing could coexist with PCE-controlled LSPs. The statistics collection
for auto-bandwidth was taking effect only when the control mode of a PCE-controlled
LSP changes from external to local. This was happening in cases such as no connectivity
to a PCE or when a PCE returns delegation of LSPs back to the PCC.
TCP-MD5 Authentication for PCEP Sessions
A stateful PCE server automates the creation of traffic engineering paths across the
network, increasing network utilization and enabling a customized programmable
networking experience with the use of PCEP communication with a PCC. A PCC sends
LSP reports to a PCE server, and the PCE updates or provisions LSPs back to the PCC.
The data sent over a PCEP session is crucial for a PCE server to perform external path
computing. As a result, an attack on the PCEP communication can disrupt network
services. If altered PCEP messages are sent to a PCC, inappropriate LSPs can be set up.
Similarly, if altered PCEP messages are sent to a PCE, an incorrect view of the network
is learned by the PCE.
Considering the significance of the PCEP communication between a PCE and PCC in
executing the PCE functionalities effectively, Junos OS Release 16.1 introduces the feature
of securing a PCEP session using TCP-MD5 authentication as per RFC 5440. This feature
protects the communication between a PCE and PCC over a PCEP session, which might
be subject to an attack, and can disrupt network services.
To enable the MD5 security mechanism for a PCEP session, it is recommended that you
define and bind the MD5 authentication key at the [edit protocols pcep pce pce-id]
hierarchy level for a PCEP session. You can, however, also use a predefined keychain
from the [edit security authentication-key-chains key-chain] hierarchy level to secure a
PCEP session. In this case, you should bind the predefined keychain into the PCEP session
at the [edit protocols pcep pce pce-id] hierarchy level.
The following configuration is executed on the PCC to establish a secure PCEP session
with a PCE:
• Using MD5 authentication key:
[edit protocols pcep pce pce-id]

user@PCC# set authentication-key key
• Using predefined authentication keychain:

user@PCC# set authentication-key-chain key-chain
user@PCC# set authentication-algorithm md5

For secure PCEP sessions to be established successfully, the MD5 authentication should
be configured with the pre-shared authentication key on both the PCE server and the
PCC. The PCE and PCC use the same key to verify the authenticity of each segment sent
on the TCP connection of the PCEP session.
NOTE:
• Junos OS Release 16.1 supports only TCP-MD5 authentication for PCEP
sessions, without extending support for TLS and TCP-AO, such as protection
against eavesdropping, tampering, and message forgery.
• Initial application of security mechanism to a PCEP session causes the

session to reset.
• If MD5 is misconfigured or not configured on one side of the PCEP session,

the session does not get established. Verify that the configurations on the
PCC and PCE are matching.
• This feature does not provide support for any session authentication
mechanism.
• To view the authentication keychain used by the PCEP session, use the
show path-computation-client status and show protocols pcep command
outputs.
• Use the show system statistics tcp | match auth command to view the
number of packets that get dropped by TCP because of authentication
errors.
• Operation of the keychain can be verified by using the show security keychain
detail command output.
Impact of Client-Side PCE Implementation on Network Performance
The maintenance of a stateful database can be non-trivial. In a single centralized PCE

environment, a stateful PCE simply needs to remember all the TE LSPs that the PCE has
computed, the TE LSPs that were actually set up (if this can be known), and when the
TE LSPs were torn down. However, these requirements cause substantial control protocol
overhead in terms of state, network usage and processing, and optimizing links globally
across the network. Thus, the concerns of a stateful PCE implementation include:
• Any reliable synchronization mechanism results in significant control plane overhead.

PCEs might synchronize state by communicating with each other, but when TE LSPs
are set up using distributed computation performed among several PCEs, the problems
of synchronization and race condition avoidance become larger and more complex.
• Out-of-band traffic engineering database synchronization can be complex with multiple

PCEs set up in a distributed PCE computation model, and can be prone to race
conditions, scalability concerns, and so on.
• Path calculations incorporating total network state is highly complex, even if the PCE
has detailed information on all paths, priorities, and layers.

In spite of the above concerns, the partial client-side implementation of the stateful PCE
is extremely effective in large traffic engineering systems. It provides rapid convergence
and significant benefits in terms of optimal resource usage, by providing the requirement
for global visibility of a TE LSP state and for ordered control of path reservations across
devices within the system being controlled.
17.2R1 Starting in Junos OS Release 17.2, in addition to external cspf, two new path
computation types are introduced for the PCE-controlled LSPs: local cspf and
no cspf.
16.1 Starting with Junos OS Release 16.1, you can secure a PCEP session using
TCP-MD5 authentication as per RFC 5440.
16.1 Junos OS Release 16.1 introduces the feature of securing a PCEP session using
TCP-MD5 authentication as per RFC 5440.
14.2R4 Starting in Junos OS Release 14.2R4, support of auto-bandwidth is provided

for PCE-controlled LSPs.
Related • Example: Configuring the Path Computation Element Protocol for MPLS RSVP-TE on
• Example: Configuring Path Computation Element Protocol for MPLS RSVP-TE with
Support of PCE-Initiated LSPs on page 721
Support for PCE-Controlled Point-to-Multipoint LSPs on page 735
Configuring PCEP
• Example: Configuring the Path Computation Element Protocol for MPLS

RSVP-TE on page 707
• Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support of
PCE-Initiated LSPs on page 732
Support for PCE-Controlled Point-to-Multipoint LSPs on page 735
Example: Configuring the Path Computation Element Protocol for MPLS RSVP-TE
This example shows how to enable external path computing by a Path Computation
Element (PCE) for traffic engineered label-switched paths (TE LSPs) on a Path

Computation Client (PCC). It also shows how to configure the Path Computation Element
Protocol (PCEP) on the PCC to enable PCE to PCC communication.

Requirements
• Three routers that can be a combination of ACX Series routers, M Series Multiservice
Edge Routers, MX Series 3D Universal Edge Routers, T Series Core Routers, or PTX
Series Transport Router, one of which is configured as a PCC.
• A TCP connection to an external stateful PCE from the PCC.
• Junos OS Release 12.3 or later running on the PCC along with the JSDN add-on package.
NOTE: The JSDN add-on package is required to be installed along with the
core Junos OS installation package.
Before you begin:
1. Configure the device interfaces.
2. Configure MPLS and RSVP-TE.
3. Configure IS-IS or any other IGP protocol.
Overview
Starting with Junos OS Release 12.3, the MPLS RSVP-TE functionality is extended to
provide a partial client-side implementation of the stateful PCE architecture
(draft-ietf-pce-stateful-pce) on a PCC.
NOTE: The partial client-side implementation of the stateful PCE architecture

is based on version 2 of Internet draft draft-ietf-pce-stateful-pce. Starting
with Junos OS Release 16.1, this implementation is upgraded to support
version 7, as defined in Internet draft draft-ietf-pce-stateful-pce-07. Releases
prior to 16.1 support the older version of the PCE draft, causing interoperability
issues between a PCC running a previous release and a stateful PCE server
that adheres to Internet draft draft-ietf-pce-stateful-pce-07.
To enable external path computing by a PCE, include the lsp-external-controller statement

on the PCC at the [edit mpls] and [edit mpls lsp lsp-name] hierarchy levels.
lsp-external-controller pccd;

An LSP configured with the lsp-external-controller statement is referred to as a

PCE-controlled LSP and is under the external control of a PCE by default. An active
stateful PCE can override the parameters set from the CLI, such as bandwidth, path
(ERO), and priority, for such PCE-controlled LSPs of the PCC.
To enable PCE to PCC communication, configure PCEP on the PCC at the [edit protocols]
hierarchy level.
pcep { ... }
When configuring PCEP on a PCC, be aware of the following considerations:
• The JSDN add-on package is required to be installed along with the core Junos OS
installation package.
• Junos OS Release 12.3 supports only stateful PCEs.
• A PCC can connect to a maximum of 10 stateful PCEs. At any given point in time, there
can be only one main PCE (the PCE with the lowest priority value, or the PCE that
connects to the PCC first in the absence of a PCE priority) to which the PCC delegates
LSPs for path computation.
• For Junos OS Release 12.3, the PCC always initiates the PCEP sessions. PCEP sessions
initiated by remote PCEs are not accepted by the PCC.
• Existing LSP features, such as LSP protection and make-before-break, work for
PCE-controlled LSPs.
• The auto-bandwidth option is turned off for PCE-controlled LSPs, although LSPs under
the control of auto-bandwdith and constraint-based routing can coexist with
PCE-controlled LSPs.
• PCE-controlled LSPs can be referred to by other CLI configurations, such as lsp-nexthop

to routes, forwarding adjacencies, CCC connections, and logical tunnels.
• PCE-controlled LSPs do not support GRES.
• PCE-controlled LSPs under logical-systems are not supported.
• PCE-controlled LSPs cannot be point-to-multipoint LSPs.
• Bidirectional LSPs are not supported.
• PCE-controlled LSPs cannot have secondary paths without a primary path.
• PCE-controlled LSPs depend on external path computation, which impacts overall

setup time, reroutes, and make-before-break features.
• Setup time and convergence time (reroute, MBB) for exisiting LSPs is the same as in
previous releases, in the absence of PCE-controlled LSPs. However, a small impact is
seen in the presence of PCE-controlled LSPs.
• ERO computation time is expected to be significantly higher than local-CSPF.

Topology
Figure 40: Configuring PCEP for MPLS RSVP-TE
In this example, PCC is the ingress router that connects to the external active stateful
PCE.
The external LSPs of Router PCC are computed as follows:
1. Router PCC receives the LSP tunnel configuration that was set up using the CLI.
Assuming that the received configuration is enabled with external path computing,
Router PCC becomes aware that some of the LSP attributes – bandwidth, path, and
priority – are under the control of the stateful PCE and delegates the LSP to the PCE.
In this example, the external LSP is called PCC-to-R2 and it is being set up from Router
PCC to Router R2 . The CLI-configured ERO for PCC-to-R2 is PCC-R0-R1-R2. The
bandwidth for PCC-to-R2 is 10m, and both the setup and hold priority values are 4.
2. Router PCC tries to retrieve the PCE-controlled LSP attributes. To do this, Router PCC
sends out a PCRpt message to the stateful PCE stating that the LSP has been
configured. The PCRpt message communicates the status of the LSP and contains
the local configuration parameters of the LSP.
3. The stateful PCE modifies one or more of the delegated LSP attributes and sends the
new LSP parameters to Router PCC through the PCUpd message.
4. On receiving the new LSP parameters, Router PCC sets up a new LSP and re-signals
it using the PCE-provided path.
In this example, the PCE-provided ERO for PCC-to-R2 is PCC-R3-R2. The bandwidth
for PCC-to-R2 is 8m, and both the setup and hold priority values are 3.
5. Router PCC sends a PCRpt with the new RRO to the stateful PCE.

Configuration
level.
PCC set interfaces ge-1/0/1 unit 0 family inet address 20.31.4.1/24

set protocols rsvp interface all
set protocols rsvp interface fxp0.0 disable
set protocols mpls lsp-external-controller pccd
set protocols mpls label-switched-path PCC-to-R2 to 10.255.179.98
set protocols mpls label-switched-path PCC-to-R2 bandwidth 10m
set protocols mpls label-switched-path PCC-to-R2 priority 4 4
set protocols mpls label-switched-path PCC-to-R2 primary to-R2-path
set protocols mpls label-switched-path PCC-to-R2 lsp-external-controller pccd
set protocols mpls path to-R2-path 20.31.1.2 strict
set protocols mpls path to-R2-path 20.31.2.2 strict
set protocols isis level 1 disable
set protocols isis interface all
set protocols pcep pce pce1 destination-ipv4-address 10.209.57.166
set protocols pcep pce pce1 destination-port 4189
set protocols pcep pce pce1 pce-type active
set protocols pcep pce pce1 pce-type stateful

R1 set system ports console log-out-on-disconnect






Mode.
To configure Router PCC:
NOTE: Repeat this procedure for every Juniper Networks ingress router in the
MPLS domain, after modifying the appropriate interface names, addresses,
and any other parameters for each router.
To enable MPLS, include the protocol family on the interface so that the interface
does not discard incoming MPLS traffic.
[edit interfaces]
user@PCC# set ge-1/0/1 unit 0 family inet address 20.31.4.1/24
user@PCC# set ge-1/0/1 unit 0 family iso
user@PCC# set ge-1/0/1 unit 0 family mpls

user@PCC# set lo0 unit 0 family inet address 10.255.179.95/32
2. Enable RSVP on all interfaces of Router PCC, excluding the management interface.
[edit protocols]
user@PCC# set rsvp interface all
user@PCC# set rsvp interface fxp0.0 disable
3. Configure the label-switched path (LSP) from Router PCC to Router R2 and enable
external control of LSPs by the PCE.
[edit protocols]
user@PCC# set mpls lsp-external-controller pccd
user@PCC# set mpls label-switched-path PCC-to-R2 to 10.255.179.98/32
user@PCC# set mpls label-switched-path PCC-to-R2 bandwidth 10m
user@PCC# set protocols mpls label-switched-path PCC-to-R2 priority 4 4
user@PCC# set protocols mpls label-switched-path PCC-to-R2 primary to-R2-path
user@PCC# set protocols mpls label-switched-path PCC-to-R2
lsp-external-controller pccd
4. Configure the LSP from Router PCC to Router R2, which has local control and is
overridden by the PCE-provided LSP parameters.
[edit protocols]
user@PCC# set mpls path to-R2-path 20.31.1.2/30 strict
user@PCC# set mpls path to-R2-path 20.31.2.2/30 strict

5. Enable MPLS on all interfaces of Router PCC, excluding the management interface.
[edit protocols]
user@PCC# set mpls interface all
user@PCC# set mpls interface fxp0.0 disable
6. Configure IS-IS on all interfaces of Router PCC, excluding the management interface.
[edit protocols]
user@PCC# set isis level 1 disable
user@PCC# set isis interface all
user@PCC# set isis interface fxp0.0 disable
user@PCC# set isis interface lo0.0
7. Define the PCE that Router PCC connects to, and configure the IP address of the
PCE.
[edit protocols]
user@PCC# set pcep pce pce1 destination-ipv4-address 10.209.57.166
8. Configure the destination port for Router PCC that connects to a PCE using the
TCP-based PCEP.
[edit protocols]
user@PCC# set pcep pce pce1 destination-port 4189
9. Configure the PCE type.
[edit protocols]
user@PCC# set pcep pce pce1 pce-type active
user@PCC# set pcep pce pce1 pce-type stateful
Results
From configuration mode, confirm your configuration by entering the show interfaces and
show protocols commands. If the output does not display the intended configuration,
user@PCC# show interfaces

ge-1/0/1 {
unit 0 {
family inet {
address 20.31.4.1/24;
}
family iso;
family mpls;
}
}
ge-1/1/1 {
unit 0 {
family inet {
address 20.31.1.1/24;
}

family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.179.95/32;
}
}
}
user@PCC# show protocols

rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path PCC-to-R2 {
to 10.255.179.98;
bandwidth 10m;
priority 4 4;
primary to-R2-path;
}
path to-R2-path {
20.31.1.2 strict;
20.31.2.2 strict;
}
interface all;
interface fxp0.0 {
disable;
}
}
isis {
level 1 disable;
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0;
}
pcep {
pce pce1 {
destination-ipv4-address 10.209.57.166;
pce-type active stateful;
}
}
If you are done configuring the device, enter commit from configuration mode.

Verification
• Verifying the PCEP Session Status on page 716

• Verifying the PCE-Controlled LSP Status When LSP Control Is External on page 717
• Verifying the PCE-Controlled LSP Status When LSP Control Is Local on page 718
Verifying the PCEP Session Status
Purpose Verify the PCEP session status between the PCE and Router PCC when the PCE status
is up.
Action From operational mode, run the show path-computation-client active-pce command.
user@PCC> show path-computation-client active-pce

PCE pce1
General
IP address : 10.209.57.166
Priority : 0
PCE status : PCE_STATE_UP
Session type : PCE_TYPE_STATEFULACTIVE
PCE-mastership : main
Counters
PCReqs Total: 0 last 5min: 0 last hour: 0
PCReps Total: 0 last 5min: 0 last hour: 0
PCRpts Total: 5 last 5min: 5 last hour: 5
PCUpdates Total: 1 last 5min: 1 last hour: 1
Timers
Local Keepalive timer: 30 [s] Dead timer: 120 [s]
Remote Keepalive timer: 30 [s] Dead timer: 120 [s]
Errors
PCErr-recv
PCErr-sent
PCE-PCC-NTFS
PCC-PCE-NTFS
Meaning The output displays information about the current active stateful PCE that Router PCC
is connected to. The PCE status output field indicates the current status of the PCEP
session between the PCE and Router PCC.
For pce1, the status of the PCEP session is PCE_STATE_UP, which indicates that the PCEP
session has been established between the PCEP peers.

The statistics of PCRpts indicate the number of messages sent by Router PCC to the PCE
to report the current status of LSPs. The PCUpdates statistics indicate the number of
messages received by Router PCC from the PCE. The PCUpdates messages include the
PCE modified parameters for the PCE-controlled LSPs.
Verifying the PCE-Controlled LSP Status When LSP Control Is External
Purpose Verify the status of the PCE-controlled LSP from Router PCC to Router R2 when the LSP
is under external control.
Action From operational mode, run the show mpls lsp name PCC-to-R2 extensive command.
user@PCC> show mpls lsp name PCC-to-R2 extensive

Ingress LSP: 1 sessions
10.255.179.98
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
ActivePath: to-R2-path (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Externally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary to-R2-path State: Up
Priorities: 3 3
Bandwidth: 8Mbps
SmartOptimizeTimer: 180
No computed ERO.
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
20.31.4.2 20.31.5.2
21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP
status
20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains:
bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
19 Mar 11 05:00:56.735 Selected as active path
status
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
status
12 Mar 11 05:00:56.712 Originate Call
11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters : 20.31.4.2
20.31.5.2
status
status


5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
status
1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions

Transit LSP: 0 sessions

Meaning In the output, the LSPtype and LSP Control Status output fields show that the LSP is
externally controlled. The output also shows a log of the PCEP messages sent between
Router PCC and the PCE.
The PCEP session between the PCE and Router PCC is up, and Router PCC receives the
following PCE-controlled LSP parameters:
• ERO (path)—20.31.4.2 and 20.31.5.2
• Bandwidth—8Mbps
• Priorities—3 3 (setup and hold values)
Verifying the PCE-Controlled LSP Status When LSP Control Is Local
Purpose Verify the status of the PCE-controlled LSP from Router PCC to Router R2 when the LSP
control becomes local.
Action From operational mode, run the show mpls lsp name PCC-to-R2 extensive command.
user@PCC> show mpls lsp name PCC-to-R2 extensive

10.255.179.98
LSP Control Status: Locally controlled
LoadBalance: Random
Priorities: 4 4 (ActualPriorities 3 3)
Bandwidth: 10Mbps (ActualBandwidth: 8Mbps)
No computed ERO.
20=Node-ID):
20.31.4.2 20.31.5.2


status
status
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
status
20.31.5.2
status
status
status
Created: Mon Mar 11 05:00:00 2013


Meaning In the output, the LSP Control Status output field shows that the LSP is under local control.
Although the PCE-controlled LSP is under local control, Router PCC continues to use the
PCE-provided parameters, until the next opportunity to re-signal the LSP.
The output now displays the LSP parameters that were configured using the CLI along
with the PCE-provided parameters used to establish the LSP as the actual values in use.
• Bandwidth—10Mbps (ActualBandwidth: 8Mbps)
• Priorities—4 4 (ActualPriorities 3 3)

On the trigger to re-signal the LSP, Router PCC uses the local configuration parameters
to establish the PCE-controlled LSP.
user@PCC> show mpls lsp name PCC-to-R2 extensive externally-controlled

10.255.179.98
LSP Control Status: Locally controlled
LoadBalance: Random
Priorities: 4 4
Bandwidth: 10Mbps
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
20.31.1.2 S 20.31.2.2 S 20.31.8.2 S
20=Node-ID):
20.31.1.2 20.31.2.2 20.31.8.2
28 Mar 11 05:02:51.787 Record Route: 20.31.1.2 20.31.2.2 20.31.8.2
27 Mar 11 05:02:51.787 Up
26 Mar 11 05:02:51.697 EXTCTRL_LSP: Applying local parameters with this
signalling attempt
24 Mar 11 05:02:51.696 Clear Call
23 Mar 11 05:02:51.696 CSPF: computation result accepted 20.31.1.2 20.31.2.2
20.31.8.2
status
status
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
status
20.31.5.2
status
status

status
Created: Mon Mar 11 05:00:00 2013


The Computed ERO is 20.31.1.2, 20.31.2.2, and 20.31.8.2. The PCE-controlled LSP is
established using the local configuration parameters.
Documentation
Example: Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support
of PCE-Initiated LSPs
This example shows how to configure the Path Computation Client (PCC) with the
capability of supporting Path Computation Element (PCE)-initiated traffic-engineered
label-switched paths (LSPs).

Requirements
• Three routers that can be a combination of ACX Series, M Series, MX Series, or T Series
routers.
• A TCP connection to two external stateful PCEs from the ingress router (PCC).
• Junos OS Release 16.1 or later running on the PCC.
Before you begin:
• Configure the device interfaces.
• Configure MPLS and RSVP-TE (RSVP-Traffic Engineering).
• Configure OSPF or any other IGP protocol.

Overview
Starting with Junos OS Release 16.1, the PCEP functionality is extended to allow a stateful
PCE to initiate and provision traffic engineering LSPs through a PCC. Earlier, the LSPs
were configured on the PCC and the PCC delegated control over the external LSPs to a
PCE. The ownership of the LSP state was maintained by the PCC. With the introduction
of the PCE-initiated LSPs, a PCE can initiate and provision a traffic engineering LSP
dynamically without the need for a locally configured LSP on the PCC. On receiving a
PCCreate message from a PCE, the PCC creates the PCE-initiated LSP and automatically
delegates the LSP to the PCE.
By default, a PCC rejects the request for provisioning PCE-initiated LSPs from a PCE. To
enable support of PCE-initated LSPs on the PCC, include the lsp-provisioning statement
at the [edit protocols pcep pce pce-id] or [edit protocols pcep pce-group group-id] hierarchy
levels.
A PCC indicates its capability of supporting PCE-initiated LSPs while establishing the
Path Computation Element Protocol (PCEP) session with the PCE. A PCE selects a PCC
with this capability to initiate an LSP. The PCE provides the PCC with the PCE-initiated
LSP parameters. On receiving the PCE-initiated LSP parameters, the PCC sets up the
LSP, assigns an LSP ID, and automatically delegates the LSP to the PCE.
When the PCE initiating the LSP does not provide the PCE-initiated LSP parameters, the
PCC uses the default parameters. An optional LSP template may also be configured to
specify values for the PCE-initiated LSP when the LSP parameters are not provided by
the PCE. To configure an LSP template for PCE-initiated LSPs on the PCC, include the
label-switched-path-template statement at the [edit protocols mpls lsp-external-controller
lsp-external-controller] hierarchy level.
When a PCEP session terminates, the PCC starts two timers without immediately deleting
the PCE-initiatedLSPs—delegation cleanup timeout and lsp cleanup timer—to avoid
disruption of services. During this time, an active stateful PCE can acquire control of the
LSPs provisioned by the failed PCE.
A PCE may return the delegation of the PCE-initiated LSP to the PCC to allow LSP transfer
between PCEs. Control over PCE-initiated LSPs reverts to the PCC at the expiration of
the delegation cleanup timeout. When the delegation cleanup timeout expires, and no
other PCE has acquired control over the LSP from the failed PCE, the PCC takes local
control of the non-delegated PCE-initiated LSP. Later, when the original or a new active
stateful PCE wishes to acquire control of the locally controlled PCE-initiated LSPs, the
PCC delegates these LSPs to the PCE and the LSP cleanup timer is stopped.
The PCC waits for the LSP cleanup timer to expire before deleting the non-delegated
PCE-initiated LSPs from the failed PCE. When the LSP cleanup timer expires, and no
other PCE has acquired control over the LSPs from the failed PCE, the PCC deletes all
the LSPs provisioned by the failed PCE.

When configuring the support of PCE-initiated LSPs for a PCC, be aware of the following
considerations:
• Junos OS Release 13.3 supports only stateful PCEs.
• For Junos OS Release 13.3, the PCC always initiates the PCEP sessions. PCEP sessions
initiated by remote PCEs are not accepted by the PCC.
• Existing LSP features, such as LSP protection and make-before-break, work for
PCE-initiated LSPs.
• PCE-initiated LSPs do not support graceful Routing Engine switchover (GRES).
• PCE-initiated LSPs under logical systems are not supported.
• PCE-initiated LSPs cannot be point-to-multipoint LSPs.
• Bidirectional LSPs are not supported.
• RSVP-TE for unnumbered links is not supported. PCE-initiated LSPs support only
numbered links.
Topology
Figure 41: Example PCE-Initated LSP for MPLS RSVP-TE

lo0=192.168.69.58
PCE1
lo0=192.168.12.1 lo0=192.168.10.1 lo0=192.168.11.1
PCC 10.0.102.10 R1 10.0.101.9 R2

ge-3/ 1/1 ge-3/ 1/2
ge-0/1/1 ge-0 / 1/2
ge-0/1/3 10.0.102.9 10.0.101.10 ge-0/1/3
10.0.112.14 10.0.112.13
g043463
PCE2
lo0=192.168.70.65
In this example, PCC is the ingress router that connects to two external stateful PCEs:
PCE1 and PCE2.
When there is a new demand, the active stateful PCE dynamically initiates an LSP to
meet the requirement. Since PCC is configured with the capability of supporting the
PCE-initiated LSP, path computation on PCC is performed as follows:
1. A PCE sends a PCCreate message to the PCC to initiate and provision an LSP. The
PCC sets up the PCE-initiated LSP using the parameters received from the PCE, and
automatically delegates the PCE-initiated LSP to the PCE that initiated it.
In this example, PCE1 is the active stateful PCE that initiates and provisions the
PCE-initiated LSP on PCC. On receiving the PCE-initiated LSP parameters, PCC sets
up the LSP and automatically delegates the PCE-initiated LSP to PCE1.
2. When the PCEP session between PCC and PCE1 is terminated, PCC starts two timers
for the PCE1-initiated LSP: delgation cleanup timeout and the LSP cleanup timer.
During this time, PCE1 or PCE2 can acquire control of the PCE-initiated LSP.

3. If PCE2 acquires control over the PCE-initiated LSP before the expiration of the LSP
cleanup timer, PCC delegates the PCE-initiated LSP to PCE2, and the LSP cleanup
timer and the delegation cleanup timeout are stopped.
4. If the delegation cleanup timeout expired, and neither PCE1 nor PCE2 acquired control
over the PCE-initiated LSP, PCC takes local control of the non-delegated PCE-initiated
LSP until the expiration of the LSP cleanup timer.
5. After the expiration of the LSP cleanup timer, PCC deletes the PCE-initiated LSP
provisioned by PCE1.
Configuration
level.

set protocols mpls lsp-external-controller ppcd
set protocols pcep pce-group PCEGROUP pce-type active
set protocols pcep pce-group PCEGROUP pce-type stateful
set protocols pcep pce-group PCEGROUP lsp-provisioning
set protocols pcep pce-group PCEGROUP lsp-cleanup-timer 30
set protocols pcep pce PCE1 destination-ipv4-address 192.168.69.58
set protocols pcep pce PCE1 destination-port 4189
set protocols pcep pce PCE1 pce-group PCEGROUP
set protocols pcep pce PCE2 destination-ipv4-address 192.168.70.65
set protocols pcep pce PCE2 destination-port 4189
set protocols pcep pce PCE2 pce-group PCEGROUP




Mode.
To configure the PCC router:
NOTE: Repeat this procedure for every Juniper Networks ingress router in the
MPLS domain, after modifying the appropriate interface names, addresses,
and any other parameters for each router.
To enable MPLS, include the protocol family on the interface so that the interface
does not discard incoming MPLS traffic.
[edit interfaces]

user@PCC# set lo0 unit 0 family inet address 192.168.12.1/32
2. Enable RSVP on all interfaces of the PCC, excluding the management interface.

[edit protocols]
3. Enable external control of LSPs by the PCEs.
[edit protocols]
user@PCC# set mpls lsp-external-controller pccd
4. Enable MPLS on all interfaces of the PCC, excluding the management interface.
[edit protocols]
5. Configure OSPF on all interfaces of the PCC, excluding the management interface.
[edit protocols]
user@PCC# set ospf traffic-engineering
user@PCC# set ospf area 0.0.0.0 interface all
user@PCC# set ospf area 0.0.0.0 interface fxp0.0 disable
user@PCC# set ospf interface lo0.0
6. Define the PCE group and enable support of PCE-initiated LSPs for the PCE group.
[edit protocols]
user@PCC# set protocols pcep pce-group PCEGROUP pce-type active
user@PCC# set protocols pcep pce-group PCEGROUP pce-type stateful
user@PCC# set protocols pcep pce-group PCEGROUP lsp-provisioning
user@PCC# set protocols pcep pce-group PCEGROUP lsp-cleanup-timer 30
7. Define the PCEs that connect to the PCC.
[edit protocols]
user@PCC# set pcep pce PCE1 destination-ipv4-address 192.168.69.58
user@PCC# set pcep pce PCE1 destination-port 4189
user@PCC# set pcep pce PCE1 pce-group PCEGROUP
user@PCC# set pcep pce PCE2 destination-ipv4-address 192.168.70.65

user@PCC# set pcep pce PCE2 destination-port 4189
user@PCC# set pcep pce PCE2 pce-group PCEGROUP
Results

ge-0/1/1 {
unit 0 {
family inet {
address 10.0.102.9/24;

}
family iso;
family mpls;
}
}
ge-0/1/3 {
unit 0 {
family inet {
address 10.0.112.14/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.12.1/32;
}
}
}

rsvp {
interface all;
}
interface fxp0.0 {
disable;
}
}
mpls {
interface all;
interface fxp0.0 {
disable;
}
}
ospf {
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
pce-group PCEGROUP {
lsp-provisioning;
lsp-cleanup-timer 30;
}
pce PCE1 {
pce-group PCEGROUP;
}

pce PCE2 {
pce-group PCEGROUP;
}
If you are done configuring the device, enter commit from configuration mode.
Verification
• Verifying PCC Status on page 728

• Verifying PCE1 Status on page 729
• Verifying the PCE-Initiated LSP Status When the LSP Is Externally
Provisioned on page 731
Verifying PCC Status
Purpose Verify the PCEP session status and LSP summary between the PCC and the connected
PCEs.
Action From operational mode, run the show path-computation-client status command.
user@PCC# show path-computation-client status

Session Type Provisioning Status
PCE1 Stateful Active On Up
PCE2 Stateful Active On Up
LSP Summary
Total number of LSPs : 1
Static LSPs : 0
Externally controlled LSPs : 0
Externally provisioned LSPs : 1/16000 (current/limit)
Orphaned LSPs : 0
PCE1 (main)
Delegated : 1
Externally provisioned : 1
PCE2
Delegated : 0
Externally provisioned : 0
Meaning The output displays the status of the PCEP session between the active stateful PCEs
and the PCC. It also displays information about the different types of LSPs on the PCC,
and the number of LSPs provisioned by the connected PCEs and delegated to them.
PCE1 is the main active PCE and has one PCE-initiated LSP that has been automatically
delegated to it by the PCC.

Verifying PCE1 Status
Purpose Verify the status of the main active stateful PCE.

Action From operational mode, run the show path-computation-client active-pce detail command.
user@PCC# show path-computation-client active-pce

PCE PCE1
--------------------------------------------
General
IP address : 192.168.69.58
Priority : 0
LSP provisioning allowed : On
LSP cleanup timer : 30 [s]
Max unknown messages : 5
Keepalives received : 0
Keepalives sent : 0
Dead timer : 0 [s]
Elapsed as main current : 1 [s]
Elapsed as main total : 446380 [s]
Unknown msgs/min rate : 0
Session failures : 2198
Corrupted messages : 0
Delegation timeout set : 30
Delegation timeout in : 0 [s]
Delegation failures : 0
Connection down : 167092 [s]
Counters
PCRpts Total: 5 last 5min: 5 last hour: 5
PCCreates Total: 1 last 5min: 1 last hour: 1
Timers
Local Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer:
30 [s]
Remote Keepalive timer: 0 [s] Dead timer: 0 [s] LSP cleanup timer:
- [s]
Errors
PCErr-recv
PCErr-sent
PCE-PCC-NTFS
PCC-PCE-NTFS
Meaning The output displays information about the current active stateful PCE to which the PCC
is connected. The PCE status output field indicates the current status of the PCEP session
between a PCE and PCC.
For PCE1, the status of the PCEP session is PCE_STATE_UP, which indicates that the
PCEP session has been established with the PCC.

Verifying the PCE-Initiated LSP Status When the LSP Is Externally Provisioned
Purpose Verify the status of the PCE-initiated LSP.
Action From operational mode, run the show mpls lsp externally-provisioned detail command.
user@PCC# show mpls lsp externally-provisioned detail

10.0.101.10
From: 10.0.102.9, State: Up, ActiveRoute: 0, LSPname: lsp15
ActivePath: path1 (primary)
Link protection desired
LSPtype: Externally Provisioned, Penultimate hop popping
LoadBalance: Random
*Primary path1 State: Up
Priorities: 7 0
Bandwidth: 8Mbps
10.0.102.10 S 10.0.101.9 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node
10=SoftPreempt 20=Node-ID):
10.0.102.10 S 10.0.101.9 S
Meaning In the output, the LSPtype output field shows that the LSP is externally provisioned.
The PCEP session between PCC and PCE1 is up, and the PCC receives the following
PCE-initiated LSP parameters:
• ERO (path)—10.0.102.10 and 10.0.101.9
• Bandwidth—8 Mbps
• Priority—7 0 (setup and hold values)
Documentation
• Example: Configuring the Path Computation Element Protocol for MPLS RSVP-TE on
page 707
• Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support of
PCE-Initiated LSPs on page 732

Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support of
PCE-Initiated LSPs
You can configure a Path Computation Client (PCC) with the capability of supporting
dynamically created label switched paths (LSPs) from a centralized external path
computing entity. A stateful Path Computaiton Element (PCE) can be used to perform
external path computation and generate dynamic LSPs when there is an increase in
demand.
A PCC creates the PCE-initiated LSP using the PCE-provided LSP parameters, or
parameters from a pre-configured LSP template when the PCE does not provision the
LSP, and automatically delegates the PCE-initiated LSP to the respective PCE. As a
result, for PCE-initiated LSPs, there is no need for a locally configured LSP on the PCC.
A CLI-controlled LSP, PCE-controlled LSP, and PCE-initiated LSP can coexist with each
other on a PCC.
Before you begin:
• Configure MPLS and RSVP-TE.
To configure PCC to support PCE-initiated LSPs, complete the following tasks:
1. In configuration mode, go to the following hierarchy level:
[edit]
user@PCC# edit protocols pcep
2. Specify the number of messages per minute that the PCC can receive at maximum.
[edit protocols pcep]

user@PCC# set message-rate-limit messages-per-minute
3. Specify the number of externally provisioned label switched paths (LSPs) over all
connected PCEs that the PCC can accept at maximum.

user@PCC# set max-provisioned-lsps max-count
4. Specify the unique user defined ID for the connected PCE to configure the PCE
parameters.

user@PCC# edit pce pce-id
5. Specify the amount of time (in seconds) that the PCC must wait before returning
control of LSPs to the routing protocol process after a PCEP session is disconnected.

user@PCC# set delegation-cleanup-timeout seconds

6. Specify the IPv4 address of the PCE to connect with.

user@PCC# set destination-ipv4-address ipv4-address
7. Specify the TCP port number that the PCE is using

user@PCC# set destination-port port-number
The value can range from 1 through 65535 and the default value is 4189.
8. Specify the amount of time (in seconds) that the PCC must wait before deleting any
non-delegated PCE-initiated LSPs from the failed PCE after a PCEP session terminates.

user@PCC# set lsp-cleanup-timer seconds
9. Configure the PCC to accept SPs that are externally provisioned by connected PCEs.
By default, the PCC rejects PCE-initiated LSPs.

user@PCC# set lsp-provisioning
10. Specify the number of unknown messages per minute that the PCC can receive at
maximum after which the PCEP session is closed.

user@PCC# set max-unknown-messages messages-per-minute
The value can range from 1 through 16384, and the default value is 0 (disabled or no
limit).
11. Specify the number of unknown requests per minute that the PCC can receive at
maximum after which the PCEP session is terminated.

user@PCC# set max-unknown-requests requests-per-minute
The value can range from 0 through 16384, and the default value is 5. A value of 0
disables this statement.
12. Configure the PCE type.

user@PCC# set pce-type active stateful
13. Specify the amount of time (in seconds) that the PCC must wait for a reply before
resending a request.

user@PCC# set request-timer seconds
The value can range from 0 through 65535 seconds.

14. Verify and commit the configuration.
user@PCC# show
user@PCC# commit
Sample Output
[edit]
user@PCC# edit protocols pcep

user@PCC# set message-rate-limit 50

user@PCC# set max-provisioned-lsps 16000

user@PCC# edit pce PCE
[edit protocols pcep pce PCE]

user@PCC# set delegation-cleanup-timeout 20

user@PCC# set destination-ipv4-address 192.168.69.58

user@PCC# set destination-port 4189

user@PCC# set lsp-cleanup-timer 50

user@PCC# set lsp-provisioning

user@PCC# set max-unknown-messages 5

user@PCC# set max-unknown-requests 5

user@PCC# set request-timer 50

user@PCC# up

user@PCC# show
message-rate-limit 50;
max-provisioned-lsps 16000;
pce PCE {
lsp-provisioning;
request-timer 50;
max-unknown-requests 5;
max-unknown-messages 5;
delegation-cleanup-timeout 20;
}


user@PCC# commit
commit complete
Documentation
• pcep on page 1657
Example: Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support
for PCE-Controlled Point-to-Multipoint LSPs
This example shows how to configure the Path Computation Client (PCC) with the
capability of reporting point-to-multipoint traffic engineered label-switched paths (TE
LSPs) to a Path Computation Element (PCE).

Requirements
• Three routers that can be a combination of ACX Series, M Series, MX Series, or T Series
routers.
• One virtual machine configured with Virtual Route Reflector (VRR) feature.
• A TCP connection to an external stateful PCE from the VRR.
• Junos OS Release 16.1 or later running on the PCC.
Before you begin:
• Configure MPLS and RSVP-TE.
Overview
After a PCEP session is established between a PCE and a PCC, the PCC reports all the
LSPs in the system to the PCE for LSP state synchronization. This includes PCC-controlled,
PCE-delegated, and PCE-initiated point-to-point LSPs. Starting with Junos OS Release
15.1F6 and 16.1R1, this capability is extended to report point-to-multipoint LSPs as well.
By default, PCE control of point-to-multipoint LSPs is not supported on a PCC. To add

this capability, include the p2mp-lsp-report-capability statement at the [edit protocols
pcep pce pce-name] or [edit protocols pcep pce-group group-id] hierarchy levels.

Topology
Figure 42: Example PCE-Controlled Point-to-Multipoint LSPs

PCE
.1 .2 .1 .2
ge-0 / 0/0 1.2.4.0/30 ge-0 / 0/2 ge-0 / 0/0 2.3.4.0/30 ge-0 / 0/3
4.5.0.1/30 ge-0 / 0/1 1.2.3.0/30 ge-0 / 0/5 ge-0 / 0/4 2.3.1.0/30 ge-0 / 0/1
em1 1.4.0.1/30 PCC R1 R2
ge-0/0/4 ge-0 / 0/2 1.2.2.0/30 ge-0 / 0/3 ge-0 / 0/8 2.3.5.0/30 ge-0 / 0/2
em2 ge-0 / 0/3 1.2.5.0/30 ge-0 / 0/6 ge-0 / 0/9 2.3.2.0/30 ge-0 / 0/4
1.4.0.2/30
R3 ge-0 / 0/5 1.2.1.0/30 ge-0 / 0/7 ge-0 / 1/0 2.3.3.0/30 ge-0 / 0/5
(VRR)
ge-0 / 0/6 1.2.0.0/30 ge-0 / 0/1 ge-0 / 1/1 2.3.0.0/30 ge-0 / 0/0
g043463
lo0= lo0= lo0=
128.102.180.228/32 128.102.180.202/32 128.102.177.16/32
In this example, PCC is the ingress router, Router R1 is the transit router, and Router R2
is the egress router. PCC is connected to a Virtual Route Reflector (VRR) that is connected
to a PCE. There are many point-to-multipoint interfaces between PCC, Router R1, and
Router R2.
The reporting of point-to-multipoint LSPs is executed as follows:
1. If Router PCC is configured with point-to-point and point-to-multipoint LSPs without

the support for point-to-multipoint reporting capability, only the point-to-point LSPs
are reported to the connected PCE. By default, a PCC does not support
point-to-multipoint LSP reporting capability.
2. When Router PCC is configured with point-to-multipoint LSP reporting capability,

PCC first advertises this capability to PCE through a report message.
3. By default, a PCE provides support for point-to-multipoint LSP capability. On receiving

the PCC’s advertisement for point-to-multipoint LSP capability, the PCE in return
advertises its capability to the PCC.
4. On receiving the PCE’s advertisement of the point-to-multipoint capability, PCC

reports all branches of point-to-multipoint LSPs to the PCE using the update message.
5. Once all the LSPs are reported to the PCE, LSP state is synchronized between the
PCE and PCC.
Configuration
level.



set protocols mpls lsp-external-controller pccd pce-controlled-lsp
pcc_delegated_no_cspf_* label-switched-path-template lsp_template_no_cspf
pce_initiated_no_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf
pce_initiated_loose_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf
set protocols mpls traffic-engineering database import policy TE
set protocols mpls admin-groups violet 1
set protocols mpls admin-groups indigo 2
set protocols mpls admin-groups blue 3
set protocols mpls admin-groups green 4
set protocols mpls admin-groups yellow 5
set protocols mpls admin-groups orange 6
set protocols mpls label-switched-path lsp_template_no_cspf template
set protocols mpls label-switched-path lsp_template_no_cspf no-cspf
set protocols mpls label-switched-path lsp1-pcc to 128.102.177.16
set protocols mpls label-switched-path lsp2-pcc to 128.102.177.16
set protocols mpls label-switched-path lsp2-pcc lsp-external-controller pccd
set protocols mpls path loose-path 1.2.3.2 loose
set protocols mpls path strict-path 1.2.3.2 strict
set protocols mpls path strict-path 2.3.3.2 strict
set protocols mpls path path-B
set protocols mpls path path-C
set protocols mpls interface ge-0/0/6.0 admin-group violet
set protocols mpls interface ge-0/0/5.0 admin-group indigo
set protocols mpls interface ge-0/0/2.0 admin-group blue
set protocols mpls interface ge-0/0/1.0 admin-group green
set protocols mpls interface ge-0/0/0.0 admin-group yellow
set protocols mpls interface ge-0/0/3.0 admin-group orange
set protocols bgp group northstar type internal
set protocols bgp group northstar local-address 128.102.180.228
set protocols bgp group northstar family traffic-engineering unicast
set protocols bgp group northstar export TE
set protocols bgp group northstar neighbor 128.102.180.215


set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p
set protocols pcep pce pce1 local-address 10.102.180.228
set protocols pcep pce pce1 destination-ipv4-address 10.102.180.246
set protocols pcep pce pce1 destination-port 4189
set protocols pcep pce pce1 pce-type active
set protocols pcep pce pce1 pce-type stateful
set protocols pcep pce pce1 lsp-provisioning
set protocols pcep pce pce1 lsp-cleanup-timer 0
set protocols pcep pce pce1 delegation-cleanup-timeout 60
set protocols pcep pce pce1 p2mp-lsp-report-capability
set policy-options policy-statement TE term 1 from family traffic-engineering
set policy-options policy-statement TE term 1 then accept




R3 set interfaces em0 unit 0 family inet address 10.102.180.215/19

set interfaces em1 unit 0 family inet address 4.5.0.1/30

set interfaces em2 unit 0 family inet address 1.4.0.2/30
set interfaces em2 unit 0 family mpls
set protocols topology-export
set protocols mpls lsp-external-controller pccd
set protocols mpls traffic-engineering database import igp-topology
set protocols mpls traffic-engineering database import policy TE
set protocols bgp group northstar type internal
set protocols bgp group northstar local-address 128.102.180.215
set protocols bgp group northstar family traffic-engineering unicast
set protocols bgp group northstar neighbor 128.102.180.228
set protocols ospf area 0.0.0.0 interface em2.0 interface-type p2p
set policy-options policy-statement TE from family traffic-engineering
set policy-options policy-statement TE then accept
Mode.
To configure the PCC router:
1. Configure the interfaces of Router PCC. To enable MPLS, include the protocol family
on the interface so that the interface does not discard incoming MPLS traffic.
[edit interfaces]






2. Configure the autonomous system number for Router PCC.

user@PCC# set autonomous-system 100
3. Enable RSVP on all interfaces of Router PCC, excluding the management interface.
[edit protocols]
4. Enable MPLS on all the interfaces of Router PCC, excluding the management
interface.
[edit protocols]
5. Configure a dynamic LSP and disable automatic path computation for the LSP.
[edit protocols]
user@PCC# set mpls label-switched-path lsp_template_no_cspf template
user@PCC# set mpls label-switched-path lsp_template_no_cspf no-cspf
6. Configure point-to-multipoint LSPs and define external path computing entity for
the LSP.
[edit protocols]
user@PCC# set mpls label-switched-path lsp1-pcc to 128.102.177.16
user@PCC# set mpls label-switched-path lsp2-pcc to 128.102.177.16
user@PCC# set mpls label-switched-path lsp2-pcc lsp-external-controller pccd
7. Enable external path computing for the MPLS LSPs and assign a template for
externally provisioned LSPs.
[edit protocols]
user@PCC# set mpls lsp-external-controller pccd pce-controlled-lsp
pcc_delegated_no_cspf_* label-switched-path-template lsp_template_no_cspf
pce_initiated_no_ero_no_cspf_* label-switched-path-template
lsp_template_no_cspf
pce_initiated_loose_ero_no_cspf_* label-switched-path-template
lsp_template_no_cspf
8. Configure the LSPs that have local control and are overridden by the PCE-provided
LSP parameters.
[edit protocols]
user@PCC# set mpls path loose-path 1.2.3.2 loose
user@PCC# set mpls path strict-path 1.2.3.2 strict
user@PCC# set mpls path strict-path 2.3.3.2 strict
user@PCC# set mpls path path-B
user@PCC# set mpls path path-C

9. Configure MPLS administrative group policies for constrained-path LSP computation.
[edit protocols]
user@PCC# set mpls admin-groups violet 1
user@PCC# set mpls admin-groups indigo 2
user@PCC# set mpls admin-groups blue 3
user@PCC# set mpls admin-groups green 4
user@PCC# set mpls admin-groups yellow 5
user@PCC# set mpls admin-groups orange 6
10. Assign the configured administrative group policies to Router PCC interfaces.
[edit protocols]
user@PCC# set mpls interface ge-0/0/6.0 admin-group violet
user@PCC# set mpls interface ge-0/0/5.0 admin-group indigo
user@PCC# set mpls interface ge-0/0/2.0 admin-group blue
user@PCC# set mpls interface ge-0/0/1.0 admin-group green
user@PCC# set mpls interface ge-0/0/0.0 admin-group yellow
user@PCC# set mpls interface ge-0/0/3.0 admin-group orange
11. Configure a traffic engineering database (TED) import policy.
[edit protocols]
user@PCC# set mpls traffic-engineering database import policy TE
12. Configure a BGP internal group.
[edit protocols]
user@PCC# set bgp group northstar type internal
user@PCC# set bgp group northstar local-address 128.102.180.228
user@PCC# set bgp group northstar neighbor 128.102.180.215
13. Configure traffic engineering for BGP and assign the export policy.
[edit protocols]
user@PCC# set bgp group northstar family traffic-engineering unicast
user@PCC# set bgp group northstar export TE
14. Configure OSPF area 0 on all the point-to-multipoint interfaces of Router PCC.
[edit protocols]
user@PCC# set ospf area 0.0.0.0 interface lo0.0
user@PCC# set ospf area 0.0.0.0 interface ge-0/0/6.0
15. Configure OSPF area 0 on the point-to-point interface of Router PCC.
[edit protocols]
user@PCC# set ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p

16. Enable traffic engineering for OSPF.
[edit protocols]
user@PCC# set ospf traffic-engineering
17. Define the PCE that Router PCC connects to, and configure the the PCE parameters.
[edit protocols]
user@PCC# set pcep pce pce1 local-address 10.102.180.228
user@PCC# set pcep pce pce1 destination-ipv4-address 10.102.180.246
user@PCC# set pcep pce pce1 destination-port 4189
user@PCC# set pcep pce pce1 pce-type active
user@PCC# set pcep pce pce1 pce-type stateful
user@PCC# set pcep pce pce1 lsp-provisioning
user@PCC# set pcep pce pce1 lsp-cleanup-timer 0
user@PCC# set pcep pce pce1 delegation-cleanup-timeout 60
18. Configure Router PCC to enable point-to-multipoint LSP capability for external
path computing.
[edit protocols]
set pcep pce pce1 p2mp-lsp-report-capability
19. Configure the traffic engineering policy.
user@PCC# set policy-statement TE term 1 from family traffic-engineering
user@PCC# set policy-statement TE term 1 then accept
Results

ge-0/0/0 {
unit 0 {
family inet {
address 1.2.4.1/30;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 1.2.3.1/30;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {

family inet {
address 1.2.2.1/30;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 1.2.5.1/30;
}
family mpls;
}
}
ge-0/0/4 {
unit 0 {
family inet {
address 1.4.0.1/30;
}
family mpls;
}
}
ge-0/0/5 {
unit 0 {
family inet {
address 1.2.1.1/30;
}
family mpls;
}
}
ge-0/0/6 {
unit 0 {
family inet {
address 1.2.0.1/30;
}
family mpls;
}
}

rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
lsp-external-controller pccd {
pce-controlled-lsp pcc_delegated_no_cspf_* {
label-switched-path-template {
lsp_template_no_cspf;
}
}
pce-controlled-lsp pce_initiated_no_ero_no_cspf_* {

}
}
pce-controlled-lsp pce_initiated_loose_ero_no_cspf_* {
}
}
}
traffic-engineering {
database {
import {
policy TE;
}
}
}
admin-groups {
violet 1;
indigo 2;
blue 3;
green 4;
yellow 5;
orange 6;
}
label-switched-path lsp_template_no_cspf {
template;
no-cspf;
}
label-switched-path lsp1-pcc {
to 128.102.177.16;
}
label-switched-path lsp2-pcc {
to 128.102.177.16;
}
path loose-path {
1.2.3.2 loose;
}
path strict-path {
1.2.3.2 strict;
2.3.3.2 strict;
}
path path-B;
path path-C;
interface all;
admin-group violet;
}
admin-group indigo;
}
admin-group blue;
}
admin-group green;
}

admin-group yellow;
}
admin-group orange;
}
interface fxp0.0 {
disable;
}
}
bgp {
group northstar {
type internal;
family traffic-engineering {
unicast;
}
export TE;
neighbor 128.102.180.215;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0;
interface-type p2p;
}
}
}
pcep {
pce pce1 {
lsp-provisioning;
delegation-cleanup-timeout 60;
p2mp-lsp-report-capability;
}
}
Verification
• Verifying LSP Configuration on the PCC on page 747

• Verifying PCE Configuration on the PCC on page 750

Verifying LSP Configuration on the PCC
Purpose Verify the LSP type and running state of the point-to-multipoint LSP.

Action From operational mode, run the show mpls lsp extensive command.
user@PCC> show mpls lsp extensive

128.102.177.16
From: 128.102.180.228, State: Up, ActiveRoute: 0, LSPname: lsp1-pcc
ActivePath: (primary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
*Primary State: Up
Priorities: 7 0
1.2.1.2 S 2.3.0.2 S
20=Node-ID):
1.2.1.2 2.3.0.2
6 Jul 12 14:44:10.620 Selected as active path
5 Jul 12 14:44:10.617 Record Route: 1.2.1.2 2.3.0.2
4 Jul 12 14:44:10.615 Up
3 Jul 12 14:44:10.175 Originate Call
2 Jul 12 14:44:10.174 CSPF: computation result accepted 1.2.1.2 2.3.0.2
1 Jul 12 14:43:41.442 CSPF failed: no route toward 128.102.177.16[2 times]
Created: Tue Jul 12 14:42:43 2016
128.102.177.16
From: 128.102.180.228, State: Up, ActiveRoute: 0, LSPname: lsp2-pcc
ActivePath: (primary)
LSPtype: Externally controlled - static configured, Penultimate hop popping
LoadBalance: Random
*Primary State: Up
Priorities: 7 0
External Path CSPF Status: external
20=Node-ID):
1.2.4.2 2.3.0.2
50 Jul 12 14:50:14.699 EXTCTRL LSP: Sent Path computation request and LSP
status
49 Jul 12 14:50:14.698 EXTCTRL_LSP: Computation request/lsp status contains:
signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0)
priority setup 7 hold 0
status
status
44 Jul 12 14:49:27.858 EXTCTRL_LSP: Control status became external
43 Jul 12 14:49:03.746 EXTCTRL_LSP: Control status became local
status


status
37 Jul 12 14:46:41.584 Selected as active path
36 Jul 12 14:46:41.565 Record Route: 1.2.4.2 2.3.0.2
35 Jul 12 14:46:41.565 Up
34 Jul 12 14:46:41.374 EXTCTRL_LSP: Applying local parameters with this
signalling attempt
33 Jul 12 14:46:41.374 Originate Call
32 Jul 12 14:46:41.374 CSPF: computation result accepted 1.2.4.2 2.3.0.2
status
status
status
status
status
status
status
15 Jul 12 14:43:42.398 CSPF failed: no route toward 128.102.177.16
status

status
status
status
status
1 Jul 12 14:42:43.258 EXTCTRL LSP: Awaiting external controller connection
Created: Tue Jul 12 14:42:43 2016


Meaning The output displays the lsp2-pcc LSP as the PCE-controlled LSP.
Verifying PCE Configuration on the PCC
Purpose Verify the PCE parameters configuration and PCE state.

Action From operational mode, run the show path-computation-client active-pce command.
user@PCC> show path-computation-client active-pce

PCE pce1
--------------------------------------------
General
PCE IP address : 10.102.180.246
Local IP address : 10.102.180.228
Priority : 0
LSP provisioning allowed : On
P2MP LSP report allowed : On
P2MP LSP update allowed : Off
P2MP LSP init allowed : Off
Counters
PCRpts Total: 12 last 5min: 0 last hour:

12
PCCreates Total: 0 last 5min: 0 last hour: 0
Timers
Local Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer:
0 [s]
Remote Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer:
0 [s]
Errors
PCErr-recv
PCErr-sent
Type: 1 Value: 2 Count: 1
PCE-PCC-NTFS
PCC-PCE-NTFS
Meaning The output displays the active PCE that Router PCC is connected to, and the pce1 PCE
parameters and state.
Documentation


PART 6
Configuring Layer 2 and Layer 3 Features

on ACX Series Routers
• Configuring Layer 2 Bridging and Q-in-Q Tunneling on page 755
• Configuring Layer 2 and Layer 3 Services on page 773
• Configuring Layer 3 VPNs on page 813


CHAPTER 24
Configuring Layer 2 Bridging and Q-in-Q

Tunneling
• Layer 2 Bridge Domains on ACX Series Overview on page 755

• Layer 2 Learning and Forwarding for Bridge Domains Overview on page 759
• Configuring a Bridge Domain on ACX Series Routers on page 760
• Configuring Integrated Routing and Bridging in ACX Series on page 761
• Configuring VLAN Identifiers for Bridge Domains in ACX Series on page 764
• Disabling MAC Learning for Bridge Domains on ACX Series on page 765
• Configuring Static MAC Addresses for Logical Interfaces in a Bridge Domain in ACX
Series on page 766
• Configuring the Size of the MAC Address Table for Bridge Domains in ACX
Series on page 766
• Configuring MAC Address Limits on a Logical Interface on page 767
• Preventing Communication Among Customer Edge Devices as ACX Routers on page 770
• Q-in-Q Tunneling on ACX Series Overview on page 770
• Configuring Q-in-Q Tunneling on ACX Series on page 771
Layer 2 Bridge Domains on ACX Series Overview
A bridge domain is a set of logical interfaces that share the same flooding or broadcast
characteristics. Layer 2 logical interfaces are created by defining one or more logical units
on a physical interface with encapsulation as ethernet-bridge or vlan-bridge. All the
member ports of the bridge domain participate in Layer 2 learning and forwarding. You
can configure one or more bridge domains on ACX Series routers to perform Layer 2
bridging. The Layer 2 bridging functions of ACX Series routers include integrated routing
and bridging (IRB) support for Layer 2 bridging and Layer 3 IP routing on the same
interface. IRB enables you to route packets to another routed interface or to another
bridge domain that has a Layer 3 protocol configured
NOTE: ACX Series routers do not support the creation of bridge domains by
using access and trunk ports.

You can configure E-LAN and E-LINE services by using bridge domains.
On ACX Series routers, you can configure bridge domains by using the following methods:
• Bridge domain without a vlan-id number statement
• Bridge domain with the vlan-id value set to none
• Bridge domain with a single vlan-id
• Bridge domain with a vlan-id-list
NOTE: The Layer 2 CLI configurations and show commands for ACX5048
and ACX5096 routers differ compared to other ACX Series routers. For more
information, see “Understanding Layer 2 Next Generation Mode on ACX5048
and ACX5096 Routers” on page 1167.
When you configure E-LAN and E-LINE services using a bridge domain without a vlan-id
number statement, the bridge domain should explicitly be normalized to a service VLAN
ID and TPID by configuring an input VLAN map under a logical interface. Explicit
normalization is required when a logical interface’s outer VLAN ID and TPID is not the
same as the service VLAN ID and TPID of the service being configured using a bridge
domain.
The following input VLAN map functions are supported in ACX Series routers:
• push—Add a new VLAN tag to the top of the VLAN stack.
• swap—Replace the outer VLAN tag of the VLAN stack in a frame.
• pop—Remove a VLAN tag from the top of the VLAN tag stack.
• swap-swap—Replace both the outer and inner VLAN tags of the frame.
• push-push—Push two VLAN tags on top of the VLAN stack.
NOTE: push-push does not work on ACX Series routers if the incoming
packet already has a VLAN tag.
The following VLAN map functions are not supported in ACX Series routers:
• swap-push—Replace the outer VLAN tag of the frame and add a new VLAN tag to the
top of the VLAN stack.
• pop-swap—Remove the outer VLAN tag of the frame and replace the inner VLAN tag
of the frame.
• pop-pop—Remove both the outer and inner VLAN tags of the frame.

Chapter 24: Configuring Layer 2 Bridging and Q-in-Q Tunneling
NOTE: You can configure Q-in-Q tunneling by explicitly configuring an input

VLAN map with the push function on the ingress logical interface.
A bridge domain can also be created by using aggregated Ethernet interfaces. Aggregated
Ethernet interfaces are considered as logical interfaces in a bridge domain.
The following steps outline the process for bridging a packet received over a Layer 2
logical interface:
1. When a packet is received on a physical port, it is accepted only if the VLAN identifier
of the packet matches the VLAN identifier of one of the logical interfaces configured
on that port.
2. If the bridge domain is configured without a vlan-id number statement, then the VLAN
tags are rewritten based on the input VLAN map configured on the logical interface
and normalized to a service VLAN ID.
3. If the bridge domain is configured with a normalizing VLAN identifier by using the
vlan-id number statement, the VLAN tags of the received packet are compared with
the normalizing VLAN identifier. If the VLAN tags of the packet are different from the
normalizing VLAN identifier, the VLAN tags are rewritten as described in
Table 48 on page 758.
4. If the source MAC address of the received packet is not present in the source MAC
table, it is learned based on the normalizing VLAN identifier.
5. The packet is then forwarded toward one or more outbound Layer 2 logical interfaces
based on the destination MAC address. A packet with a known unicast destination
MAC address is forwarded only to one outbound logical interface.
6. If the bridge domain is configured without a vlan-id number statement, then for each
outbound Layer 2 logical interface, the VLAN tags are rewritten based on the output
VLAN map configured on that logical interface.
7. If the bridge domain is configured with a normalizing VLAN identifier by using the
vlan-id number statement, for each outbound Layer 2 logical interface, the normalizing
VLAN identifier configured for the bridge domain is compared with the VLAN tags
configured on that logical interface. If the VLAN tags associated with an outbound
logical interface do not match the normalizing VLAN identifier configured for the bridge
domain, the VLAN tags are rewritten as described in Table 49 on page 758.
Table 48 on page 758 shows specific examples of how the VLAN tags of packets sent to
the bridge domain are processed and translated, depending on your configuration. “–”
means that the statement is not supported for the specified logical interface VLAN

identifier. “No operation” means that the VLAN tags of the received packet are not
translated for the specified input logical interface.
Table 48: Statement Usage and Input Rewrite Operations for VLAN Identifiers for a Bridge
Domain
VLAN Configurations for Bridge Domain
VLAN Identifier of
Logical Interface vlan-id none vlan-id 200
none No operation push 200
200 pop 200 No operation
1000 pop 1000 swap 1000 to 200
vlan-tags outer 2000 pop 2000, pop 300 pop 2000, swap 300
inner 300 to 200
vlan-tags outer 100 pop 100, pop 400 pop 100, swap 400
inner 400 to 200
vlan-id-range 10-100 – –
Table 49 on page 758 shows specific examples of how the VLAN tags for packets sent
from the bridge domain are processed and translated, depending on your configuration.
“–” means that the statement is not supported for the specified logical interface VLAN
identifier. “No operation” means that the VLAN tags of the outbound packet are not
translated for the specified output logical interface.
Table 49: Statement Usage and Output Rewrite Operations for VLAN Identifiers for a Bridge
Domain
VLAN Configurations for Bridge Domain
VLAN Identifier of
Logical Interface vlan-id none vlan-id 200
none no operation pop 200
200 push 200 No operation
1000 push 1000 swap 200 to 1000
vlan-tags outer 2000 push 2000, push 300 swap 200 to 300,
inner 300 push 2000
vlan-tags outer 100 inner 400 push 100, push 400 swap 200 to 400,
push 100
vlan-id-range 10-100 – –

Limitations on Layer 2 bridging—The following Layer 2 bridging limitations apply for ACX
Series Universal Access Routers:
• A bridge domain cannot have two or more logical interfaces that belong to the same
physical interface.
• A bridge domain with dual VLAN ID tag is not supported.
• The maximum number of supported input VLAN maps with TPID swap is 64.
• MAC learning cannot be disabled at a logical interface level.
• MAC limit per logical interface cannot be configured.
Related • Q-in-Q Tunneling on ACX Series Overview on page 770

Documentation
Series on page 766
• Configuring the Size of the MAC Address Table for Bridge Domains in ACX Series on
page 766
Layer 2 Learning and Forwarding for Bridge Domains Overview
When you configure a bridge domain, Layer 2 address learning is enabled by default. The
bridge domain learns unicast media access control (MAC) addresses to avoid flooding
the packets to all the ports in the bridge domain. Each bridge domain creates a source
MAC entry in its source and destination MAC tables for each source MAC address learned
from packets received on the ports that belong to the bridge domain.
NOTE: Traffic is not flooded back onto the interface on which it was received.
You can optionally disable MAC learning either for the entire router or for a specific bridge
domain. You can also configure the following Layer 2 learning and forwarding properties:
• Static MAC entries on logical interfaces
• Size of the MAC address table for the bridge domain
Related • Layer 2 Bridge Domains on ACX Series Overview on page 755

Documentation

Series on page 766
page 766
Configuring a Bridge Domain on ACX Series Routers
A bridge domain must include a set of logical interfaces that participate in Layer 2 learning
and forwarding.
To configure a bridge domain, include the following statements:
[edit]
bridge-domains {
bridge-domain-name {
vlan-id (none | number);
vlan-id-list [ vlan-id-numbers ];
}
}
You cannot use the slash (/) character in bridge domain names. If you do, the configuration
does not commit and an error is generated.
For the vlan-id statement, you can specify either a valid VLAN identifier or none.
To include one or more logical interfaces in the bridge domain, specify an interface name
for an Ethernet interface you configured at the [edit bridge-domains bridge-domain-name]
hierarchy level.
To configure a layer 2 logical interface to be included in a bridge domain, you can either
include the encapsulation vlan-bridge statement under the logical interface, or the
encapsulation ethernet-bridge statement under the physical interface.
NOTE: A maximum of 1000 logical interfaces can be configured on a physical

interface. You can configure a maximum of 3000 bridge domains on an ACX
Series router.

Documentation

Series on page 766
page 766
Configuring Integrated Routing and Bridging in ACX Series
Integrated routing and bridging (IRB) provides simultaneous support for Layer 2 bridging
and Layer 3 routing on the same interface. IRB enables you to route packets to another
routed interface or to another bridge domain that has an IRB interface configured. You
configure a logical routing interface by including the irb statement at the [edit interfaces]
hierarchy level and include that interface in the bridge domain. For more information
about how to configure a routing interface, see the Junos OS Network Interfaces Library
NOTE: You can include only one routing interface in a bridge domain.
The following are the list of features supported for IRB:
• Family inet, inet6, and iso are supported on an IRB interface.
• Routing protocols supported on an IRB interface are BGP, ISIS, OSPF, RIP, IGMP, and
PIM.
• DHCP Relay with option 82 is supported on an IRB interface.
• IRB can be added in a VRF routing instance.
• VRRP is supported on an IRB inteface.
• Bidirectional Forwarding Detection (BFD) protocol is supported on an IRB interface.
• The following Class-of-Service configurations are supported on an IRB interface:
• The IRB classifiers and rewrite on routed packets.
• Fixed classifier can be applied on an IRB logical interface.
• Firewall filters (multifield filter) can be used to assign forwarding class and loss
priority. You should define a family inet or inet6 filter and apply it as the input filter
on an IRB logical interface under family inet.
NOTE: physical-interface-filter is not supported for family inet6 filter on

IRB logical interface.

• Re-write can be applied only at the IRB interface level.
• dscp, inet-precedence, ieee-802.1, and ieee-802.1ad values can be rewritten.
ACX routers do not support MPLS families on IRB.
IRB can be configured under the following hierarchies:
• [edit intefaces irb interface_type] hierarchy level
• disable—Disables the interface
• gratuitous-arp-reply—Enables gratuitous ARP reply
• hold-time—Hold time for link up and link down
• mtu—Maximum transmit packet size (256..9192)
• no-gratuitous-arp-reply—Does not enable gratuitous ARP reply
• no-gratuitous-arp-request—Ignores gratuitous ARP request
• [edit interfaces irb.unit family (inet | inet6 | iso)] hierarchy level
• [edit bridge-domains routing-interface interface irb.unit] hierarchy level
• [edit routing-instances instance-type vrf] hierarchy level
• [edit protocols (bgp | isis | ospf | rip | igmp | pim) interface irb.unit] hierarchy level
• [edit class-of-service interfaces irb]] hierarchy level
In ACX5048 and ACX5096 routers, you can configure IRB at the [edit vlans vlan-name]
l3-interface irb.unit; level.
To configure a bridge domain with IRB support, include the following statements:
[edit]
bridge-domains {
domain-type bridge;
routing-interface routing-interface-name;
vlan-id (none | number);
vlan-tags outer number inner number;
}
}
For each bridge domain that you configure, specify a bridge-domain-name. You must also
specify the value bridge for the domain-type statement.
For the vlan-id statement, you can specify either a valid VLAN identifier or the none option.

The vlan-tags statement enables you to specify a pair of VLAN identifiers; an outer tag
and an inner tag.
NOTE: For a single bridge domain, you can include either the vlan-id statement
or the vlan-tags statement, but not both.
To include one or more logical interfaces in the bridge domain, specify the interface-name
for each Ethernet interface to include that you configured at the [edit interfaces] hierarchy
level.
NOTE: A maximum of 4000 active logical interfaces are supported on a

bridge domain configured for Layer 2 bridging.
To associate a routing interface with a bridge domain, include the

routing-interface routing-interface-name statement and specify a routing-interface-name
you configured at the [edit interfaces irb] hierarchy level. You can configure only one
routing interface for each bridge domain. For more information about how to configure
logical and routing interfaces, see the Junos OS Network Interfaces Library for Routing
Devices.
In Junos OS Release 9.0 and later, IRB interfaces are supported for multicast snooping.
For more information about multicast snooping, see the Multicast Protocols Feature Guide.
NOTE: When you configure multiple IRB logical interfaces, all the IRB logical
interfaces share the same MAC address.
The following is a sample configuration for IRB over bridge domain:
[edit]
interfaces {
ge-1/0/0 {
unit 0 {
vlan-id 100;
}
}
}
ge-1/0/1 {
unit 0 {
vlan-id 100;
}
}
}

irb {
unit 0 {
family inet {
address 10.0.1.2/24 {
}
}
}
}
bridge-domains {
bd {
domain-type bridge;
vlan-id none;
routing-interface irb.0;
}
}
Related
Documentation
Configuring VLAN Identifiers for Bridge Domains in ACX Series
You can configure VLAN identifiers for a bridge domain for normalization in the following
ways:
• Configure VLAN mapping by using the input-vlan-map and the output-vlan-map

statements at the [edit interfaces interface-name] hierarchy level.
• Configure an implicit normalizing VLAN identifier under the bridge domain by using the
vlan-id statement at the [edit bridge-domains bridge-domain-name] hierarchy level.
NOTE: You cannot configure VLAN mapping by using the input-vlan-map and
output-vlan-map statements if you configure a normalizing VLAN identifier
for a bridge domain by using the vlan-id statement.
You can use the vlan-id-list [ vlan-id-numbers ] statement to configure bridging for multiple
VLANs. Configuring this statement creates a bridge domain for:
• Each VLAN listed—for example, vlan-id-list [ 100 200 300 ]
• Each VLAN in a range—for example, vlan-id-list [ 100-200 ]
• Each VLAN in a list and range combination—for example, vlan-id-list [ 50, 100-200,
300 ]

Documentation

Series on page 766
page 766
Disabling MAC Learning for Bridge Domains on ACX Series
You can disable MAC learning in a bridge domain. Disabling dynamic MAC learning
prevents the bridge domain from learning source MAC addresses.
To disable MAC learning in a bridge domain, include the no-mac-learning statement at

the [edit bridge-domains bridge-domain-name bridge-options] hierarchy level:
[edit]
bridge-domains {
bridge-options {
no-mac-learning;
}
}
}
NOTE: When you disable MAC learning, source MAC addresses are not
dynamically learned, and any packets sent to these source addresses are
flooded into the bridge domain.

Documentation
Series on page 766
page 766

Configuring Static MAC Addresses for Logical Interfaces in a Bridge Domain in ACX
Series
You can manually add static MAC entries for the logical interfaces in a bridge domain.
You can specify one or more static MAC addresses for each logical interface.
To add a static MAC address for a logical interface in a bridge domain, include the
static-mac mac-address statement at the [edit bridge-domains bridge-domain-name
bridge-options interface interface-name] hierarchy level.
[edit]
bridge-domains {
bridge-options {
static-mac mac-address {
}
}
}
}
}

Documentation
page 766
Configuring the Size of the MAC Address Table for Bridge Domains in ACX Series
You can modify the size of the MAC address table for each bridge domain. The default
table size is 5120 addresses per bridge domain. The minimum you can configure is 1
address, and the maximum is 32,000 addresses.
If the MAC table limit is reached, new addresses can no longer be added to the table.
NOTE: Unused MAC addresses are removed from the MAC address table
automatically. This frees space in the table thereby allowing new entries to
be added.

To modify the size of the MAC table, include the mac-table-size limit statement at the
[edit bridge-domains bridge-domain-name bridge-options] hierarchy level:
[edit]
bridge-domains {
bridge-options {
mac-table-size limit {
packet-action drop;
}
}
}
}
NOTE: The mac-table-size CLI statement is not supported on ACX5048 and

ACX5096 routers.

Documentation
Series on page 766
Configuring MAC Address Limits on a Logical Interface
You can configure a limit on the number of MAC addresses learned from a specific logical
interface. This feature allows the MAC address table space to be distributed among
different logical interfaces thereby avoiding congestion. The MAC address limit can be
applied for both VLAN and VPLS routing instances and by default the MAC limit depends
on the profile configured. You can limit MAC addresses for a bridge domain and a logical
interface at the same time.
NOTE: MAC limiting is supported only on ACX5000 Series routers.
• Configuring MAC Address limit on page 768

• Configuring MAC Address Limits for VLANs on page 768
• Configuring MAC Address Limits for VPLS on page 768
• CLI Commands to Configure MAC Address Limits on page 769

Configuring MAC Address limit

You can configure the MAC Address limit by enabling the set protocols l2-learning
global-no-hw-mac-learning CLI command.
The following is an example to configure and enable MAC address limit:
[edit protocols]
l2-learning {
global-no-hw-mac-learning;
}
Configuring MAC Address Limits for VLANs

To configure a limit for the number of MAC addresses learned from each logical interface
in a VLAN, include the interface-mac-limit limit statement at the [edit vlans vlan-name]
hierarchy level. To limit the MAC addresses on a specific logical interface of the VLAN,
include the interface-mac-limit limit statement at the [edit vlans vlan-name interface
interface-name] hierarchy level.
The following is an example to configure a limit for the number of MAC addresses learned
on a logical interface in a VLAN:
[edit vlans]
vlan10 {
switch-options {
interface-mac-limit {
10;
}
}
20;
}
}
}
Configuring MAC Address Limits for VPLS

To configure a limit for the number of MAC addresses learned from each logical interface
in VPLS routing instance, include the interface-mac-limit limit statement at the [edit
routing-instances routing-instance-name protocols vpls] hierarchy level. To limit the MAC
addresses on a specific logical interface of the VPLS instance, include the
interface-mac-limit limit statement at the [edit routing-instances routing-instance-name
protocols vpls interface interface-name] hierarchy level
The following is an example to configure a limit for the number of MAC addresses learned
on a logical interface in VPLS routing instance:
[routing-instance]
v1 {
protocols {

vpls {
10;
}
20;
}
}
}
}
}
If you have configured interface MAC address limit for the logical interface in a bridge
domain and global MAC address limit for a bridge domain, then the interface MAC address
limit is considered. The following example shows two MAC address limits configured on
the interface ge-0/0/3.5 with global value as 50 and local as 30. In this case, the MAC
address limit of 30 is considered for the interface ge-0/0/3.5 in the bridge domain.
vlan20 {
switch-options {
50;
}
30;
}
}
}
}
CLI Commands to Configure MAC Address Limits

The following CLI commands are used for configuring for MAC limiting:
• set protocols l2-learning global-no-hw-mac-learning—Command to change the

hardware-based MAC learning to software-based MAC learning mode.
• set vlans vlan-name switch-options interface-mac-limit limit—Command to configure

the MAC address limit for each logical interface in a VLAN. The limit is applied to all
logical interfaces belonging to the VLAN for which a separate interface MAC address
limit is not configured.
• set vlans vlan-name switch-options interface interface-name interface-mac-limit

limit—Command to configure the interface MAC address limit for a logical interface in
a VLAN. The limit is applied to a specific logical interface in the VLAN for which it is
configured.
• set routing-instances routing-instance-name protocols vpls interface-mac-limit

limit—Command to configure the MAC address limit for each logical interface in the

VPLS routing instance. This limit is applied to all logical interfaces belonging to the
VPLS for which the separate interface MAC address limit is not configured.
• set routing-instances routing-instance-name protocols vpls interface interface-name

interface-mac-limit limit—Command to configure the interface MAC address limit for
a logical interface in the VPLS. This limit is applied to a specific logical interface in the
VPLS for which it is configured.
Related
Documentation
Preventing Communication Among Customer Edge Devices as ACX Routers
In a bridge domain, when a frame is received from a CE interface, it is flooded to the other
CE interfaces and all of the provider edge (PE) interfaces if the destination MAC address
is not learned or if the frame is either broadcast or multicast. If the destination MAC
address is learned on another CE device, such a frame is unicasted to the CE interface
on which the MAC address is learned. This might not be desirable if the service provider
does not want CE devices to communicate with each other directly.
To prevent CE devices from communicating directly, include the no-local-switching

statement at the [edit bridge-domains bridge-domain-name] hierarchy level. Configure
the logical interfaces in the bridge domain as core-facing (PE interfaces) by including
the core-facing statement at the [edit interfaces interface-nameunit logical-unit-number
family family] hierarchy level to specify that the VLAN is physically connected to a
core-facing ISP router and ensures that the network does not improperly treat the interface
as a client interface. When specified, traffic from one CE interface is not forwarded to
another CE interface.
For the no-local-switching option , integrated routing and bridging (IRB) configured on a
bridge domain with this option enabled is not treated as a designated CE or PE interface.
Traffic arriving from a CE or PE interface can navigate towards IRB and traffic that reaches
in the input direction to the IRB can pass out of a CE or PE interface. The disabling of
local switching achieves the functionality of split-horizon in a bridge domain. If
no-local-switching is configured in a bridge domain, , then traffic cannot flow between
CE and CE interfaces. This stoppage of trafic flow includes known unicast and multicast,
unknown unicast and multicast, and broadcast traffic. However, traffic continues to be
transmitted between CE and PE interfaces, and PE and PE interfaces..
Related • no-local-switching on page 1637

Documentation
Q-in-Q Tunneling on ACX Series Overview
Q-in-Q tunneling allows service providers to create a Layer 2 Ethernet connection between
two customer sites. Providers can segregate different customers’ VLAN traffic on a link
(for example, if the customers use overlapping VLAN IDs) or bundle different customer
VLANs into a single service VLAN. Service providers can use Q-in-Q tunneling to isolate

customer traffic within a single site or to enable customer traffic flows across geographic
locations.
Q-in-Q tunneling adds a service VLAN tag before the customer’s 802.1Q VLAN tags. The
Juniper Networks Junos operating system implementation of Q-in-Q tunneling supports
the IEEE 802.1ad standard.
In Q-in-Q tunneling, as a packet travels from a customer VLAN (C-VLAN) to a service

provider's VLAN (S-VLAN), another 802.1Q tag for the appropriate S-VLAN is added
before the C-VLAN tag. The C-VLAN tag remains and is transmitted through the network.
As the packet exits from the S-VLAN space, in the downstream direction, the S-VLAN
802.1Q tag is removed.
In ACX Series routers, you can configure Q-in-Q tunneling by explicitly configuring an
input VLAN map with push function on customer facing interfaces in a bridge domain.
You can configure Q-in-Q tunneling on aggregated Ethernet interface by configuring

input and output VLAN map.

Documentation
Series on page 766
page 766
Configuring Q-in-Q Tunneling on ACX Series
To configure Q-in-Q tunneling, you need to configure the logical interface connected to
the customer network (user-to-network interfaces (UNI)) and the logical interface
connected to the service provider network (network-to-network interface (NNI)).
The following is an example to configure a logical interface connected to a customer

network:
[edit]
interface ge-1/0/1 {
flxible-vlan-tagging;
unit 0 {
vlan-id-list 10-20;
input-vlan-map {
push;

vlan-id 500;
}
output-vlan-map pop;
}
}
The following is an example to configure a logical interface connected to a service provider

network:
[edit]
interface ge-1/0/2; {
unit 0 {
vlan-id 500;
}
}
The following is an example to configure the bridge domain:
[edit]
bridge-domains {
qnq-stag-500{
interface ge-1/0/1;
interface ge-1/0/2;
}
}
You can configure Q-in-Q tunneling on aggregated Ethernet interface connected to the
customer network (UNI) and the logical interface connected to the service provider
network (NNI).

Documentation
Series on page 766
page 766

CHAPTER 25
Configuring Layer 2 and Layer 3 Services
• Configuring Interfaces for Layer 2 Circuits Overview on page 774

• Configuring the Address for the Neighbor of the Layer 2 Circuit on page 774
• Configuring the Neighbor Interface for the Layer 2 Circuit on page 774
• Configuring a Community for the Layer 2 Circuit on page 775
• Configuring the Control Word for Layer 2 Circuits on page 775
• Configuring the Encapsulation Type for the Layer 2 Circuit Neighbor Interface on page 777
• Configuring the MTU Advertised for a Layer 2 Circuit on page 777
• Configuring the Protect Interface on page 778
• Configuring the Virtual Circuit ID on page 778
• Configuring the Interface Encapsulation Type for Layer 2 Circuits on page 779
• Configuring Layer 2 Circuits over Both RSVP and LDP LSPs on page 779
• Enabling the Layer 2 Circuit When the MTU Does Not Match on page 780
• Enabling the Layer 2 Circuit When the Encapsulation Does Not Match on page 780
• Configuring Local Interface Switching in Layer 2 Circuits on page 781
• Example: Configuring Layer 2 Circuit Switching Protection on page 783
• Accepting Route Updates with Unique Inner VPN Labels in Layer 3 VPNs on page 785
• Understanding Per-Packet Load Balancing on page 789
• Configuring Per-Packet Load Balancing on page 790
• Configuring Load Balancing Based on MPLS Labels on ACX Series Routers on page 793
• Configuring Load Balancing for Ethernet Pseudowires on page 797
• Configuring Load Balancing Based on MAC Addresses on page 798
• ECMP Flow-Based Forwarding on ACX Series Routers on page 799
• Sample Scenario of H-VPLS on ACX Series Routers for IPTV Services on page 800
• Guidelines for Configuring Unicast RPF on ACX Series Routers on page 803
• Configuring Unicast RPF on ACX Series Routers on page 804
• Verifying Unicast RPF Status on page 808

Configuring Interfaces for Layer 2 Circuits Overview
A Layer 2 circuit or pseudowire is a point-to-point Layer 2 connection transported by

means of MPLS or another tunneling technology on the service provider’s network. Layer
2 circuits are also called pseudowires. A Layer 2 circuit is similar to a circuit cross-connect
(CCC), except that multiple Layer 2 circuits can be transported over a single
label-switched path (LSP) tunnel between two provider edge (PE) routers. In contrast,
each CCC requires a dedicated LSP.
The Junos OS implementation of Layer 2 circuits supports only the remote form of a
Layer 2 circuit; that is, a connection from a local customer edge (CE) router to a remote
CE router.
Related • Configuring the Address for the Neighbor of the Layer 2 Circuit on page 774
Documentation
Configuring the Address for the Neighbor of the Layer 2 Circuit
All the Layer 2 circuits using a particular remote PE router designated for remote CE
routers are listed under the neighbor statement (“neighbor” designates the PE router).
Each neighbor is identified by its IP address and is usually the end-point destination for
the label-switched path (LSP) tunnel transporting the Layer 2 circuit.
To configure a PE router as a neighbor for a Layer 2 circuit, specify the neighbor address
using the neighbor statement:
neighbor address {
...
}
• [edit protocols l2circuit]
Related • Configuring Interfaces for Layer 2 Circuits Overview on page 774

Documentation
Configuring the Neighbor Interface for the Layer 2 Circuit
Each Layer 2 circuit is represented by the logical interface connecting the local provider
edge (PE) router to the local customer edge (CE) router. This interface is tied to the
Layer 2 circuit neighbor configured in “Configuring the Address for the Neighbor of the
Layer 2 Circuit” on page 774.

Chapter 25: Configuring Layer 2 and Layer 3 Services
To configure the interface for a Layer 2 circuit neighbor, include the interface statement:
bandwidth (bandwidth | ctnumber bandwidth);
community community-name;
(control-word | no-control-word);
description text;
encapsulation-type type;
ignore-encapsulation-mismatch;
ignore-mtu-mismatch;
mtu mtu-number;
no-revert;
protect-interface interface-name;
virtual-circuit-id identifier;
}
• [edit protocols l2circuit neighbor address]

Documentation
• Configuring a Community for the Layer 2 Circuit on page 775
• Configuring the Control Word for Layer 2 Circuits on page 775
• Configuring the Protect Interface on page 778
• Configuring the Virtual Circuit ID on page 778
Configuring a Community for the Layer 2 Circuit
To configure a community for a Layer 2 circuit, include the community statement:
community community-name;
• [edit protocols l2circuit neighbor address interface interface-name]

Documentation
• Configuring Policies for Layer 2 Circuits
Configuring the Control Word for Layer 2 Circuits
To emulate the virtual circuit (VC) encapsulation for Layer 2 circuits, a 4-byte control
word is added between the Layer 2 protocol data unit (PDU) being transported and the

VC label that is used for demultiplexing. For most protocols, a null control word consisting
of all zeroes is sent between Layer 2 circuit neighbors.
However, individual bits are available in a control word that can carry Layer 2 protocol
control information. The control information is mapped into the control word, which
allows the header of a Layer 2 protocol to be stripped from the frame. The remaining
data and control word can be sent over the Layer 2 circuit, and the frame can be
reassembled with the proper control information at the egress point of the circuit.
The following Layer 2 protocols map Layer 2 control information into special bit fields in
the control word:
• Frame Relay—The control word supports the transport of discard eligible (DE), forward
explicit congestion notification (FECN), and backward explicit congestion notification
(BECN) information.
NOTE: Frame Relay is not supported on the ACX Series routers.
• ATM AAL5 mode—The control word supports the transport of sequence number
processing, ATM cell loss priority (CLP), and explicit forward congestion indication
(EFCI) information. When you configure an AAL5 mode Layer 2 circuit, the control
information is carried by default and no additional configuration is needed.
• ATM cell-relay mode—The control word supports sequence number processing only.
When you configure a cell-relay mode Layer 2 circuit, the sequence number information
is carried by default and no additional configuration is needed.
The Junos OS implementation of sequence number processing for ATM cell-relay mode
and AAL5 mode is not the same as that described in Sec. 3.1.2 of the IETF draft
Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks. The
differences are as follows:
• A packet with a sequence number of 0 is considered as out of sequence.
• A packet that does not have the next incremental sequence number is considered out
of sequence.
• When out-of-sequence packets arrive, the sequence number in the Layer 2 circuit
control word increments by one and becomes the expected sequence number for the
neighbor.
The Junos OS can typically determine whether a neighboring router supports the control
word. However, if you want to explicitly disable its use on a specific interface, include the
no-control-word statement in the configuration.
Related • Configuring the Neighbor Interface for the Layer 2 Circuit on page 774
Documentation

Configuring the Encapsulation Type for the Layer 2 Circuit Neighbor Interface
You can specify the Layer 2 circuit encapsulation type for the interface receiving traffic
from a Layer 2 circuit neighbor. The encapsulation type is carried in the LDP-signaling
messages exchanged between Layer 2 circuit neighbors when pseudowires are created.
The encapsulation type you configure for each Layer 2 circuit neighbor varies depending
on the type of networking equipment or the type of Layer 2 protocol you have deployed
in your network. If you do not specify an encapsulation type for the Layer 2 circuit, the
encapsulation of the CE device interface is used by default.
Specify the encapsulation type for the Layer 2 circuit neighbor interface by including the
encapsulation-type statement:
encapsulation-type (atm-aal5 | atm-cell | atm-cell-port-mode | atm-cell-vc-mode |

atm-cell-vp-mode | cesop | ethernet | ethernet-vlan | interworking | satop-e1 | satop-e3
| satop-t1 | satop-t3);
You can include this statement at the [edit protocols l2circuit neighbor address interface
interface-name] hierarchy levels:
Related • Enabling the Layer 2 Circuit When the Encapsulation Does Not Match on page 780
Documentation
• Configuring the MTU Advertised for a Layer 2 Circuit on page 777
Configuring the MTU Advertised for a Layer 2 Circuit
By default, the MTU used to advertise a Layer 2 circuit is determined by taking the interface
MTU for the associated physical interface and subtracting the encapsulation overhead
for sending IP packets based on the encapsulation.
However, encapsulations that support multiple logical interfaces (and multiple Layer 2
circuits) rely on the same interface MTU (since they are all associated with the same
physical interface). This can prove to be a limitation for VLAN Layer 2 circuits using the
same Ethernet interface or for Layer 2 circuit DLCIs using the same Frame Relay interface.
This can also affect multivendor environments. For example, if you have three PE devices
supplied by different vendors and one of the devices only supports an MTU of 1500, even
if the other devices support larger MTUs you must to configure the MTU as 1500 (the
smallest MTU of the three PE devices).
You can explicitly configure which MTU is advertised for a Layer 2 circuit, even if the
Layer 2 circuit is sharing a physical interface with other Layer 2 circuits. When you explicitly
configure an MTU for a Layer 2 circuit, be aware of the following:
• An explicitly configured MTU is signaled to the remote PE device. The configured MTU
is also compared to the MTU received from the remote PE device. If there is a conflict,
the Layer 2 circuit is taken down.

• If you configure an MTU for an ATM cell relay interface on an ATM II PIC, the configured
MTU is used to compute the cell bundle size advertised for that Layer 2 circuit, instead
of the default interface MTU.
• A configured MTU is used only in the control plane. It is not enforced in the data plane.
You need to ensure that the CE device for a given Layer 2 circuit uses the correct MTU
for data transmission.
To configure the MTU for a Layer 2 circuit, include the mtu statement at the [edit protocols
l2circuit neighbor address interface interface-name] hierarchy level.
mtu mtu-number;

Documentation
• Configure the Layer 2 Circuit on page 196
Configuring the Protect Interface
You can configure a protect interface for the logical interface linking a virtual circuit to
its destination, whether the destination is remote or local. A protect interface provides
a backup for the protected interface in case of failure. Network traffic uses the primary
interface only so long as the primary interface functions. If the primary interface fails,
traffic is switched to the protect interface. The protect interface is optional.
To configure the protect interface, include the protect-interface statement:
summary section for this statement.
Related • Example: Configuring Layer 2 Circuit Protect Interfaces

Documentation
Configuring the Virtual Circuit ID
You configure a virtual circuit ID on each interface. Each virtual circuit ID uniquely identifies
the Layer 2 circuit among all the Layer 2 circuits to a specific neighbor. The key to
identifying a particular Layer 2 circuit on a PE router is the neighbor address and the virtual
circuit ID. An LDP-FEC-to-label binding is associated with a Layer 2 circuit based on the
virtual circuit ID in the FEC and the neighbor that sent this binding. The LDP-FEC-to-label
binding enables the dissemination of the VPN label used for sending traffic on that Layer 2
circuit to the remote CE device. When an LDP peer sends a Label Withdraw message for
a Layer 2 circuit FEC with a non zero group ID, the Junos OS software sends the Label
Release message with the group ID for the Layer 2 circuit associated with the FEC.
You also configure a virtual circuit ID for each redundant pseudowire. A redundant
pseudowire is identified by the backup neighbor address and the virtual circuit ID.

To configure the virtual circuit ID, include the virtual-circuit-id statement:
virtual-circuit-id identifier;
Related • Configuring Pseudowire Redundancy on the PE Router on page 606

Documentation
Configuring the Interface Encapsulation Type for Layer 2 Circuits
The Layer 2 encapsulation type is carried in the LDP forwarding equivalence class (FEC).
You can configure either circuit cross-connect (CCC) or translational cross-connect
(TCC) encapsulation types for Layer 2 circuits. For more information, see the Junos OS
Network Interfaces Library for Routing Devices.
To configure the interface encapsulation for a Layer 2 circuit, include the encapsulation
statement:
• [edit interfaces interface-name]
Related • Configure the Layer 2 Circuit on page 196

Documentation
Configuring Layer 2 Circuits over Both RSVP and LDP LSPs
You can configure two Layer 2 circuits between the same two routers, and have one
Layer 2 circuit traverse an RSVP LSP and the other traverse an LDP LSP. To accomplish
this, you need to configure two loopback addresses on the local router. You configure
one of the loopback address for the Layer 2 circuit traversing the RSVP LSP. You configure
the other loopback address to handle the Layer 2 circuit traversing the LDP LSP.
You also need to configure a packet switched network (PSN) tunnel endpoint for one of
the Layer 2 circuits. It can be either the Layer 2 circuit traversing the RSVP LSP or the one
traversing the LDP LSP. The PSN tunnel endpoint address is the destination address for
the LSP on the remote router.
To configure the address for the PSN tunnel endpoint, include the psn-tunnel-endpoint
statement:

• [edit protocols l2circuit neighbor address interface interface-name]
By default, the PSN tunnel endpoint for a Layer 2 circuit is identical to the neighbor
address, which is also the same as the LDP neighbor address.
The tunnel endpoints on the remote router do not need to be loopback addresses.
The following example illustrates how you might configure a PSN tunnel endpoint:

neighbor 10.255.0.6 {
psn-tunnel-endpoint 20.20.20.20;
}
}
}
The Layer 2 circuit configured for the t1-0/2/2.0 interface resolves in the inet3 routing
table to 20.20.20.20. This could be either an RSVP route or a static route with an LSP
next hop.
Related • Configuring Logical Units on the Loopback Interface for Routing Instances in Layer 3 VPNs
Documentation
Enabling the Layer 2 Circuit When the MTU Does Not Match
You can configure the Junos OS to allow a Layer 2 circuit to be established even though
the MTU configured on the PE router does not match the MTU configured on the remote
PE router by including the ignore-mtu-mismatch statement at the [edit protocols l2circuit
neighbor address interface interface-name] hierarchy level.
Related • Configuring the MTU Advertised for a Layer 2 Circuit on page 777
Documentation
• Configuring the Media MTU
Enabling the Layer 2 Circuit When the Encapsulation Does Not Match
You can configure the Junos OS to allow a Layer 2 circuit to be established even though
the encapsulation configured on the CE device interface does not match the encapsulation
configured on the Layer 2 circuit interface by including the ignore-encapsulation-mismatch
statement. You can configure the ignore-encapsulation-mismatch statement for the
connection to the remote connection by including the statement at the [edit protocols
l2circuit neighbor address interface interface-name] hierarchy level or for the local
connection by including this statement at the [edit protocols l2circuit local-switching
interface interface-name] hierarchy level.
ignore-encapsulation-mismatch;

Related • Configuring the Encapsulation Type for the Layer 2 Circuit Neighbor Interface on page 777
Documentation
Configuring Local Interface Switching in Layer 2 Circuits
You can configure a virtual circuit entirely on the local router, terminating the circuit on
a local interface. Possible uses for this feature include being able to enable switching
between Frame Relay DLCIs.
To configure a virtual circuit to terminate locally, include the local-switching statement:
local-switching {
description text;
end-interface {
no-revert;
}
no-revert;
}
}
• [edit protocols l2circuit]
• [edit logical-systems logical-system-name protocols l2circuit]
NOTE: ACX Series routers do not support the [edit logical-systems]

hierarchy level.
The following sections describe how to configure local interface switching:
• Configuring the Interfaces for the Local Interface Switch on page 781
• Enabling Local Interface Switching When the MTU Does Not Match on page 782
Configuring the Interfaces for the Local Interface Switch

Local interface switching requires you to configure at least two interfaces:
• Starting interface—Include the interface statement at the [edit protocols l2circuit

local-switching] hierarchy level.
• Ending interface—Include the end-interface statement at the [edit protocols l2circuit

local-switching interface interface-name] hierarchy level.

You can also configure virtual circuit interface protection for each local interface:
• Protect interface for the starting interface—Include the protect-interface statement

at the [edit protocols l2circuit local-switching interface interface-name] hierarchy level.
• Protect interface for the ending interface—Include the protect-interface statement at

the [edit protocols l2circuit local-switching interface interface-name end-interface]
hierarchy level.
For more information about how to configure protect interfaces, see Configuring Interfaces
for Layer 2 Circuits.
Typically, when the primary interface goes down, the pseudowire starts using the protect
interface. By default, when the primary interface comes back online, the interface is
switched-over back from the protect interface to the primary interface. To prevent the
switchover back to the primary interface, unless the primary interface goes down, include
the no-revert statement. This prevents loss of traffic during the switchover.
NOTE: If the protect interface fails, the interface is switched-over back to

the primary interface, irrespective of whether or not the no-revert statement
is included in the configuration.
You can configure the no-revert statement both for the starting interface and the ending
interface.
[edit protocols l2circuit local-switching interface interface-name]

no-revert;
end-interface {
no-revert;
}
NOTE: The protect interface must be configured prior to configuring the

no-revert statement.
Enabling Local Interface Switching When the MTU Does Not Match
You can configure a local switching interface to ignore the MTU configuration set for the
associated physical interface. This enables you to bring up a circuit between two logical
interfaces that are defined on physical interfaces with different MTU values.
To configure the local switching interface to ignore the MTU configured for the physical
interface, include the ignore-mtu-mismatch statement:
• [edit protocols l2circuit local-switching interface interface-name]

• [edit logical-systems logical-system-name protocols l2circuit local-switching interface

interface-name]

hierarchy level.
Example: Configuring Layer 2 Circuit Switching Protection
Unlike Layer 2 circuit protect interfaces (see Example: Configuring Layer 2 Circuit Protect
Interfaces), which provide traffic protection for paths configured between the PE routers
and CE routers, Layer 2 circuit switching protection provides traffic protection for the
paths configured between the PE routers. In the event the path used by a Layer 2 circuit
fails, traffic can be switched to an alternate path (or protection path). Switching protection
is supported for locally switched Layer 2 circuits and provides 1 to 1 protection for each
Layer 2 circuit interface.
When you enable Layer 2 circuit switching protection, each Layer 2 circuit interface
requires the following paths:
• Working path—Used by the Layer 2 circuit when working normally.
• Protection path—Used by the Layer 2 circuit when the working path fails.

Requirements
• ACX5000 Series Routers
• Junos OS Release 15.1X54–D60
Overview
Each working path can be configured using a pseudowire configured through an
intermediate PE router (as shown in Figure 43 on page 784). The protection path provides
failure protection for the traffic flowing between the PE routers. Failures are detected
through the link down trap.
NOTE: Non-stop routing (NSR) and graceful routing engine switchover

(GRES) do not support Layer 2 circuit switching protection.

Topology
In Figure 43 on page 784, there are two paths running between Router PE1 and Router PE2.
One is the working path between Router PE1 and Router PE2. The other is the protection
path between Router PE1 and Router PE3 to Router PE2.
Figure 43: Connection Protection Using a Pseudowire Configured through

Router PE3 as the Protection Path
Configuration
The following section describes how to configure Layer 2 circuit connection protection:
• Configuring Connection Protection Using Another PE Router for the Protection

Path on page 784
Configuring Connection Protection Using Another PE Router for the Protection

Path
Step-by-Step To configure Layer 2 Circuit switching protection as shown in Figure 43 on page 784 on
Procedure Router PE1:
1. Configure the Layer 2 circuit on Router PE1.

user@PE1# set local-switching interface ge-2/0/2.0 connection-protection
user@PE1# set local-switching interface ge-2/0/2.0 backup-neighbor 192.0.2.2
virtual-circuit-id 2
user@PE1# set local-switching interface ge-2/0/2.0 backup-neighbor 192.0.2.2
community example
user@PE1# set local-switching interface ge-2/0/2.0 end-interface interface
ge-2/0/1.0
2. Configure the routing policy on Router PE1.
user@PE1# set policy-statement load-balance then load-balance per-packet
user@PE1# set policy-statement protection-policy term protect from community
example
user@PE1# set policy-statement protection-policy term protect then install-nexthop
lsp-regex lsp-protect-*
3. Configure the routing options on Router PE1.
user@PE1# set forwarding-table export load-balance

Results From configuration mode on Router PE1, confirm your configuration by entering the show
protocols l2circuit, show policy-options, show routing-options commands. If the output
does not display the intended configuration, repeat the configuration instructions in this
example to correct it.
user@host> show protocols l2circuit

local-switching {
connection-protection;
community example;
}
end-interface {
}
}
}
user@host> show policy-options

policy-statement load-balance {
then {
}
}
policy-statement protection-policy {
term protect {
from community example;
then {
install-nexthop lsp-regex lsp-protect-*;
}
}
}
user@host> show routing-options

forwarding-table {
export load-balance;
}
Related • Example: Configuring Layer 2 Circuit Protect Interfaces

Documentation
Accepting Route Updates with Unique Inner VPN Labels in Layer 3 VPNs
For Layer 3 VPNs configured on Juniper Networks routers, Junos OS normally allocates
one inner VPN label for each customer edge (CE)-facing virtual routing and forwarding
(VRF) interface of a provider edge (PE) router. However, other vendors allocate one VPN
label for each route learned over the CE-facing interfaces of a PE router. This practice
increases the number of VPN labels exponentially, which leads to slow system processing
and slow convergence time.
Next-hop chaining (also known as “chained composite next hop”) is a composition

function that concatenates the partial rewrite strings associated with individual next
hops to form a larger rewrite string that is added to a packet. By using this function, the

number of routes with unique inner VPN labels that can be processed by a Juniper
Networks router is increased substantially. Common route update elements associated
with Layer 3 VPNs are combined, reducing the number of route updates and individual
states the Juniper Networks router must maintain, and leading to enhanced scaling and
convergence performance.
NOTE: ACX Series routers supports chained-composite-next-hop ingress CLI

statement at the [edit routing-options forwarding-table] hierarchy level only
for Layer 3 VPNs. The chained-composite-next-hop ingress CLI statement for
Layer 2 services is not supported.
You can configure the router based on the number of VPN labels you want to manage
and on whether or not you want to create chained composite next hops for IPv6 labeled
routes:
• Accepting Up to One Million Layer 3 VPN Route Updates on page 786

• Accepting More Than One Million Layer 3 VPN Route Updates on page 787
• Enabling Chained Composite Next Hops for IPv6 Labeled Unicast Routes on page 789
Accepting Up to One Million Layer 3 VPN Route Updates

For Juniper Networks routers participating in a mixed vendor network with up to one
million Layer 3 VPN labels, include the l3vpn statement at the [edit routing-options
forwarding-table chained-composite-next-hop ingress] hierarchy level. The l3vpn statement
is disabled by default.
NOTE: ACX Series routers do not support chained-composite-next-hop ingress

CLI statement at the [edit routing-options forwarding-table] hierarchy level.
BEST PRACTICE: We recommend that you configure the l3vpn statement

whenever you have deployed Juniper Networks routers in mixed vendor
networks of up to one million routes to support Layer 3 VPNs.
Because using this statement can also enhance the Layer 3 VPN performance
of Juniper Networks routers in networks where only Juniper Networks routers
are deployed, we recommend configuring the statements in these networks
as well.
You can configure the l3vpn statement on the following routers:
• ACX Series routers
• MX Series routers
• M120 routers

• M320 routers with one or more Enhanced III FPCs
• T Series routers (for Junos OS Release 10.4 and later)
To accept up to one million Layer 3 VPN route updates with unique inner VPN labels,
configure the l3vpn statement. This statement is supported on indirectly connected PE
routers only. Configuring this statement on a router that is directly connected to a PE
router provides no benefit. You can configure the l3vpn statement on a router with a mix
of links to both directly connected and indirectly connected PE routers.
NOTE: You cannot configure the l3vpn statement and sub-statements at

same time that you have configured the vpn-unequal-cost statement.
To configure the router to accept up to one million Layer 3 VPN route updates with unique
inner VPN labels:
1. Include the l3vpn statement.
[edit routing-options forwarding-table chained-composite-next-hop ingress]

user@host>set l3vpn
2. To enhance memory allocation to support a larger number of Layer 3 VPN labels,

include the vpn-label statement.
[edit chassis memory-enhanced]

user@host>set vpn-label
NOTE: The vpn-label statement does not provide any functional changes
when used on the MX Series routers. You can omit the configuration of
this statement on MX Series routers.
For more information about configuring more memory for Layer 3 VPN labels, see the
Junos OS Administration Library.
After you have configured the l3vpn statement, you can determine whether or not a Layer
3 VPN route is a part of a composite next hop by examining the display output of the
following commands:
• show route route-value extensive
• show route forwarding-table destination destination-value extensive
Accepting More Than One Million Layer 3 VPN Route Updates

For Juniper Networks routers participating in a mixed vendor network with more than one
million Layer 3 VPN labels, include the extended-space statement at the [edit
routing-options forwarding-table chained-composite-next-hop ingress l3vpn] hierarchy
level. The extended-space statement is disabled by default.

NOTE: The chained-composite-next-hop ingress and extended-space

statements are not supported on ACX Series routers.
BEST PRACTICE: We recommend that you configure the extended-space

statement in mixed vendor networks containing more than one million routes
to support Layer 3 VPNs. However, b
Because using this statements can also enhance the Layer 3 VPN performance
are deployed, we recommend configuring the statement in these networks
as well.
Using the extended-space statement can double the number of routes with unique inner
VPN labels that can be processed by a Juniper Networks router. However, when configuring
such very large-scale Layer 3 VPN scenarios, keep the following guidelines in mind:
• The extended-space statement is supported only on MX Series routers containing only

MPCs.
• The chassis must be configured to use the enhanced-ip option in network services
mode.
For more information about configuring chassis network services, see the Junos OS
Administration Library.
• Ensure that you configure per-packet load balancing for associated policies.
For more information about configuring policies, see the Routing Policies, Firewall Filters,
and Traffic Policers Feature Guide.
BEST PRACTICE: We strongly recommend using 64-bit routing engines

running 64-bit Junos OS to support Layer 3 VPN prefixes with unique inner
VPN labels at higher scale.
To configure the router to accept more than one million Layer 3 VPN route updates with
unique inner VPN labels:

user@host>set l3vpn
2. Include the extended-space statement.
[edit routing-options forwarding-table chained-composite-next-hop ingress l3vpn]

user@host> set extended-space
3. Configure chassis network services for enhanced mode.

[edit chassis]
user@host>set network-services enhanced-ip
NOTE: A router reboot might be required. See Network Services Mode

Overview in the Junos OS Administration Library for details.
After you have completed the configuration, you can determine whether or not a Layer
following commands:
Enabling Chained Composite Next Hops for IPv6 Labeled Unicast Routes
You can enable chained composite next hops for IPv6 labeled unicast routes by
configuring the labeled-bgp and inet6 statements:
• To enable chained composite next hops for inet6 labeled unicast routes, include the
inet6 statement at the [edit routing-options forwarding-table
chained-composite-next-hop ingress labeled-bgp] hierarchy level. This statement is
disabled by default.
Related • Chained Composite Next Hops for Transit Devices for VPNs
Documentation
• Configuring the Junos OS to Allocate More Memory for Routing Tables, Firewall Filters,
and Layer 3 VPN Labels
• Network Services Mode Overview
• Configuring Junos OS to Run a Specific Network Services Mode in MX Series Routers
Understanding Per-Packet Load Balancing
By default, when there are multiple equal-cost paths to the same destination for the
active route, Junos OS uses a hash algorithm to choose one of the next-hop addresses
to install in the forwarding table. Whenever the set of next hops for a destination changes
in any way, the next-hop address is rechosen using the hash algorithm.
You can configure Junos OS so that, for the active route, all next-hop addresses for a
destination are installed in the forwarding table. This feature is called per-packet load
balancing. You can use load balancing to spread traffic across multiple paths between
routers.
Figure 44 on page 790 shows a simple load balancing scenario. Device R1 is in AS 65000
and is connected to both Device R2 and Device R3, which are in AS 65001. Device R1 can
be configured to load balance traffic across the two links.

Figure 44: Simple Load Balancing Scenario
AS 6 4 501
R2
10.0 .1.1
AS 6 4 500 10.0 .2.2
R1 10.0 .1.2
10.0.0 .1
10.0 .2.1
10.0.0 .2
R3
g040 87 5
Starting in Junos OS 13.3R3, for MX Series 3D Universal Edge routers with modular port
concentrators (MPCs) only, you can configure consistent load balancing, which prevents
the reordering of all flows to active paths in an equal-cost multipath (ECMP) group when
one or more next-hop paths fail. Only flows for paths that are inactive are redirected to
another active next-hop path. Flows mapped to servers that remain active are maintained.
This feature applies only to external BGP peers.
Related • Example: Load Balancing BGP Traffic

Documentation
• Configuring Per-Packet Load Balancing on page 790
• Configuring Load Balancing Based on MPLS Labels
• Configuring Load Balancing Based on MAC Addresses on page 798
• Configuring VPLS Load Balancing Based on IP and MPLS Information
• Configuring VPLS Load Balancing on MX Series 3D Universal Edge Routers
• Configuring Consistent Load Balancing for ECMP Groups
Configuring Per-Packet Load Balancing
To configure per-packet load balancing as described in “Understanding Per-Packet Load

Balancing” on page 789, include the load-balance per-packet statement either as an option
of the route-filter statement at the [edit policy-options policy-statement policy-name term
term-name from] hierarchy level:
[edit policy-options policy-statement policy-name term term-name from]

route-filter destination-prefix match-type {
}

or at the [edit policy-options policy-statement policy-name term term-name then] hierarchy

level:
[edit policy-options policy-statement policy-name term term-name then]

To complete the configuration you must apply the routing policy to routes exported from
the routing table to the forwarding table, by including the policy name in the list specified
by the export statement:
• [edit routing-options forwarding-table]
• [edit logical-systems logical-system-name routing-options forwarding-table]
By default, the software ignores port data when determining flows. To enable per-flow
load balancing, you must set the load-balance per-packet action in the routing policy
configuration.
To include port data in the flow determination, include the family inet statement at the
[edit forwarding-options hash-key] hierarchy level:
[edit forwarding-options hash-key]

family inet {
layer-3;
layer-4;
}
If you include both the layer-3 and layer-4 statements, the router uses the following
Layer 3 and Layer 4 information to load-balance:
• Source IP address
• Destination IP address
• Protocol
• Source port number
• Destination port number
• Incoming interface index
• IP type of service
The router recognizes packets in which all of these layer-3 and layer-4 parameters are
identical, and ensures that these packets are sent out through the same interface. This
prevents problems that might otherwise occur with packets arriving at their destination
out of their original sequence.
This is appropriate behavior for Transmission Control Protocol (TCP) and User Datagram
Protocol (UDP) packets. For Internet Control Message Protocol (ICMP) packets, the field
location offset is the checksum field, which makes each ping packet a separate “flow.”
There are other protocols that can be encapsulated in IP that may have a varying value

in the 32-bit offset. This may also be problematic because these protocols are seen as
a separate flow.
With M Series (with the exception of the M120 router) and T Series routers, the first
fragment is mapped to the same load-balanced destination as the unfragmented packets.
The other fragments can be mapped to other load-balanced destinations.
For the M120 router only, all fragments are mapped to the same load-balanced
destination. This destination is not necessarily the same as that for unfragmented packets.
By default, or if you include only the layer-3 statement, the router uses the incoming
interface index as well as the following Layer 3 information in the packet header to load
balance traffic:
• Protocol
By default, IP version 6 (IPv6) packets are automatically load-balanced based on the

following Layer 3 and Layer 4 information:
• Protocol
• Source port number
• Destination port number
• Incoming interface index
• Traffic class
Per-Packet Load Balancing Examples

Perform per-packet load balancing for all routes:
[edit]
policy-options {
policy-statement load-balancing-policy {
then {
}
}
}
routing-options {
forwarding-table {
export load-balancing-policy;
}
}
Perform per-packet load balancing only for a limited set of routes:

[edit]
policy-options {
policy-statement load-balancing-policy {
from {
route-filter 192.168.10/24 orlonger;
route-filter 10.114/16 orlonger;
}
then {
}
}
}
routing-options {
forwarding-table {
export load-balancing-policy;
}
}
Related • Configuring Per-Packet Load Balancing on page 790

Documentation
Configuring Load Balancing Based on MPLS Labels on ACX Series Routers
ACX Series routers can load-balance on a per-packet basis in MPLS. Load balancing can
be performed on information in both the IP header and on up to three MPLS labels,
providing a more uniform distribution of MPLS traffic to next hops. This feature is enabled
on supported platforms by default and requires no configuration.
Load balancing is used to evenly distribute traffic when there is a single next hop over
an aggregated interface or a LAG bundle. Load balancing using MPLS labels is supported
only for LAG interfaces and not for equal-cost multipath (ECMP) links.
By default, when load balancing is used to help distribute traffic, Junos OS employs a
hash algorithm to select a next-hop address to install into the forwarding table. Whenever
the set of next hops for a destination changes in any way, the next-hop address is
reselected by means of the hash algorithm. You can configure how the hash algorithm
is used to load-balance traffic across interfaces in an aggregated Ethernet (ae) interface.
An LSP tends to load-balance its placement by randomly selecting one of the interfaces
in an ae- interface bundle and using it exclusively. The random selection is made
independently at each transit router, which compares Interior Gateway Protocol (IGP)
metrics alone. No consideration is given to bandwidth or congestion levels.
To load-balance based on the MPLS label information, configure the family mpls
statement:
[edit forwarding-options hash-key]

family mpls {
all-labels;
label-1;
label-2;
label-3;
no-labels;

payload {
ether-pseudowire;
ip {
layer-3-only;
port-data {
destination-lsb;
destination-msb;
source-lsb;
source-msb;
}
}
}
}
You can include this statement at the [edit forwarding-options hash-key] hierarchy level.
NOTE: When you configure payload ip (user@host# set forwarding-options

hash-key family mpls payload ip), configuring layer-3-only and port-data is
mandatory.
Load balancing functionality, without proper hash-keys configuration, may

result in an unpredictable behavior.
For Layer 2 VPN/pseudowire tunnel termination, upto two labels are used for hashing
and payload MAC destination and source addresses can be optionally selected. These
controls can be used to support ether-pseudowire knob in family mpls under hash-key
configuration shown above. However, since ACX2000 and ACX4000 also support TDM
pseudowires, the ether-pseudowire knobs needs to be used only when TDM pseudowires
are not being used.
For Layer 3 VPN tunnel termination, upto two labels are used for hasing and payload IP
source and destination addresses and Layer 4 source and destination ports can be
optionally selected. These controls can be used for supporting ip port-data knobs in
family mpls under hash-key configuration shown above. However, since Layer 4 port
MSB and LSB cannot be individually selected, one of destination-lsb or destination-msb
knobs or one of source-lsb or source-msb knobs would select Layer 4 destination or
source ports, respectively.
For LSR case, upto three labels are used for hashing. If a BOS is seen when parsing the
first three labels, BCM examines the first nibble of payload - if the nibble is 4, the payload
is treated as IPv4 and if the first nibble is 6, the payload is treated as IPv6 and in such
cases payload source and destination IP addresses can be speculatively used for hashing.
These controls can be used for supporting ip port-data knobs in family mpls under
hash-key configuration. However, Layer 4 ports cannot be used for hashing in LSR case,
and only layer-3-only knob is applicable. BCM does not claim support for hashing on
fields beyond the three MPLS labels. Load Balancing for a single pseudowire session
does not take place in case of LSR as all the traffic specific to that session will carry the
same set of MPLS labels.
Load balancing on LSR AE interfaces can be achieved for a higher number of MPLS
sessions, that is minimum of 10 sessions. This is applicable for CCC/VPLS/L3VPN. In

case of Layer 3 VPN, the traffic may not be equally distributed across the member links
as the layer 3 addresses also get accounted for (along with the labels) for the hash input
function.
For LER scenarios, in case of ACX5048 and ACX5096, hashing based on Layer 3 and
Layer 4 fields is possible by configuring the payload option under the “family mpls”
hierarchy. Hashing on the LER is not be based on Labels. For Layer 3 service, it is mandatory
to mention the payload as “layer-3-only” and specify “port-data” in case of Layer 4 service.
You can also mention the label count while configuring hash-keys on LER routers.
NOTE: LER and LSR load balancing behavior is applicable for

CCC/VPLS/Layer 3 VPN and other IP MPLS scenarios.
This feature applies to aggregated Ethernet and aggregated SONET/SDH interfaces. In

addition, you can configure load balancing for IPv4 traffic over Layer 2 Ethernet
pseudowires. You can also configure load balancing for Ethernet pseudowires based on
IP information. The option to include IP information in the hash key provides support for
Ethernet circuit cross-connect (CCC) connections.
Table 50 on page 795 provides detailed information about all of the possible MPLS LSP
load-balancing options.
Table 50: MPLS LSP Load Balancing Options

Statement MPLS LSP Load Balancing Options
label-l Include the first label in the hash key. Use this option for single label packets.
label-2 Include the second label in the hash key. You must also configure the label-1 option. The entire first label and
the first 16 bits of the second label are used in the hash key.
label-3 Include the third label in the hash key. You must also configure the label-1 option and the label-2 option.
no-labels Excludes MPLS labels from the hash key.
payload Allows you to configure which parts of the IP packet payload to include in the hash key. For the PTX Series
Packet Transport Switch, this value is set by default.
disable Exclude IP payload from the hash key.
ether-pseudowire Load-balance IPv4 traffic over Layer 2 Ethernet pseudowires.
ip Include the IPv4 or IPv6 address in the hash key. You must also configure either label-l or no-labels.
layer-3-only Include only the Layer 3 IP information in the hash key. Excludes all of the port-data bytes from the hash key.

Table 50: MPLS LSP Load Balancing Options (continued)

Statement MPLS LSP Load Balancing Options
port-data Include the source and destination port field information. By default, the most significant byte and least
significant byte of the source and destination port fields are used in the hash key. To select specific bytes to
use in the hash key, include one or more of the source-msb, source-lsb, destination-msb, and destination-lsb
options at the [edit forwarding-options hash-key family mpls payload ip port-data] hierarchy level. To prevent
all four bytes from being hashed, include the layer-3-only statement at the [edit forwarding-options hash-key
family mpls payload ip] hierarchy level.
destination-lsb Include the least significant byte of the destination port in the hash key. Can be combined with any of the
other port-data options.
destination-msb Include the most significant byte of the destination port in the hash key. Can be combined with any of the
other port-data options.
source-lsb Include the least significant byte of the source port in the hash key. Can be combined with any of the other
port-data options.
source-msb Include the most significant byte of the source port in the hash key. Can be combined with any of the other
port-data options.
To include the IP address as well as the first label in the hash key, configure the label-1
statement and the ip option for the payload statement at the [edit forwarding-options
hash-key family mpls] hierarchy level:
[edit forwarding-options hash-key family mpls]

label-1;
payload {
ip;
}
To include the IP address as well as both the first and second labels in the hash key,
configure the label-1 and label-2 options and the ip option for the payload statement at
the [edit forwarding-options hash-key family mpls] hierarchy level:

label-1;
label-2;
payload {
ip;
}
Ensure proper load balancing by including the label-1, label-2, and label-3 options at the
[edit forwarding-options hash-key family mpls] hierarchy level:

label-1;
label-2;
label-3;
Related • Configuring Per-Packet Load Balancing on page 790

Documentation

Configuring Load Balancing for Ethernet Pseudowires
You can configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires. You
can also configure load balancing for Ethernet pseudowires based on IP information. The
option to include IP information in the hash key provides support for Ethernet circuit
cross-connect (CCC) connections.
NOTE: This feature is supported only on M120, M320, MX Series, and T Series
routers.
To configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires, include
the ether-pseudowire statement at the [edit forwarding-options hash-key family mpls
payload] hierarchy level:
hash-key {
family mpls {
(label-1 | no-labels);
payload {
ether-pseudowire;
}
}
}
NOTE: You must also configure either the label-1 or the no-labels statement
at the [edit forwarding-options hash-key family mpls] hierarchy level.
You can also configure load balancing for Ethernet pseudowires based on IP information.
This functionality provides support for load balancing for Ethernet cross-circuit connect
(CCC) connections. To include IP information in the hash key, include the ip statement
at the [edit forwarding-options hash-key family mpls payload] hierarchy level:
hash-key {
family mpls {
payload {
ip;
}
}
}
NOTE: You must also configure either the label-1 or no-labels statement at
the [edit forwarding-options hash-key family mpls] hierarchy level.
You can configure load balancing for IPv4 traffic over Ethernet pseudowires to include
only Layer 3 IP information in the hash key. To include only Layer 3 IP information, include

the layer-3-only option at the [edit forwarding-options family mpls hash-key payload ip]
hierarchy level:
hash-key {
family mpls {
payload {
ip {
layer-3-only;
}
}
}
}
NOTE: You must also configure either the label-1 or no-labels statement at
the [edit forwarding-options hash-key family mpls] hierarchy level.
Configuring Load Balancing Based on MAC Addresses
The hash key mechanism for load-balancing uses Layer 2 media access control (MAC)
information such as frame source and destination address. To load-balance traffic based
on Layer 2 MAC information, include the family multiservice statement at the
[edit forwarding-options hash-key] hierarchy level:
family multiservice {
destination-mac;
source-mac;
}
To include the destination-address MAC information in the hash key, include the
destination-mac option. To include the source-address MAC information in the hash key,
include the source-mac option.
NOTE: Any packets that have the same source and destination address will
be sent over the same path.
NOTE: You can configure per-packet load balancing to optimize VPLS traffic
flows across multiple paths.
NOTE: Aggregated Ethernet member links will now use the physical MAC
address as the source MAC address in 802.3ah OAM packets.
NOTE: ACX Series routers do not support VPLS.

Related • Junos OS VPNs Library for Routing Devices

Documentation
ECMP Flow-Based Forwarding on ACX Series Routers
An equal-cost multipath (ECMP) set is formed when the routing table contains multiple
next-hop addresses for the same destination with equal cost. (Routes of equal cost have
the same preference and metric values.) If there is an ECMP set for the active route, the
Junos OS software uses a hash algorithm to choose one of the next-hop addresses in
the ECMP set to install in the forwarding table.
You can configure the Junos OS so that multiple next-hop entries in an ECMP set are
installed in the forwarding table. On ACX Series routers, per-flow load balancing can be
performed to spread traffic across multiple paths between routing devices. ECMP
flow-based forwarding is supported for IPv4, IPv6, and MPLS packets on aggregated
Ethernet (ae) interfaces.
Load balancing is used to evenly distribute traffic when there are multiple equal-cost
next hops over different interfaces or a single next hop over an aggregated interface. By
default, when load balancing is used to help distribute traffic, Junos OS employs a hash
algorithm to select a next-hop address to install into the forwarding table.
If a next-hop address is no longer part of the ECMP set or if it is removed from the routing
table because of a route change, a flow that uses the next hop is rerouted and the session
is not affected. Rerouting of the flow also occurs if there is a configuration change that
takes away the next-hop address or if an administrator takes down the next-hop interface
without deleting it. If a next-hop address is removed from the routing table because the
interface is deleted or the session is intentionally cleared, the session is killed without
being rerouted.
To select which packet header data to use for per-flow load balancing, include the
hash-key statement at the [edit forwarding-options] hierarchy level. To load-balance
IPv4 traffic by using the port data into the hash key, include the family-inet statement at
the [edit forwarding-options hash-key] hierarchy level. You can incorporate either the
Layer 3 IP port data, or the Layer 4 TCP or UDP port data into the hash key. To
load-balance based on the MPLS label information, configure the family mpls statement
at the [edit forwarding-options hash-key] hierarchy level.
Forwarding of MPLS traffic by using penultimate-hop popping (PHP) and label-switched

routing (LSR) is not supported on ACX Series routers. For ECMP flow-based forwarding
over pseudowires, MPLS flows are assigned to one of the ECMP routes by using the
hashing algorithm based on user-to-network interface (UNI) index.
To configure ECMP flow-based forwarding on ACX Series routers, first define a

load-balancing routing policy by including one or more policy-statement configuration
statements at the [edit policy-options] hierarchy level, with the action load-balance
per-packet. Then apply the routing policy to routes exported from the routing table to
the forwarding table. To do this, include the forwarding-table and export configuration
statements at the [edit routing-options] hierarchy level.

To view the details of the ECMP next hops and to obtain information for debugging any
problem with the ECMP functionality, issue the show route or the show route summary
command.
The maximum number of next-hop addresses in an ECMP set that can be installed in
the forwarding table of ACX Series routers is 16. A maximum of 2047 ECMP next-hops
are supported.
Related • Understanding Routing Policies

Documentation
• Summary of Routing Policy Actions
Sample Scenario of H-VPLS on ACX Series Routers for IPTV Services
Hierarchical LDP-based VPLS requires a full mesh of tunnel LSPs between all the PE
routers that participate in the VPLS service. For each VPLS service, n*(n-1)/2 pseudowires
must be set up between the PE routers. Although the full mesh requirement creates
signaling overhead, the larger negative impact to large-scale deployment is the packet
replication requirements for each provisioned pseudowire on a PE router. Using hierarchical
connectivity reduces signaling and replication overhead to facilitate large-scale
deployments. .
In a typical IPTV solution, IPTV sources are in the public domain and the subscribers are
in the private VPN domain. The objective is to deliver the multicast streams originated
from the IPTV source to the set-top boxes or subscribers in the private domain. Generally,
for an efficient delivery of multicast data from the IP Sources to the access devices (ACX
in this case), P2MP LSPs and mVPN is used. The subscriber devices could then be
connected to a VPLS or a Layer 3 VPN domain in Access router and they could be
configured to import the multicast routes from an MVPN instance. Because VPLS and
MVPN are not supported on ACX routers, an alternative approach can be used to achieve
H-VPLS capabilities. The support for PIM snooping in Layer 3 interfaces, IGMP snooping
in Layer 2 networks, IRB interfaces, and logical tunnel interfaces enables HVLS support.
An ACX router receives the multicast data on the default VRP context and the data gets
forwarded on to the BD through IRB and gets replicated on the BD ports based on the
membership detected through IGMP snooping. Unicast control traffic between Subscriber
devices and the IPTV subscriber management server goes through the private VPN
domain. Aggregation routers have VPLS full-mesh connectivity between each other and
ACX works as H-VPLS MTU. There is a PW setup between ACX and the aggregation
router. LT interface does the stitching of the Bridge domain with the PW
Sample Configuration Scenario of H-VPLS for IPTV Services

Consider a scenario in which set-top boxes (STBs) or customer premises equipment
(CPE) devices are connected to two ACX routers, ACX1 and ACX2. On the ACX routers,
a global virtual routing and forwarding (VRF) context, bridge domains, pseudowires, and
IRB settings are defined. ACX1 is connected to two MX Series routers, MX2 and MX3.
Connection to ACX1 to MX2 is through an active pseudowire with PIM deployed. PIM is
used as the transport protocol in communication between ACX and MX routers. Unicast
transmission is also configured. Connection of ACX1 to MX3 is through a backup

pseudowire. ACX2 is connected to two MX Series routers, MX2 and MX3. Connection to
ACX2 to MX2 is through an active pseudowire. ACX2 is linked to MX3 using a standby
pseudowire. MX2 and MX3 are connected to MX1, which is the root of the LSP. MX1 is
linked to an IPTV source.
Point-to-multipoint (P2MP) traffic engineering (TE) LSP is setup from the MX router
(MX-1 is connected to the IPTV source) to the aggregation MX routers (MX-2 & MX-3).
MX-1 is the root of the LSP. MX-2 and MX-3 are the leaves. Leaves cannot be configured
statically or dynamically.
• PIM can be enabled between MX-1 and IPTV Source and MX-1 is the DR for the Multicast
source.
• mVPN is configured on the default VRF routing instance. Selective tree can be used
for optimal routing.
• PIM-SM is running in the Access network between access routers (ACX-1 and ACX-2)
and aggregation routers (MX-1 and MX-2).
MX-1 and MX-2 are the RPs for the PIM-SM.
• RPF check is disabled for the multicast groups in aggregation routers for it to accept
the data from remote source.
• Rendezvous point (RP) redundancy is achieved by configuring auto-RP in ACXs and

configuring multiple aggregation routers as RP for every access ring (PIM island).
ACX has a bridge-domain and subscriber devices are connected to the BD ports. This
enables the subscribers to be on the same IP subnet. (This method of configuration
suits a topology in which you want all the subscribers connected to the ACXs in a single
access ring to be on the same subnet. This makes the DHCP server pool allocation
policy easier). No local switching is enabled on the bridge domain, to ensure that
subscriber to subscriber communication does not occur locally through the bridge
domain.
• Bridge domain has the IRB configuration providing connectivity to the default VRF
router instance. IGMP is enabled on the IRB interface. This enables the IGMP join
messages send by the subscriber devices to be processed by the routing module and
in turn triggers a PIM join towards RP in the default routing instance.
• IGMP snooping is enabled on the bridge domain for an optimal forwarding of multicast
data at the BD level.
• ACX router receives the multicast data on the default VRP context and the data gets
forwarded on to the BD through IRB and gets replicated on the BD ports based on the
membership detected through IGMP snooping.
• Unicast control traffic between Subscriber devices and the IPTV subscriber
management server goes through the private VPN domain.
• Aggregation routers have VPLS full-mesh connectivity between each other and ACX
works as H-VPLS MTU.
• There is a PW set up between ACX and the aggregation router. LT interface does the
stitching of the Bridge domain with the PW.

• An active and a standby pseudowire are set up between ACX and aggregation routers
to support redundancy for the control traffic.
• PW terminates into the VPLS instance in the aggregation router. PWs from multiple
ACX routers are terminated to the same VPLS instance as all the subscribers across
all ACX boxes connected to a same aggregation router are in the same subnet.
• VPLS instance in the aggregation router is connected to the L3VPN instance through
IRB interface which has IP address from the same subnet as the subscribers. Subscriber
management station that is controlling the subscribers belong to a particular customer
is connected to this Layer 3 VPN domain.
Guidelines for H-VPLS on ACX Routers

Keep the following points in mind while configuring H-VPLS on ACX routers:
• Control traffic is limited to 1G or 10G bandwidth based on the logical tunnel (lt-)
interface limitation.
• Multicast data delivery is based on PIM on the access network. Therefore, the
convergence time is directly related to the convergence time of the IGP protocol
configured on the access network.
• Two versions of multicast solutions must be implemented in the provider network for
the end-to-end solution to work. Also, you must set up PIM- based solution on the
access network and MVPN-based solution on the aggregation or core network. This
topology is considered a configuration overhead.
• IPv6 multicast and active-active redundancy models are not supported.
• You can implement an IPTV framework without the MVPN and VPLS support on ACX
routers.
• Multicast support using PIM-SM and IGMP is supported,
• Unicast control traffic is restricted to the customer VPN domain.
• Support for multiple subscribers to be on the same IP subnet is provided. Direct

communication between the subscribers at the ACX level is disabled.
• IGMP snooping is supported to ensure that the multicast data is not forwarded to the
subscribers that are not registered for that data.
• An IRB interface is used for only multicast data delivery from the default VRF context.
Related • PIM Overview on page 672

Documentation
• Understanding IGMP on page 445

Guidelines for Configuring Unicast RPF on ACX Series Routers
Observe the following guidelines while configuring unicast RPF on ACX Series routers:
• Support for physical interfaces impacts inet families only.
• The RPF check to be used when routing is asymmetrical is not supported because the
unicast-reverse-path (active-paths | feasible-paths) statement at the [edit
routing-instances routing-instance-name instance-type name routing-options
forwarding-table] hierarchy level is not supported.
• Even if uRPF checking is enabled, the reverse path checking is not performed if the
following conditions apply:
• The destination IP address is not a unicast address. This applies for both IPV4 and
IPV6 packets.
• The source IP address is IPV6 and the address is a link local address (FE80::/10)
• The received packet is a BOOTP/DHCP packet (SIP=0.0.0.0 and

DIP=255.255.255.255)
• If you enable/disable unicast RPF on live traffic, some packets are dropped while the
packet forwarding components are updating. This behavior occurs because route
reinstallation is initiated while you enable or disable uRPF.
• uRPF is supported at the logical interface level. Due to hardware limitations, support
is available only at the logical interface level.
• Strict mode on ECMP routes is not supported in ACX. This condition occurs because
the hardware treats ECMP routes as Loose Mode although the port is configured as
Strict mode. Because ECMP uses multiple physical paths for the route the reverse path
check results in utilizing many paths (routes) and the source port validation method
is not used in case of Strict mode. As a result, such a network scenario operates in the
same manner as loose mode.
• When the strict mode is enabled on the interface, if the packet is coming with an SIP
address which ARP resolution is pending will be dropped as it points to RESOLVE_NH.
• uRPF fail filter can be configured for family <inet | inet6> in ACX.
NOTE: The uRPF fail filter cannot match packets failed at ingress port
check (strict mode).
The uRPF fail filter can match packets failing source IP lookup but cannot
match packets failing the input interface check (strict mode).
The uRPF fail filter applies only to interface-specific instances of the firewall
filter.
The uRPF fail filters do not support reject and routing-instance actions.
• uRPF can be configured for family <inet | inet6> on IRB interfaces in ACX.

• uRPF implementation in ACX does not consider all feasible paths for reverse path
verification and only active path based verification is supported.
• uRPF failure packets statistics are not supported in ACX.
• You can use either the show interfaces extensive command or the show interfaces detail
command to verify that unicast RPF is enabled and working on the interface. In the
Flags section of the output, if unicast reverse-path forwarding (RPF) is explicitly
configured on the specified interface, the uRPF flag is displayed. If unicast RPF was
configured on a different interface (and therefore is enabled on all switch interfaces)
but was not explicitly configured on the specified interface, the uRPF flag is not
displayed even though unicast RPF is enabled.
• The uRPF detail in the Flags section of the output of the show interfaces (detail |
extensive) commands is displayed only for logical interfaces on which uRPF is
configured. Otherwise, this information is not shown.
Related •
Documentation
Configuring Unicast RPF on ACX Series Routers
IP spoofing can occur during a denial-of-service (DoS) attack. IP spoofing allows an

intruder to pass IP packets to a destination as genuine traffic, when in fact the packets
are not actually meant for the destination. This type of spoofing is harmful because it
consumes the destination’s resources.
A unicast reverse-path-forwarding (RPF) check is a tool to reduce forwarding of IP packets

that might be spoofing an address. A unicast RPF check performs a route table lookup
on an IP packet’s source address, and checks the incoming interface. The router or switch
determines whether the packet is arriving from a path that the sender would use to reach
the destination. If the packet is from a valid path, the router or switch forwards the packet
to the destination address. If it is not from a valid path, the router or switch discards the
packet. Unicast RPF is supported for the IPv4 and IPv6 protocol families, as well as for
the virtual private network (VPN) address family.
NOTE: If you want to configure unicast RPF, your router must be equipped
with the Internet Processor II application-specific integrated circuit (ASIC).
If you enable unicast RPF on live traffic, some packets are dropped while the
packet forwarding components are updating.
For transit packets exiting the router through the tunnel, forwarding path
features, such as RPF, forwarding table filtering, source class usage, and
destination class usage are not supported on the interfaces you configure as
the output interface for tunnel traffic. For firewall filtering, you must allow
the output tunnel packets through the firewall filter applied to input traffic
on the interface that is the next-hop interface towards the tunnel destination.

The following sections describe unicast RPF in detail:
• Interworking of Unicast RFF With Different System Conditions on page 805

• Configuring Unicast RPF Strict Mode on page 805
• Configuring Unicast RPF Loose Mode on page 806
• Unicast RPF and Default Routes on page 806
• Configuring Unicast RPF on a VPN on page 807
• Configuring Unicast RPF Fail Filter on page 808
Interworking of Unicast RFF With Different System Conditions

The following is the unicast RPF behaviour for different system configuration scenarios:
• Unicast RPF with default routes—unicast RPF check will not consider the default route
for its reverse path checking. That means packet will be accepted only if at least route
prefix is present in the routing table.(Loose Mode)
• Unicast RPF with filter-based forwarding—unicast RPF is applied in the Layer 3 lookup
stage in which all the filters are already applied and the corresponding VRF is identified.
So it always uses the route table with respect to the VRF it belongs to. The reverse
path check fails even it has valid route in other VRF table also.
• Unicast RPF with virtual router or VRF—unicast RPF is applied in the Layer 3 lookup
stage in which the corresponding VRF/VR is identified. So it always uses the route table
with respect to the VRF or virtual router it belongs to. The reverse path check fails even
it has a valid route in other VRF table.
• Unicast RPF with IP unnumbered case—unicast RPF is supported with IP unnumbered

case also. In this case it uses the same properties of the referenced interface.
• Unicast RPF with IPV6—unicast RPF is performed for IPV6 global unicast and unique
local address only. For the link local IPV6 address, unicast RPF is not performed.
Configuring Unicast RPF Strict Mode

In strict mode, unicast RPF checks whether the incoming packet has a source address
that matches a prefix in the routing table, and whether the interface expects to receive
a packet with this source address prefix.
If the incoming packet fails the unicast RPF check, the packet is not accepted on the
interface. When a packet is not accepted on an interface, unicast RPF counts the packet
and sends it to an optional fail filter. If the fail filter is not configured, the default action
is to silently discard the packet.
The optional fail filter allows you to apply a filter to packets that fail the unicast RPF
check. You can define the fail filter to perform any filter operation, including accepting,
rejecting, logging, sampling, or policing.
When unicast RPF is enabled on an interface, Bootstrap Protocol (BOOTP) packets and
Dynamic Host Configuration Protocol (DHCP) packets are not accepted on the interface.
To allow the interface to accept BOOTP packets and DHCP packets, you must apply a

fail filter that accepts all packets with a source address of 0.0.0.0 and a destination
address of 255.255.255.255.
For more information about unicast RPF, see the Junos OS Routing Protocols Library. For
more information about defining fail filters, see the Routing Policies, Firewall Filters, and
Traffic Policers Feature Guide.
To configure unicast RPF, include the rpf-check statement:
rpf-check;
You can include this statement at the [edit interfaces interface-name unit
logical-unit-number family (inet | inet6)] hierarchy level.
Configuring Unicast RPF Loose Mode

By default, unicast RPF uses strict mode. Unicast RPF loose mode is similar to unicast
RPF strict mode and has the same configuration restrictions. The only check in loose
mode is whether the packet has a source address with a corresponding prefix in the
routing table; loose mode does not check whether the interface expects to receive a
packet with a specific source address prefix. If a corresponding prefix is not found, unicast
RPF loose mode does not accept the packet. As in strict mode, loose mode counts the
failed packet and optionally forwards it to a fail filter, which either accepts, rejects, logs,
samples, or polices the packet.
To configure unicast RPF loose mode, include the mode:
mode loose;
You can include this statement at the [edit interfaces interface-name unit
logical-unit-number family (inet | inet6) rpf-check] hierarchy level.
Unicast RPF and Default Routes

When the active route cannot be chosen from the routes in a routing table, the router
chooses a default route. A default route is equivalent to an IP address of 0.0.0.0/0. If
you configure a default route, and you configure unicast RPF on an interface that the
default route uses, unicast RPF behaves differently than it does otherwise. For information
about configuring default routes, see the Junos OS Routing Protocols Library.
To determine whether the default route uses an interface, enter the show route command:
user@host> show route address
address is the next-hop address of the configured default route. The default route uses
the interfaces shown in the output of the show route command.
The following sections describe how unicast RPF behaves when a default route uses an
interface and when a default route does not use an interface:
• Unicast RPF Behavior with a Default Route on page 807

• Unicast RPF Behavior Without a Default Route on page 807

Unicast RPF Behavior with a Default Route
If you configure a default route that uses an interface configured with unicast RPF, unicast
RPF behaves as follows:
• Loose mode—All packets are automatically accepted. For this reason, we recommend
that you not configure unicast RPF loose mode on interfaces that the default route
uses.
• Strict mode—The packet is accepted when either of the following is true:
• The source address of the packet matches any of the routes (either default or
learned) that can be originated from the interface. Note that routes can have multiple
destinations associated with them; therefore, if one of the destinations matches the
incoming interface of the packet, the packet is accepted.
• The source address of the packet does not match any of the routes.
The packet is not accepted when either of the following is true:
• The source address of the packet does not match a prefix in the routing table.
• The interface does not expect to receive a packet with this source address prefix.
Unicast RPF Behavior Without a Default Route
If you do not configure a default route, or if the default route does not use an interface
configured with unicast RPF, unicast RPF behaves as described in “Configuring Unicast
RPF Strict Mode” on page 805 and “Configuring Unicast RPF Loose Mode” on page 806. To
summarize, unicast RPF without a default route behaves as follows:
• Strict mode—The packet is not accepted when either of the following is true:
• The packet has a source address that does not match a prefix in the routing table.
• The interface does not expect to receive a packet with this source address prefix.
• Loose mode—The packet is not accepted when the packet has a source address that
does not match a prefix in the routing table.
Configuring Unicast RPF on a VPN

You can configure unicast RPF on a VPN interface by enabling unicast RPF on the interface
and including the interface statement at the [edit routing-instances routing-instance-name]
hierarchy level.
You can configure unicast RPF only on the interfaces you specify in the routing instance.
This means the following:
• For Layer 3 VPNs, unicast RPF is supported on the CE router interface.
• Unicast RPF is not supported on core-facing interfaces.

• For virtual-router routing instances, unicast RPF is supported on all interfaces you
specify in the routing instance.
• If an input filter forwards packets anywhere other than the routing instance the input
interface is configured for, the unicast RPF check is not performed.
For more information about VPNs and virtual-router routing instances, see the Junos OS
VPNs Library for Routing Devices. For more information about FBF, see the Junos OS
Routing Protocols Library.
Example: Configuring Unicast RPF on a VPN
Configure unicast RPF on a Layer 3 VPN interface:
[edit interfaces]
so-0/0/0 {
unit 0 {
family inet {
rpf-check;
}
}
}
[edit routing-instance]
VPN-A {
interface so-0/0/0.0;
}
Configuring Unicast RPF Fail Filter

Unicast RPF fail filter allows you to apply a filter to packets that fail the unicast RPF
check. ACX Series routers supports configuring uRPF fail filter on interfaces. You can
define the fail filter to perform any filter operation, including accepting, rejecting, logging,
or policing.
For more information about unicast RPF, see the Junos OS Routing Protocols Library. For
more information about defining fail filters, see the Routing Policies, Firewall Filters, and
Traffic Policers Feature Guide.
For information about configuring a firewall filters, see “Guidelines for Configuring Firewall
Filters” on page 1044.
To configure unicast RPF fail filter, include the fail-filter statement at the [edit interfaces
interface-name unit logical-unit-number family (inet | inet6) rpf-check] hierarchy level.
Related • unicast-reverse-path on page 1770

Documentation
• Example: Configuring Unicast Reverse-Path-Forwarding Check
• Guidelines for Configuring Firewall Filters on page 1044
Verifying Unicast RPF Status
Purpose Verify that unicast reverse-path forwarding (RPF) is enabled and is working on the
interface.

Action Use one of the show interfaces interface-name commands with either the extensive or
detail options to verify that unicast RPF is enabled and working on the switch. The example
below displays output from the show interfaces ge- extensive command.
user@switch> show interfaces ge-1/0/10 extensive

Physical interface: ge-1/0/10, Enabled, Physical link is Down
Link-level type: Ethernet, MTU: 1514, Speed: Auto, MAC-REWRITE Error: None,
Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled,
Auto-negotiation: Enabled, Remote fault: Online
Interface flags: Hardware-Down SNMP-Traps Internal: 0x0
Link flags : None
Current address: 00:19:e2:50:95:ab, Hardware address: 00:19:e2:50:95:ab
Last flapped : Never
Statistics last cleared: Never
Traffic statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0,
L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0,
FIFO errors: 0, Resource errors: 0
Output errors:
Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0,
FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0

Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 0 0 0
1 assured-forw 0 0 0
5 expedited-fo 0 0 0
7 network-cont 0 0 0
Active alarms : LINK

Active defects : LINK
MAC statistics: Receive Transmit
Total octets 0 0
Total packets 0 0
Unicast packets 0 0
Broadcast packets 0 0
Multicast packets 0 0
CRC/Align errors 0 0
FIFO errors 0 0
MAC control frames 0 0
MAC pause frames 0 0
Oversized frames 0

Jabber frames 0
Fragment frames 0
VLAN tagged frames 0
Code violations 0
Filter statistics:
Input packet count 0
Input packet rejects 0
Input DA rejects 0
Input SA rejects 0
Output packet count 0
Output packet pad count 0
Output packet error count 0
CAM destination filters: 0, CAM source filters: 0
Autonegotiation information:
Negotiation status: Incomplete
Destination slot: 1
Logical interface ge-1/0/10.0 (Index 69) (SNMP ifIndex 59) (Generation 135)
Flags: Device-Down SNMP-Traps 0x0 Encapsulation: ENET2
Traffic statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Transit statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Protocol inet, Generation: 144, Route table: 0
Flags: uRPF
Meaning The show interfaces ge-1/0/10 extensive command (and the show interfaces ge-1/0/10
detail command) displays in-depth information about the interface. The Flags: output
field near the bottom of the display reports the unicast RPF status. If unicast RPF has
not been enabled, the uRPF flag is not displayed.
On EX3200 and EX4200 switches, unicast RPF is implicitly enabled on all switch
interfaces, including aggregated Ethernet interfaces (also referred to as link aggregation
groups or LAGs) and routed VLAN interfaces (RVIs) when you enable unicast RPF on a

single interface. However, the unicast RPF status is shown as enabled only on interfaces
for which you have explicitly configured unicast RPF. Thus, the uRPF flag is not displayed
on interfaces for which you have not explicitly configured unicast RPF even though unicast
RPF is implicitly enabled on all interfaces on EX3200 and EX4200 switches.
Related • show interfaces xe-

Documentation
• Example: Configuring Unicast RPF on an EX Series Switch
• Configuring Unicast RPF on ACX Series Routers on page 804
• Configuring Unicast RPF (CLI Procedure)
• Disabling Unicast RPF (CLI Procedure)
• Troubleshooting Unicast RPF


CHAPTER 26
Configuring Layer 3 VPNs
• Layer 3 VPN Introduction on page 813

• Understanding Layer 3 VPN Attributes on page 814
• Understanding VPN-IPv4 Addresses and Route Distinguishers on page 815
• Understanding Virtual Routing and Forwarding Tables on page 818
• Understanding IPv4 Route Distribution in a Layer 3 VPN on page 822
• Understanding Layer 3 VPN Forwarding Through the Core on page 826
• Understanding Routing Instances for Layer 3 VPNs on page 827
• Configuring a VPN Tunnel for VRF Table Lookup on page 828
• Introduction to Configuring Layer 3 VPNs on page 828
• Configuring Routing Between PE and CE Routers in Layer 3 VPNs on page 830
• Limiting the Number of Paths and Prefixes Accepted from CE Routers in Layer 3
VPNs on page 841
• Understanding IPv6 Layer 3 VPNs on page 842
• Layer 3 VPNs for IPv4 and IPv6 Overview on page 842
• Configuring Layer 3 VPNs to Carry IPv6 Traffic on page 844
• Configuring EBGP Multihop Sessions Between PE and CE Routers in Layer 3
VPNs on page 848
• Configuring Layer 3 VPNs to Carry IBGP Traffic on page 849
• Configuring a Label Allocation and Substitution Policy for VPNs on page 850
• Configuring Protocol-Independent Load Balancing in Layer 3 VPNs on page 852
• Configuring the Algorithm That Determines the Active Route to Evaluate AS Numbers
in AS Paths for VPN Routes on page 855
• Accepting Route Updates with Unique Inner VPN Labels in Layer 3 VPNs on page 855
Layer 3 VPN Introduction
In Junos OS, Layer 3 VPNs are based on RFC 4364. RFC 4364 defines a mechanism by
which service providers can use their IP backbones to provide VPN services to their
customers. A Layer 3 VPN is a set of sites that share common routing information and
whose connectivity is controlled by a collection of policies. The sites that make up a
Layer 3 VPN are connected over a provider’s existing public Internet backbone.

RFC 4364 VPNs are also known as BGP/MPLS VPNs because BGP is used to distribute
VPN routing information across the provider’s backbone, and MPLS is used to forward
VPN traffic across the backbone to remote VPN sites.
Customer networks, because they are private, can use either public addresses or private
addresses, as defined in RFC 1918, Address Allocation for Private Internets. When customer
networks that use private addresses connect to the public Internet infrastructure, the
private addresses might overlap with the same private addresses used by other network
users. MPLS/BGP VPNs solve this problem by adding a VPN identifier prefix to each
address from a particular VPN site, thereby creating an address that is unique both within
the VPN and within the public Internet. In addition, each VPN has its own VPN-specific
routing table that contains the routing information for that VPN only.
Understanding Layer 3 VPN Attributes
Route distribution within a VPN is controlled through BGP extended community attributes.
RFC 4364 defines the following three attributes used by VPNs:
• Target VPN—Identifies a set of sites within a VPN to which a provider edge (PE) router
distributes routes. This attribute is also called the route target. The route target is used
by the egress PE router to determine whether a received route is destined for a VPN
that the router services.
Figure 45 on page 815 illustrates the function of the route target. PE Router PE1 adds
the route target “VPN B” to routes received from the customer edge (CE) router at
Site 1 in VPN B. When it receives the route, the egress router PE2 examines the route
target, determines that the route is for a VPN that it services, and accepts the route.
When the egress router PE3 receives the same route, it does not accept the route
because it does not service any CE routers in VPN B.
• VPN of origin—Identifies a set of sites and the corresponding route as having come
from one of the sites in that set.
• Site of origin—Uniquely identifies the set of routes that a PE router learned from a
particular site. This attribute ensures that a route learned from a particular site through
a particular PE-CE connection is not distributed back to the site through a different
PE-CE connection. It is particularly useful if you are using BGP as the routing protocol
between the PE and CE routers and if different sites in the VPN have been assigned
the same autonomous system (AS) numbers.

Chapter 26: Configuring Layer 3 VPNs
Figure 45: VPN Attributes and Route Distribution
Understanding VPN-IPv4 Addresses and Route Distinguishers
Because Layer 3 VPNs connect private networks—which can use either public addresses
or private addresses, as defined in RFC 1918 (Address Allocation for Private Internets)—over
the public Internet infrastructure, when the private networks use private addresses, the
addresses might overlap with the addresses of another private network.
Figure 46 on page 816 illustrates how private addresses of different private networks can
overlap. Here, sites within VPN A and VPN B use the address spaces 10.1.0.0/16,
10.2.0.0/16, and 10.3.0.0/16 for their private networks.

Figure 46: Overlapping Addresses Among Different VPNs
To avoid overlapping private addresses, you can configure the network devices to use
public addresses instead of private addresses. However, this is a large and complex
undertaking. The solution provided in RFC 4364 uses the existing private network numbers
to create a new address that is unambiguous. The new address is part of the VPN-IPv4
address family, which is a BGP address family added as an extension to the BGP protocol.
In VPN-IPv4 addresses, a value that identifies the VPN, called a route distinguisher, is
prefixed to the private IPv4 address, providing an address that uniquely identifies a private
IPv4 address.
Only the PE routers need to support the VPN-IPv4 address extension to BGP. When an
ingress PE router receives an IPv4 route from a device within a VPN, it converts it into a
VPN-IPv4 route by adding the route distinguisher prefix to the route. The VPN-IPv4
addresses are used only for routes exchanged between PE routers. When an egress PE
router receives a VPN-IPv4 route, it converts the VPN-IPv4 route back to an IPv4 route
by removing the route distinguisher before announcing the route to its connected CE
routers.
VPN-IPv4 addresses have the following format:
• Route distinguisher is a 6-byte value that you can specify in one of the following formats:
• as-number:number, where as-number is an AS number (a 2-byte value) and number

is any 4-byte value. The AS number can be in the range 1 through 65,535. We
recommend that you use an Internet Assigned Numbers Authority (IANA)-assigned,

nonprivate AS number, preferably the Internet service provider’s (ISP’s) own or the
customer’s own AS number.
• ip-address:number, where ip-address is an IP address (a 4-byte value) and number is

any 2-byte value. The IP address can be any globally unique unicast address. We
recommend that you use the address that you configure in the router-id statement,
which is a nonprivate address in your assigned prefix range.
• IPv4 address—4-byte address of a device within the VPN.
Figure 46 on page 816 illustrates how the AS number can be used in the route distinguisher.
Suppose that VPN A is in AS 65535 and that VPN B is in AS 666 (both these AS numbers
belong to the ISP), and suppose that the route distinguisher for Site 2 in VPN A is 65535:02
and that the route distinguisher for Site 2 in VPN B is 666:02. When Router PE2 receives
a route from the CE router in VPN A, it converts it from its IP address of 10.2.0.0 to a
VPN-IPv4 address of 65535:02:10.2.0.0. When the PE router receives a route from VPN
B, which uses the same address space as VPN A, it converts it to a VPN-IPv4 address of
666:02:10.2.0.0.
If the IP address is used in the route distinguisher, suppose Router PE2’s IP address is
172.168.0.1. When the PE router receives a route from VPN A, it converts it to a
VPN-IPv4 address of 172.168.0.1:0:10.2.0.0/16, and it converts a route from VPN B to
172.168.0.0:1:10.2.0.0/16.
Route distinguishers are used only among PE routers to IPv4 addresses from different
VPNs. The ingress PE router creates a route distinguisher and converts IPv4 routes received
from CE routers into VPN-IPv4 addresses. The egress PE routers convert VPN-IPv4 routes
into IPv4 routes before announcing them to the CE router.
Because VPN-IPv4 addresses are a type of BGP address, you must configure IBGP sessions
between pairs of PE routers so that the PE routers can distribute VPN-IPv4 routes within
the provider’s core network. (All PE routers are assumed to be within the same AS.)
You define BGP communities to constrain the distribution of routes among the PE routers.
Defining BGP communities does not, by itself, distinguish IPv4 addresses.
Figure 47 on page 818 illustrates how Router PE1 adds the route distinguisher
10458:22:10.1/16 to routes received from the CE router at Site 1 in VPN A and forwards
these routes to the other two PE routers. Similarly, Router PE1 adds the route distinguisher
10458:23:10.2/16 to routes received by the CE router at Site 1 in VPN B and forwards these
routes to the other PE routers.

Figure 47: Route Distinguishers
Understanding Virtual Routing and Forwarding Tables
To separate a VPN’s routes from routes in the public Internet or those in other VPNs, the
PE router creates a separate routing table for each VPN, called a VPN routing and
forwarding (VRF) table. The PE router creates one VRF table for each VPN that has a
connection to a CE router. Any customer or site that belongs to the VPN can access only
the routes in the VRF tables for that VPN.
Figure 48 on page 819 illustrates the VRF tables that are created on the PE routers. The
three PE routers have connections to CE routers that are in two different VPNs, so each
PE router creates two VRF tables, one for each VPN.

Figure 48: VRF Tables
Each VRF table is populated from routes received from directly connected CE sites
associated with that VRF routing instance and from routes received from other PE routers
that passed BGP community filtering and are in the same VPN.
Each PE router also maintains one global routing table (inet.0) to reach other routers in
and outside the provider’s core network.
Each customer connection (that is, each logical interface) is associated with one VRF
table. Only the VRF table associated with a customer site is consulted for packets from
that site.
You can configure the router so that if a next hop to a destination is not found in the
VRF table, the router performs a lookup in the global routing table, which is used for
Internet access.

The Junos OS uses the following routing tables for VPNs:
• bgp.l3vpn.0—Stores all VPN-IPv4 unicast routes received from other PE routers. (This
table does not store routes received from directly connected CE routers.) This table is
present only on PE routers.
When a PE router receives a route from another PE router, it places the route into its
bgp.l3vpn.0 routing table. The route is resolved using the information in the inet.3 routing
table. The resultant route is converted into IPv4 format and redistributed to all
routing-instance-name.inet.0 routing tables on the PE router if it matches the VRF import
policy.
The bgp.l3vpn.0 table is also used to resolve routes over the MPLS tunnels that connect
the PE routers. These routes are stored in the inet.3 routing table. PE-to-PE router
connectivity must exist in inet.3 (not just in inet.0) for VPN routes to be resolved properly.
When a router is advertising non-local VPN-IPv4 unicast routes and the router is a
route reflector or is performing external peering, the VPN-IPv4 unicast routes are
automatically exported into the VPN routing table (bgp.l3vpn.0). This enables the
router to perform path selection and advertise from the bgp.l3vpn.0 routing table.
To determine whether to add a route to the bgp.l3vpn.0 routing table, the Junos OS
checks it against the VRF instance import policies for all the VPNs configured on the
PE router. If the VPN-IPv4 route matches one of the policies, it is added to the
bgp.l3vpn.0 routing table. To display the routes in the bgp.l3vpn.0 routing table, use
the show route table bgp.l3vpn.0 command.
• routing-instance-name.inet.0—Stores all unicast IPv4 routes received from directly

connected CE routers in a routing instance (that is, in a single VPN) and all explicitly
configured static routes in the routing instance. This is the VRF table and is present
only on PE routers. For example, for a routing instance named VPN-A, the routing table
for that instance is named VPN-A.inet.0.
When a CE router advertises to a PE router, the PE router places the route into the
corresponding routing-instance-name.inet.0 routing table and advertises the route to
other PE routers if it passes a VRF export policy. Among other things, this policy tags
the route with the route distinguisher (route target) that corresponds to the VPN site
to which the CE belongs. A label is also allocated and distributed with the route. The
bgp.l3vpn.0 routing table is not involved in this process.
The routing-instance-name.inet.0 table also stores routes announced by a remote

PE router that match the VRF import policy for that VPN. The remote PE router
redistributed these routes from its bgp.l3vpn.0 table.
Routes are not redistributed from the routing-instance-name.inet.0 table to the

bgp.l3vpn.0 table; they are directly advertised to other PE routers.
For each routing-instance-name.inet.0 routing table, one forwarding table is maintained

in the router’s Packet Forwarding Engine. This table is maintained in addition to the
forwarding tables that correspond to the router’s inet.0 and mpls.0 routing tables. As
with the inet.0 and mpls.0 routing tables, the best routes from the
routing-instance-name.inet.0 routing table are placed into the forwarding table.

To display the routes in the routing-instance-name.inet.0 table, use the show route table
routing-instance-name.inet.0 command.
• inet.3—Stores all MPLS routes learned from LDP and RSVP signaling done for VPN
traffic. The routing table stores the MPLS routes only if the traffic-engineering bgp-igp
option is not enabled.
For VPN routes to be resolved properly, the inet.3 table must contain routes to all the
PE routers in the VPN.
To display the routes in the inet.3 table, use the show route table inet.3 command.
• inet.0—Stores routes learned by the IBGP sessions between the PE routers. To provide
Internet access to the VPN sites, configure the routing-instance-name.inet.0 routing
table to contain a default route to the inet.0 routing table.
To display the routes in the inet.0 table, use the show route table inet.0 command.
The following routing policies, which are defined in VRF import and export statements,
are specific to VRF tables.
• Import policy—Applied to VPN-IPv4 routes learned from another PE router to determine

whether the route should be added to the PE router’s bgp.l3vpn.0 routing table. Each
routing instance on a PE router has a VRF import policy.
• Export policy—Applied to VPN-IPv4 routes that are announced to other PE routers.

The VPN-IPv4 routes are IPv4 routes that have been announced by locally connected
CE routers.
VPN route processing differs from normal BGP route processing in one way. In BGP, routes
are accepted if they are not explicitly rejected by import policy. However, because many
more VPN routes are expected, the Junos OS does not accept (and hence store) VPN
routes unless the route matches at least one VRF import policy. If no VRF import policy
explicitly accepts the route, it is discarded and not even stored in the bgp.l3vpn.0 table.
As a result, if a VPN change occurs on a PE router—such as adding a new VRF table or
changing a VRF import policy—the PE router sends a BGP route refresh message to the
other PE routers (or to the route reflector if this is part of the VPN topology) to retrieve
all VPN routes so they can be reevaluated to determine whether they should be kept or
discarded.
Related • IGP Shortcuts and VPNs

Documentation

Understanding IPv4 Route Distribution in a Layer 3 VPN
Within a VPN, the distribution of VPN-IPv4 routes occurs between the PE and CE routers
and between the PE routers (see Figure 49 on page 822).
Figure 49: Route Distribution Within a VPN
• Distribution of Routes from CE to PE Routers on page 822

• Distribution of Routes Between PE Routers on page 823
• Distribution of Routes from PE to CE Routers on page 825
Distribution of Routes from CE to PE Routers

A CE router announces its routes to the directly connected PE router. The announced
routes are in IPv4 format. The PE router places the routes into the VRF table for the VPN.
In the Junos OS, this is the routing-instance-name.inet.0 routing table, where
routing-instance-name is the configured name of the VPN.
The connection between the CE and PE routers can be a remote connection (a WAN
connection) or a direct connection (such as a Frame Relay or Ethernet connection).
CE routers can communicate with PE routers using one of the following:
• OSPF
• RIP

• BGP
• Static route
Figure 50 on page 823 illustrates how routes are distributed from CE routers to PE routers.
Router PE1 is connected to two CE routers that are in different VPNs. Therefore, it creates
two VRF tables, one for each VPN. The CE routers announce IPv4 routes. The PE router
installs these routes into two different VRF tables, one for each VPN. Similarly, Router
PE2 creates two VRF tables into which routes are installed from the two directly connected
CE routers. Router PE3 creates one VRF table because it is directly connected to only
one VPN.
Figure 50: Distribution of Routes from CE Routers to PE Routers
VPN A site 2
CE CE
VPN A site 1 VPN B site 2

CE CE
P P PE2
PE1 P
CE P PE3 CE
g017159
VPN B site 1 VPN A site 3
Distribution of Routes Between PE Routers

When one PE router receives routes advertised from a directly connected CE router, it
checks the received route against the VRF export policy for that VPN. If it matches, the
route is converted to VPN-IPv4 format—that is, the 8-byte route distinguisher is prepended
to the 4-byte VPN prefix to form a 12-byte VPN-IPv4 address. The route is then tagged
with a route target community. The PE router announces the route in VPN-IPv4 format
to the remote PE routers for use by VRF import policies. The routes are distributed using
IBGP sessions, which are configured in the provider’s core network. If the route does not
match, it is not exported to other PE routers, but can still be used locally for routing,
for example, if two CE routers in the same VPN are directly connected to the same PE
router.
The remote PE router places the route into its bgp.l3vpn.0 table if the route passes the
import policy on the IBGP session between the PE routers. At the same time, it checks
the route against the VRF import policy for the VPN. If it matches, the route distinguisher
is removed from the route, and it is placed into the VRF table (the
routing-instance-name.inet.0 table) in IPv4 format.

Figure 51 on page 824 illustrates how Router PE1 distributes routes to the other PE routers
in the provider’s core network. Router PE2 and Router PE3 each have VRF import policies
that they use to determine whether to accept routes received over the IBGP sessions
and install them in their VRF tables.
Figure 51: Distribution of Routes Between PE Routers
When a PE router receives routes advertised from a directly connected CE router (Router
PE1 in Figure 51 on page 824), it uses the following procedure to examine the route, convert
it to a VPN route, and distribute it to the remote PE routers:
1. The PE router checks the received route using the VRF export policy for that VPN.
2. If the received route matches the export policy, the route is processed as follows:
a. The route is converted to VPN-IPv4 format—that is, the 8-byte route distinguisher
is prepended to the 4-byte VPN prefix to form the 12-byte VPN-IPv4 address.
b. A route target community is added to the route.
c. The PE router advertises the route in VPN-IPv4 format to the remote PE routers.
The routes are distributed using IBGP sessions, which are configured in the provider’s
core network.
3. If the route does not match the export policy, it is not exported to the remote PE
routers, but can still be used locally for routing—for example,if two CE routers in the
same VPN are directly connected to the same PE router.

When the remote PE router receives routes advertised from another PE router (Routers
PE2 and PE3 in Figure 51 on page 824), it uses the following procedure to process the route:
1. If the route is accepted by the import policy on the IBGP session between the PE
routers, the remote PE router places the route into its bgp.l3vpn.0 table.
2. The remote PE router checks the route’s route target community against the VRF
import policy for the VPN.
3. If it matches, the route distinguisher is removed from the route, and it is placed into
the VRF table (the routing-instance-name.inet.0 table) in IPv4 format.
Distribution of Routes from PE to CE Routers

The remote PE router announces the routes in its VRF tables, which are in IPv4 format,
to its directly connected CE routers.
PE routers can communicate with CE routers using one of the following routing protocols:
• OSPF
• RIP
• BGP
• Static route
Figure 52 on page 826 illustrates how the three PE routers announce their routes to their
connected CE routers.

Figure 52: Distribution of Routes from PE Routers to CE Routers
Understanding Layer 3 VPN Forwarding Through the Core
The PE routers in the provider’s core network are the only routers that are configured to
support VPNs and hence are the only routers to have information about the VPNs. From
the point of view of VPN functionality, the provider (P) routers in the core—those P routers
that are not directly connected to CE routers—are merely routers along the tunnel between
the ingress and egress PE routers.
The tunnels can be either LDP or MPLS. Any P routers along the tunnel must support the
protocol used for the tunnel, either LDP or MPLS.
When PE-router-to-PE router forwarding is tunneled over MPLS label-switched paths

(LSPs), the MPLS packets have a two-level label stack (see Figure 53 on page 827):
• Outer label—Label assigned to the address of the BGP next hop by the IGP next hop
• Inner label—Label that the BGP next hop assigned for the packet’s destination address

Figure 53: Using MPLS LSPs to Tunnel Between PE Routers
Figure 54 on page 827 illustrates how the labels are assigned and removed:
1. When CE Router X forwards a packet to Router PE1 with a destination of CE Router Y,

the PE route identifies the BGP next hop to Router Y and assigns a label that
corresponds to the BGP next hop and identifies the destination CE router. This label
is the inner label.
2. Router PE1 then identifies the IGP route to the BGP next hop and assigns a second
label that corresponds to the LSP of the BGP next hop. This label is the outer label.
3. The inner label remains the same as the packet traverses the LSP tunnel. The outer
label is swapped at each hop along the LSP and is then popped by the penultimate
hop router (the third P router).
4. Router PE2 pops the inner label from the route and forwards the packet to Router Y.
Figure 54: Label Stack
Understanding Routing Instances for Layer 3 VPNs
To implement Layer 3 VPNs in the JUNOS Software, you configure one routing instance
for each VPN. You configure the routing instances on PE routers only. Each VPN routing
instance consists of the following components:
• VRF table—On each PE router, you configure one VRF table for each VPN.
• Set of interfaces that use the VRF table—The logical interface to each directly
connected CE router must be associated with a VRF table. You can associate more
than one interface with the same VRF table if more than one CE router in a VPN is
directly connected to the PE router.

• Policy rules—These control the import of routes into and the export of routes from the
VRF table.
• One or more routing protocols that install routes from CE routers into the VRF
table—You can use the BGP, OSPF, and RIP routing protocols, and you can use static
routes.
Configuring a VPN Tunnel for VRF Table Lookup
You can configure a VPN tunnel to facilitate VRF table lookup based on MPLS labels.
You might want to enable this functionality to forward traffic on a PE-router-to-CE-device
interface in a shared medium, where the CE device is a Layer 2 switch without IP
capabilities (for example, a metro Ethernet switch), or to perform egress filtering at the
egress PE router.
Related • Specifying the VT Interfaces Used by VPLS Routing Instances

Documentation
Introduction to Configuring Layer 3 VPNs
To configure Layer 3 virtual private network (VPN) functionality, you must enable VPN
support on the provider edge (PE) router. You must also configure any provider (P) routers
that service the VPN, and you must configure the customer edge (CE) routers so that
their routes are distributed into the VPN.
To configure Layer 3 VPNs, you include the following statements:
description text;
instance-type vrf;
protocols {
bgp {
group group-name {
peer-as as-number;
neighbor ip-address;
}
multihop ttl-value;
}
(ospf | ospf3) {
area area {
}
domain-id domain-id;
domain-vpn-tag number;
sham-link {
local address;
}
sham-link-remote address <metric number>;
}
rip {
rip-configuration;
}
}

route-distinguisher (as-number:id | ip-address:id);

router-id address;
routing-options {
autonomous-system autonomous-system {
independent-domain;
loops number;
}
forwarding-table {
}
interface-routes {
rib-group group-name;
}
martians {
destination-prefix match-type <allow>;
}
maximum-paths {
path-limit;
log-interval interval;
log-only;
threshold percentage;
}
maximum-prefixes {
prefix-limit;
log-interval interval;
log-only;
threshold percentage;
}
multipath {
vpn-unequal-cost;
}
options {
syslog (level level | upto level);
}
rib routing-table-name {
martians {
destination-prefix match-type <allow>;
}
multipath {
vpn-unequal-cost;
}
static {
defaults {
static-options;
}
route destination-prefix {
next-hop [next-hops];
static-options;
}
}
}
}
static {
defaults {
static-options;
}

policy [ policy-names ];
static-options;
}
}
vrf-advertise-selective {
family {
inet-mvpn;
inet6-mvpn;
}
}
vrf-export [ policy-names ];
vrf-import [ policy-names ];
vrf-target (community | export community-name | import community-name);
vrf-table-label;
• [edit routing-instances routing-instance-name]
• [edit logical-systems logical-system-name routing-instances routing-instance-name]
NOTE: The [edit logical-systems] hierarchy level is not applicable in ACX

Series routers.
The sham-link, sham-link-remote, and vrf-advertise-selective statements are

not applicable in ACX Series routers.
For Layer 3 VPNs, only some of the statements in the [edit routing-instances] hierarchy
are valid. For the full hierarchy, see Junos OS Routing Protocols Library.
In addition to these statements, you must enable a signaling protocol, IBGP sessions
between the PE routers, and an interior gateway protocol (IGP) on the PE and P routers.
By default, Layer 3 VPNs are disabled.
Many of the configuration procedures for Layer 3 VPNs are common to all types of VPNs.
Related • Centralized Internet Access Through Layer 3 VPNs

Documentation
• Configuring Hub-and-Spoke VPN Topologies: One Interface
• Configuring Overlapping VPNs Using Automatic Route Export
• Configuring a Full-Mesh VPN Topology with Route Reflectors
• Configuring a GRE Tunnel Interface Between a PE and CE Router
Configuring Routing Between PE and CE Routers in Layer 3 VPNs
For the PE router to distribute VPN-related routes to and from connected CE routers, you
must configure routing within the VPN routing instance. You can configure a routing

protocol—BGP, OSPF, or RIP—or you can configure static routing. For the connection to
each CE router, you can configure only one type of routing.
The following sections explain how to configure VPN routing between the PE and CE
routers:
• Configuring BGP Between the PE and CE Routers on page 831

• Configuring OSPF Between the PE and CE Routers on page 832
• Configuring OSPF Sham Links for Layer 3 VPNs on page 833
• Configuring an OSPF Domain ID on page 835
• Configuring RIP Between the PE and CE Routers on page 838
• Configuring Static Routes Between the PE and CE Routers on page 840
Configuring BGP Between the PE and CE Routers

To configure BGP as the routing protocol between the PE and the CE routers, include the
bgp statement:
bgp {
group group-name {
peer-as as-number;
neighbor ip-address;
}
}
• [edit logical-systems logical-system-name routing-instances routing-instance-name

protocols]

Series routers.
Please be aware of the following limitations regarding configuring BGP for routing
instances:
• In a VRF routing instance, do not configure the local autonomous system (AS) number
using an AS number that is already in use by a remote BGP peer in a separate VRF
routing instance. Doing so creates an autonomous system loop where all the routes
received from this remote BGP peer are hidden.
You configure the local AS number using either the autonomous-system statement
at the [edit routing-instances routing-instance-name routing-options] hierarchy level
or the local-as statement at any of the following hierarchy levels:
• [edit routing-instances routing-instance-name protocols bgp]
• [edit routing-instances routing-instance-name protocols bgp group group-name]

• [edit routing-instances routing-instance-name protocols bgp group group-name

neighbor address]
You configure the AS number for a BGP peer using the peer-as statement at the [edit
routing-instances routing-instance-name protocols bgp group group-name] hierarchy
level.
Configuring OSPF Between the PE and CE Routers

You can configure OSPF (version 2 or version 3) to distribute VPN-related routes between
PE and CE routers.
The following sections describe how to configure OSPF as a routing protocol between
the PE and the CE routers:
• Configuring OSPF Version 2 Between the PE and CE Routers on page 832

• Configuring OSPF Version 3 Between the PE and CE Routers on page 832
Configuring OSPF Version 2 Between the PE and CE Routers
To configure OSPF version 2 as the routing protocol between a PE and CE router, include
the ospf statement:
ospf {
area area {
}
}

protocols]

Series routers.
Configuring OSPF Version 3 Between the PE and CE Routers
To configure OSPF version 3 as the routing protocol between a PE and CE router, include
the ospf3 statement:
ospf3 {
area area {
}
}


protocols]

Series routers.
Configuring OSPF Sham Links for Layer 3 VPNs

When you configure OSPF between the PE and CE routers of a Layer 3 VPN, you can also
configure OSPF sham links to compensate for issues related to OSPF intra-area links.
The following sections describe OSPF sham links and how to configure them:
• OSPF Sham Links Overview on page 833

• Configuring OSPF Sham Links on page 834
• OSPF Sham Links Example on page 835
OSPF Sham Links Overview
Figure 55 on page 833 provides an illustration of when you might configure an OSPF sham
link. Router CE1 and Router CE2 are located in the same OSPF area. These CE routers are
linked together by a Layer 3 VPN over Router PE1 and Router PE2. In addition, Router CE1
and Router CE2 are connected by an intra-area link used as a backup.
OSPF treats the link through the Layer 3 VPN as an interarea link. By default, OSPF prefers
intra-area links to interarea links, so OSPF selects the backup intra-area link as the active
path. This is not acceptable in configurations where the intra-area link is not the expected
primary path for traffic between the CE routers.
An OSPF sham link is also an intra-area link, except that it is configured between the PE
routers as shown in Figure 55 on page 833. You can configure the metric for the sham link
to ensure that the path over the Layer 3 VPN is preferred to a backup path over an
intra-area link connecting the CE routers.
Figure 55: OSPF Sham Link
You should configure an OSPF sham link under the following circumstances:

• Two CE routers are linked together by a Layer 3 VPN.
• These CE routers are in the same OSPF area.
• An intra-area link is configured between the two CE routers.
If there is no intra-area link between the CE routers, you do not need to configure an OSPF
sham link.
For more information about OSPF sham links, see the Internet draft
draft-ietf-l3vpn-ospf-2547-01.txt, OSPF as the PE/CE Protocol in BGP/MPLS VPNs.
Configuring OSPF Sham Links
The sham link is an unnumbered point-to-point intra-area link and is advertised by means
of a type 1 link-state advertisement (LSA). Sham links are valid only for routing instances
and OSPF version 2.
Each sham link is identified by a combination of the local and remote sham link end-point
address and the OSPF area to which it belongs. Sham links must be configured manually.
You configure the sham link between two PE routers, both of which are within the same
VRF routing instance.
You need to specify the address for the local end point of the sham link. This address is
used as the source for the sham link packets and is also used by the remote PE router as
the sham link remote end-point.
The OSPF sham link’s local address must be specified with a loopback address for the
local VPN. The route to this address must be propagated by BGP. Specify the address
for the local end point using the local option of the sham-link statement:
sham-link {
local address;
}
• [edit routing-instances routing-instance-name protocols ospf]

protocols ospf]
The OSPF sham link’s remote address must be specified with a loopback address for
the remote VPN. The route to this address must be propagated by BGP. To specify the
address for the remote end point, include the sham-link-remote statement:
sham-link-remote address <metric number>;
• [edit routing-instances routing-instance-name protocols ospf area area-id]

protocols ospf area area-id]

Optionally, you can include the metric option to set a metric value for the remote end
point. The metric value specifies the cost of using the link. Routes with lower total path
metrics are preferred over those with higher path metrics.
You can configure a value from 1 through 65,535. The default value is 1.
OSPF Sham Links Example
This example shows how to enable OSPF sham links on a PE router.
The following is the loopback interface configuration on the PE router. The address
configured is for the local end point of the OSPF sham link:
[edit]
interfaces {
lo0 {
unit 1 {
family inet {
address 10.1.1.1/32;
}
}
}
}
The following is the routing instance configuration on the PE router, including the
configuration for the OSPF sham link. The sham-link local statement is configured with
the address for the local loopback interface:
[edit]
routing-instances {
example-sham-links {
instance-type vrf;
interface e1-1/0/2.0;
interface lo0.1;
route-distinguisher 3:4;
vrf-import vpn-red-import;
vrf-export vpn-red-export;
protocols {
ospf {
sham-link local 10.1.1.1;
area 0.0.0.0 {
sham-link-remote 10.2.2.2 metric 1;
interface e1-1/0/2.0 metric 1;
}
}
}
}
}
Configuring an OSPF Domain ID

For most OSPF configurations involving Layer 3 VPNs, you do not need to configure an
OSPF domain ID. However, for a Layer 3 VPN connecting multiple OSPF domains,
configuring OSPF domain IDs can help you control LSA translation (for Type 3 and Type 5
LSAs) between the OSPF domains and back-door paths. Each VPN routing and forwarding

(VRF) table in a PE router associated with an OSPF instance is configured with the same
OSPF domain ID. The default OSPF domain ID is the null value 0.0.0.0. As shown in
Table 51 on page 836, a route with a null domain ID is handled differently from a route
without any domain ID at all.
Table 51: How a PE Router Redistributes and Advertises Routes

Domain ID of the Domain ID on the Route Redistributed
Route Received Route Received Receiving Router and Advertised As
Type 3 route A.B.C.D A.B.C.D Type 3 LSA
Type 3 route A.B.C.D E.F.G.H Type 5 LSA
Type 3 route 0.0.0.0 0.0.0.0 Type 3 LSA
Type 3 route Null 0.0.0.0 Type 3 LSA
Type 3 route Null Null Type 3 LSA
Type 3 route 0.0.0.0 Null Type 3 LSA
Type 3 route A.B.C.D Null Type 5 LSA
Type 3 route Null A.B.C.D Type 5 LSA
Type 5 route Not applicable Not applicable Type 5 LSA
You can configure an OSPF domain ID for both version 2 and version 3 of OSPF. The only
difference in the configuration is that you include statements at the [edit routing-instances
routing-instance-name protocols ospf] hierarchy level for OSPF version 2 and at the
[edit routing-instances routing-instance-name protocols ospf3] hierarchy level for OSPF
version 3. The configuration descriptions that follow present the OSPF version 2 statement
only. However, the substatements are also valid for OSPF version 3.
To configure an OSPF domain ID, include the domain-id statement:
domain-id domain-Id;

protocols ospf]
You can set a VPN tag for the OSPF external routes generated by the PE router to prevent
looping. By default, this tag is automatically calculated and needs no configuration.
However, you can configure the domain VPN tag for Type 5 LSAs explicitly by including
the domain-vpn-tag statement:
no-domain-vpn-tag number;


protocols ospf]
32
The range is 1 through 4,294,967,295 (2 – 1). If you set VPN tags manually, you must
set the same value for all PE routers in the VPN.
For an example of this type of configuration, see Configuring an OSPF Domain ID for a
Layer 3 VPN.
Hub-and-Spoke Layer 3 VPNs and OSPF Domain IDs
The default behavior of an OSPF domain ID causes some problems for hub-and-spoke
Layer 3 VPNs configured with OSPF between the hub PE router and the hub CE router
when the routes are not aggregated. A hub-and-spoke configuration has a hub PE router
with direct links to a hub CE router. The hub PE router receives Layer 3 BGP updates from
the other remote spoke PE routers, and these are imported into the spoke routing instance.
From the spoke routing instance, the OSPF LSAs are originated and sent to the hub CE
router.
The hub CE router typically aggregates these routes, and then sends these newly
originated LSAs back to the hub PE router. The hub PE router exports the BGP updates
to the remote spoke PE routers containing the aggregated prefixes. However, if there are
nonaggregated Type 3 summary LSAs or external LSAs, two issues arise with regard to
how the hub PE router originates and sends LSAs to the hub CE router, and how the hub
PE router processes LSAs received from the hub CE router:
• By default, all LSAs originated by the hub PE router in the spoke routing instance have
the DN bit set. Also, all externally originated LSAs have the VPN route tag set. These
settings help prevent routing loops. For Type 3 summary LSAs, routing loops are not
a concern because the hub CE router, as an area border router (ABR), reoriginates the
LSAs with the DN bit clear and sends them back to the hub PE router. However, the
hub CE router does not reoriginate external LSAs, because they have an AS flooding
scope.
You can originate the external LSAs (before sending them to the hub CE router) with
the DN bit clear and the VPN route tag set to 0 by altering the hub PE router’s routing
instance configuration. To clear the DN bit and set the VPN route tag to zero on external
LSAs originated by a PE router, configure 0 for the domain-vpn-tag statement at the
[edit routing-instances routing-instance-name protocols ospf] hierarchy level. You should
include this configuration in the routing instance on the hub PE router facing the hub
CE router where the LSAs are sent. When the hub CE router receives external LSAs
from the hub PE router and then forwards them back to the hub PE router, the hub PE
router can use the LSAs in its OSPF route calculation.
• When LSAs flooded by the hub CE router arrive at the hub PE router’s routing instance,
the hub PE router, acting as an ABR, does not consider these LSAs in its OSPF route
calculations, even though the LSAs do not have the DN bits set and the external LSAs

do not have a VPN route tag set. The LSAs are assumed to be from a disjoint backbone
area.
You can change the configuration of the PE router’s routing instance to cause the PE
router to act as a non-ABR by including the disable statement at the [edit
routing-instances routing-instance-name protocols ospf domain-id] hierarchy level. You
make this configuration change to the hub PE router that receives the LSAs from the
hub CE router.
By making this configuration change, the PE router’s routing instance acts as a non-ABR.
The PE router then considers the LSAs arriving from the hub CE router as if they were
coming from a contiguous nonbackbone area.
Configuring RIP Between the PE and CE Routers

For a Layer 3 VPN, you can configure RIP on the PE router to learn the routes of the CE
router or to propagate the routes of the PE router to the CE router. RIP routes learned
from neighbors configured at any [edit routing-instances] hierarchy level are added to
the routing instance’s inet table (instance_name.inet.0).
To configure RIP as the routing protocol between the PE and the CE router, include the
rip statement:
rip {
group group-name {
export policy-names;
neighbor interface-name;
}
}

protocols]

Series routers.
By default, RIP does not advertise the routes it receives. To advertise routes from a PE
router to a CE router, you need to configure an export policy on the PE router for RIP. For
information about how to define policies for RIP, see Example: Applying Policies to RIP
Routes Imported from Neighbors.
To specify an export policy for RIP, include the export statement:
You can include this statement for RIP at the following hierarchy levels:
• [edit routing-instances routing-instance-name protocols rip group group-name]


protocols rip group group-name]

Series routers.
To install routes learned from a RIP routing instance into multiple routing tables, include
the rib-group and group statements:
rib-group inet group-name;

group group-name {
neighbor interface-name;
}
• [edit logical-systems logical-system-name protocols]

protocols]

Series routers.
To configure a routing table group, include the rib-groups statement:
rib-groups group-name;
• [edit routing-options]
• [edit logical-systems logical-system-name routing-options]

Series routers.
To add a routing table to a routing table group, include the import-rib statement. The
first routing table name specified under the import-rib statement must be the name of
the routing table you are configuring. For more information about how to configure routing
tables and routing table groups, see Junos OS Routing Protocols Library.
import-rib [ group-names ];

• [edit routing-options rib-groups group-name]
• [edit logical-systems logical-system-name routing-options rib-groups group-name]

Series routers.
RIP instances are supported only for VRF instance types. You can configure multiple
instances of RIP for VPN support only. You can use RIP in the customer edge-provider
edge (CE-PE) environment to learn routes from the CE router and to propagate the PE
router’s instance routes in the CE router.
RIP routes learned from neighbors configured under any instance hierarchy are added to
the instance’s routing table, instance-name.inet.0.
RIP does not support routing table groups; therefore, it cannot import routes into multiple
tables as the OSPF or OSPFv3 protocol does.
Configuring Static Routes Between the PE and CE Routers

You can configure static (nonchanging) routes between the PE and CE routers of a VPN
routing instance. To configure a static route for a VPN, you need to configure it within the
VPN routing instance configuration at the [edit routing-instances routing-instance-name
routing-options] hierarchy level.
To configure a static route between the PE and the CE routers, include the static
statement:
static {
next-hop [ next-hops ];
static-options;
}
}
• [edit routing-instances routing-instance-name routing-options]

routing-options]

Series routers.
For more information about configuring routing protocols and static routes, see Junos
OS Routing Protocols Library.

Limiting the Number of Paths and Prefixes Accepted from CE Routers in Layer 3 VPNs
You can configure a maximum limit on the number of prefixes and paths that can be
installed into the routing tables. Using prefix and path limits, you can curtail the number
of prefixes and paths received from a CE router in a VPN. Prefix and path limits apply
only to dynamic routing protocols, and are not applicable to static or interface routes.
To limit the number of paths accepted by a PE router from a CE router, include the
maximum-paths statement:
maximum-paths path-limit <log-interval interval | log-only | threshold percentage>;
For a list of hierarchy levels at which you can configure this statement, see the statement
Specify the log-only option to generate warning messages only (an advisory limit). Specify
the threshold option to generate warnings before the limit is reached. Specify the
log-interval option to configure the minimum time interval between log messages.
There are two modes for route limits: advisory and mandatory. An advisory limit triggers
warnings. A mandatory limit rejects additional routes after the limit is reached.
NOTE: Application of a route limit may result in unpredictable dynamic routing

protocol behavior. For example, when the limit is reached and routes are
rejected, BGP may not reinstall the rejected routes after the number of routes
drops back below the limit. BGP sessions may need to be cleared.
To limit the number of prefixes accepted by a PE router from a CE router, include the
maximum-prefixes statement:
maximum-prefixes prefix-limit <log-interval interval | log-only | threshold percentage>;
There are two modes for route limits: advisory and mandatory. An advisory limit triggers
warnings. A mandatory limit rejects additional routes after the limit is reached.
NOTE: Application of a route limit may result in unpredictable dynamic routing

protocol behavior. For example, when the limit is reached and routes are
rejected, BGP may not reinstall the rejected routes after the number of routes
drops back below the limit. BGP sessions may need to be cleared.
A mandatory path or prefix limit, in addition to triggering a warning message, rejects any
additional paths or prefixes once the limit is reached.

NOTE: Setting a path or prefix limit might result in unpredictable dynamic

routing protocol behavior.
You can also configure the following options for both the maximum-paths and
maximum-prefixes statements:
• log-interval—Specify the interval at which log messages are sent. This option generates
warning messages only (an advisory limit).
Specify the log-interval option to configure the minimum time interval between log
messages.
• log-only—Generate warning messages only. No limit is placed on the number of paths

or prefixes stored in the routing tables.
• threshold—Generate warning messages after the specified percentage of the maximum

paths or prefixes has been reached.
Understanding IPv6 Layer 3 VPNs
The interfaces between the PE and CE routers of a Layer 3 VPN can be configured to
carry IP version 6 (IPv6) traffic. IP allows numerous nodes on different networks to
interoperate seamlessly. IPv4 is currently used in intranets and private networks, as well
as the Internet. IPv6 is the successor to IPv4, and is based for the most part on IPv4.
In the Juniper Networks implementation of IPv6, the service provider implements an

MPLS-enabled IPv4 backbone to provide VPN service for IPv6 customers. The PE routers
have both IPv4 and IPv6 capabilities. They maintain IPv6 VPN routing and forwarding
(VRF) tables for their IPv6 sites and encapsulate IPv6 traffic in MPLS frames that are
then sent into the MPLS core network.
IPv6 for Layer 3 VPNs is supported for BGP and for static routes.
IPv6 over Layer 3 VPNs is described in RFC 4659, BGP-MPLS IP Virtual Private Network
(VPN) Extension for IPv6 VPN.
Related • Routing Policies, Firewall Filters, and Traffic Policers Feature Guide
Documentation
• Junos OS Routing Protocols Library
Layer 3 VPNs for IPv4 and IPv6 Overview
A Layer 3 virtual private network (VPN) routing instance is a collection of routing tables,
interfaces, and routing protocol parameters. The interfaces belong to the routing tables,
and the routing protocol parameters control the information in the routing tables. In the
case of MPLS VPNs, each VPN has a VPN routing and forwarding (VRF) routing instance.
A VRF routing instance consists of one or more routing tables, a derived forwarding table,
the interfaces that use the forwarding table, and the policies and routing protocols that

determine what goes into the forwarding table. Because each instance is configured for
a particular VPN, each VPN has separate tables, rules, and policies that control its
operation. A separate VRF table is created for each VPN that has a connection to a
customer edge (CE) router. The VRF table is populated with routes received from directly
connected CE sites associated with the VRF routing instance, and with routes received
from other provider edge (PE) routers in the same VPN.
The standard or the global instance is called as the default routing instance. By default,
all interfaces are associated with the default routing instance and default routing
information base (RIB) (inet0). Routing options and routing policies supported on the
default routing instance are also applicable to other routing instances.
A VRF routing instance is a BGP and MPLS VPN environment in which BGP is used to
exchange IP VPN routes and discover the remote site, and in which VPN traffic traverses
an MPLS tunnel in an IP and MPLS backbone. You can enable an ACX Series router to
function as a PE router by configuring VRF routing instances.
You can configure routing instances on ACX Series routers at the [edit routing-instances
routing-instance-name protocols] hierarchy level for unicast IPv4, multicast IPv4, unicast
IPv6, and multicast IPv6 address families. If you do not explicitly specify the address
family in an IPv4 or an IPv6 environment, the router is configured to exchange unicast
IPv4 or unicast IPv6 addresses by default. You can also configure the router to exchange
unicast IPv4 and unicast IPv6 routes in a specified VRF routing instance. If you specify
the multicast IPv4 or multicast IPv6 address family in the configuration, you can use BGP
to exchange routing information about how packets reach a multicast source, instead
of a unicast destination, for transmission to endpoints.
NOTE: Only the forwarding and virtual router routing instances support
unicast IPv6 and multicast IPv6 address families. Unicast IPv6 and multicast
IPv6 address families are not supported for VRF routing instances.
You can configure the following types of Layer 3 routing instances on ACX Series routers:
• Forwarding—Use this routing instance type for filter-based forwarding applications.

For this instance type, there is no one-to-one mapping between an interface and a
routing instance. All interfaces belong to the default instance inet.0. There are multiple
forwarding tables and the selection of a table depends on the filter applied on the
interface.
• Virtual router—A virtual router routing instance is similar to a VRF instance type, but is
used for non-VPN-related applications. There are no VRF import, VRF export, VRF
target, or route distinguisher requirements for this instance type. For this instance type,
there is a one-to-one mapping between an interface and a routing instance. This routing
instance type is used for routing and forwarding virtualization without VPNs (which is
achieved by using the VRF-Lite application).
• VRF—Use the VRF routing instance type for Layer 3 VPN implementations. This routing
instance type has a VPN routing table as well as a corresponding VPN forwarding table.
For this instance type, there is a one-to-one mapping between an interface and a
routing instance. Each VRF routing instance corresponds with a forwarding table. The

routes for each interface are installed in the forwarding table that is associated with
the VRF routing instance. This routing instance type is used to implement BGP or MPLS
VPNs in service provider networks or in big enterprise topologies.
Consider a sample VRF configuration scenario in which you want to configure two virtual
routers, one to transmit voice and data traffic and another to carry management traffic.
With such a configuration, the user and management networks are virtually separated,
although the physical infrastructure is unified and cohesive. Virtual router routing instances
enable you to isolate traffic without using multiple devices to segment your networks.
The virtual routers do not create IP, MPLS, or GRE tunnels, and automatic discovery of
remote sites that belong to the same network is not available. You must configure
interfaces that are part of a virtual network in a streamlined manner to suit your topology
requirements.
The following limitations apply to VRF routing instances that you configure on ACX Series
routers:
• You cannot establish a communication between two virtual routing instances that are
connected by external loopback.
• You cannot add a GRE or an MPLS tunnel to a virtual router.
In the Layer 3 lookup, up to 128 VRF tables are supported. Virtual routers without routing
protocols enabled (based on static routes) support 64 VRF tables and virtual routers
with all functions enabled within the routing instances support 16 VRF tables. When you
enable VRF table labels and you do not explicitly apply a classifier configuration to the
routing instance, the default MPLS EXP classifier is applied to the routing instance. You
can override the default MPLS EXP classifier and apply a custom classifier to the routing
instance. To perform this operation, you can filter the packets based on the IP header,
choose the VRF, and based on the selected VRF, create an EXP classifier and associate
it with the routing instance.
Related • Routing Instances Overview

Documentation
• Configuring Virtual-Router Routing Instances in VPNs
• Applying MPLS EXP Classifiers to Routing Instances
• Configuring Routing Instances on PE Routers in VPNs
Configuring Layer 3 VPNs to Carry IPv6 Traffic
You can configure IP version 6 (IPv6) between the PE and CE routers of a Layer 3 VPN.
The PE router must have the PE router to PE router BGP session configured with the
family inet6-vpn statement. The CE router must be capable of receiving IPv6 traffic. You
can configure BGP or static routes between the PE and CE routers.

The following sections explains how to configure IPv6 VPNs between the PE routers:
• Configuring IPv6 on the PE Router on page 845

• Configuring the Connection Between the PE and CE Routers on page 845
• Configuring IPv6 on the Interfaces on page 847
Configuring IPv6 on the PE Router

To configure IPv6 between the PE and CE routers, include the family inet6-vpn statement
in the configuration on the PE router:
family inet6-vpn {
(any | multicast | unicast) {
aggregate-label community community-name;
prefix-limit maximum prefix-limit;
rib-group rib-group-name;
}
}
You also must include the ipv6-tunneling statement:
ipv6-tunneling;
• [edit protocols mpls]
• [edit logical-systems logical-system-name protocols mpls]
Configuring the Connection Between the PE and CE Routers

To support IPv6 routes, you must configure BGP, OSPF version 3, IS-IS, or static routes
for the connection between the PE and CE routers in the Layer 3 VPN. You can configure
BGP to handle just IPv6 routes or both IP version 4 (IPv4) and IPv6 routes.
For more information about IPv6, see Junos OS Routing Protocols Library.
For more information about IS-IS see Example: Configuring IS-IS,
The following sections explain how to configure BGP and static routes:
• Configuring BGP on the PE Router to Handle IPv6 Routes on page 845

• Configuring BGP on the PE Router for IPv4 and IPv6 Routes on page 846
• Configuring OSPF Version 3 on the PE Router on page 846
• Configuring Static Routes on the PE Router on page 847
Configuring BGP on the PE Router to Handle IPv6 Routes
To configure BGP in the Layer 3 VPN routing instance to handle IPv6 routes, include the
bgp statement:

bgp {
group group-name {
local-address IPv6-address;
family inet6 {
unicast;
}
peer-as as-number;
neighbor IPv6-address;
}
}

protocols]
Configuring BGP on the PE Router for IPv4 and IPv6 Routes
To configure BGP in the Layer 3 VPN routing instance to handle both IPv4 and IPv6 routes,
include the bgp statement:
bgp {
group group-name {
local-address IPv4-address;
family inet {
unicast;
}
family inet6 {
unicast;
}
peer-as as-number;
neighbor address;
}
}

protocols]

Series routers.
Configuring OSPF Version 3 on the PE Router
To configure OSPF version 3 in the Layer 3 VPN routing instance to handle IPv6 routes,
include the ospf3 statement:
ospf3 {
area area-id {

}
}

protocols]

Series routers.
For complete configuration guidelines for this statement, see the Junos OS Routing
Protocols Library.
Configuring Static Routes on the PE Router
To configure a static route to the CE router in the Layer 3 VPN routing instance, include
the routing-options statement:
routing-options {
rib routing-table.inet6.0 {
static {
defaults {
static-options;
}
}
}
}

Series routers.
Configuring IPv6 on the Interfaces

You need to configure IPv6 on the PE router interfaces to the CE routers and on the CE
router interfaces to the PE routers.
To configure the interface to handle IPv6 routes, include the family inet6 statement:
family inet6 {
address ipv6-address;
}

• [edit interfaces interface-name unit unit-number]
• [edit logical-systems logical-system-name interfaces interface-name unit unit-number]

Series routers.
If you have configured the Layer 3 VPN to handle both IPv4 and IPv6 routes, configure
the interface to handle both IPv4 and IPv6 routes by including the unit statement:
unit unit-number {
family inet {
}
family inet6 {
}
}
• [edit logical-systems logical-system-name interfaces interface-name]

Series routers.
Configuring EBGP Multihop Sessions Between PE and CE Routers in Layer 3 VPNs
You can configure an EBGP or IBGP multihop session between the PE and CE routers of
a Layer 3 VPN. This allows you to have one or more routers between the PE and CE
routers. Using IBGP between PE and CE routers does not require the configuration of any
additional statements. However, using EBGP between the PE and CE routers requires
the configuration of the multihop statement.
To configure an external BGP multihop session for the connection between the PE and
CE routers, include the multihop statement on the PE router. To help prevent routing
loops, you have to configure a time-to-live (TTL) value for the multihop session:
multihop ttl-value;
For the list of hierarchy levels at which you can configure this statement, see the summary
section for this statement.

Configuring Layer 3 VPNs to Carry IBGP Traffic
An independent AS domain is separate from the primary routing instance domain. An AS

is a set of routers that are under a single technical administration and that generally use
a single IGP and metrics to propagate routing information within the set of routers. An
AS appears to other ASs to have a single, coherent interior routing plan and presents a
consistent picture of what destinations are reachable through it.
Configuring an independent domain allows you to keep the AS paths of the independent
domain from being shared with the AS path and AS path attributes of other domains,
including the master routing instance domain.
If you are using BGP on the router, you must configure an AS number.
When you configure BGP as the routing protocol between a PE router and a CE router in
a Layer 3 VPN, you typically configure external peering sessions between the Layer 3 VPN
service provider and the customer network ASs.
If the customer network has several sites advertising routes through an external BGP
session to the service provider network and if the same AS is used by all the customer
sites, the CE routers reject routes from the other CE routers. They detect a loop in the
BGP AS path attribute.
To prevent the CE routers from rejecting each other’s routes, you could configure the
following:
• PE routers advertising routes received from remote PE routers can remap the customer
network AS number to its own AS number.
• AS path loops can be configured.
• The customer network can be configured with different AS numbers at each site.
These types of configurations can work when there are no BGP routing exchanges between
the customer network and other networks. However, they do have limitations for customer
networks that use BGP internally for purposes other than carrying traffic between the
CE routers and the PE routers. When those routes are advertised outside the customer
network, the service provider ASs are present in the AS path.
To improve the transparency of Layer 3 VPN services for customer networks, you can
configure the routing instance for the Layer 3 VPN to isolate the customer’s network
attributes from the service provider’s network attributes.
When you include the independent-domain statement in the Layer 3 VPN routing instance
configuration, BGP attributes received from the customer network (from the CE router)
are stored in a BGP attribute (ATTRSET) that functions like a stack. When that route is
advertised from the remote PE router to the remote CE router, the original BGP attributes
are restored. This is the default behavior for BGP routes that are advertised to Layer 3
VPNs located in different domains.
This functionality is described in the Internet draft draft-marques-ppvpn-ibgp-version.txt,

RFC 2547bis Networks Using Internal BGP as PE-CE Protocol.

To allow a Layer 3 VPN to transport IBGP traffic, include the independent-domain

statement:
independent-domain;
• [edit routing-instances routing-instance-name routing-options autonomous-system

number]

routing-options autonomous-system number]
NOTE: All PE routers participating in a Layer 3 VPN with the

independent-domain statement in its configuration must be running Junos
OS Release 6.3 or later.

Series routers.
The independent domain uses the transitive path attribute 128 (attribute set) to tunnel
the independent domain’s BGP attributes through the Internal BGP (IBGP) core. In Junos
OS Release 10.3 and later, if BGP receives attribute 128 and you have not configured an
independent domain in any routing instance, BGP treats the received attribute 128 as an
unknown attribute.
There is a limit of 16 ASs for each domain.
Related • Example: Tunneling Layer 3 VPN IPv6 Islands over an IPv4 Core Using IBGP and
Documentation Independent Domains
• Disabling Attribute Set Messages on Independent AS Domains for BGP Loop Detection
Configuring a Label Allocation and Substitution Policy for VPNs
You can control label-advertisements on MPLS ingress and AS border routers (ASBRs).
Labels can be assigned on a per–next-hop (by default) or on a per-table basis (by
configuring the vrf-table-label statement). This choice affects all routes of a given routing
instance. You can also configure a policy to generate labels on a per-route basis by
specifying a label allocation policy.
To specify a label allocation policy for the routing instance, configure the label statement
and specify a label allocation policy using the allocation option:
label {
allocation label-allocation-policy;
}

You can configure this statement at the following hierarchy levels:

routing-options]

Series routers.
To configure the label allocation policy, include the label-allocation statement at the
[edit policy-options policy-statement policy-statement-name term term-name then]
hierarchy level. You can configure the label allocation mode as either per-nexthop or
per-table.
For a VPN option B ASBR, labels for transit routes are substituted for a local virtual tunnel
label or vrf-table-label label. When a VRF table is configured on the ASBR (this type of
configuration is uncommon for the option B model), the ASBR does not generate MPLS
swap or swap and push state for transit routes. Instead, the ASBR re-advertises a local
virtual-tunnel or vrf-table-label label and forwards that transit traffic based on IP
forwarding tables. The label substitution helps to conserve labels on Juniper Networks
routers.
However, this type of label substitution effectively breaks the MPLS forwarding path,
which becomes visible when using an MPLS OAM command such as LSP ping. You can
configure the way in which labels are substituted on a per-route basis by specifying a
label substitution policy.
To specify a label substitution policy for the routing instance, configure the label statement
and specify a label substitution policy using the substitution option:
label {
substitution label-substitution-policy;
}
You can configure this statement at the following hierarchy levels:

routing-options]

Series routers.
The label substitution policy is used to determine whether or not a label should be
substituted on an ASBR router. The results of the policy operation are either accept (label
substitution is performed) or reject (label substitution is not performed). The default
behavior is accept. The following set command example illustrates how you can configure

a reject label substitution policy: set policy-options policy-statement no-label-substitution

term default then reject.
Configuring Protocol-Independent Load Balancing in Layer 3 VPNs
Protocol-independent load balancing for Layer 3 VPNs allows the forwarding next hops
of both the active route and alternative paths to be used for load balancing.
Protocol-independent load balancing works in conjunction with Layer 3 VPNs. It supports
the load balancing of VPN routes independently of the assigned route distinguisher. When
protocol-independent load balancing is enabled, both routes to other PE routers and
routes to directly connected CE routers are load-balanced.
When load-balancing information is created for a given route, the active path is marked
as Routing Use Only in the output of the show route table command.
The following sections describe how to configure protocol-independent load balancing

and how this configuration can affect routing policies:
• Configuring Load Balancing for Layer 3 VPNs on page 852

• Configuring Load Balancing and Routing Policies on page 854
Configuring Load Balancing for Layer 3 VPNs

The configuration of protocol-independent load balancing for Layer 3 VPNs is a little
different for IPv4 versus IPv6:
• IPv4—You only need to configure the multipath statement at either the [edit
routing-instances routing-instance-name routing-options] hierarchy level or the [edit
routing-instances routing-instance-name routing-options rib routing-table-name] hierarchy
level.
• IPv6—You need to configure the multipath statement at both the [edit routing-instances
routing-instance-name routing-options] hierarchy level and the [edit routing-instances
routing-instance-name routing-options rib routing-table-name] hierarchy level.
NOTE: You cannot configure the multipath statement and sub-statements

at the same time that you have configured the l3vpn statement.
To configure protocol-independent load balancing for Layer 3 VPNs, include the multipath
statement:
multipath {
vpn-unequal-cost equal-external-internal;
}
When you include the multipath statement at the following hierarchy levels,
protocol-independent load balancing is applied to the default routing table for that
routing instance (routing-instance-name.inet.0):

routing-options]


Series routers.
When you include the multipath statement at the following hierarchy levels,
protocol-independent load balancing is applied to the specified routing table:
• [edit routing-instances routing-instance-name routing-options rib routing-table-name]

routing-options rib routing-table-name]

Series routers.
The vpn-unequal-cost statement is optional:
• When you include it, protocol-independent load balancing is applied to VPN routes
that are equal until the IGP metric with regard to route selection.
• When you do not include it, protocol-independent load balancing is applied to VPN
routes that are equal until the router identifier with regard to route selection.
NOTE: The vpn-unequal-cost statement is not applicable in ACX Series

routers.
The equal-external-internal statement is also optional. When you include it,

protocol-independent load balancing is applied to both internal and external BGP paths.
You can configure this in conjunction with egress IP header filtering (enabled with the
vrf-table-label statement). For more information, see Load Balancing and IP Header
Filtering for Layer 3 VPNs.
NOTE: You can include the vpn-unequal-cost equal-external-internal statement

and the l3vpn statement at the [edit routing-options forwarding-options
chained-composite-next-hop ingress] hierarchy level simultaneously. However,
if you do this, EBGP does not work. This means that when there are both
paths with chained next hops and paths with nonchained next hops as
candidates for EBGP equal-cost multipath (ECMP), the paths using chained
next hops are excluded. In a typical case, the excluded paths are the internal
paths.

Configuring Load Balancing and Routing Policies

If you enable protocol-independent load balancing for Layer 3 VPNs by including the
multipath statement and if you also include the load-balance per-packet statement in
the routing policy configuration, packets are not load-balanced.
For example, a PE router has the following VRF routing instance configured:
[edit routing-instances]
load-balance-example {
instance-type vrf;
route-distinguisher 2222:2;
vrf-target target:2222:2;
routing-options {
multipath;
}
protocols {
bgp {
group group-example {
import import-policy;
family inet {
unicast;
}
export export-policy;
peer-as 4444;
local-as 3333;
multipath;
as-override;
neighbor 10.12.33.22;
}
}
}
}
The PE router also has the following policy statement configured:
[edit policy-options policy-statement export-policy]

from protocol bgp;
then {
}
When you include the multipath statement in the VRF routing instance configuration, the
paths are no longer marked as BGP paths but are instead marked as multipath paths.
Packets from the PE router are not load-balanced.
To ensure that VPN load-balancing functions as expected, do not include the from
protocol statement in the policy statement configuration. The policy statement should
be configured as follows:
[edit policy-options policy-statement export-policy]

then {
}

For more information about how to configure per-packet load balancing, see the Routing
Policies, Firewall Filters, and Traffic Policers Feature Guide.
Related • VPN Per-Packet Load Balancing

Documentation
• Routing Policies, Firewall Filters, and Traffic Policers Feature Guide
Configuring the Algorithm That Determines the Active Route to Evaluate AS Numbers
in AS Paths for VPN Routes
By default, the third step of the algorithm that determines the active route evaluates the
length of the AS path but not the contents of the AS path. In some VPN scenarios with
BGP multiple path routes, it can also be useful to compare the AS numbers of the AS
paths and to have the algorithm select the route whose AS numbers match.
To configure the algorithm that selects the active path to evaluate the AS numbers in
AS paths for VPN routes:
• Include the as-path-compare statement at the [edit routing-instances

routing-instance-name routing-options multipath] hierarchy level.
NOTE: The as-path-compare statement is not supported for the default

routing instance.
Related • as-path-compare on page 1433

Documentation
Accepting Route Updates with Unique Inner VPN Labels in Layer 3 VPNs
For Layer 3 VPNs configured on Juniper Networks routers, Junos OS normally allocates
one inner VPN label for each customer edge (CE)-facing virtual routing and forwarding
(VRF) interface of a provider edge (PE) router. However, other vendors allocate one VPN
label for each route learned over the CE-facing interfaces of a PE router. This practice
increases the number of VPN labels exponentially, which leads to slow system processing
and slow convergence time.
Next-hop chaining (also known as “chained composite next hop”) is a composition

function that concatenates the partial rewrite strings associated with individual next
hops to form a larger rewrite string that is added to a packet. By using this function, the
number of routes with unique inner VPN labels that can be processed by a Juniper
Networks router is increased substantially. Common route update elements associated
with Layer 3 VPNs are combined, reducing the number of route updates and individual
states the Juniper Networks router must maintain, and leading to enhanced scaling and
convergence performance.

NOTE: ACX Series routers supports chained-composite-next-hop ingress CLI

statement at the [edit routing-options forwarding-table] hierarchy level only
for Layer 3 VPNs. The chained-composite-next-hop ingress CLI statement for
Layer 2 services is not supported.
You can configure the router based on the number of VPN labels you want to manage
and on whether or not you want to create chained composite next hops for IPv6 labeled
routes:
• Accepting Up to One Million Layer 3 VPN Route Updates on page 856

• Accepting More Than One Million Layer 3 VPN Route Updates on page 857
• Enabling Chained Composite Next Hops for IPv6 Labeled Unicast Routes on page 859
Accepting Up to One Million Layer 3 VPN Route Updates

For Juniper Networks routers participating in a mixed vendor network with up to one
million Layer 3 VPN labels, include the l3vpn statement at the [edit routing-options
forwarding-table chained-composite-next-hop ingress] hierarchy level. The l3vpn statement
is disabled by default.
NOTE: ACX Series routers do not support chained-composite-next-hop ingress

CLI statement at the [edit routing-options forwarding-table] hierarchy level.
BEST PRACTICE: We recommend that you configure the l3vpn statement

whenever you have deployed Juniper Networks routers in mixed vendor
networks of up to one million routes to support Layer 3 VPNs.
Because using this statement can also enhance the Layer 3 VPN performance
are deployed, we recommend configuring the statements in these networks
as well.
You can configure the l3vpn statement on the following routers:
• ACX Series routers
• M120 routers
• M320 routers with one or more Enhanced III FPCs
• T Series routers (for Junos OS Release 10.4 and later)

To accept up to one million Layer 3 VPN route updates with unique inner VPN labels,
configure the l3vpn statement. This statement is supported on indirectly connected PE
routers only. Configuring this statement on a router that is directly connected to a PE
router provides no benefit. You can configure the l3vpn statement on a router with a mix
of links to both directly connected and indirectly connected PE routers.
NOTE: You cannot configure the l3vpn statement and sub-statements at

same time that you have configured the vpn-unequal-cost statement.
To configure the router to accept up to one million Layer 3 VPN route updates with unique
inner VPN labels:

user@host>set l3vpn
2. To enhance memory allocation to support a larger number of Layer 3 VPN labels,

include the vpn-label statement.
[edit chassis memory-enhanced]

user@host>set vpn-label
NOTE: The vpn-label statement does not provide any functional changes
when used on the MX Series routers. You can omit the configuration of
this statement on MX Series routers.
For more information about configuring more memory for Layer 3 VPN labels, see the
Junos OS Administration Library.
After you have configured the l3vpn statement, you can determine whether or not a Layer
following commands:
Accepting More Than One Million Layer 3 VPN Route Updates

For Juniper Networks routers participating in a mixed vendor network with more than one
million Layer 3 VPN labels, include the extended-space statement at the [edit
routing-options forwarding-table chained-composite-next-hop ingress l3vpn] hierarchy
level. The extended-space statement is disabled by default.
NOTE: The chained-composite-next-hop ingress and extended-space

statements are not supported on ACX Series routers.

BEST PRACTICE: We recommend that you configure the extended-space

statement in mixed vendor networks containing more than one million routes
to support Layer 3 VPNs. However, b
Because using this statements can also enhance the Layer 3 VPN performance
are deployed, we recommend configuring the statement in these networks
as well.
Using the extended-space statement can double the number of routes with unique inner
VPN labels that can be processed by a Juniper Networks router. However, when configuring
such very large-scale Layer 3 VPN scenarios, keep the following guidelines in mind:
• The extended-space statement is supported only on MX Series routers containing only

MPCs.
• The chassis must be configured to use the enhanced-ip option in network services
mode.
For more information about configuring chassis network services, see the Junos OS
Administration Library.
• Ensure that you configure per-packet load balancing for associated policies.
For more information about configuring policies, see the Routing Policies, Firewall Filters,
and Traffic Policers Feature Guide.
BEST PRACTICE: We strongly recommend using 64-bit routing engines

running 64-bit Junos OS to support Layer 3 VPN prefixes with unique inner
VPN labels at higher scale.
To configure the router to accept more than one million Layer 3 VPN route updates with
unique inner VPN labels:

user@host>set l3vpn
2. Include the extended-space statement.
[edit routing-options forwarding-table chained-composite-next-hop ingress l3vpn]

user@host> set extended-space
3. Configure chassis network services for enhanced mode.
[edit chassis]
user@host>set network-services enhanced-ip

NOTE: A router reboot might be required. See Network Services Mode

Overview in the Junos OS Administration Library for details.
After you have completed the configuration, you can determine whether or not a Layer
following commands:
Enabling Chained Composite Next Hops for IPv6 Labeled Unicast Routes
You can enable chained composite next hops for IPv6 labeled unicast routes by
configuring the labeled-bgp and inet6 statements:
• To enable chained composite next hops for inet6 labeled unicast routes, include the
inet6 statement at the [edit routing-options forwarding-table
chained-composite-next-hop ingress labeled-bgp] hierarchy level. This statement is
disabled by default.
Related • Chained Composite Next Hops for Transit Devices for VPNs
Documentation
• Configuring the Junos OS to Allocate More Memory for Routing Tables, Firewall Filters,
and Layer 3 VPN Labels
• Network Services Mode Overview
• Configuring Junos OS to Run a Specific Network Services Mode in MX Series Routers


PART 7
Configuring Class of Service on ACX Series

Routers
• Configuring Class of Service on page 863
• Configuring Behavior Aggregate Classifiers on page 949


CHAPTER 27
Configuring Class of Service
• CoS on ACX Series Universal Access Routers Features Overview on page 864
• Understanding CoS CLI Configuration Statements on ACX Series Universal Access
Routers on page 865
• Configuring CoS on ACX Series Universal Access Routers on page 866
• Classifiers and Rewrite Rules at the Global, Physical and Logical Interface Levels
• Configuring Classifiers and Rewrite Rules at the Global and Physical Interface
Levels on page 872
• Understanding Schedulers Overview on page 874
• Configuring Shared and Dedicated Buffer Memory Pools on page 876
• CoS for PPP and MLPPP Interfaces on ACX Series Routers on page 877
• CoS for NAT Services on ACX Series Universal Access Routers on page 887
• Configuring the IEEE 802.1p Field for CoS Host Outbound Traffic in ACX
Series on page 889
• Configuring a Global Default IEEE 802.1p Value for All Host Outbound Traffic in ACX
Series on page 889
• Applying Egress Interface Rewrite Rules to the IEEE 802.1p Field for All Host Outbound
Traffic on the Interface in ACX Series on page 890
• Overview of Assigning Service Levels to Packets Based on Multiple Packet Header
Fields on page 891
• Configuring Multifield Classifiers on page 892
• Understanding CoS on ATM IMA Pseudowire Interfaces Overview on page 895
• Configuring Fixed Classification on an ATM IMA Pseudowire on page 897
• Example: Configuring Fixed Classification on an ATM IMA Pseudowire on page 898
• Configuring Shaping on an ATM IMA Pseudowire on page 901
• Example: Configuring Shaping on an ATM IMA Pseudowire on page 902
• Understanding RED Drop Profiles Overview on page 907
• Configuring RED Drop Profiles on page 907
• Controlling Network Access Using Traffic Policing Overview on page 908
• Configuring Policing on an ATM IMA Pseudowire on page 912

• Example: Configuring Policing on an ATM IMA Pseudowire on page 915

• Hierarchical Policers on ACX Series Routers Overview on page 920
• Guidelines for Configuring Hierarchical Policers on ACX Routers on page 921
• Hierarchical Policer Modes on page 923
• Processing of Hierarchical Policers on page 928
• Actions Performed for Hierarchical Policers on page 929
• Configuring Aggregate Parent and Child Policers on ACX Series Routers on page 931
• Hierarchical Class of Service Overview on page 933
• Hierarchical Class of Service in ACX5000 on page 936
CoS on ACX Series Universal Access Routers Features Overview
The following key CoS features are supported on ACX Series Universal Access Routers:
• Physical interface-based classifiers at the [edit class-of-service interfaces

interfaces-name] hierarchy level
• Fixed classification for all ingress packets traversing a logical interface to a single
forwarding class. Fixed classification is supported on all interface types.
• EXP bits located in each MPLS label and used to encode the CoS value of a packet as
it traverses a label-switched path (LSP). To configure global EXP bits, include the exp
statement at the [edit class-of-service system-defaults classifiers] hierarchy level.
• Rewrite rules at the physical and logical interface levels including the following: IP
type-of-service (ToS), DSCP, MPLS EXP bit value, and IEEE 802.1p bit value.
• Attachment of the following rewrite rules to the physical interface at the [edit
class-of-service interfaces interface-name rewrite-rules] hierarchy level: IP ToS, DSCP,
and IEEE 802.1p bit value.
• Rewrite rules for MPLS EXP bits on the logical interface at the [edit class-of-service
interfaces interface-name unit unit-number rewrite-rule] hierarchy level.
NOTE: Fine-grained rewrite is not possible, even when you use multifield
filters, because of the application-specific integrated circuit (ASIC)
limitation.
Queuing and scheduling features include:
• Support for up to eight forwarding classes.
• Support for up to eight egress queues per port.
• Internal buffer of 2 MB with per-egress queue buffer management.
• Three weighted random early detection (WRED) curves for TCP and one WRED curve
for non-TCP. There are two fill levels and two drop probabilities per WRED curve; the
drop probability corresponding to the first fill must be zero.

Chapter 27: Configuring Class of Service
• Strict-priority and weighted deficit round-robin scheduling.
• Multiple strict-priority queues per port.
• Per-queue committed information rate (CIR) and peak information rate (PIR).
• Per-physical-port shaping.
Queue statistics features include:
• Per-egress-queue enqueue statistics in packets, bytes, packets per second (pps), and
bits per second (bps).
• Per-egress-queue transmit statistics in packets, bytes, pps, and bps.
• Per-egress-queue drop statistics in packets and pps.
Related •
Documentation • Understanding CoS CLI Configuration Statements on ACX Series Universal Access
Routers on page 865
Understanding CoS CLI Configuration Statements on ACX Series Universal Access

Routers
ACX Series Universal Access Routers have some statements or statement options
supported on other platforms that are not supported or may not have effect on ACX
Series devices.
The following CLI options are not applicable to ACX Series Universal Access Routers:
[edit class-of-service schedulers scheduler-name priority-level]

low;
medium-low;
medium-high;
high;
Configure the strict-high-priority queue with unlimited transmission bandwidth so that

all traffic receives precedence over any non strict-high priority queues.
At the [edit class-of-service classifiers type classifier-name] hierarchy level, the dscp-ipv6
and ieee-802.1ad classifier types are not supported. For the dscp classifier type, only the
outer tag is supported.
The following CLI stanza is not applicable to ACX Series Universal Access Routers.
[edit class-of-service interfaces interface-name]

irb {
classifiers {
type (classifier-name | default);
}
rewrite-rules {

dscp (rewrite-name | default);

dscp-ipv6 (rewrite-name | default);
exp (rewrite-name | default) protocol protocol-types;
ieee-802.1 (rewrite-name | default) vlan-tag (outer | outer-and-inner);
inet-precedence (rewrite-name | default);
}
}
}
The following CLI statements are not applicable to ACX Series Universal Access Routers.
[edit class-of-service routing-instances routing-instance-name]
[edit class-of-service scheduler-map-chassis map-name]
[edit class-of-service interfaces interface-name unit logical-unit-number]

input-shaping-rate (percent percentage | rate);
input-traffic-control-profile profiler-name shared-instance instance-name;
output-traffic-control-profile profile-name shared-instance instance-name;
per-session-scheduler;
shaping-rate rate;
[edit class-of-service interfaces iinterface-name unit logical-unit-number]

classifiers {
type (classifier-name | default);
}
rewrite-rules {
dscp (rewrite-name | default);
dscp-ipv6 (rewrite-name | default);
exp (rewrite-name | default) protocol protocol-types;
exp-push-push-push default;
exp-swap-push-push default;
ieee-802.1 (rewrite-name | default) vlan-tag (outer | outer-and-inner);
inet-precedence (rewrite-name | default);
}
In the above stanza, [edit class-of-service interface-name unit logical-unit-number

rewrite-rule exp (rewrite-name | default)] is supported. However, edit [class-of-service
interface-name unit logical-unit-number rewrite-rule exp protocol protocol type] is not
supported.
[edit class-of-service interfaces interface-name interface-set interface-set-name]

excess-bandwidth-share;
internal-node;
output-traffic-control-profile profile-name;
output-traffic-control-profile-remaining profile-name;
Documentation
Configuring CoS on ACX Series Universal Access Routers
Physical interface-based classifiers are supported at the [edit class-of-service interfaces

interfaces-name] hierarchy level. EXP bits are located in each MPLS label and used to

encode the CoS value of a packet as it traverses an LSP. To configure global EXP bits,
include the exp statement at the [edit class-of-service system-defaults classifiers]
hierarchy level.
To configure CoS on ACX Series routers:
1. Configure the class of service.
[edit]
user@host# edit class-of-service
2. Configure the rewrite rules.
user@host# edit rewrite-rules (dscp | inet-precedence) rewrite-name
user@host# edit forwarding-class class-name
user@host# set loss-priority low class-name code-points (alias | bits)
3. Configure behavior aggregate classifiers for DiffServ CoS.
user@host# edit classifiers (dscp | inet-precedence) classifier-name
user@host# edit forwarding-classes class-name
user@host# set loss-priority class-name code-points (alias | bits)
4. Configure expedited forwarding class classifiers.
[edit class-of-service classifiers]

user@host# edit forwarding-classes class-name
user@host# set loss-priority class-name code-points (alias | bits)
5. Define the forwarding-class mappings.
user@host# edit forwarding-classes class queue-number queue-number
6. Configure network control forwarding class classifiers.
user@host# edit forwarding-class class-name
user@host# set loss-priority low class-name code-points (alias | bits)
7. Apply the rewrite rules and classifiers to the interfaces.
[edit class-of-service interface interface-name unit unit-number]

user@host# set rewrite-rule (dscp | inet-precedence ) (rewrite-name| default)
user@host# set classifiers (dscp | inet-precedence ) classifier-name | default)
8. Set the global system default.
[edit ]
user@host# edit class-of-service system-defaults classifiers exp classifier-name

Following is a complete configuration. This example configures ge-1/0/2 as a

network-to-network (NNI) and ge-1/0/1 as a user-to-network (UNI) interface on the ACX
Series router F1, and ge-1/0/3 as an NNI and ge-1/0/4 as a UNI on F2. In addition, the
configuration includes the following:
• Fixed classification of customer traffic on UNI ports.
• Diffserv code point (DSCP)-based BA classification and rewrites on NNI ports for IP
control traffic at port level.
• EXP-based global behavior aggregate (BA) classification and rewrites on NNI ports
for customer traffic from F1 to F2 by using pseudowire.
Common CoS configuration at F1 and F2:
[edit]
class-of-service {
classifiers {
dscp dscp-classf-core {
forwarding-class be {
}
forwarding-class be1 {
loss-priority high code-points 010101;
}
forwarding-class ef {
}
forwarding-class ef2 {
}
forwarding-class af {
}
forwarding-class af1 {
}
forwarding-class nc {
}
forwarding-class nc3 {
}
}
exp exp-rewrite-core {
}
loss-priority high code-point 110;
}
}

}
}
}
}
}
}
}
class be queue-num 0;
class ef queue-num 1;
class af queue-num 2;
class nc queue-num 3;
class be1 queue-num 4;
class ef1 queue-num 5;
class af1 queue-num 6;
class nc1 queue-num 7;
}
rewrite-rules {
dscp dscp-rewrite-core {
}
}
}
}
}
}
}

}
exp exp-rewrite-core {
}
}
}
}
}
}
}
}
}
}
CoS configuration at F1:
class-of-service {
interfaces {
ge-1/0/1 {
unit 0 {
forwarding-class be;
}
}
ge-1/0/2 {
classifiers {
dscp dscp-classf-core;
}
rewrite-rules {
dscp dscp-rewrite-core;
}
unit 0 {
rewrite-rules {
exp exp-rewrite-core;
}
}
}
}
system-defaults {
classifiers {

exp exp-classf-core;
}
}
}
CoS configuration at F2:
class-of-service {
interfaces {
ge-1/0/4 {
unit 0 {
forwarding-class be;
}
}
ge-1/0/3 {
classifiers {
dscp dscp-classf-core;
}
rewrite-rules {
dscp dscp-rewrite-core;
}
unit 0 {
rewrite-rules {
exp exp-rewrite-core;
}
}
}
}
system-defaults {
classifiers {
}
}
}
Documentation
Routers on page 865
Classifiers and Rewrite Rules at the Global, Physical and Logical Interface Levels
Overview
On ACX Series Universal Access Routers and EX Series switches, CoS supports
classification and rewrite at the global level and physical interface levels.
At a global level, you can define EXP classification.
At a physical interface level, you can define the following features:
• DSCP, DSCP-IPV6, and IPv4 precedence classifiers
• DSCP, DSCP-IPV6, and IPv4 precedence rewrites

• IEEE 802.1 and IEEE 802.1ad classifiers (inner and outer)
• IEEE 802.1 and IEEE 802.1ad rewrites (outer)
The IEEE 802.1ad classifier uses IEEE 802.1p and DEI bits together.
NOTE: You cannot configure both IEEE 802.1p and IEEE 802.1ad classifiers
together at the physical interface level.
At a logical interface level, you can define the fixed classification and EXP rewrites.
To configure global EXP classifiers, include the classfiers exp classifier-name statement
at the [edit class-of-service system-defaults] hierarchy level.
To configure classifiers or rewrite rules at the physical interface, include either the
classifiers statement or the rewrite-rules statement at the [edit class-of-service]
interfaces interface-name ] hierarchy level.
To configure fixed classifiers at the logical interface, include the [edit class-of-service
interfaces interface-name unit number forwarding-class fc] or the rewrite-rules
statement at the [edit class-of-service interfaces interface-name ] hierarchy level.
To configure EXP rewrite at the logical interface, include the [edit class-of-service
interfaces interface-name unit number rewrite-rules exp rewrite-rule] statement.
To display classifiers configured under system-defaults, enter the show class-of-service

system-defaults command.
To display classifiers and rewrite rules bound to physical interfaces, enter the show
class-of-service interfaces interface-name command.
Related • Configuring Classifiers and Rewrite Rules at the Global and Physical Interface Levels
Configuring Classifiers and Rewrite Rules at the Global and Physical Interface Levels
On ACX Series Universal Access Routers and EX Series switches, CoS supports
classification and rewrite at the global and physical interface levels.
To configure the global EXP classifier, include the following statements at the [edit
class-of-service] system-defaults hierarchy level.
{
system-defaults
{
classifiers exp classifier-name
}
}

CoS supports one global system default classifier of the EXP type, as shown in the
following example:
{
system-defaults {
classifiers {
}
}
}
To configure classifiers and rewrite rules at the physical interface level, include the
following statements at the [edit class-of-service] interfaces hierarchy level.
interfaces {
interface-name
classifiers dscp classifier-name
classifiers inet-precedence classifier-name
classifiers ieee-802.1 [vlan-tag (outer | inner)] classifier-name
rewrite-rules dscp rewrite-name
rewrite-rules inet-prec rewrite-name
rewrite-rules ieee-802.1 rewrite-name
}
The following example shows classifiers and rewrite rules configured on physical
interfaces:
ge-0/1/0 {
unit 0 {
rewrite-rules {
exp custom-exp;
}
}
classifiers {
dscp d1;
ieee-802.1 ci;
}
rewrite-rules {
dscp default;
}
}
ge-0/1/2 {
classifiers {
ieee-802.1 ci;
}
rewrite-rules {
ieee-802.1 ri;
}
}
ge-0/1/3 {
unit 0 {
rewrite-rules {
exp custom-exp2;
}

}
}
ge-0/1/7 {
classifiers {
dscp d1;
}
}
ge-0/1/8 {
classifiers {
dscp d1;
}
}
Related • Classifiers and Rewrite Rules at the Global, Physical and Logical Interface Levels
Documentation Overview on page 871
Understanding Schedulers Overview
You use schedulers to define the properties of output queues. These properties include
the amount of interface bandwidth assigned to the queue, the size of the memory buffer
allocated for storing packets, the priority of the queue, and the random early detection
(RED) drop profiles associated with the queue.
You associate the schedulers with forwarding classes by means of scheduler maps. You
can then associate each scheduler map with an interface, thereby configuring the
hardware queues, packet schedulers, and RED processes that operate according to this
mapping.
To configure class-of-service (CoS) schedulers, include the following statements at the

[edit class-of-service] hierarchy level:
interfaces {
interface-name {
shaping-rate rate;
}
}
scheduler-maps {
map-name {
forwarding-class class-name scheduler scheduler-name;
}
}
drop-profiles {
drop profile-name {
fill-level percentage drop-probability percentage;
}
}
schedulers {
scheduler-name {
buffer-size (percent percentage | remainder | temporal microseconds | buffer-partition
multicast percent percentage );

drop-profile-map loss-priority (any | low | medium-high | high) protocol (any | non-tcp

| tcp) drop-profile profile-name;
transmit-rate (rate | percent percentage remainder) <exact>;
shared-buffer maximum (percent percentage | multicast percentage);
}
}
class class-name queue-number queue-number <0..7> priority (high | low);
queue queue-number class-name priority (high | low) [ policing-priority (premium |
normal) ];
}
NOTE: The options buffer-partition multicast percent <0-100> and multicast

<0-100> are supported only on ACX5048 and ACX5096 routers. For more
information, see “Configuring Shared and Dedicated Buffer Memory Pools”
on page 876.
In ACX Series routers, you can configure more than one strict-priority queues per port.
The hardware services the queues in the descending order of queue numbers marked as
strict priority. All the strict-priority queues are given preferential treatment by the scheduler
as long as their shaping rates (or peak information rates) are not met. Unlike MX Series
routers, the ACX Series routers configured with queues as strict-high at the [edit
class-of-service schedulers scheduler-name priority strict-high] statement hierarchy, the
service is based on queue number and not based on sharing the strict-high queues. Unlike
other ACX Series routers, ACX5048 and ACX5096 router supports CIR among
strict-priority queues. There is no implicit queue number-based priority among the
strict-priority queues. Unlike other ACX Series routers, ACX5048 and ACX5096 router
supports configuring drop profiles for loss-priority low, medium-high, and high for non-TCP
protocols as well.
NOTE: In ACX Series routers, the transmit-rates statement cannot be

configured on strict-priority queues because of hardware limitations.
On an ACX 4000 router, whenever the scheduling and shaping parameters

of a port or any of its queues are changed, the entire scheduling configuration
on the port is erased and the new configuration is applied. During this window,
the traffic pattern does not adhere to user parameters. It is recommended
that the scheduling configurations are done a priori before live traffic.
Related • Understanding RED Drop Profiles Overview on page 907

Documentation
• Configuring RED Drop Profiles on page 907

Configuring Shared and Dedicated Buffer Memory Pools
The ACX5048 and ACX5096 router has 12 megabytes of Packet Forwarding Engine (PFE)
wide common packet buffer memory that is used to store packets on interface queues.
The buffer memory is divided into two pools, shared buffers and dedicated buffers or
reserved buffers.
Shared buffers are a global memory pool that the router allocates dynamically to ports
as needed, so the buffers are shared among the ports. To configure a maximum amount
of shared buffer that the multicast packets can consume, include the multicast percentage
CLI statement at the [edit class-of-service schedulers scheduler-name shared-buffer
maximum] hierarchy level. The value that you can specify for multicast percentage CLI
command can be from 0 through 100 percent. If the multicast percentage CLI statement
is not added, then the value defined by the shared-buffer maximum percent percentage
is used for multicast packets as well.
Dedicated buffers or reserved buffers are a memory pool divided equally among the
router ports. Each port receives a minimum guaranteed amount of buffer space, dedicated
to each port, not shared among ports. To configure a dedicated buffer for multicast
packets, include the buffer-partition multicast percentage CLI statement at the [edit
class-of-service schedulers scheduler-name buffer-size] hierarchy level. The value that
you can specify for buffer-partition multicast percentage CLI command can be from 0
through 100 percent. If the buffer-partition multicast percentage CLI statement is not
configured, then a default value of 25% is reserved for multicast packets.
NOTE: The total amount of actual queue buffer is defined using the buffer-size
CLI command.
To configure shared and dedicated buffers, include the multicast percentage and
buffer-partition multicast percentage CLI statements at the [edit class-of-service] hierarchy
level:
schedulers {
scheduler-name {
buffer-size (percent percentage | remainder | temporal microseconds | buffer-partition
multicast percent percentage );
shared-buffer maximum (percent percentage | multicast percentage);
}
}
The following is a sample configuration for shared and dedicated buffers in ACX5048
and ACX5096 routers:
schedulers schd1{
buffer-size percent 80;
buffer-partition {
multicast {
percent 30;

}
}
shared-buffer {
maximum {
20;
multicast {
10;
}
}
}
}
The port gets 50 microseconds worth of reserved buffer. For a 10 Gigabyte port without
any shaper, this translates to 62500 Bytes.
In the above sample configuration, the total buffer size allotted for the queue is 80
percent.
Under buffer-partition, the multicast packets get 30 percent of the total buffer-size,
which translates to about 24 percent of port-buffer. The unicast packets get the remaining
70 percent of 80 percent of the port buffer, which translates to 56 percent of port buffer.
Under shared-buffer, the multicast packets get up to 10 percent of the total shared buffer.
Unicast packets use up to 20 percent of the total shared buffer.
Related • Understanding Schedulers Overview on page 874

Documentation
CoS for PPP and MLPPP Interfaces on ACX Series Routers
Junos CoS enables you to divide traffic into classes and offer various levels of throughput
and packet loss when congestion occurs. This functionality allows packet loss to happen
according to rules that you configure. The Junos CoS features provide a set of mechanisms
that you can use to provide differentiated services when best-effort traffic delivery is
insufficient.
CoS functionalities are supported on PPP and MLPPP interfaces. Up to four forwarding
classes and four queues are supported per logical interface for PPP and MLPPP packets.
NOTE: CoS for PPP and MLPPP Interfaces is not applicable on ACX5048
and ACX5096 routers.
The Junos OS CoS features provide a set of mechanisms that you can use to provide
differentiated services when best-effort traffic delivery is insufficient. In designing CoS
applications, you must give careful consideration to your service needs, and you must
thoroughly plan and design your CoS configuration to ensure consistency across all
routing devices in a CoS domain. You must also consider all the routing devices and other
networking equipment in the CoS domain to ensure interoperability among all equipment.

Limitations That are Common for CoS on PPP and MLPPP Interfaces
The following restrictions apply for configuring CoS on PPP and MLPPP interfaces on
ACX Series routers:
• For interfaces with PPP encapsulation, you can configure interfaces to support the
IPv4, Internet Protocol Control Protocol (IPCP), PPP Challenge Handshake
Authentication Protocol (CHAP), and Password Authentication Protocol (PAP)
applications.
• Drop timeout, which defines a recovery method for any packets dropped by the member
links in a link services or multilink bundle, is not applicable for ACX routers.
• Loss of traffic occurs during a change of CoS configuration; you cannot modify
scheduling attributes instantaneously. The link moves to the down state for PPP, and
the protocol is denoted as down for MLPPP interfaces.
• Scheduling and shaping capabilities are based on the CIR-EIR model and are not in
accordance with the weighed fair queuing mode. The minimum transmit speed is 32
Kbps, and the minimum difference that can be supported between the transmit rate
and shaping rate is also 32 Kbps.
• Buffer size is calculated in terms of packets using 256 bytes as the average packet
size. For example, if you configure a 10 percent buffer size for TI interfaces, the buffer
allocated as 1.536 Mbps * (10/100) * (0.1 sec) = 15360 bits. The following formula
computes the configured queue length:
Queue length configured = Buffer/average packet size = (15360/256)/8 = 7.5 = 8

packets.
Because there are no shared buffers, the usage of "buffer-size" and "buffer-size exact"
attributes result in the same behavior.
• Only two loss priority levels, namely low and high, are supported. Traffic that arrives
from the Packet Forwarding Engine with a medium-high priority is treated as high
priority traffic. Although you can configure the medium-high loss priority type when
you configure the action for a firewall term, it is considered by the system as high priority
traffic.
• A fixed, in-built mapping between forwarding class and queue number as follows is
performed: Best-effort is queue 0, expedited-forwarding is queue 1, assured-forwarding
is queue 2, and network-control is queue 3
• For WRED configurations, the difference between maximum fill-level and minimum-fill
level is a number raised to the power of 2 in terms of number of packets (x^2).
Otherwise, the lower fill-level is tuned to turn the difference into a value raised to the
power of 2. For example, queues contain a size of 64 packets. If the following
configuration is performed:
• For the lower fill level, the minimum number of packets is 32. However, if you specify
the fill-level to be 45 instead of 50, the lower fill level is 28. Because 64 - 28, which

equals 36 is not a power of 2, the lower fill-level is internally adjusted to convert it to

be a number exponentially raised to 2.
• When fragmentation-map is configured, the forwarding-class carrying the multi-class

0 traffic must be assigned the highest priority and the forwarding-class carrying the
multi-class 3 traffic must be assigned the lowest priority. Such a configuration is
necessary because of the NPU design.
Limitations for CoS on PPP Interfaces

The following restrictions apply for configuring CoS on PPP interfaces on ACX Series
routers:
• The distribution of excess rate between 2 or more queues that contain the same priority
occurs on a first-come, first-served basis. For example, consider two Queues configured
as follows:
Q1 : Transmit-rate = 10%, Shaping-rate = 20%
Q2 : Transmit-rate = 10%, Shaping-rate = 30% on same priority
The excess rate for Q1 = (20 - 10) = 10%
The excess rate for Q2 = (30 - 10) = 20%
• The excess rate distribution between Q1 and Q2 does not follow the same ratio but
packets in these queues are served in first-come, first-served manner. The shaping
rate continues to be honored in such a scenario.
Guidelines for Configuring CoS on PPP and MLPPP Interfaces

Keep the following points in mind when you configure CoS on PPP and MLPPP interfaces:
• You can configure only the any option with the protocol statement at the [edit
class-of-service schedulers scheduler-name drop-profile-map] hierarchy level to specify
the protocol type for the specified scheduler. You cannot specify the TCP or non-TCP
protocol types.
• CoS functionalities for fractional T1 and E1 interfaces are not supported. CoS is
supported only for full T1 and E1 interfaces.
• Weighted fair queuing (WFQ) shaping and scheduling model is not supported. Instead
of WFQ, CIR-EIR model is supported to handle shaping and scheduling requirements.
• Percentage-based rate configuration is not supported for MLPPP LSQ interfaces; only
absolute rate configration in bps is supported.
• Auto-adjustment of shaping and scheduling rates with the addition or deletion of T1/E1
links is not supported. All the limitations applicable for CoS on ACX routers apply for
PPP interfaces.
• All the policer limitations on ACX routers for Gigabit Ethernet interfaces are valid for
PPP interfaces. This restriction includes ingress and egress policers. Because these
limitations are chassis-wide, they are also effective for PPP interfaces.

• All valid configurations specified for MLPPP interfaces with inet address families are
also valid for MLPPP interfaces with MPLS address families. For example, EXP classifier
as a global classifier is supported for ingress classification and EXP rewrite rule is
supported for egress logical interfaces.
• PPP encapsulation is supported on ACX1000, ACX2000, ACX2100, and ACX4000

routers.
• A maximum of 1000 logical interfaces can be supported on an ACX router .
• A maximum of 280 PPP or MLPPP logical interfaces can support drop-profiles on a

system. On each MIC, a maximum of 140 PPP or MLPPP interfaces are supported.
Limitations for CoS on MLPPP Interfaces

The following restrictions apply for configuring CoS on MLPPP interfaces on ACX Series
routers:
• Percentage-based configuration for scheduling and shaping parameters is not

supported; only absolute rate configuration is supported. As a result, dynamic, swift
redjustment of shaping and scheduling settings does not happen with the addition or
deletion of T1/E1 links.
• Buffer size is calculated in terms of a single T1 or E1 link speed. Therefore, a temporal

value, in microseconds, is used to compute the buffer size for a higher value of the
buffer size. For the temporal setting, the queuing algorithm starts dropping packets
when it queues more than a computed number of bytes. This maximum is computed
by multiplying the transmission rate of the queue by the configured temporal value.
The default queue size and percentage-based queue size are not based on the current
bandwidth.
• If you configure a scheduler map without a fragmentation map, any scheduler-map

configuration including the default settings are applied the same behavior as the exact
transmission rate functionality. Priorities of traffic are not honored and no excess rates
are provisioned. The forwarding class with no rate configuration receives the minimum
fixed rate allocated to it, which is 32 Kbps.
• Support for oversubscription and priority is not available, which might cause inefficient
bandwidth utilization. For example, consider a default scheduler map, with the
best-effort queue configured with a rate that is equal to 16*T1*(.95) transmit-rate
exact.
• The network-control queue is configured with a rate that is equal to 16*T1*(0.05)

transmit rate exact. In such a scenario, the following behavior is observed for MLPPP
bundle with a single T1 link:
Traffic that arrives as only best-effort type of traffic is provided with complete
bandwidth capacity if no traffic is distributed to any other queue. Traffic that arrives
on the only network-control queue is limited to a bandwidth of 1.2288 Mbps, even if
no traffic is present on any other queue. When traffic arrives on both the best-effort
and network-control queues, an equal division of traffic is done on both the queues
because both the queues are within their minimum guarantee rate. Queues other than
Best-Effort and Network-Control receive 32 Kbps of exact transmit bandwidth.

Queues other than best-effort and network-control are assigned 32 Kbps of exact
transmit bandwidth.
Consider another example of a default scheduler map, and an MLPPP bundle with two
T1 links. In such a scenario, the following behavior is observed for MLPPP bundle with
two T1 links:
Traffic that arrives on only the best-effort queue obtains the entire bandwidth capacity
if there is no traffic on any other queue. Traffic that arrives on only the network-control
queue is limited to 1.2288 Mbps, even when no traffic is passing through any other queue.
When traffic arrives on both the queues, it is marked at 1.2288 Mbps for the
network-control queue and at 1.843200 Mbps for best-effort queue.
For a default scheduler-map with an MLPPP bundle that contains 16 T1 links, the traffic
that arrives as only best-effort traffic receives a bandwidth that is equal to (0.95 * 16 *
T1) capacity if there is no traffic on any other queue. Traffic that arrives as only
network-control traffic is limited to 1.2288 Mbps even if no traffic on any other queue is
observed. When traffic arrives on both the queues, it is tagged as 1.2288 Mbps for
network-control and (0.95 * 16 * T1) Mbps for best-effort queues. If you configure a
scheduler-map with a fragmentation map, two or more classes when configured with
same priority receive only the transmit-rate served for them and function as the traffic
defined for exact transmit-rate functionality.
Support for oversubscription between two multi-classes on the same priority is not
provided. The queue corresponding to which there is no-multiclass entry is moved to the
disabled state. Only one-to-one mapping between forwarding-class to multi-class is
supported. One forwarding class can send traffic corresponding to only one multi-class.
CoS Functionalities for IPv4 Over PPP Interfaces

The following CoS capabilities are supported on PPP interfaces for IPv4 traffic:
• Ingress Classification can be either specified as fixed classifiers or behavior aggregate

(BA) classifiers. Fixed classifiers map all traffic on an interface to the forwarding class.
The forwarding class determines the output queue. To configure a fixed classifier,
include the forwarding-class class-name statement at the [edit class-of-service interface
interface-name unit logical-unit-number] hierarchy level.
• BA classification, or CoS value traffic classification, refers to a method of packet

classification that uses a CoS configuration to set the forwarding class of a packet
based on the CoS value in the IP packet header. The CoS value examined for BA
classification purposes can be the Differentiated Services code point (DSCP) value,
or the IP precedence value, or EXP bits. The default classifier is based on the IP
precedence value.
• To configure the global EXP classifier, include the following statements at the [edit
class-of-service system-defaults] hierarchy level.
{
system-defaults
{
classifiers exp classifier-name

}
}
CoS supports one global system default classifier of the EXP type, as shown in the
following example:
{
system-defaults {
classifiers {
}
}
}
• All packets that are received on a logical interface in the ingress direction can be
classified to a single forwarding class using fixed classification.
• BA Classification based on the following packet fields is supported at the logical

interface level:
• IPv4 - inet-precedence
• DSCP
The following is the configuration stanza for defining BA classifiers:

classifiers {
(inet-precedence|dscp ) classifier-name
{
forwarding-class class-name loss-priority [low | high]
code-points ([ aliases ] | [ dscp-bits ]);
}
• Queuing and scheduling functionalities comprise the following parameters:
• Transmit rate per queue
• Shaping rate per queue
• WRED
• Forwarding classes. A maximum of 4 forwarding classes can be defined for PPP

interfaces.
• The four priorities supported for logical interface-level queuing are strict-high,
medium-high, medium-low, or low. The transmit rate per queue (CIR) is the minimum
committed rate can be specified for each queue. The shaping rate per queue (PIR) is
the maximum transmit rate can be specified for each queue. For WRED, the default
behavior is to enable tail drops. The drop profile configuration enables WRED and
enables different drop behavior based on the drop precedence to be entered. Loss
priority settings help determine which packets are dropped from the network during
periods of congestion. The software supports multiple packet loss priority (PLP)
designations: low and high
• Buffer-size can be specific in percentage and temporal configuration. This size is turned
into the number of packets per queue, with 256 bytes treated as the average packet
size. The following settings can be configured at the queue level:

• Guaranteed transmit rate (CIR)
• Shaping rate (PIR)
• Drop profile
• Buffer size
schedulers scheduler_name {
transmit-rate (percent number | rate);
shaping-rate (percent number | rate);
buffer-size (percent | temporal)
drop-profile-map map_name;
}
Only 4 forwarding classes and only 4 queues per logical interface are supported. Also,
logical interface-based shaping is not supported.
• Packet and byte counters for transmitted and dropped packets are available per queue.
These statistical details are displayed using the show interfaces queue command.
Aggregation to provide port-level statistics, if needed, is also supported by the system.
The logical interface-level statistics are correctly available for egress direction and are
displayed in the output, but the statistics pertaining to dropped packets are not
considered because of hardware limitations. The following configuration stanza defines
the rewrite rules:
rewrite-rules {
(inet-precedence | dscp | exp) rewrite-name
{
forwarding-class class-name loss-priority [low | high]
code-point value;
}
}
Each of the rewrite rules can be attached to an interface by using the following
configuration syntax:
All of the firewall features supported on ACX routers are applicable for PPP interfaces
for IPv4 packets.
• For rewrite rules, IPv4 or inet precedence and EXP rules are supported. EXP rewrite
rules apply only to logical interfaces. You cannot apply EXP rewrite rules to physical
interfaces. There are no default EXP rewrite rules. If you want to rewrite the EXP value
in MPLS packets, you must configure EXP rewrite rules and apply them to logical
interfaces. If no rewrite rules are applied, all MPLS labels that are pushed have a value
of zero (0). The EXP value remains unchanged on MPLS labels that are swapped.
CoS Functionalities for IPv4 Over MLPPP Interfaces

The following CoS capabilities are supported on MLPPP interfaces for IPv4 traffic:

• Ingress Classification can either be specified as fixed or BA classifiers.
• Fixed classification using forwarding classes and BA classification using IPv4 precedence
value are supported.
• The following scheduling and queuing properties are supported:
• WRED
• Forwarding classes
• Buffer size per queue
• Forwarding class to multilink class mapping. You use the multilink-class statement to
map a forwarding class into a multiclass MLPPP (MCML).
• All of the firewall features supported on ACX routers are applicable for MLPPP interfaces
for IPv4 packets
• For rewrite rules, IPv4 precedence rule is supported.
The following CoS capabilities are supported on MLPPP interfaces for MPLS packets:
• Ingress Classification can either be specified as fixed or BA classifiers. Fixed classification

using forwarding classes and BA classification using EXP bits are supported.
• The following scheduling and queuing properties are supported:
• WRED
• Forwarding classes
• Buffer size per queue
• Forwarding class to multilink class mapping. You use the multilink-class statement to
map a forwarding class into a multiclass MLPPP (MCML).
• All of the firewall features supported on ACX routers are applicable for MLPPP interfaces
for IPv4 packets
• For rewrite rules, the EXP rule is supported.
The following example illustrates an MLPPP CoS configuration set:
[edit]
class-of-service {
classifiers {
inet-precedence all-traffic-inet {
}

}
}
}
drop-profiles {
plp-low-red {
}
plp-high-red {
}
}
queue 0 best-effort;
queue 1 assured-forwarding;
queue 2 expedited-forwarding;
queue 3 network-control;
}
schedulers {
evdo-mlppp-best-effort {
transmit-rate 1M;
priority medium-high;
}
evdo-mlppp-assured-forwarding {
transmit-rate 500000;
drop-profile-map loss-priority low protocol any drop-profile
plp-low-red;
drop-profile-map loss-priority high protocol any drop-profile
plp-high-red;
priority medium-low;
}
evdo-mlppp-expedited-forwarding {
priority low;
}
evdo-mlppp-network-control {
}
}
scheduler-maps {
evdo-mlppp-cos-map {
forwarding-class best-effort scheduler evdo-mlppp-best-effort;
forwarding-class assured-forwarding scheduler

evdo-mlppp-assured-forwarding;
forwarding-class network-control scheduler
evdo-mlppp-network-control;
forwarding-class expedited-forwarding scheduler
evdo-mlppp-expedited-forwarding;
}
}
frag-mlppp {

forwarding-class {
assured-forwarding {
multilink-class 2;
}
expedited-forwarding {
multilink-class 3;
}
best-effort {
multilink-class 1;
}
network-control {
multilink-class 0;
}
}
}
}
interfaces {
lsq-0/* {
unit * {
scheduler-map evdo-mlppp-cos-map;
fragmentation-map frag-mlppp;
}
}
}
NOTE: In ACX Series routers, the forwarding class and queue mapping is
fixed for PPP and MLPPP interfaces.
The following example illustrates an MLPPP firewall configuration set:
[edit]
firewall {
filter classify-evdo-traffic-mlppp {
interface-specific;
term signalling {
from {
dscp ef;
}
then {
count signalling-counter;
forwarding-class network-control;
accept;
}
}
term user-speech {
from {
dscp af31;
}
then {
policer user-speech-rate-limit;
count user-speech-counter;
accept;
}
}
term ptt-mcs {
from {

dscp af11;
}
then {
count ptt-mcs-counter;
accept;
}
}
term user-video {
from {
dscp af21;
}
then {
count user-video-counter;
loss-priority low;
forwarding-class assured-forwarding;
accept;
}
}
term user-cmcs {
from {
dscp af12;
}
then {
count user-cmcs-counter;
loss-priority low;
accept;
}
}
term ran-rlp-retransmission {
from {
dscp af41;
}
then {
count rlp-retransmit-counter;
loss-priority high;
accept;
}
}
term user-best-effort {
then {
count user-be-counter;
forwarding-class best-effort;
accept;
}
}
}
}
CoS for NAT Services on ACX Series Universal Access Routers
For packets that go through NAT services, the classification is done when the packet
enters the router, and the resulting forwarding class and the packet loss priority are
preserved when the packet goes through the inline services interface. When the packet
exits the router through a physical interface, the queuing, scheduling, and rewrite rules

configured on the egress physical interface are applied on the basis of the forwarding
class and packet loss priority derived during ingress.
NOTE: CoS for NAT services is not applicable on ACX5048 and ACX5096
routers.
Queuing and scheduling are supported on the inline services interface to handle congestion
at the inline services interface. Congestion at inline services interface is possible when
the interface is oversubscribed. In this case, you would need to selectively drop packets
based on the packet's forwarding class and packet loss priority. To drop packets based
on the packet's forwarding class and packet loss priority, scheduler map configurations
are supported on the inline services interface.
NOTE: In ACX Series routers, you cannot configure classification and rewrite
policies on the inline services interface.
Related • Network Address Translation Overview on page 999

Documentation
• Network Address Port Translation Overview on page 1001
• Enabling Inline Services Interface on ACX Series on page 1008
• Understanding Service Sets on page 1028
• Service Filters in ACX Series on page 1035
• Guidelines for Applying Service Filters on page 1036
• Service Filter Match Conditions for IPv4 Traffic on page 1038
• Network Address Translation Address Overload in ACX Series on page 1001
• Configuring Address Pools for Network Address Port Translation (NAPT) Overview on
page 1007
• Network Address Translation Rules Overview on page 1004
• Configuring Service Sets for Network Address Translation on page 1030
• Configuring Service Sets to Be Applied to Services Interfaces on page 1031
• Configuring Queuing and Scheduling on Inline Services Interface on page 1040

Configuring the IEEE 802.1p Field for CoS Host Outbound Traffic in ACX Series
This topic provides a summary of the configuration for setting the IEEE 802.1p field in the
Ethernet frame header for host outbound traffic (control plane traffic). You can set a
global value for the priority code point that applies to all host outbound traffic.
Additionally, or alternatively, you can specify that rewrite rules are applied to all host
outbound traffic on egress logical interfaces. These are rules that have been previously
configured to set the IEEE 802.1p field for data traffic on those interfaces.
To configure the IEEE 802.1p field settings:
1. (Optional) Specify a global default value for the IEEE 802.1p field for all host outbound
traffic.
See “Configuring a Global Default IEEE 802.1p Value for All Host Outbound Traffic in
ACX Series” on page 889.
2. (Optional) Specify that the IEEE 802.1p rewrite rules for the egress logical interfaces
are applied to all host outbound traffic on those interfaces.
See “Applying Egress Interface Rewrite Rules to the IEEE 802.1p Field for All Host
Outbound Traffic on the Interface in ACX Series” on page 890.
Related • Configuring a Global Default IEEE 802.1p Value for All Host Outbound Traffic in ACX
Documentation Series on page 889
Configuring a Global Default IEEE 802.1p Value for All Host Outbound Traffic in ACX
Series
This topic describes how to configure a global default value for the IEEE 802.1p field for
all host outbound traffic on ACX Series routers.
To configure a global default value for the IEEE 802.1p field:
• Specify the value.
[edit class-of-service host-outbound-traffic ieee-802.1]

user@host# set default value
For example, specify that a value of 010 is applied to all host outbound traffic:

user@host# set default 010
Related • Configuring the IEEE 802.1p Field for CoS Host Outbound Traffic in ACX Series on

Applying Egress Interface Rewrite Rules to the IEEE 802.1p Field for All Host Outbound
Traffic on the Interface in ACX Series
This topic describes how to apply rewrite rules for egress logical interfaces to the IEEE
802.1p field for all host outbound traffic on those interfaces on ACX Series routers.
This task requires separately configured rewrite rules that map packet loss priority
information to the code point value in the 802.1p field for data traffic on egress logical
interfaces. See Rewriting Packet Header Information Overview in the Junos OS Class of
Service Configuration Guide.
To configure the rewrite rules:
1. Configure the CoS rewrite rules to map the forwarding class to the desired value for
the 802.1p field.
2. Associate the rewrite rules to the desired egress logical interfaces.
3. (Optional) Configure the forwarding class for host outbound traffic. Do not configure
this forwarding class if you want to use the default forwarding class assignment (input
classification).
To configure the rewrite rules to apply to the host outbound traffic IEEE 802.1p field:
• Configure the rewrite rules.

user@host# set rewrite-rules
rewrite-rules {
ieee-802.1 rewrite_foo {
}
}
}
interfaces {
ge-1/0/0 {
unit 100 {
rewrite-rules {
ieee-802.1 rewrite_foo vlan-tag outer-and-inner;
}
}
}
}
host-outbound-traffic {

}
host-outbound-traffic {
ieee-802.1 {
rewrite-rules;
}
}
Series on page 889
Overview of Assigning Service Levels to Packets Based on Multiple Packet Header

Fields
Behavior aggregate (BA) classification (see “Understanding How Behavior Aggregate

Classifiers Prioritize Trusted Traffic” on page 950), where packets are classified based on
their QoS markings, is the most common way to assign service levels because it is
straightforward and based on a well-established, fixed-length header fields, which makes
them computationally more efficient. However, sometimes BA classification does not
provide sufficient granularity, or the QoS markings in the packet headers cannot be
trusted. In such situations, multifield classifiers can be used. A multifield classifier is a
method of classifying traffic flows based on multiple packet header fields. Devices that
sit at the edge of a network usually classify packets based on multiple packet header
fields. Multifield classification is normally performed at the network edge because of the
general lack of DiffServ code point (DSCP) or IP precedence support in end-user
applications.
In an edge router, a multifield classifier provides the filtering functionality that scans
through a variety of packet header fields to determine the forwarding class for a packet.
Typically, a classifier performs matching operations on the selected fields against a
configured value. A multifield classifier can examine multiple fields in the packet header:
destination address, source address, IP protocol, source port, destination port, and DSCP
value. Multifield classifiers are used when a simple BA classifier is insufficient to classify
a packet.
Figure 56 on page 892 provides a high-level illustration of how a classifier works.

Figure 56: How a Classifier Works
In Junos OS, you configure a multifield classifier with a firewall filter and its associated
match conditions. This enables you to use any filter match criteria to locate packets that
require classification. From a CoS perspective, multifield classifiers (or firewall filter rules)
provide the following services:
• Classify packets to a forwarding class and loss priority. The forwarding class determines
the output queue. The loss priority is used by schedulers in conjunction with the random
early discard (RED) algorithm to control packet discard during periods of congestion.
• Police traffic to a specific bandwidth and burst size. Packets exceeding the policer
limits can be discarded, or can be assigned to a different forwarding class, to a different
loss priority, or to both.
NOTE: You police traffic on input to conform to established CoS parameters,

setting loss handling and forwarding class assignments as needed. You shape
traffic on output to make sure that router resources, especially bandwidth,
are distributed fairly. However, input policing and output shaping are two
different CoS processes, each with their own configuration statements.
Related • Understanding How Behavior Aggregate Classifiers Prioritize Trusted Traffic on page 950
Documentation
• Configuring Multifield Classifiers on page 892
Configuring Multifield Classifiers
This topic describes how you configure multifield classifiers.
Multifield classifiers classify packets to a forwarding class and loss priority based on the
filter match criteria. Multifield classification is usually done at the edge of the network
for packets that do not have valid or trusted behavior aggregate code points.
If you configure both a behavior aggregate (BA) classifier and a multifield classifier, BA
classification is performed first; then multifield classification is performed. If they conflict,
any BA classification result is overridden by the multifield classifier.

NOTE: For a specified interface, you can configure both a multifield classifier
and a BA classifier without conflicts. Because the classifiers are always
applied in sequential order, the BA classifier followed by the multifield
classifier, any BA classification result is overridden by a multifield classifier
if they conflict.
To activate (apply) a multifield classifier, you must configure it on a logical interface.

There is no restriction on the number of multifield classifiers you can configure.
NOTE: For MX Series routers and EX Series switches, if you configure a firewall
filter with a DSCP action or traffic-class action on a DPC, the commit does
not fail, but a warning displays and an entry is made in the syslog.
For an L2TP LNS on MX Series routers, you can attach firewall for static LNS
sessions by configuring these at logical interfaces directly on the inline services
device (si-fpc/pic/port). RADIUS-configured firewall attachments are not
supported.
You configure multifield classifiers by:
1. Defining the filter—Configure either a firewall filter or a simple filter. Simple filters
filter IPv4 traffic (family inet) only. Firewall filters enable you to filter additional protocol
families and more complex filters. The following sections describe both procedures.
2. Applying the filter—Activate the filter by configuring on a logical interface as an input

filter.
To configure a firewall filter:
1. Under the firewall statement, specify the protocol family for which you want to filter
traffic and specify a name for the filter.
edit
user@host# edit firewall family family-name filter filter-name
2. Specify the term name and match criteria you want to look for in incoming packets.
[edit firewall family family-name filter filter-name]

user@host# set term term-name from match-conditions
3. Specify the action you want to take when a packet matches the conditions.
[edit firewall family family-name filter filter-name]

user@host# set term term-name then actions
For multifield classifiers, you can perform the following actions:
• Set the value of the DSCP field of incoming packets.
user@host# set term term-name then dscp code-point

• Set the forwarding class of incoming packets. The forwarding class determines the
output queue.
user@host# set term term-name then forwarding-class class-name
• Set the loss priority of incoming packets. The loss priority is used by schedulers in
conjunction with the random early discard (RED) algorithm to control packet discard
during periods of congestion.
user@host# set term term-name then loss-priority (high | low | medium-high |

medium-low)
To configure a simple filter:
1. Specify a name for the simple filter.
[edit firewall family family-name]

user@host# edit simple-filter filter-name
2. Specify the term name and match criteria you want to look for in incoming packets.
[edit firewall family family-name simple-filter filter-name]

user@host# set term term-name from match-conditions
3. Specify the action you want to take when a packet matches the conditions.
[edit firewall family family-name simple-filter filter-name]

user@host# set term term-name then actions
For multifield classifiers, you can perform the following actions for a simple filter:
• Set the forwarding-class of incoming packets.
• Set theloss-priority of incoming packets.
To apply the firewall filter to the appropriate logical interfaces as an input filter.
1. Specify the physical and logical interface on which you want to apply the firewall filter.
edit
user@host# edit interfaces interface-name unit unit-number
2. Specify the protocol family for the firewall filter.
[edit interfaces interface-name unit unit-number]

user@host# set family family-name
3. Specify the names of the firewall filters to apply to received packets.
[edit interfaces interface-name unit unit-number]

user@host# set filter input filter-name
Repeat this step for the family protocol filter and the simple filter.
4. Save your configuration.
[edit]

user@host# commit
Related • Overview of Assigning Service Levels to Packets Based on Multiple Packet Header
Documentation Fields on page 891
• Configuring a Simple Filter
• Guidelines for Applying Standard Firewall Filters on page 1049
• Using Multifield Classifiers to Set Packet Loss Priority
Understanding CoS on ATM IMA Pseudowire Interfaces Overview
ACX Series routers configured with Asynchronous Transfer Mode (ATM) inverse
multiplexing for ATM (IMA) pseudowire interfaces support class of service (CoS) features
for ingress and egress traffic. Policing is performed by monitoring the configured
parameters on incoming traffic to conserve resources by dropping traffic that might not
meet those configured parameters. Egress shaping uses queuing and scheduling to
control the bandwidth used. Fixed classification is provided per interface.
NOTE: ACX5048 and ACX5096 routers do not support ATM IMA pseudowire
configurations.
ATM IMA pseudowires with the following encapsulation are supported:
• atm-ccc-cell-relay
• atm-ccc-vc-mux
The following ATM IMA CoS features are supported:
• Cell-Based ATM Policing on page 895

• Cell-Based ATM Shaping on page 896
• Fixed Classification on page 896
Cell-Based ATM Policing

Policing, or rate limiting, enables you to limit the amount of traffic that passes into or out
of the interface. Policing works with firewall filters to thwart denial-of-service (DoS)
attacks. Networks police traffic by limiting the input or output transmission rate of a class
of traffic on the basis of user-defined criteria. The ATM policer controls the maximum
rate of traffic sent from or received on the interface on which it is applied. To apply limits
to the traffic flow, configure the cdvt and peak-rate parameters within the policer. Define
the policing-action parameter as discard, discard-tag, or count to set a consequence for
the packets that exceed these limits. The consequence of configuring the discard-tag
statement is usually a higher loss priority so that if those packets encounter downstream
congestion, they are discarded first.

On ACX Series routers, policing is cell based and configured in the ingress path of the
ATM IMA pseudowire interface at the [edit firewall] hierarchy level. The following ATM
policing features are supported:
• ATM Adaption Layer 5 (AAL5) pseudowires on which cell-based policing is performed

before packet assembly.
• Per-ATM IMA channel policing.
• Traffic classes—Constant bit rate (cbr), real-time variable bit rate (rtvbr), non-real-time
variable bit rate (nrtvbr), and unspecified bit rate (ubr). All traffic classes must include
the peak-rate and cdvt statements for the configuration to work. With the peak-rate
statement, you can limit the maximum traffic allowed by specifying the largest number
of cells per second that the policer processes before it drops packets. The cdvt
statement ensures that the configuration functions correctly.
• For nonconforming cells, the discard, discard-tag, and count actions at the [edit firewall
atm-policer policer-name] hierarchy level. The discard-tag action is applicable to variable
bit-rate—nrtvbr and rtvbr—traffic classes.
Cell-Based ATM Shaping

Cell-based ATM shaping uses cell-based queuing and scheduling to determine the
maximum amount of traffic that can be transmitted on an ATM IMA pseudowire.
Packet-based shaping is not supported. On ACX Series routers, ATM shaping is configured
in the egress path of the ATM IMA pseudowire interface at the [edit class-of-service]
hierarchy level. The following ATM shaping features are supported:
• Prioritized bit rate—Constant bit rate (cbr) is the highest priority, followed by variable
bit rate—nrtvbr and rtvbr. Unspecified bit rate (ubr) is similar to the best-effort service
for Ethernet traffic.
• Constant bit rate shaping—Constant bit rate (cbr) shaping uses the peak cell rate to
limit the number of cells per second that the shaper processes before it drops packets.
• Variable bit rate shaping—Variable bit rate shaping (nrtvbr and rtvbr) uses peak-rate
and sustained-rate.
• Unspecified bit rate—Unspecified bit rate (ubr) uses peak-rate with the lowest transmit
priority.
The default shaping parameter is unspecified bit rate, which is similar to the best-effort
service for Ethernet traffic.
Fixed Classification
Fixed classifiers map all traffic on an interface to the forwarding class and loss priority.
The forwarding class determines the output queue. A scheduler uses the loss priority to
control packet discard during periods of congestion by associating different drop profiles
with different loss priorities. On ACX Series routers, the fixed classifier is associated with
the ingress interface. Packets are assigned on the basis of the type of fixed classification
associated with the logical interface. To configure a fixed classifier, include the

forwarding-class class-name statement at the [edit class-of-service interface

interface-name unit logical-unit-number hierarchy level.
Related • Configuring Fixed Classification on an ATM IMA Pseudowire on page 897

Documentation
Configuring Fixed Classification on an ATM IMA Pseudowire
You configure fixed classification on the ATM IMA pseudowire logical interface (unit) by
specifying a forwarding class, which is applied to all packets received by the logical
interface. To complete this configuration, you can define a forwarding class at the [edit
class-of-service forwarding-classes] hierarchy level. If you do not define a forwarding
class, the default class is used.
The following steps require you to navigate various levels in the configuration hierarchy.
For information about navigating the CLI, see Using the CLI Editor in Configuration Mode
in the CLI User Guide.
NOTE: CoS fixed classification on an ATM IMA pseudowire is not applicable

on ACX5048 and ACX5096 routers.
To configure CoS fixed classification on an ATM IMA pseudowire:
1. Define the ATM IMA pseudowire. For information about defining the ATM IMA
pseudowire, see “Configuring Inverse Multiplexing for ATM (IMA)” on page 185.
2. In configuration mode, go to the [edit class-of-service] hierarchy level:
[edit]
3. Define the forwarding class to apply to the input logical interface, if the default
forwarding class is not used:
user@host# set forwarding-classes class class-name queue-num queue-num
4. Specify the ATM IMA interface on which to include the forwarding class:
user@host# edit interfaces at-fpc/pic/port
5. Configure the logical unit:
[edit class-of-service interfaces at-fpc/pic/port]

user@host# edit unit logical-unit-number

6. Apply the forwarding class to the logical interface:
[edit class-of-service interfaces at-fpc/pic/port unit logical-unit-number]

user@host# set forwarding-class class-name
After you have configured fixed classification, enter the commit command in configuration
mode.
Related • Understanding CoS on ATM IMA Pseudowire Interfaces Overview on page 895
Documentation
Example: Configuring Fixed Classification on an ATM IMA Pseudowire
This example shows the configuration of fixed classification on an ATM IMA pseudowire.
Fixed classification is configured on the logical interface (unit) of the ATM IMA pseudowire.
The software assigns the fixed classification to packets on the basis of the fixed
classification parameters associated with the logical interface on which the ATM cells
are received.
NOTE: This example is not applicable on ACX5048 and ACX5096 routers.

Requirements
• ACX Series router
• A previously configured ATM IMA pseudowire. For steps to configure an ATM IMA
Overview
In this example, the configured forwarding class fc-1 is applied to all packets received on
the ingress logical interface at-0/0/16 unit 0. The fixed classification classifies all traffic
on the logical interface unit zero (0) to queue-num 1.

Configuration
The following example requires you to navigate various levels in the configuration
hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration
To configure fixed classification on an ATM IMA Pseudowire, perform these tasks:
• Configuring a Forwarding Class on page 899

• Applying the Forwarding Class on page 899
level:
set class-of-service forwarding-classes class fc-1 queue-num 1

set class-of-service interfaces at-0/0/16 unit 0 forwarding-class fc-1
Configuring a Forwarding Class
Step-by-Step To define a forwarding class, which is applied to the ingress logical interface:
Procedure
[edit]
user@host# edit class-of-service forwarding-classes
2. Define the forwarding class to apply to the input logical interface:
[edit class-of-service forwarding-classes]

user@host# set class fc-1 queue-num 1
Applying the Forwarding Class
Step-by-Step To apply the forwarding class to the logical ATM IMA pseudowire:
Procedure
1. Specify the ATM IMA interface on which to include the forwarding class:
user@host# edit interfaces at-0/0/16
2. Configure the logical interface:
[edit class-of-service interfaces at-0/0/16 ]

user@host# edit unit 0
3. Apply the previously configured forwarding class to the logical interface:
[edit class-of-service interfaces at-0/0/16 unit 0]

user@host# set forwarding-class fc-1
Results
From configuration mode, confirm your configuration by entering the show command. If
In the following example, all packets coming into the router from the at-0/0/16 unit 0
interface are assigned to the fc-1 forwarding class:
user@host# show
class fc-1 queue-num 1;
}
interfaces {
at-0/0/16 {
unit 0 {
forwarding-class fc-1;
}
}
}
After you have completed the configuration, enter the commit command from
configuration mode.
Documentation

Configuring Shaping on an ATM IMA Pseudowire
On ACX Series routers, ATM shaping is applied in the egress direction only. Only cell-based
shaping is supported. A traffic control profile, which defines the ATM scheduling
parameters, is configured at the [edit class-of-service] hierarchy level. The traffic control
profile is then applied to the ATM logical interface configured at the [edit class-of-service]
hierarchy level.
NOTE: The configuration of ATM shaping requires the inclusion of the per-unit
scheduler statement at the [edit interfaces interface-name] hierarchy level.
NOTE: Configuring shaping on an ATM IMA pseudowire is not applicable on

ACX5048 and ACX5096 routers.
To configure a traffic-shaping profile on an ATM IMA pseudowire:
[edit]
3. Specify the traffic-shaping profile:
user@host# edit traffic-control-profiles profile-name
The following steps describe the traffic control profile options that you can configure.
The options include atm-service, delay-buffer-rate, max-burst-size, peak-rate, and
sustained-rate.
4. (Optional) Specify the service category that determines the traffic-shaping parameter
for the ATM queue at the ATM IMA pseudowire:
[edit class-of-service traffic-control-profiles profile-name]

user@host# set atm-service (cbr | nrt-vbr | rt-vbr)
Select one of the following service traffic categories, depending on the needs of your
network: constant bit rate (cbr), non-real-time variable bit rate (nrtvbr), or real-time
variable bit rate (rtvbr). All service traffic categories must include the peak-rate and
cdvt statements for the configuration to work. The peak-rate statement limits the

maximum traffic allowed and the cdvt statement ensures that the configuration
functions correctly.
5. (Optional) Specify the delay-buffer calculation:

user@host# set delay-buffer-rate cps
The delay-buffer calculation can be specified as cells per second—1000 cells per
second (cps) through 160,000,000,000 cps.
6. (Optional) Define the maximum number of cells that a burst of traffic can contain,
from 1 through 4000 cells:

user@host# set max-burst-size max-burst-size
7. Define the largest number of cells per second that the shaper processes before it
drops packets, from 61 cps through 38,641 cps:

user@host# set peak-rate peak-rate
The maximum peak rate value depends on the number of links in the IMA bundle—the
more the number of links, the higher the possible peak rate.
8. (Optional) Define the normal traffic rate averaged over time, from 61 cps through
38,641 cps:

user@host# set sustained-rate cps
9. To complete the configuration, configure the per-unit scheduler:

user@host# set per-unit scheduler
After you have configured shaping on the ATM IMA interface, enter the commit command
Documentation
Example: Configuring Shaping on an ATM IMA Pseudowire
The following example shows the configuration of shaping on an ATM IMA pseudowire.
On ACX Series routers, the ATM shaper is applied on the egress logical (unit) interface.


Requirements
Overview
In this example, an ATM IMA pseudowire logical interfaces (unit 0) is configured with
two egress ATM shapers—profile-1 and profile-2. The ATM shaping profiles are configured
with the following parameters:
• atm-service—ATM service category used to define the bit rate at which traffic is policed.
• peak-rate—Top rate at which traffic can burst. This is a mandatory statement that
must be included for the configuration to work correctly.
• sustained-rate—Normal traffic rate averaged over time.
• maximum-burst-size—Maximum number of cells that a burst of traffic can contain.
In addition to the configuration of shaping, this example includes the configuration of

tracing operations for the class-of-service (CoS) configuration.
Configuration
To configure shaping on an ATM IMA pseudowire, perform these tasks:

• Configuring Tracing Operations on page 905
level:
set class-of-service traffic-control-profiles profile-1 atm-service rtvbr

set class-of-service traffic-control-profiles profile-1 peak-rate 5k
set class-of-service traffic-control-profiles profile-1 sustained-rate 3k
set class-of-service traffic-control-profiles profile-1 max-burst-size 400

set class-of-service traffic-control-profiles profile-2 atm-service cbr

set class-of-service traffic-control-profiles profile-2 peak-rate 1k
set class-of-service interfaces at-0/0/16 unit 0 output-traffic-control-profile profile-1
set interfaces at-0/0/16 per-unit-scheduler
set class-of-service traceoptions file cos
set class-of-service traceoptions file size 1000000000
set class-of-service traceoptions flag all
Configuring Shaping on an ATM IMA Pseudowire
Step-by-Step The following steps require you to navigate various levels in the configuration hierarchy.
Procedure For information about navigating the CLI, see Using the CLI Editor in Configuration Mode
To configure shaping on an ATM IMA pseudowire:
[edit]
2. Specify the first traffic control profile:
user@host# edit traffic-control-profiles profile-1
3. Specify the ATM real-time variable bit rate rtvbr service traffic category:
[edit class-of-service traffic-control-profiles profile-1]

user@host# set atm-service rtvbr
drops packets:

user@host# set peak-rate 5k
5. Define the normal traffic rate averaged over time, from 61 cps through 38,641 cps:

user@host# set sustained-rate 3k
6. Define the maximum number of cells that a burst of traffic can contain, from 1
through 4000 cells:

user@host# set max-burst-size 400
7. Specify the second traffic control profile:

user@host# edit traffic-control-profiles profile-2

8. Specify the ATM constant bit rate cbr service traffic category:

user@host# set atm-service cbr
drops packets:

drops packets:

11. Apply the first shaping traffic profile to the ATM IMA pseudowire logical interface:
user@host# edit interfaces at-0/0/16 unit 101 output-traffic-control-profile profile-1
12. Configure the per-unit scheduler:
[edit interfaces at-0/0/16]

user@host# set interfaces at-0/0/16 per-unit-scheduler
Configuring Tracing Operations
Step-by-Step To define tracing operations for the class-of-service (CoS) configuration:

Procedure
1. Configure class-of-service (CoS) tracing options:
[edit]
user@host# edit class of service traceoptions
2. Create the file to receive the tracing operation output:
[edit class-of-service traceoptions]

user@host# set file cos
3. Define the maximum size of the file:

user@host# set file size 1000000000
4. Specify the tracing operation to perform:


Results
user@host# show
traffic-control-profiles {
profile-1 {
atm-service rtvbr;
peak-rate 5k;
sustained-rate 3k;
max-burst-size 400;
}
profile-2 {
atm-service cbr;
peak-rate 1k;
}
}
interfaces {
at-0/0/16 {
unit 101 {
output-traffic-control-profile profile-1;
}
}
}
traceoptions {
file cos size 1000000000;
flag all;
}
[edit interfaces]
user@host# show
at-0/0/16 {
per-unit-scheduler;
}
}
configuration mode.
Documentation

Understanding RED Drop Profiles Overview
You can configure two parameters to control congestion at the output stage. The first
parameter defines the delay-buffer bandwidth, which provides packet buffer space to
absorb burst traffic up to the specified duration of delay. When the specified delay buffer
becomes full, packets with 100 percent drop probability are dropped from the head of
the buffer.
The second parameter defines the drop probabilities across the range of delay-buffer
occupancy, supporting the random early detection (RED) process. When the number of
packets queued is greater than the ability of the router to empty a queue, the queue
requires a method for determining which packets to drop from the network. To address
this, Junos OS provides the option of enabling RED on individual queues.
Depending on the drop probabilities, RED might drop many packets long before the buffer
becomes full, or it might drop only a few packets even if the buffer is almost full.
A drop profile is a mechanism of RED that defines parameters that allow packets to be
dropped from the network. Drop profiles define the meanings of the loss priorities.
When you configure drop profiles, there are two important values: the queue fullness
and the drop probability. The queue fullness represents a percentage of the memory used
to store packets in relation to the total amount that has been allocated for that specific
queue. Similarly, the drop probability is a percentage value that correlates to the likelihood
that an individual packet is dropped from the network.
You specify drop probabilities at the [edit class-of-service drop-profiles drop profile-name
fill-level percentage drop-probability percentage;] class-of-service (COS) configuration
hierarchy and reference them in each scheduler configuration. For each scheduler, you
can configure four drop profiles as high-tcp, medium-high-tcp, low-tcp, non-tcp. Two fill
levels can be specified in each drop-profile map. The drop probability associated with
the least fill level must be set as zero, otherwise the CLI command will be rejected during
commit check.
Related • Configuring RED Drop Profiles on page 907

Documentation
• Understanding Schedulers Overview on page 874
Configuring RED Drop Profiles
You enable RED by applying a drop profile to a scheduler. When RED is operational on
an interface, the queue no longer drops packets from the tail of the queue. Rather, packets
are dropped after they reach the head of the queue.
To configure a drop profile, include the drop-profiles statement at the [edit

class-of-service] hierarchy level:
drop-profiles {
profile-name {


}
}
After you configure a drop profile, you must assign the drop profile to a drop-profile map,
and assign the drop-profile map to a scheduler, as discussed in Determining Packet Drop
Behavior by Configuring Drop Profile Maps for Schedulers.
Related • Understanding Schedulers Overview on page 874

Documentation
• Understanding RED Drop Profiles Overview on page 907
Controlling Network Access Using Traffic Policing Overview
This topic covers the following information:
• Congestion Management for IP Traffic Flows on page 908

• Traffic Limits on page 909
• Traffic Color Marking on page 910
• Forwarding Classes and PLP Levels on page 911
• Policer Application to Traffic on page 912
Congestion Management for IP Traffic Flows

Traffic policing, also known as rate limiting, is an essential component of network access
security that is designed to thwart denial-of-service (DoS) attacks. Traffic policing enables
you to control the maximum rate of IP traffic sent or received on an interface and also
to partition network traffic into multiple priority levels, also known as classes of service.
A policer defines a set of traffic rate limits and sets consequences for traffic that does not
conform to the configured limits. Packets in a traffic flow that do not conform to traffic
limits are either discarded or marked with a different forwarding class or packet loss
priority (PLP) level.
With the exception of policers configured to rate-limit aggregate traffic (all protocol
families and logical interfaces configured on a physical interface), you can apply a policer
to all IP packets in a Layer 2 or Layer 3 traffic flow at a logical interface.
With the exception of policers configured to rate-limit based on physical interface media
rate, you can apply a policer to specific IP packets in a Layer 3 traffic flow at a logical
interface by using a stateless firewall filter.
You can apply a policer to inbound or outbound interface traffic. Policers applied to
inbound traffic help to conserve resources by dropping traffic that does not need to be
routed through a network. Dropping inbound traffic also helps to thwart denial-of-service
(DoS) attacks. Policers applied to outbound traffic control the bandwidth used.
NOTE: Traffic policers are instantiated on a per-PIC basis. Traffic policing

does not work when the traffic for one local policy decision function (L-PDF)
subscriber is distributed over multiple Multiservices PICs in an AMS group.

Traffic Limits
Junos OS policers use a token bucket algorithm to enforce a limit on an average transmit
or receive rate of traffic at an interface while allowing bursts of traffic up to a maximum
value based on the configured bandwidth limit and configured burst size. The token
bucket algorithm offers more flexibility than a leaky bucket algorithm in that you can
allow a specified traffic burst before starting to discard packets or apply a penalty such
as packet output-queuing priority or packet-drop priority.
In the token-bucket model, the bucket represents the rate-limiting function of the policer.
Tokens are added to the bucket at a fixed rate, but once the specified depth of the bucket
is reached, tokens allocated after cannot be stored and used. Each token represents a
“credit” for some number of bits, and tokens in the bucket are “cashed in” for the ability
to transmit or receive traffic at the interface. When sufficient tokens are present in the
bucket, a traffic flow continues unrestricted. Otherwise, packets might be dropped or
else re-marked with a lower forwarding class, a higher packet loss priority (PLP) level,
or both.
• The rate at which tokens are added to the bucket represents the highest average
transmit or receive rate in bits per second allowed for a given service level. You specify
this highest average traffic rate as the bandwidth limit of the policer. If the traffic arrival
rate (or fixed bits-per-second) is so high that at some point insufficient tokens are
present in the bucket, then the traffic flow is no longer conforming to the traffic limit.
During periods of relatively low traffic (traffic that arrives at or departs from the interface
at average rates below the token arrival rate), unused tokens accumulate in the bucket.
• The depth of the bucket in bytes controls the amount of back-to-back bursting allowed.
You specify this factor as the burst-size limit of the policer. This second limit affects
the average transmit or receive rate by limiting the number of bytes permitted in a
transmission burst for a given interval of time. Bursts exceeding the current burst-size
limit are dropped until there are sufficient tokens available to permit the burst to
proceed.
Figure 57: Network Traffic and Burst Rates
As shown in the figure above, a UPC bar code is a good facsimile of what traffic looks
like on the line; an interface is either transmitting (bursting at full rate) or it is not. The
black lines represent periods of data transmission and the white space represents
periods of silence when the token bucket can replenish.

Depending on the type of policer used, packets in a policed traffic flow that surpasses
the defined limits might be implicitly set to a higher PLP level, assigned to a configured
forwarding class or set to a configured PLP level (or both), or simply discarded. If packets
encounter downstream congestion, packets with a low PLP level are less likely to be
discarded than those with a medium-low, medium-high, or high PLP level.
Traffic Color Marking

Based on the particular set of traffic limits configured, a policer identifies a traffic flow
as belonging to one of either two or three categories that are similar to the colors of a
traffic light used to control automobile traffic.
• Single-rate two-color—A two-color marking policer (or “policer” when used without
qualification) meters the traffic stream and classifies packets into two categories of
packet loss priority (PLP) according to a configured bandwidth and burst-size limit.
You can mark packets that exceed the bandwidth and burst-size limit in some way, or
simply discard them.
A policer is most useful for metering traffic at the port (physical interface) level.
• Single-rate three-color—This type of policer is defined in RFC 2697, A Single Rate Three
Color Marker, as part of an assured forwarding (AF) per-hop-behavior (PHB)
classification system for a Differentiated Services (DiffServ) environment. This type
of policer meters traffic based on the configured committed information rate (CIR),
committed burst size (CBS), and the excess burst size (EBS). Traffic is marked as
belonging to one of three categories (green, yellow, or red) based on whether the
packets arriving are below the CBS (green), exceed the CBS (yellow) but not the EBS,
or exceed the EBS (red).
A single-rate three-color policer is most useful when a service is structured according

to packet length and not peak arrival rate.
• Two-rate three-color—This type of policer is defined in RFC 2698, A Two Rate Three
Color Marker, as part of an assured forwarding (AF) per-hop-behavior (PHB)
classification system for a Differentiated Services (DiffServ) environment. This type
of policer meters traffic based on the configured CIR and peak information rate (PIR),
along with their associated burst sizes, the CBS and peak burst size (PBS). Traffic is
marked as belonging to one of three categories (green, yellow, or red) based on whether
the packets arriving are below the CIR (green), exceed the CIR (yellow) but not the
PIR, or exceed the PIR (red).
A two-rate three-color policer is most useful when a service is structured according to

arrival rates and not necessarily packet length.
Policer actions are implicit or explicit and vary by policer type. The term Implicit means
that Junos assigns the loss-priority automatically. Table 52 on page 911 describes the
policer actions.

Table 52: Policer Actions

Policer Marking Implicit Action Configurable Action
Single-rate two-color Green (Conforming) Assign low loss None

priority
Red (Nonconforming) None Assign low or high loss

priority, assign a
forwarding class, or
discard
On some platforms,
you can assign
medium-low or
medium-high loss
priority
Single-rate Green (Conforming) Assign low loss None

three-color priority
Yellow (Above the CIR Assign medium-high None

and CBS) loss priority
Red (Above the EBS) Assign high loss Discard

priority
Two-rate three-color Green (Conforming) Assign low loss None

priority
Yellow (Above the CIR Assign medium-high None

and CBS) loss priority
Red (Above the PIR Assign high loss Discard

and PBS) priority
Forwarding Classes and PLP Levels

A packet’s forwarding class assignment and PLP level are used by the Junos OS
class of service (CoS) features. The Junos OS CoS features include a set of mechanisms
that you can use to provide differentiated services when best-effort traffic delivery is
insufficient. For router (and switch) interfaces that carry IPv4, IPv6, and MPLS traffic,
you can configure CoS features to take in a single flow of traffic entering at the edge of
your network and provide different levels of service across the network—internal
forwarding and scheduling (queuing) for output—based on the forwarding class
assignments and PLP levels of the individual packets.
NOTE: Forwarding-class or loss-priority assignments performed by a policer

or a stateless firewall filter override any such assignments performed on the
ingress by the CoS default IP precedence classification at all logical interfaces
or by any configured behavior aggregate (BA) classifier that is explicitly
mapped to a logical interface.

Based on CoS configurations, packets of a given forwarding class are transmitted through
a specific output queue, and each output queue is associated with a transmission service
level defined in a scheduler.
Based on other CoS configurations, when packets in an output queue encounter

congestion, packets with higher loss-priority values are more likely to be dropped by the
random early detection (RED) algorithm. Packet loss priority values affect the scheduling
of a packet without affecting the packet’s relative ordering within the traffic flow.
Policer Application to Traffic

After you have defined and named a policer, it is stored as a template. You can later use
the same policer name to provide the same policer configuration each time you want to
use it. This eliminates the need to define the same policer values more than once.
You can apply a policer to a traffic flow in either of two ways:
• You can configure a standard stateless firewall filter that specifies the
policer policer-name nonterminating action or the three-color-policer (single-rate |
two-rate) policer-name nonterminating action. When you apply the standard filter to
the input or output at a logical interface, the policer is applied to all packets of the
filter-specific protocol family that match the conditions specified in the filter
configuration.
With this method of applying a policer, you can define specific classes of traffic on an
interface and apply traffic rate-limiting to each class.
• You can apply a policer directly to an interface so that traffic rate-limiting applies to
all traffic on that interface, regardless of protocol family or any match conditions.
You can configure policers at the queue, logical interface, or Layer 2 (MAC) level. Only a
single policer is applied to a packet at the egress queue, and the search for policers occurs
in this order:
• Queue level
• Logical interface level
• Layer 2 (MAC) level
Related • Stateless Firewall Filter Overview.

Documentation
• Traffic Policer Types
• Order of Policer and Firewall Filter Operations
• Packet Flow Through the Junos OS CoS Process Overview
Configuring Policing on an ATM IMA Pseudowire
On ACX Series routers, the ATM policer is attached to the ingress path of the ATM IMA
interface, making it an input policer configured at the [edit firewall] hierarchy level. This
input policer is then applied to an ATM IMA logical interface. The ATM IMA logical interface

must have circuit cross-connect (CCC) family encapsulation configured for the
configuration to work.
NOTE: Configuring policing on an ATM IMA pseudowire is not applicable on

1. Configuring an Input Policer on page 913

2. Configuring the ATM IMA Interface on page 914
Configuring an Input Policer

To configure policing on an ATM IMA pseudowire:
2. In configuration mode, go to the [edit firewall] hierarchy level:
[edit]
user@host# edit firewall
3. Define the policer:
[edit firewall]
user@host# edit atm-policer atm-policer-name
The following steps describe the ATM policer options that you can configure. The
options include: atm-service, cdvt, logical-interface-policer, max-burst-size, peak-rate,
policing-action, and sustained-rate.
4. Specify the ATM service category:
[edit firewall atm-policer atm-policer-name]

user@host# set atm-service (cbr | nrt-vbr | rt-vbr | ubr)
Select one of the following service categories, depending on the policing needs of
your network: constant bit rate (cbr), nonreal-time variable bit rate (nrtvbr), real-time
variable bit rate (rtvbr), and unspecified bit rate ubr. All service categories must include
the peak-rate and cdvt statements for the configuration to work. The peak-rate
statement limits the maximum traffic allowed and the cdvt statement ensures that
the configuration functions correctly.
5. Apply limits to the traffic flow by configuring the cell delay variation tolerance (cdvt),
from 1 microsecond through 1,800,000,000 microseconds:


user@host# set cdvt cdvt-time
6. (Optional) Define the policer as a logical interface policer:

user@host# set logical-interface-policer
The logical interface policer is associated with the interface on which the policer is
applied. To configure the policer on multiple interfaces, you must apply this policer
on each interface explicitly.
7. (Optional) Define the maximum number of cells that a burst of traffic can contain,
from 1 through 4000 cells:

user@host# set max-burst-size max-burst-size
8. Apply limits to the traffic flow by specifying the largest number of cells per second
that the policer processes before it drops packets, from 61 cells per second (cps)
through 38,641 cps:

user@host# set peak-rate peak-rate
The maximum peak rate value depends on the number of links in the IMA bundle—the
more links, the higher the possible peak rate.
9. Define the policing-action parameter to set a consequence for the packets that exceed
the traffic limits:

user@host# set policing-action (discard | discard-tag | count)
10. Define the normal traffic rate averaged over time, from 61 cps through 38,641 cps):

user@host# set sustained-rate cps
After you have configured policing, enter the commit command from configuration mode.
Configuring the ATM IMA Interface

To create the ATM IMA interface on which to apply the ATM policer:
1. In configuration mode, go to the [edit interfaces] hierarchy level:
[edit]
2. Define the ATM interface:
[edit interfaces]
user@host# edit at-fpc/pic/port

3. Specify the ATM interface unit:
[edit interfaces at-fpc/pic/port]

user@host# edit unit logical-unit-number
4. Apply the ATM policer:
[edit interfaces at-fpc/pic/port unit logical-unit-number]

user@host# set atm-policer input-atm-policer policer-name
5. Specify the encapsulation family type:
[edit interfaces at-fpc/pic/port unit logical-unit-number]

user@host# set family ccc
After you have configured the ATM IMA interface, enter the commit command in
configuration mode.
Documentation
Example: Configuring Policing on an ATM IMA Pseudowire
This example shows the configuration of policing on an ATM IMA pseudowire. On ACX
Series routers, the ATM policer is an input policer that is applied to the ATM IMA logical
interface. The ATM IMA logical interface must have the circuit cross-connect (CCC)
encapsulation family configured for the configuration to work.

Requirements

Overview
In this example, the ATM IMA pseudowire logical interfaces (unit 0, unit 1 and unit 2) are
configured with three input ATM policers—policer-1, policer-2, and policer-3. The ATM
policers are configured with the following parameters:
• logical-interface-policer—The logical interface policer is configured explicitly on each

logical interface (unit).
• atm-service—The ATM service category used to define the bit rate at which traffic is
policed.
• peak-rate—The peak rate is the top rate at which traffic can burst. This is a mandatory
statement that must be included for the configuration to work correctly.
• sustained-rate—The sustained rate is the normal traffic rate averaged over time.
• maximum-burst-size—The maximum burst size is the maximum number of cells that

a burst of traffic can contain.
• cdvt—The Cell Delay Variation Tolerance is a mandatory statement that must be

included for the configuration to work correctly.
• policing-action—The specified policing action used when the traffic exceeds the limits
set for the policer.
Configuration
To configure policing on an ATM IMA pseudowire, perform these tasks:
• Configuring an ATM Policer on page 917

• Applying the ATM Policer on the ATM IMA Logical Interface on page 918
level:
set firewall atm-policer policer-1 logical-interface-policer

set firewall atm-policer policer-1 atm-service rtvbr
set firewall atm-policer policer-1 peak-rate 2k
set firewall atm-policer policer-1 sustained-rate 1800
set firewall atm-policer policer-1 max-burst-size 400
set firewall atm-policer policer-1 cdvt 900001
set firewall atm-policer policer-1 policing-action discard-tag
set firewall atm-policer policer-2 atm-service nrtvbr
set firewall atm-policer policer-2 peak-rate 1800
set firewall atm-policer policer-2 sustained-rate 1500

set firewall atm-policer policer-2 max-burst-size 300

set firewall atm-policer policer-2 policing-action discard
set firewall atm-policer policer-3 atm-service cbr
set firewall atm-policer policer-3 peak-rate 2k
set firewall atm-policer policer-3 policing-action count
set interfaces at-0/0/16 unit 0 atm-policer input-atm-policer policer-1
set interfaces at-0/0/16 unit 0 family ccc
Configuring an ATM Policer
Step-by-Step To configure the ATM policer, which is applied to the logical ATM IMA pseudowire:
Procedure
1. Define the policer:
[edit]
user@host# edit firewall atm-policer policer-1
2. Specify the parameters for policer-1:
[edit firewall atm-policer policer-1]

user@host# set atm-service rtvbr
user@host# set sustained-rate 1800
user@host# set cdvt 900001
user@host# set policing-action discard-tag

user@host# set atm-service nrtvbr
user@host# set peak-rate 1800
user@host# set sustained-rate 1500
user@host# set policing-action discard

user@host# set atm-service cbr
user@host# set policing-action count

After you have configured the ATM policers, enter the commit command from
configuration mode.
Applying the ATM Policer on the ATM IMA Logical Interface
Step-by-Step To create the ATM IMA logical interface on which to apply the ATM policers:
Procedure
1. Define the ATM interface:
[edit interfaces]
user@host# edit interfaces at-0/0/16
2. Specify the ATM interface unit and apply the first input policer:

user@host# set unit 0 atm-policer input-atm-policer policer-1
3. Specify the encapsulation family type for unit 0:

user@host# set unit 0 family ccc
4. Specify the ATM interface unit and apply the second input policer:


6. Specify the ATM interface unit and apply the third input policer:


Results
[edit firewall]
user@host# show

atm-policer policer-1 {
logical-interface-policer;
atm-service rtvbr;
peak-rate 2k;
sustained-rate 1800;
max-burst-size 400;
cdvt 900001;
policing-action discard-tag;
}
atm-service nrtvbr;
peak-rate 1800;
sustained-rate 1500;
max-burst-size 300;
cdvt 999991;
policing-action discard;
}
atm-service cbr;
peak-rate 2k;
cdvt 800001;
policing-action count;
}
[edit interfaces]
user@host# show
at-0/0/16 {
unit 0 {
atm-policer {
input-atm-policer policer-1;
}
family ccc;
}
unit 1 {
atm-policer {
}
family ccc;
}
unit 2 {
atm-policer {
}
family ccc;
}
}
configuration mode.
Documentation

Hierarchical Policers on ACX Series Routers Overview
On ACX Series routers, two-level ingress hierarchical policing is supported. Single-level

policers define a single bandwidth profile that is used by multiple traffic flows with
different priorities. Two-level policers enable a single bandwidth profile to be optimally
used for multiple traffic flows, based on bandwidth and priority needs of a network.
Typically, multiple traffic flows can share a single policer instance. With single-level
policers, you cannot adminster the method using which the committed information rate
(CIR) and the peak information rate (PIR) values specified in the bandwidth profile are
shared across different flows. For example, in a certain network deployment, you might
want an equal or even distribution of CIR across the individual flows. In such a scenario,
you cannot accomplish this requirement using single-level policers and need to configure
aggregate or hierarchical policers.
NOTE: Hierarchical policers is not applicable on ACX5048 and ACX5096

routers.
Hierarchical policers control the sharing of an aggregate traffic rate across multiple
micro-flows, which constitute the aggregate flow or the macro-flow. Micro-flows are
defined and matched using firewall filter rules and the action of these rules point to a
macro-policer. This macro- policer or aggregate policer determines the amount of
aggregate bandwidth that can be used by the micro-flows that are associated with it.
You can control the bandwidth to be utilized among the micro-flows in different ways.
NOTE: The hierarchical policing mechanism on ACX routers is different from

the hierarching policing capability supported on MX Series routers. On MX
Series routers, with a hierarchical policer, only one child or subordinate policer
can be configured under a parent, top-level policer, whereas on ACX Series
routers, you can aggregate and specify multiple child policers under a single
parent policer. The hierarchical policing methodology on ACX routers is also
called aggregate policing.
Policers are used to enforce bandwidth profiles on the transmitted traffic. A bandwidth
profile is configured for each user based on the service level agreement (SLA) and the
subscription plan that has been requested by the user from the service or enterprise
provider. A bandwidth profile is defined using the following parameters:
• Committed information rate (CIR) denoted in bits per second (bps).
• Committed burst size (CBS) denoted in bytes.
• Excess information rate (EIR) denoted in bps.
• Excess burst size (EBS) denoted in bytes.
• Color mode (CM) can contain only one of two possible values, color-blind or
color-aware. In color-aware mode, the local router can assign a higher packet loss
priority, but cannot assign a lower packet loss priority. In color-blind mode, the local

router ignores the preclassification of packets and can assign a higher or lower packet
loss priority.
A policer is then used to enforce the bandwidth profile and perform different actions,
depending on whether a certain packet confirms to the attributes in the bandwidth profile
or does not satisfy the values in the configured bandwidth profile. Hierarchical policers
can be considered to be an alternative technique for hierarchical queuing and shaping.
However, a few differences exist between the operations that a hierarchical policer
performs when matched against the processes that a hierarchical scheduler performs.
Hierarchical scheduler enables fine-grained bandwidth sharing in terms of percentages

of the available bandwidth, whereas hierarchical policing only enables a coarse-grained
bandwidth sharing based on the absolute micro-flow values of CIR and EIR. Hierarchical
policing enables the packet loss priority (PLP) and also the forwarding class to be modified
in certain cases, depending on whether the packet is confirming, exceeding, or violating
the particular bandwidth profile. Hierarchical scheduler does not cause any modifications
to the PLP or forwarding class values of a packet. Modifications are performed only for
violating packets.
ACX routers do not support hierarchical queuing and shaping. Ingress hierarchical policers
can work in conjunction with ingress, egress, or both ingress and egress hierarchical
queues. For example, a two-level ingress hierarchical policer combined with a two-level
egress queuing framework results in a four-level CoS capability.
Related • Guidelines for Configuring Hierarchical Policers on ACX Routers on page 921
Documentation
Guidelines for Configuring Hierarchical Policers on ACX Routers
Keep the following points in mind when you configure hierarchical or aggregate policers:
• You cannot specify the same policer as both a child policer and a parent policer.
• The child policers of a hierarchical policer use the same resources as normal policers.
Therefore, the maximum number of child policers and normal policers in the system
for bridge domains and IPv4 services is as follows:
• Family Bridge
A group of 124 entries of policers shared with other family-bridge filters.
A maximum of approximately 62 policers when no other family-bridge filters with

the count action for the firewall filter.
Along with 62 policers, you can configure up to 62 family-bridge filters without the
count action for the firewall filter.

• Family inet
A group of 250 entries of policers shared with other family-inet filters.
A maximum of about 125 policers when no other family-inet filters with the count
action.
Along with 125 policers, you can define up to 62 family-inet filters without the count
action.
• The hierarchical policer supports the same policer ranger and burst size behavior as
normal policers.
• You must configure the same hierarchical policer mode for all child policers that refer
or link with the same parent policer instance.
• You cannot use the same policer template as both a normal policer and a child policer.
• You cannot use the same base policer settings as both a normal policer and an
aggregate or hierarchical policer.
• You cannot use the filter-specific statement at the [edit firewall policer policer-name]
hierarchy level to instantiate an aggregate policer. Instead, the instantiation of the
policer is performed by including the aggregate statement at the [edit firewall policer
policer-name] hierarchy level.
• All the child policers of a certain aggregate policer must contain the same definitions
of settings or attributes.
• All the policer instantiation formats are supported for the aggregate policer.
• Ingress two-level hierarchical policing is supported on all ACX routers.
• All the supported match conditions for filters used with normal policers are supported
with micro-flow policers.
• You can configure up to 32 hierarchical policer instances. You can configure up to 32

child policers per macro policer instance.
• You can configure hierarchical policers on aggregated Ethernet interfaces.
NOTE: Hierarchical policers is not applicable on ACX5048 and ACX5096

routers.
Related • Hierarchical Policers on ACX Series Routers Overview on page 920

Documentation

Hierarchical Policer Modes
The method in which the micro-flow policer determines and manages the share of the
aggregate bandwidth for the micro-flow is defined by the hierarchical policer mode. ACX
routers support the following three hierarchical policer modes. You can configure the
mode or type of the policer for each hierarchical policer instance.
NOTE: Hierarchical policer is not applicable on ACX5048 and ACX5096

routers.
This topic contains the following sections that describe the three different modes of
operation of heirarchical policers:
Guarantee Mode
This mode, also called bandwidth-guarantee mode, is used when the micro-flow policer
is used to specify that a portion of the aggregate parent policer bandwidth is guaranteed
for its micro-flow. When this micro-flow contains no traffic, then amount allocated for
this micro-flow out of the aggregate bandwidth is used by the other micro-flows that
are transmitting traffic with a size-limit or bandwidth that is higher than their respective
guaranteed bandwidth rates.
Consider a sample scenario in which the maximum allowed rate or peak information rate
(PIR) for a user is 140 Mbps. A total of four services or applications called expedited
forwarding (EF), Gold, Silver and Bronze are defined for the guaranteed bandwidth mode
of policer with a CIR of 50 Mbps, 40 Mbps, 30 Mbps, and 20 Mbps respectively. For
example, if 140 Mbps of trafic is received for each of the four services, then the permitted
traffic rates are 50, 40, 30 and 20 Mbps respectively. If 150 Mbps of Gold traffic is received,
only 140 Mbps is permitted for Gold traffic.
All the child policers must be of single-rate, single-bucket, and two-color modes for
bandwidth guarantee mode of hiearchical policer. This combination of attributes is also
called floor mode. The micro-flow policer value specifies the minimum guaranteed
bandwidth (CIR) for the micro-flow. The macro-flow policer value specifies the maximum
allowed bandwidth (PIR) for all the flows. The sum or the cumulative value of all CIR
values of the configured micro-flows must be less than or equal to the macro-flow PIR.
The burst size of macro-flow must be greater than the sum of the aggregate of the burst
size of all the child policers and the largest MTU of the physical interface among all the
physical interfaces of the logical interfaces or interface families to which the child policers
are attached.
Consider a sample configuration that has two child policers aggregated by a parent PIR
in bandwidth-guarantee mode. PIRs for the children policers and the parent policer are
configured. When two flows, flow 1 and flow 2, transmit traffic at a rate that exceeds the
configured PIR values, then the share of the parent PIR is adjusted to permit traffic for
the child policers based on their priorities defined for the flows, while the bandwidth is
maintained.

Policers use a token bucket algorithm to enforce a limit on an average transmit or receive
rate of traffic at an interface while allowing bursts of traffic up to a maximum value based
on the configured bandwidth limit and configured burst size. The token bucket algorithm
offers more flexibility than a leaky bucket algorithm in that you can allow a specified
traffic burst before starting to discard packets or apply a penalty such as packet
output-queuing priority or packet-drop priority. Following are the main components of
the token bucket algorithm:
• The bucket represents a rate-limiting function of the policer on the interface input or
output traffic.
• Each token in the bucket represents a “credit” for some number of bits, and tokens in
the bucket are “cashed in” for the ability to receive or transmit traffic that conforms to
a rate limit configured for the policer.
• The token arrival rate is a periodic allocation of tokens into the token bucket that is
calculated from the configured bandwidth limit.
• The token bucket depth defines the capacity of the bucket in bytes. Tokens that are
allocated after the bucket reaches capacity are not able to be stored and used.
An arriving packet complies with the bandwidth-guarantee mode if tokens are present
in the peak burst size (PBS) of either the parent policer or the committed burst size (CBS)
of the child policer. If sufficient tokens are not present in the PBS or CBS of either of the
parent or child policers respectively, the packet does not conform to the guarantee mode
of the hierarchical policer working. In such a case, the child policer rate is guaranteed for
the member flows. The following table describes the different scenarios of color-coding
for micro-flow and macro-flow policers and the resultant color or priority that is assigned:
Micro-Color Macro-Color Result
Green Green Green
Green Red Green
Red Green Green
Red Red Red
Peak Mode
This mode, also called bandwidth-protection mode, is used when the micro-flow policer
is used to specify the maximum amount of the aggregate parent policer bandwidth that
the micro-flow can use. This mode is used to protect a given micro-flow from starving
the other flows. Even when the other micro-flows contain no traffic (the available
aggregate bandwidth rate is greater than the rate of the particular micro-flow, the
micro-flow cannot use more than the rate configured on its micro-flow policer.
Consider a sample scenario in which the total maximum allowed rate (PIR) for a user is
100 Mbps. A total of four services or applications called expedited forwarding (EF), Gold,
Silver and Bronze are defined for the peak or bandwidth-restriction mode of the policer

with PIR values of 50 Mbps, 40 Mbps, 30 Mbps, and 20 Mbps respectively. Such a setting
is used in topologies in which you want to prevent a certain subscriber or user from utilizing
an increased share ofthe macro-flow or the parent CIR for real-time applications, such
as video-on-demand (VoD) or voice over IP (VoIP). For example, if only 100 Mbps of EF
packets are received, the permitted bandwidth rate for the traffic is 50 Mbps. When 100
Mbps of traffic is received for each of the four services, then the aggregate allowed traffic
is 100 Mbps, in which the rates are as follows for the different services:
• Less than or equal to 50 Mbps for EF traffic
• Less than or equal to 40 Mbps for Gold traffic
• Less than or equal to 30 Mbps for Silver traffic
• Less than or equal to 20 Mbps for Bronze traffic
All the child policers must be of single-rate, single-bucket, and two-color types for
bandwidth-protection or peak mode of the hierarchical policer. The micro-flow policer
value specifies the maximum allowed bandwidth (PIR) for the micro-flow. The macro-flow
policer value specifies the maximum allowed bandwidth (PIR) for all the flows. The sum
of the PIR values of the micro-flows must be greater than or equal to the PIR values of
the child policers. The macro-flow burst-size must be greater than or equal to that of
the micro-flow with the largest burst-size.
in bandwidth-guarantee mode. PIRs for the children policers and the parent policer are
configured. When two flows, flow 1 and flow 2, transmit traffic at a rate that exceeds the
configured PIR values, then the share of the parent PIR is adjusted to permit traffic for
the child policers based on their priorities defined for the flows, while the bandwidth is
restricted to maintain the minimum or committed rates of traffic flows.
An arriving packet complies with the bandwidth-guarantee mode if tokens are present
in the peak burst size (PBS) of both the child policer and the parent policer. If sufficient
tokens are not present in the PBS of both the policers, the packet does not conform to
the peak mode of the hierarchical policer working. In such a case, the child policer rate
is the maximum allowed rate or PIR for the member flows. The following table describes
the different scenarios of color-coding for micro-flow and macro-flow policers and the
resultant color or priority that is assigned:
Green Green Green
Green Red Red
Red Green Red
Red Red Red

Hybrid Mode
This mode, which is a combination of the bandwidth-guarantee and bandwidth-protection
modes, enables the capabilities of bandwidth restriction and the per-flow bandwidth
moderation to be accomplished simultanouesly. Bandwidth-guarentee or
bandwidth-restriction mode controls the guaranteed rates for a given micro-flow.
However, it does not adminster or manage the manner in which the excess aggregate
bandwidth can be shared among the micro-flows. A certain micro-flow can potentially
use all the excess aggregate bandwidth starving the other micro-flows of any excess
bandwidth.
Bandwidth-protection or peak mode controls the amount of bandwidth that a particular

micro-flow can consume, thereby protecting other flows from being starved. However,
it does not specify any guaranteed rates for the micro-flows. For example, if micro-flow
rates for flows f1, f2 and f3 are 50 Mbps, 60 Mbps, 50 Mbps respectively, and the aggregate
rate is 70 Mbps, it is possible that f1 and f2 flows might be provided 50 Mbps and 20
Mbps respectively, with no bandwidth allocated for f3.
Hybrid mode implements the benefits of the peak and guaranteed modes to overcome
their individual limitations. In hybird mode, the micro-flow policer specifies two rates,
CIR and EIR, for the micro-flow. The CIR specifies the guaranteed portion out of the total
macro-flow bandwidth for a micro-flow, and the PIR specifies the maximum portion of
the total macro-flow bandwidth for a micro-flow. This mechanism is analogues to CIR
functioning in guarantee mode and EIR functioning in peak mode, thereby combining the
advantages of both models. In hyrbid mode, both color-aware and color-blind modes
are supported for child policers.
Child policers operate in compliance with the RFC 4115 mode of two-rate three color
markers. Normal two-rate three color markers on ACX routers operate in compliance
with the RFC2698 mode.
Consider a sample configuration in which the maximum allowed rate for a user is 140
Mbps. A total of four services or applications called expedited forwarding (EF), Gold,
Silver and Bronze are defined for the hybrid mode of the policer with PIR values of 55Mbps,
60 Mbps, 130 Mbps, and 140 Mbps respectively. The defined CIR values are 50 Mbps, 40
Mbps, 30 Mbps, and 20 Mbps for EF, Gold, Silver, and Bronze services respectively. For
example, when 140 Mbps of traffic is received for each of the four services, then the
permitted green-colored traffic is 50, 40, 30 and 20 Mbps respectively for the four services.
If only 140 Mbps of EF traffic is received, 50 Mbps of EF traffic as green and 5 Mbps of
EF traffic as yellow are permitted. In the same scenario, assume the macro-policer rate
to be 26 Mbps. Also, assume two child policers in color-aware mode, namely, child
policer-1 with a CIR of 10 Mbps and an EIR of 10 Mbps. Child policer-2 has a CIR of 15
Mbps and an EIR of 5 Mbps. When flow-1 is a 100 Mbps stream of yellow traffic, and
flow-2 is an 100 Mbps stream of green traffic, the output of this policer hierarchy is as
follows:
• Flow-1 has 0 Mbps of green traffic and has less than or equal to 5 Mbps of yellow traffic.
• Flow-2 has 10 Mbps of green traffic and has greater than or equal to 10 Mbps of yellow
traffic.

• The sum of yellow traffic is less than or equal to 11 Mbps .
in hybrid mode. PIRs for the children policers and the parent policer are configured. When
two flows, flow 1 and flow 2, transmit traffic at a rate that exceeds the configured PIR
values, then the share of the parent PIR is adjusted to permit traffic for the child policers
while the child PIR values are preserved for the two flows.
Hybrid mode of working of the aggregate or hierarchical policer supports two rates (CIR
and PIR) and three colors for micro-flows. On ACX routers, for hybrid type of the policer,
the micro-policer must be of type modified-trtcm as defined in RFC 4115. Both color-blind
and color- aware modes are supported for child policers. Macro policer must be a single
rate, single bucket, two color policer with the sum of the CIR values of the micro-flows
being less than the PIR value of the macro-flow, and the cumulative value of all the PIR
values of the micro-flows being greater than the PIR value of the macro-flow. When
micro-flow traffic is less than the CIR value of the micro-flow CIR, the policer causes
either the micro-flow CIR to be maintained or PIR to be achieved. When micro-flow traffic
is greater than the CIR value of the micro-flow, the micro-flow CIR is guaranteed.
Micro-flow excess rates are shared based on the available macro-flow bandwidth with
the limitation of the excess information rate distributed for the micro-flows being
implemented by the micro-flow PIR. The CBS of the macro-flow must be greater than
or equal to the aggregate of the micro-flow CBS. The excess burst size (EBS) of the
macro-flow must be greater than or equal to that of the micro-flow with the largest EBS.
An arriving packet complies with the hybrid mode if tokens are present in the committed
burst size (CBS) of the child policer. The packet does not comply with hybrid mode if
tokens are present in both the EBS of the child policer and the PBS of the parent policer.
When a packet does not satisfy the hybrid mode of working of a policer, the CIR of the
child policer is guaranteed for the member traffic flows and the PIR value of the child
policer is the maximum permitted rate for the member flows. The following table describes
the different scenarios of color-coding for micro-flow and macro-flow policers and the
resultant color or priority that is assigned:
Green Green Green
Red Green Green
Yellow Green Yellow
Yellow Red Red
Red Green Red
Red Red Red

Documentation

Processing of Hierarchical Policers
Hierarchical policer provisions a controlled sharing of an aggregate among micro-flows.

For example, a hierarchical policer is used to share the bandwidth of a certain subscriber
or user across different CoS settings of that user. Assume that the user is configured to
connect using a logical interface, and the CoS functionality is configured using DiffServ
code point (DSCP) in the traversed packet. The user is assigned an aggregate bandwidth
of 140 Mbps. This consolidated bandwidth must be distributed and shared amongst the
four supported CoS settings represented by DSCP values of 11, 12, 21, and 22 respectively
in the order of 50 Mbps, 40 Mbps, 30 Mbps and 20 Mbps. To obtain this behavior, you
must perform the following configurations:
• Configure micro-flows--A micro-flow is characterized by all packets that pass through

the same micro policer (or child policer) instance. To enable this configuration, packets
must be classified as micro-flows by using filters to match the packets, and the action
of the filter to refer to the macro policer. You can group and combine packets matching
multiple different filters or terms into a single micro-flow by specifying the same policer
instance across the different filters and terms. These settings are identical to the
configuration required to associate a single-level policer with a filter.
• Assign child policers to the aggregate policer--This step is additional, from the procedure
to create a single-level policer, to configure a hierarchical policer. You must link or
associate the child policers to the parent or aggregate policer. You can perform this
linking by specifying at each child policer by using the aggregate-policing
aggregate-policer-name statement at the [edit firewall policer policer-name] hierarchy
level.

routers.

Documentation

Actions Performed for Hierarchical Policers
The hierarchical parent policer impacts the packet loss priority (PLP) of the child policer.
The PLP-based actions defined in the then statement of the are performed, based on
the PLP derived from the combined processing of the child and parent policers. The then
statement defined in the parent policer is not effective. This section contains the following
topics that describe the methods of instantiation of aggregate or hierarchical policers
and child or normal policers.

routers.
Instantiation Methods for Child and Aggregate Policers

In the Junos OS, a certain policer configuration or a policer template is used to create
multiple instances of the policer in the hardware using the template attributes such as
the CIR, PIR, CBS, and PBS values specified in the template. You need not create multiple
policer configurations with the same attributes for effective management by using
aggregate policers.
Instantiation Methods for Child Policers or Normal Policers

For a normal policer or a child policer, if you specify a filter-specific attribute for a policer
by entering the filter-specific statement at the [edit firewall policer policer-name] or [edit
logical-systems logical-system-name firewall policer policer-name] hierarchy level, when
you specify a ‘filter-specific’ clause, a single policer instance is used by all terms (within
the same firewall filter) that reference the policer. For example, if a filter F1 contains
terms T1 and T2, they refer to the same policer, say P1. If you configure the policer P1 as
a filter-specific type, the same policer instance on the device is referred by both the terms
T1 and T2. In this case, F1 is attached to a logical interface named IFL1, which is configured
on the physical interface named IFD1.
By default, a policer operates in term-specific mode so that, for a given firewall filter, the
Junos OS creates a separate policer instance for every filter term that references the
policer. This operation is the default instantiation mode if you do not configure the
filter-specific statement. For example, consider a filter F1 that has two terms, T1 and T2.
Both these terms refer to the same policer, namely P1. With a term-specific mode of the
policer, two policer instances are created on the device, one each for terms T1 and T2.
Instantiation Methods for Aggregate Policers

The following modes of operations are possible for aggregate policers.
• Global—Shares the same parent policer across all the child policer instances in the
system.
• Physical interface-specific—Shares the same parent policer across all the child policer
instances of a certain physical interface. This mode is not supported on ACX routers.

• Filter-specific—Shares the same parent policer across all the child policer instances
of the same filter. This mode is not supported on ACX routers.
• Interface-specific—Shares the same parent policer across all the child policer instances
of the same logical interface. This mode is not supported on ACX routers.
You can include the aggregate global statement at the [edit firewall policer
policer-template-name] hierarchy level to define an aggregate policer to be shared or
applicable across all of the child policer instances in the router. You can include the
aggregate parent statement at the [edit firewall policer policer-template-name] hierarchy
level to define an aggregate policer as the parent policer. The following statement does
not take effect for aggregate policers: set firewall policer policer-template-name
filter-specific.
Consider a sample deployment in which an aggregate policer named P3 is configured.

P1 and P2 are child policers. T1, T2, T3, and T4 are terms. F1 and F2 are filters. Logical
interfaces, IFL1 and IFL2, are created on the underlying physical interfaces, IFD1 and IFD2
in this configuration. Interface address families are correspondingly created on the
interfaces as IFF1 and IFF2.
If you configure an interface-specific filter, term-specific child policer, and the aggregate
policer as the global policer, a single instance of P3 is created and associated with the
child policers, P1 and P2. Two instances each of P1 and P2 are created, one for T1 within
F1 and the other for T2 within F1. The two instances each of P1 and P2 are associated
with IFL1 and IFL2, which in turn are bound to IFD1 and IFD2.
If you configure an interface-specific filter, term-specific or filter-specific child policer,

and the aggregate policer is physical interface- specific policer, two instances of P3 are
created. One instance of P3 contains two child policer instances of P1. P1 contains the
filter F1 and term T1 to be applied to IFL1 and IFL2. The other instance of P3 contains two
child policer instances of P1. P1 contains F1 and T1 to be applied to another two logical
interfaces, IFL3 and IFL4.
If you configure an interface-specific filter, term-specific child policer, and

interface-specific aggregate policer, two instances of P3 are created. Each P3 instance
contains two P1 instances. One P1 instance contains F1 and T1 for IFF1 to be applied to
IFL1. The other P1 instance contains F2 for IFF2 to be applied to IFL1. The other P3 instance
contains two P1 instances. Here, one P1 contains F1 and T1 for IFF3 and the other P1
contains F2 and T1 for IFF4 to be applied on IFL2.
If you configure an interface-specific filter, term-specific child policer, and filter-specific

aggregate policer, two P3 instances are created. Each P3 contains two P1 instances. One
P1 contains P1, T1, F1 IFF1, applied to IFL1. The other P1 contains P1, T2, F1, IFF1, applied to
IFL1. The third P1 contains P1, T3, F2, IFF2, applied to IFL1. The last P1 contains P1, T4, F2,
IFF2, applied to IFL1.

Documentation

Configuring Aggregate Parent and Child Policers on ACX Series Routers
On ACX Series routers, two-level ingress hierarchical policing is supported. Single-level

policers define a single bandwidth profile. You must first define the child or subordinate
policers and associate or link them with the aggregate parent policer, which is globally
applicable for the entire system. You can configure the mode of hierarchical or aggregate
policing for the child policers, such as peak mode, guarantee mode, or hybrid mode of
policing.

routers.
NOTE: The hierarchical policing mechanism on ACX routers is different from

the hierarching policing capability supported on MX Series routers. On MX
Series routers, with a hierarchical policer, only one child or subordinate policer
can be configured under a parent, top-level policer, whereas on ACX Series
routers, you can aggregate and specify multiple child policers under a single
parent policer. The hierarchical policing methodology on ACX routers is also
called aggregate policing. The hierarchical-policer statement and its
substatements at the [edit firewall] hierarchy level that are supported on MX
Series routers are not available for ACX Series routers.
To configure child or micro policers for an aggregate parent policer and associate the
parent policer with the child policers:
1. Configure one normal policer as a child policer and specify the aggregate policing
mode.
user@host# set policer mi_pol_1 if-exceeding bandwidth-limit 25m

user@host# set policer mi_pol_1 if-exceeding burst-size-limit 3k
user@host# set policer mi_pol_1 if-exceeding aggregate-policing policer mi_pol_x
aggregate-sharing-mode peak;
user@host# set policer mi_pol_1 then discard
2. Configure another normal policer as a child policer and specify the aggregate policing
mode. The aggregate-sharing-mode option is a Packet Forwarding Engine statement.
user@host# set policer mi_pol_2 if-exceeding bandwidth-limit 30m

user@host# set policer mi_pol_2 if-exceeding burst-size-limit 30k
user@host# set policer mi_pol_2 if-exceeding aggregate-policing policer mi_pol_x
aggregate-sharing-mode peak;
user@host# set policer mi_pol_2 then discard

3. Define the aggregate parent policer as the global policer for the system. The
aggregate-sharing-mode option is a Packet Forwarding Engine statement.
user@host# set policer mi_pol_x if-exceeding bandwidth-limit 55m

user@host# set policer mi_pol_x if-exceeding burst-size-limit 35k
user@host# set policer mi_pol_x aggregate global
4. Verify the settings of all policer templates configured by using the show filter policer
template command.
user@host# show filter policer template

AppType Template name Bw limit-bits/sec Burst-bytes Action
Options
------- ------------- ----------------- -----------
--------------
0 mi_pol_1
25000000 3000 DROP
Aggregate Child of mi_pol_x mode=2
0 mi_pol_2
30000000 30000 DROP
Aggregate Child of mi_pol_x mode=2
0 mi_pol_x
55000000 35000 DROP
Aggregate Parent
5. View the configured policer instances that are linked to the aggregate parent policer
by using the show filter aggregate-policer command.
user@host# show filter aggregate-policer p1

CHILDREN
-------
#1) [UNI1_filtermi_pol_trtcm1-t2] CBS[1000]kB; CIR[10000]kbps; CBS[2000]kB;
PIR[30000]kbps; Agg mode = 3;
#2) [UNI2_filtermi_pol_trtcm2-t2] CBS[1000]kB; CIR[15000]kbps; CBS[2000]kB;
PIR[35000]kbps; Agg mode = 3;
PARENT
------
[p1] PBS[3000]kB; PIR[38000]kbps;
Sum child CIR[25000]kbps;CBS[2000]kB;
Sum child PIR[65000]kbps;PBS[4000]kB;
Max child CIR[15000]kbps;CBS[1000]kB;
Max child PIR[35000]kbps;PBS[2000]kB;
RESULTS
-------
STATUS = OK

Documentation

Hierarchical Class of Service Overview
Hierarchical class of service (HCoS) is the ability to apply traffic schedulers and shapers
to a hierarchy of scheduler nodes. Each level of the scheduler hierarchy can be used to
shape traffic based on different criteria such as application, user, VLAN, and physical
port.
This allows you to support the requirements of different services, applications, and users
on the same physical device and physical infrastructure.
HCoS is implemented primarily using traffic classifiers at the ingress and hierarchical
schedulers and shapers at the egress.
A classifier is a filter that labels traffic at the device ingress based on configurable
parameters such as application or destination. Traffic is classified into what is called a
forwarding equivalence class (FEC). The FEC defines a class of traffic that receives
common treatment.
Schedulers, and their associated shapers, is the function that controls the traffic
bandwidth, jitter (delay variation), and packet loss priority at the egress of the device.
Hierarchical schedulers are used to apply multiple levels of scheduling and shaping with
each level applied to different classifications such as forwarding equivalence class, VLAN,
and physical interface (port) as shown in Figure 58 on page 934.

Figure 58: Hierarchical Scheduling Architecture
NOTE: Hierarchical class of service is also referred to as Hierarchical Quality

of Service (HQoS) in other vendor’s documentation.
A typical application of HCoS is to configure multiple levels of egress schedulers and

shapers, at the subscriber edge, using dynamic profiles to provide traffic shaping and
prioritization at the subscriber VLAN level and for multiple classes of traffic.
Dynamic profiles are a mechanism that allows you to dynamically apply schedulers and
shapers to individual subscribers or groups of subscribers.
To learn more about HCoS, the following topics are very helpful:
• Junos CoS on MX Series 3D Universal Edge Routers Overview
• CoS Features and Limitations on MX Series Routers
• CoS Features of the Router Hardware, PIC, MIC, and MPC Interface Families
• How Schedulers Define Output Queue Properties
• Subscriber Access Network Overview
• CoS for Subscriber Access Overview
• Hierarchical Class of Service for Subscriber Management Overview

The Junos OS hierarchical schedulers support up to five levels of scheduler hierarchies

on MX Series devices when using enhanced queuing Dense Port Concentrators (DPCs)
or fine-grained queuing Modular Port Concentrators (MPCs), and Modular Interface Cards
(MICs). It is important to know the capabilities of your hardware with respect to HCoS.
The following are a few tips to help you:
• Only certain hardware supports the five-level scheduler hierarchy of HCoS.
• The number of queues and logical interfaces supported is dependent upon exactly
what hardware you are using.
• The MX Series Packet Forwarding Engine handles guaranteed bandwidth and scheduler
node weight differently than other Packet Forwarding Engines.
• The fine-grained queuing MPCs and MICs have a certain granularity with respect to
the shaping and delay buffer values. The values used are not necessarily exactly the
values configured.
To learn more about platform support for HCoS, use the Juniper Networks Feature Explorer
(http://pathfinder.juniper.net/feature-explorer/). In the Feature Explorer, search on
hierarchical schedulers.
In addition, it is important to note the following:
• HCoS is most frequently used to enforce service level agreements at the subscriber
edged using dynamic traffic control profiles.
• Hierarchical schedulers can also be applied to Ethernet pseudowire interfaces,

aggregated Ethernet interfaces, Layer 2 Tunnel Protocol (L2TP) network server (LNS)
inline services, and GRE tunnels.
• Hierarchical ingress policing is a feature that is complimentary to and often used in

conjunction with HCoS.
• There are other features in Junos OS that have similar sounding names.
NOTE: The hierarchical scheduler and shaper feature supported on the SRX
Series devices is not the HCoS feature described here.
Before planning HCoS for you network, you should learn about HCoS, define you needs,
plan how you want to implement HCoS, and test the operation in a simulated environment.
Table 53: Resources for Learning More About HCoS

Document Description
Day One: Deploying Basic QoS Juniper This book is a good resource for learning the basics of CoS on Juniper
Networks Books Networks devices.
Juniper MX-Series O'Reilly Media Learn about the advanced features of HCoS. This book provides an in-depth
description of how HCoS works and how it can be deployed. It also provides
a lab tested topology and configuration example.

Table 53: Resources for Learning More About HCoS (continued)

Document Description
Day One: Dynamic Subscriber Management Learn how to use HCoS in conjunction with dynamic traffic control profiles
Juniper Networks Books for subscriber management. This book also includes troubleshooting.
QoS Enabled Networks John Wiley & Sons This book is an additional source for studying QoS.
Documentation related to HCoS is consolidated in the Hierarchical Class of Service Feature

Guide.
Related • Hierarchical Class of Service for Subscriber Management Overview

Documentation
• Hierarchical Class of Service Network Scenarios
• Understanding Hierarchical Scheduling
Hierarchical Class of Service in ACX5000
ACX5000 Series routers support hierarchical class of service at the physical interface
level. You can configure up to 8 queues per physical interface (port). Scheduling properties
can be applied at both physical as well as logical interface levels. Service providers will
be able to support hierarchical class of service at multiple levels to meet the service level
agreements and bandwidth allocations for subscribers.
• Hierarchical Scheduling on the Physical Interface on page 936

• Traffic Control Profiles on page 937
• Schedulers on page 937
• Drop Profiles on page 938
• Scheduler Maps on page 938
• Applying the Traffic Control Profiles on page 938
• Subscriber Services on page 939
Hierarchical Scheduling on the Physical Interface

By default, the queuing mode on all the physical interfaces in the ACX5000 line of routers
is 8 queues per physical interface (port). In the hierarchical scheduler mode, you can
configure up to 3 levels (physical interface, logical interface, and queues) of scheduling.
You can enable hierarchical scheduling by including the hierarchical-scheduler CLI

command under the interfaces hierarchy as shown below:
[edit]
interfaces ge-0/0/1 {
hierarchical-scheduler;
}

NOTE: If you change the physical interface queuing mode from default to
hierarchical scheduler mode or vice-versa, the traffic flowing out of the
physical interface during the mode change results in a transient loss of traffic
data.
Traffic Control Profiles

The traffic control profiles hold parameters for levels above the queue level of the
scheduler hierarchy. The scheduling and shaping configuration on the scheduler nodes
are configured using traffic-control-profiles CLI command and scheduler is for queue
level. The traffic control profile defines the following characteristics of a scheduler node:
• Scheduler-map
• Shaping rate
• Guaranteed rate
Traffic control profiles can be attached at physical interface and logical interface level.
Scheduling and queuing characteristics can be defined for the scheduler node using the
shaping-rate and guaranteed-rate. The following is a sample traffic control profile
configuration:
[edit class-of-service traffic-control-profiles]

tcp-500m-shaping-rate {
shaping-rate 500m;
}
tcp-ifl0 {
shaping-rate 200m;
guaranteed-rate 100m;
scheduler-map tcp-map-ifl0; # Applies scheduler maps to customer VLANs.
}
Schedulers
A scheduler defines scheduling and queuing characteristics of a queue and holds the
information about the queues, the last level of the hierarchy. The following is a sample
scheduler configuration:
[edit class-of-service schedulers]

sched-ifl0-q0 {
priority low;
transmit-rate 20m;
buffer-size temporal 100ms;
drop-profile loss-priority low dp-low;
drop-profile loss-priority high dp-high;
}
sched-ifl-q1 {
shaping-rate 20m;
}

Drop Profiles
Drop profiles allow you to specify queue specific behavior to drop packets based on
WRED profile under congestion. The following is a sample drop profile configuration:
[edit class-of-service drop-profiles]

dp-low {
}
dp-high {
}
Scheduler Maps
A scheduler map is referenced by traffic control profiles to define queues. The scheduler
map establishes the number of queues over a scheduler node, associating a
forwarding-class with a scheduler. The following is a sample scheduler map configuration:
[edit class-of-service scheduler-maps]

sched-map-ifl0 {
forwarding-class voice scheduler sched-vlan0-qx;
forwarding-class video scheduler sched-vlan0-qx;
forwarding-class data scheduler sched-vlan0-qx;
}
tcp-map-vlan1 {
forwarding-class voice scheduler sched-vlan1-q0;
forwarding-class video scheduler sched-vlan1-qx;
forwarding-class data scheduler sched-vlan1-qx;
}
tcp-map-vlanx {
forwarding-class voice scheduler sched-vlanx-qx;
forwarding-class video scheduler sched-vlanx-qx;
forwarding-class data scheduler sched-vlanx-qx;
}
Applying the Traffic Control Profiles

You can attach the traffic control profiles at various levels of the scheduler hierarchy to
achieve hierarchical class of service. The following is a sample configuration to apply
traffic control profiles:
NOTE: Although a shaping rate can be applied directly to the physical

interface, hierarchical schedulers must use a traffic control profile to hold
this parameter.
[edit class-of-service interfaces]

ge-1/0/0 {
output-traffic-control-profile tcp-500m-shaping-rate;
unit 0 {
output-traffic-control-profile tcp-vlan0;

}
}
Subscriber Services
ACX5000 line of routers support hierarchical class of service functionality for subscriber
services such as Layer 3 VPN, Layer 2 VPN, Ethernet pseudowire (VPWS), and VPLS for
logical interface instance on the AC (Access Port).
NOTE: Hierarchical class of service is not supported for Layer 2 bridging

(bridge domain VLAN) service.
The following sections explain the hierarchical class of service configuration for subscriber
services:
• Configuring hierarchical class of service for Layer 3 VPN Service on page 939
• Configuring hierarchical class of service for Layer 2 VPN (Ethernet Pseudowires)
Service on page 940
• Configuring hierarchical class of service for VPLS Service on page 941
• Verifying the hierarchical class of service configurations on page 942
Configuring hierarchical class of service for Layer 3 VPN Service
ACX5000 line of routers can be configured to provide Layer 3 VPN services to subscribers
by connecting the UNI port to a CE device. The physical port can be configured to provide
Layer 3 VPN services to multiple subscribers. You can schedule traffic for different Layer
3 VPN instances based on the SLA parameters agreed with the subscriber.
The following is a sample UNI and NNI logical interface configuration on the PE router
providing the Layer 3 VPN service:
[edit interfaces]
xe-0/0/1 {
description “NNI IFL”;
unit 0 {
family inet {
address 100.1.1.1/24;
}
family mpls;
}
}
ge-0/0/1 {
description “UNI IFL”;
unit 0 {
vlan-id 100;
family inet {
address 20.20.0.1/24;
}
}
unit 1 {

vlan-id 101;
family inet {
address 20.20.1.1/24;
}
}
unit 2 {
vlan-id 2;
family inet {
address 20.20.2.1/24;
}
}
unit 3 {
vlan-id 3;
family inet {
address 20.20.3.1/24;
}
}
unit 4 {
vlan-id 4;
family inet {
address 20.20.4.1/24;
}
}
...
}
Scheduling can be enabled on the interfaces to achieve hierarchical class of service

support for traffic flowing from NNI towards UNI direction.
Configuring hierarchical class of service for Layer 2 VPN (Ethernet Pseudowires)

Service
based on Ethernet pseudowires where the UNI port is connected to a CE device. The
physical port can be configured to provide Layer 2 VPN services to multiple subscribers.
You can schedule traffic for different pseudowires based on the SLA parameters agreed
with the subscriber. Hierarchical class of service can be enabled per UNI logical interface
represented as the attachment point of the Ethernet pseudowire to achieve the
functionality.
The following is a sample to configure the UNI logical interface on the PE router providing
the Layer 2 VPN service based on Ethernet pseudowire:
[edit interfaces]
ge-0/0/1 {
vlan-tagging;
unit 0 {
vlan-id 0;
}
unit 1 {
vlan-id 1;
}

unit 2 {
vlan-id 2;
}
unit 3 {
vlan-id 3;
}
unit 4 {
vlan-id 4;
}
}
You can enable scheduling on the interfaces to achieve hierarchical class of service for
traffic flowing from NNI towards UNI direction.
Configuring hierarchical class of service for VPLS Service
based on VPLS where the UNI port can be connected to a CE device. Subscriber network
is attached to UNI logical interface at the PE router and have a VPLS instance. The same
physical port can service multiple VPLS instances for various subscribers. The service
provider can schedule traffic for different VPLS instances based on the SLA parameters
agreed with the subscriber. You can enable hierarchical class of service per UNI logical
interface representing the VPLS instance for the subscriber to achieve the functionality.
The following is a sample to configure the UNI logical interface on the PE router providing
the VPLS service:
[edit interfaces]
ge-0/0/1 {
vlan-tagging;
unit 0 {
vlan-id 0;
}
unit 1 {
vlan-id 1;
}
unit 2 {
vlan-id 2;
}
unit 3 {
vlan-id 3;
}
unit 4 {
vlan-id 4;
}

Scheduling can be enabled on the interfaces to achieve hierarchical class of service for
the traffic flowing from NNI towards UNI direction.
Verifying the hierarchical class of service configurations
You can use the following CLI commands to verify the configuration:
• show interfaces queue—Shows physical interface aggregate, physical interface

remaining, and logical interface traffic statistics to monitor the traffic received and
transmitted. The following are some sample outputs of show interfaces queue CLI
command:
user@host# run show interfaces queue ge-0/0/4.2

Logical interface ge-0/0/4.2 (Index 555) (SNMP ifIndex 671)
Forwarding classes: 16 supported, 8 in use
Burst size: 0
Queue: 0, Forwarding classes: 8q0
Queued:
Packets : 1121476 7642 pps
Bytes : 587885024 32237416 bps
Transmitted:
Packets : 594964 3160 pps
Bytes : 304621568 12946280 bps
Tail-dropped packets : Not Available
RL-dropped packets : 0 0 pps
RL-dropped bytes : 0 0 bps
Total-dropped packets: 526512 4482 pps
Total-dropped bytes : 283263456 19291136 bps
Queue Buffer Usage:
Reserved buffer : 0 pkts 0 bytes
Shared buffer : 0 pkts 0 bytes
Queued:
Packets : 1121476 7642 pps
Bytes : 587885154 32237416 bps
Transmitted:
Bytes : 304619008 12946280 bps
Queue Buffer Usage:
Queued:
Packets : 1119456 7321 pps
Bytes : 595127702 31122568 bps
Transmitted:
Bytes : 140595712 6144000 bps


Queue Buffer Usage:
Queued:
Packets : 1119464 7303 pps
Bytes : 595131980 31122568 bps
Transmitted:
Bytes : 140596224 6144000 bps
Queue Buffer Usage:
Queued:
Packets : 1121476 7642 pps
Bytes : 587885024 32237416 bps
Transmitted:
Bytes : 304621568 12946280 bps
Queue Buffer Usage:
Queued:
Packets : 1121476 7660 pps
Bytes : 587885024 32310560 bps
Transmitted:
Bytes : 304621568 13019424 bps
Queue Buffer Usage:
Queued:
Packets : 1121476 7017 pps
Bytes : 587190842 29535136 bps
Transmitted:
Bytes : 318302208 14701712 bps

Queue Buffer Usage:

Queued:
Packets : 1121477 6481 pps
Bytes : 586036910 27137704 bps
Transmitted:
Bytes : 341025792 14994280 bps
Queue Buffer Usage:
user@host# run show interfaces queue ge-0/0/4 aggregate

Physical interface: ge-0/0/4, Enabled, Physical link is Up
Description: UNI side - connected to ixia 6/9
Queued:
Packets : 16762731 33205 pps
Bytes : 8738362264 139058280 bps
Transmitted:
Packets : 8779233 13724 pps
Bytes : 4494967296 56220880 bps
Queue Buffer Usage:
Queued:
Packets : 16762732 33237 pps
Bytes : 8738359966 139190408 bps
Transmitted:
Packets : 8779363 13756 pps
Bytes : 4495033856 56353008 bps
Queue Buffer Usage:
Queued:
Packets : 16754769 30221 pps
Bytes : 8826383526 127522040 bps
Transmitted:
Packets : 4052168 6369 pps

Bytes : 2074710016 26095472 bps

Queue Buffer Usage:
Queued:
Packets : 16754937 30328 pps
Bytes : 8826406908 127965968 bps
Transmitted:
Packets : 4052173 6378 pps
Bytes : 2074646336 26134456 bps
Queue Buffer Usage:
Queued:
Packets : 16762735 33406 pps
Bytes : 8738360722 139886136 bps
Transmitted:
Packets : 8779404 13828 pps
Bytes : 4495054848 56648672 bps
Queue Buffer Usage:
Queued:
Packets : 16762734 33285 pps
Bytes : 8738359924 139389112 bps
Transmitted:
Packets : 8779416 13788 pps
Bytes : 4495060992 56485136 bps
Queue Buffer Usage:
Queued:
Packets : 16762732 27688 pps
Bytes : 8721917186 115931832 bps
Transmitted:
Packets : 9618678 12111 pps
Bytes : 4924763136 49614432 bps


Queue Buffer Usage:
Queued:
Packets : 16762733 26045 pps
Bytes : 8710804790 108947832 bps
Transmitted:
Packets : 10187546 11805 pps
Bytes : 5216023552 48359208 bps
Queue Buffer Usage:
user@host# run show interfaces queue ge-0/0/4 remaining-traffic

Physical interface: ge-0/0/4, Enabled, Physical link is Up
Description: UNI side - connected to ixia 6/9
Queued:
Bytes : 41609646 26235344 bps
Transmitted:
Bytes : 1641472 999248 bps
Queue Buffer Usage:
Queued:
Bytes : 41444318 26107008 bps
Transmitted:
Bytes : 4776960 3002344 bps
Queue Buffer Usage:

Queued:
Bytes : 41362188 26054080 bps
Transmitted:
Bytes : 6357504 3996992 bps
Queue Buffer Usage:
Queued:
Bytes : 41609314 26271632 bps
Transmitted:
Bytes : 1646862 999248 bps
Queue Buffer Usage:
Queued:
Bytes : 41450894 26131200 bps
Transmitted:
Bytes : 4786688 3002344 bps
Queue Buffer Usage:
Queued:
Bytes : 41358904 26032304 bps
Transmitted:
Bytes : 6371328 3996992 bps
Queue Buffer Usage:
Queued:


Bytes : 41151002 25749384 bps
Transmitted:
Bytes : 15659520 9997088 bps
Queue Buffer Usage:
Queued:
Bytes : 41151540 25749384 bps
Transmitted:
Bytes : 15659520 9997088 bps
Queue Buffer Usage:
• show class-of-service packet-buffer usage—Shows the total buffer usage of the system.
The following is a sample output of the show class-of-service packet-buffer usage CLI
command:
user@host# run show class-of-service packet-buffer usage

Egress:
Total Buffer Bytes : 10652.89 KB in use out of 12480.00 KB
Total Buffer Pkts : 52445 in use out of 61440
Dedicated Buffer Bytes : 48.14 KB in use out of 738.16 KB
Dedicated Buffer Pkts : 237 in use out of 3634
Shared Buffer Bytes : 10604.75 KB in use out of 11741.84 KB
Shared Buffer Pkts : 52208 in use out of 57806
You can use the syslog to view the log messages and error reports.
Related
Documentation

CHAPTER 28
Configuring Behavior Aggregate Classifiers
• Understanding How Behavior Aggregate Classifiers Prioritize Trusted Traffic on page 950
• Default Behavior Aggregate Classification Overview in ACX Series on page 953
• Default IP Precedence Classifier on page 954
• Default MPLS EXP Classifier on page 955
• Default IEEE 802.1p Classifier on page 956
• Default IEEE 802.1ad Classifier on page 957
• Default DSCP and DSCP IPv6 Classifier on page 958
• Applying DSCP and DSCP IPv6 Classifiers on page 959

Understanding How Behavior Aggregate Classifiers Prioritize Trusted Traffic
The idea behind class of service (CoS) is that packets are not treated identically by the
routers or switches on the network. In order to selectively apply service classes to specific
packets, the packets of interest must be classified in some fashion.
The simplest way to classify a packet is to use behavior aggregate (BA) classification,
also called the CoS value in this document. The DSCP, DSCP IPv6, or IP precedence bits
of the IP header convey the behavior aggregate class information. The information might
also be found in the MPLS EXP bits, IEEE 802.1ad, or IEEE 802.1p CoS bits.
NOTE: Support was added for filtering on Differentiated Services Code Point
(DSCP) and forwarding class for Routing Engine sourced packets, including
IS-IS packets encapsulated in generic routing encapsulation (GRE).
Subsequently, when upgrading from a previous version of Junos OS where
you have both a class of service (CoS) and firewall filter, and both include
DSCP or forwarding class filter actions, the criteria in the firewall filter
automatically takes precedence over the CoS settings. The same is true when
creating new configurations; that is, where the same settings exist, the firewall
filter takes precedence over the CoS, regardless of which was created first.
BA classification is useful if the traffic comes from a trusted source and the CoS value
in the packet header is trusted. If the traffic is untrusted, multifield classifiers (see
“Overview of Assigning Service Levels to Packets Based on Multiple Packet Header Fields”
on page 891) are used to classify packets based on multiple packet fields. It is common
to use multifield classifiers to classify traffic at the ingress of a network, rewrite the packet
headers (see Rewriting Packet Headers to Ensure Forwarding Behavior), then use the more
efficient BA classification for transversing the network.
The BA classifier maps a CoS value in the packet header to a forwarding class and loss
priority. The forwarding class determines the output queue. The loss priority is used by
schedulers in conjunction with the random early discard (RED) algorithm to control
packet discard during periods of congestion.
Figure 59 on page 950 provides a high-level illustration of how a classifier works.
Figure 59: How a Classifier Works

Chapter 28: Configuring Behavior Aggregate Classifiers
The types of BA classifiers are based on which part of the incoming packet the classifier
examines:
• DSCP, DSCP IPv6, or IP precedence—IP packet classification (Layer 3 headers)
• MPLS EXP—MPLS packet classification (Layer 2 headers)
• IEEE 802.1p—Packet classification (Layer 2 headers)
• IEEE 802.1ad—Packet classification for IEEE 802.1ad formats (including DEI bit)
Unlike multifield classifiers (which are discussed in “Overview of Assigning Service Levels
to Packets Based on Multiple Packet Header Fields” on page 891), BA classifiers are based
on fixed-length fields, which makes them computationally more efficient than multifield
classifiers. For this reason, core devices are normally configured to perform BA
classification, because of the higher traffic volumes they handle.
In most cases, you need to rewrite a given marker (IP precedence, DSCP, IEEE 802.1p,
IEEE 802.1ad, or MPLS EXP settings) at the ingress node to accommodate BA
classification by core and egress devices. For more information about rewrite markers,
see Rewriting Packet Headers to Ensure Forwarding Behavior.
NOTE: If you apply an IEEE 802.1 classifier to a logical interface, this classifier
takes precedence and is not compatible with any other classifier type.
Classifiers for IP (DSCP or IP precedence) and MPLS (EXP) can coexist on a
logical interface if the hardware requirements are met.
For Juniper Networks M Series Multiservice Edge Routers, four classes can forward traffic
independently. For M320 Multiservice Edge Routers, T Series Core Routers, MX Series
3D Universal Edge Routers, and PTX Series Packet Transport Routers, eight classes can
forward traffic independently. If you carry more classes of traffic than the device can
forward independently, you must configure the additional classes to be aggregated into
one of the available classes. You use the BA classifier to configure class aggregation.

NOTE: For a specified interface, you can configure both a multifield classifier
and a BA classifier without conflicts. Because the classifiers are applied in
sequential order if they are both either protocol specific or protocol
independent, the BA classifier followed by the multifield classifier, any BA
classification result is overridden by a multifield classifier if they conflict.
In the case that a protocol-specific BA classifier and a protocol-independent

firewall filter are both configured together, the protocol-independent filter
is processed before the protocol-specific BA classifier, regardless or protocol
family. firewall family any filter is protocol independent and will be always
processed before protocol-specific BA classifiers.
Fixed classification is protocol independent as well, hence, it is executed

before any firewall filter.
For more information about multifield classifiers, see “Overview of Assigning

Service Levels to Packets Based on Multiple Packet Header Fields” on page 891.
For more information about protocol-independent filters, see “Guidelines for
Configuring Firewall Filters” on page 1044. For more information about fixed
classification, see Applying Forwarding Classes to Interfaces.
If you do nothing to configure or assign classifiers, Junos OS automatically assigns an

implicit default IP precedence classifier to all logical interfaces that maps IP precedence
code points to best-effort and network-control forwarding classes (mapped to queue 0
and queue 3 on routing devices, respectively). The default Junos OS CoS policy reserves
5 percent of available bandwidth for network-control traffic and 95 percent for best-effort
traffic. Junos OS provides a range of default BA classifiers that you can apply to logical
interfaces and that map various CoS values to assured-forwarding and
expedited-forwarding forwarding classes as well as to the best-effort and network-control
forwarding classes. You can also define custom BA classifiers that map any CoS value
to any classifier you define.
NOTE: The default Junos OS CoS policy, 95 percent of the bandwidth for
queue 0 and 5 percent for queue 3 on routing devices (see Default Schedulers
Overview), is in effect regardless of any custom BA classifier or forwarding
class definitions, until you configure a custom scheduler (see Configuring
Schedulers).
If you enable the MPLS protocol family on a logical interface, a default MPLS EXP classifier
is automatically applied to that logical interface. This default EXP classifier (see Default
MPLS EXP Classifier) maps the eight possible EXP code point values into a combination
of the four default forwarding classes and loss priority values to be directly compatible
with the default EXP rewrite rule (see Rewriting MPLS and IPv4 Packet Headers).
Other default classifiers (such as those for IEEE 802.1p bits and DSCP) require that you
explicitly associate a default classification table with a logical interface. When you

explicitly associate a default classifier with a logical interface, you are in effect overriding
the implicit default classifier with an explicit default classifier.
NOTE: Only the IEEE 802.1p classifier is supported in Layer 2-only interfaces.
You must explicitly apply this classifier to the interface as shown in Default
IEEE 802.1p Classifier.
NOTE: Although several CoS values map to the expedited-forwarding (ef)

and assured-forwarding (af) classes, by default no resources are assigned
to these forwarding classes. All af classes other than af1x are mapped to
best-effort, because RFC 2597, Assured Forwarding PHB Group, prohibits a
node from aggregating classes.
You can apply IEEE 802.1p classifiers to interfaces that are part of VPLS routing instances.
13.3R7 Support was added for filtering on Differentiated Services Code Point (DSCP)
and forwarding class for Routing Engine sourced packets, including IS-IS
packets encapsulated in generic routing encapsulation (GRE).
Related • Default IP Precedence Classifier on page 954

Documentation
• Default DSCP and DSCP IPv6 Classifiers
• Default MPLS EXP Classifier
• Default IEEE 802.1p Classifier
• Default IEEE 802.1ad Classifier
• Configuring Behavior Aggregate Classifiers
• Applying Behavior Aggregate Classifiers to Logical Interfaces
• Overview of Assigning Service Levels to Packets Based on Multiple Packet Header

Fields on page 891
• Rewriting Packet Headers to Ensure Forwarding Behavior
Default Behavior Aggregate Classification Overview in ACX Series
The software automatically assigns an implicit default IP precedence classifier to all

physical interfaces.
Other default classifiers (such as those for IEEE 802.1p bits and DSCP) require that you
explicitly associate a default classification table with a physical interface. When you

explicitly associate a default classifier with a logical interface, you are in effect overriding
the implicit default classifier with an explicit default classifier.
NOTE: Although several code points map to the expedited-forwarding (ef)

and assured-forwarding (af) classes, by default no resources are assigned
to these forwarding classes. All af classes other than af1x are mapped to
best-effort, because RFC 2597, Assured Forwarding PHB Group, prohibits a
node from aggregating classes.
Documentation
• Overview of BA Classifier Types
Default IP Precedence Classifier
By default, all logical interfaces are automatically assigned an implicit IP precedence

classifier called ipprec-compatibility. The ipprec-compatibility IP precedence classifier
maps IP precedence bits to forwarding classes and packet loss priorities (PLPs), as shown
in Table 54 on page 954.
Table 54: Default IP Precedence (ipprec-compatibility) Classifier

IP Precedence Bits Forwarding Class Loss Priority
000 best-effort low
001 best-effort high
010 best-effort low
100 best-effort low
110 network-control low
111 network-control high
The other default IP precedence classifier (called ipprec-default) overrides the

ipprec-compatibility classifier when you explicitly associate it with a logical interface. To
do this, include the default statement at the [edit class-of-service interfaces interface-name
unit logical-unit-number classifiers inet-precedence] hierarchy level:
[edit class-of-service interfaces interface-name unit logical-unit-number classifiers

inet-precedence]
default;

Table 55 on page 955 shows the forwarding class and PLP that are assigned to the IP
precedence bits when you apply the default IP precedence classifier.
Table 55: Default IP Precedence (ipprec-default) Classifier

IP Precedence Bits Forwarding Class PLP
000 best-effort low
001 assured-forwarding low
010 best-effort low
011 best-effort low
100 best-effort low
101 expedited-forwarding low
Related • Applying Behavior Aggregate Classifiers to Logical Interfaces

Documentation
Default MPLS EXP Classifier
Table 56 on page 955 shows the forwarding class and PLP that are assigned to the MPLS
EXP bits when you apply the explicit default MPLS EXP classifier. To do this, include the
default statement [edit class-of-service system-defaults classifier exp default].
Table 56: Default MPLS Classifier

Code Point Forwarding Class Loss Priority
000 best-effort low
011 expedited-forwarding high
101 assured-forwarding high

Table 56: Default MPLS Classifier (continued)

Code Point Forwarding Class Loss Priority
Documentation
• Default Behavior Aggregate Classification Overview in ACX Series on page 953
• Overview of BA Classifier Types
Default IEEE 802.1p Classifier
Table 57 on page 956 shows the forwarding class and PLP that are assigned to the
IEEE 802.1p CoS bits when you apply the explicit default IEEE 802.1p classifier. To do
this, include the default statement at the [edit class-of-service interfaces interface-name
classifiers ieee-802.1] hierarchy level:
[edit class-of-service interfaces interface-name classifiers ieee-802.1]

default;
Table 57: Default IEEE 802.1p Classifier

Code Point Forwarding Class PLP
000 best-effort low
011 expedited-forwarding high
101 assured-forwarding high
Series on page 889

Default IEEE 802.1ad Classifier
Table 58 on page 957 shows the code point, forwarding class alias, and PLP that are
assigned to the IEEE 802.1ad bits when you apply the explicit default IEEE 802.1ad
classifier. The table is very similar to the IEEE 802.1p default table, but the loss priority is
determined by the drop eligibility indicator (DEI) bit. To apply the default table, include
the default statement at the [edit class-of-service interfaces interface-name classifiers
ieee-802.1] hierarchy level:
[edit class-of-service interfaces interface-name classifiers ieee-802.1ad]

default;
Table 58: Default IEEE 802.1ad Classifier

IEEE 802.1ad Code Point Forwarding Class Alias PLP
0000 be low
0010 be1 low
0100 ef low
0110 ef1 low
1000 af11 low
1010 af12 low
1100 nc1 low
1110 nc2 low
0001 be-dei high
0011 be1-dei high
0101 ef-dei high
0111 ef1-dei high
1001 af11-dei high
1011 af12-dei high
1101 nc1-dei high
1111 nc2-dei high

Documentation
Routers on page 865
• Default IEEE 802.1p Classifier on page 956
Default DSCP and DSCP IPv6 Classifier
Table 59 on page 958 shows the forwarding class and packet loss priority (PLP) that are
assigned to each well-known DSCP when you apply the explicit default DSCP or DSCP
IPv6 classifier. To do this, include the default statement at the [edit class-of-service
interfaces interface-name classifiers (dscp | dscp-ipv6)] hierarchy level:
[edit class-of-service interfaces interface-name classifiers (dscp | dscp-ipv6)]

default;
Table 59: Default DSCP Classifier

DSCP and DSCP IPv6 Forwarding Class PLP
ef expedited-forwarding low
af11 assured-forwarding low
af12 assured-forwarding high
af13 assured-forwarding high
af21 best-effort low
be best-effort low
cs1 best-effort low

Table 59: Default DSCP Classifier (continued)

DSCP and DSCP IPv6 Forwarding Class PLP
cs2 best-effort low
cs3 best-effort low
cs4 best-effort low
cs5 best-effort low
nc1/cs6 network-control low
nc2/cs7 network-control low
other best-effort low
Related • Applying DSCP and DSCP IPv6 Classifiers on page 959

Documentation
Applying DSCP and DSCP IPv6 Classifiers
You can apply classifiers on a physical interface by including the classifiers statement
at the [edit class-of-service interfaces interface-name] hierarchy level and specifying the
dscpand dscp-ipv6 classifier types:
[edit class-of-service interfaces interface-name]

classifiers dscp (classifier-name | default);
classifiers dscp-ipv6 (classifier-name | default) );
For ACX Series routers, you cannot apply separate DSCP and DSCP IPv6 classifiers for
IPv4 and IPv6 packets on a physical interface. Instead, classifier assignment works as
follows:
• If you assign a DSCP classifier only, IPv4 and IPv6 packets are classified using the DSCP
classifier.
• If you assign a DSCP IPv6 classifier only, IPv4 and IPv6 packets are classified using the
DSCP IPv6 classifier.
• If you assign an IP precedence classifier only, IPv4 and IPv6 packets are classified using
the IP precedence classifier. In this case, the lower three bits of the DSCP field are
ignored because IPv4 precedence mapping requires the upper three bits only.
• You can assign either DSCP, DSCP IPv6, or IPv4 precedence classifier types on a physical
interface.
• You can configure either DSCP, DSCP IPv6, or IPv4 precedence rewrite rules on a
physical interface. The rewrite rule applies to both IPv4 and IPv6 packets.
• If you assign either the DSCP or the IP precedence classifier in conjunction with the
DSCP IPv6 classifier, the commit fails.

Related • Default DSCP and DSCP IPv6 Classifier on page 958

Documentation

PART 8
Configuring Network Management and

Administration on ACX Series Routers
• Understanding Network Management on page 963
• Configuring IP and MAC Address Validation on page 995
• Configuring Network Address Translation (NAT) and Stateful Firewall
Services on page 999
• Configuring Firewall Filters on page 1043
• Configuring IPsec on page 1087
• Configuring Operations, Administration, and Management (OAM) on page 1111
• Configuring Virtual Private LAN Service on page 1235


CHAPTER 29
Understanding Network Management
• Real-Time Performance Monitoring on ACX Series Routers on page 963

• TWAMP on ACX Series on page 964
• Storm Control on ACX Series Routers Overview on page 966
• Standard SNMP MIBs Supported by Junos OS on page 967
• Enterprise-Specific MIBs and Supported Devices on page 984
Real-Time Performance Monitoring on ACX Series Routers
Real-time performance monitoring (RPM) allows the user to perform service-level

monitoring. When RPM is configured on a router, the router calculates network
performance based on packet response time, jitter, and packet loss. RPM is supported
on all ACX Series routers. You can configure these values to be gathered by HTTP, Internet
Control Message Protocol (ICMP), TCP, and UDP requests. The router gathers RPM
statistics by sending out probes to a specified probe target, identified by an IP address.
When the target receives a probe, it generates responses that are received by the router.
You set the probe options in the test test-name statement at the [edit services rpm probe
owner] hierarchy level. You use the show services rpm probe-results command to view
the results of the most recent RPM probes.
NOTE: Packet Forwarding Engine timestamping is available only for ICMP

probes and for UDP probes with the destination port set to UDP_ECHO port
(7).
On ACX Series routers, the following statements are supported at the [edit services rpm]
hierarchy level:
probe owner {
test test-name {
data-fill data;
data-size size;
destination-interface interface-name;
destination-port port;
dscp-code-point dscp-bits;
hardware-timestamp;
history-size size;
moving-average-size number;

one-way-hardware-timestamp;
probe-count count;
probe-interval seconds;
probe-type type;
routing-instance instance-name;
source-address address;
target (url url | address address);
test-interval interval;
thresholds thresholds;
traps traps;
}
}
NOTE: The ACX Series routers do not support the configuration of RPM
probes to a routing instance along with the configuration of the
hardware-timestamp statement.
NOTE: ACX5000 line of routers do not support hardware-timestamp feature

for RPM.
Related • Configuring Real-Time Performance Monitoring

Documentation
• Examples: Configuring Real-Time Performance Monitoring
• show services rpm probe-results
TWAMP on ACX Series
The Two-Way Active Measurement Protocol (TWAMP) defines a standard for measuring
IP performance between two devices in a network. You can configure TWAMP on ACX
Series routers. ACX Series routers support only the reflector side of TWAMP.
For more information about TWAMP, see RFC 5357, A Two-Way Active Measurement
Protocol (TWAMP).
To configure TWAMP properties, include the twamp statement at the [edit services rpm]
hierarchy level:
[edit services rpm]

twamp {
server {
authentication-mode mode;
client-list list-name {
[ address address ];
authentication none];
}
max-connection-duration hours;
maximum-connections count;
maximum-connections-per-client count;

Chapter 29: Understanding Network Management
maximum-sessions count;
maximum-sessions-per-connection count;
port udp-port-number;
server-inactivity-timeout minutes;
}
}
You can specify a number of TWAMP server properties, some of which are optional, by
including the server statement at the [edit services rpm twamp] hierarchy level:
[edit services rpm twamp]

server {
client-list list-name {
[ address address ];
}
authentication-mode mode;
maximum-connections count;
maximum-connections-per-client count;
maximum-sessions count;
maximum-sessions-per-connection count;
port udp-port-number;
}
• To specify the list of allowed control client hosts that can connect to this server, include
the client-list statement at the [edit services rpm twamp server] hierarchy level. Each
value you include must be a Classless Interdomain Routing (CIDR) address (IP address
plus mask) that represents a network of allowed hosts. You can include multiple client
lists, each of which can contain a maximum of 64 entries. You must configure at least
one client address to enable TWAMP.
• ACX Series routers do not support authentication and encryption modes. The value
for authentication-mode statement at the [edit services rpm twamp server] hierarchy
level must be set to none.
• To specify the maximum number of concurrent connections the server can have to
client hosts, include the maximum-connections statement at the [edit services rpm
twamp server] hierarchy level. The allowed range of values is 1 through 2048 and the
default value is 64. You can also limit the number of connections the server can make
to a particular client host by including the maximum-connections-per-client statement.
ACX Series routers supports a maximum of 15 concurrent connections.
• To specify the maximum number of sessions the server can have running at one time,
include the maximum-sessions statement at the [edit services rpm twamp server]
hierarchy level. The allowed range of values is 1 through 2048 and the default value is
64. You can also limit the number of sessions the server can have on a single connection
by including the maximum-sessions-per-connection statement. ACX Series routers
supports a maximum of 15 sessions.
• To specify the TWAMP server listening port, include the port statement at the [edit
services rpm twamp server] hierarchy level. The range is 1 through 65,535. If a port range
is not specified, then the default port 862 is used.
• TWAMP control connection traffic always arrives on ACX routers with the listening
port set as 862. Because this port number for traffic probes can be modified, probes
that arrive with a different port number are not recognized and processed by ACX

routers correctly. As a result, TWAMP traffic and host-bound packets are dropped in
such a scenario.
Storm Control on ACX Series Routers Overview
A traffic storm is generated when messages are broadcast on a network and each
message prompts a receiving node to respond by broadcasting its own messages on the
network. This, in turn, prompts further responses, creating a snowball effect. The LAN is
suddenly flooded with packets, creating unnecessary traffic that leads to poor network
performance or even a complete loss of network service. Storm control enables the router
to monitor traffic levels and to drop broadcast, unknown unicast, and multicast (BUM)
packets if they exceed the configured limit.
Storm control is applied on the following traffic types:
• Layer 2 broadcast packets
• Layer 2 multicast packets
• Layer 2 unregistered multicast packets
• Layer 2 registered multicast packets
• Layer 2 unknown unicast packets
Storm control functions slightly differently on ACX Series routers compared to other
Juniper Networks routers. On ACX Series routers, storm control is only applicable at the
IFD level. No event will be logged when a traffic storm hits an ACX Series router. Also
interfaces will not be bound to any default profile. The default action is to drop the packets
exceeding the configured bandwidth.
Storm control configuration is done in two steps. The first step is to create a storm control
profile. Use the following configuration to create your storm control profile on an ACX
Series router:
storm-control-profiles {
foo {
all {
bandwidth [percentage | level] <x>;
[no-unknown-unicast | no-broadcast | no-multicast | no-registered-multicast |
no-unregistered-multicast]
}
}
}
The second step in configuring storm control is to bind the profile to an IFD. The following
configuration shows how to bind your storm control profile:
[edit interfaces]
ge-0/0/0 {
ether-options {
ethernet-switch-profile {
storm-control foo;
}
}

Related • Controlling Network Access Using Traffic Policing Overview on page 908
Documentation
Standard SNMP MIBs Supported by Junos OS
Junos OS supports the Standard MIBs listed in Table 60 on page 967.
NOTE: For details on SNMP MIB support on EX4600 switches, QFX Series
switches, and QFabric systems, see SNMP MIBs Support.
Table 60: Standard MIBs supported by Junos OS

Standard MIB Exceptions Platforms
IEEE 802.1ab section 12.1, Link Layer EX Series implementation of LLDP MIB EX Series and MX Series
Discovery Protocol (LLDP) MIB supports both IPv4 and IPv6
configuration.
IEEE, 802.3ad, Aggregation of Multiple Supported tables and objects: EX Series, M Series, MX Series, PTX
Link Segments Series, SRX Series, T Series, and vSRX
• dot3adAggPortTable,
dot3adAggPortListTable,
dot3adAggTable, and
dot3adAggPortStatsTable
NOTE: EX Series switches do not

support the dot3adAggPortTable and
dot3adAggPortStatsTable.
• dot3adAggPortDebugTable (only
dot3adAggPortDebugRxState,
dot3adAggPortDebugMuxState,
dot3adAggPortDebugActorSyncTransitionCount,
dot3adAggPortDebugPartnerSyncTransitionCount,
dot3adAggPortDebugActorChangeCount,
and
dot3adAggPortDebugPartnerChangeCount)
NOTE: EX Series switches do not

support the
dot3adAggPortDebugTable.
• dot3adTablesLastChanged

Table 60: Standard MIBs supported by Junos OS (continued)

IEEE, 802.1ag, Connectivity Fault Supported tables and objects: EX Series, MX Series, and QFX Series
Management
• dot1agCfmMdTableNextIndex
• dot1agCfmMdTable (except
dot1agCfmMdMhfldPermission)
• dot1agCfmMaNetTable
• dot1agCfmMaMepListTable
• dot1agCfmDefaultMdDefLevel
• dot1agCfmDefaultMdDefMhfCreation
• dot1agCfmMepTable (except
dot1agCfmMepLbrBadMsdu,
dot1agCfmMepTransmitLbmVlanPriority,
dot1agCfmMepTransmitLbmVlanDropEnable,
dot1agCfmMepTransmitLtmFlags,
dot1agCfmMepPbbTeCanReportPbbTePresence,
dot1agCfmMepPbbTeTrafficMismatchDefect,
dot1agCfmMepPbbTransmitLbmLtmReverseVid,
dot1agCfmMepPbbTeMismatchAlarm,
dot1agCfmMepPbbTeLocalMismatchDefect,
and
dot1agCfmMepPbbTeMismatchSinceReset)
• dot1agCfmLtrTable (except
dot1agCfmLtrChassisIdSubtype,
dot1agCfmLtrChassisId,
dot1agCfmLtrManAddressDomain,
dot1agCfmLtrManAddress,
dot1agCfmLtrIngressPortIdSubtype,
dot1agCfmLtrIngressPortId,
dot1agCfmLtrEgressPortIdSubtype,
dot1agCfmLtrEgressPortId, and
dot1agCfmLtrOrganizationSpecificTlv)
• dot1agCfmMepDbTable (except
dot1agCfmMebDbChassisIdSubtype,
dot1agCfmMebDbChassisId,
dot1agCfmMebDbManAddressDomain,
and dot1agCfmMebDbManAddress)
IEEE, 802.1ap, Management Information Supported tables and objects: MX Series

Base (MIB) definitions for VLAN Bridges
• ieee8021CfmStackTable
• ieee8021CfmVlanTable
• ieee8021CfmDefaultMdTable (except
ieee8021CfmDefaultMdIdPermission)
• ieee8021CfmMaCompTable (except
ieee8021CfmMaCompIdPermission)
RFC 1155, Structure and Identification of No exceptions All platforms

Management Information for
TCP/IP-based Internets
RFC 1157, A Simple Network Management No exceptions All platforms

Protocol (SNMP)


RFC 1195, Use of OSI IS-IS for Routing in Supported tables and objects: All platforms
TCP/IP and Dual Environments
• isisSystem
• isisMANAreaAddr
• isisAreaAddr
• isisSysProtSupp
• isisSummAddr
• isisCirc
• isisCircLevel
• isisPacketCount
• isisISAdj
• isisISAdjAreaAddr
• isisAdjIPAddr
• isisISAdjProtSupp
• isisRa
• isisIPRA
RFC 1212, Concise MIB Definitions No exceptions ACX Series, EX Series, M Series, MX
Series, PTX Series, SRX Series, and T
Series
RFC 1213, Management Information Base Junos OS supports the following areas: ACX Series, EX Series, M Series, MX
for Network Management of Series, PTX Series, SRX Series, and T
TCP/IP-Based Internets: MIB-II • MIB II and its SNMP version 2 Series
derivatives, including:
• Statistics counters
• IP, except for ipRouteTable, which
has been replaced by
ipCidrRouteTable (RFC 2096, IP
Forwarding Table MIB)
• SNMP management
• Interface management
• SNMPv1 Get, GetNext requests, and

version 2 GetBulk request
• Junos OS-specific secured access list
• Master configuration keywords
• Reconfigurations upon SIGHUP
RFC 1215, A Convention for Defining Traps Junos OS supports only MIB II SNMP ACX Series, EX Series, M Series, MX
for use with the SNMP version 1 traps and version 2 notifications. Series, PTX Series, SRX Series, and T
Series
RFC 1406, Definitions of Managed Objects Junos OS supports T1 MIB. ACX Series, M Series, SRX Series, and T
for the DS1 and E1 Interface Types Series
RFC 1407, Definitions of Managed Objects Junos OS supports T3 MIB. M Series and T Series
for the DS3/E3 Interface Type


RFC 1471, Definitions of Managed Objects Supported tables and objects: M Series, MX Series, and PTX Series
for the Link Control Protocol of the
Point-to-Point Protocol • pppLcp 1 object
• pppLinkStatustable table
• pppLinkConfigTable table
RFC 1657, Definitions of Managed Objects No exceptions ACX Series, EX Series, M Series, MX
for the Fourth Version of the Border Series, and T Series
Gateway Protocol (BGP-4) using SMIv2
RFC 1695, Definitions of Managed Objects No exceptions ACX Series, M Series, PTX Series, and T
for ATM Management Version 8.0 Using Series
SMIv2
RFC 1850, OSPF Version 2 Management Unsupported tables, objects, and traps: ACX Series, EX Series, M Series, MX
Information Base Series, PTX Series, SRX Series, and T
• ospfOriginateNewLsas object Series
• ospfRxNewLsas object
• The host table
• ospfOriginateLSA trap
ospfLsdbOverflow trap
ospfLsdbApproachingOverflow trap
RFC 1901, Introduction to No exceptions All platforms

Community-based SNMPv2
RFC 2011, SNMPv2 Management No exceptions ACX Series, EX Series, M Series, MX

Information Base for the Internet Protocol Series, PTX Series, and T Series
Using SMIv2

Information Base for the Transmission Series, PTX Series, SRX Series, and T
Control Protocol Using SMIv2 Series

Information Base for the User Datagram Series, PTX Series, SRX Series, and T
Protocol Using SMIv2 Series


RFC 2024, Definitions of Managed Objects Unsupported tables, objects, and traps M Series, MX Series, and T Series
for Data Link Switching Using SMIv2 with read-only access:
• dlswInterface object group

dlswSdlc object group
dlswDirLocateMacTable table
dlswDirNBTabletable
dlswDirLocateNBTable table
dlswCircuitDiscReasonLocal tabular
object
dlswCircuitDiscReasonRemote tabular
object
dlswDirMacCacheNextIndex scalar
object
dlswDirNBCacheNextIndex scalar
object
RFC 2096, IP Forwarding Table MIB The ipCidrRouteTable has been extended ACX Series, EX Series, M Series, MX
to include the tunnel name when the next Series, PTX Series, SRX Series, and T
NOTE: RFC 2096 has been replaced by hop is through an RSVP-signaled LSP. Series
RFC 4292. However, Junos OS currently
supports both RFC 2096 and RFC 4292.
RFC 2115, Management Information Base Unsupported table and objects: M Series, MX Series, SRX Series, and T
for Frame Relay DTEs Using SMIv2 Series
• frCircuitTable
• frErrTable
RFC 2233, The Interfaces Group MIB Using No exceptions ACX Series, EX Series, M Series, MX
SMIv2 Series, PTX Series, SRX Series, and T
Series
NOTE: RFC 2233 has been replaced by
RFC 2863, IF MIB. However, Junos OS
supports both RFC 2233 and RFC 2863.
RFC 2287, Definitions of System-Level Supported tables and objects: ACX Series, EX Series, M Series, MX
Managed Objects for Applications Series, PTX Series, SRX Series, and T
• sysApplInstallPkgTable Series
• sysApplInstallElmtTable
• sysApplElmtRunTable
• sysApplMapTable
RFC 2465, Management Information Base Junos OS does not support IPv6 interface ACX Series, M Series, MX Series, PTX
for IP Version 6: Textual Conventions and statistics. Series, SRX Series, and T Series
General Group (except for IPv6 interface
statistics)


RFC 2495, Definitions of Managed Unsupported tables, objects, and traps: ACX Series, M Series, SRX Series, and T
Objects for the DS1, E1, DS2, and E2 Series
Interface Types • dsx1FarEndConfigTable
• dsx1FarEndCurrentTable
• dsx1FarEndIntervalTable
• dsx1FarEndTotalTable
• dsx1FracTable
RFC 2515, Definitions of Managed Objects Unsupported table and objects: ACX Series, M Series, and T Series
for ATM Management
• atmVpCrossConnectTable
• atmVcCrossConnectTable
• aal5VccTable
RFC 2570, Introduction to Version 3 of the No exceptions ACX Series, EX Series, M Series, MX
Internet-standard Network Management Series, PTX Series, SRX Series, and T
Framework Series
RFC 2571, An Architecture for Describing No exceptions ACX Series, EX Series, M Series, MX
SNMP Management Frameworks Series, PTX Series, SRX Series, and T
(read-only access) Series

RFC 3411. However, Junos OS supports
both RFC 2571 and RFC 3411.
RFC 2572, Message Processing and No exceptions ACX Series, EX Series, M Series, MX
Dispatching for the Simple Network Series, PTX Series, SRX Series, and T
Management Protocol (SNMP) Series
(read-only access)

RFC 2576, Coexistence between Version No exceptions ACX Series, EX Series, M Series, MX
1, Version 2, and Version 3 of the Series, PTX Series, SRX Series, and T
Internet-standard Network Management Series
Framework

RFC 2578, Structure of Management No exceptions ACX Series, EX Series, M Series, MX

Information Version 2 (SMIv2) Series, PTX Series, SRX Series, and T
Series
RFC 2579, Textual Conventions for SMIv2 No exceptions ACX Series, EX Series, M Series, MX
Series


RFC 2580, Conformance Statements for No exceptions ACX Series, EX Series, M Series, MX
SMIv2 Series, PTX Series, SRX Series, and T
Series
RFC 2662, Definitions of Managed Objects No exceptions M Series, MX Series, SRX Series, and T
for ADSL Lines Series
RFC 2665, Definitions of Managed For M Series, T Series, and MX Series, the ACX Series, EX Series, M Series, MX
Objects for the Ethernet-like Interface SNMP counters do not count the Series, PTX Series, SRX Series, and T
Types Ethernet header and frame check Series
sequence (FCS). Therefore, the Ethernet
NOTE: The list of managed objects header bytes and the FCS bytes are not
specified in RFC 2665 has been updated included in the following four tables:
by RFC 3635 by including information
useful for the management of 10-Gigabit • ifInOctets
per second Ethernet interfaces. • ifOutOctets
• ifHCInOctets
• ifHCOutOctets
However, the EX switches adhere to RFC

2665.
RFC 2787, Definitions of Managed Objects Unsupported table and objects: ACX Series, EX Series, M Series, MX
for the Virtual Router Redundancy Series, PTX Series, SRX Series, and T
Protocol • vrrpStatsPacketLengthErrors Series
NOTE: Junos OS does not support this

standard for row creation and the Set
operation.
RFC 2790, Host Resources MIB Supported tables and objects: ACX Series, EX Series, M Series, MX
• hrStorageTable Series
NOTE: The file systems /, /config, /var,

and /tmp always return the same
index number. When SNMP restarts,
the index numbers for the remaining
file systems might change.
• hrSystem group
• hrSWInstalled group
• hrProcessorTable


RFC 2819, Remote Network Monitoring Supported tables and objects: ACX Series, EX Series, M Series, MX
Management Information Base Series, PTX Series, SRX Series, and T
• etherStatsTable (for Ethernet Series
interfaces only), alarmTable,
eventTable, and logTable are
supported on all devices running Junos
OS.
• historyControlTable and
etherHistoryTable (except
etherHistoryUtilization object) are
supported only on EX Series switches.
RFC 2863, The Interfaces Group MIB No exceptions ACX Series, EX Series, M Series, MX
NOTE: RFC 2863 replaces RFC 2233. Series
However, Junos OS supports both RFC
2233 and RFC 2863.
RFC 2864, The Inverted Stack Table No exceptions M Series, MX Series, PTX Series, SRX
Extension to the Interfaces Group MIB Series, and T Series
RFC 2922, The Physical Topology Supported objects: EX Series and SRX Series
(PTOPO) MIB
• ptopoConnDiscAlgorithm
• ptopoConnAgentNetAddrType
• ptopoConnAgentNetAddr
• ptopoConnMultiMacSASeen
• ptopoConnMultiNetSASeen
• ptopoConnIsStatic
• ptopoConnLastVerifyTime
• ptopoConnRowStatus
RFC 2925, Definitions of Managed Objects Supported tables and objects: ACX Series, EX Series, M Series, MX
for Remote Ping, Traceroute, and Lookup Series, PTX Series, SRX Series, and T
Operations • pingCtlTable Series
• pingResultsTable
• pingProbeHistoryTable
• pingMaxConcurrentRequests
• traceRouteCtlTable
• traceRouteResultsTable
• traceRouteProbeHistoryTable
• traceRouteHopsTable
RFC 2932, IPv4 Multicast Routing MIB No exceptions ACX Series, EX Series, M Series, MX
Series


RFC 2934, Protocol Independent Support for the pimNeighborLoss trap ACX Series, EX Series, M Series, MX
Multicast MIB for IPv4 was added in Release 11.4. Series, PTX Series, SRX Series, and T
Series
NOTE: In Junos OS, RFC 2934 is
implemented based on a draft version,
pimmib.mib, of the now standard RFC.
RFC 2981, Event MIB No exceptions ACX Series, M Series, MX Series, PTX
Series, and T Series
RFC 3014, Notification Log MIB No exceptions ACX Series, M Series, MX Series, PTX
Series, and T Series
RFC 3019, IP Version 6 Management No exceptions M Series, MX Series, PTX Series, SRX
Information Base for The Multicast Series, and T Series
Listener Discovery Protocol
RFC 3410, Introduction and Applicability No exceptions ACX Series, EX Series, M Series, MX
Statements for Internet-Standard Series, PTX Series, SRX Series, and T
Management Framework Series
RFC 3411, An Architecture for Describing No exceptions ACX Series, EX Series, M Series, MX
Simple Network Management Protocol Series, PTX Series, SRX Series, and T
(SNMP) Management Frameworks Series
NOTE: RFC 3411 replaces RFC 2571.

3411 and RFC 2571.
RFC 3412, Message Processing and No exceptions ACX Series, EX Series, M Series, MX
Dispatching for the Simple Network Series, PTX Series, SRX Series, and T
NOTE: RFC 3412 replaces RFC 2572.

3412 and RFC 2572.
RFC 3413, Simple Network Management Unsupported tables and objects: ACX Series, EX Series, M Series, MX
Protocol (SNMP) Applications Series, PTX Series, SRX Series, and T
• Proxy MIB Series
RFC 3414, User-based Security Model No exceptions ACX Series, EX Series, M Series, MX
(USM) for version 3 of the Simple Network Series, PTX Series, SRX Series, and T
Management Protocol (SNMPv3) Series
RFC 3415, View-based Access Control No exceptions ACX Series, EX Series, M Series, MX
Model (VACM) for the Simple Network Series, PTX Series, SRX Series, and T


RFC 3416, Version 2 of the Protocol No exceptions ACX Series, EX Series, M Series, MX
Operations for the Simple Network Series, PTX Series, SRX Series, and T
NOTE: RFC 3416 replaces RFC 1905,

which was supported in earlier versions
of Junos OS.
RFC 3417, Transport Mappings for the No exceptions ACX Series, EX Series, M Series, MX
Simple Network Management Protocol Series, PTX Series, SRX Series, and T
(SNMP) Series
RFC 3418, Management Information Base No exceptions ACX Series, EX Series, M Series, MX
(MIB) for the Simple Network Series, PTX Series, SRX Series, and T
NOTE: RFC 3418 replaces RFC 1907,

which was supported in earlier versions
of Junos OS.
RFC 3498, Definitions of Managed No exceptions M Series and T Series

Objects for Synchronous Optical Network
(SONET) Linear Automatic Protection
Switching (APS) Architectures
(implemented under the Juniper
Networks enterprise branch
[jnxExperiment])
RFC 3584, Coexistence between Version No exceptions ACX Series, EX Series, M Series, MX
1, Version 2, and Version 3 of the Series, PTX Series, SRX Series, and T
Internet-standard Network Management Series
Framework
RFC 3591 Managed Objects for the Supported tables and objects: M Series, MX Series, PTX Series, and T
Optical Interface Type Series
• optIfOTMnTable (except
optIfOTMnOpticalReach,
optIfOTMnInterfaceType, and
optIfOTMnOrder)
• optIfOChConfigTable (except
optIfOChDirectionality and
optIfOChCurrentStatus)
• optIfOTUkConfigTable (except
optIfOTUkTraceIdentifierAccepted,
optIfOTUkTIMDetMode,
optIfOTUkTIMActEnabled,
optIfOTUkTraceIdentifierTransmitted,
optIfOTUkDEGThr, optIfOTUkDEGM,
optIfOTUkSinkAdaptActive, and
optIfOTUkSourceAdaptActive)
• optIfODUkConfigTable (except
optIfODUkPositionSeqCurrentSize and
optIfODUkTtpPresent)


RFC 3592, Definitions of Managed Objects No exceptions M Series, MX Series, and T Series
for the Synchronous Optical
Network/Synchronous Digital Hierarchy
(SONET/SDH) Interface Type
RFC 3621, Power Ethernet MIB No exceptions EX Series
RFC 3635, Definitions of Managed Objects Unsupported tables and objects: MX Series
for the Ethernet-like Interface Types
• dot3StatsRateControlAbility
• dot3StatsRateControlStatus in
dot3StatsEntry table
NOTE: The values of the following

objects in dot3HCStatsEntry table will be
always zero for both 32-bit counters and
64-bit counters:
• dot3HCStatsSymbolErrors
• dotHCStatsInternalMacTransmitErrors
RFC 3637, Definitions of Managed Objects Unsupported tables and objects: M Series, MX Series, PTX Series, and T
for the Ethernet WAN Interface Sublayer Series
• etherWisDeviceTable,
• etherWisSectionCurrentTable
• etherWisFarEndPathCurrentTable
RFC 3811, Definitions of Textual No exceptions ACX Series, M Series, MX Series, PTX
Conventions (TCs) for Multiprotocol Label Series, SRX Series, and T Series
Switching (MPLS) Management


RFC 3812, Multiprotocol Label Switching MPLS tunnels as interfaces are not ACX Series, M Series, MX Series, PTX
(MPLS) Traffic Engineering (TE) supported. Series, and T Series
Management Information Base (MIB)
(read-only access) mplsTunnelCHopTable is supported on
ingress routers only.
NOTE: The branch used by the

proprietary LDP MIB (ldpmib.mib)
conflicts with RFC 3812. ldpmib.mib has
been deprecated and replaced by
jnx-mpls-ldp.mib.
Unsupported tables and objects:
• mplsTunnelResourceMeanRate in
TunnelResource table
• mplsTunnelResourceMaxBurstSize in
• mplsTunnelResourceMeanBurstSize in
• mplsTunnelResourceExBurstSize in
• mplsTunnelResourceWeight in
• mplsTunnelPerfTable
• mplsTunnelCRLDPResTable
RFC 3813, Multiprotocol Label Switching Unsupported tables and objects ACX Series, M Series, MX Series, PTX
(MPLS) Label Switching Router (LSR) (read-only access): Series, SRX Series, and T Series
• mplsInterfacePerfTable
• mplsInSegmentPerfTable
• mplsOutSegmentPerfTable
• mplsInSegmentMapTable
• mplsXCUp
• mplsXCDown
RFC 3826, The Advanced Encryption No exceptions ACX Series, EX Series, M Series, MX
Standard (AES) Cipher Algorithm in the Series, PTX Series, SRX Series, and T
SNMP User-based Security Model Series
RFC 3877, Alarm Management • Junos OS does not support the MX Series
Information Base alarmActiveStatsTable.
• Traps that do not conform to the
alarm model are not supported.
However, these traps can be redefined
to conform to the alarm model.


RFC 3896, Definitions of Managed Unsupported tables and objects: M Series and T Series
Objects for the DS3/E3 Interface Type
• dsx3FarEndConfigTable
• dsx3FarEndCurrentTable
• dsx3FarEndIntervalTable
• dsx3FarEndTotalTable
• dsx3FracTable
RFC 4087, IP Tunnel MIB Describes MIB objects in the following M Series, MX Series, and T Series
tables for managing tunnels of any type
over IPv4 and IPv6 networks:
• tunnelIfTable—Provides information
about the tunnels known to a router.
• tunnelInetConfigTable—Assists
dynamic creation of tunnels and
provides mapping from end-point
addresses to the current interface
index value.
NOTE: Junos OS supports MAX-ACCESS

of read-only for all the MIB objects in
tunnelIfTable and tunnelInetConfigTable
tables.
RFC 4133, Entity MIB Unsupported tables and objects: Only MX240, MX480, and MX960
routers, and EX2200 and EX3300
• entityLogicalGroup table switches
• entPhysicalMfgDate and
entPhysicalUris objects in
entityPhysical2Group table
• entLPMappingTable and
entPhysicalContainsTable in
entityMappingGroup table
• entityNotoficationsGroup table
RFC 4188, Definitions of Managed Objects • Supports 802.1D STP(1998) MX Series, EX Series, and M Series and
for Bridges • Supported subtrees and objects: T Series
• dot1dStp subtree is supported on

MX Series 3D Universal Edge
Routers.
• dot1dTpFdbAddress,
dot1dTpFdbPort, and
dot1dTpFdbStatus objects from the
dot1dTpFdbTable of the dot1dTp
subtree are supported on EX Series
Ethernet Switches.
• dot1dTpLearnedEntryDiscards and
dot1dTpAgingTime objects are
supported on M Series and T Series
routers.


RFC 4268, Entity State MIB No exceptions Only MX240, MX480, and MX960
routers, and EX2200 and EX3300
switches
RFC 4273, Definitions of Managed Objects Supported tables and objects: ACX Series, EX Series, M Series, MX
for BGP-4 Series, SRX Series, and T Series
• jnxBgpM2PrefixInPrefixesAccepted
• jnxBgpM2PrefixInPrefixesRejected
RFC 4292, IP Forwarding MIB Supported tables and objects: ACX Series, EX Series, M Series, MX
Series, PTX Series, and T Series
• inetCidrRouteTable
• inetCidrRouteNumber
• inetCidrRouteDiscards
NOTE: Junos OS currently supports

these MIB objects that will be deprecated
in future releases: ipCidrRouteTable,
ipCidrRouteNumber, and
ipCidrRouteDiscards.
RFC 4293, Management Information Base Supports only the mandatory groups. MX Series and EX Series
for the Internet Protocol (IP)
RFC 4318, Definitions of Managed Objects Supports 802.1w and 802.1t extensions EX Series, M Series, MX Series, and T
for Bridges with Rapid Spanning Tree for RSTP. Series
Protocol
RFC 4363b, Q-Bridge VLAN MIB No exceptions MX Series and EX Series
RFC 4382, MPLS/BGP Layer 3 Virtual Supported tables and objects: EX Series, M Series, MX Series, PTX
Private Network (VPN) MIB Series, and T Series
• mplsL3VpnActiveVrfs
• mplsL3VpnConfiguredVrfs
• mplsL3VpnConnectedInterfaces
• mplsL3VpnVrfConfMidRteThresh
• mplsL3VpnVrfConfHighRteThresh
• mplsL3VpnIfConfRowStatus
• mplsL3VpnIllLblRcvThrsh
• mplsL3VpnNotificationEnable
• mplsL3VpnVrfConfMaxPossRts
• mplsL3VpnVrfConfRteMxThrshTime
• mplsL3VpnVrfOperStatus
• mplsL3VpnVrfPerfCurrNumRoutes
• mplsL3VpnVrfPerfTable
• mplsL3VpnVrfRteTable
• mplsVpnVrfRTTable
• mplsL3VpnVrfTable
• mplsL3VpnIfConfTable


RFC 4444, IS-IS MIB No exceptions ACX Series, EX Series, M Series, MX

Series
RFC 4668, RADIUS Accounting Client No exceptions MX Series

Management Information Base (MIB) for
IPv6 (read-only access)
RFC 4670, RADIUS Accounting Client No exceptions MX Series

(read-only access)
RFC 4801, Definitions of Textual No exceptions M Series, MX Series, and T Series

Conventions for Generalized Multiprotocol
Label Switching (GMPLS) Management
Information Base (MIB) (read-only
access)
RFC 4802, Generalized Multiprotocol Unsupported tables and objects: M Series, MX Series, and T Series
Label Switching (GMPLS) Traffic
Engineering (TE) Management • gmplsTunnelReversePerfTable
Information Base (MIB) (read-only • gmplsTeScalars
access)
• gmplsTunnelTable
• gmplsTunnelARHopTable
• gmplsTunnelCHopTable
• gmplsTunnelErrorTable
RFC 4803, Generalized Multiprotocol Unsupported tables and objects: M Series, MX Series, and T Series
Label Switching (GMPLS) Label Switching
Router (LSR) Management Information • gmplsLabelTable
Base (MIB) (read-only access) • gmplsOutsegmentTable
NOTE: The tables in GMPLS TE (RFC

4802) and LSR (RFC 4803) MIBs are
extensions of the corresponding tables
from the MPLS TE (RFC 3812) and LSR
(RFC 3813) MIBs and use the same index
as the MPLS MIB tables.
RFC 5132, IP Multicast MIB Unsupported table: All platforms
NOTE: This RFC obsoletes RFC2932. • ipMcastZoneTable


RFC 5643, Management Information Base Unsupported tables and objects: M Series, MX Series, PTX Series, SRX
for OSPFv3 (read-only access) Series, and T Series
• ospfv3HostTable
• ospfv3CfgNbrTable
• ospfv3ExitOverflowInterval
• ospfv3ReferenceBandwidth
• ospfv3RestartSupport
• ospfv3RestartInterval
• ospfv3RestartStrictLsaChecking
• ospfv3RestartStatus
• ospfv3RestartAge
• ospfv3RestartExitReason
• ospfv3NotificationEnable
• ospfv3StubRouterSupport
• ospfv3StubRouterAdvertisement
• ospfv3DiscontinuityTime
• ospfv3RestartTime
• ospfv3AreaNssaTranslatorRole
• ospfv3AreaNssaTranslatorState
• ospfv3AreaNssaTranslatorStabInterval
• ospfv3AreaNssaTranslatorEvents
• ospfv3AreaTEEnabled
• ospfv3IfMetricValue
• ospfv3IfDemandNbrProbe
RFC 6527, Definitions of Managed Objects • Row creation ACX Series

for the Virtual Router Redundancy • The Set operation
Protocol Version 3 (VRRPv3)
• Unsupported tables and objects:
• vrrpv3StatisticsRowDiscontinuityTime
• vrrpv3StatisticsPacketLengthErrors
ESO Consortium MIB, which can be No exceptions ACX Series, EX Series, M Series, MX
found at http://www.snmp.com/eso/ Series, PTX Series, SRX Series, and T
Series
NOTE: The ESO Consortium MIB has
been replaced by RFC 3826.
Internet Assigned Numbers Authority, No exceptions ACX Series, EX Series, M Series, MX

IANAiftype Textual Convention MIB Series, PTX Series, SRX Series, and T
Series
Internet draft As defined under the Juniper Networks M Series, MX Series, and T Series
draft-ietf-atommib-sonetaps-mib-10.txt, enterprise branch [jnxExperiment] only
Definitions of Managed Objects for
SONET Linear APS Architectures


Internet draft draft-ieft-bfd-mib-02.txt, (Represented by mib-jnx-bfd-exp.txt and ACX Series, EX Series, M Series, MX
Bidirectional Forwarding Detection implemented under the Juniper Networks Series, SRX Series, and T Series
Management Information Base enterprise branch [jnxExperiment]. Read
only. Includes bfdSessUp and
bfdSessDown traps. Does not support
bfdSessPerfTable and
bfdSessMapTable.)
Internet draft No exceptions EX Series, M Series, MX Series, PTX

draft-ietf-idmr-igmp-mib-13.txt, Internet Series, SRX Series, and T Series
Group Management Protocol (IGMP) MIB
Internet draft No exceptions ACX Series, EX Series, M Series, MX

draft-ietf-idmr-pim-mib-09.txt, Protocol Series, PTX Series, SRX Series , and T
Independent Multicast (PIM) MIB Series
Internet draft Unsupported tables and objects: ACX Series, EX Series, M Series, MX
draft-ietf-isis-wg-mib-07.txt, Series, PTX Series, SRX Series, and T
Management Information Base for IS-IS • isisISAdjTable Series
• isisISAdjAreaAddrTable
NOTE: Replaced with RFC 4444, IS-IS
• isisISAdjIPAddrTable
MIB in Junos OS Release 11.3 and later.
• isisISAdjProtSuppTable)
Internet draft (Implemented under the Juniper M Series, MX Series, and T Series
draft-ietf-l3vpn-mvpn-mib-03.txt, Networks enterprise branch
MPLS/BGP Layer 3 VPN Multicast [jnxExperiment]. OID for
Management Information Base jnxMvpnExperiment is .1.3.6.1.4.1.2636.5.12.
Read only. Includes jnxMvpnNotifications
traps.)
Internet draft Unsupported tables and objects: M Series, MX Series, PTX Series, and T
draft-ietf-mpls-mldp-mib-02.txt, Series
Definitions of Managed Objects for the • mplsMldpInterfaceStatsTable
LDP Point-to-Multipoint and
Also, the following fields of the
Multipoint-to-Multipoint Label Switched
mplsMldpFecUpstreamSessTable are
Paths
not implemented because these
statistics are not currently supported in
LDP or PFE:
• mplsMldpFecUpstreamSessPackets
• mplsMldpFecUpstreamSessBytes
• mplsMldpFecUpstreamSessDiscontinuityTime
Internet draft Unsupported table: ACX Series, M Series, MX Series, PTX

draft-ietf-mpls-p2mp-te-mib-09.txt, Series, and T Series
P2MP MPLS-TE MIB (read-only access) • mplsTeP2mpTunnelBranchPerfTable
Internet draft Support for ospfv3NbrTable only. M Series, MX Series, PTX Series, SRX
draft-ietf-ospf-ospfv3-mib-11.txt, Series, and T Series
Management Information Base for
OSPFv3


Internet draft Supported tables and objects: M Series, MX Series, PTX Series, and T
draft-ietf-ppvpn-mpls-vpn-mib-04.txt, Series
MPLS/BGP Virtual Private Network • mplsVpnScalars
Management Information Base Using • mplsVpnVrfTable
SMIv2
• mplsVpnPerTable
• mplsVpnVrfRouteTargetTable
Internet draft No exceptions ACX Series, EX Series, M Series, MX

draft-reeder-snmpv3-usm-3desede-00.txt, Series, PTX Series, SRX Series, and T
Extension to the User-Based Security Series
Model (USM) to Support Triple-DES EDE
in ‘Outside’ CBC Mode
For information about standard SNMP MIB objects, see the SNMP MIB Explorer.
Related • Enterprise-Specific SNMP MIBs Supported by Junos OS

Documentation
• Network Management Administration Guide
• Standard SNMP Traps Supported by Junos OS
Enterprise-Specific MIBs and Supported Devices
NOTE: Starting with Junos OS Release 16.1, this topic has been deprecated;
refer instead to Enterprise-Specific SNMP MIBs Supported by Junos OS.
Table 61 on page 985 lists the enterprise-specific MIBs that are supported on various
devices running Junos OS.
NOTE: In this table, a value of 1 in any of the platform columns (ACX, M, MX,
T, EX, PTX, and SRX) denotes that the corresponding MIB is supported on
that particular platform. A value of 0 denotes that the MIB is not supported
on the platform.

Table 61: Enterprise-Specific MIBs and Supported Devices

Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Enterprise-Specific MIB ACX M T MX EX PTX SRX340 SRX550M SRX5800
AAA Objects MIB 0 1 1 0 0 0 0 1 1
http://www.juniper.net/techpubs/en_US/junos15.1/
topics/reference/mibs/mib-jnx-user-aaa.txt
Access Authentication Objects MIB 0 0 0 0 1 0 1 1 1
topics/reference/mibs/mib-jnx-js-auth.txt
Alarm MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-chassis-alarm.txt
Analyzer MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-analyzer.txt
Antivirus Objects MIB 0 0 0 0 0 0 1 0 0
topics/reference/mibs/mib-jnx-js-utm-av.txt
ATM Class-of-Service MIB 0 1 1 0 0 0 1 0 1
topics/reference/mibs/mib-jnx-atm-cos.txt
ATM MIB 1 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-atm.txt
BGP4 V2 MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-bgpmib2.txt
Bidirectional Forwarding Detection MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-bfd.txt

Table 61: Enterprise-Specific MIBs and Supported Devices (continued)

Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Chassis Forwarding MIB 1 0 0 0 1 1 1 0 0
topics/reference/mibs/mib-jnx-chassis-fwdd.txt
Chassis MIBs 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-chassis.txt
topics/reference/mibs/mib-jnx-chas-defines.txt
Chassis Cluster MIBs 0 0 0 0 0 0 0 1 1
topics/reference/mibs/mib-jnx-jsrpd.txt
Class-of-Service MIB 1 1 1 1 1 1 0 0 1
topics/reference/mibs/mib-jnx-cos.txt
Configuration Management MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-cfgmgmt.txt
Destination Class Usage MIB 0 1 1 0 1 0 0 1 1
topics/reference/mibs/mib-jnx-dcu.txt
DHCP MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-jdhcp.txt
DHCPv6 MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-jdhcpv6.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Digital Optical Monitoring MIB 0 1 1 1 1 1 0 0 1
topics/reference/mibs/mib-jnx-dom.txt
DNS Objects MIB 0 0 0 0 0 0 0 1 1
topics/reference/mibs/mib-jnx-js-dns.txt
Dynamic Flow Capture MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-dfc.txt
Ethernet MAC MIB 0 1 1 1 1 0 0 0 1
topics/reference/mibs/jnx-mac.txt
Event MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-event.txt
EX Series MAC Notification MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-ex-mac-notification.txt
EX Series SMI MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-ex-smi.txt
Experimental MIB 1 1 1 1 1 0 0 0 0
topics/reference/mibs/mib-jnx-exp.txt
Firewall MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-firewall.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Flow Collection Services MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-coll.txt
Host Resources MIB 1 1 1 1 1 0 1 1 1
topics/reference/mibs/mib-jnx-hostresources.txt
Interface MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-if-extensions.txt
IP Forward MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-ipforward.txt
IPsec Generic Flow Monitoring Object MIB 0 0 0 0 0 0 1 1 1
topics/reference/mibs/mib-jnx-ipsec-flow-mon.txt
IPsec Monitoring MIB 0 1 1 1 1 0 0 1 0
topics/reference/mibs/mib-jnx-ipsec-monitor-asp.txt
IPsec VPN Objects MIB 0 0 0 0 0 0 1 0 0
topics/reference/mibs/mib-jnx-js-ipsec-vpn.txt
IPv4 MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-ipv4.txt
IPv6 and ICMPv6 MIB 0 1 1 1 0 1 1 1 1
topics/reference/mibs/mib-jnx-ipv6.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
L2ALD MIB 0 0 1 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-l2ald.txt
L2CP MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-l2cp-features.txt
L2TP MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-l2tp.txt
LDP MIB 1 1 1 0 0 1 0 0 1
topics/reference/mibs/mib-jnx-ldp.txt
License MIB 0 1 1 0 0 0 1 1 1
topics/reference/mibs/mib-jnx-license.txt
Logical Systems MIB 0 0 0 0 0 0 0 1 1
topics/reference/mibs/mib-jnx-lsys-securityprofile.txt
MIMSTP MIB 0 0 1 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-mimstp.txt
MPLS LDP MIB 1 1 1 1 1 1 0 0 0
topics/reference/mibs/mib-jnx-mpls-ldp.txt
MPLS MIB 1 1 1 1 1 1 0 0 1
topics/reference/mibs/mib-jnx-mpls.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
MVPN MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-mvpn.txt and
topics/reference/mibs/mib-jnx-l2l3vpn-mcast.txt.
NAT Objects MIB 0 0 0 0 1 0 1 1 1
topics/reference/mibs/mib-jnx-js-nat.txt
NAT Resources-Monitoring MIB 0 1 1 0 0 0 0 0 0
topics/reference/ mibs/mib-jnx-sp-nat.txt
OTN Interface Management MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-otn.txt
Packet Forwarding Engine MIB 1 1 1 0 1 1 1 1 1
topics/reference/mibs/mib-jnx-pfe.txt
Packet Mirror MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-js-packet-mirror.txt
PAE Extension MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-pae-extension.txt
Passive Monitoring MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-pmon.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Ping MIB 1 1 1 1 1 0 1 1 1
topics/reference/mibs/mib-jnx-ping.txt
Policy Objects MIB 0 0 0 0 1 0 1 1 1
topics/reference/mibs/mib-jnx-js-policy.txt
Power Supply Unit MIB 0 0 0 1 0 1 0 0 0
topics/reference/mibs/mib-jnx-power-supply-unit.txt
PPP MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-ppp.txt
PPPoE MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-pppoe.txt
Pseudowire ATM MIB 0 1 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-pwatm.txt
Pseudowire TDM MIB 1 1 1 0 0 0 0 0 0
topics/ reference/mibs/mib-jnx-pwtdm.txt
PTP MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-timing-notifications.txt
Real-Time Performance Monitoring MIB 0 1 1 1 1 0 1 0 0
topics/reference/mibs/mib-jnx-rpm.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Reverse-Path-Forwarding MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-rpf.txt
RMON Events and Alarms MIB 1 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-rmon.txt
RSVP MIB 1 1 1 1 0 1 0 0 0
topics/reference/mibs/mib-jnx-rsvp.txt
Security Interface Extension Objects MIB 0 0 0 0 1 0 1 1 1
topics/reference/mibs/mib-jnx-js-if-ext.txt
Security Screening Objects MIB 0 0 0 0 0 0 0 0 1
topics/reference/mibs/mib-jnx-js-screening.txt
Services PIC MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-sp.txt
SNMP IDP MIB 0 0 0 0 0 0 1 1 0
topics/reference/mibs/mib-jnx-js-idp.txt
SONET APS MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-sonetaps.txt
SONET/SDH Interface Management MIB 0 1 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-sonet.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
Source Class Usage MIB 0 1 1 0 0 0 0 0 1
topics/reference/mibs/mib-jnx-scu.txt
SPU Monitoring MIB 0 0 0 0 0 0 1 1 1
topics/reference/mibs/mib-jnx-js-spu-monitoring.txt
Structure of Management Information MIB 1 1 1 1 1 0 1 1 1
topics/reference/mibs/mib-jnx-smi.txt
Subscriber MIB 1 0 1 0 0 0 0 0 0
topics/reference/mibs/mib-jnx-subscriber.txt
System Log MIB 0 1 1 1 1 1 1 1 1
topics/reference/mibs/mib-jnx-syslog.txt
Traceroute MIB 0 1 1 1 1 0 1 1 1
topics/reference/mibs/mib-jnx-traceroute.txt
Utility MIB 0 1 1 1 1 0 1 1 1
topics/reference/mibs/mib-jnx-util.txt
Virtual Chassis MIB 0 0 0 1 1 0 0 0 0
topics/reference/mibs/mib-jnx-virtualchassis.txt
VLAN MIB 0 0 0 1 0 0 0 0 0
topics/reference/mibs/mib-jnx-vlan.txt


Platforms
SRX
SRX1500,
SRX300, SRX5400,
SRX320, SRX5600,
and and
VPLS MIBs 0 1 1 1 0 0 0 0 0
• http://www.juniper.net/techpubs/en_US/junos15.1/
topics/reference/mibs/mib-jnx-vpls-generic.txt
topics/reference/mibs/mib-jnx-vpls-ldp.txt
topics/reference/mibs/mib-jnx-vpls-bgp.txt
VPN Certificate Objects MIB 0 0 0 0 1 0 1 1 1
topics/reference/mibs/mib-jnx-js-cert.txt
VPN MIB 1 1 1 1 1 0 0 0 0
topics/reference/mibs/mib-jnx-vpn.txt
Related • Enterprise-Specific SNMP Traps Supported by Junos OS

Documentation
• Standard SNMP MIBs Supported by Junos OS
• Loading MIB Files to a Network Management System

CHAPTER 30
Configuring IP and MAC Address

Validation
• IP and MAC Address Validation in ACX Series on page 995

• Configuring IP and MAC Address Validation for Static Interfaces on page 997
IP and MAC Address Validation in ACX Series
IP and MAC address validation enables the ACX Series router to validate that received
packets contain a trusted IP source and an Ethernet MAC source address.
Configuring IP and MAC address validation can provide additional validation when
subscribers access billable services. MAC address validation provides additional security
by enabling the router to drop packets that do not match, such as packets with spoofed
addresses.
When subscribers log in, they are automatically assigned IP addresses by DHCP. With IP
and MAC address validation enabled, the router compares the IP source and MAC source
addresses against trusted addresses, and forwards or drops the packets according to
the match and the validation mode.
IP and MAC address validation on ACX Series routers support Fast Ethernet, Gigabit
Ethernet, and 10-Gigabit Ethernet interfaces (with or without VLAN tagging).
NOTE: In ACX Series routers, IP and MAC address validation is implemented

using ternary content addressable memory (TCAM) space. The allocated
TCAM space for MAC address validation is shared by the logical interface-level
fixed classifier feature. From a scaling perspective, the allocated 192 hardware
TCAM entries are shared by these features and the allocation of TCAM entries
work on a first-come-first-serve mode. On the same logical interface, if these
features are enabled, then IP source and MAC source validation feature takes
higher precedence than the logical interface level fixed classifier. These
features work independently on different logical interfaces without any
limitation.

Trusted Addresses
A trusted address tuple comprises a 32-bit IP address and a 48-bit MAC address. Prefixes
and ranges are not supported.
The IP source address and the MAC source address used for validation must be from a
trusted source.
All static ARP addresses configured through the Junos OS CLI are trusted addresses;
dynamic ARP addresses are not considered trusted addresses.
Addresses dynamically created through an extended DHCP local server are also trusted
addresses. When a DHCP server and client negotiate an IP address, the resulting IP
address and MAC address tuple is trusted. Each DHCP subscriber can generate more
than one address tuple.
Each MAC address can have more than one IP address, which can result in more than
one valid tuple. Each IP address must map to one MAC address.
Types of IP and MAC Address Validation

You can configure either of two types or modes of MAC address validation—loose or
strict. The behavior of the two modes varies depending on how well the incoming packets
match the trusted address tuples. The modes differ only when the IP source address
alone does not match any trusted IP address. Table 62 on page 996 compares the behavior
of the two modes. Dropped packets are considered to be spoofed.
Table 62: Comparison of MAC Address Validation Modes

Incoming Packet Addresses Match Trusted Address Tuple Loose Mode Action Strict Mode Action
• IP source address matches Forwards packet Forwards packet

and
• MAC source address matches
• IP source address matches Drops packet Drops packet

but
• MAC source address does not match
• IP source address does not match Forwards packet Drops packet

and
• MAC source address either matches or does not match
Configuring strict mode is a more conservative strategy because it requires both received
source addresses to match trusted addresses.
Related • Configuring IP and MAC Address Validation for Static Interfaces on page 997
Documentation
• mac-validate on page 1593

Chapter 30: Configuring IP and MAC Address Validation
Configuring IP and MAC Address Validation for Static Interfaces
This topic describes how to configure IP and MAC address validation for static interfaces
Subscriber interfaces can be statically created and associated with a dynamic profile
(for example, VLAN interfaces).
To configure IP and MAC address validation on static interfaces, include the mac-validate
statement at the [edit interfaces interface-name unit logical-unit-number family inet]
hierarchy level.
1. Configure the static VLAN interface.
[edit interfaces]
user@host# edit interface-name unit logical-unit-number family inet
2. Configure the type of IP and MAC address validation for the interface.
• To configure loose validation:
[edit interfaces interface-name unit logical-unit-number family inet]

user@host# set mac-validate loose
• To configure strict validation:
[edit interfaces interface-name unit logical-unit-number family inet]

user@host# set mac-validate strict
For example, to configure loose validation on interface fe-0/0/0.0, configure the following:
[edit interfaces fe-0/0/0 unit 0 family inet]

user@host# set mac-validate loose
To check packets dropped by IP and MAC address validation, use the run show interfaces
interface-name statistics show command.
Related • IP and MAC Address Validation in ACX Series on page 995

Documentation


CHAPTER 31
Configuring Network Address Translation

(NAT) and Stateful Firewall Services
• Network Address Translation Overview on page 999

• Network Address Translation Constraints on ACX on page 1003
• Configuring Address Pools for Network Address Port Translation (NAPT)
• ALGs Available by Default for Junos OS Address Aware NAT on ACX500
Router on page 1009
• Junos Network Secure Overview on page 1020
• Configuring Stateful Firewall Rules on page 1023
• Service Filter Actions on page 1039
Network Address Translation Overview
Network Address Translation (NAT) is a method for modifying or translating network

address information in packet headers. Either or both source and destination addresses
in a packet may be translated. NAT can include the translation of port numbers as well
as IP addresses.

NAT is described in RFC 1631 to solve IP (version 4) address depletion problems. NAT
has been found to be a useful tool for firewalls, traffic redirect, load sharing, network
migrations, and so on.
NOTE: In ACX Series routers, NAT is supported only on the ACX1100

AC-powered router and ACX500 routers for inline NAT and inline IPsec
services. ACX1100 AC-powered router supports only source NAT for IPv4
packets. Static and dynamic NAT types are currently not supported. Service
chaining (GRE, NAT, and IPSec) on ACX1100-AC and ACX500 routers is not
supported.
A license is required for enabling inline services on ACX500 routers.
NOTE: ACX5048 and ACX5096 routers do not support NAT configurations.
Source NAT is the translation of the source IP address of a packet leaving the router.
Source NAT is used to allow hosts with private IP addresses to access a public network.
Source NAT allows connections to be initiated only for outgoing network connections—for
example, from a private network to the Internet. Source NAT is commonly used to:
• Translate a single IP address to another address (for example, to provide a single

device in a private network with access to the Internet).
• Translate a contiguous block of addresses to another block of addresses of the same

size.
• Translate a contiguous block of addresses to another block of addresses of smaller

size.
• Translate a contiguous block of addresses to a single IP address or a smaller block of

addresses using port translation.
• Translate a contiguous block of addresses to the address of the egress interface.
Related • Network Address Port Translation Overview on page 1001

Documentation

Chapter 31: Configuring Network Address Translation (NAT) and Stateful Firewall Services
page 1007
Network Address Port Translation Overview
Network Address Port Translation (NAPT) is a method by which many network addresses
and their TCP/UDP ports are translated into a single network address and its TCP/UDP
ports. This translation can be configured in both IPv4 and IPv6 networks.
In ACX Series routers, you can have up to 4096 network address translations at a time.

Documentation
page 1007
Network Address Translation Address Overload in ACX Series
The NAT services on ACX Series routers allows Junos OS interface addresses to be shared
with a NAPT pool. This feature of sharing the same address/port between the NAPT pool
and Junos OS is termed as address overloading.

To achieve address overloading, the available IPv4 address or port range of 1 to 65,536
addresses is partitioned between Junos OS and NAT as shown below:
• Junos OS—1 to 49,159 addresses.
• NAPT pool—49,160 through 53,255 addresses.
• Junos OS—53,255 through 65,535 addresses.
The number of ports reserved for NAPT pool with address overload feature is 4096.
To enable address-overloading, include the address-overload statement and the interface

statement at the [edit services nat pool nat-pool-name] hierarchy level.
The address-overload statement enables sharing of IPv4 address between Junos OS and
the NAT pool. Along with the address-overload statement, you must also specify the
interface statement so that the first available IPv4 address or port of the interface is
picked up for the NAT pool.
You can configure the address overload feature the following ways:
• Configure an interface along with the address-overload statement as shown in the

following example.
pool p3 {
address-overload;
port {
range low 49160 high 53255;
}
}
In this case, the primary address on the interface is picked for the NAT pool.
• Directly configure a /32 address as shown in the following example:
pool p4 {
address-overload;
address 45.0.0.1/32;
port {
}
}
The interface statement enables sharing of IPv4 interface address with the NAT pool
along with the port range specified in the pool.

Documentation

page 1007
Network Address Translation Constraints on ACX
You should consider the following constraints while configuring Network Address
Translation (NAT) on ACX Series routers:
• When a port is defined in a NAT pool, you can configure only one address or one address
range in the pool.
• ACX Series routers support nat-rules with match-direction as input. match-direction as

output is not supported.
• When you specify an address range or an address prefix in a NAT pool, the maximum
number of addresses supported is 65,535. ACX Series routers supports up to 4096
network address translations at a time.
• The maximum number of service sets that can be configured is 2.
• In a NAT rule term, the from clause can contain a maximum of 4 matching addresses.
• The maximum terms per NAT rule allowed is 4.
• The maximum NAT rules per service set allowed is 2.

Documentation
page 1007

Network Address Translation Rules Overview
To configure a Network Address Translation (NAT) rule, include the rule rule-name
statement at the [edit services nat] hierarchy level:
[edit services nat]

allow-overlapping-nat-pools ;
apply-groups;
apply-groups-except;
pool pool-name;
port-forwarding port-forwarding-name;
rule (Services NAT) rule-name {
match-direction (Services NAT) input;
term (Services NAT) term-name {
from {
destination-address (Services NAT) prefix;
destination-address-range (Services NAT) low minimum-value high maximum-value
<except>;
destination-port range;
source-address prefix;
source-address-range (Services NAT) low minimum-value high maximum-value
<except>;
}
then (Services NAT) {
no-translation;
translated {
source-pool nat-pool-name;
source-prefix (Services NAT) source-prefix;
translation-type {
napt-44;
}
}
}
}
}
rule-set rule-set-name;
Each rule must include a match-direction statement that specifies the direction in which
the match is applied.
NOTE: ACX Series routers support only input as the match direction.
In addition, each NAT rule consists of a set of terms, similar to a firewall filter. A term
consists of the following:

• from statement—Specifies the match conditions and applications that are included
and excluded.
• then statement—Specifies the actions and action modifiers to be performed by the

router software.
The following sections explain how to configure the components of NAT rules:
• Configuring Match Direction for NAT Rules on page 1005

• Configuring Match Conditions in NAT Rules on page 1005
• Configuring Actions in NAT Rules on page 1006
• Configuring Translation Types on page 1006
Configuring Match Direction for NAT Rules

the match is applied. To configure where the match is applied, include the match-direction
statement at the [edit services nat rule rule-name] hierarchy level:
[edit services nat rule rule-name]

match-direction input;
The match direction is used with respect to the traffic flow through the NAT engine. When
a packet is sent to the NAT engine, direction information is carried along with it. The
packet direction is determined on the basis of the following criteria:
• With an interface service set, packet direction is determined by whether a packet is

entering or leaving the interface on which the service set is applied.
• With a next-hop service set, packet direction is determined by the interface used to
route the packet to the NAT engine. If the inside interface is used to route the packet,
the packet direction is input. If the outside interface is used to direct the packet to the
NAT engine, the packet direction is output. For more information about inside and
outside interfaces, see “Configuring Service Sets to Be Applied to Services Interfaces”
on page 1031.
• On the NAT engine, a flow lookup is performed. If no flow is found, rule processing is
performed. All rules in the service set are considered. During rule processing, the packet
direction is compared against rule directions. Only rules with direction information that
matches the packet direction are considered.
Configuring Match Conditions in NAT Rules

To configure NAT match conditions, include the from statement at the [edit services nat
rule rule-name term term-name] hierarchy level:
[edit services nat rule rule-name term term-name]

from {
destination-address (Services NAT) prefix;
destination-address-range (Services NAT) low minimum-value high maximum-value
<except>;
destination-port range;

source-address prefix;
source-address-range (Services NAT) low minimum-value high maximum-value <except>;
}
To configure traditional NAT, you can use the destination address, a range of destination
addresses, the source address, or a range of source addresses as a match condition, in
the same way as you would configure a firewall filter; for more information, see the
Routing Policies, Firewall Filters, and Traffic Policers Feature Guide.
Alternatively, you can specify a list of source or destination prefixes by including the
prefix-list statement at the [edit policy-options] hierarchy level and then including either
the destination-prefix-list or the source-prefix-list statement in the NAT rule.
Configuring Actions in NAT Rules

To configure NAT actions, include the then statement at the [edit services nat rule
rule-name term term-name] hierarchy level:
[edit services nat rule rule-name term term-name]

then (Services NAT) {
no-translation;
syslog (Services NAT) ;
translated {
source-pool nat-pool-name;
source-prefix (Services NAT) source-prefix;
translation-type {
napt-44;
}
}
}
The no-translation statement enables you to specify addresses that you want excluded
from NAT.
The syslog statement enables you to record an alert in the system logging facility.
Configuring Translation Types

The translation-type statement specifies the type of NAT used for source or destination
traffic. ACX Series routers support only napt-44 NAT type. The napt-44 option implements
dynamic translation of source IP addresses with port mapping. You must specify a name
for the source-pool statement. The referenced pool must include a port configuration. If
a port range is specified, then it implies that Network Address Port Translation (NAPT)
is used.

NOTE: When configuring NAT, if any traffic is destined for the following
addresses and does not match a NAT flow or NAT rule, the traffic is dropped:
• Addresses specified in the source NAT pool when you are using source
translation

Documentation
page 1007
Configuring Address Pools for Network Address Port Translation (NAPT) Overview
With Network Address Port Translation (NAPT), you can have up to 4096 network
address or port translations.
The port statement specifies port assignment for the translated addresses. To configure
a specific range of port numbers, include the port range low minimum-value high
maximum-value statement at the [edit services nat pool nat-pool-name] hierarchy level.
Junos OS for ACX Series routers allocates ports sequentially—that is, ACX Series routers
allocate the first available address or port from the NAT pool.
The NAT pool called napt in the following configuration example uses the sequential
implementation:
pool napt {
address-range low 100.0.0.1 high 100.0.0.3;
port {
}
}
• Endpoint Independent Flow for NAPT on page 1007
Endpoint Independent Flow for NAPT

Endpoint independent flow ensures the assignment of the same external address and
port for all connections from a given host or port to any destination. This means if the

address or port are from a different source, you are free to assign a different external
address.

Documentation
Enabling Inline Services Interface on ACX Series
The inline services interface is a virtual interface that resides on the Packet Forwarding
Engine. The si- interface makes it possible to provide NAT and IPsec services without
using a special services PIC.
To configure inline services interface, you define the service interface as type si-
(service-inline) interface. You must also reserve adequate bandwidth for the inline services
interface. This enables you to configure both interface or next-hop service sets used for
NAT and IPsec services.
NOTE: In ACX Series routers, you can configure only one inline services
interface as an anchor interface for NAT and IPsec sessions: si-0/0/0.
To enable inline services interface:
1. Access an FPC-managed slot and the PIC where the interface is to be enabled.
[edit chassis]
user@host# edit fpc slot-number pic number

2. Enable the interface and specify the amount of bandwidth reserved on each Packet
Forwarding Engine for tunnel traffic that uses inline services.
[edit chassis fpc slot-number pic number]

user@host# set inline-services bandwidth 1g

Documentation
• IPsec for ACX Series Overview on page 1087
page 1007
ALGs Available by Default for Junos OS Address Aware NAT on ACX500 Router
The following Application Level Gateways (ALGs) listed in Table 63 on page 1010 are
supported for NAT processing on ACX500 routers.
To view the implementation details (port, protocol, and so on) for these Junos OS default
applications, locate the Junos OS Default ALG Name in the table and then look up the
listed name in the groups. For example, for details about TFTP, look up junos-tftp as
shown.
NOTE: The ALG for NAT is supported only on the ACX500 indoor routers.
TIP: The Junos OS provides the junos-alg, which enables other ALGs to
function by handling ALG registrations, causing slow path packets to flow
through registered ALGs, and transferring ALG events to the ALG plug-ins.

The junos-alg ALG is automatically available on the ACX500 router and does
not require further configuration.
NOTE: The remote login (rlogin) application layer gateways (ALGs) are not
supported with network address port translation (NAPT) on ACX500 router.
Table 63: ALGs Available by Default

ALG ACX500 Router Junos OS Default ALG Name
Basic TCP ALG yes NOTE: Specific Junos OS ALGs are not supported.
However, a feature called TCP tracker, available by
default, performs segment ordering and retransmit
and connection tracking, validations for TCP
connections.
Basic UDP ALG yes NOTE: TCP tracker performs limited integrity and
validation checks for UDP.
DNS yes • junos-dns-tcp

• junos-dns-udp
FTP yes • junos-ftp
ICMP yes • junos-icmp-all
NOTE: ICMP messages are handled by

default, but PING ALG support is not
provided.
TFTP yes • junos-tftp
Unix Remote Shell yes • junos-rsh

Service
NOTE: Remote Shell (RSH) ALG is not
supported for network address port
translation (NAPT).
ALG Support Details

This section includes details about the ALGs. It includes the following:
• Basic TCP on page 1011

• Basic UDP on page 1011
• DNS on page 1012
• FTP on page 1013
• ICMP on page 1016

• TFTP on page 1016

• UNIX Remote-Shell Services on page 1018
Basic TCP
This ALG performs basic sanity checking on TCP packets. If it finds errors, it generates
the following anomaly events and system log messages:
• TCP source or destination port zero
• TCP header length check failed
• TCP sequence number zero and no flags are set
• TCP sequence number zero and FIN/PSH/RST flags are set
• TCP FIN/RST or SYN(URG|FIN|RST) flags are set
The TCP ALG performs the following steps:
1. When the router receives a SYN packet, the ALG creates TCP forward and reverse
flows and groups them in a conversation. It tracks the TCP three-way handshake.
2. The SYN-defense mechanism tracks the TCP connection establishment state. It

expects the TCP session to be established within a small time interval (currently
4 seconds). If the TCP three-way handshake is not established in that period, the
session is terminated.
3. A keepalive mechanism detects TCP sessions with nonresponsive endpoints.
4. ICMP errors are allowed only when a flow matches the selector information specified
in the ICMP data.
Basic UDP
This ALG performs basic sanity checking on UDP headers. If it finds errors, it generates
the following anomaly events and system log messages:
• UDP source or destination port 0
• UDP header length check failed
The UDP ALG performs the following steps:
1. When it receives the first packet, the ALG creates bidirectional flows to accept forward
and reverse UDP session traffic.
2. If the session is idle for more than the maximum allowed idle time (the default is
30 seconds), the flows are deleted.
3. ICMP errors are allowed only when a flow matches the selector information specified
in the ICMP data.

DNS
The Domain Name System (DNS) ALG handles data associated with locating and
translating domain names into IP addresses. The ALG typically runs on port 53. The ALG
monitors DNS query and reply packets and supports only UDP traffic. The ALG does not
support payload translations. The DNS ALG closes the session only when a reply is
received or an idle timeout is reached.
The following is an example for configuring DNS ALG:
1. Creating NAT interface.
[edit]
services {
service-set set-dns {
nat-rules nat-dns;
interface-service {
service-interface ms-0/2/0;
}
}
2. Configuring NAT pool.
[edit]
services {
nat {
pool p-napt {
address 1.1.1.1/32;
}
}
}
3. Defining NAT rules for DNS ALG.
[edit]
services {
nat {
rule nat-dns {
term term1 {
from {
source-address {
50.50.50.2/32;
}
applications junos-dns-udp;;
}
then {
translated {
source-pool p-napt;
translation-type {
basic-nat44;
}
}
}

}
}
}
4. Binding service sets to the interface.
[edit]
interfaces {
ge-0/1/0 {
media-type copper;
unit 0 {
family inet {
service {
input {
service-set set-dns;
}
output {
service-set set-dns;
}
}
address 50.50.50.1/24;
}
}
}
ge-0/1/1 {
media-type copper;
unit 0 {
family inet {
address 60.60.60.1/24;
}
}
}
ms-0/2/0 {
unit 0 {
family inet;
}
}
}
FTP
FTP is the File Transfer Protocol, specified in RFC 959. In addition to the main control
connection, data connections are also made for any data transfer between the client
and the server; and the host, port, and direction are negotiated through the control
channel.
For non-passive-mode FTP, Junos OS stateful firewall service scans the client-to-server
application data for the PORT command, which provides the IP address and port number
to which the server connects. For passive-mode FTP, Junos OS stateful firewall service
scans the client-to-server application data for the PASV command and then scans the
server-to-client responses for the 227 response, which contains the IP address and port
number to which the client connects.

There is an additional complication: FTP represents these addresses and port numbers
in ASCII. As a result, when addresses and ports are rewritten, the TCP sequence number
might be changed, and thereafter the NAT service needs to maintain this delta in SEQ
and ACK numbers by performing sequence NAT on all subsequent packets.
Support for stateful firewall and NAT services requires that you configure the FTP ALG
on TCP port 21 to enable the FTP control protocol. The ALG performs the following tasks:
• Automatically allocates data ports and firewall permissions for dynamic data
connection
• Creates flows for the dynamically negotiated data connection
• Monitors the control connection in both active and passive modes
• Rewrites the control packets with the appropriate NAT address and port information
On ACX500, for passive FTP to work properly without FTP application layer gateway
(ALG) enabled (by not specifying the application junos-ftp statement at the [edit services
nat rule rule-name term term-name from] hierarchy level), you must enable the address
pooling paired (APP) functionality enabled (by including the address-pooling statement
at the [edit services nat rule rule-name term term-name then translated] hierarchy level).
Such a configuration causes the data and control FTP sessions to receive the same NAT
address.
The following is an example for configuring FTP ALG:
[edit]
services {
service-set set-ftp {
nat-rules nat-ftp;
interface-service {
}
}
[edit]
services {
nat {
pool p-napt {
address 30.30.30.0/24;
port {
}
}
}
3. Defining NAT rules for FTP ALG.
[edit]
services {

nat {
rule nat-ftp {
term term1 {
from {
source-address {
10.10.10.0/24;
}
applications junos-ftp;
}
then {
translated {
source-pool p-napt;
translation-type {
napt-44;
}
}
}
}
}
}
[edit]
interfaces {
ge-0/1/0 {
media-type copper;
unit 0 {
family inet {
service {
input {
service-set set-ftp;
}
output {
service-set set-ftp;
}
}
address 10.10.10.1/24;
}
}
}
ge-0/1/1 {
media-type copper;
unit 0 {
family inet {
address 10.10.10.1/24;
}
}
}
ms-0/2/0 {
unit 0 {
family inet;
}
}

ICMP
The Internet Control Message Protocol (ICMP) is defined in RFC 792. The Junos OS allows
ICMP messages to be filtered by specific type or specific type code value. ICMP error
packets that lack a specifically configured type and code are matched against any existing
flow in the opposite direction to check for the legitimacy of the error packet. ICMP error
packets that pass the filter matching are subject to NAT translation.
The ICMP ALG always tracks ping traffic statefully using the ICMP sequence number.
Each echo reply is forwarded only if there is an echo request with the corresponding
sequence number. For any ping flow, only 20 echo requests can be forwarded without
receiving an echo reply. When you configure dynamic NAT, the PING packet identifier is
translated to allow additional hosts in the NAT pool to use the same identifier.
Support for NAT services requires that you configure the ICMP ALG if the protocol is
needed. You can configure the ICMP type and code for additional filtering.
TFTP
The Trivial File Transfer Protocol (TFTP) is specified in RFC 1350. The initial TFTP requests
are sent to UDP destination port 69. Additional flows can be created to get or put individual
files. Support of NAT services requires that you configure the TFTP ALG for UDP
destination port 69.
The following is an example for configuring TFTP ALG:
[edit]
services {
service-set set-tftp {
nat-rules nat-tftp;
interface-service {
}
}
[edit]
services {
nat {
pool p-napt {
address 1.1.1.1/32;
}
}
}
3. Defining NAT rules for TFTP ALG.
[edit]
services {

nat {
rule nat-tftp {
term term1 {
from {
source-address {
50.50.50.2/32;
}
applications junos-tftp;
}
then {
translated {
source-pool p-napt;
translation-type {
dynamic-nat44;
}
}
}
}
}
}
[edit]
interfaces {
ge-0/1/0 {
media-type copper;
unit 0 {
family inet {
service {
input {
service-set set-tftp;
}
output {
service-set set-tftp;
}
}
address 50.50.50.1/24;
}
}
}
ge-0/1/1 {
media-type copper;
unit 0 {
family inet {
address 60.60.60.1/24;
}
}
}
ms-0/2/0 {
unit 0 {
family inet;
}
}

UNIX Remote-Shell Services
Three protocols form the basis for UNIX remote-shell services:
• Exec—Remote command execution; enables a user on the client system to execute a

command on the remote system. The first command from client (rcmd) to server (rshd)
uses well-known TCP port 512. A second TCP connection can be opened at the request
of rcmd. The client port number for the second connection is sent to the server as an
ASCII string.
• Login—Better known as rlogin; uses well-known TCP port 513. For details, see RFC 1282.
No special firewall processing is required.
• Shell—Remote command execution; enables a user on the client system to execute

a command on the remote system. The first command from client (rcmd) to server
(rshd) uses well-known TCP port 514. A second TCP connection can be opened at the
request of rcmd. The client port number for the second connection is sent to the server
as an ASCII string.
NAT remote-shell services require that any dynamic source port assigned be within the
port range 512 to 1023. If you configure a NAT pool, this port range is reserved exclusively
for remote shell applications.
The following is an example for configuring RSH ALG:
[edit]
services {
service-set set-rsh {
nat-rules nat-rsh;
interface-service {
}
}
[edit]
services {
nat {
pool p-napt {
address 1.1.1.1/32;
}
}
}
3. Defining NAT rules for RSH ALG.
[edit]
services {
nat {

rule nat-rsh {
term term1 {
from {
source-address {
50.50.50.2/32;
}
applications junos-rsh;
}
then {
translated {
source-pool p-napt;
translation-type {
dynamic-nat44;
}
}
}
}
}
}
[edit]
interfaces {
ge-0/1/0 {
media-type copper;
unit 0 {
family inet {
service {
input {
service-set set-rsh;
}
output {
service-set set-rsh;
}
}
address 50.50.50.1/24;
}
}
}
ge-0/1/1 {
media-type copper;
unit 0 {
family inet {
address 60.60.60.1/24;
}
}
}
ms-0/2/0 {
unit 0 {
family inet;
}
}
}

Related • Junos Network Secure Overview on page 1020

Documentation
• Configuring Stateful Firewall Rules on page 1023
Junos Network Secure Overview
Routers use firewalls to track and control the flow of traffic. Adaptive Services and
MultiServices PICs employ a type of firewall called a stateful firewall. Contrasted with a
stateless firewall that inspects packets in isolation, a stateful firewall provides an extra
layer of security by using state information derived from past communications and other
applications to make dynamic control decisions for new communication attempts.
NOTE: On ACX Series routers, the stateful firewall configuration is supported

only on the ACX500 indoor routers.
Stateful firewalls group relevant flows into conversations. A flow is identified by the
following five properties:
• Source address
• Source port
• Destination address
• Destination port
• Protocol
A typical Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)

conversation consists of two flows: the initiation flow and the responder flow. However,
some conversations, such as an FTP conversation, might consist of two control flows
and many data flows.
Firewall rules govern whether the conversation is allowed to be established. If a

conversation is allowed, all flows within the conversation are permitted, including flows
that are created during the life cycle of the conversation.
You configure stateful firewalls using a powerful rule-driven conversation handling path.
A rule consists of direction, source address, source port, destination address, destination
port, IP protocol value, and application protocol or service. In addition to the specific
values you configure, you can assign the value any to rule objects, addresses, or ports,
which allows them to match any input value. Finally, you can optionally negate the rule
objects, which negates the result of the type-specific match.
Firewall rules are directional. For each new conversation, the router software checks the
initiation flow matching the direction specified by the rule.

Firewall rules are ordered. The software checks the rules in the order in which you include
them in the configuration. The first time the firewall discovers a match, the router
implements the action specified by that rule. Rules still unchecked are ignored.
NOTE: Starting in Junos OS Release 14.2, MS-MPC and MS-MIC interface

cards support IPv6 traffic for Junos Network Secure Stateful Firewall.
For more information, see “Configuring Stateful Firewall Rules” on page 1023.
Stateful Firewall Support for Application Protocols

By inspecting the application protocol data, the AS or MultiServices PIC firewall can
intelligently enforce security policies and allow only the minimal required packet traffic
to flow through the firewall.
The firewall rules are configured in relation to an interface. By default, the stateful firewall
allows all sessions initiated from the hosts behind the interface to pass through the
router.
NOTE: Stateful firewall ALGs are not supported on ACX500 routers.
Stateful Firewall Anomaly Checking

The stateful firewall recognizes the following events as anomalies and sends them to
the IDS software for processing:
• IP anomalies:
• IP version is not correct.
• IP header length field is too small.
• IP header length is set larger than the entire packet.
• Bad header checksum.
• IP total length field is shorter than header length.
• Packet has incorrect IP options.
• Internet Control Message Protocol (ICMP) packet length error.
• Time-to-live (TTL) equals 0.
• IP address anomalies:
• IP packet source is a broadcast or multicast.
• Land attack (source IP equals destination IP).
• IP fragmentation anomalies:

• IP fragment overlap.
• IP fragment missed.
• IP fragment length error.
• IP packet length is more than 64 kilobytes (KB).
• Tiny fragment attack.
• TCP anomalies:
• TCP port 0.
• TCP sequence number 0 and flags 0.
• TCP sequence number 0 and FIN/PSH/RST flags set.
• TCP flags with wrong combination (TCP FIN/RST or SYN/(URG|FIN|RST).
• Bad TCP checksum.
• UDP anomalies:
• UDP source or destination port 0.
• UDP header length check failed.
• Bad UDP checksum.
• Anomalies found through stateful TCP or UDP checks:
• SYN followed by SYN-ACK packets without ACK from initiator.
• SYN followed by RST packets.
• SYN without SYN-ACK.
• Non-SYN first flow packet.
• ICMP unreachable errors for SYN packets.
• ICMP unreachable errors for UDP packets.
• Packets dropped according to stateful firewall rules.
NOTE: ACX500 routers do not support IP fragmentation anomalies.
If you employ stateful anomaly detection in conjunction with stateless detection, IDS
can provide early warning for a wide range of attacks, including these:
• TCP or UDP network probes and port scanning
• SYN flood attacks
• IP fragmentation-based attacks such as teardrop, bonk, and boink

14.2 Starting in Junos OS Release 14.2, MS-MPC and MS-MIC interface cards
support IPv6 traffic for Junos Network Secure Stateful Firewall.
Configuring Stateful Firewall Rules
To configure a stateful firewall rule, include the rule rule-name statement at the [edit
services stateful-firewall] hierarchy level:
[edit services stateful-firewall]

rule rule-name {
match-direction (input | output | input-output);
term term-name {
from {
application-sets set-name;
applications [ application-names ];
destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
destination-address-range low minimum-value high maximum-value <except>;
destination-prefix-list list-name <except>;
source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
source-address-range low minimum-value high maximum-value <except>;
source-prefix-list list-name <except>;
}
then {
(accept <skip-ids>| discard | reject);
allow-ip-options [ values ];
syslog;
}
}
}
NOTE: ACX500 routers do not support applications and application-sets at

the [edit services stateful-firewall rule rule-name term term-name from]
hierarchy level.
NOTE: On ACX500 routers, to enable syslog, include the stateful-firewall-logs

CLI statement at the [edit services service-set service-set-name syslog host
local class] hierarchy level.
Each stateful firewall rule consists of a set of terms, similar to a filter configured at the
[edit firewall] hierarchy level. A term consists of the following:
and excluded. The from statement is optional in stateful firewall rules.

router software. The then statement is mandatory in stateful firewall rules.

ACX500 Series routers do not support the following while configuring stateful firewall
rules:
• match-direction (output | input-output)
• post-service-filter at the interface service input hierarchy level.
• IPv6 source address and destination address.
• application-sets, application, allow-ip-options at the [edit services stateful-firewall]

hierarchy level.
• Application Layer Gateways (ALGs).
• Chaining of services within Multiservices Modular Interfaces Card (MS-MIC) and with
inline-services (-si).
• Class of service.
• The following show services stateful-firewall CLI commands are not supported:
• show services stateful-firewall conversations—Show conversations
• show services stateful-firewall flow-analysis—Show flow table entries
• show services stateful-firewall redundancy-statistics—Show redundancy statistics
• show services stateful-firewall sip-call—Show SIP call information
• show services stateful-firewall sip-register—Show SIP register information
• show services stateful-firewall subscriber-analysis—Show subscriber table entries
The following sections explain how to configure the components of stateful firewall
rules:
• Configuring Match Direction for Stateful Firewall Rules on page 1024

• Configuring Match Conditions in Stateful Firewall Rules on page 1025
• Configuring Actions in Stateful Firewall Rules on page 1026
Configuring Match Direction for Stateful Firewall Rules

the rule match is applied. To configure where the match is applied, include the
match-direction statement at the [edit services stateful-firewall rule rule-name] hierarchy
level:
[edit services stateful-firewall rule rule-name]

match-direction (input | output | input-output);
NOTE: ACX500 Series routers do not support match-direction (output |

input-output).
If you configure match-direction input-output, sessions initiated from both directions

might match this rule.

The match direction is used with respect to the traffic flow through the AS or Multiservices
PIC. When a packet is sent to the PIC, direction information is carried along with it.
With an interface service set, packet direction is determined by whether a packet is

With a next-hop service set, packet direction is determined by the interface used to route
the packet to the AS or Multiservices PIC. If the inside interface is used to route the packet,
PIC, the packet direction is output. For more information on inside and outside interfaces,
see Configuring Service Sets to be Applied to Services Interfaces.
On the PIC, a flow lookup is performed. If no flow is found, rule processing is performed.
Rules in this service set are considered in sequence until a match is found. During rule
processing, the packet direction is compared against rule directions. Only rules with
direction information that matches the packet direction are considered. Most packets
result in the creation of bidirectional flows.
Configuring Match Conditions in Stateful Firewall Rules

To configure stateful firewall match conditions, include the from statement at the [edit
services stateful-firewall rule rule-name term term-name] hierarchy level:
[edit services stateful-firewall rule rule-name term term-name]

from {
application-sets set-name;
applications [ application-names ];
destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
destination-address-range low minimum-value high maximum-value <except>;
destination-prefix-list list-name <except>;
source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
source-address-range low minimum-value high maximum-value <except>;
source-prefix-list list-name <except>;
}
NOTE: ACX500 routers do not support applications and application-sets at

the [edit services stateful-firewall rule rule-name term term-name from]
hierarchy level.
The source address and destination address can be either IPv4 or IPv6.
You can use either the source address or the destination address as a match condition,
in the same way that you would configure a firewall filter; for more information, see the
Routing Policies, Firewall Filters, and Traffic Policers Feature Guide. You can use the wildcard
values any-unicast, which denotes matching all unicast addresses, any-ipv4, which
denotes matching all IPv4 addresses, or any-ipv6, which denotes matching all IPv6
addresses.
Alternatively, you can specify a list of source or destination prefixes by configuring the
prefix-list statement at the [edit policy-options] hierarchy level and then including either

the destination-prefix-list or the source-prefix-list statement in the stateful firewall rule.

For an example, see Examples: Configuring Stateful Firewall Rules.
If you omit the from term, the stateful firewall accepts all traffic and the default protocol
handlers take effect:
• User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Internet
Control Message Protocol (ICMP) create a bidirectional flow with a predicted reverse
flow.
• IP creates a unidirectional flow.
You can also include application protocol definitions you have configured at the [edit
applications] hierarchy level; for more information, see Configuring Application Properties.
• To apply one or more specific application protocol definitions, include the applications
statement at the [edit services stateful-firewall rule rule-name term term-name from]
hierarchy level.
• To apply one or more sets of application protocol definitions you have defined, include
the application-sets statement at the [edit services stateful-firewall rule rule-name term
term-name from] hierarchy level.
NOTE: If you include one of the statements that specifies application

protocols, the router derives port and protocol information from the
corresponding configuration at the [edit applications] hierarchy level; you
cannot specify these properties as match conditions.
Configuring Actions in Stateful Firewall Rules

To configure stateful firewall actions, include the then statement at the [edit services
stateful-firewall rule rule-name term term-name] hierarchy level:
[edit services stateful-firewall rule rule-name term term-name]

then {
(accept | discard | reject);
allow-ip-options [ values ];
syslog;
}
You must include one of the following actions:
• accept—The packet is accepted and sent on to its destination.
• accept skip-ids—The packet is accepted and sent on to its destination, but IDS rule
processing configured on an MS-MPC is skipped.
• discard—The packet is not accepted and is not processed further.
• reject—The packet is not accepted and a rejection message is returned; UDP sends an
ICMP unreachable code and TCP sends RST. Rejected packets can be logged or
sampled.

NOTE: The ACX500 indoor routers do not support the action accept skip-ids.
You can optionally configure the firewall to record information in the system logging
facility by including the syslog statement at the [edit services stateful-firewall rule
rule-name term term-name then] hierarchy level. This statement overrides any syslog
setting included in the service set or interface default configuration.
Configuring IP Option Handling
You can optionally configure the firewall to inspect IP header information by including
the allow-ip-options statement at the [edit services stateful-firewall rule rule-name term
term-name then] hierarchy level. When you configure this statement, all packets that
match the criteria specified in the from statement are subjected to additional matching
criteria. A packet is accepted only when all of its IP option types are configured as values
in the allow-ip-options statement. If you do not configure allow-ip-options, only packets
without IP header options are accepted.
NOTE: ACX500 indoor routers do not support the configuration of

allow-ip-options statement.
The additional IP header option inspection applies only to the accept and reject stateful
firewall actions. This configuration has no effect on the discard action. When the IP header
inspection fails, reject frames are not sent; in this case, the reject action has the same
effect as discard.
If an IP option packet is accepted by the stateful firewall, Network Address Translation

(NAT) and intrusion detection service (IDS) are applied in the same way as to packets
without IP option headers. The IP option configuration appears only in the stateful firewall
rules; NAT applies to packets with or without IP options.
When a packet is dropped because it fails the IP option inspection, this exception event
generates both IDS event and system log messages. The event type depends on the first
IP option field rejected.
Table 64 on page 1027 lists the possible values for the allow-ip-options statement. You
can include a range or set of numeric values, or one or more of the predefined IP option
settings. You can enter either the option name or its numeric equivalent. For more
information, refer to http://www.iana.org/assignments/ip-parameters.
Table 64: IP Option Values

Numeric
IP Option Name Value Comment
any 0 Any IP option
ip-security 130 –

Table 64: IP Option Values (continued)

Numeric
IP Option Name Value Comment
ip-stream 136 –
loose-source-route 131 –
route-record 7 –
router-alert 148 –
strict-source-route 137 –
timestamp 68 –
17.1 accept skip-ids—The packet is accepted and sent on to its destination,

but IDS rule processing configured on an MS-MPC is skipped.
Related • Junos Network Secure Overview on page 1020

Documentation
• Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC
Understanding Service Sets
Junos OS for ACX Series routers enables you to create service sets that define a collection
of services to be performed by an inline services interface. You can configure the service
set either as an interface-style service set or as a next-hop-style service set.
An interface-style service set is used as an action modifier across an entire interface. You
can use an interface-style service set when you want to apply services to packets passing
through an interface.
A next-hop-style service set is a route-based method of applying a particular service.

Only packets destined for a specific next hop are serviced by the creation of explicit static
routes. This configuration is useful when services need to be applied to an entire virtual
routing and forwarding (VRF) table, or when routing decisions determine that services
need to be performed. When a next-hop-style service is configured, the services interface
is considered to be a two-legged module with one leg configured to be the inside interface
(inside the network) and the other configured as the outside interface (outside the
network).
To configure service sets for NAT services, include the service-set statement at the [edit
services] hierarchy level:
[edit services]

service-set service-set-name {
interface-service {
service-interface interface-name;
}
nat-rule-sets rule-set-name;
nat-rules rule-names;
stateful-firewall-rule-setsrule-set-name;
stateful-firewall-rules rule-names;
next-hop-service {
inside-service-interface interface-name.unit-number;
outside-service-interface interface-name.unit-number;
}
}
To configure service sets for IPsec VPN services, include the service-set statement at the
[edit services] hierarchy level:
[edit services]
interface-service {
}
next-hop-service {
}
ipsec-vpn-options {
local-gateway (address | interface);
no-anti-replay;
}
ipsec-vpn-rules rule-name;
}

Documentation
page 1007

Configuring Service Sets for Network Address Translation
When configuring a service set for Network Address Translation (NAT) processing, make
sure you have defined:
• Service interfaces for handling inbound and outbound traffic
• A NAT rule or rule set
NOTE: Prior to Junos OS Release 11.4R3, you could use a source NAT pool
only in a single service set. In Junos OS Release 11.4R3 and subsequent
releases, you can reuse a source or destination NAT pool in multiple service
sets, provided that the service interfaces associated with the service sets are
in different virtual routing and forwarding (VRF) instances.
• For interface-style service sets, when a NAT pool is reused in multiple

service sets, the service interfaces used in the interface-service
service-interface option of each service set must be in different VRFs.
• For next-hop-style service sets, when a NAT pool is reused in multiple

service sets, the service interfaces used in the outside-interface option of
each service set must be in different VRFs.
Not adhering to these service interface restrictions causes multiple routes

to be installed in the same VRF for the same NAT addresses, thereby causing
reverse traffic to be processed incorrectly.
To enable sharing of source NAT pools, include the

allow-overlapping-nat-pools statement at the [edit services nat] hierarchy
level.
To configure a NAT service set:
1. At the [edit services] hierarchy level, define the service set.
[edit services]
user@host# edit service-set service-set-name
2. Configure either an interface service, which requires a single service interface, or a

next-hop service, which requires an inside and outside service interface.
[edit services service-set service-set-name]

user@host# set interface-service service-interface interface-name
Or


user@host# set next-hop-service inside-service-interface interface-name
outside-service-interface interface-name
NOTE: On ACX Series routers, you can use an inline-services interface as

shown in this example:
[edit]
user@host# set interfaces si-0/0/0
[edit services service-set s1]
user@host# set interface-service service-interface si-0/0/0
For more information on interface service and next-hop service, see “Configuring
Service Sets to Be Applied to Services Interfaces” on page 1031.
3. Configure a reference to the NAT rules or rule set to be used with the service set.

user@host set nat-rules rule-or-ruleset-name

Documentation
page 1007
Configuring Service Sets to Be Applied to Services Interfaces
You can configure an inline-services interface on which a service is to be performed.

Services interfaces are used with either of the service set types described in the following
sections.
• Configuring Services Interface on page 1032

• Configuring Next-Hop Service Sets on page 1032
• Determining Traffic Direction on page 1033

Configuring Services Interface

An interface service set is used as an action modifier across an entire interface. To
configure the services interface, include the interface-service statement at the
[edit services service-set service-set-name] hierarchy level:

interface-service {
}
Only the interface name is needed, because Junos OS manages logical unit numbers
automatically. The services interface must be an inline-services interface for which you
have configured unit 0 family inet at the [edit interfaces interface-name] hierarchy level.
When you have defined and grouped the service rules by configuring the service-set
definition, you can apply services to one or more interfaces installed on the router. When
you apply the service set to an interface, it automatically ensures that packets are directed
to the Network Address Translation (NAT) engine.
To associate a defined service set with an interface, include the service-set statement
with the input and output statement at the [edit interfaces interface-name unit
logical-unit-number family inet service] hierarchy level:
[edit interfaces interface-name unit logical-unit-number family inet service]

input {
service-set service-set-name <service-filter filter-name>;
}
output {
}
You configure the same service set on the input and output sides of the interface. You
can optionally include filters associated with each service set to refine the target and
additionally process the traffic. If you include the service-set statement without a
service-filter definition, Junos OS assumes that the match condition is true and selects
the service set for processing automatically.
NOTE: If you configure service sets with filters, you must configure the service
sets on the input and output sides of the interface.
Configuring Next-Hop Service Sets

A next-hop service set is a route-based method of applying a particular service. Only
packets destined for a specific next hop are serviced by the creation of explicit static
need to be performed.

When a next-hop service is configured, the IPsec or NAT engine is considered to be a

two-part interface, with one part configured to be the inside interface (inside the network)
and the other configured as the outside interface (outside the network).
To configure the service domain, include the service-domain statement at the [edit
interfaces interface-name unit logical-unit-number] hierarchy level:
[edit interfaces interface-name unit logical-unit-number]

service-domain (inside | outside);
The service-domain setting must match the configuration for the next-hop’s inside and
outside services interfaces. To configure the inside and outside services interfaces, include
the next-hop-service statement at the [edit services service-set service-set-name] hierarchy
level. The interfaces you specify must be logical interfaces on the same NAT engine. You
cannot configure unit 0 for this purpose, and the logical interface you choose must not
be used by another service set.
next-hop-service {
}
Traffic on which the service is applied is forced to the inside interface using a static route.
For example:
routing-options {
static {
route 10.1.2.3 next-hop si-0/0/0.1;
}
}
After the service is applied, traffic exits through the outside interface. A lookup is then
performed in the Packet Forwarding Engine to send the packet out of the NAT engine.
The reverse traffic enters the outside interface, is serviced, and sent to the inside interface.
The inside interface forwards the traffic out of the NAT engine.
Determining Traffic Direction

When you configure next-hop service sets, the IPsec or NAT engine functions as a two-part
interface, in which one part is the inside interface and the other part is the outside interface.
The following sequence of actions takes place:
1. To associate the two parts with logical interfaces, you configure two logical interfaces
with the service-domain statement, one with the inside value and one with the outside
value, to mark them as either an inside or outside service interface.
2. The router forwards the traffic to be serviced to the inside interface, using the next-hop
lookup table.
3. After the service is applied, the traffic exits from the outside interface. A route lookup
is then performed on the packets to be sent out of the router.
4. When the reverse traffic returns on the outside interface, the applied service is undone;
for example, IPsec traffic is decrypted or NAT addresses are unmasked. The serviced

packets then emerge on the inside interface, the router performs a route lookup, and
the traffic exits the router.
A service rule’s match direction—whether input, output, or input and output—is applied
with respect to the traffic flow through the NAT engine, not through a specific inside or
outside interface.
When a packet is sent to an NAT engine, packet direction information is carried along
with it. This is true for both interface-style and next-hop-style service sets.
Interface-Style Service Sets
Packet direction is determined by whether a packet is entering or leaving any Packet

Forwarding Engine interface (with respect to the forwarding plane) on which the
interface-service statement is applied. This is similar to the input direction for stateless
firewall filters.
The match direction can also depend on the network topology. For example, you might
route all the external traffic through one interface that is used to protect the other
interfaces on the router, and configure various services on this interface specifically.
Alternatively, you might use one interface for priority traffic and configure special services
on it, but not care about protecting traffic on the other interfaces.
Next-Hop-Style Service Sets
Packet direction that is determined by the NAT engine is used to route packets to the
NAT engine. If you use the inside-interface statement to route traffic, then the packet
direction is input. If you use the outside-interface statement to direct packets to the NAT
engine, then the packet direction is output.
The interface to which you apply the service sets affects the match direction. For example,
apply the following configuration:
si-0/0/0 unit 1 service-domain inside;

si-0/0/0 unit 2 service-domain outside;
If you configure match-direction input, you include the following statements:
[edit]
services service-set test1 next-hop-service inside-service-interface si-0/0/0.1;
services service-set test1 next-hop-service outside-service-interface si-0/0/0.2;
services ipsec-vpn rule test-ipsec-rule match-direction input;
routing-options static route 10.0.0.0/24 next-hop si-0/0/0.1;
The essential difference between the two configurations is the change in the match
direction and the static routes’ next hop, pointing to either the NAT engine’s inside or
outside interface.

Documentation

Service Filters in ACX Series
When you apply a service set to the traffic at an inline services interface, you can optionally
use service filters to refine the target of the set of services and also to process traffic.
Service filters enable you to manipulate traffic by performing packet filtering to a defined
set of services on an inline services interface before the traffic is delivered to its destination.
In ACX Series routers, you can apply a service filter to traffic before packets are accepted
for input service processing.
NOTE: In ACX Series routers, the service-set filters are implemented using
ternary content addressable memory (TCAM) space. The allocated TCAM
space is shared by the bridge family filter. The same space is shared by the
NNI-Address-Overload-Reverse filter (for each service set that is configured
with address overloading, the internal filters are configured for the given
overloaded IP address and the port range to redirect the matched reverse-nat
(public to private) traffic to the service). From a scaling perspective, the
allocated 124 hardware TCAM entries are shared by these features and the
allocation of TCAM entries works on a first-come-first-serve basis mode.

Documentation
page 1007

Guidelines for Applying Service Filters
• Restrictions for Inline Services Interfaces on page 1036

• Statement Hierarchy for Applying Service Filters on page 1036
• Associating Service Rules with Inline Services Interfaces on page 1037
• Filtering Traffic Before Accepting Packets for Service Processing on page 1037
Restrictions for Inline Services Interfaces

You can apply a service filter to IPv4 traffic associated with a service set at an inline
services interface only.
ACX Series routers do not support post-service filters.
Statement Hierarchy for Applying Service Filters

You can enable packet filtering of IPv4 traffic before a packet is accepted for input service
processing. To do this, apply a service filter to the inline services interface input in
conjunction with an interface service set.
The following configuration shows the hierarchy levels at which you can apply the service
filters to inline services interfaces:
[edit]
interfaces {
interface-name {
unit unit-number {
service {
input {
service-set service-set-name service-filter service-filter-name;
}
output {
[ service-set service-set-name <service-filter filter-name> ];
}
}
}
}
}
}

Associating Service Rules with Inline Services Interfaces

To define and group the service rules be applied to an inline services interface, you define
an interface service set by including the service-set service-set-name statement at the
[edit services] hierarchy level.
To apply an interface service set to the input of an inline services interface, you include
the service-set service-set-name at the following hierarchy levels:
• [edit interfaces interface-name unit unit-number input]
Filtering Traffic Before Accepting Packets for Service Processing

To filter IPv4 traffic before accepting packets for input service processing, include the
service-set service-set-name service-filter service-filter-name at the following hierarchy
level:
• [edit interfaces interface-name unit unit-number family inet service input]
For the service-set-name, specify a service set configured at the [edit services service-set]
hierarchy level.
The service set retains the input interface information even after services are applied, so
that functions such as filter-class forwarding that depend on input interface information
continue to work.
The following requirements apply to filtering inbound or outbound traffic before accepting
packets for service processing:
• You configure the same service set on the input and output sides of the interface.
• If you include the service-set statement without an optional service-filter definition,

Junos OS assumes that the match condition is true and selects the service set for
processing automatically.
• The service filter is applied only if a service set is configured and selected.
Related • Enabling Inline Services Interface on ACX Series on page 1008

Documentation

Service Filter Match Conditions for IPv4 Traffic
In ACX Series, service filters support only a subset of the stateless firewall filter match
conditions for IPv4 traffic. Table 65 on page 1038 describes the service filter match
conditions.
Table 65: Service Filter Match Conditions for IPv4 Traffic

Protocol
Match Condition Description Families
destination-address Match the IP destination address field. family inet

address
destination-port Match the UDP or TCP destination port field. family inet
number
You cannot specify both the port and destination-port match conditions
in the same term.
If you configure this match condition for IPv4 traffic, we recommend that
you also configure the protocol udp or protocol tcp match statement in
the same term to specify which protocol is being used on the port.
ip-options values Match the 8-bit IP option field, if present, to the specified value or list of family inet
values.
protocol number Match the IP protocol type field. family inet
source-address Match the IP source address. family inet

address
source-port number Match the UDP or TCP source port field. family inet
you also configure the protocol udp or protocol tcp match statement in
the same term to specify which protocol is being used on the port.
tcp-flags value Match one or more of the low-order 6 bits in the 8-bit TCP flags field in family inet
the TCP header.
you also configure the protocol tcp match statement in the same term to
specify that the TCP protocol is being used on the port.

Documentation

Service Filter Actions
ACX Series support different sets of terminating and nonterminating actions that you
can configure in a service filter term.
NOTE: Service filters do not support the next term action.
Table 66 on page 1039 describes the terminating actions you can configure in a service
filter term.
Table 66: Terminating Actions for Service Filters

Terminating Protocol
Action Description Families
service Direct the packet to service processing. inet
Table 67 on page 1039 describes the nonterminating actions you can configure in a service
filter term.
Table 67: Nonterminating Actions for Service Filters

Nonterminating Protocol
Action Description Families
accept Accept the packet. inet
count counter-name Count the packet in the named counter. inet
log Log the packet header information in a buffer within the Packet Forwarding Engine. inet
You can access this information by issuing the show firewall log command at the
command-line interface (CLI).
port-mirror Port-mirror the packet based on the specified family. inet

Documentation

Configuring Queuing and Scheduling on Inline Services Interface
To configure queuing and scheduling on an inline services interface, you need to include
scheduler-map statement at the [edit class-of-services interfaces si-/0/0/0] hierarchy
level.
scheduler-maps <scheduler-map-name>;
interfaces si-0/0/0; {
scheduler-map <scheduler-map-name>;
}
The queue-number 7 of the inline services interface has strict-high priority because the
timing packets received by ACX Series routers gets assigned to this queue. You can
explicitly override this strict-high priority by assigning an explicit scheduler for
queue-number 7 in the scheduler-map statement attached to inline services interface as
shown below:
class <class-name> queue-number 7;
}
interfaces {
si-0/0/0{
scheduler-map scheduler-map-name;
}
}
scheduler-maps {
<map-name> {
forwarding-class <class-name> scheduler <scheduler-name>;
}
}
schedulers {
<scheduler-name> {
priority low ;
}
}
The following are the CoS limitations for inline services:
• Inline services packets classified with packet loss priority as medium-high in the ingress
path are treated as high on the egress path.
• When both timing and NAT services are enabled on the router, you should not classify
NAT traffic into a forwarding class mapped with queue-number 7, because if you do
so, the performance of timing services can degrade.
• If a scheduler with queue-number 7 in the scheduler-map statement is attached to an

inline services interface, then the scheduler should be configured with strict priority,
else the timing performance can degrade.


Documentation
page 1007


CHAPTER 32
Configuring Firewall Filters
• Supported Standards for Filtering on page 1043

• Standard Firewall Filter Match Conditions and Actions on ACX Series Routers
• Standard Firewall Filter Match Conditions for IPv4 Traffic on ACX Series
Routers on page 1054
• Standard Firewall Filter Match Conditions for IPv6 Traffic on ACX Series
• Standard Firewall Filter Match Conditions for MPLS Traffic on ACX Series
• Standard Firewall Filter Terminating Actions on ACX Series Routers on page 1063
• Standard Firewall Filter Nonterminating Actions on ACX Series Routers on page 1064
• Standard Firewall Filter Match Conditions for CCC Firewall Family Filters on ACX Series
• Standard Firewall Filter Match Conditions for Bridge Family Firewall Filters on ACX
Series Routers on page 1068
• Firewall Filter Match Conditions for VPLS Traffic on page 1070
• Firewall Filter Support on Loopback Interface on page 1080
• Filter-Based Forwarding for Routing Instances on page 1081
• Forwarding Table Filters for Routing Instances on ACX Series Routers on page 1083
• Configuring Forwarding Table Filters on page 1083
Supported Standards for Filtering
The Junos OS supports the following RFCs related to filtering:
• RFC 792, Internet Control Message Protocol
• RFC 2460, Internet Protocol, Version 6 (IPv6)
• RFC 2474, Definition of the Differentiated Services (DS) Field
• RFC 2475, An Architecture for Differentiated Services

• RFC 2597, Assured Forwarding PHB Group
• RFC 3246, An Expedited Forwarding PHB (Per-Hop Behavior)
• RFC 4291, IP Version 6 Addressing Architecture
• RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version
6 (IPv6) Specification
NOTE: ACX Series routers do not support RFC 2460, RFC 4291, and RFC 4443
standards.
Related • Firewall Filters Overview

Documentation
• Service Filter Overview
• Simple Filter Overview
• Firewall Filters in Logical Systems Overview
Guidelines for Configuring Firewall Filters
• Statement Hierarchy for Configuring Firewall Filters on page 1044

• Firewall Filter Protocol Families on page 1045
• Firewall Filter Names and Options on page 1046
• Firewall Filter Terms on page 1046
• Firewall Filter Match Conditions on page 1046
• Firewall Filter Actions on page 1048
Statement Hierarchy for Configuring Firewall Filters

To configure a standard firewall filter, you can include the following statements. For an
IPv4 standard firewall filter, the family inet statement is optional. For an IPv6 standard
firewall filter, the family inet6 statement is mandatory.
firewall {
family family-name {
filter filter-name {
accounting-profile name;
instance-shared;
interface-specific;
physical-interface-filter;
term term-name {
filter filter-name;
}
term term-name {
from {
match-conditions;
ip-version ip-version {

Chapter 32: Configuring Firewall Filters
match-conditions;
protocol (tcp | udp) {
match conditions;
}
}
}
then {
actions;
}
}
}
}
}
You can include the firewall configuration at one of the following hierarchy levels:
• [edit]
• [edit logical-systems logical-system-name]
NOTE: For stateless firewall filtering, you must allow the output tunnel traffic
through the firewall filter applied to input traffic on the interface that is the
next-hop interface toward the tunnel destination. The firewall filter affects
only the packets exiting the router (or switch) by way of the tunnel.
Firewall Filter Protocol Families

A firewall filter configuration is specific to a particular protocol family. Under the firewall
statement, include one of the following statements to specify the protocol family for
which you want to filter traffic:
• family any—To filter protocol-independent traffic.
• family inet—To filter Internet Protocol version 4 (IPv4) traffic.
• family inet6—To filter Internet Protocol version 6 (IPv6) traffic.
• family mpls—To filter MPLS traffic.
• family vpls—To filter virtual private LAN service (VPLS) traffic.
• family ccc—To filter Layer 2 circuit cross-connection (CCC) traffic.
• family bridge—To filter Layer 2 bridging traffic for MX Series 3D Universal Edge Routers
only.
• family ethernet-switching—To filter Layer 2 (Ethernet) traffic.
The family family-name statement is required only to specify a protocol family other than
IPv4. To configure an IPv4 firewall filter, you can configure the filter at the [edit firewall]
hierarchy level without including the family inet statement, because the [edit firewall]
and [edit firewall family inet] hierarchy levels are equivalent.

NOTE: For bridge family filter, the ip-protocol match criteria is supported
only for IPv4 and not for IPv6. This is applicable for line cards that support
the Junos Trio chipset such as the MX 3D MPC line cards.
Firewall Filter Names and Options

Under the family family-name statement, you can include filter filter-name statements
to create and name firewall filters. The filter name can contain letters, numbers, and
hyphens (-) and be up to 64 characters long. To include spaces in the name, enclose the
entire name in quotation marks (“ ”).
At the [edit firewall family family-name filter filter-name] hierarchy level, the following
statements are optional:
• accounting-profile
• instance-shared (MX Series routers with Modular Port Concentrators (MPCS) only)
• interface-specific
• physical-interface-filter
Firewall Filter Terms

Under the filter filter-name statement, you can include term term-name statements to
create and name filter terms.
• You must configure at least one term in a firewall filter.
• You must specify a unique name for each term within a firewall filter. The term name
can contain letters, numbers, and hyphens (-) and can be up to 64 characters long.
To include spaces in the name, enclose the entire name in quotation marks (“ ”).
• The order in which you specify terms within a firewall filter configuration is important.
Firewall filter terms are evaluated in the order in which they are configured. By default,
new terms are always added to the end of the existing filter. You can use the insert
configuration mode command to reorder the terms of a firewall filter.
At the [edit firewall family family-name filter filter-name term term-name] hierarchy level,
the filter filter-name statement is not valid in the same term as from or then statements.
When included at this hierarchy level, the filter filter-name statement is used to nest
firewall filters.
Firewall Filter Match Conditions

Firewall filter match conditions are specific to the type of traffic being filtered.
With the exception of MPLS-tagged IPv4 or IPv6 traffic, you specify the term’s match
conditions under the from statement. For MPLS-tagged IPv4 traffic, you specify the term’s
IPv4 address-specific match conditions under the ip-version ipv4 statement and the
term’s IPv4 port-specific match conditions under the protocol (tcp | udp) statement.

For MPLS-tagged IPv6 traffic, you specify the term’s IPv6 address-specific match
conditions under the ip-version ipv6 statement and the term’s IPv6 port-specific match
conditions under the protocol (tcp | udp) statement.
Table 68 on page 1047 describes the types of traffic for which you can configure firewall
filters.
Table 68: Firewall Filter Match Conditions by Protocol Family

Traffic Type Hierarchy Level at Which Match Conditions Are Specified
Protocol-independent [edit firewall family any filter filter-name term term-name]
For the complete list of match conditions, see Firewall Filter Match Conditions for
Protocol-Independent Traffic.
IPv4 [edit firewall family inet filter filter-name term term-name]
For the complete list of match conditions, see Firewall Filter Match Conditions for IPv4 Traffic.
IPv6 [edit firewall family inet6 filter filter-name term term-name]
For the complete list of match conditions, see Firewall Filter Match Conditions for IPv6 Traffic.
MPLS [edit firewall family mpls filter filter-name term term-name]
For the complete list of match conditions, see Firewall Filter Match Conditions for MPLS Traffic.
IPv4 addresses [edit firewall family mpls filter filter-name term term-name ip-version ipv4 ]
in MPLS flows
For the complete list of match conditions, see Firewall Filter Match Conditions for MPLS-Tagged
IPv4 or IPv6 Traffic.
IPv4 ports in MPLS flows [edit firewall family mpls filter filter-name term term-name ip-version ipv4 protocol (tcp | udp)]
IPv6 addresses [edit firewall family mpls filter filter-name term term-name ip-version ipv6 ]
in MPLS flows
IPv6 ports in MPLS flows [edit firewall family mpls filter filter-name term term-name ip-version ipv6 protocol (tcp | udp)]
VPLS [edit firewall family vpls filter filter-name term term-name]
For the complete list of match conditions, see “Firewall Filter Match Conditions for VPLS Traffic”
on page 1070.
Layer 2 CCC [edit firewall family ccc filter filter-name term term-name]
For the complete list of match conditions, see Firewall Filter Match Conditions for Layer 2 CCC Traffic.

Table 68: Firewall Filter Match Conditions by Protocol Family (continued)

Layer 2 Bridging [edit firewall family bridge filter filter-name term term-name]
(MX Series routers and [edit firewall family ethernet-switching filter filter-name term term-name] (for EX Series switches
EX Series switches only) only)
For the complete list of match conditions, see Firewall Filter Match Conditions for Layer 2 Bridging
Traffic.
If you specify an IPv6 address in a match condition (the address, destination-address, or

source-address match conditions), use the syntax for text representations described in
RFC 4291, IP Version 6 Addressing Architecture. For more information about IPv6 addresses,
see “IPv6 Overview” on page 530 and Supported IPv6 Standards.
Firewall Filter Actions

Under the then statement for a firewall filter term, you can specify the actions to be taken
on a packet that matches the term.
Table 69 on page 1048 summarizes the types of actions you can specify in a firewall filter
term.
Table 69: Firewall Filter Action Categories

Type of Action Description Comment
Terminating Halts all evaluation of a firewall filter for a specific packet. See Firewall Filter Terminating Actions.
The router (or switch) performs the specified action, and
no additional terms are used to examine the packet.
You can specify only one terminating action in a firewall

filter term. You can, however, specify one terminating
action with one or more nonterminating actions in a single
term. For example, within a term, you can specify accept
with count and syslog. Regardless of the number of terms
that contain terminating actions, once the system
processes a terminating action within a term, processing
of the entire firewall filter halts.
Nonterminating Performs other functions on a packet (such as All nonterminating actions include an implicit
incrementing a counter, logging information about the accept action. This accept action is carried out
packet header, sampling the packet data, or sending if no other terminating action is configured in
information to a remote host using the system log the same term.
functionality), but any additional terms are used to
examine the packet. See Firewall Filter Nonterminating Actions.

Table 69: Firewall Filter Action Categories (continued)

Flow control For standard firewall filters only, the next term action You cannot configure the next term action with
directs the router (or switch) to perform configured actions a terminating action in the same filter term.
on the packet and then, rather than terminate the filter, However, you can configure the next term action
use the next term in the filter to evaluate the packet. If the with another nonterminating action in the same
next term action is included, the matching packet is filter term.
evaluated against the next term in the firewall filter.
Otherwise, the matching packet is not evaluated against A maximum of 1024 next term actions are
subsequent terms in the firewall filter. supported per standard firewall filter
configuration. If you configure a standard
For example, when you configure a term with the firewall filter that exceeds this limit, your
nonterminating action count, the term’s action changes candidate configuration results in a commit
from an implicit discard to an implicit accept. The next term error.
action forces the continued evaluation of the firewall filter.
Related • Guidelines for Applying Standard Firewall Filters on page 1049

Documentation
• Understanding How to Use Standard Firewall Filters
Guidelines for Applying Standard Firewall Filters
• Applying Firewall Filters Overview on page 1049

• Statement Hierarchy for Applying Firewall Filters on page 1050
• Restrictions on Applying Firewall Filters on page 1051
Applying Firewall Filters Overview

You can apply a standard firewall filter to a loopback interface on the router or to a
physical or logical interface on the router. You can apply a firewall filter to a single interface
or to multiple interfaces on the router.Table 70 on page 1049 summarizes the behavior of
firewall filters based on the point to which you attach the filter.
Table 70: Firewall Filter Behavior by Filter Attachment Point

Filter Attachment Point Filter Behavior
Loopback interface The router’s loopback interface, lo0, is the interface to the Routing Engine and carries no data
packets. When you apply a firewall filter to the loopback interface, the filter evaluates the local
packets received or transmitted by the Routing Engine.
NOTE:
• ACX5048 and ACX5096 routers do not support the evaluation of packets transmitted by the
Routing engine for loopback interface filter.
Physical interface or When you apply a filter to a physical interface on the router or to a logical interface (or member
logical interface of an aggregated Ethernet bundle defined on the interface), the filter evaluates all data packet
that pass through that interface.

Table 70: Firewall Filter Behavior by Filter Attachment Point (continued)

Filter Attachment Point Filter Behavior
Multiple interfaces You can use the same firewall filter one or more times.
On M Series routers, except the M120 and M320 routers, if you apply a firewall filter to multiple
interfaces, the filter acts on the sum of traffic entering or exiting those interfaces.
On T Series, M120, M320, and MX Series routers, interfaces are distributed among multiple
packet-forwarding components. On these routers, you can configure firewall filters and service
filters that, when applied to multiple interfaces, act on the individual traffic streams entering or
exiting each interface, regardless of the sum of traffic on the multiple interfaces.
For more information, see Interface-Specific Firewall Filter Instances Overview.
Single interface with For interfaces hosted on the following hardware only, you can attach a protocol-independent
protocol-independent (family any) firewall filter and a protocol-specific (family inet or family inet6) firewall filter
and protocol-specific simultaneously. The protocol-independent firewall executes first.
firewall filters attached
• ACX Series Universal Access Routers
• Flexible PIC Concentrators (FPCs) in M7i and M10i Multiservice Edge Routers
• Modular Interface Cards (MICs) and Modular Port Concentrators (MPCs) in MX Series 3D
Universal Edge Routers
• T Series Core Routers
NOTE:
Interfaces hosted on the following hardware do not support protocol-independent firewall filters:
• Forwarding Engine Boards (FEBs) in M120 routers

• Enhanced III FPCs in M320 routers
• FPC2 and FPC3 modules in MX Series routers
• Dense Port Concentrators (DPCs) in MX Series routers
• PTX Series Packet Transport Routers
Statement Hierarchy for Applying Firewall Filters

To apply a standard firewall filter to a logical interface, configure the filter statement for
the logical interface defined under either the [edit] or [edit logical-systems
logical-system-name] hierarchy level. Under the filter statement, you can include one or
more of the following statements: group group-number, input filter-name, input-list
filter-name, output filter-name, or output-list filter-name. The hierarchy level at which you
attach the filter statement depends on the filter type and device type you are configuring.
Protocol-Independent Firewall Filters on MX Series Routers

To apply a protocol-independent firewall filter to a logical interface on an MX Series
router, configure the filter statement directly under the logical unit:
interfaces {
interface-name {
filter {
group group-number;
input filter-name;

input-list [ filter-names ];
output filter-name;
output-list [ filter-names ];
}
}
}
}
All Other Firewall Filters on Logical Interfaces

To apply a standard firewall filter to a logical interface for all cases other than a
protocol-independent filter on an MX Series router, configure the filter statement under
the protocol family:
interfaces {
interface-name {
...
filter {
group group-number;
input filter-name;
input-list [ filter-names ];
output filter-name;
output-list [ filter-names ];
}
}
}
}
}
Restrictions on Applying Firewall Filters

• Number of Input and Output Filters Per Logical Interface on page 1051
• MPLS and Layer 2 CCC Firewall Filters in Lists on page 1052
• Layer 2 CCC Firewall Filters on MX Series Routers and EX Series Switches on page 1052
Number of Input and Output Filters Per Logical Interface
Input filters—Although you can use the same filter multiple times, you can apply only
one input filter or one input filter list to an interface.
• To specify a single firewall filter to be used to evaluate packets received on the interface,
include the input filter-name statement in the filter stanza.
• To specify an ordered list of firewall filters to be used to evaluate packets received on

the interface, include the input-list [ filter-names ] statement in the filter stanza. You
can specify up to 16 firewall filters for the filter input list.
Output filters—Although you can use the same filter multiple times, you can apply only
one output filter or one output filter list to an interface.
• To specify a single firewall filter to be used to evaluate packets transmitted on the

interface, include the output filter-name statement in the filter stanza.

• To specify an ordered list of firewall filters to be used to evaluate packets transmitted

on the interface, include the output-list [ filter-names ] statement in the filter stanza.
You can specify up to 16 firewall filters in a filter output list.
MPLS and Layer 2 CCC Firewall Filters in Lists
The input-list filter-names and output-list filter-names statements for firewall filters for
the ccc and mpls protocol families are supported on all interfaces with the exception of
the following:
• Management interfaces and internal Ethernet interfaces (fxp or em0)
• Loopback interfaces (lo0)
• USB modem interfaces (umd)
Layer 2 CCC Firewall Filters on MX Series Routers and EX Series Switches
Only on MX Series routers and EX Series switches, you cannot apply a Layer 2 CCC
stateless firewall filter (a firewall filter configured at the [edit firewall filter family ccc]
hierarchy level) as an output filter. On MX Series routers and EX Series switches, firewall
filters configured for the family ccc statement can be applied only as input filters.
Related • family (Firewall)

Documentation
• family (Interfaces)
• filter (Applying to a Logical Interface)
• filter (Configuring)
• Understanding How to Use Standard Firewall Filters
Standard Firewall Filter Match Conditions and Actions on ACX Series Routers Overview
On ACX Series Universal Access Routers, you can configure firewall filters to filter packets
and to perform an action on packets that match the filter. The match conditions specified
to filter the packets are specific to the type of traffic being filtered.
NOTE: On ACX Series routers, the filter for the exiting traffic (egress filter)
can be applied only for interface-specific instances of the firewall filter.
Table 71 on page 1053 describes the types of traffic for which you can configure standard
stateless firewall filters.

Table 71: Standard Firewall Filter Match Conditions by Protocol Family for ACX Series Routers
Protocol-independent [edit firewall family any filter filter-name term term-name]
No match conditions are supported for this traffic type on ACX

Series routers.
IPv4 [edit firewall family inet filter filter-name term term-name
For the complete list of match conditions, see “Standard Firewall

Filter Match Conditions for IPv4 Traffic on ACX Series Routers”
on page 1054.
MPLS [edit firewall family mpls filter filter-name term term-name]
For the complete list of match conditions, see “Standard Firewall

Filter Match Conditions for MPLS Traffic on ACX Series Routers”
on page 1062.
Layer 2 CCC [edit firewall family ccc filter filter-name term term-name]
No match conditions are supported for this traffic type on ACX

Series routers.
Bridge [edit firewall family bridge filter filter-name term term-name]
[edit firewall family ethernet-switching filter filter-name term

term-name] (Applicable to ACX5048 and ACX5096 routers only.)
Under the then statement for a standard stateless firewall filter term, you can specify
the actions to be taken on a packet that matches the term.
Table 72 on page 1053 summarizes the types of actions you can specify in a standard
stateless firewall filter term.
Table 72: Standard Firewall Filter Action Categories for ACX Series Routers
Terminating Halts all evaluation of a firewall filter for a specific See “Standard Firewall Filter
packet. The router performs the specified action, Terminating Actions on ACX Series
and no additional terms are used to examine the Routers” on page 1063.
packet.
You can specify only one terminating action in a

standard firewall filter. You can, however, specify
one terminating action with one or more
nonterminating actions in a single term. For
example, within a term, you can specify accept
with count and syslog.

Table 72: Standard Firewall Filter Action Categories for ACX Series Routers (continued)
Nonterminating Performs other functions on a packet (such as See “Standard Firewall Filter
incriminating a counter, logging information about Nonterminating Actions on ACX
the packet header, sampling the packet data, or Series Routers” on page 1064.
sending information to a remote host using the
system log functionality), but any additional terms
are used to examine the packet.
Related • Guidelines for Configuring Firewall Filters on page 1044

Documentation
• Interface-Specific Firewall Filter Instances Overview
Standard Firewall Filter Match Conditions for IPv4 Traffic on ACX Series Routers
On ACX Series routers, you can configure a standard stateless firewall filter with match
conditions for IP version 4 (IPv4) traffic (family inet). Table 73 on page 1054 describes the
match conditions you can configure at the [edit firewall family inet filter filter-name term
term-name from] hierarchy level.
Table 73: Standard Firewall Filter Match Conditions for IPv4 Traffic on ACX Series Routers
Match Condition Description
destination-address address Match the IPv4 destination address field.
NOTE: On ACX Series routers, you can specify only one destination address. A list of IPv4
destination addresses is not supported.
destination-port number Match the UDP or TCP destination port field.
If you configure this match condition, we recommend that you also configure the protocol udp
or protocol tcp match statement in the same term to specify which protocol is being used on
the port.
NOTE: On ACX Series routers, you can specify only one destination port number. A list of port
numbers is not supported.
In place of the numeric value, you can specify one of the following text synonyms (the port
numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68), bootps (67), cmd (514),
cvspserver (2401), dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79),
ftp (21), ftp-data (20), http (80), https (443), ident (113), imap (143), kerberos-sec (88),
klogin (543), kpasswd (761), krb-prop (754), krbupdate (760), kshell (544), ldap (389), ldp (646),
login (513), mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-dgm (138),
netbios-ns (137), netbios-ssn (139), nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110),
pptp (1723), printer (515), radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25),
snmp (161), snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514),
tacacs (49), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or
xdmcp (177).
destination-prefix-list Match IP destination prefixes in named list.

Table 73: Standard Firewall Filter Match Conditions for IPv4 Traffic on ACX Series
Routers (continued)
dscp number Match the Differentiated Services code point (DSCP). The DiffServ protocol uses the
type-of-service (ToS) byte in the IP header. The most significant 6 bits of this byte form the
DSCP. For more information, see “Understanding How Behavior Aggregate Classifiers Prioritize
Trusted Traffic” on page 950.
You can specify a numeric value from 0 through 63. To specify the value in hexadecimal form,
include 0x as a prefix. To specify the value in binary form, include b as a prefix.
In place of the numeric value, you can specify one of the following text synonyms (the field
values are also listed):
• RFC 3246, An Expedited Forwarding PHB (Per-Hop Behavior), defines one code point: ef (46).
• RFC 2597, Assured Forwarding PHB Group, defines 4 classes, with 3 drop precedences in
each class, for a total of 12 code points:
• af11 (10), af12 (12), af13 (14)
• af21 (18), af22 (20), af23 (22)
• af31 (26), af32 (28), af33 (30)
• af41 (34), af42 (36), af43 (38)
fragment-flags number (Ingress only) Match the three-bit IP fragmentation flags field in the IP header.
In place of the numeric field value, you can specify one of the following keywords (the field
values are also listed): dont-fragment (0x4), more-fragments (0x2), or reserved (0x8).
icmp-code number Match the ICMP message code field.
If you configure this match condition, we recommend that you also configure the protocol icmp
match condition in the same term.
If you configure this match condition, you must also configure the icmp-type message-type
match condition in the same term. An ICMP message code provides more specific information
than an ICMP message type, but the meaning of an ICMP message code is dependent on the
associated ICMP message type.
values are also listed). The keywords are grouped by the ICMP type with which they are
associated:
• parameter-problem: ip-header-bad (0), required-option-missing (1)

• redirect: redirect-for-host (1), redirect-for-network (0), redirect-for-tos-and-host (3),
redirect-for-tos-and-net (2)
• time-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)
• unreachable: communication-prohibited-by-filtering (13), destination-host-prohibited (10),
destination-host-unknown (7), destination-network-prohibited (9),
destination-network-unknown (6), fragmentation-needed (4), host-precedence-violation (14),
host-unreachable (1), host-unreachable-for-TOS (12), network-unreachable (0),
network-unreachable-for-TOS (11), port-unreachable (3), precedence-cutoff-in-effect (15),
protocol-unreachable (2), source-host-isolated (8), source-route-failed (5)

Routers (continued)
icmp-type number Match the ICMP message type field.
If you configure this match condition, we recommend that you also configure the protocol icmp
match condition in the same term.
values are also listed): echo-reply (0), echo-request (8), info-reply (16), info-request (15),
mask-request (17), mask-reply (18), parameter-problem (12), redirect (5),
router-advertisement (9), router-solicit (10), source-quench (4), time-exceeded (11),
timestamp (13), timestamp-reply (14), or unreachable (3).
ip-options values Match the 8-bit IP option field, if present, to the specified value.
ACX Series routers support only the ip-options_any match condition, which ensures that the
packets are sent to the Packet Forwarding Engine for processing.
NOTE: On ACX Series routers, you can specify only one IP option value. Configuring multiple
values is not supported.
precedence Match the IP precedence field.

ip-precedence-field
In place of the numeric field value, you can specify one of the following text synonyms (the
field values are also listed): critical-ecp (0xa0), flash (0x60), flash-override (0x80),
immediate (0x40), internet-control (0xc0), net-control (0xe0), priority (0x20), or routine (0x00).
You can specify precedence in hexadecimal, binary, or decimal form.
protocol number Match the IP protocol type field. In place of the numeric value, you can specify one of the
following text synonyms (the field values are also listed): ah (51), dstopts (60), egp (8), esp (50),
fragment (44), gre (47), hop-by-hop (0), icmp (1), icmp6 (58), icmpv6 (58), igmp (2), ipip (4),
ipv6 (41), ospf (89), pim (103), rsvp (46), sctp (132), tcp (6), udp (17), or vrrp (112).
source-address address Match the IPv4 address of the source node sending the packet.
source-port number Match the UDP or TCP source port field.
If you configure this match condition for IPv4 traffic, we recommend that you also configure
the protocol udp or protocol tcp match statement in the same term to specify which protocol
is being used on the port.
In place of the numeric value, you can specify one of the text synonyms listed with the
destination-port number match condition.
source-prefix-list Match IP source prefixes in named list.

Routers (continued)
tcp-flags value Match one or more of the low-order 6 bits in the 8-bit TCP flags field in the TCP header.
To specify individual bit fields, you can specify the following text synonyms or hexadecimal
values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in
all packets sent after the initial packet.
You can string together multiple flags using the bit-field logical operators.
For combined bit-field match conditions, see the tcp-initial match conditions.
If you configure this match condition, we recommend that you also configure the protocol tcp
match statement in the same term to specify that the TCP protocol is being used on the port.
tcp-initial Match the initial packet of a TCP connection. This is an alias for tcp-flags "(!ack & syn)".
This condition does not implicitly check that the protocol is TCP. If you configure this match
condition, we recommend that you also configure the protocol tcp match condition in the same
term.
ttl number Match the IPv4 time-to-live number. Specify a TTL value or a range of TTL values. For number,
you can specify one or more values from 2 through 255.

Documentation
on page 1052
Standard Firewall Filter Match Conditions for IPv6 Traffic on ACX Series Routers
You can configure a firewall filter with match conditions for Internet Protocol version 6
(IPv6) traffic (family inet6). Table 74 on page 1058 describes the match conditions you can
configure at the [edit firewall family inet6 filter filter-name term term-name from] hierarchy
level.

Table 74: Firewall Filter Match Conditions for IPv6 Traffic
destination-address address Match the IPv6 destination address field.
destination-port number Match the UDP or TCP destination port field.
You cannot specify both the port and destination-port match conditions in the same term.
If you configure this match condition, we recommend that you also configure the next-header
udp or next-header tcp match condition in the same term to specify which protocol is being used
on the port.
tacacs (49), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
extension-headers Match an extension header type that is contained in the packet by identifying a Next Header
header-type value.
In the first fragment of a packet, the filter searches for a match in any of the extension header
types. When a packet with a fragment header is found (a subsequent fragment), the filter only
searches for a match of the next extension header type because the location of other extension
headers is unpredictable.
In place of the numeric value, you can specify one of the following text synonyms (the field values
are also listed): ah (51), destination (60), esp (50), fragment (44), hop-by-hop (0), mobility (135),
or routing (43).
To match any value for the extension header option, use the text synonym any.
NOTE: Only the first extension header of the IPv6 packet can be matched. L4 header beyond
one IPv6 extension header will be matched.
hop-limit hop-limit Match the hop limit to the specified hop limit or set of hop limits. For hop-limit, specify a single
value or a range of values from 0 through 255.

Table 74: Firewall Filter Match Conditions for IPv6 Traffic (continued)
icmp-code message-code Match the ICMP message code field.
icmp or next-header icmp6 match condition in the same term.
If you configure this match condition, you must also configure the icmp-type message-type match
condition in the same term. An ICMP message code provides more specific information than an
ICMP message type, but the meaning of an ICMP message code is dependent on the associated
ICMP message type.
are also listed). The keywords are grouped by the ICMP type with which they are associated:
• parameter-problem: ip6-header-bad (0), unrecognized-next-header (1), unrecognized-option

(2)
• time-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)
• destination-unreachable: administratively-prohibited (1), address-unreachable (3),
no-route-to-destination (0), port-unreachable (4)
icmp-type message-type Match the ICMP message type field.
icmp or next-header icmp6 match condition in the same term.
are also listed): certificate-path-advertisement (149), certificate-path-solicitation (148),
destination-unreachable (1), echo-reply (129), echo-request (128),
home-agent-address-discovery-reply (145), home-agent-address-discovery-request (144),
inverse-neighbor-discovery-advertisement (142), inverse-neighbor-discovery-solicitation (141),
membership-query (130), membership-report (131), membership-termination (132),
mobile-prefix-advertisement-reply (147), mobile-prefix-solicitation (146),
neighbor-advertisement (136), neighbor-solicit (135), node-information-reply (140),
node-information-request (139), packet-too-big (2), parameter-problem (4),
private-experimentation-100 (100), private-experimentation-101 (101), private-experimentation-200
(200), private-experimentation-201 (201), redirect (137), router-advertisement (134),
router-renumbering (138), router-solicit (133), or time-exceeded (3).
For private-experimentation-201 (201), you can also specify a range of values within square
brackets.

next-header header-type Match the first 8-bit Next Header field in the packet. Support for the next-header firewall match
condition is available in Junos OS Release 13.3R6 and later.
For IPv6, we recommend that you use the payload-protocol term rather than the next-header
term when configuring a firewall filter with match conditions. Although either can be used,
payload-protocol provides the more reliable match condition because it uses the actual payload
protocol to find a match, whereas next-header simply takes whatever appears in the first header
following the IPv6 header, which may or may not be the actual protocol. In addition, if next-header
is used with IPv6, the accelerated filter block lookup process is bypassed and the standard filter
used instead.
are also listed): ah (51), dstops (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0),
icmp (1), icmp6 (58), icmpv6 (58), igmp (2), ipip (4), ipv6 (41), mobility (135), no-next-header (59),
ospf (89), pim (103), routing (43), rsvp (46), sctp (132), tcp (6), udp (17), or vrrp (112).
NOTE: next-header icmp6 and next-header icmpv6 match conditions perform the same function.
next-header icmp6 is the preferred option. next-header icmpv6 is hidden in the Junos OS CLI.
source-address address Match the IPv6 address of the source node sending the packet.
source-port number Match the UDP or TCP source port field.
You cannot specify the port and source-port match conditions in the same term.
udp or next-header tcp match condition in the same term to specify which protocol is being used
on the port.
In place of the numeric value, you can specify one of the text synonyms listed with the
destination-port number match condition.
tcp-flags flags Match one or more of the low-order 6 bits in the 8-bit TCP flags field in the TCP header.
To specify individual bit fields, you can specify the following text synonyms or hexadecimal values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in all
packets sent after the initial packet.
For combined bit-field match conditions, see the tcp-established and tcp-initial match conditions.
If you configure this match condition, we recommend that you also configure the next-header tcp
match condition in the same term to specify that the TCP protocol is being used on the port.

tcp-initial Match the initial packet of a TCP connection. This is a text synonym for tcp-flags "(!ack & syn)".
This condition does not implicitly check that the protocol is TCP. If you configure this match
condition, we recommend that you also configure the next-header tcp match condition in the
same term.
traffic-class number Match the 8-bit field that specifies the class-of-service (CoS) priority of the packet.
This field was previously used as the type-of-service (ToS) field in IPv4.
are also listed):
• RFC 2597, Assured Forwarding PHB Group, defines 4 classes, with 3 drop precedences in each
class, for a total of 12 code points:
• af11 (10), af12 (12), af13 (14)
• af21 (18), af22 (20), af23 (22)
• af31 (26), af32 (28), af33 (30)
• af41 (34), af42 (36), af43 (38)

NOTE: If you specify an IPv6 address in a match condition (the address,

destination-address, or source-address match conditions), use the syntax for
text representations described in RFC 4291, IP Version 6 Addressing
Architecture. For more information about IPv6 addresses, see “IPv6 Overview”
on page 530 and Supported IPv6 Standards.
The following is a sample firewall family inet6 configuration:
user@host# show firewall family inet6

filter ipv6-filter {
term t1 {
from {
source-address {
2001:0000:0020:0020:0000:0000:0000:0150/128;
}
destination-address {
2001:0000:0040:0040:0000:0000:0000:0150/128;
}
next-header tcp;
source-port 1000;
extension-header dstopts;
traffic-class ef;
tcp-flags 0x20;
hop-limit 254;
}
then count ipv6-t1-count;
}
term t2 {
from {
icmp-type neighbor-solicit;
}
then count ipv6-t2-count;
}
}

Documentation
• Firewall Filter Terminating Actions
• Firewall Filter Nonterminating Actions
Standard Firewall Filter Match Conditions for MPLS Traffic on ACX Series Routers
On ACX Series routers, you can configure a standard stateless firewall filter with match
conditions for MPLS traffic (family mpls).
NOTE: The input-list filter-names and output-list filter-names statements for

firewall filters for the mpls protocol family are supported on all interfaces
with the exception of management interfaces and internal Ethernet interfaces
(fxp or em0), loopback interfaces (lo0), and USB modem interfaces (umd).

Table 75 on page 1063 describes the match conditions you can configure at the [edit firewall
family mpls filter filter-name term term-name from] hierarchy level.
Table 75: Standard Firewall Filter Match Conditions for MPLS Traffic on ACX Series Routers

exp number Experimental (EXP) bit number or range of bit numbers in the MPLS header. For number, you
can specify one or more values from 0 through 7 in decimal, binary, or hexadecimal format.

Documentation
on page 1052
Standard Firewall Filter Terminating Actions on ACX Series Routers
Standard stateless firewall filters support different sets of terminating actions for each
protocol family.
NOTE: ACX Series routers do not support the next term action.
Table 76 on page 1063 describes the terminating actions you can specify in a standard
firewall filter term.
Table 76: Terminating Actions for Standard Firewall Filters on ACX Series Routers
Terminating
Action Description Protocols
accept Accept the packet. • family any

• family inet
• family mpls
• family ccc
discard Discard a packet silently, without sending an Internet Control Message Protocol • family any
(ICMP) message. Discarded packets are available for logging and sampling. • family inet
• family mpls
• family ccc

Table 76: Terminating Actions for Standard Firewall Filters on ACX Series Routers (continued)
Terminating
Action Description Protocols
reject message-type Reject the packet and return an ICMPv4 or ICMPv6 message: family inet
• If no message type is specified, a destination-unreachable message is returned by

default.
• If tcp-reset is specified as the message type, tcp-reset is returned only if the packet
is a TCP packet. Otherwise, the administratively-prohibited message, which has a
value of 13, is returned.
• If any other message type is specified, that message is returned.
NOTE:
• Rejected packets can be sampled or logged if you configure the sample or syslog
action.
• This action is supported on ingress only.
The message-type option can have one of the following values: address-unreachable,
administratively-prohibited, bad-host-tos, bad-network-tos, beyond-scope,
fragmentation-needed, host-prohibited, host-unknown, host-unreachable,
network-prohibited, network-unknown, network-unreachable, no-route,
port-unreachable, precedence-cutoff, precedence-violation, protocol-unreachable,
source-host-isolated, source-route-failed, or tcp-reset.
routing-instance Direct the packet to the specified routing instance. • family inet
routing-instance-name

Documentation
on page 1052
Standard Firewall Filter Nonterminating Actions on ACX Series Routers
Standard stateless firewall filters support different sets of nonterminating actions for
each protocol family.
NOTE: ACX Series routers do not support the next term action.
ACX Series routers support log and syslog actions in ingress and egress
directions for family inet and family bridge.
Table 77 on page 1065 describes the nonterminating actions you can configure for a standard
firewall filter term.

Table 77: Nonterminating Actions for Standard Firewall Filters on ACX Series Routers
Nonterminating Action Description Protocol Families
count counter-name Count the packet in the named • family any

counter. • family inet
• family mpls
• family ccc
• family bridge
• family vpls
forwarding-class class-name Classify the packet based on • family inet

the specified forwarding class: • family inet6
• assured-forwarding • family mpls
• best-effort • family ccc
• expedited-forwarding • family bridge
• network-control • family vpls
NOTE: This action is

supported on ingress only.
log Log the packet header • family inet

information in a buffer within • family inet6
the Packet Forwarding Engine.
• family bridge
You can access this
information by issuing the
show firewall log command at
the command-line interface
(CLI).

supported on ingress and
egress. The action on egress is
not supported for family inet6.

Routers (continued)
loss-priority (high | medium-high | low) Set the packet loss priority • family any
(PLP) level. • family inet
You cannot also configure the • family inet6

three-color-policer • family mpls
nonterminating action for the • family ccc
same firewall filter term. These
• family bridge
two nonterminating actions
are mutually exclusive. • family vpls
You must include the tri-color

statement at the [edit
class-of-service] hierarchy
level to commit a PLP
configuration with any of the
four levels specified. If the
tri-color statement is not
enabled, you can configure
only the high and low levels.
This applies to all protocol
families.
For information about the

tri-color statement, see
Configuring and Applying
Tricolor Marking Policers. For
information about using
behavior aggregate (BA)
classifiers to set the PLP level
of incoming packets, see
Understanding How Forwarding
Classes Assign Classes to
Output Queues.

policer policer-name Name of policer to use to • family any

rate-limit traffic. • family inet
• family inet6
• family mpls
• family ccc
• family bridge
• family vpls

Routers (continued)
port-mirror Port-mirror the packet based family inet

on the specified family.

ACX5048 and ACX5096

routers do not support
port-mirror.
syslog Log the packet to the system • family inet

log file. • family inet6
NOTE: This action is • family bridge

supported on ingress and
egress. The action on egress is
not supported for family inet6.
three-color-policer (single-rate | Police the packet using the • family any

two-rate) policer-name specified single-rate or • family inet
two-rate three-color policer.
• family inet6
You cannot also configure the • family mpls
loss-priority action for the
• family ccc
same firewall filter term. These
• family bridge
two actions are mutually
exclusive. • family vpls
traffic-class Set traffic-class code point family inet6


Documentation
on page 1052
Standard Firewall Filter Match Conditions for CCC Firewall Family Filters on ACX Series
Routers
Standard Firewall Filter Match Conditions for CCC Family Firewall Filters on ACX Series Routers
On ACX Series routers, you can configure a standard firewall filter with match conditions
for circuit cross-connection (CCC) traffic (family ccc).
Table 78 on page 1068 describes the match conditions you can configure at the [edit firewall
family ccc filter filter-name term term-name] hierarchy level.

Table 78: CCC Family Firewall Filter Match Conditions for ACX Series Routers
Field Description
destination-mac-address Destination MAC address
destination-port Matches TCP/UDP destination port
dscp Matches differentiated services (DiffServ) code point
icmp-code Matches ICMP message code
icmp-type Matches ICMP message type
ip-destination-address Matches destination IP address
ip-precedence Matches IP precedence value
ip-protocol Matches IP protocol type
ip-source-address Matches source IP address
learn-vlan-1p-priority Matches learned 802.1p VLAN priority
source-mac-address Source MAC address
source-port Matches TCP/UDP source port
user-vlan-1p-priority Matches user 802.1p VLAN priority
Related • show firewall

Documentation
• clear firewall
• interface-specific (Firewall Filters)
Standard Firewall Filter Match Conditions for Bridge Family Firewall Filters on ACX
Series Routers
Standard Firewall Filter Match Conditions for Bridge Family Firewall Filters on ACX Series
Routers
Bridge family firewall filters can be configured at the IFL-family level on ACX series routers.
Bridge family filters are used to match the L2 bridge flows based on the supported
Layer2/Layer3 fields and take firewall action. The maximum number of terms supported
for bridge firewall filters on ACX Series routers is 124.
Table 79 on page 1069 shows the match conditions supported for bridge family filters.

Table 79: Bridge Family Firewall Filter Match Conditions for ACX Series Routers
apply-groups Set the groups from which to inherit configuration data
apply-groups-except Set which groups will not broadcast configuration data
destination-mac-address Set the destination MAC address
destination-port Match the TCP/UDP destination port
dscp Match the Differentiated Services (DiffServ) code point
ether-type Match the Ethernet type
icmp-code Match a ICMP message code
icmp-type Match a ICMP message type
interface-group Match an interface group
ip-destination-address Match an IP destination address
ip-precedence Match an IP precedence value
ip-protocol Match an IP protocol type
ip-source-address Match an IP source address
learn-vlan-1p-priority Match the learned 802.1p VLAN Priority
learn-vlan-dei Match user VLAN ID DEI bit
learn-vlan-id Match a learnt VLAN ID
source-mac-address Set the source MAC address
source-port Match a TCP/UDP source port
user-vlan-1p-priority Match user 802.1p VLAN Priority
user-vlan-id Match a user VLAN ID
vlan-ether-type Match a VLAN Ethernet type
Table 80 on page 1070 shows the action fields supported.

Table 80: Bridge Family Firewall Filter Action Fields for ACX Series Routers
Action Field Description
accept Accept the packet
count Count the packet in the named counter
discard Discard the packet
forwarding-class Classify packet to forwarding class
loss-priority Packet’s loss priority
log Log the packet header information in a buffer within the Packet
Forwarding Engine. You can access this information by issuing
the show firewall log command at the command-line interface
(CLI).
policer Name of policer to use to rate-limit traffic
syslog Log the packet to the system log file.
three-color-policer Police the packet using a three-colo-policer
NOTE: Bridge family firewall filters can be applied as an output filter on Layer
2 interfaces. When the Layer 2 interface is on a bridge-domain configured
with the vlan-id statement, ACX series routers can match the outer-vlan of
the packet using the user vlan-id match specified in the bridge family firewall
filter.
Related • show firewall

Documentation
• clear firewall
• interface-specific (Firewall Filters)
Firewall Filter Match Conditions for VPLS Traffic
In the from statement in the VPLS filter term, you specify conditions that the packet must
match for the action in the then statement to be taken. All conditions in the from
statement must match for the action to be taken. The order in which you specify match
conditions is not important, because a packet must match all the conditions in a term
for a match to occur.
If you specify no match conditions in a term, that term matches all packets.
An individual condition in a from statement can contain a list of values. For example, you
can specify numeric ranges. You can also specify multiple source addresses or destination

addresses. When a condition defines a list of values, a match occurs if one of the values
in the list matches the packet.
Individual conditions in a from statement can be negated. When you negate a condition,
you are defining an explicit mismatch. For example, the negated match condition for
forwarding-class is forwarding-class-except. If a packet matches a negated condition, it
is immediately considered not to match the from statement, and the next term in the
filter is evaluated, if there is one. If there are no more terms, the packet is discarded.
You can configure a firewall filter with match conditions for Virtual Private LAN Service
(VPLS) traffic (family vpls). Table 81 on page 1071 describes the match-conditions you can
configure at the [edit firewall family vpls filter filter-name term term-name from] hierarchy
level.
NOTE: Not all match conditions for VPLS traffic are supported on all routing
platforms or switching platforms. A number of match conditions for VPLS
traffic are supported only on MX Series 3D Universal Edge Routers.
In the VPLS documentation, the word router in terms such as PE router is used
to refer to any device that provides routing functions.
Table 81: Firewall Filter Match Conditions for VPLS Traffic
destination-mac-address Match the destination media access control (MAC) address of a VPLS packet.
address
destination-port number (MX Series routers and EX Series switches only) Match the UDP or TCP destination port field.
You cannot specify both the port and destination-port match conditions in the same term.
tacacs (49), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), or xdmcp (177).
destination-port-except (MX Series routers and EX Series switches only) Do not match on the TCP or UDP destination
number port field. You cannot specify both the port and destination-port match conditions in the same
term.
destination-prefix-list name (ACX Series routers, MX Series routers, and EX Series switches only) Match destination prefixes
in the specified list. Specify the name of a prefix list defined at the [edit policy-options prefix-list
prefix-list-name] hierarchy level.
NOTE: VPLS prefix lists support only IPv4 addresses. IPv6 addresses included in a VPLS prefix
list will be discarded.

Table 81: Firewall Filter Match Conditions for VPLS Traffic (continued)
destination-prefix-list name (MX Series routers and EX Series switches only) Do not match destination prefixes in the specified
except list. For more information, see the destination-prefix-list match condition.
dscp number (MX Series routers and EX Series switches only) Match the Differentiated Services code point
(DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most
significant 6 bits of this byte form the DSCP. For more information, see the “Understanding How
Behavior Aggregate Classifiers Prioritize Trusted Traffic” on page 950.
are also listed):
af11 (10), af12 (12), af13 (14),
af21 (18), af22 (20), af23 (22),
af31 (26), af32 (28), af33 (30),
af41 (34), af42 (36), af43 (38)
dscp-except number (MX Series routers and EX Series switches only) Do not match on the DSCP. For details, see the
dscp match condition.
ether-type values Match the 2-octet IEEE 802.3 Length/EtherType field to the specified value or list of values.
You can specify decimal or hexadecimal values from 0 through 65535 (0xFFFF). A value from
0 through 1500 (0x05DC) specifies the length of an Ethernet Version 1 frame. A value from 1536
(0x0600) through 65535 specifies the EtherType (nature of the MAC client protocol) of an
Ethernet Version 2 frame.
In place of the numeric value, you can specify one of the following text synonyms (the hexadecimal
values are also listed): aarp (0x80F3), appletalk (0x809B), arp (0x0806), ipv4 (0x0800),
ipv6 (0x86DD), mpls-multicast (0x8848), mpls-unicast (0x8847), oam (0x8902), ppp (0x880B),
pppoe-discovery (0x8863), pppoe-session (0x8864), or sna (0x80D5).
ether-type-except values Do not match the 2-octet Length/EtherType field to the specified value or list of values.
For details about specifying the values, see the ether-type match condition.

flexible-match-mask value bit-length Starting in Junos OS 14.2, flexible offset filters

are supported in firewall hierarchy
configurations.
Length of the data to be matched in bits, not

needed for string input (0..128)
bit-offset Bit offset after the (match-start + byte) offset

(0..7)
byte-offset Byte offset after the match start point
flexible-mask-name Select a flexible match from predefined

template field
mask-in-hex Mask out bits in the packet data to be matched
match-start Start point to match in packet
prefix Value data/string to be matched
flexible-match-range value bit-length Length of the data to be matched in bits (0..32)
bit-offset Bit offset after the (match-start + byte) offset

(0..7)
byte-offset Byte offset after the match start point
flexible-range-name Select a flexible match from predefined

template field
match-start Start point to match in packet
range Range of values to be matched
range-except Do not match this range of values
forwarding-class class Match the forwarding class. Specify assured-forwarding, best-effort, expedited-forwarding, or
network-control.
forwarding-class-except Do not match the forwarding class. For details, see the forwarding-class match condition.
class

interface interface-name Interface on which the packet was received. You can configure a match condition that matches
packets based on the interface on which they were received.
NOTE: If you configure this match condition with an interface that does not exist, the term
does not match any packet.
interface-group Match the logical interface on which the packet was received to the specified interface group or
group-number set of interface groups. For group-number, specify a single value or a range of values from 0 through
255.
To assign a logical interface to an interface group group-number, specify the group-number at the
[interfaces interface-name unit number family family filter group] hierarchy level.
For more information, see Filtering Packets Received on a Set of Interface Groups Overview.
NOTE: This match condition is not supported on T4000 Type 5 FPCs.
interface-group-except Do not match the logical interface on which the packet was received to the specified interface
group-name group or set of interface groups. For details, see the interface-group match condition.
NOTE: This match condition is not supported on T4000 Type 5 FPCs.
interface-set Match the interface on which the packet was received to the specified interface set.
interface-set-name
To define an interface set, include the interface-set statement at the [edit firewall] hierarchy level.
For more information, see Filtering Packets Received on an Interface Set Overview.
ip-address address (MX Series routers and EX Series switches only) 32-bit address that supports the standard syntax
for IPv4 addresses.
Note that when using this term, the match condition ether-type IPv4 must be defined on the
same term.
ip-destination-address (MX Series routers and EX Series switches only) 32-bit address that is the final destination node
address address for the packet.
Note that when using this term, the match condition ether-type IPv4 must be defined on the
same term.
ip-precedence (MX Series routers and EX Series switches only) IP precedence field. In place of the numeric field
ip-precedence-field value, you can specify one of the following text synonyms (the field values are also listed):
critical-ecp (0xa0), flash (0x60), flash-override (0x80), immediate (0x40), internet-control (0xc0),
net-control (0xe0), priority (0x20), or routine (0x00).
ip-precedence-except (MX Series routers and EX Series switches only) Do not match on the IP precedence field.
ip-precedence-field
ip-protocol number (MX Series routers and EX Series switches only) IP protocol field.
ip-protocol-except number (MX Series routers and EX Series switches only) Do not match on the IP protocol field.

ip-source-address address (MX Series routers and EX Series switches only) IP address of the source node sending the packet.
Note that when using this term, the match condition ether-type IPv4 must also be defined on
the same term.
ipv6-source-prefix-list (MX Series only) Match the IPv6 source address in a named-list.
named-list
ipv6-address address (MX Series and EX9200 only) 128-bit address that supports the standard syntax for IPv6
addresses. Starting in Junos OS 14.2, firewall family bridge IPv6 match criteria is supported on
MX Series and EX9200 switches.
ipv6-destination-address ((MX Series and EX9200 only) 128-bit address that is the final destination node address for this
address packet. Note that when using this term, the match condition ether-type IPv6 must be defined on
the same term.
ipv6-destination-prefix-list (MX Series only) Match the IPv6 destination addresses in a named-list.
named-list
ipv6-next-header protocol (MX Series only) Match IPv6 next header protocol type.
The following list shows the supported values for protocol:
• ah—IP Security authentication header

• dstopts—IPv6 destination options
• egp—Exterior gateway protocol
• esp—IPSec Encapsulating Security Payload
• fragment—IPv6 fragment header
• gre—Generic routing encapsulation
• hop-by-hop—IPv6 hop by hop options
• icmp—Internet Control Message Protocol
• icmp6—Internet Control Message Protocol Version 6
• igmp—Internet Group Management Protocol
• ipip—IP in IP
• ipv6—IPv6 in IP
• no-next-header—IPv6 no next header
• ospf—Open Shortest Path First
• pim—Protocol Independent Multicast
• routing—IPv6 routing header
• rsvp—Resource Reservation Protocol
• sctp—Stream Control Transmission Protocol
• tcp—Transmission Control Protocol
• udp—User Datagram Protocol
• vrrp—Virtual Router Redundancy Protocol
ipv6-next-header-except (MX Series only) Do not match the IPv6 next header protocol type.
protocol

ipv6-payload-protocol (MX Series only) Match IPv6 payload protocol type.

protocol
The following list shows the supported values for protocol:
• ah—IP Security authentication header

• dstopts—IPv6 destination options
• egp—Exterior gateway protocol
• esp—IPSec Encapsulating Security Payload
• fragment—IPv6 fragment header
• gre—Generic routing encapsulation
• hop-by-hop—IPv6 hop by hop options
• icmp—Internet Control Message Protocol
• icmp6—Internet Control Message Protocol Version 6
• igmp—Internet Group Management Protocol
• ipip—IP in IP
• ipv6—IPv6 in IP
• no-next-header—IPv6 no next header
• ospf—Open Shortest Path First
• pim—Protocol Independent Multicast
• routing—IPv6 routing header
• rsvp—Resource Reservation Protocol
• sctp—Stream Control Transmission Protocol
• tcp—Transmission Control Protocol
• udp—User Datagram Protocol
• vrrp—Virtual Router Redundancy Protocol
ipv6-payload-protocol-except (MX Series only) Do not match the IPv6 payload protocol.
protocol
ipv6-prefix-list named-list (MX Series only) Match the IPv6 address in a named-list.
ipv6-source-address address (MX Series only) 128-bit address that is the originating source node address for this packet.

ipv6-traffic-class number (MX Series only) Differentiated Services code point (DSCP). The DiffServ protocol uses the
type-of-service (ToS) byte in the IP header. The most significant 6 bits of this byte form the
DSCP. For more information, see “Understanding How Behavior Aggregate Classifiers Prioritize
Trusted Traffic” on page 950.
are also listed):
af11 (10), af12 (12), af13 (14),
af21 (18), af22 (20), af23 (22),
af31 (26), af32 (28), af33 (30),
af41 (34), af42 (36), af43 (38)
ipv6-traffic-class-except Do not match the DSCP number.

number
learn-vlan-1p-priority number (MX Series routers, M320 router, and EX Series switches only) Match on the IEEE 802.1p learned
VLAN priority bits in the provider VLAN tag (the only tag in a single-tag frame with 802.1Q VLAN
tags or the outer tag in a dual-tag frame with 802.1Q VLAN tags). Specify a single value or multiple
values from 0 through 7.
Compare with the user-vlan-1p-priority match condition.
NOTE: This match condition supports the presence of a control word for MX Series routers and
the M320 router.
learn-vlan-1p-priority-except (MX Series routers, M320 router, and EX Series switches only) Do not match on the IEEE 802.1p
number learned VLAN priority bits. For details, see the learn-vlan-1p-priority match condition.
the M320 router.
learn-vlan-dei (MX Series routers and EX Series switches only) Match the user VLAN ID drop eligability indicator
(DEI) bit.
learn-vlan-dei-except (MX Series routers and EX Series switches only) Do not match the user VLAN ID DEI bit.
learn-vlan-id number (MX Series routers and EX Series switches only) VLAN identifier used for MAC learning.
learn-vlan-id-except number (MX Series routers and EX Series switches only) Do not match on the VLAN identifier used for
MAC learning.

loss-priority level Packet loss priority (PLP) level. Specify a single level or multiple levels: low, medium-low,
medium-high, or high.
Supported on M120 and M320 routers; M7i and M10i routers with the Enhanced CFEB (CFEB-E);
and MX Series routers.
For IP traffic on M320, MX Series, and T Series routers with Enhanced II Flexible PIC Concentrators
(FPCs) and EX Series switches, you must include the tri-color statement at the [edit
class-of-service] hierarchy level to commit a PLP configuration with any of the four levels specified.
If the tri-color statement is not enabled, you can only configure the high and low levels. This
applies to all protocol families.
For information about the tri-color statement and about using behavior aggregate (BA) classifiers
to set the PLP level of incoming packets, see Understanding How Forwarding Classes Assign
Classes to Output Queues.
loss-priority-except level Do not match on the packet loss priority level. Specify a single level or multiple levels: low,
medium-low, medium-high, or high.
For information about using behavior aggregate (BA) classifiers to set the PLP level of incoming
packets, see “Understanding How Behavior Aggregate Classifiers Prioritize Trusted Traffic” on
page 950.
port number (MX Series routers and EX Series switches only) TCP or UDP source or destination port. You
cannot specify both the port match condition and either the destination-port or source-port match
condition in the same term.
port-except number (MX Series routers and EX Series switches only) Do not match on the TCP or UDP source or
destination port. You cannot specify both the port match condition and either the destination-port
or source-port match condition in the same term.
prefix-list name (MX Series routers and EX Series switches only) Match the destination or source prefixes in the
specified list. Specify the name of a prefix list defined at the [edit policy-options prefix-list
NOTE: VPLS prefix lists support only IPV4 addresses. IPV6 addresses included in a VPLS prefix
prefix-list name except (MX Series routers and EX Series switches only) Do not match the destination or source prefixes
in the specified list. For more information, see the destination-prefix-list match condition.
source-mac-address address Source MAC address of a VPLS packet.
source-port number (MX Series routers and EX Series switches only) TCP or UDP source port field. You cannot specify
the port and source-port match conditions in the same term.
source-port-except number (MX Series routers and EX Series switches only) Do not match on the TCP or UDP source port
field. You cannot specify the port and source-port match conditions in the same term.

source-prefix-list name (ACX Series routers, MX Series routers, and EX Series switches only) Match the source prefixes
in the specified prefix list. Specify a prefix list name defined at the [edit policy-options prefix-list
NOTE: VPLS prefix lists support only IPV4 addresses. IPV6 addresses included in a VPLS prefix
source-prefix-list name (MX Series routers and EX Series switches only) Do not match the source prefixes in the specified
except prefix list. For more information, see the source-prefix-list match condition.
tcp-flags flags Match one or more of the low-order 6 bits in the 8-bit TCP flags field in the TCP header.
To specify individual bit fields, you can specify the following text synonyms or hexadecimal values:
• fin (0x01)
• syn (0x02)
• rst (0x04)
• push (0x08)
• ack (0x10)
• urgent (0x20)
In a TCP session, the SYN flag is set only in the initial packet sent, while the ACK flag is set in all
packets sent after the initial packet.
If you configure this match condition for IPv6 traffic, we recommend that you also configure the
next-header tcp match condition in the same term to specify that the TCP protocol is being used
on the port.
traffic-type type-name (MX Series routers and EX Series switches only) Traffic type. Specify broadcast, multicast,
unknown-unicast, or known-unicast.
traffic-type-except (MX Series routers and EX Series switches only) Do not match on the traffic type. Specify
type-name broadcast, multicast, unknown-unicast, or known-unicast.
user-vlan-1p-priority number (MX Series routers, M320 router, and EX Series switches only) Match on the IEEE 802.1p user
priority bits in the customer VLAN tag (the inner tag in a dual-tag frame with 802.1Q VLAN tags).
Specify a single value or multiple values from 0 through 7.
Compare with the learn-vlan-1p-priority match condition.
the M320 router.
user-vlan-1p-priority-except (MX Series routers, M320 rouer, and EX Series switches only) Do not match on the IEEE 802.1p
number user priority bits. For details, see the user-vlan-1p-priority match condition.
the M320 router.
user-vlan-id number (MX Series routers and EX Series switches only) Match the first VLAN identifier that is part of the
payload.

user-vlan-id-except number (MX Series routers and EX Series switches only) Do not match on the first VLAN identifier that
is part of the payload.
vlan-ether-type value VLAN Ethernet type field of a VPLS packet.
vlan-ether-type-except value Do not match on the VLAN Ethernet type field of a VPLS packet.
14.2 Starting in Junos OS 14.2, flexible offset filters are supported in firewall
hierarchy configurations.
14.2 Starting in Junos OS 14.2, firewall family bridge IPv6 match criteria is
supported on MX Series and EX9200 switches.

Documentation
• Firewall Filter Terminating Actions
• Firewall Filter Nonterminating Actions
Firewall Filter Support on Loopback Interface
A loopback interface is a gateway for all the control traffic that enters the Routing Engine
of the router. If you want to monitor this control traffic, you must configure a firewall filter
on the loopback interface (lo0). Loopback firewall filters are applied only to packets that
are sent to the Routing Engine CPU for further processing. Therefore, you can apply a
firewall filter in the ingress and egress directions on the loopback interface. Loopack
interfaces on ACX Routers support both inet and inet6 family filters.
NOTE: On ACX, the filter for loopback interface can be applied only for
interface-specific instances of the firewall filter.
For standard firewall filter match conditions, see “Standard Firewall Filter Match
Conditions for IPv4 Traffic on ACX Series Routers” on page 1054.
The firewall filter on loopback interfaces handles only the following exception packets
in ingress direction:
• TTL exception packets
• Multicast packets having 224.0.0.x as the destination IP address

• Broadcast packets
• IP option packets
NOTE: Though policer action can be attached to looback filters in ingress

direction, behavior will be dependent on CPU RX queue configurations. Rate
limiting in ingress direction (through policer configuration) will be sub-set of
CPU rate limiters.
The following is a sample configuration for attaching a firewall to the loopback interface:
[edit interfaces]
lo0 {
unit 0 {
family <inet | inet6> {
filter {
input f1;
}
}
}
}
family <inet | inet6>{
filter f1 {
interface-specific; >> Mandatory Field.
term t1 {
from {
protocol ospf;
}
then {
count c1;
discard;
}
}
term t2 {
then {
count c2;
accept;
}
}
}
}
Related
Documentation
Filter-Based Forwarding for Routing Instances
You can use stateless firewall filters in routing instances to control how packets travel
in a network for IPv4 and IPv6 traffic. This is called filter-based forwarding.
You can define a firewall filtering term that directs matching packets to a specified routing
instance. This type of filtering can be configured to route specific types of traffic through

a firewall or other security device before the traffic continues on its path. To configure a
stateless firewall filter to direct traffic to a routing instance, configure a term with the
routing-instance routing-instance-name terminating action at the [edit firewall family <inet
| inet6>] hierarchy level to specify the routing instance to which matching packets will
be forwarded. You can apply a forwarding table filter to a routing instance of type
forwarding and also to the default routing instance inet.0. To configure the filter to direct
traffic to the master routing instance, use the routing-instance default statement at the
[edit firewall family <inet | inet6>] hierarchy level.
The following limitations apply to filter-based forwarding table configured on routing

instances:
• You cannot configure any of the following actions in a firewall filtering term when the
filtering term contains the routing-instance routing-instance-name terminating action:
• count counter-name
• discard
• forwarding-class class-name
• log
• loss-priority (high | medium-high | low)
• policer policer-name
• port-mirror
• reject message-type
• syslog
• three-color-policer (single-rate | two-rate) policer-name
• You cannot configure the fragment-flags number match condition in the filter term.
• You cannot attach a filter that is either default or physical interface-specific.
• You cannot attach a filter to the egress direction of routing instances.
• IPv6 filter-based forwarding does not support the following L4 matches:
• source-port
• destination-port
• icmp-type
• icmp-code
Although you can configure forwarding of packets from one VRF to another VRF, you
cannot configure forwarding from a VRF to the global routing instance.
The maximum number of routing instances supported is 64, which is the same as the
maximum number of virtual routers supported. Forwarding packets to the global table
(default VRF) is not supported for filter-based forwarding.

NOTE: Filter-based forwarding on the interface will not work when source
MAC address filter is configured because the source MAC address filter takes
higher precedence over filter-based forwarding.
Related • Example: Configuring Filter-Based Forwarding on the Source Address

Documentation
Forwarding Table Filters for Routing Instances on ACX Series Routers
Forwarding table filter is a mechanism by which all the packets forwarded by a certain
forwarding table are subjected to filtering and if a packet matches the filter condition,
the configured action is applied on the packet. You can use the forwarding table filter
mechanism to apply a filter on all interfaces associated with a single routing instance
with a simple configuration. You can apply a forwarding table filter to a routing instance
of type forwarding and also to the default routing instance inet.0. To configure a
forwarding table filter, include the filter filter-name statement at the [edit firewall family
<inet | inet6>] hierarchy level.
The following limitations apply to forwarding table filters configured on routing instances:
• You cannot attach the same filter to more than one routing instance.
• You cannot attach the same filter at both the [edit interfaces interface-name family
<inet | inet6> filter input filter-name] and [edit routing-instances instance-name
forwarding-options family <inet | inet6> filter input filter-name] hierarchy level.
• You cannot attach a filter that is either interface-specific or a physical interface filter.
• You cannot attach a filter to the egress direction of routing instances.
Related • Configuring Forwarding Table Filters on page 1083

Documentation
Configuring Forwarding Table Filters
Forwarding table filters are defined the same as other firewall filters, but you apply them
differently:
• Instead of applying forwarding table filters to interfaces, you apply them to forwarding
tables, each of which is associated with a routing instance and a virtual private network
(VPN).
• Instead of applying input and output filters by default, you can apply an input forwarding
table filter only.
All packets are subjected to the input forwarding table filter that applies to the forwarding
table. A forwarding table filter controls which packets the router accepts and then
performs a lookup for the forwarding table, thereby controlling which packets the router
forwards on the interfaces.

When the router receives a packet, it determines the best route to the ultimate destination
by looking in a forwarding table, which is associated with the VPN on which the packet
is to be sent. The router then forwards the packet toward its destination through the
appropriate interface.
NOTE: For transit packets exiting the router through the tunnel, forwarding
table filtering is not supported on the interfaces you configure as the output
interface for tunnel traffic.
A forwarding table filter allows you to filter data packets based on their components and
to perform an action on packets that match the filter; it essentially controls which bearer
packets the router accepts and forwards. To configure a forwarding table filter, include
the firewall statement at the [edit] hierarchy level:
[edit]
firewall {
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
}
}
}
}
family-name is the family address type: IPv4 (inet), IPv6 (inet6), Layer 2 traffic (bridge),
or MPLS (mpls).
term-name is a named structure in which match conditions and actions are defined.
match-conditions are the criteria against which a bearer packet is compared; for example,
the IP address of a source device or a destination device. You can specify multiple criteria
in a match condition.
action specifies what happens if a packet matches all criteria; for example, the gateway
GPRS support node (GGSN) accepting the bearer packet, performing a lookup in the
forwarding table, and forwarding the packet to its destination; discarding the packet;
and discarding the packet and returning a rejection message.
action-modifiers are actions that are taken in addition to the GGSN accepting or discarding
a packet when all criteria match; for example, counting the packets and logging a packet.
To create a forwarding table, include the instance-type statement with the forwarding
option at the [edit routing-instances instance-name] hierarchy level:
[edit]
routing-instances instance-name {

instance-type forwarding;
}
To apply a forwarding table filter to a VPN routing and forwarding (VRF) table, include
the filter and input statements at the [edit routing-instance instance-name
forwarding-options family family-name] hierarchy level:
[edit routing-instances instance-name]

instance-type forwarding;
forwarding-options {
filter {
input filter-name;
}
}
}
To apply a forwarding table filter to a forwarding table, include the filter and input
statements at the [edit forwarding-options family family-name] hierarchy level:
[edit forwarding-options family family-name]

filter {
input filter-name;
}
To apply a forwarding table filter to the default forwarding table inet.0, which is not
associated with a specific routing instance, include the filter and input statements at the
[edit forwarding-options family inet] hierarchy level:
[edit forwarding-options family inet]

filter {
input filter-name;
}

Documentation
• Applying Forwarding Table Filters


CHAPTER 33
Configuring IPsec

• Configuring IPsec Service Sets on page 1095
• Configuring IPsec Proposals on page 1098
• Configuring IKE Proposals on page 1100
• Configuring IPsec Policies on page 1102
• Configuring IKE Policies on page 1104
• Configuring IPsec Rules on page 1105
• Configuring IPsec Rule Sets on page 1108
• Tracing IPsec Operations on page 1108
IPsec for ACX Series Overview
The Juniper Networks Junos operating system (Junos OS) supports IPsec. This topic
includes the following sections, which provide background information about configuring
IPsec on ACX Series Universal Access Routers.
NOTE: IPsec is supported only on the ACX1100 AC-powered router and

ACX500 routers. Service chaining (GRE, NAT, and IPSec) on ACX1100-AC
and ACX500 routers is not supported.
NOTE: ACX5048 and ACX5096 routers do not support IPsec configurations.

For a list of the IPsec and IKE standards supported by Junos OS, see the Junos OS Hierarchy
and RFC Reference.
• IPsec on page 1088

• Security Associations on page 1088
• IKE on page 1088
IPsec
The IPsec architecture provides a security suite for the IP version 4 (IPv4) network layer.
The suite provides functionality such as authentication of origin, data integrity,
confidentiality, replay protection, and nonrepudiation of source. In addition to IPsec,
Junos OS also supports the Internet Key Exchange (IKE), which defines mechanisms for
key generation and exchange, and manages security associations.
IPsec also defines a security association and key management framework that can be
used with any transport layer protocol. The security association specifies what protection
policy to apply to traffic between two IP-layer entities. IPsec provides secure tunnels
between two peers.
Security Associations
To use IPsec security services, you create security associations between hosts. A security
association is a simplex connection that allows two hosts to communicate with each
other securely by means of IPsec. There are two types of security associations:
• Manual security associations require no negotiation; all values, including the keys, are
static and specified in the configuration. Manual security associations statically define
the security parameter index (SPI) values, algorithms, and keys to be used, and require
matching configurations on both ends of the tunnel. Each peer must have the same
configured options for communication to take place.
• Dynamic security associations require additional configuration. With dynamic security

associations, you configure IKE first and then the security association. IKE creates
dynamic security associations; it negotiates security associations for IPsec. The IKE
configuration defines the algorithms and keys used to establish the secure IKE
connection with the peer security gateway. This connection is then used to dynamically
agree upon keys and other data used by the dynamic IPsec security association. The
IKE security association is negotiated first and then used to protect the negotiations
that determine the dynamic IPsec security associations.
IKE
IKE is a key management protocol that creates dynamic security associations; it negotiates
security associations for IPsec. An IKE configuration defines the algorithms and keys used
to establish a secure connection with a peer security gateway.
IKE performs the following tasks:
• Negotiates and manages IKE and IPsec parameters.
• Authenticates secure key exchange.

Chapter 33: Configuring IPsec
• Provides mutual peer authentication by means of shared secrets (not passwords) and
public keys.
• Provides identity protection (in main mode).

Documentation
Enabling Inline Services Interface on ACX Series
The inline services interface is a virtual interface that resides on the Packet Forwarding
Engine. The si- interface makes it possible to provide NAT and IPsec services without
using a special services PIC.
To configure inline services interface, you define the service interface as type si-
(service-inline) interface. You must also reserve adequate bandwidth for the inline services
interface. This enables you to configure both interface or next-hop service sets used for
NAT and IPsec services.
NOTE: In ACX Series routers, you can configure only one inline services
interface as an anchor interface for NAT and IPsec sessions: si-0/0/0.
To enable inline services interface:
1. Access an FPC-managed slot and the PIC where the interface is to be enabled.
[edit chassis]
user@host# edit fpc slot-number pic number
2. Enable the interface and specify the amount of bandwidth reserved on each Packet
Forwarding Engine for tunnel traffic that uses inline services.
[edit chassis fpc slot-number pic number]

user@host# set inline-services bandwidth 1g

Documentation

page 1007
Understanding Service Sets
Junos OS for ACX Series routers enables you to create service sets that define a collection
of services to be performed by an inline services interface. You can configure the service
set either as an interface-style service set or as a next-hop-style service set.
An interface-style service set is used as an action modifier across an entire interface. You
can use an interface-style service set when you want to apply services to packets passing
through an interface.
A next-hop-style service set is a route-based method of applying a particular service.

Only packets destined for a specific next hop are serviced by the creation of explicit static
need to be performed. When a next-hop-style service is configured, the services interface
is considered to be a two-legged module with one leg configured to be the inside interface
(inside the network) and the other configured as the outside interface (outside the
network).
To configure service sets for NAT services, include the service-set statement at the [edit
services] hierarchy level:
[edit services]
interface-service {
}
nat-rule-sets rule-set-name;
nat-rules rule-names;
stateful-firewall-rule-setsrule-set-name;
stateful-firewall-rules rule-names;
next-hop-service {
}
}
To configure service sets for IPsec VPN services, include the service-set statement at the
[edit services] hierarchy level:

[edit services]
interface-service {
}
next-hop-service {
}
ipsec-vpn-options {
no-anti-replay;
}
ipsec-vpn-rules rule-name;
}

Documentation
page 1007

Configuring Service Sets to Be Applied to Services Interfaces
You can configure an inline-services interface on which a service is to be performed.

Services interfaces are used with either of the service set types described in the following
sections.
• Configuring Services Interface on page 1092

• Configuring Next-Hop Service Sets on page 1093
• Determining Traffic Direction on page 1093
Configuring Services Interface

An interface service set is used as an action modifier across an entire interface. To
configure the services interface, include the interface-service statement at the
[edit services service-set service-set-name] hierarchy level:

interface-service {
}
Only the interface name is needed, because Junos OS manages logical unit numbers
automatically. The services interface must be an inline-services interface for which you
have configured unit 0 family inet at the [edit interfaces interface-name] hierarchy level.
When you have defined and grouped the service rules by configuring the service-set
definition, you can apply services to one or more interfaces installed on the router. When
you apply the service set to an interface, it automatically ensures that packets are directed
to the Network Address Translation (NAT) engine.
To associate a defined service set with an interface, include the service-set statement
with the input and output statement at the [edit interfaces interface-name unit
logical-unit-number family inet service] hierarchy level:
[edit interfaces interface-name unit logical-unit-number family inet service]

input {
}
output {
}
You configure the same service set on the input and output sides of the interface. You
can optionally include filters associated with each service set to refine the target and
additionally process the traffic. If you include the service-set statement without a
service-filter definition, Junos OS assumes that the match condition is true and selects
the service set for processing automatically.
NOTE: If you configure service sets with filters, you must configure the service
sets on the input and output sides of the interface.

Configuring Next-Hop Service Sets

A next-hop service set is a route-based method of applying a particular service. Only
packets destined for a specific next hop are serviced by the creation of explicit static
need to be performed.
When a next-hop service is configured, the IPsec or NAT engine is considered to be a

two-part interface, with one part configured to be the inside interface (inside the network)
and the other configured as the outside interface (outside the network).
To configure the service domain, include the service-domain statement at the [edit
interfaces interface-name unit logical-unit-number] hierarchy level:
[edit interfaces interface-name unit logical-unit-number]

service-domain (inside | outside);
The service-domain setting must match the configuration for the next-hop’s inside and
outside services interfaces. To configure the inside and outside services interfaces, include
the next-hop-service statement at the [edit services service-set service-set-name] hierarchy
level. The interfaces you specify must be logical interfaces on the same NAT engine. You
cannot configure unit 0 for this purpose, and the logical interface you choose must not
be used by another service set.
next-hop-service {
}
Traffic on which the service is applied is forced to the inside interface using a static route.
For example:
routing-options {
static {
route 10.1.2.3 next-hop si-0/0/0.1;
}
}
After the service is applied, traffic exits through the outside interface. A lookup is then
performed in the Packet Forwarding Engine to send the packet out of the NAT engine.
The reverse traffic enters the outside interface, is serviced, and sent to the inside interface.
The inside interface forwards the traffic out of the NAT engine.
Determining Traffic Direction

When you configure next-hop service sets, the IPsec or NAT engine functions as a two-part
interface, in which one part is the inside interface and the other part is the outside interface.
The following sequence of actions takes place:

1. To associate the two parts with logical interfaces, you configure two logical interfaces
with the service-domain statement, one with the inside value and one with the outside
value, to mark them as either an inside or outside service interface.
2. The router forwards the traffic to be serviced to the inside interface, using the next-hop
lookup table.
3. After the service is applied, the traffic exits from the outside interface. A route lookup
is then performed on the packets to be sent out of the router.
4. When the reverse traffic returns on the outside interface, the applied service is undone;
for example, IPsec traffic is decrypted or NAT addresses are unmasked. The serviced
packets then emerge on the inside interface, the router performs a route lookup, and
the traffic exits the router.
A service rule’s match direction—whether input, output, or input and output—is applied
with respect to the traffic flow through the NAT engine, not through a specific inside or
outside interface.
When a packet is sent to an NAT engine, packet direction information is carried along
with it. This is true for both interface-style and next-hop-style service sets.
Interface-Style Service Sets
Packet direction is determined by whether a packet is entering or leaving any Packet

Forwarding Engine interface (with respect to the forwarding plane) on which the
interface-service statement is applied. This is similar to the input direction for stateless
firewall filters.
The match direction can also depend on the network topology. For example, you might
route all the external traffic through one interface that is used to protect the other
interfaces on the router, and configure various services on this interface specifically.
Alternatively, you might use one interface for priority traffic and configure special services
on it, but not care about protecting traffic on the other interfaces.
Next-Hop-Style Service Sets
Packet direction that is determined by the NAT engine is used to route packets to the
NAT engine. If you use the inside-interface statement to route traffic, then the packet
direction is input. If you use the outside-interface statement to direct packets to the NAT
engine, then the packet direction is output.
The interface to which you apply the service sets affects the match direction. For example,
apply the following configuration:
si-0/0/0 unit 1 service-domain inside;

si-0/0/0 unit 2 service-domain outside;
If you configure match-direction input, you include the following statements:
[edit]
services service-set test1 next-hop-service inside-service-interface si-0/0/0.1;
services service-set test1 next-hop-service outside-service-interface si-0/0/0.2;
services ipsec-vpn rule test-ipsec-rule match-direction input;
routing-options static route 10.0.0.0/24 next-hop si-0/0/0.1;

The essential difference between the two configurations is the change in the match
direction and the static routes’ next hop, pointing to either the NAT engine’s inside or
outside interface.

Documentation
Configuring IPsec Service Sets
IPsec service sets require additional specifications that you configure at the [edit services
service-set service-set-name ipsec-vpn-options] hierarchy level:
[edit services service-set service-set-name ipsec-vpn-options]

anti-replay-window-size bits;
ike-access-profile profile-name;
no-anti-replay;
Configuration of these statements is described in the following sections:
• Configuring the Local Gateway Address for IPsec Service Sets on page 1095
• Configuring IKE Access Profiles for IPsec Service Sets on page 1096
• Configuring or Disabling Antireplay Service on page 1097
Configuring the Local Gateway Address for IPsec Service Sets

If you configure an IPsec service set, you must configure a local-gateway statement by
either configuring a local IPv4 address or a logical interface.
If the Internet Key Exchange (IKE) gateway IP address is in inet.0 (the default situation),
you configure the following statement:
local-gateway (address | interface) ;
You can configure all the link-type tunnels that share the same local gateway address
in a single next-hop-style service set. The value you specify for the inside-service-interface
statement at the [edit services service-set service-set-name] hierarchy level need not
match the ipsec-inside-interface value, which you configure at the [edit services ipsec-vpn

rule rule-name term term-name from] hierarchy level. For more information about IPsec
configuration, see Configuring IPsec Rules.
IKE Addresses in VRF Instances
You can configure Internet Key Exchange (IKE) gateway IP addresses that are present
in a VPN routing and forwarding (VRF) instance as long as the peer is reachable through
the VRF instance.
For next-hop service sets, the key management process (kmd) places the IKE packets
in the routing instance that contains the outside-service-interface value you specify, as
in this example:
routing-instances vrf-nxthop {
instance-type vrf;
interface si-0/0/0.2;
...
}
services service-set service-set-1 {
next-hop-service {
inside-service-interface si-0/0/0.1;
outside-service-interface si-0/0/0.2;
}
...
}
For interface service sets, the service-interface statement determines the VRF, as in this
example:
routing-instances vrf-intf {
instance-type vrf;
interface si-0/0/0.3;
interface ge-1/2/0.1; # interface on which service set is applied
...
}
services service-set service-set-2 {
interface-service {
service-interface si-0/0/0.3;
}
...
}
Configuring IKE Access Profiles for IPsec Service Sets

For dynamic endpoint tunneling only, you need to reference the IKE access profile
configured at the [edit access] hierarchy level. To do this, include the ike-access-profile
statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy
level:
[edit services service-set service-set-name ipsec-vpn-options]

ike-access-profile profile-name;
The ike-access-profile statement must reference the same name as the profile statement
you configured for IKE access at the [edit access] hierarchy level. You can reference only

one access profile in each service set. This profile is used to negotiate IKE and IPsec
security associations with dynamic peers only.
NOTE: If you configure an IKE access profile in a service set, no other service
set can share the same local-gateway address.
Also, you must configure a separate service set for each VRF. All interfaces
referenced by the ipsec-inside-interface statement within a service set must
belong to the same VRF.
Configuring or Disabling Antireplay Service

You can include the anti-replay-window-size statement at the [edit services service-set
service-set-name ipsec-vpn-options] hierarchy level to specify the size of the antireplay
window.
anti-replay-window-size bits;
This statement is useful for dynamic endpoint tunnels for which you cannot configure
the anti-replay-window-size statement at the [edit services ipsec-vpn rule rule-name term
term-name then] hierarchy level.
For static IPsec tunnels, this statement sets the antireplay window size for all the static
tunnels within this service set. If a particular tunnel needs a specific value for antireplay
window size, set the anti-replay-window-size statement at the [edit services ipsec-vpn
rule rule-name term term-name then] hierarchy level. If antireplay check has to be disabled
for a particular tunnel in this service set, set the no-anti-replay statement at the [edit
services ipsec-vpn rule rule-name term term-name then] hierarchy level.
NOTE: The anti-replay-window-size and no-anti-replay settings at the [edit

services ipsec-vpn rule rule-name term term-name then] hierarchy level override
the settings specified at the [edit services service-set service-set-name
ipsec-vpn-options] hierarchy level.
You can also include the no-anti-replay statement at the [edit services service-set
service-set-name ipsec-vpn-options] hierarchy level to disable IPsec antireplay service.
It occasionally causes interoperability issues for security associations.
no-anti-replay;
This statement is useful for dynamic endpoint tunnels for which you cannot configure
the no-anti-reply statement at the [edit services ipsec-vpn rule rule-name term term-name
then] hierarchy level.
For static IPsec tunnels, this statement disables the antireplay check for all the tunnels
within this service set. If antireplay check has to be enabled for a particular tunnel, then
set the anti-replay-window-size statement at the [edit services ipsec-vpn rule rule-name
term term-name then] hierarchy level.

NOTE: Setting the anti-replay-window-size and no-anti-replay statements at

the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy
level overrides the settings specified at the [edit services service-set
service-set-name ipsec-vpn-options] hierarchy level.
Configuring IPsec Proposals
An IPsec proposal lists protocols and algorithms (security services) to be negotiated

with the remote IPsec peer.
To configure an IPsec proposal, include the proposal statement and specify an IPsec
proposal name at the [edit services ipsec-vpn ipsec] hierarchy level:
[edit services ipsec-vpn ipsec]

proposal proposal-name {
authentication-algorithm (hmac-sha-256-128 | hmac-sha1-96);
description description;
encryption-algorithm algorithm;
lifetime-seconds seconds;
protocol esp;
}
• Configuring the Authentication Algorithm for an IPsec Proposal on page 1098

• Configuring the Description for an IPsec Proposal on page 1099
• Configuring the Encryption Algorithm for an IPsec Proposal on page 1099
• Configuring the Lifetime for an IPsec SA on page 1099
• Configuring the Protocol for a Dynamic SA on page 1099
Configuring the Authentication Algorithm for an IPsec Proposal

To configure the authentication algorithm for an IPsec proposal, include the
authentication-algorithm statement at the [edit services ipsec-vpn ipsec proposal
proposal-name] hierarchy level:
[edit services ipsec-vpn ipsec proposal proposal-name]

authentication-algorithm (hmac-sha-256-128| hmac-sha1-96);
ACX Series routers supports the following authentication algorithms:
• hmac-sha1-96—Hash algorithm that authenticates packet data. Produces a 160-bit

authenticator value.
• hmac-sha-256-128—Hash algorithm that authenticates packet data. Produces a 256-bit


Configuring the Description for an IPsec Proposal

To specify an optional text description for an IPsec proposal, include the description
statement at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level:

Configuring the Encryption Algorithm for an IPsec Proposal

To configure encryption algorithm for an IPsec proposal, include the encryption-algorithm
statement at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level:

ACX Series routers support Advanced Encryption Standard (AES) 128-bit encryption
algorithm.
Configuring the Lifetime for an IPsec SA

When a dynamic IPsec SA is created, two types of lifetimes are used: hard and soft. The
hard lifetime specifies the lifetime of the SA. The soft lifetime, which is derived from the
hard lifetime, informs the IPsec key management system that the SA is about to expire.
This allows the key management system to negotiate a new SA before the hard lifetime
expires.
To configure the hard lifetime value, include the lifetime-seconds statement and specify
the number of seconds at the [edit services ipsec-vpn ipsec proposal proposal-name]
hierarchy level:

The default lifetime is 28,000 seconds. The range is from 180 through 86,400 seconds.
The soft lifetime values are as follows:
• Initiator: Soft lifetime = Hard lifetime – 135 seconds.
• Responder: Soft lifetime = Hard lifetime – 90 seconds.
Configuring the Protocol for a Dynamic SA

The protocol statement sets the protocol for a dynamic SA. IPsec uses ESP protocol to
protect IP traffic. The ESP protocol can support authentication, encryption, or both.
To configure the protocol for a dynamic SA, include the protocol statement and specify
esp at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level:

protocol esp;

Configuring IKE Proposals
Dynamic security associations (SAs) require IKE configuration. With dynamic SAs, you
configure IKE first, and then the SA. IKE creates the dynamic SAs and negotiates them
for IPsec. The IKE configuration defines the algorithms and keys used to establish the
secure IKE connection with the peer security gateway.
You can configure one or more IKE proposals. Each proposal is a list of IKE attributes to
protect the IKE connection between the IKE host and its peer.
To configure an IKE proposal, include the proposal statement and specify a name at the
[edit services ipsec-vpn ike] hierarchy level:
[edit services ipsec-vpn ike]

proposal proposal-name {
authentication-algorithm (md5 | hmac-sha-256-128| hmac-sha1-96);
authentication-method pre-shared-keys;
dh-group (group1 | group2 | group5 |group14);
}
This section includes the following topics:
• Configuring the Authentication Algorithm for an IKE Proposal on page 1100

• Configuring the Authentication Method for an IKE Proposal on page 1100
• Configuring the Encryption Algorithm for an IKE Proposal on page 1101
• Configuring the Lifetime for an IKE SA on page 1101
• Example: Configuring an IKE Proposal on page 1102
Configuring the Authentication Algorithm for an IKE Proposal

To configure the authentication algorithm for an IKE proposal, include the
authentication-algorithm statement at the [edit services ipsec-vpn ike proposal
[edit services ipsec-vpn ike proposal proposal-name]

authentication-algorithm (hmac-sha-256-128| hmac-sha1-96);
ACX Series routers support the following authentication algorithms:
• hmac-sha1-96—Hash algorithm that authenticates packet data. Produces a 160-bit

• hmac-sha-256-128—Hash algorithm that authenticates packet data. Produces a 256-bit

Configuring the Authentication Method for an IKE Proposal

To configure the authentication method for an IKE proposal, include the
authentication-method statement at the [edit services ipsec-vpn ike proposal


The authentication method can be one of the following:
• pre-shared-keys—A key derived from an out-of-band mechanism; the key authenticates

the exchanges
Configuring the Encryption Algorithm for an IKE Proposal

To configure the encryption algorithm for an IKE proposal, include the encryption-algorithm
statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

The algorithm can be one of the following:
• des-cbc—Encryption algorithm that has a block size of 8 bytes; its key size is 64 bits
long.
• 3des-cbc—Encryption algorithm that has a block size of 24 bytes; its key size is 192 bits
long.
• aes-128-cbc—Advanced Encryption Standard (AES) 128-bit encryption algorithm.
NOTE: For a list of Data Encryption Standard (DES) encryption algorithm

weak and semiweak keys, see RFC 2409, The Internet Key Exchange (IKE).
The AES encryption algorithms use a software implementation that has much
lower throughput, so DES remains the recommended option. For reference
information on AES encryption, see RFC 3602, The AES-CBC Cipher Algorithm
and Its Use with IPsec.
For 3des-cbc, the first 8 bytes should differ from the second 8 bytes, and the
second 8 bytes should be the same as the third 8 bytes.
If you configure an authentication proposal but do not include the encryption

statement, the result is NULL encryption. Certain applications expect this
result. If you configure no specific authentication or encryption values, the
Junos OS uses the default values of sha1 for the authentication and 3des-cbc
for the encryption.
Configuring the Lifetime for an IKE SA

The lifetime-seconds statement sets the lifetime of an IKE SA. When the IKE SA expires,
it is replaced by a new SA (and SPI) or the IPsec connection is terminated.
To configure the lifetime for an IKE SA, include the lifetime-seconds statement at the
[edit services ipsec-vpn ike proposal proposal-name] hierarchy level:


By default, the IKE SA lifetime is 3600 seconds. The range is from 180 through
86,400 seconds.
NOTE: For IKE proposals, there is only one SA lifetime value, specified by the
Junos OS. IPsec proposals use a different mechanism; for more information,
see Configuring the Lifetime for an IPsec SA.
Example: Configuring an IKE Proposal

Configure an IKE proposal:

proposal ike-proposal {
dh-group group1;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
}
Configuring IPsec Policies
An IPsec policy defines a combination of security parameters (IPsec proposals) used

during IPsec negotiation. It defines Perfect Forward Secrecy (PFS) and the proposals
needed for the connection. During the IPsec negotiation, IPsec looks for a proposal that
is the same on both peers. The peer that initiates the negotiation sends all its policies to
the remote peer, and the remote peer tries to find a match.
A match is made when both policies from the two peers have a proposal that contains
the same configured attributes. If the lifetimes are not identical, the shorter lifetime
between the two policies (from the host and peer) is used.
You can create multiple, prioritized IPsec proposals at each peer to ensure that at least
one proposal matches a remote peer’s proposal.
First, you configure one or more IPsec proposals; then you associate these proposals
with an IPsec policy. You can prioritize a list of proposals used by IPsec in the policy
statement by listing the proposals you want to use, from first to last.
To configure an IPsec policy, include the policy statement, and specify the policy name
and one or more proposals to associate with the policy, at the [edit services ipsec-vpn
ipsec] hierarchy level:
[edit services ipsec-vpn ipsec]

policy policy-name {
perfect-forward-secrecy {
keys (group1 | group2 | group5 | group14);
}
proposals [ proposal-names ];

This section includes the following topics related to configuring an IPsec policy:
• Configuring the Description for an IPsec Policy on page 1103

• Configuring Perfect Forward Secrecy on page 1103
• Configuring the Proposals in an IPsec Policy on page 1103
Configuring the Description for an IPsec Policy

To specify an optional text description for an IPsec policy, include the description
statement at the [edit services ipsec-vpn ipsec policy policy-name] hierarchy level:
[edit services ipsec-vpn ipsec policy policy-name]

Configuring Perfect Forward Secrecy

PFS provides additional security by means of a Diffie-Hellman shared secret value. With
PFS, if one key is compromised, previous and subsequent keys are secure because they
are not derived from previous keys. This statement is optional.
To configure PFS, include the perfect-forward-secrecy statement and specify a

Diffie-Hellman group at the [edit services ipsec-vpn ipsec policy policy-name] hierarchy
level:

perfect-forward-secrecy {
keys (group1 | group2 | group5 | group14);
}
The key can be one of the following:
• group1—Specifies that IKE use the 768-bit Diffie-Hellman prime modulus group when
performing the new Diffie-Hellman exchange.
• group14—Specifies that IKE use the 2048-bit Diffie-Hellman prime modulus group
when performing the new Diffie-Hellman exchange.
The higher numbered groups provide more security than the lowered numbered groups,,
but require more processing time.
Configuring the Proposals in an IPsec Policy

The IPsec policy includes a list of one or more proposals associated with an IPsec policy.
To configure the proposals in an IPsec policy, include the proposals statement and specify
one or more proposal names at the [edit services ipsec-vpn ipsec policy policy-name]
hierarchy level:


Configuring IKE Policies
An IKE policy defines a combination of security parameters (IKE proposals) to be used

during IKE negotiation. It defines a peer address and the proposals needed for that
connection. Depending on which authentication method is used, it defines the preshared
key for the given peer or the local certificate. During the IKE negotiation, IKE looks for an
IKE policy that is the same on both peers. The peer that initiates the negotiation sends
all its policies to the remote peer, and the remote peer tries to find a match.
A match is made when both policies from the two peers have a proposal that contains
the same configured attributes. If the lifetimes are not identical, the shorter lifetime
between the two policies (from the host and peer) is used. The configured preshared
key must also match its peer.
You can create multiple, prioritized proposals at each peer to ensure that at least one
proposal matches a remote peer’s proposal.
First, you configure one or more IKE proposals; then you associate these proposals with
an IKE policy. You can also prioritize a list of proposals used by IKE in the policy statement
by listing the proposals you want to use, from first to last.
To configure an IKE policy, include the policy statement and specify a policy name at the
[edit services ipsec-vpn ike] hierarchy level:

policy policy-name {
pre-shared-key (ascii-text key | hexadecimal key);
}
This section includes the following topics:
• Configuring the Proposals in an IKE Policy on page 1104

• Configuring the Preshared Key for an IKE Policy on page 1104
Configuring the Proposals in an IKE Policy

The IKE policy includes a list of one or more proposals associated with an IKE policy.
To configure the proposals in an IKE policy, include the proposals statement and specify
one or more proposal names at the [edit services ipsec-vpn ike policy policy-name]
hierarchy level:
Configuring the Preshared Key for an IKE Policy

When you include the authentication-method pre-shared-keys statement at the [edit
services ipsec-vpn ike proposal proposal-name] hierarchy level, IKE policy preshared keys
authenticate peers; for more information, see Configuring the Authentication Method for

an IKE Proposal. You must manually configure a preshared key, which must match that
of its peer. The preshared key can be an ASCII text (alphanumeric) key or a hexadecimal
key.
To configure the preshared key in an IKE policy, include the pre-shared-keys statement
and a key at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:
[edit services ipsec-vpn ike policy policy-name]

pre-shared-key (ascii-text key | hexadecimal key);
ACX Series routers support ascii-text key.
Configuring IPsec Rules
To configure an IPsec rule, include the rule statement and specify a rule name at the [edit
services ipsec-vpn] hierarchy level:
[edit services ipsec-vpn]

rule rule-name {
term term-name {
from {
destination-address address;
ipsec-inside-interface interface-name;
}
then {
backup-remote-gateway address;
dynamic {
ike-policy policy-name;
ipsec-policy policy-name;
}
initiate-dead-peer-detection;
dead-peer-detection {
interval seconds;
threshold number;
}
manual {
direction (inbound | outbound | bidirectional) {
authentication {
algorithm (hmac-sha-256-128| hmac-sha1-96);
key (ascii-text key | hexadecimal key);
}
auxiliary-spi spi-value;
encryption {
algorithm algorithm;
key (ascii-text key | hexadecimal key);
}
protocol esp;
spi spi-value;
}
}
no-anti-replay;
remote-gateway address;
}

}
}
Each IPsec rule consists of a set of terms, similar to a firewall filter. A term consists of
the following:
and excluded.

router software.
The following sections explain how to configure the components of IPsec rules:
• Configuring Match Direction for IPsec Rules on page 1106

• Configuring Match Conditions in IPsec Rules on page 1107
• Configuring Actions in IPsec Rules on page 1107
• Configuring Destination Address on page 1107
Configuring Match Direction for IPsec Rules

Each rule must include a match-direction statement that specifies whether the match is
applied on the input or output side of the interface. To configure where the match is
applied, include the match-direction (input | output) statement at the [edit services
ipsec-vpn rule rule-name] hierarchy level:
[edit services ipsec-vpn rule rule-name]

NOTE: ACX Series routers support match-direction as input. match-direction

as output is not supported.
The match direction is used with respect to the traffic flow through the inline service
interface. When a packet is sent to the PIC, direction information is carried along with it.
With an interface service set, packet direction is determined by whether a packet is

With a next-hop service set, packet direction is determined by the interface used to route
the packet to the inline service interface. If the inside interface is used to route the packet,
PIC, the packet direction is output. For more information on inside and outside interfaces,
see “Configuring Service Sets to Be Applied to Services Interfaces” on page 1031.
On the inline services interface, a flow lookup is performed. If no flow is found, rule
processing is performed. All rules in the service set are considered. During rule processing,
the packet direction is compared against rule directions. Only rules with direction
information that match the packet direction are considered.

Configuring Match Conditions in IPsec Rules

To configure the match conditions in an IPsec rule, include the from statement at the
[edit services ipsec-vpn rule rule-name term term-name] hierarchy level:
[edit services ipsec-vpn rule rule-name term term-name]

from {
destination-address address;
}
You can use either the source address or the destination address as a match condition,
in the same way that you would configure a firewall filter; for more information, see the
Routing Policies, Firewall Filters, and Traffic Policers Feature Guide.
IPsec services on ACX Series support IPv4 address formats. If you do not specifically
configure either the source address or destination address, the default value 0.0.0.0/0
(IPv4 ANY) is used.
Configuring Actions in IPsec Rules

To configure actions in an IPsec rule, include the then statement at the [edit services
ipsec-vpn rule rule-name term term-name] hierarchy level:
[edit services ipsec-vpn rule rule-name term term-name]

then {
dynamic {
ike-policy policy-name;
ipsec-policy policy-name;
}
}
The principal IPsec actions are to configure a dynamic or manual SA:
• You configure a dynamic SA by including the dynamic statement at the [edit services
ipsec-vpn rule rule-name term term-name then] hierarchy level and referencing policies
you have configured at the [edit services ipsec-vpn ipsec] and [edit services ipsec-vpn
ike] hierarchy levels; for more information, see Configuring Dynamic Security Associations.
• You configure a manual SA by including the manual statement at the [edit services
ipsec-vpn rule rule-name term term-name then] hierarchy level; for more information,
see Configuring Manual Security Associations.
Configuring Destination Address

To specify the remote address to which the IPsec traffic is directed, include the
remote-gateway statement at the [edit services ipsec-vpn rule rule-name term term-name
then] hierarchy level:
[edit services ipsec-vpn rule rule-name term term-name then]


Configuring IPsec Rule Sets
The rule-set statement defines a collection of IPsec rules that determine what actions
the router software performs on packets in the data stream. You define each rule by
specifying a rule name and configuring terms. Then, you specify the order of the rules by
including the rule-set statement at the [edit services ipsec-vpn] hierarchy level with a
rule statement for each rule:

rule-set rule-set-name {
rule rule-name;
}
The router software processes the rules in the order in which you specify them in the
configuration. If a term in a rule matches the packet, the router performs the corresponding
action and the rule processing stops. If no term in a rule matches the packet, processing
continues to the next rule in the rule set. If none of the rules matches the packet, the
packet is dropped by default.
Tracing IPsec Operations
Trace operations track IPsec events and record them in a log file in the /var/log directory.
By default, this file is named /var/log/kmd.
To trace IPsec operations, include the traceoptions statement at the [edit services
ipsec-vpn] hierarchy level:

traceoptions {
file <filename> <files number> <match regular-expression> <size bytes> <world-readable |
no-world-readable>;
flag flag;
level level;
no-remote-trace;
}
You can specify the following IPsec tracing flags:
• all—Trace everything.
• certificates—Trace certificates events.
• database—Trace security associations database events.
• general—Trace general events.
• ike—Trace IKE module processing.
• parse—Trace configuration processing.
• policy-manager—Trace policy manager processing.
• routing-socket—Trace routing socket messages.

• snmp—Trace SNMP operations.
• timer—Trace internal timer events.
The level statement sets the key management process (kmd) tracing level. The following
values are supported:
• all—Match all levels.
• error—Match error conditions.
• info–Match informational messages.
• notice—Match conditions that should be handled specially.
• verbose—Match verbose messages.
• warning—Match warning messages.


CHAPTER 34
Configuring Operations, Administration,

and Management (OAM)
• Understanding Ethernet OAM Link Fault Management for ACX Series Routers on page 1112
• Configuring Ethernet Local Management Interface on ACX Series on page 1113
• Ethernet Frame Delay Measurements Overview on page 1117
• Ethernet Frame Loss Measurement Overview on page 1121
• Proactive Mode for SLA Measurement on page 1123
• On-Demand Mode for SLA Measurement on page 1125
• Configuring MEP Interfaces to Support Delay Measurement on page 1125
• Ethernet OAM Connectivity Fault Management on page 1126
• IEEE 802.1ag OAM Connectivity Fault Management in ACX Series Overview on page 1128
• Configuring Maintenance Association Intermediate Points in ACX Series on page 1129
• Example: Configuring IEEE 802.3ah OAM Support for an Interface on page 1133
• Enabling Dying Gasp Functionality on page 1135
• Ethernet Alarm Indication Signal Overview on page 1136
• Configuring Alarm Indication Signal on ACX Series Routers on page 1138
• Ethernet Synthetic Loss Measurement Overview on page 1140
• Transmission of ETH-SLM Messages on page 1141
• Format of ETH-SLM Messages on page 1144
• Guidelines for Configuring ETH-SLM on page 1146
• Scenarios for Configuration of ETH-SLM on page 1147
• Managing ETH-SLM Statistics and ETH-SLM Frame Counts on page 1148
• Starting a Proactive ETH-SLM Session on page 1153
• Starting an On-Demand ETH-SLM Session on page 1156
• Dynamic Ternary Content Addressable Memory Overview on page 1157
• Service Scaling on ACX5048 and ACX5096 Routers on page 1167
• Understanding Layer 2 Next Generation Mode on ACX5048 and ACX5096

• Understanding and Configuring the Unified Forwarding Table on page 1169

• Interpreting the Enterprise-Specific Service OAM MIB on page 1171
Understanding Ethernet OAM Link Fault Management for ACX Series Routers
The Juniper Networks Junos operating system (Junos OS) for Juniper Networks ACX
Series routers allows the Ethernet interfaces on these routers to support the IEEE 802.3ah
standard for the Operation, Administration, and Maintenance (OAM) of Ethernet in access
networks. The standard defines OAM link fault management (LFM). You can configure
IEEE 802.3ah OAM LFM on point-to-point Ethernet links that are connected either directly
or through Ethernet repeaters. The IEEE 802.3ah standard meets the requirement for
OAM capabilities even as Ethernet moves from being solely an enterprise technology to
a WAN and access technology, and the standard remains backward compatible with
the existing Ethernet technology.
Ethernet OAM provides tools that network management software and network managers
can use to determine how a network of Ethernet links is functioning. Ethernet OAM should:
• Rely only on the media access control (MAC) address or virtual LAN identifier for
troubleshooting.
• Work independently of the actual Ethernet transport and function over physical Ethernet
ports or a virtual service such as a pseudowire.
• Isolate faults over a flat (or single-operator) network architecture or nested or

hierarchical (or multiprovider) networks.
The following OAM LFM features are supported on ACX Series routers:
• Discovery and Link Monitoring
The discovery process is triggered automatically when OAM is enabled on the interface.
The discovery process permits Ethernet interfaces to discover and monitor the peer
on the link if it also supports the IEEE 802.3ah standard. You can specify the discovery
mode used for IEEE 802.3ah OAM support. In active mode, the interface discovers and
monitors the peer on the link if the peer also supports IEEE 802.3ah OAM functionality.
In passive mode, the peer initiates the discovery process. After the discovery process
has been initiated, both sides participate in the process. The router performs link
monitoring by sending periodic OAM protocol data units (PDUs) to advertise OAM
mode, configuration, and capabilities.
You can specify the number of OAM PDUs that an interface can skip before the link
between peers is considered down.
• Remote Fault Detection
Remote fault detection uses flags and events. Flags are used to convey the following:
• Link Fault means a loss of signal
• Dying Gasp means an unrecoverable condition such as a power failure. In this

condition, the local peer informs the remote peer about the failure state. When the
remote peer receives a dying-gasp PDU, it takes an action corresponding to the
action profile configured with the link-adjacency-loss event.

Chapter 34: Configuring Operations, Administration, and Management (OAM)
NOTE: ACX5096 and ACX5048 routers do not support dying-gasp.
ACX Series routers can generate and receive dying-gasp packets. When LFM is
configured on an interface, a dying-gasp PDU is generated for the interface on the
following failure conditions:
• Power failure
• Packet Forwarding Engine panic or a crash
• Critical Event means an unspecified vendor-specific critical event.
You can specify the interval at which OAM PDUs are sent for fault detection.
NOTE: ACX Series routers support the receipt of dying-gasp packets, but
cannot generate them.
• Remote Loopback Mode
Remote loopback mode ensures link quality between the router and a remote peer
during installation or troubleshooting. In this mode, when the interface receives a frame
that is not an OAM PDU or a PAUSE frame, it sends it back on the same interface on
which it was received. The link appears to be in the active state. You can use the returned
loopback acknowledgement to test delay, jitter, and throughput.
If a remote data terminal equipment (DTE) supports remote loopback mode, Junos
OS can place the remote DTE into loopback mode. When you place a remote DTE into
loopback mode, the interface receives the remote loopback request and puts the
interface into remote loopback mode. When the interface is in remote loopback mode,
all frames except OAM PDUs and PAUSE frames are looped back. No changes are
made to the frames. OAM PDUs continue to be sent and processed.
Related • IEEE 802.1ag OAM Connectivity Fault Management Overview

Documentation
• Configuring Ethernet Local Management Interface
Configuring Ethernet Local Management Interface on ACX Series
• Ethernet Local Management Interface Overview on page 1113

• Configuring the Ethernet Local Management Interface on page 1115
Ethernet Local Management Interface Overview

ACX Series routers with Gigabit Ethernet (ge), 10-Gigabit Ethernet (xe), or Aggregated
Ethernet (ae) interfaces support the Ethernet Local Management Interface (E-LMI). The
E-LMI specification is available at the Metro Ethernet Forum. E-LMI procedures and
protocols are used for enabling automatic configuration of the customer edge (CE) device

to support Metro Ethernet services. The E-LMI protocol also provides user-to-network
interface (UNI) and Ethernet virtual connection (EVC) status information to the CE device.
The UNI and EVC information enables automatic configuration of CE operation based
on the Metro Ethernet configuration.
The E-LMI protocol operates between the CE device and the provider edge (PE) device.
It runs only on the PE-CE link and notifies the CE device of connectivity status and
configuration parameters of Ethernet services available on the CE port. The scope of the
E-LMI protocol is shown in Figure 60 on page 1114.
Figure 60: Scope of the E-LMI Protocol
UNI UNI
CE Metro Ethernet Network CE
g017277
E-LMI E-LMI
The E-LMI implementation on ACX Series routers includes only the PE side of the E-LMI
protocol.
E-LMI interoperates with an OAM protocol, such as connectivity fault management

(CFM), that runs within the provider network to collect OAM status. CFM runs at the
provider maintenance level (UNI-N to UNI-N with up MEPs at the UNI). E-LMI relies on
the CFM for end-to-end status of EVCs across CFM domains.
The E-LMI protocol relays the following information:
• Notification to the CE device of the addition or deletion of an EVC (active, not active)
• Notification to the CE device of the availability state of a configured EVC
• Communication of UNI and EVC attributes to the CE device:
• UNI attributes:
• UNI identifier (a user-configured name for UNI)
• CE-VLAN ID and EVC map type (all-to-one bundling, service multiplexing with
bundling, or no bundling)
• EVC attributes:
• EVC reference ID
• EVC status type (active, not active)
• EVC type (point-to-point)
• EVC ID (a user-configured name for EVC)
• CE-VLAN ID and EVC map

The E-LMI protocol on ACX Series routers supports Layer 2 circuit and Layer 2 VPN EVC
types and enables link-loss forwarding for pseudowire (Layer 2 circuit and Layer 2 VPN)
services as follows:
• Interworking between the connectivity fault management (CFM) protocol and the
E-LMI protocol for Layer 2 circuit and Layer 2 VPN.
• End-to-end CFM session between UNIs to monitor EVC status.
• In the case of pseudowire redundancy, CFM can be used to monitor active and backup
pseudowire sessions. The EVC status is declared as down to CE devices only when
both the active and backup pseudowire sessions go down.
• Interworking between remote defect indication (RDI) and E-LMI for Layer 2 circuit and
Layer 2 VPN.
• If a maintenance association end point (MEP) receives an RDI bit set in a continuity
check message (CCM) frame, and if RDI fault detection is enabled in the EVC
configuration at [edit protocols oam ethernet evcs evc-id evc-protocol cfm
management-domain name management-association name faults rdi], then the
pseudowire is declared as down to CE routers through E-LMI.
• If an end-to-end CFM session does not exist between UNIs, the pseudowire (Layer 2
circuit or Layer 2 VPN) up and down state triggers an asynchronous EVC state change
message to CE routers through E-LMI.
NOTE: ACX Series routers do not support E-LMI for Layer 2 services (bridging).
Configuring the Ethernet Local Management Interface

To configure E-LMI, perform the following steps:
• Configuring an OAM Protocol (CFM) on page 1115

• Assigning the OAM Protocol to an EVC on page 1115
• Enabling E-LMI on an Interface and Mapping CE VLAN IDs to an EVC on page 1116
Configuring an OAM Protocol (CFM)
For information about configuring the OAM protocol (CFM), see IEEE 802.1ag OAM
Connectivity Fault Management Overview.
Assigning the OAM Protocol to an EVC
To assign an OAM protocol to an EVC, you must specify a name for the EVC by using the
evcs evc-id statement at the [edit protocols oam ethernet] hierarchy level. You can set
the evc-protocol statement to cfm, l2circuit, or l2vpn to monitor the EVC status and its
options at the [edit protocols oam ethernet evcs] hierarchy level. You can configure the
number of remote UNIs in the EVC by using the remote-uni-count number statement. The
remote-uni-count value defaults to 1.

You can configure an EVC by including the evcs statement at the [edit protocols oam
ethernet] hierarchy level:
[edit protocols oam ethernet]

evcs evc-id {
evc-protocol (cfm management-domain name management-association name faults
rdi; | l2circuit interface interface-name | l2vpn interface interface-name;)
remote-uni-count count; # Optional, defaults to 1
async-status-msg-transmit-interval interval (1ms|1000ms) ; # Defaults to 10ms.
}
Enabling E-LMI on an Interface and Mapping CE VLAN IDs to an EVC
To configure E-LMI, include the lmi statement at the [edit protocols oam ethernet]
hierarchy level:
[edit protocols oam ethernet]

lmi {
polling-verification-timer value;
# Polling verification timer (T392), defaults to 15 seconds
status-counter count; # Status counter (N393), defaults to 4
interface name {
evc evc-id {
default-evc;
vlan-list [ vlan-ids ];
}
evc-map-type (all-to-one-bundling | bundling | service-multiplexing);
polling-verification-time value; # Optional, defaults to global value
status-counter count; # Optional, defaults to global value
uni-id value; # Optional, defaults to interface-name
}
}
You can set the status counter to count consecutive errors by using the status-counter
count statement at the [edit protocols oam ethernet lmi] hierarchy level. The status
counter is used to determine whether E-LMI is operational or not. The default value is 4.
You can set the polling-verification-timer value statement at the [edit protocols oam
ethernet lmi] hierarchy level. The default value is 15 seconds.
You can enable an interface and set its options for use with E-LMI by using the interface
name statement at the [edit protocols oam ethernet lmi] hierarchy level. Only ge, xe, and
ae interfaces are supported. You can use the interface uni-id option to specify a name
for the UNI. If uni-id is not configured, it defaults to the name variable in the interface
name statement.
You can specify the CE-VLAN ID and EVC map type by using the evc-map-type type
interface option. The options are all-to-one-bundling, bundling, and service-multiplexing.
Service multiplexing is with no bundling. The default type is all-to-one-bundling.
To specify the EVC that an interface uses, use the evc evc-id statement at the [edit
protocols oam ethernet lmi interface name] hierarchy level. You can specify an interface
as the default EVC interface by using the default-evc statement at the [edit protocols
oam ethernet lmi interface name evc evc-id] hierarchy level. All VLAN IDs that are not

mapped to any other EVCs are mapped to this EVC. Only one EVC can be configured as
the default.
You can map a list of VLANs to an EVC by using the vlan-list vlan-id-list statement at the
[edit protocols oam ethernet lmi interface name evc evc-id] hierarchy level.
Related • IEEE 802.1ag OAM Connectivity Fault Management in ACX Series Overview on page 1128
Documentation
• Creating a Maintenance Domain
• Configuring Maintenance Intermediate Points (MIPs)
• Creating a Maintenance Association
• Configuring Continuity Check Protocol Parameters for Fault Detection
• Configuring Linktrace Protocol in CFM
• Configuring Port Status TLV and Interface Status TLV
Ethernet Frame Delay Measurements Overview
• ITU-T Y.1731 Frame Delay Measurement Feature on page 1117

• Two-Way Ethernet Frame Delay Measurement on page 1118
• Restrictions for Ethernet Frame Delay Measurement on page 1120
ITU-T Y.1731 Frame Delay Measurement Feature

The IEEE 802.3-2005 standard for Ethernet Operations, Administration, and Maintenance
(OAM) defines a set of link fault management mechanisms to detect and report link
faults on a single point-to-point Ethernet LAN.
Junos OS supports key OAM standards that provide for automated end-to-end
management and monitoring of Ethernet service by service providers:
• IEEE Standard 802.1ag, also known as “Connectivity Fault Management (CFM).”
• ITU-T Recommendation Y.1731, which uses different terminology than IEEE 802.1ag and
defines Ethernet service OAM features for fault monitoring, diagnostics, and
performance monitoring.
These capabilities allow operators to offer binding service-level agreements (SLAs) and
generate new revenues from rate- and performance-guaranteed service packages that
are tailored to the specific needs of their customers.
ACX Series routers support proactive and on-demand modes.

NOTE: ACX5048 and ACX5096 routers supports only software-based time

stamping for delay measurement.
Ethernet Frame Delay Measurement
Two key objectives of OAM functionality are to measure quality-of-service attributes

such as frame delay and frame delay variation (also known as “frame jitter”). Such
measurements can enable you to identify network problems before customers are
impacted by network defects.
Junos OS supports Ethernet frame delay measurement between MEPs configured on

Ethernet physical or logical interfaces on ACX Series routers. Ethernet frame delay
measurement provides fine control to operators for triggering delay measurement on a
given service and can be used to monitor SLAs. Ethernet frame delay measurement also
collects other useful information, such as worst and best case delays, average delay,
and average delay variation. The Junos OS implementation of Ethernet frame delay
measurement (ETH-DM) is fully compliant with the ITU-T Recommendation Y.1731, OAM
Functions and Mechanisms for Ethernet-based Networks. The recommendation defines
OAM mechanisms for operating and maintaining the network at the Ethernet service
layer, which is called the "ETH layer" in ITU-T terminology.
NOTE: ACX Series routers do not support one-way Ethernet frame delay
measurement.
Two-Way Ethernet Frame Delay Measurement

In two-way ETH-DM mode, frame delay and frame delay variation values are based on
the time difference between when the initiator MEP transmits a request frame and
receives a reply frame from the responder MEP, subtracting the time elapsed at the
responder MEP.
DMM Transmission
When you start a two-way frame delay measurement, the router sends delay
measurement message (DMM) frames— frames that carry the PDU for a two-way
ETH-DM request—from the initiator MEP to the responder MEP at the rate and for the
number of frames you specify. The router marks each DMM frame as drop-ineligible and
inserts a timestamp of the transmission time into the frame.
DMR Transmission
When an MEP receives a DMM frame, the responder MEP responds with a delay
measurement reply (DMR) frame, which carries ETH-DM reply information and a copy
of the timestamp contained in the DMM frame.

DMR Reception
When an MEP receives a valid DMR, the router that contains the MEP measures the
two-way delay for that frame based on the following sequence of timestamps:
1. TI
TxDMM
2. TR
RxDMM
3. TR
TxDMR
4. TI
RxDMR
A two-way frame delay is calculated as follows:
[TI – TI ] – [TR – TR ]
RxDMR TxDMM TxDMR RxDMM
The calculation show that frame delay is the difference between the time at which the
initiator MEP sends a DMM frame and the time at which the initiator MEP receives the
associated DMR frame from the responder MEP, minus the time elapsed at the responder
MEP.
The delay variation is the difference between the current and previous delay values.
Two-Way ETH-DM Statistics
The router that contains the initiator MEP stores each set of two-way delay statistics in
the ETH-DM database. The ETH-DM database collects up to 100 sets of statistics for
any given CFM session (pair of peer MEPs). You can access these statistics at any time
by displaying the ETH-DM database contents.
Two-Way ETH-DM Frame Counts
Each router counts the number of two-way ETH-DM frames sent and received:
• For an initiator MEP, the router counts the number DMM frames transmitted, the number
of valid DMR frames received, and the number of invalid DMR frames received.
• For a responder MEP, the router counts the number of DMR frames sent.
Each router stores ETH-DM frame counts in the CFM database. The CFM database stores
CFM session statistics and, for interfaces that support ETH-DM, any ETH-DM frame
counts. You can access the frame counts at any time by displaying CFM database
information for Ethernet interfaces assigned to MEPs or for MEPs in CFM sessions.
NOTE: For a given two-way Ethernet frame delay measurement, frame delay
and frame delay variation values are available only at the router that contains
the initiator MEP.

Restrictions for Ethernet Frame Delay Measurement

The following restrictions apply to the Ethernet frame delay measurement feature:
• Ethernet frame delay measurements can be triggered only when the distributed periodic
packet management daemon (ppm) is enabled. To enable distributed ppm, include
the delegate-server-processing CLI statement at the [edit protocols oam ethernet
connectivity-fault-management performance-monitoring] hierarchy. For more
information about this limitation, see Guidelines for Configuring Routers to Support an
ETH-DM Session and Ensuring That Distributed ppm Is Not Disabled.
• You can monitor only one session at a time to the same remote MEP or MAC address.
For more information about starting an ETH-DM session, see Starting an ETH-DM
Session.
• ETH-DM statistics are collected at only one of the two peer routers in the ETH-DM
session. For a one-way ETH-DM session, you can display frame ETH-DM statistics at
the receiver MEP only, using ETH-DM-specific show commands. For a two-way ETH-DM
session, you can display frame delay statistics at the initiator MEP only, using the same
ETH-DM-specific show commands. For more information, see Managing ETH-DM
Statistics and ETH-DM Frame Counts.
• ETH-DM frame counts are collected at both MEPs and are stored in the respective
CFM databases.
• Accuracy of frame delay statistics is compromised when the system is changing (such
as from reconfiguration). We recommend performing Ethernet frame delay
measurements on a stable system.
• One-way Ethernet frame delay measurement is not supported.
Related • Understanding Ethernet OAM Link Fault Management for ACX Series Routers on page 1112
Documentation
• Guidelines for Configuring Routers to Support an ETH-DM Session
• Guidelines for Starting an ETH-DM Session
• Guidelines for Managing ETH-DM Statistics and ETH-DM Frame Counts
• Configuring MEP Interfaces to Support Delay Measurement on page 1125

Ethernet Frame Loss Measurement Overview
The key objectives of the OAM functionality are to measure quality-of-service attributes
such as frame delay, frame delay variation (also known as “frame jitter”), and frame loss.
Such measurements enable you to identify network problems before customers are
impacted by network defects. For more information about Ethernet frame delay
measurement, see Ethernet Frame Delay Measurements Overview.
Junos OS supports Ethernet frame loss measurement (ETH-LM) between maintenance

association end points (MEPs) configured on Ethernet physical or logical interfaces on
MX Series routers and is presently supported only for VPWS service. ETH-LM is used by
operators to collect counter values applicable for ingress and egress service frames.
These counters maintain a count of transmitted and received data frames between a
pair of MEPs. Ethernet frame loss measurement is performed by sending frames with
ETH-LM information to a peer MEP and similarly receiving frames with ETH-LM information
from the peer MEP. This type of frame loss measurement is also known as single-ended
Ethernet loss measurement.
NOTE: MX Series Virtual Chassis does not support Ethernet frame loss
measurement (ETH-LM).
ETH-LM supports the following frame loss measurements:
• Near-end frame loss measurement—Measurement of frame loss associated with

ingress data frames.
• Far-end frame loss measurement—Measurement of frame loss associated with egress

data frames.
NOTE: The proactive and dual-ended loss measurement functionality of

ITU-T Y1731 is not supported on the ACX Series routers.
The ETH-LM feature is supported on aggregated Ethernet interfaces.

NOTE: Starting Junos OS Release 16.1, the Ethernet loss measurement

(ETH-LM) results are inaccurate when connectivity fault management (CFM)
and performance monitoring (PM) PDUs received locally at a maintenance
endpoint (MEP) as classified as belonging to the yellow class or a packet
loss priority (PLP) of medium-high. This problem of incorrect results is specific
to Ethernet loss measurement for CFM sessions of down MEPs. The Ethernet
loss measurement statistics are inaccurate in the following scenarios:
• Ethernet loss measurement is working on a CFM session for a MEP in down

state
• CFM PDUs received on the logical interface of the down MEP are classified
by the classifier as yellow or medium-high PLP
• A packet is identified as yellow when the input classifier marks the PLP as
medium-high.
The problem of discrepancies with Ethernet loss measurement results is not

observed when you configure Ethernet loss measurement in colorless mode.
To avoid this problem of inaccurate loss measurement results, provision all
local CFM PDUs as green or with the PLP as high.
NOTE: Starting with Junos OS Release 16.1, performance monitoring for

connectivity fault management (by including the performance-monitoring
statement and its substatements at the [edit protocols oam ethernet
connectivity-fault-management] hierarchy level) is not supported when the
network-to-network (NNI) or egress interface is an aggregated Ethernet
interface with member links on DPCs.
16.1 Starting Junos OS Release 16.1, the Ethernet loss measurement (ETH-LM) results are
inaccurate when connectivity fault management (CFM) and performance monitoring
(PM) PDUs received locally at a maintenance endpoint (MEP) as classified as
belonging to the yellow class or a packet loss priority (PLP) of medium-high.
16.1 Starting with Junos OS Release 16.1, performance monitoring for connectivity fault
management (by including the performance-monitoring statement and its
substatements at the [edit protocols oam ethernet
connectivity-fault-management] hierarchy level) is not supported when the
network-to-network (NNI) or egress interface is an aggregated Ethernet interface
with member links on DPCs.
Related • Managing Continuity Measurement Statistics

Documentation

• Example: Measuring Ethernet Frame Loss for Single-Tagged LMM/LMR PDUs
• Example: Measuring Ethernet Frame Loss for Dual-Tagged LMM/LMR PDUs
Proactive Mode for SLA Measurement
In proactive mode, SLA measurements are triggered by an iterator application. An iterator

is designed to periodically transmit SLA measurement packets in form of
ITU-Y.1731-compliant frames for two-way delay measurement or loss measurement on
MX Series routers. This mode differs from on-demand SLA measurement, which is user
initiated. The iterator sends periodic delay or loss measurement request packets for each
of the connections registered to it. Iterators make sure that measurement cycles do not
occur at the same time for the same connection to avoid CPU overload. Junos OS supports
proactive mode for VPWS. For an iterator to form a remote adjacency and to become
functionally operational, the continuity check message (CCM) must be active between
the local and remote MEP configurations of the connectivity fault management (CFM).
Any change in the iterator adjacency parameters resets the existing iterator statistics
and restarts the iterator. Here, the term adjacency refers to a pairing of two endpoints
(either connected directly or virtually) with relevant information for mutual understanding,
which is used for subsequent processing. For example, the iterator adjacency refers to
the iterator association between the two endpoints of the MEPs.
For every DPC or MPC, only 30 iterator instances for a cycle time value of 10 milliseconds
(ms) are supported. In Junos OS, 255 iterator profile configurations and 2000 remote
MEP associations are supported.
Iterators with cycle time value less than 100 ms are supported only for infinite iterators,
whereas the iterators with cycle time value greater than 100 ms are supported for both
finite and infinite iterators. Infinite iterators are iterators that run infinitely until the iterator
is disabled or deactivated manually.
NOTE: ACX5048 and ACX5096 routers supports iterator cycle time of only
1 second and above.
A VPWS service configured on a router is monitored for SLA measurements by registering

the connection (here, the connection is a pair of remote and local MEPs) on an iterator
and then initiating periodic SLA measurement frame transmission on those connections.
The end-to-end service is identified through a maintenance association end point (MEP)
configured at both ends.
For two-way delay measurement and loss measurement, an iterator sends a request
message for the connection in the list (if any) and then sends a request message for the
connection that was polled in the former iteration cycle. The back-to-back request
messages for the SLA measurement frames and their responses help in computing delay
variation and loss measurement.

The Y.1731 frame transmission for a service attached to an iterator continues endlessly
unless intervened and stopped by an operator or until the iteration-count condition is
met. To stop the iterator from sending out any more proactive SLA measurement frames,
the operator must perform one of the following tasks:
• Enable the deactivate sla-iterator-profile 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. For more information, see
Verifying the Configuration of an Iterator Profile.
• Provision a disable statement under the corresponding iterator profile at the [edit
protocols oam ethernet connectivity-fault-management performance-monitoring
sla-iterator-profiles profile-name] hierarchy level. For more information, see Configuring
an Iterator Profile.
Ethernet Delay Measurements and Loss Measurement by Proactive Mode

In two-way delay measurement, the delay measurement message (DMM) frame is
triggered through an iterator application. The DMM frame carries an iterator type, length,
and value (TLV) in addition to the fields described in standard frame format and the
server copies the iterator TLV from the DMM frame to the delay measurement reply
(DMR) frame.
In one-way delay variation computation using the two-way delay measurement method,
the delay variation computation is based on the timestamps that are present in the DMR
frame (and not the 1DM frame). Therefore, there is no need for client-side and server-side
clocks to be in sync. Assuming that the difference in their clocks remains constant, the
one-way delay variation results are expected to be fairly accurate. This method also
eliminates the need to send separate 1DM frames just for the one-way delay variation
measurement purpose.
In proactive mode for loss measurement, the router sends packets in standard format
along with loss measurement TLV and iterator TLV.
Related • Configuring an Iterator Profile

Documentation
• Configuring a Remote MEP with an Iterator Profile
• Ethernet Frame Delay Measurements Overview
• Verifying the Configuration of an Iterator Profile
• Managing Iterator Statistics

On-Demand Mode for SLA Measurement
In on-demand mode, the measurements are triggered by the user through the CLI.
When the user triggers the delay measurement through the CLI, the delay measurement
request that is generated is as per the frame formats specified by the ITU-T Y.1731
standard. For two-way delay measurement, the server-side processing can be delegated
to the Packet Forwarding Engine to prevent overloading on the Routing Engine. For more
information, see Configuring Routers to Support an ETH-DM Session. When the server-side
processing is delegated to the Packet Forwarding Engine, the delay measurement message
(DMM) frame receive counters and delay measurement reply (DMR) frame transmit
counters are not displayed by the show command.
When the user triggers the loss measurement through the CLI, the router sends the
packets in standard format along with the loss measurement TLV. By default, the
session-id-tlv argument is included in the packet to allow concurrent loss measurement
sessions from same local MEP. You can also disable the session ID TLV by using the
no-session-id-tlv argument.
Single-ended ETH-LM is used for on-demand operation, administration, and maintenance

purposes. An MEP sends frames with ETH-LM request information to its peer MEP and
receives frames with ETH-LM reply information from its peer MEP to carry out loss
measurements. The protocol data unit (PDU) used for a single-ended ETH-LM request
is referred to as a loss measurement message (LMM) and the PDU used for a single-ended
ETH-LM reply is referred to as a loss measurement reply (LMR).
Related • Ethernet Frame Delay Measurements Overview

Documentation
• Configuring Routers to Support an ETH-DM Session.
Configuring MEP Interfaces to Support Delay Measurement
Before you can start an Ethernet frame delay measurement (ETH-DM) session across
an Ethernet service, you must configure two ACX Series routers to support ETH-DM.
To configure an Ethernet interface on a ACX Series router to support ETH-DM:
1. On each router, configure two physical or logical Ethernet interfaces connected by a

VLAN. The following configuration is typical for single-tagged logical interfaces:
[edit interfaces]
interface {
ethernet-interface-name {
vlan-tagging;
vlan-id vlan-id; # Both interfaces on this VLAN

}
}
}
Both interfaces will use the same VLAN ID.
2. On each router, attach peer MEPs to the two interfaces. The following configuration
is typical:
[edit protocols]
oam {
ethernet {
maintenance-domain md-name { # On both routers
level number;
maintenance-association ma-name { # On both routers
continuity-check {
interval 100ms;
hold-interval 1;
}
mep mep-id { # Attach to VLAN interface
auto-discovery;
direction (up | down);
priority number;
}
}
}
}
}
}
Related • Ethernet Frame Delay Measurements Overview on page 1117

Documentation
Ethernet OAM Connectivity Fault Management
The most complete connectivity fault management (CFM) is defined in IEEE 802.1ag.
This topic emphasizes the use of CFM in a Metro Ethernet environment.
The major features of CFM are:
• Fault monitoring using the continuity check protocol. This is a neighbor discovery and
health check protocol that discovers and maintains adjacencies at the VLAN or link
level.
• Path discovery and fault verification using the linktrace protocol. Similar to IP traceroute,
this protocol maps the path taken to a destination MAC address through one or more
bridged networks between the source and destination.
• Fault isolation using the loopback protocol. Similar to IP ping, this protocol works with
the continuity check protocol during troubleshooting.

CFM partitions the service network into various administrative domains. For example,
operators, providers, and customers might be part of different administrative domains.
Each administrative domain is mapped into one maintenance domain providing enough
information to perform its own management, thus avoiding security breaches and making
end-to-end monitoring possible. Each maintenance domain is associated with a
maintenance domain level from 0 through 7. Level allocation is based on the network
hierarchy, where outermost domains are assigned a higher level than the innermost
domains.
Customer end points have the highest maintenance domain level. In a CFM maintenance
domain, each service instance is called a maintenance association. A maintenance
association can be thought as a full mesh of maintenance endpoints (MEPs) having
similar characteristics. MEPs are active CFM entities generating and responding to CFM
protocol messages.
There is also a maintenance intermediate point (MIP), which is a CFM entity similar to
the MEP, but more passive (MIPs only respond to CFM messages).
MEPs can be up MEPs or down MEPs. A link can connect a MEP at level 5 to a MEP at
level 7. The interface at level 5 is an up MEP (because the other end of the link is at MEP
level 7), and the interface at level 7 is a down MEP (because the other end of the link is
at MEP level 5).
In a Metro Ethernet network, CFM is commonly used at two levels:
• By the service provider to check the connectivity among its provider edge (PE) routers
• By the customer to check the connectivity among its customer edge (CE) routers
NOTE: The configured customer CFM level must be greater than service
provider CFM level.
In many Metro Ethernet networks, CFM is used to monitor connectivity over a VPLS and
bridge network.
NOTE: In ACX Series routers, VPLS is supported only on ACX5048 and

ACX5096 routers.
Related • Ethernet Operations, Administration, and Maintenance

Documentation
• Example: Configuring Ethernet CFM on Bridge Connections
• Example: Configuring Ethernet CFM on Physical Interfaces

IEEE 802.1ag OAM Connectivity Fault Management in ACX Series Overview
Ethernet interfaces on ACX Series routers support the IEEE 802.1ag standard for Operation,
Administration, and Management (OAM). The IEEE 802.1ag specification provides for
Ethernet connectivity fault management (CFM). The goal of CFM is to monitor an Ethernet
network that may comprise one or more service instances. Junos OS supports IEEE
802.1ag connectivity fault management.
NOTE: ACX Series routers support CFM on aggregated Ethernet interfaces

with continuity check interval of 100 milliseconds or higher.
Network entities such as operators, providers, and customers may be part of different
administrative domains. Each administrative domain is mapped into one maintenance
domain. Maintenance domains are configured with different level values to keep them
separate. Each domain provides enough information for the entities to perform their own
management, perform end-to-end monitoring, and still avoid security breaches.
IEEE 802.1ag OAM is supported on untagged, single VLAN tagged, and stacked VLAN
tagged interfaces.
• Connectivity Fault Management Key Elements on page 1128
Connectivity Fault Management Key Elements

Figure 61 on page 1128 shows the relationships among the customer, provider, and operator
Ethernet bridges, maintenance domains, maintenance association end points (MEPs),
and maintenance intermediate points (MIPs).
Figure 61: Relationship Among MEPs, MIPs, and Maintenance Domain

Levels
NOTE: Maintenance intermediate points (MIP) is supported only on ACX5048

and ACX5096 routers.

A maintenance association is a set of MEPs configured with the same maintenance

association identifier and maintenance domain level. Figure 62 on page 1129 shows the
hierarchical relationships between the Ethernet bridge, maintenance domains,
maintenance associations, and MEPs.
Figure 62: Relationship Among Bridges, Maintenance Domains,

Maintenance Associations, and MEPs
Documentation
• Configuring Ethernet Local Management Interface on ACX Series on page 1113
Configuring Maintenance Association Intermediate Points in ACX Series
Maintenance Intermediate Point (MIP) provides monitoring capability of intermediate

points for services such as Layer 2 bridging, Layer 2 circuit, and Layer 2 VPN. ACX5048
and ACX5096 routers support MIPs for the Ethernet OAM 802.1ag CFM protocol. Use
the bridge-domain, interface, and mip-half-function MIP options to specify the MIP
configuration.
NOTE: ACX5048 and ACX5096 routers do not support MIP configuration

on VPLS services.
NOTE: Whenever a MIP is configured and a bridge domain is mapped to

multiple maintenance domains or maintenance associations, it is essential
that the mip-half-function value for all maintenance domains and
maintenance associations be the same.
To display MIP configurations, use the show oam ethernet connectivity-fault-management

mip (bridge-domain | instance-name | interface-name) command.
The following MIP configurations are supported in ACX5048 and ACX5096 routers:

• MIP with with bridge domain
• MIP with circuit cross-connect (CCC)
• MIP with bridge domain when maintenance association end point is configured
• MIP with CCC when maintenance association end point is configured
The following sections describe MIP configuration:
• Configuring the Maintenance Domain Bridge Domain on page 1130

• Configuring the Maintenance Domain MIP Half Function on page 1130
• Configuring the Maintenance Association Intermediate Points with Bridge
Domain on page 1131
• Configuring the Maintenance Association Intermediate Points with Circuit
Cross-Connect on page 1131
• Configuring the Maintenance Association Intermediate Points with Bridge Domain
when Maintenance Association End Point is Configured on page 1131
• Configuring the Maintenance Intermediate Points with Circuit Cross-Connect when
Maintenance Association End Point is Configured on page 1132
Configuring the Maintenance Domain Bridge Domain

To configure the bridge domain, include the vlans statement at the [edit protocols oam
ethernet connectivity-fault-management maintenance-domain maintenance-domain-name]
hierarchy level.
Configuring the Maintenance Domain MIP Half Function

MIP Half Function (MHF) divides MIP functionality into two unidirectional segments,
improves visibility with minimal configuration, and improves network coverage by
increasing the number of points that can be monitored. MHF extends monitoring capability
by responding to loopback and linktrace messages to help isolate faults.
Whenever a MIP is configured and a bridge domain is mapped to multiple maintenance

domains or maintenance associations, it is essential that the MIP half function value for
all maintenance domains and maintenance associations be the same. To configure the
MIP half function, include the mip-half-function statement at the [edit protocols oam
ethernet connectivity-fault-management maintenance-domain maintenance-domain-name]
hierarchy level.

Configuring the Maintenance Association Intermediate Points with Bridge Domain

In ACX5048 and ACX5096 routers, you can configure the MIP with bridge domain. The
following is a sample to configure the MIP with bridge domain:
[edit protocols]
oam {
ethernet {
maintenance-domain default-6 {
vlan bd1;
mip-half-function default;
}
}
}
}
Configuring the Maintenance Association Intermediate Points with Circuit Cross-Connect

In ACX5048 and ACX5096 routers, you can configure the MIP with circuit cross-connect
(CCC). The following is a sample to configure the MIP with CCC:
[edit protocols]
oam {
ethernet {
maintenance-domain default-6 {
interface xe-0/0/42.0;
}
}
}
}
Configuring the Maintenance Association Intermediate Points with Bridge Domain when
Maintenance Association End Point is Configured
In ACX5048 and ACX5096 routers, you can configure the MIP with bridge domain when
a maintenance association end point (MEP) is configured. The following is a sample to
configure the MIP with bridge domain when MEP is configured:
[edit protocols]
oam {
ethernet {
maintenance-domain md2 {
level 5;
maintenance-association ma2 {
continuity-check {
interval 1s;
}
mep 222 {
direction up;

}
}
}
}
}
}
Configuring the Maintenance Intermediate Points with Circuit Cross-Connect when Maintenance
Association End Point is Configured
In ACX5048 and ACX5096 routers, you can configure the MIP with circuit cross-connect
(CCC) when a maintenance association end point (MEP) is configured. The following is
a sample to configure the MIP with CCC when MEP is configured:
[edit protocols]
oam {
ethernet {
maintenance-domain md2 {
level 5;
maintenance-association ma2 {
continuity-check {
interval 1s;
}
mep 222 {
direction up;
}
}
}
}
}
}
Related • bridge-domain
Documentation
• connectivity-fault-management
• instance
• mip-half-function
• IEEE 802.1ag OAM Connectivity Fault Management Overview
• Creating a Maintenance Domain
• Creating a Maintenance Association
• Configuring Continuity Check Protocol Parameters for Fault Detection
• Configuring Linktrace Protocol in CFM
• Configuring Ethernet Local Management Interface

• Configuring Port Status TLV and Interface Status TLV
• Configuring MAC Flush Message Processing in CET Mode
• Configuring Rate Limiting of Ethernet OAM Messages
Example: Configuring IEEE 802.3ah OAM Support for an Interface
Junos OS for ACX Series routers allows the Ethernet interfaces on these routers to support
the IEEE 802.3ah standard for the Operation, Administration, and Maintenance (OAM)
of Ethernet in access networks. The standard defines OAM link fault management (LFM).
You can configure IEEE 802.3ah OAM LFM on point-to-point Ethernet links that are
connected either directly or through Ethernet repeaters.
This example describes how to enable and configure OAM on a Gigabit Ethernet interface.
Requirements
• Junos OS Release 12.2 or later for ACX Series routers.
• An ACX1000 or ACX2000 router.

In this example, you configure a 10-Gigabit Ethernet interface on an ACX Series router
with 802.3ah OAM support, which includes: link discovery, protocol data units (PDUs),
remote loopback, negotiation, and event thresholds.
Configuring IEEE 802.3ah OAM on an ACX Series Router
CLI Quick To quickly configure IEEE 802.3ah Ethernet OAM, copy the following commands and
Configuration paste them into the CLI:
edit
edit protocols oam ethernet link-fault-management
set interface xe-0/0/0 link-discovery active pdu-interval 800 pdu-threshold 4
remote-loopback negotiation-options allow-remote-loopback
set interface xe-0/0/0 event-thresholds frame-error 30 frame-period 50
frame-period-summary 40 symbol-period 20

Step-by-Step To configure IEEE 802.3ah OAM support on an interface:

Procedure
1. Enable IEEE 802.3ah OAM support on an interface:
[edit protocols oam ethernet link-fault-management]
user@router1# set interface (OAM Link-Fault Management) xe-0/0/0
2. Specify that the interface initiates the discovery process by setting the link discovery
mode to active:
user@router# set interface xe-0/0/0 link-discovery active
3. Set the periodic OAM PDU-sending interval (in milliseconds) to 800:
user@router# set interface xe-0/0/0 pdu-interval 800
4. Define the number of OAM PDUs to miss before an error is logged as 4:
user@router# set interface xe-0/0/0 pdu-threshold 4
5. Configure the remote interface into loopback mode so that all frames except OAM
PDUs are looped back without any changes:
user@router# set interface xe-0/0/0 remote-loopback
6. Configure remote loopback support for the local interface:
user@router# set interface xe-0/0/0 negotiation-options allow-remote-loopback
7. Set the threshold count for sending frame error events to 30:
user@router# set interface xe-0/0/0 event-thresholds frame-error 30
8. Set the threshold count for sending frame period error events to 50:
user@router# set interface xe-0/0/0 event-thresholds frame-period 50
9. Configure the threshold count for sending frame period summary error events to
40:
user@router# set interface xe-0/0/0 event-thresholds frame-period-summary

40
10. Set the threshold count for sending symbol period events to 20:
user@router# set interface xe-0/0/0 event-thresholds symbol-period 20
Results Check the results of the configuration:
[edit]

user@router# show
[edit]
protocols {
oam {
ethernet {
link-fault-management {
interface xe-0/0/0 {
link-discovery active;
pdu-interval 800;
pdu-threshold 4;
remote-loopback;
negotiation-options {
allow-remote-loopback;
}
event-thresholds {
frame-error 30;
frame-period 50;
frame-period-summary 40;
symbol-period 20;
}
}
}
}
}
}
Related • link-fault-management
Documentation
• IEEE 802.3ah OAM Link-Fault Management Overview
• Configuring IEEE 802.3ah OAM Link-Fault Management
• Enabling IEEE 802.3ah OAM Support
Enabling Dying Gasp Functionality
Dying gasp means an unrecoverable condition such as a power failure. In this condition,
the local peer informs the remote peer about the failure state. When the remote peer
receives a dying-gasp PDU, it takes an action corresponding to the action profile configured
with the link-adjacency-loss event. Dying gasp helps to avoid file system corruption.
NOTE: ACX5096 and ACX5048 routers do not support dying-gasp.
ACX Series routers can generate and receive dying-gasp packets. When LFM is configured
on an interface, a dying-gasp PDU is generated for the interface on the following failure
conditions:
• Power failure

• Packet Forwarding Engine panic or a crash
ACX Series routers support the following CLI statements to enable dying-gasp
functionality:
• dgasp-int—Enables dying-gasp functionality.
• dgasp-usb—Resets USB port during dying-gasp event.
The dgasp-int and dgasp-usb CLI statements are added under the [edit system] hierarchy
to enable dying-gasp functionality.
To enable dying-gasp functionality, you need to configure the dgasp-int and dgasp-usb
CLI statements as shown below:
root@host% cli
root@host> configure
Entering configuration mode
[edit]
root@host# set system dgasp-int
[edit]
root@host# set system dgasp-usb
[edit]
root@host# commit
commit complete
[edit]
root@host# show system
dgasp-int;
dgasp-usb;
The dying-gasp functionality is disabled by default.
Documentation
Ethernet Alarm Indication Signal Overview
ACX Series routers support ITU-T Y.1731 Ethernet Alarm Indication Signal function
(ETH-AIS) to provide fault management for service providers. ETH-AIS enables you to
suppress alarms when a fault condition is detected. Using ETH-AIS, an administrator
can differentiate between faults at customer level or faults at provider level.
The advantage of ETH-AIS is:
• Customers need not raise alarms due to lower level failures.
• Customers can get refund based on service unavailability.
When a fault condition is detected, a maintenance end point (MEP) generates ETH-AIS
packets to the configured client levels for a specified duration until the fault condition is
cleared. Any MEP configured to generate ETH-AIS packets signals to a level higher than

its own. A MEP receiving ETH-AIS recognizes that the fault is at a lower level and then
suppresses alarms at current level.
ACX Series routers support ETH-AIS PDU generation for server MEPs based on the
following defect conditions:
• Loss of connectivity (physical link loss detection)
• Layer 2 circuit or Layer 2 VPN down
Alarm indication signaling is done through the transmission and propagation of ETH-AIS
PDUs. ETH-AIS should be enabled on MEPs. A MEP which is configured to issue packets
with ETH-AIS information is generally of server layer and continues to transmit periodic
packets with ETH-AIS information until the defect condition is cleared. CFM MEPs, upon
receiving ETH-AIS PDUs, suppresses loss of continuity alarms associated with its peer
MEPs. A MEP resumes loss of continuity alarm generation upon detecting loss of continuity
defect conditions in the absence of an ETH-AIS condition.
For point-to-point Ethernet connectivity, a MEP has only a single peer MEP. Therefore, a
MEP suppress alarms on its peer MEP when it receives the ETH-AIS information.
For multi-point Ethernet connectivity, a MEP which receives ETH-AIS information cannot
determine the exact MEP encountered a fault condition and therefore it will not be able
to isolate the exact peer MEP for alarm suppression. ITU-T Y.1731 recommends suppressing
alarms for all peer MEPs irrespective of the connectivity status.
AIS transmission—A MEP upon detecting a defect condition transmits ETH-AIS PDUs in
a direction opposite to its peer MEPs. The transmission of ETH-AIS PDUs is based on a
configured ETH-AIS transmission period. An ETH-AIS transmission period of 1 second is
recommended. The first ETH-AIS PDU must be transmitted immediately following the
detection of a defect condition.
AIS reception—A MEP upon receiving ETH-AIS PDUs examines it to ensure that its
maintenance domain (MD) level corresponds to the same MD level. Upon receiving an
ETH-AIS PDU, the MEP detects a defect condition. Following the detection of a defect
condition, if there are no ETH-AIS PDUs received within an interval of 3.5 times the
ETH-AIS transmission period indicated in the ETH-AIS PDUs received earlier, the MEP
clears the defect condition. After the fault condition is cleared, MEPs continue to report
alarms.
NOTE: ACX Series routers do not support ITU-T Y.1731 ETH-AIS for layer 2
services (bridging).
The following are the limitations for server MEP
• Triggering of ETH-AIS messages over services (Layer 2 circuit and Layer 2 VPN) by the
link-loss server MEP is done on a best-effort manner. This is because the transmission
of ETH-AIS messages is independent of the service status and there is no guarantee
for delivering the ETH-AIS messages before service goes down.

• Pseudowire protection with CFM-MEP session is not monitored by the server-MEP

because an entity to monitor pseudowire protection already exists for the service (Layer
2 circuit and Layer 2 VPN).
Related • Configuring Alarm Indication Signal on ACX Series Routers on page 1138
Documentation
Configuring Alarm Indication Signal on ACX Series Routers
ACX Series routers support ITU-T Y.1731 Ethernet Alarm Indication Signal function
(ETH-AIS) to provide fault management for service providers. ETH-AIS enables you to
suppress alarms when a fault condition is detected.
To support ETH-AIS transmission, the following configuration information is required by

a CFM MEP:
• Client Maintenance Entity Group level—Maintenance Entity Group (MEG) level at which
the immediate client layer Maintenance Domain Intermediate Points (MIPs) and
Maintenance Association End Points (MEPs) exist.
• ETH-AIS transmission period—Determines the ETH-AIS PDU transmission interval.
• Priority—Determines the priority of packets with ETH-AIS information. This is optional.
To configure ETH-AIS in CFM MEP, you need to:
• Configure an action profile with ETH-AIS action

• Attach the action profile to the CFM MEP
To configure an action profile with ETH-AIS action, include the following statements at
the [edit protocols oam ethernet connectivity-fault-management] hierarchy level:
[edit protocols oam ethernet connectivity-fault-management]

action-profile action-profile-name {
event {
adjacency-loss;
all-defects;
cross-connect-ccm;
errored-ccm;
receive-ais;
}
action {
log-and-generate-ais {
level [1-7];
interval 1s | 1m ;
priority [0-7];
}
log-ais;
}
}
To attach an action profile to a CFM MEP, include the following statements at the [edit
protocols oam ethernet connectivity-fault-management] hierarchy level:

maintenance-domain maintenenace-domain-name {
level level-number;
maintenance-association maintenance-domain-name {
continuity-check {
interval 1s;
loss-threshold 3;
}
mep mep-id {
direction up | down;
priority priority-value;
action-profile action-profile-name;
}
}
}
NOTE: You cannot configure a maintenance domain level that is lower than
or equal to the level that it is associated with.
To support ETH-AIS transmission, the following configuration information required by a

server MEP:
• Server MEP definition—Defines the association of server MEP identifier to the server
layer.
• For Layer 2 circuit and Layer 2 VPN, the logical interface connected to a customer
network (UNI) would be the identifier for the server layer that needs to be monitored
by the server MEP.
• For physical link loss detection, the physical interface under Ethernet protocol would
be the identifier for the server layer that needs to be monitored by the server MEP.
• Association of server MEP defect—Defines the association of server MEP defects to

ETH-AIS action.
• Association action profile and server MEP—Defines the binding of server MEP and
action profile.
To configure ETH-AIS in server MEP, you need to:
• Create an action profile with ETH-AIS action for server MEP defects.
• Attach the action profile to a server MEP
To create an action profile, include the following statements at the [edit protocols oam
ethernet connectivity-fault-management] hierarchy level:

action-profile action-profile-name {
event {
server-mep-defects {
link-loss-defect;
l2circuit-defect;
l2vpn-defect;
}

}
action {
log-and-generate-ais {
level 1…n;
interval 1 second | 1 minute;
priority dot1p [range 0-7];
}
}
}
To attach an action profile to a server MEP, include the following statement at the [edit
protocols oam ethernet connectivity-fault-management] hierarchy level:

server-mep mep-identifier {
protocol l2circuit | l2vpn | ethernet {
}
action-profile action-profile-name;
}
Related • Ethernet Alarm Indication Signal Overview on page 1136

Documentation
Ethernet Synthetic Loss Measurement Overview
Ethernet synthetic loss measurement (ETH-SLM) is an application that enables the

calculation of frame loss by using synthetic frames instead of data traffic. This mechanism
can be considered as a statistical sample to approximate the frame loss ratio of data
traffic. Each maintenance association end point (MEP) performs frame loss
measurements, which contribute to unavailable time.
A near-end frame loss specifies frame loss associated with ingress data frames and a
far-end frame loss specifies frame loss associated with egress data frames. Both near-end
and far-end frame loss measurements contribute to near-end severely errored seconds
and far-end severely errored seconds that are used in combination to determine
unavailable time. ETH-SLM is performed using synthetic loss message (SLM) and
synthetic loss reply (SLR) frames. ETH-SLM facilitates each MEP to perform near-end
and far-end synthetic frame loss measurements by using synthetic frames because a
bidirectional service is defined as unavailable if either of the two directions is determined
to be unavailable.
There are the two types of frame loss measurement, defined by the ITU-T Y.1731 standards,
ETH-LM and ETH-SLM. Junos OS supports only single-ended ETH-SLM. In single-ended
ETH-SLM, each MEP sends frames with the ETH-SLM request information to its peer
MEP and receives frames with ETH-SLM reply information from its peer MEP to perform
synthetic loss measurements. Single-ended ETH-SLM is used for proactive or on-demand
OAM to perform synthetic loss measurements applicable to point-to-point Ethernet
connection. This method allows a MEP to initiate and report far-end and near-end loss
measurements associated with a pair of MEPs that are part of the same maintenance
entity group (MEG).

NOTE: MX Series Virtual Chassis does not support Ethernet synthetic loss
measurement (ETH-SLM).
Single-ended ETH-SLM is used to perform on-demand or proactive tests by initiating a

finite amount of ETH-SLM frames to one or multiple MEP peers and receiving the ETH-SLM
reply from the peers. The ETH-SLM frames contain the ETH-SLM information that is
used to measure and report both near-end and far-end synthetic loss measurements.
Service-level agreement (SLA) measurement is the process of monitoring the bandwidth,
delay, delay variation (jitter), continuity, and availability of a service. It enables you to
identify network problems before customers are impacted by network defects. In proactive
mode, SLA measurements are triggered by an iterator application. An iterator is designed
to periodically transmit SLA measurement packets in the form of ITU-Y.1731-compliant
frames for synthetic frame loss measurement . This mode differs from on-demand SLA
measurement, which is user initiated. In on-demand mode, the measurements are
triggered by the user through the CLI. When the user triggers the ETH-SLM through the
CLI, the SLM request that is generated is as per the frame formats specified by the ITU-T
Y.1731 standard.
NOTE: ACX5048 and ACX5096 routers support ETH-SLM for Layer 2 services.
Related • Transmission of ETH-SLM Messages on page 1141

Documentation
• Troubleshooting Failures with ETH-SLM
Transmission of ETH-SLM Messages
The ETH-SLM functionality can process multiple synthetic loss message (SLM) requests
simultaneously between a pair of MEPs. The session can be a proactive or an on-demand
SLM session. Each SLM request is identified uniquely by a test ID.
A MEP can send SLM requests or respond to SLM requests. A response to an SLM request
is called a synthetic loss reply (SLR). After a MEP determines an SLM request by using
the test ID, the MEP calculates the far-end and near-end frame loss on the basis of the
information in the SLM message or the SLM protocol data unit (PDU).

A MEP maintains the following local counters for each test ID and for each peer MEP
being monitored in a maintenance entity for which loss measurements are to be
performed:
• TxFCl—Number of synthetic frames transmitted toward the peer MEP for a test ID. A
source MEP increments this number for successive transmission of synthetic frames
with ETH-SLM request information while a destination or receiving MEP increments
this value for successive transmission of synthetic frames with the SLR information.
• RxFCl—Number of synthetic frames received from the peer MEP for a test ID. A source
MEP increments this number for successive reception of synthetic frames with SLR
information while a destination or receiving MEP increments it for successive reception
of synthetic frames with ETH-SLM request information.
The following sections describe the phases of processing of SLM PDUs to determine
synthetic frame loss:
Initiation and Transmission of SLM Requests

A MEP periodically transmits an SLM request with the OpCode field set as 55. The MEP
generates a unique Test ID for the session, adds the source MEP ID, and initializes the
local counters for the session before SLM initiation. For each SLM PDU transmitted for
the session (test ID), the local counter TxFCl is sent in the packet.
No synchronization is required of the test ID value between initiating and responding

MEPs because the test ID is configured at the initiating MEP, and the responding MEP
uses the test ID it receives from the initiating MEP. Because ETH-SLM is a sampling
technique, it is less precise than counting the service frames. Also, the accuracy of
measurement depends on the number of SLM frames used or the period for transmitting
SLM frames.
Reception of SLMs and Transmission of SLRs

After the destination MEP receives a valid SLM frame from the source MEP, an SLR frame
is generated and transmitted to the requesting or source MEP. The SLR frame is valid if
the MEG level and the destination MAC address match the receiving MEP’s MAC address.
All the fields in the SLM PDUs are copied from the SLM request except for the following
fields:
• The source MAC address is copied to the destination MAC address and the source
address contains the MEP’s MAC address.
• The value of the OpCode field is changed from SLM to SLR (54).
• The responder MEP ID is populated with the MEP’s MEP ID.
• TxFCb is saved with the value of the local counter RxFCl at the time of SLR frame
transmission.
• An SLR frame is generated every time an SLM frame is received; therefore, RxFCl in
the responder is equal to the number of SLM frames received and also equal to the
number of SLR frames sent. At the responder or receiving MEP, RxFCl equals TxFCl.

Reception of SLRs
After an SLM frame (with a given TxFCf value) is transmitted, a MEP expects to receive
a corresponding SLR frame (carrying the same TxTCf value) within the timeout value
from its peer MEP. SLR frames that are received after the timeout value (5 seconds) are
discarded. With the information contained in SLR frames, a MEP determines the frame
loss for the specified measurement period. The measurement period is a time interval
during which the number of SLM frames transmitted is statistically adequate to make a
measurement at a given accuracy. A MEP uses the following values to determine near-end
and far-end frame loss during the measurement period:
• Last received SLR frame's TxFCf and TxFCb values and the local counter RxFCl value
at the end of the measurement period. These values are represented as TxFCf[tc],
TxFCb[tc], and RxFCl[tc], where tc is the end time of the measurement period.
• SLR frame's TxFCf and TxFCb values of the first received SLR frame after the test
starts and local counter RxFCl at the beginning of the measurement period. These
values are represented as TxFCf[tp], TxFCb[tp], and RxFCl[tp], where tp is the start
time of the measurement period.
For each SLR packet that is received, the local RxFCl counter is incremented at the sending
or source MEP.
Computation of Frame Loss

Synthetic frame loss is calculated at the end of the measurement period on the basis of
the value of the local counters and the information from the last frame received. The
last received frames contains the TxFCf and TxFCb values. The local counter contains
the RxFCl value. Using these values, frame loss is determined using the following formula:
Frame loss (far-end) = TxFCf – TxFCb
Frame loss (near-end) = TxFCb – RxFCl
Related • Ethernet Synthetic Loss Measurement Overview on page 1140

Documentation

Format of ETH-SLM Messages
Synthetic loss messages (SLMs) support single-ended Ethernet synthetic loss

measurement (ETH-SLM) requests. This topic contains the following sections that
describe the formats of the SLM protocol data units (PDUs), SLR PDUs, and the data
iterator type length value (TLV).
SLM PDU Format

The SLM PDU format is used by a MEP to transmit SLM information. The following
components are contained in SLM PDUs:
• Source MEP ID—Source MEP ID is a 2-octet field where the last 13 least significant bits
are used to identify the MEP transmitting the SLM frame. MEP ID is unique within the
MEG.
• Test ID—Test ID is a 4-octet field set by the transmitting MEP and is used to identify a
test when multiple tests run simultaneously between MEPs (including both concurrent
on-demand and proactive tests).
• TxFCf—TxFCf is a 4-octet field that carries the number of SLM frames transmitted by
the MEP toward its peer MEP.
The following are the fields in an SLM PDU:
• MEG Level—Configured maintenance domain level in the range 0–7.
• Version—0.
• OpCode—Identifies an OAM PDU type. For SLM, it is 55.
• Flags—Set to all zeros.
• TLV Offset—16.
• Source MEP ID—A 2-octet field used to identify the MEP transmitting the SLM frame.
In this 2-octet field, the last 13 least significant bits are used to identify the MEP
transmitting the SLM frame. MEP ID is unique within the MEG.
• RESV—Reserved fields are set to all zeros.
• Test ID—A 4-octet field set by the transmitting MEP and used to identify a test when
multiple tests run simultaneously between MEPs (including both concurrent on-demand
and proactive tests).
• TxFCf—A 4-octet field that carries the number of SLM frames transmitted by the MEP
toward its peer MEP.
• Optional TLV—A data TLV may be included in any SLM transmitted. For the purpose
of ETH-SLM, the value part of data TLV is unspecified.
• End TLV—All zeros octet value.

SLR PDU Format

The synthetic loss reply (SLR) PDU format is used by a MEP to transmit SLR information.
The following are the fields in an SLR PDU:
• MEG Level—A 3-bit field the value of which is copied from the last received SLM PDU.
• Version—A 5-bit field the value of which is copied from the last received SLM PDU.
• OpCode—Identifies an OAM PDU type. For SLR, it is set as 54.
• Flags—A 1-octet field copied from the SLM PDU.
• TLV Offset—A 1-octet field copied from the SLM PDU.
• Source MEP ID—A 2-octet field copied from the SLM PDU.
• Responder MEP ID—A 2-octet field used to identify the MEP transmitting the SLR
frame.
• Test ID—A 4-octet field copied from the SLM PDU.
• TxFCf—A 4-octet field copied from the SLM PDU.
• TxFCb—A 4 octet field. This value represents the number of SLR frames transmitted
for this test ID.
• Optional TLV—The value is copied from the SLM PDU, if present.
• End TLV—A 1-octet field copied from the SLM PDU.
Data Iterator TLV Format

The data iterator TLV specifies the data TLV portion of the Y.1731 data frame. The MEP
uses a data TLV when the MEP is configured to measure delay and delay variation for
different frame sizes. The following are the fields in a data TLV:
• Type—Identifies the TLV type; value for this TLV type is Data (3).
• Length—Identifies the size, in octets, of the Value field containing the data pattern.
The maximum value of the Length field is 1440.
• Data pattern—An n-octet (n denotes length) arbitrary bit pattern. The receiver ignores
it.

Documentation

Guidelines for Configuring ETH-SLM
Keep the following points in mind when you configure the ETH-SLM functionality:
• The monitoring application for Ethernet OAM is initiated in the master Routing Engine.
When a stateful switchover process occurs, the monitoring application is disabled. For
on-demand ETH-SLM, graceful Routing Engine switchover (GRES) support is not
applicable. For proactive ETH-SLM, the service-level agreement (SLA) iterators are
restored during a stateful switchover process. If the adjacencies do not time out, the
ETH-SLM statistics are preserved and proactive ETH-SLM supports GRES.
• ETH-SLM is initiated only when the MEP session is up. Unified in-service software
upgrade (ISSU) support for ETH-SLM depends on the unified ISSU support for CFM.
For CFM, unified ISSU is supported using the loss threshold TLV to avoid CFM
connectivity loss during the upgrade. The receiving or the destination MEP increases
the threshold time during the termination of sessions. If you start a unified ISSU
operation when on-demand ETH-SLM is in progress, the SLM request and reply
messages are lost at the local Packet Forwarding Engine.
When an on-demand ETH-SLM is requested, if the local source MEP undergoes a

unified ISSU, a message is displayed stating that the MEP is undergoing a unified ISSU.
If the remote MEP is undergoing a unified ISSU (detected through the loss threshold
TLV), a message is displayed stating that the remote MEP is undergoing a unified ISSU.
Also, if it is not possible to identify whether unified ISSU is in progress on a remote MEP,
the SLM packets are lost at the system where unified ISSU is in progress and the loss
calculation results do not provide a valid cause for the loss. Unified ISSU is not
supported for both on-demand and proactive ETH-SLM.
• The maximum number of SLA iterator profiles that can be configured in the system is
255.
• ETH-SLM is not supported for virtual private LAN service (VPLS) (point-to-multipoint
measurements are not supported). The ETH-SLM frames are not generated with
multicast class 1 destination address. Similarly, ETH-SLM does not respond to ETH-SLM
requests with multicast DA. ETH-SLM for VPLS for point-to-point Ethernet connection
is supported using directed unicast destination MAC addresses, although
point-to-multipoint topologies are not supported.
• A unicast destination address may be used in provisioned environments for

point-to-point connections. However, it requires that the unicast destination address
of the downstream MEP must have been configured on the MEP transmitting an alarm
indication signal (AIS).
• ETH-SLM is not supported on downstream MEPs on label-switched interfaces (LSIs).
• ETH-SLM is supported on aggregated Ethernet (ae) interfaces
• The number of ETH-SLM sessions for proactive ETH-SLM that can be supported is
limited to the total number of iterators that can be supported in the system. This

limitation includes the iterator support for other measurement types such as loss,
statistical frame loss, and two-way delay. A new iterator type, SLM, is added to support
ETH-SLM. The total number of SLA iterators that you can configure in the system is
equal to the total number of iterations supported in the system.
• For on-demand SLM, the minimum period between two SLM requests is 100
milliseconds.
• For proactive SLM, the minimum period between two SLM requests is 10 milliseconds
for distributed mode and 100 milliseconds for non-distributed mode.
• ETH-SLM frames are always marked as drop-ineligible in compliance with the ITU-T
Y.1731 standard.

Documentation
Scenarios for Configuration of ETH-SLM
ETH-SLM measures near-end and far-end frame loss between two MEPs that are part
of the same MEG level. You can configure ETH-SLM to measure synthetic loss for both
upward-facing or upstream MEP and downward-facing or downstream MEP. This section
describes the following scenarios for the operation of ETH-SLM:
Upstream MEP in MPLS Tunnels

Consider a scenario in which a MEP is configured between the user network interfaces
(UNIs) of two MX Series routers, MX1 and MX2, in the upstream direction. MX1 and MX2
are connected over an MPLS core network. ETH-SLM measurements are performed
between the upstream MEP in the path linking the two routers. Both MX1 and MX2 can
initiate on-demand or proactive ETH-SLM, which can measure both far-end and near-end
loss at MX1 and MX2, respectively. The two UNIs are connected using MPLS-based Layer
2 VPN virtual private wire service (VPWS).
Downstream MEP in Ethernet Networks

Consider a scenario in which a MEP is configured between two MX Series routers, MX1
and MX2, on the Ethernet interfaces in the downstream direction. MX1 and MX2 are
connected in an Ethernet topology and downstream MEP is configured toward the

Ethernet network. ETH-SLM measurements are performed between the downstream

MEP in the path linking the two routers. ETH-SLM can be measured in the path between
these two routers.
Consider another scenario in which a MEP is configured in the downstream direction and
service protection for a VPWS over MPLS is enabled by specifying a working path or
protect path on the MEP. Service protection provides end-to-end connection protection
of the working path in the event of a failure. To configure service protection, you must
create two separate transport paths—a working path and a protect path. You can specify
the working path and protect path by creating two maintenance associations. To associate
the maintenance association with a path, you must configure the MEP interface in the
maintenance association and specify the path as working or protect.
In a sample topology, an MX Series router, MX1, is connected to two other MX Series

routers, MX2 and MX3, over an MPLS core. The connectivity fault management (CFM)
session between MX1 and MX2 is the working path on the MEP and the CFM session
between MX1 and MX3 is the protect path on the MEP. MX2 and MX3 are, in turn,
connected on Ethernet interfaces to MX4 in the access network. Downstream MEP is
configured between MX1 and MX4 that passes through MX2 (working CFM session) and
also between MX1 and MX4 that passes through MX3 (protected CFM session). ETH-SLM
is performed between these downstream MEPs. In both the downstream MEPs, the
configuration is performed on MX1 and MX4 UNIs, similar to upstream MEP.

Documentation
Managing ETH-SLM Statistics and ETH-SLM Frame Counts
• Displaying ETH-SLM Statistics Only on page 1149

• Displaying ETH-SLM Statistics and Frame Counts on page 1149
• Displaying ETH-SLM Frame Counts for MEPs by Enclosing CFM Entity on page 1150
• Displaying ETH-SLM Frame Counts for MEPs by Interface or Domain Level on page 1151
• Clearing ETH-SLM Statistics and Frame Counts on page 1151
• Clearing Iterator Statistics on page 1152

Displaying ETH-SLM Statistics Only
Purpose Display on-demand ETH-SLM statistics.
By default, the show oam ethernet connectivity-fault-management synthetic-loss-statistics

command displays on-demand ETH-SLM statistics for MEPs in the specified CFM
maintenance association within the specified CFM maintenance domain.
Action • To display the on-demand ETH-SLM statistics collected for MEPs belonging to
maintenance association ma1 within maintenance domain md1:
user@host> show oam ethernet connectivity-fault-management synthetic-loss-statistics

maintenance-domain md1 maintenance-association ma1
• To display the on-demand ETH-SLM statistics collected for ETH-SLM sessions for the
local MEP 201 belonging to maintenance association ma2 within maintenance
domain md2:

maintenance-domain md2 maintenance-association ma2 local-mep 201
• To display the on-demand ETH-SLM statistics collected for ETH-SLM sessions from
local MEPs belonging to maintenance association ma3 within maintenance domain md3
to the remote MEP 302:

maintenance-domain md3 maintenance-association ma3 remote-mep 302
Meaning The output displays on-demand ETH-SLM statistics for MEPs in the specified maintenance
association within the specified maintenance domain. For details about the output of
this command and the descriptions of the output fields, see show oam ethernet
connectivity-fault-management synthetic-loss-statistics.
Displaying ETH-SLM Statistics and Frame Counts
Purpose Display on-demand ETH-SLM statistics and ETH-SLM frame counts.
By default, the show oam ethernet connectivity-fault-management mep-statistics

command displays on-demand ETH-SLM statistics and frame counts for MEPs in the
specified CFM maintenance association within the specified CFM maintenance domain.
Action • To display the on-demand ETH-SLM statistics and ETH-SLM frame counts for MEPs
in maintenance association ma1 within maintenance domain md1:
user@host> show oam ethernet connectivity-fault-management mep-statistics

maintenance-domain md1 maintenance-association ma1

• To display the on-demand ETH-SLM statistics and ETH-SLM frame counts for the
local MEP 201 in maintenance association ma2 within maintenance domain md2:

• To display the on-demand ETH-SLM statistics and ETH-SLM frame counts for the
local MEP in maintenance association ma3 within maintenance domain md3 that
participates in an ETH-SLM session with the remote MEP 302:

maintenance-domain ma3 maintenance-association ma3 remote-mep 302
Meaning The output displays on-demand ETH-SLM statistics and ETH-SLM frame counts for
MEPs in the specified maintenance association within the specified maintenance domain.
For details about the output of this command and the descriptions of the output fields,
see show oam ethernet connectivity-fault-management mep-statistics.
Displaying ETH-SLM Frame Counts for MEPs by Enclosing CFM Entity
Purpose Display on-demand ETH-SLM frame counts for CFM maintenance association end points
(MEPs).
By default, the show oam ethernet connectivity-fault-management mep-database

command displays CFM database information for MEPs in the specified CFM maintenance
association within the specified CFM maintenance domain.
NOTE: At the router attached to the initiator MEP for a one-way session, or
at the router attached to the receiver MEP for a two-way session, you can
only display the ETH-SLM frame counts and not the MEP database details.
Action • To display CFM database information (including ETH-SLM frame counts) for all MEPs
in MA ma1 within maintenance domain md1:
user@host> show oam ethernet connectivity-fault-management mep-database

maintenance-domain ma1 maintenance-association ma1
• To display CFM database information (including ETH-SLM frame counts) only for the
local MEP 201 in MA ma1 within maintenance domain md1:

remote MEP 302 in MA ma3 within maintenance domain md3:


maintenance-domain ma3 maintenance-association ma3 remote-mep 302
Meaning The output displays ETH-SLM frame counts for MEPs within a particular maintenance
domain, or for a specific local or remote MEP. For details about the output of this
command and the descriptions of the output fields, see show oam ethernet
connectivity-fault-management mep-database.
Displaying ETH-SLM Frame Counts for MEPs by Interface or Domain Level
Purpose Display on-demand ETH-SLM frame counts for CFM maintenance association end points
(MEPs).
By default, the show oam ethernet connectivity-fault-management interfaces command

displays CFM database information for MEPs attached to CFM-enabled Ethernet
interfaces on the router or at a maintenance domain level. For Ethernet interfaces that
support ETH-SLM, any frame counts are also displayed when you specify the detail or
extensive command option.
NOTE: At the router attached to the initiator MEP, you can only display the
ETH-SLM frame counts and not the MEP database details.
Action • To display CFM database information (including ETH-SLM frame counts) for all MEPs
attached to CFM-enabled Ethernet interfaces on the router:
user@host> show oam ethernet connectivity-fault-management interfaces detail
MEPs attached to CFM-enabled router interface ge-5/2/9.0:
user@host> show oam ethernet connectivity-fault-management interfaces ge-5/2/9.0 detail
• To display CFM database information (including ETH-SLM frame counts) only for
MEPs enclosed within CFM maintenance domains at level 6:
user@host> show oam ethernet connectivity-fault-management interfaces level 6 detail
Meaning The output displays ETH-SLM frame counts for MEPs for the specified interface. For
details about the output of this command and the descriptions of the output fields, see
show oam ethernet connectivity-fault-management interfaces.
Clearing ETH-SLM Statistics and Frame Counts
Purpose Clear the on-demand ETH-SLM statistics and ETH-SLM frame counts.

By default, statistics and frame counts are deleted for all MEPs attached to CFM-enabled
interfaces on the router. However, you can filter the scope of the command by specifying
an interface name.
Action • To clear the on-demand ETH-SLM statistics and ETH-SLM frame counts for all MEPs
attached to CFM-enabled interfaces on the router:
user@host> clear oam ethernet connectivity-fault-management synthetic-loss-measurement
• To clear the on-demand ETH-SLM statistics and ETH-SLM frame counts only for MEPs
attached to the logical interface ge-0/5.9.0:
user@host> clear oam ethernet connectivity-fault-management synthetic-loss-measurement

ge-0/5/9.0
Clearing Iterator Statistics
Purpose Clear the existing iterator statistics and proactive ETH-SLM counters.
Multiple iterators can be associated with remote MEP. However, by default, only one
result pertaining to one iterator profile can be cleared.
Action • To clear the iterator statistics for remote MEP 1 and iterator profile i1 with MEPs
belonging to the maintenance association ma1 within the maintenance domain
default-1:
user@host> clear oam ethernet connectivity-fault-management sla-iterator-statistics

sla-iterator i1 maintenance-domain default-1 maintenance-association ma1 local-mep 1
remote-mep 1
• To clear the iterator statistics for remote MEP 1 and iterator profile i2 with MEPs
belonging to the maintenance association ma1 within the maintenance domain default-1:
user@host> clear oam ethernet connectivity-fault-management sla-iterator-statistics

sla-iterator i2 maintenance-domain default-1 maintenance-association ma1 local-mep 1
remote-mep 1
Related • clear oam ethernet connectivity-fault-management synthetic-loss-measurement on

• show oam ethernet connectivity-fault-management synthetic-loss-statistics on page 2807
• show oam ethernet connectivity-fault-management interfaces on

page 2768 (detail | extensive)
• show oam ethernet connectivity-fault-management mep-statistics on page 2779
• show oam ethernet connectivity-fault-management mep-database on page 2791

Starting a Proactive ETH-SLM Session
To start a proactive Ethernet synthetic loss measurement (ETH-SLM) session, you must
configure the Ethernet interfaces on maintenance association end points (MEPs) on
which packets transmitted with synthetic frame loss need to be analyzed. You must then
create an iterator profile to transmit service-level agreement (SLA) measurement packets
for ETH-SLM and associate the local and remote MEPs with the profile.
• Configuring MEP Interfaces on page 1153

• Configuring an Iterator Profile for ETH-SLM on page 1154
• Associating the Iterator Profile with MEPs for ETH-SLM on page 1155
Configuring MEP Interfaces

Before you can start an Ethernet synthetic frame loss measurement session across an
Ethernet service, you must configure two ACX Series routers to support ETH-SLM.
To configure an Ethernet interface on an ACX Series router to support ETH-SLM:
1. On each router, configure two physical or logical Ethernet interfaces connected by a

VLAN. The following configuration is typical for single-tagged logical interfaces:
[edit interfaces]
interface {
ethernet-interface-name {
vlan-tagging;
vlan-id vlan-id; # Both interfaces on this VLAN
}
}
}
Both interfaces will use the same VLAN ID.
2. On each router, attach peer MEPs to the two interfaces. The following configuration
is typical:
[edit protocols]
oam {
ethernet {
maintenance-domain md-name { # On both routers
level number;
maintenance-association ma-name { # On both routers
continuity-check {
interval 100ms;
hold-interval 1;
}
mep mep-id { # Attach to VLAN interface
auto-discovery;
direction (up | down);
priority number;

}
}
}
}
}
}
Configuring an Iterator Profile for ETH-SLM

You can create an iterator profile with its parameters to periodically transmit SLA
measurement packets in the form of ITU-Y.1731-compliant frames for synthetic loss
measurement.
NOTE: ACX5048 and ACX5096 routers supports iterator cycle time of only
1 second and above.
To create an iterator profile:
[edit]
user@host# edit protocols oam ethernet connectivity-fault-management
performance-monitoring
2. Configure the SLA measurement monitoring iterator:
[edit protocols oam ethernet connectivity-fault-management performance-monitoring]

user@host# edit sla-iterator-profiles
3. Configure an iterator profile—for example, i1:
[edit protocols oam ethernet connectivity-fault-management performance-monitoring

sla-iterator-profiles]
user@host# set i1
4. (Optional) Configure the cycle time, which is the amount of time (in milliseconds)
between back-to-back transmission of SLA frames for one connection, with a value
from 10 through 3,600,000. The default value is 1000 ms.

sla-iterator-profiles i1]
user@host# set cycle-time cycle-time-value
5. (Optional) Configure the iteration period, which indicates the maximum number of
cycles per iteration (the number of connections registered to an iterator cannot exceed
this value), with a value from 1 through 2000. The default value is 2000.

user@host# set iteration-period iteration-period-value

6. Configure the measurement type as synthetic loss measurement.

user@host# set measurement-type slm
7. Configure the disable statement to stop the iterator (that is, disable the iterator profile).

user@host# set disable

sla-iterator-profiles]
user@host# show i1
cycle-time cycle-time-value;
iteration-period iteration-period-value;
measurement-type slm;
Associating the Iterator Profile with MEPs for ETH-SLM

You can associate a remote maintenance association end point (MEP) with more than
one iterator profile.
To configure a remote MEP with an iterator profile:
user@host# edit protocols oam ethernet connectivity-fault-management

maintenance-domain md-name maintenance-association ma-name mep mep-id
2. Configure the remote MEP ID with a value from 1 through 8191.
[edit protocols oam ethernet connectivity-fault-management maintenance-domain

md-name maintenance-association ma-name mep mep-id]
user@host# set remote-mep remote-mep-id
3. Set the iterator profile.

md-name maintenance-association ma-name mep mep-id remote-mep
remote-mep-id]
user@host# set sla-iterator-profile profile-name
4. (Optional) Set the size of the data TLV portion of the Y.1731 data frame with a value
from 1 through 1400 bytes. The default value is 1.

md-name maintenance-association ma-name mep mep-id remote-mep remote-mep-id
sla-iterator-profile profile-name]
user@host# set data-tlv-size size

5. (Optional) Set the iteration count, which indicates the number of iterations for which
this connection should partake in the iterator for acquiring SLA measurements, with
a value from 1 through 65,535. The default value is 0 (that is, infinite iterations).

user@host# set iteration-count count-value
6. (Optional) Set the priority, which is the vlan-pcp value that is sent in the Y.1731 data
frames, with a value from 0 through 7. The default value is 0.

user@host# set priority priority-value

md-name maintenance-association ma-name mep mep-id remote-mep
remote-mep-id]
user@host# show
sla-iterator-profile profile-name {
data-tlv-size size;
iteration-count count-value;
priority priority-value;
}

Documentation
Starting an On-Demand ETH-SLM Session
To start an on-demand Ethernet synthetic loss measurement (ETH-SLM) session, type

the monitor ethernet synthetic-loss-measurement one-way command in operational
mode, and specify the peer MEP by its MAC address or by its MEP identifier.
For example:

user@host> monitor ethernet synthetic-loss-measurement 00:05:85:73:39:4a

maintenance-domain md6 maintenance-association ma6 count 10
ETH-SLM request to 00:05:85:73:39:4a, interface ge-1/0/0.0
Synthetic Loss measurement statistics:
SLM packets sent : 100
SLR packets received : 100
Accumulated SLM statistics:
Local TXFC1 value : 100
Local RXFC1 value : 100
Last Received SLR frame TXFCf(tc) : 100
Last Received SLR frame TXFCb(tc) : 100
SLM Frame Loss:
Frame Loss (far-end) : 0 (0.00 %)
Frame Loss (near-end) : 0 (0.00 %)
NOTE: If you attempt to monitor delays to a nonexistent MAC address, you

must press Ctrl + C to explicitly quit the monitor ethernet
synthetic-loss-measurement command and return to the CLI command
prompt.

Documentation
Dynamic Ternary Content Addressable Memory Overview
• Understanding Dynamic Ternary Content Addressable Memory on page 1157

• Applications using Dynamic TCAM Infrastructure on page 1158
• Features Using TCAM Resource on page 1158
• Monitoring TCAM Resource Usage on page 1161
• Example: Monitoring and Troubleshooting the TCAM Resource on page 1162
Understanding Dynamic Ternary Content Addressable Memory

In ACX Series routers, Ternary Content Addressable Memory (TCAM) is used by various
applications like firewall, connectivity fault management, PTPoE, RFC 2544, etc. The
Packet Forwarding Engine (PFE) in ACX Series routers uses TCAM with defined TCAM

space limits. The allocation of TCAM resources for various filter applications are statically
distributed. This static allocation leads to inefficient utilization of TCAM resources when
all the filter applications might not use this TCAM resource simultaneously.
The dynamic allocation of TCAM space in ACX routers efficiently allocates the available
TCAM resources for various filter applications. In the dynamic TCAM model, various filter
applications (such as inet-firewall, bridge-firewall, cfm-filters, etc.) can optimally utilize
the available TCAM resources as and when required. Dynamic TCAM resource allocation
is usage driven and is dynamically allocated for filter applications on a need basis. When
a filter application no longer uses the TCAM space, the resource is freed and available
for use by other applications. This dynamic TCAM model caters to higher scale of TCAM
resource utilization based on application’s demand.
Applications using Dynamic TCAM Infrastructure

The following filter application categories use the dynamic TCAM infrastructure:
• Firewall filter—All the firewall configurations
• Implicit filter—Routing Engine (RE) demons using filters to achieve its functionality.
For example, connectivity fault management, IP MAC validation, etc.
• Dynamic filters—Applications using filters to achieve the functionality at the PFE level.
For example, logical interface level fixed classifier, RFC 2544, etc. RE demons will not
know about these filters.
• System-init filters—Filters that require entries at the system level or fixed set of entries
at router's boot sequence. For example, Layer 2 and Layer 3 control protocol trap,
default ARP policer, etc.
NOTE: The System-init filter which has the applications for Layer 2 and
Layer 3 control protocols trap is essential for the overall system
functionality. The applications in this control group consume a fixed and
minimal TCAM space from the overall TCAM space. The system-init filter
will not use the dynamic TCAM infrastructure and will be created when the
router is initialized during the boot sequence.
Features Using TCAM Resource

Applications using the TCAM resource is termed tcam-app in this document. For example,
inet-firewall, bridge-firewall, connectivity fault management, link fault management,
etc., are all different tcam-apps.
Table 82 on page 1159 describes the list of tcam-apps that use TCAM resources.

Table 82: Features Using TCAM Resource

TCAM Apps/TCAM Users Feature/Functionality TCAM Stage
bd-dtag-validate Bridge domain dual-tagged validate Egress
NOTE: This feature is not supported on ACX5048 and ACX5096

routers.
bd-tpid-swap Bridge domain vlan-map with swap tpid operation Egress
cfm-bd-filter Connectivity fault management implicit bridge-domain filters Ingress
cfm-filter Connectivity fault management implicit filters Ingress
cfm-vpls-filter Connectivity fault management implicit vpls filters Ingress
NOTE: This feature is supported only on ACX5048 and ACX5096

routers.
cfm-vpls-ifl-filter Connectivity fault management implicit vpls logical interface filters Ingress
NOTE: This feature is supported only on ACX5048 and ACX5096

routers.
cos-fc Logical interface level fixed classifier Pre-ingress
fw-ccc-in Circuit cross-connect family ingress firewall Ingress
fw-family-out Family level egress firewall Egress
fw-fbf Firewall filter-based forwarding Pre-ingress
fw-fbf-inet6 Firewall filter-based forwarding for inet6 family Pre-ingress
fw-ifl-in Logical interface level ingress firewall Ingress
fw-ifl-out Logical interface level egress firewall Egress
fw-inet-ftf Inet family ingress firewall on a forwarding-table Ingress
fw-inet6-ftf Inet6 family ingress firewall on a forwarding-table Ingress
fw-inet-in Inet family ingress firewall Ingress
fw-inet-rpf Inet family ingress firewall on RPF fail check Ingress
fw-inet6-in Inet6 family ingress firewall Ingress
fw-inet6-family-out Inet6 Family level egress firewall Egress
fw-inet6-rpf Inet6 family ingress firewall on a RPF fail check Ingress

Table 82: Features Using TCAM Resource (continued)

fw-inet-pm Inet family firewall with port-mirror action Ingress

routers.
fw-l2-in Bridge family ingress firewall on Layer 2 interface Ingress
fw-mpls-in MPLS family ingress firewall Ingress
fw-semantics Firewall sharing semantics for CLI configured firewall Pre-ingress
fw-vpls-in VPLS family ingress firewall on VPLS interface Ingress
ifd-src-mac-fil Physical interface level source MAC filter Pre-ingress
ifl-statistics-in Logical level interface statistics at ingress Ingress
ifl-statistics-out Logical level interface statistics at egress Egress
ing-out-iff Ingress application on behalf of egress family filter for log and syslog Ingress
ip-mac-val IP MAC validation Pre-ingress
ip-mac-val-bcast IP MAC validation for broadcast Pre-ingress
ipsec-reverse-fil Reverse filters for IPsec service Ingress

routers.
irb-cos-rw IRB CoS rewrite Egress
lfm-802.3ah-in Link fault management (IEEE 802.3ah) at ingress Ingress

routers.
lfm-802.3ah-out Link fault management (IEEE 802.3ah) at egress Egress
lo0-inet-fil Looback interface inet filter Ingress
lo0-inet6-fil Looback interface inet6 filter Ingress
mac-drop-cnt Statistics for drops by MAC validate and source MAC filters Ingress
mrouter-port-in Multicast router port for snooping Ingress

Table 82: Features Using TCAM Resource (continued)

napt-reverse-fil Reverse filters for network address port translation (NAPT) service Ingress

routers.
no-local-switching Bridge no-local-switching Ingress
ptpoe Point-to-Point-Over-the-Ethernet traps Ingress

routers.
ptpoe-cos-rw CoS rewrite for PTPoE Egress

routers.
rfc2544-layer2-in RFC2544 for Layer 2 service at ingress Pre-ingress
rfc2544-layer2-out RFC2544 for Layer 2 service at egress Egress

routers.
service-filter-in Service filter at ingress Ingress

routers.
Monitoring TCAM Resource Usage

You can use the show and clear commands to monitor and troubleshoot dynamic TCAM
resource usage.
Table 83 on page 1161 summarizes the command-line interface (CLI) commands you can
use to monitor and troubleshoot dynamic TCAM resource usage.
Table 83: Show and Clear Commands to Monitor and Troubleshoot Dynamic TCAM
Task Command
Display the shared and the related applications for a particular application show pfe tcam app
Display the TCAM resource usage for an application and stages (egress, ingress, and show pfe tcam usage
pre-ingress)
Display the TCAM resource usage errors for applications and stages (egress, ingress, show pfe tcam errors
and pre-ingress)
Clears the TCAM resource usage error statistics for applications and stages (egress, clear pfe tcam-errors
ingress, and pre-ingress)

Example: Monitoring and Troubleshooting the TCAM Resource

This section describes a use case where you can monitor and troubleshoot TCAM
resources using show commands. In this use case scenario, you have configured Layer 2
services and the Layer 2 service-related applications are using TCAM resources. The
dynamic approach, as shown in this example, gives you the complete flexibility to manage
TCAM resources on a need basis.
The service requirement is as follows:
• Each bridge domain has one UNI and one NNI interface
• Each UNI interface has:
• One logical interface level policer to police the traffic at 10 Mbps.
• Multifield classifier with four terms to assign forwarding class and loss-priority.
• Each UNI interface configures CFM UP MEP at the level 4.
• Each NNI interface configures CFM DOWN MEP at the level 2
Let us consider a scenario where there are 100 services configured on the router. With
this scale, all the applications are configured successfully and the status shows OK state.
1. Viewing TCAM resource usage for all stages.
To view the TCAM resource usage for all stages (egress, ingress, and pre-ingress), use
the show pfe tcam usage all-tcam-stages detail command.
user@host> show pfe tcam usage all-tcam-stages detail

Slot 0
Tcam Resource Stage: Pre-Ingress

--------------------------------
Free [hw-grps: 3 out of 3]
No dynamic tcam usage
Tcam Resource Stage: Ingress

----------------------------
Group: 11, Mode: SINGLE, Hw grps used: 3, Tcam apps: 2
Used Allocated Available Errors
Tcam-Entries 800 1024 224 0
Counters 800 1024 224 0
Policers 0 1024 1024 0
App tcam usage:

----------------
App-Name Entries Counters Policers Precedence State
Related-App-Name ..
-----------------------------------------------------------------
cfm-filter 500 500 0 3 OK
cfm-bd-filter 300 300 0 2 OK
Group: 8, Mode: DOUBLE, Hw grps used: 2, Tcam apps: 1


Counters 500 1024 524 0

Policers 0 1024 1024 0
App tcam usage:

----------------
Related-App-Name ..
-----------------------------------------------------------------
fw-l2-in 500 500 0 2 OK
fw-semantics 0 X X 1 OK

Counters 200 512 312 0
Policers 100 512 412 0
App tcam usage:

----------------
Related-App-Name ..
-----------------------------------------------------------------
fw-ifl-in 200 200 100 1 OK
Tcam Resource Stage: Egress

---------------------------
2. Configure additional Layer 2 services on the router.
For example, add 20 more services on the router, thereby increasing the total number
of services to 120. After adding more services, you can check the status of the
configuration by verifying either the syslog message using the command show log
messages, or by running the show pfe tcam errors command.
The following is a sample syslog message output showing the TCAM resource shortage
for Ethernet-switching family filters for newer configurations by running the show log
messages CLI command.
[Sat Jul 11 16:10:33.794 LOG: Err] ACX Error

(dfw):acx_dfw_check_phy_slice_availability :Insufficient phy slices to
accomodate grp:13/IN_IFF_BRIDGE mode:1/DOUBLE
[Sat Jul 11 16:10:33.794 LOG: Err] ACX Error
(dfw):acx_dfw_check_resource_availability :Could not write filter:
f-bridge-ge-0/0/0.103-i, insufficient TCAM resources
[Sat Jul 11 16:10:33.794 LOG: Err] ACX Error (dfw):acx_dfw_update_filter_in_hw
:acx_dfw_check_resource_availability failed for filter:f-bridge-ge-0/0/0.103-i
[Sat Jul 11 16:10:33.794 LOG: Err] ACX Error (dfw):acx_dfw_create_hw_instance
:Status:1005 Could not program dfw(f-bridge-ge-0/0/0.103-i)
type(IN_IFF_BRIDGE)! [1005]
[Sat Jul 11 16:10:33.794 LOG: Err] ACX Error (dfw):acx_dfw_bind_shim :[1005]
Could not create dfw(f-bridge-ge-0/0/0.103-i) type(IN_IFF_BRIDGE)
[Sat Jul 11 16:10:33.794 LOG: Err] ACX Error (dfw):acx_dfw_bind :[1000] bind
failed for filter f-bridge-ge-0/0/0.103-i
If you use the show pfe tcam errors all-tcam-stages detail CLI command to verify the
status of the configuration, the output will be as shown below:

user@host> show pfe tcam errors all-tcam-stages detail

Slot 0

--------------------------------

----------------------------
Counters 960 1024 64 0
Policers 0 1024 1024 0
App tcam usage:

----------------
Related-App-Name ..
-----------------------------------------------------------------

Counters 510 1024 514 0
Policers 0 1024 1024 0
App tcam usage:

----------------
Related-App-Name ..
-----------------------------------------------------------------
fw-l2-in 510 510 0 2 FAILED
App error statistics:

----------------------
Related-App-Name ..
-----------------------------------------------------------------
fw-l2-in 18 0 0 2 FAILED

Counters 240 512 272 0
Policers 120 512 392 0
App tcam usage:

----------------
Related-App-Name ..
-----------------------------------------------------------------
fw-ifl-in 240 240 120 1 OK

---------------------------
The output indicates that the fw-l2-in application is running out of TCAM resources
and moves into a FAILED state. Although there are two TCAM slices available at the
ingress stage, the fw-l2-in application is not able to use the available TCAM space
due to its mode (DOUBLE), resulting in resource shortage failure.
3. Fixing the applications that have failed due to the shortage of TCAM resouces.
The fw-l2-in application failed because of adding more number of services on the
routers, which resulted in shortage of TCAM resources. Although other applications
seems to work fine, it is recommended to deactivate or remove the newly added
services so that the fw-l2-in application moves to an OK state. After removing or
deactivating the newly added services, you need to run the show pfe tcam usage and
show pfe tcam error commands to verify that there are no more applications in failed
state.
To view the TCAM resource usage for all stages (egress, ingress, and pre-ingress), use
the show pfe tcam usage all-tcam-stages detail command.
user@host> show pfe tcam usage all-tcam-stages detail

Slot 0

--------------------------------

----------------------------
Counters 800 1024 224 0
Policers 0 1024 1024 0
App tcam usage:

----------------
Related-App-Name ..
-----------------------------------------------------------------

Counters 500 1024 524 0
Policers 0 1024 1024 0
App tcam usage:

----------------
Related-App-Name ..

-----------------------------------------------------------------
fw-l2-in 500 500 0 2 OK

Counters 200 512 312 0
Policers 100 512 412 0
App tcam usage:

----------------
Related-App-Name ..
-----------------------------------------------------------------
fw-ifl-in 200 200 100 1 OK

---------------------------
To view TCAM resource usage errors for all stages (egress, ingress, and pre-ingress),
use the show pfe tcam errors all-tcam-stages command.
user@host> show pfe tcam errors all-tcam-stages detail

Slot 0

--------------------------------
No tcam usage

----------------------------
Errors Resource-Shortage
Tcam-Entries 0 0
Counters 0 0
Policers 0 0

Tcam-Entries 18 0
Counters 0 0
Policers 0 0

Tcam-Entries 0 0
Counters 0 0
Policers 0 0

---------------------------
No tcam usage
You can see that all the applications using the TCAM resources are in OK state and
indicates that the hardware has been successfully configured.

NOTE: As shown in the example, you will need to run the show pfe tcam errors
and show pfe tcam usage commands at each step to ensure that your
configurations are valid and that the applications using TCAM resource are
in OK state.
Service Scaling on ACX5048 and ACX5096 Routers
In ACX5048 and ACX5096 routers, a typical service (such as ELINE, ELAN and IP VPN)
that is deployed might require applications (such as policers, firewall filters, connectivity
fault management IEEE 802.1ag, RFC2544) that uses the dynamic TCAM infrastructure.
NOTE: Service applications that uses TCAM resources is limited by the TCAM
resource availability. Therefore, the scale of the service depends upon the
consumption of the TCAM resource by such applications.
A sample use case for monitoring and troubleshooting service scale in ACX5048 and
ACX5096 routers can be found at the “Dynamic Ternary Content Addressable Memory
Overview” on page 1157 section.
Related
Documentation
Understanding Layer 2 Next Generation Mode on ACX5048 and ACX5096 Routers
The Layer 2 Next Generation mode, also called Enhanced Layer 2 Software (ELS), is
supported on ACX5048 and ACX5096 routers for configuring Layer 2 features. The Layer
2 CLI configurations and show commands for ACX5048 and ACX5096 routers differ
from those for other ACX Series routers (ACX1000, ACX1100, ACX2000, ACX2100,
ACX2200, and ACX4000) and MX Series routers.
For more information about Enhanced Layer 2 Software, see Getting Started with Enhanced
Layer 2 Software.
Table 84 on page 1167 shows the differences in CLI hierarchy for configuring Layer 2 features
in Layer 2 next generation mode.
Table 84: Differences in CLI Hierarchy for Layer 2 Features in Layer 2 Next Generation Mode
ACX1000, ACX1100, ACX2000, ACX2100,
Feature ACX2200, ACX4000, and MX Series Routers ACX5048 and ACX5096 Routers
Bridge Domain [edit bridge-domains bridge-domain-name] [edit vlans vlan-name]
Family bridge [edit interfaces interface-name unit unit-number [edit interfaces interface-name unit
family bridge] unit-number family ethernet-switching]

Table 84: Differences in CLI Hierarchy for Layer 2 Features in Layer 2 Next Generation
Mode (continued)
ACX1000, ACX1100, ACX2000, ACX2100,
Layer 2 options [edit bridge-domains bridge-domain-name [edit vlans vlan-name switch-options]

bridge-options]
Ethernet options [edit interfaces interface-name gigether-options] [edit interfaces interface-name ether-options]
Integrated routing and [edit bridge-domains bridge-domain-name] [edit vlans vlan-name] l3-interface irb.unit;
bridging (IRB) routing-interface irb.unit;
Storm control [edit vlans vlan-name forwarding-options flood [edit storm-control-profiles]

filter filter-name]
[edit interfaces interface-name ether-options]
storm-control name;
recovery-timeout interval;
Internet Group Management [edit bridge-domains bridge-domain-name [edit protocols igmp-snooping vlan
Protocol (IGMP) snooping protocols igmp-snooping] vlan-name]
Family bridge firewall filter [edit firewall family bridge] [edit firewall family ethernet-switching]
Table 85 on page 1168 shows the differences in show commands for Layer 2 features in
Layer 2 next generation mode.
Table 85: Differences in show Commands for Layer 2 Features in Layer 2 Next Generation Mode
ACX1000, ACX1100, ACX2000, ACX2100,
VLAN show bridge-domain show vlans
MAC table show bridge mac-table show ethernet-switching table
MAC table options show bridge mac-table show ethernet-switching table

(MAC address, bridge-domain name, interface,
VLAN ID, and instance)
Switch port listing with VLAN show l2-learning interface show ethernet-switching interfaces
assignments
Kernel state of flush database show route forwarding-table family bridge show route forwarding-table family
ethernet-switching
Related • Storm Control on ACX Series Routers Overview on page 966

Documentation
• IGMP Snooping and Bridge Domains on page 477

• Understanding Ethernet Link Aggregation on ACX Series Routers on page 152
Understanding and Configuring the Unified Forwarding Table
• Using the Unified Forwarding Table to Optimize Address Storage on page 1169
• Configuring the Unified Forwarding Table to Optimize Address Storage Using
Profiles on page 1170
Using the Unified Forwarding Table to Optimize Address Storage

ACX5048 and ACX5096 routers support the use of a unified forwarding table to optimize
address storage. This feature gives you the flexibility to configure your router to match
the needs of your particular network environment. You can control the allocation of
forwarding table memory available to store the following entries:
• MAC addresses
• Layer 3 host entries
• Longest prefix match (LPM) table entries
You can use five predefined profiles (l2-profile-one, l2-profile-two, l2-profile-three,

l3-profile, lpm-profile) to allocate the table memory space differently for each of these
entries. The sizes of the Layer 2 MAC address table, Layer 3 host entry table, and Layer
3 LPM table are decided based on the selected profile. You can configure and select the
profiles that best suits your network environment needs.
Table 86 on page 1169 illustrates the predefined profiles in the unified forwarding table
and the respective table sizes.
Table 86: Unified Forwarding Table Profiles

Profile Layer 2 MAC Address Table Layer 3 Host Table Layer 3 LPM Table
l2-profile-one 288 KB 16 KB 16 KB
l2-profile-two 224 KB 80 KB 16 KB
l2-profile-three (default) 160 KB 144 KB 16 KB
l3-profile 96 KB 208 KB 16 KB
lpm-profile 32 KB 16 KB 128 KB
IPv4 unicast, IPv6 unicast, IPv4 multicast, and IPv6 multicast route addresses share the
Layer 3 host entry table. If the host table stores the maximum number of entries for any
given type, the entire table is full and is unable to accommodate any entries of any other
type. The IPv4 multicast and IPv6 unicast addresses occupy double the space as that
occupied by IPv4 unicast entries, and IPv6 multicast addresses occupy four times the
space of the IPv4 unicast addresses. Table 87 on page 1170 shows the Layer 3 host table
size for each profile.

Table 87: Layer 3 Host Table

Layer 3 Host Table
Profile IPv4 Unicast IPv4 Multicast IPv6 Unicast IPv6 Multicast
l2-profile-one 16 KB 8 KB 8 KB 4 KB
l2-profile-two 80 KB 40 KB 40 KB 20 KB
l2-profile-three (default) 144 KB 72 KB 72 KB 36 KB
l3-profile 208 KB 104 KB 104 KB 52 KB
lpm-profile 16 KB 8 KB 8 KB 4 KB
The Layer 3 LPM table is shared between IPv4 route prefixes and IPv6 route prefixes.
Table 88 on page 1170 illustrates the size of the table for different profiles of the IPv4 and
IPv4 addresses in the Layer 3 LPM table. When unicast reverse-path forwarding (unicast
RPF) is enabled, the table size reduces to half.
Table 88: Layer 3 LPM Table

Layer 3 LPM Table
Profile IPv4 Unicast IPv6 Unicast (Prefix <= /64) IPv6 Unicast (Prefix > /64)
l2-profile-one 16 KB 8 KB 4 KB
l2-profile-two 16 KB 8 KB 4 KB
l2-profile-three (default) 16 KB 8 KB 4 KB
l3-profile 16 KB 8 KB 4 KB
lpm-profile 128 KB 40 KB 8 KB
By default, there is no space allocated for IPv6 prefix address longer than /64 in the LPM
table. Therefore, prefix address longer than /64 are not allowed in the table by default.
The entire table is available for IPv4 addresses and for IPv6 addresses that have prefixes
shorter than /64. You can provide space in the table for addresses with prefixes longer
than /64 by using CLI configuration. The number of entries reserved for these prefixes is
configured in multiples of 16.
Configuring the Unified Forwarding Table to Optimize Address Storage Using Profiles
You can use five predefined profiles (l2-profile-one, l2-profile-two, l2-profile-three,
l3-profile, lpm-profile) to allocate the table memory space. The sizes of the Layer 2 MAC
address table, Layer 3 host entry table, and Layer 3 LPM table are decided based on the
selected profile. You can configure and select the profiles that best suits your network
environment needs.

To configure the profile that you want, enter and commit the following statement:
[edit]
user@host# set chassis forwarding-options profile-name profile-name
NOTE: When you configure and commit a profile, the Packet Forwarding
Engine (PFE) process restarts and all the data interfaces on the router go
down and come back up.
The settings for l2-profile-three are configured by default. That is, if you do not configure
the forwarding–options chassis profile-name statement, the l2-profile-three profile settings
are configured.
Interpreting the Enterprise-Specific Service OAM MIB
Junos OS supports the generation of SNMP traps and alarms for performance monitoring
(PM) functionalities using MIB objects to manage Service Operations, Administration,
and Maintenance (OAM) capabilities that are in conformance with the service OAM
requirements and framework specified by Metro Ethernet Forum (MEF) 17, service OAM
performance monitoring requirements defined by SOAM-PM, and the service OAM
management objects specified in Technical Specification MEF 7.1. Junos OS supports an
enterprise-specific MIB, SOAM PM MIB, that defines the management objects for Ethernet
services operations, administration, and maintenance for performance monitoring. SNMP
support is available for the MIB objects defined in Technical Specification MEF 36.
• Service OAM MIB on page 1171

• Managed Objects for jnxSoamPmMepTable on page 1172
• Managed Objects for jnxSoamLmCfgTable on page 1174
• Managed Objects for jnxSoamLmMeasuredStatsTable on page 1184
• Managed Objects for jnxSoamLmCurrentStatsTable on page 1185
• Managed Objects for jnxSoamLmHistoryStatsTable on page 1188
• Managed Objects for jnxSoamDmCfgTable on page 1191
• Managed Objects for jnxSoamDmMeasuredStatsTable on page 1205
• Managed Objects for jnxSoamDmCurrentStatsTable on page 1207
• Managed Objects for jnxSoamDmHistoryStatsTable on page 1211
• Managed Objects for jnxSoamLmThresholdCfgTable on page 1216
• Managed Objects for jnxSoamDmThresholdCfgTable on page 1219
• Managed Objects for jnxSoamPmNotificationObj Table on page 1226
• Managed Objects for jnxSoamPmNotifications Table on page 1227
Service OAM MIB

The Juniper Networks enterprise-specific service operations, administration, and
maintenance (OAM) MIB (jnxSoamPmMib) whose object ID is {jnxMibs 78}, defines for
the management of Ethernet services operations, administration and maintenance for

performance monitoring capabilities, such as two-way Ethernet frame delay measurement

(ETH-DM), ITU-T Y.1731 standard-compliant Ethernet loss measurement (ETH-LM), and
Ethernet synthetic loss measurement (ETH-SLM). SNMP support is available for the MIB
objects defined in Technical Specification MEF 36.
Table 89: Managed Objects for Service OAM MIB

Object Object ID Description
jnxSoamPmNotifications jnxSoamPmMib 0 Denotes notifications or traps for service OAM performance

monitoring.
jnxSoamPmMibObjects jnxSoamPmMib 1 Defines objects for service OAM performance monitoring.
jnxSoamPmMibConformance jnxSoamPmMib 2 Defines objects for conformance to service OAM

performance monitoring.
jnxSoamPmMep jnxSoamPmMibObjects 1 Contains objects for Ethernet maintenance endpoints

(MEPs) performance monitoring configuration.
jnxSoamPmLmObjects jnxSoamPmMibObjects 2 Contains objects for Ethernet loss measurement (ETH-LM).
jnxSoamPmDmObjects jnxSoamPmMibObjects 3 Contains objects for Ethernet frame delay measurement

(ETH-DM).
jnxSoamPmNotificationCfg jnxSoamPmMibObjects 4 Denotes configuration for notifications or traps for service

OAM.
jnxSoamPmNotificationObj jnxSoamPmMibObjects 5 Denotes objects for notifications for service OAM.
Managed Objects for jnxSoamPmMepTable

The jnxSoamPmMepTable, whose object identifier is {jnxSoamPmMep 1}, contains the
jnxSoamPmMepEntry that retrieves details related to Ethernet performance monitoring
of maintenance endpoints (MEPs). Each jnxSoamPmMepEntry, whose object identifier
is {jnxSoamPmMepTable 1}, contains the objects listed in the following table. The
jnxSoamPmMepTable is an extension of the dot1agCfmMepTable and rows are
automatically added or deleted from this table based upon row creation and deletion
of the dot1agCfmMepTable. This table represents the local MEP PM configuration table.
The primary purpose of this table is provide local parameters for the SOAM PM function
found in [Y.1731] and [MEF SOAM-PM] and instantiated at a MEP.

Table 90: jnxSoamPmMepTable

jnxSoamPmMepOperNextIndex jnxSoamPmMepEntry 1 Contains an unused value for a PM session number on

a MEP that can be used for either LM or DM sessions,
or a zero to indicate that none exist. This value needs
to be read in order to find an available index for
row-creation of a PM session on a MEP and then used
when a row is created. This value is automatically
updated by the SNMP Agent after the row is created.
Referential integrity is necessary (the index needs to

be persistent upon a reboot or restart of a device). The
index is never to be reused for other PM sessions on
the same MEP while this session is active, or until it
wraps to zero. The index value keeps increasing up to
that time. This is to facilitate access control based on
a fixed index for an EMS, since the index is not reused.
This object is an extension of the dot1agCfmMepTable

and the object is automatically added or deleted based
upon row creation and removal of the
dot1agCfmMepTable.
jnxSoamPmMepLmSingleEndedResponder jnxSoamPmMepEntry 2 Specifies whether the Loss Measurement (LMM)

single-ended responder is enabled.
The value of true indicates the single-ended Loss

Measurement Responder is enabled and if an LMM
message is received, an LMR will be sent in reply. The
value of false indicates the single-ended Loss
Measurement Responder is disabled. If an LMM
message is received no response will be sent and the
message will be discarded.
This object needs to be persistent upon reboot or

restart of a device. A MEP can be both a single-ended
Responder and Controller simultaneously.
jnxSoamPmMepSlmSingleEndedResponder jnxSoamPmMepEntry 3 Specifies whether the Synthetic Loss Measurement

(SLM) single-ended Responder is enabled.
The value of true indicates the single-ended SLM

Responder is enabled and if an SLM message is
received, an SLR is sent in reply. The value of false
indicates the single-ended SLM Responder is disabled.
If an SLM message is received, a response is not sent
and the message is discarded.

restart of a device.
A MEP can be both a single-ended Responder and

Controller simultaneously.

Table 90: jnxSoamPmMepTable (continued)

jnxSoamPmMepDmSingleEndedResponder jnxSoamPmMibObjects This object specifies whether the Delay Measurement

4 (DMM) single-ended Responder is enabled.
The value of true indicates the single-ended Delay

Measurement Responder is enabled and if a DMM
message is received a DMR is sent in reply. The value
of false indicates the single-ended Delay Measurement
Responder is disabled. If a DMM message is received,
no response is sent and the message is discarded.

restart of a device. A MEP can be both a single-ended
Responder and Controller simultaneously.
Managed Objects for jnxSoamLmCfgTable

The jnxSoamLmCfgTable, whose object identifier is {jnxSoamPmLmObjects 1}, contains
the jnxSoamLmCfgEntry that signifies the Ethernet loss measurement (ETH-LM)
configuration settings. Each jnxSoamLmCfgEntry, whose object identifier is
{jnxSoamLmCfgTable 1}, contains the objects listed in the following table.
The jnxSoamLmCfgTable includes configuration objects and operations for the frame
loss measurement function defined in [Y.1731] and [MEF SOAM-PM]. Each row in the
table represents a Loss Measurement session for the defined MEP. This table uses four
indices. The first three indices are the indices of the Maintenance Domain, MaNet, and
MEP tables. The fourth index is the specific LM session on the selected MEP. A Loss
Measurement session is created on an existing MEP by first accessing the
jnxSoamPmMepOperNextIndex object and using this value as the jnxSoamLmCfgIndex
in the row creation.
Some writable objects in this table are only applicable in certain cases (as described
under each object), and attempts to write values for them in other cases will be ignored.
The writable objects in this table need to be persistent upon reboot or restart of a device..
Table 91: jnxSoamLmCfgTable

jnxSoamLmCfgIndex JnxSoamLmCfgEntry Denotes an index to the Loss Measurement Configuration

1 table which indicates the specific measurement session
for the MEP.
jnxSoamPmMepOperNextIndex needs to be inspected to

find an available index for row-creation.
Referential integrity is necessary (that is, the index needs

to be persistent upon a reboot or restart of a device. The
index is never reused for other PM sessions on the same
MEP while this session is active. The index value keeps
increasing until it wraps to 0. This is to facilitate access
control based on a fixed index for an EMS, since the index
is not reused.

Table 91: jnxSoamLmCfgTable (continued)

jnxSoamLmCfgType JnxSoamLmCfgEntry Specifies the type of Loss Measurement to be performed.

2
• lmLmm(1)—LMM SOAM PDU generated and received
LMR responses tracked
• lmSlm(2)—SLM SOAM PDU generated and received
SLR responses tracked
• lmCcm(3)—CCM SOAM PDU generated and received
CCM PDUs tracked
The lmSlm value is required. The lmLmm and lmCcm

values are optional.
The lmCcm loss measurement values are only valid for a

point-to-point MEG. Multipoint MEGs may give unreliable
loss measurements. This object can only be written at row
creation time and cannot be modified once it has been
created.
jnxSoamLmCfgVersion JnxSoamLmCfgEntry Indicates the version of the PDUs used to perform Loss
3 Measurement.
The value is placed in the Version field of the PDU and

indicates that the PDU format used is the format defined
in Y.1731 with that version.
The exact PDUs to use are specified by this object in

combination with jnxSoamLmCfgType.
This object can only be written at row creation time and

cannot be modified once it has been created.


jnxSoamLmCfgEnabled JnxSoamLmCfgEntry Specifies whether the Loss Measurement session is

4 enabled.
The value 'true' indicates the Loss Measurement session

is enabled and SOAM PDUs are sent and/or
measurements are collected when the session is running
according to the scheduling objects (start time, stop time,
etc.).
The value 'false' indicates the Loss Measurement session

is disabled and SOAM PDUs are not sent and/or
measurements collected.
For a Loss Measurement session to be removed the row

is deleted in order to release internal resources.
This object can be written/modified after row creation

time.
If the LM session is enabled it resumes after

shutdown/restart. If the LM session is disabled the current
Measurement Interval is stopped, if it in process at the
time, and all the in process calculations for the partially
completed Measurement Interval are finalized.
This object does not affect whether the single-ended

Responder is enabled or not, which is enabled or disabled
by the jnxSoamPmMepLmSingleEndedResponder and
jnxSoamPmMepSlmSingleEndedResponder objects.


jnxSoamLmCfgMeasurementEnable JnxSoamLmCfgEntry
5


Contains a vector of bits that indicates the type of SOAM

LM counters found in the jnxSoamLmMeasuredStatsTable,
jnxSoamLmCurrentStatsTable,
jnxSoamLmHistoryStatsTable that are enabled.
A bit set to '1' enables the specific SOAM LM counter. A

bit set to '0' disables the SOAM LM counter.
If a particular SOAM LM counter is not supported the BIT

value is set to '0'.
Not all SOAM LM counters are supported for all SOAM LM

types.

cannot be modified after it has been created.
• bForwardTransmitedFrames (0)—Enables or disables

the
jnxSoamLmCurrentStatsForwardTransmittedFrames
and
jnxSoamLmHistoryStatsForwardTransmittedFrames
counters.
• bForwardReceivedFrames(1)—Enables or disables the
jnxSoamLmCurrentStatsForwardReceivedFrames and
jnxSoamLmHistoryStatsForwardReceivedFrames
counters.
• bForwardMinFlr(2)—Enables or disables the
jnxSoamLmCurrentStatsForwardMinFlr and
jnxSoamLmHistoryStatsForwardMinFlr counters.
• bForwardMaxFlr(3)—Enables or disables the
jnxSoamLmCurrentStatsForwardMaxFlr and
jnxSoamLmHistoryStatsForwardMaxFlr counters.
• bForwardAvgFlr(4)—Enables or disables the
jnxSoamLmCurrentStatsForwardAvgFlr and
jnxSoamLmHistoryStatsForwardAvgFlr counters.
• bBackwardTransmitedFrames(5)—Enables or disables
the
jnxSoamLmCurrentStatsBackwardTransmittedFrames
and
jnxSoamLmHistoryStatsBackwardTransmittedFrames
counters.
• bBackwardReceivedFrames(6)—Enables or disables
the jnxSoamLmCurrentStatsBackwardReceivedFrames
and jnxSoamLmHistoryStatsBackwardReceivedFrames
counters.
• bBackwardMinFlr(7)—Enables or disables the
jnxSoamLmCurrentStatsBackwardMinFlr and
jnxSoamLmHistoryStatsBackwardMinFlr counters.
• bBackwardMaxFlr(8)—Enables or disables the
jnxSoamLmCurrentStatsBackwardMaxFlr and
jnxSoamLmHistoryStatsBackwardMaxFlr counters.
• bBackwardAvgFlr(9)—Enables or disables the
jnxSoamLmCurrentStatsBackwardAvgFlr and


jnxSoamLmHistoryStatsBackwardAvgFlr counters.
• bSoamPdusSent (10)—Enables or disables the
jnxSoamLmCurrentStatsSoamPdusSent and
jnxSoamLmHistoryStatsSoamPdusSent counters.
• bSoamPdusReceivedbReceivedMeasurements
(11)—Enables or disables the
jnxSoamLmCurrentStatsSoamPdusReceived and
jnxSoamLmHistoryStatsSoamPdusReceived counters.
• bMeasuredStatsForwardMeasuredFlr(26)—Enables or
disables the jnxSoamLmMeasuredStatsForwardFlr
counter.
• bMeasuredStatsBackwardMeasuredFlr(27)— Enables
or disables the jnxSoamLmMeasuredStatsBackwardFlr
counter.
jnxSoamLmCfgMessagePeriod JnxSoamLmCfgEntry Specifies the interval between Loss Measurement OAM

6 message transmission. For Loss Measurement monitoring
applications the default value is 1 sec.
This object is not applicable if jnxSoamLmCfgType is set

to lmCcm and is ignored for that Loss Measurement Type.
jnxSoamLmCfgPriority JnxSoamLmCfgEntry Specifies the Loss Measurement OAM message priority

7 and the priority of the service OAM traffic to be monitored.
Only frames of the same Class of Service are counted.
The default value is to be the value which yields the lowest

frame loss.
This object is not applicable if jnxSoamLmCfgType is set

to lmCcm.

jnxSoamLmCfgFrameSize JnxSoamLmCfgEntry Specifies the Loss Measurement frame size between 64

8 bytes and the maximum transmission unit of the EVC. The
range of frame sizes from 64 through 2000 octets need
to be supported, and the range of frame sizes from 2001
through 9600 octets is suggested be supported.
The adjustment to the frame size of the standard frame

size is accomplished by the addition of a Data or Test TLV.
A Data or Test TLV is only added to the frame if the frame
size is greater than 64 bytes.
This object is only valid for the entity transmitting the Loss
Measurement frames, type 'lmSlm', and is ignored by the
entity receiving frames. It is not applicable for the 'lmCcm'
or 'lmLmm' types.



jnxSoamLmCfgDataPattern JnxSoamLmCfgEntry Specifies the LM data pattern included in a Data TLV when
9 the size of the LM frame is determined by the
jnxSoamLmFrameSize object and
jnxoamLmTestTlvIncluded is 'false'.
If the frame size object does not define the LM frame size
or jnxSoamLmTestTlvIncluded is 'true' the value of this
object is ignored.

jnxSoamLmCfgTestTlvIncluded JnxSoamLmCfgEntry Indicates whether a Test TLV or Data TLV is included when
10 the size of the LM frame is determined by the
jnxSoamLmFrameSize object.
A value of 'true' indicates that the Test TLV is to be

included. A value of 'false' indicates that the Data TLV is
to be included.
the value of this object is ignored.

jnxSoamLmCfgTestTlvPattern JnxSoamLmCfgEntry Specifies the type of test pattern to be sent in the LM

11 frame Test TLV when the size of LM PDU is determined
by the jnxSoamLmFrameSize object and
jnxSoamLmTestTlvIncluded is 'true'.
or jnxSoamLmTestTlvIncluded is 'false' the value of this
object is ignored.

jnxSoamLmCfgNumIntervalsStored JnxSoamLmCfgEntry Specifies the number of completed Measurement Intervals

12 to store in the history statistic table
(jnxSoamLmHistoryStatsTable) At least 32 completed
Measurement Intervals need to be stored. 96
Measurement Intervals are recommended to be stored.



jnxSoamLmCfgDestMepId JnxSoamLmCfgEntry Specifies the Maintenance Association End Point Identifier

13 of another MEP in the same Maintenance Association to
which the SOAM LM frame is to be sent.
This address will be used if the value of the column

jnxSoamLmDestIsMepId is 'true'. A value of zero means
that the destination MEP ID has not been configured.
Measurement frames, types 'lmLmm' and 'lmSlm'. It is
not applicable for the 'lmCcm' type.

jnxSoamLmCfgDestIsMepId JnxSoamLmCfgEntry Specifies whether the MEP ID or the MAC address of the
14 destination MEP is used for SOAM LM frame transmission.
A value of 'true' indicates that MEPID of the target MEP

is used for SOAM LM frame transmission. A value of 'false'
indicates that the MAC address of the target MEP is used
for SOAM LM frame transmission.
Measurement frames, types 'lmLmm' and 'lmSlm'. It is
not applicable for the 'lmCcm' type.

jnxSoamLmCfgStartTimeType JnxSoamLmCfgEntry Specifies the type of start time of the SOAM LM session.
15 The start time can be disabled (none), immediate, relative,
or fixed.
The value of 'none' is illegal and a write error will be

returned if this value is used.
The value of 'immediate' starts the SOAM LM session

when the jnxSoamLmCfgEnabled is true.
The value of 'fixed' starts the SOAM LM session when the

jnxSoamLmFixedStartDateAndTime is less than or equal
to the current system date and time and
jnxSoamLmCfgEnabled is true. This value is used to
implement an On-Demand fixed time PM session.
The value of 'relative' starts the SOAM LM session when

the current system date and time minus the
jnxSoamLmRelativeStartTime is greater than or equal to
the system date and time when the
jnxSoamLmStartTimeType object was written and
jnxSoamLmCfgEnabled is true. This value is used to
implement an On-Demand relative time PM session.



jnxSoamLmCfgFixedStartDateAndTime JnxSoamLmCfgEntry Specifies the fixed start date/time for the SOAM Loss
16 Measurement session. This object is used only used if
jnxSoamLmStartTimeType is 'fixed' and is ignored
otherwise.
The default value is year 0000, month 01, day 01, time
00:00:00.00.

jnxSoamLmCfgRelativeStartTime JnxSoamLmCfgEntry Specifies the relative start time, from the current system
17 time, for the SOAM LM session. This object is used only if
jnxSoamLmStartTimeType is 'relative' and is ignored
otherwise.

jnxSoamLmCfgRepetitionTime JnxSoamLmCfgEntry Specifies a configurable repetition time between

18 Measurement Intervals in a Loss Measurement session,
in seconds.
If the value is 0 (none), there is no time gap between the

end of one Measurement Interval and the start of a new
Measurement Interval. This is the normal usage case.
If the value is greater than 0 but less than or equal to the

measurement interval, an error is returned.
If the value is greater than one Measurement Interval there

is time gap between the end of one Measurement Interval
and the start of the next Measurement Interval. The
repetition time specifies the time between the start of
consecutive Measurement Intervals; hence the gap
between the end of one Measurement Interval and the
start of the next is equal to the difference between the
repetition time and the measurement interval. During this
gap, no SOAM PDUs are sent for this session and no
measurements are made.



jnxSoamLmCfgAlignMeasurementIntervals JnxSoamLmCfgEntry Specifies whether the Measurement Intervals for the Loss
19 Measurement session are aligned with a zero offset to real
time.
The value 'true' indicates that each Measurement Interval

starts at a time which is aligned to NE time source hour,
if the repetition time (or the Measurement Interval, if the
repetition time is 0) is a factor of an hour, that is,
60min/15min = 4. For instance, a Measurement
Interval/repetition time of 15 minutes would stop/start
the Measurement Interval at 0, 15, 30, and 45 minutes of
an hour. A Measurement Interval/Repetition Time of 7
minutes would not align to the hour since 7 minutes is NOT
a factor of an hour, that is, 60min/7min = 8.6. In this case
the behavior is the same as if the object is set to 'false'.
The value 'false' indicates that the first Measurement

Interval starts at an arbitrary time and each subsequent
Measurement Interval starts at a time which is determined
by jnxSoamLmCfgRepetitionTime.

jnxSoamLmCfgAlignMeasurementOffset JnxSoamLmCfgEntry Specifies the offset in minutes from the time of day value
20 if jnxSoamLmCfgAlignMeasurementIntervals is 'true' and
the repetition time is a factor of 60 minutes. If not, the
value of this object is ignored.
If the Measurement Interval is 15 minutes and

jnxSoamLmCfgAlignMeasurementIntervals is true and if
this object was set to 5 minutes, the Measurement
Intervals would start at 5, 20, 35, 50 minutes past each
hour.

cannot be modified once it has been created. "
jnxSoamLmCfgSessionType JnxSoamLmCfgEntry Indicates whether the current session is defined to be

21 'Proactive' or 'On-Demand'. A value of 'proactive' indicates
the current session is 'Proactive'. A value of 'onDemand'
indicates the current session is 'On-Demand'. This object
can only be written at row creation time and cannot be
modified once it has been created.
jnxSoamLmCfgSessionStatus JnxSoamLmCfgEntry indicates the current status of the LM session. A value of

22 'active' indicates the current LM session is active, i.e. the
current time lies between the start time and the stop time,
and jnxSoamLmCfgEnabled is true. A value of 'notActive'
indicates the current LM session is not active, i.e. it has not
started yet, has stopped upon reaching the stop time, or
is disabled.


jnxSoamLmCfgHistoryClear JnxSoamLmCfgEntry Clears the Loss Measurement history Table

23 (jnxSoamLmHistoryStatsTable) - all rows are deleted.
When read the value always returns 'false'. Writing this
value does not change the current stat table, nor any of
the items in the configuration table. Writing this value
during row creation has no effect.
jnxSoamLmCfgRowStatus JnxSoamLmCfgEntry Specifies the status of the row. The writable columns in
24 a row cannot be changed if the row is active, except for
jnxSoamLmCfgHistoryClear and jnxSoamLmCfgEnabled
objects. All columns must have a valid value before a row
can be activated.
Managed Objects for jnxSoamLmMeasuredStatsTable

The jnxSoamLmMeasuredStatsTable, whose object identifier is {jnxSoamPmLmObjects
2}, contains the jnxSoamLmMeasuredStatsEntry that signifies the Ethernet loss
measurement (ETH-LM) statistical details. Each jnxSoamLmMeasuredStatsEntry, whose
object identifier is {jnxSoamLmMeasuredStatsTable 1}, contains the objects listed in the
following table.
The jnxSoamLmMeasuredStatsTable contains the last measured results for a SOAM Loss
Measurement session. Each row in the table represents a Loss Measurement session for
the defined MEP. This table uses four indices. The first three indices are the indices of
the Maintenance Domain, MaNet, and MEP tables. The fourth index is the specific LM
session on the selected MEP. Instances of this managed object are created automatically
by the SNMP Agent when the Loss Measurement session is running. Each object in this
table applies only if the corresponding bit is set in jnxSoamLmCfgMeasurementEnable.
The objects in this table do not need to be persistent upon reboot or restart of a device.
Table 92: jnxSoamLmMeasuredStatsTable

jnxSoamLmMeasuredStatsForwardFlr jnxSoamLmMeasuredStatsEntry Contains the last frame loss ratio in the forward
1 direction calculated by this MEP. The FLR value
is a ratio that is expressed as a percent with a
value of 0 (ratio 0.00) through 100000 (ratio
1.00). Units are in milli-percent, where 1 indicates
0.001 percent.
jnxSoamLmMeasuredStatsBackwardFlr jnxSoamLmMeasuredStatsEntry Contains the last frame loss ratio in the backward
2 direction calculated by this MEP. The FLR value
is a ratio that is expressed as a percent with a
value of 0 (ratio 0.00) through 100000 (ratio
1.00). Units are in milli-percent, where 1 indicates
0.001 percent.

Managed Objects for jnxSoamLmCurrentStatsTable

The jnxSoamLmCurrentStatsTable, whose object identifier is {jnxSoamPmLmObjects 3},
contains the jnxSoamLmCurrentStatsEntry that signifies the Ethernet loss measurement
(ETH-LM) historical statistical details. Each jnxSoamLmCurrentStatsEntry, whose object
identifier is {jnxSoamLmCurrentStatsTable 1}, contains the objects listed in the following
table.
The jnxSoamLmCurrentStatsTable contains the results for the current Measurement

Interval in a SOAM Loss Measurement session gathered during the interval indicated by
iterator counts. A row in this table is created automatically by the SNMP Agent when the
Loss Measurement session is configured. Each row in the table represents the current
statistics for a Loss Measurement session for the defined MEP. This table uses four
MEP tables. The fourth index is the specific LM session on the selected MEP. There may
be more than one LM session per MEP. The main use case for this is to allow multiple
CoS instances to be operating simultaneously for a MEP. The objects in this table apply
regardless of the value of jnxSoamLmCfgType unless otherwise specified in the object
description. Except for jnxSoamLmCurrentStatsIndex, jnxSoamLmCurrentStatsStartTime,
jnxSoamLmCurrentStatsElapsedTime and jnxSoamLmCurrentStatsSuspect, each object
in this table applies only if the corresponding bit is set in
jnxSoamLmCfgMeasurementEnable. The objects in this table do not need to be persistent
upon reboot or restart of a device.
Table 93: jnxSoamLmCurrentStatsTable

jnxSoamLmCurrentStatsIndex jnxSoamLmCurrentStatsEntry 1 Specifies the index for the Measurement

Interval within this PM session. This value
will become the value for
jnxSoamLmHistoryStatsIndex once the
Measurement Interval is completed.
Measurement Interval indexes are

assigned sequentially by the SNMP
Agent. The first Measurement Interval
that occurs after the session is started is
assigned index 1.
jnxSoamLmCurrentStatsStartTime jnxSoamLmCurrentStatsEntry 2 Specifies the time at which the

Measurement Interval started.
jnxSoamLmCurrentStatsElapsedTime jnxSoamLmCurrentStatsEntry 3 Specifies the length of time for which the

Measurement Interval has been running,
in 0.01 seconds.

Table 93: jnxSoamLmCurrentStatsTable (continued)

jnxSoamLmCurrentStatsSuspect jnxSoamLmCurrentStatsEntry 4 Indicates whether the Measurement

Interval has been marked as suspect. The
object is set to false at the start of a
measurement interval. It is set to true
when there is a discontinuity in the
performance measurements during the
Measurement Interval. Conditions for a
discontinuity include, but are not limited
to the following:
1—The local time-of-day clock is adjusted

by at least 10 seconds
2—The conducting of a performance

measurement is halted before the current
Measurement Interval is completed
3—A local test, failure, or reconfiguration

that disrupts service
jnxSoamLmCurrentStatsForwardTransmittedFrames jnxSoamLmCurrentStatsEntry 5 Contains the number of frames

transmitted in the forward direction by
this MEP. For a PM Session of types
lmLmm and lmCcm, this includes
Ethernet Service Frames and SOAM PDUs
that are in a higher MEG level only. For a
PM Session of type lmSlm, this includes
the count of OAM ETH-SLM frames only.
jnxSoamLmCurrentStatsForwardReceivedFrames jnxSoamLmCurrentStatsEntry 6 Contains the number of frames received

in the forward direction by this MEP. For
a PM Session of types lmLmm and
lmCcm this includes Ethernet Service
Frames and SOAM PDUs that are in a
higher MEG level only. For a PM Session
of type lmSlm this includes the count of
OAM ETH-SLM frames only.
jnxSoamLmCurrentStatsForwardMinFlr jnxSoamLmCurrentStatsEntry 7 Contains the minimum one-way frame

loss ratio in the forward direction
calculated by this MEP for this
Measurement Interval. The FLR value is
a ratio that is expressed as a percent with
a value of 0 (ratio 0.00) through 100000
(ratio 1.00). Units are in milli-percent,
where 1 indicates 0.001 percent.
jnxSoamLmCurrentStatsForwardMaxFlr jnxSoamLmCurrentStatsEntry 8 Contains the maximum one-way frame



jnxSoamLmCurrentStatsForwardAvgFlr jnxSoamLmCurrentStatsEntry 9 Contains the average one-way frame loss

ratio in the forward direction calculated
by this MEP for this Measurement
Interval. The FLR value is a ratio that is
expressed as a percent with a value of 0
(ratio 0.00) through 100000 (ratio 1.00).
Units are in milli-percent, where 1
indicates 0.001 percent.
jnxSoamLmCurrentStatsBackwardTransmittedFrames jnxSoamLmCurrentStatsEntry 10 Contains the number of frames

transmitted in the backward direction by
this MEP. For a PM Session of type
lmLmm and lmCcm this includes
PM Session of types lmSlm this includes
the count of SOAM ETH-SLM frames
only.
jnxSoamLmCurrentStatsBackwardReceivedFrames jnxSoamLmCurrentStatsEntry 11 Contains the number of frames received

in the backward direction by this MEP.
For a PM Session of type lmLmm and
of types lmSlm this includes the count of
SOAM ETH-SLM frames only.
jnxSoamLmCurrentStatsBackwardMinFlr jnxSoamLmCurrentStatsEntry 12 Contains the minimum one-way frame

loss ratio in the backward direction
jnxSoamLmCurrentStatsBackwardMaxFlr jnxSoamLmCurrentStatsEntry 13 Contains the maximum one-way frame

jnxSoamLmCurrentStatsBackwardAvgFlr jnxSoamLmCurrentStatsEntry 14 Contains the average one-way frame loss

ratio in the backward direction calculated


jnxSoamLmCurrentStatsSoamPdusSent jnxSoamLmCurrentStatsEntry 15 Contains the count of the number of

SOAM PDUs sent during this
Measurement Interval. This object applies
when jnxSoamLmCfgType is lmLmm,
lmSlm, or lmCcm. It indicates the number
of LMM, CCM, or SLM SOAM frames
transmitted.
jnxSoamLmCurrentStatsSoamPdusReceived jnxSoamLmCurrentStatsEntry 16 Contains the count of the number of

SOAM PDUs received in this
lmSlm, or lmCcm. This object indicates
the number of LMR, CCM, or SLR SOAM
frames received.
Managed Objects for jnxSoamLmHistoryStatsTable

The jnxSoamLmHistoryStatsTable, whose object identifier is {jnxSoamPmLmObjects 4},
contains the jnxSoamLmHistoryStatsEntry that signifies the Ethernet loss measurement
(ETH-LM) historical statistical details. Each jnxSoamLmHistoryStatsEntry, whose object
identifier is {jnxSoamLmHistoryStatsTable 1}, contains the objects listed in the following
table.
The jnxSoamLmHistoryStatsTable contains the results for history Measurement Intervals

in a SOAM Loss Measurement session. Rows of this table object are created automatically
by the SNMP Agent when the Loss Measurement session is running and a Measurement
Interval is completed. Each row in the table represents the history statistics for a Loss
Measurement session Measurement Interval for the defined MEP. This table uses five
MEP tables. The fourth index is the specific LM session on the selected MEP. The fifth
index index the specific Measurement Interval.
At least 32 completed Measurement Intervals are to be supported. 96 completed

Measurement Intervals are recommended to be supported. If there are at least 32 rows
in the table and a new Measurement Interval completes and a new row is to be added
to the table, the oldest completed Measurement Interval may be deleted (row deletion).
If the measurement interval is other than 15 minutes then a minimum of 8 hours of
completed Measurement Intervals are to be supported and 24 hours are recommended
to be supported.
Except for jnxSoamLmHistoryStatsIndex, jnxSoamLmHistoryStatsEndTime,

jnxSoamLmHistoryStatsElapsedTime and jnxSoamLmHistoryStatsSuspect, each object
jnxSoamLmCfgMeasurementEnable. The rows and objects in this table are to be persistent

Table 94: jnxSoamLmHistoryStatsTable

jnxSoamLmHistoryStatsIndex jnxSoamLmHistoryStatsEntry 1 Specifies the index for the Measurement

Interval within this PM session.

assigned index 1. Measurement Intervals
for FLR (stored in this table) are based
on iterator count and are indexed
independently of Measurement Intervals
for availability
Referential integrity is necessary, i.e., the

index needs to be persistent upon a
reboot or restart of a device. The index is
never reused while this session is active
until it wraps to zero. The index value
keeps increasing up to that time.
jnxSoamLmHistoryStatsEndTime jnxSoamLmHistoryStatsEntry 2 Specifies the time at which the

Measurement Interval ended.
jnxSoamLmHistoryStatsElapsedTime jnxSoamLmHistoryStatsEntry 3 Specifies the length of time that the

Measurement Interval ran for, in 0.01
seconds.
jnxSoamLmHistoryStatsSuspect jnxSoamLmHistoryStatsEntry 4 Indicates whether the Measurement

object is set to true when there is a
discontinuity in the performance
measurements during the Measurement
Interval. Conditions for a discontinuity
include, but are not limited to the
following:



jnxSoamLmHistoryStatsForwardTransmittedFrames jnxSoamLmHistoryStatsEntry 5 Contains the number of frames

transmitted in the forward direction by
this MEP. For a PM Session of types
PM Session of type lmSlm this includes
the count of OAM ETH-SLM frames only.

Table 94: jnxSoamLmHistoryStatsTable (continued)

jnxSoamLmHistoryStatsForwardReceivedFrames jnxSoamLmHistoryStatsEntry 6 Contains the number of frames received

in the forward direction by this MEP. For
a PM Session of types lmLmm and
of type lmSlm this includes the count of
OAM ETH-SLM frames only.
jnxSoamLmHistoryStatsForwardMinFlr jnxSoamLmHistoryStatsEntry 7 Contains the minimum one-way frame

jnxSoamLmHistoryStatsForwardMaxFlr jnxSoamLmHistoryStatsEntry 8 Contains the maximum one-way frame

jnxSoamLmHistoryStatsForwardAvgFlr jnxSoamLmHistoryStatsEntry 9 Contains the average one-way frame loss

ratio in the forward direction calculated
jnxSoamLmHistoryStatsBackwardTransmittedFrames jnxSoamLmHistoryStatsEntry 10 Contains the number of frames

transmitted in the backward direction by
this MEP. For a PM Session of type
PM Session of types lmSlm this includes
the count of SOAM ETH-SLM frames
only.
jnxSoamLmHistoryStatsBackwardReceivedFrames jnxSoamLmHistoryStatsEntry 11 Contains the number of frames received

in the backward direction by this MEP.
For a PM Session of type lmLmm and
of types lmSlm this includes the count of
SOAM ETH-SLM frames only.

Table 94: jnxSoamLmHistoryStatsTable (continued)

jnxSoamLmHistoryStatsBackwardMinFlr jnxSoamLmHistoryStatsEntry 12 Contains the minimum one-way frame

jnxSoamLmHistoryStatsBackwardMaxFlr jnxSoamLmHistoryStatsEntry 13 Contains the maximum one-way frame

jnxSoamLmHistoryStatsBackwardAvgFlr jnxSoamLmHistoryStatsEntry 14 Contains the average one-way frame loss

ratio in the backward direction calculated
jnxSoamLmHistoryStatsSoamPdusSent jnxSoamLmHistoryStatsEntry 15 Contains the count of the number of

lmSlm, or lmCcm. It indicates the number
of LMM, CCM, or SLM SOAM frames
transmitted.
jnxSoamLmHistoryStatsSoamPdusReceived jnxSoamLmHistoryStatsEntry 16 Contains the count of the number of

lmSlm, or lmCcm. This object indicates
the number of LMR, CCM, or SLR SOAM
frames received.
Managed Objects for jnxSoamDmCfgTable

The jnxSoamDmCfgTable, whose object identifier is {jnxSoamPmLmObjects 1}, contains
the jnxSoamDmCfgEntry that signifies the Ethernet loss measurement (ETH-DM)
configuration settings. Each jnxSoamDmCfgEntry, whose object identifier is
{jnxSoamDmCfgTable 1}, contains the objects listed in the following table.
The jnxSoamDmCfgTable includes configuration objects and operations for the Delay
Measurement function. Each row in the table represents a Delay Measurement session

for the defined MEP. This table uses four indices. The first three indices are the indices
of the Maintenance Domain, MaNet, and MEP tables. The fourth index is the specific DM
session on the selected MEP. A Delay Measurement session is created on an existing
MEP by first accessing the jnxSoamDmOperNextIndex object and using this value as the
jnxSoamDmCfgIndex in the row creation. Some writable objects in this table are only
applicable in certain cases(as described under each object), and attempts to write values
for them in other cases will be ignored. The writable objects in this table need to be
persistent upon reboot or restart of a device.
Table 95: jnxSoamDmCfgTable

jnxSoamDmCfgIndex jnxSoamDmCfgEntry 1 Denotes an index to the Delay Measurement

Configuration table which indicates the
specific measurement session for the MEP.
jnxSoamPmMepOperNextIndex needs to be
inspected to find an available index for
row-creation.
Referential integrity is necessary (that is, the

index needs to be persistent upon a reboot
or restart of a device. The index is never
reused for other PM sessions on the same
MEP while this session is active. The index
value keeps increasing until it wraps to 0.
This is to facilitate access control based on
a fixed index for an EMS, since the index is
not reused.
jnxSoamDmCfgType jnxSoamDmCfgEntry 2 Specifies the type of Delay Measurement to

be performed.
• dmDmm(1)—DMM SOAM PDU generated,

DMR responses received(one-way or
two-way measurements)
• dm1DmTx(2)—1DM SOAM PDU generated
(one-way measurements are made by
the receiver)
• dm1DmRx(3)—1DM SOAM PDU received
and tracked (one-way measurements)
The exact PDUs to use are specified by this

object in combination with
jnxSoamDmCfgVersion. The value dmDMM
is required. The values dm1DmTx and
dm1DmRx are optional.

Table 95: jnxSoamDmCfgTable (continued)

jnxSoamDmCfgVersion jnxSoamDmCfgEntry 3 Indicates the version of the PDUs used to

perform Delay Measurement.
Version 0 indicates the PDU formats defined

in Y.1731-2008.
Version 1 indicates the PDU formats defined

in Y.1731-2011.
The exact PDUs to use are specified by this

object in combination with
jnxSoamDmCfgType.
This object can only be written at row

creation time and cannot be modified once
it has been created.
jnxSoamDmCfgEnabled jnxSoamDmCfgEntry 4 Specifies whether the Delay Measurement

session is enabled.
The value 'true' indicates the Delay

Measurement session is enabled and SOAM
PDUs are sent and/or measurements are
collected when the session is running
according to the scheduling objects (start
time, stop time, etc.).
The value 'false' indicates the Delay

Measurement session is disabled and SOAM
PDUs are not sent and/or measurements
collected.
For a Delay Measurement session to be

removed the row is deleted in order to
release internal resources.
This object can written/modified after row

creation time.
If the DM session is enabled it resumes after

shutdown/restart. If the DM session is
disabled the current Measurement Interval
is stopped, if it in process at the time, and
all the in process calculations for the
partially completed Measurement Interval
are finalized.
This object does not affect whether the

single-ended Responder is enabled or not,
which is enabled or disabled by the
jnxSoamPmMepDmSingleEndedResponder
object.


jnxSoamDmCfgMeasurementEnable jnxSoamDmCfgEntry 5


Contains a vector of bits that indicates the

type of SOAM DM counters found in the
jnxSoamDmMeasuredStatsTable,
jnxSoamDmCurrentStatsTable,
jnxSoamDmHistoryStatsTable that are
enabled.
A bit set to '1' enables the specific SOAM DM

counter. A bit set to '0' disables the SOAM
DM counter.
If a particular SOAM DM counter is not

supported the BIT value is set to '0'.
Not all SOAM DM counters are supported

for all SOAM DM types.

creation time and cannot be modified after
bSoamPdusSent(0)—Enables or disables
the jnxSoamDmCurrentStatsSoamPdusSent
and
jnxSoamDmHistoryStatsSoamPdusSent
counters.
bSoamPdusReceived(1)—Enables or
disables the
jnxSoamDmCurrentStatsSoamPdusReceived
and
jnxSoamDmHistoryStatsSoamPdusReceived
counters.
bFrameDelayTwoWayBins(2)—Enables or
disables the
jnxSoamDmCurrentStatsBinsEntry counter
and the jnxSoamDmHistoryStatsBinsEntry
counter when the
jnxSoamDmCfgMeasBinType is
'twoWayFrameDelay'.
bFrameDelayTwoWayMin(3)—Enables or
disables the
jnxSoamDmCurrentStatsFrameDelayTwoWayMin
and
jnxSoamDmHistoryStatsFrameDelayTwoWayMin
counters.
bFrameDelayTwoWayMax(4)—Enables or
disables the
jnxSoamDmCurrentStatsFrameDelayTwoWayMax
and
jnxSoamDmHistoryStatsFrameDelayTwoWayMax
counters.
bFrameDelayTwoWayAvg(5)—Enables or
disables the


jnxSoamDmCurrentStatsFrameDelayTwoWayAvg
and
jnxSoamDmHistoryStatsFrameDelayTwoWayAvg
counters.
bFrameDelayForwardBins(6)—Enables or
disables the
counter when the
'forwardFrameDelay'.
bFrameDelayForwardMin(7)—Enables or
disables the
jnxSoamDmCurrentStatsFrameDelayForwardMin
and
jnxSoamDmHistoryStatsFrameDelayForwardMin
counters.
bFrameDelayForwardMax(8)—Enables or
disables the
jnxSoamDmCurrentStatsFrameDelayForwardMax
and
jnxSoamDmHistoryStatsFrameDelayForwardMax
counters.
bFrameDelayForwardAvg(9)—Enables or
disables the
jnxSoamDmCurrentStatsFrameDelayForwardAvg
and
jnxSoamDmHistoryStatsFrameDelayForwardAvg
counters.
bFrameDelayBackwardBins(10)—Enables
or disables the
counter when the
'backwardFrameDelay'.
bFrameDelayBackwardMin(11)—Enables or
disables the
jnxSoamDmCurrentStatsFrameDelayBackwardMin
and
jnxSoamDmHistoryStatsFrameDelayBackwardMin
counters.
bFrameDelayBackwardMax(12)—Enables
or disables the
jnxSoamDmCurrentStatsFrameDelayBackwardMax
and
jnxSoamDmHistoryStatsFrameDelayBackwardMax
counters.


bFrameDelayBackwardAvg(13)—Enables or
disables the
jnxSoamDmCurrentStatsFrameDelayBackwardAvg
and
jnxSoamDmHistoryStatsFrameDelayBackwardAvg
counters.
bIfdvForwardBins(14)—Enables or disables
the jnxSoamDmCurrentStatsBinsEntry
counter and the
jnxSoamDmHistoryStatsBinsEntry counter
when the jnxSoamDmCfgMeasBinType is
'forwardIfdv'.
bIfdvForwardMin(15)—Enables or disables
the jnxSoamDmCurrentStatsIfdvForwardMin
and jnxSoamDmHistoryStatsIfdvForwardMin
counters.
bIfdvForwardMax(16)—Enables or disables
the
jnxSoamDmCurrentStatsIfdvForwardMax
and
jnxSoamDmHistoryStatsIfdvForwardMax
counters.
bIfdvForwardAvg(17)—Enables or disables
the
jnxSoamDmCurrentStatsIfdvForwardAvg
and
jnxSoamDmHistoryStatsIfdvForwardAvg
counters.
bIfdvBackwardBins(18)—Enables or disables
counter and the
'backwardIfdv'.
bIfdvBackwardMin(19)—Enables or disables
the
jnxSoamDmCurrentStatsIfdvBackwardMin
and
jnxSoamDmHistoryStatsIfdvBackwardMin
counters.
bIfdvBackwardMax(20)—Enables or
disables the
jnxSoamDmCurrentStatsIfdvBackwardMax
and
jnxSoamDmHistoryStatsIfdvBackwardMax
counters.


bIfdvBackwardAvg(21)—Enables or disables
the
jnxSoamDmCurrentStatsIfdvBackwardAvg
and
jnxSoamDmHistoryStatsIfdvBackwardAvg
counters.
bIfdvTwoWayBins(22)—Enables or disables
counter and the
'twoWayIfdv'.
bIfdvTwoWayMin(23)—Enables or disables
the
jnxSoamDmCurrentStatsIfdvTwoWayMin
and
jnxSoamDmHistoryStatsIfdvTwoWayMin
counters.
bIfdvTwoWayMax(24)—Enables or disables
the
jnxSoamDmCurrentStatsIfdvTwoWayMax
and
jnxSoamDmHistoryStatsIfdvTwoWayMax
counters.
bIfdvTwoWayAvg(25)—Enables or disables
the
jnxSoamDmCurrentStatsIfdvTwoWayAvg
and
jnxSoamDmHistoryStatsIfdvTwoWayAvg
counters.
bFrameDelayRangeForwardBins(26)—Enables
or disables the
counter when the
'forwardFrameDelayRange'.
bFrameDelayRangeForwardMax(27)—Enables
or disables the
jnxSoamDmCurrentStatsFrameDelayRangeForwardMax
and
jnxSoamDmHistoryStatsFrameDelayRangeForwardMax
counters.
bFrameDelayRangeForwardAvg(28)—Enables
or disables the
jnxSoamDmCurrentStatsFrameDelayRangeForwardAvg
and
jnxSoamDmHistoryStatsFrameDelayRangeForwardAvg
counters.


bFrameDelayRangeBackwardBins(29)—Enables
or disables the
counter when the
'backwardFrameDelayRange'.
bFrameDelayRangeBackwardMax(30)—Enables
or disables the
jnxSoamDmCurrentStatsFrameDelayRangeBackwardMax
and
jnxSoamDmHistoryStatsFrameDelayRangeBackwardMax
counters.
bFrameDelayRangeBackwardAvg(31)—Enables
or disables the
jnxSoamDmCurrentStatsFrameDelayRangeBackwardAvg
and
jnxSoamDmHistoryStatsFrameDelayRangeBackwardAvg
counters.
bFrameDelayRangeTwoWayBins(32)—Enables
or disables the
counter when the
'twoWayFrameDelayRange'.
bFrameDelayRangeTwoWayMax(33)—Enables
or disables the
jnxSoamDmCurrentStatsFrameDelayRangeTwoWayMax
and
jnxSoamDmHistoryStatsFrameDelayRangeTwoWayMax
counters.
bFrameDelayRangeTwoWayAvg(34)—Enables
or disables the
jnxSoamDmCurrentStatsFrameDelayRangeTwoWayAvg
and
jnxSoamDmHistoryStatsFrameDelayRangeTwoWayAvg
counters.
bMeasuredStatsFrameDelayTwoWay(35)—Enables
or disables the
jnxSoamDmMeasuredStatsFrameDelayTwoWay
counter.
bMeasuredStatsFrameDelayForward(36)—Enables
or disables the
jnxSoamDmMeasuredStatsFrameDelayForward
counter.


bMeasuredStatsFrameDelayBackward(37)—Enables
or disables the
jnxSoamDmMeasuredStatsFrameDelayBackward
counter.
bMeasuredStatsIfdvTwoWay(38)—Enables
or disables the
jnxSoamDmMeasuredStatsIfdvTwoWay
counter.
bMeasuredStatsIfdvForward(39)—Enables
or disables the
jnxSoamDmMeasuredStatsIfdvForward
counter.
bMeasuredStatsIfdvBackward(40)—Enables
or disables the
jnxSoamDmMeasuredStatsIfdvBackward
counter.
jnxSoamDmCfgMessagePeriod jnxSoamDmCfgEntry 6 Specifies the interval between Delay

Measurement OAM message transmission.
For Delay Measurement monitoring
applications, the default value is 100ms. This
object can only be written at row creation
time and cannot be modified once it has
been created.
jnxSoamDmCfgPriority jnxSoamDmCfgEntry 7 Specifies the priority of frames with Delay

Measurement OAM message information.
The default value is to be the value which
yields the lowest frame loss. This object can
only be written at row creation time and


jnxSoamDmCfgFrameSize jnxSoamDmCfgEntry 8 Specifies the Delay Measurement frame size

between 64 bytes and the maximum
transmission unit of the EVC.
The range of frame sizes from 64 through

2000 octets need to be supported, and the
range of frame sizes from 2001 through
9600 octets is suggested to be supported.
The adjustment to the frame size of the

standard frame size is accomplished by the
addition of a Data or Test TLV. A Data or
Test TLV is only added to the frame if the
frame size is greater than 64 bytes.
This object is only valid for the entity

transmitting the Delay Measurement frames
(dmDmm, dm1DmTx) and is ignored by the
entity receiving frames.
In addition, this object is not valid when

jnxSoamDmCfgVersion is 0.

jnxSoamDmCfgDataPattern jnxSoamDmCfgEntry 9 Specifies the DM data pattern included in a

Data TLV when the size of the DM frame is
determined by the jnxSoamDmFrameSize
object and jnxSoamDmTestTlvIncluded is
'false'. If the frame size object does not
define the DM frame size or
jnxSoamDmTestTlvIncluded is 'true' the

jnxSoamDmCfgTestTlvIncluded jnxSoamDmCfgEntry 10 Indicates whether a Test TLV or Data TLV

is included when the size of the DM frame is
determined by the jnxSoamDmFrameSize
object.
A value of 'true' indicates that the Test TLV

is to be included. A value of 'false' indicates
that the Data TLV is to be included.
If the frame size object does not define the

DM frame size the value of this object is
ignored.



jnxSoamDmCfgTestTlvPattern jnxSoamDmCfgEntry 11 Specifies the type of test pattern to be sent

in the DM frame Test TLV when the size of
DM PDU is determined by the
jnxSoamDmFrameSize object and
jnxSoamDmTestTlvIncluded is 'true'.
If the frame size object does not define the

DM frame size or
jnxSoamDmTestTlvIncluded is 'false' the

jnxSoamDmCfgNumIntervalsStored jnxSoamDmCfgEntry 12 Specifies the number of completed

Measurement Intervals to store in the history
statistic table
(jnxSoamDmHistoryStatsTable) At least 32
completed Measurement Intervals need to
be stored. 96 Measurement Intervals are
recommended to be stored.

jnxSoamDmCfgDestMepId jnxSoamDmCfgEntry 13 Specifies the Maintenance Association End

Point Identifier of another MEP in the same
Maintenance Association to which the SOAM
DM frame is to be sent.
This address will be used if the value of the

column jnxSoamDmDestIsMepId is 'true'. A
value of zero means that the destination
MEP ID has not been configured.

transmitting the Delay Measurement frames,
types 'dmDmm' and 'dm1DmTx'. It is not
applicable for the 'dm1DmRx' type.



jnxSoamDmCfgDestIsMepId jnxSoamDmCfgEntry 14 Specifies whether the MEP ID or the MAC

address of the destination MEP is used for
SOAM DM frame transmission.
A value of 'true' indicates that MEPID of the

target MEP is used for SOAM DM frame
transmission. A value of 'false' indicates that
the MAC address of the target MEP is used
for SOAM DM frame transmission.

transmitting the Delay Measurement frames,
types 'dmDmm' and 'dm1DmTx'. It is not
applicable for the 'dm1DmRx type.

jnxSoamDmCfgStartTimeType jnxSoamDmCfgEntry 15 Specifies the type of start time of the SOAM

DM session. The start time can be disabled
(none), immediate, relative, or fixed.
The value of 'none' is illegal and a write error

will be returned if this value is used.
The value of 'immediate' starts the SOAM

DM session when the
jnxSoamDmCfgEnabled is true.
The value of 'fixed' starts the SOAM DM

session when the
jnxSoamDmFixedStartDateAndTime is less
than or equal to the current system date and
time and jnxSoamDmCfgEnabled is true.
This value is used to implement an
On-Demand fixed time PM session.
The value of 'relative' starts the SOAM DM

session when the current system date and
time minus the
jnxSoamDmRelativeStartTime is greater
than or equal to the system date and time
when the jnxSoamDmStartTimeType object
was written and jnxSoamDmCfgEnabled is
true. This value is used to implement an
On-Demand relative time PM session.



jnxSoamDmCfgRepetitionTime jnxSoamDmCfgEntry 16 Specifies a configurable repetition time

between Measurement Intervals in a Delay
Measurement session in seconds. If the value
is 0 (none), there is no time gap between
the end of one Measurement Interval and
the start of a new Measurement Interval.
This is the normal usage case. If the value is
greater than one Measurement Interval there
is time gap between the end of one
Measurement Interval and the start of the
next Measurement Interval. The repetition
time specifies the time between the start of
consecutive Measurement Intervals; hence
the gap between the end of one
Measurement Interval and the start of the
next is equal to the difference between the
repetition time and the measurement
interval. During this gap, no SOAM PDUs are
sent for this session and no measurements
are made. If the value is greater 0 but less
than or equal to the measurement interval,
an error is returned.

jnxSoamDmCfgAlignMeasurementIntervals jnxSoamDmCfgEntry 17 Specifies whether the Measurement

Intervals for the Delay Measurement session
are aligned with a zero offset to real time.
The value 'true' indicates that each

Measurement Interval starts at a time which
is aligned to NE time source hour, if the
repetition time (or the Measurement Interval,
if the repetition time is 0) is a factor of an
hour, that is, 60min/15min = 4. For instance,
a Measurement Interval/repetition time of
15 minutes would stop/start the
Measurement Interval at 0, 15, 30, and 45
minutes of an hour. A Measurement
Interval/Repetition Time of 7 minutes would
not align to the hour since 7 minutes is NOT
a factor of an hour, that is, 60min/7min =
8.6. In this case the behavior is the same as
if the object is set to 'false'.
The value 'false' indicates that the first

Measurement Interval starts at an arbitrary
time and each subsequent Measurement
Interval starts at a time which is determined
by jnxSoamDmCfgRepetitionTime.



jnxSoamDmCfgInterFrameDelayVariationSelectionOffset jnxSoamDmCfgEntry 18 Specifies the selection offset for Inter-Frame

Delay Variation measurements. If this value
is set to n, then the IFDV is calculated by
taking the difference in frame delay between
frame F and frame (F+n). This object can
only be written at row creation time and
jnxSoamDmCfgSessionType jnxSoamDmCfgEntry 19 Indicates whether the current session is

defined to be 'Proactive' or 'On-Demand'. A
value of 'proactive' indicates the current
session is 'Proactive'. A value of 'onDemand'
indicates the current session is
'On-Demand'. This object can only be
written at row creation time and cannot be
modified once it has been created.
jnxSoamDmCfgSessionStatus jnxSoamDmCfgEntry 20 indicates the current status of the LM

session. A value of 'active' indicates the
current DM session is active, i.e. the current
time lies between the start time and the stop
time, and jnxSoamDmCfgEnabled is true. A
value of 'notActive' indicates the current DM
session is not active, i.e. it has not started
yet, has stopped upon reaching the stop
time, or is disabled.
jnxSoamDmCfgHistoryClear jnxSoamDmCfgEntry 21 Clears the Delay Measurement history Table

(jnxSoamDmHistoryStatsTable) - all rows
are deleted. When read the value always
returns 'false'. Writing this value does not
change the current stat table, nor any of the
items in the configuration table. Writing this
value during row creation has no effect.
jnxSoamDmCfgRowStatus jnxSoamDmCfgEntry 22 Specifies the status of the row. The writable

columns in a row cannot be changed if the
row is active, except for
jnxSoamDmCfgHistoryClear and
jnxSoamDmCfgEnabled objects. All columns
must have a valid value before a row can be
activated.
Managed Objects for jnxSoamDmMeasuredStatsTable

The jnxSoamDmMeasuredStatsTable, whose object identifier is {jnxSoamPmDmObjects
2}, contains the jnxSoamDmMeasuredStatsEntry that signifies the Ethernet delay
measurement (ETH-DM) statistical details. Each jnxSoamDmMeasuredStatsEntry, whose
object identifier is {jnxSoamDmMeasuredStatsTable 1}, contains the objects listed in the
following table.

The jnxSoamDmMeasuredStatsTable contains the last measured results for a SOAM

Delay Measurement session. Each row in the table represents a Delay Measurement
session for the defined MEP. This table uses four indices. The first three indices are the
indices of the Maintenance Domain, MaNet, and MEP tables. The fourth index is the
specific DM session on the selected MEP. Instances of this managed object are created
automatically by the SNMP Agent when the Delay Measurement session is running. Each
object in this table applies only if the corresponding bit is set in
jnxSoamDmCfgMeasurementEnable. The objects in this table do not need to be persistent
Table 96: jnxSoamDmMeasuredStatsTable

jnxSoamDmMeasuredStatsFrameDelayTwoWay jnxSoamDmMeasuredStatsEntry Contains the two-way frame delay

1 calculated by this MEP from the last
received SOAM PDU. This object is
undefined is jnxSoamDmCfgType is
dm1DmTx or dm1DmRx.
jnxSoamDmMeasuredStatsFrameDelayForward jnxSoamDmMeasuredStatsEntry Contains the frame delay in the forward

2 direction calculated by this MEP from
the last received SOAM PDU. The value
of this object may not be accurate in the
absence of sufficiently precise clock
synchronization. This object is
dm1DmTx.
jnxSoamDmMeasuredStatsFrameDelayBackward jnxSoamDmMeasuredStatsEntry Contains the frame delay in the

3 backward direction calculated by this
MEP from the last received SOAM PDU.
The value of this object may not be
accurate in the absence of sufficiently
precise clock synchronization. This
object is undefined is
jnxSoamDmCfgType is dm1DmTx or
dm1DmRx.
jnxSoamDmMeasuredStatsIfdvTwoWay jnxSoamDmMeasuredStatsEntry Contains the last two-way inter-frame

4 delay interval calculated by this MEP.
The value of this object is undefined
when jnxSoamDmCfgType is dm1DmTx
or dm1DmRx.
jnxSoamDmMeasuredStatsIfdvForward jnxSoamDmMeasuredStatsEntry Contains the last one-way inter-frame

5 delay interval in the forward direction
calculated by this MEP. The value of this
object is undefined when
jnxSoamDmCfgType is dm1DmTx.

Table 96: jnxSoamDmMeasuredStatsTable (continued)

jnxSoamDmMeasuredStatsIfdvBackward jnxSoamDmMeasuredStatsEntry Contains the last one-way inter-frame

6 delay interval in the backward direction
calculated by this MEP. The value of this
jnxSoamDmCfgType is dm1DmTx or or
dm1DmRx.
Managed Objects for jnxSoamDmCurrentStatsTable

The jnxSoamDmCurrentStatsTable, whose object identifier is {jnxSoamPmDmObjects
3}, contains the jnxSoamDmCurrentStatsEntry that signifies the Ethernet delay
measurement (ETH-DM) historical statistical details. Each jnxSoamDmCurrentStatsEntry,
whose object identifier is {jnxSoamDmCurrentStatsTable 1}, contains the objects listed
in the following table.
The jnxSoamDmCurrentStatsTable contains the results for the current Measurement

Interval in a SOAM Delay Measurement session gathered during the interval indicated
by iterator count. A row in this table is created automatically by the SNMP Agent when
the Delay Measurement session is configured. Each row in the table represents the current
statistics for a Delay Measurement session for the defined MEP. This table uses four
MEP tables. The fourth index is the specific DM session on the selected MEP. There can
be more than one DM session per MEP. The objects in this table apply regardless of the
value of jnxSoamDmCfgType unless otherwise specified in the object description.
Backward and two-way statistic objects are undefined if jnxSoamDmCfgType is
dm1DmRx. Except for jnxSoamDmCurrentStatsIndex, jnxSoamDmCurrentStatsStartTime
jnxSoamDmCurrentStatsElapsedTime and jnxSoamDmCurrentStatsSuspect, each
object in this table applies only if the corresponding bit is set in
jnxSoamDmCfgMeasurementEnable. The objects in this table do not need to be persistent
Table 97: jnxSoamDmCurrentStatsTable

jnxSoamDmCurrentStatsIndex jnxSoamDmCurrentStatsEntry 1 Specifies the index for the Measurement

Interval within this PM session. This value
will become the value for
jnxSoamDmHistoryStatsIndex once the
Measurement Interval is completed.

assigned index 1.
jnxSoamDmCurrentStatsStartTime jnxSoamDmCurrentStatsEntry 2 Specifies the time at which the

Measurement Interval started.

Table 97: jnxSoamDmCurrentStatsTable (continued)

jnxSoamDmCurrentStatsElapsedTime jnxSoamDmCurrentStatsEntry 3 Specifies the length of time for which the

Measurement Interval has been running,
in 0.01 seconds.
jnxSoamDmCurrentStatsSuspect jnxSoamDmCurrentStatsEntry 4 Indicates whether the Measurement

object is set to false at the start of a
measurement interval. It is set to true
when there is a discontinuity in the
performance measurements during the
Measurement Interval. Conditions for a
discontinuity include, but are not limited
to the following:



jnxSoamDmCurrentStatsFrameDelayTwoWayMin jnxSoamDmCurrentStatsEntry 5 Contains the minimum two-way frame

delay calculated by this MEP for this
Measurement Interval. This object is
dm1DmTx or dm1DmRx.
jnxSoamDmCurrentStatsFrameDelayTwoWayMax jnxSoamDmCurrentStatsEntry 6 Contains the maximum two-way frame

dm1DmTx or dm1DmRx.
jnxSoamDmCurrentStatsFrameDelayTwoWayAvg jnxSoamDmCurrentStatsEntry 7 Contains the average two-way frame

dm1DmTx or dm1DmRx.
jnxSoamDmCurrentStatsFrameDelayForwardMin jnxSoamDmCurrentStatsEntry 8 Contains the minimum one-way frame

delay in the forward direction calculated
Interval. The value of this object may not
be accurate in the absence of sufficiently
precise clock synchronization. This object
is undefined is jnxSoamDmCfgType is
dm1DmTx.


jnxSoamDmCurrentStatsFrameDelayForwardMax jnxSoamDmCurrentStatsEntry 9 Contains the maximum one-way frame

dm1DmTx.
jnxSoamDmCurrentStatsFrameDelayForwardAvg jnxSoamDmCurrentStatsEntry 10 Contains the average one-way frame

dm1DmTx.
jnxSoamDmCurrentStatsFrameDelayBackwardMin jnxSoamDmCurrentStatsEntry 11 Contains the minimum one-way frame

delay in the backward direction
Measurement Interval. The value of this
object may not be accurate in the
synchronization. This object is undefined
is jnxSoamDmCfgType is dm1DmTx or
dm1DmRx.
jnxSoamDmCurrentStatsFrameDelayBackwardMax jnxSoamDmCurrentStatsEntry 12 Contains the maximum one-way frame

dm1DmRx.
jnxSoamDmCurrentStatsFrameDelayBackwardAvg jnxSoamDmCurrentStatsEntry 13 Contains the average one-way frame

dm1DmRx.
jnxSoamDmCurrentStatsIfdvForwardMin jnxSoamDmCurrentStatsEntry 14 Contains the minimum one-way

inter-frame delay interval in the forward
direction calculated by this MEP for this


jnxSoamDmCurrentStatsIfdvForwardMax jnxSoamDmCurrentStatsEntry 15 Contains the maximum one-way

jnxSoamDmCurrentStatsIfdvForwardAvg jnxSoamDmCurrentStatsEntry 16 Contains the average one-way

jnxSoamDmCurrentStatsIfdvBackwardMin jnxSoamDmCurrentStatsEntry 17 Contains the minimum one-way

inter-frame delay interval in the backward
dm1DmRx.
jnxSoamDmCurrentStatsIfdvBackwardMax jnxSoamDmCurrentStatsEntry 18 Contains the maximum one-way

dm1DmRx.
jnxSoamDmCurrentStatsIfdvBackwardAvg jnxSoamDmCurrentStatsEntry 19 Contains the average one-way

dm1DmRx.
jnxSoamDmCurrentStatsIfdvTwoWayMin jnxSoamDmCurrentStatsEntry 20 Contains the minimum two-way

inter-frame delay interval calculated by
this MEP for this Measurement Interval.
The value of this object is undefined when
dm1DmRx.
jnxSoamDmCurrentStatsIfdvTwoWayMax jnxSoamDmCurrentStatsEntry 21 Contains the maximum two-way

dm1DmRx.


jnxSoamDmCurrentStatsIfdvTwoWayAvg jnxSoamDmCurrentStatsEntry 22 Contains the average two-way

dm1DmRx.
jnxSoamDmCurrentStatsSoamPdusSent jnxSoamDmCurrentStatsEntry 23 Contains the count of the number of

when jnxSoamDmCfgType is dmDmm or
dm1DmTx and is undefined if
jnxSoamDmCfgType is dm1DmRx. It
indicates the number of DMM or 1DM
SOAM frames transmitted.
jnxSoamDmCurrentStatsSoamPdusReceived jnxSoamDmCurrentStatsEntry 24 Contains the count of the number of

Measurement Interval. This object
indicates the number of DMR and 1DM
SOAM frames received. This object
applies when jnxSoamDmCfgType is
dmDmm or dm1DmRx and is undefined
if jnxSoamDmCfgTypeis dm1DmTx.
Managed Objects for jnxSoamDmHistoryStatsTable

The jnxSoamDmHistoryStatsTable, whose object identifier is {jnxSoamPmLmObjects 4},
contains the jnxSoamDmHistoryStatsEntry that signifies the Ethernet delay measurement
(ETH-DM) historical statistical details. Each jnxSoamDmHistoryStatsEntry, whose object
identifier is {jnxSoamDmHistoryStatsTable 1}, contains the objects listed in the following
table.
The jnxSoamDmHistoryStatsTable contains the results for history Measurement Intervals

in a SOAM Loss Measurement session. Rows of this table object are created automatically
by the SNMP Agent when the Loss Measurement session is running and a Measurement
Interval is completed. Each row in the table represents the history statistics for a Loss
Measurement session Measurement Interval for the defined MEP. This table uses five
MEP tables. The fourth index is the specific LM session on the selected MEP. The fifth
index index the specific Measurement Interval.
At least 32 completed Measurement Intervals are to be supported. 96 completed

Measurement Intervals are recommended to be supported. If there are at least 32 rows
in the table and a new Measurement Interval completes and a new row is to be added
to the table, the oldest completed Measurement Interval may be deleted (row deletion).
If the measurement interval is other than 15 minutes then a minimum of 8 hours of
completed Measurement Intervals are to be supported and 24 hours are recommended
to be supported.

Except for jnxSoamDmHistoryStatsIndex, jnxSoamDmHistoryStatsEndTime,

jnxSoamDmHistoryStatsElapsedTime and jnxSoamDmHistoryStatsSuspect, each object
jnxSoamDmCfgMeasurementEnable. The rows and objects in this table are to be
persistent upon reboot or restart of a device.
Table 98: jnxSoamDmHistoryStatsTable

jnxSoamDmHistoryStatsIndex jnxSoamDmHistoryStatsEntry 1 Specifies the index for the Measurement

Interval within this PM session.

assigned index 1. Measurement Intervals
for FLR (stored in this table) are based
on iterator count and are indexed
independently of Measurement Intervals
for availability
Referential integrity is necessary, i.e., the

index needs to be persistent upon a
reboot or restart of a device. The index is
never reused while this session is active
until it wraps to zero. The index value
keeps increasing up to that time.
jnxSoamDmHistoryStatsEndTime jnxSoamDmHistoryStatsEntry 2 Specifies the time at which the

Measurement Interval ended.
jnxSoamDmHistoryStatsElapsedTime jnxSoamDmHistoryStatsEntry 3 Specifies the length of time that the

Measurement Interval ran for, in 0.01
seconds.
jnxSoamDmHistoryStatsSuspect jnxSoamDmHistoryStatsEntry 4 Indicates whether the Measurement

object is set to true when there is a
discontinuity in the performance
measurements during the Measurement
Interval. Conditions for a discontinuity
include, but are not limited to the
following:




Table 98: jnxSoamDmHistoryStatsTable (continued)

jnxSoamDmHistoryStatsFrameDelayTwoWayMin jnxSoamDmHistoryStatsEntry 5 Contains the minimum two-way frame

dm1DmTx or dm1DmRx.
jnxSoamDmHistoryStatsFrameDelayTwoWayMax jnxSoamDmHistoryStatsEntry 6 Contains the maximum two-way frame

dm1DmTx or dm1DmRx.
jnxSoamDmHistoryStatsFrameDelayTwoWayAvg jnxSoamDmHistoryStatsEntry 7 Contains the average two-way frame

dm1DmTx or dm1DmRx.
jnxSoamDmHistoryStatsFrameDelayForwardMin jnxSoamDmHistoryStatsEntry 8 Contains the minimum one-way frame

dm1DmTx.
jnxSoamDmHistoryStatsFrameDelayForwardMax jnxSoamDmHistoryStatsEntry 9 Contains the maximum one-way frame

dm1DmTx.
jnxSoamDmHistoryStatsFrameDelayForwardAvg jnxSoamDmHistoryStatsEntry 10 Contains the average one-way frame

dm1DmTx.
jnxSoamDmHistoryStatsFrameDelayBackwardMin jnxSoamDmHistoryStatsEntry 11 Contains the minimum one-way frame

dm1DmRx.


jnxSoamDmHistoryStatsFrameDelayBackwardMax jnxSoamDmHistoryStatsEntry 12 Contains the maximum one-way frame

dm1DmRx.
jnxSoamDmHistoryStatsFrameDelayBackwardAvg jnxSoamDmHistoryStatsEntry 13 Contains the average one-way frame

dm1DmRx.
jnxSoamDmHistoryStatsIfdvForwardMin jnxSoamDmHistoryStatsEntry 14 Contains the minimum one-way

jnxSoamDmHistoryStatsIfdvForwardMax jnxSoamDmHistoryStatsEntry 15 Contains the maximum one-way

jnxSoamDmHistoryStatsIfdvForwardAvg jnxSoamDmHistoryStatsEntry 16 Contains the average one-way

jnxSoamDmHistoryStatsIfdvBackwardMin jnxSoamDmHistoryStatsEntry 17 Contains the minimum one-way

dm1DmRx.


jnxSoamDmHistoryStatsIfdvBackwardMax jnxSoamDmHistoryStatsEntry 18 Contains the maximum one-way

dm1DmRx.
jnxSoamDmHistoryStatsIfdvBackwardAvg jnxSoamDmHistoryStatsEntry 19 Contains the average one-way

dm1DmRx.
jnxSoamDmHistoryStatsIfdvTwoWayMin jnxSoamDmHistoryStatsEntry 20 Contains the minimum two-way

dm1DmRx.
jnxSoamDmHistoryStatsIfdvTwoWayMax jnxSoamDmHistoryStatsEntry 21 Contains the maximum two-way

dm1DmRx.
jnxSoamDmHistoryStatsIfdvTwoWayAvg jnxSoamDmHistoryStatsEntry 22 Contains the average two-way

dm1DmRx.
jnxSoamDmHistoryStatsSoamPdusSent jnxSoamDmHistoryStatsEntry 23 Contains the count of the number of

when jnxSoamDmCfgType is dmDmm or
dm1DmTx and is undefined if
jnxSoamDmCfgType is dm1DmRx. It
indicates the number of DMM or 1DM
SOAM frames transmitted.
jnxSoamDmHistoryStatsSoamPdusReceived jnxSoamDmHistoryStatsEntry 24 Contains the count of the number of

Measurement Interval. This object
indicates the number of DMR and 1DM
SOAM frames received. This object
applies when jnxSoamDmCfgType is
dmDmm or dm1DmRx and is undefined
if jnxSoamDmCfgTypeis dm1DmTx.

Managed Objects for jnxSoamLmThresholdCfgTable

The jnxSoamLmThresholdCfgTable, whose object identifier is {jnxSoamPmDmObjects
5}, contains the jnxSoamLmThresholdCfgEntry that signifies the Ethernet loss
measurement (ETH-LM) configuration threshold values. Each
jnxSoamLmThresholdCfgEntry, whose object identifier is {jnxSoamLmThresholdCfgTable
1}, contains the objects listed in the following table.
The jnxSoamLmThresholdCfgTable contains the list of Loss Measurement configuration

threshold values for LM Performance Monitoring. The main purpose of the threshold
configuration table is to configure threshold alarm notifications indicating that a specific
performance metric is not being met. Each row in the table represents a Loss Measurement
session threshold set for the defined MEP. This table uses five indices. The first three
indices are the indices of the Maintenance Domain, MaNet, and MEP tables. The fourth
index is the specific LM session on the selected MEP. The fifth index is the specific
threshold set number. Rows in this table are not created automatically. A row is created
in this table to set up a threshold set on a configured MEP that has a configured LM
session. If two managers try to 'create' the same row at the same time, the first creation
would succeed, the second creation attempt would result in an error. The second creation
attempt would then need to select a new index value to successfully create a new row.
An NE needs to support at least one threshold set for NE SOAM PM compliance. A second
threshold set on the NE is desirable. More than two threshold sets can be configured on
the NE if supported on the NE. All the objects in the row have a default value that disables
the particular threshold measurement. In order to enable a threshold measurement the
particular bit in the jnxSoamLmThresholdCfgEnable object is to be set to '1' and the
selected threshold measurement is to have a threshold value configured. Non-configured
threshold measurements are disabled by default. The writable objects in this table need
to be persistent upon reboot or restart of a device.
Table 99: jnxSoamLmThresholdCfgTable

jnxSoamLmThresholdCfgIndex jnxSoamLmThresholdCfgEntry 1 Denotes the index of the threshold

number for the specific LM threshold
entry. An index value of '1' needs to be
supported. Other index values can also
be supported.

Table 99: jnxSoamLmThresholdCfgTable (continued)

jnxSoamLmThresholdCfgEnable jnxSoamLmThresholdCfgEntry 2


Contains a vector of bits that indicates

the type of SOAM LM thresholds
notifications that are enabled. A bit set
to '1' enables the specific SOAM LM
threshold notification and when the
specific counter is enabled and the
threshold is crossed a notification is
generated. A bit set to '0' disables the
specific SOAM LM threshold notification.
If a particular SOAM LM threshold is not
bJnxSoamLmMeasuredFlrForwardThreshold(0)—Enables
or disables measured frame loss forward
ratio threshold notification. The
notification is sent immediately when the
jnxSoamLmMeasuredStatsForwardFlr
value is greater than or equal to the
threshold value.
bJnxSoamLmMaxFlrForwardThreshold(1)—Enables
or disables maximum frame loss forward
jnxSoamLmCurrentStatsForwardMaxFlr
value is greater than or equal to threshold
value in a Measurement Interval.
bJnxSoamLmAvgFlrForwardThreshold(2)—Enables
or disables average frame loss forward
notification is sent when at the end of a
Measurement Interval if the
jnxSoamLmCurrentStatsForwardAvgFlr
threshold value.
bJnxSoamLmMeasuredFlrBackwardThreshold(3)—Enables
or disables measured frame loss
backward ratio threshold notification.
The notification is sent immediately when
the
jnxSoamLmMeasuredStatsBackwardFlr
threshold value.
bJnxSoamLmMaxFlrBackwardThreshold(4)—Enables
or disables maximum frame loss
backward ratio threshold notification.
The notification is sent immediately when
the
jnxSoamLmCurrentStatsBackwardMaxFlr
bJnxSoamLmAvgFlrBackwardThreshold(5)—Enables
or disables average frame loss backward



jnxSoamLmCurrentStatsBackwardAvgFlr
threshold value.
jnxSoamLmThresholdCfgAvgFlrForwardThreshold jnxSoamLmThresholdCfgEntry 3 Sets the average forward frame loss ratio

threshold value that will be used to
determine if a threshold notification is
generated.
jnxSoamLmThresholdCfgAvgFlrBackwardThreshold jnxSoamLmThresholdCfgEntry 4 Sets the average backward frame loss

ratio threshold value that will be used to
generated.
jnxSoamLmThresholdCfgRowStatus jnxSoamLmThresholdCfgEntry 5 Specifies the status of the ETH-LM

threshold configuration row status. The
writable columns in a row cannot be
changed if the row is active. All columns
are to have a valid value before a row can
be activated.
Managed Objects for jnxSoamDmThresholdCfgTable

The jnxSoamDmThresholdCfgTable, whose object identifier is {jnxSoamPmDmObjects
5}, contains the jnxSoamDmThresholdCfgEntry that signifies the Ethernet delay
measurement (ETH-DM) configuration threshold values. Each
jnxSoamDmThresholdCfgEntry, whose object identifier is {jnxSoamDmThresholdCfgTable
The jnxSoamDmThresholdCfgTable contains the list of delay measurement configuration

threshold values for DM Performance Monitoring. The main purpose of the threshold
configuration table is to configure threshold alarm notifications indicating that a specific
performance metric is not being met. Each row in the table represents a delay
measurement session threshold set for the defined MEP. This table uses five indices. The
first three indices are the indices of the Maintenance Domain, MaNet, and MEP tables.
The fourth index is the specific DM session on the selected MEP. The fifth index is the
specific threshold set number. Rows in this table are not created automatically. A row is
created in this table to set up a threshold set on a configured MEP that has a configured
DM session. If two managers try to 'create' the same row at the same time, the first
creation would succeed, the second creation attempt would result in an error. The second
creation attempt would then need to select a new index value to successfully create a
new row. An NE needs to support at least one threshold set for NE SOAM PM compliance.
A second threshold set on the NE is desirable. More than two threshold sets can be
configured on the NE if supported on the NE. All the objects in the row have a default
value that disables the particular threshold measurement. In order to enable a threshold
measurement the particular bit in the jnxSoamDmThresholdCfgEnable object is to be

set to '1' and the selected threshold measurement is to have a threshold value configured.
Non-configured threshold measurements are disabled by default. The writable objects
in this table need to be persistent upon reboot or restart of a device.
Table 100: jnxSoamDmThresholdCfgTable

jnxSoamDmThresholdCfgIndex jnxSoamDmThresholdCfgEntry 1 Denotes the index of the threshold

number for the specific DM threshold
entry. An index value of '1' needs to be
supported. Other index values can also
be supported.

Table 100: jnxSoamDmThresholdCfgTable (continued)

jnxSoamDmThresholdCfgEnable jnxSoamDmThresholdCfgEntry 2


Contains a vector of bits that indicates

the type of SOAM DM thresholds
notifications that are enabled. A bit set
to '1' enables the specific SOAM DM
threshold notification and when the
specific counter is enabled and the
threshold is crossed a notification is
generated. A bit set to '0' disables the
specific SOAM DM threshold notification.
If a particular SOAM DM threshold is not
bJnxSoamDmMeasuredFrameDelayTwoWayThreshold(0)—Enables
or disables measured frame two-way
delay threshold notification. The
jnxSoamDmMeasuredStatsFrameDelayTwoWay
value.
bJnxSoamDmMaxFrameDelayTwoWayThreshold(1)—Enables
or disables maximum frame two-way
jnxSoamDmCurrentStatsFrameDelayTwoWayMax
bJnxSoamDmAvgFrameDelayTwoWayThreshold(2)—Enables
or disables average frame two-way delay
threshold notification. The notification is
sent when at the end of a Measurement
Interval if the
jnxSoamDmCurrentStatsFrameDelayTwoWayAvg
threshold value.
bJnxSoamDmMeasuredIfdvTwoWayThreshold(3)—Enables
or disables measured frame IFDV
two-way threshold notification. The
jnxSoamDmMeasuredStatsIfdvTwoWay
value.
bJnxSoamDmMaxIfdvTwoWayThreshold(4)—Enables
or disables maximum frame IFDV
jnxSoamDmCurrentStatsIfdvTwoWayMax
bJnxSoamDmAvgIfdvTwoWayThreshold(5)—Enables
or disables average frame IFDV two-way


Interval if the
jnxSoamDmCurrentStatsIfdvTwoWayAvg
threshold value.
bJnxSoamDmMaxFrameDelayRangeTwoWayThreshold(6)—Enables
or disables maximum Frame Delay Range
jnxSoamDmCurrentStatsFrameDelayRangeTwoWayMax
bJnxSoamDmAvgFrameDelayRangeTwoWayThreshold(7)—Enables
or disables average Frame Delay Range
jnxSoamDmCurrentStatsFrameDelayRangeTwoWayAvg
threshold value.
bJnxSoamDmMeasuredFrameDelayForwardThreshold(8)—Enables
or disables measured forward frame
jnxSoamDmMeasuredStatsFrameDelayForward
value.
bJnxSoamDmMaxFrameDelayForwardThreshold(9)—Enables
or disables maximum forward frame
jnxSoamDmCurrentStatsFrameDelayForwardMax
bJnxSoamDmAvgFrameDelayForwardThreshold(10)—Enables
or disables average forward frame delay
Interval if the
jnxSoamDmCurrentStatsFrameDelayForwardAvg
threshold value.


bJnxSoamDmMeasuredIfdvForwardThreshold(11)—Enables
or disables measured frame IFDV forward
sent immediately when the
jnxSoamDmMeasuredStatsIfdvForward
value.
bJnxSoamDmMaxIfdvForwardThreshold(12)—Enables
or disables maximum frame IFDV forward
sent immediately when the
jnxSoamDmCurrentStatsIfdvForwardMax
bJnxSoamDmAvgIfdvForwardThreshold(13)—Enables
or disables average frame IFDV forward
Interval if the
jnxSoamDmCurrentStatsIfdvForwardAvg
threshold value.
bJnxSoamDmMaxFrameDelayRangeForwardThreshold(14)—Enables
forward threshold notification. The
jnxSoamDmCurrentStatsFrameDelayRangeForwardMax
bJnxSoamDmAvgFrameDelayRangeForwardThreshold(15)—Enables
forward threshold notification. The
jnxSoamDmCurrentStatsFrameDelayRangeForwardAvg
threshold value.
bJnxSoamDmMeasuredFrameDelayBackwardThreshold(16)—Enables
or disables measured backward frame
jnxSoamDmMeasuredStatsFrameDelayBackward
value.
bJnxSoamDmMaxFrameDelayBackwardThreshold(17)—Enables
or disables maximum backward frame
jnxSoamDmCurrentStatsFrameDelayBackwardMax


bJnxSoamDmAvgFrameDelayBackwardThreshold(18)—Enables
or disables average backward frame
jnxSoamDmCurrentStatsFrameDelayBackwardAvg
threshold value.
bJnxSoamDmMeasuredIfdvBackwardThreshold(19)—Enables
or disables measured frame IFDV
backward threshold notification. The
jnxSoamDmMeasuredStatsIfdvBackward
value.
bJnxSoamDmMaxIfdvBackwardThreshold(20)—Enables
or disables maximum frame IFDV
jnxSoamDmCurrentStatsIfdvBackwardMax
bJnxSoamDmAvgIfdvBackwardThreshold(21)—Enables
or disables average frame IFDV backward
Interval if the
jnxSoamDmCurrentStatsIfdvBackwardAvg
threshold value.
bJnxSoamDmMaxFrameDea
l yRangeBackwardThreshod
l (22)—Enabe
ls
jnxSoamDmCurrentStatsFrameDelayRangeBackwardMax
bJnxSoamDmAvgFrameDelayRangeBackwardThreshod
l (23)—Enabe
ls
jnxSoamDmCurrentStatsFrameDelayRangeBackwardAvg
threshold value.
jnxSoamDmThresholdCfgAvgFrameDelayTwoWayThreshold jnxSoamDmThresholdCfgEntry 3 Sets the average two-way delay

threshold value that will be used to
generated.


jnxSoamDmThresholdCfgAvgIfdvTwoWayThreshold jnxSoamDLmThresholdCfgEntry 4 Sets the average two-way IFDV threshold

value that will be used to determine if a
threshold notification is generated.
jnxSoamDmThresholdCfgRowStatus jnxSoamDmThresholdCfgEntry 5 Specifies the status of the ETH-DM

threshold configuration row status. The
writable columns in a row cannot be
changed if the row is active. All columns
are to have a valid value before a row can
be activated.
Managed Objects for jnxSoamPmNotificationObj Table

The jnxSoamPmNotificationObj table, whose object identifier is {jnxSoamPmMibObjects
Table 101: jjnxSoamPmNotificationObj Table

jnxSoamPmNotificationObjDateAndTime jnxSoamPmNotificationObj 1 Contains the time and date at the time

that the notification event is detected,
not the time of the notification
generation. This object is used only for
notifications. The mechanism to set and
keep current the date and time is not
specified.
jnxSoamPmNotificationObj 2 Denotes the object identifier of the object

that caused the generation of the
notification from the
jnxSoamLmThresholdEntry or
jnxSoamDmThresholdEntry. This object
is only used for the notification.
jnxSoamPmNotificationObjThresholdConfig jnxSoamPmNotificationObj 3 Denotes the configured threshold value

of the object that caused the generation
of the notification. This object is only used
for the notification.
jnxSoamPmNotificationObjThresholdValue jnxSoamPmNotificationObj 4 Denotes the measured value of the object

at the time of the generation of the
Notification, from the
jnxSoamLmMeasuredStatsTable,
jnxSoamLmCurrentStatsTable,
jnxSoamDmMeasuredStatsTable or
jnxSoamDmCurrentStatsTable. This
object is only used for the notification.

Table 101: jjnxSoamPmNotificationObj Table (continued)

jnxSoamPmNotificationObjSuspect jnxSoamPmNotificationObj 5 Denotes the suspect flag for the current

Measurement Interval in which the
notification was generated from the
jnxSoamLmCurrentStatsTable, or
jnxSoamDmCurrentStatsTable. This
object is only used for the notification.
jnxSoamPmNotificationObjCrossingType jnxSoamPmNotificationObj 6 Denotes the Notification Crossing Type

of the object that caused the generation
of the notification from the
jnxSoamLmThresholdEntry or
jnxSoamDmThresholdEntry.
aboveAlarm(1)—Indicates that the

crossing type alarm was an above
threshold
setAlarm(2)—Indicates that the crossing

type alarm was a set threshold
clearAlarm(3)—Indicates that the

crossing type alarm was a clear threshold
This object is only used for the
notification.
jnxSoamPmNotificationObjDestinationMep jnxSoamPmNotificationObj 7 Denotes the MAC address of the

Destination MEP associated the
notification found in either the
jnxSoamDmCfgTable or
jnxSoamLmCfgTable. This object is only
used for the notification.
jnxSoamPmNotificationObjPriority jnxSoamPmNotificationObj 8 Denotes the CoS priority of the

associated notification found in either the
jnxSoamDmCfgTable or
jnxSoamLmCfgTable. This object is only
used for the notification.
Managed Objects for jnxSoamPmNotifications Table

The jnxSoamPmNotifications table, whose object identifier is {jnxSoamPmMib 0}, contains
the objects listed in the following table.

Table 102: jjnxSoamPmNotifications Table

jnxSoamLmSessionStartStopAlarm jnxSoamPmNotifications 1 A jnxSoamLmSessionStartStopAlarm

notification is sent when the state of
jnxSoamLmCfgSessionStatus changes.
The management entity that receives the

notification can identify the system from
the network source address of the
notification, and can identify the
individual PM session reporting the
start/stop by the indices in the OID
jnxSoamLmCfgSessionStatus, including
dot1agCfmMdIndex, dot1agCfmMaIndex,
dot1agCfmMepIdentifier, and
jnxSoamLmCfgIndex.
An agent is not to generate more than

one jnxSoamLmSessionStartStopAlarm
'notification-event' in a given time interval
per LM session as specified by the
jnxSoamPmNotificationCfgAlarmInterval.
A 'notification-event' is the transmission
of a single notification to a list of
notification destinations.
If additional operational state changes

occur within the
jnxSoamPmNotificationCfgAlarmInterval
period, then notification generation for
these changes are be suppressed by the
agent until the current alarm interval
expires. At the end of an alarm interval
period, one notification-event is
generated if any operational state
changes occurred since the start of the
alarm interval period. In such a case,
another alarm interval period is started
right away.

Table 102: jjnxSoamPmNotifications Table (continued)

jnxSoamDmSessionStartStopAlarm jnxSoamPmNotifications 2 A jnxSoamDmSessionStartStopAlarm

notification is sent when the state of
jnxSoamDmCfgSessionStatus changes.
The management entity that receives the

notification can identify the system from
the network source address of the
notification, and can identify the
individual PM session reporting the
start/stop by the indices in the OID
jnxSoamDmCfgSessionStatus, including
dot1agCfmMdIndex, dot1agCfmMaIndex,
dot1agCfmMepIdentifier, and
jnxSoamLmCfgIndex.

one jnxSoamDmSessionStartStopAlarm
'notification-event' in a given time interval
per DM session as specified by the
If additional operational state changes

occur within the
these changes are be suppressed by the
generated if any operational state
changes occurred since the start of the
right away.


jnxSoamPmThresholdCrossingAlarm jnxSoamPmNotifications 3


"An jnxSoamPmThresholdCrossingAlarm
notification is sent if the following
conditions are met for a particular type.
For an aboveAlarm, the following five
conditions must be satisfied:
1. Measurement of the parameter is

enabled via
jnxSoamLmCfgMeasurementEnable
for a LM crossing or
jnxSoamDmCfgMeasurementEnable
for a DM crossing.
2. The parameter threshold is configured
in the jnxSoamLmThresholdCfgTable
or jnxSoamDmThresholdCfgTable;
and c) the threshold crossing type of
bPmThresholdAboveAlarm is
enabled.
3. The measured value of the parameter
exceeds the value configured in the
jnxSoamLmThresholdCfgTable for a
LM crossing entry or
jnxSoamDmThresholdCfgTable for a
DM crossing entry for a type of
bPmThresholdAboveAlarm.
4. No previous
jnxSoamPmThresholdCrossingAlarm
notifications with type aboveAlarm
have been sent relating to the same
threshold in the
jnxSoamLmThresholdCfgTable or
jnxSoamDmThresholdCfgTable and
the same parameter, during this
Measurement Interval.
For a setAlarm, the following five

conditions must be met:

enabled using
for a DM crossing.
or jnxSoamDmThresholdCfgTable.
3. The threshold crossing type of
bPmThresholdSetClearAlarm is
enabled.
exceeds the value configured in the



bPmThresholdSetClearAlarm for the
5. The previous measured value did not
exceed the value configured in the
bPmThresholdSetClearAlarm.
For a clearAlarm, the following five

conditions must be met:

enabled using
for a DM crossing.
or jnxSoamDmThresholdCfgTable.
3. The threshold crossing type of
bPmThresholdSetClearAlarm is
enabled.
did not exceed the value configured
for a LM crossing entry or
bPmThresholdSetClearAlarm for the
5. The previous measured value did
exceed the value configured in the
bPmThresholdSetClearAlarm.


In the case of thresholds applied to a

maximum or average measurement
counter, the previous measured value is
the value of the counter at the end of the
preceding Measurement Interval. In the
case of thresholds applied to the last
measured value, it is the previous
measured value. The management entity
that receives the notification can identify
the system from the network source
address of the notification, and can
identify the LM or DM session reporting
the threshold crossing by the indices in
the
jnxSoamPmNotificationCfgThresholdId
object, including dot1agCfmMdIndex,
dot1agCfmMaIndex,
dot1agCfmMepIdentifier, and the
jnxSoamLmCfgIndex or
jnxSoamDmCfgIndex.

one jnxSoamLmThresholdCrossingAlarm
'notification-event' of a given type per LM
or DM session as specified by
If additional threshold crossing events

occur within the
these changes are suppressed by the
generated if any threshold crossing
events occurred since the start of the
right away.


CHAPTER 35
Configuring Virtual Private LAN Service
• Introduction to VPLS on page 1235

• Introduction to Configuring VPLS on page 1236
• VPLS Multihoming Overview on page 1237
• Configuring VPLS Routing Instances on page 1239
• Configuring Interfaces for VPLS Routing in ACX Series on page 1255
• Configuring VLAN Identifiers for VLANs and VPLS Routing Instances in ACX
Series on page 1262
• Configuring Static Pseudowires for VPLS on page 1266
• Configuring VPLS Without a Tunnel Services PIC on page 1267
• Configuring VPLS Multihoming (FEC 128) on page 1268
• Configuring Firewall Filters and Policers for VPLS in ACX Series on page 1271
• Configuring Interoperability Between BGP Signaling and LDP Signaling in
VPLS on page 1274
• Interoperability Between BGP Signaling and LDP Signaling in VPLS on page 1279
• PE Router Mesh Groups for VPLS Routing Instances on page 1281
• Example: Configuring BGP-Based H-VPLS Using Different Mesh Groups for Each Spoke
Router on page 1282
• Example: Configuring LDP-Based H-VPLS Using a Single Mesh Group to Terminate
the Layer 2 Circuits on page 1304
• Example: Configuring H-VPLS With VLANs on page 1310
Introduction to VPLS
VPLS is an Ethernet-based point-to-multipoint Layer 2 VPN. It allows you to connect

geographically dispersed Ethernet local area networks (LAN) sites to each other across
an MPLS backbone. For customers who implement VPLS, all sites appear to be in the
same Ethernet LAN even though traffic travels across the service provider's network.
NOTE: In ACX Series routers, VPLS configuration is supported only on


VPLS, in its implementation and configuration, has much in common with a Layer 2 VPN.
In VPLS, a packet originating within a service provider customer’s network is sent first to
a customer edge (CE) device (for example, a router or Ethernet switch). It is then sent
to a provider edge (PE) router within the service provider’s network. The packet traverses
the service provider’s network over a MPLS label-switched path (LSP). It arrives at the
egress PE router, which then forwards the traffic to the CE device at the destination
customer site.
NOTE: In the VPLS documentation, the word router in terms such as PE router
is used to refer to any device that provides routing functions.
The difference is that for VPLS, packets can traverse the service provider’s network in
point-to-multipoint fashion, meaning that a packet originating from a CE device can be
broadcast to all the PE routers participating in a VPLS routing instance. In contrast, a
Layer 2 VPN forwards packets in point-to-point fashion only.
The paths carrying VPLS traffic between each PE router participating in a routing instance
are called pseudowires. The pseudowires are signaled using either BGP or LDP.
Introduction to Configuring VPLS
Virtual private LAN service (VPLS) allows you to provide a point-to-multipoint LAN
between a set of sites in a virtual private network (VPN).
NOTE: In ACX Series routers, VPLS configuration is supported only on

To configure VPLS functionality, you must enable VPLS support on the provider edge
(PE) router. You must also configure PE routers to distribute routing information to the
other PE routers in the VPLS and configure the circuits between the PE routers and the
customer edge (CE) routers.
Each VPLS is configured under a routing instance of type vpls. A vpls routing instance
can transparently carry Ethernet traffic across the service provider’s network. As with
other routing instances, all logical interfaces belonging to a VPLS routing instance are
listed under that instance.
In addition to VPLS routing instance configuration, you must configure MPLS

label-switched paths (LSPs) between the PE routers, IBGP sessions between the PE
routers, and an interior gateway protocol (IGP) on the PE and provider (P) routers.
By default, VPLS is disabled.

Chapter 35: Configuring Virtual Private LAN Service
Many configuration procedures for VPLS are identical to the procedures for Layer 2 VPNs
and Layer 3 VPNs.
VPLS Multihoming Overview
Virtual private LAN service (VPLS) multihoming enables you to connect a customer site
to two or more PE routers to provide redundant connectivity. A redundant PE router can
provide network service to the customer site as soon as a failure is detected. VPLS
multihoming helps to maintain VPLS service and traffic forwarding to and from the
multihomed site in the event of the following types of network failures:
• PE router to CE device link failure
• PE router failure
• MPLS-reachability failure between the local PE router and a remote PE router
Figure 63: CE Device Multihomed to Two PE Routers
Figure 63 on page 1237 illustrates how a CE device could be multihomed to two PE routers.
Device CE1 is multihomed to Routers PE1 and PE2. Device CE2 has two potential paths
to reach Device CE1, but only one path is active at any one time. If Router PE1 were the
designated VPLS edge (VE) device (also called a designated forwarder), BGP would
signal a pseudowire from Router PE3 to Router PE1. If a failure occurred over this path,
Router PE2 would be made the designated VE device, and BGP would re-signal the
pseudowire from Router PE3 to Router PE2.
Multihomed PE routers advertise network layer reachability information (NLRI) for the
multihomed site to the other PE routers in the VPLS network. The NLRI includes the site
ID for the multihomed PE routers. For all of the PE routers multihomed to the same CE
device, you need to configure the same site ID. The remote VPLS PE routers use the site
ID to determine where to forward traffic addressed to the customer site. To avoid route
collisions, the site ID shared by the multihomed PE routers must be different than the
site IDs configured on the remote PE routers in the VPLS network.

Although you configure the same site ID for each of the PE routers multihomed to the
same CE device, you can configure unique values for other parameters, such as the route
distinguisher. These values help to determine which multihomed PE router is selected
as the designated VE device to be used to reach the customer site.
BEST PRACTICE: We recommend that you configure unique route

distinguishers for each multihomed PE router. Configuring unique route
distinguishers helps with faster convergence when the connection to a primary
multihomed PE router goes down. If you configure unique route distinguishers,
the other PE routers in the VPLS network must maintain additional state for
the multihomed PE routers.
Remote PE routers in the VPLS network need to determine which of the multihomed PE
routers should forward traffic to reach the CE device. To make this determination, remote
PE routers use the VPLS path-selection process to select one of the multihomed PE
routers based on its NLRI advertisement. Because remote PE routers pick only one of the
NLRI advertisements, it establishes a pseudowire to only one of the multihomed PE
routers, the PE router that originated the winning advertisement. This prevents multiple
paths from being created between sites in the network, preventing the formation of
Layer 2 loops. If the selected PE router fails, all PE routers in the network automatically
switch to the backup PE router and establish new pseudowires to it.
BEST PRACTICE: To prevent the formation of Layer 2 loops between the CE

devices and the multihomed PE routers, we recommend that you employ the
Spanning Tree Protocol (STP) on your CE devices. Layer 2 loops can form
due to incorrect configuration. Temporary Layer 2 loops can also form during
convergence after a change in the network topology.
The PE routers run the BGP path selection procedure on locally originated and received
Layer 2 route advertisements to establish that the routes are suitable for advertisement
to other peers, such as BGP route reflectors. If a PE router in a VPLS network is also a
route reflector, the path selection process for the multihomed site has no effect on the
path selection process performed by this PE router for the purpose of reflecting Layer 2
routes. Layer 2 prefixes that have different route distinguishers are considered to have
different NLRIs for route reflection. The VPLS path selection process enables the route
reflector to reflect all routes that have different route distinguishers to the route reflector
clients, even though only one of these routes is used to create the VPLS pseudowire to
the multihomed site.
Junos OS supports VPLS multihoming for both FEC 128 and FEC 129. Support for FEC
129 is added in Junos OS Release 12.3.
Related • Configuring VPLS Multihoming (FEC 128) on page 1268

Documentation
• Advantages of Using Autodiscovery for VPLS Multihoming
• Example: Configuring VPLS Multihoming (FEC 129)

• Example: VPLS Multihoming, Improved Convergence Time
Configuring VPLS Routing Instances
To configure a VPLS routing instance, include the vpls statement:
vpls {
active-interface {
any;
primary interface-name;
}
connectivity-type (ce | irb | permanent);
control-word;
encapsulation-type encapsulation-type;
interface-mac-limit limit;
import-labeled-routes [ routing-instance-name ];
label-block-size size;
mac-table-aging-time time;
mac-table-size size;
neighbor neighbor-id;
no-control-word;
no-tunnel-services;
site site-name {
active-interface {
any;
}
}
mesh-group mesh-group-name;
multi-homing;
site-identifier identifier;
site-preference preference-value {
backup;
primary;
}
}
site-range number;
traceoptions {
}
tunnel-services {
devices device-names;
primary primary-device-name;
}
vpls-id vpls-id;
}


protocols]

hierarchy.
NOTE: You cannot configure a routing protocol (OSPF, RIP, IS-IS or BGP)
inside a VPLS routing instance (instance-type vpls). The Junos CLI disallows
this configuration.
NOTE: Starting in Junos OS Release 16.1, you can use the import-labeled-routes
statement to specify one or more nondefault routing instances where you
want MPLS pseudowire labeled routes to be leaked from the mpls.0 path
routing table in the master routing instance.
The configuration for the VPLS routing instance statements is explained in the following
sections:
• Configuring BGP Signaling for VPLS on page 1240

• Configuring LDP Signaling for VPLS on page 1246
• Configuring VPLS Routing Instance and VPLS Interface Connectivity on page 1249
• Configuring the VPLS Encapsulation Type on page 1249
• Configuring the MPLS Routing Table to Leak Routes a Nondefault Routing
Instance on page 1250
• Configuring the VPLS MAC Table Timeout Interval on page 1251
• Configuring the Size of the VPLS MAC Address Table on page 1251
• Limiting the Number of MAC Addresses Learned from an Interface on page 1252
• Removing Addresses from the MAC Address Database on page 1253
Configuring BGP Signaling for VPLS

You can configure BGP signaling for the VPLS routing instance. BGP is used to signal the
pseudowires linking each of the PE routers participating in the VPLS routing instance.
The pseudowires carry VPLS traffic across the service provider's network between the
VPLS sites.

NOTE: You cannot configure both BGP signaling and LDP signaling for the
same VPLS routing instance. If you attempt to configure the statements that
enable BGP signaling for the VPLS routing instance (the site, site-identifier,
and site-range statements) and the statements that enable LDP signaling
for the same instance (the neighbor and vpls-id statements), the commit
operation fails.
Configure BGP signaling for the VPLS routing instance by completing the steps in the
following sections:
• Configuring the VPLS Site Name and Site Identifier on page 1241
• Configuring Automatic Site Identifiers for VPLS on page 1242
• Configuring the Site Range on page 1243
• Configuring the VPLS Site Interfaces on page 1245
• Configuring the VPLS Site Preference on page 1245
Configuring the VPLS Site Name and Site Identifier
When you configure BGP signaling for the VPLS routing instance, on each PE router you
must configure each VPLS site that has a connection to the PE router. All the Layer 2
circuits provisioned for a VPLS site are listed as the set of logical interfaces (using the
interface statement) within the site statement.
You must configure a site name and site identifier for each VPLS site.
To configure the site name and the site identifier, include the site and the site-identifier
statements:
site site-name {
}
site-identifier identifier;
}
The numerical identifier can be any number from 1 through 65,534 that uniquely identifies
the local VPLS site.
• [edit routing-instances routing-instance-name protocols vpls]

protocols vpls]

Configuring Automatic Site Identifiers for VPLS
When you enable automatic site identifiers, the Junos OS automatically assigns site
identifiers to VPLS sites. To configure automatic site identifiers for a VPLS routing instance,
include the automatic-site-id statement:
automatic-site-id {
collision-detect-time seconds;
new-site-wait-time seconds;
reclaim-wait-time minimum seconds maximum seconds;
startup-wait-time seconds;
}
• [edit routing-instances routing-instance-name protocols vpls site site-name]

protocols vpls site site-name]
NOTE: ACX Series routers do not support the [edit logical-systems] hierarchy.
The automatic-site-id statement includes a number of options that control different

delays in network layer reachability information (NLRI) advertisements. All of these
options are configured with default values. See the statement summary for the
automatic-site-id statement for more information.
The automatic-site-id statement includes the following options:
• collision-detect-time—The time in seconds to wait after a claim advertisement is sent

to the other routers in a VPLS instance before a PE router can begin using a site identifier.
If the PE router receives a competing claim advertisement for the same site identifier
during this time period, it initiates the collision resolution procedure for site identifiers.
• new-site-wait-time—The time in seconds to wait to receive VPLS information for a

newly configured routing instance or a new site. This time interval is also applied
whenever the automatic site identifier feature is activated on a VPLS routing instance
other than at startup. Effectively, this timer indicates how long to wait before an attempt
is made to allocate a site identifier. This timer is also triggered whenever a VPLS routing
instance is enabled.
• reclaim-wait-time—The time to wait before attempting to claim a site identifier after

a collision. A collision occurs whenever an attempt is made to claim a site identifier by
two separate VPLS sites.
• startup-wait-time—The time in seconds to wait at startup to receive all the VPLS

information for the route targets configured on the other PE routers included in the
VPLS routing instance.

Configuring the Site Range
When you enable BGP signaling for each VPLS routing instance, you can optionally
configure the site range. The site range specifies an upper limit on the maximum site
identifier that can be accepted to allow a pseudowire to be brought up. You must specify
a value from 1 through 65,534. The default value is 65,534. We recommend using the
default. Pseudowires cannot be established to sites with site identifiers greater than the
configured site range. If you issue the show vpls connections command, such sites are
displayed as OR (out of range).
To configure the site range, include the site-range statement:
site-range number;

protocols vpls]
There are networks that require that the site range be configured using a value smaller
than the local site identifier, for example, a hub-and-spoke VPLS with multihomed sites.
For this type of network, you need to allow pseudowires to be established between the
spoke routers and the hub router. However, you also need to prevent pseudowires from
being established between spoke routers directly. Due to the multihoming requirement
of spoke sites, Layer 2 VPN NRLIs need to be accepted from other spoke routers (at least
from spokes with the same site identifier as the locally configured sites) to determine
the status of local spoke routers (active or not active) based on the local preference
included in the NRLIs received from the other spoke routers.
This type of VPLS network can be implemented by, for example, numbering hub sites
with identifiers 1 through 8 and spoke sites with identifiers 9 and larger. You can then
configure a site range of 8 on each of the spoke sites. Although the spoke sites accept
NRLIs and install them in the Layer 2 VPN routing tables (allowing the multihomed sites
to determine the status of the local site), the spoke sites cannot establish pseudowires
directly to the other spoke sites due to the configured site range.
The following configurations illustrate this concept. The configurations are for the VPLS
routing instances on three routers, two spoke routers and one hub router:
Router 1—spoke:
routing-instance hub-and-spoke {
no-local-switching;
protocols {
vpls {
site-range 8;
no-tunnel-services;

site spoke-9 {
site-identifier 9 {
multi-homing;
site-preference primary;
}
}
site spoke-10 {
site-identifier 10 {
multi-homing;
site-preference backup;
}
}
}
}
}
Router 2—spoke:
no-local-switching;
protocols {
vpls {
site-range 8;
no-tunnel-services;
site spoke-9 {
site-identifier 9 {
multi-homing;
site-preference backup;
}
}
site spoke-10 {
site-identifier 10 {
multi-homing;
site-preference primary;
}
}
}
}
}
Hub—router 3:
no-local-switching;
protocols {
vpls {
no-tunnel-services;
site hub {
site-identifier 1;
}
}
}
}

Configuring the VPLS Site Interfaces
You must configure an interface for each of the pseudowires you specify for the VPLS
site.
To configure an interface for the VPLS site, include the interface statement:
}

protocols vpls]
You can also configure a limit on the number of MAC addresses that can be learned from
the specified interface. For more information, see “Limiting the Number of MAC Addresses
Learned from an Interface” on page 1252.
Configuring the VPLS Site Preference
You can specify the local preference value advertised for a particular VPLS site. The site
preference value is specified using the site-preference statement configured at the [edit
routing-instances routing-instance-name protocols vpls site site-name] hierarchy level. By
configuring the site-preference statement, a value configured for the local-preference
statement at the [edit protocols bgp] hierarchy level is ignored by the VPLS routing
instance. However, you can change the site preference value for VPLS routes exported
to other routers by configuring an export policy. When a PE router receives multiple
advertisements with the same VPLS edge (VE) device identifier, the advertisement with
the highest local preference value is preferred.
To configure the VPLS site preference, include the site-preference statement:
site-preference preference-value {
backup;
primary;
}
You can also specify either the backup option or the primary option for the site-preference
statement. The backup option specifies the preference value as 1, the lowest possible
value, ensuring that the VPLS site is the least likely to be selected. The primary option
specifies the preference value as 65,535, the highest possible value, ensuring that the
VPLS site is the most likely to be selected.
For a list of hierarchy levels at which you can include the site-preference statement, see
the statement summary section for this statement.

Configuring LDP Signaling for VPLS

You can configure LDP as the signaling protocol for a VPLS routing instance. This
functionality is described in RFC 4762, Virtual Private LAN Service (VPLS) Using Label
Distribution Protocol (LDP) Signaling.
The Junos OS software does not support all of RFC 4762. When enabling LDP signaling
for a VPLS routing instance, network engineers should be aware that only the following
values are supported:
• FEC—128 or 129
• Control bit—0
• Ethernet pseudowire type—0x0005
• Ethernet tagged mode pseudowire type—0x0004
LDP signaled VPLS supports the Virtual Circuit Connectivity Verification (VCCV) Type
Length Value (TLV) for pseudowire label mapping, label database display, and LDP
trace. When you enable LDP signaling for a pseudowire, LDP advertises the VCCV
capabilities to the neighboring routers. VCCV provides a control channel for a pseudowire
and includes both operations and management functions (for example, connectivity
verification). This control channel is established between the pseudowire's ingress and
egress devices. Once established, connectivity verification messages can be sent over
the VCCV control channel.
The Junos OS software supports the following VCCV capabilities for LDP signaled VPLS
(defined in RFC 5085 Section 8.1):
• VCCV connectivity check types:
• Router Alert Label
• MPLS pseudowire label with TTL=1
• VCCV connectivity verification type:
• LSP ping
If the peer device also advertises VCCV parameters during pseudowire setup, the Junos
OS software selects the set of common advertised parameters to use as the method for
performing VCCV OAM on the pseudowire.
The locally advertised and peer advertised VCCV parameters can be viewed using the
show ldp database command as show here:
user@host> show ldp database l2circuit extensive

Input label database, 10.255.245.198:0--10.255.245.194:0
Label Prefix
299872 L2CKT CtrlWord PPP VC 100
MTU: 4470
VCCV Control Channel types:
MPLS router alert label
MPLS PW label with TTL=1

VCCV Control Verification types:

LSP ping
Label Prefix
State: Active
Age: 19:23:08
Be aware of the following behavior with regard to TLVs when configuring LDP-signaled
VPLS in a network with equipment from other vendors:
• When a Juniper Network’s device receives a TLV with an empty address, LDP accepts
the TLV.
• When a MAC address is withdrawn, LDP specifies a zero address (0.0.0.0) for the
AddressList.
To enable LDP signaling for the set of PE routers participating in the same VPLS routing
instance, you need to use the vpls-id statement configured at the [edit routing-instances
routing-instance-name protocols vpls] hierarchy level to configure the same VPLS identifier
on each of the PE routers. The VPLS identifier must be globally unique. When each VPLS
routing instance (domain) has a unique VPLS identifier, it is possible to configure multiple
VPLS routing instances between a given pair of PE routers.
LDP signaling requires that you configure a full-mesh LDP session between the PE routers
in the same VPLS routing instance. Neighboring PE routers are statically configured.
Tunnels are created between the neighboring PE routers to aggregate traffic from one
PE router to another. Pseudowires are then signaled to demultiplex traffic between VPLS
routing instances. These PE routers exchange the pseudowire label, the MPLS label that
acts as the VPLS pseudowire demultiplexer field, by using LDP forwarding equivalence
classes (FECs). Tunnels based on both MPLS and generic routing encapsulation (GRE)
are supported.
NOTE: You cannot configure both BGP signaling and LDP signaling for the
same VPLS routing instance. If you attempt to configure the statements that
enable BGP signaling for the VPLS routing instance (the site, site-identifier,
and site-range statements), and the statements that enable LDP signaling
for the same instance, neighbor and vpls-id, the commit operation fails.
To enable LDP signaling for the VPLS routing instance, complete the steps in the following
sections:
• Configuring LDP Signaling for the VPLS Routing Instance on page 1247
• Configuring LDP Signaling on the Router on page 1248
Configuring LDP Signaling for the VPLS Routing Instance

To configure the VPLS routing instance to use LDP signaling, you must configure the
same VPLS identifier on each PE router participating in the instance. Specify the VPLS
identifier with the vpls-id statement:
vpls-id vpls-id;


protocols vpls]
To configure the VPLS routing instance to use LDP signaling, you also must include the
neighbor statement to specify each of the neighboring PE routers that are a part of this
VPLS domain:
neighbor neighbor-id;

protocols vpls]
Configuring LDP Signaling on the Router

To enable LDP signaling, you need to configure LDP on each PE router participating in
the VPLS routing instance. A minimal configuration is to enable LDP on the loopback
interface, which includes the router identifier (router-id), on the PE router using the
interface statement:
• [edit protocols ldp]
• [edit logical-systems logical-system-name protocols ldp]
You can enable LDP on all the interfaces on the router using the all option for the interfaces
statement. For more information about how to configure LDP, see the MPLS Applications
Feature Guide.

Configuring VPLS Routing Instance and VPLS Interface Connectivity

You can configure the VPLS routing instance to take down or maintain its VPLS
connections depending on the status of the interfaces configured for the VPLS routing
instance. By default, the VPLS connection is taken down whenever a customer-facing
interface configured for the VPLS routing instance fails. This behavior can be explicitly
configured by specifying the ce option for the connectivity-type statement:
connectivity-type ce;
You can alternatively specify that the VPLS connection remain up so long as an Integrated
Routing and Bridging (IRB) interface is configured for the VPLS routing instance by
specifying the irb option for the connectivity-type statement:
connectivity-type irb;
To ensure that the VPLS connection remain up until explicitly taken down, specify the
permanent option for the connectivity-type statement:
connectivity-type permanent;
This option is reserved for use in configuring Layer 2 Wholesale subscriber networks. See
the Broadband Subscriber Management Solutions Guide for details about configuring a
Layer 2 Wholesale network.

protocols vpls]
ACX Series routers do not support irb interface in VPLS instance, therefore
connectivity-type irb for VPLS is not supported.
Configuring the VPLS Encapsulation Type

You can specify a VPLS encapsulation type for the pseudowires established between
VPLS neighbors. The encapsulation type is carried in the LDP-signaling messages
exchanged between VPLS neighbors when pseudowires are created. You might need to
alter the encapsulation type depending on what other vendors’ equipment is deployed
within your network.
VPLS effectively provides a bridge between Ethernet networks. As a consequence, only

two encapsulation types are available:
• ethernet—Ethernet
• ethernet-vlan—Ethernet virtual LAN (VLAN)

If you do not specify an encapsulation type for the VPLS routing instance or the VPLS
neighbor, ethernet is used.
To specify an encapsulation type for the VPLS routing instance, include the
encapsulation-type statement:
encapsulation-type (ethernet | ethernet-vlan);

protocols vpls]
You can also specify an encapsulation type for a specific VPLS neighbor by including the
encapsulation-type statement at the following hierarchy levels:
• [edit routing-instances routing-instance-name protocols vpls neighbor address]

protocols vpls neighbor address]
Configuring the MPLS Routing Table to Leak Routes a Nondefault Routing Instance
Starting in Junos OS Release 16.1, you can specify one or more nondefault routing instances
where you want MPLS routes to be leaked from the mpls.0 path routing table in the
master routing instance. This capability is useful in an L2VPN/VPLS configuration when
the remote PE router is learned from the IGP in a nondefault routing instance, because
L2VPN/VPLS installs ingress-labeled routes only in the master mpls.0 table.
By default, routes in the mpls.0 routing table in the master routing instance are not leaked
to the corresponding routing tables in nondefault routing instances. When L2VPN/VPLS
traffic is received on the core-facing interface in a nondefault routing instance, the router
performs a lookup in the table that corresponds to that interface,
routing-instance-name.mpls.0. Because the routes are not leaked by default, then no
routes are found in the routing-instance-name.mpls.0 routing table and all the incoming
traffic is dropped.
To leak MPLS routes to a nondefault routing instance, include the import-labeled-routes

statement and specify one or more routing instances where the routes need to be leaked:
import-labeled-routes [ routing-instance-name ];

protocols vpls]

Configuring the VPLS MAC Table Timeout Interval

You can modify the timeout interval for the VPLS table. We recommend you that configure
longer values for small, stable VPLS networks and shorter values for large, dynamic VPLS
networks. If the VPLS table does not receive any updates during the timeout interval, the
router waits one additional interval before automatically clearing the MAC address entries
from the VPLS table.
To modify the timeout interval for the VPLS table, include the mac-table-aging-time
statement:
mac-table-aging-time seconds;

protocols vpls]
NOTE: The mac-table-aging-time statement is not available on ACX Series

and MX Series routers.
Configuring the Size of the VPLS MAC Address Table

You can modify the size of the VPLS media access control (MAC) address table. The
default table size is 512 MAC addresses, the minimum is 16 addresses, and the maximum
is 65,536 addresses.
NOTE: T4000 routers with Type 5 FPCs support up to 262,143 MAC addresses
per VPLS routing instance. To enable the improved VPLS MAC address
learning limit (that is, 262,143 MAC addresses), you must Include the
enhanced-mode statement at the [edit chassis network-services] hierarchy
level, reboot the router, and then modify the size of the VPLS MAC address
table.
If the MAC table limit is reached, new MAC addresses can no longer be added to the
table. Eventually the oldest MAC addresses are removed from the MAC address table
automatically. This frees space in the table, allowing new entries to be added. However,
as long as the table is full, new MAC addresses are dropped.
To change the VPLS MAC table size for each VPLS or VPN routing instance, include the
mac-table-size statement:
mac-table-size size;


protocols vpls]
When you include the mac-table-size statement, the affected interfaces include all
interfaces within the VPLS routing instance, including the local interfaces, the LSI
interfaces, and the VT interfaces.
NOTE: ACX Series routers do no support mac-table-size statement for VPLS.
Limiting the Number of MAC Addresses Learned from an Interface

You can configure a limit on the number of MAC addresses learned by a VPLS routing
instance using the mac-table-size statement. If the MAC table limit is reached, new MAC
addresses can no longer be added to the table. Eventually the oldest MAC addresses are
removed from the MAC address table automatically. This frees space in the table, allowing
new entries to be added. However, as long as the table is full, new MAC addresses are
dropped.
Because this limit applies to each VPLS routing instance, the MAC addresses of a single
interface can consume all the available space in the table, preventing the routing instance
from acquiring addresses from other interfaces.
You can limit the number of MAC addresses learned from each interface configured for
a VPLS routing instance. To do so, include the interface-mac-limit statement:
NOTE: ACX Series routers do not support interface-mac-limit limit for VPLS.

protocols vpls]
The interface-mac-limit statement affects the local interfaces only (the interfaces facing
CE devices).
Configuring the interface-mac-limit statement at the [edit routing-instances

routing-instance-name protocols vpls] hierarchy level causes the same limit to be applied
to all of the interfaces configured for that specific routing instance.

NOTE: Starting in Junos OS Release 12.3R4, if you do not configure the

parameter to limit the number of MAC addresses to be learned by a VPLS
instance, the default value is not effective. Instead, if you do not include the
interface-mac-limit option at the [edit logical-systems logical-system-name
routing-instances routing-instance-name protocols vpls site site-name interfaces
interface-name], hierarchy level, this setting is not present in the configuration
with the default value of 1024 addresses. If you upgrade a router running a
Junos OS release earlier than Release 12.3R4 to Release 12.3R4 or later, you
must configure the interface-mac-limit option with a valid value for it to be
saved in the configuration.
You can also limit the number of MAC addresses learned by a specific interface configured
for a VPLS routing instance. This gives you the ability to limit particular interfaces that
you expect might generate a lot of MAC addresses.
To limit the number of MAC addresses learned by a specific interface, include the
interface-mac-limit statement at the following hierarchy levels:
• [edit routing-instances routing-instance-name protocols vpls site site-name interfaces

interface-name]

protocols vpls site site-name interfaces interface-name]
The MAC limit configured for an individual interface at this hierarchy level overrides any
value configured at the [edit routing-instances routing-instance-name protocols vpls]
hierarchy level. Also, the MAC limit configured using the mac-table-size statement can
override the limit configured using the interface-mac-limit statement.
The MAC address limit applies to customer-facing interfaces only.
Removing Addresses from the MAC Address Database

You can enable MAC flush processing for the VPLS routing instance or for the mesh group
under a VPLS routing instance. MAC flush processing removes MAC addresses from the
MAC address database that have been learned dynamically. With the dynamically learned
MAC addresses removed, MAC address convergence requires less time to complete.
You can clear dynamically learned MAC addresses from the MAC address database by
including the mac-flush statement:
mac-flush [ explicit-mac-flush-message-options ];

To clear dynamically learned MAC addresses globally across all devices participating in
the routing instance, you can include the statement at the following hierarchy levels:

protocols vpls]
To clear the MAC addresses on the routers in a specific mesh group, you can include the
statement at the following hierarchy levels:

protocols vpls mesh-group mesh-group-name]
• [edit routing-instances routing-instance-name protocols vpls

mesh-group mesh-group-name]
NOTE: On ACX Series routers, the mesh-group statement is supported only

on ACX5000 line of routers. ACX5000 line of routers can support up to 8
user-defined mesh groups per VPLS routing instance.
For certain cases where MAC flush processing is not initiated by default, you can also
specify explicit-mac-flush-message-options to additionally configure the router to send
explicit MAC flush messages under specific conditions. For a list of the explicit MAC flush
message options you can include with this statement, see the summary section for this
statement.
16.1 Starting in Junos OS Release 16.1, you can specify one or more nondefault routing
instances where you want MPLS routes to be leaked from the mpls.0 path
routing table in the master routing instance.
12.3R4 Starting in Junos OS Release 12.3R4, if you do not configure the parameter to
limit the number of MAC addresses to be learned by a VPLS instance, the default
value is not effective.
Related • Configuring Improved VPLS MAC Address Learning on T4000 Routers with Type 5 FPCs
Documentation
• enhanced-mode
• show ldp database

Configuring Interfaces for VPLS Routing in ACX Series
On each PE router and for each VPLS routing instance, specify which interfaces are
intended for the VPLS traffic traveling between PE and CE routers. To specify the interface
for VPLS traffic, include the interface statement in the routing instance configuration:
You must also define each interface by including the following statements:
vlan-tagging;
encapsulation encapsulation-type;
family vpls;
vlan-id vlan-id-number;
}
The following sections provide enough information to enable you to configure interfaces
for VPLS routing. For detailed information about configuring interfaces and the statements
at the [edit interfaces] hierarchy level, see the Junos OS Network Interfaces Library for
Routing Devices.
• Configuring the VPLS Interface Name on page 1256

• Configuring VPLS Interface Encapsulation on page 1256
• Enabling Flexible VLAN Tagging on page 1258
• Configuring VLAN IDs for Logical Interfaces on page 1259
• Sample Scenario of Hierarchical Virtual Private LAN Service on Logical Tunnel
• Configuring Aggregated Ethernet Interfaces for VPLS on page 1261

Configuring the VPLS Interface Name

Specify both the physical and logical portions of the interface name, in the following
format:
physical.logical
For example, in ge-1/2/1.2, ge-1/2/1 is the physical portion of the interface name and 2 is
the logical portion. If you do not specify the logical portion of the interface name, 0 is set
by default.
A logical interface can be associated with only one routing instance.
If you enable a routing protocol on all instances by specifying interfaces all when
configuring the master instance of the protocol at the [edit protocols] hierarchy level,
and you configure a specific interface for VPLS routing at the [edit routing-instances
routing-instance-name] hierarchy level, the latter interface statement takes precedence
and the interface is used exclusively for VPLS.
If you explicitly configure the same interface name at both the [edit protocols] and [edit
routing-instances routing-instance-name] hierarchy levels and then attempt to commit
the configuration, the commit operation fails.
Configuring VPLS Interface Encapsulation

You need to specify an encapsulation type for each PE-router-to-CE-router interface
configured for VPLS. This section describes the encapsulation statement configuration
options available for VPLS.
To configure the encapsulation type on the physical interface, include the encapsulation
statement:
encapsulation (ethernet-vpls | ether-vpls-over-atm-llc |extended-vlan-vpls | vlan-vpls);
NOTE: ACX Series routers do not support the ether-vpls-over-atm-llc and

extended-vlan-vpls options for encapsulation.
You can include the encapsulation statement for physical interfaces at the following
hierarchy levels:

You can configure the following physical interface encapsulations for VPLS routing
instances:
• ethernet-vpls—Use Ethernet VPLS encapsulation on Ethernet interfaces that have

VLAN 802.1Q tagging and VPLS enabled. The PE router expects to receive Ethernet
frames with VLAN tags that are not service-delimiting. The Ethernet frames are not
meaningful to the PE router and cannot be used by the service provider to separate
customer traffic.
On M Series routers (except the M320 router), the 4-port Fast Ethernet TX PIC and
the 1-port, 2-port, and 4-port, 4-slot Gigabit Ethernet PICs can use the Ethernet VPLS
encapsulation type.
• ether-vpls-over-atm-llc—For ATM intelligent queuing (IQ) interfaces only, use the

Ethernet virtual private LAN service (VPLS) over ATM LLC encapsulation to bridge
Ethernet interfaces and ATM interfaces over a VPLS routing instance (as described in
RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5). Packets from
the ATM interfaces are converted to standard ENET2/802.3 encapsulated Ethernet
frames with the frame check sequence (FCS) field removed.
• extended-vlan-vpls—Use extended virtual LAN (VLAN) VPLS encapsulation on Ethernet

interfaces that have VLAN 802.1Q tagging and VPLS enabled and that must accept
packets carrying TPIDs 0x8100, 0x9100, and 0x9901. On M Series routers (except the
M320 router), the 4-port Fast Ethernet TX PIC and the 1-port, 2-port, and 4-port, 4-slot
Gigabit Ethernet PICs can use the Ethernet VPLS encapsulation type.
NOTE: The built-in Gigabit Ethernet PIC on an M7i router does not support
extended VLAN VPLS encapsulation.
• vlan-vpls—Use VLAN VPLS encapsulation on Ethernet interfaces with VLAN 802.1Q

tagging and VPLS enabled. The PE router expects to receive Ethernet frames with
VLAN tags that are service-delimiting. These VLAN tags can be used by the service
provider to separate customer traffic. For example, LAN traffic from different customers
can flow through the same service provider switch, which can then apply VLAN tags
to distinguish one customer’s traffic from the others. The traffic can then be forwarded
to the PE router.
Interfaces with VLAN VPLS encapsulation accept packets carrying standard TPID
values only. On M Series routers (except the M320 router), the 4-port Fast Ethernet
TX PIC and the 1-port, 2-port, and 4-port, 4-slot Gigabit Ethernet PICs can use the
Ethernet VPLS encapsulation type.
To configure the encapsulation type for logical interfaces, include the encapsulation
statement:
encapsulation (ether-vpls-over-atm-llc | vlan-vpls);
You can include the encapsulation statement for logical interfaces at the following
hierarchy levels:
• [edit interfaces interface-name unit number]

• [edit logical-systems logical-system-name interfaces interface-name unit number]
You can configure the following logical interface encapsulations for VPLS routing
instances:
• ether-vpls-over-atm-llc—Use Ethernet VPLS over Asynchronous Transfer Mode (ATM)

logical link control (LLC) encapsulation to bridge Ethernet interfaces and ATM interfaces
over a VPLS routing instance (as described in RFC 2684, Multiprotocol Encapsulation
over ATM Adaptation Layer 5). Packets from the ATM interfaces are converted to
standard ENET2/802.3-encapsulated Ethernet frames with the frame check sequence
(FCS) field removed. This encapsulation type is supported on ATM intelligent queuing
(IQ) interfaces only.
• vlan-vpls—Use VLAN VPLS encapsulation on Ethernet interfaces with VLAN 802.1Q

tagging and VPLS enabled. The PE router expects to receive Ethernet frames with
VLAN tags that are service-delimiting. These VLAN tags can be used by the service
provider to separate customer traffic. For example, LAN traffic from different customers
can flow through the same service provider switch, which can then apply VLAN tags
to distinguish one customer's traffic from the others. The traffic can then be forwarded
to the PE router.
Interfaces with VLAN VPLS encapsulation accept packets carrying standard TPID
values only. On M Series routers (except the M320 router), the 4-port Fast Ethernet
TX PIC and the 1-port, 2-port, and 4-port, 4-slot Gigabit Ethernet PICs can use the
Ethernet VPLS encapsulation type.
NOTE: Label-switched interfaces (LSIs) do not support VLAN VPLS

encapsulation. Therefore, you can only use VLAN VPLS encapsulation on
a PE-router-to-CE-router interface and not a core-facing interface.
When you configure the physical interface encapsulation as vlan-vpls, you also need to
configure the same interface encapsulation for the logical interface. You need to configure
the vlan-vpls encapsulation on the logical interface because the vlan-vpls encapsulation
allows you to configure a mixed mode, where some of the logical interfaces use regular
Ethernet encapsulation (the default for logical interfaces) and some use vlan-vpls.
NOTE: Starting with Junos OS release 13.3, a commit error occurs when you
configure vlan-vpls encapsulation on a physical interface and configure family
inet on one of the logical units. Previously, it was possible to commit this
invalid configuration.
Enabling Flexible VLAN Tagging

Junos OS supports receiving and forwarding routed Ethernet frames with 802.1Q virtual
local area network (VLAN) tags and running the Virtual Router Redundancy Protocol
(VRRP) over 802.1Q-tagged interfaces. For VPLS to function properly, configure the
router to receive and forward frames with 802.1Q VLAN tags by including the vlan-tagging
statement at the [edit interfaces interface-name] hierarchy level:

Gigabit Ethernet interfaces can be partitioned. You can assign up to 4095 different logical
interfaces, one for each VLAN, but you are limited to a maximum of 1024 VLANs on any
single Gigabit Ethernet or 10-Gigabit Ethernet port.
Configuring VLAN IDs for Logical Interfaces

You can bind a VLAN identifier to a logical interface by including the vlan-id statement:
vlan-id number;

You can also configure a logical interface to forward packets and learn MAC addresses
within each VPLS routing instance configured with a VLAN ID that matches a VLAN ID
specified in a list using the vlan-id-list statement. VLAN IDs can be entered individually
using a space to separate each ID, entered as an inclusive list separating the starting
VLAN ID and ending VLAN ID with a hyphen, or a combination of both.
For example, to configure the VLAN IDs 20 and 45 and the range of VLAN IDs between
30 and 40, issue the following command from the CLI:
set interfaces ge-1/0/1 unit 1 vlan-id-list [20 30-40 45];
To configure a list of VLAN IDs for a logical interface, include the vlan-id-list statement:
vlan-id-list list-of-vlan-ids;

For more information about how to configure VLANs, see the Junos OS Network Interfaces
Library for Routing Devices. For detailed information about how VLAN identifiers in a VPLS
routing instance are processed and translated, see the MX Series Layer 2 Configuration
Guide.
Sample Scenario of Hierarchical Virtual Private LAN Service on Logical Tunnel Interface
This section describes how to configure the hierarchical virtual private LAN service
(H-VPLS) on ACX5048 and ACX5096 routers. Junos OS for ACX5048 and ACX5096
routers supports configuring H-VPLS using the logical tunnel interface encapsulation.

For example, you have three provider edge devices (PE1, PE2 and PE3). PE2 device
connects both PE1 and PE3 devices. The pseudowire connecting PE1 and PE2 devices
are encapsulated with circuit cross-connect (CCC). In this case, PE1 device acts as a
spoke and PE2 as a hub. The pseudowire connecting PE2 and PE3 devices are
encapsulated with VPLS. You need to encapsulate CCC and VPLS pseudowires using
the logical tunnel interface on the PE2 device.
The following steps describe how to encapsulate CCC and VPLS pseudowires using the
logical tunnel interface on the PE2 device:
1. Create a logical tunnel interface on the PE2 device by using the set chassis fpc fpc-slot
pic pic-slot tunnel-services port port-number CLI command. The port-number can be
any port on the chassis which is not used for regular traffic forwarding. For example,
[edit]
user@host# set chassis fpc 0 pic 0 tunnel-services port 65
2. Encapsulate the CCC and VPLS pseudowires using the logical tunnel interface
(lt-0/0/65) created on the PE2 device. Use the Ethernet CCC (ethernet-ccc) and
Ethernet VPLS (ethernet-vpls) encapsulation types at the [edit interfaces
interface-name unit logical-unit-number] hierarchy level as shown in the example:
Device PE2
[edit]
user@host# set interfaces lt-0/0/65 unit 0 encapsulation ethernet-ccc;
user@host# set interfaces lt-0/0/65 unit 0 encapsulation peer-unit 1;
user@host# set interfaces lt-0/0/65 unit 1 encapsulation ethernet-vpls;
user@host# set interfaces lt-0/0/65 unit 1 encapsulation peer-unit 0;
3. Verify the configuration by entering the show command at the logical tunnel interface
level. The output should display as follows:
[edit interfaces lt-0/0/65]
user@host# show
unit 0 {
peer-unit 1;
}
unit 1 {
encapsulation ethernet-vpls;
peer-unit 0;
}
Based on this configuration, you can see that:
• The CCC pseudowire on PE2 device originates from lt-0/0/65.0
• The VPLS pseudowire on PE2 device originates from lt-0/0/65.1
• The CCC pseudowire on PE1 device originates from a regular interface
• The VPLS pseudowire on PE3 device originates from a regular interface

Configuring Aggregated Ethernet Interfaces for VPLS

You can configure aggregated Ethernet interfaces between CE devices and PE routers
for VPLS routing instances. Traffic is load-balanced across all of the links in the aggregated
interface. If one or more links in the aggregated interface fails, the traffic is switched to
the remaining links.
For more information about how aggregated Ethernet interfaces function in the context
of VPLS, see VPLS and Aggregated Ethernet Interfaces.
To configure aggregated Ethernet interfaces for VPLS, configure the interface for the
VPLS routing instance as follows:
interfaces aex {
vlan-tagging;
encapsulation encapsulation-type;
vlan-id number;
}
}
You can configure the following physical link-layer encapsulation types for the VPLS
aggregated Ethernet interface:
• ethernet-vpls
• extended-vlan-vpls
• flexible-ethernet-services
• vlan-vpls
NOTE: ACX Series routers do not support the extended-vlan-vpls and vlan-vpls
encapsulation types.
For the interface configuration statement, in aex, the x represents the interface instance
number to complete the link association; x can be from 0 through 127, for a total of
128 aggregated interfaces.
For more information about how to configure aggregated Ethernet interfaces, see the
Ethernet Interfaces Feature Guide for Routing Devices.
The aggregated Ethernet interface must also be configured for the VPLS routing instance
as shown in the following example:
[edit]
routing-instances {
green {
instance-type vpls;
interface ae0.0;
protocols {

vpls {
site-range 10;
site green3 {
site-identifier 3;
}
}
}
}
}
Interface ae0.0 represents the aggregated Ethernet interface in the routing instance
configuration. The VPLS routing instance configuration is otherwise standard.
Configuring VLAN Identifiers for VLANs and VPLS Routing Instances in ACX Series
You can configure VLAN identifiers for a VLAN or a VPLS routing instance in the following
ways:
• By using either the vlan-id statement or the vlan-tags statement to configure a

normalizing VLAN identifier. This topic describes how normalizing VLAN identifiers are
processed and translated in a VLAN or a VPLS routing instance.
• By using the input-vlan-map and the output-vlan-map statements at the [edit interfaces
interface-name unit logic-unit-number] or [edit logical-systems logical-system-name
interfaces interface-name unit logic-unit-number] hierarchy level to configure VLAN
mapping.
NOTE: In ACX5048 and ACX5096 routers, VLAN map operation is supported

only if the connectivity-type is ce mode and not with permanent mode.
The vlan-id and vlan-tags statements are used to specify the normalizing VLAN identifier
under the VLAN or VPLS routing instance. The normalizing VLAN identifier can translate
or normalize the VLAN tags of packets received into a learn VLAN identifier.
NOTE: You cannot configure VLAN mapping using the input-vlan-map and
output-vlan-map statements if you configure a normalizing VLAN identifier
for a VLAN or VPLS routing instance using the vlan-id or vlan-tags statements.
To configure a VLAN identifier for a VLAN, include either the vlan-id or the vlan-tags
statement at the [edit interfaces interface-name unit logic-unit-number] or [edit
logical-systems logical-system-name interfaces interface-name unit logic-unit-number]
hierarchy level, and then include that logical interface in the VLAN configuration.
For a VPLS routing instance, include either the vlan-id or vlan-tags statement at the [edit
interfaces interface-name unit logic-unit-number] or [edit logical-systems
logical-system-name interfaces interface-name unit logic-unit-number] hierarchy level, and
then include that logical interface in the VPLS routing instance configuration.

NOTE: For a single VLAN or VPLS routing instance, you can include either
the vlan-id or the vlan-tags statement, but not both. If you do not configure
a vlan-id or vlan-tags for the VLAN or the VPLS routing instance, the Layer 2
packets received are forwarded to the outbound Layer 2 interface without
having the VLAN tag modified unless an output-vlan-map is configured on
the Layer 2 interface. This results in a frame being forwarded to a Layer 2
interface with a VLAN tag that is different from what is configured for the
Layer 2 interface. Note that a frame received from the Layer 2 interface is still
required to match the VLAN tag(s) specified in the interface configuration.
The invalid configuration may cause a Layer 2 loop to occur. In ACX5048 and
ACX5096 routers, if the interface VLAN is configured as vlan-id-list, it is
mandatory to normalize the VPLS routing instance. vlan-id all is not supported
in ACX5048 and ACX5096 routers.
The VLAN tags associated with the inbound logical interface are compared with the
normalizing VLAN identifier. If the tags are different, they are rewritten as described in
Table 48 on page 758. The source MAC address of a received packet is learned based on
the normalizing VLAN identifier.
If the VLAN tags associated with the outbound logical interface and the normalizing
VLAN identifier are different, the normalizing VLAN identifier is rewritten to match the
VLAN tags of the outbound logical interface, as described in Table 49 on page 758.
The following steps outline the process for bridging a packet received over a Layer 2
logical interface when you specify a normalizing VLAN identifier using either the vlan-id
number or vlan-tags statement for a VLAN or a VPLS routing instance:
1. When a packet is received on a physical port, it is accepted only if the VLAN identifier
of the packet matches the VLAN identifier of one of the logical interfaces configured
on that port.
2. The VLAN tags of the received packet are then compared with the normalizing VLAN
identifier. If the VLAN tags of the packet are different from the normalizing VLAN
identifier, the VLAN tags are rewritten as described in Table 48 on page 758.
3. If the source MAC address of the received packet is not present in the source MAC
table, it is learned based on the normalizing VLAN identifier.
4. The packet is then forwarded toward one or more outbound Layer 2 logical interfaces
based on the destination MAC address. A packet with a known unicast destination
MAC address is forwarded only to one outbound logical interface. For each outbound
Layer 2 logical interface, the normalizing VLAN identifier configured for the VLAN or
VPLS routing instance is compared with the VLAN tags configured on that logical

interface. If the VLAN tags associated with an outbound logical interface do not match
the normalizing VLAN identifier configured for the VLAN or VPLS routing instance, the
VLAN tags are rewritten as described in Table 49 on page 758.
The tables below show how VLAN tags are applied for traffic sent to and from the VLAN,
depending on how the vlan-id and vlan-tags statements are configured for the VLAN and
on how identifiers are configured for the logical interfaces in a VLAN or VPLS routing
instance. Depending on your configuration, the following rewrite operations are performed
on VLAN tags:
• pop—Remove a VLAN tag from the top of the VLAN tag stack.
• pop-pop—Remove both the outer and inner VLAN tags of the frame.
• pop-swap—Remove the outer VLAN tag of the frame and replace the inner VLAN tag
of the frame.
• swap—Replace the VLAN tag of the frame.
• push—Add a new VLAN tag to the top of the VLAN stack.
• push-push—Push two VLAN tags in front of the frame.
• swap-push—Replace the VLAN tag of the frame and add a new VLAN tag to the top
of the VLAN stack.
• swap-swap—Replace both the outer and inner VLAN tags of the frame.
Table 103 on page 1264 shows the supported input and output VLAN map configurations.
Table 103: Supported Input and Output VLAN Map Configurations

Input-map Output-map
Interface
Type Configuration Parameters Configuration Parameters
Untagged push tpid.outer-vlan pop None
push-push tpid.outer-vlan/ inner-vlan pop-pop None
Single swap tpid.outer-vlan swap tpid.outer-vlan

tagged
push tpid.outer-vlan pop None
Dual tagged swap tpid.outer-vlan swap tpid.outer-vlan
pop None push tpid.outer-vlan
swap-swap tpid.outer-vlan/inner-vlan swap-swap tpid.outer-vlan
Table 48 on page 758 shows specific examples of how the VLAN tags for packets sent to
the VLAN are processed and translated, depending on your configuration. “–” means
that the statement is not supported for the specified logical interface VLAN identifier.

“No operation” means that the VLAN tags of the received packet are not translated for
the specified input logical interface.
Table 104: Statement Usage and Input Rewrite Operations for VLAN Identifiers for a VLAN
VLAN Configurations for a VLAN
VLAN Identifier of vlan tags outer 100

Logical Interface vlan-id none vlan-id 200 inner 300
none No operation push 200 push 100, push 300
200 pop 200 No operation swap 200 to 300,

push 100
1000 pop 1000 swap 1000 to 200 swap 1000 to 300,

push 100
vlan-tags outer 2000 pop 2000, pop 300 pop 2000, swap 300 swap 2000 to 100
inner 300 to 200
vlan-tags outer 100 pop 100, pop 400 pop 100, swap 400 swap 400 to 300
inner 400 to 200
Table 49 on page 758 shows specific examples of how the VLAN tags for packets sent
from the VLAN are processed and translated, depending on your configuration. “–” means
that the statement is not supported for the specified logical interface VLAN identifier.
“No operation” means that the VLAN tags of the outbound packet are not translated for
the specified output logical interface.
Table 105: Statement Usage and Output Rewrite Operations for VLAN Identifiers for a VLAN
VLAN Configurations for a VLAN
VLAN Identifier of vlan tags outer 100

Logical Interface vlan-id none vlan-id 200 inner 300
none no operation pop 200 pop 100, pop 300
200 push 200 No operation pop 100, swap 300

to 200
1000 push 1000 swap 200 to 1000 pop 100, swap 300
to 1000
vlan-tags outer 2000 push 2000, push 300 swap 200 to 300, swap 100 to 2000
inner 300 push 2000
vlan-tags outer 100 inner 400 push 100, push 400 swap 200 to 400, swap 300 to 400
push 100

Configuring Static Pseudowires for VPLS
You can configure a VPLS domain using static pseudowires. A VPLS domain consists of
a set of PE routers that act as a single virtual Ethernet bridge for the customer sites
connected to these routers. By configuring static pseudowires for the VPLS domain, you
do not need to configure the LDP or BGP protocols that would normally be used for
signaling. However, if you configure static pseudowires, any changes to the VPLS network
topology have to be managed manually.
Static pseudowires require that you configure a set of in and out labels for each
pseudowire configured for the VPLS domain. You still need to configure a VPLS identifier
and neighbor identifiers for a static VPLS domain. You can configure both static and
dynamic neighbors within the same VPLS routing instance.
To configure a static pseudowire for a VPLS neighbor, include the static statement:
static (Protocols VPLS) {

incoming-label label;
outgoing-label label;
}
You must configure an incoming and outgoing label for the static pseudowire using the
incoming-label and outgoing-label statements. These statements identify the static
pseudowire’s incoming traffic and destination.
To configure a static pseudowire for a VPLS neighbor, include the static statement at
the [edit routing-instances routing-instance-name protocols vpls neighbor address] hierarchy
level.
You can also configure the static statement for a backup neighbor (if you configure the
neighbor as static the backup must also be static) by including it at the [edit
routing-instances routing-instance-name protocols vpls neighbor address backup-neighbor
address] hierarchy level and for a mesh group by including it at the [edit routing-instances
routing-instance-name protocols vpls mesh-group mesh-group-name neighbor address]
hierarchy level.
For a list of hierarchy levels at which you can include the static statement, see the
statement summary section for this statement.
To enable static VPLS on a router, you need to either configure a virtual tunnel interface
(requires the router to have a tunnel services PIC) or you can configure a label switching
interface (LSI). To configure an LSI, include the no-tunnel-services statement at the [edit
protocols vpls static-vpls] hierarchy level. For more information, see “Configuring VPLS
Without a Tunnel Services PIC” on page 1267.

NOTE: Static pseudowires for VPLS using an LSI is supported on MX series

routers and EX Series switches only. For M series and T series routers, a tunnel
services PIC is required.
If you issue a show vpls connections command, static neighbors are displayed with "SN"
next to their addresses in the command output.
Related • Configuring VPLS Without a Tunnel Services PIC on page 1267

Documentation
Configuring VPLS Without a Tunnel Services PIC
VPLS normally uses a dynamic virtual tunnel logical interface on a Tunnel Services PIC
to model traffic from a remote site (a site on a remote PE router that is in a VPLS domain).
All traffic coming from a remote site is treated as coming in over the virtual port
representing this remote site, for the purposes of Ethernet flooding, forwarding, and
learning. An MPLS lookup based on the inner VPN label is done on a PE router. The label
is stripped and the Layer 2 Ethernet frame contained within is forwarded to a Tunnel
Services PIC. The PIC loops back the packet and then a lookup based on Ethernet MAC
addresses is completed. This approach requires that the router have a Tunnel Services
PIC and that the PE router complete two protocol lookups.
You can configure VPLS without a Tunnel Services PIC by configuring the
no-tunnel-services statement. This statement creates a label-switched interface (LSI)
to provide VPLS functionality. An LSI MPLS label is used as the inner label for VPLS. This
label maps to a VPLS routing instance. On the PE router, the LSI label is stripped and
then mapped to a logical LSI interface. The Layer 2 Ethernet frame is then forwarded
using the LSI interface to the correct VPLS routing instance.
By default, VPLS requires a Tunnel Services PIC. To configure VPLS on a router without
a Tunnel Services PIC and create an LSI, include the no-tunnel-services statement:
no-tunnel-services;
For a list of the hierarchy levels at which you can include this statement, see the summary
section for this statement.
To configure a VPLS routing instance on a router without a tunnel services PIC, include
the no-tunnel-services statement at the [edit routing-instances routing-instance-name
protocols vpls] hierarchy level. To configure static VPLS on a router without a tunnel
services PIC, include the no-tunnel-services statement at the [edit protocols vpls
static-vpls] hierarchy level.

When you configure VPLS without a Tunnel Services PIC by including the
no-tunnel-services statement, the following limitations apply:
• An Enhanced FPC is required.
• ATM1 interfaces are not supported.
• Aggregated SONET/SDH interfaces are not supported as core-facing interfaces.
• Channelized interfaces are not supported as core-facing interfaces.
• GRE-encapsulated interfaces are not supported as core-facing interfaces.
Related • Configuring Static Pseudowires for VPLS on page 1266

Documentation
Configuring VPLS Multihoming (FEC 128)
VPLS multihoming allows you to connect a customer site to multiple PE routers to provide
redundant connectivity while preventing the formation of Layer 2 loops in the service
provider’s network. A VPLS site multihomed to two or more PE routers provides redundant
connectivity in the event of a PE router-to-CE device link failure or the failure of a PE
router. For more information about VPLS multihoming, see “VPLS Multihoming Overview”
on page 1237.
NOTE: If you want to enable multihoming for a VPLS routing instance, you
cannot also enable LDP signaling. You can only enable BGP signaling.
The following sections describe how to configure VPLS multihoming. Some information
is also provided on single-homed site configuration versus multihomed site configuration.
• VPLS Multihomed Site Configuration on page 1269

• VPLS Single-Homed Site Configuration on page 1271

VPLS Multihomed Site Configuration

The following describes the requirements for a VPLS multihomed site configuration:
• Assign the same site ID on all PE routers connected to the same CE devices.
When two PE routers use the same site ID, VPLS assumes multihoming behavior by
default. The site preference value is used to signal the primary and backup PE router.
In such cases, when multihoming is explicitly configured using the multi-homing
statement , it is only used for tracking the BGP peer status, such as to prevent isolation
of the PE router from the core or split brain. There are scenarios, however that require
preventing of BGP peer tracking, such as in a two-PE-router topology. In such cases,
multihoming should not be explicitly configured as it can break node redundancy.
When identical site IDs are used without configuring multihoming, a collision log
message is generated at each signaling: RPD_L2VPN_SITE_COLLISION: Same site ID 2
configured on remote PE (RD 8.8.8.1:1013:) and local PE in VPN 1013 (non-multihomed
site 2). This is expected behavior.
• Assign unique route distinguishers for each multihomed PE router.
• Reference all interfaces assigned to the multihomed VPLS site on each PE router. Only
one of these interfaces is used to send and receive traffic for this site at a time.
• Either designate a primary interface or allow the router to select the interface to be
used as the primary interface.
If the router selects the interface, the interface used to connect the PE router to the
site depends on the order in which interfaces are listed in the PE router’s configuration.
The first operational interface in the set of configured interfaces is chosen to be the
designated interface. If this interface fails, the next interface in the list is selected to
send and receive traffic for the site.
The following configuration shows the statements you need to configure to enable VPLS
multihoming:
[edit routing-instances routing-instance-name]

instance-type vpls;
protocols vpls {
site site-name {
active-interface {
any;
}
multi-homing;
site-identifier number;
}
}
route-distinguisher (as-number:id | ip-address:id);

NOTE: If you add a direct connection between CE devices that are multihomed
to the same VPLS site on different PE routers, the traffic can loop and a loss
of connectivity might occur. We do not recommend this topology.
Most of these statements are explained in more detail in the rest of this chapter. The
following sections explain how to configure the statements that are specific to VPLS
multihoming:
• Specifying an Interface as the Active Interface on page 1270

• Configuring Multihoming on the PE Router on page 1270
Specifying an Interface as the Active Interface
You need to specify one of the interfaces for the multihomed site as the primary interface.
If there are multiple interfaces, the remaining interfaces are activated only when the
primary interface goes down. If no active interfaces are configured at the site level, all
traffic for a VPLS site travels through a single, non-multihomed PE router.
You must configure one of the following options for the active-interface statement:
• any—One configured interface is randomly designated as the active interface for the
VPLS site.
• primary—Specify the name of the multihomed interface to be used as the primary

interface by the VPLS site.
To specify a multihomed interface as the primary interface for the VPLS site, include the
active-interface statement:
active-interface {
any;
}

protocols vpls site site-name]
Configuring Multihoming on the PE Router
When a CE device is connected to the same VPLS site on more than one PE router,
including the multi-homing statement on all associated PE routers results in tracking of
BGP peers. If no BGP peer is available, VPLS deactivates all active interfaces for a site.
When two PE routers use the same site ID, VPLS assumes multihoming behavior by
default. The site preference value is used to signal the primary and backup PE router. In
such cases, when multihoming is explicitly configured using the multi-homing statement
, it is only used for tracking the BGP peer status, such as to prevent isolation of the PE
router from the core or split brain.

NOTE: When identical site IDs are used without configuring multihoming, a
collision log message is generated at each signaling:
RPD_L2VPN_SITE_COLLISION: Same site ID 2 configured on remote PE (RD
8.8.8.1:1013:) and local PE in VPN 1013 (non-multihomed site 2). This is expected
behavior.
VPLS Single-Homed Site Configuration

All VPLS single-homed sites are connected to the same default VE device. All interfaces
in a VPLS routing instance that are not configured as part of a multihomed site are
assumed to be single-homed to the default VE device.
Related • VPLS Multihoming Overview on page 1237

Documentation
• Example: VPLS Multihoming, Improved Convergence Time
• active-interface
• multi-homing
Configuring Firewall Filters and Policers for VPLS in ACX Series
You can configure both firewall filters and policers for VPLS. Firewall filters allow you to
filter packets based on their components and to perform an action on packets that match
the filter. Policers allow you to limit the amount of traffic that passes into or out of an
interface.
VPLS filters and policers act on a Layer 2 frame that includes the media access control
(MAC) header (after any VLAN rewrite or other rules are applied), but does not include
the cyclical redundancy check (CRC) field.
You can apply VPLS filters and policers on the PE router to customer-facing interfaces
only.
The following sections explain how to configure filters and policers for VPLS:
• Configuring a VPLS Filter on page 1271

• Configuring a VPLS Policer on page 1273
Configuring a VPLS Filter

To configure a filter for VPLS, include the filter statement at the [edit firewall family vpls]
hierarchy level:
[edit firewall family vpls]

interface-specific;
term term-name {
from {
match-conditions;

}
then {
actions;
}
}
}
For more information about how to configure firewall filters, see the Routing Policies,
Firewall Filters, and Traffic Policers Feature Guide. For information on how to configure a
VPLS filter match condition, see “Firewall Filter Match Conditions for VPLS Traffic” on
page 1070.
To configure a filter for VPLS traffic, complete the following tasks:
• Configuring an Interface-Specific Counter for VPLS on page 1272

• Configuring an Action for the VPLS Filter on page 1272
• Applying a VPLS Filter to an Interface on page 1272
Configuring an Interface-Specific Counter for VPLS
When you configure a firewall filter for VPLS and apply it to multiple interfaces, you can
specify individual counters specific to each interface. This allows you to collect separate
statistics on the traffic transiting each interface.
To generate an interface-specific counter for VPLS, you configure the interface-specific

statement. A separate instantiation of the filter is generated. This filter instance has a
different name (based on the interface name) and collects statistics on the interface
specified only.
To configure interface-specific counters, include the interface-specific statement at the

[edit firewall family vpls filter filter-name] hierarchy level:
[edit firewall family vpls filter filter-name]

interface-specific;
NOTE: The counter name is restricted to 24 bytes. If the renamed counter

exceeds this maximum length, it might be rejected.
For more information about the interface-specific statement and an example of how to
configure it, see the Routing Policies, Firewall Filters, and Traffic Policers Feature Guide.
Configuring an Action for the VPLS Filter
You can configure the following actions for a VPLS filter at the [edit firewall family vpls
filter filter-name term term-name then] hierarchy level: accept, count, discard,
forwarding-class, loss-priority, policer.
Applying a VPLS Filter to an Interface
To apply a VPLS filter to an interface, include the filter statement:
filter {
input input-filter-name;

output output-filter-name;
}
• [edit interfaces interface-name unit number family vpls]
• [edit logical-systems logical-system-name interfaces interface-name unit number

family vpls]
In the input statement, list the name of the VPLS filter to be evaluated when packets are
received on the interface. In the output statement, list the name of the VPLS filter to be
evaluated when packets are transmitted on the interface.
For the statement summaries for these statements, see the Junos OS Network Interfaces
Configuring a VPLS Policer

You can configure a policer for VPLS traffic. The VPLS policer configuration is similar to
the configuration of any other type of policer.
When specifying policing bandwidth, the VPLS policer considers all Layer 2 bytes in a
packet to determine the packet length.
To configure a VPLS policer, include the policer statement at the [edit firewall] hierarchy
level:
[edit firewall]
policer policer-name {
bandwidth-limit limit;
burst-size-limit limit;
then action;
}
For the statement summaries of these statements and more information about how to
configure policers, see the Routing Policies, Firewall Filters, and Traffic Policers Feature
Guide.
To apply a VPLS policer to an interface, include the policer statement:
policer {
input input-policer-name;
output output-policer-name;
}
• [edit interfaces interface-name unit number family vpls]
• [edit logical-systems logical-system-name interfaces interface-name unit number

family vpls

In the input statement, list the name of the VPLS policer to be evaluated when packets
are received on the interface. In the output statement, list the name of the VPLS policer
to be evaluated when packets are transmitted on the interface.
For the statement summaries for these statements, see the Junos OS Network Interfaces
Configuring Interoperability Between BGP Signaling and LDP Signaling in VPLS
A single VPLS routing instance can encompass one set of PE routers that use BGP for
signaling and another set of PE routers that use LDP for signaling. Within each set, all of
the PE routers are fully meshed in both the control and data planes and have a
bidirectional pseudowire to each of the other routers in the set. However, the BGP-signaled
routers cannot be directly connected to the LDP-signaled routers. To be able to manage
the two separate sets of PE routers in a single VPLS routing instance, a border PE router
must be configured to interconnect the two sets of routers.
The VPLS RFCs and Internet drafts require that all of the PE routers participating in a
single VPLS routing instance must be fully meshed in the data plane. In the control plane,
each fully meshed set of PE routers in a VPLS routing instance is called a PE router mesh
group. The border PE router must be reachable by and have bidirectional pseudowires
to all of the PE routers that are a part of the VPLS routing instance, both the LDP-signaled
and BGP-signaled routers.
For LDP BGP interworking to function, LDP-signaled routers can be configured with
forwarding equivalence class (FEC) 128 or FEC 129.
The following sections describe how to configure BGP LDP interworking for VPLS:
• LDP BGP Interworking Platform Support on page 1275

• Configuring FEC 128 VPLS Mesh Groups for LDP BGP Interworking on page 1275
• Configuring FEC 129 VPLS Mesh Groups for LDP BGP Interworking on page 1275
• Configuring Switching Between Pseudowires Using VPLS Mesh Groups on page 1276
• Configuring Integrated Routing and Bridging Support for LDP BGP Interworking with
VPLS on page 1277
• Configuring Inter-AS VPLS with MAC Processing at the ASBR on page 1277

LDP BGP Interworking Platform Support

LDP BGP interworking is supported on the following Juniper Networks routers and routing
platforms:
• ACX5048
• ACX5096
• M7i
• M10i
• M40e
• M120
• M320
• T Series routers
• TX Matrix routers
• EX Series switches
Configuring FEC 128 VPLS Mesh Groups for LDP BGP Interworking
To configure FEC 128 LDP BGP interworking for VPLS, include the mesh-group statement
in the VPLS routing instance configuration of the PE border router:
mesh-group mesh-group-name {
local-switching;
mac-flush [ explicit-mac-flush-message-options ];
neighbor address;
peer-as all;
vpls-id number;
}

protocols vpls]
Using the neighbor statement, configure each PE router that is a part of the mesh group.
You must separate the LDP-signaled routers and the BGP-signaled routers into their own
respective mesh groups. The LDP-signaled routers can be divided into multiple mesh
groups. The BGP-signaled routers must be configured within a single mesh group for
each routing instance.
Configuring FEC 129 VPLS Mesh Groups for LDP BGP Interworking
Configuration for a mesh group for FEC 129 is very similiar to the configuration for FEC
128.

Note the following differences for FEC 129:
• Each user-defined mesh group must have a unique route distinguisher. Do not use the
route distinguisher that is defined for the default mesh group at the [edit
routing-intances] hierarchy level.
• Each user-defined mesh group must have its own import and export route target.
• Each user-defined mesh group can have a unique Layer 2 VPN ID. By default, all the
mesh groups that are configured for the a VPLS routing-instance use the same Layer
2 VPN ID, the one that you configure at the [edit routing-instances] hierarchy level.
Configuring Switching Between Pseudowires Using VPLS Mesh Groups

To configure switching between Layer 2 circuit pseudowires using VPLS mesh groups,
you can do either of the following:
• Configure a mesh group for each Layer 2 circuit pseudowire terminating at a VPLS
routing instance. The Junos OS can support up to 16 mesh groups on MX Series routers
and up to 128 on M Series and T Series routers. However, two mesh groups are created
by default, one for the CE routers and one for the PE routers. Therefore, the maximum
number of user-defined mesh groups is 14 for MX Series routers and 126 for M Series
and T Series routers.
• Configure a single mesh group, terminate all the Layer 2 circuit pseudowires into it, and
enable local switching between the pseudowires by including the local-switching
statement at the [edit routing-instances routing-instance-name protocols vpls
mesh-group mesh-group-name] hierarchy level. By default, you cannot configure local
switching for mesh groups (except for the CE mesh group) because all of the VPLS PE
routers must be configured in a full mesh. However, local switching is useful if you are
terminating Layer 2 circuit pseudowires in a mesh group configured for an LDP signaled
NOTE: Do not include the local-switching statement on PE routers configured

in a full mesh VPLS network.
To terminate multiple pseudowires at a single VPLS mesh group, include the

local-switching statement:
local-switching;
• [edit routing-instances routing-instance-name protocols vpls mesh-group

mesh-group-name]

protocols vpls mesh-group mesh-group-name]

Configuring Integrated Routing and Bridging Support for LDP BGP Interworking with VPLS
Beginning with Junos OS Release 9.4, you can configure an integrated routing and bridging
(IRB) interface on a router that functions as an autonomous system border router (ASBR)
in an inter-AS VPLS environment between BGP-signaled VPLS and LDP-signaled VPLS.
Previously, IRB interfaces were supported only on Provider Edge (PE) routers.
NOTE: ACX Series routers do not support configuring IRB for LDP BGP
Interworking with VPLS.
To configure a IRB support for LDP BGP Interworking with VPLS, include the
routing-interface interface-name statement.
• [edit logical-routers logical-router-name routing-instances routing-instance-name]
Configuring Inter-AS VPLS with MAC Processing at the ASBR

Inter-AS VPLS with MAC processing at the ASBR enables you to interconnect customer
sites that are located in different ASs. In addition, you can configure the ASs with different
signaling protocols. You can configure one of the ASs with BGP-signaled VPLS and the
other with LDP-signaled VPLS. For more information about how to configure LDP-signaled
and BGP signaled VPLS, see “Configuring Interoperability Between BGP Signaling and
LDP Signaling in VPLS” on page 1274.
For inter-AS VPLS to function properly, you need to configure IBGP peering between the
PE routers, including the ASBRs in each AS, just as you do for a typical VPLS configuration.
You also need to configure EBGP peering between the ASBRs in the separate ASs. The
EBGP peering is needed between the ASBRs only. The link between the ASBR routers
does not have to be Ethernet. You can also connect a CE router directly to one of the
ASBRs, meaning you do not have to have a PE router between the ASBR and the CE
router.
The configuration for the connection between the ASBRs makes inter-AS VPLS with
MAC operations unique. The other elements of the configuration are described in other
sections of this manual.
The following sections describe how to configure inter-AS VPLS with MAC operations:
• Inter-AS VPLS with MAC Operations Configuration Summary on page 1277

• Configuring the ASBRs for Inter-AS VPLS on page 1278
Inter-AS VPLS with MAC Operations Configuration Summary
This section provides a summary of all of the elements which must be configured to
enable inter-AS VPLS with MAC operations. These procedures are described in detail
later in this chapter and in other parts of theJunos OS VPNs Library for Routing Devices.

The following lists all of major elements of an inter-AS VPLS with MAC operations
configuration:
• Configure IBGP between all of the routers within each AS, including the ASBRs.
• Configure EBGP between the ASBRs in the separated ASs. The EBGP configuration
includes the configuration that interconnects the ASs.
• Configure a full mesh of LSPs between the ASBRs.
• Configure a VPLS routing instance encompassing the ASBR routers. The ASBRs are
VPLS peers and are linked by a single pseudowire. Multihoming between ASs is not
supported. A full mesh of pseudowires is needed between the ASBR routers in all of
the interconnected ASs.
• Configure the VPLS routing instances using either BGP signaling or LDP signaling. LDP
BGP interworking is supported for inter-AS VPLS with MAC operations, so it is possible
to interconnect the BGP-signaled VPLS routing instances with the LDP-signaled VPLS
routing instances.
• Configure a single VPLS mesh group for all of the ASBRs interconnected using inter-AS
VPLS.
Configuring the ASBRs for Inter-AS VPLS
This section describes the configuration on the ASBRs needed to enable inter-AS VPLS
with MAC operations.
On each ASBR, you need to configure a VPLS mesh group within the VPLS routing instance
which needs to include all of the PE routers within the AS, in addition to the ASBR. You
need to configure the same mesh group for each of the ASs you want to interconnect
using inter-AS VPLS. The mesh group name should be identical on each AS. You also
must include the peer-as all statement. This statement enables the router to establish
a single pseudowire to each of the other ASBRs.
To configure the mesh group on each ASBR, include the mesh-group and peer-as all
statements:
mesh-group mesh-group-name {
peer-as all;
}

protocols vpls]
Related • Example: Configuring BGP Autodiscovery for LDP VPLS

Documentation
• Example: Configuring BGP Autodiscovery for LDP VPLS with User-Defined Mesh Groups

Interoperability Between BGP Signaling and LDP Signaling in VPLS
You can configure a VPLS routing instance where some of the PE routers use BGP for
signaling and some use LDP for signaling.
The following concepts form the basis of the configuration needed to include both
BGP-signaled and LDP-signaled PE routers in a VPLS routing instance:
• PE router mesh group—Consists of a set of routers participating in a VPLS routing

instance that share the same signaling protocol, either BGP or LDP, and are also fully
meshed. Each VPLS routing instance can have just one BGP mesh group. However,
you can configure multiple LDP mesh groups for each routing instance.
• Border router—A PE router that must be reachable by all of the other PE routers
participating in a VPLS routing instance, whether they are LDP-signaled or BGP-signaled.
Bidirectional pseudowires are created between the border router and all of these PE
routers. The border router is aware of the composition of each PE mesh group configured
as a part of the VPLS routing instance. It can also have direct connections to local CE
routers, allowing it to act as a typical PE router in a VPLS routing instance.
The following sections describe how the LDP-signaled and BGP-signaled PE routers
function when configured to interoperate within a VPLS routing instance:
• LDP-Signaled and BGP-Signaled PE Router Topology on page 1279

• Flooding Unknown Packets Across Mesh Groups on page 1281
• Unicast Packet Forwarding on page 1281
LDP-Signaled and BGP-Signaled PE Router Topology

Figure 64 on page 1280 illustrates a topology for a VPLS routing instance configured to
support both BGP and LDP signaling. Router B is the border router. Routers PE1 and PE2
are in the LDP-signaled mesh group LDP-1. Routers PE3, PE4, and PE5 are in the
LDP-signaled mesh group LDP-2. Routers PE6, PE7, PE8, and router B (the border router)
are in the BGP-signaled mesh group. The border router also acts as a standard VPLS PE
router (having local connections to CE routers). All of the PE routers shown are within
the same VPLS routing instance.

Figure 64: BGP and LDP Signaling for a VPLS Routing Instance
Two-way pseudowires are established between the PE routers in each mesh group and
between each PE router in the VPLS routing instance and the border router. In
Figure 64 on page 1280, two-way pseudowires are established between routers PE1 and
PE2 in mesh group LDP-1, routers PE3, PE4, and PE5 in mesh group LDP-2, and routers
PE6, PE7, and PE8 in the BGP mesh group. Routers PE1 through PE8 also all have two-way
pseudowires to the Border router. Based on this topology, the LDP-signaled routers are
able to interoperate with the BGP-signaled routers. Both the LDP-signaled and
BGP-signaled PE routers can logically function within a single VPLS routing instance.
NOTE: The following features are not supported for VPLS routing instances
configured with both BGP and LDP signaling:
• Point-to-multipoint LSPs
• Integrated routing and bridging
• IGMP snooping

Flooding Unknown Packets Across Mesh Groups

Broadcast, multicast, and unicast packets of unknown origin received from a PE router
are flooded to all local CE routers. They are also flooded to all of the PE routers in the
VPLS routing instance except the PE routers that are a part of the originating PE router
mesh group.
For example, if a multicast packet is received by the border router in Figure 64 on page 1280,
it is flooded to the two local CE routers. It is also flooded to routers PE1 and PE2 in the
LDP-1 mesh group and to routers PE3, PE4, and PE5 in the LDP-2 mesh group. However,
the packet is not flooded to routers PE6, PE7, and PE8 in the BGP mesh group.
Unicast Packet Forwarding

The PE border router is made aware of the composition of each PE router mesh group.
From the data plane, each PE router mesh group is viewed as a virtual pseudowire LAN.
The border router is configured to interconnect all of the PE router mesh groups belonging
to a single VPLS routing instance. To interconnect the mesh groups, a common MAC
table is created on the border router.
Unicast packets originating within a mesh group are dropped if the destination is another
PE router within the same mesh group. However, if the destination MAC address of the
unicast packet is a PE router located in a different mesh group, the packet is forwarded
to that PE router.
PE Router Mesh Groups for VPLS Routing Instances
A PE router mesh group consists of a set of routers participating in a VPLS routing instance
that share the same signaling protocol, either BGP or LDP. Each VPLS routing instance
can have just one BGP mesh group. However, you can configure multiple LDP mesh
groups for each routing instance.
The Junos OS can support up to 16 mesh groups on MX Series routers and up to 128 on
M Series and T Series routers. However, two mesh groups are created by default, one for
the CE routers and one for the PE routers. Therefore, the maximum number of user-defined
mesh groups is 14 for MX Series routers and 126 for M Series and T Series routers.
The Junos OS supports both forwarding equivalency class (FEC) 128 and FEC 129. FEC
129 uses VPLS autodiscovery to convey endpoint information. FEC 128 requires manually
configured pseudowires.

The following describes the behavior of mesh groups in regards to BGP-signaled PE

routers and LDP-signaled PE routers:
• BGP-signaled PE routers—Automatically discovered PE routers that use BGP for

signaling are associated with the default VE mesh group. You cannot configure the
Junos OS to associate these routers with a user-defined VE mesh group.
• LDP-signaled PE routers (FEC 128)—PE routers statically configured using FEC-128

LDP signaling are placed in a default mesh group. However, you can configure a VE
mesh group and associate each LDP FEC-128 neighbor with it. Each configured VE
mesh group contains a set of VEs that are in the same interior gateway protocol (IGP)
routing instance and are fully meshed with each other in the control and data planes.
• LDP-signaled PE routers (FEC 129)—Configuration for a mesh group for FEC 129 is very
similiar to the configuration for FEC 128.
Note the following differences for FEC 129:
• Each user-defined mesh group must have a unique route distinguisher. Do not use
the route distinguisher that is defined for the default mesh group at the [edit
routing-intances] hierarchy level.
• Each user-defined mesh group must have its own import and export route target.
• Each user-defined mesh group can have a unique Layer 2 VPN ID. By default, all the
mesh groups that are configured for the a VPLS routing-instance use the same Layer
2 VPN ID, the one that you configure at the [edit routing-instances] hierarchy level.
Related • Example: Configuring BGP Autodiscovery for LDP VPLS

Documentation
Example: Configuring BGP-Based H-VPLS Using Different Mesh Groups for Each Spoke
Router
This example shows how to configure the hierarchical virtual private LAN service (H-VPLS)
using different mesh groups to provide H-VPLS functionality and provides steps for
verifying the configuration. This is one type of H-VPLS configuration possible in the Juniper
Networks implementation. For information about the alternate type of configuration see
“Example: Configuring LDP-Based H-VPLS Using a Single Mesh Group to Terminate the
Layer 2 Circuits” on page 1304.
Using mesh groups improves LDP-based VPLS control plane scalability and avoids the
requirement for a full mesh of LDP sessions. This example uses BGP-based VPLS.
This example is organized into the following sections:


Requirements
• Four MX Series 3D Universal Edge Routers for Router PE1, Router PE2, Router PE3, and
Router PE4
• One M Series Multiservice Edge Router for Router CE4
• Two EX Series Ethernet Switches for Device CE1 and Device CE2
• One J Series Services Router for Router CE3

Figure 65 on page 1283 shows the physical topology used in this example.
Figure 65: Physical Topology of H-VPLS
The following describes the base configuration used in this example:
• Router PE1 and Router PE2 are configured as MTU devices.
• Router PE3 and Router PE4 are configured as PE-r routers, each using an LDP-based
• The LDP and OSPF protocols are configured on all of the MTU devices and PE-r routers.
• Core-facing interfaces are enabled with the MPLS address family.
• Optionally, the VPLS routing instances can be configured on PE-r routers with the
no-tunnel-interface statement. This allows the routers to use a label-switched interface
(LSI), which is useful if your routers do not have Tunnel Services PICs or built-in support
for tunnel services.

• All of the routers are configured with loopback IP addresses.
• BGP is configured on the PE-r routers. Optionally, you can configure route reflection.
This is useful for scaling internal BGP (IBGP). The BGP configuration includes the
signaling statement at the [edit protocols bgp group group-name family l2vpn] hierarchy
level to support Layer 2 VPN signaling using BGP.
Figure 66 on page 1284 shows the logical topology used in this example.
Figure 66: Logical Topology of H-VPLS
In Figure 66 on page 1284:
• The MTU devices (Router PE1 and Router PE2) have Layer 2 circuit connections to the
PE-r routers (Router PE3 and Router PE4). For redundancy, a backup neighbor is
configured for the Layer 2 circuit connections to the PE-r routers.
• The l2circuit statement in the [edit protocols] hierarchy is included on the MTU devices.
• A VPLS routing instance is configured on the PE-r routers.
• In the VPLS routing instance on the PE-r routers, mesh groups are created to terminate
the Layer 2 circuit pseudowires that originate at the MTU devices.
• Each MTU device is configured with a different virtual circuit ID.
• Each PE-r router’s mesh groups configuration includes VPLS ID values that match the
virtual circuit IDs used on the MTU devices.
Configuration
To configure H-VPLS with different mesh groups for each spoke PE-r router using
BGP-based VPLS, perform the following tasks:
• Configuring the Spoke MTU PE Routers on page 1284

• Configuring the Hub PE (PE-r) on page 1286
• Verifying the H-VPLS Operation on page 1289
Configuring the Spoke MTU PE Routers
Step-by-Step 1. On Router PE1, configure the Gigabit Ethernet interface connected to Router CE1.
Procedure Include the encapsulation statement and specify the ethernet-ccc option. Also

configure the logical interface by including the family statement and specifying the
ccc option.
[edit interfaces]
ge-2/0/5 {
unit 0 {
family ccc;
}
}
2. On Router PE1, configure the Layer 2 circuit by including the neighbor statement and
specifying the IP address of Router PE3 as the neighbor. Configure the Gigabit
Ethernet logical interface by including the virtual-circuit-id statement and specifying
100 as the ID. Also configure a backup neighbor for the Layer 2 circuit by including
the backup-neighbor statement, specifying the loopback interface IP address of
Router PE4 as the backup neighbor, and including the standby statement.
[edit protocols]
l2circuit {
neighbor 192.0.2.3 {
backup-neighbor 192.0.2.4 { # Backup H-VPLS PE router
standby;
}
}
}
3. On Router PE2, configure the Gigabit Ethernet interface connected to Router CE2.
Include the encapsulation statement and specify the ethernet-ccc option. Also
configure the logical interface by including the family statement and specifying the
ccc option.
[edit interfaces]
ge-2/0/6 {
unit 0 {
family ccc;
}
}
4. On Router PE2, configure the Layer 2 circuit by including the neighbor statement
and specifying the IP address of Router PE3 as the neighbor. Configure the Gigabit
Ethernet logical interface by including the virtual-circuit-id statement and specifying
200 as the ID. Configure the encapsulation by including the encapsulation-type
statement and specifying the ethernet option. Also configure a backup neighbor for
the Layer 2 circuit by including the backup-neighbor statement, specifying the
loopback interface IP address of Router PE4 as the backup neighbor, and including
the standby statement.
[edit protocols]
l2circuit {

virtual-circuit-id 200; # different VC-ID
encapsulation-type ethernet; # default encapsulation
standby;
}
}
}
}
Configuring the Hub PE (PE-r)
Step-by-Step 1. On Router PE3 (the primary hub), configure the Gigabit Ethernet interface connected
Procedure to Router CE3. Include the encapsulation statement and specify the ethernet-vpls
option. Also configure the logical interface by including the family vpls statement.
[edit interfaces]
ge-2/0/0 {
unit 0 {
family vpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.3/24;
}
}
}
2. On Router PE4 (the backup hub), configure the Gigabit Ethernet interface connected
to Router CE4. Include the encapsulation statement and specify the ethernet-vpls
option. Also configure the logical interface by including the family vpls statement.
[edit interfaces]
ge-2/1/7 {
unit 0 {
description to_CE4;
family vpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.4/24;
}
}
}

3. On PE-r Router PE3, configure the BGP-based VPLS routing instance by including
the instance-type statement at the [edit routing-instances H-VPLS] hierarchy level
and specifying the vpls option. Include the interface statement and specify the
Gigabit Ethernet interface connected to Router CE3. Configure a route distinguisher
to ensure that the route advertisement is unique by including the route-distinguisher
statement and specifying 192.0.2.3:33 as the value. Also configure the VPN routing
and forwarding (VRF) route target to be included in the route advertisements to
the other routers participating in the VPLS. To configure the VRF route target, include
the vrf-target statement and specify target:64510:2 as the value. Optionally, include
the no-tunnel-services statement to enable the use of LSI interfaces, which is useful
if the device does not have tunnel services. The no-tunnel-services statement is
omitted in this example. Optionally, you can include the site-range statement to
specify an upper limit on the maximum site identifier that can be accepted to allow
a pseudowire to be brought up. The site-range statement is omitted in this example.
We recommend using the default of 65,534.
Configure the VPLS protocol and the mesh groups for each MTU PE device.
To configure the VPLS protocol, include the vpls statement at the [edit
routing-instances H-VPLS protocols] hierarchy level. Include the site statement and
specify a name for the site. Include the interface statement and specify the Gigabit
Ethernet interface connected to Device CE3.
Configuring mesh groups under the VPLS instance terminates the Layer 2 circuit
into the VPLS instance. To configure each mesh group, include the mesh-group
statement and specify the mesh group name. In this example, the mesh group name
is the name of the MTU device associated with each mesh group. Include the vpls-id
statement and specify the ID that matches the virtual circuit ID configured in
“Configuring the Spoke MTU PE Routers” on page 1284. Also include the neighbor
statement and specify the IP address of the spoke PE router associated with each
mesh group. Optionally, include the local-switching statement if you are not using
a full mesh of VPLS connections. The local-switching statement is useful if you are
configuring a single mesh group and terminating multiple Layer 2 circuit pseudowires
into it. The local-switching statement is omitted in this example.
routing-instances {
H-VPLS {
instance-type vpls;
protocols {
vpls {
site pe3 {
site-identifier 3;
}
mesh-group pe1 {
vpls-id 100;
neighbor 192.0.2.1;
}
mesh-group pe2 {
vpls-id 200;

neighbor 192.0.2.2;
}
}
}
}
}
4. On PE-r Router PE4, configure a routing instance like the one on Router PE3.
routing-instances {
H-VPLS {
instance-type vpls;
protocols {
vpls {
site pe4 {
site-identifier 4;
}
mesh-group pe1 {
vpls-id 100;
neighbor 192.0.2.1;
}
mesh-group pe2 {
vpls-id 200;
neighbor 192.0.2.2;
}
}
}
}
}

Verifying the H-VPLS Operation
Step-by-Step This section describes the operational commands that you can use to validate that the
Procedure H-VPLS is working as expected.

1. On Router PE1 and Router PE2, use the show l2circuit connections command to
verify that the Layer 2 circuit to Router PE3 is Up and the Layer 2 circuit to Router
PE4 is in standby mode.
The output also shows the assigned label, virtual circuit ID, and the ETHERNET
encapsulation type.
user@PE1> show l2circuit connections


RD -- remote site signaled down XX -- unknown

Up -- operational
Dn -- down
Neighbor: 192.0.2.3
ge-2/0/5.0(vc 100) rmt Up Oct 18 15:55:07 2012 1
Remote PE: 192.0.2.3, Negotiated control-word: No
Negotiated PW status TLV: No
Local interface: ge-2/0/5.0, Status: Up, Encapsulation: ETHERNET
Neighbor: 192.0.2.4
ge-2/0/5.0(vc 100) rmt ST



Up -- operational
Dn -- down
Neighbor: 192.0.2.3
ge-2/0/6.0(vc 200) rmt Up Oct 18 15:55:07 2012 1


Local interface: ge-2/0/6.0, Status: Up, Encapsulation: ETHERNET
Neighbor: 192.0.2.4
ge-2/0/6.0(vc 200) rmt ST
2. On Router PE1 and Router PE2, use the show ldp neighbor command to verify that
the targeted LDP sessions have been created between the loopback interface to
the primary and backup H-VPLS hub neighbors.
user@PE1> show ldp neighbor

Address Interface Label space ID Hold time
10.10.3.2 ge-2/0/9.0 192.0.2.2:0 13
10.10.1.2 ge-2/0/10.0 192.0.2.3:0 10
192.0.2.3 lo0.0 192.0.2.3:0 36
192.0.2.4 lo0.0 192.0.2.4:0 39
10.10.9.2 ge-2/0/8.0 192.0.2.4:0 14
user@PE2> show ldp neighbor

10.10.3.1 ge-2/0/10.0 192.0.2.1:0 12
10.10.5.2 ge-2/0/9.0 192.0.2.4:0 11
10.10.4.1 ge-2/0/8.0 192.0.2.3:0 11
192.0.2.3 lo0.0 192.0.2.3:0 39
192.0.2.4 lo0.0 192.0.2.4:0 38
3. On Router PE3 and Router PE4, use the show vpls connections command to verify
that the VPLS connection status is Up for both the LDP-based VPLS and the
BGP-based VPLS Layer 2 circuits that are terminated.
user@PE3> show vpls connections
Layer-2 VPN connections:

EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down NP -- interface hardware not present
CM -- control-word mismatch -> -- only outbound connection is up
CN -- circuit not provisioned <- -- only inbound connection is up
OR -- out of range Up -- operational
OL -- no outgoing label Dn -- down
LD -- local site signaled down CF -- call admission control failure
RD -- remote site signaled down SC -- local and remote site ID collision
LN -- local site not designated LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status IL -- no incoming label
MM -- MTU mismatch MI -- Mesh-Group ID not available
BK -- Backup connection ST -- Standby connection
PF -- Profile parse failure PB -- Profile busy
RS -- remote site standby SN -- Static Neighbor
LB -- Local site not best-site RB -- Remote site not best-site
VM -- VLAN ID mismatch

Up -- operational
Dn -- down

Instance: H-VPLS
BGP-VPLS State
Local site: pe3 (3)
connection-site Type St Time last up # Up trans
4 rmt Up Oct 18 15:58:39 2012 1
Local interface: vt-2/0/9.135266562, Status: Up, Encapsulation: VPLS
Description: Intf - vpls H-VPLS local site 3 remote site 4
LDP-VPLS State
Mesh-group connections: pe1
Neighbor Type St Time last up # Up trans
192.0.2.1(vpls-id 100) rmt Up Oct 18 15:55:07 2012 1
Local interface: vt-2/0/10.135266560, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls H-VPLS neighbor 192.0.2.1 vpls-id 100
192.0.2.2(vpls-id 200) rmt Up Oct 18 15:55:07 2012 1


Up -- operational
Dn -- down
Instance: H-VPLS
BGP-VPLS State
Local site: pe4 (4)
connection-site Type St Time last up # Up trans
3 rmt Up Oct 18 15:58:39 2012 1


Local interface: vt-2/0/8.17826050, Status: Up, Encapsulation: VPLS
Description: Intf - vpls H-VPLS local site 4 remote site 3
LDP-VPLS State
192.0.2.1(vpls-id 100) rmt Up Oct 18 15:58:39 2012 1
192.0.2.2(vpls-id 200) rmt Up Oct 18 15:58:39 2012 1
4. On Router PE3 and Router PE4, use the show vpls flood command to verify that the
H-VPLS PE router created a flood group for each spoke PE site.
user@PE3> show vpls flood

Name: H-VPLS
CEs: 1
VEs: 3
Flood Routes:
Prefix Type Owner NhType NhIndex
0x300cc/51 FLOOD_GRP_COMP_NH __ves__ comp 1376
0x300cf/51 FLOOD_GRP_COMP_NH __all_ces__ comp 744
0x300d5/51 FLOOD_GRP_COMP_NH pe1 comp 1702
0x30001/51 FLOOD_GRP_COMP_NH __re_flood__ comp 740
user@PE4> show vpls flood

Name: H-VPLS
CEs: 1
VEs: 3
Flood Routes:
Prefix Type Owner NhType NhIndex
0x300d1/51 FLOOD_GRP_COMP_NH __ves__ comp 1534
0x300d0/51 FLOOD_GRP_COMP_NH __all_ces__ comp 753
0x30002/51 FLOOD_GRP_COMP_NH __re_flood__ comp 750
5. On Router PE3 and Router PE4, use the show vpls mac-table command to verify
that MAC addresses of the CE devices have been learned.
user@PE3> show vpls mac-table

MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : H-VPLS

Bridging domain : __H-VPLS__, VLAN : NA
MAC MAC Logical NH RTR
address flags interface Index ID

00:21:59:0f:35:32 D vt-2/0/8.135266560
00:21:59:0f:35:33 D ge-2/1/3.0
00:21:59:0f:35:d4 D vt-2/0/9.135266561
00:21:59:0f:35:d5 D vt-2/0/10.135266562
user@PE4> show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Logical system : PE4

Routing instance : H-VPLS
Bridging domain : __H-VPLS__, VLAN : NA
MAC MAC Logical NH RTR
address flags interface Index ID
00:21:59:0f:35:32 D vt-2/0/8.17826050
00:21:59:0f:35:33 D vt-2/0/9.17826050
00:21:59:0f:35:d4 D vt-2/0/10.17826050
00:21:59:0f:35:d5 D ge-2/1/7.0
6. Make sure that the CE devices can ping each other.
user@CE1> ping 10.255.14.219 # ping sent from CE1 CE4

PING 10.255.14.219 (10.255.14.219): 56 data bytes
64 bytes from 10.255.14.219: icmp_seq=0 ttl=64 time=10.617 ms
^C
--- 10.255.14.219 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.224/9.921/10.617/0.697 ms
user@CE2> ping 10.255.14.218 # ping sent from CE2 to CE3
PING 10.255.14.218 (10.255.14.218): 56 data bytes

^C
--- 10.255.14.218 ping statistics ---
7. Check the relevant routing tables.
user@PE1> show route table l2circuit.0

l2circuit.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
192.0.2.3:NoCtrlWord:5:100:Local/96
*[L2CKT/7] 00:12:16, metric2 1
> to 10.10.1.2 via ge-2/0/10.0
192.0.2.3:NoCtrlWord:5:100:Remote/96
*[LDP/9] 00:12:16
Discard
*[L2CKT/7] 00:12:10, metric2 1
> to 10.10.9.2 via ge-2/0/8.0
*[LDP/9] 00:12:15
Discard

user@PE2> show route table l2circuit.0

l2circuit.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
*[L2CKT/7] 00:13:13, metric2 1
> to 10.10.4.1 via ge-2/0/8.0
*[LDP/9] 00:13:13
Discard
*[L2CKT/7] 00:13:13, metric2 1
> to 10.10.5.2 via ge-2/0/9.0
*[LDP/9] 00:13:13
Discard
user@PE3> show route table H-VPLS.l2vpn.0
H-VPLS.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

192.0.2.3:33:3:1/96
*[L2VPN/170/-101] 03:19:26, metric2 1
Indirect
192.0.2.4:44:4:1/96
*[BGP/170] 03:15:45, localpref 100, from 192.0.2.4
AS path: I, validation-state: unverified
> to 10.10.6.2 via ge-2/0/9.0
user@PE4> show route table H-VPLS.l2vpn.0
H-VPLS.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

192.0.2.3:33:3:1/96
*[BGP/170] 03:21:17, localpref 100, from 192.0.2.3
AS path: I, validation-state: unverified
> to 10.10.6.1 via ge-2/0/9.0
192.0.2.4:44:4:1/96
*[L2VPN/170/-101] 03:17:47, metric2 1
Indirect
Results The configuration and verification parts of this example have been completed. The
following section is for your reference.
The relevant sample configuration for Router PE1 follows.
Router PE1 interfaces {

ge-2/0/5 {
unit 0 {
description to_CE1;
family ccc;
}
}
ge-2/0/8 {
unit 0 {

description to_PE4;
family inet {
address 10.10.9.1/30;
}
family mpls;
}
}
ge-2/0/9 {
unit 0 {
description to_PE2;
family inet {
address 10.10.3.1/30;
}
family mpls;
}
}
ge-2/0/10 {
unit 0 {
description to_PE3;
family inet {
address 10.10.1.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.1/24;
}
}
}
}
protocols {
mpls {
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
ldp {
interface lo0.0;
}

l2circuit {
standby;
}
}
}
}
}

ge-2/0/6 {
unit 0 {
description to_CE2;
family ccc;
}
}
ge-2/0/8 {
unit 0 {
description to_PE3;
family inet {
address 10.10.4.2/30;
}
family mpls;
}
}
ge-2/0/9 {
unit 0 {
description to_PE4;
family inet {
address 10.10.5.1/30;
}
family mpls;
}
}
ge-2/0/10 {
unit 0 {
description to_PE1;
family inet {
address 10.10.3.2/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.2/24;
}
}
}

}
protocols {
mpls {
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
ldp {
interface lo0.0;
}
l2circuit {
standby;
}
}
}
}
}

ge-2/0/8 {
unit 0 {
description to_PE2;
family inet {
address 10.10.4.1/30;
}
family mpls;
}
}
ge-2/0/9 {
unit 0 {
description to_PE4;
family inet {
address 10.10.6.1/30;
}
family mpls;
}

}
ge-2/0/10 {
unit 0 {
description to_PE1;
family inet {
address 10.10.1.2/30;
}
family mpls;
}
}
ge-2/1/3 {
unit 0 {
description to_CE3;
family vpls;
}
}
lo0 {
unit 0{
family inet {
address 192.0.2.3/24;
}
}
}
}
protocols {
mpls {
}
bgp {
group internal-peers {
type internal;
family l2vpn {
signaling;
}
neighbor 192.0.2.4;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
ldp {

interface lo0.0;
}
}
routing-instances {
H-VPLS {
instance-type vpls;
protocols {
vpls {
site pe3 {
site-identifier 3;
}
mesh-group pe1 {
vpls-id 100;
neighbor 192.0.2.1;
}
mesh-group pe2 {
vpls-id 200;
neighbor 192.0.2.2;
}
}
}
}
}
routing-options {
}

ge-2/0/8 {
unit 0 {
description to_PE3;
family inet {
address 10.10.6.2/30;
}
family mpls;
}
}
ge-2/0/9 {
unit 0 {
description to_PE1;
family inet {
address 10.10.9.2/30;
}
family mpls;
}
}
ge-2/0/10 {
unit 0 {
description to_PE2;
family inet {

address 10.10.5.2/30;
}
family mpls;
}
}
ge-2/1/7 {
unit 0 {
description to_CE4;
family vpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.4/24;
}
}
}
}
protocols {
mpls {
}
bgp {
group internal-peers {
type internal;
family l2vpn {
signaling;
}
neighbor 192.0.2.3;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
ldp {
interface lo0.0;
}
}
routing-instances {
H-VPLS {

instance-type vpls;
protocols {
vpls {
site pe4 {
site-identifier 4;
}
mesh-group pe1 {
vpls-id 100;
neighbor 192.0.2.1;
}
mesh-group pe2 {
vpls-id 200;
neighbor 192.0.2.2;
}
}
}
}
}
routing-options {
}
The relevant sample configuration for Device CE1 follows.
Router CE1 interfaces {

ge-2/0/8 {
unit 0 {
description to_PE1;
family inet {
address 172.16.0.1/24;
}
}
}
lo0 {
unit 0{
family inet {
address 10.255.14.214/32;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
}


ge-2/1/5 {
unit 0 {
description to_PE2;
family inet {
address 172.16.0.2/24;
}
}
}
lo0 {
unit 0{
family inet {
address 10.255.14.215/32;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
}

ge-2/0/9 {
unit 0 {
description to_PE3;
family inet {
address 172.16.0.3/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.255.14.218/32;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}

}
}
}

ge-2/1/6 {
unit 0 {
description to_PE4;
family inet {
address 172.16.0.4/24;
}
}
}
lo0 {
unit 0{
family inet {
address 10.255.14.219/32;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
}
}
}
Related • Example: Configuring LDP-Based H-VPLS Using a Single Mesh Group to Terminate
Documentation the Layer 2 Circuits on page 1304
Example: Configuring LDP-Based H-VPLS Using a Single Mesh Group to Terminate

the Layer 2 Circuits
This example shows how to configure a single mesh group to terminate the Layer 2
circuits into an LDP-based VPLS. This is one type of hierarchical virtual private LAN service
(H-VPLS) configuration possible in the Juniper Networks implementation. For information
about the alternate type of configuration see “Example: Configuring BGP-Based H-VPLS
Using Different Mesh Groups for Each Spoke Router” on page 1282.
This example provides step-by-step configuration instructions and also provides steps
for verifying and troubleshooting the configuration.

This example is organized into the following sections:

Requirements
• Four MX Series 3D Universal Edge Routers for Routers PE1, PE2, PE3, and PE4
• Two M Series Multiservice Edge Routers for Routers CE4 and PE5
• Two EX Series Ethernet Switches for Devices CE1 and CE2
• Two T Series Core Routers for Routers P1 and the route reflector

Figure 67 on page 1305 shows the physical topology used in this example.
Figure 67: Physical Topology of H-VPLS using a Single Mesh Group
In Figure 67 on page 1305:
• Local switching is used to switch traffic between Layer 2 circuit pseudowires from the
different spoke PE routers.
• The spoke PE routers are configured with the same virtual circuit ID and VPLS ID pair
in a mesh group.
• The spoke PE routers are configured in an LDP-signaled VPLS routing instance.
• The layer 2 circuits are terminated into the LDP-based VPLS.

Configuration
To configure a single mesh group to terminate the Layer 2 circuits into an LDP-based
VPLS, perform the following tasks:
• Configuring the Spoke PE Routers on page 1306

• Configuring the Hub PE Router on page 1308
Configuring the Spoke PE Routers
Step-by-Step Configure a single mesh group to terminate all the Layer 2 circuit pseudowires and enable
Procedure local switching between the pseudowires.
1. On Router PE1, configure the Layer 2 circuit by including the l2circuit statement at
the [edit protocols] hierarchy level. Include the neighbor statement and specify the
IPv4 address of the hub PE router. Also configure the logical interface by including
the interface statement and specify the interface connected to Router CE1.
Configure the virtual circuit ID by including the virtual-circuit-id statement and

specifying 100 as the ID value at the [edit protocols l2circuit neighbor 192.0.2.5
interface ge-1/0/0.0] hierarchy level.
Configure the backup neighbor by including the backup-neighbor statement and

specifying the IPv4 address of the backup hub PE router. Router PE3 is the backup
neighbor in this example. Also include the standby statement at the [edit protocols
l2circuit neighbor 192.0.2.5 interface ge-1/0/0.0 backup-neighbor 192.0.2.3] hierarchy
level.
[edit protocols]
l2circuit {
standby;
}
}
}
}
IPv4 address of the hub PE router. Configure the logical interface by including the
interface statement and specifying the interface connected to Router CE2.

interface ge-1/0/2.0] hierarchy level. Include the encapsulation statement and
specify ethernet as the type.


level.
[edit protocols]
l2circuit {
encapsulation-type ethernet;
standby;
}
}
}
}
IPv4 address of the hub PE router. Configure the logical interface by including the
interface statement and specify the interface connected to Router CE4.

interface ge-1/2/0.0] hierarchy level.

level.
[edit protocols]
l2circuit {
standby;
}
}
}
}

Configuring the Hub PE Router
Step-by-Step Configure a single mesh group to terminate all the Layer 2 circuit pseudowires and enable
Procedure local switching between the pseudowires.
1. On Router PE3, configure the Gigabit Ethernet interface connected to Router CE3
by including the encapsulation statement and specifying the ethernet-vpls option.
Also configure the logical interface by including the family statement and specifying
the vpls option.
[edit interfaces]
ge-1/0/1 {
unit 0 {
family vpls;
}
}
2. On Router PE3, configure the logical loopback interface by including the family
statement and specifying the inet option. Include the address statement and specify
the IPv4 address for the interface.
[edit interfaces]
lo0 {
unit 0 {
family inet {
address 192.0.2.3/24;
}
}
}
3. On Router PE3, configure the LDP-based VPLS routing instance by including the
instance-type statement at the [edit routing-instances H-VPLS] hierarchy level and
specifying the vpls option. Include the interface statement and specify the Gigabit
Ethernet interface connected to Router CE3.
Configure the VPLS protocol by including the vpls statement at the [edit
routing-instances H-VPLS protocols] hierarchy level. Include the no-tunnel-services
statement to enable the router to use an LSI interface.
[edit routing-instances]
H-VPLS {
instance-type vpls;
protocols {
vpls {
no-tunnel-services;
}
}
}

4. On Router PE3, configure the mesh group by including the mesh-group statement
at the [edit routing-instances H-VPLS protocols vpls] hierarchy level and specifying
L2-Circuits as the name of the group. Include the vpls-id statement and specify 100
as the ID value. Include the local-switching statement to enable the router to switch
traffic between the pseudowires.
For each neighbor in the mesh group, include the neighbor statement and specify
the IPv4 address of the spoke PE router.
[edit routing-instances H-VPLS protocols vpls]

mesh-group L2-Circuits {
vpls-id 100; <<< Same VPLS ID on all MTUs
local-switching; << Local-switching enabled
neighbor 192.0.2.1; <<MTU IP addresses
neighbor 192.0.2.2;
neighbor 192.0.2.4;
}
Verification
Step-by-Step 1. On Router PE5, use the show ldp neighbor command to verify that LDP sessions
Procedure have been created to each of the spoke PE routers.
user@PE5# show ldp neighbor

192.0.2.1 lo0.0 192.0.2.1:0 33
192.0.2.2 lo0.0 192.0.2.2:0 37
192.0.2.4 lo0.0 192.0.2.4:0 39
2. On Router PE5, use the show vpls connections extensive command to verify that
the mesh group neighbor session is Up, that inbound and outbound labels have
been assigned, that the VPLS ID is correct, and that the virtual tunnel interface is
being used.
user@PE5# show vpls connections extensive

...
Instance: H-VPLS
Number of local interfaces: 1
Number of local interfaces up: 1
Number of VE mesh-groups: 2
Number of VE mesh-groups up: 1
ge-2/0/0.0
Mesh-group interfaces: L2-Circuits
State: Up ID: 2
vt-2/1/0.1048848 Intf - vpls H-VPLS neighbor 192.0.2.4 vpls-id 100
Mesh-group interfaces: __ves__
State: Dn ID: 0
Mesh-group connections: L2-Circuits
192.0.2.4(vpls-id 100) rmt Up Jan 3 16:46:26 2010 1


Connection History:
Jan 3 16:46:26 2010 In lbl Update 800011
Jan 3 16:46:26 2010 In lbl Update 800011
Jan 3 16:46:26 2010 loc intf up vt-2/1/0.1048848
192.0.2.2(vpls-id 100) rmt Up Jan 3 16:46:26 2010 1
Connection History:
Jan 3 16:46:26 2010 In lbl Update 800010
Jan 3 16:46:26 2010 In lbl Update 800010
Jan 3 16:46:26 2010 loc intf up vt-2/1/0.1048849
192.0.2.1(vpls-id 100) rmt Up Jan 3 16:46:26 2010 1
Connection History:
Jan 3 16:46:26 2010 In lbl Update 800009
Jan 3 16:46:26 2010 In lbl Update 800009
Jan 3 16:46:26 2010 loc intf up vt-2/1/0.1048850
Related • Example: Configuring BGP-Based H-VPLS Using Different Mesh Groups for Each Spoke
Documentation Router on page 1282
Example: Configuring H-VPLS With VLANs
This example shows how to configure the hierarchical virtual private LAN service
(H-VPLS). VLANs are configured in this example.

Requirements
No special configuration beyond device initialization is required before configuring this
example.

Overview
H-VPLS uses LDP-based VPLS to signal and establish pseudowires. LDP-based VPLS
is defined in RFC 4762, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol
(LDP) Signaling. RFC 4762 also defines a hierarchical mode of operation for LDP VPLS
called H-VPLS.
VPLS and H-VPLS are different with respect to scaling. VPLS requires a full mesh of
tunnel label-switched paths (LSPs) among all of the provider edge (PE) routers that
participate in the VPLS service. For each VPLS service, n*(n-1)/2 pseudowires must be
set up between the PE routers. In contrast, H-VPLS partitions the network into several
edge domains that are interconnected using an MPLS core. Each edge device only needs
to learn of one local PE device and therefore needs less routing table support. This has
the potential to allow service providers to use relatively less costly devices (such as EX
Series switches) at the customer edge.
NOTE: As alternatives to H-VPLS, Juniper Networks offers other ways to

address VPLS scalability. For more information, see Application Note:
Demystifying H-VPLS.
H-VPLS defines two roles or functionalities:
• PE-r—PE device that runs VPLS with other PE-r devices, but which also has pseudowires
(it can be based on QinQ access) with another device called a multi-tenant unit (MTU),
which provides the access layer.
• MTU—PE device that represents the access layer on the H-VPLS architecture and
establishes pseudowires to one or more PE-r devices through which VPLS traffic is
forwarded.
Figure 68 on page 1311 shows the topology used in this example.
Figure 68: Basic H-VPLS With One MTU and Two PE-r Devices
(MTU)
ge-2/0/8 ge-2/0/5 ge-2/0/10 ge-2/0/10 ge-2/0/6 ge-2/1/5

CE1 PE1 PE2 CE2
172.16.0.3/24 172.16.0.4/24
ge-2/0/11
loO:
CE1 10.255.14.214 ge-2/0/10
CE2 10.255.14.215
CE3 10.255.14.218 PE3
PE1 10.255.14.217
PE2 10.255.14.216 ge-2/1/3
PE3 10.255.14.225
172.16.0.5/24 ge-2/0/9
g041351
CE3
The example shows one MTU (Device PE1) connected to two PE-r devices (Device PE2
and Device PE3).

The pseudowire between Device PE1 and Device PE3 is the primary or working path. The
pseudowire between Device PE1 and Device PE2 is the backup path.
To support VLANs with H-VPLS, you must include the output-vlan-map swap statement
in the configuration of the MTU device as a workaround to prevent a VLAN ID mismatch.
Otherwise, the PE-r devices report a VLAN ID mismatch, as shown here:



Up -- operational
Dn -- down
Instance: customer
VPLS-id: 601
10.255.14.217(vpls-id 601) rmt VM
“CLI Quick Configuration” on page 1312 shows the configuration for all of the devices in
Figure 68 on page 1311. The section “Step-by-Step Procedure” on page 1314 describes the
steps on Device PE1 and Device PE2.
Configuration
level.
Device PE1 set interfaces ge-2/0/5 vlan-tagging

set interfaces ge-2/0/5 encapsulation vlan-ccc
set interfaces ge-2/0/5 unit 601 output-vlan-map swap
set interfaces ge-2/0/5 unit 601 family ccc


set protocols l2circuit neighbor 10.255.14.225 interface ge-2/0/5.601 virtual-circuit-id
601
set protocols l2circuit neighbor 10.255.14.225 interface ge-2/0/5.601 encapsulation-type
ethernet-vlan
10.255.14.216 standby
Device PE2 set interfaces ge-2/0/6 vlan-tagging

set interfaces ge-2/0/6 encapsulation vlan-vpls
set interfaces ge-2/0/6 unit 601 encapsulation vlan-vpls
set interfaces ge-2/0/6 unit 601 family vpls
set routing-instances customer instance-type vpls
set routing-instances customer interface ge-2/0/6.601
set routing-instances customer protocols vpls vpls-id 601
set routing-instances customer protocols vpls neighbor 10.255.14.217 encapsulation-type
ethernet-vlan
set interfaces ge-2/1/3 encapsulation vlan-vpls
set interfaces ge-2/1/3 unit 601 encapsulation vlan-vpls


set interfaces ge-2/1/3 unit 601 family vpls
set routing-instances customer instance-type vpls
set routing-instances customer interface ge-2/1/3.601
set routing-instances customer protocols vpls vpls-id 601
set routing-instances customer protocols vpls neighbor 10.255.14.217 encapsulation-type
ethernet-vlan



To configure H-VPLS on the MTU device:
On the MTU device interface that connects to the customer edge, configure one of
the circuit cross-connect (CCC) encapsulation types and the CCC address family.
This enables Layer 2 circuits.
On the core-facing interfaces, enable MPLS labels. The ISO address is needed as
well on the core-facing interfaces because IS-IS is used in the core.
[edit interfaces]

user@PE1# set ge-2/0/5 vlan-tagging

user@PE1# set ge-2/0/5 encapsulation vlan-ccc
user@PE1# set ge-2/0/5 unit 601 family ccc
user@PE1# set ge-2/0/5 unit 601 encapsulation vlan-ccc
user@PE1# set ge-2/0/5 unit 601 vlan-id 601
user@PE1# set ge-2/0/5 unit 601 output-vlan-map swap



2. Enable MPLS and LDP on the interfaces.
On the MTU device interfaces that connect to other PE devices, configure MPLS
and LDP.

[edit protocols ldp ]

3. Enable routing on the interfaces.
On the MTU device interfaces that connect to other PE devices, configure an interior
gateway protocol (IGP), such as OSPF or IS-IS.

user@PE1# set level 1 disable
4. Configure the Layer 2 circuit.
The neighbor 10.255.14.225 is Device PE3’s loopback interface address. This sets
up the working path.
The neighbor 10.255.14.216 is Device PE2’s loopback interface address. This sets up
the backup path.
The virtual circuit ID must match the VPLS ID that is configured on Device PE2 and
Device PE3.

[edit protocols l2circuit neighbor 10.255.14.225 interface ge-2/0/5.601]

user@PE1# set virtual-circuit-id 601
user@PE1# set encapsulation-type ethernet-vlan
user@PE1# set backup-neighbor 10.255.14.216 standby
5. Configure the router ID.
To configure H-VPLS on the MTU device:
On the PE-r device interface that connects to the customer edge, configure one of
the VPLS encapsulation types and the VPLS address family. This enables VPLS.
On the core-facing interfaces, enable MPLS labels. The ISO address is needed as
well on the core-facing interfaces because IS-IS is used in the core.
[edit interfaces]
user@PE2# set ge-2/0/6 vlan-tagging
user@PE2# set ge-2/0/6 encapsulation vlan-vpls
user@PE2# set ge-2/0/6 unit 601 encapsulation vlan-vpls
user@PE2# set ge-2/0/6 unit 601 vlan-id 601
user@PE2# set ge-2/0/6 unit 601 family vpls


2. Enable MPLS and LDP on the interfaces.
On the MTU device interfaces that connect to other PE devices, configure MPLS
and LDP.

[edit protocols ldp ]

3. Enable routing on the interfaces.

On the MTU device interfaces that connect to other PE devices, configure an interior
gateway protocol (IGP), such as OSPF or IS-IS.

user@PE2# set level 1 disable
4. Configure VPLS.
The neighbor 10.255.14.217 statement points to Device PE1’s loopback interface

address.
The VPLS ID must match the virtual circuit ID that is configured on the MTU (Device
PE1).
[edit routing-instances customer]

user@PE2# set instance-type vpls
user@PE2# set protocols vpls vpls-id 601
user@PE2# set protocols vpls neighbor 10.255.14.217 encapsulation-type
ethernet-vlan
5. Configure the router ID.
Results From configuration mode, confirm your configuration by entering the show interfaces,
show protocols, show routing-instances, and show routing-options commands. If the

ge-2/0/5 {
vlan-tagging;
unit 601 {
vlan-id 601;
output-vlan-map swap;
family ccc;
}
}
ge-2/0/10 {
unit 0 {
family inet {
address 192.0.2.2/24;
}
family iso;
family mpls;
}
}
ge-2/0/11 {

unit 0 {
family inet {
address 192.0.2.3/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.14.217/32;
}
family iso {
address 49.0001.0102.5501.4217.00;
}
}
}

mpls {
}
isis {
level 1 disable;
interface lo0.0;
}
ldp {
interface lo0.0;
}
l2circuit {
neighbor 10.255.14.225 {
encapsulation-type ethernet-vlan;
standby;
}
}
}
}

router-id 10.255.14.217;

ge-2/0/6 {
vlan-tagging;
unit 601 {

vlan-id 601;
family vpls;
}
}
ge-2/0/10 {
unit 0 {
family inet {
address 192.0.2.4/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.14.216/32;
}
family iso {
address 49.0001.0102.5501.4216.00;
}
}
}

mpls {
}
isis {
level 1 disable;
interface lo0.0;
}
ldp {
interface lo0.0;
}
user@PE2# show routing-instances

customer {
instance-type vpls;
protocols {
vpls {
vpls-id 601;
neighbor 10.255.14.217 {
encapsulation-type ethernet-vlan;
}
}
}
}

router-id 10.255.14.216;
If you are done configuring the devices, enter commit from configuration mode.

Verification
• Verifying the Layer 2 Circuit on page 1320

• Checking the VPLS Connections on page 1320
• Checking Connectivity on page 1322
• Manually Triggering a Switch from the Active Pseudowire to the Redundant
Pseudowire on page 1322
Verifying the Layer 2 Circuit
Purpose Verify that Layer 2 circuit is operational on the MTU device.
Action From operational mode, enter the show l2circuit connections command.



Up -- operational
Dn -- down
Neighbor: 10.255.14.216
ge-2/0/5.601(vc 601) rmt Up Oct 9 16:28:58 2012 1
Neighbor: 10.255.14.225
ge-2/0/5.601(vc 601) rmt ST
Meaning As expected, the Layer 2 circuit connection to Device PE3 is operational, and the
connection to Device PE2 is in standby mode.
Checking the VPLS Connections
Purpose Verify that the VPLS connections are operational on the PE-r devices.

Action From operational mode, enter the show vpls connections command.


Up -- operational
Dn -- down
Instance: customer
VPLS-id: 601
10.255.14.217(vpls-id 601) rmt Up Oct 9 16:29:02 2012 1
Local interface: vt-2/0/10.84934914, Status: Up, Encapsulation: VLAN
Description: Intf - vpls customer neighbor 10.255.14.217 vpls-id 601





Up -- operational
Dn -- down
Instance: customer
VPLS-id: 601
10.255.14.217(vpls-id 601) rmt Up Oct 9 16:29:02 2012 1
Local interface: vt-2/0/10.68157698, Status: Up, Encapsulation: VLAN
Description: Intf - vpls customer neighbor 10.255.14.217 vpls-id 601
Meaning As expected, the VPLS connections are operational on both PE-r devices.
Checking Connectivity
Purpose Verify that Device CE1 can ping Device CE3.
Action user@CE1> ping 10.255.14.218

PING 10.255.14.218 (10.255.14.218): 56 data bytes
^C
--- 10.255.14.218 ping statistics ---
Meaning The output shows that H-VPLS is operational.
Manually Triggering a Switch from the Active Pseudowire to the Redundant

Pseudowire
Purpose Make sure that the pseudowire between Device PE1 and Device PE2 becomes operational.

Action user@CE1> request l2circuit-switchover virtual-circuit-id 601 neighbor 10.255.14.225

user@CE1> ping 10.255.14.215
PING 10.255.14.215 (10.255.14.215): 56 data bytes
^C
--- 10.255.14.215 ping statistics ---
Meaning The successful ping from Device CE1 to Device CE2 shows that the pseudowire between
Device PE1 and PE2 is operational. Now, if you ping Device CE3 from Device CE1, the ping
should fail.
Related • Application Note: Demystifying H-VPLS

Documentation
• Example: Configuring H-VPLS Without VLANs
• Configuring Redundant Pseudowires for Layer 2 Circuits and VPLS on page 606


PART 9
Monitoring and Troubleshooting ACX

Series Routers
• Diagnosing Cable States Using Time Domain Reflectometry (TDR) on page 1327
• Configuring RFC 2544-Based Benchmarking Tests on page 1335
• Configuring Port, VLAN, and Flow Mirroring on page 1385
• Configuring sFlow Technology on page 1397
• Troubleshooting ACX Series Routers on page 1401


CHAPTER 36
Diagnosing Cable States Using Time

Domain Reflectometry (TDR)
• Time Domain Reflectometry on ACX Series Routers Overview on page 1327

• Diagnosing a Faulty Twisted-Pair Cable on ACX Series Routers on page 1330
Time Domain Reflectometry on ACX Series Routers Overview
Time Domain Reflectometry (TDR) is a technology used for diagnosing copper cable
states. This technique can be used to determine if cabling is at fault when you cannot
establish a link. TDR detects the defects by sending a signal through a cable, and reflecting
it from the end of the cable. Open circuits, short circuits, sharp bends and other defects
in the cable, reflects the signal back, at different amplitudes, depending on the severity
of the defect.
Several factors that result in degraded or low-quality cable plants can cause packet loss,
suboptimal connection speed, reduced network efficiency, and complete connection
failures. These types of problems can occur because of poor cable construction,
identification of pair twists, loose connectors, poor contacts between the points, and
stretched or broken pairs of cables. Broadcom transceivers enable you to analyze the
condition of the cable plant or topology and identify any problems that have occurred.
This functionality is effectively used in the following scenarios:
• Troubleshooting during initial network equipment installation.
• Discovery of failures when network problems occur.
• Maintenance of optimally functioning cable plants.
• Fault determination during the testing of network equipment in production cable

networks.
TDR supports the following capabilities for examination of cable faults on ACX Series
routers:
• Cable status pair (open or short)—When the router operates in Gigabit Ethernet mode,
all the four pairs (8 wires) are used. Only Pair-A and Pair-B are required to operate in
10/100BASE-T Ethernet mode. If either of these required pairs is open or short-circuited,
the transceiver reports the following faults:

• Any open wire
• Wires of a particular pair that are shorted
• Distance to fault per pair—Distance at which an open or a short-circuit is detected in

meters. This measurement is also termed as cable length. The transceiver reports the
following faults:
• Cable length when the cable status is normal
• Distance to fault when the cable status is not normal
• Pair Swap—Swapping of twisted-pairs in straight-through and cross-over cable plants

are detected.
• Polarity Swap—Each cable pair carries a differential signal from one end to the other
end of the cable. Each wire within the pair is assigned a polarity. The wires in a pair are
normally connected in a one-to-one form. This connection enables the transmitter at
one end to be connected to the receiver at the other end with same polarity. Sometimes,
the wiring within the pair is also swapped. This type of connection is called polarity
swap. Broadcom transceivers can detect such swapping and automatically adjust the
connection to enable the links to operate normally. However, the transceiver reports
polarity swaps that it detects in the cable plant.
On 4-port Gigabit Ethernet and 8-port Gigabit Ethernet MICs with copper SFP transceivers
(using BCM54880) and 4-port Gigabit Ethernet, 6-port Gigabit Ethernet, and 8-port
Gigabit Ethernet MICs with copper and optical SFP transceivers (using BCM54640E
PHY), only 10BASE-T pair polarity is supported. 100BASE-T and 1000BASE-T polarities
are not supported.
When the Gigabit Ethernet link cannot be established (for example, if only two pairs are
present that are fully functional), TDR in the physical layer (PHY) brings down the link
to a 100 MB link, which is called a downshift in the link. The physical layer might require
10-20 seconds for the link to come up if a downgrade in wire speed occurs because it
attempts to connect at 1000 MB five times before it falls back to 100BASE-TX.
TDR diagnostics is supported only on copper interfaces and not on fiber interfaces.
Keep the following points in mind when you configure TDR:
• If you connect a port undergoing a TDR test to a Gigabit Ethernet interface that is
enabled to automatically detect MDI (Media Dependent Interface) and MDIX (Media
Dependent Interface with Crossover) port connections, the TDR result might be invalid.
• If you connect a port undergoing a TDR test to a 100BASE-T copper interface, the
unused pairs are reported as faulty because the remote end does not terminate these
pairs.
• You must not modify the port configuration while the TDR test is running.
• Because of cable characteristics, you need to run the TDR test multiple times to get
accurate results.
• Do not change the port status (such as removing the cable at the near or far end)
because such a change can result in inaccurate statistics in the results.

Chapter 36: Diagnosing Cable States Using Time Domain Reflectometry (TDR)
• While measuring the cable length or distance to fault (per pair), sometimes, a few
cable length inconsistencies might be observed during a TDR test. Broadcom
transceivers have the following cable length limitations:
• For a properly-terminated good cable, the accuracy of the cable length reported is
plus or minus 10 meters.
• If a pair is open or short-circuited, the far-end termination does not affect the
computed result for that pair.
• The accuracy of the measured cable length, when open and short-circuit conditions
are detected, is plus or minus 5 meters.
• The accuracy of a good pair, when one or more pairs are open or short-circuited, is
plus or minus 10 meters.
• Polarity swap detection is supported only in 10BASE-T mode.
• The TDR test does not impact the traffic if the interface operates at 10-Gigabit Ethernet
per second of bandwidth, which is the default configuration. However, if the speed of
the interface is configured to be other than 10-Gigabit Ethernet, running the TDR test
affects the traffic.
TDR diagnostics might bring the link down and initialize the physical layer (PHY) with
default configuration to perform its operation.
When the TDR validation test is completed, the PHY layer resumes operation in the
same manner as before the cable diagnostics test was performed. However, link flaps
might be momentarily observed. We recommend that you run the TDR test at a speed
of 1 gigabit per second, which is the default configuration, to obtain more accurate
results.
TDR is supported on the following interfaces on ACX Series routers:
• On ACX1000 routers, 4 RJ45 (Cu) ports or 8-port Gigabit Ethernet MICs with small
form-factor pluggable (SFP) transceivers and RJ45 connectors.
On ACX1100 routers, 4-port or 8-port Gigabit Ethernet MICs with SFP transceivers and
RJ45 connectors.
• On ACX2000 routers, 8-port Gigabit Ethernet MICs with SFP transceivers and RJ45
connectors.
• On ACX2100 and ACX2200 routers, 4-port Gigabit Ethernet MICs with SFP transceivers
and RJ45 connectors.
• On ACX4000 routers, 4-port, 6-port, or 8-port Gigabit Ethernet MICs with SFP
transceivers and RJ45 connectors.
You must select the media type as copper for the 1-Gigabit Ethernet interfaces. To specify
the media type, include the media-type statement with the copper option at the [edit
interfaces interface-name] hierarchy level. Media type selection is applicable to ports only
in slot 2. When media-type is not set, the port accepts either type of connection. The
media type is fiber if a transceiver is installed in the SFP connection. If no transceiver is
installed, the media type is copper. The COMBO ports (combination ports) on ACX routers

support both the copper and fiber-optic media types. On such ports or interfaces, you
must configure the media type as copper to run the TDR test.
You can run the TDR test from operational mode and view the success or failure results
of the test. To start a test on a specific interface, issue the request diagnostics tdr start
interface interface-name command. To stop the TDR test currently in progress on the
specified interface, issue the request diagnostics tdr abort interface interface-name
command. To display the test results for all copper interfaces, enter the show diagnostics
tdr command. To display the test results for a particular interface, enter the show
diagnostics tdr interface interface-name command.
Related • Diagnosing a Faulty Twisted-Pair Cable on ACX Series Routers on page 1330
Documentation
Diagnosing a Faulty Twisted-Pair Cable on ACX Series Routers
Problem Description: A 10/100BASE-T Ethernet interface has connectivity problems that you
suspect might be caused by a faulty cable.
Solution Use the time domain reflectometry (TDR) test to determine whether a twisted-pair
Ethernet cable is faulty.
The TDR test:
• Detects and reports faults for each twisted pair in an Ethernet cable. Faults detected
include open circuits, short circuits, and impedance mismatches.
• Reports the distance to fault to within 1 meter.
• Detects and reports pair swaps, pair polarity reversals, and excessive pair skew.
The TDR test is supported on the following ACX routers and interfaces:
• On ACX1000 routers, 4 RJ45 (Cu) ports or 8-port Gigabit Ethernet MICs with small
form-factor pluggable (SFP) transceivers and RJ45 connectors.
• On ACX1100 routers, 4-port or 8-port Gigabit Ethernet MICs with SFP transceivers and
RJ45 connectors.
• On ACX2000 routers, 8-port Gigabit Ethernet MICs with SFP transceivers and RJ45
connectors.
• On ACX2100 and ACX2200 routers, 4-port Gigabit Ethernet MICs with SFP transceivers
and RJ45 connectors.
• On ACX4000 routers, 4-port, 6-port, or 8-port Gigabit Ethernet MICs with SFP
transceivers and RJ45 connectors.

NOTE: We recommend running the TDR test on an interface when there is

no traffic on the interface.
TDR diagnostics are applicable for copper ports only and not for optical fiber
ports.
To diagnose a cable problem by running the TDR test:
1. Run the request diagnostics tdr command.
user@host> request diagnostics tdr start interface ge-0/0/10
Interface TDR detail:

Test status : Test successfully executed ge-0/0/10
2. View the results of the TDR test with the show diagnostics tdr command.
user@host> show diagnostics tdr interface ge-0/0/10

Interface name : ge-0/0/10
Test status : Passed
Link status : Down
MDI pair : 1-2
Cable status : Normal
Distance fault : 0 Meters
Polartiy swap : N/A
Skew time : N/A
MDI pair : 3-6
Polartiy swap : N/A
Skew time : N/A
MDI pair : 4-5
Cable status : Open
Polartiy swap : N/A
Skew time : N/A
MDI pair : 7-8
Polartiy swap : N/A
Skew time : N/A
Channel pair : 1
Pair swap : N/A
Channel pair : 2
Pair swap : N/A
Downshift : N/A
3. Examine the Cable status field for the four MDI pairs to determine if the cable has a
fault. In the preceding example, the twisted pair on pins 4 and 5 is broken or cut at
approximately one meter from the ge-0/0/10 port connection.

NOTE: The Test Status field indicates the status of the TDR test, not the
cable. The value Passed means the test completed—it does not mean that
the cable has no faults.
The following is additional information about the TDR test:
• The TDR test can take some seconds to complete. If the test is still running when you
execute the show diagnostics tdr command, the Test status field displays Started. For
example:
user@host> show diagnostics tdr interface ge-0/0/22

Interface name : ge-0/0/22
Test status : Started
• You can terminate a running TDR test before it completes by using the request
diagnostics tdr abort interface interface-name command. The test terminates with no
results, and the results from any previous test are cleared.
• You can display summary information about the last TDR test results for all interfaces
on the router that support the TDR test by not specifying an interface name with the
show diagnostics tdr command. For example:
user@host> show diagnostics tdr

Interface Test status Link status Cable status Max distance fault
ge-0/0/0 Passed UP OK 0
ge-0/0/1 Not Started N/A N/A N/A
ge-0/0/8 Passed Down OK 0
ge-0/0/10 Passed Down Fault 1
ge-0/0/19 Passed Down OK 0

Related • Time Domain Reflectometry on ACX Series Routers Overview on page 1327
Documentation
• request diagnostics tdr
• show diagnostics tdr


CHAPTER 37
Configuring RFC 2544-Based

Benchmarking Tests
• RFC 2544-Based Benchmarking Tests Overview on page 1335

• Layer 2 and Layer 3 RFC 2544-Based Benchmarking Test Overview on page 1338
• Configuring Ethernet Loopback for RFC 2544-Based Benchmarking Tests on page 1355
• RFC 2544-Based Benchmarking Test States on page 1358
• Example: Configuring an RFC 2544-Based Benchmarking Test for Layer 3 IPv4
Services on page 1359
• Example: Configuring an RFC 2544-Based Benchmarking Test for NNI Direction of
Ethernet Pseudowires on page 1367
• Example: Configuring an RFC 2544-Based Benchmarking Test for UNI Direction of
RFC 2544-Based Benchmarking Tests Overview
RFC 2544 defines a series of tests that can be used to describe the performance
characteristics of network interconnecting devices. RFC2544-based benchmarking tests
methodology can be applied to a single device under test (DUT), or a network service
(set of devices working together to provide end-to-end service). When applied to a
service, the RFC2544 test results can characterize the Service-Level-Agreement (SLA)
parameters.
RFC 2544 tests are performed by transmitting test packets from a device that functions
as the generator or the initiator. These packets are sent to a device that functions as the
reflector, which receives and returns the packets back to the initiator.
ACX Series routers support RFC 2544 tests to measure the following:
• Throughput
• Latency
• Frame loss rate
• Back-to-back frames

With embedded RFC 2544, an ACX Series router can be configured as an initiator and
another ACX Series router as a reflector.
NOTE: ACX5048 and ACX5096 routers can be configured only as a reflector.
Figure 69 on page 1336 shows the components, role of intiator and reflector, and the flow
of test packets in an RFC 2544-based benchmarking test.
Figure 69: RFC 2544-Based Benchmarking Test Methodology
To run RFC 2544-based tests, you need a router to generate service test traffic and a
router to reflect the service test traffic back. You need to:
1. Identify two service endpoints between which the RFC2544-based test needs to be
run.
2. Configure the reflector end and start reflection.
3. Configure the initiator end and initiate the test.
4. Review the results after the test is complete. Test results are reported in a specific
format.
In ACX Series routers, you can run the following RFC 2544-based performance
measurement tests:
• Throughput test:
• Sends a specific number of frames at a specified rate from the initiator through the
network service or a DUT. The test starts with a user-configured theoretical maximum
rate.
• Counts the number of transmitted frames and the number of received frames.
• If the number of frames received is less than those transmitted, the test is repeated
with a 50 percent reduced frame rate.

Chapter 37: Configuring RFC 2544-Based Benchmarking Tests
• Throughput is the maximum rate at which the count of test frames received is
equal to the number of test frames transmitted through the network service.
You can repeat throughput tests for different frame sizes.
• Latency test:
NOTE: To run latency test, you need to determine the throughput for DUT
or a network service at each of the specified frame sizes.
• Starts with a stream of frames at a particular frame size through the DUT at the
determined throughput rate.
• Sends an identifying tag in one frame after 60 seconds and calculate the latency
when the frame with the same tag is received by the initiator.
• Is repeated for at least 20 times with the reported latency value being the average
of the recorded values.
You can repeat latency tests for different frame sizes.
• Frame loss rate test:
• Involves sending a specific number of frames at a specified rate through the DUT or
a network service to be tested and counting the frames that are transmitted.
• Calculates frame loss rate at each point using the equation:

( ( input_count - output_count ) x 100 ) / input_count.
• Runs a trial for the frame rate that corresponds to 100 percent of the configured
maximum theoretical rate.
• Is repeated for the frame rate that corresponds to 90 percent of the maximum rate
used and then for 80 percent of the maximum rate until a certain trial result shows
no lost frames.
You repeat the frame loss rate tests for different frame sizes.
• Back-to-back frames test:
• Involves sending a burst of frames with minimum interframe gaps through the DUT
or a network service and counting the number of frames forwarded.
• Is rerun with an increased length of burst frames if the count of transmitted frames
is equal to the number of frames forwarded.
• Is rerun with a reduced length of burst frames if the count of forwarded frames is
less than the number of frames transmitted.
The back-to-back value is the number of frames in the longest burst that the DUT or
a network service can handle without the loss of any frames.
You can repeat back-to-back frame tests for different frame sizes.

NOTE: In ACX Series routers, RFC 2544 tests are supported only for E-LINE,
ELAN, and EVPL services.
ACX5048 and ACX5096 routers supports only E-LINE services. ACX5048

and ACX5096 routers do not support family inet based reflection. Family
bridge and family CCC are supported.
Related • Layer 2 and Layer 3 RFC 2544-Based Benchmarking Test Overview on page 1338
Documentation
• show services rpm rfc2544-benchmarking on page 3156
• show services rpm rfc2544-benchmarking test-id on page 3161
Layer 2 and Layer 3 RFC 2544-Based Benchmarking Test Overview
In ACX Series routers, RFC 2544-based benchmark tests can be run to measure the
performance characteristic of the E-LINE, E-LAN, and EVPL services.
NOTE: ACX5048 and ACX5096 routers supports only E-LINE services.

ACX5048 and ACX5096 routers do not support family inet based reflection.
Family bridge and family CCC are supported.
• You can configure the test on the following underlying services:
• Between two IPv4 endpoints—In this mode, the generator sends test packets to
user-configured IP destination or UDP port (which is of the reflector).
• Between two user-to-network interfaces (UNIs) of Ethernet Virtual Connection

(EVC), Ethernet Private Line (EPL, also called E-LINE), Ethernet Virtual Private Line
(EVPL), EVC (EPL, EVPL)—One end is configured as the generator or initiator and
the other end acts as the reflector. The generator receives the test packets that are
returned from the reflector and computes the test results.
NOTE: Benchmarking tests are not supported for IPv6-based services.
• You cannot perform multiple simultaneous RFC 2544-based benchmarking tests on

the same pseudowire.
• Interoperation of the RFC 2544 benchmarking tests with other third-party customer
premises equipment (CPE) that provides embedded or dedicated benchmarking test
capability is not supported.
• Fragmented test-frames and one-way measurements of frames are not supported.

You must configure one end or the source device to initiate and terminate test frames

and the other end or the destination device to reflect the received frames back to the
initiator.
• RFC 2544 generator and reflector are supported with testing bandwidth up to 1 Gbps.
ACX5048 and ACX5096 routers supports test bandwidth of up to 40 Gbps.
• The test session is supported in out-of-service mode for the underlying service. You
must not transmit any traffic to the UNI port, configured as a generator or a reflector,
that is being tested during the duration of the test. However, other services that are
not configured for the testing session are not impacted.
• Devices embedded with benchmarking test capabilities (generators and reflectors)

interoperate with other Juniper Networks devices that support the RFC 2544-based
generator or reflector functionality.
• RFC 2544 generator traffic undergoes the same traffic classifier and policer or shaper
processing as the ingress customer traffic from the UNI port.
• RFC 2544 generator produces a report with clear details of pass or fail for each critical
testing metric, based on the configured thresholds.
• The testing packets can be configured and the format of the packet depends on the
underlying service on which the test is configured. For IP-based service, the IP or port
values can be configured. For Ethernet-based service, unicast untagged or VLAN
ID-tagged dot1p formats (IEEE 802.1p or packet classification Layer 2 headers) are
supported. The Ethernet destination address and source address that you configured
are used.
• You can run RFC 2544 benchmarking inet tests on Layer 3 VPN or virtual router.
• For an inet service, each test session needs to use a unique UDP port. On the initiator
device, the source UDP port that you specify by using the source-udp-port statement
must be unique and not used by other UDP services that terminate at the initiator. On
the reflector device, the UDP port of the destination to be used in the UDP header for
the generated frames by using the destination-udp-port statement must be unique
and not used by other UDP services that terminate at the reflector.
• You must start the test on the router that operates as the reflector before you start
the test on router that functions as the initiator.
• You must configure the size of the test packet based on the configured MTU of the
packets.
• For computation of the test results for a user-to-network interface (UNI) or ingress
direction of an Ethernet pseudowire service, the customer edge (CE) device that is
configured as a reflector for inet must have the reflected destination address resolved
using ARP or a statically configured route must be present on the CE device to connect
to the initiator.
• For benchmarking tests on the UNI direction of an Ethernet pseudowire service, if

reflection mode is configured, you must configure a static ARP entry. Otherwise, the
tests fail when test frames on the UNI interface are reflected. ARP resolution does not
enable a successful reflection of test frames for UNI interfaces.

• For a CCC family and with the test performed in the egress or network-to-network
interface (NNI) direction, the tests stop on the initiator and reflector when the
pseudowire goes down.
• For an RFC 2544 test that is run in the egress or network-to-network interface (NNI)
direction of an Ethernet service for a CCC family, the ingress features are not applied.
• In ACX5048 and ACX5096 routers, for a CCC family, the pseudowire has to be opened
prior to the start of the RFC 2544 test and during the course of the test.
• The configured packet size denotes the untagged packet size. Any additional VLAN in
the payload causes the packet length to be increased correspondingly.
• For an inet service, if you configure an interface on an initiator for the RFC 2544-based
benchmarking test to be run without specifying the source IPv4 address for the test
frames, the primary IP address of the interface is used for the test frames. If the primary
IP address is not configured, the first IPv4 address of the interface is used. Similarly,
for an unnumbered interface on an initiator on which the RFC 2544 test is run, the
primary or the first IP address of the donor loopback interface is retrieved and used in
the test frames. You must explicitly configure the source IPv4 address for the test
frames by using the source-ipv4-address statement if you want a particular address
to be used.
• RFC 2544 test generates packets for performance benchmarking testing. The packets
can be destined for known or unknown unicast MAC addresses, and they can be either
tagged or untagged frames. UDP/IP packet is used as the frame payload. Refer to
“Configuring RFC 2544-Based Benchmarking Tests” on page 1341 for the frame fields
that can be configured.
• Supported outer TPIDs for tagged frames are 0x8100, 0x88a8, 0x9100, and 0x9200.
• RFC 2544 benchmark tests can be run in out-of-service and in in-service modes.
NOTE: In out-of-service mode, while the test is running, all the data traffic
sent to and from the UNI port under test on the service is interrupted.
Control protocol packets are not interrupted.
In in-service mode, while the test is running, only the data traffic
corresponding to the test session is interrupted, rest of the data traffic flow
sent to and from the UNI port under test on the service are not affected.
Control protocol packets are not interrupted.
• The source MAC address, destination MAC address, and the UNI port under test
configured uniquely identifies the RFC 2544 benchmark test session (or test stream).
• You can run only one test at a time. Multiple simultaneous tests cannot be run at a
time.
• The maximum theoretical test bandwidth supported by ACX Series routers for RFC
2544 test initiator or reflector is 1 Gpbs. On AC5048 and ACX5096 routers, the
maximum theoretical test bandwidth supported for RFC 2544 reflector is 40 Gbps.

• RFC 2544 tests can be run with different frame sizes. In ACX Series routers, the
supported frame sizes are 64, 68, 72, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 1600,
1728, 2496, 3584, 4016, 9104, and 9136 bytes.
• The minimum mandated duration for RFC 2544 benchmark tests to run is 10 seconds.
• The test uses round-trip traffic for performance measurement.
• A history of the test results is stored in memory.
• The test results can be copied to the local file system or a remote file system, optionally.
NOTE: RFC 2544 test is not supported to compute the performance attributes
of multicast or broadcast traffic streams.
Related • RFC 2544-Based Benchmarking Tests Overview on page 1335

Documentation
Configuring RFC 2544-Based Benchmarking Tests
To configure a RFC 2544 benchmark test on an initiator, you must first configure a
test-profile and reference the test-profile in a unique test-name. The test-name defines
the parameters for the tests to be performed.
To configure a test-profile, include the test-profile profile-name statement at the [edit

services rpm rfc2544-benchmarking] hierarchy level. Test profile is applicable only for
initiator.
To configure a test-name, include the test-name test-name statement at the [edit services
rpm rfc2544-benchmarking] hierarchy level.
To configure Ethernet loopback as the test mode on a logical interface, include the
Ethernet-loopback statement at the [edit services rpm rfc2544-benchmarking] hierarchy
level.
NOTE: The test-profile is not required while configuring the reflector for RFC
2544 test.
Table 106 on page 1341 lists the parameters for configuring test-profile at initiator.
Table 106: Parameters for test-profile Configuration

Parameters Description
test-type RFC 2544 test type (throughput | latency | frame-loss | back-back-frames).

Table 106: Parameters for test-profile Configuration (continued)

packet-size Size of the test packet.
The valid packet sizes are 64, 68, 72, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 1600, 1728,
2496, 3584, 4016, 9104, and 9136 bytes.
bandwidth-kbps Define the maximum bandwidth limit, in kilobits per second (kbps).
Range: 1,000 kpbs through 1,000,000 kbps.
step-percent Specify the step percentage for frame-loss tests.
Default: 10 percent
Range: 1 through 100 percent
Table 107 on page 1342 lists the parameters for configuring a test-name at initiator and
reflector.
Table 107: Parameter for test-name configuration

check-test-interface-mtu When the check-test-interface-mtu parameter is configured, the parameter validates the MTU
size of the test packets with the MTU size configured on the interface and the following would be
the behavior for initiator and reflector modes:
• On the initiator, if the MTU size of the test packet is larger than the MTU size configured on the
interface, then the RFC2544-based benchmarking test fails to start.
• On the reflector, if the test packets coming to the reflector does not confirm to the MTU size
configured on the interface, then these test packets do not get reflected and are dropped.
destination-ipv4-address Specify the destination IPv4 address.
This parameter is mandatory when family inet is specified and optional when family ccc is specified.
If a value is not specified, then by default 192.168.1.20 is used.
NOTE: This parameter is not supported on ACX5048 and ACX5096 routers.
destination-mac-address Specify the destination MAC address. For example, 0011.2233.4455.
This parameter cannot be used when family inet is specified.
This parameter is optional when family ccc is specified. If not specified, then the default value of
0x00:0x11:0xAE:0x92:0x2F:0x28 is used.
destination-udp-port Specify the destination UDP port number for the test frames. Default: 4041.
direction Specify the test direction (egress | ingress). This parameter is valid only when family ccc and bridge.
This parameter is mandatory for mode ethernet-loopback

Table 107: Parameter for test-name configuration (continued)

disable-signature-check Disable signature verification on the received test frames.
dscp-code-points Specify the value of the Differentiated Services (DiffServ) field. For example, 001111.
If a value is not specified, then '0' is used in IP header.
family Configure the test family (bridge | ccc | inet).
forwarding-class Specify the forwarding class to be used for test frames.
halt-on-prefix-down If specified, a prefix that moves to the down state causes the corresponding tests to be stopped.
ignore-test-interface-state When the ignore-test-interface-state parameter is configured for RFC2544 benchmarking tests,
the test continues to run even if there are any occurrences of interface up or down events. This is
applicable to both initiator and reflector test modes.
in-service If specified, only the data traffic corresponding to the test session is interrupted, rest of the data
traffic flow sent to and from the UNI port under test on the service are not affected.
ivlan-cfi CFI bit used in the inner VLAN tag.
ivlan-id Configure inner VLAN ID for the test frames.
This parameter is valid only for family ccc mode.
ivlan-priority Configure the priority value for the IEEE 802.1p bit in the inner VLAN tag.
Range: 0 through 7.
mode Specify the test mode (ethernet-loopback, initiate-and-terminate, or reflect).
• ethernet-loopback—Test frames are loopbacked to the measuring device after the source MAC
address and the destination MAC addresses are swapped.
• initiate-and-terminate—Test frames are initiated and terminated at the same end. If you specify
this mode, then a reflector should be configured on the peer end to bring back the test frames.
• reflect—Test frames are reflected on the chosen service.


outer-tag-protocol-id TPID to be used in the outer VLAN tag.
Supported values are 0x8100, 0x88a8, 0x9100, 0x9200.
ovlan-cfi CFI bit used in the outer VLAN tag.
ovlan-id Configure the outer VLAN ID for the test frames.
Range: 0 through 4094
This parameter is valid only for family ccc mode.
ovlan-priority Configure the priority value for the IEEE 802.1p bit in the outer VLAN tag.
Range: 0 through 7
packet-loss-priority Specify the packet loss priority (PLP) value.
If a value is not configured, then the default value of low is used.
reflect-etype Specify the EtherType ID to be used for reflection of test frames. This parameter is valid only in
mode reflect. If not specified, then all EtherTypes are reflected.
Range: 1 through 65,535.
reflect-mode Specify the reflection mode (mac-rewrite | mac-swap | no-mac-swap).
• mac-rewrite—MAC values specified in source-mac-address and destination-mac-address would

be used.
• mac-swap—Swaps the source-mac-adddress and destination-mac-address in the test frame.
This is the default behavior.
• no-mac-swap—Does not swap MAC addresses. Test frames are returned back as-is.
reflector-port Port used to configure reflector functionality for RFC 2544 test. The range of ports that can be
used based on the front panel port number are:
• On ACX5048 [16 through 53]

• On ACX5096 [64 through 95, 100 through 103].
service-type Specify the service type (E-LINE, or E-LAN)


skip-arp-iteration This parameter is valid only in family inet mode. ARP iteration is a 3-second iteration that is run
for all inet tests. The results of ARP iteration are ignored in test result calculations. The primary
use of sending test frames for 3 seconds is to ensure that all devices on the path to destination
build their ARP entries.
source-ipv4-address Specify the source IPv4 address used for the test frames. If a value is not specified for this
parameter, then:
• For family ccc, if a value is not specified, then by default 192.168.1.10 is used.
• For family inet, the source address of the interface is used to send out test frames.
source-mac-address Specify the source MAC address. For example, 0011.2233.4455
This parameter cannot be used when family inet is specified.
This parameter is optional when family ccc is specified. If not specified, then the default value of
0x00:0x60:0x67:0x71:0xC6:0x62 is used.
source-udp-port Specify the source UDP port number for the test frames.
Default: 4040
test-finish-wait-duration Number of seconds to wait after transmitting the last frame and before concluding that the test
as complete.
test-iterator-duration Specify the duration of each iteration in seconds.
Range: 10 through 120 seconds
The default value for test types throughput, back-to-back frames and frame loss rate is 20 seconds.
The default value for test type latency is 120 seconds.
test-interface Specify the name of the logical interface (UNI) on which the test needs to be run.
When you specify the family as inet and mode as initiate-and-terminate the test-interface is ignored,
instead the test is run on egress logical interface that is determined by the route lookup on the
specified destination-ipv4-address.
When you specify the family as inet and mode as reflect, the test-interface is used as the interface
to enable reflection service. If test-interface is not specified, a lookup is performed on the
source-ipv4-address parameter to determine the interface hosting the address.


test-profile Specify the name of the test-profile to be used for the test.
The test-profile parameter is ignored when mode reflect is used.
vlan-cfi CFI bit used in the VLAN tag.
vlan-id Configure the VLAN ID for the test frames.
This parameter is valid only for mode ethernet-loopback.
vlan-priority Configure the VLAN priority value.
Range: 0 through 7.
The following topics describe how to configure a test-profile and a test-name, start and
stop a RFC2544-benchmark test, and copy the test result to a local or a remote file.
• Configuring a Test Profile for an RFC 2544-Based Benchmarking Test on page 1346
• Configuring a Test Name for an RFC 2544-Based Benchmarking Test on page 1348
• Starting and Stopping the RFC 2544-Based Benchmarking Test on page 1354
• Copying an RFC 2544-Based Benchmarking Test Result on page 1354
Configuring a Test Profile for an RFC 2544-Based Benchmarking Test

You can configure a test profile by including the test-profile profile-name statement at
the [edit services rpm rfc2544-benchmarking] hierarchy level. Table 106 on page 1341 lists
the parameters for configuring test-profile.
To configure a test profile:
1. In configuration mode, go to the [edit services] hierarchy level.
[edit]
user@host# edit services
2. Configure an RPM service instance.
[edit services]
user@host# edit rpm
3. Configure an RFC 2544-based benchmarking test for the RPM instance.

[edit services rpm]

user@host# edit rfc2544-benchmarking
4. Define a name for a test profile—for example, profile1.
[edit services rpm rfc2544-benchmarking]

user@host# edit profiles test-profile profile1
5. Define the theoretical maximum bandwidth for the test in kilobits per second, with a
value from 1,000 Kbps through 1,000,000 Kbps. Specify a complete decimal number.
[edit services rpm rfc2544-benchmarking profiles test-profile profile1]

user@host# set bandwidth-kbps kbps
6. Specify the size of the test packet in bytes, with a value from 64 through 9136, to be
used for each test iteration. You can specify up to 10 packet sizes, separated by a
space, that are used sequentially for the test. The valid packet sizes are 64, 68, 72,
128, 256, 512, 768, 1024, 1280, 1518, 1522, 1600, 1728, 2496, 3584, 4016, 9104, and
9136 bytes. If you specify a packet size other than the ones listed here as valid sizes,
the configuration is saved when you commit the setting and no error message is
displayed. However, when you start the test by entering the test services rpm
rfc2544-benchmarking test test-name start command, an error message is displayed
specifying that you configured an invalid packet size in the test profile associated with
the test name.
NOTE:
• The minimum frame size for untagged frames should be 64.
• The minimum frame size for single-tagged frames should be 68.
• The minimum frame size for dual-tagged frames should be 72.
These values are no applicable for inet.

user@host# set packet-size bytes
7. Specify the step percentage for frame-loss tests with a value from 1 through 100. This
parameter is not applicable for other test types.

user@host# set step-percent percent-value
8. Configure the type of test to be performed.
• To configure a throughput test, use the throughput option with the test-type
statement.

user@host# set test-type throughput
• To configure a latency test, use the latency option with the test-type statement.


user@host# set test-type latency
• To configure a frame-loss test, use the frame-loss option with the test-type
statement.

user@host# set test-type frame-loss
• To configure a back-to-back frames test, use the back-back-frames option with the
test-type statement.

user@host# set test-type back-back-frames
Configuring a Test Name for an RFC 2544-Based Benchmarking Test

You can configure a test name by including the test-name test-name statement at the
[edit services rpm rfc2544-benchmarking] hierarchy level.
To configure a test name and define its attributes for initiator:
[edit]
[edit services]
user@host# edit rpm
[edit services rpm]

4. Define a name for the test—for example, test1. The test name identifier can be up to
32 characters in length.

user@host# edit tests test-name test1
5. Configure the destination IPv4 address for the test packets. This parameter is required
only if you configure an IPv4 family inet. This option is not required if you specify circuit
cross-connect (CCC) as the family. If you do not configure the destination IPv4 address,
the default value of 192.168.1.20 is used.
[edit services rpm rfc2544-benchmarking tests test-name test1]

user@host# set destination-ipv4-address address
6. Specify the source MAC address used in generated test frames. This parameter is
effective for a CCC family and it is not applicable for an inet family. If you specify this
parameter for an inet family, a commit error occurs when you commit the configuration.

This parameter is optional for a CCC family. If you do not configure the destination
MAC address, the default value of 0x00:0x60:0x67:0x71:0xC6:0x62 is used.

user@host# set source-mac-address address
7. Specify the destination MAC address used in generated test frames.

user@host# set destination-mac-address address
8. Specify the logical interface on which the RFC 2544-based benchmarking test is run.
This is a local user-to-network interface (UNI) on behalf of which the test frames are
generated when the test direction is egress.

user@host# set test-interface interface-name
9. Specify the family for the benchmarking test.

user@host# set family bridge
10. Specify the test mode for the packets that are sent during the benchmarking test. The
initiate-and-terminate option causes the test frames to be initiated from one end and
terminated at the same end. The initiation and termination mode requires a reflector
to be configured at the peer end to return the test frames from the peer to the
originator. The reflect option causes the test frames to be reflected on the chosen
service (IPv4, Ethernet, or bridge).
• To configure the initiation and termination mode as the test mode on a router, use
the initiate-and-terminate option.

user@host# set mode initiate-and-terminate
• To configure the reflection mode as the test mode on a router, use the reflect option.

user@host# set mode reflect
11. Specify the direction (egress | ingress) of the interface on which the test must be run.
The egress option causes the test to be run in the egress direction of the interface
(traffic sent from user-to-network interface (UNI) toward network-to-network
interface (NNI)). The ingress option causes the test to be run in the ingress direction
of the interface (traffic sent on user-to-network interface (UNI)). You cannot configure
ingress for a bridge family.

user@host# set direction egress
12. Configure the outer VLAN ID for the test frames. This parameter is valid only for a CCC
or an Ethernet pseudowire family.


user@host# set ovlan-id number
13. Configure the inner VLAN ID for the test frames. This parameter is valid only for a CCC
or an Ethernet pseudowire family.

user@host# set ivlan-id number
14. Configure the priority value for the IEEE 802.1p bit in the outer VLAN tag. The priority
value is configured when the UNI interface is dual-tagged.

user@host# set ovlan-priority value
15. Configure the priority value for the IEEE 802.1p bit in the inner VLAN tag. This
configuration is optional.

user@host# set ivlan-priority value
16. Configure the CFI value for the outer VLAN tag. This configuration is optional.

user@host# set ovlan-cfi value
17. Specify the source IPv4 address to be used in generated test frames. This parameter
is optional for both CCC and inet families. If you do not configure the
source-ipv4-address for an inet family, the source address of the interface is used to
transmit the test frames. If you do not configure the source-ipv4-address for a CCC
family, the default value of 192.168.1.10 is used.

user@host# set source-ipv4-address address
18. Specify the destination IPv4 address to be used in generated test frames.

19. Specify the source UDP port to be used in the UDP header for the generated frames.
If you do not specify the UDP port, the default value of 4040 is used.

user@host# set source-udp-port port-number
20. Specify the destination UDP port to be used in the UDP header for the generated
frames. If you do not specify the UDP port, the default value of 4041 is used.

user@host# set destination-udp-port port-number

21. Specify the value of the Differentiated Services (DiffServ) field within the IP header
of the test frames. The DiffServ code point (DSCP) bits value must be set to a valid
6-bit pattern. If you do not specify this value, 0 is used in the DSCP fields in the IP
header.

user@host# set dscp-code-points dscp-code-bits
22. Configure the address type family for the benchmarking test. The inet option indicates
that the test is run on an IPv4 service. The ccc option indicates that the test is run on
an CCC or Ethernet pseudowire service. The direction statement that you configured
in Step 11 specifies the direction (ingress or egress) to be used for the test.

user@host# set family inet
23. Specify the forwarding class to be used for test frames. The forwarding class specifies
the manner in which the test frames are processed by the Packet Forwarding Engine
of the router. If you do not configure this parameter, test frames are treated as
best-effort traffic.

24. Specify the halt-on-prefix-down option to enable a prefix that moves to the down
state to cause the corresponding tests to be stopped. The show command output for
the test displays that the test was aborted because the prefix went down. By default,
the RFC 2544-based benchmarking test ignores a prefix-down event (when the prefix
associated with the test goes down) and continues to run.

user@host# set halt-on-prefix-down
25. Specify the duration of each iteration in seconds. If you configure this value, the default
value of each iteration depends on the type of test being run. For throughput, bursty
or back-back-frames, and frame-loss types of tests, the default value is 20 seconds.
For latency tests, the default value is 120 seconds.

user@host# set test-iterator-duration seconds
26. Specify the name of the test profile to be associated with a particular test name. You
must have previously configured the profile by using the test-profile profile1 statement
at the [edit services rpm rfc2544-benchmarking] hierarchy level. The test profile is
required when the test mode is configured as initiation and termination. The test-profile
profile1 parameter is disregarded when the test mode is configured as reflection. A
reflection service does not use the parameters specified in the test profile because
the reflection service uses the same parameters for the test frames as the received
test frames when it returns the frames to the initiator.

user@host# set test-profile profile1

To configure a test name and define its attributes for reflector:
NOTE: In ACX5048 and ACX5096 routers, while performing RFC 2544

benchmark test, you must ensure that there are no configurations associated
with the reflector port.
[edit]
[edit services]
user@host# edit rpm
[edit services rpm]

4. Define a name for the test—for example, test1. The test name identifier can be up to
32 characters in length.

5. Specify the test mode for the packets that are sent during the benchmarking test. The
reflect option causes the test frames to be reflected back to the intiator end..

6. Specify the family for the benchmarking test.

user@host# set family bridge
7. Specify the direction (egress | ingress) of the interface on which the test must be run.
The egress option causes the test to be run in the egress direction of the interface
(traffic sent from user-to-network interface (UNI) toward network-to-network
interface (NNI)). The ingress option causes the test to be run in the ingress direction
of the interface (traffic sent on user-to-network interface (UNI)). You cannot configure
ingress for a bridge family.

user@host# set direction egress
8. Configure the destination IPv4 address for the test packets. This parameter is required
only if you configure an IPv4 family inet. This option is not required if you specify circuit

cross-connect (CCC) as the family. If you do not configure the destination IPv4 address,
the default value of 192.168.1.20 is used.

9. Specify the source MAC address used in generated test frames. This parameter is
effective for a CCC family and it is not applicable for an inet family. If you specify this
parameter for an inet family, a commit error occurs when you commit the configuration.
This parameter is optional for a CCC family. If you do not configure the destination
MAC address, the default value of 0x00:0x60:0x67:0x71:0xC6:0x62 is used.

user@host# set source-mac-address address
10. Specify the destination MAC address used in generated test frames.

user@host# set destination-mac-address address
11. Specify the logical interface on which the RFC 2544-based benchmarking test is run.
This is a local user-to-network interface (UNI) on behalf of which the test frames are
generated when the test direction is egress.

user@host# set test-interface interface-name
12. Specify the service type as E-LINE or E-LAN.

user@host# set service-type eline | elan
13. Specify the forwarding class to be used for test frames. The forwarding class specifies
the manner in which the test frames are processed by the Packet Forwarding Engine
of the router. If you do not configure this parameter, test frames are treated as
best-effort traffic.

14. Configure the address type family for the benchmarking test. The inet option indicates
that the test is run on an IPv4 service. The ccc option indicates that the test is run on
an CCC or Ethernet pseudowire service. The direction statement that you configured
in Step 7 specifies the direction (ingress or egress) to be used for the test.

15. Specify the EtherType to be used for reflection of the test frames, which is a two-octet
field in an Ethernet frame that defines the protocol encapsulated in the frame payload.
This parameter is valid only if you configured the test mode to be a reflector. If you do
not configure this parameter, all EtherTypes are reflected. Use an EtherType value

that matches the EtherType value set on the customer premises equipment (CPE)
to which your router connects. The EtherType value appears in the Ethernet type field
of the packet. It specifies the protocol being transported in the Ethernet frame. This
is an optional parameter.

user@host# set reflect-etype ethertype-value
16. Specify the reflection mode for the benchmarking test. This configuration is optional.

user@host# set reflect-mode (mac-swap | no-mac-swap)
You can configure one of the following reflection modes:
• mac-rewrite—Enable rewriting of the MAC address on the reflected frames. The

MAC addresses specified in the source-mac-address and destination-mac-address
options are used.
• mac-swap—Swaps the source and destination MAC addresses in the test frame.
This is the default behavior.
NOTE: In ACX5048 and ACX5096 routers, mac-swap is not supported

in reflection mode.
• no-mac-swap—Does not swap the source and destination MAC addresses in the
test frame. The frame is returned to the originator without any modification to the
MAC addresses.
Starting and Stopping the RFC 2544-Based Benchmarking Test

To start an RFC 2544-based benchmarking test, issue the run test services rpm
rfc2544-benchmarking test test-name start CLI command.
To stop an RFC 2544-based benchmarking test, issue the run test services rpm
rfc2544-benchmarking test test-name stop CLI command.
To start an RFC 2544 benchmarking inet tests on Layer 3 VPN or virtual router, issue the
run test services rpm rfc2544-benchmarking test test-name routing-instance
routing-instance-name start CLI command.
To stop an RFC 2544 benchmarking inet tests on Layer 3 VPN or virtual router, issue the
run test services rpm rfc2544-benchmarking test test-name routing-instance
routing-instance-name stop CLI command.
Copying an RFC 2544-Based Benchmarking Test Result

You can copy the RFC 2544-based benchmarking test results to a local or a remote file.
• To copy test results to a local file, use the run show services rpm rfc2544-benchmarking
test-id number detail | save rfc-2544-test-result-session-id-number CLI command.

• To copy test results to a remote file, use the run show services rpm
rfc2544-benchmarking test-id number detail | save
ftp://username:password@sftpchannel.example.com/rfc-2544-test-result-session-id-number

Documentation
Configuring Ethernet Loopback for RFC 2544-Based Benchmarking Tests
Ethernet loopback is a feature that you can use for verifying the connectivity and identifying
or isolating faults in a network.
On ACX Series routers, Ethernet loopback is supported on the egress user-to-network

interfaces (UNIs) direction for a bridge family configuration. In ACX Series routers, Ethernet
loopback is configured on the logical interfaces. The Ethernet loopback feature can be
used in performance measurements where packets are looped back to the measuring
device for testing various services.
Figure 70: Testing End-to-End Service in Ethernet Loopback Mode
Figure 70 on page 1355 shows a scenario where UNI-B interface is configured in Ethernet
loopback mode in the egress direction. The packets received on the network-to-network
interface (NNI) of the ACX Series router are forwarded to the UNI-B interface and looped
back at the UNI-B interface after the source and destination MAC addresses are swapped.
This is a use case for testing an end-to-end service.
You can use the following optional parameters to identify an egress traffic flow for
Ethernet loopback:
• Source MAC address
• Destination MAC address
• Source IPv4 address
• Destination IPv4 address
• VLAN
• VLAN .1p priority
• EtherType
• Test iterator duration

While performing RFC2544 benchmarking tests, configure Ethernet loopback as the test
mode on a logical interface by including the Ethernet-loopback CLI statement at the [edit
services rpm rfc2544-benchmarking] hierarchy level.
If you configure Ethernet loopback on logical interfaces without configuring any of the
optional parameters, then any unknown unicast traffic in the same bridge domain also
gets looped back and does not get forwarded to other logical interfaces while the test
is being performed.
When an RFC2544 benchmarking test is being performed, if the test-iterator-duration

parameter is not configured, then Ethernet loopback continues until the test is completed
or aborted.
NOTE: When performing RFC2544 benchmarking tests, you can configure

the test in initiator, reflector, or loopback mode. You cannot perform the
RFC2544 benchmarking tests in a combination of these test modes.
The following is a sample Ethernet loopback configuration:

tests {
test-name test1{
source-mac-address 00:bb:cc:dd:ee:ff;
destination-mac-address 00:11:22:33:44:55;
vlan-id 100;
vlan-priority 2;
vlan-cfi 1;
ip-swap;
udp-tcp-port-swap;
packet-loss-priority medium-high;
mode ethernet-loopback;
family bridge;
reflect-etype 2048;
direction egress;
source-udp-port 2020;
destination-udp-port 3030;
test-iterator-duration 50;
test-interface ge-0/1/6.0;
}
}
[edit interfaces]
ge-0/1/4 {
unit 0 {
vlan-id 1000;
family bridge {
filter {
input ft1;
}

}
}
ge-0/1/6 {
unit 0 {
vlan-id 100;
input-vlan-map {
push;
vlan-id 1000;
}
output-vlan-map pop;
}
}
ppm {
traceoptions {
file ppmd size 100m;
flag packet;
flag event;
flag distribute;
flag pipe;
flag all;
}
}
[edit firewall]
family bridge {
filter ft1 {
term t1 {
from {
user-vlan-id 100;
}
then count loopback;
}
}
}
bd1 {
}

Documentation
• RFC 2544-Based Benchmarking Test States on page 1358
• Example: Configuring an RFC 2544-Based Benchmarking Test for Layer 3 IPv4 Services
on page 1359
• Example: Configuring an RFC 2544-Based Benchmarking Test for NNI Direction of


• Example: Configuring an RFC 2544-Based Benchmarking Test for UNI Direction of

RFC 2544-Based Benchmarking Test States
When you trigger an RFC 2544-based benchmarking test, it passes through a series of
states. These states are displayed in the Test state field in the brief or detailed output of
the show services rpm rfc2544-benchmarking command. The following are the names of
the states through which the test progresses after it is initiated:
1. RFC2544_TEST_STATE_START_REQUEST—This is the first state that all the triggered

tests enter. When a test enters this state, the state denotes that a request has been
sent to a Packet Forwarding Engine to start the test.
2. RFC2544_TEST_STATE_START_FAILED—This state indicates that the test failed to

start. This state occurs when the Packet Forwarding Engine responds to the
START_REQUEST message. The Status field of the brief or detailed output of the
show command displays a reason for the failure. When a test enters this state, it is
categorized as an aborted test.
3. RFC2544_TEST_STATE_RUNNING—This state occurs if the Packet Forwarding Engine

is able to successfully start the test. This state indicates that the test is in progress.
You can use the output of the show command to learn additional information about
the test progress.
4. RFC2544_TEST_STATE_STOP_REQUEST—A test enters this state when you use the

test services rpm rfc2544-benchmarking test-id stop command. A request is sent to
the Packet Forwarding Engine to stop the test.
5. RFC2544_TEST_STATE_STOP_FAILED—This state is entered when the Packet

Forwarding Engine failed to stop a test after it received the STOP_REQUEST message.
The Status field displays further information regarding the exact reason for failure.
6. RFC2544_TEST_STATE_STOPPED—This state is entered when the Packet Forwarding

Engine successfully managed to stop a test when it received the STOP_REQUEST
message.
7. RFC2544_TEST_STATE_COMPLETED—This state is entered when the test successfully

completes all necessary test steps.
8. RFC2544_TEST_STATE_ABORTED_TIMEOUT—When a request is sent to the Packet

Forwarding Engine for any test, a 10-second timer control is started. If a response is
not received from the Packet Forwarding Engine and the timer elapses, the test is
transitioned to the ABORTED_TIMEOUT state. This state is introduced to prevent a
test from indefinitely waiting to receive a reply from the Packet Forwarding Engine.
9. RFC2544_TEST_STATE_RUNTIME_ERROR—This state is entered if the Packet

Forwarding Engine encounters an error when the test is running. The Status field of
the brief or detailed output specifies the reason for the failure. Tests that encounter
the RUNTIME_ERROR state are added to the count of the aborted-tests category,
which can be viewed from the output of the show services rpm rfc2544-benchmarking
command.


Documentation
Example: Configuring an RFC 2544-Based Benchmarking Test for Layer 3 IPv4 Services
This example shows how to configure the benchmarking test for a Layer 3 IPv4 service.
NOTE: This example is not applicable for ACX5048 and ACX5096 routers.

• Verifying the Results of the Benchmarking Test for Layer 3 IPv4 Services on page 1366
Requirements
Overview
Consider a sample topology in which a router, Router A, functions as an initiator and
terminator of the test frames for an RFC 2544-based benchmarking test. Router A is
connected over a Layer 3 network to another router, Router B, which functions as a
reflector to reflect back the test frames it receives from Router A. IPv4 is used for
transmission of test frames over the Layer 3 network. This benchmarking test is used to
compute the IPv4 service parameters between Router A and Router B. Logical interfaces
on both the routers are configured with IPv4 addresses to measure the performance
attributes, such as throughput, latency, frame loss, and bursty frames, of network devices
for the IPv4 service.
Figure 71 on page 1360 shows the sample topology to perform an RFC 2544 test for a Layer
3 IPv4 service.

Figure 71: RFC 2544-Based Benchmarking Test for a Layer 3 IPv4 Service
Configuration
In this example, you configure the benchmarking test for a Layer 3 IPv4 service that is
between interface ge-0/0/0 on Router A and interface ge-0/0/4 on Router B to detect
and analyze the performance of the interconnecting routers. You need not configure a
test profile on Router B because it operates as a reflector.
• Configuring Benchmarking Test Parameters on Router A on page 1361

• Configuring Benchmarking Test Parameters on Router B on page 1363
level:
Configuring
Benchmarking Test
Parameters on Router
A

set rfc2544-benchmarking profiles test-profile throughput test-type throughput
set rfc2544-benchmarking profiles test-profile throughput packet-size 64
set rfc2544-benchmarking profiles test-profile throughput test-duration 20m
set rfc2544-benchmarking profiles test-profile throughput bandwidth-kbps 500
set rfc2544-benchmarking tests test-name test1 test-profile throughput
set rfc2544-benchmarking tests test-name test1 interface ge-0/0/0.1
set rfc2544-benchmarking tests test-name test1 mode initiate-and-terminate
set rfc2544-benchmarking tests test-name test1 family inet
set rfc2544-benchmarking tests test-name test1 dest-address 200.0.0.2
set rfc2544-benchmarking tests test-name test1 udp-port 4001
Configuring
Benchmarking Test
B

set services rpm rfc2544-benchmarking tests test-name test1 interface ge-0/0/4.1

set services rpm rfc2544-benchmarking tests test-name test1 mode reflect

set services rpm rfc2544-benchmarking tests test-name test1 family inet
set services rpm rfc2544-benchmarking tests test-name test1 dest-address 200.0.0.1
set services rpm rfc2544-benchmarking tests test-name test1 udp-port 4001
Configuring Benchmarking Test Parameters on Router A
To configure the test parameters on Router A:
[edit]
2. Configure the interface on which the test must be run.
[edit interfaces]
user@host# edit ge-0/0/0

user@host# edit unit 0 family inet
4. Specify the address for the logical interface.

5. Enter the up command to go the previous level in the configuration hierarchy.

user@host# up
6. Go to the top level of the configuration command mode.
[edit interfaces ge-0/0/0 unit 0]

user@host# top
[edit]
8. Configure a real-time performance monitoring service (RPM) instance.
[edit services]
user@host# edit rpm

[edit services rpm]

10. Define a name for a test profile—for example, throughput.

user@host# edit profiles test-profile throughput
11. Configure the type of test to be performed as throughput.
[edit services rpm rfc2544-benchmarking profiles test-profile throughput]

12. Specify the size of the test packet as 64 bytes.

user@host# set test-type packet-size 64
13. Specify the period—for example, 20 minutes—for which the test is to be performed
in hours, minutes, or seconds by specifying a number followed by the letter h (for
hours), m (for minutes), or s (for seconds), respectively.

user@host# set test-type test-duration 20m
14. Define the theoretical maximum bandwidth for the test in kilobits per second, with
a value from 1,000 Kbps through 1,000,000 Kbps.

user@host# set test-type bandwidth-kbps 500

user@host# up
[edit services rpm rfc2544-benchmarking profiles]

user@host# up
17. Define a name for the test—for example, test1. The test name identifier can be up
to 32 characters in length.

18. Specify the name of the test profile—for example, throughput—to be associated
with a particular test name.

user@host# set test-profile throughput
19. Specify the logical interface, ge-0/0/0.1, on which the RFC 2544-based
benchmarking test is run.

user@host# set test-interface ge-0/0/0.1
20. Specify the test mode for the packets that are sent during the benchmarking test
as initiation and termination.

21. Configure the address type family, inet, for the benchmarking test.

22. Configure the destination IPv4 address for the test packets.

user@host# set dest-address 200.0.0.2
23. Specify the UDP port of the destination to be used in the UDP header for the
generated frames as 4001.

user@host# set udp-port 4001
24. Start the benchmarking test on the initiator.
user@host> test services rpm rfc2544-benchmarking test test1 start
After the test is successfully completed, it is automatically stopped at the initiator.
Configuring Benchmarking Test Parameters on Router B
To configure the test parameters on Router B:
[edit]
[edit interfaces]

3. Configure a logical unit and specify the protocol family as inet.



user@host# up

user@host# top
[edit]
[edit services]
user@host# edit rpm
[edit services rpm]



12. Specify reflect as the test mode for the packets that are sent during the
benchmarking test.


14. Configure the destination IPv4 address for the test packets as 200.0.0.1.


16. Start the benchmarking test on the reflector.
user@host> test services rpm rfc2544-benchmarking test test1 start
After the test is successfully completed at the initiator, you can stop the test at the
reflector by entering the test services rpm rfc2544-benchmarking test test1 start
command.
Results
In configuration mode, confirm your configuration on Router A and Router B by entering

the show command. If the output does not display the intended configuration, repeat
the configuration instructions in this example to correct it.
Configuring Benchmarking Test Parameters on Router A:
[edit interfaces]
ge-0/0/0 {
unit 0 {
family inet {
address 200.0.0.1/24;
}
}
}
[edit services rpm]

rfc2544-benchmarking {
profiles {
test-profile throughput {
test-type throughput
packet-size 64;
test-duration 20m;
bandwidth-kbps 500;
}
}
tests {

test-name test1 {
test-profile throughput;
mode initiate,terminate;
family inet;
dest-address 200.0.0.2
udp-port 4001;
}
}
}
Configuring Benchmarking Test Parameters on Router B:
[edit interfaces]
ge-0/0/4 {
unit 0 {
family inet {
address 200.0.0.2/24;
}
}
}
[edit services rpm]

# Note, When in reflector mode, test profile is not needed
tests {
test-name test1 {
mode reflect;
family inet;
dest-address 200.0.0.1;
udp-port 4001;
}
}
}
Verifying the Results of the Benchmarking Test for Layer 3 IPv4 Services
Examine the results of the benchmarking test that is performed on the configured service
between Router A and Router B.
• Verifying the Benchmarking Test Results on page 1366
Verifying the Benchmarking Test Results
Purpose Verify that the necessary and desired statistical values are displayed for the benchmarking
test that is run on the configured service between Router A and Router B.
Action In operational mode, enter the run show services rpm rfc2544-benchmarking (aborted-tests
| active-tests | completed-tests | summary) command to display information about the

results of each category or state of the RFC 2544-based benchmarking test, such as
aborted tests, active tests, and completed tests, for each real-time performance
monitoring (RPM) instance.
Meaning The output displays the details of the benchmarking test that was performed. For more
information about the run show ptp clock operational command, see show services rpm
rfc2544-benchmarking in the CLI Explorer.
Related • Configuring RFC 2544-Based Benchmarking Tests on page 1341

Documentation
• rfc2544-benchmarking on page 1698
• profiles on page 1678
• tests on page 1749
Example: Configuring an RFC 2544-Based Benchmarking Test for NNI Direction of

Ethernet Pseudowires
This example shows how to configure the benchmarking test for a network-to-network
interface (NNI) direction of an Ethernet pseudowire service.

• Verifying the Results of the Benchmarking Test for NNI Direction of an Ethernet
Pseudowire Service on page 1374
Requirements
Overview
Consider a sample topology in which a router, Router A, functions as an initiator and
terminator of the test frames for an RFC 2544-based benchmarking test. Router A
operates as a provider edge device, PE1, which is connected to a customer edge device,
CE1, on one side and over an Ethernet pseudowire to another router, Router B, which
functions as a reflector to reflect back the test frames it receives from Router A. Router
B operates as a provider edge device, PE2, which is the remote router located at the other
side of the service provider core. The UNI direction of CE1 is connected to the NNI direction

of PE1. An MPLS tunnel connects PE1 and PE2 over the Ethernet pseudowire or the
Ethernet line (E-LINE).
This benchmarking test is used to compute the performance attributes in the

network-to-network interface (NNI) direction of an Ethernet pseudowire service between
Router A and Router B. The logical interface under test on Router A is the CE1 interface
with UNI as the direction, and the logical interface under test on Router B is the CE2
interface with NNI as the direction. Data traffic arriving from UNI towards NNI is ignored
while the test is in progress. Packets from NNI are not sent toward the customer edge
because all packets are assumed to be test frames. The CCC family and NNI direction
are configured on routers A and B.
Figure 72 on page 1368 shows the sample topology to perform an RFC 2544 test for the
NNI direction of an Ethernet pseudowire service.
Figure 72: RFC 2544-Based Benchmarking Test for NNI Direction of an

Ethernet Pseudowire
Configuration
In this example, you configure the benchmarking test for the NNI direction of an Ethernet
pseudowire service that is enabled between two routers to detect and analyze the
performance of the interconnecting routers.

level:
Configuring
Benchmarking Test
A


set services rpm rfc2544-benchmarking profiles test-profile throughput test-type
throughput
set services rpm rfc2544-benchmarking profiles test-profile throughput packet-size 64
set services rpm rfc2544-benchmarking profiles test-profile throughput test-duration 20
set services rpm rfc2544-benchmarking profiles test-profile throughput bandwidth-kbps
500
set services rpm rfc2544-benchmarking tests test-name test1 test-profile throughput
set services rpm rfc2544-benchmarking tests test-name test1 mode initiate,terminate
set services rpm rfc2544-benchmarking tests test-name test1 family ccc
set services rpm rfc2544-benchmarking tests test-name test1 direction nni
Configuring
Benchmarking Test
B

set services rpm rfc2544-benchmarking tests test-name test1 reflector-port 25
set services rpm rfc2544-benchmarking tests test-name test1 mode family ccc
set services rpm rfc2544-benchmarking tests test-name test1 direction uni
Mode.
[edit]
[edit interfaces]
3. Configure VLAN tagging for transmission and reception of 802.1Q VLAN-tagged

frames.

user@host# set vlan-tagging
4. Configure a logical unit for the interface.


5. Specify the encapsulation for Ethernet VLAN circuits.

user@host# set encapsulation vlan-ccc
6. Configure the VLAN ID on the logical interface.

user@host# set vlan-id 101

user@host# top
[edit]
[edit services]
user@host# edit rpm
[edit services rpm]




14. Specify the period—for example, 20 minutes—for which the test is to be performed
in hours, minutes, or seconds by specifying a number followed by the letter h (for
hours), m (for minutes), or s (for seconds).

a value from 1 Kbps through 1,000,000 Kbps.


user@host# up

user@host# up




22. Configure the address type family, ccc, for the benchmarking test.

23. Specify the direction of the interface on which the test must be run, which is NNI in
this example.

user@host# set direction nni

Mode.
[edit]
[edit interfaces]

frames.



6. Configure the VLAN ID on the logical interface.


user@host# top
[edit]
[edit services]
user@host# edit rpm

[edit services rpm]



benchmarking test.


15. Specify the direction of the interface on which the test must be run, which is NNI in
this example.

user@host# set direction nni
Results

[edit interfaces]
ge-0/0/0 {
vlan-tagging;
unit 0 {
vlan-id 101;
}
}
[edit services rpm]


profiles {
packet-size 64;
test-duration 20m;
bandwidth-kbps 500;
}
}
tests {
test-name test1 {
family ccc;
direction nni;
}
}
}
[edit interfaces]
ge-0/0/4 {
vlan-tagging;
unit 0 {
vlan-id 101;
}
}
[edit services rpm]

tests {
test-name test1 {
mode reflect;
family ccc;
direction nni;
}
}
}
Verifying the Results of the Benchmarking Test for NNI Direction of an Ethernet Pseudowire
Service

information about the run show services rpm rfc2544-benchmarking operational command,
see show services rpm rfc2544-benchmarking in the CLI Explorer.

Documentation
Example: Configuring an RFC 2544-Based Benchmarking Test for UNI Direction of

Ethernet Pseudowires
This example shows how to configure the benchmarking test for the user-to-network
interface (UNI) direction of an Ethernet pseudowire service.

• Verifying the Results of the Benchmarking Test for UNI Direction of an Ethernet
Pseudowire Service on page 1383
Requirements

Overview
Consider a sample topology in which a router, Router A, functions as a reflector of the
test frames for an RFC 2544-based benchmarking test. The logical customer edge
(CE)-facing interface and inet family are configured on Router A. Router A is not part of
a pseudowire and therefore, a Layer 3 family configuration is required on it. Router A,
which is a customer edge device, CE1, is connected to Router B, which functions as a
provider edge device, PE1, over an Ethernet pseudowire in the UNI direction with EtherType
or Layer 2 Ethernet payload. The logical interface, CCC family, and UNI direction are
configured on Router B. Router B or PE1 is connected over an Ethernet pseudowire in the
NNI direction to a provider edge device at the remote site, PE2. The link between CE1 and
PE1 is an Ethernet Layer 2 network and it can be configured with any EtherType value.
The link between PE1 and PE2 is an Ethernet line (E-LINE) or an Ethernet Private Line
(EPL) that has Layer 2 payload and Layer 3 transport sent over it. Router B or PE1 functions
as an initiator and terminator of the test frames that are sent to Router A and reflected
back from it.
This benchmarking test is used to compute the performance attributes in the

user-to-network interface (UNI) direction of an Ethernet pseudowire service between
Router A and Router B. Data traffic arriving from a network-to-network interface (NNI)
toward the customer edge is ignored while the test is in progress. Packets from the CE
are not sent toward the NNI because all packets are assumed to be test probes.
Figure 73 on page 1376 shows the sample topology to perform an RFC 2544 test for the
UNI direction of an Ethernet pseudowire service.
Figure 73: RFC 2544-Based Benchmarking Test for UNI Direction of an

Ethernet Pseudowire

Configuration
In this example, you configure the benchmarking test for the UNI direction of an Ethernet
pseudowire service that is enabled between two routers to detect and analyze the
performance of the interconnecting routers.
• Configuring Benchmarking Test Parameters on Router A on page 1378

level:
Configuring
Benchmarking Test
A

set services rpm rfc2544-benchmarking profiles test-profile throughput test-type
throughput
set services rpm rfc2544-benchmarking profiles test-profile throughput packet-size 64
set services rpm rfc2544-benchmarking profiles test-profile throughput test-duration
20m
set services rpm rfc2544-benchmarking profiles test-profile throughput bandwidth-kbps
500
set services rpm rfc2544-benchmarking tests test-name test1 test-profile throughput
set services rpm rfc2544-benchmarking tests test-name test1 mode initiate,terminate
set services rpm rfc2544-benchmarking tests test-name test1 family inet
set services rpm rfc2544-benchmarking tests test-name test1 dest-address 200.0.0.2
set services rpm rfc2544-benchmarking tests test-name test1 udp-port 4001
Configuring
Benchmarking Test
B

set services rpm rfc2544-benchmarking tests test-name test1 mode family ccc
set services rpm rfc2544-benchmarking tests test-name test1 direction uni

Configuring Benchmarking Test Parameters on Router A
[edit]
[edit interfaces]

frames.

4. Configure a logical unit and specify the protocol family as inet.


6. Configure the VLAN ID on the logical interface as 101.


user@host# top
[edit]
[edit services]
user@host# edit rpm

[edit services rpm]




14. Specify the period for which the test is to be performed in hours, minutes, or seconds
by specifying a number followed by the letter h (for hours), m (for minutes), or s
(for seconds). In this example, you configure the period as 20 minutes.

a value from 1 Kbps through 1,000,000 Kbps.


user@host# up

user@host# up





23. Configure the destination IPv4 address for the test packets as 200.0.0.2.


[edit]
[edit interfaces]

frames.



6. Configure the VLAN ID as 101 on the logical interface.


user@host# top
[edit]
[edit services]
user@host# edit rpm
[edit services rpm]


12. Specify the logical interface on which the RFC 2544-based benchmarking test is
run.

benchmarking test.


15. Specify the direction of the interface on which the test must be run, which is UNI in
this example.

user@host# set direction uni
Results

[edit interfaces]
ge-0/0/0 {
vlan-tagging;
unit 0 {
vlan-id 101;
family inet {
address 200.0.0.1/24;
}
}
}
[edit services rpm]

profiles {
packet-size 64;
test-duration 20m;
bandwidth-kbps 500;
}
}
tests {
test-name test1 {
family inet;
dest-address 200.0.0.2
udp-port 4001;
}
}
}

[edit interfaces]
ge-0/0/4 {
vlan-tagging;
unit 0 {
vlan-id 101;
}
}
[edit services rpm]

tests {
test-name test1 {
mode reflect;
family ccc;
direction uni;
}
}
}
Verifying the Results of the Benchmarking Test for UNI Direction of an Ethernet Pseudowire
Service
information about the run show services rpm rfc2544-benchmarking operational command,
see show services rpm rfc2544-benchmarking in the CLI Explorer.


Documentation

CHAPTER 38
Configuring Port, VLAN, and Flow Mirroring
• Port, VLAN, and Flow Mirroring Overview on page 1385

• Port, VLAN, and Flow Mirroring on ACX5000 Series Routers on page 1386
• Configuring Port, VLAN, and Flow Mirroring on ACX5000 Series Routers on page 1388
Port, VLAN, and Flow Mirroring Overview
Mirroring and analyzers enable you to mirror a copy of a packet to a configured destination,
in addition to the normal processing and forwarding of the packet. Mirroring enables you
to mirror a copy of a packet and an analyzer helps in mirroring a packet based on VLANs.
Mirroring and analyzers are useful for debugging network problems and to prevent attacks
on a network.
Mirroring as a functionality has two components:
• Source—This is the source port or VLAN (based on bridge domain) from where the
packets are mirrored.
• Destination—This is the destination port or VLAN (based on bridge domain) to which

the mirrored packets are sent.
NOTE: The ACX5000 line of routers supports egress mirroring (mirroring of

packets going out through an egress port) only for port-based mirroring.
The ACX5000 line of routers supports the following mirroring modes:
• Port mirroring—Support for both ingress and egress based port mirroring using analyzer
where input to mirror is through a list of ports configured through logical interface. You
need to include the analyzer CLI statement at the [edit forwarding-options] hierarchy
level
• VLAN mirroring—In this mode, packets entering a VLAN (based on bridge domain) are
mirrored. You need to include the analyzer CLI statement at the [edit forwarding-options]
hierarchy level, where input to a mirror is a VLAN (based on bridge domain).
• Flow mirroring—In this mode, input parameters for mirroring are specified through a
firewall filter. You need to include the port-mirror CLI statement at the [edit
forwarding-options] hierarchy level. The ACX5000 line of routers supports only family

ethernet-switching and family inet configurations. If the input is family

ethernet-switching, then output must also be family ethernet-switching. If input is family
inet, then the output must also be family inet with output option as IP address. If you
configure flow-based mirroring without any firewall filter match conditions, then
mirroring is based on logical interface. The ACX5000 line of routers do not support
IPv6, CCC, MPLS, and VPLS family options under the [edit forwarding-options
port-mirroring] hierarchy level.
NOTE:
• In flow-based mirroring, firewall filters can be configured on a logical
interface as well as on a physical interface.
• If the vlan-id option for a VLAN (bridge domain) is not configured, or if the
vlan-id option is configured as none, then the mirrored packet is sent as is
without any additional VLAN tags.
Related • VLAN and Flow Mirroring on ACX5000 Series Routers on page 1386
Documentation
• Configuring VLAN Mirroring on ACX5000 Series Routers
• Configuring Flow Mirroring on ACX5000 Series Routers
• show forwarding-options analyzer
• show forwarding-options port-mirroring
Port, VLAN, and Flow Mirroring on ACX5000 Series Routers
The ACX5000 line of routers supports port, VLAN, and flow mirroring modes to mirror a
copy of a packet from a source port to a destination port.
The ACX5000 line of routers supports the following mirroring modes:
• Port mirroring—In this mode, packets entering to a configured port are mirrored. You
need to include the analyzer CLI statement at the [edit forwarding-options] hierarchy
level, where input to a mirror is through a list of ports configured through the logical
interface

Chapter 38: Configuring Port, VLAN, and Flow Mirroring
NOTE:
• The ACX5000 line of routers supports both ingress and egress mirroring
for the following mirroring modes:
• Flow and VLAN mirroring supports only ingress mirroring.
• Port mirroring supports both ingress and egress mirroring.
• In flow-based mirroring, firewall filters can be configured on a logical

interface as well as on a physical interface.
• If the vlan-id option for a VLAN (bridge domain) is not configured, or if the
vlan-id option is configured as none, then the mirrored packet is sent as is
without any additional VLAN tags.
You need to consider the following limitations before configuring port, VLAN and flow
mirroring on the ACX5000 line of routers:
• The maximum number of port mirror instances supported is four.
• Egress mirroring with firewall filter is not supported for port mirroring.
• When output of mirror is VLAN, then VLAN can have only one member and the mirrored
traffic is sent to that member.
• The rate and maximum-packet-length parameters are not supported.
• Mirroring to multiple destination ports (using next-hop group) is not supported.
• IRB interfaces cannot be configured for mirroring.
• Only eight members per aggregated Ethernet interface are supported for mirroring.
• When both VLAN and flow mirroring matches a packet stream, then flow mirroring
takes the precedence.
• If egress mirroring for a port is configured within a bridge domain, then the mirrored
copy of the packet contains the vlan-only internal. This is applicable for Layer 3 routed
packets.
• Logical tunnel (-lt) interfaces are not supported for port mirroring.
• You can have only one logical interface as output at the [edit forwarding-options
analyzer analyzer-name output] hierarchy level. Adding another logical interface as
output will override the existing logical interface configuration. Mirroring happens at
the physical interface level, even though the configuration is done as a logical interface.
Related • VLAN and Flow Mirroring Overview on page 1385

Documentation
• Configuring VLAN Mirroring on ACX5000 Series Routers
• Configuring Flow Mirroring on ACX5000 Series Routers

• show forwarding-options analyzer
• show forwarding-options port-mirroring
Configuring Port, VLAN, and Flow Mirroring on ACX5000 Series Routers
The ACX5000 line of routers supports the following mirroring modes to mirror a copy of
a packet to a configured destination:
• Port mirroring—In this mode, packets entering to a configured port are mirrored.
This topic describes the various methods to configure port, VLAN, and flow mirroring on
the ACX5000 line of routers.
• Configuring Port Mirroring on ACX5000 Series Routers on page 1388

• Configuring VLAN Mirroring on ACX5000 Series Routers on page 1390
• Configuring Flow Mirroring on ACX5000 Series Routers on page 1392
Configuring Port Mirroring on ACX5000 Series Routers

In the port mirroring mode, packets entering to a configured port are mirrored. You need
to include the analyzer CLI statement at the [edit forwarding-options] hierarchy level,
where the input to a mirror is a list of ports mentioned through a logical interface.
The following are the various methods to configure port mirroring on the ACX5000 line
of routers:
• Configuring the Input as Logical Interface and the Output as Logical Interface on page 1389
• Configuring the Input as a Logical Interface and the Ouput as VLAN on page 1389
• Configuring the Input as Logical Interface and the Output as Next-hop IP
Address on page 1389
• Configuring the Input as Logical Interface and Output as VLAN with the no-tag
Option on page 1390

Configuring the Input as Logical Interface and the Output as Logical Interface
You can configure port mirroring on the ACX5000 line of routers by configuring the input
as logical interface and the output as a logical interface as shown in the following
configuration:
analyzer analyzer-name {
input {
ingress {
interface interface -name or list of interfaces;
}
output {
interface logical-interface-name;
}
}
}
Configuring the Input as a Logical Interface and the Ouput as VLAN
as a logical interface and the output as a VLAN (VLAN name or VLAN ID) as shown in
the following configuration:
input {
ingress {
}
output {
vlan vlan-name;
}
}
}
Configuring the Input as Logical Interface and the Output as Next-hop IP Address
as a logical interface and the output as the next-hop IP address as shown in the following
configuration:
input {
ingress {
}
output {
ip-address ip-address;
}
}

Configuring the Input as Logical Interface and Output as VLAN with the no-tag
Option
as a logical interface and the output as VLAN without any additional VLAN (bridge
domain) tag. Use the no-tag CLI statement as shown in the following configuration:
input {
ingress {
interfaceinterface -name or list of interfaces;
}
output {
vlan vlan-name; {
no-tag;
}
}
}
}
NOTE: In this method, the mirrored packet do not have any VLAN tags
associated with the packets.
Configuring VLAN Mirroring on ACX5000 Series Routers

In the VLAN mirroring mode, packets entering a VLAN (based on bridge domain) are
hierarchy level, where the input to a mirror is a VLAN (based on bridge domain).
The following are the various methods to configure VLAN mirroring on the ACX5000 line
of routers:
• Configuring the Input as VLAN and the Output as Logical Interface on page 1390
• Configuring the Input and the Ouput as VLAN on page 1391
• Configuring the Input as VLAN and the Output as Next-hop IP Address on page 1391
• Configuring the Input as VLAN and Output as VLAN with the no-tag Option on page 1391
Configuring the Input as VLAN and the Output as Logical Interface
You can configure VLAN mirroring on the ACX5000 line of routers by configuring the
input as VLAN (VLAN name or VLAN ID) and the output as a logical interface as shown
in the following configuration:
input {
ingress {
vlan vlan-name;
}

output {
}
}
}
Configuring the Input and the Ouput as VLAN
input as VLAN (VLAN name or VLAN ID) and the output as a VLAN (VLAN name or VLAN
ID) as shown in the following configuration:
input {
ingress {
vlan vlan-name;
}
output {
vlan vlan-name;
}
}
}
Configuring the Input as VLAN and the Output as Next-hop IP Address
input as a VLAN (VLAN name or VLAN ID) and the output as the next-hop IP address as
shown in the following configuration:
input {
ingress {
vlan vlan-name;
}
output {
}
}
}
Configuring the Input as VLAN and Output as VLAN with the no-tag Option
input as a VLAN (VLAN name or VLAN ID) and the output as VLAN without any additional
VLAN (bridge domain) tag. Use the no-tag CLI statement as shown in the following
configuration:
input {
ingress {
vlan vlan-name;
}
output {

vlan vlan-name; {
no-tag;
}
}
}
}
NOTE: In this method, the mirrored packet do not have any VLAN tags
associated with the packets.
Configuring Flow Mirroring on ACX5000 Series Routers

In the flow mirroring mode, input parameters for mirroring are specified through a firewall
filter. You need to include the port-mirroring CLI statement at the [edit forwarding-options]
hierarchy level. The ACX5000 line of routers supports only family ethernet-switching and
family inet configurations.
The following are the various methods to configure flow mirroring on ACX5000 line of
routers:
• Configuring the Family as ethernet-switching and Specifying the Output as Layer 2

Logical Interface on page 1392
• Configuring the Family as ethernet-switching and Specifying the Output as
VLAN. on page 1393
• Configuring the Output as VLAN with the no-tag Option on page 1394
• Configuring the Family as inet and Specifying the Output as Next-Hop IP
Address on page 1395
Configuring the Family as ethernet-switching and Specifying the Output as Layer

2 Logical Interface
You can configure flow mirroring on the ACX5000 line of routers by configuring the family
as ethernet-switching and specifying the output as a Layer 2 logical interface as shown
in the following configuration:
1. Configure the output as logical interface.
port-mirroring {
family ethernet-switching {
output {
}
}
}
2. Configure the firewall filter and specify the action as mirror.
[edit firewall]

term rule-name {
from {
match-conditions;
}
then port-mirror;
}
}
}
3. Attach the firewall filter to the logical interface.
[edit interfaces]
interface-name {
unit interface-unit-number {
filter {
input filter-name;
}
vlan-id number;
}
}
}
Configuring the Family as ethernet-switching and Specifying the Output as VLAN.
as ethernet-switching and specifying the output as a VLAN (VLAN name or VLAN ID) as
shown in the following configuration:
1. Configure the output as VLAN (VLAN name or VLAN ID).
port-mirroring {
output {
vlan vlan-name;
}
}
}
[edit firewall]
term rule-name {
from {
match-conditions;
}
then port-mirror;
}
}
}

3. Attach the firewall filter to the VLAN.
[edit interfaces]
interface-name {
filter {
input filter-name;
}
vlan-id number;
}
}
}
Configuring the Output as VLAN with the no-tag Option
You can configure flow mirroring on the ACX5000 line of routers by configuring the output
as VLAN without any additional VLAN (bridge domain) tag. Use the no-tag CLI statement
as shown in the following configuration:
1. Configure the output as VLAN without any additional VLAN (bridge domain) tag by
using the no-tag CLI statement.
port-mirroring {
output {
vlan vlan-name; {
no-tag;
}
}
}
}
2. Configure the firewall filter and specify the action as mirror or mirroring instance.
[edit firewall]
term rule-name {
from {
match-conditions;
}
then (port-mirror | port-mirror-instance instance-name);
}
}
}
3. Attach the firewall filter to the VLAN.
[edit interfaces]
interface-name {

filter {
input filter-name;
}
vlan-id number;
}
}
}
NOTE: In this method, the mirrored packet does not have any VLAN tags
associated with the packet.
Configuring the Family as inet and Specifying the Output as Next-Hop IP Address
as inet and specifying the output as the next-hop IP address as shown in the following
configuration:
1. Configure the output as the next-hop IP address.
port-mirroring {
family inet {
output {
}
}
}
[edit firewall]
family inet {
term rule-name {
from {
match-conditions;
}
then port-mirror;
}
}
}
3. Attach the firewall filter to the IP address of the packets in the inet family.
[edit interfaces]
interface-name {
vlan-id number;
family inet {
filter {

input filter-name;
}
}
}
}
Related • VLAN and Flow Mirroring Overview on page 1385

Documentation
• VLAN and Flow Mirroring on ACX5000 Series Routers on page 1386

CHAPTER 39
Configuring sFlow Technology
• Overview of sFlow Technology on page 1397

• Configuring sFlow Technology on page 1399
Overview of sFlow Technology
The sFlow technology is a monitoring technology for high-speed switched or routed

networks. sFlow monitoring technology collects samples of network packets and sends
them in a UDP datagram to a monitoring station called a collector. You can configure
sFlow technology on a device to monitor traffic continuously at wire speed on all interfaces
simultaneously. You must enable sFlow monitoring on each interface individually; you
cannot globally enable sFlow monitoring on all interfaces with a single configuration
statement. Junos OS supports the sFlow technology standard described in RFC 3176,
InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed
Networks.
An sFlow monitoring system consists of an sFlow agent embedded in the device and a
central data collector, or sFlow analyzer. The sFlow agent performs packet sampling
and gathers interface statistics, and then combines the information into UDP datagrams
that are sent to the sFlow collectors for analysis. The sFlow agent is responsible for
monitoring the network port, sample all incoming packets including control traffic and
traffic arriving on all the ports in the system. The collector can be connected to one of
the data ports or the management interface.
NOTE: sFlow technology is supported only on the ACX5000 line of routers,

other ACX Series routers do not support this technology.
The following sFlow features are supported on the ACX5000 line of routers:
• Packet-based sampling—Samples one packet out of a specified number of packets

from an interface enabled for sFlow technology. Only the first 128 bytes of each packet
are sent to the collector. Data collected include the Ethernet, IP, and TCP headers,
along with other application-level headers (if present). Although this type of sampling
might not capture infrequent packet flows, the majority of flows are reported over time,
allowing the collector to generate a reasonably accurate representation of network
activity. You configure packet-based sampling when you specify a sample rate.

• Time-based sampling—Samples interface statistics (counters) at a specified interval

from an interface enabled for sFlow technology. Statistics such as Ethernet interface
errors are captured. You configure time-based sampling when you specify a polling
interval.
• Adaptive sampling—Monitors the overall incoming traffic rate on the device and provides
feedback to the interfaces to dynamically adapt their sampling rate to traffic conditions.
NOTE: If you configure sFlow technology monitoring on multiple interfaces

and a high sampling rate, we recommend that you specify a collector that is
on the data network instead of the management network. Having a high
volume of sFlow technology monitoring traffic on the management network
might interfere with other management interface traffic.
The sFlow collector uses the IP address of the sFlow agent to determine the source of
the sFlow data. You can configure the IP address of the sFlow agent to ensure that the
agent ID for the sFlow agent remains constant. If you do not assign an IP address to the
agent, an IP address will be assigned to the agent using the IP address of a configured
interface.
If a particular interface is not configured, the IP address of the next interface in the priority
list is used as the IP address for the agent. Once an IP address is assigned to the agent,
the agent ID is not modified until the sFlow service is restarted. At least one interface has
to be configured for an IP address to be assigned to the agent.
The following sFlow technology limitations apply on ACX5000 line of routers:
• The ingress and egress sampling can be configured only on one of the units under a
physical interface and the sFlow is enabled for the physical interface (port). The sFlow
cannot be enabled if the unit under a physical interface is not configured.
• Egress sampling for Broadcast, Unknown unicast and Multicast (BUM) traffic is not
supported because the source-interface field in the SFlow datagrams cannot be
populated.
• Destination VLAN and Destination Priority fields are not populated in the case of Layer
3 forwarding.
• SFlow sampling is not supported on the output interface of an analyzer.
• SNMP MIB support for SFlow is not available.
• SFlow cannot be enabled on LAG interfaces, however, it can be enabled on LAG member
interfaces individually.
• SFlow cannot be enabled on IRB interfaces.
• SFlow cannot be enabled on logical tunnel (lt-) and LSI interfaces.
Related • Configuring sFlow Technology on page 1399

Documentation

Chapter 39: Configuring sFlow Technology
Configuring sFlow Technology
The sFlow technology is a monitoring technology for high-speed switched or routed

networks. sFlow monitoring technology collects samples of network packets and sends
them in a UDP datagram to a monitoring station called a collector. You can configure
sFlow technology on a device to monitor traffic continuously at wire speed on all interfaces
simultaneously. You must enable sFlow monitoring on each interface individually; you
cannot globally enable sFlow monitoring on all interfaces with a single configuration
statement. Junos OS supports the sFlow technology standard described in RFC 3176,
InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed
Networks.
To configure sFlow features using the CLI:
1. Configure the IP address and UDP port (optional) of at least one collector:
[edit protocols sflow]

user@host# set collector ip-address udp-port port-number
The default UDP port assigned is 6343.
2. Enable sFlow technology on a specific interface:

user@host# set interfaces interface-name
NOTE: You cannot enable sFlow technology on a Layer 3 VLAN-tagged

interface.
You cannot enable sFlow technology on a LAG interface (for example

ae0), but you can enable sFlow technology on the member interfaces of
the LAG (for example, xe-0/0/1).
3. Specify how often (in seconds) the sFlow agent polls all interfaces at the global level:

user@host# set polling-interval seconds
NOTE: Specify 0 if you do not want to poll the interface.
4. Specify the rate at which packets are sampled at the global level. For example,
configuring a number of 1000 sets a sample rate of 1 in 1000 packets.

user@host# set sample-rate number
5. (Optional) You can also configure the polling interval and sample rate at the interface
level:

user@host# set interfaces interface-name polling-interval seconds sample-rate number
NOTE: The interface-level configuration overrides the global configuration

for the specified interface.
You can use the following CLI commands to verify and troubleshoot the configurations:
• show sflow—Display sFlow configuration information.
• show sflow interface—Display the interfaces on which sFlow is enabled and the sampling
parameters for the interface.
• show sflow collector—Display a list of configured sFlow collectors and their properties.
• clear sflow collector statistics—Clear the sample counters for all sFlow collectors.
Related • Overview of sFlow Technology on page 1397

Documentation

CHAPTER 40
Troubleshooting ACX Series Routers
• CT1 and CE1 Interfaces Alarms, Errors, and Defects on page 1401
• Troubleshooting PoE Interfaces on ACX2000 Universal Access Routers on page 1402
• Troubleshooting and Monitoring TCAM Resource in ACX Series Routers on page 1403
CT1 and CE1 Interfaces Alarms, Errors, and Defects
Table 108 on page 1401 lists the ct1 and ce1 media-specific alarms or defects that can
render the interface on ACX Series routers unable to pass packets.
Table 108: CT1 and CE1 Interface Alarms and Error Definitions
Alarm or Error Definitions Structure-Agnostic Interface Type Structure-Aware
AIS Alarm indication signal (blue alarm) ct1 and ce1 interfaces ct1 and ce1 interfac
BEE Block error event N/A ct1 and ce1 interfac
BES Bursty errored seconds N/A ct1 and ce1 interfac
BPV Bipolar violation N/A N/A
CRC Cyclic redundancy check (CRC) N/A ce1 interfaces
CRC Major Major alarm error threshold N/A ce1 interfaces
CRC Minor Minor alarm error threshold N/A ce1 interfaces
CS Controlled slip N/A N/A
ES Errored seconds ct1 and ce1 interfaces ct1 and ce1 interfac
EXZ Excessive zeros N/A N/A
FEBE Far-end block error N/A ct1 and ce1 interfac
LCV Line code violation ct1 and ce1 interfaces ct1 and ce1 interfac
LES Line errored seconds ct1 and ce1 interfaces ct1 and ce1 interfac

Table 108: CT1 and CE1 Interface Alarms and Error Definitions (continued)
Alarm or Error Definitions Structure-Agnostic Interface Type Structure-Aware
LOF Loss of frame ce1 interfaces ct1 and ce1 interfac
LOS Loss of signal ct1 and ce1 interfaces ct1 and ce1 interfac
PCV Path code violation N/A ct1 and ce1 interfac
SEF Severely errored frame N/A ct1 and ce1 interfac
SEFS Severely errored frame seconds N/A ct1 and ce1 interfac
SES Severely errored seconds ct1 and ce1 interfaces ct1 and ce1 interfac
UAS Unavailable seconds ct1 and ce1 interfaces ct1 and ce1 interfac
YLW Yellow alarm N/A ct1 and ce1 interfac
Troubleshooting PoE Interfaces on ACX2000 Universal Access Routers
Problem Description: A Power over Ethernet (PoE) interface is not supplying power to the powered
device.
Solution Check for the items shown in Table 109 on page 1402.
Table 109: Troubleshooting a PoE Interface
Items to Check Explanation

Is interface PoE enabled? Only interfaces ge-0/1/3 and ge-0/1/7 can
function as PoE ports.
Has PoE capability been disabled for that Use the show poe interface command to check
interface? PoE interface status.
Is the cable properly seated in the port socket? Check the hardware.
Does the powered device require more power Use the show poe interface command to check
than is available on the interface? the maximum power provided by the interface.
If the telemetries option has been enabled for Use the show poe telemetries command to
the interface, check the history of power display the history of power consumption.
consumption.
Documentation
• Example: Configuring PoE on ACX2000 Routers on page 144

Chapter 40: Troubleshooting ACX Series Routers
Troubleshooting and Monitoring TCAM Resource in ACX Series Routers
The dynamic allocation of Ternary Content Addressable Memory (TCAM) space in ACX
Series efficiently allocates the available TCAM resources for various filter applications.
In the dynamic TCAM model, various filter applications (such as inet-firewall,
bridge-firewall, cfm-filters, etc.) can optimally utilize the available TCAM resources as
and when required. Dynamic TCAM resource allocation is usage driven and is dynamically
allocated for filter applications on a need basis. When a filter application no longer uses
the TCAM space, the resource is freed and available for use by other applications. This
dynamic TCAM model caters to higher scale of TCAM resource utilization based on
application’s demand. You can use the show and clear commands to monitor and
troubleshoot dynamic TCAM resource usage in ACX Series routers.
NOTE: Applications using the TCAM resource is termed tcam-app in this

document.
Table 110 on page 1403 shows the task and the commands to monitor and troubleshoot
TCAM resources in ACX Series routers
Table 110: Commands to Monitor and Troubleshoot TCAM Resource in ACX Series
How to Command
View the shared and the related applications for a particular show pfe tcam app (list-shared-apps | list-related-apps)
application.
View the number of applications across all tcam stages. show pfe tcam usage all-tcam-stages
View the number of applications using the TCAM resource at a show pfe tcam usage tcam-stage (ingress | egress |
specified stage. pre-egress)
View the TCAM resource used by an application in detail. show pfe tcam usage app <application-name> detail
View the TCAM resource used by an application at a specified stage. show pfe tcam usage tcam-stage (ingress | egress |
pre-egress) app <application-name>
Know the number of TCAM resource consumed by a tcam-app show pfe tcam usage app <application-name>
View the TCAM resource usage errors for all stages. show pfe tcam errors all-tcam-stages detail
View the TCAM resource usage errors for a stage show pfe tcam errors tcam-stage (ingress | egress |
pre-egress)
View the TCAM resource usage errors for an application. show pfe tcam errors app <application-name>
View the TCAM resource usage errors for an application along with show pfe tcam errors app <application-name> shared-usage
its other shared application.
Clear the TCAM resource usage error statistics for all stages. clear pfe tcam-errors all-tcam-stages

Table 110: Commands to Monitor and Troubleshoot TCAM Resource in ACX Series (continued)
How to Command
Clear the TCAM resource usage error statistics for a specified stage clear pfe tcam-errors tcam-stage (ingress | egress |
pre-egress)
Clear the TCAM resource usage error statistics for an application. clear pfe tcam-errors app <application-name>
To know more about dynamic TCAM in ACX Series, see “Dynamic Ternary Content
Addressable Memory Overview” on page 1157.

PART 10
Configuration Statements and

Operational Commands on ACX Series
Routers
• Configuration Statements on page 1407
• Operational Commands on page 1781


CHAPTER 41
Configuration Statements
• access-profile on page 1417

• active on page 1418
• address (Interfaces) on page 1419
• aggregate (Routing) on page 1420
• aggregate (ACX Series) on page 1422
• aggregate-policing (ACX Series) on page 1423
• aggregated-devices on page 1424
• alarm (chassis) on page 1425
• alarm (chassis) on page 1427
• allow-any-vci on page 1428
• announce-interval (Slave Clock) on page 1429
• announce-interval (Master Clock) on page 1430
• as-path (Routing Options) on page 1431
• as-path-compare on page 1433
• asymmetry on page 1434
• asymmetric-hold-time on page 1435
• atm-options on page 1436
• atm-policer (Firewall) on page 1438
• atm-service on page 1439
• auto-export on page 1440
• autoinstallation (ACX Series) on page 1443
• autonomous-system on page 1444
• backup-neighbor on page 1447
• bandwidth-kbps (RFC 2544 Benchmarking) on page 1448
• bandwidth (Tunnel Services) on page 1449
• bits on page 1450
• bpdu-block-on-edge on page 1451

• bpdu-timeout-action on page 1452

• brief on page 1453
• bridge-domains (ACX Series) on page 1455
• bridge-options (ACX Series) on page 1456
• bundle on page 1456
• cdvt on page 1457
• cell-bundle-size on page 1457
• cell-bundle-size on page 1458
• cesopsn-options on page 1459
• classifiers (Definition) on page 1460
• classifiers (Physical Interface) on page 1461
• clear on page 1461
• clock-class-to-quality-level-mapping (ACX Series) on page 1462
• clocking on page 1463
• clock-client (Master Clock) on page 1464
• clock-mode on page 1465
• clock-mode (Chassis Synchronization) on page 1466
• clock-source (PTP Unicast Slave Interface) on page 1467
• color on page 1468
• copy-tos-from-inner-ip-header on page 1469
• copy-ttl-from-inner-ip-header on page 1469
• community (Routing Options) on page 1470
• confederation on page 1472
• continue-network-mode (ACX Series) on page 1473
• convert-clock-class-to-quality-level (ACX Series) on page 1474
• delay-buffer-rate on page 1474
• delete-upon-commit (ACX Series) on page 1475
• delegation-cleanup-timeout on page 1476
• delegation-priority on page 1477
• description (Routing Instances) on page 1478
• destination (Interfaces) on page 1479
• destination-ipv4-address (RFC 2544 Benchmarking) on page 1480
• destination-ipv4-address on page 1481
• destination-port on page 1481
• destination-mac-address (RFC2544 Benchmarking) on page 1482
• destination-udp-port (RFC 2544 Benchmarking) on page 1483
• destination-networks on page 1484

Chapter 41: Configuration Statements
• direction (RFC 2544 Benchmarking) on page 1485

• disable (Interface) on page 1486
• disable (Routing Options) on page 1487
• disable-signature-check (RFC 2544 Benchmarking) on page 1488
• discard on page 1489
• dhcp-relay (ACX Series) on page 1491
• dhcpv6 (DHCPv6 Relay Agent on ACX Series) on page 1493
• domain-id on page 1494
• domain-vpn-tag on page 1495
• domain-type on page 1495
• dscp (CoS Classifiers) on page 1496
• dscp (CoS Interfaces) on page 1496
• dscp (Rewrite Rules on Physical Interface) on page 1497
• dscp-code-points (RFC 2544 Benchmarking) on page 1498
• dscp-ipv6 on page 1500
• dynamic-tunnels on page 1502
• e1-options on page 1503
• e1-options (BITS Interfaces Signal Type) on page 1504
• ethernet-switch-profile (ACX Series) on page 1506
• encapsulation (Logical Interface) on page 1507
• encapsulation (Physical Interface) on page 1511
• esmc-transmit (Chassis Synchronization) on page 1512
• export (Routing Options) on page 1513
• family (RFC 2544 Benchmarking) on page 1514
• family on page 1515
• family inet on page 1516
• family mpls on page 1518
• family multiservice on page 1521
• flow on page 1524
• flow-map on page 1526
• force switch on page 1527
• forwarding-cache (Multicast) on page 1528
• forwarding-class (Interfaces) on page 1528
• forwarding-class (RFC 2544 Benchmarking) on page 1529
• forwarding-table on page 1530
• fragment-threshold on page 1531

• framing on page 1532

• framing (E1 Options for BITS Interfaces) on page 1533
• framing (T1 Options for BITS Interfaces) on page 1534
• full on page 1534
• generate on page 1535
• gigether-options (ACX Series) on page 1536
• global-arp-prefix-limit (Host Fast Reroute) on page 1537
• global-mac-limit on page 1538
• global-mac-table-aging-time on page 1539
• global-no-mac-learning on page 1540
• global-supplementary-blackout-timer (Host Fast Reroute) on page 1541
• gps (Chassis Synchronization Source) on page 1542
• graceful-restart (Enabling Globally) on page 1543
• grant-duration on page 1544
• gre (Routing Options) on page 1545
• group (Origin Validation for BGP) on page 1546
• halt-on-prefix-down (RFC 2544 Benchmarking) on page 1547
• hash-key (Forwarding Options) on page 1548
• hold-interval (Chassis Synchronization) on page 1551
• host-fast-reroute on page 1552
• hybrid (ACX Series) on page 1553
• ieee-802.1 (Classifier on Physical Interface) on page 1554
• ieee-802.1 (Rewrite Rules on Physical Interface) on page 1554
• igmp on page 1555
• ima-group-options on page 1557
• ima-link-options on page 1559
• independent-domain on page 1560
• inline-services (PIC level) on page 1561
• inet-precedence (CoS Classifiers) on page 1562
• inet-precedence (Classifier on Physical Interface) on page 1563
• inet-precedence (Rewrite Rules on Physical Interface) on page 1563
• inet6-vpn on page 1564
• ingress (Chained Composite Next Hop) on page 1565
• input (Chassis Alarm Relay) on page 1566
• input-relay (Alarm Relay Output Port) on page 1567
• in-service (RFC2544 Benchmarking) on page 1568
• interface on page 1569

• interface-mac-limit on page 1570

• interface (Master Clock) on page 1572
• interface (PTP Slave) on page 1573
• interface-routes on page 1574
• interface-type on page 1576
• interfaces (CoS) on page 1577
• interfaces bits (Chassis Synchronization) on page 1579
• interfaces (Chassis Synchronization Source) on page 1580
• ipv4-dscp on page 1581
• ip-swap (RFC 2544 Benchmarking) on page 1581
• ivlan-cfi (RFC 2544 Benchmarking) on page 1582
• ivlan-id (RFC 2544 Benchmarking) on page 1582
• ivlan-priority (RFC 2544 Benchmarking) on page 1583
• l3vpn on page 1584
• label-switched-path-template (Multicast) on page 1586
• link-protection (Host Fast Reroute) on page 1587
• local-gateway (IPSec) on page 1587
• local-ip-address (PTP Slave Clock Source) on page 1588
• logical-interface-policer on page 1589
• lsp-external-controller on page 1590
• mac-table-size on page 1591
• management on page 1594
• manual (Master Clock) on page 1595
• manual switch on page 1596
• martians on page 1597
• master on page 1599
• match-direction (Services NAT) on page 1600
• max-announce-interval on page 1601
• max-burst-size on page 1602
• max-delay-response-interval on page 1603
• max-sync-interval on page 1604
• max-unknown-messages on page 1605
• maximum-paths on page 1606
• maximum-prefixes on page 1608
• med-igp-update-interval on page 1610
• media-type (Dual-Purpose Uplink Ports) on page 1611

• metric (Aggregate, Generated, or Static Route) on page 1612

• message-rate-limit on page 1613
• min-announce-interval on page 1614
• min-delay-response-interval on page 1615
• min-sync-interval on page 1616
• minimum-links on page 1617
• mld on page 1618
• mode (Chassis Alarm Relay Input and Output) on page 1619
• mode (Interfaces) on page 1620
• mode (RFC 2544 Benchmarking) on page 1621
• mrru on page 1622
• mtu on page 1623
• multicast (Virtual Tunnel in Routing Instances) on page 1627
• multicast-mode (PTP Master and Slave Interfaces) on page 1628
• multilink-max-classes on page 1629
• multilink-class on page 1630
• multipath (Routing Options) on page 1631
• native-vlan-id on page 1632
• network-option on page 1634
• no-bfd-triggered-local-repair on page 1635
• no-mac-learning on page 1636
• no-local-switching on page 1637
• no-local-switching (VPLS) on page 1638
• no-partition on page 1639
• no-root-port on page 1640
• no-vrf-advertise on page 1641
• no-vrf-propagate-ttl on page 1642
• oam-liveness on page 1643
• oam-period on page 1644
• options (Routing Options) on page 1645
• output (Chassis Alarm Relay) on page 1646
• outer-tag-protocol-id (RFC 2544 Benchmarking) on page 1646
• overrides (DHCP Relay Agent) for ACX on page 1647
• ovlan-cfi (RFC 2544 Benchmarking) on page 1648
• ovlan-id (RFC 2544 Benchmarking) on page 1648
• packet-action on page 1649
• ovlan-priority (RFC 2544 Benchmarking) on page 1652

• packet-loss-priority (RFC 2544 Benchmarking) on page 1652

• packet-size (RFC 2544 Benchmarking) on page 1653
• partition on page 1654
• passive (Routing Options) on page 1654
• pce on page 1655
• pcep on page 1657
• pce-group (PCE) on page 1658
• pce-group (Protocols PCEP) on page 1659
• pce-type on page 1660
• peak-rate on page 1661
• pim on page 1662
• policing-action on page 1666
• policy (Aggregate and Generated Routes) on page 1667
• port (Alarm Relay Input) on page 1668
• port (Alarm Relay Output) on page 1669
• ppm on page 1670
• ppp-options on page 1672
• preference (Routing Options) on page 1674
• primary (Virtual Tunnel in Routing Instances) on page 1676
• priority-hold-time on page 1677
• profiles (RFC 2544 Benchmarking) on page 1678
• protect core on page 1679
• protection-group on page 1680
• promiscuous-mode on page 1682
• propagate-settings on page 1683
• priority (Chassis Synchronization Source) on page 1684
• psn-vci (ATM CCC Cell-Relay Promiscuous Mode VPI/VCI Swapping) on page 1685
• psn-vpi (ATM CCC Cell-Relay Promiscuous Mode VPI/VCI Swapping) on page 1686
• quality-level (Chassis Synchronization Source Interface) on page 1687
• quality-level (Clock Class Mapping PTP Slave) on page 1689
• quality-mode-enable on page 1690
• querier (performance-monitoring) on page 1691
• receive-failure-threshold (RFC 2544 Benchmarking) on page 1692
• relay (Chassis Alarm) on page 1693
• request (Chassis Synchronization Source) on page 1694
• rewrite-rules (Physical Interfaces) on page 1695
• reflect-etype (RFC 2544 Benchmarking) on page 1696

• reflect-mode (RFC2544 Benchmarking) on page 1697

• rib (General) on page 1699
• rib-group (Routing Options) on page 1701
• rpf-check (interfaces) on page 1702
• route-distinguisher-id on page 1703
• route-record on page 1704
• router-id on page 1705
• routing-options on page 1706
• rule (Services NAT) on page 1707
• selection-mode (Chassis Synchronization) on page 1709
• service-set (Services) on page 1710
• service-filter (Interfaces) on page 1712
• service-filter (Firewall) on page 1713
• service-package (ACX Series) on page 1714
• service-type (RFC2544 Benchmarking) on page 1715
• satop-options (Physical Interface) on page 1716
• service-plane-recovery (Inline Services) on page 1717
• short-sequence on page 1718
• signal-type (BITS Interfaces) on page 1719
• slave (ACX Series) on page 1720
• source (Chassis Synchronization) on page 1721
• source-address (Routing Options) on page 1722
• skip-arp-iteration (RFC 2544 Benchmarking) on page 1723
• source-ipv4-address (RFC 2544 Benchmarking) on page 1724
• source-mac-address (RFC2544 Benchmarking) on page 1725
• source-udp-port (RFC 2544 Benchmarking) on page 1726
• source-routing on page 1727
• speed (10-Gigabit Ethernet) on page 1728
• standby on page 1729
• static-mac on page 1730
• stateful (ACX Series) on page 1731
• static (Protocols Layer 2 Circuit) on page 1732
• static (Origin Validation for BGP) on page 1733
• step-percent (RFC 2544 Benchmarking) on page 1734
• sustained-rate on page 1735
• switchover-mode on page 1736

• sync-interval (Slave) on page 1737

• sync-interval (Master) on page 1738
• synchronization (ACX Series) on page 1739
• system-defaults on page 1740
• tag (Routing Options) on page 1741
• t1-options on page 1742
• t1-options (BITS Interfaces Signal Type) on page 1743
• temperature (Alarm Relay Output) on page 1743
• test-finish-wait-duration (RFC 2544 Benchmarking) on page 1744
• test-interface (RFC 2544 Benchmarking) on page 1744
• test-iterator-duration (RFC 2544 Benchmarking) on page 1745
• test-iterator-pass-threshold (RFC 2544 Benchmarking) on page 1745
• test-name (RFC 2544 Benchmarking) on page 1746
• test-profile (RFC 2544 Benchmarking) on page 1747
• test-type (RFC 2544 Benchmarking) on page 1748
• tests (RFC 2544 Benchmarking) on page 1749
• timeslots on page 1750
• timestamp-format (RFC 2544 Benchmarking) on page 1750
• tos on page 1751
• traceoptions on page 1752
• traceoptions (PCE) on page 1755
• traceoptions (Protocols PCEP) on page 1757
• traffic-control-profiles on page 1758
• translation-type on page 1759
• transport ipv4 (PTP Unicast Master and Slave Interface) on page 1761
• transport 802.3 (PTP Multicast Master and Slave) on page 1762
• transmit-failure-threshold (RFC 2544 Benchmarking) on page 1763
• trigger (Chassis Alarm Relay Input) on page 1763
• ttl on page 1764
• ttl on page 1764
• tunnel-services (Chassis) on page 1765
• udp-tcp-port-swap (RFC 2544 Benchmarking) on page 1766
• unicast (Virtual Tunnel in Routing Instances) on page 1767
• unicast-mode (Master Clock) on page 1768
• unicast-mode (PTP Slave Interface) on page 1769
• unicast-reverse-path on page 1770
• update-rate-limit on page 1771

• validation (Origin Validation for BGP) on page 1772

• vci on page 1773
• vlan-id (Bridge Domain in ACX Series) on page 1774
• vpi (Logical Interface and Interworking) on page 1775
• vpi (ATM CCC Cell-Relay Promiscuous Mode) on page 1776
• vpi (Define Virtual Path) on page 1777
• vrf-propagate-ttl on page 1778
• vrf-table-label on page 1779
• wait-to-restore (Chassis Synchronization Source) on page 1780

access-profile
Syntax access-profile profile-name;
Hierarchy Level [edit],

[edit forwarding-options dhcp-relay dual-stack-group dual-stack-group-name],
[edit forwarding-options dhcp-relay group group-name]
[edit forwarding-options dhcp-relay dhcpv6 group group-name]
[edit logical-systems logical-system-name routing-instances routing-instance-name]
[edit interfaces interface-name auto-configure vlan-ranges],
[edit interfaces interface-name auto-configure stacked-vlan-ranges],
[edit routing-instances routing-instances-name]
[edit system services dhcp-local-server group group-name]
[edit system services dhcp-local-server dhcpv6]
[edit system services dhcp-local-server dhcpv6 group group-name]
[edit system services dhcp-local-server dual-stack-group dual-stack-group-name]
Release Information Statement introduced in Junos OS Release 9.1.

Statement introduced in Junos OS Release 12.3 for ACX Series routers.
Description After you have created the access profile that specifies authentication and accounting
parameters, you must specify where the profile is used. Authentication and accounting
will not run unless you specify the profile. You can attach access profiles globally at the
[edit] hierarchy level, or you can apply them to DHCP clients or subscribers, VLANs, or
to a routing instance.
Options profile-name—Name of the access profile that you configured at the [edit access profile
name] hierarchy level.
Required Privilege access—To view this statement in the configuration.

Level access-control—To add this statement to the configuration.
Related • Attaching Access Profiles

Documentation
• Attaching Access Profiles to DHCP Subscriber Interfaces or DHCP Client Interfaces
• Configuring Access Components for the DHCP Layer 3 Wholesale Network Solution
• Configuring Access Components for the PPPoE Wholesale Network Solution

active
Syntax (active | passive);
Hierarchy Level [edit logical-systems logical-system-name routing-instances routing-instance-name

routing-options (aggregate | generate | static) (defaults | route)],
[edit logical-systems logical-system-name routing-instances routing-instance-name
routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)],
[edit logical-systems logical-system-name routing-options (aggregate | generate | static)
(defaults | route)],
[edit logical-systems logical-system-name routing-options rib routing-table-name (aggregate |
generate | static) (defaults | route)],
[edit routing-instances routing-instance-name routing-options (aggregate | generate | static)
[edit routing-instances routing-instance-name routing-options rib routing-table-name
(aggregate | generate | static) (defaults | route)],
[edit routing-options (aggregate | generate | static) (defaults | route)],
[edit routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)]
Release Information Statement introduced before Junos OS Release 7.4.

Statement introduced in Junos OS Release 9.0 for EX Series switches.
Statement introduced in Junos OS Release 11.3 for the QFX Series.
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series.
Description Determine whether static, aggregate, or generated routes are removed from the routing
and forwarding tables when they become inactive. Static routes are only removed from
the routing table if the next hop becomes unreachable. This can occur if the local or
neighbor interface goes down. Routes that have been configured to remain continually
installed in the routing and forwarding tables are marked with reject next hops when they
are inactive.
• active—Remove a route from the routing and forwarding tables when it becomes
inactive.
• passive—Have a route remain continually installed in the routing and forwarding tables
even when it becomes inactive.
Include the active statement when configuring an individual route in the route portion of
the static statement to override a passive option specified in the defaults portion of the
statement.
Default active
Required Privilege routing—To view this statement in the configuration.

Level routing-control—To add this statement to the configuration.
Related • Example: Summarizing Static Routes Through Route Aggregation

Documentation

• Example: Configuring a Conditional Default Route Policy
address (Interfaces)
Syntax address address {

destination address;
}
Hierarchy Level [edit interfaces interface-name unit logical-unit-number family inet],

[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number
family inet]
Description Configure the interface address.
Options address—Address of the interface.
The remaining statements are explained separately. See CLI Explorer.
Required Privilege interface—To view this statement in the configuration.

Level interface-control—To add this statement to the configuration.
Related • Junos OS Network Interfaces Library for Routing Devices for other statements that do
Documentation not affect services interfaces.
• Configuring the Links in a Multilink or Link Services Bundle
• Junos OS Network Interfaces Library for Routing Devices

aggregate (Routing)
Syntax aggregate {
defaults {
... aggregate-options ...
}
policy policy-name;
... aggregate-options ...
}
}

routing-options],
routing-options rib routing-table-name],
[edit logical-systems logical-system-name routing-options],
[edit logical-systems logical-system-name routing-options rib routing-table-name],
[edit routing-instances routing-instance-name routing-options],
[edit routing-instances routing-instance-name routing-options rib routing-table-name],
[edit routing-options],
[edit routing-options rib routing-table-name]

Description Configure aggregate routes.
Options aggregate-options—Additional information about aggregate routes that is included with

the route when it is installed in the routing table. Specify zero or more of the following
options in aggregate-options. Each option is explained separately.
• active(— Removes inactive routes from the forwarding table.
• passive— Retains inactive routes in the forwarding table.
• as-path <as-path> <origin (egp | igp | incomplete)> <atomic-aggregate>

<aggregator as-number ip-address>;
• (brief | full);
• community [ community-ids ];
• discard;
• (metric | metric2 | metric3 | metric4) value <type type>;
• (preference | preference2 | color | color2) preference <type type>;
• tag metric type number;

defaults—Specify global aggregate route options. These options only set default attributes
inherited by all newly created aggregate routes. These are treated as global defaults
and apply to all the aggregate routes you configure in the aggregate statement. This
part of the aggregate statement is optional.
route destination-prefix—Configure a nondefault aggregate route:
• default—For the default route to the destination. This is equivalent to specifying an IP

address of 0.0.0.0/0.
• destination-prefix/prefix-length—destination-prefix is the network portion of the IP

address, and prefix-length is the destination prefix length.
The policy statement is explained separately.


Documentation

aggregate (ACX Series)
Syntax aggregate global
Hierarchy Level [edit firewall policer policer-name if-exceeding]
Release Information Statement introduced in Junos OS Release 12.3X54 for ACX Series Routers.
Description Define an aggregate policer as a single parent policer across all the child policer instances
in the system. A single instance of the policer is created system-wide.
You must then link or associate the child policers to the parent or aggregate policer by
specifying at each child policer by using the aggregate-policing aggregate-policer-name
statement at the [edit firewall policer policer-name if-exceeding] hierarchy level. This step
is additional, from the procedure to create a single-level policer, to configure a hierarchical
policer.
Options global—Indicates that the aggregate policer is a parent and applicable globally throughout
the system.
Required Privilege firewall—To view this statement in the configuration.

Level firewall-control—To add this statement to the configuration.

Documentation

aggregate-policing (ACX Series)
Syntax aggregate-policing {
policer policer-name {
aggregate-sharing-mode (peak | guarantee | hybrid);
}
}
Hierarchy Level [edit firewall policer policer-name if-exceeding]

[edit firewallthree-color-policer policer-name two-rate]
Release Information Statement introduced in Junos OS Release 12.3X54 for ACX Series Routers.
Description Define a child or micro policer and the mode of hierarchical policing for the child policer.
You can configure a normal policer as a child policer or a two-rate three-color policer as
a child policer. You can also define the mode of policing as hybrid, peak, or guarantee.
An aggregate parent policer must be configured to attach or group all child policers
defined with the parent policer that is globally applicable throughout the system.
Options aggregate-policing—Defines the child or micro policer for an aggregate parent policer.
policer policer-name—Name that identifies the policer. The name can contain letters,
numbers, and hyphens (-), and can be up to 255 characters long. To include spaces
in the name, enclose it in quotation marks (“ ”).
aggregate-sharing mode guarantee—Enables bandwidth-guarantee mode, which is used

when the micro-flow policer is used to specify that a portion of the aggregate parent
policer bandwidth is guaranteed for its micro-flow. When this micro-flow contains
no traffic, then amount allocated for this micro-flow out of the aggregate bandwidth
is used by the other micro-flows that are transmitting traffic with a size-limit or
bandwidth that is higher than their respective guaranteed bandwidth rates.
aggregate-sharing mode peak—Enables peak mode, also called bandwidth-protection

mode, which is used when the micro-flow policer is used to specify the maximum
amount of the aggregate parent policer bandwidth that the micro-flow can use. This
mode is used to protect a given micro-flow from starving the other flows. Even when
the other micro-flows contain no traffic (the available aggregate bandwidth rate is
greater than the rate of the particular micro-flow, the micro-flow cannot use more
than the rate configured on its micro-flow policer.
aggregate-sharing mode hybrid—Enables hybrid mode for hiearchical policing, which is a

combination of the bandwidth-guarantee and bandwidth-protection modes, enables
the capabilities of bandwidth restriction and the per-flow bandwidth moderation to
be accomplished simultanouesly. Bandwidth-guarentee or bandwidth-restriction
mode controls the guaranteed rates for a given micro-flow. However, it does not
adminster or manage the manner in which the excess aggregate bandwidth can be
shared among the micro-flows. A certain micro-flow can potentially use all the
excess aggregate bandwidth starving the other micro-flows of any excess bandwidth.

NOTE: You can configure hybrid mode for two-rate three-color policers
only.


Documentation
aggregated-devices
Syntax aggregated-devices {
ima {
device-count number;
}
}
Hierarchy Level [edit chassis fpc slot-number pic slot-number]
Release Information Statement introduced in Junos OS Release 12.2 for ACX Series routers.
Description Configure the number of aggregated Inverse Multiplexing ATM (IMA) group interfaces
created on channelized CT1 or CE1 interfaces. The IMA group interface name format is
at-fpc/pic/port with the port number taken from the last port on the MIC plus 1. For
example, on the ACX2000 router with a 16-port built-in T1/E1 TDM MIC, the IMA group
interface numbering starts with at-0/0/16 and increments by 1 to at-0/0/17, and so on.
On the ACX1000 router with an 8-port built-in TDM MIC, the IMA group interface
numbering starts with at-0/0/8 and increments by 1 to at-0/0/9, and so on

Related • ATM IMA Configuration Overview

Documentation
• Configuring ATM IMA

alarm (chassis)
Syntax alarm {
interface-type {
alarm-name (ignore |red | yellow);
}
}
relay
input {
port port-number {
trigger (ignore | red | yellow);
}
}
output{
port port-number {
input-relay input-relay;
temperature;
}
}
Hierarchy Level [edit chassis],
Release Information Statement introduced in Junos OS Release 12.3 for the ACX Series Routers.
Description Configure the chassis alarms and whether they trigger a red or yellow alarm, or whether
they are ignored. Red alarm conditions light the RED ALARM LED on either the router’s
craft interface or the switch’s LCD screen and trigger an audible alarm if one is connected
to the contact on the craft interface or LCD screen. Yellow alarm conditions light the
YELLOW ALARM LED on either the router’s craft interface or the switch’s LCD screen and
trigger an audible alarm if one is connected to the craft interface or LCD screen.
To configure more than one alarm, include multiple alarm-name lines.
Options alarm-name—Alarm condition. For a list of conditions, see System-Wide Alarms and Alarms
for Each Interface Type.
ignore—The specified alarm condition does not set off any alarm.
interface-type—Type of interface on which you are configuring the alarm: atm, ethernet,
t1, or e1.
red—The specified alarm condition sets off a red alarm.
yellow—The specified alarm condition sets off a yellow alarm.



Documentation

alarm (chassis)
Syntax alarm {
interface-type {
alarm-name (ignore |red | yellow);
}
}
Hierarchy Level [edit chassis],

[edit chassis interconnect-device name],
[edit chassis node-group name]

Statement introduced in Junos OS Release 12.2 for the ACX Series.
Description Configure the chassis alarms and whether they trigger a red or yellow alarm, or whether
they are ignored. Red alarm conditions light the RED ALARM LED on either the router’s
craft interface or the switch’s LCD screen and trigger an audible alarm if one is connected
to the contact on the craft interface or LCD screen. Yellow alarm conditions light the
YELLOW ALARM LED on either the router’s craft interface or the switch’s LCD screen and
trigger an audible alarm if one is connected to the craft interface or LCD screen.
To configure more than one alarm, include multiple alarm-name lines.
Options alarm-name—Alarm condition. For a list of conditions, see System-Wide Alarms and Alarms
for Each Interface Type.
ignore—The specified alarm condition does not set off any alarm.
interface-type—Type of interface on which you are configuring the alarm: atm, ethernet,
sonet, or t3.
red—The specified alarm condition sets off a red alarm.
yellow—The specified alarm condition sets off a yellow alarm.

Related • Understanding Alarms

Documentation
• Chassis Conditions That Trigger Alarms
• Chassis Alarm Messages on a QFX3500 Device
• Interface Alarm Messages

allow-any-vci
Syntax allow-any-vci;
Hierarchy Level [edit interfaces interface-name unit 0],

[edit logical-systems logical-system-name interfaces interface-name unit 0]

Statement introduced in Junos OS Release 12.2 for the ACX Series Universal Access
routers.
Description Dedicate entire ATM device to ATM cell relay circuit.

Related • Configuring an ATM1 Cell-Relay Circuit Overview

Documentation

announce-interval (Slave Clock)
Syntax announce-interval announce-interval-value
Hierarchy Level [edit protocols ptp slave]
Description Specify the rate of announce messages that a Precision Time Protocol (PTP) slave
requests from the master during a unicast-negotiation session. The announce interval
is configured on the slave.
NOTE: The configuration of the announce-interval statement is effective only

when the unicast-negotiation statement is also configured at the [edit
protocols ptp] hierarchy level.
Options announce-interval-value—Announce interval value for the announce messages.

Range: 0 through 3
Default: 1


announce-interval (Master Clock)
Syntax announce-interval announce-interval-value;
Hierarchy Level [edit protocols ptp master]
Release Information Statement introduced in Junos OS Release 12.3 for ACX Series Routers.
Description Configure the logarithmic mean interval for the announce messages to be sent by the
2
master. This is a log value, which means that announce messages are requested to be
sent every two seconds.
Options announce-interval-value—Announce interval value for announce messages.

Range: 0 through 4
Default: 1


Documentation

as-path (Routing Options)
Syntax as-path <as-path> <aggregator as-number ip-address> <atomic-aggregate> <origin (egp |

igp | incomplete)>;

routing-options (aggregate | generate | static) (defaults | route)],
routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)],
[edit logical-systems logical-system-name routing-options (aggregate | generate | static)
generate | static) (defaults | route)],
[edit routing-instances routing-instance-name routing-options (aggregate | generate | static)
(aggregate | generate | static) (defaults | route)],
[edit routing-options (aggregate | generate | static) (defaults | route)],
[edit routing-options rib routing-table-name (aggregate | generate | static) (defaults | route)]

Description Associate BGP autonomous system (AS) path information with a static, aggregate, or
generated route.
In Junos OS Release 9.1 and later, the numeric range for the AS number is extended to
provide BGP support for 4-byte AS numbers as defined in RFC 4893, BGP Support for
Four-octet AS Number Space. 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. RFC 4893 also introduces a reserved, well-known, 2-byte AS number, AS
23456. This reserved AS number is called AS_TRANS in RFC 4893. All releases of Junos
OS support 2-byte AS numbers.
In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the
AS-dot notation format of two integer values joined by a period: <16-bit high-order value
in decimal>.<16-bit low-order value in decimal>. For example, the 4-byte AS number
of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format.
You can specify a value in the range from 0.0 through 65535.65535 in AS-dot notation
format.
Default No AS path information is associated with static routes.
Options aggregator—(Optional) Attach the BGP aggregator path attribute to the aggregate route.
You must specify the last AS number that formed the aggregate route (encoded as

two octets) for as-number, followed by the IP address of the BGP system that formed
the aggregate route for ip-address.
as-path—(Optional) AS path to include with the route. It can include a combination of

individual AS path numbers and AS sets. Enclose sets in brackets ( [ ] ). The first AS
number in the path represents the AS immediately adjacent to the local AS. Each
subsequent number represents an AS that is progressively farther from the local AS,
heading toward the origin of the path. You cannot specify a regular expression for
as-path. You must use a complete, valid AS path.
atomic-aggregate—(Optional) Attach the BGP atomic-aggregate path attribute to the

aggregate route. This path attribute indicates that the local system selected a less
specific route instead of a more specific route.
origin egp—(Optional) BGP origin attribute that indicates that the path information
originated in another AS.
origin igp—(Optional) BGP origin attribute that indicates that the path information
originated within the local AS.
origin incomplete—(Optional) BGP origin attribute that indicates that the path information
was learned by some other means.


Documentation
• Using 4-Byte Autonomous System Numbers in BGP Networks Technology Overview

as-path-compare
Syntax as-path-compare;

routing-options multipath],
[edit routing-instances routing-instance-name routing-options multipath]

Description Specify to have the algorithm that is used to determine the active path compare the AS
numbers in the AS path. In a VPN scenario with multiple BGP paths, the algorithm selects
as the active path the route whose AS numbers match. By default, the algorithm evaluates
only the length and not the contents of the AS path.

Related • Configuring the Algorithm That Determines the Active Route to Evaluate AS Numbers
Documentation in AS Paths for VPN Routes on page 855

asymmetry
Syntax asymmetry number
Hierarchy Level For ACX Series and QFX Series:
[edit protocols ptp slave interface unicast-mode clock-source local-ip-address]
For MX Series:
[edit protocols ptp slave interface interface-name multicast-mode],

Release Information Statement introduced in Junos OS Release 15.2 for MX Series routers.
Statement introduced in Junos OS Release 17.3 for QFX Series switches.
Description Specify the asymmetry value between the master and the slave. A compensating value
for networks in which there is path asymmetry between the 1588v2 slave and master.
Specify a positive or negative value that is added to the path delay value from the slave
to the master, making the delay symmetric and equal to the path from the master to the
slave.
Options number—The asymmetry value is in nanoseconds and can vary from minus (–)100
milliseconds to 100 milliseconds, allowing compensation for up to 1/10 of a second
of path asymmetry.

• Configuring Precision Time Protocol
• Example: Configuring Precision Time Protocol

asymmetric-hold-time
Syntax asymmetric-hold-time;
Hierarchy Level [edit protocols vrrp]
Description Enable the VRRP master router to switch over to the backup router immediately, without
waiting for the priority hold time to expire, when a route goes down. However, when the
route comes back online, the backup router that is acting as the master waits for the
priority hold time to expire before switching the mastership back to the original master
VRRP router.
Default asymmetric-hold-time is disabled.

Related • Configuring the Asymmetric Hold Time for VRRP Routers

Documentation

atm-options
Syntax atm-options {
cell-bundle-size cells;
ilmi;
linear-red-profiles profile-name {
high-plp-max-threshold percent;
low-plp-max-threshold percent;
queue-depth cells high-plp-threshold percent low-plp-threshold percent;
}
mpls {
pop-all-labels {
required-depth number;
}
}
pic-type (atm1 | atm2);
plp-to-clp;
promiscuous-mode {
vpi vpi-identifier;
}
scheduler-maps map-name {
forwarding-class class-name {
epd-threshold cells plp1 cells;
linear-red-profile profile-name;
priority (high | low);
transmit-weight (cells number | percent number);
}
vc-cos-mode (alternate | strict);
}
use-null-cw;
vpi vpi-identifier {
maximum-vcs maximum-vcs;
oam-liveness {
up-count cells;
down-count cells;
}
oam-period (disable | seconds);
shaping {
(cbr rate | rtvbr peak rate sustained rate burst length | vbr peak rate sustained rate burst
length);
queue-length number;
}
}
}
Hierarchy Level [edit interfaces interface-name]

Statement introduced in Junos OS Release 12.2 for the ACX Series Universal Access
Routers.
Description Configure ATM-specific physical interface properties.

NOTE: Certain options apply only to specific platforms.

Related • Interface Encapsulations Overview

Documentation
• multipoint-destination
• shaping
• vci on page 1773

atm-policer (Firewall)
Syntax atm-policer policer-name {

atm-service (cbr | nrtvbr | rtvbr | ubr);
cdvt cdvt;
max-burst-size max-burst-size;
peak-rate peak-rate;
policing-action (discard | discard-tag | count);
sustained-rate sustained-rate;
}
Hierarchy Level [edit firewall],

[edit interface at-fpc/pic/port unit unit-number]
Release Information Statement introduced in Junos OS Release 12.2 on ACX Series routers.
Description (ACX Series routers) Create a policer, which polices each cell in the ATM packet. A policer
defines the maximum amount of traffic that can flow through an interface and further
determines the actions to be taken when the traffic exceeds the defined limits.
When included at the [edit firewall] hierarchy level, the atm-policer statement creates
a policer that can be applied explicitly to multiple ATM IMA interfaces at the edit interface]
hierarchy level.
Options policer-name—ATM policer name. The name can contain letters, numbers, and hyphens
(-), and can be up to 255 characters long. To include spaces in the name, enclose it
in quotation marks (“ ”).

interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
Documentation

atm-service
Syntax atm-service (cbr | nrtvbr| rtvbr| ubr);
Hierarchy Level [edit class-of-service traffic-control-profiles traffic-control-profile-name],

Release Information Statement introduced in Junos OS Release 12.2 on ACX Series routers.
Description (ACX Series routers) Configure the ATM service category on ATM IMA pseudowire
interfaces to define bandwidth shaping and policing.
• For shaping at the [edit class-of-service traffic-control-profiles

traffic-control-profile-name] hierarchy level, configure the ATM service category on the
ATM IMA pseudowire for shaping and utilization. Shaping is based on the ATM service
categories—cbr, nrtvbr, and rtvbr.
• For policing at the [edit firewall atm-policer atm-policer-name] hierarchy level, configure
the ATM IMA pseudowire to control the number of cells that fall within the defined
parameters. Policing is based on the ATM service categories—cbr, rtvbr, nrtvbr, and
ubr.
Options cbr—Use the constant bit rate.
nrtvbr—Use the nonreal-time variable bit rate.
rtvbr—Use the real-time variable bit rate.
ubr—Use the unspecified bit rate.

interface—To view this statement in the configuration.
interface-control—To add this statement to the configuration.
Documentation
• show class-of-service traffic-control-profile

auto-export
Syntax auto-export {
disable;
family inet {
disable;
flow {
disable;
rib-group rib-group;
}
multicast {
disable;
}
unicast {
disable;
}
}
family inet6 {
disable;
multicast {
disable;
}
unicast {
disable;
}
}
family iso {
disable;
unicast {
disable;
}
}
traceoptions {
file filename <files number> <size maximum-file-size> <world-readable |
no-world-readable>;
}
}

routing-options],


Description Export routes between routing instances.
This statement enables you to leak routes between VPN routing and forwarding (VRF)
instances that are locally configured on a provider edge (PE) router. Auto export is always
applied on the local PE router, because it applies to only local prefix leaking by evaluating
the export policy of each VRF and determining which route targets can be leaked. The
standard VRF import and export policies affect remote PE prefix leaking.
You can use this statement as an alternative to using the VRF import and export policies.
Options (disable | enable)—Disable or enable auto-export.

Default: Enable
family—Address family.
inet—IP version 4 (IPv4) address family.
multicast—Multicast routing information.
unicast—Unicast routing information.

Related • Technology Overview: Understanding the Auto Export Feature

Documentation

autoinstallation
Syntax autoinstallation {
configuration-servers {
url;
}
interfaces {
interface-name {
bootp;
rarp;
}
}
}
Hierarchy Level [edit system]

Statement introduced in Junos OS Release 12.2 for ACX Series Universal Access Routers.
Description Download a configuration file automatically from an FTP, Hypertext Transfer Protocol
(HTTP), or Trivial FTP (TFTP) server. When you power on a router or switch configured
for autoinstallation, it requests an IP address from a Dynamic Host Configuration Protocol
(DHCP) server. Once the router or switch has an address, it sends a request to a
configuration server and downloads and installs a configuration.
Options The remaining statements are explained separately. See CLI Explorer.
Required Privilege system—To view this statement in the configuration.

Level system-control—To add this statement to the configuration.

Documentation
• Upgrading Software by Using Automatic Software Download
• configuration-servers
• idle-timeout

autoinstallation (ACX Series)
Syntax autoinstallation {
delete-upon-commit;
continue-network-mode;
configuration-servers {
url;
}
interfaces {
interface-name {
bootp;
rarp;
}
}
}
Hierarchy Level [edit system]
Release Information Statement introduced in Junos OS Release 12.2 for ACX Series Universal Access Routers.
continue-network-mode option introduced in Junos OS Release 12.3X53 for ACX Series
Universal Access Routers.
Description (ACX Series routers). Download a configuration file automatically from an FTP, Hypertext
Transfer Protocol (HTTP), or Trivial FTP (TFTP) server. When you power on a router or
switch configured for autoinstallation, it requests an IP address from a Dynamic Host
Configuration Protocol (DHCP) server. Once the router or switch has an address, it sends
a request to a configuration server and downloads and installs a configuration.
Required Privilege system—To view this statement in the configuration.

Level system-control—To add this statement to the configuration.

Documentation
• Upgrading Software by Using Automatic Software Download
• configuration-servers
• idle-timeout

autonomous-system
Syntax autonomous-system autonomous-system <asdot-notation> <loops number> {

independent-domain <no-attrset>;
}

routing-options],

asdot-notation option introduced in Junos OS Release 9.3.
asdot-notation option introduced in Junos OS Release 9.3 for EX Series switches.
no-attrset option introduced in Junos OS Release 10.4.
Description Specify the routing device’s AS number.
An autonomous system (AS) is a set of routing devices that are under a single technical
administration and that generally use a single interior gateway protocol (IGP) and metrics
to propagate routing information within the set of routing devices. An AS appears to other
ASs to have a single, coherent interior routing plan and presents a consistent picture of
what destinations are reachable through it. ASs are identified by a number that is assigned
by the Network Information Center (NIC) in the United States (http://www.isi.edu).
If you are using BGP on the routing device, you must configure an AS number.
The AS path attribute is modified when a route is advertised to an EBGP peer. Each time
a route is advertised to an EBGP peer, the local routing device prepends its AS number
to the existing path attribute, and a value of 1 is added to the AS number.
In Junos OS Release 9.1 and later, the numeric range is extended to provide BGP support
for 4-byte AS numbers as defined in RFC 4893, BGP Support for Four-octet AS Number
Space. 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. RFC 4893
also introduces a reserved, well-known, 2-byte AS number, AS 23456. This reserved AS
number is called AS_TRANS in RFC 4893. All releases of Junos OS support 2-byte AS
numbers.
In Junos OS Release 9.3 and later, you can also configure a 4-byte AS number using the
AS-dot notation format of two integer values joined by a period: <16-bit high-order value
in decimal>.<16-bit low-order value in decimal>. For example, the 4-byte AS number
of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format.

Options autonomous-system—AS number. Use a number assigned to you by the NIC.

32
Range: 1 through 4,294,967,295 (2 – 1) in plain-number format for 4-byte AS numbers
In this example, the 4-byte AS number 65,546 is represented in plain-number format:
[edit]
routing-options {
}
Range: 0.0 through 65535.65535 in AS-dot notation format for 4-byte numbers
In this example, 1.10 is the AS-dot notation format for 65,546:
[edit]
routing-options {
autonomous-system 1.10;
}
Range: 1 through 65,535 in plain-number format for 2-byte AS numbers (this is a subset
of the 4-byte range)
In this example, the 2-byte AS number 60,000 is represented in plain-number format:
[edit]
routing-options {
}
asdot-notation—(Optional) Display the configured 4-byte autonomous system number

in the AS-dot notation format.
Default: Even if a 4-byte AS number is configured in the AS-dot notation format, the
default is to display the AS number in the plain-number format.
loops number—(Optional) Specify the number of times detection of the AS number in

the AS_PATH attribute causes the route to be discarded or hidden. For example, if
you configure loops 1, the route is hidden if the AS number is detected in the path
one or more times. This is the default behavior. If you configure loops 2, the route is
hidden if the AS number is detected in the path two or more times.
Range: 1 through 10
Default: 1
NOTE: When you specify the same AS number in more than one routing
instance on the local routing device, you must configure the same number
of loops for the AS number in each instance. For example, if you configure a
value of 3 for the loops statement in a VRF routing instance that uses the
same AS number as that of the master instance, you must also configure a
value of 3 loops for the AS number in the master instance.
Use the independent-domain option if the loops statement must be enabled

only on a subset of routing instances.

The remaining statement is explained separately. See CLI Explorer.

Related • Examples: Configuring External BGP Peering

Documentation
• Examples: Configuring Internal BGP Peering

backup-neighbor
Syntax backup-neighbor address {

community name;
mtu number;
hot-standby;
standby;
static;
virtual-circuit-id number;
}
Hierarchy Level [edit logical-systems logical-system-name protocols l2circuit local-switching interface

interface-name],
[edit logical-systems logical-system-name protocols l2circuit neighbor address interface
interface-name],
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols
vpls neighbor address],
[edit protocols l2circuit local-switching interface interface-name],
[edit protocols l2circuit neighbor address interface interface-name],
[edit routing-instances routing-instance-name protocols vpls neighbor address]

Statement introduced in Junos OS Release 12.3 at the [edit protocols l2circuit
local-switching interface interface-name] hierarchy level.
Description Configure pseudowire redundancy for Layer 2 circuits and VPLS. A redundant pseudowire
can act as a backup connection and can be configured between a PE router and a CE
device or between PE routers, maintaining Layer 2 circuit and VPLS services after certain
types of failures. This feature can help improve the reliability of certain types of networks
where a single point of failure could interrupt service for customers.
NOTE: VPLS is not supported on ACX Series routers. The psn-tunnel-endpoint

statement is not supported at the [edit protocols l2circuit local-switching
interface interface-name end-interface interface interface-name] hierarchy level.
Options address—Specifies the address for the backup neighbor.

Related • Configuring Pseudowire Redundancy on the PE Router on page 606

Documentation

• Example: Configuring Layer 2 Circuit Switching Protection
• community (Protocols Layer 2 Circuit)
• psn-tunnel-endpoint
• virtual-circuit-id
bandwidth-kbps (RFC 2544 Benchmarking)
Syntax bandwidth-kbps kbps;
Hierarchy Level [edit services rpm rfc2544-benchmarking profilestest-profile profile-name]
Release Information Statement introduced in Junos OS Release 12.3X53 for ACX Series routers.
Description Define the theoretical maximum bandwidth, in kilobits per second, for the test. The
theoretical limit of the media for the frame size configured for the test. This value is
typically set to the bandwidth of the server being tested. The range is 1,000 Kbps through
1,000,000 Kbps (1 Gbps). The value defined is the highest bandwidth value used for this
test.
Options kbps—Bandwidth limit, in kilobits per second (kpbs).

Range: 1,000 kbps through 1,000,000 Kbps.


Documentation

bandwidth (Tunnel Services)
Syntax bandwidth bandwidth-value;
Hierarchy Level [edit chassis fpc slot-number pic number tunnel-services]

Statement introduced in Junos OS Release 12.3X54 for ACX Series routers.
Description (ACX Series, MX Series 3D Universal Edge Routers and T4000 Core Routers only) Specify
the amount of bandwidth in gigabits per second to reserve for tunnel services. For ACX
Series routers, you can configure a bandwidth of only 1 Gbps and 10 Gbps for logical
tunnel (lt-) interfaces.
Options bandwidth-value—Amount of bandwidth in Gbps to reserve for tunnel services. On MX

Series routers, the bandwidth values can be 1g and multiples of 10g up to 100g. On
T4000 routers, the bandwidth values are multiples of 10g up to 100g.
NOTE: The bandwidth that you specify determines the port number of the
tunnel interfaces that are created. When you specify a bandwidth of 1g, the
port number is always 10. When you specify any other bandwidth, the port
number is always 0.
NOTE: If you specify a bandwidth that is not compatible with the type of
DPCs or MPCs and their respective Packet Forwarding Engine, tunnel services
are not activated. For example, you cannot specify 1 gigabit per second
bandwidth for a Packet Forwarding Engine on a 10-Gigabit Ethernet 4-port
DPC or 16x10GE 3D MPC.
When the tunnel bandwidth is unspecified in the Routing Engine CLI, the
maximum tunnel bandwidth for MPC3E is 60G.

Related • Example: Configuring Tunnel Interfaces on a Gigabit Ethernet 40-Port DPC

Documentation
• Tunnel Interface Configuration on MX Series Routers Overview
• Configuring Tunnel Interfaces on T4000 Routers
• Example: Configuring Tunnel Interfaces on a 10-Gigabit Ethernet 4-Port DPC
• Example: Configuring Tunnel Interfaces on the MPC3E

• Configuring Layer 3 Tunnel Services Interfaces on an MX Series Router with a DPC
• tunnel-services (Chassis) on page 1765
bits
Syntax bits {
priority number;
quality-level (prc | prs |sec | smc | ssu-a | ssu-b | st2 | st3 | st3e | st4 | stu | tnc);
request request (force-switch | lockout);
}
Hierarchy Level [edit chassis synchronization source]
Release Information Statement introduced in Junos OS Release 12.2 for ACX Series Routers.
Description Configure the external BITS device connected to the router’s T1 or E1 building-integrated
timing supply (BITS) interface, which upon configuration becomes a candidate for
selection as the clock source by the clock source selection algorithm.
NOTE: The bits option is not supported on the ACX1000 router.

Documentation
• Synchronous Ethernet Overview
• show chassis synchronization on page 2386

bpdu-block-on-edge
Syntax bpdu-block-on-edge;
Hierarchy Level [edit logical-systems logical-system-name protocols (mstp | rstp | vstp)],

(mstp | rstp | vstp)],
[edit protocols ( mstp | rstp| vstp )],
[edit routing-instances routing-instance-name protocols (mstp | rstp | vstp)]

Support for logical systems added in Junos OS Release 9.6.
Description Enable BPDU blocking on the edge ports of a virtual switch.

Related • Understanding BPDU Protection for Spanning-Tree Instance Interfaces on page 423
Documentation
• BPDU Protection on All Edge Ports of the Bridge
• Configuring BPDU Protection on Spanning Tree Interfaces
• rstp
• mstp
• vstp

bpdu-timeout-action
Syntax bpdu-timeout-action (log | block);
Hierarchy Level [edit logical-systems logical-system-name protocols (mstp | rstp | vstp)],

(mstp | rstp | vstp)],
[edit protocols (mstp | rstp | vstp) interface ],
[edit routing-instances routing-instance-name protocols (mstp | rstp | vstp)]

Support for logical systems added in Junos OS Release 9.6.
Description Provide STP loop protection for a given STP family protocol interface.
Default If the bpdu-timeout-action statement is not configured, an interface that stops receiving
BPDUs will transition to the designated port (forwarding) state, creating a potential loop.
Options log—The interface logs the fact that it has not received BPDUs during the timeout interval.
block—The interface is blocked and the fact that the interface has not received BPDUs
during the timeout interval is logged.

Documentation
• rstp
• mstp
• vstp

brief
Syntax (brief | full);

routing-options (aggregate | generate) (defaults | route)],
routing-options rib routing-table-name (aggregate | generate) (defaults | route)],
[edit logical-systems logical-system-name routing-options (aggregate | generate) (defaults |
route)],
generate) (defaults | route)],
[edit routing-instances routing-instance-name routing-options (aggregate | generate)
(aggregate | generate) (defaults | route)],
[edit routing-options (aggregate | generate) (defaults | route)],
[edit routing-options rib routing-table-name (aggregate | generate) (defaults | route)]

Description Configure all AS numbers from all contributing paths to be included in the aggregate or
generated route’s path.
• brief—Include only the longest common leading sequences from the contributing AS
paths. If this results in AS numbers being omitted from the aggregate route, the BGP
ATOMIC_ATTRIBUTE path attribute is included with the aggregate route.
• full—Include all AS numbers from all contributing paths in the aggregate or generated
route’s path. Include this option when configuring an individual route in the route portion
of the generate statement to override a retain option specified in the defaults portion
of the statement.
Default full


Documentation
• Example: Configuring a Conditional Default Route Policy
• Understanding Conditionally Generated Routes
• aggregate on page 1420

• generate on page 1535

bridge-domains (ACX Series)
Syntax bridge-domains {
bridge-options {
...bridge-options-configuration...
}
domain-type bridge;
no-irb-layer-2-copy;
routing-interface routing-interface-name;
vlan-id (all | none | number);
vlan-id-list [ vlan-id-numbers ];
vlan-tags outer number inner number;
bridge-options {
static-mac mac-address;
}
mac-statistics;
mac-table-size limit;
no-mac-learning;
}
}
}
Hierarchy Level [edit],

[edit logical-systems logical-system-name routing-instances routing-instance-name],
[edit routing-instances routing-instance-name]
Description Configure a domain that includes a set of logical ports that share the same flooding or
broadcast characteristics in order to perform Layer 2 bridging.
Options bridge-domain-name—Name of the bridge domain.
NOTE: You cannot use the slash (/) character as part of the bridge domain
name. If you do, the configuration will not commit.

Related
Documentation

bridge-options (ACX Series)
Syntax bridge-options {
static-mac static-mac-address;
}
packet-action drop;
}
mac-table-size limit;
no-mac-learning;
}
Hierarchy Level [edit bridge-domains bridge-domain-name],
Description Configure Layer 2 learning and forwarding properties for a bridge domain.

Related • Layer 2 Learning and Forwarding for Bridge Domains Overview

Documentation
bundle
Syntax bundle (ml-fpc/pic/port | ls-fpc/pic/port);
Hierarchy Level [edit interfaces interface-name unit logical-unit-number family mlfr-end-to-end],

[edit interfaces interface-name unit logical-unit-number family mlfr-uni-nni]
Description Associate the multilink interface with the logical interface it is joining.
Options ml-fpc/pic/port—Name of the multilink interface you are linking.
ls-fpc/pic/port—Name of the link services interface you are linking.

Related • Configuring the Links in a Multilink or Link Services Bundle

Documentation

cdvt
Syntax cdvt cdvt;
Hierarchy Level [edit firewall atm-policer atm-policer-name]
Release Information Statement introduced in Junos OS Release 12.2 for ACX Series routers.
Description (ACX Series routers) Define the Cell Delay/Variation Tolerance (CDVT) rate for the policer
or traffic control profile on an ATM IMA interface.
Options cdvt—CDVT rate in microseconds.

Range: 1 through 1,800,000,000

Documentation
cell-bundle-size
Syntax cell-bundle-size cells;
Hierarchy Level [edit interfaces at-fpc/pic/port atm-options],

[edit interfaces at-fpc/pic/port unit logical-unit-number],
[edit logical-systems logical-system-name interfaces at-fpc/pic/port unit logical-unit-number]
Description For ATM2 IQ interfaces using ATM Layer 2 circuit cell-relay transport mode only, configure
the maximum number of ATM cells per frame.
Options cells—Maximum number of cells.

Default: 1 cell
Range: 1 through 176 cells

Documentation

cell-bundle-size
Syntax cell-bundle-size cells;
Hierarchy Level [edit interfaces at-fpc/pic/port atm-options],

[edit interfaces at-fpc/pic/port unit logical-unit-number],
[edit logical-systems logical-system-name interfaces at-fpc/pic/port unit logical-unit-number]
Description For ATM2 IQ interfaces using ATM Layer 2 circuit cell-relay transport mode only, configure
the maximum number of ATM cells per frame.
Options cells—Maximum number of cells.

Default: 1 cell
Range: 1 through 176 cells

Documentation

cesopsn-options
Syntax cesopsn-options {
sample-period milliseconds;
threshold percentile;
}
idle-pattern pattern;
jitter-buffer-latency milliseconds;
jitter-buffer-packets packets;
packetization-latency microseconds;
}

Acx 2100

Uploaded by

Copyright:

Available Formats

You might also like

Acx 2100

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Acx 2100

Uploaded by

Copyright:

Available Formats

Junos® OS

ACX Series Universal Access Router Configuration

Copyright © 2017, Juniper Networks, Inc.

YEAR 2000 NOTICE

END USER LICENSE AGREEMENT

ii Copyright © 2017, Juniper Networks, Inc.

Copyright © 2017, Juniper Networks, Inc. iii

ACX5000 Routers Hardware and CLI Terminology Mapping . . . . . . . . . . . . . . . . . 39

Part 2 Installing and Upgrading ACX Series Routers

iv Copyright © 2017, Juniper Networks, Inc.

Part 3 Configuring Interfaces and Chassis on ACX Series Routers

Copyright © 2017, Juniper Networks, Inc. v

RAPS Message Blocking and Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

vi Copyright © 2017, Juniper Networks, Inc.

Configuring Chassis Alarm Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Copyright © 2017, Juniper Networks, Inc. vii

Configure the Layer 2 Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

viii Copyright © 2017, Juniper Networks, Inc.

IEEE 1588v2 PTP Boundary Clock Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Copyright © 2017, Juniper Networks, Inc. ix

Understanding Timing Defects and Event Management on ACX Series . . . . . . . 301

Part 4 Configuring DHCP on ACX Series Routers

x Copyright © 2017, Juniper Networks, Inc.

Dynamic Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Copyright © 2017, Juniper Networks, Inc. xi

Automatically Logging Out DHCP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Part 5 Configuring Protocols on ACX Series Routers

xii Copyright © 2017, Juniper Networks, Inc.

Configuring BPDU Protection on All Edge Ports . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Copyright © 2017, Juniper Networks, Inc. xiii

IGMP Snooping and Bridge Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

xiv Copyright © 2017, Juniper Networks, Inc.

Chapter 18 Configuring Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

Copyright © 2017, Juniper Networks, Inc. xv

ATM Pseudowire Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592

xvi Copyright © 2017, Juniper Networks, Inc.

Configuring the Silent Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

Copyright © 2017, Juniper Networks, Inc. xvii

Impact of Client-Side PCE Implementation on Network

Part 6 Configuring Layer 2 and Layer 3 Features on ACX Series Routers

xviii Copyright © 2017, Juniper Networks, Inc.

Copyright © 2017, Juniper Networks, Inc. xix

Configuring a VPN Tunnel for VRF Table Lookup . . . . . . . . . . . . . . . . . . . . . . . . . 828

Part 7 Configuring Class of Service on ACX Series Routers

xx Copyright © 2017, Juniper Networks, Inc.

Copyright © 2017, Juniper Networks, Inc. xxi

Processing of Hierarchical Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928

Part 8 Configuring Network Management and Administration on ACX

xxii Copyright © 2017, Juniper Networks, Inc.

Chapter 31 Configuring Network Address Translation (NAT) and Stateful Firewall

Copyright © 2017, Juniper Networks, Inc. xxiii

Configuring Queuing and Scheduling on Inline Services Interface . . . . . . . . . . . 1040

xxiv Copyright © 2017, Juniper Networks, Inc.

Copyright © 2017, Juniper Networks, Inc. xxv

Enabling E-LMI on an Interface and Mapping CE VLAN IDs to an

xxvi Copyright © 2017, Juniper Networks, Inc.

Scenarios for Configuration of ETH-SLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147

Copyright © 2017, Juniper Networks, Inc. xxvii