Two NICs on same subnet?

[cpals]

I think this is an elementary question, but I always thought it would be impossible to put two NICs on the same subnet. After looking around though I think it may be possible, I just don't know how to tell the traffic which way to go that I want.

Example:

I have a server connected to a SAN via ISCSI. Right now all LAN traffic and SAN traffic go out one NIC and the SAN/LAN is on the same subnet. It would be easy if the SAN was on a different subnet, but it's not.

Can I put two separate NICs on 192.168.2.X and have traffic going to the SAN go out one NIC and the rest of the traffic go out NIC 2. How would I do this? Static route entries?

 

[mvbighead]

If you're asking for two NICs in one server on the same subnet and don't think so... I may be wrong, but I had tried to do the same thing, but ended up putting my NIC traffic on one subnet, and my iSCSI traffic on a different subnet because Windows was against it. If you have a VM, you could always try to mimic what you are wanting to do with a physical box and see what the OS allows you to do.

 

[ikky68]

I don't think that's possible.

See if your switch allows for trunking, increase your BW that way.

 

[ScottMac]

Just make sure they have different host addresses (i.e., 192.168.1.1 and 192.168.1.2 for example).

You can then steer the traffic using static routes. To aim at a specific host (like your server/SAN) use the full address and the subnet mask 255.255.255.255 indicating that every bit of the address is significant.

I haven't done this is a long, long time ... so it may or may not work.

And, as suggested before, there's really not much, if anything to gain and doing this unnecessarily complicates the network. If your current NIC is weak or pulling too much CPU process time, put in a good "Server class" NIC and it'll drive the LAN media as hard as is possible with little strain on the processor(s).

 

[cpals]

Okay... maybe I'm not crazy?

So this wouldn't work?

nic0:
IP - 192.168.0.3
G - 192.168.0.1

nic1:
IP - 192.168.0.4
G - 0.0.0.0

put a static to the SAN (static 192.168.0.50 192.168.0.4)

So all traffic to 0.50 goes out 0.4?

Edit:

Sorry Scott... walked away while posting and hadn't seen your response.

 

[Nothinman]

Okay... maybe I'm not crazy?

So this wouldn't work?

nic0:
IP - 192.168.0.3
G - 192.168.0.1

nic1:
IP - 192.168.0.4
G - 0.0.0.0

put a static to the SAN (static 192.168.0.50 192.168.0.4)

So all traffic to 0.50 goes out 0.4?

Edit:

Sorry Scott... walked away while posting and hadn't seen your response.

You can also specify an interface with the route add command so it might work.Maybe, if you're lucky. But Windows doesn't handle being multihomed very well in the first place, putting two interfaces on the same subnet seems like an even worse idea.

 

[imagoon]

You can do it with bonding, however is there a good reason to do so? Is your SAN a real SAN or just home sized NAS? A real SAN should be on it's own network segment that is not shared with general access with dedicated switches or a QoS'd VLAN (@10gig mostly or etherchannel). iSCSI and SAN based traffic is very sensitive to latency and packet loss. It is atypical to have it on the general access LAN as key things like flow control and jumbo frames cause issues with other general devices.

 

[seepy83]

Is your SAN a real SAN or just home sized NAS? A real SAN should be on it's own network segment that is not shared with general access with dedicated switches or a QoS'd VLAN (@10gig mostly or etherchannel). iSCSI and SAN based traffic is very sensitive to latency and packet loss. It is atypical to have it on the general access LAN as key things like flow control and jumbo frames cause issues with other general devices.

This is pretty much exactly what I was going to post. OP, do you have a SAN or a NAS?

 

[cpals]

You can do it with bonding, however is there a good reason to do so? Is your SAN a real SAN or just home sized NAS? A real SAN should be on it's own network segment that is not shared with general access with dedicated switches or a QoS'd VLAN (@10gig mostly or etherchannel). iSCSI and SAN based traffic is very sensitive to latency and packet loss. It is atypical to have it on the general access LAN as key things like flow control and jumbo frames cause issues with other general devices.

That's the problem since the SAN was initially put on the regular network subnet, which goes through the same switches/vlan. It's a regular NetApp 2050 SAN. We're in the process of upgrading the heads and are going to put it on it's own vlan, but we're stuck with how it is for now.

The NetApp only has two NICs on it bonded together.

 

[RebateMonger]

You can also specify an interface with the route add command so it might work.Maybe, if you're lucky. But Windows doesn't handle being multihomed very well in the first place, putting two interfaces on the same subnet seems like an even worse idea.

A client's SBS 2003 server was set up with two NICs, both on the same subnet. IPs are 192.168.1.254 and 192.168.1.253. That company's former IT person made it work with ROUTE commands. It does its job, but it's a dumb idea and toally unnecessary.

 

[spidey07]

A client's SBS 2003 server was set up with two NICs, both on the same subnet. IPs are 192.168.1.254 and 192.168.1.253. That company's former IT person made it work with ROUTE commands. It does its job, but it's a dumb idea and toally unnecessary.

Yes. It falls under the "really, really bad idea" category. You CAN do it, but you really shouldn't. There is zero reason to do so and adds nothing but complexity and general "weirdness" on the host side. Anytime one needs to add static routes on a HOST, one needs to rethink what you're doing it and do it differently.

 

[Nothinman]

Yes. It falls under the "really, really bad idea" category. You CAN do it, but you really shouldn't. There is zero reason to do so and adds nothing but complexity and general "weirdness" on the host side. Anytime one needs to add static routes on a HOST, one needs to rethink what you're doing it and do it differently.

I've seen people think it's a simple way to get load balancing since they don't understand how TCP/IP actually works. Which sadly seems to cover the majority of Windows admins...

 

[JackMDS]

Hmm.... I do not understand it? It works with plumbing, I can connect two pipes to my water heater and they go to the places of my choice!

 

[Nothinman]

Hmm.... I do not understand it? It works with plumbing, I can connect two pipes to my water heater and they go to the places of my choice!

Do you actually own a book of bad analogies or are they just always floating in your head?

 

[gsaldivar]

Do you actually own a book of bad analogies or are they just always floating in your head?

Are you trying to say that isn't how it actually works...?

 

[Emulex]

works fine. i have my wireless and powerline networking both on the same network. when the wifi drops below the speed of the powerline networking - windows auto metric switches preferred to the faster link.

 

[Nothinman]

Are you trying to say that isn't how it actually works...?

Well it kinda is if the OS' TCP/IP stack works properly and that's up for debate with regards to Windows...

works fine. i have my wireless and powerline networking both on the same network. when the wifi drops below the speed of the powerline networking - windows auto metric switches preferred to the faster link.

If by work fine you mean "not how the OP wants at all", then yes, you're right.

 

[RebateMonger]

Do you actually own a book of bad analogies or are they just always floating in your head?

Jack has been saving up analogies for years. We don't want his head to explode.

works fine. i have my wireless and powerline networking both on the same network. when the wifi drops below the speed of the powerline networking - windows auto metric switches preferred to the faster link.

I'll work as long as either path will allow you to get to the same final destination. But that's not always the case. That's when you either need NICs on different subnets or you need ROUTE commands.

 

[JackMDS]

Jack has been saving up analogies for years. We don't want his head to explode.

Not a problem for me, that is what I did this for the 40 years (dealing with exploded heads).

The analogy was actually a joke. Trying to say that if it work with plumbing it must work with computers too.

One does not have to be a genius to see that the that many "enthusiasts'" knowledge in electronics and computer technology is done via taking the plumbing approach, mitigated by some Social politicking stand (Intel vs AMD, ATI vs nVidia, Windows vs. Penguins) with No real balanced, and differentiation based on knowledge and functional considerations. -

 

[imagoon]

If it means anything... I got the joke. IE: Many people want their PC to be like plumbing, IE it just works 99% of the time and only needs to be fixed once every 20 years.

 

[JackMDS]

If it means anything... I got the joke. IE: Many people want their PC to be like plumbing, IE it just works 99% of the time and only needs to be fixed once every 20 years.

Yeah, it will be nice this way, and one day in the future it will happen.

Look at medicine and the advances that were made in the last 50 years.

It was done by many people working very hard for modest pay, and Not by spending most of the time "bickering" over nonsense in forums and Facebook.

 

[Nothinman]

Yeah, it will be nice this way, and one day in the future it will happen.

Look at medicine and the advances that were made in the last 50 years.

It was done by many people working very hard for modest pay, and Not by spending most of the time "bickering" over nonsense in forums and Facebook.

I'm sure there was lots of petty bickering, it was just less public.

 

[bobdole369]

Yes. It falls under the "really, really bad idea" category. You CAN do it, but you really shouldn't. There is zero reason to do so and adds nothing but complexity and general "weirdness" on the host side. Anytime one needs to add static routes on a HOST, one needs to rethink what you're doing it and do it differently.

I've done this. It was intended as failover. It worked that way without any prodding. See the metric for the "first" interface (talking Windows XP at least) is the lowest, and the second interface has a higher metric, thus any traffic for the subnet will absolutely leave via the first interface. A similar thing happens when you assign additional IP's on the same subnet to an interface. Trouble is that you can't "choose" which interface sets up first and it seems random once rebooted.

I had a stupid boss who wanted to split up server traffic that way so he could somehow keep a drawing better organized. Yeah...... He was a CEO not a very bright IT admin.

 

[freegeeks]

Yes. It falls under the "really, really bad idea" category. You CAN do it, but you really shouldn't. There is zero reason to do so and adds nothing but complexity and general "weirdness" on the host side. Anytime one needs to add static routes on a HOST, one needs to rethink what you're doing it and do it differently.

that is absolutely not true at all. That means that servers can not have different interfaces?
The absolutely worst designs I have seen are the ones which use one interface for EVERYTHING. In a good design you will split the traffic on your hosts, a properly designed voip server will have a sip interface, RTP interface, OAM, external interface for API calls, etc ....

 

[spidey07]

that is absolutely not true at all. That means that servers can not have different interfaces?
The absolutely worst designs I have seen are the ones which use one interface for EVERYTHING. In a good design you will split the traffic on your hosts, a properly designed voip server will have a sip interface, RTP interface, OAM, external interface for API calls, etc ....

Wow. Not sure if serious. That is never done nor recommended on even the largest VoIP installations and I've done plenty in the 10,000 stations and up range.