1

I have 2 100Mbps NIC cards installed into PCIe slots and connected each card to it's own desktop 8 port switch.

My Settings:

  • Mode: switch-independent
  • Load Balancing: Dynamic / Address Hash
  • VLAN: I left it all as defaults

However, after setting a static IP because the team was not getting an IP from the network, I still can not seem to get the server to ping inside or outside the network.

EDIT: I played with the settings and I have noticed some glitches where the team does not seem to be act like a team. So I guess a quick question would be does hardware have to be of "highend" quality? For example I am using these switches TRENDnet TE100-S8 8-port Fast Ethernet Switch http://www.newegg.com/Product/Product.aspx?Item=9SIA25V2VW8636

Example:

enter image description here

EDIT: It does work, kinda, but I can't get a RDP in for example. Also, if I pull say switch 1, everything breaks and you can no longer ping out as I tested with ping -t google.com. But if I pull the other switch, the ping carries on like it should so I am lead to believe it only is using the one switch.

EDIT 2:

So I found this on a Microsoft site document I downloaded:

3.11.1 The MAC address of the team In switch independent mode with address hash or dynamic load distribution the team will use the MAC address of the primary team member (one selected from the initial set of team members) on outbound traffic. The primary team member is the first team member to bind to the team after team creation or host reboot. Since the primary team member may change in a non-deterministic manner at each boot, NIC disable/enable action, or other reconfiguration activities, the MAC address of the team may vary from time to time. Normally this won’t cause problems but there are a few cases where it may. If the primary team member is removed from the team and then placed into operation there may be a MAC address conflict. To resolve this conflict disable and enable the team interface. The process of doing a disable and enable operation on the team interface will cause it to select a new MAC address from the remaining team members. If MAC address stability is desired for the team the administrator can set the MAC address of the team to any MAC address the administrator wants to use by setting it in the primary team interface the same way that an administrator can set the MAC address of any physical NIC. SOURCE: https://www.microsoft.com/en-us/download/details.aspx?id=40319

Is this saying that if the NIC that is being used as the MAC goes down you have to restart the NIC TEAM? I've noticed I can pull one switch offline and nothing goes down, but when I pull the other it crashes despite the other switching being on so my issue would be MAC related?

  • Are the switch port configured for teaming (PaGP /LACP) ? – krisFR Jun 14 '15 at 23:44
  • The switches are smart desktop switches. No way to configure. – Jason Jun 15 '15 at 0:02
  • Have you checked whether or not you can ping the server without NIC teaming? You shouldn't be able to ping Windows Server 2012 R2 by default. – joeqwerty Jun 15 '15 at 0:26
  • Deleted the NIC Teaming and I was not able to ping the server but could then access the internet. I rebooted the server once and it worked. Rebooted again and it stopped working. – Jason Jun 15 '15 at 0:41
  • The two switches are connected to each other right? If not there's no benefit to teaming those two interfaces. – Todd Wilcox Jun 15 '15 at 1:50
1

The "desktop" switches don't need to be connected to each other to take advantage of NIC teaming. Switch Independent teaming is fully supported with each team member connected to independent, non-connected upstream switches.

Although I haven't used NIC teaming in Windows Server 2012 R2 yet, here's what I think is happening:

In Switch Independent Mode with Address Hashing, the server uses the MAC address of the primary team member. So while outbound traffic may be load balanced across both team members, inbound traffic will be directed to the primary member (since an ip address can be associated only with a single MAC address). This means that the ip address of the server resolves to the MAC address of the primary team member when the primary team member is connected and working. When the primary team member fails the ip address then needs to be associated with the MAC address of the "new" primary team member. If you're testing from a computer connected to the edge switch then it stands to reason that the ARP table on the testing computer still has the ip address to original primary team member MAC address association. You can easily test this by flushing the ARP cache on the testing computer and then trying to connect to the server.

The other possibility (although I don't think it's the case here because of the teaming mode and load balancing mode you've selected) is that the problem is due to the MAC address of the primary team member being cached in the edge switches MAC address table (Note that the switch MAC address table is the MAC address to switch port association. This has nothing to do with ARP). I don't believe that's the case here because in your teaming and load balancing mode, each teamed adapter should be using a MAC address independent of each other. If each team member used a single "shared" MAC address then this scenario would be the likely cause of your problem.

I may be completely off base, but hopefully this gives you a few things to look at.

  • Assuming that this is a ARP/MAC address issue, is this just due to the setup or lowend switches and the need to use higher grade equipment? – Jason Jun 15 '15 at 17:41
  • As for the ARP cache, the switches have nothing to do with the ARP cache of the machines trying to connect to the server. As for the MAC address table of the switches, yes using desktop switches could be part of the problem. If the desktop switches don't support the Spanning Tree Protocol then they can't notify the edge switch that a topology change has occurred, which would then cause the edge switch to reduce it's MAC address table age timer. As I said though, I don't think the problem is with the MAC address table of the switches, I think it's an ARP issue. – joeqwerty Jun 15 '15 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.