BPG: Mikrotik + BIRD routing daemon
Przedstawiamy przykładową konfigurację procesów routingu BGP pomiędzy urządzeniami Mikrotik zarządzanych przez RouterOS, a procesem daemona BIRD, który może być uruchomiony w środowisku Linux/*BSD.
Zaprezentowana poniżej konfiguracja może mieć zastosowanie, w przypadku gdy posiadamy router do którego podłączone jest kilka koncentratorów PPPoE (zobacz Porada 25).
Takie rozwiązanie można zastosować, jeśli ilość terminowanych sesji PPPoE przekracza możliwości obsługi przez pojedyncze urządzenie (np. RB750, RB1000), wynika z ograniczeń licencyjnych dla MT, lub jeśli chcemy zapewnić możliwie bezawaryjną pracę - w przypadku uszkodzenia jednego z koncentratorów jego zadania przejmuje drugi/pozostałe urządzenia.
Wybór protokołu BGP (alternatywą jest np. protokół OSPF) wynika z faktu, że chcemy raczej znać informację o dostępności (poprzez dany koncentrator), a nie o najlepszej trasie do hosta.
Konfiguracja urządzenia (urządzeń) Mikrotik
Zakładając, że urządzenie jest już skonfigurowane jako koncentrator PPPoE, ustawiamy adresację IP dla interfejsu, który przyłączony jest do segmentu sieci, w którym znajduje się nasz ruter *BSD:
Z menu wybieramy IP -> Adresses, następnie dodajemy adres IP. W naszym przykładzie koncentrator będzie miał adres IP 192.168.0.100, a ruter *BSD adres 192.168.0.200, w podsieci /24.
Pożądany adres IP dodajemy do interfejsu ether2, pozostałe wpisy tworzone są przez serwer PPPoE.
Przechodzimy do zakładki BGP w menu Routing, po otwarciu okna, używamy czerwonego plusa, aby dodać instancję BGP:
Wpisujemy nazwę instancji - w naszym przykładzie pozostawiamy default,wpisujemy numer ASN, tutaj z prywatnego zakresu wybieramy 65000, oraz router ID, który najprościej definiujemy jako adres IP koncentratora.
Zaznaczenie opcji Redistribute Connected będzie skutkowało zawarciem w sesji BGP informacji o sieciach/hostach bezpośrednio przyłączonych (tj zdefiniowanych na interfejsach Mikrotika).
Zaznaczenie opcji Redistribute Static będzie skutkowało zawarciem w sesji BGP informacji o sieciach/hostach zdefiniowanych statycznie na urządzeniu Mikrotik.
Pozostałe opcje tj. redystrybucja informacji o routingu pochodzącej z protokołów RIP, OSPF bądź innych instancji BGP w naszym przypadku nie są zaznaczone.
W tym prostym przypadku nie używamy też filtrowania.
Przechodzimy do zakładki Peer i dodajemy czerwonym plusem nowy wpis, definiujący router *BSD jako partnera sesji BGP dla Mikrotika:
Najważniejsze pola do ustawienia, to od góry:
- wybór instancji - w tym przypadku wcześniej dodana default,
- ustawienie adresu IP partnera, u nas 192.168.0.200,
- ustawienie numeru ASN partnera, w przykładzie używamy iBGP, z prywatnego zakresu ASN, tj. 65000,
- Hold Time - wartość w sekundach, określająca jak długo ma być podtrzymywana sesja BGP, jeśli nie nadchodzi komunikat Update lub Keepalive.
Wartości Nexthop choice, Keepalive time, pozostawiamy ustawione domyślnie.
Oczywiście timery Hold Time i Keepalive Time możemy dostosować do własnych potrzeb, aby zapewnić możliwie szybką reakcję na utratę jednego z koncentratorów, nie mają one natomiast tak dużego wpływu na load-balancing.
W zakładce Advanced ustawiamy jeszcze, że wymiana informacji o routingu będzie dotyczyła jedynie protokołu IP.
W zakładce Status możemy podejrzeć informacje o czasie trwania sesji, aktualnych timerach i wysłanych/otrzymanych informacjach o routingu.
Konfiguracja daemona BIRD
BIRD konfigurujemy za pomocą pliku tekstowego bird.conf, wraz z komentarzami:
# logowanie do syslog-a
log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug };
# można ręcznie ustawić ID routera
router id 192.168.0.200;
# włączamy debugowanie wszystkich protokołów
debug protocols all;
# protokół kernel - tablica routingu systemu
protocol kernel {
persist; # nie usuwaj tras przy wyłączeniu BIRDa
scan time 20; # skanuj tablicę routingu co 20 sekund
import all; # domyślnie importuj wszystkie trasy
export none; # domyślnie niczego nie eksportuj
}
# protokół device - interfejsy routera
protocol device {
scan time 10; # skanuj interfejsy co 10 sek (np. wyłączenia)
}
# definiujemy peera BGP
protocol bgp pppoe1 {
# opis
description "pppoe1";
# lokalny IP i AS
local 192.168.0.200 as 65000;
# zdalny IP i AS
neighbor 192.168.0.100 as 65000;
# nie obliczaj adresu nexthop-a z iBGP
gateway direct;
# eksportujemy wszystkie trasy
export all;
# dodajemy filtr importu, tylko podsieć 10.0.0.0/16
import filter {
if net ~ 10.0.0.0/16 then {
accept;
}
reject;
};
}
Oczywiście możemy zdefiniować wiele peer-ów BGP, dzięki czemu uzyskamy odpowiednio konfiguracje fail-over i / lub load-balancing:
# definiujemy drugiego peera BGP
protocol bgp pppoe1 {
# opis
description "pppoe2";
# lokalny IP i AS
local 192.168.0.200 as 65000;
# zdalny IP i AS
neighbor 192.168.0.101 as 65000;
# nie obliczaj adresu nexthop-a z iBGP
gateway direct;
# eksportujemy wszystkie trasy
export all;
# dodajemy filtr importu, tylko podsieć 10.0.0.0/16
import filter {
if net ~ 10.0.0.0/16 then {
accept;
}
reject;
};
}
Podsumowanie
Jeżeli wszystko przebiega sprawnie, powinniśmy zobaczyć jakie informacje są wymieniane pomiędzy ruterami, zarówno od strony Mikrotika:
Jak i od strony routera *BSD z BIRD-em, za pomocą konsoli uruchamianej poleceniem birdc:
bird> show protocol pppoe1
name proto table state since info
pppoe1 BGP master up 00:02 Established
bird> show protocols all pppoe1
name proto table state since info
pppoe1 BGP master up 00:02 Established
Description: pppoe1
Preference: 100
Input filter: (unnamed)
Output filter: ACCEPT
Routes: 651 imported, 0 exported, 651 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 2898 0 1 0 2897
Import withdraws: 2247 0 --- 2 2246
Export updates: 2897 2897 0 --- 0
Export withdraws: 2246 --- --- --- 0
BGP state: Established
Neighbor address: 192.168.0.100
Neighbor AS: 65000
Neighbor ID: 192.168.0.100
Neighbor caps: refresh AS4
Session: internal AS4
Source address: 192.168.0.200
Hold timer: 232/240
Keepalive timer: 51/80
bird> show route
10.0.3.2/32 via 192.168.0.100 on lan [pppoe1 10:07] * (100) [?]
10.0.4.67/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.4.195/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.1.2/32 via 192.168.0.100 on lan [pppoe1 08:17] * (100) [?]
10.0.5.3/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.1.66/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.5.67/32 via 192.168.0.100 on lan [pppoe1 02:03] * (100) [?]
10.0.1.130/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.2.3/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.6.194/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.7.2/32 via 192.168.0.100 on lan [pppoe1 09:07] * (100) [?]
10.0.3.131/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.8.1/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.8.65/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.0.67/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.5.2/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.1.3/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
10.0.1.67/32 via 192.168.0.100 on lan [pppoe1 10:36] * (100) [?]
10.0.1.131/32 via 192.168.0.100 on lan [pppoe1 09:42] * (100) [?]
10.0.1.195/32 via 192.168.0.100 on lan [pppoe1 07:27] * (100) [?]
10.0.6.1/32 via 192.168.0.100 on lan [pppoe1 06:31] * (100) [?]
10.0.2.128/32 via 192.168.0.100 on lan [pppoe1 00:02] * (100) [?]
[...]
Load balancing dla dwóch Mikrotików:
Z praktyki wynika, że sesje PPPoE rozkładają się w miarę równomiernie pomiędzy koncentratory, bez dodatkowych ustawień, co wynika z szybszego czasu reakcji mniej obciążonego koncentratora:
|