Skip to content

regisu blog

Blog z notatkami …

Archive

Category: BGP

Parę linków bardzo przydatnych przy rozwiązywaniu problemów z BGP.

Polskie:

HAWE
THINX (dawniej ACX) – należy wybrać node THINX
TPIX
(AS 29535)
TPSA (AS 5617)
EPIX
PLIX
NETIA
TKT

Zagraniczne:

LEVEL3
TINET (inaczej TISCALI a obecnie INTELIQUENT)
TELIA
ATRATO

Kiedyś dość mocno zastanawiałem się o co chodzi w tych magicznych terminach i czym się one od siebie różnią.

Otóż PA czyli Provider Aggregatable to adresy wydzielone z puli, którą posiada nasz ISP. Nie należą niestety do nas i z chwilą kiedy rezygnujemy z usług tego operatora to musimy się z nimi pożegnać. Są plusy i minusy tego rozwiązania:

+ nie musimy kupować routera do BGP, zarządzać nim i w ogóle babrać się w routing’u jako takim.

+ nie martwimy się o aktualizację wpisów w RIPE i takich tam dziwacznych rzeczy, które na początku mogą się wydawać straszne.

+ nie musimy płacić naszemu LIR’owi kasy. Tzw. sponsoring LIR.

gdy chcemy zmienić operatora to niestety musimy też zmienić adresy, gdyż należą one do ISP, a nie do nas.

raczej wyklucza to jakiś rozsądny multihoming, gdyż nawet mając kilku operatorów i adresy od nich – każdy i tak będzie rozgłaszał swoją klasę adresową. Czyli gdy pada nam jeden ISP to adresy, które od niego dostaliśmy stają się chwilowo bezużyteczne. Można niby kombinować, ale jest z tym sporo zachodu.

Drugą opcją są adresy PI czyli Provider Independent. Jest to pula, którą dostajemy od RIPE i nie zależy ona od żadnego operatora. Dodatkowo potrzebujemy jeszcze numer ASN, który także przydziela RIPE. Ten typ adresacji posiada również swoje plusy i minusy:

+ multihoming.

+ daje większe możliwości w sterowaniu ruchem idącym do/ z sieci internet.

+ stajemy się niezależni – rezygnując z usług danego operatora zachowujemy swoje adresy.

trzeba płacić LIR’owi kasę za tzw. sponsoring LIR.

trzeba posiadać router BGP i admina, który potrafi tym sensownie zarządzać.

O przydział klasy adresowej czy też numeru ASN nie występujemy bezpośrednio do RIPE tylko do LIR’a, którym może być np. nasz ISP (ale nie musi). Spis Polskich LIR’ów można znaleźć -> tutaj. Dopiero on występuje z przygotowanym przez nas wnioskiem do RIPE. Podpisujemy z nim wcześniej umowę na tzw. „sponsoring LIR” i płacimy mu za to, że pomaga nam procedować wnioski w RIPE, a on z kolei płaci RIPE’owi za to, że jest LIR’em więc kółko się zamyka.

Metryka – służy do wyboru najlepszej trasy w przypadku gdy mamy ich do danego celu kilka. Im mniejsza metryka tym lepiej.

  • Trasy są domyślnie dodawane do tablicy routingu jeśli:
    • interfejs jest w stanie UP
    • interfejs ma przypisany adres IP(manualnie lub przez DHCP)

Atrybuty tras BGP według typów

  • Wellknown Mandatory – muszą być obsługiwane przez wszystkie implementacje BGP i występują w każdym pakiecie UPDATE (Jeśli w UPDATE brakuje jednego z atrybutów typu Wellknown to do sąsiada jest wysyłana błąd NOTIFICATION).
    • ORIGIN – typ pochodzenia:
      • IGP – zdefiniowane w BGP poprzez komendę network
      • EGP – nauczone od sąsiadów przez eBGP
      • INCOMPLETE – jeśli trasa została redystrybuowana do BGP z innego protokołu routingu nie ważne czy statycznego czy dynamicznego
    • AS_PATH – lista systemów autonomicznych przez jakie podróżowała informacja o tasie
    • NEXT_HOP – adres peera od którego dostaliśmy UPDATE z daną trasą
  • Wellknown Discretionary– muszą być wspierane przez wszystkie implementacje BGP, ale są opcjonalne jeśli chodzi o wysyłanie ich.
    • LOCAL_PREF – metryka istniejąca w obrębie jednego AS’a, określająca, która ścieżka wyjścia dla danej trasy jest najlepsza.
    • ATOMIC_AGGREGATE – zawiera numery AS, które zostały odrzucone przez agregację.
  • Optional Transistive– nie musi być rozpoznawany przez implementację BGP. Jeśli nie jest rozpoznawany, ale jest ma ustawioną flage TRANSISTIVE to jest po prostu przekazywany dalej.
    • AGGREGATOR – ID oraz numer AS routera, który dokonał sumaryzacji tras.
    • COMMUNITY – tag trasy
  • Optional Nontransistive– nie musi być rozpoznawany przez implementację BGP. Jeśli nie jest rozpoznwany i nie ma ustawionej flagi TRANSISTIVE to nie jest przekazywany dalej.
    • MED (Multi Exit Dicriminator) – metryka dla zewnętrznych sąsiadów mówiąca którędy najlepiej osiągnąć lokalny AS (domyślnie 0).
    • CLUSTER_ID – ID klastra z którego pochodzi dana trasa (wykorzystywane przy route-reflectorach i konfederacjach).
    • ORIGINATOR_ID – ID route-reflectora.

Algorytm wyboru trasy

  1. Weigth (im wyższa tym lepiej) – używana tylko w Cisco. Preferencja wyboru trasy ustawiana przez administratora. Działa lokalnie na routerze.
  2. Local preference (im wyższa tym lepiej)
  3. Self-originated (True)
  4. AS Path (najkrótsza najlepsza)
  5. Origin (IGP<EGP<INCOMPLETE)
  6. MED (najniższy najlepszy)
  7. Extrenal (eBGP over iBGP)
  8. IGP Cost (najniższy najlepszy)
  9. eBGP peering (najstarsze najlepsze)
  10. Router ID (najniższy ID)
  11. Najniższy adres IP neighbora

Inne

  • Na routerze może być skonfigurowany tylko jeden proces BGP!
  • Jeśli mamy skonfigurwany już jeden proces BGP to gdy wpiszemy komendę router bgp numer_as z innym numerem AS niż ten, z którym jest skonfigurowany obecny proces BGP, to dostaniemy błąd.
  • Dla sesji iBGP adres IP neighbora nie musi być bezpośrednio podłączony.
  • Dla sesji eBGP adres IP neighbora musi być bezpośrednio podłączony.

Definiowanie tras rozgłaszanych przez BGP

  • komenda network
  • redystrybucja np. tras statycznych <niezalecana jest redystrybucja z protokołów IGP>. Redystrybucja powoduje ustawienie atrybutu Origin jako INCOMPLETE.

BGP Synchronization

Reguła synchronizacji mówi o tym, żę router BGP nie powinien używać ani rozgłaszać do zewnętrznych sąsiadów, tras nauczonych przez iBGP, o ile trasy te nie są lokalne lub nauczone z protokołu IGP.

Synchronizacja jest domyślnie wyłączona na nowszych IOSach.

Resetowanie sesji BGP i wprowadzanie zmian w filtrach

Trzy drogi by uruchomić update:

  • hard reset – zrywa sesje i ustala ją od początku. Przez co wpływa na ruch.
  • soft reset – nie powoduje zerwania sesji BGP. Dla wyjściowych updateów jest wysyłany update zawierający zmiany.
  • route refresh – działa tylko dla in. Nowsze routery obsługują coś podobnego do soft reset, ale nie trzeba konfigurować przy neighborze soft-reconfiguration inbound, tylko od razu można w trybie EXEC użyć clear ip bgp * soft in

Peer groups

Peer groupy mogą polepszyć wydajność kiedy przetwarzane są update’y do sąsiadów BGP mających taką samą politykę wyjściową.

BGP Neighbor States

  • Idle – router przeszukuje tablicę routingu w celu znalezienia trasy do sąsiada
  • Connect – router znalazł trasę do sąsiada i zakończył three-way TCP handshake
  • Open sent – router wysłał wiadomość open, z parametrami sesji BGP
  • Open confirm – router odebrał potwierdzenie i zgodę na parametry do zestawienia sesji BGP
  • Established – sesja BGP została nawiązana

Są bardzo licznie wykorzystywane w BGP.

route-map nazwa_routemapy [[permit | deny] |  [sequence-number]]

– może mieć wiele wpisów o tej samej nazwie. Muszą się różnić tylko numerem sekwencyjnym

– wpisy w route-mapie są przetwarzane po kolei. Gdy np. pierwszy będzie się zgadzał(match), to reszta nie jest już sprawdzana.

– każdy wpis posiada zero lub więcej match‚y . Wpis bez match’a odnosi się do całego ruchu (tak jak any ACL’kach).

– jeśli ruch nie zostanie zmatch’owany to nie jest on modyfikowany, jest przetwarzany przez następny wpis.

– każdy wpis match może posiadać jeden lub więcej warunków. Jeśli choć jeden z nich jest spełniony, to reguła set jest wykonywana (OR).

– każda rote-map’a ma zero lub więcej wpisów set. Wpis jest wykonywany wtedy gdy wszystkie warunki match są spełnione „true”.

– każda route-map’a ma permit lub deny. Ruch który spełnia warunki permit jest przetwarzany przez route-map’ę. Ruch który nie spełnia warunków match lub ma deny nie jest przetwarzany przez route-map’ę.

– ruch który nie jest wprost dozwolony jest domyślnie zabroniony.

– jeśli route-map’a zawiera więcej match’y to wtedy, aby reguła set została wykonana, wszystkie warunki match muszą być spełnione (AND).