port monitoring

Discussion in 'Cisco' started by stopnowgo, Jun 21, 2006.

  1. stopnowgo

    stopnowgo Guest

    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.
     
    stopnowgo, Jun 21, 2006
    #1
    1. Advertising

  2. In article <>,
    stopnowgo <> 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.
     
    Walter Roberson, Jun 22, 2006
    #2
    1. Advertising

  3. stopnowgo

    stopnowgo Guest

    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
     
    stopnowgo, Jun 22, 2006
    #3
  4. stopnowgo

    stopnowgo Guest

    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
     
    stopnowgo, Jun 22, 2006
    #4
  5. In article <>,
    stopnowgo <> 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...._frm/thread/14e20fa4c87d6602/ef31aa9b43cf2f4f
     
    Walter Roberson, Jun 22, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. joeblow
    Replies:
    2
    Views:
    650
    AnyBody43
    Jun 10, 2004
  2. Replies:
    0
    Views:
    1,007
  3. erman

    USB port monitoring

    erman, Dec 9, 2003, in forum: Computer Support
    Replies:
    0
    Views:
    623
    erman
    Dec 9, 2003
  4. VongZa
    Replies:
    1
    Views:
    401
  5. VongZa

    port monitoring mechanism

    VongZa, Feb 8, 2007, in forum: Cisco
    Replies:
    1
    Views:
    363
    Walter Roberson
    Feb 8, 2007
Loading...

Share This Page