Fout bij melding van MAC-adresflap oplossen

Downloadopties

PDF (253.5 KB)
Met Adobe Reader op diverse apparaten bekijken
ePub (81.5 KB)
Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
Mobi (Kindle) (67.0 KB)
Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken

Bijgewerkt:24 april 2025

Document-id:221140

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inhoud

Inleiding

MAC-adresflap-melding

Inleiding

In dit document wordt beschreven hoe u foutmeldingen voor MAC-adresflap kunt oplossen.

MAC-adresflap-melding

Impact

Deze berichten kunnen worden onderzocht om ervoor te zorgen dat er geen doorstuurlus bestaat.

Beschrijving

Deze melding wordt gegenereerd door de switch wanneer deze een MAC-adres flapping gebeurtenis op het netwerk detecteert.

Een MAC-adres flapping gebeurtenis wordt gedetecteerd wanneer een switch pakketten ontvangt van dezelfde bron MAC-adres in twee verschillende interfaces.

Cisco Catalyst-switches melden wanneer hetzelfde MAC-adres wordt gedetecteerd op meerdere switch-poorten, waardoor de switch voortdurend de poort wijzigt die is gekoppeld aan het MAC-adres, en waarschuwen via deze syslog die het MAC-adres bevat van de host, VLAN en poorten waartussen het MAC-adres flapt. Gezien het feit dat dit gedrag kan worden veroorzaakt door meerdere redenen, is het identificeren van de onderliggende oorzaak van MAC-adresflapping belangrijk om de stabiliteit en prestaties van het netwerk te waarborgen.

SYSLOGmessage

SW_MATM-4-MACFLAP_NOTIF

Berichtvoorbeeld

Apr 26 12:27:55 <> %SW_MATM-4-MACFLAP_NOTIF: Host mac address in vlan X is flapping between port PoX and port PoX THIS IS A SAMPLE MESSAGE

Productfamilie

Cisco Catalyst 9300 Series switches
Cisco Catalyst 9400 Series switches
Cisco Catalyst 9200 Series switches
Cisco Catalyst 9500 Series switches
Cisco Catalyst 9600 Series switches
Cisco Catalyst 3850 Series switches
Cisco Catalyst 3650 Series switches
Cisco Catalyst 6000 Series switches
Cisco Catalyst 6800 Series switches
Cisco Catalyst 4500 Series switches
Cisco Catalyst 4900 Series switches
Cisco Catalyst 3750-X Series switches
Cisco Catalyst 3850-X Series switches
Cisco Catalyst 2960 Series switches

Aanbeveling

Er zijn veel mogelijke oorzaken voor deze fout, waarvan sommige kunnen wijzen op een ernstig netwerkprobleem.

De 3 meest voorkomende worden hier in detail uitgelegd:

1. Draadloze clientbeweging (geen netwerkeffect)

2. Verplaatsing van virtuele MAC-adressen van redundante systemen of gedupliceerde virtuele machines (matige impact op het netwerk)

3. Layer-2-lussen (hoge netwerkimpact)

Details scenario 1

Draadloze clientbewegingen worden vaak verwacht en kunnen meestal veilig worden genegeerd, ervan uitgaande dat er geen serviceeffecten worden waargenomen. Cliënten die zwerven tussen toegangspunten die geen gebruik maken van CAPWAP terug naar een draadloze controller, of zwerven tussen toegangspunten die worden bestuurd door twee verschillende draadloze controllers, zullen dit logboek waarschijnlijk genereren. De tijd tussen logs die voor hetzelfde MAC-adres worden gegenereerd, kan enkele seconden of enkele minuten uit elkaar liggen. Als u ziet dat een enkel MAC-adres meerdere keren per seconde wordt verplaatst, kan dat wijzen op een ernstiger probleem en kan aanvullende probleemoplossing nodig zijn.

Details scenario 2

Sommige redundante systemen of apparaten die in een actieve/stand-bytoestand werken, kunnen een gemeenschappelijk virtueel IP- en MAC-adres delen, waarbij alleen het actieve apparaat het op elk moment gebruikt. Als beide apparaten onverwacht actief worden en beide het virtuele adres beginnen te gebruiken, kan deze fout worden gezien. Met behulp van een combinatie van de in het logboek genoemde interfaces en de opdracht show mac address-table vlan traceert u het pad van deze mac door het netwerk om te bepalen waar en welke apparaten verkeer genereren van de gedeelde mac. Afhankelijk van de aard van de apparaten die de bewegingen genereren, kan aanvullende probleemoplossing van hun redundantiestatus vereist zijn.

Details scenario 3

L2 loops genereren vaak een groot aantal mac move fouten in een zeer korte periode (minstens één per seconde, vaak meer). Logs kunnen meestal voor één of een klein aantal mac-adressen zijn en gebruikers kunnen een impact op het netwerk ervaren. Routering en laag 2-protocollen kunnen vaak mislukken, waardoor extra logs en algemene instabiliteit worden gemaakt.

Om problemen met een L2-lus op te lossen, voert u de opdracht show int | in is up|invoersnelheid uit en noteert u alle actieve interfaces die een extreem hoog volume invoerpakketten per seconde weergeven (in het algemeen kan dit een zeer groot 6, 7 of 8+ cijferig nummer zijn, afhankelijk van de snelheid van de interface).

Er zijn waarschijnlijk slechts 1 of 2 interfaces met een abnormaal hoge invoersnelheid. Richt u niet op uitvoerpercentages en concentreer u niet op overspannende TCN's. Zodra de hoge-invoerinterface is geïdentificeerd, gebruikt u CDP, LLDP of uw interfacebeschrijvingen/netwerkdiagram om u aan te melden bij het aangrenzende apparaat dat is aangesloten op die poort en voert u de opdracht show int | in is up|invoersnelheid opnieuw uit en herhaalt u het proces van het traceren van de interfaces met abnormale invoersnelheden. Houd de interfaces en hostnamen bij terwijl u ze door het netwerk traceert.

Blijf buren controleren en naar invoertarieven kijken totdat de invoerpoorten leeg zijn en u buren opraakt of weer op het apparaat terechtkomt dat u al hebt gecontroleerd.

Een van de twee mogelijke uitkomsten kan tijdens deze methode gebeuren:

Als u uiteindelijk een poort hebt die geen CDP, LLDP of bekende buur heeft, maar een zeer hoge invoersnelheid, sluit u deze administratief af. Deze interface is waarschijnlijk de ultieme bron, of is een bijdrage aan de lus. Wacht 60 seconden tot het netwerk zich stabiliseert en als er nog steeds een lusvoorwaarde wordt gezien, houdt u de interface uitgeschakeld en start u het proces opnieuw, omdat het mogelijk is dat er een tweede bron op het netwerk is.
Als u op een apparaat terechtkomt dat u al hebt gecontroleerd, geeft dit aan dat het gebruikte protocol voor luspreventie (Spanning-tree is de meest voorkomende) ergens is mislukt. Identificeer voor Spanning-Tree-netwerken welke switch in het pad dat u hebt getraceerd naar verwachting root is en werk vanaf dat apparaat achteruit om te bepalen welke interface zich in een blokkeertoestand binnen uw getraceerde pad kan bevinden. Zodra de interface is gevonden die kan worden geblokkeerd (maar zich in de staat van doorsturen bevindt), sluit u deze administratief af. Wacht 60 seconden en controleer het netwerk op stabiliteit. Als de lus blijft bestaan, blijft de interface uitgeschakeld en herhaalt u dit proces.