Getting the most out of your Packet Broker!
All networks evolve; they must to accommodate the modern services and devices that businesses rely on and that users demand. The network is undoubtedly an investment and an asset for any organization; it enables day to day operations. Upgrading the network comes with its pain points as well, and I would venture a guess that any network engineer has at least one horror story about expanding their infrastructure. One of these pain points is that upgrading the network will invariably force some pieces of the environment into the obsolescent territory (if not make certain things outright obsolete). One of the key roles that Network Packet Brokers can play in any network is that of easing the infrastructure transition and extending the life of tools and appliances that would otherwise be left behind.
Recently I assisted a customer that was in this exact scenario. The network was being upgraded bit by bit as resources allowed. Due to budgetary and time constraints, it is hardly unusual for organizations to be unable to completely overhaul the network in one fell swoop. In this case, the infrastructure had just made the jump to 10G fiber. The transition to 10G gave this organization plenty of room to grow over the coming years; they were currently only seeing a maximum bandwidth utilization of around 1.5 Gbps. This did introduce complications into the monitoring methodologies that they had previously been employing though. The organization owned a popular packet capture appliance that also performed application performance analysis. This appliance was equipped with 4 x 1G copper interfaces for capture and was still a viable solution in the network. Previously, they had been taking advantage of the use of a SPAN port to forward traffic to the capture appliance. Now that the bandwidth on the network exceeded 1Gbps they would have to employ more SPAN ports to forward the increased traffic load to the appliance but in this situation their switch was unable to provide these additional 1G feeds, and the capture appliance would have been unable to receive a single 10G SPAN feed due to the limitations of its capture interfaces.
Let’s diverge slightly from the main issue at hand for a moment to address another element at play here. It isn’t the primary problem of simply getting the appliance connected again but is certainly relevant from a network monitoring perspective. A secondary issue in this scenario is the quality of the traffic feed from the SPAN port itself. You may already be aware that SPAN ports, while convenient, are not ideal for feeding monitoring tools. SPAN ports typically change the timing of network packets and will also readily drop packets if the switch is too taxed while performing its primary function of switching. Timing is critical to diagnosing application performance issues and missing packets…well…that’s just fundamentally counterproductive to monitoring. SPAN ports will drop errored frames and strip various Layer 2 information from traffic, again, detrimental to diagnosing performance issues and an obstacle to full network visibility. SPAN ports can only output specified traffic sessions and are particularly ill-suited to monitoring full-duplex links. Sometimes you only want to see a specific subset of traffic, something a SPAN does well enough, but in our case, the capture appliance is only at its best when it can see every bit of network traffic, errored frames, timing and all. Clarifying that last con of SPAN ports, I pointed out, will also bring us back to the main point. On a full-duplex link, there is the transmitting side of a link and the receiving side of the link. On a link rated at 1Gbps, this is, in reality, up to 2Gbps of network traffic that needs to be monitored. Obviously, you cannot output 2Gbps per second worth of traffic on a 1G SPAN port. Our customer had just upgraded their infrastructure and was already over the 1Gbps threshold in one direction. It’s not improbable then that they were already oversubscribing their 1G SPAN port before the upgrade and missing out on critical data for their capture appliance. At the estimated 1.5Gbps of peak traffic in the new environment, we needed to be prepared to handle at least 3Gbps of traffic to the tool which, fortunately, was still within its capabilities.
As it turned out, we were able to address these issues succinctly, and very economically (an important requirement for the client), with the Cubro Packetmaster EX2+. This is a small form-factor (yet fully-featured) Packet Broker that is just as well suited to travel as being racked up for long-term installation. The EX2+ integrates both a Single Mode and Multi-Mode optical TAP into the rear of the unit. These passive TAPs are the first piece of the solution, as they grant completely fail-safe access to the 10G link and output a complete copy of the network traffic. As for interfaces, the EX2+ sports 2 x 10Gbps SFP+ ports and 4 x 10/100/1000 copper ports. The two 10G ports will accept the monitor feeds from the TAP on the rear of the unit and even provide some future-proofing for this customer (more on this later). Now, we already mentioned that the capture and analysis appliance has 4 x 1G copper interfaces, potentially supporting up to 4Gbps of ingress traffic, and we are currently dealing with roughly 3Gbps of traffic that need to go to the tool. This works out perfectly since we can create a four-port, session-aware, load-balancing group on the EX2+ with our remaining copper links and connect them to the capture appliance’s 4 x 1G links. The end result is the client now has full network visibility to their network, their capture appliance is not only back in service but is receiving every last bit of traffic, and they even have a bit more room to grow before their appliance will no longer be able to keep pace with their network traffic.
I previously mentioned the future-proofing aspect of the EX2+ for this customer. This is one of the coolest parts in my opinion: The EX2+ is not only extending the life of their current toolset but will remain serviceable far into the future for this customer. With Cubro’s Packetmaster line we can easily separate the TX side of the optical transceiver from the RX side. So even while those two 10G ports have the RX interfaces occupied by the monitor feeds from the TAP the TX side is still available for outputting traffic. In the future, when this customer upgrades to a capture appliance with 10G interfaces, the EX2+ will still be perfectly capable of feeding the full capacity of the 10G link to the new tool (while still having the 4 x 1G copper interfaces available for other uses). For more information - https://www.cubro.com/network-packet-broker-packetmaster-ex2.html
This example, while not extremely complex, illustrates a situation that I believe a lot of organizations find themselves in as they grow their network infrastructure. It also highlights how the addition of a Network Packet Broker can increase the efficiency of monitoring devices while simultaneously extending their serviceable life, increasing ROI on equipment purchases.
Written by: Derek holds various certifications pertaining to Networking, Linux, and Security. He is in continual pursuit of new skills and knowledge and strives for a deep understanding of technologies in order to offer assistance and communicate them to others.
Derek Burke, Cubro North America Senior Sales Engineer
firstname.lastname@example.org or www.cubro.com