[caiu] IX-SP - Broadcast Alto - ARP Input Alto - Sessões Caindo
Douglas Fischer
fischerdouglas em gmail.com
Sex Ago 4 12:09:36 BRT 2017
Isso me lembra a questão do Arp-Reponder no IX.
Existem evoluções ou definições sobre isso?
Em 4 de agosto de 2017 12:07, Douglas Fischer <fischerdouglas em gmail.com>
escreveu:
> É o jeito!
> Ou rate-limit na interface ou usar COPP.
>
> Eu gostaria que houvesse um filtro que me permitisse filtrar ARP com base
> no endereço perguntado. Mas isso só em Firewall.
>
>
>
>
>
>
> Em 4 de agosto de 2017 10:51, Lista <lista.gter em gmail.com> escreveu:
>
>> Um arp-rate limit nas interface com o IX não ajudaria neste caso, para
>> evitar flap das seções?
>>
>>
>>
>> Em 3 de agosto de 2017 19:33, Eder F. Miotto <ederfmiotto em gmail.com>
>> escreveu:
>>
>> > Pior que é isto mesmo.. neste momento, analisei uma conexão no PIX
>> GVT-JD
>> > e está passando aproximadamente 1700 pps em arp. Cisco família 6/7k
>> sofre
>> > com
>> > este número.
>> >
>> > Fiz port-mirror da interface acima para uma porta do switch onde tenho
>> > conectado
>> > um host linux e rodei um "tcpdump -i ethX -c 100000 -n arp". Segue
>> algumas
>> > analises.
>> >
>> > Total de sources (IPs) enviando arp who-has: 1075
>> >
>> > Número de IPs solicitados (dentro do bloco 187.16.216.0/21): 1698
>> >
>> > Número de IPs solicitados (fora do bloco 187.16.216.0/21): 55 (mascara
>> > errada, proxy-arp, interface física compartilhada?)
>> > Ex:
>> >
>> > ARP, Request who-has 186.226.208.250 tell 187.16.219.41, length 46
>> > ARP, Request who-has 186.226.208.250 tell 187.16.220.154, length 46
>> > ARP, Request who-has 183.238.56.219 tell 187.16.218.171, length 46
>> > ARP, Request who-has 186.226.208.250 tell 187.16.220.61, length 46
>> > ARP, Request who-has 177.128.192.138 tell 187.16.216.54, length 46
>> > ARP, Request who-has 177.124.96.33 tell 187.16.217.237, length 46
>> > ARP, Request who-has 177.66.208.230 tell 187.16.217.237, length 46
>> >
>> >
>> >
>> > TOP 10 de IPs mais solicitados:
>> >
>> > pkts | ip | asn
>> > ---------+--------------------------+----------
>> > 2729 187.16.219.232 as28642
>> > 2145 187.16.223.171
>> > 1998 187.16.218.216 as262725
>> > 1548 187.16.222.134 as21574
>> > 1488 187.16.223.115 as28224
>> > 1345 187.16.217.48 as16735
>> > 1219 187.16.220.205 as262288
>> > 915 187.16.218.49
>> > 728 187.16.218.66 as36408
>> > 548 187.16.219.96
>> >
>> >
>> > TOP 10 de IPs que mais solicitaram arp:
>> >
>> > pkts | ip | asn
>> > ---------+--------------------------+----------
>> > 1451 187.16.220.23
>> > 872 187.16.221.244
>> > 797 187.16.221.243
>> > 736 187.16.216.253 rs1
>> > 690 187.16.223.253 rs3
>> > 627 187.16.217.63
>> > 616 187.16.221.197 as6939
>> > 598 187.16.216.92 as28166
>> > 598 187.16.216.175 as20144
>> > 585 187.16.223.239
>> >
>> > Obs: o número do ASN associado com o IP foi feito via consulta DNS ptr.
>> > Os IPs que estão sem identificação de asn é por que não tinham reverso.
>> >
>> > Se alguém quiser uma cópia dos logs, segue url para download (546k):
>> >
>> > https://ufile.io/i58mn
>> >
>> > Eder
>> >
>> >
>> >
>> >
>> > Em 3 de agosto de 2017 18:04, Douglas Fischer <fischerdouglas em gmail.com
>> >
>> > escreveu:
>> >
>> > > Estamos com problemas de sessões caindo com na Vlan ATM do IX-SP.
>> > >
>> > > Aparentemente somente as sessões BGP IPv4 que estão no ATM
>> > (Route-Servers +
>> > > Bilaterais) são afetadas.
>> > > Sessões IPv6, no ATM e nas Vlans Bilaterais, estão com um bom tempo de
>> > > vida.
>> > > Sessões IPv4 que estão em Vlan Bilaterais estão com um bom tempo de
>> vída.
>> > >
>> > >
>> > > Obviamente na hora do FLAP, por conta da convergência de rotas, CPU
>> vai
>> > lá
>> > > em cima.
>> > > Mas além disso percebemos o ARP Input tá comendo 17% de CPU, oque acho
>> > > bastante para um 7606.
>> > >
>> > >
>> > > Volume de Broadcast
>> > > -------------------
>> > > Em 30 segundos constatamos mais de 35mil pacotes de
>> Broadcast(contador da
>> > > interface).
>> > >
>> > > Ainda vamos fazer novamente as medições, mas há algum tempo atrás
>> > > observamos que o trafego BradCast+Multicast passava fácil de 10Mbps.
>> > >
>> > >
>> > > Tabela ARP
>> > > ----------
>> > > Observamos também que os tempo de vida dos registros das tabela ARP
>> estão
>> > > quase todos em "0".
>> > > Mesmo depois de esperar algum tempo, o mesmo endereço volta a ter AGE
>> > "0".
>> > >
>> > >
>> > >
>> > >
>> > > Mais alguém sofrendo com isso?
>> > >
>> > > P.S.: Isso não deveria influenciar, mas estamos com no GVT-JD.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Douglas Fernando Fischer
>> > > Engº de Controle e Automação
>> > > _______________________________________________
>> > > caiu mailing list
>> > > caiu em eng.registro.br
>> > > https://eng.registro.br/mailman/listinfo/caiu
>> > >
>> > >
>> > > --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
>> > >
>> > > https://eng.registro.br/mailman/options/caiu
>> > >
>> > _______________________________________________
>> > caiu mailing list
>> > caiu em eng.registro.br
>> > https://eng.registro.br/mailman/listinfo/caiu
>> >
>> >
>> > --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
>> >
>> > https://eng.registro.br/mailman/options/caiu
>> >
>> _______________________________________________
>> caiu mailing list
>> caiu em eng.registro.br
>> https://eng.registro.br/mailman/listinfo/caiu
>>
>>
>> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
>>
>> https://eng.registro.br/mailman/options/caiu
>>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
--
Douglas Fernando Fischer
Engº de Controle e Automação
Mais detalhes sobre a lista de discussão caiu