Multicast on Cisco Network

IP Multicast

Bernardo Pina

Filipe Cunha

Pedro Fernandes

Departamento de Ciências de Computadores

2008/2009

Índice
1 INTRODUÇÃO ........................................................................................................................ 3

2 IP MULTICAST ........................................................................................................................ 4

2.1 Spanning Tree................................................................................................................ 5

2.2 Algoritmos de criação das árvores ................................................................................ 5

2.2.1 Reverse Path Forward ........................................................................................... 5

2.2.2 Shortest Path Tree ................................................................................................. 6

2.2.3 Shared Tree (Steiner Tree) .................................................................................... 7

2.2.4 Center Based Tree ................................................................................................. 7

2.3 Protocolos IP Multicast ................................................................................................. 8

2.3.1 Internet Group Management Protocol (IGMP) ..................................................... 8

2.3.2 Protocol Independent Multicast (PIM)................................................................ 10

2.3.3 Distance Vector Multicast Routing Protocol (DVMRP) ....................................... 11

2.3.4 Multicast Open Shortest Path First (MOSPF) ...................................................... 12

3 INTRODUÇÃO AO LABORATÓRIO ........................................................................................ 13

3.1 Software necessário .................................................................................................... 13

3.1.1 SDR (Session Directory) ....................................................................................... 13

3.1.2 Ferramentas de documentos compartilhados e edição de texto ....................... 13

3.1.3 Ferramentas de vídeo e áudio............................................................................. 13

3.2 Topologia de rede ....................................................................................................... 14

3.3 Método usado ............................................................................................................. 14

4 LABORATÓRIO ..................................................................................................................... 16

4.1 Outros pacotes capturados na rede ............................................................................ 26

5 CONCLUSÃO ........................................................................................................................ 29

6 BIBLIOGRAFIA ...................................................................................................................... 30

7 ANEXOS ............................................................................................................................... 31

2

1 INTRODUÇÃO

No final dos anos 80, ninguém tinha noção do impacto que o IP Multicast teria nas nossas vidas,
nas mais diversas áreas: finanças, transportes, entretenimento, etc.
Hoje as aplicações multicast estão presentes em quase todo o lado, intimamente associadas a
uma serie de situações do nosso dia-a-dia. Desde as comuns videoconferências, seja com
familiares ou colegas de trabalho, até ao vulgar sítio de e-learning que costumamos aceder
diariamente. Todos eles podem partilhar a particularidade, imperceptível para o utilizador
normal, de executarem sobre IP Multicast.

Para perceber como esta tecnologia evoluiu, e tornou-se uma ferramenta estratégica e
importante para redes de negócios, temos de voltar atrás e entender como é que as coisas
eram feitas antes desta inovação revolucionária.

Tradicionalmente, quando alguém precisava de transmitir uma mesma informação para vários
destinos, a fonte teria de emitir, para a rede, uma cópia separada para cada destino.
Se a fonte fosse um stream de vídeo, a enviar a mil utilizadores simultaneamente, isto
significaria que o emissor teria de criar mil cópias dessa mesma stream e envia-la mil vezes
para a rede.
Isto pressupõe um enorme esforço por parte do servidor/emissor assim como uma incrível
sobrecarga, claramente ineficiente, da rede.

Assim entramos na revolução trazida pelo IP multicast.
O IP Multicast permite que os utilizadores consigam distribuir eficientemente informação -
como vídeo, voz e dados - entre utilizadores remotos, reduzindo assim o congestionamento no
lado do servidor, ao possibilitar o envio de uma stream apenas para a rede.
Toda a informação que tem necessidade de ser enviada para vários destinos ao mesmo tempo
pode tirar partido desta tecnologia.

De entre os vários benefícios podemos enunciar:

 Eficiência elevada (largura de banda, etc)
 Aumento de escalabilidade
 Eliminação de redundância
 Redução de sobrecarga nos servidores e processadores
 Aumento de performance

3

2 IP MULTICAST

Mas como funciona afinal o multicast?
O funcionamento do Multicast está intimamente ligado a criação de “árvores”. Estas “árvores”
são dinamicamente criadas através do uso de dois simples protocolos (a título de exemplo):
IGMP e PIM.
O IGMP é usado pelos receptores/emissores (utilizadores normais), para comunicarem com os
routers, e o PIM é usado pelos routers que participam na rede, para comunicarem entre si.
Para realizar transmissões de dados através do IP Multicast, as máquinas são organizadas em
grupos e recebem um endereço comum, o endereço do grupo Multicast. Quando alguma
máquina pretende enviar datagramas para todas as máquinas de um determinado grupo,
simplesmente envia os datagramas para o endereço do grupo: um endereço IP classe D
(compreendido entre 224.0.0.0 e 239.255.255.255).

Funções Endereços Multicast Reservados
Local Network Control Block 224.0.0.0-224.0.0.255

Internetwork Control Block 224.0.1.0-224.0.1.255

Spanning Tree Multicast Groups 224.1.0.0-224.1.255.255

SDP/SAP Block 224.2.0.0-224.2.255.255

Administratively Scoped 239.0.0.0-239.255.255.255

Tabela 1: Tabela com alguns dos endereços reservados para serviços IP Multicast.

Os grupos multicast são dinâmicos, os membros podem ingressar ou sair a qualquer momento.
Não existem restrições para o número de membros de um grupo e uma estação pode
participar de mais de um grupo ao mesmo tempo, assim como pode enviar datagramas a um
grupo sem lhe pertencer.
Existem grupos que possuem um endereço conhecido, fixo, denominados grupos permanentes.
Mas apenas o endereço é permanente, os membros destes grupos não são fixos e, num dado
momento, um grupo permanente pode ter qualquer número de membros, inclusive zero.
Os endereços IP multicast que não são reservados para nenhum grupo permanente estão
disponíveis para atribuição dinâmica de grupos temporários. Estes grupos existem apenas
enquanto possuem membros, sendo depois eliminados.

O Multicast pode ser usado numa rede física simples ou através da Internet. Neste último caso,
os datagramas são transmitidos por gateways multicast especiais denominados routers
multicast.
Uma estação transmite um datagrama multicast como um multicast de rede local, que atingirá
todos os membros do grupo pertencentes a rede local. Se o datagrama possuir um IP time-to-
live (correspondente ao campo time-to-live do datagrama IP) maior que um, o router multicast
ligado a rede transmite o pacote para todas as outras redes que possuem membros do grupo,
desde que sejam atingíveis dentro do seu time-to-live. Os routers multicast pertencentes as
redes destinos completam a entrega, transmitindo o datagrama como multicast local.

Se dois utilizadores, pertencentes ao mesmo grupo multicast, requisitassem uma mesma
stream multicast e estivessem em localizações diferentes, utilizariam IGMP para comunicar
4

com a rede. Os routers mais próximos desses, que percebem IGMP, iriam então usar o PIM
para se interconectarem numa reacção em cadeia em direcção ao emissor da stream.
Agora entra o conceito chave do IP Multicast: packet replication. O Packet replication acontece
quando a stream chega a bifurcação que leva a cada um dos destinos da stream. Nesse router,
e só aí, a informação é replicada e transmitida para ambos os destinos simultaneamente.
O resultado final é uma árvore cujos ramos interconectam apenas os receptores interessados,
permitindo que estes recebam uma cópia singular da informação.

Ilustração 1: Funcionamento do IP Multicast.

2.1 Spanning Tree

Como são criadas essas árvores?
Existem uma serie de condicionantes e factores importantes que devem ser levados em conta.
As árvores não devem conter ciclos. Tal comprometeria desde logo a eficiência da rede, uma
vez que possibilitaria a ocorrência de fenómenos de flooding.
Dados esses factos, a árvore terá de ser uma spanning tree.
Uma spanning tree é uma árvore composta por todos os nós de um dado grafo inicial, sem no
entanto existir ciclos entre os mesmos. Existem apenas as ligações mínimas para que todos os
nós estejam interligados.

2.2 Algoritmos de criação das árvores

2.2.1 Reverse Path Forward
O algoritmo Reverse Path Forwarding (RPF) é utilizado para encaminhar os pacotes, com a
adição de dois conceitos: prunes e grafts.
Assim, quando o primeiro pacote multicast de determinado grupo chega ao router, ele,
encaminha-o para toda a árvore multicast, excepto para quem lhe enviou o pacote, ou já foi
visitado.

5

O router “emissor” recebe mensagens de prune (corte/poda) nos caminhos onde não deve ser
encaminhado o pacote (caminhos que não contenham nenhum terminal activo naquele grupo
multicast).
O resultado é que todos os routers da árvore devem estar cientes da existência daquele grupo,
armazenando-o na sua tabela como activo (se tem receptores activos) ou pruned (se não tem
receptores activos). Quando um terminal quer fazer um join num grupo multicast pruned,
envia a mensagem IGMP ao router mais próximo, que deve enviar uma mensagem do tipo
graft para refazer o caminho até a origem.

Ilustração 2: Funcionamento do RPF.

2.2.2 Shortest Path Tree

O algoritmo Shortest Path Tree (SPT) dá origem a um subgrafo, de um grafo já existente, em
que as distâncias entre a fonte (nó raiz) e todos os outros nós, é mínima.
A fim de minimizar o comprimento total de um caminho, o percurso desde o nó raiz até cada
um dos nós, tem que ser o caminho mais curto entre eles. Senão, esse tipo de percurso é
substituído com um outro caminho mais curto, e é obtido uma “spanning tree” mais leve em
que o comprimento total desse caminho, do nó raiz aos restantes nós, é o menor.
De seguida serão apresentados dois dos mais conhecidos algoritmos de construção de
“Shortest Path Tree”, O algoritmo Dijkstra e o Bellman-Ford.

 Dijkstra’s Algorithm
Este algoritmo soluciona o problema do caminho mais curto num grafo dirigido ou não
dirigido com arestas de peso com valores não negativos, em tempo computacional O
([m+n]log n) onde m é o número de arestas e n é o número de vértices. A
complexidade deste algoritmo é quadrada, ou seja: O(n*n).

 Bellman-Ford Algorithm
O Algoritmo de Bellman-Ford é um algoritmo de busca de um caminho mínimo num
dígrafo ponderado, ou seja, cujas arestas têm pesos, inclusive negativos. O Algoritmo
de Dijkstra resolve o mesmo problema, num tempo menor, porém exige que todas as
arestas tenham pesos positivos. Portanto, o algoritmo de Bellman-Ford é normalmente
usado apenas quando existem arestas de peso negativo. O algoritmo de Bellman-Ford
executa em tempo O(v*a) onde “v” é o número de vértices e “a” o número de arestas.

6

2.2.3 Shared Tree (Steiner Tree)

Neste tipo de algoritmo é calculada uma árvore de custo mínimo, com todos os routers que
contêm membros de um determinado grupo Multicast.
Este algoritmo representa um problema de computação complexa, de classe “NP-complete”
(Nondeterministic Polynomial).
A característica mais notável para problemas “NP-complete” é a de não existir uma solução
rápida para eles. Ou seja, o tempo necessário para resolver o problema usando qualquer um
dos algoritmos mais conhecidos aumenta muito rapidamente à medida que o tamanho do
problema aumenta. E este é um dos principais problemas deste algoritmo, pois é um tipo de
problema “NP-complete”, ou seja, muito difícil de resolver. No entanto, é importante referir
que existem excelentes heurísticas sobre este problema.
Não é usada na prática pois é de uma complexidade computacional elevada e é necessária
informação sobre toda a rede.
A figura abaixo ilustrada exemplifica o funcionamento deste algoritmo.

4
3
2
1

2 2

1 1

Ilustração 3: Funcionamento de uma Shared Tree.

2.2.4 Center Based Tree

Neste tipo de algoritmo é usada uma única árvore que é partilhada por todos os “routers”.
Um router é identificado como sendo o “centro” da árvore.
Exemplificando este algoritmo temos que:
 O router num vértice envia em “unicast” um “join” endereçado para o router central.
 Essa mensagem prossegue pelos “routers” intermédios ate chegar ao router central.
 A mensagem ou chega ao centro ou percorre um ramo que já existe.
 O caminho percorrido pela mensagem passa a ser um novo ramo da árvore para esse
router que enviou a mensagem.

7

A figura abaixo ilustrada exemplifica o funcionamento deste algoritmo em que o router R6 é o
escolhido para ser o router central.

LEGEND

R1 router with attached
R4
3 group member

R2 router with no attached
2 group member
1
R5 path order in which join
messages generated
R3
1 R6 R7

Ilustração 4: Funcionamento do Center Based Tree

2.3 Protocolos IP Multicast

2.3.1 Internet Group Management Protocol (IGMP)

O Internet Group Management Protocol (IGMP) é um protocolo de comunicação utilizado para
gerir os grupos de IP multicast. É utilizado apenas entre os terminais e os routers multicast
adjacentes (Figura 1).
Este protocolo permite a um terminal, informar o router adjacente, de que uma aplicação tem
intenção de se juntar a um determinado grupo multicast. Dado que este protocolo apenas se
limita à comunicação entre os dispositivos já referidos, torna-se clara a necessidade de outro
protocolo para a coordenação de routers multicast que se encontram na restante rede. Isto é
feito por algoritmos de routing multicast ao nível da camada de rede como o PIM, DVMRP e o
MOSPF (descritos posteriormente), só para citar os mais conhecidos.

Ilustração 5: Funcionamento do IGMP.

Mensagens IGMP
8

As mensagens IGMP, que permitem gerenciar os grupos IP multicast, podem ser de três tipos
diferentes:

 membership_query

Este tipo de mensagem é enviado pelos routers para todos os terminais a ele ligados, para
determinar todos os grupos multicast a que esses mesmos terminais pertencem. Pode
também determinar quando um terminal se tornou membro de um grupo multicast
específico, indicando o endereço do grupo em questão no campo Multicast group address
do pacote.

 membership_report

É o tipo de mensagem utilizado pelos terminais para responder aos membership_query.
Pode também ser gerada por terminal no caso de este se juntar a um grupo multicast sem
aguardar por um membership_query enviado pelo router multicast adjacente.

 leave_group

Mensagens deste tipo são geradas por um terminal quando este sai de um grupo multicast.
Apesar da aparente importância deste tipo de mensagem, esta é de carácter opcional. Isto
porque os routers tem outra forma de determinar este evento: quando um router envia
mensagens membership_query com o endereço do grupo em questão e não recebe
resposta de um determinado terminal, admite que esse terminal já não pertence a esse
grupo.

IGMP snooping

O snooping IGMP é o processo de escuta de tráfego IGMP utilizado nos switches. Tal como o
nome indica, permite que os switches escutem toda a troca de pacotes entre terminais e
routers numa rede multicast, à medida que os processam.
Quando o IGMP snooping se encontra activo, o switch analisa todos os pacotes trocados entre
os terminais, e os routers multicast a ele ligados. Quando um switch escuta um report de um
terminal relativamente a um grupo multicast, adiciona o número da porta do terminal à lista
de multicast do respectivo grupo. Da mesma forma, quando escuta uma mensagem IGMP
Leave, remove a entrada da tabela, correspondente ao terminal que pretende deixar o grupo.
O snooping IGMP pode ajudar a reduzir consideravelmente o tráfego multicast, relativo a
streaming e outras aplicações IP que consumam grande largura de banda. Enquanto um switch
que não entenda multicast vai reencaminhar o tráfego para todas as suas portas (Figura 3), um
switch utilizando snooping IGMP apenas o fará para os terminais que realmente estejam
interessados nessa informação (Figura 4). Esta redução de tráfego multicast, reduz não só o
processamento de pacotes no switch mas também reduz a quantidade de trabalho necessária
nos terminais, visto que não terão que receber e filtrar todo o tráfego multicast gerado na
rede.

9

Ilustração 6: Funcionamento do IGMP Snooping.

2.3.2 Protocol Independent Multicast (PIM)

O Protocol-Independent Multicast (PIM) – RFC 2362 - é um protocolo de routing multicast, que
permite a distribuição de dados na forma um-para-muitos e de muitos-para-muitos através da
Internet.
A parte “protocol-independent”, refere-se ao facto do PIM não incluir um mecanismo de
descoberta de topologia de rede próprio. Em vez disso, utiliza informação de routing fornecida
por outros protocolos de routing tradicionais como o OSPF ou RIP.
Para desempenhar a sua tarefa, dispõe de quatro modos de distribuição:

Dense Mode (DM)
O dense mode, utilizado em situações em que os membros de um determinado grupo se
encontrem distribuídos por toda a rede e obrigue assim grande parte dos routers da
rede a participar no processo de routing de datagramas multicast.
O PIM-DM utiliza uma técnica “flood-and-prune”. Inicialmente os pacotes multicast são
enviados para toda a rede e depois são “cortados” todos os ramos da rede que não
tenham terminais interessados nesta informação.

Sparse Mode (SM)
O outro modo de operação é o sparse mode. Neste modo, o número de routers com
utilizadores multicast ligados é pequeno, comparativamente ao número total de routers
da rede. Este modo de operação é indicado para situações em que é necessário um
controlo mais apertado do tráfego na rede, especialmente quando lidamos com grandes
quantidades de tráfego comparativamente à largura de banda de que dispomos.
Quando um router (designated router) recebe datagramas de um terminal para ser
distribuído pela rede, este encapsula-os em mensagens PIM de controlo e reencaminha-
os por unicast para o rendezvous point (RP).
Esse RP é depois responsável pela distribuição da mensagem para os destinos
pretendidos. Isto torna o PIM-SM bastante escalável, na medida em que os datagramas
apenas são enviados pelo caminho realmente necessário, sem sobrecarregar routers
que não aqueles por onde os datagramas irão passar.

10

Bidirectional PIM (BM)
Este terceiro modo do PIM é baseado no Sparse Mode. A principal diferença esta no
método de envio de dados do emissor para o RP Router. No modo Bidir os dados são
enviados para o RP router por uma shared tree cujos ramos são bidireccionais – existem
fluxos de dados em ambas as direcções, em qualquer ramo. Não há necessidade de
encapsulamento dos pacotes e as regras de reencaminhamento são bastante mais
simples.
A grande vantagem em relação ao SM, é que o BM escala muito bem quando existem
muitas fontes para o mesmo grupo. No entanto, pode dar-se que o tráfego seja forçado
a seguir uma shared tree ineficiente, pelo facto do BM não seguir o conceito de source-
based trees.

PIM Source-specific multicast (SSM)
É um método de distribuir pacotes multicast onde os únicos pacotes que são entregues
ao destino são os originados pela fonte especificada pelo receptor. Dessa forma, este
método proporciona uma redução a nível do tráfego na rede e ganhos a nível de
segurança.
No entanto, como este método necessita de explicitar o IP da fonte sobre a qual
pretende receber tráfego, só funciona usando o protocolo IGMPv3 em IPv4 ou o MLDv2
em IPv6.

Rendezvous Point

Um router que actue como Rendezvous Point (RP), é utilizado como um meio de comunicação
temporário para ligar um terminal que pretenda tornar-se membro de um grupo multicast, à
árvore “source-specific” já existente, conhecida pelo RP. Assim que o volume de tráfego atinja
um threshold, o terminal passa a fazer parte de uma outra árvore, não dependente do RP.
Este RP pode ser configurado de três formas diferentes:

 manual, em cada um dos routers ligados ao RP;
 auto-RP, existe um processo de selecção dinâmica do RP;
 Bootstrap Router, apenas em routers com PIM versão 2 por haver problemas de
compatibilidade com a versão 1;
 Anycast RP, possibilita o uso de dois ou mais RP routers e ainda o uso de backup RP
routers;
 Embedded RP, permite embeber o endereço do RP router num grupo multicast any-
source multicast.

2.3.3 Distance Vector Multicast Routing Protocol (DVMRP)

O Distance Vector Multicast Routing Protocol (DVMRP) – RFC 1075 - é outro dos protocolos de
routing multicast, que permite a partilha de informação entre routers, para facilitar o
transporte de pacotes multicast através de redes.
A informação para o reencaminhamento de pacotes é calculada com base no protocolo RIP: o
router gera a sua tabela de routing com os grupos multicast que este tem conhecimento e
respectiva distância. Quando um pacote multicast é recebido, é reencaminhado pelas suas
interfaces de acordo com a informação contida nessas tabelas.

11

A grande diferença entre o RIP e este protocolo é que enquanto o primeiro se preocupa em
fazer chegar os pacotes até o seu destino específico, o DVMRP preocupa-se em reter
informação dos caminhos de retorno para a origem dos datagramas multicast.
O DVMRP utiliza mensagens IGMP na troca de informação com outros routers.

2.3.4 Multicast Open Shortest Path First (MOSPF)

O MOSPF é uma extensão multicast do protocolo de roteamento IP, Open Shortest Path First
(OSPF). Protocolo este, baseado no estado das ligações, ao contrario do RIP que baseia-se na
contagem dos nós.
O MOSPF transmite os datagramas IP multicast da origem para os vários membros do grupo
sem formar ligações, gerando uma árvore. Esta árvore tem como raiz o nó da origem do
datagrama, e todos os “ramos” terminam em membros do grupo. Este esquema de
roteamento, onde o caminho dos datagramas depende da origem e dos destinos é
denominado source/destination routing. Ele é diferente da maioria dos algoritmos unicast,
incluído o OSPF, que se baseiam somente no destino do datagrama ao fazer o roteamento. A
necessidade de considerar a origem para tomar decisões de roteamento causa maior
quantidade de cálculos, porém resulta em melhores caminhos em termos de utilização da rede
e atraso para membros individuais do grupo.
Neste protocolo, os datagramas são marcados com a sua classificação do Type of Service(TOS).
O caminho do datagrama multicast no MOSPF pode assim variar consoante a classificação TOS
utilizada. No entanto, a classificação TOS no protocolo MOSPF é, como no OSPF, opcional.

12

3 INTRODUÇÃO AO LABORATÓRIO

No nosso trabalho laboratorial pretendemos demonstrar algumas das características do IP
Multicast, nomeadamente o método de funcionamento de grupos Multicast.
Com esse intuito usou-se o SDR (Session Directory Tool) e o NTE (Network Text Editor).
Montou-se então uma rede que nos permitiu perceber os conceitos fundamentais do IP
Multicast, nomeadamente o protocolo IGMP, entre os computadores e os routers mais
próximos, e os protocolos de routing Multicast que permitem que os routers troquem
datagramas multicast entre si, como o caso do PIM.
Usou-se o Wireshark para capturar todas as mensagens trocadas na rede.

3.1 Software necessário
Actualmente, as principais aplicações multicast estão relacionadas com vídeo, áudio e texto
compartilhado. Antes que se possa realmente realizar uma conferência em qualquer destes
cenários, é necessário alocar, reservar e anunciar uma sessão multicast. Além disso, uma vez
anunciado o canal, cada terminal precisa aceder aos anúncios, podendo então entrar e sair de
um grupo. É aqui que entram as ferramentas de anúncio de sessão, como por exemplo o SDR
(Session Directory). Para a transmissão de dados propriamente dita é necessário associar a
esta ferramenta de anúncio de sessão, outras ferramentas que possibilitem que os respectivos
dados sejam enviados ao longo da rede.

3.1.1 SDR (Session Directory)
A ferramenta SDR permite que sejam reservados e alocados canais multicast de áudio, vídeo e
quadro branco (texto) para conferências e que se participe nos diversos grupos anunciados.

3.1.2 Ferramentas de documentos compartilhados e edição de texto
Com estas ferramentas, é possível compartilhar, entre os membros da sessão, documentos em
tempo real, efectuando anotações sobres estes a qualquer momento. São especialmente úteis
em transmissões de conferências, onde é possível utilizar a ferramenta como um
“retroprojector virtual”, onde uma apresentação para o público local também pode ser
apresentada para membros virtuais. Entre as ferramentas principais deste tipo temos o
WhiteBoard(WB) e o Shared Mosaic.
Para a edição de texto mais simples, temos por exemplo a ferramenta Network Text Editor
(NTE). Esta ferramenta permite abrir uma sessão de “chat”, onde qualquer pessoa nessa
sessão pode editar ou apagar texto.

3.1.3 Ferramentas de vídeo e áudio
As ferramentas de vídeo não necessitam de nenhum equipamento adicional além do próprio
terminal para receber o vídeo. Utilizam uma série de algoritmos de compressão de vídeo.
Entre as ferramentas mais utilizadas estão a Net Vídeo (NV), Vic (VideoConference) e INRIA
Videoconferencing System (IVS).
Entre as ferramentas de áudio mais utilizadas em multicast estão o Visual Audio Tool (VAT), o
Network Voice Terminal (Nevot) e o INRIA Videoconferencing System (IVS). Estas ferramentas
utilizam diversos padrões de compressão de áudio, tais como o Pulse Code Modulation (PCM),
13

o Adaptative Differential Pulse Code Modulation (ADPCM), Group Special Mobile (GSM) e
Linear Predictive Coding (LPC).

3.2 Topologia de rede

Ilustração 7: Topologia da rede idealizada para o trabalho prático.

Material utilizado:

 4 Routers Cisco 2500 (2503)
 3 Terminais com:
o Session Directory Tool (SDR) 3.0
o Network Text Editor (NTE) 2.3
o Wireshark 1.0.5
o minicom

3.3 Método usado

Os terminais foram configurados com endereços estáticos seguindo a topologia de rede
demonstrada na Ilustração 7 e funcionaram como emissores e receptores de um grupo IP
Multicast.

Vamos agora analisar ao pormenor alguns aspectos da configuração dos routers (ver em
Anexos), justificando as nossas opções:

Os routers foram configurados com RIP como protocolo de encaminhamento e com PIM
sparse-dense-mode como protocolo de encaminhamento de datagramas multicast.
14

ip subnet-zero
Esta configuração permite usar endereços que contenham o algarismo zero.

ip multicast-routing
Permite aos routers fazerem reencaminhamento de pacotes Multicast entre os nós da
rede.

ip classless
Com esta configuração o router consegue reencaminhar os pacotes multicast para as
supernets.

ip http server
Este comando activa o HTTP 1.1 server, incluindo o user interface em ambiente web.

no keepalive
Esta configuração foi necessária de forma a evitar mensagens de Loop reply entre os
routers.

router rip
Utilizou-se o RIP em detrimento do OSPF, uma vez que este último (apesar de mais
usado actualmente em IGP) é mais direccionado para redes de grandes dimensões. Por
esse facto, achamos mais conveniente usar o protocolo RIP por estar mais vocacionado
para redes locais.

ip pim sparse-dense-mode
Utilizou-se o protocolo PIM (Protocol Independent Multicast) porque não é
dependente de nenhum protocolo Unicast em particular para descobrir a topologia da
rede e utilizou-se o modo específico deste protocolo “sparse-dense-mode”. Este modo
de operação do PIM permite que este opere tanto em “sparse-mode” como em
“dense-mode”, dependendo das configurações que são dadas. No nosso caso prático,
os routers acabaram por funcionar em sparse-mode.

ip pim rp-address 10.10.1.1
Atribuiu-se um RP router estático que foi adicionado em todas as configurações. Dada
a finalidade da rede que idealizamos, acabou por ser a configuração mais conveniente.
A utilização de auto-RP, onde a atribuição dos RP é dinâmica, faria mais sentido numa
rede de grande dimensão e com alta imprevisibilidade.

As restantes configurações, dos routers e dos terminais, encontram-se em anexo.
Executou-se o programa SDR em todos os terminais, iniciando-se uma sessão Multicast num
deles.

15

4 LABORATÓRIO

Vamos então proceder ao trabalho prático de demonstração do funcionamento e capacidades
do IP Multicast.

Recapitulando, vamos dispor de três terminais (Terminal 1, Terminal2 e Terminal3) que vão
estar a ser utilizados por três utilizadores “virtuais” (user1, user2 e user3).

Temos então que o user1 decide organizar uma reunião com indivíduos que têm os mesmos
interesses, utilizando as valências do IP Multicast. Decide então criar uma sessão Multicast
para anunciar a esses interessados que vai decorrer uma reunião, no tradicional modo de
“chat” de texto, daí a algumas horas.

O user1 executa então o SDR e inicia a tal sessão, onde vai ser criado o grupo Multicast
referenciado pelo respectivo IP de classe D. Este grupo vai ser então referenciado com o IP
239.255.136.156

Ilustração 8: Terminal1 inicia a sessão multicast.

16

Ilustração 9: Captura do pacote SAP/SDP, no Wireshark, quando o Terminal1 inicia a sessão multicast.

Ilustração 10: O pacote IGMP do Terminal1 para o Router1, a comunicar que existe uma sessão
Multicast nesse terminal

17

O user1 fica assim a espera que mais interessados se juntem ao chat para iniciar a reunião.

Ilustração 11: O Terminal1 (já conectado a sessão multicast) começa a enviar pacotes relativos a
comunicação, para o grupo Multicast.

Router1#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
224.0.1.40 Ethernet0 00:03:28 00:02:53 192.168.10.1
Tabela 2: As tabelas de IGMP do Router1, antes da criação e join ao grupo Multicast.

239.255.136.156 Ethernet0 00:04:58 00:02:30 192.168.10.2
239.255.255.255 Ethernet0 00:14:55 00:02:24 192.168.10.2
224.1.127.255 Ethernet0 00:14:55 00:02:26 192.168.10.2
224.2.127.254 Ethernet0 00:14:55 00:02:29 192.168.10.2
224.0.1.75 Ethernet0 00:14:55 00:02:27 192.168.10.2
224.0.1.40 Ethernet0 00:25:56 00:02:24 192.168.10.1
Tabela 3: As tabelas de IGMP do Router1, após a criação e join ao grupo Multicast.

Nota: como se pode reparar o Router1 juntou-se não só ao IP do grupo Multicast que o user1
criou, como também a uma serie de outros IP Multicast. Esses outros IP Multicast, são
endereços especiais reservados, que possibilitam o normal funcionamento do Multicast.
Vamos mais a frente voltar a falar nesses endereços.

18

RPRouter#show ip mroute summary
IP Multicast Routing Table
Flags: 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,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.136.156), 00:11:02/00:03:23, RP 10.10.1.1, OIF count: 1, flags: S
(192.168.10.2, 239.255.136.156), 00:11:01/00:02:08, OIF count: 0, flags: PT





(*, 224.0.1.40), 01:23:43/00:00:00, RP 10.10.1.1, OIF count: 2, flags: SJCL
Tabela 4: No Router RP, após o user1 se ter juntado ao grupo Multicast. Como se vê a informação foi
passada do Router1 para o RP Router.

Router2#show ip mroute summary



Tabela 5: Tanto o Router2 como o Router3 desconhecem esses grupos Multicast, por enquanto.

19

O user2, que por acaso até tinha o SDR aberto, detecta que existe uma sessão multicast
disponível e adiciona-se a mesma.

Ilustração 12: O user2 recebe o SAP/SDP announcement da sessão criada pelo user1.

Ilustração 13: Captura do pacote IGMP, no Wireshark, quando o terminal2 adiciona-se ao grupo
multicast criado pelo user1, no terminal1.

20

239.255.136.156 Ethernet0 00:04:50 00:02:26 192.168.20.2
239.255.255.255 Ethernet0 00:10:46 00:02:26 192.168.20.2
224.1.127.255 Ethernet0 00:10:46 00:02:25 192.168.20.2
224.2.127.254 Ethernet0 00:10:46 00:02:27 192.168.20.2
224.0.1.75 Ethernet0 00:10:46 00:02:32 192.168.20.2
224.0.1.40 Ethernet0 01:28:54 00:02:32 192.168.20.1
Tabela 6: No Router2 podemos ver as tabelas IGMP nos quais mantêm-se controlo dos grupos aos
quais o user2 pertence.

Ilustração 14: Captura, no Wireshark, dos pacotes UDP correspondentes as trocas de mensagens entre
os users.

21


(*, 239.255.136.156), 00:04:30/00:02:59, RP 10.10.1.1, OIF count: 1, flags: SJCF
(192.168.10.2, 239.255.136.156), 00:04:29/00:02:58, OIF count: 1, flags: CJT
(192.168.20.2, 239.255.136.156), 00:04:30/00:03:29, OIF count: 1, flags: CFT

(*, 239.255.255.255), 00:10:27/00:02:59, RP 10.10.1.1, OIF count: 1, flags: SJC
(192.168.10.2, 239.255.255.255), 00:01:24/00:01:35, OIF count: 1, flags: CJT





Tabela 7: No Router2, onde se comprova que após o join do user2 o Router2 já incluiu na sua tabela os
participantes da sessão Multicast.

O user3, um grande interessado no tema da reunião, decide também juntar-se ao grupo.

Ilustração 15: Ao ligar o SDR o user3 faz join a um conjunto de grupos IP Multicast especiais (tal como
tínhamos já visto na Tabela 3)

22

Esses IP Multicast adicionais são reservados para serviços especiais (ver Tabela abaixo).

IPv4 Multicast Addresses Endereços Descrição
Capturados
Local Network 224.0.0.0-224.0.0.255 224.0.0.1 Todos os sistemas presentes
Control na sub-rede
Block 224.0.0.2 Todos os routers presentes na
sub-rede
Internetwork 224.0.1.0-224.0.1.255 224.0.1.40 cisco-rp-discovery
Control 224.0.1.75 Session Initiation Protocol
Block (SIP)
Spanning Tree 224.1.0.0- 224.1.127.255 Spanning Tree Multicast
Multicast 224.1.255.255 Groups
Groups
SDP/SAP 224.2.0.0- 224.2.127.255 SAPv0 Announcements
Block 224.2.255.255

Administratively 239.0.0.0- 239.255.136.156 IP do nosso grupo Multicast
Scoped 239.255.255.255

Tabela 8: Enunciamos alguns dos endereços Classe D correspondentes a grupos Multicast especiais,
que foram capturados na nossa rede.

Assim temos já reunidos os três users na nossa sessão Multicast.

Ilustração 16: Imagem do NTE com os três users a trocar mensagens

23

No entanto, o user3 acaba por ter de sair mais cedo da reunião e desactiva a ligação a sessão
Multicast.

Ilustração 17: Captura, no Wireshark, do pacote IGMP que prova a saída do terminal3 do grupo
Multicast.

Nota: Este pacote é destinado ao IP 224.0.0.2, que corresponde a contactar todos os routers
multicast na sub-rede do router de origem.

24

Ilustração 18: Mais uma vez, ao desligar o SDR, o user3 desliga-se também de todos os grupos
Multicast especiais.

RPRouter#show ip mroute summary


(192.168.10.2, 239.255.255.255), 00:00:10/00:02:49, OIF count: 0, flags: PX




Tabela 9: Prune do Router3 da tabela Multicast do RP Router.
25

É visível na tabela de routing Multicast do RP Router, que a entrada para a sub-rede
192.168.30.0/24, foi apagada da lista correspondente ao grupo Multicast da nossa sessão. Isso
prova que o Router3 acabou de ser pruned, não participando mais como router multicast, visto
o único Terminal, potencialmente interessado na sessão, já ter transmitido a mensagem IGMP
leave_group.

4.1 Outros pacotes capturados na rede
Uma série de outros tipos de pacotes foram capturados durante o nosso trabalho prático.
Interessa pois analisar as suas características mais em pormenor.

Ilustração 19: Mensagem de PIM Hello

Este PIM Hello tem como finalidade informar os restantes routers multicast, que o emissor do
pacote é também router multicast. É uma forma dos routers que funcionam em PIM, se darem
a conhecer uns aos outros.

Nota: Este pacote é destinado ao endereço Multicast especial 224.0.0.13, endereço de
controlo da rede local responsável pelo PIM.

26

Ilustração 20: Mensagem de CDP protocol

O Cisco Discovery Protocol (abreviado CDP) é um protocolo proprietário da camada de ligação
desenvolvido pela Cisco Systems que tem como principal função a descoberta de
equipamentos na rede, facilitando a compreensão da topologia da rede e de sua arquitectura.

Nota: No caso de termos interfaces a comunicar com redes remotas desconhecidas, deve-se
desactivar este género de pacotes. O facto de estes pacotes serem encaminhados para redes
externas, pode potencialmente comprometer a segurança da nossa rede local, pelo facto de
fornecermos informações relevantes a terceiros. No entanto, não foi este o caso do nosso
ambiente de teste.

27

Ilustração 21: Mensagens de RIPv1 response.

Estas mensagens visam realizar periodicamente o update das tabelas de roteamento nos
routers.

Nota: Reparar que a métrica de alcance das diferentes sub-redes, coincidem exactamente com
a topologia imposta.

28

5 CONCLUSÃO

Fundamentalmente, o IP Multicast está a mudar a nossa forma de trabalhar, jogar, viver e
aprender, providenciando soluções inovadoras que são simples e seguras.
Esta tecnologia de conservação de largura de banda, reduz o tráfego e sobrecarga dos
servidores ao distribuir, simultaneamente, uma única stream de informação a várias centenas
de utilizadores.
As aplicações que mais tiram partido da tecnologia IP Multicast incluem: as de vídeo-
conferência, e-learning e distribuição de software, entre muitas outras.

Através do estudo pormenorizado do IP Multicast e da implementação desta tecnologia, numa
situação prática, conseguimos compreender em profundidade o protocolo e as suas valências.
Foram mostrados os aspectos fundamentais do IGMP (Membership query, Membership report
e Leave group) bem como do PIM (join/prune e PIM hello) e um dos seus modos de
funcionamento (Sparse mode).

29

6 BIBLIOGRAFIA

http://www.dcc.fc.up.pt/~mrodrigues/teaching/tar0809/ip%20broadcast%20and%20multicast
.pdf
http://www.networksorcery.com/enp/protocol/ip/multicast.htm
http://www.iana.org/assignments/multicast-addresses/
http://www.dataconnection.com/multicast/pimprotocol.htm
http://www.multicasttech.com/faq/
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/IP-Multi.html
http://en.wikipedia.org/wiki/Bellman-Ford_algorithm
http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm
http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-multicast/html/mcast-
overview12.html

30

7 ANEXOS

!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router1
!
ip subnet-zero
!
!
!
!
interface Ethernet0
ip address 192.168.10.1 255.255.255.0
no keepalive
no shutdown
!
interface Serial0
mtu 1100
ip address 10.10.2.1 255.255.255.0
clockrate 9600
no shutdown
!
interface Serial1
mtu 1100
ip address 10.10.1.2 255.255.255.0
no shutdown
!
interface BRI0
no ip address
shutdown
!
router rip
network 10.10.0.0
network 192.168.10.0
network 192.168.20.0
network 192.168.30.0
!
ip classless
ip http server
!
line con 0
exec-timeout 0 0

31

line aux 0
line vty 0 4
login
!
end
Figura: Configuração do Router1

!
version 12.2
!
hostname Router2
!
ip subnet-zero
!
!
!
!
interface Ethernet0
ip address 192.168.20.1 255.255.255.0
no keepalive
no shutdown
!
interface Serial0
mtu 1100
ip address 10.10.3.1 255.255.255.0
clockrate 9600
no shutdown
!
interface Serial1
mtu 1100
ip address 10.10.2.2 255.255.255.0
no shutdown
!
interface BRI0
no ip address
shutdown
!
router rip
network 10.10.0.0
network 192.168.10.0
network 192.168.20.0
network 192.168.30.0
!
ip classless
32

ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
!
end

!
version 12.2
!
hostname Router3
!
ip subnet-zero
!
!
!
!
interface Ethernet0
ip address 192.168.30.1 255.255.255.0
no keepalive
no shutdown
!
interface Serial0
mtu 1100
ip address 10.10.4.1 255.255.255.0
clockrate 9600
no shutdown
!
interface Serial1
mtu 1100
ip address 10.10.3.2 255.255.255.0
no shutdown
!
interface BRI0
no ip address
shutdown
!
router rip
network 10.10.0.0
33

network 192.168.10.0
network 192.168.20.0
network 192.168.30.0
!
ip classless
ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
!
end

!
version 12.2
!
hostname RPRouter
!
ip subnet-zero
!
!
!
!
interface Ethernet0
no ip address
shutdown
!
interface Serial0
mtu 1100
ip address 10.10.1.1 255.255.255.0
clockrate 9600
no shutdown
!
interface Serial1
mtu 1100
ip address 10.10.4.2 255.255.255.0
no shutdown
!
interface BRI0
no ip address
shutdown
34

!
router rip
network 10.10.0.0
network 192.168.10.0
network 192.168.20.0
network 192.168.30.0
!
ip classless
ip http server
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
!
end
Figura: Configuração do RP Router

35

Multicast on Cisco Network

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (10)

Semelhante a Multicast on Cisco Network

Semelhante a Multicast on Cisco Network (20)

Mais de home

Mais de home (6)

Último

Último (20)

Multicast on Cisco Network