Introduction
Este artigo continua a série sobre IP Multicast. Vamos dar uma olhada em como funciona o IP Multicast básico. Depois veremos como o PIM Dense Mode (PIM-DM) funciona, como configurá-lo, e como solucionar problemas. Isto deverá aquecer-nos antes de assumirmos o modo PIM Sparse, um pouco mais complexo e escalável, num artigo posterior.
O artigo multicast inicial contém links para os principais grupos de trabalho IETF no seu final. Pode ser encontrado em The Protocols of IP Multicast.
Understanding IP Multicast Forwarding
O propósito de um protocolo de roteamento multicast é permitir que roteadores trabalhem juntos para entregar cópias de pacotes multicast aos receptores interessados de forma eficiente. No processo de fazer isso, o protocolo de roteamento multicast provavelmente também fornece um mecanismo para os vizinhos descobrirem e rastrearem os roteadores vizinhos também usando o protocolo de roteamento multicast.
Como vimos no último artigo, aqueles computadores interessados em receber um fluxo de pacotes multicast usam IGMP para notificar o(s) roteador(es) adjacente(s). Os roteadores então usam o protocolo multicast para organizar o envio de uma cópia do fluxo de pacotes multicast para que eles possam encaminhá-lo para a LAN que contém o receptor. Não fizemos nenhuma menção ao que acontece no final da origem do fluxo de pacotes. Em multicast IP, não há protocolo para a fonte comunicar ou registrar ou notificar os roteadores. A fonte apenas começa a enviar pacotes IP multicast, e cabe ao(s) roteador(es) vizinho(s) fazer a coisa certa. (O que acontece de “coisa certa” depende do protocolo de roteamento multicast).
A figura a seguir mostra uma fonte enviando um pacote multicast em vermelho, e roteadores downstream duplicando o pacote e inundando-o para outros roteadores e finalmente todos os segmentos da LAN. Como veremos em breve, este é o comportamento inicial (e periódico) do protocolo de roteamento multicast independente de protocolo da Cisco (PIM), quando atuando em Modo Denso.
Nota na figura acima que as setas azuis encaminham o pacote multicast de forma organizada. Pode haver duas cópias de cada pacote entrando em alguns dos roteadores ou segmentos LAN. Mas os roteadores não encaminham os pacotes “para trás”. Isto é uma coisa boa: pense no que poderia acontecer se o roteador E encaminhasse uma cópia do pacote que recebeu de C para o roteador B. B então encaminharia o pacote para A, que poderia encaminhá-lo para C, e assim por diante, em um loop de encaminhamento? Isso seria uma espécie de equivalente à Camada 3 do que acontece na Camada 2 quando o Spanning Tree é desabilitado em uma topologia de loop: uma boa maneira de desperdiçar muita largura de banda e capacidade do roteador.
Para prevenir loops de encaminhamento de multicast, o IP multicast sempre realiza uma verificação de RPF, que falaremos em breve.
Além da verificação de RPF, protocolos de roteamento multicast como o PIM também podem funcionar para prevenir a ineficiência. Por exemplo, o roteador E na figura não precisa receber duas cópias de cada pacote multicast (uma de B, uma de C).
O protocolo de roteamento multicast determina quais interfaces enviar cópias (ou não enviar cópias). Como a figura acima sugere, o encaminhamento de multicast ocorre ao longo de árvores lógicas, ramificando caminhos através da rede. Todas as informações de encaminhamento de multicast são armazenadas na tabela de estados de multicast, que algumas pessoas chamam de tabela de roteamento de multicast. Esta informação pode ser visualizada com o comando muito útil, mostrar ip mroute. Vamos dar uma breve olhada no exemplo de saída do comando show ip mroute (com o Modo Denso do PIM rodando).
Router# show ip mroute 233.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit setTimers: Uptime/ExpiresInterface state: Interface, Next-Hop, State/Mode(*, 233.1.1.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0, flags: DC Incoming interface: Null, RPF neighbor 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Dense, 0:57:31/0:02:52 FastEthernet1, Forward/Dense, 0:56:55/0:01:28 FastEthernet2, Forward/Dense, 0:56:45/0:01:22(172.16.16.1/32, 233.1.1.1), uptime 20:20:00, expires 0:02:55, flags: C Incoming interface: FastEthernet1, RPF neighbor 10.20.30.1 Outgoing interface list: Ethernet0, Forward/Dense, 20:20:00/0:02:52
Para entender isso, note que endereços começando com 224-239 são endereços ou grupos de multicast IP. (O grupo refere-se ao grupo de receptores para aquele endereço de destino multicast).
A entrada que começa com (*, 233.1.1.1) é uma entrada de árvore multicast compartilhada, às vezes referida como uma entrada (*, G). (G aqui é apenas 223.1.1.1.1). O PIM-DM não as utiliza para encaminhamento de pacotes, mas lista interfaces com uma função em multicast (receptor IGMP conhecido ou vizinho do PIM) como interfaces de saída sob tais entradas.
A entrada que começa com (172.16.16.1, 233.1.1.1.1) é referida como uma entrada (S, G). S é fonte, G é grupo. Se você preferir, pense nisso como origem e destino no cabeçalho IP (já que é onde eles realmente aparecem nos pacotes). Esta entrada é uma árvore multicast específica de origem para um grupo multicast em particular. Geralmente haverá uma dessas entradas para cada fonte e grupo. Observe que o próximo salto do roteiro unicast aparece como o vizinho RPF, e a interface de entrada é a interface RPF, a interface usada pelo roteiro unicast em direção à origem 172.16.16.1. A lista da interface de saída mostra que qualquer pacote da 172.16.16.1 com destino 233.1.1.1 recebido em FastEthernet1 será copiado para fora da Ethernet0.
Você pode desenhar a árvore de encaminhamento de multicast para um determinado (S, G) para fins de solução de problemas. Para fazer isso, execute o comando show ip mroute em cada roteador. Pegue uma cópia do seu mapa de rede e desenhe uma seta de saída para cada interface da lista de saída (“OIL” ou “OILIST”). Você terminará com um diagrama um pouco parecido com a figura acima.
State flags que você pode ver no PIM-DM mostrar a saída da rota do ip:
- D = Dense Mode. Aparece apenas nas entradas (*, G). Grupo está operando em modo Denso.
- C = Host diretamente conectado (IGMP!)
- L = Local (Roteador está configurado para ser um membro do grupo multicast).
- P = Podado (Todas as interfaces OILIST configuradas para Podar). O roteador geralmente envia a Poda para seu vizinho RPF quando isso ocorre.
- T = Encaminhamento via árvore de caminhos mais curtos (SPT), indica pelo menos um pacote recebido / encaminhado.
- J = Junte-se ao SPT. Sempre ligado em (*,G) entrada no PIM-DM, não significa muito.
O que é a Verificação RPF, e Porquê?
IP multicast forwarding sempre executa uma verificação RPF. RPF significa Reverse Path Forwarding (Encaminhamento por Caminho Inverso). O objectivo da verificação RPF é tentar evitar um loop de reencaminhamento de pacotes multicast de uma forma simples. Para cada fluxo multicast, o roteador multicast verifica o endereço de origem, que dispositivo enviou o multicast. Em seguida, ele procura o remetente na tabela de roteamento unicast e determina a interface que ele usaria para enviar pacotes unicast para a fonte multicast. Essa interface é a interface RPF, aquela em que o roteador “espera” receber multicasts. Pense nela como a interface “oficialmente aprovada” para receber multicasts daquela fonte em particular. O roteador armazena a interface RPF como parte das informações de estado do multicast para aquela fonte em particular e aquele destino (grupo) multicast em particular.
Quando um pacote multicast é recebido pelo roteador, o roteador rastreia qual interface o pacote entrou. Se o pacote é o primeiro pacote de uma nova fonte, a interface RPF é determinada e armazenada na tabela de rotas, conforme discutido anteriormente. Caso contrário, o roteador procura o grupo de origem e multicast na tabela de roteamento. Se o pacote foi recebido na interface RPF, o pacote é copiado e encaminhado em cada interface de saída listada na tabela de roteamento. Se o pacote foi recebido em uma interface não-RPF, ele é descartado. Se o roteador fosse uma pessoa, isso seria o equivalente a “Para que essa pessoa está me enviando isso? Eles devem estar confusos, vou ignorar o que eles acabaram de me enviar”
O roteador também não envia uma cópia de um pacote para fora da interface em que entrou (a interface RPF). Em outras palavras, mesmo que o roteador vizinho na interface RPF, de alguma forma, solicite o envio de cópias de um fluxo multicast, o roteador não adicionará a interface RPF à lista de interfaces de saída que recebem cópias do fluxo multicast. Isto protege contra qualquer tipo de erro de protocolo que coloque dois vizinhos em um loop de encaminhamento de multicast apertado.
Router E também está provavelmente ignorando um dos dois fluxos de pacotes, com base em se B ou C está conectado à interface RPF. Mesmo com rotas de custo igual, normalmente apenas uma interface é escolhida como a interface RPF. Então se você tiver dois links conectando dois roteadores, apenas um será tipicamente usado para multicast de qualquer subrede de origem.
Veja no entanto o comando ip multicast multicast multicaminhos (novo no Cisco IOS Versão 12.0(8) T, 12.0(5) S). Com este comando, usado corretamente, pode haver balanceamento de carga para diferentes fontes para um grupo multicast em particular. Como este é por fonte e não por fluxo, ele realmente se torna mais parecido com a divisão de carga. Pode não acabar sendo muito equilibrado.
Carregar o balanceamento de tráfego para um fluxo de pacotes (uma fonte e grupo) em duas ligações entre dois roteadores também pode ser feito usando túneis GRE entre interfaces loopback, embora eu possa me preocupar com as implicações de desempenho de fazer isso com um alto fluxo de banda.
Por falar nisso, isso também nos diz como direcionar o multicast IP sobre ligações de nossa escolha. Nós controlamos onde o tráfego multicast vai, controlando a verificação RPF. Se um router não aprender rotas de volta para uma fonte multicast em alguma interface, então essa interface não será a interface RPF. Assim, com protocolos vectoriais de distância e “route starvation” (não anunciando uma rota a um vizinho), podemos direccionar ou direccionar multicast.
Veremos mais tarde que quaisquer enxertos ou junções PIM são enviados para fora da interface RPF, de volta para a fonte (ou RP, no modo PIM Sparse). Controlando onde essa atividade ocorre, controlamos quais links o multicast é encaminhado. As entradas de rotas estáticas (rotas estáticas de volta à fonte para fins de verificação de RPF multicast) são outra forma de direcionar o tráfego de multicast. Se / quando falamos de MBGP multicast (Multiprotocol BGP for Multicast), veremos que MBGP também nos fornece uma forma de dirigir ou controlar os links utilizados pelo tráfego multicast. Note também que se a interface RPF não tem IP multicast habilitado, então na verdade o roteador está esperando pacotes onde não irá recebê-los. A interface RPF deve ser sempre uma onde o multicast IP esteja activado.
PIM Dense Mode – Overview
Protocol Independent Multicast tem dois modos, Dense Mode e Sparse Mode. Este artigo só tem espaço para cobrir o primeiro. Vamos chegar ao PIM-SM no próximo artigo.
PIM Dense Mode (PIM-DM) usa uma abordagem bastante simples para lidar com o roteamento IP multicast. A suposição básica por trás do PIM-DM é que o fluxo de pacotes multicast tem receptores na maioria dos locais. Um exemplo disso pode ser uma apresentação da empresa pelo CEO ou Presidente de uma empresa. Em contraste, o PIM Sparse Mode (PIM-SM) assume relativamente menos receptores. Um exemplo seria o vídeo de orientação inicial para novos funcionários.
Esta diferença aparece no comportamento e mecanismos iniciais dos dois protocolos. O PIM-SM só envia multicasts quando solicitado. Enquanto o PIM-DM começa por inundar o tráfego multicast, e depois pára cada link onde ele não é necessário, usando uma mensagem de Ameixa. Eu penso na mensagem Prune como um roteador dizendo a outro “nós não precisamos daquele multicast aqui agora”.
Em versões antigas do Cisco IOS, o PIM-DM iria inundar novamente todo o tráfego multicast a cada 3 minutos. Isto é bom para multicast de baixo volume, mas não para pacotes multicast com maior largura de banda. Versões mais recentes do Cisco IOS suportam um novo recurso chamado PIM Dense Mode State Refresh, desde 12.1(5)T. Este recurso usa uma mensagem de atualização de estado do PIM para atualizar o estado da Ameixa nas interfaces de saída. Outro benefício é que as mudanças de topologia são reconhecidas mais rapidamente. Por padrão, as mensagens de atualização de estado do PIM são enviadas a cada 60 segundos.
Roteadores de memória E e F na figura acima. Quando dois roteadores PIM-DM se conectam a uma LAN, eles verão os pacotes multicast um do outro. Um deve encaminhar os pacotes para a LAN, e o outro não. Ambos enviam mensagens de Assert. A melhor métrica de roteamento ganha, com endereço IP mais alto como um tie-breaker. Se eles estiverem usando protocolos de roteamento diferentes, um esquema métrico de roteamento ponderado, um pouco como a distância administrativa, define qual roteador será o Forwarder (encaminhando os pacotes multicast para a LAN). O Forwarder pode ser silenciado por uma Ameixa de um roteador downstream sem receptores, se também não houver receptores no segmento da LAN. Os roteadores Downstream podem ter que ajustar seu vizinho RPF, para refletir o vencedor do processo Assert.
Para repetir isso com todos os detalhes: quando o tráfego multicast é recebido em uma interface não-RPF, uma mensagem Prune é enviada, desde que a interface seja ponto a ponto. Estas mensagens Prune são limitadas em taxa, para garantir que o volume delas (potencialmente, uma por multicast recebido) não cause mais problemas.
Se a interface não-RPF for uma LAN, uma mensagem Assert é enviada. Os roteadores não-Forwarder então enviam uma Amostra na sua interface RPF se não precisarem do fluxo multicast. Somente uma dessas Ameixa é enviada, no momento da transição para não ter interfaces na Outgoing Interface List (OILIST). O receptor LAN Prune retarda a ação dele por 3 segundos, de modo que se outro roteador LAN ainda precisar do fluxo multicast, ele pode enviar uma mensagem PIM Join para contra-atacar (cancelar) a Poda. (“Yo, esse router não precisa dele, mas eu ainda preciso!”)
Suponha que um router tenha podado, e algum tempo depois um receptor solicita o fluxo multicast com uma mensagem IGMP. O roteador então envia uma mensagem de Graft. Na verdade, “ei, eu preciso desse fluxo multicast aqui agora”.
A figura seguinte ilustra isso, reconhecidamente de uma forma um tanto comprimida.
Explicação da figura:
(1), talvez o roteador E escolha B como seu vizinho RPF, baseado no roteamento unicast de volta à fonte. Então E recebe um pacote multicast na interface ponto-a-ponto de C. Ele envia uma ameixa de taxa limitada para C.
(2), os roteadores E e F na troca LAN Assert packets, quando E ou F vê o multicast encaminhado pelo outro dos dois. Suponha que E ganha, com base na métrica ou endereço de roteamento unicast. Então F sabe que não deve reencaminhar multicasts na LAN. Note que G e H não estão envolvidos, já que a Ethernet é sua interface RPF.
(3), suponha que o roteador G não tenha receptores downstream. Ele pode então enviar uma Amostra da LAN para o Forwarder para a LAN, roteador E.
(4), se o roteador H tem receptor(es) local ou downstream, ele contraria isso com um LAN Join.
(5), suponha que o roteador D não tinha receptores downstream ou locais e enviou uma Amostra para B. Suponha que algum tempo depois do PC à sua direita envie uma mensagem IGMP para o mesmo grupo multicast. O roteador D pode então enviar um PIM Graft para B, pedindo a B para retomar o envio do grupo multicast especificado.
Protocolo PIM e Tipos de Pacotes
PIM é um protocolo de roteamento completo, com vários tipos de mensagens. Eu não estou prestes a drone on e on sobre as diferentes mensagens. Mas acho que vale a pena dar uma breve olhada, pois nos fala um pouco sobre o protocolo.
PIM usa mensagens de Olá para descobrir vizinhos e formar adjacências. O Hello é enviado para o endereço multicast local do All-PIM-Routers, 224.0.0.13, a cada 30 segundos (PIMv1 usa AllRouters, 224.0.0.2). Cada LAN tem um Roteador Designado PIM (DR), usado no modo PIM Sparse. É também o IGMPv1 Querier: o endereço IP mais alto da LAN. O comando mostrar vizinho do ip pim mostra vizinhos e informações de proximidade e temporizador.
Clarificação adicionada 12/11/2004: IGMP querier e Designated Router são as duas funções em questão. Veja aqui.
Na versão 1 do IGMP, “O DR é responsável pelas seguintes tarefas:
- Enviar registro PIM e mensagens PIM join e prune para o RP para informá-lo sobre a adesão ao grupo host.
- Enviar mensagens de consulta ao host IGMP”
Na versão 2 do IGMP, elas são desacopladas. A consulta IGMP é eleita pelo IP mais baixo da LAN. O PIM seleciona o DR pelo IP mais alto na LAN, para encaminhar multicasts para a LAN. (Esta descarga funciona).
PIM também tem uma mensagem Join/Prune, usada como descrito acima. Há também as mensagens Graft e Graft ACK, que nos diz que Graft é feito de forma confiável (ao contrário do mundo real?).
E há a mensagem PIM Assert.
PIM-SM tem mais 3 tipos de mensagens: Register, Register-Stop, e RP-Reachability (não no PIMv2).
Configurar o modo denso do PIM
Configurar o PIM-DM é muito fácil em comparação com todos os anteriores.
Globalmente, active o encaminhamento de multicast com o comando:
ip multicast-routing
Então em cada interface que deseja participar no multicasting, active o IP multicast e o PIM com o comando de interface:
interface …
ip pim dense-mode
Atualmente, é melhor configurar o modo sparse-dense:
interface …
ip pim modo denso-esparso
A razão é que isto permite simplesmente migrar alguns ou todos os grupos multicast para o modo esparso, deixando o router saber sobre um Ponto de Encontro. E você pode até mesmo fazer isso sem reconfigurar um monte de roteadores ou interfaces de roteador.
Você pode configurar redes stub para multicast IP simples. A idéia é não executar o PIM para stub partes da rede, como pequenos sites remotos, para simplificar. Esta é uma idéia particularmente boa com roteadores que não estão sob seu controle: você não quer que eles compartilhem o roteamento multicast com seus roteadores. Também elimina a inundação PIM-DM para tais routers (com versões mais antigas do Cisco IOS).
Para configurar stub multicast, configure
ip igmp helper-address a.b.c.d
em qualquer interface LAN de router stub com potenciais receptores multicast. O endereço a.b.c.d é o endereço do roteador central que fala PIM. No roteador central, você configura um filtro para afinar qualquer mensagem PIM que o vizinho stub possa enviar, com:
ip pim neighbor-filter access-list
Veja também o Guia de Comandos na URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Existem vários comandos de exibição para ajudar a solucionar problemas de multicast IP. Os que eu mais gosto:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Posto que o espaço é apertado, eu vou referi-lo ao Command Reference para exemplos.
Uma nota de solução de problemas: se você tiver alta largura de banda multicast na sua rede, certifique-se de usar o Prune State Refresh nos lançamentos mais recentes do Cisco IOS se você estiver usando o modo esparso-denso. Eu me preocupo em roteadores “esquecendo” que eles têm um RP e revertendo para o Modo Denso, com flooding periódico. Isto pode ser uma rara ocorrência acidental, mas pode realmente arruinar a sua manhã! Também pode querer considerar técnicas de robustez de RP, um tópico para o nosso posterior artigo PIM-SM ou Rendezvous Point.
Em Conclusão
O livro recomendado para muitos tópicos de multicast: Desenvolvendo Redes IP Multicast: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
Outro link Cisco multicast extremamente bom pode ser encontrado aqui.
Próximo artigo: escalando com o modo PIM Sparse.