NetCLI

Kategoria: Sieć rozległa WAN

  • (K) Konfiguracja protokołu DMVPN**

    (K) Konfiguracja protokołu DMVPN**

    Konfiguracja tunelu GRE

    (config)# interface tunnel 0-2147483647(tunel-ID)

    Tworzy nowy interfejs wirtualny (Tunel GRE).

    (config-if)# ip address adres-IP

    Przypisuje adres IP, do konfigurowanego konfigurowanego tunelu GRE.

    (config-if)# tunnel source {adres-IP / interfejs}

    Określa interfejs źródłowy wykorzystywany przy enkapsulacji oraz dekapsulacji ruchu sieciowego, kierowanego na interfejs wirtualny (Tunel). Źródłem tunelu GRE może być zarówno interfejs fizyczny jak i wirtualny (Loopback), który zapewnia osiągalność pomimo awarii jednego z interfejsów fizycznych.

    (config-if)# tunnel destination adres-IP

    Określa adres IP urządzenia docelowego (Końcówki tunelu GRE).

    (config-if)# bandwidth 1-00000000(Kbps)*

    Interfejsy wirtualne nie posiadają koncepcji opóźnień (Latency), ani statycznie przypisanego pasa (Bandwidth). Związku z tym administrator sam powinien określić wartość, która będzie wykorzystywana przez protokoły routingu w procesie poszukiwaniu najlepszej trasy dotarcia do sieci docelowej bądź przez funkcję QoS.

    (config-if)# keepalive [0-32767] [1-255]*

    Tunel GRE domyślnie stanowi połączenie Point-to-Point wykrywane jako aktywne „Up”, w sytuacji w której urządzenie lokalne posiada trasę do docelowego adresu IP [tunnel destination adres-IP]. Jeżeli takowy adres nie znajduje się w tablicy routingu interfejs pozostaje nieaktywny „Down”. Funkcja Keepalive sprawdza ponadto stan połączenia „line protocol” aby ruter nie musiał polegać jedynie na czasach protokołów routingu dynamicznego.

    (config-if)# ip mtu 68-17916*

    Określa wartość MTU względem konfigurowanego interfejsu sieciowego. Jako że enkapsulacja GRE dodaje do ramki pakietu IP minimum 24 bajty, maksymalna wielkość pakietu może zostać przekroczona a tym samym wymagana będzie fragmentacja. Aby ograniczyć potrzebę fragmentacji, należy skonfigurować niższą wartość MTU, niż ta domyślnie stosowana (1500), w przypadku tuneli DMVPN zaleca się stosowanie wartości 1400.

    # show interface tunnel 0-2147483647(tunel-ID)

    Wyświetla szczegółowe informacje na temat interfejsu wirtualnego (Tunelu GRE).

    Konfiguracja tunelu DMVPN

    # Działanie fazy pierwszej protokołu DMVPN zostało opisane w artykule: Fazy protokołu DMVPN.

    Faza pierwsza protokołu DMVPN umożliwia nawiązanie połączenia Hub-to-Spoke.

    Konfiguracja rutera pełniącego rolę HUB-a

    Podstawowa konfiguracja rutera HUB

    (config)# interface tunnel 0-2147483647(tunel-ID)

    Tworzy nowy interfejs wirtualny (Tunel GRE).

    (config-if)# ip address adres-IP

    Przypisuje adres IP, do konfigurowanego tunelu GRE.

    (config-if)# tunnel source {adres-IP / interfejs}

    Określa interfejs źródłowy wykorzystywany do enkapsulacji oraz dekapsulacja ruchu sieciowego, kierowanego na interfejs wirtualny. Źródłem tunelu GRE może być zarówno interfejs fizyczny jak i wirtualny (Loopback), który zapewnia osiągalność pomimo awarii jednego z interfejsów fizycznych. 
    Stosowanie interfejsów wirtualnych (Loopback) jako interfejsów źródłowych tunelu GRE, może stwarzać problemy z funkcją QoS.

    (config-if)# tunnel mode gre multipoint

    Określa tryb pracy tunelu GRE na mGRE (Multipoint GRE).

    (config-if)# tunnel key 0-4294967295(Klucz)*

    Umożliwia identyfikacje konfigurowanego tunelu, w sytuacji współdzielenia jednego interfejsu źródłowego, przez wiele interfejsów wirtualnych (Tuneli GRE). Wartość klucza musi się zgadzać pomiędzy urządzeniami aby mogły one nawiązać ze sobą połączenie wirtualne (Klucz dodaje 4 bajty do nagłówka protokołu GRE).

    (config-if)# ip nhrp network-id 1-4294967295

    Lokalna wartość identyfikująca określoną chmurę (Cloud) protokołu DMVPN. (Zaleca się stosowanie tej samej wartości Network-ID na wszystkich ruterach należących do tej samej sieci DMVPN). 
    Chodź nie ma technicznej korelacji pomiędzy wartością Network-ID a kluczem tunelu DMVPN, to wartości te powinny być takie same w celu utrzymania przejrzystej konfiguracji, wspomagającej późniejsze wsparcie techniczne dla danej sieci.

    (config-if)# ip nhrp map multicast dynamic

    Umożliwia przenoszenie ruchu multicast poprzez tunel DMVPN. 
    Tunele mGRE nie wspierają funkcji Keepalive.

    Opcjonalna konfiguracja rutera HUB

    (config)# interface tunnel 0-2147483647(tunel-ID)

    Tworzy nowy interfejs wirtualny (Tunel GRE).

    (config)# ip nhrp holdtime 1-65535(sekundy)*

    Definiuje okres czasu po jakim wygasa rejestracja tunelu Dynamic DMVPN (Spoke to Spoke) oraz (Hub to Spoke) (Tunel statyczny Spoke to Hub nie wygasa).

    (config)# ip nhrp registration timeout 1-65535(sekundy)*

    Definiuje odstępy czasowe w wysyłaniu wiadomości Keepalive protokołu NHRP (Resetuje czas holdtime).

    (config-if)# ip nhrp authentication hasło*

    Tworzy nowe hasło protokołu NHRP, uwierzytelniające strony komunikacji.

    (config-if)# ip nhrp registration no-unique*

    Blokuje proces domyślnego oznaczania ruterów NHC flagą “Unique”.

    (config-if)# bandwidth 1-00000000(Kbps)*

    Interfejsy wirtualne nie posiadają koncepcji opóźnień (Latency), ani statycznie przypisanego pasa (Bandwidth). Związku z tym administrator sam powinien określić wartość, która będzie wykorzystywana przez protokoły routingu w procesie poszukiwaniu najlepszej trasy dotarcia do sieci docelowej bądź przez funkcję QoS.

    (config-if)# ip mtu 68-17916*

    Określa wartość MTU względem konfigurowanego interfejsu sieciowego. Jako że enkapsulacja GRE dodaje do ramki pakietu IP minimum 24 bajty, maksymalna wielkość pakietu może zostać przekroczona a tym samym wymagana będzie fragmentacja. Aby ograniczyć potrzebę fragmentacji, należy skonfigurować niższą wartość MTU, niż ta domyślnie stosowana (1500), w przypadku tuneli DMVPN zaleca się stosowanie wartości 1400.

    (config-if)# tunnel path-mtu-discovery [age-timer {aging-mins(10) / infinite} / min-mtu mtu-bytes(92)]*

    Na podstawie informacji zawartych w wiadomościach ICMP typu 3 oraz 4, pasywnie wykrywa właściwą wartość MTU, umożliwiając ponowne sprawdzenie maksymalnej dostępne wartości MTU, po upływie czasu (aging timer). Z=Znacząco zmniejsza ryzyko fragmentacji.

    (config-if)# ip tcp adjust-mss 500-1460(536)*

    TCP adjust zapewnia, że ruter dokona edycji segmentu TCP Three-way Handshake jeżeli przekroczy on skonfigurowaną, maksymalną wartość MSS (Maximum Segment Size). W przypadku tuneli DMVPN zaleca się stosowanie wartości 1360, aby pomieścić zawartość nagłówka rozszerzonego o dane protokołu IP, GRE oraz IPsec.

    (config-if)# keepalive [0-32767] [1-255]*

    Tunel GRE domyślnie stanowi połączenie Point-to-Point wykrywane jako aktywne „Up”, w sytuacji w której urządzenie lokalne posiada trasę do docelowego adresu IP [tunnel destination adres-IP]. Jeżeli takowy adres nie znajduje się w tablicy routingu interfejs pozostaje nieaktywny „Down”. Funkcja Keepalive sprawdza ponadto stan połączenia „line protocol” aby ruter nie musiał polegać jedynie na czasach protokołów routingu dynamicznego. 
    Każdy ruter NHC zarejestrowany na serwerze NHS, posiada przypisany adres IP tunelu GRE, wraz z odpowiadającym mu adresem sieci NBMA. Wpisy te oznaczone flagą "Unique", są widoczne w wydruku komendy [show ip nhrp adres-IP], związku z tym nie mogą być zmienione, a wszelka ingerencja w skonfigurowany adres NBMA zarejestrowanego rutera NHC, spowoduje wystąpienie błędu [%NHRP-3-PAKREPLY: Recive Registration Reply packet with error - unique address registred already (14)] na ruterze NHC.

    Dodatkowa konfiguracja rutera HUB pod kontem protokołów routingu dynamicznego

    (config)# interface tunnel 0-2147483647(tunel-ID)

    Tworzy nowy interfejs wirtualny (Tunel GRE).

    (config-if)# no ip split-horizon eigrp ASN

    Wyłącza funkcję podzielonego horyzontu „split-horizon”, względem protokołu EIGRP.

    (config-if)# ip ospf network point-to-multipoint

    Zmienia domyślny rodzaj sieci protokołu OSPF (Point to Point), na sieć rozgłoszeni-ową Broadcast, względem połączenia wirtualnego DMVPN.

    Konfiguracja rutera pełniącego rolę SPOKE

    Podstawowa konfiguracja rutera SPOKE

    Konfiguracja rutera NHC (Spoke) w fazie DMVPN Phase 1 jest podobna do konfiguracji rutera NHS (Hub) z wyjątkiem: wykorzystania tunelu GRE zamiast mGRE oraz koniecznego mapowania do przynajmniej jednego z ruterów NHS (Hub-a DMVPN).

    (config)# interface tunnel 0-2147483647(tunel-ID)

    Tworzy nowy interfejs wirtualny (Tunel GRE).

    (config-if)# ip address adres-IP

    Przypisuje adres IP, do konfigurowanego tunelu GRE.

    (config-if)# tunnel source {adres-IP / interfejs}

    Określa interfejs źródłowy wykorzystywany do enkapsulacji oraz dekapsulacji ruchu sieciowego, kierowanego na interfejs wirtualny. Źródłem tunelu GRE może być zarówno interfejs fizyczny jak i wirtualny (Loopback), który zapewnia osiągalność pomimo awarii jednego z interfejsów fizycznych. 
    Stosowanie interfejsów wirtualnych (Loopback) jako interfejsów źródłowych tunelu GRE, może powodować problemy z funkcją QoS.

    (config-if)# tunnel destination adres-IP(Adres NBMA)

    Określa docelowy adres IP, sieci „Underlay Network” (NBMA).

    (config-if)# tunnel key 0-4294967295(Klucz)*

    Umożliwia identyfikacje konfigurowanego tunelu, w sytuacji współdzielenia jednego interfejsu źródłowego, przez wiele interfejsów wirtualnych (Tuneli GRE). Wartość klucza musi się zgadzać pomiędzy urządzeniami aby mogły one nawiązać ze sobą połączenie wirtualne (Klucz dodaje 4 bajty do nagłówka protokołu GRE).

    (config-if)# ip nhrp network-id 1-4294967295

    Lokalna wartość identyfikująca określoną chmurę (Cloud) protokołu DMVPN. (Zaleca się stosowanie tej samej wartości Network-ID na wszystkich ruterach należących do tej samej sieci DMVPN).

    (config-if)# ip nhrp nhs adres-IP(Adres rutera NHS) nbma adres-IP(Adres NBMA) [multicast]

    Określa adres IP, przynajmniej jednego rutera pełniącego rolę NHS. Adres NHS odnosi się do adresu IP skonfigurowanego na interfejsie wirtualnym (GRE), natomiast adres NBMA określa adres IP sieci wielodostęp-owej (Przeważnie będącej siecią publiczną).
    * multicast – Umożliwia przenoszenie ruchu multicast poprzez tunel DMVPN, umożliwiając tym samym obsługę protokołów routingu dynamicznego.

    # show dmvpn [detail]

    Wyświetla szczegółowe informacje dotyczące statusu tuneli wirtualnych (DMVPN) w tym: status tuneli GRE, adres IP (NBMA) adres IP (GRE), tryb pracy Hub/Spoke, ilość podłączonych ruterów NHC (W przypadku rutera NHS) oraz szczegółowe informacje na tematach podłączonych ruterów NHS bądź NHC, w tym tryb pracy wybranego tunelu (Static/Dynamic).

    Konfiguracja wielu ruterów HUB

    (config)# interface tunnel 0-2147483647(tunel-ID)

    Tworzy nowy interfejs wirtualny (Tunel GRE).

    (config-if)# ip nhrp nhs cluster 0-10(ID klastera) max-connections 0-255(Maksymalna ilość jednoczesnych połączeń)

    Określa maksymalną liczbę serwerów NHS jakie mogą być jednocześnie aktywne, względem jednego klastera DMVPN.

    (config-if)# ip nhrp nhs fallback 0-60(Sekundy)

    (config-if)# ip nhrp nhs adres-IP(Adres rutera NHS) priority 0-255(Priorytet rutera NHS)
    (config-if)# ip nhrp nhs adres-IP(Adres rutera NHS) cluster 0-10(ID klastera)

    Określa wartość priorytetu rutera NHS oraz klaster do jakiego należy.
    Powyższe oraz poniższa komenda, jest stosowana zamiennie.

    (config-if)# ip nhrp nhs adres-IP(Adres rutera NHS) nbma adres-IP(Adres NBMA) [multicast] priority 0-255(Priorytet rutera NHS) cluster 0-10(ID klastera)

    Określa wartość priorytetu rutera NHS oraz klaster do jakiego należy.

    # show ip nhrp nhs redundancy

    Wyświetla

    Opcjonalna konfiguracja rutera SPOKE

    (config)# interface tunnel 0-2147483647(tunel-ID)

    Tworzy nowy interfejs wirtualny (Tunel GRE).

    (config)# ip nhrp holdtime 1-65535(sekundy)*

    Definiuje okres czasu po jakim wygasa rejestracja tunelu Dynamic DMVPN (Spoke to Spoke) oraz (Hub to Spoke) (Tunel statyczny Spoke to Hub nie wygasa).

    (config)# ip nhrp registration timeout 1-65535(sekundy)*

    Definiuje odstępy czasowe w wysyłaniu wiadomości Keepalive protokołu NHRP (Resetuje czas holdtime).

    (config-if)# ip nhrp authentication hasło*

    Tworzy nowe hasło protokołu NHRP, uwierzytelniające strony komunikacji.

    (config-if)# bandwidth 1-00000000(Kbps)*

    Interfejsy wirtualne nie posiadają koncepcji opóźnień (Latency), ani statycznie przypisanego pasa (Bandwidth). Związku z tym administrator sam powinien określić wartość, która będzie wykorzystywana przez protokoły routingu w procesie poszukiwaniu najlepszej trasy dotarcia do sieci docelowej bądź przez funkcję QoS.

    (config-if)# ip mtu 68-17916*

    Określa wartość MTU względem konfigurowanego interfejsu sieciowego. Jako że enkapsulacja GRE dodaje do ramki pakietu IP minimum 24 bajty, maksymalna wielkość pakietu może zostać przekroczona a tym samym wymagana będzie fragmentacja. Aby ograniczyć potrzebę fragmentacji, należy skonfigurować niższą wartość MTU, niż ta domyślnie stosowana (1500), w przypadku tuneli DMVPN zaleca się stosowanie wartości 1400.

    (config-if)# tunnel path-mtu-discovery [age-timer {aging-mins(10) / infinite} / min-mtu mtu-bytes(92)]*

    Na podstawie informacji zawartych w wiadomościach ICMP typu 3 oraz 4, pasywnie wykrywa właściwą wartość MTU, umożliwiając ponowne sprawdzenie maksymalnej dostępne wartości MTU, po upływie czasu (aging timer). Z=Znacząco zmniejsza ryzyko fragmentacji.

    (config-if)# ip tcp adjust-mss 500-1460(536)*

    TCP adjust zapewnia, że ruter dokona edycji segmentu TCP Three-way Handshake jeżeli przekroczy on skonfigurowaną, maksymalną wartość MSS (Maximum Segment Size). W przypadku tuneli DMVPN zaleca się stosowanie wartości 1360, aby pomieścić zawartość nagłówka rozszerzonego o dane protokołu IP, GRE oraz IPsec.

    (config-if)# keepalive [0-32767] [1-255]*

    Tunel GRE domyślnie stanowi połączenie Point-to-Point wykrywane jako aktywne „Up”, w sytuacji w której urządzenie lokalne posiada trasę do docelowego adresu IP [tunnel destination adres-IP]. Jeżeli takowy adres nie znajduje się w tablicy routingu interfejs pozostaje nieaktywny „Down”. Funkcja Keepalive sprawdza ponadto stan połączenia „line protocol” aby ruter nie musiał polegać jedynie na czasach protokołów routingu dynamicznego.

    Alternatywna konfiguracja mapowania serwera nhs (SPOKE)

    Alternatywna konfiguracja mapowania serwera NHS zamiast komendy [ip nhrp nhs adres-IP nbma adres-IP [multicast]], wykorzystuje następującą konfigurację:

    (config)# interface tunnel 0-2147483647(tunel-ID)

    Tworzy nowy interfejs wirtualny (Tunel GRE).

    (config-if)# ip nhrp nhs adres-IP

    Określa adres rutera NHS (Hub) przypisując go do konfigurowanego tunelu (GRE).

    (config-if)# ip nhrp map adres-IP(Adres rutera NHS) adres-IP(Adres NBMA)

    Mapuje adres NBMA rutera NHS do adresu IP tunelu (GRE), należącego do tego samego rutera NHS.

    (config-if)# ip nhrp map multicast [adres-IP / dynamic]

    Określa adres IP tunelu (GRE), wykorzystywany w komunikacji Multicast.

    Dodatkowa konfiguracja rutera SPOKE pod kontem protokołów routingu dynamicznego

    (config)# interface tunnel 0-2147483647(tunel-ID)

    Tworzy nowy interfejs wirtualny (Tunel GRE).

    (config-if)# ip ospf network broadcast

    Zmienia domyślny rodzaj sieci protokołu OSPF (Point to Point), na sieć rozgłoszeni-ową Broadcast, względem połączenia wirtualnego DMVPN.

    Komendy Show, Clear, Debug

    Komendy SHOW

    # show dmvpn [detail]

    Wyświetla podstawowe / szczegółowe informacje dotyczące statusu tuneli wirtualnych (DMVPN) w tym: status tuneli GRE, adres IP (NBMA) adres IP (GRE), tryb pracy Hub/Spoke, ilość podłączonych ruterów NHC (W przypadku rutera NHS) oraz szczegółowe informacje na tematach podłączonych ruterów NHS bądź NHC, w tym tryb pracy wybranego tunelu (Static/Dynamic).

    # show dmvpn peer {nbma adres-IP(Adres NBMA) [detail] / tunnel adres-IP(Adres GRE) [detail]}

    Wyświetla podstawowe / szczegółowe informacje na temat wskazanego w komendzie sąsiada protokołu DMVPN.

    # show ip nhrp [brief / detail]

    Wyświetla zawartość lokalnej bazy protokołu NHRP, w tym adres IP tunelu (GRE) wraz z przynależącym do niego adresem NBMA oraz interfejsem źródłowym.

    # show ip nhrp [purge / redirect / shortcut]

    Wyświetla zapisy bazy NHRP odnośnie wiadomości purge, redirect, shortcut.

    # show ip nhrp [dynamic / static]

    Wyświetla wszystkie statyczne / dynamiczne tunele protokołu DMVPN.

    # show ip nhrp nhs

    Wyświetla wszystkie tunele prowadzące do ruterów NHS.

    # show ip nhrp stats

    Wyświetla

    # show ip nhrp summary

    Wyświetla

    # show ip nhrp traffic

    Wyświetla

    # show ip route next-hop-override

    Wyświetla obecnie wykorzystywane adresy następnego przeskoku, dla tras wykorzystujących skrót protokołu NHRP (ip nhrp shortcut).

    Komendy CLEAR

    # clear dmvpn session [peer adres-IP]

    Czyści wszystkie / określone sesje protokołu DMVPN.

    # clear dmvpn statistics

    Czyści statystyki protokołu DMVPN.

    Komendy DEBUG

    # debug

    # debug

    # debug

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

  • (TS) Troubleshooting protokołu DMVPN*

    (TS) Troubleshooting protokołu DMVPN*

    Troubleshooting protokołu DMVPN

    Znaczenie komend SHOW

    • [show dmvpn [detail]] – Wyświetla szczegółowe informacje na temat statusu tuneli wirtualnych DMVPN w tym:
      • Status tunelu wirtualnego DMVPN (Up / Down).
      • Adres IP (NBMA / Tunelu GRE).
      • Ilość podłączonych ruterów NHC (W przypadku serwera NHS).
      • Szczegółowe informacje na tematach podłączonych urządzeń NHS bądź NHC.
      • Tryb pracy tunelu DMVPN (Static / Dynamic).
    • [show ip nhrp [brief / detail]] – Wyświetla szczegółowe informacje na temat statusu tuneli wirtualnych DMVPN w tym:
      • Adres IP (NBMA / Tunelu GRE).
      • Czas pracy tunelu DMVPN.
      • Ilość podłączonych ruterów NHC (W przypadku serwera NHS).
      • Tryb pracy wybranego tunelu (Static / Dynamic).

    Flagi oraz mapowanie protokołu NHRP

    • Stany mapowania protokołu NHRP:
      • Static – Statyczny wpis wprowadzony przez protokół DMVPN.
      • Dynamic – Dynamiczny wpis stworzony w fazie pierwszej protokołu DMVPN (Phase 1), po zarejestrowaniu rutera NHC w bazie NHRP serwera NHS (Hub-a).
      • Incomplete – Tymczasowy wpis protokołu DMVPN, przetrzymywany w bazie NHRP w czasie oczekiwania na zapytanie „Resolution”. Wpis ten blokuje przetwarzanie kolejnego wpisu dla tego samego adresu docelowego.
      • Local – Informacje dotyczące lokalnego mapowania wpisanego do bazy NHRP za pomocą odpowiedzi „Resolution”.
      • (No Socket) –
      • NBMA address –
      • NATed –
      • Route Installed –
      • Nexthop-override –
      • Authoritative – ???? pytanie egzaminacyjne CCNP route (Informacje zostały pobrane z serwera Next hop Server bądź routers that maintance NBMA to IP address mapping for this destinations.
    • Flagi protokołu NHRP:
      • Used – xx
      • Implicit – xx
      • Unique – xx
      • Router – xx
      • Rib – xx
      • Nho – xx

    Proces nawiązywania tunelu DMVPN

    1. INTF – Status Line Protocol interfejsu DMVPN jest w stanie nieaktywnym Down.
    2. IKE – Tunel DMVPN skonfigurowany wraz z protokołem IPsec nie nawiązał jeszcze sesji IKE.
    3. IPsec – Sesja IKE została nawiązana bez zakończenia procesu asocjacji SA.
    4. NHRP – Tunel DMVPN nie został jeszcze w pełni zarejestrowany.
    5. Up – Status Line Protocol interfejsu DMVPN jest w stanie aktywnym Up.

    Błędy związane z protokołem DMVPN

    • [%FORWARDING-IP_TUNNEL-3-LOOPING] – Błąd związany z enkapsulacją.
    • [%TUN-5-RECURDOWN] – Błąd protokołu GRE, związany z wysępieniem routingu rekursywnego (Recursive Routing). Określającego adres następnego przeskoku (Destination address) tunelu GRE, jako osiągalnego poprzez ten sam tunnel.
    • Neighbor relationship down – Zerwanie relacji sąsiedztwa automatycznie zrywa połączenie protokołu DMVPN.

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

  • (T) Podstawowe pojęcie dotyczące protokołu DMVPN**

    (T) Podstawowe pojęcie dotyczące protokołu DMVPN**

    Protokoły VPN

    Protokoły VPN

    • IPsec (Internet Protocol security)
    • SSL (Secure Socket Layer)
    • GRE (Generic Routing Encapsulation)
    • GRE 6to4 (IPv6 over IPv4)
    • DMVPN (Dynamic Multipoint VPN)
    • GETVPN (Group Encrypted Transport VPN)
    • EVPN (Easy Virtual Private Network)
    • FLEXVPN

    Rodzaje sieci VPN

    • VPN Site-to-site
    • VPN Remont-access

    Wartość MTU a Tunel GRE

    • PMTUD (Path MTU Discovery) – U-standaryzowana technika automatycznego wykrywania najwyższej wartości MTU, na drodze pomiędzy dwoma komunikującymi się urządzeniami. Opisana w referencji RFC 1191 dla protokołu IPv4 oraz w referencji RFC 1981 dla protokołu IPv6. Dodatkowa referencja RFC 4821 opisuje rozszerzenie dotyczące obsługi protokołu ICMP. Protokół PMTUD pomaga zniwelować problem fragmentacji pakietów IPv4.
    • Protokół GRE wykorzystuje protokół IP 47.
    Tunnel Type Tunnel Headers Size
    GRE without IPsec 24 Bytes
    DES/3DES IPsec (Transport mode) 18-25 Bytes
    DES/3DES IPsec (Tunnel mode) 38-45 Bytes
    GRE/DMVPN + DES/3DES 42-49 Bytes
    GRE/DMVPN + AES + SHA-1 62-77 Bytes

    Wielkość pakietu IP enkapsulowanego przez tunel GRE

    Wsparcie protokołu GRE dla protokołów routingu dynamicznego

    • Protokół GRE wspiera wszystkie rodzaje ruchu sieciowego (Unicast, Multicast oraz Broadcast) dzięki czemu jest wstanie przesyłać wiadomości protokołów routingu dynamicznego.

    Wstęp do protokołu DMVPN

    Technologie oraz rozwiązania wykorzystywane przez DMVPN

    • GRE (Generic Routing Encapsulation) – Zapewnia łączność na poziomie warstwy trzeciej, pomiędzy dwoma bądź też większą liczbą sieci (mGRE). Protokół DMVPN wykorzystuje enkapsulacje mGRE (Multipoint GRE) wraz z protokołami routingu dynamicznego, tworząc połączenia zwane „Overlay Network” prowadzone nad przeważnie publiczną siecią IP, zwaną „Underlay Network”.
    • NHRP (Next Hop Resolution Protocol) –  Tworzy bazę publicznych oraz prywatnych adresów IP, należących do wszystkich urządzeń Spoke z jednej instancji protokołu DMVPN.
    • Transportation Independence – Połączenia DMVPN są nawiązywane niezależnie od wybranej technologii WAN, dzięki czemu mogą korzystać z połączań PPP, Frame Relay, MPLS, czy zwykłego łącza Internetowego.
    • Zero-Touch Provisioning – Dodawanie nowych oddziałów zdalnych (Spoke), nie wymaga interwencji w obecną konfigurację oddziału głównego (Hub). Ponadto  umożliwia zastosowanie szablonów konfiguracyjnych dla biur zdalnych z wymiennymi danymi dotyczącymi np. adresów IP.
    • Scalable Deployment – Minimalna ilość ręcznie konfigurowanych tuneli DMVPN, umożliwia stworzenie rozbudowanej sieci połączeń pomiędzy oddziałami zdalnymi (Spoke) a odziałem głównym (Hub), oraz automatyczne nawiązanie połączeń wirtualnych bezpośrednio pomiędzy poszczególnymi oddziałami zdalnymi (Spoke). Niezależnie od ilości posiadanych ruterów fizycznych, logicznych bądź wirtualnych.
    • Spoke-to-Spoke Tunnels – Zapewnia pełną łączność pomiędzy oddziałami zdalnymi (Spoke to Spoke) przy zastosowaniu jedynie podstawowej konfiguracji (Spoke to Hub). Połączenia wirtualne pomiędzy końcówkami (Spoke to Spoke) są nawiązywane dynamicznie bez strat w przesyłanej transmisji danych.
    • Flexible Network Topologies – DMVPN nie przyjmuje sztywnych założeń odnośnie płaszczyzny Control Plane oraz Data Plane,  umożliwiając tworzenie topologii cechujących się wysokim stopniem odporności oraz rozproszenia, pozwalając tym samym na uniknięcie pojedynczego punktu awarii. Z drugiej strony, protokół DMVPN może być używany w modelu scentralizowanym.
    • Multiprotocol Support – DMVPN zapewnia wsparcie dla protokołów IPv4, IPv6, MPLS, OTV (Overlay Transport Virtualization) oraz innych protokołów.
    • Multicast Support – DMVPN umożliwia przepływ ruchu Multicast na interfejsach tunelowych mGRE.
    • Adaptable Connectivity – Rutery wspierające protokół DMVPN mogą nawiązać pomiędzy sobą łączność nad punktem translacji adresów NAT (Network Address Translation). Ponadto urządzenia znajdujące się w oddziałach zdalnych mogą dynamicznie pobierać adresacje IP za pomocą protokołu DHCP (Dynamic Host Configuration Protocol).
    • Standardized Building Blocks – DMVPN wykorzystuje ustandaryzowane protokoły takie jak: NHRP, GRE bądź IPsec.

    DMVPN a protokoły routingu dynamicznego

    • Protokół DMVPN wspiera następujące protokołu routingu dynamicznego:
      • EIGRP, OSPF oraz BGP.

    Zaawansowane zagadnienia związane z protokołem DMVPN

    NHRP Unique

    • Każdy ruter NHC zarejestrowany na serwerze NHS, posiada przypisany adres IP tunelu GRE, wraz z odpowiadającym mu adresem sieci NBMA. Wpisy te oznaczone flagą “Unique”, są widoczne w wydruku komendy [show ip nhrp adres-IP], związku z tym nie mogą być zmienione, a wszelka interwencja w skonfigurowany adres NBMA zarejestrowanego rutera NHC, spowoduje wystąpienie błędu [%NHRP-3-PAKREPLY: Recive Registration Reply packet with error – unique address registred already (14)].

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

  • (T) Next Hop Resolution Protocol (NHRP)**

    (T) Next Hop Resolution Protocol (NHRP)**

    Definicja protokołu NHRP

    • Protokół NHRP opisany w dokumencie RFC 2332, jest aktywowany na ruterze (Hub), zapewniając metodę odwzorowania adresów IP względem ruterów (Spoke) dla sieci NBMA (Przeważnie stanowiącej Internet bądź połączenia WAN-owe takie jak MPLS). Działania protokołu NHRP są zbliżone do funkcjonowania protokołu ARP. Jest to protokół oparty na strukturze klient-serwer w której urządzenia końcowe NHC (Next-Hop Client) (Spoke) są rejestrowane w serwerze NHS (Next-Hop Server) (Hub) odpowiadającym na zapytania odnośnie adresów IP następnego przeskoku w komunikacji (Spoke to Spoke).
    • NHS (Next-Hop Server) – Główne urządzenie sieci DMVPN wykorzystujące tunele mGRE w celu zbierania informacji o urządzeniach zdalnych (Spoke, NHC) jak i odpowiadające na ich zapytania odnoście adresów IP następnego przeskoku w komunikacji (Spoke to Spoke).
    • NHC (Next-Hop Client) – Urządzenie zdalne (Spoke) rejestrujące się bazie serwera NHRP (NHS).

    Wiadomości protokołu NHRP (RFC 2332)

    Urządzenie zdalne odnosi się do ruter-a NHC (Spoke).
    • Registration (NHC -> NHS) – Rejestruje ruter NHC w bazie protokołu NHRP, znajdującej się na ruterze NHS.
      • Ruter NHC za pomocą wiadomości „Registration” informuje serwer NHS o posiadanym adresie IP sieci NBMA wraz z czasem przez jaki ruter NHS ma przechowywać otrzymaną rejestrację.
      • Jeżeli w sieci NBMA nastąpi zmiana adresu IP (NAT), serwer NHS wykryje ją za pomocą różnicy w adresach IP, pomiędzy nagłówkiem GRE/IP a zawartością wiadomości „registration”. Zapisując w bazie NHRP obydwa adresy IP:
        • NBMA address – Adres otrzymany w nagłówku GRE/IP (Po translacji NAT).
        • Claimed NBMA Address – Adres otrzymany wraz z zawartością wiadomości „registration” (Przed translacją NAT).
    • Resolution (Zapytanie NHC -> NHS / Odpowiedź NHS -> NHC) – Umożliwia ruterowi NHC wykrycie bezpośredniego połączenia do innego rutera zdalnego, a tym samym nawiązanie tunelu dynamicznego (Spoke to spoke).
      • Zapytanie „Resolution” wysłane przez ruter NHC zawiera prośbę o przesłanie adresu IP sieci NBMA / tunelu GRE innego urządzenia zdalnego (Spoke), stanowiącego możliwy następny przeskok w drodze do sieci docelowej.
      • W odpowiedź na zapytanie „Resolution” ruter NHS dostarcza informacje o adresie IP tunelu GRE oraz sieci NBMA urządzenia (Spoke). Powyższy proces zostaje zapoczątkowany przez serwer NHS za pomocą wiadomości „Resolution” po wykryciu pierwszego pakietu „Hairpinning”. Hairpinning określa ruch sieciowy otrzymany a następnie wysyłany przez serwer NHS w obrębie jednej chmury DMVPN (Identyfikowanej za pomocą wartości NHRP ID).
    • Redirect (NHS -> NHC) – Informuje ruter NHC o istnieniu lepszej trasy dotarcia do innego rutera zdalnego.
      • Ruter NHS z włączoną funkcją „Redirect” systematycznie sprawdza każdą nadchodzącą kombinacje adresów źródłowych oraz docelowych sieci NBMA, weryfikując czy istnieje pomiędzy nimi bardziej optymalna trasa „Hairpinning”. Jeżeli takowa zostanie wykryta serwer NHS wyśle wiadomość „Redirect” do rutera NHC od którego został otrzymany dany ruch sieciowy. Dzięki czemu ruter NHC w następnym kroku wyśle zapytanie „Resolution”.
    • Purge (Zazwyczaj NHS -> NHC) – Ruter NHS informuje ruter NHC o utracie trasy przetrzymywanej w bazie NHRP.
    • Error – Informuje nadawcę wiadomości NHRP o wystąpieniu błędu.

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

  • (T) Fazy protokołu DMVPN**

    (T) Fazy protokołu DMVPN**

    Fazy protokołu DMVPN

    Tworzenia tunelu DMVPN

    • Protokół DMVPN może być zaimplementowany w postaci jednej z trzech faz, z których każda została oparta na poprzedniej oraz rozszerzona o dodatkowe możliwości. Wszystkie fazy wymagają jedynie jednego interfejsu sieciowego względem rutera.

    Phase 1 (Spoke-to-Hub)

    • Pierwsze wydanie protokołu DMVPN zapewnia możliwość instalacji z zerowym dotykiem „Zero-Touch Provisioning”. Umożliwiając tworzenie tuneli wirtualnych jedynie w topologii Hub-to-Spoke.

    Phase 2 (Spoke-to-Spoke)

    • Drugie wydanie protokołu DMVPN rozszerzyło
      możliwości tworzenia tuneli wirtualnych o dynamiczne nawiązywanie połączeń w
      topologii Spoke-to-Spoke.
    • Faza druga protokołu DMVPN nie wspiera
      sumaryzacji „Next-Hop Preservation”
      jak i komunikacji Spoke-to-Spoke pomiędzy różnymi sieciami DMVPN (Multilevel
      Hierarchical DMVPN).

    Phase 3 (Hierarchical Tree Spoke-to-Spoke)

    • Trzecie wydanie protokołu DMVPN udoskonaliło proces nawiązywania tuneli dynamicznych Spoke-to-Spoke, poprzez wprowadzenie nowych wiadomości protokołu NHRP. Niwelując tym samym potrzebę wykorzystywania protokołów routingu dynamicznego w procesie wykrywania tras Spoke-to-Spoke. Nowy proces nawiązywania dynamicznych tuneli wygląda następująco:
      • Ruter NHS (Hub) w oparciu o otrzymany ruch sieciowy, wykrywa możliwość bezpośredniego połączenia oddziałów zdalnych (Spoke) w topologii Spoke-to-Spoke, informując o tym ruter NHC za pomocą wiadomości „Redirect”.
      • W odpowiedzi na otrzymaną wiadomość „Redirect” ruter NHC wysyła zapytanie „Resolution” do rutera NHS w celu określenia adresów niezbędnych do nawiązania bezpośredniego połączenia (Spoke to spoke).
    • Faza trzecia protokołu DMVPN, umożliwia modyfikacje tras routingu wprowadzając skróty w adresach następnego przeskoku bądź dodając całkowicie nowe wpisy. Dzięki czemu możliwe staje się wprowadzanie tras zsumaryzowanych na poziome Hub-a, jak i optymalizowanie ruchu pomiędzy ruterami NHC (Spoke to spoke).
    • Wprowadzenie skrótów tras routingu za pomocą protokołu NHRP umożliwia stworzenie topologii drzewa, dzięki czemu regionalny Hub jest odpowiedzialny za zarządzanie trasami wewnątrz jednego regionu, a urządzenia Spoke mogą nawiązywać połączenia pomiędzy regionami.

    Różnice pomiędzy poszczególnymi fazami protokołu DMVPN

    Porównanie faz 1 do 3 protokołu DMVPN w topologii Multilevel DMVPN
    • Phase 1 vs 2:
      • Hub-to-Spoke – Zarówno faza pierwsza jak i druga zachowuje się identycznie względem połączenia Hub-to-Spoke.
      • Spoke-to-Spoke – Faza pierwsza udostępnia możliwość komunikacji Spoke-to-Spoke jedynie poprzez ruter Hub, natomiast faza druga dodaje możliwość bezpośredniego połączenia końcówek Spoke, jedynie przy wykorzystaniu protokołów routingu dynamicznego, bądź tras statycznych.
    • Phase 2 vs 3:
      • Hub-to-Spoke – Zarówno faza druga jak i trzeci zachowuje się identycznie względem połączenia Hub-to-Spoke.
      • Spoke-to-Spoke – Faza druga udostępnia możliwość komunikacji Spoke-to-Spoke przy wykorzystaniu protokołów routingu dynamicznego, natomiast faza trzecia dodaje możliwość bezpośredniego połączenia końcówek Spoke za pomocą skrótów (Shortcut).
      • Multilevel Spoke-to-Spoke – Faza druga udostępnia możliwość komunikacji Spoke-to-Spoke poprzez ruter Global Hub, natomiast faza trzecia dodaje możliwość bezpośredniego połączenia końcówek Spoke.
    Każda z faz protokołu DMVPN posiada własną lekko zmodyfikowaną konfigurację CLI.

    Nawiązywanie tunelu Spoke to Spoke (Faza trzecia III)

    Wizualizacja procesu nawiązywania tunelu Spoke to Spoke
    1. Ruter 21 wysyła pakiety z adresu 10.2.2.1 na adres 10.3.3.1 poprzez adres następnego przeskoku 192.168.1.1, enkapsulując nadawane pakiety nagłówkiem GRE, z adresem docelowym 172.16.1.1.
    2. Serwer 11 de-enkapsuluje nadchodzące pakiety, określając na podstawie tablicy routingu adres następnego przeskoku na 192.168.1.3. Następnie protokół NHRP na podstawie tablicy odwzorowania, określa docelowy adres NBMA pakietów na 172.16.1.3, przesyłając je do ponownej enkapsulacji poprzez ten sam tunel, na którym zostały one odebrane, w celu dostarczenia ich do rutera 31.
      1. Włączona na serwerze 11 opcja Redirect, wykrywa ruch sieciowy kierowany na ten sam tunel z którego ruch ten został odebrany „Hairpinning”. Co powoduje nadanie do rutera 21 wiadomość NHRP „Redirect”, z informacją o istnieniu bezpośredniej trasy pomiędzy siecią 10.2.2.0/24 a siecią 10.3.3.0/24.
    3. Ruter 21 wysyła do serwera 11 zapytanie NHRP „Resolution” odnośnie bezpośredniej trasy do sieci 10.3.3.1, zawierające adres tunelu GRE (192.168.1.2) oraz adres sieci NBMA (172.16.1.2). W tym samym czasie Ruter 31 przetwarza pakiety otrzymane do serwera 11, po czym odsyła przez niego odpowiedź do rutera 21.
    4. Serwer 11 przetwarza nadchodzące pakiety otrzymane od rutera 31, jednocześnie przesyłając do niego wiadomość NHRP „Redirect”, z informacją o istnieniu bezpośredniej trasy pomiędzy siecią 10.2.2.0/24 a siecią 10.3.3.0/24, ponadto przekazując zapytanie NHRP „Resolution” wysłane przez ruter 21 związku z zapytaniem o bezpośrednią trasę do sieci 10.3.3.1.
    5. Ruter 31 wysyła do serwera 11 swoje własne zapytanie NHRP „Resolution” odnośnie bezpośredniej trasy do sieci 10.2.2.1, jednocześnie odsyłając odpowiedź na wiadomość NHRP „Resolution” wysłaną przez ruter 21 związku z zapytaniem o bezpośrednią trasę do sieci 10.3.3.1. Zawiera ona adres tunelu GRE (192.168.1.3) oraz adres sieci NBMA (172.16.1.3). Odpowiedź NHRP dotyczy całej sieci 10.3.3.0/24 i jest wysyłana bezpośrednio do rutera 21.
    6. Serwer 11 przekazuje odpowiedź NHRP „Resolution” do rutera 21, odnośnie bezpośredniej trasy do sieci 10.3.3.1.
    7. Ruter 21 wysyła do rutera 31 bezpośrednią odpowiedź NHRP „Resolution”, zawierającą adres tunelu (192.168.1.2) oraz adres NBMA 172.16.1.2.

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

  • (K) PPP over Frame Relay

    (K) PPP over Frame Relay

    Konfiguracja PPP over Frame Relay

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

    (config-if)# interface serial interfejs.pod-interfejs point-to-point

    Przechodzi do poziomu konfiguracji pod-interfejsu.

    (config-subif)# frame-relay interface-dlci 16-1007(DLCI lokalne) ppp virtual-template 1-200(ID)

    Mapuje DLCI do połączenia PPP.

    (config-subif)# interface virtual-template 1-200(ID)

    Przechodzi do poziomu konfiguracji określonego interfejsu wirtualnego.

    (config-if)# encapsulation ppp

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

    (config-if)# ip address adres-IP

    Definiuje adres IP konfigurowanego interfejsu wirtualnego.

    (config-if)# interface serial interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.

    (config-if)# [no] shutdown

    Aktywuje / Dezaktywuje konfigurowany interfejs serialowy.

    Komendy SHOW

    # show frame-relay pvc

    Wyświetla szczegółowe informacje związane z połączeniami Virtual Circuits.

    # show frame-relay pvc | include PVC

    Wyświetla status połączeń Virtual Circuits.

    # show frame-relay map

    Wyświetla mapowanie lokalnego interfejsu oraz wartości DLCI, do adresu IP sąsiedniego urządzenia.

    # show frame-relay lmi

    Wyświetla wykorzystywany standard testowania połączenia (Keepalive).

    Pozostałe tematy związane z protokołem Frame Relay

  • (K) Przełącznik Frame Relay

    (K) Przełącznik Frame Relay

    Konfiguracja przełącznika Frame Relay

    Konfiguracja przełącznika Frame Relay

    Przykładowa konfiguracja przełącznika Frame Relay została opisana w artykule: Multipoint Frame Relay.

    (config)# frame-relay switching

    Aktywuje funkcję przełącznika Frame-Relay na konfigurowanym ruterze.

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

    (config-if)# frame-relay intf-type dce

    Określa rolę konfigurowanego interfejsu serialowego, na DCE.

    (config-if)# frame-relay route 16-1007(DLCI konfigurowanego interfejsu) interface interfejs(Interfejs następnego przeskoku dla danej trasy) 16-1007(DLCI przypisane do interfejsu następnego przeskoku)

    Tworzy trasę określającą powiązanie pomiędzy poszczególnymi wartościami DLCI a interfejsami serialowymi.

    (config-if)# [no] shutdown

    Aktywuje / Dezaktywuje konfigurowany interfejs serialowy.

    # show frame-relay route

    Wyświetla konfiguracje trasowania protokołu Frame Relay.

    Nowa metoda konfiguracji przełącznika Frame Relay

    Przykładowa konfiguracja przełącznika Frame Relay została opisana w artykule: Point to Point Frame Relay.

    (config)# interface serial interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.

    (config)# encapsulation frame-relay

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

    (config-if)# frame-relay intf-type dce

    Określa rolę konfigurowanego interfejsu serialowego, na DCE.

    (config-if)# frame-relay switching

    Aktywuje funkcję przełącznika Frame-Relay na konfigurowanym ruterze.

    (config)# connect nazwa interfejs(Pierwszy interfejs) 16-1007(DLCI pierwszego interfejsu) interfejs(Drugi interfejs) 16-1007(DLCI drugiego interfejsu)

    Tworzy nową trasę Frame Relay pomiędzy pierwszym interfejsem serialowym z przypisaną do niego wartością DLCI, a drugim interfejsem oraz określoną względem niego wartością DLCI.

    (config)# interface serial interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.

    (config-if)# [no] shutdown

    Aktywuje / Dezaktywuje konfigurowany interfejs serialowy.

    # show connection all

    Wyświetla konfiguracje trasowania protokołu Frame Relay.

    Komendy SHOW

    # show frame-relay route

    Wyświetla konfiguracje trasowania protokołu Frame Relay.

    # show connection all

    Wyświetla konfiguracje trasowania protokołu Frame Relay.

    Pozostałe tematy związane z protokołem 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

  • (Ts) Frame Relay**

    (Ts) Frame Relay**

    Troubleshooting protokołu Frame Relay

    Przykładowe problemy związane z protokołem Frame Relay

    1. Enkapsulacja na urządzeniach nie jest zgodna.
    2. DLCI jest nieaktywne.
    3. DLCI zostało podłączone do złego interfejsu.
    4. Lista ACL została źle skonfigurowana.
    5. Brakuje komendy [frame-relay map].
    6. Brakuje pod-komendy [broadcast].

    Komendy show

    • Komenda [show frame-relay pvc] wyświetla informacje o:
      • DE, FECN, BECN.
    • Komenda [show frame-relay lmi] wyświetla informacje o:
      • Wykorzystywanym standardzie funkcji Keepalive (LMI), DLCI.
    • Komenda [show frame-relay map] wyświetla informacje o:
      • Statycznym mapowaniu adresu następnego przeskoku do DLCI.

    Dodatkowe zagadnienia związane z troubleshooting-iem połączeń Frame Relay

    • W przypadku domyślnej konfiguracji połączenia Frame Relay, urządzenie nie jest wstanie za pingować na adres IP własnego interfejsu serialowego. Dzieje się tak ponieważ:
      • 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.

    Pozostałe tematy związane z protokołem Frame Relay

  • (T) Teoria Frame Relay**

    (T) Teoria Frame Relay**

    Zagadnienia związane z protokołem Frame Relay

    Konfiguracja protokołu Frame Relay została opisana w artykule: Konfiguracja Frame Relay.

    • Cost – Protokół Frame Relay stanowi alternatywę dla drogich połączeń dzierżawionych (Leased lines).
    • LMI (Local Management Interface) – Wymienia wiadomość Keepalive utrzymujące kontakt pomiędzy urządzeniem dostawcy ISP DCE (Data Communication Equipment) a ruterem klienta DTE (Data Terminal Equipment). Funkcja LMI wspiera trzy standardy: Cisco, ANSI oraz q933a. O tym który z nich będzie wykorzystany podczas danej sesji protokołu Frame Relay, decyduje mechanizm auto wykrywania (Autosense). Wysyła on wiadomości we wszystkich dostępnych standardach LMI, oczekując odpowiedzi w standardzie wspieranym przez sąsiednie urządzenie.
    • Mechanizm Autosense jest aktywowany gdy:
      • Interfejs sieciowy znajduje się w stanie up/down.
      • Interfejs  jest skonfigurowany jako zakończenie DTE.
      • Standart LMI nie jest statycznie skonfigurowany.
    Powyżej wspomniane pojęcia DTE oraz DCE nie odnoszą się do rodzaju zakończenia kabla serialowego.
    Wiadomości LMI inquiry są wysyłane jedynie przez urządzenie DTE, w odpowiedzi na które urządzenie DCE wysyłają wiadomości LMI Status Response. Jeżeli obydwa urządzenia posiadają domyślną konfigurację (DTE) interfejs serialowy jednego z urządzeń, będzie znajdować się w stanie (up / down (looped)). Ponieważ wiadomość LMI inquiry wysłana przez urządzenie pierwsze (1) zostanie porzucona przez sąsiada (Urządzenie DTE nigdy nie powinno takiej otrzymać) jego interfejs pozostanie w stanie (up / down). Następnie urządzenie drugie (2) wyśle własną wiadomość LMI inquiry, która zostanie odebrana przez urządzenie pierwsze (1) jako zapętlenie łącza (up / down (looped)).
    Połączenie Frame Relay z dwoma urządzeniami DTE można nawiązać jedynie poprzez wyłączenie funkcji KeepAlive.
    • Virtual Circuits – Protokół Frame relay prowadzi komunikację (Connection-Oriented data link layer), nawiązując połączenia pomiędzy dwoma urządzeniami na podstawie numerów identyfikacyjnych DLCI (Data-Link Connection Identifier), w sieci pakietowej PSN (Packet-Switched Network). Wirtualne połączenia (Virtual Circuits) dzielą się na:
      • SVC (Switched Virtual Circuits) – Tymczasowe połączenia Frame Relay wykorzystywane w sytuacjach wymagających jedynie sporadycznego przesyłania danych pomiędzy urządzeniami DTE. Sesja komunikacyjna składa się ze stanów:
        • Call setup – Połączenie Virtual Circuits zostało nawiązane pomiędzy dwoma urządzeniami DTE.
        • Data transfer – Dane są przesyłane pomiędzy urządzeniami DTE poprzez Virtual Circuits.
        • Idle – Połączenie pomiędzy urządzeniami jest aktywne, jednak żadne dane nie są przesyłane. Jeżeli stan ten utrzyma się przez określony czas, status połączenia zostanie zmieniony na  „Call termination”.
        • Call termination – Połączenie pomiędzy urządzeniami DTE zostało zawieszone.
      • PVC (Permanent Virtual Circuits) – Stabilne połączenie Frame Relay, aktywne nawet w przypadku braku ruchu sieciowego pomiędzy dwoma urządzeniami DTE. Sesja komunikacyjna składa się ze stanów:
        • Data transfer – Dane są przesyłane pomiędzy urządzeniami DTE poprzez Virtual Circuits.
        • Idle – Połączenie pomiędzy urządzeniami jest aktywne, jednak żadne dane nie są przesyłane. Utrzymanie tego stanu nie ma wpływu na połączenie Frame Relay.
    • DLCI (Data-Link Connection Identifier) – Identyfikuje jedną stronę połączenia wirtualnego (Virtual Circuits).
    • IARP (Inverse Address Resolution Protocol) – Umożliwia wykrycie adresu następnego przeskoku, należącego do konfigurowanego połączenia DLCI. Automatycznie tworząc odpowiednie mapowanie (DLCI to Next hop IP address), które domyślnie jest konfigurowane za pomocą komendy [frame-relay map ip adres-IP DLCI]. W systemie Cisco IOS możliwość automatycznego wykrycia adresu następnego przeskoku, wymaga wstępnego określenia enkapsulacji na obydwóch urządzeniach DTE za pomocą komendy [encapsulation frame-relay] wydanej w trybie konfiguracji interfejsu serialowego.
      • Protokół IARP wysyła na interfejsach serialowych ramkę powitalną, informującą sąsiednie urządzenia o swoim adresie MAC oraz adresie IP. W odpowiedzi oczekując informacji o swoich sąsiadach.
      • Istnieje możliwość wyłączenia protokołu IARP za pomocą komendy [no frame-relay Inverse-arp] wydanej w trybie konfiguracji interfejsu serialowego, jednak nie istnieje możliwość zablokowania odpowiedzi na ramkę IARP.

    Parametry protokołu Frame Relay negocjowane z dostawcą ISP

    • Parametry transmisji – Parametry negocjonowane pomiędzy klientem a dostawcą ISP:
      • CIR (Committed Information Rate) – Określa minimalną przepustowość łącza Frame Relay, gwarantowaną przez dostawcę ISP względem określonego połączenia Virtual Circuits.
      • EIR (Excess Information Rate) – Określa maksymalną przepustowość łącza Frame Relay, dla danego klienta.
    • Mechanizmy sterowania przeciążeniami – Kontrolą przeciążeń zajmują się po części urządzenie DCE oraz DTE. W sytuacji przekroczenia uzgodnionej wartości EIR urządzenie DCE ostrzerze DTE najczęściej jawnie, za pomocą jednobitowych informacji umieszczanych w nagłówku ramki Ethernet-owej: odbiorcę bitem FECN (Forward Explicit Congestion Notification) a nadawce bitem BECN (Backward Explicit Congestion Notification) Jeżeli nadawca DTE nie odpowie na sygnał BECN urządzenie dostawcy ISP (DCE) zacznie porzucać nadmiarowe ramki.
      • CLLM (Consolidated Link Layer Management) – Inny mechanizmy sterowania przeciążeniami.
    • Access Rate – Określa maksymalną przepustowość łącza Frame Relay, gwarantowaną przez ISP.
    • Congestion – Umożliwia monitorowanie wchodzącego jak i wychodzącego ruchu sieciowego. Składa się z:
      • DE (Discard Eligibility) – Bitu nagłówka umożliwiającego wykrycie jak dużo ramek zostało porzuconych.
      • FECN (Forward Explicit Congestion Notification) – Bitu nagłówka urządzenia nadającego, zawierającego prośbę by urządzenie odbiorcze zmniejszyło ilość zapytań o dane.
      • BECN (Backward Explicit Congestion Notification) – Bitu nagłówka urządzenia odbiorczego, zawierającego prośbę by urządzenie nadające wysyłało dane wolniej.

    Frame Relay Nonbroadcast Multiple Access

    • Sieć Frame Relay jest siecią NBMA, co oznacza że ruch rozgłoszeniowy nie jest obsługiwany. Dokładnie rzecz ujmując przełączniki Frame Relay nie przejmują się przesyłanym ruchem, co oznacza że nie mogą go zareplikować, tworząc z jednego pakietu wielu pakietów. Opcjonalna komenda „broadcast” wykorzystywana w mapowaniu DLCI, omija to ograniczenie tworząc oddzielne ramki unicast względem każdego sąsiedniego urządzenia (Z punktu widzenia urządzenia lokalnego zostanie wysłany jeden pakiet ale dwie ramki Ethernet-owe).

    Pozostałe tematy związane z protokołem Frame Relay

  • (K) Frame Relay Point to Point*

    (K) Frame Relay Point to Point*

    Konfiguracja Frame Relay

    Konfiguracja Point to Point Frame Relay

    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.

    (config-if)# frame-relay lmi-type {cisco / ansi / q933a}(cisco)

    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.

    (config-if)# frame-relay interface-dlci 16-1007(DLCI konfigurowanego interfejsu)

    Przypisuje określoną w komendzie wartość DLCI, do konfigurowanego interfejsu serialowego.

    (config-if)# [no] shutdown

    Aktywuje / Dezaktywuje konfigurowany interfejs serialowy.

    Point to Point Frame Relay (Subinterface)

    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.

    (config-if)# frame-relay lmi-type {cisco / ansi / q933a}(cisco)

    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.

    (config-subif)# frame-relay interface-dlci 16-1007(DLCI konfigurowanego interfejsu)

    Przypisuje określoną w komendzie wartość DLCI, do konfigurowanego pod-interfejsu serialowego.

    (config-subif)# [no] shutdown

    Aktywuje / Dezaktywuje konfigurowany interfejs serialowy.

    Opcjonalne komendy Frame Relay

    (config)# interface serial interfejs

    Przechodzi do poziomu konfiguracji określonego interfejsu serialowego.

    (config-if)# [no] keepalive

    Wyłącza / Włącza funkcją Keepalive (LMI).

    (config-if)# [no] frame-relay Inverse-arp

    Wyłącza / Włącza protokół Inverse ARP.

    Komendy SHOW oraz CLEAR

    Komendy show

    # show frame-relay pvc

    Wyświetla szczegółowe informacje związane z połączeniami Virtual Circuits.

    # show frame-relay pvc | include PVC

    Wyświetla status połączeń Virtual Circuits.

    # show frame-relay map

    Wyświetla mapowanie lokalnego interfejsu oraz wartości DLCI, do adresu IP sąsiedniego urządzenia.

    # show frame-relay lmi

    Wyświetla wykorzystywany standard testowania połączenia (Keepalive).

    Komendy clear frame-relay

    # clear frame-relay inarp

    Czyści dynamicznie wyuczone mapowanie DLCI do adresów IP (IARP).

    Pozostałe tematy związane z protokołem Frame Relay