Aquest article és el segon d'una sèrie d'articles "Com prendre el control de la vostra infraestructura de xarxa". Es pot trobar el contingut de tots els articles de la sèrie i els enllaços .
El nostre objectiu en aquesta fase és posar ordre a la documentació i configuració.
Al final d'aquest procés, hauríeu de tenir el conjunt de documents necessaris i una xarxa configurada d'acord amb ells.
Ara no parlarem d'auditories de seguretat: aquest serà el tema de la tercera part.
La dificultat per completar la tasca assignada en aquesta etapa, és clar, varia molt d'una empresa a una altra.
La situació ideal és quan
- la vostra xarxa es va crear d'acord amb el projecte i teniu un conjunt complet de documents
- s'ha implementat a la vostra empresa per a la xarxa
- d'acord amb aquest procés, disposeu de documents (inclosos tots els diagrames necessaris) que proporcionen informació completa sobre l'estat actual de les coses.
En aquest cas, la teva tasca és bastant senzilla. Cal estudiar els documents i revisar tots els canvis que s'han fet.
En el pitjor dels casos, ho tindràs
- una xarxa creada sense projecte, sense pla, sense aprovació, per enginyers que no tenen un nivell de qualificació suficient,
- amb canvis caòtics, indocumentats, amb molta “escombraries” i solucions subòptimes
Està clar que la vostra situació es troba entremig, però malauradament, en aquesta escala de millor - pitjor, hi ha una gran probabilitat que estigueu més a prop del pitjor final.
En aquest cas, també necessitareu la capacitat de llegir la ment, perquè haureu d'aprendre a entendre què volien fer els "dissenyadors", restaurar la seva lògica, acabar el que no s'havia acabat i eliminar les "escombraries".
I, per descomptat, haureu de corregir els seus errors, canviar (en aquesta etapa el mínim possible) el disseny i canviar o tornar a crear els esquemes.
Aquest article de cap manera pretén ser complet. Aquí descriuré només els principis generals i em centraré en alguns problemes comuns que s'han de resoldre.
Conjunt de documents
Comencem amb un exemple.
A continuació es mostren alguns documents que es creen habitualment a Cisco Systems durant el disseny.
CR – Requisits del client, requisits del client (especificacions tècniques).
Es crea conjuntament amb el client i determina els requisits de la xarxa.HLD – Disseny d'alt nivell, disseny d'alt nivell basat en requisits de xarxa (CR). El document explica i justifica les decisions arquitectòniques preses (topologia, protocols, selecció de maquinari,...). HLD no conté detalls de disseny, com ara les interfícies i les adreces IP utilitzades. A més, aquí no es parla de la configuració específica del maquinari. Més aviat, aquest document pretén explicar els conceptes clau de disseny a la direcció tècnica del client.
VELL – Disseny de baix nivell, disseny de baix nivell basat en disseny d'alt nivell (HLD).
Ha de contenir tots els detalls necessaris per implementar el projecte, com ara informació sobre com connectar i configurar l'equip. Aquesta és una guia completa per implementar el disseny. Aquest document hauria de proporcionar informació suficient per a la seva implementació fins i tot per part del personal menys qualificat.Alguna cosa, per exemple, les adreces IP, els números AS, l'esquema de commutació física (cablejat), es pot "extreure" en documents separats, com ara PIN (Pla d'implantació de la xarxa).
La construcció de la xarxa comença després de la creació d'aquests documents i es produeix en estricte conformitat amb ells i després el client verifica (proves) el compliment del disseny.
Per descomptat, diferents integradors, diferents clients i diferents països poden tenir diferents requisits per a la documentació del projecte. Però m'agradaria evitar tràmits i considerar la qüestió en els seus mèrits. Aquesta etapa no es tracta de dissenyar, sinó de posar ordre, i necessitem un conjunt de documents suficients (diagrames, taules, descripcions...) per completar les nostres tasques.
I al meu entendre, hi ha un mínim absolut, sense el qual és impossible controlar de manera eficaç la xarxa.
Aquests són els documents següents:
- diagrama (registre) de commutació física (cablejat)
- diagrama de xarxa o diagrames amb informació essencial de L2/L3
Diagrama de commutació física
En algunes empreses petites, els treballs relacionats amb la instal·lació d'equips i la commutació física (cablejat) són responsabilitat dels enginyers de xarxa.
En aquest cas, el problema es resol parcialment amb el següent enfocament.
- utilitzeu una descripció a la interfície per descriure què hi ha connectat
- tancar administrativament tots els ports d'equips de xarxa no connectats
Això us donarà l'oportunitat, fins i tot en cas d'un problema amb l'enllaç (quan cdp o lldp no funcionen en aquesta interfície), de determinar ràpidament què està connectat a aquest port.
També podeu veure fàcilment quins ports estan ocupats i quins són lliures, cosa que és necessària per planificar connexions de nous equips de xarxa, servidors o estacions de treball.
Però és evident que si perds l'accés a l'equip, també perdràs l'accés a aquesta informació. A més, d'aquesta manera no podreu registrar informació tan important com quin tipus d'equip, quin consum d'energia, quants ports, en quin bastidor es troba, quins panells de connexió hi ha i on (en quin bastidor/tauler de connexió ) estan connectats . Per tant, la documentació addicional (no només les descripcions de l'equip) segueix sent molt útil.
L'opció ideal és utilitzar aplicacions dissenyades per treballar amb aquest tipus d'informació. Però podeu limitar-vos a taules senzilles (per exemple, en Excel) o mostrar la informació que considereu necessària en diagrames L1/L2.
¡Important!
Un enginyer de xarxa, per descomptat, pot conèixer força bé les complexitats i els estàndards de SCS, els tipus de bastidors, els tipus de fonts d'alimentació ininterrompuda, què és un passadís fred i calent, com fer una connexió a terra adequada... igual que en principi ho pot fer. Conèixer la física de les partícules elementals o C++. Però encara cal entendre que tot això no és la seva àrea de coneixement.
Per tant, és una bona pràctica disposar de departaments o persones dedicades per resoldre problemes relacionats amb la instal·lació, connexió, manteniment d'equips, així com la commutació física. Normalment, per als centres de dades es tracta d'enginyers de centres de dades, i per a una oficina és servei d'ajuda.
Si aquestes divisions es proporcionen a la vostra empresa, aleshores els problemes de registre de la commutació física no són la vostra tasca i només podeu limitar-vos a la descripció de la interfície i l'aturada administrativa dels ports no utilitzats.
Esquemes de xarxa
No hi ha un enfocament universal per dibuixar diagrames.
El més important és que els diagrames han de proporcionar una comprensió de com fluirà el trànsit, per quins elements lògics i físics de la vostra xarxa.
Per elements físics ens referim
- equip actiu
- interfícies/ports d'equips actius
Sota lògica -
- dispositius lògics (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- subinterfícies
- túnels
- zones
- ...
A més, si la vostra xarxa no és completament elemental, constarà de diferents segments.
Per exemple
- centre de dades
- Internet
- WAN
- accés remot
- LAN d'oficina
- DMZ
- ...
És aconsellable tenir diversos diagrames que proporcionin tant la imatge general (com flueix el trànsit entre tots aquests segments) com una explicació detallada de cada segment individual.
Com que a les xarxes modernes hi pot haver moltes capes lògiques, potser és un bon enfocament (però no necessari) fer diferents circuits per a diferents capes, per exemple, en el cas d'un enfocament de superposició, podrien ser els següents circuits:
- superposició
- Base L1/L2
- L3 subjacent
Per descomptat, el diagrama més important, sense el qual és impossible entendre la idea del vostre disseny, és el diagrama d'encaminament.
Esquema d'encaminament
Com a mínim, aquest diagrama hauria de reflectir
- quins protocols d'encaminament s'utilitzen i on
- informació bàsica sobre la configuració del protocol d'encaminament (àrea/número AS/identificador de l'encaminador/...)
- en quins dispositius es produeix la redistribució?
- on es produeix el filtratge i l'agregació de rutes
- informació de ruta predeterminada
A més, l'esquema L2 (OSI) sovint és útil.
Esquema L2 (OSI)
Aquest diagrama pot mostrar la informació següent:
- quines VLAN
- quins ports són ports troncals
- quins ports s'agreguen en ether-channel (canal de port), canal de port virtual
- quins protocols STP s'utilitzen i en quins dispositius
- Configuració bàsica de STP: còpia de seguretat arrel/arrel, cost STP, prioritat de port
- paràmetres STP addicionals: protecció/filtre BPDU, protecció arrel...
Errors típics de disseny
Un exemple d'un mal enfocament per construir una xarxa.
Prenguem un exemple senzill de construcció d'una LAN d'oficina senzilla.
Tenint experiència ensenyant telecomunicacions a estudiants, puc dir que pràcticament qualsevol estudiant a mitjans del segon semestre té els coneixements necessaris (com a part del curs que vaig impartir) per configurar una LAN d'oficina senzilla.
Què és tan difícil de connectar commutadors entre si, configurar VLAN, interfícies SVI (en el cas dels commutadors L3) i configurar l'encaminament estàtic?
Tot funcionarà.
Però al mateix temps, preguntes relacionades amb
- seguretat
- reserva
- escala de xarxa
- productivitat
- rendiment
- fiabilitat
- ...
De tant en tant escolto l'afirmació que una LAN d'oficina és una cosa molt senzilla i normalment ho escolto d'enginyers (i directius) que fan de tot menys xarxes, i ho diuen amb tanta confiança que no us sorprèn si la LAN serà feta per persones amb pràctica i coneixements insuficients i es farà amb aproximadament els mateixos errors que descriuré a continuació.
Errors de disseny comuns de L1 (OSI).
- Si, tanmateix, també sou responsable de SCS, aleshores un dels llegats més desagradables que podeu rebre és el canvi descuidat i poc pensat.
També classificaria com a tipus L1 errors relacionats amb els recursos de l'equip utilitzat, per exemple,
- ample de banda insuficient
- TCAM insuficient a l'equip (o ús ineficaç d'aquest)
- rendiment insuficient (sovint relacionat amb tallafocs)
Errors de disseny comuns de L2 (OSI).
Sovint, quan no hi ha una bona comprensió de com funciona STP i quins problemes potencials comporta, els interruptors es connecten de manera caòtica, amb la configuració predeterminada, sense ajustar STP addicional.
Com a resultat, sovint tenim el següent
- gran diàmetre de xarxa STP, que pot provocar tempestes de transmissió
- L'arrel STP es determinarà aleatòriament (en funció de l'adreça Mac) i el camí del trànsit serà subòptim
- els ports connectats als amfitrions no es configuraran com a edge (portfast), cosa que provocarà un recàlcul de STP en activar/desactivar les estacions finals
- la xarxa no es segmentarà al nivell L1/L2, de manera que els problemes amb qualsevol commutador (per exemple, la sobrecàrrega d'alimentació) provocaran un recàlcul de la topologia STP i aturaran el trànsit a totes les VLAN de tots els commutadors (incloent-hi el un crític des del punt de vista del segment de servei de continuïtat)
Exemples d'errors en el disseny L3 (OSI).
Alguns errors típics dels usuaris de xarxes novells:
- Ús freqüent (o només ús) d'encaminament estàtic
- ús de protocols d'encaminament subòptims per a un disseny determinat
- segmentació de la xarxa lògica subòptima
- ús subòptim de l'espai d'adreces, que no permet l'agregació de rutes
- no hi ha rutes de seguretat
- no hi ha reserva per a la passarel·la predeterminada
- encaminament asimètric en reconstruir rutes (pot ser crític en el cas de NAT/PAT, tallafocs amb estat)
- problemes amb MTU
- quan es reconstrueixen les rutes, el trànsit passa per altres zones de seguretat o fins i tot per altres tallafocs, la qual cosa fa que aquest trànsit s'elimini.
- poca escalabilitat de la topologia
Criteris per avaluar la qualitat del disseny
Quan parlem d'optimitat/no-optimalitat, hem d'entendre des del punt de vista de quins criteris podem avaluar-ho. Aquests són, des del meu punt de vista, els criteris més significatius (però no tots) (i l'explicació en relació als protocols d'encaminament):
- escalabilitat
Per exemple, decidiu afegir un altre centre de dades. Què tan fàcil pots fer-ho? - facilitat d'ús (manejabilitat)
Què tan fàcils i segurs són els canvis operatius, com ara anunciar una nova graella o filtrar rutes? - disponibilitat
Quin percentatge del temps ofereix el vostre sistema el nivell de servei requerit? - seguretat
Què tan segures són les dades transmeses? - preu
Canvis
El principi bàsic en aquesta etapa es pot expressar amb la fórmula "no fer mal".
Per tant, encara que no estigui completament d'acord amb el disseny i la implementació escollida (configuració), no sempre és aconsellable fer canvis. Un enfocament raonable és classificar tots els problemes identificats segons dos paràmetres:
- amb quina facilitat es pot solucionar aquest problema
- quants riscos corre?
En primer lloc, cal eliminar allò que actualment redueix el nivell de servei prestat per sota del nivell acceptable, per exemple, els problemes que provoquen la pèrdua de paquets. A continuació, arregleu el que és més fàcil i segur de solucionar en ordre decreixent de gravetat del risc (des de problemes de disseny o configuració d'alt risc fins a problemes de baix risc).
El perfeccionisme en aquesta etapa pot ser perjudicial. Porta el disseny a un estat satisfactori i sincronitza la configuració de la xarxa en conseqüència.
Font: www.habr.com