Juniper Training PDF

JUNOS MX SERIES INTRODUCTION
UNIVERSAL EDGE WITH 3D SCALING

80Tbps
One JUNOS 34Tbps
One TRIO CHIPSET
One UNIVERSAL EDGE 40Tbps
17Tbps
8.8Tbps
4.8Tbps 5.3Tbps
2.8Tbps 2.6Tbps
1.6Tbps
1.4Tbps
960Gbps
480Gbps
20-80Gbps 80Gbps
MX 5-80 MX104 MX 240 MX 480 MX 960 MX 2010 MX 2020
REVENUE GENERATION FOR THE NEXT DECADE

2 Copyright © 2009 Juniper Networks, Inc. www.juniper.net
MX-3D UNIVERSAL EDGE PLATFORM FLEXIBILITY
MX240 MX480 MX960 MX2010 MX2020

Max system
switching Capacity 960 Gbps 2.72 Tbps 5.12 Tbps 40Tbps 80Tbps
(1/2 duplex)
Height (RU) 6 8 16 34 45
Slots 2 6 11 10 20
Forwarding*
240Gbps 240Gbps 240Gbps 860Gbps 860Gbps
capacity/slot
10GE Ports* 48 136 256 260 520
Redundant RE Yes Yes Yes Yes Yes
Redundant Fabric Yes Yes Yes Yes Yes
Redundant Power Yes - AC/DC Yes - AC/DC Yes - AC/DC Yes – AC/DC Yes – AC/DC
* Current capacity, system capacity is higher

MX960 PLATFORM
14 slot chassis
Physical size
 Height: 16 rack units (about 1/3 rack),
Depth: <800mm deep MX 960 Router
Dependable hardware
 Passive mid-plane
 Redundant Routing Engines
 Redundant switching fabric (2+1)
 Distributed packet forwarding architecture
 Redundant fan and power
Power and cooling
 Front-to-back cooling with separate push-pull fan assemblies
 Holds up to two fan trays (1+1 redundancy)
 Holds up to four power supplies (2+2 DC, 3+1 AC)
 Rear-side power cabling
System capacity
 14 slots: Two for fabric cards / Routing Engines with the option
of one additional SCB for redundancy
 Up to 2.6 Tbps (full-duplex)
4
MX960 COMPONENT REVIEW
Control Panel
Upper Fan tray
SCB
MPC/MPC
MPC/MPC
RE
Lower Fan tray Cable

Management
Air
Intake

MX960 FRONT PANEL
Power Supply Indications
Fan Tray Indications

Routing Engine 0 Indications
Routing Engine 1 Indications
Yellow Red Alarm
Alarm Alarm Cut- Alarm
LED LED off Relays
Slot Online/Offline Buttons

MX960 SCB/RE CONFIGURATION
 Fabric redundancy
• Redundant fabric configuration
• 3 SCBs in SCB slot 0, SCB slot 1 and SCB slot 2
• 11 MPCs with MPCs in MPC slots 0-5 and MPC slots 7-11
• Non redundant fabric configuration
• 2 SCBs in SCB slot 0 and SCB slot 1
• 12 MPCs with MPCs in MPC slots 0-11
 Control/Routing Engine redundancy
• Independent of fabric redundancy
• Non redundant Control/Routing Engine Redundancy
• Routing Engines in SCB slot 0 or SCB slot 1
• Redundant Control/Routing Engine Redundancy
• Routing Engines in SCB slot 0 and SCB slot 1

MX960 SCB
SCBs are the Switch and But:

Control Boards  SCB in slot 2 does not
SCB act as RE carrier support RE (though it can be
plugged in)
Each SCB has two SF (fabric)
 Control part and switch part
chips
on SCB are operating
independently
 switch part can operate
without RE being inserted

MX960 SWITCH AND CONTROL BOARD WITH
RE1300/2000

MX960 RE
Different types of REs
 RE1800x2 (K2)
available:  Jasper Forrest (JF) processor
 RE1300 (bronce) from Intel Nehalem family
 Supports 32 bit JUNOS  Supports 64 bit JUNOS
 2G RAM  Dual core
 8/16G RAM
 Flash 1G
 Flash 4G
 HDD 40G
 SSD 24G
 RE2000 (gold)  RE1800x4 (K2)
 Supports 32 bit JUNOS  Jasper Forrest (JF) processor
 4G RAM from Intel Nehalem family
 Supports 64 bit JUNOS
 Flash 1G
 Quad core
 HDD 40G
 8/16G RAM
 Flash 4G
 SSD 30G

Modular Port Concentrators (fixed)
Provides a total of 16x 10GE ports per slot
 12 x10GE port are line rate per slot
Supported on MX960, MX480 and MX240

 Uses 4 next generation Packet Forwarding Engines
Supports all of the Layer3, MPLS and Layer2 feature

set of the current MX product family
Hardware support for Synchronous Ethernet

Modular Port Concentrators
Advanced MX line cards to support the Universal Edge
 Full JUNOS L3 routing and L2 switching technology and
Application services
 Support for Provider Edge, ESE and BBE feature set
 In-line, distributed services
Highly cost-optimized, advanced Ethernet
 Enhanced QoS, performance and scale
 High density GE and 10GE Ethernet
 Roadmap to 100G Ethernet
High Performance Design
 JUNOS Trio Chipset Advanced Silicon
 Up to 2 Modular Interface Cards per slot (MPC1/2)
 Software license upgrades (X to R)

Modular Interface Card Options (for Subscriber Management)
MIC
 MIC-3D-20GE-SFP
 20 ports of 10/100/1000Mbps with SFP optics
 MIC-3D-2XGE-XFP
 2 ports of 10GE with XFP optics
 Support software configurable WAN or LAN PHY options
 MIC-3D-4XGE-XFP
 4 ports of 10GE with XFP optics
 Support software configurable WAN or LAN PHY options
 Not supported on the MPC1 variants
 MIC-3D-40GE-TX
 40 ports of 10/100/1000Mbps with RJ-45 connector
 One MIC supported per line card slot
– Uses entire slot

New MX Fabric: Multi-Terabit MX (FUTURE)
Capacity Increase
 Supports 160Gbps per slot initially
 Fully redundant
 Active model provides 240Gbps per slot 5.3Tbps per MX960
 In Service Upgrade
Line Rate Ports on the
16x 10GE MPC
16x 10GE MPC
 Enables line rate on all 16 ports
 8 additional line rate ports upon SCB upgrade Investment Protection
 Seamless fabric redundancy for all 16 ports

MX-3D 100GE MPC (FUTURE)
EXPERIENCE, ECONOMICS AND ECOSYSTEM
Characteristics
 120Gbps bandwidth
 Modular Design for future optics options
Form Factors
 2 Ports (2x 1-Port MIC) of 100GE (CFP or CXP)
 4 Ports (2x 2-Port MIC) of 40GE (QSFP)
 20 Ports (2x 10-Port MIC) of 10GE (SFPP, WAN-PHY)
100 GbE Modular Line Card

Experience, Economics & Ecosystem
Applications 100 GbE Card
 Up to 2.4M IP Routes WAN Edge Services 
 Full scale L3VPN and VPLS
 Service Rich Processing Full MPLS Features 
All MX Functionality 
MX480 PLATFORM
8 slot chassis (6+2)
Physical size
 Height: 8 rack units (about 1/6 rack)
MX480 Router
Depth: <800mm deep
Dependable hardware
 Redundant Routing Engines
 Redundant fan and power
Power and cooling
 Side-to-side cooling
 Holds single fan tray
 Holds up to four power supplies (2+2 DC, 2+2 AC 240V, 3+1
AC 110V)
System capacity
 8 slots: Two for fabric cards / Routing Engines
 Up to 1.4 Tbps (full-duplex)

16
MX240 PLATFORM
4 slot chassis (2+2 or 3+1)
Physical size MX240 Router
 Height: 5 rack units
Depth: <800mm deep
Dependable hardware
 Redundant Routing Engines (2+2 configuration)
 Redundant power
Power and cooling

 Side-to-side cooling holds up to two fan trays (1+1 redundancy)
 Holds up to four power supplies (1+1 DC, 1+1 AC 200-240VAC, 2+2 AC 100-110VAC)
System capacity
 4 slots: Two available for fabric cards / Routing Engines
 Up to 480 Gbps (full-duplex)
 System reuses existing SCBs, Routing Engines, and DPCs—common across all MX Series
platforms
17
JUNOS ACX SERIES INTRODUCTION
TERMINOLOGY & POSITIONING
ACX
Altius-M
ACX-4000
Altius-1 MX
ACX

JUNIPER’S MPLS-ENABLED
ACCESS & AGGREGATION PORTFOLIO
MX960
MX480
MX80
Aggregation
Altius-1
Access/NTE ACX 4000 1H2013
ACX 2x00
Pre-Aggregation
ACX 1x00
10G capable
65 Gbps, 65 Gbps, 65 Gbps, 80 Gbps 80 Gbps 960+ Gbps

2x10GE, 10xGE 2x10GE, 22xGE 4x10GE, 22xGE 4 MIC slots 2 MIC slots 12+ MIC slots
RECAP
THE JUNIPER ACX UNIVERSAL ACCESS ROUTERS
ACX Series
 Juniper’s Universal Access solution for mobile backhaul (LTE, 2G/3G), business Ethernet
services and circuit to Ethernet migration
 Complements Universal Edge with a seamless end-to-end service delivery platform, extending
the existing network and all its capabilities to the access point
 Fixed and modular platforms
 Running Junos from access to edge to core
ACX1000 ACX2000
ACX4000
ACX1100 ACX2100
THE NEW BENCHMARK FOR ACCESS NETWORKS
 60 Gbps platforms: 3x the performance of nearest competition
 Industry’s only 10 GbE capable access router
 Most flexible and adaptable service architecture
 Automated service provisioning accelerates deployments
 Only open access system for extensibility
 Highest QoE with proven and deployed precision timing
 Environmentally hardened with 65w Power over Ethernet (PoE)

UNIVERSAL ACCESS ROUTER PORTFOLIO
INTERFACE COMPARISON BETWEEN MODELS
ACX1000: 1G router, with T1/E1: FRS 2T2012

 8xT1/E1, 12xGE(8xGE RJ45, 4xGE RJ45/SFP Combo), 1RU ETSI 300
 SyncE/1588v2, Temperature Hardened, Dual Feed DC power, Passively cooled
ACX2000: 10G router, with T1/E1: FRS 2T2012

 16xT1/E1, 10xGE (8xRJ45, 2xSFP), 2x10GE SFP+, 2xPoE+ 65W, 1RU ETSI 300
ACX4000: 10G Modular router, with 2 MIC slots: FRS 3T2012

 16xT1/E1, 10xGE, 2x10GE SFP+, 2xPOE+ 65W, 2.5RU ETSI 300
 SyncE/1588v2, Temperature Hardened, Redundant AC/DC power
 Modules: 16xT1/E1, 6xGE, 4xCHOC3/STM-1
ACX1100: 1G Ethernet-only router: FRS 3T2012

 12xGE, 1RU ETSI 300
 SyncE/1588v2, Temperature Hardened, Redundant AC/DC power, Passively cooled
ACX2100: 10G with more SFP Ports: FRS 3T2012

 16xT1/E1, 10xGE (4xRJ45, 6xSFP), 2x10GE SFP+, 1RU ETSI 300

ACX1000 UP CLOSE
1RU FANLESS AND ENVIRNOMENTALLY HARDENED

ACX2000 UP CLOSE
1RU FANLESS AND ENVIRNOMENTALLY HARDENED

PASSIVE COOLING AND COMPLETE REMOTE
MANAGEMENT DELIVER ADDITIONAL VALUE
Passive cooling Complete Remote

• Fans require annual filter Management
maintenance • Integrated RFC2544 testing
• Fans need replacement after ~4 does not require NIDs or
yrs external testers
• ACX has fan less design to • ACX/Space Zero touch
avoid maintenance provisioning allows rapid roll-
outs with minimum OPEX
Avoid opex that is 15-30% Save up to 25% of initial

of initial capex capex
ACX 1X00/2X00 PASSIVE COOLING BENEFITS
FANs wear-out eventually, and the wear-out accelerates in dusty outdoor

environments. Quoted MTBF numbers are not realistic in these situations.
FANs are not field replaceable and hence will require system to be brought
down and will trigger an RMA activity.
FANs requires annual maintenance. Zero-Maintainability is more critical since

every truck roll costs OPEX.
FANs consume extra power. About 7-8 watts extra for a 50W device (16%
extra power consumption).

ACX4000 UP CLOSE
MODULAR UNIT WITH 3 TYPES OF MICs

Thank You!
MX Series Router Installation
and Initial Configuration
Host Subsystem Operation
© 2010 Juniper Networks, Inc. All rights reserved. | www.juniper.net | Proprietary and Confidential
Section Objectives
 In this section, you will learn to

operate the host subsystem in
the Juniper Networks MX960
Ethernet Services Router.
 After completing this section,
you will be able to:
• Describe the host subsystem of an
MX960 Ethernet Services Router.
• Take a host subsystem offline.
• Bring a host subsystem online.
© 2010 Juniper Networks, Inc. All rights reserved. CONFIDENTIAL FSSMX960 www.juniper.net | 2
Host Subsystem Description
The host subsystem is comprised of:

• Switch Control Board (SCB)
• Routing Engine (RE)
The host subsystem provides the routing and system management functions of
the router. You can install one or two host subsystems on the router. Each host
subsystem functions as a unit.
• We recommend you install two host subsystems for maximum

redundancy. If you install only one host subsystem, you should install it
in slot SCB0.
• Host subsystems are hot-pluggable.

• Depending on configuration, changing host subsystem mastership might
cause the router to reboot.
• The router will not forward traffic without at least one online host subsystem
The host subsystem provides control and monitoring functions for the router.
These functions include:
• Determining Routing Engine mastership
• Controlling power and reset for the other router components
• Monitoring and controlling fan speed
• Monitoring system status
• Each host subsystem has three LEDs that display its status. The host
subsystem LEDs are located in the middle of the craft interface.
Taking a Host Subsystem Offline
• Check Routing Engine LEDs in the middle of the craft interface. If the green
RE MASTER LED is lit, the corresponding host subsystem is functioning as
the master.
• Issue the following CLI command:
user@host> show chassis routing-engine
• If the host subsystem you want to take offline is currently functioning as

master, switch it to backup by issuing the CLI command:
user@host> request chassis routing-engine master switch
• For the most predictable performance, configure the two Routing
Engines identically, except for parameters unique to a Routing Engine,
such as the hostname defined at the [edit system] hierarchy level and the
management interface (fxp0 or equivalent) defined at the [edit interfaces]
hierarchy level. For instructions, see the Junos System Basics
Configuration Guide at http://www.juniper.net/techpubs/software/
• On the console or other management device connected to the Routing

Engine that is paired with the SCB you are removing, enter CLI
operational mode and issue the following command:
• user@host> request system halt
• Wait until a message appears on the console confirming that the
operating system has halted.
• The SCB might continue forwarding traffic for approximately five minutes
after the request system halt command has been issued.
• For more information about the command, see the Junos System Basics
and Services Command Reference.
Bringing a Host Subsystem Online
• A host subsystem automatically comes online when both its components

(SCB and RE) are installed and powered.
• If a second host subsystem is installed in a running router, it comes online
as the backup host subsystem.
• If two host subsystems are installed at system startup, the components in
slots SCB0 and RE0 normally function as the master, and the components
in slots SCB1 and RE1 normally function as the backup.
Bringing a Host Subsystem Online
• You can determine the current status of a host subsystem by issuing the
show chassis routing-engine command at the Junos software’s
command-line interface.
• If you want to switch the host subsystem that is functioning as master,
issue the request chassis routing-engine master switch command at
the Junos software’s CLI.
Section Summary
In this section, you learned to:

• Describe the host subsystem of an
• Take a host subsystem offline.
• Bring a host subsystem online.
Switch Control Board Removal and

Installation
Section Objectives

remove and install a Switch Control
Board (SCB) in the Juniper
Networks MX960 Ethernet Services
Router.
 After completing this section, you
will be able to:
• Describe the Switch Control Board of
an MX960 Ethernet Services Router.
• Identify Switch Control Board
components.
• Identify the tools and parts required
to remove or install a Switch Control
Board.
• Remove a Switch Control Board.
• Install a Switch Control Board.
Switch Control Board Description
• A Switch Control Board and a Routing Engine comprise a host subsystem.

• The SCB powers on and powers off cards, controls clocking, resets and
booting, and monitors and controls system functions, including fan speed,
board power status, PDM status and control, and the system front panel.
Integrated into the SCB is the switch fabric, which interconnects all the
DPCs within the chassis, supporting up to 48 Packet Forwarding Engines.
The Routing Engine installs directly into the SCB.
• You can install up to three SCBs in the router. If two SCBs are installed,
one functions as the master SCB and the other as its backup. A third
installed SCB provides fabric redundancy, but no additional control or
routing functions. If the master fails or is removed, the backup restarts and
becomes the master.
• The SCBs install vertically into the front of the chassis in the slots labeled
0, 1, and 2/6
Each Switch Control Board consists of the following components:

• Two switch planes.
• Chassis management Ethernet switch.
• I2C bus logic, used for low-level communication with each component.
• Component redundancy circuitry.
• Control Board/Routing Engine mastership mechanism.
• Gigabit Ethernet switch that is connected to the embedded CPU complex on all
components.
• Switch fabric—Provides the switching functions
© 2010 Juniper Networks, Inc. All rights reserved.
for the DPCs. FSSMX960
CONFIDENTIAL www.juniper.net | 19
• Control FPGA—Provides the PCI interface to the Routing Engine.

• 1000Base-T Ethernet controller—Provides a 1-Gbps Ethernet link between the Routing
Engines
• Ethernet switch—Provides 1–Gbps link speeds between the Routing Engine and the
DPCs.
• Circuits for chassis management and control
• Power circuits for the Routing Engine and SCB
• LEDs—Three LEDs on the SCB indicate the status of the SCB. The LEDs, labeled FABRIC
ACTIVE, FABRIC ONLY, and OK/FAIL are located directly on the SCB.
Tools and Parts Required
You will need:

• An electrostatic bag or antistatic mat
• An ESD grounding wrist strap
• A number 2 Phillips screwdriver
Removing a Switch Control Board
• The SCBs are hot-pluggable. If the router contains a redundant host

subsystem, the SCB and the Routing Engine are hot-removable and hot-
insertable. Before you replace an SCB or a Routing Engine, you must take
the host subsystem offline.
• Before removing or replacing an SCB, ensure that the ejector handles are stored
vertically and pressed toward the center of the SCB.
Operating and Positioning the SCB Ejectors
• When removing or inserting an SCB, ensure that the SCBs or blank panels in
adjacent slots are fully inserted to avoid hitting them with the ejector handles. The
ejector handles require that all adjacent components be completely inserted so the
ejector handles do not hit them, which could result in damage.
• The ejector handles have a center of rotation and need to be stored toward the
center of the board. Ensure the long ends of the ejectors located at both the top and
the bottom of the board are vertical. For an ejector located at the top of the board,
press the ejector down toward the center of the board. For an ejector located on the
bottom of the board, press the ejector up toward the center of the board.
• To insert or remove the SCB card, slide the ejector across the SCB vertically, rotate it
and slide it again another quarter of a turn. Turn the ejector again and repeat as
necessary. Utilize the indexing feature to maximize leverage and to avoid hitting any
adjacent components.
• Operate both ejector handles simultaneously. The insertion force on an SCB is too
great for one ejector.
Removing an SCB
• The router can have up to three SCBs. They are located in the front of the chassis in
the slots marked 0, 1, and 2/6. With a Routing Engine installed, each SCB weighs
approximately 9.6 lb (4.4 kg).
• The SCB and Routing Engine are removed as a unit. You can also remove the
Routing Engine separately.
To remove an SCB, follow this procedure:

• Place an electrostatic bag or antistatic mat on a flat, stable surface.
• Attach an ESD grounding strap to your bare wrist, and connect the strap to one of
the ESD points on the chassis.
• Check whether the SCB is functioning as the backup or as the master. Take the host
subsystem offline. The SCB’s “offline” LED on the craft interface will light red.
• Disconnect any cables that may be connected to ports on the RE.
• Simultaneously rotate the ejector handles counterclockwise to unseat the SCB.

• Grasp the ejector handles and slide the SCB about halfway out of the chassis.
• Place one hand underneath the SCB to support it, and slide it completely out of the
chassis.
• Place the SCB in the electrostatic bag or on the antistatic mat.
• If you are not replacing the SCB now, install a blank panel over the empty slot
Installing a Switch Control Board
• Carefully align the sides of the SCB with the guides inside the chassis.
• Slide the SCB into the chassis, carefully ensuring that it is correctly aligned.
• Grasp both ejector handles and rotate them simultaneously clockwise until the SCB
is fully seated.
Installing a Switch Control Board
• To verify that the SCB is functioning normally, check the LEDs on its faceplate. The
green OK/FAIL LED should light steadily a few minutes after the SCB is installed. If
the OK/FAIL LED is red, remove and install the SCB again. If the FAIL LED still lights
steadily, it indicates that the SCB is not functioning properly. Contact your customer
support representative.
To check the status of the SCB, use the CLI command:
user@host> show chassis environment cb
Section Summary

• Describe the Switch Control Board of
an MX960 Ethernet Services Router.
• Identify Switch Control Board
components.
to remove or install a Switch Control
Board.
• Remove a Switch Control Board.
• Install a Switch Control Board.
Routing Engine Removal and

Installation
Section Objectives
In this section, you will learn to

remove and install a Routing
Engine (RE) in the Juniper
Networks MX960 Ethernet
Services Router.
 After completing this section,
you will be able to:
• Describe the Routing Engine of an
• Identify Routing Engine components.
to remove or install a Routing
Engine.
• Remove a Routing Engine.
• Install a Routing Engine.
Routing Engine Description
A Routing Engine and a Switch Control Board comprise a host subsystem.
• The Routing Engine is an Intel-based PCI platform that runs the Junos Internet software.
Software processes that run on the Routing Engine:
• Maintain the routing tables
• Manage the routing protocols
• Control the router’s interfaces
• Control some chassis components
• Provide the interface for system management and user access
Each Routing Engine weighs approximately 2.4 lb (1.1 kg).
• You can install one or two Routing Engines in the router. The Routing Engines
install into the front of the chassis in vertical slots directly into the SCBs labeled 0
and 1. If two Routing Engines are installed, one functions as the master and the
other acts as the backup. If the master Routing Engine fails or is removed, and the
backup is configured appropriately, the backup takes over as the master.
• A Routing Engine installed in SCB slot 2/6 is not powered, install a blank panel
instead.
• The Routing Engines are hot-pluggable. Each Routing Engine must be installed
directly into an SCB. A USB port on the Routing Engine accepts a USB memory
card that allows you to load Junos software.
• A Routing Engine consists of the following components:

• CPU: Runs Junos Internet software to maintain the routing platform’s routing
tables and routing protocols.
• DRAM: Provides storage for the routing and forwarding tables, and for the other
Routing Engine processes.
• USB port: Provides a removable media interface through which you can install the
Junos Internet software manually.
• Internal flash disk: Provides primary storage for software images, configuration
files, and microcode.
• Hard disk: Provides secondary storage for the log files, memory dumps, and for
rebooting the system, if the internal flash disk fails
• LEDs: Each Routing Engine has four LEDs that indicate its status. The LEDs,
labeled MASTER, HDD, ONLINE, and FAIL are located directly on the faceplate of
the Routing Engine.
• Indicate disk activity for the internal IDE interface. They do not necessarily indicate
routing-related activity.
• The onscreen table describes the functions of the Routing Engine LEDs.
• HDD LED: Indicates disk activity for the hard disk drive.
• Routing Engine Interface Ports and Status Indicators
• In the center of the Routing Engine are three sets of ports that connect the
Routing Engine to one or more external devices on which system administrators
can issue Junos command-line interface (CLI) commands to manage the router.
These interfaces also provide information about Routing Engine status.
• Each Routing Engine has one 10/100-Mbps Ethernet port for connecting to a
management network, and two asynchronous serial ports—one for connecting to a
console and one for connecting to a modem or another auxiliary device.
• The ports with the indicated label in each set function as follows:
• AUX—Connects the Routing Engine to a laptop, modem, or other auxiliary device
through a cable with an RJ-45 connector.
• CONSOLE—Connects the Routing Engine to a system console through a cable
with an RJ-45 connector.
• ETHERNET—Connects the Routing Engine through an Ethernet connection to a

management LAN (or any other device that plugs into an Ethernet connection) for out-
of-band management. The port uses an autosensing RJ-45 connector to support the
10/100- Mbps connections. Two small LEDs on the bottom of the port indicate the
connection in use: the LED lights yellow or green for a 10-Mbps connection, and the
LED lights green when traffic is passing through the port.
• EEPROM: Stores the serial number of the Routing Engine.

• Reset button: Reboots the Routing Engine when pressed.
• Offline button: Takes the Routing Engine offline when pressed.
• Extractor clips: Used for inserting and extracting the Routing Engine.
• Captive screws: Secure the Routing Engine in place.
Routing Engine Boot Sequence

• The Routing Engine boots from the storage media in this order: the USB device, then
the internal flash disk (if present), then the hard disk, then the LAN.
Routing Engine Boot Sequence

• If the Routing Engines are configured for graceful switchover, the backup Routing
Engine automatically synchronizes its configuration and state with the master Routing
Engine. Any update to the master Routing Engine state is replicated on the backup
Routing Engine. If the backup Routing Engine assumes mastership, packet forwarding
continues through the router without interruption. For more information about graceful
switchover, see the JUNOS System Basics Configuration Guide.
• For specific information about Routing Engine components (for example, the amount
of DRAM), issue the show chassis routing-engine command.
• If two Routing Engines are installed, they must both be the same hardware version.
You will need:

Removing a Routing Engine
• The Routing Engine is hot-pluggable. If the router contains a redundant host

subsystem, the Routing Engine and SCB are hot-removable and hot-insertable. Before
you replace an SCB or a Routing Engine, you must take the host subsystem offline.
• Place an electrostatic bag or antistatic mat on a flat, stable surface.

• Attach an ESD grounding strap to your bare wrist, and connect the strap to one of the
ESD points on the chassis.
• Check whether the Routing Engine is functioning as the backup or as the master. If
necessary, take the host subsystem offline.
• Router performance might change if the standby Routing Engine's configuration differs from
the former master's configuration. For the most predictable performance, configure the two
Routing Engines identically, except for parameters unique to a Routing Engine, such as:
• hostname defined at the [edit system] hierarchy level
• management interface (fxp0) defined at the [edit interfaces] hierarchy level.
• To configure Routing Engine-specific parameters- and still use the same configuration on
both Routing Engines, include the appropriate configuration statements under the re0 and
re1 statements at the [edit groups] hierarchy level and use the apply-groups statement.
• Verify that the Routing Engine LEDs are off.

• Loosen the captive screws on the top and bottom of the Routing Engine.
• Flip the ejector handles outward to unseat the Routing Engine.
• Grasp the Routing Engine by the ejector handles, and slide it about halfway out of the
chassis.
• Place one of your hands underneath the Routing Engine to support it, and slide it completely
out of the chassis.
• Place the Routing Engine in the electrostatic bag or on the antistatic mat.
• To maintain proper airflow through the chassis, do not leave an SCB installed in the
chassis without a Routing Engine for extended periods of time. If a Routing Engine is
removed, a replacement Routing Engine should be installed as soon as possible.
Installing a Routing Engine
To install a Routing Engine:

• Ensure the ejector handles are not in the locked position.
• Place one hand underneath the Routing Engine to support it. With the other hand, grasp
one of the ejector handles on the faceplate.
• Carefully align the sides of the Routing Engine with the guides inside the opening on the
SCB.
• Slide the Routing Engine into the SCB until you feel resistance, and then press faceplate
of the Routing Engine until it engages the connectors.
• Press both the ejector handles inward to seat the Routing Engine. Once it is seated, the
Routing Engine automatically comes online.
• Tighten the captive screws on the top and bottom of the Routing Engine.
• The Routing Engine might require several minutes to boot.
• After the Routing Engine boots, verify that it is installed correctly by checking the
RE0 and RE1 STATUS LEDs on the craft interface.
• If the router is operational and the Routing Engine is functioning properly, the green OK
LED lights steadily.
• In case the red FAIL LED lights steadily, remove and install the Routing Engine again.
• If the red FAIL LED still lights steadily, the Routing Engine is not functioning properly.
Contact your customer support representative.
• To check the status of the Routing Engine, use the CLI command:
• user@host> show chassis routing-engine
Routing Engine status:
Slot 1:
Current state Backup
Section Summary

• Describe the Routing Engine of an
• Identify Routing Engine components.
to remove or install a Routing
Engine.
• Remove a Routing Engine.
• Install a Routing Engine.
Dense Port Concentrator Removal

and Installation
Section Objectives
 In this section, you will learn to remove

and install a Dense Port Concentrator (or
DPC) in the Juniper Networks MX960
Ethernet Services Router.
 After completing this section, you will be
able to:
• Describe a DPC.
to remove and install a DPC.
• Remove a DPC.
• Install a DPC.
Dense Port Concentrator Description
• The Dense Port Concentrators (DPCs) are optimized for Ethernet density and are
capable of supporting up to 40 Gigabit Ethernet or 4 10-Gigabit Ethernet ports. The DPC
assembly combines packet forwarding and Ethernet interfaces on a single board, with
four 10-Gbps Packet Forwarding Engines. Each Packet Forwarding Engine consists of
one I-chip for Layer 3 processing and one Layer 2 network processor. The DPCs
interface with the power supplies and Switch Control Boards (SCBs).
• The router has 11 dedicated DPC slots. DPCs install vertically in the front of the router.
The DPCs are numbered 0 through 11 left to right. An additional slot numbered 2/6
accepts either a DPC or an SCB. A DPC can be installed in any DPC slot on the router.
You can install any combination of DPC types in the router.

The router accepts the following types of DPCs:
• 40-port Gigabit Ethernet with SFP
• 4-port 10–Gigabit Ethernet with XFP
DPCs are hot-removable and hot-insertable.
• When you install a DPC in an operating router, the Routing Engine downloads the DPC
software, the DPC runs its diagnostics, and the Packet Forwarding Engines housed on
the DPC are enabled. Forwarding on other DPCs continues uninterrupted during this
process.
• If a slot is not occupied by a DPC, a DPC blank panel must be installed to shield the
empty slot and to allow cooling air to circulate properly through the router.
• Faceplates on DPCs for the MX960 router are labeled with the DPC type: 4x10GE or
40x1GE.
• Each DPC slot has a pair of LEDs that indicates its status. The DPC LEDs, labeled 0
through 11 and 2/6, are located along the bottom of the craft interface.
• If the DPC failed, the fail LED is a steady red. If the OK LED is blinking green, it
indicates that the DPC is starting up. If the DPC is functioning normally, the OK LED is
lit steadily green.
DPC Components
• Each DPC consists of the following components:
• DPC cover, which functions as a ground plane and a stiffener.
• Fabric interfaces.
• Two Gigabit Ethernet interfaces that allow control information, route information, and
statistics to be sent between the Routing Engine and the CPU on the DPCs.
• Two interfaces from the SCBs that enable the boards to be powered on and controlled.
• Physical DPC connectors.

• Packet Forwarding Engines.
• Midplane connectors and power circuitry.
• Processor subsystem, which includes a 1.2-GHz CPU, system controller, and 1 GB of
SDRAM.
• Online button—Takes the DPC offline when pressed.
• LEDs on the 4–port 10–Gigabit Ethernet faceplate indicate the port status. LEDs are
labeled top to bottom 0/0 through 0/3.
• LEDs on the 40–port Gigabit Ethernet faceplate indicate the port status. LEDs are
labeled horizontally and top to bottom 0/0 through 0/5, 1/0 through 1/5, 2/0 through 2/5,
and 3/0 through 3/5.
• Two LEDs, located on the craft interface above the DPC, display the status of the DPC
and are labeled OK and FAIL.
Handling and Storing DPCs
This section explains how to avoid damaging the DPCs that you install into the router.
• Many components on the DPC are fragile. Failure to handle DPCs as specified in this
course can cause irreparable damage.
• Faceplate—Edge of the DPC that has connectors into which you insert the SFP or XFP
transceivers.
• Connector edge—Edge opposite the faceplate; this edge has the connectors that attach
to the midplane.
• Top edge—Edge at the top of the DPC when it is vertical.
• Bottom edge—Edge at the bottom of the DPC when it is vertical.
You will need:

• Rubber safety caps
Removing a Dense Port Concentrator
• The router holds up to twelve DPCs, which are installed vertically in the front of the
router. The DPCs are hot-insertable and hot-removable. When you remove a DPC,
the router continues to function, although the DPC being removed no longer
functions.
Before removing a DPC, make sure you have:

• A replacement DPC or an DPC blank panel
• An antistatic mat or electrostatic bag
• Rubber safety caps
• Take the DPC offline by pressing its online/offline button. Hold the button until the LED
goes out.
• Alternately, you may also take the DPC offline by issuing the following CLI command:
• user@host>request chassis fpc slot slot-number offline
• Disconnect the cables from the DPC. If the DPC uses fiber-optic cable, immediately cover
each transceiver and the end of each cable with a rubber safety cap.
• Do not look directly into fiber interface transceivers or into the ends of fiber-optic
cables. Laser light from transceivers can cause irreversible damage to your eyes.
• Do not leave a fiber-optic transceiver uncovered, except when inserting or

removing cables. A safety cap keeps the port clean and prevents accidental
exposure to laser light.
• Avoid bending fiber-optic cable beyond its maximum bend radius. An arc smaller
than a few inches in diameter can damage the cable and cause problems that are
difficult to diagnose.
• Carefully secure each disconnected cable to the cable management system below the DPC
card cage to prevent the cables from developing stress points.
• Flip the ejector handles out of their seated position by pressing up on the top ejector and
down on the bottom ejector. Simultaneously turn both the ejector handles counterclockwise
to unseat the DPC.
• Grasp the handles and slide the DPC straight out of the card cage halfway.
• Place one hand around the front of the DPC and the other hand under it to support it.
Slide the DPC completely out of the chassis, and place it on the antistatic mat or in the
electrostatic bag.
• The weight of the DPC is concentrated in the back end. Be prepared to

accept the full weight—up to 13.1 lb (5.9 kg)—as you slide the DPC out of the
chassis.
• When the DPC is out of the chassis, do not hold it by the ejector handles, bus bars, or
edge connectors. They cannot support its weight.
• Do not stack DPCs on top of one another after removal. Place each one individually in
an electrostatic bag or on its own antistatic mat on a flat, stable surface.
• If you are not reinstalling a DPC into the emptied DPC slot within a short time, install a
blank DPC panel over the slot to maintain proper airflow in the DPC card cage.
• After removing a DPC from the chassis, wait at least 30 seconds before
reinserting it, removing a DPC from a different slot, or inserting a DPC into a
different slot.
Installing a Dense Port Concentrator
• Attach an ESD grounding strap to your bare wrist, and connect the strap to one of the ESD
points on the chassis.
• Place the DPC on an antistatic mat or remove it from its antistatic bag.
• Verify that each fiber-optic interface has a rubber safety cap covering the transceiver. If it
is not covered, cover the transceiver with a safety cap.
• Locate the slot in the DPC card cage in which you plan to install the DPC. If necessary,
remove the DPC blank plate.
• Orient the DPC so that the faceplate faces you, the text on the DPC is right-side up, and
the EMI strip is on the right-hand side.
• Lift the DPC into place and carefully align first the bottom and then the top of the DPC
with the guides inside the card cage.
• Slide the DPC all the way into the card cage until you feel resistance.
• Grasp both ejector handles and rotate them simultaneously clockwise until the DPC is
fully seated.
• If the DPC uses fiber-optic cable, remove the rubber safety cap from each transceiver
and cable, and insert the appropriate cables into the transceivers on the DPC.
• Do not look directly into a fiber-optic transceiver or into the ends of fiber-optic
cables. Fiber-optic transceivers and fiber-optic cable connected to a transceiver
emit laser light that can damage your eyes.
• Secure the cables so that they are not supporting their own weight. Place the
excess cable out of the way in a neatly coiled loop, using the cable management
system. Placing fasteners on a loop helps to maintain its shape.
• Never let cables hang free from the connector. Do not allow fastened loops of
cable to dangle, because this stresses the cable at the fastening point.
• Avoid bending fiber-optic cable beyond its minimum bend radius. An arc smaller
than a few inches in diameter can damage the cable and cause problems that are
difficult to diagnose.
• To bring the DPC online, press and hold the DPC online/offline button on the craft
interface until the green OK/FAIL LED lights steadily, which takes about 5
seconds.
• Alternately, you may also bring the DPC online by issuing the following CLI
command:
• user@host>request chassis fpc slot slot-number online
• For more information about the command, see the Junos System Basics and
Services Command Reference.
• After the OK LED turns green, wait at least 30 seconds before removing the DPC
again, removing a DPC from a different slot, or inserting a DPC in a different slot.
• You can also verify that the DPC is functioning correctly by issuing the show
chassis fpc and show chassis fpc pic-status commands described in Chapter
7 of the MX960 Hardware Guide, “Maintaining Hardware Components”.
Section Summary

• Describe a Dense Port Concentrator.
to remove and install Dense Port
Concentrator.
• Remove a Dense Port Concentrator.
• Install a Dense Port Concentrator.
SFP/XFP Removal and Installation
Section Objectives

remove and install a Small Form-
Factor Pluggable (or SFP), or 10-
gigabit Small Form-Factor
Pluggable (or XFP) in the Juniper
Router.
will be able to:
• Describe an SFP or XFP.
to remove and install an SFP or XFP.
• Remove an SFP or XFP.
• Install an SFP or XFP.
SFP/XFP Description
• SFPs and XFPs are removable optical transceivers. You can use any combination of
SFP or XFP types in a single DPC.
• SFPs and XFPs are hot-insertable and hot-removable.
• When you remove an SFP or XFP, the DPC continues to function, although the SFP
or XFP you removed no longer receives or transmits data.
You will need:

• A rubber safety cap
Removing an SFP/XFP
• Keep a replacement SFP/XFP or an SFP/XFP slot plug, an antistatic mat or

electrostatic bag, and a rubber safety cap ready.
• Remove the cable connector plugged into the SFP/XFP.
Removing an SFP/XFP
• Do not look directly into a fiber-optic transceiver or into the end of a fiber-optic cable.
Fiber-optic transceivers contain laser light sources that can damage your eyes.
• Carefully secure the disconnected cable to the cable management system below the
DPC card cage to prevent the cable from developing stress points.
• Avoid bending fiber-optic cable beyond its minimum bend radius. An arc smaller than
a few inches in diameter can damage the cable and cause problems that are difficult
to diagnose.
Removing an SFP/XFP
• Pull the ejector handle out from the transceiver.

Make sure that you open the ejector handle completely.
• Grasp the ejector handle and pull the SFP/XFP approximately 0.5 inches (or 1.3 cm)
out of the DPC.
• Using your fingers, grasp the body of the transceiver and pull it the rest of the way
out of the DPC.
• Close the ejector handle and place a rubber safety cap over the optical transceiver.
• Finally, place the removed transceiver on an antistatic mat or in an electrostatic bag.
Installing an SFP/XFP
• Next, take the SFP or XFP to be installed out of its electrostatic bag and identify the
slot on the DPC where it will be installed.
• Verify that each transceiver is covered by a rubber safety cap. If it is not, cover the
transceiver with a safety cap.
Installing an SFP/XFP
• Carefully align the SFP or XFP with the slots in the DPC. The connectors should
face the DPC.
• Slide the SFP or XFP until the connector is seated in the DPC slot. If you are unable
to fully insert the transceiver, make sure the connector is facing the right way.
• Remove the rubber safety cap from the transceiver and the end of the cable.
• Insert the cable into the transceiver.
• Verify that the status LEDs on the DPC faceplate indicate that the SFP or XFP is
functioning correctly.
Section Summary

• Describe an SFP or XFP.
to remove and install an SFP or XFP.
• Remove an SFP or XFP.
• Install an SFP or XFP.
Craft Interface Replacement
Section Objectives

replace the craft interface on the
Juniper Networks MX960 Ethernet
Services Router.
will be able to:
• Describe the craft interface.
to replace the craft interface.
• Remove the craft interface.
• Install the craft interface.
Craft Interface Description
• The craft interface allows you to view the MX960 Ethernet Services Router’s status
and troubleshooting information at a glance, and to perform many system control
functions. It weighs approximately 1.5lb (0.68 kg), is located on the front of the router
above the upper fan tray, and is hot-insertable and hot-removable.
• When the craft interface is removed, you cannot control or communicate with the
router using an external device. When you install the craft interface, allow several
minutes for the display to reflect the current state of the router.
The craft interface contains the following:

• Alarm LEDs and Alarm Cutoff/Lamp Test Button
• Power Supply LEDs
• Host Subsystem LEDs
• DPC LEDs
• SCB LEDs
• Fan LEDs
• Alarm Relay Contacts
At least one SCB must be installed in the router for the craft interface to obtain
power.
Alarm LEDs and Lamp Test Button
Host Subsystem LEDs
Power Supply LEDs
DPC LEDs
SBC LEDs
Fan LEDs
• The host interface has two alarm relay contacts for connecting the router to external
alarm devices. The alarm relay contacts are located on the upper right of the craft
interface above the DPC LEDs.
You will need:

• Electrostatic bag or mat
• ESD grounding wrist strap
• No. 2 Phillips screwdriver
Removing the Craft Interface
• Detach any external devices connected to the craft interface.
• Loosen the captive screws at the top left and right corners of the craft interface
faceplate.
Removing the Craft Interface
• Grasp the craft interface faceplate and carefully tilt it toward you until it is horizontal.
• Locate the latch on the inside of the craft interface that connects the cable to the
circuit board socket. Grasp both sides of the latch on the inside of the craft interface
and with your thumb and forefinger, gently press both sides of the latch to disengage
it.
• Put the craft interface into an electrostatic bag.
Installing the Craft Interface
• Grasp the craft interface with one hand and hold the bottom edge of the craft interface
with the other hand to support its weight.
• Align the red line along the bottom of the internal strap with the bottom of the
connector and snap gently into place.
Installing the Craft Interface
• Align the bottom of the craft interface with the sheet metal above the DPC card cage
and press it into place.
• Tighten the screws at the top left and right corners of the craft interface faceplate.
• Reattach any external devices connected to the craft interface.
Section Summary

• Describe the craft interface.
to replace the craft interface.
• Remove the craft interface.
• Install the craft interface.
Fan Tray Replacement
Section Objectives

replace the fan trays on the Juniper
Router.
will be able to:
• Describe the cooling system
components.
to replace fan trays.
• Remove a fan tray.
• Install a fan tray.
Cooling System Description
The cooling system is comprised of:

• Two front fan trays
• A front air filter
• Both fan trays install horizontally above and below the DPC card cage. Each fan tray
contains six fans. The fan trays are interchangeable, and each weighs about 13 lb (5.9
kg).
• All fan trays and filters are hot-insertable and hot-removable.
• The host subsystem monitors the temperature of the router components. When the
router is operating normally, the fans function at lower than full speed. If a fan fails or
the ambient temperature rises above a threshold, the speed of the remaining fans is
automatically adjusted to keep the temperature within the acceptable range.
• If the ambient maximum temperature specification is exceeded and the system cannot
be adequately cooled, the Routing Engine shuts down the system by disabling output
power from each PEM.
• There is a single intake in the front of the router. Air is pushed up through the DPC
card cage and through the upper fan tray, where it combines in a common exhaust
plenum and is exhausted out the upper rear of the system.
You will need:

Removing a Fan Tray
• Before removing or replacing any component, ensure you are operating the ejector
handles properly and that they are stored correctly on all router components.
Removing a Fan Tray
• Unwrap any cables on the cable management system and remove the cables from the
tray. Arrange the cables so that they do not block the front of the cable management
system and tray, and secure them with temporary fasteners so that they are not
supporting their own weight as they hang from the connector.
• If you are removing the lower fan tray, simultaneously pull the two releases
labeledPULL on the cable management system. Lift it up and outwards to lock it in
place to access the lower fan tray.
Removing a Fan Tray
• Loosen the captive screw on each side of the fan tray faceplate.
• Grasp the handles and pull the fan tray out approximately 1–3 inches
• To avoid injury, keep the tools and your fingers away from the fans as you slide the
fan tray out of the chassis. The fans might still be spinning.
Removing a Fan Tray
• When the fans stop spinning, press on the two latches located on the inside of the fan
tray.
• Place one hand under the fan tray to support it, and pull the fan tray completely out of
the chassis.
• Put the fan tray into an electrostatic bag.
Installing a Fan Tray
• Grasp the fan tray by its handles, and insert it straight into the chassis.
• Tighten the captive screws on each side of the fan tray faceplate to secure it in the
chassis.
• If you are installing the lower fan tray, unlock the cable management system and
move it to the fully lowered position.
Section Summary

• Describe the cooling system
components.
to replace the fan trays.
• Remove a fan tray.
• Install a fan tray.
Air Filter Replacement
Section Objectives

replace the air filter on the Juniper
Router.
will be able to:
• Describe the air filter.
to replace an air filter.
• Remove the air filter.
• Install the air filter.
Air Filter Description
• The router has one air filter, located in the front of the chassis below the DPC card
cage. It installs horizontally above the front lower fan tray.
• The air filter weighs approximately 1 lb (0.5 kg).
• The air filter is hot-insertable and hot-removable.
Removing the Air Filter
• Unwrap any cables on the cable management system and remove the cables from the
tray. Arrange the cables so that they do not block the front of the cable management
system and tray, and secure them with temporary fasteners so that they are not
supporting their own weight as they hang from the connector.
• Do not let fiber-optic cable hang free from the connector. Do not allow fastened loops
of cable to dangle, which stresses the cable at the fastening point.
• Simultaneously pull the two releases labeled PULL on the cable management
system.Lift it up and outwards to lock it in place to access the front air filter.
• Simultaneously slide the latches on the outer edges of the air filter tray in towards the
center of the tray
• Slide the air filter tray out of the chassis.
• Lift the air filter out of the air filter tray.
Installing the Air Filter
• Ensure the air filter is right side up.
• Place the air filter into the air filter tray.
• Insert the air filter tray into the chassis by sliding it straight into the chassis until it
stops.
• Lower the cable management system back into position.
• Rearrange the cables in the cable management system.
Section Summary

• Describe the air filter.
to replace an air filter.
• Remove the air filter.
• Install the air filter.
DC Power Supply Replacement
Section Objectives

replace a DC power supply on the
Juniper Networks MX960 Ethernet
Services Router.
will be able to:
• Describe a DC power supply.
to replace a DC power supply.
• Remove a DC power supply.
• Install a DC power supply.
DC Power Supply Description
• In the DC power configuration, the router contains either two or four DC power
supplies located at the lower rear of the chassis in slots PEM0 through PEM3 (left to
right). You can upgrade your DC power system from two to four power supplies.
• The DC power supplies in slots PEM0 and PEM2 provide power to the lower fan tray,
DPC slots 6 through 11, and SCB slots 1 and 2. The DC power supplies in slots PEM1
and PEM3 provide power to the upper fan tray, DPC slots 0 through 5, and SCB slot
0.
• Each power supply weighs approximately 3.8 lb (1.7 kg), and is hot-insertable and hot-
removable.
• Four power supplies provide full redundancy. If a DC power supply fails, its redundant
power supply takes over without interruption.
• Each DC power supply has a single DC input (–48 VDC and return) that requires a
dedicated 80 A (–48 VDC) circuit breaker for the maximum router hardware
configuration.
DC Power Supply Specifications
• DC Power Supply LEDs

• Each DC power supply faceplate contains three LEDs that indicate the status of the
power supply. See the table onscreen for descriptions of the LEDs and their status.
• The power supply status is also reflected in two LEDs on the craft interface. In
addition, a power supply failure triggers the red alarm LED on the craft interface.
You will need:

• A 3/8-in. nut driver
• Wire cutters
Removing a DC Power Supply
• Make sure that the voltage across the DC power source cable leads is 0 V.
• Do not leave a power supply slot empty for more than a short time while the router is
operational. The power supply must remain in the chassis for proper airflow;
alternately, you may install a blank panel.
• After powering off a power supply, wait at least 60 seconds before turning it back on.
• Switch the circuit breaker on the power supply faceplate to the OFF position (O).
• Remove the clear plastic cover protecting the terminal studs on the faceplate.
• Loosen the captive screw on the cable restraint on the lower edge of the power supply
faceplate. Carefully move the power cables out of the way.
• Remove the nuts and washers from the terminal studs.

• Remove the cable lugs from the terminal studs.
• While grasping the handle on the power supply faceplate with one hand, use your
other hand to pull the spring-loaded locking pin in the release lever away from the
chassis and turn the release lever counterclockwise until it stops.
• Let go of the locking pin in the release lever. Ensure that the pin is seated inside the
corresponding hole in the chassis.
• Pull the power supply straight out of the chassis.
• Put the power supply in an electrostatic bag.
• Do not touch the power connector on the top of the power supply. It can contain
dangerous voltages.
Installing a DC Power Supply
• Make sure that the voltage across the DC power source cable leads is 0 V.
• There is no standard color coding for DC power cables. The color coding used by the
external DC power source at your site determines the color coding for the leads on the
power cables that attach to the terminal studs on each power supply. You must ensure
that power connections maintain the proper polarity. The power source cables might
be labeled (+) and (–) to indicate their polarity.
• Switch the circuit breaker on the power supply faceplate to the OFF position.
• Ensure that the release lever below the empty power supply slot is locked in the
counterclockwise position.
• If necessary, pull the spring-loaded locking pin in the release lever away from the
chassis and turn the release lever counterclockwise until it stops. Let go of the locking
pin in the release lever. Ensure that the pin is seated inside the corresponding hole in
the chassis.
• Using both hands, slide the power supply straight into the chassis until the power
supply is fully seated in the chassis slot. The power supply faceplate should be flush
with any adjacent power supply faceplates.
• The small tab on the metal housing that is controlled by the release lever must be
inside of the corresponding slot at the bottom of the power supply. This tab is used to
pull the power supply down in the chassis slot, prior to removing the power supply.
• While firmly pushing the handle on the power supply faceplate with one hand, use
your other hand to pull the spring-loaded locking pin in the release lever away from the
chassis and turn the release lever clockwise until it stops.
• Let go of the locking pin in the release lever. Ensure that the pin is seated inside the
corresponding hole in the chassis.
• Remove the clear plastic cover protecting the terminal studs on the faceplate.
• Loosen the captive screw on the cable restraint on the lower edge of the power supply
faceplate. Remove the cable restraint.
• Remove the nuts and washers from the RTN (return) terminal studs.
• Attach the positive (+) DC power source cable lug to the RTN (return) terminal studs.
• Secure the power cable lug to the terminal studs. Apply between 23 lb-in. (2.6 Nm)
and 25 lb-in (2.8 Nm) of torque to each nut.
• Remove the nuts and washers from the -48V (input) terminal studs.
• Attach the negative (–) DC source power cable lug to the –48-V (input) terminal.
• Secure the power cable lug to the terminal studs. Apply between 23 lb-in. (2.6 Nm)
and 25 lb-in (2.8 Nm) of torque to each nut.
• The DC power supplies in slots PEM0 and PEM1 must be powered by dedicated
power feeds derived from feed A, and the DC power supplies in slots PEM2 and
PEM3 must be powered by dedicated power feeds derived from feed B. This
configuration provides the commonly deployed A/B feed redundancy for the system.
• Make sure the positive and negative DC power cables run properly through the left
and right sides of the cable restraint.
• Tighten the cable restraint captive screws to hold the power cables in place. Verify
that the ground and power cabling are correct, they are not touching or blocking
access to router components, and they do not drape where people can trip on them.
• Replace the clear plastic cover over the terminal studs on the faceplate.
• Switch the circuit breaker on the power supply to the ON position and observe the
status LEDs on the power supply faceplate. If the power supply is correctly installed
and functioning normally, the PWR OK, BREAKER ON, and INPUT OK LEDs light
steadily.
Section Summary

• Describe a DC power supply.
to replace a DC power supply.
• Remove a DC power supply.
• Install a DC power supply.
Junos Operating System
Fundamentals
© 2012 Juniper Networks, Inc. All rights reserved. | www.juniper.net

The Junos OS
 Robust, modular operating system

•Provides industry-leading performance and scalability
•Based on the FreeBSD UNIX operating system
© 2012 Juniper Networks, Inc. All rights reserved. www.juniper.net | 2

Single Software Train
 A single software train for all platforms running the

Junos OS
•Eases management overhead by providing a consistent set
of features that are implemented in a consistent manner
12.0 12.1 …
J2320
TX Matrix

Separation of Control and Forwarding
 All platforms running the Junos OS share a common

design goal:
•Clean separation of control and forwarding functions
Routing Engine
RT FT The
Junos OS
Control Plane Internal Link
Forwarding Plane
FT
Frames/Packets In Frames/Packets Out
Packet Forwarding Engine
Routing Engine
 Maintains routing and forwarding tables

 Controls and monitors the chassis
 Manages the PFE
Routing Engine
RT FT The
Junos OS
Control Plane
Forwarding Plane

 Uses Layer 2 and Layer 3 forwarding tables, provided

by the RE, to forward traffic toward its destination
 Implements various services such as policing,
stateless firewall filtering, and class of service
Routing Engine
Control Plane
Forwarding Plane
FT
Transit Traffic Processing
 Transit traffic is forwarded through the local system

•PFE uses the forwarding table provided by the RE
•Examples of transit traffic include unicast and multicast
traffic
Routing Engine
CPU
Control Plane
Forwarding Plane
FT
Exception Traffic Processing (1 of 2)
 Exception traffic is processed by the local system

•Traffic destined for the local system is processed by RE CPU
•In most cases, the PFE processes traffic requiring the
generation of ICMP messages, such as TTL expired
Routing Engine
CPU
Control Plane
Forwarding Plane
Frames/Packets In
Frames/Packets Out

Exception Traffic Processing (2 of 2)
 Exception traffic is rate-limited on the internal link to

protect the RE from potential DoS attacks
•Control traffic is given preference when congestion exists
Routing Engine
CPU
Control Plane
Built-In Rate Limiting
Forwarding Plane
Frames/Packets In

Overview of Junos Devices
 Platforms running the Junos OS span switching,

routing, and security roles and are suited for small to
large networks in both enterprise and service provider
environments
Routing
Switching
Security

Junos Routing Devices
ACX Series LN Series M Series
MX Series PTX Series T Series

Junos Switching Devices
EX Series QFX Series

Junos Security Devices
J Series
SRX Series

User Interface Options

Common User Interface Options
 Junos CLI
•Text-based command shell
•Accessible through the console port using a terminal
emulation program
• Uses RJ-45 RS-232 @ 9600 Bps, 8/1/N (not configurable)
•Also accessible through network ports using an access
management protocol such as Telnet or SSH
• Requires network interface and related service configuration
• Many Junos devices include a dedicated management Ethernet
interface used for out-of-band access
 J-Web
•Web-based graphical user interface
•Accessible through an HTTP-enabled or HTTPS-enabled
browser
Logging In
 When logging in:

•Nonroot users are placed into the CLI automatically
router (ttyu0)
login: user
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

user@router>
•The root user must start the CLI from the shell
• Remember to exit the root shell after logging out of the CLI!
router (ttyu0)
login: root Shell Prompt

Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

root@router% cli CLI Prompt
root@router>

CLI Modes
 Operational mode:
•Monitor and troubleshoot the software, network
connectivity, and hardware
user@router> The > character identifies
operational mode
 Configuration mode:
•Configure the device, including interfaces, protocols, user
access, and system hardware properties
[edit]
user@router# The # character identifies
configuration mode

Context-Sensitive Help
 Type ? anywhere on the command line to get help:

user@router> ?
Possible completions:
clear Clear information in the system
configure Manipulate software configuration information
file Perform file operations
help Provide help information
. . .
user@router> clear ?
amt Show AMT Protocol information
arp Clear address resolution information
auto-configuration Clear auto-configuration action
bfd Clear Bidirectional Forwarding Detection information
. . .

Topical Help
 help topic provides topical information:

user@router> help topic interfaces ?
accept-data Accept packets destined for virtual address
accept-source-mac Policers for specific source MAC addresses
access-profile-chap CHAP profile associated with physical interface
accounting Packet counting for transit traffic
accounting-profile Accounting profile
acfc Compression of Address and Control fields in PPP header
...
user@router> help topic interfaces address

Configuring the Interface Address
You assign an address to an interface by specifying the address when

configuring the protocol family. For the inet family, configure the
interface's IP address. For the iso family, configure one or more
addresses for the loopback interface. For the ccc, tcc, mpls, tnp, and
vpls families, you never configure an address.
...

Help with Configuration Syntax
 help reference offers configuration syntax help:

user@router> help reference interfaces address
address
Syntax
address address {
arp ip-address (mac | multicast-mac) mac-address <publish>;
broadcast address;
...
Hierarchy Level
[edit interfaces interface-name unit logical-unit-number family family],

[edit logical-routers logical-router-name interfaces interface-name unit
logical-unit-number family family]
...

Command and Variable Completion
 Use the Spacebar to complete commands:

user@router> sh<space>ow i<space> Press the
'i' is ambiguous. Spacebar to
complete a
iccp Show Inter Chassis Control Protocol...
igmp Show Internet Group Management Protocol... command
igmp-snooping Show IGMP snooping information
interfaces Show interface information
ipv6 Show IP version 6 information
isdn Show Integrated Services Digital
isis Show Intermediate System-to-Intermediate...
user@router> show i
 Use the Tab key to complete commands and variables:

[edit policy-options]
user@router# show policy-statement t<tab>his-is-my-policy
then accept;
Press Tab to complete
user@router# assigned variables

Editing Command Lines
 Emacs-style editing sequences are supported:

• user@router> show interfaces
Keyboard
Sequence • Ctrl+b
user@router> show interfaces
• Ctrl+a
Cursor Position
• Ctrl+f
• Ctrl+e
 A VT100 terminal type also supports the Arrow keys

CLI Operational Mode
 Execute operational mode commands to monitor and
control the operation of devices running the Junos OS
•Hierarchy of commands
• Example: user@router> show ospf interface
Less Specific
clear configure help monitor set show …
arp configuration ospf version …
…
More Specific database interface neighbor

Operational Mode Capabilities
user@router> ?
clear Clear information in the system
configure Manipulate software configuration information
file Perform file operations
help Provide help information
load Load information from file
monitor Show real-time debugging information
mtrace Trace multicast path from source to receiver
op Invoke an operation script
ping Ping remote target
quit Exit the management session
request Make system-level requests
restart Restart software process
save Save information to file
set Set CLI properties, date/time, craft interface message
show Show system information
ssh Start secure shell on another host
start Start shell
telnet Telnet to another host
test Perform diagnostic debugging
traceroute Trace route to remote host

Active Versus Candidate Configuration
 Batch configuration model:

•Must commit configuration changes
 Active configuration:
•Current operational configuration
•Boot-up configuration
 Candidate configuration:
•A working copy for configuration changes
•Initialized with the active configuration
•Becomes active configuration upon commit

Overview: The Life of a Configuration File
commit
Candidate configure Active

Configuration Configuration
0
rollback n
1 2 ... 49
Bit Bucket

Entering Configuration Mode (1 of 2)
 Type configure at the operational mode prompt to
enter configuration mode:
user@router> configure
Entering configuration mode
[edit]
user@router#
 Use configure exclusive to exclude other users

from editing the configuration
•Any uncommitted changes are discarded when users exit:
user@router> configure exclusive
warning: uncommitted changes will be discarded on exit
[edit]
user@router#

Entering Configuration Mode (2 of 2)
 Use configure private to allow users to edit
private copies of candidate configuration concurrently
•When users issue a commit, their private changes merge
back into the global configuration
•Any uncommitted changes are discarded when users exit
•If two users make competing changes, the first user’s commit
succeeds, and the second user receives a warning
• The second user must issue a second commit to activate the change
walter@router> configure private
warning: uncommitted changes will be discarded on exit Allows other
Entering configuration mode users to edit
Users currently editing the configuration: private copies
nancy terminal p0 (pid 9935) on since 2010-05-11 17:11:22 UTC
private [edit] of the
candidate
[edit] configuration
walter@router#

Configuration Statement Hierarchy
[edit]
user@router# edit protocols ospf area 51 stub
[edit protocols ospf area 0.0.0.51 stub]

user@router#
[edit]
Less Specific
chassis interfaces protocols services system …
bgp isis mpls ospf pim rip rsvp vrrp …
area area_id graceful-restart overload traffic-engineering …
…
More Specific
area-range area_range interface nssa stub

Configuration File Is Hierarchical
 Enter CLI commands without curly brackets:

[edit system]
user@router# set services web-management http port 8080
•The result is a hierarchical configuration file, complete with

curly brackets
[edit system]
user@router# show services
web-management {
http {
port 8080;
}
}

Moving Between Levels (1 of 6)
 edit functions like a change directory command:
[edit]
user@router# edit protocols ospf area 51
stub

user@router# [edit]
area-range area_range interface nssa stub …

 up moves up one level in the hierarchy:
user@router# up
[edit protocols ospf area 0.0.0.51]

user@router#
[edit]

 up n moves up n levels in the hierarchy:
user@router# up 2
[edit protocols]
user@router# [edit]

 top moves to the top of the hierarchy:
user@router# top
[edit]
user@router# [edit]

 exit moves to the previous, higher level in hierarchy:
[edit protocols ospf]
user@router# edit area 51 stub

user@router# exit

user@router#
[edit]

 Summary of moving between levels:

• edit functions like a CD command
• up moves up one level
• up n moves up n levels
• top moves to the top of the hierarchy
• exit moves to the previous, higher level in the hierarchy or
exits configuration mode if at the top level of the hierarchy
[edit]
user@router# edit protocols ospf area 51 stub
user@router# up
user@router# up 2
[edit protocols]
user@router# top
[edit]
user@router# exit
The configuration has been changed but not committed
Exit with uncommitted changes? [yes,no] (yes)

Adding Configuration Statements
 Use set to add configuration statements:

[edit system services]
user@router# show
ssh;
telnet;

user@router# set ftp
FTP service added
user@router# show
ftp;
ssh;
telnet;

Removing Configuration Statements
 Use the delete command to remove statements

•Removes everything from the specified hierarchy down

user@router# show
ftp;
ssh;
telnet;

user@router# delete telnet
Telnet service removed
user@router# show
ftp;
ssh;

Test Your Knowledge
 Pop quiz: You just disabled an interface with a set

interface interface-name disable
statement. How do you re-enable this interface?

Helpful Configuration Mode Commands (1 of 2)
 Commands to aid in configuration:

• rename a configuration statement
[edit]
user@router# rename interfaces ge-0/0/10 to ge-0/0/11
• replace pattern of configuration statements
[edit]
user@router# replace pattern ge-0/0/10 with ge-0/0/11
• copy a configuration statement to another statement
[edit]
user@router# copy interfaces ge-0/0/10 to ge-0/0/11

Helpful Configuration Mode Commands (2 of 2)
 Commands to aid in configuration:

• deactivate or ignore a configuration statement
[edit]
user@router# deactivate interfaces ge-0/0/10
• insert a configuration statement in another location
[edit policy-options policy-statement test]
user@router# insert term three before term two
• annotate a comment to a configuration statement
[edit system]
user@router# annotate name-server “adding new name servers”

Viewing the Candidate Configuration
[edit]
user@router# show system You can display the portions that concern
services you from the root of the hierarchy…
ssh;
web-management {
http {
port 8080;
}
}
[edit]
user@router# edit system
services

…or use edit to park yourself at
user@router# show
ssh; a specific subhierarchy
web-management {
http {
port 8080;
} Hint: To view the set commands used to build the
}
configuration, use the show | display set command.
Committing a Configuration (1 of 2)
 Use commit to activate configuration changes:

[edit]
user@router# commit
commit complete
•If multiple REs are installed, use commit synchronize

 Use commit check to confirm syntax:
[edit]
user@router# commit check
[edit interfaces ge-0/0/10 unit 0]
'family'
When ethernet-switching family is configured on an interface, no
other family type can be configured on the same interface.
error: configuration check-out failed
 Use commit confirmed to temporarily activate:

[edit]
user@router# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless
confirmed
commit complete
Committing a Configuration (2 of 2)
 Use commit at to schedule a future commit:
[edit]
user@router# commit at 21:00:00
configuration check succeeds
commit at will be executed at 2010-05-11 21:00:00 UTC
Exiting configuration mode
 Use commit comment to add comments:

[edit]
user@router# commit comment "Changed OSPF
configuration"
commit complete
user@router> show system commit

0 2010-05-11 15:32:42 UTC by user via cli
Changed OSPF configuration
 Use commit and-quit to save time:

…
[edit]
user@router# commit and-
quit
commit complete
user@router>

Comparing Configuration File Differences
 Compare candidate and active configurations:

user@router# show | compare
+ ftp;
- telnet;
 Compare active and historical configurations:

user@router> show configuration | compare rollback number
user@router> show configuration | compare filename
 Compare arbitrary files:

user@router> file compare files filename_1 filename_2

Backing Out of Configuration Changes
 Use rollback to restore a previous configuration:

• rollback (or rollback 0 ) resets the candidate
configuration to the currently active configuration
• rollback 1 loads the previously active configuration
• rollback n loads referenced rollback version
[edit]
user@router# rollback ?
<[Enter]> Execute this command
0 2009-10-29 00:55:48 UTC by user via cli
1 2009-10-29 00:16:27 UTC by lab via cli
...
49 2009-02-05 03:11:00 UTC by lab via cli
 Modifies only the candidate configuration

•Do not forget to commit the changes!

Review: The Life of a Configuration File
commit
Candidate configure Active

Configuration Configuration
0
rollback n
1 2 ... 49
Bit Bucket

Saving Configuration Files
 Use save to save the current configuration:

•Saves only from the current hierarchy down
•Saves to user’s working directory by default
[edit]
user@router# save filename
Wrote 101 lines of configuration to 'filename'
• You can also specify a full path and filename or a URL (FTP and SCP)
[edit]
user@router# save path/filename
[edit]
user@router# save
ftp://user:password@router/path/filename
[edit]
user@router# save scp://user@router/path/filename

Loading Configuration Files
 Use the load command to load a configuration file:
[edit]
user@router# load ?
factory-default Override existing configuration with factory default
merge Merge contents with existing configuration
override Override existing configuration
patch Load patch file into configuration
replace Replace configuration data
set Execute set of commands on existing configuration
update Update existing configuration
•Use terminal to input from terminal capture buffer:

user@router# load (replace | merge | override) terminal
•Use relative to load from current configuration hierarchy:

user@router# load (replace | merge) (filename | terminal) relative
 Use commit to activate the candidate configuration

Using the run Command
 Use run to execute operational mode CLI commands

while in configuration mode
•Can save time when testing the effects of a recent change
[edit interfaces ge-0/0/12]
user@router# set unit 0 family inet address 10.250.0.141/16
Use run to test
user@router# commit configuration
commit complete changes without
leaving
[edit interfaces ge-0/0/12] configuration
user@router# run ping 10.250.0.149 count 1
PING 10.250.0.149 (10.250.0.149): 56 data bytes mode
64 bytes from 10.250.0.149: icmp_seq=0 ttl=255 time=0.967
ms
--- 10.250.0.149 ping statistics ---

1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.967/0.967/0.967/0.000 ms

Initial Configuration

Factory-Default Configuration
 Factory-default configurations:
•Allow access through root account (no password)
•Include system logging to track system events
•Contain additional parameters that are platform dependent
= Factory-default configuration file X
MX480
= Factory-default configuration file Y
EX8208

Loading a Factory-Default Configuration
 Use load factory-default to load a system’s

factory-default configuration
•Must set root password to activate configuration:
[edit]
user@router# load factory-default
warning: activating factory configuration
[edit]
user@router# set system root-authentication plain-text-
password
New password:
Retype new password:
[edit]
user@router# commit
commit complete
Required to activate configuration

Powering On and Off a Junos Device
 Follow safety guidelines when powering on devices

•Automatic power-on feature when power is interrupted
 Gracefully shut down the Junos OS before removing
power
•Use request system halt to gracefully halt the Junos
OS and help ensure file system integrity
•When the Junos OS has been halted, system power is
maintained
• Reboot with console activity
user@router> request system halt ?
at Time at which to perform the operation
in Number of minutes to delay before operation
media Boot media for next boot
message Message to display to all users
| Pipe through a command

Initial Configuration Checklist
 Initial configuration:
•Must include root password (restrictions exist):
[edit]
user@router# set system root-authentication plain-text-password
New password: ***
error: minimum password length is 6
error: require change of case, digits or punctuation
•Typically also includes:

• Hostname
• System time
• Remote access protocols to be used (Telnet, SSH)
• Management interface and static route for management traffic

Initial Configuration (1 of 4)
 Log in as root with a null password:

Amnesiac (ttyu0)
Amnesiac prompt indicates a
login: root factory-default configuration
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

root@%
 Start the CLI:

UNIX shell prompt
root@% cli
root>
Operational mode prompt
 Enter configuration mode:

root> configure
[edit]
Configuration mode prompt
root#

 Set the identification parameters:

•Hostname
•Root password
[edit]
root# edit system
[edit system]
root# set host-name router
[edit system]
root# set root-authentication plain-text-password
New password:
Retype new password:
Passwords entered must match and meet minimum

requirements or an error will be displayed

 Set the time parameters:

•Time zone
•Current time
[edit system]
root# set time-zone America/Los_Angeles
[edit system]
root# run set date 201204250900.00
Wed April 25 09:00:00 UTC 2012
 Set the management access parameters:

•Telnet or SSH
[edit system]
root# set services telnet
[edit system]
root# set services ssh

 Set the management network parameters:

•Management interface address
Management interface name varies
•Static route for management traffic between Junos devices
[edit system]
root# top
[edit]
root# set interfaces interface name unit 0 family inet address 10.0.1.131/27
[edit]
root# set routing-options static route 10.0.1.0/24 next-hop 10.0.1.129
 Commit the changes!

[edit] Evidence that configuration
root# commit and-quit changes have taken effect
commit complete
root@router>

Viewing the Results
 Use show configuration to view the results:

root@router> show configuration
## Last commit: 2011-05-01 21:00:46 UTC by root
version 12.1R1.9;
system {
host-name host;
time-zone America/Los_Angeles;
root-authentication {
encrypted-password "$1$e/FUEOVo$JF6NiAZxuufGFxDs1OMAr/"; ##
SECRET-DATA
}
services {
ssh;
telnet;
}
syslog {
...

The Rescue Configuration
 A rescue configuration is designed to restore basic

connectivity in the event of configuration problems
•Contents of configuration are user-defined and, by default, no
rescue configuration exists
Saves active configuration as
root@router> request system configuration rescue the rescue configuration
save
Deletes the current

root@router> request system configuration rescue rescue configuration
delete
[edit]
root@router# rollback rescue
load complete
Loads and activates the current
[edit] rescue configuration
root@router# commit
commit complete

Overview of Interfaces
 Interfaces connect to networks or provide a service—

examples of interfaces include:
•Management: Connects to management network
•Internal: Connects control and forwarding planes
•Network: Provides media-specific network connectivity;
media examples include Ethernet, SONET, ATM, and so forth
•Services: Provides specific capabilities for manipulating
traffic before it is delivered to its destination
•Loopback: Logical interface that is always up; all Junos
devices use the lo0 designation for this interface

Interface Naming
 Most interfaces are named according to: Note: While different

•Interface media type (ge, so, at, and so forth) platforms use different
names for line cards and
interface cards, the CLI
•Line card (FPC) slot number almost always uses FPC
and PIC
•Interface card (PIC) slot number
•Port number
Interface Card
Interface naming example: PIC
ge-0/2/3 = port 3 of a Gigabit Ethernet PIC in slot 2 on FPC 0

PIC
Note: Slot and port numbering begins Line card

with zero (0) rather than one (1) FPC
PIC
 Other interface name designations

PIC
exist, such as lo0, vlan, ae, and
so forth
Logical Units
 Similar to subinterfaces used by other vendors

•In the Junos OS, a logical unit is always required
 Some encapsulations support only one logical unit
•Unit number must be zero for these encapsulations
 Logical unit numbers are separate in meaning from
circuit identifiers and do not need to match
•We suggest keeping them the same
 Support multiple protocol addresses
•Watch for multiple addresses when correcting mistakes!
ge-0/0/14.51

Interface Properties (1 of 2)
 Physical properties settings include:

•Data Link Layer protocol
•Link speed and duplex
•Physical MTU
 Logical properties settings include:
•Protocol family:
• inet
• inet6
• iso
• mpls
• ethernet-switching
•Addresses (IPv4 or IPv6 address and ISO NET address)
•Virtual circuits (VLAN tag, DLCI, and VPI or VCI)
Interface Properties (2 of 2)
 Physical and logical interface properties are configured

at their respective levels:
interfaces { Physical properties are configured

interface-name { under the interface-name
physical-properties;
[…]
unit unit-number {
logical-properties;
[…]
} Logical properties are configured
} under the unit-number
}

Interface Configuration Example
 Layer 3 interface configuration example:

[edit]
user@router# show interfaces Note: Multiple addresses
ge-0/0/2 { supported on a single unit
unit 0 {
family inet {
address 172.19.102.1/24;
address 172.19.102.2/24 {
preferred; Use preferred option to select
} preferred address for interface
}
family inet6 {
address 3001::1/64;
}
}
}
lo0 {
unit 0 { Note: Multiple protocol families supported on
family inet { same logical unit (family inet is used for IPv4
address 192.168.100.1/32; and family inet6 is used for IPv6
address 192.168.200.1/32 {
primary; Use primary option to select
} primary address for interface
}
}
© 2012 Juniper
} Networks, Inc. All rights reserved. www.juniper.net | 17
Tracking Interface State
 Use show interfaces terse to quickly verify the

state of interfaces
•Specify interface name to filter generated output:
user@router> show interfaces ge-0/0/2 terse
Interface Admin Link Proto Local Remote
ge-0/0/2 up up
ge-0/0/2.0 up up inet 10.15.173.1/28
172.19.102.1/24
inet6 3001::1/64
fe80::217:cbff:fe4e:a282/64
Admin and link status
Protocol family details
Address information

Secondary System
Configuration

User Authentication
 Local database
•Name and password
•Individual accounts and home directories
 RADIUS and TACACS+
•Centralized user management
•Users mapped to locally defined template users
Local
authentication
database
RADIUS or TACACS+
server

Authentication Order
 Order of authentication methods is configurable

•Attempts each configured method until password is accepted
•If radius and tacplus authentication methods fail to
reply, local authentication (password) is always consulted
[edit]
user@router# show system authentication-order
authentication-order [ radius tacplus password ];
Supported authentication methods

Authentication Order Example (1 of 3)
[edit]
authentication-order [ radius tacplus password ];
RADIUS server
Username = lab Password = lab123
Step 1 (lab, lab789)

Step 4 (lab, lab789) TACACS+ server
Step 8 ACCEPT Step 5 REJECT
Local authentication database


[edit]
authentication-order [ radius tacplus ];
RADIUS server

Step 6 REJECT Step 5 REJECT


[edit]
authentication-order [ radius tacplus ];
RADIUS server

Step 6 ACCEPT


Components of Authorization (1 of 2)
deny-commands allow-commands Authorized
User Class Permissions or
deny-configuration allow-configuration
Denied
 User CLI activity is either authorized or denied based

on the components of authorization
 Users
•Member of a single class
 Class
•Container for permissions and explicit overrides
•Four predefined classes for common groups of permissions
• operator, read-only, super-user, and unauthorized

Components of Authorization (2 of 2)
Denied
 Permissions
•Predefined sets of related commands
 Allow and deny overrides
•Define exceptions for commands and configuration
statements that would otherwise be allowed or denied
•Can be specified using regular expressions

Authorization Configuration Example
Denied
[edit system login]

root@router# show
class noc-admin {
permissions [ clear network reset view ];
allow-commands "(configure private)";
deny-commands "(file)";
allow-configuration "(interfaces) | (firewall)";
deny-configuration "(groups)";
}
user nancy {
uid 2002;
class noc-admin;
authentication {
encrypted-password "$1$KQXKa/VQ$ijv77WXLnyf7XR/.1IbTq0"; ## SECRET-DATA
}
}

System Logging Overview
 System logging:
•Uses UNIX syslog-style configuration syntax
• Primary syslog file is /var/log/messages
•Supports numerous facilities and severity levels
• The facility defines the class of log message and the severity level
determines the level of logging detail
•Provides local and remote logging support
• Remote logging (and archiving) recommended for troubleshooting

Syslog Configuration Example
[edit system syslog]
user@router# show
user * { Emergency messages go to all logged-in users (*)
any emergency;
}
host 10.210.14.174 { Logs to a remote host (recommended
any notice; for archiving logged events)
authorization info;
}
file messages { Primary syslog file (*)
any any;
authorization info;
}
file interactive-commands { Logs all CLI commands (*)
interactive-commands any;
}
file config-changes { Logs configuration changes (recommended
change-log info; for tracking user activity)
}
Note: (*) indicates a factory-default setting

Interpreting Syslog Messages
 Standard log entries consist of the following fields:

•Timestamp, host name, software process name or PID, a
message code, and the message text
Jul 27 10:48:37 host mgd[4350]: UI_DBASE_LOGOUT_EVENT: User 'user' exiting
configuration mode
 Use help syslog to help interpret message codes:

user@router> help syslog UI_DBASE_LOGOUT_EVENT
Name: UI_DBASE_LOGOUT_EVENT
Message: User '<username>' exiting configuration mode
Help: User exited configuration mode
Description: The indicated user exited configuration mode (logged out of the
configuration database).
Type: Event: This message reports an event, not an error
Severity: notice

Traceoptions Overview
 Tracing is the Junos OS equivalent of debug

•Requires configuration
•Provides local and remote logging support
• Logs are written to /var/log/filename or a remote server
•Can enable tracing in a production network

Traceoptions Configuration Example
 Include the traceoptions statement at the [edit
protocols protocol-name] hierarchy level
•Traceoptions also available for other hierarchies
The protocol or function being traced
File where trace results are written
(/var/log/ospf-trace)

user@router# show
traceoptions {
file ospf-trace replace size 128k files 10 no-stamp no-world-readable;
flag event detail;
flag error detail;
}
Trace file options
Can trace multiple options (flags) to a single file--

flags identify what aspects of the protocol are
traced and at what level of detail

Analyzing Log and Trace Files
 Use show log file-name to display file contents:

•Enter h at the more prompt for help on available options
•Use pipe (|) to make log parsing much easier!
• Syntax:
user@router> show log messages | match "support info"
May 31 23:49:16 host mgd[2711]: %INTERACT-6-UI_CMDLINE_READ_LINE:
User 'user', command 'request support information '
• Use multiple instances to evoke a logical AND search:

user@router> show log messages | find "Apr 1 09:" | match error
• Use quotes to evoke a logical OR search:

user@router> show log messages | match "error|kernel|panic"

Miscellaneous Log File Commands
 Use monitor to perform real time monitoring:

user@router> monitor start filename
•Use pipe (|) to filter file being monitored!

•Use Esc+q to halt and resume real-time output to screen
•Use monitor stop to cease all monitoring
 Log and trace file manipulation
•Use clear to clear contents of log and trace files:
user@router> clear log filename
•Use file delete to delete log and trace files:

user@router> file delete filename

NTP Clock Synchronization
 Use NTP to synchronize clocking on network devices

•Correlated timestamps on log files for troubleshooting
•The Junos OS cannot provide primary time reference
•Support for client, server, and symmetric active modes
•Message Digest 5 authentication support
[edit system ntp]

Boot server is used to set initial user@router# show The configured list of possible
NTP time upon boot boot-server synchronization sources
10.210.14.173;
server 10.210.14.173;
A simple NTP client-mode configuration

Monitoring NTP Clock Synchronization
 Use the show ntp associations command to

confirm synchronization status:
[edit]
user@router# run show ntp associations
remote refid st t when poll reach delay offset jitter

==============================================================================
*10.210.14.173 10.210.8.73 4 u 63 64 377 0.268 -24.258 7.290
Indicates peer stratum level
IP address or name of peer reference
IP address or name of NTP peer
Asterisk indicates that this peer was selected for synchronization

Archiving Configuration Files
 Configure host to automatically back up configuration

file at the [edit system archival] hierarchy
•Perform regular backups at scheduled intervals or whenever
a new configuration file is committed
Backup occurs when
commit is issued
[edit system archival]
user@router# show
configuration {
transfer-on-commit;
archive-sites {
"ftp://user@10.210.9.178:/archive" password "$9…"; ## SECRET-DATA
"scp://user@172.15.100.2:/archive" password "$9…"; ## SECRET-DATA
}
}
First URL listed is used unless transfer fails
Transfer options include
both FTP and SCP

Monitoring the Archival Process
 Configuration files are queued for transmission in the

/var/transfer/config directory
•The transfer is logged in the /var/log/messages file:
user@router> show log messages | match transfer
Jan 21 13:52:45 host logger: transfer-file: Transferred
/var/transfer/config/host_juniper.conf.gz_20120425_215150
[edit]
user@router> file list /var/transfer/config detail
Destination filename format:
/var/transfer/config: host-name_juniper.conf.gz_YYYYMMDD_HHMMSS_UTC time
total 12
-rw-r----- 1 root wheel 1530 Apr 25 13:51 host_juniper.conf.gz_20120425_215150
Output from the UNIX server
instructor@server1.dx1.sv$pwd
/home/ftp/pub/archive
instructor@server1.dx1.sv$ls
host_juniper.conf.gz_20120425_215150

SNMP Overview (1 of 2)
 SNMP facilitates communication between an SNMP

agent and a network management system
•NMS and agent communication:
• Get, GetBulk, and GetNext requests
• Set requests
• Notifications (traps—SNMP v2c or informs—SNMP v3)
•Agents respond to requests from NMS and send
notifications of network events (traps and informs)
Poll
Agent (device running

NMS the Junos OS)
Response
SNMP Overview (2 of 2)
 MIB:
•Used to define managed objects in a network device
•Designed in hierarchical tree structure
•Standard or enterprise specific
•Consists of object identifiers
 Junos SNMP support:
•Versions 1, 2c, and 3
•Remote monitoring events, alarms, and history

Example: Configuring SNMP
[edit snmp]
user@router# show
description “My JUNOS Device";
Device contact
information location "BSU East Campus Closet - Rack 4";
contact "Jim Davis - x1865"; Default authorization
community cardinals {
authorization read-only;
clients { SNMP requests limited
Defining an SNMP 10.210.14.0/24; to 10.210.14/24
community is the subnet; can also
minimum SNMP
}
} restrict to an interface
configuration
trap-group my-trap-group {
version v2; Sends SNMPv2
categories { notifications
chassis; regarding link or
link; chassis events
}
targets {
Defines NMS for
trap delivery 10.210.14.173;
}
}

Monitoring SNMP Operation
 Operation:
•Monitor the SNMP agent with NMS tools
•Monitor SNMP protocol using traceoptions, syslog, and
show commands
•MIB walks and gets are available from the CLI:
user@router> show snmp mib walk jnxOperatingDescr
jnxOperatingDescr.1.1.0.0 = midplane
jnxOperatingDescr.2.1.1.0 = Power Supply 0
jnxOperatingDescr.2.1.2.0 = Power Supply 1
jnxOperatingDescr.4.1.1.1 = FAN 0
jnxOperatingDescr.7.1.0.0 = FPC: EX3200-24T, 8 POE @ 0/*/*
jnxOperatingDescr.8.1.1.0 = PIC: 24x 10/100/1000 Base-T @ 0/0/*
jnxOperatingDescr.8.1.2.0 = PIC: 4x GE SFP @ 0/1/*
jnxOperatingDescr.9.1.0.0 = RE-EX3200-24-T

Operational Monitoring and
Maintenance

Monitoring Tools
 Primary monitoring tool is the Junos CLI, which
includes operational show and monitor commands
•Secondary monitoring tools include J-Web, SNMP, hardware
LEDs, and front-panel displays or LCDs
Junos CLI
SNMP LEDs
J-Web LCDs

Monitoring System-Level Operation
 Use show system commands to monitor system-

level operations:
user@router> show system ?
alarms Show system alarm status
audit Show file system MD5 hash and permissions
autoinstallation Show autoinstallation information
autorecovery Show autorecovery information
boot-messages Show boot time messages
buffers Show buffer statistics
certificate Show installed X509 certificates
commit Show pending commit requests (if any) and commit history
configuration Show configuration information
connections Show system connection activity
core-dumps Show system core files
directory-usage Show local directory information
download Show status of downloads
firmware Show all firmware version information
license Show feature licenses information
...

Monitoring the Chassis
 Use show chassis commands to monitor the
chassis and obtain chassis information:
user@router> show chassis ?
alarms Show alarm status
cluster Show chassis cluster information
craft-interface Show craft interface status
environment Show component status and temperature, cooling ...
fan Show fan and fan tray information
firmware Show firmware and operating system version for components
forwarding Show forwarding process (fwdd) status
fpc Show Flexible PIC Concentrator status
hardware Show installed hardware components
location Show physical location of chassis
mac-addresses Show media access control addresses
pic Show Physical Interface Card state, type, and uptime
routing-engine Show Routing Engine status
temperature-thresholds Show chassis temperature threshold settings

Verifying Interface Status
 Use show interfaces commands to verify
interface status and view interface details:
•Include options to increase or decrease displayed details
•Include interface name to limit output to that interface
user@router> show interfaces ge-0/0/0 ?
brief Display brief output
descriptions Display interface description strings
detail Display detailed output
extensive Display extensive output
media Display media information
routing-instance Name of routing instance
snmp-index SNMP index of interface
statistics Display statistics and detailed output
switch-port Front end port number (0..15)
terse Display terse output

Terse Output Example
 Use show interfaces terse to quickly verify the
state of all physical and logical interfaces:
user@router> show interfaces terse
ge-0/0/0 up up
ge-0/0/0.0 up up inet 172.18.36.1/24
ge-0/0/1 up up
ge-0/0/1.0 up up inet6 fd73:5d2a:f03b:15e0::1/64
fe80::217:cbff:fe4e:a281/64
ge-0/0/2 up up
ge-0/0/2.0 down up inet 172.19.25.1/28
iso
mpls
ge-0/0/3 down up
ge-0/0/3.0 up down inet
…
Administratively disabled

Extensive Output Example
 Use show interfaces extensive to view
interface status, properties, statistics, and errors:
•Useful tool when troubleshooting interfaces
user@router> show interfaces ge-0/0/0 extensive
Physical interface: ge-0/0/0, Enabled, Physical link is Up
Interface index: 129, SNMP ifIndex: 32, Generation: 130
Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
Remote fault: Online
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Hold-times : Up 0 ms, Down 0 ms
Current address: 00:17:cb:4e:a2:80, Hardware address: 00:17:cb:4e:a2:80
Last flapped : 2010-10-03 20:46:59 UTC (8w6d 07:27 ago)
Statistics last cleared: 2010-10-15 21:16:11 UTC (7w1d 06:58 ago)
Traffic statistics:
…

Monitoring Interfaces
 Use monitor interface interface-name to
view interface usage details in real time:
router Seconds: 23 Time: 06:11:08
Delay: 0/0/2
Interface: ge-0/0/0.0, Enabled, Link is Up
Flags: SNMP-Traps
Encapsulation: ENET2
Local statistics: Current delta
Input bytes: 146945 [13768]
Output bytes: 33911 [14327]
Input packets: 2383 [185]
Output packets: 313 [70]
Remote statistics:
Input bytes: 48 (4824 bps) [0]
Output bytes: 240 (0 bps) [0]
Input packets: 11 (0 pps) [7]
Output packets: 4 (0 pps) [0]
Traffic statistics:
Input bytes: 146993 Output bytes: , [0]
Next='n', Quit='q' or ESC, Freeze='f', Thaw='t', Clear='c', Interface='i'

Network Utilities: Part 1
 Use the ping and traceroute commands to test

reachability and determine the forwarding path
•Use Ctrl+c to stop the ping and traceroute operations
user@router> ping 10.210.14.173
PING 10.210.14.173 (10.210.14.173): 56 data bytes
64 bytes from 10.210.14.173: icmp_seq=0 ttl=64 time=0.345 ms
^C
--- 10.210.14.173 ping statistics ---
user@router> traceroute 10.210.14.173

traceroute to 10.210.14.173 (10.210.14.173), 30 hops max, 40 byte pkts
1 10.210.14.173 (10.210.14.173) 2.872 ms 0.203 ms 0.150 ms

 Use monitor traffic to decode packets:

•Captures traffic sourced from or destined to device
• Use options to modify or filter captured traffic; the following are
some common options:
user@router> monitor traffic ?
…
detail Display detailed output
extensive Display extensive output
interface Name of interface
layer2-headers Display link-level header on each dump line
matching Expression for headers of receive packets to match
…

Packet Capture Example
Use the detail or extensive option for complete decode
user@router> monitor traffic interface ge-0/0/2 layer2-headers no-resolve

verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on ge-0/0/2, capture size 96 bytes
06:19:35.121217 In 0:1b:c0:5e:53:a2 > 0:19:e2:50:3f:e3, ethertype IPv4 (0x0800),

length 98: 10.100.200.1 > 10.100.200.2: ICMP echo request, id 5153, seq 222, length 64
06:19:35.121269 Out 0:19:e2:50:3f:e3 > 0:1b:c0:5e:53:a2, ethertype IPv4 (0x0800),
length 98: 10.100.200.2 > 10.100.200.1: ICMP echo reply, id 5153, seq 222, length 64
^C
10 packets received by filter
0 packets dropped by kernel
Ctrl+c key sequence exits listening mode

 Access Telnet, SSH, and FTP client commands from

the CLI:
user@router> telnet ?
<host> Hostname or address or remote host
8bit Use 8-bit data path
bypass-routing Bypass routing table, use specified interface
inet Force telnet to IPv4 destination
inet6 Force telnet to IPv6 destination
interface Name of interface for outgoing traffic
no-resolve Don't attempt to print addresses symbolically
port Port number or service name on remote host
routing-instance Name of routing instance for telnet session
source Source address to use in telnet connection
user@router> telnet 127.0.0.1

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
router (ttyp0)
login: user
Password:
. . .

Displaying the Junos OS Release
 Use show version to view the current release of

the Junos OS:
user@router> show version
Hostname: srxA-1
Model: srx240h-poe
JUNOS Software Release [12.1R1.9]

The Junos Naming Convention
 The Junos OS uses the following naming convention:
package-release-edition
• package: name of the Junos OS package; examples include
jinstall, jinstall-ex, junos-jsr, and junos-srx
• release: includes major and minor release numbers,
release type (R, B, or I), build number, and spin number
• edition: image is either domestic or export
• Encryption capabilities differ between domestic and export editions
jinstall-12.1R1.9-domestic-signed.tgz
Junos images are digitally
Package Release Edition signed and compressed

Upgrading the Junos OS
 Download the Junos OS from the download site:

•Valid customer login is required
•Download Junos images from the download site through a
Web browser or an FTP client
• Ensure you download the proper image for your platform
 Use request system software add to upgrade
or downgrade the Junos OS:
•Specify local path and image name or retrieve an image by
specifying a URI to remote FTP or SCP server
• The Junos OS only executes signed binaries

Upgrade Example
Recommended storage location if image
is copied to the local device
user@router> request system software add /var/tmp/image-name reboot
Installing package '/altroot/cf/packages/install-tmp/junos-12.1R1.9-domestic'

Verified junos-boot-srxsme-12.1R1.9.tgz signed by PackageProduction_12_1_0
Verified junos-srxsme-12.1R1.9-domestic signed by PackageProduction_12_1_0
JUNOS 12.1R1.9 will become active at next reboot
Saving state for rollback ...
Rebooting ...
shutdown: [pid 7644]
Shutdown NOW!
A reboot is always required to activate new software

Unified ISSU
 Unified ISSU
• Enables you to upgrade between two different Junos OS releases
with no disruption on the control plane
• Eliminates network downtime during software image upgrades
• Reduces operating costs, while delivering higher service levels
• Allows fast implementation of new features
Nonstop Active Routing
RE 0 RE 1
Master Backup
Data Flow
PFE

Perform a Unified ISSU
 To perform a unified ISSU, complete the following

steps:
1. Enable GRES and NSR, and verify that the REs and
protocols are synchronized
2. Download the new software package from the Juniper
Networks Support Web site and then copy the package to
the router
3. Issue the request system software in-
service-upgrade command on the master RE

Password Recovery Process
 Must have a console connection

 Steps:
1. Reboot the system
• Press the Spacebar when prompted
• Enter boot –s to access single user mode
2. Enter recovery when prompted to go into recovery mode
3. Set root password
4. Commit the change and exit configuration mode—reboot
when prompted

Protocol-Independent
Routing

Review: Static Routes
 Manually defined routes added to route table

•A default route is an example of a static route
R1
ge-0/0/1
Network A ISP X
172.29.100.0/24 .1 .2 .1
172.30.25.0/30
192.168.63.14
user@R1> show route 192.168.63.14
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 01:09:34 Default static route with

> to 172.30.25.1 via ge-0/0/1.0 default preference

Configuring Static Routes
 Defined under the [edit routing-options]

hierarchy level and consists of destination prefix and
valid next hop
•Next hop is typically the IP address of a directly connected
device; other options exist such as discard and reject
• Use qualified-next-hop to allow independent preference
for static routes to the same destination
• Use resolve if the specified next hop is not directly connected
172.30.25.0/30
ge-0/0/1
R1
.2 Primary .1
Network A ISP X
172.29.100.0/24
.1 .6 Secondary .5
ge-0/0/2
172.30.25.4/30
Note: Routes with invalid or unreachable next hops will not become active!

Configuration Example
 Sample IPv4 and IPv6 static route configuration:

[edit routing-options]
user@R1# show
rib inet6.0 {
static {
route 0::/0 { IPv6 default static route
next-hop 3001::1;
preference 250;
}
} Parameters defined under defaults
} section are applied to IPv4 static routes
static {
defaults {
that do not include explicit definitions
preference 250;
}
route 0.0.0.0/0 { IPv4 default static route with
next-hop 172.30.25.1;
secondary qualified next hop
qualified-next-hop 172.30.25.5 {
preference 251;
}
}
route 172.28.102.0/24 { Restricts route from being advertised
next-hop 10.210.11.190; through routing policy; highly suggested for
no-readvertise; static routes used for management traffic
}
}

Test Your Knowledge (1 of 2)
 Which next hop will be used in the example?

user@R1# show
static {
defaults {
preference 180;
}
route 0.0.0.0/0 {
next-hop 172.30.25.1;
qualified-next-hop 172.30.25.5 {
preference 7;
}
}
}
172.30.25.0/30
ge-0/0/1
R1
.2 .1
Network A
172.29.100.0/24 ISP-X
.1 .6 .5
ge-0/0/2
172.30.25.4/30

Test Your Knowledge (2 of 2)
 Which static routes will be exported into OSPF?

[edit routing-options] [edit policy-options]
user@R1# show user@R1# show
static { policy-statement export2ospf {
route 172.29.12.0/24 next-hop 172.30.25.1; term match-static-routes {
route 172.29.13.0/24 { from {
next-hop 172.30.25.1; protocol static;
no-readvertise; route-filter 172.29.0.0/16 orlonger;
} }
route 172.29.16.0/24 next-hop 172.30.25.1; then accept;
route 172.29.20.0/24 next-hop 172.30.25.1; }
} }

user@R1# show
export export2ospf;
area 0.0.0.0 {
interface ge-0/0/2.0; 172.29.12.0/24
R1
interface ge-0/0/3.0;
172.29.13.0/24
interface lo0.0; OSPF ge-0/0/1
} Area 0 .2 .1 172.29.16.0/24
172.30.25.0/30
172.29.20.0/24

Aggregate Routes
 Manually defined routes that represent a collection of

more specific routes
•Typically used to reduce number of route advertisements
Network A 172.29.0.0/22
172.29.0.0/24
.1 R1
Network B .1 ge-0/0/1
ISP X
172.29.1.0/24 .2 .1
172.30.25.0/30
.1
Network C
172.29.2.0/24

Think About It…
 Which of the prefixes are part of the 10.1.0.0/20

aggregate route?
•10.1.14.0/24
•10.1.15.0/24
•10.1.16.0/24
•10.1.17.0/24

Configuring Aggregate Routes
 Defined under the [edit routing-options]
hierarchy level and consists of destination summary
prefix
•Aggregate routes must have at least one contributing route!
Network A
172.29.0.0/24 172.29.0.0/22
.1 R1
ISP X
172.29.1.0/24 .2 .1
172.30.25.0/30
.1
Network C user@R1> show route protocol aggregate

172.29.2.0/24
172.29.0.0/22 *[Aggregate/130] 00:02:23

Reject Default route preference and
next hop for aggregate routes

 Sample aggregate route configuration:

user@R1# show
aggregate {
defaults { Parameters defined under defaults
community 1:888; section are applied to aggregate routes
} that do not include explicit definitions
route 172.29.0.0/22;
route 172.25.0.0/16 {
community 1:999;
discard; discard next hop silently discards packets
} destined to a contributing subnet for which a
} more specific route entry does not exist
Note: The default next hop for aggregate routes is reject, which sends an ICMP
unreachable message when a more specific contributing route does not exist.

Viewing the Contributing Routes
 Use show route prefix exact detail to

view detailed information for an aggregate route
user@R1> show route 172.29.0.0/22 exact detail

172.29.0.0/22 (1 entry, 1 announced)
*Aggregate Preference: 130 Default route preference and
Next hop type: Reject next hop for aggregate routes
Next-hop reference count: 2
State: <Active Int Ext>
Age: 1:39:21
Task: Aggregate
Announcement bits (1): 0-KRT
AS path: I (LocalAgg)
Flags: Depth: 0 Active
AS path list:
AS path: I Refcount: 3
Contributing Routes (3):
172.29.0.0/24 proto Direct
Contributing routes 172.29.1.0/24 proto Direct
172.29.2.0/24 proto Direct
Note: Other commands provide similar information.

Test Your Knowledge
 What action does R1 take when it receives packet A
and packet B (assume the default next-hop behavior)?
Network A Advertised Route

172.29.0.0/24 172.29.0.0/22
.1 R1
ISP X
172.29.1.0/24 .2 .1
172.30.25.0/30
.1
Network C
172.29.2.0/24
Packet A Destined to 172.29.1.5
Packet B Destined to 172.29.3.5

Contributing routes for the 172.29.0.0/22 aggregate
route advertised from R1 to the upstream provider

Generated Routes
 Very similar to aggregate routes

•Key difference is the use of a forwarding next hop, which is
the next hop associated with the primary contributing route
•Can be used to generate a route of last resort (often a
default route) when required conditions are met
• Uses routing policy to identify required conditions
R1
Tier 1 ISP Customer X
Regional ISP
10.0.0.0/16 0/0
Core prefixes sent from Default route is sent from regional

Tier 1 ISP to regional ISP ISP to customer X if core prefixes
are active in R1’s route table

Case Study: Topology and Objective
 Configure R1 to generate and advertise a default

route into OSPF when the 10.0.0.0/16 BGP route is
present in its routing table
10.0.0.0/16
R2
R1
OSPF ge-0/0/1 ISP X
Area 0 .2 .1
172.30.25.0/30
R3

Case Study: Creating the Generated Route
 Sample generated route configuration:

user@R1# show
generate {
defaults { Parameters defined under defaults
preference 130; section are applied to generated routes
} that do not include explicit definitions
route 0.0.0.0/0;
}
…
10.0.0.0/16
R2
R1
OSPF ge-0/0/1 ISP X
Area 0 .2 .1
172.30.25.0/30
R3
Note: The default next hop for generated routes is the

next hop associated with the primary contributing route.
In our example, this default next hop will be 172.30.25.1.

Case Study: Defining the Required Policy
 Sample routing policy configuration:

user@R1# show policy-statement match-contributing-prefix Policy matches 10.0.0.0/16
term match-bgp-prefix { prefix exactly and rejects all
from { other potential contributors
protocol bgp;
route-filter 10.0.0.0/16 exact;
}
then accept;
}
term else-reject {
then reject;
}
user@R1# show policy-statement export-default Policy matches generated
term match-default { route defined on the previous
from { slide
protocol aggregate;
} The protocol aggregate match condition is
then accept; used for aggregate and generated routes
}

Case Study: Applying the Required Policy
 Sample routing policy application:

user@R1# show
generate {
defaults {
preference 130;
}
route 0.0.0.0/0 policy match-contributing-prefix;
}
…

user@R1# show The export-default policy exports
export export-default; the default generate route only when
area 0.0.0.0 { the required condition is met.
interface lo0.0;
}

Case Study: Monitoring the Results (1 of 2)
 Use the show route 0/0 exact detail

command on R1 to verify details of generated route:
user@R1> show route 0/0 exact detail

0.0.0.0/0 (1 entry, 1 announced)
*Aggregate Preference: 130
Next hop type: Router, Next hop index: 546
Next hop: 172.30.25.1 via ge-0/0/1.100, selected
Local AS: 65400
Age: 1:03:46
Task: Aggregate
Announcement bits (2): 0-KRT 2-OSPF
AS path: I
Flags: Generate Depth: 0 Active
Contributing Routes (1):
10.0.0.0/16 proto BGP

Case Study: Monitoring the Results (2 of 2)
 Use the show route 0/0 exact command on R2

or R3 to verify that the route was received through
OSPF:
user@R2> show route 0/0 exact

0.0.0.0/0 *[OSPF/150] 00:15:30, metric 0, tag 0

> to 172.20.12.1 via ge-0/0/2.0
10.0.0.0/16
R2
R1
OSPF ge-0/0/1
ISP X
Area 0 .2 .1
172.30.25.0/30
R3

Overview: Martian Addresses
 Prefixes ignored by the Junos OS

•Martian addresses are never installed in the routing table
•Default Martian addresses include:
• 0.0.0.0/8 orlonger
• 127.0.0.0/8 orlonger
• 128.0.0.0/16 orlonger
• 191.255.0.0/16 orlonger
• 192.0.0.0/24 orlonger
• 223.255.255.0/24 orlonger
• 240.0.0.0/4 orlonger

Adding Prefixes as Martian Addresses
 Add additional prefixes to the Martian list under the

[edit routing-options] hierarchy level
user@R1# show martians
23.0.0.0/8 orlonger;
31.0.0.0/8 orlonger; Specify prefix and match-type
36.0.0.0/8 orlonger;
 Use show route martians to view the list of

registered Martian addresses
user@R1> show route martians
inet.0:
…
23.0.0.0/8 orlonger -- disallowed
31.0.0.0/8 orlonger -- disallowed Prefixes are added to list
36.0.0.0/8 orlonger -- disallowed
Default list omitted

Review: Routing Instances
 A routing instance is a unique collection of routing

tables, interfaces, and routing protocol parameters
Device Running the Junos OS

Routing Instance (master) Routing Instance (cust-A) Routing Instance (cust-B)
inet.0 cust-A.inet.0 cust-B.inet.0
inet6.0 cust-A.inet6.0 cust-B.inet6.0
ge-0/0/0.0 ge-0/0/3.0 ge-1/0/0.0
ge-0/0/1.0 ge-0/0/4.0 ge-1/0/1.0
lo0.0 lo0.1 lo0.2
Default Route Default Route Default Route
OSPF OSPF OSPF

Default Routing Instance
 Master routing instance includes inet.0 route table

•Might include other route tables, such as inet6.0
user@R1> show route instance

Instance Type
Primary RIB Active/holddown/hidden
master forwarding
inet.0 3/0/1
inet6.0 4/0/0
…
Participating route tables; the presence of
Routing instance name
inet6.0 table indicates IPv6 is in use

User-Defined Routing Instances
 You configure user-defined routing instances at the

[edit routing-instances] hierarchy level
•Typically used for filter-based forwarding, VPN services, and
system virtualization
•Routing instance types include:
[edit routing-instances instance-name]
user@R1# set instance-type ?
forwarding Forwarding instance
l2vpn Layer 2 VPN routing instance
no-forwarding Nonforwarding instance
virtual-router Virtual routing instance
vpls VPLS routing instance
vrf Virtual routing forwarding instance
Note: Actual routing instance types vary between platforms; check product documentation for
support information.
 Routing instance configuration example:

[edit routing-instances new-instance] Routing instance name is user-defined
user@R1# show
instance-type virtual-router; Routing instance type
interface ge-0/0/1.0; Define interfaces under the [edit
interface lo0.1; interfaces] hierarchy and reference them
routing-options { under their respective routing instance
static {
route 0.0.0.0/0 next-hop 172.26.25.1;
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lo0.1;
}
}
}

Working with Routing Instances
 When working with routing instances, always

reference the instance name
user@R1> show interfaces terse routing-instance new-instance
ge-0/0/0.0 up up inet 172.26.25.5/24
ge-0/0/1.0 up up inet 172.25.182.5/24
lo0.1 up up inet 192.168.100.52 --> 0/0
user@R1> ping 172.26.25.1 rapid count 25 routing-instance new-instance

PING 172.26.25.1 (172.26.25.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.26.25.1 ping statistics ---
Software automatically
user@R1> show route table new-instance.inet.0 creates IP unicast table
new-instance.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

0.0.0.0/0 *[Static/5] 02:06:18

> to 172.26.25.1 via ge-0/0/0.0

RIB Groups
 Use RIB groups to share routes between routing

tables
•Helpful in deployments such as:
• Virtual private networks
• Multicast networks
• Filter-based forwarding
Table1 Routes Table2

Defining and Applying RIB Groups
 Defined under the routing-options hierarchy

level
user@R1# show The export-rib indicates table from
rib-groups { where routes should be retrieved
<rib-group-name> {
export-rib <routing-table-name>;
The import-rib indicates tables in
import-rib <routing-table-names>;
which routes should be placed
import-policy <policy-name>;
}
}
The import-policy is used to control which
routes are installed in the routing table group
 Applied to routing protocols, interface routes, or both

user@R1# set rib-group ?
<rib-group> Routing table group for importing OSPF routes

Routing Between Instances
 You can use a logical tunnel interface or a physical

interface to route between instances
•Logical tunnels are not supported on all Junos devices;
might require a services interface card
Device Running the Junos OS
Routing Instance (master) Routing Instance (cust-A)
inet.0 cust-A.inet.0
inet6.0 cust-A.inet6.0
ge-0/0/0.0 Logical Connection ge-1/0/0.0
lt-0/0/0.0 lt-0/0/0.1
lo0.0 lo0.1
Default Route Default Route
OSPF OSPF
Physical Connection
Open Shortest Path First

An Overview of OSPF
 OSPF is a link-state IGP used within an AS

 OSPF floods link-state advertisements
•OSPF routers use the received LSAs to create a complete
database of the network
•OSPF uses the shortest-path-first algorithm to calculate the
best path to each destination network
OSPF ISP X
AS 64512
AS 64587

The Link-State Database
 All OSPF routers maintain a copy of the database

•Database contents consist of information learned through
LSAs and must match on all routers within an area
•SPF algorithm uses the contents of the link-state database
as input data to calculate network paths
R2
R1
OSPF
Area 0
R3
R4

OSPF Packet Types
 The five OSPF packet types include:
Type 1 Type 2 Type 3 Type 4 Type 5
Hello Database Link-State Link-State Link-State

Description Request Update Acknowledgment
Link-state advertisements are flooded

reliably using link-state requests, link-state
updates, and link-state acknowledgments.
R1 R2
Link-State Request
Link-State Update
Link-State Acknowledgment

Hello Packet

 Multicast hello packets are used to establish and

maintain OSPF neighbor relationships
•Sent to 224.0.0.5—all OSPF routers address
•Consist of the OSPF header plus the following fields:
Network mask* Hello interval* Dead interval* Options*
Router priority Designated router Backup designated router Neighbor
* Fields that must match to form an adjacency over a broadcast medium; a matching
network mask is not required for point-to-point links
Database Description Packet

 Database description packets are exchanged during

adjacency formation to determine which router is in
charge of the database exchange
•Describe the contents of the link-state database and consist
of the OSPF header, a sequence number, and LSA headers

Link-State Request Packet

 Link-state request packets are sent by an OSPF router

when that router detects its database is stale
•Used to request precise version of database and consist of
the OSPF header, link-state type, link-state ID, and
advertising router
R1 R2
Link-State Request
Link-State Update

Link-State Update Packet

 Link-state update packets are the basic information

block in OSPF and can carry multiple LSAs
•Transmitted using multicast to either the all OSPF routers
address (224.0.0.5) or the all DRs address (224.0.0.6), and
consist of the OSPF header, number of advertisements, and
LSAs R1 R2
Link-State Request
Link-State Update

Link-State Acknowledgment Packet

 Link-state acknowledgment packets are received in

response to link-state update packets
•A single acknowledgment packet can include responses to
multiple update packets and consist of the OSPF header and
the LSA header
R1 R2
Link-State Request
Link-State Update

Adjacency Formation
R1 R2
Down Hello (DR=0, Seen = 0)

Down
2Way Hello (DR=RT2, Seen = RT1) Init
Hello (DR=RT2, Seen = RT2) 2Way
ExStart DD (Seq=x, Master)
DD (Seq=y, Master) ExStart
Exchange DD (Seq=y, Slave)
DD (Seq=y+1, Master) Exchange
DD (Seq=y+1, Slave)
DD (Seq=y+n, Master)
Loading DD (Seq=y+n, Slave)
LS Request Full
LS Update
LS Request
LS Update
Full

Adjacency Optimization (1 of 2)
 By default, OSPF attempts to form adjacencies with

all neighbors discovered on all interfaces
•On a broadcast media like Ethernet, this approach is
suboptimal because it would require a full mesh of
adjacencies
Adjacencies

Adjacency Optimization (2 of 2)
 OSPF elects a DR to represent the segment

•Minimizes OSPF processes and reduces traffic on segment
•A BDR is also elected to recover if the DR fails
DR BDR
DR DR
OSPF adjacencies are only
formed with the DR and BDR.
DROther DROther DROther

Electing the Designated Router
 Every OSPF router has a DR election priority

•Priority range is 0–255 (default is 128)
•If two routers share the highest priority, the router with the
highest RID is elected
•The election of a DR is a nondeterministic event
• An existing DR will not be replaced
• The first router on the segment within 40 seconds wins
DR BDR
Priority: 255 Priority: 128

RID: 192.168.100.10 DR DR RID: 192.168.100.100

OSPF Neighbors Versus Adjacencies
R1 (RID: 1.1.1.1) R2 (RID: 1.1.1.2)
DR BDR
Adjacencies
DROther 2-way DROther
R3 (RID: 1.1.1.3) R4 (RID: 1.1.1.4)
user@R1> show ospf neighbor

Address Interface State ID Pri Dead
172.25.0.4 ge-0/0/1.0 Full 1.1.1.4 128 33
172.25.0.3 ge-0/0/1.0 Full 1.1.1.3 128 38
172.25.0.2 ge-0/0/1.0 Full 1.1.1.2 254 38

172.25.0.1 ge-0/0/1.0 Full 1.1.1.1 255 37
172.25.0.2 ge-0/0/1.0 Full 1.1.1.2 254 35
172.25.0.3 ge-0/0/1.0 2Way 1.1.1.3 128 34

Scaling an OSPF Network
 Problem: As OSPF networks grow, so does the size of

the link-state database, which can overload resources
Area 0
Area 0
 Solution: Implement OSPF areas to shrink the size of

the link-state database
Area 1 Area 0 Area 2
Area 1 Area 0 Area 2

OSPF Areas
Area 0.0.0.0 serves as backbone area and distributes
routing information between attached areas.
AS 65415
Area 0.0.0.1 Area 0.0.0.0 Area 0.0.0.2
 Areas
•An AS can be divided into smaller groups called areas
•LSA flooding can be constrained to an area, which
effectively reduces the size of the link-state database
•All routers maintain an identical copy of the link-state
database on a per-area basis
OSPF Routers
Area border routers (ABRs) belong to Backbone routers have at least

Area 0.0.0.0 and an attached area. one link in OSPF Area 0.0.0.0
AS 65415
Area 0.0.0.1 Area 0.0.0.0 Area 0.0.0.2
ASBRs inject routing information Internal routers have all OSPF

from outside the OSPF domain. links in the same area.

OSPF Area Types
Intra-Area Routes
Stub Area Does not carry external routes
Special stub area that allows external and cannot contain ASBRs
routes to be advertised from the area
but not received from another area
Stub area that receives only a

default route from the backbone
Interarea Routes
(Summary Routes)
Totally Stubby Area
Not-So-Stubby Area
Backbone
(0.0.0.0)
RIP
Default Route
External Routes BGP

Overview of the LSA Packet Types
Router Links Network Links

Type 1 Type 2
Originated for multi-access segments with

more than one attached router. Describe all
Describe the state and cost of the router’s routers attached to the specific segment.
links (interfaces) to the area (Intra-area). Originated by a designated router (DR).
Summary Links External Links NSSA External Links

Type 3 and Type 4 Type 5 Type 7
NSSA
ABR ASBR ASBR

Originated by ABRs. Describe networks in
the AS but outside of area (Inter-area). Originated by an ASBR. Describe external Used by not-so-stubby areas to import
Also describe the location of the ASBR. destination prefixes or a default route. external routes into a stub area.

Test Your Knowledge
 Which of the recently discussed LSAs would you

expect to find in each of the listed areas?
Stub Area
Not-So-Stubby Totally Stubby

Area Area
Backbone
(0.0.0.0)
RIP
BGP

Junos OS OSPF Support
 The Junos OS supports OSPF version 2 and version 3,

as well as a number of supporting features, such as:
•Stub, not-so-stubby, and totally stubby areas
•Authentication
•Summarization
•External prefix limits
•Graceful restart
•Bidirectional Forwarding Detection

Configuring OSPF
[edit protocols]
user@R1# show
ospf { Used for IPv4 routing environments
area <area-id> {
<area options>;
interface <interface-name> {
<interface options>;
}
}
}
ospf3 { Used for IPv4 or IPv6 routing environments
area <area-id> {
<area options>;
interface <interface-name> {
<interface options>;
}
}
}

The Router ID
 OSPF uses the RID to identify the router from which a

packet originated
•You can manually define the RID under the [edit
routing-options] hierarchy
user@R1# show The RID is a 32-bit number
in dotted quad notation.
router-id 192.168.100.1;
•If you do not configure a RID, a non-127/8 IP address of the

first interface to come online is used (typically lo0)
•If lo0 does not have a suitable address, the IP address
associated with first hardware interface is used
Note: We strongly recommend that you configure a RID to avoid unpredictable behavior
if the interface addresses are changed.

Case Study: Topology and Objectives
 Use the following topology as a guide to implement

OSPF
•On R1, redistribute the 172.18.1.0/24 network and ensure
that it is installed as an external OSPF route
•Use metrics to ensure that the path using the ge-0/0/1
interfaces within the backbone area is preferred
Area 0.0.0.0
Area 0.0.0.1 Area 0.0.0.2
172.26.2.0/30
ge-1/0/0 ge-0/0/3 ge-0/0/1 ge-0/0/1 ge-0/0/3 ge-1/0/1
ge-0/0/1
172.18.1.0/24 172.26.1.0/30 ge-0/0/2 ge-0/0/2 172.26.4.0/30

172.26.3.0/30
R1 - lo0/RID: R2 - lo0/RID: R3 - lo0/RID: R4 - lo0/RID:

192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.4

Case Study: Configuring OSPF
[edit protocols] [edit protocols]

user@R1# show ASBR (Policy is defined and user@R4# show
ospf { applied on the next slide.) ospf {
area 0.0.0.1 { area 0.0.0.2 {
interface ge-1/0/0.0; interface ge-1/0/1.0;
interface lo0.0; interface lo0.0;
} }
} }

user@R2# show ABRs user@R3# show
ospf { ospf {
area 0.0.0.0 { area 0.0.0.0 {
interface ge-0/0/2.0 { interface ge-0/0/2.0 {
metric 100; Increased metric metric 100;
for secondary path }
}
interface lo0.0; interface lo0.0;
} }
area 0.0.0.1 { area 0.0.0.2 {
} }
} }

Case Study: Redistributing the Route
user@R1# show
policy-statement 2ospf { Redistribution policy is defined under
term match-direct-route { [edit policy-options] hierarchy.
from {
protocol direct;
}
then accept;
}
}
[edit protocols]
user@R1# show
ospf {
export 2ospf; Redistribution policy is applied under
area 0.0.0.1 { [edit protocols ospf] hierarchy.
interface lo0.0;
}
}

Test Your Knowledge
 What configuration option allows R1 to inject the

172.18.1.0/24 prefix into OSPF as an internal OSPF
route while prohibiting adjacency formation?
Include the passive
option for the interface
[edit protocols]
user@R1# set ospf area 1 interface ge-0/0/1.0 passive
Area 0.0.0.0
Area 0.0.0.1 Area 0.0.0.2
172.26.2.0/30
ge-1/0/0 ge-0/0/3 ge-0/0/1 ge-0/0/1 ge-0/0/3 ge-1/0/1
ge-0/0/1
172.18.1.0/24 172.26.1.0/30 ge-0/0/2 ge-0/0/2 172.26.4.0/30

172.26.3.0/30

192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.4

Case Study: Monitoring OSPF (1 of 2)
 Use the show ospf neighbor command to

display OSPF adjacency information
172.26.2.2 ge-0/0/1.0 Full 192.168.1.3 128 39
172.26.3.2 ge-0/0/2.0 Full 192.168.1.3 128 36
172.26.1.1 ge-0/0/3.0 Full 192.168.1.1 128 34
Area 0.0.0.0
Area 0.0.0.1 Area 0.0.0.2
172.26.2.0/30
ge-1/0/0 ge-0/0/3 ge-0/0/1 ge-0/0/1 ge-0/0/3 ge-1/0/1
ge-0/0/1
172.18.1.0/24 172.26.1.0/30 ge-0/0/2 ge-0/0/2 172.26.4.0/30

172.26.3.0/30

192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.4

Case Study: Monitoring OSPF (2 of 2)
 Use show route commands to verify route entries

and their selected paths
user@R2> show route 172.18.1.0/24 External prefix injected by R1

172.18.1.0/24 *[OSPF/150] 02:37:46, metric 0, tag 0

> to 172.26.1.1 via ge-0/0/3.0
Remote subnet connecting R3 and R4
user@R2> show route 172.26.4.0/30 is reachable through desired path.
172.26.4.0/30 *[OSPF/10] 02:24:29, metric 2

> to 172.26.2.2 via ge-0/0/1.0

Other Key Monitoring Commands
 Additional show commands exist to provide detailed

information on the operation of OSPF:
• show ospf interface
• show ospf route
• show ospf database
• show ospf statistics
• show ospf log

Displaying OSPF Interface Parameters
 Use the show ospf interface command to

display OSPF interface parameters
user@R2> show ospf interface
Interface State Area DR ID BDR ID Nbrs
ge-0/0/1.0 BDR 0.0.0.0 192.168.1.3 192.168.1.2 1
ge-0/0/2.0 DR 0.0.0.0 192.168.1.2 192.168.1.3 1
lo0.0 DR 0.0.0.0 192.168.1.2 0.0.0.0 0
ge-0/0/3.0 DR 0.0.0.1 192.168.1.2 192.168.1.1 1
Area 0.0.0.0
Area 0.0.0.1
172.26.2.0/30
ge-1/0/0 ge-0/0/3 ge-0/0/1 ge-0/0/1
ge-0/0/1
172.18.1.0/24 172.26.1.0/30 ge-0/0/2 ge-0/0/2

172.26.3.0/30
R1 - lo0/RID: R2 - lo0/RID: R3 - lo0/RID:

192.168.1.1 192.168.1.2 192.168.1.3

Displaying OSPF Route Information
 Use the show ospf route command to display

routes learned from, and advertised to, OSPF
user@R2> show ospf route
Topology default Route Table:
Prefix Path Route NH Metric NextHop Nexthop

Type Type Type Interface addr/label
192.168.1.1 Intra AS BR IP 1 ge-0/0/3.0 172.26.1.1
192.168.1.3 Intra Area BR IP 1 ge-0/0/1.0 172.26.2.2
172.18.1.0/24 Ext2 Network IP 0 ge-0/0/3.0 172.26.1.1
172.26.1.0/30 Intra Network IP 1 ge-0/0/3.0
172.26.4.0/30 Inter Network IP 2 ge-0/0/1.0 172.26.2.2
192.168.1.1/32 Intra Network IP 1 ge-0/0/3.0 172.26.1.1
192.168.1.2/32 Intra Network IP 0 lo0.0
192.168.1.3/32 Intra Network IP 1 ge-0/0/1.0 172.26.2.2
192.168.1.4/32 Inter Network IP 2 ge-0/0/1.0 172.26.2.2
External prefix injected by R1 Metric for ge-0/0/2.0 interface was

modified in earlier configuration example.

Displaying the OSPF Link-State Database
 Use the show ospf database commands to view

the OSPF link-state database
user@R2> show ospf database ABRs maintain a separate database for
each OSPF area to which they are attached.
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *192.168.1.2 192.168.1.2 0x8000000c 1387 0x22 0x84ae 60
Router 192.168.1.3 192.168.1.3 0x80000023 1249 0x22 0x545e 60
Network 172.26.2.2 192.168.1.3 0x80000005 2049 0x22 0x43e3 32
Network 172.26.3.2 192.168.1.3 0x80000005 2449 0x22 0x38ed 32
Summary *172.26.1.0 192.168.1.2 0x80000007 2541 0x22 0x4db7 28
Summary 172.26.4.0 192.168.1.3 0x80000025 2249 0x22 0xe9f8 28
Summary *192.168.1.1 192.168.1.2 0x80000006 1618 0x22 0xa3bb 28
Summary 192.168.1.4 192.168.1.3 0x8000001a 1649 0x22 0x57ef 28
ASBRSum *192.168.1.1 192.168.1.2 0x80000007 2310 0x22 0x93c9 28

Router 192.168.1.1 192.168.1.1 0x80000007 56 0x22 0x82c3 48
…
OSPF AS SCOPE link state database
Extern 172.18.1.0
192.168.1.1 0x80000005 96 0x22 0x374c 36
www.juniper.net | 33
Displaying OSPF SPF-Related Information
 Use the show ospf log command to display OSPF

SPF-related information
user@R2> show ospf log
Last instance of each event type
When Type Elapsed
04:28:24 SPF 0.000074
04:28:24 Stub 0.000030
04:28:24 Interarea 0.000042
04:28:24 External 0.000016
04:28:24 NSSA 0.000003
04:28:24 Cleanup 0.000049
Maximum length of each event type

When Type Elapsed
20:09:11 SPF 0.000110
…
Last 100 events

When Type Elapsed
16:38:21 NSSA 0.000003
…

Displaying OSPF Statistics
 Use the show ospf statistics command to

view OSPF statistics
user@R2> show ospf statistics
Packet type Total Last 5 seconds

Sent Received Sent Received
Hello 52 17 0 0
DbD 9 7 0 0
LSReq 2 2 0 0
LSUpdate 46 45 0 0
LSAck 37 33 0 0
DBDs retransmitted : 0, last 5 seconds : 0

LSAs flooded : 40, last 5 seconds : 0
LSAs flooded high-prio : 10, last 5 seconds : 0
LSAs retransmitted : 0, last 5 seconds : 0
LSAs transmitted to nbr: 8, last 5 seconds : 0
LSAs requested : 2, last 5 seconds : 0
LSAs acknowledged : 39, last 5 seconds : 0
…

OSPF Troubleshooting Tool Kit
 Primary troubleshooting tools for OSPF include

traceoptions and CLI show commands
Protocol traceoptions CLI show commands

Common Adjacency Problems
 Adjacency problems and checklist items include:
Problem Checklist
No neighbor detected  Check physical and data link layer connectivity
 Check for mismatched IP subnet/mask, area
number, area type, authentication, hello/dead
interval, or network type
Stuck in ExStart state  Check MTU settings to ensure that they match
Stuck in 2-way state  Normal for DR-Other neighbor

Using Traceoptions
 Use traceoptions to identify adjacency formation

issues; a sample configuration is shown:
[edit protocols]
user@R1# show
ospf {
traceoptions { User-defined file-name and flag options.
file trace-ospf; Include the detail option to generate
flag error detail; additional details in the associated log file.
flag event detail;
}
area 0.0.0.0 {
interface lo0.0;
}
} Area 0.0.0.0
ge-1/0/0 ge-0/0/3
R1 - lo0: 192.168.1.1 R2 - lo0: 192.168.1.2
.1 172.26.1.0/30 .2

Displaying the Log File Contents
 Use the show log file-name command to

display the contents of the traceoptions log file
user@R1> show log trace-ospf
Oct 13 09:05:51.748087 OSPF packet ignored: area mismatch (0.0.0.1) from
172.26.1.2 on intf ge-1/0/0.0 area 0.0.0.0
Oct 13 09:05:51.748208 OSPF rcvd Hello 172.26.1.2 -> 224.0.0.5 (ge-1/0/0.0
IFL 73 area 0.0.0.0)
Oct 13 09:05:51.748237 Version 2, length 44, ID 192.168.1.1, area 0.0.0.1
Oct 13 09:05:51.748250 checksum 0x8c5c, authtype 0
Oct 13 09:05:51.748264 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio
128
Oct 13 09:05:51.748281 dead_ivl 40, DR 172.26.1.2, BDR 0.0.0.0
According to the log file, R2 has

Area 0.0.0.0 the wrong OSPF area configured.
ge-1/0/0 ge-0/0/3
R1 - lo0: 192.168.1.1 R2 - lo0: 192.168.1.2
.1 172.26.1.0/30 .2

Viewing OSPF Error Counters
 Use the show ospf statistics command to

view OSPF errors
user@R1> show ospf statistics
Receive errors:
410 area mismatches
17 mtu mismatches
81 Hellos received with our router ID
•Use clear ospf statistics to refresh counters

user@R1> clear ospf statistics

Label Distribution
Protocol
4-1
Copyright © 2005 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net

Purpose of LDP
 Creates forwarding equivalence class (FEC)
•A group of IP packets that are forwarded in the same
manner (RFC 3031)
 Manages LSP to egress router
•LDP associates the FEC with each LSP it creates
•Enables VPNs
© 2008 Juniper Networks, Inc. All rights reserved. 2

LDP Operation
 LDP creates an LSP tree for each FEC from every

possible ingress router to egress router
LDP LSPs
Egress
RSVP LSPs
B
G
I
A E Only one LDP LSP

while n RSVP LSPs are
needed
D
H
C
F

The RFC 4364 (aka 2547 bis) Model
VPN A VPN B
VPN A
Site2 Site2
Site 1
CE – A2
CE1 – A2
CE – A1 P P
PE 2 CE – B2
VPN B PE 1
Site 1 VPN A
Site 3
P PE 3
CE – B1
CE – A3
 Route distribution takes place between the

following routers:
•CE to PE, PE to PE, PE to CE
 To isolate traffic, each PE router keeps a VPN
routing and forwarding table (VRF) for each VPN that
is attached to it
LDP Signaling Overview
Upstream Downstream
LDP peer LDP peer
Hello messages
Discovery
TCP Session Establishment
Session
Initialization Messages
Label Request Messages

Advertisement
Label Mapping Messages
 LDP messages types

•Discovery: Locate potential LDP peers
•Session: Manage peer-to-peer TCP sessions
•Advertisement: Create, change, or delete label mappings
•Notification: Provide advisory information

Label Assignment
FEC: 10.0.0.1/32 FEC: 10.0.0.1/32
Upstream Label: 17 Downstream FEC: 10.0.0.1/32
LSR Label: 52 LDP Peer
LDP Peer Label: 29
fe-0/0/2 so-0/0/1 so-0/0/1 so-0/0/3 so-0/0/3 at-0/2/0
Advertise Receive
Incoming Outgoing
MPLS Table Label MPLS Table Label MPLS Table
In Out In Out In Out
(fe-0/0/2, 35) (so-0/0/1, 17) (so-0/0/1, 17) (so-0/0/3, 52) (so-0/0/3, 52) (at-0/2/0, 29)
 LDP label mapping:

• Downstream peer assigns labels
• Benefits:
• Traffic engineering information is not piggybacked on routing
protocols
• Limitations:
• LSPs follow the conventional IGP path
• Does not support explicit routing

Hello-Based Neighbor Discovery
Basic Discovery
Router A Router B
224.0.0.2, UDP port 646
Extended Discovery
Specific Address, UDP port 646
 Neighbor discovery is asymmetric process

•Respond only if LDP session is desired
 Active node has the higher IP address
•Transport address takes precedence over source address

LDP Session Establishment
Router A Router B
TCP 3-way Handshake
(Passive) (Active)
10.0.1.1 10.0.1.2
Session Initialization
(Version, Label modes, Timer Values)
Session Initialization
(Version, Label modes, Timer Values)
Keepalives
 Active Node initiates TCP session

•LDP Session initiated after TCP session established

LDP Session Maintenance
 LDP session requires at least 1 hello adjacency
 Hello interval: 5-second default
 Hold timer: 15-second default
•If hold timer expires, LSR deletes hello adjacency
•Can be asymmetric
 Transport address selection:
•Interface address
•Router ID

LDP in JUNOS Software
 Support for LDP version 1
•Downstream unsolicited label allocation, liberal retention,
with an ordered control mode
•Support for LDP graceful restart
•Basic and extended neighbor discovery

Sample LDP Topology
 This topology is used to drive the configuration
examples and to provide sample operational status
r6
.5
r5 Loopbacks
10.0.8.4/30
.6 r5 = 10.0.3.5
r6 = 10.0.9.6
fe-0/0/1
r7 = 10.0.9.7
.9
10.0.8.8/30
.10
fe-0/3/1
r7

A Minimal LDP Configuration
 A functional LDP configuration involves:
•Enabling LDP on desired interfaces
•Adding the mpls family to desired interfaces
• Not needed for lo0
•Linking interfaces with the router’s MPLS process
[edit]
lab@r5# show protocols ldp [edit]
interface all; lab@r5# show interfaces fe-0/0/0
interface fxp0.0 { unit 0 {
disable; family inet {
} address 10.0.8.6/30;
}
[edit] family iso;
lab@r5# show protocols mpls family mpls;
interface all; }

Verify LDP Neighbors
 Confirming LDP interfaces is a good place to begin
lab@r5> run show ldp interface
Interface Label space ID Nbr count Next hello
lo0.0 10.0.3.5:0 0 0
fe-0/0/0.0 10.0.3.5:0 1 1
fe-0/0/1.0 10.0.3.5:0 1 2
 Neighbor status for LDP interfaces is confirmed next
lab@r5> run show ldp neighbor

Address Interface Label space ID Hold time
10.0.8.5 fe-0/0/0.0 10.0.9.6:0 11
10.0.8.10 fe-0/0/1.0 10.0.9.7:0 11

Verify LDP-Signaled LSPs
 LDP-signaled LSPs are placed into the inet.3 routing
table
[edit]
lab@r7# run show route table inet.3

Restart Complete
10.0.3.5/32 *[LDP/9] 00:12:04, metric 1

> to 10.0.8.9 via fe-0/0/1.0
10.0.9.6/32 *[LDP/9] 00:10:56, metric 1
> to 10.0.8.9 via fe-0/0/1.0, Push 100003

Confirm Forwarding with MPLS Ping
 Feature allows ping testing of RSVP-signaled and
LDP-signaled LSPs
•Does not rely on BGP routes or modification of default
routing table integration rules
•Must assign a 127.0.0.1 address to egress node’s lo0
interface!
RSVP/LDP LSP
r3 r5 r4 127.0.0.1 assigned to lo0

on egress router!
lab@r3> run ping mpls ldp 10.0.3.4

!!!!!
--- lsping statistics ---

The LDP Label Database
lab@r7> run show ldp database
Input label database, 10.0.9.7:0--10.0.3.5:0
Label Prefix
3 10.0.3.5/32
100003 10.0.9.6/32
100000 10.0.9.7/32
Output label database, 10.0.9.7:0--10.0.3.5:0

Label Prefix
100000 10.0.3.5/32
100001 10.0.9.6/32
3 10.0.9.7/32

LDP Tunneling Through RSVP-TE LSP
Router A Router B
LDP LDP
R7 RSVP R8
[edit]
lab@r7# show protocols mpls
label-switched-path test {
to 10.0.6.1;
ldp-tunneling;
no-cspf;
}
interface all;

LDP Tunneling Through RSVP-TE LSP
LDP (Logical LDP Link) LDP
LDP over RSVP Tunnel

Import Filtering Example
 Use import policy to control the FECs that LDP will
accept
•Goal is to accept only /32 FECs in this example
[edit]
lab@r7# show protocols ldp
import only-32;
interface all;
[edit]
lab@r7# show policy-options policy-statement only-32
term first {
from {
route-filter 0.0.0.0/0 upto /31;
}
then reject;
}
then accept;

Export Filtering
 Use export policy to control what FECs LDP advertises
•Goal is to block the advertisement of the 10.10.255.6 FEC to
all LDP neighbors while still advertising local router’s loopback
address
[edit]
export block-one;
interface all;
[edit]
lab@r7# show policy-options policy-statement block-one
term first {
from {
}
then reject;
} This term prevents the negation of
term last { default LDP export policy!
then accept;
}

Export Filtering
 Use export policy to control what FECs LDP advertises
•Goal is to block the advertisement of the 10.10.255.6 FEC to
all LDP neighbors while still advertising local router’s loopback
address
[edit]
export block-one;
interface all;
[edit]
lab@r7# show policy-options policy-statement block-one
term first {
from {
}
then reject; This term prevents the negation of default LDP
} export policy!
term last {
then accept;
}

Egress Policy
 Use egress policy to control the FECs that egress at
the local router
•Goal is to advertise all directly connected routes with the
local router as egress
[edit]
export block-one;
egress-policy connected-only;
interface all;
[edit]
lab@r7# show policy-options policy-statement connected-only
from protocol direct;
then accept;

LDP FEC Deaggregation
 Deaggregation breaks a single FEC into multiple FECs,
each associated with a separate LSP
r5
r6
FEC “A” Label 100000, 10.0.9.6/32

FEC “B” Label 100001, 200.0.0/24 FEC “A” Label 100000, 10.0.9.6/32, 200.0.0/24
[edit]
export block-one;
egress-policy connected-only;
deaggregate;
interface all;

LDP Session Authentication
 MD5-based authentication for TCP transport
•Configured at the LDP session level
• Note that sessions form between lo0 addresses by default!
•Applies to LDP session, not neighbor discovery
[edit protocols ldp]
lab@r5# set session 10.0.9.6 authentication-key jni

lab@r5# show
interface all;
session 10.0.9.6 {
authentication-key "$9$87Wx-wHkP5Qn"; # SECRET-DATA
}

LDP Graceful Restart
 Graceful restart maintains forwarding state during a
router restart or reboot
•Signaled with Fault Tolerant (FT) TLV in initialization
messages
•Requires helper mode in adjacent nodes
•Enabled with graceful-restart statement in main
routing instance
[edit]
lab@r3# set routing-options graceful-restart
 Can disable graceful restart, helper mode, or both for
LDP
lab@r3# set graceful-restart disable

Verify LDP Graceful Restart
 Use the show ldp session detail command
lab@r5> run show ldp session detail 10.0.9.6
Address: 10.0.9.6, State: Operational, Connection: Open, Hold time: 25
Session ID: 10.0.3.5:0--10.0.9.6:0
Next keepalive in 6 seconds
Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
Keepalive interval: 10, Connect retry interval: 1
Local address: 10.0.3.5, Remote address: 10.0.9.6
Up for 00:24:56
Authentication type: MD5
Local - Restart: enabled, Helper mode: enabled, Reconnect time: 60000
Remote - Restart: enabled, Helper mode: enabled, Reconnect time: 60000
Local maximum recovery time: 120000 msec
Next-hop addresses received:
10.0.8.2
10.0.8.5
10.0.1.6
10.0.9.6
172.16.0.9

LDP-IGP Synchronization (1 of 3)
 The problem—LDP is down along the IGP best path
•Ordered control mode (JUNOS software default)
• LSP goes down; FEC withdrawn
• IGP path still followed for normal traffic
• Traffic dropped in an Layer 3 VPN environment
•Independent control mode
• LSP stays up; no forwarding state in the middle of the network
• All traffic to FEC dropped
IGP adjacency up,

No LSP to 192.168.32.1/32 (ordered) but LDP session down
Hong Kong Amsterdam

lo0: 192.168.16.1 lo0: 192.168.32.1
San Jose Montreal

lo0: 192.168.20.1 lo0: 192.168.40.1
10.222.32.0/24
injected into BGP
Blackhole traffic using 192.168.32.1/32
as next hop (independent) Denver
© 2008 Juniper Networks, Inc. All rights reserved. lo0: 192.168.56.1 27
 The solution
•Until LDP is operational, advertise the link into the IGP with
maximum cost
•Once LDP is operational, advertise the link with normal cost
Until LDP is up, traffic to 10.222.32.1

follows LDP LSP via HongKong, SanJose, IGP adjacency up,
Denver, Montreal, Amsterdam but LDP session down
Hong Kong Amsterdam

lo0: 192.168.16.1 lo0: 192.168.32.1
San Jose Montreal

lo0: 192.168.20.1 lo0: 192.168.40.1
10.222.32.0/24
injected into BGP
Maximum cost advertised to reach
Montreal Denver
lo0: 192.168.56.1

 Configuration:
•Configure ldp-synchronization on an interface
• For OSPF, applied at the [edit protocols ospf area
area-id interface interface-name] hierarchy
• For IS-IS, applied at the [edit protocols isis interface
interface-name] hierarchy
 Operation:
• show ospf interface extensive
• show isis interface extensive
Hong Kong Amsterdam

lo0: 192.168.16.1 lo0: 192.168.32.1
San Jose Montreal

lo0: 192.168.20.1 lo0: 192.168.40.1
Denver
lo0: 192.168.56.1

Constrained
Shortest Path First
4-1

Constraint-Based Routing Overview
 Modified shortest-path-first algorithm
 Integrates TED data
•IGP topology information, available bandwidth, and link color
•Determines optimal path and setup order according to
user-provided constraints
• Maximum hop count (for fast reroute detours)
• Bandwidth
• Strict or loose routing (EROs)
• Administrative groups
• Priority
 Prunes nonqualifying paths and performs SPF on
remaining routes
•The result is either an explicit route that is handed to RSVP
for signaling, or a no route to host error message

Ingress LSR Operations
Extended IGP
Link-State Traffic Engineering Constrained User

Database Database (TED) Shortest Path First Constraints
1) Store information from IGP flooding

Explicit Route
2) Store traffic engineering information
3) Examine user-defined constraints
4) Calculate the physical path for the LSP
RSVP Signaling
5) Represent path as an explicit route
6) Pass ERO to RSVP for signaling

Topology Information Distribution
 IGP extensions propagate additional information
•IS-IS uses TLV tuples
•OSPF uses opaque LSA Type 10
•Information propagated within area or level only
 Information propagated:
•Bandwidth available
•Link affinity (link colors)
•Router ID

IGP Extension Example: IS-IS
Nov 20 14:35:05 Received L2 LSP Denver.00-00, interface fe-0/0/1.0
Nov 20 14:35:05 from Denver
Nov 20 14:35:05 sequence 0x18e, checksum 0xa30e, lifetime 1198
Nov 20 14:35:05 max area 0, length 318
Nov 20 14:35:05 no partition repair, no database overload
Nov 20 14:35:05 IS type 3, metric type 0
Nov 20 14:35:05 area address 49.0001 (3)
Nov 20 14:35:05 speaks IP
Nov 20 14:35:05 IP router id: 192.168.0.1
Nov 20 14:35:05 IP address 192.168.0.1
Nov 20 14:35:05 dyn hostname Denver
Nov 20 14:35:05 IS neighbors:
Nov 20 14:35:05 IS neighbor Washington-DC.00
Nov 20 14:35:05 internal, metrics: default 10
Nov 20 14:35:05 IS neighbor Atlanta.00
Nov 20 14:35:05 internal, metrics: default 10
Nov 20 14:35:05 IS neighbor Washington-DC.00, metric: 10
Nov 20 14:35:05 IP address: 10.0.1.2
Nov 20 14:35:05 Neighbor's IP address: 10.0.1.1
Nov 20 14:35:05 Current reservable bandwidth:
Nov 20 14:35:05 Priority 0: 77.5Mbps
Nov 20 14:35:05 Maximum reserveable bandwidth: 77.5Mbps
Nov 20 14:35:05 Maximum bandwidth: 155Mbps
Nov 20 14:35:05 Administrative groups: 0xc

Controlling IGP Updates
 RSVP interface bandwidth refresh
•Tune the IGP update threshold for RSVP interface bandwidth
•Use the update threshold threshold %(1...20)
command under RSVP interface
•Default update threshold set to 10%

Traffic Engineering Database
 Used exclusively for calculating explicit LSP paths
across the physical topology
•Maintains traffic engineering information learned from IGP
extensions
 Contains:
•Up-to-date network topology information
•Current reservable bandwidth of links
•Link administrative groups (colors)
•Link priority information

TED Analysis
lab@NewYork> show ted database extensive
TED database: 21 ISIS nodes 9 INET nodes

NodeID: SanJose.00(192.168.1.1)
Type: Rtr, Age: 522 secs, LinkIn: 2, LinkOut: 2
Protocol: IS-IS(2)
To: SanFrancisco.02, Local: 10.0.3.1, Remote: 0.0.0.0
Color: 0x2 gold
Metric: 10
Static BW: 100Mbps
Reservable BW: 100Mbps
Available BW [priority] bps:
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps
To: Toronto.03, Local: 10.0.1.1, Remote: 0.0.0.0
Color: 0x2 gold
Metric: 10
Static BW: 100Mbps
Reservable BW: 100Mbps
Available BW [priority] bps:

User-Provided Constraints
Extended IGP
Link-State Traffic Engineering Constrained Shortest User

Database Database (TED) Path First (CSPF) Constraints
 User-defined constraints
influence path selection Explicit Route
•Bandwidth requirements*
•Hop count limitations (for fast
reroute)
RSVP Signaling
•Administrative groups (colors)
•Priority (setup and hold)*
•Explicit route (strict or loose)* * Can also be specified for non-CSPF-signaled LSPs

The CSPF Algorithm
 FOR LSP = (highest priority) to (lowest priority):
1. Prune links with insufficient bandwidth
2. Prune links that do not contain an included color
3. Prune links that contain an excluded color
4. Calculate shortest path from ingress to egress consistent
with ERO
5. If equal-cost paths exist, choose the path whose last hop
address equals the LSP's destination
6. Select among equal-cost paths (least hop, then fill related
criteria)
7. Pass explicit route to RSVP

Avoiding Recent Outages
 Negative feedback: PathErr message handling
•Maintains knowledge of PathErr message for TED
calculations
•Default PathErr retention for TED = 20 seconds
•Can be modified with the rsvp-error-hold-time
hold-time (0...240 sec) statement

CSPF Tie-Breaking Terms
 The following terms and formulas are used in breaking
CSPF ties:
•Reservable bandwidth
• Link bandwidth x link subscription factor
•Available bandwidth
• Reservable bandwidth—sum of the LSP bandwidths traversing the
link
•Available bandwidth ratio
• Available bandwidth/reservable bandwidth
•Minimum available bandwidth ratio (for a path)
• Smallest available bandwidth ratio of the links that comprise a path

CSPF Tie-Breaking Options
 Random:
•Default behavior; chooses a path at random from set of
equal-cost alternatives
•Tends to balance total number of LSPs over all available
paths
 Least fill:
•Finds the path with the largest minimum available
bandwidth ratio
 Most fill:
•Prefers the path with the smallest minimum available
bandwidth ratio
 Configured at the [edit protocols mpls
label-switched-path path-name] hierarchy

Test Understanding: Least Fill
All links Fast Ethernet Available bandwidth ratio
IGP = IS-IS
All IGP path metrics equal
65
85
60
60 60
43 40
43
15
15
 Which path
will a new LSP
with a 12-Mbps
bandwidth request take?
Test Understanding: Most Fill
All links Fast Ethernet Available bandwidth ratio
IGP = IS-IS
All IGP path metrics equal
65
85
60
60 60
43 40
43
15
15
 Which path
will a new LSP
with a 12-Mbps
bandwidth request take?
An Interesting Question
All links 100% subscription factor
Each link shows reserved
bandwidth 500M 500M
IS-IS IGP; all paths equal metrics
Top and bottom links are
GE, middle links 5M
are FE
5M 5M
15M 15M 15M

 Using
least-fill load
balancing, which 430M 430M
path will a new LSP

with a 12-Mbps bandwidth
request take? •Do you find this odd?
Another Interesting Question
All links 100% subscription factor
Each link shows reserved
bandwidth 5M
5M
IS-IS IGP; all paths equal metrics
Top links are FE
Bottom links are GE 10M
10M
10M
10M 10M
10M
 Using
least-fill load 200M
200M
balancing, which
path will a new LSP
with a 4-Mbps bandwidth
request take? •Do you find this odd?
Overview of Administrative Groups
 Thirty-two named groups, 0 through 31—carried as
32-bit value in IGP updates
•Groups assigned to interfaces
Silver
San Gold
Francisco
Bronze

Administrative Groups
1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0
 Colors advertised on a per-link basis via IGP

• Using hexadecimal—for example, 0xC000000E
 Colors assigned on router:
•Internal management—for example, bronze, silver, gold, etc.

Administrative Groups: Configuration
[edit protocols]
mpls {
admin-groups {
Colors defined
good 1;
silver 2;
bronze 3;
management 30;
internal 31;
}
interface so-0/0/0 {
admin-group [ good management ]
}
admin-group silver;
}
admin-group good; Colors assigned
}
admin-group good;
}
}

Using Administrative Groups
 CSPF can factor include-any, include-all, and
exclude constraints into the path calculation
mpls {
label-switched-path to-miami { Logical OR
to 1.1.1.1;
primary use-fargo {
admin-group {
include-any [ gold silver ];
Logical AND include-all [ premium customer ];
exclude [ bronze iron ];
}
} Logical AND
}
path use-fargo {
10.0.1.2 loose; Logical OR
}
}

Displaying Administrative Groups
lab@HongKong> show mpls interface

Interface State Administrative groups
so-0/3/0.0 Up red orange yellow green blue violet
fe-0/2/1.0 Up red orange yellow green blue violet
ge-0/0/0.0 Up crimson rust maize forest navy purple

Administrative Groups I
 Choose the IGP’s best path from A to I
IGP Metrics
B 5
G 1
1 3 I
2
5
A E 6
2 1 3
2
3 6 D
H
C
F 3
4

Administrative Groups I: Solution
 Path A-D-E-G-I has the lowest IGP metric (6)
B 5
G 1
1 3 I
2
5
A E 6
2 1 3
D
2
3
H
C
F 3
6 4

Administrative Groups II
 Choose the path from A to I according to:
[edit protocols mpls]
lab@A# show
label-switched-path to-I {
to 1.1.1.1;
primary primary-path {
admin-group include-any [ gold silver ];
}
} B 5
G 1
1 3 I 1.1.1.1
2
5
A E 6 3
2 1
D 2
3 H
C 6
F 3
4

Administrative Groups II: Solution
 Path A-C-F-G-I uses only gold or silver links
B 5
G 1
1 3 I
2
5
A E 6 3
2 1
D 2
3 H
C 6
F 3
4

Administrative Groups III
 Choose the path from A to I according to:
lab@A# show
to 1.1.1.1;
admin-group {
include-any [ copper bronze ];
exclude admin;
} B 5
} G 1
} 1 3 2 I 1.1.1.1
5
A E 6 3
2 1
D 2
3 H
C 6
F 3
4
Administrative Groups III: Solution
 Path A-D-E-G-H-I is the shortest path excluding the
admin class and including copper or bronze
B 5
G 1
1 3 2 I
5
A E 6 3
2 1
D 2
3 H
C 6
F 3
4

Administrative Groups IV
 Choose the path from A to H using:
lab@A# show
label-switched-path to-H {
to 2.2.2.2;
admin-group {
include-any [ copper bronze
];
exclude admin;
} B 5
} G 1
} 1 3 2 I
3
A E 6 1
2 1
D 2
3 H
C 6 2.2.2.2
F 3
4
Administrative Groups IV: Solution
 Path A-D-E-G-I-H is the shortest path excluding the
admin class and including copper or bronze
B 5
G 1
1 3 I
2
3
A E 6 1
2 1
D 2
3 H
C 6
F 3
4

Administrative Groups V
 Choose the path from A to H using:
lab@A# show
label-switched-path to-H {
to 2.2.2.2;
admin-group include-all [ gold silver
];
}
} B 5
G 1
1 3 I
2
3
A E 6 1
2 1
D 2
3 H 2.2.2.2
C 6
F 3
4

Administrative Groups V: Solution
 No path between A and H exists that includes both
gold and silver so LSP setup fails
B 5
G 1
1 3 I
2
3
A E 6 1
2 1
D 2
3 H
C 6
F 3
4

Test for Understanding
 Will CSPF prune link C-D when choosing the path
from A to H using this constraint?
lab@A# show
to 1.1.1.1;
admin-group {
exclude admin;
} B 5
} G 1
} 1 3 2 I
3
A E 6 1
2 1
D 2
3 H
C 6
F 3
4

Traffic Protection
and LSP
Optimization
4-1

Primary Paths
 Primary path is optional: zero or one primary path
•If configured, EROs dictate physical path for LSP
•If not configured, LSR makes all decisions to reach egress
 Revertive capability
•Modified with retry-timer, retry-limit, and
revert-timer
•retry-timer:
• Time between attempts to bring up failed primary path
• Default is 30 seconds
•retry-limit:
• Number of failed attempts to bring up primary path
• Default is 0 (unlimited retries)
• If limit reached, human intervention required
•revert-timer:
• Minimum time the primary must be up and stable before traffic is
reverted to it
• Default is 60 seconds
• If set to 0 the LSP does not revert
Secondary Paths
 Optional: zero or more secondary paths
•All secondary paths are equal
• Activated based on order of listing in configuration
 Standby option:
•Preestablishes and maintains secondary path
•Eliminates LSP signaling delays when active path fails
•Additional state information must be maintained

Primary and Secondary Configuration
lab@dc# show
label-switched-path green {
to 192.168.24.1;
primary one {
Primary or secondary designation is
bandwidth 35m; linked to a named path
priority 6 6;
}
secondary two;
}
/* This is primary ERO list */
path one {
10.0.16.2 strict;
}
/* This is second ERO list */
path two {
10.0.21.2 strict;
10.0.22.2 strict;
10.0.29.2 strict;
}

Active Path Selection
 Default is automatic path selection
•If up and stable, the primary path is active
•If not, secondary paths are tried in the order in which they
appear in the configuration
 Override with select manual
or select unconditional path parameters
•The two parameters are mutually exclusive
•select unconditional:
• Higher precedence than select manual
• Path is selected as active even if it is down or degraded
•select manual:
• Path is selected as active if up and stable
• Traffic reverts to this path based on retry-timer, retry-
limit, and revert-timer

Check Your Knowledge
1. How do you configure an LSP that does not revert

back to a path that has failed?
2. What happens when four secondaries exist, and the
first one fails?

Check Your Knowledge: Solution
lab@dc# show protocols mpls

to 192.168.24.1;
revert-timer 0;
primary one;
secondary two;
}
path one {
10.0.16.2 strict;
}
path two {
10.0.29.2 strict;
}
Solution: Set revert-timer to 0 for the LSP

Priorities and Preemption
 Existing LSPs can be torn down to make room for
higher-priority LSPs
•Setup priority of new LSP must be stronger than existing
LSP’s hold priority for preemption to occur
• Priority values range from 0 (strongest) to 7 (weakest)
• Default priority settings prevent preemption (setup = 7 hold = 0)
• LSP’s hold priority must be equal to or stronger than the setup
priority to prevent preemption loops
•High-priority LSPs are signaled first and receive optimal
paths
 Soft preemption is available
user@host# show
label-switched-path sj-to-lo {
to 192.168.28.1;
soft-preemption;
no-cspf;
priority 4 4;
}
interface all; 8
Monitoring Preemption
user@host> show mpls lsp extensive
Ingress LSP: 1 sessions
192.168.24.1
From: 192.168.16.1, State: Up, ActiveRoute: 1, LSPname: green
ActivePath: two (secondary)
LoadBalance: Random
Primary one State: Dn
Priorities: 6 6
Bandwidth: 35Mbps
Will be enqueued for recomputation in 21 second(s).
51 Mar 25 19:53:39 Requested bandwidth unavailable
50 Mar 25 19:53:39 CSPF: computation result accepted
49 Mar 25 19:53:39 Deselected as active
48 Mar 25 19:53:39 Requested bandwidth unavailable
47 Mar 25 19:53:39 Session preempted
46 Mar 25 19:53:39 Down
45 Mar 25 19:51:12 Selected as active path
44 Mar 25 19:51:12 Record Route: 10.0.16.2 S 10.0.1.1 S 10.0.24.2 S
43 Mar 25 19:51:12 Up
42 Mar 25 19:51:12 Originate Call

Test for Understanding
LSP Green 10 Mbps 0 0
ISIS Metric 20
Tokyo London
lo0: 192.168.20.1 ISIS Metric 20 lo0: 192.168.28.1
LSP Purple 10 Mbps 6 4

HongKong Amsterdam
lo0: 192.168.16.1 lo0: 192.168.24.1
ISIS Metric 50
SanJose Montreal
lo0: 192.168.0.1 lo0: 192.168.2.1
LSP Blue 10 Mbps 7 7
label-switched-path Red {
to 192.168.24.1;
priority 6 6;
bandwidth 10M;
}
 Given that all links with existing LSPs have less than 10 M
available, which LSP(s) can be preempted by LSP Red?
Motivations for Fast Reroute
 Ask yourself these questions:
•Is there a way to get quicker failover in the event of primary
LSP failure?
•How can I reduce packet loss when I lose my primary LSP?

Fast Reroute Characteristics (1 of 2)
 Short-term solution to reduce packet loss
•Implements the one-to-one backup method defined in RFC
4090
•When node or link fails, upstream node:
• Immediately detours
• Signals failure to ingress LSR

Fast Reroute Characteristics (2 of 2)
 Only ingress LSR knows all TE constraints
•Ingress router computes alternate route based on
configured secondary paths; tries to reestablish primary
•Initiates long-term reroute solution
•By default, reroute detours inherit administrative groups
only—detours do not honor bandwidth, EROs, etc.
 General characteristics:
•Configured on ingress router only
•Detours around node or link failure
• <~100s of ms reroute time after failure detected
•Detour paths immediately available
•Uses TED to calculate detours
• Does not require a CSPF LSP on ingress node

Fast Reroute Example (1 of 2)
 LSP from San Francisco to New York via LA, Austin,
and Miami
 Enable fast reroute on ingress
•SF creates detour to NY
•LA creates detour to NY
•Austin creates detour to NY Multiple reroute paths merge
•Miami creates detour to NY
Fargo
Seattle
New York
Primary path
San
Francisco Phoenix
Los Angeles Miami

Austin 14
Fast Reroute Example (2 of 2)
 Los Angeles to Austin link fails
•Los Angeles immediately detours around Austin
•Los Angeles signals back to San Francisco that failure
occurred (PathErr)
 San Francisco begins using secondary path via Seattle
Secondary path
Fargo
Seattle
New York
San
Francisco Phoenix
Los Angeles Miami

Austin
Primary path with FRR detour
Configure Fast Reroute
 Add the fast-reroute keyword to LSP definition
•Applies to all primary and secondary paths
[edit]
lab@dc# show protocols mpls . . .
label-switched-path test { path bottom {
to 192.168.24.1; 192.168.8.1 loose;
fast-reroute; 192.168.12.1 loose;
primary top; }
secondary bottom { path top {
bandwidth 75m; 192.168.0.1 loose;
priority 5 5; 192.168.2.1 loose;
standby; }
}
}
. . .

Monitor Fast Reroute: Ingress LSR
lab@HongKong# run show mpls lsp extensive
Ingress LSP: 1 label-switched paths
192.168.24.1
From: 192.168.16.1, State: Up, ActiveRoute: 3, LSPname: test
ActivePath: top (primary)
FastReroute
LoadBalance: Random
*Primary top State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 40)
10.0.16.2 S 10.0.0.2 S 10.0.2.1 S 10.0.24.2 S
7 Mar 26 04:59:31 Fast-reroute Detour Up
6 Mar 26 04:59:25 Selected as active path
5 Mar 26 04:59:25 Record Route: 10.0.16.2 S 10.0.0.2 S 10.0.2.1 S 10.0.24.2 S
4 Mar 26 04:59:25 Up
3 Mar 26 04:59:25 Originate Call
2 Mar 26 04:59:25 CSPF: computation result accepted
1 Mar 26 04:57:58 Path name undefined or disabled[2 times]

Monitor Fast Reroute: Transit LSR (1 of 2)
lab@SaoPaulo> show mpls lsp extensive
Transit RSVP: 2 sessions, 1 detours
192.168.24.1
From: 192.168.16.1, LSPstate: Up, ActiveRoute: 0, LSPname: test
Resv style: 1 FF, Label in: 100045, Label out: 3
Time left: 121, Since: Mon Mar 26 05:06:53 2001
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 6 receiver 194 protocol 0
Detour branch from 10.0.2.1, to skip 192.168.24.1, Up
Detour branch from 10.0.0.1, to skip 192.168.2.1, Up
PATH rcvfrom: 10.0.8.1 (so-0/1/0.0) 7 pkts
PATH sentto: 10.0.31.1 (so-0/1/1.0) 9 pkts
RESV rcvfrom: 10.0.31.1 (so-0/1/1.0) 7 pkts
Explct route: 10.0.31.1
Record route: 10.0.16.1 10.0.1.2 10.0.2.1 10.0.8.1
<self> 10.0.31.1

Monitor Fast Reroute: Transit LSR (2 of 2)
92.168.24.1
From: 192.168.16.1, LSPstate: Up, ActiveRoute: 0, LSPname: test
Resv style: 0 -, Label in: 100043, Label out: -
Time left: 149, Since: Mon Mar 26 05:06:30 2001
Tspec: rate 75Mbps size 75Mbps peak Infbps m 20 M 1500
FastReroute
PATH rcvfrom: 10.0.13.1 (so-0/1/2.0) 8 pkts
PATH sentto: 10.0.31.1 (so-0/1/11.0) 10 pkts
Explct route: 10.0.31.1
Record route: 10.0.15.2 10.0.13.1 <self> ...incomplete
Detour is Up
Detour PATH sentto: 10.0.8.1 (so-0/1/0.0) 9 pkts
Detour RESV rcvfrom: 10.0.8.1 (so-0/1/0.0) 8 pkts
Detour Explct route: 10.0.8.1 10.0.2.1 10.0.24.2
Detour Record route: 10.0.15.2 10.0.13.1 <self> 10.0.8.1
10.0.2.1 10.0.24.2

Link Protection Overview
 Protects interfaces instead of entire LSP path
•Implements the facility backup method defined in RFC 4090
•LSPs must be flagged to make use of a bypass LSP
•Bypass LSP established around protected interface to
adjacent node
• Uses CSPF to calculate bypass LSP
• Can add ERO to influence CSPF routing of bypass LSP
Fargo
New York
San Bypass LSP

Francisco
Los Angeles Miami

© 2008 Juniper Networks, Inc. All rights reserved. Protected Interface Austin 20
Configure Link Protection
 Configure each protected interface under the
[edit protocol rsvp] hierarchy
 Tag LSPs allowed to use bypass LSP
[edit protocols rsvp]
user@sf# show
user@la# show
label-switched-path to-NY {
interface fe-0/0/0.0;
to 192.168.24.1;
link-protection;
primary use-austin;
interface at-0/1/0.0;
}
interface so-0/2/0.100 {
path use-austin {
link-protection;
192.168.1.2 loose;
}
}
interface all;

Monitor Link Protection
lab@la> show rsvp session ingress detail
Ingress RSVP: 1 sessions
10.0.3.4
From: 10.0.3.3, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass_to_10.0.2.6
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 100001
Resv style: 1 SE, Label in: -, Label out: 100001
Time left: -, Since: Wed Feb 19 16:55:36 2003
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Type: Bypass LSP
PATH rcvfrom: localclient
PATH sentto: 10.0.4.2 (fe-0/0/1.0) 9 pkts
RESV rcvfrom: 10.0.4.2 (fe-0/0/1.0) 9 pkts
Explct route: 10.0.4.2 10.0.4.9
Record route: <self> 10.0.4.2 10.0.4.9
Total 1 displayed, Up 1, Down 0

LSP Route Optimization
 Optimization allows LSP rerouting through CSPF

recomputations
•When disabled, the LSP’s path is fixed until a topology
change (or manual clearing) forces a recomputation of the
path
 Optimization is disabled by default
•Enable with:
[edit protocols mpls label-switched path lsp-path-
name]
user@host# set optimize-timer seconds (0...65535)
•Optimization can also be manually initiated

LSP Optimization Rules
 Optimize if new path can be found that meets all of
the following conditions:
1. CSPF metric is not higher (metric is <=)
2. If CSPF metric is equal, path must have fewer hops
3. New path does not cause preemption
4. Does not worsen congestion overall—compare available
bandwidth on each link from new and old paths, starting
with most congested links first
5. Reduces congestion by 10% (implies previous rule)
• Compares aggregate available bandwidth of new and old path (for
least fill only)
• Intentionally conservative rules: Use with care
• Optimize aggressive (optional): Limits reoptimization to IGP
metric only; tends to reroute more often

Adaptive Mode
 Adaptive mode provides make-before-break capability
•Establish new path (same session ID, different sender
template) with SE-style reservation
•Transfer traffic to new path
•Tear down old path
•Primarily useful when rerouting an LSP
•Avoids double-counting resources on shared links
• When configured as a primary/secondary path option, adaptive
does not prevent double bandwidth counting for that
primary/secondary pair
• When configured at the LSP level, adaptive prevents double
counting of resources for that primary/secondary pair
 Configuration example: LSP level application
[edit protocols mpls label-switched-path lsp-path-
name]
user@host# set adaptive

RSVP Reservation Styles
B F
Shared
Link
Ingress Egress
A C E G
LSR LSR
D H
Session 1
Session 2
FF Reservation Style: (default) SE Reservation Style: (adaptive)

Each session/sender has its own Each session/sender has its own
identity identity
Each session has its own bandwidth Sessions share a single bandwidth
reservation reservation

Check Your Knowledge: Adaptive
Will the secondary physical path Green be in an up
state or a down state?
Primary Physical Path
HongKong Amsterdam
lo0: 192.168.16.1 lo0: 192.168.24.1
SanJose Montreal
lo0: 192.168.0.1 lo0: 192.168.2.1
Secondary Physical Path
Denver
lab@HongKong# show label-switched-path to-AM
to 192.168.24.1;
bandwidth 85m;
no-cspf;
primary Blue {
adaptive;
}
secondary Green {
standby;
adaptive;
}

Forwarding Adjacency Overview
lab@SanJose# show protocols
mpls {
to 192.168.2.1;
primary one;
}
path one {
192.168.5.1 loose;
}
isis {
Forwarding adjacencies
interface all { announce LSPs as point-to-
level 1 disable; point interfaces into the
} IGP routing table
level 2 metric 3;
}
}

Forwarding Adjacency: Operation
Tokyo London
lo0: 192.168.20.1 lo0: 192.168.28.1
HongKong Amsterdam
lo0: 192.168.16.1 lo0: 192.168.24.1
SanJose Montreal
lo0: 192.168.0.1 lo0: 192.168.2.1
192.168.24/24
192.168.25/24
Note: Bidirectional 192.168.26/24
192.168.27/24
reachability MUST exist 200.0.5.0/24
Denver
lo0: 192.168.5.1
Sydney SaoPaulo
Dallas
lo0: 192.168.8.1 lo0: 192.168.12.1

Forwarding Adjacencies: Data Plane
lab@HongKong> traceroute 192.168.24.1
traceroute to 192.168.24.1 (192.168.24.1), 30 hops max, 40 byte packets
1 10.0.16.2 (10.0.16.2) 0.593 ms 0.485 ms 0.431 ms
2 10.0.0.2 (10.0.0.2) 0.685 ms 0.665 ms 0.642 ms
MPLS Label=100009 CoS=0 TTL=1 S=1
3 10.0.2.1 (10.0.2.1) 0.788 ms 0.965 ms 0.821 ms
4 192.168.24.1 (192.168.24.1) 1.279 ms 0.917 ms 0.813 ms

Forwarding Adjacency: Control Plane
lab@HongKong> show isis route
IS-IS routing table Current version: L1: 1150 L2:
1371
Prefix L Version Metric Type Interface Via
10.0.0.0/24 2 1371 20 int ge-0/0/0.0 SanJose
10.0.1.0/24 2 1371 20 int ge-0/0/0.0 SanJose
10.0.2.0/24 2 1371 23 int ge-0/0/0.0 SanJose
10.0.8.0/24 2 1371 30 int ge-0/0/0.0 SanJose
10.0.24.0/24 2 1371 23 int ge-0/0/0.0 SanJose
10.0.29.0/24 2 1371 33 int ge-0/0/0.0 SanJose
10.0.31.0/24 2 1371 33 int ge-0/0/0.0 SanJose
192.168.0.1/32 2 1371 10 int ge-0/0/0.0 SanJose
192.168.2.1/32 2 1371 13 int ge-0/0/0.0 SanJose
192.168.5.1/32 2 1371 20 int ge-0/0/0.0 SanJose
192.168.8.1/32 2 1371 10 int fe-0/2/1.0 Sydney
192.168.12.1/32 2 1371 30 int ge-0/0/0.0 SanJose
192.168.20.1/32 2 1371 10 int so-0/3/0.0 Tokyo
192.168.24.1/32 2 1371 23 int ge-0/0/0.0 SanJose

Check Your Knowledge
 Assuming the IGP is IS-IS and a forwarding adjacency is
configured for each LSP, how many LSPs will SanJose
advertise as point-to-point links?
Tokyo London
lo0: 192.168.20.1 lo0: 192.168.28.1
HongKong Amsterdam
lo0: 192.168.16.1 lo0: 192.168.24.1
SanJose Montreal
lo0: 192.168.0.1 lo0: 192.168.2.1
192.168.24/24
192.168.25/24
192.168.26/24
192.168.27/24
200.0.5.0/24
Denver
lo0: 192.168.5.1
Sydney SaoPaulo
Dallas
lo0: 192.168.8.1 lo0: 192.168.12.1

Policy Control over LSP Selection
 Control LSP next hops installed in the forwarding table
•Use install-nexthop lsp lsp-name action in a
policy statement
•Apply as an export policy to the forwarding table
policy-options { routing-options {
policy-statement lsp-policy { forwarding-table {
term first-route { export lsp-policy;
from { }
route-filter 192.168.48.0/24 exact; }
}
then {
install-nexthop lsp TO-to-SP;
accept;
}
}
term second-route {
from {
}
then {
install-nexthop lsp TO-to-SP-2;
accept;
}
}
}
} Juniper Networks, Inc. All rights reserved.
© 2008 33
Traffic Engineering bgp-igp
 LSP end points normally installed into inet.3 table
•Usable only by BGP for next-hop resolution
 Provides TE for internal destinations
•Moves all inet.3 prefixes into inet.0
•IGP can now use all LSPs
 Configured at the [edit protocols mpls]
hierarchy
lab@Tokyo# set traffic-engineering ?
bgp BGP destinations only
bgp-igp BGP and IGP destinations
bgp-igp-both-ribs BGP and IGP destinations with routes in both routing tables
mpls-forwarding Use MPLS routes for forwarding, not routing

MPLS Forwarding
 mpls-forwarding is another traffic engineering
option
•Addresses issues with bgp-igp overshadowing IGP routes
for RSVP-signaled and LDP-signaled LSPs
•Configured at the [edit protocols mpls] hierarchy
•Keeps routes in inet.3 for VPN and normal BGP route
resolution
•Keeps IGP routes active (for policy export, etc.) while allowing
LSP forwarding next hops in inet.0

lab@Tokyo# set traffic-engineering mpls-forwarding

MPLS Forwarding: Operational Results
lab@r7> run show route 10.0.9.6

Restart Complete
@ = Routing Use Only, # = Forwarding Use Only
10.0.9.6/32 @[IS-IS/15] 00:00:03, metric 20

> to 10.0.8.9 via fe-0/3/1.0
#[RSVP/7] 00:00:00, metric 20
> to 10.0.8.9 via fe-0/3/1.0, label-switched-path test

Restart Complete
@ = Routing Use Only, # = Forwarding Use Only
10.0.9.6/32 *[RSVP/7] 00:00:00, metric 20

> to 10.0.8.9 via fe-0/3/1.0, label-switched-path test

LSPs and Metrics
 When calculating paths with CSPF:
•By default, CSPF uses metric of shortest IGP path
•IS-IS te-metric to modify metric for CSPF calculation (only)
 For LSP selection from existing LSPs:
•LSP metric is IGP shortest cost, regardless of CSPF metric
 Can be overridden with manual metric assignment
[edit protocols mpls label-switched-path test]
lab@r3# show
to 10.0.3.4;
metric 4;
bandwidth 80m;
•IGP protocol metric can be manually assigned for

forwarding adjacency

Explicit Null Configuration
 Configure explicit null globally under MPLS or LDP
•Enables routers to signal label 0 instead of 3
•Compliant with RFC 3032
•Enables easier COS configuration and interoperability
[edit]
lab@Amsterdam# set protocols mpls explicit-null
or
lab@HongKong# set protocols ldp explicit-null
lab@Montreal# run show rsvp session

Transit RSVP: 2 sessions
To From State Rt Style Labelin Labelout LSPname
192.168.24.1 192.168.16.1 Up 1 1 FF 100003 0 HK-AM1
192.168.24.1 192.168.16.1 Up 1 1 SE 100004 0 HK-AM1

Automatic Bandwidth Provisioning
 Network automatically adjusts LSP bandwidth
•Router resignals LSP for highest average utilization over
specified timeframe
•Utilization determined by MPLS statistics feature (default =
5 minutes), default resignaling interval is 24 hours
•Configuration options include:
• Minimum and maximum bandwidth range for autoprovisioning
• Time interval for adjusting LSP’s bandwidth
• Threshold for average LSP utilization change that triggers new LSP
calculation
• Statistics gathering interval under [edit mpls statistics]
•Works with adaptive for make-before-break capability

Configure Automatic Bandwidth
[edit]
lab@dc# show protocols mpls
statistics {
file test;
auto-bandwidth;
}
label-switched-path MO-SY {
to 192.168.8.1;
install 192.168.16.0/32 active;
auto-bandwidth;
}

Monitor Auto Bandwidth
lab@Montreal# run show mpls lsp extensive
Ingress LSP: 1 sessions
192.168.8.1
From: 192.168.2.1, State: Up, ActiveRoute: 6, LSPname: MO-SY
ActivePath: PATH-4 (primary)
LoadBalance: Random
Autobandwidth
AdjustTimer: 86400 secs
Max AvgBW util: 0bps, Bandwidth Adjustment in 86395 second(s).
*Primary PATH-4 State: Up

MPLS TTL Handling Options
 Default behavior decrements TTL on all LSR hops
•Used for loop prevention and topology discovery using
traceroute
 Disable TTL decrement inside LSP using no-
decrement-ttl
•Proprietary Juniper Networks object; all LSRs must support
the option
•Supported for RSVP on per LSP basis or global basis
•IP TTL decremented at egress router only
•Sets TTL to 255 on ingress router, disables TTL writeback on
penultimate router
 Disable TTL decrement inside LSP using no-
propagate-ttl
•Global effect on LDP and RSVP, not configurable per-LSP
•No topology discovery
•IP TTL decremented at egress router only
•Sets TTL to 255 on ingress router and disables writeback on
penultimate router
Normal TTL Handling
MPLS TTL 16
IP TTL 18
Penultimate Router
1 5
IP TTL 18 IP TTL 14
4
MPLS TTL 17
2
IP TTL 18 IP TTL 15
MPLS write back to IP Header

No Decrement TTL
MPLS TTL 254

IP TTL 17
Penultimate Router
1 5
IP TTL 18 IP TTL 16
4
2 MPLS TTL 255
IP TTL 17 IP TTL 17
MPLS does not write back to IP header

No Propagate TTL
MPLS TTL 254

IP TTL 17
Penultimate Router
1 5
IP TTL 18 IP TTL 16
4
MPLS TTL 255
2
IP TTL 17 IP TTL 17
MPLS does not write back to IP header

Confirm Forwarding With MPLS Ping
 Feature allows ping testing of RSVP-signaled and
LDP-signaled LSPs
•Does not rely on BGP routes or modification of default
routing table integration rules
•Must assign a 127.0.0.1 address to egress node’s lo0
interface!
RSVP/LDP LSP
r3 r5 r4 127.0.0.1 assigned to lo0

on egress router!
lab@r3> ping mpls rsvp test

!!!!!

VPN Review

What Is a VPN?
Data Center
Shared Public Infrastructure
Corporate Home Office

Office
 Virtual private network: Branch Office
•A private network constructed over a shared infrastructure

•Virtual: Not a separate physical network
•Private: Separate addressing and routing
•Network: A collection of devices that communicate
•Constraints are key—restricted connectivity is the goal

Deploying VPNs
 Uses IP infrastructure
•Can be shared with Internet services
 Increasing importance of IP/MPLS (not ATM/Frame
Relay)
 Subscriber benefits:
•Lower operational expenses
•Single network connection for multiple services
 Provider benefits:
•Multiservice infrastructure
•Creates additional source of revenue

VPN Classification Model CPE
Site 2
 CPE-VPNs: CPE-VPN
PE
•L2TP and PPTP Site 1 Site 3
•IPsec tunnel mode VPN Tunnel

CPE PE PE CPE
 PP-VPNs:
•BGP/MPLS-based VPNs (RFC 4364)
CE
• RFC 4364 was formerly Site 2
draft-ietf-l3vpn-rfc2547bis
•Virtual routers PP-VPN
•Layer 2 MPLS VPNs Site 1
PE
Site 3
• BGP Layer 2 VPN
VPN Tunnel
• LDP Layer 2 circuits CE PE PE CE
•VPLS
• BGP signaled VPLS
• LDP signaled VPLS
CPE-VPNs: L2TP and PPTP
 Application: Dial access for remote users
•Layer 2 Tunneling Protocol
• RFC 2661
• Combination of L2F and Point-to-Point Tunneling Protocol
•Point-to-Point Tunneling Protocol
• Bundled with Windows and Windows NT
•Authentication during setup
•IPsec can operate over PPP for stronger security
Dial Access L2TP Access
Server Server
V.x Modem L2TP Tunnel
Dial Access Provider Service Provider or VPN

PPP Dial-Up PPTP Tunnel
Dial Access PPTP Access

Server Server
CPE-VPNs: IPsec Tunnel Mode
 IPsec defines IETF Layer 3 security architecture

 Applications:
•Strong security requirements, across one or multiple ISPs
•Customer responsible for key management
 Security services include:
•Access control
•Data origin authentication
•Replay protection
•Data integrity
•Data privacy (encryption)
•Key management
CPE-VPNs: IPsec Example
 Routing must be performed at CPE

 Secure tunnels terminate on subscriber premise
 Only the CPE must support IPsec
•Modifications to shared/public resources are not required
IPsec Tunnel
Public Internet
Site 1 Site 2
CPE PE PE CPE

Provider-Provisioned VPNs: Layer 3 and
Layer 2
 Layer 3 characteristics
•Provider’s routers participate in customer’s Layer 3 routing
•Provider’s routers manage VPN-specific routing tables,
distributes routes to remote sites
•CE routers advertise their routes to the provider
 Layer 2 characteristics
•Customer maps its Layer 3 routing to the circuit mesh
•Provider delivers Layer 2 circuits to the customer, one for
each remote site
•Customer routes are transparent to provider

Layer 3 PP-VPNs: RFC 4364 (1 of 2)
 Application: Outsource VPN
•PE router maintains VPN-specific forwarding tables for each
of its directly connected VPNs
•Conventional IP routing between CE and PE routers
•VPN routes distributed using MP-BGP
• Uses extended communities
•VPN traffic forwarded across provider backbone using MPLS
Service Provider Network
CE CE
PE PE
Site 1 VRF VRF Site 3
P
VRF
CE CE
P
Site 2 Site 2
P
P
CE VRF CE
Site 3 VRF Site 1
VRF P
PE PE

Layer 3 PP-VPNs: RFC 4364 (2 of 2)
 LDP or RSVP is used to set up PE-to-PE LSPs

 MP-BGP is used to distribute information about the
VPN
•Routing and reachability for the VPN
•Labels for customer sites (tunneled in PE-PE LSP)
 Constrain connectivity by route filtering
•Flexible, policy-based control mechanism

Layer 3 PP-VPNs: Virtual Routers
 Virtual router functions:

•Virtual router maintains VPN-specific forwarding tables
•PE router participates in private network routing
•Routing for private networks is tunneled along with data
using IPsec, GRE, or possibly MPLS between PE routers
• Virtual router within PE router operates as if it were a normal router
in the private network

Layer 3 PP-VPNs Advantages
 Subscriber:
•Offload routing complexity to provider
•Suits enterprises that do not want to build core routing
competency into their organizations
 Provider:
•VPN-specific routing information is not maintained on all
backbone routers
•Value-added service (revenue opportunity)

Layer 3 PP-VPNs Limitations
 Outsourcing moves administrative burden to provider

•Can be a substantial provisioning and maintenance burden
• Network management tools for adds, moves, and changes
 Some customers prefer to maintain control of their
routing architecture

MPLS-Based Layer 2 PP-VPNs
 Layer 2 MPLS-based VPNs:

•CCC
•BGP Layer 2 VPNs (draft-kompella)
•LDP Layer 2 circuits (RFC 4447)
•BGP VPLS (RFC 4761)
•LDP VPLS (RFC 4762)

Circuit Cross-Connect
 Provides the foundation for MPLS-based Layer 2 VPNs
•Broad support of PE-CE interface types
• ATM, Frame Relay, VLAN, PPP, and HDLC
 Service provider maintains LSPs between PE routers
•One LSP per VC being serviced
•Ingress PE maps each inbound PVC to a dedicated LSP
•Egress PE maps incoming LSP to outbound PVC
 CE routes VPN traffic based on subnet/PVC mappings
Large Provider PE CE
IP/MPLS Network
Site 2
DLCI 605
Network
CE 10.0.0.0/8
Site 1 DLCI 600 PE CCC Table
In Out
Source
DLCI 610 LSP 1 DLCI 605
LSP 2 DLCI 608
Routing Table CCC Table Site 3
In Out In Out Network
DLCI 600 LSP 1
DLCI 608 20.0.0.0/8
10/8 DLCI 600 DLCI 610 LSP 2 PE CE
20/8 DLCI 610
Circuit Cross-Connect Drawbacks
 List of CCC drawbacks includes:

•CE and PE router configuration
• Complex initial configuration
• Tedious configuration for adds, moves, and changes
• Interaction between service provider and customer required
•Each DLCI/PVC requires a dedicated set of LSPs
•Only appropriate for small numbers of individual private
connections
•Interface types must be the same at all CE device locations
• TCC can be used for unlike interfaces

BGP Layer 2 VPNs
 Leverages experience with CCC and MPLS

 Scalable in data and control planes
•Data plane: Label stacking consolidates multiple DLCIs,
PVCs, or VLANs over a single LSP
•Provisioning: BGP for autoconfiguration
 Routing for private network is CE to CE
Large Provider PE CE
IP/MPLS Network DLCI 605
Site 2
CE
Site 1 DLCI 600 PE
Source
DLCI 610
Site 3
DLCI 608
PE CE

LDP Layer 2 Circuits
 Leverages experience with CCC and MPLS
 Improved data plane scalability with Layer 2 VPNs
•Label stacking consolidates multiple DLCIs, PVCs, or VLANs
over a single LSP
 Must provision both ends of each circuit when adding
a site
 Routing for private network is CE to CE
MPLS Core
DLCI 600 LSP 1 DLCI 605

Site 1 Site 2
DLCI 610 DLCI 608

Virtual Private LAN Service
 To the customer in a VPLS environment, the
provider’s network appears to function as a single
LAN segment
•Acts similarly to a learning bridge
 Administrator does not need to map local circuit IDs
to remote sites
•PE device learns MAC address from received Layer 2 frames
•MAC addresses are dynamically mapped to outbound MPLS
LSPs and/or interfaces CE
CE VPN A
VPN A Site 3
PE
Site 1 PE P P
PE
CE CE
VPN A VPN A
Site 2 Site 4

MPLS-Based Layer 2 VPNs: Advantages
 Subscriber:
•Can outsource circuits
•Maintains control of routing
•Uses any Layer 3 protocol
 Provider:
•Complements RFC 4364
• Operates over the same core, using the same outer LSP
•Can collapse Layer 2 VPNs (Frame Relay, ATM, and VLANs)
onto a single IP/MPLS infrastructure
•Reduces the number of LSPs with label stacking compared
with CCC
•Simplifies adds, moves, and changes with automatic
provisioning when using BGP Layer 2 VPNs

MPLS-Based Layer 2 VPNs: Issues
 Circuit type (ATM/Frame Relay/VLAN) to each VPN

site must be uniform
•TCC can be used when circuits connecting sites differ
 Removes a provider revenue opportunity
•Provider no longer adding value by managing routing over
the backbone
 Customer must have routing expertise

Layer 3 VPNs

Customer Edge Routers
Customer Edge
PE
P CE
P
VPN A CE VPN A
PE CE
VPN B CE PE VPN B
 CE routers:
•Located at customer premises
•Provide access to the service provider network
•Can use any access technology or routing protocol for the
CE/PE connection

Provider Edge Routers
Provider Edge
PE
P CE
P
VPN A CE VPN A
PE CE
VPN B CE PE VPN B
 PE routers:
•Maintain VPN-specific forwarding tables
•Exchange VPN routing information with other PE routers
using BGP
•Use MPLS LSPs to forward VPN traffic

Provider Routers
Provider Routers
PE
P CE
P
VPN A CE VPN A
PE CE
VPN B CE PE VPN B
 P routers:
•Forward VPN data transparently over established LSPs
•Do not maintain VPN-specific routing information

VPN Sites
VPN Site
PE
P CE
P
VPN A CE VPN A
PE CE
VPN B CE PE VPN B
 A site is a collection of machines that can

communicate without traversing the service provider
backbone
 Each VPN site is mapped to a PE router interface
•Routing information is stored in different tables for each site
VPN Routing and Forwarding Tables
A VRF is created
VPN A for each site VPN A
Site 1 connected to the PE Site 2
CE–A2 VPN B
Site 2
CE–A1 OSPF
P P Routing
PE 2
VPN B Static CE–B2
Site 1 Routing VPN A
PE 1 CE–A3 Site 3
CE–B1 P P PE 3
BGP
Routing
CE–B3
CE–C1
CE–C2
VPN C VPN C
Site 1 VPN B Site 2
Site 3

VRF Tables
 Each VRF table is populated with:

•Routes received from directly connected CE sites associated
with the VRF table
•Routes received from other PE routers with acceptable
MP-BGP attributes
 Packets from a given site are only matched against
the site’s corresponding VRF table
•Provides isolation between VPNs

Overlapping Address Spaces
VPN A
10.1/16 Site 2
VPN A CE–A1 10.1/16 CE–A2
?
Site 1
PE 2
PE 1
VPN B 10.1/16
Site 1
CE–B2 VPN B
CE–B1 Site 2
10.1/16
 VPNs A and B use the same address space

•PE 1 uses a separate routing (VRF) table for each VPN site
•PE 2 would normally choose between the two 10.1/16 routes
• MPLS/BGP VPNs solve this problem with the route distinguisher

VPN-IPv4 NLRI Format
Route Distinguisher
Mask MPLS Label Type Administrator Assigned Number Subscriber IPv4 Prefix
(1 byte) (3 bytes) (2 bytes)(variable length) (variable length) (0–4 bytes)
 VPN-IPv4 address family
•New BGP-4 subsequent address family identifier (SAFI 128)
• Consists of MPLS label + route distinguisher + subscriber IPv4 prefix
•Route distinguisher disambiguates IPv4 addresses
• Allows service provider to administer its own numbering space
 VPN-IPv4 addresses are distributed by MP-BGP
•Uses multiprotocol extensions for BGP4 (RFC 2858)
 A /32 IPv4 prefix produces a VPN-IPv4 prefix with a mask
of /120 (15 octets)
•The Junos OS CLI displays (and the examples in this class) only
show IPv4 prefix length (that is, /32)
Route Distinguisher Formats
8-Byte Route Distinguisher 4-Byte IP Address
(Type) (Adm) (AN)

Assigned Number Field: Number assigned by the identified
authority for a particular purpose
Administration Field: Identifies the assigned number authority
2-Byte Type Field: Determines the lengths of the other two fields
 Two values are defined for type field: 0 and 1

•Type 0: adm field = 2 bytes, AN field = 4 bytes
• Adm field should contain an ASN from IANA
• AN field is a number assigned by service provider
•Type 1: adm field = 4 bytes, AN field = 2 bytes
• Administration field should contain an IP address assigned by IANA
• Assigned number field is a number assigned by service provider
•Examples: 10458:22:10.1.0.0/16 or
1.1.1.1:33:10.1.0.0/16
The VPN-IPv4 Address Family
 Route distinguisher disambiguates IPv4 addresses

 VPN-IPv4 routes
•Ingress PE router prepends route distinguisher to IPv4 prefix
of routes received from each CE device
•VPN-IPv4 routes are exchanged between PE routers using
MP-BGP
•Egress PE router converts VPN-IPv4 routes into IPv4 routes
before inserting into site’s routing (VRF) table
 VPN-IPv4 is used only in the control plane
•Data plane uses MPLS-encapsulated IPv4 packets

Using Route Distinguishers to
Disambiguate Addresses
VPN A
10.1/16 Site 2
VPN A CE–A1 10458:22:10.1/16 CE–A2
?
Site 1
PE 2
PE 1
VPN B 10458:23:10.1/16
Site 1
CE–B2 VPN B
CE–B1 Site 2
10.1/16
 The overlapping routes from A and B appear to be

non-overlapping to PE2 because of the prepended
route distinguisher
RFC 4364: Operational Overview
VPN A
Site 2
VPN A CE–A2
Site 1
CE–A1 P P
VPN B
VPN B PE 2 CE–B2 Site 2
Site 1
PE 1
CE–A3
VPN A
CE–B1 PE 3
P P Site 3
 Control flow (signaling plane):

•Routing information exchange between CE and PE routers
• Independent at both ends
•Routing information exchange between PE routers
•LSP establishment between PE routers (RSVP or LDP
signaling)
 Data flow (forwarding plane):
•Forwarding user traffic
RFC 4364 Policies
 VPNs are defined by administrative policies

•Used for connectivity and quality of service guarantees
•Defined by customers
•Implemented by service providers
 Full-mesh or hub-and-spoke connectivity
•Logical VPN topology results from the application of export
and import route target policies

PE-PE Route Distribution
 Distribution of routes is controlled by BGP extended
community attributes and VRF policy
•Route target
• Identifies a set of VRFs to which a PE router distributes routes
•Site of origin/route origin
• Identifies the specific site from which a PE router learns a route
 Structured similarly to the route distinguisher
•8 bytes in length (2-byte type field, 6-byte value field)
•Type 0:
• 2-byte global administrator subfield (ASN)
• 4-byte local administrator subfield
•Type 1:
• 4-byte global administrator subfield (IANA-assigned IP Address)
• 2-byte local administrator subfield
Route Target Extended Community
 Each VPN-IPv4 route advertised through MP-BGP is
associated with a route target community
•Export policy or explicit configuration define the targets
associated with routes a PE router sends
 Upon receipt of a VPN-IPv4 route, a PE router decides
whether to add that route to a VRF table
•Import policies or explicit configuration define which routes
to add to a given VRF table
 Route isolation between VRF tables is accomplished
through careful policy administration
•Service provider provisioning tools can determine the
appropriate export and import targets automatically

Exchange of Routing Information (1 of 7)
VPN B CE-1 CE-2 VPN B

PE-1 MP-BGP Session PE-2
Site 1 Site 2
VRF VRF
CE-4
VPN A CE-3 VRF VRF VPN A
Site 1 OSPF Site 2
10.1/16
 CE device advertises route to PE router

•Using traditional routing techniques (for example, OSPF, RIP,
BGP, and static routes)

VPN B CE-1 MP-BGP Session CE-2 VPN B

PE-1 PE-2
Site 1 Site 2
VRF VRF
CE-4
Site 1 OSPF Site 2
10458:23:10.1/16 10.1/16
 IPv4 address is added to the appropriate VRF table


PE-1 PE-2
Site 1 Site 2
VRF VRF
CE-4
Site 1 OSPF Site 2
10458:23:10.1/16
10.1/16
3 VPN RED Export
 VRF table is configured to advertise the routes in the

VRF table as L3 VPN routes using MP-BGP
•VRF table configuration adds VPN RED route target
community


PE-1 PE-2
Site 1 Site 2
VRF VRF
CE-3 CE-4
VPN A VRF VRF VPN A
Site 1 OSPF Site 2
10458:23:10.1/16
10.1/16
VPN RED Export
4 Label Z
Next Hop PE-2
 VPN-IPv4 NLRI is advertised to other PE routers

•Inner label (also known as VRF label, BGP label)
•Extended communities
• Route target
• Site of origin
•BGP next hop (RID of advertising PE router)
Site 1 Site 2
VRF VRF
CE-4
Site 1 OSPF Site 2
10458:23:10.1/16
VPN RED Import VPN RED Export 10.1/16
MP-BGP
Label Z
5 Next Hop PE-2
 Each PE router is configured with import route targets

•Import route target is used to incorporate VPN-IPv4 routes into
VRF tables selectively
• If import route target matches route target attribute in BGP route, the route is
installed into the bgp.l3vpn table and copied into appropriate VRF table(s)
• Based on configured route target or import policies, 10458:23:10.1/16 is
copied into the RED VRF—but not the BLUE VRF

Site 1 Site 2
VRF VRF
CE-3 CE-4
VPN A VRF VRF VPN A
Site 1 OSPF Site 2
10458:23:10.1/16
VPN RED Import
MP-BGP VPN RED Export
10458:23:10.1/16 10.1/16
Label Z
6 BGP Label (Inner) Label (Z) Next Hop PE-2
MPLS (Outer) Label (y)
 Each VPN-IPv4 route in a VRF table is associated with:

•Inner (VRF) label to reach the advertised NLRI (carried in
MP-BGP update)
•Outer label to reach the PE router
 All routes associated with the same VRF interface can
share a common label

Site 1 Site 2
VRF VRF
CE-4
Site 1 OSPF Site 2
10.1/16 Next Hop PE-1
 Each IPv4 route installed in a VRF table can be

advertised to the CE devices associated with that VRF
table
•For example, RIP, OSPF, and BGP
•Routing policy can be used on the PE-CE link to control the
exchange of routing information further
Data Flow (1 of 7)
VPN B CE-1 LSP CE-2 VPN B

PE-1 PE-2
Site 1 Site 2
VRF VRF
CE-3 CE-4
VPN A VRF VRF VPN A
Site 1 OSPF Site 2
10.1/16
 The PE-to-PE LSP must be in place before forwarding
data across the MPLS backbone
•LSPs are signaled through LDP or RSVP

Data Flow (2 of 7)

Site 1 PE-1 PE-2 Site 2
VRF VRF
CE-4
Site 1 OSPF Site 2
IP 10.1/16
10.1.2.3
 The CE device performs a traditional IPv4 lookup and

sends packets to the PE router

Data Flow (3 of 7)
PE-1
1) Look up route in Red VRF
2) Push BGP label (z)
3) Push outer label (x)

PE-1 PE-2
Site 1 Site 2
VRF VRF
CE-3 CE-4
VPN A VRF VRF VPN A
Site 1 OSPF Site 2
IP 10.1/16
10.1.2.3
 The PE router consults the appropriate VRF table for
the inbound interface
 Two labels are derived from the VRF route lookup and
are pushed onto the packet
Data Flow (4 of 7)
PE-1
1) Look up route in Red VRF
2) Push BGP label (z)
VPN B CE-1 3) Push outer label (x) CE-2 VPN B
VRF VRF
CE-3 CE-4
VPN A VRF VRF VPN A
Site 1 Outer label (x) Site 2
OSPF
BGP label (z)
IP IP 10.1/16
10.1.2.3 10.1.2.3
 Packets are forwarded using two-level label stack

•Outer (MPLS) label: •Inner (MP-BGP) label:
• Identifies the LSP to egress •Identifies outgoing
PE router interface from egress PE
• Resolves BGP next hop to CE
through inet.3
•Communicated in MP-BGP
• Distributed by RSVP or LDP
updates (control plane)
Data Flow (5 of 7)

VRF VRF
CE-3 CE-4
VPN A VRF VRF VPN A
Site 1 OSPF Site 2
Outer label (x)
BGP label (z)
IP 10.1/16
10.1.2.3
 After packets exit the ingress PE router, the outer

label is used to traverse the service provider
•P routers are not VPN aware

Data Flow (6 of 7)
Penultimate
Pop top label
VRF VRF
CE-3 CE-4
VPN A VRF VRF VPN A
Site 1 OSPF Site 2
BGP label (z)
IP 10.1/16
10.1.2.3
 Penultimate hop popping (before reaching the egress

PE router) removes the outer label

Data Flow (7 of 7)

PE-1 PE-2
Site 1 Site 2
VRF VRF
CE-3 CE-4
VPN A VRF VRF VPN A
Site 1 OSPF Site 2
IP
10.1/16
10.1.2.3
 The inner label is removed at the egress PE router
 The native IPv4 packet is sent to the outbound
interface associated with the label

Basic Layer 3 VPN
Configuration

Layer 3 VPN Preliminary Configuration
 Preliminary steps:
•Choose and configure the IGP for PE and P routers
•Configure MP-BGP peering among PE routers
• Must include VPN-IPv4 NLRI capability
•Enable the label-switched path signaling protocols
•Establish LSPs between PE routers
 The PE routers perform VPN-specific configuration

Introduction to VPN Routing Tables (1 of 2)
 VPN routing tables (Part 1):

• inet.0
• Main IP routing table, relevant for IGP and BGP
• inet.3
• RSVP and LDP routes installed, relevant for BGP only
• mpls.0
• MPLS switching table

Introduction to VPN Routing Tables (2 of 2)
 VPN routing tables (Part 2):

• vpn-name.inet.0
• Stores all unicast IPv4 routes received from directly connected CE
routers and all explicitly configured static routes in the routing
instance
• For each vpn-name.inet.0 routing table, one forwarding table
is maintained
• bgp.l3vpn.0
• Stores all VPN-IPv4 unicast routes received from other PE routers
• This table is present only on PE routers—routes are resolved using
the information in the inet.3 routing table

PE-PE MP-BGP Peering
 PE-to-PE MP-BGP sessions require VPN-IPv4 NLRI

 The Junos OS automatically negotiates BGP route
refresh
[edit]
user@R1# show protocols bgp
group my-int-group {
type internal;
local-address 192.168.1.1;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
neighbor 192.168.1.3;
}

MP-BGP Peering: PE-PE (NLRI Information)
user@R1> show bgp neighbor 192.168.1.3
Peer: 192.168.1.3+50833 AS 65512 Local: 192.168.1.1+179 AS 65512
Type: Internal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress AddressFamily Rib-group Refresh>
Address families configured: inet-unicast inet-vpn-unicast
Local Address: 192.168.1.1 Holdtime: 90 Preference: 170
Number of flaps: 1
Last flap event: RecvNotify
Error: 'Cease' Sent: 0 Recv: 1
Peer ID: 192.168.1.3 Local ID: 192.168.1.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast inet-vpn-unicast
NLRI advertised by peer: inet-unicast inet-vpn-unicast
NLRI for this session: inet-unicast inet-vpn-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
…

MP-BGP Peering: PE-PE (Route Tables)
Peer: 192.168.1.3+50833 AS 65512 Local: 192.168.1.1+179 AS 65512
…
Table bgp.l3vpn.0
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not advertising
Active prefixes: 2
Received prefixes: 2
Accepted prefixes: 2
Suppressed due to damping: 0
Table vpn-a.inet.0 Bit: 50000
Send state: in sync
Active prefixes: 2
Advertised prefixes: 2

PE Router Basic Configuration
 All VPN-specific configuration on the PE routers

 PE routing instance
•Create routing instance and list associated VRF interfaces
•Assign a route distinguisher
•Link the VRF table to import and export policies or configure
the vrf-target statement
•Configure PE-CE routing protocol properties
 VPN policy
•Create and apply BGP extended communities (for example,
route target/site of origin)
•Create VRF import and export policies

Layer 3 VPN Topology Example
 Network characteristics:
•IGP is single-area OSPF
•RSVP signaling between PE devices, LSPs established
between PE routers (CSPF not required)
•MP-BGP peering between PE routers, loopback peering,
VPN-IPv4 NLRI
•CE-PE link running EBGP
•Full-mesh Layer 3 VPN between CE-A and CE-B
Provider Core
AS 65512
Site 1 OSPF Area 0 Site 2
AS 65101 AS 65101
R1 R2 R3
.2 .1 .1 .2 .2 .1 .1 .2 Site 2
Site 1
10.0.10.0/24 172.22.210.0/24 172.22.212.0/24 10.0.11.0/24
CE-A PE P PE CE-B
lo0 192.168.11.1 lo0 192.168.1.1 lo0 192.168.1.3 lo0 192.168.11.2

VRF Routing Instances
 VRF tables are created at the [edit routing-
instances instance-name] hierarchy:
[edit routing-instances vpn-a]
user@R1# show
instance-type vrf;
interface <interface-name>;
route-distinguisher <rd_type>;
vrf-target <target community>;

Assigning the Route Distinguisher
 Manually assign the route distinguisher per VRF

user@R1# show
instance-type vrf;
route-distinguisher 192.168.1.1:1;
 Enable router to dynamically assign a unique Type 1

route distinguisher to every configured VRF
user@R1# show
route-distinguisher-id 192.168.1.1;
autonomous-system 65512;

VRF Instance Configuration Example
 Create a VRF table called vpn-a with BGP running
between the PE and CE routers using the
vrf-target statement:
[edit routing-instances]
user@R1# show
vpn-a {
instance-type vrf;
vrf-target target:65512:101;
protocols {
bgp {
group my-ext-group {
type external;
peer-as 65101;
neighbor 10.0.10.2;
}
}
}
}
Another VRF Configuration Example
 Create a VRF table called vpn-a with BGP running
between the PE and CE routers using vrf-import
and vrf-export policies:
[edit routing-instances]
user@R1# show
vpn-a {
instance-type vrf;
vrf-import import-vpn-a;
vrf-export export-vpn-a;
protocols {
bgp {
type external;
peer-as 65101;
neighbor 10.0.10.2;
}
}
}
}
VRF Import Policy Example
 Installs routes learned from other PE routers using
MP-BGP
•Routes with the specified community are installed in the
associated VRF table
user@R1# show
...
policy-statement import-vpn-a {
term 1 {
from {
protocol bgp;
community vpn-a;
}
then accept;
}
term 2 {
then reject;
}
}
community vpn-a members target:65512:101;

VRF Export Policy Example
 This policy advertises routes learned through BGP
from the CE router while adding the route target
•Matching routes are sent to MP-BGP peers that have
advertised VPN-IPv4 NLRI capabilities
user@R1# show
...
policy-statement export-vpn-a {
term 1 {
from protocol bgp;
then {
community add vpn-a;
accept;
}
}
term 2 {
then reject;
}
}

Extended BGP Communities
 The target tag specifies the route target

•Policy matches on the route target control which routes are
imported into a given VRF table
user@R1# show
...
 The origin tag allows the specification of site of origin

community
•Site of origin can be used to prevent routing loops when a
user has multiple AS numbers
user@R1# show
...
community SoO members origin:192.168.1.1:101;

PE-CE Policy
 Junos OS import/export policies can be applied to

VRF instances
•BGP and RIP allow both import and export
•OSPF allows export policies and limits import policies that
set priority or filter OSPF external routes
• Reject action is ignored if applied to a non-external route on an
import policy
 Affects routes being sent and received over the
PE-CE link

PE-CE BGP Routing/Policy Example
[edit routing-instances vpn-a protocols]
user@R1# show
bgp {
type external;
import import-cust-a;
peer-as 65101;
neighbor 10.0.10.2;
}
}
user@R1# show
policy-statement import-cust-a {
term 1 {
from protocol bgp;
then {
community add cust-a;
accept;
}
}
}
community cust-a members 65101:1;
AS Override
 Use the as-override option when CE routers
belong to the same AS
•Causes the PE router to overwrite CE’s AS number with the
provider’s AS number (two provider AS numbers in AS path)
 The autonomous-system loops n option can
also be used on the CE router
• advertise-peer-as needs to be configured on the PE
 remove-private can also work if private AS
numbers are in use Provider Core
AS 65512
Site 1 Site 2
OSPF Area 0
AS 65101 AS 65101
R1 R2 R3
Site 1 .2 .1 .1 .2 .2 .1 .1 .2 Site 2
10.0.10.0/24 172.22.210.0/24 172.22.212.0/24 10.0.11.0/24
CE-A PE P PE CE-B
lo0 192.168.11.1 Route-192.168.11.1 Route-192.168.11.1 lo0 192.168.11.2
AS Path 65101 I AS Path 65512 65512 I

CE-PE IBGP: Independent Domain
 Use this setting when CE routers belong to the same
AS and IBGP is used between CE and PE routers
•Causes the PE router to use a new attribute called ATTRSET
to carry customer attributes across provider network
•Customer’s attributes are restored or preserved when
advertised to the remote CE router
•Allows any EBGP peers of the customer to see only the
customer’s attributes, not the provider’s
Provider Core
Site 1 AS 65512 Site 2
AS 65101 OSPF Area 0 AS 65101
R1 R2 R3
.2 .1 .1 .2 .2 .1 .1 .2 Site 2
Site 1
10.0.10.0/24 172.22.210.0/24 172.22.212.0/24 10.0.11.0/24
CE-A PE P PE CE-B
lo0 192.168.11.1 lo0 192.168.11.2
Route-192.168.11.1 Route-192.168.11.1 Route-192.168.11.1
AS Path I (CE path) AS Path I (PE Path) AS Path I (CE Path)
ATTRSET AS I (CE Path) PE router copies attributes contained in ATTRSET
attribute into the IBGP advertisement sent to CE router
Site of Origin
 Use site of origin when CE router is dual-homed and
as-override is required (corner case)
• as-override needed to exchange routes between sites
 Site of origin (and policy) prevents advertising routes
back to the source
•Advertising these routes back to the CE router can cause
forwarding loops with equipment that prefers EBGP over
IGP-learned routes Provider Core Routes advertised with SoO
AS 65512 community 192.168.1.3:1
CE-B
OSPF Area 0 R3
R1 R2 .3
Site 1 .2 .1 .1 .2
AS 65101 .1 .2 PE
10.0.10.0/24 172.22.210.0/24 Site 2
CE-A PE P R4 AS 65101
Provider Loopbacks .4
192.168.1.x
PE
Routes rejected by
R4’s VRF import policy CE-C

PE-CE OSPF Routing
 Requires a separate OSPF process for each VRF table

 Carries OSPF routes across backbone as BGP routes
 Two methods to advertise OSPF routes between
customer sites
•Use of OSPF sham link
•Use of domain ID

PE-CE OSPF Using a Sham Link
 Can be used only when carrying OSPF routes between
CE routers within the same OSPF domain
Provider Network
PE PE
OSPF OSPF
Area 0 Area 0
CE CE
OSPF Sham Link
 Flooding of OSPF LSAs is automatic

•Sham link appears as a point-to-point link between the PEs
• Point-to-point link within customer’s OSPF domain
• Can be assigned a metric
•OSPF packets (hellos, LS updates, and so forth) are
tunneled across MPLS LSPs between PE routers
• vrf-target or vrf-import/export policy still required
OSPF Sham Link Example (1 of 2)
[edit routing-instances vpn-a] lo0.1 added to vrf to be used as router ID
user@R1# show for tunneled OSPF packets
instance-type vrf;
interface lo0.1;
protocols {
ospf {
sham-link local 192.168.11.3;
area 0.0.0.0 {
sham-link-remote 192.168.11.4 metric 1;
interface lo0.1;
}
} Source address of tunneled OSPF packets,
} which must also be advertised using MP-BGP
[edit interfaces lo0]
user@R1# show
...
unit 1 {
family inet {
address 192.168.11.3/32;
}
}
OSPF Sham Link Example (2 of 2)
user@R1> show ospf interface instance vpn-a
ge-1/0/4.0 BDR 0.0.0.0 192.168.11.1 192.168.11.3 1
lo0.1 DR 0.0.0.0 192.168.11.3 0.0.0.0 0
shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
user@R1> show ospf neighbor instance vpn-a

10.0.10.2 ge-1/0/4.0 Full 192.168.11.1 128 34
192.168.11.4 shamlink.0 Full 192.168.11.4 0 33
user@R1> show ospf database instance vpn-a Router LSA for local CE, local PE,
remote PE, and remote CE routers
Router 192.168.11.1 192.168.11.1 0x80000006 2386 0x22 0xf799 48
Router 192.168.11.2 192.168.11.2 0x80000007 59 0x22 0x1279 48
Router *192.168.11.3 192.168.11.3 0x80000006 2376 0x22 0x9a6f 48
Router 192.168.11.4 192.168.11.4 0x80000006 2377 0x22 0x8a7c 48
Network 10.0.10.2 192.168.11.1 0x80000002 450 0x22 0x1ba5 32
Network 10.0.11.2 192.168.11.2 0x80000002 343 0x22 0x229a 32

PE-CE OSPF Using Domain ID
 Can be used when carrying OSPF routes between

OSPF domains or within the same OSPF domain
 Routes can appear in CE router as external LSAs
(Type 5–7) or summary LSAs (Type 3)
•Cannot support stub/totally-stubby areas
•Summary LSA support requires domain ID
 PE router VRF table exports from OSPF, imports
from BGP

Basic OSPF VRF Table Example
user@R1# show
instance-type vrf;
protocols {
ospf {
export export-cust-a;
area 0.0.0.0 {
interface all;
} An export policy is required!
} OSPF does not redistribute BGP routes by default
}
user@R1# show
policy-statement export-cust-a {
term 1 {
from protocol bgp;
then accept;
}
}
...
VRF Policies When Using OSPF
user@R1# show
term 1 {
The protocol match criteria is OSPF
from protocol ospf;
then {
accept;
}
}
term 2 {
then reject;
}
}
term 1 {
from {
protocol bgp;
community vpn-a;
}
then accept;
}
term 2 {
then reject;
...
OSPF Configuration Results
 Routes are advertised to the CE device as:
•AS-external (Type 5)
• When received as AS-external
• When OSPF domain IDs do not match
•Summary LSAs (Type 3)
• When received as Type 1, 2, or 3 LSA and domain IDs match (lack
of domain ID causes implicit match)
user@CE-A> show ospf database

Router 10.0.10.1 10.0.10.1 0x80000004 2294 0x22 0x1d6 36
Router *192.168.11.1 192.168.11.1 0x80000004 2293 0x22 0xfb97 48
Network *10.0.10.2 192.168.11.1 0x80000002 2293 0x22 0x30f2 32
Summary 10.10.10.0 10.0.10.1 0x80000002 1581 0xa2 0x482 28
Summary 10.10.11.0 10.0.10.1 0x80000002 1174 0xa2 0xf88c 28
Summary 192.168.11.2 10.0.10.1 0x80000002 766 0xa2 0x240b 28
Extern 200.200.200.0 10.0.10.1 0x80000002 359 0xa2 0x31d6 36
Extern 201.201.201.0 10.0.10.1 0x80000001 2307 0xa2 0xff6 36
The OSPF Domain ID
 Allows OSPF routes to appear as Type 3 LSAs
•Up/down bit and VPN route tag to prevent looping
 Uses BGP extended communities:
•OSPF route type (Type: 0x0306 or 0x8000)
•OSPF domain ID (Types: 0x0005, 0x0105, 0x0205, and
0x8005)
•OSPF router ID (Type: 0x0107 or 0x8001)
 Helps support backdoor links

OSPF Domain ID Rules
 If the receiving PE router sees a Type 1, 2, or 3 route:

•Domain IDs match, advertised as a Type 3 LSA
•No domain ID on received route and no domain ID on the
local OSPF VRF instance, advertised as a Type 3 LSA
•With nonmatching domain ID, route is advertised as a
Type 5 LSA
 If the receiving PE router sees a Type 5 route, it is
advertised as a Type 5 LSA irrespective of the domain
ID

VRF Example: OSPF with Domain ID
user@R1# show
instance-type vrf;
routing-options {
router-id 192.168.11.3;
}
protocols {
ospf {
domain-id 1.1.1.1;
export export-cust-a;
area 0.0.0.0 {
interface all;
}
}
}

OSPF Domain ID Policy Example
user@R1# show
...
term 1 {
from protocol ospf;
then {
community add domain-a;
accept;
}
}
term 2 {
then reject;
}
}
community domain-a members domain-id:1.1.1.1:0;

Mismatched OSPF Domain IDs
 All remote routes are now presented as external LSAs
•Makes backdoor links problematic
•External routes might be wanted for extranet support
[edit]
user@CE-A> show ospf database

Router *192.168.11.1 192.168.11.1 0x80000004 99 0x22 0xf1a2 48
Router 192.168.11.3 192.168.11.3 0x80000004 100 0x22 0xe330 36
Network 10.0.10.1 192.168.11.3 0x80000002 100 0x22 0x11ae 32
Extern 10.10.10.0 192.168.11.3 0x80000001 114 0xa2 0xd18f 36
Extern 10.10.11.0 192.168.11.3 0x80000001 114 0xa2 0xc699 36
Extern 192.168.11.2 192.168.11.3 0x80000001 114 0xa2 0xf118 36
Extern 200.200.200.0 192.168.11.3 0x80000001 114 0xa2 0x6e38 36
Extern 201.201.201.0 192.168.11.3 0x80000001 114 0xa2 0x4a59 36

OSPF Backdoor Link: Domain ID
Legacy
Link Addressing: Backbone
50/24
10.0.0/24 OSPF Metrics
OSPF Area 0
51 R1 R2 R3 51
OSPF fe-0/0/0 PE PE fe-0/0/0 OSPF

Area 2 21/24 fe-0/0/1 fe-0/0/1 29/24 Area 1
CE-A CE-B
Layer 3 VPN
X 200.0.0.0/24 +Communities 200.0.0.0/24

No Summary VPN Route Summary
LSA! LSA
 Backdoor case study

•CE-A forwards traffic to 200.0.0.0/24 over the legacy
backbone with a metric of 51
• Downing the legacy backbone causes CE-A to use the Layer 3
backbone, now with a metric of 3
•R1 router does not generate a summary LSA for 200.0.0/24
when the legacy backbone is operational
A Vital Clue
 The Junos policy affects only active routes

•Default route preference causes the PE router to choose the
OSPF route received, learned from CE-A
•The route learned from BGP cannot be sent until it becomes
active
vpna.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)

200.0.0.0/24 *[OSPF/10] 00:01:39, metric 52

> to 10.0.21.2 via fe-0/0/0.0
[BGP/170] 00:01:40, MED 2, localpref 100, from 192.168.24.1
AS path: I
> to 10.0.16.2 via fe-0/0/1.0, label-switched-path R3

A Solution
 Change the preferences associated with this routing

instance
•Allows the BGP route to become active, even when receiving
the OSPF route from CE-A
[edit routing-instances vpna]
user@R1# set protocols ospf preference 180
user@R1# commit and-quit
vpna.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)

200.0.0.0/24 *[BGP/170] 00:00:21, MED 2, localpref 100, from 192.168.24.1

AS path: I
> to 10.0.16.2 via fe-0/0/1.0, label-switched-path R3
[OSPF/180] 00:00:20, metric 52
> to 10.0.21.2 via fe-0/0/0.0

Troubleshooting Layer 3 VPNs

Layer 3 VPN Troubleshooting
 Best to take a layered approach
•Core versus PE/CE problems
•Physical layer, data link layer, IGP, BGP, MPLS, VPN
configuration and import/export policy
 routing-instance switch for ping, traceroute,
Telnet, SSH, and FTP
 Routing traffic originated on the PE-CE link for
multiaccess interfaces requires special steps
•Redistribution of direct routes or vrf-target statement
• VRF interface routes are not advertised between PE routers unless
the advertising PE router has a least one other route in the VRF
table that points to its local CE router as the next hop
• vrf-table-label or virtual tunnel interface configuration
permits certain operations, like ARP, at egress PE router
Troubleshooting: A Layered Approach
Provider Core
PE1 P PE2
Site 1 Site 2
CE-A CE-B
Core Problems:
PE-CE Problems: PE-CE Problems:
IGP
IGP/EBGP IGP/EBGP
MPLS (RSVP/LDP)
Policy Policy
IBGP
PE-PE Problems: PE-PE Problems:

VRF-Export VRF-Import
Data Forwarding

Sample Layer 3 VPN Topology
Provider Core
172.20.0-3/24 lo0 192.168.2.1 AS 65512
AS 65201 lo0 192.168.2.2 172.20.4-7/24
OSPF Area 0
AS 65201
PE1 P PE2
.2 ge-1/0/4 .1 .1 ge-1/0/0 .2 .2 ge-1/0/0 .1 .1 ge-1/0/4 .2 Site 2
Site 1
10.0.10.0/24 172.22.220.0/24 172.22.222.0/24 10.0.11.0/24
CE-A CE-B
lo0 192.168.12.1 lo0 192.168.12.2
•192.168.x.y loopback addresses
•RSVP signaling between PE devices, LSPs established between
PE routers (CSPF not required)
•Full MP-IBGP mesh between PE routers, loopback peering,
VPN-IPv4 NLRI
•CE-PE link running EBGP
PE-PE Troubleshooting
 Is the core IGP operational?

 Are the PE-PE BGP sessions established?
•IPv4-VPN family?
 Are the RSVP/LDP LSPs established between PE
routers?
 Do any hidden routes exist?

PE-CE Troubleshooting
 Is the PE-CE routing protocol operational?
•Are the CE routes present in the VRF table?
•Watch for maximum-prefixes prefix limits!
 Do pings between PE routers and CE device work?
 Are the VPN routes being sent to remote PE routers?
 Are the VPN routes being received?
•Lack of received routes in bgp.l3vpn.0 indicates PE
router does not have any matching route targets
•Lack of routes in a particular VRF table indicates problems
with the VPN import policy or misconfigured vrf-target
 Are the VPN routes being sent to the CE device?
 Are routes in place to support traffic originated on
multiaccess VRF interfaces?
The routing-instance Command
user@PE1> ping 10.0.11.2 count 1
PING 10.0.11.2 (10.0.11.2): 56 data bytes
ping: sendto: No route to host

user@PE1> ping 10.0.11.2 routing-instance vpn-a count 1

PING 10.0.11.2 (10.0.11.2): 56 data bytes

 VRF interface is not installed in inet.0

 The routing-instance switch associates the
packet with a particular VRF table
•Intended for local PE-CE communications using Telnet, SSH,
pings, traceroute, and FTP
CE-CE VRF Interface Pings
 Not an issue for point-to-point interfaces

•Redistribution of direct routes or use of vrf-target
statement on PE router works with no issues
 Multiaccess technologies (GE/FE) require special
steps to facilitate advertisement of direct routes
•Exporting direct routes or vrf-target configuration on PE
router
• Requires that the PE router has learned at least one route
(static/dynamic) with the CE device as a next hop
• vrf-table-label or virtual tunnel interface configuration
negates the need for the CE-learned route

Internet Processor Functionality at Egress
PE Router (1 of 2)
 vrf-table-label option in VRF table configuration
•Uses LSP sub-interface (LSI) abstract
• Creates an LSI that maps to each VRF table
• Supported core-facing interfaces map reserved MPLS labels to each
VRF LSI
• Allows I/O Manager to strip VRF label and map packets to correct VRF
table, which allows the Internet Processor to perform key lookup on IP
packets
 Caveats:
•Only certain core-facing interface types supported
• Consult the documentation for your software version
•Not supported for MP-BGP-labeled routes (carrier of
carriers/interprovider)
•Operational display changes
Internet Processor Functionality
at Egress PE Router (2 of 2)
 A router equipped with tunnel service capability allows
for the configuration of a VPN tunnel interface
•Causes two Internet Processor lookups on the Egress PE
routers
• The first lookup is to determine to which VRF table the
MPLS-encapsulated packet belongs
• Rather than forwarding the packet directly out the physical VRF
interface, the resulting IP packet from the first lookup is sent to the
tunnel service interface (next hop equals the vt-x/y/z interface)
• The second lookup occurs when the packet returns from the tunnel
services interface and then that the Internet Processor functionality
is allowed (ARP, firewall filters, and so forth)
[edit interfaces vt-1/0/10] user@PE1# show
user@PE2# show instance-type vrf;
unit 0 { interface ge-1/0/4.0;
family inet; interface vt-1/0/10.0;
family mpls; vrf-target target:65412:100;
} . . .

PE-PE Ping and Traceroute
 Not really necessary as local PE-CE pings can be used
at both ends
•Remember multiaccess requirements to redistribute direct
• Otherwise traffic cannot be sourced from the PE-CE subnet
PING 10.0.11.1 (10.0.11.1): 56 data bytes

user@PE1> traceroute 10.0.11.1 routing-instance vpn-a

1 10.0.11.2 (10.0.11.2) 0.541 ms 0.393 ms 0.375 ms
2 10.0.11.1 (10.0.11.1) 0.476 ms 0.448 ms 0.438 ms

Traffic Path for PE-PE Pings
Provider Core
172.20.0-3/24 lo0 192.168.2.1 AS 65512
AS 65201 lo0 192.168.2.2 172.20.4-7/24
OSPF Area 0
AS 65201
PE1 P PE2
.2 .1 .1 .2 .2 .1 .1 .2 Site 2
Site 1
10.0.10.0/24 172.22.220.0/24 172.22.222.0/24 10.0.11.0/24
CE-A CE-B
lo0 192.168.12.1 lo0 192.168.12.2
Echo Request (10.0.10.1 10.0.11.1)
Echo Reply (10.0.11.1 10.0.10.1

 Filtering and ARP processing not available at egress
PE router
PING 10.0.11.1 (10.0.11.1): 56 data bytes


PE-PE MPLS Ping
 Allows administrator to test PE-to-PE L3 VPN

connectivity
user@PE1> ping mpls l3vpn vpn-a prefix 172.20.4/24

!!!!!
user@PE1> ping mpls l3vpn vpn-a prefix 172.20.3.1

vpn-a - This prefix was not learnt from a remote site, exiting.

PE Traceroute: PE to Remote CE Link
 Traffic is automatically sourced from the VRF

interface, which allows remote CE device to respond
user@PE1> traceroute 192.168.12.2 routing-instance vpn-a
traceroute to 192.168.12.2 (192.168.12.2), 30 hops max, 40 byte
packets
1 * * *
2 172.22.222.1 (172.22.222.1) 0.641 ms 0.455 ms 0.432 ms
3 192.168.12.2 (192.168.12.2) 0.451 ms 0.438 ms 0.436 ms

CE-CE-Based Traceroutes (1 of 2)
 Core router hops are hidden (original FPCs) because
the outer label's TTL is set to 255
user@CE-a> traceroute 192.168.12.2
1 10.0.10.1 (10.0.10.1) 0.444 ms 0.352 ms 0.341 ms
2 172.22.222.1 (172.22.222.1) 0.641 ms 0.455 ms 0.432 ms
3 192.168.12.2 (192.168.12.2) 0.451 ms 0.438 ms 0.436 ms
 Core router hops show up as traceroute timeouts

because the outer label’s TTL copied from the inner
label (Enhanced FPC)
lab@CE-a> traceroute 192.168.12.2
1 10.0.10.1 (10.0.10.1) 0.428 ms 0.297 ms 0.278 ms
2 * * *
3 172.22.222.1 (172.22.222.1) 0.588 ms 0.437 ms 0.424 ms
4 192.168.12.2 (192.168.12.2) 0.434 ms 0.428 ms 0.421 ms

CE-CE-Based Traceroutes (2 of 2)
 To avoid confusion, enable icmp-tunneling on PE
and P routers:
lab@p1# set icmp-tunneling
 ICMP time exceeded messages destined for the

traceroute source (CE-A) are forwarded to remote PE
router using the original two-level MPLS label stack
•Inner label maps to correct VRF table, so remote PE router
can route the P routers’ expiration messages back to CE-A
lab@CE-a> traceroute 10.0.11.2
1 10.0.10.1 (10.0.10.1) 0.872 ms 0.627 ms 0.567 ms
2 172.22.220.2 (172.22.220.2) 1.078 ms 1.020 ms 0.986 ms
3 172.22.222.1 (172.22.222.1) 1.076 ms 1.008 ms 0.975 ms
4 10.0.11.2 (10.0.11.2) 0.968 ms 0.888 ms 0.851 ms

Examining Routes in a VRF Table
 Junos OS allows the viewing of a VRF table with the show
route table vpn-name command
•VRF tables contain:
• The matching routes learned from remote PE routers
• Routes learned over the PE-CE link or static routing entries
 The bgp.l3vpn.0 table contains all routes learned from
other PE routers with at least one matching route target
•Functions as a RIB-In for VPN routes
•Discards NLRI updates that do not match at least one VRF table
• keep all is useful for troubleshooting route target-related
problems—use only for troubleshooting!
 The show route protocol bgp command displays
all BGP routes in all RIBs
•Output can be filtered by providing a prefix/mask or by piping to
match or find
Viewing the Route Table Example (1 of 2)
user@PE1> show route table vpn-a
vpn-a.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

10.0.10.0/24 *[Direct/0] 02:28:18

> via ge-1/0/4.0
10.0.10.1/32 *[Local/0] 02:28:18
Local via ge-1/0/4.0
10.0.11.0/24 *[BGP/170] 00:00:08, localpref 100, from 192.168.2.2
AS path: I
> to 172.22.220.2 via ge-1/0/0.220, label-switched-path lsp1
172.20.0.0/24 *[BGP/170] 01:11:32, localpref 100
AS path: 65201 I
> to 10.0.10.2 via ge-1/0/4.0
172.20.1.0/24 *[BGP/170] 01:11:32, localpref 100
AS path: 65201 I
> to 10.0.10.2 via ge-1/0/4.0
…

Viewing the Route Table Example (2 of 2)
user@PE1> show route table vpn-a 172.20.4.0 detail

172.20.4.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 192.168.2.2:6
Next hop type: Indirect
Source: 192.168.2.2
Next hop: 172.22.220.2 via ge-1/0/0.220 weight 0x1, selected
Label-switched-path lsp1
Label operation: Push 299824, Push 301488(top)
Protocol next hop: 192.168.2.2
Push 299824
Indirect next hop: 2790000 1048577
State: <Secondary Active Int Ext>
Local AS: 65512 Peer AS: 65512
Age: 4 Metric2: 4
AS path: 65201 I
Communities: target:65512:100
Import Accepted
VPN Label: 299824
Localpref: 100
Router ID: 192.168.2.2
Primary Routing Table bgp.l3vpn.0
Viewing the bgp.l3vpn.0 RIB
 Displays all Layer 3 VPN NLRI with at least one
matching route target
• keep all useful for troubleshooting
• Enabled by default on route reflectors
• Must be explicitly set on confederation C-EBGP speakers
user@PE1> show route table bgp.l3vpn
bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
192.168.2.2:6:10.0.11.0/24
*[BGP/170] 01:11:36, localpref 100, from 192.168.2.2
AS path: I
192.168.2.2:6:172.20.4.0/24
AS path: 65201 I
192.168.2.2:6:172.20.5.0/24
AS path: 65201 I

Viewing Routes Sent to Other PE Routers
 Use the show route advertising-protocol
bgp peer-address command
user@PE1> show route advertising-protocol bgp 192.168.2.2 172.20/16 detail

* 172.20.0.0/24 (1 entry, 1 announced)
BGP group my-int-group type Internal
VPN Label: 299808
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65512] 65201 I

Viewing Routes Received from Other
PE Routers
 Use the show route receive-protocol bgp
peer-address command
user@PE1> show route receive-protocol bgp 192.168.2.2

…
Prefix Nexthop MED Lclpref AS path
* 10.0.11.0/24 192.168.2.2 100 I
* 172.20.4.0/24 192.168.2.2 100 65201 I
* 172.20.5.0/24 192.168.2.2 100 65201 I
* 172.20.6.0/24 192.168.2.2 100 65201 I
* 172.20.7.0/24 192.168.2.2 100 65201 I
* 192.168.12.2/32 192.168.2.2 100 65201 I

192.168.2.2:6:10.0.11.0/24
* 192.168.2.2 100 I
192.168.2.2:6:172.20.4.0/24
* 192.168.2.2 100 65201 I
192.168.2.2:6:172.20.5.0/24
* 192.168.2.2 100 65201 I
Viewing a VPN Forwarding Table
 Use the show route forwarding-table vpn
vpn-name command
user@PE1> show route forwarding-table vpn vpn-a
Routing table: vpn-a.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 582 1
0.0.0.0/32 perm 0 dscd 580 1
10.0.10.0/24 intf 0 rslv 613 1 ge-1/0/4.0
10.0.10.0/32 dest 0 10.0.10.0 recv 611 1 ge-1/0/4.0
10.0.10.1/32 intf 0 10.0.10.1 locl 612 2
10.0.10.1/32 dest 0 10.0.10.1 locl 612 2
10.0.10.2/32 dest 1 80:71:1f:… ucst 614 8 ge-1/0/4.0
10.0.10.255/32 dest 0 10.0.10.255 bcst 610 1 ge-1/0/4.0
10.0.11.0/24 user 0 indr 1048576 7
172.22.220.2 Push 299824, Push 301504(top) 623 2 ge-1/0/0.220
172.20.0.0/24 user 0 10.0.10.2 ucst 614 8 ge-1/0/4.0
172.20.1.0/24 user 0 10.0.10.2 ucst 614 8 ge-1/0/4.0
172.20.2.0/24 user 0 10.0.10.2 ucst 614 8 ge-1/0/4.0
172.20.3.0/24 user 0 10.0.10.2 ucst 614 8 ge-1/0/4.0
172.20.4.0/24 user 0 indr 1048576 7
172.22.220.2 Push 299824, Push 301504(top) 623 2 ge-1/0/0.220
172.20.5.0/24 user 0 indr 1048576 7
172.22.220.2 Push 299824, Push 301504(top) 623 2 ge-1/0/0.220
. . .

Clearing VRF ARP Entries
 Use the clear arp vpn vpn-name command

user@PE1> show arp
MAC Address Address Name Interface Flags
80:71:1f:c3:07:64 10.0.10.1 10.0.10.1 ge-1/1/4.0 none
80:71:1f:c3:07:7c 10.0.10.2 10.0.10.2 ge-1/0/4.0 none
50:c5:8d:87:8b:3a 172.22.220.2 172.22.220.2 ge-1/0/0.220 none
Total entries: 3
user@PE1> clear arp

172.22.220.2 deleted
user@PE1> clear arp vpn vpn-a

10.0.10.1 deleted
10.0.10.2 deleted
 The show arp command displays both inet.0 and

VRF ARP entries
Monitoring PE-CE BGP Operation
 Use the standard BGP CLI operational-mode

commands:
• show bgp neighbor ce
• show bgp summary
• show route advertising-protocol bgp ce
• show route receiving-protocol bgp ce
• show route protocol bgp source-gateway ce
 Standard Junos OS tracing options available for PE-CE
routing instance

Monitoring PE-CE OSPF Operation
 Use the instance switch when issuing OSPF operational
commands
 Tracing operations can be performed on OSPF instances
user@PE1> show ospf interface instance vpn-a
ge-1/0/4.0 BDR 0.0.0.0 192.168.12.1 10.0.10.1 1
user@PE1> show ospf neighbor instance vpn-a

10.0.10.2 ge-1/0/4.0 Full 192.168.12.1 128 38
user@PE1> show ospf database instance vpn-a

Router *10.0.10.1 10.0.10.1 0x80000005 56 0x22 0xfed7 36
Router 192.168.12.1 192.168.12.1 0x80000004 57 0x22 0x589 48
Network 10.0.10.2 192.168.12.1 0x80000002 437 0x22 0x32ee 32
Extern *10.0.11.0 10.0.10.1 0x80000001 56 0xa2 0x73da 36
Extern 172.20.0.0 192.168.12.1 0x80000001 482 0x22 0xe496 36
Extern 172.20.1.0 192.168.12.1 0x80000001 482 0x22 0xd9a0 36
…
Layer 3 VPN Scaling
and Internet Access

How to Make It Scale
 Recommendations from RFC 4364

•Observe PE router limits regarding total number of routes
•Keep the CE-to-PE routing simple
•Create multiple BGP route reflectors for VPN routes
•Use BGP-RFRSH (refresh)
• RFC 2918
•Use route target filtering
• RFC 4684

Scalability: Divide and Conquer
 Two levels of labels allow P routers to forward VPN

traffic without needing to learn VPN routes
 PE router maintains routes only for VPNs with sites
directly connected to the PE router
 If necessary, partition BGP route reflectors among
VPNs served by the provider
•No single component within the system is required to
maintain routes for all VPNs
•Capacity of the system is not bound by the capacity of an
individual component

Scalability: VPN-Specific Route Reflectors
VPN RR VPN RR
for 1-99 for 100-199
 Use VPN route reflectors
to handle VPN-specific P P
routes VPN 1
PE-2
VPN50
•Add additional VPN route VPN150 PE-1
P P
reflectors for VPNs as PE-3
needed
•PE routers peer with as P P
many route reflectors as needed

 Route reflectors do not need to be PE routers—
normally they are P routers
•Not in the forwarding plane—do not require VRF tables
•Must support family inet-vpn
•Must have LSPs to each PE to resolve advertised next hop
•Keep all routes in bgp.l3vpn.0
Layer 3 VPN Route Reflection
 Route reflector does not need VRF tables configured—
must support family inet-vpn and BGP refresh
 Activating routes requires LSPs from route reflector to
PE routers
 PE routers filter received routes based on route
targets
Route Reflector
PE-1 PE-3
Route Reflector LSP

Unidirectional LSP
MP-BGP Peering
PE-2

Scalability: BGP Refresh
Can you send me RR-VPN1
 BGP is a stateful protocol the routes again?
CE-A
•Once peers are synchronized, RR-VPN2
they do not exchange routes PE-1
again until a change occurs New site added
or the session is disrupted to PE-1
 PE router has filtered route exchange with route

reflector VPN to limit the number of routes it must
maintain
 PE router adds/deletes a VPN, which requires the
updating of BGP routing table
 BGP route refresh allows PE router to obtain routes
for new VPNs in a non-disruptive fashion (without
terminating BGP session with route reflectors or
remote PE routers)
Scalability: BGP Route Target Filtering
Here are all the
 Without BGP route target filtering: routes I know.
•PE router receives an update, CE-A RR-VPN1
consisting of every route RR-VPN2

PE-1
RR-VPN knows, from RR-VPN Here are all the
routes I know.
•PE router applies route filter based
on route targets and drops routes that are not appropriate
 With BGP route target filtering: Here are the routes
with your targets
•PE router sends a list of route Only send me routes
with these targets.
RR-VPN1
targets that it is interested CE-A
in to RR-VPN RR-VPN2
PE-1
•RR-VPN applies route filter and Here are the routes
only sends appropriate routes to the PE router with your targets

Route Target Options
 MP-BGP route-target address family
(AFI=1, SAFI=132)
Maximum number of family route target
advertisements allowed from peer
[edit]
user@PE-1# show protocols bgp
family route-target { If maximum is reached, BGP neighbor
prefix-limit { relationship is terminated for specified
maximum <1..4294967295>; number of seconds
teardown <1..100> idle-timeout <1..2400>;
}
external-paths X; At % of maximum, syslog message is generated
advertise-default;
} This setting is used for interprovider
VPNs Option B. Allows for multiple EBGP
Usually configured on route reflector only peers to receive VPN routes (default = 1)

Route Target Filtering (1 of 5)
RR-1
192.168.1.3
VPN-A VPN-B
CE-A PE-1 PE-2 CE-B
192.168.1.1 192.168.1.2
AS 65512
user@RR-1> show configuration protocols bgp

group pe {
type internal;
family inet-vpn {
unicast;
}
family route-target; family route-target (AFI=1,
cluster 1.1.1.1; SAFI=132) capabilities are negotiated
neighbor 192.168.1.1; with the PE routers
neighbor 192.168.1.2;
}
RR-1
192.168.1.3
VPN-A VPN-B
CE-A PE-1 PE-2 CE-B
192.168.1.1 192.168.1.2
AS 65512
user@RR-1> show bgp summary

Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.l3vpn.0 8 8 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#
192.168.1.1 65512 6 8 0 0 1:18 Establ
bgp.l3vpn.0: 2/2/0
bgp.rtarget.0: 1/1/0
192.168.1.2 65512 7 6 0 0 1:04 Establ
bgp.l3vpn.0: 6/6/0
bgp.rtarget.0: 1/1/0 PE-1 and PE-2 automatically advertise a route
target for each VPN in which they participate

AS#:target:# AS#:target:#
65512:65512:100 RR-1 65512:65512:200
192.168.1.3
VPN-A VPN-B
CE-A PE-1 PE-2 CE-B
192.168.1.1 192.168.1.2
AS 65512
target:65512:100 target:65512:200
user@RR-1> show route receive-protocol bgp 192.168.1.1 detail table bgp.rtarget.0
bgp.rtarget.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

* 65512:65512:100/96 (1 entry, 1 announced)
Nexthop: 192.168.1.1
Localpref: 100
AS path: I
user@RR-1> show route receive-protocol bgp 192.168.1.2 detail table bgp.rtarget.0

* 65512:65512:200/96 (1 entry, 1 announced)
Nexthop: 192.168.1.2
Localpref: 100
AS path: I

RR-1 reflects route
AS#:target:# target to all clients.
BGP NH = RR-1
65512:65512:100 RR-1 Originator ID = RR-1
192.168.1.3
VPN-A VPN-B
CE-A PE-1 PE-2 CE-B
192.168.1.1 192.168.1.2
AS 65512
target:65512:100 target:65512:200
user@PE-1> show route table bgp.rtarget.0

65512:65512:100/96
*[RTarget/5] 00:11:19
Local
[BGP/170] 00:03:31, localpref 100, from 192.168.1.3
AS path: I
> to 172.22.210.2 via ge-1/0/0.210
65512:65512:200/96
AS path: I
> to 172.22.210.2 via ge-1/0/0.210
VPN-B routes tagged with:
target:65512:200
RR-1
192.168.1.3
VPN-A VPN-B
CE-A PE-1 PE-2 CE-B
192.168.1.1 192.168.1.2
AS 65512
target:65512:100 target:65512:200
user@PE-1> show configuration protocols bgp

keep all;
family inet-vpn { Causes PE-1 to place all received Layer 3 VPN routes into
bgp.l3vpn.0 table, regardless of configured vrf-targets
unicast;
}
family route-target; RR-1 does not send VPN-B’s Layer 3 VPN
routes to PE-1
. . .
user@PE-1> show route table bgp.l3vpn.0

Adding Traffic Engineering
3) Enters RSVP- engineered

core and pushes RSVP label 4) Pops RSVP label
2) Finds inet.3 route to the BGP 5) Pops LDP label

next hop and assigns LDP label
1) Finds BGP next hop to Y 6) Pops VPN label and forwards

and assigns VPN label packet out the CE port
Source X
Destination Y Y
PE-1 P1 P2 P3 PE-2
Packet Labels:
Outer Label: RSVP
LDP-Signaled LSP Middle Label: LDP
RSVP-Signaled LSP Inner Label: VPN

LDP Tunneling Configuration Example
[edit]
user@P1# show protocols mpls
label-switched-path P1-to-P3 {
to 192.168.5.3;
ldp-tunneling;
no-cspf;
}
interface all;
[edit]
user@P1# show protocols ldp
interface lo0.0;

VRF Table Adds, Moves, and Changes
 When a VPN/VRF table is added to or removed from a

PE router, is it disruptive?
•No
 How many router configurations must be changed
when you add or remove VPN/VRF tables?
•Only the affected PE router must be configured—in this case,
to peer with the route reflector responsible for the new VPN
•When a VPN is completely removed from the PE router,
it simply withdraws all those VPN-IPv4 routes
•Route target filtering and route refresh simplify this process

Layer 3 VPN Scaling Guidelines
 Number of VRF tables
•Might be up to 9000 depending on the Routing Engine
 Number of total routes per device can vary a great
deal depending on platform and hardware
•MX-960 can handle up to 1.5 million routes
• Can reach up to 2.4 million routes with some Trio DPCs
•Option to limit prefixes received from CE router
• maximum-routes route limit [log-only | {
threshold <1-100> }]
 Additional factors
•Does the PE router carry Internet routes?
•Are the CE routing protocols stable?
•Is the PE router performing value-added services, such as
rate limiting and firewall?
Accessing the Public Internet Public Internet
 If the VPN uses private

addresses, connecting Customer site
VPN
to Internet requires NAT

•CE or service provider can perform NAT function
 RFC 4364 Internet access options
•Option 1: PE router does not participate in Internet routing
•Option 2: PE router performs redistribution between VRF
tables and main instance while matching packets against
both tables
•Option 3: Central CE device sends Internet/default routes to
remote sites

Accessing the Public Internet: Option 1.1
 Option 1.1: VPN service provider plays no role in

Internet connectivity
•VPN customer has separate connection to Internet from
some or all of its sites
Public Internet
Customer
Site 1 Provider VPN
Customer
Site 3
PE-1 P1 P2 P3 PE-2
Customer
Site 2

Internet Internet aware router
Internet traffic
Customer Customer
Site 1 Site 2
PE-1 P1 P2 P3 PE-2
VPN Provider VPN traffic
 Option 1.2: PE router provides Layer 2 connectivity to

a router that maintains some or all Internet routes
•Service provider provides both BGP/MPLS VPNs and Layer 2
MPLS VPNs
•VPN connection assumes a separate logical (but not
necessarily physical) link between CE device and PE router
(for example, DLCI, VLAN, and GRE)
•Layer 2 VPN has connectivity to an Internet-aware router
• Different VPNs can use different Internet-aware routers
Internet
Internet traffic
Customer Customer
Site 1 Site 2
PE-1 P1 P2 P3 PE-2
VPN traffic VPN Provider
 Option 2.1: Main routing table contains Internet

routes and is consulted for packets received over
non-VRF interfaces
•Forces homogeneous Internet route selection for all VPNs
connected to the PE router
•Requires a separate logical link between CE device and PE
router for carrying traffic to and from the Internet

Internet
Return Internet traffic

Outbound Internet traffic
Customer Customer
Site 1 Site 2
PE-1 P1 P2 P3 PE-2
VPN Provider
VPN/Internet traffic VPN traffic
 Option 2.2:
•Some or all Internet routes maintained in VRF table on PE
• Routes matching non-VPN addresses are directed to the main
routing table for lookup using the next-table operation
•Requires a separate logical link between CE and PE router
for carrying return traffic from the Internet (which presents
scaling problems if VRF tables maintain a full set of routes)
• PE probably maintains a 0/0 plus a small number of other Internet
routes per VRF table with this option
Internet
Internet traffic
Customer Customer
Site 1 Site 2
PE-1 P1 P2 P3 PE-2
VPN Provider
VPN/Internet traffic VPN traffic
 Option 2.3:
•Single interface for VPN and Internet access
•Requires that:
• Either VPN has no private addresses or that it uses BGP with
community tagging
• VRF routes be copied into inet.0 using RIB groups
• Non-VPN routes be matched against the main routing table using
the next-table operation
Accessing the Public Internet: Option 3.x
Internet
All Internet traffic

VPN Provider
Customer Customer
Site 1 Site 2
PE-1 P1 P2 P3 PE-2
0/0 Default route
VPN/Internet traffic
 Option 3.x:
•Central CE device sends Internet/default routes to remote
sites
•Remote sites access both VPN and Internet using their
single VRF interface
•Central CE device turns Internet packets around and sends
them to PE router over a non-VRF interface
Internet Access Support
 Summary:
•Internet access through a non-VRF interface (PE router has
no Internet routes)
• Options 1.1 and 1.2
•Internet access through a VRF interface (PE router has some
or all Internet routes)
• Options 2.1, 2.2, and 2.3
• Uses a default route in VRF table that points to next-table inet.0
• Routes in inet.0 cannot point back to a VRF table
• RIB groups are required to install VPN routes into inet.0 so that
return traffic can be routed correctly to CE device
• Can use a single PE-CE VRF interface
•Central CE device providing Internet access (Option 3.x)
•In all cases, the CE device must use globally assigned IP
addresses for Internet traffic
Layer 3 VPNs—
Advanced Topics

Sharing Routes Between VRF Tables
in the Same PE Router
PE
VRF-A VRF-B
VPN-A/B VPN-B/A
Routes Routes
CE-A CE-B
VPN-A VPN-B
 Goal: Allow communications between CE-A and CE-B

without placing them into the same VPN
 Solution: Use the auto-export command or RIB
groups
auto-export Example
 auto-export command configured in multiple VRF

tables causes router to analyze vrf-import/export
policies or vrf-target statements in those VRF tables
•VPN routes are copied into appropriate local VRF tables
[edit routing-instances] 10.0.21/24
user@PE# show
vpn-a { vpn-b { CE .2 .1 PE
instance-type vrf; instance-type vrf; A 1 ge-0/0/0
lo0: 192.168.16.1
vrf-target target:65412:100; vrf-target target:65412:100; .1
routing-options { routing-options {
auto-export; auto-export; 10.0.50/24
} }
protocols { .2
protocols {
bgp {
CE
bgp { B
group ce-a { group ce-b {
peer-as 65000; peer-as 65000;
as-override; as-override;
neighbor 10.0.21.2; neighbor 10.0.50.2
. . . . . .

VRF RIB Group Example
routing-options {
rib-groups {
a-to-b {
import-rib [ vpn-a.inet.0 vpn-b.inet.0 ];
}
b-to-a {
import-rib [ vpn-b.inet.0 vpn-a.inet.0 ]; 10.0.21/24
}
} CE .2 .1 PE
autonomous-system 65412; A 1 ge-0/0/0
} lo0: 192.168.16.1
routing-instances { .1
vpn-a {
. . .
routing-options { 10.0.50/24
interface-routes {
.2
rib-group inet a-to-b; CE
} B
}
protocols {
bgp {
group ext {
type external;
family inet {
unicast {
rib-group a-to-b;
}
}
. . .

Verifying the Results
user@PE# run show route table vpn-b
vpn-b.inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

10.0.21.0/24 *[Direct/0] 03:21:27

> via ge-0/0/0.0
[BGP/170] 03:21:27, localpref 100 VRF routes
AS path: 65001 I (local and BGP) from
> to 10.0.21.2 via ge-0/0/0.0 VPN-A are now in
10.0.21.1/32 *[Local/0] 03:21:27 VPN-B’s VRF table
Local
10.0.50.0/24 *[Direct/0] 00:16:48
> via ge-0/0/3.0
10.0.50.1/32 *[Local/0] 00:16:48
Local
. . . .
 VPN-A’s interface and BGP routes are in VPN-B’s VRF

table (although not shown, VPN-B’s interface/BGP
routes are also present in VPN-A’s VRF table)
 Traffic can now be forwarded between sites served by
CE-A and CE-B
Keeping Shared VRF Routes from Other
PE and CE Routers
[edit policy-options policy-statement vpnb-export]
user@PE# show
term 1 {
from {
protocol bgp;
}
then {
community add vpnb-target;
accept;
}
}
term 2 {
then reject;
}
 VRF export policy for vpn-b matches the routes
learned from interface ge-0/0/3
•Routes copied from the vpn-a VRF table are not sent to
remote PE routers

Hub-and-Spoke Topologies
 Reduces the number of BGP sessions and LSPs
required, but the cost is an extra CE router hop
•Spoke-to-spoke communications must transit hub site
 Requires two VRF instances in the hub PE router
•Spoke VRF table contains routes received from spoke sites
•Hub VRF table contains routes received from the hub CE device
 Requires two VRF interfaces at the hub CE/PE link
•Can be logical units on the same interface
 Requires two route targets and possibly two route
distinguishers when supporting route reflectors
 Watch for AS path loop detection and OSPF domain ID
problems
 Issues might arise when hub PE router has locally
connected spokes, or when multiple spoke sites attach
to the same spoke PE router
Signaling Flow Between Spokes
Hub
CE
ge-0/0/0.0 4 ge-0/0/0.1
3
Spoke Hub PE Hub
VRF VRF
Target: Target:
Spoke Hub
2 5
Spoke Spoke Spoke Spoke

CE-1 PE-1 PE-2 CE-2
1 6

Data Flow Between Spokes
Hub
CE
4 3
ge-0/0/0.0 ge-0/0/0.1
Spoke Hub PE Hub

VRF VRF
5 2
Spoke Spoke Spoke Spoke

CE-1 PE-1 PE-2 1 CE-2
6

Sample Spoke Configuration (1 of 3)
 A single routing instance is defined in the spoke sites:

routing-instances {
vpna {
instance-type vrf;
vrf-import vpna-import;
vrf-export vpna-export;
protocols {
bgp {
group ext {
type external;
peer-as 65001;
as-override;
neighbor 10.0.21.2;
}
}
}
}
}

 A spoke site’s VRF import policy that accepts route

tagged as coming from the hub route target:
policy-options {
policy-statement vpna-import {
term 1 {
from {
protocol bgp;
community hub;
}
then accept;
}
term 2 {
then reject;
}
}
community origin-pe1 members origin:192.168.16.1:1;
community hub members target:65412:100;
community spoke members target:65412:101;
}
 A spoke site’s export policy and community
definitions:
policy-statement vpna-export {
term 1 {
from protocol [bgp static direct ];
then {
community add origin-pe1;
community add spoke;
accept;
}
}
term 3 {
then reject;
}
}
community origin-pe1 members origin:192.168.16.1:1;
}
Sample Hub Configuration (1 of 4)
 Multiple interfaces (logical or physical) needed at the

hub location:
interfaces {
ge-0/0/0 {
vlan-tagging;
unit 0 {
vlan-id 100;
family inet {
address 10.0.29.1/24;
}
}
unit 1 {
vlan-id 200;
family inet {
address 10.0.30.1/24;
}
}
}

 The hub instance exports routes learned from the hub

CE device to the remote spokes:
routing-instances {
hub {
instance-type vrf;
vrf-import null;
vrf-export hub-out;
protocols {
bgp {
group ext1 {
type external;
peer-as 65001;
neighbor 10.0.30.2;
}
}
}
}

 The spoke instance imports routes from the remote
spokes and sends them to the hub CE device:
routing-instances {
. . .
spoke {
instance-type vrf;
vrf-import spoke-in;
vrf-export null;
protocols {
bgp {
group ext {
type external;
peer-as 65001;
as-override;
neighbor 10.0.29.2;
}
}

 Sample hub policy (two route targets are used):

policy-options {
policy-statement spoke-in {
from {
protocol bgp;
community spoke;
}
then accept;
}
policy-statement hub-out {
from protocol bgp;
then {
community add hub;
accept;
}
}
policy-statement null {
then reject;
}
}

Hub-and-Spoke Troubleshooting
 Most problems relate to signaling

•Verify the signaling exchange by confirming the presence of
a spoke route at each stage
•Start with an examination of the hub PE router’s spoke
instance to save time
•Suspect route target mismatches
•Suspect AS loop detection when using EBGP at the hub site
 Perform a traceroute from spokes to hub before trying
spoke-to-spoke traceroutes

VPNs and CoS
 Filtering and CoS mapping functions available at
ingress PE router
•Firewall filtering, classification, rate limiting, precedence
mapping
 Filtering functions might be unavailable at egress PE
router
•Support of vrf-table-label and vt-interface
allows filtering functions at egress router
 VRF label EXP bits can be set based on FW filters,
ingress interface, or IP precedence bits
 Outer label (RSVP) can be set statically with
class-of-service configuration option
•Enhanced FPC can write both labels independently
 classifiers exp option is available on transit
and egress PE router
•Accommodates WRR and RED functions for labeled packets
VPNs CoS Configuration Example
user@R1# show interfaces ge-1/0/0
unit 0 {
family inet {
filter {
input test;
}
address 10.0.6.1/24;
. . .
user@R1# show firewall family inet
filter test {
term 1 {
from {
protocol icmp;
}
then forwarding-class assured-forwarding;
}
term 2 {
then accept;
}
. . .
user@R1# show protocols mpls label-switched-path am
to 192.168.24.1;
class-of-service 4;

VPNs CoS Example: The Result
Frame 12 (106 on wire, 106 captured)
Ethernet II
MultiProtocol Label Switching Header
MPLS Label: Unknown (100003)
MPLS Experimental Bits: 4 Top Label
MPLS Bottom Of Label Stack: 0
MPLS TTL: 254
MultiProtocol Label Switching Header
MPLS Label: Unknown (100001)
MPLS Experimental Bits: 4 Bottom Label
MPLS Bottom Of Label Stack: 1
MPLS TTL: 254
Internet Protocol
Version: 4
Header length: 20 bytes
. . . .
 The top (RSVP) label is set using the class-of-
service command under LSP definition
 The bottom (VRF) label is set based on firewall
classification at ingress PE router
VPN Load Balancing/Prefix Mapping
 Can balance VPN traffic over equal-cost LSPs

•Export policy applied to main routing instance forwarding
table
 Can map VPN traffic to specific LSPs when equal-cost
LSPs exist
•Policy used at ingress or egress nodes
• Tag VPN routes with communities at LSP egress, match these
communities at LSP ingress node
• Manipulate BGP next hop at LSP egress, map LSPs to the correct
BGP next hop at LSP ingress

VPN Prefix Mapping: Policy Example (1 of 2)
user@R1# show policy-options policy-statement map
term 1 {
from {
community gold; Communities tagged at remote PE router
}
then {
install-nexthop lsp am;
accept;
}
}
term 2 {
from {
community silver;
}
then {
install-nexthop lsp am2;
accept;
}
}
term 3 {
then accept;
}

VPN Prefix Mapping: Policy Example (2 of 2)
 map policy is applied to main routing instance:
user@R1# show routing-options
autonomous-system 65412;
forwarding-table {
export map;
}
 And the results...

user@R1> show route forwarding-table vpn vpnb
Routing table:: vpnb.inet
Internet:
Destination Type RtRef Nexthop Type Index NhRef Netif
172.16.4.0/24 user 0 10.0.16.2 Push 100001, Push 100032(top)[4] ge-0/0/1.0
. . .

PE-PE GRE Tunnels
Customer Customer
Site 1 Service Site 2
Provider
192.168.8.1 192.168.28.
1
R R R
PE-1 P CE-1 CE-2 P PE-2
GRE Tunnel Between

PE Routers
 The Junos OS supports PE-to-PE GRE tunnels

•Allows carrier-of-carriers VPN applications when provider’s
network does not support MPLS
•Requires tunnel services on customer PE routers
•Does not use MPLS forwarding

PE-PE GRE Tunnel Configuration
 Unnumbered GRE tunnel with family mpls
user@pe1# show interfaces gr-1/0/10
unit 0 {
tunnel {
source 192.168.8.1;
destination 192.168.28.1;
}
family inet;
family mpls;
}
user@pe1# show routing-options
rib inet.3 {
static {
route 192.168.28.1/32 next-hop gr-1/0/10.0;
}
}

PE-CE GRE Tunnels
IP CE
Provider Core PE Network B
OSPF Area 0 2 lo0: 192.168.24.1
ge-0/0/1
1 2 192.168.9.98 192.168.9.97
2
P1 P2 1 24/24
16/24 1/24
AS 65412 GRE Tunnel
Private Addresses
 The Junos OS supports PE-to-CE GRE tunnels

•Allows connection to remote CE devices across an IP
backbone
• routing-instance configuration option to associate
GRE tunnel with correct routing instance

IPsec and Layer 3 VPN Integration
172.20.4/24
ge-0/0/0.0 IP ge-0/0/0.0
CE
Provider Core 2 PE-2 Network B
lo0: 192.168.24.1 200.0.1.1 200.0.0.1
P-n ge-0/0/1
172.20.0/24
ge-0/0/0 ge-0/0/1 10.0.29.1 IPsec Tunnel 10.0.29.2
CE 2 PE-1
1 1 1 PE-CE Traffic
A 21/24 lo0: 192.168.16.1
CE-CE IPsec Tunnel
CE-CE Traffic
 The Junos OS supports IPsec/Layer 3 VPN integration
•IPsec tunnels terminate between the PE and CE routers
•CE-CE IPsec tunnels extend through PE routers
•IPsec tunnels can use manual or dynamic security
associations
•PE and CE routers both require AS PIC or ES PIC
•PE-PE configuration requires no change, firewall filter-based
classification not used

PE-PE GRE and IPsec Tunnels
ge-0/0/0.0
IP ge-0/0/0.0
CE
Provider Core PE-2
2 lo0: 192.168.24.1 Network B
200.0.0.1
172.20.4/24
P-n ge-0/0/1
PE
ge-0/0/1
2 ge-0/0/0
CE PE-1
HK 1
21/24 1 lo0: 192.168.16.1
A
172.20.0/24
192.168.16.1 PE-PE Traffic 192.168.24.1
 Provide BGP/MPLS VPN service without MPLS backbone

•Secure transport across the provider’s backbone when the CE
device does not support IPsec
•Configure GRE and IPsec tunnels between PE routers
•MPLS information encapsulated with IP and IPsec header
•Source address is ingress PE router, destination address is BGP
next hop—the address of the egress PE router
Multicast VPNs

Model for Multiservice Network
Private IP ATM/FR Emulation
PSTN Bearer
and Signalling
Ethernet Services
Internet
L3VPN
L2VPN VPLS ?
(unicast only)
Signalling and Auto-Discovery (BGP)
Transport Infrastructure (MPLS LSPs)
Note: Legacy draft-Rosen L3VPN multicast scheme does not conform to this model.

Legacy Model for MVPN (draft-Rosen)
PIM adjacencies between PEs (per-VRF) to

exchange info about multicast receivers
L3VPN
(multicast)
Signalling and Auto-discovery (PIM)
Transport Infrastructure (multicast GRE tunnels)
Multicast trees across the core signalled by PIM running in

main routing instance

Legacy Multicast Topology (draft-Rosen)
Customer PIM domain Provider’s PIM domain Customer PIM domain
Source
CE
Provider Core PE-2
B
P-RP lo0: 192.168.24.1
OSPF Area 0
1.1.1.1
P1 P2
C-RP/DR
CE PE-1 AS 65412 Receiver
A 1 lo0: 192.168.16.1
1.1.1.1 224.7.7.7 M-cast Data 192.168.16.1 239.1.1.1 1.1.1.1 224.7.7.7 M-cast Data 1.1.1.1 224.7.7.7 M-cast Data
SA DA GRE-SA GRE-DA SA DA SA DA
 PE routers must participate in both customer’s and

provider’s multicast domain
 PIM/multicast traffic from customer instance of PIM
encapsulated in GRE using configured vpn-group-
address on PE router (example uses 239.1.1.1)
•Multicast data, hellos, join/prunes, Bootstrap, Auto-RP, etc.
•PE-1 and PE-2 join configured vpn-group-address
within provider’s domain using the provider RP
Motivations Behind NG-MVPN
 IETF motivations for a new MVPN scheme called

next-generation MVPN
•Increasing interest from customers of Layer 3 VPN services
in having multicast capability, in addition to unicast
• New mission-critical MVPN applications such as IPTV
•Point to multipoint MPLS LSPs provide multicast-like
forwarding
•Realization that existing Rosen scheme for MVPN has
fundamental architectural limitations

Model for Next-Generation MVPN
Private IP ATM/FR emulation
PSTN bearer +
signalling
Ethernet Services
Internet
L3VPN
IPTV
(unicast and L2VPN VPLS ?
multicast)
Signalling and Auto-discovery (BGP)
Transport Infrastructure (MPLS LSPs)
Traffic Engineering, bandwidth guarantees, fast-reroute…

Replacing PIM with BGP
 BGP for PE-PE signaling
• Seven MP-BGP NLRI for
MVPN signaling PE1
• MVPN membership
autodiscovery
• Autodiscovery for selective RR RR
provider tunnels
• Customer PIM join message PE5 PE2
conversion
• Active sources
PE3
• PE routers might need only PE4
a couple of BGP sessions

to route-reflectors
• Can be the same as Layer 3
VPN unicast scheme
Next-Generation MVPN Terms
 Terms
•PMSI : Type of tunnel to use to transport multicast data
across the provider core (also called provider tunnel)
• RSVP point to multipoint LSPs
• Provider instance PIM distribution trees (similar to draft-Rosen)
• MLDP
•I-PMSI
• Multidirectional: All PEs in a MVPN can transmit multicast packets
to all other PEs participating in MVPN
• Unidirectional: Enables only a particular PE to transmit multicast
packets to other PEs
•S-PMSI
• A particular PE can transmit multicast packets to a subset of PEs
Next-Generation MVPN BGP
Advertisements
 Next-generation MVPN routes use the MCAST-VPN NLRI
format
• AFI 1/SAFI 5
• Routes tagged with correct route target community are
placed into the bgp.mvpn.0 and Type routing-
Length Route Type Specific
instance.mvpn.0 table (1 bytes) (1 bytes) (variable length)
 Next-generation MVPN draft specifies new attributes

• P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute
Tunnel
Flags Type
MPLS Label Tunnel ID
(1 bytes) (1 bytes) (3 bytes) (variable length)
MPLS label that receiving PE should RSVP Session ID for RSVP point to
expect as an inner label for incoming multipoint LSPs
MVPN traffic (0 = No label)

Next-Generation MVPN BGP NLRI Types
(1 of 4)
 Type 1: Intra-AS Inclusive MVPN Membership Discovery
• Sent by all PE routers participating in MVPN
• In the case of I-PMSI using RSVP-TE, these routes determine
where to automatically build the point to multipoint LSPs
• Routes are tagged with PMSI Tunnel attribute
1:10.1.1.1:1:10.1.1.1
Type Sending Sending
PE’s RD PE’s lo0
 Type 2: Inter-AS Inclusive MVPN Membership Discovery

• Used for membership discovery between PE routers in
different ASs
• Not covered in this material 2:10.1.1.1:1:65412
Type Sending Sending
PE’s RD PE’s AS

(2 of 4)
 Type 3: Selective MVPN Autodiscovery Route
• Sent by the PE that initiates an S-PMSI
3:10.255.170.100:1:32:192.168.194.2:32:224.1.2.3:10.255.170.100
Sending C-S using S- C-G using Sending PE’s
Type C-S C-G
PE’s RD PMSI S-PMSI lo0
Mask Mask
 Type 4: Selective MVPN Autodiscovery Route for Leaf

• Sent by receiver PE upon receiving a Type 3 with the leaf
information bit set
4:3:10.255.170.100:1:32:192.168.194.2:32:224.1.2.3:10.255.170.100:10.255.170.98
Type Received Type Sending PE’s
3 Route lo0

(3 of 4)
 Type 5: Source Active Autodiscovery Route
• Sent by PE router that discovers an active multicast source
• Learned through PIM register messages (RP), MSDP source active
messages, or a locally connected source
5:10.255.170.100:1:32:192.168.194.2:32:224.1.2.3
Type Sending C-S C-G

C-S C-G
PE’s RD
Mask Mask
 Type 6: Shared Tree Join Route

• Sent by receiver PE that receives PIM join (C-*,C-G) on VRF
interface
6:10.255.170.100:1:65000:32:10.12.53.12:32:224.1.2.3
RD of upstream C-RP Address C-G
Type AS of C-RP C-G
PE (towards C-RP) upstream Mask Mask
PE

(4 of 4)
 Type 7: Source Tree Join Route
• Sent by receiver PE that receives PIM join (C-S,C-G) on VRF
interface
7:10.255.170.100:1:65000:32:192.168.194.2:32:224.1.2.3
RD of upstream C-S C-G
Type AS of C-S C-G
PE (towards C-RP) upstream Mask Mask
PE

Point-to-Multipoint LSP Concept
 RSVP point-to-multipoint LSPs can be used as the
transport mechanism for next-generation MVPN traffic
across the core
 Traffic can be protected using standard methods like fast reroute and
link protection
PE1
Can use MPLS FRR, Traffic
Engineering, Bandwidth
Core routers only need IGP plus Reservations
MPLS, no PIM needed!
P2
P1
PE5 PE2
PE4 PE3

Next-Generation MVPN Inclusive Trees
 Inclusive trees
• Each tree serves one MVPN
only PE1
• All the multicast traffic in

that MVPN arriving at an
ingress PE is mapped to
that same tree to get from
the ingress PE to all the PE5 PE2
other PEs in the same
MVPN
PE4 PE3
• Analogous to default-MDT
in draft-Rosen

Next-Generation MVPN Selective Trees
 Selective trees
• Serves particular selected
multicast group(s) from a PE1
given MVPN
• Similar to data-MDT in Selective Tree
draft-Rosen
PE5 PE2
PE4 PE3

I-PMSI Signalling Example (1 of 4)
 Example with show the use of inclusive trees with RSVP
point to multipoint LSPs
• Prior to enabling an MVPN, the PE routers have an existing
L3VPN established using LDP to signal LSPs
• The provider core does not have PIM enabled
Customer PIM domain Customer PIM domain

Source
PE-2
CE
Provider Core B
OSPF Area 0 lo0: 192.168.2.1
10.0.101.2
P1 P2
C-DR
CE PE-1
AS 65512
A 1 lo0: 192.168.6.1
PE-3 CE
C-RP C
lo0: 192.168.2.2

 With no source or receivers for multicast traffic, an
MVPN is enabled on the PE routers
• Each PE router:
• Advertises a Inclusive MVPN A-D route to each other tagged with
Route Target and PMSI Tunnel Attribute
• Automatically builds a point to multipoint LSP to other PEs with itself
as root and no PHP (virtual tunnel interface or vrf-table-label)
1:192.168.6.1:1:192.168.6.1
PMSI – RSVP Session ID, Label = 0
PE-2
CE
Provider Core B
OSPF Area 0 lo0: 192.168.2.1
P1 P2
C-DR
CE PE-1
AS 65512
A 1 lo0: 192.168.6.1
C-RP
PE-3 CE
lo0: 192.168.2.2 C

 Source begins sending multicast traffic
• CE-A sends register messages to PE-1
• PE-1 is now aware of an active source
• PE-1 sends SA Autodiscovery Route to remote PEs
5:192.168.6.1:1:32:10.0.101.2:32:224.7.7.7
PE-2
CE
Provider Core B
OSPF Area 0 lo0: 192.168.2.1
10.0.101.2
P1 P2
C-DR
CE PE-1
AS 65512
A 1 lo0: 192.168.6.1
PE-3 CE
C-RP C
lo0: 192.168.2.2
PIM Registers

 Using IGMP, receivers join source specific group
•Receiver CEs send PIM (S,G) join upstream to PE-2 and PE-3
•Receiver PEs convert PIM join to MVPN Source Tree Join
•Source PE convert MVPN Source Tree Join to PIM (S,G) Join
and sends it to the DR to complete the multicast tree
PIM (S,G) Join 7:192.168.6.1:1:65512:32:10.0.101.2:32:224.7.7.7 PIM (S,G) Join
CE
Provider Core PE-2 B
OSPF Area 0 lo0: 192.168.2.1
10.0.101.2
P1 P2
C-DR Receivers
CE PE-1
AS 65512
A 1 lo0: 192.168.6.1
PE-3 CE
C-RP C
lo0: 192.168.2.2

I-PMSI Forwarding
 After multicast forwarding tree is built
• CE-A sends native multicast packets to PE-1
• PE-1 encapsulates packets in a single MPLS header
• Outbound MPLS label is derived from the point to multipoint LSP
• P2 sends copies of packets to both PE-2 and PE-3
• Receiver PE’s pop outer label and send traffic based on VRF
S-IP 224.7.7.7 M-cast Data Label S-IP 224.7.7.7 M-cast Data S-IP 224.7.7.7 M-cast Data
SA DA MPLS SA DA SA DA
PE-2
CE
Provider Core B
OSPF Area 0 lo0: 192.168.2.1
S-IP=10.0.101.2
P1 P2
C-DR Receivers
CE PE-1
AS 65512
A 1 lo0: 192.168.6.1
PE-3 CE
C-RP C
lo0: 192.168.2.2

S-PMSI Signalling Example (1 of 5)
 Example with show the use of selective trees with RSVP
point to multipoint LSPs
• Prior to enabling an MVPN, the PE routers have an existing
L3VPN established using LDP to signal LSPs
• The provider core does not have PIM enabled

Source
PE-2 CE
Provider Core B
OSPF Area 0 lo0: 192.168.2.1
10.0.101.2
P1 P2
C-DR
CE PE-1
AS 65512
A 1 lo0: 192.168.6.1
PE-3 CE
C-RP C
lo0: 192.168.2.2

 With no source or receivers for multicast traffic, an

MVPN is enabled on the PE routers
• Each PE router:
• Advertises a Inclusive MVPN A-D route to each other tagged with
Route Target
• No point to multipoint LSPs are built between PEs at this point
Customer PIM domain 1:192.168.6.1:1:192.168.6.1 Customer PIM domain
CE
Provider Core PE-2 B
OSPF Area 0 lo0: 192.168.2.1
P1 P2
C-DR
CE PE-1
AS 65512
A 1 lo0: 192.168.6.1
PE-3 CE
C-RP C
lo0: 192.168.2.2

 Source begins sending multicast traffic
• CE-A sends register messages to PE-1
• PE-1 is now aware of an active source
• PE-1 sends SA Autodiscovery Route to remote PEs
5:192.168.6.1:1:32:10.0.101.2:32:224.7.7.7
PE-2
CE
Provider Core B
OSPF Area 0 lo0: 192.168.2.1
10.0.101.2
P1 P2
C-DR
CE PE-1
AS 65512
A 1 lo0: 192.168.6.1
PE-3 CE
C-RP C
lo0: 192.168.2.2
PIM Registers

 Using IGMP, receivers join source specific group

•Receiver CE-B sends PIM (S,G) join upstream to
•Receiver PE-2 converts PIM join to MVPN Source Tree Join
•No receiver attached to CE-C
7:192.168.6.1:1:65512:32:10.0.101.2:32:224.7.7.7 PIM (S,G) Join
PE-2
CE
Provider Core B
OSPF Area 0 lo0: 192.168.2.1
10.0.101.2
P1 P2
C-DR Receiver
CE PE-1
A 1 lo0: 192.168.6.1 AS 65512
PE-3 CE
C-RP lo0: 192.168.2.2 C

 PE-1 completes the multicast forwarding tree
•PE-1 sends S-PMSI Autodiscovery route remote PEs
•Only PE-2 responds with a Leaf Autodiscovery route
•PE-1 builds point to multipoint LSP to responding leaf PEs
and sends PIM join towards the DR
1 3:192.168.6.1:1:0:0.0.0.0:32:224.7.7.7:192.168.6.1
PMSI – RSVP Session ID, Label = 0, Leaf Info Required
4 4:3:192.168.6.1:1:0:0.0.0.0:32:224.7.7.7:192.168.6.1:192.168.2.1 2
PIM (S,G) Join Customer PIM domain
Customer PIM domain
PE-2 CE
Provider Core B
3 OSPF Area 0 lo0: 192.168.2.1
10.0.101.2
P1 P2
C-DR Receiver
CE PE-1
AS 65512
A 1 lo0: 192.168.6.1
PE-3 CE
C-RP lo0: 192.168.2.2 C

Hardware Requirements for
Next-Generation MVPNs
 Requires tunnel service PIC on certain routers

•Customer’s first hop DR
•Customer’s candidate RPs
•All PE routers participating in customer’s multicast network
• Except when using vrf-table-label
•Tunnel services simply needs to be enabled on the
MX Series DPC/MPCs
[edit]
user@pe1# show chassis
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}

Next-Generation MVPN Junos OS Support
 Junos OS supports:
•Provider Tunnel Types
• RSVP Inclusive Trees
• RSVP Selective Trees
• PIM–ASM Tunnels
• PIM-SSM Tunnels
• Data MDT Tunnels
•PIM features
• PIM Sparse Mode
• PIM Dense Mode
• Auto-RP
• Bootstrap Protocol

Next-Generation MVPN Configuration
(1 of 4)
 PE to PE MP-BGP session must be configured to allow

for MVPN signaling
[edit]
user@pe1# show protocols bgp
family inet {
unicast;
any;
}
family inet-vpn {
any;
}
family inet-mvpn {
signaling;
}
type internal;
neighbor 192.168.2.2;
neighbor 192.168.2.1;
}

(2 of 4)
 Configure P2MP LSP template for provider tunnel
[edit]
user@pe1# show protocols mpls
label-switched-path mvpn-example {
template;
no-cspf;
link-protection;
p2mp;
}
 Configure RSVP-TE LSP to be used as provider tunnel
Inclusive Provider Tunnel Selective Provider Tunnel
[edit routing-instances mcast-pe-vrf] [edit routing-instances mcast-pe-vrf]
user@pe1# show user@pe1# show
… …
provider-tunnel { provider-tunnel {
rsvp-te { selective {
label-switched-path-template { group 224.7.7.0/24 {
mvpn-example; wildcard-source {
} rsvp-te {
} label-switched-pat…{
} default-template;
… …
vrf-table-label; vrf-table-label;
…
(3 of 4)
 Configure the VRF to participate in the C-PIM domain

as well as the MVPN
[edit]
user@pe1# show routing-instances mcast-pe-vrf
…
protocols {
…
pim {
rp {
local {
address 192.168.13.3;
}
}
interface all {
mode sparse;
}
}
mvpn {
mvpn-mode {
spt-only;
}
…
(4 of 4)
 Full VRF example configuration
[edit routing-instances mcast-pe-vrf] …
user@pe1# show pim {
instance-type vrf; rp {
interface ge-1/0/9.251; local {
interface lo0.13; address 192.168.13.3;
provider-tunnel { }
rsvp-te { }
label-switched-path-template { interface all {
mvpn-example; mode sparse;
} }
} }
} mvpn {
vrf-target target:65512:100; mvpn-mode {
vrf-table-label; spt-only;
protocols { }
bgp { }
group external { }
type external;
export exp-policy;
neighbor 10.0.50.2 {
peer-as 65501;
}
}
…
Options
 Provider tunnels
[edit routing-instances mcast-pe-vrf]
user@pe1# set provider-tunnel ?
…
> mdt Data MDT tunnels for PIM MVPN
> pim-asm PIM-SM provider tunnel
> pim-ssm PIM-SSM provider tunnel
> rsvp-te RSVP-TE point-to-multipoint LSP for flooding
> selective Selective tunnels
 MVPN settings
[edit routing-instances mcast-pe-vrf]
user@pe1# set protocols mvpn ?
…
> autodiscovery-only Use MVPN exclusively for PE router autodiscovery
> mvpn-mode MVPN mode of operation
receiver-site MVPN instance has sites only with multicast receivers
> route-target Configure route-targets for MVPN routes
sender-site MVPN instance has sites only with multicast sources
> traceoptions Trace options for BGP-MVPN
unicast-umh-election Upstream Multicast Hop election based on unicast route
preference
View VRF PIM Status
 Verify PIM status

user@pe1> show pim join instance mcast-pe-vrf extensive
Instance: PIM.mcast-pe-vrf Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 224.7.7.7
Source: 10.0.101.2
Flags: sparse
Upstream interface: ge-1/0/9.251
Upstream neighbor: 10.0.50.2
Upstream state: Local RP, Join to Source
Keepalive timeout:
Downstream neighbors:
Interface: Pseudo-MVPN
Instance: PIM.mcast-pe-vrf Family: INET6

R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Verify Multicast Packet Forwarding
 Verify multicast traffic

user@pe1> show multicast route extensive instance mcast-pe-vrf
Family: INET
Group: 224.7.7.7
Source: 10.0.101.2/32
Upstream interface: ge-1/0/9.251
Session description: Unknown
Statistics: 139 kBps, 263 pps, 532482 packets
Next-hop ID: 3638
Upstream protocol: MVPN
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: forever
Wrong incoming interface notifications: 0
Family: INET6

MVPN RIB-IN
 View MVPN routes learned from remote PEs
•Routes that populate this table have been accepted by vrf-
import policy (based on vrf-target matching)
user@pe1> show route table bgp.mvpn.0
bgp.mvpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

1:192.168.2.1:65535:192.168.2.1/240
AS path: I
> to 172.22.250.2 via ge-1/0/4.250, Push 299888
1:192.168.2.2:65535:192.168.2.2/240
AS path: I
> to 172.22.250.2 via ge-1/0/4.250, Push 299808
7:192.168.6.1:5:65512:32:10.0.101.2:32:224.7.7.7/240
AS path: I
> to 172.22.250.2 via ge-1/0/4.250, Push 299888

VRF Specific MVPN Routes
 View MVPN routes specific to a particular VRF
user@pe1> show route table mcast-pe-vrf.mvpn.0
mcast-pe-vrf.mvpn.0: 5 destinations, 6 routes (5 active, 1 holddown, 0 hidden)

1:192.168.2.1:65535:192.168.2.1/240
AS path: I
> to 172.22.250.2 via ge-1/0/4.250, Push 299888
1:192.168.2.2:65535:192.168.2.2/240
AS path: I
> to 172.22.250.2 via ge-1/0/4.250, Push 299808
1:192.168.6.1:5:192.168.6.1/240
*[MVPN/70] 00:41:29, metric2 1
Indirect
5:192.168.6.1:5:32:10.0.101.2:32:224.7.7.7/240
*[PIM/105] 18:23:21
Multicast (IPv4)
7:192.168.6.1:5:65512:32:10.0.101.2:32:224.7.7.7/240
*[PIM/105] 00:18:31
Multicast (IPv4)
[BGP/170] 00:18:31, localpref 100, from 192.168.2.1
AS path: I
> to 172.22.250.2 via ge-1/0/4.250, Push 299888

Verify Provider Tunnel
 View status of point to multipoint LSP
user@pe1> show rsvp session
Ingress RSVP: 2 sessions
To From State Rt Style Labelin Labelout LSPname
192.168.2.1 192.168.6.1 Up 0 1 SE - 300096 192.168.2.1:192.168.6.1:5:mvpn:mcast-pe-vrf
192.168.2.2 192.168.6.1 Up 0 1 SE - 300096 192.168.2.2:192.168.6.1:5:mvpn:mcast-pe-vrf
 Verify multicast traffic with traverse point to multipoint

LSP
user@pe1> show route forwarding-table destination 224.7.7.7 extensive
Routing table: mcast-pe-vrf.inet [Index 5]
Internet:
…
Destination: 224.7.7.7.10.0.101.2/64
Route type: user
Route reference: 0 Route interface-index: 223
Flags: cached, check incoming interface , accounting, sent to PFE
Next-hop type: flood Index: 3638 Reference: 2
Nexthop: 172.22.250.2
Next-hop type: Push 300096 Index: 3625 Reference: 1
Next-hop interface: ge-1/0/4.250
…

BGP Layer 2 VPNs

Differences Between Layer 2 VPNs
BGP Layer 2 LDP Layer 2
BGP VPLS LDP VPLS
VPN Circuit
Auto-Provisioning BGP Based Not Defined BGP Based Not Defined
RFC 4448 RFC 4448 RFC 4448 RFC 4448
Layer 2 Frame Format
VPN Signaling BGP LDP BGP LDP

Interprovider and Carrier Defined Not Defined Defined Not Defined
of Carriers
AAL5, Cell AAL5, Cell Ethernet Only Ethernet Only
ATM Modes
IETF Status Internet-Draft RFC 4447 RFC 4761 RFC 4762

Juniper Networks Yes Yes Yes Yes
Support

Layer 2 MPLS-Based VPNs
 Provider edge device delivers Layer 2 circuit IDs

(DLCI, VPI/VCI, or VLAN ID) to the customer
•Customer sees standard Layer 2 circuit identifiers for each
reachable site
 PE router maps circuit IDs to and from MPLS LSPs for
transport over the provider core
•Can use label stacking to improve scalability
 Customer maps its own routing architecture to the
circuit mesh
•Customer routes are transparent to provider
•Separation of administrative responsibility

Improving Traditional Layer 2 VPNs
 Decouple edge (customer-facing) technology from

core technology
 Have a single network infrastructure for multiple
services
 Simplify provisioning

Standards for Layer 2 VPNs
 Proposals supported: draft-kompella-l2vpn-l2vpn
(BGP Layer 2 VPN), RFC 4447 (LDP Layer 2 circuit),
RFC 4761 (BGP VPLS) and RFC 4762 (LDP VPLS)
•All use martini encapsulation (RFC 4448)
 BGP Layer 2 VPN:
•BGP signaling
•Martini encapsulation in data plane
•Offers IP-only Layer 2 interworking to allow interconnection
of different Layer 2 circuit technologies
•Proposals are different in control plane
•BGP Layer 2 VPNs use BGP while LDP Layer 2 Circuits use
LDP-based signaling

Different Device Roles in a Layer 2 VPN
CE-A
VPN-A PE-1 PE-2 CE-C
VPN A
ATM
CE-B P P
Frame
VPN-B Relay PE-3 CE-D
VPN B
Frame
 Different device roles P P Relay
•CE device:
• Layer 2 and Layer 3 independent of the service provider network
• Normally the same Layer 2 technology used at both ends of a VPN
•PE routers:
• Maintain and exchange VPN-related information with other PE
routers
• Use MPLS LSPs to carry VPN traffic between PE routers
•P routers:
• Forward VPN traffic transparently over established LSPs
• Do not maintain VPN-specific forwarding information
VPN Forwarding Tables
 Each VRF is populated with:

•The information provisioned for the local CE device
• For example, site ID, logical interfaces, encapsulation, label base
•Layer 2 VPN NLRIs are received from other PE routers using
MP-BGP A VRF is created for each CE device
connected to the PE router
CE-A
Site 1 PE-1 PE-2 CE-C
VPN-B
Site 2
P P VPN-B
CE-B
Site 1 PE-3 CE-D
VPN-A
Site 4
P P VPN-A

VPN Connection Tables
 The VPN connection table is a subset of information

held by the VRF
•One Layer 2 NLRI per site
 The PE routers distribute Layer 2 NLRIs using MP-BGP
A Layer 2 NLRI is distributed for each VPN site to PEs
CE-A CE-C
Site 1 Site 2
VPN-A VRF VRF VPN-B
NLRI
PE-1 PE-2
CE-B CE-D
VRF P1 P2 VRF
Site 1 Site 4
VPN-B MP-BGP Session VPN-A

Provisioning the Core
 Provisioning the core:

•LSPs between PE routers must be pre-established
• Can use either RSVP or LDP
• Can use LSPs for many services (for example, Internet, Layer 2
VPN, Layer 3 VPN)
•Between PE routers, MP-BGP must be configured to support
the sessions with l2-vpn signaling family
CE-A CE-C
Site 1 Site 2
VPN-A VRF VRF VPN-B
PE-1 PE-2
CE-B CE-D
VRF P1 P2 VRF
Site 1 Site 4

Provisioning the Local CE Device
 Local site provisioning:
•List of DLCIs: One for each remote CE device, spare values
(over-provisioning) recommended
• Can be learned automatically through LMI
•DLCIs independently numbered for each CE device
• VLAN IDs must be the same at both ends
•LMI and Inverse ARP properties
•No changes as VPN membership changes
• Until over-provisioning limit is reached
•Configuration of Layer 3 properties and routing protocols
CE-D's Routing Table
DLCIs
In Out
63
CE-D
10/8
20/8
30/8
DLCI 63
DLCI 75
DLCI 82
75
82
Core
Provisioning Customer Site on PE Router
CE-D VRF
R-Target RT1
 A VRF is provisioned at each PE Site ID 4
router for each local CE device Label Range 4
CE-D's NLRI
•Import/export route target Label Base 1000

Sub-Int IDs Label
•Site ID: Unique value to identify a site 63
•Label range: Maximum number of 75
CE devices to which it can connect 82
•Label base: Label assigned to the first sub-interface ID—the

PE router reserves n contiguous labels, where n is the CE
device range
•Sub-interface IDs list: Set of local sub-interface IDs (DLCIs)
assigned for the CE-PE connection
• The PE router assigns the reserved labels to the sub-interface IDs
 Logical interfaces and Layer 2 properties must be
compatible
VRF Provisioning Example
CE-A CE-C
Site 1 MP-BGP Session Site 2
VPN-A VRF VRF VPN-B
FR FR
PE-1 PE-2
CE-B CE-D
VRF P1 P2 VRF
Site 1 FR Site 4
VPN-B R-Target RT1
VPN-A
Site ID 4
Note: CE-E and CE-F are not shown
4
Label Range
Label Base 1000

 PE-2 is configured Label Offset 1
with a VRF for CE-D CE-D’s DLCI to CE-A 63

CE-D’s DLCI to CE-E 75
1000 Label used to reach CE-D from CE-A
1001 Label used to reach CE-D from CE-E
 PE-2 computes CE-D’s DLCI to CE-F 82 1002 Label used to reach CE-D from CE-F
received VRF labels based on remote site ID (label-

base-local + remote-site-ID – label-offset-local)
•Associates each VRF label with local connections based on
the ordered list of interfaces and use of remote-site-id
Distributing Layer 2 NLRIs (1 of 2)
 Distribution uses MP-BGP for auto-discovery of

members
 Connection mapping between sites is automatic
 VPN policy:
•BGP route target communities and route filtering (based on
route target) produces a given VPN topology

Distributing Layer 2 NLRIs (2 of 2)
 PE-1 receives BGP update with PE-2’s CE-D NLRI
•PE-1 stores the information within the received NLRI in its
corresponding VRF table.
CE-A CE-C
Site 1 MP-BGP Session Site 2
VPN-A VRF VRF VPN-B
FR FR
PE-1 PE-2
CE-B CE-D
VRF P1 P2 VRF
Site 1 FR Site 4
VPN-B VPN-A
CE-D NLRI update
Note: CE-E and CE-F are not shown
R-Target RT1
Site ID 4
Label Range 4
Label Base 1000
Label Offset 1

Updating mpls.0 Table (1 of 2)
 PE-1 updates its CE-A VRF with CE-D’s NLRI information
•Import route target (RT1) for CE-A VRF matches route target
carried by the BGP route
•NLRI copied into bgp.l2vpn.0
 PE-1 computes outgoing label for traffic sent to CE-D
•(local-site-id + remote-label-base – remote-label-offset = 1000)
•Matches label already computed by PE-2 for received traffic
from Site CE-A Frame Relay
DLCI 414
CE-A CE-C
Site 1 Site 2
PE-1’s mpls.0 VPN-A VRF VRF VPN-B
Inner TX
PE-1 PE-2
Sub-Int IDs CE-B CE-D
Label P1 P2
Site 1 VRF VRF Site 4
150 5020 VPN-B VPN-A
265 9350
414 1000 Label used to reach CE-D

Updating mpls.0 Table (2 of 2)
 PE-1 obtains the outer label by resolving PE-2’s host

address through an RSVP or LDP LSP
 PE-1 maps VRF label for CE-D to a local connection
identifier based on the ordered list of interfaces and
use of remote-site-id Frame Relay
CE-A DLCI 414 CE-C
Site 1 Site 2
VPN-A VRF VRF VPN-B
PE-1 PE-2
CE-B CE-D
VRF P1 P2 VRF
Site 1 Site 4
PE-1’s mpls.0 table VPN-B VPN-A
Inner TX Outer TX
Sub-Int IDs
Label Label
150 5020
265 9350
414 1000 500 LSP label to PE-2

Data Flow (1 of 5)
DLCI (414)
CE-A Packet CE-C
Site 1 Site 2
VPN-A mpls.0 VPN-B
PE-1 PE-2
CE-B CE-D
P1 P2
Site 1 mpls.0 Site 4
VPN-B VPN-A
 CE-A sends packets to the PE router using DLCI 414

•This DLCI maps to site 4 (CE-D)

Data Flow (2 of 5)
PE-1 MPLS label (500)
1) Lookup incoming interface in mpls.0
Site label (1000)
2) Push VPN label (1000)
3) Push MPLS label (500) CE-A Packet CE-C
Site 1 Site 2
VPN-A mpls.0 VPN-B
PE-1 PE-2
CE-B CE-D
P1 P2
VPN-B VPN-A
 The ingress PE router removes the DLCI

 VRF lookup derives two labels
•Outer tunnel (MPLS) label:
• Identifies the LSP to egress PE router
• Distributed by RSVP or LDP
•Inner (site) label:
• Identifies outgoing subinterface from egress PE router to the CE
• Derived from BGP Layer 2 NLRI distributed by egress PE router
Data Flow (3 of 5)
MPLS label (600)
Site label (1000)
CE-A Packet CE-C
Site 1 Site 2
VPN-A mpls.0 VPN-B
PE-1 PE-2
CE-B CE-D
P1 P2
VPN-B VPN-A
 MPLS switching by LSRs in the core

•Outer label swapped at each LSR

Data Flow (4 of 5)
Site label (1000)
CE-A Packet CE-C
Site 1 Site 2
VPN-A mpls.0 VPN-B
PE-1 PE-2
CE-B CE-D
P1 P2
VPN-B VPN-A
 The outer label is removed through penultimate hop

popping

Data Flow (5 of 5)
CE-A CE-C
Site 1 Site 2
VPN-A mpls.0 VPN-B
PE-1 PE-2
CE-B CE-D
P1 P2
VPN-B VPN-A
DLCI 63
Packet
 The egress PE router does a label lookup to find the

corresponding DLCI value
 The inner label is popped at the egress PE router
 The native Frame Relay packet is sent to the
corresponding outbound logical interface

BGP Layer 2 VPN: Configuration Complexity
 Optimized for common topologies (but also can

support arbitrary topologies)
•For example, full-mesh, hub-and-spoke topologies are easy
to provision
 0(N) configuration for the whole VPN
•Could be more for complex topologies
 0(1) configuration to add a site
•Assumes over-provisioning of DLCIs (connection IDs) at
existing sites

BGP Layer 2 VPN: Layer 2 Technologies
 Supported encapsulations:
•Frame Relay
•ATM AAL5
•ATM SNAP
•ATM Transparent Cell Mode
•Ethernet
•Ethernet VLAN
•Cisco HDLC
•PPP
•IP-only interworking

Martini Encapsulation
 draft-kompella-l2vpn-l2vpn (BGP Layer 2 VPN), RFC

4447 (LDP Layer 2 circuit), RFC 4761 (BGP VPLS) and
RFC 4762 (LDP VPLS).
 RFC 4448 defines the Martini encapsulation
• Encapsulates data (Layer 2 frame or version of original frame) in a
control word
• Martini control word is used to help pad and preserve information
in the original Layer 2 frame as it is relayed between PE devices
MPLS/GRE Header MPLS Header Control Word Layer 2 Frame (modified)
RSVD FLAGS 00 Length Sequence Number

# of bits 4 4 2 6 16
Flags and Modified Layer 2 Frame (1 of 2)
 Format of the modified Layer 2 frame and meaning of
the flags depends on encapsulation type:
•Frame Relay (control word required)
• Format: Original frame minus header and CRC
• Flags: FECN, BECN, DE, C/R
•ATM AAL5 (control word required)
• Format: Reassembled AAL5 packet minus AAL5 trailer
• Flags: EFCI, CLP, C/R (Frame Relay/ATM interworking)
•ATM Cell (control word is optional)
• Format: One or more original cells
• Flags: Not used, original cells contain pertinent information
•Ethernet and Ethernet VLAN (control word is optional)
• Format: Original frame minus preamble and FCS
• Flags: Not used

Flags and Modified Layer 2 Frame (2 of 2)
 Format of the modified Layer 2 frame and meaning of

the flags depends on encapsulation type (contd.):
•HDLC (control word optional)
• Format: Original frame minus HDLC Flags and FCS
• Flags: Not used
•PPP (control word is optional)
• Format: Original frame minus HDLC address and FCS
• Flags: Not used

Preliminary Layer 2 VPN Configuration
 Preliminary steps for P and PE routers:

1. Choose and configure the IGP
2. Configure MP-BGP peering among PE routers
• Must include l2-vpn signaling NLRI capability
3. Enable MPLS and the desired MPLS signaling protocol(s)
on P and PE routers
4. Establish LSPs between PE routers
• LSP establishment automatic for LDP
• The BGP next hop associated with the Layer 2 VPN NLRI must
equal the host ID of the LSP’s endpoint
 PE routers perform all VPN-related configuration

PE-PE IBGP Peering
 PE-to-PE MP-BGP sessions requires the

l2-vpn signaling NLRI
•Add family inet-vpn if Layer 3 VPN support also needed
•Add family inet if PE router is to support IPv4 NLRI
 The Junos OS negotiates BGP route refresh by default
[edit protocols bgp]
user@R1# show
type internal;
family inet {
unicast;
}
family l2vpn {
signaling;
}
neighbor 192.168.1.3;
}
MP-BGP Peering Example
Peer: 192.168.1.3+52460 AS 65512 Local: 192.168.1.1+179 AS 65512
...
Address families configured: inet-unicast l2vpn-signaling
Local Address: 192.168.1.1 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.1.3 Local ID: 192.168.1.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast l2vpn-signaling
NLRI advertised by peer: inet-unicast l2vpn-signaling
NLRI for this session: inet-unicast l2vpn-signaling
Peer supports Refresh capability (2)
...
Table bgp.l2vpn.0
Send state: not advertising
Active prefixes: 1
...

Layer 2 VPN NLRI
Length (2 Bytes)
 Layer 2 AFI/SAFI == 25/65 Route Distinguisher (8 Bytes)
•CE device’s ID uniquely identifies a CE ID (2 Bytes)
site within a given VPN Label Block Offset (2 Bytes)
Label Base (3 Bytes)

•Label block offset allows a site to
Circuit Status Vector
choose the correct label when
Other Variable Length TLVs
multiple blocks are advertised
• One NLRI update is generated for each label block
 Circuit status vector:
•Indicates label range
•Reports status of local circuit and transmit LSP

The Circuit Status Vector
MP-BGP Session ATM PVC detected
down by PE-1
F5 RDI cells
CE-A PE-1 PE-2 CE-B
Site 1 Site 2
VPN-A ATM P1 P2 ATM VPN-A
(bits) 0 n
1 ...
Layer 2 NLRI with updated CSV
 The circuit status vector contains a single bit for each

label in a block
•Setting this bit to a 1 indicates that either (or both) the local
circuit or the LSP to the remote PE router is down
•Receiving PE router reports failure to attached CE device
Layer 2 Information Extended Community
1 Frame Relay
2 ATM AAL5 Community Type (2 Bytes)
3 ATM Transparent Cell
4 Ethernet VLAN
Encapsulation Type (1 Byte)
5 Ethernet Control Flags (1 Byte)
6 Cisco HDLC
7 PPP Layer 2 MTU (2 Bytes)
12 VPLS
64 IP-Only Layer 2 Internetworking
Reserved (2 Bytes)
 Layer 2 information:
•Control flags indicate:
• If sequencing is required
• Whether the Martini control word is required
•MTU field describes the VPN’s MTU
• All members of a VPN must use the same MTU, as mismatched
MTU causes NLRI to be ignored
Layer 2 VPN Configuration Overview
 Layer 2 VPN configuration overview:

•Create Layer 2 VPN routing instance
•Assign a route distinguisher
•Define BGP extended communities (route target)
•Configure vrf-target statement or create and apply VRF
import and export policies
•Configure local site properties
• Assign a site ID
• Specify VPN encapsulation and interfaces
• Configure PE-CE VPN interfaces

Example Layer 2 VPN Topology
•MP-BGP between PE routers, loopback peering,
•CE devices running OSPF Area 0
Provider Core
AS 65512
Site 1 Site 2
OSPF Area 0
OSPF Area 0 OSPF Area 0
R1 R2 R3
.1 .1 .2 .2 .1 .2 Site 2
Site 1
10.0.10.0/24 172.22.210.0/24 172.22.212.0/24 10.0.10.0/24
CE-A PE P PE CE-B
lo0 192.168.11.1 lo0 192.168.1.1 lo0 192.168.1.3 lo0 192.168.11.2

Creating a Layer 2 VPN Routing Instance
instances] configuration hierarchy
•Selecting instance-type l2vpn creates a VRF instance
type

user@R1# show
instance-type l2vpn;
interface <interface-name>;
route-distinguisher <rd_type>;
vrf-target <target community>;

Example Layer 2 Instance
 A Layer 2 VPN instance called vpn-a with a single
interface provisioned between the PE and CE
• vrf-target statements can be used rather than vrf
import/export statements
 Local site properties are set under protocols
user@R1# show
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site ce-A {
site-identifier 1;
interface ge-1/0/4.512 {
}
}
...
Layer 2 Instance: VRF Import Policy
 Layer 2 VPN import policy:
•Installs Layer 2 NLRIs learned from other PE routers using
MP-BGP
• NLRI with matching route target communities are installed in the
associated Layer 2 VRF
• Nonmatching updates are discarded
user@R1# show
...
term 1 {
from {
protocol bgp;
community vpn-a;
}
then accept;
}
term 2 {
then reject;
}
}
Layer 2 Instance: VRF Export Policy
 Layer 2 VPN export policy:

•Adds a route target community to the site ID and label block
advertised to remote PE routers
•No routing protocol-based match condition is specified
user@R1# show
...
term 1 {
then {
accept;
}
}
term 2 {
then reject;
}
}

Layer 2 VPN Extended BGP Communities
 The target tag specifies a route target extended

community
•Policy matches the route target control that the Layer 2 site
information imported into a given VRF
user@R1# show
...

Layer 2 Instance: Local Site Properties
 Local site properties configured under the protocols

portion of l2vpn instances

user@R1# show
protocols {
l2vpn {
site CE-A {
site-identifier 1;
interface ge-1/0/4.512
}
}
}

Default Site Association Rules
 Inherited remote site identifier is one higher than
previous interface
•First interface associated with Site 1 by default
• Default inheritance increased by 2 when remote site
identifier = local site ID
site CE-A {
site-identifier 1;
interface ge-1/0/4.512; Default remote site identifier = site 2
interface ge-1/0/4.513; Default remote site identifier = site 3

Remote Site Identifier Example
 Explicitly define the remote site

 Both examples produce equivalent connectivity and
label ranges
l2vpn {
site CE-A {
site-identifier 1;
remote-site-id 3;
}
remote-site-id 2;
. . .
. . .
l2vpn {
site CE-A {
site-identifier 1;
interface ge-1/0/4.512; (Default RSI = 2)
interface ge-1/0/4.513; (Default RSI = 3)
. . .

Interface Configuration Example
 PE to CE interface configuration:
•Encapsulation is set at the interface level and the unit level
•CCC vlans must be between 512 and 4094
ge-1/0/4 {
vlan-tagging;
encapsulation vlan-ccc;
unit 512 {
vlan-id 512;
}
unit 513 {
vlan-id 513;
}
}

Expanding Layer 2 VPN Membership (1 of 5)
Provider Core Site B
Site A AS 65512
OSPF Area 0 OSPF Area 0 CE-B
unit 512 R1 R2 R3 lo0 192.168.11.2
.1 10.0.10.0/24 .1 .2 .2 .1
Site A .1 10.0.11.0/24 Site B & C
172.22.210.0/24 172.22.212.0/24
unit 513 PE OSPF Area 0
CE-A P PE
lo0 192.168.11.1 lo0 192.168.1.1 lo0 192.168.1.3
Site C
CE-C
lo0 192.168.11.3
 Sites A and B are over-provisioned

•One VLAN ID needed for two sites, but two are provisioned
to allow for a future three-node full mesh
•Over-provisioning required to take advantage of the
draft-kompella auto-provisioning features
 Now, adding Site C should not require modification to
the R1 PE router (Site A)
 CE-A’s interface and protocol configuration:

user@CE-A# show interfaces user@CE-A# show protocols
ge-1/1/4 { ospf {
vlan-tagging; area 0.0.0.0 {
vlan-id 512; interface ge-1/1/4.513;
family inet { }
address 10.0.10.1/24; }
}
}
unit 513 {
vlan-id 513;
family inet {
address 10.0.11.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.11.1/32;
}
}
}
 R1’s VPN interface and Layer 2 configuration (Site A):

[edit interfaces]
user@R1# show ge-1/0/4 user@R1# show routing-instances
vlan-tagging; vpn-a {
encapsulation vlan-ccc; instance-type l2vpn;
encapsulation vlan-ccc; interface ge-1/0/4.513;
vlan-id 512; route-distinguisher 192.168.1.1:1;
} vrf-import import-vpn-a;
unit 513 { vrf-export export-vpn-a;
encapsulation vlan-ccc; protocols {
vlan-id 513; l2vpn {
} encapsulation-type ethernet-vlan;
site CE-A {
site-identifier 1;
Default site 2 interface ge-1/0/4.512;
association interface ge-1/0/4.513;
}
} Default site 3
} association
}
 R3’s VPN interface configuration (Site B and Site C):
[edit interfaces] [edit interfaces]

user@R3# show ge-1/0/4 user@R3# show ge-1/0/5
vlan-tagging; vlan-tagging;
encapsulation vlan-ccc; encapsulation vlan-ccc;
unit 512 { unit 513 {
vlan-id 512; vlan-id 513;
} }
unit 514 { unit 514 {
vlan-id 514; vlan-id 514;
} }

 R3’s VPN interface and Layer 2 configuration

(Site B and Site C): .
.
[edit routing-instances vpn-a] .
user@R3# show protocols {
instance-type l2vpn; l2vpn {
interface ge-1/0/4.512; encapsulation-type ethernet-vlan;
interface ge-1/0/4.514; site CE-B {
interface ge-1/0/5.513; site-identifier 2;
route-distinguisher 192.168.1.3:1; interface ge-1/0/4.514;
vrf-import import-vpn-a; }
vrf-export export-vpn-a; }
site CE-C {
. site-identifier 3;
. interface ge-1/0/5.513;
. interface ge-1/0/5.514;
}
}
}

Layer 2 Interworking Stitching
BGP Layer 2 VPN BGP Layer 2 VPN
10.0.11.0/24 10.0.11.0/24
.1 .2 Site 2
Site 1
ge-1/0/4 ge-1/0/4
CE-A PE1 P1 P2 PE3 CE-B
lo0 192.168.1.1 lo0 192.168.1.3
PE2
lo0 192.168.1.2
 Layer 2 interworking interface uses the Junos OS to

stitch together both BGP Layer 2 VPN’s routes
•Include the iw0 statement under [edit interfaces]
hierarchy
• The logical interfaces must be associated with the endpoints of the
BGP Layer 2 VPNs.
•Layer 2 interworking l2iw protocols must be configured

Stitching: Interface Configuration
 The iw0 interface is configured under the
[edit interfaces] hierarchy
 The encapsulation and vlan-id must be the
same as the remote end of the VPN
[edit interfaces]
user@PE2# show
iw0 {
unit 0 {
vlan-id 610;
peer-unit 1;
}
unit 1 {
vlan-id 610;
peer-unit 0;
}
}

Stitching: BGP Layer 2 VPNs
 The iw0 interface must be configured under both

Layer 2 VPN instances using the separate peer units
[edit routing-instances] [edit routing-instances]
user@PE-2# show user@PE-2# show
vpn-1 { ...
instance-type l2vpn; vpn-2 {
interface iw0.0; instance-type l2vpn;
route-distinguisher 192.168.1.2:11; interface iw0.1;
vrf-target target:65512:2; route-distinguisher 192.168.1.2:12;
protocols { vrf-target target:65512:2;
l2vpn { protocols {
encapsulation-type ethernet-vlan; l2vpn {
site 1 { encapsulation-type ethernet-vlan;
site-identifier 2; site 2 {
interface iw0.0 { site-identifier 2;
remote-site-id 1; interface iw0.1 {
} remote-site-id 3;
} }
} }
} }
} }
... }

Layer 2 VPN Troubleshooting: Overview
• Core problems often indicated by inability to establish BGP
sessions or PE-PE LSPs
•Physical Layer, Data Link Layer, IGP, BGP, MPLS, VPN
configuration and import/export policies
 Difficulty caused by inability to conduct PE-CE pings
•Can be difficult to determine operational status of PE-CE link
• Ethernet does not support Data Link Layer keepalives
• PPP and HDLC keepalives operate end to end
• Frame Relay LMI and ATM OAM can be used to verify PE-CE link
integrity
•Watch for mismatched DLCIs/VCIs/VLAN IDs on PE-CE link
•VLAN IDs must be the same end to end

 Are the PE-PE BGP sessions established?
•Layer 2 VPN family?
routers?
•BGP next hop = to LSP egress?
•Does MPLS ping complete?
 Do any hidden routes exist?

Displaying Layer 2 VPN Connections
user@R1> show l2vpn connections
Layer-2 VPN connections:
Legend for connection status (St)

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 availble
BK -- Backup connection ST -- Standby connection
PF -- Profile parse failure PB -- Profile busy
RS -- remote site standby SN -- Static Neighbor
Legend for interface status

Up -- operational
Dn -- down If there is a problem the code will be displayed here.
Instance: vpn-a This code can provide you with a clue where to begin.
Local site: CE-A (1)
connection-site Type St Time last up # Up trans
2 rmt Up Sep 29 17:04:28 2010 2
Remote PE: 192.168.1.3, Negotiated control-word: Yes (Null)
Incoming label: 800001, Outgoing label: 800004
Local interface: ge-1/0/4.512, Status: Up, Encapsulation: VLAN
Examining Layer 2 VPN NLRI
 The Junos OS allows you to view a VRF table by using
the show route table vpn-name command
•VRF tables contain:
• Local entries for attached sites
• Layer 2 VPN label blocks for updates received from remote PE
routers with matching route targets
 The bgp.l2vpn.0 table contains all NLRIs learned
from remote PE routers with matching route targets
•NLRI updates that do not match one local VRF are discarded
• keep all option is useful for troubleshooting route target
related problems (use only for troubleshooting)
 The show route protocol bgp command
displays all BGP routes in all RIBs
•Output can be filtered by piping output to match or find
Examining the PE mpls.0 Forwarding Table
 The PE mpls.0 forwarding table
•Incoming Layer 2 VPN interface to LSP mapping
•Incoming inside label value from remote PE
mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
0 *[MPLS/0] 1w1d 00:16:01, metric 1

Receive
1 *[MPLS/0] 1w1d 00:16:01, metric 1
Receive
2 *[MPLS/0] 1w1d 00:16:01, metric 1
Receive
800001 *[L2VPN/7] 04:10:30
> via ge-1/0/4.512, Pop Offset: 4
ge-1/0/4.512 *[L2VPN/7] 04:10:30, metric2 2
> to 172.22.210.2 via ge-1/0/0.210, label-switched-path lsp-1
PE Layer 2 VPN interface

LSP used to reach remote PE
Incoming inside label from remote PE

 Is the Physical Layer up?

•Physical Layer alarms
•Frame Relay LMI/ATM ILMI and OAM cells
•Lack of IP connectivity between PE-CE makes conventional
troubleshooting problematic
 Are compatible circuit IDs provisioned?
 Pings and CE access (Telnet) require OoB access
•Separate interface or logical unit with compatible IP
addressing

Tracing Layer 2 VPNs
 Tracing options for Layer 2 VPNs:

[edit routing-instances vpn-a protocols l2vpn]
user@R1# set traceoptions flag ?
all Trace everything
connections Trace Layer 2 VPN and VPLS connections
error Trace errors
general Trace general events
nlri Trace Layer 2 VPN and VPLS remote site advertisements
normal Trace normal events
oam Trace OAM messages
policy Trace policy processing
route Trace routing information
state Trace state transitions
task Trace routing protocol task processing
timer Trace routing protocol timer processing
topology Trace Layer 2 VPN and VPLS topology changes
 Sample traceoptions configuration:

protocols {
l2vpn {
traceoptions {
file file-name;
flag error detail;
flag connections detail;
flag route detail;
flag topology detail;
}
}

Layer 2 VPN Scaling and CoS

General Recommendations
 Observe PE router limits, such as total number of

Layer 2 instances and connection identifiers
 Create separate BGP route reflectors for VPN routes
•RRs must support l2vpn family
•Routes kept in bgp.l2vpn.0
 Use BGP refresh message
•RFC 2918
 Use BGP route target filtering
•RFC 4684

Layer 2 VPN Scaling Guidelines
 Maximum number of Layer 2 VPN instances

•Up to 9 k (VLAN based) depending on RE
• Successfully tested, not an architectural limit
•Increased VRFs equals longer convergence times
 Maximum number of Layer 2 VPN pseudowires
•Up to 64 k depending on the hardware installed

CoS for Layer 2 MPLS VPNs
 Similar mechanisms to those for Layer 3 VPN CoS
 Service models might be inherited from current
Layer 2 technology
•Rate based
•Loss based
•CoS based
 Control word allows preservation of Layer 2 indicators
•The Junos OS uses a null control word in most cases
• FECN, BECN, and DE translation for Frame Relay can be enabled
• ATM sequence number information carried in control word by
default (CLP and EFCI are carried in AAL5 mode is used)
• Control word can be disabled for backwards compatibility with
previous Junos OS releases

Layer 2 CoS Options
 Interface-based rate limiting (leaky bucket)
•SONET, DS3 (to or from the CE device)
•ATM traffic shaping (towards the CE device)
 Traffic engineering
•CCC connections can be mapped into RSVP LSPs that offer
various service levels
• BGP Layer 2 VPN connections can be mapped to a given LSP using
communities and routing policy
•Outer label (RSVP) can be set statically with
class-of-service knob
•VRF label can be set with firewall filter
• Enhanced FPC allows RSVP label to be set based on VRF label
•Use classifiers exp on transit and egress PE routers
• Accommodates EXP-based WRR and RED functions for labeled packets
Layer 2 VPNs: CoS and Filtering Features
 Filtering functions currently available for CCC or

Layer 2 VPNs
•Firewall filter-based counting
•Rate limiting
• Interface or logical unit level policers
•Multi-field classification
• Based on destination MAC and VLAN priority
 No support for CIR/GCRA to police Layer 2
connections
•Interface- and LSP-based rate limiting are available
• Logical unit level interface policers offer granularity that LSP-based
policing does not
Layer 2 VPN CoS Example
 VRF interface and LSP mapped to queue 2:
Configuration Results
[edit]
user@R1# show protocols mpls Ethernet II
label-switched-path PE2 { Destination: 00:d0:b7:3f:ad:d5
to 192.168.24.1; (00:d0:b7:3f:ad:d5)
class-of-service 4; Source: 00:90:69:6d:98:01
no-cspf; (00:90:69:6d:98:01)
… Type: MPLS label switched packet
[edit] (0x8847)
lab@mxB-1# show firewall MultiProtocol Label Switching Header
family ccc { MPLS Label: Unknown (100003)
filter mf-classifier { MPLS Experimental Bits: 4
term 10 { MPLS Bottom Of Label Stack: 0
then forwarding-class assured-forwarding; MPLS TTL: 255
} MultiProtocol Label Switching Header
… MPLS Label: Unknown (32768)
[edit] MPLS Experimental Bits: 4
lab@mxB-1# show interfaces ge-1/0/4 MPLS Bottom Of Label Stack: 1
… MPLS TTL: 255
unit 515 {
vlan-id 515;
family ccc {
filter {
input mf-classifier;
}

Layer 2 VPN Load Balancing
 Layer 2 VPN traffic is mapped to the PE-PE LSP with

the lowest metric
•When equal-cost LSPs exist, LSP selection is random
•LSP metric can be set manually; by default, LSP
metric = the best IGP metric
 BGP Layer 2 VPN traffic can be mapped to a particular
LSP if desired
•Use policy and community matches to select LSP at LSP
ingress

LDP Layer 2 Circuits

LDP Layer 2 Circuits: Overview
 Defined in RFC 4447

•Remote connections only
 Uses LDP for signaling
•No site IDs or route distinguishers; BGP not required
•PE-to-PE LDP sessions can be adjacent or extended
•LDP sessions can be tunneled over RSVP LSPs
 Uses CCC or TCC encapsulation
•CCC: Only like interfaces can be interconnected
•TCC: Different interface types can be interconnected
 Defines inner label as a virtual circuit label
•No VRF table/routing instance configuration
LDP Layer 2 circuit:
Virtual Circuit Label Distribution
 The PE router uses LDP to distribute a VC label for

each Layer 2 circuit defined
 PE-1 advertises labels to PE-2; PE-2 uses these labels
as the inner labels when forwarding traffic to PE-1
A VC label (FEC) is sent for every Layer 2 circuit
CE-A CE-C
Site 1 Site 3
VPN-A VPN-B
PE-1 PE-2
CE-B CE-D
P1 P2
Site 2 Site 4
VPN-B LDP Session VPN-A
(Extended)
PE-1’s Advertised Label
PE-2’s Inner Label

Virtual Circuit FEC Element
VC TLV C VC Type VC Info Length
Group ID
VC ID
Interface Parameters
““
 A virtual circuit FEC element is advertised along with

every VC label
•Used in LDP label mapping and label withdraw messages
• C bit: Specifies whether control word is present
• VC type: Specifies encapsulation type
• Group ID: Used to help withdraw multiple labels when a physical
port fails—currently set to 0 by the Junos OS
• VC ID: Administrator assigned circuit ID
• Interface parameters: Specifies the interface specifics, like MTU
LDP Extended Session
CE-A CE-C
Site 1 Site 3
VPN-A VPN-B
PE-1 PE-2
CE-B CE-D
P1 P2
Site 2 Site 4
VPN-B LDP or RSVP LSPs VPN-A
(Bidirectional)

•LDP and optionally RSVP
• LDP-signaled or RSVP-signaled LSPs must be established between
PE routers
• LDP must be enabled on the PE router loopback interfaces for
extended sessions
•Single IGP routing domain—BGP and RSVP not required
•MPLS must be enabled on PE and P router core interfaces
Provisioning the CE Device
In Out VLANs
10/8 VLAN 63 63
CE-D
Core
20/8 VLAN 75
30/8 VLAN 82 75
82

•Configure Layer 2 circuit IDs—one for each remote CE device
• VLAN IDs must be the same at both ends (unless you are using TCC
encapsulation)
•Configure Layer 2 parameters, like keepalives and MTUs
•Configure CE device’s Layer 3 properties and routing
protocols
Provisioning the PE Router
 A LDP Layer 2 circuit is configured for each Layer 2

connection
•Similar to CCC, but with label stacking
• Remote neighbor
• Interface being connected
• Virtual circuit ID must be the same at both ends of the connection
•Encapsulation is not configured under the l2circuit
 Interface configuration
•Interface must support CCC or TCC encapsulation
• Encapsulation method determines Layer 2 circuit encapsulation
• Configured Layer 2 parameters must be compatible with local CE
device

Example LDP Layer 2 Circuit: Topology
•LDP is configured on P and PE routers
• PE routers must run LDP on loopback interface
•CE devices running OSPF Area 0
• Ethernet encapsulation
Provider Core
Site 1 OSPF Area 0 Site 2
OSPF Area 0 OSPF Area 0
R1 R2 R3
Site 1 .1 .1 .2 .2 .1 .2 Site 2
10.0.10.0/24 172.22.210.0/24 172.22.212.0/24 10.0.10.0/24
CE-A PE P PE CE-B
lo0 192.168.11.1 lo0 192.168.1.1 lo0 192.168.1.3 lo0 192.168.11.2

Example LDP Layer 2 Circuit: Configuration
 R1’s l2circuit configuration:
•LDP Layer 2 circuits are defined at the
[edit protocols l2circuit] hierarchy
[edit protocols l2circuit]
user@R1# show
neighbor 192.168.1.3 {
virtual-circuit-id 4;
}
}
 R1’s LDP configuration:

user@R1# show
interface lo0.0;

Example LDP Layer 2 Circuit:
PE-CE Interface
 R1’s Layer 2 circuit PE-CE interface configuration:

user@R1# show
vlan-tagging;
unit 512 {
vlan-id 512;
}
 CE-A’s CE-PE interface configuration:

user@CE-A# show
vlan-tagging;
unit 512 {
vlan-id 512;
family inet {
address 10.0.10.1/24;
}
}

Layer 2 Interworking Stitching
BGP Layer 2 VPN LDP Layer 2 circuit
10.0.11.0/24 10.0.11.0/24
.1 .2 Site 2
Site 1
ge-1/0/4 ge-1/0/4
lo0 192.168.1.1 lo0 192.168.1.3
PE2
lo0 192.168.1.2
 Layer 2 interworking interface uses the Junos OS to

stitch together both Layer 2 VPN routes
•Include the iw0 statement under [edit interfaces]
hierarchy
• The logical Interfaces must be associated with the endpoints of a
Layer 2 circuit and Layer 2 VPN connections
•Layer 2 interworking l2iw protocols must be configured

Stitching: Interface Configuration
 The iw0 interface is configured under the
[edit interfaces] hierarchy
 The encapsulation and vlan-id must be the
same as the remote end of the VPN and circuit
[edit interfaces]
user@PE2# show
iw0 {
unit 0 {
mtu 1514;
vlan-id 610;
peer-unit 1;
}
unit 1 { MTU is configured to be the same as the
encapsulation vlan-ccc; remote PE to CE interface
mtu 1514;
vlan-id 610;
peer-unit 0;
}
}

Stitching: VPN and Circuit Configurations
 The iw0 interface must be configured under both the

Layer 2 VPN instance and the Layer 2 circuit using
separate units
[edit routing-instances vpn-1] [edit protocols]
user@PE2# show user@PE2# show
instance-type l2vpn; l2iw;
interface iw0.0; ...
route-distinguisher 192.168.1.2:1; l2circuit {
vrf-target target:65512:1; neighbor 192.168.1.3 {
protocols { interface iw0.1 {
l2vpn { virtual-circuit-id 1;
encapsulation-type ethernet-vlan; }
site vpn-a { }
site-identifier 2; }
interface iw0.0 {
remote-site-id 1;
}
}
}
}

LDP Layer 2 Circuit: Troubleshooting
• Core problems often indicated by inability to establish IGP sessions
or PE-PE LSPs
•Physical Layer, Data Link Layer, IGP, MPLS, l2circuit
configuration
 Difficulty caused by inability to conduct PE-CE pings
•Can be difficult to determine operational status of PE-CE link
•Watch for mismatched DLCIs/VCIs/VLAN IDs on PE-CE link
•VLAN IDs must be the same end to end (unless you use TCC
encapsulation)


routers?
•Is lo0 configured for protocol LDP?
•Is the virtual circuit ID correct on both PEs?
•Does MPLS ping complete?

Confirming LDP Operation (1 of 2)
 show ldp neighbors operational mode
command:
•The R1 PE router has an extended neighbor relationship to
the remote R3 PE router
user@R1> show ldp neighbor

Address Interface Label space ID Hold time
172.22.210.2 ge-1/0/0.210 192.168.1.2:0 14
192.168.1.3 lo0.0 192.168.1.3:0 32

Confirming LDP Operation (2 of 2)
 show ldp database operational mode command:
•Labels are associated with L2CKT for extended LDP
neighbor
user@R1> show ldp database
Input label database, 192.168.1.1:0--192.168.1.3:0
Label Prefix
300240 192.168.1.1/32
300160 192.168.1.2/32
3 192.168.1.3/32
300256 L2CKT CtrlWord VLAN VC 4
Output label database, 192.168.1.1:0--192.168.1.3:0

Label Prefix
3 192.168.1.1/32
299776 192.168.1.2/32
299824 192.168.1.3/32
299840 L2CKT CtrlWord VLAN VC 4
...

Displaying Layer 2 Circuit Connections
 show l2circuit connections
operational mode command:
user@R1> show l2circuit connections
Layer-2 Circuit Connections:

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 XX -- unknown

Up -- operational
Dn -- down
Neighbor: 192.168.1.3
Interface Type St Time last up # Up trans
ge-1/0/4.512(vc 4) rmt Up Oct 5 16:23:16 2010 1
Remote PE: 192.168.1.3, Negotiated control-word: Yes (Null)
Negotiated PW status TLV: No
Local interface: ge-1/0/4.512, Status: Up, Encapsulation: VLAN
 Is the Physical Layer up?

•Physical Layer alarms
•Frame Relay LMI/ATM ILMI and OAM cells
•Lack of IP connectivity between PE-CE makes conventional
troubleshooting problematic
 Are compatible circuit IDs provisioned?
 Pings and CE access
•Separate logical unit with compatible IP addressing

LDP Layer 2 Circuit: Traceoptions
 Example tracing configuration and trace output:

[edit protocols l2circuit]
user@R1# show
traceoptions {
file l2circuit-log;
flag connections detail;
flag fec detail;
}
neighbor 192.168.1.3 {
virtual-circuit-id 4;
}
}
user@R1> show log l2circuit-log

Oct 5 17:24:24 trace_on: Tracing to "/var/log/l2circuit-log" started
Oct 5 17:24:24.148881 New policy call for L2CKT from l2ckt.0
Oct 5 17:24:24.148927 [add] l2circuit VC l2ckt_vc_adv_recv (cw-bit 1, encaps VLAN, vc-
id 4,label 300256, mtu 1500, cb-size 0, vlan-id 512, TDM payload size 0 bytes, TDM
bitrate 0 (xDS0)) received from PE 192.168.1.3
Oct 5 17:24:24.148953 [l2ckt_vc_adv_recv] Adv received for active pw from neighbor
192.168.1.3
Oct 5 17:24:24.148983 [l2ckt_vc_adv_recv] Intf ge-1/0/4.512 (VC-ID 4) updated from
signalled info: label 300256, encaps VLAN, cw-bit 1, mtu 1500, cb-size 0, TDM payload
size 0 (bytes), TDM bitrate 0 (xDS0) vlan-id 512
...

Circuit Cross Connect: Overview
 CCC Connects two Layer 2 sites

•Supports:
• PPP, Cisco HDLC, Frame Relay, ATM, and VLAN 802.1Q
•Based on Layer 2 circuit ID
• Carries any protocol
• Connects only like interfaces (for example, Frame Relay to Frame
Relay, or ATM to ATM)
 Three types of cross-connects:
•Layer 2 switching
•MPLS tunneling
•Stitching MPLS LSPs

CCC MPLS Interface Tunneling (1 of 2)
Provider Core
OSPF Area 0
Site 1 Site 2
OSPF Area 0 LSP 1 OSPF Area 0
R1 R2 R3
.1 .1 .2 .2 .1 .2 Site 2
Site 1
10.0.10.0/24 172.22.210.0/24 172.22.212.0/24 10.0.10.0/24
CE-A VLAN 610 PE P PE VLAN 610 CE-B
lo0 192.168.11.1 lo0 192.168.1.1 LSP 2
lo0 192.168.1.3 lo0 192.168.11.2
 Transports packets from one interface through an

MPLS LSP to a remote interface
•Requires two dedicated LSPs for each CCC instance
• Label stacking is not supported
•Supports tunneling between two like interfaces, such as
ATM, Frame Relay, PPP, Ethernet and Cisco HDLC
•Bridges Layer 2 packets from end to end
CCC MPLS Interface Tunneling (2 of 2)
Provider Core
OSPF Area 0
Site 1 Site 2
OSPF Area 0 LSP-1 OSPF Area 0
R1 R2 R3
.1 .1 .2 .2 .1 .2 Site 2
Site 1
10.0.10.0/24 172.22.210.0/24 172.22.212.0/24 10.0.10.0/24
CE-A PE P PE CE-B
lo0 192.168.11.1 lo0 192.168.1.1 LSP-2
lo0 192.168.1.3 lo0 192.168.11.2

user@R1# show user@R3# show
connections { connections {
remote-interface-switch vpn-a { remote-interface-switch vpn-a {
transmit-lsp LSP-1; transmit-lsp LSP-2;
receive-lsp LSP-2; receive-lsp LSP-1;
} }
} }

Caveats for CCC
 CCC caveats:
•VLAN tagging at physical interface
• VLAN 0-511 allowed on unit for standard 802.1Q VLAN tagging
• VLAN 512-4094 are the only valid VLAN IDs for CCC encapsulation
•Frame Relay: Encapsulates frame-relay-ccc at physical
interface
• DLCI 1-511 allowed on unit for normal Frame Relay
• DLCI 512-1022 on unit is CCC Frame Relay
•Layer 2 switching cross-connect: PPP and HDLC must be
unit 0
•ATM: Cannot configure family on unit if atm-ccc-vc-mux
encapsulation is set

Virtual Private LAN Service

Layer 2 Provider-Provisioned VPNs
PE
P P CE
CE VPN A
VPN A
Site 2
Site 1
VLAN
VLANs
PE CE VPN A
VLAN
PE VLAN Site 4
VPN A CE
Site 3
 Layer 2 VPNs and Layer 2 circuits offer point-to-point

Ethernet, Frame Relay, ATM, PPP, or Cisco-HDLC
service
 Administrator of PE router maps local circuit IDs to
remote sites
Virtual Private LAN Service (VPLS)
PE
CE P P CE
VPN A
VPN A
Site 2
Site 1
PE CE VPN A
VPN A Site 4
CE PE
Site 3
 To the customer in a VPLS environment, the provider’s

network appears to function as a single LAN segment
•Acts similarly to a learning bridge
 Administrator does not need to map local circuit IDs to
remote sites
•PE device learns MAC address from received Layer 2 frames
•MAC addresses are dynamically mapped to outbound MPLS
LSPs and/or interfaces
References
 Standards for VPLS:

•RFC 4761
• K. Kompella and Y. Rekhter, Virtual Private LAN Service (VPLS)
Using BGP for Auto-Discovery and Signaling
•RFC 4762
• Lasserre, V. Kompella, et. al., Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP) Signaling
•Primary Difference:
• RFC 4761 uses M-BGP for signaling
• RFC 4762 uses LDP for signaling
• Juniper supports both

Benefits of BGP Signaling
 Benefits:
•Auto-discovery
• Provision VPNs as a whole versus building them circuit by circuit
•Scalable protocol
• Meant to handle lots of routes
• Route reflectors/confederations for hierarchy
• Designed to work across autonomous systems
•Mechanisms to provide all VPNs types via Multiprotocol BGP
(MP-BGP, RFC 2858)

Different Device Roles in a VPLS
CE-A
VPN-A PE-1 PE-2 CE-C
VPN-A
VLAN
CE-B P P
VPN-B PE-3 CE-D

VPN-B
VLAN
 Different device roles P P
•CE device:
• Ethernet used at both ends of a VPN
•PE routers:
• Maintain and exchange VPN-related information with other PE
routers
• Performs MAC learning function
• Use MPLS LSPs to carry VPN traffic between PE routers
•P routers:
• Forward VPN traffic transparently over established LSPs
• Do not maintain VPN-specific forwarding information
Provisioning the Local CE Device
In Out VLANs
CE-D
10/8 VLAN 512 512
Core
20/8 VLAN 513
30/8 VLAN 514 513
514

•Provider-facing interface must be Ethernet interface or
Ethernet using VLANs
•List of VLANs: One for each VPLS
•VLANs independently numbered for each VPLS
• VLAN IDs must be the same at both ends
•No changes needed as VPN membership changes
• Unless new VLAN is wanted
•Configuration of Layer 3 properties and routing protocols

BGP VPLS Route and Forwarding Tables
A VRF and a MAC table are
created for each CE
connected to the PE
VPN A
VPN A CE–A2 Site 2
Site 1 CE–A1 P P
VPN B
VPN B PE2 CE–B2 Site 2
Site 1
PE1
CE–A3
CE–B1 PE3 VPN A
P P
Site 3
 Each VPLS uses two tables

•Routing Table (VRF)
• Local label blocks and those blocks learned from remote PEs
•MAC table
• Used to forward layer 2 data and store learned MAC address for
the VPLS
CE-A CE-C
Site 1 Site 2
VPN-A VPN-B
PE-1 PE-2
CE-B CE-D
P1 P2
Site 1 Site 4

•LSPs between PE routers must be preestablished
• Can use either RSVP or LDP
• Can use LSPs for many services (for example, Internet, Layer 2
VPN, Layer 3 VPN)
•Between PE routers, full-mesh MP-IBGP or use of RRs must
be configured to support the sessions with l2-vpn family
BGP VPLS Label Distribution
VPLS label information is distributed
for each VPN site to each
participating PE routers
VPN B CE-1
MP-IBGP Session CE-2 VPN B
PE-1 PE-2
Site 1 Site 2
VRF VRF
CE-3 CE-4
VPN A VRF VRF
VPN A
Site 1 Site 2
 The PE routers distribute VPLS to label mapping

information using MP-IBGP
•BGP-based VPLS uses same NLRI as Layer 2 VPNs
•Instead of sending individual advertisements for each
remote site, labels are advertised in blocks
• Remote PE uses simple mathematics to determine outgoing label
Provisioning Customer Site on PE Router
 PE Provisioning
•VPLS routing instance
•Route Target BGP community
•Site ID: Unique value in the context of a VPLS
•Site range: Maximum number of CE devices
to which it can connect
• Label base: Label assigned to the first sub-interface ID—the PE
router reserves n contiguous labels, where n is the CE device range
•Remote sites: Learned dynamically (described later)
• The PE router forwards frames to the remote sites using the labels
learned via MP-IBGP
•Layer 2 encapsulation on VPN interfaces must be VPLS

BGP VPLS NLRI
Length (2 Bytes)
 PE initially advertises a single Route Distinguisher (8 Bytes)
Site ID (2 Bytes)
VPLS NLRI for each VPLS Label Block Offset (2 Bytes)
instance in which it participates Label Base (3 Bytes)
•Each NLRI defines labels Circuit Status Vector (Variable)
(demultiplexors) for a range of

other PE routers in the VPLS
•If new labels must be added to existing VPLS, additional
NLRI is sent
•Same AFI and SAFI (25/65) as L2 VPN NLRI
•PE router encapsulation and capabilities are signaled in
Layer 2 information extended community

Layer2 Info Extended Community
Community Type (2 Bytes)
 Signals control information Encapsulation Type (1 Byte)
about the VPLS Control Flags (1 Byte)
•Community type is set to 0x800A Layer-2 MTU (2 Bytes)
Preference (2 Bytes)
•Encapsulation Type is VPLS (19)
•Control Flags - 2 bits used
• C-bit – Control word must be used if set to 1
• S-bit – Sequenced delivery of frames is necessary if set to 1
• All zeros by default
•Layer 2 MTU
•Preference – Used to specify the preference of the local site
• Value is also copied to BGP local preference by default

Automatic Label Calculation
Note: Sites CE-A2 and CE-A3 are not shown.
MPLS LSP 200

PE-1 PE-2
CE-A1 CE-A4
VPN A VRF VRF
VPN A
Site 1 VLAN
VLAN Site 4
600
600
PE-1’s NLRI for Site 1 PE-2’s VPLS MAC FT for VPN A
R-Target RT1 MACs learned Outer Inner Rx PE-2’s NLRI for Site 4
Site ID 1 from remote site Tx Label Tx Label Label R-Target RT1
Range 8 Advertised Site ID 4
1 200 2003 1000
Label base 2000 using L2 VPN Range 8
2 1001
Label Offset 1 AFI and SAFI Label base 1000
3 1002 Label Offset 1
 PE-1 and PE-2 configured for a VPLS called VPN A

between Site 1 and 4
 PE-2 computes transmit and receive VRF labels
•Tx Label = Remote Base + Local Site ID – Remote Offset
•Rx Label = Local Base + Remote Site ID – Local Offset

Distributing VPLS NLRI
 Distribution uses MP-IBGP for auto-discovery of members
•PE router advertises the VPLS instances to which it is attached
•PE router advertises the VPLS instances to which it is no longer
attached
•PE router discovers which VPLS instances are running on other
PE routers
 Mapping of inbound and outbound labels to sites is
automatic
•For each remote site a VT interface is created dynamically
•Receive label for each remote site is mapped to the VT interface
• VT interface is used in forwarding process described in future pages
• Ethernet frames arriving from provider’s core are passed through VT
interface (Tunnel Services PIC) so that they can be forwarded based on
MAC address
• Allows PE device to also learn MAC addresses from received Ethernet
frames
 VPN policy used to determine VPLS membership
Updating VRFs (1 of 3)
PE-2 VRF CE-A2
Full Mesh VPN A
IBGP Sessions Site 2
VLAN
VRF 600
CE-A1
VPN A VRF CE-A3
Site 1 VLAN PE-1
600 VLAN VPN A
PE-3 600 Site 3
CE-A3 l2vpn NLRI update

R-Target RT1
Site ID 3
Range 4
Label Base 1000
Offset 1
 PE-1 receives BGP update from PE-3 for site 3

•NLRI contains label block information that PE-3 has
dedicated to the VPLS

PE-2 VRF CE-A2
VPN A
MPLS LSPs Site 2
VLAN
VRF 200 600
CE-A1
VPN A 300 VRF CE-A3
Site 1 VLAN PE-1
600 VLAN VPN A
PE-3 600 Site 3
Site 1’s MAC Forwarding Table
MACs learned Outer Assumes similar label block advertisement
Inner
from remote site Tx Label Tx Label has been received from PE-2
2 200 2000
3 300 1000 Label used to reach Site 3
 PE-1 updates its VRF with PE-3 NLRI

•Import route target (RT1) for PE-1’s VRF matches route target
carried by the BGP route
•NLRI copies into bgp.l2vpn.0 and vpn-name.l2vpn.0
 PE-1 computes outgoing label for traffic sent to Site 3
•(local-site-id + remote-label-base – remote-label-offset = 1000)
•PE3 computes same label for received traffic from Site 1
PE-2 VRF CE-A2
VPN A
MPLS LSPs Site 2
VLAN
VRF 200
CE-A1 600
VPN A 300 VRF CE-A3
Site 1 VLAN PE-1
600 VLAN VPN A
PE-3 600 Site 3
Site 1’s MAC Forwarding Table
MACs learned Outer Inner
from remote site Tx Label Tx Label
2 200 2000
3 300 1000
Calculated during BGP
recursive route lookup
 PE-1 obtains the outer label by resolving PE-3’s host

address through an RSVP or LDP LSP

LDP VPLS Label Distribution
A VC label (FEC) is sent for every VPLS
VPN B CE-1 Extended LDP Session CE-2 VPN B

PE-1 PE-2
Site 1 Site 2
CE-3 CE-4
VPN A VPN A
Site 1 Site 2
PE-1’s Advertised Label
PE-2’s Inner Label
 The PE routers distribute VPLS to label mapping

information using LDP
•Junos OS only supports FEC 128, Control bit 0, and Ethernet
pseudowire type
•For each VPLS you must configure a full mesh of LDP
session between participating PE routers.
•PE-1 advertises labels to PE-2; PE-2 uses these labels as the
inner labels when forwarding traffic to PE-1
VPLS FEC Element
VC TLV C VC Type VC Info Length
Group ID
VC ID
Interface Parameters
““
 A VPLS FEC element is advertised along with every VC

label
•Used in LDP label mapping and label withdraw messages
• C bit: Specifies whether control word is present
• VC type: Specifies encapsulation type
• Group ID: Used to help withdraw multiple labels when a physical
port fails—currently set to 0 by the Junos OS
• VC ID: Administrator assigned circuit ID
• Interface parameters: Specifies the interface specifics, like MTU
PE Forwarding: Inbound from CE
VT Interface dynamically created RE FT: vpn-name.vpls
for each learned remote 0x30002/51 flood to all CEs (local and remote)
site (not used for packets 0x30003/51 flood to all CEs (local only)
00:90:69:68:55:55/48 nh so-0/0/0.0, push, push
inbound from CE device)
00:90:69:68:54:00/48 nh fe-0/1/0.600
PFE 3 Local CE device's MAC is

IP II
learned and placed in
vt-0/2/0.32768 forwarding table
2
PIC Tunnel PIC FE PIC SO PIC

so-0/0/0.0
Ethernet Frame fe-0/1/0.600
1
IP VLAN SA DA
600 To core
Ethernet Frame
IP VLAN
SA DA MPLS MPLS
CE 600
4
DA = Remote CE device’s MAC (00:90:69:68:55:55)
SA = Local CE device’s MAC (00:90:69:68:54:00)

PE Forwarding: Inbound from Core
FT: vpn-name.vpls
RE
0x30002/51 flood to all CEs (local and remote) FT: mpls.0
0x30003/51 flood to all CEs (local only)
100000 pop, nh vt-0/2/0.32768
00:90:69:68:54:00/48 nh fe-0/1/0.600
00:90:69:68:55:55/48 nh so-0/0/0.0, push, push
PFE 3
Remote CE’s MAC is 2
learned (if not already
IP II
known) and placed in vt-0/2/0.32768
forwarding table
4
PIC Tunnel PIC FE PIC PIC

so-0/0/0.0
fe-0/1/0.600
Ethernet Frame 1
5 VLAN SA DA To core
IP
600 IP VLAN
SA DA MPLS
600
CE SA = Remote CE device’s MAC (00:90:69:68:55:55)
DA = Local CE device’s MAC (00:90:69:68:54:00)

Data Flow and MAC Learning (1 of 10)
CE-A2
PE-2 VPN A
MPLS LSPs Site 2
VLAN
200 600
CE-A1
VPN A 300 CE-A3
VLAN
Site 1 PE-1
600 VLAN VPN A
PE-3 600 Site 3
Ethernet Frame
ARP Req VLAN SA DA
600 1.1.1.1
DA = ff:ff:ff:ff:ff:ff
SA = CE-A1’s MAC
 CE-A1 attempts to ping CE-A3’s interface

•CE-A1 does not know the MAC address of 1.1.1.1, so CE-A1
must send ARP request

MPLS label (200)
Site label (2000) PE-2 CE-A2
VPN A
Frame Site 2
PE-1 VLAN
200
CE-A1 600
VPN A 300 CE-A3
Site 1 VLAN
600 MPLS label (300) VLAN VPN A
PE-3 600 Site 3
Site label (1000)
Frame
 PE-1 learns CE-A1’s MAC from the frame and maps

that MAC address to VPLS interface for return traffic
•Entry added to MAC table called vpn-name.vpls
 Ingress PE router replicates and floods the frame to all
sites (broadcast DA)
•Forwarding lookup is performed in MAC table vpn-
name.vpls

 PE router forwarding is based on the interface a

packet is received on and its destination MAC address
•MAC address learning:
• Associates source MAC address with receiving port or remote PE
router
• Qualified learning: Based on MAC address and VLAN tag
• Unqualified learning: Based on MAC address alone
•Flooding
• Broadcast/Unknown/Multicast destination MAC address: Forward
to all ports and PE routers associated with the VPLS of the
receiving interface
• Known destination MAC address (in FIB—vpn-name.vpls):
Unicast to associated interface or PE router

MPLS label (201)
Site label (2000)
CE-A2
Frame PE-2 VPN A
Site 2
VLAN 600
201
CE-A1
VPN A 301 CE-A3
Site 1 VLAN 600 PE-1
MPLS label (301) VLAN 600 VPN A
Site label (1000) PE-3 Site 3
Frame
 MPLS switching by LSRs in the core

•Outer label swapped at each LSR

Site label (2000)
Frame
Penultimate
Hop Popping CE-A2
PE-2 VPN A
Site 2
VLAN 600
CE-A1
VPN A CE-A3
VLAN 600 VPN A
PE-3 Site 3
Site label (1000)
Frame
 The outer label is removed through penultimate hop

popping

ARP Req VLAN SA DA
600
CE-A2
PE-2 VPN A
Site 2
VLAN 600
CE-A1
VPN A CE-A3
VLAN 600 VPN A
PE-3 Site 3
ARP Req VLAN SA DA
600
 The egress PE router does a label lookup in mpls.0

to find the corresponding next hop (VT interface)
•The label is popped by the egress PE router and sent to VT
interface (Tunnel Services/ASP/Link Services PIC)
•Allows egress routers to learn the CE-A1’s MAC address
from Ethernet frame (MAC-to-LSP mapping stored in
vpn-name.vpls) and then forward out VPLS interfaces
ARP Req VLAN SA DA
600
CE-A2
PE-2 VPN A
Site 2
VLAN 600
CE-A1
VPN A CE-A3
VLAN 600 VPN A
PE-3 Site 3
ARP Req VLAN SA DA
600
 Because the frame is a broadcast frame, both CE-A2

and CE-A3 analyze the contents
•CE-A2 discards the frame
•CE-A3 responds with ARP reply

CE-A2
PE-2 VPN A
Site 2
VLAN 600
CE-A1
VPN A CE-A3
MPLS LSP label VLAN 600 VPN A
Site 1 Label PE-3 Site 3
Frame ARP Reply VLAN SA DA
600
DA = CE-A1’s MAC
SA = CE-A3’s MAC
 PE-3 receives Ethernet frame from CE-A3

and performs a lookup in vpn-name.vpls
•Because it previously learned that CE-A1’s MAC address is
located at Site 1, PE-1 sends the Ethernet frame directly to
PE-1 using MPLS encapsulation
•Flooding frame to all remote PE routers is not required when
MAC address is learned and stored in VPLS FIB
Penultimate
CE-A2
Hop Popping PE-2 VPN A
Site 2
VLAN 600
CE-A1
VPN A CE-A3
VLAN 600 VPN A
Site 1 Label PE-3 Site 3
Frame
 PE-1 does a label lookup in mpls.0 to find the

corresponding next hop (VT interface)
•The inner label is popped by the egress PE router and sent
to VT interface (Tunnel Services/ASP/Link Services PIC)
•Allows egress routers to learn the CE-A1’s MAC address
from Ethernet frame (MAC-to-LSP mapping stored in
vpn-name.vpls) and then perform second lookup to
forward frame out of the VPLS interface

CE-A2
PE-2 VPN A
Site 2
VLAN 600
CE-A1
VPN A CE-A3
VLAN 600 VPN A
PE-3 Site 3
Echo Requests
Echo Replies
 Any future traffic between CE-A1 and CE-A3 no longer

must be flooded as in initial data flow
•CE and PE routers have learned MAC addresses of both CE
devices
•The vpn-name.vpls table on both PE-1 and PE-3 have
dynamically installed forwarding entries for inbound and
outbound traffic based on MAC addresses learned

Relieve PE1 of BUM Replication Duties
Replication with no Penultimate
Hop Popping PE-2 CE-A2
VPN A
Site 2
PE-1 VLAN
200
CE-A1 600
VPN A CE-A3
Site 1 VLAN
600 P2MP label (200) VLAN VPN A
PE-3 600 Site 3
Frame
 P2MP LSPs can be used instead of unicast LSPs to

forward BUM traffic
•Ingress PE no longer has to perform all of the replication of
BUM traffic
•Can be used in BGP VPLS scenario only
• P2MP LSP to VPLS mapping is performed with the readvertisement of
an ingress PE’s label blocks with the PMSI Tunnel attribute

Network Assumptions
 PEs are fully meshed

•MPLS LSPs established by LDP or RSVP
•Tunnels can also be GRE
 Full mesh enables split-horizon behavior
•No PE forwards a packet from a remote PE router to another
remote PE router
•Reduces need for Spanning Tree Protocol (STP) in provider
network
 PE routers perform MAC learning and flooding
•But no PE router requests another PE router to flood or learn
on its behalf

Potential Layer 2 Loops (1 of 2)
PE-2 CE-A2
CE-A1 VPN A
VPN A Site 2
Site 1 PE-1
 Redundant links between a CE and PE

•Solutions
• Configure active/backup links on PE-2 (BGP VPLS only)
• Configure LAG between PE-2 and CE-A2
• Configure ERP between PE-2 and CE-A2
• Run a spanning tree protocol between PE-2 and CE-A2

Potential Layer 2 Loops (2 of 2)
PE-2
CE-A2
CE-A1 VPN A
VPN A Site 2
Site 1 PE-1
PE-3
 Multihomed CE with two different PEs

•Solutions
• Configure multihoming and Local Preference on PE-2 and PE-3 (BGP
VPLS only)
• Configure primary and backup neighbor (LDP VPLS only)
• Run a spanning tree protocol between PE-2, PE-3, and CE-A2

VPLS Configuration

Sample Topology
Provider Core lo0 192.168.2.2 Site 2
.1 OSPF Area 0 ge-1/0/4 .2 .2
Site 1 10.0.12.0/24
CE-A PE2 10.0.12.0/24 CE-B
lo0 192.168.11.1 lo0 192.168.11.2
PE1 PE3
lo0 192.168.2.1 P
Site 3
lo0 192.168.2.3
.3 CE-C
lo0 192.168.11.3
•CE interface addressing is 10.0.12/24 (except loopbacks)
•Full MP-IBGP mesh between PE routers, loopback peering,
•Ethernet VPLS between CE-A, CE-B, and CE-C (VLAN 515)
PE Interface Configuration
ge-1/0/5 { PE1’s Gibabit Ethernet
vlan-tagging; configuration from sample
encapsulation vlan-vpls;
unit 515 { topology with vlan-
encapsulation vlan-vpls; tagging enabled
vlan-id 515;
family vpls;
}
}
ge-0/0/1 {
encapsulation ethernet-vpls;
unit 0 {
Sample Gigabit Ethernet with
family vpls; no VLAN tagging
}
}

Creating a VPLS Routing Instance
instances] configuration hierarchy
•Selecting instance-type vpls creates a VPLS instance
type
user@PE1# set ?
> access Network access configuration
> access-profile Access profile for this instance
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> bridge-domains Bridge domain configuration
description Text description of routing instance
> forwarding-options Forwarding options configuration
instance-type Type of routing instance
> interface Interface name for this routing instance
> multicast-snooping-options Multicast snooping option configuration
no-irb-layer-2-copy Disable transmission of layer-2 copy of packets of irb
routing-interface
no-local-switching Disable local switching within CE-facing interfaces
…
BGP VPLS Signaling Configuration
 Set up BGP sessions between the PEs with Layer 2
VPN signaling enabled
user@PE1> show configuration protocols bgp
family l2vpn {
signaling;
}
type internal;
export statics;
neighbor 192.168.2.2;
neighbor 192.168.2.3;
}
user@PE1> show bgp summary

Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 0 0 0 0 0 0
inet.2 0 0 0 0 0 0
bgp.l2vpn.0 2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
192.168.2.2 65512 5 6 0 0 1:16 Establ
bgp.l2vpn.0: 2/2/2/0
vpn-a.l2vpn.0: 2/2/2/0
…
BGP VPLS Instance on PE1
 A VPLS instance called vpn-a with a single interface
is provisioned between PE1 and CE-A device:
[edit routing-instances vpn-a] [edit routing-options]
instance-type vpls; route-distinguisher-id 192.168.2.1;
interface ge-1/0/5.515; autonomous-system 65512;
protocols {
vpls {
site-range 20;
site ce-a {
site-identifier 1;
}
}
}

LDP VPLS Instance and Signaling on PE1
 A VPLS instance called vpn-a with a single interface

is provisioned between PE1 and CE-A device:

user@PE1# show
instance-type vpls;
protocols {
vpls { Each PE participating in VPLS
vpls-id 100; must be specified
neighbor 192.168.2.2;
neighbor 192.168.2.3;
}
}

lab@PE1# show Enables LDP VPLS Signaling
interface lo0.0;

Multihomed CE
.1 OSPF Area 0 ge-1/0/4 .2 .2
Site 1 10.0.12.0/24
CE-A PE2 10.0.12.0/24 CE-B
lo0 192.168.11.1 lo0 192.168.11.2
PE1 PE3
lo0 192.168.2.1 P
Site 3
lo0 192.168.2.3
.3 CE-C
lo0 192.168.11.3
 CE-B is multihomed to PE2 and PE3

• For the BGP VPLS solution, the configuration for VPLS on
PE2 and PE3 must
• Assign the same site ID to the same CE device
• Assign the same route distinguisher to the routing instances
• Configure the multi-homing statement
• For the LDP VPLS solution, loop prevention is configured on
PE1 only
BGP VPLS Multihomed CE Solution
•Allows BGP to prevent loops by configuring multihoming and
adjusting the local preference label block advertisement
• PE2 provides a single path to CE-B until a failure occurs
• PE3 will provide backup path and is notified of failure by BGP
[edit routing-instances vpn-a] [edit routing-instances vpn-a]
instance-type vpls; instance-type vpls;
route-distinguisher 192.168.2.2:1; route-distinguisher 192.168.2.2:1;
vrf-target target:65512:100; vrf-target target:65512:100;
protocols { protocols {
vpls { vpls {
site-range 20; site-range 20;
site ce-b { site ce-b {
site-identifier 2; site-identifier 2;
multi-homing; multi-homing;
site-preference 300; site-preference 100;
} }
} }
} }
LDP VPLS Multihomed CE Solution
• PE1 configured for a primary pseudowire with a backup
option
• PE2 and PE3 are not configured for a neighbor relationship
between each other, only with PE1
user@PE1# show
instance-type vpls;
Time to wait (milliseconds) before switching from
interface ge-1/0/6.515; failed primary to backup neighbor
protocols {
vpls {
vpls-id 100;
Time to wait (seconds) before switching from
neighbor 192.168.2.2 {
backup neighbor to primary, once the primary
switchover-delay 10000; becomes available again
revert-time 5;
backup-neighbor 192.168.2.3 { Optional standby configuration allows backup
standby; pseudowire to be immediately available if the
} primary fails
…

Multihomed CE to Single PE
.1 OSPF Area 0 ge-1/0/4 .2 .2
Site 1 10.0.12.0/24
CE-A PE2 10.0.12.0/24 CE-B
lo0 192.168.11.1 lo0 192.168.11.2
PE1 PE3
lo0 192.168.2.1 P
Site 3
lo0 192.168.2.3
.3 CE-C
lo0 192.168.11.3
 CE-C has multiple interfaces to PE1

• To prevent loops configure one of the following:
• Primary/Backup Interfaces (BGP VPLS only)
• LAG
• Ethernet Ring Protection
• A spanning tree protocol

Primary and Backup Interfaces (BGP VPLS)
 Configuring active- [edit]
user@PE1# show routing-instances vpn-a
interface allows the instance-type vpls;
PE have multiple interface ge-1/0/5.515;
VPLS interfaces with vrf-target target:65512:100;
protocols {
only one active vpls {
site-range 20;
site ce-a {
•If primary fails, one of site-identifier 1;
the other interfaces }
configured for the site site ce-c {

site-identifier 3;
becomes active active-interface primary ge-1/0/4.515;
• For non-revertive interface ge-1/0/4.515;
behavior set }
}
active- }
interface any

Link Aggregation
 Use link aggregation to prevent loops as well as
provide added bandwidth between PE and CE
user@PE1# show chassis
aggregated-devices { [edit]
ethernet { user@PE1# show routing-instances vpn-a
device-count 20; instance-type vpls;
… interface ge-1/0/5.515;
[edit] interface ae1.515;
user@PE1# show interfaces vrf-target target:65512:100;
ge-1/0/4 { protocols {
gigether-options { vpls {
802.3ad ae1; site-range 20;
… site ce-a {
ge-1/0/6 { site-identifier 1;
gigether-options { interface ge-1/0/5.515;
802.3ad ae1; }
… site ce-c {
ae1 { site-identifier 3;
vlan-tagging; interface ae1.515;
encapsulation vlan-vpls; }
unit 515 { }
encapsulation vlan-vpls; }
vlan-id 515;
family vpls;
Ethernet Ring Protection
 ERP is designed to provide sub-50 ms, loop-free protection to
an Ethernet ring topology
 PE1 and CE-C use VLAN 100 as the ERP control channel
[edit]
user@PE1# show interfaces [edit]
ge-1/0/4 { user@PE1# show protocols protection-group
unit 100 { ethernet-ring pg100 {
family bridge { ring-protection-link-owner;
interface-mode trunk; east-interface {
vlan-id-list 100; control-channel {
… ge-1/0/6.100;
ge-1/0/6 { vlan 100;
unit 100 { }
family bridge { }
interface-mode trunk; west-interface {
vlan-id-list 100; control-channel {
… ge-1/0/4.100;
[edit] vlan 100;
user@PE1# show bridge-domains }
bd { ring-protection-link-end;
vlan-id 100; }
} }

Spanning Tree Protocols
 Configure a layer2-control instance to run a
spanning tree protocol between PE and CE
[edit] [edit]
user@PE1# show routing-instances vpn-a user@PE1# show routing-instances l2-control
instance-type vpls; instance-type layer2-control;
interface ge-1/0/6.515; protocols {
vrf-target target:65512:100; mstp {
protocols { configuration-name site3;
vpls { revision-level 1;
site-range 20; interface ge-1/0/4;
site ce-a { interface ge-1/0/6;
site-identifier 1; msti 1 {
interface ge-1/0/5.515; vlan 1-4094;
} }
site ce-c { }
site-identifier 3; }
}
}
}

Stitching an L2VPN to a VPLS
.1 OSPF Area 0 ge-1/0/4 .2 .2
Site 1 10.0.12.0/24
lo0 192.168.2.1 PE2 10.0.12.0/24
CE-A CE-B
PE1
PE3
L2VPN P
Site 3
PE4 lo0 192.168.2.3
.3 CE-C
lo0 192.168.2.4 .4 Site 4 .1
10.0.12.0/24
CE-D
 PE4 is providing an L2VPN from CE-D to PE1 and

the customer requests that it be added to the VPLS
• Use LT interfaces to stitch the L2VPN to the VPLS

Stitch Configuration
 LT interfaces can be used to stitch either an L2VPN or
an Layer 2 Circuit to a VPLS
[edit] [edit]
user@PE1# show interfaces lt-1/0/10 user@PE1# show routing-instances vpn-a
unit 0 { instance-type vpls;
encapsulation vlan-vpls; interface ge-1/0/4.515;
vlan-id 515; interface ge-1/0/5.515;
peer-unit 1; interface ge-1/0/6.515;
} interface lt-1/0/10.0;
unit 1 { vrf-target target:65512:100;
encapsulation vlan-ccc; protocols {
vlan-id 515; vpls {
peer-unit 0; site-range 20;
} site ce-a {
[edit] site-identifier 1;
user@PE1# show routing-instances vpn-to-stitch interface ge-1/0/5.515;
instance-type l2vpn; interface lt-1/0/10.0;
interface lt-1/0/10.1; }
vrf-target target:65512:200; site ce-c {
protocols { site-identifier 3;
l2vpn { interface ge-1/0/6.515;
encapsulation-type ethernet-vlan; interface ge-1/0/4.515;
site stitch { }
site-identifier 1; …
interface lt-1/0/10.1;
BGP and LDP VPLS Interworking
BGP Signaled LDP Signaled
VPLS Mesh Group VPLS Mesh Group
10.0.12.0/24 10.0.12.0/24
.1 .2 Site 2
Site 1
ge-1/0/4 ge-1/0/4
lo0 192.168.2.1 lo0 192.168.2.2
Border Router
(PE3)
 PE3 is acting as PE router for both a BGP-signaled

and an LDP-signaled VPLS
• PE3 uses a single MAC-table to forward traffic between
mesh groups
• BUM traffic received by PE3 from the BGP-signaled mesh
group is flooded to all local CE’s (if they exist) and to the
LDP-signaled mesh group and vice versa

BGP and LDP Interworking Configuration
 Configure both BGP and LDP-signaling within the
same routing instance
•BGP – Specify RT, RD, and Site ID
• BGP neighbors are automatically placed into the default mesh
group
•LDP – Specify a user-defined mesh group with VPLS ID and
neighbors user@PE3# show routing-instances interworking
instance-type vpls;
protocols {
vpls {
site border {
site-identifier 3;
}
mesh-group ldp-sig {
vpls-id 100;
neighbor 192.168.2.2;
}
}
}

VPLS with P2MP LSPs for BUM Traffic
 Use P2MP LSPs to relieve the PE router of performing
all of the replication of BUM traffic
[edit]
user@PE1# show routing-instances vpn-a
instance-type vpls;
provider-tunnel {
rsvp-te {
label-switched-path-template {
default-template;
}
}
}
protocols {
vpls {
site-range 20;
site ce-a {
site-identifier 1;
no-tunnel-services
 LSI interface
•Used when there is no tunnel services available
•The same concept as vrf-table-label—similar restrictions

user@PE1# show
instance-type vpls;
protocols {
vpls {
no-tunnel-services;
vpls-id 100;
neighbor 192.168.2.2;
}
}

Forwarding Table with lsi
 The LSI interfaces have replaced the VT interfaces

•LSI interface is unique on per-remote site basis on every
VPLS instance
 LSI has some forwarding and statistical limitations
user@PE1> show route forwarding-table family mpls
Routing table: default.mpls
MPLS:
default perm 0 dscd 50 1
0 user 0 recv 49 3
1 user 0 recv 49 3
2 user 0 recv 49 3
262154 user 0 Pop 664 2 lsi.1048576
800257 user 0 Pop 703 2 lt-1/0/10.1
lsi.1048576 (VPLS) user 0 indr 1048576 4
172.22.220.2 Push 800000, Push 302608(top) 659 2 ge-1/0/0.220

Limit Number of MACs Learned per VPLS
 Per-instance MAC table size limit

•Default is 512 per instance

user@PE1# set protocols vpls mac-table-size ?
<limit> Maximum number of MAC addresses (16..524287)
packet-action Action when MAC limit is reached

user@PE1# set protocols vpls mac-table-size 200 packet-action ?
drop Drop packets and do not learn. Default is forward

Limit Number of MACs Learned per Interface
 Per-CE interface learnt MAC limit

•Default is the same as the MAC table size, 512
user@PE1# set protocols vpls interface-mac-limit ?
<limit> Maximum number of MAC addresses per interface
(1..131071)
packet-action Action when MAC limit is reached

user@PE1# set protocols vpls interface-mac-limit 200 packet-action ?
drop Drop packets and do not learn. Default is forward

Label Block Size
 One label block is equal to one MP-BGP L2VPN route

•Label block size can affect the number of routes that a PE
needs to send for a VPLS
• Can be set to 2,4,8, or 16
• To minimize the number of routes sent by a PE set to 16
[edit]
user@PE1# set routing-instances vpn-a protocols vpls label-block-size ?
<label-block-size> Label block size for this VPLS instance (2..16)
[edit]
user@PE1#

Frame Flooding
[edit]
user@PE1# show routing-instances vpn-a forwarding-options
family vpls {
flood {
input BUM-fw;
}
}
 Policer can be used to control
[edit]
the flood packet volume
user@PE1# show firewall
policer BUM { •That covers all Unknown Dst
if-exceeding {
bandwidth-limit 100k; MAC address frames/
}
burst-size-limit 15k;
Bcast MAC frames/
then discard; Mcast MAC frames
}
family vpls {
filter BUM-fw {
 Be careful on what to limit
term term1 {
then policer BUM;
(routing update packets
}
} between the CEs)
}

show vpls connections Legend
 Use the legend to determine the status of the VPLS
user@PE1> 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 availble
BK -- Backup connection ST -- Standby connection
PF -- Profile parse failure PB -- Profile busy
RS -- remote site standby SN -- Static Neighbor

Up -- operational
Dn -- down

VPLS Connection Status
 Get status with show vpls connections
•Use the legend to determine the meaning of the status code
•Only one connection (pseudowire) can exist between two
PEs per VPLS instance
• Although local site 3’s connection to site 2 is in LM state, it is still
able to communicate with remote sites using site 1 connection to
site 2
user@PE1> show vpls connections
…
Instance: vpn-a
Local site: ce-a (1)
2 rmt Up Oct 18 11:13:48 2010 1
Remote PE: 192.168.2.2, Negotiated control-word: No
Local interface: vt-1/0/10.1049600, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpn-a local site 1 remote site 2
Local site: ce-c (3)
2 rmt LM

Flood Routes
 View the flood routes to determine which interfaces
are actively being used for flooding
user@PE1> show vpls flood extensive
Name: __juniper_private1__
CEs: 0
VEs: 0
Name: vpn-a
CEs: 4
VEs: 1
Flood route prefix: 0x30004/51
Flood route type: FLOOD_GRP_COMP_NH
Flood route owner: __ves__
Flood group name: __ves__
Flood group index: 0
Nexthop type: comp
Nexthop index: 734
Flooding to:
Name Type NhType Index
__all_ces__ Group comp 715
Composition: split-horizon
Flooding to:
Name Type NhType Index
ge-1/0/4.515 CE ucst 658
ge-1/0/5.515 CE ucst 659
ge-1/0/6.515 CE ucst 663
lt-1/0/10.0 CE ucst 679

MAC Table
 View the MAC table to determine what MAC
addresses are being learned
user@PE1> show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC,

SE -Statistics enabled, NM -Non configured MAC)
Routing instance : vpn-a

Bridging domain : __vpn-a__, VLAN : NA
MAC MAC Logical
address flags interface
80:71:1f:c3:07:7d D ge-1/0/5.515
80:71:1f:c3:07:7f D ge-1/0/4.515
80:71:1f:c3:4c:7e D lt-1/0/10.0
80:71:1f:c3:4c:7f D vt-1/0/10.1049600

VPLS Statistics
 View the statistic to see valuable information about
the traffic being forwarded by the VPLS
user@PE1> show vpls statistics
VPLS statistics:
Instance: vpn-a
Local interface: vt-1/0/10.1049600, Index: 68
Remote PE: 192.168.2.2
Broadcast packets: 3
Broadcast bytes : 180
Multicast packets: 0
Multicast bytes : 0
Flooded packets : 0
Flooded bytes : 0
Unicast packets : 15
Unicast bytes : 1530
Current MAC count: 1
Local interface: ge-1/0/4.515, Index: 78
Broadcast packets: 321
Broadcast bytes : 19260
Multicast packets: 0
Multicast bytes : 0
Flooded packets : 0
Flooded bytes : 0
Unicast packets : 42343
Unicast bytes : 4316382
Current MAC count: 1 (Limit 1024)
Label Block Advertisements
 View the BGP routes in the VPLS VRF
user@PE1> show route table vpn-a extensive
vpn-a.l2vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

RD:Site #:Offset
192.168.2.2:1:2:1/96 (1 entry, 1 announced)
Source: 192.168.2.2
Indirect next hop: 2 no-forward
State: <Secondary Active Int Ext>
Age: 31:06 Metric2: 1
Task: BGP_65512.192.168.2.2+179
Announcement bits (1): 0-vpn-a-l2vpn
AS path: I
Communities: target:65512:100 Layer2-info: encaps:VPLS, control
flags:, mtu: 0, site preference: 300
Import Accepted
Label-base: 800000, range: 8
Localpref: 300
Router ID: 192.168.2.2
Primary Routing Table bgp.l2vpn.0
Indirect next hops: 1
MPLS Forwarding Table
 mpls.0 is used first by the PE router to forward
incoming VPLS traffic from the core
user@PE1> show route table mpls.0

0 *[MPLS/0] 3d 06:53:48, metric 1

Receive
1 *[MPLS/0] 3d 06:53:48, metric 1
Receive
2 *[MPLS/0] 3d 06:53:48, metric 1
Receive
800009 *[VPLS/7] 00:37:22
> via vt-1/0/10.1049600, Pop
Arriving packets have MPLS header popped

and sent to Services PIC using VT interface

VPLS Forwarding Table
 vpn-name.vpls is used by the PE router to forward
incoming VPLS traffic from the VT interfaces (core)
and the CEs
•Learned MAC address are stored here as well
user@PE1> show route forwarding-table family vpls
Routing table: vpn-a.vpls
VPLS:
default perm 0 dscd 523 1
vt-1/0/10.1049600 intf 0 indr 1048575 5
172.22.220.2 Push 800000, Push 302608(top) 706 2 ge-1/0/0.220
0x30004/51 user 0 comp 734 2
80:71:1f:c3:07:7d/48 user 0 ucst 659 5 ge-1/0/5.515
80:71:1f:c3:07:7f/48 user 0 ucst 658 5 ge-1/0/4.515
80:71:1f:c3:4c:7e/48 user 0 ucst 664 3 lt-1/0/10.0
80:71:1f:c3:4c:7f/48 user 0 indr 1048575 5
172.22.220.2 Push 800000, Push 302608(top) 706 2 ge-1/0/0.220
ge-1/0/4.515 intf 0 ucst 658 5 ge-1/0/4.515
ge-1/0/5.515 intf 0 ucst 659 5 ge-1/0/5.515
ge-1/0/6.515 intf 0 ucst 663 4 ge-1/0/6.515
lt-1/0/10.0 intf 0 ucst 664 3 lt-1/0/10.0
0x30002/51 user 0 comp 723 2
0x30001/51 user 0 comp 720 2

Interprovider Backbones

Hierarchical VPN Models
 Carrier-of-carriers model
Customer Customer External
External Site 1 Service Site 2 Routes
Routes Provider A
PE P PE
ASBR CE CE ASBR
LSP
Global Addressing Global Addressing
 Interprovider VPN model
Provider 1 Provider 2 Customer
Customer
Site 1 Site 2
PE-C1 ASBR ASBR PE-C2

LSP LSP
Private Addressing Private Addressing

Carrier-of-Carriers VPN Support
 Carrier-of-carriers and VPN integration
External External
Customer Customer
VPN VPN
Site 1 Service Site 2
Routes Routes
Provider A
PE P PE
PE-C1 CE-1 CE-2 PE-C2
LSP (ASBR)
(ASBR)
LSP LSP
Private Private
Addressing Addressing

Interprovider VPNs: Option A
 Option A describes EBGP VRF table-to-VRF table

operation between ASBRs
•Serious scalability issues
• Separate VRF table required for each VPN
• Provider PE router must house all customer VPN routes
•Inherently supported by the Junos OS
VPN B Unlabeled VPN routes VPN B
Site 1 Site 2
ASBR-1 ASBR-2
PE-1 P-1 P-2 PE-2
EBGP
VPN A
SP 1 SP 2 VPN A
Site 1 Site 2

Interprovider VPNs: Option B
 Option B describes MP-EBGP-labeled route
distribution between ASBRs
•Better than Option A as ASBRs do not need per-VPN VRF
tables
•Still has scalability issues
• Requires that ASBRs carry VPN routes and state for transit MPLS
sessions
Labeled VPN Routes
VPN B VPN B
MP-IBGP MP-IBGP Site 2
Site 1
ASBR-1 ASBR-2
PE-1 P-1 P-2 PE-2
EBGP
SP 1 MP-EBGP
VPN A SP 2 VPN A
Site 1 Site 2

Interprovider VPNs: Option C
 Option C describes MP-EBGP-labeled route distribution
between source and destination ASs
•ASBRs now only carry internal routes
• Requires labeled-unicast family on ASBR-ASBR MP-EBGP
sessions
•External prefixes are exchanged through I/EBGP sessions
between provider PE routers
• EBGP requires multihop
LSP with Multihop EBGP VPN B
VPN B
Site 1 For VPN Routes Site 2
ASBR-1 ASBR-2
PE-1 P-1 P-2 PE-2
EBGP
EBGP Session with
labelled-unicast
VPN A
SP 1 SP 2 VPN A
Site 1 Site 2

Carrier of Carriers: Operation
Customer Customer External
External Site 1 Service Site 2
Routes Routes
Provider
MPLS MPLS
PE-1 PE-2
P
ASBR-1 CE-1 CE-2 ASBR-2
LSP
 Service provider routers:
•P routers maintain only provider internal routes
•PE routers maintain provider internal and customer internal
routes
• PE routers do not carry customer external routes
 Customer routers:
•CE routers maintain internal routes and external routes
learned from their customers
•ASBRs interface to downstream subscribers to exchange
internal routes (subscriber internal = customer external)
Carrier of Carriers: Signaling
MP-IBGP 7
EBGP Multihop
Session Site 2 Internal Route Label 101 External
3 Route x
External Service
Route Provider To Site 1
Customer Site 1 Customer Site 2
x AS=64512 (EBGP) 6
AS=11 External
AS=10
8 Route x
PE-1 PE-2 From
P 2
ASBR-1 CE-1 4 CE-2 ASBR-2 Subscriber
MP-EBGP 30 LSP MP-EBGP
5 1
IBGP Site 2 Internal Site 2 Internal IBGP
Route Label 200 Route = x
Site 2 Internal Route Label 300
 Provider network requires LSP signaling

 MP-BGP signaling between CE and PE routers
•Uses labeled-unicast address family
 IBGP/EBGP signaling between ASBRs
•Full mesh (except CE routers) for IBGP, multihop for EBGP
• Route reflection possible to improve scalability
•BGP sessions between ASBRs are tunneled over LSP in
provider’s backbone
Carrier of Carriers: Data Flow
EBGP Multihop MP-IBGP

To Site 1
Session Site 2 Internal Route Label 101
(EBGP)
Service External
Provider Route x
Customer Site 1 5 Customer Site 2
AS=64512
AS=10 AS=11
1 PE-1 PE-2
P 7
ASBR-1 2 CE-1 3 CE-2 6 ASBR-2
30 LSP MP-EBGP
MP-EBGP
IBGP Site 2 Internal Site 2 Internal IBGP
4 Route = x
Site 2 Internal Route Label 300 Route Label 200
30 200
300 101 101
DA=x DA=x DA=x DA=x
DA=x DA=x DA=x
Packet @ ASBR PE-2 swaps CE-2 pops label Packet delivered
CE-1 pushes PE-1 swaps top PHP by VRF label to subscriber x
addressed to x and sends packet
label 300 label and P router and sends to destination
pushes MPLS MPLS label
label 30 200 to CE
 Two-level label stack in provider’s network

Carrier of Carriers: Example
Provider Core 200.0.0/24
AS 65512
OSPF Area 0 AS 11
AS 10
Site 1 Site 2 OSPF Area 0
OSPF Area 0
10.0.50.0/24 10.0.20.0/24 172.22.220.0/24 172.22.222.0/24 10.0.21.0/24 10.0.60.0/24

.2 .1 .2 .1 .1 .2 .2 .1 .1 .2 .1 .2
ge-1/1/4 ge-1/0/1 ge-1/0/4
ASBR-1 CE-1 PE-1 P-1 PE-2 CE-2 ASBR-2
lo0 192.168.12.1 lo0 192.168.2.1 lo0 192.168.2.2 lo0 192.168.12.2
lo0 192.168.12.3 lo0 192.168.12.4
 Sample network:
•AS 65512 provides carrier-of-carrier services to its
customers in AS 10 and AS 11
• LSP established between PE routers
•Policy exists on CE routers to advertise /32 loopback
addresses to provider
• EBGP with labeled-unicast NLRI between CE and PE routers
•ASBR-1 and ASBR-2 routers establish a multihop EBGP
session to advertise external routes (200.0.0/24)
Carrier-of-Carriers ASBR-2 Configuration
 Redistributes external routes to internal and external

peers using multihop EBGP with loopback peering:
user@asbr-2# show protocols bgp user@asbr-2 # show policy-options
export 200; policy-statement 200 {
group int { term 10 {
type internal; from {
local-address 192.168.12.4; route-filter 200.0.0.0/24 exact;
neighbor 192.168.12.2; }
} then accept;
group ext { }
type external; term 20 {
multihop; then reject;
local-address 192.168.12.4; }
peer-as 10; }
neighbor 192.168.12.3;
}

Carrier-of-Carriers CE-2 Configuration
 Redistributes internal /32s to PE-2; family inet
labeled-unicast needed on EBGP peering
session
user@ce-2# show protocols bgp user@ce-2# show policy-options
group int { policy-statement internals {
type internal; term 10 {
local-address 192.168.12.2; from {
export nhs; route-filter 192.168.12.2/32 exact;
neighbor 192.168.12.4; route-filter 192.168.12.4/32 exact;
} }
group ext { then accept;
type external; }
family inet { term 20 {
labeled-unicast; then reject;
} }
export internals; }
peer-as 65512; policy-statement nhs {
neighbor 10.0.21.1; term 10 {
} then {
next-hop self;

Carrier-of-Carriers PE-2 Configuration
 PE router’s VRF table also supports inet labeled-
unicast family
user@pe-2# show routing-instances user@pe-2# show protocols mpls
vpn { label-switched-path pe2-to-pe1 {
instance-type vrf; to 192.168.2.1;
interface ge-1/0/4.0; no-cspf;
route-distinguisher 192.168.2.2:100; }
vrf-target target:65512:100; interface all;
protocols {
bgp {
group vpn {
type external;
family inet {
labeled-unicast;
}
peer-as 11;
neighbor 10.0.21.2;
}
}
}
}

Carrier-of-Carriers Operation: CE-1 (1 of 2)
 CE-1 receives labeled routes for Site 2’s internal

routes:
user@ce-1> show route receive-protocol bgp 10.0.20.1 detail
* 192.168.12.2/32 (1 entry, 1 announced)

Accepted
Route Label: 300112
Nexthop: 10.0.20.1
AS path: 65512 11 I
* 192.168.12.4/32 (1 entry, 1 announced)

Accepted
Route Label: 300128
Nexthop: 10.0.20.1
AS path: 65512 11 I

Carrier-of-Carriers Operation: CE-1 (2 of 2)
 CE-1 learns Site 2’s externals routes from ASBR-1:

user@ce-1> show route 200.0.0.0 detail

200.0.0.0/24 (1 entry, 1 announced)
Source: 192.168.12.3
Next hop: 10.0.20.1 via ge-1/1/4.0, selected
Label operation: Push 300128
Indirect next hop: 27964b0 1048577
Task: BGP_10.192.168.12.3+61199
Announcement bits (2): 0-KRT 4-Resolve tree 1
AS path: 11 I
Accepted

Carrier-of-Carriers Operation: PE-1
 PE-1’s VPN MPLS forwarding table:
•Swap/push operations create two-level label stack in
provider core
user@pe-1> show route table vpn.mpls.0 detail
vpn.mpls.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

300112 (1 entry, 1 announced)
*VPN Preference: 170
Source: 192.168.2.2
Label-switched-path pe1-to-pe2
Label operation: Swap 299904, Push 302368(top)
Swap 299904
Indirect next hop: 28aab40 1048583
Local AS: 65512
Task: BGP RT Background

Carrier-of-Carriers Operation:
ASBR Traceroute
 Traceroute must be sourced from ASBR-1’s loopback
address in this example:
•If icmp-tunneling is not configured, P router hops are
seen as traceroute timeouts due to preservation of TTL in all
MPLS headers
user@asbr-1> traceroute 200.0.0.2 source 192.168.12.3
traceroute to 200.0.0.2 (200.0.0.2) from 192.168.12.3, 30 hops max, 40 byte
packets
1 10.0.50.1 (10.0.50.1) 0.389 ms 0.302 ms 0.281 ms
2 10.0.20.1 (10.0.20.1) 0.402 ms 0.381 ms 0.365 ms
3 * * *
4 * * *
5 10.0.21.2 (10.0.21.2) 0.593 ms 0.465 ms 0.461 ms
6 10.0.60.2 (10.0.60.2) 0.409 ms !N 0.390 ms !N 0.386 ms !N

Carrier-of-Carriers VPN Operation (Option C)
Customer Site 1 Service
Customer Site 2
External Provider
External
Routes ASBR ASBR
Routes
ASBR ASBR ASBR ASBR
PE-2 P PE-3
PE-1 P CE-1 CE-2 P PE-4
LSP
LSP
LSP
 Service provider routers:
•P routers maintain only P-internal routes
•PE routers maintain P-internal and C-internal routes
 Customer routers:
•CE routers maintain C-internal routes
•PE routers maintain both C-internal and C-external routes (VRF
tables house C-external routes)
•LSPs required between customer PE and CE routers
 ASBRs interconnect with other autonomous systems
 Three-level label stack in provider and customer networks
•MP-I/EBGP needed for labeled route exchange
Carrier-of-Carriers VPNs: Signaling
MP-IBGP 7
EBGP Multihop To Site 1
(MP-EBGP)
3
External Service External Route x
Route Provider
Customer Site 1 Customer Site 2 Route Label 1004
x AS=64512
AS=10 6
AS=11 External
8 LSP Route x
PE-2 PE-3 From
P 2
PE-1 CE-1 4 CE-2 PE-4 Subscriber
LSP
5 MP-EBGP MP-EBGP 1
MP-IBGP Site 2 Internal LSP
Site 2 Internal Site 2 Internal IGP Internals
Route Label 1007 Route Label 1020
Route Label 1020
 Provider and customer networks require LSP signaling
 MP-BGP signaling between customer CE and provider
PE routers
•Uses labeled-unicast address family
 IBGP/EBGP signaling between customer PE routers
•Full mesh among customer PE routers with common VPNs
• RR improves scalability—no-nexthop-change command
•BGP sessions between customer PE routers are tunneled over
LSP in provider’s backbone and use family inet-vpn
© 2010 Juniper Networks, Inc. All rights reserved. | 19 www.juniper.net
Carrier-of-Carriers VPNs: Data Flow
EBGP Multihop MP-IBGP
To Site 1
(MP-EBGP)
Service External Route x
Provider
Customer Site 1 6 Customer Site 2 Route Label 1004
AS=64512
AS=10
AS=11
LSP
PE-2 PE-3
1 2 P 7
PE-1 CE-1 CE-2 PE-4
3 1008 LSP
MP-EBGP MP-EBGP 9
MP-IBGP 4 Site 2 Internal LSP
Site 2 Internal Site 2 Internal IGP Internals
Route Label 1007 Route Label 1020
Route Label 1020
5
1007 1001 1020 DA=x
1008 1004 1004
DA=x 1004 1004 1004
1001
DA=x 1004 DA=x DA=x DA=x DA=x Native packet
Packet @ PE1 delivered to
addressed to x CE1 Swaps DA=x PHP by PE3 swaps CE2 pops PE4 pops
subscriber x
top label PE2 swaps top P router top label top label VRF label
1020 8
1004 label, and (PHP)
2
DA=x pushes MPLS
label 1008
PE1 pushes
label 1004 and 1020
(PHP = no top label)  Requires three-level label stack
Carrier-of-Carriers VPN Example 172.16/16
Provider Core
172.15/16 AS 65512 CE-2A
OSPF Area 0 AS 11
CE-1A AS 10
Site 1 Site 2 OSPF Area 0 .2
OSPF Area 0
.2
10.0.50.0/24 10.0.20.0/24 172.22.220.0/24 172.22.222.0/24 10.0.21.0/24 10.0.60.0/24
.1
.2 .1 .2 .1 .1 .2 .2 .1 .1 .2 .1 .2
.1
ge-1/1/4 ge-1/0/1 ge-1/0/4
PE-1 PE-2 PE-4
CE-1 P-1 PE-3 CE-2
lo0 192.168.12.1 lo0 192.168.2.1 lo0 192.168.2.2 lo0 192.168.12.2
lo0 192.168.12.3 lo0 192.168.12.4
 AS 65512 provides carrier-of-carriers services to its
customers in AS 10 and AS 11
•LSP established between PE routers
 Policy on customer PE routers to advertise /internal
routes to provider
•EBGP with labeled-unicast NLRI between CE device and
PE routers
 PE-1 and PE-4 routers establish a multihop
MP-EBGP session to advertise external (VPN) routes
(172.16/16) using family inet-vpn
PE-1 Configuration
 Redistributes external (VRF) routes to PE peers

 Multihop EBGP-loopback peering with resolve-vpn
user@pe-1# show protocols bgp user@pe-1# show routing-instances
group int { vpn-2 {
type internal; instance-type vrf;
local-address 192.168.12.3; interface ge-1/0/6.0;
family inet { route-distinguisher 192.168.12.3:1;
labeled-unicast { vrf-target target:10:200;
resolve-vpn; routing-options {
} static {
} route 172.15.0.0/16 next-hop 10.0.51.2;
neighbor 192.168.12.1; }
} }
group ext { }
type external; user@pe-1# show protocols mpls
multihop; interface all;
family inet-vpn { user@pe-1# show protocols ldp
unicast; interface all;
}
family l2vpn {
signaling;
}
peer-as 11;
neighbor 192.168.12.4;
}

CE-1 Configuration
 Redistributes internal routes to PE-2; family inet
labeled-unicast needed on BGP peering session
user@ce-1# show protocols
…
bgp {
group int {
type internal;
family inet {
labeled-unicast;
}
export nhs;
neighbor 192.168.12.3;
}
group ext {
type external;
family inet {
labeled-unicast;
}
export internals;
peer-as 65512;
neighbor 10.0.20.1;
…

Carrier-of-Carriers VPN Operation:
VPN Routes
 VRF routes are learned through MP-EBGP connection

between customer PE routers
user@pe-1> show route receive-protocol bgp 192.168.12.4
vpn-2.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

* 10.0.61.0/24 192.168.12.4 11 I
* 172.16.0.0/16 192.168.12.4 11 I

192.168.12.4:1:10.0.61.0/24
* 192.168.12.4 11 I
192.168.12.4:1:172.16.0.0/16
* 192.168.12.4 11 I

Internal Routes
 Internal routes are learned through MP-IBGP
connection between CE and PE routers
• resolve-vpn copies labeled routes into inet.3 for VPN
route resolution
user@pe-1> show route receive-protocol bgp 192.168.12.1

* 10.0.21.0/24 192.168.12.1 100 65512 I
* 192.168.12.2/32 192.168.12.1 100 65512 11 I
* 192.168.12.4/32 192.168.12.1 100 65512 11 I

* 10.0.21.0/24 192.168.12.1 100 65512 I
* 192.168.12.2/32 192.168.12.1 100 65512 11 I
* 192.168.12.4/32 192.168.12.1 100 65512 11 I

Carrier-of-Carriers VPN Operation: PE-2
 PE-2’s VPN MPLS forwarding table
•Swap/push operations create three-level label stack in
provider core
user@pe-2> show route table vpn.mpls.0 detail
vpn.mpls.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

300288 (1 entry, 1 announced)
*VPN Preference: 170
Source: 192.168.2.2
Label-switched-path pe1-to-pe2
Label operation: Swap 300080, Push 302400(top)
Swap 300080
Indirect next hop: 28aa1e0 1048576
Local AS: 65512
Age: 1:13:50 Metric2: 4
Task: BGP RT Background
…

traceroute
 traceroute operational command:
•Customer PE-to-PE VRF table:
user@pe-1> traceroute 10.0.61.2 routing-instance vpn-2
1 * * *
…
5 * * *
6 10.0.60.2 (10.0.60.2) 0.797 ms 0.515 ms 0.502 ms
7 10.0.61.2 (10.0.61.2) 0.501 ms 0.507 ms 0.487 ms
•Customer PE-to-PE:
user@pe-1> traceroute 192.168.12.4 source 192.168.12.3
traceroute to 192.168.12.4 (192.168.12.4) from 192.168.12.3, 30 hops max, 40
byte packets
1 10.0.50.1 (10.0.50.1) 0.510 ms 0.391 ms 0.361 ms
2 10.0.20.1 (10.0.20.1) 0.383 ms 0.379 ms 0.373 ms
3 * * *
4 * * *
5 10.0.21.2 (10.0.21.2) 0.606 ms 0.478 ms 0.466 ms
6 192.168.12.4 (192.168.12.4) 0.477 ms 0.475 ms 0.457 ms

Juniper Training PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Juniper Training PDF

Hochgeladen von

Copyright:

Verfügbare Formate

JUNOS MX SERIES INTRODUCTION

UNIVERSAL EDGE WITH 3D SCALING

MX 5-80 MX104 MX 240 MX 480 MX 960 MX 2010 MX 2020

REVENUE GENERATION FOR THE NEXT DECADE

MX240 MX480 MX960 MX2010 MX2020

10GE Ports* 48 136 256 260 520

Redundant RE Yes Yes Yes Yes Yes

Redundant Fabric Yes Yes Yes Yes Yes

* Current capacity, system capacity is higher

4 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

Upper Fan tray

Lower Fan tray Cable

5 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

Power Supply Indications

Fan Tray Indications

Slot Online/Offline Buttons

6 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

7 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

SCBs are the Switch and But:

8 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

9 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

10 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

Supported on MX960, MX480 and MX240

Supports all of the Layer3, MPLS and Layer2 feature

11 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

12 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

13 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

14 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

100 GbE Modular Line Card

16 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

Power and cooling

19 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

65 Gbps, 65 Gbps, 65 Gbps, 80 Gbps 80 Gbps 960+ Gbps

21 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

ACX1000: 1G router, with T1/E1: FRS 2T2012

ACX2000: 10G router, with T1/E1: FRS 2T2012

ACX4000: 10G Modular router, with 2 MIC slots: FRS 3T2012

ACX1100: 1G Ethernet-only router: FRS 3T2012

ACX2100: 10G with more SFP Ports: FRS 3T2012

22 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

23 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

24 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

Passive cooling Complete Remote

Avoid opex that is 15-30% Save up to 25% of initial

FANs wear-out eventually, and the wear-out accelerates in dusty outdoor

FANs requires annual maintenance. Zero-Maintainability is more critical since

26 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

27 Copyright © 2009 Juniper Networks, Inc. www.juniper.net

Host Subsystem Operation

 In this section, you will learn to

The host subsystem is comprised of:

• We recommend you install two host subsystems for maximum

• Host subsystems are hot-pluggable.

• If the host subsystem you want to take offline is currently functioning as

• On the console or other management device connected to the Routing

• A host subsystem automatically comes online when both its components

In this section, you learned to:

Switch Control Board Removal and

 In this section, you will learn to

• A Switch Control Board and a Routing Engine comprise a host subsystem.

Each Switch Control Board consists of the following components:

• Control FPGA—Provides the PCI interface to the Routing Engine.

You will need: