Les presento un extracto que analiza las desventajas de SPAN y RSPAN hecho por un especialista en networking: Tim O'Neill. La primera parte presenta al autor y la segunda muestra el análisis de esta tecnología.
Especialidades de Tim O’Neill "Oldcommguy™":
High Tech Business Development, Mergers/Acquisitions ,Branding and Identity - In technologies like Industrial LAN, IT LAN, WAN, ATM, WiFi, IP, VoIP, Video-oIP, Database, and Internet technologies. I am a skilled technical media writer.
Editor of www.lovemytool.com a technology advocacy site.
Ex-Law enforcement and Technologist who volunteers to train Internet Safety for Children, Adults and Seniors.
Volunteer Cybercrimes consultant to the Georgia P.O.S.T. Executive Director.
RSPAN … Friend or Foe? (by Tim O’Neill)
Es posible que tu navegador no permita visualizar esta imagen. Editor Profile - Tim O’Neill is an independent technology consultant. He has over 30 years experience working in the WAN, Analog, ISDN, ATM and LAN test market. Tim has worked with companies like Navtel, Network General, Ganymede and ClearSight Networks and is now helping companies get lab recognition and technology verification. Tim is also the Chief Contributing Editor for LoveMyTool.com, a website designed to help network managers gain access to valuable information and real solution stories from other customers. Tim is a patent holding, published and degreed engineer, who has seen this technology grow from Teletype (current loop) data analysis to today’s 10 Gigabit LAN’s focused on business applications with heavy compliance demands. Tim can be reached at oldcommguy (at) bellsouth (dot) net.
Is RSPAN something one should be using? Or is it something to be avoided?
Recently I wrote an article about SPAN that details the overall issues with using SPAN ports as the monitoring data access point, providing evidence that SPAN access for monitoring and analysis is not in the best interest of network managers who need to fully understand their networks.
The list of problems with using SPAN ports for network monitoring and analysis are many and in particular, I pointed out that SPAN ports will not meet the demands of compliance requirements for high fidelity data access nor for analysis of synchronized traffic such as VoIP.
So you should not be surprised when I tell you that RSPAN is even a bigger potential mess and that its usage is not only not recommended but is in fact prohibited altogether in many high-end customer sites!
What is RSPAN?
RSPAN stands for Remote Switched Port for ANalysis.
RSPAN is similar to SPAN except that it utilizes a “remote” switch to send data back through the “production” network for monitoring.
RSPAN has all the issues of SPAN and more
Recall that,
1. SPAN’ing or mirroring changes the timing of the frame interaction (what you see is not a true representation of your network traffic).
2. The SPAN algorithm is not designed to be the primary focus or the main function of the device like switching or routing. This means that the first priority is not SPAN and if replicating a frame becomes an issue, the hardware will temporally drop the SPAN process.
3. If the speed of the SPAN port becomes overloaded frames are dropped.
4. Proper SPAN port setup requires that a network engineer configure the switches properly and this takes away from the more important tasks that network engineers have. Many times configurations can become problematic (constantly creating contention between the IT team, the security team and the compliance team).
5. SPAN port drops all packets that are corrupt or those that are below the minimum size, so all frames are not passed on. For IPv6 knowing the amount of fragments is an important measurement criterion.
All of these events can occur and no notification is sent to the user, so there is no guarantee that one will get any, much less all, the data required for proper analysis or reporting/statistics.
Now we add RSPAN, this means that the above issues are compounded with more delay, more loss, more filtering and data grooming. In addition, the RSPAN packets are transported over the production network. This is just unreliable for any type of serious monitoring or analysis techniques.
How does RSPAN really work?
The following shows Cisco’s schematic for RSPAN.
Es posible que tu navegador no permita visualizar esta imagen.
The Source switch is taking frames from the source port and encapsulating them in newly-created RSPAN frames. The switch then sends these new RSPAN frames through the production network to a Destination switch which then removes the encapsulating headers and presents the frames to a capture device on the destination port. From a simple frame timing and performance monitoring perspective, what appears at the ultimate destination port bears no reliable resemblance to what actually occurred at the source port or on the network being monitored.
Summary
SPAN does not deliver high fidelity data access and is a potential failure point in your network. RSPAN just adds to the issues of SPAN and is not recommended for any application of monitoring or analysis for today’s networks.
If one must have remote access to data, my recommendation is to use real access taps such as those manufactured by Network Critical or a secure remote access device like the Gigamon Systems data access switch. This will give you all the packets required for meeting today’s critical analysis and monitoring needs (and save you lots of headache).
Comments from Network Experts –
Betty DuBois – Sniffer Expert, Network Consultant and Wireshark instructor
Tim O’Neill hits the nail on the head again. So often I will hear customers tell me “the sales guy said that with RSPAN I could see my whole network without having to move the capture device”. Just remember the acronym for the OSI model. Please Do Not Take Sales Person’s Advice on this one. If all you need is something quick and dirty just to see if the client and server can talk to each other, then it is fine. But RSPAN is not a viable solution if you are trying to prove whose fault it is, the delta times for the packets are completely skewed.
Scott Haugdahl – Network Expert and Founder of Bitcricket
Editor's Note - Scott has also written previously about RSPAN, please refer here.
Tim, I agree that RSPAN is generally bad for enterprises with a high volume of traffic. There are certain situations where you cannot for practical reasons, put a tap on every segment in your infrastructure, especially low volume local or remote edges. In such situations, save taps for higher volume traffic and permanent installs and use an SNMP tool to monitor switch stats for port CRC counts (i.e. packets not passed through the SPAN).
If the RSPAN VLAN is sharing the same physical segments as corporate data, one might look into lowering the switch VLAN priority for passing RSPAN traffic. Sure, this can worsen the timing but I can still obtain valuable troubleshooting information even if the packet timing at the analyzer is not precise. Finally, using a security ACL as a filter (such as TCP port 80) on the RSPAN VLAN (supported by higher end Catalyst switches in certain configurations), is worth a look to cut down the traffic volume. Regardless, tread *very* lightly!
Tom Tosh – Sniffer Expert – Senior Consultant and Network Expert
RSPAN is one of those features that, when I first heard the concept, I thought “Hmm…. Interesting,” but on a second look, after coming to understand how it works, soon asked, “When and how could that possibly be useful?” I believe that a comprehensive visibility strategy for networks requires some understanding and consideration of RSPAN, its limitations and its caveats. When we have no other visibility into a remote switch, and the answers we seek regarding the traffic seen at any specific, user-based port on that switch are not performance-based, RSPAN can likely provide some usable information. And in that statement are the key caveats of RSPAN:
Limit RSPAN sourcing to a single, user-based port in order to minimize RSPAN’s impact on the switches and network path. This means no multiple-port spanning, and no spanning of trunk or server ports.
Apart from basic network conversations seen within the RSPAN-sourced frames – for example: “this user is definitely talking to this server,” refrain from making any conclusions as to the performance occurring on those conversations. If you have any alternative means of getting the limited answers that RSPAN can provide by all means use them prior to resorting to RSPAN.
Jenny Wilson – Sniffer Expert, Network Expert, Consultant and Trainer
Excellent article Tim! When it comes to RSPAN, if we're not aware of the risks and disclaimers, we can unwittingly sabotage ourselves - either causing additional problems, or spending months troubleshooting a problem that could have been solved in a few minutes with accurate information.
Tony Fortunato - Network Performance Consultant, Certified Wireshark and Fluke Networks instructor with over 15 years experience
Tim you are right on as there are many problems with SPAN and RSPAN! I’ve personally experienced when spanning a server port and capturing from the client’s computer creates duplicate packets and cause false positives. I have seen cases where the worst case scenario involves technician blindly spanning multiple ports or an entire VLAN causing significant switch performance degradation and possible complete switch failure. I’ve been onsite where arguments leading to physical threats between the IDS group who needs the SPAN port and the Network Technician who wants to use the same port for his troubleshooting. Full and direct access is always best!
Richard Bejtlich - Founder of TaoSecurity and author of many security books including Tao of Network Security Monitoring and Extrusion Detection
This is the simplest way for me to compare SPAN ports to taps: a SPAN port is a girlfriend, but a tap is a wife. It takes a real level of institutional commitment to install a tap, and the rewards are long-lasting. A SPAN port is a temporary fling subject to break-up (i.e., deactivation). Furthermore, I really liked [Tim's] emphasis on SPAN configuration as a change that must be allowed by the change control board in any semi-mature IT shop. The only CCB action needed for a tap is the initial installation. Any change to a SPAN port configuration should be authorized by the CCB.
To SPAN or to TAP – That is the question!
Until the early 1990’s, using a TAP or test access point from a switch patch panel was the only way to monitor a communications link. Most links were WAN so an adaptor like the V.35 adaptor from Network General or an access balum for a LAN was the only way to access a network. Most LAN analyzers had to join the network to really monitor.
As switches and routers developed, there came a technology we call SPAN ports or mirroring ports and now monitoring was off and running. Analyzers and monitors no longer had to be connected to the network; engineers would use the SPAN (mirror) port and direct packets from their switch or router to the test device for analysis.
SPAN generally stands for Switch Port for Analysis and was a great way to effortlessly and non-intrusively acquire data for analysis. By definition, a SPAN Port usually indicates the ability to copy traffic from any or all data ports to a single unused port but also usually disallows bidirectional traffic on that port to protect against backflow of traffic into the network.
Es posible que tu navegador no permita visualizar esta imagen.
Is SPAN port a passive technology – No!
Some call SPAN port a passive data access solution – but passive means “having no effect” and spanning (mirroring) does have measurable effect on the data.
First - Spanning or mirroring changes the timing of the frame interaction (what you see is not what you get),
Second - The spanning algorithm is not designed to be the primary focus or the main function of the device like switching or routing so the first priority is not spanning and if replicating a frame becomes an issue, the hardware will temporally drop the SPAN process,
Third - If the speed of the SPAN port becomes over loaded frames are dropped.
Fourth – Proper spanning requires that a network engineer configure the switches properly and this takes away from the more important tasks that network engineers have and many times configurations can become a political issue (constantly creating contention between the IT team, the security team and the compliance team).
Fifth – SPAN port drops all packets that are corrupt or those that are below the minimum size, so all frames are not passed on. All of these events can occur and no notification is sent to the user, so there is no guarantee that one will get all the data required for proper analysis.
In summary, the fact that SPAN port is not a truly passive data access technology or even entirely non-intrusive can be a problem particularly for Data Security Compliance monitoring or Lawful Intercept. Since there is no guarantee of absolute fidelity, it is possible or even likely that evidence gathered by this monitoring process will be challenged in the court of law.
Is SPAN port a scalable technology – No!
When we had only 10Mbps links and with a robust switch (like one from Cisco) one could almost guarantee they could see every packet going through the switch. With 10Mbps fully loaded at around 50% to 60% of the maximum bandwidth, the switch backplane could easily replicate every frame. Even with 100Mbps one could be somewhat successful at acquiring all the frames for analysis and monitoring and if a frame or two here and there were lost, it was no big problem.
This has all changed with Gigabit and 10 Gigabit technologies starting with the fact that maximum bandwidth is now twice the base bandwidth – so a Full Duplex (FDX) Gigabit link is now 2 Gigabits of data and a 10 Gigabit FDX link is now 20 Gigabits of potential data.
No switch or router can handle replicating/mirroring all this data plus handling its primary job of switching and routing. It is difficult if not impossible to pass all frames (good and bad one) including FDX traffic at full time rate, in real time at non blocking speeds.
Furthermore, to this FDX need we must also consider the VLAN complexity and finding the origin of a problem once the frames have been analyzed and a problem detected.
From Cisco’s own White Paper – On SPAN port usability and using the SPAN port for LAN analysis
Cisco warns that “the switch treats SPAN data with a lower priority than regular port-to-port data.” 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. This rule applies to preserving network traffic in any situation. For instance, when transporting remote SPAN (RSPAN) traffic through an Inter Switch Link (ISL), which shares the ISL bandwidth with regular network traffic, the network traffic takes priority. If there is not enough capacity for the remote SPAN traffic, the switch drops it. Knowing that the SPAN port arbitrarily drops traffic under specific load conditions, what strategy should users adopt so as not to miss frames? 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.”
Hubs? How about it?
Hubs can be used for 10/100 access but they have several issues that one needs to consider. Hubs are really Half Duplex devices and only allow one side of the traffic to be seen at a time. This effectively reduces the access to 50% of the data.
The Half Duplex issue often leads to collisions when both sides of the network try to talk at the same time. Collision loss is not reported in any way and the analyzer or monitor does not see the data.
The big problem is if a Hub goes down or fails the link it is on is lost.
Hubs no longer fit as an acceptable, reliable access technology for the reasons above and they do not support Gigabit or above access and should not be considered.
Today’s “REAL” Data Access requirements
To add more complexity and challenges to SPAN port as a data access technology,
1) We have entered a much higher utilization environment with many times more frames in the network
2) We have moved from 10 Mbps to 10 Gbps Full Duplex and
3) We have entered into the era of Data Security Legal Compliance and Lawful Intercept which requires that we must monitor all of the data and not just “sample” the data, with the exception of certain very focused monitoring technologies (e.g., application performance monitoring).
These demands will continue to grow since we have become a very digitally focused society. With the advent of VoIP and digital video we now have revenue generating data that is connection oriented and sensitive to bandwidth, loss and delay. The older methods need reviewing and the aforementioned added complexity requires that we change some of the old habits to allow for “real” 100% Full Duplex real time access to the critical data.
In summary, being able to provide “real” access is not only important for Data Compliance Audits and Lawful Intercept events, it is the law (keeping our bosses out of jail has become very high priority these days).
When is SPAN port methodology “OK”?
Many monitoring products can and do successfully use SPAN as an access technology. Since they are looking for low bandwidth application layer events like “conversation analysis”, “application flows” and for access VoIP reports from Call managers, etc.
These monitoring requirements utilize a small amount of bandwidth and grooming does not effect the quality of the reports and statistics. The reason for their success is that they keep within the parameters and capability of the SPAN port capability and they do not need every frame for their successful reporting and analysis. In other words, SPAN port is a very usable technology if used correctly and the companies that use mirroring or SPAN are using it in a well managed and tested methodology.
Conclusion
Spanning (mirroring) technology is still viable for some limited situations but as one migrates to FDX Gigabit and 10 Gigabit networks and with the demands of seeing all frames for Data Security Compliance and Lawful Intercept one must use “real” access (taps) technology to fulfill the demands of today’s complex analysis and monitoring technologies.
If the technology demands are not enough, the network engineers can focus their infrastructure equipment on switching and routing and not spend their valuable resources and time setting up span ports or rerouting data access.
In summary, the advantages of Taps compared to SPAN ports are ...
• Taps do not alter the time relationships of frames – spacing and response times especially important with VoIP and Triple Play analysis including FDX analysis.
• Taps do not introduce any additional jitter or distortion which is important in VoIP / Video analysis.
• VLAN tags are not normally passed through the SPAN port so this can lead to false issues detected and difficulty in finding VLAN issues.
• Taps do not groom data nor filter out physical layer errored packets
• Short or large frames are not filtered
• Bad CRC frames are not filtered
• Taps do not drop packets regardless of the bandwidth
• Taps are not addressable network devices and therefore cannot be hacked
• Taps have no setups or command line issues so getting all the data is assured and saves users time.
• Taps are completely passive and do not cause any distortion even on FDX and full bandwidth networks. They are also fault tolerant.
• Taps do not care if the traffic is IPv4 or IPv6, it passes all traffic through.
