two eth devices, eth0 gets eth1 bindings?

[zzaappp]

I have a network configuration that has me a little stumped on a work-around. Basically both eth0 and eth1 look as though they are configured for the same network, but they really are on separate physical networks. The problem is that the address assigned to eth1 seems to become available on eth0. /etc/conf.d/net looks like:

[solamour]

Forgive my ignorance, but if eth0 and eth1 are on separate networks, shouldn't they have at lease separate IPs, such as the following?

[zzaappp]

As I said in the original posting: there are two separate physical networks that both use the 192.168.1.xxx block, and that unpleasant truth is something I have no control over. My job is to find a way to prevent eth1 from binding its assigned ip address to eth0.

For the sake of clarity (or absurdity), I'll describe it a bit differently: its two distinct switches set to use the same 192.168.1 block, and except for the server I've installed, this works for them. I was given a static IP to be used for each of the separate networks. Right now the physical network IP address assigned on eth1 is apparently binding to eth0. I do not want that to happen because the eth1 IP address is not the address I was given for eth0.


-z

[gentoo_ram]

Really you have a routing issue here. Let's say another box 192.168.1.3 (on eth0) does an SSH connect to your box. Your box wants to respond to 192.168.1.3. Which interface will that response go out on? Normally the destination address (192.168.1.3) is the sole determining factor which interface the response goes out on.

That's not going to work on your box because it will have 2 different routes to 192.168.1.0/24 in the routing table. One for eth1 and one for eth0. Whichever route it hits first, it will use. If the route that says "192.168.1.0/24 is on eth1" is first, then that's the route it will go out on most likely.

The only thing that's going to muck things up is the ARP cache. It's possible that 192.168.1.3 will be in the ARP cache and the packet will go out on the "proper" network anyway. I'm not sure how that fits in, before or after the routing table.

But if it's after that means the box may decide to send the response out eth1, thus the "source" address of the response is the eth1 interface address. But because of ARP, it may go out on the eth0 network. It may "seem" that eth1 "took over" eth0 but really you just have a totally messed up network configuration that won't work. It all depends on the timing of entries in the ARP cache. Those entries go away after a while, so you will get inconsistent behavior.

Your only hope is to maybe hard-code ARP entries in the table for certain well-known addresses of things that want to connect to your server. Maybe you can limp along that way. But it isn't a long-term solution. The network configuration as stated is bad news. Maybe you can Google something about "source routing". But I haven't had to resort to such madness before on network configurations.

Maybe another possibility is to have 2 different SSH daemon that listen on different ports. One daemon binds only to the eth0 address port 22, one binds only to the eth1 address port 2222. Boxes on the net1 network have to connect to port 2222. That may help with the situation, but I doubt it.

[AngelKnight]

[mp342]

If your network works like this, it's probably because it uses a /29 or a /30 network mask.
The problem with your configuration is with the 192.168.1.15 address: whereas it's the correct network mask, this address is the broadcast address of your network.