Jakiś czas temu w moje ręce wpadł produkt Ubiquiti Networks – mianowicie EdgeRouter Lite i od razu przyciągnął moją uwagę faktem, że generalnie w środku tego dość taniego urządzenia siedzi rasowy Linux (Debian) z zainstalowaną „nakładką” bazującą na forku VyattaOS. Nie byłoby w tym nic specjalnego – gdyż sporo urządzeń bazuje na Linuxie – niemniej jednak wykorzystanie Debiana wraz z „uszytym” na miarę kernelem dla platformy sprzętowej Cavium Octeon dawało całkiem niezłe możliwości. Po pierwsze – pełna możliwość skorzystania z repozytorium dawała możliwość kompilacji/instalacji niemalże dowolnego oprogramowania. Po drugie – wbudowane w kernel moduły dla chipsetu firmy Cavium dawało wręcz oszałamiające rezultaty jeśli chodzi o wydajność. Warto wspomnieć, że wersja LITE spokojnie daje radę przerzucać ponad 1 milion PPSów przy zegarze na poziomie 500MHZ i wielkości ramki na poziomie 64 bajtów. Robi to wrażenie – szczególnie, że sprzęt ten kosztuje poniżej 400zł. Dodatkowo sam układ Octeon zapewnia sprzętową akcelerację dla trasowania oraz przetwarzania pakietów co powoduje, że router przy niewielkim zużyciu CPU jest w stanie spokojnie „przetrawić” realnego ruchu 1Gbit/s.
Mimo bardzo fajnego hardware’u oprogramowanie które było instalowane na urządzeniu posiadało sporo niższe możliwości w stosunku nawet do królującego na domowych routerach OpenWRT czy nie wspominając już o Mikrotikowym RouterOS. Wersja 1.4 oprogramowania EdgeOS zasadniczo nie pozwalała na nic więcej – więc pozostawało tak naprawdę mozolne „dłubanie” w terminalu aby uzyskać stosowną funkcjonalność – lub po prostu ręcznie dłubiąc w Debianie.

Poza tą niedogodnością – pierwsze wersje LITE posiadały również szereg wad. Porty Ethernet w ilości skromnej ilości 3 sztuk skutecznie uniemożliwiały wykorzystanie urządzenia jako prostego „domowego routerka” a do tego firmware wraz z Debianem instalowane były na wbudowanym w urządzenie pendrive’wie wciskanym w port USB dolutowanym do PCB. Jak się okazało w czasie – bardzo często pendrive nie wytrzymywał próby czasu i albo się uszkadzał skutecznie uniemożliwiając poprawną pracę urządzenia – albo po prostu pojawiały się błędy magistrali USB.  Nowsze wersje (z prostokątną obudową) posiadały już zupełnie inny układ pamięci Flash – niemniej wciąż urządzenie uruchamiało się poprzez magistralę USB.

Pewien przełom dokonał się dopiero po pojawieniu się „najmocniejszej” wersji EdgeRoutera z dopiskiem PRO. Wersja PRO przygotowana była już do cięższych zadań i z uwagi na dopisek PRO doczekała się obudowy typu RACK 1U oraz 6 portów Ethernet (Gigabit Ethernet) wraz z dwoma portami Combo (SFP+RJ45). Całość napędzana najszybszym dwurdzeniowym procesorem Octeon o taktowaniu 1GHZ pozwalała zgodnie z deklaracją producenta przenieść do 2Mppsów przy deklarowanym maksymalnym poborze energii na poziomie 40W – co w porównaniu do ciężkich i prądożernych PCtów robi całkiem niezłe wrażenie.

EdgeRouter PRO …. jako BGP?

Pomysł na użycie EdgeRoutera PRO jako routera BGP narodził się zupełnie przez przypadek podczas poeksperymentowania z możliwościami Linuxa na tej platformie sprzętowej. Głównym powodem wykorzystania ER-PRO do BGP była chęć po pierwsze zredukowania kosztów energii elektrycznej oraz możliwość wykorzystania większej ilości portów Ethernet w stosunku do 2-4 portów jakie można było wykorzystać w standardowym sprzęcie PC. Poza tym jednolita platforma sprzętowa dawała możliwość zasadniczo uwolnienia się od problemów typowych dla architektury PC – problem z przerwaniami, podziałem wątków karty sieciowej na rdzenie. Po wielu testach udało mi się stwierdzić, że ER-PRO po prostu przerzuca bez większego wysiłku nawet kilka ładnych gigabitów ruchu bez specjalnego zmęczenia czy gubienia ramek w stosunku do posiadanej platformy PC opartej o profesjonalny sprzęt firmy Supermicro. Pomysł więc wydał się całkiem rozsądny, zważywszy że….  do BGP na platformie PC używałem od wielu lat BIRDa – a którego instalacja pod EdgeRouterem wydawała się dziecinnie łatwa.

Dlaczego BIRD?

BIRD to daemon protokołu BGP/OSPF/BFD dla Linuxa oraz innych systemów Unixopodobnych. Mimo, że generalnie prym pod tym kątem i niemal standardem od wielu lat stanowi Quagga – to BIRD w stosunku do konkurencji posiada szereg niezaprzeczalnych zalet. Główną zaletą BIRDa są przede wszystkim niewielkie wymagania sprzętowe – zgodnie z dokumentacją i porównaniem – BIRD zżera nawet 3-krotnie mniej pamięci operacyjnej w stosunku do Quaggi przy podobnej ilości zaciągniętych prefiksów. Poza tym BIRD generalnie nie jest taką rozpasaną „kobyłą” w stosunku do Quaggi i potrafi przetwarzać całkiem dobrze różnego rodzaju filtry co czyni go znacznie „szybszym” zamiennikiem. Dodatkowo główną zaletą oraz powodem uruchamiania BGP pod BIRDem było moje lenistwo – konfigurację BIRDa praktycznie już miałem podaną na widelcu, więc … po co kombinować? Zważywszy, że implementacja BGP w ówczesnej najnowszej wersji EdgeOS pozostawała nie tylko wiele do życzenia – co było po prostu niemożliwe.

Jak zainstalować BIRDa?

W pierwszej kolejności musimy zainstalować najnowszą wersję EdgeOS. W tym celu pobieramy odpowiedni upgrade ze strony : https://www.ubnt.com/download/edgemax/
Na chwilę obecną najnowszą wersją jest wersja 1.9.1. W celu dodania repozytorium Wheezy (taka jest wersja Debiana dla wersji 1.9.1) wpisujemy spod konsoli :

configure
set system package repository wheezy components 'main contrib non-free’
set system package repository wheezy distribution wheezy
set system package repository wheezy url http://http.us.debian.org/debian
commit
save
exit

Następnie już spod konsoli wpisujemy sudo bash i następnie apt-get update w celu zaktualizowania dostępnych pakietów. Pamiętajmy o tym, żeby nasz router miał dostęp do Internetu – to chyba jest oczywiste 😉

Aby móc łatwo konfigurować BIRDa do edycji i poruszania się po strukturze katalogów możemy zainstalować Midnight Commandera – w tym celu wpisujemy apt-get install mc. Po instalacji uruchamiamy mc i przechodzimy do katalogu /etc/apt/source.list i dodajemy wpis :

deb http://ftp.de.debian.org/debian wheezy-backports main

Zapisujemy i ponownie wykonujemy apt-get update. Z uwagi, że repozytorium Debiana nie posiada zwykle najnowszej wersji BIRDa musimy wybrać najnowszą wersję jaka jest dostępna. W tym celu wpisujemy :

apt-cache policy bird

I następnie apt-get install bird=1.4.5-1~bpo70+1 – gdzie 1.4.5-1~bpo70+1 wpisujemy najnowszą dostępną wersję. Generalnie w moim przypadku jest to wersja 1.4.5 więc powiedzmy jest to w miarę „świeża” wersja. Być może za niedługo dostępna będzie jeszcze nowsza wersja.

Od czego zaczynamy?

Po pierwsze konfiguracja BIRDa jest dziecinnie prosta. Konfiguracja zasadniczo składa się z jednego pliku w postaci : /etc/bird.conf i ew. /etc/bird6.conf dla protokołu IPv6.

Struktura pliku jest dość dobrze opisana w oryginalnej dokumentacji. Zanim jednak zaczniemy bawić się BGP musimy wprowadzić parę dość istotnych modyfikacji do konfiguracji EdgeRouter’a. Po pierwsze musimy skonfigurować adresację na interfejsach – tak jak powinny one być zaadresowane.

Następnie musimy napisać prosty skrypt, który pozwoli nam wprowadzić parę „udogodnień” w celu optymalizacji działania naszego routera i zminimalizowania zużycia procesora.

W tym celu tworzymy plik start.sh w katalogu /config/scripts/post-config.d/ :

cd /config/scripts/post-config.d/
touch start.sh
chmod +x start.sh
chmod 777 start.sh

Następnie umieszczamy w nim np.:

#!/bin/sh

echo „0” > /proc/sys/net/ipv4/conf/all/log_martians

W logach nie będziemy przechowywać komunikatów martians – często zapycha nam to niepotrzebnie SYSLOGA.

iptables -A FORWARD -p tcp –dport 135:139 -j DROP
iptables -A FORWARD -p tcp –dport 135:139 -j DROP
iptables -A FORWARD -p udp –sport 135:139 -j DROP
iptables -A FORWARD -p udp –sport 135:139 -j DROP
iptables -A FORWARD -p tcp –dport 445 -j DROP
iptables -A FORWARD -p tcp –dport 445 -j DROP
iptables -A FORWARD -p udp –sport 445 -j DROP
iptables -A FORWARD -p udp –sport 445 -j DROP

#Możemy przyblokować różnego rodzaju śmieci które będą przekazywane pomiędzy portami.

ip rule add to 185.23.12.0/23 table BGP
ip rule add from 185.23.12.0/23 table BGP

#Jeśli korzystamy z alternatywnej tablicy dla BGP koniecznie musimy dopisać nasze prefiksy tak, aby były one w tablicy routingu przeznaczone dla BGP. Inaczej mimo „zassania” prefiksów globalnych nasze nie będą propagowane „w górę” sieci, gdyż BIRD będzie rozgłaszał tylko to co zostanie w tej tablicy umieszczone.

iptables -t raw -A PREROUTING -j NOTRACK

# Jeśli nasze BGP będzie tylko i wyłącznie przerzucać ramki – powinniśmy nie używać conntracka gdyż przy nawet nie dużym ruchu jesteśmy w stanie go zapchać prędzej czy później. Komenda ta generalnie odciąża przetwarzanie każdego połączenia dzięki czemu nasz router po pierwsze nie obciąża pamięci – po drugie jego wydajność wzrasta co najmniej kilkukrotnie! No chyba, że chcemy używać NAT – ale tego raczej nie powinien wykonywać router BGP.

iptables -A FORWARD -m icmp -p icmp –icmp-type destination-unreachable -j DROP
iptables -A FORWARD -m icmp -p icmp –icmp-type port-unreachable -j DROP
iptables -A FORWARD -m icmp -p icmp –icmp-type net-unreachable -j DROP
iptables -A FORWARD -m icmp -p icmp –icmp-type host-unreachable -j DROP
iptables -A FORWARD -m icmp -p icmp –icmp-type time-exceeded -j DROP
iptables -A FORWARD -s 0.0.0.0/0 -d 0.0.0.0/0 -p udp –dport 1900 -j DROP

# te regułki pozwalają nam na ograniczenie róznego rodzaju floodów i śmieci jakie generowane są przez DDOSy.

echo „160” > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo „160” > /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
echo „160” > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo „180” > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo „640” > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo „160” > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo „160” > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
echo „2212000” > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo „2212000” > /proc/sys/net/nf_conntrack_max

#Jeśli potrzebowalibyśmy używać Conntracka dobrze jest zoptymalizować jego parametry.

echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

# Jeśli mamy dużo adresów MAC w naszej sieci – warto zwiększyć tablicę ARP.
Dobrym rozwiązaniem w tym wypadku jest rozdzielenie tablicy głównej routingu z tablicą do której będą wpadały wpisy BGP. Nie jest to konieczne – ale pozwala zaoszczędzić trochę zasobów sprzętowych oraz pozwala rozdzielić prefiksy rozgłaszane przez protokół BGP z prefiksami np. wewnętrznymi. W tym celu należy dodać po prostu wpis do pliku : /etc/iproute2/rt_tables np.

20 BGP

Spowoduje to utworzenie tablic nr 20 o nazwie BGP.

Sama konfiguracja BIRDa jest zasadniczo bardzo prosta. Najprostszy (ALE NIE ZALECANY!) konfig wygląda następująco :

log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug };
log „/tmp/bird.log” all;

Ustawiamy aby, BIRD wypluwał nam wszelkiego rodzaju problemy bezpośrednio do sysloga – to bardzo się przydaje podczas ew. diagnostyki

router id 0.0.0.1;

Ustawiamy ID routera – wartość ta musi być unikatowa – najcześciej jest to adres IP publiczny

protocol device { }
protocol direct { }

protocol kernel {
scan time 360; // co jaki interwał czasu mamy sprawdzać zmiany w kernelu
import all; // z wpisów z kernela importujemy wszystko
export all; // oraz eksportujemy wszystkie prefiksy
kernel table 20; // jako tablicę routingu dla BIRDa używamy alternatywną o numerze 20 (o nazwie BGP)
learn on; // włączamy uczenie się nowych wpisow
}

protocol bgp MAIN {
local as 12881; // nasz lokalny numer ASN
direct;
preference 1000; // lokalna waga/preferencja interfejsu
next hop self; // rozglaszamy ze sami jestesmy brama
source address 10.0.5.108; // nasz adres zrodlowy dla tej sesji BGP
neighbor 10.0.5.99 as 6619; // dane naszego sasiada
import all; // importujemy wszystko – NIE ZALECAMY TEGO!
export all; // exportujemy wszystko co mamy w tablicy routingu – KONIECZNIE TUTAJ MUSZA ZNALEZC SIE FILTRY!!!
}

Performance i stabilność

BIRD generalnie po zainstalowaniu z repozytorium powinien bez problemu startować przy każdym uruchomieniu się EdgeRoutera i zasadniczo nie wymagane jest stosowanie dodatkowych „watchdogów” – chociaż możemy bez większego problemu zainstalować pakiet monit, który przy prostej konfiguracji pozwoli nam uruchomić ponownie BIRDa w razie „wywalenia się”.

Działanie BIRDa możemy monitorować za pomocą komendy birdc i tutaj generalnie należy sięgnąć do dokumentacji, gdyż składnia w niczym nie przypomina tej z Cisco czy z Quaggi.  Dla monitorowania generalnie zużycia pamięci i obciążenia procesora proponuje od razu z repozytorium doinstalować pakiet htop który pozwala również na monitorowanie obciążenia nie tylko procesora przez software, ale również pozwala zobaczyć obciążenie procesora przez hardware.

Dla przykładu – 3 pełne tablice BGP oraz 6 lokalnych sesji BGP w przypadku BIRDa wymaga ok. 140MB pamięci operacyjnej co jest ilością śmiesznie małą. Czas konwergencji i przeliczenia tras zajmuje stosunkowo niewielką ilość czasu i zajmuje z zegarkiem w ręku ok. 30 sekund na maszynie pokroju ER-PRO.

Poprawnie skonfigurowany router BGP pozwala przerzucić sumarycznie ok. 2-3Gbit/s ruchu. Co myślę jak na sprzęt za 1500zł jest ilością wystarczającą i zarazem imponującą!h