[GTER] Socorro! 3.1Mpps UDP len 34-46 matando Juniper/MX5-T-DC

[Joao Carlos Peixoto Ponce]

>
> >> Balanceamento de porta IP é feito para evitar dessequenciamento de
> pacotes,
>
>> então dependendo do perfil de tráfego poderá ir tudo para uma única
> porta.
> >> Assim, um tráfego de 1.1G pode saturar um port-bundle de n x 1G.
> >>
> >
> > OK, só não é o que está acontecendo.
> >
> >> Além disso, uma porta Giga não consegue transmitir 1 Gbps de pacotes
> >>>> pequenos. Por causa do inter-frame gap, uma porta giga transmite algo
> >> 600
> >>>> Mbps de pacotes desse tamanho se fiz as contas direito.
> >>>>
> >>>
> >>> OK, não é o que está acontecendo de qualquer forma.
> >>>
> >>>
> >> Porque você diz isso ? Quantos Mpps em cada interface física nos
> momentos
> >> de ataque ?
> >>
> >
> > Variando de 300 a 360Mbit/s por porta de tráfego quando o ataque chega a
> > mim.
> > De 860Kpps a 1.3Mpps por porta.
> > Ja tive picos de 2Mpps por porta.
> > Ja tive trafego de até 1.6Mpps por porta para pacotes TCP bem pequenos,
> na
> > casa de 200 bytes, em momentos de menor tempestade, trafego muito
> estranho
>
> Desculpe mas citando nosso querido Padre Quevedo, “isso non ecziste!”. O
> line-rate máximo possível para é de 1.488,095 pps em uma porta de 1Gbit/s
> (aka wire-speed). Ainda que você consiga enfiar 1Gbit/s em 1.6Mpps ou 2Mpps
> não vai conseguir essa taxa de PPS na porta em questão.
>
> Por melhor que seja um Juniper, o paradigma padre quevedo fala mais falto.
> Alguma base de entendimento no porque isso não é possível:
>
> http://kb.juniper.net/InfoCenter/index?page=content&id=KB14737
>
> Mas como você está se baseando em uma memória passada do que acredita ter
> vivenciado, vamos assumir que você errou ao monitorar ou está falando de
> portas agregadas.
>

Patrick e Rubens.
Sim voces tem razao.
Sim eu certamente me enganei.
Minha "memória passada" como você se refere vem dos meus gráficos de
Centron mas só pode ser erro no template RRD, no snmp ou outro erro.
Ou seja meus gráficos apesar de apontarem taxa de Mbit/s corretamente com o
que eu percebo ser a vazão deve mesmo estar mostrando coisas erradas com os
contadores de frames. Olhei no histórico e vi picos de 2.2M ou seja vocês
tem razão impossível.


> Em outro e-mail você menciona que está com LACP, se for em uma porta
> trunking OK esses valores são possíveis, se for “on the wire”, padre
> quevedo!
>

Não não é.
Era apenas a porta e não LAG.
O erro como disse acima parecer ser no Centreon.


> Olha existem mais comunidades BGP, no caso da GVT que podem ter ajudar.
> Sugiro que tente encontrar o Romao da GVT, tente escalar o ticket dentro de
> uma questão “BGP” até chegar nele. Que acredito esteja nessa lista e talvez
> veja isso. Todos problemas que tive e dependia da GVT para uma solução, foi
> com ele que me entendi. Excelente profissional.
>

Obrigado.
Anotado.


>
> Li em seu e-mail que amanhã de manhã você talvez receba o ataque de volta
> na caixa. Colete todas as saídas que os amigos solicitaram, Rodrigo,
> Rubens, Diogo em especial, e cole todas as saídas no pior momento do ataque
> se sua caixa tiver condições de gerar essa saída (se estiver responsivo).
> Temos informações desencontradas na mesa e a saída mais recentes desses
> comandos vai ajudar todos nós a ajudarmos seu caso.
>
> Sem dúvidas se tem uma caixa MX/40 segundo a pancada, tem algo estranho na
> sua Mx/5 já que basicamente são a mesma coisa em termos de processamento
> que parece na sua avaliação e na sua saída ser gargalo. Está subindo pra
> CPU o que deveria não estar sendo processado la.
>
> Adicione aos comandos pra você coletar pra gente, o seguinte:
>
> show security idp status
> show security idp counters packet
> show security idp counters ips
> show security idp attack table
> show security idp qmodule statistics
> request security idp security-package install detail-status
> request pfe execute command "show usp idp status" target fwdd
>

Olha.
Vou responder rapidamente. Consegui gerar todos essas saídas e optei por
enviar em PVT para as pessoas que quiserem me ajudar.
Algumas das saídas são enormes.


> Acima são associados a firewall e IPS. Mesmo que voce acredite não estar
> em uso, envie as saídas. Se não quiser expor detalhes do seu ambiente envie
> em PVT as pessoas tentando te ajudar. Esse consumo parece vir de outro
> lugar. Sua caixa está como BGP, vamos avaliar se não tem firewall stateful
> e outras coisas do IDP ligadas.
>
> Execute ainda:
>
> show system core-dumps no-forwarding
>
> E se der erro de not found não se preocupe, problema se encontrar algo me
> fale para seguirmos com debug, isso significa que sua caixa MORREU alguma
> vez.
>

Sim foram encontrados arquivos de core.
Te enviei em particular a saída se puder me ajudar com os proximos passos.
É certo que isso significa que minha maquina morreu?


>
> Execute:
>
> show system processes extensive no-forwarding
>
> Isso é o “top” do FreeBSD. Procure as colunas com alto consumo de WCPU e
> tome nota do que está na coluna CPU pra sabermos quem está processando o
> que. Será possível identificar o que o Trio está ou não está processando.
>
> Execute:
>
> show pfe statistics error
> show pfe statistics traffic
>
> show chassis routing-engine no-forwarding
> show chassis environment no-forwarding
>
> Execute tambem:
>
> show system boot-messages  no-forwarding
>
> Isso é o “dmesg” do FreeBSD.
>
> Nele procure esse trecho e nos envie:
>
> real memory  = 2147483648 (2048MB)
> avail memory = 1073795072 (1024MB)
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> Security policy loaded: JUNOS MAC/pcap (mac_pcap)
> Security policy loaded: JUNOS MAC/runasnonroot (mac_runasnonroot)
> netisr_init: !debug_mpsafenet, forcing maxthreads from 2 to 1
> cpu0 on motherboard
> CAVIUM's OCTEON 5020 CPU Rev. 0.1 with no FPU implemented
>         L1 Cache: I size 32kb(128 line), D size 8kb(128 line), sixty four
> way.
>         L2 Cache: Size 128kb, 8 way
>
> Quero saber qual CPU, algo na linha desse CAVIUM’s OCTEON da vida pode
> surgir. Esta vendo a parte ali com Security policy loaded? Procure ali por
> perto algo com AUDIT ou CASPER ja que pelo que vi nos seus e-mails
> anteriores você está usando JunOS versão 13. Se tiver habilitado isso vamos
> ter que desabilitar.
>

Certo.
Estou enviando em particular.


>
> Execute também:
>
> show system buffer no-forwarding
>
> Isso é o “netstat -m” do FreeBSD e vai ser significativo ver o que ele tem
> a dizer.
>
> Alias outra coisa que me ocorreu, quando executar o "show security idp
> counters packet” procure por:
>
> "jbuf pullup failed"
>


Meu contador de jbuf pulp failed é um valor muito estranho
Eu diria que é alto mas e excessivamente baixo
Ou seja abaixo de zero veja o trecho:

 jbuf pullup failed                                          -1603851390791


>
> E garanta que esse contador esteja zerado.
>

Na esta zerado


>
> Aproveitando salve também a saída de:
>
> request pfe execute command "show  security utm status all" target fwdd
>

Nesse comando tem outro pull up failed com valor negativo mas um numero
diferente
Veja em particular a saída completa.


> request pfe execute command "show usp flow tcp-proxy all" target fwdd
>
> Sei que não tem qualquer graças pra quem está na sua posição mas é um caso
> de expressivo interesse técnico de muitos aqui. É um problema que não afeta
> apenas uma caixa Juniper, é bem genérico.
>
> Esse seu perfil de tráfego mencionado é tráfego UDP das câmeras de
> segurança andam virando até notícia no fantástico hehe, voce sabe disso ne?
>
> Envie também por favor, se voce julgar adequado, a saída de:
>
> show configuration
>
> Ou para preservar sua segurança:
>
> show configuration | grep -v SECRET-DATA
>

Esse comando deu erro minhas senhas ficaram na saída do comando.


>
> Se achar que está se expondo demais envie em pvt essas saídas mas não
> deixe de enviar, creio que temos um número bom de especialistas em Juniper
> aqui na lista e provavelmente no seu PVT. E esse e-mail da CTBC Telecom @
> gmail.com ai interagindo nessa thread, abuse desses caras! Esse e-mail é
> “grupal” (não no sentido de sacanagem hehehe) e tem muita gente boa lendo
> ele.
>

Obrigado.
Preciso dormir.
Estou um pouco irritado com a ALGAR e talvez tenha deixado de ser gentil
com esse e-mail da algar no gmail mesmo.
Vou me retratar.


>
> Tenho um conhecido, professor Ricardo da FUMEC e CEMIG TELECOM, sei que
> você também é de MG então se precisar de um apoio no Juniper, recomendo
> entrar em contato. Se quiser posso apresenta-los (pvt), segue contato:
>
> Ricardo Bernardo dos Santos, MSc.
> ricardobernardosantos at gmail.com
> MCSE, CCNP, JNCIA
>
> Abraços. Qualquer coisa fique a vontade para entrar em contato.
>

Obrigado.

>