PIM-SM VPN-ის გავლით: BSR-ის, RP ასახვისა და RPF მარშრუტების შემოწმება

გვირაბი მუშაობს, unicast ping-ები მასში გადის, მიმღები კი მაინც შავ ეკრანს აჩვენებს. PIM-SM-ის განლაგებაში ეს სიმპტომი თითქმის ყოველთვის ნიშნავს, რომ ოთხი მართვის გზიდან ერთი გატეხილია და მონაცემთა გზა არასოდეს ყოფილა პრობლემა. გაიარეთ ქვემოთ მოცემული სია თანმიმდევრობით და შეჩერდით პირველ წარუმატებელ საფეხურზე, რადგან ყოველი შემდგომი საფეხური წინაზეა დამოკიდებული. მე ეს ხუთი შემოწმება მონახაზის ფაილში მაქვს და ტერმინალში ვაკოპირებ, როცა multicast-ის ჩივილი შემოდის, რაც დიაგნოზის გამოცნობად გადაქცევას ხელს უშლის.

დაიწყეთ მიმღებით და არა გვირაბით

მიმღები, რომელსაც ჯგუფი არასოდეს მოუთხოვია, არცერთ როუტერზე მდგომარეობას არ ქმნის, ამიტომ სანამ რაიმე სხვას შეამოწმებთ, დაადასტურეთ, რომ გაწევრიანება მიმღებისკენ მიმართულ სეგმენტში არსებობს. Cisco-ს ტიპის პლატფორმებზე ბოლო ნახტომის როუტერზე show ip igmp groups ბეჭდავს გაწევრიანებულ ჯგუფებს იმ ინტერფეისის გვერდით, რომელმაც ისინი გაიგო. როცა ჯგუფი ამ გამოტანაში არ არის, გვირაბი ყურადღების გადატანაა: მოთხოვნა მოკვდა წვდომის კომუტატორზე, ჰოსტის სოკეტზე ან VLAN-ში querier-ის გარეშე.

ორი ჩვეულებრივი მიზეზი ხსნის ჩემ მიერ ნანახ დაკარგული გაწევრიანებების უმეტესობას: IGMP ვერსიის შეუთანხმებლობა ჰოსტსა და როუტერს შორის, და querier-ის არჩევა, რომელიც ისეთ კომუტატორზე მოხვდა, რომელიც არ მარშრუტიზაციას აკეთებს. მესამე უფრო დახვეწილია: ჯგუფში გაწევრიანებაა, მაგრამ არასწორ VLAN-ში, რადგან ჰოსტს ორი ქსელური ბარათი აქვს და აპლიკაცია არასწორს დაუკავშირდა. IPv6 მიმღებებს იგივე პრობლემა აქვთ MLD-სთან, სადაც show ipv6 mld groups იმავე კითხვას პასუხობს. არცერთი მათგანი გვირაბზე შეხებით არ სწორდება და სწორედ ამიტომ არის თანმიმდევრობა მნიშვნელოვანი.

როგორც კი გაწევრიანება ჩანს, დაადასტურეთ, რომ PIM ჩართულია როგორც მიმღებისკენ მიმართულ ინტერფეისზე, ისე შეხვედრის წერტილისკენ მიმავალ ინტერფეისზე. როუტერი, რომელსაც IGMP წევრობა აქვს, მაგრამ ზედა ინტერფეისზე PIM არ აქვს, ჯგუფს ლოკალურ ცხრილში შეინახავს და არსად არაფერს გაგზავნის.

აღწევს BSR-ის ნაკრები მეორე მხარეს?

Bootstrap Router შეტყობინებები ერთი PIM დომენის შიგნით ნახტომ-ნახტომ მოძრაობს და სწორედ ეს მიმართულება იტეხება გვირაბის გავლით. კანდიდატი RP-ები თავიანთ განცხადებებს არჩეულ BSR-ს unicast-ით უგზავნიან, ამიტომ RP-დან BSR-მდე მონაკვეთი ჩვეულებრივ უცვლელად გადაურჩება მოქმედ გვირაბს. Bootstrap შეტყობინებების ნაკადი საპირისპირო მიმართულებით დამოკიდებულია იმაზე, რომ ყოველ შუალედურ ინტერფეისზე PIM იყოს ჩართული და რომ არაფერი აჩერებდეს შეტყობინებებს საზღვარზე. RFC 5059 განსაზღვრავს ამ გავრცელებას და ადმინისტრაციული არეალის იმ საზღვრებს, რომელთაც მისი შემოკლება შეუძლიათ.

ip pim bsr-border განაცხადი, 103 პროტოკოლის ფილტრავი ACL, ან პოლიტიკაზე დაფუძნებული IPsec გვირაბი, რომელსაც multicast-ის ტარება არ შეუძლია, თითოეული ნაკადს გაჭრის, ხოლო unicast უვნებელი დარჩება. სწორედ ეს კომბინაცია ხდის ხარვეზს RP-ის პრობლემის მსგავსს, მაშინ როცა სინამდვილეში ეს ხელმისაწვდომობის პრობლემაა, და ამიტომაც ვკითხულობ BSR-ის მდგომარეობას RP-ის კონფიგურაციამდე.

მეორე მხარის როუტერზე show ip pim bsr-router ასახელებს არჩეულ BSR-ს და ნასწავლ RP-ის ნაკრებს; თუ გამოტანა ცარიელია, მეორე მხარე საკუთარ დომენში ზის და RP-ის ვერც ერთი კონფიგურაცია ვერ შეარიგებს ორივეს. შეადარეთ ჯგუფების დიაპაზონები და RP-ის მისამართები show ip pim rp mapping-ის გამოტანაში გვირაბის ორივე მხარეს. მხოლოდ ლოკალურად არსებული ასახვა წარმოქმნის საერთო ხეს, რომელიც არასწორ ადგილას მთავრდება, და მიმღები უსასრულოდ ელოდება.

შეათანხმეთ RP-ის ასახვა გვირაბის ორივე მხარეს

სტატიკური RP, BSR და anycast-RP ერთი და იმავე კითხვის სამი პასუხია და მათი გვირაბის გავლით შერევა საიმედო გზაა იმ დომენის ასაშენებლად, რომელიც არასოდეს თანხვდება. თუ თავისი ბოლო იყენებს BSR-ს, ხოლო ფილიალი — სხვა მისამართზე მითითებულ სტატიკურ ip pim rp-address-ს, ფილიალი თავის საერთო ხეს RP-ისკენ აშენებს, რომელმაც არ იცის მიმღების არსებობა. ასახვა უნდა ემთხვეოდეს როგორც ჯგუფის დიაპაზონს, ისე მისამართს, რადგან უფრო კონკრეტული დიაპაზონი ფართოს იმარჯვებს.

Anycast-RP სწორედ იმისთვის არსებობს, რომ ორმა საიტმა ერთი RP მისამართი გაიზიაროს, და ღირს აქ მისი დასახელება, რადგან ის ცვლის იმას, რასაც «იგივე RP» ნიშნავს. ორი RP, რომლებიც ერთ მისამართს აცხადებენ, დიზაინით თანმიმდევრულია; ორი RP, რომლებიც ერთი და იმავე დიაპაზონისთვის სხვადასხვა მისამართს აცხადებენ, ასეთი არ არის, რაც არ უნდა ჯანსაღად გამოიყურებოდეს თითოეული საიტი ცალკე.

232.0.0.0/8-ის შიგნით წყაროსპეციფიკური multicast-ისთვის RP-ს არასოდეს ეკითხებიან, ამიტომ ცარიელი RP ასახვა ავტომატურად ხარვეზი არ არის. გადაწყვიტეთ, რომელ მომსახურების მოდელს იყენებს აპლიკაცია, სანამ RP-ს დაედევნებით, რომელიც არასოდეს ყოფილა საჭირო.

წაიკითხეთ RPF-ის ძებნა წყაროსკენ

PIM ხეს unicast გზის შებრუნებით აშენებს, ამიტომ მთავარი შემოწმება წყაროსკენ უკან მიმავალი მარშრუტია, ან საერთო ხისთვის RP-ისკენ უკან მიმავალი. გაწევრიანება, რომელიც ისეთ ინტერფეისზე ჩამოდის, რომელსაც როუტერი ზედა არ თვლის, იგდება და მიზეზი RPF-ის ჩავარდნად აღირიცხება და არა გვირაბის ჩავარდნად. ფილიალის როუტერზე, რომელსაც გვირაბზე ნაგულისხმევი მარშრუტი და WAN-ზე უფრო კონკრეტული მარშრუტი აქვს, RPF-ის ინტერფეისი ადვილად შეიძლება WAN იყოს, თუმცა წყარო მხოლოდ გვირაბით მისაწვდომია. ეს არის ყველაზე გავრცელებული ერთადერთი მიზეზი, რის გამოც გაწევრიანება ჩუმად იგდება.

show ip rpf 192.0.2.10 ბეჭდავს არჩეულ ინტერფეისს, შემდეგ ნახტომს და იმ მარშრუტს, რომელმაც გადაწყვეტილება წარმოქმნა, და ეს ჩვეულებრივ საკმარისია შეუსაბამობის სანახავად. სტატიკური multicast მარშრუტი, როგორიც ip mroute 192.0.2.0 255.255.255.0 tunnel0-ია, გვერდს უვლის unicast ძებნას ამ პრეფიქსისთვის და ეს ლეგიტიმური შესწორებაა, როცა multicast ტოპოლოგია ნამდვილად განსხვავდება unicast ტოპოლოგიისგან. მოეპყარით მას როგორც დოკუმენტირებად კონფიგურაციას და არა როგორც ინციდენტის დროს დადებულ და შემდეგ დავიწყებულ ლაქას.

დაადასტურეთ გაწევრიანება ბრძანებებით და არა ping-ით

Ping ამტკიცებს, რომ unicast მუშაობს, რაც უკვე იცოდით. ბოლოდან ბოლომდე დადასტურება არის მიმდევრობა, რომელიც გაწევრიანებას, ასახვას, მეზობელს და ხეს სწორედ ამ რიგით აჩვენებს და ყოველი ბრძანება სხვა კითხვას პასუხობს.

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

შევსებული (S,G) ჩანაწერი ნამდვილი შემავალი ინტერფეისით და არაცარიელი გამავალი სიით ნიშნავს, რომ მართვის სიბრტყემ თავისი საქმე დაამთავრა. ჩანაწერი, რომლის შემავალი ინტერფეისი Null-ად იკითხება, ან RPF failed იარლიყის მთვლელი, რომელიც განუწყვეტლივ იმატებს, უკან წინა განყოფილებაზე მიუთითებს და არა გვირაბზე.

თუ ხუთივე ბრძანება სწორად გამოიყურება და მიმღები მაინც ვერაფერს ხედავს, დარჩენილი ეჭვმიტანილი თავად გვირაბის პოლიტიკაა: კრიპტო ACL ან firewall-ის წესი, რომელიც unicast მარშრუტიზაციის პროტოკოლს უშვებს, მაგრამ PIM-ს, IGMP-ს ან თავად ჯგუფის ტრაფიკს არა. პოლიტიკაზე დაფუძნებულ IPsec გვირაბში multicast საერთოდ არ გადაიცემა, ამიტომ პასუხი GRE-ს ან VTI-ის დიზაინია და არა ფილტრის კიდევ ერთი გამონაკლისი. ჩაწერეთ, ხუთი შემოწმებიდან რომელი ჩავარდა, სანამ რამეს შეცვლით, შემდეგ შეცვალეთ მხოლოდ ის ფენა.