“What is a tunnel?” must rank very low on the scale of the most interesting questions in the world. Surely there are simple definitions for tunneling within the network world, right? For instance, “Anytime one packet is encapsulated inside another, the packet is being tunneled.”
Yes, simple enough—but it’s often easy to create a simple definition that’s simply wrong. To understand why the initial definition given above is wrong, examine the normal operation of network protocols as they progress up and down a network stack, as shown in Figure 12-1.
Figure 12-1 Layered Encapsulation
Within normal network protocol layering, IP packets are placed inside
Ethernet packets, TCP packets are placed inside IP packets, and some other data format is placed inside TCP packets. If we stick with the definition
“Anytime a packet is placed inside another packet, the inner packet is being tunneled,” then IP tunnels TCP, and Ethernet tunnels IP. Clearly, our
definition needs to be fine-tuned a bit to fit the real world.
Let’s try to firm this definition up by adding a condition: “Anytime one packet is encapsulated inside another packet of the same or a higher layer, the packet is being tunneled.” This is a definition we can live with, so long as we
assume each protocol can live at one (and only one) layer. In the real world, this one restriction is generally true, so this definition will work out most of the time from a packet perspective.
What about from the data plane’s perspective? Here we can use this definition: “A tunnel is a path through the network where the forwarding devices along the path do not know the actual destination of nor have visibility into the data.” It is true that in all tunneling schemes, devices forward traffic to some intermediate device that then removes an outer header and forwards the traffic again toward its real and final destination.
And the control plane? From a control plane perspective, the crucial point to remember is that there must be more than one control plane (or perhaps more than one view of the forwarding and reachability information across every link the virtual topology crosses) for a virtual topology or a tunnel to exist. To see this last rule in action, examine Figure 12-2.
Figure 12-2 Control Plane Interaction with Tunnels
Router A has three paths it can take to reach 192.0.2.0/24: (A,B,D,F), (A,C,E,F), and (A,tunnel,F). Which path should it take? How can we control which traffic enters the tunnel and which does not?
The obvious answer is, of course, that you can control which traffic enters the tunnel by modifying the metrics for various destinations. The shortest path in terms of hop count to 192.0.2.0/24 from Router A would be through the tunnel, so traffic destined to hosts on that subnet should be forwarded along the tunnel path. But wouldn’t the link (E,F) also be reachable across the tunnel other than through the path (A,C,E)? If metrics are used to determine which traffic enters the tunnel and which does not, then the metrics must be carefully planned and managed to prevent routing loops or unintended suboptimal routing through the tunnel interfaces.
The less obvious answer is the one that’s normally used to manage traffic flows through the tunnel—control routing so 192.0.2.0/24 is only advertised through the tunnel, and not through the underlying network. Although it is possible to filter routing information to achieve this effect, it’s much simpler in larger deployments to run a second control plane. This second control plane might be as simple as two static routes, or it might be a second layer of control plane information contained in the same routing protocol (such as carrying MPLS reachability information through a link state protocol), or it might be a completely different routing protocol.
A side effect of deploying a second control plane is that the “routers in the middle” can’t reach the destinations on either end of the tunnel; Routers B and D can’t, in this case, reach 192.0.2.0/24 (and whatever hosts on that network are talking to beyond Router A). Normally this is the intended effect
of tunneling; it reduces the forwarding information Routers B and D must carry in their tables, and helps to break the network into smaller failure domains (see Chapter 6, “Principles of Modularity”).
So, then, tunneling involves three levels of definition:
From a packet’s perspective, a tunnel is created when one packet is encapsulated into another packet at an equal or higher level.
From the data plane’s perspective, tunnels allow the forwarding of traffic to destinations only some of the devices along the path know how to reach.
From the control plane perspective, tunneling involves the deployment of a second control plane (or precise controls and policies configured on one control plane), combined with breaking the network into multiple vertical failure domains.
Is MPLS Tunneling?
How does MPLS fit into this picture? On the one side are engineers who state MPLS is tunneling, and on the other side are engineers who insist MPLS is not tunneling. Entire shows and articles have been produced addressing this question, with the result normally being a draw. Resolving this long-standing dispute is a useful exercise in understanding the concept of tunneling.
What are the attributes of MPLS that point toward its status as a tunneled solution?
It’s used to carry IP and other traffic through a network.
MPLS is normally deployed either with a separate control plane or with control plane information that’s not mixed with IP forwarding information.
MPLS connections between the edges of the network are explicitly called tunnels, with head and tail ends at either edge of the
network.
MPLS is designed to reduce the IP forwarding information
managed by the nodes in the center of the network by tunneling through them.
All of these, combined, certainly make a strong case for MPLS to be
considered tunneling. On the other hand, routers and switches in the core of an MPLS network must support MPLS forwarding for MPLS to be deployed edge-to-edge in the network. If MPLS is a tunneling technology, then why must core devices be MPLS aware?
The resolution to this problem entails returning to what tunneling really means. Let’s take IP as an example: is IP a tunneling protocol, or isn’t it? IP normally provides end-to-end addressing and traffic delivery for higher layer protocols, and it relies on the control plane of every device an IP packet passes through to know how to reach the packet’s destination. It’s clearly not a tunneling protocol, correct?
On the other hand, IP packets can be encapsulated inside other IP packets, to be carried across some part of the network that might not know about the
destination in the inner packet header. MPLS, in fact, can also be encapsulated into a GRE packet, which is then encapsulated into an IP packet. These are all tunneled use cases, however—so IP must be a tunneling protocol, right?
This confusion about what’s a tunneling protocol and what’s not comes about because we’ve approached the tunneling problem from the wrong end of the stick.
In reality, there are no tunneling protocols.
Tunneling is something that is done by stacking protocols; the protocols being stacked are not, in and of themselves, tunneling or “not tunneling”
protocols, as Figure 12-3 illustrates.
Figure 12-3 Tunneling or Not?
Router A in Figure 12-3 receives a packet, consults its local forwarding information, and decides the packet needs to be transmitted over a tunnel interface toward Router D, rather than over the physical interface connected to Router B. To forward this packet over the tunnel, Router A encapsulates the packet into an outer header of some type and forwards the packet to Router B. Routers B and C forward the traffic according to this outer header (Router C removes the outer header because it is the penultimate hop, or the next to last hop, in the tunnel).
Note:Penultimate label popping is something particular to MPLS; most
tunneling protocols don’t pop the outer label until the packet has reached the tunnel end point, or tail. This doesn’t impact whether or not MPLS is a
tunneling protocol, however; it’s just a matter of operational details within MPLS itself. In Figure 12-3, the dashed line shows where the outer header takes the packet, rather than where the tunnel terminates from a
configuration perspective.
The question we need to ask to understand the problem of MPLS being a tunneling protocol is this:Does it matter what protocol the inner and outer headers are?
The answer to this question must be no. What matters is that one packet is placed inside another header (the outer header) to form a second packet at the same or higher layer than the original packet, not what the inner protocol is, nor what the outer protocol is. In the case of IP in IP, the inner header is an IP header, and the outer header is an IP header.
In the case of MPLS, the inner header is MPLS (normally carrying IP, Ethernet, or some other data link or transport layer protocol). The outer header is like an Ethernet header, used to carry traffic hop by hop. The inner header in MPLS defines the end-to-end tunnel between Routers A and D; the outer header is used to carry the packet along from Router A to Router B, from Router B to Router C, and so on.
So the answer is this: MPLS is a protocol that can be used to tunnel traffic or as a data link protocol to carry packets hop by hop. The confusion in MPLS stems from the reality that the inner header is the tunneling header, while the outer header is the hop-by-hop header; normally these roles are
reversed. However, if we think of the outer header just like an Ethernet
header, and the inner header like a tunnel header, we get a clearer picture of what is going on.
Protocols shouldn’t be classified as a “tunneling protocol” or not (with the exception of protocols specifically designed for the sole purpose of tunneling other protocols). Just as the inner label in an MPLS label stack can be defined as a tunnel, but the outer label is hop by hop and therefore not a tunnel, tunneling is defined by the way the packets are built, not by the protocols being used in the inner or outer headers.