BGP w małej sieci: kiedy routing dynamiczny zamiast tras statycznych

Centrala i dwa oddziały są połączone tunelami IPsec, a każdy oddział ma drugi tunel przez LTE. Trasy są statyczne: główna i zapasowa z gorszą odległością administracyjną. W oddziale pada światłowód. Router oddziału przechodzi na tunel zapasowy, ale centrala nadal odpowiada tunelem głównym, bo jej interfejs tunelu nie zmienił stanu. Pakiety z oddziału docierają do centrali, a odpowiedzi giną.

Routing dynamiczny nie jest zarezerwowany dla operatorów. Przy kilku lokalizacjach i zapasowych ścieżkach sesja BGP działa jak kontrola zdrowia wspólna dla obu końców tunelu: gdy się zrywa, obie strony wycofują trasy niemal jednocześnie. Warunkiem są filtry i limity od pierwszego dnia, bo BGP bez nich rozsyła wszystko, co dostanie.

Kiedy trasy statyczne w zupełności wystarczą

Jedna lokalizacja z jednym wyjściem do internetu nie potrzebuje routingu dynamicznego: stacje mają bramę domyślną, a zapora trasę domyślną do operatora. Drugie łącze tego nie zmienia, bo przełączeniem ruchu wychodzącego zajmuje się kontrola zdrowia łączy, opisana we wpisie o dwóch łączach internetowych. Dwie lokalizacje z jednym tunelem to po jednej trasie z każdej strony.

Typowe sygnały, że trasy statyczne przestają wystarczać:

Każda nowa podsieć wymaga zmian na kilku routerach, a pominięcie jednego daje sieć działającą „prawie wszędzie”.
Tunele zapasowe obsługują trasy z gorszą odległością administracyjną, przełączane wyłącznie stanem interfejsu.
Każda strona tunelu ocenia stan ścieżki osobno, więc przełączenie bywa jednostronne.

! trasa główna przez tunel na łączu światłowodowym
ip route 10.20.0.0/16 10.255.1.2
! trasa zapasowa przez tunel LTE, odległość administracyjna 250
ip route 10.20.0.0/16 10.255.2.2 250

Trasa zapasowa wchodzi do tablicy routingu dopiero wtedy, gdy adres 10.255.1.2 przestaje być osiągalny, zwykle po przejściu interfejsu tunelu w stan nieaktywny. Interfejsy tunelowe w Linuksie (VTI, XFRM) pozostają aktywne także przy niedziałającym IPsec, a w wielu zaporach stan interfejsu zależy od wykrywania martwego partnera (DPD). Dobry plan adresacji, z jednym blokiem /16 na lokalizację, ogranicza liczbę wpisów, ale nie zmienia tego, że trasa statyczna nie wie, czy ścieżka działa.

Dlaczego BGP, a nie OSPF

BGP zestawia sesję TCP na porcie 179 z sąsiadem wpisanym w konfiguracji. Nie wymaga multicastu ani wspólnego segmentu sieci, więc działa po każdym tunelu, którym przechodzi zwykły ruch IP. Ręcznie wpisani sąsiedzi oznaczają, że wiadomo, z kim router wymienia trasy.

Drugą zaletą jest polityka na poziomie sąsiada. Lista prefiksów określa, co wolno przyjąć i co wolno ogłosić. Local-preference wskazuje preferowane wyjście w obrębie jednego systemu autonomicznego (AS). AS-path prepend, czyli wielokrotne dopisanie własnego numeru AS, wydłuża trasę w oczach sąsiadów z innych AS. BGP obsługują zapory (FortiGate, MikroTik, pfSense i OPNsense przez pakiet FRR), Linux z FRR oraz bramy VPN w AWS i Azure.

OSPF jest uczciwą alternatywą wewnątrz jednej lokalizacji z kilkoma routerami lub przełącznikami L3: sąsiedzi wykrywają się sami, a preferencję ścieżki ustawia koszt interfejsu. Routery w obszarze muszą jednak mieć tę samą bazę stanu łączy, więc nie da się odfiltrować trasy od jednego sąsiada, a każda zmiana topologii rozchodzi się po całym obszarze, także przez łącza LTE. Redystrybucja tras między OSPF a BGP to osobne źródło błędów, dlatego mała firma powinna wybrać jeden protokół.

Centrala jako reflektor tras

Najprostszy układ to jeden prywatny AS (np. 65001) dla całej firmy i sesje iBGP po tunelach. Router nie przekazuje trasy od jednego sąsiada iBGP innym sąsiadom iBGP, więc bez dodatkowej konfiguracji każdy oddział potrzebowałby sesji z każdym innym. Reflektor tras (route reflector) w centrali przekazuje trasy oddziałów dalej, a każdy oddział ma z nim sesję na każdym ze swoich tuneli.

Adresy w przykładach: centrala 10.10.0.0/16, oddział A 10.20.0.0/16, oddział B 10.30.0.0/16, tunele główne w 10.255.1.0/24, zapasowe w 10.255.2.0/24, po jednej sieci /30 na tunel.

! zakres centrali w tablicy routingu, żeby polecenie network miało co ogłosić
ip route 10.10.0.0/16 blackhole
!
ip prefix-list PL-BRANCH-A seq 10 permit 10.20.0.0/16
ip prefix-list PL-BRANCH-B seq 10 permit 10.30.0.0/16
ip prefix-list PL-TO-BRANCHES seq 10 permit 10.10.0.0/16
ip prefix-list PL-TO-BRANCHES seq 20 permit 10.20.0.0/16
ip prefix-list PL-TO-BRANCHES seq 30 permit 10.30.0.0/16
!
! trasy z tunelu zapasowego: niższa preferencja
route-map RM-BACKUP-IN permit 10
 set local-preference 50
!
router bgp 65001
 bgp router-id 10.10.0.1
 bgp log-neighbor-changes
 neighbor BRANCHES peer-group
 neighbor BRANCHES remote-as 65001
 neighbor BRANCHES password <hasło-sesji>
 ! BFD wymaga uruchomionego demona bfdd
 neighbor BRANCHES bfd
 ! oddział A: tunel główny i zapasowy
 neighbor 10.255.1.2 peer-group BRANCHES
 neighbor 10.255.2.2 peer-group BRANCHES
 ! oddział B: tunel główny i zapasowy
 neighbor 10.255.1.6 peer-group BRANCHES
 neighbor 10.255.2.6 peer-group BRANCHES
 !
 address-family ipv4 unicast
  network 10.10.0.0/16
  neighbor BRANCHES route-reflector-client
  neighbor BRANCHES next-hop-self force
  neighbor BRANCHES prefix-list PL-TO-BRANCHES out
  neighbor BRANCHES maximum-prefix 20
  neighbor 10.255.1.2 prefix-list PL-BRANCH-A in
  neighbor 10.255.2.2 prefix-list PL-BRANCH-A in
  neighbor 10.255.2.2 route-map RM-BACKUP-IN in
  neighbor 10.255.1.6 prefix-list PL-BRANCH-B in
  neighbor 10.255.2.6 prefix-list PL-BRANCH-B in
  neighbor 10.255.2.6 route-map RM-BACKUP-IN in
 exit-address-family

Polecenie network ogłasza prefiks tylko wtedy, gdy dokładnie taki prefiks jest w tablicy routingu, stąd trasa typu blackhole dla zakresu centrali. Ruch do nieistniejących podsieci jest odrzucany zamiast krążyć. bgp log-neighbor-changes zapisuje każdą zmianę stanu sesji w logu.

Tunel zapasowy z niższą preferencją

Local-preference jest jednym z pierwszych kryteriów wyboru najlepszej trasy, przed długością ścieżki AS. Wyższa wartość wygrywa, a domyślna wynosi 100. Centrala nadaje trasom z tunelu zapasowego wartość 50, a oddział robi to samo po swojej stronie. Gdy sesja na tunelu głównym się zrywa, oba końce usuwają jej trasy i niemal jednocześnie przechodzą na zapasowe, a po ponownym zestawieniu sesji wracają same. Ta sama polityka na oddziale z FortiGate:

config router route-map
    edit "RM-BACKUP-IN"
        config rule
            edit 1
                set set-local-preference 50
            next
        end
    next
end
config router bgp
    set as 65001
    set router-id 10.20.0.1
    config neighbor
        edit "10.255.1.1"
            set remote-as 65001
        next
        edit "10.255.2.1"
            set remote-as 65001
            set route-map-in "RM-BACKUP-IN"
        next
    end
    config network
        edit 1
            set prefix 10.20.0.0 255.255.0.0
        next
    end
end

Zakres oddziału też musi być w tablicy routingu, np. jako trasa statyczna z set blackhole enable. Filtry tworzy się w config router prefix-list i przypisuje polami sąsiada prefix-list-in i prefix-list-out, a hasło sesji polem password. W CLI FortiOS znak ? wywołuje pomoc kontekstową, więc hasło lepiej generować bez niego.

BGP z operatorem

Sesja BGP z operatorem, czyli ogłaszanie własnych adresów przez dwa łącza, wymaga publicznego numeru AS i adresów niezależnych od operatora. Przydziela je RIPE NCC, zwykle za pośrednictwem LIR, a wniosek o numer AS wymaga uzasadnienia, najczęściej połączeń z co najmniej dwiema sieciami. Najmniejsza sieć IPv4 powszechnie przyjmowana w internecie to /24, a pula IPv4 RIPE NCC jest wyczerpana, więc adresy się kupuje lub dzierżawi. Małej firmie zwykle wystarczą dwa łącza z przełączaniem, a BGP zostaje wewnątrz jej sieci.

Zabezpieczenia sesji

Bez filtrów pomyłka w jednym oddziale, np. ogłoszenie trasy domyślnej, trafia do wszystkich routerów.

Zasada	Przed czym chroni	FRR
Filtr prefiksów na wejściu	trasą domyślną lub cudzym zakresem od sąsiada	`prefix-list … in`
Filtr prefiksów na wyjściu	wyciekiem tras, np. sieci zarządzania	`prefix-list … out`
Limit prefiksów	zalaniem tablicy przy błędzie w filtrze	`maximum-prefix 20`
Hasło sesji	sesją z nieuprawnionego urządzenia	`password`
BFD lub krótsze liczniki	minutami ruchu w martwy tunel	`bfd`, `timers 10 30`
Prywatny numer AS	kolizją z numerami publicznymi	64512–65534

Przekroczenie limitu prefiksów domyślnie zamyka sesję: zerwana sesja oddziału jest mniejszym problemem niż setki błędnych tras. redistribute connected ogłasza wszystkie podłączone sieci, także zarządzania i tuneli, więc bez route-map nie powinno się go używać.

Hasło sesji to opcja TCP MD5 (RFC 2385), obsługiwana przez zapory i FRR. Nowszy TCP-AO (RFC 5925) jest bezpieczniejszy, ale jego obsługę trzeba sprawdzić po obu stronach. Hasło nie szyfruje sesji; w tunelu robi to IPsec.

Domyślne liczniki BGP w wielu implementacjach to 60 s między komunikatami keepalive i 180 s do uznania sąsiada za niedostępnego, więc bez BFD przełączenie może trwać trzy minuty. BFD w FRR domyślnie wysyła pakiety co 300 ms i po trzech brakujących uznaje ścieżkę za martwą. Musi być włączone po obu stronach sesji.

Statyczne, OSPF czy BGP

Kryterium	Trasy statyczne	OSPF	BGP
Typowy zakres	1–2 lokalizacje, jedna ścieżka	jedna lokalizacja, kilka routerów L3	kilka lokalizacji, tunele zapasowe
Wykrycie awarii ścieżki	stan interfejsu lub osobny monitor	wbudowane, opcjonalnie BFD	wbudowane, opcjonalnie BFD
Spójność obu końców	każda strona osobno	wspólna baza stanu łączy	jedna sesja dla obu stron
Nowa podsieć	zmiana na wielu urządzeniach	automatycznie	w zakresie lokalizacji bez zmian
Filtrowanie per sąsiad	nie dotyczy	tylko na granicy obszaru	pełne
Wybór ścieżki	odległość administracyjna	koszt interfejsu	local-preference, AS-path
Bramy VPN w chmurze	nie	zwykle nie	tak
Próg wejścia	najniższy	średni	najwyższy, filtry od początku

Sprawdź u siebie

Na routerze z FRR polecenia pokazują stan sesji, trasy wpisane przez BGP i prefiksy ogłaszane sąsiadowi.

# vtysh wymaga uprawnień roota lub członkostwa w grupie frrvty
vtysh -c "show bgp summary"
vtysh -c "show ip route bgp"
# wszystkie ścieżki do zakresu oddziału A, z local-preference i oznaczeniem najlepszej
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"
# prefiksy ogłaszane oddziałowi A przez tunel główny
vtysh -c "show ip bgp neighbors 10.255.1.2 advertised-routes"

Każdy sąsiad powinien mieć liczbę w kolumnie State/PfxRcd; Active, Connect lub Idle oznacza brak sesji. Krótki czas w kolumnie Up/Down przy sąsiedzie, którego nikt nie zmieniał, wskazuje na niestabilny tunel. Najlepsza ścieżka (best) do oddziału powinna prowadzić przez tunel główny z local-preference 100, a ogłaszane prefiksy pokrywać się z PL-TO-BRANCHES.

Na FortiGate te same informacje pokazują polecenia get.

get router info bgp summary
get router info routing-table bgp
get router info bgp neighbors 10.255.1.1 advertised-routes

Dobry wynik na oddziale A: liczba w State/PfxRcd przy obu sąsiadach, trasy do 10.10.0.0/16 i 10.30.0.0/16 przez 10.255.1.1 i tylko 10.20.0.0/16 na liście ogłaszanych prefiksów.

Ze stacji w oddziale widać, którędy faktycznie idzie ruch do centrali.

Find-NetRoute -RemoteIPAddress 10.10.1.10
Get-NetRoute -AddressFamily IPv4 | Where-Object NextHop -ne '0.0.0.0'
tracert -d -h 6 10.10.1.10

Stacja ma najczęściej tylko trasę domyślną do routera oddziału. Drugi skok w tracert to zwykle adres centrali na tunelu głównym (10.255.1.1); adres tunelu zapasowego (10.255.2.1) bez znanej awarii oznacza ruch przez LTE.

ip route
ip route get 10.10.1.10
traceroute -n -m 6 10.10.1.10

ip route get pokazuje trasę wybraną dla konkretnego adresu, a traceroute czyta się jak tracert.