s vermill wrote: > > Priscilla Oppenheimer wrote: > > > > Hale Nick wrote: > > > > > > Scenario: > > > Cat 6509 (SW 5.5(16)) with MSFC (Version 12.1(1)E). > > > The MSFC has over 15 vlans. > > > The vlan in question has over 60 active devices. > > > There is one device that when pinged (datagram size does not > > > change the result) it produces a source quench. > > > > Source quench comes from the host (end device) that you're > > pinging. That device is probably just too busy to respond to > > pings. This isn't necessarily a problem. The definition of > "too > > busy" is operating system and version-dependent. > > That's interesting. I always thought a source quench was > reserved for scenarios where the receiver was getting hammered > (maybe a server on an FE port drowning a PC on a 10 Mbps > port). I would think it would be just as costly to generate a > source quench response as it would be to generate an ICMP echo > reply. Or is the pinging device supposed to immediately stop > repeated pings altogether, thereby ensuring that the receiver > was only going to need to send one response vs. possibly many?
Yes, the sender should quench itself. That reduces the load on the recipient. > If so, does that really happen in practice? Do you mean does the sender really quench itself? It should, but I wouldn't be surprised if some applications don't stop or don't stop right away anyway. RFC 1122 says this: "If a Source Quench message is received, the IP layer MUST report it to the transport layer (or ICMP processing). In general, the transport or application layer SHOULD implement a mechanism to respond to Source Quench for any protocol that can send a sequence of datagrams to the same destination and which can reasonably be expected to maintain enough state information to make this feasible." Source quench is hardly ever used by anything. I hope the original poster can tell use what was sending it. The other responder implied that a router or switch might be sending it. I highly doubt that. As mentioned earlier, per RFC 1812, published in 1995, routers shouldn't send it. Layer 3 switches shouldn't send it either. Layer 2 switches, of course, wouldn't send it anyway. They don't do Layer 3 stuff. Priscilla > > > > > In the olden days, routers used to send source quench. That > was > > determined to be a useless feature. Per RFC 1812, > "Requirements > > for IP Version 4 Routers," a router should not originate > source > > quench messages. A host may send source quench messages, > > however, per RFC 1122, "Requirements for Internet Hosts." > > > > What is the device that you're pinging? What's the operating > > system? What version? Some operating systems send source > quench > > almost immediately after just a couple pings. For example, Mac > > OS used to do this. I can't remember which version, but it's > > pre-Mac OS X, e.g. pre-UNIX. > > > > > All other devices on the vlan respond to pings ok. > > > From the command prompt on my desktop the result is the > same. > > > From a unix server the ping results are normal. > > > > Are you saying that when you ping from a UNIX server to the > > device in question, you don't get a source quench? That seems > > weird. But it could happen if the UNIX ping sends less > > frequently and so doesn't trigger the recipient to go into > > quenching mode. > > > > > From the switch the ping results are normal. > > > > Pinging from the switch doesn't result in source quench > either? > > Is it just when you ping from the command prompt on your > > desktop? That ping must send more quickly. Try telling the > ping > > to let more time elapse between each ping. If it's the DOS > > ping, you can't do this, though. The -w option is only a > > timeout between unsuccessful pings, unfortunately. > > > > > Specifications of the server are unknown. > > > > What server? If you mean specifications of the ping recipient > > are unknown, then the reason you're seeing this result will be > > unknown also. :-) > > > > > The port that the device connects to is set to 100/full and > > has > > > no errors. > > > The MSFC and switch resources are fine > > > The vlan interface does not have any errors. > > > The switch and router module are both heavily used and it > > > appears this issue is only happening to the one device. > > > > Yes, it would be device-dependent. Source quench comes from > the > > recipient. It just means it's busy, as I mentioned. > > > > _______________________________ > > > > Priscilla Oppenheimer > > www.troubleshootingnetworks.com > > www.priscilla.com > > > > > > > > > > > Can anyone tell me why this is happening? > > > > > > > > > > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57892&t=57870 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
