[GTER] [MASOCH-L] Jumbo frames no PTT

Lista lista.gter at gmail.com
Sat Aug 11 00:23:00 -03 2012


Boa Noite.

Essa questão de alterar  o MTU em interfaces internas entre PE's, não pode
surtir um efeito negativo? Outra coisa para alterar isso os switchs teria
que ser configurado para aceitar MTU's maiores também, ou ele já recalcula
isso?

Em 10 de agosto de 2012 18:17, Rubens Kuhl <rubensk at gmail.com> escreveu:

> > O problema operacional está nos participantes (L3) em cenário misto, com
> > alguns participantes usando MTU de 1500 bytes, e outros usando MTUs
> > maiores (por exemplo: 3500 e 9000 bytes).  Isso poderia acontecer no
> > ATM, por exemplo (se MTU maiores não forem segregadas para outras VLANs).
> >
> > Neste cenário misto, é necessário que o PMTUD esteja funcional.
>
> E aqui temos um argumento até para defender a não expansão do MTU em
> VLANs públicas, que é exatamente evitar esse tipo de conflito entre
> participantes...
>
> >> Existe uma outra aplicação que seria beneficiada por Jumbo MTU, que é
> >> o trânsito com full-routing. Sessões BGP com MTU alto e PMTUD em cima
> >> de interfaces GigE podem diminuir bastante o tempo de convergência
> >> num retorno de falha.
> >
> >
> > Pelo que vejo nos docs da Cisco, isso procede.  Confesso que fiquei
> > espantado em haver uma dependência grande entre MTU (na verdade, o MSS)
> > e velocidade de sincronização do eBGP, aparentemente superior a que
> > poderia ser atribuído apenas ao overhead dos cabeçalhos.  Você sabe a
> razão?
>
> Sem contar o slow-start, um aumento de n vezes o MSS já aumentaria em
> n vezes a taxa de transferência. No caso do BGP porém a transferência
> de tabelas ainda ocorre boa parte durante efeito do slow start, com
> tamanho de janela ainda baixo... pode ser isso.
>
> Eu imagino que haja também um pouco de "efeito soluço", em que um
> recálculo da RIB e da FIB seja realizado a cada conjunto de rotas
> recebidas, ou seja, a cada segmento TCP que chega com checksum
> verificado; um menor número de segmentos gera um menor número de
> "soluços" e uma resposta mais rápida.
>
>
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list