[GTER] Socorro! 3.1Mpps UDP len 34-46 matando Juniper/MX5-T-DC
Lucas Willian Bocchi
lucas.bocchi at gmail.com
Sat Nov 22 18:51:52 -02 2014
Cabra nao tem salvacao. Trava os anuncios internacionais, ativa um peer
pewueno no bgp num /24 e tenta achar a origem. Nao tou vendo outra solucao
pra esse negocio
Em 22/11/2014 18:48, "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