SMB communication on tcp port 445 causes huge traffic in network

Question

Hello All,

I am faced with a strange situation. All of the lan interfaces in a vlan are receiving too much traffic for two hours every morning. I captured the traffic and the traffic is tcp traffic between two servers on port 445. The traffic I am talking about is not netbios traffic but it is still getting received on all of the interfaces in the vlan on which those two servers reside. I have traced to the source of the traffic and it seems that it is Microsoft SCCM server. I have attached the screenshots of the packet capture and the statistics of that packet capture. Also I am capturing traffic in promiscuous mode but other traffic (traffic other than 445) between those two servers is not seen on every other host in that Vlan. Can somebody please help me…

Please refer the packet capture details :

Answer 1

After some out-of-band communication with the author of the question, the answer is that the flooding of non-participants of the tcp session in question is caused by use of Mircosoft's Network Load Balancing mechanism in the LAN.

The packets which flood the non-participants look as follows:

Ethernet II, Src: d8:8d:37:14:59:a8, Dst: 02:bf:0a:0e:23:f7
Destination: 02:bf:0a:0e:23:f7
    Address: 02:bf:0a:0e:23:f7
    .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: d8:8d:37:14:59:a8
    Address: d8:8d:37:14:59:a8
    .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.14.35.232, Dst: 10.14.35.224

(IP and MAC addresses manually anonymized)

The destination MAC address is not a multicast one, but it is a "locally administered" one. The 02 bf indicates that the MAC is created by MS NLB, the remaining four bytes represent an IPv4 address.

The overall functionality is such that there is a group of NICs which the administrator wants to participate in handling requests sent to a common IP address depending on their actual load, so they need to make the network deliver each request to all of them. Which one will actually serve a given request is their internal decision.

To achieve that goal, the group responds to arp requests to the group IP address with the 02:bf:ip:ad:re:ss MAC address, but each NIC sends outgoing IP packets with its real MAC address as source. As a consequence, the switches in the network never see the 02:bf:ip:ad:re:ss as source MAC, so they cannot associate it to any port, and thus any packet with this address as destination MAC is sent to all ports of the switch (leaving VLANs and the ingress port aside for simplicity). This behaviour is essential to make the whole idea work, and the collateral damage is that everything else connected to that LAN is flooded with copies of all packets sent towards the group IP.

Microsoft seems to support use of multicast MAC address, instead of a unicast one, for the group IP. On more advanced switches, use of multicast MAC address allows to choose which ports should forward such traffic on egress and which not, but not every switch can do that and some of those which can have to spend extra CPU power on that.