NetCLI

Blog

  • (K) Konfiguracja interfejsów, metryki OSPF**

    (K) Konfiguracja interfejsów, metryki OSPF**

    Konfiguracja Interfejsów

    Konfiguracja Interfejsów pasywnych

    Dezaktywacja interfejsów pasywnych

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# passive-interface interfejs

    Włącza funkcję pasywną na określonym interfejsie sieciowym.

    Aktywacja interfejsów pasywnych

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# passive-interface default

    Włącza funkcję pasywną na wszystkich interfejsach sieciowych.

    (config-router)# no passive-interface interfejs

    Wyłącza funkcję pasywną na określonym interfejsie sieciowym.

    Konfiguracja wartości MTU

    # Wymaganie dotyczące procesu nawiązywania relacji sąsiedztwa zostały opisane w artykule: Nawiązywanie relacji sąsiedztwa.

    (config)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# ip mtu wartość-MTU

    Określa wartość MTU. Ustawienie różnych wartości MTU na sąsiednich interfejsach może doprowadzić do błędów w czasie wymiany danych bazy LSDB, a tym samym uniemożliwić nawiązanie relacji sąsiedztwa pomiędzy ruterami.

    # show ip interface interfejs | include MTU

    Wyświetla skonfigurowaną wartość MTU, względem określonego interfejsu sieciowego.

    Statyczny wybór topologii sieciowej

    (config)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# ip ospf network {point-to-point / non-broadcast / broadcast / point-to-multipoint / point-to-multipoint non-broadcast} –

    Określa rodzaj topologii sieciowej, względem protokołu OSPF.

    # show ip ospf interface [interfejs] | include Network

    Wyświetla informacje na temat rodzaju skonfigurowanej sieci, względem określonego interfejsu bądź wszystkich interfejsów sieciowych.

    Konfiguracja interfejsów wirtualnych (Virtual Links)

    Wstęp teoretyczny

    • Zgodnie z zasadami funkcjonowania protokołu OSPF, każda strefa non-backbone powinna mieć zapewnioną łączność ze strefą Backbone (Area 0). Jeżeli warunek ten nie zostanie spełniony, w sieci dojdzie do sytuacji zwanej „Discontiguous area 0”.
    • Aby tymczasowo umożliwić kontakt pomiędzy strefą non-backbone a strefą Backbone, poprzez inną strefą non-backbone. Protokół OSPF posiada funkcją połączenia wirtualnego „Virtual Link” , nawiązywanego w warstwie kontrolnej „Control Plane”.
    • W przypadku konfiguracji połączeń wirtualnych strefy non-backbone nie mogą być skonfigurowane jako strefy specjalne Stub Area ani filtrować ruchu LSA typu trzeciego (LSA Type 3).

    Konfiguracja Linku Wirtualnego

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# area ID-strefy(Tranzytowej) virtual-link RID(Sąsiedniego urządzenia)

    Tworzy wirtualny link pomiędzy lokalnym urządzeniem a ruterem o określonej wartości RID (Podana w komendzie strefa (Area) jest strefą tranzytową, przez którą przechodzi konfigurowane połączenie wirtualne).

    (config-router)# area ID-strefy(Tranzytowej) virtual-link RID(Sąsiedniego urządzenia) dead-interval 1-8192(sekundy)

    Określa wartość czasu „dead-interval”.

    (config-router)# area ID-strefy(Tranzytowej) virtual-link RID(Sąsiedniego urządzenia) hello-interval 1-8192(sekundy)

    Określa wartość czasu „hello-interval”.

    Uwierzytelnianie Linku Wirtualnego

    (config-router)# area ID-strefy(Tranzytowej) virtual-link RID(Sąsiedniego urządzenia) authentication authentication-key hasło

    Uwierzytelnia połączenie wirtualne przy pomocy hasła (Plain Text).

    (config-router)# area ID-strefy(Tranzytowej) virtual-link RID(Sąsiedniego urządzenia) authentication message-digest message-digest-key 1-255(ID Klucza) md5 hasło

    Uwierzytelnia połączenie wirtualne przy pomocy hasła MD5.

    # show ip ospf virtual-links

    Wyświetla stan skonfigurowanych połączeń wirtualnych.

    # show ip ospf border-routers [detail]

    Wyświetla szczegółowe informacje na temat urządzeniach granicznych ABR, znajdujących się w tej samej strefie co lokalne urządzenia.

    Konfiguracja kosztów protokołu OSPF (Metryki)

    Koszt dotarcia protokołu OSPF do sieci docelowej, jest obliczany na podstawie pasma wszystkich interfejsów znajdujących się na trasie prowadzącej do celu. Wartość pasma interfejsu można dowolnie modyfikować.
    Interfejs Domyślna wartość pasma Formuła (Kbps) Koszt OSPF
    Ethernet 10.000 Kbps 100.000/10.000 10
    Token Ring 16.000 Kbps 100.000/16.000 6
    Fast Ethernet 100.000 Kbps 100.000/100.000 1
    Gigabit Ethernet 1.000,000 Kbps 100.000/1.000.000 1
    10 Gigabit Ethernet 10.000.000 Kbps 100.000/10.000.000 1
    100 Gigabit Ethernet 100.000.000 Kbps 100.000/100.000.000 1

    Domyślne koszty interfejsów protokołu OSPF

    # Teoria związana z wyliczaniem metryki protokołu OSPF została opisana w artykule: Wyliczanie metryki.

    (config)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# bandwidth 1-10000000(Kbps)

    Określa statyczną wartość pasma przypisaną do konfigurowanego interfejsu sieciowego.

    (config-if)# ip ospf cost 1-65535(Mbps)

    Określa statyczną wartość kosztu OSPF przypisaną do konfigurowanego interfejsu sieciowego.

    (config-if)# auto-cost reference-bandwidth 1-1000000(100)

    Zmienia domyślną wartość “Reference Bandwidth“.
    Wzór służący do wyliczenia kosztu protokołu OSPF jest następujący: (Reference-Bandwidth / Bandwidth). Show ip ospf Border routers

    Komendy SHOW

    # show ip ospf interface interfejs

    Wyświetla informacje związane z konfiguracją kosztu OSPF, względem określonego interfejsu sieciowego.

    # show ip ospf interface brief

    Wyświetla koszty wszystkich interfejsów sieciowych.

    # show ip ospf interface interfejs

    Wyświetla koszt określonego interfejsu sieciowego.

    # show ip ospf | section bandwidth

    Wyświetla skonfigurowaną wartości „Reference-Bandwidth”.

    Pozostałe tematy związane z konfiguracją protokołu OSPF

    OSPFv3

  • (TK) Filtrowanie protokołu OSPF**

    (TK) Filtrowanie protokołu OSPF**

    Wstęp teoretyczny do filtrowania tras routingu

    • Zgodnie z zasadą funkcjonowania protokołu OSPF, baza LSDB musi mieć taką samą zawartość, na wszystkich urządzeniach względem tej samej strefy (Area). Zasada ta wyklucza więc stosowanie filtracji tras routingu w obrębie jednej tej samej strefy (Area), dopuszczając ją jedynie na ruterach pełniących rolę ABR (SLA typu 3) oraz ASBR (SLA typu 5).
    • Trasy „Interarea Routers” wymieniane za pomocą struktur LSA typu trzeciego oraz piątego,funkcjonują zgodnie z logiką Distance Vector a nie Link-State, jak ma to miejsce w przypadku struktur LSA typu pierwszego oraz drugiego.
    Filtrowanie tras routingu (in & out)

    ??KONFIGURACJA SPRAWDŹ?? 49- OSPF of Type-5 LSAs (Redistribution filtering) 28 minuta nagrania w dan.

    Konfiguracja filtrowania tras routingu

    Filtrowanie struktur LSA typu 3 (ABR)

    # Szczegółowa konfiguracja Prefix listy została opisana w artykule: Prefix Lista.

    (config)# ip prefix-list nazwa-prefix-listy [seq 1-4294967294(ID sekwencji)] {deny / permit} adres-sieci/prefix [ge mini-prefix / le max-prefix]

    Dopuszcza bądź blokuje trasy routingu, dotyczące wskazanej w komendzie sieci, której maska mieści się w zakresie od prefix-mini do max-prefix.
    Przykładowa komenda [ip prefix-list nazwa permit 192.168.0.0/16 ge 24 le 26] dopuszcza trasy routingu, posiadające prefix z zakresu od 24 do 26, dla sieci 192.168.0.0/16.

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# area ID-strefy filter-list prefix-list nazwa-prefix-listy {in / out}

    Określona w komendzie prefix lista filtruje adresy zapisane w wpisie „deny” a przepuszcza wpisy „permit”.
    Pod-komenda„in” filtruje trasy przychodzące do danej strefy (Area), natomiast „out” filtruje trasy wychodzące z danej strefy (Area).

    (config-router)# show ip prefix-list [nazwa-prefix-listy]

    Wyświetla wszystkie skonfigurowane, bądź określoną w komedzie prefix listę.

    Filtrowanie struktur LSA typu 5 (ASBR)

    # Szczegółowa konfiguracja Router mapy została opisana w artykule: Router mapa.

    (config)# route-map nazwa-router-mapy {permit / deny} sequence

    Tworzy nową router mapę przepuszczającą (permit), bądź filtrujące (denny). Wskazane w komendzie trasy routingu. Podany numer sekwencyjny określa porządek rozpatrywania wpisów router mapy.

    (config-route-map)# match ip address {ACL-ID / prefix-list nazwa-prefix-listy}

    Określa trasy prowadzące do sieci, zawartych w określonej przez komendę liście ACL bądź Prefix liście.
    Konfiguracja Prefix listy, została opisana w następującym artykule.

    (config-route-map)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# redistribute protokół [ASN] [route-map nazwa-ruter-mapy] [subnets]

    * Route-map – Określa Router Mapę ,filtrującą wskazane trasy routingu.
    * Subnets – Zezwala na rozgłaszanie zarówno sieci klasowych jak i bezklasowych (IPv4).

    # show route-map [nazwa-router-mapy]

    Wyświetla określoną / wszystkie skonfigurowane na danym urządzeniu Router Mapy.

    Filtrowanie struktur LSA typu 1,2 (ABR) za pomocą sumaryzacji

    Filtrowanie struktur LSA typu pierwszego oraz drugiego jest możliwe jedynie na ruterze ABR, za pomocą wykluczonej sumaryzacji "not-advertise".

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# area ID-strefy range sieć maska not-advertise

    Określa filtrowaną sieć, wraz ze strefą (Area) z której pochodzi (Metoda ta umożliwia filtrowanie jedynie struktur LSA typu pierwszego jak i drugiego na ruterze ABR). W topologii Area 1 – Area 0 – Area 2 filtrowanie poprzez sumaryzację może być zastosowane pomiędzy strefą 1,0 dla sieci ze strefy pierwszej jak i zerowej oraz pomiędzy strefą 0, 2 dla sieci zerowej jak i drugiej, nie można jej jednak stosować pomiędzy np. strefą 1,0 dla sieci ze strefy drugiej).

    Filtrowanie tras sieciowych niezależnie do struktur LSA za pomocą listy (Distribute List)

    • Filtrowanie tras routingu za pomocą funkcji „Distribute List”, blokuje możliwość dodania określonej sieci do tablicy routingu, względem wszystkich protokołów routingu dynamicznego. W przypadku protokołu OSPF filtracja ta nie wpływa ani na struktury LSA ani na algorytm SPF, ponieważ dotyczy jedynie procesu aktualizacji tablicy routingu (Jest to najmniej pożądana metoda filtracji, mogąca doprowadzić do powstania dziur w topologii routingu).
    • Proces dodawania tras routingu na ruterze wykorzystującym protokół OSPF jest następujący:
      • Baza LSDB -> Algorytm SPF -> Distribute-List in -> IP Routing Table.
      • Lista Distribute-List out nie zadziała w przypadku protokołu OSPF ponieważ filtruje ona jedynie sieci pobierane z tablicy routingu w procesie redystrybucji. Natomiast protokół OSPF nie pobiera z tablicy routingu żadnych informacji dotyczących sieci a jedynie korzysta z własnej bazy LSDB w tym procesie.

    Podstawowa filtracja tras routingu (ACL)

    (config)# access-list ACL deny sieć dzika-maska

    Tworzy standardową listę ACL filtrującą wskazaną sieć.

    (config)# access-list ACL permit any

    Dodaje wpis listy ACL przepuszczający pozostałe sieci.

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# distribute-list ACL in [interfejs]

    Blokuje możliwość dodania określonej sieci do tablicy routingu, względem wszystkich protokołów routingu dynamicznego. W przypadku protokołu OSPF filtracja ta nie wpływa ani na struktury LSA ani na algorytm SPF, ponieważ dotyczy jedynie procesu aktualizacji tablicy routingu (Jest to najmniej pożądana metoda, mogąca doprowadzić do powstania dziur w topologii routingu).

    Rozszerzona filtracja tras routingu (ACL)

    (config)# access-list ACL deny ip RID adres-IP-następnego-przeskoku sieć dzika-maska

    Tworzy rozszerzoną listę ACL filtrującą określoną w komendzie sieć (sieć dzika-maska), rozgłaszaną przez ruter o określonej wartości RID oraz adresie następnego przeskoku.

    (config)# access-list ACL permit ip any any

    Dodaje wpis listy ACL przepuszczający pozostałe sieci.

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# distribute-list ACL in [interfejs]

    Blokuje możliwość dodania określonej sieci do tablicy routingu, względem wszystkich protokołów routingu dynamicznego. W przypadku protokołu OSPF filtracja ta nie wpływa ani na struktury LSA ani na algorytm SPF, ponieważ dotyczy jedynie procesu aktualizacji tablicy routingu (Jest to najmniej pożądana metoda, mogąca doprowadzić do powstania dziur w topologii routingu).

    Filtrowanie tras OSPF (Prefix lista)

    # Szczegółowa konfiguracja Prefix listy została opisana w artykule: Prefix Lista.

    (config)# ip prefix-list nazwa-prefix-listy [seq 1-4294967294(ID sekwencji)] {deny / permit} adres-sieci/prefix [ge mini-prefix / le max-prefix]

    Dopuszcza bądź blokuje trasy routingu, dotyczące wskazanej w komendzie sieci, której maska mieści się w zakresie od prefix-mini do max-prefix.
    Przykładowa komenda [ip prefix-list nazwa permit 192.168.0.0/16 ge 24 le 26] dopuszcza trasy routingu, posiadające prefix z zakresu od 24 do 26, dla sieci 192.168.0.0/16.

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# distribute-list prefix nazwa-prefix-listy in [interfejs]

    Blokuje możliwość dodania określonej sieci do tablicy routingu, względem wszystkich protokołów routingu dynamicznego. W przypadku protokołu OSPF filtracja ta nie wpływa ani na struktury LSA ani na algorytm SPF, ponieważ dotyczy jedynie procesu aktualizacji tablicy routingu (Jest to najmniej pożądana metoda, mogąca doprowadzić do powstania dziur w topologii routingu).

    Filtrowanie tras OSPF (Router mapa)

    # Szczegółowa konfiguracja Router mapy została opisana w artykule: Router mapa.

    (config)# route-map nazwa-router-mapy {permit / deny} sequence

    Tworzy nową router mapę przepuszczającą (permit), bądź filtrujące (denny). Wskazane w komendzie trasy routingu. Podany numer sekwencyjny określa porządek rozpatrywania wpisów router mapy.

    (config-route-map)# match ip address {ACL-ID / prefix-list nazwa-prefix-listy}

    Określa trasy prowadzące do sieci, zawartych w określonej przez komendę liście ACL bądź Prefix liście.
    Konfiguracja Prefix listy, została opisana w następującym artykule.

    (config-route-map)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# distribute-list router-map nazwa-router-mapy in [interfejs]

    Blokuje możliwość dodania określonej sieci do tablicy routingu, względem wszystkich protokołów routingu dynamicznego. W przypadku protokołu OSPF filtracja ta nie wpływa ani na struktury LSA ani na algorytm SPF, ponieważ dotyczy jedynie procesu aktualizacji tablicy routingu (Jest to najmniej pożądana metoda, mogąca doprowadzić do powstania dziur w topologii routingu). 
    Lista ACL bądź też lista Prefix lista, zawierająca wpis Deny wymusza przejście do kolejnego wpisu router-mapy.
    Wpis router-mapy bez skonfigurowanej komendy [match] dotycz wszystkich tras routingu.

    Komendy SHOW

    # show ip ospf xxx

    Wyświetla

    # show ip ospf xxx

    Wyświetla

    # show ip ospf xxx

    Wyświetla

    Pozostałe tematy związane z konfiguracją protokołu OSPF

    OSPFv3

  • (T) Wyliczanie metryki OSPF**

    (T) Wyliczanie metryki OSPF**

    Zmiana kosztu OSPF

    Zmiana kosztu OSPF (Reference-Bandwidth)

    • OSPF przy wyliczaniu kosztu interfejsu sieciowego, wykorzystuje następujący wzór (Cost = Reference-Bandwidth / Interface-Bandwidth). Z czego „Reference-Bandwidth” odnosi się do domyślnej wartości protokołu OSPF (100), która może być opcjonalnie zmodyfikowana za pomocą komendy [auto-cost reference-bandwidth 1-4294967(pasmo)(Mbps)] wydanej w trybie konfiguracji protokołu OSPF. 
    Należy przy tym pamiętać, aby wszystkie rutery należące do tej samej instancji protokołu OSPF, posiadały takie same ustawienia wartości „Reference-Bandwidth”.

    Przykładowe wyliczanie kosztu

    • Obliczanie kosztu z domyślną wartością Reference-Bandwidth (Domyślna wartość wynosi 100):
      • Ethernet (10 Mbps) – 100 / 10 = 10.
      • FastEthernet (100 Mbps) – 100 / 100 = 1.
      • GigabitEthernet (1 Gbps) – 100 / 1000 = 0.1 (1 Stanowi najniższą wartość).
      • 10 GigabitEthernet (10 Gbps) – 100 / 10 000 = 0.01 (1 Stanowi najniższą wartość).
    • Obliczanie kosztu z zmodyfikowaną wartością Reference-Bandwidth (Na wartość 10 000):
      • Ethernet (10 Mbps) – 10 000 / 10 = 1000.
      • FastEthernet (100 Mbps) – 10 000 / 100 = 100.
      • GigabitEthernet (1 Gbps) – 10 000 / 1000 = 10.
      • 10 GigabitEthernet (10 Gbps) – 10 000 / 10 000 = 1.
    Powodem motywującym do zmiany domyślnej wartości „Reference-Bandwidth”, może być fakt że dla interfejsów działających w standardzie Fast Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet oraz wyższych domyślna, wartość koszu jest taka sama i wynosi 1. Ponieważ jest to najniższa wartość używana w protokole OSPF. W takim przypadku zmiana domyślnej wartości „Reference-Bandwidth”, umożliwi uwzględnienie różnic pasma pomiędzy wskazanymi standardami.

    Zmiana kosztu protokołu OSPF (Interfejs-Bandwidth)

    • Drugą metodą umożliwiającą ingerencję w wartość kosztu protokołu OSPF, względem określonego interfejsu sieciowego. Jest statyczne skonfigurowanie wartości „Interface-Bandwidth” za pomocą komendy [bandwidth 1-10000000(pasmo)(Kbps)] wydanej w trybie konfiguracji interfejsu sieciowego.

    Zmiana kosztu protokołu OSPF (OSPF Cost)

    • Ostatnią najskuteczniejszą metodą zmiany wartości kosztu interfejsu sieciowego, jest statyczne zmodyfikowanie wartości kosztu za pomocą komendy [ip ospf cost 1-65535(Wartość-kosztu)] wydanej z poziomu konfiguracji interfejsu sieciowego.

    Podsumowanie zmiany domyślnego kosztu protokołu OSPF

    • Wzór na obliczanie wartości interfejsu wygląda następująco: Cost = Reference-Bandwidth / Interface- Bandwidth.
      • Komenda [auto-cost reference-bandwidth 1-4294967(pasmo)(Mbps)] zmienia domyślną wartość „Reference-Bandwidth”.
      • Komenda [bandwidth 1-10000000(pasmo)(Kbps)] zmienia domyślną wartość „Interface-Bandwidth”.
      • Komenda [ip ospf cost 1-65535(Wartość-kosztu)] zmienia wyliczoną wartość „Cost”.
    • Wartość kosztu interfejsu sieciowego można zweryfikować za pomocą komendy:
      • [show running-config | section ospf] – Wyświetla konfigurację protokołu OSPF.
      • [show ip ospf interface brief] – Wyświetla koszty wszystkich interfejsów sieciowych.
      • [show ip ospf interface interfejs] – Wyświetla koszt określonego interfejsu sieciowego.
      • [show ip ospf | section bandwidth] – Wyświetla skonfigurowaną wartości „Reference-Bandwidth”.

    Pozostałe tematy związane z protokołem OSPF

    OSPFv3

  • (T) Multi-Area OSFP*

    (T) Multi-Area OSFP*

    Multi-Area OSFP

    Informacje dotyczące Multi-Area OSFP

    • Protokół OSPF wymaga aby poszczególne strefy (Area), były łączone pomiędzy sobą za pośrednictwem strefy głównej (Backbone Area 0). Konfiguracja pojedynczej strefy (Area) nie wymaga aby była to strefa Backbone.
    • Wymiana tras routingu może zachodzić jedynie pomiędzy strefą tranzytową (Area 0) a inną strefą protokołu OSPF.

    Przyczyny podziału na strefy Area

    • Large link-state database – Im większa topologia sieciowa, tym więcej pamięci (RAM-u) zajmuje baza LSDB a tym samym więcej informacji jest wymienianych pomiędzy ruterami. Ponadto większa baza wymaga większego nakładu pracy procesora CPU przy obliczaniu ścieżki wolnej od pętli.
    • Large routing table – Sieci wewnątrz jednej strefy (Area) nie mogą być zsumaryzowane ani filtrowane.
    • Frequent SPF algorithm calculations – Każda zmiana statusu interfejsu może doprowadzić do wystąpienia ponownego procesu przeliczania ścieżki dotarcia do sieci docelowej, a tym samym znacząco zwiększyć utylizację procesora CPU.
    Według niektórych źródeł liczba 50 ruterów stanowi punkt, w którym stosowanie podziału na strefy jest wskazane.

    Skutki zastosowania podziału na strefy Area

    • Smaller routing tables – Sieci mogą zostać zsumaryzowane pomiędzy poszczególnymi strefami (Area).
    • Reduced link-state update overhead – Zmniejszenie pojedynczej strefy (Area), ogranicza ilość rozgłaszanych struktur LSA, tym samym zmniejszając ilość wykorzystywanej pomięci RAM oraz zmniejszając poziom utylizacji procesora CPU.
    • Reduced frequency of SPF calculations – Minimalizuje zasięg zmian wymagających ponownej re-kalkulacji algorytmu SPF.

    Nazewnictwo związane z podziałem na strefy Area

    • Area – Grupa ruterów współdzielących tę samą zawartość bazy LSDB.
    • Backbone Area – Główna strefa, do której muszą być podłączone inne strefy (Area).
    • Intra-area route – Trasa do sieci znajdującej się w tej samej strefie (Area).
    • Interarea route – Trasa do sieci znajdującej się w innej strefie (Area).
    • Internal Router – Ruter, którego wszystkie interfejsy należą do tej samej strefy (Area).
    • Area Border Router (ABR) – Ruter łączący strefę Backbone Area z innymi strefami protokołu OSPF.
    • Backbone Router – Ruter, którego przynajmniej jeden z interfejsów należy to strefy Backbone.
    • Autonomous System Boundary Router (ASBR) – Ruter, którego przynajmniej jeden z interfejsów należy do innego systemu autonomicznego (Wspiera inny protokół routingu bądź inną instancje protokołu OSPF).
    Nazewnictwo związane z podziałem na strefy

    Virtual links

    • Połączenie wirtualne stosowane w protokole OSPF, ma na celu zapewnienie bezpośredniej łączności pomiędzy strefą główną (Backbone Area 0) a inną strefą (Area). W sytuacji, w której obydwie strefy nie są ze sobą bezpośrednio połączone, ponieważ rozdziela je inna strefa. W takim przypadku zastosowanie połączenia wirtualnego (Virtual link) stanowi tymczasowe rozwiązanie umożliwiające bezpośrednią komunikację ze strefą (Backbone).
    • Połączenie wirtualne może być przydatne w sytuacji:
      • Gdy połączenie strefy (Nonbackbone Area) za pomocą sieci WAN, poprzez inną strefę (Nonbackbone Area) jest tańsze niż bezpośrednie połączenie ze strefą (Backbone Area 0).
      • Utraty połączenia pomiędzy dwoma częściami strefy (Backbone Area 0), co może doprowadzić do powstania dwóch niezależnych stref (Area 0).
      • Łączenia ze sobą dwóch niezależnych topologii sieciowych, z których każda posiada własną strefą Area 0.

    Pozostałe tematy związane z protokołem OSPF

    OSPFv3

  • (T) Model TCP/IP*

    (T) Model TCP/IP*

    Wstęp do modelu TCP/IP

    • Pierwsze próby stworzenia sieci komputerowej, zostały podjęte przez amerykańskie korporacje, dążące do ułatwienia wymiany danych pomiędzy swoimi pracownikami. Początkowo poszczególne firmy tworzyły swoje własne rozwiązanie techniczne, co uniemożliwiało tworzenie sieci rozległych wychodzących poza przestrzeń lokalną. Dlatego najważniejszym zadaniem stającym przed informatykami było ujednolicenie wykorzystywanych technologii, aby mogły ze sobą współpracować pomimo różnic w budowie fizycznej poszczególnych komponentów. Powstałe dzięki temu protokoły określały poszczególne etapy komunikacji pomiędzy dwiema stronami, w oderwaniu od warstwy fizycznej. A tym samym umożliwiały komunikacje komputerów, których karty sieciowe zostały stworzone przez konkurujących ze sobą producentów. Tworzeniem nowych protokołów np. w postaci dokumentów RFC (Request for Comments) opatrzonych unikalnym numerem, zajmuje się wiele organizacji pozarządowych takich jak IETF (Internet Engineering Task Force). Jest to organizacja zrzeszająca informatyków z całego świata, których wspólna praca napędza rozwój Internetu.
    • W latach siedemdziesiątych Agencja Zaawansowanych Projektów Badawczych Departamentu Obrony Stanów Zjednoczonych DARPA (Defense Advanced Research Projects Agency) stworzyła zestaw protokołów TCP/IP wprowadzający standaryzację, określającą szczegóły komunikacji między komputerami oraz sposoby nawiązywania łączności. Nowo powstały zestaw protokołów opierał się na zasadzie podziału struktury na współpracujące ze sobą warstw (Layers), dzięki czemu poszczególne protokoły mogły być tworzone przez inne niezależne grupy programistów, specjalizujących się w innych częściach sieci. Podstawowymi założeniami nowego standardu było uzyskanie następujących cech:
      • Dobrej odtwarzalność po awarii.
      • Możliwość dodawania nowych sieci bez przerywania pracy istniejących.
      • Wysokiego współczynnika korekcji błędów.
      • Niezależności od platformy.
      • Dużej wydajność.

    Zasada „end-to-end argument” i „fate sharing”

    • Zasada „end-to-end argument” akcentuje niemożliwość osiągnięcia poprawnej komunikacji w oderwaniu od użytkowników, hostów będących dwoma głównymi punktami połączenia. Ponieważ niemożliwe jest przewidzenie wszystkich wymagany w przyszłości funkcjonalności, to główne z nich takie jak kontrola błędów, szyfrowanie lub potwierdzenie dostarczenia danych, powinny być implementowane w wyższych warstwach modelu. Niższe natomiast powinny dostarczać elementy wspomagające, ułatwiające implementacje powyższych funkcji. Konstrukcja ta stworzona jest zgodnie z filozofią „głupiej sieci” w której „inteligentne końcówki” prowadzą komunikację poprzez sieć o prymitywnej funkcjonalności. Druga koncepcja „fate sharing”, stworzona w zgodzie z postanowieniami pierwszej nakazuje, aby hosty posiadały wszystkie niezbędne do utrzymania komunikacji funkcje, dzięki czemu uszkodzenie sieci nie musi oznaczać zerwania transmisji pomiędzy urządzeniami, a jedynie zmianę ścieżki je łączącej.

    Architektura warstwowa

    • Architektura warstwowa dzieli protokoły na grupy należące do różnych warstw, z których każda kontroluje inny aspekt komunikacji. Ułatwia to opracowywanie nowych składników zestawu w sposób niezależny od siebie. Dzięki czemu specjaliści z różnych dziedzin mogą pracować nad zagadnieniami typowymi dla swoich specjalizacji.
    Porównanie modelu TCP/IP z modelem OSI/ISO

    Pozostałe tematy związane z modelem OSI/ISO, TCP/IP

    Podstawy sieci komputerowych

    Warstwy modelu OSI

    Bezpieczeństwo sieci

    Troubleshooting

  • (T) Rodzaje ruchu / topologii sieciowych*

    (T) Rodzaje ruchu / topologii sieciowych*

    Rodzaje ruchu sieciowego

    • Unicast – Ruch kierowany do pojedynczego urządzenia docelowego.
    • Multicast – Ruch kierowany do wielu urządzeń docelowych.
    • Broadcast – Ruch kierowany do wszystkich dostępnych urządzeń, znajdujących się w jednej domenie rozgłoszeni-owej.
      • Local Broadcast – Adres rozgłoszeniowy (255.255.255.255).
      • Subnet Broadcast Address – Adres rozgłoszeniowy sieci bezklasowej (Np. dla sieci 10.1.1.0/24 będzie to adres 10.1.1.255).
      • Network Broadcast Address – Adres rozgłoszeniowy sieci klasowej.
    • Anycast – Ruch kierowany do najbliższego urządzenia, wykorzystywany w adresacji IPv6 umożliwia współdzielenie przez wiele urządzeń jednego tego samego adresu IPv6, dzięki czemu globalne tablicę trasowania będą kierowały nadchodzący pakiety do najbliższego urządzenia o tym samym adresie.
    Adres rozgłoszeniowy „Broadcast” nie jest przepuszczany przez rutery.
    Komenda [no ip directed-broadcast] umożliwia przekazywania ruchu „Subnet Broadcast” przez rutery.

    Rodzaje topologii sieciowych

    Rodzaje topologii sieciowych

    • Rodzaje topologii sieci WAN:
      • Point to point topology
      • Hub and spoke topology
      • Full mesh topology
      • Partial mesh topology
    • Rodzaje topologii sieci LAN:
      • Star topology
      • Extended Star topology or Hybrid
      • Bus topology
      • Ring topology

    Inne rodzaje sieci

    Sieć rozgłoszeni-owa (Broadcast Network) – Stanowi wydzieloną sieć, w której pakiety rozgłoszeni-owe (Broadcast) wysłane z jednego punktu źródłowego, trafią na wszystkie inne urządzenia znajdujące się w sieci lokalnej (rutery bądź sieci wirtualne VLAN blokują rozprzestrzenianie się tego rodzaju wiadomości w Internecie).

    Topologia NBMA (Non Broadcast Multi Access)

    NBMA (Non Broadcast Multi Access) – Sieć, w której nie występuje ruch multicast ani broadcast, a komunikacja jest możliwa jedynie dzięki pakietom kierowanym na adresy unicast. W powyższym przykładzie ruter HQ jest połączony jednym kablem serialowym do dwóch innych ruterów, przy użyciu sieci opartej o technologię Frame Relay lub ATM co uniemożliwia mu nawiązanie relacji sąsiedztwa z innymi urządzeniami w sieci (ATM i Frame Relay nie wspierają komunikacji multicast niezbędnej do nawiązania takiej relacji) w takim przypadku administrator musi ręcznie skonfigurować relację sąsiedztwa lub wykorzystać tunelowanie VPN wspierające wiadomości multicast.

    Innym ważnym aspektem dotyczącym protokołu EIGRP oraz RIP w kontekście sieci NBMA jest funkcjonalność podzielonego horyzontu (Split Horizon), która w powyższym przykładzie uniemożliwia ruterowi HQ przekazanie informacji otrzymanych od rutera BR1 do rutera BR2.

    Rodzaje topologii sieciowych

    Rodzaje modeli sieciowych

    • Proces Same-Layer Interaction – Zachodzi pomiędzy dwoma urządzeniami, wymieniającymi dane na poziomie jednej, tej samej warstwy modelu OSI.
    • Proces Adjacent-Layer Interaction – Zachodzi na jednym urządzeniu pomiędzy różnymi warstwami modelu OSI.
    • Funkcja End-to-end delivery – Jest realizowana w warstwie trzeciej za pomocą warstwy czwartej. Stanowi gwarancje dostarczenia całości przesyłanych danych, od urządzenia źródłowego do docelowego.

    Pozostałe tematy związane z podstawami sieci

    Podstawy sieci komputerowych

    Warstwy modelu OSI

    Bezpieczeństwo sieci

    Troubleshooting

  • (T) Struktury LSA 4-9 OSPF**

    (T) Struktury LSA 4-9 OSPF**

    Przykładowa topologia obrazująca działanie struktur LSA

    Przykładowa topologia obrazująca działanie struktur LSA

    LSA Type 4 – ASBR Summary

    • Struktury LSA typu czwartego są rozgłaszane przez rutery ABR (Area Border Router) jako element uzupełniający względem struktur LSA typu piątego. Zawierają one wartość RID rutera ASBR oraz ABR dzięki czemu umożliwiają lokalizację urządzenia ASBR (Autonomous System Border Router) znajdującego się w innej strefie (Area).
    • Struktury LSA typu piątego (LSA type 5) rozgłaszają trasy pochodzące z innych protokołów routingu bądź też innych instancji protokołu OSPF. Zawierają one oprócz podstawowych informacji dotyczących rozgłaszanej sieci, wartość RIDrutera ASBR rozgłaszającego daną trasę.
      • W przypadku urządzeń znajdujących się w tej samej strefie (Area), co ruter ASBR, struktura LSA typu piątego nie sprawiają żadnych problemów, ponieważ wszystkie urządzenia posiadają lokalizację rutera ASBR, pobraną z bazy LSDB (Na podstawie struktur LSA typu pierwszego).
      • W przypadku urządzeń znajdujących się w innej strefie (Area), niż ruter ASBR, informacja o jego wartości RID, na nic się nie zda innym urządzeniom, ponieważ nie posiadają one informacji o jego lokalizacji. W tym momencie wykorzystywana jest struktura LSA typu czwartego, ponieważ rozgłasza ona informacje o trasie oraz koszcie dotarcia do rutera ASBR poprzez ruter ABR.
    • Lokalne urządzenie —> (Koszt) —> ABR —> (+Koszt rozgłaszany przez LSA typu 4) —> ASBR (Z najniższą metryką trasy E2 / E1).
      • Wartość metryki dotarcia do sieci zewnętrznej E2 = Metryka rozgłaszana przez ruter ASBR.
      • Wartość metryki dotarcia do sieci zewnętrznej E1 = Metryka rozgłaszana przez ruter ASBR + koszt dotarcia do ASBR.

    Zawartość struktury LSA type 4

    Struktura LSA typu czwartego zawiera

    • Wartość RID rutera ASBR, rozgłaszającego trasę zewnętrzną.
    • Wartość RID rutera ABR, rozgłaszającego daną strukturę LSA.
    • Adres sieci wraz z maską.
    • Wartość LSID (Wartość RID rutera ASBR).
    • Koszt trasy rutera ABD do rutera ASBR (Metrykę).
    • Numer sekwencyjny.
    • Sumę kontrolną (Checksum).

    Wyświetlanie struktur LSA type 4

    • Informacje na temat struktury LSA typu czwartego można wyświetlić za pomocą komendy [show ip ospf database], znajdują się one pod punktem (summary ASB Link State (Area ID-area)), oraz za pomocą komendy [show ip ospf database asbr-summary].
    32-bitową wartość identyfikatora (LSID) w przypadku struktury LSA typy czwartego (LSA Type 4) stanowi wartość RID rutera ASBR.

    LSA Type 5 – AS External

    • Struktury LSA typu piątego są rozgłaszane przez rutery ASBR na granicy pomiędzy protokołem OSPF a innymi protokołami routingu dynamicznego bądź też inną instancją protokołu OSPF.
    • Struktury LSA typu piątego rozgłaszają trasy pochodzenia zewnętrznego, pochodzące od innych protokołów routingu bądź też innych instancji protokołu OSPF. Nie są jednak rozgłaszane w strefach specjalnych Stubby Area, gdzie rozgłaszana jest jedynie trasa domyślna.
    • Trasy zewnętrzne rozgłaszane przez struktury LSA typu piątego, dzielą się na dwa rodzaje różniące się od siebie metodą kalkulacji metryki. Są one następujące:
      • External type 1 (E1) – Nie dodaje wewnętrznych (Internal) wartości metryki do kalkulacji koszu całej trasy.
      • External type 2 (E2) – Dodaje wewnętrzne (Internal) wartości metryki do kalkulacji koszu całej trasy.

    Zawartość struktury LSA type 5

    Struktura LSA typu piątego zawiera

    • Wartość RID rutera ASBR, rozgłaszającego daną strukturę LSA.
    • Adres sieci wraz z maską.
    • Wartość LSID (Adres sieci bez maski).
    • Koszt danej trasy (Metrykę).
    • Rodzaj danej trasy (E1 bądź E2).
    • Numer sekwencyjny.
    • Sumę kontrolną (Checksum).

    Wyświetlanie struktur LSA type 5

    • Informacja na temat struktury LSA typu piątego można wyświetlić za pomocą komendy [show ip ospf database], znajdują się one pod punktem (Type-5 AS External Link State (Area ID-area)), oraz za pomocą komendy [show ip ospf database external].
    32-bitową wartość identyfikatora (LSID) w przypadku struktury LSA typy piątego (LSA Type 5) stanowi wartość stanowi adres rozgłaszanej sieci (bez maski).

    Struktury LSA 6-9

    LSA Type 6 – Group Membership

    Struktura LSA typu szóstego nie został zaimplementowana w systemie Cisco IOS.

    LSA Type 7 – External Attributes (NSSA External)

    • Struktury LSA typu siódmego są rozgłaszana przez rutery ASBR w obrębie stref specjalnych NSSA oraz Totally NSSA.
    • Struktury LSA typu siódmego pełnią w strefie NSSA oraz Totally NSSA podobną rolę, jaką pełnią struktury LSA typu piątego w innych strefach protokołu OSPF.
    • Ruter ASBR —> (NSSA LSA type 7) —> ABR —> (Area 0 LSA type 5).

    LSA Type 8 – Link LSAs (OSPFv3)

    • Struktury LSA typu ósmego rozgłaszają adresy IPv6 link-local do wszystkich ruterów współdziedziczących ten sam link.
    • Struktura LSA typu ósmego rozgłasza bit opcji.

    LSA Type 9 – Intra-Area Prefix LSAs  (OSPFv3)

    • Struktura LSA typu dziewiątego posiada podobną funkcjonalność względem protokołu IPv6 co struktura LSA typu pierwszego oraz drugiego względem protokołu IPv4.

    Podsumowanie struktur LSA

    LSA type Routing Table Symbol LSA type Routing Table Symbol LSA type Routing Table Symbol
    LSA 1 O LSA 2 O LSA 3 O IA
    LSA 4 O IA LSA 5 O E1 / O E2 LSA 7 O N1 / O N2

    Struktury LSA a symbole przypisane do tras w Tablicy Routingu

    Ograniczanie ilości otrzymywanych struktur LSA

    • Domyślnie system Cisco IOS nie ogranicza ilości otrzymywanych a następnie przetwarzanych struktur LSA. Istnieje jednak opcjonalna możliwość zabezpieczenia systemu przed nadmiernym napływem struktur LSA, za pomocą komendy [max-lsa 1-4294967294] użytej w trybie konfiguracji protokołu OSPF.
    • W przypadku przekroczenia liczby otrzymanych struktur LSA (Nie licząc struktur stworzonych przez lokalne urządzenie), system IOS wyśle komunikat systemowy „Log Messages”. Jeżeli sytuacja nie ulegnie zmianie a nowe struktury nadal będą docierały, ruter ponowi wiadomość „Log Messages”. W przypadku braku reakcji ruter rozwiąże wszystkie relacje sąsiedztwa oraz porzuci wszystkie zapisane struktury LSA. Rozpoczynając nawiązywanie nowych relacji od nowa.

    Pozostałe tematy związane z protokołem OSPF

    OSPFv3

  • (T) Wybór najkrótszej trasy OSPF**

    (T) Wybór najkrótszej trasy OSPF**

    Wybór najkrótszej trasy

    Proces wymiany struktur LSA, ma na celu stworzenie spójnej bazy LSDB, względem wszystkich urządzeń znajdujących się w obrębie jednej tej samej strefy (Area). Dzięki czemu możliwe staje się znalezienie najkrótszej trasy prowadzącej do sieci docelowej. Proces ten wygląda następująco:

    • Algorytm SPF analizuje zawartość bazy LSDB w celu znalezienia wszystkich tras prowadzących do sieci docelowej.
    • Dla każdej z znalezionych tras, protokół OSPF kalkuluje koszt dotarcia do sieci docelowej, na podstawie zsumowanych kosztów poszczególnych interfejsów sieciowych na drodze do celu.
    • Algorytm SPF dodaje to tablicy routingu trasę z najniższym kosztem dotarcia do sieci docelowej.
    Koszt interfejsu sieciowego względem protokołu OSPF może być wyświetlony za pomocą komendy [show ip ospf interface].
    Kalkulacja kosztów tras, prowadzących do sieci docelowej

    Kalkulacja najkrótszej trasy (Intra-Area Routes)

    • Podczas analizy bazy LSDB, protokół OSPF:
      • Szuka wszystkich sieci dodanych do bazy LSDB na podstawie struktur LSA typu pierwszego oraz drugiego.
      • Uruchamia algorytm SPF w celu znalezienia wszystkich tras prowadzących do sieci znalezionych w punkcie 1.
      • Kalkuluje koszt każdej trasy na podstawie kosztów interfejsów wyjściowych.
      • Wybiera trasę z najniższym kosztem względem wszystkich sieci znalezionych w punkcie 1
    • W przypadku znalezienia wielu tras o tym samym koście dotarcia do celu, OSPF wykorzystuje wszystkie trasy z pomocą funkcji Load-Balance. Maksymalną liczbę jednocześnie wykorzystywanych tras można skonfigurować za pomocą komendy [maximum-paths 1-32] w trybie konfiguracji protokołu OSPF.
    Zmiana zaszła w strukturze LSA typu pierwszego bądź drugiego wymaga ponownej rekalkulacji algorytmu SFP.

    Kalkulacja najkrótszej trasy (Interarea Routes)

    • Podczas analizy bazy LSDB, protokół OSPF:
      • Szuka najkrótszej trasy dotarcia do rutera ABR, rozgłaszającego struktury LSA typu trzeciego.
      • Dodaje do kosztu dotarcia do rutera ABR, koszt rozgłaszany poprzez strukturę LSA typu trzeciego. Jest to koszt trasy pomiędzy ruterem ABR a siecią docelową.
    • Struktura LSA typu trzeciego zawiera:
      • Adres sieci wraz z maską.
      • Koszt dotarcia z rutera ABR do sieci docelowej.
      • Wartość RID rutera ABR.
    Zmiana zaszła w strukturze LSA typu trzeciego nie wymaga ingerencji algorytmu SFP.

    Intra-Area Routes oraz Interarea Routes na ruterach ABRs

    • Problem
      związany z trasami Intra-Area Routes oraz Interarea Routes, pojawia się w sytuacji,
      w której wiele ruterów ABR łączą ze sobą dwie te same strefy (Area), w
      celu zachowania nadmiarowości.
    • Każdy
      z wyżej wspomnianych ruterów ABR posiada trasę Intra-Area Routes oraz Interarea
      Routes, prowadząca do sieci docelowej. Związku z tym protokół OSPF będzie
      kierował się następującą logiką:
      • Trasa Intra-Area jest zawsze lepsza od trasy
        Interarea Routes, niezależnie od kosztów obydwóch tras.
      • Jeżeli ruter ABR otrzyma strukturę typu trzeciego w strefie Nonbackbone,
        zignoruje ją.
    Trasa Intra-Area oraz Interarea na ruterach ABR

    Licznik użycia algorytmu SFP

    Każdorazowa zmiana struktury LSA typu pierwszego bądź drugiego, wymaga ponownego przeliczenia najkrótszej trasy z wykorzystaniem algorytmu SFP, co zwiększa wartość licznika widocznego pod wydrukiem komendy [show ip ospf].

    # show ip ospf
    …
    Area BACKBONE(0)
    Number of interfaces in this area is 1
    Area has no authentication
    SPF algorithm last executed 2w5d ago
    SPF algorithm executed 2 times
    Area ranges are
    Number of LSA 3. Checksum Sum 0x01101D
    Number of opaque link LSA 0. Checksum Sum 0x000000
    Number of DCbitless LSA 0
    Number of indication LSA 0
    Number of DoNotAge LSA 0
    Flood list length 0

    Kolejność wyboru tras protokołu OSPF (AD, Metric)

    1. Intra-Area (O).
    2. Inter-Area (O IA).
    3. External Type 1 (E1).
    4. External Type 2 (E2).
    5. NSSA Type 1 (N1).
    6. NSSA Type 2 (N2).

    Pozostałe tematy związane z protokołem OSPF

    OSPFv3

  • (T) Struktury LSA 1-3 OSPF**

    (T) Struktury LSA 1-3 OSPF**

    LSA Type 1 – Router

    • Struktury LSA typu pierwszego są rozgłaszane przez wszystkie rutery, względem pojedynczej strefy (Area). Zawierają one informacje o sieciach przyległych należących do jednej strefy (Area).
    • Sąsiednie urządzenia przekazują otrzymane od swoich sąsiadów struktury LSA typu pierwszego, a oni przekazują je do swoich sąsiadów, aż wszystkie urządzenia z danej strefy (Area) będą posiadały pełną wiedzę na temat wszystkich struktur LSA typu pierwszego, jakie są dostępne w obrębie tej samej strefy.

    Zawartość struktury LSA type 1

    • Struktura LSA typu pierwszego zawiera następujące informacje:
      • LS age – Czas jaki upłynął od ostatniej aktualizacji danej struktury LSA (Age).
      • LS Type – Rodzaj struktury LSA (Router Links).
      • Link State ID – Wartość LSID (Local router ID (RID)).
      • Advertising Router – Wartość RID lokalnego urządzenia.
      • Sequence Number – Wartość numeru sekwencyjnego.
      • Checksum – Sumę kontrolną.
      • Length – Długość (Wielkość struktury LSA w Bajtach).
      • Number of links – Ilość linków jakie zawiera dana struktura.

    Informacje dotyczące interfejsów

    • Struktury LSA typu pierwszego zawierają informację o wszystkich interfejsach sieciowych, aktywnych względem określonej strefy (Area). W zależności od rodzaju interfejsu, OSPF przechowuje różne informacje.
    • W przypadku interfejsów sieciowych dla których została przeprowadzona elekcja urządzeń DR / BDR, struktura LSA typu pierwszego będzie zawierała jedynie adres IP urządzenia pełniącego rolę DR-a. Informację dotyczące sieci przyległych, są w tym przypadku rozgłaszane przez urządzenie główne (DR) za pomocą struktur LSA typu drugiego.
      • OSPF określa sieć tego typu, mianem sieci tranzytowej  „Transit Network”.
    • W przypadku interfejsów sieciowych dla których nie została przeprowadzona elekcja urządzeń DR / BDR, struktura LSA typu pierwszego będzie zawierała:
      • Względem sieci rozgłoszeni-owych (broadcasts), adres sieci, maskę oraz koszt interfejsu.
        • OSPF określa sieć tego typu mianem sieci krańcowej  „Stub Network”.
      • Względem sieci Point-to-Point, wartość RID sąsiedniego urządzenia oraz standardowe informacje rozgłaszane przez sieci broadcasts-owe takie jak adres sieci,maskę oraz koszt interfejsu.
        • OSPF określa sieć tego typu mianem sieci krańcowej „Stub Network”.
    W przypadku konfiguracji interfejsu loopback, protokół OSPF zignoruje skonfigurowaną maskę sieciową, rozgłaszając daną sieć jako „Stub Network” z maską 255.255.255.255. Aby zmienić to domyślne zachowanie protokołu OSPF należy wykonać komendę [ip ospf network point-to-point] w trybie konfiguracji interfejsu loopback.
    Każde urządzenie tworzy swoją własną pojedynczą strukturę LSA typu pierwszego, wyjątek od tej reguły stanowią rutery ABR, które tworzy po jednej strukturze LSA typu pierwszego względem każdej ze stref (Area) do której należy.
    Trzy przykładowe Struktury LSA typu pierwszego (Area 5)

    Zawartość struktury LSA type 1

    • Struktura LSA typu pierwszego zawiera:
      • Wartość LSID (Wartość RID lokalnego urządzenia).
      • Informacje o wszystkich aktywnych względem protokołu OSPF interfejsach (Adres/maska).
      • Koszty interfejsów (OSPF Interface Cost).
      • Wartości RID sąsiednich urządzeń.
      • Numer sekwencyjny.
      • Sumę kontrolną (Checksum).

    Wyświetlanie struktur LSA type 1

    • Informacje na temat struktury LSA typu pierwszego można wyświetlić za pomocą komendy [show ip ospf database], znajdują się one pod punktem (Router Link State (Area ID-area)) jak i za pomocą komendy [show ip ospf database router [RID]].
      • [show ip ospf database] – Wyświetla podsumowanie wszystkich otrzymanych struktur LSA.
      • [show ip ospf database router [RID]] – Wyświetla szczegółowe informacje na temat struktury LSA typu pierwszego, otrzymanej od określonego w komendzie sąsiada (RID). Poszczególne punkty opisują oddzielne linki, sieci wyświetlając między innymi informacje na temat rodzaju połączenia w wpisie „Link Connected to: (Rodzaj topologii)”.
    Ponieważ wartość RID jest wykorzystywana przez wiele struktur LSA, Cisco zaleca, aby była to wartość łatwa to zapamiętania (Identyfikacji konkretnego urządzenia).
    32-bitową wartość identyfikatora (LSID) w przypadku struktury LSA typy pierwszego (LSA Type 1) stanowi wartość RID rutera który takową strukturę LSA stworzył.

    LSA Type 2 – Network

    • Struktury LSA typu drugiego są rozgłaszane przez rutery pełniące rolę DR-a w sieciach wielodostęp-owych.
    • Algorytm SPF wymaga aby baza LSDB, zawsze tworzyła topologię, opartą o dwa rutery (Nodes) połączone ze sobą za pomocą jednej sieci (Link). Zasada ta znacząco komplikuje proces tworzenia wpisów dotyczących sieci wielodostęp-owych, w których pewna liczba ruterów połączona jest ze sobą za pomocą jednej sieci (Linku). W tej sytuacji baza LSDB tworzy pseudo-strukturę LSA typu drugiego, do której podłączane są poszczególne rutery.

    Proces elekcji rutera DR

    • Zgodnie z właściwym rodzajem topologii sieciowej. Protokół OSPF przystępuje do elekcji urządzenia pełniącego rolę DR, zaraz po odebraniu pierwszej wiadomości Hello od przynajmniej jednego z sąsiadów. Proces elekcji jest prowadzony jest w celu:
      • Tworzenia oraz propagowania struktury LSA typu drugiego.
      • Wsparcia procesu wymiany danych bazy LSDB.
    • Proces elekcji urządzenia DR / BDR wygląda następująco:
      • Rolę aktywną (DR) przejmuje urządzenie z najwyższą wartością priorytetu (0–255). Jeżeli wartość ta jest taka sama na wszystkich urządzeniach, pod uwagę brana jest najwyższa wartość RID.
      • Urządzenie z drugą najwyższą wartością (Priorytetu / wartości RID) przejmuje rolę zapasową BDR (Backup Designated Router).
      • Po zakończeniu elekcji urządzeń (DR, BDR), ponowna elekcja może nastąpić jedynie w sytuacji awarii przynajmniej jednego z urządzeń pełniących rolę DR-a bądź BDR-a.
      • W przypadku utraty DR-a jego rolę przejmuje BDR niezależnie od tego czy w sieci istnieje urządzenia z większą wartością priorytetu czy też nie takowego nie ma.
      • Wartość priorytetu można skonfigurować za pomocą komendy [ip ospf priority 0-255] w trybie konfiguracji interfejsu sieciowego.

    Znaczenie struktury LSA type 2

    • Jako że protokół OSPF w przypadku sieci wielodostęp-owych nie jest w stanie przyporządkować w bazie LSDB więcej niż dwóch ruterów do jednego linku, wykorzystuje strukturę LSA typu drugiego w postaci pseudo kodu. W takim przedstawieniu każda struktura LSA typu pierwszego stworzona przez urządzenia podłączone do tej samej sieci wielodostęp-owej, jest łączona w bazie LSDB do pseudo struktury LSA typu drugiego.
    • Struktura LSA typu drugiego jest tworzona oraz propagowana przez ruter pełniący rolę DR-a.
    Cztery przykładowe Struktury LSA typu pierwszego oraz jedna typu drugiego (Area 34)

    Zawartość struktury LSA type 2

    • Struktura LSA typu drugiego zawiera:
      • Wartość LSID (Wartość ID urządzenia pełniącego rolę DR-a).
      • Informacje o wszystkich aktywnych względem protokołu OSPF interfejsach (Adres/maska).
      • Wartości RID sąsiednich urządzeń.
      • Numer sekwencyjny.
      • Sumę kontrolną (Checksum).

    Wyświetlanie struktur LSA type 2

    • Informacje na temat struktury LSA typu drugiego można wyświetlić za pomocą komendy [show ip ospf database], znajdują się one pod punktem (Net Link State (Area ID-area)) jak i za pomocą komendy [show ip ospf database {router RID / network [LSID]}].
      • [show ip ospf database] – Wyświetla podsumowanie wszystkich otrzymanych struktur LSA.
      • [show ip ospf database network [LSID]] – Wyświetla szczegółowe informacje na temat struktury LSA typu drugiego (względem danej wartości LSID), w tym wartości RID wszystkich struktur LSA typu pierwszego, należących do danej sieci wielodostęp-owej a tym samym podłączonych do pseudo struktury LSA typu drugiego.

    LSA Type 3 – Net Summary

    Struktury LSA typu pierwszego (LSA type 1) są propagowane w obrębie jednej strefy (Area), struktury LSA typu drugiego (LSA type 2) są propagowane w obrębie jednej sieci wielodostęp-owej, tymczasem struktury LSA typu trzeciego (LSA type 3) są rozgłaszane za pomocą ruterów granicznych ABR, pomiędzy różnymi strefami (Multiple areas).
    • Struktury LSA typu trzeciego są rozgłaszane przez rutery ABR, stanowiące granicę pomiędzy strefami (Multiple areas).
    • Ruter ABR generuje po jednej strukturze LSA typu trzeciego względem każdej z rozgłaszanych sieci, dla każdej strefy (Area) z osobna. Zamieszczając w nich jedynie podstawowe informacje na temat rozgłaszanej sieci.
    Cztery przykładowe struktury LSA typu trzeciego
    • Zgodnie z powyższą grafiką, każdy ruter wewnętrzny (Internal Router), propaguje stworzone przez siebie struktury LSA typu pierwszego (Fioletowe strzałki) w obrębie jednej strefy (Area), tak aby każdy z ruterów posiadał identyczną zawartość bazy LSDB. Urządzenie graniczne ABR (Area Border Router) stanowiące barierę pomiędzy strefami (Area), rozgłaszając sieci pomiędzy strefami za pomocą struktur LSA typu trzeciego (Czerwone strzałki). Zgodnie z następującymi zasadami:
      • Każda struktura LSA typu trzeciego przenosi informację o jedynie jednej, z rozgłaszanych sieci.
      • Ruter ABR tworzy jedną strukturę LSA typu trzeciego względem każdej z rozgłaszanych sieci, dla każdej strefy z osobna (Poza strefą, z której pochodzi rozgłaszana sieć).

    Zawartość struktury LSA type 3

    • Struktura LSA typu trzeciego zawiera:
      • Wartość RID rutera ABR, rozgłaszającego daną strukturę LSA.
      • Adres sieci wraz z maską.
      • Wartość LSID (Adres sieci bez maski).
      • Wartość kosztu (Metryki).
      • Numer sekwencyjny.
      • Sumę kontrolną (Checksum).

    Wyświetlanie struktur LSA type 3

    • Informacje na temat struktury LSA typu trzeciego można wyświetlić za pomocą komendy [show ip ospf database / show ip ospf database summary [LSID]], znajdują się one pod punktem (summary Net Link State (Area ID-area)).
      • [show ip ospf database] – Wyświetla podsumowanie wszystkich otrzymanych struktur LSA.
      • [show ip ospf database summary LSID] – Wyświetla szczegółowe informacje na temat struktury LSA typu trzeciego.
    32-bitową wartość identyfikatora (LSID) w przypadku struktury LSA typy trzeciego (LSA Type 3) stanowi adres rozgłaszanej sieci (bez maski).

    Podsumowanie struktur LSA 1-3

    • Protokół
      OSPF wykorzystuje struktury LSA typu pierwszego, drugiego oraz trzeciego w celu
      kalkulacji najlepszej drogi dotarcia do sieci docelowej. Poniższa tabela
      prezentuje różnice pomiędzy trzema podstawowymi strukturami LSA:
    LSA Type (Number) LSA Type (Name) This Type Represents Show ip ospf database … LSID is Equal to Created by
    1 Router A one router in one area router RID of router Each router creates its own peer area
    2 Network A subnet in with a DR exists network DR’s IP address in the subnet The DR in that subnet
    3 Summary A subnet in another Area summary Subnet address An ABR

    Podsumowanie struktur LSA 1-3

    Pozostałe tematy związane z protokołem OSPF

    OSPFv3

  • (T) LSDB (Link-State Database) OSPF**

    (T) LSDB (Link-State Database) OSPF**

    Struktura danych protokołu OSPF

    • Adjacency Database <-> Neighbor Table:
      • Zawiera listę wszystkich ruterów z którymi lokalne urządzenie nawiązało relację sąsiedztwa.
      • Jej zawartość może być wyświetlona za pomocą komendy [show ip ospf neighbor].
      • Jest unikalna względem każdego z ruterów.
    • Link-State Database (LSDB) <-> Topology Table:
      • Posiada informacje o wszystkich ruterach należących do tej samej strefy (Area).
      • Zawiera wartości RID wszystkich ruterów należących do tej samej strefy (Area).
      • Posiada informacje o wszystkich sieciach należących do tej samej strefy (W tym adresy IP oraz maski sieciowe).
      • Jej zawartość może być wyświetlona za pomocą komendy [show ip ospf database].
      • Jest taka sama względem wszystkich ruterów w danej strefie.
    • Forwarding Database <-> Routing Table:
      • Zawiera trasy dodane przez algorytm SPF, na podstawie zawartości bazy Link-State Database (LSDB).
      • Jej zawartość może być wyświetlona za pomocą komendy [show ip route ospf].
      • Jest unikalna względem każdego z ruterów, ponieważ przedstawia sieć protokołu OSPF w postaci drzewa topologii sieciowej, z lokalnym ruterem stanowiącym korzeń.

    Struktury LSA

    • Struktury LSA są wykorzystywane przez protokół OSPF, w celu wymiany informacji dotyczących budowy topologii sieciowej.
    • Poszczególne informacje zawarte w strukturach LSA tworzą bazę danych LSDB (Link State Data Base).
      • LSA Type 1 – Router.
      • LSA Type 2 – Network.
      • LSA Type 3 – Net Summary.
      • LSA Type 4 – ASBR Summary.
      • LSA Type 5 – AS External.
      • LSA Type 6 – Group Membership.
      • LSA Type 7 – External Attributes (NSSA External).
      • LSA Type 8 – Link LSAs (OSPFv3).
      • LSA Type 9 – Intra-Area Prefix LSAs  (OSPFv3).
    • Przed rozpoczęciem procesu wymiany danych zgromad
    • zonych w bazie LSDB, każdy z ruterów rozpoczyna wysyłanie wiadomości DBD zawierających wartości LSID każdej posiadanej przez siebie struktury LSA. Jeżeli sąsiednie urządzenie zorientuje się że nie posiada którejś ze struktur LSA, może o nią poprosić za pomocą zapytania LSR. W odpowiedzi na które, otrzyma wiadomość LSU zawierającą brakujące struktury LSA.

    Algorytm SPF (Shortest Path First)

    • Protokół OSPF w celu wyznaczenia najkrótszej trasy dotarcia do celu, wykorzystuje algorytm „Dijkstra SPF Algorithm”.
    • Algorytm SPF (Shortest Path First) tworzy drzewo, którego korzeniem jest lokalny ruter (Na jego podstawie wyliczana jest najkrótsza trasa dotarcia do każdej znanej sieci). Następnie wyliczone trasy są przekazywane do lokalnej tablicy routingu.

    Zmiana zawartości w rozgłaszanej strukturze LSA

    • Jeżeli po dokonaniu zmiany w topologii sieciowej, struktura LSA np. typu pierwszego przestała być już aktualna, ruter za nią odpowiedzialny zacznie rozgłaszać ją ze zmodyfikowaną wartość wieku (Age), zwiększoną do wartości „Max Age” czyli 3600 sekund. Po czy stworzy a następnie zacznie rozgłaszać nową strukturę LSA, ze zwiększonym numerem sekwencyjnym oraz zresetowanym czasem (Age).

    Pozostałe tematy związane z protokołem OSPF

    OSPFv3

  • (T) Rodzaje topologii sieciowych OSPF**

    (T) Rodzaje topologii sieciowych OSPF**

    Rodzaje topologii sieciowych protokołu OSPF

    • Point-to-Point – Dwa urządzenia połączone pojedynczym linkiem np. serialowym czy Ethernet-owym.
    • Broadcast multiaccess – Wiele urządzeń połączonych do jednej sieci rozgłoszeni-owej np. poprzez przełącznik sieciowy.
    • Non Broadcast multiaccess (NBMA) – Wiele urządzeń połączonych do sieci niewspierającej ruchu rozgłoszeni-owego.
    • Point-to-Multipoint – Wiele urządzeń połączonych do sieci w topologii Hub-and-Spoke.
    • Virtual links – Wirtualne połączenia prowadzące z strefy niebędącej strefą Backbone (Area 0) do strefy głównej (Area 0).
    Interface Type Used DR / BDR? Default Hello / Dead Interval Dynamic Discovery of Neighbors? More that Two Routers allowed in the Subnet?
    Broadcast Yes 10 / 40 Yes Yes
    Nonbroadcast [1](NBMA) Yes 30 / 120 No Yes
    Point-to-Point [2] No 10 / 40 Yes No
    Point-to-Multipoint Broadcast No 30 / 120 Yes Yes
    Point-to-Multipoint Nonbroadcast No 30 / 120 No Yes
    Loopback No —- —- No

    Porównanie rodzajów topologii sieciowych protokołu OSPF

    Broadcast topology

    • Protokół OSPF umożliwia skonfigurowanie statycznego połączenia sieciowego w topologii broadcast, za pomocą komendy [ip ospf network broadcast] wydanej w trybie konfiguracji interfejsu sieciowego.

    Point-to-Point topology

    • Protokół OSPF umożliwia skonfigurowanie statycznego połączenia sieciowego w topologii Point-to-Point, za pomocą komendy [ip ospf network point-to-point] wydanej w trybie konfiguracji interfejsu sieciowego.
    • Interfejs funkcjonujący w topologii Point-to-Point względem protokołu OSPF, może być zweryfikowany za pomocą komendy [show ip ospf interface interfejs] gdzie w punkcie Network Type powinien widnieć zapis [POINT_TO_POINT] jak i za pomocą komendy [show ip ospf neighbor] gdzie w punkcie state powinien widnieć zapis [FULL/].

    Non-broadcast multiaccess (NBMA) topology

    • Protokół OSPF umożliwia skonfigurowanie statycznego połączenia sieciowego w topologii nonbroadcast, za pomocą komendy [ip ospf network non-broadcast] wydanej w trybie konfiguracji interfejsu sieciowego.
    • W przypadku topologii nonbroadcast, automatyczne wykrywanie sąsiadów nie jest niemożliwe, tym samym wymagana jest ręczna konfiguracja statycznych relacji sąsiedztwa, za pomocą komendy [neighbor adres-IP-sąsiada] wydanej w trybie konfiguracji protokołu OSPF.

    Point-to-Multipoint topology

    • Protokół OSPF umożliwia skonfigurowanie statycznego połączenia sieciowego w topologii Point-to-Multipoint, za pomocą komendy [ip ospf network point-to-multipoint] wydanej w trybie konfiguracji interfejsu sieciowego.
    • W przypadku sieci Point-to-Multipoint istnieje możliwość przypisania dodatkowej wartości kosztu względem konfigurowanych relacji sąsiedztwa, za pomocą komendy [neighbor adres-IP cost 1-65535] wydanej w trybie konfiguracji protokołu OSPF.

    Point-to-Multipoint Non-broadcast topology

    • Protokół OSPF umożliwia skonfigurowanie statycznego połączenia sieciowego w topologii Point-to-Multipoint nonbroadcast, za pomocą komendy [ip ospf network point-to-multipoint non-broadcast] wydanej w trybie konfiguracji interfejsu sieciowego.
    • W przypadku topologii nonbroadcast, automatyczne wykrywanie sąsiadów nie jest niemożliwe, tym samym wymagana jest ręczna konfiguracja statycznych relacji sąsiedztwa, za pomocą komendy [neighbor adres-IP-sąsiada] wydanej w trybie konfiguracji protokołu OSPF.

    Virtual links

    • Połączenie wirtualne stosowane w protokole OSPF, ma na celu zapewnienie bezpośredniej łączności pomiędzy strefą główną (Backbone Area 0) a inną strefą (Area). W sytuacji, w której obydwie strefy nie są ze sobą bezpośrednio połączone, ponieważ rozdziela je inna strefa. W takim przypadku zastosowanie połączenia wirtualnego (Virtual link) stanowi tymczasowe rozwiązanie umożliwiające bezpośrednią komunikację ze strefą (Backbone).
    • Połączenie wirtualne może być przydatne w sytuacji:
      • Gdy połączenie strefy (Nonbackbone Area) za pomocą sieci WAN, poprzez inną strefę (Nonbackbone Area) jest tańsze niż bezpośrednie połączenie ze strefą (Backbone Area 0).
      • Utraty połączenia pomiędzy dwoma częściami strefy (Backbone Area 0), co może doprowadzić do powstania dwóch niezależnych stref (Area 0).
      • Łączenia ze sobą dwóch niezależnych topologii sieciowych, z których każda posiada własną strefą Area 0.

    Pozostałe tematy związane z protokołem OSPF

    OSPFv3

    [1] Domyślnie występuje w przypadku protokołu Frame Relay na fizycznych oraz wielopunktowych pod-interfejsach.

    [2] Domyślnie występuje w przypadku protokołu Frame Relay na pod-interfejsach Point-to-Point.

  • (T) Nawiązywanie relacji sąsiedztwa OSPF**

    (T) Nawiązywanie relacji sąsiedztwa OSPF**

    Nawiązywanie relacji sąsiedztwa

    Warunki nawiązania relacji sąsiedztwa

    Aby routery nawiązały ze sobą relację sąsiedztwa muszą spełniać następujące kryteria:

    Wymagania dotyczące relacji sąsiedztwa EIGRP OSPF
    Sąsiedzi muszą być wstanie wysyłać pomiędzy sobą pakiety IP Tak Tak
    Adresy IP muszą należeć do tej samej sieci Tak Tak
    Interfejsy nie mogą działać w trybie pasywnym Tak Tak
    Sąsiedzi muszą należeć do tego samego systemu autonomicznego ASN (EIGRP) bądź procesu „process-ID” (OSPF) Tak Nie
    Czasy hello oraz Hold (EIGRP), Dead (OSPF) muszą się zgadzać Nie Tak
    Sąsiedzi muszą przejść proces autentykacji (Jeżeli przynajmniej jedno z urządzeń takiego wymaga) Tak Tak
    Sąsiedzi muszą należeć do tej samej strefy Area (OSPF). N/A Tak
    Wartość IP MTU musi się zgadzać Nie Tak
    Wartość K-value musi być taka sama Tak N/A
    Wartość Router ID musi być unikalna Przeważnie nie Tak

    Wymagania dotyczące procesu nawiązywania relacji sąsiedztwa dla protokołu OSPF / EIGRP

    W przypadku kryterium „Adresy IP muszą należeć do tej samej sieci” logika postępowania protokołu OSPF różni się od logiki postępowania protokołu EIGRP. OSPF porównuje całą wartość adresu oraz maski sąsiedniego urządzenia, natomiast EIGRP patrzy jedynie na to czy adres IP sąsiada należy do tej samej sieci co lokalny interfejs. Przykładowo sąsiednie urządzenie z skonfigurowanym adresem [ip address 192.168.10.2 255.255.255.252] nawiąże relacje sąsiedztwa z interfejsem o adresie [ip address 192.168.10.1 255.255.255.0] w przypadku protokołu EIGRP, ale nie OSPF.

    Nazewnictwo związane z procesem nawiązywania relacji sąsiedztwa

    • DR (Designated Router) – Główne urządzenie zbierające nadchodzące struktury LSA typu pierwszego, w obrębie jednej sieci wielodostęp-owej. W celu ich przetworzenia a następnie rozesłania w postaci struktury LSA typu drugiego, do sąsiednich urządzeń (W obrębie jednej sieci wielodostęp-owej).
    • BDR (Buckup Designated Router) – Ruter zapasowy , przejmujący rolę aktywną (DR) w przypadku awarii rutera DR-a.
    • DROther – Każdy ruter sieci wielodostęp-owej, nie pełniący roli DR-em bądź BDR-em.
    • Stan Adjacent – Osiągają rutery DROther w relacji z innymi urządzeniami działającym w trybie DROther (Nie osiągają one pełnej relacji sąsiedztwa a jedynie tryb Two-Way State).
    • Stan Fully Adjacent – Osiągają rutery: DR w relacji z BDR, DR z DROther oraz BDR z DROther (Wszystkie wymienione kombinacje relacji sąsiedztwa osiągają pełny stan Full State).

    Przyczyny procesu elekcji rutera DR oraz BDR

    • Sieci wielodostęp-owe takie jak „Broadcast multiaccess”,mogą wymagać nawiązanie wielu relacji sąsiedztwa, a ty samym spowodować wygenerowanie dużej liczby wiadomości aktualizacyjnych, zgodnie ze wzorem n (n-1)/2 (Z czego n stanowi ilość podłączonych do sieci ruterów).
    • Aby zapobiec powstaniu nadmiarowego ruchu sieciowego, rutery prowadzą elekcję urządzenia pełniącego rolę DR-a (Designated Router), na podstawie wymienianych pomiędzy sobą wiadomości Hello. Po zakończeniu procesu elekcji do wybranego rutera DR kierowane są wszystkie wiadomości LSA typu pierwszego , nadchodzące od sąsiadów należących do tej samej sieci wielodostęp-owej. Następnie DR odsyła przetworzone przez siebie dane za pomocą struktur LSA typu drugiego, niwelując tym samym potrzebę wymiany aktualizacji bezpośrednio pomiędzy sąsiadami DROther.
    • Ponadto oprócz rutera DR, następuje elekcja urządzenia zapasowego BDR (Backup Designated Router), mogącego automatycznie przejąć rolę aktywną (DR) w przypadku utraty kontaktu z obecnym ruterem DR.
    Inne rutery znajdujące się w sieci wielodostęp-owej nazywane są DROther. Nie osiągają one pomiędzy sobą pełnej relacji sąsiedztwa Full State a jedynie stan pośredni Two-way State (Stan Two-way State, oznacza że sąsiednie urządzenia nie wymieniły pomiędzy sobą informacji na temat zawartości baz LSDB).

    Elekcja rutera DR oraz BDR

    • Rolę aktywną (DR) przejmuje urządzenie z najwyższą wartością priorytetu (0–255). Jeżeli wartość ta jest taka sama na wszystkich urządzeniach, pod uwagę brana jest najwyższa wartość RID.
    • Urządzenie z drugą najwyższą wartością (Priorytetu / wartości RID) przejmuje rolę zapasową BDR (Backup Designated Router).
    • Po zakończeniu elekcji urządzeń (DR, BDR), ponowna elekcja może nastąpić jedynie w sytuacji awarii przynajmniej jednego z urządzeń pełniących rolę DR-a bądź BDR-a.
    • W przypadku utraty DR-a jego rolę przejmuje BDR niezależnie od tego czy w sieci istnieje urządzenia z większą wartością priorytetu czy też nie takowego nie ma.
    • Wartość priorytetu można skonfigurować za pomocą komendy [ip ospf priority 0-255] w trybie konfiguracji interfejsu sieciowego.

    Stany protokołu OSPF

    Nawiązywanie relacji sąsiedztwa

    • Down State – Początkowa faza procesu nawiązywania relacji sąsiedztwa. W większości przypadków urządzenia pozostają w tej fazie kiedy statycznie skonfigurowany sąsiad nie odpowiada na wiadomości powitalne Hello. Tego typu relacja z innym ruterem wskakuje, że lokalne urządzenie zna adres IP swojego sąsiada, ale nie może nawiązać z nim relacji sąsiedztwa, z powodu problemów związanych z komunikacją.
    • Attempt State – Stan występujący jedynie w sieciach „Nonbroadcast Multiaccess” NBMA, w przypadku statycznie skonfigurowanej relacji sąsiedztwa (Ruter wie o swoim sąsiedzie ale nie otrzymał od niego żadnej wiadomości Hello).
    • Init State – Połączenie z sąsiednim ruterem zostaje przeniesione w stan „Init” zaraz po otrzymaniu pierwszej wiadomości Hello, w której lista widzianych routerów (Active Neighbor) nie zawiera wartości RID lokalnego urządzenia. Co oznacza, że jest ono w stanie wykryć swojego sąsiada, ale nie ma pewności czy samo jest dla niego widoczne.
    • Two-Way State – Połączenie z sąsiednim ruterem zostaje przeniesione w stan „Two-Way” zaraz po otrzymaniu pierwszej poprawnej wiadomości Hello, której lista widzianych routerów (Active Neighbor) zawiera wartości RID lokalnego urządzenia. Co oznacza, że obydwa urządzenia są dla siebie widoczne. Stan ten jest stanem stabilnym dla sąsiadów nie aspirujących do fazy „Full State”, w przypadku sieci wielodostęp-owych „Multiaccess” pomiędzy urządzeniami DROther.
    Proces nawiązywania relacji sąsiedztwa
    • Powyższa grafika prezentuje przykładowy proces nawiązywania relacji sąsiedztwa, pomiędzy dwoma ruterami znajdującymi się w stanie „Down State”:
    • Obydwa urządzenia wysyłają do siebie wiadomości powitalne Hello, na Multicast-owy adres IP (224.0.0.5, Init).
    • Każdy z routerów weryfikuje otrzymaną od sąsiada wiadomość powitalną Hello, sprawdzając zgodność wszystkich parametrów wymaganych do nawiązania prawidłowej relacji sąsiedztwa.
    • Obydwa urządzenia wysyłają kolejne wiadomości powitalne Hello, zawierające wartość RID sąsiedniego routera.
    • Po otrzymaniu wiadomości Hello zawierającej lokalną wartością RID, wpisaną w listę widzianych routerów (Seen), relacja pomiędzy urządzeniami przechodzi w stan „Two-Way State”.
    • Po osiągnięciu stanu „Two-Way State” rutery decydują, czy powinny nawiązać pełną relację sąsiedztwa, w oparciu o pełnione przez siebie role (DR, BDR bądź DROther). W przypadku topologii niewymagających elekcji rutera DR, każdorazowa odpowiedź na to pytanie będzie twierdząca.

    Wymiana danych LSDB

    • ExStart State – Rutery przechodzą do stanu „ExStart” ze stanu „Init” bądź stanu „Two-Way” po potwierdzeniu wzajemnej widoczności jak i zdecydowaniu o należności nawiązania pełnej relacji sąsiedztwa, pomiędzy obydwoma urządzeniami. Podstawowym zadaniem stanu „ExStart State” jest nawiązanie relacji Master/Slave pomiędzy sąsiadami, za pomocą wiadomości „Database Description” zawierającej wartości RID, na postawie których wybierany jest ruter pełniący rolę Master-a (Większa wartość RID) oraz negocjowany jest startowy numeru sekwencyjny dla struktur LSA.
    • Exchange State – Po nawiązaniu relacji Master/Slave pomiędzy sąsiadami, rutery przechodzą w stan „Exchange State”, w którym to obydwa urządzenia wymieniają pomiędzy sobą wiadomości „Database Description”, proces ten jest kontrolowany przez ruter pełniący rolę Master-a. Wiadomości DBD zawierają wartości LSID (Link State ID) oraz numery sekwencyjne wszystkich znanych struktur LSA z danej strefy (Area).
    • Loading State – Po zakończeniu wymiany informacji o wszystkich znanych strukturach LSA, relacja pomiędzy ruterami przechodzi w stan „Loading State”. W tym momencie każdy z ruterów określa jakich struktur LSA, które posiada sąsiednie urządzenie mu brakuje, a następnie wysyła oddzielne wiadomości LSR dla każdej z brakujących struktur. W odpowiedzi na zapytanie LSR sąsiednie urządzenie odsyła wiadomość LSU zawierającą brakujące struktury LSA, oczekując tym samym na potwierdzenie otrzymania wiadomości LSU za pomocą potwierdzenia ACK.
    • Full State – Po zakończeniu obopólnej wymiany danych, relacja sąsiedztwa przechodzi w stan „Full State”.
    stanie „Exchange State” wymianie ulegają jedynie dane LSID oraz numery sekwencyjne wszystkich struktur LSA. Natomiast w wiadomościach LSU przesyłane są pełne kopie struktur LSA.
    Wiadomości DBD, LSR oraz LSU są wymieniane pomiędzy ruterami za pomocą pakietów Unicast-owych.
    Wiadomości LSU mogą być również wymieniane za pomocą adresu Multicast-owego.
    Proces wymiany informacji zawartych w bazie LSDB

    Nawiązywanie relacji Master/Slave

    • Funkcja nawiązywania relacji Master/Slave, ma na celu skoordynowanie procesu wstępnej wymiany danych LSDB za pomocą wiadomości DBD. Ruter pełniący rolę Master-a zostaje wybrany na podstawie wartości RID, przejmując tym samym role nadzorczą umożliwiającą mu inicjonowanie wymiany wiadomości DBD czy określanie wartości numeru sekwencyjnego dla struktur LSA. Tmczasem ruter pełniący rolę Slave może jedynie odpowiadać wiadomościami DBD, na wysłane przez Master-a zapytania DBD.

    Wymiana danych LSDB bez elekcji rutera pełniącego role DR

    • Po osiągnieciu stanu „Two-Way” obydwa rutery decydują, czy nawiążą ze sobą pełną relację sąsiedztwa, polegającą na wymianie danych zawartych w bazie LSDB. Jeżeli w sieci łączącej obydwa urządzenia nie zachodzi potrzeba elekcji rutera DR, BDR, odpowiedź jest zawsze twierdząca. W takiej sytuacji urządzenia postępują zgodnie z następującą logiką:
      • 1. Odkrywają struktury LSA znane sąsiadowi, ale nie znane jemu samemu.
      • 2. Odkrywają struktury LSA znane obydwóm ruterom, z czego te posiadane przez sąsiada są bardziej aktualne.
      • 3. Proszą sąsiedni ruter o kopie wszystkich brakujących bądź nie aktualnych struktur LSA, określonych w punkcie 1 oraz 2.
    • Po otrzymaniu pierwszej wiadomości DBD (Wysłanej na Multicast-owy adres IPv4 224.0.0.5) ruter przenosi relację sąsiedztwa w stan „ExStart State”, do momentu elekcji rutera pełniącego rolę Master, na podstawie większej wartości RID (Router ID).
    • Po określeniu roli Master-a, rutery kontynuują wymianę wiadomości DBD zawierających dane LSID oraz numery sekwencyjne wszystkich struktur LSA, w celu określenia powyższych punktów 1 oraz 2. Następnie relacja przechodzi w stan „Loading State” rozpoczynając następujący cykl zdarzeń:
      • Rutery wysyłają do siebie nawzajem zapytania LSR zawierające dane LSID, odpowiadające każdej z brakujących bądź nieaktualnych strukturze LSA jakich same nie posiadają.
      • W odpowiedzi na zapytania LSR sąsiedni ruter wysyła odpowiedź LSU zawierającą pełną strukturę LSA.
      • Po otrzymaniu odpowiedzi LSU ruter potwierdza otrzymanie struktury LSA za pomocą wiadomości LSAck (Explicit Acknowledgment) bądź odsyłając otrzymaną wiadomość LSU (Implicit Acknowledgment).

    Wymiana danych LSDB po elekcji rutera pełniącego role DR-a, BDR-a

    • Wymiana danych bazy LSDB, w sieci posiadającej rutery pełniące rolę DR-a oraz BDR-a, różni się od tego samego procesu zachodzącego w sieci nie wymagającej elekcji ruterów DR oraz BDR. Chodź nazewnictwo oraz znaczenie poszczególnych etapów jest takie samo, to wymiana danych pomiędzy niektórymi z ruterów może być ograniczona. Ponieważ pełną relację sąsiedztwa a co za tym idzie pełną wymianę danych LSDB, utrzymują jedynie rutery DROther z ruterami DR oraz ruterami BDR jak i rutery DR z ruterami BDR.
    • Proces działania wymiany danych bazy LSDB jest następujący:
    • Rutery DROther oraz rutery BDR wysyłają wiadomości DBD zawierające wartości LSID struktur LSA Typu pierwszego (LSA Type 1) na multicast-owy adres 224.0.0.6, oznaczający wszystkie rutery DR oraz DBR.
    • Ruter płonący rolę DR-a przetwarza wszystkie otrzymane wiadomości DBD, odpowiadając na nie tymi samymi wiadomościami wysłanymi na multicast-owy adres 224.0.0.5, zawierającymi wartości LSID struktur LSA Typu drugiego (LSA Type 2). Po ustaleniu brakujących struktur LSA, rutery wymieniają pomiędzy sobą jedynie brakujące dane za pomocą zapytań LSR oraz odpowiedzi LSU, potwierdzanych wiadomościami LSAck.
    Wymiana danych LSDB po elekcji rutera pełniącego role DR-a, BDR-a
    • Status relacji sąsiedztwa względem rutera pełniącego rolę DROther oraz rutera BDR możemy zweryfikować za pomocą komendy [show ip ospf interface interfejs] bądź komendy [show ip ospf neighbor [interfejs]].
      • [show ip ospf interface interfejs] – Wyświetla wartość RID oraz adres IP rutera pełniącego rolę DR-a jak i BDR-a.
      • [show ip ospf neighbor interfejs] – Wyświetla informację o wszystkich sąsiadach podłączonych do danego interfejsu.

    Periodic Flooding

    • Każda struktura LSA posiada własny licznik czasu (Age), który po naliczeniu 30 minut (1800 Sekund) powinien być zresetowany przez urządzenie rozgłaszające daną strukturę LSA. Odpowiedzialny za to ruter po stworzeniu nowej struktury resetuje jej licznik czasu oraz zwiększa jej numer sekwencyjny, rozgłaszając ją do innych urządzeń.
    • Jeżeli w przeciągu czasu „MaxAge” 1 godzina (3600 Sekund), struktura LSA nie zostanie odnowiona przez ruter ją rozgłaszający, zostanie ona usunięta z bazy LSDB, a informacja o tym zdarzeniu zostanie przekazana innym sąsiadom.
    • Aktualną wartość czasu (Age) dla danej struktury, można zweryfikować za pomocą komendy [show ip ospf database].

    Pozostałe tematy związane z protokołem OSPF

    OSPFv3

  • (T) Wiadomości protokołu OSPF*

    (T) Wiadomości protokołu OSPF*

    Wiadomości protokołu OSPF

    • Hello Packet – Umożliwia nawiązanie oraz utrzymanie relacji sąsiedztwa pomiędzy sąsiednimi ruterami.
    • DBD (Database Description Packet) – Zawiera wartości LSID struktur LSA zawartych w bazie LSDB.
    • LSR (Link-State Request Packet) – Umożliwia wysłanie zapytania o brakujące struktury LSA.
    • LSU (Link-State Update Packet) – Zawiera pełne struktury LSA (Stanowią odpowiedź na zapytanie LSR).
    • LSAck (Link-State Acknowledgment) – Potwierdza otrzymanie innych wiadomości protokołu OSPF.

    Budowa pakietu EIGRP

    Budowa pakietu OSPF (Nagłówek protokołu OSPF)

    • Version (1 Byte) – Określa wersja protokołu OSPF (Domyślnie wykorzystywana jest wersja 2).
    • Message Type (1 Byte) – Określa rodzaj przesyłanej wiadomości (1 = Hello, 2 = DBD, 3 = LSR, 4 = LSU, 5 = LSAck).
    • Packet Length (2 Bytes) – Określa wielość przesyłanego pakietu w bajtach.
    • Router ID (4 Bytes) – Określa wartość, określającą unikalny adres ID danego rutera (Zapisywany w postaci DDN).
    • Area ID (4 Bytes) – ID strefy, w której znajduje się dany ruter (Np. Area 5 = 0.0.0.5).
    • Checksum (2 Bytes) – Określa wartość kontrolną protokołu OSPF.
    • Auth Type (2 Bytes) – Określa rodzaj wykorzystywanego uwierzytelnienia wiadomości protokołu OSPF (0 = Brak autentykacji, 1 = Autentykacja z wykorzystaniem zwykłego tekstu, 2 = Autentykacja z wykorzystaniem za-haszowanego klucza).
    • Auth Crypt key (1 Bytes) – Określa numer ID wykorzystywanego klucza.
    • Auth Crypt Data Length (4 Bytes) – Określa wielość przesyłanego klucza w bajtach.
    • Auth Crypt Sequence Number (4 Bytes) – Określa numer sekwencyjny wiadomości.
    • Auth Crypt Data (Wielkość zależna od długości klucza) – Zahaszowana wartość klucza / hasła w postaci zwykłego tekstu.

    Budowa pakietu OSPF (Zawartość wiadomości Hello) Message Type 1

    • Network Mask (4 Bytes) – Maska sieci, w której znajduje się interfejs przesyłający wiadomość.
    • Hello Interval (2 Bytes) – Domyślna bądź statycznie skonfigurowana wartość czasu Hello Interval. Musi być taka sama na obydwóch urządzeniach, aby mogły one nawiązać między sobą relację sąsiedztwa.
    • Router Priority (1 Byte) – Wartość priorytetu wykorzystywanego przy elekcji urządzenia pełniącego rolę DR oraz BDR.
    • Dead Interval (4 Bytes) – Domyślna bądź statycznie skonfigurowana wartość czasu Dead Interval. Musi być taka sama na obydwóch urządzeniach, aby mogły one nawiązać między sobą relację sąsiedztwa.
    • Designated Router (DR) (4 Bytes) – Adres IP rutera pełniącego rolę DR.
    • Backup Designated Router (BDR) (4 Bytes) – Adres IP rutera pełniącego rolę BDR.
    • Active neighbor (4 Bytes) – Wartość, określającą unikalny adres ID jednego z ruterów współdziedziczących sieć wielodostęp-ową (Wartość ta powtarza się tyle razy ile sąsiadów znajduje się w jednej sieci wielodostęp-owej).

    Budowa pakietu OSPF (Zawartość wiadomości DB Descryption) Message Type 2

    • Interface MTU (2 Bytes) – Wartość skonfigurowanej maksymalnej wielości przesyłanego segmentu (MTU).
    • Options (1 Bytes) –
    • BD Descryption (1 Bytes) – Flagi określające rolę pełnioną przez ruter (I = Init, M = More, MS = Master).
    • DD Sequence (4 Bytes) –

    Budowa pakietu OSPF (Zawartość wiadomości LS Request) Message Type 3

    • LS Type (4 Bytes) –
    • Link State ID (4 Bytes) –
    • Advertising Router (4 Bytes) –

    Budowa pakietu OSPF (Zawartość wiadomości LS Update) Message Type 4

    • Number of LSAs (4 Bytes) –
    • LSA-type nn (Wielkość zależna od zawartości) – 
    W zależności od wybranej metody autentykacji część pul może być pusta.

    # Konfiguracja czasów protokołu OSPF została opisana w artykule: Podstawowa konfiguracja protokołu OSPF.

    Wiadomości powitalne Hello

    • Protokół OSPF wykorzystuje wiadomości powitalna (Hello) w celu:
      • Wykrywania sąsiednich ruterów oraz nawiązywania z nimi relacji sąsiedztwa.
      • Utrzymania obustronnej komunikacji pomiędzy sąsiednimi urzadzeniami.
      • Wymiany danych o konfiguracji protokołu OSPF pomiędzy sąsiadami, w celu ustalenia wzajemnej kompatybilności.
      • Wyboru rutera pełniącego rolę DR-a (Designated Router) oraz BDR-a (Backup Designated Router), w sieciach wielodostęp-owych takich jak Frame Relay czy Ethernet (Sieci Point to Point nie wymagają procesu elekcji).
    • Domyślnie wiadomości Hello są wymieniane pomiędzy sąsiadami zgodnie z następującymi przedziałami czasowymi:
      • Hello Interval – Określa odstępy czasowe w wysyłaniu wiadomości Hello. Czas „Hello Interval” wynosi:
        • 10 sekund dla sieci typu Point to Point czy Ethernet.
        • 30 Sekund dla sieci typu NBMA, których pasmo wynosi 1544 Kbps lub mniej.
      • Dead Interval – Określa czas, po upływie którego sąsiedni ruter zostanie uznany za nieosiągalny (W przypadku otrzymania wiadomości hello licznik czasu „Dead Interval” zostaje zresetowany). Czas „Dead Interval” wynosi:
        • 40 sekund dla sieci typu Point to Point czy Ethernet.
        • 120 Sekund dla sieci typu NBMA, których pasmo wynosi 1544 Kbps lub mniej.
    Domyślnie wartość czasu „Dead Interval” stanowi czterokrotność czasu „Hello Interval”.
    • Wiadomości Hello są wysyłane na adresu Multicast 224.0.0.5 dla protokołu IPv4 oraz adres FF02::5 dla protokołu IPv6.
    • Wiadomości Hello zawierają następujące informacje:
      • Wartość RID rutera rozgłaszającego wiadomość Hello.
      • Strefę Area do której należy interfejs z którego została wysłana wiadomość Hello.
      • Adres IP wraz z maską sieci interfejsu z którego została wysłana wiadomość Hello.
      • Informacje związane z autoryzacją interfejsu z którego została wysłana wiadomość Hello.
      • Wartość czasu „Hello Interval”, interfejsu z którego została wysłana wiadomość Hello.
      • Wartość czasu „Dead Interval”, interfejsu z którego została wysłana wiadomość Hello.
      • Priorytet rutera rozgłaszającego wiadomość Hello.
      • Adres IP rutera DR jak i BDR.
      • Pięć flag.
      • Listę wszystkich znanych ruterów (RID).

    Czasy i inne wartości

    • Hello Interval – Określa odstępy czasowe w wysyłaniu wiadomości Hello.
    • Dead Interval – Określa czas, po upływie którego sąsiedni ruter zostanie uznany za nieosiągalny (W przypadku otrzymania wiadomości hello licznik czasu „Dead Interval” zostaje zresetowany).
    • Retransmit Interval – Określa czas retransmisji wiadomości DBD (Gdy ruter nie otrzyma wiadomości Acknowledgment potwierdzającej otrzymanie wiadomości DBD od swojego sąsiada, w przeciągu określonego czasu „retransmit-interval”. Ponowi próbę przekazania wiadomości DBD).
    • Wait Interval – Określa czas wstrzymania przed wyborem rutera pełniącego rolę DR-a (Wartość czasy Wait, jest zawsze równa wartości czasu Dead Interval).

    Pozostałe tematy związane z protokołem OSPF

    OSPFv3

  • (K) Podstawowa konfiguracja protokołu OSPF**

    (K) Podstawowa konfiguracja protokołu OSPF**

    Wstęp teoretyczny do konfiguracji protokołu OSPF

    1. Pierwszym krokiem umożliwiającym konfigurację dynamicznego protokołu routingu, jest stworzenie nowej instancji OSPF za pomocą komendy [router ospf Proces-ID] wydanej w trybie konfiguracji systemu IOS. (W przypadku konfiguracji przełącznika warstwy trzeciej wpierw należy włączyć funkcjonalność routingu za pomocą komendy [ip routing] wydanej w trybie konfiguracji systemu IOS).
    2. Po stworzeniu nowej instancja protokołu OSPF, należy określić jakie sieci będą przez nią rozgłaszane za pomocą komendy [network sieć dzika-maska area ID-strefy]. Po zastosowaniu nie mniejszej komendy router rozpocznie:
      1. Wysyłanie wiadomości powitalnych na określonych przez komendę [network] interfejsach.
      1. Proces dodawania sieci przyległych, określonych przez komendę [network] do bazy topologii.
    3. W celu zlokalizowania interfejsów, na których ma być aktywowany protokół OSPF, router porównuje sieć zawartą w komendzie [network sieć dzika-maska area ID-strefy] z adresami skonfigurowanymi na interfejsach urządzenia. Korzystając przy tym z logiki postępowania list ACL.
    4. Bez względu na kolejność wpisywania komend [network], router przetrzymuje wpisane sieci w konfiguracji urządzenia, zaczynając od tej najbardziej szczegółowej. Np. użycie komendy [network 10.1.12.2 0.0.0.0 area 0] wraz z komendą [network 10.1.0.0 0.0.255.255 area 1] spowoduje, że interfejs z adresem IP 10.1.12.2 będzie należał do strefy
    5. Inną metodą umożliwiającą dodanie sieci do protokołu OSPF jest komenda [ip ospf ASN area ID-strefy] wydana w trybie konfiguracji określonego interfejsu sieciowego.

    Konfiguracja protokołu OSPF

    Rozgłaszanie sieci

    Rozgłaszanie sieci z poziomu konfiguracji protokołu OSPF

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# router-id RID(0-255.0-255.0-255.0-255)

    Określa numer ID (RID) konfigurowanego rutera. Skonfigurowanie statycznej wartości RID, w momencie gdy ruter posiada już aktywne relacje sąsiedztwa, wymaga resetu aktywnych relacji za pomocą komendy [clear ip ospf process].

    (config-router)# network sieć dzika-maska area ID-strefy

    Określa sieć, na podstawie której, ruter decyduje na jakich interfejsach będą rozgłaszane wiadomości „hello” protokołu OSPF. Przykładowa sieć 100.1.1.0/24 skonfigurowana na interfejsie sieciowym za pomocą komendy [ip address 100.1.1.4 255.255.255.0], może być dodana do procesu OSPF w jeden z poniższych sposobów:
    * network 0.0.0.0 0.0.0.0 a 0
    * network 100.0.0.0 0.255.255.255 a 0
    * network 100.1.1.0 0.0.0.255 a 0
    * network 100.1.1.4 0.0.0.0 a 0

    # show ip ospf neighbor

    Wyświetla listę aktywnych sąsiadów protokołu OSPF.

    Rozgłaszanie sieci z poziomu konfiguracji interfejsu sieciowego

    (config)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# ip ospf Proces-IDarea ID-strefy

    Włącza funkcje rozgłaszania wiadomości „hello” protokołu OSPF na danym interfejsie (Jest to nowsza wersja komendy [network]).

    Rozszerzona konfiguracja protokołu OSPF

    Zaawansowana konfiguracja OSPF

    (config)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# ip ospf demand-circuit

    Zaprzestaje wysyłania wiadomości powitalnych (Hello) na konfigurowanym interfejsie sieciowym. Funkcja ta jest stosowana na połączeniach WAN, dla których płatność jest uzależniona od czasu wykorzystania łącza.

    (config-if)# ip ospf flow-reduction

    Blokuje licznik Age, względem rozgłaszanych struktur LSA. Komenda [show ip ospf database] wyświetla pełną bazę LSDB (Struktury LSA z zablokowanym licznikiem będą posiadały oznaczenie [(DNA)]).

    Manipulowanie domyślnymi wartościami czasów OSPF

    # Teoria dotycząca czasów protokołu OSPF została opisana w artykule: Wiadomości protokołu OSPF.

    (config)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# ip ospf hello-interval 1-65535(10)(sekund)

    Zmienia domyślną wartość czasu „Hello-timer” (Ponadto komenda ta automatycznie zmieni wartość czasu „Dead-timer” do czterokrotności nowo skonfigurowanej wartości „Hello-timer”).

    (config-if)# ip ospf dead-interval 1-65535(40)(sekund)

    Zmienia domyślną wartość czasu „Dead-timer” (Zgodnie z zaleceniami Cisco wartość ta powinna stanowić czterokrotność czasu „Hello-timer”).

    (config-if)# ip ospf retransmit-interval 1-65535(5)(sekund)

    Zmienia domyślną wartość czasu „retransmit-interval” (Jest to wartość wykorzystywana w celu retransmisji wiadomości DBD. W sytuacji w której ruter nie otrzyma wiadomości Acknowledgment potwierdzającej otrzymanie wiadomości DBD od swojego sąsiada, w przeciągu określonego czasu „retransmit-interval”. Ponowi próbę przekazania wiadomości DBD).

    (config-if)# ip ospf dead-interval minimal hello-multiplier 3-20(ilość wiadomości na sekundę)

    Jednocześnie zmienia domyślną wartość czasu „Hello-timer” oraz czasu „Dead-timer”.

    # show ip ospf [ASN] interface [interfejs] | include Timer

    Wyświetla informacje na temat skonfigurowanych czasów protokołu OSPF, względem określonego interfejsu bądź wszystkich interfejsów sieciowych.

    Konfiguracja funkcji Load-balance

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# maximum-paths 1-32(4)

    W przypadku istnienia wielu ścieżek o takim samym koszcie, prowadzących do tej samej sieci. Protokół OSPF umożliwia funkcję równomiernego rozprowadzenia ruch pomiędzy czterema drogami. Powyższa komenda umożliwią zmniejszenie bądź zwiększenie tej wartości.

    # show ip protocols

    Wyświetla konfiguracje protokołu OSPF, w tym skonfigurowaną wartość “maximum-paths”.

    Elekcja rutera pełniącego rolę DR oraz BDR

    # Teoria dotycząca elekcji urządzeń DR / BDR została opisana w artykule: Nawiązywanie relacji sąsiedztwa.

    (config)# interface interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.

    (config-if)# ip ospf priority 0-255(1)

    Określa priorytet rutera biorącego udział elekcji roli DR/BDR. W przypadku skonfigurowania wartości „0” ruter nigdy nie zostanie wybrany DR-em lub BDR-em.

    # show ip ospf interface [interfejs] | include Priority

    Wyświetla informacje na temat skonfigurowanej wartości priorytetu OSPF, względem określonego interfejsu bądź wszystkich interfejsów sieciowych.

    Wyłączenie procesu OSPF

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# shutdown

    Włącza proces OSPF powodując tym samym:
    * Zamknięcie wszystkich relacji sąsiedztwa.
    * Wstrzymanie procesu nawiązywania nowych relacji sąsiedztwa.
    * Zatrzymanie procesu wysyłania wiadomości Hello. 
    wyłączenie procesu OSPF nie usuwa konfiguracji danego procesu z pliku konfiguracyjnego urządzenia.

    Wiadomości systemowe (Logging) protokołu OSPF

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# log-adjacency-changes detail

    Wysyła wiadomość systemową w przypadku zmiany statusu relacji sąsiedztwa.

    Zmiana domyślnej wartość AD (Administrative Distance)

    (config)# router ospf Proces-ID

    Przechodzi do poziomu konfiguracji protokołu OSPF.

    (config-router)# distance 1-255(110)

    Zmienia domyślną wartość AD, względem konfigurowanej instancji protokołu OSPF.

    (config-router)# distance ospf external 1-255(110)

    Zmienia domyślną wartość AD względem tras zewnętrznych (External), konfigurowanego protokołu OSPF.

    (config-router)# distance ospf intra-area 1-255(110)

    Zmienia domyślną wartość AD względem tras wewnętrznych (Intra), konfigurowanego protokołu OSPF.

    (config-router)# distance ospf inter-area 1-255(110)

    Zmienia domyślną wartość AD względem tras między-strefowych (Inter), konfigurowanego protokołu OSPF.

    # show ip protocols

    Wyświetla konfiguracje protokołu OSPF, w tym skonfigurowaną wartość AD.

    Pozostałe tematy związane z konfiguracją protokołu OSPF

    OSPFv3

  • (KP) Multipoint Frame Relay

    (KP) Multipoint Frame Relay

    Konfiguracja przykładowa

    Topologia sieci

    Multipoint Frame Relay

    Konfiguracja rutera ISP1

    ISP1(config)# frame-relay switching


    ISP1(config)#     interface serial0/0
    ISP1(config-if)#     encapsulation frame-relay
    ISP1(config-if)#     frame-relay lmi-type cisco
    ISP1(config-if)#     frame-relay intf-type dce
    ISP1(config-if)#     frame-relay route 201 interface serial0/1 101
    ISP1(config-if)#     frame-relay route 202 interface serial0/2 102
    ISP1(config-if)#     frame-relay route 203 interface serial0/3 103


    ISP1(config-if)#     interface serial0/1
    ISP1(config-if)#     encapsulation frame-relay
    ISP1(config-if)#     frame-relay lmi-type cisco
    ISP1(config-if)#     frame-relay intf-type dce
    ISP1(config-if)#     frame-relay route 101 interface serial0/0 201


    ISP1(config-if)#     interface serial0/2
    ISP1(config-if)#     encapsulation frame-relay
    ISP1(config-if)#     frame-relay lmi-type cisco
    ISP1(config-if)#     frame-relay intf-type dce
    ISP1(config-if)#     frame-relay route 102 interface serial0/0 202


    ISP1(config-if)#     interface serial0/3
    ISP1(config-if)#     encapsulation frame-relay
    ISP1(config-if)#     frame-relay lmi-type cisco
    ISP1(config-if)#     frame-relay intf-type dce
    ISP1(config-if)#     frame-relay route 103 interface serial0/0 203

    Konfiguracja rutera RW1

    RW1(config)# interface serial0/0
    RW1(config-if)#     encapsulation frame-relay
    RW1(config-if)#     frame-relay lmi-type cisco


    RW1(config-if)#     interface serial0/0.101 point-to-point
    RW1(config-if)#     ip address 10.1.1.1 255.255.255.0
    RW1(config-if)#     frame-relay interface-dlci 101

    Konfiguracja rutera RW2

    RW2(config)# interface serial0/0
    RW2(config-if)#     encapsulation frame-relay
    RW2(config-if)#     frame-relay lmi-type cisco


    RW2(config-if)#     interface serial0/0.102 point-to-point
    RW2(config-if)#     ip address 10.1.1.2 255.255.255.0
    RW2(config-if)#     frame-relay interface-dlci 102

    Konfiguracja rutera RW3

    RW3(config)# interface serial0/0
    RW3(config-if)#     encapsulation frame-relay
    RW3(config-if)#     frame-relay lmi-type cisco


    RW3(config-if)#     interface serial0/0.103 point-to-point
    RW3(config-if)#     ip address 10.1.1.3 255.255.255.0
    RW3(config-if)#     frame-relay interface-dlci 103

    Konfiguracja rutera HQ

    HQ(config)# interface serial0/0
    HQ(config-if)#     encapsulation frame-relay
    HQ(config-if)#     frame-relay lmi-type cisco


    HQ(config-if)#     interface serial0/0.1 multipoint
    HQ(config-if)#     ip address 10.1.1.10 255.255.255.0
    HQ(config-if)#     frame-relay map ip 10.1.1.1 201 broadcast
    HQ(config-if)#     frame-relay map ip 10.1.1.2 202 broadcast
    HQ(config-if)#     frame-relay map ip 10.1.1.3 203 broadcast

    Test końcowy

    HQ# ping 10.1.1.1
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/8/28 ms
    HQ# ping 10.1.1.2
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
    HQ# ping 10.1.1.3
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/16 ms

    Full Multipoint Frame Relay

  • (K) Point to Point Protocol*

    (K) Point to Point Protocol*

    Konfiguracja protokołu HDLC

    W starszy wersjach systemu IOS komenda [clock rate] nie została domyślnie aktywowana, tym samym połączenie serialowe nie zostanie nawiązane dopóki administrator jej nie skonfiguruje.

    (config)# interface serial interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.

    (config)# ip address sieć maska

    Przypisuje adres IP do konfigurowanego interfejsu serialowego.

    (config-if)# clock rate 300-8000000(Wspiera wartości podzielne przez 1200)

    Określa przepustowość łącza serialowego (Komenda jest możliwa do wykonania jedynie na ruterze podłączonym przez kabel serialowy z końcówką DCE).

    (config-if)# encapsulation hdlc

    Protokół HDLC jest domyślnie wykorzystywanym protokołem PPP w systemie Cisco IOS, dlatego jego aktywacja nie jest konieczna w większości przypadków.

    (config-if)# [no] shutdown

    Aktywuje / Dezaktywuje konfigurowany interfejs serialowy.

    (config-if)# bandwidth 1-10000000(Kilobity na sekundę)*

    Określa przepustowość łącza w celu informacyjnym dla protokołów routingu dynamicznego czy protokołu QoS.

    (config-if)# description opis-interfejsu*

    Dodaje opis interfejsu w celach informacyjnych.

    (config-if)# [no] keepalive*

    Wyłącza / Włącza funkcję Keepalive.

    Konfiguracja protokołu PPP

    Protokół PPP do funkcjonowania nie wymaga adresu IP.
    W starszy wersjach systemu IOS komenda [clock rate] nie jest domyślnie skonfigurowana, tym samym połączenie serialowe nie zostanie nawiązane dopóki administrator jej nie użyje.

    Konfiguracja PPP

    (config)# interface serial interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.

    (config)# ip address sieć maska

    Przypisuje adres IP do konfigurowanego interfejsu serialowego.

    (config-if)# clock rate 300-8000000(Wspiera wartości podzielne przez 1200)

    Określa przepustowość łącza serialowego (Komenda jest możliwa do wykonania jedynie na ruterze podłączonym przez kabel serialowy z końcówką DCE).

    (config-if)# encapsulation ppp

    Zmienia domyślną metodę enkapsulacji interfejsu serialowego na protokół PPP.

    (config-if)# [no] shutdown

    Aktywuje / Dezaktywuje konfigurowany interfejs serialowy.

    (config-if)# bandwidth 1-10000000(Kilobity na sekundę)*

    Określa przepustowość łącza w celu informacyjnym dla protokołów routingu dynamicznego czy protokołu QoS.

    (config-if)# description opis-interfejsu*

    Dodaje opis interfejsu w celach informacyjnych.

    (config-if)# [no] keepalive*

    Wyłącza / Włącza funkcję Keepalive.

    Uwierzytelnianie protokołu PPP

    Uwierzytelnianie PPP (CHAP)

    (config)# hostname nazwa

    Określa nazwę lokalnego urządzenia (Hostname).

    (config)# username hostname(Hostname sąsiada) password hasło

    Tworzy nowego użytkownika którego login odpowiada nazwie (Hostname) sąsiedniego urządzenia, natomiast hasło jest współdzielone.

    (config)# interface serial interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.

    (config-if)# encapsulation ppp

    Zmienia domyślną metodę enkapsulacji interfejsu serialowego na PPP.

    (config-if)# ppp authentication chap

    Aktywuje uwierzytelnianie protokołu PPP za pomocą protokołu CHAP.

    Proces troubleshooting-u protokołu PPP został opisany w artykule: Troubleshooting protokołu PPP. 

    Jeżeli proces uwierzytelniania się nie powiedzie, status interfejsu będzie widoczny jako „Down State”. Natomiast wydruk komendy [show interface interfejs] będzie pozbawiony opcji „LCP Open”.

    Uwierzytelnianie PPP (PAP)

    (config)# hostname nazwa

    Określa nazwę lokalnego urządzenia (Hostname).

    (config)# username hostname(Hostname sąsiada) password hasło(Hasło sąsiada)

    Tworzy nowego użytkownika którego zarówno login jak i hasło odpowiada konfiguracji sąsiedniego urządzenia.

    (config)# interface serial interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.

    (config-if)# encapsulation ppp

    Zmienia domyślną metodę enkapsulacji interfejsu serialowego na PPP.

    (config-if)# ppp authentication pap

    Aktywuje autentykację protokołu PPP za pomocą protokołu PAP.

    (config-if)# ppp pap sent-username hostname(Hostname lokalne) password hasło(Hasło lokalne)

    Wysyła dane służące do uwierzytelnienia z sąsiednim urządzeniem.

    # Proces troubleshooting-u protokołu PPP został opisany w artykule: Troubleshooting protokołu PPP. 

    Jeżeli proces uwierzytelniania się nie powiedzie, status interfejsu będzie widoczny jako „Down State”. Natomiast wydruk komendy [show interface interfejs] będzie pozbawiony opcji „LCP Open”.

    Komendy SHOW oraz DEBUG

    Komendy SHOW

    # show controllers interfejs

    Wyświetla szczegółowe informacje dotyczące określonego w komendzie interfejsu serialowego (W tym ustawienia DCE, DTE czy skonfigurowane pasmo (Clock rate)).

    # show interface serial interfejs

    Wyświetla informacje o ustawieniach interfejsu w tym: skonfigurowane pasmo, protokół warstwy drugiej (HDLC, PPP), adres IP oraz status protokołów LCP i NCP.

    # show ip interface brief

    Wyświetla podstawowe informacje dotyczące statusu oraz konfiguracji adresacji IP względem wszystkich interfejsów (Zarówno fizycznych jak i wirtualnych).

    # show interface description

    Wyświetla podstawowe informacje dotyczące stanu wszystkich interfejsów sieciowych, wraz z przypisanym opisem [description opis-interfejsu].

    # show ppp all

    Wyświetla status połączeń PPP, wraz z informacjami o stanie (+, -, *) używanych protokołów.

    Komendy DEBUG

    # debug ppp authentication

    Debaguje wymianę wiadomości uwierzytelniających CHAP, PAP, MSCHAP oraz EAP.

    # debug ppp negotiation

    Debaguje proces negocjowania połączenia PPP.

    Pozostałe tematy związane z protokołem PPP oraz PPPoE

  • (Ts) Point to Point Protocol*

    (Ts) Point to Point Protocol*

    Podstawowe informacje o statusie interfejsu serialowego

    • Podstawowa komenda weryfikująca osiągalność warstwy trzeciej [ping], umożliwia szubką weryfikację połączenia serialowego.
      • Jeżeli komenda ping się nie powiedzie, należy sprawdzić status interfejsu serialowego [show ip interface brief].
      • Jeżeli komenda ping się powiedzie, należy sprawdzić status danej sieci w tablicy routingu.
    Line Status Protocol Status Likely General Reason / Layer
    Administratively down Down Interface Shutdown
    Down Down Layer 1
    Up Down Layer 2
    Up Up Layer 3

    Status interfejsu serialowego, a warstwa modelu OSI/ISO

    Troubleshooting Warstwy pierwszej modelu OSI

    • Status interfejsów serialowych na obydwóch końcach połączenia, może się od siebie różnić. Np. w sytuacji w której jedno z urządzeń wyłączy interfejs komendą [shutdown] a drugie będzie w stanie (down/down). Dlatego weryfikując połączenie PPP należy sprawdzi status połączenia na obydwóch końcach przewodu serialowego.

    Troubleshooting Warstwy drugiej modelu OSI

    Line Status Protocol Status Likely General Reason / Layer
    Up Down on both ends (Flaping Up / Down) Mismatch „encapsulation” comands.
    Up Down on one ends, Up on the other Keepalive disabled on the end in an up state when using HDLC
    Up Down on both ends PAP / CHAP authentication failure

    Status interfejsu serialowego, dla warstwy drugiej modelu OSI/ISO

    Problemy związane z funkcją Keepalive

    • Funkcja Keepalive umożliwia śledzenie statusu interfejsu sieciowego, dzięki czemu w przypadku wykrycia przerwania połączenia serialowego, interfejs automatycznie przejdzie w stan (down). Funkcja Keepalive wysyła wiadomości utrzymujące kontakt pomiędzy sąsiadami w 10 sekundowych odstępach, jednocześnie oczekując na nie odpowiedzi. W przypadku nieotrzymania tak owej, przez okres od 30 do 50 sekund, ruter uzna że sąsiednie urządzenie nie jest już dostępne a tym samym przeniesie je w stan (down).
    • Problem z funkcją Keepalive Failure występuje, kiedy jedno z urządzeń ją wyłączy a drugie nie. W takim przypadku urządzenie które dezaktywowało funkcję Keepalive będzie posiadać status up/down. Aby sprawdzić status funkcji Keepalive, należy wykorzystać komendę [show interface]. (Problem ten nie dotyczy protokołu PPP a jedynie protokołu HDLC).

    Problemy związane z uwierzytelnianiem

    • Statusu (up/down) na interfejsie serialowym, oznacza że ruter może mieć problemy z uwierzytelnianiem protokołu PAP/CHAP, aby to zweryfikować należy wykorzystać komendę [show interface], [show ppp all] bądź też sprawdzić wydruk debugowania procesu uwierzytelniania za pomocą komendy [debug ppp authentication].
    • Protokół CHAP wykorzystuje trzy rodzaje wiadomości, aby je wyświetlić należy włączyć proces debugowania a następnie zresetować interfejs komendą [shutdown] oraz [no shutdown]. Rodzaje wiadomości protokołu CHAP są następujące:
      • CHALLENGE – Urządzenie uwierzytelniające inicjuje proces uwierzytelniania obydwóch urządzeń.
      • RESPONSE – Urządzenie uwierzytelniane wysyła odpowiedź zawierającą login wraz z hasłem.
      • FAILURE – Urządzenie uwierzytelniające informuje o niepowodzeniu procesu uwierzytelniania.

    Troubleshooting Warstwy trzeciej modelu OSI

    • Status (Up/Up) interfejsu serialowego, nie gwarantuje że działa on prawidłowo, może zdarzyć się że pomimo statusu (Up/Up) komenda [ping] zawiedzie, wskazując na problemy związane z błędną konfiguracją warstwy trzeciej.

    Pozostałe tematy związane z protokołem PPP oraz PPPoE

  • (T) Point to Point Protocol*

    (T) Point to Point Protocol*

    Wstęp do linii dzierżawionej

    Wstęp do linii dzierżawionej

    • Linia dzierżawiona (Leased Line) funkcjonuje na zasadzie wstępnie zestawionego łącza pomiędzy dwoma punktami, zapewniając stabilną oraz bezpieczną komunikację. W swoim działaniu stanowi przeciwieństwo linii komutowanej, której zestawienie odbywa się przed rozpoczęciem przesyłu, aby po zakończeniu transferu zakończyć połączenie, umożliwiając tym samym wymianę danych innym użytkownikom sieci. W początkowym okresie istnienia linia dzierżawiona stanowiła jeden fizyczny kabel łączący dwa urządzenia, jednak obecnie dzięki rozwojowi technologii powstały nowe linie wirtualne, tworzące logiczne kanały pomiędzy stronami przy zachowaniu zalety pierwotnej fizycznej wersji. Połączenia dzierżawione korzystają z łącza o miedzianym lub światłowodowym medium transmisji, wydzierżawionym od dostawcy usług Internetowych lub osoby indywidualnej. Dane przesyłane są za pomocą jednego z dwóch protokołów, PPP (Point to Point Protocol) bądź też HDLC (High-level Data Link Control) umożliwiając obopólną łączność z opcjonalnym uwierzytelnianiem obydwóch stron komunikacji.
    Typ Linii Pasmo w bitach
    T1 1.544 Mb/s
    E1 2.048 Mb/s
    E3 34.368 Mb/s
    CC-1 51.84 Mb/s
    OC-48 4.488 Gb/s
    OC-768 39.813 Gb/s

    Rodzaje linii dzierżawionych z wartością pasma

    Podstawowe pojęcia dotyczące linii dzierżawionej oraz interfejsu serialowego

    • Linia dzierżawiona „Leased Line” zapewnia łączność pomiędzy urządzeniami na poziomie warstwy pierwszej modelu OSI. Jest odpowiedzialna za przesyłanie bitów pomiędzy dwoma punktami oddalonymi nawet o setki kilometrów.
    • Linia dzierżawiona nie definiuje jaki protokołu warstwy drugiej zostanie użyty do transmisji danych.
    • Interfejs serialowy składa się z dwóch niezależnych oraz niepołączonych ze sobą elementów (TX oraz RX). TX służy do nadawania ruchu sieciowego, natomiast RX do jego odbierania. Tym samym ruch sieciowy kierowany na adres IP przypisany do lokalnego interfejsu serialowego, musi być najpierw wysłany do sąsiedniego rutera skąd będzie przekierowany z powrotem. Jako że mapowanie określa jedynie adres sąsiedniego urządzenia, ruter nie wie gdzie wysłać ruch kierowany do siebie samego.
      • Aby uzyskać możliwość ping-owania na własny adres IP interfejsu serialowego, należy skonfigurować dodatkowe mapowanie za pomocą komendy [frame-relay map ip adres-IP(IP lokalnego urządzenia) 16-1007(DLCI lokalne)] wydanej w trybie konfiguracji interfejsu serialowego.

    High-Level Data Link Control

    • HDLC zapewnia łączność na poziomie warstwy drugiej, określając format ramki zwierającej dane kontrolne FCS czy bit kontroli (Control byte). W przypadku urządzeń Cisco, ramka HDLC posiada dodatkową wartość (Type) określającą przesyłany protokół wyższej warstwy (NP. IPv4 bądź też IPv6). Pełna ramka HDLC wygląda następująco:
    1 bytes 1 bytes 1 byte 2 bytes Variable 2 bytes
    Flag Address Control Type (Only Cisco) Data FCS

    Budowa nagłówka protokołu HDLC

    Protokół HDLC powstał w czasach w których nie istniały jeszcze rutery, dlatego nie posiada on wielu funkcji zawartych w nowszym protokole PPP.

    Point to Point Protocol

    #  Konfiguracja protokołu PPP została opisana w artykule: Konfiguracja PPP.

    Podstawowe pojęcia dotyczące protokołu PPP

    • Protokół PPP powstał w latach 90 ubiegłego wieku, tym samym jest młodszy od swojego poprzednika HDLC. Zawiera wiele udoskonaleń takich jak autentykację, kompresję czy możliwość tworzenia mulit-linków.
    • Protokół PPP posiada następujące cechy oraz funkcje:
      • Definiuje nagłówek warstwy drugiej, dzięki czemu jest w stanie przesyłać dane poprzez połączenia serialowe.
      • Wspiera zarówno połączenia synchroniczne jak i asynchroniczne (Synchronous and Asynchronous).
      • Posiada wbudowane pole „Type” tym samym może wspierać różne protokoły warstwy trzeciej.
      • Posiada wbudowane mechanizmy autentykacji użytkowników, takie jak protokół: PAP (Password Authentication Protocol) czy CHAP (Challenge Handshake Authentication Protocol).

    Bodowa protokołu PPP

    Protokół PPP do funkcjonowania nie wymaga adresu IP.
    • Protokół PPP składa się z trzech warstw:
      • Pierwszej opartej na protokole HDLC (High-Level Data Link Control), wykorzystywanym do enkapsulacji połączenia PPP (Obecnie wykorzystywaną przez Cisco wersją protokołu HDLC jest protokół cHDLC).
      • Drugiej wykorzystującej protokół LCP (Link Control Protocol), przeznaczony do obsługiwania warstwy drugiej.
      • Trzeciej wykorzystującej protokół NCP (Network Control Protocol), odpowiedzialny z integracje z innymi protokołami warstw wyższych (Np. IPv4 czy IPv6).
    • LCP (Link Control Protocol) – Testuje, konfiguruje oraz nawiązuje połączenie protokołu PPP. W pierwszym etapie przed nawiązaniem komunikacji, urządzenia wysyłają wiadomości LCP w celu zbadania tożsamości sąsiedniego rutera a tym samym sprawdzenia czy mogą one nawiązać ze sobą połączenie. Proces weryfikacji wiadomości LCP dotyczy ustawień limitów związanych z dopuszczalną wielkością pakietu czy występujących w nim błędów. Po zaakceptowaniu odebranej wiadomości LCP połączenie PPP może być nawiązane.
    • NCP (Network Control Protocol) – Umożliwia integrację protokołu PPP z innymi protokołami tworząc instancje PPP Control Protocol (CP), takie jak: IPCP dla protokołu IPv4, IPv6CP dla protokołu IPv6 czy CDPCP dla protokołu CDP.
    1 bytes 1 bytes 1 bytes 2 bytes Variable 2 bytes
    Flag Address Control Type Data FCS

    Budowa nagłówka protokołu PPP

    Funkcje protokołu PPP

    • Loop Link Detection (Magic Number) – Umożliwia wykrycie oraz zapobiega powstawaniu pętli sieciowych. Każdy z uczestników komunikacji systematycznie wysyła unikalną liczbę, jeśli odebrana ramka PPP będzie zawierała taką samą wartość, oznaczać to będzie że w sieci istnieje pętla sieciowa.
    • Error Detection (Link-Quality Monitoring LQM) – Blokuje interfejs, który przekroczył próg błędnie nadanych ramek, co umożliwia znalezienie lepszej jak i mniej awaryjnej drogi prowadzącej do celu.
    • Multilink Support (Multilink PPP) – Umożliwia równomierne obciążenie ruchu PPP na wielu interfejsach serialowych.
    • Authentication (PAP and CHAP) – Uwierzytelnia strony komunikacji za pomocą loginu jak i hasła użytkownika.

    Uwierzytelnianie protokołu PPP

    Uwierzytelnianie protokołu PPP – PAP

    • Protokół PAP umożliwia obopólne uwierzytelnianie stron komunikacji, za pomocą hasła wysyłanego w postaci czystego tekstu (Plain text), tym samym jest to protokół znacznie mniej bezpieczny od protokół CHAP.
    • Protokół PAP wysyła nazwę użytkownika w procesie uwierzytelniania.
    • Proces nawiązywania komunikacji połączenia PPP z włączonym uwierzytelnianiem PAP wygląda następująco:
      • Urządzenie pierwsze (Uwierzytelniane) wysyła swój login wraz z hasłem.
      • Urządzenie drugie (Uwierzytelniające) potwierdza otrzymanie danych, akceptując lub odrzucając połączenie.
    Protokół PAP może być wykorzystywany do autentykacji użytkowników końcowych PPP, z użyciem serwera TACACS+.

    Uwierzytelnianie protokołu PPP – CHAP

    • Protokół CHAP w celu autentykacji stron komunikacji wykorzystuje hasło haszowane algorytmem MD5.
    • Proces nawiązywania komunikacji połączenia PPP z włączonym uwierzytelnianiem PAP wygląda następująco:
      • Urządzenie pierwsze (Uwierzytelniające) wysyła wiadomość „Challenge” z prośbą o odpowiedź drugiej strony.
      • Urządzenie drugie (Uwierzytelniane) wysyła swój login wraz z hasłem zahaszowanym algorytmem MD5.
      • Urządzenie pierwsze (Uwierzytelniające) potwierdza otrzymanie danych, akceptując lub odrzucając połączenie.
    • MSCHAPv2  – Umożliwia zmianę przedawnionego hasła oraz wzajemną autentykację urządzeń.
    Po nadaniu wiadomości „Challenge”, urządzenie uwierzytelniające generuje a następnie wysyła losową liczbę. Po odebraniu wiadomości urządzenie uwierzytelniane odsyła zahaszowane hasło wraz z odebraną liczbą.

    Porównanie protokołu PAP do CHAP

    • Protokół CHAP:
      • Generuje unikalną wartość String, względem każdej transmisji.
      • Wspiera ponowne uwierzytelnianie.
    • Protokół PAP:
      • Zapewnia minimalny poziom bezpieczeństwa.
      • Wymaga jedynie loginu oraz hasła.

    Multilink PPP (MLPPP)

    • Protokół MLPPP może być wykorzystany w celu zapewnienia redundancji jak i równomiernego obciążenia ruchu sieciowego, pomiędzy wieloma interfejsami serialowymi.
    • Protokół MLPPP agreguje (Scala) dwa lub więcej interfejsów serialowych na poziomie warstwy drugiej. Automatycznie tworząc nowy wirtualny interfejs, do którego przypisana zostaje konfiguracja warstwy trzeciej. Tym samym względem warstwy drugiej istnieją dwa niezależna połączenia, natomiast względem warstwy trzeciej istnieje tylko jeden link.
    • Na poziomie warstwy drugiej protokół MLPPP dzieli ramkę na części, w ilości aktywnych interfejsów serialowych, należących do jednej grupy. A następnie przesyła podzielone dane, oznaczając je specjalnym nagłówkiem protokołu PPP.

    Pozostałe tematy związane z protokołem PPP oraz PPPoE