«Arhitecturi moderne de retea»

Partea a 4-a

     Avem o retea si mai multe solutii de implementare. Am sustinut in fata management board-ului ca a sosit timpul sa facem pasul inainte si sa o modernizam. Ieri ati fost chemat si vi s-a spus:

“- Am inteles ca avem o retea functionala, dar pe viitor nu ne mai putem permite sa avem intreruperi asa cum ni s-a intimplat luna trecuta. Am obtinut acordul de principiu, in citeva luni vom avea si  banii necesari pentru retea si pt. servere. Cind o avem gata?”

- De care din cele 3 variante vorbim? De cea mai buna, de cea optimizata sau de cea mai ieftina?

- De cea pe care tu o vrei. Tu esti IT manager.

- Perfect. In 2 saptamini aveti raspunsul.

- OK. Dar tine minte: Anul acesta rezolvam reteaua si la anul sper sa putem face si upgrade-ul la servere, depinde de citi bani ramin de la retea. Vorbeste cu Ionescu de la servere, explica-i ca reteaua are prioritate. Si sa nu mai aud vreodata ca dati vina unul pe celalalt ca luna trecuta.”

     Cum veti negocia cu Ionescu? Intr-un mod foarte deschis: punind pe o aceeasi schema structura retelei impreuna cu toate serverele, identificind impreuna cu el: domeniile de defectare, domeniile de broadcast, domeniile de spanning-tree, politica de acces la servere. In acest fel Ionescu va intelege de ce este nevoie sa aveti o retea logico-structurata, iar implementarea va fi o experienta benefica pentru amindoi.

     Incep aceasta ultima parte a articolului “Arhitecturi moderne de retea” repetind obsesiv ideea exprimata in fraza anterioara: este esential sa stabiliti cu cei de la departamentul Servere necesitatile lor. Nu neaparat fiindca vi se cere, ci fiindca din lipsa de  informatii la momentul proiectarii riscati sa scrieti ulterior liste de acces pentru zeci de switch-uri L3, in loc sa faceti doar una. Este esential sa stabiliti si sa delimitati inca de la inceput VLAN-urile si IP subnet-urile asociate, fiindca altfel riscati sa pierdeti mai mult timp gestionind liste de adrese IP definite manual decit va va lua sa construiti arhitectura propriu-zisa.

     Si inca ceva: sub nici un motiv sa nu lasati clienti de retea in VLAN-ul 1. Un laptop conectat intr-un port de retea prin intermediul unui mini-switch este plasat direct in vlan-ul 1 si are astfel acces la traficul tuturor dispozitivelor din acel vlan, existind pericolul potential de a exploata aceasta oportunitate.

Acestea fiind spuse, sa trecem in revista arhitectura unei unitati elementare de retea si apoi sa integram mai multe astfel de unitati intr-o schema completa, pentru a intelege mai bine modul de functionare.

	Fig. 5 - unitati elementare de retea: detalii de functionare

     In zona de acces avem switch-uri de nivel OSI L2, ce asigura conectarea clientilor la retea. Fiindca vrem sa cream o redundanta de tip D2, D2’ si D3, vom conecta switch-ul “sa1” nu la unul, ci la doua switch-uri de core secundar.

In zona de core secundar este nevoie sa definim o metoda de redundanta. Deoarece comutarea in switch-urile normale are loc la nivel L2, toate pachetele de date din “sa1” vor fi trimise automat si catre scs1 (spre punctul 1). Scs1 are, in esenta, minim 2 tipuri  de interfete de retea: cite o interfata in vlan-ul fiecarui switch de acces (inclusiv cu sa1) si inca o interfata de uplink, catre care se trimit pachetele cu destinatie externa (nonLAN - in cazul acesta spre core). Scs1 ofera deci si servicii de router. Din pacate protocolul TCP/IP nu este capabil sa suporte doua interfete “default gateway” si de aici apare problema criticitatii router-ului. Desi rezolvarea redundantei in L2 este imposibila, rezolvarea ei in Layer 3 este relativ simpla. Pentru a “pacali” clientii de retea, se creeaza o interfata virtuala, cu o adresa MAC “proprie”, si un protocol de functionare acceptat de ambele switch-uri L3 ce formeaza core-ul secundar.

Cisco a oferit prima implementare proprietara in 1998, sub denumirea comerciala de HSRP (Hot Standby Routing Protocol). Descrierea acestui protocol o gasiti in RFC 2281 . Sase ani mai tirziu a aparut o implementare standardizata si non-proprietara, sub numele de VRRP (Virtual Router Redundancy Protocol). Cisco a atacat in justitie IETF, pretinzind ca multe mecanisme ce fac parte din protocolul VRRP au avut ca sursa de inspiratie protocolul HSRP. In paralel cu dezvoltarea VRRP, cei de la Universitatea din Berkeley au conceput un protocol de redundanta mai general sub acronimul CARP (Common Address Redundancy Protocol). Acesta include nu numai mecanisme de redundanta specifice LAN-ului, ci si elemente criptografice, care sa-i ofere securitate in cazul unor posibile atacuri, iar incepind cu octombrie 2003 l-au inclus in distributiile FreeBSD si NetBSD.

Desi sint switch-uri, cele doua dispozitive “scs1” si “scs2” (scs = switch de core secundar) vor asigura servicii de routing pt. switch-urile de acces ce se leaga la ele, avind deci capabilitati de router. Prezenta router-ului va limita automat domeniul de broadcast al switch-ului de acces “sa1” chiar la interfata de uplink (conexiunea 1). Practic, domeniul de broadcast va fi limitat numai la porturile switch-ului “sa1”.

Pentru a limita si domeniul de defectare, vom defini unul-doua vlan-uri (si subnet-urile aferente) numai pentru switch-ul “sa1”.

In fine, pentru a obtine redundanta conexiunii switch-ului “sa1”, mai ramine sa activam si un protocol de redundanta in cele doua switch-uri “scs1” si “scs2” si, bine-nteles, sa definim in “sa1” drept default gateway adresa IP virtuala a “cluster-ului” format din “scs1” si “scs2”.

In ceea ce priveste balansarea traficului (load balancing), aceste se poate realiza prin mai multe metode, dintre care cea mai simpla consta in definirea a doua vlan-uri pe fiecare switch de acces. O regula simpla si infailibila poate fi aceea a alocarii adreselor IP in cele doua vlan-uri pe principiul impartirii adreselor IP ale clientilor dupa criteriul: “pare si impare”. Este foarte simplu sa se parametreze apoi ca toate adresele impare sa aibe ca gateway primar echipamentul  “sa1”, iar pe cele pare sa aibe ca gateway primar pe “sa2”. In acest fel traficul se echilibreaza de la sine. Daca se doreste o impartire mai elaborata, se pot folosi mecanisme de balansare specifice fiecarei solutii de redundanta aleasa.

Am obtinut astfel un “modul” de retea logico-structurata care va conecta cladirea ce o deserveste la un core de retea. Prin repetarea acestui model pentru toate cladirile aflate intr-un perimetru dat, in limita conectarii directe la core-ul de retea (uzual 10 Km de fibra), obtinem o retea logico-structurata. Core-ul poate fi si L2, deoarece routarea necesara este realizata de fiecare “cluster” de core secundar in parte.

	Fig. 6 - unitati elementare de retea ce formeaza o retea completa

     Revenind la unitatea elementara de retea, trebuie sa subliniez faptul ca, desi structura acestui bloc “constructiv” pare simpla, ascunde un comportament complex si variat, in functie de parametrarea scs-urilor si de modul in care este construit core-ul de retea. Aici trebuie remarcat faptul ca modulul de retea NU TREBUIE, si nici NU ESTE NECESAR, sa contina bucle de redundanta clasica (spanning-tree loops), si nici agregari de vlan-uri (vlan trunks). Activarea unor astfel de mecanisme complica modul de functionare (si implicit de intelegere) al retelei. Modulul in sine este redundant la nivelul core-ului secundar, in deplina concordanta cu cele discutate in partea a 2a.

In ceea ce priveste conectarea serverelor gestionate de Ionescu, acelasi modul elementar de retea poate fi folosit si pentru conectarea lor. Aplicind dictonul “divide et impera”, putem imparti plaja de adrese IP destinate serverelor in subnet-uri judicios alese, iar apoi obtinem functionalitatea necesara prin intermediul aplicarii unor Liste de Control al Accesului (ACL) in cele doua switch-uri de core secundar existente in Camera Serverelor.

     Citeva cuvinte despre core. Core-ul reprezinta elementul central al retelei, locul unde tot traficul se cumuleaza. Uzual acest nucleu este construit cu echipamente puternice ce au o putere mare de comutare. Fiindca core-ul este un element critic, este necesar sa aiba o structura redundanta, asemanatoare core-ului secundar. Cum am spus mai devreme, poate fi de nivel L2 sau L3. In cazul in care este de nivel L3, core-ul este locul ideal unde se pot defini listele ACL, inlocuind definirea lor in core-ul secundar ce deserveste camera serverelor. Bineinteles ca pentru retele complexe se pot crea liste ACL in cele doua locuri discutate mai devreme.

     Una peste alta, am obtinut un prim model de inlocuire a unei retele simple L2 (flat network) cu un model modular, logico-structurat, ce inglobeaza toate functionalitatile expuse in partea a 2-a. Acest model este foarte potrivit pentru o retea in care nu exista vlan-uri functionale care sa se intinda pe mai multe cladiri. Modelul nostru foloseste vlan-uri doar pentru segmentarea retelei in scopul fiabilizarii ei. Desi este un caz des intilnit, nu este cel mai general si, in plus, este ideal pentru o introducere in proiectarea retelelor modulare logico-structurate. Sint inca multe alte aspecte de luat in calcul (existenta in retea a protocoalelor IPX, sau decnet, de exemplu).

     Inchei aici acest articol cu speranta ca v-am trezit interesul pentru acest gen de solutii. In practica problemele sint specifice si variate si din aceasta cauza nu exista o solutie universala (pentru cei ca noi ar fi fost de-a dreptul plictisitor, nu-i asa?). Astept cu un viu interes comentariile voastre pe blog sau, daca preferati stilul clasic, pe email.

vizitatori.

Site alternativ: sorin-p.xhost.ro