Aha, sakra, přiznám se, že jsem vůbec neřešil text a díval jsem se jen na obrázek. Bez textu by to smysl nemělo, takto s textem ano.
I kdyby ta síová maska byla ok, tak prostě router defaultně neforwarduje ARP. Ten příklad je tam přísně účelově a celý text tomu odpovídá. Není to žáden překlep ;-)
Kdyby byla síová maska na hostech "A" a "B" "korektne" (ve smyslu prvotního předpokladu že jde o prostý routing), tedy maska by byla /25, pak by to fungovalo i bez ARP proxy. Byly by to prostě jen dva subnety, jeden 192.168.0.0/25, druhý 192.168.0.128/25, ergo by "A" a "B" byli v prvním s bránou 192.168.0.1 a "C" v druhém s bránou 192.168.0.129 a vesele by komunikovali prostřednictvím routeru.
V daném příkladu ovšem šlo o to demonstrovat funkci ARP proxy.
Můj dotaz byl celou dobu o tom, co se však v případě takového setupu stane s TCP broadcasty, které jsou na poslední IP adrese v rozsahu?
Nic, budou fungovat. Hosti "A" a "B" s maskou /24 mají jako bcast adresu 192.168.0.255. Host "C" má sice masku /25, nicméně je už za hranicí "druhého subnetu", který je:
net: 192.168.0.128
range: 192.168.0.129 - 192.168.0.254
bcast: 192.168.0.255
Jak vidíš, mají všichni stejnou bcast adresu, liší se pouze jejich vidění sítě.
No ale nic, stejně nevidím moc praktické využití
Striktně pro tento případ asi jen zřídka, jinak se najde a je to zmíněné i v tom textu:
This behaviour can be usefull, for example, if you want to assign dial-in (ppp, pppoe, pptp) clients IP addresses from the same address space as used on the connected LAN.
Já to třeba používám pro pptp klienty a přiznám se, že když jsem s MT začínal, dost mne to potrápilo, než jsem došel k tomu, že je třeba arp-proxy zapnout. Byl jsem zvyklý, že to "krabička udělala sama".
Ostatně i na tomto fóru je dost dootazů jak zprovoznit pptp tunel tak, aby viděl i "za router", kde lidé nepoužijí arp proxy a přes tunel se dostanou jen na MT. Někteří to pak řeší maškarádou, která je zde ale úplně zbytečná.