In reply to a post by PCJM40:

Surely to god part of anyone's calculation is the type of person asking the question, I have to say behuk has got to be at the other end of the scale when suspecting a loaded question. This shows very poor judgement, hopefully it will be a lesson to you.

Go and join the police and catch real criminals.

In reply to a post by DFScale:

Go and join the police and catch real criminals.

Clearly no remorse from your side, typical sign of a hardened criminal trampling over other people to get what they want 😎

In reply to a post by candlerb:

In reply to a post by XGS_Is_On:

That won't work.

It *should* work. A standards-compliant router does longest-prefix match: if it has a static route to 84.18.228.42/32 and a connected route to 84.18.228.0/22, the former will be followed when the destination address of a datagram is .42

It will then see the next-hop of .1, which it can resolve via the connected route.

In reply to a post by XGS_Is_On:

What may work is a static ARP entry for the address pointing to the gateway.

That should work as well. Although really the BNG should be doing proxy-ARP in this scenario, to enable the client-to-client communication on the same subnet.

The root cause of the issue is the router ARPing for the other customer as they're in the same subnet as its WAN interface. Routing is irrelevant here, they think they're on the same layer 2 segment but actually aren't despite being in the same IP subnet as no path for ARP.

Edited by XGS_Is_On (Mon 13-Jul-26 15:59:20)

Not disagreeing with you, except that a /32 static route is another option to fix the problem. The more specific /32 will win.

I don't think a static /32 route will get past the WAN interface of the router, for the reason the previous poster said. Unless it is routed via the ISP gateway IP, which may not be constant, and you might need a script to find it out and set the route every time the DHCP lease is renewed. You need to set a static /32 rather than /24 on the WAN interface of the router, but DHCP will still be needed to set other parameters. It depends on the router, but minimal research suggests you can put a "supersede" statement in dhclient.conf. No idea if this will work.

In reply to a post by ianfretwell:

Myself and a colleague both have static IP addresses from Zzoomm.

Both connections are DHCP based and get a subnet mask of 255.255.252.0 - placing us on the same network...

As a result there's no way to route traffic between the two addresses, meaning VPN's, etc are a no-go.

But to confirm that Zzoomm haven't made an error with our connections could anybody else with a Zzoomm static address confirm they are also in the address range 84.18.228.1 - 84.18.231.254 please ? (we're both South Yorkshire based in case region plays a part in this).

(Zzoomm themselves have blamed our respective configs rather than accepting there might be a problem).

Cheers.

What routers are you and your colleague both using?

It's fairly trivial to road test some of the scenarios discussed here, as long as your routers are configurable to do so.

In reply to a post by candlerb:

Not disagreeing with you, except that a /32 static route is another option to fix the problem. The more specific /32 will win.

Directly connected will win. Prefix length irrelevant. Router will ARP, fail, inform unreachable exactly as it should. Routers have no routing option other than the default, it's broken because they aren't getting that far. The /32 does nothing given it's going to the same gateway as the default.

In reply to a post by rogerh:

I don't think a static /32 route will get past the WAN interface of the router, for the reason the previous poster said. Unless it is routed via the ISP gateway IP, which may not be constant, and you might need a script to find it out and set the route every time the DHCP lease is renewed. You need to set a static /32 rather than /24 on the WAN interface of the router, but DHCP will still be needed to set other parameters. It depends on the router, but minimal research suggests you can put a "supersede" statement in dhclient.conf. No idea if this will work.

Yep. As long as the routers follow the behaviour a lot of other kit does give them a /32 they'll route everything via gateway. Common solution to force clients via default gateway for inspection especially for IoT kit. Linux and Windows are both okay with this, just a faff to automate when DHCP is actually issuing a /24. Static ARP should achieve the desired result.

In reply to a post by candlerb:

It *should* work. A standards-compliant router does longest-prefix match: if it has a static route to 84.18.228.42/32 and a connected route to 84.18.228.0/22, the former will be followed when the destination address of a datagram is .42

It will then see the next-hop of .1, which it can resolve via the connected route.

I just realised what you're saying. Networks don't work like this, sorry. Directly connected routes are not treated in the same manner as unconnected ones. On basic kit metrics or whatever they call it are a thing with directly connected always taking precedence, on more complex equipment admin distances. These end up in the RIB as route preference. Prefix length is further down the decision tree to differentiate routes with the same route preference. I'm not aware of any equipment or OS that assigns the same preference to directly connected as static. Cisco, Juniper, Fortinet, PAN, Aruba, Checkpoint, Linux, BSD, Windows all prefer connected over static, prefix length comparison never done as doesn't matter.

Parenthetically, it is sad that no one seems to think that telling the ISP to configure their DHCP server properly is a viable solution! In theory, it is the simplest solution.