LAN, subnet, router and firewall fun!

[WinstonWolf]

Unless it was a routing switch...

[ffc]

wombleh said:

If it was a switch between them rather than router/s then it wouldn't be two networks, just one at the IP level.

Sorry, I missed that. The IP addresses on the rings are unique so you are right a switch would work.

[wombleh]

WinstonWolf said:

Unless it was a routing switch...

Stick both ports in the same VLAN then, voila no routing !

[WinstonWolf]

wombleh said:

WinstonWolf said:

Unless it was a routing switch...

Stick both ports in the same VLAN then, voila no routing !

There's a few ways to solve it, as long as it's addressed properly and you've got some form of dynamic routing on all the core devices it should "just work" without any static routes.

[George111]

He did say:

"These two networks were built as physically separate networks (no idea why! and it's not something I can change so we have to deal with it as is) " so it looks like they have to stay seperate, not part of the same vlan.

So he needs two routers or router instances and NAT to hide the duplicate addressing. I'd also want to run a routing protocol, I'd not fancy creating statics for all the networks !

[WinstonWolf]

Id just change one of the rings, the problem will only get worse if the network grows

[George111]

WinstonWolf said:

Id just change one of the rings, the problem will only get worse if the network grows

I'd join the rings. I've seen similar designs before where the two rings were on a diagram to emphasise the fact that there are two separate rings for redundancy but it wasn't meant to be implemented as two separate logical rings, they were just two physical fibres run into pairs of switches for resilience but in the OPs case somebody appears to have taken it to the extreme.

[wombleh]

Could be legacy layout from an old FDDI network, not ideal but will work and give basic redundancy.

NAT would complicate the static routes and firewall rules, having it all in one layer 3 domain would be simpler, but may need some spanning-tree tweaks like set switch joining the rings as the root bridge.

Edited by wombleh on Saturday 27th August 12:56

[TonyRPH]

yorkshireegg said:

WinstonWolf said:

• If* I'm reading that correctly it will get lost at 10.0.100.92 because 10.0.100.94 is theoretically on the network the packet just came from. I still think you need to readdress your rings so they have a sane addressing structure.

I see what you're saying and I would be inclined to agree with you but why can I access some machines on a given subnet but not others?

I agreed with WinstonWolf - OP, what does the routing table look like?

I'm failing to see how device with address 10.0.3.6 on the left hand (controls) ring* is able to communicate with any device on the right hand (archive) ring* as any routing tables on 10.0.70.10 / 71.10 will simply make 10.0.100.0 part of the local network.

As for accessing some devices and not others - are you sure about this? Have you checked your ARP cache to see which MAC address(es) are associated with the IP?

I just don't see how you can have a routing table like: (using generic command) route add 10.0.100.0/25 via 10.0.71.10 and vice versa, as both 10.0.71.10 and 10.0.70.10 will have interfaces on the 10.0.100.0 networks - and hence regard the traffic as local (unless there is some fancy iptables redirection taking place) what O/S is all this based on?

Have you tried tools like traceroute to see which path the traffic is actually taking (both for the working and non working devices).

Depending on how many hosts you have - a quick and easy solution would be to split the 10.0.100.0/24 in half (giving it a /25** mask), and that would solve your routing issues, although you would of course need to change subnet masks everywhere.

This also leads me to think that the device(s) you can actually communicate with may possible have an incorrect subnet mask set.

• with reference to your posted diagram.

• a /25 would yield 126 hosts for either side (10.0.100.1/25 -> 10.0.100.126/25) and (10.0.100.128/25 -> 10.0.100.254/25)

Edited by TonyRPH on Monday 29th August 14:32

[yorkshireegg]

Apologies for not replying to this thread, things have been rather hectic.

Latest news is we have joined the two fibre rings over the weekend and it seems to be working much better. I was reluctant to do this at first as ownership of the network is a bit complicated and I'd rather not take that decision on myself! We're going to run a few tests to see how it goes with traffic levels etc. Is it actually likely to be an issue?

Regarding the previous setup with the two separate 10.0.100.0 rings for clarity... The routing tables are all static (and yes, I now have to go round today updating them all!) and held within the industrial firewall/routers that act as the gateway to each subnet. Because each gateway could only see the 100.0 ring that it sits on, the routes actually worked for some machines. Using tracert showed this. ( All masks were set at /24, all machines able to see other machines on the same subnet and the servers sat on the same ring. I can only assume an obscure hidden firewall rule was stopping some packets to some addresses due to the crazy routing necessary to make it 'work' on that setup.

Fingers crossed this new setup works... the routes are much simpler so issues will be easier to trace at least!

Thanks all for your help. Always good to see different ideas for solutions to a problem.

[droopsnoot]

WinstonWolf said:

There's a few ways to solve it, as long as it's addressed properly

Groan...