cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5078
Views
8
Helpful
11
Replies

unicast flooding vmware mac-addresses 0050.56

pclevis
Level 1
Level 1

Hi all,

I recently noticed that we have a unicast flooding problem coming from the vmware-devices.

All devices (vmware, PC, AP's, ...) are in the same vlan (vlan2), the vmware are directly connected to a C4503-core switch and traces are taken on a C2960-access witch.

If I look at the CAM-table of the 4503, the mac's are present, but still I see flooding (1000's pakects) from time to time.

It's one-way traffic --> only "ack" coming from one of the devices, the rest is not flooded.

The C4503 has IOS cat4000-i9s-mz.122-25.EWA5 installed.

No STP changes (rstp) before, during or after the flooding

Only flooding of the mac-addresses starting with 0050.56 and only "ack"

LAN-topology is a star-topology -> a C4503-core with several C2960's connected

All vmware-devices are directly connected on the WS-X4548-GB-RJ45 of the core-switch.

Thanks,

Patrick    

11 Replies 11

Eugene Lau
Cisco Employee
Cisco Employee

HI Patrick,

Just a few questions to clear things up for me.

1. You've checked the 00:50:56 mac on the 4506 but what about on the 2960 at the time you get flooding?

2. Anything unusual reported in the logs, such as mac-address flapping - in any of the switches?

3. If you look at the sniffer trace, what is the delta from the starting packet to the ending packet in the time stamp. That is, how long does the flooding last for?

4. Is there anything unique about the VM? load balancing, redundant cluster etc

5. Are you seeing any traffic that has the source mac is 00:50:56.xx.xx.xx of that VM?

Eugene.

Here's the basic of unicast-flooding. Switch starts to flood unicast traffic when it does not know or learns about the destination mac in the CAM table. Meaning that the originating device sends a complete unicast traffic to the switch, but switch does not have dest mac in mac table. Some of the known reason why switch would not learn or flush the mac-address are below

1. Asymmetric path between source and destination.

2. mac sync issue between DFC and SP (6500 stuff !!!)

3. No incoming traffic from the destination machine ( usually incase of backup server as they dont send out any network traffic).

4. Seperate vlans using different HSRP gateways for redundancy and loadbalance (sort of asymmetric routing)

If you encounter any off the above issue. Configure below command and should take care of it.

- mac address-table aging-time 14400

this will hold the mac untill the ARP expires, so if there is really no traffic ARP will purge out too.

I hope you find this post useful.. Please rate it helps.

Regards,

Sebastian Fernandez

I have already changed the mac-aging-timer to 7200 and this helps.

I also found on another switch in the LAN a server with SLB-method configured as NIC-teaming, without a channel configuration on the switch.

The result was MAC-flapping on that switch.

Can this cause the flooding on another switch?

Yes this may cause unicast flooding depending upon if the the new MAC info is flooded intime to the neighor switch.

Kindly rate posts if you find the solution as helpful.

Rgds,

Sebastian Fernandez

A wless device that roams from one AP to another and where the AP's are connected on other switches, gives also a MAC-FLAP.

Thus this means that this also can cause unicastflooding, because the CAM-table is flushed?

Hello Eugene,

Nothing seen on that C2960, on another C2960 I have seen a continuous MAC flapping caused by NIC-teaming (SLB) and no channle configured on that C2960.

The only traffic that I see on the C2960 that has source 0050.56 is broadcast- and multicast traffic.

Roaming of clients from one AP to another would not cause much of the unicast flooding.. Actually this mechanism also helps to allow traffic to be passed even if the destination mac is not learned. Hence when client move from one AP to another, new mac is learned on the next flow in new AP zone. So this may not cause much traffic.

In my opinion identify the vlan where you unicast flooding and isolate source that is causing the uncast flooding. Understand why its MAC is not been learned i.e. no traffic incoming from it.

Rgds,

Sebastian Fernandez

Hey Patrick,

a. RE Wireless client Roaming

-> no big issues if the mac-address flap is for this and is not frequent. You are correct in that when this address flaps, and if there's traffic destined for the client you will see temporary flooding. The key is to understand that the switch should not age out the whole mac-address table, only flag that address.

b. Flapping due to SLB should be fixed but should not cause other switches to "fast age" their mac tables, unless a TC (topology change occurs)

(I am  assuming that there is no relationship between the flapping SLB MAC and the VM MAC you are focused on.)

- double check for fast aging

#sh mac-address-table aging vlan [no] -> should see 300seconds (if default)

Run it a few times in a row to make sure aging is not changing.

Let's focus on the issue at hand, where you ran a sniffer trace on the 2960 and saw the unicast flooding.

- does the 0050.56 mac appear? Have you ever seen it disappear? or have you resolved it with the higher mac aging? (run the #sh mac address-table address xxxx.xxxx.xxxx over and over until you see flooding on the sniffer)

- is there any port security or similar mechanism or straight?

- is there a pattern in the source address in the sniffer trace that see's unicast flooding?

Eugene.

Aaron Street
Level 1
Level 1

Did you ever find the casue of this issue? I would be really intrested to hear as I ahve same issue on 6506.

I know this is old but I found what my issue was.

Some one had created wo management interface on the vmware virtual switch, and vmware was reciving on one and sending on the other. to compaund the issue it responded to ARP requests with only one of the MAC addresses but used the other in conversations.

So when the swich would learn MAc address A of the VMware server as this is what it used to send data, but there server we respond to mac address B as it had lernt via ARP. Becasuse the switch had not seen MAC B as a soruce address it simple turns in to a hub and floods the packets across the network.

The solutions was to set the arp time and and mac address learning age to the same values, and also correct the configuration on the vmware server so it always used the same MAC address as it responded with in its ARP messages. Ie only one managemnt interface per subnet.

ITInfraTeam
Level 1
Level 1

Hi All,

We appear to be experiencing a similar issue on a stack of Cisco Catalyst 2960S (IOS:15.0(1)SE2. Not configured to preform layer 3 (no ip routing).

We have a number of VMware 5.1 hosts in a cluster with VMKernal adapters per host with Active/Standby adapters.

Host A

VMKernal: 172.1.1.1/16
NIC 1: Active

NIC 2: Standby
VLAN: 300

VMKernal: 172.2.1.1/16
NIC 1: Active

NIC 2: Standby

VLAN: 400

VMKernal: 172.3.1.1/16
NIC 1: Active

NIC 2: Standby

VLAN: 500

Host B

VMKernal: 172.1.1.2/16
NIC 1: Active

NIC 2: Standby

VLAN: 300

VMKernal: 172.2.1.2/16
NIC 1: Active

NIC 2: Standby

VLAN: 400

VMKernal: 172.3.1.2/16
NIC 1: Active

NIC 2: Standby

VLAN: 500

When completing a packet sniff on each of the VLANs, we have identified unicast flooding taking place. To add to this we are able to see that the CAM table have all the required MAC addresses to successfully switch the data to the associated port.

What we are identifying also is that standby ports in VMware appear to be receiving traffic (however we do not know if VMware is indeed accepting the traffic).

Has anyone experienced this issue also????

Any assistance would be very much appreciated

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: