Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > Monitoring (sniffing) switch traffic - Back to basics

Reply
Thread Tools

Monitoring (sniffing) switch traffic - Back to basics

 
 
Johnny Noitargim
Guest
Posts: n/a
 
      02-26-2005
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


 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      02-26-2005
In article <421fc321$0$53240$(E-Mail Removed)>,
Johnny Noitargim <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Johnny Noitargim
Guest
Posts: n/a
 
      02-26-2005
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" <(E-Mail Removed)-cnrc.gc.ca> wrote in message
news:cvoi6c$25f$(E-Mail Removed)...
> In article <421fc321$0$53240$(E-Mail Removed)>,
> Johnny Noitargim <(E-Mail Removed)> 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



 
Reply With Quote
 
Arnold Nipper
Guest
Posts: n/a
 
      02-26-2005
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
 
Reply With Quote
 
Johnny Noitargim
Guest
Posts: n/a
 
      02-26-2005
How can I do that?



"Arnold Nipper" <(E-Mail Removed)> wrote in message
news:cvqjeg$lie$(E-Mail Removed)...
> 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



 
Reply With Quote
 
Arnold Nipper
Guest
Posts: n/a
 
      02-26-2005
On 26.02.2005 23:29 Johnny Noitargim wrote

> How can I do that?
>


Ask the IT boss.


Arnold

>
>
> "Arnold Nipper" <(E-Mail Removed)> wrote in message
> news:cvqjeg$lie$(E-Mail Removed)...
>> 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

>
>

 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      02-26-2005
In article <4220cd9e$0$31681$(E-Mail Removed)>,
Johnny Noitargim <(E-Mail Removed)> 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.
 
Reply With Quote
 
thrill5
Guest
Posts: n/a
 
      02-27-2005
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" <(E-Mail Removed)-cnrc.gc.ca> wrote in message
news:cvr0h6$81f$(E-Mail Removed)...
> In article <4220cd9e$0$31681$(E-Mail Removed)>,
> Johnny Noitargim <(E-Mail Removed)> 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.



 
Reply With Quote
 
Williams Williams is offline
Junior Member
Join Date: Nov 2009
Posts: 25
 
      09-09-2010
For monitor your using protemac. com ProteMac Meter.It's nice prog.Thanks)
 
Reply With Quote
 
nover nover is offline
Junior Member
Join Date: Nov 2010
Posts: 5
 
      11-15-2010
as for me I prefer to use ProteMac Meter (protemac.com)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Two Cisco switch connected back to back ping issue Jaseela Cisco 0 01-20-2010 05:43 AM
back to basics on divisions richard HTML 4 04-14-2008 02:17 AM
congesting a back-to-back link on a switch akmann7@gmail.com Cisco 1 07-07-2007 12:31 PM
Back to the basics Ken Davey Digital Photography 7 10-09-2006 12:06 AM
Monitoring traffic through router and switch? Ramon F Herrera Cisco 1 11-23-2003 07:58 AM



Advertisments