LAN-uri virtuale

LAN-uri virtuale

La inceputul dezvoltarii retelelor locale de calculatoare, cabluri groase galbene serpuiau prin conductele de cablu ale multor cladiri de birouri. Acestea conectau toate calculatoarele pe la care treceau. Adesea erau mai multe cabluri conectate la coloana vertebrala centrala (ca in fig. 4-39) sau la un nod central. Nu se acorda nici o importanta corespondentei intre calculatoare si LAN-uri. Toti oamenii din birouri alaturate erau conectati la acelasi LAN idiferent daca apartineau sau nu aceleiasi organizatii. Pozitionarea fizica a calculatoarelor domina logica.

Totul s-a schimbat odata cu aparitia Iui lOBase-T si a nodurilor in anii 1990. Gadirile au fost recablate (cu costuri considerabile) pentru a scoate vechile cabluri galbene, instalandu-se in loc cabluri cu perechi de fire torsadate de la fiecare birou pana la locurile de conectare centrala de la capatul fiecarui coridor sau pana la camera unde se afla calculatorul principal, asa cum este ilustrat in fig. 4-48.

Daca vicepresedintele care se ocupa de cablare era vizionar, se instalau cabluri cu perechi de fire torsadate de categoria a cincea; daca acesta era un statistician era utilizat cablu de telefon existent (categoria 3) (pentru a fi inlocuit cativa ani mai tarziu cand a aparut Ethernet-ul rapid).

Folosindu-se noduri (si mai tarziu, comutatoare) Ethernet, era adesea posibila configurarea LAN-urilor din punct de vedere logic mai mult decat din punct de vedere fizic. Daca o companie doreste k IAN-uri, cumpara k noduri. Alegand cu grija ce conectoare vor fi introduse in nod, ocupantii LAN-ului pot fi alesi din punct de vedere organizational fara a se da prea mare importanta amplasarii geografice. Bineinteles, daca doi oameni apartinand aceluiasi departament lucreaza in cladiri diferite, cel mai probabil acestia sunt conectati in noduri diferite si astfel in LAN-uri diferite. Cu toate acestea, situatia se prezinta mult mai bine decat in cazul LAN-urilor bazate pe amplasare geografica.

Conteaza cine este conectat si in ce LAN? Oricum, in toate organizatiile, toate LAN-urile sunt in cele din urma interconectate. Pe scurt, raspunzand la intrebare: adesea conteaza. Dintr-o multitudine de motive administratorii de retea isi doresc sa grupeze utilizatorii in IAN-uri pentru a reflecta structura organizatorica mai degraba decat structura fizica a cladirii. O problema este securitatea. Orice interfata de retea poate fi configurata in mod transparent, copiind tot traficul care soseste pe canalul de comunicatie. Multe departamente, cum ar fi cele de cercetare, patente si contabilitate, detin informatii pe care nu doresc sa le faca cunoscute in afara departamentului. In situatii ca acestea, punerea tuturor oamenilor din departament intr-o singura retea locala fara a permite vreunui fel de trafic sa iasa din aceasta retea este o solutie buna. Totusi, administratorul va vrea sa auda despre astfel de aranjamente doar daca toti oamenii din fiecare departament sunt localizati in birouri adiacente, fara birouri interpuse intre acestea.

Poate sa apara si o a doua problema. Unele retele locale sunt utilizate mai intensiv decat altele si poate fi benefica separarea acestora la anumite momente. De exemplu, daca persoanele de la cercetare ruleaza tot felul de experimente dichisite care din cand in cand scapa de sub control si Ie satureaza reteaua locala, persoanele de la contabilitate s-ar putea sa nu fie foarte entuziasmate in a dona capacitatea departamentului lor pentru a ajuta.

O a treia problema este difuzarea. Cele mai multe retele locale suporta difuzarea si multe protocoale de nivel superior folosesc aceasta facilitate in mod extensiv. Spre exemplu, atunci cand un utilizator doreste sa trimita un pachet catre o adresa IP x, cum stie statia sa ce adresa MAC sa puna in cadru? Vom studia aceasta intrebare in cap. 5, dar, pe scurt, raspunsul este ca va difuza un cadru care contine intrebarea: A cui este adresa IP x? Apoi asteapta un raspuns. Si exista multe alte exemple de utilizare a difuzarii. Pe masura ce din ce in ce mai multe retele locale sunt interconectate, numarul cadrelor de difuzare receptionate de fiecare masina tinde sa creasca liniar cu numarul de masini.

O alta problema legata de difuzare apare din cand in cand, atunci cand o placa de retea se defecteaza si incepe sa transmita un sir nesfarsit de cadre de difuzare. Rezultatul acestei furtuni de difuzari (broadeast storm) este ca (1) intreaga capacitate a retelei locale este ocupata de aceste cadre si (2) ca toate masinile din toate retele locale interconectate cu aceasta sunt paralizate doar prin procesarea si ignorarea tuturor cadrelor difuzate.

La prima vedere s-ar putea parea ca furtunile de difuzari pot fi limitate in spatiu prin separarea retelelor locale prin punti si comutatoare, dar daca scopul este sa se atinga transparenta (de ex o masina poate fi mutata intr-o retea locala diferita fara ca nimeni sa observe acest lucru), atunci puntile trebuie sa inainteze toate cadrele de difuzare.

Dupa ce am vazut de ce companiile ar dori sa aiba mai multe retele locale cu intindere limitata, haideti sa ne intoarcem la problema decuplarii topologiei logice de cea fizica. Sa presupunem ca un utilizator este mutat in cadrul companiei de la un departament la altul fara sa isi schimbe biroul, sau

ca isi schimba biroul fara a-si schimba departamentul. Folosind o cablare bazata pe hub-uri, mutarea utilizatorului in reteaua locala corecta presupune ca administratorul de retea sa mearga in centrul de cablare si sa mute conectorul pentru calculatorul utilizatorului respectiv dintr-un hub in alt hub.

in multe companii, schimbarile organizationale au loc tot timpul, insemnand ca administratorii de sistem petrec o multime de timp scotand cabluri de undeva si punandu-Ie in alta parte. De asemenea, in unele cazuri, este posibil ca schimbarile sa nu poata fi facute deloc, pentru ca perechea torsadata de la masina utilizatorului este prea departe de hub-ul potrivit (de ex. in alta cladire).

Ca raspuns la cerintele utilizatorilor pentru o flexibilitate sporita, comerciantii de echipamente de retea au inceput sa lucreze la o modalitate de a recabla cladiri in intregime doar cu ajutorul sof-tware-ului.. Conceptul rezultat este numit VLAN (Virtual LAN, rom: retea locala virtuala) si a fost standardizat de catre comitetul 802. Acum este utilizat in multe organizatii. Haideti sa aruncam o privire asupra lui Pentru informatii suplimentare despre VLAN-uri, vezi (Breyer and Riley, 1999; and Seifert, 2000).

VLAN-urile se bazeaza pe comutatoare dedicate, cu toate ca pot avea niste hub-uri la periferie, ca in fig. 4-48. Pentru configurarea unei retele bazate pe VLAN-uri, administratorul de retea decide cate VLAN-uri vor exista, ce calculatoare vor apartine fiecarui VLAN si cum se vor numi VLAN-urile. De cele mai multe ori, VLAN-urile sunt denumite (informai) cu nume de culori, pentru ca este apoi posibila tiparirea de diagrame color cu dispunerea fizica a masinilor, figurand membrii VLAN-ului rosu in rosu, membrii VLAN-uIui verde in verde si asa mai departe. in acest fel, atat dispunerea logica, cat si cea fizica, sunt vizibile intr-o singura figura.

Ca un exemplu, sa consideram cele patru retele locale din fig. 4-49(a), in care opt dintre masini apartin VLAN-ului G (gri) si sapte apartin VLAN-ului A (alb). Cele patru retele locale sunt conectate cu doua punti. Bl si B2. Daca este folosita cablare centralizata cu fire torsadate, pot fi de asemenea prezente 4 hub-uri (care nu sunt prezentate in figura), dar la nivel logic un cablu cu mai multi conectori si un hub sunt acelasi lucru. Prezentarea lor in modul in care sunt figurati aici face figura mai putin incarcata. De asemenea, termenul de punte tinde sa fie folosit in zilele noastre mai ales in cazurile cand exista mai multe masini pe fiecare port, ca in aceasta figura, dar in rest termenii 'punte' si 'comutator' sunt interschimbabili. Fig. 4-49(b) prezinta aceleasi masini si aceleasi acelasi VLAN-uri folosind comutatoare cu un singur calculator pe fiecare port.

B

h- M

N

(a)

Fig. (a) Patru retele fizice organizate in doua VLAN-uri, gri si alb, de catre doua punti (b) Aceleasi 15 masini organizate in doua VLAN-uri cu comutatoare

Pentru a asigura functionarea corecta a VLAN-urilor, trebuie create tabele de configurare in comutatoare sau in punti. Aceste tabele stabilesc care VLAN este accesibil pe fiecare dintre porturi (linii). Arunci cand un cadru este receptionat de la, sa spunem, VLAN-ul gri, acesta trebuie inaintat catre toate porturile marcate cu G. Acest lucru este valabil atat pentru traficul directionat, cat si pentru cel cu destinatie multipla si cu difuzare.

Observati faptul ca un port poate fi marcat cu mai multe culori de VLAN-uri. Acest lucru poate fi vazut clar in fig. 4-49(a). Sa presupunem ca masina A difuzeaza un cadru. Puntea Bl receptioneaza cadrul si observa ca acesta este provenit de la o statie din VLAN-ul gri, deci il va inainta catre toate porturile marcate cu G (cu exceptia portului de unde a venit). Din moment ce Bl are numai doua alte porturi si ambele sunt marcate cu G, cadrul va fi trimis pe ambele porturi.

in cazul lui B2 povestea este diferita. Aici puntea stie ca nu exista masini gri in reteaua locala 4, deci cadrul nu va ti inaintat acolo. Acesta va merge numai catre reteaua locala 2. Daca unul dintre utilizatorii din reteaua locala 4 isi va schimba departamentul si va fi mutat in VLAN-ul gri, atunci tabela din interiorul lui B2 va trebui actualizata pentru a reeticheta portul cu GA in loc de A Daca masina F devine gri, atunci portul catre reteaua locala 2 trebuie etichetat cu G in loc de GA

Acum sa presupunem ca toate masinile atat din reteaua locala 2 cat si din reteaua locala 4 devin gri. Atunci nu numai ca porturile lui B2 catre retelele 2 si 4 vor fi marcate cu G, dar si portul lui Bl catre B2 trebuie dc asemenea reetichetat de la GA la G, din moment ce cadrele albe care ajung la Bl din retelele 1 si 3 nu mai sunt inaintate catre B2. in fig. 4-49(b) acesti situatie ramane in picioare, numai ca aici toate porturile care ajung la cate o singura masina sunt etichetate cu o singura culoare deoarece acolo exista un singur VIAN.

Pana acum am presupus ca puntile si comutatoarele stiu cumva ce culoare are un cadru receptionat. Cum stiu acest lucru? Exista trei metode folosite:

Fiecarui port ii este asociata o culoare de VLAN

Fiecarei adrese MAC ii este asociata o culoare de VLAN

Fiecarui protocol dc nivel 3 sau fiecarei adrese IP ii este asociata o culoare de VLAN

Cu prima metoda, fiecare port este etichetat cu o culoare de VLAN. Totusi, aceasta metoda func-tioneaza doar daca toate masinile de pe un port apartin aceluiasi VLAN. In fig. 4-49(a), acest lucru este valabil in cazul lui Bl pentru portul catre reteaua 3, dar nu si pentru portul catre reteaua 1.

In cazul celei de-a doua metode, puntea sau comutatorul are o singura tabela ce contine adresa MAC pe 48 de biti a fiecarui masini conectate la el, impreuna cu VlAN-ul caruia ii apartine masina respectiva. In aceste conditii, este posibila combinarea mai multor VLAN-uri pe o singura retea locala fizica, cum este cazul retelei I din fig. 4-49(a). Cand un cadru este receptionat, tot ce trebuie sa faca puntea sau comutatorul este sa extraga adresa MAC si sa caute intrarea corespunzatoare din tabela, pentru a gasi VLAN-ul de unde a fost receptionat cadrul.

Cea de-a treia metoda presupune ca puntea sau comutatorul sa examineze campul incarcare utila al cadrului cu scopul de a clasifica, de exemplu, toate masinile IP ca apartinand unui VLAN si toate masinile AppIcTalk ca apartinand altuia. Pentru cel dintai, adresa IP poate fi de asemenea utilizata pentru identificarea masinii. Aceasta strategie este foarte utila atunci cand mai oricare din mai multe masini sau calculatoare portabile pot fi cuplate in mai multe statii de ancorare. Din moment ce fiecare statie de ancorare are propria adresa MAC, doar cunoasterea statiei de ancorare folosite nu spune nimic despre VI jKN-uI caruia ii apartine laptop-ul.

Singura problema cu aceasta abordare este ca nu respecta una dintre regulile de baza in retele ce calculatoare: independenta nivelurilor. Nu este treaba nivelului legatura dc date ce este in campul dc incarcare utila al cadrului. Acest nivel nu ar trebui sa examineze aceste camp si cu atat mai putin sa ia decizii pe baza continutului acestuia. O consecinta a utilizarii acestei abordari este aceea ca o modificare a unui protocol de nivel 3 (de exemplu o trecere de la IPv4 la IPv6) va duce la nefunctionarea comutatorului. Din nefericire, exista pe piata comutatoare care functioneaza in acest fel.

Desigur, nu este nimic in neregula in rutarea bazata pe adrese IP - aproape tot cap. 5 este dedicat rularii IP - dar sa combini nivelurile inseamna sa o cauti cu lumanarea. Un producator de comutatoare poate desconsidera acest argument sustinand ca toate comutatoarele comercializate de el inteleg atat IPv4, cat si IPv6, deci totul este in regula. Dar ce se va intampla atunci cand va aparea IPv7? Producatorul probabil ca va raspunde: cumparati comutatoare noi, este asta atat de rau?

Standardul IEEE 802.1Q

Daca ne gandim mai bine, ceea ce conteaza cu adevarat este VLAN-ul cadrului insusi, nu VLAN-ul masinii care l-a trimis. Daca ar exista o modalitate de identificare a VIAN-ului in antetul cadrului, atunci necesitatea de a examina campul incarcare ar disparea. Pentru un model nou de retea locala, cum ar fi 802.11 sau 802.16, ar fi fost destul de usor sa fie adaugat numarul VLAN-ului in antet. De fapt, campul identificator de conexiune din 802.16 este oarecum similar cu spiritul identificatorilor de VIAN. Dar ce sa facem cu Ethernetul, care este tehnologia dominanta de retele locale si care nu are campuri goale disponibile care sa poata fi utilizate pentru identificatorul de VIAN?

Comitetul IEEE 802 a confruntat aceasta problema in 1995. Dupa multe discutii, a facut inimaginabilul si a modificat cadrul Ethernet. Noul format a fost publicat in standardul IEEE 802.10, lansat in 1998. Noul format contine marcajul pentru VIAN; il vom examina in curand. Nu in mod surprinzator, schimbarea a ceva atat de bine impamantenit cum este Ethernetul nu este in intregime triviala. O serie de intrebari care ne vin in gand sunt:

Trebuie sa aruncam cateva sute de milioane de placi de retea Ethernet?

Daca nu, cine genereaza noul camp?

Ce se intampla cu cadrele care au deja lungimea maxima?

Desigur, comitetul 802 a fost constient (in mod dureros) de aceste probleme si a trebuit sa ofere .solutii, ceea ce a si facut.

Cheia pentru gasirea solutiei este sa realizam ca identificatorii de VLAN sunt utilizati efectiv numai de punti si de comutatoare si nu de catre masinile utilizatorilor. Prin urmare, in fig. 4-49 nu este esential ca identificatorii sa fie prezenti pe liniile ce pornesc de Ia statii, atat timp cat sunt prezenti pe liniile ce interconecteaza puntile. Prin urmare, pentru a folosi VLAN-uri, puntile si comutatoarele trebuie sa fie constiente de existenta acestora, dar aceasta era deja o cerinta. Acum introducem necesitatea suplimentara ca acestea sa implementeze 802.1Q, iar cele noi deja fac acest lucru.

La intrebarea daca trebuie aruncate toate placile Ethernet, raspunsul este nu. Aduceti-va aminte: comisia 802.3 nu a putut convinge oamenii sa schimbe campul tip intr-un alt camp numit lungime. Va puteti imagina reactia acestora la anuntul ca toate placile Ethernet au fost scoase din uz. Oricum, in momentul in care noile placi Ethernet vor aparea pe piata, se spera ca acestea vor suporta 802. IQ si se vor putea integra in totalitate in VLAN-uri.

Asa ca, daca cel care genereaza mesajul nu introduce campurile pentru VIAN, atunci cine o va face? Raspunsul este ca prima punte sau comutator ce suporta VLAN la care ajunge un cadru, adauga campurile, si Ia ultimul le scoate. Dar cum stie care cadru apartine carui VLAN ? Ei bine, prima punte sau primul comutator poate atribui un numar VLAN unui port, se poate uita la adresa MAC, sau sa examineze informatia utila. Pana cand toate placile Ethernet vor in conformitate cu 802.1Q,

suntem oarecum tot in punctul din care am plecat. Marca speranta este ca de la inceput toate placile gigabil Ethernet vor fi in conformitate cu 802.IO si pc masura ce oamenii vor trece la gigabit Ethernet, 802.1Q va fi introdus automat. in ce priveste problema cadrelor mai mari de 1518 octeti, 802.1Q ridica limita la 1522 octeti, i

in timpul procesului de tranzitie, multe retele vor avea ca masini perimate (de obicei Ethernet clasic sau rapid) care nu suporta VLAN si masini (de obicei gigabit Ethernet) care suporta. Situatia este aratata in fig. 4-50, unde simbolurile umbrite suporta VLAN iar celelalte nu. Pentru a simplifica problema, presupunem ca toate comutatoarele suporta VLAN. Chiar daca nu este cazul, primul comutator ce suporta VLAN poate adauga marcaje bazate pe adrese MAC sau IP.

Fig. Tranzitia de la un Ethernet perimat la un Ethernet ce suporta VLAN. Simbolurile umbrite suporta VLAN; cele goale nu.

in aceasta figura, placile Ethernet ce suporta VIAN genereaza direct cadre marcate (de exemplu 802.10), si comutarile ulterioare se folosesc de aceste marcaje. Pentru a face aceasta comutare, comutatoarele trebuie sa stie in prealabil care VLAN poate fi accesat si pe ce port. Stiind ca un cadru apartine unui VLAN gri, nu ajuta prea mult faptul ca un cadru apartine unui VIAN gri, pana cand comutatorul stie care porturi sunt conectate la masinile din VLAN-ul gri. Asa ca, comutatorul are nevoie de o tabela indexata de VLAN care sa spuna ce porturi sa foloseasca si care suporta VLAN sau nu.

Cand un PC perimai trimite un cadru catre un comutator ce suporta VIAN, comutatorul construieste un nou cadru marcat bazat pe cunostintele sale despre VLAN-ul care I-a trimis (folosind portul, adresa MAC sau adresa IP). Din acel punct, nu mai conteaza daca cel care trimite este o masina legacy (perimata). Similar, un comutator care trebuie sa trimita un cadru marcat catre o masina perimata (legacy) trebuie sa reconstruiasca cadrul in forma veche inainte de a-1 furniza

Haideti sa privim formatul cadrului 802.10. Este schitai in fig. 4-51. Singura schimbare este adaugarea unei perechi de campuri a cate 2 octeti. Primul este identificatorul protocolului VLAN. El are intotdeauna valoarea 0x8100. intrucat acest numar esle mai mare de 1500, toate placile Ethernet interpreteaza acest numar ca tip nu ca lungime. Ce face o placa mai veche cu un asemenea cadru este o problema deoarece asemenea cadre nu ar trebui trimise catre acestea.

Identificatorul protocolului VLAN (0x8100)

Fig. 4-51. Formatul cadrelor Ethernet 802.3 mostenite si 802.10.

Al doilea camp de 2 octeti contine trei sub-campuri. Sub-campul principal este identificatorul VLAN ce ocupa cei mai putin semnificativi 12 octeti. Aceasta este problema principala: carui VLAN apartine fiecare cadru? Gimpul Prioritate de 3 biti nu are nici o legatura cu VLAN-ul, dar intrucat schimbarea antetului Ethernet este un eveniment foarte rar care s-ar desfasura pe parcursul a trei ani si ar implica 100 de oameni, de ce nu am pune alte informatii folositoare in el? Acest camp face posibila distingerea intre traficul in timp real implementat hard si cel implementat soft si de traficul inteas pentru o mai buna calitate a serviciilor in Ethernet. Este nevoie de voce prin Ethernet (ca sa fim impartiali, 1P a avut un camp similar mai mult de un sfert de secol si nu a fost folosit niciodata).

Ultimul bit, CF1 (Canonical Format Indicator, rom: indicator de formal canonic) ar fi trebuit sa fie numit CEI (Corporate Ego Indicator, rom: indicator de ego al corporatiei). Originar era folosit sa indice adresele MAC in format little-indian sau btg-indian insa aceasta obisnuinta s-a pierdut datorita controverselor. in zilele noastre prezenta lui indica faptul ca informatiile utile contin un 802.5 cadru prestabilit (freezed-dried, rom: inghetat si uscat) care este transportat de o retea Ethernet care spera sa gaseasca la destinatie un LAN 802.5. Tot acest aranjament, nu are nici o legatura cu VLAN-urile. Insa politica comitetului de standarde este foarte asemanatoare cu politica obisnuita: daca votezi in favoarea bitului meu, votez si eu in favoarea bitului tau.

Asa cum am precizat mai sus, cand un cadru marcat ajunge la un comutator ce suporta VLAN, comutatorul foloseste, ca un index intr-o tabela identificatorul VIAN, pentru a gasi la ce port sa trimita. Dar de unde vine tabela? Este construita manual, ne-am intors de unde am plecat: configurarea manuala a puntilor. Frumusetea puntilor transparente este faptul ca acestea sunt montate si pornite (plug-and-play) si nu au nevoie de configurare manuala. Ar fi pacat sa se piarda aceasta facilitate. Din fericire, puntile care suporta VIAN se pot autoconfigura pe baza marcajelor care vin. Daca un cadru marcat, cum ar fi VLAN 4, ajunge la portul 3, aparent cateva calculatoare de pe portul 3 apartin VLAN-ului 4. Standardul 802.1Q explica cum sa construiesti dinamic tabelele, in marea majoritate a cazurilor referindu-se la parti apropiate din algoritmul lui Perimau standardizat in 802.1D.

Inainte de a parasi subiectul referitor la rularea in VLAN, merita sa facem o ultima observatie. Multi oameni in lumea Internetului si a Ethernetului sustin fanatic retelele neorientate pe conexiune si se opun cu violenta conexiunilor la nivelul legaturii de date. in momentul de fata, VLAN-urile introduc ceva ce este surprinzator de asemanator cu o conexiune. Pentru a utiliza corect VLAN-uri, fiecare cadru are un nou identificator special care este utilizat pe post de index intr-o tabela din comutator, pentru a gasi destinatia cadrului. Este exact acelasi principiu de functionare ce apare la retelele orientate pe conexiune. In retelele neorientate pe conexiune adresa destinatie este folosita la rutare si nu exista identificatori de conexiune. Alte aspecte privind comunicarea vor fi tratate in cao. 5.