Modo Denso Multicast Pim

Na lição anterior discutimos o básico do roteamento multicast e eu Explicou algumas das diferenças entre os protocolos de roteamento multicast do modo denso e esparso. O único protocolo de roteamento multicast que é totalmente suportado em dispositivos Cisco IOS é PIM (Protocolo Independent Multicast).

A parte independente é um pouco confuso … Pim depende de 100% na informação na tabela de roteamento unicast, mas Não importa qual protocolo de roteamento unicast que você usa para preenchê-lo. Outros protocolos de roteamento multicast, como DVMRP e MOPF, não usam a tabela de roteamento Unicast, mas construam suas próprias tabelas.

PIM suporta três modos diferentes:

Modo Denso
• PIM
• PIM Sparse Mode
• PIM Sparse-denso modo

Aqui está a diferença chave entre o modo esparso e denso:

• Modo Denso: Nós encaminhamos o tráfego multicast em todas as interfaces até que um roteador downstream nos peça para parar de enfraquecimento.
• Modo esparso: não encaminhamos o tráfego multicast em qualquer interface até que um roteador downstream nos solicite .

Nesta lição, daremos uma olhada próxima no modo Denso Pim.

Modo Denso Pim é um método de push onde usamos árvores baseadas em origem. O que isto significa? Vamos ver um exemplo:

Acima, vemos um servidor de vídeo enviando um pacote multicast para R1. Assim que R1 receber este pacote multicast, criará uma entrada em sua tabela de roteamento multicast onde armazena o endereço de origem e o endereço do grupo multicast. Ele inundará o tráfego em todas as suas interfaces.

Outros roteadores que recebem este pacote multicast farão a mesma coisa, o pacote multicast é inundado em todas as suas interfaces. Isso causa alguns problemas, um problema é que teremos loops de roteamento multicast. Por exemplo, você pode ver que o pacote que R1 recebe é encaminhado para R2 > r4 > R5 e de volta para R1 (e a outra maneira por aí). Como nós lidamos com isto? Dê uma olhada abaixo:

Cada roteador que não está interessado no tráfego multicast irá enviar uma fraca Para o seu roteador a montante, solicitando que pare a encaminhá-lo. O roteador upstream é o roteador onde recebemos tráfego multicast de, um roteador a jusante é um roteador onde encaminhamos o tráfego multicast para. As setas vermelhas acima são as mensagens podar que os roteadores enviarão. Há algumas razões pelas quais um roteador pode enviar uma mensagem de ameixa:

• quando não temos nenhum hosts diretamente conectado que estão interessados em receber o tráfego multicast.
• Quando nenhum roteadores downstream estiver interessado em receber o tráfego multicast.
• Quando recebermos tráfego em uma interface não-RPF.

rpf (encaminhamento de caminho reverso) é um Verificação adicional que ajuda a evitar loops de roteamento multicast:

Quando um roteador recebe um pacote multicast, ele verificará o endereço IP de origem deste pacote na tabela de roteamento unicast. Ele irá verificar a próxima interface de salto e saída que usamos para alcançar a fonte.

• Quando o pacote multicast foi recebido na interface que usamos para chegar à fonte, a verificação RPF é bem-sucedida.
• Quando o pacote multicast foi recebido em outra interface, ele falha na verificação RPF e o pacote é descartado.

O resultado final ficará assim:

Agora temos uma boa topologia limpa, onde o tráfego multicast é inundado de R1 a R2 > R6 > H1. Este comportamento de inundação e ameuna ocorrerá a cada três minutos.

Chamo esta topologia a árvore de distribuição baseada em origem ou SPT (árvore de caminho mais curto). Às vezes, também é chamado de árvore de origem:

• A árvore define o caminho da origem para o (s) receptor (s).
• A fonte é a raiz da nossa árvore.
• os roteadores entre os que são o tráfego de encaminhamento são os nós.
• As sub-redes com receptores são os ramos e folhas da árvore.

Dependendo Nos grupos de origem e / ou multicast que usamos, você pode ter mais de uma árvore de origem na sua rede. Uma vez que olhamos para a configuração, você veremos que usamos a notação para se referir a uma árvore de origem específica:

• s: o endereço de origem
• g: a multicast Endereço do grupo.

Agora você tem uma ideia do que o modo Denso Pim é sobre, vamos ver o que parece em alguns roteadores reais Vamos?

Configuração

vamos usar a seguinte topologia para esta demonstração:

acima, temos um servidor de vídeo no lado esquerdo, que será a fonte do nosso tráfego multicast. H2 e H3 são dois dispositivos host que desejam receber o tráfego multicast.R1, R2 e R3 serão configurados para usar o modo Denso PIM.

Roteamento Unicast

primeiro, primeiro vamos configurar um protocolo de roteamento em todos os roteadores, vou escolher OSPF. Todas as interfaces serão anunciadas:

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 nos concentrar na configuração multicast.

Modo Denso PIM

Multicast Roteamento é desabilitado por padrão nos roteadores da Cisco IOS, então temos que ativá-lo:

R1, R2 & R3(config)#ip multicast-routing

Agora podemos configurar o PIM. Vamos começar com R1:

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

Assim que eu habilitar o modo Denso Pim na interface, nosso roteador começará a enviar os pacotes PIM Hello. Aqui está o que estes se parecem em Wireshark:

acima você pode ver o tipo do pacote (Olá ) e também mostra o tempo de espera. Por qualquer motivo, o Wireshark (versão 2.0.1) está me mostrando um valor de 1, mas o padrão é 105 segundos. Se você quiser dar uma olhada neste pacote, aqui está a captura CloudShark:

PIM Denso modo Olá pacote

Mostra o tempo de espera correto de 105 segundos.

Vamos ativar o PIM Denso no R2 também:

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

Assim que fizermos isso, R1 e R2 se tornarão vizinhos, uma vez que recebem uns aos outros Pim Hello pacotes.Se eles continuarem recebendo-os antes que o temporizador de detenção seja expirado, eles continuarão vendo uns aos outros como vizinhos PIM.:

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

permite permitir todas as outras interfaces . Você também precisa ativar as interfaces PIM que se conectam a dispositivos de host:

R1(config)#interface GigabitEthernet 0/2R1(config-if)#ip pim dense-mode R1(config)#interface GigabitEthernet 0/3R1(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 vizinhos densos

certifique-se de que todos os roteadores se tornaram vizinhos:

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

Acima, podemos ver que todos os roteadores se tornaram vizinhos PIM. A versão padrão no Cisco IOS é a versão 2. O Tempos de Expiração é o temporizador de detenção que está contando. Cada vez em que o roteador recebe um pacote PIM Hello, ele se redefinirá para 00:01:45 (105 segundos).

Roteamento multicast

Vamos dar uma olhada no roteamento multicast tabelas:

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 nós não Tenho qualquer tráfego multicast acontecendo, mas vemos um grupo multicast nas tabelas, 224.0.1.40. Isso pode ser confuso se você é novo em multicast, deixe-me explicar:

PIM Sparse Mode (que discutiremos em outras aulas) usa um RP (ponto Rendezvous) e os roteadores Cisco suportam um protocolo chamado “Auto RP Discovery “para encontrar automaticamente o RP na rede. Auto RP usa este endereço de grupo multicast, 224.0.1.40.

PIM Denso modo não usa RPS para que não haja razão para nossos roteadores Ouça o endereço do grupo 224.0.1.40. Por qualquer motivo, assim que você habilitar o PIM, o AutorP também está habilitado e o roteador ouvirá esse endereço de grupo. Você pode ignorar completamente essa entrada quando estiver trabalhando com o modo Denso Pim.

Se você fizer uma olhada de perto, você pode ver que nenhum dos roteadores está recebendo ou encaminhando tráfego para este grupo:

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

Vamos gerar algum tráfego multicast. Primeiro, terei que configurar um dos hosts para participar de um grupo multicast. Vamos configurar o H2 para se juntar 239.1.1.1:

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

Vamos verificar como isso influencia a tabela de roteamento multicast de R2:

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

Acima, podemos ver que R2 criou uma entrada *, 239.1.1.1 para o grupo multicast 239.1.1.1. Neste momento, no entanto, não estamos recebendo qualquer tráfego para este grupo, então não sabemos o que é a fonte e não podemos encaminhar qualquer coisa.

Vamos mudar isso. O método mais simples para gerar tráfego multicast é enviar um ping do endereço 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

acima você pode ver que o H2 está respondendo. Vamos verificar as tabelas de roteamento 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

Vamos discutir o que vemos acima:

• R1 está recebendo tráfego multicast para 239.1 .1.1 de 192.168.1.1 em sua interface GI0 / 3 e adicionou esta entrada em sua tabela de roteamento multicast. Esta é a entrada que eu expliquei antes.
• R1 foi encaminhando este tráfego por um minuto e 16 segundos na interface GI0 / 1.
• Quando não encaminhar quaisquer pacotes Por um minuto e 43 segundos, esta entrada será removida da tabela de roteamento multicast. Enquanto continuarmos recebendo pacotes, este temporizador será redefinido para três minutos.
• As bandeiras T significa que estamos usando a árvore de origem do caminho mais curta.
• o vizinho R1 para R1 é 0.0.0.0, este valor está vazio, pois é uma interface diretamente conectada.
• R1 é o tráfego de encaminhamento na sua interface GI0 / 1 conectado a R2. Tem feito isso por um minuto e 16 segundos e não há expiração. Ele continuará fazendo isso até que seja podado.
• R1 parou de encaminhar o tráfego em sua interface GI0 / 2, já que é podada.

Como o R3 não está interessado em Recebendo este tráfego multicast e enviou uma mensagem de ameixa para R1, pedindo que pare de encaminhar este tráfego. Aqui está o que esta mensagem de podar parece:

acima você pode ver que este pacote foi enviado por R3 (192.168.13.3) e destinado a 224.0.0.13 (PIM versão 2).

PIM usa um único pacote para junção e as mensagens podar, neste pacote, podemos ver que R3 solicita uma podar para 239.1.1.1 de 192.168.1.1. Este pacote é destinado a 192.168.13.1.

Uma interface é podada por três minutos e cada vez que enviamos uma mensagem de ameixa, este temporizador será redefinido. Se Paramos de enviar mensagens de ameixa, então a interface voltará ao encaminhamento após três minutos.

Quer ver este pacote para você mesmo? Dê uma olhada aqui:

PIM Dense Mensagem de ameune

Vamos verificar 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

vamos discutir o que temos acima:

• r2 definiu o DC bandeiras para este grupo. O D significa que estamos usando o modo denso e o c significa que temos um host diretamente conectado que quer receber este tráfego (H2).
• r2 tem recebido tráfego de 192.168.1.1 para 239.1.1.1 na sua interface GI0 / 1. O vizinho RPF é 192.1 68.12.1 (R1).
• R2 parou de encaminhar o tráfego em sua interface GI0 / 2 para R3.
• R2 é o tráfego de encaminhamento em sua interface GI0 / 3 para H2.

e sobre 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

Vamos ver:

• r3 está recebendo tráfego para 239.1.1.1 De 192.168.1.1 na sua interface GI0 / 1 que se conecta a R1. O vizinho RPF é 192.168.13.1.
• O sinalizador P significa que esse tráfego foi podado.
• R3 podiu sua interface GI0 / 2. A bandeira representa o vencedor da afirmação.

Então a grande questão … o que é um vencedor de afirmação?

R2 e R3 estão ambos conectados ao 192.168.23.0/24 A sub-rede e ambos estão recebendo tráfego de R1.

Vamos imaginar que temos um host na sub-rede 192.168.23.0/24 que deseja receber tráfego multicast. Qual roteador encaminhará este tráfego? R2 ou R3? Se ambos os roteadores encaminham o tráfego multicast, o host receberia pacotes multicast duplicados.