Encapsulating, shim headers, tunnelling – does it matter?

I overheard my manager today giving one of the new junior guys the run-down on basic encapsulation methods and general IP. Basically, how to TCP/IP. In explaining 802.1Q and VLAN tagging, my boss uttered the following phrase:

“…a switch encapsulates the frame with the VLAN number…”

It was at that point I ran over to his desk and put in my point (a bit of semantics, especially for a newbie) that technically, a 802.1Q tag actually modifies the Ethernet header and is more like a shim header.


An 802.1Q frame

But then GRE and IP tunnelling was brought up. And MPLS. And IPSec. And after much debate, I let the coaching continue and probably caused quite a bit of confusion for my green colleague. I’ve come to realize that I tend to fly off the handle and get a bit too far in a technical discussion that I lose those who might not have learnt or had exposure to the technology that myself and others know intimately.

Anyways, onto the whole encap-vs-tunnel-vs-shim debate. Here’s how I like to explain it and understand it myself as it applies generally:

  • encapsulation distinctly divides bits on the wire. When viewing a packet in Wireshark for example, an IP packet is encapsulated in an Ethernet header and an IP header, followed by whatever transport protocol (TCP, UDP or ICMP), and then finally application data. Encapsulation forms the basic structure of data packets, with a clear division of labor. Routers inspect IP headers for destination networks. Switches inspect Ethernet headers for destination MAC addresses.
  • tunnels utilize tunnel and multiple IP headers to create overlay networks riding over underlying infrastructure. GRE (with IPSec for encryption) is the most widely used tunnelling mechanism. It works great for connecting remote sites over the Internet. Internet routers only inspect the outer IP header, which is routed to the tunnel endpoint, at which point the far-end will strip the outer IP and GRE headers, and then make its own routing decisions base on the “inside” IP header. MPLS* also functions in a similar way for VPN applications.
  • shim headers are the muddiest of the bunch. MPLS is often called a shim header because it inserts a small 40 byte header within a data packet, which is then processed and/or inspected by MPLS-enabled routers. It also doesn’t have only one location where it could appear. In the case of pure IP L3VPNs, it’s shimmed between inner- and outer IP headers. It could also appear between disparate Layer 2 headers, in the case of Any Transport over MPLS (AToM). 802.1Q is further harder to define since it modifies existing Ethernet headers. A frame could have multiple .1Q tags in the case of dot1q tunnelling (confused yet?).

And yet, after writing those short descriptions of each, it’s apparent to me that all of those terms are muddy. You can’t always define a data type as one over the other, since you’ll find numerous exceptions and special use cases (that are not so special and very widely deployed) that break any rigidly-defined “layering rules”. Smarter people than me have agreed to that fact as it relates to explaining TCP and using dated reference models such as the OSI model. The IETF has also agreed that reference models
that adhere to strict onion layers as it relates to data networks hurts more than it helps.

But I digress. The concepts of encapsulation/decapsulation and tunnelling are central concepts that all networks use. Never will you (or should you) see an end host spit out an IP packet without its data link header (mostly Ethernet these days) along with its IP header and any associated transport/application data. It’s just the way TCP/IP evolved over its development several decades ago. And it’s the best we got. Sometimes, it’s less important about terminology and semantics, and more important of the overall goal said method is trying to achieve.

If I’m grossly mistaken, be sure to let me know in the comments. I’ll try my best not to harass anyone less technical and nerdy than myself with (sometimes) unimportant details.

CCIE or bust! And other going-on’s

The time has come…

I’ve finally made the committed decision to pursue my number for CCIE Routing and Switching. Like most folks in networking, I’ve gotten to the point where I’m feeling quite confident in my skills; solid foundations with just a few cobwebs here and there to knock out (mostly due to re-focusing). This decision has come to me after moving on from my VAR support job, which covered the entire breadth of Cisco but prevented my skills from becoming specialized, to a network engineer doing implementation for a financial org. Since I’m settling in to the new job, I’ve come to realize that all the nitty-gritty routing and switching bits are what interest me the most. Sure, I’ve done a bit of this and a bit of that in other areas (mostly in wireless and data center) but I’m an R&S guy.

Which brings me to my next bit of personal news – I’ve now gone from support to implementation. For those in the NOC’s or VAR’s, I would highly recommend it as a next step after you’ve gotten your feet wet in the trenches of support. It’s nice to learn what happens when things break and how to resolve issues, however, in my humble opinion, in order to have that deep understanding, you have to be there to know *why* something is configured or designed a certain way. Delving into the world of real-world business challenges and requirements, as well as ITIL and change management (ugh, how I loathe thee…a “necessary evil” some may say), I know get to make decisions on how my network looks and how it functions to accomplish a certain goal. Whatever those goals may be, such as a new project or business requirement. For those who are looking to move up in the world of networking, implementation is required experience.

So, while I haven’t been blogging much here (seriously, just so much to learn and write about…some may say too much!), I will be focusing on hitting the books and lab prep. I’m shooting for a Q2 2014 target. Wish me luck!

PS: There are so many good blogs out there with CCIE “notes” – however, I could start banging out tidbits here and there for things that stump me or just bother me…More to come.

On preventing burn out and spreading yourself too thin

Networking is full of what I like to call “rabbit holes”. You start looking into a technology or a solution and before you know it, you’ve lost hours of time pouring over white papers, best-practice design guides, sample configurations, blog posts and labs. There’s a lot of pieces that make up the networks that we work with daily, from QOS to routing, switching, WAN, hardware architectures, protocols…the list goes on and on. Depending on your role in your organization, you could be working with a few technologies and platforms very intimately or you could be spread across multiple parts of the overall infrastructure.

Working for a VAR for multiple vendors, I find it difficult sometimes to find a middle ground between knowing enough about the equipment and environments we support to solve the problems our customers have, what’s to come from the vendors and getting the expert knowledge I crave. In the last year alone, I’ve touched probably everything under the sun from our lovely vendors, including data center gear, wireless, security and SP (only missing voice). While I certainly know a lot more than I did a year ago, I also find that I’m unable to really dive into any one part in particular.

Like I said, its highly dependent on your role in your organization. I’m sure there’s a lot of folks out there that would love to get away from the hundreds of ASA’s they support or the 6500’s that are still chugging along in their campus core (*shudder*) and wiring closets to get their hands on something new. A compromise between both extremes is, in my opinion, a sweet spot.

I’m constantly challenged, engaged on new projects and new solutions, realizing customer goals and solving complex technical issues. I just warn to my fellow networking colleagues that it’s very easy to spread yourself too thin. I find myself having to stop myself from sticking my nose into every new thing that comes into my office, just so that I can focus on what’s on my plate.

Don’t get me wrong, I’m loving the challenge and wouldn’t want to work in any other part of our IT industry. I just want to avoid being that “jack of all trades, master at none“. With all the new technologies coming out (especially in the data center), you got to keep your head above water from drowning in all the stuff that puts everything together.

Maybe it’s time for a change of pace or at least a change in attitude. I’m currently back reviewing my R&S to possibly put myself on the coveted path of the CCIE lab (I actually had a dream/nightmare about getting thrown into the lab exam…it was exciting but terrifying at the same time). I just hope that I don’t spread out too thin that I burn out. I’m sure we’ve all been there at some point or another.

I’d love to hear your thoughts on this so please leave a comment or send a tweet my way. In the meantime, keeping plumbing!

PS: I love Ivan’s post about knowledge and complexity. Given the nature of this post, I find it rings true to home/work a lot. Great advice from Mr. Pepelnjak as always.