Yeah...
Looks like this. Thanks, Alexei.
Totally forgot that the router in question has two interfaces to reach.
Disabled one of them and started seeing ICMP host unreachables sent. But ...
How about the difference in ICMP unreachable and ICMP host unreachable in terms 
of conditions?
If the task asks to disable the former would it be just enough to disable ICMP 
unreachable or ICMP host unreachable is a candidate as well?

For example,
I have the following ACL on the target router (R5) and the respective class-map 
and policy-map to apply to he control-plane host subinterface:

ip access-list extended ICMP-UNREACH-ACL
deny   icmp any host 150.1.2.2 host-unreachable
deny   icmp any host 150.1.2.2 unreachable
permit icmp any any unreachable

Then I'm pinging the nonexistent host by sending ICMP via R5 from R2 sourcing 
it from different interfaces and expecting NOT to see unreachables if sent from 
loopback0 (150.1.2.2):

R2(config)#do ping 100.100.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2(config)#do ping 100.100.100.1 so loop0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.1, timeout is 2 seconds:
Packet sent with a source address of 150.1.2.2
.....
Success rate is 0 percent (0/5)

In both cases I still see that R5 sends ICMP host unreachable:

R5(config)#
ICMP: dst (100.100.100.1) host unreachable sent to 141.1.25.2
ICMP: dst (100.100.100.1) host unreachable sent to 141.1.25.2
ICMP: dst (100.100.100.1) host unreachable sent to 141.1.25.2
ICMP: dst (100.100.100.1) host unreachable sent to 141.1.25.2
ICMP: dst (100.100.100.1) host unreachable sent to 141.1.25.2

ICMP: dst (100.100.100.1) host unreachable sent to 150.1.2.2
ICMP: dst (100.100.100.1) host unreachable sent to 150.1.2.2
ICMP: dst (100.100.100.1) host unreachable sent to 150.1.2.2
ICMP: dst (100.100.100.1) host unreachable sent to 150.1.2.2
ICMP: dst (100.100.100.1) host unreachable sent to 150.1.2.2

Eugene

From: Alexei Monastyrnyi [mailto:[email protected]]
Sent: Thursday, July 19, 2012 1:44 AM
To: Eugene Pefti
Cc: [email protected]
Subject: Re: [OSL | CCIE_Security] ICMP unreachables vs ICMP time exceeded

time-exceeded is TTL becoming 0.. are you sure you don't have a loop in your 
topology?
On 19 July 2012 17:41, Eugene Pefti 
<[email protected]<mailto:[email protected]>> wrote:
Guys,
I was expecting the router will send ICMP host unreachable if the packet is 
sent to it to the destination the router doesn't have any route.
Instead I see that it sends ICMP time exceeded:

ICMP: time exceeded (time to live) sent to 141.1.25.2 (dest was 100.100.100.1)

And hence the  task to stop sending ICMP unreachables doesn't work. Is there 
something I can verify?
Or rather I should have formulated the question about the conditions when the 
ICMP unreachable or host unreachable are sent.

ICMP unreachables are allowed on the interface in question:

R5#sh ip int Ser0/0/1
Serial0/0/1 is up, line protocol is up
  Internet address is 141.1.25.5/24<http://141.1.25.5/24>
  Broadcast address is 255.255.255.255
  Address determined by non-volatile memory
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is enabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is enabled
  ICMP redirects are always sent
  ICMP unreachables are always sent
  ICMP mask replies are never sent

Eugene

_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com<http://www.ipexpert.com/>

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com<http://www.platinumplacement.com/>

_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

Reply via email to