Layer 2 VPN is a large topic domain, as such, its important to cover the basics first. There are older posts breaking down some of the behind the scenes, but we are focusing on the configuration, the mapping and proving L2VPN is actually working. The goal is to basically "simulate" 2 Customer sites or 2 sites period being able to see each other over the WAN as directly connected. Historically the "xconnect" or cross connect configured under the interface facing the customer was used to bridge traffic over the SP core.
We're taking that same concept, and using newer syntax that is used to scale the L2VPN design overall. No more xconnects under the interface, rather several individual pieces tied together to extend the broadcast domain over the SP core.
There are three components used here:
1. The service instance
2. The Pseudowire interface
3. The l2vpn xconnect context
The SI or service instance creates the EFP or Ethernet Flow Point that allows highly scalable L2 services to be configured at the same time under the interface facing the customer. Instead of just bridging, EFP gives us several options to match on for enhanced flexibility. SI 1 could be used for P2P connectivity while SI 2 could be used for VPLS, while SI 3 could be used for H-VPLS, each matching on different L2 traffic.
The Pseudowire or PW as I'll reference it, is used to create a tLDP or Targeted LDP peering between the PE devices in this case. There are several options that are available under the PW construct, too many to list here. The goal is to have a dedicated construct that can be used for signaling and other options between the PEs. Remote AC or Attachment Circuit failure detection on the local PE is useful and enabled with the use of the CW or Control Word.
The L2VPN xconnect context is what connect or maps the SI to the PW to allow the PEs to communicate with each other. Like the other 2 constructs, there are many options available. The context references the SI and PW as members of the construct which pretty much just binds them together. That's a simplification of course.
Between the three components, this makes L2VPN much more scalable than just the "xconnect". So much so, that when I kickoff the CCIE SPv4 video series later this year, L2VPN will have a dedicated section. One thing to note is that L2VPN is not limited to 1 PW or context but rather several of each, and not just one AS either, Inter AS and CSC designs are supported and will be covered later, after I test them out of course.
The goal here, enable R18 and R16 to communicate with each other over AS 50693 with each router having an interface in the common subnet, 10.1.1.0/24.
R15
interface GigabitEthernet2
no ip address
negotiation auto
no keepalive
service instance 1 ethernet
encapsulation default
!
interface pseudowire1
encapsulation mpls
neighbor 192.0.2.17 1
control-word include
!
l2vpn xconnect context P2P
member pseudowire1
member GigabitEthernet2 service-instance 1
R17
interface GigabitEthernet2
no ip address
negotiation auto
no keepalive
service instance 1 ethernet
encapsulation default
!
interface pseudowire1
encapsulation mpls
neighbor 192.0.2.15 1
control-word include
!
l2vpn xconnect context P2P
member GigabitEthernet2 service-instance 1
member pseudowire1
Now that we have the PEs configured, let's verify some basic connectivity.
R17#show l2vpn atom vc
Service
Interface Peer ID VC ID Type Name Status
--------- --------------- ---------- ------ ------------------------ ----------
pw1 192.0.2.15 1 p2p P2P UP
This output simply prove that there is an active pseudowire between R15 and R17.
R17# show mpls ldp neighbor 192.0.2.15
Peer LDP Ident: 192.0.2.15:0; Local LDP Ident 192.0.2.17:0
TCP connection: 192.0.2.15.646 - 192.0.2.17.27620
State: Oper; Msgs sent/rcvd: 37/36; Downstream
Up time: 00:04:19
LDP discovery sources:
Targeted Hello 192.0.2.17 -> 192.0.2.15, active, passive
Addresses bound to peer LDP Ident:
100.64.157.15 100.64.158.15 192.0.2.15 100.64.151.15
This output shows that there is a targeted LDP peering between R15 and R17. Targeted meaning that R15 and R17 are not directly connected.
Let's test connectivity between R16 and R18.
R16
interface GigabitEthernet2
ip address 10.1.1.16 255.255.255.0
R18
interface GigabitEthernet2
ip address 10.1.1.18 255.255.255.0
The verficiation:
R16#ping 10.1.1.18
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.18, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/21/65 ms
R15#show mpls forwarding-table labels 44
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
44 No Label l2ckt(1) 647 Gi2 point2point
We'll send more pings to verify it again.
R15#show mpls forwarding-table labels 44
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
44 No Label l2ckt(1) 1217 Gi2 point2point
As you can see, there are packets being labeled switched.
