Redundante Default Routen und Lastverteilung unter Linux

Anders als viele glauben kann ein Linux “Router” nicht nur ein Default Gateway besitzen sondern mehrere. Das macht bei 2 Szenarien Sinn:

  1. Autofailover
    Definiert man 2 Default Routen etwa mit:

    route add default gw 172.16.1.1 dev eth1
    route add default gw 172.16.2.1 dev eth2

    So wird die zweite Default Route dann verwendet, wenn die erste einen Timeout liefert.

  2. Loadbalancing
    Das geht auch ganz einfach:

    ip route del default
    ip route add default equalize nexthop via 172.16.1.1 dev eth1 nexthop via 172.16.2.1 dev eth2

    . Am besten trägt man das in /etc/rc.d/rc.local ein. Dann übersteht es auch einen Reboot.

Beiden Methoden ist übrigens gemein, dass der Timeout einer ausgefallenen Default Route noch angepasst werden muss. Der Default Timeout liegt bei stolzen 300 Sekunden.

cat /proc/sys/net/ipv4/route/gc_timeout
300

Das bedeutet, dass erst nach 5 Minuten die entsprechende Route deaktiviert wird. Umstellen kann man diesen Wert über sysctl. Also in /etc/sysctl.conf folgendes eintragen:

net.ipv4.route.gc_timeout = 10

und mit

sysctl -p

aktivieren

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)
Artikel als PDF exportieren.

iproute2 – source based routing

Source based routing ist nicht schön, aber manchmal wirklich notwendig. Allerdings geht es mit dem iproute2 Paket auch wirklich einfach. In meinem Fall habe ich 2 Internet-Anbindungen wovon die erste (default) für alle offziellen Adressen genutzt werden soll, die zweite rein für Traffic aus dem VPN.

Folgende Schritte sind notwendig.

  1. Als erstes muss die Tabelle in /etc/iproute2/rt_table definiert werden. In meinem Fall:
    10 vpn-link
  2. Das Routing für das VPN muss definiert werden:
    ip route add 172.16.128.0/20 via 172.16.1.253 table vpn-link
    ip route add default via 172.16.1.254 table vpn-link 
    ip route list table vpn-link
  3. Jetzt muss noch die Tabelle für die Source Route aktiviert werden
    ip rule add from 172.16.128.0/20 table vpn-link
    ip rule list

Ginge das nur mit Windows auch so einfach.

Source based routing ist übrigens nicht schön, weil es mehr Last erzeugt. Schließlich müssen weitere 32 Bit (Source-Adresse) aus dem IP-Header verarbeitet werden.

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)
Artikel als PDF exportieren.
Posted in Routing. Keine Kommentare »

Quagga

Mein nächstes Alix Projekt steht schon fest. Ich bau mir eine eierlegende Wollmilchsau als Router. Ich brauch ständig unterwegs einen UMTS/DSL/Lan Router, der auch WLan für meinen Sip-Client am Handy spielt. Das Teil soll auch OpenVPN können, damit ich mir keine Gedanken über meine Telefongespräche machen muss. Mittlerweile habe ich so einige VPN Tunnel ständig am laufen und muss überall immer die Route eintragen. Neulich hatte ich wieder durch ein VPN mir eine Schleife gelegt und hatte erst alles mögliche im Verdacht, bis ich auf das wahre Problem gekommen bin. Das nervt mich langsam! Daher wird jetzt mit dem Projekt auf ein Routing Protokoll umgestellt! Ich hätte das schon längst machen sollen!

Also wird der neue Alix-(Thinclient)-Router wohl auch Quagga bekommen. Und ich werde mir wohl OSPF oder Rip einrichten. Quagga ist schon ziemlich lustig. Die Konfiguration fällt mir dank meiner Cisco-Zertifizierung und der entsprechenden Erfahrung damit super leicht. Schließlich emuliert das Interface genau solch eine IOS Konsole. Alles ziemlich simple. Quagga kann sogar BGP. Aber nachdem ich noch keine Ahnung habe welche Größe so eine Routingtablle mit Quagga annehmen kann und ich kein eigenes AS habe brauch ich das ja auch noch nicht. Da muss mein Netz noch viel größer werden ;-)

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)
Artikel als PDF exportieren.
Posted in Alix, Routing. Tags: , , , . Keine Kommentare »
show
 
close