IP : Tunelamento IP

Solução de Problemas de Fragmentação de IP, MTU, MSS e PMTUD com GRE e IPSEC

3 Abril 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (14 Janeiro 2008) | Feedback


Índice

Introdução
Fragmentação de IP e Remontagem
     Problemas de Fragmentação de IP
     Evitando Fragmentação de IP: O que o TCP MSS Faz e Como Ele Funciona
O que é PMTUD?
     Problemas com o PMTUD
     Topologias Comuns de Rede que Necessitam do PMTUD
O que é um Túnel?
     Considerações Referentes a Interfaces de Túnel
     O Roteador como um Participante do PMTUD no Ponto Final de um Túnel
Modo "Puro" Túnel de IPsec
GRE e IPsec Juntos
Mais Recomendações
Discussões relacionadas da comunidade de suporte da Cisco
Informações Relacionadas

Introdução

O objetivo deste documento é apresentar como a Fragmentação de IP e a descoberta da unidade de transmissão máxima do caminho (PMTUD) funcionam e discutir alguns cenários que envolvem o comportamento de PMTUD quando combinado com diferentes combinações de túneis IP. O uso atualmente difundido de túneis de IP na Internet trouxe problemas que envolvem a Fragmentação de IP e a PMTUD.

Fragmentação de IP e Remontagem

O protocolo IP foi desenhado para ser usado em uma ampla variedade de links de transmissão. Embora o comprimento máximo de um datagrama IP seja 64K, a maioria dos links de transmissão reforça um limite máximo de comprimento de pacote, chamado MTU. O valor de MTU depende do tipo do link de transmissão. O desenho do IP acomoda diferenças de MTU, permitindo que os roteadores fragmentem datagramas IP conforme necessário. A estação de recebimento é responsável por remontar os fragmentos de volta no datagrama IP de tamanho original normal.

A Fragmentação de IP envolve a fragmentação de um datagrama em vários pedaços que podem ser remontados posteriormente. A fonte, o destino, a identificação, o comprimento total e os campos de compensação de fragmentação de IP, juntamente com os flags “more fragments” (mais fragmentos) e “don’t fragment” (não fragmentar) do cabeçalho IP, são utilizados para fragmentação e remontagem de IP. Para obter mais informações sobre os mecanismos de fragmentação e remontagem de IP, consulte RFC 791 leavingcisco.com.

A imagem a seguir mostra o layout de um cabeçalho IP.

pmtud_ipfrag_01.gif

A identificação é de 16 bits e é um valor atribuído pelo remetente de um datagrama IP para ajudar na remontagem de fragmentos de um datagrama.

O deslocamento do fragmento é de 13 bits e indica a posição à qual o fragmento pertence no datagrama IP original. Esse valor é um múltiplo de oito bytes.

No campo de flags do cabeçalho IP há três bits para flags de controle. É importante observar que o bit "don't fragment" (DF) desempenha uma função central na PMTUD, pois determina se um pacote pode ou não ser fragmentado.

O bit 0 é reservado e está sempre definido como 0. O bit 1 é o bit DF (0 = "may fragment" (pode fragmentar) 1 = "don't fragment"). O bit 2 é o bit MF (0 = "last fragment" (último fragmento) 1 = "more fragments").

Valor

Bit 0 Reservado

Bit 1 DF

Bit 2 MF

0

0

Pode ser fragmentado

Último

1

0

Não pode ser fragmentado

Mais

O gráfico a seguir mostra um exemplo de fragmentação. Se você adicionar todos os comprimentos dos fragmentos IP, o valor excederá o comprimento original do datagrama IP em 60. O fato de o comprimento geral ter aumentado em 60 se deve à criação de três cabeçalhos IP adicionais, 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 do cabeçalho IP original ligeiramente modificado.

O segundo fragmento foi um deslocamento de 185 (185 x 8 = 1480), o que significa que a porção de dados desse fragmento começa com 1480 bytes no datagrama IP original. O comprimento desse fragmento é 1500; isso inclui o cabeçalho IP adicional criado para esse fragmento.

O terceiro fragmento tem um deslocamento de 370 (370 x 8 = 2960), o que significa que a parte de dados desse fragmento começa com 2960 bytes no datagrama IP original. O comprimento desse fragmento é 1500; isso inclui o cabeçalho IP adicional criado para esse fragmento.

O quarto fragmento tem uma compensação de 555 (555 x 8 = 4440), que significa que a parte de dados desse fragmento começa com 4440 bytes no datagrama IP original. O comprimento desse fragmento é de 700 bytes; isso inclui o cabeçalho IP adicional criado para esse fragmento.

Apenas quando o último fragmento é recebido, o tamanho do datagrama IP original pode ser determinado.

O deslocamento no último fragmento (555) fornece um deslocamento de dados de 4440 bytes para o datagrama IP original. Se, em seguida, adicionar os bytes de dados do último fragmento (680 = 700 - 20), você obterá 5120 bytes, o que representa a porção de dados do datagrama IP original. Portanto, adicionar 20 bytes a um cabeçalho IP, igualará o tamanho do datagrama IP original (4440 + 680 + 20 = 5140).

pmtud_ipfrag_02.gif

Problemas de Fragmentação de IP

Existem vários problemas que tornam a fragmentação de IP indesejável. Quando um datagrama IP é fragmentado, ocorre um pequeno aumento na sobrecarga de CPU e de memória. Isso continua verdadeiro para o remetente e para um roteador no caminho entre o remetente e o receptor. A criação de fragmentos envolve simplesmente a criação de cabeçalhos de fragmentos e a cópia do datagrama original nos fragmentos. Essa tarefa é eficaz porque todas as informações necessárias para a criação dos fragmentos são imediatamente disponibilizadas.

A fragmentação resulta em sobrecarga para o receptor na remontagem dos fragmentos, pois o receptor precisa alocar memória para os fragmentos chegando e mesclá-los de volta no datagrama, depois que todos os fragmentos são recebidos. A remontagem em um host não é considerada um problema, porque o host tem recursos de memória e tempo para executar essa tarefa.

A remontagem, no entanto, é muito ineficiente em um roteador cuja função principal é encaminhar pacotes o mais rápido possível. Os roteadores não são desenhados para manter pacotes; nem que seja por um curto período. Além disso, um roteador que realiza remontagem escolhe o maior buffer disponível (18K) para trabalhar, pois ele só tem como saber o tamanho do pacote IP original quando o fragmento é recebido.

Outro problema de fragmentação envolve o tratamento de fragmentos descartados. Se um fragmento de um datagrama IP for descartado, o datagrama IP original inteiro deverá ser reenviado, e também será fragmentado. Você verá um exemplo disso com o NFS (Network File System). O NFS, por padrão, tem um tamanho de bloco de leitura e de gravação de 8192; portanto, um datagrama de IP/UDP NFS será de aproximadamente 8500 bytes (incluindo cabeçalhos NFS, UDP e IP). Uma estação de envio conectada a uma Ethernet (MTU 1500) terá que fragmentar o datagrama de 8500 bytes em seis partes; cinco fragmentos de 1500 bytes e um fragmento de 1100 bytes. Se algum dos seis fragmentos for descartado em razão de um link congestionado, o datagrama original completo precisará ser retransmitido, o que significa que mais seis fragmentos terão que ser criados. Se esse link descartar um dos seis pacotes, é pouco provável que algum dado NFS possa ser transferido por esse link, pois pelo menos um fragmento IP seria descartado de cada datagrama IP original de 8500 bytes do NFS.

Os firewalls que filtram ou manipulam pacotes baseados em informações da Camada 4 (L4) até a Camada 7 (L7) no pacote podem ter problemas para processar fragmentos IP corretamente. Se os fragmentos IP estiverem danificados, o firewall poderá bloquear os fragmentos não iniciais porque eles não carregam as informações que correspondem ao filtro de pacote. Isso significaria que o datagrama IP original não poderia ser remontado pelo host de recebimento. Se o firewall estiver configurado para permitir que fragmentos não iniciais com informações insuficientes sejam compatíveis com o filtro, poderá ocorrer um ataque de fragmento não inicial pelo firewall. Além disso, alguns dispositivos de rede (como Content Switch Engines) direcionam pacotes baseados nas informações de L4 a L7 e, se um pacote abranger vários fragmentos, o dispositivo pode ter problemas reforçando as respectivas políticas .

Evitando Fragmentação de IP: O que o TCP MSS Faz e Como Ele Funciona

O Maximum Segment Size (MSS) do TCP define a quantidade máxima de dados que um host pode aceitar em um datagrama TCP/IP simples. Esse datagrama TCP/IP pode estar fragmentado na camada IP. O valor de MSS é enviado como uma opção de cabeçalho TCP apenas em segmentos TCP SYN. Cada lado de uma conexão TCP informa o seu valor de MSS ao outro lado. Ao contrário do que se pensa, o valor de MSS não é negociado entre hosts. O host de envio deve limitar o tamanho de dados de um segmento TCP simples a um valor igual ou inferior ao de MSS informado pelo host de recebimento.

Originalmente, MSS significava o tamanho do buffer (maior ou igual a 65496 K) alocado em uma estação de recebimento para que seja possível armazenar os dados de TCP incluídos em um único datagrama IP. O MSS era o segmento (bloco) máximo de dados que o receptor de TCP estava disposto a aceitar. Esse segmento TCP poderia ter 64K (o tamanho máximo de datagrama IP) e poderia estar fragmentado na camada de IP a fim de ser transmitido na rede para o host de recebimento. O host de recebimento remontava o datagrama IP antes de entregar o segmento completo de TCP à camada de TCP.

A seguir estão alguns cenários mostrando como os valores de MSS são definidos e usados para limitar tamanhos de segmentos de TCP e, portanto, valores de datagramas IP.

O cenário 1 ilustra a forma como o MSS foi implementado da primeira vez. O Host A tem um buffer de 16K e o Host B tem 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 IP que forem maiores do que o MTU da interface mas menores do que o MSS de envio, pois a pilha de TCP pode passar 16K ou 8K bytes de dados para baixo até o IP. No caso do Host B, os pacotes podem ser desfragmentados duas vezes: uma vez para chegar à LAN de Token Ring e outra vez para chegar À LAN de Ethernet.

Cenário 1

pmtud_ipfrag_03.gif

  1. O Host A envia seu valor de MSS de 16K para o Host B.

  2. O Host B recebe o valor de MSS de 16K do Host A.

  3. O Host B define seu valor de MSS de envio para 16K.

  4. O Host B envia seu valor de MSS de 8K para o Host A.

  5. O Host A recebe o valor de MSS de 8K do Host B.

  6. O Host A define seu valor de MSS de envio para 8K.

Para ajudar a impedir a fragmentação de IP nos pontos finais da conexão TCP, a seleção do valor de MSS foi alterada para o tamanho mínimo de buffer e o MTU da interface de saída (- 40). Os números MSS são 40 bytes menores que os números MTU, já que o MSS tem o tamanho de dados de TCP exato, que não inclui os cabeçalhos IP e TCP, ambos de 20 bytes. O MSS se baseia em tamanhos de cabeçalho padrão; a pilha de envio deve subtrair os valores apropriados relacionados ao cabeçalho IP e o cabeçalho TCP, dependendo de quais opções de TCP ou IP estão sendo usadas.

Agora, o MSS faz com que cada host compare primeiro o MTU da interface de saída com o próprio buffer e escolha o menor valor como o MSS a ser enviado. Em seguida, os hosts comparam o tamanho do MSS recebido com base no MTU de sua própria interface e escolhem novamente o menor dos dois valores.

O cenário 2 ilustra esta etapa adicional executada pelo remetente para evitar a fragmentação nos fios local e remoto. Observe como o MTU da interface de saída é levado em conta por cada host (antes de os hosts enviarem seus valores de MSS um ao outro) e como isso ajuda a evitar a fragmentação.

Cenário 2

pmtud_ipfrag_04.gif

  1. O Host A compara seu buffer de MSS (16K) e seu MTU (1500 - 40 = 1460) e usa o menor valor como o MSS (1460) para enviar ao Host B.

  2. O Host B recebe o MSS de envio (1460) do Host A e o compara ao valor do MTU da interface externa - 40 (4422).

  3. O Host B define o menor valor (1460) como o MSS para envio de datagramas IP para o Host A.

  4. O Host B compara seu buffer de MSS (8K) e seu MTU (4462 - 40 = 4422) e usa 4422 como o MSS para enviar ao Host A.

  5. O Host A recebe o MSS de envio (4422) do Host B e o compara ao valor do MTU da interface externa - 40 (1460).

  6. O Host A define o menor valor (1460) como o MSS para envio de datagramas IP para o Host B.

O valor escolhido por ambos os hosts como o MSS de envio de um para o outro é 1460. Geralmente, 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 pontos finais de uma conexão TCP, pois ambas as MTUs de interfaces de saída são levadas em consideração pelos hosts. É possível que os pacotes ainda sejam fragmentados na rede, entre os roteadores A e B, se encontrarem um link com um MTU inferior ao das interfaces externas dos hosts.

O que é PMTUD?

O MSS do TCP, como descrito acima, cuida da fragmentação nos dois pontos finais de uma conexão TCP, mas não trata do caso em que existe um pequeno link de MTU no meio, entre esses dois pontos finais. O PMTUD foi desenvolvido para evitar fragmentação no caminho entre os pontos finais. Ele é usado para determinar dinamicamente o MTU mais baixo ao longo do caminho, desde a origem até o destino de um pacote.

Observação: O PMTUD só é suportado pelo TCP. O UDP e demais protocolos não oferecem suporte a ele. SE o PMTUD estiver habilitado em um host, e ele quase sempre está, todos os pacotes TCP/IP do host terão o bit DF definido.

Quando um host envia um pacote de dados MSS completo com o bit DF marcado, o PMTUD reduz o valor do MSS de envio dessa conexão, caso receba informação de que o pacote requer fragmentação. O host normalmente “lembra” o valor de MTU de um destino criando uma entrada “host” (/32) na respectiva tabela de roteamento com esse valor de MTU.

Se um roteador tentar encaminhar um datagrama IP, com o bit DF definido, para um link com um MTU inferior ao tamanho do pacote, esse roteador descartará o pacote e retornará uma mensagem “Destino Inalcançável” do Internet Control Message Protocol (ICMP) à origem desse datagrama IP, com o código indicando "fragmentação necessária e DF definido" (tipo 3, código 4). Quando receber a mensagem ICMP, a estação de origem diminuirá o MSS de envio e, quando o TCP retransmitir o segmento, ele usará o menor tamanho de segmento.

Veja a seguir um exemplo de mensagem "fragmentação necessária e DF definido" do ICMP, que você pode ver em um roteador após ativar o comando debug ip icmp:

ICMP: dst (10.10.10.10) frag. needed and DF set
unreachable sent to 10.1.1.1

O diagrama abaixo mostra o formato do cabeçalho ICMP de uma mensagem "Destino inalcançável" de "fragmentação necessária e DF definido".

pmtud_ipfrag_05.gif

De acordo com a RFC 1191 leavingcisco.com, um roteador que retorna uma mensagem ICMP indicando "fragmentação necessária e DF definido", deve incluir o MTU dessa rede de próximo salto na ordem baixa de 16 bits do campo de cabeçalho ICMP adicional, rotulado como "não usado" na especificação RFC 792 leavingcisco.com de ICMP.

Implementações anteriores da RFC 1191 não ofereciam informações do MTU de próximo salto. Mesmo quando essas informações eram fornecidas, alguns hosts as ignoravam. Nesse caso, a RFC 1191 também contém uma tabela que lista os valores sugeridos em que o MTU deve ser reduzido durante o PMTUD. Ela é usada por hosts para se chegar mais rapidamente a um valor razoável para o MSS de envio.

pmtud_ipfrag_06.gif

O PMTUD é executado continuamente em todos os pacotes porque o caminho entre o remetente e o receptor pode ser alterado dinamicamente. Sempre que o remetente envia uma mensagem ICMP "Não é possível fragmentar", ele atualiza as informações de roteamento (onde armazena o PMTUD).

Duas coisas podem acontecer durante o PMTUD:

  • O pacote pode passar por todo o caminho para 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 de inalcançáveis ICMP que enviaria. Portanto, neste contexto, se você tiver um cenário de rede no qual espera que o roteador precise responder com mais de dois ICMPs (código = 3, tipo = 4) por segundo (podem ser hosts diferentes), convém desativar a aceleração das mensagens ICMP com o comando no ip icmp rate-limit unreachable [df] interface.

  • O remetente pode obter mensagens de ICMP "Cant Fragment" a partir de quaisquer (ou de todos) os nós ao longo do 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 do fluxo dispare uma das estações finais para reduzir o MSS de envio e a outra estação final mantenha o MSS de envio original, pois nunca enviou um datagrama IP grande o suficiente para disparar o MTUD.

Um bom exemplo disso é a conexão de HTTP mostrada a seguir, no Cenário 3. O cliente TCP está enviando pacotes pequenos e o servidor está enviando pacotes grandes. Neste caso, apenas os pacotes grandes de servidores (maiores do que 576 bytes) disparam 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

pmtud_ipfrag_07.gif

O Cenário 4 mostra um exemplo de roteamento assimétrico em que um dos caminhos tem um MTU mínimo menor do que o outro. O roteamento assimétrico ocorre quando caminhos diferentes são tomados para envio e recebimento de dados entre dois pontos finais. Neste cenário, o PMTUD disparará a redução do MSS de envio apenas em uma direção do fluxo de TCP. O tráfego do cliente TCP para o servidor flui pelos Roteadores A e B, ao passo que o tráfego de retorno, vindo do servidor para o cliente, flui pelos Roteadores D e C. Quando o servidor TCP envia pacotes para o cliente, o PMTUD dispara o servidor para reduzir o MSS de envio, pois o Roteador D precisa fragmentar os pacotes de 4092 bytes antes de poder enviá-los para o Roteador C.

O cliente, por outro lado, nunca receberá uma mensagem de ICPM “Destino Inalcançável” com o código indicando “fragmentation needed and DF set”, porque o Roteador A não tem que fragmentar pacotes quando faz o envio para o servidor por meio do Roteador B.

Cenário 4

pmtud_ipfrag_08.gif

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

Problemas com o PMTUD

Há três coisas que podem romper o PMTUD, duas incomuns e uma comum.

  • O roteador pode descartar um pacote e não enviar a mensagem ICMP. (Incomum)

  • O roteador pode gerar e enviar uma mensagem ICMP, mas a mensagem ICMP fica bloqueada por um roteador ou um firewall entre esse roteador e o remetente. (Comum)

  • O roteador pode gerar e enviar uma mensagem ICMP, mas o remetente ignora a mensagem. (Incomum)

O primeiro e o último dos três marcadores acima são incomuns e normalmente são resultantes de um erro, mas o marcador central descreve um problema comum. A pessoa que implementa filtros de pacotes de ICMP tende a bloquear todas as mensagens ICMP, em vez de bloquear apenas determinados tipos. Um filtro de pacote pode bloquear todos os tipos de mensagens ICMP, exceto as "inalcançáveis" ou com o "tempo excedido". O êxito ou a falha do PMTUD depende do fato de mensagens ICMP inalcançáveis conseguirem chegar ao remetente de um pacote TCP/IP. As mensagens de ICMP com o tempo excedido são importantes para outros problemas de IP. Veja a seguir um exemplo desse tipo de filtro de pacote implementado em um roteador:

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 úteis para amenizar o problema de o ICMP estar completamente bloqueado.

  • Elimine o bit DF no roteador e permita a fragmentação mesmo assim (Isso, no entanto, pode não ser uma boa idéia. Consulte Problemas de Fragmentação de IP para obter mais informações).

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

No Cenário 5 a seguir, os Roteadores A e B estão no mesmo domínio administrativo. O roteador C está inacessível e bloqueando o ICMP, portanto, o PMTUD foi interrompido. Uma alternativa para essa situação é eliminar o bit DF nas duas direções do Roteador B para permitir a fragmentação. Isso pode ser feito utilizando o roteamento de políticas. A sintaxe para eliminar e definir o bit DF está disponível no Cisco IOS® Software Release 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

pmtud_ipfrag_09.gif

Outra opção é alterar o valor de opção MSS do TCP em pacotes SYN que atravessem o roteador (disponível no Cisco IOS 12.2(4)T e posterior). Isso reduz o valor da opção MSS no pacote SYN de TCP de forma que ele seja inferior ao valor (1460) no comando ip tcp adjust-mss. O resultado é que o emissor do TCP não enviará segmentos maiores que esse valor. O tamanho do pacote IP será 40 bytes maior (1500) do que o valor de MSS (1460 bytes) para contabilização do cabeçalho TCP (20 bytes) e do cabeçalho IP (20 bytes).

É possível ajustar o MSS dos pacotes TCP SYN com o comando ip tcp adjust-mss. A sintaxe a seguir reduz o valor de MSS para 1460 em segmentos TCP. Esse comando afeta o tráfego de entrada e de saída na interface serial0.

int s0
ip tcp adjust-mss 1460

Os problemas de Fragmentação de IP se tornaram mas difundidos desde que os túneis de IP se tornaram mais amplamente implantados. Os túneis causam mais fragmentação porque o encapsulamento adiciona "sobrecarga" ao tamanho do pacote. Por exemplo, a adição de Encapsulamento de Roteamento Genérico (GRE) acrescenta 24 bytes ao pacote e, após esse aumento, o pacote pode precisar ser fragmentado por ser maior do que o MTU externo. Em uma seção posterior deste documento você verá exemplos de tipos de problemas que podem surgir com túneis e fragmentação de IP.

Topologias Comuns de Rede que Necessitam do 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. Alguns motivos comuns para a existência desses links de MTU menores são:

  • Hosts finais conectados ao Token Ring (ou FDDI) com uma conexão Ethernet entre eles. Os MTUs de Token Ring (ou FDDI) nas extremidades são maiores do que o MTU de Ethernet intermediário.

  • 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 tunelamento como GRE, IPsec e L2TP também precisam de espaço para os respectivos cabeçalhos e trailers. Isso também reduz o MTU efetivo da interface de saída.

Nas seções seguintes estudaremos o impacto do PMTUD quando o protocolo de tunelamento é usado entre os dois hosts finais. Dos três casos acima, este é o mais complexo, cobrindo todos os problemas que você possa encontrar nos demais casos.

O que é um Túnel?

Túnel é uma interface lógica em um roteador Cisco que oferece um modo de encapsular pacotes de passageiro dentro de um protocolo de transporte. Trata-se de uma arquitetura desenhada para fornecer os serviços para implementar um esquema de encapsulamento de ponto a ponto. O tunelamento tem os três seguintes componentes principais:

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

  • Protocolo de portador – um dos seguintes protocolos de encapsulamento:

    • GRE – protocolo de portador multiprotocolo da Cisco. Consulte a RFC 2784 leavingcisco.com e a RFC 1701 leavingcisco.com para obter mais informações.

    • IP em túneis de IP - consulte a RFC 2003 leavingcisco.com para obter mais informações.

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

Os pacotes abaixo ilustram os conceitos de IP Tunneling em que GRE é o protocolo de encapsulamento e IP é o protocolo de transporte. O protocolo de passageiro também é IP. Neste caso, o IP é o protocolo de transporte e de passageiro.

Pacote Normal

IP

TCP

Telnet

Pacote de túnel

IP

GRE

IP

TCP

Telnet

  • IP é o protocolo de transporte.

  • GRE é o protocolo de encapsulamento.

  • IP é o protocolo de passageiro.

O próximo exemplo mostra o encapsulamento de IP e DECnet como protocolos de passageiro com GRE como o portador. Isso ilustra o fato de que o protocolo de portador pode encapsular vários protocolos de passageiro.

pmtud_ipfrag_10.gif

Um administrador de rede pode considerar o tunelamento em uma situação em que existam duas redes não IP descontíguas separadas por um backbone de IP. Se as redes descontíguas estiverem executando DECnet, o administrador talvez não deseje conectá-las uma à outra configurando o DECnet no backbone. O administrador pode não desejar permitir que roteamento DECnet consuma largura de banda de backbone, pois isso poderia interferir no desempenho da rede IP.

Uma alternativa viável é fazer o tunelamento DECnet pelo backbone de IP. O tunelamento encapsula os pacotes DECnet dentro do IP e os envia pelo backbone para o ponto final do túnel, onde o encapsulamento é removido e os pacotes DECnet podem ser roteados para seu destino via DECnet.

O encapsulamento de tráfego dentro de outro protocolo oferece as seguintes vantagens:

  • Os pontos finais estão usando endereços privados (RFC 1918 leavingcisco.com) e o backbone não é compatível com o roteamento desses endereços.

  • Permitir Virtual Private Networks (VPNs) através de WANS ou da Internet.

  • Unir redes de multiprotocolos descontíguas por um backbone de protocolo único.

  • Criptografia de tráfego pelo backbone ou pela Internet.

Para o restante do documento, usaremos IP como o protocolo de passageiro e IP como o protocolo de transporte.

Considerações Referentes a Interfaces de Túnel

A seguir são apresentadas considerações sobre tunelamento.

  • O switching rápido de túneis GRE foi introduzido no Cisco IOS Release 11.1 e o switching CEF foi introduzido no Release 12.0. O switching CEF para túneis GRE multiponto foi introduzido no Release 12.2(8)T. O encapsulamento e o desencapsulamento nos pontos finais de túneis eram operações lentas nas versões anteriores do IOS, quando havia suporte apenas para o switching de processo.

  • Existem problemas de segurança e topologia no tunelamento de pacotes. Os túneis podem desviar listas de controle de acesso (ACLs) e firewalls. Se fizer tunelamento por meio de firewall, você basicamente ignorará o firewall para qualquer protocolo de passageiro em que estiver fazendo o tunelamento. Portanto, é recomendado incluir a funcionalidade de firewall nos pontos finais do túnel para aplicar qualquer política aos protocolos de passageiro.

  • O tunelamento pode criar problemas com os protocolos de transporte que tenham temporizadores limitados (por exemplo, DECnet) devido à latência aumentada.

  • O tunelamento através de ambientes com diferentes links de velocidade, como anéis de FDDI rápidos e linhas telefônicas lentas de 9600 bps, pode apresentar problemas de reordenação de pacotes. Alguns protocolos de passageiros funcionam de maneira deficiente em redes de mídia mista.

  • Os túneis ponto a ponto podem usar a largura de banda em um link físico. Se você estiver executando protocolos de roteamento em túneis de ponto a ponto múltiplos, tenha em mente que cada interface de túnel tem uma largura de banda e que a interface física em que o túnel é executado tem uma largura de banda. Por exemplo, seria conveniente definir a largura de banda do túnel em 100 Kb se 100 túneis estivessem sendo executados em um link de 10 Mb. A largura de banda padrão para um túnel é 9Kb.

  • Os protocolos de roteamento talvez prefiram um túnel em um link "real", porque o túnel poderia parecer enganosamente um link de um salto com o caminho de custo mais baixo, embora ele na verdade envolva mais saltos e seja mais dispendioso do que outro caminho. Isso pode ser mitigado com a configuração correta do protocolo de roteamento. É possível considerar a execução como um protocolo de roteamento diferente sobre a interface do túnel e não o roteamento de uma execução de protocolo na interface física.

  • Problemas com roteamento recursivo podem ser evitados configurando rotas estáticas apropriadas para o destino do túnel. Uma rota recursiva é quando o melhor caminho para o “destino de túnel” é por meio do próprio túnel. Essa situação faz com que a interface do túnel salte para cima e para baixo. Você verá o seguinte erro quando houver um problema de roteamento recursivo.

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

O Roteador como um Participante do PMTUD no Ponto Final de um 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 encaminhador de um pacote de host. Para o processamento PMTUD, o roteador precisa verificar o bit DF e o tamanho do pacote do pacote de dados original e tomar a medida apropriada quando necessário.

  • A segunda função é exercida depois que o roteador encapsulou o pacote IP original dentro do pacote de túnel. Nesse estágio o roteador está funcionando mais como um host com relação ao PMTUD e com referência ao pacote IP do túnel.

Comecemos por analisar o que acontece quando o roteador está atuando na primeira função, encaminhando pacotes IP, com respeito ao PMTUD. Esse roteador entra em ação antes de o roteador encapsular o pacote IP de host dentro do pacote de túnel.

Se o roteador participar como o encaminhador de um pacote de host, ele fará o seguinte:

  • Verifique se o bit DF está definido.

  • Verifique que tamanho de pacote o túnel pode acomodar.

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

  • Descarte o pacote (se o pacote for muito grande e o bit DF estiver definido) e envie uma mensagem ICMP ao remetente.

  • Encapsule (se o pacote não for muito grande) e envie.

Em termos genéricos, há uma opção de encapsulamento e, em seguida, fragmentação (enviando dois fragmentos de encapsulamento) ou fragmentação e, em seguida, encapsulamento (enviando dois fragmentos encapsulados).

A seguir apresentamos alguns exemplos que descrevem a mecânica de encapsulamento e fragmentação de pacote IP e dois cenários que mostram a interação do PMTUD e de pacotes atravessando redes de exemplo.

O exemplo a seguir mostra o que acontece a um pacote quando o roteador (na origem do túnel) está atuando na função de um roteador de encaminhamento. Lembre-se de que, para o processamento PMTUD, o roteador precisa verificar o bit DF e o tamanho do pacote do pacote de dados original e tomar a medida apropriada. Este exemplo usa encapsulamento de GRE para o túnel. Como se pode ver a seguir, o GRE faz a fragmentação antes do encapsulamento. Exemplos posteriores mostrarão 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 o MTU IP do túnel GRE é 1476 (1500 - 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 IP de 20 bytes e um payload TCP de 1480 bytes.

    IP

    dados + TCP de 1480 bytes

  2. Como o pacote será muito grande para o MTU IP após a sobrecarga do GRE (24 bytes) ser adicionada, o roteador de encaminhamento fragmentará o datagrama em dois fragmentos de 1476 (cabeçalho IP de 20 bytes + virulência de IP de 1456 bytes) e 44 bytes (cabeçalho IP de 20 bytes + virulência de IP de 24 bytes); assim, depois que o encapsulamento de GRE for adicionado, o pacote não será maior do que o MTU da interface física de saída.

    IP0

    dados + TCP de 1456 bytes

    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 IP de 20 bytes, a cada fragmento do datagrama IP original. Esses dois datagramas IP possuem agora o comprimento de 1500 e 68 bytes e são vistos como datagramas IP individuais, não como fragmentos.

    IP

    GRE

    IP0

    dados + TCP de 1456 bytes

    IP

    GRE

    IP1

    dados de 24 bytes

  4. O roteador de destino do túnel remove o encapsulamento de GRE de cada fragmento do datagrama original mantendo dois fragmentos IP com comprimentos de 1476 e 24 bytes. Esses fragmentos de datagrama IP serão encaminhados separadamente pelo roteador para o host de recebimento.

    IP0

    dados + TCP de 1456 bytes

    IP1

    dados de 24 bytes

  5. O host de recebimento irá remontar esses dois fragmentos no datagrama original.

    IP

    dados + TCP de 1480 bytes

O Cenário 5 mostra a função do roteador de encaminhamento no contexto de uma topologia de rede.

No exemplo a seguir, o roteador está atuando 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.

    IP

    dados + TCP de 1480 bytes

  2. Como o bit DF está definido e o tamanho do datagrama (1500 bytes) é maior do que o MTU IP do túnel GRE (1476), o roteador encerra o datagrama e envia uma mensagem "fragmentação ICMP necessária, menos o conjunto de bits DF" para a origem do datagrama. A mensagem ICMP alertará o remetente de que o MTU é de 1476.

    IP

    MTU de 1476 do ICMP

  3. O host de envio recebe a mensagem ICMP e, ao reenviar os dados originais, usa um datagrama IP de 1476 bytes.

    IP

    dados + TCP de 1456 bytes

  4. O comprimento desse datagrama IP (1476 bytes) é igual em termos de valor ao MTU IP do túnel GRE e, portanto, o roteador adiciona o encapsulamento de GRE ao datagrama IP.

    IP

    GRE

    IP

    dados + TCP de 1456 bytes

  5. O roteador de recebimento (no destino do túnel) remove o encapsulamento de GRE do datagrama IP e o envia para o host de recebimento.

    IP

    dados + TCP de 1456 bytes

Agora podemos analisar o que acontece quando o roteador está atuando na segunda função como um host de envio com relação ao PMTUD e com referência ao pacote IP do túnel. Com essa rechamada, a função entra em ação após o roteador ter encapsulado o pacote IP original no pacote de túnel.

Observação: Por padrão, um roteador não faz PMTUD nos pacotes de túnel GRE que ele gera. O comando tunnel path-mtu-discovery pode ser utilizado para ativar o PMTUD em pacotes de túnel GRE-IP.

Veja a seguir um exemplo do que acontece quando o host está enviando datagramas IP pequenos o bastante para caber no MTU IP da interface do Túnel GRE. O bit DF, nesse caso, pode ser configurado ou limpo (1 ou 0). O comando tunnel path-mtu-discovery não está configurado na interface do túnel GRE, portanto, o roteador não fará PMTUD no pacote GRE-IP.

Exemplo 3

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

    IP

    dados + TCP de 1456 bytes

  2. Esse roteador encapsula o datagrama IP de 1476 bytes dentro do GRE para obter um datagrama IP do GRE de 1500 bytes. O bit DF no cabeçalho IP GRE será limpo (DF = 0). Esse roteador, então, encaminhará esse pacote para o destino de túnel.

    IP

    GRE

    IP

    dados + TCP de 1456 bytes

  3. Suponhamos que exista um roteador entre a origem e o destino de túnel com um MTU do link de 1400. Esse roteador irá fragmentar o pacote de túnel, uma vez que o bit DF está limpo (DF = 0). Lembre-se de que este exemplo fragmenta o IP mais distante, portanto, os cabeçalhos TCP, GRE e IP interno só aparecerão no primeiro fragmento.

    IP0

    GRE

    IP

    dados + TCP de 1352 bytes

    IP1

    dados de 104 bytes

  4. O roteador de destino do túnel deve realizar a remontagem do pacote de túnel GRE.

    IP

    GRE

    IP

    dados + TCP de 1456 bytes

  5. Depois que o pacote de túnel GRE for remontado, o roteador removerá o cabeçalho IP GRE e enviará o datagrama IP original em seu caminho.

    IP

    dados + TCP de 1456 bytes

O próximo exemplo mostra o que acontece quando o roteador está funcionando como um host de envio com relação a PMTUD e com referência ao pacote IP do túnel. Agora, o bit DF está definido (DF = 1) no cabeçalho IP original e configuramos o comando tunnel path-mtu-discovery de forma que o bit DF será copiado do cabeçalho IP interno para o cabeçalho externo (GRE + IP).

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.

    IP

    dados + TCP de 1456 bytes

  2. Esse roteador encapsula o datagrama IP de 1476 bytes dentro do GRE para obter um datagrama IP do GRE de 1500 bytes. Esse cabeçalho IP GRE terá o bit DF definido (DF = 1), uma vez que o datagrama IP original tinha o bit DF definido. Esse roteador, então, encaminha esse pacote para o destino de túnel.

    IP

    GRE

    IP

    TCP de 1456 bytes

  3. Mais uma vez, suponhamos que exista um roteador entre a origem e o destino de túnel com um MTU do link de 1400. Esse roteador não fragmentará o pacote de túnel, pois o bit DF está definido (DF = 1). Esse roteador deve descartar o pacote e enviar uma mensagem de erro de ICMP ao roteador de origem do túnel, uma vez que esse é o endereço IP de origem do pacote.

    IP

    MTU de 1400 do ICMP

  4. O roteador de encaminhamento na origem do túnel recebe esta mensagem de erro de ICMP e diminuirá o MTU IP de túnel do GRE para 1376 (1400 - 24). Na próxima vez que o host de envio retransmitir os dados em um pacote IP de 1476 bytes, este será considerado muito grande, e o roteador enviará uma mensagem de erro de ICMP ao remetente, com valor MTU de 1376. Quando o host de envio retransmitir os dados, ele os enviará em um pacote IP de 1376 bytes, e esse pacote conseguirá isso através do túnel GRE para o host de recebimento.

Cenário 5

Esse cenário ilustra a fragmentação GRE. Lembre-se de que você fragmenta antes do encapsulamento de GRE; em seguida, faz PMTUD para o pacote de dados e o bit DF não será copiado quando o pacote IP for encapsulado pelo GRE. Nesse cenário, o bit DF não está definido. O MTU IP de interface do túnel GRE tem, por padrão, 24 bytes menos do que o MTU IP da interface física, portanto o MTU IP da interface GRE é de 1476.

pmtud_ipfrag_11.gif

  1. O remetente envia um pacote de 1500 bytes (cabeçalho IP de 20 bytes + payload TCP de 1480 bytes).

  2. Como o MTU do túnel GRE é 1476, o pacote de 1500 bytes está dividido em dois Fragmentos IP 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 IP. Agora os fragmentos são de 1500 (1476 + 24) e 68 (44 + 24) bytes cada.

  4. Os pacotes GRE + IP contendo os dois fragmentos IP são encaminhados para o roteador de peer de túnel GRE.

  5. O roteador de peer de 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 remonta os fragmentos IP de volta ao datagrama IP original.

Cenário 6

Este cenário é similar ao Cenário 5, mas desta vez o bit de DF é configurado. No Cenário 6, o roteador está configurado para fazer PMTUD nos pacotes de túnel GRE + IP com o comando tunnel path-mtu-discoverye o bit DF é copiado do cabeçalho IP original para o cabeçalho IP GRE. Se o roteador receber um erro ICMP do pacote GRE + IP, ele reduzirá o MTU IP na interface do túnel GRE. Mais uma vez, lembre-se de que, por padrão, o MTU IP do Túnel GRE está definido para 24 bytes a menos do que o MTU da interface física, assim, o MTU IP do GRE aqui é de 1476. Observe também que há um link de MTU de 1400 no caminho de túnel GRE.

pmtud_ipfrag_12.gif

  1. O roteador recebe um pacote de 1500 bytes (cabeçalho IP de 20 bytes + payload TCP de 1480) e descarta o pacote. O roteador descarta o pacote pois ele é maior do que o MTU IP (1476) na interface do túnel GRE.

  2. O roteador envia um erro ICMP ao remetente, informando que o MTU do próximo salto é 1476. O host registrará essas informações, geralmente como um rota de host para o destino na tabela de roteamento respectiva.

  3. O host de envio usa um tamanho de pacote de 1476 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 link de 1400 bytes; portanto, será descartado pelo roteador intermediário.

  5. O roteador intermediário envia um ICMP (código = 3, tipo = 4) ao roteador GRE com um MTU do próximo salto de 1400. O roteador GRE roteador reduz isso a 1376 (1400 - 24) e define um valor MTU IP interno na interface GRE. Você só verá essa alteração de valor quando usar o comando debug tunnel command; ela não poderá ser vista na saída do comando show ip interface tunnel<#>.

  6. Da próxima vez que o host reenviar o pacote de 1476 bytes, o roteador GRE descartará o pacote, uma vez que ele é maior do que o MTU IP atual (1376) na interface do túnel GRE.

  7. O roteador GRE envia outro ICMP (código = 3, tipo = 4) ao remetente com um MTU do próximo salto de 1376 e o host atualiza as informações atuais com valores novos.

  8. O host reenvia novamente os dados, mas agora em um pacote menor, de 1376 bytes; o GRE incluirá 24 bytes de encapsulamento e o encaminhará. Desta vez o pacote conseguirá fazer isso com o peer de túnel GRE, onde o pacote será desencapsulado e enviado ao host de destino.

    Observação: Se o comando tunnel path-mtu-discovery não estivesse configurado no roteador de encaminhamento neste cenário e o bit DF estivesse definido nos pacotes encaminhados pelo túnel GRE, o Host 1 ainda assim teria êxito no envio de pacotes TCP/IP para o Host 2, mas eles ficariam fragmentados no meio, no link de MTU 1400. Além disso, o peer de túnel GRE teria que remontá-los antes de poder desencapsular e encaminhá-los adiante.

Modo "Puro" Túnel de IPsec

O protocolo IPSec é um método baseado em padrões que fornece privacidade, integridade e autenticidade das informações transferidas por redes IP. O IPsec oferece criptografia de camada de rede IP. IPsec amplia o pacote IP adicionando pelo menos um cabeçalho IP (modo de túnel). O(s) cabeçalho(s) adicionado(s) varia(m) em função do modo de configuração IPsec, mas não excedem ~58 bytes de (Encapsulating Security Payload (ESP) e autenticação ESP (ESPauth)) por pacote.

O IPsec tem dois modos: modo de túnel e modo de transporte.

  • Modo de túnel é o modo padrão. Com o modo de transporte, o pacote IP original é protegido (criptografado, autenticado ou ambos) e encapsulado pelos trailers e cabeçalhos IPSEC. Em seguida, um novo cabeçalho IP é preconcebido para o pacote, especificando os pontos finais de IPsec (peers) como a origem e o destino. O modo de túnel pode ser usado com qualquer tipo de tráfego de IP de unicast e deve ser usado se o IPSec estiver protegendo o tráfego de hosts por trás dos peers do IPSec. Por exemplo, o modo de túnel é usado com Virtual Private Networks (VPNs), onde hosts em uma rede protegida enviam pacotes a hosts em uma rede protegida distinta através de um par de correspondentes do IPsec. Com VPNs, o “túnel" IPSec protege o tráfego IP entre os hosts ao criptografar esse tráfego entre os roteadores peer do IPSec.

  • Com o modo de transporte (configurado com o subcomandomode transport, na definição de transformação), somente o payload do pacote IP original será protegido (criptografado, autenticado ou ambos). O payload é encapsulado pelos cabeçalhos e trailers de IPsec. Os cabeçalhos IP originais ficam intactos, exceto pelo campo de protocolo IP, alterado para ESP (50), e o valor do protocolo original, salvo no trailer IPsec para ser restaurado quando o pacote for descriptografado. O modo de transporte é usado somente quando o tráfego IP a ser protegido está entre os próprios peers do IPsec e quando os endereços IP de origem e destino no pacote são os mesmos que os endereços do peer do IPsec. Normalmente, o modo de transporte de IPsec só é usado quando outro protocolo de tunelamento (como o GRE) for usado para encapsular pela primeira vez o pacote de dados de IP, então o IPsec é usado para proteger os pacotes de túnel GRE.

O IPsec sempre faz PMTUD para pacotes de dados e para seus próprios pacotes. Há comandos de configuração Ipsec para modificar o processamento de PMTUD de maneira que o pacote IP IPsec, IPsec possa limpar, definir ou copiar o bit DF do Cabeçalho IP do pacote de dados para o Cabeçalho IP IPsec. Esse recurso é denominado "Funcionalidade de Anulação de Bit DF".

Observação: Você realmente deseja evitar a fragmentação após o encapsulamento quando executa criptografia de hardware com IPsec. A criptografia de hardware pode oferecer um throughput de cerca de 50 Mbs, dependendo do hardware, mas se o pacote Ipsec estiver fragmentado, você perderá de 50% a 90% do throughput. Essa perda ocorre porque os pacotes IPsec fragmentados são comutados por processo para remontagem e, em seguida, são enviados ao engine de criptografia do hardware para decodificação. Essa perda de throughput pode reduzir o nível de desempenho do throughput de criptografia de hardware ao nível da criptografia de software (2-10 Mbs).

Cenário 7

Este cenário ilustra a fragmentação de IPsec em ação. Neste cenário, o MTU ao longo de todo o caminho é de 1500. Neste cenário, o bit DF não está definido.

pmtud_ipfrag_13.gif

  1. O roteador recebe um pacote de 1500 bytes (Cabeçalho IP de 20 bytes + payload TCP de 1480 bytes) destinado ao Host 2.

  2. O pacote de 1500 bytes é criptografado por IPsec e 52 bytes de sobrecarga são adicionados (cabeçalho IPsec, trailer IPsec e Cabeçalho de IP adicional). Agora o IPsec precisa enviar um pacote de 1552 bytes. Como o MTU externo é 1500, este pacote terá que ser fragmentado.

  3. Dois fragmentos são criados a partir do pacote IPsec. Durante a fragmentação, um cabeçalho IP de 20 bytes adicional é acrescentado ao segundo fragmento, resultando em um fragmento de 1500 bytes e um fragmento IP de 72 bytes.

  4. O roteador de peer de túnel IPsec recebe os fragmentos, remove o cabeçalho IP adicional e mescla os fragmentos IP de volta ao pacote IPsec original. Em seguida, o IPsec descriptografa esse pacote.

  5. O roteador encaminha o pacote de dados original de 1500 bytes para o Host 2.

Cenário 8

Este cenário é semelhante ao Cenário 6, exceto que neste caso o bit DF está definido no pacote de dados original e há um link no caminho entre os peers de túnel IPsec com um MTU inferior aos demais links. Este cenário demonstra como o roteador de peer IPsec realiza as duas funções de PMTUD, conforme descrito em Roteador como Participante PMTUD do Ponto Final de uma seção de Túnel.

Neste cenário você observará como o PMTU IPsec altera-se para um valor mais baixo como resultado da necessidade de fragmentação. Lembre-se de que o bit DF é copiado do cabeçalho IP interno para o cabeçalho IP externo quando o IPsec criptografa um pacote. Os valores medianos de PMTU e MTU são armazenados na SA (Security Association) do IPsec. O MTU mediano tem como base o MTU da interface de roteador externa e o PMTU tem como base o MTU mínimo visto no caminho entre os correspondentes IPsec. Lembre-se de que o IPsec encapsula/criptografa o pacote antes de tentar fragmentá-lo.

pmtud_ipfrag_14.gif

  1. O roteador recebe um pacote de 1500 bytes, que é descartado porque a sobrecarga do IPsec, quando adicionada, torna o pacote maior que o PMTU (1500).

  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 o valor máximo de sobrecarga do IPsec durante a utilização do ESP e do ESPauth do IPsec. A verdadeira sobrecarga de IPsec pode ser de até 7 bytes a menos que esse valor. O Host 1 registrará normalmente essas informações em sua tabela de roteamento como rota para o destino (Host 2).

  3. O Host 1 reduz o PMTU do Host 2 para 1442; portanto, o Host 1 envia pacotes menores (1442 bytes) durante a transmissão de dados para o Host 2. O roteador recebe o pacote de 1442 bytes e o IPsec adiciona 52 bytes de sobrecarga de criptografia; portanto, o pacote IPsec resultante será de 1496 bytes. Esse pacote contém o conjunto de bits DF em seu cabeçalho, por isso é descartado pelo roteador intermediário com o link MTU de 1400 bytes.

  4. O roteador intermediário que descarta o pacote envia uma mensagem ICMP para o remetente do pacote Ipsec (primeiro roteador), informando que o MTU de próximo salto é de 1400 bytes. Esse valor é registrado no PMTU do IPsec SA.

  5. Da próxima vez que o Host 1 retransmitir o pacote de 1442 bytes (ele não recebeu uma confirmação para isso), o IPsec descartará o pacote. Novamente, o roteador descartará o pacote porque a sobrecarga de IPsec, quando adicionada, torna o pacote maior que o PMTU (1400).

  6. O roteador envia uma mensagem ICMP para o Host 1, informando que o MTU do próximo salto, no momento, é de 1342. (1400 - 58 = 1342). O Host 1 registrará novamente essas informações.

  7. Ao retransmitir os dados, o Host 1 usará novamente o pacote do menor tamanho (1342). Esse pacote não exigirá fragmentação e fará isso por meio do túnel IPsec para o Host2.

GRE e IPsec Juntos

Interações mais complexas de fragmentação e PMTUD ocorrem quando o IPsec é utilizado para criptografar túneis. O IPsec e o GRE são combinados dessa forma porque o IPsec não oferece suporte a pacotes de IP Multicast, o que significa que não é possível executar um protocolo de roteamento dinâmico pela rede IPsec de VPN. Os túneis GRE oferecem suporte a multicast, de modo que um túnel GRE pode ser usado para, primeiramente, encapsular o pacote multicast de roteamento dinâmico em um pacote unicast de IP GRE a ser criptografado por IPsec. Ao fazer isso, o IPsec geralmente está implementado no modo de transporte do ponto máximo do GRE, porque os peers de IPsec e os pontos finais do túnel GRE (os roteadores) são os mesmos e o modo de transporte salvará 20 bytes de sobrecarga de IPsec.

Um caso interessante é quando um pacote IP é dividido em dois fragmentos e encapsulado pelo GRE. Nesse caso, o IPsec perceberá dois pacotes GRE + IP independentes. Em geral, em uma configuração padrão, um desses pacotes será grande o suficiente para demandar uma fragmentação após ser criptografado. O peer de IPsec terá que remontar esse pacote antes da criptografia. A "doublé fragmentation" (fragmentação dupla) (uma vez antes do GRE e outra vez após o IPsec) no roteador de envio aumenta a latência e reduz o throughput. Da mesma forma, como a remontagem é comutada por processo, haverá um acerto de CPU no roteador de recebimento sempre que houver remontagem.

Para evitar essa situação, defina o "mtu ip" da interface do túnel GRE como um valor baixo o suficiente para considerar tanto a sobrecarga do GRE quanto a do IPsec (por padrão, a interface do túnel GRE "mtu ip" é definida pelos bytes de sobrecarga de MTU -GRE da interface real de saída).

A tabela a seguir lista os valores MTU sugeridos para cada combinação túnel/modo, supondo-se 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 mais comuns do modo GRE + IPsec. Além disso, não há não há redução discernível para permitir uma sobrecarga extra de 20 ou 40 bytes. É mais fácil de se lembrar e definir um valor que cubra a maior parte dos cenários.

Cenário 9

O IPsec é implantado no ponto máximo do GRE. O MTU físico de saída é 1500, o PMTU de IPSec é 1500 e o MTU IP do GRE é 1476 (1500 - 24 = 1476). Por causa disso, os pacotes TCP/IP serão fragmentados duas vezes: uma antes do GRE e outra após o IPsec. O pacote será fragmentado antes do encapsulamento de GRE, e um desses pacotes GRE será fragmentado novamente após a criptografia do Ipsec.

Configurar o "mtu ip 1440" (Modo de transporte IPsec) ou "mtu ip 1420" (Modo de túnel IPsec) no túnel GRE eliminará a possibilidade de fragmentação dupla nesse cenário.

pmtud_ipfrag_15.gif

  1. O roteador recebe um datagrama de 1500 bytes.

  2. Antes do encapsulamento, o GRE fragmenta o pacote de 1500 bytes em duas partes de 1476 (1500 - 24 = 1476) e 44 (24 dados + 20 cabeçalhos IP) bytes.

  3. O GRE encapsula os fragmentos IP, o que adiciona 24 bytes a cada pacote. Isso resulta em dois pacotes GRE + IPsec de 1500 (1476 + 24 = 1500) e 68 (44 + 24) bytes cada.

  4. O IPsec criptografa os dois pacotes, adicionando 52 bytes (modo de túnel de IPsec) de sobrecarga de encapsulamento a cada um, o que resulta em um pacote de 1552 bytes e em outro de 120 bytes.

  5. O pacote IPsec de 1552 bytes é fragmentado pelo roteador porque é maior do que o MTU externo (1500). O pacote de 1552 bytes é dividido em pedaços, um pacote de 1500 bytes e outro pacote de 72 bytes (52 bytes de payload mais um cabeçalho IP adicional de 20 bytes para o segundo fragmento). Os três pacotes de 1500 bytes, 72 bytes e 120 bytes são encaminhados para o peer IPsec + GRE.

  6. O roteador de recebimento une novamente os dois fragmentos do IPsec (1500 bytes e 72 bytes) para obter o pacote de Ipsec + GRE original de 1552 bytes. Nenhuma ação é necessária com relação ao pacote de Ipsec + GRE de 120 bytes.

  7. O IPsec descriptografa o código dos pacotes IPsec + GRE de 1552 bytes e 120 bytes para obter os pacotes GRE de 1500 bytes e de 68 bytes.

  8. O GRE encapsula os pacotes GRE de 1500 bytes e de 68 bytes para obter os fragmentos de pacote IP de 1476 bytes e de 44 bytes. Esses fragmentos de pacotes IP são encaminhados ao host de destino.

  9. O Host 2 reagrupa esses fragmentos IP para obter o datagrama IP original de 1500 bytes.

O Cenário 10 é semelhante ao Cenário 8, exceto pela existência de um link MTU mais baixo no caminho do túnel. Trata-se do cenário de "pior caso" do primeiro pacote enviado do Host 1 para o Host 2. Após a última etapa do cenário, o Host 1 define o PMTU correto para o Host 2 e tudo fica certo com relação às conexões TCP entre o Host 1 e o Host 2. Os fluxos de TCP entre o Host 1 e os outros hosts (atingíveis por meio do túnel IPsec + GRE) só terão 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/IP originados no Host 1.

Cenário 10

pmtud_ipfrag_16.gif

  1. O roteador recebe um pacote de 1500 bytes. Esse pacote é descartado pelo GRE, que não pode fragmentar nem encaminhar o pacote porque o bit DF está definido, e o tamanho do pacote excede o "mtu ip" da interface externa após a adição de sobrecarga de GRE (24 bytes).

  2. O roteador envia uma mensagem ICMP ao Host 1, permitindo que ele saiba que o MTU do próximo salto é 1476 (1500 - 24 = 1476).

  3. O Host 1 altera seus PMTUs do Host 2 para 1476, e envia o menor tamanho quando retransmite o pacote. O GRE realiza o encapsulamento e passa o pacote de 1500 bytes para o IPsec. O IPsec descarta o pacote porque o GRE copiou o bit DF (conjunto) do cabeçalho interno IP e, com a sobrecarga do IPsec (máximo de 38 bytes), o pacote torna-se excessivamente grande para enviar a interface física.

  4. O IPsec envia uma mensagem ICMP para o GRE, indicando que o MTU do próximo salto será de 1462 bytes (uma vez que um máximo de 38 bytes será adicionado para criptografia e sobrecarga de IP). O GRE registra o valor de 1438 (1462 - 24) como "mtu ip" na interface do túnel.

    Observação: Essa alteração de valor será armazenada internamente e não poderá ser vista na saída do comando show ip interface tunnel<#>. Você só poderá ver essa alteração quando voltar a usar o comando debug tunnel.

  5. Da próxima vez que o Host 1 retransmitir o pacote de 1476 bytes, o GRE o descartará.

  6. O roteador envia uma mensagem ICMP ao Host 1 indicando que 1438 é o MTU do próximo salto.

  7. O Host 1 rebaixa o PMTU do Host 2 e retransmite um pacote de 1438 bytes. Nesse momento, o GRE aceita e encapsula o pacote, passando-o para o IPsec para ser criptografado. O pacote Ipsec é encaminhado para o roteador intermediário e descartado porque tem um MTU de interface externa de 1400.

  8. O roteador intermediário envia uma mensagem ICMP para o IPsec, informando que o MTU do próximo salto será de 1400. Esse valor é registrado pelo IPsec no valor PMTU do IPsec SA associado.

  9. Quando o Host 1 retransmite o pacote de 1.438 bytes, o GRE o encapsula e entrega-o ao IPSec. O IPsec descarta o pacote porque ele alterou seu próprio PMTU para 1400.

  10. O IPsec envia um erro ICMP para o GRE, indicando que o MTU do próximo salto é de 1362, e que o GRE registra internamente o valor de 1338.

  11. Quando o Host 1 retransmitir o pacote original (porque não recebeu uma confirmação para isso), o GRE descartará o pacote.

  12. O roteador envia uma mensagem ICMP para o Host 1, indicando que o MTU do próximo salto é de 1338 (1362 - 24 bytes). O Host 1 rebaixa o PMTU do Host 2 para 1338.

  13. O Host 1 retransmite um pacote de 1338 bytes e, nesse momento, pode finalmente atingir o Host 2.

Mais Recomendações

Configurar o comando tunnel path-mtu-discovery na interface de um túnel pode ser útil à interação do GRE com o Ipsec quando eles estiverem configurados no mesmo roteador. Lembre-se de que, se o comando tunnel path-mtu-discovery não estiver configurado, o bit DF será sempre eliminado do cabeçalho IP GRE. Isso permite que o pacote IP do GRE seja fragmentado, embora o cabeçalho IP dos dados encapsulados contenha o conjunto do bit DF, o que, em geral, não permite a fragmentação do pacote.

Se o comando tunnel path-mtu-discovery estiver configurado na interface do túnel GRE, ocorrerá o seguinte.

  1. O GRE copiará o bit DF do cabeçalho IP dos dados no cabeçalho IP GRE.

  2. Caso o bit DF seja definido no cabeçalho IP GRE e o pacote fique "excessivamente grande" após a criptografia do IPsec do MTU IP da interface física de saída, o IPsec descartará o pacote e solicitará ao túnel GRE que reduza o tamanho de seu MTU IP.

  3. O IPsec realiza o PMTUD de seus próprios pacotes e, caso o PMTU de IPsec se altera (for reduzido), o IPsec não notificará imediatamente o GRE; porém, quando outro pacote “excessivamente grande" passar, será realizado o processo da etapa 2.

  4. O MTU IP do GRE é menor no momento, de modo que ele descartará todos os pacotes IP com conjunto de bit DF excessivamente grandes, e enviará uma mensagem ICMP para o host de envio.

O comando tunnel path-mtu-discovery ajuda a interface GRE a definir de maneira dinâmica o seu MTU IP, em vez de o fazer estatisticamente com o comando ip mtu. Na verdade, é recomendado utilizar ambos os comandos. O comando ip mtu é usado para fornecer espaço para as sobrecargas de GRE e IPsec relativas ao MTU IP da interface física de saída local. O comando tunnel path-mtu-discovery permite que o MTU IP do túnel GRE seja reduzido ainda mais, caso haja um link de MTU IP no caminho entre os peers de IPsec.

A seguir, algumas ações que podem ser realizadas se surgirem problemas com o PMTUD de uma rede onde haja túneis GRE + IPsec configurados.

A lista a seguir começa com a solução mais adequada.

  • Corrija o problema com o PMTUD que não funciona que, em geral, é causado por um roteador ou firewall que bloqueia o ICMP.

  • Use o comando ip tcp adjust-mss nas interfaces de túnel para que o roteador reduza o valor de TCP MSS no pacote TCP SYN. Isso ajudará os dois hosts finais (TCP emissor e receptor) a usar pacotes suficientemente pequenos, de modo que o PMTUD não seja necessário.

  • Use o roteamento de política na interface de ingresso do roteador e configure um mapa de política para eliminar o bit DF do cabeçalho IP de dados antes que ele atinja a interface do túnel GRE. Isso permite que o pacote IP de dados seja fragmentado antes do encapsulamento de GRE.

  • Aumente o "mtu ip" da interface do túnel GRE para equipará-lo ao MTU da interface externa. Isso permitirá que o pacote IP de dados seja encapsulado pelo GRE, sem ser desfragmentado primeiramente. O pacote GRE, em seguida, será criptografado pelo IPsec e fragmentado para sair da interface externa física. Nesse caso, o comando tunnel path-mtu-discovery não será configurado na interface do túnel GRE. Isso pode reduzir drasticamente o throughput porque a remontagem do pacote IP no peer do IPSec é feita no modo de switching de processo.

Discussões relacionadas da comunidade de suporte da Cisco

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


Informações Relacionadas


Document ID: 25885