VPN üzərində PIM-SM: BSR, RP xəritələnməsi və RPF yollarını yoxlayın
VPN üzərindən PIM-SM hansı idarəetmə yolunun çatışmadığına görə uğursuz olur. IGMP üzvlüyünü, BSR əhatəsini, RP xəritələnməsini və RPF qonşularını bu ardıcıllıqla işləyin.
Tunel işləyir, unicast ping-lər ondan keçir, lakin qəbuledici hələ də qara ekran göstərir. PIM-SM qurulumunda bu simptom demək olar ki, həmişə dörd idarəetmə yolundan birinin sındığını bildirir və məlumat yolu heç vaxt problem olmayıb. Aşağıdakı siyahını sıra ilə işləyin və uğursuz olan ilk addımda dayanın, çünki hər sonrakı addım özündən əvvəlkindən asılıdır. Mən bu beş yoxlamanı bir qaralama faylında saxlayıram və multicast şikayəti gələndə terminala yapışdırıram ki, diaqnoz təxminə çevrilməsin.
Tuneldən deyil, qəbuledicidən başlayın
Qrup üçün heç vaxt sorğu göndərməmiş qəbuledici heç bir marşrutlaşdırıcıda vəziyyət yaratmır, ona görə başqa heç nəyi yoxlamazdan əvvəl qoşulmanın qəbulediciyə baxan seqmentdə mövcud olduğunu təsdiqləyin. Cisco üslublu platformalarda son hop marşrutlaşdırıcısında show ip igmp groups qoşulmuş qrupları onları eşidən interfeysin yanında çap edir. Qrup bu çıxışda yoxdursa, tunel diqqəti yayındırır: sorğu giriş kommutatorunda, host soketində və ya sorğu göndərəni olmayan VLAN-da ölüb.
Gördüyüm itkin qoşulmaların çoxunu iki adi səbəb izah edir: host ilə marşrutlaşdırıcı arasında IGMP versiya uyğunsuzluğu və marşrutlaşdırma etməyən kommutatora düşən sorğu seçkisi. Üçüncüsü daha incədir: qrup qoşulub, lakin yanlış VLAN-dadır, çünki hostun iki şəbəkə kartı var və tətbiq yanlışına bağlanıb. IPv6 qəbuledicilərində MLD ilə eyni problem var, burada show ipv6 mld groups həmin suala cavab verir. Bunların heç biri tunelə toxunmaqla düzəlmir və sıranın əhəmiyyəti məhz bundadır.
Qoşulma görünən kimi PIM-in həm qəbulediciyə baxan interfeysdə, həm də görüşmə nöqtəsinə aparan interfeysdə aktiv olduğunu təsdiqləyin. IGMP üzvlüyü olan, lakin yuxarı interfeysində PIM olmayan marşrutlaşdırıcı qrupu yerli cədvəldə saxlayacaq və heç yerə heç nə göndərməyəcək.
BSR dəsti uzaq tərəfə çatırmı?
Bootstrap Router mesajları tək PIM domeni daxilində hop-hop hərəkət edir və tunel üzərindən sınan istiqamət elə budur. Namizəd RP-lər öz reklamlarını seçilmiş BSR-ə unicast ilə göndərir, ona görə RP-dən BSR-ə qədər hissə işləyən tuneldə adətən dəyişməz qalır. Digər istiqamətdə Bootstrap mesajlarının axını hər aralıq interfeysin PIM aktiv olmasından və heç nəyin mesajları sərhəddə dayandırmamasından asılıdır. RFC 5059 həmin paylanmanı və onu kəsməyə icazə verilən inzibati əhatə sərhədlərini müəyyən edir.
ip pim bsr-border ifadəsi, 103 protokolunu filtrləyən ACL və ya multicast daşıya bilməyən siyasət əsaslı IPsec tuneli hər biri unicast toxunulmaz qalmaqla axını kəsəcək. Bu birləşmə nasazlığı əslində əlçatanlıq problemi olduğu halda RP problemi kimi göstərir və BSR vəziyyətini RP konfiqurasiyasından əvvəl oxumağımın səbəbi də budur.
Uzaq tərəfdəki marşrutlaşdırıcıda show ip pim bsr-router seçilmiş BSR-i və öyrəndiyi RP dəstini göstərir; çıxış boşdursa, uzaq tərəf öz domenində oturur və heç bir RP konfiqurasiyası ikisini uzlaşdıra bilməz. Tunelin hər iki tərəfində show ip pim rp mapping çıxışında qrup aralıqlarını və RP ünvanlarını müqayisə edin. Yalnız yerli mövcud olan xəritələnmə səhv yerdə bitən paylaşılan ağac yaradır və qəbuledici əbədi gözləyir.
RP xəritələnməsini tunelin hər iki tərəfində uyğunlaşdırın
Statik RP, BSR və anycast-RP eyni suala cavab verməyin üç yoludur və onları tunel üzərindən qarışdırmaq heç vaxt yaxınlaşmayan domen qurmağın etibarlı yoludur. Əgər başlanğıc tərəf BSR istifadə edirsə, filial isə fərqli ünvana işarə edən statik ip pim rp-address istifadə edirsə, filial paylaşılan ağacını qəbuledicinin varlığından xəbərsiz RP-yə doğru qurur. Xəritələnmə ünvanda olduğu kimi qrup aralığında da uyğun olmalıdır, çünki daha dəqiq aralıq daha genişə qalib gəlir.
Anycast-RP məhz iki saytın bir RP ünvanını paylaşması üçün mövcuddur və burada adını çəkməyə dəyər, çünki «eyni RP» anlayışını dəyişir. Bir ünvanı reklam edən iki RP dizayn baxımından uzlaşandır; eyni aralıq üçün fərqli ünvanlar reklam edən iki RP isə deyil, hər sayt öz-özlüyündə nə qədər sağlam görünsə də.
232.0.0.0/8 daxilində mənbəyə xas multicast üçün RP-yə heç vaxt müraciət edilmir, ona görə boş RP xəritələnməsi avtomatik nasazlıq sayılmır. Heç vaxt lazım olmayan RP-nin arxasınca düşməzdən əvvəl tətbiqin hansı xidmət modelindən istifadə etdiyini müəyyənləşdirin.
RPF axtarışını mənbəyə doğru oxuyun
PIM ağacı unicast yolunu tərsinə çevirməklə qurur, ona görə vacib yoxlama mənbəyə, paylaşılan ağac üçün isə RP-yə geri gedən marşrutdur. Marşrutlaşdırıcının yuxarı hesab etmədiyi interfeysdən gələn qoşulma atılır və səbəb tunel nasazlığı kimi deyil, RPF nasazlığı kimi qeyd olunur. Tunel üzərindən default marşrutu və WAN üzərindən daha dəqiq marşrutu olan filial marşrutlaşdırıcısında RPF interfeysi asanlıqla WAN ola bilər, hərçənd mənbəyə yalnız tunel vasitəsilə çatmaq olur. Bu, qoşulmanın səssizcə atılmasının ən çox yayılmış yeganə səbəbidir.
show ip rpf 192.0.2.10 seçilmiş interfeysi, növbəti hopu və qərarı verən marşrutu çap edir, bu da adətən uyğunsuzluğu görmək üçün kifayətdir. ip mroute 192.0.2.0 255.255.255.0 tunnel0 kimi statik multicast marşrutu həmin prefiks üçün unicast axtarışını üstələyir və multicast topologiyası unicast topologiyasından həqiqətən fərqlənəndə qanuni düzəlişdir. Ona sənədləşdirilməli konfiqurasiya kimi yanaşın, insident zamanı tətbiq edilib sonra unudulan yamaq kimi deyil.
Qoşulmanı ping ilə deyil, əmrlərlə təsdiqləyin
Ping unicast-ın işlədiyini sübut edir, bunu artıq bilirdiniz. Başdan sona təsdiq qoşulmanı, xəritələnməni, qonşunu və ağacı bu sıra ilə göstərən ardıcıllıqdır və hər əmr fərqli suala cavab verir.
show ip igmp groups 239.1.1.1 show ip pim rp mapping show ip pim neighbor show ip rpf 192.0.2.10 show ip mroute 239.1.1.1
Həqiqi gələn interfeysi və boş olmayan çıxan siyahısı olan doldurulmuş (S,G) qeydi idarəetmə müstəvisinin işini bitirdiyini bildirir. Gələn interfeysi Null oxunan qeyd və ya durmadan artan RPF failed etiketli sayğac tunelə deyil, əvvəlki bölməyə işarə edir.
Beş əmrin hamısı doğru görünürsə və qəbuledici hələ də heç nə görmürsə, qalan şübhəli tunelin öz siyasətidir: unicast marşrutlaşdırma protokoluna icazə verən, lakin PIM, IGMP və ya qrup trafikinin özünə icazə verməyən kripto ACL və ya firewall qaydası. Siyasət əsaslı IPsec tunelində multicast ümumiyyətlə daşınmır, ona görə cavab növbəti filtr istisnası deyil, GRE və ya VTI dizaynıdır. Nəyisə dəyişməzdən əvvəl beş yoxlamadan hansının uğursuz olduğunu yazın, sonra yalnız o qatı dəyişin.