Olá Caros,

  Como havia prometido vamos comentar um pouco sobre o termo mencionado acima. Portanto, o que significa MSS? 😕

  MSS está relacionado com o tamanho máximo do datagrama IP, ou seja, ele tem relação com as conexões TCP e UDP. Para isso temos algumas suposições feitas anteriormente de que o tamanho padrão do datagrama tem alguns valores incoerentes. Esse pensamento foi absorvido por volta de 1983:

A origem não pode enviar datagrama maiores do que 576 octetos, a menos que eles tenham um conhecimento específico de que o destino está preparado para aceitar datagrama maiores.

  Para solucionar esse conceito, podemos chamar de ambiguidade, o TCP MSS foi definido com a seguinte regra:

O tamanho do TCP MSS é o máximo tamanho do datagrama IP menos 40

  O máximo tamanho do datagrama IP é 576
  O TCP MSS é 536

  A definição para o MSS esta detalhado através da RFC 879. O TCP provê uma opção que pode ser usada no momento que a conexão é estabelecida ( somente ), no qual indica que tamanho máximo no segmento TCP pode ser aceito naquela conexão. O MSS é enviado da origem para o destino e pode dizer ” Eu posso aceitar no segmento TCP até um tamanho X “. Esse tamanho X pode ser maior ou menor do que o padrão, e o MSS pode ser usado completamente independente de cada fluxo de direção do trafego.

  Um ponto importante é que o MSS não conta o cabeçalho TCP e o cabeçalho IP, ou seja, ele conta apenas os dados não tendo o TCP SYN e o FIN. Lembrando-se que o TCP sobre Ethernet:

• Adiciona 20 bytes para o cabeçalho IPV4 e 40 bytes para o cabeçalho IPV6
• Adiciona 20 bytes para o cabeçalho TCP
• Adiciona 12 bytes opcional para o TCP timestamps

  Nesse caso o cliente quer estabelecer uma conexão TCP com o servidor WEB, portanto eles anunciam o MSS deles para o outro para que eles aceitem o maior tamanho TCP nesse segmento. O valor negociado será de 1500 bytes, e o bit “ df-bit ” foi setado no servidor web, portanto esse pacote não poderá ser fragmentado. Quando o servidor  devolver esse pacote para o roteador R2, ele irá tentar encapsular o pacote dentro de um túnel para entregar ao R1, porém o tunel GRE tem 24bytes a menos que o MTU configurado no servidor. Portanto o pacote irá ser fragmentado criando um pacote de 1476bytes ( dados e cabeçalho IP ) e um pacote de 44bytes ( 24bytes de dados e um novo cabeçalho IP de 20 bytes ). R2 irá encapsular ambos os pacotes de 1500bytes e 68bytes.

  Mas você lembra-se que esse pacote não podia ser fragmentado devido ao df-bit, portanto R2 irá instruir o servidor WEB para enviar pacote menores. Isso significa que irá encaminhar um ICMP ( type 3 code 4 – Destination Unreachable; Fragmentation Needed and DF set ), para qual terá na mensagem o correto valor do MTU a ser usado pelo servidor WEB. Essa mensagem pode ser consultada através da RFC 1191 que trata do PMTUD, e também pode ser visualizada em um outro post através do wireshark mostrado para vocês. 

  Com isso podemos ter algumas soluções para resolver esse problema da fragmentação:

• Modificando o bit ” df-bit “

!
interface FastEthernet0
…
ip policy route-map clear-df
!
route-map clear-df permit 10
match ip address 101
set ip df 0
!
access-list 101 permit tcp 10.1.3.0 0.0.0.255 any

• Trocar o valor TCP MSS que comunica através do roteador. Isso será configurado através do comando disponível no IOS 12.2(4)T ou superior pelo ip tcp adjust-mss [ value ], colocando 1436 ( MTU menos o tamanho do IP, TCP, GRE ), ou seja, ( 1500 – 20 – 20 – 24 ). 

interface tunnel0
…
ip tcp adjust-mss 1436