We’ve discussed why network packet brokers are an essential component for the increasingly crowded data center, for traffic aggregation and load balancing. We’ve also begun diving into specific advanced features such as deduplication. Today, we’ll be focusing on network tunneling. In a nutshell, this feature allows the network packet brokers (NPB) to transport protocols that the network infrastructure doesn’t support, bringing potential performance issues or threats to your attention that much sooner.
Ironically, tunneling isn’t the best visual analogy for what network tunneling entails. Instead of thinking of network tunneling as a car going through a tunnel, it might be easier to think about network tunneling as a car traveling on a ferry.
In this analogy, your car is a packet. The packet, like your car, is designed to travel around a lot, but there are some places it can’t get to. A packet might be incompatible with your data center in the same way that your car is incompatible with a large body of water.
Rather than drive your car into the ocean—or your packet into an incompatible network—you can use a ferry instead. The ferry encapsulates your car and safely transports it to a compatible network of roads. In the same way, network tunneling protocols encapsulate an incompatible packet with a different header that’s designed to make it compatible with your network.
Network tunneling is commonly used to connect remote sites and virtual private network applications. In this scenario, packets coming from your computer are encrypted, in a way that makes them incompatible with the public internet. The VPN appliance encapsulates these packets with new headers which tell the internet to send these packets to the corporate network, where they are then stripped of the new header and decrypted.
Tunneling is an important feature for network packet brokers in situations in which your corporate network is associated with the VPNs and the cloud. In these contexts, it may be impossible to set up a physical network TAP or SPAN port, because the infrastructure in the cloud doesn’t belong to you or is accessible. By using an advanced network packet broker with a tunneling feature, you can capture packets in the cloud and in private networks and then send them to your monitoring tools for analysis.
There’s more than one way to skin a cat—or tunnel a packet, for that matter. There are multiple network tunneling protocols, each with its own advantages and disadvantages in terms of a network security use case.
Developed by Cisco Systems, GRE has become a widely-used industry standard for network tunneling. It’s very simple to use, as all it does is add two new headers to an encapsulated packet. One header identifies the packet, and the other header adds the address where the packet will be sent.
In order for GRE to work, you need to establish a GRE tunnel. This involves creating a specific configuration between two routers, which means that GRE can only be used for specific point-to-point communications. GRE is often used with VPN applications, in which VPN provides a secure encryption layer and GRE tunnels encrypted traffic to where it needs to go.
L2GRE or Layer 2 GRE provides a virtual private Ethernet in the IP network, allowing you to have the same VLAN in multiple locations and be connected. The layer-2 packets are encapsulated in a GRE packet and then encapsulated in an IP protocol. The tunnel extracts the packet and forwards the packet to its destination, allowing the source and destination peers to operate as if they have a virtual connection with each other.
By contrast to GRE, VXLAN is much more commonly seen in data center applications, especially in data centers that contain highly virtualized environments. It can be difficult to scale network communications across these environments because the amount of traffic they handle can vastly outstrip the capacity of physical infrastructure.
As such, VXLAN is used to create an overlay network that allows administrators to virtualize network infrastructure. Using VXLAN, administrators can deploy and use virtual switches, firewalls, and other network infrastructure, allowing the network to scale alongside the growing number of virtual machines.
Basically, this is a virtual SPAN port. Like a SPAN port, ERSPAN lets administrators mirror traffic from a port on one switch, and then delivers this traffic (using GRE) to a different port on another device. In our previous post on deduplication, we mentioned that SPAN ports were a huge source of duplicate packets—and we recommended that you switch to network TAPS if possible. ERSPAN has many more possibilities than a traditional SPAN port, however.
For example, SPAN ports usually only mirror traffic from one switch to another, but ERSPAN lets you mirror traffic from a switch to any device you want. For example, you can send the mirrored traffic to a PC or server provisioned with dedicated monitoring equipment, and you can use a filter so that your device only examines packets that were sent with GRE. This means that you can use ERSPAN to send traffic from anywhere in your network directly to a device equipped to monitor it.
The data center you’re running now is probably far from the private clouds of old. It’s heavily virtualized, is highly integrated with cloud storage, and contains multiple VPN or SD-WAN connections linking it to branch offices and remote users. Without a network packet broker, these new linkages create blind spots in the network that traditional monitoring tools can’t touch. By using advanced network packet brokers like PacketMAX equipped with tunneling, you can bring these blind spots into the light, resulting in a more secure and stable network.
Looking to add a packet broker to your deployment, but not sure where to start? Join us for a brief network Design-IT consultation or demo. No obligation - it’s what we love to do.
