Return to Answer

etc.

TO DO What I haven't done is actually test this. To do that I need to get at least one quad Gb NIC and write the IPtable commands to setup the rules. I have read enough about IPtables to know the above steps will work. I need to figure out the precise commands needed to make it happen.

It will take me at least a couple of months to get the hardware and test a prototype. Until then, this answer will remain incomplete. There should be enough information here to allow someone else to solve their problem with IPtables.

IPtables is very flexible, so if your problem is not the same as mine, it should be easy to adapt to get the solution you are looking for.

I will update this answer after I have tested the prototype.

THE APPLIED SOLUTION After going through a series of iterations, starting with a Cisco based approach, I ended up with the solution outlined below.

Rather than use IPTables, I used nft, its modern replacement, running on a single Linux box. The rules here don't allow scripts to be posted so I will describe what was done. There are several parts to the solution shown in the diagram.

PART A I set up a filter so that only traffic within the IP range of the connected devices was allowed in.

PART B nft is setup to direct specific IP addresses to specific ports. They act like VLANS but they are not, because all the IP addresses are in the same domain. The packets are DNATed to route them correctly. An packet from the network is sent to the correct port and the destination IP is changed to match the host.

PART C Part C needs to differentiate between traffic to the neighbour of a pair of hosts, or out to the rest of the network.

Note there is no requirement for comms across different pairs of host. There is only a requirement for comms between the two hosts that make up a pair. The setup below will allow for comms between pairs of hosts.

nft is setup so that any traffic with a destination IP of it's neighbour is steered to the correct eth port and vice versa. For example, if a packet from host 172.30.21.50 (source) comes in from eth0, and has a destination IP of 172.30.21.60 (its neighbour), then nft sends it out through port eth1. No NATing is required.

If a packet comes in from the network with a destination IP of 172.30.22.010, then it is DNATed to 172.30.21.50 with the source untouched (ip xxx.xxx.xxx.xxx) and sent out eth0 port.

The reply to that packet coming back in eth0 port with have a dest IP of xxx.xxx.xxx.xxx, and a source of 172.30.21.50. This is SNATed to 172.30.22.010 and sent out to the network. The network thinks it is communicating with a host on IP 172.30.22.010.

Part C differentiates between external traffic and traffic between pairs. From outside, each host looks like it has its own IP address. Each host can communicate with its neighbour without knowing that there are multiple pairs of hosts with the same IP addresses. All of this is done with a single Linux box with one ethernet port per host.

Bitcoin Switch This solution is limited by the number of available ports on the Linux box. The work around is to use machine designed for bit coin mining. These have many more pci-express connectors than a standard MoBo. Each connector can take a 4-way network card. It isn't hard to find a mobo with more than 15 pci-e interfaces. That makes a single Linux box with 60 or more ports a practical solution.

The throughput of a single Linux box based on a bit coin MoBo will not match a purpose build Cisco switch/router but it works for a lab test environment (my application). It is a low cost and efficient solution in terms of:

• energy consumption,
• space,
• single box solution,
• $$ cost.

It is a much better solution than Cisco can provide.

This is something that should be achievable in software inside the device. Having to connect a physical router on each switch port is a club fisted solution. I hope there is a better solution. If you can offer a good solution, then please get writing.

The IP pipeline of this solution is illustrated in the diagram below. The first router NATs the externally visible address pairs to another subnet specifically to separate the VLAN subnet ranges so they are acceptable to the switch. The VLAN then directs traffic to specific switch ports. The router then NATs the intermediate address to the actual address of the server.

I think there is a good chance this could be done with a single Linux box and IP Tables. A bit mining MoBo with 8 or more PCI-e slots running a low spec CPU and a whiff of RAM plus budget quad Gb NICs would probably provide a single device solution. In contrast, a pure Cisco solution looks like it would need 11 devices! That is worth further investigation.

The whole point of VLANs is to be able to create a virtual network in software. Having to double NAT IPs in hardware to work around programmed software constraints of the switch is not good. If this is the way that it has to be done, then this answer (as bad as it is) will be of interest to others with similar problems. If there is a better way of doing this, please contribute your answer.

The IPTables Solution

Having decided that a Cisco based solution won't meet the design requirements, I looked for alternatives. It didn't take long to find IP Tables.

This will be connected to a PC with a lot of PCI slots. MoBos made for bit coin mining are ideal candidates. Quad Gb NICs are now readily available. It is relatively cheap and easy assemble a PC with 24 Gb Lan ports. A lot cheaper than a new Cisco device.

The process is illustrated below.

Step 1. Write a IPtables rule that sends a block of IP addresses to a specific port. 172.30.21.50 to 99 > 172.30.21.100 The block is the IP addresses that map to the IP pairs. The port 172.30.21.100 is connected to a server running IPtables and installed with many network cards (quad PCI 1Gb NICs).

Step 2. The IPtable rules direct each IP address of the block to a specific LAN port. Those same rules NAT the address to match one of the IP pairs

The whole point of VLANs is to be able to create a virtual network in software. Having to double NAT IPs in hardware to work around programmed software constraints of the switch is not good.

I concluded that a Cisco based solution was too complex and required too many devices. It is a bad solution.

I decided that a layer based solution was the wrong approach. I started looking at an IP pipeline illustrated in the diagram below. The first router NATs the externally visible address pairs to another subnet specifically to separate the VLAN subnet ranges so they are acceptable to the switch. The VLAN then directs traffic to specific switch ports. The router then NATs the intermediate address to the actual address of the server.

The IPTables Solution

Having decided that a Cisco based solution won't meet the design requirements, I looked for alternatives. It didn't take long to find IP Tables. IPTables (almost) ignores layers. It is specifically designed to process IP pipelines.

This will be connected to a PC with a lot of PCI slots. MoBos made for bit coin mining are ideal candidates. Quad Gb NICs are now readily available. I will call this the switch host. It is relatively cheap and easy assemble a PC with 24 Gb LAN ports. A lot cheaper than a new Cisco device.

The IPtables process pipeline is illustrated below.

Step 1. Write a IPtables rule on the firewall that sends a block of IP addresses to a specific port on the switch host. 172.30.21.50 to 99 > 172.30.21.100 The block is the IP addresses that map to the IP pairs. The port 172.30.21.100 is connected to the switch host with many network cards (quad PCI 1Gb NICs) installed .

Step 2. The IPtable rules on the switch host direct each IP address of the block to a specific LAN port. Those same rules NAT the address to match one of the IP pairs

The more I learn, the less likely a pure and practical Cisco solution is achievable. There are quite a few questions out there seeking solutions to a variety of problems with overlapping subnets. The range of solutions offered by Cisco is very narrow.

The whole point of VLANs is to be able to create a virtual network in software. Having to double NAT IPs in hardware to work around programmed software constraints of the switch is not good. If this is the way that it has to be done, then this answer (as bad as it is) will be of interest to others with similar problems. If there is a better way of doing this, please contribute your answer.

The Requirements This solution aims to solve the problem of connecting pairs of hosts. Each IP address of hosts of the pair is different. All pairs share the same two IP addresses. The IPs of the pairs are:

172.30.21.50

172.30.21.60

The Use Case here is for a test and development system. Only average network speed is required. There is one connection to the rest of the network. The solution must be efficient in space, energy usage and cost.

The Cisco "Solution" There are quite a few questions out there seeking solutions to a variety of problems with overlapping subnets. The more I learn, the less likely a pure and practical Cisco solution is achievable. The range of solutions offered by Cisco is very narrow.

The whole point of VLANs is to be able to create a virtual network in software. Having to double NAT IPs in hardware to work around programmed software constraints of the switch is not good. If this is the way that it has to be done, then this answer (as bad as it is) will be of interest to others with similar problems. If there is a better way of doing this, please contribute your answer.

The IPTables Solution

Having decided that a Cisco based solution won't meet the design requirements, I looked for alternatives. It didn't take long to find IP Tables.

The solution I came up with is as follows:

My network has a Linux IPtables based firewall/router.

This will be connected to a PC with a lot of PCI slots. MoBos made for bit coin mining are ideal candidates. Quad Gb NICs are now readily available. It is relatively cheap and easy assemble a PC with 24 Gb Lan ports. A lot cheaper than a new Cisco device.

The process is illustrated below.

Step 1. Write a IPtables rule that sends a block of IP addresses to a specific port. 172.30.21.50 to 99 > 172.30.21.100 The block is the IP addresses that map to the IP pairs. The port 172.30.21.100 is connected to a server running IPtables and installed with many network cards (quad PCI 1Gb NICs).

Step 2. The IPtable rules direct each IP address of the block to a specific LAN port. Those same rules NAT the address to match one of the IP pairs

172.30.21.50 > NAT 172.30.21.50 > eth1

172.30.21.51 > NAT 172.30.21.60 > eth0

172.30.21.52 > NAT 172.30.21.50 > eth2

172.30.21.53 > NAT 172.30.21.60 > eth3

etc.

TO DO What I haven't done is actually test this. To do that I need to get at least one quad Gb NIC and write the IPtable commands to setup the rules. I have read enough about IPtables to know the above steps will work. I need to figure out the precise commands needed to make it happen.

It will take me at least a couple of months to get the hardware and test a prototype. Until then, this answer will remain incomplete. There should be enough information here to allow someone else to solve their problem with IPtables.

IPtables is very flexible, so if your problem is not the same as mine, it should be easy to adapt to get the solution you are looking for.

I will update this answer after I have tested the prototype.