Академический Документы
Профессиональный Документы
Культура Документы
A
SH
Junos Layer 3 VPNs
T
NO
15.a
DO
—
Student Guide
Volume 2
LY
ON
E
US
408-745-2000
www.juniper.net
A
marks are the property of their respective owners.
Junos Layer 3 VPNs Student Guide, Revision 15.a
Copyright © 2016 Juniper Networks, Inc. All rights reserved.
SH
Printed in USA.
Revision History:
Revision 15.a—November 2016
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 15.1R2.9.
T
Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special,
exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
NO
DO
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known
time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
—
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement
executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its
license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain
prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.
LY
ON
E
US
AL
RN
TE
IN
Contents
A RE
Chapter 6: Layer 3 VPNs—Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
SH
Exchanging Routes Between VRF Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Hub-and-Spoke Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Layer 3 VPN CoS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
Layer 3 VPN and GRE Tunneling Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-30
Layer 3 VPN and IPsec Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-34
T
Layer 3 VPN Egress Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38
BGP PIC Edge for MPLS Layer 3 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-66
NO
Provider Edge Link Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-72
Lab: GRE Tunnel Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-79
DO
Hierarchical VPN Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Junos Support of Carrier-of-Carriers Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Junos Support of Carrier-of-Carriers VPN Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Interprovider VPN Option C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37
Lab: Carrier-of-Carriers VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-52
—
Chapter 8: Troubleshooting Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Troubleshooting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
LY
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-38
MVPN Internet Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-44
Lab: MVPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-53
TE
iv • Contents www.juniper.net
Course Overview
RE
This two-day course is designed to provide students with MPLS-based Layer 3 virtual private network (VPN) knowledge
and configuration examples. The course includes an overview of MPLS Layer 3 VPN concepts, scaling Layer 3 VPNs,
Internet access, Interprovider L3VPNs, and Multicast for Layer 3 VPNs. This course also covers Junos operating
A
system-specific implementations of Layer 3 VPNs. This course is based on the Junos OS Release 15.1R2.9.
Through demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos OS
SH
and in device operations.
Intended Audience
This course benefits individuals responsible for configuring and monitoring devices running the Junos OS.
T
Course Level
NO
Junos Layer 3 VPNs (JL3V) is an advanced-level course.
Prerequisites
The prerequisites for this course include the following:
• Intermediate-level networking knowledge and an understanding of OSPF, IS-IS, BGP, and Junos policy;
DO
• Experience configuring MPLS label-switched paths using Junos;
• Introduction to the Junos Operating System (IJOS) course or equivalent;
• Junos Routing Essentials (JRE) course or equivalent;
• Junos Intermediate Routing (JIR) course or equivalent; and
—
• Junos MPLS Fundamentals (JMF) course or equivalent.
Objectives
LY
• Describe the format of the BGP routing information, including VPN-IPv4 addresses and route distinguishers.
• Describe the propagation of VPN routing information within an AS.
US
• List the BGP design constraints to enable Layer 3 VPNs within a provider network.
• Explain the operation of the Layer 3 VPN data plane within a provider network.
• Create a routing instance, assign interfaces to a routing instance, create routes in a routing instance, and
AL
• List the steps necessary for proper operation of a PE-CE dynamic routing protocol.
• List the troubleshooting and monitoring techniques for routing instances.
• Explain the difference between the bgp.l3vpn table and the inet.0 table of a routing instance.
TE
RE
• Describe the flow of control traffic and data traffic in a hub-and-spoke Layer 3 VPN.
• Describe QoS mechanisms available in L3VPNs.
• Configure L3VPN over GRE tunnels.
A
• Describe the RFC 4364 VPN options.
SH
• Describe the carrier-of-carriers model.
• Configure the carrier-of-carriers and “Option C” configuration.
• Describe the flow of control and data traffic in a draft-rosen multicast VPN.
• Describe the configuration steps for establishing a draft-rosen multicast VPN.
T
• Monitor and verify the operation of draft-rosen multicast VPNs.
NO
• Describe the flow of control traffic and data traffic in a next-generation multicast VPN.
• Describe the configuration steps for establishing a next-generation multicast VPN.
• Describe the configuration steps for establishing a next-generation multicast VPN.
• Monitor and verify the operation of next-generation multicast VPNs.
DO
• Describe the flow of control traffic and data traffic when using MVPNs for Internet multicast.
• Describe the configuration steps for enabling Internet multicast using MVPNs.
• Monitor and verify the operation of MVPN Internet multicast.
—
LY
ON
E
US
AL
RN
TE
IN
RE
Day 1
Chapter 1: Course Introduction
A
Chapter 2: MPLS VPNs
SH
Chapter 3: Layer 3 VPNs
Chapter 4: Basic Layer 3 VPN Configuration
Lab 1: Layer 3 VPN with Static and BGP Routing
Chapter 5: Layer 3 VPN Scaling and Internet Access
T
Lab 2: LDP over RSVP Tunnels and Public Internet Access
NO
Day 2
Chapter 6: Layer 3 VPNs – Advanced Topics
Lab 3: GRE Tunneling
Chapter 7: Interprovider Backbones for Layer 3 VPNs
DO
Lab 4: Carrier-of-Carrier Layer 3 VPNs
Chapter 8: Troubleshooting Layer 3 VPNs
Lab 5: Troubleshooting Layer 3 VPNs
Day 3
—
Chapter 9: Draft-Rosen Multicast VPNs
Chapter 10: Next Generation Multicast VPNs
LY
Lab 6: MVPNs
ON
E
US
AL
RN
TE
IN
RE
CLI and GUI Text
Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user
A
interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter
text according to the following table.
SH
Style Description Usage Example
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
T
Courier New Console text:
commit complete
• Screen captures
NO
• Noncommand-related Exiting configuration mode
syntax
GUI text elements:
Select File > Open, and then click
• Menu names Configuration.conf in the
DO
Filename text box.
• Text field entry
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
E
Finally, this course distinguishes between regular text and syntax variables, and it also distinguishes between syntax
variables where the value is already assigned (defined variables) and syntax variables where you must assign the value
(undefined variables). Note that these styles can be combined with the input style as well.
AL
CLI Undefined Text where the variable’s value is Type set policy policy-name.
the user’s discretion or text where
ping 10.0.x.y
the variable’s value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
TE
RE
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, and class locations from the World
A
Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.
About This Publication
SH
The Junos Layer 3 VPNs Student Guide was developed and tested using software Release 15.1R2.9. Previous and later
versions of software might behave differently so you should always consult the documentation and release notes for the
version of code you are running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development team. Please send
T
questions and suggestions for improvement to training@juniper.net.
NO
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the format in which you
DO
want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC
—
(within the United States) or 408-745-2121 (outside the United States).
LY
ON
E
US
AL
RN
TE
IN
T
NO
Chapter 6: Layer 3 VPNs—Advanced Topics
DO
—
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 3 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Will Discuss:
• How the auto-export command and routing table groups can be used to support communications between sites
attached to a common provider edge (PE) router;
E
• The various Layer 3 virtual private network (VPN) class of service (CoS) mechanisms supported by the Junos
operating system;
• Junos OS support for generic routing encapsulation (GRE) and IP Security (IPsec) tunnels in Layer 3 VPNs. and
• Junos OS support for different types of egress protection.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Allowing Communication
At this point, you should be well versed in the procedures used to populate VPN routing and forwarding tables (VRFs) with routes
learned from local customer edge (CE) devices and with the routes learned from remote PE routers. However, what if you want to
E
allow communications between two different VPN sites that attach to the same PE router?
US
A common example why this might be necessary is a provider’s network management system requiring communications with CE
routers at customer sites that are attached to the same PE router. In some cases, it might be possible to resolve this dilemma by
simply combining the two VRF tables into one VRF table by placing both CE routers into the same VPN. Unfortunately, this
straightforward solution does not work well for the example on the slide because administrative boundaries (which are the
whole purpose of VPNs) are difficult to maintain when different VPNs suddenly merge into one VPN.
AL
VRF policy does not solve this problem either. VRF policy normally only affects routes exchanged between PE routers.
Because the sites shown on the slide are attached to the same PE router, no Multiprotocol Border Gateway Protocol
(MP-BGP) session exists to which you could even apply VRF policy. However, if you configure the auto-export command in
each VRF table, the import and export VRF policies are evaluated without the need for MP-BGP sessions to exist, as
RN
within the router so that routes can be exchanged between them. The use of routing table groups to solve this problem is
demonstrated as well in following pages.
IN
A RE
SH
T
NO
DO
—
LY
ON
auto-export Example
This slide provides an example of how to use the auto-export command to leak routes between VRF tables in the same PE
router. The drawing on the slide shows the PE router that now has CE-B attached to its ge-0/0/3 interface. In each VRF table on
E
the PE, the auto-export command is enabled. This command causes the router to analyze some combination of the
vrf-import policy, vrf-export policy, and the vrf-target statements of each VRF table that has the auto-export
US
command configured. Any routes with the correct target communities are then copied between these VRF tables.
In the example on the slide, because both VRF tables use the same import and export VRF target, all routes in the vpn-a
table are copied into the vpn-b table, and vice versa.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
example, the a-to-b routing table group is told to place its routes into its own instance (vpn-a.inet.0) and into the routing
table associated with the vpn-b.inet.0 instance. The same effect is configured for the opposite direction with the b-to-a
US
The next code snippet shows the relevant portions of the vpn-a VRF table. While the VRF table configuration for vpn-b is
not shown, that instance requires similar configuration steps. In this case, the VRF instance has its routing-options
configured to place the VRF interface routes into the a-to-b routing table group. This configuration is required so that the
interface routes associated with each VRF table are copied into the VRF tables of the other sites with which it is to
RN
communicate. If the VRF interface routes are not copied into the other VRF tables, the routes that are copied will be
unresolvable (and therefore unusable) by virtue of their pointing to an unknown interface as part of the packet’s next hop.
Continued on the next page.
TE
IN
RE
The last relevant portion of vpn-a’s VRF configuration is the need to link the CE-PE routing protocol to the a-to-b routing
table group. This step causes the BGP routes learned from CE-A to be copied into both the vpn-a and vpn-b VRF tables. EBGP,
OSPF, and RIP support routing table groups. You can define static routes in each site’s VRF table, or they can be specified in a
routing table group that imports into the VRF tables.
A
The Junos OS also allows the use of policy to control the exchange of routes between routing table groups. To use this feature,
include the import-policy option when defining the routing table groups:
SH
user@PE# show routing-options
rib-groups {
a-to-b {
import-rib [ vpn-a.inet.0 vpn-b.inet.0 ];
T
import-policy rib-policy;
...
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
screen capture also confirms that the interface routes associated with the vpn-b instance are also present in the vpn-b VRF
table.
US
The 10.0.21/24 interface route is listed twice because it is both a direct route and a route learned through BGP (the CE-A router
has a BGP policy to redistribute direct routes). Because policy is not used in this routing table group example, both routes are
copied from the vpn-a VRF table to the vpn-b VRF table even though only the direct route is currently active in the vpn-a VRF
table.
AL
Although not shown on the slide, the configuration steps performed under the vpn-b routing instance cause the interface and
BGP routes in the vpn-b VRF table to be copied into the vpn-a VRF table.
Because both VPN sites now have routes for each other’s site, the two locations can now communicate freely through the PE
router.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The example shows vpn-b’s VRF export policy, which now includes an interface condition in term 1’s from clause. The
result is that only routes learned from the ge-0/0/3 interface are accepted for export to remote PE routers. This result
prevents the vpn-b instance from advertising routes leaked from the vpn-a VRF table.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Hub-and-Spoke Topologies
The slide highlights the topic we discuss next.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
exception rather than the norm. A hub-and-spoke VPN has the added advantage of reducing BGP peering and LSP requirements
in that spoke locations only require a single BGP session and LSP to the hub site. The hub site must support n–1 LSPs and BGP
US
locations and conveys them to the hub CE router. The hub instance receives routes from the hub CE router and redistributes
them out to the spoke sites.
A separate VRF interface is required to back up each VRF instance in the hub PE router. In practice, this interface is normally
one physical interface with two logical units.
Continued on the next page.
TE
IN
RE
The hub-and-spoke topology uses two route targets. Spoke sites advertise routes to the spoke instance using one route target
and receive routes from the hub instance with another route target. You can implement a hub-and-spoke topology with a single
route distinguisher used for both the hub and spoke instances, but the presence of route reflection forces a unique route
distinguisher value for each instance. This requirement is needed to ensure that the route reflector does not attempt to
A
compare the routes advertised (and choose a best route) by the two instances.
SH
AS Path Loops and Domain ID Issues
The use of BGP in a hub-and-spoke topology can result in problems with AS loop detection. Enabling autonomous system (AS)
loops on the hub PE router might be required, even when using as-override and remove-private.
The use of OSPF as the hub PE-CE routing protocol can present problems due to the up/down bit that prevents link-state
T
advertisement (LSA) looping. A PE router that receives an LSA with this bit set will not install the corresponding route. By default,
this bit is set on all LSAs that the PE router advertises to the CE router. You can disable this functionality by explicitly configuring
NO
domain-vpn tag 0. Hub sites must manually configure this VPN route tag in their spoke instance so that the hub instance
will install the routes to spoke CE routers.
DO
The presence of multiple spokes attached to the same PE router, or a spoke site attached to the hub PE router, requires
additional configuration steps to ensure the hub CE device is transited for spoke-to-spoke communications.
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The following list provides details of the signaling flow shown on the slide:
1. Spoke CE-1 advertises a route.
2. Spoke PE-1 advertises this route to the spoke instance on the hub PE router using the spoke route target.
3. The spoke instance in the hub PE router sends the route to the hub CE router using the ge-0/0/0.0 VRF interface.
AL
4. The hub CE router either re-advertises the route or generates an aggregate for all spoke sites, which is sent to the
hub PE router’s hub instance using the ge-0/0/0.1 VRF interface.
5. The hub instance in the hub PE router advertises this route to the spoke sites using the hub route target.
RN
The spoke sites match the routes with the hub route target and install the route in their VRF table. For spoke PE-2, the route
is sent to the attached spoke CE router (CE-2).
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
2. PE-2 has learned the routes for Site 1 through the hub instance, so it forwards the packet to the hub PE router.
3. The packet is received by the hub PE router’s hub instance. It is forwarded out the
ge-0/0/0.1 VRF interface, because the hub instance has learned these routes from the hub CE router.
4. The hub CE router has learned about Site 1’s routes from the hub PE router’s spoke instance. Therefore, the packet
AL
is turned around by the hub CE router and is sent back to the hub PE router on the ge-0/0/0.0 VRF interface.
5. The spoke instance in the hub PE router forwards the packet to spoke PE-1.
6. Spoke PE-1 forwards the packet to CE-1.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
This example also shows the extended community definitions, including both a hub and a spoke route target.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Because spoke routes are learned by the hub site’s spoke VRF instance, the hub instance uses a null VRF import policy. As
US
shown on subsequent slides, this policy requires that a policy statement named null be configured with a single then
reject statement.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Because the hub site’s hub VRF instance advertises spoke routes, the spoke instance is using a null VRF export policy. As
US
shown on subsequent slides, this policy requires that a policy statement named null be configured with a single then
reject statement.
Because EBGP is used on the hub’s PE-CE link, AS-path loop detection is a problem. In this case, the use of the as-override
knob prevents loop detection problems as the spoke routes are delivered to the hub CE router through the spoke instance.
However, because the provider’s AS number is now at the front of the AS path, when the hub CE router readvertises the routes
AL
back to the hub PE router’s hub instance, the hub PE router detects an AS loop and discard the routes. Therefore, you should
observe the following guideline:
• Do not use EBGP at the hub site.
RN
A RE
SH
T
NO
DO
—
LY
ON
configuration in effect reverses the above policies by attaching the spoke community on advertised routes and matching the
routes learned from the hub community for received routes.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
While complex in its entirety, breaking down the signaling into discrete steps makes signaling verification a manageable task.
US
For example, if the spoke route is in the local spoke CE device’s VRF table but not in the hub PE router’s spoke instance, the
problem must relate to either that spoke router’s advertisements (VRF export) or the hub PE router’s reception (VRF import).
By examining the hub PE router’s spoke VRF instance first, you can verify nearly one half of the total signaling exchange in one
step. Eliminating half of all possible causes with each test is a prime way of expediting the fault isolation process.
AL
Because of the requirement for two route targets, and the likelihood of AS loop detection when EBGP is provisioned at the
hub PE-CE link, you always should suspect these two areas as likely causes for operational problems.
When a traceroute between two spoke locations fails, it is often difficult to determine the location of the problem. Because
spoke-to-spoke communications must transit the hub location, first verify that each spoke location can communicate
successfully with the hub site. When two spokes can reach the hub, but not each other, the problem normally lies in the hub
CE device operation, as it would relate to the re-advertisement of the spoke routes.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
You can also employ filtering and CoS functions at the egress PE router when certain conditions are met. These functions
allow for Address Resolution Protocol (ARP) operations, egress rate limiting, and firewall filtering.
The EXP bits in the VRF label can be set based on firewall classification, IP precedence bits, or ingress interface.
The EXP bits of the RSVP label can be set with a static CoS value. Or, with the Enhanced Flexible PIC Concentrator (FPC), the
RSVP or LDP label can have its EXP field set to the value used by the VRF label.
Setting the classifiers exp option on transit LSRs makes weighted round-robin (WRR) and random early detection
(RED) functionality available for labeled packets. Failing to specify an EXP classifier results in all labeled packets being
placed into output queue 0 by default. With Enhanced FPC hardware, you can create custom EXP to output queue mappings,
IN
but an exp classifiers statement is still necessary to effect EXP-based output queue selection for queues 1–3.
A RE
SH
T
NO
DO
—
LY
ON
queue number 2 (assured-forwarding forwarding class). The ingress PE router places all Internet Control Message Protocol
(ICMP) traffic into queue 2 with all other traffic going into queue 0 (the default queue).
US
With an Enhanced FPC, both labels can be written independently. Thus, the queuing decisions made by the ingress PE router
can be mirrored in the transit LSRs and at the egress PE router.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The bottom (VRF) label in this example is carrying a CoS value set by the firewall-based classification of the packet at
ingress. With a B2 FPC, the firewall-based classification is overwritten by the outer label’s EXP value. Therefore,
differentiated queuing is only possible at the ingress PE router. With the Enhanced FPC, the values are set independently. By
default, an Enhanced FPC-equipped router sets the outer label to the value of the inner label such that classification at the
AL
ingress PE router sets the EXP field of both labels, thereby allowing transit and egress queuing based on input classification.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Load Balancing
You can load-balance VPN traffic across multiple LSPs by applying a load-balancing policy to the main forwarding instance.
E
You also can map VPN traffic to a specific LSP when multiple LSPs exist between a pair of PE routers. This mapping allows a
service provider to offer a multitier service by deploying LSPs between PE routers having differing performance
characteristics.
The most common technique for prefix-to-LSP mapping involves routing policy at the LSP ingress node. This policy maps
AL
traffic to a particular LSP using community-based match criteria. This technique assumes that the LSP egress node tags VPN
prefixes with the correct community value as the routes are advertised to PE routers using multiprotocol IBGP. Note that this
technique currently does not support route filter match conditions at the LSP ingress node.
You can also map prefixes to LSPs by manipulating the BGP next hop at the LSP egress node as the routes are advertised to
RN
PE routers. When establishing the two LSPs, you must use care to ensure that each is defined to terminate on the correct IP
address at the LSP egress node. The result is that the LSP ingress node resolves some of the VPN routes to one of the BGP
next hops and the remaining routes to the other BGP next hop. When the LSP egress node resolves these BGP next hops
through its inet.3 routing table, it selects the LSP that matches the route’s BGP next hop for installation in the forwarding
table.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The policy uses the install-nexthop lsp action modifier to direct matching routes to a specific RSVP session. Term 3
US
accepts all nonmatching routes for the default action of per-prefix load balancing across equal-cost LSPs.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The Results…
US
After applying and committing the prefix mapping policy, you can verify the results by examining the vpnb VRF table. The
highlighted entries confirm that traffic associated with the 172.16 routes is mapped to one LSP (top label set to 100032),
while traffic to the 192.168 routes is mapped to a different LSP (top label set to 100030).
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
To support GRE tunnels, a tunnel services must be enabled as described in previous slides. GRE-encapsulated packets are
US
A RE
SH
T
NO
DO
—
LY
ON
customer’s IGP does not run over the GRE tunnel, because this can lead to recursion problems.
US
On the slide, unit 0 of the Tunnel Services interface is configured with tunnel properties such as the tunnel’s source and
destination addresses. In this case, the addresses represent the values assigned to the PE router’s loopback interfaces. This
example shows an unnumbered GRE tunnel, and therefore no IP address is specified. Because this tunnel will be used to
support MPLS, family mpls must also be specified.
As illustrated on the slide you need to configure a static route with the next-hop of the GRE interface in the inet.3
AL
routing table. This is route is configured under the [edit routing-options rib inet.3] hierarchy.
Note that you must also include the routing instance destination under the tunnel hierarchy if the GRE-encapsulating
interface is also configured under the VRF table. In the example on the slide, the VRF table does not include the PE router’s
RN
encapsulating interface.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
are forwarded across the IP network based on the global addressing used for the GRE tunnel.
US
To support GRE tunnels, tunnel services must be enable on routers running the Junos OS. The new routing-instance
configuration is used to place a GRE tunnel into the correct routing instance:
gr-1/0/0 {
unit 0 {
tunnel {
AL
source 192.168.9.98;
destination 192.168.9.97;
routing-instance {
destination vrf-name;
RN
}
}
}
}
TE
Normally, static routing is used to populate the PE router’s VRF table, because running a routing protocol over a GRE tunnel
can lead to low speeds or a complete halt.
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
• PE-CE IPsec tunnel termination: The Junos OS offers support for the termination of IPsec tunnels between the
PE and CE routers.
• CE-CE tunnels: As shown, the CE routers establish end-to-end IPsec tunnels, which are passed transparently
through the PE routers. These IPsec tunnels provide secure site-to-site communications for data transferred
over the provider’s backbone.
AL
• Manual or dynamic SAs: The PE-CE IPsec tunnel can use either manual or dynamic security associations (SAs).
When configuring dynamic SAs, you must ensure that the encapsulating interface is not listed in the PE router’s
VRF table, because this causes dynamic SAs to fail.
RN
RE
• Hardware required: To support PE-CE IPsec tunnels, both the PE and CE routers require the presence of either
an AS PIC, ES PIC, or a service Dense Port Concentrator (DPC).
• PE-PE configuration: The termination of IPsec tunnels between the PE and CE routers does not affect the PE-PE
A
or P router configuration. The following pages highlight the configuration needed to support PE-CE IPsec
tunnels. Because the IPsec tunnel is associated with the control traffic to and from the VRF table, you do not
need to use firewall filters to classify traffic for encryption. We also discuss PE-PE configuration over GRE and
SH
IPsec.
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
corresponding MPLS label stack. The label stack is used to forward the packet to the egress PE router, where the bottom
label is removed and the packet is forwarded to the specified CE router.
US
You can also provide Layer 3 BGP/MPLS VPN service without an MPLS backbone by configuring GRE and IPsec tunnels
between the PE routers. The MPLS information for the VPN (the VPN label) is encapsulated within an IP header and an IPsec
header. The source address of the IP header is the address of the ingress PE router, while the destination address has the
BGP next hop, the address of the egress PE router.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Fast Restoration
Link and node protection works well on transit routers of MPLS LSPs. However, it doesn’t work so well in the context of a
Layer 3 VPN when dealing with the failure of an egress PE router. As you know, it is the PE routers that store the VPN routing
E
and forwarding information. It is obviously not an easy task to protect against a PE node failure in a Layer 3 VPN scenario.
The Junos OS supports the protection of a Layer 3 VPN egress PE. The scenario on the slide shows a multihomed CE. It is
US
connected to PE2, called the Protected PE, as all traffic between sites traverses PE2. PE3 provides a backup path to site 2. It
will be PE2 that will need to receive and store Layer 3 VPN state from PE2. PE3 will be referred to as the Protector PE. It will
be the P router that will first detect a failure in PE2. The router will act as the Point of Local Repair (PLR). To perform this
function, the PLR must have precalculated a loop free alternate (LFA) path to an anycast address (called the context ID) that
will be shared by both the Protected and Protector PE routers.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
node-link-protection under ISIS, the router will compute a backup path for ISIS learned routes. In order to install the backup
next hop in the forwarding table you need to configure the router to perform per-packet load balancing. Once ISIS has
US
The next few slides will show the change in forwarding table due to this configuration.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Anycast Address
The slide shows how to configure the context ID to be used as an anycast address by both the Protected and Protector PE. As
a result of this configuration, the PE2 and PE3 will use ISIS to advertise that this network is attached it. The slide shows the
E
A RE
SH
T
NO
DO
—
LY
ON
Next-Hop-Self
The configuration of the PE2 router (the Protected PE) causes the router to begin advertising its VRF routes with a BGP next
hop of the context identifier (10.0.0.3). The configuration of the PE3 router causes it to treat any received L3VPN routes in a
E
special manner if the BGP next hop is the same as the configured context identifier (these are called protected routes). The
next few slides will show how PE3 treats protected routes from PE2 in a special way. You can optionally configure an import
US
A RE
SH
T
NO
DO
—
LY
ON
failure along that path. Remember that the label used to reach PE3 is 299776. This will be the outer label on protected
packets at the time of failure. PE3 will need to be able to properly route packet that arrive with an outer label of 299776.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
PE2’s Routes
The slide shows the protected routes being advertised by PE2. Notice that the next hop is the context identifier. Also, notice
that the label is 16. This will be the inner label of all VPN packets sent from PE1. It is important for PE3 to be aware of this
E
label so that it will be able to deal with protected traffic (inner label 16) during a failure.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Final Lookups
Remember, that all of these tables are setup prior to a failure. The slide shows that PE3 performs a lookup on the singly
labeled packet, pops the last label leaving an IP packet, and directs the packet to an IP based routing table for a final lookup.
E
The final IP lookup will cause the router to finally send the remaining IP packet out of the VRF interface.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
alternate (LFA) route did not find the backup path to the protector.
US
A new configuration statement, advertise-mode, enables you to set the method for the interior gateway protocol (IGP) to
advertise egress protection availability
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
sets up the bypass LSP tunnel to back up the egress node by avoiding the primary egress node. This model requires a Junos
OS upgrade in core nodes, but is flexible enough to support all traffic engineering constraints. The PLR learns that the
US
context ID has a protector. When the primary context ID goes down, packets are rerouted to the protector by way of a
pre-programmed backup path. The context ID and protector mapping are configured or learned on the PLR and signaled in
the IGP from the protector. A routing table called inet.5 on the PLR provides the configured or IGP-learned details.
IS-IS advertises context IDs into the TED through an IP address TLV. IS-IS imports this TLV into the TED as extended
AL
information. IS-IS advertises the protector TLV routes in the inet.5 route for the context ID with protocol next hop being the
protector’s router ID. If the protector TLV has a label, the label is added to the route in the inet.5 routing table for LDP to use.
CSPF considers the IP address TLV for tunnel endpoint computation.
RN
With the stub alias model, the protector LSP setup does not require any changes in any nodes. But bypass LSP setup for
node protection requires changes in the PHN and the protector router.
LDP is useful in the case when the network supports 100 percent LFA coverage but does not support 100 percent per-prefix
LFA coverage. LDP sets up a backup path with the protector with the context label advertised by the protector to the service
TE
point. In networks in which 100 percent LFA coverage is not available, it is useful to have backup LSP LFAs with RSVP-based
tunnels.
IN
A RE
SH
T
NO
DO
—
LY
ON
Based on this information, all routers that might be a PLR in the network create routing entries in inet.5. The bottom label of
US
this entry is the label advertised in TLV 149 and the top is the LDP label used at the PLR to reach the protector. So we are
tunneling the 149 label in LDP.
PLR pushes the TLV149 label on the traffic and then another LDP label on top that get the traffic to the protector node. This
second label (the LDP one) is picked from the LDP database based on it being a label able to reach the protector node
announcing the context id with TLV149. in the stub-link style the LDP label would be towards the context ID IP. In a LFA
AL
topology with coverage problems this label would not exist. The PLR on the other hand will always have a LDP label towards
any other routers’ router ID.
When the traffic gets to the protector node and the LDP label is popped the remaining TLV149 label lets the protector node
RN
understand which context ID the protected traffic relates to and should be forward by.
TE
IN
RE
A
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
• Checking the route to 10.10.50/24 in PE1 reveals an active route via interface ge-2/0/2.0 pushing label 16 on
US
Table __6.6.6.6-vpn__.inet.0 is for the routing instance vpn protected routes and it shows that destination 10.10.50.0/24
can now be reached via PE2’s ge-3/2/4.0 interface using next hop 10.10.30.2 which is the PE2 facing interface in router
CE2.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
the LSP's primary egress node and backup egress node. With this representation, the penultimate hop of the LSP primary
egress point can behave like a PLR in setting up a bypass tunnel to back up the egress by avoiding the primary egress node.
US
This model has the advantage that you do not need to upgrade Junos OS on core nodes and will thereby help operators to
deploy this technology.
In RSVP, the behavior changes are only in the protector and primary routers. RSVP terminates the LSP and the bypass LSP to
the context ID. If the context ID is the protector, a non-null label is signaled. Otherwise, it will be based on the configuration or
AL
the requested label type. RSVP verifies the Explicit Route Object (ERO) from the path for itself and the context ID. RSVP sends
the Resv message with two Record Route Object (RRO) objects—one for the context ID and one for itself. This simulates the
penultimate-hop node (PHN) to do node protection with the protector for the primary for context ID LSP. As the fast reroute
(FRR)-required bypass, the LSP has to merge back to the protector LSP PHN setup bypass to context ID through the protector
RN
context node with a bandwidth and a TE metric. Other TE characteristics of TE links are not advertised by Junos OS.
IN
A RE
SH
T
NO
DO
—
LY
ON
node function.
US
The virtual node in the IS-IS LSDB announces the context ID with a TLV 135, e.g. the same used in the stub-link style.
Now all PLR routers (candidates to eventually handle PLR function depending on how the network topology might change)
see two paths to the context ID. One via the low metric virtual link between Protected node and the virtual context ID node
and another high metric path between the Protector node and the virtual context ID node.
AL
It is important to note that virtual context ID node is set to overload in ISIS, it is fake so it would not be much good to forward
any traffic.
The reason LDP doesn't work here is because we are not doing any tunneling. If there is a coverage problem and the PLR
path to the protector goes back on itself then the path to the protector is still infeasible for LFA, so no LDP label will be
RN
a node protection bypass LSP that goes to the virtual context ID node via the protector, ready for the failure of the Protected.
IN
A RE
SH
T
NO
DO
—
LY
ON
P1 (the PLR) is directly connected to Device PE3 (the protector). Using the configuration statement, advertise-mode
stub-proxy, enables you to set the method for the interior gateway protocol (IGP) to advertise egress protection
US
availability.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
TED DB in PE1 shows the PE2-6.6.6.6.00(6.6.6.6) reachable using both PE2 (Protected) and PE3 (Protector).
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
all these routes in the VPN routing table. The protector PE router scans the policy and builds the remote instance with the
configured community name from the policy.
US
• Route Target - Shows the route target associated with the routing instance
NLRI configured with egress protection shows the BGP family configured with egress protection. The Egress-protection
NLRI inet-vpn-unicast, keep-import: [remote-vrf] shows the egress protection routing policy for the BGP
RN
group.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Checking the Transit LSP in P1 router shows us the above mentioned LSP transiting P1 router. We can also see that a
Recovery label was sent from P1, which was the case when a failure occurs (penultimate router would signal for a bypass
US
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
failure and provide an alternate route can be time consuming. For example, a provider edge (PE) router might be configured
with 200,000 or more IP prefixes, and a PE router failure could affect many of those prefixes.
US
BGP Prefix-Independent Convergence (PIC) Edge allows you to install a Layer 3 VPN route in the forwarding table as an
alternate path, enabling fast failover when a PE router fails or you lose connectivity to a PE router. This already installed path
is used until global convergence through the IGP is resolved. Using the alternative VPN route for forwarding until global
convergence is complete reduces traffic loss.
AL
BGP PIC Edge supports multiprotocol BGP IPv4 or IPv6 VPN network layer reachability information (NLRI) resolved using any
of these IGP protocols:
• OSPF
RN
• IS-IS
• LDP
BGP PIC Edge does not support multicast traffic.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Example Topology
This example shows two customer edge (CE) routers, Device CE1 and Device CE2. Devices PE1, PE2, and PE3 are PE routers.
Device P1 is a provider core router. Only Device PE1 has BGP PIC edge configured. The example uses the P1-PE2 link (P-PE)
E
For testing, the address 172.16.1.5/24 is added as a loopback interface address on Device CE2. The address is announced
to Device PE2 and Device PE3 and is relayed by way of internal BGP (IBGP) IBGP to Device PE1. On Device PE1, there are two
paths to the 172.16.1.5/24 network. These are the primary and a backup path.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Example Configuration
Before the BGP PIC Edge in an MPLS Layer 3 VPN configuration make sure you have configured
E
1. Configure LDP
2. Configure an IGP, either OSPF or IS-IS
US
[edit policy-options]
user@PE1# set policy-statement policy-name then load-balance per-packet
7. Apply the per-packet load balancing policy to all routes exported from the routing table to the forwarding table
TE
A RE
SH
T
NO
DO
—
LY
ON
Verification of Protection
BGP routing information displays load balancing availability to the destination via both PE2 and PE3.
E
The Indirect next hop output lines that contain weight follow next hops that the software can use to repair paths where a link
failure occurs.
US
A RE
SH
T
NO
DO
—
LY
ON
The OSPF route output shows the tracked session IDs for the loopback interface addresses on Devices PE2 and PE3.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
used. The protection path can be configured on a PE router in a Layer 3 VPN by configuring the protection statement at the
[edit routing-instances instance-name protocols bgp family inet unicast] or [edit
US
routing-instances instance-name protocols bgp family inet6 unicast] hierarchy level. The
protection statement indicates that protection is required on prefixes received from a particular neighbor or family. After
protection is enabled for a given family, group, or neighbor, protection entries are added for prefixes or next hops received
from the respective peer.
AL
A protection path can be selected only if the best path has already been installed by BGP in the forwarding table. This is
because a protection path cannot be used as the best path. There are two conditions under which the protection path will
not work:
• When configured for an internal BGP peer; and
RN
hierarchy for the routers that have protected PE-CE links. This applies to Junos OS Releases 12.3 through 13.2 inclusive.
IN
A RE
SH
T
NO
DO
—
LY
ON
Example Topology
This example shows the customer edge CE2 router being dual homed to PE2, and PE3 routers. Device P is a provider core
router. Only Device PE3 has the Provider Edge Link Protection configured.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
To minimize packet loss when the protected path is down, also use the per-prefix-label statement at the [edit
routing-instances instance-name protocols bgp family inet labeled-unicast] hierarchy level.
Configure this statement on every PE router within the AS containing the protected path.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
multiple paths from router PE3 to the destination route, 1.1.1.6, on router CE2. The first path is directly through the PE3-CE2
link (10.1.1.26). The second path is through the provider core and PE2 (10.1.1.17).
US
The show route 1.1.1.6 extensive output verifies that the protection path is correctly configured by confirming that
the weight for the active path being protected is 0x1 (lower), and the weight for the protection candidate path is 0x4000
(greater).
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
We Discussed:
• How the auto-export command and routing table groups can be used to support communications between sites
attached to a common provider edge (PE) router;
E
• The various Layer 3 virtual private network (VPN) class of service (CoS) mechanisms supported by the Junos
operating system;
• Junos OS support for generic routing encapsulation (GRE) and IP Security (IPsec) tunnels in Layer 3 VPNs; and
• Junos OS support for different types of egress protection.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Review Questions
1.
E
2.
US
3.
AL
4.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
RE
1.
To place routes from one routing table into a second routing table, you must first create a routing table-group that lists both
routing tables as an import routing table with the primary table listed first. Once the routing table-group is specified, you
need to specify which routes will go into the routing table-group. A common set of routes to place in the routing table-group
A
would be interface routes which can be applied to the routing table-group under [edit routing-options
interface-routes] level of the hierarchy. Apply the routing table-group at this level of the hierarchy will take the local
SH
and direct routes found in the primary table (the first table in the list) and ensure they exist in both tables. For routes learned
by routing protocols, these routes can be applied to the routing table-group at the [edit protocols protocol-name]
level of the hierarchy.
2.
T
Routes from Spoke PEs and CEs are received by and accepted by the Spoke instance on the Hub PE. The HUB PE passes
those route to the HUB CE. The HUB CE then advertises those routes to the Hub instance on the Hub PE. The Hub PE then
NO
advertises those routes to the Spoke sites.
3.
The Junos OS supports firewall filtering and rate limiting. It also support the setting of the experimental bits on both the inner
and outer headers of an MPLS packet.
DO
4.
GRE and IPsec tunnels are support from CE to CE, PE to PE, and CE to PE using the Junos OS.
—
LY
ON
E
US
AL
RN
TE
IN
T
NO
Chapter 7: Interprovider VPNs
DO
—
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 3 VPNs
RE
A
SH
T
NO
DO
—
LY
ON
We Will Discuss:
• Junos operating system support for carrier of carriers;
E
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Carrier-of-Carriers Model
This model allows service provider A to offer a backbone service to the customer, another service provider. Assume the
customer is a new service provider that has a point of presence (POP) in a few sparse locations with no backbone network to
E
interconnect those POPs. The customer (the new service provider) can purchase the carrier-of-carriers service from the
service provider A to interconnect its sites making the customer network appear as a single autonomous system (AS) without
US
service provider A having to carry the external routes learned by the customer. The details of this model are discussed in the
subsequent slides.
Interprovider VPN
AL
This model allows for a Layer 3 VPN, BGP Layer 2 VPN, or a BGP virtual private LAN service (VPLS) to extend between
autonomous system or service providers.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Carrier-of-Carriers VPN
This model is a combination of the two models discussed on the previous slide. In this model, the customers of service
provider A will be providing VPN service to its own customers. The details of this model are described in subsequent slides.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Option A
RFC 4364 describes three methods of providing multiple AS backbones. Option A is the least scalable of the options. This
option requires that the autonomous system boundary routers (ASBRs) maintain separate VPN routing and forwarding tables
E
(VRFs) and store all of the associated routes for every one of its customers. Although this option is supported by the Junos
OS, it is not a recommended solution.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Option B
With option B, the ASBRs does not need to maintain separate VRF instances for each VPN. However, the ASBR will still have
to keep VPN routes in a single routing table, bgp.l3vpn.0 for L3VPN routes. Through an EBGP session between one another,
E
the ASBRs will then exchange VPN routes as label routes. The EBGP advertised labels are used stitch together the
label-switched paths (LSPs) that terminate between provider edge (PE) and ASBR.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Option C
This option is generally accepted as the most scalable solution for interprovider VPNs. This option allows the PE routers in
different autonomous systems to exchange VPN routes (Layer 3 VPN, BGP Layer 2 VPN, or BGP VPLS) using a multihop BGP
E
session. The ASBRs do not need to store any VPN routes in this case. Instead, the ASBRs will exchange the internal networks
of each service provider (most importantly the loopback addresses of the PEs) using labeled IP version 4 (IPv4) routes. The
US
labels associated with the internal networks will be used to stitch together the MPLS LSPs that exist between PE and ASBR in
the service provider networks.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
internal routes. These routes normally consist of at least the customer’s /32 loopback addresses. The provider’s PE routers
do not carry the customer’s external routes, which is critical to the overall scalability of this model.
US
Customer Routers
The customer’s routers must maintain both customer internal and external routes. The customer’s external routes are those
learned from the customer’s downstream subscribers.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
does not require MPLS signaling, the CE router must support the family MPLS on its PE-facing interface, because it must
send labeled packets.
Continued on the next page.
RN
TE
IN
RE
Once the customer’s internal routes are exchanged across the provider’s backbone, the ASBRs can establish internal BGP
(IBGP) (same AS numbers) sessions or multihop EBGP (different AS numbers) sessions through the provider’s backbone for
the purposes of exchanging external routes. A full IBGP mesh is needed between routers at the customer sites when using
IBGP, except for the CE routers, which peer indirectly using the provider’s backbone. Because this example demonstrates the
A
use of EBGP, only the peering session between ASBR-2 and CE-1 is needed. The second BGP session between the two
ASBRs (shown as a dotted line) is only required for IBGP peering when the customer sites share the same AS number.
SH
Signaling: Step by Step
The details of the signaling exchanges shown on the slide are:
1. The IGP at customer Site 2 exchanges internal reachability with CE-2. ASBR-2 establishes an IBGP neighbor
T
relationship with CE-2.
NO
2. CE-2 selectively advertises Site 2’s internal routes to the provider’s PE-2 router using multiprotocol EBGP
(MP-EBGP) with support of labeled-unicast routes. These routes are advertised with a valid label, which is
200 in this example.
3. PE-2 houses Site 2’s internal routes in a VRF table and uses MP-IBGP to send labeled VPN-IPv4 routes to PE-1.
The route to ASBR-2 is assigned Label 101 in this example.
DO
4. PE-1 uses MP-EBGP to send Site 2’s internal routes to CE-1. PE-1 changes the BGP next hop. Therefore, it must
assign a new label to the prefix advertised (Label 300 in this example).
5. After receiving the labeled route, CE-1 distributes Site 2’s internal routes to ASBR-1 using IBGP. No labels are
needed, because conventional IP forwarding is used within the customer sites. At this point, the ASBRs can
establish an EBGP multihop session through the provider’s backbone. This session is tunneled through the LSP
—
in the provider’s network.
6. ASBR-2 learns an external route x from one of its subscribers. IBGP conveys external routes from ASBR-2 to
CE-2. PE-1, PE-2, and P routers never become aware of the external route advertisement x.
LY
7. The external route x is now advertised to ASBR-1 using the EBGP session established at Step 5. No labels are
associated with this route due to the lack of MPLS forwarding in the customer networks.
8. External route x is advertised by ASBR-1 to its downstream subscribers as well as to CE-1.
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
3. CE-1 pushes Label 300 onto the packet and forwards it to PE-1.
4. PE-1 swaps the top label with the value received from PE-2, and pushes an MPLS label (30 in this example)
onto the stack. The P router pops this top label (PHP) such that PE-2 receives a packet with a single label.
RN
5. PE-2 swaps the VRF label with the label advertised by CE-2 and forwards the packet out the VRF interface to
CE-2.
6. CE-2 pops the MPLS label and routes the native packet using Site 2’s interior gateway protocol (IGP).
TE
7. ASBR-2 performs a longest-match lookup and routes the packet towards destination x.
IN
A RE
SH
T
NO
DO
—
LY
ON
• Provider network: The provider’s network is assigned AS 65512 and has already established an LSP between
US
PE-1 and PE-2 using RSVP. The PE routers have a VRF table configured, along with the necessary VRF target
community and route distinguishers.
• Policy on CE routers: The CE routers are configured to run MP-EBGP with the PE routers and have a policy in
place to ensure that only internal prefixes are advertised to the PE routers.
AL
• ASBR-1 and ASBR-2 routers exchange external routes: A multihop EBGP session is configured between the
ASBRs because the customer networks are assigned differing AS numbers. ASBR-2 advertises the external
route 200.0.0/24 to ASBR-1 using this EBGP session.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
ASBR-2 Configuration
This slide lists the key aspects of ASBR-2’s configuration. An IBGP session is configured to CE-2, and a multihop EBGP
session is configured for ASBR-1 at Site 1.
E
The 200 policy in ASBR-2 ensures that only external routes (200.0.0/24 in this example) are sent to ASBR-1. The default
US
IBGP policy causes all external routes ASBR-2 learns through EBGP to be sent to CE-2.
This policy is rather simple and requires changes for each new external route. A more scalable solution involves an AS path
regex that blocks all internal routes and only accepts routes whose AS-path attribute does not begin with 11.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
CE-2 Configuration
This slide lists the key aspects of CE-2’s configuration. An IBGP session is configured to ASBR-2, and an MP-EBGP session is
configured for communications with PE-2.
E
The MP-EBGP session has the labeled-unicast family configured, which is required for the exchange of labeled routes
US
A RE
SH
T
NO
DO
—
LY
ON
PE-2 Configuration
This slide lists the key aspects of PE-2’s configuration. An MP-EBGP VRF routing instance is configured for communications
with CE-2. Also shown is an LSP that terminates on PE-1.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
session.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
label and push operation. Thus, CE-1 routes packets addressed to 200.0.0/24 by pushing label 300128 and forwarding the
labeled packet to PE-1 (10.0.20.1) for ultimate delivery to ASBR-2.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
After PHP, PE-2 receives a packet with Label 299904, which it swaps with the label learned from CE-2 (labeled unicast route)
before forwarding the singly labeled packet to CE-2.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
ASBR-1.
US
In this example, the external route is a static route on ASBR-2, so hops beyond ASBR-2 are not present. Also, because the
provider core routers (main routing instances) do not have routes associated with the customer networks, core router hops
show up as timeouts.
AL
RN
TE
IN
RE
A
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
routers and normally consist of at least the customer’s /32 loopback addresses. The provider’s PE routers do not carry the
customer’s external routes (C-external), which is a critical aspect of the overall scalability of this model.
US
Customer Routers
The customer’s routers must maintain both C-internal and C-external routes. External routes are those learned from the
customer’s downstream subscribers and are now stored in site-specific VRF tables. Unlike the previous examples, the
AL
support of VPN routes requires that LSPs be established between customer PE and CE routers. These can be established
using either RSVP or LDP. The use of LSP-based forwarding within the customer networks accommodates private/local use
addressing.
RN
ASBRs
ASBRs can be PE or CE routers and are used to connect with other autonomous systems. ASBRs advertise labeled routes
between autonomous systems and maintain switching tables that allow them to stitch together LSPs existing in adjacent
networks.
TE
RE
The presence of VRF-related labels results in the need to support three levels of label stacking in the provider and customer
networks. In the case of PE-1, the three labels have the following functions:
1. The bottom label is the VRF label assigned using MP-BGP. This label does not change as the packet is
forwarded.
A
2. The middle label is assigned by the downstream ASBR (CE-1, in the case of PE-1) and is used by the ASBR to
SH
associate the packet with the LSP leading to the next ASBR in the path.
3. The top label associates the packet with the LSP connecting PE-1 to CE-1 and is assigned by RSVP or LDP.
Because an LSP must be established across AS boundaries to interconnect customer PE routers, labels must be
communicated along with the NLRI advertised by ASBRs. Although a protocol such as LDP could be used for this purpose,
T
the Junos OS currently supports MP-BGP for this purpose.
RFC 3107, Carrying Label Information in BGP-4, specifies labeled routes. Labeled route advertisements use SAFI 4 and
NO
differ from VPN-labeled routes in that there is no route distinguisher or route target communities in the advertised NLRI.
Simply put, labeled routes allow the binding of an MPLS label to the advertised IPv4 NLRI. ASBRs use the advertised labels
to build MPLS switching tables that result in an end-to-end LSP spanning multiple autonomous networks.
Within an AS, labeled routes are sent using MP-IBGP while MP-EBGP is used across AS boundaries.
DO
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
As with the previous application, the customer’s CE routers use EBGP with labeled-unicast NLRI to exchange labeled
routes with the provider’s PE routers. The use of labeled routes allows the provider to extend its LSPs to the customer CE
router and thereby eliminate the need to carry customer internal routes in its P routers.
AL
backbone for the purposes of exchanging external routes. In this case, the routes are exchanged using MP-BGP and are
labeled VPN routes.
Continued on the next page.
TE
IN
RE
To improve scalability, the customer networks can use route reflection. The two route reflectors peer using MP-EBGP. A
command called no-nexthop-change is required to tell the route reflectors to pass—unchanged—the third party next
hops to their clients.
A
Signaling: Step by Step
SH
The details of the signaling exchanges shown on the slide are:
1. The IGP at customer Site 2 exchanges internal reachability with CE-2. External (VRF) routes are not sent to PE-3.
2. CE-2 selectively advertises Site 2’s internal routes to the provider’s PE-3 router using MP-EBGP with support of
labeled-unicast routes. The route to PE-4 is sent with a label value used to associate packets with the LSP
to PE-4 in Site 2 (1020 in this example).
T
3. PE-3 houses Site 2’s internal routes in a VRF table and uses MP-IBGP to send labeled VPN-IPv4 routes to PE-2.
NO
The route to PE-4 is assigned Label 1001 in this example.
4. PE-2 uses MP-EBGP to send Site 2’s internal routes to CE-1. Because PE-2 has changed the BGP next hop (as is
always the case with ASBRs), it must assign a new label to the prefix advertised (Label 1007 in this example).
5. After receiving the labeled route, CE-1 distributes Site 2’s internal routes to PE-1 using MP-IBGP. Unlike the
DO
carrier-of-carriers application, this exchange involves labeled-unicast routes, and therefore requires MP-IBGP.
Because CE-1 is also an ASBR, it rewrites the BGP next hop and must therefore assign a new label (Label 1020
in this example).
At this point, the ASBRs (PE-1 and PE-4) establish an MP-EBGP multihop session through the provider’s backbone. This BGP
session is tunneled through the LSP in the provider’s network and is used to carry labeled VPN routes. This session should
—
be contrasted to the carrier-of-carriers application, in which MP-I/EBGP was not needed due to native IP forwarding within
the customer networks.
6. Here, PE-4 learns an external route x from one of its VPN subscribers.
LY
7. The external route x is now advertised to PE-1 using the MP-EBGP session established at Step 5. This NLRI
advertisement includes the VRF label that PE-4 expects to receive for routes associated with this particular VRF
instance.
8. PE-1 advertises the external route to its downstream VPN subscribers.
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
assigned by CE-1 (to associate the packet with the LSP to PE-4). In this one-hop LSP example, PHP results in the
absence of a third RSVP/LSP label used to associate the packet with the LSP between PE and CE routers.
3. CE-1 receives the labeled packet and swaps the top label.
RN
4. PE-2 receives the labeled packet and swaps the top label with the value received from PE-3 while also pushing
the MPLS label (Label 1008 in this example) onto the stack.
5. The P router pops the top label (PHP) so that PE-3 receives a packet with only two labels.
Continued on the next page.
TE
IN
RE
6. PE-3 also performs a swap on the top label before forwarding the packet to CE-2.
7. Being the penultimate router for the LSP to PE-4, CE-2 pops the label stack and sends the resulting VRF-labeled
packet to PE-4.
A
8. PE-4 pops the VRF label and consults the corresponding VRF table to perform a longest-match lookup on the
now unlabeled packet.
SH
9. The native packet is forwarded out PE-4’s VRF interface towards the subscriber to which it is addressed.
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The provider’s network is assigned AS 65512. It already has established an LSP between PE-2 and PE-3 using RSVP. The PE
US
routers have a VRF table configured, along with the necessary VRF target and route distinguishers. PE-2 and PE-3 function
as ASBRs in this application.
Policy on CE Routers
AL
The CE routers are configured to run MP-EBGP (family inet labeled-unicast) with the PE routers and have a policy
in place to ensure that only internal prefixes are advertised to the provider’s PE routers.
A multihop MP-EBGP session is configured between the PE-1 and PE-4, because the customer networks are assigned
different AS numbers. The external route 172.16/16 is advertised as a labeled-VPN route by PE-4 to PE-1 using this
MP-EBGP session. Customer routers CE-1 and CE-2 also function as ASBRs in this example.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
PE-1 Configuration
This slide shows the key aspects of PE-1’s configuration. Family labeled-unicast is configured for its MP-IBGP session
to CE-1, and family inet-vpn is configured for the multihop MP-EBGP session to PE-4.
E
US
resolve-vpn
The resolve-vpn option causes PE-1 to copy the labeled-unicast routes it receives from CE-1 into inet.3, which
allows VPN routes to resolve through the interprovider LSPs. Without this option, all the VPN routes received would be
hidden, due to unusable next hops.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
CE-1 Configuration
This slide displays key portions of the configuration on CE-1. RSVP is enabled, and an LSP is defined back to PE-1 (not
shown). The MP-IBGP session to PE-1 has the labeled-unicast family configured. This configuration is needed so that
E
CE-1 can include labeled-unicast routes along with the advertisements for Site 2’s internal routes.
US
CE-1 also has an MP-EBGP session configured for its connection to PE-2. This session must also support
labeled-unicast routes.
The following policy is applied to CE-1’s MP-EBGP session to PE-2. This policy ensures that Site 1 sends only internal routes
to the provider:
AL
then accept;
}
term 3 {
then reject;
}
TE
}
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
The labeled-unicast routes received by PE-1 are copied into the main routing table (inet.0) as well as the inet.3
table. This copying is the result of the resolve-vpn option on PE-1 and is critical to the operation of this network.
US
Normally, VPN routes must resolve to an LSP that terminates on the egress PE router. Because PE-1 does not have an LSP
terminating directly on PE-4, the VPN routes are unusable without the labeled-unicast entries to the remote PE routers
in inet.3, which indicate a multinetwork LSP between PE-1 and PE-4 exists.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
stack (VRF-label—300080—302400).
US
The top label is popped by the provider P router (PHP), such that PE-3 receives a packet with a two-level label stack. PE-3
swaps the top label with the value assigned to the LSP to PE-4 by CE-2. PE-3’s label operation is shown here:
user@pe-3> show route table mpls.0
...
299904 *[VPN/170] 19:07:27
RN
RE
The result is that CE-2 receives a packet with a two-level label stack (VRF-label—299872). CE-2 then swaps the top label with
the value it associates with the LSP to the egress PE router. In this example, CE-2 pops the stack because it is the
penultimate router for this LSP.
A
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
All other router hops in the customer an provider networks are seen as traceroute timeouts.
US
The traceroute between PE-1 and PE-4 shows the outer MPLS label for the various hops in the path, except for the provider’s
routers which appear as timeouts. The provider routers are not able to generate traceroute responses, owing to their not
carrying customer external or internal routes.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
• PE routers maintain the internal routes from its own AS (AS-internal), the loopback address from the other AS
PE’s (AS-external), and the L3VPN routes.
US
• ASBR routers maintain the internal routes from its own AS (AS-internal), and the loopback addresses from the
other AS PE’s (AS-external). It does not maintain L3VPN routes which makes this solution scalable.
ASBR Routers
AL
The ASBR routers interconnect the providers. To ensure that the L3VPN traffic is sent labeled across the interprovider link
labeled-unicast routes are exchanged across the EBGP session.
CE Routers
RN
CE routers are unaware of the interprovider setup so just as for single provider L3VPNs they only care about their own circuit
information and their local routing (if used at all).
Continued on the next page.
TE
IN
RE
The presence of L3VPN related labels results in the need to support three levels of label stacking in the provider networks. In
the case of PE-1, the three labels have the following functions:
1. The bottom label is the L3VPN label assigned using multihop MP-EBGP. This label does not change as the
packet is forwarded.
A
2. The middle label is assigned by the downstream ASBR1 and is used by the ASBR1 to associate the packet with
SH
the LSP leading to the remote PE This is a labeled unicast learned label.
3. The top label associates the packet with the LSP connecting PE1 to ASBR1 and is assigned by RSVP or LDP.
Because an LSP must be established across AS boundaries to interconnect customer PE routers, labels must be
communicated along with the NLRI advertised by ASBRs. Although a protocol such as LDP could be used for this purpose,
T
the Junos OS currently supports MP-BGP for this purpose.
RFC 3107, Carrying Label Information in BGP-4, specifies labeled routes. Labeled route advertisements use SAFI 4 and
NO
differ from VPN-labeled routes in that there is no route distinguisher or route target communities in the advertised NLRI.
Simply put, labeled routes allow the binding of an MPLS label to the advertised IPv4 NLRI. ASBRs use the advertised labels
to build MPLS switching tables that result in an end-to-end LSP spanning multiple autonomous networks.
Within an AS, labeled routes are sent using MP-IBGP while MP-EBGP is used across AS boundaries.
DO
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The ASBR routers use EBGP with labeled-unicast NLRI to exchange labeled routes across the interprovider connection.
The use of labeled routes allow the providers to extend its LSPs to each other by also carrying the loopback addresses of the
PE’s from the other AS.
AL
addresses.
RE
To improve scalability for large deployments, the provider networks can use route reflection. The two or more route reflectors
peer using multhop MP-EBGP. A command called no-nexthop-change is required to tell the route reflectors to pass—
unchanged—the third party next hops to their clients.
A
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
second label (2007) assigned by ASBR1 (to associate the packet with the extended LSP to PE2). The top label
(1020) is pushed to use the LDP LSP to reach ASBR1.
3. P1 receives the labeled packet and pops the top label (PHP).
RN
4. ASBR1 receives the labeled packet and swaps the top label with the value received from ASBR2 (2007
-->2008)
5. ASBR2 receives the labeled packet and swaps the top label with the value of the LDP LSP towards PE2 (2008
--> 1010).
TE
RE
6. Being the penultimate router for the LDP LSP to PE2, P2 pops the label stack and sends the resulting
L3VPN-labeled packet to PE2.
7. PE2 pops the L3VPN label and consults the corresponding table to forward the traffic out of the correct
CE-facing interface.
A
8. The native packet is forwarded out PE2’s L3VPN interface towards the CE to which it is addressed.
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Within each provider’s network the IGP and LDP protocols already have been configured so that within each AS there is an
US
policy in place to ensure that only internal PE’s loopback prefixes are advertised to the other provider’s ASBR.
AS numbers. The L3VPN NLRI is advertised as a labeled-VPN route by PE2 to PE1 using this MP-EBGP session.
IN
A RE
SH
T
NO
DO
—
LY
ON
PE1 Configuration
This slide shows the key aspects of PE1’s configuration. Family labeled-unicast is configured for its MP-IBGP session to
ASBR1, and family inet-vpn unicast is configured for the multihop MP-EBGP session to PE2.
E
US
resolve-vpn
The resolve-vpn option causes PE1 to copy the labeled-unicast routes it receives from ASBR1 into inet.3, which
allows L3VPN routes to resolve through the interprovider LSPs. Without this option, all the VPN routes received would be
hidden, due to unusable next hops.
AL
The slide also shows the L3VPN routing-instance configuration that is identical as used for single provider L3VPNs.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
ASBR1 Configuration
This slide shows the key aspects of ASBR1’s configuration. Family labeled-unicast is configured for its MP-IBGP
session to ASBR1, and for its MP-EBGP session to ASBR2.
E
Notice the export policy called internals that contains the local PE’s loopback addresses.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
The labeled-unicast routes received by PE1 are copied into the main routing table (inet.0) as well as the inet.3
table. This copying is the result of the resolve-vpn option on PE1 and is critical to the operation of this network. Normally,
US
L3VPN routes must resolve to an LSP that terminates on the egress PE router. Because PE1 does not have an LSP
terminating directly on PE2, the VPN routes are unusable without the labeled-unicast entries to the remote PE routers
in inet.3, which indicate a multinetwork LSP between PE1 and PE2 exists.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
• Label 299776 (L3VPN label received from PE2 across MP-EBGP session)
US
• Label 300064 (Label received from the labeled unicast MP-IBGP session with ASBR1)
• 299824 = Top label (Label received from P1 router using the LDP protocol)
To verify the data-plane connectivity you can use a ping from one CE toward the remote CE. As shown in the slide the ping is
successful.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
We Discussed:
• Junos support for carrier of carriers;
E
A RE
SH
T
NO
DO
—
LY
ON
Review Questions
1.
E
2.
US
3.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
RE
1.
In a carrier-of-carrier application the customer routers maintain both customer internal and external routes. In an
interprovider VPN, except for the ASBRs connect to VPN sites, the customer routers maintain customer internal routes only.
A
2.
Option A specifies the use of separate VRFs for every VPN on the ASBRs. Option B specifies the used of the EBGP exchange
SH
of VPN routes between ASBRs. Option C specifies the use of multihop EBGP (or IBGP) to exchange VPN routes between PEs
in remote autonomous systems.
3.
The labeled-unicast address family is used between PE and CE.
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
RE
A
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
T
NO
Chapter 8: Troubleshooting Layer 3 VPNs
DO
—
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 3 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Will Discuss
• Using a structured approach to troubleshoot Layer 3 VPN issues;
E
• Useful commands and tools to check both the signaling and the forwarding plane; and
• Troubleshooting MVPN issues.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Troubleshooting Overview
The slide lists the topics we will discuss. We discuss the highlighted topic first.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The Layer 3 VPN signaling plane includes such components as the PE-CE dynamic routing protocols, the MP-BGP IBGP
US
session used to advertise VPN routes to other PEs and the label distribution protocols used to signal the transport LSPs.
Checking the forwarding plane, instead, typically means sending test traffic (even with tools such as ping mpls) to detect
forwarding problems.
Troubleshooting in many cases starts with checking the state of the signaling plane. The first steps are driven by the problem
AL
description: for example, in case of total loss of connectivity between a single CE and all the others, a natural starting point
would be the PE-CE routing protocol used on the CE side. If a whole previously-working VPN suddenly goes down and no site
can reach any other site, a natural starting point would be the IBGP infrastructure (e.g. route reflectors) or the label
distribution protocols used.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Some typical signaling issues are missing routes or unreachable sites. Even if the actual root cause is hardware, e.g. a failed
US
interface on the PE-CE link, the signaling plane will be able to help pinpoint where the problem is. More complex signaling
issues are suboptimal routing or routing loops within a VPN. These problems are however are not specific to Layer 3 VPNS,
and are essentially routing policy or redistribution issues.
When it comes to forwarding issues, some typical examples are partial or total packet loss between sites, or failure to
forward multicast streams even when the multicast signaling plane appears correct. These problems are generally more
AL
complex to troubleshoot, and may involve other features and functionalities as Class of Service.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
3. The MPLS label-distribution protocols used for establishing label-switched paths in the core
We will now look at several useful commands to check each of these components.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
This will summarize the amount of routes present in each routing instance, divided by protocol, and it is often a good first
step to check the overall signaling plane. The command will also display the number of hidden routes which - in a Layer 3
US
VPN environment - are typically caused by lack of MPLS reachability to remote PEs.
In the picture, you can see two VPNs (VPN-A and VPN-B). There are no hidden routes, but while the output for VPN-B appears
normal, VPN-A does not show any BGP routes. This means no route from remote PEs are being received, and could indicate
a target/VRF policy problem.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
sessions.
US
A RE
SH
T
NO
DO
—
LY
ON
BGP export policies are still needed when distributing routes between instances using auto-export or a rib-group, or
in general whenever you need to advertise any non-BGP route (e.g. statics) to the local CE.
When using BGP as PE-CE protocol, it is often the case that all CEs in a VPN are configured as part of the same Autonomous
System. To prevent routes from being discarded by the CE as an AS-PATH loop, several options are possible: if the customer
is using a private AS, the as-override command is a common solution. If the customer is actually using a public AS and is
connected to the Internet, then using IBGP with independent-domain may be a good alternative.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
To improve scalability of OSPF as PE-CE routing protocol, several configuration options are possible. Among the commonly
deployed ones is domain-id, that allows to redistribute VPN routes using export policies as Type-3 LSAs rather than Type-5.
A problem in VRF policies or a wrong domain-id configuration can cause VPN routes to be advertised as Type-5 rather than
AL
Type-3. This can potentially cause routing problems for multi-homed sites, due to the different protocol preference of OSPF
external (150) and internal routes (10).
A second, less common configuration option is the use of sham-links, which behave similarly to virtual links, connecting
multiple part of the same OSPF domain through the provider MPLS infrastructure. Sham-links are typically used when a
RN
Layer 3 VPN is used to extend an OSPF domain, for example connecting multiple OSPF sites or regions.
be computed on the basis of the LSAs being received via the sham links.
Continued on the next page.
IN
RE
When using export policies instead (with or without domain-id) it is possible to verify what is being advertised by checking
self-originated LSAs of Type-3 or Type-5, according to the domain-id matching rules.
However, the output of show ospf database needs to be interpreted, as it only returns LSAs, not prefixes. For example,
here is the output of show ospf database instance <VPN> external advertising-router self on a PE
A
router:
SH
user@PE> show ospf database instance VPN-A external advertising-router self
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *10.3.0.0 10.1.0.2 0x80000201 1932 0xa2 0xfa61 36
Extern *10.3.0.3 10.1.0.2 0x80000201 1075 0xa2 0xca91 36
T
Extern *10.3.0.255 10.1.0.2 0x80000201 1503 0xa2 0xfa61 36
Extern *10.3.1.0 10.1.0.2 0x80000201 646 0xa2 0xef6b 36
NO
Extern *10.3.2.0 10.1.0.2 0x80000201 218 0xa2 0xe475 36
Extern *10.3.3.0 10.1.0.2 0x80000200 2789 0xa2 0xdb7e 36
From this output alone it is not possible to find out which prefixes are being advertised. This requires examining each LSA in
detail and checking its network and netmask., as shown below:
DO
user@PE> show ospf database instance VPN-A external lsa-id 10.3.0.0 detail
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *10.3.0.0 10.1.0.2 0x80000201 2654 0xa2 0xfa61 36
mask 255.255.0.0
Topology default (ID 0) —
Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 208.0.255.232
user@PE> show ospf database instance VPN-A external lsa-id 10.3.0.255 detail
OSPF AS SCOPE link state database
LY
In this example, the first LSA (lsa-id 10.3.0.0) is for 10.3.0.0/16, and the third (lsa-id 10.3.0.255) is for the 10.0.3.0/24
prefix.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
change according to the domain-id settings and the type of route (OSPF internal vs. OSPF external), and can be either a
Type-3 or a Type-5.
US
One special case is the use of sham-links; in this case, the PEs will not re-distribute MP-BGP VPN routes into OSPF, but just
transport using sham-links OSPF LSAs generated by remote sites. When using sham-links, you cannot easily check which
routes you are advertising to the CE without examining in detail the link-state database. Still, you can check if the sham-link
is operating correctly with show ospf neighbor instance vpn.
AL
A RE
SH
T
NO
DO
—
LY
ON
external routes, and a summary LSA. The summary LSA and the two external LSAs reflect respectively OSPF-internal and
OSPF-external routes from remote CEs. Note that to get the details (e.g. metrics, prefix length) you will need to use the show
US
A RE
SH
T
NO
DO
—
LY
ON
RIP does not have the concept of “neighbor” or “adjacency”, and because of this RIP-related commands are typically not very
US
intuitive. For example, the show rip neighbor instance <vpn> command takes as argument a local interface, not
a neighbor address as with other protocols.
user@router> show rip neighbor instance VPN-B ge-1/0/8.0
Local Source Destination Send Receive In
Neighbor State Address Address Mode Mode Met
AL
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
the table of MPLS egress points, and verify that all remote PEs are present.
US
For destinations internal to the local AS, the LSPs between PE routers are usually created by the LDP or RSVP label
distribution protocol. Inter-domain applications instead typically use BGP labeled-unicast; in this case, the command
resolve-vpn may be needed in order to get labeled-unicast routes installed also in inet.3 in addition to inet.0.
Using resolve-vpn is not the only way to install MPLS egress points in inet.3 ad well as in inet.0. There are also
other possibilities, including changing the default Junos traffic engineering behavior by enabling traffic-engineering
AL
mpls-forwarding at the [edit protocols mpls] level. Still, the MP-BGP next-hops for inet-vpn routes need to
be resolvable via an entry in inet.3. This makes checking this table a fundamental and useful troubleshooting step.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
From troubleshooting the point of view, one advantage of RSVP is that it gives ingress routers full visibility of the state of
LSPs, including errors along the path. With LDP it is easy to detect a LSP-down event, due to the missing route in inet.3.
However, finding the root cause often means checking hop-by-hop from the ingress to the egress, until the failure is found.
Detailed RSVP and LDP troubleshooting is covered in other Juniper Education courses.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
MP-BGP
The slide highlights the topic we discuss next.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
command on a PE. Especially with complex VRF import and export policies, it is always best to check also the remote side,
using the show route advertising-protocol bgp command.
US
A second important point to consider is that a reflector will not reflect hidden routes, which means the reflector needs to be
able to resolve inet-vpn BGP next-hops using label-switched paths. This means either establishing label-switched paths to all
PEs (even if those LSPs will typically never be used for forwarding traffic) or - if the reflector is away from the forwarding path
- using a static “dummy” inet.3 route. This last option will also prevent a route from being dropped just because there is no
AL
LSP from a PE to the reflector, even when there is full MPLS reachability between the PEs.
For example, to allow a reflector outside the MPLS domain to reflect VPN routes this static entry could be added to the inet.3
table:
RN
[edit routing-options]
user@route-reflector# show
rib inet.3 {
static {
route <prefix-of-PEs-loopbacks> discard;
TE
}
}
...
IN
The presence of a static route to MP-BGP next-hops is enough to allow the correct reflection of VPN routes.
A RE
SH
T
NO
DO
—
LY
ON
On the slide, you can see a BGP neighbor in Established state. Apparently everything seems correct, but if you check the
US
address families advertised by each peer, you can see that the remote end (probably a route reflector) is advertising also
family route-target, while the local end only inet-unicast and inet-vpn-unicast. On a big setup, this means
that a large number of unnecessary updates can be sent from the reflector to the local router, only to be discarded on
receive.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
One common misconception is that examining the bgp.l3vpn.0 table can be used to detect policy problems, e.g. target
mismatch. Unfortunately this is not the case, as target mismatches will result in routes being dropped, not stored or hidden.
It is possible to override this behavior by configuring the keep-all keyword at the bgp neighbor level, but this is typically
not recommended in any realistic deployment due to its potential negative side effects (increased resource utilization).
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
In the slide, you can see a sample output showing four hidden routes; those should be investigated, as they usually indicate
MPLS reachability problem to one or several PEs
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
After this, you can verify that the BGP next-hops are actually missing from the inet.3 table with show route table
inet.3. Once the unreachable next-hops are identified, it is just a matter of troubleshooting the label-distribution protocol
US
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
To troubleshoot PE-CE communications, both the ping and the traceroute commands accept the
routing-instance modifier, and can be used in the same way as for ordinary IP forwarding troubleshooting. Similarly,
show arp can be used to verify IP-to-MAC resolution on Ethernet interfaces.
To troubleshoot the MPLS core, instead, you can use the ping mpls and traceroute mpls commands specific to your
label distribution protocol. In addition to these, you can also use the Layer 3 VPN specific command ping mpls l3vpn.
AL
Finally, it is possible to enable icmp-tunneling to allow traceroute through the MPLS core from within the VPN. It is
important to be aware of the limitations of this functionality, as it can be very misleading. Specifically, if there is a forwarding
failure in the MPLS backbone anywhere between two PEs. traceroute originating from the CE will show a loss at the first hop,
RN
regardless where the real problem is. This is because the TTL-expired ICMP messages need to be forwarded all the way to the
remote PEs and then back. Any failure in the path will still be perceived as loss immediately after the local PE.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
(due for example to a link failure) traffic is re-routed using the alternative, MTU-constrained path, triggering the problem.
US
The example shows a case where the core MTU of an Ethernet-based network was left as 1500 bytes. The ping mpls
command try to find out the actual MTU by sending packets with different sizes, in an attempt to discover the larger packet
that can be sent on the MPLS path.
In this example, the command reports a usable MTU of 1488, due to the 12 bytes being used for 3 labels (transport, VPN
AL
A RE
SH
T
NO
DO
—
LY
ON
Troubleshooting MVPNs
The slide highlights the topic we discuss next.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
architectures are typically plagued by several limitations and are today considered obsolete.
A natural way of approaching troubleshooting MVPNs is to follow this order, first verifying if the customer multicast domain is
working up until the PE, then checking if multicast state is correctly relayed by MP-BGP, and finally investigate the Provider
RN
Multicast Service Interface, based on LDP or RSVP (next-generation MVPN) or PIM and GRE tunnels (the original, obsolete
draft-rosen). It is also worth mentioning that sometimes problems that appear at a first look to be forwarding issues are in
fact signaling issues in the PMSI. For example, a branch of a point-to-multipoint LSP flapping will result in intermittent packet
loss affecting on one or more PEs, but the actual root cause might be tied to RSVP, LDP or even the IGP.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
problem: for example, if no CE can receive traffic from a given source it is natural to start with checking source registration,
while if a receiver cannot receive any source but every other CE can, it is probably useful to start checking IGMP, then move
US
In addition to PIM-related commands, the show mvpn c-multicast instance-name <vpn> can be used to check
customer multicast state on the PE. The use of this command will be illustrated in the next slide.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
source 10.0.101.2 sending to group 224.7.7.1 is handled via a point-to-multipoint RSVP LSP, while the line immediately
above shows a join-to-RP (*,g) state for group 224.7.7.1. This command can be especially useful when using selective
US
provider tunnels, to find out the mapping between (source,group) pairs and PMSIs.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
An initial check might involve verifying if every PE is advertising a type-1 route (I-PMSI autodiscovery). Types 5, 6 and 7 are a
translation of (respectively) PIM register source, join-to-RP and join-to-source messages. When running MVPN in SPT-only
mode, checking for type-5 routes is a good way to verify quickly if a PE has knowledge of sources registered elsewhere, while
types 6 and 7 are useful when following PIM state from the receiving CE towards the source CE (for type 7) or towards the RP
(for type 6). Finally, type 3 and 4 are useful for checking selective PMSIs; a type-3 route should be advertised by each PE
AL
which wants to set up a selective tree, and interested receiving PEs should ‘answer’ with a type-4 route in order to be
included in the multicast distribution tree.
For more information of the encodings and functions of the different MVPN route types, please see the document “NG-MVPN
route types and encodings” available on the Juniper Networks Knowledge Base with document-id TN-115.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
counters which show how much multicast traffic is being forwarded. Very often troubleshooting multicast forwarding means
to go from router to router checking the traffic counters tied to a specific multicast (source, group) pair; having traffic
US
counters makes this easy and non-disruptive, as it can be done without changing the configuration or enabling traceoptions.
The command also shows the number of packets discarded due to Reverse Path Forwarding Check Failure, in the line titled
“Wrong incoming interface notification”.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
We Discussed
• Using a structured approach to troubleshoot Layer 3 VPN issues;
E
• Useful commands and tools to check both the signaling and the forwarding plane; and
• Troubleshooting MVPN issues.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Review Questions
1.
E
2.
US
3.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
RE
1.
An export policy is always needed with RIP, and are needed for OSPF when not using a sham-link.
2.
A
The show bgp neighbor command will display the address family configured on both the local and the remote end of the
BGP session.
SH
3.
The typical cause of hidden routes in the bgp.l3vpn.0 table is the lack of a LSP to the advertising PE.
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
T
NO
Chapter 9: Multicast Review and Draft Rosen
DO
—
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 3 VPNs
RE
A
SH
T
NO
DO
—
LY
ON
We Will Discuss:
• IP multicast traffic flow;
E
• Components of IP multicast;
• How multicast addressing works;
US
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Address Types
In IP networking three types of addressing are typically used for the communication between hosts:
E
• Unicast addressing: Unicast addresses are used when a host wants to send traffic to another specific host.
Each host requires its own unique IP address for this type of traffic.
US
• Broadcast addressing: Broadcast addresses are used when a host wants to send traffic to all hosts on a given
subnet. Each subnet has its own broadcast IP address. Traffic to the broadcast address is typically not
forwarded by the router. Some types of broadcast traffic (for example, DHCP) might need to be forwarded to
other parts of the network.
AL
• Multicast addressing: Multicast addresses are used when a host wants to communicate with a group of hosts
that are interested in that specific traffic. Different types of multicast applications exist, such as where one host
sends traffic to many interested receivers (one to many), and other applications that send traffic between all
the interested hosts (many to many).
RN
A more recent type of addressing that is used in IP networking is the anycast address. The concept of anycast addressing is
that a group of receivers all share the same address. When traffic must be delivered to the anycast address, it is delivered to
the nearest member of the group. An example of where anycast addressing is used is Domain Name System (DNS) anycast.
In multicast it is also used in a feature called anycast RP. An advantage of anycast addressing is that it provides a very fast
TE
A RE
SH
T
NO
DO
—
LY
ON
packet should have a unicast source address. Generally, a multicast packet uses UDP, the Real-Time Transport
Protocol (RTP), or both as its transport protocols. No guarantees exist that packets will be received by all
members of a group. One protocol, the Pragmatic General Multicast (PGM) protocol, has been developed to add
loss detection and retransmission capabilities to multicast.
AL
• Designated router (DR): The DR is the router closest to the source that forwards multicast packets into the
network. If two or more routers are attached to the source, only one ever becomes the DR based on an election
algorithm that depends on the multicast routing protocol in use.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
• Group membership protocol: Receivers use a group membership protocol to inform the directly connected
router of their interest in receiving packets for one or more multicast group addresses. That is, the host receiver
US
is informing the router of its desire to become a member of a multicast group. IGMP is used by IP version 4
(IPv4) hosts and routers for this purpose. This material focuses on IPv4 multicast.
• Multicast routing protocol: A multicast routing protocol is used between routers to build and maintain the
multicast forwarding trees between source and receiver. The following slides describe the basic functionality of
a multicast routing protocol. The two most common multicast routing protocols are Protocol Independent.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Service Models
We use the following terminology for multicast service models:
E
• Any-source multicast (ASM): This delivery model was designed into the original specifications for multicast in
RFC 1112. The model supports both one-to-many applications like Internet Protocol Television (IPTV), as well as
US
many-to-many applications like white boarding or video conferencing. ASM gets its name from receivers being
able to join a group without specifying from which source they want to receive traffic, so they accept it from any
source.
• Source-specific multicast (SSM): In SSM, the receiver specifies the sources from which it wants to receive the
traffic. It can also specify from which sources it does not want to receive traffic. So for SSM to work, the source
AL
information must be known. SSM makes deployment of multicast less complex and also makes allocating
multicast addresses easier.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Distribution Modes
We use the following terminology for multicast distribution modes:
E
• Dense mode: In dense mode, traffic is forwarded to all parts of the network (which is known as flooding). The
parts of the network that are not interested in receiving the traffic send prune messages to their neighboring
US
routers asking them to stop forwarding traffic. In case a receiver subscribes after sending the prune, the router
sends a graft message asking for the traffic to be forwarded again.
• Sparse mode: In sparse mode, traffic is forwarded only into parts of the network with interested receivers. The
routers send join messages to indicate their willingness to receive traffic. If a receiver is no longer interested,
the router sends prune messages to the neighbor asking it to stop forwarding the traffic.
AL
• Sparse-dense mode: Sparse-dense mode allows the router interface to operate on a per-group basis in either
sparse or dense mode. A group specified as dense is not mapped to an RP. Instead, data packets destined for
that group are forwarded by means of PIM dense-mode rules. A group specified as sparse is mapped to an RP,
RN
A RE
SH
T
NO
DO
—
LY
ON
Distribution Trees
We use the following terminology for multicast distribution trees:
E
• Source tree or shortest-path tree (SPT): A source tree is the forwarding path for the traffic from a specific source
all the way up to the router that is closest to the receiver. A source tree is the shortest path between source and
US
receiver and can only be used when the router next to the receiver knows about the source. The routers keep
the forwarding path from the receiver to the source in the following state: S, G (S comma G). S indicates source
address and G indicates group address. In dense mode a source tree is always used. In sparse mode a source
tree is used after the receiver router learns about the source.
• Shared tree or rendezvous point tree: If the source is not known, a source tree cannot yet be built. In the ASM
AL
model, the receivers subscribe to a group address using IGMP. In the subscription request, they do not indicate
the source. The routers must build a tree toward an unknown source. The solution to this problem is to have a
meeting point for sources and receivers in the network. This meeting point is called a rendezvous point (RP).
The tree built from the receiver to the RP in the network is called a shared tree (because it is shared by all
RN
receivers). The routers keep the forwarding path from the receiver router to the RP in the following state: *,G (*
comma G). The * indicates any source and the G indicates the group address.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Multicast Forwarding
In multicast forwarding, the path between source and receiver is called a tree. The source is the root of the tree. The tree
branches out into the network, and at the end of the branches are the receivers (or leaves). The source is considered
E
upstream and the receivers are downstream. Branches of the tree are created when receivers join, and are torn down when
receivers leave. In the case of a shared tree, the RP is considered upstream and the root of the tree.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
• Source Tree: The source tree, or shortest-path tree, builds the forwarding path from source directly toward the
receiver. The forwarding state kept in the routers between source and receiver uses the S,G notation.
US
In dense mode, the shortest-path tree is always used between the source and any router in the network during
the flooding process. Any part of the network that does not have receivers prunes the distribution tree. The
result is a source tree with branches to the parts of the network that actually have receivers.
To join a shortest-path tree in sparse mode, S,G join messages are exchanged. In case a receiver is no longer
AL
interested in receiving traffic from the source, S,G prune messages are sent by the router closest to the
receiver.
• Shared Tree: The shared tree is used if the source address is not known. In that case the only option is to
enable the forwarding state up to the RP. The forwarding state toward the rendezvous point uses the *,G
RN
notation.
Once the source starts sending traffic, the router closest to the source sends the traffic to the RP, and from
there it can be sent to the receiver. All routers in the network must agree on which router is the RP, so source
and receivers can be connected in the network.
TE
The advantage of using shared trees is that they typically generate less state information in the network,
because it is not necessary to create a unique source tree for each session in the network. The disadvantage is
that the path between source and receiver across a shared tree is often not optimal. This issue is especially
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Multicast Forwarding
When forwarding unicast traffic, the router is primarily concerned with the destination address. The goal of unicast
forwarding is to send the packet in the direction of the destination. A route lookup is performed to find the best route toward
E
the destination, and the packet is sent in that direction. Multicast forwarding is not initially concerned about the destination
address of a multicast packet.
US
Multicast forwarding bases its decisions primarily on the source address of the incoming packet. The goals of multicast
forwarding are to make sure traffic sent toward the receivers does not loop in the network and also to avoid packet
duplication. To make sure no loops or duplicated packets exist, multicast routing sends only a single packet down each
branch of the distribution tree.
AL
To determine which incoming packets are sent down the distribution tree, multicast forwarding uses the reverse path
forwarding (RPF) check. The RPF mechanism basically selects packets to forward down the distribution tree only if the
packet was received on the interface that is nearest to the source.
RN
The RPF check looks into the routing table to determine the best route back to the source. The next-hop interface of that
route must be the incoming interface of the multicast packet. If the interfaces match, the packet passes the RPF check and
can be forwarded down the tree. If the incoming interface does not match the route back to the source, the RPF check fails
and the packet is discarded.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
check succeeds, and the packet is forwarded to all interfaces on the outgoing interface list. Initially, all interfaces other than
ge-0/0/4.125 will be on the outgoing interface list.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
• Forwarding plane: A successful RPF check allows traffic from an incoming interface to be forwarded down the
US
distribution tree. The incoming interface is considered the upstream interface because the source is upstream.
The receivers are downstream on the tree so the interfaces to which the traffic can be forwarded are called
downstream interfaces. The group of interfaces with downstream receivers is called the outgoing interface list
(OIL). The result of a successful RPF check is cached in table inet.1.
• Control plane: The RPF check is also used in the control plane. If a router must receive traffic because of
AL
downstream receivers, it signals only to upstream routers on the interface that would pass the RPF check.
Therefore, join and prune messages are only exchanged with neighboring routers on the interface to the
upstream router nearest to the source. The receipt of IGMP or PIM join messages moves those interfaces to the
OIL, so packets are forwarded to these interfaces toward the receivers.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
• inet.0: The default table used by the RPF check process is the same as the unicast forwarding table. Thus,
the unicast topology and multicast topology are identical.
US
• inet.1: The results of successful RPF checks for forwarding traffic are cached in a separate inet.1 table.
• inet.2: If you must have a separate topology for multicast forwarding, you can achieve this separate topology
by changing the table the RPF check uses. Therefore, instead of looking in the default inet.0 table, the RPF
check can be directed to look in inet.2. The inet.2 table must be filled with routing information to build the
AL
– Other protocols must use routing information base (RIB) groups to place routes into inet.2.
To direct the multicast routing protocols to use inet.2 for the RPF check, RIB groups are required.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
exchanged twice, once for unicast routing (inet.0) and once for multicast routing (inet.2).
US
When AS 65013 sends unicast traffic toward AS 65011, it prefers the bottom link. For the multicast traffic coming from AS
65011, the RPF check prefers the top link. If the multicast and unicast topologies had been identical, the multicast RPF
check would have also preferred the bottom link.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Normally, you do not have to run IGMP between routers because routers normally do not join multicast groups.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
router’s IGMP query message to indicate that it is still interested in receiving traffic for that group. When the host wants to
receive traffic for a given group, it must also start listening for the corresponding MAC address.
US
The routers on the segment cache the IGMP report information to keep track of the receivers on that segment per multicast
group address.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The router must keep track of the receivers to make sure at least one receiver remains on any of the outgoing interfaces
because it is wasting resources if it is forwarding traffic to interfaces without downstream receivers. To check if the receivers
are still interested, the router sends periodic IGMP query messages asking if interested receivers still exist. The IGMP query
message is sent to 224.0.0.1 (all systems). The goal of the query message is to receive a solicited report message back from
at least one receiver per group. Therefore, it is not useful if more than one receiver responds per group as the router only
AL
in one report answer per group to the query message from the router.
If more than one router exists on a given segment, the routers elect one active querier router. Each router starts out thinking
it must start querying, but as soon as it sees queries from another router with a lower IP address, it stops. These non-querier
routers that lose the querier election still keep track of the IGMP cache.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
router must time-out receivers before it can stop forwarding out of that interface, which results in a long leave latency.
US
In IGMP version 2, this problem is solved by having a specific IGMP leave message that a host should send when it is no
longer interested in traffic for a specific group. The leave group message is sent to the group’s multicast address. When a
router receives a leave message, it sends a group-specific query to find out if other receivers for that group are still on the
interface. The remaining receivers should respond to the group-specific query to indicate that there is at least one receiver
remaining on the interface. The advantage of this method is that the leave latency is greatly reduced because the timers in
AL
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Multiservice Network
This slide illustrates the general model for multiservice network.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Draft Rosen
There was a time when draft-Rosen has been the standard by which multicast was transported between Layer 3 VPN
(L3VPN) sites. This method does not rely on either MPLS or BGP. Instead, not only does the customer need to run a multicast
E
routing protocol like Protocol Independent Multicast (PIM) but the service provider network must also use PIM to signal the
end to end path of the L3VPN multicast traffic. Also, MPLS is not used to transport the multicast data between sites, instead,
US
A RE
SH
T
NO
DO
—
LY
ON
domain. Within the provider network (main routing instance), a PE must participate in the providers PIM domain.
US
A RE
SH
T
NO
DO
—
LY
ON
these addresses would not be possible to route over the ISP network. Customers could not be able to use same Multicast
group IP addresses since these would no longer be individually associated to a single customer in the ISP Core. Core routers
US
could not be able to differentiate to which customer network a particular Multicast packet would belong to. A solution is to
run the Multicast traffic over GRE tunnels set up between all customer’s CE routers in a full mesh fashion. This approach can
be feasible in a very small customer CE base but the number of GRE tunnels increases with the number of CE routers with
N’(N-1)/2, where N = number of CE routers.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
address for the GRE tunnel is the sourcing PE router’s loopback IP address. Destination address is the Multicast group IP
address. We call these GRE tunnels the Multicast Distribution Tree (MDT). Of course this setup requires that the ISP core has
US
A RE
SH
T
NO
DO
—
LY
ON
service provider (SP) network. A multicast-enabled VPN routing and forwarding (VRF) instance corresponds to a multicast
domain (MD), and a PE router attached to a particular VRF instance is said to belong to the corresponding MD. For each MD
US
there is a default multicast distribution tree (MDT) through the SP backbone, which connects all of the PE routers belonging
to that MD. Any PE router configured with a default MDT group address can be the multicast source of one default MDT.
Draft-rosen MVPNs with service provider tunnels start by sending all multicast traffic over a default MDT, as described in
section 2 of the IETF Internet draft draft-rosen-vpn-mcast-06.txt and section 7 of the IETF Internet
AL
draft draft-rosen-vpn-mcast-07.txt. This default mapping results in the delivery of packets to each provider edge (PE) router
attached to the provider router even if the PE router has no receivers for the multicast group in that VPN. Each PE router
processes the encapsulated VPN traffic even if the multicast packets are then discarded.
Let’s say that the Customer in the diagram above having routers CE1, CE2, CE3, and CE4 has Multicast address
RN
239.10.11.11 in the ISP Core. Each of the PE routers will attempt to form a GRE tunnel with the other PE routers. The PE
routers will also join the Multicast group 239.10.11.11 in the ISP core. The result is that the PE routers now will send GRE
tunneled traffic which will end up at all other PE routers since the destination address is the Multicast IP address.
Multicast enabled GRE tunnels:
TE
A RE
SH
T
NO
DO
—
LY
ON
the new MDT group address. An advertisement of a new MDT group address is sent in a User Datagram Protocol (UDP)
type-length-value (TLV) packet called an MDT join TLV. The MDT join TLV identifies the source and group pair
US
(20.1.1.1,239.10.11.11) in the VRF instance as well as the new data MDT group address 239.10.11.12 used in the provider
space. The PE router to which the source site is attached sends the MDT join TLV over the default MDT for that VRF instance
every 60 seconds as long as the source is active. When the PE router to which the source site is attached sends a
subsequent MDT join TLV for the VRF instance over the default MDT, any existing cache entries for that VRF instance are
simply refreshed with a timeout value of 180 seconds.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
• PE routers connected to receivers in the VRF instance for the current multicast group cache the contents of the
US
MDT join TLV, adding a 180-second timeout value to the cache entry, and also join the new data MDT group.
• PE routers not connected to receivers listed in the VRF instance for the current multicast group also cache the
contents of the MDT join TLV, adding a 180-second timeout value to the cache entry, but do not join the new
data MDT group at this time.
AL
When a remote PE router joins the new data MDT group, it sends a PIM join message for the new group directly to the source
PE router from the remote PE routers by means of a PIM (S,G) join.
The source PE router starts encapsulating the multicast traffic for the VRF instance using the new data MDT group after
3 seconds, allowing time for the remote PE routers to join the new group. The source PE router then halts the flow of
multicast packets over the default MDT, and the packet flow for the VRF instance source shifts to the newly created data
MDT. After the source PE stops sending the multicast traffic stream over the default MDT and uses the new MDT instead,
TE
only the PE routers that join the new group receive the multicast traffic for that group.
To display the information cached from MDT join TLV packets received by all PE routers in a PIM-enabled VRF instance, use
the show pim mdt data-mdt-joins operational mode command.
IN
A RE
SH
T
NO
DO
—
LY
ON
its cache and can join the data MDT immediately without waiting up to 59 seconds for the next data MDT advertisement.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
the MDT join TLVs and switches back to sending on the default MDT for that VRF instance.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
• Draft-rosen multicast VPNs with service provider tunnels operating in any-source multicast (ASM) mode (also
referred to as rosen 6 Layer 3 VPN multicast)—Described in RFC 4364,BGP/MPLS IP Virtual Private Networks
US
(VPNs) and based on Section 2 of the IETF Internet draft draft-rosen-vpn-mcast-06.txt, Multicast in MPLS/BGP
VPNs (expired April 2004).
• Draft-rosen multicast VPNs with service provider tunnels operating in source-specific multicast (SSM) mode
(also referred to as rosen 7 Layer 3 VPN multicast)—Described in RFC 4364,BGP/MPLS IP Virtual Private
Networks (VPNs) and based on the IETF Internet draft draft-rosen-vpn-mcast-07.txt, Multicast in MPLS/BGP IP
AL
VPNs. Draft-rosen multicast VPNs with service provider tunnels operating in SSM mode do not require that the
provider (P) routers maintain any VPN-specific Protocol-Independent Multicast (PIM) information.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
your VPNs between the participating PE routers and verify the functionality.
US
Make sure that the routing devices support multicast tunnel (mt) interfaces for encapsulating and de-encapsulating data
packets into tunnels. For multicast to work on draft rosen Layer 3 VPNs, each of the following routers must have tunnel
interfaces:
• Each provider edge (PE) router.
AL
A RE
SH
T
NO
DO
—
LY
ON
ASM Configuration
This slide illustrates the example network used in the next few slides.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
PE Router Configuration
The slide highlights the key components for configuring the ASM PE router:
E
• interface lo0.1: Configures an additional unit on the loopback interface of the PE router. For
the lo0.1 interface, assign an address from the VPN address space. Add the lo0.1 interface to the following
US
• In multicast Layer 3 VPNs, the multicast PE routers must use the primary loopback address (or router ID) for
sessions with their internal BGP peers. If the PE routers use a route reflector and the next hop is configured as
self, Layer 3 multicast over VPN will not work, because PIM cannot transmit upstream interface information for
RN
multicast sources behind remote PEs into the network core. Multicast Layer 3 VPNs require that the BGP
next-hop address of the VPN route match the BGP next-hop address of the loopback VRF instance address.
• protocols pim interface - Configures the interfaces between each provider router and the PE routers.
• protocols pim mode sparse - Enables PIM sparse mode on the lo0 interface of all PE routers. You can
TE
either configure that specific interface or configure all interfaces with the interface all statement.
• protocols pim rp static - On all PE routers, configure the address of the router acting as the RP
statically since in this example we have chosen to use static RP configuration. RP is the P1 router.
IN
RE
• routing-options rib-groups - Configures the multicast routing group. This group configuration results
in using inet.2 when doing RPF checks. However, if you are using inet.0 for multicast RPF checks, this step
will prevent your multicast configuration from working. You can use inet.0 only and skip the inet.2 which is
just an option not a mandatory configuration step.
A
• group-address - In a routing instance, configure multicast connectivity for the VPN on the PE routers.
Configure a VPN group address on the interfaces facing toward the router acting as the RP. The PIM
SH
configuration in the VPN routing and forwarding (VRF) instance on the PE routers needs to match the master
PIM instance on the CE router. Therefore, the PE router contains both a master PIM instance (to communicate
with the provider core) and the VRF instance (to communicate with the CE routers).
• VRF instances that are part of the same VPN share the same VPN group address. For example, all PE routers
T
containing multicast-enabled routing instance VPN-A share the same VPN group address configuration. In
figure on previous page the shared VPN group address configuration is 239.1.1.1.
NO
• routing-instances VPN-A protocols pim rib-group - Adds the routing group to the VPN's VRF
instance ands activates it in the instance.
Note that imports and exports confide because the rib group is reused between both pim and interface routes:
• export for pim routes and
DO
• import for interface routes
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
On router CE1 you need to configure PIM statically to use CE2 as the RP for VPN-A
US
...
interface all {
mode sparse;
version 2;
RN
...
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Display multicast tunnel interface information, DR information, and the PIM neighbor status between VRF instances on the
US
PE1 and PE2 routers by using the show pim neighbors instance VPN-A command from either PE router.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Each PE sends an MDT subsequent address family identifier (MDT-SAFI) BGP network layer reachability information (NLRI)
US
join for each. Autodiscovery provides the next-hop address of each PE, and the VPN group address for the tunnel rooted at
that PE for the given route distinguisher (RD) and route-target extended community attribute.
Each remote PE router imports the MDT-SAFI advertisements from each of the other PE routers if the route target matches.
Each PE router then joins the (S,G) tree rooted at each of the other PE routers.
TE
After a PE router discovers the other PE routers, the source and group are bound to the VPN routing and forwarding (VRF)
through the multicast tunnel de-encapsulation interface.
IN
A RE
SH
T
NO
DO
—
LY
ON
the (S,G) state to the multicast tunnel (mt) interface and sends a join message for that group. Autodiscovery for a draft-rosen
MVPN with service provider tunnels operating in SSM mode uses some of the facilities of the BGP-based MVPN control plane
US
software module. Therefore, the BGP-based MVPN control plane must be enabled. The BGP-based MVPN control plane can
be enabled for autodiscovery only.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
your VPNs between the participating PE routers and verify the functionality. Make sure that the routing devices support
multicast tunnel (mt) interfaces for encapsulating and de-encapsulating data packets into tunnels. For multicast to work on
US
draft rosen Layer 3 VPNs, each of the following routers must have tunnel interfaces:
• Each provider edge (PE) router.
• Any provider (P) router acting as the RP.
AL
• Any customer edge (CE) router that is acting as a source's DR or as an RP. A receiver's designated router does
not need a Tunnel Services PIC.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
information (NLRI), called MDT sub address family identifier information (MDT-SAFI) to facilitate autodiscovery of PEs by
other PEs. MDT-SAFI updates are BGP messages distributed between intra-AS internal BGP peer PEs. Thus, receipt of an
US
MDT-SAFI update enables a PE to autodiscover the identity of other PEs with sites for a given VPN and the default MDT (S,G)
routes to join for each. Autodiscovery provides the next-hop address of each PE, and the VPN group address for the tunnel
rooted at that PE for the given route distinguisher (RD) and route-target extended community attribute.
set protocols bgp group group-name family inet-mdt signaling
AL
Enables PIM to learn about neighbors from the MDT-SAFI autodiscovery NLRI.
A RE
SH
T
NO
DO
—
LY
ON
a VPN use the same group address. This is because the rendezvous point assignment and autodiscovery are not
accomplished over the default MDT tunnels for the group. Thus, you can configure some or all PEs in a VPN to use a different
US
group, but the same group cannot be used in different VPNs on the same PE router.
set routing-instance instance-name provider-tunnel pim-ssm group-address
multicast-address
Configures the VRF export policy. When you configure draft Rosen multicast VPNs with provider tunnels operating in
AL
source-specific mode and using the vrf-target statement, the VRF export policy is automatically generated and automatically
accepts routes from the vrf-name.mdt.0routing table.
set routing-instances ce1 vrf-target target:community-id
RN
When you configure draft Rosen multicast VPNs with provider tunnels operating in source-specific mode and using the
vrf-export statement to specify the export policy, the policy must have a term that accepts routes from the
vrf-name.mdt.0 routing table. This term ensures proper PE autodiscovery using the inet-mdt address family.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Outgoing data MDTs are shown after the outgoing default MDT. Incoming data MDTs are shown after all incoming default
MDTs.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
default MDT and identifies the tunnel mode as PIM-SSM. For the data MDTs initiated by the local PE router, the command
identifies the multicast source using the data MDT, the multicast tunnel logical interface set up for the data MDT tunnel, the
US
configured threshold rate, and current statistics. The output also provides the details for the following fields:
• C-Group: IPv4 group address in the address space of the customer’s VPN-specific PIM-enabled routing
instance of the multicast traffic destination. This 32-bit value is carried in the C-group field of the MDT join TLV
packet.
AL
• C-Source: IPv4 address in the address space of the customer’s VPN-specific PIM-enabled routing instance of
the multicast traffic source. This 32-bit value is carried in the C-source field of the MDT join TLV packet.
• P-Group: IPv4 group address in the service provider’s address space of the new data MDT that the PE router
RN
will use to encapsulate the VPN multicast traffic flow (C-Source, C-Group). This 32-bit value is carried in the
P-group field of the MDT join TLV packet.
• Data tunnel interface: Multicast data tunnel interface that set up the data-MDT.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
timeout value of each entry. The output provides the following information:
US
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
By sending the Multicast traffic by default over the default MDT forces all participating PE routers to receive the traffic no
US
matter whether they have active receivers or not. It also means that both control plane and data plane share the same
tunnel.
Since the Multicast trees in the SP Core are set up as default MDTs per customer there is a scalability issue in running a
large number of Multicast streams through the network. without a simple way of providing aggregation of the trees.
AL
ASM uses GRE tunnels for the Multicast distribution between the PE routers which adds on bot protocol overhead and
encapsulation/decapsulation. It also requires PICs supporting tunneling protocols.
One VRF on a PE router must maintain PIM adjacencies with all other VRFs of that MVPN, i.e. PIM adjacency is maintained
per MVPN per PE, not just per PE. In addition to PE adjacencies the VRF also must maintain PIM adjacencies with all of its
RN
RE
A
SH
T
NO
DO
—
LY
ON
We Discussed:
• IP multicast traffic flow;
E
• Components of IP multicast;
• How multicast addressing works;
US
A RE
SH
T
NO
DO
—
LY
ON
Review Questions
1.
E
2.
US
3.
AL
RN
TE
IN
RE
1.
Shortest path tree and rendezvous path tree.
2.
A
To verify that packets are received via the shortest path between the multicast source and the local router.
SH
3.
GLOP addressing.
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
T
NO
Chapter 10: Next Generation Multicast VPNs
DO
—
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 3 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Will Discuss:
• The flow of control traffic and data traffic in a next-generation multicast virtual private network (MVPN);
E
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
providers have become increasingly interested in looking to the Internet to deliver content in a secure environment to their
customers.
US
MPLS forwarding has evolved as well. With the advent of the point-to-multipoint LSP, an MPLS-based network can provide
multicast-like forwarding capabilities without the need for running multicast protocols.
The draft-Rosen method of delivering multicast content has some scaling limitations. For example, consider an example
where a PE has 1,000 VRFs, and each of these VRFs corresponds to an MVPN that is present on 100 PEs. The PE would
AL
need to maintain 100,000 PIM adjacencies with other PEs. The rate of PIM Hellos that the PE would need to process is
3,300 per second.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
perform functions like MVPN membership autodiscovery, selective tunnel autodiscovery, PIM join message conversion, and
active source advertisement.
US
The PIM adjacency problem between PEs that was found in draft-Rosen no longer exists. Instead, a PE router might only
need a few BGP neighbor relationships with route-reflectors, which might also be the same route-reflectors used for the
L3VPN.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
• Provider-Multicast Service Interface (PMSI): Tunnel used to transport multicast data from PE to PE. It is also
called a provider tunnel. Provider tunnels can take several forms including RSVP-traffic engineered
US
point-to-multipoint label-switched paths (LSPs), provider instance PIM distribution trees, and Multipoint Label
Distribution Protocol (mLDP).
• Inclusive-PMSI (I-PMSI): There are two type of I-PMSIs.
– Multidirectional I-PMSI: Allows all PEs of a multicast VPN (MVPN) to transmit multicast data between
AL
each other (one point-to-multipoint LSP from all PEs to all other PEs).
– Unidirectional I-PMSI: Allows a single PE to transmit multicast data to other PEs (one point-to-multipoint
LSP from a single PE to all other PEs).
RN
• Selective-PMSI (S-PMSI): A PE can transmit multicast packets to only those PEs of an MVPN that have
expressed interest in being part of the multicast forwarding tree.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
MCAST-VPN NLRI
The NLRI format for next-generation MVPN signaling can be found in RFC 6514. The MCAST-VPN NLRI is carried in MP-BGP
extensions with an AFI of 1 and SAFI of 5. When these type of routes are received from remote PEs and accepted by a policy
E
that matches on the route target community (same as L3VPNs), the receiving PE will place the routes in the MVPN routing
table-IN called bgp.mvpn.0 and then into the corresponding VRFs MVPN routing table, routing-instance.mvpn.0.
US
A RE
SH
T
NO
DO
—
LY
ON
Type 1 NLRI
The Intra-autonomous system (AS) I-PMSI autodiscovery route is the initial route type that is advertised between PEs of the
same MVPN allowing them to autodiscover one another. It is distributed to other PEs that attach to sites of the MVPN. The
E
routes carry the sending PE’s route distinguisher (RD), the sending PE’s loopback address, and a route target community to
allow for import into a VRF. In the case of an inclusive provider tunnel, the route will also be tagged with the PMSI Tunnel
US
attribute.
Type 2 NLRI
The Inter-AS I-PMSI autodiscovery route is used to discover members of an MVPN in different ASs. Inter-AS MVPNs are
AL
A RE
SH
T
NO
DO
—
LY
ON
Type 3 NLRI
Selective MVPN Autodiscovery routes are used to help build an S-PMSI. This route is advertised by the multicast source’s PE
in response to receiving a Type 6 or Type 7 route (described in subsequent slides) which are essentially requests to join the
E
multicast forwarding tree (BGP version of a PIM join). The slide shows the details of what is carried in the Type 3 route. Even
though the source PE learns that the remote PE wants to receive a particular multicast stream from a type 7 advertisement,
US
the source PE sends the type 3 as a request to the receiver PE to join the S-PMSI. The most important reason for this
message is because it is tagged with the PMSI tunnel attribute allowing the receiver PEs to know the details of the provider
tunnel.
Type 4 NLRI
AL
The Selective MVPN autodiscovery route is sent by an interested receiver PE (in the case of an RSVP-signalled LSP in the
data plane) in response to receiving a type 3 route from a source PE.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Type 5 NLRI
The Source Active autodiscovery route is advertise by a a PE that discovers a source that is attached to a locally connected
site. The PE learns of the source either from PIM register messages, Multicast Source Discovery Protocol (MSDP) source
E
active messages, or a locally connected source. The source PE sends this advertisement to all other PEs participating in the
MVPN.
US
Type 6 NLRI
The Shared Tree Join route is advertised by a receiver PE to all other PEs participating in the MVPN in response to receiving a
PIM (*,G) join from the local CE. It serves a similar purpose to the PIM (*,G) join in that it is a request to join the shared
AL
multicast tree.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Type 7 NLRI
The Source Tree Join route is advertised by a receiver PE to all other PEs participating in the MVPN in response to receiving a
PIM (S,G) join from the local CE. It serves a similar purpose to the PIM (S,G) join in that it is a request to join the source
E
multicast tree.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
1. The burden of data replication is taken off of the ingress PE. Instead, each router along the path of the LSP can
US
(RSVP only).
4. The service provider network does not need to run PIM to support multicast routing. Multicast routing of
customer traffic can occur on the same IP/MPLS design that was used to build the unicast L3VPNs.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Inclusive Trees
The simplest form of provider tunnel is the inclusive tree (I-PMSI). An inclusive tree serves an entire MVPN. In the diagram,
there is one inclusive tree that serves the blue VPN and one that serves the red VPN. Any multicast traffic arriving at the
E
source PE (PE-1) will be sent to all other PEs in the same MVPN. This works well when all remote PEs need to receive the
multicast traffic but this form of tree can be wasteful of resources (bandwidth, packet processing, and so on) when only a
US
few of the remote PEs need to receive multicast traffic. The solution to this problem is the use of selective trees described in
subsequent slides.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Selective Tree
Selective trees can be used to forward traffic for particular source and group combinations to the remote PE that specifically
request to receive that traffic. The dotted line in the diagram shows that a point-to-multipoint LSP has been built to send
E
multicast traffic for the red VPN to PE2 and PE4 only.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
2. There is an existing L3VPN between all customer sites using LDP to signal the unicast LSPs;
3. PE-1 will be acting as the customer rendezvous point (RP) (within the VRF);
4. CE-A will be acting as the customer designated router (DR) closest to the source; and
AL
A RE
SH
T
NO
DO
—
LY
ON
With no source and receivers in the network, an MVPN is enabled on all three PEs. Once enabled, each PE will advertise their
membership to the MVPN using a Type 1 route tagged with the PMSI tunnel attribute. Each PE will automatically build an
US
RSVP-signaled point-to-multipoint LSP to all other PEs. In the network shown on the slide, there will only ever be a single
source attached to PE-1. Because PE-2 and PE-3, will never be attached to a source site, the point-to-multipoint LSP that
each of them instantiated as themselves as ingress routers will never be used. It is possible to configure PE-2 and PE-3 as
receiver-only sites so that they do not build the unnecessary point-to-multipoint LSPs.
When PE-2 and PE-3 eventually receive multicast traffic from PE-1 using the point-to-multipoint LSP, they will need to use the
AL
incoming MPLS label encapsulating the multicast packets to determine which VRF to use for forwarding. Normally a
point-to-multipoint LSP is signalled with a label of 3 on the penultimate hops meaning that there would be no label
encapsulating the incoming traffic. Therefore, a virtual tunnel interface or vrf-table-label must be configured within the VRF
to allow for a non-implicit-null label to be used on the penultimate hops.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
With no source and receivers in the network, an MVPN is enabled on all three PEs. Once enabled, each PE will advertise their
membership to the MVPN using a Type 1 route tagged with the PMSI tunnel attribute. Each PE will automatically build an
US
LDP-signaled point-to-multipoint LSP to the source as advertised in the received Type 1 PMSI attribute. In the network shown
on the slide, there will only ever be a single source attached to PE-1. Because PE-2 and PE-3, will never be attached to a
source site, the point-to-multipoint LSP that is built to each of them with themselves as ingress routers will never be used. It
is possible to configure PE-2 and PE-3 as receiver-only sites so that point-to-multipoint LSPs and not built to them.
When PE-2 and PE-3 eventually receive multicast traffic from PE-1 using the point-to-multipoint LSP, they will need to use the
AL
incoming MPLS label encapsulating the multicast packets to determine which VRF to use for forwarding. Normally a
point-to-multipoint LSP is signaled with a label of 3 on the penultimate hops meaning that there would be no label
encapsulating the incoming traffic. Therefore, a virtual tunnel interface or vrf-table-label must be configured within the VRF
to allow for a non-implicit-null label to be used on the penultimate hops.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
learning of a new source in the customer’s network advertises that source in the form of the Type 5 Source Active
autodiscovery route to all other PEs of the MVPN.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
receiving the PIM joins, PE-2 and PE-3 send Type 7 Source Tree Join routes to the source PE, PE-1. Upon receiving the Type 7
advertisement from the remote PE, PE-1 sends a PIM (S, G) join upstream to the customer’s DR router, CE-A. At the point the
US
multicast forwarding tree is complete and multicast traffic forwarded from the source to receivers.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
I-PMSI Forwarding
Now that the multicast forwarding tree is complete, multicast traffic can be sent from end to end. From the source to PE-1,
multicast packets are forwarded in their native format. From PE-1 to P1, multicast packets are encapsulated in the MPLS
E
header that is associated with the point-to-multipoint LSP that uses PE-1 as the ingress router. P1 simply performs a label
swap. At P2, because of the behavior of point-to-multipoint LSP, the data traffic is replicated, the label is swapped, and then
US
sent to both remote PEs. The receiving PEs pop the incoming label and use the label to determine the VRF to use for
forwarding. The receiving PE then send the multicast traffic in its native format towards the receivers.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
2. There is an existing L3VPN between all customer sites using LDP to signal the unicast LSPs;
3. PE-1 will be acting as the customer RP (within the VRF);
4. CE-A will be acting as the customer DR closest to the source; and
AL
A RE
SH
T
NO
DO
—
LY
ON
In an S-PMSI scenario, a point-to-multipoint LSP is not built until at least one PE has a receiver attached.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
customer’s network advertises that source in the form of the Type 5 Source Active autodiscovery route to all other PEs of the
MVPN.
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Upon receiving the Type 7 advertisement from the PE-2, PE-1 sends a Type 3 S-PMSI autodiscovery route tagged with PMSI
Tunnel attribute with the leaf information required bit set. PE-2 now knows the RSVP session ID of the point-to-multipoint LSP
US
that will be used for forwarding. PE-2 then responds to PE-1 with a Type 4 Leaf autodiscovery route. PE-1 builds a
point-to-multipoint RSVP-signaled LSP to all PEs that responded with a Type 4. In this case. PE-1 builds a point-to-multipoint
LSP to a single end-point, PE-2. Finally, PE-1 sends a PIM (S, G) join upstream to the customer’s DR router, CE-A. At the point
the multicast forwarding tree is complete and multicast traffic forwarded from the source to receivers.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Upon receiving the Type 7 advertisement from the PE-2, PE-1 sends a Type 3 S-PMSI autodiscovery route tagged with PMSI
Tunnel attribute which includes a PMSI type of P2MP, IP address of the root (PE-1), and the LSP ID. PE-2 now knows
US
everything it needs to know to build an LDP signaled point-to-multipoint LSP that will be used for multicast data forwarding.
PE-2 then responds by sending a P2MP FEC to its upstream neighbor in the direction of source. This process continues until
a complete P2MP lsp is setup fro PE-2 (an egress PE) to PE-1 (ingress and root PE for the LSP). Finally, PE-1 sends a PIM (S,
G) join upstream to the customer’s DR router, CE-A. At the point the multicast forwarding tree is complete and multicast
traffic forwarded from the source to receivers.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Tunnel Services
Assuming every router is running the Junos OS, tunnel services must be enabled on certain routers. Some routers require a
Tunnel Service PIC or Adaptive Service PIC to provide tunnel services. In the case of the MX Series device, the feature just
E
A RE
SH
T
NO
DO
—
LY
ON
Junos OS Support
The slide shows the protocols that are supported when enabling next-generation MVPNs using the Junos OS.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Configuration
The slide highlights the topic we discuss next.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
MP-BGP Configuration
To allow for BGP neighbors to exchange the new MVPN NLRI, family inet-mvpn signaling must be enabled on all
participating PE routers.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The example on the slide shows how to configure an RSVP-traffic engineered point-to-multipoint LSP for use as an inclusive
provider tunnel and a selective provider tunnel. At a minimum, you must configure an inclusive provider tunnel (even when
selective is also configured) so that the PE will be able to forward a multicast packets even when they do not match the
selective group range (the inclusive tunnel will act as the default method for multicast forwarding). You can use a configured
AL
LSP template or just use the default template. To ensure that penultimate hop popping is not performed along the LSP, the
example shows the configuration of vrf-table-label. A virtual tunnel interface could also have been used.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
The example on the slide shows how to configure LDP signaled point-to-multipoint LSP for use as an inclusive provider tunnel
and a selective provider tunnel. At a minimum, you must configure an inclusive provider tunnel (even when selective is also
configured) so that the PE will be able to forward a multicast packets even when they do not match the selective group range
(the inclusive tunnel will act as the default method for multicast forwarding). To ensure that penultimate hop popping is not
AL
performed along the LSP, the example shows the configuration of vrf-table-label. A virtual tunnel interface could also
have been used.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
settings available under the mvpn hierarchy. The slide shows the configuration of the mvpn-mode. There are two options for
the mode. First is the spt-only mode which allows for only shortest path trees to be built from receiver PEs towards the
US
source (Type 7s only). The second mode is rpt-spt mode which allows for both rendezvous point based trees and shortest
path trees to be built from receiver PE to source (Type 6s and Type 7s allowed). Subsequent slides will show more options
that are available under the mvpn hierarchy.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
VRF Configuration
This slide shows the full, working VRF configuration for PE1.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Provider Tunnels
There are several options available for provider tunnels.
E
• ingress-replication: point to point LSPs (RSVP or LDP) are used for multicast data transport. Ingress PE
performs all multicast replication;
US
• lsp-p2mp: Used to configure an I-PMSI between PEs using LDP point-to-multipoint LSPs;
• mdt: Used to configure Multicast Data Tunnels as provider tunnels;
• pim-asm: Used to configure PIM any source provider tunnels;
AL
• selective: Used to configure an S-PMSI between PEs using either RSVP or LDP point-to-multipoint LSPs.
MVPN Settings
It is under the MVPN settings that you can specify whether a site is a sender-only site or receiver-only site. By default, every
TE
site is both and sender and receiver site. You can also configure the MVPN mode, traceoptions, and the upstream multicast
hop settings.
IN
A RE
SH
T
NO
DO
—
LY
ON
Monitoring
The slide highlights the topic we discuss next.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
PIM Status
To verify the status of PIM within the customer network using the show pim commands using a modifier of instance
instance-name. The command on the slide shows the (S, G) state of the PE router.
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
RE
A
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
Point-to-Multipoint LSP
Use the show rsvp session or show ldp database command to determine the status of the point-to-multipoint LSP.
In the output of the RSVP command, you can see that the outbound label for the point-to-multipoint LSP is 300096. For the
E
LDP command, the output shows that the outbound label for the P2MP LSP is 300208.
US
Forwarding Table
The command on the slide shows the routes in PE1’s forwarding table that are associated with the multicast group of
224.7.7.7 with a source of 10.0.101.2. Notice that all multicast packets of this type will be sent out of the ge-1/0/4.250
interface with a single MPLS label of 300096.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
The ingress replication tunnel can be selective or inclusive, depending on the configuration of the provider tunnel in the
routing instance.
US
The ingress-replication provider tunnel type uses unicast tunnels between routers to create a multicast distribution
tree.
The mpls-internet-multicast routing instance type uses ingress replication provider tunnels to carry IP multicast
data between routers through an MPLS cloud, using MBGP (or Next Gen)MVPN. Ingress replication can also be configured
AL
system. All multicast and unicast routes used for IP multicast are associated only with the default routing instance
(inet.0), not with a configured routing instance. The mpls-internet-multicast routing instance type is configured
for the default master instance on each router, and is also included at the [edit protocols pim] hierarchy level in the
default instance.
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
hierarchy level.
US
When a new destination needs to be added to the ingress replication provider tunnel, the resulting behavior differs
depending on how the ingress replication provider tunnel is configured:
• create-new-ucast-tunnel: When this statement is configured, a new unicast tunnel to the destination is
created, and is deleted when the destination is no longer needed. Use this mode for RSVP LSPs using ingress
replication.
AL
• label-switched-path-template: When this statement is configured, an LSP template is used for the for
the point-to-multipoint LSP for ingress replication.
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
the IP routers, through the MPLS cloud, using ingress replication tunnels for the data plane and a full-mesh IBGP session for
the control plane.
US
AL
RN
TE
IN
RE
A
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
A RE
SH
T
NO
DO
—
LY
ON
We Discussed:
• The flow of control traffic and data traffic in a next-generation MVPN;
E
A RE
SH
T
NO
DO
—
LY
ON
Review Questions
1.
E
2.
US
3.
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
Lab: MVPNs
The slide provides the objectives for this lab.
E
US
AL
RN
TE
IN
RE
1.
The draft-Rosen required that the provider network be running PIM for signaling. The next-generation approach uses BGP to
signal the providers network and does not require PIM be configured in the core.
A
2.
Type 1: Intra-AS Inclusive MVPN Membership Discovery
SH
Type 2: Inter-AS Inclusive MVPN Membership Discovery
Type 3: Selective MVPN Autodiscovery Route
Type 4: Selective MVPN Autodiscovery Route for Leaf
T
Type 5: Source Active Autodiscovery Route
NO
Type 6: Shared Tree Join Route
Type 7: Source Tree Join Route
3.
The first hop designated router, the candidate rendezvous points, and all PE routers participating in the multicast network,
DO
unless using vrf-table-label option, require the use of a tunnel services interface.
—
LY
ON
E
US
AL
RN
TE
IN
A RE
SH
T
NO
DO
—
LY
ON
• Content Explorer: Junos OS and ScreenOS software feature information to find the right software release and
hardware platform for your network.
• Feature Explorer: Technical documentation for Junos OS-based products by product, task, and software
release, and downloadable documentation PDFs.
AL
• Learning Bytes: Concise tips and instructions on specific features and functions of Juniper technologies.
• Installation and configuration courses: Over 60 free Web-based training courses on product installation and
configuration (just choose eLearning under Delivery Modality).
RN
• J-Net Forum: Training, certification, and career topics to discuss with your peers.
• Juniper Networks Certification Program: Complete details on the certification program, including tracks, exam
details, promotions, and how to get started.
TE
• Technical courses: A complete list of instructor-led, hands-on courses and self-paced, eLearning courses.
• Translation tools: Several online translation tools to help simplify migration tasks.
IN
www.juniper.net
Junos Layer 3 VPNs
A RE
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
www.juniper.net
Acronym List
RE
ABR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . area border router
A
ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Resolution Protocol
AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .autonomous system
SH
ASBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .autonomous system boundary routers
ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asynchronous Transfer Mode
CapEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .capital expenses
CCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . circuit cross-connect
CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . customer edge
T
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . class-of-service
NO
CSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constrained Shortest Path First
DLCI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .data-link connection identifier
DPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dense Port Concentrator
DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .designated router
FPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flexible PIC Concentrator
GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .generic routing encapsulation
DO
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface
HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High-Level Data Link Control
IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . internal BGP
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol
IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Group Management Protocol
—
IGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interior gateway protocol
I-PMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inclusive-PMSI
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP version 4
JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Networks Certification Program
LY
RID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . router ID
RP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rendezvous point
SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . security association
SAFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . subsequent address family identifier
TE
S-PMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selective-PMSI
TCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . translational cross-connect
VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .virtual LAN
VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual private LAN service
IN
RE
WRR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . weighted round-robin
A
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN