[GTER] TOP BUG mais estranho do RouterOS

Mon Apr 9 18:43:49 -03 2018

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