Kako preuzeti kontrolu nad vašom mrežnom infrastrukturom. Poglavlje drugo. Čišćenje i dokumentacija

Ovaj članak je drugi u nizu članaka “Kako preuzeti kontrolu nad svojom mrežnom infrastrukturom”. Sadržaj svih članaka u seriji i linkove možete pronaći ovdje.

Naš cilj u ovoj fazi je da uvedemo red u dokumentaciju i konfiguraciju.
Na kraju ovog procesa trebali biste imati potreban skup dokumenata i mrežu konfiguriranu u skladu s njima.

Sada nećemo govoriti o sigurnosnim revizijama - to će biti tema trećeg dijela.

Naravno, teškoća izvršavanja zadatka koji je dodijeljen u ovoj fazi, naravno, uvelike varira od kompanije do kompanije.

Idealna situacija je kada

• Vaša mreža je kreirana u skladu sa projektom i imate kompletan set dokumenata
• je implementiran u vašoj kompaniji proces kontrole i upravljanja promjenama za mrežu
• u skladu sa ovim procesom, imate dokumente (uključujući sve potrebne dijagrame) koji pružaju potpune informacije o trenutnom stanju stvari

U ovom slučaju, vaš zadatak je prilično jednostavan. Trebali biste proučiti dokumente i pregledati sve promjene koje su napravljene.

U najgorem slučaju, imat ćete

• mreža stvorena bez projekta, bez plana, bez odobrenja, od strane inženjera koji nemaju dovoljan nivo kvalifikacija,
• sa haotičnim, nedokumentiranim promjenama, sa puno "smeća" i neoptimalnih rješenja

Jasno je da je vaša situacija negdje između, ali nažalost, na ovoj ljestvici bolje - gore, velika je vjerovatnoća da ćete biti bliže najgorem kraju.

U ovom slučaju će vam trebati i sposobnost čitanja misli, jer ćete morati naučiti da shvatite šta su „dizajneri“ hteli da urade, da im vratite logiku, dovršite ono što nije završeno i uklonite „đubre“.
I, naravno, morat ćete ispraviti njihove greške, promijeniti (u ovoj fazi što je minimalno moguće) dizajn i promijeniti ili ponovo kreirati sheme.

Ovaj članak ni na koji način ne tvrdi da je potpun. Ovdje ću opisati samo opća načela i fokusirati se na neke uobičajene probleme koje je potrebno riješiti.

Set dokumenata

Počnimo s primjerom.

Ispod su neki dokumenti koji se obično kreiraju u Cisco Systems tokom dizajna.

CR – Zahtjevi kupaca, zahtjevi klijenata (tehničke specifikacije).
Kreira se zajedno sa kupcem i određuje zahtjeve mreže.

HLD – Dizajn visokog nivoa, dizajn visokog nivoa zasnovan na zahtevima mreže (CR). Dokument objašnjava i opravdava donesene arhitektonske odluke (topologija, protokoli, izbor hardvera,...). HLD ne sadrži detalje dizajna, kao što su interfejsi i IP adrese koje se koriste. Također, ovdje se ne raspravlja o specifičnoj hardverskoj konfiguraciji. Umjesto toga, ovaj dokument ima za cilj da objasni ključne koncepte dizajna tehničkom menadžmentu korisnika.

LLD – Low Level Design, dizajn niskog nivoa zasnovan na dizajnu visokog nivoa (HLD).
Trebao bi sadržavati sve detalje potrebne za implementaciju projekta, kao što su informacije o tome kako povezati i konfigurirati opremu. Ovo je potpuni vodič za implementaciju dizajna. Ovaj dokument treba da pruži dovoljno informacija za njegovu implementaciju čak i od strane manje kvalifikovanog osoblja.

Nešto, na primjer, IP adrese, AS brojevi, fizička komutirajuća shema (kabliranje), može se "iznijeti" u zasebne dokumente, kao npr. NIP (Plan implementacije mreže).

Izgradnja mreže počinje nakon izrade ovih dokumenata i odvija se u strogom skladu s njima, a zatim se provjerava od strane kupca (testovima) na usklađenost sa projektom.

Naravno, različiti integratori, različiti klijenti i različite zemlje mogu imati različite zahtjeve za projektnu dokumentaciju. Ali želio bih izbjeći formalnosti i razmotriti to pitanje u meritumu. U ovoj fazi se ne radi o dizajnu, već o dovođenju stvari u red, a potreban nam je dovoljan set dokumenata (dijagrami, tabele, opisi...) da završimo svoje zadatke.

I po mom mišljenju, postoji određeni apsolutni minimum, bez kojeg je nemoguće efikasno kontrolisati mrežu.

Ovo su sljedeći dokumenti:

• dijagram (log) fizičkog prebacivanja (kabliranje)
• mrežni dijagram ili dijagrami sa bitnim L2/L3 informacijama

Dijagram fizičke komutacije

U nekim malim kompanijama, posao vezan za instalaciju opreme i fizičko prebacivanje (kabliranje) je odgovornost mrežnih inženjera.

U ovom slučaju problem se dijelom rješava sljedećim pristupom.

• koristite opis na interfejsu da opišete šta je povezano sa njim
• administrativno isključiti sve nepovezane portove mrežne opreme

Ovo će vam dati priliku, čak i u slučaju problema sa vezom (kada cdp ili lldp ne radi na ovom interfejsu), da brzo odredite šta je povezano sa ovim portom.
Također možete lako vidjeti koji su portovi zauzeti, a koji slobodni, što je neophodno za planiranje povezivanja nove mrežne opreme, servera ili radnih stanica.

Ali jasno je da ako izgubite pristup opremi, izgubit ćete i pristup ovim informacijama. Osim toga, na ovaj način nećete moći snimiti tako važne informacije kao što su kakva oprema, koja potrošnja energije, koliko portova, u kojem se rek-u nalazi, koji se patch paneli nalaze i gdje (u kojem rack-u/patch panelu ) oni su povezani. Stoga je dodatna dokumentacija (ne samo opis opreme) i dalje vrlo korisna.

Idealna opcija je korištenje aplikacija dizajniranih za rad s ovom vrstom informacija. Ali možete se ograničiti na jednostavne tabele (na primjer, u Excelu) ili prikazati informacije koje smatrate potrebnima u L1/L2 dijagramima.

Važno!

Mrežni inženjer, naravno, može prilično dobro da zna zamršenosti i standarde SCS-a, vrste rekova, vrste neprekidnog napajanja, šta je to hladan i topao prolaz, kako pravilno uzemljiti... baš kao što, u principu, zna fiziku elementarnih čestica ili C++. Ali ipak treba shvatiti da sve to nije njegova oblast znanja.

Stoga je dobra praksa imati ili namenska odeljenja ili posvećene ljude za rešavanje problema vezanih za instalaciju, povezivanje, održavanje opreme, kao i fizičko prebacivanje. Obično za data centre to su inženjeri data centra, a za kancelariju je help-desk.

Ako su takve podjele predviđene u vašoj kompaniji, onda pitanja evidentiranja fizičkog prebacivanja nisu vaš zadatak, a možete se ograničiti samo na opis interfejsa i administrativno gašenje neiskorištenih portova.

Mrežni dijagrami

Ne postoji univerzalni pristup crtanju dijagrama.

Najvažnije je da dijagrami treba da daju razumijevanje o tome kako će promet teći, kroz koje logičke i fizičke elemente vaše mreže.

Pod fizičkim elementima mislimo

• aktivna oprema
• interfejsi/priključci aktivne opreme

Pod logičnim -

• logički uređaji (N7K VDC, Palo Alto VSYS, ...)
• VRF
• Vilans
• podinterfejsi
• tuneli
• zone
• ...

Također, ako vaša mreža nije potpuno elementarna, sastojat će se od različitih segmenata.
Na primjer

• data centar
• internet
• WAN
• daljinski pristup
• office LAN
• DMZ
• ...

Pametno je imati nekoliko dijagrama koji daju i širu sliku (kako promet teče između svih ovih segmenata) i detaljno objašnjenje svakog pojedinačnog segmenta.

Budući da u modernim mrežama može postojati mnogo logičkih slojeva, možda je dobar (ali ne i neophodan) pristup napraviti različita kola za različite slojeve, na primjer, u slučaju preklapajućeg pristupa to bi mogli biti sljedeći sklopovi:

• overlay
• L1/L2 podloga
• L3 podloga

Naravno, najvažniji dijagram, bez kojeg je nemoguće razumjeti ideju vašeg dizajna, je dijagram rutiranja.

Shema rutiranja

U najmanju ruku, ovaj dijagram bi trebao odražavati

• koji se protokoli rutiranja koriste i gdje
• osnovne informacije o postavkama protokola usmjeravanja (područje/AS broj/id-ruter/…)
• na kojim uređajima dolazi do preraspodjele?
• gdje dolazi do filtriranja i agregacije ruta
• zadane informacije o ruti

Također, L2 shema (OSI) je često korisna.

L2 shema (OSI)

Ovaj dijagram može prikazati sljedeće informacije:

• kakvi VLAN-ovi
• koji su portovi trunk portovi
• koji portovi su agregirani u eter-kanal (port kanal), virtuelni port kanal
• koji se STP protokoli koriste i na kojim uređajima
• osnovne STP postavke: root/root sigurnosna kopija, STP cijena, prioritet porta
• dodatne STP postavke: BPDU guard/filter, root guard…

Tipične greške u dizajnu

Primjer lošeg pristupa izgradnji mreže.

Uzmimo jednostavan primjer izgradnje jednostavnog uredskog LAN-a.

Imajući iskustvo u predavanju studenata telekomunikacijama, mogu reći da praktično svaki student do sredine drugog semestra ima potrebno znanje (u okviru predmeta koji sam ja predavao) za postavljanje jednostavnog uredskog LAN-a.

Šta je toliko teško u međusobnom povezivanju prekidača, postavljanju VLAN-a, SVI interfejsa (u slučaju L3 svičeva) i postavljanju statičkog rutiranja?

Sve će raditi.

Ali u isto vrijeme, pitanja vezana za

• sigurnost
• rezervacija
• mrežno skaliranje
• performanse
• propusnost
• pouzdanost
• ...

S vremena na vrijeme čujem izjavu da je uredski LAN nešto vrlo jednostavno i to obično čujem od inženjera (i menadžera) koji rade sve osim mreža, a oni to govore tako samouvjereno da se nemojte iznenaditi ako će LAN biti napravljen od strane ljudi sa nedovoljno prakse i znanja i biće napravljen sa približno istim greškama koje ću opisati u nastavku.

Uobičajene greške u dizajnu L1 (OSI).

• Ako ste ipak odgovorni i za SCS, onda je jedno od najneugodnijih nasljeđa koje možete dobiti je nemarno i nepromišljeno prebacivanje.

Takođe bih klasifikovao kao greške tipa L1 koje se odnose na resurse korišćene opreme, na primer,

• nedovoljna propusnost
• nedovoljan TCAM na opremi (ili neefikasna upotreba iste)
• nedovoljne performanse (često povezane sa zaštitnim zidovima)

Uobičajene greške u dizajnu L2 (OSI).

Često, kada nema dobrog razumevanja kako STP funkcioniše i koje potencijalne probleme sa sobom nosi, prekidači se povezuju haotično, sa podrazumevanim postavkama, bez dodatnog podešavanja STP-a.

Kao rezultat toga, često imamo sljedeće

• veliki prečnik STP mreže, što može dovesti do oluja
• STP root će biti određen nasumično (na osnovu mac adrese) i put prometa će biti podoptimalan
• portovi povezani na hostove neće biti konfigurirani kao edge (portfast), što će dovesti do STP ponovnog izračunavanja prilikom uključivanja/isključivanja krajnjih stanica
• mreža neće biti segmentirana na nivou L1/L2, zbog čega će problemi sa bilo kojim prekidačem (na primjer, preopterećenje napajanja) dovesti do ponovnog izračunavanja STP topologije i zaustavljanja prometa u svim VLAN-ovima na svim switchevima (uključujući jedan kritičan sa stanovišta segmenta usluge kontinuiteta)

Primjeri grešaka u L3 (OSI) dizajnu

Nekoliko tipičnih grešaka početnika u mreži:

• Česta upotreba (ili samo upotreba) statičkog usmjeravanja
• korištenje suboptimalnih protokola rutiranja za dati dizajn
• suboptimalna logička segmentacija mreže
• neoptimalna upotreba adresnog prostora, koja ne dozvoljava agregaciju ruta
• nema rezervnih ruta
• nema rezervacije za default gateway
• asimetrično rutiranje pri ponovnoj izgradnji ruta (može biti kritično u slučaju NAT/PAT, zaštitnih zidova sa punim stanjem)
• problemi sa MTU
• kada se rute ponovo izgrade, saobraćaj ide kroz druge sigurnosne zone ili čak druge zaštitne zidove, što dovodi do prekida ovog prometa
• loša skalabilnost topologije

Kriterijumi za ocjenu kvaliteta dizajna

Kada govorimo o optimalnosti/neoptimalnosti, moramo razumjeti sa gledišta po kojim kriterijima to možemo ocijeniti. Evo, sa moje tačke gledišta, najznačajnijih (ali ne svih) kriterijuma (i objašnjenja u vezi sa protokolima rutiranja):

• skalabilnost
  Na primjer, odlučite dodati još jedan podatkovni centar. Koliko lako možete to učiniti?
• jednostavnost upotrebe (upravljivost)
  Koliko su jednostavne i sigurne operativne promjene, kao što je najava nove mreže ili filtriranje ruta?
• dostupnost
  U kom postotku vremena vaš sistem pruža potreban nivo usluge?
• sigurnost
  Koliko su sigurni preneseni podaci?
• cijena

Promjene

Osnovni princip u ovoj fazi može se izraziti formulom „ne naškoditi“.
Stoga, čak i ako se ne slažete u potpunosti s dizajnom i odabranom implementacijom (konfiguracijom), nije uvijek preporučljivo praviti promjene. Razuman pristup je rangiranje svih identifikovanih problema prema dva parametra:

• koliko se lako može riješiti ovaj problem
• koliki rizik ona snosi?

Prije svega, potrebno je eliminisati ono što trenutno smanjuje nivo pružene usluge ispod prihvatljivog nivoa, na primjer, probleme koji dovode do gubitka paketa. Zatim popravite ono što je najlakše i najsigurnije popraviti u opadajućem redoslijedu ozbiljnosti rizika (od problema s dizajnom ili konfiguracijom visokog rizika do problema s niskim rizikom).

Perfekcionizam u ovoj fazi može biti štetan. Dovedite dizajn u zadovoljavajuće stanje i u skladu s tim sinhronizirajte mrežnu konfiguraciju.

izvor: www.habr.com