Pentru ca tot sunt implicat in niste proiecte de design la anumiti clienti , vad tot ma des o problema foarte grava in ceea ce priveste design-ul . Problema e grava pentru ca odata implementata o retea la layer 1 , e foarte greu a fi modificata , costurile sunt mari , si de obicei problemele generate sunt pe masura.
Designu-ul clasic in LAN care este pentru multa lume acceptat este urmatorul .
Aruncam un router in sala serverelor , si de acolo pornim cu un switch l2 , legat la alt switch l2 la care mai punem inca un cablu si legam cu switch-ul de la etajul 1 , de la etajul 1 il ducem in hala de productie la alt switch si tot asa…
Problema e in cazul de mai sus ce te faci daca
- Orice cablu intre switch-uri se “moare” dintr-un motiv sau altul.
- Intra un port de uplink in err-disabled
- Se ia curentul in rack-ul unde e switch-ul
- Se strica switch-ul x
Raspunsul e clar , tot ce este dupa switch-ul X ramane fara conectivitate. Este innaceptabil asa ceva in mediul enterprise , va spun eu ca va iesi scandal , cineva va da cu subsemantul , va fi de rau.
Design-ul de mai sus pe care il vom nota de acum inainte cu ” ASA NU ” arata cam asa .
In exemplul de mai sus switch-ul de la etajul 1 “moare” dintr-u motiv X , poate nu are curent , poate s-a taiat un cablu , TOT ce este in spatele lui pierde orice fel de conectivitate. Aici nu vorbim de retele de 10 useri intelegatori care vor spune ” Adi , nu mai merge netu , fa-i ceva ” , aici vorbim de masini industriale care folosesc serverul din datacenter pentru productie , 200-300 de useri , email-uri , voip , ca suntem baieti mari , am depasit faza cu reteaua = net = ziare , facebook si mail pe yahoo.
De aceea cum va spuneam design-ul este foarte important in faza de proiect al unei retele , si trebuie facut de cineva care are anumite cunostiinte despre folosirea unor protocoale care sunt facute special pentru a oferi reduntanta .
Fara a lungi prea mult , pentru ca sunt convins ca ati prins ideea va arat o topologie de LAN redundanta si vom discuta pe “poza” 🙂
Sa analizam design-ul
Core-ul este compus din doua switch-uri L3 (eu recomand Cisco 3750X /4500 /6500)
Core-ul fiind layer 3 este si default gateway-ul intregii retele si a tuturor vlan-urilor.
Implementarea intre cele doua core-uri protocolul HSRP. (facem practic mai jos) pentru reduntanta la ip-ul defalt gateway.
Intre cele doua core-uri uplink-ul este format din doua porturi agregate (atat redundanta cat si dublu viteza)
Pe partea de access avem switch-uri l2 legate in amblele switch-uri de CORE, in felul acesta oferind redundanta.
Pentru multi acest design este ca si apa sfintzita pentru vampiri , vor urla cat ii tin puterile “BUCLAAAAAA” !!!! “FACI BUCLAAA”
Cunosc oameni care toata viata lor in IT au transpirat cand bagau un cablu intr-un switch facand analize,calcule sa nu cumva sa faca bucla 🙂
Bucla este ok , ofera redundanta la switch-urile de CORE in cazul nostru si este best practice in industrie. Exista protocolul STP pe care il vom configura si care va bloca link-urile redundante atat timp cat exista “BUUUUCLAAAA”
PS : Stiu , stiu vor fi baietzi din industrie care vor spune : bine ,dar de ce nu pui 3750x in stack si faci cross-stack etherchannel intre switch-urile de access si core facand astfel uplink-urile intre switch-urile de core nemaifiind blocate isi vor dubla capacitatea de transfer.
Raspunsul meu este ca nu toata lumea are stack , in loc de 3750-uri poate lumea are alte device-uri si nu vreau sa dau o solutie de nisa unei probleme generice.
Sa incepem de sus in jos , in primul rand configurarea HSRP.
HSRP este un protocol proprietar Cisco care ofera redundanta permitand a doua echipamente sa mentina un ip virtual. Tehnic vorbind stiim cu totii ca adresa de mac este unica in lume pe fiecare device iar ca comunicarea in LAN se bazeaza pe aceasta adresa.
Daca , in cazul in care avem un default gateway care “cade” si il inlocuim cu un alt device cu acelasi ip sunt sanse foarte mari ca nimic sa nu mearga o perioada de timp din cauza arp cache-ului , windowsul , routerele , mai toate device-urile au un cache de ARP care stiu ca ip-ul X este mapat pe MAC-ul Y.
Cisco cand a inventant HSRP-ul a facut in asa fel incat routerele participante sa “inventeze” un mac comun pe care impreuna cu ip-ul virtual sa il mentina , in eventualitatea in care routerul activ cade , routerul standby preia functiile avand acelasi mac si ip.
Comunicarea intre routerele participante in HSRP este adresa de multicast 224.0.0.102 .
Genial este ca HSRP permite group-uri , astfel putem configura ca , switch-ul Core 1 si sa fie ACTIVE pentru vlan 1 , dar switch-ul Core2 sa fie active pentru vlan 2 , ca standby folosind Core 1. Din pacate foarte putina lume am vazut sa configureze in asa fel HSRP-ul desi este best practice permitand amblelor switch-uri sa fie folosite , acest concept numindu-se HSRP load sharing.
Configuratia minima pentru HSRP se face in cateva minute dupa cum urmeaza :
Sa continuam cu o replica draga mie ” Ceeee avem noi aici ? ” Da, ce avem noi aici intre switch-urile de Core , vad dublu sau sunt doua link-uri ?
BUUUUUUUUCLAAAAAAAAAAAAA !!!!!!!!!!!!!!!!!!!!! Nu , nu ,nu e bucla e blocat de STP.
Raspunsul corect nu nici una nici alta . Este AGREGAREA de porturi , mai exact Etherchannel.
Etherchannel-ul permite agregarea mai multor porturi fizice intr-un port logic. Pe switch-urile Cisco se pot agrega maxim 8 porturi pe fiecare switch. Beneficiile sunt enorme. Daca agregam doua porturi Gigabit portul logic va avea un bandwidth de 2GB , iar ca si bonus aveti redundanta , in cazul in care un link cade comunicatia nu “moare” ci doar trece ii scade bandwidth-ul la 1GB.
Ca si protocoale de negociere in industrie se folosesc :
- PAgP – Proprietar Cisco
- LACP – Open
- Personal folosesc PAgP si cand e nevoie (de obicei ESX-urile au nevoie) LACP.
Nu am observat vreo diferenta in practica intre un protocol si celelalt. O parte interesanta si bine de stiut este felul in care se face load balancing-ul pe aceste link-uri agregate , nu o sa aveti nevoie des de a modifica default-ul dar e bine sa stiti ca poate sa balanseze folosind :
- src-mac
- dst-mac
- src-dst-mac
- src-ip
- dst-ip
- src-dst-ip
- src-port
- dst-port
- src-dst-port
Ca sa configurati Etherchannel-ul dinamic folosind protocoalele Pagp sau LACP porturile trebuie sa fie in urmatoarele moduri :
- channel-group [#] mode on (disables PAgP en LACP)
- channel-group [#] mode off (disables PAgP en LACP and prevent the ports to form a port-channel)
- channel-group [#] mode auto (use PAgP in a passive mode, it will wait until a PAgP packet will be send)
- channel-group [#] mode passive (use LACP in a passive mode, it will wait until a PAgP packet will be send)
- channel-group [#] mode desirable (use PAgP in an active mode, it will start to send PAgP packets)
- channel-group [#] mode active (use LACP in an active mode, it will start to send LACP packets)
In functie de preferinte si combinand modurile de mai sus puteti opta pentru ce protocol doriti.
Foarte important este ca sa se formeze agregarea porturile trebuie sa :
- Aiba aceeasi viteza / duplex
- Acelasi Vlan / cu exceptia cand e trunk
- Acelasi protocol de trunking si acelasi native VLAN
- Acelasi cost STP
- Sa nu fie port SPAN (mirroring)
Din pacate imaginea IOS pe care o folosesc in GNS 3 nu suporta protocoale de negociere dar vom configura un etherchannel in simulatorul Packet Tracer (Cisco) astfel combinand cele doua simulatoare (Pachet tracer nu suporta HSRP).
Gata cu switch-urile de core , sa ne ocupam putin de LAN si de redundanta la layer 2 in LAN.
Pentru redundanta la layer 2 se folosesc BUCLELE !!! Buuuclaaaaaaaaaaa !!!!!!! Ori de cate ori spun bucla imi aduc aminte de un fost sef de departament IT intr-o intreprindere care avea un fix cu buclele, orice numai bucla nu.Si suna bine ,repetati dupa mine …bucla,bucla …it`s funny.
Ce pot sa va spun este ca daca infrastrucutra este facuta din switch-uri Cisco chiar daca sunt scoase din cutie si faceti bucle peste bucle nu ar trebui sa fie o problema, sunt convins ca multi aveti bucle in retea dar nici nu stiti de ele. Daca treceti pe langa un switch Cisco si vedeti un port portocaliu sunt toate sansele ca portul respectiv sa fie blocat de spanning tree datorita unei bucle.
Buclele intr-adevar fara spanning tree ar fi un cosmar,ar pune in cap LAN-ul la nivel de secunde si am vazut in realitate ce inseamna asta. Primul semn ca este o bucla undeva este ca procesorul este in 100% si numarul de pachete pe secunda este enorm sa nu mai vorbim de cum fac led-urile cand te uiti la switch.
Dar sa vorbim despre acest protocol care ne salveaza LAN-ul si despe care nu multa lume stie. E destul de complex , nu vom intra foarte adanc in detalii tehnice. Protocolul spanning tree este un protocol creat special pentru a preveni buclele in retea si ca bonus ofera redundanta.
Cum functioneaza (varianta scurta si simplificata ) :
Selectarea root-ului
Intr-o topologie toate switch-urile participante au un “bridge ID” si pe baza acestui bridge ID se face un “concurs” . Switch-ul cu cel mai MIC , (la STP mai mic = mai bun) bridge ID este ales ROOT-ul . ROOT-ul reprezinta punctul pe care toate switch-urile din retea se vor chinui sa il ajunga cat mai repede pe care ce mai scurta (cu costul cel mai mic).
Problema este ca daca nu setati ID-ul care de fapt este o cifra default pe toate switch-urile va fi aceeasi valoare respectiv 32769 (nu stiu de unde a scos Cisco valoarea asta). Avand toate switch-urile acelasi BID departajarea se face printr-un mod foarte prost , respectiv adresa de mac cea mai mica.
De obicei adreasa de mac cea mai mica o are cel mai vechi switch din retea , cine stie pe unde , prin ce rack obscur, uitat de lume , acel switch va deveni ROOT-ul infrastructurii. Niciodata nu am intalnit atat de des in practica o eroare de configurare ca si root-ul spanning tree.Nimeni nu seteaza root-ul , normal ca astfel LAN-ul nu este optimizat corespunzator.
Determinarea caii catre ROOT
Odata a ales switch-ul de root , fiecare switch participant se va da peste cap si va face calcule peste calcule , algorimti,ecuatii si matrici ca sa ajunga cat optim catre root.
Fiecare switch care nu este root-ul isi va desemna un root port ,mai exact un port care duce spre root cu un cost cat mai mic. Costurile spanning tree-ului variaza in functie de latimea de banda , si au valorile din tabelul de mai jos :
Costul se calculeaza prin suma tuturor link-urilor pana la ROOT. Daca root-bridge-ul se afla la peste 2 switch-uri legate prin 100mb se calculeaza 19+19 = cost 38
Acum incepeti sa intelegeti de ce este foarte important sa stabiliti manual root-ul si sa nu il lasati la intamplare.
Daca sunt doua porturi care duc spre root este blocat automat portul cu cost mai mare catre ROOT.
Restul porturilor se numesc “DESIGNATED” mai pe romaneste porturi care forwardeaza traficul si nu sunt porturi spre root. Din categoria asta fac parte porturile spre alte switch-uri sau pc-uri ,etc.
Cum se “prinde” switch-ul ca este o bucla este putin mai complicat :
Pentru a obtine informatiile de mai sus Spanning tree-ul foloseste niste pachete speciale numite BPDU. ( Bridge Protocol Data Units )
Switch-ul trimite folosind ca sursa mac-ul fiecarui port BPDU-uri la fiecare 2 secunde cu destinatia adresa de multicast Layer 2 01:80:C2:00:00:00. Este o adresa multicat rezervata STP . (nu trebuie sa stiti pe de rost adresa )
Cand un device este introdus intr-un port , portul trece prin mai multe state-uri ca sa se asigure ca nu exista o bucla in retea. Aici si explicatie de ce atasati un device la un switch cisco si staaaa, staaaa portul portocaliu cca 1 min pana sa se faca verde.
Fazele sunt :
- Listening – faza in care switch-ul asculta si proceseaza BPD-urile primite de la celelalte switch-uri
- Learning – faza in care switch-ul inca nu forwardeaza traficul dar invata adresele de MAC si populeaza tabela CAM.
- Forwarding – faza in care switch-ul forwardeaza traficul, continuand sa primeasca si BPDU-uri , si sa monitorizeze eventualele bucle.
- Blocking – starea unui port care daca ar fi pornit ar cauza o bucla.
Cum spuneam toate fazele de mai sus insumeaza cca 50 secunde , care la inventia STP-ului era un downtime acceptabil dar dupa standardele actuale este de neconceput. Cisco a venit cu un protocol proprietar care se numeste PVRST (rapid per-vlan spanning tree) care optimizeaza acele 50 de secunde ,introducand si cateva noi roluri ale porturilor.
Totodata in cazul in care aveti mai multe vlan-uri pe fiecare vlan functioneaza o instanta de STP , in asa fel puteti optimiza extrem punand root-ul unde va convine in functie de fiecare vlan. Totodata daca aveti un trunk care cauzeaza o bucla nu opreste tot trunk-ul ci doar vlan-ul respectiv.
Pe partea de securitate exista capitole intregi despre securizarea STP-ului , dupa cate vedeti STP-ul nu accepta nici o parola ,deci oricine poate venii cu un switch si sa il puna root , si aici din nou e o problema in industrie , nu prea vad la nimeni securizat STP-ul , exista imbunatatiri aduse precum comezi ca si “spanning tree portfast” , uplinkfast , udld , care se invata la CCNP Switching si despre care nu voi intra in detaliu aici.
Mai sunt si alte protocoale de spanning tree proprietare a altor vendori dar nu le vom discuta aici pentru ca habar nu am de ele.
Cuprins articol: