როგორ მუშაობს PIM პროტოკოლი

PIM პროტოკოლი არის პროტოკოლების ნაკრები როუტერებს შორის ქსელში მულტიკასტის გადაცემისთვის. სამეზობლო ურთიერთობები აგებულია ისევე, როგორც დინამიური მარშრუტიზაციის პროტოკოლების შემთხვევაში. PIMv2 აგზავნის Hello შეტყობინებებს ყოველ 30 წამში დაჯავშნილ მულტიკასტის მისამართზე 224.0.0.13 (All-PIM-Routers). შეტყობინება შეიცავს Hold Timers - ჩვეულებრივ უდრის 3.5*Hello Timer-ს, ანუ სტანდარტულად 105 წამს.

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

R3 ამოიცნობს multicast წყაროს (Source IP) მულტიკასტის გზავნილიდან და შეამოწმებს ორ ნაკადს R1-დან და R2-დან მისი unicast ცხრილის გამოყენებით. ცხრილის მიერ მითითებული ინტერფეისის ნაკადი (R1-დან R3-მდე) გადაიცემა შემდგომ, ხოლო ნაკადი R2-დან ჩამოიშლება, რადგან მულტიკასტის წყარომდე მისასვლელად, თქვენ უნდა გაგზავნოთ პაკეტები S0/1-ის საშუალებით.
საკითხავია, რა მოხდება, თუ თქვენ გაქვთ ორი ეკვივალენტური მარშრუტი ერთი და იგივე მეტრიკით? ამ შემთხვევაში, როუტერი ამ მარშრუტებიდან შეარჩევს შემდეგ ჰოპს. ვისაც აქვს უფრო მაღალი IP მისამართი, იმარჯვებს. თუ ამ ქცევის შეცვლა გჭირდებათ, შეგიძლიათ გამოიყენოთ ECMP. Უფრო ვრცლად აქ.
RPF წესის შემოწმების შემდეგ, როუტერი აგზავნის მულტიკასტის პაკეტს ყველა PIM მეზობელთან, გარდა იმისა, ვისგანაც ეს პაკეტი მიიღო. სხვა PIM მარშრუტიზატორები იმეორებენ ამ პროცესს. გზა, რომელიც Multicast პაკეტმა გაიარა წყაროდან საბოლოო მიმღებამდე, ქმნის ხეს, რომელსაც ეწოდება წყაროზე დაფუძნებული განაწილების ხე, უმოკლესი ბილიკის ხე (SPT), წყაროს ხე. სამი განსხვავებული სახელი, აირჩიეთ რომელიმე.
როგორ მოვაგვაროთ პრობლემა, რომ ზოგიერთმა მარშრუტიზატორმა არ თქვა უარი ზოგიერთ მულტიკასტის ნაკადზე და არავის აქვს ის, რომლითაც მას გაუგზავნის, მაგრამ ზედა ნაკადის როუტერი უგზავნის მას. ამისთვის გამოიგონეს Prune მექანიზმი.
Prune შეტყობინება.
მაგალითად, R2 გააგრძელებს მულტიკასტის გაგზავნას R3-ზე, თუმცა R3, RPF წესის მიხედვით, ჩამოაგდებს მას. რატომ იტვირთება არხი? R3 აგზავნის PIM Prune შეტყობინებას და R2, ამ შეტყობინების მიღებისთანავე, ამოიღებს ინტერფეისს S0/1 ამ ნაკადის გამავალი ინტერფეისის სიიდან, ინტერფეისების სიიდან, საიდანაც ეს ტრაფიკი უნდა გაიგზავნოს.

ქვემოთ მოცემულია PIM Prune შეტყობინების უფრო ოფიციალური განმარტება:
PIM Prune შეტყობინება იგზავნება ერთი როუტერის მიერ მეორე როუტერზე, რათა მეორე როუტერმა წაშალოს ბმული, რომელზეც Prune მიღებულია კონკრეტული (S,G) SPT-დან.

Prune შეტყობინების მიღების შემდეგ, R2 აყენებს Prune ტაიმერს 3 წუთზე. სამი წუთის შემდეგ, ის კვლავ დაიწყებს ტრაფიკის გაგზავნას, სანამ არ მიიღებს სხვა Prune შეტყობინებას. ეს არის PIMv1-ში.
და PIMv2-ში დამატებულია State Refresh ტაიმერი (ნაგულისხმევად 60 წამი). როგორც კი Prune შეტყობინება გაიგზავნება R3-დან, ეს ტაიმერი იწყება R3-ზე. ამ ტაიმერის ვადის გასვლის შემდეგ, R3 გამოგიგზავნით State Refresh შეტყობინებას, რომელიც აღადგენს 3-წუთიან Prune Timer-ს R2-ზე ამ ჯგუფისთვის.
Prune შეტყობინების გაგზავნის მიზეზები:

• როდესაც Multicast პაკეტი ვერ ახერხებს RPF შემოწმებას.
• როდესაც არ არსებობს ლოკალურად დაკავშირებული კლიენტები, რომლებმაც მოითხოვეს მულტიcast ჯგუფი (IGMP Join) და არ არსებობენ PIM მეზობლები, რომლებზეც შეიძლება გაიგზავნოს მულტიკასტის ტრაფიკი (არა-პრუნე ინტერფეისი).

გრაფტის შეტყობინება.
წარმოვიდგინოთ, რომ R3-ს არ სურდა ტრაფიკი R2-დან, გაგზავნა Prune და მიიღო multicast R1-დან. მაგრამ მოულოდნელად არხი R1-R3-ს შორის დაეცა და R3 დარჩა მულტიკასტის გარეშე. შეგიძლიათ დაელოდოთ 3 წუთი, სანამ R2-ზე Prune Timer ამოიწურება. 3 წუთი დიდი ლოდინია, ისე რომ არ დაელოდოთ, უნდა გამოაგზავნოთ შეტყობინება, რომელიც მყისიერად გამოიყვანს ამ S0/1 ინტერფეისს R2-ზე გასხვლის მდგომარეობიდან. ეს შეტყობინება იქნება Graft შეტყობინება. Graft შეტყობინების მიღების შემდეგ, R2 უპასუხებს Graft-ACK-ით.
Prune Override.

მოდით შევხედოთ ამ დიაგრამას. R1 ავრცელებს მულტიკასტს სეგმენტზე ორი როუტერით. R3 იღებს და ავრცელებს ტრაფიკს, R2 იღებს, მაგრამ არავის ჰყავს ტრაფიკის გადაცემა. ის აგზავნის Prune შეტყობინებას R1-ს ამ სეგმენტში. R1-მა უნდა ამოიღოს Fa0/0 სიიდან და შეწყვიტოს მაუწყებლობა ამ სეგმენტში, მაგრამ რა ბედი ეწევა R3-ს? და R3 არის იმავე სეგმენტში, ასევე მიიღო ეს შეტყობინება პრუნისგან და მიხვდა სიტუაციის ტრაგედიას. სანამ R1 შეწყვეტს მაუწყებლობას, ის ადგენს ტაიმერს 3 წამის განმავლობაში და შეწყვეტს მაუწყებლობას 3 წამის შემდეგ. 3 წამი - ეს არის ზუსტად რამდენი დრო აქვს R3-ს, რათა არ დაკარგოს თავისი მულტიკასტი. ამიტომ R3 უგზავნის Pim Join შეტყობინებას ამ ჯგუფისთვის რაც შეიძლება მალე და R1 აღარ ფიქრობს მაუწყებლობის შეწყვეტაზე. ქვემოთ შეტყობინებების შესახებ.
შეტყობინების გაგზავნა.

წარმოვიდგინოთ ეს სიტუაცია: ორი როუტერი ერთდროულად გადაიცემა ერთ ქსელში. ისინი იღებენ ერთსა და იმავე ნაკადს წყაროდან და ორივე გადასცემს მას იმავე ქსელში e0 ინტერფეისის უკან. ამიტომ მათ უნდა დაადგინონ, ვინ იქნება ამ ქსელის ერთი და ერთადერთი მაუწყებელი. ამისთვის გამოიყენება დამადასტურებელი შეტყობინებები. როდესაც R2 და R3 აღმოაჩენენ მულტიკასტის ტრაფიკის დუბლირებას, ანუ R2 და R3 იღებენ მულტიკასტს, რომელსაც თავად ავრცელებენ, მარშრუტიზატორები ესმით, რომ აქ რაღაც არასწორია. ამ შემთხვევაში, მარშრუტიზატორები აგზავნიან Assert შეტყობინებებს, რომლებიც მოიცავს ადმინისტრაციულ დისტანციას და მარშრუტის მეტრიკას, რომლითაც მიიღწევა მულტიკასტის წყარო - 10.1.1.10. გამარჯვებული გამოვლინდება შემდეგნაირად:

1. ერთი ქვედა AD.
2. თუ AD ტოლია, მაშინ ვის აქვს ქვედა მეტრიკა.
3. თუ აქ თანასწორობაა, მაშინ მას, ვისაც აქვს უფრო მაღალი IP ქსელში, რომელზედაც ისინი ავრცელებენ ამ მულტიკასტს.

ამ ხმის გამარჯვებული ხდება დანიშნული როუტერი. Pim Hello ასევე გამოიყენება DR-ების შესარჩევად. სტატიის დასაწყისში ნაჩვენები იყო PIM Hello გზავნილი, იქ შეგიძლიათ ნახოთ DR ველი. ამ ბმულზე ყველაზე მაღალი IP მისამართის მქონე იმარჯვებს.
სასარგებლო ნიშანი:

MROUTE მაგიდა.
PIM პროტოკოლის მუშაობის პირველადი შესწავლის შემდეგ, ჩვენ უნდა გავიგოთ, როგორ ვიმუშაოთ multicast მარშრუტიზაციის მაგიდასთან. mroute ცხრილი ინახავს ინფორმაციას იმის შესახებ, თუ რომელი ნაკადები იყო მოთხოვნილი კლიენტებისგან და რომელი ნაკადები მიედინება მულტიკასტის სერვერებიდან.
მაგალითად, როდესაც IGMP წევრობის ანგარიში ან PIM Join მიიღება რომელიმე ინტერფეისზე, ტიპის ჩანაწერი ( *, G ) ემატება მარშრუტიზაციის ცხრილში:

ეს ჩანაწერი ნიშნავს, რომ მიღებულ იქნა ტრაფიკის მოთხოვნა მისამართით 238.38.38.38. DC დროშა ნიშნავს, რომ multicast იმუშავებს Dense რეჟიმში და C ნიშნავს, რომ მიმღები პირდაპირ არის დაკავშირებული როუტერთან, ანუ როუტერმა მიიღო IGMP Membership Report და PIM Join.
თუ არის ჩანაწერი ტიპის (S,G), ეს ნიშნავს, რომ ჩვენ გვაქვს მულტიკასტის ნაკადი:

S ველში - 192.168.1.11, ჩვენ დავარეგისტრირეთ multicast წყაროს IP მისამართი, სწორედ ეს შემოწმდება RPF წესით. პრობლემების არსებობის შემთხვევაში, პირველი, რაც უნდა გააკეთოთ, შეამოწმეთ უნიკასტის ცხრილი წყარომდე მარშრუტისთვის. Incoming Interface ველში მიუთითებს ინტერფეისი, რომელზეც მიიღება მულტიკასტი. უნიკასტის მარშრუტიზაციის ცხრილში, მარშრუტი წყარომდე უნდა ეხებოდეს აქ მითითებულ ინტერფეისს. გამავალი ინტერფეისი აზუსტებს სად გადამისამართდება მულტიკასტი. თუ ის ცარიელია, მაშინ როუტერს არ მიუღია რაიმე მოთხოვნა ამ ტრაფიკისთვის. დამატებითი ინფორმაცია ყველა დროშის შესახებ შეგიძლიათ იხილოთ აქ.
PIM იშვიათი რეჟიმი.
Sparse-mode-ის სტრატეგია მკვრივი რეჟიმის საპირისპიროა. როდესაც Sparse-mode იღებს მულტიკასტ ტრაფიკს, ის გაგზავნის ტრაფიკს მხოლოდ იმ ინტერფეისებით, სადაც იყო მოთხოვნები ამ ნაკადისთვის, მაგალითად Pim Join ან IGMP Report შეტყობინებები, რომლებიც ითხოვენ ამ ტრაფიკს.
მსგავსი ელემენტები SM და DM-სთვის:

• სამეზობლო ურთიერთობები აგებულია ისევე, როგორც PIM DM-ში.
• RPF წესი მუშაობს.
• DR არჩევანი მსგავსია.
• Prune Overrides და Assert შეტყობინებების მექანიზმი მსგავსია.

იმის გასაკონტროლებლად, თუ ვინ, სად და რა სახის მულტიcast ტრაფიკია საჭირო ქსელში, საჭიროა საერთო საინფორმაციო ცენტრი. ჩვენი ცენტრი იქნება Rendezvous Point (RP). ვისაც სურს რაიმე სახის მულტიკასტის ტრაფიკი ან ვინმემ დაიწყო მულტიკასტის ტრაფიკის მიღება წყაროდან, შემდეგ ის აგზავნის მას RP-ზე.
როდესაც RP მიიღებს მულტიcast ტრაფიკს, ის გაუგზავნის მას იმ მარშრუტიზატორებს, რომლებმაც ადრე მოითხოვეს ეს ტრაფიკი.

წარმოვიდგინოთ ტოპოლოგია, სადაც RP არის R3. როგორც კი R1 მიიღებს ტრაფიკს S1-დან, ის ათავსებს ამ მრავალგზის პაკეტს unicast PIM Register შეტყობინებაში და აგზავნის მას RP-ზე. საიდან იცის, ვინ არის RP? ამ შემთხვევაში, ის კონფიგურირებულია სტატიკურად, ხოლო დინამიური RP კონფიგურაციის შესახებ მოგვიანებით ვისაუბრებთ.

ip pim rp-მისამართი 3.3.3.3

RP გამოიყურება - იყო ინფორმაცია ვინმესგან, ვისაც სურს ამ ტრაფიკის მიღება? დავუშვათ, რომ ეს არ იყო. შემდეგ RP გაუგზავნის R1-ს PIM Register-Stop შეტყობინებას, რაც ნიშნავს, რომ არავის სჭირდება ეს multicast, რეგისტრაცია უარყოფილია. R1 არ გაგზავნის მულტიკასტს. მაგრამ Multicast წყაროს ჰოსტი გამოაგზავნის მას, ასე რომ R1, Register-Stop-ის მიღების შემდეგ, დაიწყებს Register-Suppression ტაიმერის ტოლფასი 60 წამი. ამ ტაიმერის ვადის ამოწურვამდე 5 წამით ადრე, R1 გამოგიგზავნით ცარიელ რეგისტრაციას შეტყობინებას Null-Register ბიტით (ანუ, ინკაფსულირებული მულტიcast პაკეტის გარეშე) RP-სკენ. RP, თავის მხრივ, იმოქმედებს ასე:

• თუ არ იყო მიმღები, მაშინ ის უპასუხებს რეგისტრაცია-სტოპ შეტყობინებით.
• თუ მიმღებები გამოჩნდებიან, ის არანაირად არ უპასუხებს მას. R1, რომელმაც არ მიიღო უარი რეგისტრაციაზე 5 წამის განმავლობაში, მოხარული იქნება და RP-ს გაუგზავნის შეტყობინებას რეგისტრაციაზე ჩასმული მულტიკასტურით.

ჩვენ, როგორც ჩანს, გავარკვიეთ, თუ როგორ აღწევს multicast RP-ს, ახლა შევეცადოთ ვუპასუხოთ კითხვას, თუ როგორ აწვდის RP ტრაფიკს მიმღებებს. აქ აუცილებელია ახალი კონცეფციის - root-path tree (RPT) შემოღება. RPT არის RP-ში დაფუძნებული ხე, რომელიც იზრდება მიმღებებისკენ და განშტოებულია თითოეულ PIM-SM როუტერზე. RP ქმნის მას PIM Join შეტყობინებების მიღებით და ამატებს ახალ ტოტს ხეს. ასე რომ, ყველა ქვედა დინების როუტერი აკეთებს. ზოგადი წესი ასე გამოიყურება:

• როდესაც PIM-SM როუტერი იღებს PIM Join შეტყობინებას ნებისმიერ ინტერფეისზე, გარდა იმ ინტერფეისისა, რომლის მიღმაც იმალება RP, ის ამატებს ახალ ტოტს ხეს.
• ფილიალი ასევე ემატება, როდესაც PIM-SM როუტერი მიიღებს IGMP წევრობის ანგარიშს პირდაპირ დაკავშირებული ჰოსტიდან.

წარმოვიდგინოთ, რომ ჩვენ გვყავს Multicast კლიენტი R5 როუტერზე 228.8.8.8 ჯგუფისთვის. როგორც კი R5 მიიღებს IGMP წევრობის ანგარიშს ჰოსტისგან, R5 აგზავნის PIM Join-ს RP-ის მიმართულებით და თავად ამატებს ინტერფეისს ხეს, რომელიც უყურებს მასპინძელს. შემდეგი, R4 იღებს PIM Join-ს R5-დან, ამატებს ინტერფეისს Gi0/1 ხეს და აგზავნის PIM Join-ს RP-ის მიმართულებით. საბოლოოდ, RP (R3) იღებს PIM Join-ს და ამატებს Gi0/0 ხეს. ამრიგად, მულტიკასტის მიმღები რეგისტრირებულია. ვაშენებთ ხეს R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0 ფესვით.
ამის შემდეგ, PIM Join გაიგზავნება R1-ზე და R1 დაიწყებს მულტიკასტის ტრაფიკის გაგზავნას. მნიშვნელოვანია აღინიშნოს, რომ თუ მასპინძელმა მოითხოვა ტრაფიკი მულტიკასტის მაუწყებლობის დაწყებამდე, მაშინ RP არ გაუგზავნის PIM Join-ს და საერთოდ არ გაუგზავნის არაფერს R1-ზე.
თუ მოულოდნელად მულტიკასტის გაგზავნისას, ჰოსტს შეწყვეტს მისი მიღების სურვილი, როგორც კი RP მიიღებს PIM Prune-ს Gi0/0 ინტერფეისზე, ის დაუყოვნებლივ გაგზავნის PIM Register-Stop-ს პირდაპირ R1-ზე, შემდეგ კი PIM Prune-ს. შეტყობინება Gi0/1 ინტერფეისის საშუალებით. PIM Register-stop იგზავნება unicast-ის საშუალებით იმ მისამართზე, საიდანაც მოვიდა PIM რეგისტრაცია.
როგორც ადრე ვთქვით, როგორც კი როუტერი აგზავნის PIM Join-ს სხვას, მაგალითად R5-ს R4-ში, მაშინ ჩანაწერი ემატება R4-ს:

და დაწყებულია ტაიმერი, რომ R5 მუდმივად უნდა აღადგინოს ეს ტაიმერი PIM შეუერთდეს შეტყობინებებს მუდმივად, წინააღმდეგ შემთხვევაში R4 გამოირიცხება გამავალი სიიდან. R5 გამოგიგზავნით ყოველ 60 PIM Join შეტყობინებას.
უმოკლესი ბილიკის ხის გადართვა.
ჩვენ დავამატებთ ინტერფეისს R1-სა და R5-ს შორის და ვნახოთ, როგორ მიედინება ტრაფიკი ამ ტოპოლოგიით.

დავუშვათ, რომ ტრაფიკი გაგზავნილი და მიღებული იყო ძველი სქემის მიხედვით R1-R2-R3-R4-R5 და აქ ჩვენ დავაკავშირეთ და დავაკონფიგურირეთ ინტერფეისი R1-სა და R5-ს შორის.
უპირველეს ყოვლისა, ჩვენ უნდა აღვადგინოთ unicast მარშრუტიზაციის ცხრილი R5-ზე და ახლა ქსელში 192.168.1.0/24 მიიღწევა R5 Gi0/2 ინტერფეისის მეშვეობით. ახლა R5, რომელიც იღებს Multicast ინტერფეისზე Gi0/1, ესმის, რომ RPF წესი არ არის დაკმაყოფილებული და უფრო ლოგიკური იქნება Gi0/2-ზე მულტიკასტის მიღება. მან უნდა გათიშოს RPT-დან და შექმნას უფრო მოკლე ხე, სახელწოდებით უმოკლესი ბილიკის ხე (SPT). ამისათვის ის აგზავნის PIM Join-ს R0-ზე Gi2/1-ის მეშვეობით და R1 იწყებს მულტიკასტის გაგზავნას ასევე Gi0/2-ის მეშვეობით. ახლა R5 უნდა გააუქმოს RPT-ის გამოწერა, რათა არ მიიღოს ორი ასლი. ამისათვის ის Prune-ს უგზავნის შეტყობინებას, რომელშიც მითითებულია წყაროს IP მისამართი და ჩასმულია სპეციალური ბიტი - RPT-bit. ეს ნიშნავს, რომ თქვენ არ გჭირდებათ ტრაფიკის გაგზავნა, მე აქ უკეთესი ხე მაქვს. RP ასევე აგზავნის PIM Prune შეტყობინებებს R1-ზე, მაგრამ არ აგზავნის შეტყობინებას Register-Stop. კიდევ ერთი ფუნქცია: R5 ახლა მუდმივად აგზავნის PIM Prune-ს RP-ზე, რადგან R1 აგრძელებს PIM Register-ის გაგზავნას RP-ზე ყოველ წუთს. სანამ არ იქნება ახალი ხალხი, ვისაც ეს ტრაფიკი სურს, RP უარს იტყვის მასზე. R5 აცნობებს RP-ს, რომ ის აგრძელებს მულტიკასტის მიღებას SPT-ის საშუალებით.
დინამიური RP ძებნა.
ავტო-RP.
ეს ტექნოლოგია არის Cisco-ს საკუთრება და არ არის განსაკუთრებით პოპულარული, მაგრამ ჯერ კიდევ ცოცხალია. Auto-RP ოპერაცია შედგება ორი ძირითადი ეტაპისგან:
1) RP აგზავნის RP-Announce შეტყობინებებს დაჯავშნილ მისამართზე - 224.0.1.39, აცხადებს თავს RP ან ყველასთვის ან კონკრეტული ჯგუფისთვის. ეს შეტყობინება ყოველ წუთს იგზავნება.
2) საჭიროა RP რუკების აგენტი, რომელიც გამოგიგზავნით RP-Discovery შეტყობინებებს, სადაც მითითებულია, თუ რომელი ჯგუფებისთვის უნდა მოისმინოს RP. სწორედ ამ გზავნილიდანაა, რომ ჩვეულებრივი PIM მარშრუტიზატორები თავად განსაზღვრავენ RP-ს. Mapping Agent შეიძლება იყოს ან თავად RP როუტერი ან ცალკე PIM როუტერი. RP-Discovery იგზავნება 224.0.1.40 მისამართზე ერთი წუთის ტაიმერით.
მოდით შევხედოთ პროცესს უფრო დეტალურად:
მოდით დავაკონფიგურიროთ R3 როგორც RP:

ip pim გაგზავნა-rp-აცხადებს loopback 0 სფერო 10

R2, როგორც რუკების აგენტი:

ip pim send-rp-discovery loopback 0 სფერო 10

და ყველა დანარჩენზე ჩვენ ველით RP-ს Auto-RP-ის მეშვეობით:

ip pim autorp მსმენელი

R3-ის კონფიგურაციის შემდეგ, ის დაიწყებს RP-Announce-ის გაგზავნას:

და R2, რუკების აგენტის დაყენების შემდეგ, დაიწყებს RP-Announce შეტყობინების მოლოდინს. მხოლოდ მაშინ, როდესაც ის აღმოაჩენს მინიმუმ ერთ RP-ს, ის დაიწყებს RP-Discovery-ის გაგზავნას:

ამ გზით, როგორც კი ჩვეულებრივი მარშრუტიზატორები (PIM RP მსმენელი) მიიღებენ ამ შეტყობინებას, მათ ეცოდინებათ, სად მოიძიონ RP.
Auto-RP-ის ერთ-ერთი მთავარი პრობლემა ის არის, რომ RP-Announce და RP-Discovery შეტყობინებების მისაღებად, თქვენ უნდა გაგზავნოთ PIM Join მისამართებზე 224.0.1.39-40, ხოლო გასაგზავნად, თქვენ უნდა იცოდეთ სად არის RP მდებარეობს. კლასიკური ქათმის და კვერცხის პრობლემა. ამ პრობლემის გადასაჭრელად გამოიგონეს PIM Sparse-Dense-Mode. თუ როუტერმა არ იცის RP, მაშინ ის მუშაობს Dense-რეჟიმში, თუ იცის, მაშინ Sparse-რეჟიმში. როდესაც PIM Sparse-mode და ip pim autorp listener ბრძანება კონფიგურირებულია ჩვეულებრივი მარშრუტიზატორების ინტერფეისებზე, როუტერი იმუშავებს მკვრივ რეჟიმში მხოლოდ მულტიკასტინგისთვის პირდაპირ Auto-RP პროტოკოლიდან (224.0.1.39-40).
BootStrap როუტერი (BSR).
ეს ფუნქცია მუშაობს Auto-RP-ის მსგავსად. თითოეული RP უგზავნის შეტყობინებას რუკების აგენტს, რომელიც აგროვებს რუკების შესახებ ინფორმაციას და შემდეგ ეუბნება ყველა სხვა მარშრუტიზატორს. მოდით აღვწეროთ პროცესი Auto-RP-ის მსგავსად:
1) მას შემდეგ რაც R3-ის კონფიგურაციას ვაკეთებთ, როგორც კანდიდატად RP, ბრძანებით:

ip pim rp-candidate loopback 0

მაშინ R3 არაფერს გააკეთებს; იმისათვის, რომ დაიწყოს სპეციალური შეტყობინებების გაგზავნა, მან ჯერ უნდა მოძებნოს რუკების აგენტი. ამრიგად, ჩვენ გადავდივართ მეორე საფეხურზე.
2) დააკონფიგურირეთ R2, როგორც რუკების აგენტი:

ip pim bsr-candidate loopback 0

R2 იწყებს PIM Bootstrap შეტყობინებების გაგზავნას, სადაც ის მიუთითებს თავს რუკების აგენტად:

ეს შეტყობინება იგზავნება მისამართზე 224.0.013, რომელსაც PIM პროტოკოლი ასევე იყენებს სხვა შეტყობინებებისთვის. ის აგზავნის მათ ყველა მიმართულებით და, შესაბამისად, არ არის ქათმისა და კვერცხის პრობლემა, როგორც ეს იყო Auto-RP-ში.
3) როგორც კი RP მიიღებს შეტყობინებას BSR როუტერიდან, ის დაუყოვნებლივ გაუგზავნის unicast შეტყობინებას BSR როუტერის მისამართზე:

რის შემდეგაც, BSR, რომელმაც მიიღო ინფორმაცია RP-ების შესახებ, გააგზავნის მათ მულტიკასტის საშუალებით 224.0.0.13 მისამართზე, რომელსაც უსმენს ყველა PIM მარშრუტიზატორი. ამიტომ, ბრძანების ანალოგი ip pim autorp მსმენელი ჩვეულებრივი მარშრუტიზატორებისთვის, რომლებიც არ არიან BSR-ში.
Anycast RP Multicast Source Discovery Protocol-ით (MSDP).
Auto-RP და BSR საშუალებას გვაძლევს გავანაწილოთ დატვირთვა RP-ზე შემდეგნაირად: თითოეულ მულტიკასტ ჯგუფს აქვს მხოლოდ ერთი აქტიური RP. შეუძლებელი იქნება დატვირთვის განაწილება ერთი მულტიcast ჯგუფისთვის რამდენიმე RP-ზე. MSDP ამას აკეთებს RP მარშრუტიზატორების გაცემით იგივე IP მისამართით 255.255.255.255 ნიღბით. MSDP სწავლობს ინფორმაციას ერთ-ერთი მეთოდის გამოყენებით: სტატიკური, Auto-RP ან BSR.

სურათზე გვაქვს Auto-RP კონფიგურაცია MSDP-ით. ორივე RP კონფიგურირებულია IP მისამართით 172.16.1.1/32 Loopback 1 ინტერფეისზე და გამოიყენება ყველა ჯგუფისთვის. RP-Announce-ით ორივე მარშრუტიზატორი აცხადებს თავს ამ მისამართის მითითებით. Auto-RP რუკების აგენტი, ინფორმაციის მიღების შემდეგ, აგზავნის RP-Discovery-ს RP-ის შესახებ მისამართით 172.16.1.1/32. ჩვენ ვეუბნებით მარშრუტიზატორებს ქსელის შესახებ 172.16.1.1/32 IGP-ის გამოყენებით და შესაბამისად. ამრიგად, PIM მარშრუტიზატორები ითხოვენ ან არეგისტრირებენ ნაკადებს RP-დან, რომელიც მითითებულია, როგორც შემდეგი ჰოპ მარშრუტზე 172.16.1.1/32 ქსელში. თავად MSDP პროტოკოლი შექმნილია იმისთვის, რომ თავად RP-ებმა გაცვალონ შეტყობინებები მულტიკასტის ინფორმაციის შესახებ.
განვიხილოთ ეს ტოპოლოგია:

Switch6 ავრცელებს ტრაფიკს 238.38.38.38 მისამართზე და ჯერჯერობით მხოლოდ RP-R1-მა იცის ამის შესახებ. Switch7-მა და Switch8-მა მოითხოვეს ეს ჯგუფი. მარშრუტიზატორები R5 და R4 გაუგზავნიან PIM Join-ს R1 და R3-ზე, შესაბამისად. რატომ? მარშრუტი 13.13.13.13-მდე R5-ისთვის მიმართავს R1-ს IGP მეტრიკის გამოყენებით, ისევე როგორც R4-ისთვის.
RP-R1-მა იცის ნაკადის შესახებ და დაიწყებს მის მაუწყებლობას R5-ის მიმართულებით, მაგრამ R4-მა არაფერი იცის ამის შესახებ, რადგან R1 უბრალოდ არ გაგზავნის მას. ამიტომ MSDP აუცილებელია. ჩვენ ვაკონფიგურირებთ R1 და R5-ზე:

ip msdp peer 3.3.3.3 connect-source Loopback1 R1-ზე

ip msdp peer 1.1.1.1 connect-source Loopback3 R3-ზე

ისინი გამართავენ სესიას ერთმანეთს შორის და როდესაც მიიღებენ რაიმე ნაკადს, ისინი შეატყობინებენ ამას თავიანთ RP მეზობელს.
როგორც კი RP-R1 მიიღებს სტრიმინგს Switch6-დან, ის დაუყოვნებლივ გაგზავნის unicast MSDP Source-Active შეტყობინებას, რომელიც შეიცავს ინფორმაციას, როგორიცაა (S, G) - ინფორმაცია მულტიკასტის წყაროსა და დანიშნულების შესახებ. ახლა, როდესაც RP-R3-მა იცის, რომ წყარო, როგორიცაა Switch6, R4-ისგან ამ ნაკადის მოთხოვნის მიღებისას, ის გაგზავნის PIM Join-ს Switch6-ისკენ, მარშრუტიზაციის ცხრილის ხელმძღვანელობით. შესაბამისად, R1-მა, რომელმაც მიიღო ასეთი PIM Join, დაიწყებს ტრაფიკის გაგზავნას RP-R3-ისკენ.
MSDP გადის TCP-ზე, RP-ები უგზავნიან ერთმანეთს შენახულ შეტყობინებებს სიცოცხლისუნარიანობის შესამოწმებლად. ტაიმერი არის 60 წამი.
MSDP peers-ის სხვადასხვა დომენებად დაყოფის ფუნქცია გაურკვეველია, რადგან Keepalive და SA შეტყობინებები არ მიუთითებს რომელიმე დომენში წევრობაზე. ასევე, ამ ტოპოლოგიაში, ჩვენ გამოვცადეთ კონფიგურაცია, რომელიც მიუთითებს სხვადასხვა დომენებზე - არ იყო განსხვავება შესრულებაში.
თუ ვინმეს შეუძლია გარკვევა, სიამოვნებით წავიკითხავ კომენტარებში.

წყარო: www.habr.com