TD - Sales International Holland B.V. [mailto:[EMAIL PROTECTED]] wrote:
> Question on the switch here. A switch is used to speed up > networks among > other things. No. A switch is used to increase overall network bandwidth by providing multiple collision domains and separate pipes to different highly-utilized devices. The effect is that performance will generally improve, but the only speed change is the possibility to communicate at full-duplex. However, it is also possible that a switch can REDUCE performance. If you have a busy network, cannot take advantage of full-duplex, and all of your traffic goes to or comes from one network device (i.e., your only server, which also acts as a proxy), then a switch can actually REDUCE performance due to the latency involved in getting a packet through the switch. > 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? First, let's look at switch congestion in general. Most switches have buffer memory. This is RAM that is used to temporarily store incoming network packets until they can be forwarded to the appropriate outgoing port. Once the switch's buffer(s) is full, it should use flow control to slow the pace of incoming packets. Different flow control will be used, depending on whether the attached device is operating at half or full duplex. If in half-duplex mode, the switch should simulate a collision back to the device. In full-duplex mode, the switch should send the overflowing packet(s) back to the source. In practice, I don't know if the source knows what to do with a packet returned by flow control. I think it just ignores it, and then an upper layer (3 for TCP, 7 or 8 for UDP) treats the event as a dropped packet (by the way, layer 8 -- also referred to as the Bozo Layer -- is the user acting on an Abort, Retry, Ignore network error message). Now, looking at port monitoring specifically, we have the individual port saturation problem (more than 100mbps of data out one port). But we also have a bigger problem: the switch's backplane and processor bandwidth. If you exceed the port bandwidth, the switch should just discard overflow from the buffer. Of course, this means you won't be able to capture every packet, but what's a reasonable alternative? However, if you saturate the switch backplane or processor, then packets will start backing-up on all the ports, which will result in all the ports getting flow control or the switch might, as you say, "freak out". Since the majority of switches are blocking, (i.e., they don't have sufficient backplane or processor bandwidth to accommodate all ports at full utilization), you need to be selective when you setup monitoring.
