1

I've currently got 2 NICs going to my LAN and each one to it's own virtual switch. I've been wondering about instead of the two switches using one virtual switch and having my two LAN NICs teamed.

So I guess the question is what would be the advantages to using teaming vs. the two virtual switches I'm using now? (everything is working now I'm just the type of person who likes to learn new things and I follow the "if it isn't broke break it" method)

Additional information from my comment below: Currently everything is on the same lan. the two virtual switches are connected together by a physical switch. So as far as traffic is concerned using a team vs the two v switches nothing will be different. What I'm wondering is maybe more a comparison between one nic and one vswitch vs a team of nics and a vswitch. Yes you can get more bandwidth with the team but is there a cost somethere? Would I be giving up on latency? CPU overhead?

Some more additional information: This environment though used by people and I want to minimize downtime is not a critical environment and I use it to try out new features/technology before using it on other more critical environments. I'm just trying to get all the information before I start messing around. The two adapters are both Intel CT Gigabit adapters and another question would be should I use the Windows Server 2012 teaming or use the Intel ProSet teaming in the driver?

2
  • 1
    How long is a piece of string? Why do you have two virtual switches? Individual virtual switches are typically used to segment your virtual networks (VLAN's). Why would you want to team the network cards instead? NIC teaming is typically used to increase fault tolerance or to provide link aggregation. It's a little tough following your logic when you're asking which way is better because each way is typically used to achieve different objectives. It's not a question of which is better, it's a question of which one do you need to use to achieve your objectives?
    – joeqwerty
    Feb 21, 2015 at 19:34
  • Valid Points. I guess that's why I'm having a tough time figuring out an answer. Currently everything is on the same lan. the two virtual switches are connected together by a physical switch. So as far as traffic is concerned using a team vs the two v switches nothing will be different. What I'm wondering is maybe more a comparison between one nic and one vswitch vs a team of nics and a vswitch. Yes you can get more bandwidth with the team but is there a cost somethere? Would I be giving up on latency? CPU overhead?
    – David
    Feb 21, 2015 at 21:32

2 Answers 2

3

Here's my off the cuff opinion:

Having two virtual switches connected to the same physical switch doesn't make much sense unless you're connecting the virtual switches to different VLAN's on the physical switch. That leaves teaming. Do you want or need to provide fault tolerance for the physical NIC's? If so then set up a fault tolerant NIC team. Do you want or need to aggregate the bandwidth/throughput of the two physical NIC's? If so, then set up a LAG/LACP team. If you don't want or need either of these then don't do anything. Configure a single virtual switch on a single physical NIC.

Never do something just because you can do it. Do it because you have specific needs, objectives or design goals.

I have three Hyper-V servers each with a 4 port NIC. I'm using 3 of the ports on each server. I'm not trying to find a use for the fourth port. I don't need it in my current design so I'm not trying to find things to use it for. If I need it in the future I know it's available.

1

Team & trunk! I always start with what I find is the best and most flexible arrangement. Team those NICs up. Then configure the team as a trunk. This covers all my possible needs. Load balancing, & VLANs. I agree, do it because you want to learn, good for you.

Only time I wouldn't necessarily team is if I want switch redundancy and couldn't do a team across 2 switches.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .