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

Faza 1-3

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-SpokeFaza 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-SpokeFaza 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-SpokeFaza 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 skierowany na ten sam tunel z którego ruch ten został odebrany, co w terminologii protokołu DMVPN nazywane jest mianem ruchu Hairpinning. Umożliwia on 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

PDFPRINT

Robert T Kucharski

Cisco Network Engineer in GPW.

Dodaj komentarz