I have c2611 configured as basic router with two interfaces (1 on internal and 1 on external network). No NAT, ACL neither than Firewall configured on interfaces.
PC(ext) <-HUB-> (ext)-router-(int) <-HUB-> PC(int)
I'm able to ping/reach the PC(int) from PC(ext).
My problem is that when I send an HTTP from PC(ext) to a non existing IP address on same network than PC(int), per RFC 792 (http://www.ietf.org/rfc/rfc792.txt), I should receive on PC(ext) a ICMP message Type 3 Code 1 (host unreachable) but I receive nothing and my request stay alive indefinitively.
How can I configure my router to send back to the source host an ICMP unreachable message when the destination host is unreachable ?
A router will send an ICMP host unreachable message if it does not know the route to the destination address. But your router does have a route as the router is directly connected to the network so i don't believe you would see a host unreachable message.
What happens if you try to connect to a host on a completely different network that your router knows nothing about
Well, a Linux based router sends ICMP host unreachable in this exact same configuration. The Linux router sends ARP requests on the destination network, stops after 3 seconds and sends back an ICMP host unreachable.
With the same architecture, the Cisco sends the ARP requests, and that's all.
I thought i'd better test it in our lab just to confirm what i said was true.
It does indeed work that way. An ip address that is on a network that the router has no knowledge of will generate a host unreachable. An ip address that is on a network the router knows about but there is no actual host will not generate an ICMP host unreachable.
The problem in this case is that it takes 3 minutes for a TCP connection to timeout, instead of 3 seconds with a Linux router.
In a scenario where there is multiple HTTP servers listed with the same domain name, and one of the server is disconnected from the network, then in the worst case a browser will have to wait 3 minutes before trying the next IP address on the list. This is not a user-friendly behavior.
Is there any way to force the Cisco router to send the ICMP Host Unreachable in this case?
What you are trying to do is load balancing then by the sounds of it.
I'm not sure what version of IOS you have but IOS can do a form of load-balancing called IOS slb. I have attached a link to a Cisco doc about it. To be honest i have never used it as we use dedicated load balancers where i work nut it may be of some help.
I appreciate you are a little annoyed that the Cisco router isn't doing what you want.
But what you are trying to do is load balancing by the sounds of it. It's called poor mans load balancing because your are using DNS to send back different IP addresses for the same domain name in a round robin fashion. This is not a failing of the router but a limitation of DNS in that it cannot sense when a server has gone down. That is why you use load balancing.
I am not saying a Cisco router cannot send an ICMP host unreachable. It can and does. It will send an ICMP host unreachable for a host IP address it cannot find a route to. However where there is a route but the server does not respond you will not get a ICMP host unreachable.
I have tried to give you a solution but i appreciate you may not want to go down this route. I will have a look into ICMP on Cisco routers to see if it can do what you want but i'm not too hopeful.
This is an old, but interesting thread.
"If a packet is to be forwarded to a host on a network that is directly connected to the router (i.e., the router is the last-hop router) and the router has ascertained that there is no path to the destination host then the router MUST generate a Destination Unreachable, Code 1 (Host Unreachable) ICMP message."
"The link layer MUST NOT report a Destination Unreachable error to IP solely because there is no ARP cache entry for a destination; it SHOULD queue up to a small number of datagrams breifly while performing the ARP request/reply sequence, and reply that the destination is unreachable to one of the queued datagrams only when this proves fruitless."
In IOS, when initial packets arrive with a destination IP address for which no ARP entry exists, the packets are dropped (according to A. Zinin, "Cisco IP Routing"). This approach tries to avoid having the router wait for an ARP reply that may potentially never be received, thus stopping other packets from flowing through an interface. So, basically, this approach makes the router more resistant to DoS attacks and makes better use of buffers. In the normal case this is a tradeoff between questionable usability of such a feature and speed/efficiency of forwarding. In the attack case, it is a tradeoff between the same feature and device security.
Since the cisco router doesn't queue the initial packets (RFC says it "should", but it's not a "must", BTW: the RFC in the original post says "may", those words often make all the difference), then the router cannot send a message about the host being unreachable (router drops packets on own initiative and doesn't wait for host to respond, so has no clue about whether host is unreachable or not). The RFC in this case says that it must not do that ("The link layer MUST NOT report a Destination Unreachable error to IP solely because there is no ARP cache entry for a destination").
To sum up:
1) The feature requested in this thread is not mandatory
2) The feature is directly associated to how ARP is implemented
3) ARP is implemented in a specific way for good reasons
4) Since ARP is implemented like that, router must not send the unreachable message
I personally do not expect this behavior to change.
Thank you for your reply.
This would be useful int the case of DNS Round Robin. Just like nicolas06 wrote before:
"The problem in this case is that it takes 3 minutes for a TCP connection to timeout, instead of 3 seconds with a Linux router.
In a scenario where there is multiple HTTP servers listed with the same domain name, and one of the server is disconnected from the network, then in the worst case a browser will have to wait 3 minutes before trying the next IP address on the list. "
But it is good to know, that this is not possible with Cisco Routers, so we don't have to investigate more time in this Problem.