Originalna topologija:
Code:
[A]-----[hub]-----[B]
|
|
[R]
|
{internet}
je ekvivalentna ovoj:
Code:
---+----+----+---
| | |
[A] [B] [R]---{internet}
Šta se dešava kad A pinguje B?
A šalje ARP na MAC adresu FF:FF:FF:FF:FF:FF (broadcast - primaju svi na broadcast domenu) sa "pitanjem": Koja je MAC adresa računara 192.168.1.2? B odgovara na unicast MAC adresu računara A.
Šta se dešava kad A pinguje R? A proverava u svojoj tabeli ruta (routing table) kako da dođe do adrese 192.168.1.254. Ne nalazi, dakle, treba da pošalje na default gateway. Nema rutu ni ka njemu. Aplikacija (ping) dobija informaciju da je destinacija nedostupna (destination unreachable).
Šta se dešava kad B pinguje A? Isto kad i A pinguje B, samo obrnuto.
Najzanimljiviji deo, šta se dešava kad R pinguje A? Pošto A spada u isti subnet kao i R (sudeći po R), R šalje ARP na FF:FF:FF:FF:FF:FF sa pitanjem: KOja je MAC adresa računara 192.168.1.1? Posto su na istom "kablu", ovo pitanje će doći na A. Procesiranje ARP-a se dešava na drugom nivou, dakle, nema nikakvih netmaski, A će uredno odgovoriti na pitanje i pritom staviti MAC adresu R-a u svoju ARP keš tabelu. R šalje prvi ICMP echo-request, koji dolazi do A. A će odgovoriti na njega, pošto po ARP tabeli zna kako da dođe do R (ako u ARP tabeli postoji odgovarajući podatak, ne konsultuju se ostale tabele).
Recimo da se ping iznad zaustavio. A opet hoće da pinguje R. Ovde sad počinje zanimljiv deo. U zavisnosti od operativnog sistema (zapravo TCP/IP steka na istom), ping će da prođe dokle god ne istekne ARP iz keša (uglavnom 10 minuta). Drugi operativni sistemi će pak prvo konsultovati routing tabele kao u prethodnom slučaju kad A pinguje R. Oba načina ponašanja su, generalno, ispravna.
Dakle, imamo situaciju da ping na istoj mreži radi samo u jednom smeru.
Ovo je samo jedan od scenarija. Ima i zanimljivijih, a sve ima veze sa pogrešnom netmaskom :-).
Marko.