Whether you’ve been in the IT, Network Monitoring, or Network Security industries for a short period or for a long period, you’ve probably been asked, “to SPAN or not to SPAN?" Today’s your lucky day because you will learn how to best answer this question both for yourself and for the next time a colleague or prospect asks you.
Enterprise and service provider security and compliance requirements demand that IT organizations have full network visibility across data center infrastructure elements to gain insight into how well they are functioning and enable detection and remediation of critical security threats and potential availability or performance anomalies.
SPAN stands for Switch Port for Analysis and is an effective form of source interface–based routing to acquire network traffic for analysis for security and compliance applications. SPAN enables port mirroring or copying of traffic from a physical port on a switch to another port on that same switch to non-intrusively feed traffic to out-of-band security tools such as probes, intrusion detection systems, network recorders and network analyzers.
The ideal location for SPAN-based port mirroring is a data center core network switch. However, any switch that supports maximum visibility into the traffic of interest is acceptable.
In the past, Gigabit Ethernet networks involved frequent use of ad-hoc SPAN ports configured-on-demand in switches and routers on the troubleshooting path. Unfortunately, SPAN ports configured on production routers and switches that were “safe” at 1GE speeds were often service-impacting at 10GE speeds.
In GbE-only networking environments, SPAN was effectively guaranteed that every packet going through the switch was mirrored, since GbE switch backplanes could easily replicate every frame and deliver all the frames for analysis.
However, this dramatically changed with the advent of 10 Gigabit Ethernet starting with the fact that maximum bandwidth is now twice the base bandwidth – so a Full Duplex 10 Gigabit link now has 20 Gigabits of potential traffic. Few switches or routers can handle replicating all this traffic, in addition to handling their primary job of switching and routing.
Furthermore, it is difficult, if not impossible, for core switches to mirror all Full Duplex traffic at full-time rate, in real time, as environments migrate to 40 and 100 Gigabit Ethernet, limiting the applicability of SPAN for security and compliance applications in service provider and enterprise data centers.
For example, Cisco’s White Paper re SPAN Port Usability cautions that “the switch treats SPAN data with a lower priority than regular port-to-port traffic. In other words, if any resource under load must choose between passing normal traffic and SPAN data, the SPAN loses and the mirrored frames are arbitrarily discarded.” Knowing that the SPAN port arbitrarily drops traffic under specific load conditions, what strategy should users adopt so as not to experience dropped packets? According to Cisco, “the best strategy is to make decisions based on the traffic levels of the configuration and when in doubt to use the SPAN port only for relatively low-throughput situations”.
SPAN deployment may also limit the number and type of monitoring tools that can be deployed, which presents another scalability challenge. Core switches typically provide the option of creating two SPAN ports. While this may be enough for most networks, you can easily end up with a situation where no SPAN ports are available. In comparison, the security monitoring tool count continues to grow with each of these tools typically in use by different teams related to network operations or security, with changes engineered in at different frequencies, and visibility into different but overlapping slices of the network.
As data center networks scale, the traditional approach has been for organizations to deploy additional monitoring tools, which consume larger numbers of SPAN/mirror ports, leading to problems with performance—e.g., dropped packets or the inability of the tools to keep up with throughput — or just causing the administrator to run out of available ports. In addition, the time required for network operations teams to provision the additional SPAN ports can lead to unacceptable downtime and limit access by other IT groups interested in consuming this data.
Organizations typically connect security and monitoring tools directly to SPAN ports, but this approach limits scalability, as the number of SPAN ports is limited and simply adding more security and monitoring tools to provide coverage over a rapidly expanding network is costly and increases network complexity. Additionally, the tools themselves frequently run out of capacity due to increased traffic volumes and the need to process unnecessary packets.
Out-of-band security places the application outside the flow of traffic, for example through a SPAN/mirror port attachment. It is less disruptive to network traffic than in-band and can scale more easily. However, it comes with the downside of some potential delay between detection and correction of a problem (during which the offending traffic continues to flow) and the need for some degree of network reconfiguration upon installation.
SPAN port connectivity is reaching its limits. Up to this point, organizations have addressed growth in data center network scale and complexity by tactically deploying more tools. Though this may provide a short-term solution, the required collection points for network monitoring and security-related activities has the potential to quickly saturate SPAN/mirror ports.
Another way to mirror network traffic to both inline elements and out-of-band network security tools including WAN acceleration, IPS/IDS, and network analyzers is to use a Network TAP.
Modern enterprise networks typically have a range of problems when it comes to maximizing the value of their monitoring tools. These include getting only the right data to
Getting the right data to the right tool is a challenge because different tools need different types of data. For enterprises that use SPAN ports to feed data to the tools, as the network grows, SPAN port shortages often occur, resulting in tools that sit unused.
SPAN-based monitoring architectures present no shortage of challenges in establishing complete visibility as well as accurate, lossless access to sources of packet streams for network and security monitoring and analysis. Such challenges are compounded by the broad-based requirement for improving monitoring tool efficiency and moderating tool costs in face of continuous growth in the volume of packets crossing enterprise and service provider data center networks.
For larger networks and zero packet loss, you may want to check out Network TAPs as an alternative.