Este artigo é o segundo dunha serie de artigos "Como tomar o control da túa infraestrutura de rede". Pódense atopar os contidos de todos os artigos da serie e as ligazóns .
O noso obxectivo nesta fase é poñer orde na documentación e configuración.
Ao final deste proceso, debería ter o conxunto necesario de documentos e unha rede configurada de acordo con eles.
Agora non falaremos de auditorías de seguridade: este será o tema da terceira parte.
A dificultade para completar a tarefa asignada nesta fase, por suposto, varía moito dunha empresa a outra.
A situación ideal é cando
- a túa rede creouse de acordo co proxecto e tes un conxunto completo de documentos
- implementouse na súa empresa para a rede
- de acordo con este proceso, dispón de documentos (incluíndo todos os diagramas necesarios) que proporcionan información completa sobre o estado actual de cousas.
Neste caso, a súa tarefa é bastante sinxela. Debes estudar os documentos e revisar todos os cambios que se fixeron.
No peor dos casos, terás
- unha rede creada sen proxecto, sen plan, sen aprobación, por enxeñeiros que non teñan un nivel de cualificación suficiente,
- con cambios caóticos e indocumentados, con moito "lixo" e solucións subóptimas
Está claro que a súa situación está nalgún lugar intermedio, pero, por desgraza, nesta escala de mellor - peor, hai unha alta probabilidade de que estea máis preto do peor final.
Neste caso, tamén necesitarás a capacidade de ler as mentes, porque terás que aprender a comprender o que querían facer os "deseñadores", restaurar a súa lóxica, rematar o que non estaba rematado e eliminar o "lixo".
E, por suposto, terás que corrixir os seus erros, cambiar (nesta fase o máis mínimo posible) o deseño e cambiar ou recrear os esquemas.
Este artigo de ningún xeito pretende estar completo. Aquí describirei só os principios xerais e centrarei algúns problemas comúns que se deben resolver.
Conxunto de documentos
Comecemos cun exemplo.
A continuación móstranse algúns documentos que se crean habitualmente en Cisco Systems durante o deseño.
CR – Requisitos do cliente, requisitos do cliente (especificacións técnicas).
Créase conxuntamente co cliente e determina os requisitos da rede.HLD – Deseño de alto nivel, deseño de alto nivel baseado nos requisitos de rede (CR). O documento explica e xustifica as decisións arquitectónicas tomadas (topoloxía, protocolos, selección de hardware,...). HLD non contén detalles de deseño, como as interfaces e os enderezos IP utilizados. Ademais, a configuración específica do hardware non se discute aquí. Pola contra, este documento pretende explicar os conceptos clave de deseño á xestión técnica do cliente.
VELLO – Low Level Design, deseño de baixo nivel baseado no deseño de alto nivel (HLD).
Debe conter todos os detalles necesarios para implementar o proxecto, como información sobre como conectar e configurar o equipo. Esta é unha guía completa para implementar o deseño. Este documento debe proporcionar información suficiente para a súa implementación, incluso por persoal menos cualificado.Algo, por exemplo, enderezos IP, números de AS, esquema de conmutación física (cablación), pode ser "expresado" en documentos separados, como NIP (Plan de Implantación da Rede).
A construción da rede comeza despois da creación destes documentos e prodúcese en estrita conformidade con eles e despois é verificada polo cliente (probas) para o cumprimento do deseño.
Por suposto, diferentes integradores, diferentes clientes e diferentes países poden ter diferentes requisitos para a documentación do proxecto. Pero gustaríame evitar trámites e considerar a cuestión segundo os seus méritos. Esta etapa non é de deseño, senón de poñer en orde, e precisamos dun conxunto de documentos suficientes (diagramas, táboas, descricións...) para completar as nosas tarefas.
E na miña opinión, hai un certo mínimo absoluto, sen o cal é imposible controlar eficazmente a rede.
Estes son os seguintes documentos:
- diagrama (log) de conmutación física (cableado)
- diagrama de rede ou diagramas con información esencial L2/L3
Diagrama de conmutación física
Nalgunhas pequenas empresas, o traballo relacionado coa instalación de equipos e a conmutación física (cablación) é responsabilidade dos enxeñeiros de rede.
Neste caso, o problema resólvese en parte co seguinte enfoque.
- use unha descrición na interface para describir o que está conectado a ela
- pechar administrativamente todos os portos de equipos de rede sen conexión
Isto darache a oportunidade, mesmo no caso de producirse un problema coa ligazón (cando cdp ou lldp non funciona nesta interface), para determinar rapidamente o que está conectado a este porto.
Tamén podes ver facilmente que portos están ocupados e cales son libres, o que é necesario para planificar conexións de novos equipos de rede, servidores ou estacións de traballo.
Pero está claro que se perde o acceso ao equipo, tamén perderá o acceso a esta información. Ademais, deste xeito non poderá rexistrar información tan importante como que tipo de equipo, que consumo de enerxía, cantos portos, en que rack se atopa, que paneis de conexión hai e onde (en que rack/panel de conexión). ) están conectados . Polo tanto, a documentación adicional (non só as descricións do equipo) segue sendo moi útil.
A opción ideal é utilizar aplicacións deseñadas para traballar con este tipo de información. Pero pode limitarse a táboas sinxelas (por exemplo, en Excel) ou mostrar a información que considere necesaria en diagramas L1/L2.
Importante!
Un enxeñeiro de rede, por suposto, pode coñecer bastante ben as complejidades e os estándares do SCS, os tipos de bastidores, os tipos de fontes de alimentación ininterrompidas, o que é un corredor frío e quente, como facer unha conexión a terra adecuada... como en principio pode facer. Coñecer a física das partículas elementais ou C++. Pero aínda hai que entender que todo isto non é a súa área de coñecemento.
Polo tanto, é unha boa práctica contar con departamentos ou persoas dedicadas para resolver problemas relacionados coa instalación, conexión, mantemento de equipos, así como conmutación física. Normalmente para os centros de datos trátase de enxeñeiros de centros de datos, e para unha oficina é a mesa de axuda.
Se tales divisións se proporcionan na súa empresa, entón os problemas de rexistro de conmutación física non son a súa tarefa e só pode limitarse á descrición da interface e ao peche administrativo dos portos non utilizados.
Diagramas de rede
Non existe un enfoque universal para debuxar diagramas.
O máis importante é que os diagramas deben proporcionar unha comprensión de como vai fluír o tráfico, a través de cales elementos lóxicos e físicos da súa rede.
Por elementos físicos entendemos
- equipos activos
- interfaces/portos dos equipos activos
Baixo lóxico -
- dispositivos lóxicos (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- subinterfaces
- túneles
- zonas
- ...
Ademais, se a súa rede non é completamente elemental, constará de diferentes segmentos.
Por exemplo
- centro de datos
- Internet
- WAN
- acceso remoto
- LAN de oficina
- DMZ
- ...
É conveniente ter varios diagramas que dean a imaxe xeral (como circula o tráfico entre todos estes segmentos) e unha explicación detallada de cada segmento individual.
Dado que nas redes modernas pode haber moitas capas lóxicas, quizais sexa un bo (pero non necesario) facer circuítos diferentes para diferentes capas, por exemplo, no caso dun enfoque de superposición, estes poderían ser os seguintes circuítos:
- superposición
- Base L1/L2
- Base L3
Por suposto, o diagrama máis importante, sen o cal é imposible entender a idea do seu deseño, é o diagrama de enrutamento.
Esquema de ruta
Como mínimo, este diagrama debería reflectir
- que protocolos de enrutamento se utilizan e onde
- información básica sobre a configuración do protocolo de enrutamento (área/número AS/router-id/...)
- en que dispositivos se produce a redistribución?
- onde se produce o filtrado e a agregación de rutas
- información de ruta predeterminada
Ademais, o esquema L2 (OSI) adoita ser útil.
esquema L2 (OSI)
Este diagrama pode mostrar a seguinte información:
- que VLAN
- que portos son portos troncais
- que portos se agregan en ether-channel (canle de porto), canle de porto virtual
- que protocolos STP se utilizan e en que dispositivos
- configuración básica de STP: copia de seguridade de root/root, custo STP, prioridade de porto
- configuración STP adicional: protección/filtro BPDU, protección raíz...
Erros típicos de deseño
Un exemplo de mal enfoque para construír unha rede.
Poñamos un exemplo sinxelo de construción dunha LAN de oficina sinxela.
Tendo experiencia na ensinanza de telecomunicacións a estudantes, podo dicir que practicamente calquera estudante a mediados do segundo cuadrimestre ten os coñecementos necesarios (como parte do curso que impartei) para configurar unha sinxela LAN de oficina.
Que é tan difícil de conectar conmutadores entre si, configurar VLAN, interfaces SVI (no caso dos conmutadores L3) e configurar o enrutamento estático?
Todo funcionará.
Pero ao mesmo tempo, preguntas relacionadas co
- seguridade
- reserva
- escalado da rede
- produtividade
- rendemento
- fiabilidade
- ...
De cando en vez escoito a afirmación de que unha LAN de oficina é algo moi sinxelo e adoito escoito isto de enxeñeiros (e xestores) que fan de todo menos de redes, e din isto con tanta confianza que non se sorprenderá se a LAN será feita por persoas con práctica e coñecementos insuficientes e realizarase aproximadamente cos mesmos erros que describirei a continuación.
Erros comúns de deseño de L1 (OSI).
- Se, con todo, tamén es responsable de SCS, entón un dos legados máis desagradables que pode recibir é o cambio descoidado e mal pensado.
Tamén clasificaría como tipo L1 os erros relacionados cos recursos do equipo utilizado, por exemplo,
- ancho de banda insuficiente
- TCAM insuficiente no equipo (ou uso ineficaz do mesmo)
- rendemento insuficiente (a miúdo relacionado con cortalumes)
Erros comúns de deseño de L2 (OSI).
Moitas veces, cando non hai unha boa comprensión de como funciona STP e que problemas potenciais trae consigo, os interruptores están conectados de forma caótica, con configuracións predeterminadas, sen axustes STP adicional.
Como resultado, moitas veces temos o seguinte
- gran diámetro de rede STP, o que pode provocar tormentas de transmisión
- A raíz STP determinarase de forma aleatoria (en función do enderezo Mac) e a ruta do tráfico será subóptima
- os portos conectados aos anfitrións non se configurarán como edge (portfast), o que provocará un recálculo de STP ao activar/desactivar as estacións finais
- a rede non se segmentará no nivel L1/L2, polo que os problemas con calquera conmutador (por exemplo, a sobrecarga de enerxía) levarán a un recálculo da topoloxía STP e a detención do tráfico en todas as VLAN en todos os conmutadores (incluído o unha crítica desde o punto de vista do segmento do servizo de continuidade)
Exemplos de erros no deseño L3 (OSI).
Algúns erros típicos dos principiantes en rede:
- Uso frecuente (ou só uso) de enrutamento estático
- uso de protocolos de enrutamento subóptimos para un determinado deseño
- segmentación de rede lóxica subóptima
- uso subóptimo do espazo de enderezos, que non permite a agregación de rutas
- sen rutas de copia de seguridade
- sen reserva para a pasarela predeterminada
- enrutamento asimétrico ao reconstruír rutas (pode ser crítico no caso de NAT/PAT, firewalls con estado)
- problemas con MTU
- cando se reconstrúen as rutas, o tráfico pasa por outras zonas de seguridade ou mesmo por outros cortalumes, o que fai que este tráfico se abandone
- escasa escalabilidade da topoloxía
Criterios de avaliación da calidade do deseño
Cando falamos de optimidade/non-optimidade, debemos entender desde o punto de vista de que criterios podemos avaliar isto. Aquí, dende o meu punto de vista, están os criterios (e a explicación en relación aos protocolos de enrutamento) máis significativos (pero non todos):
- escalabilidade
Por exemplo, decides engadir outro centro de datos. Que fácil podes facelo? - facilidade de uso (manexabilidade)
Que tan sinxelos e seguros son os cambios operativos, como anunciar unha nova grella ou filtrar rutas? - dispoñibilidade
Que porcentaxe do tempo proporciona o seu sistema o nivel de servizo necesario? - seguridade
Que tan seguros son os datos transmitidos? - prezo
Cambios
O principio básico nesta fase pódese expresar coa fórmula "non facer dano".
Polo tanto, aínda que non estea totalmente de acordo co deseño e a implementación escollida (configuración), non sempre é recomendable facer cambios. Un enfoque razoable é clasificar todos os problemas identificados segundo dous parámetros:
- con que facilidade se pode solucionar este problema
- canto risco corre ela?
En primeiro lugar, é necesario eliminar o que actualmente reduce o nivel de servizo prestado por debaixo do nivel aceptable, por exemplo, os problemas que provocan a perda de paquetes. A continuación, corrixa o que é máis fácil e seguro de arranxar por orde decrecente de gravidade do risco (desde problemas de deseño ou configuración de alto risco ata problemas de baixo risco).
O perfeccionismo nesta fase pode ser prexudicial. Levar o deseño a un estado satisfactorio e sincronizar a configuración da rede en consecuencia.
Fonte: www.habr.com