When doing some network engineering, it’s sometimes necessary to tunnel across IP-clouds. There are multiple reasons why one would use a tunnel:
- Security: You don’t want the carrier-network to see your data
- IP conflicts and/or routing issues: You want to carry private IP addresses (eg 10.0.0.0/8 in IPv4) across a public segment (eg the Internet)
- Workarounds: for whatever reason you whised that there was a connection between A and B
Technically, a tunnel consists of taking a bunch of bytes and re-packaging it. The well knows GRE-tunnel takes IP packets and encapsulates them in another IP packet. The outer IP-layer is used to carry the packet across to the other endpoint, where the inner IP-layer reappears. Other tunnels operate at different layers. SSH for example encapsulates TCP segments inside its TCP-connection; SSL-based VPN encapsulate IP packets inside their TLS-session.
Especially in the third case, workarounds, it would be very practical to be able to build a layer 2 tunnel: transport raw ethernet frames, including IEEE802.1q VLAN tags. This is called the L2TP, Layer 2 tunneling protocol. The current version (3) is defined in RFC 3931.
The Cisco website has a complete page on L2TP, in all its variants (Frame relay over MPLS, HDLC over ATM, …). I only wanted to do ethernet over IP. This is the (partial) router configuration I used. Items in bold need to be adapted on the receiving end.
pseudowire-class PW_TEST encapsulation l2tpv3 protocol none ip local interface FastEthernet0/1 ! interface FastEthernet0/0 no ip address xconnect 10.0.0.3 1 encapsulation l2tpv3 manual pw-class PW_TEST l2tp id 2 3 ! interface FastEthernet0/1 ip address 10.0.0.2 255.255.255.
This is all that is needed to tunnel every frame of Fa0/0 to 10.0.0.3 (and back). I pinged through this tunnel using both the native VLAN and a tagged vlan. Here is the resulting PCAP file. Wireshark shows the tunneled ethernet frame: