Vrstvy ISO/OSI a teorie síťování

Další nepříjemností pro uživatele sítě, které postihne příliš horlivý admin zakazující ICMP je, že se nedozví o chybách, které nastávají, když se pokouší navázat spojení, resp. obecně komunikovat s různými protistranami. Pokud například klient pokusí navázat TCP spojení na IP adresu, která je v subnetu, na který nevede žádná cesta ve směrovací tabulce, tak první router, který zjistí, že neví, co má s prvním datagramem daného spojení (červená šipka ve schématu níže) dělat, daný datagram zahodí a pošle o tom odesílateli ICMP zprávu (Destination Unreachable - no route to destination) - ta je reprezentována zelenou šipkou.

Pokud ICMP zpráva dorazí odesílateli zahozeného datagramu, je hned jasné, že snaha o spojení je marná, a že jí nemá smysl ani opakovat, ani čekat na odpověď od serveru, na který se připojujeme. Jinými slovy, pokus o spojení z aplikace může být rovnou ukončen a chybové hlášení, které aplikace a snad i uživatel dostane, říká, jaký byl důvod, že spojení selhalo.

Když naopak ICMP zpráva nepřijde, protože je ICMP zahazováno firewallem našeho horlivého admina, tak klient se opakovaně pokouší spojení navázat a čeká na dlouhý timeout (v Linuxu to je v defaultním nastavení TCP stacku 6 pokusů a dohromady přes 2 minuty času). A nakonec aplikace dostane zcela nevypovídající hlášení: Timeout exceeded. O důvodu pak může uživatel jen spekulovat.

Obdobná situace nastává, pokud se klient pokouší komunikovat s adresou, která je sice součástí existující sítě, ale žádný počítač neodpoví routeru, který má do daného subnetu connected route na ARP / NDP (to pak vede na Destination Unreachable - destination host unreachable). Nebo pokud se aplikace pokouší komunikovat protokolem UDP na port, který je zavřený (nikdo na něm neposlouchá). (V případě TCP server reaguje na pokus o navázání TCP spojení na zavřený port segmentem s flagem RST=1.)