Seu provedor de internet começou pequeno, com poucos usuários, com tecnologias de bridging e switching, e agora está grande, com vários pontos de repetição, pontos de presença, e também com o infeliz aumento dos problemas relacionados às redes, os “loopings”? E seu consultor de rede insiste em dizer: “Migre sua rede para camada 3”? Se sim, este artigo é para você!
Em primeiro lugar, precisamos distinguir a origem dos problemas. Os citados loops, que são percebidos através dos logs dos equipamentos, e que frequentemente estão associados à “derrubada” de partes da rede. Esses não são os inimigos, são apenas os alertas que recebemos de que os inimigos podem entrar em ação a qualquer momento.
Os alertas de loops sinalizam que um caminho propício se formou para os destrutivos “floods”. Os floods, também conhecidos como “inundações de pacotes”, começam como um fluxo normal de pacotes (por esse motivo não são identificados pelos demais alarmes da rede), porém se transformam em uma “tempestade de broadcast” ao combinar dois fatores em conjunto: um caminho em loop (um caminho cujo terminal retorna para o ponto de início, não tendo um fim), mais um emissor de pacotes persistentes (uma origem de comunicação cujo fluxo é ininterrupto ou grande o suficiente para gerar muitos pacotes).
As inundações de rede, ou simplesmente floods, quando encontram um caminho propício (loop), podem ocorrer de forma imprevisíveis e com grandezas de devastações também imensuráveis. Um caminho em loop constituído para flood pode apresentar problemas iminentes ou levar dias até seus efeitos serem percebidos. Também podem ocorrer repentinamente, como uma chuva de verão, que abranda também repentinamente, sem deixar maiores estragos, ou como um tsunami, que rapidamente deixa um rastro de devastação.
Tendo um caminho propício em loop, o gatilho que determinará a escala de devastação do flood será a fonte emissora. Esta pode ser um mero usuário de uma rede corporativa, um CPE cliente do seu provedor, um cliente PPPoE, uma consulta SNMP em tempo real, um ping ICMP com a opção “-t”, até mesmo um protocolo de proteção STP. As opções são infinitas. Imagine que um anel foi constituído, e que ao longo desse anel você tem todos esses agentes plugados. O primeiro que iniciar a transmissão no anel já será o suficiente para dar início à inundação. Se outros começarem a falar no mesmo anel, aumentarão a devastação. E se as conversas envolverem pacotes maiores, então o caos estará alcançado.
Porém, um caminho propício em loop pode não apresentar problemas de forma iminentes, pois os “agentes plugados ao anel” podem ser poucos e podem estar “adormecidos” – por exemplo, um cliente PPPoE, que só utiliza a internet nos fins de semana. Quando o cliente PPPoE finalmente for utilizar a internet, abrir seu navegador, e o mesmo começar a transferir diversas solicitações de HTTP, com tamanhos variados, a tormenta virá à tona e com possíveis rastros de devastação.
Mas como se dá esse rastro de devastação? A tormenta da inundação de pacotes em broadcast, como o nome já diz, encaminha todos os pacotes do emissor para todos os demais agentes que estiverem conectados ao anel (loop), na forma de um broadcast. Cada agente ativo (CPE, DTE, comutador, roteador, core, gateway) irá receber o pacote do emissor e devolver para o mesmo anel, onde todos os agentes novamente irão receber as respostas de cada agente e irão tentar responder outra vez, gerando um loop infinito de perguntas e respostas. Na medida em que os agentes plugados respondem as perguntas (queries) em modo loop infinito, irá aumentar o volume de dados no anel de forma exponencial. Esse volume todo deverá ser respondido por cada agente ativo do anel, pois assim funcionam os protocolos de broadcast, multicast e unicast. Todas essas perguntas e respostas vão ocasionar dois eventos: exaustão dos consumos de CPU e memória dos agentes ativos, e exaustão da capacidade do enlace físico. A exaustão desses recursos leva a uma condição bem conhecida: o travamento do ativo.
Na melhor das situações, o travamento de um agente do anel pode condicionar a quebra do anel (loop), e pôr fim de forma imediata a tormenta, que irá sanar por completo nos respectivos ativos atormentados na medida que suas CPU e memória finalizem todas as respostas em broadcast. Porém, raramente essa sorte é alcançada, e o que vemos no dia a dia, é que a maioria, se não todos os agentes do anel (loop), perecem à exaustão dos seus recursos. É comum nestes momentos de pane na rede vermos administradores de redes tomarem ações inapropriadas, como realizar um reboot em ativos da rede. O reboot dá uma falsa sensação de recuperação e normalização, pois interrompe a ação dos agentes transmissores. Porém, apenas reinicia a tempestade, voltando o cronômetro da devastação para zero e sabendo que em breve retornará com força total.
E quais as formas de erradicar esses problemas de inundações de pacotes em rede? De forma clássica: elimine os caminhos propícios (formações de loops). Se eliminar não for uma opção, decorrente de um crescimento desorganizado da sua rede, então adote a estratégia do “Dividir para Proteger”. Vamos discutir essa estratégia a seguir.
Antes de mais nada, acredito que sua rede cresceu através do uso de bridging e switching. Equipamentos cujas soluções são as melhores para o mercado de provimento de internet, pois apresentam o melhor custo-benefício, e são em torno de 10 a 15 vezes mais performáticas do que as soluções baseadas em routing. Enquanto um bom roteador só processa algo em torno de 100 K de pacotes por segundo, o mesmo comutador com preço equivalente consegue processar 100 M de pacotes por segundos. Porém, é preciso saber trabalhar com essas soluções mais baratas, que implicam uma necessidade de organização muito em dia. Apenas para esclarecimentos, as soluções baseadas em routing têm suas características típicas, mas o cenário que estou apresentando é de provedores de internet, emergentes da falência das grandes operadoras nacionais.
Na literatura da Cisco, do curso preparatório para projetista de redes, Cisco Certified Design Network – CCDN, as chamadas Redes de Campo equivalem, na prática, às redes de provedores emergentes, que independente das tecnologias de enlace adotadas precisam antes de tudo organizar suas topologias. Após a organização da topologia, estratégias de Dividir para Proteger precisam ser adotadas para manter o funcionamento saudável da rede. Essas ações resumem o que os consultores de rede relatam em seus artigos técnicos como “migrem suas redes de camada 2 para camada 3”, mas que não explicam os motivos.
Neste artigo, apresento minhas anotações realizadas no curso do CCDP Cisco, o qual foquei tendo como base resolver os problemas de loops na rede de um provedor em Pernambuco, que mescla tecnologias de fibra óptica com rádios, e cuja consultoria recomendou alterar a topologia da rede para camada 3, porém sem apresentar embasamentos sólidos. Nestes passos, descrevo que não existe uma necessidade plena de alterar todos os ativos da rede, nem de realizar grandes alterações lógicas drásticas na rede, e sim uma combinação de melhores práticas lógicas de comutação e roteamento, mantendo a mesma infraestrutura física de comutadores switches e bridges:
1. A primeira ação de um provedor emergente para estruturar sua rede de forma profissional é estabelecer a divisão conceitual da rede no modelo hierárquico da Cisco, conforme: 1) Área de backbone – corresponde ao núcleo da rede (core network e datacenter), o qual deverá ser no mínimo um TIER-1 pela EIA/TIA-942; 2) Área de distribuição – corresponde aos pontos de distribuição do backbone e que distribuem as redes para os clientes, onde deverão constar todas as formas de redundância de transporte e rota; 3) Área de acesso – corresponde aos pontos de acesso que abordam os clientes nas últimas milhas, onde deverão constar possíveis formas de redundância de enlaces na última milha;
2. Adotar as melhores práticas de comutação de rede (camada 2), conforme: 1) Áreas de backbone e áreas de distribuição não podem conter portas de acesso, apenas portas trunk; 2) Áreas de backbone e áreas de distribuição não podem estar visíveis dentro de domínios de broadcast, ou seja, todo e qualquer tráfego deverá estar necessariamente percorrendo por dentro de uma VLAN; 3) Cada cliente deve ser um domínio de broadcast específico, com uma VLAN específica que saia da área de backbone até o CPE cliente na área de acesso; 4) Áreas de distribuição precisam estar protegidas por protocolos de proteção de rede, como o STP, RSTP ou outro protocolo equivalente; 5) Protocolos de proteção distintos não podem estar ativados simultaneamente em um mesmo ativo da rede, mas cada ativo da rede pode fazer uso de um protocolo distinto de proteção; 6) Cada bridge criada nas áreas de backbone e distribuição deverá conter única e exclusivamente as portas que encaminham a VLAN do cliente, e estas não poderão conter protocolos de proteção em ativos de rede cuja presença de um protocolo de proteção já esteja ativado; 7) Clientes com rotas distintas por VLANs distintas precisam ser cuidadosamente implantados para não formar um caminho de loop lógico entre VLANs;
3. Adotar as melhores práticas de roteamento de rede (camada 3), conforme: 1) Cada cliente deve estar em uma sub-rede específica, adotando a relação 1-1 entre VLAN e sub-rede; 2) Clientes corporativos (LAN-TO-LAN), devem permanecer em uma mesma VLAN porém com sub-redes distintas; 3) Toda e qualquer comunicação entre clientes, mesmo os corporativos, deverá ser realizada através de um gateway roteador de rede; 4) Toda e qualquer regra de firewall, ACL, deverá ser especificada na área de acesso; 5) É imprescindível haver para cada VLAN o monitoramento do tráfego de rede, de forma a alarmar em condições onde o fluxo de broadcast, multicast ou unicast seja maior que 20% da capacidade de banda do cliente; 6) Idealmente, que nos gateways concentradores das VLANS haja um monitoramento de tráfego, com regras ativas, que realizem o bloqueio de tráfego para situações de inundações de pacotes, mesmo que isso torne indisponível um cliente, mas que mantenha os demais clientes do gateway em normal operação;
4. Combinar as melhores práticas de comutação de rede (camada 2) com roteamento de rede (camada 3), conforme: 1) Cada CPE cliente deverá ter sua porta de entrada em modo Acesso, para o caso de haver uma única VLAN de rota para o cliente, ou trunk, para o caso de haver mais de um VLAN de rota para o cliente (rota primária e secundária); 2) Para cada VLAN de entrada deverá ser realizada uma bridge de acesso, de forma que o cliente possa separar seus tráfegos, realizar gerência ou outra necessidade que for demandada pelo cliente; 3) Não deverá haver portas bridges desocupadas ou em standby, pois o uso de protocolos de proteção de redes não é recomendado em CPE cliente, e dessa forma o controle de portas de acesso é majoritário nessa Área da rede; 4) Cada VLAN deverá estar associada a uma única sub-rede, e cada VLAN corresponderá a um serviço distinto, como: rota secundária, serviço de CDN, serviço de multicast IPTV, serviço de monitoramento e gerência de rede, serviço de L2L, serviço MPLS, serviço de internet etc; 5) As políticas de segurança que dizem respeito de forma exclusiva ao cliente deverão ser realizadas no CPE cliente;
Em geral, observo que os pontos propostos acima conduzem uma rede emergente, não planejada, para as devidas formas de operação e segurança profissional que o mercado exige. Em minhas experiências, a simples adoção de um ou outro desses pontos já foi suficiente para apresentar significantes resultados em curto período de tempo. A junção de todas essas ações seria o equivalente a apresentar um plano de ação definitivo para curto, médio e longo prazo, de forma a manter todos os ativos comutadores existentes no provedor (camada 2), ao mesmo tempo em que se adota as melhores práticas de segurança do roteamento (camada 3), alcançando desta forma alto níveis de SLA (TIER-2 de rede).
Márcio Nogueira é gestor de NOC em operadora de telecomunicações de Pernambuco. Professor de pós-graduação em redes e segurança da informação. Presta consultoria e treinamentos em BPM, PMP, ITIL, Cobit, VMware ESXi, Linux, Windows Server, ISO 27.002, Routing & Bridging, Wireless, VPN e Certificados Digitais. https://www.linkedin.com/in/marcionogueira
No Comment