Hi all, Quick couple of questions regarding NIC teaming. 1. It's my understanding that if I have two NIC adapters, and I want to team them. Then I should leave the two adapters set to DHCP, and only give the teamed NIC a static IP? My boss said its wise to give all adapters (unteamed and the teamed NIC) static IPs, but personally I think its not required. 2. Should I team my two Domain Controllers? I've read its not a good idea to team NICs on a DC because it can affect DNS? 3. At work, we have a flat network, consisting of 7 VLANS (VLAN IDs 96-102). I've noticed that my NIC adapters have a tab called "VLAN" and it requires the VLAN-IDs to be entered. Shall I leave this tab alone? My understanding is that I do not need to configure the VLAN tab on my NICs because the switches in the network deal with the VLANs. Thanks all. Any input would be greatly appreciated.

Teaming is not a MS technology, it is a vendor/hardware technology. MS does not support NIC Teaming in any fashion. Point in case: http://support.microsoft.com/kb/968703 That being said, here is my advice. 1) Use static IPs for the physical and the teamed 2) Milage varies with the technology and your skill set. In general for newbies don't do it in production unless you want to learn trial by fire with your boss impatiently wondering why this is causing you problems. Or Disable the Team at the first sign of a problem, and go do more testing to build up your knowledge. 3) If the switch port is assigned a VLAN ID, then you don't need to assign it on the NIC. If the switch port is a TRUNK (passes all VLAN traffic) then your NIC must use a TRUNKING protocol and specify which VLAN ID to use for each packet it sends. In general most people use the first config not the second, SO NO you don't need it.

Thanks for the info, Gunner. The DC's NIC does indeed connect to a switch which in turn is configured as an untagged port on VLAN-96. So there is no need to touch the VLAN tab on the NIC I take it? Can I ask why you advise a static IP on the physical NICs? Does it really matter if the NICs have a static or automatic address prior to teaming? The only reason I can think of giving the NICs a static IP prior to teaming is DNS configuration problems. If I give the NICs a static IP prior to teaming, can the static IPs be anything at all? Also, do you need to give the NICs that are going to be included in the team a gateway and DNS address? I don't see why you'd need to.

Can I ask why you advise a static IP on the physical NICs? Does it really matter if the NICs have a static or automatic address prior to teaming? The only reason I can think of giving the NICs a static IP prior to teaming is DNS configuration problems. What happens when the NIC team fails? How do you troubleshoot/connect to a server with an unknown IP? With no DNS (especial if this is your DNS server)? Static solves these issues. Always, think about how to troubleshoot failures as well. You are welcome to use DHCP, but if it fails in 2 years, and have to come into the office to gain physical access to the server you will be kicking yourself.

Can I ask why you advise a static IP on the physical NICs? Does it really matter if the NICs have a static or automatic address prior to teaming? The only reason I can think of giving the NICs a static IP prior to teaming is DNS configuration problems. What happens when the NIC team fails? How do you troubleshoot/connect to a server with an unknown IP? With no DNS (especial if this is your DNS server)? Static solves these issues. Always, think about how to troubleshoot failures as well. But if the team fails, isn't the teaming software still going to stop the two NICs from working since they are still bound to a team? So if I give the two NICs a static each (say 10.48.96.2 & 3) before merging into a team, could I use these two statics as legit IPs for other devices on the LAN even if they are used for the two NICs in the team? Also, do I need to give the NICs a Gateway and DNS address prior to teaming?

All excellent questions, sound like you have research to do. Some things you are just better off learning through experience. Also, I haven't used NIC teaming in years, because it isn't required to provide high availablity, it is a partial fix to a realitive small problem - a NIC or switch port failing. These problems very rarely happen, and if the application was SO important to the company they should invest in clustering the OS and a cluster aware application not partial fixes. I learned valuable information from teaming NICs, you will too, then you can form your own opinion of the technology and how valuable it is too you. Actually, now that i think of it, if you TEAM the NIC they don't get IP Address, instead a different protocol is used...but i could be wrong, and it may vary by vendor.

Thanks for your help, Gunner. I'll just see how it goes with a team and I'll try without a team, too.

@stuka109, not sure about all of the teaming vendors, but with HP teaming, even if you apply a static IP on the individual NICs, the config will be wiped out once you team them. Leave the NICs set as is, install the teaming software, then manage the NICs via teh software. For a typical configuration, you'll apply a static IP to the virtual teamed IP address. Also, I dont recommend teaming on the DCs. Been there, done that... AS a matter of fact, I would not implement teaming just for the sake of teaming. You are adding a layer of complexity to the system. Only team servers that have a business need for this configuration. In the example of DCs, you have more than one so if a DC is taken offline temporarily due to a network issue, you are still providing AD services with the rest of your DCs. Its all going to depend on the application services being hosted on the server and the SLAs you have in place with your customers. Visit: anITKB.com, an IT Knowledge Base.

Also, I dont recommend teaming on the DCs. Been there, done that... AS a matter of fact, I would not implement teaming just for the sake of teaming. You are adding a layer of complexity to the system. Only team servers that have a business need for this configuration. In the example of DCs, you have more than one so if a DC is taken offline temporarily due to a network issue, you are still providing AD services with the rest of your DCs. Its all going to depend on the application services being hosted on the server and the SLAs you have in place with your customers. Visit: anITKB.com, an IT Knowledge Base. This is exactly what I wanted to hear, JM! Thanks for the help. When I get back to work on Monday, I'm going to take the teamings off the two DCs and just have one NIC with a static IP address, the other NIC will be disabled but ready to enable if one NIC fails. The teaming software we have on one DC isn Broadcoms and the other is Intels. This is probably a stupid question, but just to clarify, is it possible to give a DC two seperate IP addresses with two seperate NIC adapters? Or is that just asking for trouble?

That is considered multihoming and for DCs...you are just asking for trouble. I wouldnt generally multihome. Visit: anITKB.com, an IT Knowledge Base.

That is considered multihoming and for DCs...you are just asking for trouble. I wouldnt generally multihome. Visit: anITKB.com, an IT Knowledge Base. Yeah, basically what I thought. Thanks for the help. I think what I'll do is just give both NICs a static IP, and leave them enabled, but only have one connected to the LAN. So if one NIC fails, all I have to do is plug the other one in.

You should leave the "cold" standby NIC disabled until you need to use it.Visit: anITKB.com, an IT Knowledge Base.

That's what I ended up doing today. I enabled one NIC and disabled the other. I noticed that if I left both NICs active, then the NIC that wasn't being used would put a SRV record in DNS with a 169 APIPA entry. Weird.

That is expected. You can change that behavior, but I would recommend exactly what you did by disabling the NIC.Visit: anITKB.com, an IT Knowledge Base.