Traceroute — en zijn kleine broertje, ping — is een van de meest gebruikte tools in netwerktoepassingen. het oplossen van problemenHoe nuttig deze tool ook is, er zijn een paar belangrijke uitdagingen bij het gebruik ervan voor de veel complexere problemen van vandaag. Bedenk dat traceroute eind jaren 1980 werd ontwikkeld, toen netwerken veel eenvoudiger waren.
Alles was fysiek, point-to-point was helemaal in, en er waren minder protocollen om mee te werken. Switches werden vaak bridges genoemd, met LAN-naar-WAN-routers die van het ene gebouw naar het andere liepen. (Bedenk dat dit zes jaar vóór het internet bestond!) En wie herinnert zich nog 'Leased T1 Lines'? De goede oude tijd, om het zo maar te zeggen.
Dus, hoe houden dit soort antieke tools zich staande in de huidige softwaregedefinieerde en gevirtualiseerde wereld? Er moet toch wel een modernere manier zijn om problemen met moderne netwerken op te lossen? Jazeker, dus lees verder.
Om te beginnen, leren we meer over de traceroute-opdracht. Daarna bespreken we traceroute-fouten, beperkingen en meer.
De bronmachine (SRC) stuurt doorgaans drie probepakketten naar het bestemmings-IP-adres, te beginnen met de Time to Live (TTL) ingesteld op 1. Mensen denken ten onrechte dat het probepakkettype altijd ICMP is. In werkelijkheid hangt het af van het apparaat dat de traceroute genereert. Windows-besturingssystemen gebruiken vaak ICMP, terwijl Unix- en routingapparaten doorgaans UDP-berichten gebruiken naar tijdelijke poorten (poorten groter dan 1024 die geen bekende services zijn, zoals DNS, SMTP, WEB, enz.).
Wanneer elk Layer-3-apparaat het probepakket ontvangt, wordt de TTL verlaagd. Wanneer de TTL 0 bereikt, stuurt het ontvangende apparaat een ICMP-bericht vanaf de ontvangende interface: "TTL Expired". Zo herkent traceroute elke hop langs de route.
In de onderstaande afbeelding zouden 172.16.2.1 en 10.3.2.2 de adressen zijn die worden geretourneerd in de traceroute-resultaten.
Standaard rapporteert een traceroute het pad tussen punt A en B. De tegenovergestelde route vereist een tweede traceroute. Laten we bespreken waarom dit een beperking kan zijn.
Asymmetrische routing is gebruikelijk in moderne netwerken. Hierbij spelen veel routingprotocollen een rol, waaronder:
Afhankelijk van het algoritme dat voor hashing wordt gebruikt, zal het verkeer waarschijnlijk in elke richting een andere route volgen. Deze verschillende routes zijn moeilijk te detecteren met één enkele uitvoering van een traceroute-opdracht. Daarom is het moeilijk te bepalen waar de vertraging vandaan komt.
Zoals je hierboven kunt zien, neemt de vertraging aanzienlijk toe op deze specifieke hop. Maar waar zit de vertraging? Is het op de heen- of terugweg?
Als we nogmaals naar de bovenstaande traceroute kijken, is de enige verstrekte informatie:
Om hop zes te onderzoeken, moeten we een Telnet- of SSH-verbinding met de router tot stand brengen en bepalen welke interface aan dit specifieke IP-adres is gekoppeld. "Toon IP route 129.259.2.41" was mijn favoriete manier om dit te doen. Je kunt echter ook de IP-interface weergeven en de uitvoer doorsturen naar een parser… "Toon IP-interfaceoverzicht | in 129.150.2.41." U hebt een vervolgopzoekactie nodig om de uitgaande interface te identificeren. Bijvoorbeeld: "toon IP-route 192.41.37.40."
Bij ICMP-berichten wordt soms een grotere vertraging gemeld dan bij het verkeer. Dit komt vooral doordat er gebruik wordt gemaakt van langzame padverwerking in plaats van snelle padverwerking.
Wat is een langzaam pad? Dat is wanneer de router de pakketinhoud moet verwerken. Vrijwel elk pakket dat voor een apparaat bestemd is, wordt op deze manier verwerkt. De interne mechanismen van nieuwere routers bepalen welke pakketten ze verwerken, en geven daarbij prioriteit aan de pakketten die ze verwerken.
Ze verwerken eerst updates van het routingprotocol en vervolgens ICMP-berichten, wat het probleem verergert. Veel systemen gebruiken UDP-berichten. Het genereren van het ICMP TTL-verlopen-bericht heeft echter een lagere prioriteit. Het retourpad zal dan een ICMP-bericht zijn. Hierdoor zijn de vertragingsgegevens in de resultaten moeilijk te accepteren als echte problemen.
TIP: Wanneer een traceroute bij een bepaalde stap een sprong maakt en de daaropvolgende resultaten laag zijn, is dit vaak een teken dat de "trage" router een verwerkingsvertraging ervaart. Als het pad een sprong maakt en de daaropvolgende stappen worden verhoogd, betekent dit meestal dat er een vorm van wachtrij is vanwege congestie.
Nu we het pad naar een specifieke bestemming kennen, maar wat als we de extra hops langs het pad verder willen onderzoeken? Als een gebruiker de Telnet- of SSH-console gebruikt, moet hij of zij inloggen op elk apparaat. De traceroute-respons geeft alleen het IP-adres van de interface. In veel netwerken levert dit problemen op.
Beveiligingsbeleid vereist dat gebruikers Telnet of SSH gebruiken om toegang te krijgen tot het beheer-IP-adres. De specifieke interfaces die in de traceroute worden gerapporteerd, kunnen Telnet blokkeren, wat een handmatige zoekopdracht vereist om de beheerinterface van het apparaat met dat interface-adres te bepalen. Als u DNS-omzetting niet kunt gebruiken, kan dit vrijwel onmogelijk zijn. Bij een storing kan elke seconde tegen u tellen.
Zoals eerder vermeld, zijn multi-path routes met gelijke of ongelijke kosten tegenwoordig gangbaar in de meeste netwerken. Traceroute rapporteert alleen over het specifieke pad dat deel uitmaakte van de probe-berichten voor de aanvraag. De meest voorkomende traceroute-implementaties verzenden drie probe-pakketten met verschillende UDP-bestemmingspoorten. Hierdoor is het mogelijk dat in een ECMP-omgeving voor elke hop tot drie verschillende IP-adressen worden gerapporteerd. Het bijhouden van welk antwoord deel uitmaakt van welk pad kan lastig zijn.
Zoals we nu begrijpen, verlaagt traceroute de TTL-waarde in een IP-pakket en genereert ICMP-berichten waarvan de TTL is verlopen. Alleen Layer-3-apparaten verlagen de TTL. Hierdoor is er geen ingebouwde zichtbaarheid of functie om eenvoudig het Layer-2-pad te bepalen dat uit het resultaat is gehaald. De meeste bedrijfs- en datacenteromgevingen gebruiken een Layer-2-toegangsswitch voor het aggregeren van eindstations.
Sommige ontwerpen hebben een Layer-2 distributielaag voordat ze een core-router bereiken. De router voert de eerste Layer-3 routingfunctie uit, die kan rapporteren aan een traceroute-aanvraag.
Als er pakketverlies optreedt in de traceroute-uitvoer, kan dit de volgende oorzaken hebben:
Sommige problemen kun je alleen ontdekken door de Layer-2-elementen langs het pad te inspecteren. Om deze informatie te vinden, heb je het volgende nodig:
Dit proces kan erg tijdrovend zijn, vooral als CDP/LLDP niet is ingeschakeld in het netwerk of als de documentatie verouderd is.
De resultaten die u met een traceroute ziet, zijn de huidige status. Er is geen manier om te bepalen welk pad werd gebruikt toen het verkeer succesvol was (gisteren bijvoorbeeld). Bekijk de onderstaande traceroute. Het zou handig zijn om te weten wat hop vier was vóór de verandering, om het mogelijke probleem te kunnen isoleren.
Opmerking: Onze ervaring leert dat engineers op basis van de uitvoer van de bovenstaande traceroute-opdracht aannemen dat hop drie het probleem is. Dit is vaak niet het geval. Een gebruiker dient eerst in te loggen op het apparaat bij hop drie en te controleren of er een routingsingang naar de bestemming is. Zo ja, dan is het probleemapparaat vaak de volgende hop in de routingsingang. Voor een grondige analyse is het nuttig om de uitgangsinterface naar de volgende routingshop te controleren om de prestaties op interfaceniveau en de ACL-configuratie te verifiëren.
Wanneer ik een probleem met een traceroute-opdracht tegenkom, zie ik zo nu en dan een teken in de uitvoer dat me verrast. De onderstaande tabel is afkomstig uit Cisco's implementatie van traceroute. Een van de beperkingen van traceroute is dat ze misschien eenvoudig lijken, maar om te begrijpen wat er gebeurt, is over het algemeen meer onderzoek nodig.
Stel bijvoorbeeld dat ik de letter A ontvang in het traceroute-antwoord. Ik begrijp dat een toegangslijst de traceroute blokkeert, maar welke toegangslijst is dat? Om dit te bepalen, moet ik het volgende doen:
Dit proces kan lang duren en we maken ons altijd zorgen over de tijd bij het oplossen van problemen. Daarom zou een betere manier om toegang te krijgen tot deze informatie van onschatbare waarde zijn.
OPMERKING: Naar onze ervaring worden deze traceroute-foutmeldingen alleen weergegeven op basis van de inkomende interface. Zodra een pakket is ontvangen en vervolgens is doorgestuurd naar de volgende hop op het pad, krijgt u, als er een ACL op de uitgaande poort staat, simpelweg een *** voor de volgende hop. Dit betekent dat u extra stappen moet nemen om ervoor te zorgen dat de uitgaande interface bekend is en dat alle ACL's op die poort ook gevalideerd zijn.
NetBrain Bevat veel automatiserings- en visualisatiefuncties die nodig zijn voor het onderhoud van moderne netwerken. Het begrijpt softwaregedefinieerde, gevirtualiseerde en zelfs cloudnetwerken. Het communiceert continu met elk apparaat in het end-to-end netwerk en bouwt een realtime digitale tweeling van het netwerk, een exacte kopie van de details van elk apparaat.
Het kan realtime netwerken visualiseren en omvat een moderne vervanging voor traceroute, de A/B-padcalculatorDeze tool helpt ingenieurs dynamisch een gedetailleerd netwerkpad in kaart brengen tussen twee willekeurige punten in het netwerk.
Het ondersteunt mapping via onderlagen, overlagen en moderne technologieën, waaronder:
Tegelijkertijd houdt het rekening met geavanceerde protocollen zoals:
Eenmaal ingezet, is de gevisualiseerde structuur het perfecte platform voor automatisering zonder code van elke taak, groot en klein!
Geef uw teams de mogelijkheid om problemen op te lossen en de prestaties van applicaties te diagnosticeren op het niveau van de verkeersstroom met NetBrain's Applicatie zekerheid (AAM). Het:
Voorkom prestatieverslechtering van applicaties met NetBrain's no-code Intent-gebaseerde automatisering. NetBrain AAM beschermt de gebruikerservaring door: