Această articol este al doilea dintr-o serie de articole intitulate „Cum să-ți controlezi infrastructura de rețea”. Conținutul tuturor articolelor din serie și link-urile pot fi găsite .
Obiectivul nostru în această etapă este să facem ordine în documentație și configurație.
La finalul acestui proces, ar trebui să aveți setul necesar de documente și rețeaua configurată conform acestora.
În acest moment nu vom discuta despre auditul de securitate – acest subiect va fi tratat în partea a treia.
Dificultatea executării sarcinii stabilite în această etapă variază semnificativ de la o companie la alta.
Situația ideală este aceea când
- rețeaua dumneavoastră a fost creată conform proiectului și aveți un set complet de documente
- în compania dumneavoastră a fost implementat pentru rețea
- conform acestui proces, dispuneți de documente (inclusiv toate schemele necesare) care oferă informații complete despre starea actuală a lucrurilor
În acest caz, sarcina dumneavoastră este destul de simplă. Trebuie să studiați documentele și să treceți în revistă toate modificările care au fost efectuate.
În cel mai rău caz, veți avea
- o rețea creată fără proiect, fără plan, fără aprobat, de ingineri care nu au un nivel suficient de calificare,
- cu modificări haotice, nedocumentate, cu un număr mare de „gunoi” și soluții suboptimale
Se înțelege că situația dumneavoastră este undeva la mijloc, dar, din păcate, pe această scară, mai bine – mai rău, cu o mare probabilitate, veți fi mai aproape de capătul rău.
În acest caz, va trebui să aveți inclusiv abilitatea de a citi gândurile, pentru că va trebui să învățați să înțelegeți ce au vrut să facă „designerele”, să restaurați logica lor, să finalizați cele nefinalizate și să eliminați „gunoiul”.
Și, desigur, va trebui să limitați erorile lor, să schimbați (în acest stadiu, pe cât posibil minim) designul și să modificați sau să creați din nou schemele.
Această articol nu pretinde în niciun caz a fi exhaustiv. Aici voi descrie doar principiile generale și voi aborda câteva probleme frecvente care trebuie rezolvate.
Set de documente
Să începem cu un exemplu.
Mai jos sunt enumerate câteva documente care sunt de obicei create de compania Cisco Systems în procesul de proiectare.
CR – Cerințele clientului, cerințele clientului (specificație tehnică).
Se creează împreună cu clientul și definește cerințele rețelei.HLD – High Level Design, design de nivel înalt bazat pe cerințele rețelei (CR). Documentul explică și justifică deciziile arhitecturale luate (topologie, protocoale, alegerea echipamentelor,…). HLD nu conține detalii de design, cum ar fi interfețele utilizate și adresele IP. De asemenea, nu este discutată configurația specifică a echipamentelor. Acest document este mai degrabă destinat explicării concepțiilor cheie de design pentru managementul tehnic al clientului.
LLD – Low Level Design, design de nivel scăzut bazat pe cel de nivel înalt (HLD).
Acesta ar trebui să conțină toate detaliile necesare pentru implementarea proiectului, cum ar fi informațiile despre cum să conectați și să configurați echipamentul. Este un ghid complet pentru implementarea designului. Acest document ar trebui să furnizeze suficiente informații pentru implementarea sa chiar și de către personal mai puțin calificat.Câteva aspecte, cum ar fi adresele IP, numerele AS, schema de conectație fizică (cabling), pot fi "extrase" în documente separate, cum ar fi NIP (Network Implementation Plan).
Construirea rețelei începe după crearea acestor documente și se desfășoară în strictă conformitate cu acestea și apoi este verificată de client (teste) pentru conformitate cu designul.
Desigur, la diferiți integratori, la diferiți clienți, în diferite țări cerințele pentru documentația de proiect pot fi diferite. Dar ne-ar plăcea să evităm formalitățile și să abordăm problema substanțial. Această etapă nu este despre proiectare, ci despre ordonarea lucrurilor și avem nevoie de un set suficient de documente (scheme, tabele, descrieri...) pentru a ne îndeplini sarcinile.
Și, în opinia mea, există un minim absolut, fără care nu se poate controla eficient rețeaua.
Acestea sunt următoarele documente:
- schema (jurnal) de conectație fizică (cabling)
- schema sau schemele rețelei cu informații esențiale L2/L3
Schema de interconectare fizică
În unele companii mici, sarcinile legate de instalarea echipamentului și de conectația fizică (cabling) sunt responsabilitatea inginerilor de rețea.
În acest caz, problema este parțial rezolvată prin următoarea abordare.
- utilizați descrierea pe interfață pentru a explica ce este conectat la ea
- de-a administrativ dezactivați (shutdown) toate porturile de rețea neconectate
Aceasta vă va permite, chiar și în cazul unei probleme cu linkul (când cdp sau lldp nu funcționează pe această interfață), să identificați rapid ce este conectat la acest port.
De asemenea, veți putea vedea cu ușurință ce porturi sunt ocupate și care sunt libere, ceea ce este necesar pentru planificarea conexiunilor noului echipament de rețea, servere sau stații de lucru.
Dar este clar că, dacă pierdeți accesul la echipament, veți pierde și accesul la aceste informații. În plus, în acest mod nu veți putea documenta informații importante, cum ar fi ce echipament este, ce putere consumă, câte porturi are, în ce rack se află, ce panouri de patch există și unde (în ce rack/panou de patch) sunt acestea conectate. De aceea, documentarea suplimentară (nu doar descrierile de pe echipamente) este foarte utilă.
Cea mai bună opțiune este utilizarea aplicațiilor create pentru a lucra cu acest tip de informații. Însă se poate limita și la simple tabele (de exemplu, în Excel) sau să afișeze informațiile pe care le considerați necesare în scheme L1/L2.
Important!
Un inginer de rețea, desigur, poate cunoaște destul de bine subtilitățile și standardele SCS, tipurile de rackuri, tipurile de surse de alimentare neîntreruptibilă, ce este un coridor rece și unul cald, să efectueze împământarea corectă,… la fel cum în principiu ar putea ști fizica particulelor elementare sau C++. Dar trebuie să înțelegem că toate acestea nu fac parte din domeniul său de cunoștințe.
De aceea, o practică bună este ca pentru a rezolva problemele legate de instalarea, conectarea, menținerea funcționalității echipamentului, precum și de comutarea fizică, să existe fie departamente dedicate, fie persoane desemnate. De obicei, pentru centrele de date, aceștia sunt inginerii de centre de date, iar pentru birouri — help-desk.
Dacă astfel de departamente sunt prevăzute în compania dumneavoastră, atunci întrebările privind înregistrarea comunicației fizice nu sunt sarcina dumneavoastră, și vă puteți limita doar la descrierea de pe interfață și la dezactivarea administrativă a porturilor neutilizate.
Scheme de rețea
Nu există o abordare universală pentru desenarea schemelor.
Cel mai important — schemele trebuie să ofere înțelegerea modului în care va circula traficul, prin ce elemente logice și fizice ale rețelei dumneavoastră.
Prin elemente fizice ne referim la
- echipamente active
- interfețele / porte ale echipamentului activ
Sub logicele —
- dispozitive logice (N7K VDC, Palo Alto VSYS, …)
- VRF
- VLAN-uri
- subinterfețe
- tuneluri
- zone
- …
De asemenea, dacă rețeaua dumneavoastră nu este chiar foarte simplă, va consta în diferite segmente.
De exemplu
- centru de date
- internet
- WAN
- acces de la distanță
- LAN de birou
- DMZ
- …
Ar fi rezonabil să avem mai multe scheme, care oferă atât o imagine 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 niveluri logice, o abordare bună (dar nu obligatorie) poate fi să se elaboreze scheme diferite pentru diferitele niveluri, de exemplu, în cazul abordării overlay, ar putea fi următoarele scheme:
- overlay
- L1/L2 underlay
- L3 underlay
Desigur, cea mai importantă schemă, fără de care nu se poate înțelege ideea designului dumneavoastră, este schema de rutare.
Schema de rutare
Cel puțin în această schemă ar trebui să fie reflectate
- ce protocoale de rutare și unde sunt utilizate
- informațiile de bază despre configurarea protocoalelor de rutare (area/AS number/router-id/…)
- pe ce echipamente are loc redistribuția
- unde are loc filtrarea și agregarea rutelor
- informația despre ruta default
De asemenea, deseori utilă este schema L2 (OSI).
Schema L2 (OSI)
În această schemă poate fi reflectată următoarea informație:
- ce VLAN-uri
- ce porți sunt porți trunk
- ce porți sunt agregate în ether-channel (port channel), virtual port channel
- ce protocoale STP și pe ce echipamente sunt utilizate
- setările de bază ale STP: root/root backup, cost STP, prioritate port
- setări suplimentare STP: BPDU guard/filter, root guard…
Erori caracteristice în proiectare
Exemplu de abordare slabă în construirea unei rețele.
Să luăm un exemplu simplu de construire a unei rețele locale de birou simple.
Având experiență în predarea telecomunicațiilor studenților, pot spune că practic orice student, până la mijlocul celui de-al doilea semestru, dispune de cunoștințele necesare (în cadrul cursului pe care l-am predat) pentru a configura o LAN de birou simplă.
Ce este complicat în a conecta între ele switch-uri, a configura VLAN-uri, interfețe SVI (în cazul switch-urilor L3) și a introduce rutare statică?
Totul va funcționa.
Dar, în același timp, rămân deoparte întrebările legate de
- securitate.
- reziliență
- scalabilitatea rețelei
- performanță
- lățimea de bandă
- fiabilitate.
- …
Uneori aud afirmația că o rețea LAN de birou este ceva foarte simplu și aud acest lucru de obicei de la ingineri (și manageri) care se ocupă cu orice altceva, dar nu cu rețelele, și o spun cu atât de multă încredere încât nu te mira dacă LAN-ul este realizat de oameni cu practică și cunoștințe insuficiente, fiind realizat aproximativ cu aceleași greșeli pe care le voi descrie mai jos.
Greșeli caracteristice de design la nivelul L1 (OSI)
- Dacă totuși ești responsabil și pentru cablajul structurat, unul dintre cele mai neplăcute moșteniri pe care le poți avea este o configurare neglijentă și gândită.
De asemenea, la tipul L1 aș include greșelile legate de resursele echipamentului utilizat, de exemplu,
- lățimea de bandă insuficientă
- TCAM insuficient pe echipament (sau utilizare ineficientă a acestuia)
- performanță insuficientă (se referă adesea la firewall-uri)
Greșeli caracteristice de design la nivelul L2 (OSI)
Adesea, când nu există o înțelegere bună a modului în care funcționează STP, ce probleme pot apărea, switch-urile sunt conectate haotic, cu setările implicite, fără ajustări suplimentare pentru STP.
Ca rezultat, avem adesea următoarele
- diametru STP mare al rețelei, ceea ce poate conduce la furtuni de broadcast
- root-ul STP va fi determinat aleator (pe baza adresei MAC) și calea traficului va fi suboptimă
- porturile conectate la gazde nu vor fi configurate ca edge (portfast), ceea ce va duce la recalcularea STP la pornirea/oprinerea stațiilor finale
- rețeaua nu va fi segmentată la nivelul L1/L2, ceea ce va face ca problemele cu orice switch (de exemplu, suprasarcină de alimentare) să conducă la recalcularea topologiei STP și la oprirea traficului în toate VLAN-urile de pe toate switch-urile (inclusiv în segmentul critic din perspectiva continuității serviciului)
Exemple de erori în proiectarea L3 (OSI)
Câteva greșeli caracteristice ale rețelisti începători:
- utilizarea frecventă (sau utilizarea exclusivă) a rutării statice
- utilizarea protocoalelor de rutare neoptime pentru acest design
- segmentarea logică neoptimă a rețelei
- utilizarea neoptimă a spațiului de adresare, care nu permite agregarea rutelor
- lipsa rutelor de rezervă
- lipsa rezervării pentru gateway-ul implicit
- routare asimetrică în refacerea rutelor (poate fi critic în cazul NAT/PAT, firewalls stateful)
- probleme cu MTU
- în timpul refacerii rutelor, traficul trece prin alte zone de securitate sau chiar prin alte firewalls, ceea ce duce la pierderea acestui trafic
- scalabilitate slabă a topologiei
Criterii de evaluare a calității designului
Când vorbim despre optimitate/ne-optimalitate, trebuie să înțelegem din perspectiva căror criterii putem evalua acest lucru. Din punctul meu de vedere, cele mai semnificative (dar nu toate) criterii (și explicația în raport cu protocoalele de rutare) sunt:
- scalabilitate (scalability)
De exemplu, ați decis să adăugați un alt centru de date. Cât de ușor puteți face acest lucru. - conveniență în management (manageability)
Cât de ușor și sigur se efectuează modificările operaționale, de exemplu, anunțarea unei noi rețele sau filtrarea rutelor - disponibilitate (availability)
Ce procent din timp sistemul dvs. oferă nivelul de servicii necesar - securitate (security)
Cât de protejate sunt datele transmise - prețul
Modifică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 rațional să faceți modificări. O abordare rezonabilă este clasificarea tuturor problemelor identificate în funcție de doi parametri:
- cât de ușor poate fi rezolvată această problemă
- cât de mare este riscul pe care îl prezintă
În primul rând, trebuie să eliminați ceea ce în prezent reduce nivelul serviciului furnizat sub cel acceptabil, de exemplu, problemele care conduc la pierderi de pachete. Apoi, rezolvați ceea ce este mai ușor și mai sigur de reparat în ordine descrescătoare a gravității riscului (de la problemele de design sau configurație, care prezintă riscuri mari, la cele cu riscuri mai mici).
Perfectionismul în această etapă poate fi dăunător. Aduceți designul la un stadiu satisfăcător și sincronizați configurația rețelei în conformitate cu acesta.
Sursa: habr.com
