Multicast routing – PIM SM Part 2

feb
2013
20

skrevet af i Netværk

Ingen kommentarer

I den første artikel i denne serie, undersøgte jeg processen hvor sender bliver registreret i PIM, og vi sluttede ved situation hvor RP er bekendt med senders eksistens. Jeg identificerede tre mulige scenarier på dette punkt, og i dag vil vi undersøge scenarie, hvor sender er registreret, men der er ingen modtagere som er interesseret i at modtage denne trafik. For at fortsætte undersøgelsen af PIM sender registrerings processen, vil vi bruge følgende diagram, der anvendes i den foregående artikel.

PIM_Reg1

Vi stoppede vores analyse på det tidspunkt, hvor sender er registreret hos RP. Men på dette tidspunkt, har sender endnu ikke tilsluttet sig den gruppe som er annonceret i staten, hvilket betyder, at RP er ikke bekendt med at dette overhovedet eksisterer. Multicast-trafik indkapslet som unicast som sendes fra FHR og behandles af RP er unødvendig. På grund af det, RP vil straks begynde at kassere denne trafik og sende unicast svar tilbage til FHR at stoppe med at sende det. Dette er den såkaldte “PIM Register Stop”. Når FHR modtager denne besked, vil den straks stoppe unicasting af multicast trafik fra sender til RP og begynde at også at kassere den. På billedet nedenfor har vi de trin fra PIM Registrerings proces, så lad os kigge kronologisk på dem.

PIM_Reg2

1. På dette tidspunkt (efter trin 4 i første artikel) indser RP at der ikke er direkte eller indirekte forbundne modtagere som er villige til at modtage trafik sendt til gruppe G. Det straks kasserer alle pakker, som sagt, men (S, G) tilstand, opbevares på RP.
2. Unicast meddelelse sendes til FHR at stoppe at sende de unicastede multicast registrering pakker.
3. FHR stopper registreringsprocessen og begynder straks at kassere indkommende pakker fra sender. Omregistrering timeren begynder at tælle ned fra 180 sekunder (3 minutter).
4. Sender er uvidende om noget foregår på FHR, og det heldigvis holder på at sende multicast trafik til FHR.

Jeg vil gerne påpege et punkt i trin # 3: Omregistrering timer. Så længe sender fortsætter til at sende multicast trafik til FHR, vil registreringsprocessen gentage hvert tredje minut. Grunden til dette er behovet for at opretholde RP informeret om tilstedeværelsen af kilden. Hvis sender stopper at sende multicast trafik i mellemtiden, vil både FHR og RP mister deres (S, G) hedder.
Hvad sker der, når kunden endelig slutter sig til gruppen? Lad os tage et kig. Jeg vil starte denne forklaring med et billede og tale igennem den.

PIM_Reg3

1. Mens sender (punkt 0) fortsat at sende, multicast trafik, modtager slutter sig til gruppe G ved hjælp af IGMP join.
2. Modtagers medlemskab rapport vil medføre Modtager router/DR (og alle andre PIM routere på segmentet) til at skabe lokal (*, G) tilstand, med modtager-vendende interface i udgående interface liste (olist) for (*, G).
3. DR genererer PIM join for (*, G) gruppe og sende den mod den kendte RP-adresse til gruppe G.
4. Da RP har (S, G) stat registreret i forvejen, og i kraft af multicast regler associerede (*, G) indgang i denne tabellen, vil det tilføje nedstrøms interface til DR, til udgående interface liste (olist) for denne (S, G). RP sender (S, G) join til sender via FHR at slutte dette mod sender.
5. FHR modtager join fra RP og tilføjer interface nedstrøms for RP til olist for (S, G). FHR stopper at kassere indgående multicast trafik sendt af vores sender og sender den videre ud fra alle de registrerede interfaces i “olist” for (S, G).
Bemærk: Join bliver ikke sendt fra FHR til sender, da der, som vi har snaget for, sender ved ikke hvad det foregår op i hierarkiet og hele tid sender multicast trafik mod FHR.
6. RP modtager nu multicast trafikken fra FHR, og den sender det ud til alle interfaces i “olist” for (S, G).
7. DR nu modtager trafik og videresender trafik ud alle interfaces i olist for (*, G), som har den virkning at modtageren modtager trafik som sendes af sender i gruppen (S,G).

Næste gang, vil vi tage et kig ind i, hvad der sker, når modtagere melder at de vil deltage i gruppen, og få multicast trafik, men der er ingen sender. God fornøjelse!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Skriv kommentar