• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Tunneling Ethernet over IP

Qacer

Platinum Member
I'm having difficulty understanding how Ethernet frames can be transported over IP. First, how does it work? Does a device virtualize a physical interface and make a Layer 2 device think that it is passing the Ethernet frames to Layer 1? Second, if an Ethernet frame is 1500 bytes, how does it fit in an IP packet? Third, if an IP packet is encapsulated in an Ethernet frame and that Ethernet is then encapsulated in an IP packet, wouldn't it make sense to just use a router for an IP to IP communication?
 
First, how does it work? Does a device virtualize a physical interface and make a Layer 2 device think that it is passing the Ethernet frames to Layer 1?

Yes.

Second, if an Ethernet frame is 1500 bytes, how does it fit in an IP packet?

Ethernet frames can be smaller than 1500 bytes.

Third, if an IP packet is encapsulated in an Ethernet frame and that Ethernet is then encapsulated in an IP packet, wouldn't it make sense to just use a router for an IP to IP communication?

Tunnels are used when direct IP communication is either impossible or undesired.
 
Ethernet frames can also be split and sent via multiple IP packets and reassembled on the other end.

Another thing you assume is that everything is IP. Layer 1 / 2 only require that the datalink and physical layer of data be proper. Meaning a device on the network could run MAC address to MAC address and be "internet(working) unaware." To route this on an IP network it would need to be read off the layer 2 network, encapsulated in to Layer 3 and then sent. I think older versions of SNA worked that way.

The biggest issue is the Datalink Layer is meant to be "local" so you have to do some tricks to make it all work such as proxy arp of the remote segments and the like.
 
MTUs of larger than 1500 bytes are also possible, and are quite frequent when using Ethernet-based WAN protocols.

There are a number of reasons why this might be desirable... L2 adjacency from site-to-site over a shared network (the Internet, for instance). That's known as a layer 2 VPN. Psuedowires are one way of accomplishing this...basically, you create a psuedowire between two interfaces on a router and whatever goes in those interfaces is encapsulated (usually within MPLS) and then transmitted over the network at large and output from the interface on the other side. It functions exactly as a direct network link would.

Direct IP (L3 VPNs) is fine for most applications, but there are certain things that can't work with it. VMotion artificially requires L2 adjacency between hosts. So, if you want VMotion across sites, you'd need a L2 VPN. Even with VPLS/MetroE and separate VLANs, it may be desirable to extend this via encryption. So you would encapsulate your VMotion traffic inside MPLS over GRE over IPSec and then send that across the WAN link, rather than simply extending the L2 VLAN across the WAN link.

The tech wouldn't exist if there weren't a few applications for it. Mainly, it exists so that you can transport ANY L2 protocol over an IP link...the fact that it works with Ethernet is incidental.
 
IP packets go inside Ethernet frames.
TCP segments go inside IP Packets.

Each layer fits inside the container of the protocol below it.
 
IP packets go inside Ethernet frames.
TCP segments go inside IP Packets.

Each layer fits inside the container of the protocol below it.

Right but there are reasons to do the reverse at times. Like routing layer 2 stuff over layer 3. Like how VPN is potentially everything from layer 2 and up being packaged in to an application frame first then sent back down the stack.

Because datalink has no native internetwork abilities, you can encapsulate it in the internetworking layer and send it some where else to unencapsulate it. This makes the 2 remote sites at like layer 2 local networks.
 
Cisco's OTV extends ethernet over IP as well.
It natively stops unknown unicast-flooding, and you don't have to worry about SPT across sites, so is a better choice than EoMPLS or VPLS in many cases.
 
Back
Top