Juniper MPLS and VPNs PDF
Juniper MPLS and VPNs PDF
Juniper MPLS and VPNs PDF
10.a
Instructor Guide
Volume 1
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.
Contents
iv • Contents www.juniper.net
Chapter 14: BGP Layer 2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Overview of Layer 2 Provider-Provisioned VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-3
BGP Layer 2 VPN Operational Model: Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-11
BGP Layer 2 VPN Operational Model: Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-22
Preliminary Layer 2 VPN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33
Layer 2 VPN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-40
Layer 2 interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-57
Monitoring and Troubleshooting Layer 2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-60
Lab 10: BGP Layer 2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-71
www.juniper.net Contents • v
vi • Contents www.juniper.net
Course Overview
This five-day course is designed to provide students with MPLS-based virtual private network (VPN)
knowledge and configuration examples. The course includes an overview of MPLS concepts such
as control and forwarding plane, RSVP Traffic Engineering, LDP, Layer 3 VPNs, next-generation
multicast virtual private networks (MVPNs), BGP Layer 2 VPNs, LDP Layer 2 Circuits, and virtual
private LAN service (VPLS). This course also covers Junos operating system-specific
implementations of Layer 2 control instances and active interface for VPLS. This course is based on
the Junos OS Release 10.3R1.9.
Through demonstrations and hands-on labs, students will gain experience in configuring and
monitoring the Junos OS and in device operations.
Objectives
After successfully completing this course, you should be able to:
• Explain common terms relating to MPLS.
• Explain routers and the way they forward MPLS packets.
• Explain packet flow and handling through a label-switched path (LSP).
• Describe the configuration and verification of MPLS forwarding.
• Understand the information in the Label Information Base.
• Explain the two label distribution protocols used by the Junos OS.
• Configure and troubleshoot RSVP-signaled and LDP-signaled LSPs.
• Explain the constraints of both RSVP and LDP.
• Explain the path selection process of RSVP without the use of the Constrained
Shortest Path First (CSPF) algorithm.
• Explain the Interior Gateway Protocol (IGP) extensions used to build the Traffic
Engineering Database (TED).
• Describe the CSPF algorithm and its path selection process.
• Describe administrative groups and how they can be used to influence path selection.
• Describe the default traffic protection behavior of RSVP-Signaled LSPs.
• Explain the use of primary and secondary LSPs.
• Explain LSP priority and preemption.
• Describe the operation and configuration of fast reroute.
• Describe the operation and configuration of link and node protection.
• Describe the LSP optimization options.
• Explain the purpose of several miscellaneous MPLS features.
• Explain the definition of the term “Virtual Private Network”.
• Describe the differences between provider-provisioned and customer-provisioned
VPNs.
• Describe the differences between Layer 2 VPNs and Layer 3 VPNs.
• Explain the features of provider-provisioned VPNs supported by the Junos OS.
• Explain the roles of Provider (P) routers, Provider Edge (PE) routers, and Customer
Edge (CE) routers.
• Describe the VPN-IPv4 address formats.
• Describe the route distinguisher use and formats.
• Explain the RFC 4364 control flow.
Day 1
Chapter 1: Course Introduction
Chapter 2: MPLS Fundamentals
Lab 1: MPLS Fundamentals
Chapter 3: Label Distribution Protocols
Lab 2: Label Distribution Protocols
Chapter 4: Constrained Shortest Path First
Lab 3: CSPF
Day 2
Chapter 5: Traffic Protection and LSP Optimization
Lab 4: Traffic Protection
Chapter 6: Miscellaneous MPLS Features
Lab 5: Miscellaneous MPLS Features
Chapter 7: VPN Review
Chapter 8: Layer 3 VPNs
Lab 6: VPN Baseline Configuration
Day 3
Chapter 9: Basic Layer 3 VPN Configuration
Lab 7: Layer 3 VPN with Static and BGP Routing
Chapter 10: Troubleshooting Layer 3 VPNs
Chapter 11: Layer 3 VPN Scaling and Internet Access
Lab 8: Route Reflection and Internet Access
Chapter 12: Layer 3 VPNs—Advanced Topics
Lab 9: GRE Tunnel Integration
Day 4
Chapter 13: Multicast VPNs
Chapter 14: BGP Layer 2 VPNs
Lab 10: BGP Layer 2 VPNs
Chapter 15: Layer 2 VPN Scaling and COS
Chapter 16: LDP Layer 2 Circuits
Lab 11: Circuit Cross Connect and LDP Layer 2 Circuits
Chapter 17: Virtual Private LAN Service
Day 5
Chapter 18: VPLS Configuration
Lab 12: Virtual Private LAN Service
Chapter 19: Interprovider VPNs
Lab 13: Carrier-of-Carrier VPNs
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
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.
CLI Undefined Text where the variable’s value Type set policy policy-name.
is the user’s discretion and text
ping 10.0.x.y
where the variable’s value as
GUI Undefined shown in the lab guide might Select File > Save, and type
differ from the value the user filename in the Filename field.
must input.
Introductions
The slide asks several questions for you to answer during class introductions.
Prerequisites
The slide lists the prerequisites for this course.
Additional Resources
The slide provides links to additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.
Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and
feedback. Depending on the class you are taking, please complete the survey at the end of the class,
or be sure to look for an e-mail about two weeks from class completion that directs you to complete
an online survey form. (Be sure to provide us with your current e-mail address.)
Submitting your feedback entitles you to a certificate of class completion. We thank you in advance
for taking the time to help us improve our educational offerings.
Course List
You can access the latest Education Services offerings covering a wide range of platforms at
http://www.juniper.net/training/technical_education/.
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice
them now so that your instructor can best address your needs during class.
This chapter contains no review questions.
MPLS Foundation
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
IGP Forwarding
This slide shows metric-based traffic engineering in action. When sending traffic from a network
connected to R1 to a network connected to R6, traffic is routed through R3 because it has a lower
overall cost (3, as opposed to 4, through R4). Note that not only the traffic destined for networks
connected to R6 follow the upper path, but also all traffic for networks connected to R7 and any routers
downstream from these routers.
Redirecting Traffic
At some point, sending all of the traffic for R6 and R7 and points beyond through the R3 might not be
the best idea. For example, a lot of local traffic to the R3 might exist, and this traffic might delay the
traffic to R6 and R7 while the path through R4 is underutilized. Whatever the actual cause, you might
want to route at least some of the traffic to some destinations over the lower links and through R4.
Suppose traffic for R7 needs to be rerouted onto this lower path.
Rerouting traffic for R7 by raising metrics along the current path, as shown in the slide, has the desired
effect. Traffic to R7 now follows the path with cost 4 instead of cost 5. But forcing the traffic to use R4,
by raising the metric on the upper path, has the unintended effect of causing traffic destined for R6 to
do the same and flow through R4.
Because interior gateway protocol (IGP) route calculation is topology driven and based on a simple
additive metric, such as the hop count or an administrative value, the traffic patterns on the network are
not taken into account when the IGP calculates its forwarding table. As a result, traffic will not be evenly
distributed across the network’s links, causing inefficient use of expensive resources. Some links may
become congested, while other links remain underutilized. This result might be satisfactory in a smaller
network with less traffic, but in larger networks or networks with many connections, you must control the
paths that traffic takes in order to balance the traffic load. In other words, you need more control for
realistic traffic engineering than the usual IGP method of sending all traffic to a group of destinations
over the same, single best path.
Possible Destabilization
Changing of IGP metric to force traffic path movements has more drawbacks than just moving the traffic
to downstream destinations along with the target to the new path. Adjusting metrics manually can have
a severe destabilizing effect on a network, especially a large one. As Internet service provider (ISP)
networks became more richly connected, it became more difficult to ensure that a metric adjustment in
one part of the network did not cause problems in another part of the network. Adjusting metrics just
tended to move problems around. The low-cost links and paths became saturated, while the higher-cost
links and paths remained almost devoid of traffic.
There was little to no real control over the process. All traffic followed the path with the lowest IGP metric
because no other standard mechanism to distribute traffic flow existed. There were no rules and few
guidelines to follow about which metrics to adjust and by how much to adjust them. Traffic engineering
based on metric manipulation offered a trial-and-error approach, rather than a scientific solution to an
increasingly complex problem.
Benefits of ATM
ATM switches use what are called virtual circuits (VCs) to logically connect the routers and forward
traffic. From the perspective of the routers these VCs are viewed as point-to-point connections, but as
you can see the physical topology can be much more complicated. If a section within the network is
deemed to be overutilized then the VCs can be altered, moving traffic to a less utilized section, without
changing the topology from the routers perspective. Another benefit for using an ATM network is the
ability to gather statistics on a per-VC basis. With standard IGP routing there was no way to gather
relevant statistics because all traffic either entering or leaving the router was counted. Being able to
count the traffic entering or leaving a VC allowed the ISPs to evaluate the network load of each VC and
engineer their network accordingly.
Continued on next page.
MPLS was originally designed to make IP routers as fast as ATM switches for handling traffic. MPLS
uses label values to make its forwarding decisions as traffic traverses the network. It is still
commonly believed that MPLS somehow significantly enhances the forwarding performance of
label-switching routers. However, it is more accurate to say that exact-match lookups, such as those
performed by MPLS and ATM switches, historically have been faster than the longest-match lookups
performed by IP routers.
In any case, recent advances in silicon technology allow application-specific integrated circuit
(ASIC)-based route-lookup engines to run just as fast as MPLS or ATM virtual path identifier (VPI)/virtual
channel identifier (VCI) lookup engines, so MPLS is no longer seen as just a faster way of routing.
Things to Remember
The following are some of the key things to remember about working with MPLS labels:
• MPLS labels can be either assigned manually or set up by a signaling protocol running in
each LSR along the path of the LSP. Once the LSP is set up, the ingress router and all
subsequent routers in the LSP do not examine the IP routing information in the labeled
packet—they use the label to look up information in their label forwarding tables. Changing
Labels by Segment
• Much as with ATM VCIs, MPLS label values change at each segment of the LSP. A single
router can be part of multiple LSPs. It can be the ingress or egress router for one or more
LSPs, and it also can be a transit router of one or more LSPs. The functions that each router
supports depend on the network design.
• The LSRs replace the old label with a new label in a swap operation and then forward the
packet to the next router in the path. When the packet reaches the LSP’s egress point, it is
forwarded again based on longest-match IP forwarding.
• There is nothing unique or special about most of the label values used in MPLS. We say
that labels have local significance, meaning that a label value of 10254, for example,
identifies one LSP on one router, and the same value can identify a different LSP on
another router.
Terminology
The slide highlights the topic we discuss next.
Label-Switching Routers
An LSR understands and forwards MPLS packets, which flow on, and are part of, an LSP. In addition, an
LSR participates in constructing LSPs for the portion of each LSP entering and leaving the LSR. For a
particular destination, an LSR can be at the start of an LSP, the end of an LSP, or in the middle of an
LSP. An individual router can perform one, two, or all of these roles as required for various LSPs.
However, a single router cannot be both entrance and exit points for any individual LSP.
Router = LSR
This course uses the terms LSR and router interchangeably because all Junos OS routers are capable of
being an LSR.
Label-Switched Path
An LSP is a one-way (unidirectional) flow of traffic, carrying packets from beginning to end. Packets must
enter the LSP at the beginning (ingress) of the path, and can only exit the LSP at the end (egress).
Packets cannot be injected into an LSP at an intermediate hop.
Generally, an LSP remains within a single MPLS domain. That is, the entrance and exit of the LSP, and all
routers in between, are ultimately in control of the same administrative authority. This ensures that
MPLS LSP traffic engineering is not done haphazardly or at cross purposes but is implemented in a
coordinated fashion.
MPLS Configuration
The slide highlights the topic we discuss next.
Interface Configuration
The default behavior of an interface is to accept IP packets. In the Junos OS, this is done by adding the
protocol family inet with an IP address to the interface you are working with. In order for the interface to
recognize and accept MPLS packets we have to also configure the MPLS protocol family under the
interfaces that will be participating in your MPLS domain. Sample output demonstrates an interface
configuration with both families applied.
The transit static LSP is added to the mpls.0 routing table. You should configure each static LSP using a
unique name and at least one unique incoming label on the router. Each transit static LSP can have one
or more incoming labels configured. If a transit LSP has more than one incoming label, each would
effectively operate as an independent LSP, meaning you could configure all of the related LSP attributes
for each incoming label. The range of incoming labels available is limited to the standard static LSP
range of labels (1,000,000 through 1,048,575). To verify that a static LSP has been added to the
routing table, issue the show route table mpls.0 command.
Since we must configure the pop action at the penultimate router we do not need to configure the static
LSP on the egress router. The packet coming into the egress router will be routed based on its Layer 3
information.
Additional Information
It is best practice make your LSP names unique to the path. This allows you to quickly identify the path
you are looking for when troubleshooting or making alterations to the configuration.
In the Junos OS you can configure your outgoing label with values from 0 to 1,048,575 but will only
accept a incoming label between 1,000,000 and 1,048,575 on the transit router. The Junos OS allows
the outgoing label to be configured this way to allow interoperability with other vendor equipment that
may not have the same static label restriction on the transit routers.
The Junos OS will also allow the static label to be swapped and sent with a label value of 0 from the
penultimate router. This will allow the egress router to honor the EXP bits when queuing traffic through
the static LSP.
Route Resolution
The example in the next series of slides shows how a router uses the information learned by BGP to
forward transit traffic into a LSP. We begin by examining how traffic is forwarded to the 64.25.1/24
network from the perspective of the Core.
Things start with the 64.25.1/24 prefix being learned by the R5 router through its EBGP session to
Site2. The R1 router then learns about 64.25.1/24 through its internal BGP (IBGP) session to R5. R1
installs the prefix as active and readvertises the prefix to the Site1 router, again using EBGP.
In this example, routers in Site1 begin sending traffic to 64.25.1/24 prefixes through R1. When this
transit traffic arrives at the R1 router, it must decide how to forward this transit traffic to 64.25.1/24.
So far, nothing in this example has anything to do with MPLS or traffic engineering. This has simply been
a recap of conventional BGP operation.
Suggested Resolution
This slide solves the 64.25.1/24 hidden route problem at R1 through a next-hop self policy applied at
the R5 router. A next-hop self solution is one of several viable ways to correct unreachable BGP next
hops.
Setting next-hop self on the R5 router results in the route advertisement for 64.25.1/24 arriving at the
R1 router with a BGP next hop that represents the R5 router’s loopback address. The R1 router can
resolve the R5 router’s loopback address because the IGP running throughout the autonomous system
(AS) advertises that information.
At this stage, transit connectivity to 64.25.1/24 destinations is now provided by the core. This
connectivity is based on IGP forwarding.
Ingress Router
The previous example demonstrated how signaled LSPs are installed in the inet.3 routing table.
RSVP, LDP, and Static LSPs install the IP prefix to the egress router into the inet.3 table on the ingress
router. We will discuss RSVP and LDP in later chapters.
The next-hop data for entries in the inet.3 table consist of the LSP’s egress interface and the label
value assigned by the LSP’s first downstream router.
Note that the various routing protocols continue to use the inet.0 IP routing table to determine the
current active route to IP destinations.
Continued on next page.
Implicit NULL
Implicit Null is the default behavior in the Junos OS from the perspective of the egress router. This
operation tells the upstream router (penultimate) that they should pop the label and forward the packet
without a MPLS header.
Explicit NULL
Explicit Null can be configured on the egress router under the [edit protocols mpls] hierarchy. This
operation tells the upstream router (penultimate) they it needs to forward the packets on to the egress
router with a MPLS header and the egress router will handle the pop action.
Review Questions
1.
The ingress router uses the destination IP address of the packet to make its forwarding decision. It will consult
the inet.0 and inet.3 routing table to resolve the next-hop.
2.
The default behavior in the Junos OS is for the egress router to signal the penultimate hop router to pop the
mpls header and send the packet downstream without a mpls header. This is known as penultimate hop popping.
3.
The transit router will use the mpls.0 routing table to make its forwarding decisions. These decisions are made
based on the incoming label value.
RSVP
The Junos OS uses RSVP as the label distribution protocol for traffic engineered LSPs.
• RSVP was designed to be the resource reservation protocol of the Internet and “provide
a general facility for creating and maintaining distributed reservation state across a set
of multicast or unicast delivery paths” (RFC 2205). Reservations are an important part
of traffic engineering, so it made sense to continue to use RSVP for this purpose rather
than reinventing the wheel.
• RSVP was explicitly designed to support extensibility mechanisms by allowing it to carry
what are called opaque objects. Opaque objects make no real sense to RSVP itself but
are carried with the understanding that some adjunct protocol (such as MPLS) might
find the information in these objects useful. This encourages RSVP extensions that
create and maintain distributed state for information other than pure resource
reservation. The designers believed that extensions could be developed easily to add
support for explicit routes and label distribution.
Continued on the next page.
Thus, RSVP provides MPLS-signaled LSPs with a method of support for explicit routes (“go here, then
here, finally here…”), path numbering through label assignment, and route recording (where the LSP
actually goes from ingress to egress, which is very handy information to have).
RSVP also gives MPLS LSPs a keepalive mechanism to use for visibility (“this LSP is still here and
available”) and redundancy (“this LSP appears dead…is there a secondary path configured?”).
LDP
LDP associates a set of destinations (prefixes) with each data link layer LSP. This set of destinations
is called the FEC. These destinations all share a common data LSP path egress and a common
unicast routing path. LDP supports topology-driven MPLS networks in best-effort, hop-by-hop
implementations. The LDP signaling protocol always establishes LSPs that follow the contours of the
IGP’s shortest path. Traffic engineering is not possible with LDP.
RSVP
The slide lists the topics we cover in this chapter. We discuss the highlighted topic next.
RSVP
RSVP is a generic signaling protocol designed originally to be used by applications to request and
reserve specific quality-of-service (QoS) requirements across an internetwork. Resources are
reserved hop by hop across the internetwork; each router receives the resource reservation request,
establishes and maintains the necessary state for the data flow (if the requested resources are
available), and forwards the resource reservation request to the next router along the path. As this
behavior implies, RSVP is an internetwork control protocol, similar to Internet Control Message
Protocol (ICMP), Internet Group Management Protocol (IGMP), and routing protocols.
RSVP does not transport application data, nor is it a routing protocol. It is simply a label distribution
protocol. RSVP uses unicast and multicast IGP routing protocols to discover paths through the
internetwork by consulting existing routing tables.
Traceoptions
Traceoptions are configured under the protocol that you want to troubleshoot. Because the
information gathered can be very extensive it is recommended that you only turn on traceoptions
when troubleshooting a specific issue. The more specific you can make the flag options, the easier it
is to locate the information you need to review. As displayed in earlier slides you can also use match
and find conditions to narrow down the information displayed when looking at the file. In our
example we capture all available information for RSVP communication. We also included the detailed
tag to increase the detail of information captured in the RSVP-traceoptions file.
Configuration Example
As noted in the slide, all configuration examples will be from the perspective of the ingress router
(R1). We will use the topology and IP addressing illustrated on this slide to demonstrate the
configuration required to create an LSP that egresses at R5.
All verification and show commands will be displayed from the ingress router (R1) or one of the
transit routers (R2).
Point-to-Multipoint LSPs
A point-to-multipoint MPLS LSP is an RSVP LSP with multiple destinations. By taking advantage of
the MPLS packet replication capability of the network, point-to-multipoint LSPs avoid unnecessary
packet replication at the ingress router.
Lets walk through the packet processing detailed on the slide. Router R1 is configured with a
point-to-multipoint LSP to routers R3 and R5. When router R1 sends a packet through the
point-to-multipoint LSP, router R2 replicates the packet and forwards it on to routers R3 and R5.
Point-to-Multipoint Details
A point-to-multipoint LSP allows you to use MPLS for point-to-multipoint data distribution. This
functionality is similar to that provided by IP multicast. A branch can be added or removed from the
main point-to-multipoint LSP without disrupting traffic. The unaffected parts of the LSP continue to
function normally. A router can be configured as both a transit and an egress router for different
branch LSPs of the same point-to-multipoint LSP. Link protection can also be used with
point-to-multipoint LSPs. Link protection can provide a bypass LSP for each of the branch LSPs that
make up the LSP. If any of the primary paths fail, traffic can be quickly switched to the bypass.
Point-to-multipoint LSPs can be configured either statically, dynamically, or as a combination of static
and dynamic LSPs. You can enable graceful Routing Engine switchover (GRES) and graceful restart
for point-to-multipoint LSPs at ingress and egress routers.
Multicast Example
One of the obvious benefits of using point-to-multipoint LSPs is that its forwarding properties are very
multicast-like. The Junos OS allows for the configuration of point-to-multipoint LSPs as a
replacement for multicast routing protocols in the core of a network. In the example on this slide and
the next, P1 is configured for a point-to-multipoint that terminates on both R3 and R5. A multicast
source is attached to R1 and a receiver is attached to both R3 and R5. As multicast data arrives from
the source to R1, R1 encasulates the multicast traffic into an MPLS header and sends the MPLS
packet into the core. R2 will then receive that traffic, replicate the traffic, swap the labels, and send
the traffic out of its two outgoing interfaces. R3 and R5 will eventually receive the multicast traffic
even without a multicast routing protocol running in the core.
LDP
The slide lists the topics we cover in this chapter. We discuss the highlighted topic next.
Purpose of LDP
LDP associates a set of destinations (prefixes) with each LSP. This set of destinations is called the
FEC. These destinations share a common LSP path and egress router, as well as a common unicast
routing path.
LDP maps groups of prefixes to an egress router at the end of an LSP. LDP manages the LSP to the
egress router for each FEC. LDP is not related to RSVP or traffic engineering concepts from previous
lectures.
LDP maps the FECs (prefixes) to label values. The LSP forwarding paths look like a unicast
forwarding path, in that MPLS traffic for the ultimate destination is forwarded along the unicast
forwarding tree.
LDP allows multiple prefixes to share the same label mapping. No constraints are allowed when
signaling the LSPs. The LSPs must follow the IGP best path. LDP merges together traffic from
different tunnels, which results in fewer total tunnels than would be required with RSVP.
LDP will create a LSP tree for each FEC from every possible ingress point in the LDP network to the
egress point. Each LDP speaking router will advertise the addresses reachable via a MPLS label into
the LDP domain. The label information is exchanged in a hop by hop fashion so every LSR in the
domain will become an ingress router to all other routers in the network. This process creates a full
mesh LDP environment. The slide displays what LSPs will be generated for the FEC egressing at R5.
Neighbor Discovery
The discovery process can either send a hello message to 224.0.0.2 (basic discovery) or to a specific
address (extended discovery), in both cases using UDP encapsulation and port 646. 224.0.0.2 is the
all routers on this subnet multicast address. Note that a station’s response to a hello message
indicates its desire to establish an LDP session with the neighboring router.
Transport Address
The transport address is used to determine which side is active. The transport address is placed into
the Hello message as a transport address object. If the transport address object is not specified, the
source address of the hello packet is used to determine the active router.
Session Maintenance
An LDP peer must receive an LDP packet every keepalive period to prevent the tear down of neighbor
state. Any LDP protocol message is acceptable for keepalive purposes, so keepalive messages are
sent only in the absence of other LDP traffic. Either end can shut down the session by issuing a
shutdown message. If a router has multiple links to an LDP peer then hellos are sent across all of the
links. As long as one of the links can continue to exchange hellos, the LDP session remains active.
See the last section on the next page for more detail on choosing an LDP transport address.
The LDP hello messages enable LDP routers to discover one another and to detect the failure of a
neighbor, or the link, to that neighbor. Hello messages are sent periodically on all interfaces on which
LDP is enabled. By default, LDP sends hello messages every 5 seconds. This value can be
configured depending on the network requirements.
The hold time determines how long a router can wait for a hello message before declaring the
neighbor lost. The configured value is sent inside of hello messages to inform the receiving router
how often it should expect to receive a hello; this mechanism means that hello intervals do not be
the same between neighbors. The default hold time is 15 seconds; this value represents the
recommended setting of three times the hello interval.
Continued on the next page.
LDP Tunneling
You can tunnel LDP LSPs over RSVP-signaled LSPs using label stacking. Note that you must enable
LDP on the lo0.0 interface to support extended neighbor discovery needed for this application.
Additionally, you must configure the LSPs over which you want LDP to operate by including the
ldp-tunneling statement as shown.
Use the show ldp session command with the detail switch to confirm LDP graceful restart
settings.
Review Questions
1.
The only router that requires configuration is the ingress router. The other routers need to have protocols
MPLS and RSVP configured but do not need information about the label-switched-path.
2.
There are many RSVP Objects. We discussed the SESSION, LABEL_REQUEST, EXPLICIT_ROUTE
(ERO), RECORD_ROUTE (RRO), SESSION_ATTRIBUTE, RSVP-HOP, LABEL, and the STYLE
objects within this chapter.
3.
No. The Junos OS does not support traffic engineering for LDP signaled LSPs. You can however, us LDP
tunneling over RSVP traffic engineered LSPs to apply traffic engineering to the LDP traffic.
Bandwidth Reservation
It is possible for an LSP to be configured to reserve bandwidth along the path of the LSP. During the
setup process for an LSP configured for bandwidth (as shown in slide), each downstream router will
receive a request to reserve bandwidth for the LSP in the form of the traffic specification (TSpec)
object. Each router along the path will make its own individual decision as whether it has enough
available bandwidth on its egress interface for the LSP. To determine whether or not there is enough
available bandwidth, a router will sum the bandwidth of all LSPs traversing the egress interface and
subtract it from the total bandwidth for the interface. If there is not enough available bandwidth, the
LSP will fail to be instantiated and the upstream routers will be informed with a PathErr message.
By default, the bandwidths described on the slide are only logical and used for LSP setup. The
amount of traffic that actually traverses an LSP is not enforced. It is possible, however, to override
the default behavior and have the ingress router police the traffic that enters an LSP however. This
can be done by configuring auto-policing or configuring a firewall filter an applying directly to
the specific LSP.
RSVP Bandwidth
Whether or not the CSPF algorithm is being used, when RSVP is being used for LSP signaling in a a
network, every interface on every router will have an associated available bandwidth associated with
it. By default, the available bandwidth for LSP reservation is equivalent to the physical speed of the
interface. This can be overridden by one of the methods shown on the slide.
CSPF Algorithm
The slide highlights the topic we discuss next.
IGP Extensions
Both OSPF and IS-IS can propagate additional information through some form of extension. IS-IS
carries different parameters in type/length/value (TLV) tuples, which are propagated within a level;
these TLVs do not propagate between levels. OSPF, on the other hand, uses Type 10 opaque LSAs to
carry traffic engineering extensions. Type 10 LSAs have an area flooding scope, meaning that the
information is propagated within a given area only; OSPF traffic engineering extensions do not cross
area border routers (ABRs). The MPLS Traffic Engineering Information carried by these IGP
extensions is defined in RFCs 3630 and 4203 for OSPF, and RFCs 3784 and 4205 for IS-IS.
Information Propagated
The TLVs listed here are based on IS-IS traffic engineering extensions. OSPF supports more or less
the same parameters; the primary difference is how the extended information is propagated (TLV
versus opaque LSA).
• Router ID (TLV 134): Single stable address, regardless of node’s interface state. The
/32 prefix for router ID should not be installed into the forwarding table or it can lead to
forwarding loops for systems that do not support this TLV.
• Extended IP Reachability (TLV 135): One bit used for route leaking (up/down bit);
extends metrics from 6 bits to 32 bits.
Continued on next page.
TED Contents
CSPF uses the TED to calculate explicit paths across the physical topology. It is similar to IGP
link-state database (LSDB) and relies on extensions to the IGP, but it is stored independently of the
IGP database.
Traffic engineering requires detailed knowledge about the network topology as well as dynamic
information about network loading. The information distribution component is implemented by
defining relatively simple extensions to the IGPs so that link attributes are included as part of each
router's link-state advertisement (LSA). The standard flooding algorithm used by the link-state IGPs
ensures that link attributes are distributed to all routers in the routing domain. Some of the traffic
engineering extensions to be added to the IGP link-state advertisement include maximum link
bandwidth, maximum reserved link bandwidth, current bandwidth reservation levels, and link
coloring.
User-Provided Constraints
You can influence the outcome of the CSPF path selection process by specifying one of more of the
following constraints when defining an RSVP-signaled LSP:
• Bandwidth: The bandwidth to reserve for this LSP. The reserved bandwidth is calculated
against each link’s available bandwidth. The available bandwidth is the bandwidth
remaining after the subscription factor is applied to the link and all existing link
subscriptions are removed.
• Hop count: The maximum number of hops to extend the path to bypass the next
downstream node when creating a fast-reroute detour.
• Link color: Administrative groups, also known as link coloring or resource class, are
manually assigned attributes that describe the color of links, such that links with the
same color conceptually belong to the same class. You can use administrative groups to
implement a variety of policy-based LSP routing controls.
• Priority: Specifies the setup and hold priority for the LSP. New setup priorities are
compared with existing hold values. When not enough bandwidth is available to satisfy
all LSPs concurrently, a given link is considered in the path only when the new LSP’s
setup priority is stronger than the hold priority of existing LSPs.
• EROs: Both CSPF and non-CSPF LSPs can be constrained with one or more ERO routing
directives.
Negative Feedback
Junos OS automatically retains knowledge of RSVP PathErr messages for a short period of time. This
knowledge prevents the TED from resignaling in the same direction that caused the original error. By
default, the system maintains knowledge of PathErr messages for 20 seconds, configurable from
0 to 240 seconds in the [edit protocols mpls] hierarchy with the
rsvp-error-hold-time command.
Random
If more than one path is available after running the CSPF algorithm, a tie-breaking rule is applied to
choose the path for the LSP. Three tie-breaking rules are available: random, least fill, and most fill.
The actual rule used depends on the specifics of your configuration. The default tie-breaking method
is random, which, as you might surmise, chooses one of the qualifying paths at random. This rule
tends to place an equal number of LSPs on each link, regardless of the available bandwidth.
Least Fill
The least-fill option chooses the path with the largest minimum available bandwidth ratio. This rule
tries to equalize the reservation levels on each link. This form of load balancing might be preferred
when the goal is to minimize the total number of LSPs that are disrupted when a link failure occurs.
Continued on next page.
Configuration
To explicitly configure a tie-breaking behavior, include the random, least-fill, or most-fill
statement at the [edit protocols mpls label-switched-path path-name] hierarchy
level. Note that you do not have to explicitly configure random load balancing as this is the default.
An Interesting Question
Step 6 of the CSPF algorithm, as explained on a previous page, indicates that if no decision is
reached after the router processes the first five steps of the algorithm, the paths with the smaller
hop count are selected. When multiple paths remain, the tie-breaking algorithm moves on to
consider fill-related criteria.
Because least fill looks for the largest available bandwidth ratio, you might expect the middle links to
be selected because they have 95 and 85 available bandwidth ratios. However, these links are not
chosen because they have more hops. The two outer paths have their available bandwidth ratios
compared because they have lower (and equal) hop counts. Therefore, the bottom path, which has
an available bandwidth ratio of 57 ((1000-430)/1000) is selected over the top link, which has an
available bandwidth ratio of 50 ((1000-500)/1000).
Note that the same logic is followed regardless of the actual bandwidth available on a link. For
example, if the outer paths were Fast Ethernet links with lower available bandwidth ratios than the
two middle paths—which could be Gigabit Ethernet with really high available bandwidth ratios—the
CSPF hop count rule will still eliminate the middle links due to their higher hop-counts. Even if the
Gigabit Ethernet links have huge amounts of percentage or actual bandwidth available, the hop
count rule holds sway over what paths are considered equal, and therefore subject to a
load-balancing decision.
Administrative Groups
The slide highlights the topic we discuss next.
IGP Advertisements
A traffic engineering aware IGP communicates the administrative group of each interface as a 32-bit
(4 bytes) bit mask. Each of the bit values in 32-bit sequence represents a different administrative
group.
Color Assignments
Each bit value is correlated through configuration to a human-friendly name within Junos OS. This
capability helps to simplify router management, as the name silver often means more to the typical
human than the hexadecimal value of 0x02, for example.
These names are often assigned as colors, but they do not have to be a color; they can be any
descriptive term you want. Each link can have one or more bits enabled, and can therefore be
associated with one or more colors simultaneously. The colors advertised by each link are displayed
in both hexadecimal and in symbolic form in the output of show ted database extensive
command. When multiple bits are set in the TED, the order of the colors displayed correlates to the
order of the bits that are set. When no colors are assigned, the 32 bits default to all zeros
(0x00000000).
Review Questions
1.
OSPF supports the flooding of the opaque type 10 LSA. IS-IS supports the flooding of extended TLVs for
traffic engineering. Both of the extensions to the protocols support the advertisement of rsvp bandwidth,
administrative group, and router ID.
2.
Some possible user inputs are bandwidth requirement, administrative group requirement, explicit route, and
priority.
3.
The default CSPF tie-breaking algorithm is random.
4.
When configuring an LSP an administrator can specify which administrative groups the LSP can traverse.
The administrator can specify several administrative group constraints for an LSP by using the
include-any, include-all, and the exclude statements.
Lab 3: CSPF
The slide provides the objectives for this lab.
Network Failures
When a network failure occurs along the path of an RSVP-signaled LSP, traffic that is currently
traversing the LSP will be dropped. In the example, at the instant that the link between R3 and R4
fails, traffic that has already encapsulated in an MPLS header by R1 and forwarded downstream will
be dropped. Also, until R1 receives PathTear message for the LSP, R1 may continue forwarding traffic
using the LSP. That traffic will also be dropped. The time that it takes for traffic flow to be restored
depends on the time it takes R1 to be notified of the failure followed as well as resignal a new LSP
that will bypass the failed link. There are several features, like fast reroute and link protection which
are described later in this chapter, that can significantly reduce down time.
R1 Receives PathTear
When R1 receives the PathTear, it considers the LSP down and deletes the Path and Resv state
block. The LSP is no longer a valid next-hop for routes in inet.3 (or any other routing table) so the /32
route associate with the LSP in inet3 is removed. Also, any BGP routes that had been using the LSP
as a next-hop will need to have their next-hop recalculated. Now at this point, if the LSP was only
being used to forward standard IP traffic (non-VPN traffic) packet drops may stop and new packets
could be forwarded using next hops learned by using interior gateway protocol (IGP) routes in the
inet.0 table. However, in a virtual private network (VPN) scenario as described in future chapters, a
route in inet.3 must exist to forward traffic for a VPN between Site 1 and Site 2. Traffic between VPN
sites might still continue to be dropped due to the lack of a valid route in the inet.3 table.
Along with the churn that occurs in the routing tables as described above, R1 will also attempt to
reestablish the failed LSP by sending a Path message downstream towards the egress router.
The second question is designed to test your understanding of secondary paths and how they are
handled in the face of failures.
The answer to the second question depends on whether or not select unconditional or
select manual is configured. If neither is configured and the primary path is absent or down,
Junos OS attempts to establish an active path by signaling each secondary LSP in the order in which
it appears in the configuration. If the first secondary physical path fails or cannot be established, the
router attempts to signal the next secondary physical path, and so on. The select
unconditional and select manual parameters override this behavior.
Monitoring Preemption
This slide shows that at 20:36:39, the green LSP’s primary path, path one, was preempted and the
secondary path, path two, became active. This scenario uses equal setup and hold values for each LSP,
with the priority values set to 6 for the green LSP. In this example, another LSP with a higher priority 0
0 has caused the preemption of the green LSP’s primary path, path one, which in turn results in the
establishment of a secondary path, path two. The green LSP’s secondary path is configured with a
lower bandwidth requirement to allow it to establish in the event the primary path is preempted. There is
no reference to the LSP with 0 0 priority in the screen captures because this is a priori knowledge. The
truncated capture below continues the output shown on the slide. The output confirms that the
secondary path, path two, became active at the same time the primary path was preempted:
*Secondary two State: Up
Priorities: 7 0
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4)
172.22.221.2 S 172.22.203.2 S 172.22.204.2 S 172.22.223.1 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
172.22.221.2 172.22.203.2 172.22.204.2 172.22.223.1
83 Sep 14 20:36:39.286 Selected as active path
82 Sep 14 20:36:39.284 Record Route: 172.22.221.2 172.22.203.2 172.22.223.1
81 Sep 14 20:36:39.284 Up
...
Test Understanding
You can assume in this example that all links with existing LSPs have less than 10 M available.
Therefore, the only way to establish LSP Red is for it to preempt one of the existing LSPs. Can you
determine which LSP will be preempted by LSP Red?
The setup priority for Red is 6 (the first number). The hold priority (the second number) for LSPs Green
and Purple are both less than 6, which gives these LSPs a stronger hold priority that will prevent their
preemption. In contrast, LSP Blue has a hold a priority of 7, which is weaker that LSP Red’s setup
priority. Thus, LSP Red can only preempt LSP Blue. Note the IS-IS metric has no effect on LSP
preemption.
Question: What if LSP Red had priority [3 7]?
Answer: This is a trick question because such a priority setting is not allowed. Recall that an LSP
cannot have a setup priority that is stronger than its hold setting.
Fast Reroute
The slide highlights the topic we discuss next.
When you define a secondary physical path in the standby state, the router presignals an alternate
physical path for the LSP. However, traffic transiting the network is still lost while the network
forwards information about failed links (and the failed primary path) to the ingress router. When the
ingress router learns that a link is down, it begins using the alternate path immediately, but during
this time traffic that is in transit or still being presented to the primary path is lost. Fast reroute
provides a way for intermediate LSRs to immediately start forwarding traffic over an alternate route
while simultaneously alerting the ingress LSR to the presence of downstream link or node failures.
When an active physical path fails and a detour is available, the upstream router sends a PathErr
message to the ingress router. This message triggers new CSPF computations and a switchover to an
alternate path if available. If a fast reroute detour is not available, the downstream node sends a
ResvTear message and begins withdrawing the MPLS labels, which brings down the LSP. A fast
reroute path might stay up indefinitely if an alternative primary path is not found.
By default, fast reroute has a limit of six hops out of the way to get to the next downstream path. You
can configure a larger or smaller number with the hop-count parameter.
This output shows that a detour branch, used to skip a downstream neighbor is active.
Bypass LSPs
The slide highlights the topic we discuss next.
Protects Interfaces
Link protection is the Junos OS nomenclature for the facility backup feature defined in RFC 4090. The
link protection feature is interface based, rather than LSP based. The slide shows how the R2 node is
protecting its interface and link to R3 through a bypass LSP that is calculated using CSPF and the node’s
TED.
While fast reroute attempts to protect the entire path of a given LSP, you can apply link protection on
a per-interface basis as needed. LSPs must be tagged for them to make use of a bypass LSP, and
you can provide an ERO list to influence the CSPF-based routing of the bypass LSP. Note that a
bypass LSP must terminate on the adjacent downstream node, but the bypass LSP can transit other
nodes as shown on the slide.
Node Protection
Node protection is the Junos OS nomenclature for the facility backup feature defined in RFC 4090. Node
protection uses the same messaging as link protection. The slide shows that R2 is protecting against the
complete failure of R3 through a bypass LSP that is calculated using CSPF.
LSPs must be tagged for node-link protection to make use of the bypass LSPs, and you can provide
an ERO list to influence the CSPF-based routing of the bypass LSP.
Note that the mere presence of a bypass LSP does not, in itself, provide protection to the LSPs that
might happen to egress the protected interface. You must add the link-protection keyword to
the ingress node’s LSP definitions for all LSPs that are expected to benefit from the existence of
bypass LSPs.
This slide shows how the output of a show rsvp interface extensive command indicates
the presence of a bypass LSP at the transit node. Note that link protection is an RSVP feature, and as
a result, the resulting bypass LSPs are not listed in the output of show mpls lsp commands.
LSP Optimization
The slide highlights the topic we discuss next.
LSP Rerouting
Once an LSP is established, changes in topology or available resources might result in the existing path
becoming suboptimal. A subsequent CSPF recomputation might result in the determination that a better
path is now available. When optimization is enabled, LSPs can be rerouted as a result of periodic CSPF
recomputations. Without optimization the LSP has a fixed path and cannot take advantage of newly
available network resources, at least until the next topology change or operator induced clearing breaks
the LSP and forces recomputation of a new path. Note that optimization is not related to failover; a new
path is always computed when topology failures occur that disrupt an established path.
Enable Optimization
Because of the potential system overhead involved, you should carefully consider the frequency at
which routers perform optimization runs. By default, the optimize-timer is set to 0 (that is, it is
disabled). LSP optimization is only meaningful for CSPF LSPs. Due to statistical characteristics that arise
in large topologies, a network can effectively synchronize and end up trying to recalculate all LSPs at the
same time when all reoptimization timers are set the same. To prevent this behavior, the LSP
reoptimization timer is modified to include a randomization factor when recalculating LSPs. The
randomization factor is fixed and cannot be modified.
Note that you can manually trigger optimization with the operational mode clear mpls lsp
optimize command.
Optimization Rules
By default, an LSP can only have its path optimized when all of the following criteria are met. These rules
are intentionally conservative as stability is better than being optimal in many cases:
1. The new path is not higher in CSPF metric. (The metric for the old path is updated during
computation, so if a recent link metric changed somewhere along the old path, it is
accounted for.)
2. If the new path has the same CSPF metric, it must not have more hops.
3. The new path does not cause preemption. (This is to reduce the ripple effect of one
preemption causing yet more preemption.)
4. The new path does not worsen congestion overall. This is determined by comparing the
percentage of available bandwidth on each link traversed by the new and old paths,
starting from the most congested links.
When all the above conditions are met, then if the new path has a lower CSPF metric, it is accepted. If
the new path has an equal CSPF metric and lower hop count, it is accepted. If you choose least fill as a
load-balancing algorithm and if the new path reduces congestion by at least 10 percent aggregated over
all links it traversed, it is accepted. For random or most-fill algorithms, this rule does not apply.
Otherwise, the new path is rejected.
Continued on next page.
To force the reoptimization to be based upon IGP metric only, enable the optimize-aggressive
keyword. This setting negates the tests outlined in Steps 2, 3, and 4 on the previous page. You can
manually trigger aggressive optimization with a clear mpls optimize-aggressive
command. The LSP must still comply with the original CSPF constraints when optimized aggressively,
but no attention is paid to available bandwidth ratios, as explained in the sample calculation above,
so you will tend to see more LSP rerouting when operating in aggressive mode.
Review Questions
1.
When a primary is active and there is a failure along the path the ingress router will signal the secondary LSP
to provide protection for traffic while the primary is down.
2.
Fast reroute protects an entire LSP from failures along the path. Link protection provides protection for the
failure of a single link.
3.
Aggressive optimization only takes IGP metric into consideration. Normal optimization also takes into
consideration number of hops, congestion, and preemption.
Route Review
Start by looking at your EBGP routes to determine what the next hop is. As displayed on the slide, we
do have an active route. The protocol next hop for this route is 10.0.11.2 and you can tell that the
next hop was resolved in the inet.0 table. You can also see that there is not an entry in the inet.3
routing table. This is because the LSP terminates at the loopback address of R4. Because BGP will
first try to resolve the next hop in the inet.3 table, we need to add this prefix in order to route the
traffic through the LSP.
MPLS Forwarding
Another option for traffic engineering is mpls-forwarding. The mpls-forwarding option is
designed to overcome some of the problems associated with the use of traffic-engineering
bgp-igp. Specifically, the option is designed to prevent the overshadowing of IGP routes in the
inet.0 routing table when RSVP or LDP-signaled LSPs are copied from inet.3 into inet.0 so
that LSPs can be used when forwarding to internal destinations.
By keeping the IGP routes active, your export policies continue to operate as expected, even though
forwarding might occur over an LSP next hop. Unlike the bgp-igp option, mpls-forwarding
maintains copies of the LSPs in the inet.3 routing table where they can still be used for normal
VPN or BGP next-hop resolution.
Forwarding Adjacencies
The slide highlights the topic we discuss next.
LSP Metrics
The slide highlights the topic we discuss next.
Automatic Bandwidth
The slide highlights the topic we discuss next.
Option Meaning
adjust-interval Time to adjust LSP bandwidth (300..4294967295
seconds)
TTL Handling
The slide highlights the topic we discuss next.
MPLS Pings
The slide highlights the topic we discuss next.
Review Questions
1.
Including the active option when installing a prefix for a RSVP LSP installs the route in the inet.0 routing
table and allows both the IGP and BGP to use the LSP.
2.
The default resignaling interval is 24 hours when using the auto-bandwidth feature.
3.
First no-decrement-ttl is only configured on the ingress router and no-propagate-ttl must be
configured on all LSRs in the path. Second, using no-decrement-ttl allows you to change default behavior
on a per LSP basis while no-propagate-ttl is only allowed at the global level and applies to all LSPs.
Overview of VPNs
The slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
Uses IP Infrastructure
Most companies today provide their employees with access to the Internet for e-mail and web
browsing services. The Internet has become part of everyday life in today’s society. By utilizing the
Internet as the public infrastructure for building VPNs, companies can use their existing equipment
to reduce costs.
Subscriber Benefits
VPNs deployed over the Internet can lower operational expenses for companies by making it possible
to use a single network connection to provide multiple services. A company no longer needs a Frame
Relay network to provide VPN services and Internet connectivity for e-mail services; it can all be done
using one Internet connection.
Provider Benefits
VPNs can also create an additional source of revenue for the provider. ISPs can now offer not only
Internet service but also value-added VPN services. Everybody wins!
CPE-Based VPNs
The slide highlights the topic we discuss next.
Applications
For a customer with a strong security requirement, IPsec is a perfect fit. However, key management
and routing between sites are the customer’s responsibility.
Security Services
Security services include the following:
• Access control;
• Data origin authentication;
• Replay protection;
• Data integrity;
• Data privacy (encryption); and
• Key management.
Provider-Provisioned
The slide highlights the topic we discuss next.
Outsourced VPNs
MPLS-based VPNs make it possible for a service provider to offer value-added services to new and
existing customers using its existing network infrastructure.
The Junos OS supports Layer 3 provider-provisioned VPNs based on RFC 4364. In this model, the
provider edge (PE) routers maintain VPN-specific routing tables called VPN route and forwarding
(VRF) tables for each of their directly connected VPNs. To populate these forwarding tables, the CE
routers advertise routes to the PE routers using conventional routing protocols like RIP, OSPF and
EBGP.
The PE routers then advertise these routes to other PE routers with Multiprotocol Border Gateway
Protocol (MP-BGP) using extended communities to differentiate traffic from different VPN sites.
Traffic forwarded from one VPN site to another is tunneled across the service provider’s network
using MPLS. The MPLS-based forwarding component allows support for overlapping address space
and private addressing.
Virtual Routers
A virtual router functions much like an RFC 4364 PE router in that it maintains site-specific routing
instances and tables for use in the forwarding of IP-based VPN traffic. A significant difference,
however, is that in the virtual router approach, the PE router does not terminate the routing protocol
used by the CE device. In effect, the two PE routers create a sham link representing the connection
between the PE routers for use in the flooding of OSPF LSAs across the provider’s backbone.
CCC Drawbacks
The following list details some of the drawbacks of CCC:
• CE and PE router configuration can be complex, especially during adds, moves, and
changes. The customer must coordinate with the service provider.
• Each data-link connection identifier (DLCI)/PVC requires a dedicated set of MPLS LSPs.
There can be no sharing of the LSP when using CCC.
• CCC as a Layer 2 VPN solution is only appropriate for small numbers of individual
private connections.
• Interface types must be the same at all CE device locations. For instance, if Frame Relay
is used at one VPN site then Frame Relay must be used at all other sites. However, the
Junos OS has a feature called translational cross-connect (TCC) that can be used when
there are different interfaces types at the CE locations.
Routing Is CE to CE
Because the provider delivers Layer 2 circuits to the customer, the routing for the customer’s private
network is entirely in the hands of the customer. From the perspective of the attached CE device,
there is no operational difference between a Frame Relay service, CCC, and a BGP Layer 2 VPN
solution.
Subscriber Advantages
With Layer 2 VPNs the customer can outsource Layer 2 circuits to the provider over an existing
Internet access circuit while maintaining control over the routing of its traffic. Also, because the
provider is encapsulating Layer 2 traffic for transport using MPLS, the customer can use any Layer 3
protocol—not only IP-based protocols.
Provider Advantages
Layer 2 and Layer 3 VPNs can coexist by using the same MPLS transport and signaling protocols. The
provider can now sell Frame Relay or ATM circuits to different customers using its existing IP core.
Automatic provisioning of Layer 2 circuits simplifies the processes of adds, moves, and changes.
Also, the use of label stacking greatly improves efficiency and scalability.
Review Questions
1.
A VPN is a private network that is constructed over a shared, public infrastructure such as Frame Relay, an
ATM network, or the Internet.
2.
The primary difference is that the CPE VPN requires the customer equipment to create and manage tunnels
for the private IP traffic. A provider-provisioned VPN solution is a VPN that relies on the provider’s
equipment to create and manage tunnels for the private traffic using MPLS as the enabling technology.
3.
The first and most notable difference is with a Layer 2 VPN solution, the backbone routing is the
responsibility of the customer. With a Layer 3 VPN solution, the backbone routing is handled by the
provider. Another difference is that with a Layer 2 VPN solution, non-IP traffic can be passed from site to
site. With a Layer 3 VPN solution the traffic has to be IP.
Provider Routers
Provider (P) routers are located in the provider’s core. These routers do not carry VPN customer
routes, nor do they interface in the VPN control and signaling planes. This is a key aspect of the RFC
4364 scalability model; only PE routers are aware of VPN customer routes, and no single PE router
must hold all VPN customer state information.
P routers are involved in the VPN forwarding plane where they act as label-switching routers (LSRs)
performing label swapping (and popping) operations.
VPN Sites
A VPN site is a collection of devices that can communicate with each other without the need to
transit the provider’s backbone. A site can range from a single location with one router to a network
consisting of many geographically diverse routers.
Mapped to a VRF
Each VPN site is attached to at least one PE router and can be dual-homed with multiple connections
to different PE routers. Each site is associated with a site-specific VRF table in the PE routers. It is
here that the PE router maintains the routes specific to that site and, based on policy, the routes for
remote sites to which this location can communicate.
On this slide, PE 1 has three VRF tables—one for each of its attached VPN sites. The VRF tables store
routes learned from the attached site, as well as routes learned through MP-BGP interaction with
remote PE routers. In the latter case, VPN policy determines which routes are copied into which VRF
tables based on the presence of a VPN-IPv4 route attribute known as a route target.
Site Separation
When a packet is received from a given site, the PE router performs a longest-match Layer 3 lookup
against only the entries housed in that site’s VRF table. This separation permits duplicate addressing
among VPN customers with no chance of routing ambiguity.
Distributed by MP-BGP
Labeled VPN routes are exchanged over the MP-BGP sessions, which terminate on the PE routers.
The examples on the slide show both the Type 0 and Type 1 route distinguisher formats. The first
example shows the 2-byte administration field with the 4-byte assigned number field (Type 0).
VPN-IPv4 Routes
The ingress PE router adds (or prepends) the route distinguisher to the IPv4 prefix of routes received
from each CE router. These VPN-IPv4 routes are then exchanged between PE routers using MP-BGP. The
egress router converts the VPN-IPv4 routes back into IPv4 routes before inserting them into the site’s
routing table.
The VPN address family exists only in the signaling or control plane between PE routers. Routes that
match VPN policy, and are therefore installed into a particular VRF table, have the 8-byte route
distinguisher (and MPLS label) removed so that they appear as conventional IPv4 routes in the VRF
table. Because the site-specific VRF tables provide route isolation, there is no need for the route
distinguisher once a route is safely stored away in a VRF table. Only signaling exchanges between
PE routers use the VPN-IPv4 address format.
The sole purpose of the route distinguisher is to make what would otherwise be identical addresses
incomparable. The PE routers do not interpret or act on the fields in the route distinguisher for any
other reason.
Control Flow
VPN control flows exist at various places in the RFC 4364 environment. First, we have the signaling
exchange between CE and PE routers that can take the form of OSPF, RIP, BGP, or even static routing.
The control exchanges between PE and CE routers are totally independent, due to the PE routers
terminating the local CE-PE signaling flows. The PE routers then use MP-BGP to convey routes from
site-specific VRF tables for the purposes of populating the VRF tables on remote PE routers.
Finally, the need for LSPs in the provider’s networks results in the presence of MPLS-related signaling in
the form of either RSVP or LDP.
Data Flow
Data flow relates to the actual forwarding of VPN traffic from CE router to CE router using MPLS
label-based switching through the provider’s core.
Administrative Policy
The use of policy in the PE routers determines the connectivity that results between VPN sites. While site
connectivity requirements are defined by the VPN customers, the act of implementing this policy is the
job of the service provider.
Mistakes made by the provider when defining and implementing VPN policy can lead to security
breaches at worst and broken VPN connectivity at best.
VPN policy is extremely flexible and can result in full-mesh, partial-mesh, or hub-and-spoke
topologies. The combination of VPN import and export policy determines the resulting site
connectivity.
BGP extended communities are defined in RFC 4360. Extended communities’ attributes have a
structure similar to the route distinguisher in that they are 8 bytes in length and support the same
type code options and structure.
Route Advertisements
Each VPN-IPv4 route advertised by a PE router contains one or more route target communities. These
communities are added using VRF export policy or explicit configuration.
Receiving Routes
When a PE router receives route advertisements from remote PE routers, it determines whether the
associated route target matches one of its local VRF tables. Matching route targets cause the PE router
to install the route into all VRF tables whose configuration matches the route target.
Routing Exchange
The following sequence of slides discusses the end-to-end exchange of routing information between
CE routers belonging to the same VPN.
CE-4 sends the routes associated with VPN A Site 2 to its attached PE router. The 10.1/16 prefix can be
exchanged using OSPF, RIP, or BGP. Static routing can also place a site’s routes into the local PE router’s
VRF table.
Whatever protocol is used between CE-4 and PE-2, the operation of this protocol is terminated by the
PE router. This termination provides isolation of the VPN site’s routing protocol and the MP-BGP
protocols used to convey the routes between PE routers. This isolation improves scalability and
stability as malfunctions in the PE-CE routing protocol tend to be limited to that PE-CE pairing.
Routes received by a local CE device are automatically installed into the VRF table associated with
that site.
The PE router evaluates the route based on its configuration. If the VRF export policy accepts the
route, or if a VRF target is configured, the PE router converts the address into the VPN-IPv4 format by
adding the configured route distinguisher. At this time the PE router also chooses a 20-bit MPLS
label value used to associate received traffic with this VRF table. Lastly, the PE router associates the
route with one or more extended communities. At a minimum, the route will have a route target
community added.
In Step 4, PE-2 generates a BGP update message containing the route learned from CE4 at VPN Site
A. This route is sent to all MP-BGP peers configured on the PE router that have successfully
negotiated the support of the VPN-IPv4 address family. Other routes learned from the CE device that
share common community attributes can be packed into a single NLRI advertisement.
PE-1 now associates the RID of PE-2 as the next hop for 10.1/16 when forwarding traffic that
matches the prefix and was received on its RED VRF interface.
Label Association
When VPN routes are advertised, part of the NLRI is the VRF label chosen by the advertising PE router.
This label is often called the inner label because it is always found at the bottom of the label stack. The
purpose of this label is to associate received packets with the correct VRF table.
The receiving PE router must be able to resolve the RID of the advertising route to an MPLS LSP stored
in the inet.3 table. If an LSP does not exist to the advertising PE router, the route is hidden due to an
unusable next hop. VPN traffic can only be forwarded across the provider’s backbone using MPLS
switching. If an LSP to the egress PE router does not exist, the VPN route can never be used.
The result of this process is a two-level label stack used to forward packets across the provider’s
backbone, and then to associate the traffic with a specific VRF table on the receiving PE router.
Common Labels
RFC 4364 allows the PE router to issue a single VRF label for all routes belonging to a common VRF
interface or to allocate a unique label for each route being advertised. The Junos OS takes the former
approach because it drastically reduces the number of VRF labels that must be managed. Compliant
implementations that use per-route VRF label assignment are interoperable with this
one-label-per-VRF-interface approach, however.
Where wanted, you can use routing policy to control or refine the route exchange between PE and
CE routers further. This policy would function in addition to the VRF import and export policy
discussed in this section.
Traffic Forwarding
The slide highlights the topic we discuss next.
On this slide, the CE device performs a longest-match lookup on a packet addressed to 10.1/16.
This lookup results in the CE device forwarding the packet to the IP address associated with the
PE router’s VRF interface.
Assuming that a match is found, the PE router associates the packet with two labels: the VRF label
originally advertised with the route, and an outer MPLS label, assigned by either LDP or RSVP, which
is used to associate the packet with the LSP between ingress and egress PE routers.
The PE router performs a double label push operation involving both the VRF and MPLS labels. The
VRF label associates the packet with the correct VRF table on the egress PE router while the MPLS
label associates the packet with the LSP that terminates on the egress PE router. The ingress
PE router now forwards the labeled packet to the next-hop LSR along the LSP’s path.
The use of exact match MPLS forwarding allows the P routers to forward the packet towards the
egress PE router correctly, without any awareness of the labeled packet’s contents. This concept is
key to RFC 4364 scalability, because this MPLS capability is what allows P routers to remain
unaware of the VPN.
The last P router in the LSP’s path performs a pop operation, which results in a single-level label
stack. The packet is now forwarded to the LSP’s egress point with only the VRF label.
After mapping the packet to a specific VRF interface, the VRF label is popped, and the packet is sent
to the CE device attached to that VRF interface.