[GTER] TOP BUG mais estranho do RouterOS

Tue Apr 10 10:03:52 -03 2018

Depende do que você está configurado como MAX-MTU e MAX-MRU no PPPoE Server.

Se você definir como 1492 bytes (máximo em relação a Ethernet Jumbo Frame)
Você terá um payload de 1452 bytes (o calculo é sempre 40 a menos .......
[20bytes IP header] e [20bytes TCP header] )

Se fosse um frame Ethernet normal (1500 bytes) o payload seria de 1460 bytes

É justamente isso que o roteador ajusta.

Att,

Andre

Em 9 de abril de 2018 18:43, Gustavo Stocco <gustavostocco at gmail.com>
escreveu:

> Entendido, Andre.
> E esse novo MTU que o RouterOS determinada para os clientes PPPoE é de
> quanto?
>
> 2018-04-09 15:29 GMT-03:00 Andre Almeida <andre at bnet.com.br>:
>
> >  1) O bug ocorre apenas para quem tá com a função habilitada ("yes")?
> > Provavelmente, mas eu não testei com ele desabilitado, pois eu precisava
> > dele habilitado.
> >
> >
> > 2) Vocês utilizam essa função habilitada? Há necessidade de mudar a
> > MSS por alguma
> > razão, considerando que todas as suas interfaces suportem 1492?
> > Sempre tive um pouco de dúvidas sobre a necessidade de uso dessa função
> no
> > PPP.
> >
> > Sim, há a necessidade pois um MTU normal do padrão Ethernet é de 1500
> > bytes.
> > Mas  quando se usa PPPoE em cima dos 1500 bytes, o PPPoE consome 8bytes,
> > então você usará 1492 bytes de MTU na real.
> >
> > Como não se pode diminuir o tamanho do cabeçalho, faz-se necessário que
> se
> > reduza 8 bytes no payload.
> > Ou seja, quando há o handshake, você precisa informar que seu lado é 1492
> > bytes.
> > Mas porque se muda o MSS no roteador? Porque normalmente o
> > computador/dispositivo do seu lado não sabe disso, na real ele não
> enxerga
> > o tunel.
> > Ou seja, ele faz o handshake da interface dele, que normalmente está
> > conectada a 1500 bytes.
> > O problema é que o handshake informado errado não iria funcionar
> > corretamente.
> > Por isso ele é alteado pelo roteador.
> >
> >
> > Esse é o meu entendimento.
> >
> > Andre Almeida
> >
> > Em 7 de abril de 2018 13:10, Gustavo Stocco <gustavostocco at gmail.com>
> > escreveu:
> >
> > > Já que o problema ocorreu nessa função de "Change TCP MSS" no PPP, que
> é
> > > setado lá em "Profiles".
> > > Duas perguntas:
> > >
> > > 1) O bug ocorre apenas para quem tá com a função habilitada ("yes")?
> > > 2) Vocês utilizam essa função habilitada? Há necessidade de mudar a MSS
> > por
> > > alguma razão, considerando que todas as suas interfaces suportem 1492?
> > > Sempre tive um pouco de dúvidas sobre a necessidade de uso dessa função
> > no
> > > PPP.
> > >
> > > Se alguém puder esclarecer a questão número 02, eu agradeço! Acredito
> que
> > > possa ser a dúvida de muitos.
> > >
> > > Abraços
> > >
> > > 2018-04-06 22:42 GMT-03:00 Rogerio Mariano <rsouza.rjo at gmail.com>:
> > >
> > > > Boa noite turma !
> > > >
> > > > Olhando a lista de discussão me veio algo em mente...
> > > >
> > > > Quando um SP ou ISP aqui da lista, faz a aquisição um router (por
> > > exemplo)
> > > > , ele não deveria fazer antes de adquirir e botar em produção uma
> > análise
> > > > de coisas como MTBF, MTTR, versões de software com menos bugs (claro,
> > > > porque todos terão bugs, da Mikrotik CCR1072, passando pelo Cisco NCS
> > > 6008
> > > > e chegado em um Juniper PTX 10016, ninguém esta imune) e drawbacks da
> > > caixa
> > > > ? Isso não evitaria a "fadiga" ?  Não quero parecer cabotino, apenas
> > digo
> > > > porque vira e mexe vejo alguém reclamar de alguma situação que no
> final
> > > era
> > > > um bug.
> > > >
> > > >
> > > > OBS: Ainda em tempo, a recorrência do mesmo tipo de problema também
> > pode
> > > > indicar a falta de processos como por exemplo análise de falhas,
> > > desempenho
> > > > e post-mortem na rede.
> > > >
> > > >
> > > > Saudações,
> > > >
> > > > Rogerio Mariano
> > > >
> > > > Em 6 de abril de 2018 20:17, Anderson Oliveira <
> > > > anderson.oliveira54 at gmail.com> escreveu:
> > > >
> > > > > No caso de MKT, onde o lançamento de firmware/correções é muito
> mais
> > > > > 'frequente' que o restante, sempre optamos por trabalhar com nossas
> > > > caixas
> > > > > sempre atualizadas. Evitam uma série de situações.
> > > > >
> > > > >
> > > > > *Att.*
> > > > >
> > > > > *Anderson Henrique de Oliveira*
> > > > >
> > > > > Em 6 de abril de 2018 18:55, Márcio Elias Hahn do Nascimento <
> > > > > marcio at sulonline.net> escreveu:
> > > > >
> > > > > > Não tenho nada a discordar Anderson.
> > > > > >
> > > > > > Mais vc há de convir que um problema afetar algo tão específico
> > > > > > dificilmente vai te levar a desconfiar da versão do software da
> > caixa
> > > > > > que faz PPPoE em uma primeira vista.
> > > > > >
> > > > > > Em 2018-04-06 17:32, Anderson Oliveira escreveu:
> > > > > >
> > > > > > > Patch de firmware existe para isso. Corrigir BUGs
> > > > > > >
> > > > > > > Sempre opte pelo firmware current ou o bug fix
> > > > > > >
> > > > > > > *Att.*
> > > > > > >
> > > > > > > *Anderson Henrique de Oliveira*
> > > > > > >
> > > > > > > Em 6 de abril de 2018 16:36, Márcio Elias Hahn do Nascimento <
> > > > > > > marcio at sulonline.net> escreveu:
> > > > > > >
> > > > > > >> Pessoal, depois de muito bater cabeça, não descobri o por que,
> > > mais
> > > > > > >> ainda vou depurar uns PCAP's, o negócio é que nós estávamos
> com
> > > > > > >> problemas para acessar um site específico (
> scipiracicaba.com.br
> > ).
> > > > > > >>
> > > > > > >> O erro era reportado por clientes PPPoE atraz de um Mikrotik
> na
> > > > versão
> > > > > > >> 6.41. Os que caiam em outros concentradores na versão 6.40.5
> não
> > > > > tinham
> > > > > > >> problemas.
> > > > > > >>
> > > > > > >> ICMP, Ok, HTTPS não (somente para esse domínio, claro que não
> > > > testamos
> > > > > > >> todos os domínios registrados e funcionando, mais falo isso
> pelo
> > > > > > >> feedback dos clientes).
> > > > > > >>
> > > > > > >> Pois bem, depois de não achar solução partimos para um
> > laboratório
> > > > com
> > > > > > >> uma RB750 fazendo PPPoE, primeiro na versão 6.40.5, tudo ok.
> > > > > > >>
> > > > > > >> Colocamos então a 6.41.3 (a última stable), ok também.
> > > > > > >>
> > > > > > >> Ai fizemos o downgrade para a 6.41, não foi!!!
> > > > > > >>
> > > > > > >> Voltamos a atualizar para 6.41.3 normal.
> > > > > > >>
> > > > > > >> Essa eu confesso que nunca tinha visto...
> > > > > > >>
> > > > > > >> Se alguém estiver rodando PPPoE server no routeros 6.41 e
> quiser
> > > > > testar
> > > > > > >> o acesso ao referido site.
> > > > > > >>
> > > > > > >> --
> > > > > > >> Att
> > > > > > >>
> > > > > > >> Márcio Elias Hahn do Nascimento
> > > > > > >> --
> > > > > > >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > > > > --
> > > > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > > >
> > > > > > --
> > > > > > Att
> > > > > >
> > > > > > Márcio Elias Hahn do Nascimento
> > > > > > --
> > > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > > >
> > > > > --
> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > >
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Gustavo Stocco
> > > NAXI TELECOMUNICAÇÕES
> > > +55 (47) 3054-2233
> > > 0800-932-0000 R.3322
> > > INOC-DBA BR 53001*100
> > > ASN 53001
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
>
> Gustavo Stocco
> NAXI TELECOMUNICAÇÕES
> +55 (47) 3054-2233
> 0800-932-0000 R.3322
> INOC-DBA BR 53001*100
> ASN 53001
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>