2 routers

[Crimliar]

It's still not clear what you are hoping to achieve through this segmentation!

With the primary router set

IP: 192.168.1.254/16 (255.255.0.0) and DHCP allocating say 192.168.1.16- 192.168.1.239 Gateway: 192.168.1.254

you could then set the secondary router (LAN to LAN connection) as:

IP: 192.168.2.254/15 (255.255.0.0) and DHCP allocating say 192.168.2.16-192.168.2.239 Gateway 192.168.1.254

Provided the routers are setup correctly they should be able to handle routing up to 255 local clients (it's built into the network controller chips).

*This should work, but it's a quirky way of doing things, and if it doesn't work it'll most likely be the case of whoever coded the router did not anticipate what you are trying to do.

[countrypaul]

If you use 255.255.0.0 as the masks you will have trouble communicating between those on the first network with those on the second network. Anything in the 192.168.1.x network will think anything on the 192.168.2.x network is on their network and not use the router - similarly the for those on the 192.168.2.x network will not use the router to get to the 192.168.1.x network.  The second DHCP server should not give out the 192.168.1.254 address as the gateway since that is in the first network and it won't find it as it does not know where the second router is. The second DHCP server should give the address of the second router (on the second network) as the gateway.  That won't solve the problem of trying to communicate with nodes directly on the first network from the second network but would allow nodes on the second network to access the Internet. Packets from the internet might not make it to the second network as the first router (if using a 255.255.0.0 mask) would look for their destination on the local network rather than forwarding to the second router. 

[Crimliar]

You are connecting LAN port to LAN port, so you don't actually have two LANs.  All you are doing is segmenting what is allocated via the DHCP server(s).  Whether it works or not depends on how the code for the routers is written, but that second router is acting as little more than a switch.  It ain't clever, but without knowing what the OP is trying to do, coming up with a clever solution is near impossible!

[Bikeboardsurf]

Thanks for the posts.

I have a small lab running a Kubernetes cluster, when a service needs to be exposed (e.g a bespoke API, a web page, a web based application etc.)  outside of the Kubernetes cluster, an IP address is created within a pre-agreed range (this range can be anything I configure it to be), MetalLB is used for this in conjunction with the router. But the range cannot clash with existing Ip addresses.  Every time a new service needs to be exposed, a unique IP address needs to be assigned , clearly a lot of IP addresses will be generated so this limits the range i can configure, especially as I use the lab for research and development. So the original idea is to have a router handle those IP addresses while keeping the rest of the house household issued IP ddresses that are not relevant to the lab separate and not to mess about too much with the HH during what I'm doing on the lab cluster. The IP range for Router B can be any arbitrary value, it does not need to be 10.0.2.x.   So to summarise I'm looking for the HH to be relatively stable by keeping it separate from the lab and I'd like the other router to do the hard work and ideally using an IP range that easily signifies that it is lab related. 

[countrypaul]

If you have 2 DHCP servers on the same Lan then it becomes a bit of a lottery as to which one will actually serve  any request.  I assumed the second router was there for that purpose of making sure there are 2 subnets so that DHCP requests are served by the relevant DHCP server. 

The original request was that clients in the first subnet (from SH 192.168.1.x) could not see the addresses in the second subnet (router 2 10.0.2.x) - which could be achieved by using a router as a router and not just a switch. I presume this would require the WAN port on router2 to be connected to a Lan port on the SH2.

[Crimliar]

At the point where a DHCP request is made, physical clients should receive a DHCP allocation from the device they are connecting to, and provided the LAN SSIDs are different the same should be true for WiFi clients.  As said, it's messy, and does depend on the underlying software to work properly.

There is nothing in the original post that requests that clients in range one cannot see clients in range two!

[countrypaul]

Ah, I read that first post in a different way, when op wrote:

DEVICE 1 (192.168.1.10)  cannot reach DEVICE 2(10.0.2.5) . 

I took that as a requirement, in that he did wanted devices in the 192.168.1.x subnet to not have access to the 10.0.2.x subnet.  Re - reading that post, I can see it as either a requirement or a problem with his setup. 

[Crimliar]

I've been toying this around my head all day, and it's still beyond messy.  The first time you get a DHCP broadcast it'd probably all fall down even if everything else was in place.  It'd be much easier if you abandon the BT router altogether, preferably (and I hate to say this) use a pFsense or oPensense router using a large IP range (MetaILB doesn't need a full subnet to itself).  You might still need to recompile the DHCP daemon, and use a short TTL (Time To Live) for the IP tables.

Beyond that, getting advice from the MetaILB or Kubernetes communities is probably best!