VARP: aktív-aktív FHRP megoldás

A legutóbb egy kevéssé ismert Cisco IOS HSRP feature volt terítéken, most sem megyünk sokkal messzebb: olvastam a napokban egy másik FHRP-ről, a VARP-ról (Virtual ARP). Ez a jószág az Arista EOS-t futtató L3 switchek egyik érdekessége, egy-két éve létező lehetőség, ami a többi hasonló protokollal ellentétben aktív-aktív redundanciát biztosít.

A VARP helyes működéséhez (a többi protokollhoz hasonlóan) kézzel vagy valamilyen irányító protokollal tökéletes szinkronban kell tartani az eszközök route tábláját, és a megfelelő VLAN interfészen az IP cím mellé fel kell venni azt a virtuális IP címet, amit a hostjaink átjáróként fognak használni. Amiben különbözik társaitól a VARP, az a virtuális MAC cím, amit mindkét L3-as Arista eszközön konfigurálni kell, hogy ezzel a MAC címmel válaszoljanak a virtuális IP-s ARP kérésekre, illetve ezt a MAC címet szórják gratuitous ARP-pal.

A többi protokollnál (HSRP, VRRP) kizárólag aktív-passzív redundanciára van lehetőségünk, ahol a forgalom kelet-nyugati és észak-déli irányban is megterheli az aktív eszköz összeköttetéseit, a VARP ezzel szemben egyenletesebb terhelést nyújt észak-déli irányban, és egyáltalán nem terheli feleslegesen a kelet-nyugati kapcsolatokat:

Az egyetlen furcsa dolog a VARP működésében az lehet, hogy amikor egy kliens megkérdezi ARP-vel, hogy mi az átjárójának a MAC címe, akkor szerintem mindkét Arista eszköz el fogja neki küldeni a virtuális MAC címet, azaz kétszer kap választ. Ha szigorú biztonsági felügyelet van a hálózatban, ezek a dupla válaszok kiverhetik a biztosítékot. De ha egyszer a kliens megtudja a virtuális IP-hez tartozó virtuális MAC címet, akkor már csak úgy süvítenek kifelé a bitek a legközelebbi Arista L3 switchen (ezért kell mindegyiken ugyanazt a virtuális MAC címet beállítani). A VARP konfigurálásához a részletes útmutató megtalálható az Arista User Manualban.

DHCP relay agent HSRP mellett IOS-en

Eddig még sosem kellett HSRP-s virtual router groupon (VRG) DHCP-t relayeznem, ma ez is megtörtént. Nem egy bonyolult dolog, de az mégiscsak érdekes, hogy a VRG-ben lévő eszközök közül akkor pontosan melyik fogja ellátni a relay funkciót. Addig ugye világos, hogy semmiképp nem állhatunk meg ott, hogy csupán az elsődleges eszközön konfigurálunk az IOS-ben ip helpert, hiszen akkor nem lesz redundáns a megoldás.

Ha a fenti topológiában mindkét eszközön (R2, R3) beállítjuk az ip helper funkciót a következők szerint:

R2
interface Fa0/1
 ip address 10.10.25.2 255.255.255.0
 ip helper-address 10.10.1.4
 standby 25 ip 10.10.25.1
 standby 25 priority 101
 standby 25 preempt

R3
interface Fa0/1
 ip address 10.10.25.3 255.255.255.0
 ip helper-address 10.10.1.4
 standby 25 ip 10.10.25.1
 standby 25 priority 99
 standby 25 preempt

...akkor arra számíthatunk, hogy a DHCP szerverünk a 10.10.25.0/24-ből érkező DHCP kéréseket duplán fogja kiszolgálni, mert az R2 és az R3 külön ip helper processzei nem tudnak egymásról semmit, csak figyelik az UDP broadcast forgalmat, és teszik a dolgukat süketen és vakon: kétszer fog eljutni minden klienstől minden DHCP üzenet a DHCP szerverre és vissza.

Ahogy az a fenti példában (a kliens szemszögéből) láthatjuk, jámbor kliensünk megpróbálja megújítani a régi IP-jét a 22-es keretben, ám a zord relay agentek egyszerre ráförmednek a DHCP szerver nevében, hogy dobja el, de rögtön (27 és 29), ekkor emberünk belekezd egy új cím igénylésébe (31), amit minden ügynök továbbít a szerver felé, majd a szerver válaszát meg vissza a kliensnek, és így tovább, amíg le nem zárul a folyamat. Ha nem túl háklis a DHCP szerverünk, akkor ezekből a dupla üzenetekből különösebb problémánk nem adódhat.

A Cisco vonatkozó oldalán jelzett szoftververzióktól kezdve azonban véget vethetünk az ip helperek süketelésének, ugyanis a fenti konfigurációt egy-két aprósággal kiegészítve már a VRG állapotától tehetjük függővé az ip helper ténykedését. A relaying kizárólag a VRG-ben éppen aktív eszközön fog működni, azaz megszűnik a fent leírt jelenség, ha minden eszközt hasonlóan konfigurálunk:

R2
interface Fa0/1
 ip address 10.10.25.2 255.255.255.0
 ip helper-address 10.10.1.4 redundancy nemsuket
 standby 25 ip 10.10.25.1
 standby 25 priority 101
 standby 25 preempt
 standby 25 name nemsuket