[GTER] Perda de pacotes aleatória em Huawei NE20E-S2F
Uesley Correa
uesleycorrea at gmail.com
Thu Jun 6 11:28:55 -03 2019
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
>
More information about the gter
mailing list