Konfiguracja interfejsu serialowego musi być taka sama na każdym interfejsie fizycznym, należącym do tego samego połączenia wirtualnego Multilink.
Numer identyfikacyjny grupy „ppp multilink group” oraz numer interfejsu „interface multilink” musi być taki sam na obydwóch urządzeniach.
Komendy SHOW oraz DEBUG
Komendy SHOW
Komendy show PPP
#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 show MLPPP
#show interface multilink 1-2147483647(ID grupy)
Wyświetla informacje związane o wskazanym w komendzie interfejsie wirtualnym.
#show ppp multilink
Wyświetla informacje o konfiguracji wszystkich wirtualnych interfejsów serialowych (Wskazując interfejsy serialowe należące do jednej grupy „Multilink”).
Komendy DEBUG
#debug ppp authentication
Debaguje wymianę wiadomości uwierzytelniających CHAP, PAP, MSCHAP oraz EAP.
Określa jaki protokół będzie wykorzystywany w celu testowania dostępności drugiej strony połączenia (Protokoły te działają jak wiadomość Keepalive w warstwie drugiej).
(config-if)#interface serial interfejs.pod-interfejs multipoint
Przechodzi do poziomu konfiguracji pod-interfejsu.
(config-subif)# ip address adres-IP
Przypisuje adres IP, do konfigurowanego pod-interfejsu serialowego.
(config-subif)#bandwidth 1-10000000(Kilobity na sekundę)*
Określa przepustowość łącza w celu informacyjnym dla protokołów routingu dynamicznego czy protokołu QoS.
(config-subif)#frame-relay map ip adres-IP(IP sąsiedniego urządzenia)16-1007(DLCI lokalne)[broadcast]
Mapuje lokalny interfejs serialowy z drugą stroną połączenia Frame Relay. Opcjonalna komenda „broadcast” umożliwia obsługą protokołów routingu dynamicznego. Komendę należy powtórzyć względem każdego oddziału zdalnego.
(config-subif)#interface serial interfejs
Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.
Określa jaki protokół będzie wykorzystywany w celu testowania dostępności drugiej strony połączenia (Protokoły te działają jak wiadomość Keepalive w warstwie drugiej).
(config-if)#interface serial interfejs.pod-interfejs point-to-point
Przechodzi do poziomu konfiguracji pod-interfejsu.
(config-subif)# ip address adres-IP
Przypisuje adres IP, do konfigurowanego pod-interfejsu serialowego.
(config-subif)#bandwidth 1-10000000(Kilobity na sekundę)*
Określa przepustowość łącza w celu informacyjnym dla protokołów routingu dynamicznego czy protokołu QoS.
(DIALER I) Konfiguracja dla warstwy trzeciej modelu OSI
(config)#interface dialer dial-pool-number
Przechodzi do konfiguracji interfejsu wirtualnego „Dialer”.
(config-if)#ip address negotiated
Umożliwia dynamiczne przypisanie adresu IP (Zgodnie z wolą dostawcy ISP).
(config-if)#mtu 1492
Ogranicza dopuszczalną (maksymalną) wielkość ramki Ethernetowej, dzięki czemu łączna wielkość przenoszonej zawartości użytecznej, wraz z nagłówkiem protokołu PPPoE oraz nagłówkiem innych warstw, nie przekroczy domyślnej wartości 1500 bajtów (Wartość 1492 jest rekomendowana przez Cisco).
(DIALER II) Konfiguracja dla warstwy pierwszej modelu OSI
(config-if)#dialer pool ID-puli
Łączy interfejs wirtualny „Dialer” z interfejsem fizycznym.
(DIALER III) Konfiguracja dla warstwy drugiej modelu OSI
(config-if)#encapsulation ppp
Zmienia domyślną metodę enkapsulacji (HDLC) interfejsu serialowego na protokół PPP.
(config-if)#ppp chap hostname login
Określa login klienta protokołu PPPoE.
(config-if)#ppp chap password hasło
Określa hasło klienta protokołu PPPoE.
Konfiguracja interfejsu fizycznego
(config)#interface interfejs
Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.
(config-if)#no ip address*
Wyłącza funkcję warstwy trzeciej na konfigurowanym interfejsie sieciowym.
(config-if)#pppoe-client dial-pool-number ID-puli
Łączy interfejs fizyczny z interfejsem wirtualnym „Dialer”.
(config-if)#ppp enable
Komenda ta jest automatycznie wpisywana podczas konfiguracji klienta PPP.
Wymusza na połączeniu PPPoE utrzymywanie ciągłej sesji, pomimo braku ruchu sieciowego. * delay – Określa czas jaki urządzenie sieciowe będzie oczekiwać, zanim ponowi próbę nawiązania połączenia PPPoE. * delay initial – Określa czas jaki urządzenie sieciowe będzie oczekiwać, przed próbą nawiązania pierwszego połączenia PPPoE. * max-attempts – Określa ilość prób wznowienia połączenia PPPoE.
Określa czas po jakim połączenie PPPoE zostanie zakończone, w przypadku braku ruchu sieciowego (Po użyciu komendy [dialer persistent] wartość Idle-timeout nie będzie brana pod uwagę).
(config-if)#interface interfejs
Przechodzi do poziomu konfiguracji określonego interfejsu sieciowego.
(config-if)#pppoe-client ppp-max-payload 64-1492
Wysyła tagowanie „ppp-max-payload” w pakiecie kontrolnym.
Komendy Show, Clear, Debug
Komendy SHOW
#show pppoe session
Wyświetla informacje o stanie połączenia PPPoE, wskazuje powiązane ze sobą interfejsy (3).
#show interfaces dialerdial-pool-number
Wyświetla informacje o interfejsie wirtualnym „Dialer” wraz z przypisanym do niego interfejsem fizycznym.
#show ip interfaces brief dialer dial-pool-number
Wyświetla skrócone informacje o interfejsie „Dialer”.
W czasie istnienia sesji protokołu PPPoE, interfejs wirtualny „Dialer Interfejs” jest związany z interfejsem „Virtual Access Interface”. Komenda [show interfaces dialer ID] wyświetla informacje o obydwóch interfejsach wirtualnych.
Każdy interfejs posiada oddzielny opis wskazujący obopólne przywiązanie.
Interfejs „Dialer Interfejs” skupia się na warstwie trzeciej modelu OSI. Protokół LCPjest na nim nieaktywny(Closed).
Interfejs „Virtual Access Interface” skupia się na warstwie drugiejmodelu OSI. Protokół LCPjest na nim aktywny(Open), ale nie posiada przypisanego adresu IP.
Szczegółowy opis komendy [show interfaces dialer ID]:
Line protocol is up (Spoofing)– Określa status interfejsu „Dialer”, wartość „Spoofing” odnosi się do faktu że warstwa druga jest obsługiwana przez inny interfejs, w tym przypadku jest to „Virtual Access Interface”.
Istnieje możliwość wyświetlenia informacji o interfejsie „Virtual Access Interface”, za pomocą komendy [show interfaces virtual-access ID].
Komenda SHOW interfaces virtual-access ID
configuration
Komenda [show interfaces virtual-access ID configuration] wyświetla konfiguracje interfejsu „Virtual Access Interface”, a dane w niej zawarte są częściowo pobierane z ustawień interfejsu „Dialer”.
Interfejs „Virtual Access Interface” pobiera informacje o ustawieniach wartości MTU oraz danych autoryzacyjnych klienta PPPoE.
Proces Troubleshooting-u
Przed rozpoczęciem Troubleshooting-u:
Po wykorzystaniu komendy [no ip address] na interfejsie wirtualnym „Dialer” , interfejs ten będzie widniał jako „line protocol is up (Spoofing)”. Jednak sesja PPPoE nie będzie aktywna co potwierdzi wydruk komendy [show ppp sessions].
Status po konfiguracji warstwy pierwszej:
Po wykorzystaniu komendy [dialer pool ID] na interfejsie wirtualnym „Dialer” oraz komendy [pppoe-client dial-pool-number ID / pppoe enabled] względem interfejsu fizycznego (Ethernet), sesja PPPoE zmieni swój tryb pracy na PADISNT. Ponadto w wydruku komendy [show ppp sessions] brakować będzie adresów MAC oraz interfejsu „Virtual Access Interface”.
Status po konfiguracji warstwy drugiej(PPP) :
Po dodaniu obsługi protokołu PPP za pomocą komendy [encapsulation ppp] oraz skonfigurowaniu loginu jak i hasła, w wydruku komendy [show ppp sessions] zaczną widnieć dane brakujące w poprzednim punkcje.
Status po konfiguracji warstwy trzeciej(IP) :
Ostatnim krokiem jest konfiguracja warstwy trzeciej modelu OSI, czyli adresów IP.
Podsumowanie:
Warstwa 1 [show pppoe session interface interfejs] – Komenda ta umożliwia przeanalizowanie współpracujących ze sobą interfejsów (3), ich numerów ID oraz statusu pracy.
Warstwa 2 [show pppoe session interfaceinterfejs] – Jeżeli komenda nie wyświetli informacji o interfejsie „Virtual Access Interface”, może oznaczać to błąd konfiguracji warstwy drugiej bądź błąd autentykacji protokołu CHAP.
Warstwa 2 [show interfaces dialer ID].
Warstwa 3[show interfacesinterfejs / show ip interface brief].
Aby uzyskać pewność, że wszystko działa poprawnie należy wykonać trzy kroki:
Sprawdzić czy status sesji ma wartość (Up).
Sprawdzić czy wszystkie trzy interfejsy są wyświetlone.
Sprawdzićvgb adresy MAC.
Komenda [show interfaces dialer 2] wyświetla komunikat „line protocol is up (Spoofing)” niezależnie od tego czy PPPoE działa czy nie, dlatego nie należy zawracać uwagi na status (Up).
Interfejs fizyczny (Ethernet) nie powinien mieć przypisanego adresu IP.
Pozostałe tematy związane z protokołem PPP oraz PPPoE
Protokół PPP powstał z myślą o połączeniach serialowych, jednak jego cechy takie jak uwierzytelnianie użytkowników końcowych (klientów), spowodowały jego propagację na inne media takie jak Ethernet czy sieci ATM.
Protokół PPPoE nawiązuje sesją PPP pomiędzy ruterami z wykorzystaniem adresacji IP, jednak wysyłane pakiety są enkapsulowane nagłówkami Ethernet-owymi (Co oznacza że protokół PPPoE działa jedynie w warstwie drugiej, pozostawiając warstwę trzecią w gestii protokołu PPP).
Uwierzytelnianie użytkowników protokołu PPPoE, działa jedno-kierunkowo, umożliwiając uwierzytelnianie klienta bez możliwości uwierzytelnienia drugiej strony komunikacji (Czyli Dostawcy usług Internetowych ISP).
Fazy protokołu PPPoE
Active Discovery Phase– Klient lokalizuje serwer PPPoE nazywany „Access Concetrator”.
PPP Session Phase– Nawiązywana jest sesja pomiędzy klientem a serwerem, opcje protokołu PPP są negocjowane jak i zachodzi proces uwierzytelniania użytkowników końcowych (Klientów protokołu PPPoE).
Zagadnienia związane z protokołem PPPoE
PPPoE session – Wewnętrzny proces sytemu Cisco IOS, umożliwiający potrzymanie działania protokołu PPPoE.
Virtual-Address Interface– Dodatkowy wirtualny interfejs stworzony przez system IOS do obsługi sesji PPPoE.
Pakiety protokołu PPPoE
Etap pierwszy – Nawiązywanie sesji PPPoE (Discovery Stage / Active Discovery Stage):
PADI(PPPoE Active Discovery Initiation)(Host / Broadcast) – Rozgłoszeni-owa wiadomość inicjująca sesje protokołu PPPoE, mająca na celu zlokalizowanie serwera DSL (Digital Subscriber Line). Zawiera adres MAC klienta.
PADO (PPPoE Active Discovery Offer) (Access Concentrators / Unicast) – Bezpośrednia odpowiedz serwera PPPoE, wysłana do klienta, zawierająca adres MAC klienta otrzymany w wiadomości PADI oraz ofertę nawiązania sesji PPPoE wraz z nazwą serwera. Klient może otrzymać wiele odpowiedzi PADO od różnych serwerów.
PADR (PPPoE Active Discovery Request) (Host / Unicast) – Bezpośrednia odpowiedz klienta, wysłana do serwera PPPoE (Potwierdzająca wybór oferty, oraz informująca o potrzebach klienta).
PADS (PPPoE Active Discovery Session-Confirmation) (Access Concentrators)– Wiadomość potwierdzająca nawiązanie sesji protokołu PPPoE (Stanowiąca odpowiedź na wiadomość PADR).
Jeżeli serwer PPPoE zechce nawiązać sesje, odeśle wiadomość PADS z numerem ID sesji oraz nazwą serwisu.
Jeżeli serwer PPPoE nie zechce nawiązać sesji, odeśle wiadomość PADS z nazwą serwisu (Error) jak i zresetuje wartość ID sesji.
Protokół PPP negocjuje nawiązanie sesji PPP za pomocą protokołu kontrolnego LCP (Link Control Protocol).
Protokół PPP przy pomocy protokołu NCP (Network Control Protocol) konfiguruje ustawienia warstwy trzeciej.
Etap trzeci – Kończenie sesji PPPoE:
PADT (PPPoE Active DiscoveryTerminate) (Broadcast) – Wiadomość rozgłoszeni-owa wykorzystywana do kończenia sesji protokołu PPPoE.
Restrykcje związane z protokołem PPPoE
Klient protokołu PPPoE nie wspiera:
Współistnienia serwera oraz klienta PPPoE na jednym urządzeniu.
Więcej niż 10 użytkowników na jednej końcówce CPE.
Protokołu Multilink PPP (MLP).
Protokołu NSF oraz SSO.
Funkcji Dial-on-demand.
Protokołu EVPN.
Protokołu QoS.
Protokołu IPv6.
Zasady działania protokołu PPPoE
Proces nawiązywania połączenia PPPoE
PPPoE
Fizyczny interfejs Ethernet-owy oraz wirtualny „Dialer”, zostają powiązane w odniesieniu do tej samej puli „Dial”.
System IOS rozpoczyna działania mające na celu zaimplementowanie usługi PPPoE jak i protokołu PPP, tworząc tym samym sesję „PPPoE session”. Jest to logiczna sesja przetrzymująca zmienne statusu Point to Point Protocol, CP(Control Protocols). Zarządza ona wysyłaniem jak i odbieraniem wiadomości PPPoE z i od serwera PPPoE.
System IOS tworzy nowy wirtualny interfejs (Virtual-Access Interface). Jeżeli protokół PPPoE uzyska status UP, będzie on działał jako interfejs PPPoE utrzymujący większą cześć operacji warstwy drugiej względem protokołu PPPoE.
Wszystkie powyższe interfejsy są od siebie odseparowane, jednak współpracują ze sobą w celu potrzymania komunikacji protokołu PPPoE.
Podsumowują proces działania protokołu PPPoE, Interfejs fizyczny nadaje oraz odbiera ramki Ethernet-owe, interfejs wirtualny Virtual Access Interface prowadzi komunikację protokołu PPPoE poprzez interfejs fizyczny natomiast ostatni interfejs „Dialer” przesyła pakiety warstwy trzeciej poprzez interfejs dostępowy (Access Interfejs) do interfejsu fizycznego (Ethernet-owego).
Pod-protokół IPCP umożliwia uzyskanie adresu IP od dostawcy ISP. Jest wykorzystywany na interfejsie „Dialer Interfejs”.
Sesje PPPoE jest nawiązywana z poziomu interfejsu „Dialer Interfejs”.
Konfiguracja protokołu PPPoE
Konfiguracja protokołu PPPoE
Pozostałe tematy związane z protokołem PPP oraz PPPoE
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)#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.
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”.
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
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
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 posiadadodatkową 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 synchronicznejak i asynchroniczne(Synchronousand 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).
Drugiejwykorzystują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, IPv6CPdla protokołu IPv6 czy CDPCPdla 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
Przykładowa konfiguracja protokołu Point to Point Frame Relay została opisana w artykule: Point to Point Frame Relay.
Point to Point Frame Relay
Protokół Frame Relay umożliwia automatyczne mapowanie adresów IP oraz wykrywanie wartości DLCI, jaka powinna być skonfigurowana na interfejsie sieciowym.
(config)#interface serial interfejs
Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.
(config-if)#encapsulation frame-relay
Zmienia domyślną metodę enkapsulacji interfejsu serialowego na Frame Relay.
Określa jaki protokół będzie wykorzystywany w celu testowania dostępności drugiej strony połączenia serialowego (Powyższe protokoły działają analogicznie do wiadomość Keepalive w warstwie drugiej).
(config-subif)#bandwidth 1-10000000(Kilobity na sekundę)*
Określa przepustowość łącza w celu informacyjnym dla protokołów routingu dynamicznego czy protokołu QoS.
(config-if)#ip address adres-IP
Przypisuje adres IP do konfigurowanego interfejsu serialowego.
Protokół Frame Relay umożliwia automatyczne mapowanie adresów IP oraz wykrywanie wartości DLCI, jaka powinna być skonfigurowana na interfejsie sieciowym. Jenak w przypadku pod-interfejsów wartość DLCI musi być określona statycznie za pomocą komendy [frame-relay interface-dlci 16-1007(DLCI].
(config)#interface serial interfejs
Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.
(config-if)#encapsulation frame-relay
Zmienia domyślną metodę enkapsulacji interfejsu serialowego na Frame Relay.
Określa jaki protokół będzie wykorzystywany w celu testowania dostępności drugiej strony połączenia serialowego (Powyższe protokoły działają analogicznie do wiadomość Keepalive w warstwie drugiej).
(config)#interface serial interfejs.pod-interfejs point-to-point
Przechodzi do poziomu konfiguracji określonego pod-interfejsu serialowego.
(config-subif)#bandwidth 1-10000000(Kilobity na sekundę)*
Określa przepustowość łącza w celu informacyjnym dla protokołów routingu dynamicznego czy protokołu QoS.
(config-subif)#ip address adres-IP
Przypisuje adres IP do konfigurowanego pod-interfejsu serialowego.
