Monitoring (sniffing) switch traffic - Back to basics

Monitoring (sniffing) switch traffic - Back to basics
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.sys.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
Monitoring (sniffing) switch traffic - Back to basics Johnny Noitargim 02-26-2005
Posted by Johnny Noitargim on February 26, 2005, 12:30 am
If you were  Registered and logged in, you could reply and use other advanced thread options
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




Pure Networks
Posted by Walter Roberson on February 26, 2005, 1:08 am
If you were  Registered and logged in, you could reply and use other advanced thread options
: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


Posted by Johnny Noitargim on February 26, 2005, 7:27 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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.



> :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




Posted by Arnold Nipper on February 26, 2005, 8:42 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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


Posted by Johnny Noitargim on February 26, 2005, 10:29 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
How can I do that?



> 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




Similar ThreadsPosted
congesting a back-to-back link on a switch July 7, 2007, 2:25 am
Configure switch for sniffing October 3, 2006, 12:56 pm
Seeing unexpected skinny heartbeats when sniffing IP phone's network traffic August 24, 2005, 1:08 pm
PIX 501 website traffic out and come back in March 24, 2007, 7:01 pm
traffic monitoring November 28, 2006, 8:01 pm
4510R and traffic monitoring June 7, 2005, 8:01 am
Monitoring specific traffic. October 3, 2006, 3:31 am
dual router back to back serial connection (2501 <-> 2620) September 23, 2006, 7:43 pm
Monitoring network traffic on Cisco 1800 series November 18, 2008, 2:44 am
encapsulation failed when add 'dialer inband' (aux back to back) July 19, 2004, 12:29 am

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map