cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5422
Views
10
Helpful
6
Replies

Extended ACL & Destination Unreachable Message

169.254.X.Y
Level 1
Level 1

PC1 -- SW1 -- R1 -- R2 -- SW2 -- PC2

From above topology, I adjusted access-list 101 deny icmp host PC1's IP host PC2's IP + access-list 101 permit ip any any inbound in R2's serial interface. I was expecting that if PC1 pings PC2, time-exceeded would show up 4 times since the echo request from PC1 at least reached R2. I was taught that, R2 would drop the echo request if PC1 pings PC2. BUT, I got the destination unreachable 4 times. As far as I know, the destination unreachable message shows up if the router cannot find the path from the routing table, so I thoguht this is some kind of bug from the packet tracer. My net instructor told me that time-exceeded message would definitely show up in real life. Just to make sure, I tested again on the packet tracer 7.1, but the result was same: destination unreachable message * 4. If you know exactly which message would show up in real life, please let me know and please explain to me why.

2 Accepted Solutions

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

First of all, do not take Packet Tracer's behavior as representative of real world's behavior. Packet Tracer is a wonderful teaching tool as long as the Cisco command line goes, but you have to keep in mind that it does not implement real full IP stack - it just mimicks it, and its behavior may differ from real IP driver implementations. Whenever you have an option of running real IOSes, go for it.

That being said, the ICMP Destination Unreachable message in your case is correct. When a packet is dropped due to an ACL, the router dropping the packet will generate ICMP Destination Unreachable message type, usually with the Communication Administratively Prohibited code.

The ICMP Time Exceeded message is sent only in two cases: Either the packet's TTL had to be decreased to 0 while routing it, and so the packet had to be dropped, or the packet was fragmented and delivered to the end host but one or more fragments did not arrive within a reasonable time, and the host gave up waiting for the missing fragment(s). Obviously, none of these events really occurred in your network.

If you want to see an ICMP Time Exceeded message, remove all ACLs, and run a traceroute from PC1 to PC2. Traceroute works by sending out packets with consecutively growing TTLs, starting with 1 and growing, and it detects the routers on the path to the destination exactly by having the packets expire on the first hop, then on the second, the third etc., and thereby forcing the hops to reveal themselves by sending an ICMP Time Exceeded message back.

Best regards,
Peter

View solution in original post

Hello,

I guess that you could work around the file type limitation by simply adding a new extension to the file name, say, "txt", or store it into a TAR archive.

In any case, I've checked the snapshots. I do not believe that PC1 receives any ICMP message back whatsoever. If you see PC1 reporting some kind of "Request timed out" when pinging 192.168.1.2, this is because it did not receive any response back in expected time. However, this message is not printed out due to some ICMP signalling. Router0 did not send any packet back to PC1 because it had no reason to do so, and Router1 could not respond back because it does not have a route back to 1.1.1.0/24, and so it dropped its own response rather than sending it. Once again, the "Request timed out" (or whatever PC1 prints out) is a message generated by the "ping.exe" binary that sends the pings but never gets the response back, and so it reports a timeout. There is no ICMP Time Exceeded involved here at all.

Since Router 2 cannot find the path to 1.1.1.1 from its routing table, router 2 would drop the echo request received from PC0.

Not entirely correct. Router2 would receive and process the ECHO Request from PC1 happily because Router2 is its intended destination. Router2 would even construct an ECHO Reply, but at the moment it tried to send it out, it would find out that it does not know how to reach 1.1.1.1. At that moment, Router2 would drop the packet - but it would drop its own Reply, not PC1's Request.

As usual, feel welcome to ask further!

Best regards,
Peter

View solution in original post

6 Replies 6

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

First of all, do not take Packet Tracer's behavior as representative of real world's behavior. Packet Tracer is a wonderful teaching tool as long as the Cisco command line goes, but you have to keep in mind that it does not implement real full IP stack - it just mimicks it, and its behavior may differ from real IP driver implementations. Whenever you have an option of running real IOSes, go for it.

That being said, the ICMP Destination Unreachable message in your case is correct. When a packet is dropped due to an ACL, the router dropping the packet will generate ICMP Destination Unreachable message type, usually with the Communication Administratively Prohibited code.

The ICMP Time Exceeded message is sent only in two cases: Either the packet's TTL had to be decreased to 0 while routing it, and so the packet had to be dropped, or the packet was fragmented and delivered to the end host but one or more fragments did not arrive within a reasonable time, and the host gave up waiting for the missing fragment(s). Obviously, none of these events really occurred in your network.

If you want to see an ICMP Time Exceeded message, remove all ACLs, and run a traceroute from PC1 to PC2. Traceroute works by sending out packets with consecutively growing TTLs, starting with 1 and growing, and it detects the routers on the path to the destination exactly by having the packets expire on the first hop, then on the second, the third etc., and thereby forcing the hops to reveal themselves by sending an ICMP Time Exceeded message back.

Best regards,
Peter

Always thank you very much!!! But, I am still confusing :( Could you tell me why time exceeded message shows up when PC0 pings 192.168.1.2 in this topology and which case applies in this case? http://imgur.com/a/9o156
I knew that time exceeded message would show up but my reason doesn't match two cases you gave me. Since Router 2 cannot find the path to 1.1.1.1 from its routing table, router 2 would drop the echo request received from PC0. However, since router 3 forwarded the echo request and PC0 thinks he definitely sent the echo message, but didn't receive the reply, time-exceeded message definitely would show up. This is my reason...

Hi,

Can you please post the PKT file with the topology? There are too many variables without knowing the exact configuration of all devices.

Best regards,
Peter

I tried to post the ptk file, but the following message keeps showing up, "The file time_exceeded.pkt does not have a valid extension for an attachment and has been removed. jpg,gif,png,xlsx,tar,rtf,csv,ppt,pptx,mov,mp4,qt,wmv,doc,docx,pdf,jpeg,txt,xls are the valid extensions."

I added pictures of configurations of devices. Here is the new link: http://imgur.com/a/fwIHX 

P.S. If you know how to post the ptk file, please let me know. It would be really helpful for me when asking a question if I know how to post the ptk file :) 

 

 

 

Hello,

I guess that you could work around the file type limitation by simply adding a new extension to the file name, say, "txt", or store it into a TAR archive.

In any case, I've checked the snapshots. I do not believe that PC1 receives any ICMP message back whatsoever. If you see PC1 reporting some kind of "Request timed out" when pinging 192.168.1.2, this is because it did not receive any response back in expected time. However, this message is not printed out due to some ICMP signalling. Router0 did not send any packet back to PC1 because it had no reason to do so, and Router1 could not respond back because it does not have a route back to 1.1.1.0/24, and so it dropped its own response rather than sending it. Once again, the "Request timed out" (or whatever PC1 prints out) is a message generated by the "ping.exe" binary that sends the pings but never gets the response back, and so it reports a timeout. There is no ICMP Time Exceeded involved here at all.

Since Router 2 cannot find the path to 1.1.1.1 from its routing table, router 2 would drop the echo request received from PC0.

Not entirely correct. Router2 would receive and process the ECHO Request from PC1 happily because Router2 is its intended destination. Router2 would even construct an ECHO Reply, but at the moment it tried to send it out, it would find out that it does not know how to reach 1.1.1.1. At that moment, Router2 would drop the packet - but it would drop its own Reply, not PC1's Request.

As usual, feel welcome to ask further!

Best regards,
Peter

WOW!!!! Thank you very much. Again, I learned things I cannot learn from the textbook. But, it is pretty sad that Router2 drops the ICMP Reply which Router2 constructed for PC1. I guess it is generally better to construct the Reply packet first and then check the routing table.
But, in this case, it would have been better if Router2 checks the routing table first. In that case, Router2 doesn't have to constrcut the Reply packet and furthermore doesn't have to drop its own Reply :)
On the other hands, I also think it could be a bad idea if the destination is reachable. In that case, Router 2 needs to look up the routing table twice.

If my assumptions are not 100% correct, please let me know. I am always waiting to get enlightened :)

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: