Informacja dotycząca pojedynczej trasy zawiera: · adres docelowego hosta lub sieci;

2. Dynamiczne protokoły rutowania można sklasyfikować na kilka sposobów. Pierwszy związany jest z tym, jaką część sieci protokół obejmuje swym zasięgiem. Wyróżnić tutaj możemy: ·         Protokoły zewnętrzne (Exterior Gateway Protocols); ·         Protokoły wewnętrzne (Interior Gateway Protocols). Protokół klasyfikowany jako zewnętrzny odpowiada za wymianę informacji o rutingu pomiędzy dwiema niezależnymi domenami administracyjnymi, zwanymi często systemami autonomicznymi. Najpopularniejszym obecnie protokołem rutingu, wykorzystywanym pomiędzy systemami autonomicznymi jest BGP (Border Gateway Protocol). Charakterystyczną cechą protokołów zewnętrznych jest ich dobra skalowalność i przystosowanie do obsługi dużych sieci. Składają się zwykle z wielu podprotokołów, a ich implementacja jest dość skomplikowana.

4. Wewnętrzne protokoły rutingu stosowane są wewnątrz pojedynczej domeny administracyjnej. Oznacza to, że rutery należące do różnych domen, nie komunikują się ze sobą bezpośrednio. Protokoły posiadają prostszą implementację, w mniejszym stopniu obciążają procesor i pamięć rutera. Najczęściej wykorzystywanymi reprezentantami tej klasy protokołów są: RIP (Routing Information Protocol), OSPF (Open Shortest Path First) i IGRP i EIGRP (Enhanced Interior Gateway Protocol). RIP i OSPF są standardami otwartymi, IGRP i EIGRP są natomiast opracowane przez Cisco Systems i stosowane w ruterach tej firmy.

5. Innym kryterium klasyfikacji może być sposób w jaki wykorzystywane są przez protokoły rutingu informacje zawarte w tablicach rutingu i informacje dostarczane przez inne rutery. Wyróżnić tutaj możemy: ·         protokoły typu dystans-wektor (Distance - vector); ·         protokoły stanu łącza (Link - state). Reprezentantem protokołów typu dystans-wektor jest historyczny i mocno dziś krytykowany (aczkolwiek nadal używany) protokół RIP, opisywany szczegółowo w dokumentach RFC1058 (Routing Information Protocol. C.L. Hedrick) i RFC2453 (RIP Version 2. G. Malkin).

6. Protokoły typu dystans-wektor regularnie rozsyłają kompletne tablice rutingu. Pojedynczy zapis w tablicy dotyczący danej drogi w sieci zwykle określa, obok adresu przeznaczenia i adresu następnego „skoku”, ilość skoków do sieci docelowej (liczbę ruterów na drodze pakietu do sieci docelowej). Liczba skoków jest tutaj jedyną miarą jakości danej ścieżki. W odróżnieniu od protokołów dystans-wektor w protokołach typu stan łącza miara jakości danej trasy może być wyznaczona z wykorzystaniem kilku wskaźników takich jak: obciążenie sieci, pasmo przepustowości danego łącza, opóźnienie na łączu oraz inne parametry opisujące ruter. Dodatkowo, administrator sieci sam może zdefiniować miarę administracyjną dla danego interfejsu rutera wykorzystywaną przez proces rutingu. Ruter z protokołem stanu łącza nie przekazuje do sąsiednich ruterów informacji o miejscach, które można osiągnąć i w jaki sposób, lecz dostarcza informacje o topologii sieci. Przekazuje listę segmentów lub łączy, do których jest przyłączony bezpośrednio oraz stan tych łączy (czy funkcjonują i jaki koszt jest z nimi związany).

11. Protokół RIP przeznaczony jest dla środowiska o stosunkowo prostej topologii z niewielką liczbą ruterów połączonych łączami o takiej samej charakterystyce. Protokół ten, jako pierwszy protokół typu IGP (Interior Gateway Protocol), był powszechnie używany i darmowo dystrybuowany w systemie Unix BSD, jako proces demon o nazwie routed. Protokół ten funkcjonuje do dziś w najnowszych dystrybucjach systemów unixowych, aczkolwiek w nieco odświeżonej formie. RIP jest protokołem typu dystans-wektor. Nazwa ta wywodzi się od zastosowanego tutaj algorytmu Bellmana-Forda wyznaczania najkrótszych ścieżek w grafie obrazującym topologię sieci. RIP wymaga zaangażowania wszystkich ruterów (czasem również serwerów plików, aplikacji, bazodanowych, itp.) w proces utrzymywania aktualności tras i oceny ich długości.

12. Zasada działania rutera z protokołem RIP jest bardzo prosta. Każdy ruter jest zaprogramowany tak, aby rozgłaszał wszystkie cele (adresy sieci docelowych, czasem również hostów), które zna oraz odległości do nich. Co określony kwant czasu wysyła w sieć pełną informację o wszystkich trasach w znanej sobie topologii sieci. Po otrzymaniu podobnych informacji od innych ruterów zaczyna analizować wszystkie możliwe cele i obliczać (wykorzystując wspomniany algorytm Bellmana-Forda) najkrótsze ścieżki do nich. Tylko najkrótsza ścieżka dla danego celu jest zapisywana w tablicy rutingu. Tablica ta wykorzystywana jest przy wyborze drogi dla napływającego strumienia pakietów.

13. Kluczowym aspektem działania protokołów typu dystans-wektor jest to, że dowolny ruter zna tylko kolejny krok w sekwencji dostarczania pakietów do ich miejsca przeznaczenia. Protokół RIP funkcjonuje do dziś, jest szeroko używany i jest jedynym protokołem trasowania „rozumianym” przez wszystkie komputery używające systemów operacyjnych typu Unix. Niestety protokół ten posiada szereg wad i ograniczeń, które dyskwalifikują go w roli protokołu rutingu dla dużych sieci. Z założenia każdy ruter z uruchomionym protokołem RIP co 30 sekund wysyła tzw. aktualizacje RIP. Aktualizacje te to wszystkie zapisy dotyczące znanych tras z tablicy rutingu rutera. Jeśli więc tych tras jest dużo, kilka ruterów z protokołem RIP potrafi „skonsumować” znaczną część przepustowości sieci.

14. Informacja dotycząca pojedynczej trasy zawiera: ·         adres docelowego hosta lub sieci; ·         adres IP rutera (bramki) wysyłającego aktualizację; ·         wartość wskazującą odległość (w sensie liczby skoków) do celu. W momencie otrzymania aktualizacji trasy od sąsiedniego rutera, ruter porównuje przyjętą informację z zawartością własnej tablicy trasowania. W przypadku, gdy aktualizacja dotyczy nowej trasy, trasa jest dodawana do tablicy rutingu. Jeśli ruter otrzyma informację o istniejącej w tablicy trasie, z mniejszą liczbą skoków do danego celu, stary zapis o osiągalności tego celu jest zastępowany świeżą informacją. Oczywiście istnieje tutaj zabezpieczenie przed sytuacjami kiedy dana trasa przestaje funkcjonować (uszkodzenie linii, uszkodzenie rutera na drodze do sieci docelowej). Ruter RIP pamięta niestety tylko jedną, najlepszą trasę. W jego tablicy trasowania brak jest zapisów dotyczących tras alternatywnych.

15. Do sterowania sytuacjami awaryjnymi RIP używa czasomierzy. Obok zegara sterującego wysyłaniem aktualizacji tras (domyślnie co 30s) wykorzystywany jest zegar zliczający dla każdej z tras czas jaki upłynął od jej ostatniej aktualizacji. Jeżeli ruter nie otrzyma aktualizacji danej trasy w przeciągu 180 s trasa zaznaczana jest jako nieosiągalna. Po stwierdzeniu nieosiągalności trasy ruter wysyła specjalną wiadomość informującą sąsiadów o zaistniałej sytuacji. Po 270s nieosiągalna i zarazem nieaktualna trasa jest usuwana z tablicy rutingu rutera. Kolejne zegary noszą nazwę czasomierzy: aktualizacji (update), błędu (invalid) i usuwania (flush).

16. Podsumowując, protokół RIP posiada szereg ograniczeń i przez to nie nadaje się do wykorzystania w dużych sieciach. Najważniejsze z nich to, że : -          miarą jakości danej ścieżki RIP jest liczba skoków. RIP zakłada maksymalną liczbę skoków równą 15. Sieć, do której odległość wynosi 15 skoków jest dla protokołu RIP nieosiągalna; -          liczba skoków jest jedyną miarą jakości danej trasy, co w przypadku istnienia alternatywnych, „szybszych” tras, ale o większej liczbie skoków, przekreśla ich zastosowanie w procesie wyboru drogi dla pakietu; -          RIP w wersji 1 nie potrafi obsługiwać podsieci o różnych wielkościach (ruting klasowy); -          okresowa wymiana całych tablic rutingu wprowadza znaczne obciążenie sieci; -          konwergencja sieci z protokołem RIP jest wolniejsza niż dla protokołów typu link-state; -          sieci RIP są sieciami płaskimi. Nie zakłada się ich podziału na obszary, nie wyznacza się granic tych obszarów. Pewne modyfikacje wprowadzone zostały w RIP2 (VLMS, autentication, multicast routing updates, "split horizon"). Nadal jednak podstawową miarą rutingu pozostaje liczba skoków, nadal jej maksymalna wartość to 15 (wartość 16 odpowiada nieosiągalności miejsca przeznaczenia).

17. Algorytm Split Horizon Ruter nigdy nie wysyła aktualizacji dotyczących danej sieci (trasy) zapisanej w tablicy rutingu na interfejs, z którego dowiedział się o tej sieci (trasie). eth0 Sieć 2 Ruter A Ruter B Sieć 1 Sieć 0 C - Sieć 1 C – Sieć 0 R – Sieć 2 via Ruter B C - Sieć 2 C – Sieć 0 R – Sieć 1 via Ruter A Jakie mogłyby być konsekwencje wysyłania np.przez Ruter A aktualizacji informującej o osiągalności Sieci 2 w przypadku upadku interfejsu eth0 Rutera B ?

18. Split Horizon z odtrutką Algorytm jest zmodyfikowanym algorytmem Split Horizon. Modyfikacja polega na tym, że ruter zamiast niepodawania tras do źródła, informuje źródła o trasach, ale trasom tym przypisuje metrykę (liczbę skoków) równą 16, co z punktu widzenia protokołu RIP jest „nieskończonością”. Ruter źródłowy ignoruje więc informację o trasie z taką metryką. Algorytm Split Horizon i Split Horizon z odtrutką zawodzi w przypadku konfiguracji sieci jak na rysunku poniżej. B A Ruter-A Ruter-B Ruter-C Ruter-D C

19. Reguła dzielenia horyzontu jest domyślnie włączona w konfiguracji interfejsów. Po jej wyłączeniu można doprowadzić do pętli między ruterami. Aby wyłączyć regułę wystarczy w trybie konfiguracji interfejsu wydać polecenie: no ip split-horizon Skutek sprawdzamy poleceniem sh ip int s0/0 Skutki wyłączenia reguły mogą być czasem obserwowane po włączeniu śledzenia rip debug ip rip Zad. Przygotować w domu odpowiedni eksperyment na laboratorium

20. Aktualizacje wyzwalane i wstrzymania (Triggered Updates and Hold-Downs) • Czas potrzebny do uaktualnienia wszystkich tablic trasowania przez protokoły rutingu nazywamy czasem zbieżności (convergence time). • Aby przyspieszyć proces konwergencji w protokole RIP występują aktualizacje wyzwalane, co polega na tym, że zawsze kiedy ruter z aktywnym protokołem RIP dowiaduje się o zmianie topologii sieci, nie będzie czekał do następnej aktualizacji trasowania, aby wysłać tę informację, wyśle ją natychmiast jako aktualizację wyzwalaną). • Zasada wstrzymania oznacza, że kiedy trasa jest usunięta (ruter otrzyma aktualizację wyzwalaną) zwykłe aktualizacje dotyczące tej trasy nie będą akceptowane przez czas określony przez czasomierz wstrzymania (hold down timer).

23. Protokół RIP - parametry czasowe Update (czas aktualizacji) - czas wysyłania kolejnych aktualizacji. W protokole RIP domyślnie około 30 sekund.Invalid (trasa nieważna) - zegar uruchamiany razem z ostatnią aktualizacją. Przy braku aktualizacji, po przekroczeniu tego czasu trasa oznaczana jest jako nieważna, ale nie jest automatycznie usuwana z tabeli routingu, tylko przechodzi w tryb przytrzymania trasy (hold down). W protokole RIP czas ten wynosi domyślnie 180 sekund (6 czasów aktualizacji).Hold down (przytrzymywanie trasy) - czas przetrzymywania w tabeli routingu tras nieważnych (nieaktualizowanych). Trasa w tym trybie oznaczana jest w tabeli routingu jako "possibly down", ale jest cały czas wykorzystywana do wysyłania pakietów i router nie akceptuje ewentualnych ogłoszeń tej trasy od innych sąsiadów. Zastosowano tutaj zasadę, że lepiej przytrzymać w tabeli routingu trasę być może uszkodzoną, niż zbyt szybko przełączyć się na inną trasę do tej samej sieci, ale z wyższą metryką. W protokole RIP czas ten wynosi domyślnie 180 sekund (chyba że wcześniej skończy się czas flush).Flush (usuwanie trasy z tabeli) - czas, po którym trasa nieaktualizowana usuwana jest z tabeli routingu. Zegar ten uruchamiany jest razem z ostatnią aktualizacją trasy. Ponieważ w protokole RIP czas ten wynosi domyślnie 240 sekund, więc w praktyce trasa nieaktualizowana usunięta zostanie z tabeli routingu już po 60 sekundach trybu hold down (plus 180 sekund czasu invalid).

24. Protokół IGRP Protokół IGRP opracowany został przez firmę Cisco w celu wyeliminowania niektórych ograniczeń protokołu RIP. Jedną z najważniejszych zmian jest znacznie większy dopuszczalny rozmiar sieci. W protokole RIP najdłuższa ścieżka mogła mieć tylko 15 skoków, w protokole IGRP zwiększono tę wartość do 255 (domyślnie limit ustawiony jest na 100 skoków). Jako protokół wektora odległości i protokół klasowy IGRP podlega takim samym zasadom pracy, jak protokół RIP i w wielu punktach jest do niego podobny. Poszczególne sieci ogłaszane są do sąsiadów przez wszystkie włączone interfejsy z wykorzystaniem komunikacji rozgłoszeniowej. Zmieniono jednak wartości liczników czasowych w porównaniu z protokołem RIP (ich znaczenie jest identyczne), co pokazuje poniższa tabela: Czas Wartość Update od 72 do 90 sekund Invalid 270 sekund Hold down 280 sekund Flush 630 sekund

25. Ciekawą zmianą w stosunku do RIP jest możliwość rozłożenia ruchu pakietów na kilka tras o niejednakowej metryce, prowadzących do tej samej sieci. Jedną z najważniejszych cech protokołu IGRP jest jednak zupełnie inny sposób obliczania metryki trasy. W protokole RIP koszt trasy opierał się tylko na liczbie skoków do sieci docelowej. IGRP przesyła i monitoruje liczbę skoków, ale tylko w celu sprawdzania, czy trasa nie jest zbyt długa (255 skoków maksymalnie). Liczba skoków nie jest w ogóle brana pod uwagę przy wyliczaniu metryki. W zamian uwzględnia się 5 następujących parametrów: • Przepustowość - wartość stała definiowana w konfiguracji interfejsu, ustawiana poleceniem bandwidth. Im większa wartość, tym bardziej preferowana trasa. Domyślnie uwzględniana w metryce. • Opóźnienie - wartość stała definiowana w konfiguracji interfejsu, ustawiana poleceniem delay. Im mniejsza wartość, tym bardziej preferowana trasa. Domyślnie uwzględniana w metryce. • Pewność - wartość dynamicznie mierzona na poziomie interfejsu i wyrażana jako liczba z przedziału od 1 do 255. Im większa wartość (mniej błędów na interfejsie), tym bardziej preferowana trasa. Domyślnie nieuwzględniana w metryce. • Obciążenie - wartość dynamicznie mierzona na poziomie interfejsu i wyrażana jako liczba z przedziału od 1 do 255. Im mniejsza liczba (mniej obciążony interfejs), tym bardziej preferowana trasa. Domyślnie nieuwzględniana w metryce. • MTU - maksymalny rozmiar pola danych ramki przesyłanej w danym segmencie. Protokół IGRP śledzi najmniejszą wartość MTU na trasie, ale obecnie w ogóle nie uwzględnia tego parametru w metryce.

26. Wartości stałych od k1 do k5 można zmienić poleceniem metric weights tos k1 k2 k3 k4 k5 Aktualne wartości powyższych parametrów wyświetlić można poleceniem show interfaces. Ponieważ Pewność i Obciążenie są parametrami rzeczywistymi, zmieniającymi się w trakcie pracy interfejsu, oznaczałoby to również "ciągłą" zmianę metryk. Aby temu zapobiec, wprowadzono rozwiązanie, w którym parametry te wyznaczane są z dokładnością do 5 minut na podstawie średniej ważonej z odczytów wykonywanych co 5 sekund. Kompletny wzór, na podstawie którego wyznacza się metrykę ma postać: metryka = [k1*BWIGRP(min) + (k2*BWIGRP(min))/(256-LOAD) + k3*DLYIGRP(sum)] * [k5/RELIABILITY + k4] Zwróćmy uwagę na stosowane we wzorze stałe od k1 do k5. Jeżeli stała k5 przyjmuje wartość 0, ostatni składnik wzoru (nawias kwadratowy) nie jest w ogóle uwzględniany (wynik mnożenia zawsze byłby zerowy). Domyślnie stała k1=k3=1, a pozostałe stałe mają wartość 0, co oznacza, że powyższy wzór przekształca się do następującego: metryka = BWIGRP(min) + DLYIGRP(sum)

27. Składnik BWIGRP(min) oblicza się, dzieląc 10 000 000 przez najmniejszą Przepustowość na całej trasie, natomiast DLYIGRP(sum) jest sumą opóźnień wprowadzanych przez wszystkie interfejsy wyjściowe na całej trasie wyrażoną w dziesiątkach mikrosekund. Wyznaczymy teraz metrykę przykładowej trasy prowadzącej z routera A do sieci 5 za routerem D. Najniższa przepustowość na trasie z routera A do sieci 5 wynosi 512 kb/s, stąd: BWIGRP(min) = 10 000 000/512 = 19531 oraz DLYIGRP(sum) = 50000/10 = 5000, czyli metryka=19531+5000=24531

29. Protokół IGRP konfigurujemy podobnie jak protokół RIP, za pomocą głównego polecenia konfiguracyjnego router oraz podkomend network, których znaczenie i działanie jest takie samo, jak w protokole RIP. Zasadniczą różnicą jest stosowanie opcji obszar w poleceniu router, wskazującej identyfikator obszaru autonomicznego, w tym wypadku zwanego również domeną routingu. W przeciwieństwie do protokołu RIP, routery pracujące z protokołem IGRP mogą zostać logicznie przydzielone do różnych obszarów, w ramach których wymieniane są informacje. Standardowo routery pracujące w dwu różnych obszarach nie wymieniają informacji o sieciach. c2600(config)#router IGRP 10 c2600(config-router)#network 131.107.0.0 c2600(config-router)#network 131.108.0.0 I 212.1.1.0/24 [100/80135] via 131.107.12.2, 00:00:21, Serial0/0 I 10.0.0.0/8 [100/80225] via 131.107.13.2, 00:00:22, Serial0/1 I 196.168.2.0/24 [100/82135] via 131.107.12.2, 00:00:22, Serial0/0 [100/82135] via 131.107.13.2, 00:00:22, Serial0/1 131.108.0.0/24 is subnetted, 1 subnets C 131.108.1.0 is directly connected, Ethernet0/0 131.107.0.0/24 is subnetted, 4 subnets I 131.107.10.0 [100/82125] via 131.107.13.2, 00:00:22, Serial0/1 I 131.107.11.0 [100/82125] via 131.107.12.2, 00:00:22, Serial0/0

30. Bardzo ciekawą cechą protokołu IGRP jest możliwość rozłożenia ruchu pakietów na kilka tras o różnych metrykach. Jeśli w konfiguracji protokołu IGRP na routerze zastosujemy polecenie variance zakres, w tabeli routingu oprócz trasy najlepszej pojawią się również te, których metryka nie będzie niższa niż iloczyn zakresu i najlepszej metryki. Zad. Przygotować odpowiedni eksperyment (konfigurację ruterów) na ćwiczenia lab.

31. Przełączanie pakietów na routerach Cisco • Routery Cisco mogą pracować w dwóch trybach przełączania pakietów: • procesowym, w którym stosuje się równoważenie obciążenia, przesyłając pakiet po pakiecie na poszczególne trasy; • pamięciowym (przełączanie szybkie), w którym stosuje się wybór jednej trasy dla wszystkich pakietów związanych z konkretnym miejscem przeznaczenia. • W przełączaniu procesowym przeszukiwana jest tablica routingu dla każdego pakietu, co zwiększa obciążenie procesora routera. Przełączanie szybkie wykorzystuje specjalny obszar pamięci podręcznej, w którym przechowuje się informację o wybranej trasie do konkretnego miejsca docelowego (adres docelowy, interfejs routera). Dla pierwszego wysyłanego pakietu stosuje się zawsze przełączanie procesowe, następnie tworzony jest wpis w pamięci podręcznej i na tej podstawie przesyłane są kolejne pakiety. Korzystanie z pamięci podręcznej jest rozwiązaniem szybszym niż przeglądanie tabeli tras stosowane w przełączaniu procesowym. Domyślnie w konfiguracji wszystkich interfejsów włączone jest przełączanie szybkie, co można sprawdzić poleceniem show ip interface nazwa_interfejsu. Aby wyłączyć szybkie przełączanie (i włączyć procesowe), należy w trybie konfiguracji interfejsu wykonać komendę no ip route-cache.

32. Redystrybucja danych routingu Proces redystrybucji danych o routingu między różnymi źródłami informacji najczęściej konfiguruje się w środowisku, w którym uruchomione są różne protokoły routingu dynamicznego. Jego celem jest przekazanie informacji o sieciach zebranych w ramach jednego protokołu do innego protokołu routingu dynamicznego. Można sobie wyobrazić rozbudowaną sieć, w której część urządzeń pracuje z wykorzystaniem protokołu RIP, a pozostała część korzysta z protokołu IGRP. Dzięki redystrybucji wszystkie routery będą posiadały informacje o wszystkich segmentach sieci. Specyficzną odmianą procesu redystrybucji jest rozgłaszanie tras statycznych przy wykorzystaniu protokołu routingu dynamicznego. Poprzez redystrybucję realizuje się także wymianę danych między różnymi obszarami w ramach protokołu IGRP. Podstawowym problemem przy przekazywaniu informacji z jednego źródła do innego jest zmiana metryki. Nie można bowiem przenieść tras z protokołu RIP, gdzie metryka to liczba skoków mniejsza niż 16, do protokołu IGRP, w którym koszt trasy wyznaczany jest według zupełnie innych kryteriów. W trakcie konfigurowania procesu redystrybucji w ramach określonego protokołu routingu dynamicznego należy podać wartość metryki, jaką będą otrzymywały wszystkie pobierane z innego źródła trasy

33. c2600(config)#router rip c2600(config-router)#redistribute igrp 10 metric 5 c2600(config-router)#passive-interface Serial 0/1 c2600(config-router)#network 131.107.0.0 c2600(config)#router igrp 10 c2600(config-router)#redistribute rip c2600(config-router)#default-metric 1000 100 255 1 1500 c2600(config-router)#passive-interface Serial 0/0 c2600(config-router)#network 131.107.0.0 W powyższym przykładzie polecenie default-metric wymagało aż pięciu parametrów, z których liczona jest metryka w protokole IGRP (Przepustowość, Opóźnienie, Pewność, Obciążenie, MTU). Dla protokołu RIP wymagany jest tylko jeden parametr - liczba skoków. Polecenie passive-interface blokuje ogłaszanie danego protokołu przez wskazany interfejs.

35. Protokoły klasowe • Jako sieć główną przyjmuje się adres sieci zgodny z klasą adresu IP. • Podstawową cechą protokołów klasowych jest to, iż nie ogłaszają one maski podsieci razem z adresem sieci. Router odbierający może zastosować maskę z własnego interfejsu, jeśli interfejs ma adres IP z tej samej sieci głównej, co sieć ogłaszana. • Dla protokołów klasowych stosowane są następujące zasady ogłaszania sieci lub podsieci: • Jeżeli podsieć oraz interfejs, przez który jest ogłaszana, mają identyczną sieć główną oraz jednakowej długości maskę podsieci, to podsieć będzie ogłaszana poprawnie (poprawny adres sieci, ale bez maski). • Jeżeli podsieć ma taką samą sieć główną jak interfejs, przez który ma być ogłoszona, ale inną maskę podsieci, podsieć ta nie będzie w ogóle ogłaszana. • Jeżeli ogłaszana podsieć ma inną sieć główną niż interfejs, przez który jest ogłaszana, router wysyłający ogłoszenie dokonuje automatycznego przekształcenia na adres sieci głównej, czyli adres wynikający z klasy. Proces ten nazywany jest łączeniem tras na granicy sieci głównych

36. Router A ogłasza przez interfejs S0 podsieć 170.71.5.0 (sieć LAN), a router B interpretuje to ogłoszenie z maską podsieci własnego interfejsu S0 (w tym wypadku maska ma 30 bitów). • Router B nie będzie ogłaszał przez interfejs S0 podsieci 170.71.8.0, ponieważ jej maska (24 bity) jest niezgodna z maską interfejsu S0 (30 bitów).

37. Łączenie tras na granicy sieci głównych

38. Jednym z problemów wynikających ze stosowania protokołów klasowych jest brak obsługi tzw. sieci nieciągłych. Sieci nieciągłe to dwie podsieci tej samej sieci głównej rozdzielone inną siecią główną - p. rysunek poniżej. Interfejsy Ethernet routerów A i B mają przypisane adresy IP z różnych podsieci sieci głównej 170.71.0.0. Na interfejsach szeregowych łączących routery wykorzystywana jest sieć główna 170.73.0.0. W tej sytuacji router A, ogłaszając sieć 170.71.5.0 do swojego sąsiada, będzie musiał dokonać przekształcenia na adres wynikający z klasy (granica sieci głównych). Ogłoszenie sumaryczne dociera do routera B, ale jest ignorowane, ponieważ router B ma dokładniejsze informacje o sieci 170.71.0.0, gdyż jest lokalnie podłączony do podsieci 170.71.8.0.

39. Kolejny adres przypisujemy do interfejsu poleceniem konfiguracyjnym interfejsu: ip address adres_IP Maska_Podsieci secondary Sieci 10.45.5.0 za routerem A oraz 10.45.35.0 za routerem C należą do tej samej sieci głównej 10.0.0.0 i są przykładem podsieci nieciągłych rozdzielonych inną siecią główną: 192.168.11.0 oraz 192.168.80.0. Dzięki przypisaniu adresów drugorzędnych należących do różnych podsieci tej samej sieci głównej 10.0.0.0, ogłaszanie informacji przez poszczególne interfejsy na trasie między routerem A i C nie wymaga łączenia tras na granicy sieci głównych. Ogłaszanie realizowane jest niezależnie dla poszczególnych adresów IP przypisanych do interfejsu. W omawianym przypadku przypisanie dwu adresów IP do interfejsu oznacza dwukrotny proces ogłaszania, niezależnie dla adresu głównego i drugorzędnego.