Techinka: Konfiguracja systemu Vyatta w ćwiczeniach
Autor: Łukasz Łaciak | Data: 09/06/11
| |
|
5. Routing statyczny.
Routing, czyli trasowanie, jest procesem pozwalającym na przesyłanie informacji w sieciach składających się z wielu węzłów, zwanych routerami. W pakietach wysyłanych z komputera-nadawcy określony jest adres docelowy, który jest analizowany przez każdy router po drodze i przypasowywany do tablic routingu, w których powinna znajdować się informacja, którym interfejsem przesyłać pakiety, aby trafił do celu.
Trasowanie statyczne polega na ręcznym ustalaniu możliwych ścieżek do sąsiednich sieci i dopisywaniu ich do tablic routingu. Przy trasowaniu statycznym nie ma konieczności wymiany informacji o stanach łącz między routerami, jak ma to miejsce w przypadku protokołów routingu dynamicznego, więc jest to proces niezależny na każdym z routerów.
5.1. Topologia.
Obraz 5-1: Topologia sieci użytej w zadaniu
Z rysunku topologii została usunięta część mówiącą o połączeniu komputera R1 z Internetem, gdyż rysunek byłby zbyt duży, a co za tym idzie nieczytelny.
5.2. Przygotowanie wirtualnych sieci.
Topologia uległa znaczącej zmianie, więc przed uruchomieniem maszyn trzeba najpierw ustawić odpowiednie sieci.
R1:
eth0 - NAT (VMnet8)
eth1 - VMnet2
eth2 - VMnet5
R2:
eth0 - VMnet2
eth1 - VMnet3
R3:
eth0 - VMnet3
eth1 - VMnet6
eth2 - VMnet4
R4:
eth0 - VMnet4
eth1 - VMnet5
Host:
eth0 - VMnet6
5.3. Cel oraz założenia.
W niniejszym ćwiczeniu zostanie przeprowadzona konfiguracja ze statycznym ustalaniem tras, oraz z uwzględnieniem możliwości awarii jednego z interfejsów.
Zalecana jest znajomość poprzednich ćwiczeń oraz protokołu ICMP.
5.4. Konfiguracja.
Mimo, że na rysunku topologii nie ma mowy o tym mowy, to konfiguracja interfejsu eth0 maszyny R1 oraz bramy domyślnej i maskarady będzie taka sama jak w ćwiczeniu "3. Maskarada". Można ją przywrócić poleceniem 'load' dla komputerów R1, R2 i R3, oczywiście, jeśli została zapisana. Tym samym poleceniem, maszynom R4 i Host zostanie przywrócona konfiguracja z ćwiczenia "2. Początkowa konfiguracja i aktualizacja". Do ukończenia tego ćwiczenia nie jest wymagane połączenie z Internetem.
Poniższe polecenia dostosowują konfigurację do wymogów topologii.
R1:
delete interfaces ethernet eth1 address
set interfaces ethernet eth1 address 10.50.0.1/28
set interfaces ethernet eth2 address 10.50.30.2/28
commit
R2:
delete interfaces ethernet eth0 address
set interfaces ethernet eth0 address 10.50.0.2/28
set interfaces ethernet eth1 address 10.50.10.1/28
set system gateway-address 10.50.0.1
commit
R3:
delete interfaces ethernet eth0 address
set interfaces ethernet eth0 address 10.50.10.2/28
set interfaces ethernet eth1 address 192.168.0.1/24
set interfaces ethernet eth2 address 10.50.20.1/28
set system gateway-address 10.50.10.1
commit
R4:
delete interfaces ethernet eth0 address
set interfaces ethernet eth0 address 10.50.20.2/28
set interfaces ethernet eth1 address 10.50.30.1/28
set system gateway-address 10.50.20.1
commit
Host:
delete interfaces ethernet eth0 address
set interfaces ethernet eth0 address 192.168.0.2/24
set system gateway-address 192.168.0.1
commit
Każdy komputer powinien móc pingować wszystkie interfejsy sąsiedniej maszyny w kierunku przeciwnym do wskazówek zegara. Jest to możliwe dzięki mechanizmowi bramy domyślnej. Dzięki niemu pakiety kierowane z komputera R4 powinny dobrzeć do R1, ale odpowiedź nie powinna wrócić. I to będzie ćwiczenie właśnie o tym jak kierować ruchem za pomocą tras statycznych.
Teraz jest dobry moment, aby zapisać poleceniem 'save' konfigurację na każdej z maszyn, ponieważ przyda się ona w kolejnych ćwiczeniach jako konfiguracja wejściowa.
Na maszynie R1 poleceniem 'sudo tshark -i eth1' został uruchomiony sniffer, czyli program do podglądu ruchu sieciowego, o nazwie Tshark. Nasłuchuje na interfejsie eth1. Na komputerze R4 został uruchomiony program Ping poleceniem 'ping 10.50.0.1', a więc pakiety są kierowane do R1. [Obraz 5-2].
Obraz 5-2: Efekt działania sniffera
Jak widać na powyższym obrazie, żądanie echa ICMP Echo Request dociera do komputera R1, ale odpowiedzi nie widać. Wiadomość zwrotna, Echo Reply została skierowana na adres bramy domyślnej przez interfejs eth0, ponieważ maszyna R1 nie zna trasy do komputera o adresie 10.50.20.2.
Aby poinstruować router R1, co ma zrobić z pakietami od innych maszyn wystarczy wpisać poniższe polecenia.
Składnia użytych poleceń:
- 'set protocols static route next-hop ' -określa przez jaki adres ma zostać wykonany przeskok, aby osiągnąć daną sieć.
R1:
set protocols static route 10.50.10.0/28 next-hop 10.50.0.2
set protocols static route 10.50.20.0/28 next-hop 10.50.0.2
set protocols static route 192.168.0.0/24 next-hop 10.50.0.2
commit
W tym momencie router R1 będzie już wiedział którym interfejsem ma odpowiadać na zapytania ICMP generowane przez program Ping na komputerze R4, lecz R4 nie dostanie odpowiedzi, ponieważ maszyny R2 i R3 nadal nie wiedzą co robić z tymi pakietami i zwracają je z powrotem na adresy swoich bram domyślnych. Aby rozwiązać problem do końca, trzeba skonfigurować także trasy na komputerze R2.
R2:
set protocols static route 10.50.20.0/28 next-hop 10.50.10.2
set protocols static route 192.168.0.0/24 next-hop 10.50.10.2
commit
Komputery uzyskują dostęp do sieci 10.50.30.0/28 również dzięki bramom domyślnym, ponieważ bramy te prowadzą pakiety do routera R1, a ta sieć jest do niego bezpośrednio podłączona, co można zobaczyć wywołując tablicę routingu poleceniem 'show ip route' w trybie operacyjnym [Obraz 5-2].
Obraz 5-3: Tablica routingu komputera R1
Istnieje bardzo użyteczny program do sprawdzania przebiegu trasy. Zwie się on Traceroute. Na obrazie 5-3 pokazane jest wywołanie go poleceniem 'traceroute 10.50.0.1' z komputera Host.
Obraz 5-4: Trasa z maszyny Host do R1
Powyższy obraz ukazuje trasę Host->R1, wraz adresami interfejsów wejściowych kolejnych komputerów po drodze. Dlaczego akurat interfejsy, którymi pakiety wchodzą do komputerów, a nie wychodzące? Ponieważ program Traceroute, tak samo jak Ping, korzysta z protokołu ICMP do diagnostyki. Odpytuje każdą maszynę po drodze, a ona odpowiadając mu komunikatem Echo Reply, korzysta właśnie z interfejsów skierowanych w stronę komputera pytającego.
Dla przypomnienia przydatnego polecenia, na obrazie 5-4 zaprezentowana została gałąź drzewa konfiguracji dotycząca protokołów routera R1.
Obraz 5-5: Efekt działania polecenia 'show protocols'
5.5. Działanie w przypadku awarii węzła.
Zasymulowana zostanie awaria komputera R2, odłączając jego interfejs eth0.
R2:
delete interfaces ethernet eth0
commit
Komunikacja na trasach, w których udział brał usunięty interfejs zanikła. Aby ją przywrócić, należy usunąć wpisy o trasach i skonfigurować nowe.
R1:
delete protocols static
set protocols static route 10.50.10.0/28 next-hop 10.50.30.1
set protocols static route 10.50.20.0/28 next-hop 10.50.30.1
set protocols static route 192.168.0.0/24 next-hop 10.50.30.1
commit
R4:
set protocols static route 10.50.10.0/28 next-hop 10.50.20.1
set protocols static route 192.168.0.0/24 next-hop 10.50.20.1
commit
Przykładowe pakiety z routera R1 do komputera Host będą dochodzić, jednak znowu pojawi się problem z pakietami powracającymi, ponieważ bramy domyślne kierują je w stronę usuniętego interfejsu. Aby temu zaradzić, należy przekonfigurować bramy domyślne maszyn R2, R3 i R4 lub dodać na nich wpisy routingu statycznego. Mimo, że ćwiczenie to traktuje o routingu statycznym, zostanie wykonana opcja pierwsza - rekonfiguracja bram, ponieważ tak jest bardziej elegancko i nie dodaje się zbędnych wpisów do tablic routingu.
R2:
set system gateway-address 10.50.10.2
commit
R3:
set system gateway-address 10.50.20.2
commit
R4:
set system gateway-address 10.50.30.2
commit
W tym momencie pakiety z komputera R1 do maszyny Host powinny już dochodzić, a trasa powinna być w pełni sprawna, co można sprawdzić poleceniem 'traceroute 192.168.0.2' [Obraz 5-5].
Obraz 5-6: Trasa R1->Host
Routing statyczny jest najprostszą formą trasowania, jednak ma on niewątpliwe zalety. Jest dostępny w każdej sytuacji, nie używa wielu zasobów, jest bardzo prosty i przewidywalny. Jednak jest on odpowiedni tylko dla małych sieci lub dołączania pojedynczych urządzeń do sieci z działającym protokołem routingu dynamicznego, ponieważ nie posiada możliwości automatycznej adaptacji, jak te protokoły.
|
poprzednia strona (4. DHCP.) 
