Acest articol este al doilea dintr-o serie de articole „Cum să preia controlul asupra infrastructurii de rețea”. Conținutul tuturor articolelor din serie și link-urile pot fi găsite .
Scopul nostru în această etapă este să punem ordine în documentație și configurare.
La sfârșitul acestui proces, ar trebui să aveți setul necesar de documente și o rețea configurată în conformitate cu acestea.
Acum nu vom vorbi despre audituri de securitate - acesta va fi subiectul celei de-a treia părți.
Dificultatea de a îndeplini sarcinile atribuite în această etapă, desigur, variază foarte mult de la companie la companie.
Situația ideală este când
- rețeaua dumneavoastră a fost creată în conformitate cu proiectul și aveți un set complet de documente
- a fost implementat în compania dumneavoastră pentru retea
- În conformitate cu acest proces, aveți documente (inclusiv toate diagramele necesare) care oferă informații complete despre starea actuală a lucrurilor.
În acest caz, sarcina ta este destul de simplă. Ar trebui să studiați documentele și să revizuiți toate modificările care au fost făcute.
În cel mai rău caz, veți avea
- o rețea creată fără proiect, fără plan, fără aprobare, de ingineri care nu au un nivel suficient de calificare,
- cu schimbări haotice, nedocumentate, cu multă „gunoaie” și soluții suboptime
Este clar că situația ta este undeva la mijloc, dar, din păcate, pe această scară de mai bine - mai rău, există o mare probabilitate să fii mai aproape de cel mai rău capăt.
În acest caz, veți avea nevoie și de capacitatea de a citi mințile, deoarece va trebui să învățați să înțelegeți ce au vrut să facă „designerii”, să le restabiliți logica, să terminați ceea ce nu a fost terminat și să eliminați „gunoaiele”.
Și, desigur, va trebui să le corectați greșelile, să modificați (în această etapă cât mai puțin posibil) proiectarea și să modificați sau să recreați schemele.
Acest articol nu pretinde în niciun caz a fi complet. Aici voi descrie doar principiile generale și mă voi concentra asupra unor probleme comune care trebuie rezolvate.
Set de documente
Să începem cu un exemplu.
Mai jos sunt câteva documente care sunt create în mod obișnuit la Cisco Systems în timpul proiectării.
CR – Cerințe ale clienților, cerințe ale clienților (specificații tehnice).
Este creat în comun cu clientul și determină cerințele rețelei.HLD – High Level Design, proiectare la nivel înalt bazat pe cerințele de rețea (CR). Documentul explică și justifică deciziile arhitecturale luate (topologie, protocoale, selecție hardware,...). HLD nu conține detalii de design, cum ar fi interfețele și adresele IP utilizate. De asemenea, configurația hardware specifică nu este discutată aici. Mai degrabă, acest document are scopul de a explica conceptele cheie de proiectare pentru managementul tehnic al clientului.
LLD – Low Level Design, design de nivel scăzut bazat pe design de nivel înalt (HLD).
Ar trebui să conțină toate detaliile necesare implementării proiectului, cum ar fi informații despre modul de conectare și configurare a echipamentului. Acesta este un ghid complet pentru implementarea designului. Acest document ar trebui să ofere suficiente informații pentru implementarea sa chiar și de către personalul mai puțin calificat.Ceva, de exemplu, adresele IP, numerele AS, schema de comutare fizică (cablare), poate fi „dispus” în documente separate, cum ar fi PNI (Planul de implementare a rețelei).
Construcția rețelei începe după crearea acestor documente și are loc în strictă conformitate cu acestea și este apoi verificată de către client (teste) pentru conformitatea cu proiectul.
Desigur, diferiți integratori, diferiți clienți și diferite țări pot avea cerințe diferite pentru documentația de proiect. Dar aș dori să evit formalitățile și să analizez problema pe fond. Această etapă nu este despre proiectare, ci despre punerea lucrurilor în ordine și avem nevoie de un set suficient de documente (diagrame, tabele, descrieri...) pentru a ne îndeplini sarcinile.
Și în opinia mea, există un anumit minim absolut, fără de care este imposibil să controlezi eficient rețeaua.
Acestea sunt următoarele documente:
- diagrama (log) de comutare fizică (cablare)
- diagramă de rețea sau diagrame cu informații esențiale L2/L3
Diagrama de comutare fizică
În unele companii mici, lucrările legate de instalarea echipamentelor și comutarea fizică (cablare) sunt responsabilitatea inginerilor de rețea.
În acest caz, problema este parțial rezolvată prin următoarea abordare.
- utilizați o descriere pe interfață pentru a descrie ceea ce este conectat la aceasta
- închideți administrativ toate porturile de echipamente de rețea neconectate
Acest lucru vă va oferi posibilitatea, chiar și în cazul unei probleme cu legătura (când cdp sau lldp nu funcționează pe această interfață), să determinați rapid ce este conectat la acest port.
De asemenea, puteți vedea cu ușurință ce porturi sunt ocupate și care sunt libere, ceea ce este necesar pentru planificarea conexiunilor de noi echipamente de rețea, servere sau stații de lucru.
Dar este clar că dacă pierzi accesul la echipament, vei pierde și accesul la aceste informații. În plus, în acest fel nu veți putea înregistra informații atât de importante precum ce fel de echipament, ce consum de energie, câte porturi, în ce rack se află, ce panouri de corecție sunt și unde (în ce rack/panou de corecție ) sunt conectate . Prin urmare, documentația suplimentară (nu doar descrierile echipamentelor) este încă foarte utilă.
Opțiunea ideală este utilizarea aplicațiilor concepute pentru a lucra cu acest tip de informații. Dar vă puteți limita la tabele simple (de exemplu, în Excel) sau puteți afișa informațiile pe care le considerați necesare în diagramele L1/L2.
Important!
Un inginer de rețea, desigur, poate cunoaște destul de bine complexitățile și standardele SCS, tipurile de rafturi, tipurile de surse de alimentare neîntreruptibile, ce este un culoar rece și fierbinte, cum să facă o împământare corectă... la fel cum poate, în principiu, cunoașteți fizica particulelor elementare sau C++. Dar trebuie totuși să înțelegem că toate acestea nu sunt domeniul lui de cunoaștere.
Prin urmare, este o bună practică să aveți fie departamente dedicate, fie oameni dedicați pentru a rezolva problemele legate de instalarea, conectarea, întreținerea echipamentelor, precum și comutarea fizică. De obicei, pentru centrele de date este vorba despre inginerii centrelor de date, iar pentru un birou este un birou de asistență.
Dacă astfel de divizii sunt furnizate în compania dvs., atunci problemele de înregistrare a comutării fizice nu sunt sarcina dvs. și vă puteți limita doar la descrierea interfeței și închiderea administrativă a porturilor neutilizate.
Diagrame de rețea
Nu există o abordare universală pentru desenarea diagramelor.
Cel mai important lucru este că diagramele ar trebui să ofere o înțelegere a modului în care va circula traficul, prin care elemente logice și fizice ale rețelei dvs.
Prin elemente fizice înțelegem
- echipament activ
- interfețe/porturi ale echipamentelor active
Sub logic -
- dispozitive logice (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- subinterfețe
- tuneluri
- zonă
- ...
De asemenea, dacă rețeaua dvs. nu este complet elementară, aceasta va consta din diferite segmente.
De exemplu
- centru de date
- Internet
- WAN
- acces de la distanță
- LAN de birou
- DMZ
- ...
Este înțelept să aveți mai multe diagrame care să ofere atât imaginea de ansamblu (cum circulă traficul între toate aceste segmente), cât și o explicație detaliată a fiecărui segment în parte.
Deoarece în rețelele moderne pot exista multe straturi logice, este probabil o abordare bună (dar nu necesară) să faceți circuite diferite pentru diferite straturi, de exemplu, în cazul unei abordări de suprapunere, acestea ar putea fi următoarele circuite:
- acoperire
- L1/L2 suport
- L3 substrat
Desigur, cea mai importantă diagramă, fără de care este imposibil să înțelegeți ideea designului dvs., este diagrama de rutare.
Schema de rutare
Cel puțin, această diagramă ar trebui să reflecte
- ce protocoale de rutare sunt folosite și unde
- informații de bază despre setările protocolului de rutare (zonă/număr AS/id-router/...)
- pe ce dispozitive are loc redistribuirea?
- unde are loc filtrarea și agregarea rutelor
- informații despre rută implicită
De asemenea, schema L2 (OSI) este adesea utilă.
Schema L2 (OSI)
Această diagramă poate prezenta următoarele informații:
- ce VLAN-uri
- care porturi sunt porturi trunk
- care porturi sunt agregate în ether-channel (canal de port), canal de port virtual
- ce protocoale STP sunt utilizate și pe ce dispozitive
- setări de bază STP: backup rădăcină/rădăcină, cost STP, prioritate port
- setări STP suplimentare: protecție/filtru BPDU, protecție rădăcină...
Greșeli tipice de design
Un exemplu de abordare proastă a construirii unei rețele.
Să luăm un exemplu simplu de construire a unui simplu LAN de birou.
Având experiență în predarea telecomunicațiilor studenților, pot spune că practic orice student până la jumătatea semestrului doi are cunoștințele necesare (ca parte a cursului pe care l-am predat) pentru a configura un simplu LAN de birou.
Ce este atât de dificil în a conecta switch-uri între ele, a configura VLAN-uri, interfețe SVI (în cazul switch-urilor L3) și a configura rutarea statică?
Totul va funcționa.
Dar, în același timp, întrebări legate de
- Securitate
- rezervare
- scalarea rețelei
- productivitate
- debitului
- fiabilitate
- ...
Din când în când aud afirmația că o rețea LAN de birou este ceva foarte simplu și de obicei aud asta de la ingineri (și manageri) care fac totul, în afară de rețele, și spun asta atât de încrezător încât să nu fii surprins dacă LAN-ul va fi făcute de oameni cu practică și cunoștințe insuficiente și vor fi făcute cu aproximativ aceleași greșeli pe care le voi descrie mai jos.
Greșeli comune de proiectare L1 (OSI).
- Dacă, totuși, sunteți și responsabil pentru SCS, atunci una dintre cele mai neplăcute moșteniri pe care le puteți primi este schimbarea neglijentă și greșită.
De asemenea, aș clasifica drept tip L1 erorile legate de resursele echipamentului utilizat, de exemplu,
- lățime de bandă insuficientă
- TCAM insuficient pe echipament (sau utilizarea ineficientă a acestuia)
- performanță insuficientă (deseori legată de firewall-uri)
Greșeli comune de proiectare L2 (OSI).
Adesea, când nu există o înțelegere bună a modului în care funcționează STP și ce probleme potențiale aduce cu el, comutatoarele sunt conectate haotic, cu setări implicite, fără reglaj STP suplimentar.
Drept urmare, avem adesea următoarele
- diametru mare de rețea STP, care poate duce la furtuni difuzate
- Rădăcina STP va fi determinată aleatoriu (pe baza adresei Mac) și calea de trafic va fi suboptimă
- porturile conectate la gazde nu vor fi configurate ca edge (portfast), ceea ce va duce la recalcularea STP la pornirea/oprirea stațiilor finale
- rețeaua nu va fi segmentată la nivelul L1/L2, drept urmare problemele cu orice comutator (de exemplu, suprasarcina de alimentare) vor duce la o recalculare a topologiei STP și la oprirea traficului în toate VLAN-urile de pe toate comutatoarele (inclusiv la unul critic din punct de vedere al segmentului de servicii de continuitate)
Exemple de greșeli în proiectarea L3 (OSI).
Câteva greșeli tipice ale utilizatorilor începători în rețea:
- Utilizarea frecventă (sau utilizarea numai) a rutării statice
- utilizarea protocoalelor de rutare suboptimale pentru un proiect dat
- segmentare logică suboptimă a rețelei
- utilizarea suboptimă a spațiului de adrese, care nu permite agregarea rutelor
- fără rute de rezervă
- nicio rezervare pentru gateway-ul implicit
- rutare asimetrică la reconstruirea rutelor (poate fi critică în cazul NAT/PAT, firewall-uri cu stare)
- probleme cu MTU
- atunci când rutele sunt reconstruite, traficul trece prin alte zone de securitate sau chiar prin alte firewall-uri, ceea ce duce la eliminarea acestui trafic
- scalabilitate slabă a topologiei
Criterii de evaluare a calității designului
Când vorbim de optimitate/non-optimalitate, trebuie să înțelegem din punctul de vedere al criteriilor pe care le putem evalua. Iată, din punctul meu de vedere, cele mai semnificative (dar nu toate) criteriile (și explicația în legătură cu protocoalele de rutare):
- scalabilitate
De exemplu, decideți să adăugați un alt centru de date. Cât de ușor poți să o faci? - ușurință în utilizare (gestionabilitate)
Cât de ușoare și sigure sunt modificările operaționale, cum ar fi anunțarea unei noi rețele sau filtrarea rutelor? - disponibilitate
În ce procent din timp sistemul dumneavoastră oferă nivelul necesar de serviciu? - Securitate
Cât de sigure sunt datele transmise? - preț
schimbări
Principiul de bază în această etapă poate fi exprimat prin formula „nu face rău”.
Prin urmare, chiar dacă nu sunteți complet de acord cu designul și implementarea aleasă (configurarea), nu este întotdeauna recomandabil să faceți modificări. O abordare rezonabilă este de a clasifica toate problemele identificate în funcție de doi parametri:
- cât de ușor poate fi rezolvată această problemă
- cat riscuri suporta?
În primul rând, este necesar să se elimine ceea ce reduce în prezent nivelul de serviciu oferit sub nivelul acceptabil, de exemplu, problemele care duc la pierderea pachetelor. Apoi remediați ceea ce este cel mai ușor și mai sigur de remediat în ordinea descrescătoare a severității riscului (de la probleme de proiectare sau configurație cu risc ridicat la cele cu risc scăzut).
Perfecționismul în această etapă poate fi dăunător. Aduceți designul într-o stare satisfăcătoare și sincronizați configurația rețelei în consecință.
Sursa: www.habr.com