Layer 2 across Layer 3. Part 2 – EoMPLS

Continuing L2 across L3 topic started with post about L2TP.

Another easy-to-setup way to interconnect two Ethernet segments across Layer 3 network is EoMPLS, a particular case of AToM.

The diagram I used for my tests and the initial configuration are the same as in my previous post on L2TP.

Lab Diagram
Lab Diagram

 

R2 R3
interface FastEthernet0/0
  description -= WAN =-
  ip address 115.0.0.2 255.255.255.252
ip route 0.0.0.0 0.0.0.0 115.0.0.1
interface FastEthernet0/0
 description -= WAN =-
 ip address 116.0.0.2 255.255.255.252
ip route 0.0.0.0 0.0.0.0 116.0.0.1

To set up EoMPLS you need to have MPLS-enabled transport network in between the border routers. But if you don’t have this option, such as in case of interconnecting LAN segments across the internet you can just use GRE to make border routers look directly connected to each other across the tunnel. All the configurations are made for common Cisco IOS (not XE or XR).

Setting up GRE

GRE Tunnel uses outside physical interfaces IP addresses as source and destination:

GRE Tunnel
GRE Tunnel
R2 R3
interface Tunnel0
 ip address 1.1.1.1 255.255.255.252
 keepalive 1 3
 tunnel source 115.0.0.2
 tunnel destination 116.0.0.2
interface Tunnel0
 ip address 1.1.1.2 255.255.255.252
 keepalive 1 3
 tunnel source 116.0.0.2
 tunnel destination 115.0.0.2

Tunnel is up:

R3#sh ip int brief | inc Tunnel0
Tunnel0 1.1.1.2 YES manual up up

And we have R2 and R3 “directly connected”.

Setting up LDP

First, I have set up Loopback interfaces on both border routers:

R2

interface Loopback0
 ip address 2.2.2.2 255.255.255.255

R3

interface Loopback0
 ip address 3.3.3.3 255.255.255.255

To have connectivity between Loopback interfaces  I have set up OSPF (one might use static routing as well):

R2

interface Tunnel0
 ip ospf 100 area 0
interface Loopback0
 ip ospf 100 area 0

R3

interface Tunnel0
 ip ospf 100 area 0
interface Loopback0
 ip ospf 100 area 0

So now both Loopback interfaces see each other:

R2#sh ip route ospf

Gateway of last resort is 115.0.0.1 to network 0.0.0.0

3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/1001] via 1.1.1.2, 00:01:48, Tunnel0
R3#sh ip route ospf

2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/1001] via 1.1.1.1, 00:01:20, Tunnel0

R3#ping 2.2.2.2 source 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 212/222/228 ms

Enforce the LDP router-ID on both routers:

R2

mpls ldp router-id loop0 force

R3

mpls ldp router-id loop0 force

Enable label exchange over GRE Tunnel:

R2

int tunnel0
mpls ip

R3

int tunnel0
mpls ip

Now the LDP neighborship is established:

R2#sh mpls ldp neighbor
Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0
TCP connection: 3.3.3.3.64467 - 2.2.2.2.646
State: Oper; Msgs sent/rcvd: 8/8; Downstream
Up time: 00:00:12
LDP discovery sources:
Tunnel0, Src IP addr: 1.1.1.2
Addresses bound to peer LDP Ident:
116.0.0.2 3.3.3.3 1.1.1.2R2#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 3.3.3.3/32 0 Tu0 point2point

 

R3#sh mpls ldp nei
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 3.3.3.3:0
TCP connection: 2.2.2.2.646 - 3.3.3.3.64467
State: Oper; Msgs sent/rcvd: 8/8; Downstream
Up time: 00:00:32
LDP discovery sources:
Tunnel0, Src IP addr: 1.1.1.1
Addresses bound to peer LDP Ident:
115.0.0.2 2.2.2.2 1.1.1.1R3#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 2.2.2.2/32 0 Tu0 point2point

We see some label (16) in show mpls forwarding-table command output, but it’s not the the label that will be used for tunneling traffic.  There will be a few words later in this post about MPLS labels use with EoMPLS.

Now we have the following:

LDP Relationship
LDP Relationship

Setting up the EoMPLS Interconnection

Similarly to L2TPv3 we now configure the interconnection (Virtual Circuit) using xconnect.

R2

interface fastethernet2/0
xconnect 3.3.3.3 2222 encapsulation mpls

R3

interface fastethernet2/0
xconnect 2.2.2.2 2222 encapsulation mpls

Verifying

Trying ping between hosts:

R4#ping 192.168.1.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 120/143/224 ms

R5#ping 192.168.1.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 96/134/208 ms

And to the broadcast address:

R5#ping 255.255.255.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:

Reply to request 0 from 192.168.1.4, 152 ms
Reply to request 1 from 192.168.1.4, 188 ms
Reply to request 2 from 192.168.1.4, 180 ms
Reply to request 3 from 192.168.1.4, 172 ms

Checking that the Virtual Circuit is established:

R2#show mpls l2transport vc detail
Local interface: Fa2/0 up, line protocol up, Ethernet up
Destination address: 3.3.3.3, VC ID: 2222, VC status: up
Output interface: Tu0, imposed label stack {17}
Preferred path: not configured
Default path: active
Next hop: point2point
Create time: 03:38:36, last status change time: 01:26:33
Signaling protocol: LDP, peer 3.3.3.3:0 up
Targeted Hello: 2.2.2.2(LDP Id) -> 3.3.3.3
Status TLV support (local/remote)   : enabled/supported
Label/status state machine        : established, LruRru
Last local dataplane   status rcvd: no fault
Last local SSS circuit status rcvd: no fault
Last local SSS circuit status sent: no fault
Last local  LDP TLV    status sent: no fault
Last remote LDP TLV    status rcvd: no fault
MPLS VC labels: local 17, remote 17
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description: -= LAN =-
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 1382, send 1394
byte totals:   receive 140659, send 185950
packet drops:  receive 0, seq error 0, send 3
R3#show mpls l2transport vc detail

Local interface: Fa2/0 up, line protocol up, Ethernet up
  Destination address: 2.2.2.2, VC ID: 2222, VC status: up
    Output interface: Tu0, imposed label stack {17}
    Preferred path: not configured
    Default path: active
    Next hop: point2point
  Create time: 03:36:10, last status change time: 01:24:29
  Signaling protocol: LDP, peer 2.2.2.2:0 up
    Targeted Hello: 3.3.3.3(LDP Id) -> 2.2.2.2
    Status TLV support (local/remote)   : enabled/supported
      Label/status state machine        : established, LruRru
      Last local dataplane   status rcvd: no fault
      Last local SSS circuit status rcvd: no fault
      Last local SSS circuit status sent: no fault
      Last local  LDP TLV    status sent: no fault
      Last remote LDP TLV    status rcvd: no fault
    MPLS VC labels: local 17, remote 17
    Group ID: local 0, remote 0
    MTU: local 1500, remote 1500
    Remote interface description: -= LAN =-
  Sequencing: receive disabled, send disabled
  VC statistics:
    packet totals: receive 1374, send 658
    byte totals:   receive 139272, send 88278
    packet drops:  receive 0, seq error 0, send 1

In both commands output above we see Virtual Circuit ID that we have configured (2222), it’s status (Up), and the tunnel label (17). This is an actual label used in traffic “encapsulation/decapsulation”. The encapsulation itself consists in appending the label to the packet sent across the tunnel.

Looking at the ping capture between R4 and R5 we can see how the packet is formed:

ICMP Echo Request transferred over Layer 2 MPLS Tunnel
ICMP Echo Request transferred over Layer 2 MPLS Tunnel
ICMP Echo Reply transferred over Layer 2 MPLS Tunnel
ICMP Echo Reply transferred over Layer 2 MPLS Tunnel

Both captures show ICMP packet inside the Ethernet frame. Above that comes the Label 17 which we saw in show mpls l2transport vc detail command output. This is so-called VC Label that actually identifies Layer 2 interconnection. Above that comes GRE header and then IPv4 header used to deliver packet from one border router to another. This configuration theoretically can be used to establish EoMPLS interconnection across any sort of Layer 3 WAN, i.e. to perform the same task as L2TPv3 usually does.

Here are the final configurations for both routers:

R2

mpls ldp router-id Loopback0 force
!
interface FastEthernet0/0
  description -= WAN =-
  ip address 115.0.0.2 255.255.255.252
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.25
!
interface Tunnel0
 ip address 1.1.1.1 255.255.255.252
 keepalive 1 3
 tunnel source 115.0.0.2
 tunnel destination 116.0.0.2
 ip ospf 100 area 0
 mpls ip
!
interface Loopback0
 ip ospf 100 area 0
!
interface fastethernet2/0
 xconnect 3.3.3.3 2222 encapsulation mpls
!
ip route 0.0.0.0 0.0.0.0 115.0.0.1

R3

mpls ldp router-id Loopback0 force
!
interface FastEthernet0/0
 description -= WAN =-
 ip address 116.0.0.2 255.255.255.252
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Tunnel0
 ip address 1.1.1.2 255.255.255.252
 keepalive 1 3
 tunnel source 116.0.0.2
 tunnel destination 115.0.0.2
!
interface fastethernet2/0
 xconnect 2.2.2.2 2222 encapsulation mpls
 ip ospf 100 area 0
 mpls ip
!
interface Loopback0
 ip ospf 100 area 0
!
ip route 0.0.0.0 0.0.0.0 116.0.0.1

The general case

The more general use case for EoMPLS is when a service provider uses it to give Layer 2 interconnectivity to its customer. The EoMPLS VC starts at one PE router, crosses the MPLS-enabled service provider network (a number of P routers) and gets terminated at another PE router. In this case instead of GRE the MPLS transport is used. The series of labels gets attached and popped from the packet above the VC label. The network diagram I used to emulate this looks the following:

mplsbblab2

This is how ICMP echo request from R5 to R6 (192.168.1.5 to 192.168.1.6) travels across the MPLS WAN:

R1 → R2

R1R2

R2 → R3

R2R3

R3 → R4

R3R4

The packet carries two labels: the inner one identifies the VC as in previous case and the outer one is used to transport packet across the MPLS network. The outer label gets discarded on R3, because of penultimate-hop-popping so we don’t see it on R3 → R4 segment.

The outer label can easily change on the way, because it is local for each MPLS router interface. The captures above just show the case where both R1 and R2 got the same label (23) assigned for packets that are being forwarded towards 4.4.4.4/32 prefix. However it’s not always the case. Here is an example with echo reply packet going back from R6 to R5:

R4 → R3

R4R3

R3 → R2

R3R2

R2 → R1

R2R1

Outer label gets switched from 18 to 16 and then discarded on R2. The inner label stays the same.

Here is a diagram showing the packet flow for echo-request and echo-reply:

mplsbblab3flow
Packet flow with EoMPLS across MPLS WAN

Layer 2 across Layer 3. Part 1 – L2TP

Several tasks I’ve been up to recently have made me study solutions to interconnect Layer 2 network segments across Layer 3 infrastructure. I decided to do a series of quick review of the technologies that serve this purpose. The most detailed information could be found in standards and vendors documents, there is no point to rewrite all of it here. What I was intended to is just produce a sort of quick reference/cheatsheet for what I have studied.

The first is Layer 2 Tunneling Protocol.

Lab 

Here is a network diagram I used:

Lab Diagram
Lab Diagram
  • R4 and R5 represent two hosts in the same VLAN. Those are the ones that need to be interconnected across the WAN.
  • R2 and R3 represent border routers in each location.
  • R1 is just a transport WAN emulation.

Starting configuration for border routers:

R2 R3
interface FastEthernet0/0
  description -= WAN =-
  ip address 115.0.0.2 255.255.255.252
ip route 0.0.0.0 0.0.0.0 115.0.0.1
interface FastEthernet0/0
 description -= WAN =-
 ip address 116.0.0.2 255.255.255.252
ip route 0.0.0.0 0.0.0.0 116.0.0.1

The starting configuration for R1, R4 and R5 is just IP addresses assigned to interfaces according to the diagram.

The basic L2TPv3 configuration

L2TP is probably the most straightforward method to implement Layer-2 interconnection across Layer-3 WAN. Basic config looks like this:

R2

pseudowire-class test-pw-class
encapsulation l2tpv3
ip local interface FastEthernet0/0
interface FastEthernet2/0
description -= LAN =-
no ip address
xconnect 116.0.0.2 123 encapsulation l2tpv3 pw-class test-pw-class

R3

pseudowire-class test-pw-class
encapsulation l2tpv3
ip local interface FastEthernet0/0
interface FastEthernet2/0
description -= LAN =-
no ip address
xconnect 116.0.0.2 123 encapsulation l2tpv3 pw-class test-pw-class

Here is the result:

L2TPv3 Tunnel Established
L2TP Tunnel Established

All the traffic coming to FastEthernet 2/0 port of any of the border routers gets encapsulated and sent to the opposite site where it gets decapsulated while going out of another FastEthernet 2/0 interface. As a result we can ping R5 from R4 and vice versa as if they were connected directly by Layer-2 link:

R5#ping 192.168.1.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.4, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 88/98/120 ms
R4#ping 192.168.1.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/116/156 ms

The broadcast traffic also gets propagated successfully:

R4#ping 255.255.255.255
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:
Reply to request 0 from 192.168.1.5, 152 ms
Reply to request 1 from 192.168.1.5, 108 ms
Reply to request 2 from 192.168.1.5, 152 ms
Reply to request 3 from 192.168.1.5, 104 ms

Some theory

The obvious advantage of L2TP is that in order to implement it you don’t need anything but Layer 3 connectivity between devices that will terminate both ends of the tunnel.

Here is what happens to the Layer 2 Payload when it gets transferred over the tunnel:

Encapsulation Scheme
Encapsulation Scheme

First, L2TPv3 Header gets added to the original Layer 2 Frame. It contains all the information needed to identify the Tunnel and the Session.

Second IP Delivery Header containing source and destination IP addresses of the tunnel peers (in our case R2 and R3 routers) and UDP Header are added to deliver the packet to the other end device that will decapsulate it. On transport layer L2TPv3 uses port 1701.

The packet flow to establish the connection is the following:

L2TP Control Packet Flow
L2TP Control Packet Flow

Verifying 

Checking tunnel and session states:

R2#show l2tun

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
                                                           Count VPDN Group
1401476767 197244710  R3            est    116.0.0.2       1     l2tp_default_cl

LocID      RemID      TunID      Username, Intf/      State  Last Chg Uniq ID
                                 Vcid, Circuit
4141636091 3431548551 1401476767 123, Fa2/0           est    00:02:50 1

You can see the tunnel Virtual Circuit ID 123 configured and it’s state as established.

Here is a debug command showing tunnel establishment process where you can see packets related to tunnel setup marked bold. R2 plays the role of the server in this case, so the tunnel establishment process begins with it receiving SCCRQ, responds SCCRP and so on. Notice also the states the system passes through (Idle, Proc-SCCRQ, Wt-SCCN, etc.) till it gets to established.

R2#debug l2tp event
*Dec  8 23:52:23.159: L2X  tnl   08318:________: Create logical tunnel
*Dec  8 23:52:23.159: L2TP tnl   08318:________: Create tunnel
*Dec  8 23:52:23.163: L2TP tnl   08318:________:     version set to Cisco-V3
*Dec  8 23:52:23.163: L2TP tnl   08318:________:     remote ip set to 116.0.0.2
*Dec  8 23:52:23.167: L2TP tnl   08318:________:     local ip set to 115.0.0.2
*Dec  8 23:52:23.175: L2TP tnl   08318:70A47756: FSM-CC ev Rx-SCCRQ
*Dec  8 23:52:23.175: L2TP tnl   08318:70A47756: FSM-CC    Idle->Proc-SCCRQ
*Dec  8 23:52:23.179: L2TP tnl   08318:70A47756: FSM-CC do Rx-SCCRQ
*Dec  8 23:52:23.183: L2TP tnl   08318:70A47756:     class name l2tp_default_class
*Dec  8 23:52:23.191: L2TP       _____:________: Check for existing cc
*Dec  8 23:52:23.191: L2TP       _____:________:   115.0.0.2<->116.0.0.2
*Dec  8 23:52:23.195: L2TP       _____:________:   and peer router id: 116.0.0.2
*Dec  8 23:52:23.195: L2TP       _____:________:   and peer hostname: R3
*Dec  8 23:52:23.199: L2TP       _____:________:   and version: V3
*Dec  8 23:52:23.203: L2TP       _____:________:   No other cc exists to tie with
*Dec  8 23:52:23.203: L2TP tnl   08318:70A47756: FSM-CC ev SCCRQ-OK
*Dec  8 23:52:23.207: L2TP tnl   08318:70A47756: FSM-CC    Proc-SCCRQ->Wt-SCCCN
*Dec  8 23:52:23.207: L2TP tnl   08318:70A47756: FSM-CC do Tx-SCCRP
*Dec  8 23:52:23.211: L2X        _____:________: l2x_open_socket: is called
*Dec  8 23:52:23.211: L2TP tnl   08318:70A47756: Open sock 115.0.0.2:0->116.0.0.2:0
*Dec  8 23:52:23.215: L2TP tnl   08318:70A47756: FSM-CC ev Sock-Ready
*Dec  8 23:52:23.215: L2TP tnl   08318:70A47756: FSM-CC    in Wt-SCCCN
*Dec  8 23:52:23.219: L2TP tnl   08318:70A47756: FSM-CC do Ignore-Sock-Up
*Dec  8 23:52:23.355: L2TP tnl   08318:70A47756: FSM-CC ev Rx-SCCCN
*Dec  8 23:52:23.359: L2TP tnl   08318:70A47756: FSM-CC    Wt-SCCCN->Proc-SCCCN
*Dec  8 23:52:23.359: L2TP tnl   08318:70A47756: FSM-CC do Rx-SCCCN
*Dec  8 23:52:23.379: L2TP tnl   08318:70A47756: FSM-CC ev SCCCN-OK
*Dec  8 23:52:23.379: L2TP tnl   08318:70A47756: FSM-CC    Proc-SCCCN->established
*Dec  8 23:52:23.383: L2TP tnl   08318:70A47756: FSM-CC do Established
*Dec  8 23:52:23.383: L2TP tnl   08318:70A47756: Control channel up
*Dec  8 23:52:23.387: L2TP tnl   08318:70A47756:   115.0.0.2<->116.0.0.2
*Dec  8 23:52:23.431: L2X  _____:_____:________: Create logical session
*Dec  8 23:52:23.435: L2TP _____:_____:________: Create session
*Dec  8 23:52:23.435: L2TP _____:_____:________:   Using ICRQ FSM
*Dec  8 23:52:23.439: L2TP _____:_____:________: FSM-Sn ev created
*Dec  8 23:52:23.439: L2TP _____:_____:________: FSM-Sn    Init->Idle
*Dec  8 23:52:23.443: L2TP _____:_____:________: FSM-Sn do none
*Dec  8 23:52:23.443: L2TP _____:_____:________:     remote ip set to 116.0.0.2
*Dec  8 23:52:23.447: L2TP _____:_____:________:     local ip set to 115.0.0.2
*Dec  8 23:52:23.451: L2TP tnl   08318:70A47756: FSM-CC ev Session-Conn
*Dec  8 23:52:23.451: L2TP tnl   08318:70A47756: FSM-CC    in established
*Dec  8 23:52:23.455: L2TP tnl   08318:70A47756: FSM-CC do Session-Conn-Est
*Dec  8 23:52:23.455: L2TP tnl   08318:70A47756:   Session count now 1
*Dec  8 23:52:23.459: L2TP _____:08318:ECEDBDCE: FSM-Sn ev CC-Up
*Dec  8 23:52:23.459: L2TP _____:08318:ECEDBDCE: FSM-Sn    in Idle
*Dec  8 23:52:23.463: L2TP _____:08318:ECEDBDCE: FSM-Sn do CC-Up-Ignore0-1
*Dec  8 23:52:23.463: L2TP _____:08318:ECEDBDCE: Session attached
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE: FSM-Sn ev Rx-ICRQ
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE: FSM-Sn    Idle->Proc-ICRQ
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE: FSM-Sn do Rx-ICRQ
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE:   Chose application XCONNECT
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE:   App type set to XCONNECT
*Dec  8 23:52:23.471: L2TP tnl   08318:70A47756:   XCONNECT Session count now 1
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE: Remote AC is now UP
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE: XCONNECT: process AVPs
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE: Set HA epoch to 0
*Dec  8 23:52:23.475: L2TP _____:08318:ECEDBDCE:
*Dec  8 23:52:23.495: L2X  _____:_____:________: Destroying logical session
*Dec  8 23:52:23.495: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.499: L2TP 00001:08318:ECEDBDCE:   App type set to XCONNECT
*Dec  8 23:52:23.499: L2TP 00001:08318:ECEDBDCE:   Need cc version: Cisco-V3
*Dec  8 23:52:23.503: L2TP 00001:08318:ECEDBDCE:   Sequencing default tx disabled
*Dec  8 23:52:23.507: L2TP 00001:08318:ECEDBDCE:   Sequencing default rx disabled
*Dec  8 23:52:23.507: L2TP 00001:08318:ECEDBDCE: no cookies enabled
*Dec  8 23:52:23.511: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev ICRQ-OK
*Dec  8 23:52:23.511: L2TP 00001:08318:ECEDBDCE: FSM-Sn Proc-ICRQ->Wt-Tx-ICRP
*Dec  8 23:52:23.515: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Tx-ICRP-Local-Check
*Dec  8 23:52:23.515: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev Local-Cont
*Dec  8 23:52:23.519: L2TP 00001:08318:ECEDBDCE: FSM-Sn    Wt-Tx-ICRP->Wt-Rx-ICCN
*Dec  8 23:52:23.519: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Tx-ICRP
*Dec  8 23:52:23.523: L2X        _____:________: l2x_open_socket: is called
*Dec  8 23:52:23.527: L2TP 00001:08318:ECEDBDCE: Open sock 115.0.0.2:0->116.0.0.2:0
*Dec  8 23:52:23.527: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev Sock-Ready
*Dec  8 23:52:23.531: L2TP 00001:08318:ECEDBDCE: FSM-Sn    in Wt-Rx-ICCN
*Dec  8 23:52:23.535: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Ignore-Sock-Up
*Dec  8 23:52:23.555: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.559: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev DP-Setup
*Dec  8 23:52:23.559: L2TP 00001:08318:ECEDBDCE: FSM-Sn    in Wt-Rx-ICCN
*Dec  8 23:52:23.563: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Ignore-DP-Setup
*Dec  8 23:52:23.799: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev Rx-ICCN
*Dec  8 23:52:23.803: L2TP 00001:08318:ECEDBDCE: FSM-Sn    Wt-Rx-ICCN->Proc-ICCN
*Dec  8 23:52:23.807: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Rx-ICCN
*Dec  8 23:52:23.807: L2TP 00001:08318:ECEDBDCE:   MTU is 65535
*Dec  8 23:52:23.811: L2TP 00001:08318:ECEDBDCE: Session data plane UP
*Dec  8 23:52:23.815: L2TP 00001:08318:ECEDBDCE: XCONNECT: process AVPs
*Dec  8 23:52:23.819: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.839: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev ICCN-OK
*Dec  8 23:52:23.843: L2TP 00001:08318:ECEDBDCE: FSM-Sn    Proc-ICCN->established
*Dec  8 23:52:23.843: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Established
*Dec  8 23:52:23.847: L2TP 00001:08318:ECEDBDCE: Session up
*Dec  8 23:52:23.851: L2TP 00001:08318:ECEDBDCE:   115.0.0.2<->116.0.0.2
*Dec  8 23:52:23.895: L2TP 00001:08318:ECEDBDCE: XCONNECT: process AVPs
*Dec  8 23:52:23.899: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.903: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev DP-Up
*Dec  8 23:52:23.907: L2TP 00001:08318:ECEDBDCE: FSM-Sn    in established
*Dec  8 23:52:23.907: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Ignore-DP-UP

Similar packet exchange information can be seen with debug vpdn command.

In case you need to reset L2TPv3-tunnel, the following command can be used:

R2#clear l2tun remote ip 116.0.0.2