[GTER] Looping L2 / Arp Flood em roteadores Juniper.

[Rubens Kuhl]

2013/2/8 Gustavo Santos <gustkiller at gmail.com>:
> A algum tempo, venho notando de muita gente está começando a adotar
> roteadores Juniper , principalmente da linha MX.
>
> Porém, estes roteadores tem um conjunto de filtros default e implícitos,
> chamado de DDOS-PROTECTION. O problema é que um destes filtros é uma
> armadilha, e é o ARP filter.
>
> O Arp filter, é um filtro default do pacote de proteções contra DDoS e é
> system wide, ou seja, é um filtro único para todo o sistema. O resultado
> disto, é que em caso de flood ou looping L2, como os últimos que
> aconteceram no PTT-SP, o roteador simplesmente para de responder arp em
> TODAS as suas interfaces causando o travamento/parada de todos os outros
> protocolos como OSPF /BGP que estão nas interfaces não conectadas ao PTT.
>

Um alerta similar que faço é sobre Cisco. É bem fácil seguindo os
guias de criação de "Control-Plane Policing" (CoPP) deixar multicast
com rate-limit de alguns kbps. Isso é suficiente para subir uma sessão
OSPF, pois mesmo gente usando fast-hello não se transita tantos bytes
assim em multicast... agora, é só algum l-user começar a mandar
multicast para o gateway (ex: impressoras) que a quantidade vai ser
grande o suficiente para causar rate-limit de multicast indo para a
CPU de roteamento. O rate-limit vai jogar fora de forma isonômica
alguns pacotes de HELO, até que todas as suas conexões OSPF caiam.

Então ao implantar CoPP você precisa separar muito bem os buckets e
ter certeza que os matches estão funcionando (o que dependendo da
versão de supervisora vai de difícil a impossível) para que coisas
como OSPF e IPv6 Neighbor Discovery continuem funcionando mesmo que
venha lixo. Notar que assim como no caso que você citou, o que gera a
indisponibilidade não é um esgotamento de recursos, mas uma "alergia"
que gera uma reação desproporcional do equipamento.

Rubens