Tecnologias IBM : Data-Link Switching (DLSw) e Data-Link Switching Plus (DLSw+)

IP Path MTU Discovery e DLSw

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

O conjunto de protocolos IBM, DLSw, ATURDE, e o BSTUN estabelece uma tubulação da sessão IP de um roteador a outro. O TCP é de uso geral como o método do transporte entre roteadores devido a sua confiança. Este documento fornece a informação na capacidade do TCP para descobrir dinamicamente o MTU o maior que pode ser usado na tubulação da sessão, que minimiza a fragmentação e maximiza a eficiência.

Antes de Começar

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Pré-requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Informações de Apoio

O Path MTU Discovery (PMTD), como descrito no RFC 1191, especifica que o tamanho do byte do padrão de um pacote IP é 576. As parcelas IP e TCP do quadro ocupam 40 bytes que deixam 536 bytes como o payload de dados. Este espaço é sabido como o Maximum Segment Size ou o MSS. A seção 3.1 do RFC1191 especifica um MSS maior possa ser negociado, e este é exatamente o que emitir o comando ip tcp path-mtu-discovery faz em um roteador Cisco. Quando este comando é configurado e uma sessão de TCP está começada, o pacote SYN fora do roteador contém uma opção de TCP que especifica um MSS maior. Este MSS maior é o MTU da interface externa menos 40 bytes. Se o MTU da interface externa é 1500 bytes, o MSS anunciado é 1460. Se a interface externa tem um MTU maior, por exemplo, Frame Relay com 4096 um byte MTU, o MSS será o menos bytes 4096 40 bytes da informação IP, e estará indicado na saída do comando show tcp (o segmento de dados máximo é 4056 bytes).

Configurar o PMTD o no roteador não tem nenhum efeito nas sessões de TCP existentes já estabelecidas desde/até o roteador. O PMTD foi introduzido no nível 11.3.5T IO, e nas versões subsequente dos IO, assentou bem em um comando opcional. Antes de IO 11.3(5)T, estava ligada à revelia. Adicionalmente, o PMTD é automático quando os endereços IP de Um ou Mais Servidores Cisco ICM NT estão na mesma sub-rede, indicando eles é anexado diretamente nos mesmos media.

Ambo o Roteadores deve ser configurado para que o PMTD trabalhe corretamente. Quando ambo o Roteadores é configurado, o SYN de um roteador ao outro contém o valor opcional TCP que anuncia o MSS mais alto. O SYN de retorno anuncia então o valor mais alto MSS. Assim, os ambos os lados anunciam aos outro que podem aceitar um MSS maior. Se somente um roteador, roteador1, tem o comando ip tcp path-mtu-discovery configurado, anunciará o MSS maior e assim, o roteador2 pode enviar ao roteador1 um frame de bytes 1460. O roteador2 nunca anunciará o MSS maior, e o roteador1 é travado assim em enviar os valores padrão.

DLSw com PMTD

Na suite IBM, DLSw, ATURDE, e o BSTUN pode ser encarregado para levar grandes quantidades de dados sobre uma sessão de TCP do roteador ao roteador. Pode ser importante e extremamente benéfico executar o PMTD, considerando especialmente que esteve permitido à revelia em 11.2 e em níveis prévios IO. Conforme o RFC, o quadro o maior é 576 bytes à revelia, menos 40 bytes para o encapsulamento IP/TCP. DLSw usa outro 16 bytes de encapsulamento. Os dados reais que estão sendo transportados, usando o padrão MSS, são 520 bytes. DLSw igualmente tem a capacidade de levar dois Logical Link Control diferentes 2 pacotes (LLC2) em um quadro TCP. Se duas estações de trabalho cada um enviam um quadro LLC2, DLSw pode levar ambos os quadros LLC2 ao peer remoto de DLSw em um quadro. Tendo um MSS maior, os Driver TCP podem acomodar este esquema de reboque. Os seguintes são três cenários principais para ilustrar o valor do comando path-mtu-discovery.

Encenação 1 - Carga adicional indesejada

/image/gif/paws/41982/Scenario1.gif

Os dispositivos SDLC serão configurados geralmente para um maxdata de 265 ou 521 bytes de dados em cada quadro. Se o valor é 521 e os 3174 enviam ao roteador1 um quadro de 521 bytes SDLC, o roteador1 fará dois quadros TCP para transportar este ao roteador de peer 2. DLSW. O primeiro quadro conterá 520 bytes de dados, 16 bytes da informação de DLSw, e 40 bytes da informação IP para um total de 576 bytes. O segundo pacote conterá 1 byte de dados, 16 bytes da informação de DLSw, e 40 bytes da informação IP. Quando o PMTD é usado e de suposição 1500 um byte MTU para obter uns 1460 MSS, o roteador1 esteve dito pelo roteador2 que o roteador2 pode receber 1460 bytes de dados. O roteador1 enviará todos os 521 bytes de dados SDLC ao roteador2 em um pacote com 16 bytes da informação de DLSw e 40 bytes da informação IP. Desde que DLSw é um evento comutado processo, usando o PMTD, a utilização CPU para processar este quadro um SDLC foi partido ao meio. Adicionalmente, o roteador2 não tem que esperar o segundo pacote para montar o quadro LLC2. Com, o PMTD permitido, roteador2 recebe o pacote inteiro e pode então remover o IP e a informações de DLSW do pacote e enviá-la aos 3745 sem demora.

Encenação 2 - Atraso dos pacotes estragados

/image/gif/paws/41982/Scenario2.gif

Nesta encenação, há duas nuvens IP disponíveis com medidor igual para a função de balanceamento de carga ou a Redundância. Não permitir o PMTD pode retardar DLSw severamente. Sem PMTD permitido, o roteador1 deve montar o quadro do 521-byte em dois pacotes-um TCP com 520 bytes de dados e os segundos com 1 byte de dados. Se o primeiro pacote atravessa a nuvem IP da parte superior, há uma probabilidade que significativa chegará após o segundo pacote se o segundo pacote é enviado através do mais baixo, nuvem IP dos custos iguais. Isto gera o que é sabido como um pacote estragado. Inerente na capacidade de protocolo IP/TCP é a capacidade para controlar esta edição. Os pacotes estragados são armazenados na memória que espera o córrego inteiro para chegar e para ser remontado então. Os pacotes estragados não são raros, contudo, todas as tentativas de minimizá-los devem ser feitas como este evento utilizam a memória e os recursos do CPU. Uma grande quantidade de para fora--ordens pode causar o atraso significativo a nível TCP. Se a sessão layer3/DLSw é atrasada, a seguir a sessão LLC2/SDLC que está sendo levada sobre este DLSw sofrerá subseqüentemente. Se o PMTD é permitido nesta encenação, um único quadro do 521-byte está enviado em um quadro TCP sobre uma ou outra nuvem IP. O buffer de recepção da necessidade do roteador somente e de-encapsula um quadro TCP.

O PMTD não tem nenhum relacionamento o quadro o maior à estação final anunciada à estação final nos ambientes de SNA. Isto inclui o quadro o maior (LF) no campo de informação de roteamento (RIF) no token ring. O PMTD dita restritamente a quantidade de dados que podem ser encapsulados em um quadro TCP. LLC2 e o SDLC não têm os pacotes de fragmento da capacidade, contudo, o IP/TCP faz. Um grande quadro SNA pode ser segmentado como ele é encapsulado no TCP. Estes dados são descapsulado no roteador DLSw remoto, e apresentado outra vez como dados NON-fragmentados SNA.

Encenação 3 - Conectividade LLC2 e taxa de transferência mais rápidas

/image/gif/paws/41982/Scenario3.gif

Nesta encenação, os 3174 e a estação de trabalho têm sessões com os 3745 TIC à unidade central, se ambos os dispositivos enviam dados destinados para o host, ele são TCP possível podem pôr ambos os quadros LLC2 em um pacote. Sem PMTD, isto não é possível se os dados combinados dos dois quadros são 521 bytes ou maiores. Em tal caso, o software TCP precisará de enviar separadamente cada pacote. Por exemplo, se os 3174 e a estação de trabalho enviam um quadro aproximadamente no mesmo tempo e cada um destes pacotes tem 400 bytes de dados, o roteador recebe e protege cada quadro. O roteador agora deve encapsular cada um destes 400 fluxos de dados do byte em pacotes de TCP separados para a transmissão ao par.

Com o PMTD permitido e que supõe um MSS de 1460, o roteador recebe e protege os dois pacotes LLC2. Poderá agora encapsular ambos em um pacote. Este um pacote de TCP conterá 40 bytes da informação IP, 16 bytes da informação de DLSw para o primeiro circuito de DLSw que emparelha-se, os 400 bytes de dados, outros 16 bytes de dados para o segundo circuito de DLSw que emparelha-se, e outros 400 bytes de dados. Este cenário particular usa dois dispositivos e assim, dois circuitos de DLSw. O PMTD permite que DLSw escale a uns números mais altos de circuitos de DLSw mais eficientemente. Muitas redes do spoke-hub exigem centenas de locais remotos, cada um com os um ou dois dispositivos SNA, espreitando em um roteador de site central que conecta a um OSA ou a um FEP que fornecem o acesso aos aplicativos do host. O PMTD dá o TCP e o DLSw a capacidade para escalar às exigências maiores sem sobre a utilização do CPU de roteador e dos recursos de memória assim como o fornecimento de um transporte mais rápido.

Nota: Havia um Bug de Software encontrado em 12.1(5)T atrasado e resolvido em 12.2(5)T onde o PMTD não estava trabalhando sobre um túnel do Virtual Private Network (VPN). Este defeito do software é CSCdt49552 (clientes registrados somente).

Verificando o PMTD para o DLSW

Emita o comando show tcp.

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

Este indicador é identificado como uma sessão de DLSw TCP porque uma das portas na sessão de TCP é 2065. Perto da parte inferior da saída é o segmento de dados máximo é 536 bytes. Este valor indica que o roteador de peer remoto de DLSw de 10.1.1.1 não tem o comando ip tcp path-mtu-discovery configurado. O valor de byte 536 já esclarece os 40 bytes da informação IP em um quadro IP. Este valor de byte 536 não esclarece os 16 bytes da informação de DLSw que seria adicionado a um pacote de TCP que leva o tráfego SNA.

Com o comando ip tcp path-mtu-discovery configurado, o segmento de dados máximo é agora 1460. Adicionalmente, a saída do comando show tcp indica o MTU do trajeto capaz imediatamente antes da indicação de segmento de dados máxima. A interface externa tem um MTU de 1500 bytes. O menos bytes dos iguais 1500 MTU 40 bytes da informação IP é 1460 bytes. DLSw usará outro 16 bytes. Consequentemente, o frame de bytes até 1444 de LLC2 ou de SDLC pode ser transmitido em um quadro TCP.

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 

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 41982