Train route in MPLS-netwerk

Downloadopties

  • PDF     (491.9 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (438.6 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (462.3 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:25 september 2018
Document-id:200510

Inclusief taalgebruik

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.

Over deze vertaling

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.

Inleiding

Dit document beschrijft het Internet Control Message Protocol (ICMP) traceroute-gedrag in het netwerk Multiprotocol Label Switching (MPLS) en een snelle vergelijking met LSP-spoor.

Achtergrondinformatie

In IP-omgeving wordt elk knooppunt wanneer een pakje ontvangt en als de tijd om te leven (TTL) is verlopen, verwacht dat u "TTL Overschot" ICMP-foutbericht (Type=11, Code=0) genereert en naar het pakketbronadres stuurt. Dit concept wordt uitgebreid om het IP-pad van bron naar bestemming te traceren door UDP-pakketjes met TTL te verzenden vanaf 1. Er kan op worden gewezen dat de zeer basisvereisten voor deze functionaliteit zijn:

  • Bron-adres van het pakket is bereikbaar via de doorvoerknooppunten
  • ICMP is niet langs het pad gefilterd

In MPLS-omgeving is het mogelijk dat een doorvoerprovider LSR niet altijd bereikbaar is voor het bronadres en enige verbetering nodig heeft voor ICMP-verwerking in MPLS-domein. 

ICMP-Traceroute in MPLS-netwerk

Het standaardgedrag van elke LSR bij het ontvangen van een pakje met TTL=1 op het bovenste label volgt het traditionele IP-gedrag van het vallen van het pakje en het activeren van de ICMP-foutmelding. Als u het ICMP-bericht naar de bron wilt doorsturen, voert de LSR het volgende uit:

  • Buffer de labelstack van inkomend pakket (het pakket dat met TTL=1 wordt ontvangen)
  • ICMP-foutmelding met bron als eigen adres en bestemming als bronadres uit ontvangen pakket genereren.
  • Voeg alle labels toe vanaf de onderkant van labelstack (die eerder gebufferd was in stap 1) met TTL=255 behalve de bovenste.
  • Neem het bovenste label van de gebufferde labelstapel en voer lokale LFIB raadpleging uit om het label te ruilen en de bijbehorende volgende hop.
  • Voeg het nieuwe etiket aan de bovenkant van stapel toe met TTL=255 en stuur over.

Met deze benadering gaat de ICMP-foutmelding van doorvoerslang naar GRE en dan terug naar LER naar echte bron.

ICMP-tracering van PE naar Remote PE

Hier is een eenvoudig voorbeeld dat het gedrag verklaart wanneer het spoor van ICMP van PE aan verre PE binnen hetzelfde MPLS domein wordt geactiveerd:

200510-Trace-route-in-MPLS-network-00.jpeg

In deze topologie, wanneer ICMP traceroute van R2 naar 10.1.4.4 wordt geactiveerd, wordt het eerste pakket verzonden met TTL van 1. R3 op het ontvangen van het pakket zal de TTL tot 0 decrement en activeer ICMP generatiemechanisme.

200510-Trace-route-in-MPLS-network-01.jpeg

R3 zal de labelstack bufferen en ICMP-foutmelding genereren en de inkomende labelstack van de buffer in ICMP-lading opnemen. Het vult de IP-header verder met bronadres van de inkomende interface van het geëtiketteerde pakket, doeladres als de bron van het geëtiketteerde pakket. De TTL is ingesteld op 255. Hij duwt nu de labelstack van de buffer en raadt de LFIB-tabel aan om actie op het bovenste label door te sturen. In deze topologie is de ontvangen labelstack 17. Na het uitvoeren van een raadpleging in de LFIB-tabel, wordt label 17 omgewisseld met label 16 en wordt doorgestuurd naar Nexthop R6. R6 zal op zijn beurt het toplabel poppen en naar R4 doorsturen, waardoor IP de verpakking naar R2 terugstuurt.

Zoals het in de uitvoer van Tracoute op R2 kon worden opgemerkt, zal het inkomende etiket door elke hop langs het pad worden vermeld.

ICMP-tracering van CE naar Remote CE

Hier is een eenvoudig voorbeeld dat het gedrag verklaart wanneer het spoor van ICMP van CE aan verre CE over MPLS domein wordt geactiveerd:

200510-Trace-route-in-MPLS-network-02.jpeg

In deze topologie, wanneer ICMP traceroute van R1 (CE) aan 192.168.5.5 (afstandsbediening van CE) wordt geactiveerd, wordt het eerste pakket met TTL van 1 verzonden. Dit is normaal IP pakket en daarom volgt R2 het traditionele gedrag van het genereren van ICMP en het direct verzenden naar R1. Het tweede pakket verzonden met TTL=2 zal bij R3 verlopen.

200510-Trace-route-in-MPLS-network-03.jpeg

R3 zal de labelstack bufferen en ICMP-foutmelding genereren en de inkomende labelstack van de buffer in ICMP-lading opnemen. Het vult de IP-header verder met bronadres van de inkomende interface van het geëtiketteerde pakket, doeladres als de bron van het geëtiketteerde pakket. De TTL is ingesteld op 255. Hij duwt nu de labelstack van de buffer en raadt de LFIB-tabel aan om actie op het bovenste label door te sturen. In de bovenstaande topologie is de ontvangen labelstack {17, 18}. Na het uitvoeren van een raadpleging in de LFIB-tabel voor het toplabel, worden er 17 omgewisseld met label 16 en worden doorgestuurd naar Nexthop R6. R6 zal op zijn beurt het toplabel toevoegen en naar R4 doorsturen. R4 zal het VRF-label gebruiken om de VRF te identificeren en de verpakking naar R1 terug te sturen.

Zoals het in de uitvoer van Tracoute op R1 kon worden genoteerd, wordt de inkomende stapel van het etiket door elke hop langs het pad vermeld.

MPLS LSP-Traceroute in MPLS-netwerk

200510-Trace-route-in-MPLS-network-04.jpeg

In tegenstelling tot op ICMP gebaseerde traceroute, gebruikt LSP traceroute de machine die in RFC4379 wordt gedefinieerd. Het gebruikt IP/UDP insluiting met bestemmingsadres van verzoek ingesteld op loopback-adres (127.0.0.0/8-bereik). Verwacht wordt dat LSP Ping binnen hetzelfde MPLS-domein wordt geactiveerd en daarom wordt het antwoord rechtstreeks naar de Initiator gestuurd.

Wanneer LSP traceroute ("traceroute mpls ipv4 <FEC>") wordt geactiveerd vanuit een LSR, worden de gegevens over de te valideren FEC in een TLV opgenomen als "Target FEC Stack" in MPLS Echo-aanvraag. Dit bericht wordt met TTL op de labelstack verzonden vanaf 1. Any transit LSR bij het ontvangen van het pakket en als de TTL-overeenkomst verloopt, verwerkt u het IP-pakket, aangezien het doeladres een loopback-adres is. en punt naar CPU voor MPLS OAM-verwerking.

Responder zal naar keuze FEC-validatie uitvoeren door de label(s) te halen uit een labelstack van ontvangen MPLS Echo-aanvraag en FEC-gegevens van Target FEC Stack TLV om hetzelfde te valideren aan de hand van de informatie over het lokale besturingsplane. In het geval van overtrek zal Responder de downstreaminformatie zoals het uittredende label en downstreamadres van de buur enz. in een TLV opnemen als Downstream Mapping (DSMAP) TLV. (DSMAP wordt afgebroken door DMAP omdat het flexibeler is dan DSMAP).

LSP-rail geactiveerd van PE naar Remote PE

200510-Trace-route-in-MPLS-network-05.jpeg

In deze topologie wordt LSP-overtrekken van R2 geactiveerd om de LSP te valideren tot voorvoegsel 10.1.4.4/32. De TTL op het label wordt ingesteld van 1. R3 bij het ontvangen van het zal punt naar CPU voor OAM-verwerking.

200510-Trace-route-in-MPLS-network-06.jpeg

R3 antwoordt op R2 met MPLS Echo Reactie met DSMAP TLV met een uitgaand etiket 16 en aanvullende informatie zoals downstreambuurdetails. In tegenstelling tot ICMP-berichten zal MPLS Echo Reactie rechtstreeks worden verzonden van responder R3 naar Initiator R2.

Zoals het in de LSP traceroute uitvoer op R2 kon worden genoteerd, zal de uitgaande etiketstapel door elke hop langs het pad worden vermeld. Dit is verschillend van op ICMP gebaseerde traceroute waar het etiket in uitvoer vermeld in inkomende etiketstapel zal zijn.

LSP-rail geactiveerd van CE naar Remote CE

200510-Trace-route-in-MPLS-network-07.jpeg

Dit is van toepassing in CSC zoals scenario's waar MPLS tussen PE-CE is geactiveerd. Er zijn 2 uitdagingen bij het uitvoeren van LSP-sporen van CE naar externe CE via Carrier MPLS-domein, zoals hieronder:

  • LSP Echo-antwoord wordt rechtstreeks naar de Initiator gestuurd. responder MOET dus bereikbaar zijn voor Initiator. In bovenstaande topologie kan R3 geen bereikbaarheid voor R1 hebben zoals het in VRF is.
  • Voor elk etiket in een etiketstapel moeten er relevante FEC-details zijn opgenomen in Target FEC Stack voor validatie. De FEC die door Initiator wordt meegeleverd, is 1 terwijl PE op 2 labels drukt. In bovenstaande topologie stuurt R1 MPLS Echo-aanvraag met FEC= {192.168.5.5/32} en voegt label 28 in de stapel toe. Aangezien R2 swaps label 28 met {17, 27}, zal R3 het Aanvraag met 2 etiket in de stapel ontvangen terwijl 1 FEC in TLV de FEC validatie verwart.

RFC6424 definieert het concept "FEC Stack change TLV" om probleem 2 aan te pakken. Deze TLV wordt opgenomen in antwoord met de desbetreffende FEC als PUSH/POP die door de Initiator in een volgend Echo-verzoek kan worden opgenomen.

concept-ietf-mpls-lsp-ping-relais definieert het concept om Relay Node-adresstack in TLV te verzenden die door Responder kan worden gebruikt om de reactie door te geven, ook al is deze niet bereikbaar voor de Initiator.

200510-Trace-route-in-MPLS-network-08.jpeg

Deze 2 kwesties worden momenteel niet ondersteund in Cisco IOS® en dus zal LSP-overtrek van CE naar externe CE alleen een lijst maken van de inkomende PE en externe CE. Dit is alleen voor de volledigheid opgenomen.

Gerelateerde informatie

TAC Authored

Bijgedragen door Cisco-engineers

  • Nagendra Kumar Nainar
    Cisco TAC-ingenieur

Was dit document nuttig?

FeedbackFeedback

Contact Cisco