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

108 NTS for CCIE SP Lab by chatasos

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

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
109 NTS for CCIE SP Lab by chatasos

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

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
110 NTS for CCIE SP Lab by chatasos

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

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

111 NTS for CCIE SP Lab by chatasos

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

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

mpls ldp neighbor R1 targeted

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.
112 NTS for CCIE SP Lab by chatasos

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

mpls ldp neighbor R2 targeted

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 neighbor R1 targeted

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.
113 NTS for CCIE SP Lab by chatasos

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

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

114 NTS for CCIE SP Lab by chatasos

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

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.

115 NTS for CCIE SP Lab by chatasos

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

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

116 NTS for CCIE SP Lab by chatasos

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

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

duration: 86400 seconds

LDP Session Protection enabled, state: Protecting

duration: 86400 seconds

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
117 NTS for CCIE SP Lab by chatasos

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

%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.

118 NTS for CCIE SP Lab by chatasos

delay x

sync

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

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.

119 NTS for CCIE SP Lab by chatasos

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

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
120 NTS for CCIE SP Lab by chatasos
chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

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

R4#sh mpls int detail Interface FastEthernet0/0:

IP labeling not enabled

LSP Tunnel labeling enabled BGP labeling not enabled MPLS
operational
MTU = 1530

IOS

interface FastEthernet0/0 mtu 1530

mpls mtu 1508

121 NTS for CCIE SP Lab by chatasos

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

R4#sh mpls int detail Interface FastEthernet0/0:

IP labeling not enabled

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)

122 NTS for CCIE SP Lab by chatasos

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

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

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

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

124 NTS for CCIE SP Lab by chatasos

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

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

Clearing of vrf routing table might be needed every time a new prefix is redistributed.
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
125 NTS for CCIE SP Lab by chatasos

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

redistribute bgp 200 exit-address-family

!
router bgp 200

address-family ipv4 vrf VPN

redistribute eigrp 1

IOS-XR
router eigrp 100
vrf VPN

address-family ipv4

autonomous-system 1

redistribute bgp 200 !

router bgp 200

vrf VPN

address-family ipv4 unicast

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
Clearing of vrf routing table might be needed every time a new prefix is redistributed.
ISIS metric = hops (10)
Configuration
126 NTS for CCIE SP Lab by chatasos

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

IOS

router isis 100

address-family ipv4 vrf VPN redistribute bgp 200

!
router bgp 200

address-family ipv4 vrf VPN

redistribute isis 100

IOS-XR

router isis 100

vrf VPN
redistribute bgp 200

!
router bgp 200

vrf VPN
address-family ipv4 unicast

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)

127 NTS for CCIE SP Lab by chatasos

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

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
Clearing of vrf routing table might be needed every time a new prefix is redistributed.
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
128 NTS for CCIE SP Lab by chatasos

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

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.

129 NTS for CCIE SP Lab by chatasos

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

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

OSPF Router with ID (10.1.3.1) (Process ID 100)

Type-5 AS External Link States

130
NTS for CCIE SP Lab by chatasos

Links

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

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).

131 NTS for CCIE SP Lab by chatasos

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

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:

132 NTS for CCIE SP Lab by chatasos

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

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
OSPF Router with ID (10.1.2.2) (Process ID 100)

...

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)

133 NTS for CCIE SP Lab by chatasos

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

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.
134 NTS for CCIE SP Lab by chatasos

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

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

NTS for CCIE SP Lab by chatasos

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

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

!
interface FastEthernet0/0.20

description ** Customer VPN2 ** encapsulation dot1q 20

ip vrf forwarding VPN2
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

neighbor 10.10.10.2 activate

exit-address-family !

address-family ipv4 vrf VPN2

136 NTS for CCIE SP Lab by chatasos

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

neighbor 20.20.20.2 remote-as 2

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 **

!
interface FastEthernet0/0.10

description ** Customer VPN1 ** encapsulation dot1q 10

ip vrf forwarding VPN1
ip address 10.10.10.2 255.255.255.0

!
interface FastEthernet0/0.20

description ** Customer VPN2 ** encapsulation dot1q 20

ip vrf forwarding VPN2
ip address 20.20.20.2 255.255.255.0

!
router bgp 2

neighbor 2.2.2.2 remote-as 2

neighbor 2.2.2.2 update-source Loopback0 neighbor 2.2.2.2
description iBGP-VPNv4

!
address-family vpnv4
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community extended neighbor 2.2.2.2
next-hop-self

exit-address-family !

address-family ipv4 vrf VPN1 neighbor 10.10.10.1 remote-as 1

neighbor 10.10.10.1 activate

exit-address-family !

address-family ipv4 vrf VPN2 neighbor 20.20.20.1 remote-as 1

137 NTS for CCIE SP Lab by chatasos

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

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 !

address-family vpnv4
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

interface FastEthernet0/0 description ** Inter-AS NNI ** ip

address x.x.x.x
mpls bgp forwarding

!
router bgp 2

no bgp default route-target filter

neighbor PE-2 remote-as 2
neighbor PE-2 update-source Loopback0 neighbor PE-2
description MP-iBGP with PE-2
138 NTS for CCIE SP Lab by chatasos

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

neighbor ASBR-1 remote-as 1

neighbor ASBR-1 description MP-eBGP with ASBR-1 !

address-family vpnv4
neighbor PE-2 activate
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 remote-as 1
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

!
address-family vpnv4

neighbor PE-1 activate

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
139 NTS for CCIE SP Lab by chatasos

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

ASBR-1

IOS

interface FastEthernet0/0 description ** Inter-AS NNI ** ip

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

!
address-family vpnv4

neighbor RR-1 activate

neighbor RR-1 send-community extended exit-address-family

ASBR-2

IOS

interface FastEthernet0/0 description ** Inter-AS NNI ** ip

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 !

140 NTS for CCIE SP Lab by chatasos

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

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

!
address-family vpnv4

neighbor RR-2 activate

neighbor RR-2 send-community extended exit-address-family

RR-2

IOS

router bgp 2
neighbor PE-2 remote-as 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

!
address-family vpnv4

neighbor PE-2 activate

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.
141 NTS for CCIE SP Lab by chatasos
chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

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
address-family ipv4 unicast

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.

142 NTS for CCIE SP Lab by chatasos

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

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

MAC/Encaps=18/18, MRU=1504, Label Stack{}

CA02141C0008CA0417EC0000810000770800
No output feature configured

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

forwarding-table 19.19.19.19 detail Outgoing Prefix Bytes

Label Label or Tunnel Id Switched Pop Label 19.19.19.19/32 0

Outgoing interface
Fa0/0 12.1.19.19

MAC/Encaps=18/18, MRU=1504, Label Stack{}

CA02141C0008CA0417EC0000810000770800
No output feature configured

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

interface FastEthernet0/0

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

NTS for CCIE SP Lab by chatasos

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

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.
144 NTS for CCIE SP Lab by chatasos

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

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

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

MAC/Encaps=18/18, MRU=1504, Label Stack{}

CA02141C0008CA0611100000810001A38847
No output feature configured

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

NTS for CCIE SP Lab by chatasos

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

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

Transport label is 20, VPN label is 26

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

MAC/Encaps=18/22, MRU=1500, Label Stack{19}

CA0711100000CA0417EC00008100000D8847 00013000 No output
feature configured
Transport label is 19, VPN label is 26

IOS

R3#sh mpls
Local
Label
19

forwarding-table labels 19 detail

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

MAC/Encaps=18/18, MRU=1504, Label Stack{}

CA0517EC0000CA0711100000810000178847
No output feature configured

VPN label is 26

IOS
R2#sh bgp vpnv4 unicast all 7.7.7.7/32
BGP routing table entry for 102:202:7.7.7.7/32, version 4
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
146 NTS for CCIE SP Lab by chatasos

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

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 activate

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.
147 NTS for CCIE SP Lab by chatasos

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

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

NTS for CCIE SP Lab by chatasos

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

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.

149 NTS for CCIE SP Lab by chatasos

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

route-target 10:X !

address-family ipv4

exit-address-family !

interface Ethernet1/0
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 !
address-family vpnv4
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)

mpls ldp router-id Loopback0 mpls label protocol ldp

!
interface Ethernet1/0

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

150 NTS for CCIE SP Lab by chatasos

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

route-target 100:Y !
address-family ipv4 exit-address-family

!
interface Ethernet1/3

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

no bgp default ipv4-unicast
neighbor CC-PE2 remote-as 100
neighbor CC-PE2 update-source Loopback0 !
address-family vpnv4

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)

mpls ldp router-id Loopback0 mpls label protocol ldp

!
router isis/ospf x

!
mpls ldp

router-id x.x.x.x

interface x !

!forconnectivitytoCsC-CE2 (eBGP+Label)

vrf CC-VPN
address-family ipv4 unicast

import route-target 10:X

151 NTS for CCIE SP Lab by chatasos

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

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
address-family ipv4 unicast

CsC-CE2/32 GigabitEthernet0/2/1/1 !

router bgp 10
address-family ipv4 unicast !
vrf CC-VPN

rd 10:X
address-family ipv4 unicast

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

152 NTS for CCIE SP Lab by chatasos

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

CsC-CE2 (IOS)

!forconnectivitytoCsC-PE2 (eBGP+Label)

interface Ethernet1/0
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

exit-address-family !

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 !
address-family vpnv4

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

153 NTS for CCIE SP Lab by chatasos

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

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)

o Transport label is 26, VPN label is 20 o next-hop is R10 (10.10.10.10)

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)

o Transport label is 21, VPN label is 20 o next-hop is R7 (7.7.7.7)

R7 (7.7.7.7) (CsC-PE) - vrf CSC 154

NTS for CCIE SP Lab by chatasos

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

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

2 20.2.3.3 [MPLS: Labels 20/20 Exp 0] 7 msec 7 msec 7 msec

3 20.3.4.4 [MPLS: Labels 26/20 Exp 0] 8 msec 8 msec 7 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

6 20.6.7.7 [MPLS: Labels 21/20 Exp 0] 3 msec 3 msec 3 msec

7 20.7.8.8 [MPLS: Labels 18/20 Exp 0] 1 msec 1 msec 1 msec

8 20.8.9.9 [MPLS: Labels 17/20 Exp 0] 1 msec 1 msec 1 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

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

BGP routing table entry for 100:1:99.99.99.99/32, version 11

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)

Origin incomplete, metric 1, localpref 100, valid, internal,
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

MAC/Encaps=18/22, MRU=1500, Label Stack{18}

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

nexthop 20.1.2.2 FastEthernet0/0.12 label 18

Transport label is 18, VPN label is 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

forwarding-table 10.10.10.10 detail

Outgoing Label
20

Prefix Bytes Label or Tunnel Id Switched 10.10.10.10/32 13707

Outgoing
interface
Fa0/0.23 20.2.3.3

MAC/Encaps=18/22, MRU=1500, Label Stack{20}

CA0610240000CA0113DC00008100002E8847 00014000 No output
feature configured

Transport label is 20, VPN label is 20

Next Hop

156 NTS for CCIE SP Lab by chatasos

CsC-CE

R3#sh mpls
Local
Label
20
forwarding-table 10.10.10.10 detail

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

Outgoing Label
26

Prefix Bytes Label or Tunnel Id Switched 10.10.10.10/32 15048

Outgoing Next Hop interface

Fa0/0.34 20.3.4.4

MAC/Encaps=18/22, MRU=1500, Label Stack{26}

CA0207940008CA0610240000810001A38847 0001A000 No output
feature configured

Transport label is 26, VPN label is 20

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
No output feature configured

2 Transport labels are used (use "detail" to see them)

R4#sh bgp vpnv4 unicast vrf CSC 10.10.10.10

BGP routing table entry for 200:1:10.10.10.10/32, version 12
Paths: (1 available, best #1, table CSC)

Advertised to update-groups: 3

100
7.7.7.7 (metric 4) from 7.7.7.7 (7.7.7.7)

Origin incomplete, metric 20, localpref 100, valid, internal,

best Extended Community: RT:200:1
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

forwarding-table 7.7.7.7 detail

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

MAC/Encaps=18/22, MRU=1500, Label Stack{16}

C20911080000CA0207940008810003338847 00010000 No output
feature configured

Transport label is 16/21, VPN label is 20

Backbone Carrier P router

Next Hop

R5#sh mpls forwarding-table 7.7.7.7 detail

Local Outgoing Prefix Bytes tag Outgoing Next Hop

157 NTS for CCIE SP Lab by chatasos

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

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

Per-packet load-sharing

Transport label is 16/21, VPN label is 20

Backbone Carrier P router

R6#sh mpls forwarding-table 7.7.7.7 detail

Local Outgoing Prefix

Bytes tag
switched
42398

Outgoing Next Hop interface

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
No output feature configured

Per-packet load-sharing

Transport label is 21, VPN label is 20

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

forwarding-table 10.10.10.10 detail

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

MAC/Encaps=18/22, MRU=1500, Label Stack{18}

CA0710240000CA04151800008100000D8847 00012000 VPN route: CSC
No output feature configured

Transport label is 18, VPN label is 20

Outgoing Label
17

Prefix Bytes Label or Tunnel Id Switched 10.10.10.10/32 24703

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

Next Hop

MAC/Encaps=18/22, MRU=1500, Label Stack{17}

CA0013DC0000CA0710240000810000238847 00011000 No output
feature configured

Transport label is 17, VPN label is 20

Customer Carrier P router

R9#sh mpls
Local
Label
17
20.9.10.10

forwarding-table 10.10.10.10 detail Outgoing Prefix Bytes

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

158

NTS for CCIE SP Lab by chatasos

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

MAC/Encaps=18/18, MRU=1504, Label Stack{}

CA0515180000CA0013DC0000810000198847
No output feature configured

Transport label is removed, VPN label is 20

Customer Carrier PE router

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

MAC/Encaps=18/18, MRU=1504, Label Stack{}

C20A0F840000CA05151800008100001D0800
VPN route: VPN
No output feature configured

VPN label is removed, destination reached

Following the labels

Customer Carrier P router

R2#sh mpls
Local
Label
18

forwarding-table labels 18 detail

Outgoing Label
20

Prefix Bytes Label or Tunnel Id Switched 10.10.10.10/32 13852

Outgoing
interface
Fa0/0.23
Next Hop
20.4.6.4

MAC/Encaps=18/22, MRU=1500, Label Stack{20}

CA0610240000CA0113DC00008100002E8847 No output feature

configured

Transport label is 20, VPN label is 20

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

MAC/Encaps=18/22, MRU=1500, Label Stack{26}

CA0207940008CA0610240000810001A38847 0001A000 No output
feature configured

Transport label is 26, VPN label is 20

CsC-PE

Label

159 NTS for CCIE SP Lab by chatasos

R4#sh mpls
Local
Label
26

forwarding-table labels 26 detail

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

Outgoing Label
21
Prefix Bytes Label or Tunnel Id Switched
10.10.10.10/32[V]16645

Outgoing Next Hop interface

Fa0/0.45 20.4.5.5

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

C20911080000CA0207940008810003338847 0001000000015000 VPN
route: CSC
No output feature configured

2 Transport labels are used (use "detail" to see them)

Transport label is 16/21, VPN label is 20

Backbone Carrier P router

R5#sh mpls forwarding-table labels 16 detail

Local Outgoing Prefix

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

Transport label is 16/21, VPN label is 20

Backbone Carrier P router

R6#sh mpls forwarding-table labels 16 detail

Local Outgoing Prefix

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

Transport label is 21, VPN label is 20

CsC-PE

R7#sh mpls
Local
Label
21

forwarding-table labels 21 detail

Outgoing Label
18

Prefix Bytes Label or Tunnel Id Switched

10.10.10.10/32[V]17260

Outgoing
interface
Fa0/0.78 20.7.8.8

MAC/Encaps=18/22, MRU=1500, Label Stack{18}

CA0710240000CA04151800008100000D8847 00012000 VPN route: CSC
No output feature configured

Transport label is 18, VPN label is 20

Next Hop
160 NTS for CCIE SP Lab by chatasos

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

CsC-CE

R8#sh mpls
Local
Label
18

forwarding-table labels 18 detail

Outgoing Label
17

Prefix Bytes Label or Tunnel Id Switched 10.10.10.10/32 17726

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

Next Hop
MAC/Encaps=18/22, MRU=1500, Label Stack{17}
CA0013DC0000CA0710240000810000238847 00011000 No output
feature configured

Transport label is 17, VPN label is 20

Customer Carrier P router

R9#sh mpls
Local
Label
17
20.9.10.10

forwarding-table labels 17 detail Outgoing Prefix Bytes Label

Label or Tunnel Id Switched Pop Label 10.10.10.10/32 17200

MAC/Encaps=18/18, MRU=1504, Label Stack{}

CA0515180000CA0013DC0000810000198847
No output feature configured

Transport label is removed, VPN label is 20

Customer Carrier PE router

R10#sh mpls forwarding-table labels 20 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

MAC/Encaps=18/18, MRU=1504, Label Stack{}

C20A0F840000CA05151800008100001D0800
VPN route: VPN
No output feature configured

VPN label is removed, destination reached

161

NTS for CCIE SP Lab by chatasos

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

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

no bgp default ipv4-unicast
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

162 NTS for CCIE SP Lab by chatasos

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

!
neighbor CE-IPv6

remote-as X
address-family ipv6 unicast

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
Assume the following network:
163 NTS for CCIE SP Lab by chatasos

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

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 next-hop is R5 (IPv4 loopback)
o Transport label is 25, IPv6 label is 28

R4 (IPv4)
o next-hop is R5 (IPv4 loopback)
o Transport label is removed, IPv6 label is 28

R5 (IPv4/IPv6 6PE)

o next-hop is R6 (IPv6 link-local)
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

3 ::FFFF:10.3.4.4 [MPLS: Labels 25/28 Exp 0] 1 msec 1 msec 1

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

164 NTS for CCIE SP Lab by chatasos

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

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

Verification in every hop

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

R2#sh bgp ipv6 unicast 2001::6:6:6:6/128

BGP routing table entry for 2001::6:6:6:6/128, version 3
Paths: (1 available, best #1, table default)

Advertised to update-groups: 1

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

mpls labels in/out nolabel/28

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

forwarding-table 5.5.5.5 detail

Outgoing Label
26

Prefix
or Tunnel Id
5.5.5.5/32
Bytes Label
Switched
0

Outgoing Next Hop interface

Fa0/0.23 10.2.3.3

MAC/Encaps=18/22, MRU=1500, Label Stack{26}

CA071AC40000CA0517C80000810000178847 0001A000 No output
feature configured

165

NTS for CCIE SP Lab by chatasos

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

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

recursive via 5.5.5.5 label 28

nexthop 10.2.3.3 FastEthernet0/0.23 label 26

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

MAC/Encaps=18/22, MRU=1500, Label Stack{25}

CA0113200000CA071AC40000810000248847 00019000 No output
feature configured

Transport label is 25, IPv6 label is 28

Provider IPv4 Router

R4#sh mpls
Local
Label
25

forwarding-table 5.5.5.5 detail

Outgoing Prefix
Label or Tunnel Id Pop Label 5.5.5.5/32

Bytes Label
Switched
16125

Outgoing interface Fa0/0.45 10.4.5.5

MAC/Encaps=18/18, MRU=1504, Label Stack{}

CA0214D00008CA01132000008100026B8847
No output feature configured

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
No output feature configured

Next Hop

R5#sh mpls
Local
Label
28

forwarding-table 2001::6:6:6:6/128 detail

166

NTS for CCIE SP Lab by chatasos

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

R5#sh bgp ipv6 unicast 2001::6:6:6:6/128
BGP routing table entry for 2001::6:6:6:6/128, version 3
Paths: (1 available, best #1, table default)

Advertised to update-groups: 2

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

mpls labels in/out 28/nolabel

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

Last updated 00:43:37 ago

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

no bgp default ipv4-unicast
neighbor 6VPE-IPv4 remote-as 100
neighbor 6VPE-IPv4 update-source Loopback0 !
address-family vpnv6

neighbor 6VPE-IPv4 activate

neighbor 6VPE-IPv4 send-community extended exit-address-family

!
address-family ipv6 vrf VPN
167 NTS for CCIE SP Lab by chatasos

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

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
address-family ipv6 unicast
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.

168 NTS for CCIE SP Lab by chatasos

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

6VPE Example

Assume the following network:

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)
o next-hop is R2 (IPv6 link-local)

R2 (IPv4/IPv6 6VPE)

o next-hop is R5 (IPv4 loopback)
o Transport label is 18, VPNv6 label is 28

R3 (IPv4)
o next-hop is R5 (IPv4 loopback)
o Transport label is 25, VPNv6 label is 28

R4 (IPv4)
o next-hop is R5 (IPv4 loopback)
o Transport label is removed, VPNv6 label is 28

R5 (IPv4/IPv6 6VPE)

o next-hop is R6 (IPv6 link-local)
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

2 ::FFFF:10.2.3.3 [MPLS: Labels 18/28 Exp 0] 1 msec 1 msec 1

msec

3 ::FFFF:10.3.4.4 [MPLS: Labels 25/28 Exp 0] 1 msec 1 msec 1

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.

169 NTS for CCIE SP Lab by chatasos

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

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

Verification in every hop

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

Last updated 01:47:39 ago

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)

Advertised to update-groups: 3

1
::FFFF:5.5.5.5 (metric 4) from 5.5.5.5 (5.5.5.5)

Origin incomplete, metric 0, localpref 100, valid, internal,

best Extended Community: RT:100:1
mpls labels in/out nolabel/28

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

forwarding-table 5.5.5.5 detail

Outgoing Label
18

Prefix
or Tunnel Id
5.5.5.5/32
Bytes Label
Switched
0
Outgoing Next Hop interface
Fa0/0.23 10.2.3.3

MAC/Encaps=18/22, MRU=1500, Label Stack{18}

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

170 NTS for CCIE SP Lab by chatasos

R3#sh mpls
Local
Label
18

forwarding-table labels 18 detail Outgoing Prefix Bytes Label

Label or Tunnel Id Switched
25 5.5.5.5/32 45876

Outgoing
interface
Fa0/0.34
Next Hop
10.3.4.4

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

recursive via 5.5.5.5 label 28
nexthop 10.2.3.3 FastEthernet0/0.23 label 18

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.

Provider IPv4 Router

MAC/Encaps=18/22, MRU=1500, Label Stack{25}

CA0119D80000CA070D4C0000810000248847 No output feature

configured

Transport label is 25, VPNv6 label is 28

Provider IPv4 Router

R4#sh mpls
Local
Label
25

00019000

Bytes
Switched
45343

forwarding-table labels 25 detail

Outgoing Prefix
Label or Tunnel Id Pop Label 5.5.5.5/32

Label

Outgoing
interface
Fa0/0.45
Next Hop
10.4.5.5

MAC/Encaps=18/18, MRU=1504, Label Stack{}

CA0217AC0008CA0119D800008100026B8847
No output feature configured

Transport label is removed, VPNv6 label is 28

Provider 6VPE router

R5#sh mpls
Local
Label
28

forwarding-table labels 28 detail

Outgoing Label
No Label

Prefix Bytes Label or Tunnel Id Switched

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
No output feature configured

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)

171 NTS for CCIE SP Lab by chatasos

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

Advertised to update-groups: 1

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,

best Extended Community: RT:100:1
mpls labels in/out 28/nolabel

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

Last updated 02:08:07 ago

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

172 NTS for CCIE SP Lab by chatasos

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

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
address-family ipv6 vrf VPN

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)

Advertised to update-groups: 4

65001
2001:10:2:8::8 from 10.2.8.8 (10.8.8.8)

Origin IGP, metric 0, localpref 100, valid, external,

best Extended Community: RT:26:65001
mpls labels in/out 27/nolabel

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)

173 NTS for CCIE SP Lab by chatasos

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.

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

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
Status codes: s suppressed, d damped, h history, * valid, >
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
...
Status codes: s suppressed, d damped, h history, * valid, >
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

NTS for CCIE SP Lab by chatasos

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

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.

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

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.

176 NTS for CCIE SP Lab by chatasos

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

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
 pw-class L2TP-PWCLASS
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

177 NTS for CCIE SP Lab by chatasos

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

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

ip local interface Loopback0

!
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.

178 NTS for CCIE SP Lab by chatasos

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

p2p A-P2P
neighbor 1.1.1.1 pw-id 100

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
pw-class L2TP-PWCLASS
179 NTS for CCIE SP Lab by chatasos

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

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.
180 NTS for CCIE SP Lab by chatasos

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

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.
181 NTS for CCIE SP Lab by chatasos

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

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
pw-class FRoMPLS-PWCLASS

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

182 NTS for CCIE SP Lab by chatasos

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

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
neighbor 1.1.1.1 pw-id 19

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

183 NTS for CCIE SP Lab by chatasos

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

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.

184 NTS for CCIE SP Lab by chatasos

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

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

185 NTS for CCIE SP Lab by chatasos

UP

UP

IOS

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

ac Fa1/0(Ethernet) UP mpls 9.9.9.9:19

R1#sh xconnect all detail

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 ------+---------------------------------+--
+----------------------------- ----+--
UP

ac Fa1/0(Ethernet) Interworking: none

UP mpls 9.9.9.9:19

AD=Admin Down IA=Inactive RV=Recovering NH=No Hardware

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

NTS for CCIE SP Lab by chatasos

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

------ ----------- ------------------ ------------

--------------- ------ ------
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

Type escape sequence to abort.

! 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

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

Type escape sequence to abort.

! 1 10.8.9.9 1 ms [Labels: 16100 Exp: 0]

local 1.1.1.1 remote 9.9.9.9 vc id 19

187 NTS for CCIE SP Lab by chatasos

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

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
neighbor 1.1.1.1 pw-id 22

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
188 NTS for CCIE SP Lab by chatasos

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

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
xconnect group A-XCONGRP

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.

189 NTS for CCIE SP Lab by chatasos

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

PW Redundancy

IOS

Ethernet

interface FastEthernet1/0
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

pw-class FRoMPLS-PWCLASS

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

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 ------+---------------------------------+--
+----------------------------- ----+--
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

AD=Admin Down IA=Inactive RV=Recovering NH=No Hardware

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

NTS for CCIE SP Lab by chatasos

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

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:

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

Type escape sequence to abort.

!!!!!
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

191 NTS for CCIE SP Lab by chatasos

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

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

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

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 ------+---------------------------------+--
+----------------------------- ----+--
UP pri ac

Fa1/0(Ethernet) UP Fa1/0(Ethernet)

UP mpls 9.9.9.9:19 UP mpls

AD=Admin Down IA=Inactive RV=Recovering NH=No Hardware

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

NTS for CCIE SP Lab by chatasos

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

IOS-XR l2vpn configuration

Everything must be configured under the "l2vpn" hierarchy, including the pw-classes.

VPWS

IOS-XR
l2vpn
xconnect group A-XCONGRP

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

NTS for CCIE SP Lab by chatasos

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

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

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

NTS for CCIE SP Lab by chatasos

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

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

NTS for CCIE SP Lab by chatasos

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

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

!
interface FastEthernet0/0.2

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

NTS for CCIE SP Lab by chatasos

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

Frame-Relay to Frame-Relay
IOS

frame-relay switching

!
interface Serial2/0

encapsulation frame-relay
frame-relay interface-dlci 100 switched frame-relay intf-type
dce

!
interface Serial2/1

encapsulation frame-relay
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

ip local interface Loopback0

pseudowire-class L2TP-11-CLASS encapsulation l2tpv3

ip local interface Loopback1

interface Loopback0
ip address 1.1.1.1 255.255.255.255

interface Loopback1
ip address 11.11.11.11 255.255.255.255

interface FastEthernet0/0
xconnect 11.11.11.11 111 pw-class L2TP-1-CLASS

!
interface FastEthernet0/1
xconnect 1.1.1.1 111 pw-class L2TP-11-CLASS

2 loopbacks are required for L2TPv3 local switching to work.

197 NTS for CCIE SP Lab by chatasos

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

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 ------+---------------------------------+--
+----------------------------- ----+--
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

AD=Admin Down IA=Inactive RV=Recovering NH=No Hardware

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 !

198 NTS for CCIE SP Lab by chatasos

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

interface Ethernet1/0
xconnect 2.2.0.7 27 pw-class PWCLASS

R7 (IOS)
interface Tunnel0

ip unnumbered Loopback0

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 !

interface Ethernet1/0

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

neighbor 2.2.2.2 pw-id 12

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).

199 NTS for CCIE SP Lab by chatasos

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

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
200 NTS for CCIE SP Lab by chatasos

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

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

no bgp default ipv4-unicast

neighbor 2.2.2.2 remote-as 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.

201 NTS for CCIE SP Lab by chatasos

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 activate
neighbor 2.2.2.2 send-community extended

exit-address-family

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

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.
202 NTS for CCIE SP Lab by chatasos

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

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.

Assume the following network:

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.

203 NTS for CCIE SP Lab by chatasos

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

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)

2. checks reservation attributes
3. sends PATH message with src/dst R1/R4 to next-hop (R3)

3. R3

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

2. checks reservation attributes
 3. sends PATH message with src/dst R1/R4 to next-hop (R4)

4. R4

1. receives PATH message with src/dst R1/R4 from previous-hop (R3)

2. checks reservation attributes
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

2. sends RESV message with src/dst R3/R2 to previous-hop (R2)

6. R2

1. receives RESV message with src/dst R3/R2 from R3

2. sends RESV message with src/dst R2/R1 to previous-hop (R1)

7. R1

1. receives RESV message with src/dst R2/R1 from R2

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.
204 NTS for CCIE SP Lab by chatasos

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

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.

205 NTS for CCIE SP Lab by chatasos

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

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.

206 NTS for CCIE SP Lab by chatasos

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

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

ip unnumbered Loopback0
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 !

207 NTS for CCIE SP Lab by chatasos

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

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.

208 NTS for CCIE SP Lab by chatasos

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

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

209 NTS for CCIE SP Lab by chatasos

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

R2#sh mpls
Local
Label
None
point2point

forwarding-table 19.19.19.19 detail

Outgoing Label
16

Prefix Bytes Label or Tunnel Id Switched 19.19.19.19/32 0

Outgoing Next Hop

interface
Tu0

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

CA0611400000CA0509F00000810000188847 00010000
No output feature configured

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
210 NTS for CCIE SP Lab by chatasos

Thenumber"0
traffic-eng tunnels"output.

Next Hop
Other options include:

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

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

211 NTS for CCIE SP Lab by chatasos

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

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.

212 NTS for CCIE SP Lab by chatasos

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

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

interface tunnel-te0
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.

213 NTS for CCIE SP Lab by chatasos

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

tunnel mpls traffic-eng bandwidth 99000 tunnel mpls traffic-

eng path-option 1 dynamic

IOS-XR

rsvp
interface X

bandwidth 100000 !

interface tunnel-te0
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
ip unnumbered Loopback0
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
tunnel mpls traffic-eng path-option 1 explicit name R3-R4-R6-
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.

214 NTS for CCIE SP Lab by chatasos

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

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

215 NTS for CCIE SP Lab by chatasos

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

mpls traffic-eng path-selection metric igp

!
interface tunnel-te0

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
tunnel mpls traffic-eng path-option 1 explicit name R3-R4-R5-
R6 tunnel mpls traffic-eng path-option 2 dynamic
IOS-XR

interface tunnel-te0
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

216 NTS for CCIE SP Lab by chatasos

...

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

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

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 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

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 rx label, 'P' - no rx intf label prot, 'p' -