Thanks Chuck! I'll put M back in my list. I tried it again on my network
and did get it! Yeah. (My testing was flawed before.)
I couldn't get & to happen either. By turning on debug ip packet detail, I
could see that I was receiving a TTL exceeded, even though the ping result
showed just .....
IP: s=172.16.20.1 (local), d=172.16.90.1 (TokenRing0), len 100, sending
ICMP type=8, code=0
IP: s=172.16.40.1 (TokenRing0), d=172.16.20.1 (TokenRing0), len 78, rcvd 3
ICMP type=11, code=0.
By the way, I stumbled on this somewhat helpful document:
http://www.cisco.com/warp/public/63/ping_traceroute.html
Couldn't find it by starting with the Tech Tips pages, but the search
engine found it when I searched on something bizarre.
I hope you understand my frustration now! ;-) Thanks for your support.
Priscilla
At 09:16 PM 7/4/01, Chuck Larrieu wrote:
>managed to get some rack time in this evening. some results:
>
>1) to answer the question about the ping response regarding MTU issues. Yes
>there is an "M" response. my lab set up was quite simple - linear, with the
>MTU set to 500 on one segment and using extended ping to send a 1500 byte
>packet. results:
>
>first - sending 100-byte packets - works just fine
>
>Router_1#
>Router_1#ping
>Protocol [ip]:
>Target IP address: 175.175.1.1
>Repeat count [5]:
>Datagram size [100]:
>Timeout in seconds [2]:
>Extended commands [n]: y
>Source address or interface: l 0
>Type of service [0]:
>Set DF bit in IP header? [no]: yes
>Validate reply data? [no]:
>Data pattern [0xABCD]:
>Loose, Strict, Record, Timestamp, Verbose[none]:
>Sweep range of sizes [n]:
>Type escape sequence to abort.
>Sending 5, 100-byte ICMP Echos to 175.175.1.1, timeout is 2 seconds:
>!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/16 ms
>Router_1#
>
>next - sending 1500-byte packets - get the big M!
>
>Router_1#
>Router_1#ping
>Protocol [ip]:
>Target IP address: 175.175.1.1
>Repeat count [5]:
>Datagram size [100]: 1500
>Timeout in seconds [2]:
>Extended commands [n]: y
>Source address or interface: l 0
>Type of service [0]:
>Set DF bit in IP header? [no]: yes
>Validate reply data? [no]:
>Data pattern [0xABCD]:
>Loose, Strict, Record, Timestamp, Verbose[none]:
>Sweep range of sizes [n]:
>Type escape sequence to abort.
>Sending 5, 1500-byte ICMP Echos to 175.175.1.1, timeout is 2 seconds:
>M.M.M Success rate is 0 percent (0/5)
>Router_1#
>Router_1#
>
>irritating annoyance - note the M.M.M why aren't they all M's????
>
>as far as the TTL exceed ( & )
>
>I can't get any such response.
>
>I set a routing loop and tested using the extended trace and 255 tries. I
>could see the loop between the two end points. A sample of the trace is
>provided.
>
>19 190.190.45.4 16 msec 12 msec 12 msec
> 20 190.190.45.5 12 msec 12 msec 16 msec
> 21 190.190.45.4 16 msec 16 msec 12 msec
> 22 190.190.45.5 12 msec 16 msec 408 msec
> 23 190.190.45.4 40 msec 36 msec 12 msec
> 24 190.190.45.5 12 msec 16 msec 16 msec
> 25 190.190.45.4 16 msec 16 msec 16 msec
> 26 190.190.45.5 16 msec 16 msec 16 msec
> 27 190.190.45.4 12 msec 16 msec 16 msec
>
>note the packets bouncing around.
>
>however - ping and extended ping ( setting the timeout to 10 seconds rather
>than default 2 seconds ) still reveals only the .....
>
>Router_1#ping 100.1.1.1
>
>Type escape sequence to abort.
>Sending 5, 100-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds:
>.....
>Success rate is 0 percent (0/5)
>
>Question: why have something, document something, and not use it? I can come
>up with no means of obtaining a TTL exceeded report. I wish I has a sniffer
>to see what was happening to the packets.
>
>In answer to your question about the tech docs, there are the release notes,
>obviously.
>
>the only other thing I can think is the TAC pages, which are no longer
>public. Persistent searching there often reveals some good stuff.
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
>Priscilla Oppenheimer
>Sent: Wednesday, July 04, 2001 6:53 PM
>To: [EMAIL PROTECTED]
>Subject: RE: ping replies [7:10910]
>
>
>At 11:07 AM 7/4/01, Chuck Larrieu wrote:
> >I admire your persistence. A quick look through several IOS versions'
> >command references, and the master command reference on CCO all indicate
> >that only a particular subset of the commands you mention below exist.
that
> >suggests to me that any responses other than the documented !.U&?CI may
>have
> >been put there for the software and networking guys' testing purposes.
>
>I have figured out the confusion. The other codes are for trace, not ping.
>Ping just outputs U for most errors, even when the router receives a more
>detailed ICMP message.
>
>
> >also, somewhere in the 11.x range, ping was taken from the system
>management
> >section to the troubleshooting section, for whatever reason.
>
>It is still in System Management. To find decent documentation on ping you
>have to go to:
>
>Configuration Guides and Command References
>Cisco IOS Configuration Fundamentals Command Reference
>System Management Commands
>Troubleshooting and Fault Management Commands
>
>CL: yep - that's where I went
>
>Make sure you don't go to Cisco IOS Configuration Fundamentals
>Configuration, because then you won't see the chart about the character
>codes. You have to go to the command reference. Note that this is backwards
>from most examples. Usually more detail would be in the configuration guide.
>
>You can also sometimes stumble on information using the search engine which
>finds documents in Tech Notes. What if you just want to start with Tech
>Notes? What and where are they?
>
>CL:Tech Notes apears to fall under http://www.cisco.com/warp/public/
>if you enter numbers after the last / you get various documents titled Tech
>Notes. I can't find an index page and trying to fake it with FTP doesn't
>seem to work.
>==========
>
>CL: ooohhhhh.... lookie here!
>http://www.cisco.com/public/technotes/serv_tips.shtml
>this may be the source of the tech notes pages. long lost. Cisco just loves
>to hide things
>check it out!!!!!!!!!!!!!!
>
>
>
>Priscilla
>
> >it was of minor
> >interest to see how the documentation has evolved over time. going back to
> >the 8.x and 9.x versions I saw a generally quite different organizational
> >structure.
> >
> >They teach us in CCIE class to use the doc CD ( CCO univerCD ) and drill
> >down. Obviously there are limitations to that approach. Were you checking
> >the TAC pages?
> >
> >Chuck
> >
> >-----Original Message-----
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> >Priscilla Oppenheimer
> >Sent: Wednesday, July 04, 2001 8:44 AM
> >To: [EMAIL PROTECTED]
> >Subject: Re: ping replies [7:10910]
> >
> >
> >I have seen E also, but only with AppleTalk. AppleTalk ping is AEP. IPX
> >ping has two versions -- Cisco proprietary and Novell compatible. As far
as
> >the other pings and trace routes, I don't know! I intend to find out
>though!
> >
> >In answer to the implied (from Chuck ;-) question as to why I should care
> >about Cisco's implementation and documentation for ping being bad....
> >
> >Well, I admit Cisco has more important things to worry about. But, what
> >command gets used the most on a Cisco router? Maybe show ip route. But I
> >bet it's ping. Why can't they output the results in plain language. Sure
we
> >have all gotten used to !!!, but why can't it just say "reply?" And why
has
> >the documentation for years claimed that all those other character codes
> >can happen even though they don't seem to happen?
> >
> >OK, I'm not going to go so far as to say that Cisco should have a GUI,
ugh,
> >but get with the times, for heavens sake. Maybe configuring class-based
> >weighted-fair queuing, or policy routing, or dial peers, has to be
> >complicated, but using ping doesn't have to be!
> >
> >And while I'm at it, why is the documentation for ping, buried in the
> >System Management documentation. Couldn't it be somewhere obvious? And
even
> >in that documentation, the character codes couldn't be found (if I
recall).
> >I had to use the index to find the 20 different versions of the character
> >code table.
> >
> >Using the index did cause me to learn something else. Did you know that
> >there is an SNA ping? It opens an APPC session.
> >
> >Priscilla
> >
> >At 02:24 AM 7/4/01, nrf wrote:
> > >I have seen an 'E', but only with failed Appletalk pings, never in IP.
> > >
> > >Question (slightly off-topic, my apologies, Priscilla) - does anybody
>know
> > >exactly how Cisco implements ping and trace in non-IP protocols? With
> > >Appletalk, I presume it has something to do with AEP, but how about a
IPX
> > >trace, what's going on there? Or a Decnet/Vines/Apollo/CLNS/XNS ping,
> > >what's up with those?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >""Priscilla Oppenheimer"" wrote in message
> > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > > As we all know, ping is really an ICMP echo. There are many possible
> >ICMP
> > > > replies. Now, Cisco could tell the user of the Cisco IOS ping command
> >the
> > > > actual reply received, but instead they output a character code.
> >(Wouldn't
> > > > want to make the product intuitive, now would we?) I'm trying to get
> >more
> > > > data on the character codes.
> > > >
> > > > This is not a newbie question. Don't send me the chart of ping reply
> > >codes.
> > > > I've already seen about 20 versions of the chart. I'm trying to
figure
> >out
> > > > what routers really display and why there are so many versions of the
> > > > chart. Putting together all versions of the chart (plus the A code
>that
> >we
> > > > have all seen but is not listed in Cisco documentation, as far as I
>can
> > > > tell), I have developed this list:
> > > >
> > > > ! An ICMP echo reply was received.
> > > > . The sending router or switch timed out while waiting for a reply.
> > > > U A destination unreachable response was received.
> > > > N A network unreachable response was received.
> > > > H A host unreachable response was received.
> > > > P A protocol unreachable response was received.
> > > > M Fragmentation was needed and the don't fragment (DF) bit was set.
> > > > & A time-to-live exceeded message was received.
> > > > I The user interrupted the test.
> > > > A The ping was administratively prohibited (blocked by an access list
> > > > probably).
> > > > Q A source quench response was received.
> > > > ? An unknown packet was received.
> > > > C A packet was received with the congestion-experienced bit set.**
> > > >
> > > > Questions:
> > > >
> > > > Has anyone ever seen N, H, or P? It seems to me that Cisco just
>outputs
> >U
> > > > if the router receives network, host, or protocol unreachable.
> > > >
> > > > Has anyone ever seen M? I couldn't get this to happen in my lab. Is M
> >even
> > > > for real or was that an error in one of the versions of the
> >documentation?
> > > >
> > > > Has anyone every seen &? I couldn't get that one to happen either.
> > > >
> > > > How about I? That doesn't happen on my routers. Plus one version of
>the
> > > > documentation said it was |, not I.
> > > >
> > > > And how about the mysterious C? I found out that it's related to RFC
> >2481,
> > > > an experimental protocol that adds explicit congestion notification
to
> >IP.
> > > > Maybe some internal developer asked for this. Cisco clearly favors
> >helping
> > > > developers troubleshoot over helping customers troubleshoot. (Sorry,
>but
> > > > this ping research has made me angry at Cisco.)
> > > >
> > > > Thanks for your help.
> > > >
> > > > Priscilla
> > > >
> > > >
> > > >
> > > > ________________________
> > > >
> > > > Priscilla Oppenheimer
> > > > http://www.priscilla.com
> >________________________
> >
> >Priscilla Oppenheimer
> >http://www.priscilla.com
>________________________
>
>Priscilla Oppenheimer
>http://www.priscilla.com
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=11097&t=11097
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
