Este artigo é o segundo de uma série intitulada ‘Como controlar sua infraestrutura de rede’. O conteúdo de todos os artigos da série e os links podem ser encontrados .
Nosso objetivo neste estágio é organizar a documentação e a configuração.
Ao final deste processo, você deverá ter um conjunto necessário de documentos e uma rede configurada de acordo com eles.
Agora não falaremos sobre auditoria de segurança – isso será abordado na terceira parte.
A dificuldade em realizar a tarefa proposta neste estágio varia bastante de empresa para empresa.
A situação ideal é quando
- sua rede foi criada de acordo com o projeto e você possui todo o conjunto de documentos
- sua empresa implementou para a rede
- de acordo com esse processo, você possui documentos (incluindo todos os esquemas necessários) que fornecem informações completas sobre a situação atual
Nesse caso, sua tarefa é bastante simples. Você deve revisar os documentos e analisar todas as mudanças que foram feitas.
Na pior das hipóteses, você terá uma
- rede criada sem projeto, sem planejamento, sem aprovação, por engenheiros que não possuem o nível adequado de qualificação,
- com alterações caóticas, não documentadas, muita ‘bagunça’ e soluções não otimizadas.
É evidente que sua situação está em algum lugar entre esses extremos, mas, infelizmente, na escala de melhor – pior, com alta probabilidade, você estará mais próximo do pior extremo.
Nesse caso, será necessário também ter a habilidade de ler pensamentos, pois você terá que aprender a entender o que os ‘designers’ pretendiam, recuperar sua lógica, finalizar o que não foi completo e remover ‘lixo’.
E, claro, você precisará corrigir seus erros, modificar (neste estágio, minimamente) o design e alterar ou criar esquemas do zero.
Este artigo não reivindica, de forma alguma, ser exaustivo. Aqui, descreverei apenas os princípios gerais e abordarei alguns problemas comuns que precisam ser resolvidos.
Conjunto de documentos
Começaremos com um exemplo.
Abaixo estão alguns documentos que costumam ser criados na empresa Cisco Systems durante o projeto.
CR – Requisitos do Cliente, requisitos do cliente (especificação técnica).
Criado em parceria com o cliente, define os requisitos para a rede.HLD – High Level Design, design de alto nível baseado nos requisitos da rede (CR). O documento explica e justifica as decisões arquitetônicas tomadas (topologia, protocolos, escolha de equipamentos,…). O HLD não contém detalhes sobre o design, como interfaces e endereços IP utilizados. Além disso, não discute configurações específicas de equipamento. Este documento destina-se principalmente a explicar ao gerenciamento técnico do cliente os conceitos-chave do design.
LLD – Low Level Design, design de baixo nível baseado no alto nível (HLD).
Ele deve conter todos os detalhes necessários para a implementação do projeto, como informações sobre como conectar e configurar o equipamento. Este é um guia completo para a implementação do design. Este documento deve fornecer informações suficientes para sua execução, mesmo por pessoal não muito qualificado.Algo, como endereços IP, números AS, esquema de cabeamento (cabling), pode ser "extraído" para documentos separados, como NIP (Plano de Implementação de Rede).
A construção da rede começa após a criação desses documentos e ocorre em estrita conformidade com eles, sendo posteriormente verificada pelo cliente (testes) para garantir a conformidade com o design.
Claro, diferentes integradores, clientes e países podem ter requisitos variados para a documentação do projeto. Mas gostaríamos de evitar formalidades e discutir a questão de forma substancial. Esta etapa não se refere ao design, mas à organização e precisamos de um conjunto adequado de documentos (esquemas, tabelas, descrições ...) para cumprir nossas tarefas.
E, na minha opinião, existe um mínimo absoluto sem o qual não é possível controlar efetivamente a rede.
Estes documentos são os seguintes:
- esquema (registro) de cabeamento (cabling)
- esquema ou esquemas da rede com informações significativas de L2/L3
Diagrama de comutação física
Em algumas pequenas empresas, o trabalho relacionado à instalação de equipamentos e cabeamento (cabling) está sob a responsabilidade dos engenheiros de rede.
Nesse caso, a tarefa é parcialmente resolvida através da abordagem a seguir.
- use a descrição na interface para especificar o que está conectado a ela.
- desative administrativamente (shutdown) todas as portas não conectadas do equipamento de rede
Isso permitirá que você, mesmo em caso de problemas com o link (quando o cdps ou lldp não estão funcionando nessa interface), identifique rapidamente o que está conectado a essa porta.
Além disso, você poderá ver facilmente quais portas estão ocupadas e quais estão livres, o que é necessário para planejar as conexões de novos equipamentos de rede, servidores ou estações de trabalho.
Mas é claro que se você perder o acesso ao equipamento, também perderá o acesso a essas informações. Além disso, dessa forma você não conseguirá registrar informações tão importantes como qual equipamento está, com qual potência consumida, quantas portas possui, em qual rack está, quais patch panels estão lá e para onde (em qual rack/patch panel) estão conectados. Portanto, uma documentação adicional (não apenas descrições no equipamento) é muito útil.
A melhor opção é utilizar aplicativos projetados para trabalhar com esse tipo de informação. Mas pode-se limitar a tabelas simples (por exemplo, no Excel) ou visualizar as informações que você considera necessárias em esquemas L1/L2.
Importante!
Um engenheiro de rede, é claro, pode conhecer bem os detalhes e padrões do cabeamento estruturado, tipos de racks, tipos de fontes de alimentação ininterrupta, o que é um corredor frio e um corredor quente, fazer um aterramento correto, … assim como, em princípio, ele pode conhecer a física de partículas elementares ou C++. Mas é preciso entender que tudo isso não faz parte de seu domínio de conhecimento.
Portanto, é uma boa prática ter ou departamentos dedicados ou pessoas designadas para resolver questões relacionadas à instalação, conexão, manutenção do funcionamento do equipamento, assim como a comutação física. Normalmente, para data centers, isso são engenheiros de data center, e para escritórios — help-desk.
Se esses departamentos estão previstos em sua empresa, então a questão da manutenção de registros de comutação física não é sua responsabilidade, e você pode se limitar apenas à descrição na interface e à desativação administrativa das portas não utilizadas.
Diagramas de rede
Não existe uma abordagem universal para desenhar esquemas.
O mais importante é que os diagramas devem transmitir uma compreensão de como o tráfego fluirá, através de quais elementos lógicos e físicos da sua rede.
Por elementos físicos, entendemos
- equipamentos ativos
- interfaces/portas de equipamentos ativos
Por lógicos —
- dispositivos lógicos (N7K VDC, Palo Alto VSYS, …)
- VRF
- VLANs
- subinterfaces
- túneis
- zonas
- …
Além disso, se a sua rede não for completamente elementar, ela consistirá em diferentes segmentos.
Por exemplo
- data center
- internet
- WAN
- acesso remoto
- LAN de escritório
- DMZ
- …
É razoável ter vários diagramas, proporcionando uma visão geral (como o tráfego flui entre todos esses segmentos), assim como uma explicação detalhada de cada segmento específico.
Como nas redes modernas pode haver muitos níveis lógicos, uma abordagem boa (mas não obrigatória) pode ser fazer diferentes diagramas para diferentes níveis, por exemplo, no caso de uma abordagem de sobreposição, estes poderiam ser os seguintes diagramas:
- overlay
- L1/L2 underlay
- L3 underlay
Claro, o diagrama mais importante, sem o qual não é possível entender a ideia do seu design, é o diagrama de roteamento.
Diagrama de roteamento
No mínimo, neste diagrama deve estar refletido
- quais protocolos de roteamento estão em uso e onde são aplicados
- informações básicas sobre as configurações do protocolo de roteamento (área/número AS/router-id/…)
- em quais dispositivos ocorre a redistribuição
- onde é feita a filtragem e agregação de rotas
- informações sobre a rota padrão
Além disso, muitas vezes um diagrama L2 (OSI) também é útil.
Diagrama L2 (OSI)
Neste diagrama, podem ser refletidas as seguintes informações:
- quais VLANs
- quais portas são portas trunk
- quais portas estão agregadas em ether-channel (port channel), virtual port channel
- quais protocolos STP estão em uso e em quais dispositivos
- configurações principais do STP: root/root backup, custo do STP, prioridade da porta
- configurações adicionais do STP: BPDU guard/filter, root guard…
Erros comuns no design
Exemplo de uma abordagem ruim na construção de uma rede.
Vamos pegar um exemplo simples de construção de uma rede local de escritório simples.
Tendo experiência em ensinar telecomunicações a estudantes, posso dizer que praticamente qualquer aluno, até a metade do segundo semestre, possui o conhecimento necessário (dentro do curso que eu ministrei) para configurar uma LAN de escritório simples.
O que há de complicado em conectar switches entre si, configurar VLANs, interfaces SVI (no caso de switches L3) e definir o roteamento estático?
Tudo funcionará.
Mas ainda ficam de lado questões relacionadas a
- segurança
- redundância
- escalabilidade da rede
- desempenho
- largura de banda
- confiabilidade
- …
Às vezes, ouço a afirmação de que uma LAN de escritório é algo muito simples e geralmente ouço isso de engenheiros (e gerentes) que lidam com tudo, menos com redes, e falam isso com tanta confiança que não se surpreenda se a LAN for feita por pessoas com prática e conhecimentos limitados, resultando em erros semelhantes aos que descreverei um pouco mais adiante.
Erros característicos de design de nível L1 (OSI)
- Se você também é responsável pela cabeação estruturada, um dos legados mais desagradáveis que pode herdar é a comutação descuidada e mal planejada.
Eu também atribuiria ao tipo L1 erros relacionados aos recursos do equipamento utilizado, como por exemplo,
- largura de banda insuficiente
- TCAM insuficiente no equipamento (ou seu uso ineficiente)
- desempenho insuficiente (frequentemente relacionado a firewalls)
Erros característicos de design de nível L2 (OSI)
Frequentemente, quando não há uma boa compreensão de como o STP funciona, quais problemas potenciais ele pode trazer, os switches são conectados de forma caótica, com configurações padrão, sem ajuste adicional do STP.
Como resultado, muitas vezes temos o seguinte:
- um grande diâmetro de STP na rede, o que pode levar a tempestades de broadcast
- a raiz do STP será definida aleatoriamente (com base no endereço MAC) e o caminho do tráfego será subótimo
- portas conectadas a hosts não serão configuradas como edge (portfast), o que fará com que o STP seja recalculado ao ligar/desligar estações finais
- a rede não será segmentada nos níveis L1/L2, resultando em problemas com qualquer switch (por exemplo, sobrecarga de energia) levando ao recalculo da topologia do STP e paralisando o tráfego em todas as VLANs em todos os switches (inclusive em segmentos críticos para continuidade de serviço)
Exemplos de erros no design L3 (OSI)
Alguns erros característicos de iniciantes em redes:
- uso frequente (ou uso somente) de roteamento estático
- uso de protocolos de roteamento que não são ideais para esse design
- segmentação lógica da rede não ideal
- uso inadequado do espaço de endereçamento, o que impede a agregação de rotas
- falta de rotas de backup
- falta de redundância para o gateway padrão
- roteamento assimétrico durante a reestruturação de rotas (pode ser crítico em caso de NAT/PAT, firewalls stateful)
- problemas com MTU
- durante a reestruturação de rotas, o tráfego passa por outras zonas de segurança ou até mesmo por outros firewalls, levando à perda desse tráfego
- pouca escalabilidade da topologia
Critérios para avaliação da qualidade do design
Quando falamos sobre otimização/não otimização, devemos entender sob quais critérios podemos avaliar isso. Na minha opinião, os critérios mais relevantes (mas não todos) são os seguintes (e suas definições aplicadas aos protocolos de roteamento):
- escalabilidade (scalability)
Por exemplo, você decidiu adicionar mais um data center. Quão fácil é fazer isso? - facilidade de gerenciamento (manageability)
Quão fáceis e seguros são as mudanças operacionais, por exemplo, a divulgação de uma nova rede ou filtragem de rotas - disponibilidade (availability)
Qual percentual de tempo seu sistema fornece o nível de serviço exigido - segurança (security)
Quão protegidos estão os dados transmitidos - o preço
Mudanças
O princípio principal nesta fase pode ser expresso pela fórmula "primeiro, não prejudicar".
Portanto, mesmo que você não concorde totalmente com o design e a implementação escolhida (configuração), nem sempre é sensato fazer mudanças. Um enfoque razoável é classificar todos os problemas identificados em dois parâmetros:
- quão fácil é corrigir esse problema
- quão grande é o risco que ele representa
Primeiro, é necessário corrigir o que atualmente reduz o nível de serviço a um nível abaixo do aceitável, como problemas que causam perda de pacotes. Depois, corrija o que é mais fácil e seguro de resolver, em ordem decrescente de gravidade do risco (de problemas de design ou configuração que trazem maiores riscos para menores).
O perfeccionismo nesta fase pode ser prejudicial. Leve o design a um estado satisfatório e sincronize a configuração da rede de acordo com ele.
Fonte: habr.com
