Como assumir o controle de sua infraestrutura de rede. Capítulo dois. Limpeza e Documentação

Este artigo é o segundo de uma série de artigos “Como assumir o controle de sua infraestrutura de rede”. O conteúdo de todos os artigos da série e links podem ser encontrados aqui.

Como assumir o controle de sua infraestrutura de rede. Capítulo dois. Limpeza e Documentação

Nosso objetivo nesta fase é colocar ordem na documentação e configuração.
Ao final deste processo, você deverá ter o conjunto de documentos necessários e uma rede configurada de acordo com os mesmos.

Agora não falaremos sobre auditorias de segurança - este será o assunto da terceira parte.

A dificuldade de completar a tarefa atribuída nesta fase, claro, varia muito de empresa para empresa.

A situação ideal é quando

  • sua rede foi criada de acordo com o projeto e você possui um conjunto completo de documentos
  • foi implementado em sua empresa processo de controle e gerenciamento de mudanças para rede
  • de acordo com este processo, você possui documentos (incluindo todos os diagramas necessários) que fornecem informações completas sobre a situação atual

Neste caso, sua tarefa é bastante simples. Você deve estudar os documentos e revisar todas as alterações que foram feitas.

Na pior das hipóteses, você terá

  • uma rede criada sem projeto, sem plano, sem aprovação, por engenheiros que não possuem um nível de qualificação suficiente,
  • com mudanças caóticas e não documentadas, com muito “lixo” e soluções abaixo do ideal

É claro que a sua situação está algures no meio, mas infelizmente, nesta escala de melhor - pior, há uma grande probabilidade de que você esteja mais perto do pior final.

Neste caso, você também precisará da capacidade de ler mentes, pois terá que aprender a entender o que os “designers” queriam fazer, restaurar sua lógica, terminar o que não foi concluído e retirar o “lixo”.
E, claro, você precisará corrigir seus erros, alterar (nesta fase o mínimo possível) o design e alterar ou recriar os esquemas.

Este artigo não pretende de forma alguma ser completo. Aqui descreverei apenas os princípios gerais e focarei em alguns problemas comuns que precisam ser resolvidos.

Conjunto de documentos

Vamos começar com um exemplo.

Abaixo estão alguns documentos que são normalmente criados na Cisco Systems durante o projeto.

CR – Requisitos do cliente, requisitos do cliente (especificações técnicas).
É criado em conjunto com o cliente e determina os requisitos da rede.

HLD – High Level Design, design de alto nível baseado em requisitos de rede (CR). O documento explica e justifica as decisões arquitetônicas tomadas (topologia, protocolos, seleção de hardware,...). O HLD não contém detalhes de design, como interfaces e endereços IP usados. Além disso, a configuração específica do hardware não é discutida aqui. Em vez disso, este documento pretende explicar os principais conceitos de design ao gerenciamento técnico do cliente.

LLD – Low Level Design, design de baixo nível baseado em design de alto nível (HLD).
Deve conter todos os detalhes necessários à implementação do projeto, como informações sobre como conectar e configurar o equipamento. Este é um guia completo para implementar o design. Este documento deverá fornecer informações suficientes para a sua implementação mesmo por pessoal menos qualificado.

Algo, por exemplo, endereços IP, números AS, esquema de comutação física (cabeamento), pode ser “exposto” em documentos separados, como NIP (Plano de Implementação da Rede).

A construção da rede inicia-se após a elaboração destes documentos e ocorre em estrita conformidade com os mesmos, sendo posteriormente verificada pelo cliente (testes) quanto à conformidade com o projeto.

É claro que diferentes integradores, diferentes clientes e diferentes países podem ter requisitos diferentes para a documentação do projeto. Mas gostaria de evitar formalidades e considerar a questão pelo seu mérito. Esta etapa não se trata de design, mas sim de colocar as coisas em ordem, e precisamos de um conjunto de documentos suficiente (diagramas, tabelas, descrições...) para completar as nossas tarefas.

E na minha opinião existe um certo mínimo absoluto, sem o qual é impossível controlar efetivamente a rede.

Estes são os seguintes documentos:

  • diagrama (log) de comutação física (cabeamento)
  • diagrama de rede ou diagramas com informações essenciais L2/L3

Diagrama de comutação física

Em algumas pequenas empresas, o trabalho relacionado à instalação de equipamentos e comutação física (cabeamento) é de responsabilidade dos engenheiros de rede.

Neste caso, o problema é parcialmente resolvido pela seguinte abordagem.

  • use uma descrição na interface para descrever o que está conectado a ela
  • desligar administrativamente todas as portas de equipamentos de rede não conectados

Isso lhe dará a oportunidade, mesmo em caso de problema com o link (quando cdp ou lldp não funciona nesta interface), de determinar rapidamente o que está conectado a esta porta.
Você também pode ver facilmente quais portas estão ocupadas e quais estão livres, o que é necessário para planejar 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, desta forma você não poderá registrar informações tão importantes como que tipo de equipamento, qual consumo de energia, quantas portas, em que rack está, quais patch Panels estão e onde (em qual rack/patch panel ) eles estão conectados. Portanto, documentação adicional (não apenas descrições do equipamento) ainda é muito útil.

A opção ideal é utilizar aplicativos desenvolvidos para trabalhar com esse tipo de informação. Mas você pode limitar-se a tabelas simples (por exemplo, no Excel) ou exibir as informações que considera necessárias em diagramas L1/L2.

Importante!

Um engenheiro de rede, é claro, pode conhecer muito bem as complexidades e padrões do SCS, tipos de racks, tipos de fontes de alimentação ininterruptas, o que é um corredor frio e quente, como fazer o aterramento adequado... assim como, em princípio, ele pode conhecer a física das partículas elementares ou C++. Mas ainda é preciso entender que tudo isso não é sua área de conhecimento.

Portanto, é uma boa prática ter departamentos ou pessoas dedicadas para resolver problemas relacionados à instalação, conexão, manutenção de equipamentos, bem como comutação física. Normalmente, para data centers, são engenheiros de data center e, para um escritório, é help-desk.

Se tais divisões forem fornecidas em sua empresa, então as questões de registro de comutação física não são sua tarefa, e você pode limitar-se apenas à descrição na interface e ao desligamento administrativo de portas não utilizadas.

Diagramas de rede

Não existe uma abordagem universal para desenhar diagramas.

O mais importante é que os diagramas forneçam 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 queremos dizer

  • equipamento ativo
  • interfaces/portas de equipamentos ativos

Sob lógico -

  • dispositivos lógicos (N7K VDC, Palo Alto VSYS, ...)
  • VRF
  • Vilans
  • subinterfaces
  • túneis
  • zona
  • ...

Além disso, se a sua rede não for totalmente elementar, ela consistirá em diferentes segmentos.
Por exemplo

  • Centro de dados
  • Internet
  • WAN
  • acesso remoto
  • LAN do escritório
  • DMZ
  • ...

É aconselhável ter vários diagramas que forneçam uma visão geral (como o tráfego flui entre todos esses segmentos) e uma explicação detalhada de cada segmento individual.

Como nas redes modernas pode haver muitas camadas lógicas, talvez seja uma boa (mas não necessária) abordagem fazer circuitos diferentes para camadas diferentes, por exemplo, no caso de uma abordagem de sobreposição, poderiam ser os seguintes circuitos:

  • sobreposição
  • Subcamada L1/L2
  • Subcamada L3

Claro, o diagrama mais importante, sem o qual é impossível entender a ideia do seu projeto, é o diagrama de roteamento.

Esquema de roteamento

No mínimo, este diagrama deve refletir

  • quais protocolos de roteamento são usados ​​e onde
  • informações básicas sobre configurações de protocolo de roteamento (área/número AS/router-id/…)
  • em quais dispositivos ocorre a redistribuição?
  • onde ocorre a filtragem e agregação de rotas
  • informações de rota padrão

Além disso, o esquema L2 (OSI) é frequentemente útil.

Esquema L2 (OSI)

Este diagrama pode mostrar as seguintes informações:

  • quais VLANs
  • quais portas são portas de tronco
  • quais portas são agregadas em canal ether (canal de porta), canal de porta virtual
  • quais protocolos STP são usados ​​e em quais dispositivos
  • configurações básicas de STP: backup root/root, custo de STP, prioridade de porta
  • configurações adicionais de STP: proteção/filtro BPDU, proteção root…

Erros típicos de design

Um exemplo de uma abordagem ruim para construir uma rede.

Vejamos um exemplo simples de construção de uma LAN de escritório simples.

Tendo experiência no ensino de telecomunicações para alunos, posso dizer que praticamente qualquer aluno em meados do segundo semestre terá o conhecimento necessário (como parte do curso que ministrei) para montar uma simples LAN de escritório.

O que há de tão difícil em conectar switches entre si, configurar VLANs, interfaces SVI (no caso de switches L3) e configurar roteamento estático?

Tudo vai dar certo.

Mas, ao mesmo tempo, questões relacionadas

  • segurança
  • reserva
  • dimensionamento de rede
  • produtividade
  • Taxa de transferência
  • fiabilidade
  • ...

De vez em quando ouço a afirmação de que uma LAN de escritório é algo muito simples e costumo ouvir isso de engenheiros (e gerentes) que fazem tudo menos redes, e eles dizem isso com tanta confiança que não se surpreenda se a LAN for feito por pessoas com prática e conhecimento insuficientes e será cometido aproximadamente com os mesmos erros que descreverei a seguir.

Erros comuns de design L1 (OSI)

  • Se, no entanto, você também é responsável pelo SCS, então um dos legados mais desagradáveis ​​que você pode receber é a troca descuidada e mal pensada.

Eu também classificaria como tipo L1 os erros relacionados aos recursos dos equipamentos utilizados, por exemplo,

  • largura de banda insuficiente
  • TCAM insuficiente no equipamento (ou uso ineficaz dele)
  • desempenho insuficiente (geralmente relacionado a firewalls)

Erros comuns de design L2 (OSI)

Freqüentemente, quando não há um bom entendimento de como o STP funciona e quais problemas potenciais ele traz consigo, os switches são conectados caoticamente, com configurações padrão, sem ajuste adicional do STP.

Como resultado, muitas vezes temos o seguinte

  • grande diâmetro de rede STP, o que pode levar a tempestades de transmissão
  • A raiz STP será determinada aleatoriamente (com base no endereço MAC) e o caminho do tráfego será abaixo do ideal
  • portas conectadas aos hosts não serão configuradas como edge (portfast), o que levará ao recálculo do STP ao ligar/desligar estações finais
  • a rede não será segmentada no nível L1/L2, como resultado de problemas com qualquer switch (por exemplo, sobrecarga de energia) levarão a um recálculo da topologia STP e à interrupção do tráfego em todas as VLANs em todos os switches (incluindo o um ponto crítico do ponto de vista do segmento de serviços de continuidade)

Exemplos de erros no design L3 (OSI)

Alguns erros típicos de networkers novatos:

  • Uso frequente (ou apenas uso) de roteamento estático
  • uso de protocolos de roteamento abaixo do ideal para um determinado projeto
  • segmentação de rede lógica abaixo do ideal
  • uso abaixo do ideal do espaço de endereço, que não permite agregação de rotas
  • sem rotas de backup
  • nenhuma reserva para gateway padrão
  • roteamento assimétrico ao reconstruir rotas (pode ser crítico no caso de NAT/PAT, firewalls statefull)
  • problemas com MTU
  • quando as rotas são reconstruídas, o tráfego passa por outras zonas de segurança ou até mesmo por outros firewalls, o que faz com que esse tráfego seja descartado
  • escalabilidade de topologia pobre

Critérios para avaliar a qualidade do design

Quando falamos em otimalidade/não otimalidade, devemos entender do ponto de vista de quais critérios podemos avaliar isso. Aqui, do meu ponto de vista, estão os critérios mais significativos (mas não todos) (e explicações em relação aos protocolos de roteamento):

  • escalabilidade
    Por exemplo, você decide adicionar outro data center. Quão fácil você pode fazer isso?
  • facilidade de uso (gerenciamento)
    Quão fáceis e seguras são as mudanças operacionais, como anunciar uma nova rede ou filtrar rotas?
  • disponibilidade
    Qual porcentagem de tempo seu sistema fornece o nível de serviço necessário?
  • segurança
    Quão seguros são os dados transmitidos?
  • preço

Mudanças

O princípio básico nesta fase pode ser expresso pela fórmula “não causar danos”.
Portanto, mesmo que você não concorde totalmente com o design e a implementação (configuração) escolhida, nem sempre é aconselhável fazer alterações. Uma abordagem razoável é classificar todos os problemas identificados de acordo com dois parâmetros:

  • com que facilidade esse problema pode ser resolvido
  • quanto risco ela corre?

Em primeiro lugar, é necessário eliminar o que atualmente reduz o nível de serviço prestado abaixo do nível aceitável, por exemplo, problemas que levam à perda de pacotes. Em seguida, corrija o que for mais fácil e seguro de corrigir em ordem decrescente de gravidade do risco (desde problemas de design ou configuração de alto risco até problemas de baixo risco).

O perfeccionismo nesta fase pode ser prejudicial. Deixe o projeto em um estado satisfatório e sincronize a configuração da rede de acordo.

Fonte: habr.com

Adicionar um comentário