Skip to content

regisu blog

Blog z notatkami …

Archive

Category: Sieci

Oprócz sprzętu Cisco miałem okazję zarządzać też paroma switchami Della z serii 6000. Niestety producent nie pomyślał w nich totalnie o tym, że nawet<a może zwłaszcza!> sprzęt sieciowy wymaga backupu. Niby jest opcja w CLI przełącznika by zapisać obecny konfig jako backup, ale … na przełączniku. A to nijak nie pomoże w przypadku padu urządzenia, czy innej katastrofy, która spowoduje, że nie będzie można odczytać z niego tej konfiguracji.

Dlatego tez postanowiłem sam napisać sobie skrypt, który mi ten backup zrobi. Wykorzystałem do tego: pythona z biblioteką telnetlib i serwer tftp. Pewną rolę odegrał tu także plik /etc/hosts. 🙂

kontynuuj czytanie …

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

No tak dzisiaj musiałem zrobić małe sniffowanie ruchu na porcie do klienta, bo nie wiadomo skąd leci do niego 400Mbit którego nie powinno tam być.

No i natknąłem się na problemik jak zrobić port mirror na switch’u Dell’a. Na szczęście okazało się to banalne. Trzeba to zrobić tak:

  • Wchodzimy w tryb configure
  • Teraz trzeba podać port źródłowy, który chcemy mirror’ować oraz kierunek interesującego nas ruchu monitor session 1 source interface 1/g1 [tx, rx, both]
  • W razie potrzeby można dodać jeszcze kilka portów źródłowych
  • Następnie trzeba podać port docelowy, na który ten ruch ma być kopiowany monitor session 1 destination interface 1/g2
  • I na koniec trzeba daną sesję włączyć monitor session 1 mode

I to w zasadzie tyle.

Właśnie się dowiedziałem o istnieniu ciekawego makra:

switchport host

Jak go użyć i co powoduje?

Otóż wystarczy powyższą komendę wydać w trybie konfiguracji interfejsu fizycznego. Spowoduje ona:

  • Ustawienie portu na access
  • Włączenie spanning-tree portfast
  • Wyłączenie portchannel’a

Oczywiście makro przydaje się tylko wtedy, gdy zakładamy, że do tego portu będzie podłączony PC’et albo inne urządzenie końcowe. Podpięcie switcha może spowodować powstanie pętli, gdyż portfast od razu ustawi port w stan forwarding pomijając przy tym pozostałe dwa stany (listening i learning), przez co przełącznik nie ma szans wykryć pętli.

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 …

W niektórych sieciach portsecurity może być bardzo przydatną funkcją. Polega ona na kontroli dostępu do portów na podstawie MAC adresów. Aby włączyć porstecurity na porcie trzeba w konfiguracji portu wpisać:

switchport port-security

A następnie określić adresy MAC, których użycie na tym porcie ma być dozwolone. Można to zrobić na dwa sposoby:

  • poprzez ręczne ustawienie MAC’ów
  • naukę MAC’ów na podstawie ruchu na porcie (domyślnie)

kontynuuj czytanie …

DHCP snooping zabezpiecza sieć przed wpięciem nieautoryzowanego serwera DHCP, który mógłby namieszać np. podszywając się pod właściwy serwer, a następnie dokonując ataku typu Man in the Middle.

Gdy DHCP snooping jest włączony, porty na switch’u są dzielone na:

  • zaufane (trusted)
  • niezaufane (untrusted).

Prawowity serwer DHCP jest podłączony do zaufanego portu. Przełącznik przechwytuje wszystkie żądania pochodzące z niezaufanych portów przed wysłaniem ich dalej w sieć. Wszystkie odpowiedzi na żądania DHCP pochodzące z niezaufanego portu są odrzucane, a sam port jest wyłączany i znajduje się w stanie errdisable. kontynuuj czytanie …

Przydatna rzecz. Żeby działał ip helper address <adres ip serwera dhcp>, musi być włączona usługa service dhcp na cisco.