Introduction:
In this article I would like to address the role that Network Packet Brokers play in enabling effective monitoring for encapsulated traffic on the network. This article will be divided into two portions because, at least in my view, the topic can be divided into two problem areas: the traditional problem, that users have been dealing with for some time, and a new set of issues that have cropped up with the rise of distributed compute infrastructures, data centers, and virtualization. Before delving into the issues of monitoring encapsulated traffic let’s talk about what it is.
Encapsulation, tagging, or labeling network traffic is a necessity in all but the simplest of modern networks. Whether it is simply VLAN tagging to isolate broadcast domains, building complex overlay networks, or segmenting virtual traffic. These processes involve adding additional information to network traffic headers (known as tagging or labeling) or taking an entire frame and placing it inside some other transport protocol (encapsulation, tunneling) all for the benefits of reduced latency, secure routing, and network efficiency. Once the encapsulated or tagged packet reaches its intended destination, the tag/label is removed or, in the case of a tunnel endpoint, the tunnel is terminated (the traffic is decapsulated) and the packet continues to its ultimate destination.
The traditional problem:
An area where these technologies have traditionally caused an issue is with network monitoring tools. When tapping links of the network to copy traffic off to monitoring and security appliances, traffic will invariably be found with all kinds of additional L2 and L3 protocol headers. Likewise, if performing monitoring inline. In truth, it would only be when monitoring is performed at the endpoint that there is little likelihood of seeing encapsulated traffic. The problem, at its worst, is many monitoring tools cannot parse these headers and, therefore, cannot process the traffic. This has the effect of creating just the kind of blind spot we strive to eliminate with monitoring systems. In the best-case scenario, the tools may be configurable to strip these headers to access the inner data but at the cost of performance due to additional processing requirements.
Fortunately, traditional Network Packet Brokers have long been equipped with features to address exactly these kinds of shortcomings. It should be expected of any L2-4 NPB today to be able to perform VLAN tag removal just as the Cubro Packetmaster series does. This includes the ability to remove multiple VLAN tags; a lot of monitoring and security tools will handle VLAN tags without any issue. However, there could be an upper limit to how many tags any given device can process; perhaps one, maybe even two. Any tags beyond that number would need to be stripped prior to being sent to that device and this is a task network packet brokers can handle with ease. MPLS labels are another protocol header that network packet brokers can remove from traffic before it reaches any appliances for monitoring and/or inspection. Terminating network tunnels is yet another task that network packet brokers can handle and can be very important in both out-of-band and inline applications. For example, Cubro Packetmaster network packet brokers can all function as a GRE (Generic Route Encapsulation) endpoint. One of the many applications for GRE support in these packet brokers is to strip the GRE headers so the traffic can be consumed by monitoring and security tools. This is true of other supported tunneling protocols as well such as NVGRE, GENEVE, and VXLAN.
GTP (GPRS Tunneling Protocol) is the critical family of tunneling protocols that mobile networks use to transport signaling, control plane, and user plane data between the core network and various other nodes of the network (depending on the data type). Each GTP tunnel can contain hundreds of individual IP streams and for these to be monitored and/or analyzed the GTP tunnel must be stripped away; a feature that the Cubro Sessionmaster EXA40 and EXA24160 provide. Incidentally, these advanced network packet brokers can also perform correlation of user and signaling plane data to create a comprehensive picture of the traffic to monitoring systems, but more of that in Part 2.
Packet slicing, which admittedly has nothing to do with encapsulated traffic, is something I want to mention because it fits the spirit of the conversation (in so far as eliminating extraneous data to increase the tool’s performance). Let’s say for instance that we have encrypted traffic on our network (we can expect that we certainly will) and we don’t have access to the keys used for encryption. In this case there is no way for us to decrypt the encrypted portion of the traffic. Some examples of this could be a TLS session where we don’t control the cert or someone using PGP to encrypt their email. In both cases we should have usable headers up to Layer 4 and with PGP only a portion of the payload will be encrypted. Using packet slicing we can discard the encrypted portion of the traffic while retaining any header information that is visible for our monitoring tools. This reduces processing to a degree but, more importantly, in situations where traffic is being recorded to disk, drastically conserves available storage space. This isn’t to suggest that an organization will always discard the encrypted portion of the traffic, but it is a nice option to have.
It is also worth mentioning that, while this article is about the removal of these additional protocol headers, the aforementioned criteria can be used to filter traffic as well. A benefit of Cubro’s network packet brokers is that, apart from data correlation, these features are implemented in hardware and therefore are completely deterministic and suffer no performance penalties regardless of bandwidth and device utilization. Need a 32-port packet broker that can terminate VXLAN tunnels at 100 Gbps on all ports simultaneously? We have a device for that.
This is great for out-of-band monitoring but what if we are monitoring traffic inline? If traffic is being monitored inline then it stands to reason that any encapsulation headers need to remain intact for the traffic to get to its intended destination (kind of important to keep the network functioning, right?). An approach to this problem is to remove the headers that would interfere with monitoring and security tools right before passing them to those devices and then have that traffic come back into the network packet broker where the headers can be reapplied. Just as a quality network packet broker should be able to strip headers from traffic, so too should it be able to apply them.
Previously I have been speaking to monitoring and security tools as the devices that are unable to parse many kinds of encapsulated traffic but, in truth, many network packet brokers are disadvantaged by encapsulated traffic as well. Usually the packet brokers can pass the traffic perfectly fine but, when it comes to filtering the traffic, they are only able to filter on the outermost headers. These outermost headers are, of course, the encapsulation headers or, in the case of something like Q in Q traffic, the outermost VLAN tag. In order to filter on the inner headers or tags the encapsulation headers/tags must first be stripped away, just like we would for the monitoring tools incapable of processing the traffic. To address this Cubro developed its line of G5 Sessionmasters that can filter on the inner tags/headers of network traffic without stripping any headers (and this is done in hardware). This means rules can be configured to filter on the inner VLAN tag of Q in Q traffic, or the inner IP headers of protocols like GTP, VXLAN, as well as other tunneling protocols.
Now you may be wondering at this point “If we have to strip the headers for the monitoring/security appliances then what does it matter if a lot of packet brokers need to strip headers for filtering purposes?” The answer boils down to this: the traditional monitoring techniques are simply not cutting it anymore. With the rapid growth of cloud computing, virtualization, scalable and ephemeral container instances, and software-defined networking a new approach to monitoring is required. Cubro’s advanced packet brokers that can filter on these inner headers without header stripping are the first piece in the puzzle of monitoring these new, incredibly complex networks and we will discuss that in Part 2 of this article.
By Derek Burke (The article was originally published on NetworkDataPedia)