IP Path MTU-detectie en DLSw
Inhoud
Inleiding
De IBM-protocolreeks, DLSw, STUN en BSTUN maken een IP-sessiebuis van de ene router naar de andere. TCP wordt over het algemeen gebruikt als transportmethode tussen routers vanwege de betrouwbaarheid ervan. Dit document bevat informatie over de mogelijkheid van TCP om dynamisch de grootste MTU te ontdekken die op de sessiebuis kan worden gebruikt, waardoor fragmentatie wordt geminimaliseerd en de efficiëntie wordt gemaximaliseerd.
Voordat u begint
Conventies
Zie de Cisco Technical Tips Convention voor meer informatie over documentconventies.
Voorwaarden
Er zijn geen specifieke voorwaarden van toepassing op dit document.
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als u in een levend netwerk werkt, zorg er dan voor dat u de potentiële impact van om het even welke opdracht begrijpt alvorens het te gebruiken.
Achtergrondinformatie
Pad MTU Discovery (PMTD), zoals beschreven in RFC 1919, specificeert dat de standaardgrootte van een IP-pakket 576 is. De IP- en TCP-delen van het frame nemen 40 bytes weg, waarbij 536 bytes als de gegevenslading achterblijven. Deze ruimte is bekend als de maximale segmentgrootte of MSS. Sectie 3.1 van RFC191191 specificeert een grotere MSS die kan worden overeengekomen, en dit is precies wat het uitgeven van het ip pad-mtu-discovery bevel in een Cisco router doet. Wanneer deze opdracht is geconfigureerd en er een TCP-sessie wordt gestart, bevat het SYN-pakket uit de router een TCP-optie die een grotere MSS specificeert. Deze grotere MSS is de MTU van de uitgaande interface min 40 bytes. Als de MTU van de uitgaande interface 1500 bytes is, is de geadverteerde MSS 1460. Als de uitgaande interface een grotere MTU heeft, bijvoorbeeld Frame Relay met een MTU van 4096 bytes MTU, is de MSS 4096 bytes min 40 bytes van IP-informatie, en zal worden weergegeven in de opdrachtoutput van de show (max. gegevenssegment is 4056 bytes).
Het configureren van PMTD op de router heeft geen effect op bestaande TCP sessies die al vanaf/naar de router zijn ingesteld. PMTD werd geïntroduceerd in het IOS-niveau van 11.3.5T en in daaropvolgende releases van IOS werd het een optionele opdracht. Vóór IOS 11.3(5)T, was deze standaard ingeschakeld. Bovendien is PMTD automatisch wanneer de IP adressen in zelfde voorwerp zijn, erop wijzend dat zij direct op de zelfde media verbonden zijn.
Beide routers moeten zodanig zijn geconfigureerd dat PMTD correct werkt. Wanneer beide routers worden geconfigureerd, bevat SYN van de ene router naar de andere de optionele TCP-waardespreiding voor de hogere MSS. Het terugkerende SYN adverteert dan de hogere MSS waarde. Beide partijen adverteren dus met elkaar dat zij een groter MSS kunnen accepteren. Als slechts één router, router 1, de IP pad-mtu-discovery opdracht van IP heeft uitgevoerd, zal deze de grotere MSS en dus, router 2 kan naar router 1 a 1460 byte frame sturen. Router 2 zal nooit de grotere MSS adverteren en dus wordt router 1 vergrendeld om de standaardwaarden te verzenden.
DLSw met PMTD
In de IBM-reeks kunnen DLSw, STUN en BSTUN worden belast met het dragen van grote hoeveelheden gegevens via een TCP-sessie van router naar router. Het kan belangrijk en extreem voordelig zijn om PMTD uit te voeren, vooral gezien het feit dat deze standaard op 11.2 en eerdere IOS-niveaus was ingeschakeld. Volgens de RFC is het grootste frame standaard 576 bytes, minus 40 bytes voor IP/TCP-insluiting. DLSw gebruikt een andere 16 bytes voor insluiting. De eigenlijke gegevens die getransporteerd worden, met behulp van de standaard MSS, zijn 520 bytes. DLSw heeft ook de mogelijkheid om twee verschillende Logical Link Control 2 (LLC2)-pakketten in één TCP-kader over te brengen. Als twee werkstations elk een LLC2-frame verzenden, kan DLSw beide LLC2-frames naar de DLSw externe peer in één frame dragen. Door een grotere MSS te hebben, kunnen de TCP chauffeurs dit pigmentschema aanpassen. Het volgende zijn drie hoofdscenario's om de waarde van de path-mtu-discovery opdracht te illustreren.
Scenario 1 - ongewenste overhead
SDLC-apparaten worden meestal geconfigureerd voor een maximale hoeveelheid van 265 of 521 bytes gegevens in elk frame. Als de waarde 521 is en 3174 naar Router 1 een 521-byte SDLC frame verstuurt, zal Router 1 twee TCP-frames maken om dit naar DLSW peer Router 2 te transporteren. Het eerste frame zal 520 bytes van gegevens, 16 bytes van DLSw-informatie en 40 bytes IP-informatie bevatten voor een totaal van 576. Het tweede pakket bevat 1 bytes aan gegevens, 16 bytes van DLSw-informatie en 40 bytes van IP-informatie. Wanneer PMTD wordt gebruikt en uitgaande van een 1500 bytes MTU om een 1460 MSS te verkrijgen, werd router 1 door router 2 verteld dat Router 2 1460 bytes van gegevens kan ontvangen. Router 1 zal alle 521 bytes van SDLC gegevens naar router 2 verzenden in één pakket met 16 bytes van DLSw-informatie en 40 bytes van IP-informatie. Aangezien DLSw een proces-switched gebeurtenis is, is het CPU-gebruik om dit ene SDLC-frame te verwerken, gehalveerd. Bovendien hoeft router 2 niet te wachten tot het tweede pakket om het LLC2 frame te assembleren. Met, PMTD ingeschakeld, ontvangt Router 2 het gehele pakket en kan vervolgens de IP- en DLSW-informatie uit het pakket verwijderen en onverwijld naar de 3745 sturen.
Scenario 2 - Vertraging van out-of-order pakketten
In dit scenario zijn er twee IP-wolken beschikbaar met gelijke metriek voor werklastverdeling of redundantie. Het niet inschakelen van PMTD kan DLSw ernstig vertragen. Als PMTD niet is ingeschakeld, moet router 1 het frame van 521 bytes in twee TCP-pakketten assembleren, met 520 bytes van gegevens en de tweede met 1 bytes van gegevens. Als het eerste pakket de bovenste IP-cloud verlaat, is er een aanzienlijke waarschijnlijkheid dat deze na het tweede pakket arriveert wanneer het tweede pakket via de lagere, gelijkwaardige IP-cloud wordt verzonden. Dit genereert wat bekend staat als een out-of-order pakje. Inherent in de mogelijkheid van IP/TCP-protocol is de mogelijkheid om deze kwestie te beheren. Out-order pakketten worden opgeslagen in geheugen dat op de volledige stroom wacht om te komen en dan opnieuw geassembleerd worden. out-of-order pakketten zijn niet ongewoon, maar alle pogingen om deze te minimaliseren moeten worden ondernomen omdat deze gebeurtenis geheugen en CPU-bronnen gebruikt. Een grote hoeveelheid buiten bestellingen kan aanzienlijke vertraging op het TCP-niveau veroorzaken. Als de Layer 3/DLSw-sessie wordt uitgesteld, dan zal de LLC2/SDLC-sessie die over deze DLSw wordt overgedragen, hieronder lijden. Als PMTD in dit scenario is geactiveerd, wordt één 521-byte frame in één TCP-frame over één of IP-cloud verzonden. De ontvangende router hoeft alleen een TCP-frame op te nemen en af te kapselen.
PMTD heeft geen relatie met het grootste frame dat wordt geadverteerd voor eindstation in SNA-omgevingen. Dit omvat het Grootste frame (LF) in het Routing Information Field (RIF) op Token-Ring. PMTD bepaalt strikt de hoeveelheid gegevens die in één TCP-kader kan worden ingekapseld. LLC2 en SDLC hebben niet de overeenkomende pakketten van het vermogensfragment, maar IP/TCP wel. Een groot SNA kader kan worden gesegmenteerd aangezien het in TCP wordt ingekapseld. Deze gegevens worden gedecapsulEERD op de externe DLSw-router en opnieuw gepresenteerd als niet-gefragmenteerde SNA-gegevens.
Scenario 3 - Snellere LLC2-connectiviteit en -doorvoersnelheid
In dit scenario, hebben de 3174 en het werkstation sessies door de 3745 TIC aan de Mainframe, als beide apparaten gegevens verzenden bestemd voor de gastheer, is het mogelijk TCP beide LLC2 frames in één pakket te plaatsen. Zonder PMTD is dit niet mogelijk als de gecombineerde gegevens van de twee frames 521 bytes of hoger zijn. In dat geval moet de TCP-software elk pakket afzonderlijk verzenden. Als bijvoorbeeld de 3174 en het werkstation op ongeveer hetzelfde moment een frame verzenden en elk van deze pakketten 400 bytes gegevens heeft, ontvangt de router elk frame en buffert deze. De router moet nu elk van deze 400 byte gegevensstromen in afzonderlijke TCP-pakketten insluiten voor transmissie naar de peer.
Met een PMTD die en een MSS van 1460 wordt aangenomen, ontvangt de router de twee LLC2-pakketten en buffers. Het kan nu beide in één pakje insluiten. Dit ene TCP-pakket bevat 40 bytes IP-informatie, 16 bytes DLSw-informatie voor de eerste DLSw-circuitbedrading, de 400 bytes van gegevens, een andere 16 bytes van gegevens voor de tweede DLSw-circuitbedrading en de andere 400 bytes van gegevens. Bij dit specifieke scenario worden twee apparaten gebruikt en dus twee DLSw-circuits. Met PMTD kan DLSw efficiënter worden geschaald naar hogere aantallen DLSw-circuits. Veel spraak-hub-netwerken vereisen honderden externe sites, elk met een of twee SNA-apparaten, die in een centrale site-router werken die aansluit op een OSA of FEP die toegang biedt tot de host-toepassingen. PMTD biedt TCP- en DLSw de mogelijkheid om aan grotere vereisten te schalen zonder gebruik te maken van router CPU- en geheugenbronnen en sneller transport te bieden.
Opmerking: Er is een softwarebug aangetroffen in het einde van 12.1(5)T en opgelost in 12.2(5)T, waar PMTD niet werkte via een VPN-tunnel (Virtual Private Network). Dit softwaredefect is CSCdt49552 (alleen geregistreerde klanten).
PMTD voor DLSW controleren
Geef de show TCP opdracht uit.
havoc#show tcp Stand-alone TCP connection to host 10.1.1.1 Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 30.1.1.1, Local port: 11044 Foreign host: 10.1.1.1, Foreign port: 2065 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) TCP driver queue size 0, flow controlled FALSE Event Timers (current time is 0xA18A78): Timer Starts Wakeups Next Retrans 3 0 0x0 TimeWait 0 0 0x0 AckHold 0 0 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 2 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 iss: 3215333571 snduna: 3215334045 sndnxt: 3215334045 sndwnd: 20007 irs: 3541505479 rcvnxt: 3541505480 rcvwnd: 20480 delrcvwnd: 0 SRTT: 99 ms, RTTO: 1539 ms, RTV: 1440 ms, KRTT: 0 ms minRTT: 24 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: higher precedence, retransmission timeout Datagrams (max data segment is 536 bytes): Rcvd: 30 (out of order: 0), with data: 0, total data bytes: 0 Sent: 4 (retransmit: 0, fastretransmit: 0), with data: 2, total data bytes: 473
Deze weergave wordt geïdentificeerd als een DLSw TCP-sessie omdat een van de poorten in de TCP-sessie 2065 is. Bijna de onderkant van het uitvoerbestand is het maximale gegevenssegment 536 bytes. Deze waarde wijst erop dat de externe DLSw peer-router van 10.1.1.1 niet de opdracht ip pad-mtu-discovery heeft uitgevoerd. De bytewaarde van 536 vertegenwoordigt al de 40 bytes van IP informatie in een IP frame. Deze bytewaarde van 536 neemt geen rekening met de 16 bytes van DLSw informatie die aan een TCP-pakket wordt toegevoegd dat SNA-verkeer bevat.
Als de opdracht ip pad-mtu-discovery uitvoeren is het max-gegevenssegment nu 1460. Daarnaast geeft de opdrachtoutput van de show tcp aan dat het pad mtu onmiddellijk vóór de max verklaring van het gegevenssegment geschikt is. De uitgaande interface heeft een MTU van 1500 bytes. MTU is gelijk aan 1500 bytes min 40 bytes van IP-informatie is 1460 bytes. DLSw gebruikt nog eens 16 bytes. Daarom kan tot 1444 bytes frame van LLC2 of SDLC in één TCP-frame worden verzonden.
havoc#show tcp Stand-alone TCP connection to host 10.1.1.1 Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 30.1.1.1, Local port: 11045 Foreign host: 10.1.1.1, Foreign port: 2065 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) TCP driver queue size 0, flow controlled FALSE Event Timers (current time is 0xA6DA58): Timer Starts Wakeups Next Retrans 4 0 0x0 TimeWait 0 0 0x0 AckHold 1 0 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 3 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 iss: 3423657490 snduna: 3423657976 sndnxt: 3423657976 sndwnd: 19995 irs: 649085675 rcvnxt: 649085688 rcvwnd: 20468 delrcvwnd: 12 SRTT: 124 ms, RTTO: 1405 ms, RTV: 1281 ms, KRTT: 0 ms minRTT: 24 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: higher precedence, retransmission timeout, path mtu capable Datagrams (max data segment is 1460 bytes): Rcvd: 5 (out of order: 0), with data: 1, total data bytes: 12 Sent: 6 (retransmit: 0, fastretransmit: 0), with data: 3, total data bytes: 485
Feedback