Skip to content

regisu blog

Blog z notatkami …

Archive

Tag: routing

Floating static route polega na tym, że konfigurujemy trasę statyczną z większym AD<Administrative Distance> niż to jakie ma dynamiczny protokół routingu od którego również tą trasę otrzymujemy. Dzięki temu, gdy wyleci nam trasa dynamiczna to do tablicy routingu wrzucona zostaje trasa statyczna, która normalnie jest ignorowana ze względu na wysoki AD.

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).

Nie raz już potrzebowałem szybko sprawdzić jak dany prefix jest widziany przez zagranicznych dostawców. Ale zawsze wiązało się to z wyszukaniem looking glass’a, wejściem na niego, wybraniem odpowiedniej opcji, wpisaniem prefixu itp. itd.. Jak się to robi odpowiednio często to ma się dość.

Na szczęście TINET umożliwia dostęp po telnecie do testowego route serwera, na którym można sprawdzić czy dany prefix znajduję się w tablicy routing’u, od kogo przyszedł, jakie ma community ustawione itp.

Ale telnetowanie się na rotue serwer i wpisywanie wszystkiego z palca też nie jest szczytem wygody. Dlatego napisałem sobie prosty skrypcik kontynuuj czytanie …

Routing można w debianie włączyć na kilka sposobów. Jednym z nich jest napisanie skryptu, który przy starcie wykonać linijkę:

echo "1" > /proc/sys/net/ipv4/ip_forward

Ale można też skorzystać z dedykowanego rozwiązania jakim jest sysctl. To interfejs który pozwala w dość elegancki sposób zmieniać dynamicznie parametry pracy jądra. Aby przekazywanie pakietów włączało się przy starcie wystarczy w pliku /etc/sysctl.conf dopisać lub odkomentować linijkę:

net.ipv4.ip_forward=1

Dzięki temu po restarcie systemu routing będzie działał.

Można oczywiście obejść się bez restartu, wystarczy przeładować ustawienia sysctl przy pomocy polecenia:

sysctl -p /etc/sysctl.conf