Don't forget that switch have ingress (inward) and egress (outward) buffers (memory allocation blocks) on each port - or at least divided up and appropriated to each port. Although the traffic generated in that split second of throughput exceeds 100mb/s the buffer queues come into play and logically 'manage' the traffic flow.
Plus, as long as you have got enough of a buffer set on your sniffer software you should not miss any packets. d. "The OSI model has 9 layers, not 7. Two of them are hidden. Politics & Finance...." -----Original Message----- From: TD - Sales International Holland B.V. [mailto:[EMAIL PROTECTED]] Sent: 14 November 2001 09:59 To: Chris Eidem; [EMAIL PROTECTED] Subject: Re: Packet Sniffing in a Switched LAN Question on the switch here. A switch is used to speed up networks among other things. Now using the example below and setting P6 to a monitoring port is ofcourse a way to do it. However what happens if P1 till P5 generate a total of more than 100Mbit of traffic (which can happen on a switch). What will happen to the data going out through P6? Will packets be dropped, will the rest of the network be slowed down, will the switch freak out? What's going to happen? Regards On Monday 12 November 2001 22:53, Chris Eidem stuffed this into my mailbox: > OK, 50,000 foot description. > > Level 2 (you know your OSI layers, right?) on a hub is a simple > repeater. Packet comes in one port and is transmitted to all ports. > Level 2 on a switch is different because the collision domain (the > ethernet wire in this case) is simply between the host and the switch. > The switch then looks up the MAC of the next hop in a table that it > keeps in memory and then places the packets on the port where the MAC is > destined to go, omitting the broadcast traffic to the rest of the ports. > > a picture of a mythical 6 port hub: > > Hub P > > +------------------------+ > > | P1 P2 P3 P4 P5 P6 | > > +------------------------+ > ^ | | | | | > > | * * * * * > > -----+ > > packet goes in P1 and broadcast out P2-P6. > > Now the host on P1 want to send to P4, but P is now a switch: > > > Switch P Lookup table > > +------------------------+ MAC Port > > | P1 P2 P3 P4 P5 P6 | ------------ > > +------------------------+ host1 P1 > ^ | host2 P4 > > | * host3 P6 > > -----+ host4 P2 > > The switch has a lookup table that maps the receiving host's MAC with P4 > and sends it there. > > So, if you are on a switch and you want to see the conversation between > the host on P1 and the host on P4 while your host is on P6, you're outta > luck. Traffic is going straight between P1 and P4. You need to enlist > the switch's help by turning P6 into a monitor port and that will mirror > all traffic to P6 and then you can use ethereal to see it all or use > something like the dsniff tools to mess up the arptables. > > Chris > > > -----Original Message----- > > From: Marc Mc Guinness [mailto:[EMAIL PROTECTED]] > > Sent: Friday, November 09, 2001 5:32 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Packet Sniffing in a Switched LAN > > > > > > Hello! > > > > Am Donnerstag, 8. November 2001 23:24 schrieb Matt Hemingway: > > > If it's a switched network, which the subject of this e-mail > > > states, than Ethereal won't work. The best tool for a switched > > > network is ettercap (ettercap.sourceforge.net). > > > > > > Personally I use Arpwatch (no url available) to find all hosts on > > > the network and than use Ettercap to sniff the victim. > > > > > > If this is a hubbed network than Ethereal works like a charm. > > > > I don't understand that. Can anybody explain it to me? Why is > > ethereal not good for a switched LAN, but for a hubbed one it is? > > I'm starting to work with ethereal at the moment (in a switched > > network). > > > > Best regards, > > > > Marc Mc Guinness
