Ingo , Martin, All, i can confirm when the issue occured the command
arp -s gateway-ip-address gateway-mac-address worked to restore connectivity Cheers, Tom Smyth On 1 May 2018 at 21:16, Tom Smyth <tom.sm...@wirelessconnect.eu> wrote: > Hello Ingo, Martin,All, > > I think you hit the nail on the head, (I was too busy looking at the > routing table (and forgot the fundamental principle of longest prefix > match) > > so if I have a static arp entry before adding in the > (more specific than the connected route) i should be OK > > just to explain (the method in my madness ) > (what i agree in hindsight is a fragile setup) > basically I have a /22 network the clients are isolated from each > other on Layer 2 (so the clients cant see each others > arp requests / replys) (Bridge horizon / protected ports / privatevlan) > to limit bandwith wasting stuff such as broadcasts and other > security issues such as rogue DHCP servers etc. > > The clients can only see the gateway > and the gateway can see all the clients .. I have heard of people > using some proxy arp solutions on the gateway and perhaps > that is what I should be doing rather than the ( more specific > than connected static routes) > > Does anyone who operate Access layer in ISPS have suggestions > I appreciate the help and the reminder of the longest prefix match > rule :) > > Thanks again > > On 1 May 2018 at 21:03, Martin Pieuchot <m...@openbsd.org> wrote: >> On 01/05/18(Tue) 21:28, Ingo Schwarze wrote: >>> [...] >>> So what you are doing seems fragile to me. It may sometimes work >>> due to order of configuration, timeouts, whatever, i'm not sure. >> >> It can work if the ARP entry, what Ingo called the /32 is created >> before you add your /23. >> >>> But once part of it gets broken for whatever reason, i don't see >>> how it could possibly automatically recover via the normal RTF_CLONING >>> mechanism. >> >> It can't because as you described the /23 will be a better match. And the >> reason will be the expiration of the ARP cache.
