[GTER] TOP BUG mais estranho do RouterOS

Tue Apr 10 10:04:53 -03 2018

Retificando...

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

Se você definir como 1492 bytes (máximo em relação a Ethernet SEM 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 10 de abril de 2018 10:03, Andre Almeida <andre at bnet.com.br> escreveu:

> 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
>>
>
>