Więcej

    Redystrybucja między OSPF a EIGRP [WYZWANIE]

    spot_img

    Jakiś czas temu otrzymałem od jednego z Czytelników ciekawy scenariusz do przelabowania i wytłumaczenia. PDF z rozpiską troszkę u mnie przeleżał, ale w końcu się do niego zabrałem i poniżej dzielę się z Tobą rezultatami mojego „dochodzenia”. Zachęcam Cię do przelabowania tego scenariusza na własną rękę i dojścia do konkluzji zanim jeszcze przeczytasz przygotowane przeze mnie rozwiązanie.

    Topologia

    Topologia jest relatywnie prosta i składa się z czterech routerów połączonych jak na obrazku poniżej:

    Mamy tu do czynienia z dwiema domenami routingu – z wykorzystaniem OSPF oraz EIGRP. Ja całość przelabowałem na obrazach IOSv w EVE-NG i Tobie również polecam użyć to narzędzie.

    Gdy już zbudujesz powyższą topologię, czas przystąpić do konfiguracji.

    Konfiguracja

    Poniżej znajdziesz snippety konfiguracyjne dla każdego z routerów, aby przygotować je pod labowany scenariusz.

    R1

    hostname R1
    !
    interface Loopback1
     ip address 1.1.1.1 255.255.255.255
     no shutdown
    !
    interface GigabitEthernet0/0
     ip address 12.0.0.1 255.255.255.0
     no shutdown
    !
    router eigrp 1
     network 1.1.1.1 0.0.0.0
     network 12.0.0.1 0.0.0.0

    R2

    hostname R2
    !
    interface GigabitEthernet0/0
     ip address 12.0.0.2 255.255.255.0
     no shutdown
    !
    interface GigabitEthernet0/1
     ip address 23.0.0.2 255.255.255.0
     no shutdown
    !
    interface GigabitEthernet0/2
     ip address 24.0.0.2 255.255.255.0
     no shutdown
    !
    router eigrp 1
     network 12.0.0.2 0.0.0.0
      network 23.0.0.2 0.0.0.0
    !
    router ospf 1
     network 23.0.0.2 0.0.0.0 area 0
     network 24.0.0.2 0.0.0.0 area 0

    R3

    hostname R3
    !
    interface GigabitEthernet0/1
     ip address 23.0.0.3 255.255.255.0
     no shutdown
    !
    interface GigabitEthernet0/3
     ip address 34.0.0.3 255.255.255.0
     no shutdown
    !
    router eigrp 1
     network 23.0.0.3 0.0.0.0
     redistribute ospf 1 metric 1 1 1 1 1
    !
    router ospf 1
     redistribute eigrp 1 subnets
     network 23.0.0.3 0.0.0.0 area 0
     network 34.0.0.3 0.0.0.0 area 0

    R4

    hostname R4
    !
    interface Loopback1
     ip address 4.4.4.4 255.255.255.255
     no shutdown
    !
    interface GigabitEthernet0/2
     ip address 24.0.0.4 255.255.255.0
     no shutdown
    !
    interface GigabitEthernet0/3
     ip address 34.0.0.4 255.255.255.0
     no shutdown
    !
    router ospf 1
     network 4.4.4.4 0.0.0.0 area 0
     network 24.0.0.4 0.0.0.0 area 0
     network 34.0.0.4 0.0.0.0 area 0

    Zadanie

    Czas na faktyczne zadanie. A brzmi ono następująco:

    W wyniku fuzji doszło do połączenia ze sobą dwóch organizacji. Młodszy inżynier sieciowy, aby zapewnić pełną łączność, postanowił dokonać podwójnej redystrybucji pomiędzy OSPF i EIGRP na Routerze 3. Aby sprawdzić łączność postanowił spingować 4.4.4.4 z Routera 1. Ping niestety nie działa. Nasz kolega sieciowiec jest bezsilny i pilnie potrzebuje Twojej pomocy. Czy potrafisz wyjaśnić dlaczego R1 nie jest w stanie spingować adresu 4.4.4.4?

    Zanim przejdziemy dalej upewnij się wpierw, że wszystkie interfejsy są up/up i są zaadresowane zgodnie z diagramem. Sprawdź również czy relacje sąsiedztwa są ustanowione.

    Następnie dokonajmy redystrybucji zgodnie z treścią zadania:

    R3(config)#router eigrp 1
    R3(config-router)#redistribute ospf 1 metric 1 1 1 1 1
    
    R3(config)#router ospf 1
    R3(config-router)#redistribute eigrp 1 subnets

    Po zrobieniu takiej redystrybucji ping z R1 do 4.4.4.4 faktycznie nie przechodzi.

    Dlaczego?

    Rozwiązanie

    Szybkie spojrzenie w tablicę routingu na R1 udowadnia, że R1 nie posiada trasy do 4.4.4.4 w tablicy routingu:

    Pytanie natomiast czy EIGRP na R1 wie o 4.4.4.4? Również nie:

    Cofnijmy się w takim razie do punktu redystrybucji czyli R3. Tam jak widać 4.4.4.4 znajduje się już w tablicy topologii EIGRP:

    Czas spojrzeć jak wygląda sytuacja na R2. I tu czeka na nas niespodzianka:

    Widzimy, że Feasible Distance dla 4.4.4.4 to Infinity! R2 co prawda spinguje 4.4.4.4 za sprawą trasy nauczonej za pośrednictwem OSPF, ale już nie przekaże trasy do 4.4.4.4 za pośrednictwem EIGRP do R1.

    Co oznacza „FD is Infinity”?

    Dochodzimy do wytłumaczenia napotkanego problemu. Otóż R2 dowiaduje się o trasie do 4.4.4.4 z dwóch źródeł:

    • z protokołu OSPF, z dystansem administracyjnym 110, oraz
    • ze zredystrybuowanego protokołu EIGRP, zatem jest to trasa EIGRP external, z dystansem administracyjnym 170.

    R2 posiada zatem bardziej „wiarygodną” trasę (tę nauczoną przez OSPF) co powoduje, że proces EIGRP oznacza swoją trasę jako nieużyteczną. Sposobem na takie oznaczenie jest właśnie ustawienie FD jako Infinity. Z tego też powodu trasa ta ostatecznie nie trafia do R1.

    Jak naprawić problem?

    Rozwiązań oczywiście w tym konkretnym przypadku jest wiele – pozwól, że zaprezentuję jedno z nich. Sytuacja ulegnie poprawie jeżeli zmniejszymy dystans administracyjny dla tras EIGRP external na R2 w taki sposób aby był niższy od dystansu OSPF:

    R3(config)#router eigrp 1
    R3(config-router)#distance eigrp 90 100

    W ten sposób zmniejszyliśmy AD tras EIGRP external z 170 do 100, czyli poniżej AD OSPF (110).

    W rezultacie R2 instaluje trasę do 4.4.4.4 w swojej tablicy routingu:

    Dzięki temu R1 nauczy się trasy do R2 i również zainstaluje ją w swojej tablicy routingu:

    Szybki ping potwierdza, że udało się w ten sposób naprawić problem:

    Ciekawy przypadek i dobrze obrazujący ten mechanizm. Jeszcze raz podziękowania za podesłanie tego scenariusza! Jeżeli Ty również masz jakiś ciekawy przypadek warty opisania na łamach „Na Styku Sieci” to nie wahaj się i pisz do nas!

    Zachęcamy również do dołączenia do grona naszych Patronów – zyskując tym samym pierwszeństwo w proponowaniu artykułów i nowych treści!

    No i koniecznie daj znać czy udało Ci się samodzielnie rozwiązać problem i czy udało Ci się znaleźć alternatywne rozwiązanie

    🗳 Jak przydatna była ta publikacja?

    Średnia ocena 5 / 5. Ilość głosów: 7

    Brak ocen. Bądź pierwszy!

    Dziękujemy za ocenę! Zapraszamy Cię do obserwowania NSS w mediach społecznościowych!

    Przykro nam, że ta publikacja okazała się być dla Ciebie nieprzydatna!

    Uwaga: Twój głos będzie liczony tylko jeśli udzielisz feedbacku używając formularza poniżej.

    Jak możemy poprawić tę publikację?

    Damian Michalak
    Network Consultant, Twórca Na Styku Sieci

    2 KOMENTARZE

    guest
    2 - Ilość komentarzy
    Sortuj wg najstarszych
    Sortuj wg najnowszych Sortuj wg najlepszych
    Inline Feedbacks
    View all comments
    Seb

    Miałem przypadek z rzeczywistości przy konieczności podłączenia sieci z RIP na szczęście v2 (czemu RIP hmm… bo 2 switche L3 z routingiem, które trzeba było zapiąć tylko taki protokol obsługiwały) do 2 routerów Cora z EVPN-MPLS w celu uzyskania redundancji (może nie najlepszej ale jakiejkolwiek redundancji). To są te przypadki kiedy praca sieciowca daje wiele satysfakcji – czyli te 10% przypadków z ogółu zajęć – gdzie trzeba się pogłowić żeby rozwiązać konkretny niekoniecznie trywialny problem.

    Przygotowujesz się do certyfikacji CCNA?

    Zapisz się na nasz NSSletter, a co tydzień we wtorek rano otrzymasz porcję sieciowej wiedzy oraz porady dotyczące certyfikacji.

    Uzupełniając powyższe pole wyrażasz zgodę na otrzymywanie od GetGoodNet Damian Michalak z siedzibą we Wrocławiu newslettera zawierającego treści edukacyjne. Zgodę możesz wycofać w każdym czasie.

    NSS na Social Media

    1,611FaniLubię
    72ObserwującyObserwuj
    134ObserwującyObserwuj
    1,220SubskrybującySubskrybuj

    Najnowsze artykuły

    spot_img

    Może Cię też zainteresować...

    2
    0
    Co sądzisz na temat tej publikacji? Zostaw proszę komentarzx
    ()
    x