Monitoring (sniffing) switch traffic - Back to basics

Discussion in 'Cisco' started by Johnny Noitargim, Feb 26, 2005.

  1. Hi everyone,

    I have recently started looking into detail into the traffic that goes
    through some of my switches as we noticed some considerable slowness to end
    users when I was running a backup during the day.

    The switch design in this wiring closet is (3550 Aggregator 'feeding' 4 x
    3548 swiches). All kit obviously catalyst.

    I started using Netasyst to 'sniff' some of the problems but I need to get
    some things straight before going into more detail about my problem. When
    sniffing one of the switch ports I can see a lot of traffic (port is not in
    span mode) going from and to various servers. This traffic does not look
    like multi or broadcast. It looks more like point to point as I can clearly
    see the source and destination of the packet.

    I always thought that the switch port would not show anything on a sniffer
    if no traffic was destined for that port. Is this not the case?

    I look forward to some feedback so that we can analyse this further...

    Many thanks in advance,

    Johny
     
    Johnny Noitargim, Feb 26, 2005
    #1
    1. Advertising

  2. In article <421fc321$0$53240$>,
    Johnny Noitargim <> wrote:
    :I always thought that the switch port would not show anything on a sniffer
    :if no traffic was destined for that port. Is this not the case?

    1) If the MAC table fills up, then all packets for unknown MACs will
    be flooded to all ports in the same VLAN; this will continue to happen
    until space becomes free in the MAC table;

    2) If the destination MAC for a packet is unknown to the switch, then
    the packet will be flooded to all ports in the same VLAN. This usually
    happens a small number of times, as the first reply packet back will
    tell the switch what port the MAC is on, obliviating the need to flood.
    However, if there is assymetric routing leading to the switch never
    seeing the response packets, then the switch will have to continue to
    flood the packets to that destination.

    You are probably seeing the first half of #2.
    --
    'ignorandus (Latin): "deserving not to be known"'
    -- Journal of Self-Referentialism
     
    Walter Roberson, Feb 26, 2005
    #2
    1. Advertising

  3. Walter,

    thank you for taking the time to reply.

    On # 2 you refer to 'assymetric' routing causing the switch never to see the
    response packet... Is this something that I can undo or design around?

    Thanks,

    J.



    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:cvoi6c$25f$...
    > In article <421fc321$0$53240$>,
    > Johnny Noitargim <> wrote:
    > :I always thought that the switch port would not show anything on a

    sniffer
    > :if no traffic was destined for that port. Is this not the case?
    >
    > 1) If the MAC table fills up, then all packets for unknown MACs will
    > be flooded to all ports in the same VLAN; this will continue to happen
    > until space becomes free in the MAC table;
    >
    > 2) If the destination MAC for a packet is unknown to the switch, then
    > the packet will be flooded to all ports in the same VLAN. This usually
    > happens a small number of times, as the first reply packet back will
    > tell the switch what port the MAC is on, obliviating the need to flood.
    > However, if there is assymetric routing leading to the switch never
    > seeing the response packets, then the switch will have to continue to
    > flood the packets to that destination.
    >
    > You are probably seeing the first half of #2.
    > --
    > 'ignorandus (Latin): "deserving not to be known"'
    > -- Journal of Self-Referentialism
     
    Johnny Noitargim, Feb 26, 2005
    #3
  4. On 26.02.2005 20:27 Johnny Noitargim wrote

    > Walter,
    >
    > thank you for taking the time to reply.
    >
    > On # 2 you refer to 'assymetric' routing causing the switch never to see the
    > response packet... Is this something that I can undo or design around?
    >


    Only if you have control over the whole network. Then you could make the
    backtraffic take the same way.




    Arnold
    --
    Arnold Nipper, AN45
     
    Arnold Nipper, Feb 26, 2005
    #4
  5. How can I do that?



    "Arnold Nipper" <> wrote in message
    news:cvqjeg$lie$...
    > On 26.02.2005 20:27 Johnny Noitargim wrote
    >
    > > Walter,
    > >
    > > thank you for taking the time to reply.
    > >
    > > On # 2 you refer to 'assymetric' routing causing the switch never to see

    the
    > > response packet... Is this something that I can undo or design around?
    > >

    >
    > Only if you have control over the whole network. Then you could make the
    > backtraffic take the same way.
    >
    >
    >
    >
    > Arnold
    > --
    > Arnold Nipper, AN45
     
    Johnny Noitargim, Feb 26, 2005
    #5
  6. On 26.02.2005 23:29 Johnny Noitargim wrote

    > How can I do that?
    >


    Ask the IT boss.


    Arnold

    >
    >
    > "Arnold Nipper" <> wrote in message
    > news:cvqjeg$lie$...
    >> On 26.02.2005 20:27 Johnny Noitargim wrote
    >>
    >> > Walter,
    >> >
    >> > thank you for taking the time to reply.
    >> >
    >> > On # 2 you refer to 'assymetric' routing causing the switch never to see

    > the
    >> > response packet... Is this something that I can undo or design around?
    >> >

    >>
    >> Only if you have control over the whole network. Then you could make the
    >> backtraffic take the same way.
    >>
    >>
    >>
    >>
    >> Arnold
    >> --
    >> Arnold Nipper, AN45

    >
    >
     
    Arnold Nipper, Feb 26, 2005
    #6
  7. In article <4220cd9e$0$31681$>,
    Johnny Noitargim <> wrote:
    :On # 2 you refer to 'assymetric' routing causing the switch never to see the
    :response packet... Is this something that I can undo or design around?

    I would expect you are just seeing the flooding of packets when the MAC
    isn't yet known. Asymmetric routing is not particularily common.
    It does happen though, and can be difficult sometimes to track down.

    Some things that have just come to mind that can lead to asymmetric
    flows:

    1) there is a cluster system in which inward packets are sent
    to a certain MAC (a virtual MAC) but the replies come from the
    MAC of the individual machine. Well designed cluster systems send
    from the virtual MAC, but not all clusters are well designed.

    2) if you have a VLAN leak so a port can hear packets from
    multiple VLANs but can only send through one of them, then you
    can end up with asymmetric flows;

    3) if you have a VLAN topology loop that is being successfully pruned
    by the spanning tree, but one of the switches involved does not
    support per-VLAN spanning tree, then that switch can end up
    "flapping" the MAC<->port association.
    --
    Before responding, take into account the possibility that the Universe
    was created just an instant ago, and that you have not actually read
    anything, but were instead created intact with a memory of having read it.
     
    Walter Roberson, Feb 26, 2005
    #7
  8. Johnny Noitargim

    thrill5 Guest

    If you have asymetric routing and are using a L2/L3 switch as the router,
    the problem is easily solved. You need to set the ARP timeout to same value
    as the CAM timeout. CAM entries timeout after 5 minutes, while the default
    ARP timeout is 4 hours. On each vlan router interface, enter the command
    "arp timeout 300". The problem is that the at Layer 3, the packet is
    routed, and the destination MAC of the next hop is known from the ARP entry.
    At layer 2, the MAC address is unknown because traffic from this device uses
    a different path and goes to a different switch. If no traffic FROM this
    device is seen after 300 seconds (the default CAM aging timer), the CAM
    entry is aged out, and the traffic is sent as unicast flood to all the ports
    in the VLAN because the MAC is unknown. If you set the ARP timeout to 300
    seconds, the ARP entriy will timeout after 300 seconds, and it send an ARP.
    The ARP reply will then populate the CAM table and it will no longer be sent
    as a unicast flood. IMHO this is "bug" in IOS, and the default ARP value
    should be set to same value as the CAM aging value.

    Scott
    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:cvr0h6$81f$...
    > In article <4220cd9e$0$31681$>,
    > Johnny Noitargim <> wrote:
    > :On # 2 you refer to 'assymetric' routing causing the switch never to see
    > the
    > :response packet... Is this something that I can undo or design around?
    >
    > I would expect you are just seeing the flooding of packets when the MAC
    > isn't yet known. Asymmetric routing is not particularily common.
    > It does happen though, and can be difficult sometimes to track down.
    >
    > Some things that have just come to mind that can lead to asymmetric
    > flows:
    >
    > 1) there is a cluster system in which inward packets are sent
    > to a certain MAC (a virtual MAC) but the replies come from the
    > MAC of the individual machine. Well designed cluster systems send
    > from the virtual MAC, but not all clusters are well designed.
    >
    > 2) if you have a VLAN leak so a port can hear packets from
    > multiple VLANs but can only send through one of them, then you
    > can end up with asymmetric flows;
    >
    > 3) if you have a VLAN topology loop that is being successfully pruned
    > by the spanning tree, but one of the switches involved does not
    > support per-VLAN spanning tree, then that switch can end up
    > "flapping" the MAC<->port association.
    > --
    > Before responding, take into account the possibility that the Universe
    > was created just an instant ago, and that you have not actually read
    > anything, but were instead created intact with a memory of having read it.
     
    thrill5, Feb 27, 2005
    #8
  9. Johnny Noitargim

    Williams

    Joined:
    Nov 17, 2009
    Messages:
    25
    For monitor your using protemac. com ProteMac Meter.It's nice prog.Thanks)
     
    Williams, Sep 9, 2010
    #9
  10. Johnny Noitargim

    nover

    Joined:
    Nov 15, 2010
    Messages:
    5
    as for me I prefer to use ProteMac Meter (protemac.com)
     
    nover, Nov 15, 2010
    #10
    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. Ramon F Herrera
    Replies:
    1
    Views:
    532
  2. AM
    Replies:
    1
    Views:
    1,745
  3. SplkBarney
    Replies:
    4
    Views:
    784
  4. SplkBarney
    Replies:
    5
    Views:
    563
    SplkBarney
    Sep 1, 2005
  5. Sako
    Replies:
    5
    Views:
    673
    Scooby
    Oct 5, 2006
Loading...

Share This Page