CCIE SPv4 - MPLS L2VPN - VPWS, EPL, AToM

Software versions:
IOS XE 15.5
IOS XR 5.3

The topology for this demo:

In this post we will be taking a look at the various ways to configure the basic L2VPNs available today. A L2VPN, or Layer 2 Virtual Private Network is a way for the Service Provider to "extend" layer 2 traffic over the WAN without the need to physically trench cables for a P2P connection. This technology leverages the existing MPLS network the provider already built. We'll start off with the Port based configuration in this post. 

The port based configuration is the physical interface of the PE to CE connection or the attachment circuit or AC isn't being used to multiplex connectivity for the customer. We'll take a look at that later in another post. We are focused on just the aspect of bridging the customer traffic over the provider core. 

The first configuration we'll take a look at is the "xconnect" feature. This is configured on the interface facing the customer. We need to point the xconnect to the PE that has the AC to the customer on the remote end. In our demo, R3 and R5 will act as PEs. R7 and R9 are configured in the same subnet 10.7.9.0/24 and should be able to ping each other when complete. Let's test to make sure it's not working now.

We will also take a look at AToM/EPL on IOS XR. That setup will be between XR1 and R3. The data plane is NOT supported here, but the control plane is. You can setup the AC between the PE and CE but no data will flow between the PEs. This is just a platform limitation of the XRv RSP, but not of the real ASR9K, CRS or other XR platform. 

R7#ping 10.7.9.9

Type escape sequence to abort.

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

.....

Success rate is 0 percent (0/5)

R7

interface GigabitEthernet1

 ip address 10.7.9.7 255.255.255.0

end

R9#sh run

interface GigabitEthernet1

 ip address 10.7.9.9 255.255.255.0

end

Before we actually configure the pseudowire or layer 2 VPN between R3 and R5, let's double check that R3 and can reach R5's loopback when sourced of it's own loopback, ensuring R5 also can reach R3.

R3#ping 192.168.1.5 source lo0

Type escape sequence to abort.

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

Packet sent with a source address of 192.168.1.3

!!!!!

R3#traceroute 192.168.1.5 source lo0 num

Type escape sequence to abort.

Tracing the route to 192.168.1.5

VRF info: (vrf in name/id, vrf out name/id)

  1 10.3.4.4 [MPLS: Label 403 Exp 0] 2 msec 1 msec 1 msec

  2 10.4.5.5 1 msec *  1 msec

OK, now on to the reason why we are here. One thing to note is that you can't place the "xconnect'' on an interface that has an IP address assigned.

R3

interface GigabitEthernet2

 no ip address

 xconnect 192.168.1.5 79 encapsulation mpls

R5

interface GigabitEthernet2

 no ip address

 xconnect 192.168.1.3 79 encapsulation mpls

So let's break this down: 
The xconnect is the "bridge'' configuration that signals the creation of a pseudowire to be created in IOS.
The IP address is the pointer towards the remote PE. Just like in L3 VPN we have VPNv4 iBGP peerings between the PEs. Same concept applies here, R5 is the LSP endpoint for R3's pseudowire. 
The encapsulation mpls dictates that to get from R3 to R5 or R5 to R3 use the MPLS encapsulated LSP between the PEs.


R5
%LINEPROTO-5-UPDOWN: Line protocol on Interface pseudowire0, changed state to up

R3
%LDP-5-NBRCHG: LDP Neighbor 192.168.1.5:0 (2) is UP


Let's verify that the PW or pseudowire is actually up. There are several verification options, we'll take a look at a few, the first is the "L2 VPN CLI" output, which is used more frequently that the second on "xconnect" output. The show very similar outputs.

R3#show l2vpn atom vc vcid 79

                                       Service
Interface Peer ID         VC ID      Type   Name                     Status
--------- --------------- ---------- ------ ------------------------ ----------

pw100003  192.168.1.5     79         p2p    Gi2-8                    UP


R3#show xconnect all
Legend:    XC ST=Xconnect State  S1=Segment1 State  S2=Segment2 State
  UP=Up       DN=Down            AD=Admin Down      IA=Inactive
  SB=Standby  HS=Hot Standby     RV=Recovering      NH=No Hardware

XC ST  Segment 1                         S1 Segment 2                         S2
------+---------------------------------+--+---------------------------------+--

UP pri   ac Gi2:8(Ethernet)              UP mpls 192.168.1.5:79               UP

As you can see the configuration worked as is up and running. CAVEAT, the configuration here on the CSR1000v will support control plane and data plane forwarding. IOS XRv only supports the control plane. You'll notice that (Ethernet) is in parenthesis, this indicates this is a port level configuration. We are not looking for VLAN IDs or other types of traffic. This is severely limiting for an ISP which is why we will take a look at more scalable configuration in other posts. 

Let's see if R7 can ping/trace to R9 now.
R7#ping 10.7.9.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.7.9.9, timeout is 2 seconds:
.!!!!

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

It works! now let's trace and see what it looks like.

R7#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.7.9.7                -   000c.29ba.0e21  ARPA   GigabitEthernet1

Internet  10.7.9.9               32   000c.29bb.45ef  ARPA   GigabitEthernet1

We can see in the ARP output that R7 sees R9's MAC address populated.


R7#traceroute 10.7.9.9 num
Type escape sequence to abort.
Tracing the route to 10.7.9.9
VRF info: (vrf in name/id, vrf out name/id)

  1 10.7.9.9 16 msec *  1 msec

Notice how it shows only one hop, that's because the ISP is taking the incoming packets and forwarding them over the provider core inside MPLS. 

Let's verify the provider core now.

R3#show mpls forwarding-table
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface

302        No Label   l2ckt(2)         0             Gi2        point2point
318        403        192.168.1.5/32   0             Gi1.34     10.3.4.4

The connection to the customer is Pont2Point for a reason, it's an AC. I included the label values that R3 will use to get to R5 with. 

Let's take a look at a wireshark and output to show what's going on behind the scenes. 

As you can see, only the ICMP data is captured. We can verify that the LSP is getting used by seeing the amount of bytes switched on R4.

R4#  show mpls forwarding-table

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop

Label      Label      or Tunnel Id     Switched      interface

402        No Label   192.168.1.3/32   24984         Gi1.34     10.3.4.3

403        Pop Label  192.168.1.5/32   25209         Gi1.45     10.4.5.5

R3 MPLS L2 Transport verification.

R3#show mpls l2transport vc detail

Local interface: Gi2 up, line protocol up, Ethernet up

  Destination address: 192.168.1.5, VC ID: 79, VC status: up

    Output interface: Gi1.34, imposed label stack {403 509}

You can see by the bolded label values that label 403 is used by R3 to get to R4,

R5#sho mpls l2transport vc 79 detail

Local interface: Gi2 up, line protocol up, Ethernet up

  Destination address: 192.168.1.3, VC ID: 79, VC status: up

    Output interface: Gi1.45, imposed label stack {402 302}

You can see by the bolded label values that label 402 is used by R5 to get to R4,

This is effectively the most basic implementation of L2 VPN in a P2P configuration. 

So when we look at this from IOS XR is a slightly different way of doing things. On XR, you have to explicitly define an interface for Layer 2 connectivity with the "l2transport" command, this is done on the "physical" for "Port" mode EPL. You can do this on the subinterface for EVPL, but in my testing, EVPL on XRv isn't supported. 

XR1

interface GigabitEthernet0/0/0/2

 l2transport

The "l2transport" indicates this interfaces will be used for layer 2 services.

When you have this enabled, this will allow you to map the G0/0/0/2 to the "xconnect" setup under the "l2vpn" configuration mode. In my configuration, I try to make it "obvious" what I am trying to work on, like labeling the xconnect group "Port".

l2vpn

 !

 xconnect group PORT

  p2p R12_R7

   interface GigabitEthernet0/0/0/2

   neighbor ipv4 192.168.1.3 pw-id 127

The "p2p" indicates this configuration will involve a point to point connection rather than the "mp2mp" which is more any to any like VPLS. Then you map the AC (G0/0/0/2) to the neighbor PE that terminates the other end of the PW. 

R3

Legacy "xcconnect'' configuration

interface GigabitEthernet2

 xconnect 192.168.1.11 127 encapsulation mpls

R3#sho xconnect all

Legend:    XC ST=Xconnect State  S1=Segment1 State  S2=Segment2 State

  UP=Up       DN=Down            AD=Admin Down      IA=Inactive

  SB=Standby  HS=Hot Standby     RV=Recovering      NH=No Hardware

XC ST  Segment 1                         S1 Segment 2                         S2

------+---------------------------------+--+---------------------------------+--

UP pri   ac Gi2:8(Ethernet)              UP mpls 192.168.1.11:127             UP

As you can see, not much configuration under the interface. You could configure this with the "L2 VPN Protocol CLI" if you choose to do so. 

R3
New "L2 VPN Protocol CLI"

interface pseudowire127
 encapsulation mpls
 neighbor 192.168.1.11 127
l2vpn xconnect context PORT
 member pseudowire127

 member GigabitEthernet2

R3#sh l2vpn atom vc vcid 127

                                       Service
Interface Peer ID         VC ID      Type   Name                     Status
--------- --------------- ---------- ------ ------------------------ ----------

pw127     192.168.1.11    127        p2p    PORT                     UP

R3#show xconnect all

Legend:    XC ST=Xconnect State  S1=Segment1 State  S2=Segment2 State

  UP=Up       DN=Down            AD=Admin Down      IA=Inactive

  SB=Standby  HS=Hot Standby     RV=Recovering      NH=No Hardware

XC ST  Segment 1                         S1 Segment 2                         S2

------+---------------------------------+--+---------------------------------+--

UP pri mpls 192.168.1.11:127             UP   ac Gi2:8(Ethernet)              UP

As you can see, not very difficult to get working. You'll notice that up to this point, I haven't been integrating anything IPv6. For MPLS support for IPv6 is slim unless your trying to do 6PE or 6VPE. That's why I didn't include it in the MPLS specific posts. I'll update this post with IPv6 outputs for completeness soon, then moving forward IPv6 will be included everywhere. 

The control plane is all that works, the dataplane won't forward data. This is a limitation of the XRv platform for L2 services. It's speculated that the XRv9K supports L2 services in the dataplane but I have not succeeded in making it work in my testing. I'll add in XRv configuration if the control plane works, if I can't get it working following the documentation, I simply chock it up to a lack of support and move on. CSR1000v appears to support all L2 services, some limitations on PBB L2 services, we'll focus on what works and not what doesn't. 

Thanks for stopping by!
Rob Riker, CCIE #50693