0

I have a device with fixed IP address (192.168.1.86). I also have a DHCP network using 192.168.1.x--and I'm not allowed to just reserve 192.168.1.86 on that network. I have one machine (call it a bridge) that needs to be able to talk to both the main network, and that one fixed-address device.

A has two network adapters, so what I've done so far is configure one interface with DHCP to talk to the main network, and the other manually to talk to the fixed-address device. Then I enable one interface and disable the other, so at any given time I can talk to one or other other. This is obviously pretty clumsy and sometimes frustrating though.

I'd like would be to manage to do this without manually enabling/disabling the interfaces, but having all traffic destined for 192.168.1.86 automatically get sent to one interface, and traffic for any other address get sent by the other interface. And yes, I realize that if I can manage to do this, that bridge machine won't be able to talk to 192.168.1.86 on the main network any more--I'm fine with that. As a bonus, it would also be nice if I could get the fixed-address device to talk to the internet via the bridge machine.

This seems like it ought to be a static route, but I'm not sure how (or even if it's possible) to set up a static route for one specific address rather than an entire subnet (especially when that address is inside the subnet otherwise handled by the other interface).

So, can I (and if so how can I) configure the bridge machine to send traffic specifically for 192.168.1.86 to one interface, and traffic for any other address to the other interface?

The bridge machine (the one connected to both the rest of the network and the fixed-address device) is running CentOS 7.

7
  • 1
    So you have two interfaces, both of them on the same 192.168.1.x network? Or are you saying you have two networks, both using the 192.168.1.x subnet? – mikem Sep 13 '20 at 23:55
  • Two separate networks using the same subnet (and I can't change that). One machine connected to both networks, that I'd like to have talk to both concurrently. – Jerry Coffin Sep 14 '20 at 0:49
  • Is the host at 192.168.1.86 running a standard OS like UNIX/Linux? – mikem Sep 14 '20 at 2:55
  • I think so, but it's more or less a sealed system, so if you want to advise reconfiguring it, chances are pretty good that I won't be able to do it. – Jerry Coffin Sep 14 '20 at 2:56
  • The easiest solution would be to add a second IP to the interface on the 192.168.1.86 host. ie. eth0:1 at 10.1.1.x or something. It's easy to do with virtually no impact. If that's not an option then on your centos host, maybe use iptables to act as a natting firewall for that interface and use portmapping to direct the traffic. On the centos side, it would appear as some other network (ie 10.1.1.x). So instead of ssh'ing (or whatever) to 192.168.1.86, you would ssh to 10.1.1.1 as an example. Not sure if it's doable, but might be worth exploring. – mikem Sep 14 '20 at 3:01
3

Add a host route to 192.168.1.86 with the following command:

ip route add 192.168.1.86/32 dev eth1

where eth1 is the interface the device is connected to. This route is more specific than the normal 192.168.1.0/24 route and will be chosen when talking to the device, for other hosts the normal route applies.

1

If you are able to assign an additional address to the 192.168.1.86 host, you could approach it like this:

On 192.168.1.86 use "ifconfig -a" to get the list of current interface settings, for example:

# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.86  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 00:21:f6:41:94:37  txqueuelen 1000  (Ethernet)
        RX packets 68267884  bytes 20871214051 (19.4 GiB)
        RX errors 0  dropped 3485  overruns 0  frame 0
        TX packets 5758238  bytes 843203020 (804.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets 1663  bytes 508496 (496.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1663  bytes 508496 (496.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 

In my case, I have eth0 as my interface. You can ignore the lo (loopback) interface.

To add an address to this interface, you simply config another "sub" interface and assign an address and netmask to it. For example:

# ifconfig eth0:1 10.33.33.33 netmask 255.255.255.0 up

Which will result in a new interface called "eth0:1":

# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.86  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 00:21:f6:41:94:37  txqueuelen 1000  (Ethernet)
        RX packets 68268140  bytes 20871241191 (19.4 GiB)
        RX errors 0  dropped 3485  overruns 0  frame 0
        TX packets 5758341  bytes 843217718 (804.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.33.33.33  netmask 255.255.255.0  broadcast 10.33.33.255
        ether 00:21:f6:41:94:37  txqueuelen 1000  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets 1663  bytes 508496 (496.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1663  bytes 508496 (496.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Then on your "bridge" host, for the interface that needs to talk to the 192.168.1.86 host, configure that interface to also be on the 10.33.33.x network (in this example)... say 10.33.33.1.

At this point, you would no longer refer to the 192.168.1.86 host by the 192.168.1.86 address... it would now be reachable at 10.33.33.33.

This should eliminate the problem with having the same network on two interfaces on your "bridge" host.

To make the additional interface definition permanent on the 192.168.1.86 host, you would add a file in /etc/sysconfig/network-scripts called ifcfg-eth0:1 that might have contents that look similar to this:

TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
NAME=eth0
DEVICE=eth0:1
ONBOOT=yes
IPADDR=10.33.33.33
PREFIX=24

Note that in my case, the interface was eth0. Your's may be different, so extrapolate as necessary. Also, in my example I used the network 10.33.33.x, but you will want to make sure the network you specify doesn't conflict elsewhere in your environment. Generally the 10.x.x.x network is pretty safe, just pick an unused subnet.

Johan's suggestion of using a static route is simple and clean. It will leave the mess of having to reference the same network on both sides of the bridge host in place but should work. My suggestion above will help make the "ugly" double network problem go away from a practical perspective. Either should solve your dilemma.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.