Prev: Cat 4003 issue
Next: WAN Emulator
From: stopnowgo on 21 Jun 2006 16:16
Does port monitoring cause a performance hit on a switch, especially if
several (or all) of the ports on the switch are monitored by one port?
We have no user complaints but do not fully understand what the port
monitor command does to the performance of a switch. We have Cisco
3548's. If performance is affected are there any commands that can show
us what is going on. Any help or suggestions is appreciated.

From: Walter Roberson on 21 Jun 2006 21:25
In article <1150920984.663354.16890(a)y41g2000cwy.googlegroups.com>,
stopnowgo <adam.rothschild(a)gmail.com> wrote:
>Does port monitoring cause a performance hit on a switch, especially if
>several (or all) of the ports on the switch are monitored by one port?

It depends on the switch design.

And of course if the total volume monitored exceeds the transmission
capacity of the monitoring port then you will have problems.

>We have no user complaints but do not fully understand what the port
>monitor command does to the performance of a switch. We have Cisco
>3548's. If performance is affected are there any commands that can show
>us what is going on. Any help or suggestions is appreciated.

show cpu would show the performance effects.

I don't recognize the 3548 model at the moment. Is it better known
as a 3548XL ? The 3500XL series is an older generation of switches
and I don't know anything about the internals.

On the newer Cat3550 and Cat3750, all the packets flow through a common
bus, with a bit set in the header for each port that is to receive the
packet, so there is no particular performance drop for monitoring
(except any involved in selecting which packets should be monitored)
as no extra copies of the packet get made on the bus.

From: stopnowgo on 22 Jun 2006 11:09
they are 3500XL's, here is some other info I gathered from the web. The
monitoring port should be the only thing to take a performance dive, by
dropping packets. Any thoughts on this? I thought maybe there was some
type of flow control? My setup is such that 1 etherent port is
monitoring 46 other ethernet ports(no all in use) minus the to ports
that tha sniffer is using. Let me know if you have any more info, Thanks

From: stopnowgo on 22 Jun 2006 11:09
they are 3500XL's, here is some other info I gathered from the web. The
monitoring port should be the only thing to take a performance dive, by
dropping packets. Any thoughts on this? I thought maybe there was some
type of flow control? My setup is such that 1 etherent port is
monitoring 46 other ethernet ports(no all in use) minus the to ports
that tha sniffer is using. Let me know if you have any more info, Thanks

From: Walter Roberson on 22 Jun 2006 13:12
In article <1150988940.990706.256360(a)u72g2000cwu.googlegroups.com>,
stopnowgo <adam.rothschild(a)gmail.com> wrote:

Please quote context. Please see here for information on how to
do so from Google Groups: http://cfaj.freeshell.org/google/

>they are 3500XL's, here is some other info I gathered from the web. The
>monitoring port should be the only thing to take a performance dive, by
>dropping packets. Any thoughts on this? I thought maybe there was some
>type of flow control?

What is your interface flow-control set to?
http://www.cisco.com/univercd/cc/td/doc/product/lan/c2900xl/29_35xw/1061504.htm#16307


It is not uncommon on switches (and routers) that when a port is set to
be a monitoring port, that the device operating system turns off listening
on the port, so that what is output over the line is *only* the
monitored traffic. And besides, there is no certainty that the next
device down supports sending PAUSE frames.


Internally, if the traffic to be monitored arrives faster than the
rate at which packets can be transmitted through the monitoring port,
then packets will get buffered -- but there is a limit to the buffer size.
The switch is not going to send PAUSE frames to all the ports being
monitored to get them to stop sending long enough for the output queue
to drain: if it did that, then the monitoring would interfere with
the normal traffic. Besides, some of the monitored ports might be
half-duplex, and that doesn't support PAUSE frames; the switch could,
I suppose, deliberately send out collision signals on the port, but
if it did that, there would be a risk of "too many collisions" resulting
in the incoming packet being dropped (and if that happens too often,
then the sender might decide that the link is faulty and disable the
link...)

The easiest way to resolve all of this without interfering with the
normal switch traffic is for the monitoring port to buffer only
as much as it can, and for excess packets to be dropped. This does
mean that the received monitored traffic does not necessarily contain
all of the packets that passed through the switch, but really you
have to expect something like that if your monitoring port is not at
least as fast as the total traffic being monitored.

Also, you should be aware that if you are monitoring packets at
high throughput, that you either need a hardware monitoring
appliance designed for that purpose, or else you need a well
designed and tuned monitoring computer. For more on this topic, see
http://groups.google.ca/group/comp.protocols.tcp-ip/browse_frm/thread/14e20fa4c87d6602/ef31aa9b43cf2f4f

 | 
Pages: 1
Prev: Cat 4003 issue
Next: WAN Emulator