Multicast routing – PIM SM Part 1

feb
2013
19

skrevet af i Netværk

Ingen kommentarer

Hej alle sammen! Efter kortere pause fra arbejde her på side, pga. af mine forpligtelser, jeg vender nu tilbage og vil gerne starte endnu en emne som kan være guldåre eller værste mareridt i konfiguration af netværk.

IP Multicast routing er et af de emner hvor flest af netværks folk altid kæmpe med. Gennem den her artikel, vil jeg snakke om en af de “tynge” emner, netop Multicast routing og præcis om PIM udgave. Her vil jeg ikke forklare det grundlegende om Multicast eller hvad PIM er. Jeg vil undersøge sender (Source) registrerings processen. Dette er en af tre stillinger, som jeg vil undersøge i denne proces. Først vil jeg kigge lidt hvad er sender registrering? I Sparse-mode Multicast netværk, et af de design mål er at begrænse den mængde trafik, der unødvendigt sendes (oversvømmet) i hele topologi.
Oversvømmelser som jeg taler om, er den proces, der anvendes af Dense -mode Multicast til at “informere” Multicast routere om tilstedeværelse af Multicast sender (Source). For at opsummere hurtigt, i Dense-mode netværk, når sender begynder at sende trafik, vil disse data blive at oversvømme hele netværket og derefter beskæres fra dele, hvor det ikke er nødvendige, dvs. hvor der ikke er modtager (Client), der søger at modtage denne trafik. Denne oversvømmelse-and-prune proces gentages hver tredje minutten. Dette er ikke en optimal proces, men det løser problemet med bevarelse af små Multicast routing tabeller i routere og hjælpe at give sender oplysninger til alle routere i topologi.
I Sparse-mode netværk, er ideen at holde små Multicast router tabeller og samtidig at undgå oversvømmelse-and-prune proces, som vi har i Dense-mode, når det er muligt. For at opnå dette mål, har vi behov for en mødested (Rendezvous point – RP), så routere med sendere kan registreres der. Samtidig der er sted, hvor routere med modtagere kan kigge efter aktive sendere. Dette møde sted er en router, der er udpeget til at være mødested (RP).
RP er routeren som har viden om alle aktive sendere i netværket. For at nå dette mål, alle routere, der har direkte knyttet sendere skal registrere dem hos RP. Denne registrering er selvfølgelig “PIM Register” som jeg vil gerne forklare i dag.

Nedenfor har vi et netværk som vi kan bruge til vores gennemgang af problematikken:

Som vi kan se på diagrammet, vil vi bruge eksempel med tre routere og to andre enheder hvor:
• Multicast sender deltager ikke i Multicast routing, dvs. det behøver ikke at køre hverken PIM eller IGMP.
• Multicast modtager vil anmode trafik for en bestemt gruppe med IGMP.
• De tre Multicast routere er konfigureret til at køre PIM Sparse-mode blandt dem.

Alt i alt er dette et temmelig grundlæggende IP Multicast routing topologi.

Men, vi kan ikke begunde med læring uden at vi stiler første spørgsmål:
Hvordan sender registrerer sin eksistens hos RP, hvis denne deltager ikke selv i Multicast routing?

Svaret er simpelt – det gør den ikke. Alt som sender har behov for, er at være i stand at generere IP-trafik med destination IP-adresse. I dette her tilfalde der er IP-adresse i en gyldig IP Multicast område: 224.0.0.0 / 4 (224.0.0.0 – 239.255.255.255).

Næste spørgsmål:
Hvis sender ikke registreres hos RP, hvordan så RP vide om det?

Dette er et af de ansvarsområder som ”ligger” hos første hop router, eller routeren, som er direkte forbundet til sender. Når en Multicast sender begynder at sende trafikken, og denne trafik når første-hop-router, vil denne router gøre flere ting.

1. Sender begynder at sende trafikken.
2. Multicast state (S, G) er skabt på FHR, hvor S er sender IP-adressen, og G er gruppen adresse (multicast destination IP-adresse af pakkerne).
3. Multicast trafik er indkapslet i unicast pakker og sendes mod RP.
4. Ved modtagelse af unicast trafik og afkapsler originale multicast-pakker, opretter RP lokal (S, G) tilstand
Bemærk at der ikke vil være multicast-trafik som nu videresendes i retning af RP – det vil være unicast. Denne unicast trafik er sender registrering. Vi kan sige disse ting kommer til at ske “samtidigt”, men i virkeligheden sker i rækkefølge. Det er vigtigt at holde dette i tankerne, når I kommer at fejlfinde i levende netværk! Her, for lab miljø, kan vi behandle disse som samtidige begivenheder.

Som vi kan konkludere, på dette tidspunkt, ved afslutning af punktet 4. er sender registreret hos RP. Hvad der sker herefter, afhænger af, om RP har kendskab til modtagere, der ønsker at modtage denne trafik eller ej. Dette efterlader os med følgende muligheder:
• Sender begynder at sende trafik, før der er nogen interesserede modtagere (klienter).
• Modtagere tilmelder sig gruppen, før sender begynder at sende.
• Der er kunder direkte forbundet til FHR eller RP.

Disse vil jeg snakke ved de neste artikler og forklare grundig teoretisk set.
Inden da god fornøjelse og held og lykke med Multicast routing.

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

Skriv kommentar