El protocol PIM és un conjunt de protocols per transmetre multicast en una xarxa entre encaminadors. Les relacions de veïnatge es construeixen de la mateixa manera que en el cas dels protocols d'encaminament dinàmic. PIMv2 envia missatges de salutació cada 30 segons a l'adreça de multidifusió reservada 224.0.0.13 (Tots els encaminadors PIM). El missatge conté temporitzadors de retenció, normalment iguals a 3.5 * Hola temporitzador, és a dir, 105 segons per defecte.
PIM utilitza dos modes de funcionament principals: el mode dens i el mode escàs. Comencem amb el mode Dens.
Arbres de distribució basats en fonts.
S'aconsella utilitzar el mode dens en el cas d'un gran nombre de clients de diferents grups multicast. Quan un encaminador rep trànsit multicast, el primer que fa és comprovar-ho per la regla RPF. RPF: aquesta regla s'utilitza per comprovar l'origen d'una multidifusió amb una taula d'encaminament unicast. Cal que el trànsit arribi a la interfície darrere de la qual s'amaga aquest host segons la versió de la taula d'encaminament unicast. Aquest mecanisme resol el problema d'un bucle que es produeix durant la transmissió multicast.
L'R3 reconeixerà la font de multidifusió (IP de la font) del missatge de multidifusió i comprovarà els dos fluxos de R1 i R2 mitjançant la seva taula unicast. El flux de la interfície apuntat per la taula (R1 a R3) es transmetrà més endavant, i el flux de R2 s'eliminarà, ja que per arribar a la font de multidifusió, cal enviar paquets mitjançant S0/1.
La pregunta és, què passa si teniu dues rutes equivalents amb la mateixa mètrica? En aquest cas, l'encaminador seleccionarà el següent salt d'aquestes rutes. Guanya qui tingui l'adreça IP més alta. Si necessiteu canviar aquest comportament, podeu utilitzar ECMP. Més detalls .
Després de comprovar la regla RPF, l'encaminador envia un paquet de multidifusió a tots els seus veïns PIM, excepte a aquell de qui s'ha rebut el paquet. Altres encaminadors PIM repeteixen aquest procés. El camí que un paquet de multidifusió ha pres des de la font fins als destinataris finals forma un arbre anomenat arbre de distribució basat en font, arbre de camí més curt (SPT), arbre font. Tres noms diferents, tria qualsevol.
Com resoldre el problema que alguns encaminadors no van renunciar a algun flux multicast i no hi ha ningú a qui l'enviï, però l'encaminador amunt li ho envia. Per a això es va inventar el mecanisme Prune.
Missatge de poda.
Per exemple, R2 continuarà enviant una multidifusió a R3, tot i que R3, segons la regla RPF, l'elimina. Per què carregar el canal? L'R3 envia un missatge PIM Prune i l'R2, en rebre aquest missatge, eliminarà la interfície S0/1 de la llista d'interfícies de sortida per a aquest flux, la llista d'interfícies des de les quals s'ha d'enviar aquest trànsit.
La següent és una definició més formal d'un missatge PIM Prune:
El missatge PIM Prune l'envia un encaminador a un segon encaminador per fer que el segon encaminador suprimi l'enllaç on es rep el Prune d'un SPT (S,G) particular.
Després de rebre el missatge Prune, R2 estableix el temporitzador de Prune a 3 minuts. Després de tres minuts, tornarà a enviar trànsit fins que rebi un altre missatge Prune. Això és a PIMv1.
I a PIMv2 s'ha afegit un temporitzador d'actualització d'estat (60 segons per defecte). Tan bon punt s'ha enviat un missatge Prune des de l'R3, aquest temporitzador s'inicia a l'R3. Un cop expirat aquest temporitzador, R3 enviarà un missatge d'actualització de l'estat, que restablirà el temporitzador de poda de 3 minuts a R2 per a aquest grup.
Motius per enviar un missatge Prune:
- Quan un paquet de multidifusió falla la comprovació RPF.
- Quan no hi ha clients connectats localment que hagin sol·licitat un grup de multidifusió (IGMP Join) i no hi ha veïns PIM als quals es pugui enviar trànsit multicast (Interfície no poda).
Missatge d'empelt.
Imaginem que R3 no volia trànsit de R2, va enviar Prune i va rebre una multidifusió de R1. Però de sobte, el canal entre R1-R3 va caure i R3 es va quedar sense multicast. Podeu esperar 3 minuts fins que caduqui el temporitzador de poda de l'R2. 3 minuts és una llarga espera, per no esperar, heu d'enviar un missatge que a l'instant portarà aquesta interfície S0/1 a R2 fora de l'estat de poda. Aquest missatge serà un missatge d'empelt. Després de rebre el missatge Graft, R2 respondrà amb un Graft-ACK.
Anul·lació de poda.
Vegem aquest diagrama. R1 emet multicast a un segment amb dos encaminadors. R3 rep i emet trànsit, R2 rep, però no té ningú a qui transmetre trànsit. Envia un missatge Prune a R1 en aquest segment. L'R1 hauria d'eliminar Fa0/0 de la llista i deixar d'emetre en aquest segment, però què passarà amb l'R3? I R3 està en el mateix segment, també va rebre aquest missatge de Prune i va entendre la tragèdia de la situació. Abans que R1 deixi d'emetre, estableix un temporitzador de 3 segons i deixarà d'emetre després de 3 segons. 3 segons: això és exactament el temps que té R3 per no perdre la seva multidifusió. Per tant, R3 envia un missatge de Pim Join per a aquest grup tan aviat com sigui possible, i R1 ja no pensa en aturar l'emissió. Sobre Unir-se als missatges següents.
Afirma el missatge.
Imaginem aquesta situació: dos encaminadors emeten a una xarxa alhora. Reben el mateix flux de la font i tots dos l'emeten a la mateixa xarxa darrere de la interfície e0. Per tant, han de determinar qui serà l'únic emissor d'aquesta xarxa. Per a això s'utilitzen missatges d'afirmació. Quan R2 i R3 detecten la duplicació del trànsit multicast, és a dir, R2 i R3 reben una multicast que ells mateixos emeten, els encaminadors entenen que hi ha alguna cosa malament. En aquest cas, els encaminadors envien missatges Assert, que inclouen la distància administrativa i la mètrica de ruta amb què s'arriba a la font de multidifusió: 10.1.1.10. El guanyador es determina de la següent manera:
- El d'AD inferior.
- Si AD són iguals, llavors qui té la mètrica més baixa.
- Si aquí hi ha igualtat, llavors el que té la IP més alta a la xarxa a la qual emeten aquesta multidifusió.
El guanyador d'aquesta votació es converteix en l'encaminador designat. Pim Hello també s'utilitza per seleccionar DR. Al principi de l'article, es va mostrar el missatge PIM Hello, hi podeu veure el camp DR. Guanya el que tingui l'adreça IP més alta en aquest enllaç.
Senyal útil:
Taula MROUTE.
Després d'una primera mirada a com funciona el protocol PIM, hem d'entendre com treballar amb una taula d'encaminament multicast. La taula mroute emmagatzema informació sobre quins fluxos s'han sol·licitat als clients i quins fluxos flueixen dels servidors de multidifusió.
Per exemple, quan es rep un informe de pertinença a IGMP o una unió a PIM en alguna interfície, s'afegeix un registre de tipus ( *, G ) a la taula d'encaminament:
Aquesta entrada significa que s'ha rebut una sol·licitud de trànsit amb l'adreça 238.38.38.38. El senyalador DC significa que la multidifusió funcionarà en mode dens i C significa que el destinatari està connectat directament a l'encaminador, és a dir, l'encaminador ha rebut l'informe de pertinença a IGMP i la unió a PIM.
Si hi ha un registre de tipus (S,G) vol dir que tenim un flux multicast:
Al camp S - 192.168.1.11, hem registrat l'adreça IP de la font multicast, és aquesta la que es comprovarà per la regla RPF. Si hi ha problemes, el primer que heu de fer és comprovar la taula d'unicast per a la ruta a la font. Al camp Interfície d'entrada, indica la interfície a la qual es rep la multidifusió. En una taula d'encaminament unicast, la ruta a la font ha de fer referència a la interfície especificada aquí. La interfície de sortida especifica on es redirigirà la multidifusió. Si està buit, l'encaminador no ha rebut cap sol·licitud d'aquest trànsit. Podeu trobar més informació sobre totes les banderes .
PIM Mode escàs.
L'estratègia del mode escàs és l'oposada al mode dens. Quan el mode escàs rep trànsit multicast, només enviarà trànsit a través d'aquelles interfícies on hi ha hagut sol·licituds per a aquest flux, per exemple, missatges de Pim Join o IGMP Report que demanen aquest trànsit.
Elements similars per a SM i DM:
- Les relacions de veïnatge es construeixen de la mateixa manera que a PIM DM.
- La regla de l'RPF funciona.
- La selecció de DR és similar.
- El mecanisme dels missatges Prune Overrides i Assert és similar.
Per controlar qui, on i quin tipus de trànsit multicast es necessita a la xarxa, cal un centre d'informació comú. El nostre centre serà Rendezvous Point (RP). Qualsevol que vulgui algun tipus de trànsit multicast o algú va començar a rebre trànsit multicast des de la font, llavors l'envia a RP.
Quan l'RP rebi trànsit multicast, l'enviarà a aquells encaminadors que prèviament han sol·licitat aquest trànsit.
Imaginem una topologia on RP és R3. Tan bon punt R1 rep trànsit de S1, encapsula aquest paquet multicast en un missatge de registre PIM unicast i l'envia a RP. Com sap qui és el RP? En aquest cas, es configura estàticament, i de la configuració dinàmica de RP parlarem més endavant.
ip pim rp-address 3.3.3.3
RP mirarà: hi havia informació d'algú a qui li agradaria rebre aquest trànsit? Suposem que no ho era. A continuació, RP enviarà a R1 un missatge PIM Register-Stop, el que significa que ningú necessita aquesta multidifusió, el registre es denega. R1 no enviarà multicast. Però l'amfitrió d'origen multicast l'enviarà, de manera que R1, després de rebre Register-Stop, iniciarà un temporitzador de supressió de registre igual a 60 segons. 5 segons abans que expiri aquest temporitzador, R1 enviarà un missatge de registre buit amb un bit de registre nul (és a dir, sense un paquet de multidifusió encapsulat) cap a RP. RP, al seu torn, actuarà així:
- Si no hi havia destinataris, respondrà amb un missatge de parada de registre.
- Si apareixen els destinataris, no hi respondrà de cap manera. R1, no havent rebut una negativa a registrar-se en 5 segons, estarà content i enviarà un missatge de registre amb una multidifusió encapsulada a RP.
Sembla que hem descobert com la multidifusió arriba a RP, ara intentem respondre a la pregunta de com RP ofereix trànsit als destinataris. Aquí cal introduir un nou concepte: l'arbre de ruta arrel (RPT). RPT és un arbre arrelat a RP, que creix cap als destinataris, ramificant-se a cada encaminador PIM-SM. RP el crea rebent missatges PIM Join i afegeix una branca nova a l'arbre. I per tant, tots els encaminadors aigües avall ho fan. La regla general es veu així:
- Quan un encaminador PIM-SM rep un missatge PIM Join en qualsevol interfície que no sigui la interfície darrere de la qual s'amaga el RP, afegeix una nova branca a l'arbre.
- També s'afegeix una branca quan l'encaminador PIM-SM rep un informe de pertinença a IGMP d'un host connectat directament.
Imaginem que tenim un client multicast al router R5 per al grup 228.8.8.8. Tan bon punt l'R5 rep l'informe de pertinença a l'IGMP de l'amfitrió, l'R5 envia una unió PIM en direcció a l'RP i afegeix una interfície a l'arbre que mira l'amfitrió. A continuació, R4 rep PIM Join de R5, afegeix la interfície Gi0/1 a l'arbre i envia PIM Join en direcció a RP. Finalment, RP ( R3 ) rep PIM Join i afegeix Gi0/0 a l'arbre. Així, es registra el destinatari multicast. Estem construint un arbre amb l'arrel R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Després d'això, s'enviarà un PIM Join a R1 i R1 començarà a enviar trànsit multicast. És important tenir en compte que si l'amfitrió va sol·licitar trànsit abans que comencés l'emissió multicast, aleshores RP no enviarà PIM Join i no enviarà res a R1.
Si de sobte mentre s'envia una multidifusió, l'amfitrió deixa de voler rebre-la, tan bon punt RP rep un PIM Prune a la interfície Gi0/0, immediatament enviarà un PIM Register-Stop directament a R1 i després un PIM Prune. missatge a través de la interfície Gi0/1. PIM Register-stop s'envia mitjançant unicast a l'adreça d'on prové el PIM Register.
Com hem dit anteriorment, tan bon punt un encaminador envia una unió PIM a un altre, per exemple, R5 a R4, s'afegeix un registre a R4:
I s'inicia un temporitzador que l'R5 ha de reiniciar constantment aquest temporitzador PIM Join missatges constantment, en cas contrari, R4 quedarà exclòs de la llista de sortida. R5 enviarà cada 60 missatges PIM Join.
Canvi de l'arbre del camí més curt.
Afegirem una interfície entre R1 i R5 i veurem com flueix el trànsit amb aquesta topologia.
Suposem que el trànsit es va enviar i rebre segons l'antic esquema R1-R2-R3-R4-R5, i aquí vam connectar i configurar la interfície entre R1 i R5.
En primer lloc, hem de reconstruir la taula d'encaminament unicast a R5 i ara s'accedeix a la xarxa 192.168.1.0/24 a través de la interfície R5 Gi0/2. Ara R5, rebent multicast a la interfície Gi0/1, entén que la regla RPF no es compleix i seria més lògic rebre multicast a Gi0/2. Hauria de desconnectar-se de RPT i construir un arbre més curt anomenat arbre de camí més curt (SPT). Per fer-ho, envia PIM Join a R0 a través de Gi2/1 i R1 comença a enviar una multidifusió també a través de Gi0/2. Ara R5 ha de donar-se de baixa de RPT per no rebre dues còpies. Per fer-ho, envia a Prune un missatge indicant l'adreça IP d'origen i inserint un bit especial: bit RPT. Això vol dir que no cal que m'enviïs trànsit, aquí tinc un arbre millor. RP també envia missatges PIM Prune a R1, però no envia cap missatge Register-Stop. Una altra característica: ara R5 enviarà contínuament PIM Prune a RP, ja que R1 continua enviant PIM Register a RP cada minut. Fins que no hi hagi gent nova que vulgui aquest trànsit, RP ho rebutjarà. R5 notifica a RP que continua rebent multidifusió mitjançant SPT.
Cerca dinàmica de RP.
Auto-RP.
Aquesta tecnologia és propietat de Cisco i no és especialment popular, però encara està viva. El funcionament d'Auto-RP consta de dues etapes principals:
1) RP envia missatges RP-Announce a l'adreça reservada - 224.0.1.39, declarant-se RP per a tothom o per a grups específics. Aquest missatge s'envia cada minut.
2) Es requereix un agent de mapeig RP, que enviarà missatges RP-Discovery indicant per a quins grups s'ha d'escoltar quin RP. És a partir d'aquest missatge que els encaminadors PIM regulars determinaran el RP per ells mateixos. L'agent de mapes pot ser el propi encaminador RP o un encaminador PIM independent. RP-Discovery s'envia a l'adreça 224.0.1.40 amb un temporitzador d'un minut.
Vegem el procés amb més detall:
Configurem R3 com a RP:
ip pim send-rp-announce loopback 0 àmbit 10
R2 com a agent de mapes:
ip pim send-rp-discovery loopback 0 àmbit 10
I en tots els altres esperarem RP mitjançant Auto-RP:
ip pim autorp listener
Un cop configurem R3, començarà a enviar RP-Announce:
I R2, després de configurar l'agent de mapes, començarà a esperar el missatge RP-Announce. Només quan trobi almenys un RP començarà a enviar RP-Discovery:
D'aquesta manera, tan bon punt els encaminadors habituals (PIM RP Listener) rebin aquest missatge, sabran on buscar el RP.
Un dels principals problemes amb Auto-RP és que per rebre missatges RP-Announce i RP-Discovery, cal que envieu PIM Join a les adreces 224.0.1.39-40, i per enviar-los, heu de saber on RP es troba. Problema clàssic de la gallina i l'ou. Per resoldre aquest problema, es va inventar el mode dens dispers PIM. Si l'encaminador no coneix RP, llavors funciona en mode dens; si ho fa, en mode escàs. Quan el mode dispers PIM i l'ordre ip pim autorp listener es configuren a les interfícies dels encaminadors normals, l'encaminador funcionarà en mode dens només per a la multidifusió directament des del protocol Auto-RP (224.0.1.39-40).
Encaminador BootStrap (BSR).
Aquesta funció funciona de manera similar a Auto-RP. Cada RP envia un missatge a l'agent de mapes, que recull la informació de mapes i després l'informa a la resta d'encaminadors. Descrivim el procés de manera similar a Auto-RP:
1) Un cop configurem R3 com a candidat a ser RP, amb l'ordre:
ip pim rp-candidate loopback 0
Aleshores, R3 no farà res; per començar a enviar missatges especials, primer ha de trobar un agent de mapes. Per tant, passem al segon pas.
2) Configureu R2 com a agent de mapes:
ip pim bsr-candidate loopback 0
R2 comença a enviar missatges PIM Bootstrap, on s'indica com a agent de mapes:
Aquest missatge s'envia a l'adreça 224.0.013, que el protocol PIM també utilitza per als seus altres missatges. Els envia en totes direccions i, per tant, no hi ha cap problema amb ous i gallines com hi havia a Auto-RP.
3) Tan bon punt l'RP rebi un missatge de l'encaminador BSR, enviarà immediatament un missatge unicast a l'adreça de l'encaminador BSR:
Després d'això, el BSR, després d'haver rebut informació sobre els RP, els enviarà per multicast a l'adreça 224.0.0.13, que és escoltada per tots els encaminadors PIM. Per tant, un anàleg de la comanda ip pim autorp listener per a encaminadors normals que no són a BSR.
Anycast RP amb Multicast Source Discovery Protocol (MSDP).
Auto-RP i BSR ens permeten distribuir la càrrega en RP de la següent manera: Cada grup multicast només té un RP actiu. No serà possible distribuir la càrrega per a un grup de multidifusió entre diversos RP. MSDP ho fa emetent als encaminadors RP la mateixa adreça IP amb una màscara de 255.255.255.255. MSDP aprèn informació mitjançant un dels mètodes: estàtic, Auto-RP o BSR.
A la imatge tenim una configuració Auto-RP amb MSDP. Tots dos RP estan configurats amb l'adreça IP 172.16.1.1/32 a la interfície Loopback 1 i s'utilitzen per a tots els grups. Amb RP-Announce, tots dos encaminadors s'anuncien fent referència a aquesta adreça. L'agent de mapes Auto-RP, després d'haver rebut la informació, envia RP-Discovery sobre el RP amb l'adreça 172.16.1.1/32. Expliquem als encaminadors sobre la xarxa 172.16.1.1/32 mitjançant IGP i, en conseqüència. Així, els encaminadors PIM sol·liciten o registren fluxos des de l'RP que s'especifica com el següent salt de la ruta a la xarxa 172.16.1.1/32. El propi protocol MSDP està dissenyat perquè els mateixos RP intercanviïn missatges sobre informació multicast.
Considereu aquesta topologia:
Switch6 emet trànsit a l'adreça 238.38.38.38 i fins ara només RP-R1 ho sap. Switch7 i Switch8 han sol·licitat aquest grup. Els encaminadors R5 i R4 enviaran PIM Join a R1 i R3, respectivament. Per què? La ruta a 13.13.13.13 per a R5 es referirà a R1 mitjançant la mètrica IGP, igual que per a R4.
RP-R1 sap sobre el flux i començarà a emetre-lo cap a R5, però R4 no en sap res, ja que R1 no l'enviarà simplement. Per tant, MSDP és necessari. Ho configurem a R1 i R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 a R1
ip msdp peer 1.1.1.1 connect-source Loopback3 a R3
Aixecaran una sessió entre ells i quan rebin qualsevol flux ho comunicaran al seu veí de RP.
Tan bon punt RP-R1 rebi un flux d'Switch6, enviarà immediatament un missatge MSDP Font-Active unicast, que contindrà informació com (S, G) - informació sobre l'origen i destinació de la multidifusió. Ara que RP-R3 sap que una font com Switch6, quan rep una sol·licitud de R4 per a aquest flux, enviarà PIM Join cap a Switch6, guiat per la taula d'encaminament. En conseqüència, l'R1 després d'haver rebut aquesta unió PIM començarà a enviar trànsit cap a RP-R3.
MSDP s'executa a través de TCP, els RP s'envien missatges de manteniment entre ells per comprovar la vivacitat. El temporitzador és de 60 segons.
La funció de dividir els companys de MSDP en diferents dominis encara no està clara, ja que els missatges Keepalive i SA no indiquen pertinença a cap domini. A més, en aquesta topologia, vam provar una configuració que indicava diferents dominis; no hi havia cap diferència de rendiment.
Si algú ho pot aclarir, m'agradaria llegir-ho als comentaris.
Font: www.habr.com