HSRP (Hot Standby Router Protocol), proprietar Cisco, sau VRRP, standard IETF, si GLBP, proprietar Cisco, sunt protocoale cu ajutorul carora asiguram redundanta, chiar si load-sharing in cazul GLBP, pentru echipamentul folosit ca si “default gateway”. Ele sunt numite generic First Hop Redundancy Protocols (FHRP).
Nu intru in detaliile de functionare ale fiecarui protocol, in schimb voi prezenta o solutie practica cu care m-am intalnit recent: HSRP folosit impreuna cu protocolul de rutare BGP / influentarea protocolului HSRP de catre starea unei sesiuni BGP.
Aceasta este topologia solutiei:
Fizic este o topologie simpla conceputa pentru a asigura Clientului un acces redundant, atat Layer1/2, cat si Layer 3, la serviciile Service Provider-ului.
Am folosit HSRPv2 pe cele doua CPE-uri penrtu a asigura redundanta default gateway-ului configurat in SVI-ul 1800, SVI acces client.
De ce versiunea 2 si nu versiunea 1? Iata cateva argumente pro versiunea 2, primele 3 fiind cele mai importante:
- pot folosi autentificare MD5;
- pot folosi grupuri HSRP mai mari decat 255, intre 0 si 4095, ceea ce imi permite, cand vreau sa asigur, de exemplu, redundanta default gateway-ului in SVI-ul 1800, sa configurez grupul HSRP cu acelasi numar, 1800, pentru o investigare mai rapida a posibilelor probleme ce pot aparea in viitor;
- atat timpii mai mari de o secunda, cat si timpii mai mici de o secunda (Hello Time, Hold Time), sunt anuntati si invatati automat; pot astfel sa configurez timpii protocolului HSRP doar pentru echipamentul definit initial ca si HSRP Active, astfel am mai putine linii in fisierul de configurare;
- mesajele specifice HSRP sunt trimise in versiune 2 catre destinatia 224.0.0.102, pe cand in versiunea 1 sunt trimise catre destinatia 224.0.0.2, “All Multicast Routers”; daca folositi protocolul proprietar Cisco CGMP, protocol Layer 2, atunci ar putea aparea probleme pentru ca si mesajele acestuia, mesajele de tip “Leave”, sunt trimise tot cate destinatia 224.0.0.2.
Am folosit protocolul eBGP pe cele doua CPE-uri pentru a primi prefixele la care Clientul trebuie sa aiba acces. Ambele sesiuni BGP sunt configurate identic si anunta concomitent aceleasi prefixe.
Am folosit urmatorii timpi pentru protocolul HSRP:
- Hello: 2 secunde;
- Hold: 10 secunde;
- Preempt: 120 secunde.
Router-ul CPE1 este configurat ca si HSRP Active (are configurata Prioritatea HSRP 120) si isi pierde acest statut daca si numai daca se intampla oricare dintre urmatoarele evenimente:
- legatura intre Service Provider si CPE1 devine nefunctionala, “line protocol down”;
- sesiunea BGP dintre Serivce Provider si CPE1 devine nefunctionala, stare “Down”;
- mesajele HSRP nu mai pot fi trimie intre cele doua CPE-uri, unul dintre cele doua switch-uri din stack devine nefunctional sau/si oricare legatura dintre CPE si stack devine nefunctionala.
Utima situatie este detectata automat de catre protocolul HSRP in maxim 10 secunde (Hold Time), moment in care cele doua CPE-uri devin izolate, fiecare se va crede HSRP Active, insa numai unul dintre ele va mai avea conectivitate catre Client. Client-ul va resimti un downtime de maxim 10 secunde.
HSRP nu detecteaza automat celelalte doua probleme, astfel trebuie sa gasim solutii pentru ele.
Pentru ca, atunci cand legatura dintre Service Provide si oricare dintre CPE devine nefunctionala, CPE-ul care pierde legatura sa piarda si statutul de HSRP Active trebuie sa folosim comanda “track”. Cu ajutorul acesteia, daca starea legaturii va deveni “line protocol down”, atunci starea grupului va fi fortata in INIT, grupul HSRP devenind astfel inactiv, pierzand atat statutul de HSRP Active, cat si statutul de HSRP Standby.
Pentru a evita ca un flap rapid al interfetei catre Service Provider sa provoace schimbarea router-ului HSRP Active (instabilitate), comanda “track” este configurata cu optiunea “delay”, a carei valoare am configurat-o 2 secunde; ignor o schimbare de stare a interfetei catre Service Provider mai rapida decat 2 secunde.
Cat credeti ca va fi, in cazul configuratiei prezentate mai jos, downtime-ul sesizat de catre Client in cazul in care legatura catre Service Provider a CPE1 devine inactiva (“line protocol down”)?
Monitorizarea starii sesiunii BGP ne solicita un pic pentru ca nu putem avea un prefix de control trimis tot timpul pe ambele sesiuni BGP pe care sa configuram “track” si a carui prezenta/lipsa din tabela de rutare sa influenteze starea HSRP a fiecarui CPE.
Am gasit ca si solutie folosirea “Cisco IOS Embedded Event Manager (EEM)”. Cu ajutorul EEM monitorizez mesajele de tip log (logging buffered) si la aparitia mesajului “neighbor x.x.x.x Down .*” (protocolul BGP trebuie sa aiba configurat “bgp log-neighbor-changes”) consider sesiunea BGP cu neighbor-ul x.x.x.x ca fiind nefunctionala si micsorez prioritatea HSRP, influentand astfel o realegere a router-ului HSRP Active.
Iata care sunt liniile ce compun configuratia acestui serviciu:
Configuratie CPE1
! GigabitEthernetX este interfata catre Service Provider, CPE1
track 1 interface GigabitEthernetX line-protocol
delay down 2 up 2
!
! SVI-ul Acces pentru Client pe CPE1
!
interface Vlan1800
description Client
ip address 172.17.1.2 255.255.255.0
load-interval 30
standby version 2
! 172.17.1.1 este Default Gateway pentru Client
standby 1800 ip 172.17.1.1
standby 1800 priority 120
standby 1800 timers 2 10
standby 1800 preempt delay minimum 120
standby 1800 authentication md5 key-string 7 10663A2B355A465A5D
standby 1800 name HSRP-1800
standby 1800 track 1 shutdown
!
! Cisco EEM CPE1
!
event manager applet ServiceProvider-BGP-DOWN
event syslog pattern "neighbor x.x.x.x Down .*"
! action 1.1 scrie mesajul "BGP Nei x.x.x.x : Down -> Decrease HSRP Prio to 50" in log (logging buffered)
action 1.1 syslog msg "BGP Nei x.x.x.x : Down -> Decrease HSRP Prio to 50"
action 2.1 cli command "enable"
action 2.2 cli command "conf t"
action 2.3 cli command "interface vlan 1800"
action 2.4 cli command "standby 1800 priority 50"
!
event manager applet ServiceProvider-BGP-UP
event syslog pattern "neighbor x.x.x.x Up .*"
! action 1.1 scrie mesajul "BGP Nei x.x.x.x : Up -> Increase HSRP Prio to 120" in log (logging buffered)
action 1.1 syslog msg "BGP Nei x.x.x.x : Up -> Increase HSRP Prio to 120"
action 2.1 cli command "enable"
action 2.2 cli command "conf t"
action 2.3 cli command "interface vlan 1800"
action 2.4 cli command "standby 1800 priority 120"
!
Configuratie CPE2
! GigabitEthernetY este interfata catre Service Provider, CPE2
track 1 interface GigabitEthernetY line-protocol
delay down 2 up 2
!
! SVI-ul Acces pentru client pe CPE2
!
interface Vlan1800
description Client
ip address 172.17.1.3 255.255.255.0
load-interval 30
standby version 2
! 172.17.1.1 este Default Gateway pentru Client
standby 1800 ip 172.17.1.1
! Valoarea "priority" este implicit 100
standby 1800 priority 100
standby 1800 preempt delay minimum 120
standby 1800 authentication md5 key-string 7 10663A2B355A465A5D
standby 1800 name HSRP-1800
standby 1800 track 1 shutdown
!
! Cisco EEM CPE2
!
event manager applet ServiceProvider-BGP-DOWN
event syslog pattern "neighbor y.y.y.y Down .*"
! action 1.1 scrie mesajul "BGP Nei y.y.y.y : Down -> Decrease HSRP Prio to 50" in log (logging buffered)
action 1.1 syslog msg "BGP Nei y.y.y.y : Down -> Decrease HSRP Prio to 50"
action 2.1 cli command "enable"
action 2.2 cli command "conf t"
action 2.3 cli command "interface vlan 1800"
action 2.4 cli command "standby 1800 priority 50"
!
event manager applet ServiceProvider-BGP-UP
event syslog pattern "neighbor y.y.y.y Up .*"
! action 1.1 scrie mesajul "BGP Nei y.y.y.y : Up -> Increase HSRP Prio to 100" in log (logging buffered)
action 1.1 syslog msg "BGP Nei y.y.y.y : Up -> Increase HSRP Prio to 100"
action 2.1 cli command "enable"
action 2.2 cli command "conf t"
action 2.3 cli command "interface vlan 1800"
action 2.4 cli command "standby 411 priority 100"
!
De ce credeti ca am folosit “standby preempt” pe ambele CPE-uri? Este folositor, sau puteam sa il folosesc doar pe CPE1?
Enjoy!
Fara standby preempt routerul nu se pune active router chiar daca are prioritate mai buna. Deci daca foloseai doar pe CPE1 , cind CPE1 isi schimba prioritatea si anunta “may preempt” CPE2 nu ar fi devenit activ chiar daca avea prioritatea mai buna. Invers ar fi functionat, daca CPE2 (ca router activ fara standby preempt setat) si-ar fi scazut prioritatea , CPE1 ca standby router cu preempt setat ar fi facut takeover de la CPE2. Deci failoverul ar fi functionat doar intr-un singur sens.Dar in configuratia de mai sus, daca doar CPE1 ar fi avut standby preempt setat, configuratia nu ar fi functionat, deoarece CPE2 fara preempt nu ar fi facut takeover.
@DragosV Cand CPE1, router-ul cu prio mai mare si initial HSRP Active, devine dupa o perioada de inactivitate iar disponibil, daca are Preempt configurat trimite un mesaj “Coup”. Dupa expirarea Hold Timer este luat in considerare Preempt de catre CPE2. Dupa ce expira timpul definit prin Preempt, CPE2 trimite un mesaj “Resign” si CPE1 redevine HSRP Active (CPE1 isi recastiga starea de HSRP Active in aproximativ Hold Timer + Preempt Delay).
In momentul in care CPE1 devine indisponibil, CPE2 devine HSRP Active dupa expirarea Hold Timer-ului => Clientul poate sesiza un downtime in jurul valorii Hold Timer in momentul in care CPE1 devine indisponibil.
Practic Preemp Delay isi face treaba numai in cazul in care este configurat pentru router-ul ales de noi sa fie HSRP Activ.
Schema de comunicatie este asa cum zici tu. Eu spun doar ca rolul functiei preempt este ca atunci cind un router cu o prioritate mai mare revine din starea de inactivitate sa poate sa redevina active router. Fara preempt setat, odata ce un router isi pierde rolul de active router nu se mai face active chiar daca are prioritate mai buna. Fara preempt se poate face active router doar daca routerul active nu mai trimite hello packets (si cum zici tu dupa expirarea holdtimer-ului.
misto solutia cu EEM, dar nu e mai simplu sa bagi un eigrp pe lan in loc de hsrp?
@robert nu inteleg exact unde te gandesti sa folosesti EIGRP, te rog spune mai multe detalii.
Am putea duce mai departe solutia si sa ne gandim ca putem folosi un link direct intre cele doua CPE-uri, link peste care configuram iBGP. In acest caz scap de problema sincronizarii HSRP cu ceea ce se intampla in reteaua dinspre SP, dar pierd in acelasi timp si placerea de a folosi EEM 🙂