The high level of interest in my previous blog Is Spanning Bad has prompted me to follow up with the “sequel” - RSPAN (Remote SPAN). Keep those emails coming!
In a nutshell, the Cisco RSPAN feature supports source and destination ports distributed across multiple switches, allowing one to monitor any port located on the same VLAN. This avoids having to move the analyzer to another switch and allows for some interesting monitoring possibilities like picking up packets from a specific port in a multi-switch VLAN.
The downside is twofold: 1) the packet timing (i.e. the timestamp that the analyzer will generate when eventually receiving it’s copy of the packet) will not be the true timestamp of when it was received at the remote port and 2) copies of packets in high volume situations can impact regular traffic in the switching fabric both inside and outside the switch (i.e. the interconnection).
Be sure to weigh the pros and cons when using RSPAN. Alternatives include use of dedicated taps, switchable or “matrix” taps (support for both Datacom Systems and NetOptics matrix taps is integrated into our Omni distributed analysis solution) or even dedicated analysis engines at strategic switch points. Our Enterprise Services Group can help you make the most of your SPANing and tapping requirements.
More SPAN Dept.
Some of you asked for more information about SPAN architecture realizing that not every switch mirroring technique is identical and the impact on the CPU can vary dramatically. Shared memory also plays a role in certain Cisco architectures (see link below). Another vendor, Foundry Networks, has a slick feature in their switch/routers where an inbound port takes care of sending routed packets (that bypass the CPU in the first place) to both the outbound and mirror ports. Be sure to consult your vendor if you are not able to find operational specifics for your particular device.