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

[Joao Carlos Peixoto Ponce]

2014-11-21 21:20 GMT-02:00 Rubens Kuhl <rubensk at gmail.com>:

> >
> >
> > Tenho um Juniper MX/5/T/DC que em tese deveria suportar até lindos 8Mpps
> > mas me parece que o discurso de venda conta 8Mpps agregado em todas as
> > portas. O fato é que desde a última madrugada tomando um ataque de
> 3.1Mpps
> > (que segundo o suporte da Juniper isso dá 6.2Mpps, 3.1 que entra e 3.1
> que
> > sai ou tenta sair).
> >
>
> Isso se aplicaria a banda mas não a pps... tem algo estranho nessa resposta
> deles.
>

Estão simplesmente somando pps de RX + pp de TX, portas diferentes, pps
diferentes, fluxos diferentes, mesmos recursos computacionais.


> >
> > Esse ataque é de pacotes udp com algumas particularidades que deu para
> > mapear entre elas pkt len variando de 34-46 bytes.
> > Isso gera na minha entrada 1.1Gbit/s de lixo, mas não é a banda meu
> > problema, mas a taxa de PPS.
>
>
> Se você tem um MX5, que não tem porta 10G mas apenas porta 1G, 1.1Gbps é
> suficiente para lotar a porta de 1G, não ?
>

Que me conste portas de 10G somente a partir do MX/40.
Não entendi seu calculo mas não tenho apenas 1 porta ou 2 portas.
Inicialmente estava em 3x1G para os upstream e 4x1 para minha LAN.

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.


> > Meu MX/5 esgota CPU em 2.8-2.9Mpps.
>
> O MX5 não comuta em CPU, e mesmo um pacote que o Trio 3D não roteie iria
> para o exception processor.
> O que está lotando exatamente nessa quantidade de Mpps ?
>

Não entendi o que o MX5 não faz mesmo que o TRIO não faça rss, e não
entendi sua pergunta. Você pergunta no profiling o que esta lotando? Não
entendi mesmo.


> > Apenas
> > roteando. Se coloco regra de firewall a regra pega o fluxo mas consome
> > ainda mais pacote me gerando uma negação de serviço imediata com apenas 1
> > regra de firewall.
> >
>
> Apesar de regras de firewall consumirem parte dos ciclos úteis do ASIC,
> diminuindo sim a capacidade de encaminhamento em pps, o cenário ainda não
> está fechando...
>
>
> > Meu problema fica pior, o ataque vem de endereços IPs que não fazem
> > sentido, alguns de classes reservadas que não tem dono, outros de china,
> > vietnan, russia mas não importa o IP porque ja notamos que é soprado. Não
> > tem para alguns desses IP sequer rota BGP anunciada, ou seja ninguém se
> > preocupa em receber resposta é um ataque exclusivo de TX, eu só tomo
> > pancada e não respondo nada.
> >
> >
> Se for um bom número dos IPs, usar loose-mode RPF poder ajudar. Eu tenho
> impressão que a proporção não vai compensar, mas é uma tentativa.
>
>
rfp-check ja estava habilitado e mode ja está loose.


> > A GLBX colocou um Juniper MX/40 pois segundo eles precisaram de uma porta
> > de 10Gbit/s para dar conta desse PPS e conseguiram filtrar.
>
> Considerando a banda que você comentou, talvez seja pela banda mesmo...
>

Não estou tendo esgotamento na porta
É esgotamento de capacidade de processamento

Como a ALGAR caiu fora no meu cenário a GLX já se posicionou de forma a me
permitir fechar com eles 2 ou 3 portas de 1Gbit, como chega nos viramos com
wfq por pacote ou qualquer outro balancing ou BGP mesmo que seja.



> > Preciso de uma solução para isso alguma sugestao que não seja comprar uma
> > caixa de 100 mil para esse filtro pois isso inviabiliza meu negocio.
>
>
> Upgrades da Juniper não costumam ser baratos, mas você talvez consiga ir
> para uma ou duas portas 10GE por menos do que isso.
>

Não sei se é meu contato comercial mas não me deram escolha.
Para eu ir para 10Gb tenho que pular de MX/5 pra MX/40 nem MX/10 me atende.

O custo do lease do MX/40 já não fecha com minha verba que dirá a
aquisição/upgrade.
Preciso de uma solução certa.


>
>
> > Preciso de sugestões seguras e reais, conto com a experiência dos
> > participantes dessa lista para isso. Não posso arriscar comprar um
> > equipamento XYZ se não tiver certeza que ele vai resolver a questão.
> > Gostaria de uma solução baseada em BGP algo mais eficiente que deixar de
> me
> > anunciar (rss rss) ou alguma community milagrosa que evite meus anúncios
> de
> > fato chegarem nesse faroeste sem xerife que é a russia, china, e outros
> > buracos do leste europeu.
> >
>
> Se você souber em função do que a GBLX já tenha te passado alguns AS de
> onde esteja vindo o ataque, você pode tentar se tornar invisível para esse
> AS da seguinte forma:
>
> Seu anúncio BGP hoje para trânsito: <SEU AS> ou <SEU AS> <SEU AS>
> Seu novo anúncio BGP: <SEU AS> <AS1 de onde vem o ataque> <AS2 de onde vem
> o ataque> <SEU AS>
>
> Com isso o controle de aceitação de rotas do EBGP desses AS vai descartar
> suas rotas por achar que elas vieram de lá e não deveriam estar sendo
> recebidas de outros.
>

Parece bom, consigo fazer isso no Juniper? Conheço formas de prebendar meu
AS ou o AS da GLBX diversas vezes.
O problema é o seguinte, como eu mencionei antes os IPs são forjados então
os AS que eu mesmo mapeei não valem nada. Conseguimos mapear ASs de
transito, foi assim que vimos que as origens são regiões especificas da
europa e asia. Pelos transito não pelos AS de origem.

Essa abordagem que voce sugere teria efeito equivalente?




>
>
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter