.png)
Estou executando várias VMs no Azure. As VMs estão em execução em uma sub-rede com NSG. As NICs não usam NSGs, não usamos redes aceleradas.
Percebo que quando uma VM se comunica com outra VM da mesma sub-rede usando TCP, o valor MSS nos pacotes SYN é reduzido em 42. Isso significa que se eu enviar um TCP SYN com MSS = 876 para outra VM da mesma rede, o outra VM irá capturar um TCP SYN com MSS=834:
Cliente:
18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 876,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.528398 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1418,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.528430 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
Servidor:
18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 834,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.527682 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1460,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.529167 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
Estamos usando vários NVAs, e nossos pacotes SYN viajam por vários saltos, e na verdade vemos o MSS sendo reduzido várias vezes, medimos originalmente uma redução de 84, também medimos uma redução de 138 em alguns casos (na verdade, não um múltiplo de 42), isso significa que reduzimos em mais de 10% a eficiência da nossa rede.
Passei algum tempo observando como vários dispositivos de rede funcionam com o MSS. Na maioria dos casos, o MSS é definido para um valor fixo, sendo fixado em um valor estático ou no caminho MTU. PaloAlto utilizará um “ajuste” relativo ao MTU de uma interface de rede, que é um valor fixo. Arista permitirá que você defina um valor máximo para o tráfego de entrada ou saída, novamente valores absolutos. Alguns fornecedores de firewall, como PaloAlto, reduzirão o MSS em caso de ataque DoS e os cookies SYN serão ativados, mas o MSS será um dos 8 valores possíveis nesse caso.
Acredito que esse mecanismo MSS -= 42 quebra o TCP: se o cliente suportar jumbo frames e enviar um MSS de 8860, o servidor no Azure recebe 8876, ele próprio responde 1330, mas o cliente recebe 1246, o cliente concordará que os pacotes devem ter 1246 bytes carga útil, enquanto o servidor enviará carga útil de 1330 bytes.
O maior problema é que temos casos em que o trânsito funciona “por acaso”. A fixação não é feita corretamente no lado da rota expressa, mas por causa disso -42 aqui e ali o MSS é realmente reduzido a um valor que "se ajusta", até que haja alguma pequena mudança na forma como os pacotes são roteados, e você descobre de repente, houve uma configuração incorreta em algum lugar.
Alguma ideia de como explicar essa redução? Acredito que esse comportamento não esteja documentado em lugar nenhum.
EDITAR
Apenas lendoRFC879
O MSS pode ser usado de forma totalmente independente em cada direção do fluxo de dados. O resultado pode ser tamanhos máximos bastante diferentes nas duas direções.
Portanto, parece legítimo de acordo com a RFC. Ainda assim, um comportamento estranho.
Responder1
Ao contrário da rede física, a rede SDN consome “bytes” adicionais para cabeçalhos de encapsulamento (GRE). Os IPs visíveis são CA (endereço do cliente), mas também existe PA (endereço do provedor) que requer roteamento no provedor de nuvem. Conseqüentemente, você verá menos MSS disponíveis, uma vez que o provedor de nuvem aplica fixação TCP adicional na infra para que o roteamento de back-end aconteça.