3750G Access Layer Mac Flapping

[Elton Babcock]

Hello Experts,

Lately I have been noticing mac flap messages on some of our access layer 3750G switches.

Just a little background on how this is setup.

These 3750G switches are stacked and uplinked to a distribution layer 3750E stack (2 switches) via cross stacked etherchannel. (Usually 4 links) The access layer switches are stricly layer 2 where the distribution layer 3750E is routing the VLANs at the access layer to to the core 6500 switches.

I have just about ruled out physical loops on these stacks for the reason that the Macs are flapping. I am seeing this on two different stacks now each having 3 switches in the stack at the access layer. The cross stack etherchannel is spanned across the first two switches at the access layer and connected to both switches at the distribution layer.

I have checked the etherchannel status and all ports appear to be part of the etherchannel and they appear fine.

The mac addressses that are flapping are just plain old desktop machines that plug directly into the access layer. I usually see this when the mac is learned on a port such as when a machine is plugged into the network or reboots.

Has anyone seen this before? I'm pretty stumped by it and i'm not sure where else to go with it.

Thanks, Elton

[Reza Sharifi]

Hi,

Are you running the same protocol (LACP or PAGP) on both sides of the links?

Can you post the portchannel config for both sides?

also, what is output of "sh ether summ"

HTH

[Elton Babcock]

Thanks for the reply.

All of our Etherchannels are running LACP on both sides of the link. Either in mode passive or mode active. Always at least one side set on active.

Access layer switch:

interface Port-channel1

description C3-43N

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,16,66,90,91,98,99,166,901

switchport mode trunk

spanning-tree portfast disable

43N-3750-ST1#show etherchannel summary
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator

        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port

Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Gi1/0/49(P) Gi1/0/50(P) Gi2/0/49(P)
                                 Gi2/0/50(P)

Distribution Layer Switch:

interface Port-channel11

description 4-3-N

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,4,16,66,90,91,98,99,166,901

switchport mode trunk

11     Po11(SU)        LACP      Gi1/0/21(P) Gi1/0/22(P) Gi2/0/21(P)

                                 Gi2/0/22(P) 11   

Thanks

[Reza Sharifi]

Hi,

You currently have po1 on one switch and po11 on the other switch.

I know the portchannel numbers are locally significant, and it shouldn't matter what pochannel number you use on what device, but to eliminate this as an issue, is there a way for you to use the same portchannel id on both sides and test again?

HTH

[pille1234]

Between what ports does the flapping actually occur?

[Elton Babcock]

At this point I would like to refrain from having to build a new etherchannel interface as it would create an outage for the users on this stack. That is about 75 people. I understand where you are coming from but we have a lot of other switch stacks with the same setup using different etherchannel IDs on each side and they work fine.



As far as which ports flap it is very random and random to which ports they flap with. It almost always happens when a machine reboots, the port is bounced or if an user unplugs and replugs their cable. Other than that the ports don't flap.

Sent from Cisco Technical Support iPhone App

[Elton Babcock]

I just wanted to update everyone on the mac flapping issue that I was having a while back. I finally have it resolved and it actually had nothing related to the Cisco equipment.

This issue was related to Microsoft SCCM Wake up Proxy. See the links below to better explain what the wake up proxy is.

http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

https://supportforums.cisco.com/thread/2220560