ICMP-omleidingsberichten begrijpen
Inhoud
Inleiding
Dit document beschrijft de functionaliteit voor ICMP-pakketomleiding (Internet Control Message Protocol).
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
- Nexus 7000 platform architectuur
- Cisco NX-OS-softwareconfiguratie
- Internet Control Message Protocol, zoals gedocumenteerd in Verzoek om Opmerkingen (RFC) 792
Gebruikte componenten
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
- Nexus 7000 switch
- Cisco NX-OS-software
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 bespreekt de functionaliteit voor pakketomleiding die wordt geboden door Internet Control Message Protocol (ICMP). Het document legt uit welke aanwezigheid van ICMP-omleidingsberichten in het netwerk gewoonlijk aangeeft en wat kan worden gedaan om negatieve neveneffecten te minimaliseren die zijn gekoppeld aan netwerkomstandigheden die het genereren van ICMP-omleidingsberichten veroorzaken.
ICMP-omleidingsberichten
De functionaliteit van ICMP-omleiding wordt met dit voorbeeld uitgelegd in RFC 792 Internet Control Message Protocol:
De gateway stuurt een omleidingsbericht naar een host in deze situatie.
Een gateway, G1, ontvangt een datagram van Internet van een gastheer op een netwerk waaraan de gateway in bijlage is. De gateway, G1, controleert zijn routeringstabel en verkrijgt het adres van de volgende gateway, G2, op de route aan het datagram Internet bestemmingsnetwerk, X
Als G2 en de host die wordt geïdentificeerd door het internetbronadres van het datagram zich op hetzelfde netwerk bevinden, wordt er een omleidingsbericht naar de host verzonden. Het omleiden bericht adviseert de host om zijn verkeer voor netwerk X rechtstreeks naar gateway G2 te verzenden aangezien dit een kortere weg naar de bestemming is.
De gateway verstuurt de oorspronkelijke datagramgegevens naar zijn internetbestemming.
Dit scenario wordt getoond in Afbeelding 1. De host en twee routers, G1 en G2, zijn verbonden met een gedeeld Ethernet-segment en hebben IP-adressen in hetzelfde netwerk 10.0.0.0/24
Image1 - ICMP-omleidingen in Ethernet-netwerken met meerdere punten
ICMP-omleidingen in multi-point Ethernet-netwerken
Host heeft IP-adres 10.0.0.100. De Host Routing Table heeft een standaard routeingang die wijst naar router G1's IP-adres 10.0.0.1 als de standaardgateway. De router G1 gebruikt router G2 IP adres 10.0.0.2 als zijn volgende hop wanneer het door:sturen van verkeer aan bestemmingsnetwerk X.
Dit is wat er gebeurt wanneer de host een pakket naar een doelnetwerk verstuurt X:
1. Gateway G1 met IP-adres 10.0.0.1 ontvangt gegevenspakket van host 10.0.0.10 op een netwerk waaraan het is gekoppeld.
2. De gateway, G1, controleert zijn routeringstabel en verkrijgt het IP-adres 10.0.0.2 van de volgende gateway, G2, op de route naar het gegevenspakketbestemmingsnetwerk, X.
3. Als G2 en de host die wordt geïdentificeerd door het bronadres van IP-pakket zich op hetzelfde netwerk bevinden, wordt een ICMP-omleidingsbericht naar de host verzonden. Het ICMP Redirect-bericht adviseert de host om zijn verkeer voor netwerk X rechtstreeks naar gateway G2 te verzenden, aangezien dit een kortere weg naar de bestemming is.
4. De gateway G1 verstuurt het oorspronkelijke gegevenspakket naar de bestemming.
Afhankelijk van de configuratie van de host, kan deze ervoor kiezen ICMP-omleidingsberichten te negeren die G1 naar de host stuurt. Als Host echter ICMP-berichten gebruikt om de routingcache aan te passen en latere gegevenspakketten rechtstreeks naar G2 begint te verzenden, worden deze voordelen in dit scenario bereikt
- Optimalisatie van het doorsturen van gegevens pad door het netwerk; verkeer bereikt sneller zijn bestemming.
- Vermindering van het gebruik van netwerkbronnen, zoals bandbreedte en router CPU-belasting.
Afbeelding 2 - Next Hop G2 geïnstalleerd in host Routing Cache
Next Hop G2 geïnstalleerd in host routing cache
Zoals getoond in Afbeelding 2, nadat de Host route cache ingang voor Network X met G2 als zijn volgende hop creëerde, worden deze voordelen in het netwerk gezien:
- Het bandbreedtegebruik op het verband tussen Switch en router G1 vermindert in beide richtingen.
- Het gebruik van cpu op router G1 vermindert omdat de verkeersstroom van Host naar Network X niet deze knoop meer oversteekt.
- De end-to-end netwerkvertraging tussen host en netwerk X verbetert.
Om het belang van het mechanisme van ICMP Redirect te begrijpen, herinner dat de vroege routerimplementaties van Internet hoofdzakelijk op de middelen van cpu vertrouwden om gegevensverkeer te verwerken. Daarom was het wenselijk om het verkeersvolume te verminderen dat door om het even welke enkele router moest worden behandeld en ook om het aantal routerhop te minimaliseren dat een bepaalde verkeersstroom op zijn weg naar de bestemming moest oversteken. Tegelijkertijd werd Layer 2 Forwarding (ook bekend als switching) voornamelijk geïmplementeerd in aangepaste Application-Specific Integrated Circuits (ASIC), en vanuit het perspectief van doorsturen van prestaties was relatief goedkoop in vergelijking met Layer 3 Forwarding (ook wel routing genoemd), die, opnieuw, werd uitgevoerd in processors voor algemene doeleinden.
Nieuwe ASIC-generaties kunnen zowel Layer 2 als Layer 3-pakketdoorsturen. Layer 3-tabelopmaak die in hardware wordt uitgevoerd, helpt de prestatiekosten te verlagen die door de routers aan pakketverwerking worden gekoppeld. Bovendien, toen Layer 3-doorsturen in Layer 2-switches werd geïntegreerd (die nu Layer 3-switches worden genoemd), werd pakketdoorsturen efficiënter. Dit elimineerde de behoefte aan één-gewapende router (ook bekend als router op een stok) ontwerpopties en vermeden beperkingen verbonden aan dergelijke netwerkconfiguraties.
Afbeelding 3 bouwt voort op het scenario in afbeelding 1. Layer 2- en Layer 3-functies, die oorspronkelijk door twee aparte knooppunten, Switch en router G1, worden geleverd, worden geconsolideerd in één Layer 3-Switch, zoals Nexus 7000 Series-platform.
Afbeelding 3 - Layer 3 Switch vervangt configuratie met één poort
Layer 3 Switch vervangt configuratie met één poort
Dit gebeurt er wanneer de host een pakket naar een doelnetwerk verstuurt X:
1. Gateway L3 Switch met IP-adres 10.0.0.1 ontvangt gegevenspakket van een host 10.0.0.10 op een netwerk waaraan het is gekoppeld.
2. De gateway, L3 Switch, controleert zijn routeringstabel en verkrijgt het adres 10.0.0.2 van de volgende gateway, G2, op het netwerk van de route aan de bestemming van het gegevenspakket, X.
3. Als G2 en de host die wordt geïdentificeerd door het bronadres van IP-pakket zich op hetzelfde netwerk bevinden, wordt een ICMP-omleidingsbericht naar de host verzonden. Het ICMP Redirect-bericht adviseert de host om zijn verkeer voor Network X rechtstreeks naar gateway G2 te verzenden, aangezien dit een kortere weg naar de bestemming is.
4. De gateway stuurt het oorspronkelijke gegevenspakket door naar de bestemming.
Nu Layer 3-switches zowel Layer 2 als Layer 3-pakketdoorsturen op ASIC-niveau kunnen uitvoeren, kan worden geconcludeerd dat beide voordelen van ICMP-omleidingsfunctionaliteit bieden. Ten eerste, verbetering van de vertraging door het netwerk en ten tweede, vermindering van het gebruik van netwerkbronnen worden bereikt, en er is geen behoefte meer aan veel aandacht voor pad optimalisatie technieken in multi-point Ethernet segmenten.
Echter, met ICMP Redirect functionaliteit ingeschakeld op Layer 3-interfaces, blijft suboptimaal doorsturen via multi-point Ethernet-segmenten potentiële knelpunten voor prestaties opleveren, ondanks dat om een andere reden, zoals uitgelegd in de sectie Nexus Platform Considerations later in dit document.
Suboptimale paden door Ethernet-netwerken
Interior Gateway Protocols (IGP), zoals Open Shortest Path First (OSPF) en Cisco Enhanced Interior Gateway Routing Protocol (EIGRP), zijn ontworpen om routing-informatie tussen routers te synchroniseren en consistent en voorspelbaar pakketdoorstuurgedrag te bieden op alle netwerkknooppunten die dergelijke informatie honoreren. Bijvoorbeeld, met multi-point Ethernet-netwerken, als alle Layer 3-knooppunten op een segment dezelfde routing-informatie gebruiken en het eens zijn over hetzelfde exit point naar de bestemming, is suboptimaal doorsturen over dergelijke netwerken zelden het geval.
Om te begrijpen wat sub-optimale het door:sturen wegen veroorzaakt, herinner dat Layer 3 knopen pakket het door:sturen van besluiten onafhankelijk van elkaar maken. Dat wil zeggen, het pakketdoorsturen van beslissingen die door router B zijn genomen is niet afhankelijk van het pakketdoorsturen van beslissingen die door router A zijn genomen. Dit is een van de belangrijkste principes om te onthouden wanneer u pakketdoorsturen via IP-netwerken probleemoplossing aanbiedt, en een belangrijk principe om in gedachten te houden wanneer u suboptimaal doorsturen pad in multi-point Ethernet-netwerken onderzoekt.
Zoals eerder vermeld, in netwerken waar alle routers op één enkel dynamisch routeringsprotocol vertrouwen om verkeer tussen eindpunten te leveren, moet het suboptimale door multi-point Ethernet-segmenten niet gebeuren. In real-world netwerken is het echter heel gewoon om een combinatie van verschillende packet routing- en verzendingsmechanismen te vinden. Voorbeelden van dergelijke mechanismen zijn diverse IGP’s, statische routing en op beleid gebaseerde routing. Deze functies worden doorgaans samen gebruikt om het gewenste doorsturen van verkeer via het netwerk te realiseren.
Terwijl gecombineerd gebruik van deze mechanismen kan helpen verkeer fijnafstemmen en aan vereisten van een bepaald netwerkontwerp voldoen, overzien zij bijwerkingen die deze hulpmiddelen samen in multi-point Ethernet netwerken kunnen veroorzaken in slechte algemene netwerkprestaties kunnen resulteren.
Statische routing
Om dit te illustreren, overweeg scenario in Beeld 4. Router A heeft statische route naar Network X met router B als zijn volgende-hop. Tezelfdertijd gebruikt router B router C als zijn volgende-hop in statische route naar netwerk X.
Afbeelding 4 - Suboptimaal pad met statische routing
Suboptimale pad met statische routing
Terwijl het verkeer dit netwerk bij router A ingaat, verlaat het door router C, en uiteindelijk wordt geleverd aan bestemmingsNetwerk X, moeten de pakketten dit IP netwerk tweemaal op hun manier doorkruisen aan de bestemming. Dit is geen efficiënt gebruik van netwerkbronnen. In plaats daarvan, verzend pakketten van Router A rechtstreeks naar Router C zou de zelfde resultaten, terwijl bereiken en minder netwerkmiddelen verbruiken.
Op beleid gebaseerde routing
Op beleid gebaseerde routing (PBR) is een ander mechanisme dat een suboptimaal pad via Ethernet-netwerken kan veroorzaken. In tegenstelling tot statische of dynamische routing werkt PBR echter niet op routingtabelniveau. In plaats daarvan wordt voor het verkeer een toegangscontrolelijst (ACL) direct in de switch-hardware omgeleid. Dientengevolge, voor geselecteerde verkeersstromen, omzeilt het pakket door:sturen raadpleging op de toegangslijn kaart het verpletteren van informatie die via Statische of Dynamische Verplettering wordt verkregen.
In afbeelding 4 wisselen routers A en B routerinformatie uit over het doelnetwerk X met een van de dynamische routerprotocollen. Beiden zijn het eens over router B is de beste volgende-hop aan dit netwerk.
Met een PBR-configuratie op router B die routing-informatie die van het routeringsprotocol is ontvangen en router C als volgende hop op netwerk X instelt, wordt echter voldaan aan de voorwaarde om de ICMP-omleidingsfunctie te activeren en wordt het pakket naar de CPU van router B verzonden om het verder te verwerken.
ICMP-omleidingen op point-to-point links
Tot nu toe verwees dit document naar Ethernet-netwerken die drie (of meer) Layer 3-knooppunten hebben gekoppeld, vandaar de naam multi-point Ethernet-netwerken. Houd er echter rekening mee dat ICMP-omleidingsberichten ook op point-to-point Ethernet-koppelingen kunnen worden gegenereerd.
Overweeg het scenario op Afbeelding 5. Router A gebruikt statische standaardroute om verkeer naar router B te verzenden, terwijl router B een statische route aan netwerk X heeft die aan router A richt.
Afbeelding 5 - ICMP-omleidingen op point-to-point links
Suboptimale pad met statische routing
Deze ontwerpoptie, ook wel bekend als single-homed verbinding, is een populaire keuze wanneer u kleine gebruikersomgevingen verbindt met Service Provider netwerken. Hier is router B een Provider Edge (PE)-apparaat en router A is een User Edge (CE)-apparaat.
Bericht dat de typische configuratie van Ce de gezamenlijke statische route(s) aan gebruiker IP adresblokken omvat die aan Null0 interface richten. Deze configuratie is een aanbevolen best practice voor single-homed CE-PE connectiviteit optie met statische routing. Ga er in dit voorbeeld echter van uit dat er geen dergelijke configuratie aanwezig is.
Stel dat router A de connectiviteit met netwerk X verliest zoals in de afbeelding. Wanneer pakketten van het gebruikersnetwerk Y of het externe netwerk Z proberen om netwerk X te bereiken, kunnen routers A en B het verkeer tussen elkaar stuiteren, en vermindert het IP Time-To-Live veld in elk pakket tot de waarde 1 bereikt, op welk punt verdere routing van het pakket niet mogelijk is.
Terwijl het verkeer aan Netwerk X heen en weer tussen PE en CE routers stuitert, stijgt dramatisch (en onnodig) Ce-PE gebruik van de verbindingsbandbreedte. Het probleem wordt erger als ICMP-omleidingen zijn ingeschakeld aan een of beide zijden van point-to-point PE-CE-verbinding. In dit geval wordt elk pakket in de stroom die naar Network X wordt geleid, meerdere malen in CPU’s op elke router verwerkt om de ICMP-omleidingsberichten te genereren.
Nexus platform overwegingen
Wanneer ICMP-omleidingen zijn ingeschakeld op Layer 3-interface en een inkomend gegevenspakket deze interface gebruikt om een Layer 3-switch in te voeren en te verlaten, wordt een ICMP-bericht voor omleiding gegenereerd. Layer 3-pakketdoorsturen gebeurt in hardware op Cisco Nexus 7000-platform, maar het is nog steeds de verantwoordelijkheid van de switch-CPU om ICMP-omleidingsberichten te construeren. Om dit te doen, moet CPU op Nexus 7000 Supervisor module IP adresinformatie verkrijgen van de stroom waarvan het pad door het netwerksegment kan worden geoptimaliseerd. Dit is de reden achter gegevenspakket dat door toegangslijnkaart naar de module van de Supervisor wordt verzonden.
Als ontvangers van een ICMP Redirect-bericht dit negeren en doorgaan met het doorsturen van gegevensverkeer naar Layer 3-switch van Nexus waarop ICMP-omleidingen zijn ingeschakeld, wordt het ICMP Redirect-generatieproces geactiveerd voor elk gegevenspakket.
Op lijnkaartniveau begint het proces in de vorm van hardware-Forwarding-uitzondering. De uitzonderingen worden opgeheven op ASICs wanneer de pakket het door:sturen verrichting niet met succes door de lijnkaartmodule kan worden voltooid. In dit geval moet het gegevenspakket naar de Supervisor-module worden verzonden voor correcte pakketverwerking.
Nadat CPU op de Supervisor module verzonden ICMP Redirect bericht naar de bron, voltooit het uitzondering behandeling door gegevenspakket door te sturen naar de volgende hop door uitgang lijnkaartmodule.
Terwijl Nexus 7000 Supervisor modules gebruik maken van krachtige CPU-processors die grote verkeersvolumes kunnen verwerken, is het platform ontworpen om het grootste deel van het dataverkeer op lijnkaartniveau te verwerken zonder de noodzaak om de Supervisor CPU-processor te betrekken bij het pakketdoorsturen proces. Hierdoor kan de CPU zich op zijn kerntaken richten en kan pakketdoorsturen naar speciale hardware-engine op lijnkaarten.
In stabiele netwerken wordt verwacht dat pakketdoorsturen van uitzonderingen, als ze zich voordoen, op een redelijk lage snelheid plaatsvindt. Op basis van deze veronderstelling kunnen ze worden verwerkt door Supervisor CPU zonder dat dit van grote invloed is op de prestaties. Aan de andere kant kan een CPU die zich bezighoudt met pakketdoorsturen van uitzonderingen die op een zeer hoog tempo voorkomen een negatief effect hebben op de algehele systeemstabiliteit en reactievermogen.
Het Nexus 7000 platformontwerp biedt een aantal mechanismen om switch CPU’s te beschermen tegen aanzienlijk verkeer. Deze mechanismen worden op verschillende punten in het systeem toegepast. Op lijnkaartniveau zijn er hardwareresultaten en besturingsplane Policing (CoPP)-functie. Beide vastgestelde verkeersdrempels, die effectief de hoeveelheid verkeer controleert die van elke lijnkaartmodule naar de Supervisor moet worden doorgestuurd.
Deze beveiligingsmechanismen geven de voorkeur aan het verkeer van verschillende controleprotocollen die van cruciaal belang zijn voor netwerkstabiliteit en beheerbaarheid van de switch, zoals OSPF, BGP of SSH, en filteren tegelijkertijd op agressieve wijze verkeerstypen die niet van cruciaal belang zijn om de vliegtuigfunctionaliteit van de switch te regelen. Het grootste deel van het gegevensverkeer wordt, indien dit naar de CPU wordt doorgestuurd als gevolg van uitzonderingen voor het doorsturen van pakketten, zwaar bewaakt door dergelijke mechanismen.
Hardware snelheidsbegrenzers en CoPP policing De mechanismen verstrekken stabiliteit van controlevliegtuig van de switch en sterk geadviseerd om altijd worden toegelaten, kunnen zij één van de belangrijkste redenen van gegevenspakketdalingen, overdrachtvertragingen, en algemene slechte toepassingsprestaties over het netwerk zijn. Dit is waarom het belangrijk is om de wegen te begrijpen die verkeersstromen door het netwerk en het gebruik van hulpmiddelen nemen om netwerkapparatuur te controleren die kan en/of verwacht om functionaliteit ICMP Redirect te gebruiken.
Tools voor bewaking en diagnose van verkeer
IP-verkeer tonen
Zowel Cisco IOS- als Cisco NX-OS-software biedt een manier om statistieken te controleren van het verkeer dat door CPU wordt verwerkt. Dit gebeurt met show ip traffic uit. Deze opdracht kan worden gebruikt om ontvangst en/of genereren van ICMP Redirect-berichten te controleren op Layer 3-switch of -router.
Nexus7000#show ip traffic | begin ICMP
ICMP Software Processed Traffic Statistics
------------------------------------------
Transmission:
Redirect: 1000, unreachable: 0, echo request: 0, echo reply: 0,
<output omitted for brevity>
ICMP originate Req: 0, Redirects Originate Req: 1000
Originate deny - Resource fail: 0, short ip: 0, icmp: 0, others: 0
Reception:
Redirect: 0, unreachable: 0, echo request: 0, echo reply: 0,
<output omitted for brevity>
Nexus7000#
Voer uit show ip traffic opdracht een paar keer en controleer of ICMP-omleiding tellerstoename.
Ethanalyzer
Cisco NX-OS-software heeft een ingebouwde tool om verkeer op te nemen flowing van en naar switch CPU, bekend als Ethanalyzer.
Afbeelding 6 laat een scenario zien dat vergelijkbaar is met dat in Afbeelding 3. Hier wordt Netwerk X vervangen door 192.168.0.0/24 netwerk.
Afbeelding 6 - Ethanalyzer Capture uitvoeren
Leg ethanalyzer Capture uit
De host 10.0.0.10 verstuurt een continue stroom ICMP Echo-aanvragen naar het IP-adres van de bestemming 192.168.0.1. De host gebruikt Switch Virtual Interface (SVI) 10 van Nexus 7000 switch als zijn volgende hop naar het externe netwerk 192.168.0.0/24. Voor demonstratiedoeleinden wordt de host geconfigureerd om ICMP-omleidingsberichten te negeren.
Gebruik deze volgende opdracht om ICMP-verkeer op te nemen dat is ontvangen en verzonden door Nexus 7000 CPU:
Nexus7000#ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000
Capturing on inband
2018-09-15 23:45:40.124077 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.124477 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.124533 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.126344 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.126607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.126655 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.130362 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.130621 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.130669 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.132392 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.132652 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.132700 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.134347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.134612 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.134660 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.136347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.136598 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.136645 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.138351 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
2018-09-15 23:45:40.138607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.138656 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
...
Tijdstempels in de vorige output suggereren dat drie pakketten die in dit voorbeeld werden benadrukt tegelijkertijd werden opgenomen, 2018-09-15 23:45:40.128. Vervolgens is er een uitsplitsing per pakket van deze pakketgroep
- Het eerste pakket is het gegevenspakket voor ingangsgegevens, dat in dit voorbeeld een ICMP-echoverzoek is.
2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping)-verzoek
- Het tweede pakket is een pakket ICMP Redirect, dat door gateway wordt geproduceerd. Dit pakket wordt teruggestuurd naar de host.
2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect voor host)
- Het derde pakket is het gegevenspakket dat in de uitgangsrichting is opgenomen nadat het door de CPU is gerouteerd. Hoewel niet eerder getoond, is de IP TTL van dit pakket verminderd en de controlesom opnieuw berekend.
2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping)-verzoek
Terwijl u door grote Ethanalyzer bladert vangt die vele pakketten van verschillende types en stromen hebben, kan het moeilijk zijn om ICMP te correleren omleiden berichten met het gegevensverkeer dat aan hen beantwoordt.
In deze situaties, focus op ICMP omleiden berichten om informatie op te halen over sub-optimaal doorgestuurde verkeersstromen. ICMP-omleidingsberichten bevatten de internetheader plus de eerste 64 bits van de oorspronkelijke datagramgegevens. Deze gegevens worden gebruikt door de bron van het datagram om het bericht aan het aangewezen proces aan te passen.
Gebruik het pakketopnamegereedschap van Ethanalyzer met detailtrefwoord om de inhoud van ICMP-omleidingsberichten weer te geven en IP-adresinformatie te vinden van de gegevensstroom die suboptimaal wordt doorgestuurd.
Nexus7000#ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000 detail
...
Frame 2 (70 bytes on wire, 70 bytes captured)
Arrival Time: Sep 15, 2018 23:54:04.388577000
[Time delta from previous captured frame: 0.000426000 seconds]
[Time delta from previous displayed frame: 0.000426000 seconds]
[Time since reference or first frame: 0.000426000 seconds]
Frame Number: 2
Frame Length: 70 bytes
Capture Length: 70 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:icmp:ip:icmp:data]
Ethernet II, Src: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf), Dst: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
Destination: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
Address: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
Address: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.100 (10.0.0.100)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0xf986 (63878)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0xadd9 [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.1 (10.0.0.1)
Destination: 10.0.0.100 (10.0.0.100)
Internet Control Message Protocol
Type: 5 (Redirect)
Code: 1 (Redirect for host)
Checksum: 0xb8e5 [correct]
Gateway address: 10.0.0.2 (10.0.0.2)
Internet Protocol, Src: 10.0.0.100 (10.0.0.100), Dst: 192.168.0.1 (192.168.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0xf986 (63878)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 254
Protocol: ICMP (0x01)
Header checksum: 0xa8ae [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.100 (10.0.0.100)
Destination: 192.168.0.1 (192.168.0.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0 ()
Checksum: 0x02f9 [incorrect,shouldbe 0xcae1]
Identifier: 0xa01d
Sequence number: 36096 (0x8d00)
...
ICMP-omleidingen uitschakelen
Als het netwerkontwerp vereist dat de verkeersstroom uit dezelfde Layer 3-interface wordt gerouteerd waarop het de switch of router heeft ingevoerd, is het mogelijk om te voorkomen dat de stroom door de CPU wordt gerouteerd als u de ICMP-omleidingsfunctionaliteit op Layer 3-interface die aan deze interface beantwoordt, uitschakelt.
In feite is het voor de meeste netwerken een goede praktijk om ICMP-omleidingen proactief uit te schakelen op alle Layer 3-interfaces, zowel fysiek, zoals Ethernet-interface, als virtueel, zoals Port-Channel- en SVI-interfaces. Gebruik de no ip redirects Cisco NX-OS opdracht op interfaceniveau om ICMP-omleidingen op een Layer 3-interface uit te schakelen. Controleer of de functionaliteit van ICMP Redirect is uitgeschakeld:
- verzekeren
no ipomleidt bevel wordt toegevoegd aan interfaceconfiguratie.
Nexus7000#show run interface vlan 10 interface Vlan10
no shutdown no ip redirects ip address 10.0.0.1/24
- Zorg ervoor dat de status van ICMP-omleidingen op de interface uitgeschakeld is.
Nexus7000#show ip interface vlan 10 | include redirects IP icmp redirects: disabled
- Zorg ervoor dat de vlag voor ICMP Redirect Enable/Disable op 0 is ingesteld door de softwarecomponent van Cisco NX-OS die de interfaceconfiguratie van switch Supervisor naar een of meer lijnkaarten duwt.
Nexus7000#show system internal eltm info interface vlan 10 | i icmp_redirect per_pkt_ls_en = 0, icmp_redirect = 0, v4_same_if_check = 0
- Zorg ervoor dat ICMP Redirect in-/uitschakelen vlag voor een bepaalde Layer 3-interface is ingesteld op 0 op een of meer lijnkaarten.
Nexus7000#attach module 7
Attaching to module 7 ...
To exit type 'exit', to abort type '$.'
Last login: Wed Sep 15 23:56:25 UTC 2018 from 127.1.1.1 on pts/0
module-7#
!--- Optionally, jump to non-admin Virtual Device Context (VDC) if verification needs to be done in one of the custom VDCs
module-7#vdc 6
module-7#show system internal iftmc info interface vlan 10 | include icmp_redirect
icmp_redirect : 0x0 ipv6_redirect : 0x1
Samenvatting
Het ICMP Redirect-mechanisme, zoals beschreven in RFC 792, is ontworpen om het doorsturen van pad door multi-point netwerksegmenten te optimaliseren. Aan het begin van het internet hielp een dergelijke optimalisatie om dure netwerkresources te beschermen, zoals de bandbreedte van de link en de CPU-cycli van routers. Naarmate de netwerkbandbreedte betaalbaarder werd en de relatief langzame op CPU’s gebaseerde pakketrouting evolueerde tot een snellere Layer 3-pakketdoorgifte in speciale hardware-ASIC’s, nam het belang van een optimale gegevensdoorvoer door multipoint netwerksegmenten af. Standaard is de functionaliteit ICMP Redirect ingeschakeld op elke Layer 3-interface. Pogingen om de netwerkknooppunten op multi-point Ethernet-segmenten op de hoogte te stellen van optimale doorstuurpaden worden echter niet altijd begrepen en door het netwerkpersoneel opgevolgd. In netwerken met gecombineerd gebruik van verschillende doorsturen mechanismen, zoals Statische routing, Dynamische routing en op beleid gebaseerde routing, kan dit leiden tot ongewenst gebruik van doorvoer knooppunt(en) CPU’s om productieverkeer te verwerken als u de functionaliteit ICMP Redirect inschakelt en niet goed controleert. Dit kan op zijn beurt een aanzienlijk effect hebben op zowel de stromen van productieverkeer als de stabiliteit van het controlevliegtuig van de netwerkinfrastructuur.
Voor de meeste netwerken wordt het beschouwd als een goede praktijk om functionaliteit ICMP Redirect op alle Layer 3-interfaces in netwerkinfrastructuur proactief uit te schakelen. Dit helpt om scenario's van productiegegevensverkeer te voorkomen dat in CPU van Layer 3-switches en -routers wordt verwerkt wanneer er een beter doorsturen pad is door multipoint netwerksegmenten.
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
3.0 |
31-Oct-2023 |
Bijgewerkte branding vereisten, opmaak en bijdragerlijst. |
2.0 |
22-Sep-2022 |
Hercertificering |
1.0 |
17-Oct-2018 |
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)