[GTER] Perda de pacotes aleatória em Huawei NE20E-S2F

Bruno Vane broonu at gmail.com
Fri Sep 13 16:23:19 -03 2019


Pessoal,

Desencavando um tópico antigo, mas acho que seja de interesse de outros
participantes, o suporte da Huawei na China identificou que era mesmo um
bug, e sairá um patch para corrigir o problema. Resumindo, em algum momento
o BRAS não aplicava corretamente o controle de banda quando o cliente se
conectava, era aplicada um car de 32k, mesmo mostrando tudo certo na sessão
(100Mbps), mostrando a banda aplicada.

Em seg, 10 de jun de 2019 às 14:22, Bruno Vane <broonu at gmail.com> escreveu:

> @Uesley, tanto faz, passando pela caixa ou coma destino à caixa. Dois
> clientes lado a lado, um pode ter o problema e o outro não. Reconectando,
> resolvia.
>
> Em qui, 6 de jun de 2019 às 11:49, Uesley Correa <uesleycorrea at gmail.com>
> escreveu:
>
>> Bom dia.
>>
>> A perda é passando pelo Huawei ou com destino ao Huawei? Se é com destino,
>> é bom lembrar que soluções assim (Huawei, Cisco, etc) contém proteção de
>> CPU conta flood de pacotes de entrada (ICMP, consultas arp, etc). Seria
>> bom
>> dar uma olhada para ver se não é esse o caso.
>>
>> Saudações,
>>
>> On Thu, Jun 6, 2019, 08:45 Willian Pires de Souza <
>> willian_pires at hotmail.com>
>> wrote:
>>
>> > Quem gera resposta de icmp é o processador do seu roteador você
>> > desabilitou IPv6 e teve um ganho ok. Mas o que você tem que levar em
>> > consideração.
>> > Desabilitar IPv6 não é uma alternativa exceto se você estiver
>> considerando
>> > que tem ipv4 de sobra, ninguém tem.
>> >
>> > Ganhar CPU é garantir que o processador certo está tratando o pacote
>> > correto.
>> >
>> > Meu ponto de vista:
>> > Garanta que os blocos roteados nessa caixa IPv6/4 tenham um null route,
>> > isso vai garantir que nenhum pacote sem um destino use o cpu seja para
>> te
>> > enviar um unreachable seja para re escanear a arp table em busca de um
>> > destino.
>> > Icmp rate limite, arp rate limit Sao alcançados depois de uma CPU em
>> uso.
>> >
>> > Garante via ACL que seja impossível que um cliente te envie um pacote
>> com
>> > origem diferente da esperada.
>> >
>> > Por último acompanhe os logs de rate limit ele vai te ajudar a ver que
>> > está te gerando problema.
>> >
>> > Abraço
>> >
>> > Get Outlook for Android<https://aka.ms/ghei36>
>> >
>> > ________________________________
>> > From: gter <gter-bounces at eng.registro.br> on behalf of Bruno Vane <
>> > broonu at gmail.com>
>> > Sent: Tuesday, June 4, 2019 1:32:13 PM
>> > To: Grupo de Trabalho de Engenharia e Operacao de Redes
>> > Subject: Re: [GTER] Perda de pacotes aleatória em Huawei NE20E-S2F
>> >
>> > Mas eu perdia pacote IPv4 do cliente pingando para o próprio BRAS.
>> >
>> > Em seg, 3 de jun de 2019 às 17:04, Willian Pires de Souza <
>> > willian_pires at hotmail.com> escreveu:
>> >
>> > > Deve ser o mesmo motivo :D
>> > >
>> > > IPV6 sem ter para onde ir.
>> > >
>> > > O seu problema continua o mesmo, você só esta sem ele por mais um
>> tempo.
>> > > ________________________________
>> > > De: gter <gter-bounces at eng.registro.br> em nome de Bruno Vane <
>> > > broonu at gmail.com>
>> > > Enviado: sexta-feira, 31 de maio de 2019 10:17
>> > > Para: Grupo de Trabalho de Engenharia e Operacao de Redes
>> > > Assunto: Re: [GTER] Perda de pacotes aleatória em Huawei NE20E-S2F
>> > >
>> > > Nós desativamos o IPv6 para os clientes PPPoE e até então não tivemos
>> > mais
>> > > problemas.
>> > >
>> > > Em seg, 27 de mai de 2019 às 19:45, Willian Pires de Souza <
>> > > willian_pires at hotmail.com> escreveu:
>> > >
>> > > > Boa noite,
>> > > >
>> > > > Me parece que o seu problema é falta de null routing.
>> > > >
>> > > > Não sei qual o seu bloco ip, mas recomendo que você faça alguns
>> > > roteamentos
>> > > > marotos estáticos na sua caixa para prevenir destination
>> unreachable.
>> > > >
>> > > > Mass primeiro de tudo, se você tem ospf  precisa fazer um filtro com
>> > oque
>> > > > o seu ospf vai
>> > > > exportar para evitar exportar rotas estáticas.
>> > > >
>> > > > Algo assim:
>> > > >
>> > > > seu bloco local: 201.50.1.0/22  estou pegando uma parte do seu /20
>> > > >
>> > > > ospf 1000 router-id 10.254.100.254
>> > > >  import-route direct cost 11 type 1
>> > > >  import-route static cost 11 type 1 route-policy NO_EXPORT_NULL
>> > > >
>> > > >
>> > > > #
>> > > > route-policy NO_EXPORT_NULL deny node 10
>> > > >  if-match ip address prefix-list FULL_NETS
>> > > > #
>> > > >
>> > > >  ip prefix-list FULL_NETS index 10 permit 169.254.0.0 16
>> > > >  ip prefix-list FULL_NETS index 20 permit 172.16.0.0 12
>> > > >  ip prefix-list FULL_NETS index 30 permit 192.168.0.0 16
>> > > >  ip prefix-list FULL_NETS index 40 permit 10.0.0.0 8
>> > > >  ip prefix-list FULL_NETS index 50 permit 100.64.0.0 10
>> > > >  ip prefix-list FULL_NETS index 60 permit 201.50.1.0 22
>> > > >
>> > > >
>> > > > E por fim adicionar essas rotas para NULL
>> > > >  ip route-static 10.0.0.0 8 NULL0
>> > > >  ip route-static 169.254.0.0 16 NULL0
>> > > >  ip route-static 172.16.0.0 12 NULL0
>> > > >  ip route-static 192.168.0.0 16 NULL0
>> > > >  ip route-static 100.64.0.0 10 NULL0
>> > > >  ip route-static 201.50.1.0 22 NULL 0
>> > > >
>> > > >
>> > >
>> >
>> --------------------------------------------------------------------------------------------------------------------------------------
>> > > >
>> > > > Qual a explicação por trás disso, que pegamos aqui.
>> > > > Muitos clientes acabam solicitando pacotes de redes RFC1918 como
>> > destino,
>> > > > e isso vai para a querida
>> > > > cpu do router, assim como pacotes indo para a sua rede no caso /22
>> que
>> > > > ainda não foi alocado, e isso explica,
>> > > > a quantidade de destination unreachable.
>> > > >
>> > > > A interface que de base que você usa como pppoe pode conter acl de
>> > > entrada
>> > > > e saída bem restritiva, para esses
>> > > > alvos e isso é controlado pelo ASIC e não sobe para o CPU do router.
>> > > >
>> > > > Se quiser detalhar, manda a sua configuração base ai que a gente da
>> uma
>> > > > força.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > ________________________________
>> > > > De: gter <gter-bounces at eng.registro.br> em nome de Bruno Vane <
>> > > > broonu at gmail.com>
>> > > > Enviado: segunda-feira, 27 de maio de 2019 10:32
>> > > > Para: Grupo de Trabalho de Engenharia e Operacao de Redes
>> > > > Assunto: Re: [GTER] Perda de pacotes aleatória em Huawei NE20E-S2F
>> > > >
>> > > > Bom dia Willian,
>> > > >
>> > > > Segue:
>> > > >
>> > > >
>> > > > <BRAS4-SOVR>display icmp statistics
>> > > > Input:  bad formats          0          bad checksum              0
>> > > >         echo                 14734      destination unreachable
>>  232
>> > > >         source quench        0          redirects                 0
>> > > >         echo reply           0          parameter problem         0
>> > > >         timestamp request    0          information request       0
>> > > >         mask requests        0          mask replies              0
>> > > >         time exceeded        76         timestamp reply           0
>> > > >         Mping request        0          Mping reply               0
>> > > > Output: echo                 14         destination unreachable
>> >  1770294
>> > > >         source quench        0          redirects                 0
>> > > >         echo reply           14734      parameter problem         0
>> > > >         timestamp request    0          information reply         0
>> > > >         mask requests        0          mask replies              0
>> > > >         time exceeded        1217331    timestamp reply           0
>> > > >         Mping request        0          Mping reply               0
>> > > > <BRAS4-SOVR>
>> > > > <BRAS4-SOVR>
>> > > > <BRAS4-SOVR>display ip routing-table statistics
>> > > > Summary Prefixes : 18773
>> > > > Proto      total      active     added      deleted    freed
>> > > >            routes     routes     routes     routes     routes
>> > > > DIRECT     14         14         14         0          0
>> > > > STATIC     0          0          0          0          0
>> > > > RIP        0          0          0          0          0
>> > > > OSPF       0          0          0          0          0
>> > > > IS-IS      0          0          0          0          0
>> > > > BGP        6712       6711       13512      6800       6800
>> > > > UNR        12048      12048      49059      37011      37011
>> > > > Total      18774      18773      62585      43811      43811
>> > > > <BRAS4-SOVR>
>> > > > <BRAS4-SOVR>
>> > > > <BRAS4-SOVR>
>> > > > <BRAS4-SOVR>display cpu-usage service
>> > > > Cpu utilization statistics at 2019-05-27 10:30:54 855 ms
>> > > > System cpu use rate is :                24%
>> > > > ---------------------------
>> > > > ServiceName  UseRate
>> > > > ---------------------------
>> > > > SYSTEM           20%
>> > > > BRAS              2%
>> > > > FEA               2%
>> > > > AAA               0%
>> > > > ARP               0%
>> > > > BGP               0%
>> > > > CMF               0%
>> > > > CSP               0%
>> > > > DEVICE            0%
>> > > > DHCP              0%
>> > > > ETRUNK            0%
>> > > > EUM               0%
>> > > > FEC               0%
>> > > > FIBRESM           0%
>> > > > IFM               0%
>> > > > IP STACK          0%
>> > > > LDT               0%
>> > > > LINK              0%
>> > > > LOCAL PKT         0%
>> > > > MFLP              0%
>> > > > MSTP              0%
>> > > > ND                0%
>> > > > NETSTREAM         0%
>> > > > OAM               0%
>> > > > PKI               0%
>> > > > PNP               0%
>> > > > PTPA              0%
>> > > > RBS               0%
>> > > > RGM               0%
>> > > > RM                0%
>> > > > SLA               0%
>> > > > SMLK              0%
>> > > > SOC               0%
>> > > > SVRO              0%
>> > > > TNLM              0%
>> > > > TUNNEL            0%
>> > > > VLAN              0%
>> > > > ---------------------------
>> > > > <BRAS4-SOVR>
>> > > > <BRAS4-SOVR>
>> > > > <BRAS4-SOVR>
>> > > > <BRAS4-SOVR>display logbuffer | in cpu-defend
>> > > > Info: It will take a long time if the content you search is too
>> much or
>> > > the
>> > > > string you input is too long, you can press CTRL_C to break.
>> > > > Logging buffer configuration and contents : enabled
>> > > > Allowed max buffer size : 10240
>> > > > Actual buffer size : 512
>> > > > Channel number : 4 , Channel name : logbuffer
>> > > > Dropped messages : 0
>> > > > Overwritten messages : 0
>> > > > Current messages : 333
>> > > >
>> > > > May 26 2019 12:20:17-03:00 BRAS4-SOVR
>> > > >
>> > > >
>> > >
>> >
>> %%01CPUDEFEND/4/hwXQoSCpDefendDiscardedPacketAlarm_clear(l):CID=0x807f047d-alarmID=0x0c150009-clearType=service_resume;Security
>> > > > cpu-defend drop packets alarm cleared. (ChassisID=1, SlotID=3,
>> > > > ObjectIndex=40, DiscardedPackets=927569, DiscardedThreshold=30000,
>> > > > ProtocolDescription=IPV4_MTU_EXCEED, Reason=The discarded rate for
>> > > packets
>> > > > destined to CPU exceeded alarm threshold.)
>> > > > May 26 2019 01:31:13-03:00 BRAS4-SOVR
>> > > >
>> > > >
>> > >
>> >
>> %%01CPUDEFEND/4/hwXQoSCpDefendDiscardedPacketAlarm_active(l):CID=0x807f047d-alarmID=0x0c150009;Security
>> > > > cpu-defend drop packets alarmed. (ChassisID=1, SlotID=3,
>> > ObjectIndex=40,
>> > > > DiscardedPackets=927569, DiscardedThreshold=30000,
>> > > > ProtocolDescription=IPV4_MTU_EXCEED, Reason=The discarded rate for
>> > > packets
>> > > > destined to CPU exceeded alarm threshold.)
>> > > > <BRAS4-SOVR>
>> > > >
>> > > >
>> > > > Em sáb, 25 de mai de 2019 às 19:56, Willian Pires de Souza <
>> > > > willian_pires at hotmail.com> escreveu:
>> > > >
>> > > > > Envie os seguintes comandos:
>> > > > >
>> > > > > [~SBRSPO17IR04HH20E]display icmp statistics
>> > > > > Input:  bad format           0          bad checksum
>> 43
>> > > > >         echo                 5          destination unreachable
>> >  24005
>> > > > >         source quench        0          redirects
>>  4
>> > > > >         echo reply           581888     parameter problem
>>  0
>> > > > >         timestamp request    16         information request
>>  0
>> > > > >         mask requests        0          mask replies
>> 0
>> > > > >         time exceeded        59220      timestamp reply
>>  0
>> > > > >         Mping request        0          Mping reply
>>  0
>> > > > >
>> > > > > Output: echo                 584753     destination unreachable
>> > >  321149
>> > > > >         source quench        0          redirects
>>  0
>> > > > >         echo reply           5          parameter problem
>>  0
>> > > > >         timestamp request    0          information reply
>>  0
>> > > > >         mask requests        0          mask replies
>> 0
>> > > > >         time exceeded        638654717  timestamp reply
>>  15
>> > > > >         Mping request        0          Mping reply
>>  0
>> > > > >
>> > > > >
>> > > > > [~SBRSPO17IR04HH20E]display ip routing-table statistics
>> > > > > Summary Prefixes : 772374
>> > > > > Proto      total      active     added      deleted    freed
>> > > > >            routes     routes     routes     routes     routes
>> > > > > DIRECT     43         43         52         9          9
>> > > > > STATIC     8          8          34         26         26
>> > > > > RIP        0          0          0          0          0
>> > > > > OSPF       1          0          1          0          0
>> > > > > IS-IS      0          0          0          0          0
>> > > > > BGP        772324     772323     41438651   40666327   40666327
>> > > > > Total      772376     772374     41438738   40666362   40666362
>> > > > >
>> > > > >
>> > > > > [~SBRSPO17IR04HH20E]display cpu-usage service
>> > > > > Cpu utilization statistics at 2019-05-25 17:10:58 858 ms
>> > > > > System cpu use rate is :                18%
>> > > > > ---------------------------
>> > > > > ServiceName  UseRate
>> > > > > ---------------------------
>> > > > > FEA              15%
>> > > > > CMF               2%
>> > > > > SYSTEM            1%
>> > > > > AAA               0%
>> > > > > ARP               0%
>> > > > > BGP               0%
>> > > > > CSP               0%
>> > > > > DEVICE            0%
>> > > > > DHCP              0%
>> > > > > DNS               0%
>> > > > > ETRUNK            0%
>> > > > > EUM               0%
>> > > > > FEC               0%
>> > > > > FIBRESM           0%
>> > > > > IFM               0%
>> > > > > IP STACK          0%
>> > > > > LINK              0%
>> > > > > LOCAL PKT         0%
>> > > > > MFLP              0%
>> > > > > MSTP              0%
>> > > > > ND                0%
>> > > > > NETSTREAM         0%
>> > > > > OAM               0%
>> > > > > OSPF              0%
>> > > > > PNP               0%
>> > > > > PTPA              0%
>> > > > > RBS               0%
>> > > > > RGM               0%
>> > > > > RM                0%
>> > > > > SLA               0%
>> > > > > SMLK              0%
>> > > > > SOC               0%
>> > > > > SVRO              0%
>> > > > > TNLM              0%
>> > > > > VLAN              0%
>> > > > > TUNNEL            0%
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > display logbuffer | in cpu-defend
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > ________________________________
>> > > > > De: gter <gter-bounces at eng.registro.br> em nome de Bruno Vane <
>> > > > > broonu at gmail.com>
>> > > > > Enviado: quinta-feira, 23 de maio de 2019 17:33
>> > > > > Para: Grupo de Trabalho de Engenharia e Operacao de Redes
>> > > > > Assunto: [GTER] Perda de pacotes aleatória em Huawei NE20E-S2F
>> > > > >
>> > > > > Pessoal,
>> > > > >
>> > > > > Estamos com alguns BRAS Huawei aqui e um deles está apresentando
>> um
>> > > > > problema bem estranho. É um NE20E-S2F Version 8.180 (NE20E
>> > > > > V800R010C10SPC500), com patch V800R010SPH035 aplicado.
>> > > > >
>> > > > > O problema é totalmente (aparentemente) aleatório, um cliente
>> PPPoE
>> > que
>> > > > > está funcionando normalmente de repente para de funcionar, o ping
>> do
>> > > > > cliente para o próprio BRAS fica com uns 70% de perda, navegação
>> web
>> > ou
>> > > > > qualquer outro serviço fica impraticável. Isso surge em horários
>> > > > aleatórios
>> > > > > do dia, com uma quantidade de clientes aleatória, não afeta todos
>> os
>> > > > > clientes. Se eu desconectar e reconectar, resolve. Pode ser que
>> > resolva
>> > > > em
>> > > > > definitivo bem como pode acontecer de novo, com esse mesmo
>> cliente.
>> > > > > Acontece tanto em IPv4 e IPv6, e somente com PPPoE, um cliente L3
>> não
>> > > > > apresenta essa perda.
>> > > > >
>> > > > > Alguém já passou por algum problema parecido?
>> > > > >
>> > > > > Esse BRAS está com 21 mil clientes, tenho outro que não está dando
>> > > > > problema, mas versão mais antiga.
>> > > > > --
>> > > > > gter list
>> > > > >
>> > > >
>> > >
>> >
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603222023&sdata=Q258UK9r%2B4qJdy2rQE7boojRtVJgMV4rKNbW9MIbVSE%3D&reserved=0
>> > > > > --
>> > > > > gter list
>> > > >
>> > >
>> >
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603222023&sdata=Q258UK9r%2B4qJdy2rQE7boojRtVJgMV4rKNbW9MIbVSE%3D&reserved=0
>> > > > >
>> > > > --
>> > > > gter list
>> > > >
>> > >
>> >
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603222023&sdata=Q258UK9r%2B4qJdy2rQE7boojRtVJgMV4rKNbW9MIbVSE%3D&reserved=0
>> > > > --
>> > > > gter list
>> > >
>> >
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603222023&sdata=Q258UK9r%2B4qJdy2rQE7boojRtVJgMV4rKNbW9MIbVSE%3D&reserved=0
>> > > >
>> > > --
>> > > gter list
>> > >
>> >
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603232027&sdata=Dq%2FyI%2BNyVHzm76FtDXs0j98GobW%2FIsVa%2Fe%2BdqY3ROU8%3D&reserved=0
>> > > --
>> > > gter list
>> >
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603232027&sdata=Dq%2FyI%2BNyVHzm76FtDXs0j98GobW%2FIsVa%2Fe%2BdqY3ROU8%3D&reserved=0
>> > >
>> > --
>> > gter list
>> >
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C9c37f67287d2469d170008d6e90be2cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636952634603232027&sdata=Dq%2FyI%2BNyVHzm76FtDXs0j98GobW%2FIsVa%2Fe%2BdqY3ROU8%3D&reserved=0
>> > --
>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>> >
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>


More information about the gter mailing list