It depends upon the switch. In my experience, if you generate enough traffic to saturate the bus of a Cisco, you generally get dropped packets at the switch. If the aggregate traffic is greater than the the bandwidth of monitoring port, you _will_ get dropped packets.
You would be surprised, however, how little this actually happens, due to the bursty nature of most network traffic. Unless you're monitoring multiple high-resolution video streams or some such, you should be all right. If this becomes a problem, then you will need to place your sensor somewhere else upstream to make sure that you don't get flooded out. Chris > -----Original Message----- > From: TD - Sales International Holland B.V. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 14, 2001 3:59 AM > 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 >
