Same Network on Two Interfaces

Tom schrieb:

On some OS you can configure it this way but you will not achieve what you want, because always the first rote will match and so at least all outgoing traffic will use e1 (and probably the packets will have the wrong source IP)

For load balancing or speed trunking you must aggregate the two physical interfaces into a single virtual one. See the keywords 'NIC bondin", "NIC teaming", "link aggregation", ...

Many *nix OS support this native, AFAIK windows not (only by using third party software)

Regards Klaus

Klaus is spot on, but allow me to add a little bit of commentary. The short answer is, there is nothing technically wrong with having two interfaces on the same network as long as they have two different IP addresses and mac addresses. But, then the next question is the routing table and how the upper layers use those interfaces. They have to default to one side or the other, and someone would have to manage the app to interface mapping, and the separate routing tables. Else an app would default to one and would never use the other, or if it did use both, the single routing table/default gateway would override it anyway. And this is all just the outgoing traffic.

On the incoming side, the routers/switches have to be able to send traffic to the same server down both paths. But App A has to go out one interface or the other, and therefore you are still not ether- channeling. Now yes I suppose you could engineer flow-based load balancing out two nics, but that is an awful lot to engineer and manage one very server. And, each individual flow would still be capped at 1gbps (or whatever speed).

Therefore, the complexity just isn't worth it. If you want redundancy, you have two nics in the same server with the same IP and you configure failover. If you want performance, you channel them together so the aggregate can go to 2 gbps (or whatever speed) instead of just one. Of course the issue there is that you are only plugged into a single switch, so redundancy at the network layer is gone. The best solution for both redundancy and performance is using external load balancers to manage the VIPs, and let them route accordingly. If you still need the bandwidth, you dual connect to two different switches.

The shortest answer to the question above is that system only has one routing table. So even with two nics, all traffic will go out one path unless you are going to split routes to destinations and manage that. And if you had two gateways, only the first would be used. So what good is having the second nic if all traffic goes out and comes back in the first one? The answer is there is none. You have to look at load balancing or etherchannel, neither of which is solely engineered at the server level.

There are also issues with broadcast and multicast traffic which would all be processed twice, which could be a very bad thing. The system must be able to handle this so that only one of the interfaces processes this traffic, along with the ability to switch which interface is processing this traffic if the active one goes down.

You are incorrect.

It can.

There is nothing to stop you doing that.

Barry ===== Home page

e:

Absolutely agree, but 'can' and 'should' are two very different things. Over-complicates both resiliency and channeling (given other available solutions), and is not scalable to manage.

ote:

I should qualify. I do see a value in this for app servers that can manage two different routing tables, and you have multiple apps on that server that you want to keep separate. But in cases of aggregating bandwidth or having greater resiliency, this is not the way to go.

Thanks for all the great explanations...after I posted this it hit me as to why this isn't a good idea. Duh? Anyway. Thanks for all the answers!