Need help on Mirror Configuration

[Gokhan ALGANATAY]

Problem: Unexpected traffic appears at edge switch port

Configuration : Single Procurve 5406 as backbone and all Hp procurve edge switches (2810, 2910 etc)

Observation: There is no mirror configuration at neither backbone nor edge switches. Capture results of any related packet show that source and destination mac and Ip addresses are as expected. 

Case: When I capture unicast traffic at the edge switch port or an empty port of backbone sw, I see traffic that should not reach my port. For example smtp connections comming from security gateway to nlb adress, http connection requests going from clients to URL filter appliance. 

Actions: I double checked that there is no mirror setting at the backbone and edge switches. 

I'm completely stuck, any ideas (even the weirdest ones) are appriciated.

[Michael Patmon]

Sounds like those packets are being flooded on the VLAN.  Packets that would get flooded normally:

• Broadcast - all F's MAC DA
• Multicast - least significant bit in the most significant byte of MAC DA is 1, generally 01:xx:xx:xx:xx:xx for IPv4
• Only reserved Mcast are flooded with IGMP enabled
• Unknown unicast MAC DA - probably what you're seeing

So for the MAC addresses being flooded I would check that the destiation MAC is learned (show mac-address).  If not it's flooded. 

[Gokhan ALGANATAY]

Hi Michael,

Thank you for the reply,

I was unable to access customer networks for the weekend. I'm goint to check for it as soon as possible.

Gokhan

[Gokhan ALGANATAY]

In the customer site I localized the problem packets to Exchange NLB and two CAS servers.

When I check the mac table for top of the rack switch and the backbone switch those MAC addresses are listed without a port assignment. That seems to be the reson for the broad cast.

However I when I check the NLB setting it is in unicast setting.

So, I still cannot understand the reason why those packets are flooded all around.

Gokhan

[Michael Patmon]

I'm not sure why the entry would displayed in "show mac-address" with no port information.  I'll have to investigate that.  If you see it being flooded it means that MAC is not in the hardware MAC table, probably because it has not seen that MAC as a source address in a packet.

From the limited info gathered on NLB it looks like the flooding might be intentional to facilitate load balancing.

NLB assumes that NLB interfaces are connected to a Layer 2 device by default. This configuration uses the MaskSourceMAC feature to ensure that the switch is unable to learn the original source MAC addresses of the NLB hosts.

In Unicast cluster operation mode, if the switch is unable to associate a MAC address with a particular port (because it is masked) it sends the data to all switch ports; thereby ensuring that all NLB hosts process the traffic.

To identify NLB-enabled hosts when using switch or network tracing software look for MAC addresses that start with 02. The masked MAC address is similar to the original MAC address, but with the first two fields replaced as follows: 02-[Host ID including zero]-[Original MAC address values]. That is, an NLB host with a host ID of 3 and a MAC address of 00-19-BB-3C-29-08 has a substituted source MAC address of 02-03-BB-3C-29-08.

https://technet.microsoft.com/en-us/library/ff849728.aspx

[Vince-Whirlwind]

I've seen this before too.

Basically in my situation the server was responding to ARP requests with a MAC address of an interface it wasn't using and conducting its side of the subsequent conversation using a different MAC address.

So frames going to the server were being addressed to a MAC address that wasn't being used in any replies, so the switch was not learning its port ID, so all those frames were being flooded to all switchports on the VLAN.

Basically it was bad interface/routing config on the server.

[Gokhan ALGANATAY]

Thank you for the comment. Could this be the expected behaviour for the NLB protocol? If not do you suggest static mac address entry on specific ports of 540X?

Gokhan