IntroductionEst documento descreve como funciona a fragmentação de IPv4 e a Descoberta da unidade máxima de transmissão do caminho (PMTUD), bem como discute alguns cenários que envolvem o comportamento da PMTUD com diferentes combinações de túneis IPv4. O uso generalizado atual de túneis IPv4 na Internet colocou em destaque os problemas que envolvem a fragmentação de IPv4 e a PMTUD. Show
Fragmentação e remontagem de IPv4O protocolo IPv4 foi projetado para uso em uma grande variedade de links de transmissão. Embora o comprimento máximo de um datagrama IPv4 seja 65535, a maioria dos links de transmissão impõe um limite menor de comprimento máximo do pacote, chamado MTU. O valor da MTU depende do tipo do link de transmissão. O design do IPv4 comporta diferenças de MTU, pois permite aos roteadores fragmentarem datagramas IPv4 conforme a necessidade. A estação receptora é responsável pela remontagem dos fragmentos no datagrama IPv4 original de tamanho completo. A fragmentação de IPv4 envolve quebrar um datagrama em um número de peças que podem ser remontadas posteriormente. A origem, o destino, a identificação, o tamanho total e os campos de deslocamento do fragmento de IPv4, juntamente com os sinalizadores de "mais fragmentos" e "não fragmentar" no cabeçalho do IPv4, são usados para fragmentação e remontagem de IPv4. Para obter mais informações sobre a mecânica da fragmentação de IPv4 e da remontagem, consulte RFC 791 Esta imagem mostra o layout de um cabeçalho IPv4.
A identificação é de 16 bits e é um valor atribuído pelo remetente de um datagrama IPv4 para ajudar na remontagem dos fragmentos de um datagrama. O deslocamento do fragmento é de 13 bits e indica onde um fragmento pertence no datagrama de IPv4 original. Esse valor é um múltiplo de oito bytes. No campo de sinalizadores de cabeçalho IPv4, existem três bits para sinalizadores de controle. É importante notar que o bit "não fragmentar" (DF) desempenha um papel central na PMTUD, porque determina se um pacote pode ou não ser fragmentado. O bit 0 é reservado e sempre definido como 0. O bit 1 é o bit DF (0 = "pode fragmentar", 1 = "não fragmentar"). O Bit 2 é o bit MF (0 = "último fragmento", 1 = "mais fragmentos").
O próximo gráfico mostra um exemplo de fragmentação. Se você somar todos os comprimentos de fragmentos IPv4, o valor excederá em 60 o comprimento do datagrama IPv4 original. O motivo pelo qual o comprimento total é aumentado em 60 é porque três cabeçalhos IPv4 adicionais foram criados, um para cada fragmento após o primeiro fragmento. O primeiro fragmento tem um deslocamento de 0, o comprimento desse fragmento é de 1.500; Isso inclui 20 bytes para o cabeçalho IPv4 original ligeiramente modificado. O segundo fragmento tem um deslocamento de 185 (185 x 8 = 1.480), o que significa que a parte de dados desse fragmento inicia em 1.480 bytes no datagrama IPv4 original. O comprimento desse fragmento é de 1.500; Isso inclui o cabeçalho IPv4 adicional criado para esse fragmento. O terceiro fragmento tem um deslocamento de 370 (370 x 8 = 2.960), o que significa que a parte de dados desse fragmento inicia em 2.960 bytes no datagrama IPv4 original. O comprimento desse fragmento é de 1.500; Isso inclui o cabeçalho IPv4 adicional criado para esse fragmento. O quarto fragmento tem um deslocamento de 555 (555 x 8 = 4.440), o que significa que a parte de dados desse fragmento inicia em 4.440 bytes no datagrama IPv4 original. O comprimento desse fragmento é de 700 bytes; Isso inclui o cabeçalho IPv4 adicional criado para esse fragmento. O tamanho do datagrama IPv4 original só pode ser determinado quando o último fragmento for recebido. O deslocamento do fragmento no último fragmento (555) fornece um deslocamento de dados de 4.440 bytes para o datagrama IPv4 original. Se você adicionar os bytes de dados do último fragmento (680 = 700-20), totalizará 5.120 bytes, que é a porção de dados do datagrama IPv4 original. Em seguida, a adição de 20 bytes para um cabeçalho IPv4 é igual ao tamanho do datagrama IPv4 original (4.440 + 680 + 20 = 5140), conforme mostrado nas imagens.
Problemas com fragmentação de IPv4Há vários problemas que tornam a fragmentação de IPv4 indesejável. Há um pequeno aumento na sobrecarga de CPU e memória para fragmentar um datagrama de IPv4. Isso continua verdadeiro para o remetente e para um roteador no caminho entre o remetente e o receptor. A criação de fragmentos simplesmente envolve a criação de cabeçalhos de fragmento e a cópia do datagrama original nos fragmentos. Isso pode ser feito de forma bastante eficiente, porque todas as informações necessárias para criar os fragmentos estão imediatamente disponíveis. A fragmentação provoca mais “overhead” para o destinatário durante a remontagem dos fragmentos, porque o destinatário deve alocar memória para os fragmentos de chegada e agrupá-los novamente em um datagrama, depois do recebimento de todos os fragmentos. A remontagem em um host não é considerada um problema, porque o host possui os recursos de memória e o tempo para se dedicar a essa tarefa. Porém, a remontagem é muito ineficiente em um roteador, cuja principal função é encaminhar pacotes o mais rápido possível. Um roteador não é projetado para reter os pacotes por qualquer período. Além disso, um roteador que faz a remontagem escolhe o maior buffer disponível (18k) com o qual deseja trabalhar, porque ele só saberá o tamanho do pacote IPv4 original quando o último fragmento for recebido. Outro problema da fragmentação envolve o modo de manuseio dos fragmentos descartados. Se um fragmento de um datagrama IPv4 for descartado, então todo o datagrama IPv4 original deverá ser reenviado e também será fragmentado. Você verá um exemplo disso com o NFS (Network File System). NFS, por padrão, tem um tamanho de bloco de leitura e gravação de 8192, então um datagrama IPv4/UDP de NFS é de aproximadamente 8.500 bytes (incluindo cabeçalhos NFS, UDP e IPv4). Uma estação de envio, ligada a uma Ethernet (MTU 1500) , deve fragmentar o datagrama de 8.500 bytes em seis pedaços; cinco fragmentos de 1.500 bytes e um fragmento de 1.100 bytes. Se qualquer um dos seis fragmentos for descartado por causa de um link congestionado, o datagrama original completo precisará ser retransmitido, o que significa que mais seis fragmentos serão criados. Caso esse link descarte um a cada seis pacotes, é baixa a probabilidade de transferência de quaisquer dados de NFS, já que pelo menos um fragmento IPv4 seria descartado em cada datagrama IPv4 iginal de 8.500 bytes de NFS. Os firewalls que filtram ou manipulam pacotes baseados nas informações da Camada 4 (L4) a Camada 7 (L7) no pacote podem ter dificuldade em processar fragmentos IPv4 corretamente. Se os fragmentos IPv4 estiverem fora de ordem, um firewall poderá bloquear os fragmentos não iniciais, pois não carregam as informações que corresponderiam ao filtro de pacote. Isso significaria que o datagrama IPv4 original não pode ser recomposto pelo host de recebimento. Se o firewall estiver configurado para permitir fragmentos não iniciais com informações insuficientes para corresponder corretamente ao filtro, poderá ocorrer um ataque de fragmento não inicial pelo firewall. Além disso, alguns dispositivos de rede (como Mecanismos de Switch de Conteúdo) direcionam os pacotes de acordo com as informações de L4 a L7, e se um pacote abranger vários fragmentos, o dispositivo pode ter dificuldade em aplicar as políticas. Evitar fragmentação de IP: O que o MSS TCP faz e como ele funcionaO tamanho máximo de segmento TCP (MSS) define o volume máximo de dados que um host deseja aceitar em um único conjunto de dados TCP/IPv4. Este datagrama de TCP/IPv4 pode ser fragmentado na camada de IPv4. O valor MSS é enviado como uma opção de cabeçalho TCP somente em segmentos TCP SYN. Cada lado de uma conexão TCP relata seu valor MSS para o outro lado. Ao contrário do que se acredita, o valor MSS não é negociado entre os hosts. O host remetente é necessário para limitar o tamanho dos dados em um único segmento TCP para um valor menor ou igual ao MSS relatado pelo host destinatário. Originalmente, o MSS mostrava o tamanho de um buffer (maior ou igual a 65.496 bytes) alocado em uma estação receptora para armazenar os dados TCP contidos em um único datagrama IPv4. O MSS foi o máximo segmento (pedaço) de dados que o receptor TCP estava disposto a aceitar. Esse segmento TCP poderia ser tão grande quanto 64 K (o tamanho máximo do datagrama IPv4) e poderia ser fragmentado na camada IPv4 para transmissão pela rede ao host de destino. O host receptor remontaria o datagrama de IPv4 antes de ele enviar o segmento TCP completo para a camada de TCP. Aqui estão algumas situações que mostram como os valores de MSS são definidos e usados para os tamanhos de segmento TCP limite e, portanto, tamanhos de datagrama IPv4. O cenário 1 ilustra a maneira que o MSS foi implementado pela primeira vez. O Host A tem um buffer de 16K e o Host B um buffer de 8K. Eles enviam e recebem seus valores de MSS e ajustam o MSS de envio para enviar dados um ao outro. Observe que o Host A e o Host B precisarão fragmentar os datagramas IPv4 maiores do que a interface MTU, mas ainda assim menores que o MSS enviado, porque a pilha TCP poderia transmitir 16K ou 8K bytes de dados para a pilha de IPv4. No caso do Host B, os pacotes poderiam ser fragmentados duas vezes, uma vez para chegar à LAN de Token Ring e, novamente, para chegar à LAN de Ethernet. Cenário 1
Para ajudar a evitar fragmentação de IPv4 nos endpoints da conexão de TCP, a seleção do valor MSS foi trocada para o tamanho de buffer mínimo e para a MTU da interface de saída (- 40). Os números de MSS são menores que os números de MTU de 40 bytes porque o MSS é apenas o tamanho de dados de TCP, não incluindo o cabeçalho IPv4 de 20 bytes e o cabeçalho TCP de 20 bytes. O MSS tem como base os tamanhos do cabeçalho padrão; a pilha de remetente deve subtrair os valores apropriados para o cabeçalho IPv4 e o cabeçalho TCP, dependendo de quais opções de IPv4 ou TCP são usadas. Agora, o MSS faz com que cada host compare primeiro a interface MTU de saída com o próprio buffer e escolha o menor valor como o MSS a ser enviado. Os hosts compararão o tamanho MSS recebido com base em sua própria MTU de interface e escolherão novamente o menor dos dois valores. O cenário 2 ilustra esta etapa adicional executada pelo remetente, a fim de evitar a fragmentação nos fios locais e remotos. Observe como o MTU da interface de saída é considerado por cada host (antes dos host trocarem entre si os valores de MSS) e como isso ajuda a evitar a fragmentação. Cenário 2
1460 é o valor escolhido por ambos os hosts como o MSS de envio de um para o outro. Muitas vezes, o valor do MSS de envio será o mesmo em cada extremidade de uma conexão TCP. No cenário 2, a fragmentação não ocorre nos endpoints de uma conexão TCP, porque os hosts consideram os dois MTUs de interface de saída. É possível que os pacotes ainda sejam fragmentados na rede, entre os roteadores A e B, se encontrarem um enlace com uma MTU inferior à das interfaces de saída dos hosts. O que é PMTUD?Conforme descrito anteriormente, o MSS de TCP se encarrega da fragmentação em dois endpoints de uma conexão TCP, mas não interfere quando há um link de MTU menor no meio, entre esses dois endpoints. O PMTUD foi desenvolvido para evitar a fragmentação no caminho entre os endpoints. Ele é usado para determinar dinamicamente o MTU mais baixo ao longo do caminho, da origem de um pacote até o destino. Note: O PMTUD é compatível somente com TCP e UDP. Outros protocolos não são compatíveis. Se o PMTUD for ativado em um host, o que quase sempre ocorre, todos os pacotes TCP e UDP provenientes do host terão o bit DF definido. Quando um host envia um pacote de dados MSS completo com o conjunto de bits DF, o PMTUD reduz o valor do MSS de envio para a conexão, caso ele receba a informação de que o pacote precisa de fragmentação. Um host geralmente "lembra" o valor de MTU para um destino, pois ele cria uma entrada de "host" (/32) em sua tabela de roteamento com esse valor MTU. Se um roteador tentar encaminhar um datagrama IPv4 com o conjunto de bits DF em um link que tem um MTU menor que o tamanho do pacote, o roteador descarta o pacote e retornará uma mensagem de Internet control message protocol (ICMP) "Destino inacessível" para a origem do datagrama IPv4, com o código que indica "fragmentação necessária e DF definido" (tipo 3, código 4). Quando a estação de origem recebe a mensagem do ICMP, diminuirá o MSS de envio e, quando o TCP retransmitir o segmento, usará o menor tamanho de segmento. Este é um exemplo de uma mensagem ICMP de "fragmentação necessária e DF definido" que você pode ver em um roteador após o comando debug ip icmp ser ativado: ICMP: dst (10.10.10.10) frag. needed and DF set unreachable sent to 10.1.1.1 Este diagrama mostra o formato do cabeçalho de ICMP de uma mensagem "fragmentação necessária e DF definido" "Destino inacessível".
De acordo com RFC 1191, um roteador que retorna uma mensagem ICMP indicando "fragmentação necessária e DF definido" deve incluir o MTU da rede de próximo salto nos 16 bits de ordem inferior do campo de cabeçalho adicional de ICMP, rotulado como "não utilizado" na especificação do ICMP RFC 792. As implementações iniciais do RFC 1191 não forneceram as informações de MTU do próximo salto. Mesmo quando essa informação tiver sido fornecida, alguns hosts vão ignorá-la. Para esse caso, o RFC 1191 também contém uma tabela que lista os valores sugeridos que devem ser usados para diminuir o MTU durante o PMTUD. Ele é usado por hosts para chegar com mais rapidez a um valor razoável para o MSS de envio conforme mostrado na imagem.
O PMTUD é executado continuamente em todos os pacotes porque o caminho entre o remetente e o receptor pode ser alterado dinamicamente. Sempre que um remetente receber mensagens ICMP de "não é possível fragmentar", ele atualizará as informações de roteamento (onde armazena o PMTUD). Duas coisas podem acontecer durante o PMTUD: 1. O pacote pode chegar até o receptor sem ser fragmentado. Note: Para que um roteador proteja a CPU contra ataques DoS, ele limita para duas pessoas por segundo o número de mensagens ICMP inacessíveis enviadas. Portanto, nesse contexto, se você tiver um cenário de rede em que o roteador precisa responder com mais de duas mensagens ICMP (tipo = 3, código = 4) por segundo (pode ser de diferentes hosts), talvez você prefira desativar o controle de fluxo de mensagens ICMP com o comando de interface no ip icmp rate-limit unreachable [df]. 2. O remetente pode obter mensagens ICMP "Cant Fragment" a partir de quaisquer (ou de todos) os nós junto com o caminho para o receptor. O PMTUD é efetuado independentemente de ambas as direções de um fluxo de TCP. Pode haver casos em que o PMTUD em uma direção de fluxo aciona uma das estações finais para diminuir o MSS de envio e a outra estação final mantém o MSS de envio original, porque ela nunca enviou um datagrama IPv4 grande o suficiente para disparar o PMTUD. Um bom exemplo disso é a conexão HTTP retratada abaixo no Cenário 3. O cliente TCP envia pacotes pequenos e o servidor envia pacotes grandes. Nesse caso, apenas os pacotes grandes do servidor (maiores de 576 bytes) acionarão o PMTUD. Os pacotes do cliente são pequenos (menores que 576 bytes) e não dispararão PMTUD porque não requerem fragmentação para chegar ao link de 576 MTU. Cenário 3
O Cenário 4 mostra um exemplo de roteamento assimétrico, em que um dos caminhos tem um MTU mínimo menor que o outro. O roteamento assimétrico ocorre quando diferentes caminhos são usados para enviar e receber dados entre os dois endpoints. Nesse cenário, o PMTUD acionará a redução do MSS de envio apenas em uma direção de um fluxo de TCP. O tráfego do cliente TCP para o servidor flui através do Roteador A e do Roteador B, enquanto o tráfego de retorno que vem do servidor para o cliente flui através do Roteador D e do Roteador C. Quando o servidor TCP envia pacotes para o cliente, o PMTUD disparará o servidor para reduzir o MSS de envio porque o Roteador D deve fragmentar os pacotes de 4092 bytes antes de enviá-los para o Roteador C. Por outro lado, o cliente nunca receberá uma mensagem ICMP de “Destino inacessível" com o código que indica "fragmentação necessária e DF definido", porque o Roteador A não precisa fragmentar os pacotes quando os envia ao servidor pelo Roteador B. Cenário 4
Note: O comando ip tcp path-mtu-discovery é usado para ativar a descoberta de caminho TCP MTU para conexões TCP iniciadas pelos roteadores (BGP e Telnet, por exemplo). Problemas com o PMTUDHá três coisas que podem romper o PMTUD, duas que são incomuns e uma que é comum.
O primeiro e o último dos três marcadores aqui são incomuns e geralmente são o resultado de um erro, mas o marcador central descreve um problema comum. As pessoas que implementam filtros de pacotes de ICMP tendem a bloquear todos os tipos de mensagens de ICMP em vez de bloquear somente determinados tipos de mensagens de ICMP. Um filtro de pacotes pode bloquear todos os tipos de mensagens ICMP, exceto as que contêm "inacessível" ou "tempo excedido". O sucesso ou a falha do PMTUD depende das mensagens inacessíveis de ICMP que chegam ao remetente de um pacote TCP/IPv4. As mensagens ICMP de tempo excedido são importantes para outros problemas de IPv4. Um exemplo desse filtro de pacotes, implementado em um roteador, é mostrado aqui. access-list 101 permit icmp any any unreachable access-list 101 permit icmp any any time-exceeded access-list 101 deny icmp any any access-list 101 permit ip any any Há outras técnicas que podem ser usadas para ajudar a aliviar o problema do bloqueio total do ICMP.
No próximo cenário, os Roteadores A e B estão no mesmo domínio administrativo. O Roteador C é inacessível e bloqueia o ICMP, então o PMTUD é interrompido. Uma solução para essa situação é limpar o bit DF em ambos sentidos no Roteador B, para habilitar a fragmentação. Isso pode ser feito com o roteamento de política. A sintaxe para limpar o bit DF está disponível no Cisco IOS® Software Versão 12.1(6) e posterior. interface serial0 ... ip policy route-map clear-df-bit route-map clear-df-bit permit 10 match ip address 111 set ip df 0 access-list 111 permit tcp any any
Outra opção é alterar o valor de opção TCP MSS em pacotes SYN que atravessam o roteador (disponível no Cisco IOS® 12.2(4)T e posterior). Isso reduz o valor da opção MSS no pacote TCP SYN para que ele seja menor que o valor (1460) no comando ip tcp adjust-mss. O resultado é que o emissor do TCP enviará segmentos não maiores que esse valor. O tamanho do pacote IP será 40 bytes (1.500) maior do que o valor do MSS (1.460 bytes) para incluir o cabeçalho TCP (20 bytes) e o cabeçalho IPv4 (20 bytes). É possível ajustar o MSS dos pacotes TCP SYN com o comando ip tcp adjust-mss. Essa sintaxe reduzirá o valor MSS em segmentos TCP para 1460. Esse comando afeta o tráfego de entrada e saída na interface serial0. int s0 ip tcp adjust-mss 1460 Os problemas de fragmentação de IPv4 tornaram-se mais conhecidos desde que as implantações de túneis IPv4 aumentaram. O encapsulamento do túnel adiciona um “overhead" ao tamanho do pacote, por isso os túneis provocam mais fragmentação. Por exemplo, a adição de Encapsulamento de roteador genérico (GRE) aumenta um pacote em 24 bytes e, após esse aumento, o pacote talvez precise ser fragmentado porque é maior do que o MTU de saída. Em uma seção posterior neste documento, você verá exemplos dos tipos de problemas que podem surgir com túneis e fragmentação de IPv4. Topologias de rede comuns que necessitam de PMTUDO PMTUD é necessário nas situações de rede em que os links intermediários têm MTUs menores que o MTU dos links finais. Algumas razões comuns para a existência desses enlaces de MTU menores são:
Os protocolos de tunelamento, como o GRE, IPv4sec, L2TP, também precisam de espaço para seus respectivos cabeçalhos e rodapés. Isso também reduz a MTU efetiva da interface de saída. Nas próximas seções, o impacto de PMTUD, onde um protocolo de tunelamento é usado em algum lugar entre os dois hosts terminais, será estudado. Dos três casos anteriores, esse é o mais complexo e abrange todos os problemas que você pode ver nos outros casos. TúnelUm túnel é uma interface lógica em um roteador da Cisco, proporcionando uma maneira de encapsular pacotes passageiros dentro de um protocolo de transporte. É uma arquitetura projetada para prestar serviços para implementação em um esquema de encapsulamento ponto a ponto. O encapsulamento tem estes três componentes principais:
Os pacotes mostrados nesta seção ilustram os conceitos de tunelamento de IPv4, em que o GRE é o protocolo de encapsulamento e o IPv4 é o protocolo de transporte. O protocolo de passageiro também é IPv4. Nesse caso, o IPv4 é o protocolo de transporte e de passageiros. Pacote normal Pacote de túneis
O próximo exemplo mostra o encapsulamento de IPv4 e DECnet como protocolos de passageiro com GRE como transportador. Isso ilustra o fato de que o protocolo da transportador pode encapsular vários protocolos de passageiro, conforme mostrado na imagem.
Um administrador de rede pode considerar um tunelamento quando há duas redes não contíguas e sem IPv4 separadas por um backbone de IPv4. Caso as redes não contíguas executem o DECnet, o administrador pode não querer conectá-las entre si ao configurar o DECnet no backbone. O administrador pode não querer permitir que o roteamento de DECnet consuma a largura de banda do backbone, porque isso interferiria no desempenho da rede IPv4. Uma alternativa viável é fazer um túnel DECnet no backbone IPv4. O tunelamento encapsula os pacotes DECnet dentro do IPv4 e os envia pelo backbone até o terminal de túnel, onde o encapsulamento é removido e os pacotes DECnet podem ser encaminhados ao seu destino através de DECnet. Encapsular o tráfego dentro de um outro protocolo oferece estas vantagens:
No resto do documento, o IPv4 é usado como protocolo passageiro e protocolo de transporte. Considerações com relação às interfaces de túnelEstas são considerações sobre tunelamento.
Roteador como participante PMTUD no endpoint do túnelO roteador tem duas funções PMTUD diferentes quando é o ponto final de um túnel.
Vamos começar a analisar o que acontece quando o roteador atua na primeira função, um roteador que encaminha pacotes IP do host, em relação ao PMTUD. Essa função ocorre antes do roteador encapsular o pacote IPv4 do host dentro do pacote de túnel. Se o roteador participar como o remetente de um pacote do host, ele executará estas ações:
Genericamente, há uma escolha de encapsulamento e fragmentação (envia dois fragmentos de encapsulamento) ou fragmentação e encapsulamento (envia dois fragmentos encapsulados). Alguns exemplos que descrevem a mecânica do encapsulamento e a fragmentação de pacotes IPv4 e os dois cenários que mostram a interação do PMTUD e pacotes que atravessam redes de exemplo estão detalhados nesta seção. O primeiro exemplo mostra o que acontece com um pacote quando o roteador (na origem do túnel) tem a função de roteador de encaminhamento. Lembre-se que para processar o PMTUD, o roteador precisa verificar o tamanho do bit DF e do pacote de dados original para executar a ação apropriada. Este exemplo usa encapsulamento GRE para o túnel. Como pode ser observado, o GRE faz a fragmentação antes do encapsulamento. Os exemplos posteriores mostram cenários em que a fragmentação é feita após o encapsulamento. No exemplo 1, o bit DF não está definido (DF = 0) e a MTU de IPv4 do túnel GRE é 1.476 (1.500-24). Exemplo 1 1. O roteador de encaminhamento (na origem de túnel) recebe um datagrama de 1500 bytes com o bit DF limpo (DF = 0) do host de envio. Esse datagrama é composto por um cabeçalho de IP de 20 bytes e um payload de TCP de 1480 bytes.
2. Como o pacote é muito grande para o IPv4 de MTU depois da adição do overhead de GRE (24 bytes), o roteador de encaminhamento divide o datagrama em dois fragmentos de 1.476 (20 bytes de cabeçalho IPv4 + 1.456 bytes de payload IPv4) e 44 bytes (20 bytes de cabeçalho IPv4 + 24 bytes de payload IPv4), portanto depois que o encapsulamento GRE for adicionado, o pacote não será maior do que o MTU de interface física de saída.
3. O roteador de encaminhamento adiciona o encapsulamento GRE, incluindo um cabeçalho GRE de 4 bytes e um cabeçalho IPv4 de 20 bytes, a cada fragmento do datagrama IPv4 original. Esses dois datagramas IPv4 agora têm um comprimento de 1.500 e 68 bytes e não são considerados fragmentos, mas sim datagramas IP individuais.
4. O roteador de destino do túnel remove o encapsulamento GRE de cada fragmento do datagrama original, permanecendo dois fragmentos IPv4 de 1.476 e 24 bytes de comprimento. Esses fragmentos de datagrama de IPv4 são encaminhados separadamente por este roteador para o host destinatário.
5. O host destinatário remonta esses dois fragmentos no datagrama original.
O cenário 5 descreve a função do roteador de encaminhamento no contexto de uma topologia de rede. Neste exemplo, o roteador tem a mesma função do roteador de encaminhamento, mas dessa vez o bit DF está definido (DF = 1). Exemplo 2 1. O roteador de encaminhamento na origem do túnel recebe um datagrama de 1500 bytes com DF = 1 do host de envio.
2. Como o bit DF está definido, e o tamanho do datagrama (1.500 bytes) é maior do que o MTU IPv4 do túnel GRE (1476), o roteador descartará o datagrama e enviará uma mensagem de "fragmentação ICMP necessária, mas bit DF definido" para a origem do datagrama. A mensagem de ICMP alertará o remetente de que o MTU é 1.476.
3. O host remetente recebe a mensagem de ICMP e, ao reenviar os dados originais, ele usa uma datagrama IPv4 de 1.476 bytes.
4. Esse comprimento de datagrama IPv4 (1.476 bytes) agora é igual em valor ao MTU IPv4 do túnel GRE, de modo que o roteador adiciona o encapsulamento GRE ao datagrama IPv4.
5. O roteador destinatário (no destino do túnel) remove o encapsulamento GRE do datagrama IPv4 e o envia para o host destinatário.
Agora, você pode analisar o que acontece quando o roteador tem uma segunda função como host remetente em relação ao PMTUD e ao pacote IPv4 do túnel. Lembre-se de que essa função ocorre após o roteador encapsular o pacote IPv4 original do host dentro do pacote de túnel. Note: Como padrão, um roteador não faz PMTUD nos pacotes de túnel GRE gerados por ele. O comando tunnel path-mtu-discovery pode ser usado para ativar o PMTUD para pacotes de túnel IPv4 do GRE. O exemplo 3 mostra o que acontece quando o host envia datagramas IPv4 suficientemente pequenos para caber no IPv4 do MTU da interface de túnel GRE. O bit DF, nesse caso, pode ser configurado ou limpo (1 ou 0). A interface de túnel GRE não tem o comando tunnel path-mtu-discovery configurado, portanto o roteador não faz o PMTUD no pacote IPv4 do GRE. Exemplo 3 1. O roteador de encaminhamento na origem do túnel recebe um datagrama de 1476 bytes do host de envio.
2. Esse roteador encapsula o datagrama de IPv4 de 1476 bytes dentro do GRE para obter um datagrama de IPv4 do GRE de 1.500 bytes. O bit DF no cabeçalho do IPv4 do GRE será removido (DF = 0). Esse roteador encaminha, em seguida, esse pacote ao destino do túnel.
3. Pressuponha que há um roteador entre a origem e o destino do túnel com um MTU de link de 1.400. Esse roteador fragmentará o pacote de túnel porque o bit de está limpo (DF = 0). Lembre-se que esse exemplo fragmenta o IPv4 mais externo, então os cabeçalhos de GRE, IPv4 interno e TCP só aparecerão no primeiro fragmento.
4. O roteador de destino do túnel deve realizar a remontagem dos pacotes GRE do túnel.
5. Depois que o pacote de túnel GRE for remontado, o roteador removerá o cabeçalho IPv4 de GRE e encaminhará normalmente o datagrama IPv4 original.
O próximo exemplo mostra o que acontece quando o roteador funciona como host remetente em relação ao PMTUD e ao pacote IPv4 do túnel. Dessa vez, o bit DF está definido (DF = 1) no cabeçalho IPv4 original e o comando tunnel path-mtu-discovery foi configurado para que o bit DF seja copiado do cabeçalho IPv4 interno para o cabeçalho externo (GRE + IPv4). Exemplo 4 1. O roteador de encaminhamento na fonte de túnel recebe um datagrama de 1.476 bytes com DF = 1 proveniente do host remetente.
2. Esse roteador encapsula o datagrama de IPv4 de 1476 bytes dentro do GRE para obter um datagrama de IPv4 do GRE de 1.500 bytes. Este cabeçalho IPv4 de GRE terá o DF bit definido (DF = 1), pois o datagrama IPv4 original tinha o bit DF definido. Esse roteador encaminha, em seguida, esse pacote ao destino do túnel.
3. Novamente, pressuponha que há um roteador entre a origem e o destino do túnel com um MTU de link de 1.400. Este roteador não fragmentará o pacote de túnel desde que o bit DF esteja definido (DF = 1). Esse roteador deve descartar o pacote e enviar uma mensagem de erro de ICMP para o roteador de origem do túnel, já que é o endereço IPv4 de origem no pacote.
4. O roteador de encaminhamento na origem do túnel recebe esta mensagem de erro de "ICMP" e diminuirá o MTU de IPvr do túnel GRE para 1.376 (1.400-24). Na próxima vez que o host de envio retransmite os dados em um pacote de IPv4 de 1.476 bytes, esse pacote pode ser muito grande e o roteador enviará uma mensagem de erro de "ICMP" para o remetente com um valor MTU de 1.376. Quando o host remetente retransmite os dados, ele envia um pacote IPv4 de 1.376 bytes e o pacote atravessará o túnel GRE até o host destinatário. Cenário 5Esse cenário ilustra a fragmentação GRE. Lembre-se que você fragmenta antes do encapsulamento para o GRE e, em seguida, faz o PMTUD para o pacote de dados, além disso o bit DF não é copiado quando o pacote IPv4 é encapsulado pelo GRE. Nesse cenário, o bit DF não está definido. O MTU de IPv4 da interface de túnel GRE é, por padrão, 24 bytes menor do que o MTU de IPv4 de interface física, portanto o MTU de IPv4 da interface GRE é 1.476, como mostrado na imagem.
Cenário 6Esse cenário é semelhante ao cenário 5, mas desta vez o bit DF está definido. No Cenário 6, o roteador está configurado para fazer PMTUD nos pacotes de túnel IPv4 + GRE com o comando tunnel path-mtu-discovery, e o bit DF é copiado do cabeçalho IPv4 original para o cabeçalho IPv4 do GRE. Se o roteador recebe um erro de ICMP para o pacote IPv4 + GRE, ele reduz o MTU do IP na interface de túnel GRE. Novamente, lembre-se de que o MTU do IPv4 do túnel GRE é definido como 24 bytes, menos do que o MTU de interface física por padrão, portanto este MTU de IPv4 de GRE é 1.476. Além disso, observe que há um link de MTU de 1.400 no caminho do túnel GRE, conforme mostrado na imagem.
Note: Se o comando tunnel path-mtu-discovery não for configurado no roteador de encaminhamento neste cenário, e o bit DF for definido nos pacotes encaminhados pelo túnel GRE, o Host 1 ainda conseguiria enviar os pacotes TCP/IPv4 para o Host 2, mas eles teriam se fragmentado no meio, no link MTU 1.400. Além disso, o par do túnel GRE teria que remontá-los, antes que pudessem ser desencapsulados, e enviá-los. GRE + IPsec (Modo de túnel)O protocolo de segurança IPv4 (IPv4sec) é um método padronizado que fornece privacidade, integridade e autenticidade às informações transferidas pelas redes IPv4. O IPv4sec fornece a criptografia de camada de rede IPv4. O IPv4sec alonga o pacote IPv4 ao adicionar pelo menos um cabeçalho IPv4 (modo de túnel). O(s) cabeçalho(s) adicionado(s) varia(m) em comprimento dependendo do modo de configuração IPv4sec, mas não excedem ~58 bytes (Encapsulating Security Payload (ESP) e ESP authentication (ESPauth)) por pacote. O IPv4sec tem dois modos, o modo de túnel e o modo de transporte.
O IPv4sec sempre faz PMTUD para pacotes de dados e para seus próprios pacotes. Existem comandos de configuração IPv4sec para modificar o processamento de PMTUD para o pacote IPv4 de IPv4sec, o IPv4sec pode limpar, definir ou copiar o bit DF do cabeçalho IPv4 do pacote de dados para o cabeçalho IPv4 de IPv4sec. Esse recurso é denominado "Funcionalidade de Anulação de Bit DF". Note: Você realmente quer evitar a fragmentação após o encapsulamento quando faz a criptografia de hardware com o IPv4sec. A criptografia de hardware pode fornecer a você uma produtividade de cerca de 50 Mbs, dependendo do hardware, mas se o pacote IPv4sec estiver fragmentado você perderá de 50 a 90% da produtividade. Essa perda ocorre porque os pacotes IPv4sec fragmentados são comutados por processo para remontagem e, em seguida, enviados para o mecanismo de criptografia de hardware para descriptografia. Essa perda de produtividade pode prejudicar a produtividade de criptografia de hardware até o nível de desempenho da criptografia de software (2-10 Mbs). Cenário 7Este cenário retrata a fragmentação de IPv4sec em ação. Nesse cenário, o MTU em todo o caminho é 1.500. Nesse cenário, o bit DF não está definido.
Cenário 8Esse cenário é semelhante ao cenário 6, porém, neste caso, o bit DF está definido no pacote de dados original e há um link no caminho entre os pares de túnel IPv4sec com MTU menor do que os outros links. Esse cenário demonstra como o roteador par de IPv4sec executa as duas funções de PMTUD, conforme descrito na seção O roteador como um participante PMTUD no endpoint de um túnel. Nesse cenário, você verá como o PMTU de IPv4sec é alterado para um valor mais baixo, como resultado da necessidade de fragmentação. Lembre-se de que o bit DF é copiado do cabeçalho IPv4 interno para o cabeçalho IPv4 externo, quando o IPv4sec criptografa um pacote. Os valores de MTU e PMTU de mídia são armazenados em Security Association (SA) do IPv4sec. A mídia de MTU baseia-se no MTU da interface do roteador de saída e o PMTU tem como base o MTU mínimo visto no caminho entre os pares de IPv4sec. Lembre-se de que o IPv4sec encapsula/criptografa o pacote antes de tentar fragmentá-lo, conforme mostrado na imagem.
GRE e IPv4sec juntosAs interações mais complexas para fragmentação e PMTUD ocorrem quando o IPv4sec é usado para criptografar túneis GRE. O IPv4sec e o GRE são combinados dessa maneira porque o IPv4sec não comporta pacotes de multicast de IPv4, o que significa que você não pode executar um protocolo de roteamento dinâmico pela rede IPv4sec VPN. Os túneis GRE oferecem suporte ao multicast, portanto, um túnel GRE pode ser usado para encapsular primeiro o pacote de multicast do protocolo de roteamento dinâmico em um pacote de unicast de IPv4 de GRE, que pode então ser criptografado pelo IPv4sec. Ao fazer isso, o IPv4sec geralmente é implementado no modo de transporte no topo do GRE, porque os pares de IPv4sec e os endpoints de túnel de GRE (os roteadores) são os mesmos, e o modo de transporte salvará 20 bytes de sobrecarga de IPv4sec. Um caso interessante é quando um pacote IPv4 tiver sido dividido em dois fragmentos e encapsulado pelo GRE. Nesse caso, o IPv4sec verá dois pacotes de GRE + IPv4 independentes. Frequentemente, em uma configuração padrão, um desses pacotes será grande o suficiente para precisar ser fragmentado depois que for criptografado. O par de IPv4sec terá que remontar este pacote antes de descriptografar. Essa “fragmentação dupla" (uma vez antes de GRE e novamente depois de IPv4sec) no roteador remetente aumenta a latência e reduz a taxa de transferência. Além disso, a remontagem é em switch de processo, então haverá um acesso à CPU no roteador destinatário sempre que isso acontecer. Essa situação pode ser evitada ao definir o "ip mtu" da interface do túnel GRE baixo o suficiente para levar em conta a sobrecarga do GRE e IPv4sec (por padrão, a interface do túnel GRE "ip mtu" é definido como os bytes de sobrecarga de MTU - GRE da interface real de saída). Esta tabela lista os valores de MTU sugeridos para cada combinação de túnel/modo, pressupondo que a interface física de saída tenha um MTU de 1.500.
Note: O valor de MTU de 1.400 é recomendado porque abrange as combinações de modo de GRE + IPv4sec mais comuns. Além disso, não há nenhuma desvantagem discernível em permitir um overhead de 20 ou 40 bytes adicionais. É mais fácil de lembrar e definir um valor e esse valor abrange quase todos os cenários. Cenário 9O IPv4sec é implantado por cima do GRE. O MTU físico de saída é 1.500, o IPv4sec de PMTU é 1.500 e o MTU de IPv4 de GRE é 1.476 (1.500-24 = 1.476). Por causa disso, os pacotes TCP/IPv4 serão fragmentados duas vezes, uma vez antes do GRE e uma vez depois do IPv4sec. O pacote será fragmentado antes do encapsulamento de GRE e um desses pacotes GRE será fragmentado novamente após a criptografia de IPv4sec. Configurar o "ip mtu 1440" (modo de transporte de IPv4sec) ou "mtu ip 1420" (modo de túnel de IPv4sec) no túnel GRE eliminaria a possibilidade de fragmentação dupla nesse cenário.
O Cenário 10 é semelhante ao Cenário 8, exceto pela existência de um link MTU mais baixo no caminho de túnel. Este é um pior cenário para o primeiro pacote enviado do Host 1 para o Host 2. Após a última etapa neste cenário, o Host 1 define o PMTU correto para o Host 2 e tudo está bem para as conexões TCP entre o Host 1 e o Host 2. Os fluxos de TCP entre o Host 1 e outros hosts (alcançáveis através do túnel IPv4sec + GRE) terão apenas que passar pelas três últimas etapas do Cenário 10. Nesse cenário, o comando tunnel path-mtu-discovery é configurado no túnel GRE e o bit DF é definido em pacotes TCP/IPv4 que se originam do Host 1. Cenário 10
Outras recomendaçõesConfigurar o comando tunnel path-mtu-discovery em uma interface de túnel pode ajudar na interação do GRE e IPv4sec quando eles estão configurados no mesmo roteador. Lembre-se de que sem o comando tunnel path-mtu-discovery configurado, o bit DF será sempre removido do cabeçalho IPv4 do GRE. Essa configuração permite que o pacote IPv4 de GRE seja fragmentado, mesmo que o cabeçalho IPv4 dos dados encapsulados tenha o bit DF definido, o que normalmente não permitiria a fragmentação do pacote. Se o comando tunnel path-mtu-discovery for configurado na interface de túnel GRE, isso acontecerá.
O comando tunnel path-mtu-discovery ajuda a interface do GRE definir seu MTU de IPv4 dinamicamente, em vez de estaticamente, com o comando ip mtu. Na verdade, recomenda-se que os dois comandos sejam usados. O comando ip mtu é usado para dar espaço para o GRE e a sobrecarga do IPv4sec relativo ao MTU de IPv4 de interface física de saída. O comando tunnel path-mtu-discovery permite que o túnel GRE do MTU de IPv4 seja reduzido ainda mais se houver um link de MTU de IPv4 mais baixo no caminho entre os pares de IPv4sec. Aqui estão algumas ações que podem ser feitas caso você esteja com problemas de PMTUD em uma rede com túneis GRE + IPv4sec configurados. Esta lista começa com a solução mais desejável.
Informações Relacionadas
Qual termo descreve um campo no cabeçalho do pacote IPv4?Os campos significativos no cabeçalho IPv4 incluem: Versão - Contém um valor binário de 4 bits que identifica a versão do pacote IP. Em pacotes IPv4, esse campo é sempre definido como 0100.
Qual o campo do cabeçalho IPv4 que identifica o protocolo de camada superior presente no pacote?Qual campo de cabeçalho IPv4 identifica o protocolo da camada superior transportado no pacote? Explicação: É o campo Protocolo no cabeçalho IP que identifica o protocolo da camada superior que o pacote está transportando. O campo Versão identifica a versão do IP.
Qual a afirmativa descreve uma característica dos campos de cabeçalho do quadro de camada de enlace de dados?Qual afirmação descreve uma característica dos campos de cabeçalho de quadro da camada de enlace de dados? Os campos de cabeçalho do quadro Ethernet contêm os endereços de origem e destino da Camada 3. Eles incluem informações sobre os aplicativos do usuário.
Qual valor que está contido em um campo de cabeçalho IPv4 e diminuído por cada roteador que recebe um pacote?Qual valor, que está contido em um campo de cabeçalho IPv4, é diminuído por cada roteador que recebe um pacote? Explicação: Quando um roteador recebe um pacote, o roteador diminuirá o campo Time-to-Live (TTL) em um.
|
Qual termo descreve um campo no cabeçalho do pacote IPv4 usado para identificar o Protocolo de próximo nível?
Postagens relacionadas
direito autoral © 2024 ptcemlecom Inc.
