[GTER] Perda de pacotes aleatória em Huawei NE20E-S2F
Bruno Vane
broonu at gmail.com
Tue Jun 4 13:32:13 -03 2019
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7Cf35423a1607a44c505c208d6e5cfcd10%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636949078023866452&sdata=XahmFb7SgX%2BQuoaMWZ0ymxNzM1kstdyI2azEbXBOVPY%3D&reserved=0
> > > --
> > > gter list
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7Cf35423a1607a44c505c208d6e5cfcd10%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636949078023866452&sdata=XahmFb7SgX%2BQuoaMWZ0ymxNzM1kstdyI2azEbXBOVPY%3D&reserved=0
> > >
> > --
> > gter list
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7Cf35423a1607a44c505c208d6e5cfcd10%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636949078023876457&sdata=GQ8OSZKmjrWOyDfYLM5iuUiFrqlPOPZ51SbqgiMikC8%3D&reserved=0
> > --
> > gter list
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7Cf35423a1607a44c505c208d6e5cfcd10%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636949078023876457&sdata=GQ8OSZKmjrWOyDfYLM5iuUiFrqlPOPZ51SbqgiMikC8%3D&reserved=0
> >
> --
> gter list
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7Cf35423a1607a44c505c208d6e5cfcd10%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636949078023876457&sdata=GQ8OSZKmjrWOyDfYLM5iuUiFrqlPOPZ51SbqgiMikC8%3D&reserved=0
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list