Resolver problemas de fragmentação de IPv4, MTU, MSS e PMTUD com GRE e IPsec

Introduction

Este documento descreve como a Fragmentação IPv4 e a Descoberta da Unidade Máxima de Transmissão do Caminho (PMTUD) funcionam. 

Informações de Apoio

Também são discutidos cenários que envolvem o comportamento do PMTUD quando combinado com diferentes combinações de túneis IPv4.

Fragmentação e remontagem de IPv4

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 de MTU depende do link de transmissão.

O design do IPv4 acomoda diferenças de MTU porque permite que os roteadores fragmentem datagramas IPv4 conforme necessário.

A estação receptora é responsável pela remontagem dos fragmentos no datagrama IPv4 original de tamanho completo.

A fragmentação do IPv4 divide um datagrama em pedaços que são remontados posteriormente.

Os campos de origem, destino, identificação, comprimento total e deslocamento de fragmentos do IPv4, juntamente com os sinalizadores "mais fragmentos" (MF) e "não fragmentar" (DF) no cabeçalho IPv4, são usados para fragmentação e remontagem do 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. Isso ajuda 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 8 bytes.

Há 3 bits para os sinalizadores de controle no campo de sinalizadores do cabeçalho IPv4. O bit "do not fragment" (DF) 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 = "can fragment", 1 = "do not fragment").

O Bit 2 é o bit MF (0 = "último fragmento", 1 = "mais fragmentos").

Valor	Bit 0 reservado	Bit 1 DF	Bit 2 MF
0	0	Maio	Sobrenome
1	0	Errado	Mais

Se os comprimentos dos fragmentos IPv4 forem adicionados, o valor excederá o comprimento do datagrama IPv4 original em 60.

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 é 1500; isso inclui 20 bytes para o cabeçalho IPv4 original ligeiramente modificado.

O segundo fragmento tem um deslocamento de 185 (185 x 8 = 1480); a parte de dados desse fragmento começa com 1480 bytes no datagrama IPv4 original.

O comprimento desse fragmento é 1500; isso inclui o cabeçalho IPv4 adicional criado para esse fragmento.

O terceiro fragmento tem um deslocamento de 370 (370 x 8 = 2960); a parte de dados desse fragmento começa com 2960 bytes no datagrama IPv4 original.

O comprimento desse fragmento é 1500; 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 é 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.

A soma dos bytes de dados do último fragmento (680 = 700 - 20) produz 5120 bytes, que é a parte de dados do datagrama IPv4 original.

A adição de 20 bytes para um cabeçalho IPv4 é igual ao tamanho do datagrama IPv4 original (4440 + 680 + 20 = 5140) como mostrado nas imagens.

Problemas com fragmentação de IPv4

A fragmentação de IPv4 resulta em um pequeno aumento na sobrecarga de CPU e memória para fragmentar um datagrama IPv4. Isso é verdadeiro para o remetente e para um roteador no caminho entre um remetente e um destinatário.

A criação de fragmentos envolve a criação de cabeçalhos de fragmentos e copia o datagrama original nos fragmentos.

Isso é feito de forma eficiente porque 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.

A remontagem, no entanto, é ineficiente em um roteador cujo trabalho principal é encaminhar pacotes o mais rápido possível.

Um roteador não é projetado para reter os pacotes por qualquer período.

Um roteador que faz a remontagem escolhe o maior buffer disponível (18K), porque não tem como determinar o tamanho do pacote IPv4 original até que o último fragmento seja recebido.

Outro problema da fragmentação envolve o modo de manuseio dos fragmentos descartados.

Se um fragmento de um datagrama IPv4 for descartado, todo o datagrama IPv4 original deverá estar presente e também será fragmentado.

Isso é visto com o NFS (Network File System). O NFS tem um tamanho de bloco de leitura e gravação de 8192. 

Portanto, um datagrama NFS IPv4/UDP tem aproximadamente 8500 bytes (o que inclui cabeçalhos NFS, UDP e IPv4).

Uma estação emissora conectada a uma Ethernet (MTU 1500) precisa fragmentar o datagrama de 8500 bytes em seis (6) pedaços; cinco (5) fragmentos de 1500 bytes e um (1) fragmento de 1100 bytes.

Se qualquer um dos seis fragmentos for descartado devido a um link congestionado, o datagrama original completo terá que ser retransmitido. Isso resulta em mais seis fragmentos a serem criados.

Se esse link descartar um em seis pacotes, haverá poucas chances de que qualquer dado NFS seja transferido por esse link, pois pelo menos um fragmento IPv4 seria descartado de cada datagrama IPv4 original de 8.500 bytes do NFS.

Os firewalls que filtram ou manipulam pacotes com base nas informações da Camada 4 (L4) até a Camada 7 (L7) têm problemas para processar fragmentos IPv4 corretamente.

Se os fragmentos IPv4 estiverem fora de ordem, um firewall bloqueará os fragmentos não iniciais porque eles não carregam as informações correspondentes ao filtro do pacote.

Isso significa que o datagrama IPv4 original não pôde ser remontado pelo host receptor.

Se o firewall estiver configurado para permitir fragmentos não iniciais com informações insuficientes para corresponder corretamente ao filtro, um ataque de fragmento não inicial pelo firewall será possível.

Os dispositivos de rede, como Content Switch Engines, direcionam pacotes com base nas informações de L4 a L7 e, se um pacote abranger vários fragmentos, o dispositivo terá problemas para aplicar suas políticas.

Evite a fragmentação de IPv4: como o TCP MSS funciona

O MSS (Maximum Segment Size, tamanho máximo de segmento) do TCP (Transmission Control Protocol) define a quantidade máxima de dados que um host aceita em um único datagrama TCP/IPv4.

Esse datagrama TCP/IPv4 é possivelmente fragmentado na camada 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. O valor de MSS não é negociado entre 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 era o segmento máximo de dados que o receptor TCP ia aceitar. Esse segmento TCP poderia ser tão grande quanto 64K e fragmentado na camada IPv4 para ser transmitido ao host receptor.

O host receptor remontaria o datagrama de IPv4 antes de ele enviar o segmento TCP completo para a camada de TCP.

Como os valores MSS são definidos e usados para limitar os tamanhos de segmentos TCP e de datagramas IPv4.

O Exemplo 1 ilustra como 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.

O Host A e o Host B precisam fragmentar os datagramas IPv4 que são maiores que o MTU da interface, ainda que menores que o MSS de envio, porque a pilha TCP passa 16K ou 8K bytes de dados pela pilha até o IPv4.

No caso do Host B, os pacotes são fragmentados para chegar à LAN Token Ring e, novamente, à LAN Ethernet.

Exemplo 1

1. O Host A envia o valor MSS de 16K para o Host B.
2. O Host B recebe o valor MSS de 16K do Host A.
3. O Host B define o valor MSS de envio como 16K.
4. O Host B envia o valor MSS de 8K para o Host A.
5. O Host A recebe o valor MSS de 8K do Host B.
6. O Host A define o valor MSS de envio como 8K.

Para ajudar a evitar a fragmentação de IPv4 nos pontos finais da conexão TCP, a seleção do valor de MSS foi alterada para o tamanho mínimo do buffer e o MTU da interface de saída (- 40).

Os números MSS são 40 bytes menores do que os números MTU porque o MSS (o tamanho dos dados TCP) não inclui o cabeçalho IPv4 de 20 bytes e o cabeçalho TCP de 20 bytes.

O MSS é baseado em tamanhos de cabeçalho padrão; a pilha de remetente deve subtrair os valores apropriados para o cabeçalho IPv4 e o cabeçalho TCP depende de quais opções de TCP ou IPv4 são usadas.

O MSS funciona atualmente de uma maneira em que cada host compara primeiro seu MTU de interface de saída com seu próprio buffer e escolhe o valor mais baixo como o MSS a enviar.

Em seguida, os hosts comparam o tamanho do MSS recebido com o MTU da própria interface e escolhem novamente o menor dos dois valores.

O Exemplo 2 ilustra essa etapa adicional realizada pelo remetente para evitar a fragmentação nos fios local e remoto.

A MTU da interface de saída é levada em conta por cada host antes que os hosts enviem uns aos outros seus valores de MSS. Isso ajuda a evitar a fragmentação.

Exemplo 2

1. O Host A compara o buffer de MSS (16K) e seu MTU (1.500 - 40 = 1.460) e usa o valor mais baixo como MSS (1.460) para envio ao Host B.
2. O Host B recebe o MSS de envio (1460) do Host A e o compara ao valor de sua interface de saída MTU - 40 (4422).
3. O Host B define o valor mais baixo (1.460) como o MSS  para enviar datagramas IPv4 para o Host A.
4. O Host B compara o buffer de MSS (8K) e o MTU (4.462-40 = 4.422) e usa 4.422 como MSS para enviar ao Host A.
5. O Host A recebe o MSS de envio (4422) do Host B e o compara ao valor de sua interface de saída MTU -40 (1460).
6. O Host A define o valor mais baixo (1.460) como o MSS para enviar datagramas IPv4 para o Host B.

1460 é o valor escolhido por ambos os hosts como o MSS de envio de um para o outro. Frequentemente, o valor MSS de envio é o mesmo em cada extremidade de uma conexão TCP.

No Exemplo 2, a fragmentação não ocorre nos pontos finais de uma conexão TCP porque os hosts levam em consideração as MTUs da interface de saída.

Os pacotes ainda se tornam fragmentados na rede entre o Roteador A e o Roteador B se encontrarem um link com uma MTU mais baixa do que a interface de saída de qualquer um dos hosts.

O que é PMTUD

O TCP MSS aborda a fragmentação nos dois pontos finais de uma conexão TCP, mas não trata de casos em que há um link de MTU menor no meio entre esses dois pontos finais.

O PMTUD foi desenvolvido para evitar a fragmentação no caminho entre os endpoints. É usado para determinar dinamicamente a MTU mais baixa ao longo do caminho de uma origem de pacote para seu destino.

Observação: o PMTUD só é suportado pelo TCP e pelo UDP. Outros protocolos não são compatíveis. Se o PMTUD estiver habilitado em um host, todos os pacotes TCP e UDP do host têm 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 registra o valor de MTU para um destino porque cria uma entrada de host (/32) em sua tabela de roteamento com esse valor de MTU.

Se um roteador tenta encaminhar um datagrama IPv4 (com o bit DF definido) para um link que tem uma MTU menor que o tamanho do pacote, o roteador descarta o pacote e retorna uma mensagem de "Destino Inalcançável" do Internet Control Message Protocol (ICMP) 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 ICMP, ela reduz o MSS de envio e, quando o TCP retransmite o segmento, ele usa o menor tamanho de segmento.

Este é um exemplo de uma mensagem ICMP "fragmentation needed and DF set" vista em um roteador após o comando debug ip icmp está 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 pelos quais o MTU é reduzido durante o PMTUD.

Ele é usado por hosts para chegar mais rapidamente a um valor razoável para o MSS de envio e como mostrado neste exemplo.

O PMTUD é executado continuamente em todos os pacotes porque o caminho entre o remetente e o destinatário pode mudar dinamicamente.

Cada vez que um remetente recebe mensagens ICMP "Não é possível fragmentar", ele atualiza 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.

Observação: para que um roteador proteja a CPU contra ataques DoS, ele acelera para duas por segundo o número de mensagens ICMP inalcançáveis que enviaria. Portanto, nesse contexto, se você tiver um cenário de rede no qual espera que o roteador precise responder com mais de duas mensagens ICMP (tipo = 3, código = 4) por segundo (podem ser hosts diferentes), desative a limitação de mensagens ICMP com o comando no ip icmp rate-limit unreachable [df] interface comando.

2. O remetente recebe mensagens ICMP "Cannot Fragment" dos saltos ao longo do caminho até o receptor.

O PMTUD é efetuado independentemente de ambas as direções de um fluxo de TCP.

Há casos em que o PMTUD em uma direção de um fluxo aciona uma das estações finais para reduzir o MSS de envio e a outra estação final mantém o MSS de envio original porque nunca enviou um datagrama IPv4 grande o suficiente para acionar o PMTUD.

Um exemplo é a conexão HTTP descrita no Exemplo 3. O cliente TCP envia pacotes pequenos e o servidor envia pacotes grandes.

Nesse caso, somente os pacotes grandes do servidor (maiores que 576 bytes) disparam o PMTUD.

Os pacotes do cliente são pequenos (menos de 576 bytes) e não disparam PMTUD porque não exigem fragmentação para atravessar o link de MTU 576.

Exemplo 3

O Exemplo 4 mostra um exemplo de roteamento assimétrico em que um dos caminhos tem uma MTU mínima menor que o outro.

O roteamento assimétrico ocorre quando diferentes caminhos são usados para enviar e receber dados entre os dois endpoints.

Neste exemplo, o PMTUD aciona a redução do MSS de envio somente em uma direção de um fluxo TCP.

O tráfego do cliente de TCP para o servidor passa pelos Roteadores A e B, enquanto o tráfego de retorno proveniente do servidor para o cliente passa pelos Roteadores D e C.

Quando o servidor TCP envia pacotes ao cliente, o PMTUD aciona o servidor para reduzir o MSS de envio, pois o Roteador D deve fragmentar os pacotes de 4.092 bytes antes de poder enviá-los ao Roteador C.

Por outro lado, o cliente nunca recebe uma mensagem ICMP "Destino Inalcançável" com o código que indica "fragmentação necessária e DF definido", porque o Roteador A não precisa fragmentar pacotes quando os envia ao servidor através do Roteador B.

Exemplo 4

Observação: o comando ip tcp path-mtu-discovery é usado para habilitar a descoberta de caminho TCP MTU para conexões TCP iniciadas por roteadores (BGP e Telnet, por exemplo).

Problemas com o PMTUD

Essas são coisas que podem quebrar o PMTUD.

• Um roteador descarta um pacote e não envia uma mensagem ICMP. (Incomum)

• Um roteador gera e envia uma mensagem ICMP, mas a mensagem ICMP é bloqueada por um roteador ou firewall entre esse roteador e o remetente. (Comum)

• Um roteador gera e envia uma mensagem ICMP, mas o remetente ignora a mensagem. (Incomum)

O primeiro e o último dos três marcadores aqui são geralmente o resultado de um erro, mas o marcador do meio descreve um problema comum.

Aqueles que implementam filtros de pacotes ICMP tendem a bloquear todos os tipos de mensagens ICMP, em vez de bloquear apenas determinados tipos de mensagens ICMP.

É possível que o filtro de pacotes bloqueie todos os tipos de mensagens ICMP, exceto aquelas que são "inalcançáveis" ou "tempo excedido".

O sucesso ou a falha do PMTUD depende das mensagens ICMP inalcançáveis 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 aliviar o problema de um ICMP completamente bloqueado.

• Limpe o bit DF no roteador e permita a fragmentação. (Esta não é uma boa ideia, porém. Consulte Problemas com a fragmentação de IP para obter mais informações).

• Manipule o valor da opção TCP MSS MSS com o comando interface ip tcp adjust-mss <500-1460>.

No próximo exemplo, 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 seja menor que o valor (1460) no ip tcp adjust-msscomando.

O resultado é que o remetente TCP envia segmentos não maiores que esse valor.

O tamanho do pacote IPv4 é 40 bytes maior (1500) do que o valor MSS (1460 bytes) para considerar o cabeçalho TCP (20 bytes) e o cabeçalho IPv4 (20 bytes).

Você pode ajustar o MSS de pacotes TCP SYN com o comando ip tcp adjust-mss comando. Essa sintaxe reduz o valor de 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.

Os túneis causam mais fragmentação porque o encapsulamento do túnel adiciona "sobrecarga" ao tamanho de um pacote.

Por exemplo, a adição de Generic Router Encapsulation (GRE) adiciona 24 bytes a um pacote e, após esse aumento, o pacote precisa ser fragmentado porque é maior que o MTU de saída.

Topologias de rede comuns que necessitam de PMTUD

O 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:

• Hosts terminais conectados por Token Ring (ou FDDI), com uma conexão Ethernet entre eles. Os MTUs de Token Ring (ou FDDI) nas extremidades são maiores que o MTU de Ethernet localizado no meio.

• O PPPoE (geralmente utilizado com ADSL) precisa de 8 bytes para seu cabeçalho. Isso reduz o MTU efetivo de Ethernet para 1492 (1500 - 8).

Protocolos de túnel como GRE, IPv4sec e L2TP também precisam de espaço para seus respectivos cabeçalhos e trailers. Isso também reduz o MTU efetivo da interface de saída.

Túnel

Um 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. As interfaces de túnel têm estes três componentes principais:

• Protocolo de passageiro (AppleTalk, Banyan VINES, CLNS, DECnet, IPv4 ou IPX)

• Protocolo de portador - um desses protocolos de encapsulamento:

  • GRE - protocolo de operadora multiprotocolo da Cisco. Consulte RFC 2784 e RFC 1701 para obter mais informações.

  • IPv4 em túneis de IPv4 - Consulte RFC 2003 para obter mais informações.

• Protocolo de transporte - O protocolo usado para transportar o protocolo encapsulado.

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

IPv4

TCP

Telnet

Pacote de túneis

IPv4

GRE

IPv4

TCP

Telnet

• IPv4 é o protocolo de transporte

• GRE é o protocolo de encapsulamento.

• IPv4 é o protocolo de passageiros.

O próximo exemplo mostra o encapsulamento de IPv4 e DECnet como protocolos de passageiro com GRE como transportador.

Isso ilustra a possibilidade de que os protocolos de portadora encapsulem vários protocolos de passageiro como mostrado na imagem.

Um administrador de rede considera o tunelamento em uma situação em que há duas redes não-IPv4 não contíguas separadas por um backbone IPv4.

Se as redes não contíguas executarem DECnet, o administrador poderá optar por conectá-las juntas (ou não) configurando DECnet no backbone.

O administrador não deseja permitir que o roteamento DECnet consuma largura de banda de backbone, pois isso poderia interferir no desempenho da rede IPv4.

Uma alternativa viável é fazer um túnel DECnet no backbone IPv4. A solução de túnel encapsula os pacotes DECnet dentro do IPv4 e os envia pelo backbone para o ponto final do túnel onde o encapsulamento é removido e os pacotes DECnet são roteados para seu destino via DECnet.

Há vantagens em encapsular o tráfego dentro de outro protocolo:

• Os endpoints usam endereços privados (RFC 1918) e o backbone não oferece suporte ao roteamento desses endereços.

• Permitem redes virtuais privadas (VPNs) através de WANs ou Internet.

• Unem redes de multiprotocolos descontíguas em um backbone de protocolo único.

• Criptografam o tráfego ao longo do backbone ou da Internet.

Daqui em diante, o IPv4 é usado como o protocolo de passageiro e o IPv4 como o protocolo de transporte.

Considerações com relação às interfaces de túnel

Estas são considerações sobre tunelamento.

• O switching rápido de túneis GRE foi introduzido no Cisco IOS® versão 11.1 e o switching de CEF foi introduzido na versão 12.0.

• O switching de CEF para túneis GRE de vários pontos foi introduzido na versão 12.2(8)T.

• O encapsulamento e o desencapsulamento no terminal de túnel eram operações lentas em versões anteriores do Cisco IOS® , quando havia suporte somente ao switching de processo.

• Há problemas de segurança e topologia no tunelamento de pacotes. Os túneis podem desviar listas de controle de acesso (ACLs) e firewalls.

• Se você criar um túnel através de um firewall, você ignora o protocolo de passageiro sendo colocado em túnel. Portanto, é recomendável incluir a funcionalidade do firewall nos endpoints do túnel para aplicar qualquer política aos protocolos de passageiro.

• O tunelamento cria problemas com protocolos de transporte que têm temporizadores limitados (por exemplo, DECnet) devido ao aumento da latência.

• O encapsulamento em ambientes com diferentes links de velocidade, como anéis FDDI rápidos e linhas telefônicas lentas de 9600 bps, apresenta problemas de reordenação de pacotes. Alguns protocolos passageiros apresentam baixo desempenho nas redes de mídia mista.

• Os túneis ponto a ponto consomem largura de banda em um link físico. Em vários túneis ponto a ponto, cada interface de túnel tem uma largura de banda e a interface física sobre a qual o túnel é executado tem uma largura de banda. Por exemplo, defina a largura de banda do túnel como 100 Kb se houver 100 túneis sendo executados em um link de 10 Mb. A largura de banda padrão para um túnel é 9Kb.

• Os protocolos de roteamento preferem um túnel sobre um link real porque o túnel aparenta ser um link de um salto com o caminho de menor custo, embora envolva mais saltos e, portanto, mais caro que outro caminho. Isso é atenuado com a configuração adequada do protocolo de roteamento. Considere a execução de um protocolo de roteamento diferente na interface de túnel do que o protocolo de roteamento em execução na interface física.

• Os problemas com o roteamento recursivo são evitados com a configuração de rotas estáticas apropriadas para o destino do túnel. Uma rota recursiva ocorre quando o melhor caminho para o destino do túnel é pelo próprio túnel. Essa situação faz com que a interface de túnel salte para cima e para baixo. Esse erro é visto quando há um problema de roteamento recursivo.

  %TUN-RECURDOWN Interface Tunnel 0
  temporarily disabled due to recursive routing

Roteador como participante PMTUD no endpoint do túnel

O roteador tem duas funções PMTUD diferentes quando é o ponto final de um túnel.

• Na primeira função, o roteador é o remetente de um pacote de host. Para o processamento de PMTUD, o roteador precisa verificar o tamanho do bit DF e do pacote de dados original para executar a ação apropriada, quando necessário.

• A segunda função ocorre após o roteador encapsular o pacote IPv4 original do host dentro do pacote de túnel. Nessa fase, o roteador atua mais com um host em relação ao PMTUD e ao pacote IPv4 do túnel.

Quando o roteador atua na primeira função (um roteador que encaminha pacotes IPv4 do host), essa função entra em ação antes de o roteador encapsular o pacote IPv4 do host dentro do pacote de túnel.

Se o roteador participa como o encaminhador de um pacote de host, ele conclui estas ações:

• Verifica se o bit DF está definido.

• Verifica qual tamanho de pacote o túnel pode comportar.

• Fragmento (se o pacote for muito grande e o bit DF não estiver definido), encapsule os fragmentos e envie; ou

• Descarta o pacote (se o pacote for muito grande e o bit DF estiver definido) e envia uma mensagem de ICMP para o remetente.

• Encapsula (se o pacote não for muito grande) e envia.

Genericamente, há uma escolha de encapsulamento e fragmentação (envia dois fragmentos de encapsulamento) ou fragmentação e encapsulamento (envia dois fragmentos encapsulados).

Dois exemplos que mostram a interação de PMTUD e pacotes que atravessam redes de exemplo sã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.

Para processar PMTUD, o roteador precisa verificar o bit DF e o tamanho do pacote do pacote de dados original e tomar a ação apropriada.

Este exemplo usa encapsulamento GRE para o túnel. 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 do túnel) recebe um datagrama de 1500 bytes com o bit DF limpo (DF = 0) do host origem.

Esse datagrama é composto por um cabeçalho de IP de 20 bytes e um payload de TCP de 1480 bytes.

IPv4	TCP de 1.480 bytes + dados

 2. Como o pacote é muito grande para o MTU IPv4 depois que a sobrecarga de GRE (24 bytes) é adicionada, o roteador de encaminhamento divide o datagrama em dois fragmentos de 1476 (cabeçalho IPv4 de 20 bytes + payload IPv4 de 1456 bytes) e 44 bytes (cabeçalho IPv4 de 20 bytes + payload IPv4 de 24 bytes)

Depois que o encapsulamento de GRE é adicionado, o pacote não é maior do que o MTU da interface física de saída.

IP0	TCP de 1.456 bytes + dados

IP1	Dados de 24 bytes

 3. O roteador de encaminhamento adiciona o encapsulamento GRE, que inclui um cabeçalho GRE de 4 bytes mais 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.

IPv4

GRE

IP0

TCP de 1.456 bytes + dados

IPv4

GRE

IP1

Dados de 24 bytes

4. O roteador de destino do túnel remove o encapsulamento GRE de cada fragmento do datagrama original, o que deixa dois fragmentos IPv4 de comprimentos de 1476 e 24 bytes.

Esses fragmentos de datagrama de IPv4 são encaminhados separadamente por este roteador para o host destinatário.

IP0	TCP de 1.456 bytes + dados

IP1	Dados de 24 bytes

5. O host receptor reagrupa esses dois fragmentos no datagrama original.

IPv4	TCP de 1.480 bytes + dados

O Exemplo 2 descreve a função do roteador de encaminhamento no contexto de uma topologia de rede.

O roteador atua na mesma função do roteador de encaminhamento, mas desta 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.

IPv4	TCP de 1.480 bytes + dados

2. Como o bit DF está definido e o tamanho do datagrama (1500 bytes) é maior que o MTU IPv4 do túnel GRE (1476), o roteador descarta o datagrama e envia uma mensagem "fragmentação ICMP necessária, mas o bit DF definido" à origem do datagrama.

A mensagem ICMP alerta o remetente de que o MTU é 1476.

IPv4	MTU de ICMP de 1.476

3. O host origem recebe a mensagem ICMP e, quando reenvia os dados originais, usa um datagrama IPv4 de 1.476 bytes.

IPv4	TCP de 1.456 bytes + dados

4. O comprimento desse datagrama IPv4 (1476 bytes) agora é igual em valor à MTU IPv4 do túnel GRE, de modo que o roteador adicione o encapsulamento GRE ao datagrama IPv4.

IPv4

GRE

IPv4

TCP de 1.456 bytes + dados

5. O roteador receptor (no destino do túnel) remove o encapsulamento GRE do datagrama IPv4 e o envia ao host receptor.

IPv4	TCP de 1.456 bytes + dados

Isso é o que acontece quando o roteador atua na segunda função como um host de envio em relação ao PMTUD e em relação ao pacote IPv4 do túnel.

Essa função entra em ação depois que o roteador encapsula o pacote IPv4 original dentro do pacote de túnel.

Observação: Por padrão, um roteador não executa PMTUD nos pacotes de túnel GRE que gera. O tunnel path-mtu-discovery pode ser usado para ativar o PMTUD para pacotes de túnel GRE-IPv4.

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 para que o roteador não desative o PMTUD no pacote GRE-IPv4.

Exemplo 3

1. O roteador de encaminhamento na origem do túnel recebe um datagrama de 1.476 bytes do host de envio.

IPv4	TCP de 1.456 bytes + dados

2. Este roteador encapsula o datagrama IPv4 de 1.476 bytes dentro do GRE para obter um datagrama IPv4 GRE de 1.500 bytes.

O bit DF no cabeçalho IPv4 do GRE é apagado (DF = 0). Esse roteador encaminha, em seguida, esse pacote ao destino do túnel.

IPv4

GRE

IPv4

TCP de 1.456 bytes + dados

3. Suponha que haja um roteador entre a origem e o destino do túnel com um link MTU de 1400.

Esse roteador fragmenta o pacote de túnel, já que o bit DF está limpo (DF = 0).

Lembre-se de que este exemplo fragmenta o IPv4 mais externo, de modo que os cabeçalhos GRE, IPv4 interno e TCP só aparecem no primeiro fragmento.

IP0

GRE

IP

TCP de 1352 bytes + dados

IP1	Dados de 104 bytes

4. O roteador de destino do túnel deve remontar o pacote do túnel GRE.

IP

GRE

IP

TCP de 1.456 bytes + dados

5. Após a remontagem do pacote de túnel GRE, o roteador remove o cabeçalho IPv4 do GRE e envia o datagrama IPv4 original.

IPv4	TCP de 1.456 bytes + dados

O Exemplo 4 mostra o que acontece quando o roteador atua na função de um host emissor em relação ao PMTUD e em relação ao pacote IPv4 do túnel.

Desta vez, o bit DF é definido (DF = 1) no cabeçalho IPv4 original e o 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 origem do túnel recebe um datagrama de 1476 bytes com DF = 1 do host de envio.

IPv4	TCP de 1.456 bytes + dados

2. Este roteador encapsula o datagrama IPv4 de 1.476 bytes dentro do GRE para obter um datagrama IPv4 GRE de 1.500 bytes.

Esse cabeçalho IPv4 de GRE tem o conjunto de bits DF (DF = 1), já que o datagrama IPv4 original tinha o conjunto de bits DF.

Esse roteador encaminha, em seguida, esse pacote ao destino do túnel.

IPv4

GRE

IPv4

TCP de1456 bytes

3. Novamente, suponha que haja um roteador entre a origem e o destino do túnel com um link MTU de 1400.

Esse roteador não fragmenta o pacote de túnel porque o bit DF está definido (DF=1).

Esse roteador deve descartar o pacote e enviar uma mensagem de erro ICMP ao roteador de origem do túnel, pois esse é o endereço IPv4 de origem no pacote.

IPv4	MTU de ICMP de 1.400

4. O roteador de encaminhamento na origem do túnel recebe essa mensagem de erro "ICMP" e reduz o MTU IPv4 do túnel GRE para 1376 (1400 - 24).

Na próxima vez que o host emissor retransmitir os dados em um pacote IPv4 de 1.476 bytes, esse pacote poderá ser muito grande e esse roteador enviará uma mensagem de erro "ICMP" ao remetente com um valor de MTU de 1.376.

Quando o host emissor retransmite os dados, ele os envia em um pacote IPv4 de 1.376 bytes e esse pacote faz isso através do túnel GRE para o host receptor.

Exemplo 5

Este exemplo ilustra a fragmentação de GRE. Fragmente antes do encapsulamento para o GRE, depois faça PMTUD para o pacote de dados e o bit DF não será copiado quando o pacote IPv4 for encapsulado pelo GRE.

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.

1. O remetente envia um pacote de 1.500 bytes (cabeçalho IPv4 de 20 bytes + 1.480 bytes de payload de TCP).
2. Como o MTU do túnel GRE é 1476, o pacote de 1500 bytes é dividido em dois fragmentos IPv4 de 1476 e 44 bytes, cada um em antecipação dos 24 bytes adicionais do cabeçalho GRE.
3. Os 24 bytes do cabeçalho GRE são adicionados a cada fragmento de IPv4. Agora os fragmentos têm 1.500 (1.476 + 24) e 68 (44 + 24) bytes cada.
4. Os pacotes IP + GRE que contêm os dois fragmentos IPv4 são encaminhados para o roteador de túnel GRE correspondente.
5. O roteador do par do túnel GRE remove os cabeçalhos GRE dos dois pacotes.
6. Esse roteador encaminha os dois pacotes para o host de destino.
7. O host de destino reagrupa os fragmentos IPv4 de volta ao datagrama IP original.

Exemplo 6

Este exemplo é semelhante ao Exemplo 5, mas desta vez o bit DF está definido. O roteador está configurado para fazer PMTUD em pacotes de túnel GRE + IPv4 com o comando tunnel path-mtu-discoverye 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.

O MTU IPv4 do túnel GRE é definido como 24 bytes a menos do que o MTU da interface física por padrão, portanto o MTU IPv4 do GRE aqui é 1476. Há um link de MTU de 1400 no caminho do túnel GRE, como mostrado na imagem.

1. O roteador recebe um pacote de 1.500 bytes (cabeçalho IPv4 de 20 bytes + payload TCP de 1.480), e ele descarta o pacote. O roteador descarta o pacote porque é maior do que o IPv4 de MTU (1.476) na interface de túnel GRE.
2. O roteador envia um erro ICMP ao remetente informando que o próximo MTU de nó é 1476. O host registra essas informações, geralmente como uma rota de host para o destino em sua tabela de roteamento.
3. O host de envio usa um tamanho de pacote de 1.476 bytes quando reenvia os dados. O roteador GRE acrescenta 24 bytes de encapsulamento de GRE e envia um pacote de 1500 bytes.
4. O pacote de 1500 bytes não pode atravessar o enlace de 1400 bytes; portanto, será descartado pelo roteador intermediário.
5. O roteador intermediário envia um ICMP (tipo = 3, código = 4) para o roteador GRE com um MTU de próximo salto de 1.400. O roteador GRE reduz isso a 1.376 (1.400-24) e define um valor de MTU de IPv4 interno na interface GRE. Essa alteração só pode ser vista quando você usa o comando debug tunnel não pode ser visto na saída do comando show ip interface tunnel<#> comando.
6. Na próxima vez que o host reenviar o pacote de 1.476 bytes, o roteador GRE descartará o pacote, já que ele é maior que o MTU atual do IPv4 (1.376) na interface de túnel GRE.
7. O roteador GRE envia outro ICMP (tipo = 3, código = 4) ao remetente com um MTU do próximo salto de 1376 e o host atualiza suas informações atuais com um novo valor.
8. O host envia novamente os dados, mas agora em um pacote menor de 1.376 bytes, o GRE adiciona 24 bytes de encapsulamento e os encaminha. Desta vez, o pacote chega ao peer de túnel GRE, onde o pacote é desencapsulado e enviado ao host de destino.

Nota: Se a tunnel path-mtu-discovery não foi configurado no roteador de encaminhamento nesse cenário, e o bit DF foi definido nos pacotes encaminhados através do túnel GRE, o host 1 ainda consegue enviar pacotes TCP/IPv4 para o host 2, mas eles ficam fragmentados no meio no link MTU 1400. Além disso, o par de túnel GRE precisa remontá-los antes que possa desencapsulá-los e encaminhá-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 do IPv4sec, mas não excedem ~58 bytes (ESP (Encapsulating Security Payload) e autenticação ESP (ESPauth)) por pacote.

O IPv4sec tem dois modos, o modo de túnel e o modo de transporte.

1. Modo de túnel é o modo padrão. No modo de túnel, todo pacote IPv4 original é protegido (criptografado, autenticado ou ambos) e encapsulado pelos cabeçalhos e rodapés IPv4sec. Em seguida, um novo cabeçalho IPv4 é anexado ao pacote, especificando os endpoints de IPv4sec (pares) como a origem e o destino. O modo de túnel pode ser usado com qualquer tráfego IPv4 unicast e deve ser usado se o IPv4sec protege o tráfego contra hosts escondidos nos pares IPv4sec. Por exemplo, o modo de túnel é usado em Redes virtuais privadas (VPNs), onde hosts em uma rede protegida enviam pacotes para hosts em uma rede diferente por meio de um par de pares IPv4sec. Com VPNs, o "túnel" IPv4sec protege o tráfego de IPv4 entre os hosts ao criptografar esse tráfego entre os roteadores de pares IPv4sec.
2. Com o modo de transporte (configurado com o subcomando, mode transport, na definição de transformação), somente o payload do pacote IPv4 original é protegido (criptografado, autenticado ou ambos). O payload é encapsulado pelos cabeçalhos e trailers de IPv4sec. Os cabeçalhos IPv4 originais permanecem intactos, exceto o campo de protocolo IPv4 que é alterado para ESP (50), e o valor do protocolo original é salvo no trailer IPv4sec para ser restaurado quando o pacote for descriptografado. O modo de transporte é usado apenas quando o tráfego IPv4 a ser protegidos está entre os pares de IPv4sec, a origem e os endereços IPv4 de destino no pacote são os mesmos que os endereços de mesmo nível de IPv4sec. Normalmente o modo de transporte IPv4sec é usado somente quando um outro protocolo de encapsulamento (como GRE) for usado para encapsular primeiro o pacote de dados IPv4, em seguida, o IPv4sec é usado para proteger os pacotes de túnel GRE.

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".

Observação: evite a fragmentação após o encapsulamento quando a criptografia de hardware com IPv4sec estiver concluída. A criptografia de hardware oferece um rendimento de cerca de 50 Mbs, que depende do hardware, mas se o pacote IPv4sec estiver fragmentado, você perderá de 50 a 90% do rendimento. 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).

Exemplo 7

Este 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.

1. O roteador recebe um pacote de 1.500 bytes (cabeçalho IPv4 de 20 bytes + payload TCP de 1.480) destinado para o Host 2.
2. O pacote de 1.500 bytes é criptografado por IPv4sec e 52 bytes de sobrecarga são adicionados (cabeçalho IPv4sec, trailer e cabeçalho adicional do IPv4). Agora, o IPv4sec precisa enviar um pacote de 1.552 bytes. Como o MTU de saída é 1500, esse pacote precisa ser fragmentado.
3. Dois fragmentos são criados fora do pacote IPv4sec. Durante a fragmentação, um cabeçalho IPv4 adicional de 20 bytes é adicionado ao segundo fragmento, o que resulta em um fragmento de 1.500 bytes e um fragmento IPv4 de 72 bytes.
4. O roteador de par do túnel IPv4sec recebe os fragmentos, remove o cabeçalho IPv4 adicional e agrupa os fragmentos IPv4 de volta ao pacote original do IPv4sec. Em seguida, o IPv4sec descriptografa esse pacote.
5. O roteador encaminha o pacote de dados original de 1500 bytes para o Host 2.

Exemplo 8

Este exemplo é semelhante ao Exemplo 6, exceto que, neste caso, o bit DF é definido no pacote de dados original e há um link no caminho entre os peers de túnel IPv4sec que tem uma MTU mais baixa que os outros links.

Este exemplo demonstra como o roteador de peer IPv4sec executa ambas as funções PMTUD, conforme descrito na seção O roteador como um participante PMTUD no ponto final de um túnel.

O PMTU do IPv4sec é alterado para um valor mais baixo como resultado da necessidade de fragmentação.

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.

O IPv4sec encapsula/criptografa o pacote antes de tentar fragmentá-lo, como mostrado na imagem.

1. O roteador recebe um pacote de 1.500 bytes e o descarta porque a sobrecarga de IPv4sec, quando adicionada, torna o pacote maior que o PMTU (1.500).
2. O roteador envia uma mensagem ICMP ao Host 1 informando-o de que o MTU do próximo salto é 1442 (1500 - 58 = 1442). Esses 58 bytes são a sobrecarga máxima do IPv4sec quando você usa ESP e ESPauth do IPv4sec. A sobrecarga real do IPv4sec é possivelmente 7 bytes menor que esse valor. O Host 1 registra esta informação, geralmente como uma rota de host para o destino (Host 2), em sua tabela de roteamento.
3. O Host 1 reduz o PMTU do Host 2 para 1442, de modo que o Host 1 envia pacotes menores (1442 bytes) quando retransmite os dados para o Host 2. O roteador recebe o pacote 1.442 bytes e o IPv4sec adiciona 52 bytes de sobrecarga de criptografia, então o pacote IPv4sec resultante é de 1.496 bytes. Como esse pacote tem o DF bit definido no cabeçalho, ele é descartado pelo roteador do meio com o link de MTU de 1.400 bytes.
4. O roteador do meio que descartou o pacote envia uma mensagem ICMP para o remetente do pacote IPv4sec (o primeiro roteador) dizendo que o MTU do próximo salto é de 1.400 bytes. Esse valor é registrado no PMTU de SA do IPv4sec.
5. Na próxima vez que o Host 1 retransmitir o pacote de 1.442 bytes (ele não recebeu uma confirmação para ele), o IPv4sec descartará o pacote. O roteador descarta o pacote porque a sobrecarga de IPv4sec, quando adicionada ao pacote, o torna maior que o PMTU (1400).
6. O roteador envia uma mensagem ICMP para o Host 1 dizendo que o MTU do próximo salto agora é de 1.342. (1.400 - 58 = 1.342). O Host 1 registra essas informações novamente.
7. Quando o Host 1 retransmite os dados, ele usa o pacote de tamanho menor (1342). Esse pacote não requer fragmentação e passa pelo túnel IPv4sec para o Host 2.

GRE e IPv4sec juntos

As 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.

Quando você faz isso, o IPv4sec é frequentemente implantado no modo de transporte sobre o GRE, pois os peers do IPv4sec e os pontos finais do túnel GRE (os roteadores) são os mesmos, e o modo de transporte economiza 20 bytes de sobrecarga do IPv4sec.

Um caso interessante é quando um pacote IPv4 tiver sido dividido em dois fragmentos e encapsulado pelo GRE.

Nesse caso, o IPv4sec vê dois pacotes GRE + IPv4 independentes. Muitas vezes, em uma configuração padrão, um desses pacotes é grande o suficiente para que ele precise ser fragmentado depois de ter sido criptografado.

O par IPv4sec precisa remontar este pacote antes da descriptografia. 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.

A remontagem é comutada por processo, portanto há um acerto de CPU no roteador receptor sempre que isso acontece.

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 túnel/modo que supõe que a interface física de saída tenha um MTU de 1500.

Combinação de Túneis	MTU específico necessário	MTU recomendado
GRE + IPsec (Modo de transporte)	1440 bytes	1400 bytes
GRE + IPsec (Modo de túnel)	1420 bytes	1400 bytes

Observação: o valor de MTU de 1400 é recomendado porque cobre as combinações de modo 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.

Exemplo 9

O 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).

Os pacotes TCP/IPv4 são, portanto, fragmentados duas vezes, uma antes do GRE e outra depois do IPv4sec.

O pacote é fragmentado antes do encapsulamento GRE e um desses pacotes GRE é fragmentado novamente após a criptografia 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.

1. O roteador recebe um datagrama de 1.500 bytes.
2. Antes do encapsulamento, o GRE fragmenta o pacote de 1.500 bytes em dois pedaços, 1.476 (1.500-24 = 1.476) e 44 (24 dados + 20 cabeçalhos IPv4) bytes.
3. O GRE encapsula os fragmentos IPv4, acrescentando 24 bytes a cada pacote. Isso resulta em dois pacotes GRE + IPv4sec de 1.500 (1.476 + 24 = 1.500) e 68 (44 + 24) bytes cada.
4. O IPv4sec criptografa os dois pacotes, que adicionam 52 bytes (modo de túnel IPv4sec) de sobrecarga de encapsulamento a cada um, para fornecer um pacote de 1552 bytes e um pacote de 120 bytes.
5. O pacote IPv4sec de 1.552 bytes é fragmentado pelo roteador porque é maior do que o MTU de saída (1.500). O pacote de 1.552 bytes é dividido em partes, um pacote de 1.500 bytes e um pacote de 72 bytes (52 bytes "de payload" mais um cabeçalho de IPv4 de 20 bytes adicional para o segundo fragmento). Os três pacotes de 1.500 bytes, 72 bytes e 120 bytes são encaminhados para o par IPv4sec + GRE.
6. O roteador destinatário remonta a dois fragmentos de IPv4sec (1.500 bytes e 72 bytes) para compor o pacote de IPv4sec de 1.552 bytes + pacote GRE original. Nada precisa ser feito para o pacote IPv4sec + GRE de 120 bytes.
7. O IPv4sec descriptografa os pacotes IPv4sec + GRE de 1.552 bytes e 120 bytes para obter pacotes GRE de 68 bytes e de 1.500 bytes.
8. O GRE desencapsula os pacotes GRE de 1.500 bytes e de 68 bytes para obter fragmentos de pacotes IPv4 de 1.476 bytes e 44 bytes. Esses fragmentos de pacotes IPv4 são encaminhados para o host de destino.
9. O Host 2 remonta esses fragmentos IPv4 para obter o datagrama IPv4 original de 1.500 bytes.

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á correto para as conexões TCP entre o Host 1 e o Host 2. Os fluxos de TCP entre o Host 1 e outros hosts (acessíveis via túnel IPv4sec + GRE) só precisam passar pelas últimas três etapas do Cenário 10.

Neste cenário, o tunnel path-mtu-discovery é configurado no túnel GRE e o bit DF é definido em pacotes TCP/IPv4 que se originam do Host 1.

Exemplo 10

• O roteador recebe um pacote de 1.500 bytes. Este pacote é descartado pelo GRE porque o GRE não pode fragmentá-lo ou encaminhá-lo, pois o bit DF está definido, e o tamanho do pacote excede a interface de saída "ip mtu" depois de adicionar o overhead do GRE (24 bytes).
• O roteador envia uma mensagem ICMP ao Host 1 para informar que o MTU do próximo salto agora é de 1.476 (1.500 - 24 = 1.476)
• O Host 1 altera o PMTU do Host 2 para 1.476 e envia o menor tamanho quando retransmite o pacote. O GRE o encapsula e entrega o pacote de 1.500 bytes para o IPv4sec. O IPv4sec descarta o pacote porque o GRE copiou o bit DF (definido) do cabeçalho IPv4 interno e, com o overhead de IPv4sec (máximo de 38 bytes), o pacote é muito grande para encaminhamento fora da interface física.
• O IPv4sec envia uma mensagem ICMP ao GRE que indica que o MTU do próximo salto é de 1462 bytes (já que um máximo de 38 bytes são adicionados para criptografia e sobrecarga de IPv4). O GRE registra o valor 1.438 (1.462-24) como o "ip mtu" da interface de túnel.
• Observação: essa alteração no valor é armazenada internamente e não pode ser vista na saída do comando show ip interface tunnel<#>comando. Você só verá essa alteração se virar e usar o comando debug tunnel comando.
• Da próxima vez que o Host 1 retransmitir o pacote de 1.476 bytes, ele será descartado pelo GRE.
• O roteador envia uma mensagem ICMP para o Host 1, que indica que 1.438 é o MTU do próximo salto.
• O Host 1 reduz o PMTU para o Host 2 e retransmite um pacote de 1.438 bytes. Desta vez, o GRE aceita o pacote, o encapsula e entrega ao IPv4sec para criptografia.
• O pacote de IPv4sec é encaminhado para o roteador intermediário e descartado porque tem uma interface de saída MTU de 1.400.
• O roteador intermediário envia uma mensagem ICMP para o IPv4sec dizendo que o MTU do próximo salto é de 1.400. Esse valor é gravado pelo IPv4sec no valor de PMTU do SA de IPv4sec associado.
• Quando o Host 1 retransmite o pacote de 1.438 bytes, o GRE o encapsula e entrega para o IPv4sec. O IPv4sec descarta o pacote porque mudou seu próprio PMTU para 1.400.
• O IPv4sec envia um erro de ICMP ao GRE, indicando que o MTU do próximo salto é de 1.362, e o GRE registra o valor 1.338 internamente.
• Quando o Host 1 retransmite o pacote original (porque não recebeu uma confirmação de recebimento), ele é descartado pelo GRE.
• O roteador envia uma mensagem ICMP ao Host 1, indicando que o MTU do próximo salto é de 1.338 (1.362 - 24 bytes). O Host 1 reduz para 1.338 o PMTU para o Host 2.
• O Host 1 retransmite um pacote de 1.338 bytes e dessa vez pode finalmente chegar até o fim para o Host 2.

Outras recomendações

Configurando o tunnel path-mtu-discovery em uma interface de túnel pode ajudar na interação de GRE e IPv4sec quando eles são configurados no mesmo roteador.

Sem a tunnel path-mtu-discovery configurado, o bit DF sempre seria apagado no 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 a tunnel path-mtu-discovery está configurado na interface túnel GRE:

1. O GRE copia o bit DF do cabeçalho IPv4 de dados para o cabeçalho IPv4 do GRE.
2. Se o bit DF estiver definido no cabeçalho IPv4 do GRE e o pacote for "muito grande" após a criptografia IPv4sec para o MTU de IPv4 na interface de saída física, o IPv4sec descartará o pacote e notificará o túnel GRE para reduzir seu tamanho de MTU de IPv4.
3. O IPv4sec realiza PMTUD para seus próprios pacotes e se o PMTU do IPv4sec for alterado (se for reduzido), o IPv4sec não notificará imediatamente o GRE, mas quando outro pacote maior for enviado, ocorrerá o processo na etapa 2.
4. O MTU IPv4 do GRE agora é menor, portanto ele descarta todos os pacotes IPv4 de dados com o bit DF definido que agora são muito grandes e envia uma mensagem ICMP para o host de envio.

O tunnel path-mtu-discovery ajuda a interface GRE a definir seu MTU IPv4 dinamicamente, em vez de estaticamente com o comando ip mtu comando. Na verdade, recomenda-se que os dois comandos sejam usados.

O ip mtu é usado para fornecer espaço para a sobrecarga de GRE e IPv4sec relativa ao MTU IPv4 da interface física de saída local.

O tunnel path-mtu-discovery permite que a MTU IPv4 do túnel GRE seja reduzida ainda mais se houver um link de MTU IPv4 mais baixo no caminho entre os pares 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.

1. Corrija o problema do PMTUD que não está funcionando, geralmente causado por um roteador ou firewall que bloqueia o ICMP.
2. Use o ip tcp adjust-mss nas interfaces de túnel para que o roteador reduza o valor TCP MSS no pacote TCP SYN. Isso ajuda os dois hosts finais (o emissor e o receptor TCP) a usar pacotes pequenos o suficiente para que o PMTUD não seja necessário.
3. Use o roteamento de política na interface de ingresso do roteador e configure um mapa de rota para liberar o bit DF no cabeçalho IPv4 de dados antes de chegar à interface de túnel GRE. Isso permite que o pacote IPv4 de dados seja fragmentado antes do encapsulamento de GRE.
4. Aumente o "ip mtu" da interface de túnel GRE para que seja igual ao MTU da interface de saída. Isso permite que o pacote IPv4 de dados seja encapsulado em GRE sem antes fragmentá-lo. O pacote GRE é criptografado por IPv4sec e, em seguida, fragmentado para sair da interface de saída física. Nesse caso, você não configuraria tunnel path-mtu-discovery na interface do túnel GRE. Isso pode reduzir significativamente a taxa de transferência porque remontagem do pacote IPv4 no peer IPv4sec é feita no modo de switching de processos.

Informações Relacionadas

• Página de Suporte do IP Routing
• Página de suporte do IPSec (protocolo de segurança IP)
• Calculadora de overhead de IPSec (calcular o tamanho do pacote com protocolos de encapsulamento de IPSec)
• Descoberta de MTU de caminho RFC 1191
• Opções de descoberta de MTU RFC 1063 IP
• Protocolo de Internet RFC 791
• Protocolo de controle de transmissão RFC 793
• RFC 879 - O tamanho máximo do segmento de TCP e tópicos relacionados
• RFC 1701 Generic Routing Encapsulation (GRE)
• Esquema 1241 A de RFC para um protocolo de encapsulamento de Internet
• RFC 2003 IP Encapsulation within IP
• Suporte Técnico e Documentação - Cisco Systems