Background:
A NIC Team is known by a single MAC address to clients in the network. This MAC address is only used as the source MAC address by the Primary adapter in the Team. Secondary adapters in the team use their own MAC address as the source address. This MUST be done by NIC Teaming to be compliant with IEEE standards.
For TLB, when a client ARP's for the Team's MAC address using the Team's IP address, the Team will respond with the Team's MAC address (used by the Primary adapter). So, all traffic is received by the Primary adapter. Traffic transmitted out of the Primary adapter has a source address of the Team. Traffic transmitted out of the Secondary adapters use their own MAC address (not the same as the Team MAC address). Since clients with a proper TCP/IP stack implementation should ONLY update their ARP table based on data received in ARP request or replies, receiving data with a different source MAC from a secondary adapter will not affect clients with a complient TCP/IP stack.
Some implementations of the TCP/IP stack in clients are picky in that they require the source MAC address to match the MAC address in the ARP cache. There's no good reason for this. In fact, we've found a few of our own products that had this incorrect implementation and we had to fix it.
A NIC Team is known by a single MAC address to clients in the network. This MAC address is only used as the source MAC address by the Primary adapter in the Team. Secondary adapters in the team use their own MAC address as the source address. This MUST be done by NIC Teaming to be compliant with IEEE standards.
For TLB, when a client ARP's for the Team's MAC address using the Team's IP address, the Team will respond with the Team's MAC address (used by the Primary adapter). So, all traffic is received by the Primary adapter. Traffic transmitted out of the Primary adapter has a source address of the Team. Traffic transmitted out of the Secondary adapters use their own MAC address (not the same as the Team MAC address). Since clients with a proper TCP/IP stack implementation should ONLY update their ARP table based on data received in ARP request or replies, receiving data with a different source MAC from a secondary adapter will not affect clients with a complient TCP/IP stack.
Some implementations of the TCP/IP stack in clients are picky in that they require the source MAC address to match the MAC address in the ARP cache. There's no good reason for this. In fact, we've found a few of our own products that had this incorrect implementation and we had to fix it.