Tunnels for networking are not good. We see a real-life example taking place with the twelve Thai boys that were stuck at the end of a tunnel with a very narrow section under water preventing passage. The tunnel offered them only one way out, and the particular path was not passable. This is what happens in networks. We\u2019re thankful for the heroic rescue of these brave boys, but networks don\u2019t always fare as well.\nYou will hear others speak about how a tunnel-based virtual network is the next amazing trend in networking. In fact, an analyst recently told me tunnels are great. And they are, when used for the purpose they were intended. But, using tunnels to get aggregates of packets to go where they wouldn\u2019t go otherwise is dangerous, and will lead to the accumulation of technical debts.\nAs described below, in many of these new cases, tunnels are used for aggregates of users, flows and applications. Using tunnels this way, we are taking on large amounts of technical debt and I predict there will be a day of reckoning.\n1st debt: Routed as an aggregate \u2013 only one pathway to use\nSecure tunnels look like a singular long-lived network flow to core routers. Routers and switches will \u201chash\u201d the singular tunnel flow onto a singular path. Not knowing what else is on this path, or the current conditions over time, the tunnel performance will be tied for very long periods of time to a single path. If the pathway gets degraded, you will not have the ability to route around to better pathways.\n2nd debt: Tunnels have no flow control \u2013 poor for mixed media\nBranch offices and data centers can send\/receive network data much faster than the network. To slow applications down, routers drop packets. Applications understand that when a packet is dropped \u2013 they need to slow down. Tunnel protocols do not have flow control, window size controls, or retransmission. Tunnels require that the internal application provide this capability on its own for its own benefit. Thus if a tunnel had a single application in it, it would work perfectly. If the network wanted to slow the application down, it simply drops a tunnel packet, and the singular application will slow down. When tunnels are used for aggregates of applications, with mixed media (voice\/video and web traffic) the results can be very negative and highly unpredictable.\nSD-WAN companies will tell you they \u201corder and provide QoS at entry\u201d to the tunnel. This simply will not work. Consider a tunnel with 100 unique sessions in it. When a 101st session is added, and it goes through its \u201cramp up\u201d waiting for the network to \u201cslow it down,\u201d the network will likely drop packets from the existing sessions, slowing down the wrong session. The core routers drop a packet from the aggregate flow to \u201cslow it down,\u201d it likely will not be a packet from the session in the tunnel that needs to \u201cslow down.\u201d So we slow down the wrong flow, and let the new flow \u201caccelerate.\u201d If each of the unique sessions were not in the tunnel, the core routers would treat them uniquely, and drop the correct packets on the correct flows. Media flows are consistent and predictable, but when mixed in with bursty web traffic, the chance of a packet drop is increased dramatically. SD-WAN vendors know this and offer media packet duplication or forward error correction for media as a solution. Forward error correction increases bandwidth adding to our technical debt.\n3rd debt: Tunnels waste 30% of the network capacity\nTunnels add a lot of additional bandwidth per packet sent. It is generally accepted that with standard Internet traffic mixes, the additional bandwidth is 30 percent more. Take your total transport costs and multiply it by 1.3. This is a substantial long-term cost of using tunnels.\n4th debt: Decrease in effective packet size\nMany modern protocols figure out what the maximum size packet they can send. When a tunnel is used, the maximum useful packet payload is reduced. When you need to move a large file, or transfer a lot of data, it will indeed take more packets, and more time to transfer the same amount of data.\n5th debt: Increased packet fragmentation\nUpon entry to a tunnel, if a packet is larger than can be supported, it is split into two packets. This is called fragmentation. The packet pieces are sent in two or more packets, and then reassembled on the other side. This takes processing power, memory, and extra CPU. There are also many complications when a router drops a fragment.\n6th debt: Tunnel setup delays \u2013 slow link recovery\nWhen a tunnel is established, the negotiation for security keys requires physical time. Normally this isn\u2019t a problem, but when a tunnel connection is dropped, or needs to be moved, it may cause all internal applications to reset due to the delay.\n7th debt: Network routing features disabled\nThe tunnel will obfuscate all of the internal flows, providing very little if any useful information to the core of the network. This in fact is by design. But this prevents the core network from providing any routing or security capabilities. For example, if a carrier offered differentiated services, it would not be possible for the Tunnel owner to take advantage of it. If there were denial of service attack inside the tunnel, the core network would not be able to assist in stopping it.\n8th debt: Network tools not useful\nNetworking engineers frequently use tools to figure out why the network isn\u2019t working. Many of these tools will not work correctly in the presence of a tunnel or may provide very misleading answers. Network probes are typically unable to get data from the insides of a tunnel, invalidating their use.\n9th debt: Aggregate use tunnels violate fundamental security rules\nThou shall not bridge networks! Tunnels join address spaces between networks in a bi-directional way. This essentially creates an open door between two networks. Further provisioning complications and actions must be taken to manage security risks when using tunnels.\n10th debt: Re-encryption penalty\nAll modern software applications use encryption. Encryption is virtually free now, and one would be remiss to not use it. IPSEC tunnels also use encryption. Thus for most tunneled modern applications, encryption is being done twice, wasting CPU and bandwidth, with no advantage.\n11th debt: Best current practice requires two tunnels\nBecause networks that support tunnels fail, most users of tunnels require that there be two tunnels for each communication path. This is also standard practice for networking with AWS and Azure. Each tunnel has overhead to keep it ready for use, which adds to our accumulated debt. Having two tunnels does however create some routing problems. Best current practice is to run BGP over the tunnels to prevent routing loops. The cost of running BGP inside the tunnel adds to our accumulated debt.\n12th debt: Tunnels do not support network segmentation\nIPSEC tunnels do not support VLAN\u2019s. Customers seeking secure segmentation often are forced to use separate tunnels for each segment or MP-BGP and VRF\u2019s to separate user groups one-from-another.\u00a0 Even with a modest number of branches this quickly become untenable.\n13th debt: Hub-and-spoke debt\nTo avoid the complexity of managing an n-squared set of tunnels between all sites, best current practices suggest a data center hub, with branch spokes. This works well for everything but real time media going from branch to branch. The incremental latency and wasted bandwidth adds to our technical debt.\nWhen the number of tunnels gets large, and the technical debt has piled up so high, seek out solutions to your networking problems that don\u2019t use tunnels. Networking professionals need to solve the problems by finding ways to get packets to go where they wouldn\u2019t go otherwise, without tunnels. What is needed is innovation at the routing layer.