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.
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.
Dit document beschrijft hoe u invoerdruppels op de interface op XR-routers kunt oplossen.
Er zijn geen specifieke vereisten van toepassing op dit document.
Dit artikel behandelt ASR 9000 Series routers, CRS Series routers, en GSR 12000 Series routers.
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.
Invoerdruppels in Cisco IOS XR hebben een heel andere betekenis dan invoerdruppels in Cisco IOS. Het kan u verwarren wanneer het Cisco IOS naar Cisco IOS XR migreert en zijn inputdroptellers in de showinterface begint te zien.
In Cisco IOS was een invoerval het gevolg van de wachtrij voor de interfaceinvoer die vol wordt. Dit betekent dat te veel pakketten voor processwitching aan de CPU werden gekopieerd en dat deze niet snel genoeg kon worden verwerkt. De invoerrij wordt opgebouwd tot hij vol is en er zijn een aantal druppels.
In Cisco IOS XR is er geen strikte definitie van een invoerval. Het is dus in principe aan de ontwikkelaars van een component om te beslissen of ze de invoerdrop-teller willen verhogen wanneer ze beslissen om een pakket te laten vallen. Het belangrijkste is dat op een bepaald punt in de code, de router beslist om het pakket te laten vallen, zodat het betekent dat het waarschijnlijk is dat de router niet verondersteld was om dat pakket door te sturen, en router besloot bewust om het te laten vallen. Daarom is dit niet gerelateerd aan congestie zoals in Cisco IOS. Het is echter een pakketje dat door de router is ontvangen en dat niet had moeten worden doorgestuurd, dus de router besloot het te laten vallen en het is zeer waarschijnlijk geen reden om te worden gealarmeerd. Hoewel, kunt u niet zeggen of het iets is om je zorgen over te maken of niet totdat u volledig het soort pakketten dat de input drop teller verhogen heeft begrepen, en dat is niet zo eenvoudig.
Voorbeelden:
Wanneer de input druppels worden gerapporteerd, is het probleem te achterhalen of dit legitieme druppels zijn zoals in voorbeeld 1, of de consequentie van een probleem zoals in voorbeeld 2.
Dit document beschrijft de redenen voor de invoerdalingen die worden verhoogd en hoe te controleren als het die reden is:
Voert uit, Frame Check Sequence (FCS), aborteert, FIFO-overflow (First Input First Output), Gigabit Packet over SDH/SONET (POS) daalt.
RP/0/RP0/CPU0:equinox#show controllers poS 0/2/0/0 framer statistics POS Driver Internal Cooked Stats Values for port 0 =================================================== Rx Statistics Tx Statistics ------------- ------------- Total Bytes: 71346296 Total Bytes: 67718333 Good Bytes: 71346296 Good Bytes: 67718333 Good Packets: 105385 Good Packets: 67281 Aborts: 0 Aborts: 0 FCS Errors: 0 Min-len errors: 0 Runts: 0 Max-len errors: 0 FIFO Overflows: 0 FIFO Underruns: 0 Giants: 0 Drops: 0 RP/0/RP0/CPU0:equinox#
Voor een Ethernet (gige, tengige...) interface, controleer iets als:
toon controllers gigabitEthernet 0/0/0/18 stats
Zie of er één teller in de controllerstatus is die stappen aan de zelfde snelheid zoals de inputdaling teller in toont interface. Sommige van deze fouttellers moeten ook in de showinterface staan.
Pakketten met een MAC-adres van de bestemming, niet dat van de interface of met een Virtual Local Area Network (VLAN) dat niet wordt aangepast door een subinterface. Dit kan gebeuren als er een aantal overstromingen is in een L2-domein met onbekende unicast MAC-adressen, zodat de XR-router die is aangesloten op dat L2-domein frames ontvangt met een MAC-adres van de bestemming dat geen van de controllers is. Het is ook mogelijk wanneer een Cisco IOS router ethernetkeepalives op zijn interface verstuurt, zodat deze keepalives de invoerdruppels op de XR router verhogen omdat ze niet het doelmac-adres van de XR router hebben. Ook, wanneer de interface wordt verbonden met een ander apparaat dat meer dot1q VLAN's/subinterfaces heeft die zoals op de router XR worden gevormd zodat de router XR frames met een onbekende dot1q markering ontvangt.
Op een CRS vaste Physical Layer Interface Modules (PLIM), kon u dergelijke druppels vinden in:
RP/0/RP0/CPU0:pixies-uk#sh contr plim asic statistics interface tenGigE 0/1/0/3 location 0/1/CPU0 Wed Aug 22 16:07:47.854 CEST Node: 0/1/CPU0 TenGigE0/1/0/3 Drop ------------------------------------------------------------------------------- RxFiFO Drop : 0 PAR Tail Drop : 0 PAR Err Drop : 0 Invalid MAC Drop : 86 TxFIFO Drop : 0 Invalid VLAN Drop : 11
Of in de status van de stapel- of beeldregelaar:
RP/0/RP0/CPU0:pixies-uk#sh contr ten 0/1/0/3 stats Wed Aug 22 16:22:42.059 CEST Statistics for interface TenGigE0/1/0/3 (cached values): Ingress: Input drop overrun = 0 Input drop abort = 0 Input drop invalid VLAN = 11 Input drop invalid DMAC = 0 Input drop invalid encap = 0 Input drop other = 86
Opmerking: Cisco bug-id CSCub74803 bestaat. Input drop andere wordt verhoogd in plaats van Input drop ongeldige DMAC ten minste op de 8-poorts tengige vaste buiging van de CRS.
Voor gedeelde poortadapters (SPA’s) (CRS, XR 12000) worden de pakketten met ongeldige MAC door de SPA l2-tcam gedropt, zodat u deze druppels kunt vinden in showcontrollers TenGigE a/b/c/d alles:
Input drop other = 107 l2-tcam Invalid DA Drops: 107
Op een ASR 9000 worden de Input drop ongeldige DMAC en Input drop andere tellers in de controller status niet verhoogd. De manier om deze druppels op de ASR 9000 te herkennen is door het NP te vinden dat de interface met de invoerdruppels bedient:
RP/0/RSP0/CPU0:obama#sh int gig 0/0/0/30 | i "input drops" Wed Aug 22 16:55:52.374 CEST 1155 packets input, 156256 bytes, 1000 total input drops RP/0/RSP0/CPU0:obama#sh contr np ports all location 0/0/CPU0 Wed Aug 22 16:56:01.385 CEST Node: 0/0/CPU0: ---------------------------------------------------------------- NP Bridge Fia Ports -- ------ --- --------------------------------------------------- 0 0 0 GigabitEthernet0/0/0/30 - GigabitEthernet0/0/0/39 1 0 0 GigabitEthernet0/0/0/20 - GigabitEthernet0/0/0/29 2 1 0 GigabitEthernet0/0/0/10 - GigabitEthernet0/0/0/19 3 1 0 GigabitEthernet0/0/0/0 - GigabitEthernet0/0/0/9 RP/0/RSP0/CPU0:obama#
U kunt zien dat de interface gig 0/0/0/30 wordt behandeld door NP 0 op 0/0/CPU0.
Laten we de NP-tellers van NP0 op 0/0/CPU0 controleren:
RP/0/RSP0/CPU0:obama#sh contr np counters np0 location 0/0/CPU0 Wed Aug 22 16:56:19.883 CEST Node: 0/0/CPU0: ---------------------------------------------------------------- Show global stats counters for NP0, revision v3 Read 26 non-zero NP counters: Offset Counter FrameValue Rate (pps) ------------------------------------------------------------------------------- 22 PARSE_ENET_RECEIVE_CNT 1465 0 23 PARSE_FABRIC_RECEIVE_CNT 2793 0 24 PARSE_LOOPBACK_RECEIVE_CNT 2800 0 28 MODIFY_FABRIC_TRANSMIT_CNT 80 0 29 MODIFY_ENET_TRANSMIT_CNT 1792 0 32 RESOLVE_INGRESS_DROP_CNT 1000 0 35 MODIFY_EGRESS_DROP_CNT 1400 0 36 MODIFY_MCAST_FLD_LOOPBACK_CNT 1400 0 38 PARSE_INGRESS_PUNT_CNT 465 0 39 PARSE_EGRESS_PUNT_CNT 155 0 45 MODIFY_RPF_FAIL_DROP_CNT 1400 0 53 PARSE_LC_INJECT_TO_FAB_CNT 80 0 54 PARSE_LC_INJECT_TO_PORT_CNT 864 0 57 PARSE_FAB_INJECT_UNKN_CNT 155 0 67 RESOLVE_INGRESS_L3_PUNT_CNT 465 0 69 RESOLVE_INGRESS_L2_PUNT_CNT 464 0 70 RESOLVE_EGRESS_L3_PUNT_CNT 1400 0 93 CDP 464 0 95 ARP 1 0 109 DIAGS 154 0 221 PUNT_STATISTICS 9142 1 223 PUNT_DIAGS_RSP_ACT 155 0 225 PUNT_DIAGS_RSP_STBY 155 0 227 NETIO_RP_TO_LC_CPU_PUNT 155 0 373 L3_NOT_MYMAC 1000 0 565 INJECT_EGR_PARSE_PRRT_PIT 928 0 RP/0/RSP0/CPU0:obama#
Dus L3_NOT_MYMAC in de NP-teller betekent dat de router een frame op een Layer 3-interface heeft ontvangen met een doeladres van MAC dat geen van de interfaces is. De router laat vallen het zoals verwacht, en dit wordt gemeld als inputdalingen in showinterface.
Op de ASR 9000 voor pakketten die worden ontvangen met een dot1q VLAN dat niet is geconfigureerd op een subinterface van de ASR 9000, wordt de inputdrop met onbekende 802.1Q-teller niet verhoogd in de statistieken van de showcontrollers gigabitEthernet 0/0/0/30. De procedure is dezelfde als hierboven voor de onbekende DMAC: identificeer welke NP de interfaces verwerkt en controleer vervolgens deze NP teller. Je ziet dat de NP-teller UIDB_TCAM_MISS_AGG_DROP verhogen in dat geval.
Dat is gemakkelijk te ontdekken aangezien er een teller voor deze dalingen één lijn onder de inputdalingen in show interface is:
RP/0/RSP0/CPU0:obama#sh int gig 0/0/0/18 Wed Aug 22 17:14:35.232 CEST GigabitEthernet0/0/0/18 is up, line protocol is up 5 minute input rate 4000 bits/sec, 0 packets/sec 5 minute output rate 5000 bits/sec, 0 packets/sec 7375 packets input, 6565506 bytes, 1481 total input drops 1481 drops for unrecognized upper-level protocol
Je kunt hier zien dat alle inputdruppels te wijten waren aan een niet herkend protocol op het hoogste niveau.
Dat betekent dat de pakketten met een protocol werden ontvangen Ethernet dat de router niet in geinteresseerd is. Dat betekent dat een functie is geconfigureerd op de buur (of op een host die is aangesloten op de Layer 2-domein die is aangesloten op die interface), zodat er frames worden verzonden met een protocol dat niet is geconfigureerd op de XR-router.
Voorbeelden: BPDU’s, Intermediate System to Intermediate System (ISIS), Connection Less Network Protocol (CLNP), IPv6, UDLD, Cisco Discovery Protocol (CDP), VLAN-trunkingprotocol (VTP), Dynamic Trunking Protocol (DTP), Link Layer Discovery Protocol (LLDP) enzovoort....
Wanneer deze eigenschappen niet op de interface XR worden gevormd, dan laat vallen de doos XR hen zoals verwacht. Om te weten te komen wat voor soort frames deze teller verhogen, kunt u moeten vergelijken welke functies zijn ingeschakeld op de XR router met de functies die zijn ingeschakeld op de buurman (het kan een switch of een router zijn), of de functies die zijn ingeschakeld op alle apparaten die zijn aangesloten op de Layer 2 domeinen die zijn aangesloten op die interface (veel minder gemakkelijk). Als de XR router is aangesloten op een switch, kunt u een reeks proberen op die switch van de pakketten die naar de XR router worden verzonden op de interface met invoerdruppels.
ASR 9000/XR: meldingen voor niet-herkende protocolfout op bovenniveau
Droptellers in het Netwerkproces (NP) van de ASR 9000 worden als invoerdruppels gemeld wanneer ze van toepassing zijn op een pakket dat op een interface wordt ontvangen en wordt gedropt. Dit gebeurt niet voor de Packet Switch Engine (PSE)-druppels op het CRS en de XR-12000. Ze worden niet geteld als invoerdruppels.
Dus als je invoerdalingen hebt op een ASR 9000 en ze komen niet overeen met een van deze redenen, dan zou je een show controllers np poorten alle locatie 0/<x>/CPU0 doen om de NP te vinden die de interface met invoerdalingen behandelt en dan zijn NP-tellers controleren met show contr np-tellers np<y> locatie 0/<x>/CPU0.
U kunt de uitvoer naar alleen DROP-tellers sturen met een opdracht zoals sh-contr-np-tellers np<y> locatie 0/<x>/CPU0 | i DROP, maar dit kan gevaarlijk zijn omdat een drop teller niet heeft DROP in zijn naam. Je hebt een goed voorbeeld gezien met L3_NOT_MYMAC. Dus misschien is er een pijp voor DROP|DISCARD|NOT|EXCD.
U kunt de interfacetellers en de NP-tellers met duidelijke controller np-tellers np<y>-locatie 0/<x>/CPU0 tegelijkertijd wissen om erachter te komen welke NP-tellers met hetzelfde tempo als de invoer worden verhoogd.
Je krijgt bijvoorbeeld IPV4_PLU_DROP_PKT in de NP tellers wat betekent dat de CEF/PLU vermelding zegt dat het pakket moet worden gedropt. U hebt geen standaardroute en onbereikbare uitgeschakelde pakketten die niet overeenkomen met een specifiekere route, waar het raken van de standaard CEF-handler, een drop-ingang is.
Als u een drop teller in het NP vindt die de input kan verklaren daalt aangezien zij aan het zelfde tarief verhogen, maar de NP drop teller is niet zeer duidelijk, kunt u deze pagina navigeren om te proberen te begrijpen wat de teller betekent:
ASR 9000/XR: probleemoplossing voor pakketdruppels en inzicht in NP-droptellers
Opmerking: Xander's pagina op ondersteuningsfora bevat de redenen voor de daling van de eerste generatie linecards (Trident), en er zijn nieuwe tellers voor de nieuwe generatie (Tyfoon) linecards. Op basis van de naam moet je in staat zijn om een soortgelijke tegennaam te vinden als op Trident.
U kunt een show netio idb <int> verzamelen en dit geeft u de interface-ingang en de netio knooppunt drop-tellers:
RP/0/RP0/CPU0:ipc-lsp690-r-ca-01#show netio idb gigabitEthernet 0/2/0/1
GigabitEthernet0/2/0/1 (handle: 0x01280040, nodeid:0x21) netio idb:
---------------------------------
name: GigabitEthernet0_2_0_1
interface handle: 0x01280040
interface global index: 3
physical media type: 30
dchain ptr: <0x482e0700>
echain ptr: <0x482e1024>
fchain ptr: <0x482e13ec>
driver cookie: <0x4829fc6c>
driver func: <0x4829f040>
number of subinterfaces: 4096
subblock array size: 7
DSNCNF: 0x00000000
interface stats info:
IN unknown proto pkts: 0
IN unknown proto bytes: 0
IN multicast pkts: 0
OUT multicast pkts: 0
IN broadcast pkts: 0
OUT broadcast pkts: 0
IN drop pkts: 0 <=========== cleared when added to input drop counter !!!
OUT drop pkts: 0
IN errors pkts: 0
OUT errors pkts: 0
Chains
--------------------
Base decap chain:
ether <30> <0xfd018cd8, 0x482c736c> < 0, 0>
Protocol chains:
---------------
<Protocol number> (name) Stats
Type Chain_node <caps num> <function, context> <drop pkts, drop bytes>
<snip>
<13> (mpls) Stats IN: 204 pkts, 23256 bytes; OUT: 0 pkts, 0 bytes
Encap:
mpls <25> <0xfcc7ddbc, 0x00000000> < 0, 0>
ether <30> <0xfd0189b4, 0x482c736c> < 0, 0>
l2_adj_rewrite <86> <0xfcaa997c, 0x4831a2e8> < 0, 0>
pcn_output <54> <0xfd0561f0, 0x48319f04> < 0, 0>
q_fq <43> <0xfd05f4b8, 0x48320fec> < 0, 0>
txm_nopull <60> <0xfcadba38, 0x4824c0fc> < 0, 0>
Decap:
pcn_input <55> <0xfd0561f0, 0x4830ba8c> < 0, 0>
q_fq_input <96> <0xfd05f330, 0x48312c7c> < 0, 0>
mpls <25> <0xfcc7b2b8, 0x00000000> < 152, 17328>
Fixup:
l2_adj_rewrite <86> <0xfcaa945c, 0x00000000> < 0, 0>
pcn_output <54> <0xfd0561f0, 0x48319f04> < 0, 0>
q_fq <43> <0xfd05f4b8, 0x48320fec> < 0, 0>
txm_nopull <60> <0xfcadba38, 0x4824c0fc> < 0, 0>
De druppels in de Multi-Protocol Label Switching (MPLS) knooppunt hier kunnen het gevolg zijn van MPLS Time To Live (TTL) verlopen (in het geval van een lus of wanneer de klant een traceroute doet), of fragmentatie vereist en Do Not Fragment (DF) bit set bijvoorbeeld. U kunt debug mpls-pakketdrop uitvoeren en mpls-fout met de locatie van de interface zuiveren om te proberen erachter te komen welk soort pakket deze teller verhoogt.
Punted multicast-pakketten. Als je netio IN drop-pkts ziet maar geen netio-knoop hieronder met wat druppels die de IN drop-pkts zouden kunnen verklaren, dan kan dit worden gegoten gepunte pakketten, en je kunt debmfib netio drop inschakelen om uit te zoeken wat voor soort pakketten
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
12-Jul-2023 |
Bijgewerkte Titel, Inleiding, Branding Vereisten, Machinevertaling, Stijl Vereisten, Grafiek en het Formatteren. |
1.0 |
04-Jan-2019 |
Eerste vrijgave |