Podsumowanie tras DMVPN a mapa podsumowania NHRP: różne tabele
Podsumowanie tras zmienia ogłaszany prefiks i następny skok. Mapa podsumowania NHRP zmienia to, co zwraca odpowiedź rozwiązania. To samo słowo, inna tabela.
Ktoś prosi cię o podsumowanie spoke’ów, a zgłoszenie zamyka się z mniejszą liczbą prefiksów na hubie. Tydzień później ruch między oddziałami, który wcześniej szedł bezpośrednio, znowu przechodzi przez hub, i nikt nie łączy tych dwóch zmian. Wyrażenie podsumuj spoke’y obejmuje dwie różne operacje, które dotykają dwóch różnych tabel. Wskaż, który stan redukujesz, zanim pożyczysz polecenie z innego przykładu DMVPN.
Objaw: bezpośredni ruch spoke wrócił do huba
Ta różnica ma największe znaczenie, gdy dyskusję o Phase 2 stosuje się do projektu Phase 3. Te same słowa pojawiają się w obu rozmowach, a wpływ na przekazywanie nie jest taki sam.
Dlatego też zmiana wyglądała poprawnie podczas przeglądu: przegląd sprawdził tabelę routingu, a to tylko jeden z trzech zaangażowanych stanów.
Jedna agregacja, dwie tabele
Obie operacje wyglądają tak:
| Operation | What it actually changes |
|---|---|
| Routing summary | Aggregates the prefixes the routing protocol advertises and changes the next hop the receiver installs |
| NHRP summary map | Changes the network returned in a resolution reply, so a requesting spoke resolves to a different address |
| Protection path | IPsec state for the peer you actually resolved; neither aggregation changes it |
Podsumowanie tras to stwierdzenie o tym, co hub ogłasza i co odbierający spoke instaluje jako trasę. Mapa podsumowania NHRP to stwierdzenie o odpowiedzi, którą spoke wysyła, gdy inny spoke pyta, jak dotrzeć do adresu. To różne pytania z różnymi trybami awarii, a projekt może zmienić jedno, zostawiając drugie dokładnie takim, jakie było. Traktowanie ich jako jednej dźwigni to droga, na której zmiana agregacji po cichu staje się zmianą przekazywania.
Żadna z operacji nie jest stwierdzeniem o ścieżce ochrony, ponieważ jest ona negocjowana dla peera, którego faktycznie rozwiązałeś.
Co faktycznie zmienia podsumowanie na hubie
Przewodnik Cisco po mapach podsumowania NHRP między spoke’ami opisuje układ Phase 3, w którym hub ogłasza podsumowanie i pozostaje następnym skokiem routingu. Przekierowanie i późniejsze rozwiązanie NHRP dają wtedy bardziej bezpośrednią ścieżkę przekazywania. Czytanie samej trasy zagregowanej nie opisuje więc całego stanu przekazywania i nie oznacza, że każdy pakiet musi na zawsze przechodzić przez hub. Podsumowanie dotyczy osiągalności, a nie ścieżki.
Dlatego przegląd projektu, który zatrzymuje się na tabeli routingu, może zatwierdzić zmianę zmieniającą zachowanie rozwiązania. Sprawdź wybraną trasę, wynik NHRP i ścieżkę ochrony jako trzy osobne obserwacje.
Jeśli nie potrafisz powiedzieć, który z trzech się zmienił, nie zakończyłeś zmiany.
Co zmienia mapa podsumowania NHRP
Weź spoke, który posiada 10.32.0.0/19 przez kilka bardziej szczegółowych tras LAN, podczas gdy hub ogłasza większą agregację pozostałym spoke’om. Żądanie 10.32.12.10 otrzymałoby inaczej informację o rozwiązaniu dla pasującej mniejszej sieci. Udokumentowana funkcja mapy podsumowania NHRP pozwala spoke’owi zwrócić zamiast tego skonfigurowany prefiks pokrywający, co może zmniejszyć powtarzaną pracę rozwiązania dla sieci należących do tego spoke’a. Nie czyni to podsumowania tras huba i podsumowania rozwiązania spoke’a tym samym obiektem.
Nadaj temu prefiksowi pokrywającemu przemyślany model własności. Szeroka odpowiedź obejmująca adresy należące gdzie indziej albo luki, które są nieosiągalne, może skierować późniejszy ruch do nieodpowiedniego peera.
Sprawdź rzeczywiste trasy i zamierzone odrzucone przypadki, zanim powiększysz prefiks, a nie po fakcie.
Porównaj pierwsze miejsce docelowe i jedno wewnątrz podsumowania
Wybierz dwa miejsca docelowe: pierwsze, które testowałeś, oraz inne, które leży wewnątrz proponowanego podsumowania. Dla każdego zapisz wybraną trasę, stan NHRP użyty do dotarcia do niego oraz rzeczywistą ścieżkę odpowiedzi. To porównanie mówi, czy zmieniłeś skalę routingu, skalę rozwiązania czy błąd przekazywania, i to jedyny użyteczny wniosek. Wyświetlacz z mniejszą liczbą prefiksów nie jest dowodem żadnego z nich.
Potwierdź wdrożoną fazę i zachowanie następnego skoku protokołu routingu, zanim zastosujesz przykład Phase 3 do swojej sieci. Krótki przykład nie dowodzi, że inny projekt zachowuje tę samą bezpośrednią ścieżkę spoke.
Zgłoszenie powinno mówić, którą tabelę zmniejszyłeś, a którą zostawiłeś w spokoju. Cokolwiek mniej zostanie po miesiącu zdiagnozowane od zera.