Network failover with quagga (ospfd)

Hallo,

diesmal in Deutsch.
Für das erfolgreiche ausweichende Routing (das Benutzen anderer Netzwerkkarten, bekannt als failover, einfache Hochverfügbarkeit) kann man das Paket quagga (z.B. in der OpenSUSE 10.3 Distribution) nutzen.

Quagga (vormals Zebra)
hierbei ist "Free Routing Software (for BGP, OSPF and RIP, for example)".

Hier ein Beispiel mit zwei virtuellen Instanzen (via Xen) auf einem Hostsystem. Ziel ist es die ICMP -'ping' Aufforderung bei dem Ausfall einer Netzwerkroute auf die andere umzuleiten.

Konfiguration:
- einen Xen Host, mit zwei virtuellen Instanzen,
- die Instanz A ist mit drei virtuellen Netzwerkkarten, die Instanz B ist mit zwei Netzwerkkarten ausgerüstet,
- beide sind über das Xen Domain0 Routing miteinander verbunden (das ist Standard)
- beide Instanzen verfügen über eine OpenSUSE 10.3 Standardinstallation mit zusätzlichem Paket quagga

Instanz A:
Nun müssen die Dateien ospfd.conf und zebra.conf editiert werden:
linux-ynzp:~ # cat /etc/quagga/ospfd.conf
hostname node1-ospf
password quagga
enable password quagga
debug ospf zebra
log file /var/log/quagga/ospfd.log debugging
!
!
!
interface eth2
!
interface eth4
!
interface lo
!
interface eth3
!
router ospf
redistribute connected
!passive-interface eth3
!passive-interface eth4
!passive-interface eth2
network 192.168.1.0/24 area 0.0.0.0
network 192.168.2.0/24 area 0.0.0.0
network 192.168.3.0/24 area 0.0.0.0
network 172.16.1.0/24 area 0.0.0.0
!
line vty
!

linux-ynzp:~ # cat /etc/quagga/zebra.conf
hostname node1-quagga
password quagga
enable password quagga
log file /var/log/quagga/quagga.log
!
interface eth2
ipv6 nd suppress-ra
!
interface eth1
ipv6 nd suppress-ra
!
interface lo
!
interface eth3
ipv6 nd suppress-ra
!
interface eth4
ipv6 nd suppress-ra
!
interface eth0
ipv6 nd suppress-ra
!
ip forwarding
!
line vty
!

Instanz B
die Konfigurationsdaten:
linux-5c5k:~ # cat /etc/quagga/ospfd.conf
hostname node2-ospf
password quagga
enable password quagga
debug ospf zebra
log file /var/log/quagga/ospfd.log debugging
!
!
!
interface eth0
!
interface eth1
!
interface lo
!
interface eth2
!
router ospf
redistribute connected
network 192.168.1.0/24 area 0.0.0.0
network 192.168.2.0/24 area 0.0.0.0
network 192.168.3.0/24 area 0.0.0.0
line vty

linux-5c5k:~ # cat /etc/quagga/zebra.conf
hostname node2-quagga
password quagga
enable password quagga
log file /var/log/quagga/quagga.log
!
interface eth2
ipv6 nd suppress-ra
!
interface eth1
ipv6 nd suppress-ra
!
interface lo
!
interface eth0
ipv6 nd suppress-ra
!
ip forwarding
!
line vty

Zusammendfassend
Es müssen auf beiden Instanzen der ospfd sowie der zebra Dienst laufen:
rcospfd start
rczebra start

Versuchsaufbau der Instanzen

Ergänzung: die Benennung der Interfaces (eth2-eth4) ist beliebig, wichtig ist nur:

eth4                       eth2,  eth3           eth0,  eth1
            ------------- 192.168.1.1/24   ---   192.168.1.2/24 -------------
172.16.1.0 -- Instanz A-                                         - Instanz B-
            ------------- 192.168.2.1/24   ---   192.168.2.2/24 -------------

Das Instanz A ein Netzwerk hat, welches nur Instanz A kennt.

Netzwerkausfall Simulation
Wichtig ist es die Netzwerkarten hochzufahren:
linux-ynzp:~ # cat setup.sh
#!/bin/bash -x
#ifconfig eth0 down
#ifconfig eth1 down
ifconfig eth2 down
ifconfig eth3 down
ifconfig eth4 down

#ifconfig eth0 192.168.1.1/24 up
#ifconfig eth1 192.168.2.1/24 up
ifconfig eth2 192.168.1.1/24 up
ifconfig eth3 192.168.2.1/24 up
ifconfig eth4 172.16.1.1/16 up
ifconfig

Auf Instanz A nutzt man hierbei folgenden Skript:
linux-ynzp:~ # o interface_cycle.sh
#!/bin/bash -x
ifconfig eth2 up
ifconfig eth3 up
while true; do
echo "neustart";
sleep 1;
ifconfig eth2 down;
sleep 20;
ifconfig eth2 up;
sleep 1;
ifconfig eth3 down;
sleep 20;
ifconfig eth3 up;
sleep 3;
ifconfig eth2 down;
ifconfig eth3 down;
sleep 3;
ifconfig eth3 up
ifconfig eth2 up
ps aux | grep ospf
done

Wie man leicht sehen kann, es schaltet periodisch einzelne Netzwerke ab und zwingt damit den OSPF Dienst dieses bei den Partnersystem (Instanz B) bekannt zu machen.


Auf der Instanz B:
fährt man ebenfalls die Netzwerkkarten hoch:
linux-5c5k:~ # cat setup.sh
#!/bin/bash -x
ifconfig eth0 down
ifconfig eth1 down
ifconfig eth2 down

ifconfig eth0 192.168.1.2/24 up
ifconfig eth1 192.168.2.2/24 up
ifconfig eth2 192.168.3.2/24 up
ifconfig

Danach erfolgt dann die Ping-Aufforderung:
ping 172.16.1.1
Zeitgleich kann man sich das Ergebnis anschauen:
while true; do route -n | grep 172; sleep 2;done
Mit der Schleife sieht man die Veränderung der Routingschnittstelle.

Dazu startet man auf der Instanz das Skript interface_cycle.sh, danach kann man die Veränderung der Routingschnittstelle auf der Instanz B verfolgen.

Ergebnis:
bei der Abschalten der Netzwerkarte auf Instanz A erfolgt ein Routingwechsel auf Instanz B:

64 bytes from 172.16.1.1: icmp_seq=3 ttl=64 time=0.110 ms
64 bytes from 172.16.1.1: icmp_seq=4 ttl=64 time=0.082 ms
172.16.0.0 192.168.1.1 255.255.0.0 UG 20 0 0 eth0
64 bytes from 172.16.1.1: icmp_seq=5 ttl=64 time=0.096 ms
64 bytes from 172.16.1.1: icmp_seq=6 ttl=64 time=3.64 ms
172.16.0.0 192.168.1.1 255.255.0.0 UG 20 0 0 eth0
64 bytes from 172.16.1.1: icmp_seq=7 ttl=64 time=0.072 ms
64 bytes from 172.16.1.1: icmp_seq=8 ttl=64 time=0.104 ms
172.16.0.0 192.168.2.1 255.255.0.0 UG 20 0 0 eth1
64 bytes from 172.16.1.1: icmp_seq=9 ttl=64 time=3.18 ms
64 bytes from 172.16.1.1: icmp_seq=10 ttl=64 time=0.105 ms
172.16.0.0 192.168.2.1 255.255.0.0 UG 20 0 0 eth1
64 bytes from 172.16.1.1: icmp_seq=11 ttl=64 time=0.101 ms
64 bytes from 172.16.1.1: icmp_seq=12 ttl=64 time=0.081 ms