Begrijp ICMP-omleidingsberichten

Inleiding

In dit document wordt de functie Internet Control Message Protocol (ICMP) packet redirect beschreven.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Nexus 7000-platformarchitectuur
• Cisco NX-OS-softwareconfiguratie
• Internet Control Message Protocol zoals gedocumenteerd in Request for Comments (RFC) 792

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Nexus 7000 
• 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

In dit document wordt de pakketomleidingsfunctionaliteit besproken die wordt geboden door het Internet Control Message Protocol (ICMP). Het document legt uit wat de aanwezigheid van ICMP Redirect-berichten in het netwerk meestal aangeeft en wat kan worden gedaan om negatieve bijwerkingen te minimaliseren die verband houden met netwerkomstandigheden die het genereren van ICMP Redirect-berichten veroorzaken.

ICMP-omleidingsberichten

De ICMP redirect functionaliteit wordt uitgelegd in RFC 792 Internet Control Message Protocol met dit voorbeeld:

De gateway stuurt een redirect-bericht naar een host in deze situatie.

Een gateway, G1, ontvangt een internetdatagram van een host op een netwerk waaraan de gateway is gekoppeld. De gateway, G1, controleert de routeringstabel en verkrijgt het adres van de volgende gateway, G2, op de route naar het datagram Internet destination network, X

Als G2 en de host die wordt geïdentificeerd door het internetbronadres van het datagram zich op hetzelfde netwerk bevinden, wordt een omleidingsbericht naar de host verzonden. Het omleidingsbericht adviseert de host om zijn verkeer voor netwerk X rechtstreeks naar gateway G2 te sturen, omdat dit een korter pad naar de bestemming is.

De gateway stuurt de oorspronkelijke datagramgegevens door naar de internetbestemming.

Dit scenario wordt getoond in afbeelding 1. 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

Afbeelding 1 - ICMP-omleidingen in Ethernet-netwerken met meerdere punten

ICMP-omleidingen in Ethernet-netwerken met meerdere punten

Host heeft IP-adres 10.0.0.100. De routeringstabel van de host heeft een standaard routevermelding die verwijst naar het IP-adres 10.0.0.1 van router G1 als de standaardgateway. Router G1 gebruikt het IP-adres 10.0.0.2 van router G2 als de volgende stap bij het doorsturen van verkeer naar bestemmingsnetwerk X. 

Dit is wat er gebeurt wanneer de host een pakket naar bestemmingsnetwerk X verzendt:

1. Gateway G1 met IP-adres 10.0.0.1 ontvangt een gegevenspakket van host 10.0.0.100 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 bestemmingsnetwerk voor gegevenspakketten, X.

3. Als G2 en de host die door het bronadres van het IP-pakket wordt geïdentificeerd, zich op hetzelfde netwerk bevinden, wordt het ICMP-redirect-bericht naar de host verzonden. Het ICMP Redirect-bericht adviseert de host om zijn verkeer voor netwerk X rechtstreeks naar gateway G2 te sturen, omdat dit een korter pad naar de bestemming is.

4. De gateway G1 stuurt het oorspronkelijke gegevenspakket door naar de bestemming.

Afhankelijk van de hostconfiguratie kan het ervoor kiezen om ICMP Redirect-berichten die G1 naar het host verzendt, te negeren. Als Host echter ICMP Redirect-berichten gebruikt om de routeringscache aan te passen en volgende gegevenspakketten rechtstreeks naar G2 begint te verzenden, worden deze voordelen in dit scenario bereikt

• Optimalisatie van het data forwarding pad door het netwerk; het verkeer bereikt sneller zijn bestemming.
• Vermindering van het gebruik van netwerkbronnen, zoals bandbreedte en CPU-belasting van de router.

Afbeelding 2 - Volgende Hop G2 geïnstalleerd in hostrouteringscache

Volgende Hop G2 geïnstalleerd in hostrouteringscache

Zoals in Afbeelding 2 wordt getoond, worden deze voordelen in het netwerk gezien nadat de host routecachevermelding heeft gemaakt voor Network X met G2 als volgende hop:

• Het bandbreedtegebruik op de verbinding tussen Switch en router G1 neemt in beide richtingen af.
• CPU-gebruik op router G1 vermindert omdat de verkeersstroom van host naar netwerk X deze node niet meer doorkruist.
• End-to-end netwerkvertraging tussen host en netwerk X verbetert. 

Om het belang van het ICMP Redirect-mechanisme te begrijpen, moet u er rekening mee houden dat vroege internetrouterimplementaties voornamelijk afhankelijk waren van CPU-bronnen om dataverkeer te verwerken. Daarom was het wenselijk om het verkeersvolume te verminderen dat door een enkele router moest worden afgehandeld en ook om het aantal routerhops te minimaliseren dat een bepaalde verkeersstroom moest doorlopen op weg naar de bestemming. Tegelijkertijd werd Layer 2 forwarding (ook bekend als switching) voornamelijk geïmplementeerd in aangepaste Application-Specific Integrated Circuits (ASIC), en vanuit het oogpunt van forwarding-prestaties was relatief goedkoop in vergelijking met Layer 3 forwarding (ook wel routing genoemd), dat opnieuw werd gedaan in processors voor algemene doeleinden.

Nieuwere ASIC-generaties kunnen zowel Layer 2- als Layer 3-packet forwarding uitvoeren. Het opzoeken van de Layer 3-tabel in hardware helpt de prestatiekosten te verlagen die gepaard gaan met pakketverwerking door de routers. Toen de Layer 3-forwardingfunctionaliteit in Layer 2-switches werd geïntegreerd (die nu Layer 3-switches worden genoemd), werd de pakketforwardingwerking bovendien efficiënter. Dit elimineerde de noodzaak voor eenarmige router (ook bekend als router op een stick) ontwerpopties en vermeden beperkingen in verband met dergelijke netwerkconfiguraties.

Afbeelding 3 bouwt voort op het scenario in afbeelding 1. De Layer 2- en Layer 3-functies, die oorspronkelijk werden geleverd door twee aparte knooppunten, Switch en router G1, zijn nu geconsolideerd in één Layer 3-Switch, zoals het Nexus 7000-platform.

Afbeelding 3 - Layer3-Switch vervangt routerconfiguratie met één arm

Layer3-Switch vervangt routerconfiguratie met één arm

Dit is wat er gebeurt wanneer de host een pakket verzendt naar de bestemming Network X:

1. Gateway L3-Switch met IP-adres 10.0.0.1 ontvangt een gegevenspakket van een host 10.0.0.100 op een netwerk waarop het is aangesloten.

2. De gateway, L3-Switch, controleert de routeringstabel en krijgt het adres 10.0.0.2 van de volgende gateway, G2, op de route naar het bestemmingsnetwerk voor gegevenspakketten, X.

3. Als G2 en de host die door het bronadres van het IP-pakket wordt geïdentificeerd, zich op hetzelfde netwerk bevinden, wordt het ICMP-redirect-bericht naar de host verzonden. Het ICMP Redirect-bericht adviseert de host om zijn verkeer voor Network X rechtstreeks naar gateway G2 te sturen, omdat dit een korter pad naar de bestemming is.

4. De gateway stuurt het oorspronkelijke gegevenspakket door naar de bestemming.

Met Layer 3-switches die nu in staat zijn om zowel Layer 2- als Layer 3-pakketforwarding op ASIC-niveau uit te voeren, kan worden geconcludeerd dat beide voordelen van ICMP Redirect-functionaliteit. Ten eerste, verbetering van de vertraging via het netwerk en ten tweede, vermindering van het gebruik van netwerkbronnen worden bereikt, en er is niet meer nodig om veel aandacht te hebben voor pad optimalisatie technieken in multi-point Ethernet segmenten.

Met de ICMP Redirect-functionaliteit die is ingeschakeld op Layer 3-interfaces, blijft suboptimale forwarding via Ethernet-segmenten met meerdere punten potentiële prestatieknelpunten opleveren, ook al is dit om een andere reden, zoals uitgelegd in de sectie Overwegingen over Nexus-platform verderop in dit document.

Opmerking: ICMP-omleidingen zijn standaard ingeschakeld op Layer 3-interfaces in Cisco IOS®- en Cisco NX-OS-software.

Opmerking: Overzicht van omstandigheden waarin ICMP-omleidingsberichten worden gegenereerd: Layer3-switch genereert ICMP-omleidingsbericht terug naar de bron van het gegevenspakket, als het gegevenspakket moet worden doorgestuurd naar de Layer 3-interface waarop dit pakket wordt ontvangen.

Suboptimale paden via Ethernet-netwerken

Interior Gateway Protocollen (IGP), zoals Open Shortest Path First (OSPF) en Cisco Enhanced Interior Gateway Routing Protocol (EIGRP), zijn ontworpen om routeringsinformatie tussen routers te synchroniseren en om consistent en voorspelbaar pakketdoorstuurgedrag te bieden op alle netwerkknooppunten die dergelijke informatie eren. Als bijvoorbeeld bij Ethernet-netwerken met meerdere punten alle Layer 3-knooppunten in een segment dezelfde routeringsinformatie gebruiken en hetzelfde afsluitpunt naar de bestemming overeenkomen, is suboptimale doorgifte over dergelijke netwerken zelden het geval.

Om te begrijpen wat suboptimale doorstuurpaden veroorzaakt, moet u onthouden dat Layer 3-knooppunten beslissingen over het doorsturen van pakketten onafhankelijk van elkaar maken. Dat wil zeggen dat de beslissing over het doorsturen van pakketten door Router B niet afhankelijk is van de beslissing over het doorsturen van pakketten die door Router A is genomen. Dit is een van de belangrijkste principes om te onthouden wanneer u problemen oplost bij het doorsturen van pakketten via IP-netwerken, en is een belangrijke om in gedachten te houden wanneer u suboptimale doorstuurpad in multi-point Ethernet-netwerken onderzoekt.

Zoals eerder vermeld, in netwerken waar alle routers vertrouwen op een enkel dynamisch routeringsprotocol om verkeer tussen eindpunten te leveren, mag suboptimale doorgifte via Ethernet-segmenten met meerdere punten niet plaatsvinden. In echte netwerken is het echter heel gebruikelijk om een combinatie van verschillende pakketrouting- en doorstuurmechanismen te vinden. Voorbeelden van dergelijke mechanismen zijn verschillende IGP's, statische routering en op beleid gebaseerde routering. Deze functies worden meestal samen gebruikt om het gewenste verkeer door het netwerk te laten doorsturen.

Hoewel gecombineerd gebruik van deze mechanismen kan helpen bij het afstemmen van de verkeersstroom en voldoen aan de vereisten van een bepaald netwerkontwerp, zien ze bijwerkingen over het hoofd die deze hulpmiddelen samen kunnen veroorzaken in Ethernet-netwerken met meerdere punten, wat kan leiden tot slechte algehele netwerkprestaties.

statische routering

Om dit te illustreren, overweeg het scenario in afbeelding 4. Router A heeft een statische route naar Network X met Router B als de volgende stap. Tegelijkertijd gebruikt Router B Router C als de volgende stap in de statische route naar Network X.

Afbeelding 4 - Suboptimaal pad met statische routering

Suboptimaal pad met statische routering

Terwijl het verkeer dit netwerk binnenkomt bij Router A, het verlaat via Router C en uiteindelijk wordt geleverd aan bestemmingsnetwerk X, moeten pakketten dit IP-netwerk twee keer doorkruisen op weg naar de bestemming. Dit is geen efficiënt gebruik van netwerkbronnen. In plaats daarvan zou het verzenden van pakketten van Router A rechtstreeks naar Router C dezelfde resultaten opleveren, terwijl het minder netwerkbronnen zou verbruiken.

Opmerking: Hoewel in dit scenario Router A en Router C worden gebruikt als ingress- en egress Layer 3-knooppunten voor dit IP-netwerksegment, kunnen beide knooppunten worden vervangen door netwerkapparaten (zoals load balancers of firewalls) als de laatste routeringsconfiguratie hebben die resulteert in hetzelfde pakketdoorstuurgedrag.

op beleid gebaseerde routering

Policy Based Routing (PBR) is een ander mechanisme dat een suboptimaal pad door Ethernet-netwerken kan veroorzaken. In tegenstelling tot statische of dynamische routering werkt PBR echter niet op routingtafelniveau. In plaats daarvan programmeert het verkeer omleiden Access Control List (ACL) rechtstreeks in de switch hardware. Als gevolg hiervan omzeilt packet forwarding-opzoeken op ingress line-kaarten voor bepaalde verkeersstromen routeringsinformatie die wordt verkregen via statische of dynamische routering. 

In Afbeelding 4 wisselen routers A en B routeringsinformatie over bestemmingsnetwerk X uit met een van de dynamische routeringsprotocollen. Beide zijn het erover eens dat Router B de beste next-hop is voor dit netwerk.

Echter, met een PBR configuratie op Router B die routing informatie ontvangen van routing protocol overschrijven en stelt Router C als next-hop naar netwerk X, voorwaarde om ICMP Redirect functie te activeren wordt voldaan en pakket wordt verzonden naar de CPU van Router B om het verder te verwerken.

ICMP-omleidingen op Point-to-Point Links

Tot nu toe verwees dit document naar Ethernet-netwerken waaraan drie (of meer) Layer 3-knooppunten zijn gekoppeld, vandaar de naam multi-point Ethernet-netwerken. Houd er echter rekening mee dat ICMP Redirect-berichten ook op point-to-point Ethernet-koppelingen kunnen worden gegenereerd.

Overweeg scenario op afbeelding 5. Router A gebruikt een statische standaardroute om verkeer naar router B te verzenden, terwijl router B een statische route naar netwerk X heeft die naar router A wijst.

Afbeelding 5 - ICMP-omleidingen op point-to-point links

Suboptimaal pad met statische routering

Deze ontwerpoptie, ook bekend als single-homed-verbinding, is een populaire keuze wanneer u kleine gebruikersomgevingen verbindt met netwerken van serviceproviders. Router B is een Provider Edge (PE) apparaat en Router A is een User Edge (CE) apparaat.

Merk op dat de typische CE-configuratie geaggregeerde statische route(s) naar gebruikers-IP-adresblokken bevat die naar de Null0-interface verwijzen. Deze configuratie is een aanbevolen best practice voor single-homed CE-PE connectiviteitsoptie met statische routering. Ga er voor de toepassing van dit voorbeeld echter van uit dat een dergelijke configuratie niet aanwezig is.

Stel dat router A de verbinding met netwerk X verliest, zoals in de afbeelding wordt weergegeven. Wanneer pakketten van de gebruiker Network Y of remote Network Z proberen Network X te bereiken, kunnen Routers A en B het verkeer tussen elkaar stuiteren en het IP Time-To-Live-veld in elk pakket verlagen totdat de waarde 1 bereikt, op welk punt verdere routering van het pakket niet mogelijk is.

Terwijl het verkeer naar Network X heen en weer stuitert tussen PE- en CE-routers, neemt het gebruik van de CE-PE-linkbandbreedte drastisch (en onnodig) toe. Het probleem wordt erger als ICMP-omleidingen zijn ingeschakeld aan één of beide zijden van de PE-CE-verbinding. In dit geval wordt elk pakket in de stroom die naar Network X wordt geleid, meerdere keren in CPU op elke router verwerkt om de ICMP Redirect-berichten te helpen genereren.

Overwegingen over het Nexus-platform

Wanneer ICMP-omleidingen zijn ingeschakeld op de Layer 3-interface en een inkomend gegevenspakket deze interface gebruikt om een Layer3-switch in en uit te schakelen, wordt een ICMP-omleidingsbericht gegenereerd. Hoewel Layer 3 packet forwarding wordt uitgevoerd op het Cisco Nexus 7000-platform, is het nog steeds de taak van de switch-processor om ICMP Redirect-berichten te construeren. Hiervoor moet de CPU op de Nexus 7000 Supervisor-module IP-adresinformatie verkrijgen van de stroom waarvan het pad door het netwerksegment kan worden geoptimaliseerd. Dit is de reden achter het datapakket dat per ingress-lijnkaart naar de module Supervisor wordt verzonden.

Als ontvangers van het ICMP-redirect-bericht dit negeren en doorgaan met het doorsturen van dataverkeer naar de Layer 3-interface van de Nexus-switch waarop ICMP-redirects zijn ingeschakeld, wordt het ICMP-redirect-generatieproces geactiveerd voor elk gegevenspakket.

Op het niveau van de lijnkaart begint het proces in de vorm van een uitzondering voor het doorsturen van hardware. Uitzonderingen worden gemaakt op ASIC's wanneer het doorsturen van pakketten niet met succes kan worden voltooid door de lijnkaartmodule. In dit geval moet het gegevenspakket worden verzonden naar de module Supervisor voor een correcte pakketverwerking.

Opmerking: De CPU op de Supervisor-module genereert niet alleen ICMP-omleidingsberichten, maar verwerkt ook vele andere uitzonderingen voor het doorsturen van pakketten, zoals IP-pakketten met de TTL-waarde (Time To Live) ingesteld op 1 of IP-pakketten die gefragmenteerd moeten worden voordat ze naar de volgende hop worden verzonden.

Nadat de CPU op de Supervisor-module het ICMP-omleidingsbericht naar de bron heeft verzonden, voltooit deze de uitzonderingsafhandeling door het gegevenspakket door te sturen naar de volgende hop-through-egress-lijnkaartmodule.

Terwijl Nexus 7000 Supervisor-modules krachtige CPU-processors gebruiken die grote hoeveelheden verkeer kunnen verwerken, is het platform ontworpen om het grootste deel van het gegevensverkeer op het niveau van de lijnkaart af te handelen zonder de Supervisor CPU-processor in te schakelen in het proces voor het doorsturen van pakketten. Hierdoor kan de CPU zich concentreren op zijn kerntaken en kan het pakket worden doorgestuurd naar speciale hardware-engines op lijnkaarten.

In stabiele netwerken worden uitzonderingen voor het doorsturen van pakketten, als ze zich voordoen, verwacht tegen een redelijk lage snelheid. Met deze aanname kunnen ze worden afgehandeld door de Supervisor-CPU zonder aanzienlijke invloed op de prestaties. Aan de andere kant, met een CPU die zich bezighoudt met packet forwarding uitzonderingen die zich voordoen bij een zeer hoge snelheid kan een negatief effect hebben op de algehele stabiliteit van het systeem en de responsiviteit.

Het Nexus 7000-platformontwerp biedt een aantal mechanismen om de switch-CPU te beschermen tegen aanzienlijke hoeveelheden verkeer. Deze mechanismen worden op verschillende punten in het systeem geïmplementeerd. Op het niveau van de lijnkaart zijn er hardwaresnelheidsbegrenzers en de functie Control Plane Policing (CoPP). Beide stellen verkeersdrempels vast, die effectief de hoeveelheid verkeer regelen die vanuit elke lijnkaartmodule naar de toezichthouder moet worden doorgestuurd. 

Deze beveiligingsmechanismen geven de voorkeur aan het verkeer van verschillende besturingsprotocollen die van cruciaal belang zijn voor netwerkstabiliteit en beheerbaarheid van de switch, zoals OSPF, BGP of SSH, en tegelijkertijd filteren ze agressief soorten verkeer die niet van cruciaal belang zijn om de vliegtuigfunctionaliteit van de switch te regelen. Het grootste deel van het dataverkeer, indien doorgestuurd naar de CPU als gevolg van packet forwarding uitzonderingen, wordt zwaar bewaakt door dergelijke mechanismen.

Hoewel hardwaresnelheidsbegrenzers en CoPPpolicing-mechanismen zorgen voor een stabiele controle van het bedieningsvlak van de switch en sterk worden aanbevolen om altijd ingeschakeld te zijn, kunnen ze een van de belangrijkste redenen zijn voor het vallen van gegevenspakketten, overdrachtvertragingen en algehele slechte toepassingsprestaties in het netwerk. Daarom is het belangrijk om de paden te begrijpen die verkeersstromen door het netwerk nemen en het gebruik van hulpmiddelen om netwerkapparatuur te bewaken die ICMP Redirect-functionaliteit kan en / of naar verwachting zal gebruiken.

Tools voor het monitoren en diagnosticeren van verkeer

IP-verkeer weergeven

Zowel Cisco IOS- als Cisco NX-OS-software bieden een manier om statistieken te controleren van het verkeer dat wordt afgehandeld door de CPU. Dit gebeurt met  show ip traffic  commando. Deze opdracht kan worden gebruikt om de ontvangst en/of het genereren van ICMP Redirect-berichten door Layer 3-switch of -router te controleren.

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 de opdracht een paar keer uitshow ip trafficen controleer of de ICMP-redirect-tellers toenemen.

ethanolanalysator

Cisco NX-OS-software heeft een ingebouwde tool om verkeer van en flowing naar de switch-CPU vast te leggen, bekend als Ethanalyzer.

Opmerking: Raadpleeg voor meer informatie over Ethanalyzer Ethanalyzer op de Nexus 7000-handleiding voor probleemoplossing.

Afbeelding 6 toont scenario vergelijkbaar met dat op afbeelding 3. Hier wordt Netwerk X vervangen door 192.168.0.0/24 netwerk.

Afbeelding 6 - Ethanalyzer Capture uitvoeren

Ethanalyzer Capture uitvoeren

De host 10.0.0.100 verzendt een continue stroom van ICMP-echoverzoeken naar het IP-adres van bestemming 192.168.0.1. De host gebruikt Switch Virtual Interface (SVI) 10 van Nexus 7000 switch als de volgende stap naar extern netwerk 192.168.0.0/24. Voor demonstratiedoeleinden is de host geconfigureerd om ICMP Redirect-berichten te negeren.

Gebruik deze volgende opdracht om ICMP-verkeer vast te leggen dat is ontvangen en verzonden door de 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 uitvoer suggereren dat drie pakketten die in dit voorbeeld zijn gemarkeerd, tegelijkertijd zijn vastgelegd, 2018-09-15 23:45:40.128. De volgende is een uitsplitsing per pakket van deze pakketgroep

• Het eerste pakket is het ingress-gegevenspakket, dat in dit voorbeeld een ICMP Echo Request is.

2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) aanvraag

• Het tweede pakket is een ICMP Redirect-pakket, gegenereerd door een gateway. Dit pakket wordt teruggestuurd naar de host.

2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Omleiden voor host)

• Het derde pakket is het gegevenspakket dat wordt vastgelegd in de richting van uitgang, nadat het is gerouteerd door de CPU. Hoewel niet eerder getoond, heeft dit pakket zijn IP TTL verlaagd en checksum opnieuw berekend.

2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) aanvraag

Terwijl u door grote Ethanalyzer-opnamen navigeert die veel pakketten van verschillende typen en stromen hebben, kan het moeilijk zijn om ICMP Redirect-berichten te correleren met het gegevensverkeer dat ermee overeenkomt.

Richt u in deze situaties op ICMP Redirect-berichten om informatie op te halen over suboptimaal doorgestuurde verkeersstromen. ICMP Redirect-berichten bevatten de Internet header plus de eerste 64 bits van de oorspronkelijke datagramgegevens. Deze gegevens worden door de bron van het datagram gebruikt om het bericht aan het juiste proces te koppelen.

Gebruik Ethanalyzer packet capture tool met detail trefwoord om de inhoud van ICMP Redirect berichten weer te geven en vind IP-adres informatie 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, should be 0xcae1]
Identifier: 0xa01d
Sequence number: 36096 (0x8d00)

...

ICMP-omleidingen uitschakelen

Als het netwerkontwerp vereist dat de verkeersstroom wordt gerouteerd vanuit dezelfde Layer 3-interface waarop deze de switch of router is binnengegaan, is het mogelijk om te voorkomen dat de stroom door de processor wordt gerouteerd als u de ICMP-omleidingsfunctionaliteit op Layer 3-interface die ermee overeenkomt, uitschakelt.

Voor de meeste netwerken is het zelfs een goede gewoonte om ICMP-omleidingen proactief uit te schakelen op alle Layer 3-interfaces, zowel fysieke, zoals Ethernet-interface, en virtuele, zoals Port-Channel- en SVI-interfaces. Gebruik de opdracht Cisco NX-OS interface-levelno ip redirectsom ICMP-omleidingen op een Layer 3-interface uit te schakelen. Om te controleren of de ICMP Redirect-functionaliteit is uitgeschakeld:

• Zorg ervoor dat geen IP-omleidingen opdracht is toegevoegd aan de interface configuratie.

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 wordt weergegeven.

Nexus7000#show ip interface vlan 10 | include redirects
  IP icmp redirects: disabled

• Zorg ervoor dat de markering voor in-/uitschakelen van ICMP Redirect is ingesteld op 0 door de softwarecomponent 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 de markering voor het in- en uitschakelen van ICMP Redirect 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 doorstuurpad door netwerksegmenten met meerdere punten te optimaliseren. Aan het begin van het internet hielp een dergelijke optimalisatie om dure netwerkbronnen te beschermen, zoals linkbandbreedte en de CPU-cycli van routers. Naarmate de netwerkbandbreedte betaalbaarder werd en de relatief langzame, op de CPU gebaseerde pakketroutering evolueerde naar snellere Layer 3-pakketforwarding in speciale hardware-ASIC's, nam het belang van optimale gegevensdoorvoer door multi-point netwerksegmenten af. Standaard is de ICMP Redirect-functionaliteit ingeschakeld op elke Layer 3-interface. De pogingen om netwerkknooppunten op Ethernet-segmenten met meerdere punten te informeren over optimale doorstuurpaden worden echter niet altijd begrepen en opgevolgd door netwerkpersoneel. In netwerken met gecombineerd gebruik van verschillende doorstuurmechanismen, zoals statische routering, dynamische routering en op beleid gebaseerde routering, als u de ICMP-redirect-functionaliteit ingeschakeld laat en deze niet goed bewaakt, kan dit leiden tot ongewenst gebruik van de CPU van de doorvoerknooppunten om het productieverkeer af te handelen. Dit kan op zijn beurt aanzienlijke gevolgen hebben voor zowel de productieverkeersstromen als de stabiliteit van het controlevlak van de netwerkinfrastructuur.

Voor de meeste netwerken wordt het als een goede praktijk beschouwd om de ICMP Redirect-functionaliteit op alle Layer 3-interfaces in de netwerkinfrastructuur proactief uit te schakelen. Dit helpt om scenario's van productiegegevensverkeer te voorkomen die worden afgehandeld in CPU van Layer 3-switches en routers wanneer er een beter doorstuurpad is door netwerksegmenten met meerdere punten.