[GTER] TOP BUG mais estranho do RouterOS

Mon Apr 9 15:29:59 -03 2018

 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
>