[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