Modeo Multicast Pim Dense Modo

Na lección anterior discutimos os conceptos básicos do enrutamento multicast e eu Explicou algunhas das diferenzas entre os protocolos de enrutamento multicast denso e escasos. O único protocolo de enrutamento multicast que está totalmente soportado nos dispositivos Cisco iOS é PIM (protocolo multidifusión independente).

A parte independente é un pouco confuso … PIM depende do 100% sobre a información da táboa de enrutamento dunic Non importa o protocolo de enrutamento dunicast que usa para enchelo. Outros protocolos de enrutamento multicast como DVMRP e MOSPF non utilizan a táboa de enrutamento Unicast pero constrúen as súas propias táboas.

PIM soporta tres modos diferentes:

• Modo denso
• Modo escarpado
• PIM Modo espeso

Aquí está a diferenza clave entre o modo escaso e denso:

• Modo denso: Reenviamos o tráfico multidifusión en todas as interfaces ata que un enrutador de abaixo pídenos que deixemos de afrontar.
• Modo escaso: non reenvía o tráfico multicast en ningunha interface ata que un enrutador descendente pidémosnos .

Nesta lección, teremos unha ollada de preto de Modo Dense Pim.

Modo Dense Pim é un método de empuxe onde usamos árbores baseadas en fontes. Que significa isto? Vexamos un exemplo:

Por riba vemos un servidor de vídeo que envía un paquete de multidifusión cara a R1. Axiña que R1 recibe este paquete de multidifusión, creará unha entrada na súa táboa de enrutamento multidifusión onde almacena o enderezo de orixe e o enderezo do grupo de multicast. A continuación, inundará o tráfico en todas as súas interfaces.

Outros enrutadores que reciben este paquete de multidifusión farán o mesmo, o paquete de multicast está inundado en todas as súas interfaces. Isto causa algúns problemas, un problema é que teremos loops de enrutamento multicast. Por exemplo, podes ver que o paquete que R1 recibe é reenviado a R2 > R4 > R5 e de volta a R1 (e ao contrario arredor). Como lidamos con isto? Bótalle un ollo a continuación:

Cada enrutador que non está interesado no tráfico multicast enviará unha poda ao seu enrutador Upstream, pedíndolle que deixe de reenvío. O enrutador Upstream é o enrutador onde recibimos o tráfico de multicast, un enrutador de Downstream é un enrutador onde enviamos o tráfico multicast a. As frechas vermellas anteriores son as mensaxes de poda que enviarán os enrutadores. Hai un par de razóns polas que un enrutador pode enviar unha mensaxe de poda:

• cando non temos ningún anfitrión directamente conectado que están interesados en recibir o tráfico multicast.
• Cando ningún enrutadores de entrada está interesado en recibir o tráfico multicast.
• cando recibimos o tráfico nunha interface non RPF.

RPF (reenvío de ruta inversa) é un Comprobación adicional que axuda a previr os loops de enrutamento multicast:

Cando un enrutador recibe un paquete de multidifusión, verificará a dirección IP de orixe deste paquete na táboa de enrutamento Unicast. Comprobará a interface do próximo salto e saída que usamos para chegar á fonte.

• Cando o paquete de multicast foi recibido na interface que usamos para chegar á fonte, a verificación RPF ten éxito.
• Cando se recibiu o paquete de multidifusión noutra interface, falla o control de RPF eo paquete descartado.

O resultado final verá así:

Agora temos unha boa topoloxía limpa onde o tráfico multicast está inundado de R1 a R2 > r6 > h1. Este comportamento de inundación e poda producirase cada tres minutos.

Chamamos a esta topoloxía a árbore de distribución baseada en orixe ou a SPT (ruta máis curta). Ás veces, tamén se chama a árbore de orixe:

• A árbore define a ruta da fonte ao receptor (s).
• A fonte é a raíz da nosa árbore.
• Os enrutadores entre os que están a reenviar o tráfico son os nodos.
• Os subredes con receptores son as ramas e as follas da árbore.

Dependendo Nos grupos de orixe e / ou multicast que usamos, pode ter máis dunha árbore de orixe na súa rede. Unha vez que miremos a configuración, verás que usamos a notación para referirse a unha árbore fonte particular:

• s: a dirección de orixe
• g: o multicast Enderezo do grupo.

Agora tes unha idea do que é o modo de denso de pim, imos ver o que parece nalgúns enrutadores reais que imos?

Configuración

Usaremos a seguinte topoloxía para esta demostración:

Above temos un servidor de vídeo No lado esquerdo, que será a fonte do noso tráfico multicast. H2 e H3 son dous dispositivos de hospedaxe que queren recibir o tráfico multicast.R1, R2 e R3 configuraranse para usar o modo Pim Dense.

Enrutamento de Unicast

Primeiro Configuraremos un protocolo de enrutamento en todos os enrutadores, escollo OSPF. Todas as interfaces serán anunciadas:

R1(config)#router ospf 1R1(config-router)#network 192.168.1.0 0.0.0.255 area 0R1(config-router)#network 192.168.12.0 0.0.0.255 area 0R1(config-router)#network 192.168.13.0 0.0.0.255 area 0

R2(config)#router ospf 1R2(config-router)#network 192.168.2.0 0.0.0.255 area 0R2(config-router)#network 192.168.12.0 0.0.0.255 area 0R2(config-router)#network 192.168.23.0 0.0.0.255 area 0

R3(config)#router ospf 1R3(config-router)#network 192.168.3.0 0.0.0.255 area 0R3(config-router)#network 192.168.13.0 0.0.0.255 area 0R3(config-router)#network 192.168.23.0 0.0.0.255 area 0

agora Podemos centrarnos na configuración de multidifusión.

Modo denso

O enrutamento multicast está desactivado por defecto en enrutadores de Cisco iOS polo que temos que habilitalo:

Agora podemos configurar PIM. Empecemos por R1:

R1(config)#interface GigabitEthernet 0/1R1(config-if)#ip pim dense-mode

En canto habilite o modo pim denso na interface, o noso enrutador comezará a enviar paquetes de Hello PIM. Aquí está o que parecen en Wireshark:

arriba pode ver o tipo de paquete (Hola ) E tamén mostra o tempo de espera. Por calquera motivo, Wireshark (versión 2.0.1) me mostra un valor de 1 pero o valor predeterminado é de 105 segundos. Se queres botar unha ollada a este paquete a ti mesmo, aquí está a captura de CloudShark:

Pim Dense Modo Hello Packet

Mostra o tempo correcto de 105 segundos.

Imos permitir a pim denso en R2 tamén:

R2(config)#interface GigabitEthernet 0/1R2(config-if)#ip pim dense-mode 

En canto facemos isto, R1 e R2 converteranse nos veciños xa que reciben un pim paquetes. Se seguen recibindo antes de que o temporizador de espera caduce, entón seguirán véndense como veciños de PIM.:

R1#%PIM-5-NBRCHG: neighbor 192.168.12.2 UP on interface GigabitEthernet0/1

imos activar todas as outras interfaces .. Tamén cómpre habilitar a interfaces de PIM que se conecten aos dispositivos de servidor:

R1(config)#interface GigabitEthernet 0/2R1(config-if)#ip pim dense-mode R1(config)#interface GigabitEthernet 0/3R1(config-if)#ip pim dense-mode

R2(config)#interface GigabitEthernet 0/2R2(config-if)#ip pim dense-modeR2(config)#interface GigabitEthernet 0/3R2(config-if)#ip pim dense-mode

R3(config)#interface GigabitEthernet 0/1R3(config-if)#ip pim dense-mode R3(config)#interface GigabitEthernet 0/2R3(config-if)#ip pim dense-modeR3(config)#interface GigabitEthernet 0/3R3(config-if)#ip pim dense-mode

Pim Dense Neighbors

Imos asegurarnos de que todos os enrutadores convertéronse en veciños:

R1#show ip pim neighbor PIM Neighbor TableMode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable, G - GenID Capable, L - DR Load-balancing CapableNeighbor Interface Uptime/Expires Ver DRAddress Prio/Mode192.168.12.2 GigabitEthernet0/1 00:05:59/00:01:37 v2 1 / DR S P G192.168.13.3 GigabitEthernet0/2 00:00:48/00:01:26 v2 1 / DR S P G

R2#show ip pim neighbor PIM Neighbor TableMode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable, G - GenID Capable, L - DR Load-balancing CapableNeighbor Interface Uptime/Expires Ver DRAddress Prio/Mode192.168.12.1 GigabitEthernet0/1 00:06:18/00:01:22 v2 1 / S P G192.168.23.3 GigabitEthernet0/2 00:01:00/00:01:43 v2 1 / DR S P G

R3#show ip pim neighbor PIM Neighbor TableMode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable, G - GenID Capable, L - DR Load-balancing CapableNeighbor Interface Uptime/Expires Ver DRAddress Prio/Mode192.168.13.1 GigabitEthernet0/1 00:01:14/00:01:29 v2 1 / S P G192.168.23.2 GigabitEthernet0/2 00:01:09/00:01:33 v2 1 / S P G

arriba podemos ver que todos os enrutadores convertéronse en veciños de PIM. A versión por defecto en Cisco iOS é a versión 2. Os tempos de caducidade é o temporizador de Holddown que está contando. Cada vez que o enrutador recibe un paquete de Hello PIM, restablecerase ás 00:01:45 (105 segundos).

Enrutamento multidifunción

Vexamos o enrutamento multicast Táboas:

R1#show ip mroute IP Multicast Routing TableFlags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group, G - Received BGP C-Mroute, g - Sent BGP C-Mroute, N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, Q - Received BGP S-A Route, q - Sent BGP S-A Route, V - RD & Vector, v - Vector, p - PIM Joins on route, x - VxLAN groupOutgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.0.1.40), 00:12:12/00:02:48, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/2, Forward/Dense, 00:03:06/stopped GigabitEthernet0/1, Forward/Dense, 00:12:12/stopped

R2#show ip mroute IP Multicast Routing TableFlags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group, G - Received BGP C-Mroute, g - Sent BGP C-Mroute, N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, Q - Received BGP S-A Route, q - Sent BGP S-A Route, V - RD & Vector, v - Vector, p - PIM Joins on route, x - VxLAN groupOutgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.0.1.40), 00:08:33/00:02:35, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/2, Forward/Dense, 00:03:15/stopped GigabitEthernet0/1, Forward/Dense, 00:08:33/stopped

R3#show ip mroute IP Multicast Routing TableFlags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group, G - Received BGP C-Mroute, g - Sent BGP C-Mroute, N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, Q - Received BGP S-A Route, q - Sent BGP S-A Route, V - RD & Vector, v - Vector, p - PIM Joins on route, x - VxLAN groupOutgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.0.1.40), 00:03:24/00:02:10, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/2, Forward/Dense, 00:03:20/stopped GigabitEthernet0/1, Forward/Dense, 00:03:24/stopped

Neste momento non temos ‘T ten algún tráfico de multidifusión, pero vemos un grupo multicast nas táboas, 224.0.1.40. Isto pode ser confuso se é novo en multidifusión, deixe-me explicar:

Modo escrito de PIM (que imos discutir noutras leccións) usa un RP (punto de rendez) e os enrutadores de Cisco soportan un protocolo chamado “Auto RP Discovery “para atopar automaticamente o RP da rede. Auto RP usa este enderezo de grupo multicast, 224.0.1.40.

Modo de pim denso non usa RPS para que non haxa ningunha razón para os nosos enrutadores Escoita o enderezo do grupo 224.0.1.40. Por calquera motivo, apenas habilite a PIM, a continuación, A AUTORP tamén está habilitado e o enrutador escoitará este enderezo de grupo. Pode ignorar esta entrada completamente cando está a traballar con modo Dense.

Se tes unha mirada estreita, podes ver que ningún dos enrutadores está a recibir ou reenviar o tráfico para este grupo:

• A interface entrante é nula.
• A lista de interface de saída mostra parada.

Imos xerar algún tráfico multicast a nós mesmos. Primeiro vou ter que configurar un dos anfitrións para unirse a un grupo multicast. Imos configure H2 para unirse 239.1.1.1:

H2(config)#interface GigabitEthernet 0/1H2(config-if)#ip igmp join-group 239.1.1.1

cheque imos como iso inflúe multicast enrutamento táboa de R2 o:

R2#show ip mroute 239.1.1.1(*, 239.1.1.1), 00:00:19/00:02:51, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/3, Forward/Dense, 00:00:19/stopped GigabitEthernet0/2, Forward/Dense, 00:00:19/stopped GigabitEthernet0/1, Forward/Dense, 00:00:19/stopped

por riba podemos ver que R2 creou unha entrada *, 239.1.1.1.1 para o grupo multicast 239.1.1.1. Neste momento, con todo, non estamos a recibir ningún tráfico para este grupo polo que non sabemos cal é a fonte e non podemos reenviar nada.

Imos cambiar isto. O método máis sinxelo para xerar tráfico multicast é enviar un ping desde o enderezo do grupo multicast:

S1#ping 239.1.1.1 repeat 2147483647Type escape sequence to abort.Sending 2147483647, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:Reply to request 0 from 192.168.2.2, 132 msReply to request 1 from 192.168.2.2, 7 msReply to request 2 from 192.168.2.2, 6 ms

arriba pode ver que H2 está respondendo. Comprobamos as táboas de enrutamento multicast:

R1#show ip mroute 239.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group, G - Received BGP C-Mroute, g - Sent BGP C-Mroute, N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, Q - Received BGP S-A Route, q - Sent BGP S-A Route, V - RD & Vector, v - Vector, p - PIM Joins on route, x - VxLAN groupOutgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode(*, 239.1.1.1), 00:01:16/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/2, Forward/Dense, 00:01:16/stopped GigabitEthernet0/1, Forward/Dense, 00:01:16/stopped(192.168.1.1, 239.1.1.1), 00:01:16/00:01:43, flags: T Incoming interface: GigabitEthernet0/3, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/1, Forward/Dense, 00:01:16/stopped GigabitEthernet0/2, Prune/Dense, 00:01:15/00:01:43

imos discutir o que vemos arriba:

• R1 está a recibir tráfico multicast por 239,1 .1.1 Desde 192.168.1.1 Na súa interface GI0 / 3 engadiu esta entrada na súa táboa de enrutamento multicast. Esta é a entrada que explicou antes.
• R1 estivo reenviando este tráfico por un minuto e 16 segundos na interface GI0 / 1.
• cando non reenvía ningún paquete Por un minuto e 43 segundos, esta entrada será eliminada da táboa de enrutamento multicast. Mentres seguimos recibindo paquetes, este temporizador será reiniciado a tres minutos.
• As bandeiras T significa que estamos a usar a árbore de orixe do camiño máis curto.
• o veciño RPF para R1 é 0.0.0.0, este valor está baleiro xa que é unha interface directamente conectada.
• R1 está reenviante o tráfico na súa interface GI0 / 1 conectada a R2. Foi facendo isto por un minuto e 16 segundos e non hai caducidade. Seguirá facendo isto ata que se arrepinte.
• R1 deixou de reenviar o tráfico na súa interface GI0 / 2 xa que está podada.

desde que R3 non está interesado en Recibir este tráfico multicast e enviou unha mensaxe de poda a R1, pedíndolle que deixase de reenviar este tráfico. Aquí está o que parece esta mensaxe de poda:

arriba podes ver que este paquete foi enviado por R3 (192.168.13.3) e destinado a 224.0.0.13 (PIM versión 2).

PIM usa un único paquete de mensaxes de unirse e poda, neste paquete podemos ver que R3 solicita unha poda por 239.1.1.1. Desde 192.168.1.1. Este paquete está destinado a 192.168.13.1.

Unha interface está podada por tres minutos e cada vez que enviamos unha mensaxe de poda, este temporizador será reiniciado. Se Deixamos de enviar mensaxes de poda, a interface volverá ao reenvío despois de tres minutos.

Quere ver este paquete por si mesmo? Bótalle un ollo aquí:

PIM DENE Mensaxe de poda

Imos comprobar R2:

R2#show ip mroute 239.1.1.1(*, 239.1.1.1), 00:03:47/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/3, Forward/Dense, 00:03:47/stopped GigabitEthernet0/2, Forward/Dense, 00:03:47/stopped GigabitEthernet0/1, Forward/Dense, 00:03:47/stopped (192.168.1.1, 239.1.1.1), 00:01:22/00:01:37, flags: T Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.12.1 Outgoing interface list: GigabitEthernet0/2, Prune/Dense, 00:01:22/00:01:37 GigabitEthernet0/3, Forward/Dense, 00:01:22/stopped

imos discutir o que temos arriba:

• R2 configurouse o DC Bandeiras para este grupo. A D significa que estamos a usar o modo denso e os medios C que temos un servidor directamente conectado que quere recibir este tráfico (H2).
• R2 estivo recibindo tráfico desde 192.168.1.1. a 239.1.1.1 na súa interface GI0 / 1. O veciño RPF é 192.1 68.12.1 (R1).
• R2 deixou de reenviar o tráfico na súa interface GI0 / 2 cara a R3.
• R2 está reenviando o tráfico na súa interface GI0 / 3 cara a H2.

Que hai de R3?

R3#show ip mroute 239.1.1.1(*, 239.1.1.1), 00:01:27/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/2, Forward/Dense, 00:01:27/stopped GigabitEthernet0/1, Forward/Dense, 00:01:27/stopped(192.168.1.1, 239.1.1.1), 00:01:27/00:01:32, flags: PT Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.13.1 Outgoing interface list: GigabitEthernet0/2, Prune/Dense, 00:01:27/00:01:32, A

Vexamos:

• R3 está a recibir tráfico para 239.1.1.1 a partir de 192.168.1.1 na súa interface GI0 / 1 que se conecta a R1. O veciño RPF é de 192.168.13.1.
• A bandeira P significa que este tráfico foi podado.
• R3 poda a súa interface GI0 / 2. A bandeira significa o gañador de afirmación.

Entón, a gran pregunta … ¿Que é un vencedor de afirmación?

R2 e R3 están conectados ao 192.168.230/24 Subrede e ambos están a recibir tráfico de R1.

Imaxinamos que temos un servidor na subred de 192.168.23.24 que quere recibir tráfico multicast. Que enrutador remitirá este tráfico? R2 ou R3? Se os dous enrutadores avanzan o tráfico multicast, o servidor recibiría paquetes de multidifusión duplicados.