|
|
|
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.
|
|
|
Can you ping your colleague's IP address and get a reply?
Michael Chare
|
|
|
|
If you are on the same network, then there is no routing required. Routing is by definition between different subnets.
That's not to say that Zzoomm have not got something in place to blackhole traffic between customers. Can you get this site's BQM to work for both connections? That will prove that ICMP [I think] is getting through from totally outside, pinging between routers will then show that you are working across the subnet.
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
|
This is a side effect of a DHCP connection over PPPoE - there's no broadcast traffic permitted over the /22 so each client can only speak to the gateway.
One of the customers will have to request a change of subnet, which may not even be possible depending on how Zzoomm structure their network.
|
|
|
|
You can bodge your way around this by tunnelling IPv4 over IPv6
|
|
|
This is a side effect of a DHCP connection over PPPoE - there's no broadcast traffic permitted over the /22 so each client can only speak to the gateway.
Interesting. This looks like a breach of the implied Internet Services contract for IPv4, to provide connectivity to all public IPv4 addresses
One of the customers will have to request a change of subnet, which may not even be possible depending on how Zzoomm structure their network.
Looks like a solution, which would work and require zzoomm to do whatever is required given the implied IPv4 contact
|
|
|
|
On each router, try adding a static route to the other party's IP address via the gateway
e.g. say:
you are 84.18.228.42 with gateway 84.18.228.1
they are 84.18.228.123 with gateway 84.18.228.1
On your router, add a route to 84.18.228.123/32 via 84.18.228.1
On their router, add a route to 84.18.228.42/32 via 84.18.228.1
|
|
|
One of the customers will have to request a change of subnet, which may not even be possible depending on how Zzoomm structure their network.
Tailscale/Tailnet? That would work, depending on what latency they require, and keep the pesky ISP out of the conversation 
The user formally known as Sponge34
|
|
|
If you can't do that, it may be possible to give the router the usual fixed IP address with the suffix /32 or mask 255.255.255.255, and not accept that information from DHCP.
Roger Hayter
|
|
|
|
What implied contract, please?
|
|
|
What implied contract, please?
Like I said, the implied Internet Services contract for IPv4, to provide connectivity to all public IPv4 addresses.
You ain't going to get a link from me, because it is an implied contract term and is not explicit. Think of it like this:- suppose the ISP gave you an IP address and a working link with TCP/IP, but it didn't route anywhere. Would you think that they were fulfilling the contract?
|
|
|
Like I said, the implied Internet Services contract for IPv4, to provide connectivity to all public IPv4 addresses.
Is the implied contract IPv4-only, or does it apply to IPv6 addresses too?
|
|
|
Is the implied contract IPv4-only, or does it apply to IPv6 addresses too?
I will leave that as an exercise for you. Do google and read up the law on implied contracts.
|
|
|
Is the implied contract IPv4-only, or does it apply to IPv6 addresses too? I will leave that as an exercise for you. Do google and read up the law on implied contracts.
Fair, genuine question from behuk, shame a poor "look it up yourself" was the response, could have understood if some others including me had asked it.
|
|
|
On each router, try adding a static route to the other party's IP address via the gateway
e.g. say:
you are 84.18.228.42 with gateway 84.18.228.1
they are 84.18.228.123 with gateway 84.18.228.1
On your router, add a route to 84.18.228.123/32 via 84.18.228.1
On their router, add a route to 84.18.228.42/32 via 84.18.228.1
That won't work. What may work is a static ARP entry for the address pointing to the gateway. If that's done on both sides the gateway BNG will hopefully just forward the data along and the static ARP will overrule whatever the source address is if the BNG doesn't rewrite it.
Obviously whether the routers they are using allow them to add static ARP entries is a different matter entirely!
|
|
|
Fair, genuine question from behuk, shame a poor "look it up yourself" was the response, could have understood if some others including me had asked it.
Implied terms is a fairly straightforward concept to understand, but difficult to actually pin down in a formal definition. As the question was actually asked, I think it is better for people to read up on the topic themselves and come to their own view. FWIW, I think that the implied Internet Services contract for IPv6, would be to provide connectivity to all public IPv6 addresses where the contract includes IPv6 and not where it doesn't. But if I had said that, I could have been criticised for being patronising or something. And, genuine or not, the question did look like a trap for exactly that.
|
|
|
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.
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 question did look like a trap Not good when you start believing every question could be a trap.
|
|
|
|
I suspected one question. Just one. I didn't believe, I suspected. Now make of that what you probably will.
|
|
|
I suspected one question. Just one. I didn't believe, I suspected. Now make of that what you probably will. 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.
|
|
|
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.
|
|
|
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 😎
|
|
|
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.
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.
Roger Hayter
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
Roger Hayter
|
|
|
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.
I have no idea why I wrote this. It's nonsense and I need to not post while, yeah never mind. You get the idea given the time of day. *Sigh* LPM wins, admin distance is later in the tree and I'm going to go hide somewhere.to rethink my life choices. The reason it may not work like that here is the behaviour of the switch chip in the router being used for hardware forwarding and how it's been programmed. I need to go relearn the basics it seems and perhaps see a doctor. This is incredibly fundamental stuff. Sorry OP/candlerb.
Edited by XGS_Is_On (Sun 19-Jul-26 17:09:58)
|
|
|
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.
Sorry, but I have to disagree.
Routes from the various RIBs (e.g. static routes, connected routes, OSPF routes, BGP routes) are fed into the global RIB. If two *identical* routes (same prefix and prefix length) come from two different RIBs, then the admin distance is used to decide between them.
But two different routes (different prefix and/or length) will both find their way into the global RIB, which in turn is used to build the forwarding information base (FIB). And once in the FIB, it's longest-prefix match wins - always. In any case, the admin distances are lost by the time the routes get into the global RIB.
It's easy enough to demonstrate. For a living, I build classes for this sort of stuff using IOU, but you can check using Linux if you prefer. Here you go:
| Text | 1
23
45
67
89
10 | root@nuc3:~# ip -4 a l dev incusbr0
12: incusbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 inet 10.12.13.1/24 brd 10.12.13.255 scope global incusbr0
valid_lft forever preferred_lft foreverroot@nuc3:~# ip route add 10.12.13.14/32 via 10.12.13.2
root@nuc3:~# ping 10.12.13.14PING 10.12.13.14 (10.12.13.14) 56(84) bytes of data.
^C--- 10.12.13.14 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1036ms |
Meanwhile, in another window, I'm running tcpdump -i incusbr0 -nn:
| Text | 1
23
45
6 | root@nuc3:~# tcpdump -i incusbr0 -nn
tcpdump: verbose output suppressed, use -v[v]... for full protocol decodelistening on incusbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:32:54.633806 ARP, Request who-has 10.12.13.2 tell 10.12.13.1, length 2818:32:55.669476 ARP, Request who-has 10.12.13.2 tell 10.12.13.1, length 28
18:32:56.693535 ARP, Request who-has 10.12.13.2 tell 10.12.13.1, length 28 |
You can see that it has followed the static route, and is ARPing for the next-hop of the static route (10.12.13.2), not for the address in the connected subnet (10.12.13.14)
|
Pages in this thread: 
Print Thread
