|
|
||
|
|
HSRP v1 |
Ultima revisione: 20 Agosto 2023 |
|
Introduzione Un modo di aumentare efficacemente l'affidabilita' di una rete consiste nel ridondarne gli apparati che ne compongono il core. In particolare in questo articolo consideriamo come esempio topologie in cui differenti router si contendono il ruolo di gateway di rete. Poiche' apparati diversi in una stessa VLAN devono avere indirizzi L3 necessariamente differenti non possiamo di certo assegnare uno stesso indirizzo IP a diversi router per ridondare il gateway pertanto e' stato necessario ideare un meccanismo che consentisse di utilizzare per PC e server un unico indirizzo L3 di gateway di rete in grado di spostarsi da un apparato router ad uno differenti al verificarsi di determinate condizioni. HSRP consente di configurare indirizzi IP virtuali svincolati dalla singola interfaccia fisica e di associarli invece a piu' interfacce di due o piu' dispositivi differenti. HSRP e' un protocollo Cisco supportato dai router Cisco. Il protocollo VRRP ne e' un'evoluzione e rappresenta la standardizzazione di HSRP di cui condivide il principio di funzionamento. Il protocollo GLBP ne e' un'evoluzione e supporta il load-balancing tra apparati. HSRPv1 e' RFC2281 Marzo 1998. VRRP e GLBP Un accenno al Gateway Load Balancing Protocol (GLBP). E' l'evoluzione di HSRP e VRRP in quanto permette il load-balancing tra apparati. Quindi in un gruppo piu' di un apparato puo' essere attivo. Un singolo apparato (chiamato AVG) risponde alla richieste ARP inviate dalle end station di una rete che sono alla ricerca del MAC del gateway. AVG risponde in modo differente ad ogni richiesta ovvero risponde con mac-address differenti a richieste che ARP relative sempre ad un unico IP. Ci sono varie modalita' per rispondere alle richieste ARP: round-robin (default), in base al mac dell'host (ad ogni host si risponde sempre con lo stesso MAC), oppure pesato. Quest'ultima modalita' e' molto utile perche' daremo piu' peso ai router che dispongono di una maggiore banda dati lato WAN.
Con il protocollo Hot Standby Router Protocol (HSRP) un router R1, gateway di una rete, ha uno o piu' router gemelli che possono fungere da backup in caso di guasto, diciamo due per semplicita'. La presenza di due possibili gateway nella rete, per esempio due router Cisco con IOS, in circostanze normali ci costringe ad assegnare due indirizzi IP distinti alle loro interfacce ethernet. Questo implica che, per avere ridondanza, dovremmo delegare i server di rete a gestire gateway multipli correttamente. Questa scelta, se pur possibile, e' comunque fortemente limitata dalla variegata' diversita' di dispositivi di rete possibili che devono avere accesso all'esterno della rete. Tolti casi specifici dev'essere responsabilita' della rete switched/routed di una LAN il garantire l'accesso continuativo alle risorse ai client di rete. Con HSRP i due router R1 e R2 hanno un
indirizzo fisico di rete distinto ma si definisce un terzo
indirizzo virtual IP con un Virtual MAC Address che
si utilizzera' come gateway di riferimento per le end stations di
rete. Tale IP sara' quindi virtuale, ovvero assegnato al router
attivo, e passato dal primo router al secondo in caso di guasto,
e viceversa. Ogni router manterra' il suo indirizzo IP fisico e
permanente. HSRP e topologia di rete – dual brain - Come possiamo raggiungere il massimo
livello di uptime utilizzando in una rete HSRP?
Il caso (2) e' molto interessante perche' porta ad una condizione nota come dual-brain. I due apparati ridondati non comunicano piu' tra loro per cause terze, ad esempio perche' sono collegati a due switch che per un problema tecnico non comunicano a loro volta tra loro, e quindi entrambi pensano che l'altro abbia un guasto ed entrambi diventano active. Collegare due router R1 e R2 back-to-back quale canale per evitare problemi di dual-brain non e' risolutivo e normalmente e' inutile per questo scopo. Se entrambi i router sono in ACTIVE il fatto che il collegamento back-to-back sia attivo non cambia il comportamento di HSRP. Puo' fare solo comodo come path alternativo lato WAN nel caso di collegamenti WAN di performance molto differenti tra i due router. Un router ACTIVE ma a priorita' inferiore potrebbe utilizzarlo per raggiungere un link WAN in alcuni casi. Se vogliamo coprire casi come questi dobbiamo creare una topologia di rete che limiti al massimo queste condizioni.
Una bella configurazione consiste nel configurare un ether-channel LACP tra i due router R1 e R2 e due switch SW1 e SW2 magliati in configurazione stack. In questo modo non ci puo' essere un singolo guasto che interrompa il servizio di rete. E' chiaro che qui ci stiamo preoccupando solo del lato LAN ma ogni router lato WAN dovra' essere in condizione di dare un servizio, ad esempio Internet, in autonomia. Tuttavia lato WAN ci sono problematiche differenti da gestire.
Configurazione Ecco i comandi principali utilizzati in una tipica configurazione di HSRP: standby [group-number
0-255] ip ip-address [secondary] Supponendo di avere due router Cisco con SO di tipo IOS, in questo esempio due 2800, diciamo 2800-A e B, segue questa configurazione di esempio: interface
FastEthernet0/0 L'indirizzo fisico e' 192.168.30.10. Supponiamo che il 2800-B abbia indirizzo fisico 192.168.30.11. Il comando standby abilita HSRP. L'indirizzo 192.168.30.1 e' quello che va impostato come gateway sulle end stations di rete. I router di un gruppo comunicano tramite l'indirizzo multicast 224.0.0.2, sono UDP con porta 1985. Il valore di priorita' definisce il router che ha precedenza sugli altri per acquisire l'indirizzo virtuale che e' 192.168.30.1. Il comando priority definisce una priorita' dove vince il valore piu' alto. Nel caso due router abbiano la stessa priorita' l'interfaccia con IP piu' alto diventa Active. Ma chi ha priorita' maggiore non necessariamente detiene l'indirizzo l'IP virtuale. Per capire meglio il problema dobbiamo introdurre il concetto di preempt. Configurazione: preempt Supponiamo che 2800A abbia priorita' maggiore e quindi detiene l'indirizzo virtuale. Se 2800A va offline l'indirizzo virtuale passa a 2800B. Cosa succede quando 2800A rientra in servizio? Senza preempt 2800B continuerebbe a detenere l'indirizzo IP virtuale. In caso di preempt invece l'indirizzo tornera' su 2800A. Con il comando preempt si puo' quindi forzare un router come primario “in ogni caso”. Da RFC: “If a router has higher priority than the active router and preemption is configured, it MAY take over as the active router using a Coup message. Coup messages are sent when a router wishes to become the active router. Resign messages are sent when a router no longer wishes to be the active router. “ Se abbiamo due router basta configurare il comando preempt in quello a priorita' maggiore in quanto quello con priorita' minore essendo gli apparati solo due non potra' vantare un preempt nei confronti di nessuno se e' active. In alcune circostanze potremmo volere che il router a priorita' maggiore NON faccia preempt. In una topologia con tre router in HSRP con le stesse performance potremmo benissimo decidere di restare su un router di backup anche dopo che quello a priorita' maggiore torna online e delegare all'amministratore di rete una verifica e la rimessa in active del router a priorita' maggiore. Questo potrebbe aumentare l'affidabilita' di una rete infatti potremmo evitare condizioni in cui un router malfunzionante faccia reboot ogni 10minuti, tanto per fare un esempio.
Configurazione: track L'ultima riga di
configurazione contiene il subcomando track. Questo
consente di variare la priorita' di un router a seconda dello
stato delle sue interfacce. Ad esempio se l'interfaccia WAN
(nell'esempio Fa0/1) del 2800-A va in down allora il valore di
priorita' del router scende di 10 punti (default) portandolo a
95. A questo punto vogliamo che il router 2800-B diventi Active.
Ma questo non e' automatico. Infatti il router B vedra' il router
A sempre attivo, ma con priorita' minore. Non ci sara' nessun
passaggio, a meno che non ci sia il comando preempt nel router B,
che gli faccia prendere il controllo. Configurazione: timers Secondo quale criterio un router con HSRP classifica come off-line gli altri router del suo gruppo e dopo quanto tempo? Le porte di uno stesso gruppo hanno un valore di hello time pari a 3 secondi. Se per un valore pari a hold time non arrivano i pacchetti di hello il router mittente viene considerato in fault. Questi parametri sono settabili. Si deduce che di default sono necessari almeno 10 secondi per passare da un router all'altro in caso di assenza di hello packets ma questo tempo puo' variare a seconda della configurazione di HSRP e della topologia di rete. Nota: lato switch configurare il portfast sullo spanning tree dalle porte verso i router. Questo potrebbe prendere anche 30sec circa per attivare la porta, un tempo superiore ai 10sec di timeout dell'HSRP, e e quindi puo' creare dei delay. Potete usare, se disponibile, il comando "set spantree portfast enable". E' consigliabile disabilitare tutte le feature avanzate di STP come UplinkFast e BackboneFast. Configurazione: monitoraggio ed esempi con Cisco IOS routers Per finire ecco dei comandi per il monitoring e il debugging: Router#show
standby Router#sh run int
eth0 Non si possono usare classi differenti in un gruppo HSRP altrimenti si ha questo errore: 7200_A#show
standby come si vede a causa di questo errore HSRP non funziona. Esempio 2
ROUTER B interface gigabitethernet
4/0/0
ROUTER C interface gigabitethernet
4/0/0 Esempio 2 – Cisco serie ASR1000 con IOS-XR ASR1002-B
ASR1002_B#show
standby
ASR1002_B_GENESYS#debug standby
HSRP e bridge group – BVI - E' possibile configurare HSRP in una interfaccia BVI. In questo esempio abbiamo una ridondanza anche a livello di link ethernet fisico che possiamo gestire in quanto una delle due interfacce ethernet andra' in blocking grazie a STP come si vede a seguire:
3800A# show standby HSRP e BGP Le sessioni BGP non funzionano correttamente se la sessione e' fatta utilizzando un IP di HSRP. Quindi non possiamo utilizzare HSRP per ridondare una sessione BGP. |
||
|
|
Copyright 2002-2023 – Gianrico Fichera – Il
materiale di questa pagina non e’ sponsorizzato o sottoscritto
da Cisco Systems, Inc. Ciscoâ
e’
un trademark di Cisco Systems, Inc. negli Stati Uniti e in altri
stati. L’autore di questa pagina non si assume nessuna
responsabilita’ e non da nessuna garanzia riguardante
l’accuratezza e la completezza delle informazioni presenti
nonche’ da conseguenze sull’uso delle informazioni presenti
in questa pagina. |
This material is not sponsored by, endorsed by, or affiliated with Cisco Systems, Inc., Cisco, Cisco Systems, and the Cisco Systems logo are trademarks or registered trade marks of Cisco Systems, Inc. or its affiliates. All other trademarks are trademarks of their respective owners. |