# L2TPv3: first tests #

In this article I want to review some basic L2TPv3 features. If you are familiar with Any Transport Over MPLS (AToM) and Pseudowire emulations understanding L2TPv3 should be easy, because the wanted target when using AToM or L2TPv3 is essentially the same, in other words you want a method to extend Layer2 connectivity over either an MPLS backbone (in the case of AToM) or a pure IP Backbone (in the case of L2TPv3).

The basic elements for reaching this target are Pseudowires in both cases. In the case of AToM, Pseudowires are bidirectional logical entities that are made of TWO unidirectional Label Switched Paths (LSPs) between two remote PEs. In this case a Two Level Stack of MPLS labels will work to give you an Outer Label (aka the Tunnel Label or IGP/LDP label, or RSVP/TE label if MPLS Traffic-Engineering is used) and a Inner Label identifying the Virtual Channel (VC) (aka the VC Label) that extends the L2 connectivity between sites (read here for some basic AToM scenario).

In the case of L2TPv3, we have no labels, but in a similar way we’ll have an outer Tunnel Encapsulation that transports the original L2 frame inside it. Now, when I was reading some L2TPv3 stuff at the beginning (reference this book (“L2 VPN architectures“), as I did, if you want a very detailed description about L2TPv3) I understood that I need a pure IP backbone to use it, but at the same time I was thinking that not too many Service Providers (SPs) are using only IP today, then to do some tests I built a little bit consistent scenario where three remote sites of a generic enterprise need to be connected at L2 level through an MPLS SP’s backbone, and L2TPv3 will be built over the IP connectivity provided with an MPLS L3 VPN service. The topology I will use is the one shown in the following figure:

l2tpv3-topology

We have a central HUB site, connected via L3 MPLS/VPN service to two remote sites. The VPN is configured in HUB/SPOKE configuration, that is only the HUB can talk to the spokes, no traffic can pass directly between spokes. Inside this VPN, only the Loopbacks of CEs will be exchanged via BGP:

NOTE: I named CEs as CEx-vPEx because these routers will act as PEs router inside the private enterprise’s network from a L2VPN point of view.

CE1-vPE1#show ip route bgp | b Gate
Gateway of last resort is not set
99.0.0.0/32 is subnetted, 3 subnets
B        99.0.0.3 [20/0] via 10.0.0.77, 00:47:29
B        99.0.0.4 [20/0] via 10.0.0.77, 00:47:29

CE2-vPE2#show ip route bgp | b Gate
Gateway of last resort is not set
99.0.0.0/32 is subnetted, 3 subnets
B        99.0.0.3 [20/0] via 10.0.0.81, 00:49:01
B        99.0.0.4 [20/0] via 10.0.0.81, 00:49:01

CE3-vPE3#sh ip route bgp | b Gate
Gateway of last resort is not set
99.0.0.0/32 is subnetted, 3 subnets
B        99.0.0.1 [20/0] via 10.0.0.93, 00:50:46
B        99.0.0.2 [20/0] via 10.0.0.93, 00:50:42

CE4-vPE4#show ip route bgp | b Gate
Gateway of last resort is not set
99.0.0.0/32 is subnetted, 3 subnets
B        99.0.0.1 [20/0] via 10.0.0.97, 01:08:23
B        99.0.0.2 [20/0] via 10.0.0.97, 01:08:19

The enterprise doesn’t want other L3 info exchanged over the SP’s network and decides to build its own Overlay IP backbone using a DMVPN solution that uses two clouds. Then the Enterprise IP Backbone will become as shown here:

l2tpv3-dmvpn

Then servers’ administrators ask network team to stretch the Layer2 connectivity between the servers located at HUB site and the remote server, the solution should grant a point-to-point ethernet service between central servers and remote servers as shown in the following picture:

l2tpv3-logicall2

The picture should describe the wanted communication paths between the servers, S1 must talk to S3 and S4 on Vlans 101 and 102, S2 must talk to S3 and S4 on Vlan 201 and 202, S3 and S4 cannot talk to each other on any Vlans. The desidered beahviour is reached stretching the L2 Vlans by means of L2TPv3, the following picture should show how.

l2tpv3-pws

I configured 8 PWs on both remote routers CE3-vPE3 and CE4-vPE4, these 8 PWs are divided in two groups of 4 PWs that go to the 2 different HUB routers over the DMVPN tunnels for redundancy reasons, every Vlans of remote servers have then two available paths to reach the central servers.

Of course this could not be the best solution from a scalability point of view because you need two links for every group of PWs terminated at each HUB routers.

Let’s see how is configured one of this L2TPv3 Pseudowire.

l2tpv3-conf

Not considering for a moment that we are building a L2TPv3 circuit over a DMVPN over an MPLS/L3VPN, the configuration is quite simple, you need to configure a pseudowire-class that uses a local interface (in this case the DMVPN Tunnel) and use the xconnect command to target the remote DMPVN HUB (That in this case is the remote peer terminating the L2TPv3 circuit).

Now, let’s try to go deeper inside L2TPv3 protocol operations. The operational model of L2TPv3 can be represented as shown in the following picture (reference L2 VPN ARCHITECTURES)

l2tpv3-model

The control channel (known as L2TP Tunnel in IOS terms) controls Pseudowires (known as L2TP sessions in IOS terms) creation, removal and teardown, in addition to provide with negotiation, detection and keepalive mechanisms. The control channel is optional, this means that you can create L2TPv3 Pseudowires without using a dynamic control signaling (in this case you need to manually specify L2TP sessions (PWs) attributes). Given that the control channel is optional, you can have three different mode of Control Plane Operations in L2TPv3:

1) Manual Mode ==> Needs predefined Sessions (PWs) IDs.
2) Manual Mode with Keeaplive ==> Negotiate the Control Connection phase but not the Session Negotiation Phase
3) Dynamic Mode ==> Negotiate both Control Connection and Session Negotiation

The generic structure of a L2TPv3 Control frame can be described as show here:

l2tpv3-controlframeformat

The signaling of the control channel works in two phases:

1) Control Connection Establishment
2) Session Establishment ==> This establishes Pseudowires

Phase 1) begins with a three-way-handshake message exchange represented below:

l2tpv3-3way

The SCCRQ message is sent as soon as the remote peer is configured. Below you can see some outputs showing the status of the L2TPv3 signaling before activating the DMVPN clouds (all DMVPN Tunnels on CEx-vPEx are in shutdown)

CE1-vPE1#show l2tun tunnel
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is hardware calendar, *09:34:39.713 CET Thu Dec 15 2016
%No active L2TP tunnels

CE1-vPE1#show l2tun tunnel
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is hardware calendar, *09:34:40.704 CET Thu Dec 15 2016
L2TP Tunnel Information Total tunnels 1 sessions 0
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
Count VPDN Group
3457022636 0                        wsccrp 99.0.0.11       0     l2tp_default_cl

CE1-vPE1#show l2tun tunnel
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is hardware calendar, *09:34:48.416 CET Thu Dec 15 2016
L2TP Tunnel Information Total tunnels 1 sessions 0

LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
Count VPDN Group
3457022636 0                        shutdn 99.0.0.11       0     l2tp_default_cl

CE1-vPE1#show l2tun tunnel
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is hardware calendar, *09:37:42.080 CET Thu Dec 15 2016
L2TP Tunnel Information Total tunnels 2 sessions 0
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
Count VPDN Group
2828345584 0                        shutdn 99.0.0.9        0     l2tp_default_cl
3656548549 0                        wsccrp 99.0.0.9        0     l2tp_default_cl

When the xconnect command is configured with right informations, CE1-vPE1 starts to try to contact the remote peers, for this routers peers are 99.0.0.11 (DMVPN Tu41 on CE4-vPE4) and 99.0.0.9 (DMVPN Tu31 on CE3-vPE3),

CE1-vPE1#sh run | s xcon
xconnect 99.0.0.11 10103 encapsulation l2tpv3 pw-class CE-vPE
xconnect 99.0.0.11 20103 encapsulation l2tpv3 pw-class CE-vPE
xconnect 99.0.0.11 10203 encapsulation l2tpv3 pw-class CE-vPE
xconnect 99.0.0.11 20203 encapsulation l2tpv3 pw-class CE-vPE
xconnect 99.0.0.9 10101 encapsulation l2tpv3 pw-class CE-vPE
xconnect 99.0.0.9 20101 encapsulation l2tpv3 pw-class CE-vPE
xconnect 99.0.0.9 10201 encapsulation l2tpv3 pw-class CE-vPE
xconnect 99.0.0.9 20201 encapsulation l2tpv3 pw-class CE-vPE

but since there is no IP connectivity over the DMVPN clouds (all tunnels are in shut) the status of the L2TP Tunnel (the control channel) flaps between some states:

1] No active tunnels
2] wsccrp ==> Wait for Start Control Connection Reply ==> CE1-vPE1 sent a SCCRQ to the peer
3] shutdown ==> the reply doesn’t come in, after a timeout CE1-vPE1 deletes local state about the control session it was trying to establish, removing allocated LocTunID
4] CE1-vPE1 starts again the cycle allocating a new LocTunID and sending a new SCCRQ message to the peer.

The same thing happens on other CEx-vPEx routers. As soon as DMVPN cloud become active, the three-way-handshake can complete and two control sessions (L2TP Tunnels) will be established on each CEx-vPEx, we have two sessions because on each router we have TWO L2TPv3 peers (the peers defined in the xconnect commands) independently from how many Pseudowires are configured toward a single remote peer (in my case 4 PWs for each L2TPv3 peer)

CE1-vPE1#sh l2tun tunnel
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is hardware calendar, *10:00:11.695 CET Thu Dec 15 2016
L2TP Tunnel Information Total tunnels 2 sessions 4
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
                                                           Count VPDN Group
1702918756 4156337381 CE4-vPE4      est    99.0.0.11       0     l2tp_default_cl
2410642474 3789595332 CE3-vPE3      est    99.0.0.9        4     l2tp_default_cl

CE1-vPE1#sh l2tun tunnel
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is hardware calendar, *10:00:57.374 CET Thu Dec 15 2016
L2TP Tunnel Information Total tunnels 2 sessions 8
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
                                                           Count VPDN Group
2410642474 3789595332 CE3-vPE3      est    99.0.0.9        4     l2tp_default_cl
2951893505 805688764  CE4-vPE4      est    99.0.0.11       4     l2tp_default_cl

The keyword “tunnel” in the command “show l2tun” filters for us only the control channel information, but we can see that, as part of the control session establishment, the “Sessn Count” counter starts to increase, this counter counts the number of PWs created by the specific control channel sessions, in this case at the end of the process we reach the value of 4 PWs for each Control Channel Session, PWs are created in the Second Phase of Control Channel Establishment, that is, routers build a Control Session first, then they use the created session to activate the configured PWs.

Let’s see how the real packets are, capturing the control channel messages on my test network.

l2tpv3-3way-packets

Looking at the above picture it’s possible to find the connection IDs assigned locally by each L2TPv3 peer and sent to the remote peer. Each message has many Attribute Value Pairs (AVPs) used for different functions, for example you can notice among others Hostname AVP, Router-ID AVP, Tie-breaker AVP (only in SCCRQ mesasge). For example, L2TPv3 implementation should be coded in such a way that only ONE Control Channel Session exists between two peers, it could happen that each peer starts the Control Connection Request concurrently, in this case each peer that receives a SCCRQ message checks if a SCCRQ message has been sent to the peer, if yes the peer checks the value sent in its Tie-Breaker AVP that contains a random generated number, comparing this value with the one received by the peer; the lower value wins and the “loser router” should drop its initiated connection. Router-ID AVP can be used instead to identify a router for control connection setup, tie breaking, and/or tunnel authentication (Read RFC 3931 from a full detailed description of the diiferent AVPs). The picture should give an idea of the messages exchanged during Phase 1) of the Control Channel Session and correlates the different Control Connection IDs with the IDs you can find looking at some show commands from your routers (LocTunID and RemTunID). If you notice rapid changing in these values it’s most likely that you have a problem with your L2TPv3 Control Session.

Here I’ve done things in a correct way so my Control Session are established and stable. I can now activate the Pseudowires (Phase 2 of the Control Session). Let’s see what the peers trying to do when the Control Session is up and we have already configured the PWs, but no Attachment Circuit is active yet (all the subinterfaces terminating the L2 circuits to extend on CEx-vPEx are shutdown), the command to look at for checking Control information about PWs is “show l2tun sessions” as already said “sessions” in IOS terms means PWs (while “tunnels” means Control Sessions)

#######   NOTE   #######
You will see different Control Sessions IDs in next outputs, because while writing I had to restart some times my test environment, but at this level what a control session is and how its messages are exchanged should be clear. Below you can find the new IDs for the Control Sessions:

CE1-vPE1#show l2tun tunnel
L2TP Tunnel Information Total tunnels 2 sessions 8
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
                                                           Count VPDN Group
102723315  1444491787 CE4-vPE4      est    99.0.0.11       4     l2tp_default_cl
693553882  3213023170 CE3-vPE3      est    99.0.0.9        4     l2tp_default_cl

CE2-vPE2#show l2tun tunnel
L2TP Tunnel Information Total tunnels 2 sessions 8
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
                                                           Count VPDN Group
1809819245 2267040803 CE3-vPE3      est    99.0.0.17       4     l2tp_default_cl
1877243060 391712093  CE4-vPE4      est    99.0.0.19       4     l2tp_default_cl

CE3-vPE3#show l2tun tunnel
L2TP Tunnel Information Total tunnels 2 sessions 8
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
                                                           Count VPDN Group
2267040803 1809819245 CE2-vPE2      est    99.0.0.18       4     l2tp_default_cl
3213023170 693553882  CE1-vPE1      est    99.0.0.10       4     l2tp_default_cl

CE4-vPE4#show l2tun tunnel
L2TP Tunnel Information Total tunnels 2 sessions 8
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
                                                           Count VPDN Group
391712093  1877243060 CE2-vPE2      est    99.0.0.18       4     l2tp_default_cl
1444491787 102723315  CE1-vPE1      est    99.0.0.10       4     l2tp_default_cl
####### END NOTE #######

 

The following picture shows all Pseudowires configured in all routers, each router has 8 configured PWs, we can see also that routers try to signal groups of 4 PWs using one of the two active Control Sessions, for example CE3-vPE3 will signal PWs with IDs 10101,10201,20101,20201 using the Control Session with ID 3213023170;

l2tpv3-pw-sessions

Note that outputs show a Tunnel ID that is the LocTunID assigned by CE3-vPE3 to its Control Session:

CE3-vPE3#show l2tun tunnel
L2TP Tunnel Information Total tunnels 2 sessions 8
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
Count VPDN Group
2267040803 1809819245 CE2-vPE2      est    99.0.0.18       4     l2tp_default_cl
3213023170 693553882  CE1-vPE1      est    99.0.0.10       4     l2tp_default_cl

We can see that PWs are locally identified by another local LocID and remote RemID pair, RemID is 0 because attached circuits are still not active and the PWs are not fully established (their state is wtaci an acronym for “wait for attachment circuit”); I will activate the first one capturing some packets to see which are the message exchanged. From a general point of view Phase 2 of the Control Session Establishment (a.k.a Pseudowires Establishment) can be described as shown in the following picture:

l2tpv3-pws-3way

Let’s activate one pf the PWs, PW 10101 configured between CE3-vPE3 and CE1-vPE1, for the moment both Attachment Circuits (ACs) are down at both sides:

CE1-vPE1#sh run int e1/2.101 | b interface
interface Ethernet1/2.101
encapsulation dot1Q 101
shutdown
xconnect 99.0.0.9 10101 encapsulation l2tpv3 pw-class CE-vPE

CE3-vPE3#sh run int e1/2.101 | b interface
interface Ethernet1/2.101
encapsulation dot1Q 101
shutdown
xconnect 99.0.0.10 10101 encapsulation l2tpv3 pw-class HUB1

CE1-vPE1#sh int e1/2.101 | i admin
Ethernet1/2.101 is administratively down, line protocol is down

CE3-vPE3#sh int e1/2.101 | i admin
Ethernet1/2.101 is administratively down, line protocol is down

CE1-vPE1(config-if)#int e1/2.101
CE1-vPE1(config-subif)#no shut

CE3-vPE3(config-if)#int e1/2.101
CE3-vPE3(config-subif)#no shut

After some time I see:

CE1-vPE1#show l2tun session
L2TP Session Information Total tunnels 2 sessions 8
LocID      RemID      TunID      Username, Intf/      State  Last Chg Uniq ID
Vcid, Circuit
4189368413 0          102723315  20203, Et0/3.202:202 wtaci  05:01:12 0
1275221123 0          102723315  10203, Et0/3.102:102 wtaci  05:01:13 0
3794801464 0          102723315  20103, Et0/2.201:201 wtaci  05:01:13 0
2854273597 0          102723315  10103, Et0/2.101:101 wtaci  05:01:13 0
3193702682 0          693553882  10201, Et1/3.102:102 wtaci  05:01:13 0
1510766902 3351463031 693553882  10101, Et1/2.101:101 est    00:28:38 0
860305463  0          693553882  20201, Et1/3.202:202 wtaci  05:01:13 0
1738242945 0          693553882  20101, Et1/2.201:201 wtaci  05:01:13 0

CE3-vPE3#show l2tun session
L2TP Session Information Total tunnels 2 sessions 8
LocID      RemID      TunID      Username, Intf/      State  Last Chg Uniq ID
Vcid, Circuit
1182995048 0          2267040803 10202, Et1/3.102:102 wtaci  05:02:47 0
2741047630 0          2267040803 20102, Et1/3.201:201 wtaci  05:02:48 0
1849218534 0          2267040803 10102, Et1/3.101:101 wtaci  05:02:48 0
2315747320 0          2267040803 20202, Et1/3.202:202 wtaci  05:02:47 0
716269323  0          3213023170 20101, Et1/2.201:201 wtaci  05:02:47 0
3073507617 0          3213023170 10201, Et1/2.102:102 wtaci  05:02:47 0
3351463031 1510766902 3213023170 10101, Et1/2.101:101 est    00:30:11 0 
1727225366 0          3213023170 20201, Et1/2.202:202 wtaci  05:02:47 0

I see that CE3-vPE3 and CE1-vPE1 established a PW session for PW with ID 10101, the PW Session is identified by the pair of IDs 3351463031 (on CE3-vPE3), 1510766902 (on CE1-vPE1) and the Pseudowire was signaled on the Control Session identified by the pair of IDs 3213023170 (on CE3-vPE3) and 693553882 (on CE1-vPE1)

#######    NOTE    #######
If you look at other available command, for example “show l2tun session brief” you find:

CE1-vPE1#show l2tun session brief
L2TP Session Information Total tunnels 2 sessions 8
LocID      TunID      Peer-address    State     Username, Intf/
sess/cir  Vcid, Circuit
4189368413 102723315  99.0.0.11       wtaci,DN  20203, Et0/3.202:202
1275221123 102723315  99.0.0.11       wtaci,DN  10203, Et0/3.102:102
3794801464 102723315  99.0.0.11       wtaci,DN  20103, Et0/2.201:201
2854273597 102723315  99.0.0.11       wtaci,DN  10103, Et0/2.101:101
3193702682 693553882  99.0.0.9        wtaci,DN  10201, Et1/3.102:102
1510766902 693553882  99.0.0.9        est,UP    10101, Et1/2.101:101
860305463  693553882  99.0.0.9        wtaci,DN  20201, Et1/3.202:202
1738242945 693553882  99.0.0.9        wtaci,DN  20101, Et1/2.201:201

The “brief” option shows only local information about the different involved IDs, here you find for example 1510766902 LocID (PW Session assigned ID) on CE1-vPE1, and 693553882 TunID= LocTunID this taken from “show l2tun tunnel” command on CE1-vPE1. Then, don’t confuse all this entities when looking at the different outputs, LocTunID, RemTunID, LocID, RemID, TunID, I can say that the names of these identifier are not the best option for keep things clear, anyway that’s it.
#######  END NOTE  #######

Next figure shows the messages exchanged during this PW session establishment.

l2tpv3-pws-3way-packets

Looking at the above picture it’s possible to check the 3-way-handshake messages needed to signal PW establishment, you can also see a State Link Info message used by routers to communicate the status of Attachment Circuits. Without entering the specific details of every Attirbute Value Pair (AVP), to establish a PW routers use a Control Session that already exist between them and use this Control Session to exchange Local and Remote IDs that will identify this PW, it’s also possible to see the signaled Pseudowire Type in the namesake AVP. In this case the signaled PW is of type 4 (Ethernet VLAN).

Now that we have enough knowledge about Control Session and Pseudowire Establishment it’s time to send some data on the PWs. Before sending any data from server S3 to S1 their ARP tables are:

S1#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.16.101.1            –   aabb.cc00.1200  ARPA   Ethernet0/0
Internet  172.16.102.1            –   aabb.cc00.1210  ARPA   Ethernet0/1

S3#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.16.101.3            –   aabb.cc00.1130  ARPA   Ethernet0/3
Internet  172.16.102.3            –   aabb.cc00.1100  ARPA   Ethernet0/0
Internet  172.16.201.3            –   aabb.cc00.1110  ARPA   Ethernet0/1
Internet  172.16.202.3            –   aabb.cc00.1120  ARPA   Ethernet0/2

S1 and S3 know only their own IP address. Let’s check status of PW10101:

CE3-vPE3#sh l2tun session circuit vcid 10101
L2TP Session Information Total tunnels 2 sessions 8
LocID      TunID      Peer-address    Type Stat Username, Intf/
Vcid, Circuit
2680818259 281472352  99.0.0.10       VLAN UP   10101, Et1/2.101:101

CE1-vPE1#sh l2tun session circuit vcid 10101
L2TP Session Information Total tunnels 2 sessions 8
LocID      TunID      Peer-address    Type Stat Username, Intf/
Vcid, Circuit
2132379093 1312899494 99.0.0.9        VLAN UP   10101, Et1/2.101:101 

PW10101 is UP. Again, note that you see 4 different IDs in the above outputs, because that command only show you Local information at one side, for example for CE3-vPE3 LocID=2680818259 is the Local ID assigned to PW10101 and signaled over Local Control Session ID TunID=LocTunID=281472352 as visible here:

CE3-vPE3#show l2tun tunnel
L2TP Tunnel Information Total tunnels 2 sessions 8
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
Count VPDN Group
281472352  1312899494 CE1-vPE1      est    99.0.0.10       4     l2tp_default_cl
3702214141 1027194267 CE2-vPE2      est    99.0.0.18       4     l2tp_default_cl

Let’s send some ping from interface e0/3 of S3 belonging to VLAN101:

S3#ping 172.16.101.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.101.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 3/3/3 ms

After resolving ARP requests, routers populate their ARP table with the new learned MACs:

S3#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.16.101.1            0   aabb.cc00.1200  ARPA   Ethernet0/3
Internet  172.16.101.3            –   aabb.cc00.1130  ARPA   Ethernet0/3
Internet  172.16.102.3            –   aabb.cc00.1100  ARPA   Ethernet0/0
Internet  172.16.201.3            –   aabb.cc00.1110  ARPA   Ethernet0/1
Internet  172.16.202.3            –   aabb.cc00.1120  ARPA   Ethernet0/2

S1#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.16.101.1            –   aabb.cc00.1200  ARPA   Ethernet0/0
Internet  172.16.101.3            0   aabb.cc00.1130  ARPA   Ethernet0/0
Internet  172.16.102.1            –   aabb.cc00.1210  ARPA   Ethernet0/1

We can check also mac address table of the switches:

Switch3#show mac address-table vlan 101
Mac Address Table
——————————————-

Vlan    Mac Address       Type        Ports
—-    ———–       ——–    —–
 101    aabb.cc00.1130    DYNAMIC     Et0/3
101    aabb.cc00.1200    DYNAMIC     Et1/2
Total Mac Addresses for this criterion: 2

SW1#show mac address-table vlan 101
Mac Address Table
——————————————-

Vlan    Mac Address       Type        Ports
—-    ———–       ——–    —–
101    aabb.cc00.1130    DYNAMIC     Et1/2
101    aabb.cc00.1200    DYNAMIC     Et0/0
Total Mac Addresses for this criterion: 2

In the following picture you can see the broadcast arp/reply and the icmp echo/reply encapsulated in L2TPv3 packets over a DMVPN over a L3 MPLS/VPN.

NOTE: With the version of wireshark I’m using, you must force wireshark to decode the information encapsulated under L2TPv3 as Ethernet info, otherwise Wireshark is not able to decode the packet in a correct way (You will see some Cisco HDLC info with a protocol number 0xCC00), to decode as Ethernet, right click the packet choose “Decode as…” and select Ethernet as L2TPv3 payload.

l2tpv3-full-ping

You can see how original ethernet frames are transported over L2TPv3 Tunnel and how original VLAN Tag are preserved when entering the Pseudowire.

After all PWs will be up and traffic flows between the servers, they will have fully populated their arp tables in this way:

l2tpv3-completearptable