Show 102 – A Layer of Indirection: Is MPLS Tunneling?

Greg Ferro and Ethan Banks dive into a deep, dark hole of nerdery with Ivan PepelnjakMarko Milivojevic, and Petr Lapukov to see if we can decide whether or not MPLS is tunneling. We plumb the depths of packet and frame formatting, compare and contrast various technologies, toss different scenarios around, contradict one another, and throw buckets of cold water all over the place. In the end, we think we have an answer. So put the kids to bed, cram in your earbuds, and visualize the virtual whiteboard. Close your eyes…focus…there it is! All that’s missing is the smell of dry erase markers.

What We Talk About

In the witty opening banter, we find out Greg is an Interop judge, Petr works on something called “Bing”, and Marko is teaching the first CCIE ever a thing or two. Oh, and who WAS the first CCIE anyway? Hint – not our friend Terry. Not quite. From here, the show gets serious, and includes the following topics:

  1. Foundations: circuits vs. connections vs connectionless.
  2. How is a tunnel different from a virtual circuit?
  3. How do we say that a circuit has “state”?
  4. We could think of a tunnel as “a layer of forwarding indirection”.
  5. The tricky business of distinguishing between the OSI model (classical layering) vs. what we normally consider tunnels.
  6. Now wait a minute…could MPLS be considered NAT in a certain sense?
  7. So…maybe a tunnel is tunnel when you see the same protocol twice in the header.
  8. Redefining a tunnel as “a layer of frozen interaction”.
  9. MPLS is not exactly L2 or L3. It’s a total layering violation.
  10. How do CRC checks impact our definition of tunneling?
  11. Isn’t it time for a new networking model?

Once we’ve hammered through all of that, we loop back around to review why we had the chat. The question comes back up – why are we reinventing the wheel in data center networking? Couldn’t an MPLS application be written to do many of the same things the explosion of overlay protocols are doing? Or would we have scalability problems?


Ethan Banks
Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 3M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks
Ethan Banks
Ethan Banks
  • Alexandra Stanovska

    Oh dear, Slavic mafia striking again 😀

  • Damian


  • Hakim

    I was hoping to listen to some more practical scenarios when discussing the encapsulation/layering… Ivan should have given more time to elaborate on this. I do like his insights. 

    Perfect work guys!


  • Michael Kantowski

    Any encapsulation is basically tunnelling… You can say UDP payloads are tunnelled over IP.  IP can be tunnelled over ethernet.

    I think a “tunnel” is defined by the endpoints at which the “new” encapsulation begins and where it ends.  So for example, in the UDP tunnelled over IP example, your endpoints are the two computers that are communicating.  In the case of MPLS, the tunnel starts where the tag is pushed and ends where the tag is popped.

    Overall, we are tunnelling all the time.  We just have many different choices and the tunnels begin and end and various points on the end to end path.

  • Billy

    Not a question directed at the bulk of the discussion, but I was quite interested in the short discussion held towards the end of the podcast where Greg was talking about social media networks and the ramifications.

    Greg, could you please reply and let me know which book it was exactly that you were reading? I’d be interested in purchasing it for my own reading.


    • Etherealmind

      Hi Billy, The book is Social Network Analysis for Startups

      Ethan and I talk more about this in an upcoming show which might be worth a listen.


      • Billy

        Nice! Thanks Greg.

        All packet pusher shows are worth a listen. Multiple times over. =)

  • riw777

    The way I see it is… As long as you have something at layer 3 riding on something else at layer 3, or something at layer 2 riding on something at layer 3, you have a tunnel. With this in mind, you have a number of ways of looking at MPLS. If you’re just running IP->MPLS->Ether, then you might be able to say it’s not a tunnel, just a “shim transport.” But the moment you put it like this: IP->MPLS->MPLS->Ether –you’re talking about a tunnel, just like you would be with IP->IP->Ether. If you have IP->Ether->MPLS->Ether, you’re back in tunnel land, as well.

    So, MPLS can be implemented so it’s not a tunnel. But in the real world, it almost never is –there’s always an inner and outer header, and there is sometimes something other than a network transport layer protocol inside, which means tunnel.

  • Ahmed

    Great show! We need more discussions like this

  • Mikkel Markussen

    I dislike the way Greg and Ethan’s arguments near 23:30 were dismissed.

    You don’t need to be aware of the destination before you shove an Ethernet frame onto the network. Your network doesn’t even have to be aware of it. No discovery has to be made prior to transmission, because end point location awareness in Ethernet is achieved by snooping and flooding.

    Marco makes the case that ARP is a prerequisite for transmitting Ethernet, and that this constitutes stateful endpoint discovery, but ARP is a resolution protocol for IP, and deals with mapping layer 3 addresses to layer 2 addresses, which is necessary only when you’re trying to address devices on a layer 2 network with layer 3 addresses. Even if the case is made that there’s no sense in arguing Ethernet without IP, because it doesn’t really happen, then this argument still doesn’t stick, as ARP is still a mechanism for address discovery, and not endpoint or path discovery.

    What Greg ends up defining isn’t the difference between tunnelled and non-tunnelled traffic, but the difference between circuit switching and packet switching, so Marco’s counter-argument really seems to end up being that Ethernet is circuit switching.