[GTER] Socorro! 3.1Mpps UDP len 34-46 matando Juniper/MX5-T-DC
Rodrigo 1telecom
rodrigo at 1telecom.com.br
Sat Nov 22 19:12:08 -02 2014
http://www.scn.rain.com/~neighorn/PDF/Traffic_Engineering_with_BGP_and_Level3.pdf
Este pdf tem umas communities da level3 ao final dele... Sao muitas...
Enviado via iPhone
Grupo Connectoway
> Em 22/11/2014, às 14:01, Joao Carlos Peixoto Ponce <jocapponce at gmail.com> escreveu:
>
> 2014-11-21 22:53 GMT-02:00 CTBC Telecom <algartelecom at gmail.com>:
>
>> 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.
>
> Obrigado novamente Tiago e também pela tentativa de apoio em pvt espero que
> caminhemos bem com o que te solicitei. Sim voce tem razão e sim a Juniper
> provavelmente tem razão. Meu desconforto é com a abordagem comercial e não
> a técnica. Os detalhes e motivos pelos quais o MX/5 está sofrendo dão uma
> boa e rica discussão mas no momento eu não me importo com os motivos e sim
> como evitar que esses limites surjam.
>
> Eu também li que o TRIO suporta até 55Mpps mas li que pra isso tem que ser
> no upgrade máximo. Que alcance 55Mpps eu tenho certeza tanto que na GLBX é
> um MX/40 quem consegue me filtrar, a preço de ouro é verdade mas ele da
> conta.
>
> No meu caso, ainda como MX/5 li que eu não devo esperar mais de 8Mpps, o
> que seria ótimo, mesmo no calculo da Juniper, se o MX/5 desse 8Mpps somando
> Rx+Tx de todas as portas eu teria 4Mpps para os RX nas portas WAN e
> descartaria o que não quero, não tendo outros 4Mpps de TX nas portas LAN
> mas a teoria é diferente da realidade. Primeiro que não está suportando
> 3.1Mpps (que da 6.2Mpps no calculo da Juniper caso eu consiga rotear esses
> pacotes), segundo que o limite do TRIO é de 55Mpps então se de fato
> pensarmos em X portas recebendo, o RE encaminhando e outros Y portas
> transmitindo, num cenário simples estamos falando de 27Mpps. Mas não me
> importo porque para mim não está dando conta.
>
> Notei que nessas estatísticas não devem entrar firewall. Quanto mais
> filtros eu colocava pior ficava. Com os filtros que preciso, como o
> seguinte:
>
> term DDoSNovembAsiaEuro {
> family inet {
> from {
> protocol udp;
> destination-port 37000-49999;
> packet-length 34-46;
> }
> then { discard; };
> }
> }
>
> O consumo de CPU sobe muito em especial com o "set packet-length 34-46".
>
> So pra referencia, durante o ataque sem o filtro do MX/40 do lado GLBX, ou
> seja com o ataque de fato passando pelo meu MX/5 a minha carga fica assim
> no RE0:
>
> Routing Engine status:
> Slot 0:
> Current state Master
> Election priority Master (default)
> Temperature 59 degrees C / 138 degrees F
> CPU temperature 63 degrees C / 145 degrees F
> DRAM 3584 MB
> Memory utilization 69 percent
> CPU utilization:
> User 24 percent
> Background 14 percent
> Kernel 25 percent
> Interrupt 36 percent
> Idle 0 percent
> Start time 2014-11-02 12:12:19 UTC
> Last reboot reason Router rebooted after a normal shutdown.
> Load averages: 1 minute 5 minute 15 minute
> 4.12 4.21 4.89
>
> O Interrupt é por conta do ataque e justamente é o que aumenta em maior
> proporção se eu tento filtrar com firewall. So pra saber, esse load ai é
> sem firewall, apenas o routing engine atuando.
> Outras saídas que talvez ajudem voces me ajudarem:
>
>> show chassis network-services
> Network Services Mode: IP
>> show configuration chassis network-services
> network-services enhanced-ip;
>> show configuration chassis network-services
> network-services enhanced-ip;
>> show chassis network-services
> Network Services Mode: Enhanced-IP
>> show invoke-on all-routing-engines
> re0:
> --------------------------------------------------------------------------
> Hostname: twibgp
> Model: mx5-t/dc
> JUNOS Base OS boot [13.3R1.6]
> JUNOS Base OS Software Suite [13.3R1.6]
> JUNOS Kernel Software Suite [13.3R1.6]
> JUNOS Crypto Software Suite [13.3R1.6]
> JUNOS Packet Forwarding Engine Support (M/T Common) [13.3R1.6]
> JUNOS Packet Forwarding Engine Support (MX Common) [13.3R1.6]
> JUNOS Online Documentation [13.3R1.6]
> JUNOS Voice Services Container package [13.3R1.6]
> JUNOS Border Gateway Function package [13.3R1.6]
> JUNOS Services AACL Container package [13.3R1.6]
> JUNOS Services LL-PDF Container package [13.3R1.6]
> JUNOS Services PTSP Container package [13.3R1.6]
> JUNOS Services Stateful Firewall [13.3R1.6]
> JUNOS Services NAT [13.3R1.6]
> JUNOS Services Application Level Gateways [13.3R1.6]
> JUNOS Services Captive Portal and Content Delivery Container package
> [13.3R1.6]
> JUNOS Services RPM [13.3R1.6]
> JUNOS Services HTTP Content Management package [13.3R1.6]
> JUNOS AppId Services [13.3R1.6]
> JUNOS IDP Services [13.3R1.6]
> JUNOS Services Crypto [13.3R1.6]
> JUNOS Services SSL [13.3R1.6]
> JUNOS Runtime Software Suite [13.3R1.6]
> JUNOS Routing Software Suite [13.3R1.6]
>
> re1:
> --------------------------------------------------------------------------
> Hostname: twibgp
> Model: mx5-t/dc
> JUNOS Base OS boot [13.3R1.6]
> JUNOS Base OS Software Suite [13.3R1.6]
> JUNOS Kernel Software Suite [13.3R1.6]
> JUNOS Crypto Software Suite [13.3R1.6]
> JUNOS Packet Forwarding Engine Support (M/T Common) [13.3R1.6]
> JUNOS Packet Forwarding Engine Support (MX Common) [13.3R1.6]
> JUNOS Online Documentation [13.3R1.6]
> JUNOS Voice Services Container package [13.3R1.6]
> JUNOS Voice Services Container package [13.3R1.6]
> JUNOS Border Gateway Function package [13.3R1.6]
> JUNOS Services AACL Container package [13.3R1.6]
> JUNOS Services LL-PDF Container package [13.3R1.6]
> JUNOS Services PTSP Container package [13.3R1.6]
> JUNOS Services Stateful Firewall [13.3R1.6]
> JUNOS Services NAT [13.3R1.6]
> JUNOS Services Application Level Gateways [13.3R1.6]
> JUNOS Services Captive Portal and Content Delivery Container package
> [13.3R1.6]
> JUNOS Services RPM [13.3R1.6]
> JUNOS Services HTTP Content Management package [13.3R1.6]
> JUNOS AppId Services [13.3R1.6]
> JUNOS IDP Services [13.3R1.6]
> JUNOS Services Crypto [13.3R1.6]
> JUNOS Services SSL [13.3R1.6]
> JUNOS Services IPSec [13.3R1.6]
> JUNOS Runtime Software Suite [13.3R1.6]
> JUNOS Routing Software Suite [13.3R1.6]
>
>
>
>
>>
>>
>> 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
>> --
>> gter list https://eng.registro.br/mailman/listinfo/gter
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list