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

Willian Pires de Souza willian_pires at hotmail.com
Mon May 27 19:40:41 -03 2019


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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7Cdaa0e3af625d488d12fe08d6e2aa02e6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636945617173447090&sdata=p3u1oKlMGtMkKDT%2FnhxYNK1vIFhDcwLzM27KSbaUl6A%3D&reserved=0
> --
> gter list    https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7Cdaa0e3af625d488d12fe08d6e2aa02e6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636945617173447090&sdata=p3u1oKlMGtMkKDT%2FnhxYNK1vIFhDcwLzM27KSbaUl6A%3D&reserved=0
>
--
gter list    https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7Cdaa0e3af625d488d12fe08d6e2aa02e6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636945617173447090&sdata=p3u1oKlMGtMkKDT%2FnhxYNK1vIFhDcwLzM27KSbaUl6A%3D&reserved=0


More information about the gter mailing list