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

Bruno Vane broonu at gmail.com
Mon May 27 10:32:19 -03 2019


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://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Feng.registro.br%2Fmailman%2Flistinfo%2Fgter&data=02%7C01%7C%7C637f04472cc441d35cad08d6e03d522b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636942951342038684&sdata=g112hdlm0X0D%2FGdwUiSKocQvmcRmjtXacR%2BBmWMpgxU%3D&reserved=0
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


More information about the gter mailing list