02 TER36075 V3.1 AX Ed.1 PDF

Copyright 2014 Alcatel-Lucent. All Rights Reserved.
This page is left blank intentionally

2
TERMS OF USE AND LEGAL NOTICE

Alcatel-Lucent provides this training course to you subject to these Terms of Use and Legal Notice. Your use of this training course
and/or this site constitutes your acceptance of and agreement to these Terms of Use and Legal Notice. These Terms of Use and Legal
Notice, as well as the contents of this training course, may be updated or amended by Alcatel-Lucent from time to time without prior
notice to you. Your use of the Alcatel-Lucent training materials after such update or amendment constitutes your acceptance of and
agreement to said updated or amended Terms of Use and Legal Notice.
SAFETY WARNING
Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages present. Always
observe all safety precautions and do not work on the equipment alone. The user is strongly advised not to wear conductive jewelry
while working on the products. Equipment referred to or used during this course may be electrostatic sensitive. Please observe correct
anti-static precautions.
PERMISSION TO USE CONTENT
The information, communications, scripts, photos, text, video, graphics, music, sounds, images and other materials provided in this
training course (collectively the "Content"), is intended for the lawful use of employees of Alcatel-Lucent and other authorized
participants in this Alcatel-Lucent training course. You are hereby granted a non-exclusive, non-transferable permission to access and
use the Content solely for your personal training and non-commercial use. This permission may be terminated by Alcatel-Lucent at
any time for any reason or no reason, with or without notice. You must immediately cease use of the Content upon such termination.
COPYRIGHTS AND TRADEMARKS
The unauthorized copying, displaying or other use of any Content from this training course is a violation of the law and Alcatel-Lucents
corporate policies. The Content is protected in France, the U.S. and other countries by a variety of laws, including but not limited to,
copyright laws and treaty provisions, trademark laws, patent laws and other proprietary rights laws (collectively, "IP Rights"). In
addition to Alcatel-Lucents IP Rights in the Content, in part and in whole, Alcatel-Lucent, and any of the third parties who have
licensed and/or contributed to the Content, owns a copyright in the formatting and presentation of the Content.
Alcatel-Lucent does not grant you any permission to use the Content other than the permission expressly stated in these Terms of Use
and Legal Notice. All other use of Content from this training course, including, but not limited to, modification, publication, transmission,
participation in the transfer or sale of, copying, reproduction, republishing, creation of derivative works from, distribution, performance,
display, incorporation into another training course or presentation, or in any other way exploiting any of the Content, in whole or in
part, for uses other than those expressly permitted herein is strictly prohibited and shall not be made without Alcatel-Lucents prior
written consent. All characters appearing in this training course are fictitious. Any resemblance to real persons, living or dead, is purely
coincidental.
There may be a number of proprietary logos, marks, trademarks, slogans and product designations found in the Content. Alcatel,
Lucent, Alcatel-Lucent and the Alcatel-Lucent logos are trademarks of Alcatel-Lucent. All other trademarks are the property of their
respective owners. Alcatel-Lucent does not grant you a license to use any of the foregoing logos, marks, trademarks, slogans and
product designations in any fashion. Granting of the right to access and use the Content for training purposes does not confer upon
you any license under any of Alcatel-Lucents or any third party's IP Rights.
DISCLAIMER
ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM, DAMAGE, OR ANY SPECIAL,
EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND (INCLUDING WITHOUT LIMITATION
LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT LIABILITY OR OTHERWISE, THAT ARISES OUT
OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE CONTENT OR THE TRAINING COURSES BY YOU, OR (B)
ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS, DIRECTORS, AGENTS OR EMPLOYEES IN CONNECTION WITH THE
CONTENT OR THE TRAINING COURSES (INCLUDING, WITHOUT LIMITATION, THE USE OF OR INABILITY TO USE ANY COMPONENT
OF THE CONTENT OR TRAINING BY YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT SUCH EXCLUSION OF WARRANTIES OR
LIMITATION OF LIABILITIES AND SO THE FOREGOING EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITY MAY NOT APPLY
TO YOU.
GOVERNING LAW
These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is governed by
the laws of the country that governs your employment contract, if applicable. If any provision of these Terms of Use and Legal Notice,
or the application thereto to a person or circumstance, is held invalid or unenforceable by law, statute or a court of competent
jurisdiction, for any reason, then such provision shall be modified and/or superseded by a provision that reflects the intent of the
original provision as closely as possible. All other provisions of these Terms of Use and Legal Notice shall remain in full force and
effect. You may not assign these Terms of Use or any permission granted hereunder without Alcatel-Lucents prior written
consent. Nothing herein shall be deemed an employment agreement or an offer of employment or an alteration in any way of a users
terms of employment with or within Alcatel-Lucent.
Copyright 2013 Alcatel-Lucent. All Rights Reserved

3
Welcome to 7705 SAR 7705 SR

Mobile Backhaul
1. Seamless MPLS
1. Seamless MPLS Overview
2. Seamless MPLS Lab Exercises

4

TER36075_V3.1-AX-English-Ed1 Module 1.1 Edition 1
Appendix 1 Module 1 Page 1
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
Last name, first name
First edition


Page
1 Seamless MPLS Overview
1.1 Why Seamless MPLS?
1.2 Decouple Transport Layer from Services
1.3 Inter-Region Transport Layer for Seamless MPLS
1.4 Creating an end-to-end Transport Layer using Seamless MPLS
1.5 Implementing Services with Seamless MPLS
1.6 Extending IP/MPLS to the access node with LDP DoD
1.7 Extending IP/MPLS to the access node with LDP FEC to BGP Stitching
1.8 LDP DoD and LDP FEC to BGP Stitching
2 Seamless MPLS Resiliency

2.1 Seamless MPLS End-to-End Resiliency
2.2 Service Redundancy - Pseudowire Redundancy
2.3 VLL Service Endpoints
2.4 Active Path Failure Scenario
2.5 Inter-Region Tunnel Redundancy - BGP FRR (Edge PIC)
2.6 Intra-Region Tunnel Redundancy - LDP FRR using LFA
2.7 LDP FRR (with LFA) - Failure and Restoration
2.8 Intra-Region Tunnel Redundancy - RSVP FRR (MPLS FRR)
2.9 Comparison of RSVP FRR 1:1 and Facility Backup
14
3 Configuration
3.1 Seamless-MPLS Enabling Technologies
3.2 Set Up Requirements
3.3 OSPF Configuration
3.4 Verify OSPF Configuration
3.5 LDP Configuration
3.6 Verify LDP Configuration
3.7 Verify LDP FRR Configuration
3.8 RSVP and LSP Configuration
3.9 Verify LSP Configuration
3.10 RSVP FRR Configuration
3.11 Verify RSVP FRR Configuration
3.12 Core Policy Configuration
3.13 Verify Policy Configuration
3.14 Core BGP Configuration
3.15 BGP Configuration with RSVP
3.16 Verify BGP Configuration
3.17 Verify BGP Configuration with LDP in the Core
3.18 Verify BGP Configuration with RSVP in the Core
3.19 Verify Tunnel Configuration
3.20 Metro Policy and BGP Configuration
3.21 SDP Configuration
3.22 Verify SDP and Targeted LDP Configuration
3.23 Epipe Configuration
3.24 Verify Epipe Configuration
3.25 Epipe PW Redundancy Configuration
3.26 Verify Epipe Configuration
24
4 BGP Fast Re-Route

4.1 BGP Fast Re-Route Overview
4.2 BGP FRR in Base Router
4.3 BGP FRR in L3VPN/VPRN
4.4 BGP FRR labeled IPv4 Routes
59


The figure above depicts a multi-region network with two metro regions (Metro 1 and Metro 2)
interconnected by a Core region. Typically, each region is operated independently. Depending on the
service deployed, the service end-points may be within the same metro region or across different
regions. Deploying a service from one metro region to another requires provisioning at several
intermediate points in the end-to-end network, making troubleshooting and fault recovery more complex.
For instance, deploying a Layer 2 point-to-point service from one metro region to another may require
provisioning of multiple segments within the metro-core regions, with appropriate mappings at the
region boundaries. A preferred approach would be to deploy a single end-to-end service with minimal
coordination between regions.
Additionally, service providers are constantly challenged by the evolving needs of their services mix:
Fixed-Mobile Convergence (FMC) and evolution to LTE
Integrated business services (Internet, VPNs)
Cloud services: seamless access to the datacenter
Based on a set of fairly common assumptions, the Seamless MPLS draft (draft-ietf-mpls- seamless-mpls)
is one of the architecture options available to extend MPLS networks to integrate metro and core
regions into a single MPLS domain. It provides a robust framework which enables service providers to
deploy scalable and flexible end-to-end services.
Seamless MPLS offers the following key attributes:
Scalability and resiliency (recognizing some nodes have limited capabilities): Access nodes can scale
in number up to the thousands and are typically optimized for simplicity and lower cost. Seamless
MPLS helps scale the end-to-end network to more than 100,000 MPLS devices, recognizing that some
nodes (e.g., access) have limited capabilities.

Seamless MPLS offers the following key attributes (contd):

A single end-to-end MPLS domain: Seamless MPLS extends the core region and integrates metro
regions into a single MPLS domain. This single domain makes managing and troubleshooting the
transport and services layer more efficient.
A network without boundaries (seamless): Seamless MPLS allows MPLS-based services to be
established between any two endpoints, without per-service configuration in intermediate nodes.
Rapid Fault detection and recovery: Seamless MPLS supports end-to-end fault detection, fast
protection (and end-to-end operations, administration and maintenance (OAM) functions.
Decoupling of transport layer from services: Seamless MPLS allows services to be provisioned
wherever they are needed, no matter how the underlying transport is
laid out. This is achieved by implementing a three-layer hierarchy as shown in the diagram above,
consisting of a transport layer and a service layer.

As shown in the figure above, a Seamless MPLS network consists of multiple regions: Metro1,
Core and Metro 2. With other end-to-end MPLS options (e.g., end-to-end Label Distribution Protocol
(LDP) in a flat network) Interior Gateway Protocol (IGP) or MPLS signaling information is not
contained within the region and is exchanged across regions. This increases the size of
routing/forwarding tables as well as the MPLS state within individual routers. The Seamless MPLS
model addresses this challenge by introducing a hierarchy of transport and service layers. The
Seamless MPLS transport layer consists of an inter-region tunnel and an intra-region tunnel.
Inter-region border gateway protocol (BGP) transport tunnel
The inter-region transport tunnel must minimize scaling constraints on routing nodes within the
end-to-end network. This requires controlling how reachability information is propagated across
region boundaries. Each region communicates using end-to-end transport tunnels set up by RFC
3107 (carrying label information in BGP). BGP was built to handle boundary control and is
therefore the best choice to create the inter-region transport tunnel.
RFC 3107 (carrying label information in BGP) specifies how the label mapping information for a
particular route is piggybacked in the same BGP update message used to distribute the route itself.
When BGP is used to distribute a particular route, it can also be used to distribute an MPLS label
mapped to that route, as part of Network Layer Reachability Information(NLRI) in the multiprotocol
extensions attributes :
NLRI is encoded as one or more triples of the form <length, label, prefix>
A region may represent an Open Shortest Path First (OSPF) area, Intermediate System to
Intermediate System (IS-IS) level, OSPF/IS-IS instance, or even an autonomous system (AS). The
Area Border Router (ABR) nodes act as Route Reflectors (RRs) for the region and act as a RR client
to the core RRs (P1). The network represents an inter- area scenario and hence uses iBGP between
RRs and RR clients. Provider Edge (PE) loopbacks and label bindings are advertised by Labeled
BGP.
Figure above depicts two inter-region transport tunnels:

1. Inter-region tunnel between PE-11 and PE-21
2. Inter-region tunnel between PE-12 and PE-S
These tunnels provide the PE to PE reachability across regions and provide the inner tunnel label
of the transport layer hierarchy. For tunnel 1, the ABR nodes (ABR-21/ABR-22) receive the
loopback and advertise the loopback and a label with next hop self to ABR-11 and ABR-12. The
NHS is to let the node receiving the label (in this case ABR-11 and ABR-12) to know that the next
hop for this label is the node advertising the label (in this case ABR-21/ABR-22). These ABRs, in
turn, advertise the loopback with next hop self to PE-11. Note: The Seamless MPLS draft suggests
that only the local ABRs change the next hop to self (e.g. for PE-21 loopback, ABR-21 changes the
next hop to self but not ABR-11). While this approach has some scalability advantages, it requires
that PE routers in Metro 1 have RSVP or LDP reachability to all ABR nodes in the core area.
Upon initial configuration, BGP tunnels are established automatically between PE nodes in the endto-end network using the mechanism described above. This includes tunnels between PE nodes
within a metro as well as PE nodes between metros. Often, BGP tunnel connectivity may not be
required between all PE nodes.
A key benefit of the BGP-based approach is the ability to use BGP policies to limit (permit/deny)
propagating loopback reachability to different parts of the network on an as-needed basis. BGP
filtering policies based on IPv4 prefixes or BGP communities may be configured on specific nodes
within the network to prevent loopback propagation (and hence BGP tunnel creation beyond that
point).
Intra-region LDP/RSVP-TE transport tunnel
The intra-region transport tunnels provide transport for the inter-region BGP tunnel within each
region. These tunnels provide the outer tunnel label of the transport layer hierarchy. This intraregion tunnel may use LDP or Resource Reservation Protocol with Traffic Engineering (RSVP-TE)
and is used to switch the packet between BGP peers (i.e. routes point to the BGP next hop).
As described earlier, the initial configuration creates the inter-region tunnels between PE nodes and
intra-region tunnels between BGP peers. This forms the transport layer of the hierarchy. Once the
transport layer is created, services can be provisioned end-to-end.
The figure above shows two service examples,
1. A Layer 2 Virtual Private LAN Service (VPLS) between PE-11 and PE-21. This may be a business
service offered across metro 1 and metro 2. The service label for the VPLS is created using
targeted LDP (tLDP) between PE-11 and PE-21.
2. A Layer 3 IP-VPN service between PE-12 and PE-S. This may be a cell site to mobile gateway
connection. The service label for the IP-VPN service is created using multiprotocol BGP (MPBGP) for IP-VPN between PE-12 and PE-S.
Decoupling transport and services layers within the Seamless MPLS framework allows services to
be provisioned wherever they are needed, independent of the underlying transport layer. Further,
services can be established between any two endpoints, without per-service configuration in
intermediate nodes.

Seamless MPLS Scaling Access Nodes

Access nodes typically outnumber aggregation, edge and core nodes in a network by an order of
magnitude. Access nodes may include digital subscriber line access multiplexers (DSLAMs), gigabit
passive optical networks optical line termination(GPON OLTs), Metro Ethernet switches, customerlocated equipment (CLE) and cell site routers (CSRs). Seamless MPLS supports an end-to-end
architecture which extends IP/MPLS capabilities to access nodes, recognizing they may have
limited capabilities. LDP Downstream on Demand (DoD) and LDP forward equivalence class (FEC) to
BGP stitching are two features that help extend Seamless MPLS to access nodes.
LDP Downstream on Demand (DoD)
The figure above depicts the use case for LDP DoD in end-to-end MPLS network design. One of the
main goals of Seamless MPLS (defined in draft-ietf-mpls-ldp-dod) is to meet the specific
requirements of access devices, based on their position in the network topology and their compute
and memory constraints, which limit the amount of state they can hold.
This can be achieved with LDP-DoD. In this topology, access nodes can implement a simple IP
routing configuration with static routes, limiting number of IP Routing Information Base and IP
Forwarding Information Base (IP RIB and IP FIB) entries required on the access node. In general,
MPLS routers implement LDP Downstream Unsolicited (LDP DU), advertising MPLS labels for all the
loopback routes in their RIB. LDP DoD enables on-request label distribution, ensuring only the
required labels are requested, provided and installed.
The access node in the figure above is configured with static default routes to the PE nodes
(access nodes are typically dual-homed to the PE nodes). The access and PE nodes support LDPDoD. The access node will request a label for a FEC from the PEs using LDP DoD. The aggregation
PE nodes reply with the label information, which the access nodes can use to establish the labelswitched path (LSP) to the destination.
Seamless MPLS with LDP-DoD therefore, enables on-request label distribution. This ensures only
the required labels are requested, provided and installed, thereby supporting end-to-end
architectures where the access nodes may have compute and resource constraints.
LDP FEC to BGP stitching

LDP FEC to BGP stitching may be used along with LDP DoD or LDP DU. The example covered
describes LDP FEC to BGP stitching with LDP DoD, which may be typical for supporting access nodes
with limited capabilities.
The PE nodes in the figure above perform a translation (LDP FEC to BGP stitching) function.
PE-11 can export an access node LDP Forwarding Equivalence Class (LDP FEC) into
BGP and advertise this as a label route using RFC 3107.
PE-21 translates the /32 BGP labeled routes into LDP FEC and redistribute this FEC
to LDP-DU peers and to LDP-DoD peers (access nodes), if requested.
The outermost label represents the LDP tunnels used to switch the packet between BGP peers
within the region (intra-region tunnel).The middle label (inter-region BGP tunnel) is used to switch
the packet to the destination PE (PE-11 or PE-21 depending on traffic direction).
The innermost label is the MPLS service label between the access nodes.
Configuration:
config>router>ldp>peer-parameters>peer>dod-label-distribution
When this option is enabled, LDP will set the A-bit in the Label Initialization message when the
LDP session to the peer is established. When both peers set the A-bit, they will both use the DoD
label distribution method over the LDP session.

The diagram above provides an overview of LDP DoD.


As shown in the figure above, Seamless MPLS provides end-to-end resiliency at the transport and
service layers. The framework supports Pseudowire (PW) redundancy at the service layer. The
transport layer supports protection of the inter-region transport tunnel (BGP tunnel), as well as the
intra-region (LDP or RSVP tunnel) transport tunnel. During failures, this ensures local fast
protection (i.e., LDP FRR, RSVP FRR or BGP FRR) is initiated while end-to-end protocol convergence
occurs, which eventually results in a new set of BGP transport tunnels being created end-to-end.

Service layer redundancy

PW redundancy allows PWs to be protected with a pre-provisioned PW and switching traffic over to that
standby PW in the event of failure. Normally, PWs are redundant because of the transport tunnel
redundancy mechanism. For instance, if the tunnel is an RSVP LSP and is protected by a secondary
standby path and/or by Fast-Reroute (FRR) paths, the PW is also protected.
There are a few applications in which tunnel redundancy does not protect the end-to-end PW path,
such as when there are two different destination PE nodes for the same Virtual Leased Line (VLL)
service. The main use case is to provision dual-homing customer premises equipment (CPE) or access
node to two PE nodes located in different points of presence. The other use case is to provision a pair
of active and standby broadband remote access server (BRAS) nodes, or active and standby links to
the same BRAS node to provide service resiliency for broadband service subscribers. The Alcatel-Lucent
end- to-end MPLS toolkit supports basic PW redundancy as well as unique methods to address extended
PW redundancy scenarios.
For layer-3 IP-VPN services, BGP egress node FRR mechanisms for the IP-VPN address families (v4 and
v6) are supported.
The figure above shows the use of pseudowire redundancy in the network to provide a resilient end-toend VLL service between CE1 and CE2. The SDP bindings (pseudowires) have been established between
endpoint components on VLL service instances. The next slide provides details about endpoints.
The PE NEs notify each other of their SAP states using T-LDP (Targeted-Label Distribution Protocol)
signaling (status bits included in LDP Notification messages). The Peer PW bits indicate the status of the
other end peer.

The SR-OS supports the endpoint concept, which allows the provisioning of objects through which the
service moves traffic. Two endpoints can be configured in a VLL service instance on each router. On this
slide, the endpoints are called x and y, but they can have any name (of maximum 32 characters).
You can provision two types of endpoint objects in the SR-OS:
SAP objects (can be implicit)
Spoke SDP objects (explicit)
An endpoint facing the access side can contain maximum one SAP object and one ICB Spoke SDP object
(the SAP needs to be part of a LAG if the ICB is already present).
An endpoint facing the network side can contain maximum 4 Spoke SDP objects, any combination of the
following:
primary Spoke SDP (maximum 1 per endpoint, set to revertive, precedence set to 0 or primary)
secondary Spoke SDP (maximum 4 per endpoint, not revertive, precedence non-zero)
ICB (inter-chassis backup) Spoke SDP (maximum 1 per endpoint)
Traffic can be forwarded only between two endpoints. Objects that are associated with the same
endpoint cannot forward traffic to each other. The VLL service forms a path following the LAGs that are
active and the endpoint components.

1.
Primary Spoke-SDP: The VLL service always uses this PW and only switches to a secondary PW
when it is down
The PW service switches the path to the primary PW when it is back up. User configurable timer
for reverting back to the primary or to never revert is available
2.
Secondary spoke-SDP: There can be a maximum of three secondary spoke-SDPs per endpoint in
addition to the Primary Spoke-SDP. The user can configure the precedence of a secondary PW to
indicate the order in which a secondary PW is made active upon a failure
When does a PW switch occur?
T-LDP peer (remote PE) node withdrew the PW label

T-LDP peer signaled a FEC status indicating a PW failure or a remote SAP failure
T-LDP session to peer node timed out
SDP binding and VLL service went DOWN as a result of a network failure condition such as the SDP
to peer node going operationally DOWN
Revertive switching between backup PWs is not possible.
Activity switches back to the primary PW only, never to the PW with a lower precedence value
Endpoint TX: only 1 active object
Endpoint RX: from all endpoint objects

Transport layer redundancy Inter-region tunnel

Inter-region transport layer redundancy is supported using BGP FRR and/or egress node
BGP FRR mechanism.
BGP FRR (or Edge PIC)
BGP fast reroute (FRR) or Edge PIC (Prefix Independent Convergence) is a feature that brings
together indirection techniques in the forwarding plane and pre-computation of BGP backup paths
in the control plane to support fast reroute of BGP traffic around unreachable/failed next-hops.
When BGP fast reroute is enabled, the control plane attempts to find an eligible backup path for
every received IPv4 and/or IPv6 prefix, depending on configuration. When BGP decides that a
primary path is no longer usable (detected for example using next hop tracking or BFD), the
affected traffic is immediately switched to the backup path. Traffic immediately fails over to backup
path without the need to wait for the BGP decision process and FIB updates i.e. the failover time
and convergence is Prefix Independent. BGP fast reroute is supported with IPv4, labeled-IPv4,
IPv6, 6PE, VPN-IPv4 and VPN- IPv6 routes.
In the figure above, BGP FRR (PIC) capability is enabled on PE1. An alternate BGP next-hop
(NH2/on PE3) is provided to the FIB in PE1 along with the primary (best) path (NH1/on PE2). PE1
groups routes with the same next-hops in the FIB so that the time to switch many routes to the
backup path is independent of the number of destination prefixes (Prefix Independent). If node PE2
fails, traffic is switched to the backup path (NH2)via PE3. NH1 unavailability may be detected via
IGP or BFD mechanisms.

Transport layer redundancy Intra-region tunnel

Intra-region transport layer redundancy is supported using LDP FRR or MPLS FRR.
LDP FRR using Loop Free Alternate (LFA)
When a local link fails without LFAs, a router must signal the event to its neighbors via the IGP,
recompute new primary next-hops for all affected prefixes and only then install those new primary
next-hops into the forwarding plane. This is a time consuming process. FRR using LFA reduces the
reaction time to milliseconds (tens of milliseconds). LDP/FRR enables IP/LDP packets to be
forwarded without waiting for IGP convergence.
For each destination in the network, a backup (alternate) loop-free next-hop is calculated using the
IGP LFA calculation specified in RFC 5286. Traffic is sent via the alternate next hop when a link or
node failure is detected. LFA coverage is dependent on topology. While dual-homed or full mesh
topologies offer good LFA coverage, ring topologies do not. LFA coverage can be improved in ring
topologies with shortcuts or remote LFA (draft-ietf-rtgwg-remote-lfa).
LDP FRR using LFA provides a rapid restoration option for architectures that do not require traffic
engineering (TE) capabilities.
NHLFE (Next Hop Label Forwarding Entry)
Routes:
The primary route is via P1 to P4 to PE-2 (in red)
The LFA route via P2 and P3 protects against node failure of P1.
The LFA route via P2 and P1 protects against failure of link PE1-P1

LDP FRR using Loop Free Alternate (LFA)

Upon failure, LDP instructs in the fast path the IOMs to enable the backup Next Hop Label
Forwarding Entry (NHLFE) for each FEC next-hop impacted by this event, and then resume
forwarding.
LDP will also update the impacted ILMs (LSR) and service records (LER) to use the backup NHLFE as
their primary NHLFE until the next routing update.

RSVP FRR (MPLS FRR)

RSVP FRR (defined in RFC 4090) provides the ability to establish backup LSP tunnels for local LSP
tunnel repair. This mechanism enables the redirection of traffic onto backup LSP tunnels in 10s of
milliseconds, in the event of a failure.
RSVP based FRR (MPLS FRR) may be deployed in segments of the network where traffic engineering
is required.
When Fast Reroute is enabled, each node along the path of the LSP tries to establish a backup LSP:
Each upstream node sets up a backup LSP that avoids only the immediate downstream node (
by default node protection is enabled)
The Point of Local Repair (PLR) looks for the backup path which merges back to the protected
LSP sooner
i.e., the Merge Point (MP) is closer to the PLR
The backup LSP may take one or more hops merging back to the main LSP or it may only merge
at the eLER
If it is not possible to set up a backup LSP that avoids the immediate downstream node, a
backup can be set up to the downstream node on a different interface
In case of failure, traffic is immediately rerouted by the PLR onto the pre-computed backup LSP,
minimizing packet-loss.
When the upstream node (iLER) is informed by the PLR that a downstream router is using its
backup LSP, the iLER switches traffic to a standby path if one was set up for the LSP.
A locally repaired LSP (i.e., using the backup path) will try to globally revert back when the retry
timer expires.
The diagram above depicts a facility backup (see next slide for what a facility backup is).

RSVP FRR can be accomplished using two methods, both of which can be used to protect links and
nodes during network failure:
1.
The one-to-one backup method, which creates detour LSPs for each protected LSP at each
potential point of local repair.
2.
The facility backup method creates a bypass tunnel to protect a potential failure point; by
taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have
similar backup constraints



Seamless MPLS can be implemented with different designs, but it requires the basic set up shown in
the slide above. For example, IGPs in the core and metro areas can be configured with different
combinations such as:
using OSFP with area 0 (backbone area) in the core and area 1 and area 2 in the metro areas
using IS-IS with instance 0 and level 2 in the core and level 1 in the metro areas
using IS-IS with different instance in the core and metro areas
using OSPF in the core and IS-IS in the metro areas or vice versa
LDP or RSVP is used for intra-area label distribution. The core and metro areas can be implemented
with either all LDP or all RSVP or a combination of LDP in one area and RSVP in a different area.
L- BGP is labeled BGP (RFC 3107) for inter-area label distribution.


















This PE is set to be a route reflector for area 1.

min-route-advertisement <interval> is the minimum interval, (Default 30sec), a prefix can be advertised to peer.
advertise-label ipv4 command is for setting exchange LDP FEC prefixed as RFC 3107 labeled IPv4 routes.




Note that the word RSVP follows the word tunneled to show that RSVP-TE is the intra-region tunnel.













BGP FRR or PIC is a resiliency feature that will speed up convergence. It operates by having a backup route
installed and ready to be used in cases of failure. As visible in the image above, this feature can be used for
resiliency both at the core and edge, as long as there are redundant routes/paths available. These redundant
routes/paths need to have a different next hop than the best path available. In order to determine the selection
process for best path, please continue on to the next slide.

It is important to review the BGP route selection process in order to aid troubleshooting/deployment of this
service. BGP will select and use the best route, while not using the more inferior routes based on the selection
process above. The backup route will be the second best route that does not use the same next-hop as the
primary path.

Looking at the legend from the command show router bgp routes X.X.X.X, we can see:
- First route is the best and used.
- Second route is the backup (not used unless primary path fails).
- Third route is not used.
From the command available, can you tell the criteria that BGP used to select the best and backup path?
Unfortunately, there is not enough detail, and a more detailed command might be needed.

It is important to understand the output of valuable commands, in this case, show router bgp routes X.X.X.X
detail.
Observations:
- We can see that the best route chosen has a lower peer router identifier.
- The backup path, indicated by the flags, has the next lowest peer router identifier AND a different next-hop
than the primary/best route.

- Now, the route that has not been selected as the backup or best, has the highest peer router id.

In case you are not familiar with ECMP (Equal-Cost Multi-Path), it is a feature that allows, as the name suggests,
to load share among multiple paths as long as their cost is the same. The functionality of ECMP, can be carried
over into BGP, when multipath is enabled. In this case, the MED will represent our metrics (as our MED represents
the igp metrics), and we can see that the first two routes have an equal cost of 1000. Traffic will be load
balanced between the first two routes, as they are the best or primary paths. Now, per the selection process, the
third route is the backup path as it is the next best to the primary paths.
See below CLI examples:

A:SR-7750>config>router# ecmp
- ecmp <max-ecmp-routes>
- no ecmp
<max-ecmp-routes>
: [0..16]
A:SR-7750>config>router>bgp# multipath
- multipath <max-paths>
- no multipath
<max-paths>
: [1..16]
When will the backup path be used? As stated before, the backup path will be used when the primary path fails.
Now do we know under what conditions the primary path will be considered as failed? This slide gives us most
scenarios in which the primary path will be considered as failed.
1.
If the BGP session is terminated, routes received from that peer will be cleared. BFD may be used to improve
failure detection on BGP peers, as well as peer-tracking BGP feature.
2.
If the next-hop cannot be resolved, the primary path is considered as failed, and the backup will be used.

PE1 will receive the routes from PE6 advertised by both PE2 and PE3. As we discussed earlier, BGP will select one
path as primary, and also the second best path as backup. The primary path will be utilized as long as there are
no failure conditions. In case of any detected fault, the backup path will be chosen as best path until the primary
path is recovered. Once the primary path is recovered, traffic will again be redirected through it.

If multiple paths are being used as best, through ECMP and BGP Multipath, traffic will be load balanced between
the primary paths. Now, if one of the primary paths fails, the backup path will not be used. In order for a backup
path to be used for this particular scenario, all primary/best paths should be down. Needless to say, the backup
path will not load balance with the primary paths that are still functional.


A simple CLI command is used to enable this feature. Remember that the backup path will only come active if,
there are multiple paths for the same prefix and one of these paths should have a different next-hop than the
one used for the primary.

There are no restrictions for the command backup-path ipv4 to be used. Although, in order for a path to be
selected as backup, points 1 and 2 will be a major factor. The third option is simply to improve fault detection of
the BGP session. When the BGP session is brought down, all the routes associated with that session will also be
removed. PE1 will receive routes from AS64400 from both PE2 and PE3, therefore point 1 is met. Also, PE1 has
two next-hops for this route (PE1 and PE2). Meeting the requirements of point 1 and 2, indicate that PE1 will
have a primary and backup path for these prefixes.


By enabling the CLI command, enable-bgp-vpn-backup, the BGP routes learned via bgp-vpn, will be taken into
consideration for the selection process for the backup route. The next slide will explain in more detail how these
two features interact in a L3VPN environment.

Through a L3VPN, routes are learned either through the PE-CE eBGP session or through bgp-vpn routes from other
PEs participating in the same VRF. Backup-path ipv4 as in previous examples, will add resiliency for ipv4 and ipv6
routes which in this case are learned from the PE-CE peering. In some cases, a PE may receive the same prefix
from different sources (ie. redundant Route Reflectors), but BGP FRR feature will not be included for bgp-vpn
routes unless enable-bgp-vpn-backup is used.


In RFC 3107, BGP carry labels associated with each route. Backup-path will also provided resiliency for these
labeled routes.

Different solutions make use of this technology, BGP 3107. It is not necessary to know all the solutions listed in
the slide above, just know that it is an essential component.

This scenario is similar to the first one where ipv4 or ipv6 BGP routes are being protected. The exception is that
backup-path has also been extended to protected labeled ipv4/ipv6 routes which are needed for Model C L3VPN
environments.

The slide above simply shows the output of a bgp command where labels are assigned to a prefix. An in depth
analysis of BGP-3107 is not contained within this module, as focus is BGP FRR resiliency feature





Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition



Page
1 Interface Setup
1.1 Seamless MPLS Lab Infrastructure
1.2 Configure Network Interfaces
2 IGP and MPLS Setup

2.1 Configure and Verify IGP and MPLS Protocols
2.2 Verify IGP and MPLS Configuration
10
3 Policy and BGP Setup

3.1 Configure and Verify Routing Policy
3.2 Configure and Verify Routing Policy at the Core
3.3 Configure BGP at the Core
3.4 Configure and Verify Routing Policy at the Edge
3.5 Configure BGP at the Edge
3.6 Verify BGP Configuration
4 Services Setup
14
21
4.1 SDP Setup

4.2 Configure and Verify Epipe Configuration
4.3 Epipe Pseudowire Redundancy Setup
4.4 Configure and Verify Redundant Epipe Configuration
5 Changing Configuration Scenarios
5.1 Change IGP Protocol
5.2 Change MPLS Protocol
5.3 Shutdown Scenarios

26

Objective:
Create and verify the configuration of the metro and core regions in building a Seamless MPLS solution.
Lab Exercises:
In order to build a seamless MPLS across metro and core regions, the following tasks are required:
IP interface infrastructure setup
IGP routing infrastructure: OSPF
MPLS infrastructure: LDP and RSVP
BGP infrastructure
Seamless MPLS
ePipe Service implementation
Using the commands and physical diagram provided on the next slides, students will verify configuration and thus
become familiar with the general lab layout and functionality.

Objective: Configure and verify the system name and network interfaces for each of the devices in the network
as assigned by the instructor.
Configure System Name and Network Interfaces
Using the commands below and the tables on the next slide, configure and verify the system name and network
interface for each node according to the diagram above. For example on Core 1, this is the configuration:
configure system name P1(CORE1)
configure router interface system address 10.10.10.1/32
configure router interface toCORE4 address 10.1.14.1/28
configure router interface toCORE4 port 1/1/1
configure router interface toEdge1 address 10.1.15.1/28
configure router interface toEdge1 port 1/1/5
Note: if port 1/1/5 is a dot1q encapsulated port, assign a VLAN ID that is not in use. For example, port
1/1/5:11.

On Edge 1, this is the configuration:

configure system name PE1(EDGE1)
configure router interface system address 10.10.10.5/32
exit all
configure router interface toEdge2 address 10.2.12.5/28
configure router interface toEdge2 port 1/1/2
exit all
configure router interface LoopBack
address 55.55.55.55/32
loopback
exit all
Note: if port 1/1/4 is a dot1q encapsulated port, assign a VLAN ID that matches port 1/1/5 on the core router. For
example, port 1/1/4:11.
System
name
Interfaces
to other
nodes
Core 1
Core 2
Core 3
Core 4
Edge 1
Edge 2
Edge 3
Edge 4
P1(CORE1)
P2(CORE2)
P3(CORE3)
P4(CORE4)
PE1(EDGE1)
PE2(EDGE2)
PE3(EDGE3)
PE4(EDGE4)
toCORE2
toCORE1
toCORE1
toCORE1
toCORE1
toCORE2
toCORE3
toCORE4
toCORE3
toCORE3
toCORE2
toCORE2
toEdge2
toEdge1
toEdge4
toEdge3
toCORE4
toCORE4
toCORE4
toCORE3
toEdge1
toEdge2
toEdge3
toEdge4
LoopBack
address
55.55.55.55
/32
LoopBack
address
66.66.66.66/
32
LoopBack
address
77.77.77.77
/32
LoopBack
address
88.88.88.88
/32
Loopback
interface
and
address
Commands to verify network interface configuration
Verify Network Interface Configuration

show router interface
configure router interface <interface_name> [Enter] info <detail>
admin display-config


Objective: Configure and verify IGP and MPLS protocol for each of the devices in the network as assigned by the
instructor.
Configure OSPFv2
Using the following commands, configure OSPF with multiple areas for each node according to the diagram above
and the table below. For example on Core 1, this is the configuration:
configure
configure
configure
configure
router
router
router
router
ospf
ospf
ospf
ospf
area 0 interface "system"

area 0 interface toCORE2 interface-type point-to-point
configure router ospf area 2 interface toEdge1 interface-type point-to-point

configure router ospf area 2 interface "system"
configure router ospf area 2 interface toCORE1 interface-type point-to-point
configure router ospf area 2 interface toEdge2 interface-type point-to-point
OSPF
Area and
Interface
Core 1
Core 2
Core 3
Core 4
Edge 1
Edge 2
Edge 3
Edge 4
Area 0:
toCORE2
toCORE3
toCORE4
Area 0:
toCORE1
toCORE3
toCORE4
Area 0:
toCORE1
toCORE2
toCORE4
Area 0:
toCORE1
toCORE2
toCORE3
Area 2:
toCORE1
toEdge2
Area 2:
toCORE2
toEdge1
Area 1:
toCORE3
toEdge4
Area 1:
toCORE4
toEdge3
Area 2:
toEdge1
Area 2:
toEdge2
Area 1:
toEdge3
Area 1:
toEdge4

Commands to verify OSPF Configuration
Verify OSPF Configuration

show router route-table
show router ospf status
show router ospf area
show router ospf interface
show router ospf neighbor
show router ospf database
Configure LDP signaled LSPs
Using the following commands, enable LDP on the interfaces for each node required to support the full
mesh service topology according to the diagram above and the table below. For example, on Core 1, this
is the configuration:
configure router ldp interface-parameters interface "toCORE2"
configure router ldp interface-parameters interface "toEdge1
On Edge 1, this is the configuration
configure router ldp interface-parameters interface "toEdge2"

Verify LDP Configuration
LDP Verification
show router ldp bindings
show router ldp bindings active
show router ldp discovery
show router ldp interface
show router ldp parameters
show router ldp peer
show router ldp session
show router ldp status
show router route-table alternative
Verification of OSPF and LDP:

1. Verify the status of each of the protocols and the interfaces in each protocols. Are they operationally Up? If
not, verify the protocol configuration to identify the problem. Make the appropriate corrections and reaffirm
that the interfaces are operational.
2. How many LDP sessions are on a core router? How many are on an edge router?
3. How many routes are found in the routing table of the core and edge routers?
Configure LDP FRR with Loop-Free Alternate

On all the routers (core and edge), configure the following for LDP FRR with LFA:
configure router ldp fast-reroute
configure router ospf loopfree-alternate
Verification of LDP FRR:
1. Comparing the routing table entry before and after configuring LDP FRR, what is the difference? Why? (look
at the results of the show router route-table and show router route-table alternative commands)


Objective: Configure and verify a routing policy for each of the devices in the network as assigned by the
instructor.
Configure Policy On Core Routers
Using the following commands, create a policy on the core routers (which are the ABRs in this set up) to
redistribute the edge routers system and loopback address as well as set the next-hop self. A prefix list is first
created for the edge routers system and loopback addresses and then used in the policy to redistribute into BGP.
These addresses will be used later for service creation. A second prefix list is created for the remote ABR system
addresses which will be used for route redistribution.
Core 1 and 2
Core 3 and 4
configure router policy-options begin
configure router policy-options prefix-list "PE_Sys_loop_Out" configure router policy-options prefix-list "PE_Sys_loop_Out"
prefix 10.10.10.5/32 exact
exit
exit
configure router policy-options prefix-list "remoteABR"
configure router policy-options prefix-list "remoteABR"
exit
exit
Redistribute the loopback and system addresses of the Edge routers into BGP setting next hop to the ABR on all the
core routers. Configure the following on all the core routers:
configure router policy-options policy-statement "expNHS"
entry 10
from
prefix-list "PE_Sys_loop_Out"
family ipv4
exit
to
protocol bgp
exit
action accept
next-hop-self
exit
exit
exit
The following is to allow BGP routes from the remote ABR into the IGP. Configure the following on all the core
routers:
configure router policy-options policy-statement "remoteABR"
entry 10
from
prefix-list "remoteABR"
exit
action accept
exit
exit
exit
configure router policy-options commit
Verify policy configuration
Policy Verification
show router policy admin

For Seamless MPLS to function, BGP need to be enabled on all provider routers supporting the
following family:
ms-pw Exchanges dynamic MS-PW related information
vpn-ipv4 Exchanges IPv4 VPN routing information
ipv4 Provisions support for IPv4 routing information (exchange LDP FEC prefixed as RFC 3107
labeled IPv4 routes)

Next, BGP has to be configured on the core routers.
For this set up, all routers are in the same autonomous system (AS). In each BGP core group, set
the neighbor applicable to that router. For example, in Core 1, set neighbors to 10.10.10.2,
10.10.10.3, and 10.10.10.4 (other core routers) and not to 10.10.10.1. On Core 1, this is the
configuration:
configure router autonomous-system 65000
configure router bgp
min-route-advertisement 1 # minimum interval, (Default 30sec), a prefix can be advertised
to peer.
group "core"
family ipv4 vpn-ipv4 ms-pw
type internal
export "expNHS"
neighbor 10.10.10.2
advertise-label ipv4
exit
neighbor 10.10.10.3
exit
neighbor 10.10.10.4
exit
exit
Set core 1 to be a route reflector (RR) for Area 2 and core 3 to be a RR for Area 1.
Core 1
Core 3
configure router bgp group "Area2"

type internal
cluster 10.10.10.1
neighbor 10.10.10.5
exit
neighbor 10.10.10.6
exit
exit
configure router bgp group "Area1"

type internal
cluster 10.10.10.3
neighbor 10.10.10.7
exit
neighbor 10.10.10.8
exit
exit

Using the following commands, create a policy on the edge routers to export the loopbacks and system addresses.
A prefix list is first created for the edge routers system and loopback addresses and then used in the policy to
redistribute into BGP.
For each edge router, set the prefix list applicable to that router. See table below. On Edge 1, this is the
configuration:
configure router policy-options prefix-list "PE_Sys_loop_Out"
exit
Edge 1
Edge 2
Edge 3
Edge 4
prefix 10.10.10.5/32 exact prefix 10.10.10.6/32 exact prefix 10.10.10.7/32 exact prefix 10.10.10.8/32 exact
prefix 55.55.55.55/32 exact prefix 66.66.66.66/32 exact prefix 77.77.77.77/32 exact prefix 88.88.88.88/32 exact
The following is to be configured on all edge routers:

configure router policy-options policy-statement "expBGP"
entry 10
from
prefix-list "PE_Sys_loop_Out"
exit
action accept
exit
exit
exit
configure router policy-options commit
Verify policy configuration
Policy Verification
show router policy admin

Next, BGP has to be configured on the edge routers.

For this set up, all routers are in the same autonomous system (AS). In each BGP group, set the neighbor
applicable to that router.
configure router autonomous-system 65000
Edge 1 and Edge 2

min-route-advertisement 1
group "Area2"
type internal
export "expBGP"
neighbor 10.10.10.1
exit
neighbor 10.10.10.2
exit
exit
exit
Edge 3 and Edge 4

min-route-advertisement 1
group "Area1"
type internal
export "expBGP"
neighbor 10.10.10.3
exit
neighbor 10.10.10.4
exit
exit
exit

Verify BGP Configuration
BGP Verification
show router bgp summary
show router bgp neighbor 10.10.10.1 advertised-routes
show router route-table 55.55.55.55/32
show router bgp routes 77.77.77.77/32 detail
show router tunnel-table
Verification of BGP:
1. From viewing the route table on a core router, what is the size of the routing table?
2. What do you noticed about the system addresses of the edge routers? What is the type and protocol of these
addresses?
3. What do you noticed about the loopback addresses of the edge routers? What is the type and protocol of these
addresses?
4. From viewing the route table on an edge router, what is the size of the routing table?
5. What do you noticed about the system addresses of the edge routers? What is the type and protocol of these
addresses?
6. What do you noticed about the loopback addresses of the edge routers? What is the type and protocol of these
addresses?


Objective: Configure and verify an epipe service.

Configure SDP
Using the following commands, create an SDP using BGP tunnel and enable T-LDP for signalling from Edge 1 to
Edge 3 and another SDP from Edge 3 to Edge 1. On Edge 1, this is the configuration:
configure service sdp 57 mpls create
far-end 77.77.77.77
bgp-tunnel
no shutdown
exit all
configure router ldp targeted-session
peer 77.77.77.77
local-lsr-id "LoopBack"
exit
far-end 55.55.55.55
bgp-tunnel
no shutdown
exit all
peer 55.55.55.55
exit
Configure Epipe
Using the following commands, create an Epipe service between Edge 1 and Edge 3. On Edge 1, this is the
configuration:
configure service epipe 57 customer 1 create
sap 1/1/5:1.57 create
exit
spoke-sdp 57:57 create
exit
no shutdown
exit
spoke-sdp 75:57 create
exit
no shutdown
Note: if port 1/1/5 on Edge 1 and Edge 3 have not been configured to an access port with qinq encap, execute
the following command and then create the service:
configure port 1/1/5
shutdown
ethernet
mode access
encap-type qinq
exit
no shutdown
exit
Verify service configuration
Service Verification
show service sdp
show service id 57 base
show service id 57 all
show service id 57 labels
show service id 57 sap
show service id 57 sdp
Verification:
1. Verify the status of each of the components. Are they operationally Up? If not, verify the service configuration
to identify the problem. Make the appropriate corrections and reaffirm that the service is operational.
2. What type of LSP is used by the SDPs and how are they signalled?

Objective: Configure and verify a redundant epipe service.

Configure SDP
Using the following commands, create an SDP from Edge 1 to Edge 4 and another SDP from Edge 4 to Edge 1. On
Edge 1, this is the configuration:
far-end 88.88.88.88
bgp-tunnel
no shutdown
exit all
peer 88.88.88.88
exit
far-end 55.55.55.55
bgp-tunnel
no shutdown
exit all
peer 55.55.55.55
exit
Configure Redundant Epipe

Using the following commands, create a redundant Epipe service between Edge 1 and Edge 3, and Edge 1 and Edge
4. On Edge 1, this is the configuration:
endpoint PWRed create
exit
exit
spoke-sdp 57:578 endpoint PWRed create
precedence primary
exit
precedence 2
exit
no shutdown
exit
exit
exit
no shutdown
On Edge 4, this is configuration:
exit
exit
exit
no shutdown
Verify
service Verification
configuration
Service
show service sdp
show service id 578 base
show service id 578 endpoint
show service endpoint-using
Verification:
1. On Edge 1, how many SDPs are found in the epipe? Which one is active?

Objective: Change the IGP protocol from OSPF to IS-IS in metro region 1 and ensure that seamless MPLS is
operational.
Shut down OSPF
Shutdown OSPF in metro region 1 by shutting down OSPF on Edge 1 and Edge 2 and shutting down OSPF Area 2 on
Core 1 and Core 2. On Core 1, this is the configuration:
configure router ospf area 2 interface toEdge1 shutdown
On Core 2:
configure router ospf area 2 interface toEdge2 shutdown
On Edge 1 and Edge 2, this is the configuration:
configure router ospf shutdown
Configure IS-IS
Configure IS-IS instance 0 and level 2 on Edge 1 and Edge 2 and on Core 1 and Core 2. On Core 1, this is the
configuration:
configure router isis level-capability level-2
area-id 49.0001
traffic-engineering
interface "system
interface toCORE2 interface-type point-to-point
interface toEdge1 interface-type point-to-point

On Core 2, this is the configuration:

area-id 49.0001
traffic-engineering
interface "system
interface toEdge2 interface-type point-to-point
area-id 49.0001
traffic-engineering
interface "system
area-id 49.0001
traffic-engineering
interface "system
Commands to verify IS-IS Configuration
Verify IS-IS Configuration

show router isis status
show router isis adjacency
show router isis interface
show router isis database
Verification:
1. From viewing the route table on Core 3 router, what is the size of the routing table?
2. What do you noticed about the system addresses of Edge 1 and Edge2 routers? What is the type and
protocol of these addresses?

3. What do you noticed about the loopback addresses of Edge 1 and Edge 2 routers? What is the type and

4. From viewing the route table on Edge 1 router, what is the size of the routing table? Are there any
entries missing?
5. What is the status of the epipes configured in previous exercises? Why?

Next, in order for the BGP tunnel to exchange labels in the IS-IS domain to the edge routers, a new policy
statement has to be created and configured in BGP on Core 1 and Core 2.
Note: whenever a routing policy is modified start by entering configure router policy-options begin and at
the end commit the changes by entering policy-options commit.
configure router policy-options prefix-list "PE_Sys_loop_Out-farend"
configure router policy-options policy-statement "expNHS-2"
entry 10
from
prefix-list "PE_Sys_loop_Out-farend"
family ipv4
exit
to
protocol bgp
exit
action accept
next-hop-self
exit
exit
configure router bgp group Area2 export expNHS-2
Verification:
1. Now view the route table on Edge 1 again. What changed?
2. What do you noticed about the system addresses and loopback addresses of Edge 3 and Edge 4 routers?
What is the type and protocol of these addresses?


Objective: Change the MPLS protocol from LDP to RSVP-TE in metro region 2 and ensure that seamless MPLS is
operational.
Shut down LDP
Shutdown LDP in metro region 2 by shutting down LDP interfaces on Edge 3, Edge 4, Core 3 and Core 4. On Core
3, this is the configuration:
configure router ldp interface-parameters interface toEdge3 shutdown
On Edge 3:
configure router ldp interface-parameters interface toCORE3 shutdown
On Core 4:
On Edge 4:
configure router ldp interface-parameters interface toCORE4 shutdown

Configure RSVP
Enable MPLS and RSVP on Edge 3, Edge 4, Core 3, and Core 4 routers. Create LSPs between Edge3 and Core
3, and LSPs between Edge 4 and Core 4.
configure router mpls no shutdown
configure router rsvp no shutdown
configure router ospf traffic-engineering (for FRR)
configure router mpls interface toEdge3
configure router mpls path toEdge3
lsp "to7
to 10.10.10.7
cspf
fast-reroute
primary "toEdge3"
exit
no shutdown
exit
On Edge 3:
configure router mpls interface toCORE3
configure router mpls path toCore3
lsp "to3
to 10.10.10.3
cspf
fast-reroute
primary "toCore3"
exit
no shutdown
exit
configure router mpls interface toEdge4
configure router mpls path toEdge4
lsp "to8
to 10.10.10.8
cspf
fast-reroute
primary "toEdge4"
exit
no shutdown
exit
On Edge 4:
configure router mpls interface toCORE4
configure router mpls path toCore4
lsp "to4
to 10.10.10.4
cspf
fast-reroute
primary "toCore4"
exit
no shutdown
exit

Commands to verify LSP Configuration
Verify LSP Configuration

show router mpls interface
show router mpls path
show router mpls lsp
show router mpls lsp <lsp_name> activepath
show router rsvp neighbor
show router rsvp session
show router rsvp interface
Verification:
1. From viewing the route table on Core 3 router, what do you noticed about the system addresses of Edge 3
and Edge 4 routers? What is the type and protocol of these addresses?
2. What do you noticed about the loopback addresses of Edge 3 and Edge 4 routers? What is the type and

3. From viewing the route table on Edge 3 router, what is the size of the routing table? Are there any entries
missing?
Configure Policy and BGP

Next, in order for the BGP tunnel to exchange labels in the RSVP domain to the edge routers, a new policy
statement has to be created and configured in BGP on Core 3 and Core 4.
configure router policy-options prefix-list "PE_Sys_loop_Out-farend"
configure router policy-options policy-statement "expNHS-2"
entry 10
from
prefix-list "PE_Sys_loop_Out-farend"
family ipv4
exit
to
protocol bgp
exit
action accept
next-hop-self
exit
exit

configure router bgp group Area1 export expNHS-2

Verification:
1. Now view the route table on Edge 3 again. What changed?
2. What do you noticed about the system addresses and loopback addresses of Edge 1 and Edge 2 routers?
What is the type and protocol of these addresses?


Objective: Make changes in the network by shutting down port or interfaces and see that seamless MPLS is
still operational.
Shut down ports
Select a port such as the ones in the core region connecting the core routers and shut it down.
View the services created in the network.
View the route tables in the core routers and edge routers.
Verification:
1. Did any service go down?
2. Were there any changes in the route tables?
Shut down OSPF interface

Select an OSPF such as the ones in the core region connecting the core routers and shut it down.
View the services created in the network.
View the route tables in the core routers and edge routers.
Verification:
1. Did any service go down?
2. Were there any changes in the route tables?
Redundant Epipe Shut down SAP

On the Epipe with PW Redundancy configured, view which is the active endpoint. Select the SAP at the
far end of the active SDP and shut it down.
View the endpoint of the Epipe services.
Verification:
1. Is the Epipe still operational?
2. Which is the active SDP?




Appendix 2 Page 1
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Appendix 2 Page 2

Appendix 2 Page 3
Page
1 Versatile Services Module

Appendix 2 Page 4

Appendix 2 Page 5
Provides roughly the equivalent connectivity as looping back external ports, but with various improvements:
- The interconnect function is performed internally eliminating the need for the physical port MAC, PHY,
cable and other MDA specific components
producing a more reliable adaptor.
- Bandwidth is utilized in a more efficient manner than with externally cabled ports. Typically, the offered
load presented to each side of the cross connect port pair is asymmetric in nature. When physical ports are
used to cross connect services, each service is egress bandwidth limited to the link speed of the TX-RX path
it is using. If one TX-RX path is underutilized, egress services on the other path cannot make use of the
available bandwidth. Since the VSM is forwarding all services over the same path, all the available bandwidth
may be used up to the 10 Gbps (half duplex) capability.
The MDA is called a vsm-cca in the CLI to tie together the Cross-Connect Aggregation Group concepts
underlying the VSM. VSM-CCAs may be placed into CCAGs (Cross Connect Aggregation Groups). A CCAG
provides a mechanism to aggregate multiple vsm-ccas into a single forwarding group. The CCAG uses
conversation hashing to dynamically distribute cross connect traffic to the active CCAs in the aggregation
group. In the event that an active CCA fails or is removed from the group, the conversation hashing function
will redistribute the traffic over the remaining active CCAs within the group.
Ordering Information:
3HE01197AA
7750 SR Versatile Services Module (VSM)
3HE01198AA
7450 ESS Versatile Services Module (VSM)

Appendix 2 Page 6
With the R9.0 platforms of the 7750 SR and 7450 ESS, the Alcatel-Lucent Versatile Services
Module-XP (also called VSM-CCA-XP ) enables new service offerings by internally connecting
services with centralized Quality of Service (QoS) enforcement.
Each Alcatel-Lucent VSM-XP occupies half a slot in an IOM and can interconnect up to 25 Gb/s
(half-duplex) of services when installed in an IOM3-XP and 10 Gb/s when installed in an IOM2 or
IOM1.
Performance and Scalability
IOM3-XP: Up to 25 Gb/s half-duplex per VSM-XP
IOM2 and IOM1: Up to 10 Gb/s half-duplex per VSM-XP
At least eight logical groups of VSM-XP for interconnect bandwidth scaling
At least eight VSM-XPs per logical group
Limits on logical groups and VSM-XP per logical group are chassis and software-release
dependent
Part No.: 3HE05942AA
Name: VSM - 7x50 VSM-XP

Appendix 2 Page 7
This slide shows the data flow for a single Versatile Services Module (VSM) (or vsm-cca in the CLI).
When multiple VSMs are installed, the cross connect traffic can be distributed across the VSMs.
The VSMs can be spread across IOMs. Each VSM support 10 Gbps of half-duplex service
interconnect traffic.
The VSM can be used to interconnect services with Ethernet encapsulations (e.g. no Frame Relay
or ATM encapsulated SAPs)

Appendix 2 Page 8
CCAG - Cross Connect Aggregation Group

Provides a mechanism to aggregate multiple CCAs into a single forwarding group. The CCAG uses
conversation hashing to dynamically distribute cross connect traffic to the active VSMs in the
aggregation group. In the event an active VSM fails or is removed from the group, the conversation
hashing function will redistribute the traffic over the remaining active VSMs within the group.

Appendix 2 Page 9
CCID Cross Connect Identifier

Services and IP interfaces are bound to a CCAG through a CCID (Cross Connect Identifier). When
two services or a service and an IP interface are assigned the same CCID, the CCAG will attempt
to provide a crosss connection path between the objects. The CCID enables multiple pairs of cross
connected services to share the same CCAG.
From a services perspective, a CCID is an object that not only binds two services together, but
also provides the attachment point for the ingress and egress QoS, filtering and accounting
policies. When considered in conjunction with the CCAG, it allows the actual cross connection
path (through the VSMs) to be indirectly associated with the services using the CCAG and
maintains a simplified provisioning model over port level cross connected services.

Appendix 2 Page 10
Virtual Paths
The function of the VSM is to connect an egress forwarding path directly to an ingress forwarding
path, allowing a packet to exit and reenter the system on the same MDA interface. This creates a
half duplex forwarding environment for all cross connected objects using the VSM and differs from
the full duplex nature of externally cross connected ports which support two distinct forwarding
paths. VSM provisioning emulates full duplex provisioning with two logical Path A and Path B
constructs which each emulate a TX-RX path for the CCAG.
Although Path A and Path B use the same TX bandwidth at the hardware level (represented by the
shared egress forwarding path for a given VSM), defining these distinct paths within a CCAG allows
for optional provisioning of rate limiting on each path. When enabled, rate limiting on a path is
spread across all the VSMs in the CCAG.
SAPs are defined as belonging to either Path A or Path B when the SAP is created on the CCID. An
IP interface is assigned to Path A or Path B when it is bound to a CCAG. A Path A object can only
be paired with a Path B object and vice versa.

Appendix 2 Page 11

Appendix 2 Page 12
A:ALA-48# configure vsm

ccag 1 create
description "VSM test
member-cca 10/1
member-cca 10/2
path a
net-sap
queue-policy "nq1
egress
pool
slope-policy "A
exit
exit
exit
exit
path b
weight 100
sap-sap
egress
pool
slope-policy "B
exit
exit
exit
exit
no shutdown
exit
A more complete Sample

Appendix 2 Page 13

Appendix 2 Page 14

Appendix 2 Page 15

Appendix 2 Page 16

Appendix 2 Page 17
VSM Configuration
Note: Ue the Versatile Services Modules (VSM) installed in the MLS routers to build cross-connections
between local Layer 2 and 3 services. Using the VSM, you can provide members of a VPLS server access to
a local Layer 3 services, either an IES or VPRN, through which the VPLS members can route traffic to
other network segments.
You may combine VSMs for additional bandwidth and redundancy. They may be located in the same or
different IOMs. You may assign bandwidth to each path, and set optional bandwidth constraints on a per
path basis.
In a live network, you would use at least two VSMs. In a lab environment, there can be one member per
Cross Connect Aggregate Group (CCAG). Only one CCAG per router would be configured.
1. Configure the VSM:
MLSx# configure card <iom slot> mda <mda slot> mda-type vsm-cca
MLSx# configure vsm
MLSx>config>vsm# ccag 1 create
MLSx>config>vsm>ccag# description "Service Cross Connect group L2 to L3"
MLSx>config>vsm>ccag# member-cca <iom>/<mda>
MLSx>config>vsm>ccag# path a sap-sap mtu 9212
MLSx>config>vsm>ccag# path b sap-sap mtu 9212
MLSx>config>vsm>ccag# exit all
MLSx#
2. Verify the VSM configuration:

MLSx# show ccag 1

Appendix 2 Page 18
Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Appendix 2 Page 19

Appendix 2 Page 20
All Rights Reserved Alcatel-Lucent 2014
All Rights Reserved Alcatel-Lucent 2014

02 TER36075 V3.1 AX Ed.1 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02 TER36075 V3.1 AX Ed.1 PDF

Uploaded by

Copyright:

Available Formats

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

This page is left blank intentionally

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

TERMS OF USE AND LEGAL NOTICE

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Welcome to 7705 SAR 7705 SR

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

This page is left blank intentionally

Last name, first name

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

2 Seamless MPLS Resiliency

4 BGP Fast Re-Route

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Seamless MPLS offers the following key attributes (contd):

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Figure above depicts two inter-region transport tunnels:

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Seamless MPLS Scaling Access Nodes

LDP FEC to BGP stitching

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

The diagram above provides an overview of LDP DoD.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Service layer redundancy

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

When does a PW switch occur?

T-LDP peer (remote PE) node withdrew the PW label

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Transport layer redundancy Inter-region tunnel

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Transport layer redundancy Intra-region tunnel

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

LDP FRR using Loop Free Alternate (LFA)

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

RSVP FRR (MPLS FRR)

i.e., the Merge Point (MP) is closer to the PLR

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.

Copyright 2014 Alcatel-Lucent. All Rights Reserved.