Rede de conteúdo : Redundância

O PIM VRRP-ciente com PIM NonDR junta-se ao exemplo de configuração da característica

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como configurar um roteador a fim usar a transmissão múltipla independente de protocolo (VRRP-ciente) Protocolo-ciente da Redundância do roteador virtual (PIM).

Contribuído por Mohammed Muddasir Khan, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

Cisco recomenda que você tem o conhecimento do Multicast e das características VRRP.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Informações de Apoio

o PIM VRRP-ciente é apoiado na liberação da versão 3.10 VRRP (15.3(3)S). O PIM não tem nenhuma potencialidade de redundância inerente e sua operação é completamente independente dos primeiros protocolos da redundância de salto (FHRP) como o VRRP. Em consequência, o tráfego do Protocolo IP multicast não é enviado necessariamente pelo mesmo roteador que é elegido pelo VRRP.

Há uma necessidade de fornecer o Protocolo IP multicast consistente que envia nas redes redundantes os grupos de roteador virtual (VRGs) permitidos. Com Redundância PIM, o serviço da Redundância do roteador virtual (VRRS) é leveraged e a eleição do Designated Router (DR) e o PIM junta-se/ameixa seco que processa decisões é feito baseado nos estados VRRP no roteador. Quando você permite o PIM não-DR junte-se à característica, permite que o não-DR (NonDR) crie estados da rota de transmissão múltipla (mrouter) e puxe o tráfego, mas não envie o tráfego. Quando um failover do VRRP ocorre, o roteador mestre novo (MR) eleito pelo grupo VRRP toma sobre as primeiras responsabilidades do roteador de salto (FHR) ou do roteador do último salto (LHR) DR e começa a enviar o tráfego.

Características novas da relação

Cisco introduziu uns novos recursos que fossem permitidos com o pim IP NON-DR-se juntassem ao comando CLI. Estes novos recursos trabalham independentemente da característica VRRP-ciente PIM, e pode ser útil com outros recursos, tais como a detecção bidirecional da transmissão (BFD), além do que o VRRP. Esta característica CLI, uma vez que permitido, permite que o NonDR processe o Internet Group Management Protocol (IGMP) se junta e função apenas como o DR, com estas exceções:

  • O NonDR mantém as relações na lista de interface enviada (ÓLEO), mas não ajusta a bandeira F (a bandeira dianteira na base de informação do roteamento de transmissão múltipla (MRIB)) de modo que o tráfego não seja enviado. Quando o NonDR se transforma o DR, ajusta a bandeira F e começa a enviar o tráfego.

    Nota: Esta lógica trabalha completamente independentemente dos estados dos grupos VRRP.

  • Se ambos que o pim IP NON-DR-se junta e características do <value> da DR-prioridade do vrrp do <tag> da Redundância do pim IP é permitido em uma relação, o tráfego está puxado em todo o NonDRs também, apesar do estado VRRP. O PIM ajusta ou cancela a bandeira F na relação baseada no estado VRRP, que reserva o tempo da convergência rápida em cima do switchover VRRP.

Redundância IP Pim

A configuração que é descrita neste documento utiliza a característica nova da relação CLI a fim ligar o PIM a uma sessão VRRS através de uma etiqueta (sequência de caracteres 48):

ip pim redundancy <tag> [vrrp ] dr-priority <value>

ipv6 pim redundancy <tag> [vrrp ] dr-priority <value>

O PIM registra-se como um cliente VRRS e escuta-se as notificações dos eventos VRRP. A fim designar o VRRP MR como o PIM DR em um segmento de multi-acesso, aumente a prioridade PIM DR no mensagem Hello Messages que é enviado do endereço IP de Um ou Mais Servidores Cisco ICM NT físico.

Uma vez que o seguimento VRRP-ciente PIM é permitido em uma relação, os comportamentos diferentes puderam ser observados, dependente de se o pim IP NON-DR-se junta à característica está permitido na mesma relação:

  • Se o pim IP NON-DR-se junta à característica é permitido, o processo que de NonDRs o IGMP relata e crie estados do mrouter como de costume. Diferente do comportamento de NonDR do padrão, NonDRs adiciona relações à lista da interface externa da entrada de rota m, envia o PIM junta-se/ameixa seco decisões rio acima, e puxa o tráfego apenas como o DR. Contudo, NonDRs não ajusta a bandeira F nas relações no MRIB, assim que o tráfego não é enviado da relação. Em lugar de, uma bandeira nova b (obstruída) é ajustada para a relação na lista da interface externa (ÓLEO) do MRIB, que indica que enviar está obstruída nesta relação (se no estado alternativo VRRP). Isto reserva o tempo da convergência rápida em cima do switchover, à custa da largura de banda.

  • Se o pim IP NON-DR-se junta à característica não está permitido, a seguir somente o MR funciona enquanto o PIM DR e processa o PIM decisões juntam-se/ameixas secos quando todos os roteadores de backup ignorarem o IGMP se juntam e o PIM pedidos se junta/ameixa seco. Em cima do switchover, o MR novo envia a mensagem dos hellos de PIM com um endereço IP de Um ou Mais Servidores Cisco ICM NT virtual. Os anfitriões ou as caixas a jusante são provocados então para enviar novamente juntam-se a pedidos, assim que o MR novo processa estes pedidos e puxa o tráfego multicast. Isto conduz a um tempo de convergência mais lento do que a outra aproximação, mas é largura de banda-mais econômico de um ponto de vista do sistema.

Desde que a única instalação do aplicativo do interesse é a encenação do último/primeiramente do salto, o PIM é permitido somente seguir um grupo VRRP pela relação. Você não pode configurar uma relação a fim seguir os grupos múltiplos VRRP, que criariam uma situação onde uma relação estivesse no estado mestre para um grupo VRRP, e no estado alternativo para um outro grupo VRRP.

Em cima do failover do VRRP, o roteador que se tornou o MR novo é elegido como o DR novo:

  • Se o pim IP NON-DR-se junta a característica está permitida, o PIM anda todas as entradas de rota m, cancela a bandeira b, e ajusta a bandeira F nas relações (desde que é agora o MR do grupo VRRP). O MR precedente cancela a bandeira F e ajusta a bandeira b nas relações se incorpora o estado alternativo.

  • Se o pim IP NON-DR-se junta a característica não está permitida, a seguir a lógica Protocolo-ciente do roteador PIM (HSRP-ciente) do standby recente é seguida, o MR novo envia a mensagem dos hellos de PIM com o GenID novo a fim provocar as caixas a jusante para enviar novamente o PIM junta-se a pedidos (ou a esperas para que os anfitriões enviem os relatórios periódicos seguintes IGMP), recreia-se os estados do mrouter, e puxa-se o tráfego através do DR novo.

  • O tráfego é enviado agora com o MR novo (e PIM DR) ao LAN, e não há nenhuma operação exigida nos roteadores downstream de todo em cima do Failover.

Papel do VRRP

O VRRP especifica um protocolo de eleição que atribua dinamicamente a responsabilidade para um roteador virtual que seja representado por um endereço IPv4/IPv6 a um do Roteadores VRRP em um LAN (RFC5798). O roteador VRRP que controla o endereço associado com um roteador virtual é-lhe chamado o mestre, e para a frente os pacotes que são enviados a um endereço do controle de acesso de mídia virtual (MAC).

Quando estes novos recursos são executados, o VRRP está usado a fim eleger o VRRP MR. O VRRP MR executa o roteamento e a transmissão para todo o tráfego que é endereçado ao IP virtual do grupo VRRP (VIP). Isto consegue três objetivos:

  • Notifica VRRS sobre toda a mudança e atualizações de estado do servidor VRRP.

  • Permite todo o PIM pedidos junta-se/ameixa seco alcançar o grupo VIP VRRP, que minimiza mudanças e configurações no lado do roteador downstream (precisam de conhecer o VIP somente).

  • Permite que o PIM DR seja executado no mesmo gateway que o VRRP MR e mantenha estados do mrouter. O tráfego multicast é enviado a calha o VRRP MR, e o PIM pode leverage a Redundância VRRP a fim evitar o tráfego duplicado do potencial e fazer com que o Failover torne-se permitido.

Papel do PIM

O PIM atua como um cliente VRRS, escuta a mudança de estado e as notificações da atualização do server VRRS (VRRP), e:

  • Ajusta automaticamente a prioridade PIM DR baseada no estado VRRP.

  • Recebe notificações da mudança de estado de VRRS para os grupos seguidos VRRP em cima do failover do VRRP. Na resposta, o PIM controla as bandeiras da relação e assegura-se de que o tráfego esteja enviado com o VRRP MR.

Desde que os estados e o tráfego do mrouter estão disponíveis no mestre e em roteadores de backup, o tempo de switchover é decidido na maior parte pela infraestrutura da Redundância (VRRP e VRRS) assim como pela escala da instalação (tal como o número de entradas de rota m). Em cima da notificação da mudança de estado, o PIM notifica imediatamente o MRIB e a base de informação do Multicast Forwarding (MFIB) para enviar o tráfego com o VRRP MR.

Detalhes de implementação

Esta seção apresenta algumas observações importantes sobre a configuração que é descrita neste documento.

Ligamento PIM com um grupo VRRP

O comando CLI PIM é introduzido a fim permitir a Redundância PIM em uma relação e ligá-la a um grupo de servidor VRRS (grupo VRRP):

ip pim redundancy <tag> [vrrp ] dr-priority <value>

ipv6 pim redundancy <tag> [vrrp ] dr-priority <value>

Quando configurado em uma relação, o PIM registra-se com o VRRS como um cliente e obtém-se uma identificação de cliente que seja atribuída pelo base de dados VRRS. Igualmente pede que VRRS enviam notificações ao PIM para todos os eventos para o grupo que é identificado por um <tag>.

Nota: Os server e os clientes VRRS ligam com um nome (sequência de caracteres 48), que seja chamado uma etiqueta. VRRS trabalha através de um mecanismo do registro e da rechamada. Clientes (tais como o PIM) esse registro da Redundância do implementar com o VRRS.  

Incorpore um destes comandos no CLI a fim permitir o NonDR juntam-se à característica:

ip pim non-dr-join

ipv6 pim non-dr-join

Siga grupos múltiplos VRRP em uma relação

Porque a encenação do aplicativo do alvo é instalação somente primeiro/último salto, a instalação a mais comum é onde todo o LHR conecta na trilha LAN o mesmo grupo VRRP. Consequentemente, o PIM é permitido somente seguir um grupo VRRP pela relação, mesmo se você pode permitir VRRS de seguir etiquetas múltiplas pela relação.

Nota: À revelia, a característica é desabilitada.

Configurar

Diagrama de Rede

 

Permita os recursos de redundância PIM

Nota: Há somente um comando CLI que você pode usar a fim permitir a Redundância PIM. Você pode usar os comandos show and debug atuais para o PIM e o HSRP.

Incorpore um destes comandos no CLI a fim permitir os recursos de redundância PIM e especificar a prioridade PIM DR para cada grupo VRRP:

[no] ip pim redundancy <tag> [hsrp | vrrp] dr-priority <value>

[no] ipv6 pim redundancy <tag> [hsrp | vrrp] dr-priority <value>

Incorpore um destes comandos no CLI a fim permitir funcionalidades PIM DR (exceto a transmissão em NonDRs):

[no] ip pim non-dr-join

[no] ipv6 pim non-dr-join

Configurações LHR

Use esta configuração para LHR DR:

interface Ethernet0/0
ip address 10.10.10.1 255.255.255.0
ip pim redundancy VRRP vrrp dr-priority 150
ip pim non-dr-join
ip pim sparse-mode
vrrp 1 address-family ipv4
  vrrs leader VRRP
  priority 120
  track 1 decrement 30
  address 10.10.10.5 primary
exit-vrrp ! track 1 interface Ethernet0/1 line-protocol

Use esta configuração para LHR NonDRs:

interface Ethernet0/0
ip address 10.10.10.2 255.255.255.0
ip pim redundancy VRRP vrrp dr-priority 150
ip pim non-dr-join
ip pim sparse-mode
vrrp 1 address-family ipv4
  address 10.10.10.5 primary
exit-vrrp

Incorpore o comando do resumo do vrrp da mostra a fim ver a configuração LHR:

LHR-DR#show vrrp brief
Interface         Grp A-F Pri Time Own Pre State   Master addr/Group addr
Et0/0               1 IPv4 120     0 N   Y MASTER 10.10.10.1(local) 10.10.10.5
LHR-DR#
LHR-NonDR#show vrrp brief
Interface         Grp A-F Pri Time Own Pre State   Master addr/Group addr
Et0/0               1 IPv4 100 3609 N   Y BACKUP 10.10.10.1 10.10.10.5
LHR-NonDR#

Verificar

Use a informação que é descrita nesta seção a fim verificar que sua configuração trabalha corretamente.

Verifique a informação de base de dados VRRS

Incorpore o comando do server VRRP dos vrrs da mostra no CLI a fim verificar que o base de dados VRRS está povoado pela configuração precedente:

LHR-DR#show vrrs server VRRP

Server Name: vrrpEthernet0/0v41
  Address Family: IPv4
  Interface: Ethernet0/0
  State: ACTIVE
  vMAC: 0000.5E00.0101
  vIP Address: 10.10.10.5
  Tags Connected:
    Tag Name VRRP
LHR-DR#
LHR-NonDR#show vrrs server VRRP

Server Name: vrrpEthernet0/0v41
  Address Family: IPv4
  Interface: Ethernet0/0
  State: BACKUP
  vMAC: 0000.5E00.0101
  vIP Address: 10.10.10.5
  Tags Connected:
LHR-NonDR#

Verifique a informação da relação

Incorpore um destes comandos a fim verificar que as relações estão programadas corretamente para a característica da NON-DR-junta e que o NonDR tem a árvore construída com uma bandeira obstruída:

LHR-DR#show ip pim int e0/0 det | i Non|DR
   PIM DR: 10.10.10.1 (this system)
   PIM Non-DR-Join: TRUE
LHR-NonDR#show ip pim int e0/0 det | i Non|DR
   PIM DR: 10.10.10.1
   PIM Non-DR-Join: TRUE
LHR-NonDR#

Incorpore o comando escasso do mrouter da mostra IP no LHR-NonDR CLI a fim ver o campo obstruído novo:

LHR-NonDR#show ip mroute sparse
(*, 239.1.1.1), 01:26:15/stopped, RP 192.168.1.254, flags: SJC
Incoming interface: Ethernet0/1, RPF nbr 192.168.2.2
Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 00:00:16/00:02:43 Blocked

(192.168.7.2, 239.1.1.1), 00:11:56/00:02:50, flags: T
Incoming interface: Ethernet0/1, RPF nbr 192.168.2.2
Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 00:00:16/00:02:43 Blocked

Inscreva o comando route do mrib da mostra no CLI do LHR-NonDR a fim verificar que a rota MRIB não tem a bandeira F ajustada:

LHR-NonDR#show ip mrib route 239.1.1.1 | b \(
(*,239.1.1.1) RPF nbr: 192.168.2.2 Flags: C
Ethernet0/1 Flags: A NS

(192.168.7.2,239.1.1.1) RPF nbr: 192.168.2.2 Flags:
Ethernet0/1 Flags: A

Como desejado, a rota MRIB tem a bandeira F ajustada no LHR-DR:

LHR-DR#show ip mrib route 239.1.1.1 | b \(
(*,239.1.1.1) RPF nbr: 192.168.3.2 Flags: C
Ethernet0/0 Flags: F NS
Ethernet0/1 Flags: A NS

(192.168.7.2,239.1.1.1) RPF nbr: 192.168.3.2 Flags:
Ethernet0/1 Flags: A
Ethernet0/0 Flags: F NS

Inscreva o comando conf t no CLI do LHR-DR a fim provocar uma mudança de estado VRRP através da parada programada Ethernet0/1:

LHR-DR#conf t
Enter configuration commands, one per line. End with CNTL/Z.
LHR-DR(config)#int e0/1
LHR-DR(config-if)#shutdown
LHR-DR(config-if)#end

Quando você observa as saídas do LHR-NonDR, você pode ver que o estado VRRP mudou (que é informado a VRRS) e que o PIM toma a notificação de VRRS e muda o papel DR em conformidade:

LHR-NonDR#show ip pim int e0/0 det | i DR
   PIM DR: 10.10.10.2 (this system)
   PIM Non-DR-Join: TRUE
LHR-NonDR#
LHR-NonDR# show vrrp brief
Interface         Grp A-F Pri Time Own Pre State   Master addr/Group addr
Et0/0               1 IPv4 100     0 N   Y MASTER 10.10.10.2(local) 10.10.10.5
LHR-NonDR# show vrrs server VRRP

Server Name: vrrpEthernet0/0v41
Address Family: IPv4
Interface: Ethernet0/0
State: ACTIVE
vMAC: 0000.5E00.0101
vIP Address: 10.10.10.5
Tags Connected:

Como esperado, a bandeira F é ajustada e o NonDR começa a enviar o tráfego multicast sem a necessidade de construir uma árvore de transmissão múltipla fresca:

LHR-NonDR# show ip mrib route 239.1.1.1 | b \(
(*,239.1.1.1) RPF nbr: 192.168.2.2 Flags: C
Ethernet0/0 Flags: F NS
Ethernet0/1 Flags: A NS

(192.168.7.2,239.1.1.1) RPF nbr: 192.168.2.2 Flags:
Ethernet0/0 Flags: F NS
Ethernet0/1 Flags: A

Troubleshooting

Dois pacotes foram perdidos na transação da seção anterior. Você pode verificar este no roteador de origem:

Source#ping 239.1.1.1 rep 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Reply to request 0 from 10.10.10.3, 2 ms
Reply to request 1 from 10.10.10.3, 2 ms
Reply to request 2 from 10.10.10.3, 1 ms..
Reply to request 5 from 10.10.10.3, 1 ms

As disposições que são executado (HA) em uma Alta disponibilidade do projeto do Multicast exigem uma formação à espera da árvore em NonDRs e podem tirar proveito da característica da NON-DR-junta. Esta característica puxa o tráfego multicast mas não o envia até que esteja elegida como o DR.

Informações Relacionadas



Document ID: 118859