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

[CTBC Telecom]

A informação da Juniper procede. O MX5, e composto por apenas um chip de
encaminhamento. Esse chip, chamado de TRIO por eles, é capaz de suportar em
cenário ideal até 55Mpps, não importando de quais portas os pacotes
chegaram.

O que me parece é que por algum motivo os pacotes não estão sendo comutados
no plano de encaminhamento, ou seja, pelo chip TRIO, mas estão sendo
enviados a CPU para alguma tratativa. E nesse caso você deve estar
congestionando a interface entre a RE (controladora) e o TRIO. Essa
interface entre RE e TRIO é de apenas 1Gbps.



Verifique também se o seu MX está com esse comando habilitado "set chassis
network-services enhanced-ip"

2014-11-21 22:40 GMT-02:00 CTBC Telecom <algartelecom at gmail.com>:

> Joao, como você deixou público o problema, coloco a disposição para ajudar
> por aqui ou em PVT.
>
>
>
> 2014-11-21 21:38 GMT-02:00 Rodrigo Augusto <rodrigo at 1telecom.com.br>:
>
> vc esta com filtros na RE?
>>
>>
>> ----- Mensagem original -----
>> De: "Joao Carlos Peixoto Ponce" <jocapponce at gmail.com>
>> Para: "Grupo de Trabalho de Engenharia e Operacao de Redes" <
>> gter at eng.registro.br>
>> Enviadas: Sexta-feira, 21 de novembro de 2014 18:47:10
>> Assunto: [GTER] Socorro! 3.1Mpps UDP len 34-46 matando Juniper/MX5-T-DC
>>
>> Prezados
>>
>> 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).
>>
>> 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. Meu MX/5 esgota CPU em 2.8-2.9Mpps. 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.
>> 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.
>>
>> Meu CIDR é um /22, no início o alvo to ataque eram IPs previsíveis em uma
>> mesma /24 mas dai separei esse /24 e deixei de anunciar ele pro mundo. O
>> ataque virou de foco e foi para outro /24, tentei colocar em communities
>> para evitar seu anuncio para algumas regiões da Europa, Leste Europeu e
>> Asia mas o que diz a documentação dos meus upstream não parece condizer
>> com
>> a realidade dos filtros ja que mesmo nessas communities ainda recebo o
>> ataque.
>>
>> O ataque não tem caracteristica desses ataques da moda contra dns, ntp ou
>> snmp.
>> As portas 123, 53, 5353, etc não são o alvo, o alvo são um range de portas
>> que consegui mapear, na casa de 37XXX a 49XXX no começo achei que era RTP
>> ou outros breques de VoIP e afins mas me parece ser na verdade um range de
>> servidores de cameras IP de segurança.
>> Meus upstreams são ALGAR, GLBX e estou no PTT-SP pelo PIX da Telium. Isso
>> na teoria pois na prática só me sobra a Telium / PTT.
>>
>> A ALGAR com todo respeito mas me dou direito ao desabafo, é uma vexatória
>> vergonha como conduziu o meu atendimento entre a madrugada de quinta e
>> hoje. Eles mais que não conseguem me ajudar, parece que o router de borda
>> da ALGAR que me atende passou a sofrer também com esse fluxo e dai o que
>> eles fizeram? Deixaram de anunciar meu CIDR pro mundo para o ataque não
>> chegar a mim passando pelos routers deles. Sinceramente se tiver alguém da
>> ALGAR por aqui com a mínima responsabilidade sugiro que me contacte para
>> tentarmos resolver isso.
>>
>> 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. Um filtro por
>> tamanho de pacotes UDP e range de portas resolveu mas a GLBX está me
>> cobrando a bagatela de R$ 647,81 (um numer magico) ao dia para me alugar o
>> MX/40. Se o ataque durar 1 mes serão 20 mil reais ao mes, sendo que meu
>> contrato de transito IP com eles é de 3/4 desse valor, ou seja meu custo
>> mais que dobrou.
>>
>> 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. Estou
>> tranquilo no PTT ja que a origem desse ataque apesar de não identificada
>> precisamente sei que vem dos cafundós da europa e asia, segundo a glbx
>> conseguiu rastrear, não tendo EUA ou LATAM aparentemente envolvidos na
>> geração desse trafego.
>> Estou praticamente sem redundancia internacional ja que aumentei meu link
>> pela GLBX como medida de urgencia ja que fiquei sem os covardes da ALGAR.
>> Ou seja só tenho PTT segundo meu negócio, pois mesmo com o MX/40 da CTBC
>> evitando que esses PPS cheguem em mim sinto que tem muitos momentos de
>> instabilidade da GLBX para europa, que só apareceram depois desse ataque.
>> Creio que eles tambem estão sofrendo um pouco para rotear antes do MX/40
>> filtrar.
>> Preciso de ajuda. Preciso me livrar desse trafego antes dele chegar no meu
>> MX/5 sem ter que pagar pelo aluguel de um MX/40.
>>
>> 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.
>>
>> obrigado
>> joca
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>