Inzicht in fouten in cyclische redundantiecontrole op Nexus-switches
Inhoud
Inleiding
Dit document beschrijft fouten die zijn waargenomen bij cyclische redundantiecontrole (CRC) op interfacetellers en statistische gegevens van Cisco Nexus-switches.
Voorwaarden
Vereisten
Cisco raadt basiskennis aan van Ethernet-switching en de opdrachtregelinterface (CLI) van Cisco NX-OS. Raadpleeg een van de volgende documenten voor meer informatie:
- Cisco Nexus 9000 – Configuratiehandleiding voor basiselementen van NX-OS, release 10.2(x)
- Cisco Nexus 9000 Series – Configuratiehandleiding voor basiselementen van NX-OS, release 9.3(x)
- Cisco Nexus 9000 Series – Configuratiehandleiding voor basiselementen van NX-OS, release 9.2(x)
- Cisco Nexus 9000 Series – Configuratiehandleiding voor basiselementen van NX-OS, release 7.x
Gebruikte componenten
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
- Nexus 9000 Series switches die beginnen met NX-OS softwarerelease 9.3(8)
- Nexus 3000 Series switches die beginnen met NX-OS softwarerelease 9.3(8)
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Achtergrondinformatie
Dit document beschrijft informatie over fouten die zijn waargenomen bij cyclische redundantiecontrole (CRC) op interfacetellers op switches uit de Cisco Nexus-serie. Dit document beschrijft wat een CRC is, hoe het op het veld Frame Check Sequence (FCS) van Ethernet-frames wordt gebruikt, hoe CRC-fouten zich op Nexus-switches manifesteren en hoe CRC-fouten bij Store-and-Forwarding-switching interageren. Dit artikel beschrijft ook Cut-Through-switchscenario's, de meest waarschijnlijke grondoorzaken van CRC-fouten, en hoe CRC-fouten op te lossen en op te lossen.
Toepasselijke hardware
De informatie in dit document is van toepassing op alle Cisco Nexus Series switches. Een deel van de informatie in dit document kan ook van toepassing zijn op andere routing- en switchingplatforms van Cisco, zoals Cisco Catalyst-routers en -switches.
Definitie van CRC
Een CRC is een foutdetectiemechanisme dat vaak wordt gebruikt in computer- en opslagnetwerken om data te identificeren die tijdens de overdracht is gewijzigd of beschadigd. Wanneer een apparaat dat is aangesloten op het netwerk data moet verzenden, voert het apparaat een rekenalgoritme (gebaseerd op cyclische codes) uit op de data. Dit resulteert in een getal met vaste lengte. Dit getal met vaste lengte wordt de CRC-waarde genoemd, of CRC. Deze CRC-waarde wordt aan de data toegevoegd en via het netwerk naar een ander apparaat verzonden. Dit apparaat op afstand voert hetzelfde cyclische coderingsalgoritme uit tegen de gegevens en vergelijkt de waarde die resulteert met de aan de gegevens toegevoegde CRC. Als beide waarden overeenkomen, dan gaat het apparaat op afstand ervan uit dat de gegevens zonder beschadiging over het netwerk zijn verzonden. Als de waarden niet overeenkomen, dan veronderstelt het externe apparaat dat de gegevens in de transmissie over het netwerk zijn beschadigd. De beschadigde data kan niet worden vertrouwd en wordt genegeerd.
CRC’s worden gebruikt voor foutdetectie via meerdere computernetwerktechnologieën, zoals Ethernet (zowel bekabelde als wireless varianten), Token Ring, asynchronous transfer mode (ATM) en Frame Relay. Ethernet-frames hebben een 32-bits Frame Check Sequence (FCS) veld aan het einde van het frame (onmiddellijk na de payload van het frame) waar een 32-bits CRC-waarde is ingevoegd.
Neem als voorbeeld een scenario waar twee hosts, Host-A en Host-B, rechtstreeks met elkaar verbonden zijn via hun netwerkinterfacekaarten (NIC’s). Host-A moet de zin ‘Dit is een voorbeeld’ via het netwerk naar Host-B verzenden. Host-A creëert een Ethernet-frame bestemd voor Host-B met de payload ‘Dit is een voorbeeld’ en berekent dat de CRC-waarde van het frame de hexadecimale waarde 0xABCD is. Host-A voegt de CRC-waarde van 0xABCD in het FCS-veld van het Ethernet-frame in en stuurt vervolgens het Ethernet-frame vanuit Host-A NIC naar Host-B.
Wanneer host-B dit frame ontvangt, kan het de CRC-waarde van het frame berekenen met het gebruik van exact hetzelfde algoritme als host-A. Host-B berekent dat de CRC-waarde van het frame de hexadecimale waarde 0xABCD is, wat aangeeft dat het Ethernet-frame niet beschadigd was toen het frame naar Host-B werd verzonden.
Definitie van CRC-fout
Een CRC-fout treedt op wanneer een apparaat (een netwerkapparaat of een host die met het netwerk is verbonden) een Ethernet-frame met een CRC-waarde in het FCS-veld van het frame ontvangt dat niet overeenkomt met de CRC-waarde die door het apparaat voor het frame is berekend.
Dit concept kan het best worden gedemonstreerd aan de hand van een voorbeeld. Neem als voorbeeld een scenario waar twee hosts, Host-A en Host-B, rechtstreeks met elkaar verbonden zijn via hun netwerkinterfacekaarten (NIC’s). Host-A moet de zin ‘Dit is een voorbeeld’ via het netwerk naar Host-B verzenden. Host-A creëert een Ethernet-frame bestemd voor Host-B met de payload ‘Dit is een voorbeeld’ en berekent dat de CRC-waarde van het frame de hexadecimale waarde 0xABCD is. Host-A voegt de CRC-waarde van 0xABCD in het FCS-veld van het Ethernet-frame in en stuurt vervolgens het Ethernet-frame vanuit Host-A NIC naar Host-B.
Schade aan de fysieke media die Host-A verbindt met Host-B beschadigt echter de inhoud van het frame zodanig dat de zin in het frame verandert in ‘Dit was een voorbeeld’ in plaats van de gewenste payload ‘Dit is een voorbeeld’.
Wanneer host-B dit frame ontvangt, kan het de CRC-waarde van het frame berekenen en de beschadigde payload in de berekening opnemen. Host-B berekent dat de CRC-waarde van het frame de hexadecimale waarde 0xDEAD is, die verschilt van de CRC-waarde 0xABCD in het FCS-veld van het Ethernet-frame. Dit verschil in CRC-waarden geeft bij Host-B aan dat het Ethernet-frame beschadigd was toen het frame werd verzonden naar Host-B. Dientengevolge, kan Host-B niet op de inhoud van dit Ethernet-frame vertrouwen, zodat het kan vallen. Host-B kan meestal een soort foutenteller verhogen op de netwerkinterfacekaart (NIC), zoals de "invoerfouten", "CRC-fouten" of "RX-fouten" tellers.
Veelvoorkomende symptomen van CRC-fouten
CRC-fouten manifesteren zich doorgaans op twee manieren:
- Oplopende of niet-nulzijnde foutentellers op interfaces van met het netwerk verbonden apparaten.
- Packet-/frameverlies voor verkeer dat het netwerk oversteekt vanwege op het netwerk aangesloten apparaten die beschadigde frames neerzetten.
Deze fouten manifesteren zich op enigszins verschillende manieren afhankelijk van het apparaat waarmee u op dat moment werkt. Dit wordt in de volgende subsecties gedetailleerd voor elk type apparaat beschreven.
Teller Received op Windows-hosts
CRC-fouten op Windows-hosts manifesteren zich doorgaans als een niet-nulzijnde foutenteller Received die wordt getoond in de output van de opdracht netstat -e na de opdrachtprompt. Hieronder volgt een voorbeeld van een niet-nulzijnde teller Received na de opdrachtprompt van een Windows-host:
>netstat -e
Interface Statistics
Received Sent
Bytes 1116139893 3374201234
Unicast packets 101276400 49751195
Non-unicast packets 0 0
Discards 0 0
Errors 47294 0
Unknown protocols 0
De NIC en het bijbehorende stuurprogramma moeten verantwoording van CRC-fouten die door de NIC worden ontvangen ondersteunen, zodat het aantal ontvangen fouten dat via de opdracht netstat -e wordt gemeld nauwkeurig is. De meeste moderne NIC’s en hun bijbehorende stuurprogramma’s ondersteunen nauwkeurige verantwoording van CRC-fouten die door de NIC worden ontvangen.
Teller RX errors op Linux-hosts
CRC-fouten op Linux-hosts manifesteren zich doorgaans als een niet-nulzijnde teller RX errors die wordt getoond in de output van de opdracht ifconfig. Hieronder volgt een voorbeeld van een niet-nulzijnde teller RX errors van een Linux-host:
$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.0.2.10 netmask 255.255.255.128 broadcast 192.0.2.255
inet6 fe80::10 prefixlen 64 scopeid 0x20<link>
ether 08:62:66:be:48:9b txqueuelen 1000 (Ethernet)
RX packets 591511682 bytes 214790684016 (200.0 GiB)
RX errors 478920 dropped 0 overruns 0 frame 0
TX packets 85495109 bytes 288004112030 (268.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
CRC-fouten op Linux-hosts kunnen zich ook manifesteren als een niet-nulzijnde teller RX errors die wordt getoond in de output van de opdracht ip -s link show. Hieronder volgt een voorbeeld van een niet-nulzijnde teller RX errors van een Linux-host:
$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 08:62:66:84:8f:6d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
32246366102 444908978 478920 647 0 419445867
TX: bytes packets errors dropped carrier collsns
3352693923 30185715 0 0 0 0
altname enp11s0
De NIC en het bijbehorende stuurprogramma moeten verantwoording van CRC-fouten die door de NIC worden ontvangen ondersteunen, zodat het aantal RX-fouten dat via de opdracht ifconfig of ip -s link show wordt gemeld nauwkeurig is. De meeste moderne NIC’s en hun bijbehorende stuurprogramma’s ondersteunen nauwkeurige verantwoording van CRC-fouten die door de NIC worden ontvangen.
CRC-fouten op netwerkapparaten
Netwerkapparaten werken in een van de volgende twee verzendmodi:
- Store-and-Forwarding-modus
- Doorgesneden doorsturen in modus
De manier waarop een netwerkapparaat een ontvangen CRC-fout verwerkt, verschilt afhankelijk van de wijze van doorsturen. In de subsecties wordt het specifieke gedrag voor elke doorstuurmodus beschreven.
Teller input error op netwerkapparaten in de modus Store-and-Forward
Wanneer een netwerkapparaat dat in een Store-and-Forwarding-modus werkt een frame ontvangt, kan het netwerkapparaat het gehele frame bufferen ("Store") voordat u de CRC-waarde van het frame valideert, een doorsturen besluit over het frame neemt en het frame vanuit een interface ("Forward") overbrengt. Daarom wanneer een netwerkapparaat dat in een Store-and-Forward het door:sturen wijze werkt een beschadigd kader met een onjuiste CRC waarde op een specifieke interface ontvangt, kan het het kader laten vallen en de teller van de "Invoerfouten"op de interface verhogen.
Met andere woorden: beschadigde Ethernet-frames worden niet doorgestuurd door netwerkapparaten in de doorstuurmodus Store-and-Forward maar bij inkomst afgewezen.
Cisco Nexus 7000 en 7700 Series switches werken in de doorstuurmodus Store-and-Forward. Hieronder volgt een voorbeeld van een niet-nulzijnde teller input error en een niet-nulzijnde teller CRC/FCS van een Nexus 7000 of 7700 Series switch:
switch# show interface
<snip>
Ethernet1/1 is up
RX
241052345 unicast packets 5236252 multicast packets 5 broadcast packets
245794858 input packets 17901276787 bytes
0 jumbo packets 0 storm suppression packets
0 runts 0 giants 579204 CRC/FCS 0 no buffer
579204 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
CRC-fouten kunnen zich ook manifesteren als een niet-nulzijnde teller FCS-Err in de output van de opdracht show interface counters errors. De "Rcv-Err" teller in de uitvoer van deze opdracht kan ook een waarde anders dan nul hebben, wat de som is van alle invoerfouten (CRC of anderszins) die door de interface worden ontvangen. Hieronder volgt een voorbeeld hiervan:
switch# show interface counters errors
<snip>
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth1/1 0 579204 0 579204 0 0
Tellers input error en output error op netwerkapparaten in de modus Cut-Through
Wanneer een netwerkapparaat dat in een besnoeiing-Door het door:sturen wijze werkt begint een kader te ontvangen, kan het netwerkapparaat een het door:sturen besluit over de kaderkopbal nemen en beginnen het kader uit een interface over te brengen zodra het genoeg van het kader ontvangt om een geldig het door:sturen besluit te maken. Aangezien frame- en pakketheaders aan het begin van het frame staan, wordt deze doorstuurbeslissing doorgaans genomen voordat de payload van het frame wordt ontvangen.
Het FCS-veld van een Ethernet-frame staat aan het einde van het frame, direct na de payload van het frame. Daarom kan een netwerkapparaat dat in een Cut-Through het door:sturen wijze werkt reeds zijn begonnen het kader uit een andere interface te verzenden tegen de tijd dat het CRC van het kader kan berekenen. Als de CRC-waarde die door het netwerkapparaat voor het frame wordt berekend niet overeenkomt met de CRC-waarde in het FCS-veld, betekent dit dat het netwerkapparaat een beschadigt frame heeft doorgestuurd naar het netwerk. Wanneer dit gebeurt, kan het netwerkapparaat twee tellers verhogen:
- De teller input error op de interface waar het beschadigde frame oorspronkelijk werd ontvangen.
- De teller output error op alle interfaces vanaf waar het beschadigde frame werd verzonden. Voor unicastverkeer kan dit doorgaans één interface zijn - voor broadcast, multicast of onbekend unicastverkeer kan dit echter een of meer interfaces zijn.
Hieronder volgt een voorbeeld hiervan. Hierin blijkt uit de output van de opdracht show interface dat er meerdere beschadigde frames zijn ontvangen op Ethernet1/1 van het netwerkapparaat en verzonden vanaf Ethernet1/2 als gevolg van de doorstuurmodus Cut-Through van het netwerkapparaat:
switch# show interface
<snip>
Ethernet1/1 is up
RX
46739903 unicast packets 29596632 multicast packets 0 broadcast packets
76336535 input packets 6743810714 bytes
15 jumbo packets 0 storm suppression bytes
0 runts 0 giants 47294 CRC 0 no buffer
47294 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
Ethernet1/2 is up
TX
46091721 unicast packets 2852390 multicast packets 102619 broadcast packets
49046730 output packets 3859955290 bytes
50230 jumbo packets
47294 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause
CRC-fouten kunnen zich ook manifesteren als een niet-nulzijnde teller FCS-Err op de inkomende interface en een niet-nulzijnde teller Xmit-Err op uitgaande interfaces in de output van de opdracht show interface counters errors. De "Rcv-Err" teller op de ingangsinterface in de uitvoer van deze opdracht kan ook een niet-nulwaarde hebben, die de som is van alle invoerfouten (CRC of anderszins) die door de interface worden ontvangen. Hieronder volgt een voorbeeld hiervan:
switch# show interface counters errors
<snip>
--------------------------------------------------------------------------------
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
--------------------------------------------------------------------------------
Eth1/1 0 47294 0 47294 0 0
Eth1/2 0 0 47294 0 0 0
Het netwerkapparaat kan ook de CRC-waarde in het FCS-veld van het frame op een specifieke manier wijzigen, die aangeeft dat dit frame beschadigd is. Dit gedrag staat bekend als ‘stomping’ van de CRC. De precieze manier waarop de CRC wordt aangepast, varieert van platform tot platform, maar over het algemeen berekent het de CRC-waarde van het beschadigde frame, keert dan die waarde om en neemt het op in het FCS-veld van het frame. Hier is een voorbeeld van:
Original Frame's CRC: 0xABCD (1010101111001101)
Corrupted Frame's CRC: 0xDEAD (1101111010101101)
Corrupted Frame's Stomped CRC: 0x2152 (0010000101010010)
Als resultaat van dit gedrag kunnen netwerkapparaten in de doorstuurmodus Cut-Through een beschadigd frame op een netwerk verspreiden. Als een netwerk bestaat uit meerdere netwerkapparaten in de doorstuurmodus Cut-Through, kan één beschadigd frame ervoor zorgen dat de tellers input error en output error op meerdere netwerkapparaten binnen uw netwerk worden opgehoogd.
CRC-fouten traceren en isoleren
De eerste stap om de basisoorzaak van CRC-fouten te identificeren en op te lossen is om de bron van de CRC-fouten te isoleren naar een specifiek verband tussen twee apparaten binnen uw netwerk. Eén apparaat dat aangesloten is op deze link kan een interface output error counter hebben met een waarde nul of groeit niet, terwijl het andere apparaat dat aangesloten is op deze link een niet-nul of stijgende interface input error counter kan hebben. Dit suggereert dat het verkeer de interface van een apparaat intact verlaat wordt beschadigd op het moment van de transmissie naar het apparaat op afstand en wordt geteld als een invoerfout door de toegangsinterface van het andere apparaat op de link.
Deze link identificeren in een netwerk dat bestaat uit netwerkapparaten die werken in een Store-and-Forwarding modus is een eenvoudige taak. Als u deze link echter identificeert in een netwerk dat bestaat uit netwerkapparaten die werken in een doorgesneden doorsturen modus is moeilijker, omdat veel netwerkapparaten niet-nul input en output fouttellers kunnen hebben. Een voorbeeld van dit fenomeen kan in de topologie hier worden gezien, waar de verbinding die in rood wordt benadrukt zodanig wordt beschadigd dat het verkeer de verbinding doorkruist wordt bedorven. Interfaces met een in rood aangegeven ‘I’ zijn interfaces die een niet-nulzijnde teller input error kunnen hebben; interfaces met een in blauw aangegeven ‘O’ zijn interfaces die een niet-nulzijnde teller output error kunnen hebben.
Dit document beschrijft fouten die zijn waargenomen bij cyclische redundantiecontrole (CRC) op interfacetellers en statistische gegevens van Cisco Nexus-switches.
Een gedetailleerd proces om een beschadigde link te traceren en te identificeren kan het best worden gedemonstreerd door middel van een voorbeeld. Bekijk deze topologie:
In deze topologie is interface Ethernet1/1 van Nexus-switch Switch-1 verbonden met host Host-1 via NIC eth0 van Host-1. Interface Ethernet1/2 van Nexus-switch Switch-1 is verbonden met een tweede Nexus-switch, Switch-2, via interface Ethernet1/2 van Switch-2. Interface Ethernet1/1 van Switch-2 wordt aangesloten op een host met de naam Host-2 via Host-2 NIC eth0.
De koppeling tussen host-1 en Switch-1 via de Ethernet1/1-interface van Switch-1 is beschadigd en veroorzaakt dat verkeer dat de link doorkruist met tussenpozen wordt beschadigd. Of de link beschadigd is, is op dit moment echter onbekend. U moet het pad overtrekken dat de beschadigde frames in het netwerk achterlaten door niet-nul of verhoogde input en output fouttellers om de beschadigde link in dit netwerk te vinden.
In dit voorbeeld meldt Host-2 NIC dat het CRC-fouten ontvangt.
Host-2$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:84:8f:6d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
32246366102 444908978 478920 647 0 419445867
TX: bytes packets errors dropped carrier collsns
3352693923 30185715 0 0 0 0
altname enp11s0
U weet dat Host-2 NIC verbinding maakt met Switch-2 via interface Ethernet1/1. U kunt controleren of interface Ethernet1/1 een niet-nulzijnde teller output error heeft met de opdracht show interface.
Switch-2# show interface
<snip>
Ethernet1/1 is up
admin state is up, Dedicated Interface
RX
30184570 unicast packets 872 multicast packets 273 broadcast packets
30185715 input packets 3352693923 bytes
0 jumbo packets 0 storm suppression bytes
0 runts 0 giants 0 CRC 0 no buffer
0 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
TX
444907944 unicast packets 932 multicast packets 102 broadcast packets
444908978 output packets 32246366102 bytes
0 jumbo packets
478920 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause
Aangezien de teller output error van interface Ethernet1/1 niet-nul is, is er zeer waarschijnlijk een andere interface van Switch-2 met een niet-nulzijnde teller input error. U kunt de opdracht show interface counters errors non-zero gebruiken om na te gaan of er interfaces zijn van Switch-2 met een niet-nulzijnde teller input error.
Switch-2# show interface counters errors non-zero <snip> -------------------------------------------------------------------------------- Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards -------------------------------------------------------------------------------- Eth1/1 0 0 478920 0 0 0 Eth1/2 0 478920 0 478920 0 0 -------------------------------------------------------------------------------- Port Single-Col Multi-Col Late-Col Exces-Col Carri-Sen Runts -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port InDiscards --------------------------------------------------------------------------------
U kunt zien dat interface Ethernet1/2 van Switch-2 een niet-nulzijnde teller input error heeft. Dit duidt erop dat Switch-2 beschadigd verkeer op deze interface ontvangt. U kunt bevestigen welk apparaat is verbonden met interface Ethernet1/2 van Switch-2 via de functie Cisco Discovery Protocol (CDP) of Link Local Discovery Protocol (LLDP). Hieronder volgt een voorbeeld hiervan, met de opdracht show cdp neighbors.
Switch-2# show cdp neighbors
<snip>
Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge
S - Switch, H - Host, I - IGMP, r - Repeater,
V - VoIP-Phone, D - Remotely-Managed-Device,
s - Supports-STP-Dispute
Device-ID Local Intrfce Hldtme Capability Platform Port ID
Switch-1(FDO12345678)
Eth1/2 125 R S I s N9K-C93180YC- Eth1/2
U weet nu dat Switch-2 beschadigd verkeer ontvangt op zijn Ethernet1/2-interface van Switch-1's Ethernet1/2-interface, maar u weet nog niet of het verband tussen Switch-1's Ethernet1/2 en Switch-2's Ethernet1/2 beschadigd is en de corruptie veroorzaakt, of als Switch-1 een doorgesneden switch is die beschadigd verkeer doorstuurt dat het ontvangt. U moet inloggen bij Switch-1 om dit te verifiëren.
U kunt controleren of interface Ethernet1/2 van Switch-1 een niet-nulzijnde teller output error heeft met de opdracht show interfaces.
Switch-1# show interface
<snip>
Ethernet1/2 is up
admin state is up, Dedicated Interface
RX
30581666 unicast packets 178 multicast packets 931 broadcast packets
30582775 input packets 3352693923 bytes
0 jumbo packets 0 storm suppression bytes
0 runts 0 giants 0 CRC 0 no buffer
0 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
TX
454301132 unicast packets 734 multicast packets 72 broadcast packets
454301938 output packets 32246366102 bytes
0 jumbo packets
478920 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause
U kunt zien dat interface Ethernet1/2 van Switch-1 een niet-nulzijnde teller output error heeft. Dit suggereert dat het verband tussen Switch-1's Ethernet1/2 en Switch-2's Ethernet1/2 niet beschadigd is; in plaats daarvan is Switch-1 een doorgesneden switch die corrupt verkeer doorstuurt dat het op een andere interface ontvangt. Zoals eerder aangetoond met Switch-2, kunt u de opdracht gebruikenshow interface counters errors non-zeroom te bepalen of interfaces van Switch-1 een niet-nulinvoerfoutenteller hebben.
Switch-1# show interface counters errors non-zero <snip> -------------------------------------------------------------------------------- Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards -------------------------------------------------------------------------------- Eth1/1 0 478920 0 478920 0 0 Eth1/2 0 0 478920 0 0 0 -------------------------------------------------------------------------------- Port Single-Col Multi-Col Late-Col Exces-Col Carri-Sen Runts -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port Giants SQETest-Err Deferred-Tx IntMacTx-Er IntMacRx-Er Symbol-Err -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Port InDiscards --------------------------------------------------------------------------------
U kunt zien dat interface Ethernet1/1 van Switch-1 een niet-nulzijnde teller input error heeft. Dit duidt erop dat Switch-1 beschadigd verkeer op deze interface ontvangt. U weet dat deze interface verbinding maakt met de eth0 NIC van Host-1. U kunt de interfacestatistieken voor de eth0-NIC van Host-1 bekijken om te bevestigen of Host-1 beschadigde frames naar deze interface stuurt.
Host-1$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:84:8f:6d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
73146816142 423112898 0 0 0 437368817
TX: bytes packets errors dropped carrier collsns
3312398924 37942624 0 0 0 0
altname enp11s0
De eth0 NIC-statistieken van Host-1 wijzen erop dat de host geen beschadigd verkeer verzendt. Dit duidt erop dat de link tussen NIC eth0 van Host-1 en interface Ethernet1/1 van Switch-1 defect is en de bron vormt van beschadiging van het verkeer. U moet deze link oplossen om de defecte component die deze corruptie veroorzaakt te identificeren en te vervangen.
Hoofdoorzaken van CRC-fouten
De vaakst voorkomende hoofdoorzaak van CRC-fouten is een beschadigde of defecte component van een fysieke link tussen twee apparaten. Voorbeelden zijn:
- Defect of beschadigd fysiek medium (koper of vezel) of kabels voor directe koppeling (DAC’s).
- Defecte of beschadigde transceivers/optics.
- Defecte of beschadigde patchpaneelpoorten.
- Defecte netwerkapparaathardware (dit omvat specifieke poorten, lijnkaart, toepassingsspecifieke geïntegreerde circuits [ASIC’s], mediatatoegangscontroles [MAC’s], fabricmodules, enzovoort).
- Defecte netwerkinterfacekaart die in een host is geplaatst.
Het is ook mogelijk dat een of meer onjuist geconfigureerde apparaten onbedoeld CRC-fouten veroorzaken binnen een netwerk. Een voorbeeld hiervan is een Maximum Transmission Unit (MTU) configuratie mismatch tussen twee of meer apparaten binnen het netwerk die veroorzaakt dat grote pakketten onjuist worden ingekort. Wanneer u deze configuratiekwestie identificeert en oplost kan het CRC fouten binnen een netwerk eveneens verbeteren.
CRC-fouten oplossen
U kunt de specifieke defecte component identificeren via eliminatie:
- Vervang het fysieke medium (koper of vezel) of de DAC door een fysiek medium van hetzelfde type waarvan bekend is dat het goed werkt.
- Vervang de transceiver in één apparateninterface met een bekende-goede transceiver van het zelfde model wordt opgenomen dat. Als dit niet de CRC fouten oplost, vervang de transceiver in de andere apparateninterface met een bekende-goede transceiver van het zelfde model wordt opgenomen die.
- Als er patchpanelen worden gebruikt als onderdeel van de defecte link, verplaatst u de link naar een poort op het patchpaneel waarvan bekend is dat deze goed werkt. U kunt ook het patchpaneel als mogelijke oorzaak elimineren door de koppeling indien mogelijk zonder het patchpaneel aan te sluiten.
- Verplaats de defecte link naar een andere poort op elk apparaat waarvan bekend is dat deze goed werkt. U kunt meerdere verschillende poorten moeten testen om een MAC-, ASIC- of lijnkaartfout te isoleren.
- Als de defecte link een host betreft, verplaats de link dan naar een andere NIC op de host. U kunt de beschadigde link ook aansluiten op een bekende goede host om een storing van de host-NIC te isoleren.
Als de defecte component een Cisco-product is (zoals een Cisco-netwerkapparaat of een transceiver) dat wordt gedekt door een actief ondersteuningscontract, kunt u een ondersteuningscase met Cisco TAC openen, uw probleemdetails opnemen en de defecte component laten vervangen door een RMA (Return Material Authorisation).
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
3.0 |
10-Nov-2021 |
Verbeter de minder belangrijke opmaak van het document |
2.0 |
10-Nov-2021 |
Eerste vrijgave |
1.0 |
10-Nov-2021 |
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)