Services Architecture v3.2 Student Guide Download

Alcatel-Lucent Services Architecture
Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute
Module 0 Course Introduction
Alcatel-Lucent Services Architecture v3.2
All rights reserved 2012 Alcatel-Lucent
Module 0 Page 1
Module Overview
Alcatel-Lucent Career Certification

General Course Information
Timeline
Prerequisites
Introduction
Goal
Administration
Module 0 |

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. See www.alcatellucent.com/src for more information on the SRC program.
To locate additional information relating to the topics presented in this manual, refer to the following:
Technical Practices for the specific product
Internet Standards documentation such as protocol standards bodies, RFCs, and IETF drafts
Technical support pages of the Alcatel-Lucent website located at: http://www.alcatel-lucent.com/support
Module 0 Page 2
Objectives
ALCATEL-LUCENT
NETWORK ROUTING SPECIALIST I
ALCATEL-LUCENT
NETWORK ROUTING SPECIALIST II
4 DAYS / 1 COURSE / 1 WRITTEN EXAM
18 DAYS / 4 COURSES / 4 WRITTEN EXAMS /

1 PRACTICAL LAB EXAM
ALCATEL-LUCENT
ALCATEL-LUCENT
TRIPLE PLAY ROUTING PROFESSIONAL MOBILE ROUTING PROFESSIONAL
36 DAYS / 8 COURSES / 8 WRITTEN EXAMS /
1 PRACTICAL LAB EXAM
32 DAYS/ 7 COURSES / 7 WRITTEN EXAMS /

2 PRACTICAL LAB EXAMS
ALCATEL-LUCENT
SERVICE ROUTING ARCHITECT
49 DAYS / 11 COURSES / 11 WRITTEN EXAMS / 2 PRACTICAL LAB EXAMS
Module 0 |
Module 0 Page 3
Alcatel-Lucent Service Routing Certification Program Four Certifications
Module 0 |
Module 0 Page 4
SRC Program Courses and Exams
Exam Number
Exam Pre-requisites
(4A0-XXX)
Alcatel-Lucent Scalable IP Networks
4A0-100
NA
Alcatel-Lucent Interior Routing Protocols
4A0-101
NA
Alcatel-Lucent Border Gateway Protocol
4A0-102
NA
Exam Name
Alcatel-Lucent Multiprotocol Label Switching
4A0-103
NA
4A0-104
NA
Alcatel-Lucent Virtual Private LAN Services
4A0-105
NA
Alcatel-Lucent Virtual Private Routed Networks
4A0-106
NA
Alcatel-Lucent Quality of Service
4A0-107
NA
Alcatel-Lucent Multicast Protocols
4A0-108
NA
Alcatel-Lucent Triple Play Services
4A0-109
NA
Alcatel-Lucent Advanced Troubleshooting
4A0-110
NA
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport
4A0-M01
NA
Alcatel-Lucent Mobile Gateways for the LTE Evolved

Packet Core
4A0-M02
NA
Alcatel-Lucent Network Routing Specialist II Lab Exam
NRSII4A0
100, 101, 103, 104
Alcatel-Lucent Mobile Routing Professional Lab Exam
MRP4A0
100, 101, 103, 104, 107, M01, M02, NRSII4A0
Alcatel-Lucent Service Routing Architect Lab Exam
ASRA4A0
100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110,
NRSII4A0
Module 0 |
Module 0 Page 5
SRC Program Exam Profile
Exam Delivery
Written Exams
Delivered by Prometric
Global provider of testing services
5000+ test sites worldwide
Lab Exams
Written at Alcatel-Lucent sites
NRS II Certification
Half-day lab exam
SRA Certification
Full-day lab exam
Module 0 |
Module 0 Page 6
Register at:
www.prometric.com/alcatel-lucent
SRC Program Global Reach, Flexible Delivery Options
On-site delivery at your business location anywhere in the world
Delivery from any of fifteen Alcatel-Lucent University locations globally

APAC
Shanghai, China
Americas
Sydney, Australia
Plano, USA
Wellington, New Zealand

Bangalore, Chennai, Gurgaon, Mumbai, India
Europe
Ottawa, Canada
Mexico City, Mexico
Sao Paulo, Brazil
Antwerp, Belgium
Newport, UK
Paris, France
Class schedules posted @ www.alcatel-lucent.com/src
Registration online @ www.alcatel-lucent.com/srcreg
Module 0 |
Module 0 Page 7
Melbourne, Australia
Your Own Service Router Lab Now you can have one
Need access to a lab to help you:

Prepare for your NRS II and SRA exams?
Practice and build your service routing knowledge and configuration
skills?
Remote, private access (724) to an Alcatel-Lucent service router lab:
six-node fully meshed network three-hour time slots available
Access to a suite of over 30 lab practice scenarios with optimal
solutions
Access to traffic simulation and analysis tools
To find out more and sign up visit http://www.alcatellucent.com/src/examprep
Module 0 |
Module 0 Page 8
The Alcatel-Lucent Exam Preparation service provides:
Credit for Other IP Certifications

Cisco or Juniper certified?
Certifications must be valid to

receive exemptions
Submit your request for
exemptions at: http://www.alcatellucent.com/srcexemptions
Module 0 |
Module 0 Page 9
You can receive exemptions from

some of the SRC exams, if you
hold any one of the Cisco or
Juniper certifications identified
This course will provide course participants with foundation

knowledge of Layer 2 services (VPWS and VPLS), Layer 3
services (IES and VPRN), and mirroring service and how to
implement these services in an Alcatel-Lucent environment.
Module 0 |
10
Module 0 Page 10
Alcatel-Lucent Services Architecture Goal
Alcatel-Lucent Services Architecture Course Objectives
Upon successful completion of this course, you should be able to:

Demonstrate the significance of Alcatel-Lucent services
List the different service types available and their components
Explain the encapsulation of service data with a service label and
transport label
Describe the operation of VPWS services
Configure, verify and troubleshoot an epipe service
Recognize the interworking capabilities of the different VPWS
Explain the operation of Virtual Private LAN Service (VPLS)
Configure and verify a VPLS
Module 0 |
11
Module 0 Page 11
Explain the concept of SAP and SDP and how they are used
Alcatel-Lucent Services Architecture Course Objectives
Explain the operation of Internet enhanced services (IES)

Describe the operation of the basic VPRN architecture
Configure, verify, and troubleshoot an IPv4 VPRN
Configure, verify, and troubleshoot an IPv6 VPRN
Module 0 |
12
Module 0 Page 12
Upon successful completion of this course, you should be able to:

Use the correct operations, administration and maintenance (OAM)
tools to analyze, manage, and troubleshoot IP/MPLS service
networks
Describe mirror services and differentiate between local and
distributed mirror services
Alcatel-Lucent Services Architecture Course Timeline
Day 1
Module 0 Course Introduction
Module 1 Services Overview and Implementation
Lab 1 IP/MPLS Infrastructure
Lab 2 - Distributed Epipe Service
Day 2
Module 2 Virtual Private Wire Service section 2 and 3
Module 3 Virtual Private LAN Service
Lab 3 VPLS Service
Lab 4 Spoke Termination to a VPLS
Module 0 |
13
Module 0 Page 13
Module 2 Virtual Private Wire Service section 1
Alcatel-Lucent Services Architecture Course Timeline (contd)
Day 3
Module 4 OAM Tools and Mirroring Service
Lab 5 OAM Tools
Module 5 Layer 3 Services (Sections 1 and 2)
Lab 7 IES
Lab 8 VPLS Spoke Termination on IES
Day 4
Module 5 Layer 3 Services (Sections 3-6)
Lab 9 IPv4 VPRN
Lab 10 IPv6 VPRN
Module 0 |
14
Module 0 Page 14
Lab 6 Mirror Service
Alcatel-Lucent Services Architecture Course Prerequisites

Suggested Prerequisites
Alcatel-Lucent Scalable IP Networks
Alcatel-Lucent Interior Routing Protocols
Alcatel-Lucent Services Architecture Exam

To ensure full comprehension of the material covered in this course, it is
recommended that, upon successful completion of the Services Architecture
course, the student register for and take this exam.
Module 0 |
15
Notice that the BGP section of the ASIN course is one of the important topics required as a prerequisite for
the Virtual Private Routed Network sections of module 5.
Module 0 Page 15
Alcatel-Lucent Multiprotocol Label Switching
Alcatel-Lucent Services Architecture Symbols and Icons
Alcatel-Lucent 7750 SR
Customer sites
Generic switch
Internet
MP-BGP Update
Pipe
Network cloud
(various colors)
Encapsulated Ethernet Frame
Module 0 |
16
Module 0 Page 16
IP router
Registration
Facility information
Restrooms
Communications
Materials
Schedule
Introductions
Name and company
Experience
Familiarity with Services Architecture
Questions
Module 0 |
17
Module 0 Page 17
Administration
www.alcatel-lucent.com
3HE-02770-AAAA-WBZZA Edition 01
Module 1 Services Overview & Implementation
Module 1 Page 1
Module Objectives
After successfully completing this module, you will be able to:
Describe the different service types offered on the AlcatelLucent 7750 SR

Explain the components required to support these services
Alcatel-Lucent Services Architecture v 3.2
Module 1 |

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. Visit the AlcatelLucent web site at www.alcatel-lucent.com/src for more information on the SRC program.
To locate additional information related to the topics presented in this manual, refer to the following:
Internet Standards documentation such as protocol standards bodies, RFCs and IETF drafts
Technical support pages of the Alcatel-Lucent web site located at http://www.alcatellucent.com/support
This module provides an introduction to the concept of a service router; the service configuration model
will be described along with various service entities such as customer, SAP and SDP. In addition, a brief
overview of service policies will also be covered. We will also examine how Alcatel-Lucent implements the
services concept, and steps are provided for deploying a services tunnel in a service providers core
MPLS backbone.
Module 1 Page 2
Describe a service router and how it differs from a traditional

router
Services Overview & Implementation
Section 1 Introduction to Services
Module 1 Page 3
Section Objectives
After successfully completing this section, you will be able to:
Describe the features of a service router
List the differences between a service router and a traditional
router
Define the concept of a service

Describe the types of services offered by the Alcatel-Lucent service
router
Module 1 |
Module 1 Page 4
Telecommunication Services Technologies

Service Providers Telecommunications Networks
Time division multiplexing (TDM) technologies for real-time voice
Frame Relay and ATM for private network services with specific
service levels
Requirement is to offer all types of services on one platform
Module 1 |
Historically, telecommunications service providers have deployed completely separate networks to

provide different types of services, such as time division multiplexing (TDM) technologies for real-time
voice, Frame Relay and ATM for private network services with specific service levels and IP for best effort
data services.
Module 1 Page 5
IP for best effort data services
Converged Network Infrastructure Requirements
Service providers consolidate the delivery of multiple service types

onto a single networking technology because of:
High cost of maintaining and operating discrete legacy networks
Consumer demand for new services that require higher bandwidth

service at decreasing prices
Module 1 |
A number of factors are driving service providers to evolve to a single network infrastructure that supports
the delivery of a wide variety of telecommunications services. These include:
High cost of maintaining and operating discrete legacy networks.
Service provider desire to continue to support high-revenue legacy services such as Frame Relay and
TDM.
Consumer demand for new services such as wireless data and streaming video.
Competitive market creating consumer expectations of higher bandwidth service at decreasing prices.
One approach to building a common infrastructure for deploying a wide range of telecommunication
services uses a core IP/MPLS network that supports a range of virtual private network (VPN) services.
Module 1 Page 6
The need to continue to support the high revenue legacy services

such as Frame Relay and TDM
A single network infrastructure using a core IP/MPLS network that supports a

range of virtual private network (VPN) services
Module 1 |
The Alcatel-Lucent 7750 SR product family was specifically designed to build a single network
infrastructure using a core IP/MPLS network that supports a range of virtual private network (VPN)
services
The Alcatel-Lucent 7750 SR has the ability to collapse separate overlay networks onto one platform while
still supporting an overlay model. Before we get into the details of the Alcatel-Lucent Service Router, we
need to understand what is meant by virtual private network (VPN)
Module 1 Page 7
Alcatel-Lucent Solution: Alcatel-Lucent 7750 Service Router
Virtual Private Network (VPN) Service

VPN is a network in which a shared infrastructure is used to provide private
services to its users
Virtual - A VPN to the service provider is a virtual network
Private - A VPN to the customer is a private network
Service:
A logical entity that refers to a type of connectivity (Internet, Layer 2 or
Layer 3 VPN)
Each service is uniquely identified by a service ID
Module 1 |
VPN is a network in which a service provider shared infrastructure is used to provide private services to its
customers. It is virtual since it does not require separate dedicated circuits between various locations, and
it is based on the logical as opposed to physical separation of the facilities. It is private in the sense that
customers can maintain their own addressing and routing schemes fully independent of and transparent to
other customers.
A service is a logical globally unique entity that provides a uniform, end-to-end configuration,
management, and billing model for provisioning either Internet or VPN connectivity between customer
access points; it can be either local or distributed.
Module 1 Page 8
Network A collection of devices that communicate with each other
The Alcatel-Lucent Service Router

A scalable IP router that offers best-effort IP routing and supports data
services using a service-oriented architecture
Module 1 |
A service router is a scalable Internet router that offers best-effort Internet services as well as enables the
migration of traditional data services to a service-oriented architecture.
Existing Layer 3 switches and Internet routers were designed around interfaces or physical ports for besteffort packet forwarding. It is often the case that edge routers are old core/Internet routers with
channelized interfaces; traditional IP service platforms were designed for low-speed, best-effort consumer
services.
Alternately, the Alcatel-Lucent service router is designed primarily for use as a service router. The service
router delivers service-level-agreement-based services, also known as SLA-based services. A service
router such as the 7750 SR must support additional functionality including:
Quality of Service (QoS) - The ability to provide distinct levels of service depending on the customer,
application or service level agreement.
Accounting - The ability to measure the traffic and service delivered based on a specific customer or
service and perform logging and billing accordingly
Filtering The ability to restrict or monitor specific traffic, based on customer or service
Troubleshooting The ability to analyze and troubleshoot problems from the perspective of a specific
service
These capabilities are supported to a varying degree in traditional IP routers, but generally they are
oriented around the routers interfaces or physical ports. It can be difficult to apply these functions to a
specific service instance since many services may use the same port.
Module 1 Page 9
Typical IP/MPLS Service Network Components

A service router functions as the Provider Edge (PE) router in a
service network
Module 1 |
10
The key component in a service network is the provider edge (PE) router that provides the interface
between the customer network and the core service provider network. All the service-specific functions are
found in the PE router
The service router functions as the PE router in a service network. It is a scalable, full function IP/MPLS
router that supports the full range of service types and customers and the additional service management
capabilities described earlier.
Access Routers typically support low-speed Internet access services and are not equipped to provide the
higher bandwidth required to meet future customer needs.
Core or Provider (P) routers support high-speed interfaces and are primarily designed to provide the
capacities for forwarding large quantities of data. Core routers are not well-suited for supporting the QoS,
bandwidth management and accounting functions needed by a service-edge router. These devices can be
connected to other PE or P routers. They will run a routing protocol for the purposes of internal routing in
the provider core using the providers choice of IP addressing.
Layer 2 or IP Service Switches were created in an attempt to enhance core routers; by increasing the
processing power, IP service switches provide services such as subscriber management and encryption.
However, the IP service switch does not support complete Internet routing functionality, nor does it provide
the same variety of routing policies that are available in a service edge router.
Module 1 Page 10
A PE router provides the interface between the customer network

and the core service provider network
Alcatel-Lucent 7750 SR Service Types

The following types of service are offered on the Alcatel-Lucent 7750
SR:
VPN services
Virtual private LAN service (VPLS) provides a multipoint Ethernet

service similar to an Ethernet switch
Virtual private routed network service (VPRN) provides a
multipoint IP routed service
Internet Enhanced Service (IES)

Provides the customer with a Layer 3 IP interface to send and
receive Internet traffic
Mirroring services
Module 1 |
11
A variety of different service types are supported in a service network of Alcatel-Lucent 7750 SRs, based
on a common core of IP/MPLS technology. The different possible VPN services are:
Virtual Private Wire Service (VPWS) also known as Virtual Leased Lines (VLL) Layer 2 point-to-point
service.
Virtual Private LAN Service (VPLS) - Layer 2 multipoint-to-multipoint VPN
Virtual Private Routed Network (VPRN) - Layer 3 IP multipoint-to-multipoint VPN service as defined in
RFC 4364 (formerly RFC 2547bis)
In addition to the VPN based services, the 7750 SR supports the Internet Enhanced Service. IES is a
Layer 3 direct Internet access service where the customer is assigned an IP interface for Internet
connectivity.
Mirroring services - allows an operator to see the actual traffic on a customers service with a sniffer.
Mirror service be will be discussed later in module 4.
Module 1 Page 11
Virtual private wire service (VPWS) provides a point-to-point

service that emulates a leased line
Virtual Private Wire Service (VPWS)

VPWS is a Layer 2 point-to-point service
VPWS defines a virtual point-to-point service that emulates a private leased
line connection
Module 1 |
12
Virtual Private Wire Service (VPWS)

The Alcatel-Lucent 7750 SR supports a Layer 2 point-to-point service commonly known as a Virtual
Private Wire Service (VPWS). The VPWS encapsulates customer data and transports it across a service
providers IP or MPLS network in a GRE or MPLS tunnel. VPWS is sometimes referred to as Layer 1
VPN, since there is no MAC learning required.
The Alcatel-Lucent service router is able to provide point-to-point Ethernet, Frame Relay, ATM
(Asynchronous Transfer Mode) or TDM (Time Division Multiplexing) service. In the slide figure a service
provider network provides an epipe (point-to-point Ethernet) service.
A pseudowire is an emulated, Layer 2 circuit built across an MPLS network that can transport Layer 2
PDUs (protocol data units) as if they were transmitted on their native media. Epipes (Ethernet), apipes
(ATM), fpipes (Frame Relay), ipipes (IP Interworking) and cpipes (TDM circuit emulation) are all examples
of pseudowire technologies and are described in more detail in Module 2.
Module 1 Page 12
VPWS encapsulates customer data and transports it across the service

providers network in a GRE (generic routing encapsulation) or MPLS tunnel
Types of VPWS
VPWS service supported on the Alcatel-Lucent 7750 SR

EPipe - emulates a point-to-point Ethernet service
Apipe - emulates a point-to-point ATM service
Cpipe - emulates a point-to-point TDM circuit

Ipipe - provides IP interworking capabilities between different Layer 2 technologies
Module 1 |
13
The types of VPWS service supported on the Alcatel-Lucent 7750 SR include:

Epipe - emulates a point-to-point Ethernet service. VLAN tagged Ethernet frames are supported.
Interworking with other Layer 2 technologies is also supported.
Apipe - emulates a point-to-point ATM service. A number of sub-types are provided to support different
ATM service types.
Fpipe - emulates a point-to-point Frame Relay circuit. Some features for interworking with ATM are also
supported.
Cpipe - emulates a point-to-point TDM circuit.
Ipipe - provides IP interworking capabilities between different Layer 2 technologies
Module 1 Page 13
Fpipe - emulates a point-to-point Frame Relay circuit
VPWS Advantages
Customers perspective:
Supports ATM, Frame Relay, TDM or Ethernet
Service provider (SP) network appears as a leased line between the two
customer locations
Service providers perspective:

Only the PE device is aware of the service
Scalability
Flexibility
The service provider can apply QoS, billing, ingress/egress traffic shaping
and policing on a per-service basis
Module 1 |
14
Scalability the service provider can support thousands of customers per router
Flexibility many different services for different customers can be provided over a single core IP/MPLS
network
Module 1 Page 14
Transparent to customer data
Virtual Private LAN Service (VPLS)
Module 1 |
15
Alcatel-Lucent supports Virtual Private LAN Service (VPLS) multipoint switched services. A VPLS is a
multipoint Layer 2 service that allows multiple customer sites to be connected in a single-switched domain
contained within a provider-managed IP/MPLS network. Customer sites in the VPLS appear to be on the
same LAN, even if the sites are geographically dispersed.
VPLS services switch traffic based on MAC addresses.
Module 1 Page 15
VPLS is an Ethernet service that connects multiple sites in a single

switched domain over a provider-managed IP/MPLS network
VPLS Advantages
It looks as if all sites appear to be connected to a single-switched
VLAN
Can operates over a single, local site or over multiple,
geographically-dispersed sites
Frames are only forwarded across the required links in the network
The advantages to the service provider are similar to those of a
VPWS service
Module 1 |
16
The VPLS advantages from the customers perspective are:

The VPLS is transparent to the customers data and higher layer protocols,
The VPLS can operate over a single local site or at multiple, geographically dispersed sites
The VPLS performs MAC learning so that frames are forwarded only across the required links in the
network
The advantages to the service provider are the same advantages as for a VPWS service. The SP can
reuse the IP/MPLS infrastructure to offer multiple services.
Module 1 Page 16
Transparent to the customers data
Virtual Private Routed Network (VPRN)
Module 1 |
17
Virtual Private Routed Network (VPRN)

IETF RFC 4364 (formerly RFC 2547bis) details a method of distributing routing information and forwarding
data to provide a Layer 3 Virtual Private Networks (VPN) service to end-customers. Each Virtual
Private Routed Network (VPRN) consists of a set of customer sites connected to one or more PE
routers. Each associated PE router maintains a separate IP forwarding table for each VPRN. The
diagram shows three VPRN services (Red, Yellow, and Green). The details of VPRN service operation
will be explained later in the course.
Module 1 Page 17
VPRN is a Layer 3 service that connects multiple sites in a routed domain

over a provider-managed IP/MPLS network
VPRN Advantages
Sites are connected to a private routed network administered by
the service provider for that customer only
The VPRN can operate over a single local site or over multiple
geographically-dispersed sites
The advantages to the service provider are the same advantages as
for a VPWS or VPLS service
Module 1 |
18
The VPRN advantages from the customer perspective are:

To the customer it appears as if all sites are connected to a private, routed IP network. The PE router
maintains a separate, virtual routing and forwarding (VRF) table for each VPRN
The IP address plan used by the customer is completely separate and independent of any address plan
used by the provider or any of its other customers.
The VPRN can operate over a single, local site or at multiple, geographically-dispersed sites
The advantages to the service provider are the same advantages as for a VPWS or VPLS service. The
service provider uses MP-BGP to distribute the routes for the different customer networks.
Module 1 Page 18
Separate and independent IP address plan per VPRN
Internet Enhanced Service (IES)

IES provides customers with direct Internet access via a Layer 3 IP interface
From the customers perspective, IES provides a direct connection to the
Internet
Module 1 |
19
An Internet enhanced service (IES) is a routed connectivity service where the subscriber communicates
with a Layer 3 IP interface to send and receive Internet traffic.
The difference between the IES and a basic network interface is that the service provider can apply all
QoS, billing, ingress/egress shaping and policing available within a service to the IES interface.
Module 1 Page 19
The service provider can apply all billing, ingress/egress shaping and
policing to the customer
Section 2 Transport and Service Label Signaling
Module 1 Page 20
Section Objectives
Explain how customer data is transmitted across the service
provider network (MPLS vs. GRE tunnels)
Explain the encapsulation of service data with a service label and
transport label
Module 1 |
21
Explain how service labels are signaled
Module 1 Page 21
MPLS or GRE tunnels are used to transmit customer data across the service
provider network
Multiple service tunnels can be carried within a transport tunnel
Multiple transport tunnels can be configured on a single network port
Inner service label defines the service tunnel; outer transport label defines
the transport tunnel
Module 1 |
22
All the IP/MPLS VPN services described in section one use MPLS or GRE tunnels to transmit customer
data across the service provider network. When MPLS is used, customer data is encapsulated with two
MPLS labels; an outer transport label and an inner service label.
Alcatel-Lucent routers are connected to physical links that are used to carry traffic. When a service is set
up using MPLS, transport LSP tunnels are set up between provider edge, or PE, routers. Each service or
customer sends traffic through a service tunnel within the transport LSP tunnel. Transport tunnel LSPs are
identified by MPLS labels that are swapped at each intermediate router, also known as a transit LSR,
along the LSP from the ingress to the egress of the MPLS network.
The service label, or VC label, is used to identify which service or customer owns the packet. In the
identification process, the label is attached at the ingress point and does not change value as the packet
travels from ingress to egress.
Module 1 Page 22
Transport Tunnels and Service Tunnels
Transport Tunnels and Service Tunnels (continued)

Transport tunnels:
RSVP-TE or LDP signaled LSP
Labels are signaled using RSVP-TE or LDP
The MPLS-encapsulated data is forwarded to the egress PE for the service
The data is encapsulated with an IP header

The source IP address is the ingress PE router and the destination address is the
egress PE router
Typically used when there are routers in the transport network that do not
support MPLS label switching
Service tunnels:
MP-BGP or T-LDP are used to set up per-VPN service tunnels
Module 1 |
23
Typically the transport tunnel is an RSVP-TE or LDP signaled LSP although it may also be a GRE tunnel.
Because the customer data is MPLS-encapsulated, forwarding across the network is not based at all on
the customer data. The encapsulated data is simply forwarded to the tunnel egress, which is the egress
PE for the service.
In GRE the data is encapsulated with an IP header. The source IP address is the ingress PE router and
the destination address is the egress PE router. This header is used to route the packet across the
network. The customers data has no influence on forwarding while the packet is in the GRE tunnel. GRE
does not support traffic engineering futures that are available in MPLS
Our focus here is on the use of MPLS for transport tunnels.
Module 1 Page 23
GRE tunnel
Transport and Service Label Encapsulation
DLC header Layer 2 header used to transport the MPLS packet
MPLS transport (outer) label The label signaled by the next-hop PE
Service (inner) label The service, or virtual circuit (VC) label that
identifies the service the packet belongs to
Control word Optional and primarily used for ATM or Frame Relay
services
Service packet The customer data being transported by the service
Module 1 |
24
Services over MPLS

In an IP/MPLS service network, data is encapsulated with at least two labels, the transport label and the
service label.
Data Link Control Header (DLC Header) - a Layer 2 header used to transport the MPLS packet. In many
cases, the data link, or Layer 2, header in use is Ethernet. In this case, all of the following apply: a 14-byte
DLC header, a 6-byte destination MAC address, a 6-byte source MAC address and a 2-byte Ethertype
field (0x8847 for MPLS or 0x0800 for IP/GRE). The 7750 SR also supports packet over SONET/SDH
(POS).
When services are configured over MPLS, customer traffic is encapsulated in MPLS frames and sent over
MPLS tunnels. A service label, or VC label, that indicates a specific customer connection, such as a
Frame Relay DLCI, is pushed into the label stack between the transport tunnel label and the packet data.
An optional service-specific control word may be placed between the packet data and the service label.
The control word is used for frame sequencing and/or carrying service-specific information, such as
Frame Relay forward explicit congestion notification (FECN) and backward explicit congestion notification
(BECN) information. At the tunnel-end, the service label is used to find the customer interface over which
the traffic is sent. The control word, if present, is used to convert the encapsulated customer traffic into its
native format.
Note: do not confuse VC Label with the VC ID that is used for service provisioning.
Module 1 Page 24
MPLS encapsulation of VPN service traffic
Transport and Service Label Encapsulation (continued)
IP header and the GRE header are used instead of the MPLS transport label
A service label is still required to demultiplex the packet to the appropriate

service
The service provider routers use the GRE header to route the packet across
the network
Module 1 |
25
Services over GRE

When GRE is used to transport services, an MPLS transport label is not used. Instead, an IP header is
used, where the source IP address is the local PE router and the destination IP address is the far-end PE
router. The minimum GRE header consists of 4 bytes: 2 for the flags, and 2 are used as protocol type files
(contains the protocol ID of the payload packet). The MPLS protocol ID, which identifies the MPLS service
label, is 0x8847. It is important to note that in this case, even though GRE is used for transport, an MPLS
service label still exists so that the far-end PE can de-multiplex the service correctly. Therefore, unlike with
MPLS transport labels, there is no label swapping at each router in the service providers network.
Rather, the outer IP header is used to forward the packet through the service provider network; as such,
the IP header is not swapped at each router. The GRE IP header is stripped at the far-end provider edge
router, which then uses the service label to demultiplex the service. At this point, the service label is
stripped before the frame is passed to the customer. The main application of GRE would be in the case
that a service provider has transport routerss (P routers) that are not MPLS-capable. In this case, GRE
could be used to encapsulate the frame and only MPLS would be required on the service endpoint routers
(PE routers). In general, if MPLS-capable routers are available, the MPLS will be utilized for the transport
tunnel.
Module 1 Page 25
GRE encapsulation of VPN service traffic
MPLS Transport and Service Label Signaling

MPLS transport tunnel signaling protocols:
LDP or RSVP-TE are used to set up LSPs
Provide a means to set up label-switched paths, also known as LSPs, that
can carry many other service tunnels
Service labels, or VC labels, are used to encapsulate and identify

customer traffic that belongs to a particular service
A service label is applied to the customer traffic before the transport
label, or LSP label, is applied
VPLS and VPWS services are signaled using targeted LDP, also known as
T-LDP
VRPN service is signaled by MP-BGP, based on RFC 4364 (formerly RFC
2547bis)
Module 1 |
26
Signaling protocols use LDP and/or RSVP-TE to set up LSPs, which can then be used for various service
tunnels.
Service labels are used to encapsulate and identify customer traffic belonging to a particular service. This
label is applied to the customer traffic before the transport label is applied. Service labels for VPLS and
VPWS services are signaled using T-LDP.
T-LDP is the same protocol as link LDP used for signaling transport labels with a few additional
capabilities added. Sessions are LDP sessions between non-directly connected peers. When a service
distribution point (SDP) is configured (SDP will be explained in the next section), automatic ingress and
egress labeling is enabled by default, and ingress and egress service labels are signaled over a T-LDP
connection. If signaling is turned off on an SDP, ingress and egress service labels must be manually
configured when the SDP is bound to a service.
In a VPRN service, MP-BGP is used to exchange customer routes across the VPRN. The BGP updates
also include a label for these routes.
Signaling is required between the PE routers in order to provide the necessary connectivity information
throughout the VPN. Two approaches exist to provide this end-to-end signaling information. One approach
is known as Martini Signaling and uses LDP, while the second approach is known as Kompella Signaling
and uses BGP. The Draft-Martini uses T-LDP between the PE routers to distribute VC labels. This
mechanism contains information such as the unique VC ID, the specific interface parameters and the VC
Type, such as ATM, Frame Relay and Ethernet. The PE routers use this information to build the
forwarding tables and set up the VC LSPs. The Draft-Kompella approach makes use of BGP between the
PE routers to advertise route distinguishers and route targets. This enables the receiving PE to determine
if the incoming BGP update is relevant for its VPN clients. If so, the receiving PE accepts the update and
populates the forwarding tables accordingly. Currently the Martini approach is more commonly used than
the Kompella Draft for signaling purposes.
Martini draft was standardized under RFC 4096. Draft-Kompella is obsolete and was not standardized.
Module 1 Page 26
Service tunnel signaling protocols:
TLDP/MPBGP
Module 1 |
27
The physical topology of the base is made up of four routers set up in series-form. The routers presented
in this slide are two PE routers, representing the edge of the service provider network, and two P routers,
representing the service provider core.
The service provider makes use of an IGP to propagate routing knowledge for PE-PE connectivity.
Either LDP or RSVP-TE is used for label propagation. Once each router has advertised its label
knowledge to the neighboring routers, a complete LSP will have been created.
Targeted (targeted) LDP or MP-BGP is then used to establish an end-to-end connection-oriented session,
providing the inner label. The inner label is used for service tunnel signaling.
Once we have signaled service labels and created a transport tunnel between the two PE endpoints, we
have created a service.
The difference between link LDP and T-LDP is that T-LDP is used for exchanging service label information
and the T-LDP peers do not need to be directly connected. Because they may not be directly connected, a
router must know the IP address of its T-LDP peer. It then sends its Hello messages to its peers unicast
address instead of the multicast address. Otherwise the process for establishing adjacencies and the
messages exchanged are the same as for link LDP.
LDP must be enabled to configure VPWS or VPLS services so that T-LDP can signal the service labels,
even if RSVP-TE is used for signaling the transport labels.
Module 1 Page 27
MPLS Transport and Service Label Signaling (continued)
The exchange of service labels occurs when the pseudowire is created
The following outlines the service label signaling process:

1. PE2 sends PE1 a service label (11350)
2. PE1 sends PE2 a service label (21350)
3. Unidirectional service tunnels are created
4. PE1 uses the label (11350) to send traffic towards PE2
Module 1 |
28
5. Likewise, PE2 uses label (21350) to send traffic towards PE1
The exchange of service labels occurs when the service is created.
Module 1 Page 28
Module 1 |
29
The core LSRs use information from the top label when switching the labeled frame across the MPLS
domain. It is possible that during this process, additional labels can be also be pushed along the way. The
egress LER infers from the VC label how to process the frame and then forwards it to the appropriate
outgoing port; however, the VC label is not visible until the frame reaches the egress LER due to the
MPLS tunneling hierarchy.
This slide shows the order of events that occur when signaling transport and service labels for a service
and then subsequently forwarding a packet. The control plane is right to left, while the data plane is left to
right (the traffic is sent from PE1 to PE2). It is important to note that the control and data planes are
always in opposite directions. For the purpose of this discussion it is assumed that IGP convergence has
already occurred.
LDP is enabled, which creates the outer service tunnel label. It should be noted that RSVP could
also have been used in this case. PE1 receives LDP label 217 from P1 and, therefore, uses label
217 as the label representing the LSP to PE2
T-LDP or MP-BGP is enabled, which creates an end-to-end connection-oriented session between
PE1 and PE2, and propagates the service label
A data packet arrives at PE1 and is encapsulated with both the outer label, learned through LDP,
as well as the service label, learned through T-LDP or MP-BGP
As the data packet traverses the P routers, the outer label is swapped while the inner label remains
unchanged
Upon receiving the data packet, the receiving PE, in this case PE2, removes the outer LDP label.
Then, prior to removing the inner label, the receiving PE maps it to the appropriate service.
The result is the original data packet, which is then forwarded to correct interface for the service,
and then on to the CE (not shown).
Note: the control plane / dataplane would be in the opposite direction for sending traffic from PE2 to PE1
Module 1 Page 29
Section 3 Service Components
Module 1 Page 30
Section Objectives
Describe the main components required to configure Alcatel-Lucent
services (SAP, service ID, VC-ID, SDP)
Explain the concept of SAP and encapsulation identifier
Describe the operation of a local service

Configure and verify a local service
Describe the operation of a distributed service
Define a service distribution point (SDP) and list its characteristics
Configure and verify a distributed service
Module 1 |
31
Module 1 Page 31
Module 1 |
32
The Alcatel-Lucent router is based on the service model where service edge routers are deployed at the
provider edge. Services are provisioned on the router and transported across an IP and/or IP/MPLS
provider core network in encapsulation tunnels, created using GRE or MPLS LSPs.
The service model uses logical service entities to construct a service. The logical service entities are
designed to provide a uniform, service-centric configuration, management and billing model for service
provisioning.
The service model is based on the following components:
Subscriber - describes the user of the service
Service access point (SAP) - The subscribers point of interface to the service network
Customer ID - A value associated with the service that can be used to group together a number of services
for reporting purposes
Service ID - The numeric value used on the 7750 SR to identify the service
Service Type The type of the service that is configured on the 7750 SR (VPWS, VPLS, VPRN, IES)
VC ID - Identifies the service when signaling the service labels. This value must match at both ends of the
service. The VC ID is usually the same as the service ID
Service distribution point (SDP) - A logical representation of the transport tunnel that will be used to deliver
the service data to the egress PE
Transport tunnel - This is the LSP used to transport the service data, typically signaled with RSVP-TE or LDP.
An SDP is associated with the transport tunnel
Service tunnel - This is the tunnel represented by the service labels signaled end-to-end by the two PEs that
are the service endpoints
Demultiplexer - Represents the operation of delivering the data arriving at the egress router to the appropriate
service based on the service label
Module 1 Page 32
Service Components
The terms customers and subscribers are used synonymously here
The customer ID is assigned when the customer account is created
To provision a service, a customer ID must be associated with the service at

the time of service creation
Multiple services can be associated with one customer
The customer ID for the service cannot be changed once the service is created
Module 1 |
33
Once a service has been created with a customer association, it is not possible to edit the customer
association; the service must be deleted and recreated with a new customer association. Once a service
is created, the use of the customer ID is optional for navigating into the service configuration context.
Attempting to edit a service with the incorrect customer ID specified will result in an error.
The customer must be created before the service is created. The customer ID for the service cannot be
changed once the service is created. Although it is recommended that a globally consistent value be used
for the customer ID, it is never signaled to other PEs and has no effect on the service.
Module 1 Page 33
Customers and Subscribers
Customer Creation
*A:PE-1# configure service customer 100 create

*A:PE-1>config>service>cust$ description "VPWS_Customer"
*A:PE-1>config>service>cust$ phone "1-111-111-1111"
*A:PE-1>config>service>cust$ exit
*A:PE-1# show service customer

===============================================================================
===============================================================================
Customer-ID
: 1
Contact
: (Not Specified)
Description
: Default customer
Phone
: (Not Specified)
Customer-ID
: 100
Contact
: (Not Specified)
Description
: VPWS_Customer
Phone
: 1-111-111-1111
------------------------------------------------------------------------------Total Customers : 2
Module 1 |
34
When using the CLI to configure services, a customer ID of 1 is used by default, but it is good practice to
configure specific customer IDs
Module 1 Page 34
Customers
Service Identifiers
Service ID - The numeric value used on the 7750 SR to identify the
service
A service is associated with a customer ID
Module 1 |
35
Service
The Alcatel-Lucent 7750 service router is a service-based router. All functionality revolves around the
concept of a service, where a service is a unique entity that refers to the type of connectivity for either
Internet (Layer 3), or VPN (Layer 2 or Layer 3) connectivity.
A service is considered to be any of the following:
VPWS, including apipe, epipe and fpipe
VPLS
VPRN
IES
Mirroring, which is used for management and troubleshooting
A service can be either a local service, in which case it must be defined and associated with two local
SAPs; or it can be distributed, in which case it must be defined and associated with a SAP and an SDP.
Local and distributed service will be explained in more details in the following slides.
Module 1 Page 35
A service must be created using a unique service ID on that router
Service Creation
*A:PE-1# configure service epipe 50 customer 100 create
*A:PE-1# show service id 50 base

===============================================================================
Service Basic Information
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 100
Last Status Change: 01/30/2012 16:55:09
Last Mgmt Change : 01/31/2012 11:48:48
Admin State
: Up
Oper State
: Down
MTU
: 1514
Vc Switching
: False
SAP Count
: 0
SDP Bind Count
: 0
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------No Matching Entries
Module 1 |
36
The slide shows the creating of an epipe service. The service is operationally down because it is not
completely configured.
Service ID identifies the service on the local router. A service must be created using a unique service ID.
Once a value is used for one service it cannot be used for another on that router.
Note: the vpn id is used to specify the VPN ID number, allowing you to identify virtual private networks
(VPNs) by a VPN ID. If this parameter is not specified, the VPN ID uses the same service ID number.
Values 1 2147483647
Default null (0)
Module 1 Page 36
*A:PE-1>config>service>epipe$ no shutdown
Service Access Point (SAP)

A SAP is the subscribers point of interface to the service network
A SAP is specified as a physical port and an encapsulation identifier
SAP
1/2/3
Service
Module 1 |
37

A SAP is a logical entity that serves as the customers point of access into a service. Each subscriber
service is configured with at least one SAP. A SAP can only be configured on a port that has been
configured specifically as an access port. The default configuration for a port is network, which means
that you may need to reconfigure a port before you can configure a SAP onto it. SAPs for IES and VPRN
services are configured on IP interfaces. A SAP is the subscriber-side entry and exit point for a service.
Module 1 Page 37
To be used as a SAP, a port must be configured as an access port
SAP Configuration Considerations

A SAP ID is locally unique the same SAP ID value can be used on another service
router
A SAP is associated with a single service and can only be configured on an access
port
A port or channel can have more than one SAP configured on it
All SAPs must be explicitly created and are administratively enabled at the time of
creation there are no default SAPs
VLAN IDs have local port significance
A SAP can be configured with any of the following:
Ingress and egress filter policy
Ingress and egress QoS policy
Ingress and egress scheduler policy
Accounting policy
Module 1 |
38
VLAN ID is the encapsulation ID that is used to distinguish services.
Module 1 Page 38
SAP ID
A SAP is a local entity to the service router and is uniquely
identified by the following:
The physical Ethernet port or SONET/SDH or TDM port and channel
Depending on the encapsulation, a physical port or channel can

have more than one SAP associated with it
SAPs can only be created on ports or channels designated as
access in the physical port configuration
SAPs cannot be created on ports designated as core-facing
network ports
Module 1 |
39
SAP Encapsulation Types and Identifiers

A SAP is local to the router and is uniquely identified by the following:
Physical Ethernet port or packet-over-SONET/SDH (POS) port and channel
Encapsulation identifier (ID)
The encapsulation identifier depends on the type of port used as the SAP. For example, if the SAP is an
Ethernet port, the encapsulation identifier can be a VLAN tag or a Q-in-Q tag. The encapsulation identifier
may be null in which case the SAP is simply the port.
The encapsulation type is an access property of a service Ethernet port or SONET/SDH or TDM channel.
The appropriate encapsulation type for the port or channel depends on whether it is required to support
multiple services on a single port/channel on the associated SAP, and the capabilities of the downstream
equipment connected to the port/channel. For example, a port can be tagged with IEEE 802.1Q
encapsulation, referred to as dot1Q encapsulation, in which each individual tag can be identified with a
service. A SAP is created on a given port or channel by identifying the service with a specific
encapsulation ID.
Depending on the encapsulation used, a physical port or POS channel can have more than one SAP
associated with it. Using dot1Q encapsulation or POS channels, the router can support either multiple
services for one customer, or one service for multiple customers.
SAPs cannot be created on ports designated as core-facing network ports bacause these ports have a
different set of features enabled in software.
Module 1 Page 39
The encapsulation identifier (ID)
Ethernet Encapsulations
Null supports a single service on the port
Dot1Q supports multiple services for one customer or multiple services
for multiple customers
Ethernet port encapsulation can be set using the following command:

config>port>ethernet encap-type
where encap-type: dot1q|null|qinq
Module 1 |
40
Null supports a single service on the port; for example, where a single customer with a single service customer
edge (CE) device is attached to the port, the encapsulation ID is always zero. For example: sap 1/1/3
Dot1Q supports multiple services for one customer or multiple services for multiple customers.
For example: the port is connected to a multi-tenant unit (MTU) device with multiple downstream customers.
The encapsulation ID used to distinguish an individual service is the VLAN ID in the IEEE 802.1Q header. For
example: sap 1/1/3:50
Q-in-Q The Q-in-Q encapsulation type adds an IEEE 802.1Q tag to the 802.1Q-tagged packets entering the
network in order to expand the VLAN space by tagging tagged packets.
For example: sap 1/1/3:10:100
On SONET ports the following encapsulation types are supported:
Internet Protocol Control Protocol (IPCP)
IPCP supports a single IP service on SONET/SDH for each port or for each channel.
This is typically used for router interconnection that uses point-to-point protocol (PPP).
Bridging Control Protocol (BCP-null)
BCP-null supports a single service.
SONET/SDH port
SONET/SDH port for each channel if the interface is channelized.
BCP-null is used for bridging a single service between two devices using PPP over SONET/SDH. The
encapsulation ID is always zero.
Bridging Control Protocol (BCP-Dot1Q)
BCP-Dot1Q supports multiple services on the SONET/SDH port or channel.
BCP-Dot1Q is used for bridging multiple services between two devices using PPP over SONET/SDH.
The encapsulation ID that is used to distinguish services is the VLAN ID in the IEEE 802.1Q header found in
the BCP-encapsulated frame.
SONET port encapsulation can be configured from the following menu:

config>port# sonet-sdh path encap-type
{atm|bcp-null|bcp-dot1q|ipcp|ppp-auto|frame-relay|wan-mirror|cisco-hdlc
Module 1 Page 40
Q-in-Q The Q-in-Q encapsulation type adds an IEEE 802.1Q tag to the
802.1Q-tagged packets entering the network to expand the VLAN space by
tagging tagged packets. This produces a double-tagged frame
SAP Configuration
*A:PE-1# show port

===============================================================================
Ports on Slot 1
===============================================================================
Port
Admin Link Port
Cfg Oper LAG/ Port Port Port
SFP/XFP/
Id
State
State
MTU MTU Bndl Mode Encp Type
MDIMDX
------------------------------------------------------------------------------1/1/1
Up
Yes Up
1578 1578
- netw null gige
1/1/2
Down No
Down
1578 1578
- netw null gige
1/1/3
Up
Yes Up
1518 1518
- accs dotq gige
1/1/4
Down No
Down
1578 1578
- netw null gige
1/1/5
Down No
Down
1578 1578
- netw null gige
1/1/6
Down No
Down
1578 1578
- netw null gige
1/1/7
Down No
Down
1578 1578
- netw null gige
1/1/8
Down No
Down
1578 1578
- netw null gige
1/1/9
Down No
Down
1578 1578
- netw null gige
1/1/10
Down No
Down
1578 1578
- netw null gige
===============================================================================
Module 1 |
41
To be used as a SAP, a port must be configured as an access port. Ports are configured as network ports
by default.
Note: when the ports are configured as Ethernet access ports with dot1q encapsulation, they are
automatically changed to an MTU (maximum transmission unit) of 1518. This defines the maximum size of
frame that will be accepted for a service using this port as a SAP. By default the 7750 SR configures an
Ethernet access port to accept a standard-sized Ethernet frame. Since this port is configured for dot1q
encapsulation, the MTU is 1518. MTU consideration will be explained in detail in Module 2.
Many other encapsulation types are possible. These depend on the MDA type of the port and the type of
service being provisioned. SAP encapsulations are described in more detail in Module 2.
Module 1 Page 41
*A:PE-1# configure port 1/1/3

*A:PE-1>config>port# shutdown
*A:PE-1>config>port# ethernet
*A:PE-1>config>port>ethernet# mode access
*A:PE-1>config>port>ethernet# encap-type dot1q
*A:PE-1>config>port>ethernet# exit
*A:PE-1>config>port# no shutdown
*A:PE-1>config>port# exit
Local Service
Module 1 |
42
A service can be either local or distributed. A local service involves two SAPs and provides a connection
path between two sites. A local service provides a point-to-point logical connection from the customers
perspective.
Module 1 Page 42
In a local service, all components of the service are on a single router.
Local Service Configuration

Local epipe service configuration on a single router:
Module 1 |
43

*A:PE-1>config>service>epipe# sap 1/1/1 create
*A:PE-1>config>service>epipe>sap$ exit
*A:PE-1>config>service>epipe# sap 1/1/2 create
*A:PE-1>config>service>epipe>sap$ exit
Note: the CE routers are configured with IP interfaces as shown below:

*A:CE-1# configure port 1/1/1 no shutdown
*A:CE-1# configure router interface "toCE2"
*A:CE-1>config>router>if# port 1/1/1
*A:CE-1>config>router>if# address 192.168.1.1/24
*A:CE-1>config>router>if# show router interface
Module 1 Page 43
*A:PE-1>config>service>epipe# show service id 50 base

===============================================================================
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 100
Last Mgmt Change : 01/31/2012 15:15:21
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 2
SDP Bind Count
: 0
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/1
q-tag
1514
1514
Up
Up
sap:1/1/2
q-tag
1514
1514
Up
Up
===============================================================================
Module 1 |
44
As shown in the slide, the epipe service is up and the CE routers should be able to reach each other over
the Ethernet connection, as shown in the ping test below:
*A:CE-1> ping 192.168.1.2 count 1
PING 192.168.1.2 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=4.45ms.
Module 1 Page 44
Local Service Verification
A distributed service has components on multiple routers and uses the

IP/MPLS network to connect the service and deliver data
SDP binding is required to signal the service labels and define the
transport to the remote router
Module 1 |
45
A distributed service has components on multiple routers and uses the IP/MPLS network to connect the
service and deliver data.
Distributed service spans more than one router. It uses SDPs to direct traffic to another router; traffic is
transported by a transport tunnel through a service tunnel.
Module 1 Page 45
Distributed Service
A service distribution point (SDP) is a logical entity used to direct traffic

from one router to another through a unidirectional service tunnel
SDPs are locally unique; the same SDP ID can be used on another router
SDPs use the system IP address to identify far-end destinations
An SDP is not specific to one service; many services can use the same SDP
All services bound to an SDP use the same encapsulation
Operations on an SDP will affect all services that are bound to that SDP
Module 1 |
46
A service distribution point (SDP) acts as a logical way to direct traffic from one router to another through
a unidirectional service tunnel. The SDP terminates at the far-end router, which directs packets to the
correct service egress SAPs on that device. A distributed service consists of a configuration with at least
one SAP on a local router, one SAP on a remote router, and an SDP binding the service to the service
tunnel.
An SDP has the following characteristics:
An SDP is locally unique to a router. The same SDP ID can appear on other routers.
An SDP uses the system IP address to identify the far-end edge router.
An SDP is not specific to any one service or type of service. Once an SDP is created, services are
bound to the SDP. An SDP can also have more than one service type associated with it.
All services mapped to an SDP use the same transport encapsulation type defined for the SDP
either GRE or MPLS.
An SDP is a management entity. Even though the SDP configuration and the services carried
within are independent, they are related objects. Operations on the SDP affect all the services
associated with the SDP. For example, the operational and administrative state of an SDP controls
the state of services bound to the SDP.
A return-path SDP is needed when a far-end device communicates with a local device. Each device must
have an SDP defined for every remote router that is receiving service. Before a distributed service can be
configured, SDPs must first be created.
Module 1 Page 46
Service Distribution Point (SDP) Characteristics
Binding an SDP to a Service

SDPs provide the binding between the control plane signaling of
service labels and the transport tunnels (LDP/RSVP or GRE)
To direct a service to use an SDP for distribution, the service is
joined to the SDP using SDP binding
A service label is not signaled unless the service is bound to an SDP
Module 1 |
47
Because all service distribution relies on the SDP, the transport is

most often RSVP with fast rerouting capabilities
Module 1 Page 47
Creating an SDP and SDP Characteristics

The SDP ID is locally unique
This means that the same SDP ID can appear on other routers
The SDP uses the system IP address to identify the far-end PE
The SDP is not specific to any single service
More than one service type can be associated with an SDP
SDP defines which transport encapsulation type is used by the
services
Module 1 |
48
Other SDP characteristics include the following:

An SDP is a management entity. Even though the SDP configuration and the services carried within it are
independent of each other, they are related objects. Operations on the SDP affect all the services
associated with the SDP; for example, the operational and administrative state of a SDP controls the state
of services bound to the SDP.
An SDP from the local device to a far-end eLER (egress label edge router) requires a return-path SDP
from the far-end back to the local router.
Each device must have an SDP defined for every remote router it provides service to.
Module 1 Page 48
The SDP must be created before the service configuration
SDP Encapsulation Types

MPLS encapsulation:
Uses LDP or RSVP-TE for label signaling
LDP relies on an IGP to find its path
RSVP-TE requires additional configuration
GRE encapsulation:
Encapsulates traffic in an IP/GRE header, appears as an IP packet
Low control plane overhead
GRE uses normal IP routing to find a path
Module 1 |
49
MPLS Encapsulation
MPLS uses LDP or RSVP-TE for label signaling
LDP relies on an IGP to find its path
RSVP-TE requires manual configuration, path can be loose or strict, may reserve bandwidth, and
can use fast reroute to speed convergence after change
Generic Routing Encapsulation (GRE)

Low control plane overhead
Uses an IGP to find a path from edge to edge
Convergence depends on the IGP
Module 1 Page 49
RSVP-TE allows finer control of paths
Module 1 |
50
Transport Tunnel
A transport tunnel is used by an SDP to direct traffic from one router to another.The diagram shows that
multiple services can use the same SDP.
Multi-router VPWS and VPLS traffic is transported using unidirectional service tunnels. Service tunnels
originate on an SDP on one router and terminate at a destination router. The destination router directs
packets to the correct service egress interfaces on that device. Service tunnels can be configured to use
either GRE or MPLS LSPs. Services that originate and terminate on the same router do not require
service tunnels or SDPs.
Module 1 Page 50
Logical Service-Level View
Module 1 |
51
Each SDP identifies the destination-system-ID as the far-end address, thereby specifying the targeted
LDP connection. The SDP ID is not transferred to the far-end system, therefore the SDP ID does not need
to match. Although it is not necessary for the SDP ID to be identical on opposite sides of the service
tunnel, it is suggested. Alternately, the SDP ID must be locally unique in each system. In addition, it is not
necessary that the service ID be identical on each system. By default, the service ID equals the VC ID.
In the diagram in this slide, Subscriber A has two sites which are being connected by a VPWS. This
VPWS provides a virtual point-to-point connection across any existing IP/MPLS network infrastructure,
while maintaining the appearance of a directly connected segment.
Module 1 Page 51
Single Subscriber Distributed VPWS Service
Module 1 |
52
Multiple services can be associated with the same SDP allowing subscribers to have access to multiple
sites across multiple platforms for multiple services.
In the diagram in this slide, Subscriber A has two sites while Subscriber B has three sites. In relation to
Subscriber A, Site 1 and Site 2 are connected by a point-to-point connection a VPWS. In the case of
Subscriber B, each site requires access to all three locations, which is more indicative of a VPLS offering.
Since services can be bound to multiple SDPs, the number of SDPs only needs to equal to the number of
connected neighbors, regardless of how many subscribers or services are being used.
Module 1 Page 52
Multiple Subscribers
Module 1 |
53
Multiple SAPs can be associated with a single service. In this way, a subscriber can have multiple access
points into a single service.
In the diagram in this slide, Subscriber B, Subscriber Site 1, Subscriber Site 2 and Subscriber Site 3 are
all interconnected; however, Subscriber Site 1 and Subscriber Site 2 have two SAPs each.
Module 1 Page 53
Multiple SAPs on a Single Service
Module 1 |
54
Physical interfaces can be identified with multiple services based on the tag information. In the diagram
on this slide, two subscribers, A and B, are using the same physical port but are uniquely identified by their
tag ID. The tag ID is used to uniquely identify two separate SAPs connected to two separate services.
Module 1 Page 54
Multiple SAPs on a Single Port
Distributed Site Single Service Logical View
Module 1 |
55
Connection
Connectiontype
typeisisdependant
dependanton
onhow
how
the
service
is
defined.
the service is defined.
Module 1 Page 55
Module 1 |
56
Logical Service-Level Connectivity
Service Connectivity
The SAP is the customer access point to the service
The SAP is provisioned on access ports only; encapsulation must be specified
Service Distribution Point (SDP)
SDPs have a locally unique ID number
The SDP typically uses the system address of the far-end router
The SDP encapsulation type is GRE or MPLS
Service ID
The service ID is provisioned by the user to uniquely identify a service
It is suggested to have a globally unique value for each service
Virtual Circuit ID (VC ID)
The VC ID must be identical end-to-end
The VC ID is provisioned by the user by default and used by T-LDP to negotiate the service label in
Martini encapsulation
Using T-LDP, the egress and ingress service label that is provisioned or dynamically assigned
uniquely identifies the service to the tunnels far end
Module 1 Page 56
Section 4 Distributed Service Configuration
Module 1 Page 57
Distributed Service Configuration
The following steps must be completed for a successful distributed

service operation:
IGP configuration - ensure that routing tables have system addresses
Signaling transport labels are enabled for either LDP or RSVP

LDP has to be enabled for dynamic signaling of service labels using T-LDP
Creation of a path if using RSVP
Creation of LSP and bind path if using RSVP
Creation and binding of SDP to LSP if using RSVP or select LDP
Module 1 |
58
Module 1 Page 58
Distributed Service Configuration - Continued

Customer-facing ports must be changed to access mode and
encapsulation must be changed as required to any of the following:
null, dot1Q or q-in-q
Creation of the service and selection of the service type, including

any of the following: epipe, fpipe, apipe, ipipe or cpipe. In addition,
the following must also be done:
Add SAPs to service
Add SDPs to service with VC ID
Module 1 |
59
Module 1 Page 59
Distributed Service Configuration Case Study
Module 1 |
60
The following slides demonstrate the provisioning steps using the network topology shown in this slide. In
this case, we will be using OSPF for the IGP and RSVP to set up our transport tunnels.
Module 1 Page 60
Distributed service configuration will be demonstrated using the

following network:
IGP Configuration
Network ports and system interface are added to IGP
*A:PE-1>config>router>ospf# info
---------------------------------------------area 0.0.0.0
interface "system"
exit
interface "to-PE2"
interface-type point-to-point
exit
exit
*A:PE-1>config>router# info
---------------------------------------------echo "IP Configuration"
#---------------------------------------------interface "system"
address 10.10.10.1/32
exit
interface "to-PE2"
address 10.1.2.1/27
port 1/1/1
exit
*A:PE-1# show router ospf neighbor

===============================================================================
OSPF Neighbors
===============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
------------------------------------------------------------------------------to-PE2
10.10.10.2
Full
1
0
34
------------------------------------------------------------------------------No. of Neighbors: 1
Module 1 |
61
Module 1 Page 61
Network Convergence
Routing table contains the system addresses
*A:PE-1# show router route-table
Module 1 |
62
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.2.0/27
Local
Local
13h45m55s
0
to-PE2
0
10.10.10.1/32
Local
Local
01d16h57m
0
system
0
10.10.10.2/32
Remote OSPF
13h28m51s
10
10.1.2.2
100
------------------------------------------------------------------------------No. of Routes: 3
===============================================================================
Module 1 Page 62
Enable MPLS
Network ports and system interfaces are added to MPLS
Enable RSVP with the no shutdown command
*A:PE-1# show router mpls interface

===============================================================================
MPLS Interfaces
===============================================================================
Interface
Port-id
Adm
Opr
TE-metric
------------------------------------------------------------------------------system
system
Up
Up
None
Admin Groups
None
Srlg Groups
None
to-PE2
1/1/1
Up
Up
None
Admin Groups
None
Srlg Groups
None
------------------------------------------------------------------------------Interfaces : 2
===============================================================================
Module 1 |
63
You need to enable RSVP with the no shutdown command as follows

*A:PE-1# configure router rsvp no shutdown
*A:PE-1# show router rsvp interface
===============================================================================
RSVP Interfaces
===============================================================================
Interface
Total
Active
Total BW Resv BW
Adm Opr
Sessions Sessions (Mbps)
(Mbps)
------------------------------------------------------------------------------system
Up Up
to-PE2
1
1
1000
0
Up Up
------------------------------------------------------------------------------Interfaces : 2
===============================================================================
Module 1 Page 63
*A:PE-1# configure router mpls

*A:PE-1>config>router>mpls$ interface "system"
*A:PE-1>config>router>mpls>if$ back
*A:PE-1>config>router>mpls$ interface "to-PE2"
*A:PE-1>config>router>mpls>if$ back
*A:PE-1>config>router>mpls# no shutdown
A:PE-1# configure router rsvp no shutdown
Enable LDP for Targeted-LDP
If LDP is not enabled, the SDPs that are configured in the next step will not
become operational
T-LDP is enabled by default when LDP is enabled
*A:PE-1# configure router ldp no shutdown
===============================================================================
LDP Status for LSR ID 10.10.10.1
===============================================================================
Admin State
: Up
Oper State
: Up
Created at
: 01/30/2012 17:24:48 Up Time
: 0d 00:00:21
Oper Down Reason
: n/a
Oper Down Events
: 2
Last Change
: 02/01/2012 10:32:12 Tunn Down Damp Time : 3 sec
Module 1 |
64
LDP is disabled by default. If LDP is not enabled, the SDPs that are configured in the next step will not
become operational. When configuring SDPs, you are essentially setting up targeted-LDP sessions. The
LDP must be enabled on any PE participating in the service. One exception to that is when signaling is
intentionally disabled (static label mappings), but that is not a routine case. Another reason to shutdown
signaling may be if the network is only used for VPRN (which will be discussed later), as T-LDP is not
used in VPRN.
Module 1 Page 64
*A:PE-1# show router ldp status
MPLS Path and LSP Creation

A path must be defined in order to create the LSP
*A:PE-1>config>router>mpls# path loose

*A:PE-1>config>router>mpls>path$ no shutdown
*A:PE-1>config>router>mpls>path$ back
*A:PE-1>config>router>mpls# lsp to-PE2
*A:PE-1>config>router>mpls>lsp$ to 10.10.10.2
*A:PE-1>config>router>mpls>lsp$ primary "loose"
*A:PE-1>config>router>mpls>lsp# no shutdown
*A:PE-1# show router mpls lsp

===============================================================================
MPLS LSPs (Originating)
===============================================================================
LSP Name
To
Fastfail
Adm
Opr
Config
------------------------------------------------------------------------------to-PE2
10.10.10.2
No
Up
Up
------------------------------------------------------------------------------LSPs : 1
Module 1 |
65
A path can be created explicitly or dynamically. If explicit, the path can be loose or strict.
An LSP must be configured to use a specific predefined path. The path can be either a primary path or a
secondary path. Any number of secondary paths may be defined. If a primary path, once defined, goes
down, the secondary path will be used to reach the destination LSR. However, if the primary path is
inaccessible and no secondary path has been identified, then the LSP fails.
Note: a secondary path may be defined without a primary path. The LSP will use the secondary path in
absence of a primary path. One difference between a primary path and a secondary path is that once a
primary path becomes available, the router will ignore the secondary path in favor of the primary path.
However, the router will not ignore a secondary path in favor of another secondary path. Another
difference between a primary path and a secondary path is that a secondary path cannot have fast reroute
enabled.
Module 1 Page 65
The LSP must be configured to use an existing path
Each SDP represents a method for reaching a service edge router
Encapsulation methods include GRE and MPLS
SDPs are created and then bound to services
Many services can be bound to a single SDP
VC labels are created when a service is bound to an SDP

*A:PE# configure service sdp
- no sdp <sdp-id>
- sdp <sdp-id> [gre|mpls] [create]
<sdp-id>
<gre|mpls>
<create>
[no] ldp
[no] lsp
: [1..17407]
: keywords - specify delivery mechanism
: keyword - mandatory while creating an entry.
- Enable/disable LDP-signaled LSP's
- Configure LSP to be used by SDP
Module 1 |
66
If you do not specify GRE or MPLS, the default encapsulation type is GRE.
Note: the tunnel is created when you specify the far-end IP address. In essence, you are creating the path
from Point A to Point B. When you configure a distributed service, you must identify a SDP ID.
Use the show service sdp command to display the qualifying SDPs.
Note: when specifying MPLS SDP parameters, you can only either specify an LSP or enable an LDP.
There cannot be two methods of transport in a single SDP. If an LSP name is specified then RSVP is used
for dynamic signaling within the LSP.
Module 1 Page 66
Configuring an SDP
*A:PE-1# configure service sdp 2 mpls create

*A:PE-1>config>service>sdp$ far-end 10.10.10.2
*A:PE-1>config>service>sdp$ lsp "to-PE2"
*A:PE-1>config>service>sdp$ no shutdown
*A:PE-1>config>service>sdp$ exit all
*A:PE-1# show service sdp
==============================================================================
Services: Service Destination Points
==============================================================================
SdpId
Adm MTU Opr MTU IP address
Adm Opr
Deliver
Signal
-----------------------------------------------------------------------------2
0
1556
10.10.10.2
Up
Up
MPLS
TLDP
-----------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------
Module 1 |
67
Configuring SDPs
Configuration involves creating, deleting or editing an SDP. An SDP is a logical mechanism that directs
traffic from one router to another through a unidirectional service tunnel. Each SDP represents a method
for reaching a service edge router.
An IP generic router encapsulation (GRE) tunnel is one type of tunnel encapsulation. GRE does not
specify a specific path to the service edge router. A GRE-based SDP uses the underlying IGP routing
table to find the best next hop to the far-end service edge router.
Another type of tunnel uses multiprotocol label switching (MPLS) encapsulation. A service supports both
signaled (LDP or RSVP-TE) and non-signaled label switched paths (LSPs) through the network. Nonsignaled static paths are defined at each hop through the network, while signaled paths are
communicated through protocol from end-to-end using resource reservation protocol (RSVP). Paths may
be manually configured or dynamically derived using the constrained shortest path first (CSPF) algorithm
and data from OSPF-TE or ISIS-TE traffic engineering databases (TED).
SDPs are created and bound to services, and many services may be bound to a single SDP. The
operational and administrative state of the SDP controls the state of the SDP binding to the service.
Module 1 Page 67
Creating an SDP and Binding the SDP to LSP
Building the Configuration
*A:PE-1>config>router>mpls# path loose

*A:PE-1>config>router>mpls>path$ no shutdown
*A:PE-1>config>router>mpls>path$ back
*A:PE-1>config>router>mpls# lsp to-PE2
*A:PE-1>config>router>mpls>lsp$ to 10.10.10.2
*A:PE-1>config>router>mpls>lsp$ primary "loose"
*A:PE-1>config>router>mpls>lsp# no shutdown
*A:PE-1# configure service sdp 2 mpls create

*A:PE-1>config>service>sdp$ far-end 10.10.10.2
*A:PE-1>config>service>sdp$ lsp "to-PE2"
*A:PE-1>config>service>sdp$ no shutdown
*A:PE-1>config>service>sdp$ exit all
Module 1 |
68
Module 1 Page 68
Customer-Facing Port Configuration

The CE devices are configured with IP interfaces that use VLAN tag 50
*A:CE-1# configure port 1/1/3

*A:CE-1> config>port# shutdown
*A:CE-1>config>port# ethernet encap-type dot1q
*A:CE-1>config>port# no shutdown
*A:CE-1# configure router

*A:CE-1>config>router>if#

*A:PE-1> config>port# shutdown
*A:PE-1>config>port# ethernet mode access
*A:PE-1>config>port# ethernet encap-type dot1q
*A:PE-1>config>port# no shutdown
interface "to-CE2"
address 192.168.2.1/27
port 1/1/3:50
no shutdown
exit all
Module 1 |
69
Module 1 Page 69
Service Configuration
Configure the service type with a customer ID
Define the SAP
Associate an SDP for distributed services
Enable the service
Module 1 |
70
Configuration Tasks:
Module 1 Page 70
Once the service infrastructure has been configured, the distributed service
can be provisioned
The configuration of an epipe is shown below:
*A:PE-1# configure service customer 100 create

*A:PE-1>config>service>cust$ exit
*A:PE-1>config>service>epipe$ sap 1/1/3:50 create
*A:PE-1>config>service>epipe>sap$ back
*A:PE-1>config>service>epipe# spoke-sdp 2:50 create
*A:PE-1>config>service>epipe>spoke-sdp$ back
*A:PE-1>config>service>epipe# no shutdown
Module 1 |
71
Once the service infrastructure has been configured, the distributed service can be provisioned.
Configuration of a distributed service is very similar to the local service. The difference is that an SDP
binding is required to signal the service labels and define the transport to the remote router. On the 7750
SR, the SDP binding is defined as a spoke or mesh binding. Mesh bindings are used only for VPLS
services. The difference between the two is described later in the course.
The SDP binding specifies both the SDP ID and the VC ID in the format spoke-sdp sdp-id:vc-id. This
identifies the transport tunnel and service tunnel for the pseudowire that is signaled by T-LDP.
Module 1 Page 71
Service Configuration (continued)
Service Verification
Once the service is configured on the remote router with a matching VC ID,
a service label is signaled and the service is up as shown below:
===============================================================================
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 100
Last Mgmt Change : 01/31/2012 21:05:55
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/3:50
q-tag
1518
1518
Up
Up
sdp:2:50 S(10.10.10.2)
Spok
0
1556
Up
Up
===============================================================================
Module 1 |
72
A pseudowire is bidirectional and is not operational until both ends are successfully signaled.
Module 1 Page 72
Service Verification (continued)

A service label is signaled and the CE routers can connect to each other
through the epipe
*A:PE-1# show router ldp bindings fec-type services
===============================================================================
LDP LSR ID: 10.10.10.1
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending, C - Cpipe Service
TLV - (Type, Length: Value)
===============================================================================
LDP Service FEC 128 Bindings
===============================================================================
Type
VCId
SvcId
SDPId Peer
IngLbl EgrLbl LMTU RMTU
------------------------------------------------------------------------------E-Eth 50
50
2
10.10.10.2
131068U 131068S 1500 1500
------------------------------------------------------------------------------No. of VC Labels: 1
*A:CE-1# ping 192.168.2.2
64 bytes from 192.168.2.1: icmp_seq=1
ttl=64
ttl=64
ttl=64
ttl=64
ttl=64
time=5.35ms.
time=2.20ms.
time=2.26ms.
time=2.19ms.
time=2.25ms.
Module 1 |
73
Configuration of a distributed service is very similar to the local service. The difference is that an SDP
binding is required to signal the service labels and define the transport to the remote router. On the 7750
SR, the SDP binding is defined as a spoke or mesh binding. Mesh bindings are used only for VPLS
services. The difference between the two is described later in the course.
The SDP binding specifies both the SDP ID and the VC ID in the format spoke sdp sdp-id:vc-id. This
identifies the transport tunnel and service tunnel for the pseudowire that is signaled by T-LDP.
A pseudowire is bidirectional and is not operational until both ends are successfully signaled.
Module 1 Page 73
Service Components Summary

Customers (Subscribers)
The customer ID must be associated with the service at the time of
service creation
Service Type

This is the logical entity that serves as the customers access to the
service
Service Distribution Points (SDPs)
A method by which a service will connect to the service on another
router
Describes the transport tunnel encapsulation that this service will be
using, such as MPLS/RSVP-TE, MPLS/LDP or IP/GRE
Module 1 |
74
To provision a service on an Alcatel-Lucent router, you must configure the following:

Service you must define the type of service required.
Service Access Point (SAP) this is a logical entity that serves as the customer access to the
service.
For a remote VPN you must identify the following:
Service Distribution Points (SDP) An SDP identifies the other router(s) a service is associated
with. The SDP also identifies the tunnel encapsulation used by the service tunnel, such as MPLS,
or GRE.
Auto-Bind (VPRN only) This feature is used with MPLS/LDP tunnels and automatically
provisions the tunnels.
Module 1 Page 74
VPRN, VPLS, VPWS or IES
Module Summary
SAPs, services and SDPs work together to provide logical service-level

connectivity
SDPs provide links to service tunnels, which are provisioned with a set
encapsulation type of either MPLS or GRE
SDPs provide the T-LDP session
Matching VC IDs are used to signal the service labels

SAPs can only be configured on access ports, while SDPs can only be
created on network ports
Although many of the service component identifiers have local
significance, the VC ID has point-to-point significance and must be unique
Module 1 |
75
Module 1 Page 75
Module Summary (continued)

VPWS is a point-to-point pseudowire established through a packet-switched
network
VPLS is a logical grouping of pseudowires with MAC learning and allows the
interconnection of several LAN segments across a packet-switched network
Alcatel-Lucent 7750 SR supports epipe, apipe, cpipe, fpipe and ipipe services
Both VPWS and VPLS can be defined as either local services or distributed
services
A SAP is where traffic enters and exits the service in relation to the customer
sites
A service is a globally unique, logical entity that provides connectivity
between SAPs; a service also provides a uniform, end-to-end configuration,
management and billing model for Layer 2 or Layer 3 service provisioning
Module 1 |
76
Module 1 Page 76

When a service spans more than one router, it uses SDPs to direct traffic
to another router; traffic is transported by a transport tunnel through a
service tunnel
To provision a service, you must configure the following: customer,
service type, SAP and SDP
The following are transport tunnel encapsulation options: MPLS/RSVPTE, MPLS/LDP or IP/GRE
To provision a service, a customer ID must be associated with the
service when it is created
The following are SAP identifiers: physical Ethernet port or POS port and
channel, encapsulation type and encapsulation identifier
SDPs are locally unique and normally use the system IP address to
identify far-end destinations
Module 1 |
77
Module 1 Page 77
SDP is not specific to one service; many services can use the same SDP
A service label is used to distinguish between multiple services that use

the same SDP
VPLS and VPWS service labels are signaled using T-LDP
VPRN service label is signaled by MP-BGP based on RFC 4364
An SAP is associated with a single service and can only be configured on

an access port
Module 1 |
78
Module 1 Page 78

A SAP can be configured with filters, QoS, scheduling and accounting
policies
SAPs cannot be created on ports designated as network ports
Before you can provision services, you must do the following:
Configure IGP routing protocols
Build the IP/MPLS core network

Configure MPLS LSPs
Construct the core SDP service-tunnel for the services
Module 1 |
79
Module 1 Page 79
Learning Assessment
1. List three advantages of VPWS from the customers perspective.
2. Which VPWS services are currently supported by Alcatel-Lucent?
3. Is the following statement true or false? Epipe service does not perform any
MAC learning.
5. How many SDPs in total need to be configured on a local epipe service?

6. Verify whether the following statement is true or false? A service ID must
always be equal to the VC ID.
Module 1 |
80
1. List three advantages of VPWS from the customers perspective

Support ATM, Frame Relay, TDM or Ethernet
Service provider (SP) network appears as a leased line between the two customer locations
Transparent to customer data
2. Which VPWS services are currently supported by Alcatel-Lucent?

epipe, apipe, fpipe, ipipe, and cpipe
3. Verify whether the following statement is true or false: Epipe service does not perform any MAC
learning.
True
4. Verify whether the following statement is true or false: SAPs can be created on either access ports or
network ports.
False. SAPs must be created on access ports
5. In total, how many SDPs need to be created on a local epipe service?
None. A local service only needs SAPs. SDPs are used for distributed services.
6. Verify whether the following statement is true or false: A service ID must always be equal to the VC ID.
False. It is recommended to use the same service ID as VC ID, but not required.
Module 1 Page 80
4. Verify whether the following statement is true or false: SAPs can be

created on either access ports or network ports.
Learning Assessment (continued)

7. Based on best practice, place the correct letter on each line:
SAP ID
______
a. Local significance
SDP ID
______
b. Global significance
VC ID
______
c. Point-to-point significance
Customer ID ______
8.
Fill in the blank: A SAP can only be configured on a port which has been
configured as an ____________ port.
9.
Fill in the blank: The default configuration for a port is ______.
10. Verify whether the following statement is true or false: Service tunnels
are unidirectional.
11. Verify whether the following statement is true or false: A SAP can never
be associated with more than one service.
Module 1 |
81
7. Based on best practice, place the correct letter on each line:

SAP ID
SDP ID
VC ID
Service ID
Customer ID
8. Fill in the blank: A SAP can only be configured on a port which has been configured as an access port.
9. Fill in the blank: The default configuration for a port is network.
10.Verify whether the following statement is true or false: Service tunnels are unidirectional.
True
11. Verify whether the following statement is true or false: A SAP can never be associated with more than
one service.
True
Module 1 Page 81
Service ID ______
Lab 1 Lab infrastructure and IGP Configuration
In this lab you will:
Verify preconfigured IP addressing and physical operation
Configure IGP routing and LDP for the service provider network
Module 1 |
82
Module 1 Page 82
www.alcatel-lucent.com/src
3FL-30636-AAAA-ZZZZA Edition 01
Module 2 Virtual Private Wire Services
Module 2 Page 1
Module Objectives
Examine the details of E-pipe configuration and verification
Recognize the interworking capabilities of the different VPWS
Module 2 |
This module defines and identifies the VPWS services implemented by Alcatel-Lucent. In this module, you
will be introduced to the process used by Alcatel-Lucent in the implementation of VPWS, including epipe,
apipe, fpipe and cpipe services. This module provides information on these Layer 2 point-to-point services
and how customer data is encapsulated and transported across a service providers IP or MPLS network.
Epipe, apipe, fpipe and cpipe are identified as completely transparent to the subscribers data and
protocols.
Module 2 Page 2
Describe the other VPWS types available (apipe, fpipe, cpipe,

ipipe)
Section 1 Epipe
Module 2 Page 3
Section Objectives
Define the different types of VPWS available
Describe the different types of Ethernet SAP encapsulation (null,

dot1q, qinq) and the concept of VLAN tag
Differentiate between the supported SAP values (default, null, etc)
Explain the use of Ethertype value in identifying tagged frames
Identify the types of MTUs to be considered when designing a layer 2
service (SAP MTU, Service and VC MTU, SDP MTU, network port MTU)
Module 2 |
Module 2 Page 4
Section Objectives (continued)
Explain the relationship between the different types of MTUs

Describe the difference between VC-types for epipe: tagged mode
(VLAN) versus raw mode (Ether)
Identify the different possible combination of frame transmission for

null, dot1q, and qinq encapsulation SAP with different egress
encapsulation
Configure and verify a distributed epipe service
Module 2 |
Module 2 Page 5
Epipe SAP Encapsulation

SAP encapsulation provides the router with a way of delineating
services
Ethernet encapsulation
Dot1Q(802.1q) supports multiple services for a single customer or
multiple services for multiple customers
Q-in-Q provides a way to differentiate between customer
services based on Q-tags
Module 2 |
SAP encapsulation provides the router with a way of delineating services. Null means that there is only
one service on the port; the other encapsulations, such as dot1Q and Q-in-Q, indicate that there can be
multiple services on that port.
Ethernet Encapsulation
The following are three encapsulation types that are supported on Ethernet access ports:
Null supports a single service on the port and is used in situations where there is a single customer
edge (CE) device connected to the port. The encapsulation identifier (ID) is set to zero.
Dot1Q a single Q-tag (Qtag1) is used to delineate customer services. This tag can have a value
anywhere from 0 to 4096. All tags are local in relation to the port where the SAP is bound.
Q-in-Q up to two Qtags (Qtag1 and Qtag2) are used to delineate customer services. Each tag can
have a value anywhere from 0 to 4096. All tags are either local to the port where the SAP is bound, or the
inner label can be transported intact to the destination if the router is configured to do so.
Module 2 Page 6
Null supports a single service on a port
Encapsulation type
VLAN tags
SAP syntax
null
port
Example - Port 1/1/1
dot1q
port:tag
Example - port 1/1/1:10
qinq
port:outer-tag.inner-tag
Example - port 1/1/1:10.100
VLAN tag is used to determine which service the frame belongs to
Multiple SAPs can be defined on a single port for different services
Module 2 |
The Alcatel-Lucent 7750 SR implementation of an epipe is based on RFC 4448 (Encapsulation Methods
for Transport of Ethernet over MPLS Networks).
IEEE 802.1Q, or VLAN Tagging, is a networking standard written by the IEEE 802.1 workgroup. It allows
multiple-bridged networks to transparently share the same physical network link without leakage
of information between networks. IEEE 802.1Q also known as dot1q is commonly used to refer to
the encapsulation protocol used to implement this mechanism over Ethernet networks.
When a VLAN tag is specified as part of the encapsulation, it is considered to be service delimiting. This
means that the VLAN tag is used to determine which service the frame belongs to. For example, if a SAP
is created in a service as 1/1/1:10, all frames arriving at port 1/1/1 with VLAN tag 10 belong to the service.
All other frames do not.
Using service delimiting VLAN tags, multiple SAPs can be defined on a single port for different services.
Module 2 Page 7
Epipe SAP Encapsulation (continued)
Epipe SAP Encapsulation (continued)

Null
Service is delimited by the port (SAP 1/1/1)
The physical port belongs to a single service and a single customer
Tags are treated as customer data and are transparent on the network
Service is delimited by the VLAN tag (SAP 1/1/1:10)

Allows more than one SAP to be configured on each physical port
Q-in-Q:
Service is delimited by two VLAN tags as port:outer.inner (SAP
1/1/1:10.100)
Can specify a top and bottom VLAN ID to be matched
Module 2 |
Ethernet SAPs can be configured as null, dot1q, or q-in-q.

Null encapsulation is the default for all Ethernet ports. The physical port must be configured with the
correct encapsulation in order to bind a null SAP, dot1Q SAP or Q-in-Q SAP to the port.
If null encapsulation is specified for an access port and SAP, the SAP will accept all frames received on
the port whether they are untagged, dot1Q tagged or Q-in-Q tagged. They will be treated as any Ethernet
frame and transmitted with the VLAN tag transparently preserved across the service.
With dot1Q and Q-in-Q SAPs, VLAN tags have local significance.
Q-in-Q encapsulation works in a very similar manner to dot1Q encapsulation, except that two VLAN tag
values are specified in the SAP as port:outer.inner, where outer is the outer (sometimes known as
provider) VLAN tag and inner is the inner (sometimes known as customer) VLAN tag.
*A:PE-1# configure service epipe <service-id>
sap
- no sap <sap-id>
- sap <sap-id> [create] [no-endpoint]
- sap <sap-id> [create] endpoint <endpoint-name>
<sap-id>
: null
- <port-id|bundle-id|bpgrp-id|lag-id|aps-id>
dot1q
- <port-id|bundle-id|bpgrp-id|lag-id|aps-
qinq
- <port-id|bundle-id|bpgrp-id|lag-
id>:qtag1
id>:qtag1.qtag2
Module 2 Page 8
Dot1Q
Ethernet Frame Encapsulation in an Epipe Service
On the 7750 SR, VLAN tags are stripped at the SAP ingress by default
Module 2 |
When service delimiting VLAN tags are used on the 7750 SR, they are stripped at the SAP ingress by
default. The FCS for the frame is also removed. All other fields of the customers frame are maintained.
The figure in the slide shows the encapsulation of data on the provider network as it is transmitted across
the epipe service. An Ethernet frame arrives at PE1. It has a VLAN tag with a value of 50. The VLAN tag
identifies the service that is intended to handle the frame and is stripped from the frame by router PE1
along with the FCS field. The rest of the frame, (header and data) is encapsulated with two MPLS labels.
This frame is then encapsulated in a Layer 2 frame for transmission to the next hop. The FCS in this case
is for the entire frame carrying the MPLS encapsulated data.
When the frame reaches the egress PE router (PE2), the MPLS labels are popped and the untagged
frame is transmitted on the SAP interface. A VLAN tag is added to the frame, depending on the
encapsulation ID on the SAP. In this example, the SAP on PE2 is 1/1/4:100, so the VLAN tag added to the
customer frame is 100.
Module 2 Page 9
The FCS for the frame is also removed
Special SAP Values - dot1q

Default SAP (port:*)
Receives all untagged frames and any frames with tag values that are
not used as a service-delimiting value on another SAP
VLAN tags are not stripped and are passed transparently
Null SAP (port:0)

Receives all untagged frames and all frames with a VLAN tag of 0
Example sap 1/1/3:0
Null SAP and default SAP are mutually exclusive on a port
Module 2 |
10
VLAN tags do not have to be service delimiting and can be passed transparently. Similar to the behavior in
null encapsulation, in a case where a SAP is defined as a dot1Q service, delimiting SAP and a Q-in-Q
frame is received at the port. If the outer tag matches the value in the SAP, it will be stripped and the
frame transmitted over the service with the inner tag transparently maintained. If the outer tag does not
match the SAP value, the frame is ignored by the service.
The default SAP can be used in a situation where it is desired to pass all customer VLAN tagged frames
transparently, but capture some specific traffic for another purpose.
The null SAP is used when it is desirable to capture untagged traffic in another service. Use of the null
SAP and default SAP are mutually exclusive on a port - if one is defined in a service the other cannot be
used.
Module 2 Page 10
Example sap 1/1/3:*
Ethernet Frame Encapsulation - Default (port:*) SAP Example
VLAN tags are not stripped and are passed transparently on a default SAP
Module 2 |
11
The figure in the slide shows the encapsulation of data on the provider network as it is transmitted across
the epipe service. One Ethernet frame that has a VLAN tag value of 50 arrives at PE1. Since the
encapsulation on the SAP is default dot1q (1/1/4:*), the VLAN tag will not be stripped and will pass
transparently. The frame (header, VLAN tag, and data) is encapsulated with two MPLS labels. This frame
is then encapsulated in a Layer 2 frame for transmission to the next hop. When the frame reaches the
egress PE router (PE2), the MPLS labels are popped and the tagged frame is transmitted on the SAP
interface. Again, the SAP encapsulation is default dot1q, therefore the VLAN tag (50) is passed
transparently.
Another Ethernet frame that is untagged arrives at PE1. Since the encapsulation on the SAP is default
dot1q (1/1/4:*), the frame is accepted and will be encapsulated with two MPLS labels. This frame is then
encapsulated in a Layer 2 frame for transmission to the next hop. When the frame reaches the egress PE
router (PE2), the MPLS labels are popped and the untagged frame is transmitted on the SAP interface.
Again, the SAP encapsulation is default dot1q, therefore no VLAN tags will be added to the frame.
Module 2 Page 11
Special SAP Values Q-in-Q

Wildcard SAP (port:x.*)
Receives all frames with outer tag value x regardless of the inner tag
The outer tag is stripped and the inner tag is passed transparently
Example sap 1/1/3:10.*
Receives all untagged frames and/or any frames with a VLAN tag of 0
Example sap 1/1/3:0.*
Null bottom SAP (port:x.0)
Receives all frames with outer tag value x and inner tag of 0 or no
bottom tag
Example sap 1/1/3:10.0
An encapsulation of (port:*.* or Port:*.x) is not valid on the 7750 SR
Module 2 |
12
For Q-in-Q encapsulated SAPs there is no default SAP. An encapsulation of port:*.* is not valid on the
7750 SR so there is no way to capture all combinations of Q-in-Q tagged frames, except to configure the
port for null or dot1Q encapsulation and use the dot1Q default SAP.
Wildcard SAP - SAP 1/1/3:10.* Will only match 10 as the top Q tag and may have any bottom tag or
no bottom tag at all.
Null SAP - SAP 1/1/3:0.* - Will allow any untagged frames and/or frames with an outer tag of 0 only.
If the outer tag is 10,for example, the frame will be dropped. However, if the outer tag is 0 and the inner
tag is 10, then the frame will not be dropped.
Null bottom SAP - SAP 1/1/3:10.0 Will only match 10 as the top Q tag and may have a bottom tag of 0
or no bottom tag at all.
Module 2 Page 12
Null SAP (port:0.*)
Ethernet Frame Encapsulation - Null SAP (port:0.*) Example
Null SAP will pass untagged frames, frames with one VLAN tag of 0, or
double-tags where the outer VLAN tag is 0
Module 2 |
13
A VLAN tag received on a SAP port is considered service delimiting if it matches the encapsulation on the
SAP port. The figure in the slide shows the encapsulation of data on the customer network as it is
transmitted across the epipe service. Three frames arrive at a null SAP on PE1.
The first Ethernet frame is untagged; null SAP will accept the frame and the frame (header, data) is
encapsulated with two MPLS labels. This frame is then encapsulated in a Layer 2 frame for transmission
to the next hop. When the frame reaches the egress PE router (PE2), the MPLS labels are popped and
the untagged frame is transmitted on the SAP interface. The SAP encapsulation on PE2 is null, therefore
no tags are added and the frame is passed transparently.
The second frame has an outer VLAN tag of 0, and no inner VLAN tag. SAP 1/1/4:0.* will accept the frame
and service delimiting tag of 0 is stripped before the frame is encapsulated with the two MPLS labels. On
PE2 the frame will be passed transparently as in the first case.
The third frame has an outer tag of 0 and an inner tag of 10. The null SAP 1/1/4:0.* will accept the frame,
the service outer tag is stripped and the inner tag (10) is passed transparently. The frame (header, VLAN
tag 10, and data) will be encapsulated with the two MPLS labels. When the tagged frame reaches the PE2, the MPLS labels are popped and the tagged frame is transmitted on the null SAP interface. No other
VLAN tags will be added to the frame.
Module 2 Page 13
Ethertype Values
IEEE 802.1Q specifies a hex value of 0x8100 to be used in the Ethertype
field to indentify the frame as a tagged frame
On the 7750 SR, Ethertype can be configured as follows:
*A:PE-1>config>port# ethernet dot1q-etype ?
- no dot1q-etype
<0x0600..0xffff>
: [1536..65535] - accepts in decimal or hex
For multivendor interoperability, frames with non-matching Ethertypes are

treated as untagged
Module 2 |
14
IEEE 802.1Q specifies a hex value of 0x8100 to be used in the Ethertype field to indentify the frame as a
tagged frame. This value is also used for the Ethertype value in the inner VLAN tag for Q-in-Q
encapsulation. However, some older switches use proprietary Ethertype values to identify the VLAN tag. If
the 7750 SR in its default configuration receives a tagged frame with an Ethertype value other than
0x8100, it is simply treated as an untagged frame.
It is possible to configure the port on the 7750 SR to use a different Ethertype value to identify tagged
frames. A different value can be specified for either the outer tag (dot1Q Ethertype) or the inner tag (Q-inQ Ethertype), or both.
When the Ethertype value is changed, any frame with an Ethertype that does not match the configured
value is treated as an untagged frame.
Module 2 Page 14
- dot1q-etype <0x0600..0xffff>
Maximum Transmission Unit (MTU)

MTU is an important issue in both Layer 2 and Layer 3 services
For an IP/MPLS network, the following MTU entities must be
considered:
Access port, or SAP MTU
SDP path MTU
Network port MTU
Oversized frames arriving at a Layer 2 interface are not fragmented
Layer 3 services will fragment oversized packets for transmission
Module 2 |
15
A fundamental characteristic of any Layer 2 technology is its MTU. When the pseudowire is established
with T-LDP signaling, an MTU is negotiated that must match at each end of the service.
In designing an IP/MPLS network, there are a number of entities where MTU must be considered. These
are:
Access port, or SAP MTU
Service MTU
SDP path MTU
Network port MTU
MTU is an important consideration in a Layer 2 service since oversized frames arriving at a Layer 2
interface are not fragmented, but simply discarded.
A Layer 3 service, such as a VPRN, will fragment oversized packets for transmission; however, this is an
expensive operation and generally undesirable. Thus MTU is an important issue in both Layer 2 and Layer
3 services.
Module 2 Page 15
Service and VC MTU
SAP and Service MTU

Service MTU defines the maximum customer payload that can be carried in
service
The default service MTU for an Ethernet VPN service is 1514 bytes = 1500
bytes (payload) + 14 bytes DLC header
The SAP MTU must be >= service MTU to be operationally up
A Q-in-Q encapsulated SAP has a default MTU of 1522
When the VLAN tags are service delimiting, they are stripped at the SAP
Module 2 |
16
An Ethernet VPN service, such as an epipe or VPLS service, has a default service MTU of 1514 bytes.
This is the size required to carry a standard Ethernet frame - a 1500 byte payload and a 14 byte Data Link
Control (DLC) header with no FCS.
Layer 2 technologies do not support fragmentation. If an oversized frame is received at an Ethernet
interface, it is discarded. The router will compare the service MTU to the SAP MTU (port MTU) to ensure
that frames offered to SAPs from the service will not be discarded. If the SAP MTU is too small, the router
will signal the SAP to the operationally down state.
The service MTU also serves to limit the size of payload the service can process before discarding and
fragmenting for Layer 2 and Layer 3 services, respectively.
In a Layer 2 service, the SAP MTU must always be equal to or larger than the service MTU. Of course, if
the SAP MTU is larger than the service MTU, there is the risk that a frame will be dropped at ingress to
the service. SAP MTU is changed by changing the port MTU.
A dot1q encapsulated SAP has a default MTU of 1518, and the VLAN tag is removed before transmitting.
A Q-in-Q encapsulated SAP has a default MTU of 1522, and both VLAN tags are removed before
transmitting.
When using default values, the service MTU and SAP MTU are set to the appropriate values for a full-size
Ethernet frame.
Module 2 Page 16
A dot1q encapsulated SAP has a default MTU of 1518
SAP and Service MTU (continued)

When the VLAN tags are not service delimiting, they are not stripped
at the SAP (for example: a default dot1Q SAP)
Module 2 |
17
MTU problems arise when we have a configuration different from the regular default configuration. For
example, in a default dot1Q SAP, VLAN tags are not stripped at the SAP since they are not service
delimiting. The diagram shows a default dot1Q SAP for an epipe service.
The default SAP will accept a full-size frame of 1518 bytes (1500 byte payload), but since the VLAN tag is
not stripped from the customer frame, the service payload is 1518 bytes. A frame of this size exceeds the
service MTU of 1514 and the frame is dropped. Therefore, to carry a full-size Ethernet frame for the
default dot1Q SAP, we need a service MTU of 1518. to configure the service for this larger MTU, the
command PE1 # config>service>epipe# service-mtu 1518 is used. When increasing the service MTU
we must also consider the SDP path MTU which is discussed in the following slides.
A null encapsulated SAP behaves in the same manner as a dot1Q default SAP and has the same issue if
it receives VLAN tagged frames.
To configure a service MTU the command is
configure service <service type> <service id> service-mtu <octets>
<octets>
: [1..9194]
Module 2 Page 17
SAP MTU is changed by changing the port MTU
VC-MTU
Layer 2 services: service MTU is configured
VC-MTU = configured service MTU 14 (DLC header)
Layer 3 services: service MTU is not configured

VC-MTU of Layer 3 service interface can be configured by configuring the IP-MTU
parameter under the service
If the SDP path MTU is not configured, the SDP path MTU and the VC-MTU are
derived from the network port MTU
SDP path MTU = network port MTU 4 (transport label) 4 (VC-label)
port encapsulation (14 in case of null encapsulation, 18 in case of
Dot1Q...)
VC-MTU = network port MTU 4 (transport label) 4 (VC-label) 14
(port encapsulation in case of null ..) 14 Ethernet overhead
Module 2 |
18
The VC-MTU is derived from the configured service MTU (VC-MTU = configured service MTU 14
(Ethernet overhead, FCS not counted)). By default, epipe and VPLS services are configured with a service
MTU of 1514. By default, the signaled VC-MTU is 1500.
Layer 3 services have no service MTU configured. By default, there is also no SDP path MTU configured.
Whereas in Epipe and VPLS services the signaled VC-MTU = configured service-mtu 14 (ethernet), in
the case of a Layer 3 service, the signaled VC-MTU = configured IP-MTU.
VC-MTU of a Layer 3 interface can be configured by configuring the IP-MTU parameter under the Layer 3
service.
PE>config>service>vprn# interface toCustomerVPRN ip-mtu
- ip-mtu <octets>
- no ip-mtu
<octets>
: [512..9000]
Module 2 Page 18
VC-MTU = configured SDP path MTU 14 (DLC header)
SDP Path and Network Port MTU

The SDP path MTU defines the maximum payload size that can be
carried in the SDP transport tunnel
Network port MTU >= SDP path MTU + transport tunnel encapsulation
overhead
Service MTU <= Access port MTU
Module 2 |
19
The diagram in the slide shows the relationship between network port, path, service and access port MTU.
The default value for the SDP path MTU on the 7750 SR is calculated on the ingress PE router by
subtracting the encapsulation overhead of the transport tunnel from the egress network port MTU.
Many different services may be bound to the same SDP. These services may have different service
MTUs, but they can never exceed the SDP path MTU.
Note: if the access port MTU is larger than the service MTU there is the risk that a frame will be dropped
at ingress to the service. Best practice is to keep the network MTU (and hence SDP MTU) to largest
possible values to accommodate many services then, if required, change the service specific MTU with
the service MTU setting in Layer 2 and ip-MTU in Layer 3.
Module 2 Page 19
SDP path MTU >= Service MTU
Example of SDP Path and Network Port MTU

For a gigabit Ethernet network port with an MTU of 9212 (default on
the 7750 SR)
If SDP uses MPLS encapsulation
If SDP uses GRE encapsulation

SDP path MTU = 9212 (network port MTU) 14 (Ethernet header) - 4
(GRE header) 20 ( IP header) 4 (service label) = 9170 bytes
Module 2 |
20
As an example, assume the SDP network port is a gigabit Ethernet port with an MTU of 9212 (default on
the 7750 SR), and the SDP uses MPLS encapsulation. The encapsulation overhead of the transport tunnel
is 14 bytes for the Ethernet header plus 8 bytes for the two MPLS labels. Therefore, the default path MTU
for the SDP is 9212 - 22 = 9190 bytes
If an SDP is defined with GRE for the transport tunnel, it uses a GRE header (4 bytes) and an IP header
(20 bytes) instead of the 4 byte MPLS transport label. The encapsulation overhead for a GRE tunnel on
the same Ethernet interface is 14 bytes for Ethernet header plus 20 bytes for IP header plus 4 bytes for
GRE header plus 4 bytes for service label = 42 bytes. The SDP path MTU for a GRE-encapsulated SDP is
9212 - 42 = 9170 bytes.
When calculating the required network port MTU, you must also consider any other factors that increase
the encapsulation overhead. For example, facility backup or LDP over RSVP each require an additional
MPLS label. If both are used together on the same LSP, this is an additional eight bytes of encapsulation
overhead.
Module 2 Page 20
SDP path MTU = 9212 (network port MTU) 14 (Ethernet header )

8 ( two MPLS labels) = 9190 bytes
Physical MTU Default Values
Port Type
Mode
Encap Type
Default (Bytes)
Ethernet
access
null
1514
Ethernet
access
Dot1Q
1518
Ethernet
access
Q-in-Q
1522
Fast Ethernet
network
1514
Gigabit Ethernet
network
9212
Module 2 |
21
The default MTU value depends on the port or sub-port type, the
mode and the encapsulation, which are listed in the table below:
Module 2 Page 21
Configuring Path MTU

Configuring the network port MTU impacts all SDPs traversing the
port:
Configuring the SDP path MTU impacts a single SDP traversing any
port:
config>service>sdp# path-mtu
path mtu values can be: [1500..9194]
A useful command to determine the effective path MTU of an SDP is

oam sdp-mtu
Module 2 |
22
A tool that is useful in determining the effective path MTU of an SDP is the command oam sdp-mtu,
which transmits increasingly large packets on the SDP. The OAM commands are described in more detail
later in the course.
For GRE tunnels, this value is set by the administrator; it is assumed that reality matches the config.
For signaled MPLS tunnels, the path MTU can be determined by the signaling exchange. This is
accomplished using the adspec command, which is configured under the router mpls lsp context.
RSVP defines the adspec object that can be used in the path message to collect information about the
path at each router, including MTU information. If adspec is configured on the LSP used as the transport
for the SDP, the SDP path MTU is derived from the path MTU signaled in RSVP using the ADSPEC
object. Negotiated MTU for the LSP is set to the smallest MTU value found on the path. If the path of the
RSVP changes, the MTU will change to reflect MTU on the new path.
Module 2 Page 22
config>port slot/mda/port>ethernet># mtu <mtu-bytes>

mtu-bytes can be from [512..9212] bytes.
The core network is configured with OSPF as the routing protocol
The customer sites connect to the PE nodes using dot1Q Ethernet

encapsulation
The SDP between the PE routers uses RSVP-signaled LSPs for transport
Epipe service is configured between PE1 and PE2
Module 2 |
23
Epipe MTU Case Study
Module 2 Page 23
Epipe MTU Case Study Port Configuration
*A:PE-1>config>port# info
------------------------------ethernet
mode access
encap-type dot1q
exit
no shutdown
-------------------------------
*A:CE1# configure port 1/1/3

*A:CE1>config>port# info
------------------------------ethernet
encap-type dot1q
exit
no shutdown
-------------------------------
*A:PE-1# show port

===============================================================================
Ports on Slot 1
===============================================================================
Port
Admin Link Port
SFP/XFP/
Id
State
State
MDIMDX
------------------------------------------------------------------------------1/1/1
Down No
Down
9212 9212
- netw null gige
1/1/2
Down No
Down
9212 9212
- netw null gige
1/1/3
Up
Yes Up
9212 9212
- netw null gige
1/1/4
Up
Yes Up
1518 1518
- accs dotq gige
*A:P1# show port

===============================================================================
Ports on Slot 1
===============================================================================
Port
Admin Link Port
SFP/XFP/
Id
State
State
MDIMDX
------------------------------------------------------------------------------1/1/1
Down No
Down
9212 9212
- netw null gige
1/1/2
Down No
Down
9212 9212
- netw null gige
1/1/3
Up
Yes Up
9212 9212
- netw null gige
1/1/4
Up
Yes Up
9212 9212
- netw null gige
Module 2 |
24
The configuration of the customer-facing port on PE1 (port 1/1/4) is shown, similar configuration exists on
PE2 for port 1/1/4.
Note: the network port MTU value is 9212 for the gig Ethernet port.
Since the encapsulation type used is dot1q, the MTU value for the SAP is 1514 + 4 (VLAN tag) = 1518
The configuration of the customer port facing the PE router on CE1 (port 1/1/3) is shown, similar
configuration exists on CE2 for port 1/1/3.
Module 2 Page 24
Epipe MTU Case Study MPLS and SDP Configuration
*A:PE-1>config>service# sdp 2
*A:PE-1>config>service>sdp# info
--------------------------------------------far-end 10.10.10.2
lsp "to-PE2"
keep-alive
shutdown
exit
no shutdown
---------------------------------------------

==============================================================================
==============================================================================
SdpId
Adm Opr
Deliver
Signal
-----------------------------------------------------------------------------2
0
9190
10.10.10.2
Up
Up
MPLS
TLDP
-----------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------
Module 2 |
25
Since the SDP network port is a gigabit Ethernet port with an MTU of 9212 (default on the 7750 SR) and
the SDP uses MPLS encapsulation, the default path MTU for the SDP is 9212 14 (transport tunnel
encapsulation overhead) 8 ( two MPLS labels) = 9190 bytes.
The sdp keep-alive option enables SDP connectivity monitoring keep-alive messages for the SDP ID.
Default state is disabled (shutdown) in which case the operational state of the SDP-ID is not affected by
the keep-alive message state.
Module 2 Page 25
*A:PE-1>config>router>mpls# info
----------------------------------interface "system"
exit
interface "to-P1"
exit
path "loose"
no shutdown
exit
lsp "to-PE2"
to 10.10.10.2
primary "loose"
exit
no shutdown
exit
no shutdown
-----------------------------------
*A:PE-1>config>service# info
----------------------------------------
epipe 50 customer 100 create
sap 1/1/4:50 create
exit
spoke-sdp 2:50 create
exit
no shutdown
exit
-----------------------------------------

===============================================================================
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 100
Last Mgmt Change : 02/09/2012 15:09:34
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4:50
q-tag
1518
1518
Up
Up
sdp:2:50 S(10.10.10.2)
Spok
0
9190
Up
Up
===============================================================================
Module 2 |
26
Since the service delimiting VLAN tag is used on PE1 (dot1q encapsulation), it is stripped at the SAP
ingress by default. Therefore the service MTU for the epipe will be 1514 bytes = 1500 bytes (payload) +
14 bytes DLC.
When an Ethernet frame arrives at PE1, it has a VLAN tag with a value of 50. The VLAN tag is stripped
from the frame by router PE1 along with the FCS field. The rest of the frame, (header and data) is
encapsulated with two MPLS labels. This frame is then encapsulated in a Layer 2 frame for transmission
to the next hop.
When the frame reaches the egress PE router (PE2 in this case), the MPLS labels are popped and the
untagged frame is transmitted on the SAP interface. A VLAN tag is added to the frame, depending on the
encapsulation ID on the SAP. In this example, the SAP on PE2 is 1/1/4:50, so the VLAN tag added to the
customer frame is 50.
This show service id base command displays basic information about the service ID including service
type, description, SAPs and SDPs; it is a useful command to use when summary information about a
service is required.
Syntax id: service-id base
Context: show>service
Description: Display information for a particular service-id.
Parameters: service-id the unique service identification number that identifies the service in the service
domain. Information such as the service type, admin and operational states can be determined using this
command. In addition, all of the relevant SAPs and SDPs that are bound to a service are displayed.
Module 2 Page 26
Epipe MTU Case Study Service Configuration
*A:CE1# ping 192.168.1.2 size 1472 do-not-fragment count 2

---- 192.168.1.2 PING Statistics ---2 packets transmitted, 2 packets received, 0.00% packet loss
round-trip min = 4.80ms, avg = 4.90ms, max = 5.01ms, stddev
= 0.105ms

Request timed out. icmp_seq=1.
---- 192.168.1.2 PING Statistics ---2 packets transmitted, 0 packets received, 100% packet loss
Module 2 |
27
When using default values, the service MTU and SAP MTU are set to the appropriate values for a full-size
Ethernet frame. The ping commands with specific packet sizes shown demonstrate that.
The size value specifies the size of the ping packet, but does not include the 20 bytes of the IP header or
the 8 bytes of the ICMP header. Thus a 1500 byte IP packet is created with a ping value of 1500 - 20 - 8 =
1472.
Note: the ping of size 1473 is not transmitted through the service, because the frame size is now 1473 +
20 + 8 + 14 = 1515, which is larger than the service MTU of 1514. If the IP header do not fragment flag is
not set, the packet is fragmented into smaller packets that will not exceed the configured MTU size. If the
do not fragment bit is set (as in this case), the packet is silently discarded at egress when it exceeds the
IP MTU.
Module 2 Page 27
Epipe MTU Case Study SAP and Service MTU
*A:PE-1>config>service>epipe# info
-----------------------------------------service-mtu 1518
sap 1/1/4:50 create
exit
exit
no shutdown
------------------------------------------
-----------------------------------------service-mtu 1518
sap 1/1/4:50 create
exit
exit
no shutdown
------------------------------------------

===============================================================================
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 100
Last Mgmt Change : 02/09/2012 15:55:19
Admin State
: Up
Oper State
: Down
MTU
: 1518
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4:50
q-tag
1518
1518
Up
Down
sdp:2:50 S(10.10.10.2)
Spok
0
9190
Up
Up
===============================================================================
Module 2 |
28
When the service MTU is changed on both PE routers, the entire service goes down because SAP-MTU
can not support the new service.
The SAP-MTU must be changed so that it can support the service MTU.
Port-MTU >= service-MTU + MAX egress encapsulation
In this case, since the SAP is dot1Q encapsulated, it must be changed to 1522 (service MTU + 4 bytes
Dot1Q encap).
Note: if the MTU is increased on PE1 only, then the SDP binding will also be down. The service MTU is
used in the T-LDP signaling of the pseudowire and must match at both ends of the service. We increased
the MTU on both PE1 and PE2 and the path MTU is up.
Module 2 Page 28
Epipe MTU Case Study Changing the Service MTU
*A:PE-1# configure port 1/1/4 shutdown

*A:PE-1# configure port 1/1/4 ethernet mtu 1522
*A:PE-1# configure port 1/1/4 no shutdown


===============================================================================
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 100
Last Mgmt Change : 02/09/2012 17:15:58
Admin State
: Up
Oper State
: Up
MTU
: 1518
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4:50
q-tag
1522
1522
Up
Up
sdp:2:50 S(10.10.10.2)
Spok
0
9190
Up
Up
===============================================================================
Module 2 |
29
The SAP MTU is changed to 1522 (service MTU + 4 bytes Dot1Q encapsulation). The service is up.
Module 2 Page 29
Epipe MTU Case Study Changing the SAP MTU
Epipe MTU Case Study SDP path MTU
The network port MTU between

P1 and P2 is set to 1514 bytes
It is required to support a service

MTU of 9000 byte
*A:PE-1# configure service epipe 50 service-mtu 9000

*A:PE-2# configure service epipe 50 service-mtu 9000


===============================================================================
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 100
Last Mgmt Change : 02/09/2012 17:56:14
Admin State
: Up
Oper State
: Up
MTU
: 9000
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4:50
q-tag
9004
9004
Up
Up
sdp:2:50 S(10.10.10.2)
Spok
0
9190
Up
Up
Module 2 |
30
The calculation of SDP path MTU from the egress network port assumes that all ports on the SDP path
have an equal or greater MTU. When this is not the case, it may cause problems with services bound to
the SDP. We have changed the MTU on the network ports between P1 and P2 to 1514 bytes.
To support a service MTU of 9000, we need to increase the SAP MTU to 9004 since we are using dot1q
encapsulation.
The SDP path MTU is 9190, which is calculated as physical interface MTU - 14 bytes DLC (6 byte source
MAC + 6-byte dest MAC + 2 byte Ethertype) - 4 byte (MPLS transport label) - 4 byte (MPLS service label).
The service MTU is smaller than the SDP path of 9190, so the service is up.
Module 2 Page 30
Epipe MTU Case Study SDP path MTU (continued)

The epipe service does not support anywhere near the size frame expected
with a service MTU of 9000 bytes

---- 192.168.1.2 PING Statistics ---1 packet transmitted, 1 packet received, 0.00% packet loss
round-trip min = 5.08ms, avg = 5.08ms, max = 5.08ms, stddev = 0.000ms

---- 192.168.1.2 PING Statistics ---1 packet transmitted, 0 packets received, 100% packet loss
Module 2 |
31
Although we can ping across the epipe, we find that it does not support anywhere near the size frame
expected with a service MTU of 9000 bytes. The maximum size ping is found to be 1450 bytes. The size
of the frame transmitted on the network port for this ping can be calculated as 1450 plus 28 byte IP/ICMP
header plus 14 byte payload Ethernet header plus 22 bytes transport encapsulation overhead = 1514
bytes. This is exactly as expected since the link MTU between PE1 and PE2 is 1514.
Module 2 Page 31
Epipe MTU Case Study SDP path MTU (continued)
*A:PE-1# oam sdp-mtu 2 size-inc 1450 1500 step 10

Size
Sent
Response
---------------------------1450
.
Success
1460
.
Success
1470
.
Success
1480
.
Success
1490
.
Success
1500
...
Request Timeout

Size
Sent
Response
---------------------------1490
.
Success
1491
.
Success
1492
.
Success
1493
...
Request Timeout
Maximum Response Size: 1492
Module 2 |
32
The command oam sdp-mtu transmits increasingly large packets on the SDP. The slide shows the use of
this tool to determine the effective path MTU for SDP 2 of 1492 bytes. If we add the transport
encapsulation overhead of 22 bytes to this, we get a network port MTU of 1514.
Module 2 Page 32
To determine the effective path MTU of the SDP, the command oam
sdp-mtu is used
Epipe MTU Case Study SDP path-MTU - Verify Path MTU Using RSVP ADSPEC
If ADSPEC is configured on the LSP used as the transport for the SDP, the SDP pathMTU is derived from the path MTU signaled in RSVP using the ADSPEC object
Negotiated MTU for the LSP is set to the smallest MTU value found on the path
*A:PE-1>config>router>mpls# lsp "to-PE2"

*A:PE-1>config>router>mpls>lsp# adspec
*A:PE-1>config>router>mpls>lsp# info
-----------------------------------------to 10.10.10.2
adspec
primary "loose"
exit
no shutdown
-------------------------------------------
*A:PE-1# show router mpls lsp "to-PE2" path detail

===============================================================================
MPLS LSP to-PE2 Path (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
LSP to-PE2 Path loose
------------------------------------------------------------------------------LSP Name
: to-PE2
Path LSP ID : 38922
From
: 10.10.10.1
To
: 10.10.10.2
Adm State
: Up
Oper State : Up
Path Name
: loose
Path Type
: Primary
Path Admin : Up
Path Oper
: Up
OutInterface: 1/1/3
Out Label
: 131069
.
Oper CT
:
Record Route:
Oper MTU
:
Adaptive
:
Include Grps:
0
Record
1500
Enabled
Record Label: Record

Neg MTU
: 1500
Oper Metric : 300
Exclude Grps:
Module 2 |
33
RSVP defines the ADSPEC object that can be used in the path message to collect information about the
path at each router, including MTU information.
Negotiated MTU for the LSP is set to the smallest MTU value found on the path. If the path of the RSVP
changes, the MTU will change to reflect MTU on the new path.
If ADSPEC is configured on the LSP used as the transport for the SDP, the SDP path MTU is derived from
the path MTU negotiated by RSVP-TE using the ADSPEC object. Notice that the LSP MTU is 1500 bytes.
The SDP path MTU is 8 bytes less to accommodate the two MPLS labels.
Module 2 Page 33
Epipe MTU Case Study SDP path MTU - Verify Path MTU Using RSVP ADSPEC
The SDP path MTU is

now 1492 bytes
The service is down

because the SDP pathMTU is now less than
the service MTU of
9000 bytes
*A:PE-1# show service sdp 2

==============================================================================
Service Destination Point (Sdp Id : 2)
==============================================================================
SdpId
Adm Opr
Deliver
Signal
-----------------------------------------------------------------------------2
0
1492
10.10.10.2
Up
Up
MPLS
TLDP
==============================================================================
*A:PE-1# show service id 50 sdp 2:50 detail

===============================================================================
Service Destination Point (Sdp Id : 2:50) Details
===============================================================================
Sdp Id 2:50 -(10.10.10.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 2:50
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 1492
Far End
: 10.10.10.2
Delivery
: MPLS
Hash Label
: Disabled
Admin State
Acct. Pol
Ingress Label
Last Status Change

Last Mgmt Change
Endpoint
Class Fwding State
Flags
Peer Pw Bits
: Up
: None
: 131071
Oper State
Collect Stats
Egress Label
: Down
: Disabled
: 131069
:
:
:
:
:
:
Signaling
Force Vlan-Vc
Precedence
: TLDP
: Disabled
: 4
02/09/2012 18:53:18
02/09/2012 17:56:14
N/A
Down
PathMTUTooSmall
pwNotForwarding
Module 2 |
34
The service is down because the SDP path MTU is now less than the service MTU of 9000. The Flags
field is set to PathMTUTooSmall
The show service sdp detail command displays detailed information related to a particular SDP. This
SDP may or may not be bound to a service.
Syntax: sdp [sdp-id | far-end ip-address] [detail | keep-alive-history]
Description: Displays SDP information. If no optional parameters are specified, a summary SDP output
for all SDPs is displayed.
Parameters: sdp-id the SDP ID associated with the displayed information
Default all SDPs
Values 1 - 17407
far-end ip-address: Displays only SDPs matching the specified far-end IP address
Default SDPs with any far-end IP address
Detail: Displays detailed SDP information
Default SDP summary output
keep-alive-history: Displays the last fifty keep-alive events for the SDP
Default: SDP summary output
Some of the important pieces of information that can be obtained from this command include the following:
SDP far-end IP address: This information is the system address of the far-end router where the SDP
terminates.
Delivery: This information indicates whether this SDP is a MPLS- or GRE-based SDP.
LSP Name: This information relates to the LSP associated with the SDP and their administrative and
operational states. This information applies if the SDP is a MPLS-based SDP and RSVP-TE is being used
as the MPLS signaling protocol.
The show service id sdp detail command displays information for the specific SDPs associated with a
particular service. In this case, we are displaying information about the SDP associated with the service
that has a service ID of 50.
Module 2 Page 34
Epipe MTU Case Study Changing the Network Port MTU

Changing the MTU on the link from P1 to P2 to 9212 will make the service
up again
*A:P1# configure port 1/1/4 shutdown
*A:P1# configure port 1/1/4 ethernet mtu 9212
*A:P1# configure port 1/1/4 no shutdown
*A:P2# configure port 1/1/4 shutdown

*A:P2# configure port 1/1/4 ethernet mtu 9212
*A:P2# configure port 1/1/4 no shutdown
===============================================================================
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 100
Last Mgmt Change : 02/09/2012 17:56:14
Admin State
: Up
Oper State
: Up
MTU
: 9000
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4:50
q-tag
9004
9004
Up
Up
sdp:2:50 S(10.10.10.2)
Spok
0
9190
Up
Up
===============================================================================
*A:PE-1# show service sap-using

===============================================================================
Service Access Points
===============================================================================
PortId
SvcId
Ing. Ing.
Egr. Egr.
Adm Opr
QoS
Fltr
QoS
Fltr
------------------------------------------------------------------------------1/1/4:50
50
1
none
1
none
Up
Up
------------------------------------------------------------------------------Number of SAPs : 1
Module 2 |
35
The service could be made operationally up by setting the service MTU to 1492; however, we want to be
able to support a service MTU of 9000 bytes. Changing the MTU on the link from P1 to P2 to 9212 will
make the service up again as shown.
The show service sap-using command displays information for a particular SAP that may be associated
with a service.
You can also verify the service is up using the following command
*A:PE-1# show service service-using epipe
===============================================================================
Services [epipe]
===============================================================================
ServiceId Type
Adm Opr CustomerId Service Name
------------------------------------------------------------------------------50
Epipe
Up
Up
100
------------------------------------------------------------------------------Matching Services : 1
-------------------------------------------------------------------------------
Another show command that displays the service tunnel labels that are being used by the service is
*A:PE-1# show service id 50 labels
===============================================================================
Martini Service Labels
===============================================================================
Svc Id
Sdp Binding
Type I.Lbl
E.Lbl
------------------------------------------------------------------------------50
2:50
Spok 131071
131071
-------------------------------------------------------------------------------
Module 2 Page 35
The command show

service id 50 all
displays detailed
information related
to all aspects of the
service
*A:PE-1# show service id 50 all

===============================================================================
Service Detailed Information
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 100
Last Mgmt Change : 02/09/2012 17:56:14
Admin State
: Up
Oper State
: Up
MTU
: 9000
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------Sdp Id 2:50 -(10.10.10.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 2:50
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 9190
Far End
: 10.10.10.2
Delivery
: MPLS
Hash Label
: Disabled
Admin State
Acct. Pol
Ingress Label
Ingr Mac Fltr-Id
Ingr IP Fltr-Id
Ingr IPv6 Fltr-Id
Admin ControlWord
Admin BW(Kbps)
Last Status Change
:
:
:
:
:
:
:
:
:
Up
None
131071
n/a
n/a
n/a
Not Preferred
0
02/09/2012 19:15:45
Oper State
Collect Stats
Egress Label
Egr Mac Fltr-Id
Egr IP Fltr-Id
Egr IPv6 Fltr-Id
Oper ControlWord
Oper BW(Kbps)
Signaling
Module 2 |
36
:
:
:
:
:
:
:
:
:
Up
Disabled
131071
n/a
n/a
n/a
False
0
TLDP
The command show service id all displays detailed information related to all aspects of the service.
Syntax id: service-id all
Description: Displays information for a particular service ID
Parameters: service-id the unique service identification number that identifies the service in the service
domain.
Some of the important pieces of information that can be obtained using this command are as follows:
Administrative and operational states: This can help you to determine if the service is administratively
and operationally up.
SDP and VC ID information: The VC ID in the example in this slide is 50, and is associated with an SDP
ID of 2.
Ingress and egress labels: The ingress label, which is 131071 in this example, is the label that this router
has advertised to the adjacent router. The adjacent router will use the same label when sending data to
this router. The egress label, which is 131071 in this example, is the label that this router will use when
sending data to the adjacent router.
LSP Name: If this SDP is bound to a RSVP-TE-based LSP, then the name of the LSP is displayed.
If you want to delete an epipe service, perform the following steps prior to deleting it:
1. Shut down the SAP and SDP.
2. Delete the SAP and SDP.
3. Shut down the service.
You can shut down an epipe service without deleting the service parameters by using the shutdown
command.
Module 2 Page 36
Epipe MTU Case Study Verification
SDP and VC Type

RFC 4448 defines two VC types for the Ethernet pseudowire
The VC type is specified when the SDP is bound to the service and is
signaled by T-LDP
The service delimiting VLAN tag is stripped at the ingress and is not
carried across the epipe
VLAN - specifies tagged mode

A VLAN tags is carried in the frame
Supported on the 7750 SR mainly for interoperability with systems that
only support tagged mode
Module 2 |
37
RFC 4448 defines the transport of Ethernet frames over an MPLS network and defines two VC types for
the Ethernet pseudowire: tagged mode and raw mode. The 7750 SR supports both, with raw mode the
default. The VC type is specified when the SDP is bound to the service and is signaled by T-LDP.
In raw mode, the service delimiting VLAN tag or tags are stripped at the ingress and are not carried across
the epipe. In tagged mode, a VLAN tag is carried in the frame. Tagged mode is supported on the 7750 SR
mainly for interoperability with systems that only support tagged mode.
If tagged mode is used, remember to add an additional 4 bytes when calculating the required service
MTU.
When type VLAN is specified and the SAP is defined with a service delimiting tag, this value is used for
the tag on the pseudowire. If there is no service delimiting tag, a tag with value of 0 is used.
The value for the tag can be configured to use a specific value.
Module 2 Page 37
Ether - specifies raw mode (default)
VC Type Configuration
The epipe on PE1 is configured with type VLAN
*A:PE-1>config>service# epipe 50
*A:PE-1>config>service>epipe# spoke-sdp 2:50 shutdown
*A:PE-1>config>service>epipe# spoke-sdp 2:50 vc-type vlan create
*A:PE-1>config>service>epipe>spoke-sdp# vlan-vc-tag 150
*A:PE-1>config>service>epipe# spoke-sdp 2:50 no shutdown
---------------------------------------------service-mtu 9000
sap 1/1/4:50 create
exit
spoke-sdp 2:50 vc-type vlan create
vlan-vc-tag 150
exit
no shutdown
----------------------------------------------
*A:PE-2# configure service epipe 50

---------------------------------------------service-mtu 9000
sap 1/1/4:50 create
exit
exit
no shutdown
----------------------------------------------
Module 2 |
38
The slide shows the configuration of epipe 50 with type VLAN using a tag value of 150 on PE1. The other
end of the epipe (PE2) is still using type ether.
Module 2 Page 38
On PE2 the epipe is still using type Ether
VC Type Configuration (continued)

======================================================
Services [epipe]
======================================================
ServiceId Type
-----------------------------------------------------50
Epipe
Up
Down 100
-----------------------------------------------------Matching Services : 1

===========================================================================
===========================================================================
Sdp Id 2:50 -(10.10.10.2)
--------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 2:50
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: VLAN
VC Tag
: 150
Admin Path MTU
: 0
Oper Path MTU
: 9190
Far End
: 10.10.10.2
Delivery
: MPLS
Hash Label
: Disabled
Admin State
Acct. Pol
Ingress Label
Ingr Mac Fltr-Id
Ingr IP Fltr-Id
Ingr IPv6 Fltr-Id
Admin ControlWord
Admin BW(Kbps)
Last Status Change
Last Mgmt Change
Endpoint
Class Fwding State
Flags
Peer Pw Bits
Peer Fault Ip
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Up
None
131071
n/a
n/a
n/a
Not Preferred
0
02/10/2012 11:27:18
02/10/2012 11:27:57
N/A
Down
NoEgrVCLabel
None
None
Module 2 |
39
Oper State
Collect Stats
Egress Label
Egr Mac Fltr-Id
Egr IP Fltr-Id
Egr IPv6 Fltr-Id
Oper ControlWord
Oper BW(Kbps)
Signaling
Force Vlan-Vc
Precedence
:
:
:
:
:
:
:
:
:
:
:
Down
Disabled
0
n/a
n/a
n/a
False
0
TLDP
Disabled
4
T-LDP will not make a pseudowire operational unless the VC ID and VC type match. The Flags field
contains NoEgrVCLabel, which is an indication that there is no service at the other end.
Module 2 Page 39
T-LDP will not make a pseudowire operational unless the VC ID and

VC type match

T-LDP will not make a pseudowire operational unless the VC ID and
VC type match
===============================================================================
LDP LSR ID: 10.10.10.1
===============================================================================
===============================================================================
===============================================================================
Type
VCId
SvcId
SDPId Peer
------------------------------------------------------------------------------E-Vlan 50
50
2
10.10.10.2
131071U
-8986 0
?-Eth 50
Ukwn
R. Src 10.10.10.2
-131071S 0
8986
------------------------------------------------------------------------------No. of VC Labels: 2
Module 2 |
40
The show router ldp bindings fec-type services command shows two different services with VC ID of
50 but different VC types.
Module 2 Page 40
Configure the epipe on PE2 with type VLAN

*A:PE-2>config>service>epipe# spoke-sdp 1:50 vc-type vlan create
*A:PE-2>config>service>epipe>spoke-sdp# vlan-vc-tag 150
*A:PE-2>config>service>epipe>spoke-sdp# no shutdown
*A:PE-2>config>service>epipe>spoke-sdp# exit
---------------------------------------------service-mtu 9000
sap 1/1/4:50 create
exit
spoke-sdp 1:50 vc-type vlan create
vlan-vc-tag 150
exit
no shutdown
----------------------------------------------
Module 2 |
41
The remote router (PE2) is configured as type VLAN.
Module 2 Page 41

Verifying the epipe service

==========================================================
Services [epipe]
==========================================================
ServiceId Type
---------------------------------------------------------50
Epipe
Up
Up
100
---------------------------------------------------------Matching Services : 1
----------------------------------------------------------

===============================================================================
LDP LSR ID: 10.10.10.1
===============================================================================
===============================================================================
===============================================================================
Type
VCId
SvcId
SDPId Peer
------------------------------------------------------------------------------E-Vlan 50
50
2
10.10.10.2
131071U 131071S 8986 8986
------------------------------------------------------------------------------No. of VC Labels: 1
Module 2 |
42
After the remote router (PE-2) is configured as type VlAN, the service is operational
Module 2 Page 42
Module 2 |
43
The slide shows the different combinations of frame transmission possible for a null encapsulated SAP
with different egress encapsulations. The behavior of the default dot1Q SAP is the same.
Notice in the diagram above:
VLAN tags received on a customer SAP port are never considered by null SAPs to be service delimiting.
Therefore, ingress VLAN tags are passed transparently through the network from ingress SAP to egress
SAP. Since these tags are not considered to be service delimiting, in VC type VLAN mode, we will always
add a dummy tag with default VLAN ID = 0.
Note: on the egress SAP, the tags configured on the SAP always encapsulate the frame, including any
VLAN tag received.
Module 2 Page 43
VLAN Tag Behavior With a Null SAP
Module 2 |
44
The slide shows the different combinations of frame transmission possible for a dot1Q encapsulated SAP
with different egress encapsulations.
An encapsulation of dot1Q with a service SAP of 0 accepts untagged traffic or traffic with VLAN ID=0.
This means that untagged Ethernet traffic or Ethernet traffic with VLAN ID=0 will be mapped on this SAP.
To determine the handling of VLAN tags received on a SAP ingress port, you must determine if the VLAN
are considered service delimiting. Service delimiting VLANs are also called provider VLANs. If the VLANs
are considered service delimiting tags, they may be sent on a VC type VLAN; however, they will be
stripped on the egress PE instead of being sent out the egress PE SAP.
A VLAN tag received on a SAP port is considered service delimiting if it matches the encapsulation on the
SAP port. For example, in case B2 the encapsulation used on the dot1Q port is :C. Therefore, the
encapsulation matches the VLAN ID received, hence the tag is considered service delimiting and will not
be seen on the SAP egress of the far-end PE. When a VC type Ether is used, service delimiting tags are
stripped rather than passed over. In the case of a VC type VLAN, a single service delimiting tag is sent
over the core but stripped at the far-end PE.
In case B3, the same procedure is used to determine which of the VLAN tags received are service
delimiting. In this case, the SAP is dot1Q encapsulated, therefore there can only be a single service
delimiting tag. The outer VLAN tag on the Ethernet frame received on the SAP is C, which matches the
SAP encapsulation. Therefore, the outer VLAN tag is considered service delimiting. If a tag received on a
SAP port is not service delimiting, as in case B2, if the VC type is Ether, the service delimiting tag C is
not passed through; if the VC type is VLAN, the service delimiting tag C is passed through but is not
seen on the egress SAP.
In the cases presented here, when the VC type is VLAN, the service delimiting VLAN ID is sent over. If a
VLAN-VC-tag is defined with a new VLAN-ID, it is this VLAN ID that will be sent as the service delimiting
VLAN over. In the default case, the VLAN-VC-tag is not defined and the service delimiting tag that
matches the SAP encapsulation tag is sent over the core.
Module 2 Page 44
VLAN Tag Behavior With a dot1Q SAP
Module 2 |
45
In the cases presented here, when the VC type is VLAN, the service delimiting VLAN ID is sent over. If a
VLAN-VC-tag is defined with a new VLAN-ID, it is this VLAN ID that will be sent as the service delimiting
VLAN. In the default case, the VLAN-VC-tag is not defined and the service delimiting tag that matches the
SAP encapsulation tag is used.
Module 2 Page 45
VLAN Tag Behavior With a Q-in-Q SAP
Encapsulation and VC Type Summary
An epipe can be configured with any combination of SAP encapsulation at

each end
Null SAP or default dot1Q SAP (SAP 1/1/1, SAP 1/1/1:*)
Dot1Q SAP or wildcard Q-in-Q SAP (SAP 1/1/1:10, SAP 1/1/1:10.*)

Outer VLAN tag is removed at ingress, and any remaining tags are
transmitted in the pseudowire
The specified VLAN tag is added to packets on egress
Q-in-Q SAP (SAP 1/1/1:10:20)

Two outer VLAN tags are removed at ingress
The two specified VLAN tags are added to egressing packets
Module 2 |
46
There are many options for SAP encapsulations as well as two options for the VC type on an Ethernet
pseudowire.
An epipe can be configured with any combination of SAP encapsulation at each end; a null SAP on one
side and a Q-in-Q encapsulated SAP on the other side, for example.
Module 2 Page 46
All VLAN tags received at ingress are transmitted in the pseudowire. No

VLAN tags are added to egressing packets
Encapsulation Summary dot1Q

Explicitly matched VLAN tags are stripped on the ingress PE when the SDP
VC type is set to "Ether
The VLAN tag may be regenerated at the egress PE depending on how
the SAP is configured
SAP:*, allows untagged frames and tagged frames with any VLAN ID that
has not been explicitly defined on the port
Module 2 |
47
Examples:
When a SAP is defined with the 1/1/1:0, any untagged frames and/or frames with a tag of 0 are
accepted.
When a SAP is defined with a wild card (SAP 1/1/1:*), the default SAP will allow untagged frames and
tagged frames with any VLAN ID that has not been explicitly defined on port 1/1/1.
Module 2 Page 47
SAP:0, only untagged frames and/or a VLAN of 0 are accepted
Encapsulation Summary Q-in-Q

Explicitly matched tag (SAP:Top:Bottom) is stripped at ingress when the VC
type on the SDP is set to Ether, and regenerated at egress depending on
how the egress SAP is configured
Will also accept no bottom tag
SAP:0.* matches untagged and/or a VLAN of 0 for the top tag
Module 2 |
48
Examples
SAP 1/1/1:0.* Will allow any untagged frames and/or frames with a top tag of 0 only.
SAP 1/1/1:10.* Will only match 10 as the top Q tag and may have any bottom tag or no bottom tag at
all.
SAP 1/1/1:10.0 Will only match 10 as the top Q tag and may have a bottom tag of 0 or no bottom tag
at all.
SAP 1/1/1:10.* and 1/1/1:10.0 Co-exist in the same service: traffic with a top tag of 10 will always be
learned from SAP 1/1/1:10.0
SAP 1/1/1:10.11 Will only match packets with an existing top and bottom tag, in this case the top tag is
10 and the bottom tag is 11.
Module 2 Page 48
SAP:top.* strips the top VLAN tag and preserves the bottom (MTU
implications)
Lab 2 Distributed Epipe Service
In this lab you will configure and verify an epipe service.
Module 2 |
49
Module 2 Page 49
Section 2 Other VPWS
Module 2 Page 50
Section Objectives
Describe the main characteristics of fpipe service
Describe the main characteristics of apipe service
Describe the main characteristics of cpipe service
Module 2 |
51
In the previous section we described the epipe service in detail, and throughout this course most of the
attention to Layer 2 services is given to Ethernet. Other Layer 2 services supported by the Alcatel-Lucent
7750SR are also important. Although the trend in current network deployments is increasingly to Ethernet
for reasons of cost and performance, there is still a very significant demand for other technologies that
represent very significant revenues to service providers. These services can be deployed on an IP/MPLS
infrastructure that simultaneously provides a base for modern Ethernet and IP services. Layer 2 services
available besides Ethernet (epipe) are fpipe, apipe, cpipe and ipipe (ipipe will be covered in the next
section).
These services are all based on RFC 4447 (Pseudowire Setup and Maintenance Using LDP) and most of
the characteristics, configuration and maintenance that we describe for epipes apply to these services as
well. In this section we introduce each of these services, paying particular attention to any characteristics
that distinguish them from an epipe service.
Module 2 Page 51
Describe the two modes of operation supported on the AlcatelLucent 7750 SR for apipe
Fpipe provides a point-to-point Frame Relay service between users

connected to 7750SR routers on the IP/MPLS network
A single Frame Relay circuit is mapped to an fpipe service
From the customers perspective, the PE router should appear as a native

Frame Relay UNI (user network interface)
The control word is required for an fpipe because the Frame Relay header is
not carried with the encapsulated frame
Module 2 |
52
In the past, VPN markets were dominated by both Frame Relay and private lines, which dominated
approximately 90 percent of enterprise connections. The popularity of Frame Relay service over a private
line is based on the lower cost of Frame Relay as well as its ability to support large amounts of traffic.
However, growth in Frame Relay services is limited by its lower speed and the cost of multipoint solutions.
For service providers with established Frame Relay services, the MPLS network allows them to leverage
their existing infrastructure to enable new revenue opportunities. These new revenue opportunities are
created by blending technologies through service interworking in order to create a service hybrid. For the
enterprise that is seeking a gradual transition from a Frame Relay VPN to an Ethernet VPWS or who
wants to add a new site with Ethernet access while still maintaining Frame Relay at the other sites, a
service hybrid is ideal.
UNI: user network interface.
Frame Relay pseudowires are described in RFC 4619 (Encapsulation Methods for Transport of Frame
Relay Over MPLS Networks). The 7750 SR supports one-to-one mode for the mapping of a Frame Relay
DLCI (data link connection identifier) to a pseudowire. This means that a single Frame Relay circuit is
mapped to an fpipe service.
From the customers perspective, the PE router should appear as much as possible like a native Frame
Relay UNI (user network interface).
When a frame arrives at the fpipe SAP, the Frame Relay header and any padding are removed. The frame
is encapsulated with a service label and transport label as for any pseudowire service. The fpipe also uses
the MPLS control word, which is a 4-byte field directly following the service label. Specific values from the
Frame Relay header are copied into the control word.
The MPLS control word is an optional field in the RFC 4447 pseudowire encapsulation. It is not generally
used in an epipe, but is always present in the fpipe encapsulation.
The control word is required for an fpipe because the Frame Relay header is not carried with the
encapsulated frame. When the frame is received at the ingress SAP, specific bits are copied to the control
word. When the Frame Relay frame is reconstructed at the egress SAP these bits are copied to the
appropriate bit in the header.
Module 2 Page 52
Fpipe Service
Fpipe Common Configuration Tasks

The fpipe uses the same provisioning steps as an epipe, with the
following exceptions:
The service type is fpipe
SAP is in the form of port:DLCI (example 1/1/1:65)
Module 2 |
53
There is no Frame Relay MDA. Frame Relay encapsulation is supported on all MDAs that support POS
encapsulation.
Module 2 Page 53
The physical port or channel is a SONET port set for Frame Relay
framing
Apipe Service
Module 2 |
54
ATM pseudowires are described in RFC 4717 (Encapsulation Methods for Transport of ATM Over MPLS
Networks).
ATM VPWS (apipes) provide a point-to-point ATM service between users connected to 7750 SR routers
on an IP/MPLS network. Users are directly connected to either a 7750 SR PE or through an ATM access
network. In both cases, an ATM PVC (permanent virtual circuit) is configured on the 7750 SR PE; for
example, a virtual channel (VC) or a virtual path (VP) are configured on the 7750 SR PE. This feature
supports local cross-connection when users are attached to the same 7750 SR PE router. VPI/VCI
translation is supported in the ATM VPWS.
An ATM PVC is configured on the PE; the apipe appears as an ATM circuit to the customer.
Module 2 Page 54
Apipe is used to carry ATM cells over an MPLS network.
Apipe Service Modes of Operation

Supported apipe modes of operation:
N:1 cell mode:
ATM Adaptation Layer 5 (AAL5) frame mode:

An AAL5 SDU (service delivery unit) frame is encapsulated for
transmission on the apipe
Module 2 |
55
Two different modes of operation are supported on the Alcatel-Lucent 7750 SR for ATM apipes: the N:1
cell mode and AAL5 frame mode.
Module 2 Page 55
Individual cells or groups of cells are encapsulated for transmission on

the apipe
One or more cells is transparently encapsulated in an apipe frame
The advantage of N:1 concatenation is the efficient bandwidth use
The disadvantage is that the wait required to complete an MPLS packet

increases the delay for the ATM connection
Module 2 |
56
N:1 cell mode provides a service that supports the transport of control, signaling and routing information
since cells arriving at the SAP are transparently carried over the apipe.
The figure shows a group of ATM cells encapsulated in N:1 cell mode.
An important characteristic of N:1 concatenation is that multiple cells can be encapsulated in a single
MPLS packet. The advantage of concatenation is more efficient bandwidth use, since the encapsulated
ATM cells are only 52 bytes each (The 5-byte ATM header is transported as 4 bytes, the Header Error
Check byte (HEC) is removed). The disadvantage is that the waiting required to complete an MPLS
packet increases the delay for the ATM connection.
The cell-concatenation command is used in the spoke SDP context to specify the concatenation
parameters for the pseudowire. The default is no cell concatenation.
Module 2 Page 56
N:1 Cell Mode
AAL5 was defined for a best effort, connectionless packet service such as IP
The control word is required for an apipe in AAL5 frame mode
Allows ATM AAL5 PDUs traveling on a particular ATM PVC across the network
to travel to another ATM PVC
Requires segmentation and reassembly on the ingress PE-CE ATM interface
Once reassembled, the AAL5-SDU is carried through a pseudowire to the

egress PE
Module 2 |
57
The AAL5 SDU (service delivery unit) is the payload that the service is intended to carry - in this case, the
IP packet. The SDU is encapsulated in an AAL5 PDU, which has no header but an 8-byte trailer, and is
padded so that the SDU + trailer + padding is an exact multiple of 48 bytes long. The AAL5 PDU is then
split into the necessary number of cells for transmission. This operation is known as segmentation and
reassembly (SAR).
Module 2 Page 57
AAL5 Frame Mode
Module 2 |
58
The AAL5 SDU (service delivery unit) is the payload that the service is intended to carry - in this case, the
IP packet. The SDU is encapsulated in an AAL5 PDU, which has no header but an 8-byte trailer, and is
padded so that the SDU + trailer + padding is an exact multiple of 48 bytes long. The AAL5 PDU is then
split into the necessary number of cells for transmission. This operation is known as segmentation and
reassembly (SAR).
When the apipe is defined as VC type atm-sdu, the PEs perform the SAR operation and only the AAL5
SDU is carried in the MPLS-encapsulated packet. This provides more efficient use of the bandwidth, since
the AAL5 overhead (padding and trailer) and the ATM cell headers are discarded.
The SAP defines a single PVC in the format port:pvi/pci.
As in the fpipe, the control word is also required for an apipe in AAL5 frame mode. The purpose is to carry
the information lost when the cell headers are stripped in the SAR process.
Module 2 Page 58
AAL5 Frame Mode Operation
Apipe Common Configuration Tasks

The service type is apipe
The physical port or channel is a SONET port set for ATM
framing
SAP syntax changes depending on the VC type used:

The default is AAL5 SDU with a SAP syntax of port:VPI/VCI; for
example, port 1/1/1:0/100
Module 2 |
59
The same provisioning steps used in the configuration of epipe also apply to apipe, with the exceptions
shown in the slide.
Module 2 Page 59
Many VC types are supported by apipe, including SDU frame

mode and N:1 cell mode
Cpipe Service
Module 2 |
60
Circuit Emulation Services (CES) VPWS or Cpipe, is a point-to-point VPN service emulating a TDM
leased line. Two PE routers connected to the customer sites through the local attachment circuit receive
native TDM traffic, perform both VPN (PW) and transport tunnel encapsulation, and finally send the traffic
through the packet-switched network to reach the remote site. The packet-switched network is PSN,
usually IP/MPLS.
Cpipes are an implementation of TDM pseudowires to transport T1 or E1 circuits. T-1 is a digital circuit
that uses the DS-1 (Digital Signaling level 1) signaling format to transmit voice/data over the PSTN
network at 1.544 Mbps. T-1 can carry up to 24 uncompressed digital channels of 64 Kbps (DS0) for voice
or data. E-1 is the European equivalent of the T-1, except E-1 carries information at the rate of 2.048
Mbps. E-1 is used to transmit 30 64Kbps digital channels (DS0) for voice or data calls, plus a 64Kbps
channel for signaling, and a 64Kbps channel for framing and maintenance.
Module 2 Page 60
TDM VPWS (cpipe) is used to carry TDM frames over an IP/MPLS

network
Cpipe Service (continued)

SAPs are configured on a SONET/SDH port
There are two categories of cpipes:
Structured emulation - Makes use of the TDM framing structure, where

each frame is comprised of a sequence of timeslots
The encapsulation for all cpipes includes the control word
Module 2 |
61
There are two categories of cpipes:

Unstructured emulation - SAToP (Structure Agnostic TDM over Packet) pseudowires are defined in RFC
4553 and transport unstructured T1 or E1 circuits. Disregards the TDM framing structure and treats the
TDM data as a stream of consecutive octets
Structured emulation - CESoPSN (Circuit Emulation Service over Packet Switched Network)
pseudowires are defined in RFC 5086 and transport multiple DS0 channels from a T1 or E1 circuit. Makes
use of the TDM framing structure, where each frame is comprised of a sequence of timeslots.
Module 2 Page 61
Unstructured emulation - disregards the TDM framing structure and

treats the TDM data as a stream of consecutive octets
Cpipe Common Configuration Tasks

The following applies to the configuration of Cpipe:
The SAP will be a TDM port
Module 2 |
62
Configuring a cpipe is similar to configuring an epipe or apipe, with the exception of the VC type and the
syntax used for the SAP.
Module 2 Page 62
VC types are added for cpipes depending on whether the service is

using structured or unstructured TDM ports/channels
Section 3 VPWS Interworking Capabilities
Module 2 Page 63
Section Objectives
Identify the 7750 SR interworking capabilities provided with VPWS
Module 2 |
64
Define ipipe service and explain its main characteristics
Module 2 Page 64
Interworking VPWS
ATM
Frame Relay
Ethernet
ATM
Apipe
Apipe (FRF.5 interworking)
Epipe (bridged)
Ipipe (routed)
Frame Relay
Apipe (FRF.5 interworking)
Fpipe
Epipe (bridged)
Ipipe (routed)
Ethernet
Epipe (bridged)
Ipipe (routed)
Epipe (bridged)
Ipipe (routed)
Epipe
Module 2 |
65
The Alcatel-Lucent VPWS offers network interworking for Ethernet, ATM and Frame Relay across a
common IP/MPLS network. The interworking capabilities of the VPWS allow different Layer 2 networks to
be connected together across an IP/MPLS core network.
The table in this slide lists the various interworking scenarios possible with ATM, Frame Relay and
Ethernet ports at either end of a pseudowire.
When IP traffic, encapsulated inside an Ethernet frame, needs to be transported by a bridge/router over
its ATM port to a bridge/router with an Ethernet port, bridged encapsulation is used. An epipe is required
to transport this type of traffic.
Routed encapsulation is used when native IP traffic is transported across a bridge/router with an ATM port
to a bridge/router with an Ethernet port. An ipipe is required to transport this type of traffic.
Module 2 Page 65
The interworking capabilities of the 7750 SR are:
FRF.5 Interworking Over an Apipe
Module 2 |
66
On the Alcatel-Lucent 7750 SR, Frame Relay traffic can be transported over an ATM network to another
Frame Relay network on the other side through the use of an apipe. This is known as Frame Relay Forum
(FRF.5) Network Interworking.
It is configured on the 7750 SR by creating an apipe service that specifies interworking FRF.5 and a
Frame Relay SAP with a DLCI encapsulation ID. The port is configured for Frame Relay encapsulation.
The other end of the apipe has a regular ATM SAP with VPI/VCI encapsulation ID. The VC type of the
apipe must be atm-sdu
Module 2 Page 66
FRF.5 defines a standard method for encapsulating and transporting

Frame Relay frames over an ATM network through the use of an
apipe
Epipe is used between the Ethernet user and the ATM-attached user or
Frame-Relay-attached user
Provides ATM and Frame Relay bridged encapsulation access to the epipe
service of an Alcatel-Lucent 7750 SR
Module 2 |
67
This slide provides an example of an Ethernet interworking VPWS. The Ethernet interworking VPWS
provides a point-to-point Ethernet VPWS between Frame-Relay-attached users, ATM-attached users and
Ethernet-attached users across an IP/MPLS packet-switched network. It effectively provides ATM and
Frame Relay bridged encapsulation termination on the existing Epipe service of the 7750SR.
The Frame Relay network must be sending and receiving Ethernet encapsulated frames as defined by
RFC 2427 (Multiprotocol Interconnect over Frame Relay). The ATM network must be sending and
receiving Ethernet encapsulated frames as defined by RFC 2684 (Multiprotocol Encapsulation over
AAL5). One side of the epipe has either a Frame Relay or ATM SAP, the other an Ethernet SAP. Any
VLAN tags in the encapsulated frames are passed transparently as they would be for a null SAP.
Module 2 Page 67
Ethernet Interworking VPWS
IP Interworking VPWS (Ipipes)
Ipipe is a point-to-point Ethernet interworking VPWS that supports

interconnection between hosts that are attached to different pointto-point access circuits on either end of a pseudowire
Only IP traffic can be transported over an ipipe

Ipipe is useful for network migration purposes
Module 2 |
68
Ipipe is a point-to-point Ethernet interworking VPWS that supports interconnection between hosts that are
attached to different point-to-point access circuits on either end of a pseudowire.
Ipipe supports interconnection between:
ATM - using RFC 2684 routed encapsulation.
Frame Relay - using RFC 2427 routed encapsulation.
point-to-point protocol (PPP) - using IPCP encapsulation as defined in RFC 1332
Ethernet - using null, dot1Q or Q-in-Q encapsulation
Cisco HDLC - routed encapsulation
The difference between Ethernet interworking VPWS and an IP interworking VPWS (ipipe) is that the
former supports bridged encapsulation and the latter supports routed encapsulation. Ipipes provide a
routed interworking service. We say routed because the encapsulated data are Layer 3 (IP) packets
instead of the Layer 2 frames. They are not truly routed, since the ipipe is a point-to-point service.
Ipipe is useful for network migration purposes; for example, in the interim step during ATM/Frame Relay
network to Ethernet network migration, where ATM/Frame Relay equipment uses routed IP encapsulation.
Module 2 Page 68
Ipipe provides a routed interworking service
Module 2 |
69
The ipipe shown in the figure is configured with a Frame Relay SAP on PE1 and a dot1Q encapsulated
SAP configured on PE2. Both PE devices must also know the IP address of the local and remote CE
devices. On PE1, for example, the SAP is configured with the address of the local CE device, and the
spoke SDP is configured with the address of the remote CE. PE2 is configured in a similar manner. When
the service is brought up, PE 2 broadcasts an ARP request on the local LAN for the MAC address of the
CE device. The two PE routers are now able to exchange encapsulated IP packets over the ipipe between
the two CE devices.
Any protocol that runs over IP can also run over the ipipe. OSPF, RIP, BGP sessions can be established
between two CEs connected by an ipipe. IS-IS does not run over IP; we cannot establish IS-IS
adjacencies between the two CEs over an ipipe.
Module 2 Page 69
IP Packet Transport Through an Ipipe
Module Summary
Alcatel-Lucent supports epipe, apipe, fpipe, cpipe and ipipe as
VPWS applications
Ethernet SAP encapsulation types are null, dot1q, and qinq
For null encapsulation, the service is delimited by the port
In dot1q encapsulation, the service is delimited by the VLAN tag

In qinq encapsulation, the service is delimited by two VLAN tags
Null SAP and default SAP are mutually exclusive on a port
On the 7750 SR, VLAN tags are stripped at the SAP ingress by default
Module 2 |
70
Module 2 Page 70
Service MTU defines the maximum customer payload that can be carried in
a VPN service
SAP MTU is changed by changing the port MTU
The SDP path MTU defines the maximum payload size that can be carried by
a service using that SDP
Network port MTU >= SDP path-MTU + transport tunnel encapsulation

overhead
Fpipe provides a point-to-point Frame Relay service between users

connected to 7750SR nodes on the IP/MPLS network
Apipe provides a point-to-point ATM service between users connected to

7750 SR routers on an IP/MPLS network
Module 2 |
71
Module 2 Page 71
Cpipes are an implementation of TDM pseudowires to transport T1 or E1

circuits
The Alcatel-Lucent VPWS offers network interworking for Ethernet, ATM and
Frame Relay across a common IP/MPLS network
FRF.5 defines a standard method for encapsulating and transporting Frame

Relay frames over an ATM network
The Ethernet interworking VPWS provides a point-to-point Ethernet VPWS

between Frame-Relay-attached users, ATM-attached users and Ethernetattached users across an IP/MPLS packet-switched network
Ipipe provides a routed interworking service
Module 2 |
72
Module 2 Page 72
Learning Assessment
1. Which VPWS emulates a point-to-point TDM circuit?
2. What is the purpose of using a VLAN tag?
3. Verify whether the following statement is true or false: Multiple
SAPs can be defined on a single port for different services
5. What is the default service MTU value for an Ethernet VPN service
such as an epipe?
6. What is the relationship between the network port MTU and the SDP
path MTU?
7. What are the two modes of operation supported on Alcatel-Lucent
7750 SR for an apipe service?
Module 2 |
73
1. Which VPWS emulates a point-to-point TDM circuit?

Cpipe service emulates a point-to-point TDM circuit
2. What is the purpose of using VLAN tag?
VLAN tag is used to determine to which service the frame belongs
3. Verify whether the following statement is true or false: Multiple SAPs can be defined on a single port for
different services.
True
4. What frames will a dot1q null sap receive?
A dot 1q null sap receives all untagged frames and all frames with a VLAN tag of 0
5. What is the default service MTU value for an Ethernet VPN service such as an epipe?
An Ethernet VPN service, such as an epipe service, has a default service MTU of 1514 bytes
6. What is the relationship between the network port MTU and the SDP path MTU?
Network port MTU >= SDP path MTU + transport tunnel encapsulation overhead
7. What are the two modes of operation supported on Alcatel-Lucent 7750 SR for an apipe service?
The two modes of operation supported on the Alcatel-Lucent 7750 SR for ATM apipes are the N:1 cell
mode and AAL5 frame mode.
Module 2 Page 73
4. What frames will a dot1q null sap receive?
Module 2 |
74
Module 3 Introduction to Virtual Private LAN Service (VPLS)
Module 3 Page 1
Module Objectives
Explain the operation of Virtual Private LAN Service (VPLS)
Explain how VPLS emulates a virtual Ethernet switch through

its MAC learning and flooding behavior
Compare VPLS topologies (full mesh, hub and spoke,
hierarchical VPLS, and spoke termination in a VPLS)
Module 3 |
Module 3 Page 2
Module 3 Introduction to VPLS
Section 1 VPLS Operation
Module 3 Page 3
Section Objectives
Define a VPLS and list its features
Explain the similarities and differences between epipe and VPLS
List the advantages of a VPLS from the perspective of both the

customer and service provider
Explain VPLS flooding behavior
Identify the difference between mesh SDP and spoke SDP
Describe the MAC learning process in VPLS
Module 3 |
Module 3 Page 4
VPLS is an Ethernet service that connects multiple sites in a single switched

domain over the provider-managed IP/MPLS network
VPLS is essentially an enhancement of the VPWS
Multiple VPLS services can be deployed using the same IP/MPLS core
Module 3 |
A VPLS is a multipoint Layer 2 service that allows multiple customer sites to be connected in a single
bridged domain contained within a provider-managed IP/MPLS network. Customer sites in the VPLS
appear to be on the same LAN, even if the sites are geographically-dispersed. VPLS characteristics are
described in RFC 4665 (Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks)
and RFC 4762 (Virtual Private LAN Service Using LDP Signaling)
VPLS is essentially an enhancement of the Ethernet pseudowire service, or Virtual Private Wire Service
(VPWS) to a multipoint service.
As discussed in Module 1, the advantages of a VPLS from the customers perspective are:
To the customer it appears as if all sites are connected to a single switched Ethernet network.
The VPLS is transparent to the customers data and higher layer protocols.
The VPLS can operate over a single local site or at multiple, geographically-dispersed sites.
The VPLS performs MAC learning so that frames are forwarded only across the required links in the
network.
The advantages of a VPLS for the service provider are:
Only the PE devices require configuration for the VPLS service.
There is a clear demarcation of functionality between the service provider and customer networks.
Scalability the provider can support thousands of customers per router.
Flexibility many different services for many different customers can be provided over a single core
IP/MPLS network.
The service provider can apply QoS, billing, ingress/egress traffic shaping and policing on a per service
basis
Module 3 Page 5
VPLS Overview
VPLS vs. Epipe
Encapsulation and transport mechanism
The signaling of transport and service labels
The SAP encapsulation types: null, dot1Q and Q-in-Q
The treatment of customer data at the SAP
Differences:
A VPLS is a multipoint service; epipe is a point-to-point service
The VPLS appears as a single switched LAN to the customer; the epipe appears as a
direct Ethernet connection
A VPLS performs MAC learning to build a forwarding database (FDB) containing the
addresses of customer-attached devices
Module 3 |
The similarities between an epipe and a VPLS are

They both use the same encapsulation and transport mechanism: an MPLS or GRE encapsulated packet
with an inner service label.
The signaling of transport and service labels is the same: LDP or RSVP-TE for transport labels and TLDP for service labels.
The SAP encapsulation types of null, dot1Q and Q-in-Q are the same for a VPLS as for an epipe.
The treatment of customer data at the SAP is the same in a VPLS as in an epipe
The differences between an epipe and a VPLS service are:
A VPLS is a multipoint service instead of the point-to-point service of an epipe.
The VPLS appears as a single switched LAN to the customer, whereas the epipe appears as a direct
Ethernet connection.
A VPLS performs MAC (Media Access Control) learning to build a forwarding database (FDB) containing
the addresses of customer-attached devices. The VPLS uses the FDB for intelligent forwarding of
customer traffic over the IP/MPLS core network.
Like other pseudowire services, a VPLS can be local (multiple sites connected to a single PE) or
distributed (multiple sites connected to multiple PEs).
Module 3 Page 6
Similarities:
VPLS: Customer Operation

Customers maintain complete control over routing
Module 3 |
VPLS 1 and VPLS 2 can use the same IP address ranges due to a VPN functionality provided with the
VPLS service.
Note: since VPLS is a Layer 2 service, the customer site router interfaces that connect to the VPLS must
belong to the same subnet. From the customers perspective, the routers are logically connected by a
Layer 2 Ethernet switch.
Module 3 Page 7
Adding new sites requires minimal reconfiguration at existing sites
All PE routers in the VPLS are T-LDP peers and exchange labels for the service
The VC-ID configured for the service must match among targeted LDP peers
Customer frames are encapsulated with a service label and a transport label
The VPLS instance on each PE router is often referred to as a virtual switch (VS)
PE 1->PE 2: For VC ID 101 Use VC-label 131071

Module 3 |
For the transport of customer data, the VPLS acts as if it were a full mesh of epipes between all the PEs in
the service.
Note: there is only a single T-LDP session required between two routers to signal service labels,
regardless of the number of services that exist between them. For example, even if there were 100 VPLS
or epipe services between PE 1 and PE 2, only a single T-LDP session would exist. The T-LDP session is
used to negotiate service labels for all 100 services.
Note: if the VC IDs do not match point-to-point, the service label will not be present; therefore, the service
will not be accessible on the remote router.
The VPLS instance on each PE router is often referred to as a virtual switch (VS) since it emulates the
behavior of an Ethernet switch.
Module 3 Page 8
VPLS Label Signaling
VPLS connects the customers multiple locations like a virtual Ethernet switch
All SAPs belong to the same broadcast domain in a VPLS, regardless of the VLAN tags
Module 3 |
The PE routers must support all classical Ethernet features, such as MAC learning, packet replication
and forwarding. The PE routers learn the source MAC addresses of the traffic arriving on their access and
network ports. From a functional point of view, this means that the PEs must implement a switch for each
VPLS instance; this is often called a virtual switch, or VS for short.
The VS functionality is implemented in the PE through a forwarding data base (FDB) for each VPLS
instance; this FDB is populated with all the learned MAC addresses. All traffic is switched based on MAC
addresses and forwarded between all participating PE routers using the LSP tunnels.
By default, packets with an unknown destination are replicated and forwarded on all LSPs to the PE
routers participating in that service. This is done until the target station responds and the MAC address is
learned by the PE routers associated with that service. Packet destinations may be unknown when, for
example, the destination MAC address has not been learned.
One significant difference between the VPLS and an Ethernet switch is that the VPLS joins any VLANs
used for service delimiting tags. On an Ethernet switch, VLAN tags create separate broadcast domains.
However, in a VPLS, all SAPs belong to the same broadcast domain, regardless of the VLAN tags. The
figure shows six different tag values that are used at the six different sites. Since service delimiting tags
are stripped at ingress, they are effectively invisible to the VPLS, and the VLANs are joined. If it is
desirable to maintain VLAN tags, the SAPs can be defined using a null encapsulation.
Module 3 Page 9
Virtual Switch (VS) Functionality
VPLS Flooding Behavior
Module 3 |
10
Because a VPLS provides multipoint connectivity, traffic entering the service must be appropriately
replicated to the other locations. As in an Ethernet switch, known unicast traffic is sent only to the
destination. The figure shows an Ethernet frame arriving at PE4. The FDB on PE4 contains the destination
MAC address of the frame and thus can forward the encapsulated frame to PE3. The FDB on PE3 also
contains the destination MAC so PE3 forwards the frame out the appropriate SAP.
Module 3 Page 10
Known unicast traffic is sent to the destination
Traffic to multicast, broadcast or unknown unicast addresses is flooded to all local

SAPs and remote PEs in the service
In a basic VPLS, the SDP is bound to the service as a mesh SDP
Mesh SDP floods frames received from a SAP or from a spoke SDP, but does not flood
frames received from another mesh SDP
Mesh SDPs prevent loops
Module 3 |
11
On an Ethernet switch, traffic to multicast, broadcast or unknown unicast addresses is flooded to all ports.
A VPLS also floods such traffic to all SAPs in the service.
When an SDP is bound to a service, it is bound as either a spoke SDP or a mesh SDP. The type of SDP
indicates how flooded traffic is transmitted.
All mesh SDPs bound to a service are logically treated as a single bridge port for flooded traffic; flooded
traffic received on any mesh SDP on the service is replicated to other ports (spoke SDPs and SAPs) and
is not transmitted on any mesh SDPs.
In the figure, PE3 forwards the frame it receives only to the SAPs and not on the SDP to PE1 or PE2. In a
basic VPLS such as this one, the SDP is bound to the service as a mesh SDP. In a VPWS, the SDP is
bound as a spoke SDP. The only difference between the two is their flooding behavior.
A basic VPLS is configured with a full mesh of mesh SDPs between all the PE routers in the service.
Module 3 Page 11
VPLS Flooding Behavior (continued)
VPLS Flooding Behavior (continued)
Module 3 |
12
A spoke SDP is treated as the equivalent of a traditional bridge port where flooded traffic received on the
spoke SDP is replicated on to all other ports and not transmitted on the port it was received from. Other
ports include other spoke SDPs and mesh SDPs or SAPs.
In the figure shown, the service is now configured with spoke SDPs between the routers. PE 4 forwards
the frame it received from the SAP to PE2 and PE3. PE3 forwards the frame it receives from PE1 to the
SAPs and on the SDP to PE1. PE2 also does the same; it forwards the frame to the SAPs and on the SDP
to PE1 resulting in unwanted and uncontrolled flooding of frames in the VPLS.
Mesh SDPs ensure that all PE devices receive the frame without looping or duplication of frames. In
section 3 we describe some specific situations where spoke SDPs are used in a VPLS.
Module 3 Page 12
Spoke SDP floods frames received from a SAP, spoke SDP or mesh
SDP
VPLS Flooding Behavior Frame Received on a SAP
Module 3 |
13
The figure shows a VPLS service on one PE. It has two SAPs on the local PE and four SDPs that lead to
other PE devices. A frame received on one SAP and destined to a broadcast, multicast or unknown
address must be flooded through the VPLS. It is transmitted on the other SAP, the two mesh SDPs and
the two spoke SDPs. The frame is not transmitted on the port it was received from.
Module 3 Page 13
A frame received on one SAP to be flooded through the VPLS is

transmitted on the other SAPs, mesh SDPs and the spoke SDPs
VPLS Flooding Behavior Frame Received on a Spoke SDP
Module 3 |
14
The figure shows a frame received on a spoke SDP to be flooded through the VPLS, transmitted on both
SAPs, the other spoke SDP and both mesh SDPs
Module 3 Page 14
A frame received on a spoke SDP to be flooded through the VPLS is

transmitted on the SAPs, the other spoke SDPs and the mesh SDPs
VPLS Flooding Behavior Frame Received on a Mesh SDP
Module 3 |
15
The figure shows a frame received on a mesh SDP to be flooded through the VPLS, transmitted on both
SAPs, both spoke SDPs, but not the other mesh SDP
Module 3 Page 15
A frame received on a mesh SDP to be flooded through the VPLS is

transmitted on the SAPs and the other spoke SDPs, but not the other
mesh SDPs
MAC Learning in a VPLS
Module 3 |
16
The VPLS learns the MAC addresses of the customers attached devices in the same manner as an
Ethernet switch. The learned addresses are stored in a forwarding database (FDB) kept on each PE
device.
The PE maintains a separate FDB for every VPLS service configured on the router. The figure shows the
two FDBs maintained on PE1 for two different VPLS services.
Module 3 Page 16
The learned MAC addresses are stored in a forwarding database

(FDB) kept on each PE device
PE2 receives a frame from M2 destined to M1
The frame is flooded because M1 is an unknown address
All PE routers in the VPLS have learned M2s address
Module 3 |
17
The figure shows the transmission of a customer frame across a VPLS to see how the PE routers learn
MAC addresses. When PE2 receives a frame from M2 destined to M1, it is flooded because M1 is an
unknown address. Afterwards, all PE routers in the VPLS have learned M2s address.
The step-by-step process is as follows:
M2 transmits a unicast Ethernet frame destined to M1 that is received at the SAP on PE-2.
PE-2 learns the location of M2 on the SAP from the source address in the received frame and updates
its FDB with M2s MAC address.
Because M1s address (the destination address) is unknown, PE-2 floods the frame to both SDPs in
the service.
PE-1 and PE-3 both receive the frame and learn the location of M2 as being on the SDP to PE-2 and
update their FDBs with M2s MAC address.
Since the destination address is unknown to PE-1 and PE-3, they both flood the frame out their local
SAPs. The frame arrives at the customer device, M1.
Module 3 Page 17
Example of MAC Learning in a VPLS
M1 sends a frame to M2, the frame is sent directly to PE2
Once the frame arrives at M2, both PE1 and PE2 have learned M1s MAC address and
have it in their FDBs
PE3 does not learn the MAC address of M1
Module 3 |
18
M1 next sends a frame to M2. Since M2 is now known in the FDB, the frame does not have to be flooded
and can be sent directly to PE2. Once the frame arrives at M2, both PE1 and PE-2 have learned M1s
MAC address and have it in their FDBs
The step-by-step process is as follows:
M1 transmits a frame with M2 as the destination. The frame arrives at the SAP on PE1.
PE1 has the MAC address for M2 in its FDB and knows to transmit the frame on the SDP to PE2. PE1
learns the location of M1 from the source address in the frame and updates its FDB.
PE2 has the MAC address for M2 in its FDB and knows to transmit the frame out the SAP. PE2 learns
the location of M1 from the source address in the frame and updates its FDB. The frame arrives at the
destination, M2.
After the transmission from M1 to M2, both PE1 and PE2 have an entry for M1 in their FDB. Since the
frame from M1 was not flooded in the VPLS, PE3 does not have M1 in its FDB. If it receives a frame
destined for M1 it will be flooded in the VPLS by PE3.
Note: if M2 is to send a frame to M1, the flow of the frame will be from M2 to PE2, PE2 to PE1, and PE1
will only send it over SAP 1/1/1 to M1. The frame will not be sent over SAP 1/1/2 as in the previous
slide.
Module 3 Page 18
Example of MAC Learning in a VPLS (continued)
Section 2 VPLS Configuration and Verification
Module 3 Page 19
Section Objectives
Identify the steps to configure a VPLS
Module 3 |
20
Complete Lab 3 Configuring a VPLS
Module 3 Page 20
Infrastructure Configuration
Configure IP interfaces and an IGP for basic routing in the core
network
Configure MPLS interfaces and LSPs. Either LDP or a full mesh of
RSVP-TE LSPs between all PE routers is required
Module 3 |
21
As for any other VPN service, the following must be done before provisioning a VPLS service on the
Alcatel-Lucent 7750 SR:
IGP configuration - OSPF is used in this case study
IGP convergence (routing tables have system addresses)
Enable signaling of transport labels with LDP or RSVP
Enable LDP for dynamic signaling of service labels using T-LDP
Create path (if using RSVP) RSVP is used in this case study and a loose path is created
Create LSP and bind path (if using RSVP) full mesh of RSVP-TE LSP has been created
Create SDP and bind SDP to LSP (if using RSVP or select LDP)
Change customer-facing ports to access mode and change encapsulation as required Null
encapsulation is used here
Create VPLS service
Add SAPs to service
Add SDPs to service with VC ID
Module 3 Page 21
Configure a full mesh of SDPs between all PE routers
IP Interfaces and an IGP Configuration / Verification
*A:PE-1# show router route-table

===============================================================================
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Metric
------------------------------------------------------------------------------10.1.2.0/27
Local
Local
04d23h51m
0
to-PE2
0
10.1.3.0/27
Local
Local
04d23h51m
0
to-PE3
0
10.2.4.0/27
Remote OSPF
04d23h36m
10
10.1.2.2
200
10.3.4.0/27
Remote OSPF
04d23h35m
10
10.1.3.3
200
10.10.10.1/32
Local
Local
22d18h14m
0
system
0
10.10.10.2/32
Remote OSPF
04d23h36m
10
10.1.2.2
100
10.10.10.3/32
Remote OSPF
04d23h36m
10
10.1.3.3
100
10.10.10.4/32
Remote OSPF
04d23h36m
10
10.1.2.2
200
------------------------------------------------------------------------------No. of Routes: 8
Module 3 |
22
---------------------------------------------traffic-engineering
area 0.0.0.0
interface "system"
exit
interface "to-PE2"
exit
interface "to-PE3"
exit
exit
----------------------------------------------
A single area OSPF with traffic engineering enabled is configured on the PE routers.
Module 3 Page 22
MPLS Configuration / Verification
*A:PE-1# show router mpls lsp

===============================================================================
MPLS LSPs (Originating)
===============================================================================
LSP Name
To
Fastfail
Adm
Opr
Config
------------------------------------------------------------------------------to-PE2
10.10.10.2
No
Up
Up
to-PE3
10.10.10.3
No
Up
Up
to-PE4
10.10.10.4
No
Up
Up
------------------------------------------------------------------------------LSPs : 3
Module 3 |
23
A full mesh of RSVP-TE LSPs are configured on the PE routers. The configuration on PE1 is shown.
Module 3 Page 23
*A:PE-1>config>router>mpls# info
---------------------------------interface "system"
exit
interface "to-PE2"
exit
interface "to-PE3"
exit
path "loose"
no shutdown
exit
lsp "to-PE2"
to 10.10.10.2
primary "loose"
exit
no shutdown
exit
lsp "to-PE3"
to 10.10.10.3
primary "loose"
exit
no shutdown
exit
lsp "to-PE4"
to 10.10.10.4
primary "loose"
exit
no shutdown
exit
no shutdown
-------------------------------
SDPs Configuration

==============================================================================
==============================================================================
SdpId
Adm Opr
Deliver
Signal
-----------------------------------------------------------------------------2
0
9190
10.10.10.2
Up
Up
MPLS
TLDP
3
0
9190
10.10.10.3
Up
Up
MPLS
TLDP
4
0
9190
10.10.10.4
Up
Up
MPLS
TLDP
-----------------------------------------------------------------------------Number of SDPs : 3
------------------------------------------------------------------------------
Module 3 |
24
*A:PE-1>config>service# info
-----------------------------------------customer 1 create
description "Default customer"
exit
customer 1000 create
description "VPLS_Customer"
exit
sdp 2 mpls create
far-end 10.10.10.2
lsp "to-PE2"
keep-alive
shutdown
exit
no shutdown
exit
sdp 3 mpls create
far-end 10.10.10.3
lsp "to-PE3"
keep-alive
shutdown
exit
no shutdown
exit
sdp 4 mpls create
far-end 10.10.10.4
lsp "to-PE4"
keep-alive
shutdown
exit
no shutdown
exit
A full mesh of MPLS encapsulated SDPs are configured as shown.

Note: we have also created customer 1000 as our VPLS customer.
Module 3 Page 24
VPLS Configuration
Steps to configure a VPLS Service:
Configure the customer-facing ports as access ports
Create the VPLS service on each of the PE routers
Add the appropriate customer-facing SAPs
Verify that the service is operationally up on all PEs
Verify connectivity through the service by pinging between the
customer devices
Module 3 |
25
At this point the infrastructure configuration for the IP/MPLS network is completed, and we are ready to
configure the VPLS service. The steps shown in the slides are required for a successful VPLS
configuration.
Note: it is possible to have VPLS topologies that don't have a full mesh; these topologies will be covered
in the following section.
Module 3 Page 25
Add a full mesh of SDP bindings between the PEs
Create the VPLS Service and Bind the SDPs
*A:PE-1# configure service vpls 1000 customer 1000 create

*A:PE-1>config>service>vpls$ mesh-sdp 2 create
*A:PE-1>config>service>vpls>mesh-sdp$ exit
*A:PE-1>config>service>vpls# mesh-sdp 3 create
*A:PE-1>config>service>vpls# mesh-sdp 4 create
*A:PE-1>config>service>vpls# no shutdown
*A:PE-1>config>service>vpls# info
-----------------------------------stp
shutdown
exit
mesh-sdp 2:1000 create
exit
exit
exit
no shutdown
Module 3 |
26
Notice that the customer facing ports on PE1 and PE2 have been configured as access ports with null
encapsulation. Any encapsulation supported for an epipe is possible in a VPLS. Recall that the port MTU
changes to 1514 when it is configured as an access port.
The creation of the VPLS and the binding of the SDPs to the service is shown on PE1. Similar
configuration is required on all participating PEs. The mesh SDPs are used to create a loop-free core for
the VPLS.
Unlike binding a spoke SDP to a service where we need to specify the VC-ID, when binding the mesh
SDP to the VPLS service, the VC-ID is not specified, by default it uses the def-mesh-vc-id as the VC-ID.
Since the def-mesh-vc-id is the service ID by default, so the VC-ID in this case will be equal to 1000. All
mesh SDPs within a single service will use the same VC-ID.
To change the default mesh VC ID, use the following command:
*A:PE-1>config>service# vpls 1000 def-mesh-vc-id
- def-mesh-vc-id <vc-id>
- no def-mesh-vc-id [<vc-id>]
<vc-id>
: [1..4294967295]
This might be required if there are two different VPLS service IDs configured that require a mesh SDP
between them.
Module 3 Page 26
For a mesh SDP, the VC ID takes on the value of the service ID by

default
*A:PE-1# configure service vpls 1000
Create the VPLS Service and Bind the SDPs (continued)

VPLS configuration and SDP bindings on all participating PE routers

-----------------------------------stp
shutdown
exit
exit
exit
exit
no shutdown
------------------------------------

------------------------------------stp
shutdown
exit
exit
exit
exit
no shutdown
-------------------------------------
Module 3 |
27
A full mesh of SDPs is required for the VPLS. The VPLS ID is the same in all four PEs. All mesh SDPs
use the same VC ID. A mesh SDP must be established in both directions before it becomes operational.
The configuration shown is on PE1 and PE2. The configuration PE3 and PE4 are similar as shown below:
------------------------------------- ------------------------------------stp
stp
shutdown
shutdown
exit
exit
exit
exit
exit
exit
exit
exit
no shutdown
no shutdown
Module 3 Page 27
Verify the Mesh SDPs

The mesh SDPs are operationally up
*A:PE-3# show service id 1000 sdp

=============================================================================
=============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
----------------------------------------------------------------------------1:1000
Mesh 10.10.10.1
Up
Up
131068
131067
2:1000
Mesh 10.10.10.2
Up
Up
131065
131064
4:1000
Mesh 10.10.10.4
Up
Up
131067
131067
-----------------------------------------------------------------------------Number of SDPs : 3
*A:PE-1# show service id 1000 sdp

=============================================================================
=============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
----------------------------------------------------------------------------2:1000
Mesh 10.10.10.2
Up
Up
131068
131068
3:1000
Mesh 10.10.10.3
Up
Up
131067
131068
4:1000
Mesh 10.10.10.4
Up
Up
131063
131065
----------------------------------------------------------------------------Number of SDPs : 3
Module 3 |
28
After the VPLS 1000 is configured on the other PE routers and the service is bound to the SDPs, the PEs
have signaled a label for VC-ID 1000, which creates an ingress and an egress service label binding.
A VC label will only be signaled when a service is bound to a SDP. For example, if we shutdown the mesh
SDP binding on PE-2 towards PE-1.
*A:PE-2>config>service>vpls# mesh-sdp 1 shutdown
We notice that PE-1 does not have an egress VC label, and the flag for the SDP shows NoEgrVCLabel
because there has been no label signaled by PE-2.
*A:PE-1# show service id 1000 sdp 2
===============================================================================
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------2:1000
Mesh 10.10.10.2
Up
Down
131068
0
===============================================================================
*A:PE-1# show service id 1000 sdp 2 detail
===============================================================================
Service Destination Point (Sdp Id : 2) Details
===============================================================================
Sdp Id 2:1000 -(10.10.10.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 2:1000
Type
: Mesh
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 9190
Far End
: 10.10.10.2
Delivery
: MPLS
Ingress Label
: 131068
Egress Label
: 0
Flags
: NoEgrVCLabel
Module 3 Page 28
An ingress and an egress service label have been signaled
---------------------------------stp
shutdown
exit
sap 1/1/4 create
exit
exit
exit
exit
no shutdown
---------------------------------
---------------------------------------stp
shutdown
exit
sap 1/1/4 create
exit
exit
exit
exit
no shutdown
---------------------------------------
Module 3 |
29
With null encapsulation there can only be one SAP ID associated with the port.
The slide shows that the customer-facing ports on PE1 and PE2 (port 1/1/4), which has been configured
as an access port, is now added to the service as sap 1/1/4.
Module 3 Page 29
Bind the SAPs to the VPLS Service
Verify the VPLS Service
Module 3 |
30

===============================================================================
===============================================================================
Service Id
: 1000
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1000
Last Mgmt Change : 02/21/2012 16:40:17
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 1000
SAP Count
: 1
SDP Bind Count
: 3
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4
null
1514
1514
Up
Up
sdp:2:1000 M(10.10.10.2)
Mesh
0
9190
Up
Up
sdp:3:1000 M(10.10.10.3)
Mesh
0
9190
Up
Up
sdp:4:1000 M(10.10.10.4)
Mesh
0
9190
Up
Up
===============================================================================
Once the service is configured on the other PE devices, the VPLS is operationally up.
Module 3 Page 30
*A:CE1>config>router# ping 192.168.1.2

64 bytes from 192.168.1.2: icmp_seq=1 ttl=64
time=7.20ms.
time=2.34ms.
time=2.88ms.
time=2.34ms.
time=2.32ms.
Module 3 |
31
Once the VPLS is up, we should be able to ping through the service from devices in the CE network.
Module 3 Page 31
Verify the VPLS Service (continued)
*A:CE1# show router arp

==============================================================
ARP Table (Router: Base)
==============================================================
IP Address
MAC Address
Expiry
Type
Interface
-------------------------------------------------------------192.168.1.1
60:24:01:01:00:03 00h00m00s Oth[I] to-CE2
192.168.1.2
60:25:01:01:00:03 03h47m15s Dyn[I] to-CE2
-------------------------------------------------------------*A:PE-1# show service fdb-mac
===============================================================================
Service Forwarding Database
===============================================================================
ServId
MAC
Source-Identifier
Type
Last Change
Age
------------------------------------------------------------------------------1000
60:24:01:01:00:03 sap:1/1/4
L/0
02/22/2012 14:50:33
1000
60:25:01:01:00:03 sdp:2:1000
L/900 02/22/2012 14:35:21
------------------------------------------------------------------------------No. of Entries: 2
Module 3 |
32
The ARP table for CE1 is shown. Each CE routers ARP table only dynamically learns ARP entries for the
far-end CE routers interface connected to the service. This is logical because the CE routers are not
aware of any details of the service providers network, rather, the CE routers appear to be directly
connected by a single Ethernet switch.
After the ping we see that PE1 has learned the MAC addresses for CE1 and CE2 and stored them in its
FDB. PE1 knows that it reaches one device through SAP 1/1/4 and the other through SDP 2. similarly,
PE2 knows that it reaches one device through SAP 1/1/4 and the other through SDP 1 as shown below:
*A:PE-2# show service fdb-mac
===============================================================================
===============================================================================
ServId
MAC
Source-Identifier
Type
Last Change
Age
------------------------------------------------------------------------------1000
60:24:01:01:00:03 sdp:1:1000
L/30
02/22/2012 14:29:03
1000
60:25:01:01:00:03 sap:1/1/4
L/30
02/22/2012 14:54:53
-------------------------------------------------------------------------------
When CE1 pings CE2 router interface 192.168.1.2, it first sends an ARP request to learn the destination
MAC address to use for the Ethernet frame. The ARP request has a broadcast destination MAC address,
and therefore PE1 floods it to all the mesh SDPs. When PE2 receives the ARP from the mesh SDP, it only
floods it to the SAP towards CE-2 because traffic received from one mesh SDP is not sent to another
mesh SDP binding. Because CE2 has an interface with address 192.168.1.2 it responds to the ARP
message.
After the ARP exchange, the MAC address of CE1 interface to PE1 and CE2 interface to PE2 are known
on PE1 and PE2, but not on PE3 or PE4.
From this point on, all communication between CE1 and CE2 is done using the SDPs and LSPs between
PE1 and PE2. PE3 and PE4 are not used for communication.
Module 3 Page 32

===============================================================================
===============================================================================
ServId
MAC
Source-Identifier
Type
Last Change
Age
------------------------------------------------------------------------------1000
60:24:01:01:00:03 sdp:1:1000
L/0
02/22/2012 15:43:24
------------------------------------------------------------------------------No. of Entries: 1
-------------------------------------------------------------------------------

===============================================================================
===============================================================================
ServId
MAC
Source-Identifier
Type
Last Change
Age
------------------------------------------------------------------------------1000
60:24:01:01:00:03 sdp:1:1000
L/0
02/22/2012 15:33:36
------------------------------------------------------------------------------No. of Entries: 1
-------------------------------------------------------------------------------
Module 3 |
33
PE3 and PE4 have only a single entry for the source MAC address for CE1 interface to PE1. This MAC
address was learned from the original ARP request broadcast by CE1 to find the MAC address of CE2
interface to PE2.
Module 3 Page 33
Traffic received from one mesh SDP is not sent to another meshSDP binding
Lab 3 Configuring a VPLS

Configure and verify a VPLS service
Explore some of the different possibilities for SAP encapsulation
Module 3 |
34
Module 3 Page 34
Section 3 VPLS Network Topologies
Module 3 Page 35
Section Objectives
Explain the operation of a hub and spoke VPLS
Explain the operation of a hierarchical VPLS
Explain the operation of a spoke termination on a VPLS
Configure and verify a spoke SDP termination on a VPLS
Complete Lab 4 Spoke Termination to a VPLS
Module 3 |
36
Module 3 Page 36
Fully Meshed VPLS

Fully meshed VPLS is a simple and reliable approach to provision a
VPLS
Module 3 |
37
A VPLS can span a single router or multiple routers. On a VPLS that spans a single router, subscriber
data is distributed through multiple service access points (SAPs) on the router. A VPLS on a single router
does not require a service distribution path (SDP).
On a VPLS that spans multiple sites, customer data enters the service using at least one SAP on each
router. Data is transported among the routers through service tunnels over an IP/MPLS provider core
network. Core VPLS networks are typically fully meshed using mesh SDPs, which means that there is an
SDP binding from every router to every other service-aware router. No Layer 2 loops are present.
So far, the VPLS topologies we have seen in the previous sections use fully meshed topology. This is a
simple and reliable approach to provisioning a VPLS. However, there are circumstances where other,
more complex topologies are preferred. These topologies are introduced in the following slides.
Module 3 Page 37
Traffic flows through a central location (hub)
Spoke SDP removes the full mesh requirement
Module 3 |
38
A hub and spoke topology can be deployed when it is necessary to have traffic flowing through a central
location (hub). This might be to implement security policies or packet filtering, deep packet inspection or
some other constraint of the physical topology.
Broadcast traffic or traffic destined to unknown MAC addresses between PE B and PE C will flow as
follows:
When the traffic arrives on SAP 1/2/1 of PE B it will be flooded out of the spoke SDP towards PE A. PE A
will flood the traffic out of SAP 1/1/1 and the spoke SDP towards PE C. When the traffic arrives at PE C,
the traffic will be flooded out of 1/1/1. As the traffic traverses, the FDB will be populated based on the
source MAC address. There is no longer a requirement for an SDP between PE B and PE C because of
the flooding rules that apply to a spoke SDP. In the topology in this slide, PE B and PE C will associate all
remote MAC addresses with the spoke SDP going towards PE A. All traffic between PE B and PE C will
traverse PE A.
Note: if a spoke SDP was configured between PE B and PE C, there would be a loop on the VPLS
service. In this case, spanning tree has to be enabled. Spanning tree is covered in the Alcatel-Lucent
VPLS course.
Module 3 Page 38
Hub and Spoke Topology (Spoke SDP)
Enables VPLS services to span multiple metro networks
Creates scalable VPLS
A spoke SDP is used to connect smaller meshed VPLSs
Module 3 |
39
H-VPLS enables VPLS services to span multiple metro networks, as shown in the diagram in this slide.
This architecture minimizes the signaling overhead and avoids the use of a full mesh of tunnels and LSPs
between the two metro networks.
The scalability of a VPLS can be improved by joining together smaller meshed VPLSs with spoke SDPs.
The number of SDPs required for a fully meshed VPLS is n * (n - 1) , where n is the number of PE routers
participating in the service. Also, the addition of a new router in a fully meshed VPLS means that an SDP
must be configured on every router in the network to the new router.
The figure shows two metro networks that contain four fully meshed routers. If we join these two networks
using fully meshed VPLS, then we need 8*7 = 56 SDP. However, if we use spoke SDP to join them, then
we will only need 2* (3*4) = 24 SDPs plus another two spoke SDPs.
A spoke connection is used to connect each VPLS service between the two metros. In a simple scenario,
all of the VPLS services could be carried on a single tunnel LSP.
Frames from PE C within metro B destined for PE A of metro A will have three different service labels. It
will traverse a mesh SDP towards PE B, then follow the spoke SDP to metro A arriving at PE C. PE C will
then deliver the frame to PE A using a mesh SDP.
Module 3 Page 39
Hierarchical VPLS (H-VPLS)
Spoke SDP Termination on VPWS
Module 3 |
40
Using a spoke SDP reduces the number of SDPs required and simplifies the addition of new routers.
Traffic to be terminated on a given VPLS service is identified by the VC label present in the service packet,
as if it was connected to another VPLS service spoke SDP.
Module 3 Page 40
Connects a spoke SDP of a VPLS service with an epipe service
The VC-ID of the spoke SDPs on the epipe service and the VPLS service must match
VC-ID (100) does not have to match the service ID of either the epipe or the VPLS
The service MTU of the VPLS and epipe service must match
Module 3 |
41
The VC-ID of the spoke SDPs on the epipe service and the VPLS service must match. Recall that the VCID has point-to-point significance. Also note that the VC-ID (100) does not have to match the service ID of
either the epipe or the VPLS as long as both ends are the same.
Module 3 Page 41
Spoke SDP Termination on VPWS (continued)

-----------------------------------sap 1/1/4 create
exit
exit
no shutdown
------------------------------------
Spoke SDP Termination on VPWS Configuration
*A:PE-2>config>service# vpls 1000

----------------------------------stp
shutdown
exit
sap 1/1/4 create
exit
exit
exit
exit
no shutdown
------------------------------------
Module 3 |
42
Module 3 Page 42
Spoke SDP Termination on VPWS Verification

Verify the epipe service is operationally up

===============================================================================
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Mgmt Change : 02/23/2012 13:11:39
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4
null
1514
1514
Up
Up
sdp:2:100 S(10.10.10.2)
Spok
0
9190
Up
Up
===============================================================================
Module 3 |
43
The epipe service on PE1 and the spoke SDP are operationally up.
Module 3 Page 43
Spoke SDP Termination on VPWS Verification (continued)

Verify the VPLS is operationally up

===============================================================================
===============================================================================
Service Id
: 1000
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1000
Last Mgmt Change : 02/23/2012 12:04:08
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 1000
SAP Count
: 1
SDP Bind Count
: 3
Per Svc Hashing
: Disabled
Def. Gateway IP
: None
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4
null
1514
1514
Up
Up
sdp:1:100 S(10.10.10.1)
Spok
0
9190
Up
Up
sdp:3:1000 M(10.10.10.3)
Mesh
0
9190
Up
Up
sdp:4:1000 M(10.10.10.4)
Mesh
0
9190
Up
Up
===============================================================================
Module 3 |
44
The VPLS on PE2 and spoke SDP bindings are operationally up.
Module 3 Page 44

The CE devices can successfully communicate with each other
ttl=64
ttl=64
ttl=64
ttl=64
ttl=64
time=6.62ms.
time=2.27ms.
time=2.25ms.
time=2.94ms.
time=2.28ms.
*A:CE1# ping 192.168.1.2

round-trip min = 2.25ms, avg = 3.27ms, max = 6.62ms, stddev =
1.69ms
Module 3 |
45
Module 3 Page 45

Verify the FDB
*A:PE-1# show service id 50 fdb detail

MINOR: CLI Forwarding databases do not exist
for this service type.
*A:PE-1#

===============================================================================
Forwarding Database, Service 1000
===============================================================================
ServId
MAC
Source-Identifier
Type
Last Change
Age
------------------------------------------------------------------------------1000
60:24:01:01:00:03 sdp:1:100
L/0
02/23/2012 13:16:29
1000
60:25:01:01:00:03 sap:1/1/4
L/0
02/23/2012 13:16:29
------------------------------------------------------------------------------No. of MAC Entries: 2
------------------------------------------------------------------------------Legend: L=Learned; P=MAC is protected
Module 3 |
46
On PE2, the MAC address of CE2 is learned from SAP 1/1/4 and the MAC address of CE1 is learned from
an SDP binding. Note that it makes no difference whether the MAC is learned from a spoke terminating in
another VPLS or in an epipe. Both cases represent a simple pseudowire between the PE routers, and the
MAC is learned from the pseudowire.
A MAC FDB does not exist for the epipe service even when it is terminated on a VPLS. Traffic that enters
SAP 1/1/4 of the epipe is simply forwarded over the spoke SDP to PE2 and traffic received from the spoke
SDP is forwarded to the SAP and on to CE1.
Module 3 Page 46

*A:PE-1>config>service>epipe# no spoke-sdp 2:100
*A:PE-1>config>service>epipe>spoke-sdp$ exit
*A:PE-1>config>service>epipe#info
---------------------------------------------sap 1/1/4 create
exit
exit
no shutdown

==============================================================================
==============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Admin State
: Up
Oper State
: Down
MTU
: 1514
Service Access & Destination Points

-----------------------------------------------------------------------------Identifier
Type
-----------------------------------------------------------------------------sap:1/1/4
null
1514
1514
Up
Up
sdp:2:50 S(10.10.10.2)
Spok
0
9190
Up
Down
Module 3 |
47
In the configuration shown, we have changed the VC-ID of the spoke SDP of the epipe service to 50. The
VPLS spoke SDP VC-ID remains the same (100).
Note: the epipe service is now operationally down because of the VC-ID mismatch.
The error flag for the SDP shows NoEgrVCLabel.
*A:PE-1# show service id 50 sdp detail
===============================================================================
Services: Service Destination Points Details
===============================================================================
Sdp Id 2:50 -(10.10.10.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 2:50
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 9190
Far End
: 10.10.10.2
Delivery
: MPLS
Hash Label
: Disabled
Admin State
: Up
Oper State
: Down
Acct. Pol
: None
Collect Stats
: Disabled
Ingress Label
: 131068
Egress Label
: 0
Last Status Change : 01/30/2012 16:55:09

Signaling
: TLDP
Last Mgmt Change
: 02/23/2012 13:37:55
Force Vlan-Vc
: Disabled
Endpoint
: N/A
Precedence
: 4
Class Fwding State : Down
Flags
: NoEgrVCLabel
Peer Pw Bits
: None
Peer Fault Ip
: None
Module 3 Page 47
Spoke SDP Termination on VPWS VC-ID Mismatch

===============================================================================
===============================================================================
Service Id
: 1000
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1000
Last Mgmt Change : 04/18/2012 14:08:48
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 1000
SAP Count
: 1
SDP Bind Count
: 4
Per Svc Hashing
: Disabled
Def. Gateway IP
: None
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4
null
1514
1514
Up
Up
sdp:1:100 S(10.10.10.1)
Spok
0
9190
Up
Down
sdp:3:1000 M(10.10.10.3)
Mesh
0
9190
Up
Up
sdp:4:1000 M(10.10.10.4)
Mesh
0
9190
Up
Up
===============================================================================
Module 3 |
48
The output shows that the VPLS service is still operationally up, however, the spoke SDP binding to the epipe service
is down.
The error flag for the SDP shows NoEgrVCLabel.
===============================================================================
===============================================================================
Sdp Id 1:100
-(10.10.10.1)
------------------------------------------------------------------------------Description
SDP Id
Spoke Descr
: (Not Specified)
: 1:100
Type
: Spoke
: (Not Specified)
Split Horiz Grp
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 9190
Far End
: 10.10.10.1
Delivery
: MPLS
Hash Label
: Disabled
Admin State
: Up
Oper State
: Down
Acct. Pol
: None
Collect Stats
: Disabled
Ingress Label
: 131070
Egress Label
: 0
Signaling
: TLDP
Retries Left
: 3
Last Status Change : 04/18/2012 14:12:03
Flags
: NoEgrVCLabel
Time to RetryReset : never
Module 3 Page 48
Spoke SDP Termination on VPWS VC-ID Mismatch (continued)

*A:PE-1>config>service>epipe# no spoke-sdp 2:50
*A:PE-1>config>service>epipe>spoke-sdp$ back
*A:PE-1>config>service>epipe# service-mtu 1500
---------------------------------------------service-mtu 1500
sap 1/1/4 create
exit
exit
no shutdown
----------------------------------------------

==============================================================================
==============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Admin State
: Up
Oper State
: Down
MTU
: 1500

-----------------------------------------------------------------------------Identifier
Type
-----------------------------------------------------------------------------sap:1/1/4
null
1514
1514
Up
Up
sdp:2:100 S(10.10.10.2)
Spok
0
9190
Up
Down
Module 3 |
49
In the configuration shown, we have changed the VC-ID of the spoke SDP of the epipe service back to 100, however
we have changed the service MTU to be 1500 bytes. The VPLS spoke SDP VC-ID and service MTU remain the
same.
Note: the epipe service is now operationally down because of the service MTU mismatch.
The error flag for the SDP shows ServiceMTUMismatch.
*A:PE-1# show service id 50 sdp 2 detail
===============================================================================
Service Destination Point (Sdp Id : 2) Details
===============================================================================
Sdp Id 2:100 -(10.10.10.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 2:100
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 9190
Far End
: 10.10.10.2
Delivery
: MPLS
Hash Label
: Disabled
Admin State
Acct. Pol
Ingress Label
Last Status Change

Last Mgmt Change
Endpoint
Class Fwding State
Flags
Peer Pw Bits
: Up
: None
: 131062
Oper State
Collect Stats
Egress Label
: Down
: Disabled
: 131068
:
:
:
:
:
:
Signaling
Force Vlan-Vc
Precedence
: TLDP
: Disabled
: 4
02/23/2012 13:42:05
02/23/2012 13:42:05
N/A
Down
ServiceMTUMismatch
pwNotForwarding
Module 3 Page 49
Spoke SDP Termination on VPWS MTU Mismatch
Module Summary
VPLS is a class of VPN that allows the connection of multiple
sites in a single-bridged domain over a provider-managed
IP/MPLS network
VPLS emulates a virtual Ethernet switch, in particular its MAC
learning and flooding behavior
VPLS uses T-LDP for signaling service labels

By default, the VC ID equals the service ID in mesh SDP
A VPLS can span a single router or multiple routers
Spoke SDPs and mesh SDPs can be used together to form
hierarchical VPLS topologies
Module 3 |
50
Module 3 Page 50
Module Summary (Continued)

Hub and spoke topologies utilize spoke SDP in a single site to
enforce policy
Module 3 |
51
VPLS can be joined to an epipe service using spoke SDP

termination
Module 3 Page 51
Learning Assessment
1. How many SDPs must be configured for local VPLS?
2. What is the difference in behavior of an Ethernet switch
and a VPLS?
4. Verify whether the following statement is true or false:
Using spoke SDPs in a VPLS removes the requirement for a
full mesh of SDP bindings.
5. Which signaling protocol is used to create the following:
a. The inner label of a label stack in a VPLS application?
b. The outer label of a label stack in a VPLS application?
Module 3 |
52
1. How many SDPs must be configured for local VPLS?

None; SDPs are only used with distributed VPLS.
2. What is the difference in behavior between an Ethernet switch and a VPLS?.
The VPLS merges all SAPs into a common broadcast domain regardless of the VLAN tags. An
Ethernet switch uses VLAN tags to create separate broadcast domains
3. Describe how a VPLS populates the MAC FDB?
The VPLS performs MAC learning by checking the source address of received frames. It associates
this address with the SAP or SDP on which the frame arrived.
4. Verify whether the following statement is true or false: Using spoke SDPs in a VPLS removes the
requirement for a full mesh of SDP bindings
True, spoke SDPs remove the need for a full mesh since traffic is forwarded from spoke SDPs to other
spoke and mesh SDPs. However, this behavior can lead to loops in the network. A mixture of spoke
and mesh SDPs are often used in a VPLS and MAC learning is performed on both types
5. Which signaling protocol is used to create the following:
a) The inner label of a label stack in a VPLS application?
T-LDP
b) The outer label of a label stack in a VPLS application?
LDP, RSVP and GRE
Module 3 Page 52
3. Describe how a VPLS populates the MAC FDB.
Lab 4 Spoke Termination to a VPLS

Configure and verify spoke termination to a VPLS
Module 3 |
53
Module 3 Page 53
Module 3 |
54
Module 4 OAM Tools and Mirroring Service
Module 4 Page 1
Module Objectives
Identify reasons to use mirroring service and differentiate

between local and distributed mirror service
Configure and verify the operation of a local and remote
mirror service
Module 4 |

Module 4 Page 2
Use the correct operations, administration and maintenance

(OAM) tools to analyze, manage and troubleshoot IP/MPLS
service networks
Module 4 OAM Tools and Mirroring

Service
Section 1 Operations, Administration and Maintenance (OAM)
Module 4 Page 3
Section Objectives
Provide an overview of OAM tools
Utilize the tools available for managing and troubleshooting a

service network ( lsp-ping, lsp-trace, SDP-ping, SDP-MTU, SVC-ping)
Complete Lab 5 OAM tools
Module 4 |
Module 4 Page 4
OAM Overview
Delivery of services requires a number of operations to occur
properly and at different levels in the service delivery model
OAM diagnostics tools supplement the basic IP ping and traceroute

operations with diagnostics specialized for the different levels in the
service delivery model
OAM packets closely resemble customer packets to effectively test
the customer's forwarding path
OAM packets are kept within the service provider's network and are
not forwarded to the customer
Module 4 |
Traditionally, ICMP ping has been commonly used to troubleshoot IP based networks. However, as an
MPLS core network has different behavior, ICMP ping will not be able to fully troubleshoot MPLS
networks. ICMP ping has some shortcomings, such as the inability to detect MPLS data plane failure if the
IP layer is working properly.
Proper delivery of services requires a number of operations to occur properly and at different levels in the
service delivery model. For example, operations such as the association of packets to a service, service
labels to a service and each service to a service tunnel must be performed properly in the forwarding
plane for the service to function properly. In order to verify that a service is operational, a set of in-band,
packet-based OAM tools is required, with the ability to test each of the individual packet operations.
For in-band testing, the OAM packets closely resemble customer packets to effectively test the customer's
forwarding path, but are distinguishable from customer packets so they are kept within the service
provider's network and not forwarded to the customer.
The 7750 SR OS suite of OAM diagnostics supplement the basic IP ping and traceroute operations with
diagnostics specialized for the different levels in the service delivery model. There are diagnostics for
MPLS LSPs, SDPs, Services and VPLS MACs within a service.
Module 4 Page 5
A set of packet-based OAM tools are used to verify that a service is

operational
OAM Tools
OAM tools are useful in managing and troubleshooting a network
MPLS paths diagnostic tools:
SDP diagnostic tools:

sdp-ping and sdp-mtu
Service diagnostic tools:
svc-ping
Module 4 |
Operations, administration and maintenance (OAM) tools available in modern routers are useful to
manage and troubleshoot the network.
The OAM tools that will be covered in this section are:
lsp-ping and lsp-trace - These allow the network operator to diagnose and discover the condition of
MPLS paths in the network.
sdp-ping and sdp-mtu - These allow the network operator to diagnose and discover details about a
configured SDP, including path MTU.
svc-ping - This tools allows the network operator to diagnose a configured service and the SDP bindings
for the service at both the local and remote ends.
lsp-ping and lsp-trace are defined in RFC 4379 and can inter-operate with other vendors equipment.
sdp-ping and svc-ping are tools proprietary to the Alcatel-Lucent 7750 SR.
Module 4 Page 6
lsp-ping and lsp-trace
Isp-ping and lsp-trace

Used on either LDP or RSVP-TE LSPs to verify the data path for the
LSP
Modeled after the ICMP echo request/reply used by ping and
traceroute to detect and localize faults in IP networks
LSP-ping verifies whether the packet reaches the egress label edge
router (LER) for a given FEC
For LSP traceroute, the packet is sent to the control plane of each
transit-label-switched router (LSR)
Module 4 |
The 7750SR LSP diagnostics are implementations of LSP ping and LSP traceroute based on RFC
4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures.
When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane.
For the MPLS data plane verification, the IP data plane verification tools (ping and traceroute) are
extended to work on the MPLS networks. The lsp Ping/traceroute, modeled after the ping/traceroute
paradigm: ping is used for connectivity verifications, and traceroute is used for hop-by-hop
fault localization and path tracing.
LSP ping and LSP traceroute provide diagnostics and troubleshooting capabilities for MPLS LSPs. These
tools provide basic building blocks for the MPLS OAM capabilities. This enables verification of the MPLS
data plane consistency.
The basic idea behind lsp-ping and lsp-trace tests is to verify that packets that belong to a particular
Forwarding Equivalence Class (FEC) actually end their MPLS path on a label switching router (LSR) that
is an egress for that FEC. These tests are carried out by sending a packet (OAM or MPLS echo request
packet) along the same data path as other packets belonging to this FEC. An MPLS echo request also
carries information about the FEC whose MPLS path is being verified. This echo request is forwarded just
like any other packet belonging to that FEC. In "ping" mode (basic connectivity check), the packet should
reach the end of the path, at which point it is sent to the control plane of the egress LSR, which then
verifies whether it is indeed an egress for the FEC. In traceroute mode (fault isolation), the packet is sent
to the control plane of each transit LSR, which performs various checks that it is indeed a transit LSR for
this path; this LSR also returns further information that helps check the control plane against the data
plane. For example, that the forwarding matches what the routing protocols determined as the path.
Module 4 Page 7
A UDP packet is MPLS-encapsulated and transmitted along the LSP
lsp-ping and lsp-trace Operation

The MPLS echo request packet is sent to a target router through the use of the appropriate label
stack associated with the LSP to be validated
The destination IP address of the MPLS echo request packet is defined as a 127.x.y.z/8 address
The 127.x.y.z/8 address prevents the IP packet from being IP switched to its destination if the LSP
is broken
LSP-ping/traceroute uses the same label stack as is used by the LSP, which causes the echo to be
switched inband of LSP
An MPLS echo reply is sent in response to an MPLS echo request. The reply is sent as an IP packet
and it may not take the same path used by the LSP
LSP-ping/traceroute only verifies the LSP paths in one direction; it does not verify the LSP return
path
Module 4 |
LSP ping needs to diagnose situations where the control and data planes are out of sync. It performs this by routing
an MPLS echo request packet based solely on its label stack. That is, the IP destination address is never used in a
forwarding decision. In fact, the sender of an MPLS echo request packet may not know, a priori, the address of the
router at the end of the LSP.
The MPLS echo request packet is sent to a target router through the use of the appropriate label stack associated
with the LSP to be validated. Use of the label stack causes the packet to be forwarded over the LSP itself.
For the LSP ping/trace packet to be treated as a control packet, the same label stack is used as is used by the LSP,
which causes the echo to be switched in-band of the LSP tested. The destination of the echo request is a 127.x.y.z/8
address and not the same as the one used for selecting the LSP.
Any router using the 127/8 address for forwarding (because of a broken LSP) punts the packet for local processing,
for example: the packet will not be forwarded naturally and is sent to the switch CPU for process switching. 127/8 also
forces the packet to be processed by the route processor (RP) at the egress router for a given LSP. The 127.x.y.z/8
address prevents the IP packet from being IP switched to its destination if the LSP is broken.
LSP Ping/traceroute uses the same label stack as is used by the LSP, which causes the echo to be switched in-band
of LSP.
An MPLS echo reply is sent in response to an MPLS echo request. The reply is sent as an IP packet and it is
forwarded using IP, MPLS, or a combination of both types of switching. The source address of the MPLS echo reply
packet is an address obtained from the router generating the echo reply. The destination address is the source
address of the router that originated the MPLS echo request packet.
An echo reply, which may or not be labeled, has the same outgoing interface IP address as the source. The
destination IP address and port are copied from the source address and port of the echo request. The echo reply can
thus take an MPLS or an IP path to return to the source router. LSP Ping/Traceroute verifies only the LSP paths in
one direction and not the LSP return path.
Module 4 Page 8
lsp-ping and lsp-trace for LDP
*A:PE-3# oam lsp-ping prefix 10.10.10.4/32

LSP-PING 10.10.10.4/32: 80 bytes MPLS payload
Seq=1, send from intf to-PE1, reply from 10.10.10.4
udp-data-len=32 ttl=255 rtt=1.81ms rc=3 (EgressRtr)
*A:PE-3# oam lsp-trace prefix 10.10.10.4/32 detail

lsp-trace to 10.10.10.4/32: 0 hops min, 0 hops max, 104 byte
packets
1 10.10.10.1 rtt=1.11ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 10.1.2.2 MRU=1500 label=131066 proto=3(LDP)
3 10.10.10.4 rtt=1.73ms rc=3(EgressRtr)
Module 4 |
The figure shows the network topology used to demonstrate the use of lsp-ping and lsp-trace. The default
metric in this network is 100 and the link between PE3 and PE4 has been set to 1000 to force traffic on a
specific LSP. The default port MTU is 9212, but this has been set to 1514 on the link between PE1 and
PE2.
Notice that Maximum Receivable Unit (MRU) is the biggest packet size that a router can receive and
forward downstream without fragmentation.
LDP is configured on all router
*A:PE-3# show router ldp peer
===============================================================================
LDP Peers
===============================================================================
Peer
Adm
Opr
Hello
Hold
KA
KA
Passive
Auto
Factor
Time
Factor
Timeout
Mode
Created
------------------------------------------------------------------------------10.10.10.1
Up
Up
45
40
Disabled
Yes
10.10.10.2
Up
Up
45
40
Disabled
Yes
10.10.10.4
Up
Up
45
40
Disabled
Yes
------------------------------------------------------------------------------No. of Peers: 3
Module 4 Page 9
---- LSP 10.10.10.4/32 PING Statistics ---1 packets sent, 1 packets received, 0.00% packet loss
lsp-ping and lsp-trace for RSVP-TE LSP
*A:PE-3# oam lsp-ping "to-PE2"

LSP-PING to-PE2: 92 bytes MPLS payload
Seq=1, send from intf to-PE1, reply from 10.10.10.2
udp-data-len=32 ttl=255 rtt=1.84ms rc=3 (EgressRtr)
*A:PE-3# oam lsp-trace "to-PE2" detail

lsp-trace to to-PE2: 0 hops min, 0 hops max, 116 byte packets
DS 1: IfAddr 10.1.2.2 MRU=1500 label=131063 proto=4(RSVP-TE)
Module 4 |
10
The use of lsp-ping and lsp-trace is similar for RSVP-TE, although the LSP is specified by name. An LSP
is configured from PE3 to PE2 using a loose path, since the metric value on the link between PE3 and
PE4 is high, the path for this LSP will be via PE1 as shown below:
===============================================================================

------------------------------------------------------------------------------LSP Name
: to-PE2
Path LSP ID : 17922
From
: 10.10.10.3
To
: 10.10.10.2
Adm State
: Up
Oper State : Up
Path Name
: loose
Path Type
: Primary
Path Admin : Up
Path Oper
: Up
OutInterface: 1/1/3
Out Label
: 131066
Oper MTU
: 1500
Neg MTU
: 1500
Adaptive
: Enabled
Oper Metric : 200
ExplicitHops:
No Hops Specified
Actual Hops :
10.1.3.3(10.10.10.3)
Record Label
: N/A
-> 10.1.3.1(10.10.10.1)
Record Label
: 131066
-> 10.1.2.2(10.10.10.2)
Record Label
: 131063
ResigEligib*: False
Module 4 Page 10
---- LSP to-PE2 PING Statistics ---1 packets sent, 1 packets received, 0.00% packet loss
lsp-ping and lsp-trace Testing the Path MTU
*A:PE-3# oam lsp-trace prefix 10.10.10.4/32 size 1497 detail

lsp-trace to 10.10.10.4/32: 0 hops min, 0 hops max, 1497 byte
packets
2 0.0.0.0 *
3 0.0.0.0 *
4 0.0.0.0 *
5 0.0.0.0 *
6 0.0.0.0 *
*A:PE-3# oam lsp-ping prefix 10.10.10.4/32 size 1497

LSP-PING 10.10.10.4/32: 1497 bytes MPLS payload
Request timed out.
---- LSP 10.10.10.4/32 PING Statistics ---1 packets sent, 0 packets received, 100.00% packet loss
Module 4 |
11
lsp-ping can be used for measuring the round trip time for a specific forwarding class, or testing the path
MTU. The size of the MPLS payload can be specified as a parameter and used to determine the effective
MTU of the path.
In the above network, since the PE1-PE2 link has a port MTU of 1514, the maximum MPLS payload that
can be accommodated is 1496 bytes (1514 14 bytes Ethernet header 4 bytes MPLS label).
Note: if fast reroute is used then you need to consider another 4 bytes for that, therefore the MTU value
would be 1492 bytes
Module 4 Page 11
*A:PE-3# oam lsp-trace prefix 10.10.10.4/32 size 1496 detail

lsp-trace to 10.10.10.4/32: 0 hops min, 0 hops max, 1496 byte packets
SDP-ping and SDP-MTU

sdp-ping performs in-band unidirectional or round-trip connectivity
tests on SDPs
Unidirectional sdp-ping
The remote SDP is not specified
The remote SDP is specified
sdp-mtu enables the service provider to get the actual path MTU
supported between the service ingress and service termination
points
Module 4 |
12
sdp-ping performs in-band unidirectional or round-trip connectivity tests on SDPs. The SDP ping OAM
packets are sent in-band in the tunnel encapsulation, so they will follow the same path as traffic within the
service. The SDP ping response can be received out-of-band in the control plane, or in-band using the
data plane for a round-trip test.
A Unidirectional test requires egress SDP ID and tests ability to reach the far-end IP address of the SDP
within the SDP encapsulation. A bi-directional test requires a local egress SDP ID and a remote SDP ID
and tests the remote SDP encapsulation.
The path MTU discovery tool provides a powerful tool that enables the service provider to get the exact
MTU supported between the service ingress and service termination points (accurate to one byte).
Module 4 Page 12
Bi-directional sdp-ping
SDP-ping
*A:PE-3# oam sdp-ping 4

Err SDP-ID Info
Local
Remote
-------------------------------------------------SDP-ID:
4
N/A
Administrative State:
Up
N/A
Operative State:
Up
N/A
Path MTU:
9190
N/A
Response SDP Used:
No
IP Interface State:
Up
Actual IP Address:
10.10.10.3
10.10.10.4
Expected Peer IP:
10.10.10.4
10.10.10.3
Forwarding Class
be
be
Profile
Out
Out
Request Result: Sent - Reply Received
RTT: 1.61(ms)
*A:PE-3# oam sdp-ping 4 resp-sdp 3

Err SDP-ID Info
Local
Remote
-------------------------------------------------SDP-ID:
4
3
Administrative State:
Up
Up
Operative State:
Up
Up
Path MTU:
9190
N/A
Response SDP Used:
Yes
IP Interface State:
Up
Actual IP Address:
10.10.10.3
10.10.10.4
Expected Peer IP:
10.10.10.4
10.10.10.3
Forwarding Class
be
be
Profile
Out
Out
RTT: 1.70(ms)
Module 4 |
13
The figure shows a network topology with an SDP configured between PE3 and PE4. The SDP IDs at PE3
and PE4 are 4 and 3 respectively. The metric for the link between PE3 and PE4 has been set to 1000 to
force traffic on a specific LSP. The default port MTU is 9212, but this has been set to 1514 on the link
between PE1 and PE2.
Note: the SDP has a path MTU of 9190 (9212 14 4 4) even though the link between PE1 and PE2
has an MTU value of 1514. As described in Module 2, the path MTU is set based on the network port MTU
unless adspec is configured on the RSVP-TE LSP.

------------------------------------------------------------------------------LSP Name
: to-PE4
Path LSP ID : 52240
From
: 10.10.10.3
To
: 10.10.10.4
Adm State
: Up
Oper State : Up
Path Name
: loose
Path Type
: Primary
Path Admin : Up
Path Oper
: Up
OutInterface: 1/1/3
Out Label
: 131070
Record Route: Record

Record Label: Record
Oper MTU
: 9198
Neg MTU
: 9198
Actual Hops :
10.1.3.3(10.10.10.3)
Record Label
: N/A
-> 10.1.3.1(10.10.10.1)
Record Label
: 131070
-> 10.1.2.2(10.10.10.2)
Record Label
: 131065
-> 10.2.4.4(10.10.10.4)
Record Label
: 131070
ResigEligib*: False
LastResignal: n/a
CSPF Metric : 0
===============================================================================
Module 4 Page 13
*A:PE-3# show service sdp 4

==============================================================================
==============================================================================
SdpId
Adm Opr
Deliver
Signal
-----------------------------------------------------------------------------4
0
9190
10.10.10.4
Up
Up
MPLS
TLDP
==============================================================================
SDP-MTU

Size Sent Response
---------------------------1450 .
Success
1460 .
Success
1470 .
Success
1480 .
Success
1490 .
Success
1500 ...
Request Timeout

Size Sent Response
---------------------------1490 .
Success
1491 .
Success
1492 .
Success
1493 ...
Request Timeout
Module 4 |
14
The sdp-mtu command can be used to find the actual path MTU of the SDP as shown. The value of 1492
is as expected and is calculated as (1514 - 8 - 14 = 1492).
Note: the path MTU is 4 bytes less than the MTU discovered using lsp-ping in slide 11. This is because
lsp-ping uses only a single MPLS label, while sdp-mtu uses both the service and transport label.
Module 4 Page 14
Used to find the actual path MTU of the SDP
SVC-ping
Provides end-to-end connectivity testing for an individual service
Service ping operates at a higher level than the SDP diagnostics
Alcatel-Lucents implementation functions for both GRE and MPLS tunnels

and tests the following from edge-to-edge:
Tunnel connectivity
VC label mapping verification
Service existence
Service provisioned parameter verification
Round-trip path verification
Service dynamic configuration verification
Module 4 |
15
svc-ping verifies the correct configuration of a service and can help verify any miss-configuration.
Service ping is initiated from a 7750 SR router to verify round-trip connectivity and delay to the far-end of
the service. Transport tunnels can run svc-ping on a continuous basis to monitor the health of the tunnel
and optionally notify the operator of a connectivity issue.
Module 4 Page 15
It verifies an individual service and not the collection of services carried

within an SDP
SVC-ping Parameters
svc-ping is configured using the following command:
The parameter local-sdp specifies that the ping should be sent to the far-end in-band
using the SDP
The parameter remote-sdp specifies that the return ping should be sent in-band
Module 4 |
16
The parameter local-sdp specifies that the ping should be sent to the far end in-band using the SDP, and
the parameter remote-sdp specifies that the return ping should be sent in-band.
If local-sdp / remote-sdp parameters are not specified the ping is sent out of band.
Module 4 Page 16
oam svc-ping <ip-address> service <service-id> [local-sdp] [remote-sdp]
Example of svc-ping
This example specifies local-sdp, and the output shows that the SDP was not used by
the remote end
Err Info
Local
Remote
---------------------------------------------------Type:
EPIPE
EPIPE
Admin State:
Up
Up
Oper State:
Up
Up
Service-MTU:
1514
1514
Customer ID:
1
1
IP Interface State: Up
Actual IP Addr:
10.10.10.3
10.10.10.4
Expected Peer IP:
10.10.10.4
10.10.10.3
SDP Path Used:
Yes
No
SDP-ID:
4
3
Admin State:
Up
Up
Operative State:
Up
Up
Binding Admin State:Up
Up
Binding Oper State: Up
Up
Binding VC ID:
100
100
Binding Type:
Spoke
Spoke
Binding Vc-type:
Ether
Ether
Binding Vlan-vc-tag:N/A
N/A
Egress Label:
131062
131062
Ingress Label:
131062
131062
Egress Label Type: Signaled
Signaled
Ingress Label Type: Signaled
Signaled
Module 4 |
17
The slide shows an example of svc-ping for the configured epipe 100. This example specifies local-sdp,
and the output shows that the SDP was not used by the remote end.
Module 4 Page 17
*A:PE-3# oam svc-ping 10.10.10.4 service 100 local-sdp

Service-ID: 100
Example of svc-ping (continued)
The local-sdp and the remote-sdp are specified, and the output shows that the SDP
was used by the remote end
The svc-ping output shows the service MTU as the configured value for the epipe
Err Info
Local
Remote
----------------------------------------------------Type:
EPIPE
EPIPE
Admin State:
Up
Up
Oper State:
Up
Up
Service-MTU:
1514
1514
Customer ID:
1
1
IP Interface State: Up
Actual IP Addr:
10.10.10.3
10.10.10.4
Expected Peer IP:
10.10.10.4
10.10.10.3
SDP Path Used:
Yes
Yes
SDP-ID:
4
3
Admin State:
Up
Up
Operative State:
Up
Up
Binding Admin State:Up
Up
Binding Oper State: Up
Up
Binding VC ID:
100
100
Binding Type:
Spoke
Spoke
Binding Vc-type:
Ether
Ether
Binding Vlan-vc-tag:N/A
N/A
Egress Label:
131062
Ingress Label:
131062
Egress Label Type: Signaled
Ingress Label Type: Signaled
131062
131062
Signaled
Signaled
Module 4 |
18
The slide shows another example of svc-ping for the configured epipe 100. The localsdp and the remote-sdp are specified and the output shows that the SDP was used by
the remote end.
Note: the output shows the service MTU as the configured value for the epipe. There is
no verification by svc-ping that the service is actually able to transport a payload of this
size. The sdp-mtu command in slide 14 shows that the effective path MTU for this
service is actually 1492 bytes.
===============================================================================
===============================================================================
Service Id
: 100
Vpn Id
: 0
Service Type
: Epipe
Admin State
: Up
Oper State
: Up
MTU
: 1514

------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/1
null
1514
1514
Up
Up
sdp:4:100 S(10.10.10.4)
Spok
0
9190
Up
Up
===============================================================================
Module 4 Page 18
*A:PE-3# oam svc-ping 10.10.10.4 service 100 local-sdp remote-sdp

Service-ID: 100
Lab 5 OAM tools
In this lab you will

Explore OAM commands using the epipe service
Explore the MTU issues related to a Layer 2 service
Module 4 |
19
Module 4 Page 19
Module 4 OAM Tools and Mirroring

Service
Section 2 Mirroring Service
Module 4 Page 20
Section Objectives
Describe mirroring service
Differentiate between local and distributed mirror service
Configure and verify the operation of a local and remote mirror

service
Complete Lab 6 Mirror Service
Module 4 |
21
Module 4 Page 21
Mirroring Service Overview

Port-mirroring: traditional routers and switches allow the operator
to replicate traffic received or sent on one port to be replicated on
another
The mirror source can be a port, SAP, MPLS label, IP filter or
MAC filter
The replicated traffic can be sent to a destination on the local
router or through an SDP to a remote location
Mirror source: The source of the traffic on a specific point to be
mirrored
Mirror destination: The location to which mirrored traffic is sent
Module 4 |
22
When troubleshooting complex operational problems, customer packets can be examined as they traverse
the network. One way to accomplish this is with an overlay of network analyzers, together with skilled
technicians operating them to decode the data provided. This method of traffic-mirroring often requires
setting up complex filters in multiple switches and/or routers. At best, these switches and routers are only
able to mirror from one port to another on the same device.
Alcatel-Lucent mirroring service extends and integrates these capabilities into the network and provides
significant operational benefits. Each device can mirror packets from a specific service to any destination
point in the network, regardless of interface type or speed.
While some Layer 3 switches and routers can mirror on a per-port basis within the device, the AlcatelLucent 7750 SR provides a similar feature with much more powerful capabilities.
The mirror source can not only be a port, but other service entities such as a SAP, MPLS label, IP filter or
MAC filter.
The replicated traffic can not only be sent to a destination on the local switch, but also through an SDP to
a remote location.
Original packets are forwarded, while a copy is sent from the mirrored port to the mirroring (destination)
port.
Mirroring service allows an operator to see the actual traffic on a customers service with a sniffer sitting
in a central location. In many cases, this reduces the need for a separate, costly overlay sniffer network.
The mirrored frame size that is transmitted to the mirror destination can be explicitly configured using
slicing features. This enables mirroring only the parts needed for analysis. For example, only the headers
can be copied for analysis, protecting the integrity and security of customer data, or conversely, copying
the full packet, including customer data.
Module 4 Page 22
The Alcatel-Lucent 7750 SR provides more powerful capabilities:
The mirror source and mirror destination are on the same device
The mirror destination is created first, as a mirror service
The mirror service includes a SAP that identifies where the traffic is replicated
If a dot1Q encapsulation is used, the same physical port can be used for multiple
distinct service destinations
The mirror source can be a port, SAP, IP filter, MAC filter, or ingress label
Module 4 |
23
Mirror destinations can terminate on egress virtual ports, which allows multiple mirror destinations to send
to the same packet decode device, delimited by IEEE 802.1Q (Dot1q) tags. This is helpful when
troubleshooting a multi-port issue within the network.
Mirror sources can be ports in either access or network mode. On a 7750 SR Port, mirroring is supported
in the following combinations:
Port Type
Port Mode
Port Encap Type
faste/gige/xgige
access
dot1q, null
faste/gige/xgige
network
dot1q, null
Module 4 Page 23
Local Mirror Service
Local Mirror Configuration

Configuration requirements:
Mirror destination parameters:
A mirror destination ID
A mirror destination SAP
A mirror source ID, which is the same as the mirror destination service
ID
At least one source type specified (port, SAP, IP filter, MAC filter, or
ingress label)
Module 4 |
24
The configure mirror mirror-dest command is used to specify where the mirrored traffic should be sent.
*A:PE-1# configure mirror mirror-dest
- mirror-dest <service-id> [create] [type <encap-type>]
- no mirror-dest <service-id>
<service-id>
: [1..2147483648]|<svc-name:64 char max>
<create>
: keyword - mandatory while creating an entry.
<encap-type>
: ether|frame-relay|ppp|ip-only|atm-sdu|satop-e1|satopt1|cesopsn|cesopsn-cas
The debug mirror-source command is used as traffic selection criteria to identify traffic that is to be
mirrored at the source.
*A:PE-1# debug mirror-source
- mirror-source <service-id>
- no mirror-source <service-id>
<service-id>
: [1..2147483648]|<svc-name:64 char max>
Module 4 Page 24
Mirror source parameters:
The mirror destination is configured on SAP 1/1/2
The mirror source is configured on SAP 1/1/4 of the epipe to mirror both ingress and
egress traffic
*A:PE-1# configure mirror mirror-dest 99

*A:PE-1>config>mirror>mirror-dest# info
---------------------------------------------sap 1/1/2 create
exit
no shutdown
----------------------------------------------
*A:PE-1# debug mirror-source

*A:PE-1>debug>mirror-source#
Module 4 |
99
sap 1/1/4 ingress egress
no shutdown
exit
25
The diagram in this slide displays a sample configuration of a local mirror service where the source and destinations
are on the same device (PE1).
An epipe service is configured between PE1 and PE2, the mirror destination is configured on SAP 1/1/2, while the
mirror source is configured on SAP 1/1/4 of the epipe to mirror both ingress and egress traffic to the destination.
The service destination is created using the configure mirror mirror-dest <service-id> create command.
The mirror source is configured using the debug mirror-source command.
A packet sniffer is attached to port 1/1/2 of PE1. The mirrored traffic is transmitted on this port and received by the
sniffer.
When PE1 gets traffic from CE1, it sends it to PE-2 and replicates it out of SAP 1/1/2 towards the sniffer.
In this example, we configure a router with an IP filter on a local epipe SAP to emulate the sniffer. The filter captures
traffic sent to the IP address of the far end router. The filter configuration is shown later.
The epipe is operationally up as shown below:
===============================================================================
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
Admin State
: Up
Oper State
: Up
MTU
: 1514

------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4
null
1514
1514
Up
Up
sdp:2:50 S(10.10.10.2)
Spok
0
9190
Up
Up
===============================================================================
Module 4 Page 25
Example of Local Mirror Configuration
Example of Local Mirror Configuration (continued)
The mirror service can be verified using the following commands:
*A:PE-1# show mirror mirror-dest

===============================================================================
Mirror Services
===============================================================================
Id
Type
Adm
Opr
Destination
SDP Lbl/
Slice
SAP QoS
------------------------------------------------------------------------------99
Ether Up
Up
SAP 1/1/2
1
0
===============================================================================
*A:PE-1# show service service-using mirror

===============================================================================
Services [mirror]
===============================================================================
ServiceId Type
------------------------------------------------------------------------------99
Mirror
Up
Up
1
-------------------------------------------------------------------------------
Module 4 |
26
A mirror source can only have one destination.

If a mirrored destination service ID is shut down, the corresponding mirror source is put into an operational
down mode.
The default state for a mirror destination is shutdown, while the default state for a mirror source is noshutdown.
Module 4 Page 26
Creating a sniffer using IP filter on an epipe SAP configuration
*A:Sniffer>config>filter# info
----------------------------------------log 111 create
destination memory 100
exit
ip-filter 11 create
entry 10 create
match
dst-ip 192.168.1.0/27
exit
log 111
action forward
exit
exit
-----------------------------------------
Module 4 |
*A:Sniffer>config>service>epipe# info
------------------------------------sap 1/1/1 create
exit
sap 1/1/2 create
ingress
filter ip 11
exit
exit
no shutdown
--------------------------------------
27
In this example, we are not using a conventional PC to function as a sniffer, instead we are configuring an
IP filter to replace the PC and act as a sniffer.
When the packets arrive at SAP 1/1/4 on PE1, they will be replicated to SAP 1/1/2. To examine these
packets, we need a network protocol analyzer or sniffer.
The slide shows the configuration of an IP filter on a local epipe 110 that is configured on the sniffer router.
The filter is configured to capture traffic sent to destination 192.168.1.0/27, forward it through the local
epipe 110, and log this information and store it the memory. The filter is applied at SAP 1/1/2 for the
ingress traffic.
Module 4 Page 27
ttl=64
ttl=64
ttl=64
ttl=64
ttl=64
time=2.52ms.
time=2.58ms.
time=2.47ms.
time=2.45ms.
time=2.50ms.
*A:Sniffer>config>service>epipe# show filter log 111

===============================================================================
Filter Log
===============================================================================
Admin state : Enabled
Description : (Not Specified)
Destination : Memory
Wrap
: Enabled
------------------------------------------------------------------------------Maximum entries configured : 100
Number of entries logged
: 10
2012/03/02 17:06:12 Ip Filter: 11:10 Desc:
SAP: 1/1/2 Direction: Ingress Action: Forward
Src MAC: 60-24-01-01-00-03 Dst MAC: 60-25-01-01-00-03 EtherType: 0800
Src IP: 192.168.1.1 Dst IP: 192.168.1.2 Flags: 0 TOS: 00 TTL: 64
Protocol: ICMP Type: Echo Request Code: 0
2012/03/02 17:06:12 Ip Filter: 11:10 Desc:
Protocol: ICMP Type: Echo Reply Code: 0
Module 4 |
28
If we ping the far-end CE router with a count of two, the packets are replicated and sent to the mirror
destination. This can be seen by viewing the filter log as shown. Because the packets are replicated, the
original packets are still forwarded through the epipe and a reply received. Both ingress and egress traffic
is mirrored so we see both the echo request and the echo reply.
*A:Sniffer>config>service>epipe# show filter log 111
===============================================================================
Filter Log
===============================================================================
Wrap
: Enabled
: 10
2012/03/02 17:06:12 Ip Filter: 11:10 Desc:
2012/03/02 17:06:12 Ip Filter: 11:10 Desc:
2012/03/02 17:06:13 Ip Filter: 11:10 Desc:
Module 4 Page 28
*A:CE1# ping 192.168.1.2

Mirror source and mirror destination are on different routers
The mirror source and mirror destination parameters must be configured using the
same mirror service ID
The router with the mirror source (PE2) has an SDP as the mirror destination
The mirrored traffic is encapsulated and sent to the far-end router (PE1)
The far-end router has a local mirror destination defined that accepts the packets
from the remote source
Module 4 |
29
Remote mirroring uses a service distribution path (SDP), which acts as a logical way of directing traffic
from one 7750 SR (PE2) to another (PE1) through a unidirectional service tunnel. The SDP terminates at
the far-end 7750 SR (PE1), which directs packets to the correct destination on that device.
The SDP configuration from the mirrored device to a far-end 7750SR requires a return-path SDP from the
far-end 7750 SR (PE1) back to the mirrored router (PE2). Each device must have an SDP defined for
every remote router to which it wants to provide mirroring services. SDPs must be created before services
can be configured.
Module 4 Page 29
Remote Mirror Service
Remote Mirror Service Configuration

Configuration requirements:
Mirror destination parameters:
A mirror destination ID, which is the same as the mirror source service
ID
The remote source needs to be specified in the mirror destination

service
A mirror destination SAP or SDP
Mirror source parameters:
A mirror source ID, which is the same as the mirror destination service
ID
An SDP as the mirror destination
At least one source type specified (port, SAP, IP filter, MAC filter, or
ingress label)
Module 4 |
30
Module 4 Page 30
An SDP is specified as the mirror destination
The mirror source is configured on SAP 1/1/4 to mirror both ingress and egress traffic
*A:PE-2# configure mirror mirror-dest 999 create

*A:PE-2>config>mirror>mirror-dest$ spoke-sdp 1:999 create
*A:PE-2>config>mirror>mirror-dest>spoke-sdp$ back
*A:PE-2>config>mirror>mirror-dest# no shutdown
*A:PE-2>config>mirror>mirror-dest# exit
*A:PE-2>config>mirror# info
---------------------------------------------mirror-dest 999 create
exit
no shutdown
exit
---------------------------------------------*A:PE-2# debug mirror-source 999
*A:PE-2>debug>mirror-source# sap 1/1/4 ingress egress
*A:PE-2>debug>mirror-source# no shutdown
*A:PE-2>debug>mirror-source# exit all
*A:PE-2# show debug
debug
mirror-source 999
sap 1/1/4 egress ingress
no shutdown
exit
Module 4 |
31
The diagram in this slide displays a sample configuration of a remote mirror service where the source is
on PE2 and the destination is on PE1.
An epipe service is configured between PE1 and PE2, the mirror destination is configured on SAP 1/1/2
while the mirror source is configured on SAP 1/1/4 of the epipe to mirror both ingress and egress traffic to
the destination via the spoke SDP 1:999.
A packet sniffer is attached to port 1/1/2 of PE1. The mirrored traffic is transmitted on this port and
received by the sniffer. In this example, we configure a router with an IP filter on a local epipe SAP to
emulate the sniffer. The filter configuration is shown below.
*A:Sniffer>config>filter# info
----------------------------------------log 111 create
destination memory 100
exit
ip-filter 11 create
entry 10 create
match
dst-ip 192.168.1.0/27
exit
log 111
action forward
exit all
----------------------------------------*A:Sniffer>config>service>epipe# info
------------------------------------sap 1/1/1 create
exit
sap 1/1/2 create
ingress
filter ip 11
exit
exit
no shutdown
Module 4 Page 31
Example of Remote Mirror Configuration Mirror Source
The remote source needs to be specified in the mirror destination service
The mirror source is configured on SAP 1/1/4 to mirror both ingress and egress traffic
*A:PE-1>config>mirror# mirror-dest 999 create

*A:PE-1>config>mirror>mirror-dest# remote-source
*A:PE-1>config>mirror>mirror-dest>remote-source# far-end 10.10.10.2
*A:PE-1>config>mirror>mirror-dest>remote-source# exit
*A:PE-1>config>mirror>mirror-dest# sap 1/1/2 create
*A:PE-1>config>mirror>mirror-dest>sap$ back
---------------------------------------------remote-source
far-end 10.10.10.2
exit
sap 1/1/2 create
exit
no shutdown
---------------------------------------------*A:PE-2# show service sdp-using
===============================================================================
SDP Using
===============================================================================
SvcId
SdpId
Type
Far End
Opr S* I.Label E.Label
------------------------------------------------------------------------------999
1:999
Spok
10.10.10.1
Up
n/a
131060
Module 4 |
32
For the spoke binding used for the mirror service to be operationally up, the far-end has to be configured
so there will be an egress label. The mirror destination configuration at the far- end of the tunnel (PE1) is
shown in the slide.
Once the remote mirror destination is configured on PE1, an egress label is signaled to PE2 using T-LDP
and the mirror service is up. There is no egress label signaled by PE2, since a mirror service really only
requires a one-way pseudowire.
Module 4 Page 32
Example of Remote Mirror Configuration Mirror Destination
Example of Remote Mirror Configuration Verification
The filter log is cleared and then ping packets are sent
*A:Sniffer# clear filter log 111

*A:Sniffer# show filter log 111
===============================================================================
Filter Log
===============================================================================
Wrap
: Enabled
: 10
2012/03/05 12:23:49 Ip Filter: 11:10 Desc:
2012/03/05 12:23:49 Ip Filter: 11:10 Desc:
Module 4 |
33
The mirror service is operationally up as shown below. When ping packets are sent between the CE
routers, the packets will be replicated and sent to the sniffer as shown in the slide. The slide shows that
we see packets on the sniffer router. There are only 10 in this case, 5 in each direction.
*A:PE-2# show service service-using mirror
===============================================================================
Services [mirror]
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId Service Name
------------------------------------------------------------------------------999
Mirror
Up
Up
-------------------------------------------------------------------------------
Module 4 Page 33
Remote Mirror Service Filter-Based Source

Filter-based source configuration requirements:
Define a filter, either IP or MAC, with at least one entry
Apply that filter to a SAP or an IP interface
Under the debug mirror-source context, define one or more entries to the
filter, which will identify matching traffic for mirroring
Module 4 |
34
The regular rules regarding filters still apply here; only one ingress and one egress filter are permitted, and
in each case either an IP filter or a MAC filter may be used, but not both. This example will use an IP filter.
The filter must be applied to a SAP or IP interface. If a filter is defined but not associated with a SAP or IP
interface, mirroring will not be enabled as there are no packets to mirror. In this example the filter is
applied to SAP 1/1/4 on PE2.
Simply having a filter applied to a SAP or IP interface does not cause mirroring; by default, none of the
packets matching any of the filter criteria are mirrored. The mirroring of packets must be explicitly defined
by identifying the entries to use for matching.
All packets are mirrored as they appear on the wire. Ingress packets are mirrored as they appear before
any ingress modifications. Egress packets are mirrored as they appear after all egress modifications and
encapsulations have been applied.
Note: an IP filter cannot be applied to a mirror destination SAP. No change is necessary to the
configuration of the mirror destination (compared with the previous example).
Module 4 Page 34
Example of Remote Mirror Service Filter-Based Source
*A:PE-2>config>service>epipe# sap 1/1/4

*A:PE-2>config>service>epipe>sap# egress filter ip 101
*A:PE-2>config>service>epipe>sap# exit
---------------------------------------------sap 1/1/4 create
egress
filter ip 101
exit
exit
exit
no shutdown
Module 4 |
35
Define the filter
Applying the filter

to SAP 1/1/4
In this example an IP filter is applied to SAP 1/1/4 on PE2. The IP filter specified only the destination IP
address of the ping (192.168.1.0/27)
Module 4 Page 35
*A:PE-2# configure filter ip-filter 101 create

*A:PE-2>config>filter>ip-filter$ entry 10 create
*A:PE-2>config>filter>ip-filter>entry$ match dst-ip 192.168.1.0/27
*A:PE-2>config>filter>ip-filter>entry$ action forward
*A:PE-2>config>filter>ip-filter>entry$ exit
*A:PE-2>config>filter>ip-filter# info
---------------------------------------------entry 10 create
match
dst-ip 192.168.1.0/27
exit
action forward
exit
----------------------------------------------
*A:PE-2# debug mirror-source 999

*A:PE-2>debug>mirror-source# ip-filter 101 entry 10
*A:PE-2>debug>mirror-source# exit
*A:PE-2# show debug
debug
mirror-source 999
ip-filter 101 entry 10
no shutdown
exit
exit
Module 4 |
36
An entry to the filter is applied under the debug mirror source instead of the previously configured SAP
1/1/4. This entry identifies the matching traffic for mirroring.
We need to clear the filter log before we ping 192.168.1.1 from CE2 in order to verify the configurations.
After the filter log is cleared we can see that there are 0 entries logged.
*A:Sniffer# clear filter log 111
===============================================================================
Filter Log
===============================================================================
Wrap
: Enabled

: 0
===============================================================================
Module 4 Page 36
Example of Remote Mirror Service Filter-Based Source (continued)

===============================================================================
Filter Log
===============================================================================
Wrap
: Enabled
: 5
2012/03/05 15:54:48 Ip Filter: 11:10 Desc:
2012/03/05 15:54:49 Ip Filter: 11:10 Desc:
Protocol: ICMP Type: Echo Reply Code
...
Module 4 |
37
Ping packets are sent to the far-end CE (CE1) router as shown:

*A:CE2# ping 192.168.1.1
The slide shows that we see packets on the sniffer router. There are only five in this case (only two are
shown) since the IP filter for the mirror source specified only the destination IP address of the ping.
Module 4 Page 37
Example of Remote Mirror Service Filter-Based Source (continued)
Mirror Slicing
Mirror service allows network operators to slice customer data, mirroring
only the parts they need to analyze
Allows only a specified number of bytes to be transmitted to the mirror
destination
Enables the copying of a specific packet size of each frame
Can mirror large frames

Limits the size of the stream of packets traveling through the router and
the network
Module 4 |
38
In traditional routers, replication of mirrored packets typically affected performance and needed to be used
with caution. Due to the duplication of some or all packets, the total amount of traffic within the network
would increase, possibly causing congestion in downstream links and routers.
The replication of packets is handled by the hardware on the IOM (Input/Output Module) and thus has
minimal impact on router performance. However, it is important to remember that mirroring involves the
duplication of traffic and thus increases the bandwidth required. If ingress and egress traffic on a 1 Gb/s
port is mirrored, this could represent as much as an additional 2 Gb/s of traffic to the mirror destination.
When a mirror destination is configured, the packet slice option can truncate mirrored packets to the
destination. This minimizes replication and tunneling overhead.
Slicing is useful for monitoring network usage without having to copy the actual data. Slicing enables you
to mirror frames larger than the destination-packet decode equipment can handle. It also enables the
conservation of mirroring resources by limiting the size of the stream of packets traveling through the SR
and the core network.
When a mirror slice size is defined, a threshold is created that truncates a mirrored frame to a specific
size. For example, if the value of 256 bytes is defined, up to the first 256 bytes of the frame are transmitted
to the mirror destination. The original frame is not affected by the truncation. Mirrored frames will most
likely be slightly larger due to encapsulation overhead, but no more than 256 bytes of the original packet
will be transmitted.
The transmission of a sliced or non-sliced frame is also dependent on the mirror destination SDP path
MTU and/or the mirror destination SAP physical MTU. Packets that require a larger MTU than the
mirroring destination supports are discarded if the defined slice size does not truncate the packet to an
acceptable size.
Module 4 Page 38
Can monitor network usage without copying the actual data
Mirror Slicing Configuration
*A:PE-2# configure mirror mirror-dest 999

*A:PE-2>config>mirror>mirror-dest# slice-size 128
---------------------------------------------spoke-sdp 1:999 create
exit
slice-size 128
no shutdown
----------------------------------------------
Module 4 |
39
*A:PE-2>config>mirror>mirror-dest# slice-size
- no slice-size
- slice-size <slice-size>
<slice-size>
: [128..9216]
Default: no slice-size mirrored packet truncation is disabled.
Parameters: bytes the number of bytes to which mirrored frames will be truncated; the value is
expressed as a decimal integer.
Values: 128 9216
This command enables mirrored frame truncation and specifies the maximum size, in bytes, of a mirrored frame that
can be transmitted to the mirror destination. It enables the mirroring of frames larger than the destination-packet
decode equipment can handle. It also allows conservation of mirroring resources by limiting the size of the packet
stream traveling through the router and the core network.
The actual capability of the 7750 SR to transmit a sliced or non-sliced frame is also dictated by the mirror destination
SDP path MTU and/or the mirror destination SAP physical MTU. Packets that require a larger MTU than the mirroring
destination can support are discarded if the defined slice size does not truncate the packet to an acceptable size. The
no form of the command disables mirrored packet truncation.
The slide shows the configuration of mirror slicing on PE2. Recall that epipe 50 service MTU is 1514, the maximum
payload that can be carried through the service is 1514-14 = 1500 bytes. The SDP MTU is 9190 as shown below.
===============================================================================
Service Id
: 50
Vpn Id
: 0
Service Type
: Epipe
MTU
: 1514

------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4
null
1514
1514
Up
Up
sdp:1:50 S(10.10.10.1)
Spok
0
9190
Up
Up
Module 4 Page 39
Configuring slice size for a remote mirror service
Mirror Slicing Verification
*A:Sniffer# show filter ip 11 counters

=======================================================================
IP Filter
=======================================================================
Filter Id
: 11
Applied
: Yes
Scope
: Template
Def. Action
: Drop
Radius Ins Pt: n/a
CrCtl. Ins Pt: n/a
Entries
: 1
----------------------------------------------------------------------Filter Match Criteria : IP
----------------------------------------------------------------------Entry
: 10
Ing. Matches : 1 pkts (132 bytes)
Egr. Matches : 0 pkts
Module 4 |
40
To verify mirror slicing, we have cleared the filter IP (see below), therefore there are no packets captured.
Then we sent a ping from CE2 to CE1 with a size of 1200 byte, as shown in the slide (the size value
specifies the size of the ping packet; recall that the maximum size for a successful ping would be 1472
bytes). If we check the IP filter counter we see (as expected) there is only one packet that has been
matched on the ingress, and the size of that packet is 132 bytes - 4 bytes more than the 128 bytes
configured in the mirror slicing due to encapsulation overhead.
*A:Sniffer# clear filter ip 11
*A:Sniffer# show filter ip 11 counters
======================================================================
IP Filter
======================================================================
Filter Id
: 11
Applied
: Yes
Scope
: Template
Def. Action
: Drop
Radius Ins Pt: n/a
CrCtl. Ins Pt: n/a
Entries
: 1
----------------------------------------------------------------------Filter Match Criteria : IP
----------------------------------------------------------------------Entry
: 10
Ing. Matches : 0 pkts
Egr. Matches : 0 pkts
Module 4 Page 40
*A:CE2# ping count 1 192.168.1.1 size 1200

OAM tools are provided in modern routers to help manage and troubleshoot
the network
lsp-ping command is used to verify LSP connectivity
lsp-trace command is used to determine the hop-by-hop path for an LSP
sdp-mtu performs in-band MTU path tests on an SDP to determine the

largest path MTU supported on an SDP
sdp-ping tests an SDP for in-band unidirectional or round-trip connectivity

with a round-trip time estimate
svc-ping tests a service ID for correct and consistent provisioning between

two service end-points
Module 4 |
41
Module Summary
Module 4 Page 41
Mirror services can be implemented on the same device (local) or on two

different devices (remote)
Remote mirroring makes use of the SDP tunnel
Mirror source is configured under the debug context, whereas the mirror
destination is configured under the config mirror context
The mirror source can be one of:
Port
SAP
IP filter
MAC filter
Ingress label
Mirror slicing enables the copying of a specific packet size of each frame
Module 4 |
42
Module 4 Page 42
Learning Assessment
1. What are the OAM SDP diagnostic tools?
2. What is lsp-ping used for?
3. Why is the path MTU found using sdp-mtu 4 bytes less than the MTU
discovered using lsp-ping?
5. Verify whether the following statement is true or false: Traffic from

more than one ingress mirror source can be mirrored to the same traffic
analyzer using different SAPs on the same access port.
6. How many SDPs in total are involved in local mirroring?
7. How many mirror destinations can a mirror source have within a mirror
service?
Module 4 |
43
1. What are the OAM SDP diagnostic tools?

The OAM SDP diagnostic tools are sdp-ping and sdp-mtu
2. What is lsp-ping used for?
lsp-ping can be used for measuring the round trip time for a specific forwarding class, or testing the
path MTU
3. Why is the path MTU found using sdp-mtu 4 bytes less than the MTU discovered using lsp-ping?
The path MTU found using sdp-mtu is 4 bytes less than the MTU discovered using lsp-ping because
lsp-ping uses only a single MPLS label, while sdp-mtu uses both the service and transport label.
4. In oam svc-ping, what do the parameters local-sdp and remote-sdp indicate?
The parameter local-sdp specifies that the ping should be sent to the far-end in-band using the SDP
and the parameter remote-sdp specifies that the return ping should be sent in-band
5. Verify whether the following statement is true or false: Traffic from more than one ingress mirror source
can be mirrored to the same traffic analyzer using different SAPs
True
6. How many SDPs in total are involved in local mirroring?
None
7. Within a mirror service, how many mirror destinations can a mirror source have?
One
Module 4 Page 43
4. In oam svc-ping, what do the parameters local-sdp and remote-sdp

indicate?

8. What happens to a mirror source when the corresponding mirror
destination service ID is shut down?
10. Verify whether the following statement is true or false: With local
mirroring, the local mirror source and mirror destination components
must be configured using the same service ID.
Module 4 |
44
8. What happens to a mirror source when the corresponding mirror destination service ID is shut down?
The mirror source is put into an operational down mode.
9. Which command syntax is used to configure a mirror source? Which command syntax is used to
configure a mirror destination?
A mirror source uses the debug>mirror-source context, while the mirror destination uses the
config>mirror context.
10.Verify whether the following statement is true or false: With local mirroring, the local mirror source and
mirror destination components must be configured under the same service ID context.
True
Module 4 Page 44
9. Which command syntax is used to configure a mirror source? Which

command syntax is used to configure a mirror destination?
Lab 6-1 Local Mirror Service

Configure a local mirror service
Module 4 |
45
Module 4 Page 45
Lab 6-2 Remote Mirror Service

Configure a remote mirror service
Module 4 |
46
Module 4 Page 46
Module 4 |
47
Module 5 Layer 3 Services
Module 5 Page 1
Module Objectives
Provide an overview of IES and its features
Describe the operation and implementation of an IES
Describe the application of Layer 3 service spoke termination
to a Layer 2 service
Configure and verify an IES spoke termination to a VPLS
Module 5 |

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) program. Refer to the
Alcatel-Lucent website located at www.alcatel-lucent.com/src for more information on the SRC
program.
Internet standards documentation such as protocol standards bodies, RFCs, and IETF drafts
Technical support pages of the Alcatel-Lucent website located at http://www.alcatellucent.com/support
Module 5 Page 2
Configure and verify an IES
Module Objectives (continued)
Describe the Alcatel-Lucent VPRN service and recognize its

benefits
Explain the interaction between the control and data plane

of a VPRN service
Configure, verify and troubleshoot an IPv4 and IPv6 VPRN
service
Module 5 |
Module 5 Page 3
Identify the protocols and technologies required to

implement the Alcatel-Lucent VPRN service
Section 1 Internet Enhanced Service (IES) Overview
Module 5 Page 4
Section Objectives
Describe customer access to IES
Explain IES characteristics
Configure and verify an IES
Complete Lab 7 Configuring an IES
Module 5 |
Module 5 Page 5
Internet Enhanced Services (IES)

IES is a routed connectivity service where the customer communicates
with an IP router interface to send and receive Internet traffic.
An IES has one or more logical IP routing interfaces, each with a SAP that
acts as the access point to the customers network
Module 5 |
Internet enhanced service (IES) is a routed connectivity service where the customer communicates
with an IP router interface to send and receive Internet traffic. An IES has one or more logical IP
routing interfaces, each with a SAP that acts as the access point to the customers network. IES
allows customer-facing IP interfaces to participate in the same routing instance used for service
network core routing connectivity.
From the customers perspective, it provides a direct connection to the Internet. Unlike other services
such as epipe, VPLS and VPRN, there is nothing virtual or private about an IES.
Module 5 Page 6
IES provides direct Internet access to the customer
IES Characteristics
Multiple IES services are created to separate customer-owned IP interfaces
More than one IES service can be created for a single customer ID
Multiple interfaces can be configured in a single IES
IES allows customer-facing IP interfaces to participate in the same routing

instance used for service network core routing connectivity
The service provider can apply all billing, QoS and accounting to the
customer
Does not necessarily require a service distribution path (SDP); traffic is
routed rather than encapsulated in a tunnel
Module 5 |
The Internet Enhanced Service (IES) is essentially a way of providing a Layer 3 interface to a
customer. It is similar to a normal Layer 3 interface, but treated as a service, with the port configured
as a SAP (SAPs support multiple encapsulation types such as Ethernet null, dot1Q, Q-in-Q.). This
provides more flexibility and also the ability to use all service-oriented capabilities of an access port
such as QoS, accounting and filtering. Like any IP interface, the customer can use the IES interface as
a neighbor for a routing protocol such as OSPF, IS-IS or BGP. The IES provides access to the service
providers core routing instance.
Since the traffic in an IES communicates using an IP interface for the core routing instance, there is no
need for the concept of tunneling traffic to a remote router. As such, a simple IES does not necessarily
require the configuration of any SDPs when configuring the service.
In the following section we will discuss how an IES can provide Layer 3 termination of a Layer 2 VPLS
service. In that case, a spoke SDP is used in conjunction with an IES.
Module 5 Page 7
All IP interfaces created within an IES belong to the same customer
IES Configuration Tasks

Basic IES configuration tasks:
Creating an IES and associating it with a customer ID
Configuring an IES interface
Enabling the service
Module 5 |
The tasks performed to configure IES include:

Associate an IES with a customer ID
Create an interface
Specify the name for the interface
Specify the IP address, including the mask
Define the SAP parameters on the interface
Specify port and Q tag values (if any)
Optional select QoS policies other than the default (configured in the config>qos context)
Optional select filter policies (configured in the config>filter context)
Optional select accounting policy (configured in the config>log context)
Enable the service
The slide shows the network diagram we will be using to configure an IES on PE1. Customer A would
like to have two access points to the internet using the service provider network. An IES will be
created with two interfaces, one to Customer Site 1, and the other to Customer Site 2, as shown in the
following slides.
Module 5 Page 8
Configuring a SAP on the interface specifying the access port and

encapsulation values (if any)
*A:PE-1# configure service ies 100

*A:PE-1>config>service>ies# info
---------------------------------------------interface "to-Site1" create
address 192.168.100.2/27
sap 1/1/4:1 create
exit
exit
interface "to-Site2" create
address 192.168.200.2/27
sap 1/1/4:2 create
exit
exit
no shutdown
----------------------------------------------
Module 5 |
An IES 100 is configured with two interfaces as shown. The customer CE router interfaces are
configured as shown below:
*A:CE1>config>router# info
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "IES_1"
address 192.168.100.1/27
port 1/1/3:1
exit
interface "IES_2"
address 192.168.200.1/27
port 1/1/3:2
exit
interface "system"
address 10.10.10.5/32
exit
#--------------------------------------------------
Module 5 Page 9
Example of IES Configuration
*A:PE-1# show router interface

===========================================================================
Interface Table (Router: Base)
===========================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
--------------------------------------------------------------------------system
Up
Up/Down
Network system
10.10.10.1/32
n/a
to-Site1
Up
Up/Down
IES
1/1/4:1
192.168.100.2/27
n/a
to-Site2
Up
Up/Down
IES
1/1/4:2
192.168.200.2/27
n/a
to-PE2
Up
Up/Down
Network 1/1/1
10.1.2.1/27
n/a
to-PE3
Up
Up/Down
Network 1/1/3
10.1.3.1/27
n/a

==============================================================================
==============================================================================
Service Id
: 100
Vpn Id
: 0
Service Type
: IES
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Mgmt Change : 03/12/2012 12:11:39
Admin State
: Up
Oper State
: Up
SAP Count
: 2
-----------------------------------------------------------------------------Service Access & Destination Points
-----------------------------------------------------------------------------Identifier
Type
-----------------------------------------------------------------------------sap:1/1/4:1
q-tag
1518
1518
Up
Up
sap:1/1/4:2
q-tag
1518
1518
Up
Up
Module 5 |
10
The configured IES interfaces appear as regular Layer 3 interfaces in the base router instance. We
refer to the core routing instance on the Alcatel-Lucent 7750 SR as the base router instance.
Although the IES interface is similar to a standard IP interface, the SAP provides the QoS, accounting
and billing capabilities of a service interface. You can use the command show service id 100 sap
1/1/4:1 detail to see those details.
The same default SAP MTU rules that were covered for Layer 2 services apply to an IES. The SAP
MTU is based on the physical port to which it is bound. Access ports have a default MTU of 1514 if
their encapsulation type is null, 1518 if their encapsulation type is dot1Q, and 1522 if their
encapsulation type is Q-in-Q. Notice that the SAP MTU value is 1518 bytes, because we have used
dot1Q encapsulation.
Notice that when we use the command show service service-using ies there is another IES created;
it has a service ID of 2147483648. After release 8.0, service objects such as interfaces, SAPs and
related objects can be automatically created for internal use in IES or in configured VPRN services.
*A:PE-1# show service service-using ies
===============================================================================
Services [ies]
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId Service Name
------------------------------------------------------------------------------100
IES
Up
Up
2147483648 IES
Up
Down 1
_tmnx_InternalIesService
Module 5 Page 10
IES Verification
*A:CE1>config>router>ospf# info
---------------------------------------------area 0.0.0.0
interface "IES_1"
mtu 1500
exit
interface "IES_2"
mtu 1500
exit
exit
----------------------------------------------
*A:CE1# show router ospf neighbor

============================================================================
OSPF Neighbors
=============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
----------------------------------------------------------------------------IES_1
10.10.10.1
Full 1
0
38
IES_2
10.10.10.1
Full 1
0
34
----------------------------------------------------------------------------No. of Neighbors: 2
Module 5 |
11
In order for Customer A to have access to the provider core and exchange routes, OSPF is configured
between CE1 and PE1. The slide shows OSPF configuration on CE1.
Notice that the port MTU on the CE router must match the SAP MTU of the IES in order for the OSPF
adjacency to be established.
OSPF configuration on PE1 is shown below:
---------------------------------------------area 0.0.0.0
interface "system"
exit
interface "to-PE2"
exit
interface "to-PE3"
exit
interface "to-Site1"
exit
interface "to-Site2"
exit
exit
Module 5 Page 11
Connecting Customers CE Interface Through IES
Connecting Customers CE Interface Through IES (continued)
*A:CE1# show router route-table

===============================================================================
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Metric
------------------------------------------------------------------------------10.1.2.0/27
Remote OSPF
19h43m26s
10
192.168.100.2
200
10.1.3.0/27
Remote OSPF
19h43m26s
10
192.168.100.2
200
10.2.4.0/27
Remote OSPF
19h43m26s
10
192.168.100.2
300
10.3.4.0/27
Remote OSPF
19h43m26s
10
192.168.100.2
400
10.10.10.1/32
Remote OSPF
19h43m26s
10
192.168.100.2
100
10.10.10.2/32
Remote OSPF
19h43m26s
10
192.168.100.2
200
10.10.10.3/32
Remote OSPF
19h43m26s
10
192.168.100.2
200
10.10.10.4/32
Remote OSPF
19h43m26s
10
192.168.100.2
300
10.10.10.5/32
Local
Local
35d01h48m
0
system
0
192.168.100.0/27
Local
Local
19h55m06s
0
IES_1
0
192.168.200.0/27
Local
Local
19h54m12s
0
IES_2
0
------------------------------------------------------------------------------No. of Routes: 11
Module 5 |
12
The customer is able to receive the routes from the provider core and will be able to access the
Internet via the core network.
Module 5 Page 12
The customer receives the routes from the provider core
Connecting Customers CE Interface Through IES (continued)

Layer 3 service performs fragmentation to accommodate larger packets.
*A:CE1# ping 10.10.10.4 source 192.168.100.1 size 1472 count 1
*A:CE1# ping 10.10.10.4 source 192.168.100.1 size 1473 count 1

*A:CE1# ping 10.10.10.4 source 192.168.100.1 size 1473 count 1 do-not-fragment

---- 10.10.10.4 PING Statistics ---1 packet transmitted, 0 packets received, 100% packet loss
Module 5 |
13
The ping test shown verifies that the customer can reach destinations within the provider core. Since
the CE router system interface has not been advertised through the network (as shown in previous
slide for the OSPF configuration of the CE router), a source address needs to be specified in the ping
because the default behavior of the 7750 SR is to use the system interface as the source address of a
ping destined to a non-directly attached network.
The frame size generated by the ping with size 1472 bytes equals to 1518 bytes ( 1472 + 20 IP header
+ 8 ICMP header + 14 Layer 2 header + 4 VLAN tag). In this case, the ping is successful because the
frame size is less than the SAP MTU.
In the second ping test, the frame size equals 1519 bytes (ping size 1473), which is larger than the
SAP MTU; however, the ping is still successful. The reason is that Layer 3 service performs
fragmentation to accommodate larger packets.
In the third ping test, when the do-not-fragment option is added, the ping is not successful because
fragmentation is not performed. This results in a frame size larger than the SAP MTU.
Module 5 Page 13
Section 2 Layer 3 Service Spoke Termination to Layer 2 VPN
Module 5 Page 14
Section Objectives
Describe the application or use of Layer 3 service spoke

termination to a Layer 2 VPN
Highlight the MTU issues that can arise when configuring a Layer 3
service spoke termination to a Layer 2 VPN service
Describe the steps for configuring IES spoke termination to VPLS
Complete Lab 8 IES Spoke Termination to a VPLS
Module 5 |
15
Module 5 Page 15
Layer 3 Service Spoke SDP Termination Overview
Introduces the ability to connect the spoke SDP of a Layer 2 service with a Layer 3
service
See left diagram below: the spoke is tied to a Layer 2 Service (VPLS or epipe)
Module 5 |
16
Sometimes it is desirable to use a Layer 2 service, such as an epipe or a VPLS, to connect the
customer to the Layer 3 (IES or VPRN) interface. This is known as a spoke termination on an IES or
VPRN, respectively. This feature introduces the ability to cross-connect traffic entering on a spoke
SDP used for Layer 2 services to a Layer 3 service.
From a logical point of view, the spoke SDP entering on a network port is connected to the Layer 3
service as if it had entered through a service SAP. The main exception applies to traffic entering the
Layer 3 service through a spoke SDP; in this case, the traffic is handled based on network QoS
policies rather than access QoS policies.
This section will show the configuration details of spoke termination on an IES. Similar configuration
steps are used for spoke termination on VPRN.
The diagram shows a network where a spoke SDP is used to connect Layer 3 service to Layer 2
service. On the left, the spoke is tied to a VPLS or epipe service: no special or different configuration
is required. On the right, a Layer 3 (IES or VPRN) IP interface terminates the spoke-SDP.
As usual, one SDP may carry other services in addition to the IES or VPRN service.
Module 5 Page 16
See right diagram below: a Layer 3 (IES or VPRN) IP interface terminates the spoke
SDP
Traffic that has to be terminated on a given Layer 3 service is identified by the SDP
ID and VC label present in the service packet
A Layer 3 service can only terminate a spoke SDP, not a mesh SDP
Layer 2 and Layer 3 service MTUs must be equal
Module 5 |
17
Both MPLS and GRE spoke SDPs are supported.

Note: T-LDP must be configured between the SR with the VPLS service and the SR with the IES
service so that they can exchange VC labels.
The spoke SDP must terminate on a remote Alcatel-Lucent 7750 SR. You cannot create an IES
service on the same router as the epipe/VPLS service for spoke SDP termination: the VC-ID can only
be used in one service.
Module 5 Page 17
IES Spoke SDP Termination Overview
*A:PE-1# configure service ies 100

*A:PE-1>config>service>ies# info
---------------------------------------------interface "To_VPLS_1000" create
address 192.168.100.2/27
exit
exit
no shutdown
---------------------------------------------
---------------------------------------------stp
shutdown
exit
sap 1/1/4 create
exit
exit
exit
exit
no shutdown
----------------------------------------------
Module 5 |
18
In the network shown, the service provider is providing a VPLS to its customer that terminates on an
IES. This supplies a Layer 3 interface to the customer. The slide shows the IES configuration. Notice
that the spoke SDP connected to the service is included in the IES instead of a SAP.
*A:CE>config>router# info
------------------------------------echo "IP Configuration"
#-----------------------------------interface "system"
address 10.10.10.6/32
exit
interface "to-IES"
address 192.168.100.1/27
port 1/1/3
exit
-------------------------------------
Module 5 Page 18
IES Spoke SDP Termination to a VPLS - Configuration
IES Spoke SDP Termination to a VPLS - Verification

===============================================================================
===============================================================================
Service Id
: 100
Vpn Id
: 0
Service Type
: IES
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Mgmt Change : 03/12/2012 11:43:42
Admin State
: Up
Oper State
: Down
SAP Count
: 0
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sdp:2:100 S(10.10.10.2)
Spok
0
9190
Up
Down
Module 5 |
19
Module 5 Page 19
The status of the spoke SDP in the IES service is operationally

down. More detailed investigation is required.
IES Spoke SDP Termination to a VPLS - MTU Mismatch

The spoke SDP is not operational with a flags value of ServiceMTUMismatch
The VC-MTU signaled from the IES side is based on the network port MTU (9212 bytes)
The VC-MTU signaled from the VPLS is based on the service MTU of the VPLS, which is
1514 by default

=========================================================================
=========================================================================
Sdp Id 2:100 -(10.10.10.2)
------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 2:100
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 9190
Far End
: 10.10.10.2
Delivery
: MPLS
Admin State
Acct. Pol
Ingress Label
Admin ControlWord
Last Status Change
Last Mgmt Change
Class Fwding State
Flags
Peer Pw Bits
: Up
: None
: 131064
:
:
:
:
:
:
Oper State
Collect Stats
Egress Label
Not Preferred
Oper ControlWord
01/30/2012 16:55:09
Signaling
03/12/2012 11:43:42
Down
PWPeerFaultStatusBits ServiceMTUMismatch
pwNotForwarding

==============================================================================
LDP LSR ID: 10.10.10.1
==============================================================================

==============================================================================
Type
VCId
SvcId
SDPId Peer
-----------------------------------------------------------------------------I-Eth 100
100
2
10.10.10.2
131064U 131062D 9176 1500
-----------------------------------------------------------------------------No. of VC Labels: 1
: Down
: Disabled
: 131062
: False
: TLDP
Module 5 |
20
We see that the spoke SDP is not operational with a flags value of ServiceMTUMismatch. This is
because the MTU signaled from the IES side is based on the network port MTU (network port MTU is
9212 by default), and the MTU signaled from the VPLS is based on the service MTU of the VPLS
which is 1514 by default. The pseudowire will not become operational if the MTUs are not the same.
show router ldp bindings fec-type services command shows the different MTU values signaled by
the two ends of the pseudowire.
The network port MTU is 9212 as shown below. The VC MTU will be equal to 9176 bytes ( 9212-14
port encapsulation 14 Ethernet header 4 transport label 4 service label).
*A:PE-1# show port 1/1/1
===============================================================================
Ethernet Interface
===============================================================================
Description
: 1-Gig Ethernet SFP
Interface
: 1/1/1
Oper Speed
Link-level
: Ethernet
Config Speed
: N/A
Admin State
: up
Oper Duplex
: full
Oper State
: up
Config Duplex
: N/A
Physical Link
: Yes
MTU
: 9212
: 1 Gbps
Module 5 Page 20
The spoke SDP binding only becomes operationally up if the VC-MTU (signaled using
T-LDP ) on both ends match.
Spoke SDP Termination: MTU Considerations
The VC-MTU is derived from the configured service MTU (VC-MTU =

configured service MTU 14 (Ethernet overhead, FCS not counted).
If no service MTU is configured, the VC-MTU is derived from the configured

SDP path MTU (VC-MTU = configured SDP path MTU 14 (Ethernet
overhead, FCS not counted).
If the SDP path MTU is not configured, the SDP path MTU and the VC-MTU
are derived from the network port MTU.
SDP path MTU = network port MTU 4 (transport label) 4 (VC-label) port
encapsulation (14 in case of null encapsulation, 18 in case of dot1Q...)
VC-MTU = network port MTU 14 (port encap) 4 (transport label) 4 (VC-label)
14 Ethernet overhead
Module 5 |
21
Module 5 Page 21
Service MTU cannot be configured on IES or VPRN service.
Spoke SDP Termination: MTU Considerations (continued)

By default, epipe and VPLS services are configured with a service MTU of 1514. By
default, the signaled VC-MTU is 1500.
IES and VPRN services have no service MTU configured. By default, there is also no SDP
path MTU configured.
On PE1, the following applies:
SDP path MTU = 9212 4 4 14 = 9190

VC-MTU = 9190 14 = 9176
Module 5 |
22
SDP path-MTU = network port MTU 4 (transport label) 4 (VC-label) port encapsulation (14 in case
of null encapsulation, 18 in case of Dot1Q...)
VC-MTU = network port-MTU 14 SDP path-MTU
Module 5 Page 22
Network port MTU = 9212
IES Spoke SDP Termination to a VPLS- IP MTU

The MTU values can be made to match by:
Changing the VC-MTU of the IES using the ip-mtu command (preferred
method)
*A:PE-1# configure service ies 100 interface To_VPLS_1000"

*A:PE-1>config>service>ies>if# ip-mtu 1500
*A:PE-1>config>service>ies>if# info
Adjusting the SDP path MTU ( not recommended)

Adjusting the network port MTU (not recommended)
Module 5 |
23
Whereas in epipe and VPLS services the signaled VC-MTU = configured service-mtu 14 (Ethernet
header), in the case of an IES or VPRN service, the signaled VC-MTU = configured IP-MTU.
The following command is used to configure the ip-mtu:
*A:PE-1>config>service# ies 100 interface "To_VPLS_1000" ip-mtu
- ip-mtu <octets>
- no ip-mtu
<octets>
: [512..9000]
Another option to solve the MTU mismatch is changing the SPD path MTU. However, setting the SDP
path MTU may also impact other services running over that SDP.
A third option is to change the network port MTU. However, this option is also not recommended for
the following reasons:
It needs to be configured on the network ports of both routers.
It will impact all services over that port.
Module 5 Page 23
For Layer 3 service: the signaled VC-MTU = configured IP-MTU.
IES Spoke SDP Termination to a VPLS - Verification

===============================================================================
===============================================================================
Service Id
: 100
Vpn Id
: 0
Service Type
: IES
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Mgmt Change : 03/12/2012 11:43:42
Admin State
: Up
Oper State
: Up
SAP Count
: 0
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sdp:2:100 S(10.10.10.2)
Spok
0
9190
Up
Up

===============================================================================
LDP LSR ID: 10.10.10.1
===============================================================================
output omitted
===============================================================================
===============================================================================
Type
VCId
SvcId
SDPId Peer
------------------------------------------------------------------------------I-Eth 100
100
2
10.10.10.2
131064U 131062S 1500 1500
Module 5 |
24

===============================================================================
===============================================================================
Service Id
: 1000
Vpn Id
: 0
Service Type
: VPLS
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 1000
SAP Count
: 1
SDP Bind Count
: 4
Per Svc Hashing
: Disabled
Def. Gateway IP
: None
------------------------------------------------------------------------------Identifier
Type
------------------------------------------------------------------------------sap:1/1/4
null
1514
1514
Up
Up
sdp:1:100 S(10.10.10.1)
Spok
0
9190
Up
Up
sdp:3:1000 M(10.10.10.3)
Mesh
0
9190
Up
Up
sdp:4:1000 M(10.10.10.4)
Mesh
0
9190
Up
Up
===============================================================================
Module 5 Page 24
The spoke SDP binding and IES are operationally up
IES Spoke SDP Termination to a VPLS Connectivity Verification
The CE router can now ping the IES interface

The CE router ARP cache has the MAC address of the PE router with the IES
*A:CE# ping 192.168.100.2 count 1

*A:CE# show router arp

===========================================================
ARP Table (Router: Base)
===========================================================
IP Address
MAC Address
Expiry
Type
Interface
----------------------------------------------------------192.168.100.1
60:25:01:01:00:03 00h00m00s Oth[I] to-IES
192.168.100.2
60:20:ff:00:00:00 03h59m54s Dyn[I] to-IES

===============================================================================
Forwarding Database, Service 1000
===============================================================================
ServId
MAC
Source-Identifier
Type
Last Change
Age
------------------------------------------------------------------------------1000
60:20:ff:00:00:00 sdp:1:100
L/1005 03/14/2012 14:19:06
1000
60:25:01:01:00:03 sap:1/1/4
L/0
03/14/2012 14:36:09
Module 5 |
25
When traffic is sent from the CE router, it enters the SAP of the VPLS on PE2. Traffic is passed to
PE1 using the spoke SDP between PE2 and PE1. From PE1 traffic can be sent to other routers as an
IP packet using the IGP.
The ARP table of the CE router has one dynamically learned entry for the gateway address. However,
because the gateway address is an IES interface on a spoke SDP, the MAC address supplied to the
CE router is the chassis MAC of PE1.
The VPLS learns two MAC addresses. The first address is the MAC of the CE router, which it learns
from the SAP. The second MAC address is PE1 chassis MAC address for the IES interface.
*A:PE-1# show chassis
===============================================================================
Chassis Information
===============================================================================
Name
: PE-1
Base MAC address

: 60:20:ff:00:00:00
*A:CE# show router interface "to-IES" detail
===============================================================================
Interface
------------------------------------------------------------------------------If Name
: to-IES
Admin State
: Up
Oper (v4/v6)
: Up/Down
Protocols
: None
IP Addr/mask
: 192.168.100.1/27
Address Type
: Primary
IGP Inhibit
: Disabled
Broadcast Address : Host-ones
------------------------------------------------------------------------------
MAC Address
: 60:25:01:01:00:03
Arp Timeout
: 14400
Module 5 Page 25
interface
Module 5 |
26
Module 5 Page 26
Lab 7: Configuring an IES
Module 5 |
27
Module 5 Page 27
Lab 8 IES Spoke Termination to a VPLS
Section 3 VPRN Overview
Module 5 Page 28
Section Objectives
Define VPRN and explain its features
Describe the key mechanisms and features that make up the

VPRN architecture
Explain the implementation of label stack in VPRN
Describe the usage of the VPN routing and forwarding (VRF)

table in VPRN
Describe the distribution of VPRN routing information between

CE-PE and PE-PE routers
Describe data packets forwarding across a service provider

network from a CE router to a remote CE
Module 5 |
29
Module 5 Page 29
VPRN
Module 5 |
30
VPRN service allows multiple customer sites to communicate securely at the IP level over a
provider-managed MPLS network. As shown in the slide, a single provider-managed IP/MPLS
infrastructure permits the deployment of multiple, distinct customer-routed networks that are
fully isolated from each other.
Although VPRNs are known by many names, they all have the same definition: a Layer 3 routed
service across a provider-managed IP/MPLS core.
Other names commonly used to define VPRNs include: Layer 3 Backbone VPNs, Layer 3 MPLS-based
VPNs, MPLS-based IP-VPNs, or Border Gateway Protocol (BGP)/MPLS-based VPNs (according to the
standard RFC 2547bis, which is co-authored by Alcatel-Lucent).
RFC 2547bis is an extension of the original RFC 2547, which details a method of distributing routing
information and forwarding data to provide a Layer 3 virtual private network (VPN) service to endcustomers.
Although RFC 2547bis has long been quoted as an industry standard and is used in common
terminology to define this class of VPN, this RFC has since been made obsolete by RFC 4364.
Module 5 Page 30
Virtual Private Routed Network (VPRN) is an IP (Layer 3) service

that connects multiple sites in a single routed domain over the
provider-managed IP/MPLS network.
Network Model
Advantages:
Customers perspective: each site is connected to a routed network
administered by the service provider that appears to be solely dedicated
to the customer
Module 5 |
31
A VPRN is the Alcatel-Lucent service implementation of a MPLS Layer 3 VPN. RFC 4364 describes a
method of a Layer 3 VPN service that provides the following functions to the customer:
Distributing the customers routing information between sites.
Forwarding customer originated data packets to the appropriate destination.
Providing secure Layer 3 routing connectivity among the various customer sites.
Each VPRN consists of a set of customer sites connected to one or more provider routers. Each
associated provider router maintains a separate IP forwarding table for each VPRN.
Customers can manage their own IP addressing and select their own preference in terms of the
routing protocol.
The provider network remains a shared infrastructure, offering services to multiple customers while
securely isolating the routing and packet forwarding of each customer. Moreover, the provider can
offer a full range of IP-enabled services to its customers.
Each customer router becomes a routing peer of the provider router that is directly connected to, not a
peer to the other customer routers. A customer router provides the provider router with routing
information for the private (not necessarily implementing private IP addressing) customer network.
Regardless of the routing exchange between the customer and provider routers, the provider
infrastructure is provisioned in such a way that from the point of view of the customer routers, they
appear to be directly connected at Layer 3.
The service provider can reuse the IP/MPLS infrastructure to offer multiple services to each or all
customers.
Module 5 Page 31
Service providers perspective: The IP/MPLS core infrastructure is shared

among multiple customers and can be reused to offer multiple services
VPRN Features
VPRN site additions or removals can be accomplished with

minimal additional configuration
The outer label allows traffic to transit across the MPLS
network.
The inner label determines the VPRN
Provides connectivity among any number of customer sites
Provides customer routers with transparent IP connectivity
without knowledge of the core router
Module 5 |
32
VPRNs take advantage of the dynamics of IP routing protocols, supporting site additions or removal of
the VPN using the same infrastructure.
This type of VPN invokes label stacking with a top label that allows traffic received from a customer to
transit the interior gateway protocol (IGP) service provider cloud and a bottom label that directs the
traffic to the appropriate outgoing interface or service towards the final destination of the customer
network.
An additional feature of the VPRN includes the ability to support any-to-any IP-only connectivity,
providing connectivity among any number of customer sites.
Module 5 Page 32
VPRN utilizes MPLS label stacking
VPRN Features (continued)
Simplifies the routing topology at customer sites

The service provider manages the core network and the customer
routes
Layer 2 is independent allows different Layer 2 connectivity at

customer sites
Allows the usage of overlapping private IP address space among
different customers
Different sites belonging to same customer can use different IP
subnets
Module 5 |
33
There are many benefits to be gained by implementing a Layer 3 VPRN service, such as:
Routing at customer sites can be simplified as the provider is managing the routed infrastructure.
Some sites can achieve full connectivity with only a default route.
The entire infrastructure can be provider-managed and provider-maintained.
Redundancy and resiliency are provided by the service providers infrastructure, and any architectural
benefits designed in the core can be leveraged by the customer.
Privacy is maintained by the isolation of each customer network and routing topology, which separates
routes into logical routing tables (VRF). The customer is permitted to use virtually any addressing
hierarchy and structure, independent of the providers choice of addressing and the addressing of any
other customer of the provider.
Any type of physical interconnection can be used between the CE and the PE provided that the
routers support the required interface type.
Module 5 Page 33
Customers receive the redundancy benefits designed in the

provider core
VPRN Architecture
Customer Edge devices (CE)
Module 5 |
34
The Customer Edge (CE) device is the interface from the customer site to the service provider
network. In a Layer 3 VPN, the CE device is typically a router; however, in some service
implementations, an Ethernet switch can be used as the CE device. In the VPRN context, the CE is
typically Layer 3-aware.
If the CE device is a switch, a static route pointing to the switch subnet is configured on the PE device.
The customer typically owns and operates these devices. These routers will run a routing protocol for
the purposes of internal routing at the site, using the customers choice of IP addressing. The CE also
runs a common routing protocol with the service provider router in order to exchange routes with the
provider network.
This routing protocol can be the same as or differ from the routing protocol used internally at the
customer site or in the provider network.
The CE is typically unaware of the existence of the MPLS protocol or the VPNs and runs standard IP
routing protocols.
Module 5 Page 34
Exchange IP routing information with other customer routers

at the same site
Exchange IP routing information with the service provider
CE devices are unaware of the existence of MPLS or the
VPRN
VPRN Architecture (continued)

Provider Backbone devices (PE and P)
Module 5 |
35
The service providers backbone consists of PE routers as well as other routers ("P routers") that do
not attach to CE devices.
The Provider Edge (PE) is the device that interfaces the customer network to the provider-managed
IP MPLS network. A PE is commonly shared among multiple customers, or in some cases, can be
dedicated to a single customer.
The provider owns and operates the PE devices in which each PE runs multiple instances of routing
protocols and serves a different purpose. They will run a routing protocol for the purposes of internal
routing in the provider core using the providers choice of IP addressing. There is typically only one
routing protocol instance used for this purpose.
The PE will run a routing protocol with all other PE devices in the provider core in order to exchange
VPRN routes. The PE also runs a common routing protocol with each connected CE to exchange
routes with the local customer site. This protocol can be the same or different than the routing protocol
used internally to the provider core.
Each instance of a routing protocol used for PE-CE routing should be fully isolated from the other. The
PE must be configured for MPLS and related protocols and must be aware of the VPRNs. They run
standard IP routing protocols for various exchanges of required routing information and additional
protocols that exchange MPLS-related information to enable the VPRN service.
Provider (P) devices are devices that comprise the internal provider network core. These devices can
be connected to other PE or P routers but do not have any connections to the CE. They will run a
routing protocol for the purposes of internal routing in the provider core using the providers choice of
IP addressing. There is typically only one routing protocol instance used for this purpose.
Module 5 Page 35
PE exchanges each customers routes (VPRN routes) with

other PEs
The VPN network layer is terminated at the PE
P routers are unaware of the PE to CE routing protocol

Label Stack
The outer label is known as the top, transport or LSP label

and identifies the transport tunnel between PEs.
The inner label is known as the service or VPN label and
identifies the customer VPRN.
Only the IP packet that is encapsulated for transmission

across the VPRN
Module 5 |
36
In the VPRN context, each packet should have a label stack consisting of two labels applied by the PE
router that receives the packet from the customer.
The top label is known as the outer label, transport label or LSP label and identifies the label
switched path (LSP) between PEs.
The inner label is known as the service label or VPN label and identifies the customer VPRN.
Note: Layer 2 encapsulation is removed and only the IP packet that is encapsulated for transmission
across the VPRN.
Module 5 Page 36
A VPRN service uses a label stack consisting of two labels.

Virtual routing and forwarding (VRF) table
Each PE contains an isolated routing table per VPRN service.
Module 5 |
37
A VRF is a logical private forwarding routing table created within a PE router. It securely isolates the
routing information of one customer from the next, and also from the routes of the provider core
network.
The SP network provides connectivity between same-customer sites while isolating customers from
each other. The keystone of the PE-based VPN model is the isolation between routing tables,
achieved at two levels:
Isolation between customersCustomer-specific routing tables (VRF tables) are used on the edge
routers. At any particular edge router, one VRF routing table is associated with each site connected to
that router. Entries from one VRF table do not leak to another unless explicitly configured to do so.
Isolation between core and edge routingProviders routes, used by PE routers to reach each other
over the provider backbone, are kept separate from customers routes. As a matter of fact, most
provider core routers (P-routers) store only these routes while overlooking customer routes.
Each PE router maintains a number of separate forwarding tables. One of the forwarding tables is the
default forwarding table. The others are VPN routing and forwarding tables or "VRFs".
VPRN service uses VRFs within a PE device to maintain forwarding information on a per-site basis.
Each PE can maintain multiple separate VRFs based on the number of customer sites it connects to.
Module 5 Page 37
A PE may maintain multiple VRFs.
VPRN Control Plane Routing Functions

CE to PE Routing Control Plane
PE to PE Routing Control Plane

CE routes are exchanged between PE routers
PE to CE Routing Control Plane

Propagates remote CE routes within the VRF to the locally attached CE
Module 5 |
38
The routing control plane function of the VPRN provides the necessary exchange of routing
information between devices that are aware of the VPRN. A PE maintains a specific VRF containing
routes for each VPRN. A CE maintains a standard IP routing table containing routes for the VPRN to
which it belongs.
The customer is running a routing protocol internal to their site. A PE learns the routes of a customer
site from the CE using the routing protocol configured between the CE and the PE. The internal
customer network routing protocol and the CE to PE routing protocol do not have to be identical.
PE maintains the base routing table with internal provider network routes and maintains separate
VRFs for the associated VPRNs. PE devices exchange routes among each other across the provider
core. Isolation must be maintained between the routes received from each customer (per-VRF) and
from provider core routes.
Routes received from each CE might need to be propagated to multiple remote PE devices.
PE to CE route exchange: a policy is required to advertise the remote customer routes to the local CE.
The PE-CE routing protocol, supported on the Alcatel-Lucent 7750, includes static routes, OSPF, RIP,
and BGP
Module 5 Page 38
CE routes are advertised to the PE and stored in the appropriate VRF
VPRN Control Plane Label Signaling

VPN labels are signaled between PE devices
VPN Label
Identifies the VPRN to which the prefix belongs
Module 5 |
39
All routers in the provider core are MPLS-enabled and perform MPLS label signaling and label
exchange functions in order to form the MPLS label switched path or LSP between PEs. The LSP
label is signaled for this purpose. These LSPs form the forwarding path between PE devices across
the provider core network.
Label signaling, used to create the LSP, is not sufficient to establish a VPRN service. The LSP label
only provides the packet with the information required to reach the far-end PE at the edge of the MPLS
domain. There is no indication of which VPRN the packet should be sent to once it reaches the edge.
VPN labels are also signaled between PE devices. VPN labels are used with other identification
values to differentiate between the specific customer destination networks.
VPN labels are the second set of labels used in the VPRN context to identify the customer site as the
destination of the VPRN service.
Module 5 Page 39
Identifies the customer network on the egress PE
VPRN Data Plane Functions

The customers data packets received from a CE will be
forwarded across the service providers network to the
remote CE.
CE to Ingress PE (VPRN Data Plane)
Module 5 |
40
CE devices are not MPLS-enabled and are only configured with traditional routing protocols.
The CE forwards unlabeled packets from the customer site to the PE based on the routing table of the
originating CE. The ingress PE receives the packets and pushes (inserts or imposes) a label stack
onto each customer packet.
The LSP label identifies the egress PE for this VPRN and the VPN label identifies the specific VPRN
(customer network) on the egress PE.
The VPRN appears as an IP router to the customer network. This means that data arriving at the
VPRN has the Layer 2 encapsulation removed and the PE makes a forwarding decision. It is the IP
packet that is encapsulated for transmission across the VPRN.
Module 5 Page 40
CEs forward unlabeled packets from the customer site to the

PE
The ingress PE pushes a label stack onto each customer packet
VPRN Data Plane Functions (continued)

PE to PE
The ingress PE sends the labeled packets to the provider core
Provider core P devices label-switch the packets to the correct egress PE
Egress PE to CE
The egress PE forwards unlabeled packets to the customer based on the
VPN label
Module 5 |
41
PE to PE:
The ingress PE switches the labeled packets into the provider core. The P devices internal to the
provider core label switch the packets to the correct egress PE using the LSP label.
The VPN label should never be visible to P devices since these devices forward exclusively based on
the LSP label. Moreover, there should not be any routing of customer packets by the P routers. For
customer packets, only label switching occurs in the provider core.
Egress PE to CE:
The egress PE receives a label stacked packet from the provider core. Since it is the endpoint of the
LSP, the LSP terminates. The LSP label is popped (removed) from the packet and the egress PE
exposes the VPN label in the packet.
The VPN label is now visible to the egress PE so it can determine which VPRN the packet is
associated with. The VPN label is popped (removed) from the packet. Based on the VRF associated
to the VPN label, the egress PE forwards unlabeled packets to the correct customer.
Module 5 Page 41
The egress PE receives label stacked packets from the provider core
Module 5 Layer 3 VPNs
Section 4 VPRN Control Plane Details
Module 5 Page 42
Section Objectives
Explain the role of virtual routing and forwarding instances

(VRFs) in establishing a VPRN service
Identify a VPN-IPv4 address family and explain its usage in

VPRN
Define a route distinguisher (RD) and explain its function
Explain how the VPRN routing information is distributed among

PE routers through the use of Multiprotocol BGP extensions
Module 5 |
43
Module 5 Page 43
Define a route target (RT) and explain how it is used to

identify the set of VPNs in which a particular VRF participates
Explain the requirements of distributing VPRN routing

information between PE-CE routers
List transport tunnel creation options and explain how they

are used in VPRN
Demonstrate VPN label signaling via MP-BGP
Module 5 |
44
Module 5 Page 44
Section Objectives (continued)
VPRN Control Plane Tasks

The MPLS/VPRN control plane consists of routing information and
label exchange
Distinct sets of routes must be exchanged
Distinct sets of labels must be exchanged

VPN service labels
Module 5 |
45
VPRN control plane tasks include the routing exchange and label exchange. Routes must be
exchanged between all routers in the provider network for core routing purposes and separately
between routers at the customer edge for VPRN connectivity.
Module 5 Page 45
Provider core routing

Customer VPRN routing
Overlapping IP Addressing
Route
Route Table
Table (Router:
(Router: Base)
Base)
===============================================================================
===============================================================================
Dest
Address
Next
Type
Proto
Age
Metric
Pref
Dest Address
Next Hop
Hop
Type
Proto
Age
Metric
Pref
------------------------------------------------------------------------------------------------------------------------------------------------------------10.1.1.0/24
CE_Blue
Remote
BGP
03d18h53m
0
170
10.1.1.0/24
CE_Blue
Remote BGP
03d18h53m 0
170
10.1.1.0/24
CE_Red
Remote
00h25m00s
170
10.1.1.0/24
CE_Red
Remote BGP
BGP
00h25m00s 00
170
Module 5 |
46
If BGP sessions are established between the PE devices, we can accomplish the goal of route
exchange and policy which can be applied to the exchange. Secondly, the provider core P routers do
not have to run BGP at all, eliminating the need for the P routers to manage the volume of routes
present and increasing security through the isolation of the P network from the customer routes.
BGP sessions established between PE devices will transport all VRF routes across the provider core.
The sessions must be established in a logical iBGP full mesh between all PE peers. BGP will also
provide the required separation of the provider core routing from the customer VRF routes since the
provider core routes are to never be carried by BGP.
Although BGP provides the scalable solution to the exchange of routes across the provider core, it
does not immediately address all issues. BGP was designed for public Internet use where all
addressing (and routes) are managed by a central authority and must be unique.
In the VPRN context, a provider core links separate sites of a private routed domain using the VPRN;
however, the provider deals with multiple customers. It is possible that any or all of these customers
have implemented private (RFC 1918) addressing in their network. Furthermore, it is possible that
more than one of these customers has implemented the same (overlapping) addressing.
If these customer networks were not linked by a common provider core, this would not present a
problem because the overlapping routes would be isolated from each other. This is not true in the
VPRN context since a single BGP session carries all prefixes between PEs across the same provider
core. BGP was not designed with this intention in mind, therefore you would not be able to see a
routing table similar to the one above in real situation. Therefore, we have to look for an alternative.
Module 5 Page 46
A single BGP session carries all prefixes between PEs across the
same provider core for all its customers
Overlapping IP Addressing Problem

Multiple customers can have the same IP address architecture
Routes from different customers with the same IPv4 address prefix
are treated as equivalent by BGP
Flag
Nexthop
LocalPref
Flag Network
Network
Nexthop
LocalPref MED
MED
VPN
As-Path
VPN Label
Label
As-Path
------------------------------------------------------------------------------------------------------------------------------------------------------------u*>
CE_Blue
none
none
u*> 10.1.1.0/24
10.1.1.0/24
CE_Blue
none
none
64496
64496
u*
10.1.1.0/24
CE_Red
none
none
u*
10.1.1.0/24
CE_Red
none
none
64497
64497
Module 5 |
47
An important consideration to note with overlapping addressing is that if BGPv4 sees two (or more)
separate entries for the same IPv4 address prefix, it will treat these prefixes as if they are going to the
same destination and will install only one route in the routing table (by default) based on the route
selection criteria.
In the case of VPRN, this poses a problem. The routes are for the same destination prefix but have
originated in different customer VPRNs. Therefore, they are completely separate and distinct
destination networks.
Module 5 Page 47
Only one route will be selected as 'best' according to the route

selection criteria
Solution: VPN-IPv4 Address Family
The VPN-IPv4 address family contains an identifier called the

route distinguisher (RD) whose sole purpose is to ensure that IP
prefixes are globally unique
VPN-IPv4 allows BGP to recognize multiple entries that exist with

the same prefixes but originate from distinct customers
Module 5 |
48
IP version 4 expects all address instances to be unique. In the VPRN model, it is expected that this will
not occur. A new addressing structure, called the VPN-IPv4 address family, is defined.
VPN-IPv4 Address Family
A solution to this problem requires a mechanism that allows BGP to recognize multiple entries that exist
with the same prefixes and have originated from distinct customers. This makes it possible to install
multiple routes for the same prefix in the BGP table with a unique identifier to distinguish from which
customer VPRN the route originated. RFC 4364 supports this capability by defining the VPN-IPv4
address family.
An RD is simply a number that does not contain any inherent information and does not identify the origin
of the route or the set of VPNs to which the route is to be distributed. The purpose of the RD is solely to
allow one to create distinct routes to a common IPv4 address prefix. Other means are used to determine
where to redistribute the route.
Module 5 Page 48
The RD is appended to the IPv4 prefix to form the 12-byte VPNIPv4 prefix
Route Distinguisher Format

The route distinguisher is an 8-byte parameter containing three fields:
Type (2 bytes)
Administrator (Length)
ALU supports the three types of RDs defined in RFC 4364

Type
Administrator
Assigned Number
VPN-IPv4 example
2 Bytes (Type 0)
2 Bytes (ASN)
4 Bytes
0:64496:100:10.1.1.0/24
2 Bytes (Type 1)
4 Bytes (IP Address)
2 Bytes
1:10.10.10.10:100:10.1.1.0/24
2 Bytes (Type 2)
4 Bytes (ASN)
2 Bytes
2:64496:100:10.1.1.0/24
Module 5 |
49
The Alcatel-Lucent 7750 SR supports type 0, 1, and 2 route distinguisher formats.

Type 0
Administrator subfield (2 bytes)
Assigned number subfield (4 bytes)
The administrator field must contain an AS number (using private AS numbers is discouraged). The assigned
number field contains a number assigned by the service provider.
Example: For the IPv4 address 10.1.1.0/24, the VPN-IPv4 address is 0:64496:100:10.1.1.0/24 where 64496 is
the AS number and 100 is the assigned number.
Type 1
The administrator field must contain an IP address (using a private IP address space is discouraged). The
assigned number field contains a number assigned by the service provider.
Example: For the IPv4 address 10.1.1.0/24, the VPN-IPv4 address is 1:10.10.10.10:100:10.1.1.0/24 where
10.10.10.10 is the IP address and 100 is the assigned number.
Type 2
The administrator field must contain a 4-byte AS number (using a private AS number is discouraged). The
assigned number field contains a number assigned by the service provider.
Example: For the IPv4 address 10.1.1.0/24, the VPN-IPv4 address is 2:64496:100:10.1.1.0/24 where 64496 is
the 4 byte AS number and 100 is the assigned number.
The VPN-IPv4 address appears only in the PE control plane - it is added when the prefix is exported from the
VRF to the VPRN. The CE router never sees the VPN-IPv4 address and it never appears anywhere in any IP
packet on the network. Usually, it makes sense to assign the same route distinguisher to the VRFs of sites
belonging to the same VPRN so that all the routes of the network will have the same route distinguisher. For
more information about BGP support for four-octet AS number space, refer to RFC 4893.
Module 5 Page 49
Assigned Number (Value)
Multiprotocol BGP (MP-BGP)
The VPN-IPv4 address family is only used in the provider core control plane
when exchanging MP-BGP routing updates.
Module 5 |
50
Multiprotocol Border Gateway Protocol (MP-BGP)

MP-BGP extensions are used to encode customer IPv4 address prefixes into unique VPN-IPv4
Network Layer Reachability Information (NLRI) values. NLRI refers to a destination address in MPBGP. In the context of IPv4 MP-BGP, NLRI refers to VPN-IPv4 Prefix that is carried in the BGP routing
updates.
The multiprotocol nature of MP-BGP allows the overlapping routing information to be transported
across the provider core as VPN-IPv4 addressing. VPRN routes are not distributed within the provider
core network as IPv4 routes, but as 12-byte VPN-IPv4 routes.
VPN-IPv4 addresses are only present within the service provider network and should never be made
visible to the customer. They are created at the ingress PE by appending a route distinguisher to the
customer route and are transported across the provider domain. At the egress PE, the route
distinguisher is removed from the route and a traditional IPv4 route is restored.
It is important to note that the VPN-IPv4 address family is used only in the provider core control plane
when exchanging MP-BGP routing updates between PEs. All data traffic is carried in standard IP
version 4 packets.
Module 5 Page 50
Multiprotocol BGP (MP-BGP) extensions allow VPN-IPv4 prefixes to

distribute VPRN routing information across the service providers network
MP-BGP Update
received at PE-2
The sending PE will add the RD to the IPv4 prefixes before sending the
VPN-IPv4 prefixes in MP-BGP updates
Problem: How will the receiving PE know which routes belong to which
VRFs?
Module 5 |
51
When using the MP-BGP: before sending an update to the remote PE, the sending PE will prepend a
unique (per-customer) 64-bit route distinguisher to each customers 32-bit IPv4 prefix thus exchanging
unique VPN-IPv4 routing updates with the remote PE. The PE routers (BGP peers) will send each
other these prepended VPN-IPv4 routes. Now how is the router going to know what routes belong to
which VRF?
A new identifier, separate from the route distinguisher, is required to associate a route to a VRF and
defines the VPRN membership of the route. This identifier is called route target.
Module 5 Page 51
Multiprotocol BGP (MP-BGP) (continued)
Route Target (RT)
Route Target (RT) is a BGP extended community used to advertise

the VPRN membership identifier to the receiving PE
Module 5 |
52
BGP-extended community is a mechanism for including additional information to be carried in BGP

updates. The route target (RT) is the closest approximation to a VPRN membership identifier in the
VPRN architecture, and identifies the VRF table that a prefix is associated with to the receiving PE.
When a VPN-IPv4 route is created (from an IPv4 route that the PE has acquired from a CE) by a PE
router, it is associated with one or more route target attributes. These are carried in BGP as attributes of
the route. Any route associated with route target T must be distributed to every PE router that has a VRF
associated with route target T. When such a route is received by a PE router, it is eligible to be installed
in the PEs VRFs that are associated with route target T.
A route target attribute can be thought of as identifying a set of sites or a set of VRFs. It is used to filter
the appropriate routes into the correct VRFs.
Module 5 Page 52
RT is the mechanism from which VPRN controls the distribution of

VPN routing information
MP-BGP Update
received at PE-2
MP-BGP updates include VPN-IPv4 unique addressing for customer routes

and the RT to identify VPRN membership at the receiving PE
The route target identifies to the receiving PE the VRF that a VPN-IPv4
prefix is associated with
Module 5 |
53
The routes associated with a VRF are exported out of the VRF table of the originating PE with
defined route target values associated to the prefix. VPN-IPv4 prefixes are exported by a PE with the
route target attached.
The receiving PE will install routes into the associated VRFs if its configured import route target is the
same value as the route target 'exported' by the originating PEs. For example, if routes are exported
on the sending PE with a route target value of '64496:10', these routes will only be imported into a
VRF on the receiving PE if that VRF imports route target values of '64496:10'.
Each VPRN route is tagged with one or more route target values when it is exported from a VRF by
the sending PE and transported across the provider core by MP-BGP. Therefore, the import route
target value of the receiving PE should match the export route target value of the originating PE.
You can also associate a set of route targets with a VRF, and any route tagged with at least one of
those route targets will be imported into the VRF. This technique allows the creation of complex VPRN
topologies. In these cases, a single VPRN might need more than one route target for successful
implementation, and VRF policies must be used instead of the simple vrf-target command. This is
discussed in details in the VPRN course.
Module 5 Page 53
Multiprotocol BGP (MP-BGP) (continued)
PE to CE Route Exchange
IPv4 routing information is exchanged between the PE and CE after
being received via MP-BGP updates over the provider core
Module 5 |
54
A routing protocol must be run between the PE and CE for the purposes of exchanging the customer
routing information from the receiving PE to the customer sites. The receiving PE will propagate routes
from the VRF to the CE as IPv4 routes.
Module 5 Page 54
Routing protocol, or static routes, may be used to propagate routes

to the CE
VPRN Label Signaling - VPN Service Labels

VPN Service Labels via MP-BGP
Inner MPLS (VPN) label is included in the MP-BGP update
Module 5 |
55
After the establishment of the routing topology in the provider core, the network must be MPLSenabled to support services such as VPRN. Transport tunnels must be created between the PEs. The
transport tunnel is either an MPLS LSP or a GRE point-to-point tunnel between PEs. These tunnels
serve as the label switched paths the customer packets will take as they cross the provider core
network.
VPRNs are also known as BGP/MPLS VPNs. BGP is used to distribute VPRN routing information
across the provider's backbone and MPLS is used to forward VPRN traffic from one VPRN site to
another. BGP is a fundamental protocol in the VPRN implementation that is used in the control plane
for both routing exchange and label signaling. Multiprotocol extensions to BGP (MP-BGP) convey the
inner label that a specific VPRN uses between different PE routers. MP-BGP is also used to advertise
routes between VPRN sites.
Alcatel-Lucent 7750 SR routers support MP-BGP for VPN label signaling for VPRN service regardless
of whether RSVP-TE or LDP is used for the LSP signaling
Module 5 Page 55
Tells the far-end PE which label to push on the stack such that VPRN data is
encapsulated to the correct VRF
Creating MPLS Transport in a VPRN

Using the auto-bind option under the VPRN service instance
auto-bind allows a VPRN service to automatically resolve the BGP nexthop from VPRN routes to a GRE or MPLS LSP
Alcatel-Lucent 7750 SR supports auto-bind {ldp|gre|rsvp-te|mpls}

options
Configure SDP and bind the VPRN service instance to the SDP
instance
Module 5 |
56
The 7750 SR supports multiple mechanisms to provide transport tunnels for the forwarding of traffic between PE
routers:
RSVP-TE protocol to create tunnel LSP's between PE routers
LDP protocol to create tunnel LSP's between PE routers
GRE tunnels between PE routers.
The transport tunnel in a VPRN is created either by configuring the auto-bind option under the VPRN service
instance or by configuring an SDP and binding the VPRN service instance to the SDP instance.
When the 'auto-bind' command is used, next-hop resolution refers to the base (core) routing instance for IP
reachability. For VPRN service, auto-bind specifies the lookup to be used by the routing instance if an SDP to the
destination does not exist. In this way auto-bind acts as a replacement by creating SDPs for the transport tunnels
manually.
Auto-bind ldp binds the VPRN service to the LDP FECs in the core without the need to configure SDPs explicitly
Auto-bind rsvp-te
Allows the use of traffic-engineered paths between PE routers for VPRN services without explicitly
defining them through the SDP configuration mechanism.
If configured, this feature will use the RSVP-TE-based LSP with the lowest metric to resolve the MPBGP route within a VPRN context.
Auto-bind mpls allows auto-bind to select available RSVP-TE or LDP LSPs to resolve IP-VPN routes from
remote PEs.
For VPRN services, SDP tunnels can be created using MPLS/rsvp-te. If SDP-based tunnels are used, they must
be created prior to their binding to the VPRN service. The configuration of an SDP includes specifying the far-end
PE address and the type of encapsulation used, such as MPLS.
Module 5 Page 56
auto-bind specifies the lookup to be used by the routing instance if an

SDP to the destination does not exist
Section 5 VPRN Case Study
Module 5 Page 57
Section Objectives
Identify the requirements for a successful operation of a VPRN

service
Configure a MP-BGP for the provider network and verify its

operation
Configure VPRN service instances and verify their operations
Configure a PE-CE routing protocol (BGP) and verify its

operation
Module 5 |
58
Module 5 Page 58
Demonstrate an end-to-end route exchange for a given VPRN

network.
Demonstrate an end-to-end data flow for a given VPRN

network.
Verify that the VPRN service is operational using OAM tools

(oam vprn ping, oam vprn trace)
Complete Lab 9 Configure and verify basic IPv4 VPRN using

LDP.
Module 5 |
59
Module 5 Page 59
Section Objectives (Continued)
Module 5 |
60
The network diagram will be used to demonstrate the configuration and operation of VPRN.
The loopback interfaces simulate locally-connected networks.
Customer sites, belonging to different VPRNs, will be able to use the same private IP address space.
Module 5 Page 60
Network Diagram
VPRN Implementation
Successful operation of a VPRN service requires the following
preliminary configuration steps:
Configure the foundation network infrastructure
Configure the IGP for the provider core routing protocol
Configure MP-BGP between PE devices
Configure the CE-PE routing protocol
Module 5 |
61
Students should be able to configure the foundation network infrastructure, IGP for provider core
routing (OSPF is used), and the provider core for MPLS tunneling (LDP is used). These configurations
are not shown.
Note: If the tunnel type is chosen to be IP/GRE, then no MPLS tunneling configuration is needed.
Module 5 Page 61
Configure the provider core for MPLS tunneling (if desired)
Provider Core Network Preparation

OSPF is selected as the IGP routing in the core
A:PE1>config>router>ospf# info
---------------------------------------------area 0.0.0.0
interface "system"
exit
interface "toPE2"
exit
exit
----------------------------------------------
A:PE1>config>router>ldp# info
-----------------------------------------interface-parameters
interface "toPE2"
exit
exit
targeted-session
exit
------------------------------------------
Module 5 |
62
Configure the IGP routing protocol (IGP for the provider core network) on the system interface
and all provider-core-facing interfaces of all PE and P devices. Typically OSPF or IS-IS are
used.
Module 5 Page 62
LDP is used to provide MPLS tunneling
Configuring MP-BGP
PE1# configure router autonomous-system 64496

PE2# configure router autonomous-system 64496
Configure a MP-BGP session between the PE routers

A:PE1>config>router>bgp# info
---------------------------------------------group "multi-bgp
family vpn-ipv4
peer-as 64496
neighbor 10.10.10.2
local-address 10.10.10.1
exit
exit
----------------------------------------------
A:PE2>config>router>bgp# info
---------------------------------------------group "multi-bgp
family vpn-ipv4
peer-as 64496
neighbor 10.10.10.1
exit
exit
----------------------------------------------
Module 5 |
63
To enable BGP on the PE devices, the BGP autonomous system number is first configured in the
global context.
The MP-BGP sessions established between the PE routers allow for the exchange of customer VPRN
routes across the service provider core network. Sessions must be established between all PE routers
in the MPLS domain to ensure a scalable and reliable implementation. The MP-BGP sessions also
enable the exchange of VPN labels which are transported along with the routing information in MPBGP updates.
To transport VPN-IPv4 routes, the 'vpn-ipv4' address family must be configured under the BGP
context. All remaining parameters related to the MP-BGP session are then configured under the 'vpnipv4' address family in a fashion similar to the configuration of traditional BGP neighbors.
Defining a BGP group is mandatory; within this group, the peer parameters will be configured. The
remote and local device addresses used for the session must be defined. The MP-BGP sessions
should always be established between the system addresses of each PE device.
Module 5 Page 63
Configure the BGP autonomous system
Verifying MP-BGP sessions
A:PE1# show router bgp neighbor

------------------------------------------------------------------------------BGP Neighbor
------------------------------------------------------------------------------Peer : 10.10.10.2
Group : multi-bgp
------------------------------------------------------------------------------Peer AS
: 64496
Peer Port
: 179
Peer Address
: 10.10.10.2
Local AS
: 64496
Local Port
: 50603
Local Address
: 10.10.10.1
Peer Type
: Internal
State
: Established
Last State
: OpenSent
Last Event
: recvKeepAlive
Last Error
: Cease
Local Family
: VPN-IPv4
Remote Family
: VPN-IPv4
-output omitted Local Capability
: RtRefresh MPBGP 4byte ASN
Remote Capability
: RtRefresh MPBGP 4byte ASN
Import Policy
: None Specified / Inherited
Export Policy
: None Specified / Inherited
------------------------------------------------------------------------------Neighbors : 1
Module 5 |
64
The show router bgp neighbor command is used to verify the details of the BGP sessions of the PE,
including the operational status of the MP-BGP sessions.
The following is shown in the slide:
The verification of the internal PE neighbor
The VPN-IPv4 address family is supported between the neighbors for the purpose of VPRN
route exchange
Module 5 Page 64
Check that the MP-BGP sessions are established between all PE

routers.
Configuring a VPRN on the PE

The steps required to configure a VPRN include:
Creating customer accounts
Create VPRN service instances
Define route distinguishers
Define route targets
Configuring VPRN interfaces
Configuring the tunnel type
Activating the VPRN service
Module 5 |
65
The service configuration commands to provision a VPRN service are located under the
config>service>vprn context
The show commands are in the show>service context.
A summary of the steps required to provision a VPRN customer are shown and detailed in the
following pages. Only the configurations on PE1 will be shown.
Module 5 Page 65
Configuring VPRN service instances
Creating a Customer Account
PE1# configure service

PE1>config>service# customer 10 create
PE1>config>service>cust# description "Customer Blue"
PE1>config>service>cust# exit all
PE1#

PE1>config>service# customer 20 create
PE1>config>service>cust# description "Customer Red"
PE1>config>service>cust# exit all
PE1#
Module 5 |
66
All customer accounts must have a customer ID.

Other parameters are configurable under the customer context but are optional and include the
following:
Description
Contact name
Telephone number
Module 5 Page 66
Create a customer record on each PE where the VPRN service must be

provisioned.
Creating a VPRN Service
PE1>config>service# vprn 10 customer 10 create

PE1>config>service>vprn$ description "VPRN Service for Customer Blue"
PE>config>service>vprn$ router-id 10.10.10.1
PE1>config>service>vprn$
PE1>config>service# vprn 20 customer 20 create

PE1>config>service>vprn$ description "VPRN Service for Customer Red"
PE>config>service>vprn$ router-id 10.10.10.1
Module 5 |
67
The VPRN service must be defined and associated to the customer ID created in an earlier
configuration. A description for the VPRN should always be included for ease of reference and
troubleshooting.
The router ID is manually configured to establish a predictable identifier for the protocols that require
one, such as OSPF and BGP. This is preferred over leaving the router ID selection to the default
mechanism, which can result in unpredictable values.
The creation of the VPRN for customer Blue and customer Red in PE1 is shown in the slide.
Module 5 Page 67
Create VPRN services associated with the customers IDs.
Available options to add or select routes based on the RT on 7750

SR are:
vrf-target {<ext-community>|export <ext-community>|import
<ext-community>}
vrf-import <policy-name> [<policy-name>...(upto 5 max)]
vrf-export <policy-name> [<policy-name>...(upto 5 max)]
Specified vrf-import or vrf-export policies override the vrf-target

policy
Module 5 |
68
The simplest way is to use the vrf-target command. For example, the command vrf-target
target:64496:10 will add the community string target:64496:10 to all routes taken from the VRF into MPBGP and select all MP-BGP routes with this community string and put them in the VRF.
Context:
Syntax:
community>}
Parameters:
Default:
config>service>vprn
- vrf-target {<ext-community>|export <ext-community>|import <ext- no vrf-target
<ext-community> :
target:{<ip-addr:comm-val>|
<2byte-asnumber:ext-comm-val>|
<4byte-asnumber:comm-val>}
ip-addr
- a.b.c.d
comm-val
- [0..65535]
2byte-asnumber - [0..65535]
ext-comm-val
- [0..4294967295]
4byte-asnumber - [0..4294967295]
no vrf-target
Description: This command facilitates a simplified method to configure the route target to be added to
advertised routes or to be compared against received routes from other VRFs on the same or remote
PE routers (via MP-BGP).VPN-IPv4 routes imported with a vrf-target statement will use the BGP
preference value of 170 when imported from remote PE routers, or retain the protocol preference value
of the exported route when imported from other VRFs in the same router.
vrf-import
- vrf-import <policy-name> [<policy-name>...(upto 5 max)]
- no vrf-import
vrf-export
- vrf-export <policy-name> [<policy-name>...(upto 5 max)]
- no vrf-export
Module 5 Page 68
Configuring Route Targets
Configuring the Route Distinguisher and Route Target
It is mandatory to define a route distinguisher for the VPRN.

PE1>config>service# vprn 10
PE1>config>service>vprn$ route-distinguisher 64496:1
The route target will be added to advertised routes and compared to the
value contained in received routes.
PE1>config>service>vprn$ vrf-target target:64496:10
PE1>config>service>vprn$ vrf-target target:64496:20
Module 5 |
69
The route-distinguisher command sets the identifier attached to routes that distinguish the VPN they
belong to. Each routing instance must be associated with a unique (within the carriers domain) route
distinguisher. A route distinguisher must be defined for a VPRN to be operationally-active.
The vrf-target command facilitates a simplified method to configure the route target to be added to
advertised routes or compared against received routes from other VRFs on the same or remote PE
routers (using MP-BGP).
The vrf-target command does not allow multiple export or import route targets to be specified.
Module 5 Page 69
PE1>config>service>vprn$ route-distinguisher 64496:2
Creating the VPRN Interfaces
PE1>config>service>vprn# interface "toCE1" create
PE1>config>service>vprn>if$ description "Customer BlueSite1"
PE1>config>service>vprn>if$ address 10.1.3.1/27
PE1>config>service>vprn>if$ sap 1/1/3 create
PE1>config>service>vprn>if$ exit all
PE1>config>service>vprn# interface "toCE3" create
PE1>config>service>vprn>if$ description "Customer RedSite1"
PE1>config>service>vprn>if$ address 10.1.6.1/27
PE1>config>service>vprn>if$ sap 1/1/2 create
PE1>config>service>vprn>if$ exit all
Module 5 |
70
The PE routers customer-facing interfaces are configured and associated to the VPRN service.
Module 5 Page 70
A minimum of one interface must be created and associated with each

VPRN service on the PE.
Configuring the Tunnel Type

The auto-bind ldp command is used in this case study. It binds LDPbased transport tunnels to the VPRN service.
*A:PE1# configure service vprn 10

*A:PE1>config>service>vprn# info
#------------------------------------------------service
vprn 10 customer 10 create
description "Customer Blue"
router-id 10.10.10.1
autonomous-system 64496
route-distinguisher 64496:1
auto-bind ldp
vrf-target target:64496:10
interface "toR3" create
address 10.1.3.1/27
sap 1/1/3 create
exit
exit
Module 5 |
71
auto-bind ldp is used in this case study.

The auto-bind ldp feature is only used for the VPRN service via LDP-based transport tunnels.
Module 5 Page 71

PE1>config>service# vprn 10 customer 10
PE1>config>service>vprn# auto-bind ldp
PE1>config>service>vprn# exit all
Select the PE to CE routing protocol (BGP is used in this case)
Configure the PE
Define the route policy on the PE
Configure the VPRN routing protocol
Configure the CE
Define the route policy on the CE (optional)
Configure BGP on the CE
The same PE-CE routing protocol is not mandatory for all sites
Module 5 |
72
Static routing, RIP, OSPF, or BGP can be used as the PE-CE routing protocol. In this case study, BGP
will be used.
When BGP is used as the PE-CE routing protocol, PE and CE routers will become BGP peers. The CE
will use BGP to tell the PE router the set of address prefixes that are reachable at the router site of the
CE.
To configure BGP on the PE, the BGP instance must be created under the VPRN service context. The
CE is configured with a standard BGP instance, since it is not MPLS-aware.
When BGP is configured in the CE, care must be taken to ensure that address prefixes from other sites
(for example, address prefixes learned by the CE router from the PE router) are never displayed to the
PE. Specifically, if a PE router receives a VPN-IPv4 route and as a result distributes an IPv4 route to a
CE, then that route must not be distributed back from the site of the CE to a PE router, either from the
same or a different router.
This topic is discussed in further detail in the VPRN course.
Module 5 Page 72
Configuring PE to CE Routing
PE1 and PE2 are already MP-BGP peers

CE1 and CE3 will be configured as BGP peers of PE1
CE2 and CE4 will be configured as BGP peers of PE2
Module 5 |
73
If BGP is used as the PE-CE protocol, then each PE device will have multiple BGP peerings. The MPBGP mesh must be maintained between PE devices. Meanwhile, a traditional BGP session must be
established for each CE running BGP with the PE.
Module 5 Page 73
BGP Peerings
Defining the PE-CE Route Policy on the PE
*A:PE1>config>router>policy-options# info
*A:PE1>config>router>policy-options# info
------------------------------------------------------------------------------------------policy-statement "mpbgp-bgp"
policy-statement "mpbgp-bgp"
entry 10
entry 10
from
from
protocol bgp-vpn
protocol bgp-vpn
exit
exit
action accept
action accept
exit
exit
exit
exit
exit
exit
-------------------------------------------------------------------------------------------
Module 5 |
74
Policy must be defined to allow the exchange of routes from MP-BGP into the configured PE-CE
protocol. The route policy can be applied as an import policy or an export policy. The policies must be
defined before they can be applied.
Routes that belong to a VPRN must use the protocol owner, VPN-IPv4, to denote that it is a VPRN
route. This can be used within the route policy match criteria.
Module 5 Page 74
VPN route exchange from MP-BGP to BGP is controlled by policy.
Configuring BGP on the PE
PE1# configure service vprn 10

PE1>config>service>vprn# autonomous-system 64496
PE1>config>service>vprn# bgp
PE1>config>service>vprn>bgp$ group "toCE1"
PE1>config>service>vprn>bgp>group$ neighbor 10.1.3.3
PE1>config>service>vprn>bgp>group>neighbor$ export mpbgp-bgp
PE1>config>service>vprn>bgp>group>neighbor$ peer-as 64497

Module 5 |
75
The PE must also be configured with BGP by defining the CE as a peer. This is done in traditional BGP
fashion. All PE BGP configuration is performed under the service context, including the autonomous
system number, except in the case of VPRN.
The defined policy is applied to the configured PE-CE routing protocol as a route export policy to control
the flow of routing information from MP-BGP to BGP.
Module 5 Page 75
The defined policy is applied to the VPRN BGP instance to

control the exchange of routes from MP-BGP to BGP.
Defining the Route Policy on the CE
*A:CE1>config>router>policy-options# info
*A:CE1>config>router>policy-options# info
------------------------------------------------------------------------------------------policy-statement "direct-bgp"
policy-statement "direct-bgp"
entry 10
entry 10
from
from
protocol direct
protocol direct
exit
exit
to
to
protocol bgp
protocol bgp
exit
exit
action accept
action accept
exit
exit
exit
exit
exit
exit
-------------------------------------------------------------------------------------------
Module 5 |
76
Recall that in this case study we are using the loopback interfaces to simulate locally connected
networks. It is more likely that the customer would be running a routing protocol like OSPF, in that case
the OSPF routes need to be exported into BGP.
Module 5 Page 76
A policy is configured on the CE to control the advertisement

of the customer site routes into BGP.
Configuring the CE for BGP
CE1# configure router

CE1>config>router# autonomous-system 64497
CE1>config>router# bgp
CE1>config>router>bgp$ group toPE1"
CE1>config>router>bgp>group$ peer-as 64496
CE1>config>router>bgp>group$ neighbor 10.1.3.1
CE1>config>router>bgp>group$ export "direct-to-bgp"
CE1>config>router>bgp>group>neighbor$ exit all

Module 5 |
77
The CE will be configured with BGP as the routing protocol, as shown in the slide.
Note: the autonomous system is defined in the global context and a policy is specified to control the set
of prefixes exchanged with peers.
Module 5 Page 77
Configure the CE for BGP with the specified route policy applied.
A:PE1# show router 10 bgp summary

A:PE1# show router 10 bgp summary
===============================================================================
===============================================================================
BGP Router ID:10.10.10.1
AS:64496
Local AS:64496
AS:64496
Local AS:64496
===============================================================================
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 1
Total Peer Groups
: 1
Total Peers
: 1
Total BGP Paths
: 4
Total Path Memory
: 512
Total BGP Paths
: 4
Total Path Memory
: 512
Total IPv4 Remote Rts
: 3
Total IPv4 Rem. Active Rts : 2
: 3
: 0
: 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
Total Decay Rts
: 0
===============================================================================
===============================================================================
BGP Summary
BGP Summary
===============================================================================
===============================================================================
Neighbor
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
PktSent OutQ
------------------------------------------------------------------------------------------------------------------------------------------------------------10.1.3.3
10.1.3.3
64497
13750
0 04d19h23m 3/2/3 (IPv4)
64497
13750
0 04d19h23m 3/2/3 (IPv4)
13845
0
13845
0
Module 5 |
78
When issued from the PE, the CE should appear as a BGP neighbor under the show router <service
id> bgp summary command.
The details of the CE-PE BGP neighbor relationship will be visible under the show router <service id>
bgp neighbor command.
Module 5 Page 78
Verifying BGP Peering
CE Routing Table
Routing table on CE1 before enabling the VPRN service
===============================================================================
===============================================================================
===============================================================================
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Dest Prefix
Type
Proto
Age
Pref
Metric
Metric
------------------------------------------------------------------------------------------------------------------------------------------------------------10.1.3.0/27
Local
Local
01h35m30s
0
10.1.3.0/27
Local
Local
01h35m30s
0
toPE1
0
toPE1
0
10.10.10.3/32
Local
Local
05d04h01m
0
10.10.10.3/32
Local
Local
05d04h01m
0
system
0
system
0
192.168.1.0/27
Local
Local
01h14m50s
0
192.168.1.0/27
Local
Local
01h14m50s
0
BlueSite1
0
BlueSite1
0
------------------------------------------------------------------------------------------------------------------------------------------------------------No. of Routes: 6
No. of Routes: 6
===============================================================================
===============================================================================
Module 5 |
79
The show router route-table command (in this case on the CE) is used to verify the contents of the
base routing instance.
As shown in the slide, this table contains only the locally connected customer routes. There are no
remote routes as the VPRN service is not yet enabled.
Module 5 Page 79
A:CE1# show router route-table

Enabling the VPRN Service

#-------------------------------------------------#-------------------------------------------------service
service
auto-bind ldp
auto-bind ldp
address 10.1.3.1/27
address 10.1.3.1/27
sap 1/1/3 create
sap 1/1/3 create
exit
exit
exit
exit
bgp
bgp
group "toCE1"
group "toCE1"
neighbor 10.1.3.3
neighbor 10.1.3.3
export "mbgp-bgp"
export "mbgp-bgp"
peer-as 64497
peer-as 64497
exit
exit
exit
exit
exit
exit
no shutdown
no shutdown
Module 5 |
80
To enable the VPRN service, no shutdown command is used. The slide shows the complete VPRN
configuration on PE1 for customer Blue. Similar configurations are on PE2 as shown below:
---------------------------------------vprn 10 customer 10 create
auto-bind ldp
address 10.2.4.2/27
sap 1/1/3 create
exit
exit
bgp
group "toCE2"
neighbor 10.2.4.4
export "mbgp-bgp"
peer-as 64498
exit
exit
exit
no shutdown
Module 5 Page 80
Complete the VPRN service configuration on PE1 for

Customer Blue.
Verifying the VPRN Service

Verify that the VPRN Service is operational.
Route Dist.
Dist.
ASRoute
Number
AS Number
ECMP
ECMP
Max
IPv4 Routes
MaxIPv6
IPv4Routes
Routes
Max
Max IPv6
Routes
Ignore
NH Metric
Ignore
NH Metric
Hash
Label
Hash
Label
Vrf Target
Vrf
Target
Vrf Import
VrfExport
Import
Vrf
Vrf Vrf
Export
MVPN
Target
MVPNVrf
VrfImport
Target
MVPN
MVPN
VrfExport
Import
MVPN Vrf
MVPN Vrf Export
: 64496:1
64496:1
: :64496
64496
: :Enabled
: :NoEnabled
Limit
Limit
: :NoNoLimit
No Limit
: :Disabled
:
Disabled
: Disabled
:
Disabled
: target:64496:10
target:64496:10
: :None
None
: :None
None
: :None
None
: :None
:
None
: None
: None
VPRN Type
VPRN Type
Router
Id
Router
ECMP
Max Id
Routes
ECMPBind
Max Routes
Auto
Auto Bind
: regular
regular
: :10.10.10.1
: :1 10.10.10.1
1
: :LDP
: LDP
SAP Count
: 1
SDP Bind Count
: 0
SAP Count
: 1
SDP Bind Count
: 0
------------------------------------------------------------------------------------------------------------------------------------------------------------Service
Access & Destination Points
Service
Access
&
Destination
Points
------------------------------------------------------------------------------------------------------------------------------------------------------------Identifier
Type
Identifier
Type
------------------------------------------------------------------------------------------------------------------------------------------------------------sap:1/1/3
null
1514
1514
Up
Up
sap:1/1/3
null
1514
1514
Up
Up
Module 5 |
81
The show service id <id> base command displays detailed information for a particular service ID.
Shown in this slide is the verification of the configuration of auto-bind for LDP, the configured route
distinguisher and the route target.
Note: the SAP count is 1, indicating that a SAP has been associated to this service; however, the
SDP bind count is 0 because we have not used an SDP in this configuration.
Module 5 Page 81
A:R1# show service id 10 base

A:R1# show service id 10 base
===============================================================================
===============================================================================
Service
Basic Information
===============================================================================
===============================================================================
Service
Id
: 10
Vpn Id
: 0
Service
Id
10
Vpn Id
: 0
Service Type
: :VPRN
Service Type
VPRNSpecified)
Name
: :(Not
Name
(Not Specified)
Description
: :Customer
Blue
Description
Customer
Id
: :10Customer Blue
Customer
10
Last
StatusIdChange: :03/23/2011
13:43:51
LastMgmt
Status
Change:
03/23/201113:43:51
13:43:51
Last
Change
: 03/23/2011
Last
Mgmt
Change
Admin State
: :Up03/23/2011 13:43:51Oper State
: Up
Admin State
: Up
Oper State
: Up
Verifying the VPRN Service (continued)
Verify the routing table on the CE.
===============================================================================
===============================================================================
===============================================================================
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Dest Prefix
Type
Proto
Age
Pref
Metric
Metric
------------------------------------------------------------------------------------------------------------------------------------------------------------10.1.3.0/27
Local
Local
01h35m30s
0
10.1.3.0/27
Local
Local
01h35m30s
0
toPE1
0
toPE1
0
10.2.4.0/27
Remote BGP
00h27m11s
170
10.2.4.0/27
Remote BGP
00h27m11s
170
10.1.3.1
0
10.1.3.1
0
10.10.10.3/32
Local
Local
05d04h01m
0
10.10.10.3/32
Local
Local
05d04h01m
0
system
0
system
0
10.10.10.4/32
Remote BGP
00h27m11s
170
10.10.10.4/32
Remote BGP
00h27m11s
170
10.1.3.1
0
10.1.3.1
0
192.168.1.0/27
Local
Local
01h14m50s
0
192.168.1.0/27
Local
Local
01h14m50s
0
BlueSite1
0
BlueSite1
0
192.168.2.0/27
Remote BGP
00h27m11s
170
192.168.2.0/27
Remote BGP
00h27m11s
170
10.1.3.1
0
10.1.3.1
0
------------------------------------------------------------------------------------------------------------------------------------------------------------No. of Routes: 6
No. of Routes: 6
===============================================================================
===============================================================================
Module 5 |
82
The show router route-table command (in this case on the CE) is used to verify the contents of the
base routing instance.
As shown in the slide, this table should contain customer routes only. The service ID parameter is not
required on the CE because this device is not MPLS-aware and runs only standard IGP routing
protocols.
Module 5 Page 82

Verify the VPRN services routing table on the PE.
===============================================================================
===============================================================================
Route Table (Service: 1)
Route Table (Service: 1)
===============================================================================
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Dest Prefix
Type
Proto
Age
Pref
Metric
Metric
------------------------------------------------------------------------------------------------------------------------------------------------------------10.1.3.0/27
Local
Local
00h26m35s
0
10.1.3.0/27
Local
Local
00h26m35s
0
toCE1
0
toCE1
0
10.2.4.0/27
Remote BGP VPN 00h40m13s
170
10.2.4.0/27
170
10.10.10.2 (tunneled)
0
10.10.10.2 (tunneled)
0
10.10.10.3/32
Remote BGP
00h25m45s
170
10.10.10.3/32
Remote BGP
00h25m45s
170
10.1.3.3
0
10.1.3.3
0
10.10.10.4/32
170
10.10.10.4/32
170
10.10.10.2 (tunneled)
0
10.10.10.2 (tunneled)
0
192.168.1.0/27
Remote BGP
00h25m45s
170
192.168.1.0/27
Remote BGP
00h25m45s
170
10.1.3.3
0
10.1.3.3
0
192.168.2.0/27
170
192.168.2.0/27
170
10.10.10.2 (tunneled)
0
10.10.10.2 (tunneled)
0
------------------------------------------------------------------------------------------------------------------------------------------------------------No. of Routes: 6
No. of Routes: 6
===============================================================================
===============================================================================
Module 5 |
83
The show router <service-id> route-table command is used to verify the contents of the routing
instance for the specified service.
As shown in the slide, this table should contain customer routes such as physical links to the PE
devices, system interfaces of the CE devices, and internal customer LAN networks.
The prefixes received from the local CE will be learned from the configured PE-CE protocol (BGP), while
the prefixes received from the remote CE will be learned from the BGP VPN (MP-BGP) protocol.
Module 5 Page 83
A:PE1# show router 10 route-table

A:PE1# show router 10 route-table

Verify the MPLS labels with an active binding
The label owned by VPRN is the VPN label for the service.
The label owned by LDP is the transport tunnel label for the service.
A:PE1# show router mpls label 32 131071 in-use

A:PE1# show router mpls label 32 131071 in-use
=================================================================
=================================================================
MPLS Labels from 32 to 131071 (In-use)
MPLS Labels from 32 to 131071 (In-use)
=================================================================
=================================================================
Label
Label Type
Label Owner
Label
Label Type
Label Owner
--------------------------------------------------------------------------------------------------------------------------------131068
dynamic
VPRN
131068
dynamic
VPRN
131069
dynamic
VPRN
131069
dynamic
VPRN
131070
dynamic
ILDP
131070
dynamic
ILDP
131071
dynamic
ILDP
131071
dynamic
ILDP
--------------------------------------------------------------------------------------------------------------------------------In-use labels (Owner: All) in specified range
: 4
In-use labels (Owner: All) in specified range
: 4
In-use labels in entire range
: 4
In-use labels in entire range
: 4
=================================================================
=================================================================
Module 5 |
84
The show router mpls label command displays the bindings of the in-use MPLS labels and their
owner. In this case, there should be labels bound to LDP as a result of the transport tunnel signaling
and labels bound to the VPRN as a result of MP-BGP service label signaling.
ILDP is an interface LDP and refers to the transport tunnel (LSP) label, while VPRN refers to the inner
(VPN) label.
Although it is considered optional to configure MPLS when using LDP as the label signaling protocol,
any show router mpls command can be available when MPLS is enabled.
Module 5 Page 84
If RSVP were configured, the label owned by RSVP would be the LSP
label.
A:PE1# show router bgp routes vpn-ipv4

===============================================================================
===============================================================================
AS:64496
Local AS:64496
AS:64496
Local AS:64496
Legend Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
===============================================================================
BGP VPN-IPv4 Routes
BGP VPN-IPv4 Routes
===============================================================================
===============================================================================
Flag Network
LocalPref
MED
Flag Network
LocalPref
MED
Nexthop
VPNLabel
Nexthop
VPNLabel
As-Path
As-Path
------------------------------------------------------------------------------------------------------------------------------------------------------------u*>i 64496:1:10.2.4.0/27
100
None
u*>i 64496:1:10.2.4.0/27
100
None
10.10.10.2
131069
10.10.10.2
131069
No As-Path
No As-Path
u*>? 64496:1:10.10.10.4/32
100
None
u*>? 64496:1:10.10.10.4/32
100
None
10.10.10.2
131069
10.10.10.2
131069
64498
64498
u*>? 64496:1:192.168.2.0/27
100
None
u*>? 64496:1:192.168.2.0/27
100
None
10.10.10.2
131069
10.10.10.2
131069
64498
64498
u*>i 64496:2:10.2.5.0/27
100
None
u*>i 64496:2:10.2.5.0/27
100
None
10.10.10.2
131068
10.10.10.2
131068
No As-Path
No As-Path
u*>? 64496:2:10.10.10.5/32
100
None
u*>? 64496:2:10.10.10.5/32
100
None
10.10.10.2
131068
10.10.10.2
131068
64450
64450
u*>? 64496:2:192.168.2.0/27
100
None
u*>? 64496:2:192.168.2.0/27
100
None
10.10.10.2
131068
10.10.10.2
131068
64450
64450
Routes : 6
Routes : 6
Module 5 |
85
The show router bgp routes vpn-ipv4 command displays the VPN-IPv4 routes received by PE1,
including the VPN label.
Module 5 Page 85
Verify that the VPN-IPv4 routes are received.
A:PE1# show router 10 fib 1

A:PE1# show router 10 fib 1
===============================================================================
===============================================================================
FIB Display
FIB Display
===============================================================================
===============================================================================
Prefix
Protocol
Prefix
Protocol
NextHop
NextHop
------------------------------------------------------------------------------------------------------------------------------------------------------------10.1.3.0/27
LOCAL
10.1.3.0/27
LOCAL
10.1.3.0 (toCE1)
10.1.3.0 (toCE1)
10.2.4.0/27
BGP_VPN
10.2.4.0/27
BGP_VPN
10.10.10.2 (VPRN Label:131069 Transport:LDP)
10.10.10.3/32
BGP
10.10.10.3/32
BGP
10.1.3.3 Indirect (toCE1)
10.10.10.4/32
BGP_VPN
10.10.10.4/32
BGP_VPN
192.168.1.0/27
BGP
192.168.1.0/27
BGP
192.168.2.0/27
BGP_VPN
192.168.2.0/27
BGP_VPN
------------------------------------------------------------------------------------------------------------------------------------------------------------Total Entries : 6
Total Entries : 6
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Module 5 |
86
The show router <service id> fib command can be used to verify the contents of the FIB.
Prefixes learned from traditional routing mechanisms are listed and associated with the traditional IP
forwarding parameters of the next-hop address and egress interface.
Prefixes learned from MP-BGP as VPN-IPv4 routes are listed and associated with the egress label
and MPLS forwarding and LSP parameters.
Module 5 Page 86
Verify the IP and MPLS forwarding information.
A:CE1# ping 192.168.2.1

ttl=62
ttl=62
ttl=62
ttl=62
ttl=62
time=2.33ms.
time=3.01ms.
time=2.32ms.
time=2.48ms.
time=2.47ms.
A:CE1# traceroute 192.168.2.1

traceroute to 192.168.2.1, 30 hops max, 40 byte packets
1 10.1.3.1 (10.1.3.1)
1.77 ms 1.91 ms 1.76 ms
2 10.2.4.2 (10.2.4.2)
2.13 ms 2.11 ms 2.24 ms
3 192.168.2.1 (192.168.2.1)
2.86 ms 2.85 ms 2.86 ms
Module 5 |
87
Verify the connectivity from the local CE to the remote CE after service implementation.
The MPLS-enabled core routers will not be reported as valid traceroute hops and will not be visible in
the traceroute output (not shown here).
The egress PE will report a timeout represented by the '* * *' in the traceroute output. Therefore, the
ingress PE device and the routers at the customer site are the only devices visible in the traceroute
results.
Module 5 Page 87
Verify the routes are reachable via the VPRN service using ping and
traceroute commands.
A:PE1# oam vprn-trace 1 source 10.1.3.1 destination 10.2.4.2

TTL Seq Rcvd-on
Reply-Path RTT
TTL Seq Rcvd-on
Reply-Path RTT
------------------------------------------------------------------------------------------------------------------------------------------------------[Send request TTL: 1, Seq. 1.]
[Send request TTL: 1, Seq. 1.]
1
1
cpm
In-Band
0.826ms
1
1
cpm
In-Band
0.826ms
Node-Id 10.10.10.2
Node-Id 10.10.10.2
Requestor 10.10.10.1
Route: 10.2.4.0/27
Route: 10.2.4.0/27
Vpn Label: 131069 Metrics 0 Pref 170 Owner bgpVpn
Next Hops: [1] ldp tunnel
Route Targets: [1]: target:64496:10
Responder 10.10.10.2
Route: 10.2.4.2/32
Route: 10.2.4.2/32
Vpn Label: 0 Metrics 0 Pref 0 Owner local
Next Hops: [1] ifIdx 2 nextHopIp 10.2.4.2
TTL Seq Rcvd-on
Reply-Path RTT
TTL Seq Rcvd-on
Reply-Path RTT
------------------------------------------------------------------------------------------------------------------------------------------------------[Send request TTL: 1, Seq. 1.]
[Send request TTL: 1, Seq. 1.]
1
1
cpm
In-Band
0.915ms
1
1
cpm
In-Band
0.915ms
Node-Id 10.10.10.2
Node-Id 10.10.10.2
Route: 10.2.5.0/27
Route: 10.2.5.0/27
Route: 10.2.5.2/32
Route: 10.2.5.2/32
Module 5 |
88
In order to verify that a service is operational, a set of in-band, packet-based operation, administration,
and maintenance (OAM) tools is required with the ability to test each of the individual packet
operations.
For in-band testing, the OAM packets closely resemble customer packets to effectively test the
customer's forwarding path, but they are distinguishable from customer packets so they are kept
within the service provider's network and not forwarded to the customer.
The suite of OAM diagnostics supplements the basic IP ping and traceroute operations with
diagnostics specialized for the different levels in the service delivery model.
The oam vprn-ping command is used to verify that the customer VPRN service is operational. The
oam vprn-trace command is used to verify the path taken for the customer VPRN service and the
tunneling mechanism used across the provider core.
Module 5 Page 88
Verifying the VPRN using OAM tools
VPRN Control Plane Flow

CE learns a route and propagates to the PE via the configured PE-CE
protocol.
Module 5 |
89
The control plane flow demonstration is shown for the Blue VPN.
This case study uses BGP as the PE-CE routing protocol; however, static, RIP, OSPF, OSPFv3 or
EPGP routing may also be used.
The CE router needs a policy to advertise directly connected routes to the PE. CE-x to PE-x routing
protocol may be configured independent of any other CE-y-PE-y routing protocol.
A:CE1>config>router>policy-options# info
---------------------------------------------policy-statement "direct-bgp"
entry 10
from
protocol direct
exit
to
protocol bgp
exit
action accept
exit
exit
exit
A:CE1>config>router>bgp# info
---------------------------------------------group "toPE1"
peer-as 64496
neighbor 10.1.3.1
export "direct-bgp"
exit all
Module 5 Page 89
The PE will install the route into the VRF based on the configuration
of the interface the route was received on.
VPRN Control Plane Flow (continued)
Module 5 |
90
When PE propagates customer routes to a BGP table, it becomes a VPN-IPv4 route by adding the RD
and RT.
CE to PE routing protocol may be configured independent of any other CE-PE routing protocol.
Module 5 Page 90
On PE1, customer routes are automatically propagated into a BGP

table.
Module 5 |
91
PE1 and PE2 are BGP neighbors and thus have a BGP session in which MP-BGP updates are
exchanged.
Each VPRN appears as an additional routing instance and the routes for a service are
exchanged via MP-BGP between various PEs.
Module 5 Page 91
MP-BGP updates pass customer routes via VPN-IPv4 prefixes and

route targets across the provider core.
PE2 FIB
Prefix
VPN Label
192.168.1.0/27
131069
Module 5 |
92
Module 5 Page 92
The receiving PE (egress PE) installs the VPN-IPv4 routes into a VRF
based on the route target in the MP-BGP update.
Module 5 |
93
A:PE2>config>router>policy-options# info
---------------------------------------------policy-statement "mbgp-bgp"
entry 10
from
protocol bgp-vpn
exit
to
protocol bgp
exit
action accept
exit all
---------------------------------------------echo "Service Configuration"
service
customer 10 create
description "Default customer"
exit
bgp
group "toCE1"
neighbor 10.1.3.3
export "mbgp-bgp"
peer-as 64497
exit
exit
exit
no shutdown
Module 5 Page 93
A policy is required to exchange the VRF routes to the PE-CE

routing protocol.

Return Path
Module 5 |
94
Similarly, route exchanges must occur in the opposite direction. CE2 learns a route and propagates to
PE2 via the configured PE-CE protocol (BGP). PE2 will then install the route into the VRF based on
the configuration of the interface the route is received on. Customer routes are then automatically
propagated into the BGP table on the PE2.
MP-BGP updates pass the customer routes via VPN-IPv4 prefixes and route targets across the
provider core. The receiving PE (PE1) places all VPN-IPv4 routes into the VRFs corresponding to the
proper route targets. The VRF routes are then exchanged to the PE1-CE1 routing protocol via policy.
Module 5 Page 94
A bi-directional route exchange must occur across the core
VPRN Data Plane Flow
Module 5 |
95
Packet Flow:
1. An IP Packet intended for 192.168.1.1 is forwarded by the CE2 router via its routing table to the PE2 router.
2. At PE2, the packet is received on an interface associated to the Blue VRF. The PE thus knows that
it will use the Blue VRF for forwarding decisions.
3. In the Blue VRF, the next-hop address for the FEC is PE1.
Module 5 Page 95
Packet Flow CE2 to PE2
VPRN Data Plane Flow (continued)

Packet Flow at PE2
PE2 FIB
Prefix
VPN Label
192.168.1.0/27
131069
Module 5 |
96
Packet Flow:
The packet will receive a service label by PE2 defining the service on the egress PE.
Module 5 Page 96
The VPN label is determined by the BGP table, defining the

service

Packet Flow at PE2
Module 5 |
97
Packet Flow:
1. A label will be determined for the next-hop address from the LFIB. The label associated to
10.10.10.1 is 131071.
2. The packet will be labeled by PE2 with a transport label of 131071, which defines the transport
tunnel to the egress PE.
Note: Packet flow at P routers (not shown in the slide): each P router along the path will swap the LSP
label and label switches the packet towards the egress PE. There are no changes to the IP header or
the VPN label in the core network. The packet will be label switched across the provider core until it
reaches the egress PE.
Module 5 Page 97
The transport label is determined by the LFIB for the next-hop,

defining the transport tunnel

Packet Flow at PE1
Module 5 |
98
Packet Flow:
1. The egress PE will POP the LSP label as there is no egress label in the LFIB.
2. The result is an MPLS labeled packet.
Module 5 Page 98
The LSP label will be popped, while the next label will be
processed

Packet Flow at PE1
PE1 FIB
Module 5 |
99
Prefix
VPN Label
192.168.1.0/27
131069
Packet Flow:
1. The egress PE will reference the VPN label and determine the associated VRF as there is a unique
one-to-one association between a VPN label and a VRF.
2. The VPN label is popped and results in an unlabeled packet forwarded via the VRF based on the
longest match lookup algorithm.
3. The next-hop is identified as being external to the MPLS domain. The packet will be forwarded by
PE1 to CE1.
4. CE1 receives an unlabeled packet for destination 192.168.1.1 and will route the unlabeled packet
via its routing table.
Module 5 Page 99
The VPN label will be popped, while the unlabeled packet will be sent
out to the interface corresponding to the longest match lookup
algorithm
Lab 9: IPv4 VPRN

AS 64497
Blue VPN Site 1
AS 64499
Red VPN Site 1
BGP
Pod 2
Pod 1
Pod 3
Pod 4
BGP
AS 64498
Blue VPN Site 2
AS 64500
Red VPN Site 2
In this lab you will configure an IPv4 VPRNs

Module 5 |
100
Module 5 Page 100
MP-BGP
LDP
Section 6 IPv6 VPRN
Module 5 Page 101
Section Objectives
Describe the operation of 6VPE
Configure and verify a basic 6VPE
Complete Lab 10 Configure and verify an IPv6 VPRN using

BGP as the PE-CE routing protocol and LDP for signaling in the
IPv4 core
Module 5 |
102
Module 5 Page 102
Transition from IPv4 to IPv6

Internet Protocol version 6 (IPv6) is a replacement of IPv4
IPv6 is deployed in phases
How can we enable those isolated IPv6 networks to communicate

with each other?
Tunneling technologies are used to connect separated IPv6
networks
Module 5 |
103
Internet Protocol version 6 (IPv6) is a replacement of IPv4. The industry believes that IPv6 will
boost the development of a series of new services and technologies, particularly in mobile
communications and digital home appliances.
IPv6 cannot be deployed in one action. IPv4 is currently a dominant protocol of the Internet in which
almost all applications on the IP network are based on it. Thus, the applications of IPv6 are to be
developed step-by-step.
Currently, the main body of the Internet is still using IPv4, whereas IPv6 is deployed in merely a few
IPv6 backbone networks such as the CNGI in China and the e-Japan in Japan. The primary issue is
how to enable those isolated IPv6 networks to communicate with each other.
There are many issues involved when interconnecting IPv4 and IPv6 networks, as well as many
strategies for transitioning to IPv6. Tunneling technologies are used to connect separated IPv6
networks.
Module 5 Page 103
Currently, the main body of the Internet is still using IPv4, whereas
IPv6 is only deployed in a few IPv6 backbone networks
6VPE Technology
What is 6VPE?
6VPE technology is an extension of VPRN technology for IPv6, which can
carry an IPv6 or IPv4 VPN service on IPv4 MPLS backbone networks.
Module 5 |
104
6VPE (BGP-MPLS IPv6 VPN) is a RFC 4364-like VPN model for IPv6 networks. It is a method in
which a service provider may use its packet-switched backbone to provide Virtual Private Network
services for its IPv6 customers.
6VPE supports multiple IPv6 VRFs on the PE routers. The 6VPE route delivery and packet forwarding
principles are consistent with those of the VPRN using traditional IPv4. The 6VPE router is a PE router
that provides a BGP-MPLS IPv6 VPN service over an IPv4-based MPLS core.
As explained earlier, VRF is a VPN routing and forwarding instance in a PE. Meanwhile, a VRF table
is a routing and a forwarding table associated with a VRF. This customer-specific table enables the PE
router to maintain independent routing states for each customer.
Module 5 Page 104
6VPE logically separates routing table entries for VPN customers.
6VPE Versus IPv4-VPRN

Similarities
A route distinguisher (RD) is used to create prefixes that are unique across multiple VPRNs.
A single instance of MP-BGP is used to distribute customer IPv6 routes across the VPRN.
A route target (RT) is used to select routes for a specific VPRN.
The ingress PE makes a forwarding decision based on the contents of the VRF.
Differences
A new address family, VPN-IPv6 is defined.
A VPN-IPv6 address is a 16-byte IPv6 address prepended with an 8-byte RD to form a 24byte address.
The PE routers run a dual stack of IPv4 and IPv6.
IPv6 routes must be resolved to an IPv6 next-hop.
Module 5 |
105
In principle, no difference exists between IPv4 VPNs and IPv6 VPNs, as specified in RFC 4659 BGPMPLS IP VPN Extension for IPv6 VPN. Similar to IPv4, MP-BGP is the centerpiece of the MPLS
VPN-IPv6 architecture. It is used to distribute IPv6 routes over the SP backbone with the same set of
mechanisms to deal with overlapping addresses, redistribution policies, and scalability issues.
Although IPv6 should not have overlapping address space, the IPv6 VPN addresses are still
prepended with a route distinguisher. The route target extended community is used to control
distribution of routing information, by tagging exported routes and filtering imported ones.
Similar to VPN-IPv4, the ingress PE makes a forwarding decision in the data plane based on the
contents of the VRF. IPv6 data packets are encapsulated with a service and transport label for
transmission across the core.
The differences between 6VPE and VPN-IPV4 are:
A new address family, VPN-IPv6 is defined for 6VPE, the VPN-IPv6 address is created by adding the
eight byte route distinguisher (RD) to a 16 byte IPv6 address.
The PE routers run a dual stack of IPv4 and IPv6. Only IPv4 is required in the core network.
IPv6 routes must be resolved to an IPv6 next-hop. IPv4 addresses in the core are mapped to IPv6
addresses to accomplish this.
Module 5 Page 105
PE routers maintain a VRF for each VPRN on that router.
6VPE Overview
Customer IPv6 VPRN routes are exchanged between 6VPE routers across
the IPv4 MPLS provider core infrastructure.
The customers connected to 6VPE could run a native IPv6 or IPv4.
Module 5 |
106
The routing component of the VPN operation is divided into core routing and edge routing.
Core routing, which involves PE routers and P routers, is typically performed by an IPv4 IGP such as OSPF or
IS-IS. The core routing enables connectivity among the P and PE routers.
Edge routing takes place in two directions: routing between PE pairs achieved via MP-BGP using a specific
address family (VPN-IPv6) and routing between a PE and a CE. Routing between the CE and its PE is achieved
using a routing protocol that is VRF-aware. At this time, only static routes and BGP are VRF-aware.
The following routing tables are used at PE1:
IPv6 VRFs: a set of customer-specific IPv6 routing tables that contains customer routes. Each of these routing
tables contains routes received from the CE routers, as well as routes from remote sites in the same VPN.
A default routing table that is exclusively used to reach routers inside the provider network. It is an IPv4 table if
the MPLS core is IPv4 based (as in this case), and IPv6 otherwise.
A BGP table that contains entries from all customer-specific IPv6 routing tables.
Similar to VPRN for IPv4 customers, route distribution between sites occurs as follows:
1. The CE1 router announces a customer prefix to the provider router (PE1). Although this entry belongs to the
default routing table at the CE1, it is installed in a VRF IPv6 table (red) at the PE1. The interface on which these
entries are received determines the table into which they should be installed.
2. PE1 redistributes this entry into its MP-BGP table after prefixing it with the RD, referencing the VRF table the
entry is coming from.
3. Once in the BGP table, the entry is announced to the BGP peer at PE2.
4. Once installed in the PE2 BGP table, the entry is redistributed into one or more VRF tables after stripping off
the RD.
Note: the RD is used solely to distinguish entries in BGP, not as a policy mechanism to determine what entry
from which VRF table is to be redistributed in which VRF table on the remote PE. Instead, BGP communities
(route targets) are used for that purpose.
5. From the VRF table, the entry is finally redistributed into the customer site.
Module 5 Page 106
Each PE router maintains a separate logical routing table (VRF) for each
IPv6 VPRN.
6VPE Label Stack
The outer label is known as the top, transport, or LSP label that identifies
the transport tunnel between PEs.
Signaled via LDP or RSVP
The inner label is known as the service, VC, or VPN label that identifies
the customer VPRN.
Signaled via MP-BGP
These labels are applied on the IPv6 packet directly (no additional headers
are needed although the core is IPv4)
Module 5 |
107
Module 5 Page 107
The IPv6 VPRN Service, similar to IPv4 VPRNs, uses a label stack consisting
of two labels.
6VPE Control Plane Next-hop

For the VPN IPv6 address family, the next-hop has to be an IPv6
address, regardless of the nature of the network between the PEs.
The MP-BGP next-hop is updated to make it IPv6-compliant.
A value of ::FFFF: gets prepended to the IPv4 next-hop.
If the provider network is a native IPv6, the next-hop will be the IPv6
address of the egress PE.
Module 5 |
108
The 6VPE BGP sessions are established over an IPv4 core, and the core (P) routers do not have IPv6
enabled.
When announcing a prefix, MP-BGP running on one PE inserts a BGP next-hop in the update
message sent to a remote PE. This next-hop is the address of the PE sending the update message
(egress PE). For the VPN-IPv6 address family, it has to be an IPv6 address, regardless of the nature
of the network between the PE speakers.
Module 5 Page 108
If the provider network is an IPv4, the next-hop of the advertising 6VPE

router will be an IPv4-mapped IPv6 address.
6VPE Data Plane Ingress 6VPE Router
When the ingress 6VPE router receives an IPv6 packet, it looks for the destination
address in the VRF table.
This destination prefix is either local to the 6VPE (which is another interface participating in
the VPN) or a remote ingress 6VPE router.
For the prefix learned through the remote 6VPE router, the ingress router does a
The VPN-IPv6 route has an associated MPLS label to a MBGP next-hop and an
associated VPRN service label.
The ingress 6VPE router needs to push two MPLS labels in order to send the packets
to the egress 6VPE router.
The top label is an MPLS IPv4 label that is used to reach the egress 6VPE router.
The bottom label is an MPLS label that is advertised in MBGP by the remote 6VPE router for
the IPv6 prefixes in the VRF.
Module 5 |
109
Module 5 Page 109
lookup in the VPN-IPv6 forwarding table.
6VPE Data Plane Egress 6VPE Router

The provider core (P) routers label switch the packets to the correct
egress 6VPE via the transport label.
The egress 6VPE router receives label-stacked packets from the core.
The egress 6VPE router pops the bottom IPv6 VPRN service label and
identifies the target VRF and the address family.
A further Layer 3 lookup is performed in the target VRF and the IPv6
packet is sent toward the proper customer edge router in the IPv6 domain.
The egress 6VPE forwards unlabeled packets to the customer
Module 5 |
110
Module 5 Page 110
The egress 6VPE router pops the top transport label.
Router
System addresses
Loopback interfaces configured on
PE1
10.10.10.1/32
CE1
2001:db8:1:1f1::1/64
2001:db8:1:100::1/128
CE2
2001:db8:1:1f2::2/64
PE2
10.10.10.2/32
2001:db8:1:100::2/128
CE1
2001:db8:1:200::1/128
CE2
2001:db8:1:200::2/128
Module 5 |
111
6VPE operation is very similar to MPLS VPN for IPv4. The main difference is that the advertised
customer routes are IPv6 instead of IPv4.
The provider edge (PE) routers must run IPv4 (to communicate with the IPv4 MPLS core) and IPv6 (to
communicate with customers).
The provider core routers are IPv6-unaware and do not need to run BGP.
Module 5 Page 111
6VPE Configuration
Network Diagram
There are two separate sites of an IPv6 VPN customer.
These customer sites (CE1 and CE2) only run IPv6. They are
separated in the middle by the IPv4 network.
MP-BGP is used as the PE-CE routing protocol.
Module 5 |
112
The network diagram will be used to demonstrate the configuration and operation of 6VPE (Blue
VPN).
The loopback interfaces simulate locally connected networks.
The goal of this case study is to test IPv6 VPN routing over IPv4 MPLS infrastructure with BGP routing
between CE and PE (static routing can also be used).
This architecture requires no backbone infrastructure upgrades nor a reconfiguration of core routers
since forwarding is purely based on MPLs labels.
No changes are made to the core routing configuration from the IPv4 VPRN case study. OSPF is used
for core routing and LDP as the transport tunnel.
Note: In order to use IPv6 on the Alcatel-Lucent 7750 SR, you must first enable chassis mode c.
Module 5 Page 112
PE1 and PE2 are dual stack (IPv4/IPv6) routers. They have
interfaces connected to both IPv6 or IPv4 networks.
PE-CE BGP IPv6 Routing Configuration
#-------------------------------------------------#-------------------------------------------------echo "BGP Configuration"

echo "BGP Configuration"
#-------------------------------------------------#-------------------------------------------------bgp
bgp
local-as 64497
local-as 64497
group "toPE1"
group "toPE1"
family ipv6
family ipv6
neighbor 2001:db8:12::2
export "direct-bgp"
export "direct-bgp"
peer-as 64496
peer-as 64496
exit
exit
exit
exit
exit
exit
exit
exit
Module 5 |
113
BGP is used as a PE-CE protocol. The BGP configuration is pretty straightforward with an ipv6
family and the use of an IPv6 address for neighbor declaration. No changes are needed for the policy
configuration, which are used to redistribute customer routes into BGP.
#-------------------------------------------------echo "Policy Configuration"
#-------------------------------------------------policy-options
begin
policy-statement "direct-bgp"
entry 10
from
protocol direct
exit
to
protocol bgp
exit
action accept
exit
exit
exit
commit
exit
Module 5 Page 113
CE1 BGP Configuration (Similar to CE2).
PE-CE BGP IPv6 Routing Configuration (continued)

auto-bind ldp
auto-bind ldp
ipv6
ipv6
address 2001:db8:12::2/64
address 2001:db8:12::2/64
exit
exit
sap 1/1/3 create
sap 1/1/3 create
exit
exit
exit
exit
bgp
bgp
group "toCE1"
group "toCE1"
family ipv6
family ipv6
export "mpbgp-bgp"
export "mpbgp-bgp"
peer-as 64497
peer-as 64497
exit
exit
exit
exit
exit
exit
no shutdown
no shutdown
exit
exit
Module 5 |
114
Module 5 Page 114
PE1 VPRN BGP Configuration (similar to PE2).
6VPE Routers Configuration
#-------------------------------------------------#-------------------------------------------------echo "BGP Configuration"

echo "BGP Configuration"
#-------------------------------------------------#-------------------------------------------------bgp
bgp
group "multi-bgp"
group "multi-bgp"
family vpn-ipv4 vpn-ipv6
family vpn-ipv4 vpn-ipv6
neighbor 10.10.10.2
neighbor 10.10.10.2
peer-as 64496
peer-as 64496
exit
exit
exit
exit
exit
exit
exit
exit
Module 5 |
115
PE1 and PE2 are the 6VPE routers in the network. They run IPv4 (towards the core) and IPv6
(towards the CE and other PEs).
In order to support 6VPE and exchange the IPv6 VPN routes, they need to run multi-protocol BGP
(MBGP) between them.
LDP is used in the IPv4 network to setup MPLS tunnels for IPv6 over IPv4.
Module 5 Page 115
6VPE Routers MP-BGP Configuration (PE1 and PE2).
6VPE Routers Configuration (continued)
#-------------------------------------------------#-------------------------------------------------echo "Policy Configuration"

echo "Policy Configuration"
#-------------------------------------------------#-------------------------------------------------policy-options
policy-options
begin
begin
entry 10
entry 10
from
from
protocol bgp-vpn
protocol bgp-vpn
exit
exit
to
to
protocol bgp
protocol bgp
exit
exit
action accept
action accept
exit
exit
exit
exit
exit
exit
commit
commit
exit
exit
Module 5 |
116
The route policy mpbgp-bp is used at the 6VPE router in order to export MBGP IPv6 routes into the
VPN.
There is no need to define any import policy to advertise VPN IPv6 prefixes when BGP is being used
as a PE-CE routing protocol.
The VRF route-target attribute needs to be set and match in order to import/export routes between
6VPEs.
In our example, we used a route-target value of target:64496:10.
Note: that the core routers (not present in this network) do not run BGP. They use IPv4 MPLS to
switch the packets.
Module 5 Page 116
BGP VPN Route Policy Configuration on PE1 (similar to PE2).
6VPE Verification
*A:PE1# show router 10 bgp summary

*A:PE1# show router 10 bgp summary
===============================================================================
===============================================================================
AS:64496
Local AS:64496
AS:64496
Local AS:64496
===============================================================================
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 1
Total Peer Groups
: 1
Total Peers
: 1
Total BGP Paths
: 6
Total Path Memory
: 760
Total BGP Paths
: 6
Total Path Memory
: 760
: 0
: 0
: 3
: 3
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
Total Decay Rts
: 0
===============================================================================
===============================================================================
BGP Summary
BGP Summary
===============================================================================
===============================================================================
Neighbor
Neighbor
PktSent OutQ
PktSent OutQ
------------------------------------------------------------------------------------------------------------------------------------------------------------2001:db8:12::1
2001:db8:12::1
64497
244
0 01h17m27s 3/2/3 (IPv6)
64497
244
0 01h17m27s 3/2/3 (IPv6)
238
0
238
0
===============================================================================
===============================================================================
Module 5 |
117
After the configuration, both IPv6 networks are visible to each other via the 6VPE routers.
The show router 10 bgp summary command can be used at the PE to verify that the BGP session to
CE is established and that VPN IPv6 routes are exchanged.
Module 5 Page 117
Verify that the BGP session to CE is established and VPN IPv6 routes
are exchanged.
6VPE Verification (continued)
A:PE2# show router bgp summary

A:PE2# show router bgp summary
===============================================================================
===============================================================================
BGP
Router ID:10.10.10.2
AS:64496
Local AS:64496
AS:64496
Local AS:64496
===============================================================================
===============================================================================
BGP
Admin State
: Up
BGP Oper State
: Up
BGP Admin
State
BGP Oper
Total
Peer Groups
: :1 Up
Total
PeersState
: :1 Up
TotalBGP
Peer
Groups
TotalPath
Peers
1
Total
Paths
: :141
Total
Memory
: :1792
Total
BGP
Paths
:
14
Total
Path
Memory
: 0
Total IPv4 Rem. Active Rts : :0 1792
Total
IPv4
Remote
Rts
:
0
Total
IPv4
Rem.
Active
Rts
: 0
Total IPv6 Rem. Active Rts : :0 0
TotalSupressed
IPv6 Remote
TotalHist.
IPv6 Rts
Rem. Active Rts : :0 0
Total
Rts Rts : :0 0
Total
TotalDecay
Supressed
Total Hist. Rts
: 0
Total
Rts Rts
: :0 0
Total Decay Rts
: 0
Total VPN Peer Groups
: 2
Total VPN Peers
: 2
TotalVPN
VPNLocal
Peer Rts
Groups : :7 2
Total VPN Peers
: 2
Total
TotalVPN-IPv4
VPN Local
RtsRts : :4 7
Total
Rem.
Total VPN-IPv4 Rem. Act. Rts: 4
TotalVPN-IPv6
VPN-IPv4Rem.
Rem.Rts
Rts: :3 4
TotalVPN-IPv6
VPN-IPv4Rem.
Rem.Act.
Act.Rts:
Rts:3 4
Total
Total
TotalL2-VPN
VPN-IPv6
TotalL2VPN
VPN-IPv6
Total
Rem.Rem.
Rts Rts: :0 3
Total
Rem. Rem.
Act. Act.
Rts Rts:
: 03
TotalVPN
L2-VPN
TotalVPN
L2VPN
Rem.
Total
Supp.Rem.
Rts Rts : :0 0
Total
Hist.
RtsAct. Rts : :0 0
TotalVPN
VPNDecay
Supp.Rts
Rts
Total VPN Hist. Rts
: 0
Total
: :0 0
TotalMVPN-IPv4
VPN DecayRem
RtsRts : :0 0
Total
Total MVPN-IPv4 Rem Act Rts : 0
TotalMDT-SAFI
MVPN-IPv4
TotalMDT-SAFI
MVPN-IPv4
Total
RemRem
RtsRts: :0 0
Total
RemRem
ActAct
RtsRts: :0 0
Total MDT-SAFI Rem Rts : 0
Total MDT-SAFI Rem Act Rts : 0
===============================================================================
===============================================================================
BGP
Summary
BGP Summary
===============================================================================
===============================================================================
Neighbor
Neighbor
ASPktSent
PktRcvdOutQ
InQ Up/Down
PktSent OutQ
------------------------------------------------------------------------------------------------------------------------------------------------------------10.10.10.1
10.10.10.1
64496
58529
0 01h46m16s 0/0/0 (IPv4)
64496 58512
58529
0/0/0(IPv6)
(IPv4)
0 0 01h46m16s0/0/0
58512
0
0/0/0(VpnIPv4)
(IPv6)
4/4/4
4/4/4(VpnIPv6)
(VpnIPv4)
3/3/3
3/3/3 (VpnIPv6)
Module 5 |
118
The show router bgp summary command can be used at the PE to verify that the MP-BGP session
to 6VPE is established and that VPN IPv6 routes are exchanged.
Module 5 Page 118
Verify that the MP-BGP session to PE is established and VPN IPv6

routes are exchanged.

===============================================================================
===============================================================================
AS:64496
Local AS:64496
AS:64496
Local AS:64496
===============================================================================
===============================================================================
===============================================================================
===============================================================================
BGP VPN-IPv6 Routes
BGP VPN-IPv6 Routes
===============================================================================
===============================================================================
Flag Network
LocalPref
MED
Flag Network
LocalPref
MED
Nexthop
VPNLabel
Nexthop
VPNLabel
As-Path
As-Path
------------------------------------------------------------------------------------------------------------------------------------------------------------u*>i 64496:1:2001:db8:56::/64
100
None
u*>i 64496:1:2001:db8:56::/64
100
None
::FFFF:A0A:A02
131069
::FFFF:A0A:A02
131069
No As-Path
No As-Path
u*>? 64496:1:2001:db8:1:200::2/128
100
None
u*>? 64496:1:2001:db8:1:200::2/128
100
None
::FFFF:A0A:A02
131069
::FFFF:A0A:A02
131069
64498
64498
u*>? 64496:1:2001:db8:1:1f2::/64
100
None
u*>? 64496:1:2001:db8:1:1f2::/64
100
None
::FFFF:A0A:A02
131069
::FFFF:A0A:A02
131069
64498
64498
------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 3
Routes : 3
===============================================================================
===============================================================================
Module 5 |
119
The VPN IPv6 routes received by PE1 and PE2 can be seen using the show router bgp routes vpnipv6 command.
=============================================================================
AS:64496
Local AS:64496
=============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
=============================================================================
BGP VPN-IPv6 Routes
=============================================================================
Flag Network
LocalPref
MED
Nexthop
VPNLabel
As-Path
----------------------------------------------------------------------------u*>i 64496:1:2001:db8:12::/64
100
None
::FFFF:A0A:A01
131070
No As-Path
u*>? 64496:1:2001:db8:1:200::1/128
100
None
::FFFF:A0A:A01
131070
64497
u*>? 64496:1:2001:db8:1:1f1::/64
100
None
::FFFF:A0A:A01
131070
64497
----------------------------------------------------------------------------Routes : 3
Module 5 Page 119
Verify that the VPN IPv6 routes are received by PE1 and PE2.
A:PE1# show router 10 route-table ipv6

===============================================================================
===============================================================================
IPv6 Route Table (Service: 1)
===============================================================================
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Dest Prefix
Type
Proto
Age
Pref
Metric
Metric
------------------------------------------------------------------------------------------------------------------------------------------------------------2001:db8:12::/64
Local
Local
02h16m34s
0
2001:db8:12::/64
Local
Local
02h16m34s
0
toR3
0
toR3
0
2001:db8:56::/64
170
2001:db8:56::/64
170
10.10.10.2 (tunneled)
0
10.10.10.2 (tunneled)
0
2001:db8:1:200::1/128
Remote BGP
01h31m32s
170
2001:db8:1:200::1/128
Remote BGP
01h31m32s
170
2001:db8:12::1
0
2001:db8:12::1
0
2001:db8:1:200::2/128
170
2001:db8:1:200::2/128
170
10.10.10.2 (tunneled)
0
10.10.10.2 (tunneled)
0
2001:db8:1:1f1::/64
Remote BGP
01h31m32s
170
2001:db8:1:1f1::/64
Remote BGP
01h31m32s
170
2001:db8:12::1
0
2001:db8:12::1
0
2001:db8:1:1f2::/64
170
2001:db8:1:1f2::/64
170
10.10.10.2 (tunneled)
0
10.10.10.2 (tunneled)
0
------------------------------------------------------------------------------------------------------------------------------------------------------------No. of Routes: 6
No. of Routes: 6
===============================================================================
===============================================================================
Module 5 |
120
The show router 10 route-table ipv6 command can be used in PE1 and PE2 to verify VPN.
IPv6 routes are learnt via MBGP from the remote 6VPE router.
=============================================================================
=============================================================================
Dest Prefix
Type
Proto
Age
Pref
Metric
----------------------------------------------------------------------------2001:db8:12::/64
170
10.10.10.1 (tunneled)
0
2001:db8:56::/64
Local
Local
00h50m59s
0
toR4
0
2001:db8:1:200::1/128
170
10.10.10.1 (tunneled)
0
2001:db8:1:200::2/128
Remote BGP
00h29m21s
170
2001:db8:56::6
0
2001:db8:1:1f1::/64
170
10.10.10.1 (tunneled)
0
2001:db8:1:1f2::/64
Remote BGP
00h29m21s
170
2001:db8:56::6
0
----------------------------------------------------------------------------No. of Routes: 6
Module 5 Page 120
Verify that the VPN IPv6 routes are learnt via MP-BGP from the
remote 6VPE router and installed in the VRF.
A:CE1# show router route-table ipv6

A:CE1# show router route-table ipv6
===============================================================================
===============================================================================
IPv6 Route Table (Router: Base)
IPv6 Route Table (Router: Base)
===============================================================================
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Dest Prefix
Type
Proto
Age
Pref
Metric
Metric
------------------------------------------------------------------------------------------------------------------------------------------------------------2001:db8:12::/64
Local
Local
02h06m09s
0
2001:db8:12::/64
Local
Local
02h06m09s
0
toR1
0
toR1
0
2001:db8:56::/64
Remote BGP
00h46m54s
170
2001:db8:56::/64
Remote BGP
00h46m54s
170
2001:db8:12::2
0
2001:db8:12::2
0
2001:db8:1:200::1/128
Local
Local
01h29m24s
0
2001:db8:1:200::1/128
Local
Local
01h29m24s
0
system
0
system
0
2001:db8:1:200::2/128
Remote BGP
00h25m21s
170
2001:db8:1:200::2/128
Remote BGP
00h25m21s
170
2001:db8:12::2
0
2001:db8:12::2
0
2001:db8:1:1f1::/64
Local
Local
01d02h10m
0
2001:db8:1:1f1::/64
Local
Local
01d02h10m
0
BlueSite1
0
BlueSite1
0
2001:db8:1:1f2::/64
Remote BGP
00h25m21s
170
2001:db8:1:1f2::/64
Remote BGP
00h25m21s
170
2001:db8:12::2
0
2001:db8:12::2
0
------------------------------------------------------------------------------------------------------------------------------------------------------------No. of Routes: 6
No. of Routes: 6
===============================================================================
===============================================================================
Module 5 |
121
The show router route-table ipv6 command can be used in CE1 and CE2 to verify the VPN.
IPv6 routes are learnt via the PE-CE BGP session and installed in the route table.
The ping command can be used in CE1 to verify that CE2s advertised network is accessible.
A:CE1# ping 2001:db8:1:200::2
PING 2001:db8:1:200::2 56 data bytes
64 bytes from 2001:db8:1:200::2 icmp_seq=1 hlim=62 time=2.80ms.
---- 2001:db8:1:200::2 PING Statistics ---5 packets transmitted, 5 packets received, 0.00% packet loss
Module 5 Page 121
Verify that the VPN IPv6 routes are learned via the PE-CE BGP
session and installed in the route table.
*A:PE1# show router bgp routes 64496:1:2001:db8:1:200::2/128 hunt

*A:PE1# show router bgp routes 64496:1:2001:db8:1:200::2/128 hunt
===============================================================================
===============================================================================
AS:64496
Local AS:64496
AS:64496
Local AS:64496
===============================================================================
===============================================================================
===============================================================================
===============================================================================
BGP VPN-IPv6 Routes
BGP VPN-IPv6 Routes
------------------------------------------------------------------------------------------------------------------------------------------------------------RIB In Entries
RIB In Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------Network
: 2001:db8:1:200::2/128
Network
: 2001:db8:1:200::2/128
Nexthop
: ::FFFF:A0A:A02
Nexthop
: ::FFFF:A0A:A02
Route Dist.
: 64496:1
VPN Label
: 131069
Route Dist.
: 64496:1
VPN Label
: 131069
From
: 10.10.10.2
From
: 10.10.10.2
Res. Nexthop
: n/a
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : NotAvailable
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
Atomic Aggr.
: Not Atomic
MED
: None
Community
: target:64496:10
Community
: target:64496:10
Cluster
: No Cluster Members
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 10.10.10.2
Originator Id : None
Peer Router Id : 10.10.10.2
Flags
: Used Valid Best Incomplete
Flags
: Used Valid Best Incomplete
AS-Path
: 64498
AS-Path
: 64498
VPRN Imported : 1
VPRN Imported : 1
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Module 5 |
122
The show router bgp routes 64496:1:2001:db8:1:200::2/128 hunt command can be used to verify
that the IPv6 route is learnt via M-BGP over the IPv4 core.
The next-hop for the route is an IPv4-mapped IPv6 route.
This command also displays the VPN label 131069 used for 6VPE (remember from IPv4 MPLS VPNs
that we use platform-based labeling).
Note: that BGP must have a valid next hop for the route before it is installed in the route table. If the
MPLS transport in the VPRN (auto-bind ldp in this case) has not been configured, then the route will
be marked as Invalid and not used by BGP as there is no transport tunnel to the next hop.
Module 5 Page 122
Verify that the IPv6 route is learned via M-BGP over the IPv4 core.
Lab 10: IPv6 VPRN
AS 64497
Blue VPN Site 1
AS 64499
Red VPN Site 1
BGP
MP-BGP
LDP
Pod 3
Pod 4
BGP
AS 64498
Blue VPN Site 2
AS 64500
Red VPN Site 2
In this lab you will configure and verify IPv6 VPRNs

Module 5 |
123
In this lab, students will configure and verify IPv6 VPN (6VPE) routing over IPv4 MPLS infrastructure
with BGP routing between CE and PE.
Module 5 Page 123
Pod 2
Pod 1
Module Summary
IES is a routed Layer 3 connectivity service.
IES provides direct Internet access with billing, ingress and egress shaping
and policing capabilities.
A functional IES requires customer association and interface configuration.

The IES interface must be assigned an IP address and must terminate
either a SAP or a spoke SDP.
Multiple interfaces may be configured for each IES.
A Layer 3 service can only terminate a spoke SDP, not a mesh SDP.
Layer 3 service termination to a Layer 2 service may require adjustment of
the IP-MTU parameter.
Module 5 |
124
Module 5 Page 124
IES allows customer-facing IP interfaces to participate in the same routing

instance used for service network core routing connectivity.

A VPRN consists of customer sites connected to PE routers where the
provider associates each of these sites with a VPRN service.
PE routers must run traditional routing protocols with the CE and MPLS
protocols with the P routers.
P routers are MPLS-enabled but are not aware of customer VPRNs.
PE routers maintain a separate VRF for each VPRN.
VPRN service uses an MPLS label stack consisting of two labels:
The LSP label defines the forwarding path between PEs.
The VPN label identifies the customer network on the egress PE.
Module 5 |
125
Module 5 Page 125
CE routers are not MPLS-enabled and are only configured with traditional
routing protocols.

VPN-IPv4 addresses were created to extend BGPs ability to carry
overlapping routing information.
A VPN-IPv4 address is a 12-byte value consisting of an 8-byte route

distinguisher (RD) and a 4-byte IPv4 prefix.
The 8-byte route target (RT) is a BGP-extended community attribute used
as the VPN identifier.
LSP label signaling is exchanged between provider core routers via RSVPTE or LDP.
PE routers exchange the routing information learned from all customer
sites via MP-BGP.
Module 5 |
126
Module 5 Page 126
VPN-IPv4 addresses are carried only across the provider's backbone by the
MP-BGP protocol.

VPRN label signaling is carried between PE routers in MP-BGP updates.
The Alcatel-Lucent 7750 SR router assigns one label per VRF.
Customer packets crossing the service providers backbone are IPv4
packets with an added MPLS label stack.
Creating customer accounts

Defining the VPRN service
Creating VPRN interfaces and SAP associations
Selecting and configuring the transport tunnel type for the VPRN service
Selecting and configuring the CE-PE routing protocol
Configuring route redistribution
Activating the VPRN Service
Module 5 |
127
Module 5 Page 127
VPRN service configuration will include the following items:
6VPE is a tunneling technology that makes use of MPLS tunnels to

transport IPv6 information over the IPv4 MPLS infrastructure.
As in IPv4 VPRN, MP-BGP is used to distribute routes from an IPv6 VPN site
to all the other PE routers connected to a site of the same IPv6 VPN.
PEs use VPN routing and forwarding tables (VRFs) to maintain the
reachability and forwarding information for each IPv6 VPN separately.
Module 5 |
128
Module 5 Page 128
In 6VPE, the PE routers run a dual stack of IPv4/IPv6 and exchange the
IPv6 routes using MP-BGP.
Learning Assessment
1. Verify whether the following statement is true or false: An IES must
be configured with a SAP and an SDP.
3. When an IES is used to provide a Layer 3 termination for a SAP,

what extra configuration is necessary within the SAP?
4. When an IES is used to terminate the spoke SDP of a VPLS, what
extra configuration must be done on the VPLS side?
extra configuration must be done on the IES side?
MAC address appears in the VPLS FDB for the IES interface?
Module 5 |
129
1. Verify whether the following statement is true or false: An IES is configured with a SAP and a SDP.
False
2. Verify whether the following statement is true or false: An IES may configured to either a
SAP or on a network port.
False; it cannot be configured on a network port.
3. When an IES is used to provide a Layer 3 termination for a SAP, what extra configuration is
necessary within the SAP?
No extra configuration is required for the SAP.
4. When an IES is used to terminate the spoke SDP of a VPLS, what extra configuration must be done
on the VPLS side?
No extra configuration is required within the VPLS.
5. When an IES is used to terminate the spoke SDP of a VPLS, what extra configuration must done on
the IES side?
The VC MTU must match on both sides of the spoke SDP, so it will typically be necessary to
define the IP-MTU setting for each interface within the IES.
6. When an IES is used to terminate the spoke SDP of a VPLS, what MAC address appears in the
VPLS FDB for the IES interface?
The MAC address of the IES corresponds to the base chassis MAC address of the IES router.
Module 5 Page 129
2. Verify whether the following statement is true or false: An IES may

be configured to either a SAP or on a network port.
7. What are the three key functions described in RFC 4364 to provide a
Layer 3 VPN service?
8. What table is used for a VPRN service in PE routers?
10. Contrast between the functions of a PE and P device.
11. How does a VPRN service allow the usage of overlapping customer
addressing?
12. What is the function of a VPN label?
Module 5 |
130
Learning Assessment Answers

7. What are the three key functions described in RFC 4364 to provide a Layer 3 VPN service?
Distributing the customers routing information between sites.
Forwarding the customer originated data packets to the appropriate destination.
Providing secure Layer 3 routing connectivity between the various customer sites.
8. What table is used for a VPRN service in PE routers?
The VPN (or virtual) routing and forwarding (VRF) table is used.
9. List three benefits of a VPRN service.
A VPRN service simplifies the routing topology at customer sites.
The service provider manages the core network and the customer routes.
Customers receive the redundancy benefits designed into the provider core.
10. Contrast between the functions of a PE and P device.
PE devices are the interface to the provider network for one or more CE devices, from one or more distinct
customers.
P devices comprise the internal provider network core without connections to the customer.
11. How does a VPRN service allow the usage of overlapping customer addressing?
A VPRN service allows the usage of overlapping customer addressing by securely isolating routes from
different customers in a logical routing table known as the VRF.
12. What is the function of a VPN label?
The VPN (or inner) label differentiates between the specific customer destination networks at the egress to the
MPLS domain.
Module 5 Page 130
9. List three benefits of a VPRN service.

13. Fill in the blanks: The VPRN service distributes the customers routing
information using __________________ and forwards their data packets
using __________________ tunnels.
15. What are the different types of CE-PE routing protocols supported for the
VPRN service?
16. Fill in the blanks: A VPN-IPv4 address is a ______byte value consisting of the
_______byte route distinguisher (RD) and the ____ byte IPv4 address prefix.
17. Why are VPN-IPv4 addresses used for a VPRN service?
18. Is there a fixed association between the choice of PE-CE protocols and the
choice of MPLS protocols used in a VPRN network?
Module 5 |
131

13. Fill in the blanks: The VPRN service distributes customers routing information using MP-BGP and
forwards their data packets using MPLS or GRE tunnels.
14. Fill in the blank: For VPRN services, PE routers exchange the routing information learnt from all
customer sites according to the MP-BGP routing protocol.
15. What are the different types of CE-PE routing protocols supported for the VPRN service?
Alcatel-Lucent supports static, RIP, OSPF, OSPFv3, and BGP as CE-PE routing protocols for the
VPRN service.
16. Fill in the blanks: A VPN-IPv4 address is a 12-byte value consisting of the 8-byte route distinguisher
(RD) and the 4-byte IPv4 address prefix.
17. Why are VPN-IPv4 addresses used for a VPRN service?
VPN-IPv4 addressing allows the IP address prefixes used within different VRFs to overlap (in other
words, to be the same).
18. Is there a fixed association between the choice of PE-CE protocols and the choice of MPLS
protocols used in a VPRN network?
There is no fixed association between the choice of protocols used in a MPLS network. Any PE-CE
routing protocol can be used in association with any transport tunnel label signaling protocol.
Module 5 Page 131
14. Fill in the blank: For VPRN services, PE routers exchange the routing
information learnt from all customer sites according to the
_________________ routing protocol.

19. What is the purpose of a route target (RT)?
20. How is a BGP session configured to carry VPN-IPv4 prefixes?
21. Will the VPRN PE-CE interface be operationally active if the route
distinguisher is not configured?
23. What routing tables are used by a 6VPE router?
Module 5 |
132

19. What is the purpose of a route target (RT)?
The route target (RT) provides the ability for MP-BGP to install the routes into the correct egress VRF table.
20. How is a BGP session configured to carry VPN-IPv4 prefixes?
A BGP session is configured to carry VPN-IPv4 prefixes by defining the 'family vpn-ipv4 parameter
under the BGP configuration.
21. Will the VPRN service be operationally active if the route distinguisher is not configured?
A route distinguisher must be defined in order for VPRN PE-CE interface to be operationally active.
22. What is a dual stack router?
Dual stack means that a router can support both IPv4 and IPv6 protocol stacks. Such a router can
communicate with an IPv4 and IPv6 router directly. Therefore, it can be regarded as a connection point
between IPv4 and IPv6 networks.
23. What routing tables are used by a 6VPE router?
IPv6 VRFs: a set of customer-specific IPv6 routing tables that contains customer routes. Each of these routing
tables contains routes received from the CE routers as well as routes from remote sites in the same VPN.
A default routing table that is exclusively used to reach routers inside the provider network.
A BGP table that contains entries from all the customer-specific IPv6 routes.
Module 5 Page 132
22. What is a dual stack router?
This appendix is provided as supplementary material for students who did not take the latest IRP course
version. Its material is not part of the services exam.
Module 5 Page 133
Appendix IPv6
Appendix Overview
Module 5 |
134

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) program. Refer to the
Alcatel-Lucent website located at www.alcatel-lucent.com/src for more information on the SRC program.
Internet standards documentation such as protocol standards bodies, RFCs, and IETF drafts
Technical support pages of the Alcatel-Lucent website located at http://www.alcatellucent.com/support
Module 5 Page 134
IPv6 addressing
ICMPv6
Configuring IPv6 interfaces on Alcatel-Lucent 7750 SR
IPv6 Addressing
Three types of addresses defined in IPv6

Unicast (single host)
Multicast (multiple hosts)
Anycast (multiple hosts)
Closest host with the anycast address responds
No broadcast address
Solicited-node multicast used instead of broadcast
Module 5 |
135
IPv6 defines three different types of addresses:

Unicast A unicast address provides an address for a single host.
Multicast A multicast address provides an address for a group of hosts.
Anycast An anycast address is a unicast address used by more than one host. A packet addressed
to an anycast address is delivered to the nearest host as determined by the routing protocol.
IPv6 does not define broadcast addresses. There is a link-local multicast address for all routers on the
link (ff02::1) and solicited-node multicast addresses that replace the IPv4 ARP protocol.
Module 5 Page 135
Hosts must join the multicast group
IPv6 Addressing
IPv6 is 128 bits, expressed in groups of 4 hex digits

Eg. 2001:0db8:0000:0000:0021:0000:4ab9:0300
Only one group can be omitted

Eg. 2001:0db8::0021:0000:4ab9:0300
Leading zeroes can be omitted

Eg. 2001:db8::21:0:4ab9:300
Module 5 |
136
Since the IPv6 address is 128 bits, there are a number of conventions used to shorten them as much as
possible.
1. Addresses are written in groups of 4 hex digits, separated by a single colon. For example
2001:0db8:0000:0000:0021:0000:4ab9:0300.
2. One or more groups of zeroes can be replaced by two colons. The number above becomes
2001:0db8::0021:0000: 4ab9:0300.
3. Only one group of zeroes can be replaced with double colons. Otherwise it would not possible to tell
where the zeroes are located. However, leading zeroes in a group can also be omitted. The address
above becomes 2001:db8::21:0: 4ab9:300.
Module 5 Page 136
One or more groups of consecutive zeroes can be omitted
64 bits for routing prefix

48 bit global prefix
16 bit subnet
2000::/3 is reserved as the global routing prefix

64 bits for interface identifier
May be derived from MAC address
Module 5 |
137
Regular IPv6 unicast addressing uses a fixed structure where 64 bits are defined as the routing prefix
and 64 bits are defined as the interface identifier. For a globally routed address, 48 bits of the routing
prefix are used as the global routing prefix and 16 bits are the local routing prefix (or subnet).
The allocation for globally routed IPv6 addresses is the address space 2000::/3. This represents one
eighth of the entire address space and is all addresses beginning with the bit pattern 001. An ISP is
typically allocated a network assignment of /32 or larger (larger means a smaller prefix such as /31 or 30
and hence a larger network range). An individual enterprise typically receives a /48 or larger. Since a /48
has 16 bits available for the local subnet, this provides 65,536 individual subnets.
The interface ID portion of the address is locally assigned, but can be automatically derived from the 48
bit MAC address. It might also be assigned from a DHCPv6 server, through an auto-discovery
mechanism or manually assigned.
Module 5 Page 137
Unicast Addresses
Uses modified EUI-64, derived from MAC address

7th most significant bit of OUI is flipped
Hex string ff:fe is inserted between OUI and individual address
component
Module 5 |
138
To derive an IPv6 interface ID from the MAC address, the approach is to create a modified EUI-64
(Extended Unique Identifier-64). This involves flipping the 7th most significant bit of the OUI
(Organizationally Unique Identifier) and inserting the hex string ff:fe between the 3 bytes of the OUI and
the 3 bytes of the NIC-specific component.
For example, assume an organization is assigned the prefix 2001:db8/48. The organization has 16 bits
for subnetting. Perhaps they have 30 locations and decide to assign the first 8 bits based on the location
and the next 8 on the subnet at that location. Subnet 10 at location 3 gives a subnet value of 030a, for a
routing prefix of 2001:db8:0:30a::/64. With the modified EUI-64 assignment, the host with MAC address
00:16:4d:13:5c:ae has an interface ID of 0216:4dff:fe13:5cae. The resulting IPv6 address is
2001:db8::30a:216:4dff:fe13:5cae.
Module 5 Page 138
Deriving IPv6 Interface ID
Special IPv6 Addresses
::/128 is the unspecified host address

::1/128 is the loopback address
::/0 is the default route (same as IPv4)
All interfaces automatically have a link-local address
fc00::/7 defines Unique Local Address (ULA) range

Similar to private addresses in IPv4
::ffff:0:0/96 is a prefix to map IPv4 addresses

May use notation such as ::ffff:0:0:192.168.1.0
Module 5 |
139
There are a number of other unicast addresses in IPv6 that have special meaning.
::/128 is the unspecified host address (all zeroes). This address might be used until an address is
assigned to the device.
::1/128 is the loopback address (all zeroes except the last bit). This corresponds to the address
127.0.0.1 in IPv4.
::/0 is the default unicast route (the same as 0.0.0.0/0 in IPv4).
fe80::/64 is the prefix for the link-local address (binary 1111111010 followed by 54 zeroes). IPv6
requires that every IPv6 interface have a link-local address. This is not a valid routing prefix and is only
used for communications on the local link.
Typically the link-local interface ID is assigned the same value as the global interface ID which means
using the modified EUI-64 address. For the global address 2001:db8:0:30a:216:4dff:fe13:5cae, the link
local address would be fe80::216:4dff:fe13:5cae.
fc00::/7 defines a range known as Unique Local Addresses (ULA, RFC 4193). These are addresses
intended to be used on a private network and not routed on the global Internet (similar to private
addresses in IPv4). The ULA range is split into two ranges, depending on the value of the eighth bit.
fd00::/8 is intended to be used as a 48-bit prefix with the remaining 40 bits self-assigned using a
pseudo-random generator. This means that even though addresses are self-assigned, the probability of
two networks sharing the same prefix is very small. This is intended to make it easier to interconnect
privately-addressed networks.
fc00::/8 addresses are intended to have the remaining 40 bits allocated by a registrar to provide
globally unique private addresses, although the mechanism is yet to be defined (draft-hain-ipv6-ulac-02)
at the time of writing.
::ffff:0:0/96 is a prefix for IPv4-mapped IPv6 addresses. This provides an IPv6 address space that can
be used by native IPv4 applications. It is acceptable to use the standard IPv4 notation for the low order
32 bits of the address. For example 192.168.0.1 is mapped to the IPv6 address ::ffff:0:0:192.168.0.1.
Module 5 Page 139
fe80::/64 is the prefix for link-local addresses
IPv6 Multicast Addresses
Next four are flag bits

Following four are scope bits
Remaining 112 identify the multicast group
Some well-known multicast addresses

ff02::1 all routers on the local link
ff02::2 all routers on the local link
ff02::1:2 all DHCPv6 servers
Module 5 |
140
All IPv6 multicast addresses have an 8 bit prefix of all ones (ff00::/8) followed by 4 flag bits and 4 bits
that define the multicast scope. For general multicast addresses, the remaining 112 bits define the
multicast group.
Some well known IPv6 multicast addresses are:
ff02::1 - All routers on the local link.
ff02::2 - All routers on the local link.
ff02::1:2 - All DHCPv6 servers and relays on the local link.
Module 5 Page 140
Multicast addresses have an 8-bit prefix of all ones (ff::/8)
Replaces the broadcast address from IPv4

In 112-bit field, 79 zeroes followed by 9 ones, then 24 bits
from the unicast address
Last 24 bits are last 24 bits of unicast address being solicited
03-03-xx-xx-xx-xx reserved by IEEE for IPv6 multicast

MAC multicast address formed from last 32 bits of IPv6
multicast address
Module 5 |
141
IPv6 also defines a group of multicast addresses called solicited-node multicast. The sixteen bits of the
prefix, flags and scope are followed by 79 zeroes and 9 ones. The remaining 24 bits are taken from the
last 24 bits of the unicast address (or addresses) that is being solicited. If the destination router has the
address 2001:db8::30a:216:4dff:fe13:5cae, then the solicited-node multicast address becomes
ff02::1:ff13:5cae.
The IEEE provides the range of multicast addresses of 03-03-xx-xx-xx-xx for IPv6, where the xx-xx-xxxx string is the 32 low-order bits of the multicast IP address. Each IPv6 node on Ethernet automatically
joins the multicast groups corresponding to their solicited-node address and the all-routers address.
Thus, the host in this example will receive the Ethernet multicast groups:
03-03-ff-13-5c-ae and
03-03-00-00-00-01
The use of solicited-node multicast for host address resolution is described in the ICMPv6 section.
Module 5 Page 141
IPv6 Solicited-Node Multicast
Anycast Addresses
Anycast address is a special use of a unicast address

Any unicast address can be used for anycast
Useful for redundant services such as DNS
RFC 2526 reserves the highest 128 addresses on every subnet

as anycast addresses
Must not be assigned as unicast addresses
Module 5 |
142
Anycast addresses are used in limited situations in IPv4, but IPv6 formally incorporates the concept of
an anycast addresses. Think of an anycast address as a virtual unicast address shared by multiple
hosts. An IPv6 packet sent to an anycast address is routed to the nearest reachable host assigned the
anycast address. This is a useful mechanism for providing a redundant service, such as a DNS server.
An anycast address can be formed from any unicast address. In addition, RFC 2526 defines a range of
anycast addresses to be reserved on every subnet for well-known services. This range is the highest
128 interface addresses on the subnet. These addresses must never be assigned as unicast addresses.
Its similar to the concept in IPv4 of reserving the highest address as the broadcast address on a subnet,
except that a range of 128 addresses (from 0 to 127) is reserved for anycast in IPv6. To date, only one
address in this range has been assigned - the value 126, for Mobile IPv6 Home Agents.
Module 5 Page 142
Packets with an anycast address are routed to closest device

assigned the address
Header is simplified from IPv4

Extension headers support extra features
Forwarding is similar to IPv4
No fragmentation by routers
No header checksum
Fixed header size
Module 5 |
143
Despite the significant differences in addressing, IPv6 has many similarities to IPv4 - its actually a fairly
conservative revision of the protocol. The forwarding mechanism is essentially the same as in IPv4.
Packets are forwarded hop-by-hop based on a lookup in the forwarding table for the longest prefix
match. This provides the next hop for forwarding the packet. The IPv6 header has some significant
changes that simplify the forwarding process compared to IPv4.
The main changes in the forwarding process are:
- No header length field to process since the IPv6 header is a fixed length.
-No checksum calculations. In IPv4 the header checksum is verified and recalculated at each hop since
the TTL value changes at each hop. IPv6 relies on the error checking performed by
Layer 2 and the error checking of upper layer protocols.
- No fragmentation operations to perform
Module 5 Page 143
IPv6 Header
IPv6 Header Fields
Version identifies protocol version (as in IPv4)

Traffic Class similar to TOS in IPv4
First 6 bits are DSCP, last two Explicit Congestion Notification
Payload length like IPv4 except that it does not include headers
Next header like protocol field in IPv4, except that it may also
indicate an extension header
Hop limit similar to TTL, except that it is strictly a hop count
Source and destination addresses as in IPv4 except that it
contains 128 bit addresses
Module 5 |
144
Version As in IPv4 this field contains the protocol version number, in this case the value 6.
Traffic Class Similar to the TOS (Type of Service) field in IPv4, this value is used for prioritizing the
treatment of traffic. The first 6 bits are to be interpreted as the Differentiated Services Code Point
(DSCP) defined in RFC 2474 and the last two as Explicit Congestion Notification defined in RFC 3168.
Flow Label This field has no counterpart in IPv4. It can be used to indicate that this packet belongs to
a specific data flow of an upper layer protocol or application. This could be used as a simple
classification mechanism by an intermediate router to identify all the packets belonging to a specific
application, for example. The use of this field is defined in RFC 3697.
Payload Length Similar to the IPv4 total length field except that this field indicates payload length
only. Since this is a 16 bit field, the maximum size of a regular size IPv6 packet is 65,535 bytes plus
headers. A larger size field in the hop-by-hop options extension header provides for jumbograms up to
a maximum of 232 - 1 bytes.
Next Header This corresponds to the Protocol field in IPv4. In IPv6 it is also used to indicate that
there are extension headers in use. An IPv6 packet may have 0 or multiple extension headers. The
value in this field in the last extension header indicates the upper layer protocol carried in the packet.
Hop Limit This is the same as the TTL field in IPv4, although it is considered strictly a hop count in
IPv6. The value is decremented by each router. If the value reaches zero the packet is discarded and an
ICMPv6 message is sent to the source.
Source and Destination Address These fields have the same meaning as in IPv4, except that each
requires 128 bits in IPv6.
Module 5 Page 144
Flow label identifies packet as part of higher layer flow
Value
0
6
17
41
43
44
50
51
58
59
60
Description
IPv6 Hop-by-hop options
Upper layer protocol TCP
Upper layer protocol UDP
IPv6 Encapsulation header (tunneling)
Routing extension header
Fragment extension header
Encapsulating Security Payload (ESP)
Authentication Header (AH)
ICMPv6
IPv6 No next header
Destination options
Module 5 |
145
In general, only the IPv6 header is used by intermediate routers for forwarding, and the extension
headers are only processed at the destination. The exception is the hop-by-hop options header that
must be processed by each intermediate router. Therefore, if it exists, it must be the first extension
header after the IPv6 header. The extension headers described below must be supported by all IPv6
routers.
Hop-by-hop options These are a grouping of options that must be processed by intermediate
routers. These include the option for jumbograms (RFC 2675) and the Router Alert option (RFC 2711).
Routing extension header This provides the ability for source routing. RFC 2460 defines a Type 0
routing header (RH0) for loose source, but this was deprecated in RFC 5095 because of security
concerns. Mobility support in IPv6 (RFC 3775) defines a Type 2 routing header (RH2).
Fragment extension header IPv6 routers do not fragment IPv6 packets, but the fragment extension
header allows the source router to fragment packets in case the payload supplied by the upper layer
protocol is too large for the link or path MTU. This should not be a common occurrence.
ESP header The ESP header (RFC 2402) is an IPsec header that provides security for IPv6 and
IPv4. ESP provides authentication, data integrity and data confidentiality for all fields after the ESP
header, but not for the IPv6 header.
AH header The AH header (RFC 2406) is an IPsec header that provides authentication for IPv6 and
IPv4. AH provides authentication and data integrity services for the entire packet, except for the fields of
the header that might change in transit (Traffic Class, Flow Label and Hop Limit).
Destination options The destination extension header defines options that are to be examined only
by the destination router. Mobility support in IPv6 (RFC 3775) defines a Type 201 destination option for
carrying the Home Address of a mobile router.
Except for the hop-by-hop options header, the extension headers have no impact of the forwarding of
IPv6 packets and are not discussed any further in this course.
Module 5 Page 145
IPv6 Next Header Field
New version of ICMP defined in RFC 4443 for IPv6

Similar structure as for IPv4, but more functionality
Neighbor Discovery (ND) protocol replaces ARP

Multicast Listener Discovery (MLD) replaces IGMP
Module 5 |
146
The ICMPv6 header is similar to ICMPv4. The meaning of each field is described below:
Type The 8-bit type field indicates the type of ICMPv6 message.
Code Similar to IPv4, a specific ICMPv6 message type may (or may not) have a number of codes
defined to further define the nature of the message.
Checksum A 16-bit checksum of the ICMPv6 message, plus the IPv6 pseudo-header (includes the
source address, destination address, length and next header fields of the IPv6 header).
Message The contents of the message body varies, depending on the type of message.
Module 5 Page 146
ICMPv6
ICMPv6 Message Types

Message
Destination Unreachable
Packet Too Big
Time Exceeded
4
127
Parameter Error
Reserved for expansion of ICMPv6 error messages
128
Echo Request
129
Echo Reply
130
Multicast Listener Query
131
Multicast Listener Report
132
Multicast Listener Done
133
Router Solicitation
134
Router Advertisement
135
Neighbor Solicitation
136
Neighbor Advertisement
137
Redirect Message
255
Reserved for expansion of ICMPv6 informational messages
Module 5 |
147
For the type value, the range 0 to 127 (high order bit zero) is used for error messages. The range 128 to
255 (high order bit one) is used for informational messages (anything other than an error message).
Some of the different ICMPv6 message types are shown above. At present (2011) the IANA has
allocated all the values from 128 thru 154.
Some of the ICMPv6 message types are described in more detail below:
Destination Unreachable Generated when the packet could not be routed to the destination or the
upper layer protocol. Code values 0 thru 6 are defined.
Packet Too Big Generated when the MTU of the forwarding interface is too small for the packet to
be forwarded. This message is used for path MTU discovery, which should be supported by IPv6
routers.
A sender will initially choose its link MTU as the path MTU. If this is too large for transmission to the
destination, the sender will receive a Packet Too Big message with the MTU of the smaller link. The
sender will reset the path MTU to the MTU of the smaller link and will continue in this way until no more
Packet Too Big messages are received. If the path to the destination changes during a session and a
Packet Too Big message is received, the sender resets the path MTU to this value.
When the path MTU is smaller than the local link MTU, the sender may periodically (every 10 minutes is
recommended) send a packet at the size of the link MTU to determine whether the path MTU can be
increased. A sender that does not support path MTU discovery should always use the minimum IPv6
MTU of 1280 for its transmissions.
Time Exceeded Generated if the hop limit is exceeded or the time to reassemble a packet at the
destination is exceeded (60 seconds).
Parameter Error Generated if an unknown or illegal parameter is found in the header, such as an
unknown value in the Next Header field.
Echo Request, Echo Reply A program such as ping will send an Echo Request to a destination
router. The destination should respond with an Echo Reply message.
Module 5 Page 147
Type
Neighbor Discovery Functions
Router discovery find routers on a link

Prefix discovery find address prefixes on a link
Parameter discovery find link parameters
Address resolution resolve IPv6 address to a link layer address
Next-hop determination find next-hop address for a destination
Neighbor unreachability determine that the neighbor is not
reachable
Duplicate address detection identify duplicate addresses on a link
Redirect inform host of a better next hop
Module 5 |
148
The neighbor discovery (ND) protocol for IPv6 (RFC 4861) provides the capabilities handled in IPv4 by
ARP, router discovery and router redirect and quite a few additional capabilities as well. The functions
handled by ND are:
Router discovery Find routers on a link.
Prefix discovery Find the address prefixes for a link.
Parameter discovery Find link parameters such as MTU or hop Limit.
Address autoconfigurationMechanism that allows an interface to configure its own address (defined
in RFC 4862).
Address resolution Resolve a destination IP address to a link layer address.
Next-hop determination Map an IP address into the next-hop address that the packet should be
sent to.
Neighbor unreachability detection Mechanism to determine that the neighbor is no longer
reachable. If this is the default router, the host can change its default to another router.
Duplicate address detection Mechanism to identify duplicate addresses on the link.
Redirect Allow a router to inform a host of a better next hop to a destination.
Module 5 Page 148
Address autoconfiguration automatically configure an address
Neighbor Discovery Message Types
Description
133 Router Solicitation
New host asking for a Router

Advertisement
134 Router Advertisement
Router advertising itself and link

parameters
135 Neighbor Solicitation
Used to find the link address of a

neighbor
136 Neighbor Advertisement Response to a Neighbor Solicitation

137 Redirect
Informs a host of a better next hop
Module 5 |
149
ND uses five different ICMPv6 messages to perform the functions described above. The messages are:
Router Solicitation (Type 133) When a host becomes active on a link it can send a Router
Solicitation to ask for a Router Advertisement immediately.
Router Advertisement (Type 134) Routers advertise their presence and link parameters periodically
with Router Advertisement messages. This information can include link MTU, link prefixes and route
information.
Neighbor Solicitation (Type 135) Used by a router to determine the link address on a neighbor, or
to verify that the neighbor is still reachable. If the link address is unknown, the message is sent to the
solicited node multicast address. Since this address is formed with the last 24 bits of the IP address, it is
unlikely that there will be more than one router with the address. This makes the protocol much less
disruptive than ARP. If the router is verifying a known link address, the message is sent to the unicast
address.
Neighbor Advertisement (Type 136) Response to a Neighbor Solicitation sent to the unicast
address. A router may also send an unsolicited Neighbor Advertisement to announce a link address
change.
Redirect (Type 137) Sent by a router to inform a host of a better next hop address.
Module 5 Page 149
Type Message
Router sends Neighbor Solicitation to solicited-node multicast

address (03-03-ff-0e-93-31)
Neighbor responds with Neighbor Advertisement to unicast address
Module 5 |
150
Neighbor Discovery replaces the ARP protocol in IPv4. A device that wants to resolve an IPv6 address
to a MAC address sends a Neighbor Solicitation message containing the IPv6 address. This message is
sent to the solicited node multicast address formed from the desired unicast address. The neighbor that
has this unicast address is likely the only one listening to this multicast group. It responds with a
Neighbor Advertisement message containing its MAC address. ND is more efficient than ARP since
other hosts on the network do not have to process a broadcast message.
The flags in the Neighbor Advertisement message have the following meaning:
Router The advertisement message was sent by a router.
Solicited The advertisement was sent in response to a Neighbor Solicitation message.
Override The advertisement should override an existing cache entry.
Module 5 Page 150
MAC Address Discovery
Configuring IPv6 Interfaces
Link-local address automatically created from MAC address

Global routing addresses can be assigned as needed
*A:R1#
*A:R1# configure
configure system
system chassis-mode
chassis-mode cc force
force
*A:R1#
*A:R1# configure
configure router
router
*A:R1>config>router#
*A:R1>config>router# interface
interface "toR2"
"toR2" ipv6
ipv6
*A:R1>config>router
if>ipv6# exit
exit
*A:R1>config>router>>if>ipv6#
interface "toR3"
"toR3" ipv6
ipv6
*A:R1>config>router>if>ipv6#
*A:R1>config>router>if>ipv6# exit
exit
interface "system"
"system" ipv6
ipv6
*A:R1>config>router>if>ipv6# address
address 2001:db8:1:100::1/128
2001:db8:1:100::1/128
*A:R1>config>router>if>ipv6# exit
exit
Module 5 |
151
Configuring IPv6 interfaces and routing for IPv6 is very similar to configuration of IPv4. The most
obvious difference is the use of IPv6 addresses. IPv6 and IPv4 can be configured in parallel on the
same network.
In order to use IPv6 on the Alcatel-Lucent 7750 SR, you must first enable chassis mode c or higher.
IPv6 is only supported on IOM2s or newer. As soon as we enable IPv6 on the interface, a link local
address is automatically assigned based on the modified EUI-64 address. If its not necessary to route to
the interfaces, we dont need to assign them global routing addresses - we can simply use the link local
addresses.
In this example, the enterprise has been allocated a prefix from their service provider, 2001:db8:1::/48.
The enterprise decides to subnet the prefix using the first 8 bits to identify a specific location and the
second 8 bits to identify subnets at that location. The router in this example is at location 01. System
interfaces are addressed using subnet 00 at all locations. The system address for this router is thus
2001:db8:1:100::1/128, which is assigned to the system interface.
Module 5 Page 151
Router must have chassis-mode c or higher
Interface Verification
IPv4 and IPv6 addresses can be used at the same time
===============================================================================
===============================================================================
Interface
Interface Table
Table (Router:
(Router: Base)
Base)
===============================================================================
===============================================================================
Interface-Name
Adm
Opr(v4/v6)
Port/SapId
Interface-Name
Adm
Opr(v4/v6) Mode
Mode
Port/SapId
IP-Address
PfxState
IP-Address
PfxState
------------------------------------------------------------------------------------------------------------------------------------------------------------system
Up
Up/Up
Network
system
Up
Up/Up
Network system
system
10.10.10.1/32
n/a
10.10.10.1/32
n/a
2001:DB8:1:100::1/128
PREFERRED
2001:DB8:1:100::1/128
PREFERRED
toR2
Up
Up/Up
Network
1/1/1
toR2
Up
Up/Up
Network 1/1/1
10.1.2.1/27
n/a
10.1.2.1/27
n/a
FE80::225:BAFF:FE30:7908/64
PREFERRED
FE80::225:BAFF:FE30:7908/64
PREFERRED
toR3
Up
Up/Up
Network
toR3
Up
Up/Up
Network 1/1/3
1/1/3
10.1.3.1/27
n/a
10.1.3.1/27
n/a
FE80::225:BAFF:FE30:790A/64
PREFERRED
FE80::225:BAFF:FE30:790A/64
PREFERRED
------------------------------------------------------------------------------------------------------------------------------------------------------------Interfaces
Interfaces :: 33
===============================================================================
===============================================================================
Module 5 |
152
The interfaces have already been configured with IPv4 addresses. You can see that the link local
address was formed from the MAC address of the interfaces. The router is running both IPv4 and IPv6
and the interfaces are up for both protocols.
IPv6 defines state for prefixes. They can be tentative, preferred, duplicated or deprecated. An address
should be preferred, which means it can be used without restrictions. An IPv6 interface performs
duplicate address detection and the state of the prefix is Tentative until the address has been confirmed
as unique.
Module 5 Page 152
*A:R1>config>router# show
show router
router interface
interface
Interface Verification (continued)
Link-local addresses never appear in the route table

Router can route both IPv4 and IPv6
===============================================================================
===============================================================================
IPv6
IPv6 Route
Route Table
Table (Router:
(Router: Base)
Base)
===============================================================================
===============================================================================
Dest
Prefix
Type
Proto
Age
Pref
Dest Prefix
Type
Proto
Age
Pref
Next
Metric
Next Hop[Interface
Hop[Interface Name]
Name]
Metric
------------------------------------------------------------------------------------------------------------------------------------------------------------2001:DB8:1:100::1/128
Local
00h08m56s
2001:DB8:1:100::1/128
Local Local
Local
00h08m56s 00
system
00
system
------------------------------------------------------------------------------------------------------------------------------------------------------------No.
No. of
of Routes:
Routes: 11
===============================================================================
===============================================================================
Module 5 |
153
The interfaces have already been configured with IPv4 addresses. You can see that the link local
address was formed from the MAC address of the interfaces. The router is running both IPv4 and IPv6
and the interfaces are up for both protocols.
Module 5 Page 153
*A:R1>config>router# show
show router
router route-table
route-table ipv6
ipv6
Module 5 |
154

Services Architecture v3.2 Student Guide Download

Uploaded by

Document Information

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

Services Architecture v3.2 Student Guide Download

Uploaded by

Copyright:

Available Formats

Alcatel-Lucent Services Architecture

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 0 Course Introduction

Alcatel-Lucent Services Architecture v3.2

All rights reserved 2012 Alcatel-Lucent

Alcatel-Lucent Career Certification

Alcatel-Lucent Services Architecture v3.2

All rights reserved 2012 Alcatel-Lucent

Alcatel-Lucent Services Architecture

Alcatel-Lucent Services Architecture v3.2

All rights reserved 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

4 DAYS / 1 COURSE / 1 WRITTEN EXAM

18 DAYS / 4 COURSES / 4 WRITTEN EXAMS /

32 DAYS/ 7 COURSES / 7 WRITTEN EXAMS /

Alcatel-Lucent Services Architecture v3.2

Alcatel-Lucent Services Architecture v3.2

All rights reserved 2012 Alcatel-Lucent

All rights reserved 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Alcatel-Lucent Service Routing Certification Program Four Certifications

Alcatel-Lucent Services Architecture v3.2

Alcatel-Lucent Services Architecture v3.2

All rights reserved 2012 Alcatel-Lucent

All rights reserved 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

SRC Program Courses and Exams

Alcatel-Lucent Scalable IP Networks

Alcatel-Lucent Interior Routing Protocols

Alcatel-Lucent Border Gateway Protocol

Alcatel-Lucent Multiprotocol Label Switching

Alcatel-Lucent Services Architecture

Alcatel-Lucent Virtual Private LAN Services

Alcatel-Lucent Virtual Private Routed Networks

Alcatel-Lucent Quality of Service

Alcatel-Lucent Multicast Protocols

Alcatel-Lucent Triple Play Services

Alcatel-Lucent Advanced Troubleshooting

Alcatel-Lucent IP/MPLS Mobile Backhaul Transport

Alcatel-Lucent Mobile Gateways for the LTE Evolved

Alcatel-Lucent Network Routing Specialist II Lab Exam

100, 101, 103, 104

Alcatel-Lucent Mobile Routing Professional Lab Exam

100, 101, 103, 104, 107, M01, M02, NRSII4A0

Alcatel-Lucent Service Routing Architect Lab Exam

Alcatel-Lucent Services Architecture v3.2

Alcatel-Lucent Services Architecture v3.2

All rights reserved 2012 Alcatel-Lucent

All rights reserved 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

SRC Program Exam Profile

Alcatel-Lucent Services Architecture v3.2

Alcatel-Lucent Services Architecture v3.2

All rights reserved 2012 Alcatel-Lucent

All rights reserved 2012 Alcatel-Lucent

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

SRC Program Global Reach, Flexible Delivery Options

On-site delivery at your business location anywhere in the world

Delivery from any of fifteen Alcatel-Lucent University locations globally

Wellington, New Zealand

Alcatel-Lucent Services Architecture v3.2

Alcatel-Lucent Services Architecture v3.2

All rights reserved 2012 Alcatel-Lucent

All rights reserved 2012 Alcatel-Lucent