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.
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"
Niciun comentariu :
Trimiteți un comentariu