Question about Virtual Connect behavior

[chuckk281]

Artur asked an interesting Virtual Connect question:

********************

Our customer has 2 VC Flex10. Each VC Flex10 are connected to one core switch. When my customer check core switch log, he tell us that VC is connecting intermittently to all ports with the same MAC address. We are using an active-standby configuration in the Virtual Connect networks uplinks.

In this example, VC MAC is D8-D3-85-69-EA-CF, and monitoring switch port is lag.0.10. As you can see, VC MAC is intermittently show.

TJ_N7_CORE1(su)->sh mac port-string lag.0.10

MAC Address FID Port Type Status

----------------- ---- ------------- ------- -------

00-17-A4-77-04-04 12 lag.0.10 learned

00-17-A4-77-04-06 12 lag.0.10 learned

00-17-A4-77-04-24 12 lag.0.10 learned

00-17-A4-77-04-26 12 lag.0.10 learned

D8-D3-85-69-EA-CF 25 lag.0.10 learned

TJ_N7_CORE1(su)->sh mac port-string lag.0.10

MAC Address FID Port Type Status

----------------- ---- ------------- ------- -------

00-17-A4-77-04-04 12 lag.0.10 learned

00-17-A4-77-04-06 12 lag.0.10 learned

00-17-A4-77-04-24 12 lag.0.10 learned

00-17-A4-77-04-26 12 lag.0.10 learned

If now I go to monitor another switch port where VC is connected, I can see intermittently the same MAC address.

Can someone tell us if this is a normal behavior? If that, where we can found documentation to explain this behavior to customer?

************************

Chris asked :

**********************

So are they experiencing any issues?  I would probably suspect this is due to LLDP frames being sent from VC and the upstream switch not understanding them.

**********************

Andreas also joined in::

***************************

LLDP is using Ethertype 0x88CC and 01:80:C2:00:00:0E (which is a multicast address). So I would not expect this is the source of this kind of entry.

The OUI 00-17-A4-…. and D8-D3-85-… are both registered to HP. But I am not the expert for what information this mac is used inside HP.

Some questions:

-          Can you provide a show mac .. from both core switches?

-          If you have an active-standby setup, there should not learned anything on the core systems which connects to the standby

-          Can you sniff the frame to see, what information is carried with this frame?

*************

Chris replied:

**************************

It all depends on if the switch supports that Ethertype.  If not, it can handle the frame in an unexpected manner.  I have seen this with Nortel switches that did not support LLDP and LACP, where they treated LACPpdu’s and LLDP frames as broadcast traffic, which they are not.

***********************

Herman also had some input:

*************************

I agree that the traffic from a VC Module MAC address that is being learned by the upstream switch is most likely LLDP.

LLDP does use 01:80:C2:00:00:0E as its destination MAC but the source MAC is usually the sender’s MAC (the VC Ethernet Module MAC address in this case).

The Ethertype shouldn’t matter for determination of forwarding.  LLDP’s destination MAC address (and LACP’s too) falls within the IEEE Bridge Filtered MAC Group Address range (01-80-C2-00-00-00 to 01-80-C2-00-00-0F) and should NOT be forwarded regardless of Ethertype.   There are some examples of other vendor’s switch models which do not seem to conform to this at certain code levels.  Examples are Nortel as Chris mentioned and the Brocade(aka Foundry) MLX switch.

In my experience, most vendor’s switches do not “learn” source addresses from LLDP frames but we have seen a few exceptions.  One example is the Cisco Catalyst 3750 on certain IOS levels.  Maybe other vendor switches that don’t support the LLDP Ethertype will learn from those frames but it should still not forward them.

Also, VC Ethernet modules do not have a per port MAC address design but instead use the VC Module MAC address as the source address for all LLDP frames that are sent out of each of its uplinks including links that are in Standby.  If you have more than one uplink from one VC module connected to the same VLAN, you could see the VC Module MAC address flap around a bit on a switch that is learning from LLDP frames (like Cisco above).

 Artur, I’d be interested to know what kind of core switch the customer below has and what version of code it is running to determine if it is just learning LLDP frames (not a big deal) or forwarding LLDP frames (bad).

**************************

Any other input or comments on this subject?