PIM արձանագրությունը երթուղղիչների միջև ցանցում բազմակի հաղորդում փոխանցելու արձանագրությունների մի շարք է: Հարևանության հարաբերությունները կառուցվում են այնպես, ինչպես դինամիկ երթուղային արձանագրությունների դեպքում: PIMv2-ն ուղարկում է Hello-ի հաղորդագրություններ յուրաքանչյուր 30 վայրկյանը մեկ 224.0.0.13 (All-PIM-Routers) վերապահված multicast հասցեին: Հաղորդագրությունը պարունակում է Hold Timers - սովորաբար հավասար է 3.5*Hello Timer-ին, այսինքն՝ լռելյայն 105 վայրկյան:
PIM-ն օգտագործում է երկու հիմնական աշխատանքային ռեժիմ՝ խիտ և նոսր ռեժիմ: Սկսենք Խիտ ռեժիմից:
Աղբյուրի վրա հիմնված բաշխման ծառեր:
Խիտ-ռեժիմի ռեժիմը նպատակահարմար է օգտագործել տարբեր բազմահաղորդակցական խմբերի մեծ թվով հաճախորդների դեպքում: Երբ երթուղիչը ստանում է բազմաֆունկցիոնալ տրաֆիկ, առաջին բանը, որ անում է, այն ստուգում է RPF կանոնի համար: RPF - այս կանոնն օգտագործվում է բազմակի հեռարձակման աղբյուրը unicast երթուղային աղյուսակով ստուգելու համար: Անհրաժեշտ է, որ երթևեկությունը հասնի այն միջերեսին, որի հետևում թաքնված է այս հոսթը՝ համաձայն unicast երթուղղման աղյուսակի տարբերակի: Այս մեխանիզմը լուծում է բազմակի փոխանցման ժամանակ առաջացող հանգույցի խնդիրը:
R3-ը կճանաչի բազմահեռարձակման աղբյուրը (Աղբյուր IP) բազմահեռարձակման հաղորդագրությունից և կստուգի երկու հոսքերը R1-ից և R2-ից՝ օգտագործելով իր unicast աղյուսակը: Աղյուսակով մատնանշված ինտերֆեյսից հոսքը (R1-ից R3) կփոխանցվի հետագա, իսկ հոսքը R2-ից կթողարկվի, քանի որ բազմակի հեռարձակման աղբյուրին հասնելու համար անհրաժեշտ է փաթեթներ ուղարկել S0/1-ի միջոցով:
Հարցն այն է, թե ինչ է տեղի ունենում, եթե դուք ունեք երկու համարժեք երթուղիներ նույն մետրով: Այս դեպքում երթուղիչն այս երթուղիներից կընտրի հաջորդ հոպը: Ով ունի ավելի բարձր IP հասցե, հաղթում է: Եթե Ձեզ անհրաժեշտ է փոխել այս վարքագիծը, կարող եք օգտագործել ECMP: Ավելի մանրամասն .
RPF կանոնը ստուգելուց հետո երթուղիչը ուղարկում է բազմաբնույթ փաթեթ իր բոլոր PIM հարևաններին, բացառությամբ այն մեկի, ումից ստացվել է փաթեթը: Այլ PIM երթուղիչները կրկնում են այս գործընթացը: Ճանապարհը, որը բազմաբնույթ փաթեթն անցել է աղբյուրից մինչև վերջնական ստացողներ, ձևավորում է մի ծառ, որը կոչվում է աղբյուրի վրա հիմնված բաշխման ծառ, ամենակարճ ճանապարհի ծառ (SPT), աղբյուրի ծառ: Երեք տարբեր անուններ, ընտրեք ցանկացած մեկը:
Ինչպես լուծել այն խնդիրը, որ որոշ երթուղիչներ չհրաժարվեցին ինչ-որ multicast հոսքից, և չկա մեկը, որին ուղարկի այն, բայց վերընթաց երթուղիչն այն ուղարկում է նրան: Դրա համար հորինվել է Prune մեխանիզմը։
Prune հաղորդագրություն.
Օրինակ, R2-ը կշարունակի multicast ուղարկել 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 ստուգումը:
- Երբ չկան լոկալ միացված հաճախորդներ, որոնք խնդրել են բազմաֆունկցիոնալ խումբ (IGMP Join), և չկան PIM հարևաններ, որոնց կարող է ուղարկվել բազմահաղորդակցական երթևեկություն (Non-prune Interface):
Փոխպատվաստման հաղորդագրություն.
Եկեք պատկերացնենք, որ R3-ը չի ուզում տրաֆիկ R2-ից, ուղարկել է Prune-ն և ստացել է մուլտիհեռարձակում 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-ը գտնվում է նույն հատվածում, նույնպես ստացել է այս հաղորդագրությունը Prune-ից և հասկացել է իրավիճակի ողբերգությունը։ Մինչ R1-ը կդադարեցնի հեռարձակումը, այն սահմանում է 3 վայրկյան ժամանակաչափ և կդադարեցնի հեռարձակումը 3 վայրկյան հետո: 3 վայրկյան - հենց այսքան ժամանակ ունի R3-ը, որպեսզի չկորցնի իր բազմահեռարձակումը: Հետևաբար, R3-ը Pim Join հաղորդագրություն է ուղարկում այս խմբի համար որքան հնարավոր է շուտ, և R1-ն այլևս չի մտածում հեռարձակումը դադարեցնելու մասին: Ստորև բերված միանալու հաղորդագրությունների մասին:
Հաստատել հաղորդագրությունը.
Եկեք պատկերացնենք այս իրավիճակը. միանգամից երկու երթուղիչ հեռարձակվում է մեկ ցանցի վրա: Նրանք ստանում են նույն հոսքը աղբյուրից, և երկուսն էլ այն հեռարձակում են նույն ցանցին e0 ինտերֆեյսի հետևում: Ուստի նրանք պետք է որոշեն, թե ով է լինելու այս ցանցի միակ հեռարձակողը։ Դրա համար օգտագործվում են հաստատման հաղորդագրություններ: Երբ R2-ը և R3-ը հայտնաբերում են բազմակի հեռարձակման տրաֆիկի կրկնօրինակում, այսինքն՝ R2-ը և R3-ը ստանում են մուլտիհեռարձակում, որը նրանք իրենք են հեռարձակում, երթուղիչները հասկանում են, որ այստեղ ինչ-որ բան այն չէ: Այս դեպքում երթուղիչները ուղարկում են Assert հաղորդագրություններ, որոնք ներառում են Administrative Distance և երթուղու մետրիկ, որով հասնում է բազմակի հեռարձակման աղբյուրը՝ 10.1.1.10: Հաղթողը որոշվում է հետևյալ կերպ.
- Ավելի ցածր մ.թ.
- Եթե AD-ը հավասար են, ապա ով ունի ավելի ցածր մետրիկ:
- Եթե այստեղ հավասարություն կա, ապա նա, ով ավելի բարձր IP ունի այն ցանցում, որին հեռարձակում են այս մուլտիհեռարձակումը։
Այս քվեարկության հաղթողը դառնում է Նշանակված երթուղիչը: Pim Hello-ն օգտագործվում է նաև DR-ներ ընտրելու համար: Հոդվածի սկզբում ցուցադրվեց PIM Hello հաղորդագրությունը, այնտեղ կարող եք տեսնել DR դաշտը։ Այս հղման վրա ամենաբարձր IP հասցե ունեցողը հաղթում է:
Օգտակար նշան.
MROUTE Սեղան.
Նախնական հայացքից հետո, թե ինչպես է աշխատում PIM արձանագրությունը, մենք պետք է հասկանանք, թե ինչպես աշխատել բազմաբնույթ երթուղային աղյուսակի հետ: «Mroute» աղյուսակը պահում է տեղեկատվություն այն մասին, թե որ հոսքերն են պահանջվել հաճախորդներից, և որ հոսքերը հոսում են բազմաբնույթ սերվերներից:
Օրինակ, երբ IGMP Անդամակցության հաշվետվությունը կամ PIM Join-ը ստացվում է ինչ-որ ինտերֆեյսի վրա, երթուղղման աղյուսակում ավելացվում է տիպի գրառում ( *, G ).
Այս գրառումը նշանակում է, որ տրաֆիկի հարցում է ստացվել 238.38.38.38 հասցեով։ DC դրոշը նշանակում է, որ multicast-ը կգործի խիտ ռեժիմում, իսկ C-ն նշանակում է, որ ստացողը ուղղակիորեն միացված է երթուղիչին, այսինքն՝ երթուղիչը ստացել է IGMP Անդամակցության հաշվետվություն և PIM Join:
Եթե կա (S,G) տիպի գրառում, դա նշանակում է, որ մենք ունենք բազմակի հեռարձակում.
S դաշտում՝ 192.168.1.11, մենք գրանցել ենք multicast աղբյուրի IP հասցեն, հենց սա է ստուգվելու RPF կանոնով։ Եթե խնդիրներ կան, առաջին բանը, որ դուք պետք է անեք, ստուգեք unicast աղյուսակը դեպի աղբյուր տանող երթուղին: Ներգնա ինտերֆեյս դաշտում ցույց է տալիս ինտերֆեյսը, որի վրա ստացվում է բազմակի հեռարձակումը: Unicast երթուղղման աղյուսակում դեպի աղբյուր տանող երթուղին պետք է վերաբերի այստեղ նշված ինտերֆեյսին: Ելքային ինտերֆեյսը նշում է, թե որտեղ է վերահղվելու բազմահեռարձակումը: Եթե այն դատարկ է, ապա երթուղիչը այս տրաֆիկի համար որևէ հարցում չի ստացել: Բոլոր դրոշների մասին լրացուցիչ տեղեկություններ կարելի է գտնել .
PIM նոսր ռեժիմ:
Sparse-mode-ի ռազմավարությունը հակառակն է Dense-mode-ի: Երբ Sparse-mode-ը ստանում է բազմաֆունկցիոնալ տրաֆիկ, այն կուղարկի երթևեկությունը միայն այն միջերեսների միջոցով, որտեղ եղել են այս հոսքի հարցումներ, օրինակ՝ Pim Join կամ IGMP Report հաղորդագրությունները, որոնք պահանջում են այս տրաֆիկը:
Նմանատիպ տարրեր SM-ի և DM-ի համար.
- Հարևանության հարաբերությունները կառուցվում են այնպես, ինչպես PIM DM-ում:
- RPF կանոնը գործում է.
- DR ընտրությունը նման է.
- Prune Overrides-ի և Assert հաղորդագրությունների մեխանիզմը նման է:
Վերահսկելու համար, թե ով, որտեղ և ինչպիսի մուլտիհեռարձակման տրաֆիկ է անհրաժեշտ ցանցում, անհրաժեշտ է ընդհանուր տեղեկատվական կենտրոն: Մեր կենտրոնը կլինի Rendezvous Point (RP): Ամեն ոք, ով ցանկանում է ինչ-որ մուլտիհաստատված տրաֆիկ կամ ինչ-որ մեկը սկսել է ստանալ բազմակաստ տրաֆիկ աղբյուրից, այնուհետև նա այն ուղարկում է RP:
Երբ RP-ն ստանում է բազմաֆունկցիոնալ տրաֆիկ, այն կուղարկի այն երթուղիչներին, որոնք նախկինում խնդրել են այս տրաֆիկը:
Եկեք պատկերացնենք մի տոպոլոգիա, որտեղ RP-ն R3 է: Հենց որ R1-ը ստանում է S1-ից տրաֆիկ, այն ընդգրկում է այս բազմաբնույթ փաթեթը միանվագ PIM գրանցման հաղորդագրության մեջ և այն ուղարկում RP-ին: Նա որտեղի՞ց գիտի, թե ով է ՀՀԿ-ն։ Այս դեպքում այն կարգավորվում է ստատիկորեն, իսկ դինամիկ RP կոնֆիգուրացիայի մասին մենք կխոսենք ավելի ուշ:
ip pim rp-հասցե 3.3.3.3
RP-ն կնայի՝ տեղեկություն կա՞ր ինչ-որ մեկից, ով կցանկանար ստանալ այս տրաֆիկը: Ենթադրենք՝ այդպես չի եղել։ Այնուհետև RP-ն R1-ին կուղարկի PIM Register-Stop հաղորդագրություն, ինչը նշանակում է, որ ոչ ոքի պետք չէ այս multicast-ը, գրանցումը մերժված է: R1-ը բազմակի հեռարձակում չի ուղարկի: Բայց Multicast աղբյուրի հոսթինգը կուղարկի այն, որպեսզի R1-ը, Register-Stop-ը ստանալուց հետո, կսկսի 60 վայրկյանի հավասար գրանցում-անջատման ժամանակաչափ։ Այս ժմչփի ժամկետը լրանալուց 5 վայրկյան առաջ R1-ը դատարկ Գրանցման հաղորդագրություն կուղարկի Null-Register բիթով (այսինքն՝ առանց պարփակված բազմահաղորդակցման փաթեթի) դեպի RP: ՀՀԿ-ն իր հերթին կգործի այսպես.
- Եթե հասցեատերեր չեն եղել, ապա այն կպատասխանի Գրանցվել-Դադարեցնել հաղորդագրությամբ:
- Եթե հասցեատերեր հայտնվեն, նա դրան ոչ մի կերպ չի արձագանքի։ R1-ը, 5 վայրկյանի ընթացքում չստանալով գրանցման մերժում, ուրախ կլինի և RP-ին կուղարկի Գրանցման հաղորդագրություն՝ պարփակված մուլտիհաղորդումով:
Մենք, կարծես, հասկացել ենք, թե ինչպես է multicast-ը հասնում RP-ին, այժմ եկեք փորձենք պատասխանել այն հարցին, թե ինչպես է RP-ն տրաֆիկ մատակարարում հասցեատերերին: Այստեղ անհրաժեշտ է ներդնել նոր հայեցակարգ՝ արմատ-ուղու ծառ (RPT): RPT-ն RP-ում արմատավորված ծառ է, որը աճում է դեպի ստացողներ և ճյուղավորվում յուրաքանչյուր PIM-SM երթուղիչի վրա: RP-ն այն ստեղծում է՝ ստանալով PIM Join հաղորդագրություններ և նոր ճյուղ է ավելացնում ծառին: Եվ այսպես, ամեն ներքեւի երթուղիչ անում է: Ընդհանուր կանոնն ունի հետևյալ տեսքը.
- Երբ PIM-SM երթուղիչը ստանում է PIM Join հաղորդագրություն ցանկացած ինտերֆեյսի վրա, բացի այն միջերեսից, որի հետևում թաքնված է RP-ն, այն ծառին նոր ճյուղ է ավելացնում:
- Մասնաճյուղ է ավելացվում նաև, երբ PIM-SM երթուղիչը ստանում է IGMP Անդամակցության հաշվետվություն ուղղակիորեն միացված հոսթից:
Եկեք պատկերացնենք, որ մենք ունենք բազմաֆունկցիոնալ հաճախորդ 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 Join հաղորդագրությունները անընդհատ, հակառակ դեպքում 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-ը, ստանալով Gi0/1 ինտերֆեյսի վրա multicast, հասկանում է, որ RPF կանոնը չի բավարարվում, և ավելի տրամաբանական կլիներ ստանալ Multicast Gi0/2-ում: Այն պետք է անջատվի RPT-ից և կառուցի ավելի կարճ ծառ, որը կոչվում է Shortest-Path Tree (SPT): Դա անելու համար նա ուղարկում է PIM Join R0-ին Gi2/1-ի միջոցով, իսկ R1-ը սկսում է multicast ուղարկել նաև Gi0/2-ի միջոցով: Այժմ R5-ը պետք է դուրս գա RPT-ից, որպեսզի չստանա երկու օրինակ: Դա անելու համար նա Prune-ին ուղարկում է հաղորդագրություն՝ նշելով աղբյուրի IP հասցեն և տեղադրելով հատուկ բիթ՝ RPT-bit: Սա նշանակում է, որ ձեզ հարկավոր չէ ինձ թրաֆիկ ուղարկել, ես այստեղ ավելի լավ ծառ ունեմ: RP-ն նաև ուղարկում է PIM Prune հաղորդագրություններ R1-ին, բայց չի ուղարկում Register-Stop հաղորդագրություն: Մեկ այլ առանձնահատկություն. R5-ն այժմ շարունակաբար կուղարկի PIM Prune-ը RP-ին, քանի որ R1-ը շարունակում է ամեն րոպե ուղարկել PIM ռեգիստրը RP-ին: Քանի դեռ այս տրաֆիկը ուզող նոր մարդիկ չլինեն, ՀՀԿ-ն կհրաժարվի դրանից։ R5-ը տեղեկացնում է RP-ին, որ այն շարունակում է ստանալ multicast-ը 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 Liner) ստանան այս հաղորդագրությունը, նրանք կիմանան, թե որտեղ փնտրել RP-ն:
Auto-RP-ի հիմնական խնդիրներից մեկն այն է, որ RP-Announce և RP-Discovery հաղորդագրություններ ստանալու համար անհրաժեշտ է ուղարկել PIM Join 224.0.1.39-40 հասցեներին, իսկ ուղարկելու համար պետք է իմանալ, թե որտեղ է RP գտնվում է. Դասական հավի և ձվի խնդիր. Այս խնդիրը լուծելու համար հորինվել է PIM Sparse-Dense-Mode-ը: Եթե երթուղիչը չգիտի RP, ապա այն աշխատում է խիտ ռեժիմով, եթե գիտի, ապա Sparse ռեժիմով: Երբ PIM Sparse-mode-ը և ip pim autorp listener հրամանը կազմաձևված են սովորական երթուղիչների միջերեսների վրա, երթուղիչը կգործի խիտ ռեժիմում միայն Auto-RP արձանագրությունից (224.0.1.39-40) ուղիղ հեռարձակման համար:
BootStrap Router (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-ների մասին, դրանք կուղարկի multicast-ով 224.0.0.13 հասցեին, որը լսում են բոլոր PIM երթուղիչները: Հետեւաբար, հրամանի անալոգը ip pim autorp լսող սովորական երթուղիչների համար, որոնք BSR-ում չեն:
Anycast RP Multicast Source Discovery Protocol-ով (MSDP):
Auto-RP-ն և BSR-ը մեզ թույլ են տալիս բաշխել բեռը RP-ի վրա հետևյալ կերպ. Յուրաքանչյուր բազմահեռարձակող խումբ ունի միայն մեկ ակտիվ RP: Հնարավոր չի լինի բաշխել մեկ բազմաբնույթ խմբի բեռը մի քանի RP-ների վրա: MSDP-ն դա անում է՝ թողարկելով RP երթուղիչներ նույն IP հասցեն՝ 255.255.255.255 դիմակով: MSDP-ն տեղեկատվություն է սովորում՝ օգտագործելով մեթոդներից մեկը՝ ստատիկ, Auto-RP կամ BSR:
Նկարում մենք ունենք Auto-RP կոնֆիգուրացիա MSDP-ով: Երկու RP-ն էլ կազմաձևված են 172.16.1.1/32 IP հասցեով 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: Ինչո՞ւ։ R13.13.13.13-ի համար դեպի 5 երթուղին կվերաբերի 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-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 գործընկերները տարբեր տիրույթների բաժանելու գործառույթը մնում է անհասկանալի, քանի որ Keepalive և SA հաղորդագրությունները չեն նշում որևէ տիրույթի անդամակցություն: Բացի այդ, այս տոպոլոգիայում մենք փորձարկեցինք կոնֆիգուրացիա, որը ցույց է տալիս տարբեր տիրույթներ. կատարողականի տարբերություն չկար:
Եթե որևէ մեկը կարող է պարզաբանել, ուրախ կլինեմ կարդալ մեկնաբանություններում։
Source: www.habr.com