RE: Souce Quench to a device from an MSFC [7:57870] posted 11/22/2002
- Subject: RE: Souce Quench to a device from an MSFC [7:57870]
- From: "Priscilla Oppenheimer" <nobody@xxxxxxxxxxxxxx>
- Date: Fri, 22 Nov 2002 19:38:13 GMT
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
> > 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.
> > In the olden days, routers used to send source quench. That
> > determined to be a useless feature. Per RFC 1812,
> > for IP Version 4 Routers," a router should not originate
> > 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
> > 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
> > > 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
> > Is it just when you ping from the command prompt on your
> > desktop? That ping must send more quickly. Try telling the
> > 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
> > 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:
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to abuse@xxxxxxxxxxxxxx