EIGRP qonşusu, yoxsa DMVPN tranziti? Əvvəlcə rolu yoxlayın

Qonşuluq yoxdur və ortadakı marşrutlaşdırıcı aşkar şübhəli kimi görünür. O, günahsız ola bilər. Xarici tunel paketlərini ötürmək və overlay marşrutlaşdırma protokolunda iştirak etmək iki fərqli işdir və cihaz birincini ikincisini etmədən görə bilər. Aşağıdakı beş yoxlamanı ardıcıllıqla aparın və ilk uğursuz olanında dayanın.

Addım 1: iki rolu çəkin

Nəzərdə tutulan EIGRP qonşuluğunu iki marşrutlaşdırıcı arasında məntiqi əlaqə kimi çəkin, sonra onun tunel paketlərini daşıyan underlay marşrutlaşdırıcılarını çəkin. Eyni cihaz hər iki siyahıda görünməməlidir və siyahıları qarışdırmaq sağlam tranzit marşrutlaşdırıcısının qonşuluğu pozmaqda günahlandırılmasının ən geniş yayılmış səbəbidir.

Tranzit marşrutlaşdırıcı xarici paketləri adi IP marşrutlaşdırması və siyasəti ilə ötürür. Qorunan tunelin içində daşınan protokolu işlətməsinə ehtiyac yoxdur və bu paketləri ötürmək üçün EIGRP prosesinə də ehtiyacı yoxdur.

Addım 2: orta cihazın nəyi sonlandırdığını yoxlayın

Əgər orta marşrutlaşdırıcı tuneli sonlandırır və spoke-larla EIGRP qonşuluqları yaratmalıdırsa, cavab tamamilə dəyişir. Həmin cihaz dəstəklənən overlay marşrutlaşdırma davranışına ehtiyac duyur və onu tranzit adlandırmaq qonşu tələbini aradan qaldırmır. Tunel konfiqurasiyasını marşrutlaşdırma konfiqurasiyasından əvvəl oxuyun. Bu cavab sonrakı bütün yoxlamaları müəyyən edir.

Deməli, ilk real sual hansı protokolu tənzimləmək deyil. Sual budur: qutu hub, spoke, təmiz underlay hop, yoxsa son nöqtələr arasında kadr daşıyan Layer 2 xidmətidir.

Addım 3: qonşunun idarəetmə müstəvisini yoxlayın

Qonşu olmalı olan hər cihazda dörd şeyi təsdiqləyin: EIGRP nüsxəsi və avtonom sistem nömrəsi, autentifikasiya parametrləri, prosesdə iştirak edən interfeys və həmin interfeysi əhatə edən şəbəkə ifadəsi. Bunlardan hər hansı birində uyğunsuzluq interfeys işlək qalarkən və ping davam edərkən qonşuluğu aşağıda saxlayır.

RFC 7868 EIGRP-ni multicast idarəetmə mübadiləsi olan IP protokolu kimi təsvir edir, buna görə də qonşu münasibəti ara marşrutlaşdırıcının paketləri təyinat istiqamətinə yönləndirməklə vəkil edə biləcəyi bir şey deyil. Ya idarəetmə mübadiləsi həmyaşıda çatır, ya da qonşuluq yaranmır.

Addım 4: nəqliyyatın idarəetmə mübadiləsini çatdırdığını yoxlayın

Sonra, overlay-ın idarəetmə trafikini nəzərdə tutulan son nöqtələr arasında həqiqətən daşıdığını yoxlayın. Həmyaşıd üçün NHRP xəritələnməsini və ona çatan xarici marşrutu yoxlayın, sonra tunel interfeysinin işlək olduğunu və trafik keçirdiyini təsdiqləyin. Uğurlu underlay ping-i xarici yolun mövcud olduğunu sübut edir; overlay idarəetmə mübadiləsinin çatdırıldığını sübut etmir.

Şəffaf Layer 2 xidməti, nöqtədən-nöqtəyə tunel və çoxnöqtəli DMVPN buludu multicast-ı fərqli çatdırır. Üçünün də eyni davrandığını fərz etmək əvəzinə faktiki yerləşdirilmiş model üçün dəstəklənən interfeys, NHRP və multicast modelini izləyin.

Addım 5: iştirak edə bilmirsə, sərhədi yenidən layihələndirin

Tələb olunan overlay cihazı protokolu işlədə bilmirsə, dizaynı açıq şəkildə dəyişin. Həmin sərhəddə dəstəklənən protokol və ya mübadilə modeli istifadə edin, və ya qonşuların bir-biri ilə həqiqətən danışan son nöqtələr olması üçün uyğun ucdan-uca tunel təşkil edin. Statik marşrutun iştirak etməyəni hər idarəetmə paketi üçün rele çevirdiyini fərz etməyin.

Diaqramda hər cihazın rolunu qeyd edin və konfiqurasiya ilə birlikdə saxlayın. RFC 7868 protokol mübadiləsinin tərifi qonşu münasibətinin tranzit yönləndirmə ilə təqlid edilə bilməməsinin səbəbi üçün istinaddır.

Qonşuluq bütün beş yoxlamadan sonra da uğursuz olarsa, qalan şübhəlilər tunel interfeysində multicast emalı və 88 protokolunu süzən siyasət kimi platforma xüsusiyyətləridir. Bunlar konkret, yoxlanıla bilən səbəblərdir və ortadakı marşrutlaşdırıcını günahlandırmağın növbəti raundundan daha dəyərlidirlər.