Si funksionon protokolli PIM

Protokolli PIM është një grup protokollesh për transmetimin multicast në një rrjet ndërmjet ruterave. Marrëdhëniet e fqinjësisë ndërtohen në të njëjtën mënyrë si në rastin e protokolleve dinamike të rrugëzimit. PIMv2 dërgon mesazhe Hello çdo 30 sekonda në adresën e rezervuar multicast 224.0.0.13 (All-PIM-Routers). Mesazhi përmban Hold Timers - zakonisht i barabartë me 3.5*Hello Timer, domethënë 105 sekonda si parazgjedhje.

PIM përdor dy mënyra kryesore funksionimi - modaliteti i dendur dhe i rrallë. Le të fillojmë me modalitetin e dendur.
Pemët e shpërndarjes të bazuara në burim.
Modaliteti i modalitetit të dendur këshillohet të përdoret në rastin e një numri të madh klientësh të grupeve të ndryshme multicast. Kur një ruter merr trafik multicast, gjëja e parë që bën është ta kontrollojë atë për rregullin RPF. RPF - ky rregull përdoret për të kontrolluar burimin e një multicast me një tabelë rutimi unicast. Është e nevojshme që trafiku të arrijë në ndërfaqen pas së cilës fshihet ky host sipas versionit të tabelës së rrugëtimit unicast. Ky mekanizëm zgjidh problemin e një cikli që ndodh gjatë transmetimit multicast.

R3 do të njohë burimin multicast (IP-ja e burimit) nga mesazhi multicast dhe do të kontrollojë dy rrjedhat nga R1 dhe R2 duke përdorur tabelën e tij unicast. Rrjedha nga ndërfaqja e treguar nga tabela (R1 në R3) do të transmetohet më tej, dhe rrjedha nga R2 do të hiqet, pasi për të arritur në burimin multicast, duhet të dërgoni pako përmes S0/1.
Pyetja është, çfarë ndodh nëse keni dy rrugë ekuivalente me të njëjtën metrikë? Në këtë rast, ruteri do të zgjedhë hop tjetër nga këto rrugë. Kushdo që ka adresën IP më të lartë fiton. Nëse keni nevojë të ndryshoni këtë sjellje, mund të përdorni ECMP. Më shumë detaje këtu.
Pas kontrollit të rregullit RPF, ruteri dërgon një paketë multicast tek të gjithë fqinjët e tij PIM, përveç atij nga i cili është marrë paketa. Ruterët e tjerë PIM e përsërisin këtë proces. Rruga që ka marrë një paketë multicast nga burimi deri te marrësit përfundimtar, formon një pemë të quajtur pema e shpërndarjes së bazuar në burim, pema e rrugës më të shkurtër (SPT), pema burimore. Tre emra të ndryshëm, zgjidhni cilindo.
Si të zgjidhet problemi që disa ruter nuk hoqën dorë nga një transmetim multicast dhe nuk ka kujt t'ia dërgojë atë, por ruteri në rrjedhën e sipërme ia dërgon atij. Mekanizmi Prune u shpik për këtë.
Prune Message.
Për shembull, R2 do të vazhdojë të dërgojë një multicast në R3, megjithëse R3, sipas rregullit RPF, e heq atë. Pse të ngarkoni kanalin? R3 dërgon një mesazh PIM Prune dhe R2, me marrjen e këtij mesazhi, do të heqë ndërfaqen S0/1 nga lista e ndërfaqes dalëse për këtë rrjedhë, listën e ndërfaqeve nga të cilat duhet të dërgohet ky trafik.

Më poshtë është një përkufizim më formal i një mesazhi PIM Prune:
Mesazhi PIM Prune dërgohet nga një ruter në një ruter të dytë për të bërë që ruteri i dytë të heqë lidhjen në të cilën është marrë Prune nga një SPT (S,G) e veçantë.

Pas marrjes së mesazhit Prune, R2 vendos kohëmatësin Prune në 3 minuta. Pas tre minutash, do të fillojë të dërgojë përsëri trafik derisa të marrë një mesazh tjetër Prune. Kjo është në PIMv1.
Dhe në PIMv2 është shtuar një kohëmatës i rifreskimit të gjendjes (60 sekonda si parazgjedhje). Sapo një mesazh Prune është dërguar nga R3, ky kohëmatës fillon në R3. Pas skadimit të këtij kohëmatësi, R3 do të dërgojë një mesazh Rifreskimi të gjendjes, i cili do të rivendosë kohëmatësin 3-minutësh të Prune në R2 për këtë grup.
Arsyet për dërgimin e një mesazhi Prune:

• Kur një paketë multicast dështon, kontrolli RPF.
• Kur nuk ka klientë të lidhur lokalisht që kanë kërkuar një grup multicast (IGMP Join) dhe nuk ka fqinjë PIM tek të cilët mund të dërgohet trafiku multicast (Non-prune Interface).

Mesazhi i shartimit.
Le të imagjinojmë që R3 nuk donte trafik nga R2, dërgoi Prune dhe mori një multicast nga R1. Por befas, kanali midis R1-R3 ra dhe R3 mbeti pa multicast. Mund të prisni 3 minuta derisa kohëmatësi i Prune në R2 të skadojë. 3 minuta është një pritje e gjatë, për të mos pritur, duhet të dërgoni një mesazh që do ta sjellë menjëherë këtë ndërfaqe S0/1 në R2 jashtë gjendjes së krasitur. Ky mesazh do të jetë një mesazh Graft. Pas marrjes së mesazhit Graft, R2 do të përgjigjet me një Graft-ACK.
Mbështetja e krasitjes.

Le të shohim këtë diagram. R1 transmeton multicast në një segment me dy rutera. R3 merr dhe transmeton trafikun, R2 merr, por nuk ka kujt të transmetojë trafikun. Ai dërgon një mesazh Prune te R1 në këtë segment. R1 duhet të heqë Fa0/0 nga lista dhe të ndalojë transmetimin në këtë segment, por çfarë do të ndodhë me R3? Dhe R3 është në të njëjtin segment, mori edhe këtë mesazh nga Prune dhe kuptoi tragjedinë e situatës. Përpara se R1 të ndalojë transmetimin, cakton një kohëmatës prej 3 sekondash dhe do të ndalojë transmetimin pas 3 sekondash. 3 sekonda - kjo është saktësisht sa kohë ka R3 për të mos humbur multicast-in e tij. Prandaj, R3 dërgon një mesazh Pim Join për këtë grup sa më shpejt të jetë e mundur dhe R1 nuk mendon më të ndalojë transmetimin. Rreth mesazheve Join më poshtë.
Pohoni mesazhin.

Le të imagjinojmë këtë situatë: dy rutera transmetohen në një rrjet menjëherë. Ata marrin të njëjtin transmetim nga burimi dhe të dy e transmetojnë atë në të njëjtin rrjet pas ndërfaqes e0. Prandaj, duhet të përcaktojnë se kush do të jetë transmetuesi i vetëm i këtij rrjeti. Për këtë përdoren mesazhet e pohimit. Kur R2 dhe R3 zbulojnë dyfishimin e trafikut multicast, domethënë, R2 dhe R3 marrin një multicast që ata vetë transmetojnë, ruterët kuptojnë se diçka nuk është në rregull këtu. Në këtë rast, ruterët dërgojnë mesazhe Assert, të cilat përfshijnë distancën administrative dhe metrikën e rrugës me të cilën arrihet burimi multicast - 10.1.1.10. Fituesi përcaktohet si më poshtë:

1. Ai me AD më të ulët.
2. Nëse AD janë të barabarta, atëherë kush e ka metrikën më të ulët.
3. Nëse këtu ka barazi, atëherë ai që ka IP-në më të lartë në rrjetin në të cilin transmetojnë këtë multicast.

Fituesi i këtij votimi bëhet Router i Përcaktuar. Pim Hello përdoret gjithashtu për të zgjedhur DR-të. Në fillim të artikullit u shfaq mesazhi PIM Hello, aty mund të shihni fushën DR. Ai me adresën më të lartë IP në këtë lidhje fiton.
Shenja e dobishme:

Tabela MROUTE.
Pas një vështrimi fillestar se si funksionon protokolli PIM, ne duhet të kuptojmë se si të punojmë me një tabelë kursimi multicast. Tabela mroute ruan informacionin se cilat transmetime janë kërkuar nga klientët dhe cilat rrjedha rrjedhin nga serverët multicast.
Për shembull, kur një Raport Anëtarësimi IGMP ose PIM Join merret në një ndërfaqe, një rekord i tipit ( *, G ) shtohet në tabelën e rrugëtimit:

Kjo hyrje do të thotë se është pranuar një kërkesë për trafik me adresën 238.38.38.38. Flamuri DC do të thotë që multicast do të funksionojë në modalitetin Dense dhe C do të thotë që marrësi është i lidhur drejtpërdrejt me ruterin, domethënë ruteri ka marrë Raportin e Anëtarësisë IGMP dhe PIM Join.
Nëse ka një rekord të tipit (S,G) do të thotë që kemi një transmetim multicast:

Në fushën S - 192.168.1.11, ne kemi regjistruar adresën IP të burimit multicast, është kjo që do të kontrollohet nga rregulli RPF. Nëse ka probleme, gjëja e parë që duhet të bëni është të kontrolloni tabelën unicast për rrugën drejt burimit. Në fushën "Incoming Interface", tregon ndërfaqen në të cilën merret multicast. Në një tabelë rutimi unicast, rruga drejt burimit duhet t'i referohet ndërfaqes së specifikuar këtu. Ndërfaqja dalëse specifikon se ku do të ridrejtohet multicast. Nëse është bosh, atëherë ruteri nuk ka marrë asnjë kërkesë për këtë trafik. Mund të gjeni më shumë informacion për të gjithë flamujt këtu.
Modaliteti i rrallë PIM.
Strategjia e Sparse-Mode është e kundërta e Dense-Mode. Kur "Modaliteti i rrallë" merr trafik multicast, ai do të dërgojë trafik vetëm përmes atyre ndërfaqeve ku ka pasur kërkesa për këtë rrjedhë, për shembull mesazhet Pim Join ose IGMP Report që kërkojnë këtë trafik.
Elementë të ngjashëm për SM dhe DM:

• Marrëdhëniet e fqinjësisë ndërtohen në të njëjtën mënyrë si në PIM DM.
• Rregulli RPF funksionon.
• Zgjedhja e DR është e ngjashme.
• Mekanizmi i mesazheve Prune Overrides dhe Assert janë të ngjashëm.

Për të kontrolluar se kush, ku dhe çfarë lloj trafiku multicast nevojitet në rrjet, nevojitet një qendër e përbashkët informacioni. Qendra jonë do të jetë Rendezvous Point (RP). Kushdo që dëshiron një lloj trafiku multicast ose dikush ka filluar të marrë trafik multicast nga burimi, atëherë ai e dërgon atë në RP.
Kur RP merr trafik multicast, ai do ta dërgojë atë tek ata ruter që e kanë kërkuar më parë këtë trafik.

Le të imagjinojmë një topologji ku RP është R3. Sapo R1 merr trafik nga S1, ai e kapsulon këtë paketë multicast në një mesazh unicast PIM Register dhe e dërgon atë në RP. Nga e di ai se kush është RP-ja? Në këtë rast, ai është konfiguruar në mënyrë statike, dhe ne do të flasim për konfigurimin dinamik të RP më vonë.

ip pim rp-adresa 3.3.3.3

RP do të shikojë - a kishte informacion nga dikush që do të dëshironte të merrte këtë trafik? Le të supozojmë se nuk ishte. Më pas RP do t'i dërgojë R1 një mesazh PIM Register-Stop, që do të thotë se askush nuk ka nevojë për këtë multicast, regjistrimi refuzohet. R1 nuk do të dërgojë multicast. Por hosti i burimit multicast do ta dërgojë atë, në mënyrë që R1, pasi të marrë Register-Stop, të nisë një kohëmatës të Regjistrimit-Suppression të barabartë me 60 sekonda. 5 sekonda përpara se të skadojë ky kohëmatës, R1 do të dërgojë një mesazh bosh Regjistrohu me një bit Null-Register (d.m.th., pa një paketë multicast të kapsuluar) drejt RP. RP, nga ana tjetër, do të veprojë si kjo:

• Nëse nuk kishte marrës, atëherë ai do të përgjigjet me një mesazh Regjistrohu-Stop.
• Nëse shfaqen marrës, ai nuk do t'i përgjigjet në asnjë mënyrë. R1, pasi nuk ka marrë një refuzim për t'u regjistruar brenda 5 sekondave, do të jetë i lumtur dhe do të dërgojë një mesazh Regjistrohu me një multicast të kapsuluar në RP.

Duket se kemi kuptuar se si multicast arrin RP, tani le të përpiqemi t'i përgjigjemi pyetjes se si RP u jep trafik marrësve. Këtu është e nevojshme të prezantohet një koncept i ri - pema e rrugës rrënjësore (RPT). RPT është një pemë e rrënjosur në RP, që rritet drejt marrësve, duke u degëzuar në çdo ruter PIM-SM. RP e krijon atë duke marrë mesazhe PIM Join dhe shton një degë të re në pemë. Dhe kështu, çdo ruter në rrjedhën e poshtme bën. Rregulli i përgjithshëm duket si ky:

• Kur një ruter PIM-SM merr një mesazh PIM Join në çdo ndërfaqe tjetër përveç ndërfaqes pas së cilës fshihet RP, ai shton një degë të re në pemë.
• Një degë shtohet gjithashtu kur ruteri PIM-SM merr një Raport Anëtarësimi IGMP nga një host i lidhur drejtpërdrejt.

Le të imagjinojmë se kemi një klient multicast në ruterin R5 për grupin 228.8.8.8. Sapo R5 merr Raportin e Anëtarësimit IGMP nga hosti, R5 dërgon një PIM Join në drejtim të RP-së ​​dhe vetë shton një ndërfaqe në pemën që shikon hostin. Më pas, R4 merr PIM Join nga R5, shton ndërfaqen Gi0/1 në pemë dhe dërgon PIM Join në drejtim të RP. Më në fund, RP (R3) merr PIM Join dhe shton Gi0/0 në pemë. Kështu, marrësi multicast regjistrohet. Po ndërtojmë një pemë me rrënjë R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Pas kësaj, një PIM Join do t'i dërgohet R1 dhe R1 do të fillojë të dërgojë trafik multicast. Është e rëndësishme të theksohet se nëse hosti ka kërkuar trafik përpara fillimit të transmetimit multicast, atëherë RP nuk do të dërgojë PIM Join dhe nuk do të dërgojë asgjë te R1.
Nëse befas gjatë dërgimit të një multicast, hosti pushon së dëshiruari ta marrë atë, sapo RP të marrë një PIM Prune në ndërfaqen Gi0/0, ai menjëherë do të dërgojë një PIM Register-Stop direkt te R1, dhe më pas një PIM Prune mesazh përmes ndërfaqes Gi0/1. PIM Register-stop dërgohet nëpërmjet unicast në adresën nga erdhi Regjistri PIM.
Siç thamë më herët, sapo një ruter dërgon një PIM Join te një tjetër, për shembull R5 në R4, atëherë një rekord i shtohet R4:

Dhe fillon një kohëmatës që R5 duhet të rivendosë vazhdimisht këtë kohëmatës PIM Join mesazhet vazhdimisht, përndryshe R4 do të përjashtohet nga lista dalëse. R5 do të dërgojë çdo 60 mesazhe PIM Join.
Ndërrimi i pemës me shtegun më të shkurtër.
Ne do të shtojmë një ndërfaqe midis R1 dhe R5 dhe do të shohim se si rrjedh trafiku me këtë topologji.

Le të supozojmë se trafiku është dërguar dhe marrë sipas skemës së vjetër R1-R2-R3-R4-R5, dhe këtu kemi lidhur dhe konfiguruar ndërfaqen midis R1 dhe R5.
Para së gjithash, ne duhet të rindërtojmë tabelën e rrugëzimit unicast në R5 dhe tani rrjeti 192.168.1.0/24 arrihet përmes ndërfaqes R5 Gi0/2. Tani R5, duke marrë multicast në ndërfaqen Gi0/1, e kupton që rregulli RPF nuk është i kënaqur dhe do të ishte më logjike të merrte multicast në Gi0/2. Duhet të shkëputet nga RPT dhe të ndërtojë një pemë më të shkurtër të quajtur Pema e Rrugës më të Shkurtër (SPT). Për ta bërë këtë, ai dërgon PIM Join në R0 përmes Gi2/1 dhe R1 fillon të dërgojë një multicast gjithashtu përmes Gi0/2. Tani R5 duhet të çabonohet nga RPT në mënyrë që të mos marrë dy kopje. Për ta bërë këtë, ai i dërgon Prune një mesazh që tregon adresën IP të burimit dhe fut një bit të veçantë - RPT-bit. Kjo do të thotë që ju nuk keni nevojë të më dërgoni trafik, unë kam një pemë më të mirë këtu. RP gjithashtu dërgon mesazhe PIM Prune te R1, por nuk dërgon një mesazh Register-Stop. Një veçori tjetër: R5 tani do të dërgojë vazhdimisht PIM Prune në RP, pasi R1 vazhdon të dërgojë Regjistrin PIM në RP çdo minutë. Derisa të mos ketë njerëz të rinj që duan këtë trafik, RP do ta refuzojë atë. R5 njofton RP se vazhdon të marrë multicast nëpërmjet SPT.
Kërkimi dinamik RP.
Auto-RP.
Kjo teknologji është pronë e Cisco-s dhe nuk është veçanërisht e popullarizuar, por është ende e gjallë. Funksionimi Auto-RP përbëhet nga dy faza kryesore:
1) RP dërgon mesazhe RP-Njoftoni në adresën e rezervuar - 224.0.1.39, duke u deklaruar RP ose për të gjithë ose për grupe të veçanta. Ky mesazh dërgohet çdo minutë.
2) Kërkohet një agjent i hartës RP, i cili do të dërgojë mesazhe RP-Discovery duke treguar se për cilat grupe duhet të dëgjohen RP. Është nga ky mesazh që ruterat e rregullt PIM do të përcaktojnë RP për veten e tyre. Agjenti i hartës mund të jetë ose vetë ruteri RP ose një ruter i veçantë PIM. RP-Discovery dërgohet në adresën 224.0.1.40 me një kohëmatës prej një minutë.
Le të shohim procesin në më shumë detaje:
Le të konfigurojmë R3 si RP:

ip pim send-rp-njoftoj loopback 0 shtrirja 10

R2 si agjent hartografik:

ip pim send-rp-discovery loopback 0 shtrirja 10

Dhe për të gjitha të tjerat do të presim RP përmes Auto-RP:

ip pim autorp dëgjues

Pasi të konfigurojmë R3, ai do të fillojë të dërgojë RP-Announce:

Dhe R2, pas konfigurimit të agjentit të hartës, do të fillojë të presë për mesazhin RP-Announce. Vetëm kur të gjejë të paktën një RP, do të fillojë të dërgojë RP-Discovery:

Në këtë mënyrë, sapo ruterat e rregullt (PIM RP Degjues) të marrin këtë mesazh, ata do të dinë se ku të kërkojnë RP-në.
Një nga problemet kryesore me Auto-RP është se për të marrë mesazhe RP-Announce dhe RP-Discovery, duhet të dërgoni PIM Join në adresat 224.0.1.39-40, dhe për të dërguar, duhet të dini se ku RP ndodhet. Problemi klasik i pulës dhe vezëve. Për të zgjidhur këtë problem, u shpik modaliteti PIM Sparse-Dense-Mode. Nëse ruteri nuk e njeh RP, atëherë ai funksionon në modalitetin e dendur; nëse e njeh, atëherë në modalitetin e rrallë. Kur modaliteti i rrallë PIM dhe komanda e dëgjuesit autorp ip pim janë konfiguruar në ndërfaqet e ruterave të rregullt, ruteri do të funksionojë në modalitetin e dendur vetëm për transmetim të shumëfishtë direkt nga protokolli Auto-RP (224.0.1.39-40).
Router BootStrap (BSR).
Ky funksion funksionon ngjashëm me Auto-RP. Çdo RP i dërgon një mesazh agjentit të hartës, i cili mbledh informacionin e hartës dhe më pas u tregon të gjithë ruterave të tjerë. Le ta përshkruajmë procesin në mënyrë të ngjashme me Auto-RP:
1) Pasi të konfigurojmë R3 si kandidat për të qenë RP, me komandën:

ip pim rp-kandidati loopback 0

Atëherë R3 nuk do të bëjë asgjë; për të filluar dërgimin e mesazheve speciale, ai së pari duhet të gjejë një agjent hartash. Kështu kalojmë në hapin e dytë.
2) Konfiguro R2 si një agjent hartës:

ip pim bsr-kandidati loopback 0

R2 fillon të dërgojë mesazhe PIM Bootstrap, ku tregon veten si një agjent hartash:

Ky mesazh dërgohet në adresën 224.0.013, të cilën protokolli PIM e përdor edhe për mesazhet e tjera të tij. I dërgon në të gjitha drejtimet dhe për këtë arsye nuk ka asnjë problem me pulën dhe vezët siç ishte në Auto-RP.
3) Sapo RP të marrë një mesazh nga ruteri BSR, do të dërgojë menjëherë një mesazh unicast në adresën e ruterit BSR:

Pas së cilës, BSR, pasi ka marrë informacione për RP-të, do t'i dërgojë ato me multicast në adresën 224.0.0.13, e cila dëgjohet nga të gjithë ruterat PIM. Prandaj, një analog i komandës ip pim autorp dëgjues për ruterat e rregullt jo në BSR.
Anycast RP me Multicast Source Discovery Protocol (MSDP).
Auto-RP dhe BSR na lejojnë të shpërndajmë ngarkesën në RP si më poshtë: Çdo grup multicast ka vetëm një RP aktive. Nuk do të jetë e mundur të shpërndahet ngarkesa për një grup multicast mbi disa RP. MSDP e bën këtë duke lëshuar ruterat RP të njëjtën adresë IP me një maskë prej 255.255.255.255. MSDP mëson informacionin duke përdorur një nga metodat: statike, Auto-RP ose BSR.

Në foto kemi një konfigurim Auto-RP me MSDP. Të dy RP-të janë konfiguruar me adresën IP 172.16.1.1/32 në ndërfaqen Loopback 1 dhe përdoren për të gjitha grupet. Me RP-Announce, të dy ruterët shpallin veten duke iu referuar kësaj adrese. Agjenti i hartës Auto-RP, pasi ka marrë informacionin, dërgon RP-Discovery rreth RP me adresën 172.16.1.1/32. Ne u tregojmë ruterave për rrjetin 172.16.1.1/32 duke përdorur IGP dhe, në përputhje me rrethanat. Kështu, ruterët PIM kërkojnë ose regjistrojnë flukse nga RP që është specifikuar si hop tjetër në rrugën drejt rrjetit 172.16.1.1/32. Vetë protokolli MSDP është krijuar që vetë RP-të të shkëmbejnë mesazhe rreth informacionit multicast.
Konsideroni këtë topologji:

Switch6 transmeton trafikun në adresën 238.38.38.38 dhe deri më tani vetëm RP-R1 di për të. Switch7 dhe Switch8 kërkuan këtë grup. Routerët R5 dhe R4 do të dërgojnë PIM Join tek R1 dhe R3, respektivisht. Pse? Rruga për në 13.13.13.13 për R5 do t'i referohet R1 duke përdorur metrikën IGP, ashtu si për R4.
RP-R1 di për transmetimin dhe do të fillojë ta transmetojë atë drejt R5, por R4 nuk di asgjë për të, pasi R1 thjesht nuk do ta dërgojë atë. Prandaj MSDP është i nevojshëm. Ne e konfigurojmë atë në R1 dhe R5:

ip msdp peer 3.3.3.3 Connect-source Loopback1 në R1

ip msdp peer 1.1.1.1 Connect-source Loopback3 në R3

Ata do të ngrenë një seancë midis njëri-tjetrit dhe kur marrin ndonjë rrjedhë, ata do ta raportojnë atë tek fqinji i tyre RP.
Sapo RP-R1 të marrë një transmetim nga Switch6, do të dërgojë menjëherë një mesazh unicast MSDP Source-Active, i cili do të përmbajë informacione si (S, G) - informacion rreth burimit dhe destinacionit të multicast. Tani që RP-R3 e di se një burim i tillë si Switch6, kur merr një kërkesë nga R4 për këtë rrjedhë, ai do të dërgojë PIM Join drejt Switch6, i udhëhequr nga tabela e rrugëzimit. Rrjedhimisht, R1 pasi ka marrë një PIM Join të tillë do të fillojë të dërgojë trafik drejt RP-R3.
MSDP kalon mbi TCP, RP-të i dërgojnë njëri-tjetrit mesazhe të qëndrueshme për të kontrolluar gjallërinë. Kohëmatësi është 60 sekonda.
Funksioni i ndarjes së kolegëve MSDP në fusha të ndryshme mbetet i paqartë, pasi mesazhet e Keepalive dhe SA nuk tregojnë anëtarësimin në asnjë domen. Gjithashtu, në këtë topologji, ne testuam një konfigurim që tregon fusha të ndryshme - nuk kishte asnjë ndryshim në performancë.
Nëse dikush mund të sqarojë, do të jem i lumtur ta lexoj në komente.

Burimi: www.habr.com