Esperienza su Virtual Router Redundancy Protocol (VRRP)
Esperienza su Virtual Router Redundancy Protocol (VRRP) |
|
|
|
Per la realizzazione di questo modulo useremo
Netkit4TIC.
Scarica il tarball (100KB)
contenente la configurazione e lo script lab per la
costruzione dell'esperienza.
La realizzazione di reti ad alta affidabilità si attua adottando percorsi ridondati e duplicazioni di apparati di reti ma questo può non essere sufficiente soprattutto per quanto riguarda i nodi finali. Infatti in questi nodi viene configurato staticamente un defalt gateway che nel caso si guasti isola di fatto la stazione. Questioni di sicurezza, semplicità di configurazione e consumo di risorse sconsigliano l'utilizzo di protocolli di routing dinamici in queste stazioni. Da alcuni anni sono state proposte delle soluzioni che si chiamano HSRP e il suo derivato VRRP. Per una trattazione completa si rimanda al libro "Switched LAN" di Baldi e Nicoletti, Mc-Graw-Hill Italia Associates capitolo 7 pagina 216 e oltre.
L'implementazione di VRRP che utilizziamo è quella realizzata dal pacchetto keepalived disponibile sia in Debian che in LEAF/Bering uClibc. In particolare l'esperienza è basata su quest'ultima distribuzione.
Per la documentazione di questa implementazione ci sono due ottimi riferimenti:
Per l'utilizzo del pacchetto kpalived.lrp occorre
specificare nel file di configurazione leaf.cfg,
oltre a kpalived stesso, i pacchetti di cui ha bisogno:
libpopt.lrp libssl.lrp libcrpto.lrp.
Nella mappa
(pdf,
xml)
della rete dell'esercizio viene simulata una LAN (192.168.42.0/24)
connessa ad una WAN (192.168.43.0/24) tramite una coppia di router
in cui è configurato il VRRP. Abbiamo voluto provare
una configurazione di "load sharing" per utilizzare
contemporaneamente entrambe i router. Infatti in mancanza di
guasti il traffico entrante passa per il router rA
e il traffico uscente per il router rB.
La configurazione di VRRP costruisce rispettivamente
l'IP virtuale 192.168.42.1 per la rete LAN
e l'IP virtuale 192.168.43.1 per la rete WAN. Il primo risulta
il default gateway per la LAN rappresentata dal nodo int.
Il secondo rappresenta il nodo della WAN utilizzabile
dal nodo ext
per l'inoltro dei pacchetti sulla LAN
(detto anche next-hop).
Per la distribuzione del carico (Load sharing) abbiamo pensato
che il nodo rA sia di transito per il flusso
entrante nella LAN e che il nodo rB sia di
transito per il flusso uscente dalla LAN.
La configurazione per il nodo rA è la seguente:
! /etc/keepalived/keepalived.conf
vrrp_instance VI_1 ! Defines a new instance of VRRP
{
state MASTER ! This VRRP instance will attempt to start in master state
interface eth0 ! This VRRP instance operates on the eth0 interface
virtual_router_id 1 ! The VRID this VRRP instances belongs to.
priority 250 ! The priority ot this VRRP router in this virtual router
advert_int 2 ! VRRP advertisements will occur ever 2 seconds
authentication { ! Defines the type of authentications
auth_type PASS
auth_pass 1234
}
virtual_ipaddress { ! The list of VIP that are managed by this VRID
192.168.43.1/24 !
}
notify_master "/etc/keepalived/email-master.sh VI_1 master"
notify_backup "/etc/keepalived/email-backup.sh VI_1 backup"
notify_fault "/etc/keepalived/email-fault.sh VI_1 fault"
smtp_alert ! Send email notif during state transition
}
vrrp_instance VI_2
{
state BACKUP ! This VRRP instance will attempt to start in backup state
interface eth1
virtual_router_id 2
priority 10
advert_int 2
smtp_alert
authentication {
auth_type PASS
auth_pass 5678
}
virtual_ipaddress {
192.168.42.1/24
}
notify_master "/etc/keepalived/email-master.sh VI_2 master"
notify_backup "/etc/keepalived/email-backup.sh VI_2 backup"
notify_fault "/etc/keepalived/email-fault.sh VI_2 fault"
smtp_alert
}
La configurazione per il nodo rB ` simile
tranne che per lo stato di VI_1 che passa da MASTER a BACKUP
e per lo stato di VI_2 che passa da BACKUP a MASTER.
Dopo aver settato correttamente l'ambiente Netkit
lancia lo script che genera la rete interamente configurata:
realhost$ lstart
Le attività eseguite dal programma vengono registrate nel file
/var/log/messages (nell'esempio dal router rA):
Keepalived_vrrp: Using MII-BMSR NIC polling thread... Keepalived_vrrp: Registering Kernel netlink reflector Keepalived_vrrp: Registering Kernel netlink command channel Keepalived_vrrp: Registering gratutious ARP shared channel Keepalived_healthcheckers: Watchdog: Starting listener on /tmp/.healthcheckers wdog socket Keepalived_vrrp: Configuration is using : 76341 Bytes Keepalived_vrrp: Watchdog: Starting listener on /tmp/.vrrp wdog socket Keepalived_vrrp: VRRP_Instance(VI_2) Entering BACKUP STATE Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER STATE Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
Nel caso di un fault del router rB simulato da:
realHost$ lcrash rB
nel file (di rA) compariranno anche le seguenti tracce:
Keepalived_vrrp: VRRP_Instance(VI_2) Transition to MASTER STATE Keepalived_vrrp: VRRP_Instance(VI_2) Entering MASTER STATE
e al ripristino del router rB simulato da:
realHost$ lstart rB
nel file (sempre di rA) compariranno anche le seguenti tracce:
Keepalived_vrrp: VRRP_Instance(VI_2) Received higher prio advert Keepalived_vrrp: VRRP_Instance(VI_2) Entering BACKUP STATE
Per controllare quali IP sono assegnati alle interfacce eth0 ed eth1 utilizziamo i comandi:
rA# ip addr show eth0; ip addr show eth1
4: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether fe:fd:c0:a8:2b:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.43.8/24 brd 192.168.43.255 scope global eth0
inet 192.168.43.1/24 scope global secondary eth0
inet6 fe80::fcfd:c0ff:fea8:2b08/64 scope link
5: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether fe:fd:c0:a8:2a:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.42.8/24 brd 192.168.42.255 scope global eth1
inet6 fe80::fcfd:c0ff:fea8:2a08/64 scope link
dove è evidenziato in colore la riga dell'IP virtuale
per l'interfaccia nella WAN. Nell'altro router rB
i valori sono:
rB# ip addr show eth0; ip addr show eth1
4: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether fe:fd:c0:a8:2b:09 brd ff:ff:ff:ff:ff:ff
inet 192.168.43.9/24 brd 192.168.43.255 scope global eth0
inet6 fe80::fcfd:c0ff:fea8:2b09/64 scope link
5: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether fe:fd:c0:a8:2a:09 brd ff:ff:ff:ff:ff:ff
inet 192.168.42.9/24 brd 192.168.42.255 scope global eth1
inet 192.168.42.1/24 scope global secondary eth1
inet6 fe80::fcfd:c0ff:fea8:2a09/64 scope link
Nel caso di guasto del router rB l'output diventa:
rA# ip addr show eth0; ip addr show eth1
4: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether fe:fd:c0:a8:2b:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.43.8/24 brd 192.168.43.255 scope global eth0
inet 192.168.43.1/24 scope global secondary eth0
inet6 fe80::fcfd:c0ff:fea8:2b08/64 scope link
5: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether fe:fd:c0:a8:2a:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.42.8/24 brd 192.168.42.255 scope global eth1
inet 192.168.42.1/24 scope global secondary eth1
inet6 fe80::fcfd:c0ff:fea8:2a08/64 scope link
È stato catturato il traffico sia sul segmento (File ACP) WAN che nel segmento (File ACP) LAN.
Configurazione "Sync Group" |
|
Per evitare casi di "dead route" il pacchetto keepalive permette
la configurazione "sync grouping". Infatti nel caso
precedente quando ad esempio non si guasta l'intero router rA
ma solo l'interfaccia eth1 il traffico entrante
dall'interfaccia eth0 non riesce a raggiungere la LAN.
Per garantire il funzionamento per questi casi dobbiamo abbandonare
la configurazione "load sharing" e quindi eleggere il nodo rA
come MASTER per tutte le sue interfacce e il nodo rB
come BACKUP per tutte le sue interfacce.
Inoltre occorre aggiungere nel file di configurazione:
! /etc/keepalived/keepalived.conf
[...]
vrrp_sync_group SG { ! VRRP sync group declaration
group { ! group of instance to sync together
VI_1
VI_2
}
notify_master "/etc/keepalived/email-master.sh SG master"
notify_backup "/etc/keepalived/email-backup.sh SG backup"
notify_fault "/etc/keepalived/email-fault.sh SG fault"
smtp_alert ! send email notif during state transit
}
[...]
Per attivare questa modalità di configurazione occorre fare le seguenti modifiche:
rA# /etc/init.d/keepalived stop rB# /etc/init.d/keepalived stop rA# cp /etc/keepalived/keepalived.conf.no-SPoF /etc/keepalived/keepalived.conf rB# cp /etc/keepalived/keepalived.conf.no-SPoF /etc/keepalived/keepalived.conf rA# /etc/init.d/keepalived start rB# /etc/init.d/keepalived start
Simuliamo il caso di guasto:
rA# ip link set dev eth1 down
Osserviamo il contenuto del file /var/log/messages del nodo rB:
Keepalived_vrrp: VRRP_Instance(VI_2) Transition to MASTER STATE Keepalived_vrrp: VRRP_Group(SG) Syncing instances to MASTER state Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER STATE Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE Keepalived_vrrp: VRRP_Instance(VI_2) Entering MASTER STATE
e quello del nodo rA:
[...] Keepalived_vrrp: Kernel is reporting: interface eth1 DOWN Keepalived_vrrp: VRRP_Instance(VI_2) Entering FAULT STATE Keepalived_vrrp: VRRP_Instance(VI_2) Now in FAULT state Keepalived_vrrp: VRRP_Group(SG) Syncing instances to FAULT state Keepalived_vrrp: VRRP_Instance(VI_1) Entering FAULT STATE Keepalived_vrrp: VRRP_Instance(VI_1) Now in FAULT state
|
|
Sandro Doro (email me)