Laboratoare troubleshoot PT (CCNA2)

A trecut ceva vreme de cand nu am mai scris un articol aici.
Cu postarea de azi ma intorc cumva la origini, fiind in stransa legatura cu programa CCNA.

Voi pune mai jos un link catre o colectie de laboratoare facute in PacketTracer (v 8.1.1).
Sunt laboratoare de troubleshoot, gandite sa acopere scenarii ce pot fi intalnite in practica si a caror rezolvare sa nu dureze mai mult de 5-10 minute. Majoritatea pot fi rezolvate prin introducerea unei singure comenzi, odata ce cauza problemei a fost identificata.

Din punct de vedere al programei Netacad, se pliaza pe subiectele discutate in cap. 1 - 4 din CCNA 2, respectiv VLANs, trunking dot1Q si Inter-VLAN routing. Sper sa le fie utile celor care se pregatesc pentru certificarea CCNA.

Link

Mult succes!

Huawei LTE modem API

Deoarece tot mai multe dintre electrocasnicele pe care le utilizez necesita o conexiune la internet pentru a accesa in totalitate capabilitatile acestora, am simtit nevoia de a upgrada conectivitatea casei prin asigurarea unei linii de backup.

Astfel, am contractat un serviciu de date de la Orange. Recunosc ca alegerea operatorului a fost subiectiva pentru ca am fost “in interior” si au oameni misto, priceputi si care fac treaba buna. Continutul articolului nu are vreun substrat promotional, am facut precizarea pentru ca asa am simtit si pentru ca e blogul meu, so… deal with it. :)

Dar dincolo de aceasta, la baza deciziei a stat si o componenta obiectiva pe care o voi detalia in cele ce urmeaza.

Serviciul este promovat sub denumirea comerciala de “Internet fix 4G”. La prima vedere, alaturarea celor doi termeni “fix”, respectiv “4G” poate parea nefireasca, dar voi explica imediat cum functioneaza lucrurile.

Suportul fizic pentru livrarea serviciului este un modem Huawei in care se introduce un SIM de date mobile. Acesta ridica o conexiune cu o celula din proximitate si din ce am inteles, sunt modele care raman “ancorate” de celula la care se autentifica prima data si modele de modem care suporta reautentificarea si la alte celule. Deoarece traficul inclus in abonament e mai mare in cazul modelului “fix”, am ales aceasta varianta.

Exceptand componenta datelor mobile, experienta de utilizare este similara ca in cazul oricarui astfel de echipament oferit de un ISP. Dispune de un port ethernet pentru LAN, dispune de o antena WiFi, are un GUI de configurare, the usual stuff.

Revenind la componenta obiectiva, daca nu mergeam pe varianta descrisa mai sus, alternativa era sa merg catre un abonament de la Telekom livrat prin fibra optica. Linia principala de la DIGI fiind livrata tot prin fibra optica, am ales din motive de redundanta sa nu optez pentru varianta Telekom. De multe ori traseele optice se suprapun pe ultima portiune la intrarea intr-o cladire, iar un incident pe acest segment are o probabilitate ridicata de a afecta ambii operatori. In plus Telekom nu imi oferea ce doream, respectiv doar un serviciu de acces internet. Ar fi trebuit sa iau serviciul la pachet cu un altul si sincer nu aveam nevoie de telefon fix, televiziune prin cablu, sau alte servicii avangardiste din portofoliul lor. :)

Un serviciu similar cu cel de la Orange stiu sa mai ofere in piata doar DIGI, dar exclusiv pe segmentul business. Din acest motiv, plus faptul ca o solutie mai "solida" rezulta si din separarea la nivel de provider, alegerea serviciului de la Orange a venit in mod natural. Cele doua linii sunt agregate fara probleme intr-un firewall, prin porturi Gigabit.

Si acum, daca avem jucarie noua… zic sa ne jucam, nu ?

Cei 100GB de trafic inclus ma astept sa fie un adevarat overkill, serviciul deservind o linie de backup. Totusi, intentionez ca ocazional sa verific gradul de utilizare al traficului din abonament. Acest lucru se face foarte usor din GUI, dar parca nu as vrea ca de fiecare data sa deschid un tab nou, sa ma autentific, iar apoi sa navighez pana la pagina de statistici doar pentru o informatie simpla. Astfel am inceput sa analizez posibilitatea de a automatiza acest proces.

Initial m-am gandit sa utilizez libraria requests pentru python, dar dupa mai multe incercari am realizat ca e un drum nu foarte eficient si m-am decis sa fac putin research pe subiect. Astfel am ajuns la un thread foarte interesant de pe forumurile Huawei. Cineva a mai fost interesat de subiect si a dezvoltat un API pentru interactiunea cu aceste echipamente.

Din pacate API-ul nu este documentat si este necesar sa cautati in repository-ul de pe Github pentru a vedea metodele disponibile. Las mai jos linkurile catre pagina proiectului, catre repository-ul de pe Github asociat acestuia si catre un script facut de mine. Scriptul meu dupa ce e rulat in terminal va afisa traficul utilizat in luna curenta, exprimat in MB si cat reprezinta el procentual din totalul traficului inclus in abonament. O alta utilizare interesanta ar putea fi monitorizarea parametrilor radio.

• Project page
• Github repository
• pentru metodele disponibile uitati-va in huawei_lte_api/api
• My script
• necesare:
• pip install stdiomask
• pip install huawei-lte-api
• My setup
• Device model: B311-221
• Firmware: 11.0.1.2(H697SP2C983)
• Python version: 3.8.10

Pentru usurinta am creat un bash script in care initializez virtual environment-ul python in care am lucrat pentru a rezolva dependintele, dupa care ruleaza scriptul, apoi am creat un alias catre acest script.

Screenshot

Redundanta server DHCP configurat pe Cisco IOS

In Octombrie 2019 scriam despre posibilitatea de a modifica starea HSRP intre doua routere folosindu-ne de un EEM care sa fie declansat de statusul sesiunii BGP asociata serviciului de pe routerul principal. Descriam atunci si scenariul in care consider ca s-ar preta un astfel de setup. Linkul catre articol il puteti gasi aici.

Cam in aceeasi directie, respectiv a utilizarii EEM pentru a obtine ceva, dar pornind de la o nevoie diferita voi merge si in articolul de acum. Scenariul este urmatorul, la fel ca in articolul precedent avem un setup cu doua routere configurate intr-un cluster HSRP. Totusi, discutia de acum este despre serverul DHCP. Mai precis, unde il configuram si cum ii asiguram redundanta in cazul in care routerul pe care e configurat devine indisponibil.

In cautarile mele am gasit un articol pe learningnetwork in care era adresata aceasta speta, dar nu am identificat o solutie prezentata in comentarii. Prin urmare, it’s back to the old GNS3 lab again.
Topicul de pe learningnetwork poate fi gasit aici.

Am ridicat o topologie precum cea din imaginea de mai jos.

Primul pas a fost sa ma decid ce router aleg pentru configurarea serverului DHCP principal.

Am ales in mod natural routerul de backup, deoarece intr-un setup cu HSRP el ar urma sa fie idle in majoritatea timpului. Prin urmare, am zis sa “ii dau ceva de facut”.

Ok, prima parte a spetei e rezolvata, avem redundanta la gateway prin clusterul HSRP si avem un server DHCP care serveste hosturile din LAN. HSRP-ul isi face treaba daca avem un incident pe routerul principal, dar ce facem daca avem un incident pe cel secundar si ne este afectat serverul DHCP ?

Well, EEM to the rescue!

Pe routerul active am configurat o proba SLA care sa monitorizeze interfata de LAN a routerului standby. Aceasta proba am inclus-o intr-un obiect de tip track, iar acest obiect este utilizat ca declansator pentru un script EEM.

Concret, cand proba SLA isi schimba starea in down, scriptul EEM configureaza pe routerul active un server DHCP cu aceleasi caracteristici precum serverul configurat pe routerul standby. Acest server nou ridicat va servi in continuare detaliile necesare conectivitatii IP catre hosturile care se conecteaza in LAN.

Ok, dar noul server va porni cu un nou index in dhcp pool, iar acest nou index cel mai probabil se va suprapune peste o adresa deja alocata unui host de catre serverul de pe standby. “Nu vom avea probleme cu cel putin un conflict de IP-uri ?” ne-am putea intreba firesc.

Well, nu prea. Iar pentru a intelege de ce, va trebui sa ne uitam putin “sub capota” din perspectiva routerului active, la ce se intampla atunci cand un host intra in retea si cere o configuratie IP. Primul mesaj DHCP primit dinspre host e un mesaj de tip DHCP DISCOVER, trimis broadcast. Pentru trasabilitate, clientului ii este alocat un ID, pana la finalizarea procesului de configurare. 

Imediat dupa primirea acestui mesaj, routerul formuleaza un ARP request pentru IP-ul care este index in dhcp pool si creaza o intrare de tip incomplete in ARP table pentru acest IP. Daca va primi un ARP reply de la un host care are deja alocat acest IP, atunci va updata ARP table cu MAC-ul primit, va incrementa cu 1 bit indexul dhcp pool-ului si va trimite un nou ARP request ce va contine noul IP.

Procesul se repeta pana in momentul cand la ARP request nu se mai primeste raspuns, moment in care IP-ul este considerat disponibil, iar serverul DHCP formuleaza un mesaj de tip DHCP OFFER in care include acest IP si il trimite spre retea la adresa de broadcast (255.255.255.255).

Dupa primirea acestui mesaj de catre host, sunt schimbate ultimele doua mesaje, trimise de asemenea la adresa de destinatie broadcast (255.255.255.255). Hostul trimite un mesaj de tip DHCP REQUEST in care solicita IP-ul oferit de server, iar serverul raspunde cu un mesaj de tip DHCP ACK in care trimite IP-ul alocat.

Am adaugat mai jos o captura de pachete si outputul unui debug facut pe routerul active, care surprind procesul descris mai sus.

• captura
• debug

Dupa ce situatia este remediata, iar routerul de backup devine functional, un alt script EEM este rulat la modificarea starii probei SLA, iar serverul DHCP de pe routerul active este deconfigurat.

Am pus mai jos cele doua scripturi EEM.

Script EEM (configurare):

event manager applet GO-LIVE-DHCP event track 1 state down action 1.0 cli command "enable" action 2.0 cli command "conf t" action 4.0 cli command "ip dhcp pool DHCP" action 5.0 cli command "network 10.0.0.0 /24" action 6.0 cli command "default-router 10.0.0.254"

action 7.0 cli command "class IPRANGE"

action 8.0 cli command "address range 10.0.0.100 10.0.0.110" action 9.0 cli command "no ip dhcp conflict logging"

Script EEM (deconfigurare):

event manager applet DO-DOWN-DHCP event track 1 state up action 1.0 cli command "enable" action 2.0 cli command "conf t" action 3.0 cli command "no ip dhcp pool DHCP"