O protocolo PIM é un conxunto de protocolos para transmitir multicast nunha rede entre enrutadores. As relacións de veciñanza constrúense do mesmo xeito que no caso dos protocolos de enrutamento dinámico. PIMv2 envía mensaxes de Ola cada 30 segundos ao enderezo de multidifusión reservado 224.0.0.13 (All-PIM-Routers). A mensaxe contén temporizadores de espera, normalmente iguais a 3.5*Hello Timer, é dicir, 105 segundos por defecto.
PIM usa dous modos de funcionamento principais: o modo Denso e o Modo Escasa. Comecemos co modo Denso.
Árbores de distribución baseadas na fonte.
O modo denso é recomendable no caso dun gran número de clientes de diferentes grupos de multidifusión. Cando un enrutador recibe tráfico multicast, o primeiro que fai é comprobar a regra RPF. RPF: esta regra úsase para comprobar a orixe dunha multidifusión cunha táboa de enrutamento unicast. É necesario que o tráfico chegue á interface detrás da cal este host está oculto segundo a versión da táboa de enrutamento unicast. Este mecanismo resolve o problema dun bucle que se produce durante a transmisión multicast.
R3 recoñecerá a fonte de multidifusión (IP fonte) da mensaxe de multidifusión e comprobará os dous fluxos de R1 e R2 usando a súa táboa de unidifusión. O fluxo desde a interface sinalada pola táboa (R1 a R3) transmitirase máis, e o fluxo de R2 abandonarase, xa que para chegar á fonte de multidifusión, cómpre enviar paquetes a través de S0/1.
A pregunta é, que pasa se tes dúas rutas equivalentes coa mesma métrica? Neste caso, o enrutador seleccionará o seguinte salto destas rutas. Gaña quen teña o enderezo IP máis alto. Se precisa cambiar este comportamento, pode utilizar ECMP. Máis detalles .
Despois de comprobar a regra RPF, o router envía un paquete de multidifusión a todos os seus veciños PIM, excepto a aquel de quen recibiu o paquete. Outros enrutadores PIM repiten este proceso. O camiño que tomou un paquete de multidifusión desde a orixe ata os destinatarios finais forma unha árbore chamada árbore de distribución baseada na fonte, árbore de camiños máis curtos (SPT), árbore de orixe. Tres nomes diferentes, escolle calquera.
Como resolver o problema de que algúns enrutadores non renunciaron a algún fluxo de multidifusión e non hai ninguén a quen envialo, pero o enrutador ascendente envíallo. Para iso inventouse o mecanismo Prune.
Mensaxe de poda.
Por exemplo, R2 seguirá enviando unha multidifusión a R3, aínda que R3, segundo a regra RPF, descarta. Por que cargar a canle? R3 envía unha mensaxe PIM Prune e R2, ao recibir esta mensaxe, eliminará a interface S0/1 da lista de interfaces de saída para este fluxo, a lista de interfaces desde as que se debe enviar este tráfico.
A seguinte é unha definición máis formal dunha mensaxe PIM Prune:
A mensaxe PIM Prune é enviada por un enrutador a un segundo enrutador para facer que o segundo enrutador elimine a ligazón na que se recibe o Prune dun determinado (S,G) SPT.
Despois de recibir a mensaxe de poda, R2 configura o temporizador de poda en 3 minutos. Despois de tres minutos, comezará a enviar tráfico de novo ata que reciba outra mensaxe de Prune. Isto está en PIMv1.
E en PIMv2 engadiuse un temporizador de actualización de estado (60 segundos por defecto). En canto se envía unha mensaxe de Prune desde R3, este temporizador iníciase no R3. Ao vencer este temporizador, R3 enviará unha mensaxe de actualización de estado, que restablecerá o temporizador de poda de 3 minutos en R2 para este grupo.
Motivos para enviar unha mensaxe Prune:
- Cando un paquete de multidifusión falla a comprobación RPF.
- Cando non hai clientes conectados localmente que solicitaron un grupo de multidifusión (IGMP Join) e non hai veciños PIM aos que se poida enviar tráfico de multidifusión (Interface non podada).
Mensaxe de enxerto.
Imaxinemos que R3 non quería tráfico de R2, enviou Prune e recibiu un multicast de R1. Pero de súpeto, a canle entre R1-R3 caeu e R3 quedou sen multicast. Podes esperar 3 minutos ata que caduque o temporizador de poda do R2. 3 minutos é unha longa espera, para non esperar, cómpre enviar unha mensaxe que faga instantaneamente que esta interface S0/1 saia do estado de poda a R2. Esta mensaxe será unha mensaxe de Graft. Despois de recibir a mensaxe Graft, R2 responderá cun Graft-ACK.
Anulación de poda.
Vexamos este diagrama. R1 transmite multicast a un segmento con dous enrutadores. R3 recibe e transmite tráfico, R2 recibe, pero non ten a quen transmitir tráfico. Envía unha mensaxe Prune a R1 neste segmento. R1 debería eliminar Fa0/0 da lista e deixar de emitir neste segmento, pero que pasará con R3? E R3 está no mesmo segmento, tamén recibiu esta mensaxe de Prune e entendeu a traxedia da situación. Antes de que R1 deixe de emitir, establece un temporizador de 3 segundos e deixará de emitir despois de 3 segundos. 3 segundos: este é exactamente o tempo que ten R3 para non perder o seu multicast. Polo tanto, R3 envía unha mensaxe de Pim Join para este grupo canto antes e R1 xa non pensa en deixar de emitir. Acerca de Únete ás mensaxes a continuación.
Mensaxe de afirmación.
Imaxinemos esta situación: dous enrutadores transmiten a unha rede á vez. Reciben o mesmo fluxo da fonte e ambos o transmiten á mesma rede detrás da interface e0. Polo tanto, necesitan determinar quen será o único emisor desta rede. As mensaxes de afirmación úsanse para iso. Cando R2 e R3 detectan a duplicación de tráfico de multidifusión, é dicir, R2 e R3 reciben unha multidifusión que eles mesmos emiten, os enrutadores entenden que algo está mal aquí. Neste caso, os enrutadores envían mensaxes Assert, que inclúen a Distancia administrativa e a métrica de ruta coa que se chega á fonte de multidifusión - 10.1.1.10. O gañador determínase do seguinte xeito:
- O de menor AD.
- Se AD son iguais, entón quen ten a métrica máis baixa.
- Se aquí hai igualdade, entón o que ten a IP máis alta na rede á que transmiten este multicast.
O gañador desta votación pasa a ser o Router Designado. Pim Hello tamén se usa para seleccionar DR. Ao comezo do artigo mostrouse a mensaxe PIM Hello, alí podes ver o campo DR. Gaña o que teña o enderezo IP máis alto nesta ligazón.
Sinal útil:
MROUTE Táboa.
Despois dunha ollada inicial ao funcionamento do protocolo PIM, necesitamos entender como traballar cunha táboa de enrutamento multicast. A táboa mroute almacena información sobre cales fluxos se solicitaron aos clientes e que fluxos flúen desde servidores de multidifusión.
Por exemplo, cando se recibe un informe de pertenza a IGMP ou unha unión PIM nalgunha interface, engádese un rexistro de tipo ( *, G ) á táboa de enrutamento:
Esta entrada significa que se recibiu unha solicitude de tráfico co enderezo 238.38.38.38. A bandeira DC significa que a multidifusión funcionará en modo Denso e C significa que o destinatario está conectado directamente ao enrutador, é dicir, o enrutador recibiu o Informe de adhesión IGMP e a unión PIM.
Se hai un rexistro de tipo (S,G) significa que temos un fluxo multicast:
No campo S - 192.168.1.11, rexistramos o enderezo IP da fonte de multidifusión, é este o que comprobará a regra RPF. Se hai problemas, o primeiro que cómpre facer é comprobar a táboa de unidifusión para a ruta ata a fonte. No campo Interface entrante, indícase a interface á que se recibe a multidifusión. Nunha táboa de enrutamento unicast, a ruta á orixe debe referirse á interface especificada aquí. A interface de saída especifica onde se redirixirá a multidifusión. Se está baleiro, o enrutador non recibiu ningunha solicitude para este tráfico. Pódese atopar máis información sobre todas as bandeiras .
Modo escaso PIM.
A estratexia do modo disperso é a oposta do modo denso. Cando o modo Sparse recibe tráfico de multidifusión, só enviará tráfico a través daquelas interfaces onde houbo solicitudes para este fluxo, por exemplo, Pim Join ou IGMP Report mensaxes que solicitan este tráfico.
Elementos similares para SM e DM:
- As relacións veciñais constrúense do mesmo xeito que en PIM DM.
- A norma do RPF funciona.
- A selección DR é semellante.
- O mecanismo das anulacións de poda e as mensaxes de afirmación son similares.
Para controlar quen, onde e que tipo de tráfico multicast é necesario na rede, é necesario un centro de información común. O noso centro será Rendezvous Point (RP). Calquera persoa que queira algún tipo de tráfico de multidifusión ou alguén comezou a recibir tráfico de multidifusión da fonte, entón envíano a RP.
Cando o RP reciba tráfico multicast, enviarao a aqueles enrutadores que previamente solicitaron este tráfico.
Imaxinemos unha topoloxía onde RP é R3. Tan pronto como R1 recibe tráfico de S1, encapsula este paquete de multidifusión nunha mensaxe de rexistro PIM unicast e envíao a RP. Como sabe quen é o RP? Neste caso, está configurado de forma estática, e da configuración dinámica de RP falaremos máis adiante.
enderezo ip pim rp 3.3.3.3
RP buscará: houbo información de alguén que lle gustaría recibir este tráfico? Supoñamos que non o foi. Entón RP enviará a R1 unha mensaxe PIM Register-Stop, o que significa que ninguén necesita esta multidifusión, o rexistro é denegado. R1 non enviará multicast. Pero o host fonte multicast enviarao, de xeito que R1, despois de recibir Register-Stop, iniciará un temporizador de supresión de rexistro igual a 60 segundos. 5 segundos antes de que expire este temporizador, R1 enviará unha mensaxe de rexistro baleira cun bit de rexistro nulo (é dicir, sen un paquete de multidifusión encapsulado) cara a RP. RP, pola súa banda, actuará así:
- Se non houbese destinatarios, responderá cunha mensaxe de parada de rexistro.
- Se aparecen destinatarios, non lle responderá de ningún xeito. R1, ao non recibir unha negativa a rexistrarse en 5 segundos, estará satisfeito e enviará unha mensaxe de rexistro cunha multidifusión encapsulada a RP.
Parecemos que descubrimos como a multidifusión chega a RP, agora imos tentar responder á pregunta de como RP entrega o tráfico aos destinatarios. Aquí é necesario introducir un novo concepto: árbore de ruta raíz (RPT). RPT é unha árbore enraizada en RP, que crece cara aos destinatarios, ramándose en cada enrutador PIM-SM. RP créao recibindo mensaxes de PIM Join e engade unha nova rama á árbore. E así, todos os enrutadores posteriores faino. A regra xeral é así:
- Cando un enrutador PIM-SM recibe unha mensaxe PIM Join en calquera interface que non sexa a interface detrás da cal está oculto o RP, engade unha nova rama á árbore.
- Tamén se engade unha rama cando o enrutador PIM-SM recibe un informe de pertenza a IGMP dun host conectado directamente.
Imaxinemos que temos un cliente multicast no router R5 para o grupo 228.8.8.8. Tan pronto como R5 recibe o Informe de pertenza a IGMP do host, R5 envía un PIM Join en dirección ao RP e engade unha interface á árbore que mira o host. A continuación, R4 recibe PIM Join de R5, engade a interface Gi0/1 á árbore e envía PIM Join en dirección a RP. Finalmente, RP ( R3 ) recibe PIM Join e engade Gi0/0 á árbore. Así, o destinatario de multidifusión está rexistrado. Estamos construíndo unha árbore coa raíz R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Despois disto, enviarase un PIM Join a R1 e R1 comezará a enviar tráfico multicast. É importante ter en conta que se o host solicitou tráfico antes de que comezase a emisión de multidifusión, entón RP non enviará PIM Join e non enviará nada a R1.
Se, de súpeto, mentres se envía unha multidifusión, o host deixa de querer recibilo, tan pronto como RP reciba un PIM Prune na interface Gi0/0, enviará inmediatamente un PIM Register-Stop directamente a R1 e despois un PIM Prune. mensaxe a través da interface Gi0/1. PIM Register-stop envíase vía unicast ao enderezo do que procede o PIM Register.
Como dixemos anteriormente, tan pronto como un enrutador envía un PIM Join a outro, por exemplo R5 a R4, engádese un rexistro a R4:
E iníciase un temporizador que R5 debe reiniciar constantemente este temporizador PIM Join mensaxes constantemente, se non, R4 será excluído da lista de saída. R5 enviará cada 60 mensaxes PIM Join.
Cambio de árbore de camiño máis curto.
Engadiremos unha interface entre R1 e R5 e veremos como flúe o tráfico con esta topoloxía.
Supoñamos que o tráfico foi enviado e recibido segundo o esquema antigo R1-R2-R3-R4-R5, e aquí conectamos e configuramos a interface entre R1 e R5.
Primeiro de todo, temos que reconstruír a táboa de enrutamento unicast en R5 e agora accede á rede 192.168.1.0/24 a través da interface R5 Gi0/2. Agora R5, recibindo multicast na interface Gi0/1, entende que a regra RPF non se cumpre e sería máis lóxico recibir multicast en Gi0/2. Debe desconectarse de RPT e construír unha árbore máis curta chamada árbore de camiño máis curto (SPT). Para iso, envía PIM Join a R0 a través de Gi2/1 e R1 comeza a enviar unha multidifusión tamén a través de Gi0/2. Agora R5 necesita darse de baixa de RPT para non recibir dúas copias. Para iso, envía a Prune unha mensaxe indicando o enderezo IP de orixe e inserindo un bit especial - RPT-bit. Isto significa que non precisas enviarme tráfico, aquí teño unha árbore mellor. RP tamén envía mensaxes PIM Prune a R1, pero non envía unha mensaxe de parada de rexistro. Outra característica: R5 agora enviará continuamente PIM Prune a RP, xa que R1 segue enviando PIM Register a RP cada minuto. Ata que non haxa novas persoas que queiran este tráfico, RP rexeitarao. R5 notifica a RP que segue recibindo multicast a través de SPT.
Busca dinámica de RP.
Auto-RP.
Esta tecnoloxía é propietaria de Cisco e non é particularmente popular, pero segue viva. A operación Auto-RP consta de dúas etapas principais:
1) RP envía mensaxes RP-Announce ao enderezo reservado - 224.0.1.39, declarándose RP para todos ou para grupos específicos. Esta mensaxe envíase cada minuto.
2) Requírese un axente de mapeo de RP, que enviará mensaxes RP-Discovery indicando para que grupos que RP debería escoitarse. A partir desta mensaxe, os enrutadores PIM habituais determinarán o RP por si mesmos. O axente de cartografía pode ser o propio enrutador RP ou un enrutador PIM independente. RP-Discovery envíase ao enderezo 224.0.1.40 cun temporizador dun minuto.
Vexamos o proceso con máis detalle:
Imos configurar R3 como RP:
ip pim send-rp-announce loopback 0 ámbito 10
R2 como axente de cartografía:
ip pim send-rp-discovery loopback 0 alcance 10
E en todos os demais esperaremos RP a través de Auto-RP:
ip pim autorp listener
Unha vez que configuremos R3, comezará a enviar RP-Announce:
E R2, despois de configurar o axente de mapeo, comezará a esperar a mensaxe RP-Announce. Só cando atope polo menos un RP comezará a enviar RP-Discovery:
Deste xeito, en canto os routers habituais (PIM RP Listener) reciban esta mensaxe, saberán onde buscar o RP.
Un dos principais problemas con Auto-RP é que para recibir mensaxes RP-Announce e RP-Discovery, cómpre enviar PIM Join aos enderezos 224.0.1.39-40 e, para enviar, cómpre saber onde RP está situado. Problema clásico de galiña e ovo. Para resolver este problema, inventouse o PIM Sparse-Dense-Mode. Se o enrutador non coñece RP, entón funciona en modo denso; se o coñece, entón en modo disperso. Cando o modo disperso PIM e o comando ip pim autorp listener están configurados nas interfaces dos enrutadores normais, o enrutador funcionará en modo denso só para a multidifusión directamente desde o protocolo Auto-RP (224.0.1.39-40).
Enrutador BootStrap (BSR).
Esta función funciona de forma similar a Auto-RP. Cada RP envía unha mensaxe ao axente de mapeo, que recolle a información de mapeo e despois di a todos os demais enrutadores. Imos describir o proceso de forma similar a Auto-RP:
1) Unha vez que configuramos R3 como candidato para ser RP, co comando:
ip pim rp-candidate loopback 0
Entón R3 non fará nada; para comezar a enviar mensaxes especiais, primeiro ten que atopar un axente de cartografía. Así, pasamos ao segundo paso.
2) Configure R2 como axente de cartografía:
ip pim bsr-candidate loopback 0
R2 comeza a enviar mensaxes PIM Bootstrap, onde se indica como axente de mapeo:
Esta mensaxe envíase ao enderezo 224.0.013, que o protocolo PIM tamén utiliza para as súas outras mensaxes. Envíaos en todas as direccións e, polo tanto, non hai ningún problema de galiña e ovo como o que houbo en Auto-RP.
3) Tan pronto como o RP reciba unha mensaxe do enrutador BSR, enviará inmediatamente unha mensaxe unicast ao enderezo do enrutador BSR:
Despois diso, o BSR, recibindo información sobre os RP, enviaraos por multidifusión ao enderezo 224.0.0.13, que é escoitado por todos os enrutadores PIM. Polo tanto, un análogo do comando ip pim autorp listener para routers normais que non están en BSR.
Anycast RP con Multicast Source Discovery Protocol (MSDP).
Auto-RP e BSR permítennos distribuír a carga en RP do seguinte xeito: Cada grupo de multidifusión só ten un RP activo. Non será posible distribuír a carga dun grupo de multidifusión en varios RP. MSDP fai isto emitindo aos routers RP o mesmo enderezo IP cunha máscara de 255.255.255.255. MSDP aprende información usando un dos métodos: estático, Auto-RP ou BSR.
Na imaxe temos unha configuración Auto-RP con MSDP. Ambos os RP están configurados co enderezo IP 172.16.1.1/32 na interface Loopback 1 e úsase para todos os grupos. Con RP-Announce, ambos enrutadores anúncianse facendo referencia a este enderezo. O axente de cartografía Auto-RP, unha vez recibida a información, envía RP-Discovery sobre o RP co enderezo 172.16.1.1/32. Informamos aos enrutadores sobre a rede 172.16.1.1/32 usando IGP e, en consecuencia. Así, os enrutadores PIM solicitan ou rexistran fluxos do RP que se especifica como o seguinte salto na ruta á rede 172.16.1.1/32. O protocolo MSDP en si está deseñado para que os propios RP intercambien mensaxes sobre información de multidifusión.
Considere esta topoloxía:
Switch6 transmite o tráfico ao enderezo 238.38.38.38 e ata agora só RP-R1 sabe diso. Switch7 e Switch8 solicitaron este grupo. Os enrutadores R5 e R4 enviarán PIM Join a R1 e R3, respectivamente. Por que? A ruta a 13.13.13.13 para R5 referirase a R1 usando a métrica IGP, igual que para R4.
RP-R1 coñece o fluxo e comezará a emitilo cara a R5, pero R4 non sabe nada diso, xa que R1 non o enviará simplemente. Polo tanto, MSDP é necesario. Configuramos en R1 e R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 en R1
ip msdp peer 1.1.1.1 connect-source Loopback3 en R3
Levantarán unha sesión entre si e ao recibir calquera fluxo comunicarano ao seu veciño de RP.
Tan pronto como RP-R1 reciba un fluxo de Switch6, enviará inmediatamente unha mensaxe MSDP Source-Active de unidifusión, que conterá información como (S, G) - información sobre a fonte e o destino da multidifusión. Agora que RP-R3 sabe que unha fonte como Switch6, ao recibir unha solicitude de R4 para este fluxo, enviará PIM Join cara Switch6, guiado pola táboa de enrutamento. En consecuencia, o R1 que recibiu tal unión PIM comezará a enviar tráfico cara a RP-R3.
MSDP execútase sobre TCP, os RP envíanse mensaxes para comprobar a súa vida. O temporizador é de 60 segundos.
A función de dividir os pares de MSDP en diferentes dominios segue sen estar clara, xa que as mensaxes de Keepalive e SA non indican a pertenza a ningún dominio. Ademais, nesta topoloxía, probamos unha configuración que indica dominios diferentes; non houbo diferenzas no rendemento.
Se alguén pode aclarar, encantaríame lelo nos comentarios.
Fonte: www.habr.com