Vous êtes sur la page 1sur 18

Fragmentao de IP da resoluo, edies MTU, MSS, e PMTUD

com GRE e IPSEC


ndice
Introduo
Fragmentao e remontagem IP
Problemas com fragmentao de IP
Evitando a fragmentao de IP: O que o MSS TCP faz e como ele funciona
O que PMTUD?
Problemas com o PMTUD
Topologias de rede comuns que necessitam de PMTUD
O que um tnel?
Consideraes com relao s interfaces de tnel
O roteador como um PMTUD participante no ponto final de um tnel
Modo de tnel IPsec puro
GRE e IPsec juntos
Outras recomendaes
Informaes Relacionadas

Introduo
O objetivo deste documento apresentar como a fragmentao IP e a descoberta da unidade de transmisso mxima do caminho (PMTUD)
funcionam e discutir alguns cenrios que envolvem o comportamento de PMTUD quando combinado com diferentes combinaes de tneis IP.
O uso atualmente difundido de tneis de IP na Internet trouxe problemas que envolvem a fragmentao de IP e PMTUD.

Fragmentao e remontagem IP
O protocolo IP foi projetado para o uso em uma ampla variedade de enlaces de transmisso. Embora o comprimento mximo de um IP datagram
seja 64K, a maioria de enlaces de transmisso reforam um limite menor do comprimento mximo do pacote, chamado um MTU. O valor da
MTU depende do tipo do link de transmisso. O design do IP acomoda diferenas de MTU permitindo que os roteadores fragmentem datagramas
de IP conforme necessrio. A estao de recebimento responsvel pela remontagem dos fragmentos de volta para o datagrama de IP de tamanho
completo original.
A fragmentao de IP envolve quebrar uma datagrama em um nmero de partes que podem ser remontadas mais tarde. A fonte de IP, o destino, a
identificao, o comprimento total, os campos de compensao de fragmento, junto com os flags mais fragmentos e no fragmente no cabealho
do IP, so utilizados para fragmentao e remontagem de IP. Para obter mais informaes sobre dos mecnicos da fragmentao e reinstalao de
IP, veja por favor o RFC 791 .
A imagem abaixo representa o layout de um cabealho IP.

A identificao de 16 bits e um valor atribudo pelo remetente de um datagrama de IP para ajudar na remontagem de fragmentos de um
datagrama.
O deslocamento do fragmento de 13 bits e indica a posio qual o fragmento pertence no datagrama de IP original. Esse valor um mltiplo
de oito bytes.
No campo das bandeiras do cabealho IP, h trs bit para flags de controle. importante notar que o Don't Fragment (DF) mordeu jogos um
papel central no PMTUD porque determina mesmo se um pacote est permitido ser fragmentado.
0 mordido so reservados, e ajustados sempre a 0. morderam 1 so o bit DF (0 = podem fragmentar, 1 = Don't Fragment). 2 mordidos so o
bit MF (0 = ltimo fragmento, 1 = mais fragmentos).
Valor

0 mordido reservado

Mordido 1 DF

2 mordidos MF

maio

ltimo

No faa

Mais

O grfico a seguir mostra um exemplo de fragmentao. Se voc adiciona acima todos os comprimentos dos fragmentos IP, o valor excede o
comprimento da datagrama de IP original por 60. O motivo do comprimento geral ter aumentado de 60 devido criao de trs cabealhos de
IP adicionais, um para cada fragmento aps o primeiro fragmento.
O primeiro fragmento tem um offset de 0, o comprimento deste fragmento 1500; isto inclui 20 bytes para o cabealho de IP original levemente
alterado.
O segundo fragmento foi um deslocamento de 185 (185 x 8 = 1480), o que significa que a poro de dados desse fragmento comea com 1480
bytes no datagrama de IP original. O comprimento deste fragmento 1500; isto inclui o cabealho IP adicional criado para este fragmento.
O terceiro fragmento tem um deslocamento de 370 (370 x 8 = 2960), o que significa que a parte de dados desse fragmento comea com 2960
bytes no datagrama IP original. O comprimento deste fragmento 1500; isto inclui o cabealho IP adicional criado para este fragmento.
O quarto fragmento tem uma compensao de 555 (555 x 8 = 4440), que significa que a parte de dados deste fragmento comea com 4440 bytes
no datagrama de IP original. O comprimento deste fragmento 700 bytes; isto inclui o cabealho IP adicional criado para este fragmento.
somente quando o ltimo fragmento recebido que o tamanho da datagrama de IP original pode ser determinado.
O deslocamento de fragmento no ltimo fragmento (555) d um offset dos dados de 4440 bytes na datagrama de IP original. Se voc adiciona
ento os bytes de dados do ltimo fragmento (680 = 700 - 20), aquele d-lhe 5120 bytes, que a poro de dados da datagrama de IP original.
Em seguida, adicionando 20 bytes para um cabealho de IP obtm-se o tamanho do datagrama de IP original (4.440 + 680 + 20 = 5.140).

Problemas com fragmentao de IP


H diversas edies que fazem o undesirable da fragmentao de IP. H um pequeno aumento na sobrecarga de CPU e de memria para
fragmentar um datagrama IP. Isso continua verdadeiro para o remetente e para um roteador no caminho entre o remetente e o receptor. Criar
fragmentos envolve simplesmente criar encabeamentos e copi do fragmento da datagrama original nos fragmentos. Isso pode ser feito com
eficientemente porque todas as informaes necessrias para criar os fragmentos esto imediatamente disponveis.
A fragmentao causa mais despesas gerais para o receptor ao remontar os fragmentos porque o receptor deve atribuir a memria para os
fragmentos de chegada e coalescer eles de novo em uma datagrama depois que todos os fragmentos so recebidos. A remontagem em um host
no considerada um problema porque o host tem o momento e os recursos de memria de devotar a esta tarefa.
Mas, a remontagem muito incapaz em um roteador cujo o trabalho principal seja enviar o mais rapidamente possvel pacotes. Um roteador no
projetado aferrar-se aos pacotes para nenhum intervalo de tempo. Igualmente um roteador que faz a remontagem escolhe o buffer o maior
disponvel (18K) com que trabalhar porque no tem nenhuma maneira de conhecer o tamanho do pacote IP original at que o ltimo fragmento
estiver recebido.
Uma outra questo de fragmentao envolve segurar fragmentos deixados cair. Se um fragmento de um IP datagram deixado cair, a seguir a
datagrama de IP original inteira deve ser enviada novamente, e ser fragmentada igualmente. Voc ver um exemplo disso com o NFS (Network
File System). O NFS, revelia, tem um tamanho de bloco de leitura e de gravao de 8192, assim que uma datagrama NFS IP/UDP ser
aproximadamente 8500 bytes (que incluem o NFS, o UDP, e os cabealhos IP). Uma estao de envio conectada a um Ethernet (MTU 1500) ter
que fragmentar a datagrama de byte 8500 em seis partes; cinco 1500 fragmentos do byte e um fragmento de 1100 bytes. Se alguns dos seis
fragmentos so deixados cair devido a um link congestionado, a datagrama original completa ter que ser retransmitida, assim que significa que
seis mais fragmentos tero que ser criados. Se este link deixa cair um em seis pacotes, a seguir as probabilidades so baixas que todos os dados
NFS podem ser transferidos sobre este link, desde que pelo menos um fragmento IP seria deixado cair de cada IP datagram do byte original NFS
8500.
Os Firewall que filtram ou manipulam os pacotes baseados na camada 4 (L4) com a informao da camada 7 (L7) no pacote podem ter o
problema que processa fragmentos IP corretamente. Se os fragmentos IP so foras de servio, um Firewall pode obstruir os fragmentos no
iniciais porque no levam a informao que combinaria o filtro de pacote. Isto significaria que a datagrama de IP original no poderia ser
remontada pelo host de recepo. Se o Firewall configurado para permitir que os fragmentos no iniciais com informao insuficiente
combinem corretamente o filtro, a seguir um ataque do fragmento no inicial com o Firewall poderia ocorrer. Tambm, os pacotes diretos de
alguns dispositivos de rede (tais como os motores de switch de contedo) baseados no L4 com a informao L7, e se um pacote mede fragmentos
mltiplos, a seguir o dispositivo podem ter o problema que refora suas polticas.

Evitando a fragmentao de IP: O que o MSS TCP faz e como ele funciona
O MSS do TCP define a quantidade mxima de dados que um host pode aceitar em um datagrama de TCP/IP simples. Este datagrama TCP/IP
pode estar fragmentado na camada IP. O valor MSS enviado como uma opo de cabealho de TCP somente em segmentos TCP SYN. Cada
lado de uma conexo de TCP relata seu valor MSS ao outro lado. O contrrio crena popular, o valor MSS no negociado entre anfitries. O
host de emisso exigido limitar o tamanho dos dados em um nico segmento TCP a um valor inferior ou igual ao MSS relatado pelo host de
recepo.
Originalmente, o MSS significava o tamanho do buffer (maior ou igual a 65496 K) que era alocado em uma estao de recebimento para poder
armazenar os dados TCP includos em um nico datagrama IP. O MSS era o segmento mximo (pedao) dos dados esses o receptor de TCP era
disposto aceitar. Este segmento TCP poderia ter 64K (o tamanho mximo de datagrama de IP) e poderia estar fragmentado na camada de IP a fim
de ser transmitido na rede para o host de recebimento. O host receptor remontava o datagrama de IP antes de entregar o segmento completo de
TCP camada de TCP.
Esto abaixo um par encenaes que mostram como os valores MSS so ajustados e usados para limitar tamanhos do segmento TCP, e
consequentemente, tamanhos do IP datagram.
A encenao 1 ilustra a maneira que o MSS foi executado primeiramente. Hospede A tem um buffer de 16K e de Host B um buffer de 8K. Eles

enviam e recebem seus valores de MSS e ajustam o MSS de envio para enviar dados um ao outro. Observe que que hospeda A e Host B ter que
fragmentar as datagramas IP que so maiores do que a interface MTU mas ainda menos do que a emisso MSS porque a pilha TCP poderia
passar os bytes de dados 16K ou 8K abaixo da pilha ao IP. No caso do host b, os pacotes podiam ser fragmentados duas vezes, uma vez para
obter no LAN de token ring e para obter outra vez no LAN de Ethernet.
Cenrio 1

1.
2.
3.
4.
5.
6.

Hospede A envia seu valor MSS de 16K ao Host B.


O Host B recebe o valor 16K MSS do host A.
O Host B ajusta-se seu envia o valor MSS a 16K.
O Host B envia seu valor MSS de 8K para hospedar o A.
Hospede A recebe o valor 8K MSS do Host B.
Hospede os grupos seus enviam o valor MSS a 8K.

A fim ajudar em evitar a fragmentao de IP nos valores-limite da conexo de TCP, a seleo do valor MSS foi mudada ao tamanho mnimo de
buffer e ao MTU da interface enviada (- 40). Os nmeros MSS so 40 bytes menores do que nmeros MTU porque o MSS apenas o tamanho de
dados TCP, que no inclui o encabeamento do IP de byte 20 e o cabealho TCP com XX bytes 20. O MSS baseado em tamanhos de cabealho
padro; a pilha do remetente deve subtrair os valores apropriados para o cabealho IP e o cabealho de TCP segundo que TCP ou opes IP esto
sendo usados.
Agora, o MSS faz com que cada host compare primeiro a interface MTU de sada com o prprio buffer e escolha o menor valor como o MSS a
ser enviado. Os hosts compararo o tamanho MSS recebido com base em sua prpria MTU de interface e escolhero novamente o menor dos dois
valores.
O cenrio 2 ilustra esta etapa adicional tomada pelo remetente para evitar a fragmentao nos fios local e remoto. Observao como o MTU da
interface enviada est levado em considerao por cada host (antes que os anfitries se enviam seus valores MSS) e como este ajuda a evitar a
fragmentao.
Cenrio 2

1. Hospede A compara seu buffer MSS (16K) e seu MTU (1500 - 40 = 1460) e usa o valor mais baixo como o MSS (1460) para enviar ao
Host B.
2. O Host B recebe o host que os a enviam MSS (1460) e compara-o ao valor de sua interface externa MTU - 40 (4422).
3. O Host B ajusta o valor mais baixo (1460) como o MSS para enviar datagramas IP para hospedar o A.
4. O Host B compara seu buffer MSS (8K) e seu MTU (4462-40 = 4422) e usos 4422 como o MSS enviar para hospedar o A.
5. Hospede A recebe o host que os b enviam MSS (4422) e compara-o ao valor de sua interface externa MTU -40 (1460).
6. Hospede A ajusta o valor mais baixo (1460) como o MSS para enviar datagramas IP ao Host B.
1460 o valor escolhido por ambos os hosts como o MSS de envio de um para o outro. Frequentemente o valor da emisso MSS ser o mesmo

em cada extremidade de uma conexo de TCP.


Na encenao 2, a fragmentao no ocorre nos valores-limite de uma conexo de TCP porque ambo a interface enviada MTU levada em
considerao pelos anfitries. possvel que os pacotes ainda sejam fragmentados na rede, entre os roteadores A e B, se encontrarem um enlace
com uma MTU inferior das interfaces de sada dos hosts.

O que PMTUD?
O TCP MSS, como descrito acima, cuida da fragmentao nos dois pontos finais de uma conexo de TCP, mas no trata do caso em que existe
um pequeno enlace de MTU no meio, entre esses dois pontos finais. PMTUD foi desenvolvido para evitar fragmentao no caminho entre os
pontos finais. usado para determinar dinamicamente o mais baixo MTU ao longo do trajeto da fonte de um pacote a seu destino.
Nota: O PMTUD apoiado somente pelo TCP. O UDP e outros protocolos no o apoiam. Se o PMTUD est permitido em um host, e quase
sempre, todos os pacotes TCP/IP do host tero o jogo do bit DF.
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 conexo, caso
receba informao de que o pacote requer fragmentao. Um host geralmente recorda o valor MTU para um destino criando uma /32) de
entrada do host (em sua tabela de roteamento com este valor MTU.
Se um roteador tenta encaminhar um IP datagram, com o jogo do bit DF, em um link que tenha um MTU inferior do que o tamanho do pacote, o
roteador deixar cair o pacote e retornar um mensagem " destino inalcanvel " do Internet Control Message Protocol (ICMP) fonte deste IP
datagram, com o cdigo que indica a fragmentao necessria e o DF ajustar-se (tipo 3, cdigo 4). Quando a estao de origem recebe a
mensagem do ICMP, diminuir o MSS de envio e, quando o TCP retransmitir o segmento, usar o menor tamanho de segmento.
Est aqui um exemplo de um ICMP fragmentao necessria e do DF ajustar a mensagem que voc pde ver em um roteador aps ter girado
sobre 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 a seguir mostra o formato do cabealho de ICPM de uma mensagem fragmentation needed and DF set" "Destination Unreachable".

De acordo com a RFC 1191, um roteador que retorna uma mensagem de ICMP indicando fragmentation needed and DF set (fragmentao necess
ria e DF configurado), deve incluir a MTU dessa rede de prximo salto na ordem baixa de 16 bits do campo de cabealho adicional de ICMP,
rotulado como unused na especificao RFC 792 de ICMP.
As implementaes precoces do RFC 1191 no forneceram a informao de MTU do salto seguinte. Mesmo quando esta informao foi
fornecida, alguns anfitries ignoram-na. Para este caso, o RFC 1191 igualmente contm uma tabela que aliste os valores sugeridos por que o
MTU deve ser abaixado durante o PMTUD. usado por anfitries para chegar mais rapidamente em um valor razovel para a emisso MSS.

O PMTUD executado continuamente em todos os pacotes porque o caminho entre o remetente e o receptor pode ser alterado dinamicamente.
Cada vez que um remetente recebe no pode fragmentar mensagens ICMP que atualizar a informao de roteamento (onde armazena o
PMTUD).
Duas coisas podem acontecer durante o PMTUD:
O pacote pode obter toda a maneira ao receptor sem ser fragmentada.
Nota: Para que um roteador proteja o CPU contra ataques DoS, estrangula o nmero de mensagens que no chega a seu destino do ICMP
que enviaria, a dois por segundo. Portanto, neste contexto, se voc tiver um cenrio de rede no qual espere que o roteador necessite
responder com mais de dois ICMPs (cdigo = 3, tipo = 4) por segundo (podem ser hosts diferentes), seria conveniente desativar a
acelerao das mensagens de ICMP com o comando ip icmp rate-limit unreachable [df] interface.
O remetente pode obter mensagens ICMP "Cant Fragment" a partir de quaisquer (ou de todos) os ns junto com o caminho para o receptor.
O PMTUD efetuado independentemente de ambas as direes de um fluxo de TCP. Pode haver casos em que o PMTUD em uma direo de um
fluxo dispare uma das estaes finais para reduzir o MSS de envio e a outra estao final mantenha o MSS de envio original, porque nunca
enviou um datagrama de IP grande o suficiente para disparar o MTUD.
Um bom exemplo deste a conexo de HTTP descrita abaixo na encenao 3. O cliente TCP est enviando pequenos pacotes e o servidor est
enviando grandes pacotes. Neste caso, somente os grandes pacotes dos server (maior de 576 bytes) provocaro o PMTUD. Os pacotes do cliente
so pequenos (menores que 576 bytes) e no dispararo PMTUD porque no requerem fragmentao para chegar ao link de 576 MTU.
Cenrio 3

A encenao 4 mostra a um exemplo do roteamento assimtrico onde um dos trajetos tem um mnimo menor MTU do que o outro. O roteamento
assimtrico ocorre quando os trajetos diferentes so tomados enviando e recebendo dados entre dois valores-limite. Nesta encenao, o PMTUD
provocar a reduo da emisso MSS somente em um sentido de um fluxo de TCP. O trfego do cliente TCP para o servidor flui pelos
Roteadores A e B, enquanto o trfego de retorno do servidor para o cliente flui pelos Roteadores D e C. Quando o servidor de TCP envia pacotes
para o cliente, o PMTUD disparar o servidor para reduzir o envio de MSS porque o roteador D deve fragmentar os pacotes de 4092 bytes antes
que ele possa envi-los para o roteador C.
O cliente, por outro lado, nunca receber uma mensagem Destination Unreachable do ICPM com o cdigo indicando fragmentation needed and
DF set porque o roteador A no tem de fragmentar pacotes quando faz o envio para o servidor por meio do roteador B.

Encenao 4

Nota: O comando ip tcp path-mtu-discovery usado para ativar a descoberta do caminho do MTU TCP para conexes TCP iniciadas por
roteadores (BGP e Telnet, por exemplo).

Problemas com o PMTUD


H trs coisas que podem romper o PMTUD, duas que so incomuns e uma que comum.
Um roteador pode deixar cair um pacote e no enviar um mensagem ICMP. (Incomum)
Um roteador pode gerar e enviar um mensagem ICMP mas o mensagem ICMP obtm obstrudo por um roteador ou por um Firewall entre
este roteador e o remetente. (Terra comum)
Um roteador pode gerar e enviar um mensagem ICMP, mas o remetente ignora a mensagem. (Incomum)
O primeiro e o ltimo dos trs marcadores acima so incomuns e normalmente so resultantes de um erro, mas o marcador central descreve um
problema comum. As pessoas que implementam filtros de pacotes de ICMP tendem a bloquear todos os tipos de mensagens de ICMP em vez de
bloquear somente determinados tipos de mensagens de ICMP. Um filtro de pacote pode obstruir todos os tipos de mensagem ICMP exceto
aqueles que so inacessveis ou tempo excedido. O sucesso ou xito de PMTUD depende de mensagens ICMP inacessveis que passam at o
remetente de um pacote TCP/IP. As mensagens do tempo excedido ICMP so importantes para outras edies IP. Um exemplo de tal filtro de
pacote, executado em um roteador mostrado abaixo.
access-list
access-list
access-list
access-list

101
101
101
101

permit icmp any any unreachable


permit icmp any any time-exceeded
deny icmp any any
permit ip any any

H outras tcnicas que podem ser teis para amenizar o problema de o ICMP estar completamente bloqueado.
Cancele o bit DF no roteador e permita a fragmentao de qualquer maneira (esta no pode ser uma boa ideia, embora. Veja edies com
fragmentao de IP para mais informao).
Manipule o valor de opo MSS MSS TCP usando o comando interface que o IP tcp ajusta-mss <500-1460>.
Na encenao 5 abaixo, o roteador A e o roteador B esto no mesmo campo administrativo. O roteador C est inacessvel e bloqueando o ICMP,
portanto, o PMTUD foi interrompido. Uma ao alternativa para esta situao cancelar o bit DF nos ambos sentidos no roteador B para permitir
a fragmentao. Isso pode ser feito utilizando o roteamento de polticas. A sintaxe para cancelar o bit DF est disponvel no Software Release
12.1(6) e Mais Recente de Cisco IOS.
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

Uma outra opo mudar o valor de opo MSS TCP nos pacotes SYN que atravessam o roteador (disponvel no Cisco IOS 12.2(4)T e mais

tarde). Isso reduz o valor da opo 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 enviar segmentos no maiores que esse valor. O tamanho do pacote de IP ser 40 bytes maior (1500) do que o
valor de MSS (1460 bytes) para contabilizao do cabealho do TCP (20 bytes) e do cabealho do IP (20 bytes).
possvel ajustar o MSS dos pacotes TCP SYN com o comando ip tcp adjust-mss. A seguinte sintaxe reduzir o valor MSS em segmentos TCP a
1460. Este comando efetua o trfego de entrada e de partida no serial0 da relao.
int s0
ip tcp adjust-mss 1460

As edies da fragmentao de IP tornaram-se mais difundidas desde que os tneis IP se tornaram distribudos mais extensamente. A razo que
os tneis causam mais fragmentao porque o encapsulamento de tnel adiciona despesas gerais ao tamanho um pacote. Por exemplo,
adicionando o Generic Router Encapsulation (GRE) adiciona 24 bytes a um pacote, e depois que este aumento que o pacote pode precisar de ser
fragmentado porque maior ento o MTU de partida. Em uma seo mais recente deste documento, voc ver exemplos dos tipos dos problemas
que podem elevarar com tneis e fragmentao de IP.

Topologias de rede comuns que necessitam de PMTUD


O PMTUD necessrio nas situaes de rede em que os links intermedirios tm MTUs menores que o MTU dos links finais. Algumas razes
comuns para a existncia desses enlaces de MTU menores so:
Token Ring (ou FDDI) - host finais conectados com uma conexo Ethernet entre eles. O Token Ring (ou o FDDI) MTU nas extremidades
so maior ento os Ethernet MTU no meio.
O PPPoE (geralmente utilizado com ADSL) precisa de 8 bytes para seu cabealho. Isso reduz o MTU efetivo de Ethernet para 1492 (1500 8).
Os protocolos de tunelamento como o GRE, o IPsec, e o L2TP igualmente precisam o espao para seus cabealhos respectivos e reboques. Isso
tambm reduz a MTU efetiva da interface de sada.
Nas seguintes sees ns estudaremos o impacto do PMTUD onde um protocolo de tunelamento usado em algum lugar entre os dois host finais.
Dos trs casos acima deste caso o mais complexo, cobrindo todas as edies que voc pde ver nos outros casos.

O que um tnel?
Um tnel uma interface lgica em um roteador Cisco que fornea uma maneira de encapsular pacotes de passageiro dentro de um protocolo de
transporte. uma arquitetura projetada proporcionar os servios para executar um esquema do encapsulamento de Point-to-Point. O Tunelamento
tem os seguintes trs componentes principais:
Protocolo de passageiro (APPLETALK, Banyan VINES, CLNS, DECNet, IP, ou IPX)
Protocolo do portador - Um dos seguintes protocolos de encapsulamento:
GRE - O protocolo de portador multiprotocolo de Cisco. Veja o RFC 2784 e o RFC 1701
Tneis do IP in IP - Veja o RFC 2003 para mais informao.
Protocolo de transporte - O protocolo usado para transportar o protocolo encapsulado

para mais informao.

Os pacotes abaixo ilustram os conceitos de tunelamento de IP em que GRE o protocolo de encapsulamento e IP o protocolo de transporte. O
protocolo de passageiro tambm IP. Neste caso, o IP o transporte e o protocolo de passageiro.
Pacote normal
IP

TCP

Telnet

Pacote de tneis
IP

GRE

IP

TCP

Telnet

O IP o protocolo de transporte.
O GRE o protocolo de encapsulamento.
O IP o protocolo de passageiro.
O prximo exemplo mostra o encapsulamento de IP e DECnet como protocolos de passageiro com GRE como portador. Isso ilustra o fato de que
o protocolo da portadora pode encapsular vrios protocolos de passageiro.

Um administrador de rede pde considerar escavar um tnel em uma situao onde houvesse duas redes no-IP discontiguous separadas por um
backbone IP. Se as redes descontgua esto executando o DECNet, o administrador no pode querer conect-las junto configurando o DECNet no
backbone. O administrador pode no desejar permitir que roteamento DECnet consuma largura de banda de backbone, pois isso poderia interferir
no desempenho da rede IP.
Uma alternativa vivel escavar um tnel o DECNet sobre o backbone IP. O tunelamento encapsula os pacotes DECnet dentro do IP e os envia
pelo backbone para o ponto final do tnel, onde o encapsulamento removido e os pacotes DECnet podem ser roteados para seu destino via
DECnet.
Encapsular o trfego dentro de um outro protocolo fornece as seguintes vantagens:
Os pontos finais esto usando endereos privados (RFC 1918) e o backbone no compatvel com o roteamento desses endereos.
Permita o Virtual Private Networks (VPNs) atravs dos WAN ou do Internet.
Junte-se a redes multiprotocolo do juntar redes descontguas sobre um backbone de protocolo nico.
Cifre o trfego sobre o backbone ou o Internet.
Para o resto do documento ns usaremos o IP como o protocolo de passageiro e o IP como o protocolo de transporte.

Consideraes com relao s interfaces de tnel


A seguir so apresentadas consideraes sobre tunelamento.
O interruptor rpido dos tneis GRE foi introduzido no Cisco IOS Release 11.1 e o CEF switching foi introduzido na verso 12.0. O CEF
switching para tneis GRE multipontos foi introduzido na verso 12.2(8)T. O encapsulamento e o de-capsulation em pontos finais de tnel
eram operaes lentas nas verses anterior dos IO quando somente a comutao do processo foi apoiada.
H uns problemas de segurana e de topologia ao escavar um tnel pacotes. Os tneis podem desviar listas de controle de acesso (ACLs) e
firewalls. Se voc escava um tnel com um Firewall, voc contorneia basicamente o Firewall para o que protocolo de passageiro voc est
escavando um tnel. Portanto, recomendado incluir a funcionalidade de firewall nos pontos finais do tnel para aplicar qualquer poltica
nos protocolos de passageiro.
O tunelamento pode criar problemas com os protocolos de transporte que tenham temporizadores limitados (por exemplo, DECnet) devido
latncia aumentada.
O tunelamento atravs de ambientes com diferentes links de velocidade, como anis de FDDI rpidos e linhas telefnicas lentas de 9600
bps, pode apresentar problemas de reordenao de pacotes. Alguns protocolos de passageiro funcionam deficientemente em redes da mdia
mista.
Os tneis ponto a ponto podem usar a largura de banda em um enlace fsico. Se voc protocolos de roteamento running sobre o ponto
mltiplo para apontar tneis, mantenha na mente que cada interface de tnel tem uma largura de banda e que a interface fsica sobre que o
tnel executado tem uma largura de banda. Por exemplo, voc quereria ajustar a largura de banda de tnel ao Kb 100 se havia 100 tneis
que so executado sobre um link do 10 Mb. A largura de banda padro para um tnel 9Kb.
Os protocolos de roteamento podem preferir um tnel sobre um link real porque o tnel pde deceptively parecer ser um link do um-salto
com o trajeto o mais barato, embora realmente envolva mais saltos e seja realmente mais caro do que um outro trajeto. Isso pode ser
mitigado com a configurao correta do Routing Protocol. possvel considerar a execuo como um Routing Protocol diferente sobre a
interface do tnel e no o roteamento de uma execuo de protocolo na interface fsica.
Problemas com roteamento recursivo podem ser evitados configurando rotas estticas apropriadas para o destino do tnel. Uma rota
recursiva quando o melhor caminho ao destino de tnel atravs do tnel prprio. Essa situao faz com que a interface do tnel 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 PMTUD participante no ponto final de um tnel


O roteador tem duas funes PMTUD diferentes quando o ponto final de um tnel.
No primeiro papel o roteador o remetente de um pacote do host. Para o processamento de pmtud, o roteador precisa de verificar o bit DF
e o tamanho do pacote do pacote de dados originais e de tomar a ao apropriada quando necessrio.
A segunda funo exercida depois que o roteador encapsulou o pacote IP original dentro do pacote de tnel. Nesta fase, o roteador
atuando mais como um host no que diz respeito ao PMTUD e com respeito ao pacote IP do tnel.
Deixa o comeo olhando o que acontece quando o roteador est atuando no primeiro papel, pacotes do IP de host de uma transmisso do

roteador, no que diz respeito ao PMTUD. Este papel entra o jogo antes que o roteador encapsule o pacote do IP de host dentro do pacote de tnel.
Se o roteador participa porque o remetente de um pacote do host ele far o seguinte:
Verifique se o bit DF esteja ajustado.
Verifique que pacote do tamanho o tnel pode acomodar.
O fragmento (se o pacote demasiado grande e bit DF no est ajustado), encapsula fragmentos e envia-os; ou
Deixe cair o pacote (se o pacote demasiado grande e bit DF est ajustado) e envie um mensagem ICMP ao remetente.
Encapsular (se o pacote no demasiado grande) e envie.
Genericamente, h uma opo de encapsulamento e ento uma fragmentao (que enviam dois fragmentos do encapsulamento) ou uma
fragmentao e ento um encapsulamento (que enviam dois fragmentos encapsulados).
Esto abaixo alguns exemplos que descrevem os mecnicos do encapsulamento e fragmentao do pacote IP e duas encenaes que mostram a
interao do PMTUD e dos pacotes que atravessam redes de exemplo.
O primeiro exemplo abaixo mostra o que acontece a um pacote quando o roteador (no origem de tnel) est atuando no papel do 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 GRE para o tnel. Como pode ser visto abaixo, o GRE faz a
fragmentao antes do encapsulamento. Exemplos mostram cenrios mais atrasados em que a fragmentao feita aps o encapsulamento.
No exemplo 1, o bit DF no ajustado (DF = 0) e o IP de tnel GRE MTU 1476 (1500 - 24).
Exemplo 1
1. O roteador de encaminhamento (na origem de tnel) recebe um datagrama de 1500 bytes com o bit DF limpo (DF = 0) do host de envio.
Esse datagrama composto por um cabealho de IP de 20 bytes e um payload de TCP de 1480 bytes.
IP

TCP de 1.480 bytes + dados

2. Porque o pacote ser demasiado grande para o IP MTU depois que a carga adicional de GRE (24 bytes) adicionada, o roteador de
encaminhamento quebra a datagrama em dois fragmentos de 1476 (cabealho IP de 20 bytes + virulncia IP de 1456 bytes) e 44 bytes (20
bytes do cabealho IP + 24 bytes da virulncia IP) assim que depois que o encapsulamento de GRE adicionado, o pacote no ser maior
do que a interface MTU da fsica de sada.
IP0

1456 bytes TCP + dados

IP1

Dados de 24 bytes

3. O roteador de encaminhamento adiciona o encapsulamento de GRE, que inclui um cabealho de GRE 4-byte mais um cabealho IP 20byte, a cada fragmento da datagrama de IP original. Esses dois datagramas de IP possuem agora o comprimento de 1500 e 68 bytes e so
vistos como datagramas de IP individuais, no como fragmentos.
IP
IP

GRE

IP0

GRE

1456 bytes TCP + dados


IP1

Dados de 24 bytes

4. O roteador de destino do tnel remove o encapsulamento GRE de cada fragmento do diagrama original mantendo dois fragmentos de IP
com comprimentos de 1476 e 24 bytes. Estes fragmentos de datagrama de IP sero encaminhados separadamente por este roteador para o
host de recepo.
IP0

1456 bytes TCP + dados

IP1

Dados de 24 bytes

5. O host de recepo remontar estes dois fragmentos na datagrama original.


IP

TCP de 1.480 bytes + dados

O cenrio 5 descreve a funo do roteador de encaminhamento no contexto de uma topologia de rede.


No exemplo seguinte, o roteador est atuando no mesmo papel do roteador de encaminhamento mas esta vez o bit DF ajustado (DF = 1).
Exemplo 2

1. O roteador de encaminhamento na origem do tnel recebe um datagrama de 1500 bytes com DF = 1 do host de envio.
IP

TCP de 1.480 bytes + dados

2. Como o bit DF est definido e o tamanho do datagrama (1500 bytes) maior do que o tnel GRE IP MTU (1476), o roteador encerra o
datagrama e envia uma mensagem "fragmentao ICMP necessria, menos o conjunto de bits DF" para a origem do datagrama. O
mensagem ICMP alertar o remetente que o MTU 1476.
IP

ICMP MTU 1476

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

1456 bytes TCP + dados

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

GRE

IP

1456 bytes TCP + dados

5. O roteador de recebimento (no destino do tnel) remove o encapsulamento do GRE do datagrama IP e envia-o para o host recebedor.
IP

1456 bytes TCP + dados

Agora ns podemos olhar o que acontece quando o roteador est atuando no segundo papel como um host de emisso no que diz respeito ao
PMTUD e com respeito ao pacote IP do tnel. Com essa rechamada, a funo entra em ao aps o roteador ter encapsulado o pacote IP original
no pacote de tnel.
Nota: revelia um roteador no faz o PMTUD nos pacotes de tnel GRE que gera. O comando tunnel path-mtu-discovery pode ser utilizado
para ativar PMTUD para pacotes de tnel GRE-IP.
Est abaixo um exemplo do que acontece quando o host est enviando as datagramas IP que so pequenas bastante caber dentro do IP MTU na
interface do tnel GRE. O bit DF, nesse caso, pode ser configurado ou limpo (1 ou 0). A interface do tnel GRE no tem o comando tunnel
path-mtu-discovery configurou assim que o roteador no estar fazendo o PMTUD no pacote GRE-IP.
Exemplo 3
1. O roteador de encaminhamento na origem do tnel recebe um datagrama de 1476 bytes do host de envio.
IP

1456 bytes TCP + dados

2. Esse roteador encapsula o datagrama de IP de 1.476 bytes dentro do GRE para obter um datagrama de IP GRE de 1.500 bytes. O bit DF no
cabealho IP GRE ser limpo (DF = 0). Esse roteador encaminha, em seguida, esse pacote ao destino do tnel.
IP

GRE

IP

1456 bytes TCP + dados

3. Supe que h um roteador entre o origem e destino do tnel com um link MTU de 1400. Esse roteador fragmentar o pacote de tnel
porque o bit de est limpo (DF = 0). Recorde que este exemplo fragmenta o IP ultraperifrico, assim que o GRE, o IP interno, e os
cabealhos de TCP aparecer somente no primeiro fragmento.
IP0

GRE

IP1

IP

1352 bytes TCP + dados

104 dados dos bytes

4. O roteador de destino do tnel deve realizar a remontagem dos pacotes GRE do tnel.
IP

GRE

IP

1456 bytes TCP + dados

5. Depois que o pacote de tnel GRE remontado, o roteador remove o cabealho IP GRE e envia a datagrama de IP original em sua maneira.
IP

1456 bytes TCP + dados

O prximo exemplo mostra o que acontece quando o roteador est funcionando como um host de envio com relao a PMTUD e com referncia
ao pacote IP do tnel. Agora, o bit DF est definido (DF = 1) no cabealho IP original e configuramos o comando tunnel path-mtu-discovery de
forma que o bit DF ser copiado a partir do cabealho IP interno ao cabealho externo (GRE + IP).
Exemplo 4
1. O roteador de encaminhamento no origem de tnel recebe uma datagrama 1476-byte com DF = 1 do host de emisso.
IP

1456 bytes TCP + dados

2. Esse roteador encapsula o datagrama de IP de 1.476 bytes dentro do GRE para obter um datagrama de IP GRE de 1.500 bytes. Este
cabealho IP GRE ter o jogo do bit DF (DF = 1) desde que a datagrama de IP original teve o jogo do bit DF. Esse roteador encaminha, em
seguida, esse pacote ao destino do tnel.
IP

GRE

IP

TCP de1456 bytes

3. Alm disso, supe que h um roteador entre o origem e destino do tnel com um link MTU de 1400. Esse roteador no fragmentar o
pacote de tnel, uma vez que o bit DF est definido (DF = 1). Este roteador deve deixar cair o pacote e enviar um mensagem de erro ICMP
ao roteador do origem de tnel, desde que aquele o endereo IP de origem no pacote.
IP

ICMP MTU 1400

4. O roteador de encaminhamento na origem do tnel recebe esta mensagem de erro de ICMP e diminuir o MTU IP de tnel GRE para 1376
(1400 - 24). A prxima 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 ICMP ao emissor com valor MTU de 1376. Quando o host de emisso retransmite os dados,
envi-lo- em um pacote IP 1376-byte e este pacote f-lo- atravs do tnel GRE ao host de recepo.
Encenao 5
Esse cenrio ilustra a fragmentao GRE. Recorde que voc fragmenta antes do encapsulamento para o GRE, a seguir fazem o PMTUD para o
pacote de dados, e o bit DF no copiado quando o pacote IP encapsulado pelo GRE. Nesta encenao, o bit DF no ajustado. O MTU IP da
interface do tnel GRE , por padro, 24 bytes menor do que o MTU IP da interface fsica, por isso o MTU IP da interface GRE 1476.

1. O o remetente envia um pacote 1500-byte (encabeamento do IP de byte 20 + 1480 bytes do payload de TCP).
2. Como a MTU do tnel GRE 1476, o pacote de 1500 bytes est dividido em dois fragmentos IP de 1476 e 44 bytes, cada em antecipao
dos 24 bytes adicionais do cabealho GRE.
3. Os 24 bytes do cabealho GRE so adicionados a cada fragmento IP. Agora os fragmentos so 1500 (1476 + 24) e 68 (44 + 24) bytes cada
um.
4. Os pacotes GRE +IP que contm os dois fragmentos IP so enviados ao roteador de peer do tnel GRE.
5. O roteador de peer do tnel GRE remove os cabealhos de 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 novo na datagrama de IP original.
Encenao 6
Este cenrio similar ao Cenrio 5, mas desta vez o bit de DF configurado. Na encenao 6, o roteador configurado para fazer o PMTUD em
pacotes de tnel GRE +IP com o comando tunnel path-mtu-discovery, e o bit DF copiado do cabealho de IP original ao cabealho IP GRE.
Se o roteador recebe um erro ICMP para o pacote GRE +IP, reduz o IP MTU na interface do tnel GRE. Alm disso, recorde que o IP de tnel
GRE MTU est ajustado a 24 bytes menos do que a interface fsica MTU revelia, assim que o IP MTU GRE aqui 1476. Igualmente observe

que h um link de 1400 MTU no trajeto do tnel GRE.

1. O roteador recebe um pacote de 1500 bytes (cabealho de IP de 20 bytes + payload de TCP 1480) e descarta o pacote. O roteador descarta
o pacote pois ele maior do que o MTU IP (1476) na interface do tnel GRE.
2. O roteador envia um erro ICMP ao remetente informando que o prximo MTU de n 1476. O host registrar essas informaes,
normalmente 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 no pode atravessar o enlace de 1400 bytes; portanto, ser descartado pelo roteador intermedirio.
5. O roteador intermedirio envia um ICMP (cdigo = 3, tipo = 4) para o GRE Router com um Next Hop MTU de 1400. O roteador GRE
reduz isso para 1376 (1400 - 24) e define um valor de MTU IP interno na interface GRE. Esta mudana pode somente ser considerada ao
usar o comando debug tunnel; no se pode ver na sada do comando interface tunnel<-> da mostra IP.
6. Da prxima vez que o host reenviar o pacote de 1476 bytes, o roteador de GRE descartar o pacote, uma vez que ele maior do que o
MTU do IP atual (1376) na interface de tnel do GRE.
7. O roteador de GRE enviar um outro ICMP (cdigo = 3, tipo = 4) ao remetente com um salto seguinte MTU de 1376 e o host atualizar sua
informao atual com valor novo.
8. O host reenvia novamente os dados, mas agora num pacote menor de 1376 bytes; o GRE incluir 24 bytes de encapsulamento e o
encaminhar. Esta vez o pacote f-lo- ao par do tnel GRE, onde o pacote ser de-capsulated e enviado ao host de destino.
Nota: Se o comando tunnel path-mtu-discovery no foi configurado no roteador de encaminhamento nesta encenao, e o bit DF foi
ajustado nos pacotes enviados atravs do tnel GRE, o host 1 ainda sucederia em enviar pacotes TCP/IP para hospedar 2, mas obteriam
fragmentados no meio no link de 1400 MTU. Igualmente o par do tnel GRE teve que remont-los antes que poderia decapsulate e envilos sobre.

Modo de tnel IPsec puro


O protocolo IPSec um mtodo baseado em padres que fornece privacidade, integridade e autenticidade das informaes transferidas por redes
IP. O IPsec fornece a criptografia de camada de rede IP. O IPsec alonga o pacote IP adicionando pelo menos um cabealho IP (modo de tnel). O
encabeamento adicionado varia de comprimento a dependncia o modo da configurao IPSec mas no excede ~58 bytes (Encapsulating
Security Payload (ESP) e autenticao ESP (ESPauth)) pelo pacote.
O IPsec tem dois modos, modos de tnel e modos de transporte.
Modo de tnel o modo padro. Com modo de tnel, o pacote IP original inteiro protegido (cifrado, autenticado, ou ambos) e
encapsulado pelos cabealhos IPSec e pelos reboques. Ento, um novo cabealho de IP preconcebido para o pacote, especificando os
pontos finais de IPsec (peers) como a origem e o destino. O modo de tnel pode ser usado com qualquer tipo de trfego de IP de unicast e
deve ser usado se o IPSec estiver protegendo o trfego de hosts por atrs dos peers do IPSec. Por exemplo, o modo de tnel usado com
Virtual Private Networks (VPNs) onde os anfitries em uma rede protegida enviam pacotes aos anfitries em uma rede protegida diferente
atravs de um par de ipsec peer. Com VPNs, o tnel" IPSec protege o trfego IP entre os hosts ao criptografar esse trfego entre os
roteadores peer do IPSec.
Com o modo de transporte (configurado com o subcomando mode transport, na definio de transformao), somente a payload do pacote
IP original ser protegida (criptografada, autenticada ou ambas). O payload encapsulado pelos cabealhos e trailers de IPsec. Os
cabealhos de IP original permanecem intactos, salvo que o campo do protocolo IP mudado para ser ESP (50 ps), e o valor do protocolo
original salvar no trailer IPsec a ser restaurado quando o pacote decifrado. O modo de transporte usado somente quando o trfego IP a
ser protegido est entre os prprios peers do IPsec e quando os endereos IP de origem e destino no pacote so os mesmos que os
endereos do peer do IPsec. O modo transporte de IPpsec est usado normalmente somente quando um outro protocolo de tunelamento
(como o GRE) est usado a primeiramente encapsula o pacote de dados IP, a seguir o IPsec est usado para proteger os pacotes de tnel
GRE.

O IPsec faz sempre o PMTUD para pacotes de dados e para seus prprios pacotes. H comandos de configurao Ipsec para modificar o
processamento de PMTUD de maneira que o pacote de IP IPsec, IPsec possa limpar, definir ou copiar o bit DF do cabealho IP do pacote de
dados para o cabealho IP IPsec. Esse recurso denominado "Funcionalidade de Anulao de Bit DF".
Nota: Voc realmente deseja evitar a fragmentao aps o encapsulamento quando executa criptografia de hardware com IPsec. A criptografia de
hardware pode dar-lhe a taxa de transferncia aproximadamente de Mbs dos 50 ps segundo o hardware, mas se o pacote de IPsec o
fragmentado frouxamente 50 ps a 90 por cento da taxa de transferncia. Essa perda ocorre porque os pacotes IPsec fragmentados so comutados
por processo para remontagem e, em seguida, so enviados ao mecanismo de criptografia do hardware para decodificao. Esta perda de
throughput pode derrubar a taxa de transferncia da criptografia de hardware ao nvel de desempenho da criptografia de software (2-10 Mbs).
Encenao 7
Esta encenao descreve a fragmentao de IPsec na ao. Nesta encenao, o MTU ao longo do trajeto inteiro 1500. Nesta encenao, o bit DF
no ajustado.

1. O roteador recebe um pacote de 1.500 bytes (cabealho IP de 20 bytes + virulncia TCP de 1.480 bytes) destinado ao Host 2.
2. O pacote de 1500 bytes criptografado por IPsec e 52 bytes de sobrecarga so adicionados (cabealho IPsec, trailer IPsec e cabealho IP
adicional). Agora o IPsec precisa de enviar um pacote 1552-byte. Como o MTU de sada 1500, este pacote ter que ser fragmentado.
3. Dois fragmentos so criados a partir do pacote de IPsec. Durante a fragmentao, um cabealho IP 20-byte adicional adicionado para o
segundo fragmento, tendo por resultado um fragmento 1500-byte e um fragmento IP 72-byte.
4. O roteador de peer do tnel de IPsec recebe os fragmentos, descasca o cabealho IP adicional e coalesce os fragmentos IP de novo no
pacote de IPsec original. Ento o IPsec decifra este pacote.
5. O roteador encaminha o pacote de dados original de 1500 bytes para o Host 2.
Encenao 8
Esta encenao similar encenao 6 salvo que o bit DF ajustado neste caso no pacote de dados originais e h um link no trajeto entre os
pares do tnel de IPsec que tem um MTU inferior do que os outros links. Esta encenao demonstra como o roteador de IPSec peer executa
ambos os papis pmtud, como descrito o no roteador como um participante pmtud na seo do ponto final de um tnel.
Voc ver nesta encenao como o IPsec PMTU muda a um valor mais baixo como consequncia da necessidade para a fragmentao. Lembrese de que o bit DF copiado do cabealho IP interno para o cabealho IP externo quando o IPsec criptografa um pacote. Os media MTU e os
valores PMTU so armazenados na associao de segurana IPSec (SA). A MTU de mdia tem com base a MTU da interface de roteador de sada
e a PMTU tem como base a MTU mnima vista no caminho entre os correspondentes IPsec. Lembre-se de que IPsec encapsula/criptografa o
pacote antes de tentar fragment-lo.

1. O roteador recebe um pacote 1500-byte e deixa-o cair porque a carga adicional de IPsec, quando adicionada, far o pacote maior ento o
PMTU (1500).
2. O roteador envia uma mensagem ICMP ao Host 1 informando-o de que o MTU do prximo salto 1442 (1500 - 58 = 1442). Esses 58
bytes so o valor mximo de overhead do IPsec quando o ESP e o ESPauth do IPsec estiverem sendo usados. A carga adicional real de
IPsec pode ser tanto quanto os bytes 7 menos ento este valor. Hospede 1 grava esta informao, geralmente enquanto uma rota do host
para o destino (host 2), em sua tabela de roteamento.
3. O host 1 abaixa seu PMTU para o host 2 1442, assim que o host 1 enviar (pacotes menores do byte 1442) quando retransmite os dados
para hospedar 2. O roteador recebe o pacote 1442-byte e o IPsec adiciona 52 bytes de carga adicionais de criptografia assim que o pacote
de IPsec resultante 1496 bytes. Porque este pacote tem o jogo do bit DF em seu encabeamento obtm deixado cair pelo roteador
intermediria com o link 1400-byte MTU.
4. O roteador intermediria que deixou cair o pacote envia-o a um mensagem ICMP ao remetente do pacote de IPsec (primeiro roteador) que
diz que o salto seguinte MTU 1400 bytes. Esse valor registrado no PMTU do IPsec SA.
5. Da prxima vez que o Host 1 retransmitir o pacote de 1442 bytes (ele no recebeu uma confirmao para isso), o IPsec descartar o pacote.
Outra vez o roteador deixar cair o pacote porque a carga adicional de IPsec, quando adicionada ao pacote, far lhe maior ento o PMTU
(1400).
6. O roteador envia um mensagem ICMP para hospedar 1 que diz lhe que o salto seguinte MTU agora 1342. (1400 - 58 = 1342). O host 1
gravar outra vez esta informao.
7. Quando o host 1 retransmite outra vez os dados, usar o pacote menor do tamanho (1342). Esse pacote no exigir fragmentao e far isso
por meio do tnel Ipsec para o Host2.

GRE e IPsec juntos


Mais interaes complexas para fragmentao e PMTUD ocorrem quando o IPsec usado para cifrar tneis GRE. O IPsec e o GRE so
combinados desse modo porque o IPsec no apoia pacotes do Protocolo IP multicast, assim que significa que voc no pode executar um
protocolo de roteamento dinmico sobre a rede do IPSec VPN. Os tneis GRE apoiam o Multicast, assim que um tnel GRE pode ser usado a
primeiramente encapsula o pacote de transmisso mltipla do protocolo de roteamento dinmico em um pacote do unicast IP GRE, que possa
ento ser cifrado pelo IPsec. Ao fazer isto, o IPsec geralmente est implementado no modo de transporte no ponto mximo de GRE, porque os
peers de IPsec e os pontos finais do tnel GRE (os roteadores) so os mesmos e o modo de transporte salvar 20 bytes de overhead de IPsec.
Um caso interessante quando um pacote de IP dividido em dois fragmentos e encapsulado pelo GRE. Neste caso o IPsec ver dois pacotes
independentes GRE +IP. Frequentemente em uma configurao padro uma destes pacotes seja grande bastante que devero ser fragmentados
depois que foram cifrados. O ipsec peer ter que remontar este pacote antes da descriptografia. Esta dupla fragmentao (uma vez antes do
GRE e outra vez depois que IPsec) no roteador de emisso aumenta a latncia e abaixa a taxa de transferncia. Tambm, a remontagem
comutado por processo, to l ser uns acertos da CPU no roteador de recepo sempre que esta acontece.
Esta situao pode ser evitada ajustando o MTU IP na interface do tnel GRE baixo bastante para levar em considerao as despesas gerais do
GRE e do IPsec (a interface do tnel GRE MTU IP ajustada revelia interface real que parte MTU - bytes da carga adicional de GRE).
A tabela a seguir alista os valores sugeridos MTU para cada tnel/combinao de modo que supe que a relao de fsica de sada tem um MTU
de 1500.
Combinao de Tneis

MTU especfico
necessrio

MTU
recomendado

GRE + IPsec (modo de


transporte)

1440 bytes

1400 bytes

GRE + IPsec (modo de tnel)

1420 bytes

1400 bytes

Nota: O valor MTU de 1400 recomendado porque cobre o mais comum combinaes de modo GRE + de IPsec. Tambm, no h nenhuma
reduo discernvel a permitir uns 20 ou 40 bytes extra em cima. mais fcil recordar quase e ajustar todos os cenrios das tampas de um valor e

deste valor.
Cenrio 9
O IPsec distribudo sobre o GRE. O MTU fsico de sada 1500, o PMTU de IPSec 1500 e o MTU de IP do GRE 1476 (1500 - 24 = 1476).
Devido a isto, os pacotes TCP/IP sero fragmentados duas vezes, uma vez antes do GRE e uma vez aps o IPsec. O pacote ser fragmentado
antes do encapsulamento GRE e um desses pacotes GRE ser fragmentado novamente aps a criptografia Ipsec.
Configurar MTU 1440" IP (modo transporte de IPpsec) ou MTU 1420" IP (modo do tnel de IPsec) no tnel GRE removeria a possibilidade de
dupla fragmentao nesta encenao.

1. O roteador recebe um datagrama de 1.500 bytes.


2. Antes do encapsulamento, o GRE fragmenta o pacote 1500-byte em dois 1476 (1500 - 24 = 1476) e 44 (24 dados + cabealho IP 20) bytes
das partes.
3. O GRE encapsula os fragmentos IP, 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 cifra os dois pacotes, adicionando 52 byes (modo de tnel do IPsec) da carga adicional de encapsulamento a cada um, para dar um
1552-byte e um pacote do 120-byte.
5. O pacote de IPsec de 1552 bytes fragmentado pelo roteador porque maior do que o MTU de sada (1500). O pacote de 1552 bytes
dividido em pedaos, um pacote de 1500 bytes e outro pacote de 72 bytes (52 bytes de "payload" mais um cabealho de IP adicional de 20
bytes para o segundo fragmento). Os trs pacotes de 1500 bytes, 72 bytes e 120 bytes so 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 IPsec + GRE original
de 1552 bytes. Nada precisa de ser feito ao pacote do IPsec+GRE do 120-byte.
7. O IPsec decifra 1552-byte e pacotes do IPsec+GRE do 120-byte para obter os pacotes GRE 1500-byte e 68-byte.
8. GRE sem capsulamento os pacotes GRE 1500-byte e 68-byte para obter fragmentos do pacote IP 1476-byte e 44-byte. Esses fragmentos de
pacotes IP so encaminhados ao host de destino.
9. O host 2 remonta estes fragmentos IP para obter o IP datagram 1500-byte original.
O Cenrio 10 semelhante ao Cenrio 8, exceto pela existncia de um link MTU mais baixo no caminho de tnel. Esse o "pior" cenrio para o
primeiro pacote enviado do Host 1 para o Host 2. Aps a ltima etapa nesta encenao, o host 1 ajusta o PMTU correto para o host 2 e tudo
bem para as conexes de TCP entre o host 1 e os fluxos de TCP do host 2. entre o host 1 e os outros anfitries (alcanveis atravs do tnel do
IPsec+GRE) tero que somente atravessar as ltimas trs etapas da encenao 10.
Nesta encenao, o comando tunnel path-mtu-discovery configurado no tnel GRE e o bit DF ajustado nos pacotes TCP/IP que originam
do host 1.
Encenao 10

1. O roteador recebe um pacote 1500-byte. Este pacote deixado cair pelo GRE porque o GRE no pode fragmentar ou enviar o pacote
porque o bit DF ajustado, e o tamanho do pacote excede a interface externa MTU IP aps ter adicionado a carga adicional de GRE (24
bytes).
2. O roteador envia uma mensagem ICMP ao Host 1, permitindo que ele saiba que o MTU do prximo salto 1476 (1500 - 24 = 1476).
3. Hospede 1 muda seu PMTU para o host 2 1476 e envia o tamanho menor quando retransmite o pacote. O GRE encapsular-lo e entrega-o o
pacote 1500-byte ao IPsec. O IPsec deixa cair o pacote porque o GRE copiou o DF mordido (ajuste) do cabealho IP interno, e com a carga
adicional de IPsec (mximo 38 bytes), o pacote demasiado grande enviar para fora a interface fsica.
4. O IPsec envia um mensagem ICMP ao GRE que indica que o salto seguinte MTU 1462 bytes (desde que um mximo 38 bytes ser
adicionado para a criptografia e o IP em cima). O GRE grava o valor 1438 (1462 - 24) como o MTU IP na interface de tnel.
Nota: Esta mudana no valor armazenada internamente e no pode ser considerada na sada do comando interface tunnel<-> da mostra
IP. Voc ver essa alterao se acionar o comando use debug tunnel.
5. A prxima vez o host 1 retransmite o pacote 1476-byte, GRE deixa-o cair.
6. O roteador envia uma mensagem ICMP ao Host 1 indicando que 1438 a MTU do prximo salto.
7. O host 1 abaixa o PMTU para o host 2 e retransmite um pacote 1438-byte. Esta vez, o GRE aceita o pacote, encapsular-lo, e entrega-o fora
ao IPsec para a criptografia. O pacote IPSec encaminhado para o roteador intermedirio e descartado porque tem uma MTU de interface
de sada de 1.400.
8. O roteador intermedirio envia-o a um mensagem ICMP ao IPsec que diz que o salto seguinte MTU 1400. Este valor gravado pelo
IPsec no valor PMTU IPsec associado SA.
9. Quando o Host 1 retransmite o pacote de 1.438 bytes, o GRE o encapsula e entrega-o ao IPSec. O IPsec deixa cair o pacote porque mudou
seu prprio PMTU a 1400.
10. O IPsec envia um erro ICMP ao GRE que indica que o salto seguinte MTU 1362, e o GRE grava o valor 1338 internamente.
11. Quando o host 1 retransmitir o pacote original (porque no recebeu um reconhecimento), o GRE deixa-o cair.
12. O roteador envia um mensagem ICMP para hospedar 1 que indica o salto seguinte MTU 1338 (1362 - 24 bytes). O host 1 abaixa seu
PMTU para o host 2 1338.
13. O host 1 retransmite um pacote 1338-byte e esta vez onde possa finalmente conseguir por completo hospedar 2.

Outras recomendaes
Configurar o comando tunnel path-mtu-discovery em uma interface de tnel pode ajudar o GRE e a interao de IPsec quando so
configurados no mesmo roteador. Lembre-se que sem o comando tunnel path-mtu-discovery configurado, o bit DF sempre seria apagado no
cabealho IP GRE. Isto permite o pacote IP GRE seja fragmentado mesmo que o cabealho IP dos dados encapsulados tenha o jogo do bit DF,
que normalmente no permitiria que o pacote fosse fragmentado.
Se o comando tunnel path-mtu-discovery configurado na interface do tnel GRE, o seguinte acontecer.
1. O GRE copiar o DF mordido do cabealho IP dos dados ao cabealho IP GRE.
2. Se o bit DF ajustado no cabealho IP GRE e o pacote ser demasiado grande aps a criptografia IPSec para o IP MTU na interface
enviada fsica, a seguir o IPsec deixar cair o pacote e notificar o tnel GRE para reduzir seu tamanho do MTU IP.
3. O IPsec faz o PMTUD para seus prprios pacotes e se o IPsec PMTU muda (se est reduzido), a seguir IPsec no notifica imediatamente o
GRE, mas quando um outro demasiado grande pacote vem completo, a seguir o processo em etapa 2 ocorre.

4. O IP MTU do GRE agora menor, assim que deixar cair todos os pacotes IP dos dados com o jogo do bit DF que forem agora demasiado
grandes e enviar um mensagem ICMP ao host de emisso.
O comando tunnel path-mtu-discovery ajuda a interface GRE a definir seu MTU IP dinamicamente, em vez de estatisticamente com o comando
ip mtu. Recomenda-se realmente que os comandos both esto usados. O comando ip mtu usado fornecer a sala para o GRE e a carga adicional
de IPsec relativo ao IP MTU da interface enviada do local fsico. O comando tunnel path-mtu-discovery permite que o MTU IP do tnel GRE
seja reduzido mais ainda se houver um enlace de MTU do IP no caminho entre os peers de IPsec.
Esto abaixo algumas das coisas que voc pode fazer se voc est tendo problemas com PMTUD em uma rede onde haja GRE + tneis de IPsec
configurados.
A lista a seguir comea com a soluo mais desejada.
Fixe o problema com o PMTUD que no trabalha, que causado geralmente por um roteador ou por um Firewall que obstruem o ICMP.
Use o comando ip tcp adjust-mss nas interfaces de tnel para que o roteador reduza o valor de TCP MSS no pacote TCP SYN. Isso ajudar
os dois hosts finais (o TCP emissor e receptor) a usar pacotes suficientemente pequenos, de modo que o PMTUD no seja necessrio.
Use o roteamento de poltica na interface de ingresso do roteador e configurar um mapa de rota para cancelar o bit DF no cabealho IP dos
dados antes que obtenha interface do tnel GRE. Isso permite que o pacote IP de dados seja fragmentado antes do encapsulamento de
GRE.
Aumente o MTU IP na interface do tnel GRE para ser igual interface externa MTU. Isto permitir que o pacote IP dos dados seja
GRE encapsulado sem fragment-lo primeiramente. O pacote GRE ser ento IPsec cifrado e fragmentado ento para sair a interface
externa fsica. Neste caso voc no configuraria o comando tunnel path-mtu-discovery na interface do tnel GRE. Isto pode reduzir
drasticamente o throughput porque a remontagem do pacote IP no peer do IPSec feita no modo de switching de processo.

Informaes Relacionadas
Descoberta de MTU de caminho RFC 1191
Opes de descoberta de MTU RFC 1063 IP
Protocolo de Internet RFC 791
Protocolo de controle de transmisso RFC 793
RFC 879 - O tamanho mximo do segmento de TCP e tpicos 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
White Paper de Tecnologia

1992-2015 Cisco Systems Inc. Todos os direitos reservados.


Data da Gerao do PDF: 19 Setembro 2015
http://www.cisco.com/cisco/web/support/BR/104/1047/1047239_pmtud_ipfrag.html