A 2. és a 3. rétegben nagyon könnyen tudjuk redundáns útvonalakkal megbízhatóbbá tennünk a hálózatunkat. Viszont egy gyenge pontja lehet a LAN hálózatainknak, és ez az alapértelmezett átjáró, amelyet közvetlenül a végállomásokon állítunk be (akár statikusan, akár dinamikusan), és nincsen arra módszer, hogy amennyiben az alapértelmezett átjáró nem lenne elérhető, az állomások automatikusan keressenek egy másik átjárót. Erre a problémára ad megoldást a HSRP protokoll.
A HSRP működése
A HSRP (Hot Standby Router Protocol) működése nagyon egyszerű: A protokoll egy virtuális IP címet kínál fel a LAN hálózatunk számára (természetesen a LAN alhálózatából) alapértelmezett átjáróként. Ezt a virtuális IP címet fogjuk alapértelmezett átjáróként beállítani a LAN állomásain. A virtuális IP címen több forgalomirányító is osztozik, egymás között megbeszélve, hogy melyikük fogja az alapértelmezett átjáró feladatát ellátni, vagyis a tényleges adatforgalmat közvetíteni. (A virtuális IP cím mellé egy virtuális MAC címet is rendel a HSRP.)
Azt a forgalomirányítót, amelyik a tényleges adatforgalmat közvetíti, aktív (active) forgalomirányítónak nevezzük. Az, hogy melyik lesz az aktív, egy választás eredménye. Minden forgalomirányítóhoz rendelünk egy prioritást, és amelyiké a legnagyobb, az kapja meg az aktív szerepet. A második legmagasabb prioritású forgalomirányító kapja meg a tartalék (standby) szerepet, míg a többiek figyelő (listen) állapotba kerülnek. Ha az aktív kiesik, akkor a tartalék veszi át a feladatát, és a legmagasabb prioritású figyelő állapotú lesz a tartalék. (Persze, ha van.) Minden forgalomirányítónak van egy beállított, alapértelmezett HSRP prioritása, melynek értéke 100. Amennyiben két forgalomirányítónak azonos a prioritása, akkor a LAN-hoz kapcsolódó interfész IP címe alapján döntik el, hogy melyik legyen a sorban elől. (Az IOS érdekessége, hogy ha az alapértelmezett értéket konfiguráljuk prioritásként, akkor ez a parancs nem jelenik meg a futási konfigurációban.)
A forgalomirányítók csoportokba is rendezhetők (IOS10.3-tól), minden csoporton belül egy aktív és egy tartalék forgalomirányító lehet, és persze több figyelő. Összesen 32 csoport hozható létre. Érdekes, hogy ugyanaz a forgalomirányító egyszerre több csoportban is szerepelhet, sőt más-más csoportban más-más szerepekhez juthat. Minden csoport más virtuális IP címet kínálhat az állomások felé alapértelmezett átjáróként. Ezzel például terhelésmegosztás hozható létre, melyről a későbbiekben még szó lesz. (Egy csoporton belüli forgalomirányítók viszont nem képesek terhelésmegosztásra, vagyis egy csoporton belüli aktív és tartalék forgalomirányító nem képes egy időben a LAN forgalmának továbbítására.) Ha nem adjuk meg a csoportszámot, alapértelmezetten a 0-s csoporthoz rendeli a parancsokat.
A HSRP protokoll egy forgalomiránytón a LAN-hoz kapcsolódó interfészen kiadott standby ip paranccsal indítható el. Ugyanebben a parancsban lehet megadni a virtuális IP címet is (standby ip 192.168.1.254). Ha ezt elhagyjuk, akkor egy másik HSRP forgalomirányítótól fogja megtanulni azt.
A HSRP forgalomirányítók egymással az alapértelmezetten 3 másodpercenként kiküldött Hello üzenetekkel tartják a kapcsolatot. (Ez a Hello üzenet az 1. verziójú HSRP-ben a 224.0.0.2-es csoportos címre megy.) A Hello üzenetek küldésének gyakoriságát a Hello timer értéke szabja meg. Ha egy forgalomirányító kiesik, akkor a többi nem kap tőle Hello üzeneteket. A hold timer által meghatározott idő múlva ezt a forgalomirányítót elveszettnek tekintik. Amennyiben ez a kieső forgalomirányító az aktív volt, a tartalék veszi át a szerepét. Ha ez a korábbi, legmagasabb prioritással rendelkező forgalomirányító LAN interfésze visszakapcsolódik, megint elkezdi küldeni a Hello üzeneteket, és amennyiben a preemption funkció aktiválva van rajta (a standby preempt paranccsal), azonnal visszakéri az aktív szerepet. Ha a preemption funkció nincsen aktiválva, akkor csak akkor kapja vissza az aktív szerepet, ha az éppen aktív nem lesz elérhető. (Itt most feltételeztük, hogy csak 2 forgalomirányítót konfiguráltunk HSRP-re, ugyanis ha van figyelő állapotú is, akkor az első aktív kiesésekor ez a figyelő felveszi a tartalék szerepet, hiszen az addigi tartalékból lesz az aktív. Amennyiben az első aktív visszakapcsolódna, akkor amennyiben a preempt funkció engedélyezve volt rajta, akkor azonnal aktív lesz, amennyiben nem, vár a sorára, hogy az lehessen.)
Ügyeljünk a klienseken (PC-ken) a címinformáció kiosztására. Az alábbi példákban végig statikusan konfigurált IP címeket használunk, de kaphatnák ezt DHCP szervertől is. Viszont a DHCP szolgáltatást semmiféleképpen ne az alapértelmezett átjárókat nyújtó forgalomirányítók biztosítsák, hiszen pont azért konfiguráljuk a HSRP-t, hogy ha elveszítjük velük a kapcsolatokat, akkor ne álljon le a forgalom, de egy kiesett DHCP szerver feladatait nem lehet csak úgy átadni egy másiknak. (Gondoljuk el, ha R1 kiosztott egy IP címet, majd kiesik, a bérleti idő leteltével – illetve már korábban – a PC megpróbálja felkeresni, és megújítani a címet. Ha nem találja a szervert, akkor keres egy másikat – legyen ez az R2 – amely viszont nem tudja, hogy R1 milyen címeket osztott már ki. Induláskor meg persze az R1-en és R2-n futó DHCP szolgáltatások közül a gyorsabb győz, erre nem lehet alapozni.)
HSRP alapkonfiguráció
A fentebb leírtakat nézzük meg egy konkrét példán. Adott a következő topológia, amelyben 3 forgalomirányítón (R1, R2, R3) keresztül kapcsolódik a külső hálózathoz (melyet most R4 reprezentál) a LAN hálózatunkból PC1. R1, R2 és R3 PC1 számára nyújtanak redundáns alapértelmezett átjárót a 192.168.1.254 IP címmel. Ezt a címet kell PC1-en, mint alapértelmezett átjáró, beállítani. (A forgalomirányítóknak SW1 felé az fa0/0 interfészeit, SW2 felé az fa0/1 interfészeit használjuk.) A példában mindegyik forgalomirányító az 1-es HSRP csoportban kerül.
Konfiguráljuk a forgalomirányítókon a HSRP protokollt. (A konfiguráció nem tartalmazza az interfészek IP címeinek konfigurációját.)
R1#configuration terminal
R1(config)#interface fa0/0
R1(config-if)#standby 1 ip 192.168.1.254 (A virtuális IP cím)
R1(config-if)#standby 1 priority 150 (A HSRP prioritás az 1-es csoportban)
R1(config-if)#standby 1 preempt (Engedélyezzük a preemption funkciót)
R2#configuration terminal
R2(config)#interface fa0/0
R2(config-if)#standby 1 ip (Elindítjuk a HSRP protokoll)
R2(config-if)#standby 1 priority 100
R3#configuration terminal
R3(config)#interface fa0/0
R3(config-if)#standby 1 ip
R3(config-if)#standby 1 priority 50
R1 fa0/0 interfészén (ez az interfész kapcsolódik PC1 LAN-jához) konfiguráljuk az alapértelmezett átjáró virtuális IP címét (192.168.1.254), a prioritását, valamint a preemption szolgáltatást. R2 és R3 R1-től fogja megtanulni ezt a címet, de a standby 1 ip parancsot ki kell adni rajtuk, hogy a HSRP protokoll elinduljon. Természetesen rajtuk is konfiguráljuk a prioritásukat. A parancsokban szereplő 1-es szám azt jelenti, hogy ezek a forgalomirányítók az 1-es HSRP csoportba tartoznak. (Nem kötelező megadni a csoportszámot, ilyenkor alapértelmezetten a 0-s csoportot veszi.)
A HSRP protokoll állapotát az adott forgalomirányítón a show standby paranccsal lehet lekérdezni. A parancs kimenetéből nagyon sok információ kinyerhető. Láthatjuk, hogy mely HSRP csoportok vannak konfigurálva és melyik interfészen, milyen HSRP szerepben van (aktív, tartalék, figyelő), a virtuális IP cím, a preemption állapota, az aktív és a tartalék forgalomirányító prioritásukkal együtt, és az adott forgalomirányító prioritása.
R1#sh standby
FastEthernet0/0 – Group 1
State is Active
2 state changes, last state change 00:02:38
Virtual IP address is 192.168.1.254
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.212 secs
Preemption enabled
Active router is local
Standby router is 192.168.1.2, priority 100 (expires in 8.704 sec)
Priority 150 (configured 150)
IP redundancy name is “hsrp-Fa0/0-1” (default)
HSRP állapotok
Nézzük meg, hogy a fenti konfigurációban hogyan váltakoznak a szerepek, ha az egyes forgalomirányítók kiesnek (vagyis a LAN interfészüket le- és visszakapcsoljuk). A táblázat első sorai tartalmazza, hogy mely forgalomirányítókon van a preemption funkció bekapcsolva, illetve a virtuális IP cím konfigurálva. Utána az egyes forgalomirányítók kiesésekor, illetve visszatérésekor kialakuló szerepeket láthatjuk.
Mivel R1 a legmagasabb prioritású, rajta definiáltuk az virtuális IP címet, így rögtön magához ragadja az aktív szerepet. R2 másodikként tartalék lesz, míg R3-nak megmarad a figyelő állapot. Amikor R1 kiesik, R2 válik aktívvá, és R3 lép elő a tartalék szerepbe. Amint visszatér R1, a preemption funkció miatt azonnal aktívvá válik, így visszaáll a kezdeti sorrend, vagyis R2 lesz a tartalék, R3 pedig figyel. Amennyiben R2 esik ki, R3 előrelép tartalék szerepbe. Jól látható, a preemption funkció miatt amint lehet, R1 visszaveszi az aktív szerepet. Vegyük észre, hogy amennyiben egy fogalomirányító interfészén fut a HRP, de lekapcsoljuk az interfészt, a HSRP init állapotba kerül.
Most nézzük meg ugyanezt akkor, ha R1-en nem engedélyezzük a preemption funkciót. A kezdeti szerepkiosztás nem változik az előzőhöz képest, de ha R1 kiesik, majd visszatér, nem kapja vissza azonnal az aktív szerepet. Ehhez R2-nek előbb ki kell esnie.
Figyelni kell a konfigurálásnál arra, hogy amennyiben egy forgalomirányítón megadjuk a virtuális IP címet, míg a többin nem, akkor a prioritásától függetlenül ez lesz az aktív, míg a második legnagyobb prioritású a passzív. (Kivéve, ha a legnagyobb prioritásún engedélyeztük a preemption funkciót.) Utána viszont, ha kiesik ez az aktív, akkor természetesen a legnagyobb prioritású veszi át a szerepét, és utána már ténylegesen a prioritás dönti el a szerepeket. (Tehát ha vissza is kapcsolódna, már nem kapná meg az aktív szerepet.) Ezt látjuk a következő táblázatban, ahol ugyan R1 rendelkezik a legnagyobb prioritással, de R2-n definiáltuk a virtuális IP címet, így kezdetben R2 kapja meg az aktív szerepet. Itt most egyik forgalomirányítón sem engedélyeztük a preemption funkciót. Amennyiben R2 kiesik, akkor R1 veszi át természetesen a szerepét, és R3 lép elő tartaléknak. R2 visszatérésekor viszont R1 megmarad aktív szerepben, R2 pedig visszaveszi a tartalék szerepet R3-tól.
Végezetül nézzük meg az előző esetet úgy, hogy R1-en engedélyeztük a preemption funkciót. Ilyenkor mindegy, hogy a virtuális IP-t R2-n engedélyeztük, annak megtanulása után R1 azonnal magához veszi az aktív szerepet.
Azt láthattuk, hogy a HSRP különböző állapotokat vesz fel a működése során. Foglaljuk most össze ezeket, pár új állapotot is bevezetve:
Initial (kezdeti) állapotban kerül a HSRP, amikor éppen elindul egy interfészen, vagy amikor a HSRP interfészt lekapcsoljuk.
Learn (tanuló) állapotba kerül a HSRP, amikor még nem rendelkezik a virtuális IP címmel, és várja azt a Hello üzenetet az aktív forgalomirányítótól, melyben megkapja annak értékét.
Listen (figyelő) állapotban a forgalomirányító már rendelkezik a virtuális IP címmel, de se nem aktív, se nem tartalék állapotba nem került.
Speak (beszélő) állapotban a forgalomirányító éppen az aktív vagy tartalék forgalomirányító megválasztásában vesz részt.
Standby (tartalék) állapotban a forgalomirányító az aktív forgalomirányító Hello üzeneteit figyeli, és amennyiben ez a forgalomirányító kiesik, átveszi a szerepét.
Active (aktív): A forgalomirányító továbbítja a HSRP csoportba érkező adatokat, és küldi a Hello üzeneteket.
HSRP időzítők
A HSRP működése során három időzítőt használ:
Az aktív időzítő (active timer) az aktív forgalomirányító felügyeletére szolgál. Mindig akkor indul el, amikor az aktív forgalomirányító egy Hello üzenetet fogad. A Hello üzenetben szereplő tartási idő (hold time) értékének megfelelően jár le.
A tartalék időzítő (standby timer) a tartalék forgalomirányító felügyeletére szolgál. Mindig akkor indul el, amikor a tartalék forgalomirányító egy Hello üzenetet fogad. A Hello üzenetben szereplő tartási idő (hold time) értékének megfelelően jár le.
A Hello időzítő (hello timer) a Hello üzenetek időzítésére szolgál. Amikor lejár, a HSRP forgalomirányítók Hello üzenetet küldenek.
Amikor egy forgalomirányítótól a tartási időnek megfelelő időtartamon keresztül nem fogad a többi Hello üzenetet, akkor azt a forgalomirányítót kiesettnek tekintik. A Hello időzítő alapértelmezett értéke 3, míg a tartási időé 10 másodperc. A beállítható tartomány mindkettő esetében 1-255 másodperc. A Hello és a tartási idő értékének a konfigurálása a standby [group-number] timers hellotime holdtime paranccsal történhet. (Pl. standby 1 timers 2 6)
Preemption késleltetés (preemption delay)
Mint láttuk, a preemption funkció engedélyezése esetén az éppen legmagasabb prioritással rendelkező forgalomirányító azonnal átveszi az aktív szerepet, vagyis nem várja meg, hogy az éppen aktív kiessen. Ez a gyors átkapcsolás azonban nem mindig szerencsés, ugyanis amikor a forgalomirányító adott interfésze visszakapcsolódik (vagy felkapcsolódik egy újraindítás során), a forgalomirányító irányítótáblájában még nem szerepel minden bejegyzés, azokat ezután fogja megtanulni az irányító protokolloktól. Vagyis célszerű késleltetéssel átvenni az aktív szerepet. Ezt nevezzük preemption késleltetésnek, mely a standby preempt delay minimum delaytime paranccsal konfigurálható, ahol a késleltetést másodpercben kell megadni a 0-3600 tartományból. (Pl. standby preempt delay minimum 300) Amennyiben csak a forgalomirányító újraindulása után (tehát amikor először kapcsolódik fel a HSRP interfész) szeretnénk a késleltetést, akkor a minimum kulcsszó helyett a reload-ot kell használni. (Pl. standby preempt delay reload 360). A két érték együtt is megadható. (standby preempt delay minimum 300 reload 360)
Interfészkövetés (Interface Tracking)
Azt már láthattuk, hogy a HSRP protokoll nagyon jól kezeli, ha a redundáns forgalomirányítók LAN interfésze kiesik. De mi történik, ha a WAN (vagy egy uplink) interfész esik ki? Ilyenkor a forgalomirányítók zavartalanul küldik a LAN-on keresztül a többieknek a Hello üzeneteket, így nem fogja senki átvenni az aktív szerepet, noha a LAN forgalmát nem képes továbbítani.
Erre a problémára nyújt megoldást az interfész követés úgy, hogy megadhatjuk egy forgalomirányítón, ha egy interfésze kiesik, akkor mennyivel csökkentse a HSRP prioritását, lehetőséget adva ezáltal a tartalék forgalomirányítónak, hogy átvegye az aktív szerepet. Természetesen ehhez az is szükséges, hogy a tartalék forgalomirányítón engedélyezzük a preemption funkciót, hiszen különben megvárná, míg a tartaléktól nem kapna Hello üzeneteket (vagyis a LAN interfész kiesését.) Természetesen, ha a kiesett interfész visszakapcsolódik, a prioritás is visszaáll az eredeti értékére.
Az interfészkövetés konfigurálása nagyon egyszerű. A standby track parancsban csupán a követendő interfészt kell azonosítanunk, valamint meg kell adnunk, hogy mennyivel csökkentse a prioritást, ha kiesik ez az interfész. Legyen például a követendő interfész R1-en a Fastethernet1/0, és csökkentsük a fenti példának megfelelően 60-nal a prioritást:
R1#(config)#int fa0/0
R1#(config-if)#standby 1 track Fastethernet1/0 60
Ezután ha lekapcsoljuk R1 fa0/1 interfészét, akkor láthatjuk, R2 átveszi az aktív szerepet.
R2#sh standby | i State
State is Active
R1#sh standby | i State
State is Standby
R1 prioritását lekérdezve láthatjuk, hogy 90-re változott, de mutatja a parancs kimenete, hogy eredetileg 150-re volt konfigurálva, és a követett interfész Down állapota csökkentette 60-nal.
R1#sh standby | s Priority
Priority 90 (configured 150)
Track interface FastEthernet0/1 state Down decrement 60
Hitelesítés
Mint minden hálózati protokollal, a HSRP-vel is vissza lehet élni. A támadónak semmi mást nem kell csinálnia, mint a LAN hálózathoz csatlakoztatni egy újabb forgalomirányítót, beállítania a virtuális IP címet, megfelelően nagyra kell állítania a prioritását, bekapcsolnia a preemption funkciót, és máris rajta keresztül áramlik a LAN más hálózatokba irányuló forgalma. Ezt lehet megakadályozni a HSRP hitelesítés konfigurálásával. Pontosabban szólva a HSRP protokoll alapértelmezetten mindig hitelesít egy titkosítatlan alapértelmezett jelszóval. Az alapértelmezett jelszó kiolvasható a Hello csomagokból: ez a cisco.
Ez a jelszó megváltoztatható a standby authentication paranccsal. (A jelszót természetesen minden, az adott csoportba tartozó HSRP forgalomirányítón be kell állítani, különben hibajelzést kapunk.)
R1#(config)#int fa0/0
R1#(config-if)#standby 1 authentication jelszo
Ha mi ilyen könnyedén le tudjuk olvasni a jelszót, akkor persze ezt a támadó is megteheti. Érdemes ezért kivonatolt hitelesítést választani. Ehhez a parancsot az md5 key-string kulcsszóval kell kiegészíteni. (Maximum 64 karakter hosszú jelszó adható meg.)
R1#(config)#int fa0/0
R1#(config-if)#standby 1 authentication md5 key-string jelszo
Ilyenkor már nem lehet kiolvasni az elfogott hálózati adatokból a jelszót:
A jelszót key-string helyett key-chain-ben (kulcsláncban) is tudjuk tárolni a HSRP jelszavakat. Egy kulcsláncban több jelszó (key-string) is tárolható, és időzíthető, hogy mikor, melyiket használjuk. Tegyük fel, hogy a biztonsági házirend előírja, hogy minden hónap első napján 0 órakor meg kell változtatni a HSRP forgalomirányítókon a jelszót. Ilyenkor nem kell a rendszergazdának a terminál ablaka előtt ülni éjszaka az új jelszavak beállítása miatt, hanem fel lehet venni egy kulcsláncba minden hónap jelszavát előre, és minden jelszóhoz be lehet állítani, hogy mikor aktiválódjon. (Persze célszerű a forgalomirányítók óráit összehangolni, de hát erre való az NTP protokoll.)
Nézzük meg most ezt két hónapra (január és február). A kulcsláncunkat hsrp_kulcsok-nak nevezzük, mely két kulcsot tartalmaz, a 0-s és 1-es azonosítóval. A 0-s a januári, az 1-es a februári jelszót. A két megadott időintervallum a kulcsoknál a kulcs elfogadásának és elküldésének időtartamát adja meg. (A kipróbáláshoz ne feledjük beállítani valamelyik időtartamra a forgalomirányítókon az órát és a dátumot.)
R1#configure terminal
R1(config)#key chain hsrp-kulcsok
R1(config-keychain)#key 0
R1(config-keychain-key)#key-string jelszo_januar
R1(config-keychain-key)#accept-lifetime 00:00:00 Jan 01 2018 23:59:59 Jan 31 2018
R1(config-keychain-key)#send-lifetime 00:00:00 Jan 01 2018 23:59:59 Jan 31 2018
R1(config-keychain-key)#key 1
R1(config-keychain-key)#key-string jelszo_februar
R1(config-keychain-key)#accept-lifetime 00:00:00 Jan 01 2018 23:59:59 Jan 31 2018
R1(config-keychain-key)#send-lifetime 00:00:00 Feb 01 2018 23:59:59 Feb 28 2018
Ezt a kulcsláncot adjuk meg aztán a hitelesítés konfigurációjában:
R1(config)#int fa0/0
R1(config-if)#standby 1 authentication md5 key-chain hsrp-kulcsok
R2(config)#int fa0/0
R2(config-if)#standby 1 authentication md5 key-chain hsrp-kulcsok
Terhelésmegosztás HSRP csoportok segítségével
A HSRP protokoll alapvetően nem alkalmas terhelésmegosztásra, vagyis egy aktív és egy tartalék (vagy figyelő) forgalomirányító nem képes egyszerre a hosztok forgalmát továbbítani. A HSRP csoportok alkalmazásával viszont elérhetjük, hogy a hosztok egyik felének forgalmát az egyik, míg a hosztok másik felének forgalmát a másik forgalomirányító továbbítsa.
Tegyük fel, hogy a 192.168.1.0/24 hálózat forgalmát két forgalomirányító (R1 és R2) továbbítja. A forgalomirányítók az alapértelmezett átjárót a HSRP protokoll segítségével állítják elő. Mindkét forgalomirányítón konfiguráljuk 2-2 HSRP csoportot (Legyen ez az 1-es és a 2-es.) Az 1-es csoportban az alapértelmezett átjáró virtuális IP címe 192.168.1.254, a 2-es csoportban 192.168.1.253 legyen. R1 prioritása az 1-es csoportban 150, míg a 2-es csoportban 100. R2-n fordítva, az 1-es csoportban 100, míg a 2-es csoportban 150. Vagyis az 1-es csoportban az aktív forgalomirányító R1 lesz, a 2-es csoportban R2. A hosztok felénél a 192.168.1.254-et, a másik felénél a 192.168.1.253-at állítjuk be. Amikor mindkét forgalomirányító működik, akkor a hosztok egyik fele R1-en, a másik fele R2-n halad át.
Amikor R2 kiesik, akkor R1 veszi át a 2-es csoportban is az aktív szerepet, ilyenkor értelemszerűen nincsen terhelésmegosztás. Vegyük észre, ilyenkor R1 mind a két (.253 és .254) virtuális IP címre érkező forgalmat továbbítja.
Amikor R1 esik ki, akkor fordítva, R2 lesz aktív mindkét csoportban:
A forgalomirányítók konfigurációja:
R1#configuration terminal
R1(config)#interface fa0/0
R1(config-if)#standby 1 ip 192.168.1.254
R1(config-if)#standby 1 priority 150
R1(config-if)#standby 1 preempt
R1(config-if)#standby 2
R1(config-if)#standby 2 priority 100
R2#configuration terminal
R2(config)#interface fa0/0
R2(config-if)#standby 1 ip
R2(config-if)#standby 1 priority 100
R2(config-if)#standby 2 ip 192.168.1.253
R2(config-if)#standby 2 priority 150
R2(config-if)#standby 2 preempt
A terhelésmegosztás esetén is előkerül a DHCP problémája. Az eddig megtanult módon a DHCP szerver nem képes különböző PC-knek különböző alapértelmezett átjárókat kiosztani. (Van rá lehetőség, de akkor a DHCP szerverbe minden PC-t külön-külön be kell jegyezni a MAC címével, és azok szerint osztani a címinformációkat.)
Természetesen nem csak a HSRP protokollal lehet a redundáns alapértelmezett átjárók problémáját megoldani, rendelkezésünkre állnak még többek között a VRRP (Virtual Router Redundancy Protocol) és a GLBP (Gateway Load Balancing Protocol) protokollok is.
A HSRP verziói
A HSRP-nek 2 verziója van, az 1-es és a 2-es. A Cisco forgalomirányítók alapértelmezetten a HSRP 1-es verzióját használják, a fentiekben mi is ezt konfiguráltuk. A verzió közötti váltásra a standby version {1|2} parancs szolgál. A két verzió között a következő három lényegesebb különbség van:
- A 2-es verzió az 1-eshez képest az időzítők értékét már milliszekundumban hirdeti.
- Míg az 1-es verzió maximum 256 csoportot (0-tól 255-ig) tudott kezelni, addig a 2-es már 4096-ot (0-tól 4095-ig).
- Az 1-es verzió a 224.0.0.2-es csoportcímet használja, míg a 2-es a 224.0.0.102-est. Erre a változtatásra azért volt szükség, mert a Cisco Group Management Protocol is a 224.0.0.2-t használja.
