[GTER] Socorro! 3.1Mpps UDP len 34-46 matando Juniper/MX5-T-DC
Joao Carlos Peixoto Ponce
jocapponce at gmail.com
Sat Nov 22 15:01:58 -02 2014
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
>
More information about the gter
mailing list