IPv6 MTU e MSS são ignorados na LAN?

1

Eu tenho um servidor com um túnel IPv6 (seisx) e uma rede local por trás dele. O túnel tem MTU de 1470, e um prefixo com este MTU é anunciado por radvd, e escolhido pelo cliente local:

root@host:~# ip -6 route
2001:xxxx:xxxx::/64 dev eth1  proto kernel  metric 256  expires 298sec mtu 1470
fe80::/64 dev eth1  proto kernel  metric 256  mtu 1470
default via fe80::dad3:85ff:feaf:7e77 dev eth1  proto kernel  metric 1024  expires 28sec mtu 1470 hoplimit 64

A interface do cliente tem MTU de 1500, como de costume. Agora, quando eu transfiro um arquivo para um host IPv6 remoto, acontece o seguinte (o despejo do pacote wireshark no servidor, a interface LAN, da parte relevante):

15.034320 host -> remote SSHv2 Encrypted request packet len=2796
15.034408 server -> host ICMPv6 Too big
15.241163 host -> remote SSHv2 [TCP Retransmission] Encrypted request packet len=1398
15.252193 remote -> host TCP ssh > 58188 [ACK] Seq=2658 Ack=121902 Win=64128 Len=0 TSV=2205083594 TSER=4294965684
15.252480 host -> remote SSHv2 [TCP Retransmission] Encrypted request packet len=2796
15.252558 server -> host ICMPv6 Too big
15.461151 host -> remote SSHv2 [TCP Retransmission] Encrypted request packet len=1398

Assim, o host envia um pacote de tamanho 2796 (não deveria ser possível, o link MTU é 1500) e o servidor responde corretamente com o ICMPv6 Muito grande. O pacote é então retransmitido com o tamanho correto e reconhecido. Mas então, o próximo pacote é novamente grande demais, e o processo se repete indefinidamente, enquanto o arquivo é transferido a passo de caracol ... O que está acontecendo aqui? O cache de rota mostra que o MTU da rota foi selecionado corretamente (endereços IPv6 substituídos por nomes):

root@host:~# ip -6 route show cached
remote via fe80::dad3:85ff:feaf:7e77 dev eth1  metric 0 
    cache  mtu 1470 hoplimit 64
server via server dev eth1  metric 0 
    cache  mtu 1470
    
por Michel 17.01.2012 / 15:52

1 resposta

1

Ok, em casa, problemas mais estranhos estavam acontecendo na rede. Tomei o caminho da Microsoft e reiniciei o servidor. O problema parece ter desaparecido.

    
por 17.01.2012 / 21:04