Virtual Router Redundancy Protocol

Posted on pią 24 wrzesień 2010 in MikroTik

VRRP to protokół zdefiniowany w dokumencie RFC3768. Protokół pozwala na definiowanie grup routerów w jeden router wirtualny. W ramach routera wirtualnego jedna z maszyn pracuje jako master - aktywny w danej chwili router, który zajmuje się... routowaniem ;) - oraz jeden lub więcej routerów w stanie backup. Routery backup okresowo sprawdzają aktywność routera master (za pomocą arp) i jeśli wykryją awarię routera głównego, jeden z nich przejmuje jego rolę.

VR (Virtual Router) widoczny jest zawsze pod tym samym adresem IP dzięki czemu awaria mastera jest praktycznie niezauważalna dla hostów korzystających z danego router. Z kolei o tym czy router zostanie masterem czy backupem decyduje priorytet przypisany w trakcie konfiguracji - najwyższy priorytet = master.

Zobaczmy jak konfiguracja VRRP wygląda na maszynach z Mikrotik RouterOS:

[admin@MikroTik] > interface vrrp add interface=ether1 vrid=100   
  \... priority=100 authentication=ah password=xxxxx   
  \... disabled=no
[admin@MikroTik] > ip address add address=10.0.0.1/32 interface=vrrp1

Przyjrzyjmy się argumentom polecenia:

  • vrid - identyfikator wirtualnego routera - na tej podstawie router wie, do którego routera wirtualnego należy. Wszystkie routery w obrębie jednego VR mają to samo VRID
  • priority - priorytet router - na tej podstawie dokonywana jest elekcja routera master i routerów backupowych - im wyższy priorytet (wyższa liczba) tym większa szansa na to, że router będzie masterem.
  • authentication - metoda uwierzytelniania routerów - mamy do wyboru none, simple (otwarty tekst) i ah (authentication header). Oczywiście zalecam korzystać z tego ostatniego :)

Jak widać interfejs VRRP przypisujemy do interfejsu fizycznego urządzenia.

OK. Nic tak dobrze nie robi jak mały schemat :D

Przykład typowego zastosowania VRRP:

VRRP
example

I jeszcze jeden przykład - tym razem z dwoma routerami po stronie dostawcy:

VRRP
example

Na schemacie mamy dwa routery działające w ramach jednego routera wirtualnego (ten sam VRID) - każdy z routerów ma inny priorytet. Dla hostów należących do tej sieci lokalnej wirtualny router będzie manifestował się pod jednym, stałym adresem IP (VIP) - taką też bramę domyślną mają ustawione hosty.

To tyle gadania - weźmy się do roboty:

[admin@R1] > interface vrrp add interface=ether1 vrid=100

... priority=100 authentication=ah password=xxxxx
... disabled=no [admin@R1] > interface vrrp print detail Flags: X - disabled, I - invalid, R - running, M - master, B - backup 0 B name="vrrp1" mtu=1500 mac-address=00:00:5E:00:01:0A arp=enabled interface=ether1 vrid=100 priority=100 interval=1 preemption-mode=yes authentication=ah password="xxxxx" on-backup="" on-master="" [bdr@R1] > [bdr@R1] > ip address add address=10.0.0.1/32 interface=vrrp1 [bdr@R1] >

Jeden z routerów mamy z głowy. Czy ktoś zwrócił uwagę, że adres IP wirtualnego routera został ustawiony na interfejsie vrrp1? Oczywiście na interfejsie fizycznym też powinniśmy skonfigurować jakiś adres należący do tej podsieci - konieczne do komunikacji z samym routerem.

Na R2 konfiguracja jest analogiczna. Żeby skomplikować nieco sytuację R2 będzie routerem Vyatta:

vyatta@R2# edit interfaces ethernet eth1 vrrp
[edit interfaces ethernet eth1 vrrp]
vyatta@R2# set vrrp-group 100
[edit interfaces ethernet eth1 vrrp]
vyatta@R2# set vrrp-group 100 authentication type ah
[edit interfaces ethernet eth1 vrrp]
vyatta@R2# set vrrp-group 100 authentication password xxxxx
[edit interfaces ethernet eth1 vrrp]
vyatta@R2# set vrrp-group 100 priority 200
[edit interfaces ethernet eth1 vrrp]
vyatta@R2# set vrrp-group 100 virtual-address 10.0.0.1/32
[edit interfaces ethernet eth1 vrrp]

Skontrolujmy konfigurację:

[edit interfaces ethernet eth1 vrrp]
vyatta@R2# show
+vrrp-group 100 {
+    authentication {
+        password xxxxx
+        type ah
+    }
+    priority 200
+    virtual-address 10.0.0.1/32
+}
[edit interfaces ethernet eth1 vrrp]
vyatta@R2#
[edit interfaces ethernet eth1 vrrp]
vyatta@R2# commit
[edit interfaces ethernet eth1 vrrp]
vyatta@R2# save
Saving configuration to '/opt/vyatta/etc/config/config.boot'...
Done
[edit interfaces ethernet eth1 vrrp]
vyatta@R2# exit
[edit]

Jak widać w systemie Vyatta zastosowano nieco inne podejście. O ile w RouterOS vrrp funkcjonuje jako pseudointerfejs (podobnie jak VLAN) o tyle w Vyatta na danym interfejsie konfigurujemy grupę vrrp (numer grupy to odpowiednik VRID w RouterOS). Nieco inaczej konfiguruje się też adres IP wirtualnego routera - zamiast adresować pseudointerfejs vrrp (którego w Vyatta nie ma) używamy parametru virtual-adress. Warto zwrócić uwagę, że na R2 skonfigurowaliśmy inny priorytet routera.

Które z podejść jest bardziej przejżyste to kwestia gustu, ja osobiście skłaniam się ku Vyatta ;)

Na R2 konfiguracja jest analogiczna jednak zmieniamy priorytet. Sprawdźmy jeszcze czy prawidłowo przebiegła elekcja:

[admin@R1] > interface vrrp print
Flags: X - disabled, I - invalid, R - running, M - master, B - backup
 0   B  name="vrrp1" mtu=1500 mac-address=00:00:5E:00:01:0A arp=enabled
        interface=ether1 vrid=10 priority=200 interval=1
        preemption-mode=yes authentication=ah password="xxxxx" on-backup=""
        on-master=""

Flaga RM w RouterOS oznacza, ze router został masterem, na R1 powinniśmy zobaczyć flagę B, oznaczającą status backup. Voila! W sytuacji awarii zgubimy pinga czy dwa zanim router "się naprawi". Rzut oka na R2:

vyatta@R2# run show vrrp
Physical interface: eth1, Source Address 10.0.0.2
  Interface state: up, Group 100, State: master
  Priority: 100, Advertisement interval: 1, Authentication type: ah
  Preempt: true, VIP count: 1, VIP: 10.0.0.1/32
  Master router: 10.0.0.2
  Last transition: 6m24s

[edit]
vyatta@R2#

State master jasno wskazuje, że elekcja przebiegła na korzyść R2 - dokładnie tak jak się spodziewaliśmy :) Adres na fizycznym interfejsie to 10.0.0.2 natomiast VIP jest wspólny dla wszystkich routerów w ramach grupy.

Możemy także zdefiniować dwa routery wirtualne na obu maszynach, co pozwoli nam osiągnąć rozkład obciążenia przy jednoczesnym zabezpieczeniu przed awarią.

Mała uwaga na koniec - ponieważ do sprawdzania stanu mastera używany jest arp, VRRP nie uratuje nas w sytuacji gdy awaria nastąpi gdzieś "za nim". Ponowna elekcja zostanie przeprowadzona tylko w sytuacji gdy router nie odpowiada na arp (jest nieosiągalny).