Basic’s of L2VPN

Pavan Chaudhari
CCIE 37281
1. Session I
 Layer 2 VPN Motivation and Overview
 VPWS Reference Model
2. Session II
 VPLS Reference Model
 PE Auto-Discovery
3. Session III
 H-VPLS
 VPLS Multihoming
AGENDA
 Advanced Topics - FAT
 eVPN
4. Session IV
 Migration from VPWS to eVPN
 Migration from VPLS to eVPN
 eVPN-Vxlan
Key Takeaway from the session-I ( L2VPN )

L2VPN –
Extending the L2 Broadcast domain across the IP or MPLS network.

EFP –
interface TenGigE0/0/0/16.100 l2transport
encapsulation <default/dort1q/untagged>
dot1q - single vlan -- multiple vlan , exact , secondary-vlan
Vlan-range -- multiple vlan , exact , secondary-vlan
rewrite ingress tag <pop/push/translate> <vlan-numbers> symmetric

L3ACL / L2-ACL can be configured on AC / Ethernet Flow point ( EFP)

VPWS/AToM/EoMPLS/E-LINE -
No MAC address learning performed on PE router.
Ethernet Pusedowire – Ethernet port based ( type-5 ) /vlan-based ( type-4)
Bydefault PW-Type is Ethernet.
If you are defining MTU manually on pseudowire take mtu difference between IOS and IOS-XR into consideration.
IOS - mtu is IPHeader + data ( default is 1500 )
IOS-XR – mtu is Ethernet-Header + IPHeader + data ( default is 1514 )
CDP :- # IOS-XE to pass CDP/STP frames

Router(config)#interface gigabitEthernet 1
Router(config-if)#service instance 1 ethernet
Router(config-if-srv)#l2protocol forward ?
cdp Cisco Discovery Protocol
dot1x Dot1x Protocol
dtp Dynamic Trunking Protocol
elmi ELMI Protocol
esmc ESMC Protocol
lacp LACP Protocol
lldp Link Layer Discovery Protocol
pagp Port Aggregation Protocol
ptppd PTP Peer Delay Protocol
stp Spanning Tree Protocol
udld UDLD Protocol
vtp Vlan Trunking Protocol
<cr> <cr>
 CDP :- # IOS-XR to pass CDP/STP frames
https://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-
routers/116453-technote-ios-xr-l2vpn-00.html#anc27

RP/0/RSP0/CPU0:ASR-9904-A#show cdp neighbors tenGigE 0/1/1/2

Sun Sep 20 08:21:57.651 UTC
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater interface TenGigE0/0/1/2
cdp
Device ID Local Intrfce Holdtme Capability Platform Port ID !
ASR9001-F Te0/1/1/2 157 R ASR9K Ser Gi0/0/0/10 interface TenGigE0/0/1/2.1 l2transport
encapsulation untagged
ASR-9001-E Te0/1/1/2 150 R ASR9K Ser Te0/0/1/2
!
l2vpn
bridge group BG_100
bridge-domain BD_100
interface TenGigE0/0/1/2.1

interface TenGigE0/1/1/2
cdp
!
interface TenGigE0/1/1/2.100
ipv4 address 162.1.1.2 255.255.255.0
encapsulation dot1q 100
!
 MULTIPOINT
SERVICES

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 6
Multipoint Service :-

With only two interfaces in a point-to-point cross connect, an L2VPN switch takes everything received on
side and forwards it on the other side.

When there are more than two interfaces in a bridge-domain, an Ethernet switch has to make a switching
decision in order to determine where to forward frames based on their destination MAC address. The switch
does MAC learning based on the source MAC address of the frames that it receives and builds a
mac-address-table.

In Cisco IOS XR software, a broadcast domain or an emulated LAN is called a bridge-domain.

A bridge-domain is basically one broadcast domain where broadcasts and multicast frames are flooded. One
mac-address-table is associated with each bridge-domain (unless MAC learning is disabled manually by
configuration, which is very rare). This usually corresponds to one IPv4 or IPv6 subnet where all hosts in the
bridge-domain are directly connected.
BRIDGE DOMAIN :- WHAT IS BD ?

• Bridge domain is nothing but same broadcast domain.

under the bridge domain it will have same ip subnet for

all CE's, vlan can be different ( because we can add
/remove vlans)
One mac-address-table is associated with each bridge-
domain (unless MAC learning can be disabled manually)

Router will act as a switch and will pass BUM traffic to all
interface and pass known Unicast to port from where he
learned MAC address
LOCAL SWITCHING USING BRIDGE DOMAIN
interface GigabitEthernet0/1/0/38.2 l2transport interface GigabitEthernet0/1/0/3.2 l2transport
encapsulation dot1q 2 encapsulation dot1q 2
rewrite ingress tag pop 1 symmetric PE1 rewrite ingress tag pop 1 symmetric
G0/1/0/39.2 G0/1/0/38.2 G0/1/0/3.2 G0/1.2
R2 10.1.1.2 /24 R3
10.1.1.1 /24
R1
Te0/2/0/4.2

Te0/0/1/0.2 interface TengigE0/2/0/4.2 l2transport

l2vpn
10.1.1.3 /24 encapsulation dot1q 2
bridge group customer1 R4
rewrite ingress tag pop 1 symmetric
bridge-domain engineering
interface Tengige0/2/0/4.2
!
interface GigabitEthernet0/1/0/38.2
!
interface GigabitEthernet0/1/0/3.2

• Bridge-domain must be configured under a bridge group.

• In this example, customer is used to group bridge-domains; however, it can be grouped to any criteria.
RP/0/RSP0/CPU0:router1#show l2vpn bridge-domain group customer1 bd-name engineering
Legend: pp = Partially Programmed.
Bridge group: customer1, bridge-domain: engineering, id: 5, state: up,
ShgId: 0, MSTi: 0
Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
Filter MAC addresses: 0
ACs: 3 (3 up), VFIs: 0, PWs: 0 (0 up), PBBs: 0 (0 up)
List of ACs:
Gi0/1/0/3.2, state: up, Static MAC addresses: 0
Gi0/1/0/38.2, state: up, Static MAC addresses: 0
Te0/2/0/4.2, state: up, Static MAC addresses: 0
List of Access PWs:
List of VFIs:

RP/0/RSP0/CPU0:router1#show l2vpn bridge-domain group customer1 bd-name engineering

det | in "state is up|received"
AC: GigabitEthernet0/1/0/3.2, state is up
packets: received 185066, sent 465
bytes: received 13422918, sent 34974
AC: GigabitEthernet0/1/0/38.2, state is up
packets: received 8, sent 12287
bytes: received 770, sent 892418
AC: TenGigE0/2/0/4.2, state is up
packets: received 463, sent 11839
bytes: received 35110, sent 859028
RP/0/RSP0/CPU0:router1#clear l2vpn forwarding counters
RP/0/RSP0/CPU0:router1#show l2vpn forwarding bridge-domain customer1:engineering
mac-address location 0/1/CPU0
To Resynchronize MAC table from the Network Processors, use the command...
l2vpn resynchronize forwarding mac-address-table location

Mac Address Type Learned from/Filtered on LC learned Resync Age Mapped to

------------------------------------------------------------------------------
0019.552b.b581 dynamic Gi0/1/0/3.2 0/1/CPU0 0d 0h 0m 0s N/A
0019.552b.b5c3 dynamic Gi0/1/0/3.2 0/1/CPU0 0d 0h 0m 0s N/A
0024.986c.6417 dynamic Gi0/1/0/38.2 0/1/CPU0 0d 0h 0m 0s N/A
6c9c.ed3e.e484 dynamic Te0/2/0/4.2 0/2/CPU0 0d 0h 0m 0s N/A

The MAC learning is executed in hardware by the linecards each time a frame is received in the bridge-domain.
There is also a software cache of the mac-address-table, but this software table cannot be updated continuously in
order to match the hardware entries. When the show command is entered in recent code, it tries to resynchronize
the software table with the hardware table. After a maximum of 15 seconds, it prints the current state of the software
mac-address-table, even if the resynchronization is not complete (for example, if the table is large). Use the l2vpn
resynchronize forwarding mac-address-table command in order to resynchronize the software and
hardware tables manually.
Count /Block packet using L3-ACL/L2-ACL on Attachment ckt :-

1. If customer complains about specific service not working over the L2VPN then we
can either configure L2 or L3 ACL to match customer IP/MAC.

2. If we need to block any particular packet from reaching out to remote side.
E.g one site is running PVST and other site is running MST. Using ACL I can
block the BPDU’s on attachment ckt/EFP.
Count packet using L3 ACL on Attachment ckt :-
If customer complains about specific customer then we can either configure L2 or L3
ACL to match customer IP/MAC.
interface GigabitEthernet0/1/0/38.2 l2transport
ipv4 access-list L2VPN-TEST
encapsulation dot1q 2
10 permit icmp host 10.1.1.1 host 10.1.1.2 echo
rewrite ingress tag pop 1 symmetric
20 permit icmp host 10.1.1.2 host 10.1.1.1 echo-reply
ipv4 access-group L2VPN-TEST ingress hardware-count
30 permit any any
ipv4 access-group L2VPN-TEST egress hardware-count

RP/0/RSP0/CPU0:router1#show access-lists L2VPN-TEST hardware ingress location 0/1/cpu0

Fri Jul 7 22:21:13.651 EDT
ipv4 access-list L2VPN-TEST
10 permit icmp host 10.1.1.1 host 10.1.1.2 (100 hw matches)
20 permit icmp host 10.1.1.2 host 10.1.1.1
30 permit any any

RP/0/RSP0/CPU0:router1#show access-lists L2VPN-TEST hardware egress location 0/1/cpu0

Fri Jul 7 22:25:48.325 EDT
ipv4 access-list L2VPN-TEST
10 permit icmp host 10.1.1.1 host 10.1.1.2
20 permit icmp host 10.1.1.2 host 10.1.1.1 (100 hw matches)
Count/block packet using L2-ACL on Attachment ckt :-

ethernet-services access-list L2VPN-MAC-ACL

10 permit host e4c7.227c.1be6 host 8478.ac63.eb52 ………………. These are CE’s MAC address.
20 permit host 8478.ac63.eb52 host e4c7.227c.1be6
30 permit any any
!
interface GigabitEthernet0/1/0/38.2 l2transport
ethernet-services access-group L2VPN-MAC-ACL ingress
ethernet-services access-group L2VPN-MAC-ACL egress
!
RP/0/RSP0/CPU0:router1#show access-lists ethernet-services L2VPN-MAC-ACL hardware ingress location 0/1/cpu0

ethernet-services access-list L2VPN-MAC-ACL

10 permit host e4c7.227c.1be6 host 8478.ac63.eb52 (100 hw matches)
20 permit host 8478.ac63.eb52 host e4c7.227c.1be6

RP/0/RSP0/CPU0:router1#show access-lists ethernet-services L2VPN-MAC-ACL hardware egress location 0/1/cpu0

Fri Jul 7 22:33:23.224 EDT
ethernet-services access-list L2VPN-MAC-ACL
10 permit host e4c7.227c.1be6 host 8478.ac63.eb52
20 permit host 8478.ac63.eb52 host e4c7.227c.1be6 (100 hw matches)
 IRB/BVI :- BVI ?

• communication within bridge domain or broadcast domain is

possible
but what if CE want's to go out side of this broadcast domain (
like internet) , in that case BVI is required.

BVI is a L3 interface that plugs into a bridge-domain in order to

route packets in and out of the bridge-domain.
• It does not support bridging itself, but acts as a gateway for
the corresponding bridge-domain to a routed interface within the
router.
IRB/BVI :- THE BVI CANNOT UNDERSTAND THE TAG AND DROPS THE PACKETS.
interface GigabitEthernet0/1/0/38.2 l2transport interface GigabitEthernet0/1/0/3.2 l2transport
encapsulation dot1q 2 encapsulation dot1q 2
rewrite ingress tag pop 1 symmetric rewrite ingress tag pop 1 symmetric
G0/1/0/39.2 G0/1/0/38.2 G0/1/0/3.2
R2 G0/1 R3
R1
Te0/2/0/4.2

Te0/0/1/0.2 interface TengigE0/2/0/4.2 l2transport

l2vpn encapsulation dot1q 2
R4
bridge group customer1 rewrite ingress tag pop 1 symmetric
bridge-domain engineering
interface Tengige0/2/0/4.2
!
interface GigabitEthernet0/1/0/38.2
!
interface GigabitEthernet0/1/0/3.2 Interface te0/0/1/0.2
! ip address 10.1.1.3 255.255.255.0
routed interface BVI100
! Default-gateway = 10.1.1.100
interface bvi 100 OR
ipv4 address 10.1.1.100/24 Ip route 0.0.0.0 0.0.0.0 10.1.1.100

• With IRB, if the host want to go outside of the bridge domain, they can be L3 routed via BVI
interface to the other L3 interfaces.
BVI Key points to remember :-
• Only one BVI can be configured in any bridge domain.
The same BVI can not be configured in multiple bridge domains.

• A BVI is associated with a single bridge domain and represents the link between the bridging and
the routing domains on the router ( bridge between L2-domain and L3-domain ).

• A BVI follows traditional interface VLAN rules. It will not come up unless there is an active
attachment circuit in the same bridge domain that it is bound to.

• Note: BVI interfaces do not support VLAN tags; so in order for

the BVI to handle the ingress traffic on the EFP, the complete
VLAN tag must be popped on ingress using rewrite ingress tag pop 1
symmetric
RP/0/RSP0/CPU0:router1#show route | in BVI100
C 10.1.1.0/24 is directly connected, 00:00:57, BVI100
L 10.1.1.100/32 is directly connected, 00:00:57, BVI100

RP/0/RSP0/CPU0:router1#show ip int br | in Loopback159

Loopback159 159.159.159.2 Up Up default
From PE –
RP/0/RSP0/CPU0:router1#ping 10.1.1.1
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

From CE – default is configured at CE pointing towards BVI100

R RP/0/RSP0/CPU0:router2#ping 159.159.159.2 source gigabitEthernet 0/1/0/39.2
Sending 5, 100-byte ICMP Echos to 159.159.159.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/21 ms
 IRB/BVI :-

router ospf 100

area 0
<..skip>
!
interface BVI100 <<<<< called BVI under OSPF

!
!

Remote router :-

P/0/RSP0/CPU0:router-5#show ip route ospf | in 10.1.1.0

O 10.1.1.0/24 [110/2] via 169.2.2.1, 00:07:37, GigabitEthernet0/0/0/9

RP/0/RSP0/CPU0:router-5#ping 10.1.1.1

Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms

RP/0/RP0/CPU0:ASR9912-A#show adjacency BVI
Service card for BVI interfaces on node 0/RP0/CPU0

MPLS packets: Slot 0/4/CPU0 VQI 0x1bc

Non-MPLS packets: Slot 0/4/CPU0 VQI 0x1bc

----- Service Card List -----

0/RP0/CPU0 VQI: Not Applicable

0/RP1/CPU0 VQI: Not Applicable

0/0/CPU0 VQI: Not Applicable

0/1/CPU0 VQI: Not Applicable

0/2/CPU0 VQI: 0x15c

0/3/CPU0 VQI: Not Applicable

0/4/CPU0 VQI: 0x1bc

0/5/CPU0 VQI: 0x21c

• All packets from a host on a bridged interface go to the BVI if the destination MAC address matches the BVI MAC address. Otherwise, the
packets are bridged.
 QUIZ :-
Q-1 Do we support VLAN tagging on BVI interfaces ?

1. Yes
2. No

Q-2 which command is used to remove single the VLAN tag and passed the untagged
frame to BVI ?

1. rewrite ingress tag translate 1 symmetric

2. rewrite egress tag pop 1 symmetric
3. rewrite ingress tag push 1 symmetric
4. rewrite ingress tag pop 1 symmetric
 MULTIPOINT SERVICES:
VPLS

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 22
Virtual Private VLAN Service :- is a Layer 2 service that interconnects multiple sites
and emulates a LAN or VLAN across an MPLS or IP network.
VPLS provides the ability to combine bridge-domains at multiple sites into one large bridge-domain through
MPLS PWs using VFI.
VFI creates the bridging domain among all ACs and PWs. Packets received on one attachment circuit are
switched to other attachment circuits or PWs based on the destination MAC address.

When a packet is received on a PW, it has an MPLS label. The MPLS label is used to select the bridge domain
associated with the PW. The packet is forwarded to one of the attachment circuits depending on the destination
MAC address.
Note :- packet received on a PW is not forwarded back to another PW because split-horizon is enabled by default
on the VFI. The reason for this is that there is a full mesh PW between PE routers of an emulated LAN.

When a packet is received on a PW and the destination MAC address is not known, then
the packet is forwarded to all attachment circuits. The same is true if either a broadcast or
multicast packet is received on a PW.

Split horizon rule -- A full mesh of PWs is required in order to ensure that each host can receive traffic from all
other hosts. The consequence is that a VPLS PE does not forward a frame received on a VPLS PW over its
other VPLS PWs to avoid loop , because core MPLS is not running spanning-tree.
Split Horizon on VPLS – we need full mesh of pseudowires
 frame is received from Core
• don’t forward back to core
• Forward it to edge or attachment ckt.
 VPLS CONFIGURATION interface TenGigE0/0/0/16.100 l2transport
interface GigabitEthernet0/0/0/16.100 l2transport encapsulation dot1q 100
encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric
rewrite ingress tag pop 1 symmetric

190.225.250.50 19.1.1.1
G0/1 Te 0/0/0/16.100
CE1 G0/0/0/16.100 MPLS G0/1 CE3
PE1 PE3

l2vpn
bridge group VPLS-TEST l2vpn
33.20.2.92 bridge group VPLS-TEST
bridge-domain L2VPN
interface GigabitEthernet0/0/0/16.100 bridge-domain L2VPN
PE2 interface TenGigE0/0/0/16.100
!
G 0/0/1/11.100 !
vfi L2VPN-VFI
neighbor 19.1.1.1 pw-id 999 vfi L2VPN-VFI
! neighbor 33.20.2.92 pw-id 999
neighbor 33.20.2.92 pw-id 999 CE2 !
neighbor 190.225.250.50 pw-id 999
l2vpn
bridge group VPLS-TEST
bridge-domain L2VPN
interface GigabitEthernet0/0/1/11.100 l2transport
interface GigabitEthernet0/0/1/11.100 encapsulation dot1q 100
! rewrite ingress tag pop 1 symmetric
vfi L2VPN-VFI
neighbor 19.1.1.1 pw-id 999
!
neighbor 190.225.250.50 pw-id 999
Once we commit the config we will see full mesh of pseudowire
RP/0/RSP0/CPU0:ASR9001-I#show l2vpn bridge-domain group VPLS-TEST brief
Mon Jul 10 11:13:31.660 EDT
Legend: pp = Partially Programmed.
Bridge Group:Bridge-Domain Name ID State Num ACs/up Num PWs/up
-------------------------------- ----- -------------- ------------ -------------
VPLS-TEST:L2VPN 5 up 1/1 2/2

RP/0/RSP0/CPU0:ASR9001-I#show l2vpn bridge-domain group VPLS-TEST

Mon Jul 10 11:17:22.587 EDT
Legend: pp = Partially Programmed.
Bridge group: VPLS-TEST, bridge-domain: L2VPN, id: 5, state: up, ShgId: 0, MSTi: 0
Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
Filter MAC addresses: 0
ACs: 1 (1 up), VFIs: 1, PWs: 2 (2 up), PBBs: 0 (0 up)
List of ACs:
Gi0/0/0/16.100, state: up, Static MAC addresses: 0
List of Access PWs:
List of VFIs:
VFI L2VPN-VFI (up)
Neighbor 19.1.1.1 pw-id 999, state: up, Static MAC addresses: 0
Neighbor 33.20.2.92 pw-id 999, state: up, Static MAC addresses: 0
RP/0/RSP0/CPU0:ASR9001-I#show l2vpn forwarding bridge-domain VPLS-TEST:L2VPN detail location 0/0/cpu0
Bridge-domain name: VPLS-TEST:L2VPN, id: 5, state: up

GigabitEthernet0/0/0/16.100, state: oper up

Number of MAC: 1
Statistics:
packets: received 1, sent 11
bytes: received 60, sent 660
Storm control drop counters:
packets: broadcast 0, multicast 0, unknown unicast 0
bytes: broadcast 0, multicast 0, unknown unicast 0
Dynamic arp inspection drop counters:
packets: 0, bytes: 0
IP source guard drop counters:
packets: 0, bytes: 0 Nbor 33.20.2.92 pw-id 999 <<<<<<<<
Number of MAC: 0
Nbor 19.1.1.1 pw-id 999 <<<<<<<
Statistics:
Number of MAC: 1
packets: received 0, sent 1
Statistics:
bytes: received 0, sent 60
packets: received 1, sent 1
Storm control drop counters:
bytes: received 60, sent 60
packets: broadcast 0, multicast 0, unknown unicast 0
Storm control drop counters:
bytes: broadcast 0, multicast 0, unknown unicast 0
packets: broadcast 0, multicast 0, unknown unicast 0
Dynamic arp inspection drop counters:
bytes: broadcast 0, multicast 0, unknown unicast 0
packets: 0, bytes: 0
Dynamic arp inspection drop counters:
IP source guard drop counters:
packets: 0, bytes: 0
packets: 0, bytes: 0
IP source guard drop counters:
packets: 0, bytes: 0
RP/0/RSP0/CPU0:ASR9001-I#show l2vpn forwarding bridge-domain VPLS-TEST:L2VPN mac-
address location 0/0/cpu0
Mon Jul 10 11:37:19.624 EDT
To Resynchronize MAC table from the Network Processors, use the command...
l2vpn resynchronize forwarding mac-address-table location <r/s/i>

Mac Address Type Learned from/Filtered on LC learned Resync Age

Mapped to
--------------------------------------------------------------------------------
6c9c.ed3f.0f38 dynamic Gi0/0/0/16.100 0/0/CPU0 0d 0h 0m 16s N/A
e4c7.227c.1be6 dynamic (19.1.1.1, 999) 0/0/CPU0 0d 0h 0m 9s N/A

RP/0/RSP0/CPU0:ASR9001-I#show mpls forwarding | in "BD|Bytes"

Mon Jul 10 11:59:32.657 EDT
Local Outgoing Prefix Outgoing Next Hop Bytes
16025 Pop PW(19.1.1.1:999) BD=5 point2point 64
16026 Pop PW(33.20.2.92:999) BD=5 point2point 0
Quiz :-

Q3 :- Why VPLS requires a logical full mesh of pseudowire on the participating

Provider Edge (PE) routers ?

1. For redundancy
2. For faster convergence
3. Due to split-horizon which is enabled by default on the VFI.
4. frame received on one pseudowire will never be forwarded to other pseudowires.
 Sample VPLS Configuration :- IOS-XR , IOS-XE and Nexus

#NEXUS VPLS CONFIG.

feature evc
feature mpls l2vpn
!
interface Ethernet2/1
# IOS-XE service instance 1 ethernet
encapsulation dot1q 100
#IOS-XR
!
interface GigabitEthernet 0/0/2 l2vpn vfi context foo
interface GigabitEthernet0/0/0/16.100 service instance 100 ethernet vpn id 100
l2transport
encapsulation dot1q 100
encapsulation dot1q 100 member Pseudowire12
! member Pseudowire13
rewrite ingress tag pop 1 symmetric
!
! l2vpn vfi context VPLS-A interface Pseudowire12
l2vpn vpn id 100 encapsulation mpls
bridge group VPLS-TEST member 1.1.1.1 encapsulation mpls neighbor 10.2.2.2 100
bridge-domain L2VPN
member 2.2.2.2 encapsulation mpls !
interface GigabitEthernet0/0/0/16.100
! interface Pseudowire13
!
encapsulation mpls
vfi L2VPN-VFI bridge-domain 100 neighbor 10.3.3.3 100
neighbor 1.1.1.1 pw-id 100 member vfi VPLS-A !
neighbor 2.2.2.2 pw-id 100
member GigabitEthernet0/0/2 service-instance 100 bridge-domain 100
! member vfi foo
member Ethernet2/1 service instance 1
VPLS AUTO-DISCOVERY
AND SIGNALING ( KOMPELA )
Autodiscovery and Signaling :-
When you add a new VPLS PE to the network, configure the PE in order to have a PW to all existing PEs in each of
its local bridge-domains. All existing PEs must then be reconfigured in order to have a PW to the new PE because
all PEs must be fully meshed. This might become an operational challenge as the number of Pseudowires and
bridge-domains increase.
One solution is to have PEs discover other PEs automatically through BGP.

Manual configuration changes add operational costs and increase the chance of network mis-configuration.
VPLS Auto Discovery eliminates the need to manually provision a VPLS neighbor. VPLS auto discovery
automatically detects when new PEs are added or removed from the VPLS domain.

In order to discover other PEs through BGP, each PE is configured for the vpls-vpws address-family and
advertises in BGP the bridge-domains in which they want to participate. Once the other PEs that are part of
the same bridge-domain are discovered, a PW is established to each of them. BGP is the protocol used for this
autodiscovery.
There are two options for the signaling of the PW to the autodiscovered PEs: BGP and LDP.
• There are two primary functions of the VPLS control plane:
VPLS Autodiscovery :- A means for a PE to learn which remote PEs are members of a
given bridge domain.
VPLS Signalling - A means for a PE to learn the pseudowire label expected by a given
remote PE for a given VPLS.
Both of these functions are accomplished with a single BGP Update advertisement in
case of BGP signaling.

BGP needs to distribute NLRI for the VPLS bridge domain with the PE as the BGP next-
hop and appropriate VE-ID.
Additionally, the VPLS is associated with one or more BGP export Route Targets (RTs)
that are also distributed (along with NLRI). VPLS SAFI NLRI uses AFI = 25 and SAFI =
65.
VPLS CONFIGURATION – BGP SIGNALING l2vpn
bridge group BG_100
router bgp 65000 bridge-domain BD_100
Vpn-id and the route-target are the same on the different PEs for each bridge-domain, but each PE has a
address-family l2vpn vpls-vpws interface Bundle-Ether100.100
unique Virtual Edge ID (VE-ID).
!
Each PE discovers the other PEs in the VPN through BGP and uses BGP to signal !the PWs.
neighbor x.x.x.x vfi VFI_100
update-source loopback0
interface Bundle-Ether100.100 l2transport vpn-id 100 #should be same
encapsulation dot1q 100 remote-as 65000 autodiscovery bgp
rewrite ingress tag pop 1 symmetric address-family l2vpn vpls-vpws rd 100:2
! route-target 100:100
signaling-protocol bgp
ve-id 1 # should be unique
!
RP/0/RSP0/CPU0:ASR9001-D#show bgp l2vpn vpls summary
BGP router identifier 10.37.30.29, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 51
BGP NSR Initial initsync version 32 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.

Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer

Speaker 51 51 51 51 51 0

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

159.159.159.2 0 111 7965 8021 51 0 0 1d01h 1
159.159.159.3 0 111 8393 8382 51 0 0 5d18h 1
RP/0/RSP0/CPU0:ASR9001-D#show l2vpn discovery bridge-domain
Bridge group: BG_100, bridge-domain: BD_100, id: 32, signaling protocol: BGP
List of Local Edges (1 Edges):
Local Edge ID: 1, Label Blocks (1 Blocks)
Label base Offset Size Time Created
---------- ------ ---- -------------------
24045 1 10 09/02/2020 09:17:43
List of Remote Edges (2 Edges):
Remote Edge ID: 2, NLRIs (1 NLRIs)
Label base Offset Size Peer ID Time Created
---------- ------ ---- --------------- -------------------
24060 1 10 159.159.159.2 09/07/2020 02:40:20
Remote Edge ID: 3, NLRIs (1 NLRIs)
Label base Offset Size Peer ID Time Created
---------- ------ ---- --------------- -------------------
24015 1 10 159.159.159.3 09/02/2020 09:27:30
RP/0/RSP0/CPU0:ASR9001-D#show l2vpn bridge-domain bd-name BD_100
Legend: pp = Partially Programmed.
Bridge group: BG_100, bridge-domain: BD_100, id: 32, state: up, ShgId: 0,
MSTi: 0
Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
Filter MAC addresses: 0
ACs: 1 (1 up), VFIs: 1, PWs: 2 (2 up), PBBs: 0 (0 up), VNIs: 0 (0 up)
List of ACs:
BE100.100, state: up, Static MAC addresses: 0, MSTi: 1
List of Access PWs:
List of VFIs:
VFI VFI_100 (up)
Neighbor 159.159.159.2 pw-id 1000, state: up, Static MAC addresses: 0
Neighbor 159.159.159.3 pw-id 1000, state: up, Static MAC addresses: 0
RP/0/RSP0/CPU0:ASR9001-D#show bgp l2vpn vpls
BGP router identifier 10.37.30.29, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 51
BGP NSR Initial initsync version 32 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Network Next Hop Rcvd Label Local Label

Route Distinguisher: 100:1 (default for vrf BG_100:BD_100)
*> 1:1/32 0.0.0.0 nolabel 24045
*>i2:1/32 159.159.159.2 24060 nolabel
*>i3:1/32 159.159.159.3 24015 nolabel
Route Distinguisher: 100:2
*>i2:1/32 159.159.159.2 24060 nolabel
Route Distinguisher: 100:3
*>i3:1/32 159.159.159.3 24015 nolabel
RP/0/RSP0/CPU0:ASR9001-D#show bgp l2vpn vpls rd 100:2 2:1/32
BGP routing table entry for 2:1/32, Route Distinguisher: 100:2
Versions:
Process bRIB/RIB SendTblVer
Speaker 50 50
Last Modified: Sep 7 02:40:22.633 for 1d01h
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
111 4323
159.159.159.2 (metric 3) from 159.159.159.2 (169.1.1.6)
Received Label 24060
Origin IGP, localpref 100, valid, internal, best, group-best, import-
candidate, not-in-vrf
Received Path ID 0, Local Path ID 0, version 50
Extended community: L2VPN:19:0:1500 RT:100:100
Block Size:10

Extended Communities are Encap type is 19 (VPLS) , MTU , RT

VPLS CONFIGURATION – LDP SIGNALING

10.0.0.1 10.0.0.3
G0/1 MPLS G0/1/0/3
CE1 G0/0/0/1 G0/1 CE3
PE1 PE3

l2vpn l2vpn
bridge group customer1 bridge group customer1
bridge-domain VLAN2 bridge-domain VLAN2
interface GigabitEthernet0/0/0/1.2 interface GigabitEthernet0/1/0/3.2
! !
vfi TAC vfi TAC
vpn-id 3 vpn-id 3
autodiscovery bgp autodiscovery bgp
rd auto rd auto
route-target 0.0.0.1:13 route-target 0.0.0.1:13
signaling-protocol ldp signaling-protocol ldp
vpls-id 65000:1 vpls-id 65000:3
! !
router bgp 65000 router bgp 65000
address-family l2vpn vpls-vpws address-family l2vpn vpls-vpws
! !
neighbor 10.0.0.3 neighbor 10.0.0.1
address-family l2vpn vpls-vpws address-family l2vpn vpls-vpws
A PE router advertises an identifier through BGP for each VPLS instance.
This identifier is unique within the VPLS instance and acts like a VPLS ID.
The identifier enables the PE router, receiving the BGP advertisement, to identify the VPLS associated
with the advertisement, and import it to the correct VPLS instance.
In this manner, for each VPLS, a PE router learns which other PE routers are members of the VPLS.

The LDP protocol is used to configure a pseudowire to all other PE routers.

The FEC 129 standard is used for signaling. The information carried by FEC 129 includes the VPLS ID,
the Target Attachment Individual Identifier (TAII) and the Source Attachment Individual Identifier (SAII).
The LDP advertisement also contains the inner label or VPLS label that is expected for incoming traffic over
the pseudowire.

RFC 4761 - Virtual Private LAN Service (VPLS) Using BGP

Control Plane. - BGP
Data Plane – LDP labels ( targeted LDP session between PE’s )
H-VPLS
 WHY H-VPLS?

• Potential signaling overhead U-PE – User-PE , N-PE – Network PE

• Full PW mesh from the Edge , as network grows • Minimizes signaling overhead
pseudowire will increase and at some point of time its
difficult to mange the pusedowires. • Full PW mesh among Core devices
• Number of pseudowire n(n-1)/2 • Packet replication done the Core
• Packet replication done at the Edge • Partitions Node Discovery process
• Node Discovery and Provisioning extends end to end
H-VPLS :- ( E-tree )
VPLS requires a full mesh of PWs between L2VPN PEs in order to ensure that any PE can reach, in one hop, a
host behind any other PE without the need for one PE to reflect frames from one PW to another PW. This is the
basis for the split horizon rule, which prevents a PE from forwarding frames from one PW to another PW. Even in
special cases, where the destination MAC address in the mac-address-table points at another PW, the frame is
dropped.

A full mesh of PWs means that the number of PWs might become very high as the number of PEs grows, so
this might introduce scalability issues.

N-PE ( Network facing PE )

• runs VPLS psedowire between all N-PE’s ( Split-horizon will be on )

• runs xconnect ( P2P ) between N-PE and U-PE ( Split-Horizon will be disabled )

U-PE ( user facing PE )

• run xconnect ( P2P ) between N-PE and U-PE

Note :- split horizon will be disabled on pseudowire ( xconnect ) between N-PE and U-PE but if U-PE is
multihoming to N-PE’s then we need to enable the split horizon on U-PE.
H-VPLS :-
interface TengigE0/1/0/5.2 l2transport
H-VPLS (HIERARCHICAL-VPLS)
encapsulation dot1q 2
rewrite ingress tag pop 1 symmetric
10.0.0.15 10.0.0.2 10.0.0.16
10.0.0.1
MPLS
MPLS
CE1 U-PE1 MPLS U-PE2 CE3
N-PE1 N-PE2

l2vpn
l2vpn
xconnect group customer1
xconnect group customer1
p2p VLAN2
p2p VLAN2
interface TengigE0/1/0/5.2
interface TengigE0/0/0/0.2
neighbor 10.0.0.1 pw-id 15
neighbor 10.0.0.2 pw-id 16
l2vpn
bridge group customer1 l2vpn
bridge-domain VLAN2 bridge group customer1
neighbor 10.0.0.15 pw-id 15 bridge-domain VLAN2
vfi customer1-VLAN2 neighbor 10.0.0.16 pw-id 16
neighbor 10.0.0.2 pw-id 2 vfi customer1-VLAN2
neighbor 10.0.0.3 pw-id 2 neighbor 10.0.0.1 pw-id 2
neighbor 10.0.0.4 pw-id 2 neighbor 10.0.0.3 pw-id 2
neighbor 10.0.0.4 pw-id 2
 H-VPLS (HIERARCHICAL-VPLS)

10.0.0.15 10.0.0.2 10.0.0.16

10.0.0.1
MPLS
MPLS
U-PE1 MPLS U-PE2 CE3
CE1 N-PE1 N-PE2

 A user Provider Edge (U-PE) device has ACs to the CEs.

 The U-PE device transports the CE traffic over an MPLS point-to-point PW to a network Provider Edge (N-
PE) device.
 The N-PE is a core VPLS PE that is fully meshed with other N-PEs.
 The U-PE is not part of the mesh with the other N-PEs, so the N-PE can consider the access PW as an AC
and forward traffic from that access PW to the core PWs that are part of the VPLS full mesh.
 The core PWs between N-PEs are configured under a VFI in order to ensure that the split horizon rule is
applied to all the core PWs configured under the VFI.
 Access PWs from U-PEs are not configured under a VFI, so they do not belong to the same SHG as the VFI
PWs. Traffic can be forwarded from an access PW to a VFI PW and vice versa.
VPLS MULTIHOMING
We don’t have support for VPLS multihoming , we have alternate solutions
available currently (such as MSTP, MC-LAG or + nv-Cluster ) but best solution
is eVPN for multihoming.

VPLS multihoming – using MC-LAG

https://techzone.cisco.com/t5/ASR-9000/Whitepaper-for-VPLS-
Multihoming-solution-using-MC-LAG-on-ASR9k/ta-p/1593684
VPLS CONFIGURATION
router–bgp
BGP
65000 SIGNALING
l2vpn
bridge group BG_100
address-family l2vpn vpls-vpws
bridge-domain
Vpn-id and the route-target are the same on the different PEs for each bridge-domain, but each PEBD_100
has a
!
unique Virtual Edge ID (VE-ID). interface Bundle-Ether100.100
neighbor x.x.x.x
Each PE discovers the other PEs in the VPN through BGP and uses BGP to signal !the PWs.
update-source loopback0
vfi VFI_100
remote-as 65000
interface Bundle-Ether100.100 l2transport vpn-id 100 #should be same
encapsulation dot1q 100 address-family l2vpn vpls-vpws
autodiscovery bgp
rewrite ingress tag pop 1 symmetric !
rd 100:2
route-target 100:100
signaling-protocol bgp
ve-id 1 # should be unique
!

redundancy
iccp
group 100
mlacp node 1
mlacp system mac 0111.0111.0111
mlacp system priority 1
member
interface Bundle-Ether100 neighbor 159.159.159.2
ipv4 address 162.1.1.1 255.255.255.0 !
backbone
no shutdown interface GigabitEthernet0/0/0/10
!
!
!
CHALLENGES WITH VPLS CONFIGURATION
1) traffic loop for multihoming solution
2) duplicate traffic on multihoming CE-1 from remote-PE-3
3) forwarding table inconsistency on remote-PE(PE3) once received frame from PE1 and PE2.
VPLS ADVANCE
FEATURES
Features Enhancement
Traffic Storm Control :- In an L2 broadcast domain, there is the risk that a host might misbehave and send a
high rate of broadcast or multicast frames that must be flooded everywhere in the bridge-domain. Another risk is
creation of an L2 loop (that is not broken by spanning tree), which results in broadcasts and multicasts packets
looping. A high rate of broadcasts and multicasts packets impacts the performance of the hosts in the broadcast
domains.

Traffic storm control is not supported on a bundle AC interfaces or VFI PWs, but is supported on non-bundle ACs
and access PWs.

l2vpn
bridge group customer1
bridge-domain engineering
interface GigabitEthernet0/1/0/3.2
storm-control unknown-unicast pps 10000
storm-control multicast pps 10000
storm-control broadcast pps 1000
!
neighbor 10.0.0.15 pw-id 15
storm-control unknown-unicast pps 10000
storm-control multicast pps 10000
storm-control broadcast pps 1000
!
vfi customer1-engineering
neighbor 10.0.0.10 pw-id 2
!
neighbor 10.0.0.12 pw-id 2
!
RP/0/RSP0/CPU0:router2#sh l2vpn bridge-domain bd-name engineering det
Legend: pp = Partially Programmed.
Bridge group: customer1, bridge-domain: engineering, id: 5, state: up,
<snip………..>
ACs: 1 (1 up), VFIs: 1, PWs: 5 (5 up), PBBs: 0 (0 up)
List of ACs:
AC: GigabitEthernet0/1/0/3.2, state is up
<snip…………..>
Storm Control:
Broadcast: enabled(1000)
Multicast: enabled(10000)
Unknown unicast: enabled(10000)
Static MAC addresses:
Statistics:
packets: received 251295, sent 3555258
bytes: received 18590814, sent 317984884
Storm control drop counters:
packets: broadcast 0, multicast 0, unknown unicast 0
bytes: broadcast 0, multicast 0, unknown unicast 0
Dynamic ARP inspection drop counters:
packets: 0, bytes: 0
IP source guard drop counters:
packets: 0, bytes: 0
<snip>
MAC Moves :- constant MAC moves often indicate network instability, such as
severe instability during an L2 loop. The MAC address security feature lets you
report MAC moves and take corrective actions such as shutting down an offending
port.

l2vpn
bridge group customer1
bridge-domain engineering
mac
secure
action none
logging
!
!

LC/0/0/CPU0:Dec 13 13:38:23.396 : l2fib[239]:

%L2-L2FIB-5-SECURITY_MAC_SECURE_VIOLATION_AC : MAC secure in AC
GigabitEthernet0_0_0_4.1310 detected violated packet - source MAC:
0000.0000.0001, destination MAC: 0000.0001.0001; action: none
Flow Aware Transport (FAT) label :- RFC6391

For L3VPN -- If the data immediately after the bottom label starts with 0x4 or 0x6, an MPLS P router assumes that
there is an IPv4 or IPv6 packet inside the MPLS packet and tries to loadbalance based on a hash of the source and
destination IPv4 or IPv6 addresses extracted from the frame.

L2VPN – load balancing happens on bottom label, All traffic from one PW follows the same path,
so out-of-order packets do not occur, but this might lead to congestion on some links in case of high bandwidth PWs.
Once Flow lable is configure both PE will agree on it while negotiating the session.
With the FAT PW feature, the ingress L2VPN PE inserts one bottom MPLS label per src-dst-mac or per src-dst-ip.
The MPLS core routers (between the PEs) does hashing based on bottom label ( FAT)
This generally provides much better bandwidth utilization in the core unless a PW carries only a small number of
src-dst-mac or src-dst-ip conversations.

The traffic from one PW is loadbalanced over multiple paths in the core when available.
Application traffic does not suffer from out-of-order packets because all traffic from the same source (MAC or IP)
to the same destination (MAC or IP) follows the same path.

E.g. – customer may complain that bundle is not doing load balancing ( one particular link is carrying very high
traffic compare to other links ). Reason may be one particular L2VPN is carrying very high traffic and based on
bottom label hash it will stick to one particular link. , Soln is FAT label.
 RP/0/RSP0/CPU0:ASR9001-I(config-l2vpn-pwc-mpls)#load-balancing flow ?
l2vpn both Insert/Discard Flow label on transmit/recceive
pw-class fat-pw code Flow label TLV code
receive Discard Flow label on receive
encapsulation mpls transmit Insert Flow label on transmit
control-word RP/0/RSP0/CPU0:ASR9001-I(config)#l2vpn load-balancing flow ?
load-balancing src-dst-ip Use source and destination IP addresses for hashing
src-dst-mac Use source and destination MAC addresses for hashing
flow-label both
!
!
!
bridge group customer1
bridge-domain engineering
vfi customer1-engineering
neighbor 10.0.0.11 pw-id 2
pw-class fat-pw