CCIE SP Notes For Lab

Method
IOS
interface X
ip vrf forwarding VPN-A
!
interface X
vrf forwarding VPN-B
IOS-XR
interface X
vrf VPN-C
Multi-VRF Selection Using Policy-Based Routing

It allows a specific interface on a PE router to route packets to different VPNs based on
various match
criteria defined in an ip access list or on packet length.

107 NTS for CCIE SP Lab by chatasos
chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab
IOS
interface X
ip vrf receive VPN-A
ip vrf receive VPN-B
ip vrf receive VPN-C
ip address 1.1.1.1 255.255.255.0
ip policy route-map VRF-SELECTION-PBR
ip access-list standard VPN-A-ACL permit 1.1.2.2
ip access-list standard VPN-B-ACL permit 1.1.3.3
ip access-list standard VPN-C-ACL permit 1.1.4.4
!
route-map VRF-SELECTION-PBR
match ip address VPN-A-ACL
set vrf VPN-A

!
route-map VRF-SELECTION-PBR match ip address VPN-B-ACL set vrf

VPN-B
!
route-map VRF-SELECTION-PBR
match ip address VPN-C-ACL set vrf VPN-C
permit 10
permit 20
permit 30
Limitations
multicast is not usually supported by PBR
VRF Selection Based on Source IP Address

It allows a specific interface on a PE router to route packets to different VPNs based upon the
source IP
address of the packets. It's supported only on very specific hardware.
IOS
vrf selection source 1.1.1.0 255.255.255.0 vrf VPN-A vrf

selection source 2.2.2.0 255.255.255.0 vrf VPN-B !
int X
ip vrf select source ip vrf receive VPN-A ip vrf receive VPN-B

Limitations
 supported by limited hardware

 performance can degrade with longer subnet masks
If it's not supported by the router, you'll get the following output:
R1(config)#vrf selection source 1.1.1.0 255.255.255.0 vrf

VPN-A
% VRF Select: failed to add config
VRF-Autoclassify
It allows a specific interface on a PE router to route packets to different VPNs based
on the ip addresses
assigned to directly connected hosts.
At the same time it also enables certain types of Policy Based Routing (PBR) to be
created dynamically without configuring all the related route maps and access lists.
More specifically it enables the dynamic configuration of policies that are required for
the mapping of packets to the VRFs, depending on whether the source address of the
packet belongs to those connected routes.
IOS
interface X
ip address
ip address
ip address
ip vrf autoclassify source
1.1.1.1 255.255.255.0 secondary vrf VPN-A 1.1.2.1

255.255.255.0 secondary vrf VPN-B 2.2.2.2 255.255.255.0
ip vrf forwarding VPN-A
ip address 10.10.10.1 255.255.255.0 !
interface Z
ip vrf forwarding VPN-B
ip address 20.20.20.1 255.255.255.0
Limitations
!
interface Y

any directly connected hosts must not run routing protocols

the router that is enabled with the VRF-Autoclassify feature must not run routing protocols
applies only to unicast packets
ACL Based Forwarding (ABF) with VRF Next-Hop
It allows packet arriving on ingress VRF to get routed on an egress interface which is in a
different VRF based on various match criteria defined in an ip access list.
So you actually specify a nexthop VRF instead of a specific IP address for the nexthop. When
this config is enabled, packet destination lookup will be performed in the ABF Nexthop VRF.
IOS-XR
interface X
ipv4 address 10.10.10.10 255.255.255.0 vrf VPN-A
ipv4 access-group ABF-ACL ingress
!
ipv4 access-list ABF-ACL
permit ipv4 1.1.2.2 0.0.0.0 any nexthop1 vrf VPN-A permit ipv4
1.1.3.3 0.0.0.0 any nexthop1 vrf VPN-B permit ipv4 1.1.4.4
0.0.0.0 any nexthop1 vrf VPN-C
Limitations
applies only to ASR9k and CRS running IOS-XR
MPLS/LDP
LDP (Label Distribution Protocol) is defined in RFC 5036.
MPLS (Multi-Protocol Label Switching) architecture is defined in RFC 3031. MPLS Label
Stack Encoding is defined in RFC 3032.
LDP messages
LDP Discovery (to directly connected neighbors) o Multicast UDP to 244.0.0.2:646
targetedLDP Discovery (to non-directly connected neighbors) o Unicast UDP to

x.x.x.x:646
LDP Session/Advertisement/Notification (to all) o Unicast TCP to x.x.x.x:646

o
A working IGP between neighbors is a requirement for all the above, besides LDP Discovery.
Label retention/distribution
 Label retention
o liberal
o conservative
 Label distribution
o downstream
unsolicited
on-demand
Liberal, downstream, unsolicited is the most common case.
General
Although in latest software releases LDP is the default label protocol, it's a good
practice to always enable it with"mpls label protocol
ldp".Thesameapplieswiththe"mpls ldp router-id",which should in most
cases be loopback0.
Use"sh mpls ldp bindings"tochecktheLIB(labelsforallIGPdatabaseprefixes)

Use"sh mpls forwarding"tochecktheLFIB(labelsforRIBinstalledprefixes)
Outgoing Label under "show mpls forwarding-table":
X Label
o Local device is an LSR Pop Label
o Local device is an LSR and also the PHP No Label

o Local device is a LER

Youneedtoconfigure"mpls ldp explicit-
null"ifyouwanttokeeptheEXPQoStilltheendPE.
Default is implicit-null due to PHP.
"debug mpls packet"includesthelabelstack{LabelEXPTTL}information
Fa0/0.1: rx: Len 122 Stack {29 0 253} - ipv4 data Fa0/0.2: tx:
Len 122 Stack {30 0 252} - ipv4 data
Label Allocation Methods
an IGP/Transport Label is allocated through o LDP (+IGP)
o RSVP (MPLS TE)
o Labeled BGP
a VPN Label (L3VPN) is allocated through
o MP-BGP (VPNv4/v6)
a PW Label (L2VPN) is allocated through
o Targeted LDP
an IPv6 Label (6PE) is allocated through
o Labeled BGP
Targeted LDP Sessions
You can create targeted LDP sessions (assuming ip connectivity exists) using the following
methods:
IOS
Static LDP neighbors on both routers R1
mpls ldp neighbor R2 targeted
R2
Static LDP neighbor on one router and accept targeted hellos on the other R1
Debugging should be the last thing you should do in case of a problem in production
networks. So learn not to
depend on it.
R2
mpls ldp discovery targeted-hello accept
MPLS/LDP under a TE tunnel interface on one router and static LDP neighbor on the other
R1
interface Tunnel0 tunnel destination R2 mpls ip
R2
MPLS/LDP under a TE tunnel interface on one router and accept targeted hellos on the other
R1
interface Tunnel0 tunnel destination R2 mpls ip
R2
mpls ldp discovery targeted-hello accept
Something similar applies to IOS-XR too.
IOS-XR
R1
mpls ldp
neighbor R2 targeted
R2
mpls ldp
discovery targeted-hello accept
You can also use RSVP solely for (one-hop) link protection, having tLDP on top of it.
In case of RSVP in the core and LDP in the access, you can have tLDP sessions over RSVP,
where end-to-end
LSPs will have 1 label (LDP) in the access and 2 labels (RSVP/LDP) in the core.
Simple VPN with iBGP & LDP
Assuming a network of R1-R2-R3-R4-R5-R6, where R2,R3,R4,R5 run LDP+IGP in the core

and R2,R5 run iBGP between them, then R1 and R6 can communicate between each other as
long as their networks as advertised to R2,R5 (i.e with eBGP) and R2,R5 are using their
loopbacks as next-hops in their iBGP. The intermediate routers R3,R4 just do mpls switching
based on the R2,R5 loopback labels.
R2,R5 have BGP-generated labels for the R1,R6 prefixes which according to BGP have
R2,R5 as next-hops.
These labels (which are the same as the ones used for the BGP next-hop) are shown only if
you exclusivelydefinethenetworkin"sh mpls forwarding-table"oruse"sh ip
cef".
The rule for LSP usage in BGP is that when an LSP is available for the BGP next-hop of a
route, that LSP
can be used to forward traffic to that route destination.
IOS
R2#sh mpls forwarding-table | i 6.6.6.6 R2# -no entry shown-
R2#sh
Local
Label
None
R2#sh 21
mpls forwarding-table 6.6.6.6
Outgoing
Label
22
Prefix
or Tunnel Id
6.6.6.6/32
Bytes Label
Switched
0
Known via "bgp 100", distance 200, metric 0 Tag 20, type
internal
Last update from 5.5.5.5 00:35:32 ago Routing Descriptor
Blocks:
* 5.5.5.5, from 5.5.5.5, 00:35:32 ago

Route metric is 0, traffic share count is 1 AS Hops 1
Route tag 20
MPLS label: none
Outgoing
interface
Fa0/0.23
Fa0/0.23
Next Hop
20.2.3.3
20.2.3.3
mpls forwarding-table | i 5.5.5.5
22 5.5.5.5/32
R2#sh
Routing entry for 6.6.6.6/32
ip route 6.6.6.6
R2#sh ip cef 6.6.6.6 det

6.6.6.6/32, epoch 0, flags rib only nolabel, rib defined all
labels
recursive via 5.5.5.5

nexthop 20.2.3.3 FastEthernet0/0.23 label 22
R3,R4 have LDP-generated labels for the R2,R5 next-hops

Static Labels
Check "Inter-AS MPLS L3VPN" for more examples.
LDP Auto-configuration
 Supported in OSPF and IS-IS

 Not supported on MPLS-TE Tunnels
IOS
router ospf/isis X
mpls ldp autoconfig
!
interface X
no mpls ldp igp autoconfig
IOS-XR
mpls ldp
!
router ospf/isis X
mpls ldp auto-config
!
interface X
igp auto-config disable
Use"sh mpls interfaces detail"or"sh mpls ldp discovery

detail"tofindouthow LDP was activated on an interface.
IOS-XR requires the explicit activation of MPLS LDP prior to LDP

autoconfiguration.
LDP Authentication
Authentication is applicable only to the LDP TCP session.
Whensetting"mpls ldp password

required",allLDPsessionsareclearedautomatically.
Password can be configured:
After you configure the label range, you need to remove the mpls ldp config from the IGP
process or from the
interfaces in order to use the label range. If you just clear the LDP neighbors, then the old
labels remain.
After setting the LDP password, the LDP session might need to be cleared manually to have
the password
enabled.
per neighbor
o "mpls ldp neighbor x.x.x.x password" (IOS, IOS-XR)
per group of neighbors

o "mpls ldp password option X for Y-ACL" (IOS)
as a default password for all neighbors

o "mpls ldp password fallback" ( ) o "mpls ldp neighbor password"
(
Label Filtering
IOS
The LDP default behavior is to allocate local labels for all non-BGP prefixes, which includes
IGP learned prefixes and connected interfaces with LDP on.
Local Label Allocation Filtering

o controls the allocation of local labels
o uses prefix-lists for filtering
o use "allocate global prefix-list" under "mpls ldp label" config (IOS) o use
"mpls ldp label allocate" under global config (IOS-XR)
o use "sh mpls ldp bindings local" to verify
Inbound Label Binding Filtering

o controls label bindings that a router accepts from a specific neighbor
o uses access-lists for filtering
o use "mpls ldp neighbor x.x.x.x labels accept" under global config (IOS)
o use "mpls ldp label accept" under global config (IOS-XR)
o use "sh mpls ldp bindings neighbor" to verify
Outbound Label Binding Filtering

o controls label bindings that a router sends to a specific neighbor
o uses access-lists for filtering
o use "mpls ldp advertise-labels" under global config (IOS) - "no mpls
advertise" is needed first

o use "mpls ldp label advertise" under global config (IOS-XR) o use "sh mpls
ldp bindings neighbor" to verify
, but LDP does the advertisements (i.e. Inter-AS Option C). LDP neither forwards these
entries, nor releases the local labels allocated by BGP.
Common use of label filtering is to allocate labels only for PE loopback addresses.
LDP does not apply the configured local label filter to redistributed BGP routes in the global
table for which
IOS-XR
BGP allocates the local label

LDP Session Protection
When enabled, a new targeted LDP session is created between the neighbors, in order to keep
their LDP session active over any backup path, after the direct/primary link fails. When the
primary/direct link is restored, label bindings do not need to be re-exchanged.
2 implementation choices:
 both neighbors must be configured for session protection

 one router must be configured for session protection and the other router must
simply respond to
targeted hellos
IOS
mpls ldp session protection
mpls ldp session protection for LDP-NEI-ACL duration X
IOS-XR
mpls ldp
session protection
session protection for LDP-NEI-ACL duration X
You can enable it for all LDP neighbors or for specific ones using an ACL.
IOS
R2#sh mpls ldp neighbor detail | i Protection|duration LDP

Session Protection enabled, state: Ready
duration: 86400 seconds

LDP Session Protection enabled, state: Incomplete

LDP Session Protection enabled, state: Protecting
R2#sh mpls ldp neighbor 3.3.3.3 detail ...
LDP discovery sources:

FastEthernet0/0.23; Src IP addr: 20.2.3.3
holdtime: 15000 ms, hello interval: 5000 ms Targeted Hello

2.2.2.2 -> 3.3.3.3, active, passive;
holdtime: infinite, hello interval: 10000 ms
Successful recovery
%LDP-5-SP: 3.3.3.3:0: session hold up initiated %LDP-5-SP:

3.3.3.3:0: session recovery succeeded
Failed recovery
%LDP-5-SP: 4.4.4.4:0: session hold up initiated %LDP-5-SP:

4.4.4.4:0: session recovery failed
%LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (1) is DOWN (Session

Protection disabled targeted session)
LDP IGP Synchronization
When enabled, links where LDP adjacencies are not established, will have their IGP metric
increased to the max by the local IGP process.
Generally when an IGP adjacency is established on a link with LDP-IGP Sync on, but LDP-
IGP Sync is not yet achieved (or is lost), the IGP advertises the max-metric on that link. That
way the link won't be preferred for passing traffic and black-holing will be prevented.
IOS
router ospf/isis X
mpls ldp sync
!
mpls ldp igp sync holddown x !
interface X
no mpls ldp igp sync

mpls ldp igp sync
IOS-XR
router ospf/isis X
mpls ldp sync
!
mpls ldp
igp sync delay x

interface X
igp sync delay x
IOS
R2#sh mpls ldp igp FastEthernet0/0.23:
LDP configured; LDP-IGP Synchronization enabled.
Sync status: sync achieved; peer reachable. Sync delay time: 0

seconds (0 seconds left) IGP holddown time: infinite.
Peer LDP Ident: 3.3.3.3:0
IGP enabled: OSPF 1
R2#sh mpls ldp igp sync FastEthernet0/0.23:
LDP configured; LDP-IGP Synchronization enabled.
Sync status: sync not achieved; peer reachable.

delay x
sync
Sync delay time: 0 seconds (0 seconds left) IGP holddown time:

infinite.
Peer LDP Ident: 3.3.3.3:0
IGP enabled: OSPF 1
IOS-XR
GSR#sh mpls ldp igp sync
GigabitEthernet0/1/0/1.619:
Sync status: Ready Peers:
6.6.6.6:0
Targeted LDP sessions (i.e. AToM) are not supported, which is expected because these are
already tLDP sessions that can use IGP for rerouting.
In IS-IS the maximum wide metric -1 (0XFFFFFE) is used with MPLS LDP IGP
synchronization.
Links
 IETF - RFC 5443
 IETF - RFC 6138
TTL Propagation
Default behavior is to copy the TTL from the IP header to the MPLS header (topmost
label). 2 extra options are available:
do not copy the TTL for forwarded packets

o "no mpls ip propagate-ttl forwarded" (IOS)
o "mpls ip-ttl-propagate disable forwarded" (IOS-XR)
do not copy the TTL for locally generated packets

o "no mpls ip propagate-ttl local" (IOS)
o "mpls ip-ttl-propagate disable local" (IOS-XR)
If the TTL is not copied for forwarded packets, then a traceroute from a local CE to a remote
CE, will include the local PE, the remote PE and the remote CE (all the intermediate P
routers won't be shown). You can use this in order to hide the MPLS hops from the customer.
You only need to disable the TTL propagation on the PEs, since the P (LSR) routers do not
see the
original IP packet, so no TTL propagation takes place there.

Traceroute in MPLS L3VPNs works a little bit differently than in normal IP networks,
because when the traceroute packet reaches the MPLS core (P routers), the local generated
ttl-exceeded response packet must first reach the PE at the other side of the VPN before it's
returned back to the traceroute source.
i.e. in a traceroute from CE1 to CE2 (CE1-PE1-P-PE2-CE2), the following happens
 CE1 sends a ICMP packet with TTL=1 o Source=CE1
o Destination=CE2
o TTL=1
 PE1 receives the ICMP packet

 PE1 sends an ICMP ttl-exceeded response back to CE1
o Source=PE1
o Destination=CE1
 CE1 receives the ICMP response

 CE2 sends an ICMP packet with TTL=2
o Source = CE1
o Destination=CE2 o TTL=2
 PE1 receives the ICMP packet

 PE1 forwards the ICMP packet to the next P
o Source=CE1
o Destination=CE2 o TTL=1
 P receives the ICMP packet

 P creates an ICMP ttl-exceeded response and sends it to PE2 using the original
label stack
o Source=P
o Destination=CE1 o TTL=default
 PE2 receives the ICMP response and forwards it to CE1 which is the actual
destination o Source=P
o Destination=CE1
 CE1 receives the ICMP response

 CE1 sends a ICMP packet with TTL=3
o and so on...
MPLS MTU
Every label adds 4 bytes to the frame size. Common label stacks
L3VPN
o LDP label + VC label
L2VPN/VPLS
o LDP label + VC label
MPLS-TE
o TE label + VC label
o TE label + LDP label + VC label MPLS-TE/FRR
o FRR label + TE label + VC label
o FRR label + TE label + LDP label + VC label AToM & TE/FRR & CsC
o FRR label + TE label + LDP label + VPN label + VC label Common transport header sizes
(in bytes):
 Ethernet port:14
 Ethernet VLAN: 14 + 4 per vlan tag
 Frame-Relay DLCI: 2 (Cisco), 8 (IETF)
 HDLC/PPP: 4
 AToM Control Word: 4
All L3 protocols (i.e. IPv4, IPv6, MPLS, CLNS) inherit their MTU settings from L2
MTU.
The default MPLS MTU value of a link equals the interface MTU value. You need to
first change the interface MTU in order to be able to increase the MPLS MTU too.
IOS
R4#sh mpls int detail Interface FastEthernet0/0:

IP labeling not enabled
LSP Tunnel labeling enabled BGP labeling not enabled MPLS
operational
MTU = 1500
IOS
interface FastEthernet0/0
mtu 1530

LSP Tunnel labeling enabled BGP labeling not enabled MPLS
operational
MTU = 1530
IOS
interface FastEthernet0/0 mtu 1530

mpls mtu 1508

LSP Tunnel labeling not enabled BGP labeling not enabled
MPLS operational
MTU = 1508
In IOS-XR, interface MTU includes the L2 header (i.e. +14 bytes in case of untagged
ethernet).
IOS-XR
interface TenGigE0/0/0/6
mtu 9214
IOS-XR
ASR9k#sh imds int Te0/0/0/6
View: OWN - Owner, L3P - Local 3rd Party, G3P - Global 3rd
Party,
LDP - Local Data Plane, GDP - Global Data Plane, RED -

Redundancy Node 0/RSP0/CPU0 (0x41)
Interface TenGigE0/0/0/6, ifh 0x000002c0 (up, 9214)
Interface flags:
Encapsulation: Interface type: Control parent: Data parent:

Views:
Protocol
--------
None
None
arp
ipv4
mpls ether_sock ether_link_oam
0x000000000010059f (IFCONNECTOR|IFINDEX |SUP_NAMED_SUB|

BROADCAST|CONFIG|HW|VIS|DATA |CONTROL)
ether
IFT_TENGETHERNET None
None
GDP|G3P
Caps (state, mtu) -----------------

spio (up, 9214)
ether (up, 9214)
arp (up, 9200)
ipv4 (up, 9200)
mpls (up, 9200) ether_sock (up, 9200) ether_link_oam (up,
9200)
The"sh imds"commandishiddeninmostIOS-XRreleases.
IOS-XR
ASR9k#sh ip int Te0/0/0/6

TenGigE0/0/0/6 is Up, ipv4 protocol is Up
Vrf is default (vrfid 0x60000000)

Internet address is 10.201.10.221/30
MTU is 9214 (9200 is available to IP)
Fragmentation
If a labeled packet is received and the LSR notices that the outgoing MTU is not big enough
for this packet, the LSR strips off the label stack, fragments the IP packet, puts the label stack
(after the pop, swap, or push operation) onto all fragments, and forwards the fragments.
If the IP header has the DF bit set, the LSR doesn't fragment the IP packet, but it drops the
packet and returns an ICMP error message "Fragmentation needed and do not fragment bit
set" to the originator of the IP packet (following the same procedure as with traceroute).
Fragmentation should be avoided if possible.
IOS uses MRU in order to "inform" the LSR how big a received labeled packet of a certain
FEC can be in order for that to be forwarded out of this LSR without fragmenting it.
In IOS-XR, if you change the interface MTU, then you need to take into account the L2
header. If you change
the L3 protocol MTU, then it's the same as in IOS.

IOS
R6#sh mpls forwarding-table 19.19.19.19 detail
Local
Label
None
20.6.19.19
Outgoing
Label
No Label
Prefix
or Tunnel Id 19.19.19.19/32
Bytes Label
Switched
0
Outgoing
interface
Fa0/0.619
Next Hop
MAC/Encaps=18/18, MRU=1504, Label Stack{}

CA020BB00008CA01063000008100026B0800
No output feature configured
123
NTS for CCIE SP Lab by chatasos
L3VPN Redistribution
Configuration Steps
 Configure the VRFs

 Configure the RDs
 Configure the import/export RTs
 Assign the PE=>CE interfaces to VRFs
 Configure IGP/BGP between PE-CE
 Configure MP-BGP between PEs
 Mutually redistribute between MP-BGP and the PE-CE IGP
BGP<=>RIP
RIP=>BGP
RIP metric => BGP MED (auto)
RIP=>BGP=>RIP
RIP metric => BGP MED => RIP metric (auto)
OTHER=>BGP=>RIP
BGP X => RIP metric (manual)
If "auto" doesn't work (for whatever reason), you can trying clearing the vrf routing
table on the PE or you can use the following to set manually the RIP metric:
 redistribute bgp 100 metric transparent

 redistribute bgp 100 metric X
 redistribute bgp 100 route-map X
Clearing of vrf routing table might be needed every time a new prefix is redistributed.
If version 2 is to be used, then it must be defined under the ipv4 vrf address-family on
the PE.
RIP metric = hops (0-16)
Configuration
IOS
router rip
address-family ipv4 vrf VPN redistribute bgp 200
!
router bgp 100
address-family ipv4 vrf VPN

redistribute rip
IOS-XR
router rip
vrf VPN
redistribute bgp 200
!
router bgp 200
vrf VPN
address-family ipv4 unicast
redistribute rip
BGP<=>EIGRP
EIGRP=>BGP
EIGRP composite metric => BGP MED (auto)
EIGRP vector metrics => BGP Extended Cost Community (auto)
EIGRP=>BGP=>EIGRP
EIGRP composite metric => BGP MED => EIGRP composite metric (auto)
EIGRP vector metrics => BGP Extended Cost Community => EIGRP vector metrics (auto)
original internal EIGRP routes appear as internal EIGRP routes when redistributed
original external EIGRP routes appear as external EIGRP routes when redistributed
OTHER=>BGP=>EIGRP
BGP X => EIGRP metrics (manual)
original routes appear as external EIGRP routes when redistributed
If "auto" doesn't work (for whatever reason), you can trying clearing the vrf routing table on
the PE or you can use the following to set manually the EIGRP metrics:
 redistribute bgp 100 metric K1 K2 K3 K4 K5

 redistribute bgp 100 route-map X
 redistribute bgp 100 route-policy X
 redistribute bgp 100 & default-metric K1 K2 K3 K4 K5
EIGRP vector metrics = K1 K2 K3 K4 K5 (i.e. 1000 10 255 1 1500)
Configuration
IOS
router eigrp 100

address-family ipv4 vrf VPN autonomous-system 1
redistribute bgp 200 exit-address-family
!
router bgp 200
redistribute eigrp 1
IOS-XR
router eigrp 100
vrf VPN
address-family ipv4
autonomous-system 1
redistribute bgp 200 !
router bgp 200

vrf VPN
redistribute eigrp 1
Redistribution of EIGRP into the BGP vrf requires the EIGRP autonomous-system number to
be redistributed. Some software releases may accept the global EIGRP process too.
You can use the SoO extended community to prevent any possible loops.
BGP<=>ISIS
ISIS=>BGP
ISIS metric => BGP MED (auto)
ISIS=>BGP=>ISIS
ISIS metric => BGP MED => ISIS metric (auto)
OTHER=>BGP=>ISIS
BGP X => ISIS metric (manual)
You can use the following to set manually the ISIS metric:
 redistributebgp 100 metric X

 redistributebgp 100 route-map X
ISIS metric = hops (10)
Configuration
IOS
router isis 100
address-family ipv4 vrf VPN redistribute bgp 200
!
router bgp 200
redistribute isis 100
IOS-XR
router isis 100
vrf VPN
redistribute bgp 200
!
router bgp 200
vrf VPN
redistribute isis 100
Redistribution doesn't take into account the IS-IS connected routes. You have to explicitly
define them.
In order to void a possible loop while doing redistribution (when L1 is involved), you can
change the distance of the ISIS advertised routes (excluding connected) on the PE to be
higher than BGP's.
IOS
router isis 100

vrf VPN
distance 201 0.0.0.0 255.255.255.255 ISIS-NOT-CONNECTED-ACL
BGP<=>OSPF
OSPF=>BGP
OSPF metric => BGP MED + 1 (auto)
OSPF Area/LSA => BGP extended community "OSPF RT" (auto)
OSPF=>BGP=>OSPF
OSPF metric => BGP MED + 1 => OSPF metric (auto)
 original intra-area routes appear as inter-area routes when redistributed (if same
OSPF Domain-ID)
 original intra-area routes appear as external-2 routes when redistributed (if different
OSPF Domain-
ID)
 type-4 LSAs are not redistributed into BGP

 original external routes appear as external-2 routes when redistributed (requires
"match external" in
redistribution from OSPF to BGP)

OTHER=>BGP=>OSPF
BGP X => OSPF metric (manual)
You can always use the following to manually set the OSPF metric:
 redistributebgp 200 metric X

 redistributebgp 200 route-map X
OSPF metric = interface cost (0-65535)
"OSPF RT" Extended Community
"OSPF RT" format is "Area:LSA-Type:External-Type"
LSA Type to OSPF RT conversion
 Type-1/2 => RT 2
 Type-3 => RT 3
 Type-5 => RT 5
 Type-7 => RT 7
 Sham-links => RT 129 Examples
OSPF RT:0.0.0.0:2:0 o area 0.0.0.0
o LSA-Type 1/2 OSPF RT:0.0.0.0:5:0
o LSA-Type 5
o External 1
OSPF RT:0.0.0.0:5:1
o LSA-Type 5 o External 2
Configuration
IOS
router ospf 100 vrf VPN redistribute bgp 200 subnets
!
router bgp 200
address-family ipv4 vrf VPN redistribute ospf 100 vrf VPN
IOS-XR
router ospf 100

vrf VPN
redistribute bgp 200 !
router bgp 200

vrf VPN
address-family ipv4 unicast redistribute ospf 100
In IOS, if you don't include the vrf name in the redistribution of OSPF into BGP, it gets
automatically added to the configuration.
The DN Bit and the VPN Route Tag
For a PE it is necessary to know if a particular prefix has been learned from another PE
router, in order to avoid re-advertisement of it into BGP and cause a loop.
Two mechanisms are mainly used for loop prevention when OSPF is used as PE-CE protocol.
 theDN bit
 theVPN Route (or OSPF Domain) tag
By default, when a type 3, 5, 7 LSA is sent from a PE to a CE, the DN bit is set by the
PE.
Almost all Cisco software releases support the setting of DN bit only for Type-3
LSAs and they use a 32- bit VPN Route tag for Type-5/7 LSAs. The configuration
and inclusion of the VPN Route Tag is required by all implementations for backward
compatibility with older implementations that do not set the DN bit in type 5/7 LSAs.
If a PE router receives an LSA that contains the same VPN Route Tag as the locally
configured tag, then the
localPErouterknowsthatanotherPErouter(fromthesamedomain)
generatedthisrouteandtheLSAis ignored.
16bit ASNs
o VPN Route tag Format: 1101 000000000000 ASN_of_VPN_Backbone
32bit ASNs
o VPN Route tag must be defined manually
You can change this default value by using the "domain-tag" command within the OSPF
VRF process configuration.
IOS
router ospf 100 vrf VPN

When another PE receives from a CE router, a type 3, 5, 7 LSA with the DN bit set, the
prefix information
from that LSA is not used during the OSPF route calculation, which means that the prefix
doesn't get installed
into the PE's BGP table.
domain-tag 12345
IOS-XR
router ospf 100

vrf TEST
domain-tag 12345
In case of Multi-VRF (VRF-Lite), the router that is accepting the LSA with the DN bit is
actually a CE router with no BGP VPNv4 functionality, so there is no danger of redistributing
this prefix into BGP. In order to bypass this DN bit check, the following configuration can be
enabled.
IOS
router ospf 100 vrf VPN
capability vrf-lite
IOS-XR
router ospf 100

vrf VPN
disable-dn-bit-check
Verification
IOS
R1#sh ip ospf 100 database summary 10.7.7.7

OSPF Router with ID (10.1.3.1) (Process ID 100)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0 LS

age: 1196
Options: (No TOS-capability, DC, Downward)
LS Type: Summary Links(Network)
Link State ID: 10.7.7.7 (summary Network Number) Advertising

Router: 10.1.2.2
LS Seq Number: 80000005
Checksum: 0x2761
Length: 28
Network Mask: /32
MTID: 0 Metric: 2
R1#sh ip ospf 100 database external 7.7.7.7

Type-5 AS External Link States
130
Links
Routing Bit Set on this LSA in topology Base with MTID 0 LS

age: 1302
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 7.7.7.7 (External Network Number ) Advertising

Router: 10.1.2.2
LS Seq Number: 80000004
Checksum: 0x6DCF
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path) MTID: 0

Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 3489661028
IETF - RFC 4576 (the DN-bit)
OSPF Domain-ID
OSPF Domain-ID is an attribute that defines how (internal, external) the OSPF routes will be
transferred from one CE to another CE over their PEs BGP VPNv4 session.
On a PE, if the OSPF Domain-ID of the received BGP prefixes (encoded as extended
community) is the same as the OSPF Domain-ID of the local OSPF process, then:
 the MPLS core is treated like a SuperBackbone area (which is considered higher
than area 0)
 the PE is treated like an ABR (instead of an ASBR)
 internal routes are being redistributed as Type-3 LSAs (instead of Type-5)
OSPF Domain-ID needs to be changed on the PEs (where redistribution between BGP
and OSPF takes place), not on the CEs.
The "type" value can be different is some cases for backwards compatibility (like in
0005 vs 8005).
Detailed Steps
OSPF=>BGP redistribution on PE1
 ifthe OSPF Domain tag of the local OSPF process is the same as the VPN Route
tag of the prefix,
then that route isn't installed into BGP
 ifthe OSPF DN bit check is enabled in the local OSPF process and the OSPF route
has this bit set,
then that route isn't installed into BGP
 if the route is installed into BGP

IOS-XR uses a null Domain-ID by default, so this needs to be changed if the other PE is
running IOS
(which is encoding the OSPF process-id as domain-id).

o the Domain-ID of the local OSPF process is encoded into OSPF DOMAIN ID community
on the prefix
o the area and the LSA type of the OSPF prefix is encoded into OSPF RT community on the
prefix
o the Router-ID of the local OSPF process is encoded into OSPF ROUTER ID community
on the prefix
BGP=>OSPF redistribution on PE2

if the Domain-ID of the local OSPF process is the same as the OSPF DOMAIN ID
community of the
prefix, then that route is passed to the CE as internal else as external Configuration
IOS
router ospf 100

domain-id type
IOS-XR
router ospf 100

vrf VPN
vrf VPN
0005 value 000000440101
domain-id type 0005 value 000000440101
Verification
Youcanuse"sh ip ospf"toseetheDomain-IDofthelocalOSPFprocess.
Youcanuse"sh bgp vpn4 unicast"toseetheDomain-

IDencodedasextendedcommunityinthe BGP prefixes (OSPF RT is included too).
R2#sh ip ospf 100

Routing Process "ospf 100" with ID 10.1.2.2
Domain ID type 0x0005, value 0x000000440101
Start time: 00:13:37.092, Time elapsed: 00:36:17.144 Supports

only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability

Connected to MPLS VPN Superbackbone, VRF VPN
Event-log disabled
It is an area border and autonomous system boundary router
Redistributing External Routes from,
bgp 100, includes subnets in redistribution
R2#sh bgp vpnv4 unicast vrf VPN 1.1.1.1/32

BGP routing table entry for 100:1:1.1.1.1/32, version 2 Paths:
(1 available, best #1, table VPN)
Advertised to update-groups:
1 Local
10.1.2.1 from 0.0.0.0 (2.2.2.2)

Origin incomplete, metric 2, localpref 100, weight 32768,
valid,
sourced, best
Extended Community: RT:100:1 OSPF DOMAIN
ID:0x0005:0x000000440101
OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:10.1.2.2:0 mpls labels

in/out 28/nolabel
R2#sh ip ospf 100 database
...
Link ID
1.1.1.1
...
Summary Net Link States (Area 0)

ADV Router Age Seq# Checksum
10.1.1.1 980 0x80000002 0x00F336
LSA Type-3 (Summary) in local OSPF table is encoded as "OSPF RT:0.0.0.0:3:0" in local
BGP table.
Propagation of OSPF routes between CE1 and CE2
 same domain-id
o CE1O=>CE2IA
 different domain-id
o CE1O=>CE2E2
 sham-link (regardless of domain-id)
o CE1O=>CE2O
IOS
R6#sh ip route 1.1.1.1 Routing entry for 1.1.1.1/32
Known via "ospf 100", distance 110, metric 2
Tag Complete, Path Length == 1, AS 100, , type extern 2,

forward metric 1
Last update from 10.10.10.5 on POS4/0, 00:00:03 ago

Routing Descriptor Blocks:
* 10.10.10.5, from 10.10.10.5, 00:00:03 ago, via POS4/0
Route metric is 2, traffic share count is 1
Route tag 3489661028

Extra care needs to be taken if route tags are changed manually on OSPF=>BGP
redistribution, because
external OSPF routes are tagged by the BGP ASN when BGP=>OSPF redistribution takes
place, which means
that the original tag is lost (which could lead to a loop)
If a BGP VPNv4 route is redistributed into OSPF, then redistributed into another IGP like
RIP (where all the information (DN bit, VPN Route-Tag) needed to prevent looping is lost),
and then redistributed back into OSPF, then it is possible that it could be redistributed back
into BGP as a VPNv4 route, thereby causing a loop.
You can use route tags at every step of redistribution in order to avoid possible routing loops,
either caused by the above scenario or by mutual redistribution in two places.
Inter-AS MPLS L3VPN

Inter-AS MPLS L3VPN Options are defined in RFC 4364.
Inter-AS Options


Inter-AS Option A (Back-to-Back VRF)

o one logical/physical interface per VRF in the interconnection o one PE-CE eBGP/IGP
session per VRF between ASBRs
o IP traffic between ASBRs
o no need for common RDs/RTs between ASNs
o 2LSPsand1IPpathfromonePEtotheotherPE
Inter-AS Option B (MP-eBGP between ASBRs)

o one physical/logical interface for all VRFs in the interconnection o eBGP VPNv4 between
ASBRs
o MPLS traffic between ASBRs
o common RDs/RTs between ASNs (unless RT rewrite is used)
o next-hop-self on each ASBR for iBGP
3LSPsfromonePEtotheotherPE
o redistribute connected/static on each ASBR for the interconnection
2LSPsfromonePEtotheotherPE
filtertoredistributeonlythepeer'saddress o multihop (loopback) peering between ASBRs
 2LSPsfromonePEtotheotherPE
 staticroutesforpeer'sloopbackoneachASBR
 LDP between ASBRs
 MPLSstaticlabelbindingforpeer'sloopbackpointingtointerconnectiononeach
ASBR
Inter-AS Option C (Multihop MP-eBGP between RRs/PEs)

o o o o o o
o o o
one physical/logical interface for all VRFs in the interconnection labeled eBGP session
between ASBRs for next-hop exchange multihop eBGP VPNv4 session between RRs
MPLS traffic between ASBRs
common RDs/RTs between ASNs (unless RT rewrite is used) change next-hop on each
VPNv4 RR for the eBGP session (default)
2LSPsfromonePEtotheotherPE next-hop-unchanged on each VPNv4 RR for the eBGP

session
1LSPfromonePEtotheotherPE
eBGP session between ASBRs with directly connected interfaces
next-hop-selfoneachASBRfortheiBGPsessions multihop (loopback) eBGP session

between ASBRs with loopbacks

staticroutesforpeer'sloopbackoneachASBR
LDP between ASBRs
MPLSstaticlabelbindingforpeer'sloopbackpointingtointerconnectiononeach ASBR
135
The transport label changes whenever the next-hop changes.
Inter-AS Option A
ASBR-1
IOS
ip vrf VPN1
rd 1:100 route-target 1:100
!
ip vrf VPN2
rd 1:200
route-target 1:200 !
interface FastEthernet0/0 description ** Inter-AS NNI **
!
interface FastEthernet0/0.10
description ** Customer VPN1 ** encapsulation dot1q 10

ip vrf forwarding VPN1
ip address 10.10.10.1 255.255.255.0
!

ip address 20.20.20.1 255.255.255.0
!
router bgp 1
neighbor 1.1.1.1 remote-as 1

neighbor 1.1.1.1 update-source Loopback0 neighbor 1.1.1.1
description iBGP-VPNv4
!
address-family vpnv4
neighbor 1.1.1.1 activate

neighbor 1.1.1.1 send-community extended neighbor 1.1.1.1
next-hop-self
exit-address-family !
address-family ipv4 vrf VPN1 neighbor 10.10.10.2 remote-as 2

address-family ipv4 vrf VPN2

neighbor 20.20.20.2 activate exit-address-family
ASBR-2
IOS
ip vrf test1
rd 2:100 route-target 2:100
!
ip vrf test2
rd 2:200
route-target 2:200 !
interface FastEthernet0/0 description ** Inter-AS NNI **
!

ip address 10.10.10.2 255.255.255.0
!

ip address 20.20.20.2 255.255.255.0
!
router bgp 2

neighbor 2.2.2.2 update-source Loopback0 neighbor 2.2.2.2
description iBGP-VPNv4
!
neighbor 2.2.2.2 send-community extended neighbor 2.2.2.2
next-hop-self

neighbor 20.20.20.1 activate exit-address-family
Youcanalsouseadifferentrouter-idperVRF,usingthe"bgp router-id"undereachvrfaddress-
family.
Inter-AS Option B
ASBR-1
IOS
interface FastEthernet0/0 description ** Inter-AS NNI ** ip

address x.x.x.x
mpls bgp forwarding
!
router bgp 1
no bgp default route-target filter

neighbor PE-1 remote-as 1
neighbor PE-1 update-source Loopback0 neighbor PE-1
description MP-iBGP with PE-1 neighbor ASBR-2 remote-as 2
neighbor ASBR-2 description MP-eBGP with ASBR-2
no auto-summary !
neighbor PE-1 activate
neighbor PE-1 send-community extended neighbor PE-1 next-hop-
self
neighbor ASBR-2 activate
neighbor ASBR-2 send-community extended
exit-address-family
ASBR-2
IOS

address x.x.x.x
mpls bgp forwarding
!
router bgp 2
no bgp default route-target filter

neighbor PE-2 update-source Loopback0 neighbor PE-2
description MP-iBGP with PE-2
neighbor ASBR-1 remote-as 1
neighbor ASBR-1 description MP-eBGP with ASBR-1 !
neighbor PE-2 send-community extended neighbor PE-2 next-hop-
self
neighbor ASBR-1 activate
neighbor ASBR-1 send-community extended
exit-address-family
Inter-AS Option C
RR-1
IOS
router bgp 1
no synchronization
neighbor PE-1 update-source Loopback0
neighbor PE-1 description MP-iBGP with PE-1 neighbor ASBR-1
remote-as 1
neighbor ASBR-1 update-source Loopback0 neighbor ASBR-1
description MP-iBGP with ASBR-1 neighbor RR-2 remote-as 2
neighbor RR-2 ebgp-multihop 255
neighbor RR-2 update-source Loopback0
neighbor RR-2 description MP-eBGP with RR-2
no auto-summary
!

neighbor PE-1 send-community extended neighbor PE-1 route-
reflector-client neighbor ASBR-1 activate
neighbor ASBR-1 send-community extended neighbor ASBR-1 route-
reflector-client neighbor RR-2 activate
neighbor RR-2 send-community extended neighbor RR-2 next-hop-
unchanged exit-address-family
ASBR-1
IOS

address x.x.x.x
mpls bgp forwarding
!
route-map PE2-TO-IGP permit 10
match ip address PE-2 !
router IGP 100

redistribute bgp 1 route-map PE2-TO-IGP
!
router bgp 1
no synchronization
network PE-1 mask 255.255.255.255 !
neighbor RR-1 remote-as 1

neighbor RR-1 update-source Loopback0 neighbor RR-1
description MP-iBGP to RR-1 neighbor ASBR-2 remote-as 2
neighbor ASBR-2 send-label
νeighbor ASBR-2 description MP-eBGP to ASBR-2 no auto-summary
!
neighbor RR-1 activate
neighbor RR-1 send-community extended exit-address-family
ASBR-2
IOS

address x.x.x.x
mpls bgp forwarding
!
route-map PE1-TO-IGP permit 10
match ip address PE-1 !
router IGP 200

redistribute bgp 2 route-map PE1-TO-IGP
!
router bgp 2
network PE-2 mask 255.255.255.255 !

neighbor RR-2 remote-as 2

neighbor RR-2 update-source Loopback0 neighbor RR-2
description MP-iBGP to RR-2 neighbor ASBR-1 remote-as 1
neighbor ASBR-1 send-label
neighbor ASBR-1 description MP-eBGP to ASBR-1
!
neighbor RR-2 activate
neighbor RR-2 send-community extended exit-address-family
RR-2
IOS
router bgp 2
neighbor PE-2 update-source Loopback0
neighbor PE-2 description MP-iBGP with PE-2 neighbor ASBR-2
remote-as 2
neighbor ASBR-2 update-source Loopback0 neighbor ASBR-2
description MP-iBGP with ASBR-2 neighbor RR-1 remote-as 1
neighbor RR-1 ebgp-multihop 255
neighbor RR-1 update-source Loopback0
neighbor RR-1 description MP-eBGP with RR-1
!

neighbor PE-2 send-community extended neighbor PE-2 route-
reflector-client neighbor ASBR-2 activate
neighbor ASBR-2 send-community extended neighbor ASBR-2 route-
reflector-client neighbor RR-1 activate
neighbor RR-1 send-community extended neighbor RR-1 next-hop-
unchanged
exit-address-family
In IOS-XR, in order to send IPv4 prefixes with labels over a labeled BGP session, the IOS-
XR router must be the originator of the prefixes. On the other hand, an IOS router can send
labeled IPv4 prefixes over a labeled BGP session whether it's the originator or not of those
prefixes.
If an output route-map is applied on a labeled BGP session, then labels will be added only to
those prefixes
Generally, if a routerisadvertisingIPv4prefixeswithlabels,thenyoucanuseanoutputroute-
map(withthe"set mpls-
label" command) to specify which prefixes will be sent with a label.
InmostIOSsoftwarereleases,thecommand"mpls bgp
forwarding"isaddedautomaticallyunderthe eBGP peering interface when a VPNv4 or
labeled BGP session is configured between directly connected peers. If you use loopbacks for
peering, then you must manually configure it. Always verify its existence, together with the
interface's mpls operational state.
thathavethecommand"set mpls-label"undertherelevantstatementintheroute-map.
You need to disable the default RT filter from the ASBRs, unless they have all the VRFs
locally configured or
they are VPNv4 RRs.
IOS
R1#sh mpls int Interface FastEthernet0/0.13 FastEthernet0/0.30
IP Tunnel Yes (ldp) No

No No
BGP Static Operational No No Yes

Yes No Yes
Generally, Cisco software requires a /32 route for each next-hop that should be label
switched. In the Inter-AS B/C options,
in IOS-XR you must add manually a /32 static route for the peer address of the
interconnection
in order to create a label for that
labeled BGP session comes up.
IOS-XR
. IOS creates automatically a /32 connected route when the relevant VPNv4 or
router static
10.10.10.2/32 GigabitEthernet0/2/1/2
IOS
Dec 29 15:45:30.703: %BGP-5-ADJCHANGE: neighbor 10.10.10.2 Up

Dec 29 15:45:30.707: CONN: add connected route, idb:
FastEthernet0/0.30, addr: 10.10.10.2, mask: 255.255.255.255
Inter-AS scenarios emulated in GNS3 might sometimes cause very large delays in data
forwarding. Increase the ping/traceroute timeout in order to verify connectivity.
Static Label Bindings
In some cases you don't have the option of enabling LDP or having a VPNv4 or labeled BGP
session between directly connected peers, but you still need to have the label switching
functionality on their interconnection.
If you want to achieve load-sharing in a MPLS L3VPN environment with RRs, you can use a
different RD per
PE in combination with BGP multipath.

i.e. if you configure the following static route in order to reach peer's loopback: IOS
ip route 19.19.19.19 255.255.255.255 12.1.19.19
IOS
R1#sh mpls
Local
Label
24
forwarding-table 19.19.19.19 detail Outgoing Prefix Bytes

Label Label or Tunnel Id Switched
No Label 19.19.19.19/32 0
Outgoing interface
Fa0/0 12.1.19.19

CA02141C0008CA0417EC0000810000770800
then you need to also add a static (outgoing) label binding for that:
IOS
mpls static binding ipv4 19.19.19.19 255.255.255.255 output

12.1.19.19 implicit-null
Next Hop
IOS
R1#sh mpls static binding 19.19.19.19/32: Incoming label:

none;
Outgoing labels:
12.1.19.19 implicit-null
R1#sh mpls
Local
Label
24

Label Label or Tunnel Id Switched Pop Label 19.19.19.19/32 0
Outgoing interface
Fa0/0 12.1.19.19

CA02141C0008CA0417EC0000810000770800
At the same time, you must enable MPLS on this interface without using LDP:
Next Hop
IOS
R1#sh mpls int FastEthernet0/0 Interface IP
IOS
mpls bgp forwarding
IOS
R1#sh mpls int FastEthernet0/0
Tunnel
Tunnel No
BGP Static Operational
BGP Static Operational Yes No Yes
Interface FastEthernet0/0
IP No
143
Static Label Bindings per Interface
multiaccess interfaces
o next-hop ip address required o label required
point-to-point interfaces o interface required
The above differentiation per interface is applicable only on specific software releases. The
multiaccess interface is the common one.
If you must configure specific static labels, then you must first define the label range (which
will sometimes require a reload).
Implicit-null is used in the above example due to PHP (pop label) that must happen for the
directly connected peer.
Inter-AS L3VPN
If you want to follow a Inter-AS L3VPN path (assuming control-plane has been setup
correctly), then you can execute the following algorithm:
first router (start PE)

o Find the VPN label for the prefix
o Find the Transport label(s) for the prefix's next-hop
n router
o Follow the Transport top label swaps until there is a "Pop Label" for next router
n+1 router
o Find the local VPN label for the prefix
IfVPNlabelis"nolabel",then routeristheendPE
VPNislocallyattached If VPN label is other, then
routerisanRR/ASBR
findtheTransportlabel(s)fortheprefix'snewnext-hop goto"nrouter"
If VPN label doesn't exist, then

multipleTransportlabelsexist goto"nrouter"
If the route is learned from IGP, the Transport label must be allocated through LDP/RSVP. If
the route is learned from BGP, the Transport label must be allocated through BGP.
VPN label is 26
IOS
R6#sh mpls
Local
Label
None
forwarding-table 2.2.2.2 Outgoing Prefix

Label or Tunnel Id 23 2.2.2.2/32
detail
Bytes Label
Switched
0
Outgoing
interface
Fa0/0.46
Next Hop
20.4.6.4
Example R6(PE1)=>R4(P1)=>XR1(ASBR1)=>R1(ASBR2)=>R3(P2)=>R2(PE3) Start PE
IOS
R6#sh bgp vpnv4 unicast all 7.7.7.7/32

BGP routing table entry for 102:202:7.7.7.7/32, version 36
Paths: (1 available, best #1, table VPN_B)
Not advertised to any peer 100
2.2.2.2 (metric 20) from 20.20.20.20 (20.20.20.20)

Origin incomplete, metric 0, localpref 100, valid, internal,
best Extended Community: RT:102:202 0x8800:32768:0
0x8801:1:130560
0x8802:65281:25600 0x8803:65281:1500 0x8806:0:0 mpls labels

in/out nolabel/26
MAC/Encaps=18/26, MRU=1496,
CA0611100000CA0115B000008100002E8847 No output feature
configured
Transport label is 16/23, VPN label is 26
Label Stack{16 23} 0001000000017000
IOS
R4#sh mpls
Local
Label
16
20.4.19.19
forwarding-table labels 16 detail Outgoing Prefix Bytes Label
or Tunnel Id Switched Pop Label 19.19.19.19/32 18896
Next Hop

CA02141C0008CA0611100000810001A38847
Transport label is 23, VPN label is 26
IOS
XR1#sh mpls forwarding-table labels 23 detail Local Outgoing

Prefix Bytes Label
Outgoing
Next Hop
Label
Outgoing
interface
Fa0/0.419
145

Label Label or Tunnel Id Switched 23 20 2.2.2.2/32 22628
MAC/Encaps=18/22, MRU=1500, Label Stack{20}

CA0417EC0000CA02141C0008810000778847 00014000 No output
feature configured
interface
Fa0/0.119
12.1.19.1
IOS
R1#sh mpls
Local
Label
20
forwarding-table labels 20 detail
Outgoing Prefix Bytes Label Label or Tunnel Id Switched

19 2.2.2.2/32 24518
Outgoing
interface
Fa0/0.13
Next Hop
10.1.3.3

CA0711100000CA0417EC00008100000D8847 00013000 No output
feature configured
IOS
R3#sh mpls
Local
Label
19
Outgoing Prefix
Label or Tunnel Id Pop Label 2.2.2.2/32
Bytes Label
Switched
85693
Outgoing
interface
Fa0/0.23
Next Hop
10.2.3.2

CA0517EC0000CA0711100000810000178847
VPN label is 26
IOS
R2#sh bgp vpnv4 unicast all 7.7.7.7/32
Paths: (1 available, best #1, table VPN_B)
Advertised to update-groups: 1
Local
40.2.7.7 from 0.0.0.0 (2.2.2.2)
Origin incomplete, metric 156160, localpref 100, weight 32768,

valid, sourced, best
Extended Community: RT:102:202 Cost:pre-bestpath:128:156160

0x8800:32768:0 0x8801:1:130560 0x8802:65281:25600
0x8803:65281:1500 0x8806:0:0
mpls labels in/out 26/nolabel
End PE found
RT Rewrite
It is used mainly in Inter-AS topologies, when there is a need to keep different RTs between
the ASes. It allows the ASBR (or any other router that's involved) to replace the peer ASN's
RTs with their own.
Configuration Steps
 define the RTs to be replaced

 configure a route-map that matches the above RTs, deletes them and then adds the
new RTs
 apply the route-map to the bgp neighbor session
IOS
ip extcommunity-list 1 permit rt 200:1 ip extcommunity-

list 2 permit rt 200:2 !
route-map RT-REWRITE-ROUTEMAP permit 10
match extcommunity 1
set extcomm-list 1 delete
set extcommunity rt 100:1 additive continue 20
!
route-map RT-REWRITE-ROUTEMAP permit 20
match extcommunity 2
set extcomm-list 2 delete
set extcommunity rt 100:2 additive
!
route-map RT-REWRITE-ROUTEMAP permit 30 !
router bgp 100
neighbor 10.10.10.2 remote-as 200 !

address family vpnv4

neighbor 10.10.10.2 send-community extended
neighbor 10.10.10.2 route-map RT-REWRITE-ROUTEMAP in
Use the "additive" keyword when setting the new RT in order to not erase all
other extended communities.
Use the "continue" statement (in ingress route-maps) when you need to rewrite more than
one RTs in the
same prefix.
CsC
CsC (Carrier supporting Carrier) is defined in RFC 4364.
Control-Plane
 The Customer Carrier PEs run BGP VPNv4 in order to exchange VPN labels
 The Customer Carrier routers run IGP+LDP (or iBGP+Label) in order to exchange
all their internal
BGP next-hops and their labels
 The CsC-PEs and CsC-CEs run eBGP (or IGP) in order to exchange BGP next-hop
prefixes
 The CsC-PEs and CsC-CEs run eBGP+Label (or IGP+LDP) in order to exchange
labels for the BGP
next-hop prefixes
 The
Backbone Carrier routers run IGP+LDP in order to exchange all their internal
BGP next-hops and
their labels
The Backbone Carrier offers a MPLS VPN service to the Customer Carrier which in
turn offers a MPLS VPN or Internet service to its customers.
The Backbone Carrier doesn't need to know the final customer prefixes.
Using IGP+LDP in CsC is not as risky as with Inter-AS MPLS VPN Option 3
because:
 Customer Carrier internal routes are put into a specific VRF in the Backbone
Carrier
 No Backbone Carrier internal routes are distributed into the Customer Carrier
network
You can have multiple Backbone Carriers, using Inter-AS MPLS L3VPN for
interconnection.
By default a CsC-PE runs PHP towards the CsC-CE. If using an ipv4-labeled PE-CE
session, you can change
thisbehavior(inordertokeeptheQoSconsistentacrossproviders)byusingthe"neighbor
x.x.x.x send-label explicit-null"ontheCsC-CE.
CsC Load Balancing
Load balancing between CsC-PE and CsC-CE can be achieved with:

IOS-XR supports only the use of Labeled BGP as a PE-CE protocol in CsC topologies. LDP
(+IGP) is not
supported.


directly connected loopback peering for one pair of PE/CE

o one eBGP session between neighbors
o multiple static routes for each other's loopback
o mpls forwarding on all directly connected physical interfaces
eBGP multipath for multiple pairs of PEs/CEs
o maximum-paths under bgp & vrf address family on PE
148
omaximum-paths under bgp on CE

When using static routes, you also need to define the outgoing interface and the next-hop.
Configuration
BC = Backbone Carrier (AS10) CC = Customer Carrier (AS100) C = Customer (AS200)
Backbone Carrier runs IS-IS or OSPF with MPLS/LDP in its core
Backbone Carrier (CsC-PE1) runs OSPF+LDP with Customer Carrier (CsC-CE1) Backbone
Carrier (CsC-PE2) runs eBGP+Label with Customer Carrier (CsC-CE2)
Customer Site 1 (C-CE1) runs OSPF with Customer Carrier (CC-PE1) Customer Site 2 (C-
CE2) runs ISIS with Customer Carrier (CC-PE2)
CC-PE (Customer Carrier PE serving the final customer site) and CsC-CE (Carrier
supporting Carrier CE) functionalities can be collapsed into a single router.
CsC-PE1 and CsC-PE2 run iBGP VPNv4 in order to exchange Customer Carrier
prefixes/labels CsC-CE1 and CsC-CE2 run iBGP VPNv4 in order to exchange Customer
prefixes/labels
IGP+LDP between CsC-PE1 and CsC-CE1
CsC-PE1 (IOS)
! for connectivity to BC core (IGP+LDP)
mpls ldp router-id Loopback0 mpls label protocol ldp

!
interface Ethernet0/2
description ** Link to BC core ** ip address x.x.x.x

mpls ip
!
router isis/ospf x
!
! for connectivity to CsC-CE1 (OSPF+LDP) vrf definition CC-VPN
rd 10:X
"mpls bgp
forwarding"isnotautomaticallyadded,becausetheBGPsessionisnotbetweendirectly
connected neighbors. You have to add it yourself.

route-target 10:X !
address-family ipv4
description ** Link to CsC-CE1 ** vrf forwarding CC-VPN
ip address x.x.x.x
mpls ip
!
router ospf 10 vrf CC-VPN
redistribute bgp 10 subnets
network x.x.x.x area 0 !
! for connectivity to BC-PE2 (iBGP VPNv4)
router bgp 10
no bgp default ipv4-unicast
neighbor BC-PE2 remote-as 10
neighbor BC-PE2 update-source Loopback0 !
neighbor BC-PE2 activate
neighbor BC-PE2 send-community extended exit-address-family

!
address-family ipv4 vrf CC-VPN
redistribute ospf 10 vrf CC-VPN exit-address-family
CsC-CE1 (IOS)
! for connectivity to CsC-PE1 (OSPF+LDP)

!
description ** Link to CsC-PE1 ** ip address x.x.x.x

mpls ip
!
router ospf 10
network x.x.x.x area 0 !
CC-PE1 (IOS)
! for connectivity to C-CE1 (OSPF+VRF)
vrf definition C-VPN rd 100:Y
route-target 100:Y !
address-family ipv4 exit-address-family
!
description ** Link to C-CE1 ** vrf forwarding C-VPN

ip address y.y.y.y
!
router ospf 200 vrf C-VPN
redistribute bgp 100 subnets
network y.y.y.y area 0 !
! for connectivity to CC-PE2 (iBGP VPNv4)
router bgp 100

neighbor CC-PE2 remote-as 100
neighbor CC-PE2 update-source Loopback0 !
neighbor CC-PE2 activate
neighbor CC-PE2 send-community extended exit-address-family

!
address-family ipv4 vrf C-VPN
redistribute ospf 200 vrf C-VPN exit-address-family
BGP+Label between CsC-PE2 and CsC-CE2
CsC-PE2 (IOS-XR)
! for connectivity to BC core (IGP+LDP)

!
router isis/ospf x
!
mpls ldp
router-id x.x.x.x
interface x !
!forconnectivitytoCsC-CE2 (eBGP+Label)
vrf CC-VPN
import route-target 10:X

export route-target 10:X
!
interface GigabitEthernet0/2/1/1
description ** Link to CsC-CE2 ** vrf CC-VPN

ipv4 address x.x.x.x
!
router static
vrf CC-VPN
CsC-CE2/32 GigabitEthernet0/2/1/1 !
router bgp 10
address-family ipv4 unicast !
vrf CC-VPN
rd 10:X
network x.x.x.x
allocate-label all !
neighbor CsC-CE2
remote-as 100 address-family ipv4 unicast
route-policy PASS-RPL in route-policy PASS-RPL out as-override

send-extended-community-ebgp
!
address-family ipv4 labeled-unicast
route-policy PASS-RPL in route-policy PASS-RPL out as-override

send-extended-community-ebgp
!
route-policy PASS-RPL
pass
end-policy
!
! for connectivity to BC-PE1 (iBGP VPNv4) router bgp 10
address-family vpnv4 unicast !

neighbor BC-PE1
remote-as 10
update-source Loopback0 address-family vpnv4 unicast
CsC-CE2 (IOS)
!forconnectivitytoCsC-PE2 (eBGP+Label)
description ** Link to CsC-PE2 ** ip address x.x.x.x
mpls bgp forwarding
!
router bgp 100
no bgp default ipv4-unicast neighbor CsC-PE2 remote-as 10 !

address-family ipv4
neighbor CsC-PE2 activate

neighbor CsC-PE2 send-label exit-address-family
! for connectivity to C-CE2 (ISIS+VRF)
vrf definition C-VPN rd 100:Y route-target 100:Y !
address-family ipv4
interface Ethernet1/3 description ** Link to C-CE2 ** vrf

forwarding C-VPN
ip address y.y.y.y
ip router isis 200
!
router isis 200
vrf C-VPN redistribute bgp 100
! for connectivity to CC-PE1 (iBGP VPNv4)
router bgp 100

neighbor CC-PE1 remote-as 100
neighbor CC-PE1 update-source Loopback0 !
neighbor CC-PE1 activate
neighbor CC-PE1 send-community extended exit-address-family

!
address-family ipv4 vrf C-VPN
redistribute isis 200 exit-address-family
IOS-XR configuration is similar to IOS, with the major difference of using the labeled
unicast address-family instead of the send-label keyword.
Verification
 Customer Carrier PEs must have a BGP VPNv4 route and a label for the VPN
prefix
 Customer Carrier routers must have a label for the VPN prefix's next-hop
 CsC-PEs must have a BGP VPNv4 route and a label for the VPN prefix's next-hop
 Backbone Carrier routers must have a label for the next-hop of VPN prefix's next-
hop
Example
Assume the following network:
where
Then the following would happen for a VPN packet originating at R1 and terminating
at R10.
Don't forget to create a /32 static route for the CsC-PE/CE next-hop in IOS-XR when using
eBGP+Label.
Always verify the installation of labels for /32 next-hops.

R1-R2- R8-R9-
R4-R5-R6-R7-
R3- R10
Customer Carrier Network
Backbone Carrier Network
R1 (1.1.1.1) (Customer Carrier PE router) - vrf VPN o Transport label is 18, VPN label is
20
o next-hop is R10 (10.10.10.10)
R2 (2.2.2.2) (Customer Carrier P router)

o Transport label is 20, VPN label is 20 o next-hop is R10 (10.10.10.10)
R3 (3.3.3.3) (CsC-CE)

R4 (4.4.4.4) (CsC-PE) - vrf CSC

o Transport label is 16/21, VPN label is 20 o next-hop is R7 (7.7.7.7)
R5 (5.5.5.5) Backbone Carrier P router)

o Transport label is 16/21, VPN label is 20 o next-hop is R7 (7.7.7.7)
R6 (6.6.6.6) (Backbone Carrier P router)

R7 (7.7.7.7) (CsC-PE) - vrf CSC 154
o Transport label is 18, VPN label is 20
o next-hop is R10 (10.10.10.10) R8 (8.8.8.8) (CsC-CE)
o Transport label is 17, VPN label is 20
o next-hop is R10 (10.10.10.10)

R9 (9.9.9.9) (Customer Carrier P router)
o Transport label is removed, VPN label is 20
o next-hop is R10 (10.10.10.10)

R10 (10.10.10.10) (Customer Carrier PE router) - vrf VPN
o VPN label is removed, destination reached in next-hop R1#trace vrf VPN

99.99.99.99
Type escape sequence to abort. Tracing the route to
99.99.99.99
1 20.1.2.2 [MPLS: Labels 18/20 Exp 0] 10 msec 10 msec 8 msec
4 20.4.5.5 [MPLS: Labels 16/21/20 Exp 0] 7 msec 7 msec 8 msec
5 20.5.6.6 [MPLS: Labels 16/21/20 Exp 0] 6 msec 5 msec 5 msec
9 20.9.10.10 [MPLS: Label 20 Exp 0] 1 msec 1 msec 1 msec
10 30.10.10.99 1 msec 2 msec 2 msec
Verification in every hop
Customer Carrier PE router
R1#sh ip route vrf VPN 99.99.99.99
Routing Table: VPN

Routing entry for 99.99.99.99/32
Known via "bgp 100", distance 200, metric 1, type internal

Redistributing via rip
Advertised by rip metric transparent
Last update from 10.10.10.10 00:56:37 ago
Routing Descriptor Blocks:

* 10.10.10.10 (default), from 10.10.10.10, 00:56:37 ago
Route metric is 1, traffic share count is 1 AS Hops 0

MPLS label: 20
MPLS Flags: MPLS Required
R1#sh bgp vpnv4 unicast vrf VPN 99.99.99.99/32


Paths: (1 available, best #1, table VPN)
Not advertised to any peer Local
10.10.10.10 (metric 20) from 10.10.10.10 (10.10.10.10)

best Extended Community: RT:100:1
mpls labels in/out nolabel/20
VPN label is 20
R1#sh mpls
Local
Label
23
forwarding-table 10.10.10.10 detail

Outgoing Label
18
Prefix Bytes Label or Tunnel Id Switched 10.10.10.10/32 0
Outgoing
interface
Fa0/0.12 20.1.2.2

CA0113DC0000CA03079400088100026C8847 00012000 No output
feature configured
R1#sh ip cef vrf VPN 99.99.99.99 det99.99.99.99/32, epoch 0,

flags rib defined all labels
recursive via 10.10.10.10 label 20

From here you have 2 options:
 follow the next-hops

 follow the labels (i prefer this one)
Following the next-hops
Customer Carrier P router
Next Hop
R2#sh mpls
Local
Label
18
Outgoing Label
20
Outgoing
interface
Fa0/0.23 20.2.3.3

CA0610240000CA0113DC00008100002E8847 00014000 No output
feature configured
Next Hop
CsC-CE
R3#sh mpls
Local
Label
20
Outgoing Label
26
Outgoing Next Hop interface

Fa0/0.34 20.3.4.4

CA0207940008CA0610240000810001A38847 0001A000 No output
feature configured
CsC-PE
R4#sh mpls
Local
Label
26
forwarding-table vrf CSC 10.10.10.10 detail
Outgoing Label
21
Prefix Bytes Label or Tunnel Id Switched
10.10.10.10/32[V]16033
Outgoing
interface
Fa0/0.45 20.4.5.5
MAC/Encaps=18/26, MRU=1496, Label Stack{16 21}

C20911080000CA0207940008810003338847 0001000000015000 VPN
route: CSC
2 Transport labels are used (use "detail" to see them)
R4#sh bgp vpnv4 unicast vrf CSC 10.10.10.10

Paths: (1 available, best #1, table CSC)
100
7.7.7.7 (metric 4) from 7.7.7.7 (7.7.7.7)

mpls labels in/out 26/21
VPN label (21) for Backbone Carrier is actually Transport label (21) for Customer Carrier
Next Hop
R4#sh mpls
Local
Label
16
Outgoing Label
16
Prefix
or Tunnel Id
7.7.7.7/32
Bytes Label
Switched
0
Outgoing
interface
Fa0/0.45 20.4.5.5

C20911080000CA0207940008810003338847 00010000 No output
feature configured
Backbone Carrier P router
Next Hop

Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag 16
tag or VC or Tunnel Id switched interface

16 7.7.7.7/32 44218 Fa0/0.56 20.5.6.6
MAC/Encaps=18/22, MRU=1500, Tag Stack{16}

C20811080000C209110800008100004E8847 00010000 No output
feature configured

Per-packet load-sharing
Local Outgoing Prefix
Bytes tag
switched
42398

Fa0/0.67 20.6.7.7
tag 16
tag or VC or Tunnel Id Pop tag 7.7.7.7/32
MAC/Encaps=18/18, MRU=1504, Tag Stack{}

CA0415180000C20811080000810000118847
Per-packet load-sharing

CsC-PE
R7#sh mpls
Local
Label
21
forwarding-table vrf CSC 10.10.10.10
detail
CsC-CE
R8#sh mpls
Local
Label
18
Outgoing Prefix Bytes Label Label or Tunnel Id Switched

18 10.10.10.10/32[V]24156
Outgoing
interface
Fa0/0.78
Next Hop
20.7.8.8

CA0710240000CA04151800008100000D8847 00012000 VPN route: CSC

Outgoing Label
17
Outgoing
interface
Fa0/0.89
Outgoing
interface
Fa0/0.910
Next Hop
20.8.9.9
Next Hop

CA0013DC0000CA0710240000810000238847 00011000 No output
feature configured

R9#sh mpls
Local
Label
17
20.9.10.10

Label Label or Tunnel Id Switched Pop Label 10.10.10.10/32
23892
158

CA0515180000CA0013DC0000810000198847
Transport label is removed, VPN label is 20
R10#sh mpls forwarding-table vrf VPN 99.99.99.99 detail

Local
Label
20
30.10.10.99
Outgoing Label
No Label
Prefix Bytes Label or Tunnel Id Switched 99.99.99.99/32[V]1770
Outgoing
interface
Fa0/0.1010
Next Hop

C20A0F840000CA05151800008100001D0800
VPN route: VPN
VPN label is removed, destination reached
Following the labels

R2#sh mpls
Local
Label
18
Outgoing Label
20
Outgoing
interface
Fa0/0.23
Next Hop
20.4.6.4
CA0610240000CA0113DC00008100002E8847 No output feature

configured
CsC-CE
00014000
forwarding-table labels 20 detail Outgoing Prefix Bytes
R3#sh mpls
Local
Label Label or Tunnel Id Switched 20 26 10.10.10.10/32 15338
20.4.19.19
Outgoing
interface
Fa0/0.34
Next Hop

CA0207940008CA0610240000810001A38847 0001A000 No output
feature configured
CsC-PE
Label
R4#sh mpls
Local
Label
26
Outgoing Label
21
10.10.10.10/32[V]16645

Fa0/0.45 20.4.5.5
MAC/Encaps=18/26, MRU=1496, Label Stack{16 21}

C20911080000CA0207940008810003338847 0001000000015000 VPN
route: CSC
2 Transport labels are used (use "detail" to see them)
R5#sh mpls forwarding-table labels 16 detail
Bytes tag Outgoing Next Hop switched interface
20.5.6.6
tag 16
tag or VC or Tunnel Id 16 7.7.7.7/32
30421 Fa0/0.56 MAC/Encaps=18/22, MRU=1500, Tag Stack{16}
C20811080000C209110800008100004E8847 00010000
No output feature configured Per-packet load-sharing
Bytes tag Outgoing Next Hop
tag 16
tag or VC or Tunnel Id Pop tag 7.7.7.7/32
switched
interface
Fa0/0.67
29337 MAC/Encaps=18/18, MRU=1504, Tag Stack{}
20.6.7.7
CA0415180000C20811080000810000118847
No output feature configured Per-packet load-sharing

CsC-PE
R7#sh mpls
Local
Label
21
Outgoing Label
18

10.10.10.10/32[V]17260
Outgoing
interface
Fa0/0.78 20.7.8.8

CA0710240000CA04151800008100000D8847 00012000 VPN route: CSC
Next Hop
CsC-CE
R8#sh mpls
Local
Label
18
Outgoing Label
17
Outgoing
interface
Fa0/0.89
Outgoing
interface
Fa0/0.910
Next Hop
20.8.9.9
Next Hop
CA0013DC0000CA0710240000810000238847 00011000 No output
feature configured
R9#sh mpls
Local
Label
17
20.9.10.10

Label or Tunnel Id Switched Pop Label 10.10.10.10/32 17200

CA0515180000CA0013DC0000810000198847
Transport label is removed, VPN label is 20

Local
Label
20
30.10.10.99
Outgoing Label
No Label
Prefix Bytes Label or Tunnel Id Switched 99.99.99.99/32[V]1770
Outgoing
interface
Fa0/0.1010
Next Hop

C20A0F840000CA05151800008100001D0800
VPN route: VPN
VPN label is removed, destination reached

161
6PE/6VPE
6PE is defined in RFC 4798. 6VPE is defined in RFC 4659.
6PE
o customer's IPv6 prefixes are inside the global routing table
o IPv6 labels/prefixes are exchanged using Labeled IPv6 over IPv4 iBGP between the PEs
6VPE
o customer's IPv6 prefixes are inside a VRF
o IPv6 labels/prefixes are exchanged using VPNv6 over IPv4 iBGP between the PEs
6PE
6PE is a technology that allows IPv6 customers to communicate with each other over an IPv4
MPLS Provider without any tunnel setup, by having the customer IPv6 prefixes using a IPv4-
mapped IPv6 address as next-hop inside the Provider's network and using IPv4 LSPs between
the 6PEs.
In 6PE, labels must be exchanged between the 6PEs for their IPv6 prefixes, which means that
a labeled IPv4 iBGP session must be activated under the IPv6 address family (in IOS) or the
labeled IPv6 capability must be activated for the IPv4 peer 6PE (in IOS-XR).
IOS
router bgp 100

neighbor 6PE-IPv4 remote-as 100
neighbor 6PE-IPv4 update-source Loopback0 neighbor CE-IPv6
remote-as X
IOS-XR
router bgp 100
address-family ipv6 unicast allocate-label all
!
neighbor 6PE-IPv4
remote-as 100
update-source Loopback0 address-family ipv6 labeled-unicast
address-family ipv6
neighbor 6PE-IPv4 activate
neighbor 6PE-IPv4 send-label
neighbor CE-IPv6 activate

!
neighbor CE-IPv6
remote-as X
The 6PE routers are dual-stack: IPv6 towards the CE and IPv4 towards the MPLS core.
You don't need to set the "next-hop-self" in the labeled IPv4 iBGP session for the IPv6
prefixes, because that happens automatically while creating the IPv4-mapped IPv6 address.
MP_REACH_NLRI attribute
 AFI = 2 (IPv6)
 SAFI= 4 (labels)
 Prefix =X:X:X:X::X
 Label = X
 next-hop = ::FFFF:IPv4-ADDRESS
The IPv4 address which is encoded into the next-hop must be present in the IPv4
routing table and a LSP must exist to this destination. If the above conditions are not
both met, the IPv6 prefix is declared inaccessible.
R5#sh bgp ipv6 unicast 2001::1:1:1:1/128

BGP routing table entry for 2001::1:1:1:1/128, version 4
Paths: (1 available, no best path)
Not advertised to any peer 1
::FFFF:2.2.2.2 (inaccessible) from 2.2.2.2 (2.2.2.2)

Origin IGP, metric 0, localpref 100, valid, internal
If a 6PE receives unlabeled IPv6 prefixes, then the 6PE marks these prefixes as
unreachable in the IPv6 routing table, so that packets to this destination get dropped
and not sent into MPLS core.
If RRs are to be used for 6PE connectivity, then they also must have labeled BGP
enabled.
Control Plane
 CEs and 6PEs run eBGP (or IGP) in order to exchange IPv6 prefixes
 6PEs run iBGP+Label in order to exchange labels and IPv6 prefixes
 Provider routers run IGP+LDP in order to exchange all their internal BGP IPv4
next-hops and their
labels
6PE Example
R1 R
R2-R3-R4-R5-
- 6
where
(with 6PE routers and IPv4 routers)

Then the following would happen for an IPv6 packet originating at R1 and terminating at R6.
R1 (IPv6)
o next-hop is R2 (IPv6 link-local)
R2 (IPv4/IPv6 6PE)

o next-hop is R5 (IPv4 loopback)
o Transport label is 26, IPv6 label is 28
R3 (IPv4)
o Transport label is 25, IPv6 label is 28
R4 (IPv4)
o Transport label is removed, IPv6 label is 28
R5 (IPv4/IPv6 6PE)

o IPv6 label is removed, IPv6 destination reached in next-hop
R6 (IPv6)
o IPv6 destination reached
The IPv6 label in 6PE can be considered like the VPN label in MPLS VPN.
The customer routers could be IPv4/IPv6, having IPv4 traffic being forwarded as usual and
IPv6 traffic over 6PE.
Use extended traceroute if you want to source from an IPv6 address.
R1#trace
Protocol [ip]: ipv6
Target IPv6 address: 2001::6:6:6:6 Source address:
2001::1:1:1:1
...
Tracing the route to 2001::6:6:6:6
IPv6 Customer
6PE Provider
1 2001:10:1:2::2 44 msec 72 msec 32 msec
2 ::FFFF:10.2.3.3 [MPLS: Labels 26/28 Exp 0] 1 msec 1 msec 1

msec

msec
4 2001:10:5:6::5[MPLS: Label 28 Exp 0] 1 msec 1 msec 1 msec
5 2001:10:5:6::6 1 msec 1 msec 1 msec
Although all traceroute answers are given by the closest interface to the source ip, in some
software releases in the last 6PE router the traceroute answer is given by the IPv6 address on
the PE-CE link.
Youcanuse"no mpls ip propagate-ttl"onthefirst-

hop6PEifyouwanttohidethe::FFFF:IPv4
hops.
1 2001:10:1:2::2 44 msec 72 msec 32 msec
2 2001:10:5:6::5[MPLS: Label 28 Exp 0] 1 msec 1 msec 1 msec

3 2001:10:5:6::6 1 msec 1 msec 1 msec
Customer IPv6 router
R1#sh ipv6 route 2001::6:6:6:6 Routing entry for

2001::6:6:6:6/128
Known via "bgp 1", distance 20, metric 0, type external Route
count is 1/1, share count 0
Routing paths:
FE80::C805:17FF:FEC8:1C, FastEthernet0/0 MPLS label: nolabel

Last updated 00:31:05 ago
Provider 6PE router

Paths: (1 available, best #1, table default)
20
::FFFF:5.5.5.5(metric 4) from 5.5.5.5(5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best

IOS-XR doesn't display the "::FFFF:" in front of the IPv4 next-hop (How Multi is MP-BGP
in IOS-XR - Part #2).
IPv6 label is 28
R2#sh mpls
Local
Label
27
Outgoing Label
26
Prefix
or Tunnel Id
5.5.5.5/32
Bytes Label
Switched
0

Fa0/0.23 10.2.3.3

CA071AC40000CA0517C80000810000178847 0001A000 No output
feature configured
165
Transport label is 26
R2#sh ipv6 cef 2001::6:6:6:6/128 detail 2001::6:6:6:6/128,

epoch 0, flags rib defined all labels

Transport label is 26, IPv6 label is 28
You can follow the next-hop or the labels (like in CsC), but let's follow the next-hop on this
example.
Provider IPv4 Router

R3#sh mpls
Local
Label
26
forwarding-table 5.5.5.5 detail Outgoing Prefix Bytes Label

Label or Tunnel Id Switched
25 5.5.5.5/32 16342
Outgoing
interface
Fa0/0.34
Next Hop
10.3.4.4

CA0113200000CA071AC40000810000248847 00019000 No output
feature configured
Transport label is 25, IPv6 label is 28
R4#sh mpls
Local
Label
25
Outgoing Prefix
Bytes Label
Switched
16125
Outgoing interface Fa0/0.45 10.4.5.5

CA0214D00008CA01132000008100026B8847
Transport label is removed, IPv6 label is 28
Provider 6PE router
Outgoing Label
No Label
Prefix Bytes Label or Tunnel Id Switched 2001::6:6:6:6/128 \
2244
Outgoing
interface
PO2/0
Next Hop
point2point
MAC/Encaps=4/4, MRU=4474, Label Stack{} 0F0086DD
Next Hop
R5#sh mpls
Local
Label
28
forwarding-table 2001::6:6:6:6/128 detail
166

Paths: (1 available, best #1, table default)
20
2001:10:5:6::6 (FE80::C803:14FF:FED0:8) from 2001:10:5:6::6
(6.6.6.6)
Origin IGP, metric 0, localpref 100, valid, external, best

R5#sh bgp ipv6 unicast labels

Network Next Hop In label/Out label 2001::6:6:6:6/128
2001:10:5:6::6
R5#sh ipv6 route 2001::6:6:6:6/128 Routing entry for

2001::6:6:6:6/128
28/nolabel
Known via "bgp 100", distance 20, metric 0, type external

Route count is 1/1, share count 0
Routing paths:
FE80::C803:14FF:FED0:8, POS2/0
MPLS label: nolabel
IPv6 label is removed, IPv6 destination reached in next-hop
6VPE
6VPE is a technology that allows IPv6 VPN customers to communicate with each other over
an IPv4 MPLS Provider without any tunnel setup, by having the customer VPNv6 prefixes
using a v4-mapped IPv6 address as next-hop inside the provider's network and using IPv4
LSPs between the 6VPEs.
In 6VPE, labels must be exchanged between the 6VPEs for their VPNv6 prefixes, which
means that the VPNv6 address-family must be activated on the IPv4 iBGP session between
the 6VPEs.
IOS
router bgp 100

neighbor 6VPE-IPv4 remote-as 100
neighbor 6VPE-IPv4 update-source Loopback0 !
neighbor 6VPE-IPv4 activate
neighbor 6VPE-IPv4 send-community extended exit-address-family

!
neighbor CE-IPv6 remote-as X
neighbor CE-IPv6 activate exit-address-family
IOS-XR
router bgp 100
address-family vpnv6 unicast
neighbor 6VPE-IPv4
remote-as 100
update-source Loopback0 address-family vpnv6 unicast !
vrf VPN
rd 100:1
address-family ipv6 unicast !
neighbor CE-IPv6
remote-as x
The 6VPE routers are dual-stack: IPv6 towards the CE (inside a VRF) and IPv4 towards the
MPLS core. MP_REACH_NLRI attribute
 AFI = 2 (IPv6)
 SAFI= 128 (.)
 Prefix =X:X:X:X::X
 Label = X
 next-hop = ::FFFF:IPv4-ADDRESS
The IPv4 address which is encoded into the next-hop must be present in the IPv4
routing table and a LSP must exist to this destination. If the above conditions are not
both met, the IPv6 prefix is declared inaccessible.
If RRs are to be used for 6VPE connectivity, then they also must have the VPNv6
address-family enabled.
Control Plane
 CEs and 6VPEs run eBGP (or IGP) in order to exchange IPv6 prefixes
 6VPEs run VPNv6 iBGP in order to exchange labels and VPNv6 prefixes
 Provider routers run IGP+LDP in order to exchange all their internal BGP IPv4
next-hops and their
labels
In IOS, if you enable the VPNv6 address-family on an existing VPNv4 peering, you might
need to reset the
whole BGP session for VPNv6 to come up.

6VPE Example
where
(with 6VPE routers and IPv4 routers)

Then the following would happen for an IPv6 packet originating at R1 and terminating at R6.
R1 (IPv6)
R2 (IPv4/IPv6 6VPE)

o Transport label is 18, VPNv6 label is 28
R3 (IPv4)
o Transport label is 25, VPNv6 label is 28
R4 (IPv4)
o Transport label is removed, VPNv6 label is 28
R5 (IPv4/IPv6 6VPE)

o VPNv6 label is removed, IPv6 destination reached in next-hop
R6 (IPv6)
o IPv6 destination reached
Use extended traceroute if you want to source from a specific IPv6 address.
R1#trace 2001:6:6:6::6
Type escape sequence to abort.
Tracing the route to 2001:6:6:6::6
Although all traceroute answers are given by the closest interface to the source ip, in some
software releases in the last 6VPE router the traceroute answer is given by the IPv6 address
on the PE-CE link.
R1 R
R2-R3-R4-R5-
- 6
IPv6 VPN Customer
6VPE Provider
1 2001:10:1:2::2 1 msec 1 msec 1 msec

msec

msec
4 2001:10:5:6::5 [AS 100] [MPLS: Label 28 Exp 0] 1 msec 1 msec

1 msec
5 2001:10:5:6::6 [AS 100] 1 msec 1 msec 1 msec
Youcanuse"no mpls ip propagate-ttl"onthefirst-

hop6VPEifyouwanttohidethe::FFFF:IPv4
hops.
1 2001:10:1:2::2 1 msec 1 msec 1 msec
2 2001:10:5:6::5 [AS 100] [MPLS: Label 28 Exp 0] 1 msec 1 msec

1 msec
3 2001:10:5:6::6 [AS 100] 1 msec 1 msec 1 msec
Customer IPv6 router
R1#sh ipv6 route 2001::6:6:6:6 Routing entry for

2001::6:6:6:6/128
Known via "bgp 1", distance 20, metric 0, type external Route
count is 1/1, share count 0
Routing paths:
FE80::C805:EFF:FE2C:1C, FastEthernet0/0 MPLS label: nolabel

Provider 6VPE router
R2#sh bgp vpnv6 unicast vrf VPN 2001::6:6:6:6/128

BGP routing table entry for [100:1]2001::6:6:6:6/128, version
6 Paths: (1 available, best #1, table VPN)
1
::FFFF:5.5.5.5 (metric 4) from 5.5.5.5 (5.5.5.5)

IOS-XR doesn't display the "::FFFF:" in front of the IPv4 next-hop (How Multi is MP-BGP
in IOS-XR - Part #2).
VPNv6 label is 28
R2#sh mpls
Local
Label
19
Outgoing Label
18
Prefix
or Tunnel Id
5.5.5.5/32
Bytes Label
Switched
0
Fa0/0.23 10.2.3.3

CA070D4C0000CA050E2C0000810000178847 00012000 No output
feature configured
Transport label is 18
R2#sh ipv6 cef vrf VPN 2001::6:6:6:6 detail 2001::6:6:6:6/128,

epoch 0, flags rib defined all labels
R3#sh mpls
Local
Label
18

Label or Tunnel Id Switched
25 5.5.5.5/32 45876
Outgoing
interface
Fa0/0.34
Next Hop
10.3.4.4

Transport label is 18, VPNv6 label is 28
You can follow the next-hop or the labels (like in CsC), but for easiness let's follow the labels
this time.
CA0119D80000CA070D4C0000810000248847 No output feature

configured
Transport label is 25, VPNv6 label is 28

R4#sh mpls
Local
Label
25
00019000
Bytes
Switched
45343
Outgoing Prefix
Label
Outgoing
interface
Fa0/0.45
Next Hop
10.4.5.5

CA0217AC0008CA0119D800008100026B8847
Transport label is removed, VPNv6 label is 28
Provider 6VPE router

R5#sh mpls
Local
Label
28
Outgoing Label
No Label

2001::6:6:6:6/128[V] \
2820
Outgoing
interface
PO2/0
Next Hop
point2point
MAC/Encaps=4/4, MRU=4474, Label Stack{} 0F0086DD
VPN route: VPN
R5#sh bgp vpnv6 unicast vrf A 2001::6:6:6:6/128

BGP routing table entry for [100:1]2001::6:6:6:6/128, version
6 Paths: (1 available, best #1, table VPN)

1
2001:10:5:6::6 (FE80::C803:17FF:FEAC:8) from 2001:10:5:6::6
(6.6.6.6)
Origin incomplete, metric 0, localpref 100, valid, external,

Use prefix/size to verify when doing bgp lookups.
R5#sh ipv6 route vrf VPN 2001::20:20:20:20/128 Routing entry

for 2001::6:6:6:6/128
Known via "bgp 100", distance 20, metric 0, type external

Route count is 1/1, share count 0
Routing paths:
FE80::C803:17FF:FEAC:8, POS2/0
MPLS label: nolabel
VPNv6 label is removed, IPv6 destination reached in next-hop
IPv6 prefixes over an IPv4 PE-CE BGP session
Usually when doing 6PE or 6VPE, the BGP session between the PE and the CE (which is
used for exchanging the IPv6 prefixes) is IPv6 based.
Otherwise you might have the control plane showing everything is fine, but most probably
data plane won't work.
IOS
R2#sh bgp vpnv6 unicast all

BGP table version is 1, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, >
best, i - internal,
If you want to exchange IPv6 prefixes over an IPv4 PE-CE BGP session, then you must
change the IPv6
next-hop in the PEs in both directions (and then reset the session)
r RIB-failure, S Stale, m multipath, b backup-path, x best-

Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path Route

Distinguisher: 26:65001 (default for vrf VPN)
* 2001:10:2:8::/64 ::FFFF:10.2.8.8 0 0 65001 i
R2#sh bgp vpnv6 unicast all 2001:10:2:8::/64

BGP routing table entry for [26:65001]2001:10:2:8::/64,
version 0
external
Paths: (1 available, no best path) Not advertised to any peer

65001
::FFFF:10.2.8.8 (inaccessible) from 10.2.8.8 (10.8.8.8) Origin

IGP, metric 0, localpref 100, valid, external Extended
Community: RT:26:65001
IOS
router bgp X
neighbor CE-IPv4 route-map SET-IPV6NH-IN-ROUTEMAP in
neighbor CE-IPv4 route-map SET-IPV6NH-OUT-ROUTEMAP out exit-

address-family
!
route-map SET-IPV6NH-IN-ROUTEMAP permit 10
set ipv6 next-hop CE-IPv6 !

route-map SET-IPV6NH-OUT-ROUTEMAP permit 10 set ipv6 next-hop
PE-IPv6
In general:
 PE=>CE (out)
o set ipv6 next-hop PE-IPv6
 PE<=CE (in)
o set ipv6 next-hop CE-IPv6
After applying the route-map and resetting the session:
IOS
R2#sh bgp vpnv6 unicast all 2001:10:2:8::/64

BGP routing table entry for [26:65001]2001:10:2:8::/64,
version 14 Paths: (1 available, best #1, table VPN)
65001
2001:10:2:8::8 from 10.2.8.8 (10.8.8.8)
Origin IGP, metric 0, localpref 100, valid, external,

The default order of IPv6 next-hop operation is the following:

use the IPv6 address defined in the route-map of the session
use the IPv6 address used for peering (directly connected interface or loopback)
In IOS-XR, you won't even get an IPv4 BGP session up, if there are no IPv6 addresses
configured on the PE-
CE connection.

use an
IPv4-mapped IPv6 address
"no bgp default ipv6-nexthop"isalsoanoption.
and you'll be getting messages "DENIED due to: non-connected MP_REACH

NEXTHOP"(enable"debug bgp ipv6 unicast
updates" to see these). This is probably a bug, since the next-hop (PE) is actually
connected to the CE router.
Acorrectoutputof"sh bgp vpnv6 unicast"fromaPEwillinclude:
IPv6 routes from the directly connected CE

o The next hop shown must be the directly connected CE IPv6 address (i.e. 2001:10:2:8::8)
IPv6 routes from other PEs

o The next hop shown must be the remote PE IPv4 address (in v4-mapped IPv6 address
format
Also, sometimes in the CE you must enable ebgp-multihop for the PE session (2 hops at
least), otherwise
the remote IPv6 routes won't be installed in the CE's BGP table
Example:
IOS
like.::FFFF:1.1.1.1 in IOS, or just 1.1.1.1 in IOS-XR)
R2#sh bgp vpnv6 unicast all

BGP table version is 23, local router ID is 2.2.2.2
best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-

Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric Route Distinguisher: 26:65001 (default

for vrf X) *>i2001:10:1:7::/64 ::FFFF:1.1.1.1 0
*> 2001:10:2:8::/64 2001:10:2:8::8 0
IOS-XR
external
LocPrf Weight Path
100
0 65001 i
0 65001 i
GSR#sh bgp vpnv6 unicast

BGP router identifier 19.19.19.19, local AS number 26
...
best
i - internal, r RIB-failure, S stale Origin codes: i - IGP, e

- EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 26:65001 (default for vrf

*>i2001:10:1:7::/64 1.1.1.1
*> 2001:10:20:20::/64 2001:10:19:20::20
VPN)
0 100 065001i
65001 i
174
When doing the opposite and trying to exchange IPv4 prefixes over an IPv6 BGP session,
you have to set
manually the IPv4 next-hop

IOS-XR requires to enable the VPNv6 address-family before enabling the IPv6 address-
family under a VRF.
Hints
Before
R2#sh bgp ipv6 unicast 2001:10:1:7::/64

BGP routing table entry for 2001:10:1:7::/64, version 0 Paths:
(1 available, no best path)
Not advertised to any peer 26 26
2001:10:19:20::19 (FE80::C802:15FF:FE18:8) (inaccessible) from

10.19.20.19 (19.19.19.19)
Origin IGP, localpref 100, valid, external
After
R2#sh bgp ipv6 unicast 2001:10:1:7::/64

BGP routing table entry for 2001:10:1:7::/64, version 6 Paths:
(1 available, best #1, table default)
Not advertised to any peer 26 26
2001:10:19:20::19 from 10.19.20.19 (19.19.19.19) Origin IGP,

localpref 100, valid, external, best
This is probably another bug.

If you get issues with IPv6 next-hops being inaccessible when they point to eBGP interfaces
(while they
shouldn't), try to shut/no shut the interface.

AToM/L2VPN/VPLS
PW (PseudoWire) architecture is described in RFC 3985.
LDP for PWs is defined in RFC 4447.
EoMPLS (Ethernet over MPLS) is defined in RFC 4448.
L2TPv3 (Layer 2 Tunneling Protocol v3) is defined in RFC 3931.
L2VPN
AToM
o requires MPLS connectivity from end to end o source ip address is the one used for LDP
L2TPv3
o requires IP connectivity from end to end o source ip address is configured manually
L2TPv3
L2TPv3 is protocol 115. Supported protocols over L2TPv3
 Frame-Relay
 Ethernet
 VLAN
 HDLC
 PPP
 IPv6
The L2TPv3 keepalive mechanism consists of an exchange of L2TP hello messages.
The interface keepalive feature is automatically disabled on the interface to which

xconnect is applied, except for Frame-Relay encapsulation.
The IP local interface must be a loopback interface.

If you are transferring Vlans and STP packets over the L2VPN connection, then you might
need to disable
STP for those specific vlans when using any type of PVST. Alternatively you can try to
match vlans on either
side.
To convert an interface with AToM xconnect to L2TPv3 xconnect, remove the xconnect
configuration from
the interface and then configure L2TPv3.
Each L2TPv3 tunneled packet includes the entire Layer 2 frame of the payload:
 20 bytes (IP packet header)

 12 bytes (L2TPv3 session header)
 4 bytes (if sequencing is enabled)
 payload (the complete frame received on the AC)
You can have either dynamic or static pseudowires (where no signaling is required for
session establishment).
IOS
pseudowire-class L2TP-PWCLASS encapsulation l2tpv3

ip local interface Loopback0
!
interface X
xconnect 2.2.2.2 12 pw-class L2TP-PWCLASS
IOS-XR
l2vpn
pw-class L2TP-PWCLASS
encapsulation l2tpv3 protocol l2tpv3 ipv4 source 2.2.2.2
!
xconnect group R2-R1-XCONGRP
p2p R2-R1-P2P
interface X
neighbor 1.1.1.1 pw-id 12
In IOS-XR, you have to define the signaling protocol, while in IOS it's enabled by
default.
IOS
R6#sh l2tun tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 1787404852 is up, remote id is 3119273419, 1

active sessions Remotely initiated tunnel
Tunnel state is established, time since change 00:00:14
Tunnel transport is IP (115)
Remote tunnel name is R2

Internet Address 2.2.2.2, port 0
Local tunnel name is R1

Internet Address 1.1.1.1, port 0
L2TP class for tunnel is l2tp_default_class Counters, taking

last clear into account:
0 packets sent, 0 received

0 bytes sent, 0 received
Last clearing of counters never
Counters, ignoring last clear: 0 packets sent, 0 received

0 bytes sent, 0 received
Control Ns 2, Nr 3
Local RWS 1024 (default), Remote RWS 512 Control channel
Congestion Control is disabled Tunnel PMTU checking disabled
Retransmission time 1, max 2 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 1
Total resends 1, ZLB ACKs sent 1
Total out-of-order dropped pkts 0
Total out-of-order reorder pkts 0
Total peer authentication failures 0
Current no session pak queue check 0 of 5 Retransmit time
distribution: 0 1 0 0 0 0 0 0 0 Control message authentication
is disabled
Static PWs require you to define sessions & cookie parameters under the neighbor where the
PW is pointing to.
IOS
pseudowire-class L2TP-CLASS encapsulation l2tpv3 protocol none

!
interface POS2/0
xconnect 2.2.2.2 12 encapsulation l2tpv3 manual pw-class L2TP-

CLASS l2tp id 1 2
l2tp cookie local 4 4660
l2tp cookie remote 8 4660 22136
IOS-XR
l2vpn
xconnect group A-XCONGRP
Using static PWs allows the traffic to pass over the PW as soon as possible (avoiding session
parameter
negotiation).
Youneedtodefine"protocol none"underthepw-
class,otherwiseyouwon'tbeabletodothestatic
configuration.

p2p A-P2P
l2tp static local cookie size 4 value 0x1234

l2tp static local session 1
l2tp static remote cookie size 8 value 0x1234 0x5678 l2tp
static remote session 2
Local/remote values must be reversed on the other side.
When you use a static L2TPv3 session, you cannot perform interworking.
Authentication
L2TPv3 Control Message Hashing (new method) o hash is computed of entire message
o all message types are hashed
L2TP Control Channel Authentication (old method)

o hash is computed of Challenge AVP message only o only SCCRP and SCCCN messages
are hashed
IOS
l2tp-class OLDAUTH-L2TP-CLASS authentication

hostname USER
password PASS
!
l2tp-class NEWAUTH-L2TP-CLASS
digest secret 0 PASS hash SHA1 !
pseudowire-class L2TP-PWCLASS encapsulation l2tpv3

protocol l2tpv3 XXX-L2TP-CLASS ip local interface Loopback0
IOS-XR
l2tp-class OLDAUTH-L2TP-CLASS authentication

hostname USER
password PASS
!
l2tp-class NEWAUTH-L2TP-CLASS
digest hash SHA1
digest secret PASS !
l2vpn
encapsulation l2tpv3
protocol l2tpv3 class XXX-L2TP-CLASS ipv4 source 2.2.2.2
AToM
 A working LSP must exist between the PEs.

 If the configuration is correct, then a targeted LDP adjacency will be formed
between the PEs and the
pseudowire will come up (unless the PEs do not agree on some parameters).
o The PW-ID must agree on both sides.

o MTUs must agree on both ACs for the PW to come up (IOS-XR MTU includes the L2
header).
 The tLDP session is used to exchange labels for the pseudowire.

 The PW label is used to differentiate the local ACs, like the VPN label is used to
differentiate the local
VRFs.
Interfaces at both sides of a local AC must have a common encapsulation (ppp, hdlc,
frame-relay) in order for the local AC to come up.
When you change the encapsulation of an interface, any xconnect configuration is
removed.
You have to exit from the xconnect or pw-class config mode in order to have it
activated.
Besides dynamic pseudowires (based on LDP), you can also create static pseudowires
by having the labels statically defined on each PE.
Logging
Configure the following if you want to enable logging of various PW events.
IOS
xconnect logging pseudowire status
IOS-XR
l2vpn
logging
bridge-domain pseudowire vfi
In IOS-XR, the L2TP class used for authentication (and other parameters) is configured
outside the l2vpn
configuration, in the global configuration.

If you have to change the MTU of the local AC in order to agree with the remote AC, then
you must do the
same for the interface on the other side of the local AC, to account for any IGPs passing over.
Youcanusethe"clear xconnect"commandifyouwanttoresetapseudowire.
IOS
R1#clear xconnect ?
all All xconnect entries
interface All xconnects by interface
peer All xconnects by Peer IP address
PPP Pseudowires
When using xconnect for PPP L2VPN connectivity, then the PPP process of the local AC is
disabled.
no xconnect configured
Serial2/0 is up, line protocol is up

Hardware is M4T
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255 Encapsulation

PPP, LCP Open
xconnect configured
Serial2/0 is up, line protocol is up
Hardware is M4T
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255 Encapsulation

PPP, LCP Closed, crc 16, loopback not set
Frame-Relay
Each PW can be assigned to a single PVC/DLCI.
If you need to transfer all DLCIs of a port, then you have to use HDLC as the interface
encapsulation and do the usual xconnect under the interface.
Frame-relay config on the other side of each AC doesn't have to agree, as long as the DLCIs
are communicated correctly across the MPLS network.
IOS might require to have frame-relay switching enabled on the PE (IOS-XR and GNS3 don't
require it).
APVCthatistransferredacrossthePWisshownas"switched"under"show frame-relay
pvc",while another PVC that terminates locally is shown as "local".
Remember to configure appropriately the IGP network type on the interfaces, if the default
isn't the right one.
Wireshark might not decode correctly the FRoMPLS encapsulation.
IOS
interface Serial2/0 encapsulation frame-relay frame-relay

intf-type dce
!
pseudowire-class FRoMPLS-PWCLASS
encapsulation mpls !
connect FRCON Serial2/0 100 l2transport xconnect 9.9.9.9 19

pw-class FRoMPLS-PWCLASS
IOS-XR
interface POS0/0/0/0.100 l2transport pvc 100
!
interface POS0/0/0/0
encapsulation frame-relay
frame-relay intf-type dce !

l2vpn
encapsulation mpls !
xconnect group FR-XCONGRP p2p R9R1-P2P
interface POS0/0/0/0.100 neighbor 1.1.1.1 pw-id 19 pw-class

FRoMPLS-PWCLASS
IOS
R1#sh connection
ID Name Segment 1 Segment State
==============================================================
=========== =======
2 FRCON Se2/0 100 9.9.9.9 19 UP
R1#sh mpls l2transport vc 19

Local intf Local circuit Dest address VC ID
Status
------------- -------------------------- ---------------
---------- ---- ------
Se2/0 FR DLCI 100 9.9.9.9 19 UP
Ethernet Pseudowires
Tagged mode (vlan mode) o VC type 5
o VC type 4 (if vlan tag is to be transfered too) Raw mode (port mode)
o VC type 5
Usually the VC type is auto-negotiated while the PW is being setup.
Configuration
IOS
pseudowire-class EoMPLS-PWCLASS encapsulation mpls
!
interface X
xconnect 9.9.9.9 19 pw-class EoMPLS-PWCLASS
IOS-XR
interface X l2transport !
l2vpn
pw-class EoMPLS-PWCLASS encapsulation mpls
!
xconnect group R9R1-XCONGRP
p2p R9R1-P2P
interface X
pw-class EoMPLS-PWCLASS
In IOS-XR, you have to define as "l2transport" the interface used as AC in the

xconnect. If there is existing configuration under the interface, it's better to remove the whole
interface, make it L2 and then re- apply the old config (if it's still required.)
Verification
IOS
R1#sh Local
R1#sh mpls l2 vc
Local intf Local circuit Dest address VC ID
Status
------------- -------------------------- ---------------
---------- ---- ------
Fa1/0
Ethernet 9.9.9.9 19 UP mpls l2 vc detail
interface: Fa1/0 up, line protocol up, Ethernet up
Destination address: 9.9.9.9, VC ID: 19, VC status: up Output

interface: Fa0/0.12, imposed label stack {26 16100} Preferred
path: not configured
Default path: active
Next hop: 10.1.2.2
Create time: 00:20:14, last status change time: 00:20:14

Signaling protocol: LDP, peer 9.9.9.9:0 up
Targeted Hello: 1.1.1.1(LDP Id) -> 9.9.9.9, LDP is UP
Status TLV support (local/remote) LDP route watch

Label/status state machine
: enabled/supported
: enabled
: established, LruRru
Last local dataplane Last local SSS circuit Last local SSS
circuit Last local LDP TLV Last remote LDP TLV Last remote LDP
ADJ
status rcvd: No fault status rcvd: No fault status sent: No

fault status sent: No fault status rcvd: No fault status rcvd:
No fault
MPLS VC labels: local 28, remote 16100
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:

Sequencing: receive disabled, send disabled Control Word: Off
(configured: autosense) VC statistics:
transit packet totals: receive 169, send 771
transit byte totals: receive 21479, send 80640 transit packet
drops: receive 0, seq error 0, send 0
"MPLS VC labels" shows the PW labels exchanged by the PEs.
The status you see next to "Label/status state machine" translates to the following:
 L=Local, R=Remote
 r=ready, n=not ready
 u=up, d=down
IOS-XR
R9#sh l2vpn xconnect detail

Group R9R1-XCONGRP, XC R9R1-P2P, state is up;
Interworking none
AC: TenGigE0/0/0/9, state is up
Type Ethernet
MTU 1500; XC ID 0x40002; interworking none Statistics:
packets: received 2324, sent 4514
"imposed label stack" shows the complete label stack (Transport label + PW label) used by
the local PE to
reach the remote PE.
In VC statistics, the send direction counts the traffic from the AC to the PW, while the
receive direction
counts the traffic from the PW to the AC.

bytes: received 1745, sent 4668
PW: neighbor 1.1.1.1, PW ID 19, state is up ( established )
PW class EoMPLS-PWCLASS, XC ID 0xc0000001

Encapsulation MPLS, protocol LDP
Source address 9.9.9.9
PW type Ethernet, control word disabled, interworking none PW
backup disable delay 0 sec
Sequencing not set

Load Balance Hashing: src-dst-ip
Flow Label flags configured (Tx=1,Rx=1), negotiated
(Tx=0,Rx=0)
PW Status TLV in use
------
MPLS
------------
Label
VCCV CC
------------
Local Remote ------------------------------

-----------------------
Group ID
Interface
MTU
Control
PW type
VCCV CV
16100
0x1c0
TenGigE0/0/0/9
1500
disabled
Ethernet
0x2
(LSP ping verification)
0x6
(router alert label)
(TTL expiry) ------------------------------
28
0x0
**AC**
1500
disabled
Ethernet
0x2
(LSP ping verification) 0x2
(router alert label)
-----------------------
word
type
type
------
Incoming Status (PW Status
TLV):
Notification message TLV):
Notification message
Status code: 0x0 (Up) in Outgoing Status (PW Status Status

code: 0x0 (Up) in MIB cpwVcIndex: 3221225473
Create time: 27/12/2013 03:23:01

Last time status changed: 27/12/2013 03:26:49 Statistics:
packets: received 4514, sent 2324 bytes: received 4668, sent

1745
IOS
R1#sh xconnect all

Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2
State
UP=Up DN=Down SB=Standby HS=Hot Standby
XC ST Segment 1
2 S2 ------+---------------------------------+--
+----------------------------- ----+--
AD=Admin Down IA=Inactive RV=Recovering NH=No Hardware

S1 Segment
UP
UP
IOS
ac Fa1/0(Ethernet) UP mpls 9.9.9.9:19
R1#sh xconnect all detail

State
XC ST Segment 1
2 S2 ------+---------------------------------+--
+----------------------------- ----+--
UP
ac Fa1/0(Ethernet) Interworking: none
UP mpls 9.9.9.9:19
UP
IOS-XR
R9#sh l2vpn xconnect Legend: ST = State, UP = SB = Standby, SR
XConnect
Group Name ST
ST
------------------------
--
R9R1-XCONGRP R9R1-P2P UP
UP
--------------------------------------------------------------
----------- --
When viewing the LFIB, the direction is the opposite from L3VPNs, pointing towards the AC
this time.
S1 Segment
Local VC label 28 Remote VC label 16100 pw-class: EoMPLS-

PWCLASS
Up, DN = Down, AD = Admin Down, UR = Unresolved, = Standby

Ready, (PP) = Partially Programmed
IOS
R1#sh mpls
Local
Label
28
point2point
IOS-XR
forwarding-table
Segment 1
Description ST
Segment 2
Description
----------------------- Te0/0/0/9 UP
-------------------- 1.1.1.1 19
Outgoing
Label
No Label
Prefix
or Tunnel Id
l2ckt(19)
Bytes Label
Switched
19658
Outgoing
Interface
Outgoing
interface
Fa1/0
Next Hop
Next Hop
Bytes
R9#sh mpls forwarding
Local Outgoing
Label Label
Switched
Prefix or ID
186
------ ----------- ------------------ ------------

--------------- ------ ------
16100 Pop PW(1.1.1.1:19) Te0/0/0/9 point2point 464883
You can also use ping and traceroute in order to verify the PW (although it won't help you
much in case of a core problem). In IOS-XR, mpls oam must first be activated.
IOS
R1#ping mpls pseudowire 9.9.9.9 19 segment 1 verbose repeat 1

Sending 1, 100-byte MPLS Echos to 9.9.9.9,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output
interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC
mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no
label entry, 'P' - no rx intf label prot, 'p' - premature
termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

! size 100, reply addr 10.8.9.9, return code 3[Labels: 16100
Exp: 0]
Rx Interface: 10.8.9.9
local 1.1.1.1 remote 9.9.9.9 vc id 19
Success rate is 100 percent (1/1), round-trip min/avg/max =

1/1/1 ms
IOS
R1#traceroute mpls pseudowire 9.9.9.9 19 segment

Tracing MS-PW segments within range [1-1] peer address 9.9.9.9
and timeout 2 seconds

interface,
mismatch,
termination of LSP,

! 1 10.8.9.9 1 ms [Labels: 16100 Exp: 0]
local 1.1.1.1 remote 9.9.9.9 vc id 19

Static PWs
You can also use static pseudowires (without tLDP between PEs) if you manually define the
local/remote
labels to be used.
IOS
mpls label range 100 200 static 201 300 !

interface X
xconnect 1.1.1.1 22 encapsulation mpls manual pw-class

STATICPW-PWCLASS mpls label 201 202
IOS-XR
l2vpn
xconnect group XCONGRP
p2p LS-P2P
mpls static label local 201 remote 202

In IOS-XR, labels 16 to 15999 are reserved (by default) for static L2VPN pseudowires.
Interworking
Interworking is actually a transforming function that is required to interconnect two
heterogeneous ACs, by providing the translation between the different L2 encapsulations.
There are 3 main modes:
Ethernet (bridged)
o ethernet frames are extracted from the AC and sent over the PW
o non-ethernet frames are dropped
o ethernet frames with vlan tags, have their tags removed and then send over the PW
Vlan
o ethernet frames are extracted from the AC and sent over the PW
o non-ethernet frames are dropped
o ethernet frames with vlan tags, are send with their tags over the PW
IP (routed)
o ipv4 packets are extracted from the AC and sent over the PW o non-ipv4 packets are
dropped
Supported modes/technologies:
Ethernet/Vlan to Frame-Relay o MPLS/L2TPv3
o Ethernet/IP
Ethernet/Vlan to PPP
o MPLS
o IP
 Ethernet to Vlan
o MPLS/L2TPv3
o Ethernet/IP
 Frame-Relay to PPP
o MPLS/L2TPv3 o IP
In frame-relay interworking the PE router reports the PVC status to the CE router,
based on the status of the pseudowire with the remote PE. Also the status of the local
PVC detected by the PE router will be reflected into the pseudowire status towards the
remote PE.
For ethernet, the PE acts like a proxy-ARP server to all ARP requests from the CE
router. Sometimes you might need to clear the arp table on the CE after making
changes on the PE.
For PPP, proxy IPCP is automatically enabled on the PE router when IP interworking
is configured on the pseudowire.
Although it might not be applicable in the lab, generally you should take care of the
AC MTU so that it doesn't exceed the core MTU.
IOS
pseudowire-class EoMPLS-IW-PWCLASS encapsulation mpls

interworking ip
IOS-XR
l2vpn
p2p A-P2P
interworking ipv4
The rest of the configuration is the same as in normal L2VPN setup. Interworking
doesn't apply in VPLS.
When doing interworking with frame-relay, you can't use inverse-arp (because there is no ip
address on the
other side of the local AC, neither at the other side of the remote AC), so you'll have to either
use static
mapping or change the frame-relay configuration to point-to-point.
Most of the times, you must configure all IGPs for point-to-point operation between the CE
routers when
configuring an Ethernet to non-Ethernet interworking setup.

PW Redundancy
IOS
Ethernet
xconnect 9.9.9.9 19 pw-class EoMPLS-IW-PWCLASS
backup peer 8.8.8.8 18 pw-class EoMPLS-IW-PWCLASS
Frame-Relay
connect FRCON Serial2/0 100 l2transport xconnect 9.9.9.9 19

backup peer 8.8.8.8 18 pw-class FRoMPLS-PWCLASS

The"backup peer"commandisconfiguredonthePEwhichwillhandletheredundancy.
Configure the following if you want to enable logging of the PW redundancy events.
IOS
xconnect logging redundancy
The PW status is signaled between the PEs, if it's supported (it's enabled by default).
IOS
R1#sh xconnect all

State
XC ST Segment 1
2 S2 ------+---------------------------------+--
+----------------------------- ----+--
UP pri ac
Fa1/0(Ethernet) Fa1/0(Ethernet)
UP mpls 9.9.9.9:19 UP mpls
Ethernet
Ethernet
5.5.5.5
9.9.9.9
15
19 UP
UP IA sec ac
5.5.5.5:15
R1#sh mpls l2transport vc
Local intf Local circuit

Status
------------- -------------------------- ---------------
---------- ---- ------
Fa1/0
STANDBY
Fa1/0
SB
S1 Segment
Dest address
VC ID
190
R1#sh mpls l2transport vc 15 detail

Local interface: Fa1/0 up, line protocol up, Ethernet up
Destination address: 5.5.5.5, VC ID: 15, VC status: standby

Output interface: Fa0/0.12, imposed label stack {17 27}
Preferred path: not configured
Default path: active
Next hop: 10.1.2.2

Create time: 00:04:30, last status change time: 00:03:36
Signaling protocol: LDP, peer 5.5.5.5:0 up
Targeted Hello: 1.1.1.1(LDP Id) -> 5.5.5.5, LDP is UP
Status TLV support (local/remote)
LDP route watch
Label/status state machine
: enabled/supported
: enabled
: established, LrdRru
Last local dataplane Last local SSS circuit Last local SSS
circuit Last local LDP TLV Last remote LDP TLV Last remote LDP
ADJ
status rcvd: No fault

status rcvd: DOWN(UP, standby)
status sent: No fault
status sent: DOWN(standby)
status rcvd: No fault
status rcvd: No fault MPLS VC labels: local 32, remote 27
Group ID: local 0, remote 0 MTU: local 1500, remote 1500

Remote interface description:
Sequencing: receive disabled, send disabled Control Word: On

(configured: autosense)
VC statistics:
transit packet totals: receive transit byte totals: receive

transit packet drops: receive
R1#ping mpls pseudowire 5.5.5.5 15

%Total number of MS-PW segments is
the segment number to 1
Sending 5, 100-byte MPLS Echos to 5.5.5.5,
timeout is 2 seconds, send interval is 0 msec:

interface,
mismatch,
termination of LSP,

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
72/78/88 ms
116, send 0
8221, send 0
0, seq error 0, send 0
less than segment number; Adjusting

You can configure the topology as "dual-homed" under the pw-class, if you want to have
both primary and
backup pseudowires appear as active simultaneously. In any case, traffic will continue to pass
through the
primary PW only.
Links

IETF - RFC 4447
IOS
pseudowire-class EOMPLS-PWCLASS encapsulation mpls

status peer topology dual-homed
Keep in mind that the xconnect output is based on the configuration, while the mpls l2vc
output is based on the result.
IOS
R1#sh xconnect all

State
XC ST Segment 1
2 S2 ------+---------------------------------+--
+----------------------------- ----+--
UP pri ac
Fa1/0(Ethernet) UP Fa1/0(Ethernet)
UP mpls 9.9.9.9:19 UP mpls

IA sec ac
5.5.5.5:15
R1#sh mpls l2 vc
Local intf Local circuit
Status
------------- -------------------------- ---------------
---------- ---- ------
Fa1/0
Fa1/0
Ethernet
Ethernet
5.5.5.5
9.9.9.9
15 UP 19 UP
SB
S1 Segment
Dest address
VC ID
192
IOS-XR l2vpn configuration
Everything must be configured under the "l2vpn" hierarchy, including the pw-classes.
VPWS
IOS-XR
l2vpn
p2p A-P2P
interface X
!
neighbor Y pw-id k
pw-class Z
VPLS
IOS-XR
l2vpn
bridge group A-BRGRP
bridge-domain interface X1 interface X2 !
vfi A-VFI
neighbor Y1
pw-class Z
neighbor Y2
pw-class Z
A-BRDOM
pw-id k1
pw-id k2
xconnect/bridge groups are used solely for configuration grouping; you can put all bridge-
domains under the same bridge group and all the p2ps under the same xconnect group.
You can have a neighbor directly under the bridge-domain, if you want to make this an
access pseudowire.
For core pseudowires (which will be 99% the case) you need to define the neighbor under the
vfi.
Below you can find some useful commands for verification and troubleshooting.
Check AToM (AC/PW details, status, MTU, traffic, etc.)
IOS-XR
ASR9k#sh l2vpn xconnect ?
brief
detail
encapsulation
group
groups
Encapsulation brief Detailed information Filter on

encapsulation Filter on group
All groups information
193
interface
mp2mp
mspw
neighbor
private
pw-class
state
summary
type
Filter on interface
MP2MP Information
ms_pw Information
Filter on neighbor
Private information
Filter on pseudowire class Filter on xconnect state Summary
information
Filter on xconnect type Output Modifiers
Check VPLS (AC/PW details, status, MTU, traffic, split-horizon, L2 features like storm-
control, unicast/multicast/broadcast flooding, etc.)
IOS-XR
ASR9k#sh l2vpn bridge-domain ?
autodiscovery
bd-name
brief
detail
group
hardware
interface
neighbor
objects
pbb
private
summary
BGP/Radius autodiscovery information Filter on bridge domain

name
Brief information
Detailed information
Filter on bridge domain group name Hardware information

Filter on interface
Filter on neighbor
Display bridge-domain objects information Provider backbone

bridge information Private information
Bridge domain summary information
Output Modifiers
Check VPLS (mac-addresses and various L2 features like DHCP snooping, ARP inspection,
etc.)
IOS-XR
ASR9k#sh l2vpn forwarding bridge-domain ?
WORD
debug
detail
hardware
location
mac-address
mroute
pbb private
Specify Bridge group name:Bridge domain name Include debug

information
Detailed information
Read from hardware
Specify a location
MAC address information
multicast route information
Provider backbone bridge information Include private
information
194
L2transport ethertype
When configuring a l2transport interface in IOS-XR you have the following options
regarding its tagging/ethertype:
dot1q single vlan

o ethertype 0x8100 (default)
dot1q double vlan (QinQ)

o ethertype 0x8100 (default) o ethertype 0x9100
o ethertype 0x9200
dot1ad
o ethertype 0x88a8 (default)
single vlan double vlan
dot1ad
o ethertype 0x88a8 (default)
The above ethertype refers always to the outer vlan.
dot1q refers to 802.1q, while dot1ad refers to 802.1ad (which is the standard).
H-VPLS
Instead of having a full-mesh of core pseudowires from end to end,
N=Network U= User
core domain
o core PWs between all N-PEs
access domains
o access PWs between each U-PE and a core N-PE
You can also have simple L2 ethernet circuits instead of access PWs. Configuration-wise the
idea is the same as above:
 CE
 U-PE o
 N-PE o
P
o
no change
one (or two) p2p PW from the U-PE to one (or two) N-PE full-mesh of p2p PWs between all
N-PEs
just MPLS switching
you partition the network into smaller
access domains (containing U-PEs and CEs) and a core domain (containing N-PEs and Ps).
195
Example N-PE Config
IOS-XR
l2vpn
bridge group A-BRGRP
bridge-domain A-BRDOM neighbor U-PE1 pw-id k1
pw-class Z !
vfi A-VFI
neighbor N-PE2 pw-id k1
pw-class Z
neighbor N-PE3 pw-id k2
pw-class Z
The above N-PE is responsible for switching the traffic from the access PW (coming from U-
PE1) to the core PWs (going to N-PE2 and N-PE3) and vice versa, based on the usual mac
learning.
Local Switching
Vlan to Vlan
IOS
interface FastEthernet0/0.1 encapsulation dot1q 1
!
encapsulation dot1q 2 !
connect VLAN2VLAN FastEthernet0/0.1 FastEthernet0/0.2
IOS-XR
interface TenGigE0/0/0/0.1 l2transport dot1q vlan 100
!
interface TenGigE0/0/0/0.2 l2transport
dot1q vlan 200

!
l2vpn
xconnect group XCONGRP
Remember that access PWs go outside the VFI and core PWs go inside the VFI, while
everything goes under
the bridge-domain.
p2p LS-P2P
interface
interface
TenGigE0/0/0/0.1 TenGigE0/0/0/0.2
196
Frame-Relay to Frame-Relay
IOS
frame-relay switching
!
interface Serial2/0
frame-relay interface-dlci 100 switched frame-relay intf-type
dce
!
interface Serial2/1
frame-relay interface-dlci 200 switched frame-relay intf-type
dce
!
connect FR2FR serial2/0 100 serial2/1 200
L2TPv3 Local Switching
IOS
pseudowire-class L2TP-1-CLASS encapsulation l2tpv3

pseudowire-class L2TP-11-CLASS encapsulation l2tpv3

interface Loopback0
ip address 1.1.1.1 255.255.255.255
interface Loopback1
ip address 11.11.11.11 255.255.255.255
xconnect 11.11.11.11 111 pw-class L2TP-1-CLASS
!
xconnect 1.1.1.1 111 pw-class L2TP-11-CLASS
2 loopbacks are required for L2TPv3 local switching to work.
IOS
R1#sh xconnect all

State
XC ST Segment 1
2 S2 ------+---------------------------------+--
+----------------------------- ----+--
UP ac
1.1.1.1:111
UP ac
11.11.11.11:111
R1#sh l2tun tunnel sum

L2TP Tunnel Information Total tunnels 2 sessions 2
LocTunID RemTunID Remote Name State Remote Address Sessn L2TP

Class/
Group
1280397094 3308679294 R1 l2tp_default_cl 3308679294 1280397094
R1 l2tp_default_cl
L2VPN/AToM over GRE
Configuration Steps
Count VPDN
est 11.11.11.11 1
est 1.1.1.1 1
Fa0/1(Ethernet) Fa0/0(Ethernet)
UP UP
UP l2tp
UP l2tp
S1 Segment
 create a GRE tunnel with destination the remote L2VPN PE
 enable MPLS on the GRE tunnel
 route the PW through the GRE tunnel (using IGP, static route, preferred-path)
R2 (IOS)
interface Tunnel0
ip unnumbered Loopback0
mpls ip
tunnel source 2.2.29.2
tunnel destination 2.2.79.7 !
ip route 2.2.0.7 255.255.255.255 Tunnel0 !

xconnect 2.2.0.7 27 pw-class PWCLASS
R7 (IOS)
interface Tunnel0
mpls ip
tunnel source 2.2.79.7
tunnel destination 2.2.29.2 !
ip route 2.2.0.2 255.255.255.255 Tunnel0 !

xconnect 2.2.0.2 27 pw-class PWCLASS
IOS-XR
interface tunnel-ip0
ipv4 address 10.10.10.1/24 tunnel mode gre ipv4
tunnel source 11.11.11.1 tunnel destination 12.12.12.2
mpls ldp
interface tunnel-ip0
! l2vpn
xconnect group XCONGRP p2p P2P
The other end of the tunnel is also the remote PE where the PW terminates.
In latest IOS-XR, you can also use the preferred tunnel-path feature in order to map the PW
to a specific GRE tunnel, instead of pointing the PW to the remote PE router..
IOS-XR
l2vpn
pw-class GRE-PWCLASS
encapsulation mpls
preferred-path interface tunnel-ip0
You must also enable an IGP on the tunnel (or create a static route for a different hop), in
order to drive the
PW destination across it. Be careful of recursive routing (tunnel destination must not go
through the tunnel
itself).
Only PE-to-PE tunnels are supported when using preferred-path.

IOS supports something similar, but in very specific hardware and software.
PW Switching or Multisegment PW
An L2VPN multisegment PW (MS-PW, also known as switched PW) is a set of two or more
PW segments that function as a single PW. They can be inside a single AS or they can span
multiple AS.
The end routers are called terminating PE routers (T-PEs) and the switching routers are called
S-PE routers. S-PE's role is to:
 terminate the tunnels of the preceding and succeeding PW segments

 switch the control and data planes of the preceding and succeeding PW segments
An MS-PW is declared to be up when all the single-segment PWs are up.

Interworking must be configured only at the edge PEs, not on the S-PEs.
In an MS-PW spanning PE-1 <=> S-PE-2 <=> S-PE-3 <=> PE-4, the configuration
would be the following:
IOS
PE-1
interface X
xconnect S-PE-2 12 encapsulation mpls
S-PE-2
l2 vfi MS123-VFI point-to-point neighbor PE-1 12

encapsulation mpls neighbor S-PE-3 23 encapsulation mpls
S-PE-3
l2 vfi MS234-VFI point-to-point neighbor S-PE-2 23

encapsulation mpls neighbor PE-4 34 encapsulation mpls
PE-4
interface X
xconnect S-PE-3 34 encapsulation mpls
BGP-Based VPLS Autodiscovery
It enables each VPLS PE router to discover "automatically" the other PE routers that are part
of the same VPLS domain using BGP.
BGP uses the L2VPN RIB to store endpoint provisioning information, which is updated each
time a L2 VFI is configured. When BGP distributes the endpoint provisioning information in
an update message to all its BGP neighbors, the endpoint information is used to configure a
PW mesh between these neighbors.
In older releases, VPLS Autodiscovery is not supported with L2TPv3 or Inter-AS topologies.
You will want to configure extra static VPLS neighbors for:
 PEs that do not participate in the autodiscovery process (in order to join the VPLS)
 PEs that have been configured with the Tunnel Selection feature
 U-PEs in H-VPLS configurations that do not participate in the autodiscovery
process and have split-
horizon forwarding disabled
The same RT is not allowed in multiple VFIs in the same PE router.
In older releases, the BGP peer address must be a /32 address bound to the peer's LDP
router-id.
Split-horizon should not be disabled on autodiscovered neighbors.
Route reflectors can be used to reflect the BGP VPLS prefixes without having VPLS
explicitly configured on them.
IOS
l2 vfi VPLSAUTO-VFI autodiscovery vpn id 100
!
router bgp 1

neighbor 2.2.2.2 update-source Loopback0
The same vpn id must be configured on all PEs that are part of the same VPN.
It'sgoodpracticetoalsouse"bgp update-delay
1"inordertominimizetheinitialupdatetime.
You can configure both autodiscovered and manually configured PWs in the same VFI, but
not for the same
peer PE. If you need to do that, then configure appropriately the RT values to prevent each
peer from
receiving discovery data for that VPLS.
address-family l2vpn vpls

neighbor 2.2.2.2 send-community extended
exit-address-family

There are various options you can configure under the l2 vfi, with the RT being the most
important.
IOS
l2 vfi VPLSAUTO-VFI autodiscovery vpn id X

vpls-id X:Y
rd X:Y
route-target import/export X:Y l2 router-id x.x.x.x
Default values:
 vpls-id: ASN:vpn-id
 rd: ASN:vpn-id
 route-target: lower 6 bytes of rd and vpls-id
 l2 router-id: LDP router-id
VPLS ID is a BGP extended community value that identifies the VPLS domain. It
must be the same between PEs of the same VPN and unique between different VFIs
of the same PE.
In case of Inter-AS VPLS, it must
be defined manually and be the same on all PEs of the same VPLS domain, since ASNs are
different.
RSVP/MPLS-TE
MPLS-TE (MPLS Traffic Engineering) Requirements are described in RFC 2702. RSVP
(Resource Reservation Protocol) is defined in RFC 2205.
RSVP-TE (RSVP Traffic Engineering extension) is defined in RFC 3209. OSPFv2
extensions for TE are defined in RFC 3630.
OSPFv3 extensions for TE are defined in RFC 5329. ISIS extensions for TE are defined in
RFC 5305.
RSVP
Two main messages:
PATH
o sent with the same source and destination addresses as the actual data (i.e. tunnel src/dst),
in
order to be routed correctly even through non-RSVP routers o objects
LabelRequestObject
ExplicitRouteObject(ERO)
RecordRouteObject(RRO)
SessionAttributeObject(SAO) SenderTSpec
RESV
o sent hop-by-hop by having each RSVP router forward a RESV message to the previous
RSVP
hop (learned by the PATH message) o objects
LabelObject
RecordRouteObject(RRO)
Each RESV message follows the exact reverse path of the initial PATH message
As a general case (but not applicable to MPLS-TE), if the PATH message arrives at a router
that does not understand RSVP, that router should forward the message as a normal packet
without interpreting the contents of the message and will not reserve resources for the flow.

R1-R2-R3-R4
where an MPLS-TE tunnel is going to be built from R1 to R4.
RSVP messages are sent hop-by-hop between RSVP-enabled routers as "raw" IP packets
with protocol
number 46.
Then the following actions will happen when an RSVP reservation is asked:
1. R1
1. checks reservation attributes

2. sends PATH message with src/dst R1/R4 to next-hop (R2)
2. R2
1. receives PATH message with src/dst R1/R4 from previous-hop (R1)

3. R3

4. R4

3. makes the reservation
4. sends RESV message with src/dst R4/R3 to previous-hop (R3)
5. R3
1. receives RESV message with src/dst R4/R3 from R4

6. R2

7. R1

2. creates the tunnel (up/up)
In case of MPLS-TE, one reservation attribute could be the transport label required in order
to build the LSP tunnel.
tunnel head-end = RSVP sender tunnel tail-end = RSVP receiver
The request to bind labels to a specific LSP tunnel is initiated by the tunnel ingress node
(known as RSVP sender) using a PATH message.
The reply to this label allocation PATH message is sent from the egress node (known as
RSVP receiver) back upstream towards the sender using a RESV message, following the path
state across all nodes created by the initial PATH message in reverse order.
Each intermediate node that receives a RESV message containing a label, uses that label for
outgoing traffic associated with this specific LSP tunnel. If the node is not the sender, it
allocates a new label and places that
Labels are allocated downstream (R1=>R4) using PATH messages and propagated upstream
(R4=>R1) using
RESV messages.
new label into a new RESV message which it sends upstream to the previous-hop, until it
reaches the sender and a complete LSP is built.
RSVP hellos are not enabled by default, since they are not needed for normal MPLS TE
operation.
RSVP & Fast Failure Detection
When RSVP signals a TE LSP and there is a failure somewhere along the path, the failure
can remain undetected for as long as two minutes (timeout of RSVP session).
Two solutions can be used for triggering fast detection in case of a failure:
 RSVP hellos
 BFD RSVP hellos
IOS
ip rsvp signalling hello
!
interface X
ip rsvp signalling hello
IOS-XR
not supported
IOS
R4#sh ip rsvp hello

Hello:
RSVP Hello for Fast-Reroute/Reroute: Enabled Statistics:

Disabled
BFD for Fast-Reroute/Reroute: Disabled RSVP Hello for

Graceful Restart: Disabled
Whenusing"sh ip rsvp
int"toverifythersvpbandwidthonaninterface,allrsvpenabledinterfaces
are shown, even the ones that are shut down.
IOS-XR supports only BFD for fast detection (< 1sec). RSVP hellos can be used for simple
reroute (detection
> 10sec) or GR.

Thesametypeof"rsvp signalling
hello"mustbeconfiguredontheothersidetooforfastdetection
to take place.
R4#sh ip rsvp hello client lsp sum

Local Remote tun_id lsp_id subgrp_orig FLAGS
2.2.2.2 19.19.19.19 0 46 0.0.0.0 0x24
R4#sh ip rsvp hello client lsp det Hello Client LSPs (all lsp
tree)
Tun Dest: 19.19.19.19 Tun ID: 0 Ext Tun ID: 2.2.2.2 Tun
Sender: 2.2.2.2 LSP ID: 46
subgrp_id 0
Lsp
R4#sh ip
Local
20.4.5.4
R4#sh ip
Hello
Nbr
RR DN nbr: 20.4.5.5 FRR
rsvp hello client nbr
Remote Type
20.4.5.5 RR
rsvp hello client nbr det
Client Neighbors
Remote addr 20.4.5.5,

State: Normal Type:
NBR_STATE HI_STATE Normal Up
LSPs 1
Lsp flags: 0x24

Nbr Hello State: Up
LSPs protecting: 1 I/F: Fa0/0.45
In IOS, there are 3 different commands to set the hello refresh interval:
ip rsvp signalling hello refresh interval xxx o refresh interval: 10-
30000 ms
Local addr 20.4.5.4 Reroute
ip rsvp signalling hello fast-reroute refresh interval xxx o

refresh interval: 10-30000 ms
ip rsvp signalling hello reroute refresh interval xxx o refresh

interval: 1000-30000 ms
The first two ones are the same and are the ones that actually enable/configure FRR. The
number of refresh misses is configured likewise.
BFD
Check "BFD" for more information.
In both cases in IOS, RSVP hellos must be configured both globally on the router and on the
specific interface
in order to be operational.
MPLS-TE Configuration
 enable MPLS-TE globally

 enable MPLS-TE & RSVP under each interested interface
 enable MPLS-TE extensions under the IGP
 create the MPLS-TE tunnel
Minimum configuration includes the following:
IOS
! global
mpls traffic-eng tunnels
! per interface interface X
mpls traffic-eng tunnels ip rsvp bandwidth
! per IGP router isis X
metric-style wide mpls traffic-eng mpls traffic-eng
!
router ospf X
mpls traffic-eng mpls traffic-eng
! per tunnel interface Tunnel0
router-id Loopback0 level x
router-id Loopback0 area x
tunnel mode mpls traffic-eng
tunnel destination x.x.x.x
tunnel mpls traffic-eng path-option 1 dynamic
IOS-XR
! global mpls ldp
! per interface rsvp
interface X !
mpls traffic-eng interface X
! per IGP router ospf X
area 0
mpls traffic-eng
mpls traffic-eng router-id Loopback0
!
router isis X
address-family ipv4 unicast metric-style wide

mpls traffic-eng level x
mpls traffic-eng router-id Loopback0
! per tunnel interface tunnel-te0
ipv4 unnumbered Loopback0 destination x.x.x.x path-option 1

dynamic
If you don't set the router-id under the IGP, you won't be able to create any TE paths for the
tunnels.
You have to configure "ip rsvp bandwidth" in order to set the reserved bandwidth per
interface (tunnels can work without setting it, as long as their required bandwidth is 0).
Default bandwidth is 75% in IOS and 0 in IOS-XR (IOS-XR doesn't support the setting of
bandwidth as a percentage).
You won't see the RSVP bandwidth of an interface as allocated, unless the tunnel that passes
through it is fully operational.
RSVP bandwidth is reserved only on the egress interface of a router (based on the direction
of the tunnel).
Don't forget to enable wide metrics if using IS-IS (IOS gives you a warning).
In IOS-XR every tunnel type has a specific interface name. For MPLS-TE tunnels, the name
"tunne-te" is used.
Each TE tunnel is unidirectional, so if you want to make it behave like bidirectional, then you
need to configureareversetunnelfromthetail-endtothehead-endtoo.Only"ip
unnumbered"shouldbeusedin TE tunnels due to their unidirectional nature.
Is IOS-XR you must also enable MPLS LDP (even when LDP is not going to be used),
otherwise data-
plane won't work and you'll see unresolved CEF entries.
Most tunnel changes require to shut/no shut the tunnel interface in order to have immediate
effect.
Setting the (signaled) bandwidth on the tunnel is not necessary for normal operation, but it
might help to verify the TE path when checking the RSVP interface bandwidth on the path.
MPLS TE in Cisco software supports only a single IGP process/instance.
For extra logging information, you can configure the following:
IOS
R1(config)#mpls traffic-eng logging lsp ?
path-errors preemption reservation-errors setups
teardowns
Log LSP Path Error traps
Log LSP Preemption traps
Log LSP Reservation Error traps Log LSP Establishment Traps
Log LSP Teardown Traps
R1(config)#mpls traffic-eng logging tunnel ? lsp-selection Log

Tunnel LSP Selection traps path Log Tunnel Path-related traps
IOS-XR
C12k(config-if)#logging events ?
link-status Enable interface and line-protocol state change
alarms lsp-status Enable interface LSP state change alarms
C12k(config-if)#logging events lsp-status ?
insufficient-bandwidth bandwidth
reoptimize
reroute
state
switchover
MPLS-TE Verification
IOS
Enable Syslog for setup/reopt failure due to
Enable interface LSP REOPT change alarms Enable interface LSP

REROUTE change alarms Enable interface LSP UP/DOWN change
alarms Enable interface LSP SWITCHOVER change alarms
When using MPLS-TE in place of LDP for a L3VPN connection, then the transport label is
provided by
RSVP.
R2#sh mpls traffic-eng tunnels tunnel 0 | i Label InLabel : -

OutLabel : FastEthernet0/0.24, 16
R2#sh mpls
Local
Label
None
point2point
Outgoing Label
16
Outgoing Next Hop

interface
Tu0
MAC/Encaps=18/22, MRU=1500, Label Stack{16}, via Fa0/0.24

CA0611400000CA0509F00000810000188847 00010000
The VPN label is still provided by BGP VPNv4.
IOS
R2#sh bgp vpnv4 unicast all 20.20.20.20/32 | i label mpls

labels in/out nolabel/17
You can also check the labels assigned by RSVP in the intermediate routers and follow the
path like in LDP labels.
Don'tforgettousethecompleteprefixwhencheckingtheLFIBinthePE,otherwise"sh mpls
forwarding-table" won't show you anything about it.
IOS
R4#sh mpls
InLabel
OutLabel
R5#sh mpls
InLabel
OutLabel
IOS
R4#sh mpls
Local
Label
16
R5#sh mpls
Local
Label
26
20.5.19.19
traffic-eng tunnels | i Label : FastEthernet0/0.24, 16
: FastEthernet0/0.45, 26
traffic-eng tunnels | i Label

: FastEthernet0/0.45, 26
: FastEthernet0/0.519, implicit-null
Keepinmindthat"sh mpls forwarding-

table"willshowyouthetunnelsourceprefix(which
originated the RSVP messages) when referring to TE tunnels.
forwarding-table
Outgoing Prefix
Label or Tunnel Id 26 2.2.2.2 0 [1]
forwarding-table
Outgoing Prefix
Label or Tunnel Id Pop Label 2.2.2.2 0 [1]
Bytes Label
Switched
7658
Bytes Label
Switched
7540
Outgoing
interface
Fa0/0.45 20.4.5.5
Outgoing Next Hop

interface
Fa0/0.519
[1]"aftertheprefixarethe"Tun_Id"and"Tun_instance"foundin"sh mpls
Thenumber"0
traffic-eng tunnels"output.
Next Hop
Other options include:
R5#sh mpls traffic-eng tunnels | i Tun

LSP Tunnel R2_t0 is signalled, connection is up
Src 2.2.2.2, Dst 19.19.19.19, Tun_Id 0, Tun_Instance 1

Youcanuse"clear ip rsvp reservation
*"ifyouwanttocleartheRSVPlabelbindings(i.e.after
you change the mpls label range).
You can use the following command in order to find the optimal path for a tunnel, based on
current resources:
IOS
R2#sh mpls traffic-eng tunnels suboptimal constraints current

| b Short Shortest Availability-Constrained Path Info:
Path Weight: 30 (TE)

Explicit Route: 20.2.4.2 20.2.4.4 20.4.5.4 20.4.5.5
20.5.19.5 20.5.19.19 19.19.19.19
R2#sh mpls
current
max
resources
none
Thesameinfoisavailableifyouusethe"sh mpls traffic-eng tunnels tunnel
X"command,
explicitly specifying the tunnel.

An easy way to find the address (and label when using FRR) of each hop, is to enable record-
route.
IOS
interface Tunnel0
tunnel mpls traffic-eng record-route
IOS-XR
interface tunnel-te0
record-route
IOS
R2#sh mpls traffic-eng tunnels | b Resv RSVP Resv Info:
Record Route: 20.3.4.3 20.4.5.4 20.5.19.5 20.5.19.19
Besidesvariousshowcommands,youcanuse"debug mpls traffic-eng

tunnels"inorderto check for any error messages while setting up the tunnel path. Other
possible debugs are the following:
traffic-eng tunnels suboptimal constraints ?

path lookup constrained by available resources
path lookup constrained by network's maximum potential
path lookup without any constraints
R2#debug mpls traffic-eng tunnels ?
auto-bw
errors
events fast-reroute labels path-protection reoptimize

signalling state
timers
MPLS Traffic Engineering tunnel auto-bw

MPLS Traffic Engineering tunnel errors
MPLS Traffic Engineering tunnel system events MPLS Traffic
Engineering tunnel fast reroute MPLS Traffic Engineering
tunnel labels
MPLS Traffic Engineering tunnel path protection MPLS Traffic
Engineering tunnel reoptimization MPLS Traffic Engineering
tunnel signalling
MPLS Traffic Engineering tunnel state machine MPLS Traffic
Engineering tunnel timers
Some of these debugs are replicated in the RSVP debug commands.
Ifyouenable"debug mpls traffic-eng tunnels signalling

detail"andthereisanerror in RSVP communication somewhere in the path, you'll get the
following message, which will guide you to the hop with the problem:
TE-SIG-HE: Tunnel0 [71]->1.1.1.1: received Path Error from

20.2.4.2: Routing Problem: No route available toward
destination
Traffic steering & LSP attributes
You can use the following methods in order to steer the tunnel traffic through a specific TE
path:
 use explicit path-option with specific addresses included/excluded

 use dynamic path option and change the interface IGP metric
 use dynamic path option and change the interface TE metric (administrative-
weight)
 use dynamic path option and change the interface RSVP bandwidth or the tunnel
bandwidth
 use dynamic path option and change the interface/tunnel affinity/attributes
 use a combination of explicit path-option and the above attributes
explicit-path
When using explit-paths in order to define the TE path, you can use either loopbacks
or next-hop addresses as next-address. Also there is no need to define the last-hop,
which is the tail-end.
i.e. for a path R2-R3-R4-R5-R6-R7 you can simply create the following explicit path
on R2:
IOS
interface Tunnel0
ip unnumbered Loopback0 tunnel mode mpls traffic-eng
However, it's good practice to
define next-hop addresses (plus the last-hop) if you want to be as strict as possible about the
path.

tunnel destination 2.2.2.2
tunnel mpls traffic-eng path-option 1 explicit name R3-R4-R5-

R6 !
ip explicit-path name R3-R4-R5-R6 enable next-address R3

next-address R4
next-address R5
next-address R6
IOS-XR
ipv4 unnumbered Loopback0
destination 2.2.2.2
path-option 1 explicit name R3-R4-R5-R6
!
explicit-path name R3-R4-R5-R6
index 1 next-address strict ipv4 unicast R3 index 2 next-

address strict ipv4 unicast R4 index 3 next-address strict
ipv4 unicast R5 index 4 next-address strict ipv4 unicast R6
Whileeditingtheexplicit-path,youcanuse"index
x"inordertochangeaspecificentry,or"list"to view all current entries.
Whencheckingtheoutputof"sh mpls traffic-eng

topology"youcanfindtheexactpath(ip addresses from all ingress/egress interfaces) followed
under the "Explicit Route" object (ERO).
bandwidth
You can define the tunnel required/signaled bandwidth and the interface available bandwidth
in order to steer the traffic through a path that has enough bandwidth to accommodate the
tunnel's need.
IOS
interface FastEthernet0/0 mpls traffic-eng tunnels ip rsvp

bandwidth 100000
!
interface Tunnel0
ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel

destination 2.2.2.2
When using the "exclude-address" option, the path is considered semi-dynamic. It
works like a
dynamic path (based on IGP), but specific hops are avoided.
This is purely a control-plane reservation, in order to allow the TE tunnels to be established.

In order to
actually reserve that amount of bandwidth for the TE tunnel traffic, you have to configure the
appropriate QoS
too.
tunnel mpls traffic-eng bandwidth 99000 tunnel mpls traffic-

eng path-option 1 dynamic
IOS-XR
rsvp
interface X
bandwidth 100000 !
ipv4 unnumbered Loopback0 signalled-bandwidth 99000
destination 2.2.2.2 path-option 1 dynamic
You can use the Path Option for Bandwidth Override in order to provide a fallback path
option that allows overriding the bandwidth configured on the TE tunnel (i.e a path option
with bandwidth set to 0 removes the bandwidth constraint imposed by the constraint-based
routing calculation).
When an LSP is signaled using a path option with a configured bandwidth, the bandwidth
associated with the path option is signaled instead of the signaled bandwidth configured
directly on the tunnel. You can have multiple path-options with different bandwidth
requirements.
IOS
interface Tunnel0
tunnel mode mpls traffic-eng
tunnel destination 19.19.19.19
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 50000
R5 tunnel mpls traffic-eng path-option 2 dynamic bandwidth
25000 tunnel mpls traffic-eng path-option 3 dynamic bandwidth
0
In the above example, 3 path-options are using 3 different bandwidth requirements:
 path-option 1 (explicit) requires 50000 kbps (default)

 path-option 2 (dynamic) requires 25000 kbps
 path-option 3 (dynamic) requires 0 kbps
With bandwidth override configured on a path option, the traffic engineering software
attempts to reoptimize the bandwidth every 30 seconds.
All path-options should use the same type of
bandwidth (global pool or sub-pool), otherwise reoptimization might not occur.
TE metric
You can influence the path that the tunnel will follow by changing the TE metric
(administrative-weight) on
the physical interfaces along the path.

IOS
interface Χ
mpls traffic-eng tunnels
mpls traffic-eng administrative-weight 2
IOS-XR
mpls traffic-eng interface Χ
admin-weight 2
If TE metric is set to its max under a specific interface, then tunnel will never pass through
that interface.
All TE metric changes require to shut/no shut the tunnel interface in order to have immediate
effect.
Default TE metric is the IGP metric for that specific path. Whenever IGP metric changes, TE
metric follows, unless it's explicitly configured, so it gets priority.
Usually it's easier to increase the TE metric on the path that should not be preferred, instead
of decreasing the
metric on the path that should be preferred.
IOS
R1#sh mpls traffic-eng tunnel
P2P TUNNELS/LSPs:
Name: R1_t0
Status:
Admin: up Oper: up connected
(Tunnel0) Destination: 2.2.2.2 Path: valid Signalling:
path option 1, type dynamic (Basis for Setup, path weight 23)
You can change this default path-selection policy (where TE metric is used) using the
following command,
either globally or under the specific tunnel:
IOS
mpls traffic-eng path-selection metric igp
!
interface Tunnel0
tunnel mpls traffic-eng path-selection metric igp
IOS-XR
mpls traffic-eng path-selection metric igp
!
path-selection metric igp
Use the following commands to verify the current metric type:
IOS
R1#sh mpls traffic-eng tunnels | i Metric Metric Type: TE

(default)
R1#sh mpls traffic-eng tunnels | i Metric Metric Type: IGP

(interface)
IOS-XR
GSR#sh mpls traffic-eng tunnels | i Metric Metric Type: TE

(default)
path-options
You can define multiple path-options (as fall-back methods), with preference 1 having the
highest priority. ThecurrentlyactiveTEpathcanbefoundbycheckingthe"sh mpls
traffic-eng tunnels" command output.
IOS
interface Tunnel0
R6 tunnel mpls traffic-eng path-option 2 dynamic
IOS-XR
path-option 1 explicit name R3-R4-R5-R6 path-option 2 dynamic
IOS
R2#sh mpls traffic-eng tunnels
P2P TUNNELS/LSPs:
Name: R2_t0
Status:
Admin: up Oper: up connected
(Tunnel0) Destination: 7.7.7.7 Path: valid Signalling:
path option 2, type dynamic (Basis for Setup, path weight 40)
path option 1, type explicit R3-R4-R5-R6
...
Youcanalsouse"traceroute mpls traffic-eng"onaPEinordertoverifytheTEpath

unidirectionally:
IOS
R2#traceroute mpls traffic-eng tunnel 0

Tracing MPLS TE Label Switched Path on Tunnel0, timeout is 2
seconds

interface,
mismatch,
termination of LSP,
'X' - unknown return code, 'x' - return Type escape sequence

to abort.
0 26.2.4.2 MRU 1500 L 1 26.2.4.4 MRU 1500 L 2 26.4.5.5 MRU

1500 L 3 26.5.6.6 MRU 1500 L 4 26.3.6.3 MRU 1504 ! 5
26.3.19.19 140 ms
IOS-XR
[Labels:
[Labels:
[Labels:
[Labels:
[Labels:
code 0
22 Exp: 0]
22 Exp: 0]
21 Exp: 0]
22 Exp: 0]
implicit-null Exp: 0] 112 ms
76 ms
80 ms
104 ms
GSR#traceroute mpls traffic-eng tunnel 0
Tracing MPLS TE Label Switched Path on tunnel-te0, timeout is

2 seconds

interface, 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' -
FEC mismatch, 'M' - malformed request, 'm' - unsupported tlvs,
'N' - no rx label, 'P' - no rx intf label prot, 'p' -

CCIE SP Notes For Lab

Uploaded by

Copyright:

Available Formats

CCIE SP Notes For Lab

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CCIE SP Notes For Lab

Uploaded by

Copyright:

Available Formats

Method

vrf forwarding VPN-B

Multi-VRF Selection Using Policy-Based Routing

criteria defined in an ip access list or on packet length.

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

ip access-list standard VPN-A-ACL permit 1.1.2.2

ip access-list standard VPN-B-ACL permit 1.1.3.3

ip access-list standard VPN-C-ACL permit 1.1.4.4

match ip address VPN-A-ACL

set vrf VPN-A

route-map VRF-SELECTION-PBR match ip address VPN-B-ACL set vrf

match ip address VPN-C-ACL set vrf VPN-C

VRF Selection Based on Source IP Address

address of the packets. It's supported only on very specific hardware.

vrf selection source 1.1.1.0 255.255.255.0 vrf VPN-A vrf

ip vrf select source ip vrf receive VPN-A ip vrf receive VPN-B

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

 supported by limited hardware

R1(config)#vrf selection source 1.1.1.0 255.255.255.0 vrf

% VRF Select: failed to add config

assigned to directly connected hosts.

1.1.1.1 255.255.255.0 secondary vrf VPN-A 1.1.2.1

ip vrf forwarding VPN-A

ip address 10.10.10.1 255.255.255.0 !

any directly connected hosts must not run routing protocols

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

ACL Based Forwarding (ABF) with VRF Next-Hop

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

LDP Discovery (to directly connected neighbors) o Multicast UDP to 244.0.0.2:646

targetedLDP Discovery (to non-directly connected neighbors) o Unicast UDP to

LDP Session/Advertisement/Notification (to all) o Unicast TCP to x.x.x.x:646

Use"sh mpls ldp bindings"tochecktheLIB(labelsforallIGPdatabaseprefixes)

Outgoing Label under "show mpls forwarding-table":

o Local device is an LSR Pop Label

o Local device is an LSR and also the PHP No Label

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

o Local device is a LER

Default is implicit-null due to PHP.

"debug mpls packet"includesthelabelstack{LabelEXPTTL}information

Label Allocation Methods

an IGP/Transport Label is allocated through o LDP (+IGP)

o RSVP (MPLS TE)

Targeted LDP Sessions

Static LDP neighbors on both routers R1

mpls ldp neighbor R2 targeted

mpls ldp neighbor R1 targeted

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

mpls ldp neighbor R2 targeted

mpls ldp discovery targeted-hello accept

mpls ldp neighbor R1 targeted

interface Tunnel0 tunnel destination R2 mpls ip

mpls ldp discovery targeted-hello accept

Something similar applies to IOS-XR too.

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Simple VPN with iBGP & LDP

Assuming a network of R1-R2-R3-R4-R5-R6, where R2,R3,R4,R5 run LDP+IGP in the core

can be used to forward traffic to that route destination.

R2#sh mpls forwarding-table | i 6.6.6.6 R2# -no entry shown-