RE: ping replies [7:10910] longish! [7:10910]
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marty Adkins Sent: Thursday, July 05, 2001 1:14 PM To: [EMAIL PROTECTED] Subject: Re: ping replies [7:10910] longish! [7:10910] Actually I prefer M&Ms, doesn't everyone? Sorry, chocoholic attack. :-) CL: M&M&M - my mind reels at the routing mess that would result in such a strange ping report:-> Thanks to both of you for digging and actually trying these on real gear -- it helps everyone learn much more thoroughly. CL: thanks too for your observations. goes to show - the important job for a router is to forward packets. makes sense to me. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=11151&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ping replies [7:10910] longish! [7:10910]
Priscilla Oppenheimer wrote: > > 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. > Great article, Priscilla -- thanks for sharing! At 09:16 PM 7/4/01, Chuck Larrieu wrote: > >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 Actually I prefer M&Ms, doesn't everyone? Sorry, chocoholic attack. :-) The router which generated the ICMP message rate-limited same to no greater than one per second per source IP. It's one way that IOS tries to prevent one errant traffic stream from impacting others. Note that as soon as the first "M" was received by Router_1, it immediately fired off the second ping. Hence the downstream router decided not to generate another ICMP message, forcing Router_1 to time out (in two seconds). Ping #3 occurred more than one second after #2, so the ICMP message was generated. And so on... The more common pattern seen is "U.U.U" for host unreachable. To explain a bit further about the rationale, remember that the downstream router would really like to spend its resources successfully forwarding packets, in a fast-switching mode (fast/CEF/optimum/whatever). This is performed in interrupt mode. It's not possible to generate new messages in interrupt mode, so all exception cases must be handled by an IOS process (IP input). Doing this is more CPU and buffer expensive and competes with successful traffic flows. So IOS throttles this activity for each source IP, in case the source is brain dead or potentially malicious (a DoS attack). In fact, the fast-switching code can silently drop the unroutable packet without even scheduling a process to run. Thanks to both of you for digging and actually trying these on real gear -- it helps everyone learn much more thoroughly. Marty Adkins Email: [EMAIL PROTECTED] Mentor Technologies Phone: 240-568-6526 133 National Business Pkwy WWW: http://www.mentortech.com Annapolis Junction, MD 20701Cisco CCIE #1289 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=3&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: ping replies [7:10910] longish! [7:11097]
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
Re: ping replies [7:10910]
Priscilla, Actually, I have seen an H. The other day we were testing connectivity to a new site in Germany. The connection leaves our network via a router that's at our site and owned by another company. It traverses this other network and then arrives at the site in Germany at a router, again owned by this other company, connected to the LAN we are interested in. We were testing connectivity and when I did a ping to a server on the LAN in Germany I got back H's as a reply. I had never seen this and looked it up it in my Exam Cram Support book that was within easy reach on my bookshelf. It had no mention of an H as a result for a ping. I mentioned to a colleague that this was interesting. Had anyone ever seen this? Nobody seemed to have any knowledge of this when getting a response from a ping. Before I could mention this response to the company who's network we were traversing they sent an e-mail stating that the connectivity had been established and we should have no issues connecting. Sure enough, the next ping was successful. I was to busy the rest of the day to pursue it further and had forgotten about it until I saw your post. Unfortunately, I will never know what caused that response as contacting the other company about this would be futile. -- James Haynes Network Architect Cendant IT A+,MCSE,CCNA,CCDA,CCNP,CCDP, CQS-SNA/IP ""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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=11058&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: ping replies [7:10910] longish! [7:11030]
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: ! 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: oooh 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
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 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? 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. > > >
RE: ping replies [7:10910]
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. also, somewhere in the 11.x range, ping was taken from the system management section to the troubleshooting section, for whatever reason. 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.** > > > > Qu
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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10999&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ping replies [7:10910]
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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10958&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: ping replies [7:10910]
i believe the most effective way to simulate routing loops is via configuration errors, the way they appear in real life (mutual redistribution between ospf & rip without any filtering seems pretty effective). I suspect that the supported parameters vary wildly by IOS version; I've seen cases where investigating problems with explicitly configured MTU sizes of an unacceptably small magnitude yielded little beyond failure or success. Unfortunately, the best data i have for those cases were sniffer traces from end-user systems and NOT router feedback. "Chuck Larrieu" @groupstudy.com on 07/03/2001 06:58:02 PM Please respond to "Chuck Larrieu" Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Kevin Cullimore) Subject: RE: ping replies [7:10910] methodology questions - see in line: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Priscilla Oppenheimer Sent: Tuesday, July 03, 2001 2:47 PM To: [EMAIL PROTECTED] Subject: ping replies [7:10910] MFragmentation was needed and the don't fragment (DF) bit was set. &A time-to-live exceeded message was received. IThe user interrupted the test. ?An unknown packet was received. CA packet was received with the congestion-experienced bit set.** Questions: 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? CL: curiousity, PO - are you setting the MTU on a segment at some low number, then using extended ping with a large packed size and setting DF? just thinking out loud how I would attempt an experiment Has anyone every seen &? I couldn't get that one to happen either. CL: how are you testing this one? best I can come up with is to deliberately create a routing loop someplace along the line. I'm just mulling over how to do so. static routes between two routers pointing to eachother as the place where the destination network resides? How about I? That doesn't happen on my routers. Plus one version of the documentation said it was |, not I. CL: never, and I interrupt all the time 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.) CL: Cisco been very very good to me :-> Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com | This message may contain confidential and/or privileged | | information. If you are not the addressee or authorized to | | receive this for the addressee, you must not use, copy, | | disclose or take any action based on this message or any| | information herein. If you have received this message in | | error, please advise the sender immediately by reply e-mail | | and delete this message. Thank you for your cooperation. | +-+ Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10940&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ping replies [7:10910]
Hey. I can verify the ! and . characters :-) LOL Mike W. "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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10925&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: ping replies [7:10910]
well, in practical terms, all that matters is whether you can get there or not. anything else is icing on the cake, so to speak. one of the bad things that has happened as a result of the DDoS attacks of the last year or so is that a lot of net admins have locked down their networks, and you don't get ping replies at all. how do you know you can get from here to there if all ICMP replied are dropped no matter what? in a way, you can look at the RFC and see what the writers and designers were thinking - more information leads to better analysis of issues. on the other hand, it is well publicized in security circles that the less information you provide, the more difficult it is for people with bad intentions to discover things about you. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Neiberger Sent: Tuesday, July 03, 2001 3:45 PM To: [EMAIL PROTECTED] Subject: Re: ping replies [7:10910] I personally have yet to encounter anything except a period, an exclamation point, a U, and I think possibly an A once. But that's it. I've tried to get some of the others to occur but it doesn't seem that Cisco has bothered to be too specific with their implementation. ;-) Apparently, in Cisco ICMP, we have the following reply values: ! = Good Response . = No Response U = We got a response and it wasn't good, but we don't feel like necessarily letting you in on what it was. John >>> "Priscilla Oppenheimer" 7/3/01 3:46:38 PM >>> 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10922&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: ping replies [7:10910]
methodology questions - see in line: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Priscilla Oppenheimer Sent: Tuesday, July 03, 2001 2:47 PM To: [EMAIL PROTECTED] Subject: ping replies [7:10910] 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. ? An unknown packet was received. C A packet was received with the congestion-experienced bit set.** Questions: 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? CL: curiousity, PO - are you setting the MTU on a segment at some low number, then using extended ping with a large packed size and setting DF? just thinking out loud how I would attempt an experiment Has anyone every seen &? I couldn't get that one to happen either. CL: how are you testing this one? best I can come up with is to deliberately create a routing loop someplace along the line. I'm just mulling over how to do so. static routes between two routers pointing to eachother as the place where the destination network resides? How about I? That doesn't happen on my routers. Plus one version of the documentation said it was |, not I. CL: never, and I interrupt all the time 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.) CL: Cisco been very very good to me :-> Thanks for your help. Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10919&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ping replies [7:10910]
I personally have yet to encounter anything except a period, an exclamation point, a U, and I think possibly an A once. But that's it. I've tried to get some of the others to occur but it doesn't seem that Cisco has bothered to be too specific with their implementation. ;-) Apparently, in Cisco ICMP, we have the following reply values: ! = Good Response . = No Response U = We got a response and it wasn't good, but we don't feel like necessarily letting you in on what it was. John >>> "Priscilla Oppenheimer" 7/3/01 3:46:38 PM >>> 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10918&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: ping replies [7:10910]
Not too much help I guess, but I can answer NO to all your questions. I have not seen any of those replies. Hth, Ole ~~~ Ole Drews Jensen Systems Network Manager CCNA, MCSE, MCP+I RWR Enterprises, Inc. [EMAIL PROTECTED] ~~~ http://www.OleDrews.com/CCNP ~~~ NEED A JOB ??? http://www.oledrews.com/job ~~~ -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 03, 2001 4:47 PM To: [EMAIL PROTECTED] Subject: ping replies [7:10910] 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=10913&t=10910 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
