«

»

fev 10 2009

[P&R] Multicast

Ontem, após muito tempo sem receber nenhum e-mail para a sessão de “Perguntas e Respostas”, recebi um do Diogo, interessado em conhecer mais sobre Multicast, uma vez que ele esta estudando para o CCNP e este assunto é parte intrínseca desta certificação. Bom, creio que o básico a grande maioria conhece: Multicast é uma mensagem que parte de um ponto, com destino à vários pontos, simultaneamente.

O que o diferencia do Broadcast é que suas mensagens são dirigidas apenas à um grupo restrito de destinatários, enquanto mensagens Broadcast atingem todos, indiscriminadamente.

Para não “reinventar a roda”, optei por transcrever, na íntegra, um excelente tutorial sobre Multicast preparado por Luciano Paschoal Gaspary, disponível em http://penta2.ufrgs.br/redes296/multicast/tutorial.html

Segue:

1. Introdução

Grande parte dos protocolos de rede de alto-nível (protocolos de transporte ISO ou TCP e UDP) provêm apenas um serviço de transmissão unicast, ou seja, um nodo de uma rede pode enviar dados para apenas outro nodo em uma rede distinta (serviço ponto-a-ponto). Se um nodo deseja enviar a mesma informação para vários destinatários usando o serviço de transporte unicast, ele deve proceder com um unicast replicado, enviando N cópias dos dados, sendo N o número de nodos destino.

Serviço Unicast
Figura 1.1 – Serviço unicast
 
Uma maneira mais otimizada de enviar dados de uma fonte para muitos destinos é fornecer um serviço de transporte multicast. Com ele, torna-se possível um nodo enviar dados a vários destinos fazendo apenas uma requisição ao serviço de transporte.
Serviço de Transporte Multicast 
Figura 1.2 – Serviço multicast

2. Benefícios

Muitos não acreditam na necessidade real de multicast. Se existem dados que devem ser enviados a vários pontos, poderia-se atingir este objetivo utilizando-se de uma sequëncia de transferências ponto-a-ponto. Esta crença é incorreta, uma vez que serviços baseados em multicast provêm uma diminuição de tráfego na rede, habilitam a descoberta de recursos, além de serem muito adequados em videoconferências.

3. IP Multicast

IP Multicast é a transmissão de um datagrama IP para um “grupo de hosts”, representado por um conjunto de zero ou mais hosts identificados por um único endereço IP de destino. Um datagrama deste tipo é entregue a todos os membros pertencentes a este grupo com a mesma confiabilidade “best-efforts” existente em datagramas IP unicast, ou seja, não há garantia que o datagrama chegue intacto a todos os membros do grupo destino ou que cheguem na mesma ordem em que foram enviados.

Características relativas à associação de hosts a grupos

  • A associação a um grupo é dinâmica; hosts podem participar ou abandoná-los a qualquer momento.

  • Não há restrição quanto ao posicionamento geográfico ou número de membros em um grupo de hosts.

  • Um host pode ser membro de um ou mais grupos ao mesmo tempo.

  • Um host não precisa ser membro de um grupo para enviar datagramas a ele.

Grupos

  • Um grupo de hosts pode ser permanente ou transiente. Um grupo permanente tem um IP bem conhecido. É o endereço e não a associação que é permanente; a qualquer momento um grupo permanente pode ter um número qualquer de membros, até mesmo zero.

  • Os endereços multicast que não são reservados para grupos permanentes estão disponíveis para atribuições dinâmicas para grupos transientes que existem somente enquanto houver hosts membros.

Roteamento na Internet

O roteamento de datagramas IP Multicast na Internet é manipulado por roteadores multicast que podem co-exisitir ou não com os gateways Internet. Um host transmite um datagrama IP multicast como um multicast na rede local, sendo que este alcança todos os membros vizinhos do grupo de host destino. Se o datagrama possui um time-to-live maior que 1, o roteador multicast associado a esta rede tem a responsabilidade de repassar este datagrama a todas as outras redes que possuam membros deste grupo destino. Nas redes alcançáveis (TTL), o roteador multicast a elas associado completa a entrega transmitindo o datagrama como um multicast local aos membros do grupo.

Serão apresentadas a seguir as extensões requeridas para uma implementação de um host IP que suporte IP multicast, onde “host” é qualquer máquina na Internet ou gateway que não sejam os roteadores multicast.

3.1 Níveis de Conformidade

Nível 0: sem suporte para IP Multicast

Não existe a necessidade que todas as implementações IP suportem multicast. Hosts neste nível, em geral, não serão afetados pela atividade multicast. A unica exceção ocorre em alguns tipos de rede local, onde a presença de hosts níveis 1 ou 2 pode causar erros de entrega de datagramas IP Multicast para hosts do nível 0. Estes datagramas, no entanto, podem ser facilmente identificados pela presença de um endereço classe D no campo de endereço destino; estes devem ser descartados por hosts que não suportem IP Multicast.

Nível 1: suporte para o envio mas não recebimento de datagramas IP Multicast

Permite a um host participar de alguns serviços baseados em Multicast, como locação de recursos mas não o permite participar de nenhum grupo de host.

Nível 2: suporte completo a IP Multicast

Parmite a um host participar ou abandonar grupos de hosts, além de permitir o envio de datagramas a estes grupos. Requer, no entanto, a implementação de um protocolo de gerência de grupos (IGMP – Internet Group Management Protocol), bem como a extensão do IP e das interfaces de serviço de rede local acopladas aos hosts.

A implementação destes níveis é baseada na necessidade de adaptação de diversos módulos, conforme pode ser visto na figura 3.1 abaixo.

Nïveis Estuturais IP Passíveis de Modificação
Figura 3.1 – Níveis estruturais passíveis de modificação no suporte a multicast

3.2 Endereços de Grupo

Grupos de hosts são identificados pelos endereços IP classe D ( possuem “1110” associados aos quatro bits de mais alta ordem, vide figura 3.2).

Formato do Endereço de Grupo
Figura 3.2 – Formato do endereço de grupo

Na notação padrão Internet, endereços de grupam variam de 224.0.0.0 a 239.255.555.555. O endereço 224.0.0.0 não pode ser atrubuído a nenhum grupo, e 224.0.0.1 á atribuído ao grupo permanente de todos os hosts IP (incluindo gateways). É usado para endereçar todos os hosts multicast na rede diretamente conectada. Não há endereço multicast para todos os hosts de toda a Internet. O endereço de outros grupos permanentes bem conhecidos são publicados em  “Assigned Numbers”.

3.3 Envio de Datagramas IP Multicast

Extensões à Interface de Serviço IP

Datagramas IP Multicast são enviados usando a mesma operação de envio de datagramas IP Unicast; um módulo de protocolo de nível superior especifica unicamente um endereço de grupo como destino, ao invés de um endereço IP individual. Contudo, um conjunto de extensões são necessárias:

  • a interface de serviço deve prover uma maneira dos protocolos de níveis superiores especificarem o parâmetro time-to-live de um datagrama multicast que esteja sendo enviado. Se o nível superior não especifica este parâmetro, é utilizado o valor default 1 para todos os datagramas IP Multicast, de modo que uma escolha explícita é necessária para propagar o multicast além de sua rede.

  • Para hosts que possam estar associados a mais de uma rede, o serviço de interface deve prover uma maneira para que os níveis superiores possam identificar que interface de rede será utilizada para realizar a transmissão multicast. Apenas uma interface é utilizada para a transmissão inicial; roteadores multicast são responsáveis por repassarem estes datagramas para qualquer outra rede, se necessário. Se nenhuma interface é indicada pelo nível superior, deve-se eleger uma default.

  • Se o host que está enviando um datagrama é ele próprio membro do grupo destino na interface de saída, uma cópia do datagrama deve ser “looped-back” para entrega local, a menos que tenha sido inibida pelo nível superior.

Extensões ao Módulo IP

Para suportar o envio de datagramas IP Multicast, o módulo IP deve ser extendido para reconhecer endereços de grupo quando roteando datagramas de saída. Grande parte das implementações incluem a seguinte lógica:

se IP-destino está na mesma rede local,
envia datagrama localmente para IP-destino

senão

envia datagrama localmente para o Gateway (IP-destino)

Para suportar transmissões multicast, a lógica de roteamento deve ser mudada para

se IP-destino está na mesma rede local ou IP-destino é um grupo de host,
envia datagrama localmente para IP-destino

senão

envia datagrama localmente para o Gateway (IP-destino)

O endereço IP fonte do datagrama que está saindo deve ser um dos endereços individuais correspondentes à interface de saída. Um endereço multicast nunca deve ser colocado no campo de endereço fonte de um datagrama IP que esteja sendo enviado.

Extensões à Interface de Serviço da Rede Local

Nenhuma mudança na interface de serviço da rede local é necessária para enviar datagramas IP Multicast. O módulo IP apenas especifica um endereço destino de grupo, e não um endereço individual, quando invoca a operação existente  “Send Local”.

Extensões a um Módulo de Rede Local Ethernet

O Ethernet suporta diretmanete o envio de pacotes multicast locais permitindo endereços multicast no campo destino dos pacotes Ethernet. Tudo o que é necessário para suportar o envio de datagramas IP Multicast é um procedimento para mapear endereços de grupo para endereços Ethernet Multicast.

Um endereço IP de grupo é mapeado para um endereço Ethernet Multicast atribuindo os 23 bits de baixa-ordem do endereço IP para os 23 bits de baixa-ordem do endereço Ethernet Multicast 01-00-5E-00-00-00. Pelo fato de haver 28 bits significativos em um endereço IP Multicast, mais que um endereço de grupo pode ser mapeado para o mesmo endereço Ethernet Multicast.

Extensões para Módulos de Rede Locais que não sejam Ethernet

Outras redes que suportam diretamente o multicast, como os anéis ou barramentos conforme o padrão IEEE 802.2, podem ser manipulados da mesma maneira que o Ethernet para fins de envio de datagramas IP Multicast. Para redes que suportem broadcast mas não Multicast, como a Ethernet experimental, todos os endereços de grupo de host devem ser mapeados para um único endereço de broadcast local. Para um link ponto-a-ponto unindo dois hosts (ou um host e um roteador multicast), multicasts devem ser transmitidos exatamente como unicast. Para redes do tipo store-and-forward (como a ARPANET ou uma rede pública X.25), todos os endereços de grupo devem ser mapeados para um endereço local conhecido de um roteador IP Multicast; um roteador numa rede deste tipo é responsável por completar a entrega multicast dentro da rede e entre as redes.

3.4 Recebimento de Datagramas IP Multicast

Extensões à Interface de Serviço IP

Datagramas IP Multicast que chegam são recebidos pelos protocolos de níveis superiores usando a mesma operação “Receive IP”, como se fossem datagramas unicast. Seleção de um protocolo de nível superior destino é baseado no campo protocolo no cabeçalho do IP, independente do endereço IP destino. Contudo, antes que quaisquer datagramas destinados a um grupo particular sejam recebidos, um protocolo de nível superior deve pedir ao módulo IP para participar do grupo. Deste modo, a interface de serviço IP deve ser estendida para oferecer duas novas operações:

    JoinHostGroup (endereço-grupo, interface) e
    LeaveHostGroup(endereço-grupo, interface)

A operação JoinHostGroup faz uma requisição solicitando que o host torne-se membro do grupo de host identificado pelo “endereço-grupo” em uma determinada interface de rede. O argumento interface pode ser omitido em hosts que suportem apenas uma interface. Para hosts associados a mais de uma rede, o protocolo de nível superior pode não especificar a interface; neste caso, a requisição será atendida através de uma interface default para enviar datagramas multicast.

É possível participar do mesmo grupo em mais de uma interface, sendo que neste caso datagramas multicast duplicados podem ser recebidos. Também é possível que mais de um protocolo de nível superior faça a requisição para participar de um mesmo grupo.

Ambas as operações devem retornar imediatamente por serem não-bloqueantes, indicando sucesso ou falha. A operação pode falhar devido a endereços de grupo ou interfaces inválidas. JoinHostGroup pode falhar ainda pela falta de recursos locais. LeaveHostGroup pode falhar se o host não pertencer ao grupo determinado. Esta operação pode retornar com sucesso, mas a associação pode continuar existindo se mais de um protocolo superior tiver requisitado participação no mesmo grupo.

Extensões ao Módulo IP

Para suportar a recepção de datagramas IP Multicast, o módulo IP deve ser estendido para manter uma lista de participantes de grupos de host associados a cada interface de rede. Quando um datagrama é recebido, destinado a um deste grupos, é realizado exatamente da mesma maneira como datagramas destinados a um endereço individual de host.

Pacotes que estejam chegando destinados a grupos aos quais o host não pertença são descartados sem gerar nenhuma informação de erro ou log. Em hosts com mais de uma interface de rede, se um datagrama chega via uma dada interface, destinada a um grupo para o qual o host pertence em outra interface, o datagrama é também descartado.

Um datagrama não é rejeitado por ter um time-to-live de 1 ( isto é, o time-to-live não é automaticamente decrementado em datagramas que chegam e que não sejam reenviados ). Um datagrama que chegue com um endereço de grupo em seu campo endereço fonte é descartado. Um mensagem de erro ICMP (destino inalcançavel, tempo excedido, problema com parâmetros) nunca é gerada em resposta a um datagrama destinado a um grupo de host.

A lista de participantes de grupos são atualizadas sempre que as primitivas JoinHostGroup e LeaveHostGroup são requisitadas por níveis superiores. Cada associação deve ter um contador de referência ou mecanismo similar para manipular várias requisições de join e leave para o mesmo grupo. Na primeira requisição de join e na última requisição de leave em uma determinada interface, o módulo de rede local daquela interface é notificado, de modo que ele possa atualizar seus filtros de recepção multicast.

Extensões à Interface de Serviço de Rede Local

Pacotes multicast que chegam a rede local são entregues ao módulo IP utilizando a mesma operação “Receive Local” como pacotes unicast da rede local. Para permitir o módulo IP informar ao módulo de rede local que pacotes multicast aceitar, a interface de serviço de rede local é estendida com a finalidade de incrementar duas novas operações:

    JoinLocalGroup (endereço-grupo) e
    LeaveLocalGroup (endereço-grupo)

onde endereço-grupo é o endereço de grupo de host. A operação JoinLocalGroup requisita ao módulo de rede local que aceite e entregue os pacotes subsequentes destinados a um dado endereço de grupo. A operação LeaveLocalGroup requisita ao módulo de rede local que pare de entregar pacotes destinados a um dado endereço de grupo de host. O módulo de rede local deve mapear os endereços IP Multicast para endereços de rede local como é requerido para atualizar seus filtros de recepção multicast. Qualquer módulo de rede local é livre para ignorar requisições LeaveLocalGroup, e pode entregar pacote destinados a mais endereços que apenas aqueles especificados nas requisições JoinLocalGroup, se ele é incapaz de filtrar pacotes.

O módulo de rede local não deve entregar a ele mesmo pacotes multicast que tenha sido transmitido por ele próprio. Loopback de multicast é manipulado no nível IP ou superior.

Extensões ao Módulo de Rede Local Ethernet

Para suportar a recepção de datagramas IP Multicast, um módulo Ethernet deve ser capaz de receber pacotes destinados a endereços Ethernet Multicast que correspondam a endereços de grupo. É altamente desejável aproveitar as capacidades de filtragem, de modo que o host receba apenas pacotes destinados a ele.

Infelizmente, muitas interfaces Ethernet possuem um limite pequeno de número de endereços que o hardware é capaz de reconhecer. Deste modo, uma implementação deve ser capaz de “escutar”um número de endereços multicast arbitrário, que pode significar  “abertura” dos filtros de endereço para aceitar todos os pacotes multicast durante estes períodos quando o número de endereços excede o limite do filtro.

4. IGMP

O protocolo de gerenciamento de grupo (IGMP – Internet Group Management Protocol) é usado por hosts para reportar seus participantes de grupos de hosts a roteadores multicast vizinhos. É um protocolo assimétrico e é especificado aqui do ponto de vista de um host, ao invés do de um roteador multicast.

Como o ICMP, IGMP é uma parte integral do IP. É um requisito básico de implementações a todos os hosts que desejem enviar e receber pacotes multicast. As mensagens IGMP são encapsuladas em datagramas IP, com um número de protocolo IP igual a 2. Todas as mensagens importantes do ponto de vista do host possuem o seguinte formato:

Formato da mensagem IGMP
Figura 4.1 – Formato das mensagens de protocolo IGMP

  • Versão: este tutorial especifica a versão 1 do IGMP. A versão 0 é especificada na RFC-988 e está obsoleta.

  • Tipo: há dois tipos de mensagens que devem ser levadas em consideração:

1- Host Membership Query
2- Host MemberShip Report

  • Não-Usado: campo não utilizado, zerado quando enviado e ignorado quando recebido.

  • Checksum

  • Endereço de grupo: em uma mensagem Host Membership Query, o campo de endereço de grupo é zerado quando enviado e ignorado quando recebido. Por outro lado, em uma mensagem Host Membership Report, este campo contém o endereço de grupo do grupo sendo reportado.

4.1 Descrição Informal do Protocolo

Roteadores multicast enviam mensagens Host Membership Query para decobrir que grupos de hosts têm membros nas suas rede locais associadas. As requisições são endereçadas a todos os grupos de host (endereço 224.0.0.1) e carregam um time-to-live igual a 1.

Os hosts, por sua vez, respondem à consulta gerando Host MemberShip Reports, reportando cada grupo de host para o qual ele pertence na interface de rede a partir da qual a consulta foi recebida. Co o objetivo de evitar uma explosão de reports concorrentes e reduzir o número de reports transmitidos, duas técnicas são usadas:

  • Quando um host recebe uma consulta, ao invés de enviar os reports imediatamente, ele inicia um temporizador de atraso para cada um dos participantes dos grupos na interface de rede que recebeu a consulta. A cada temporizador é atribuído um tempo randomicamente escolhido entre 0 e um valor D. Quando o temporizador expira, um report é gerado para o membro do grupo de host correspondente. Assim, reports são espalhados em um intervalo de D segundos e não ocorrerão todos da mesma vez.

  • Um reporte é enviado com um endereço de IP destino igual ao endereço de grupo de host sendo reportado, e com o time-to-live igual a 1. Se um host escuta um report a um grupo ao qual pertence, ele pode parar seu temporizador para aquele grupo e não gera report para ele. Assim, no caso normal, apenas um report será gerado para cada grupo presente na rede, pelo membro do grupo cujo atraso seja o menor. Conclui-se daí que os roteadores multicast recebem todos os datagramas IP Multicast e, portanto, não precisam ser endereçados explicitamente. Além disto, note-se que os roteadores não precisam saber quais os host pertencem a um grupo, apenas que pelo menos um host pertence a um grupo em uma rede particular.

Roteadores multicast fazem consultas peridocamente para atualizar suas tabelas de grupos presentes em um rede particular. Se nenhum report é recebido de um grupo particular após um certo número de consultas, os roteadores assumem que aquele grupo particular não possuem mais membros e eles não precisa mais redirecionar pacotes multicast originados remotamente para aquele grupo naquela rede específica. As consultas são feitas com um intervalo razoável ( em tono de 1 minuto) a fim de não sobrecarregar a rede.

Quando um host passa a participar de um grupo ele deve transmitir imediatamente um report para aquele grupo, ao invés de esperar pelo consulta feita pelos roteadores, no caso de ele ser o primeiro membro daquele grupo na rede. Para cobrir a possibilidade do report inicial ser perdido ou danificado, é recomendável que este seja repetido uma ou duaz vezes após intervalos curtos.

4.2 Diagrama de Transição de Estados

O comportamento IGMP é mais formalmente especificado pelo diagrama de transição de estados abaixo. Um host pode estar em um dos três estados possíveis, para cada grupo de host IP em qualquer interface de rede (Vide Figura 4.2 abaixo) :

Diagrama de Transição de Estados do Protocolo IGMP
Figura 4.2 – Diagrama de transição de estados do protocolo IGMP

  • Estado Non-Member – quando o host não pertence ao grupo na interface. Este é o estado inicial para todos os grupos em todas as interfaces de rede; não requer armazenamento no host.

  • Estado Delaying Member – quando o host pertence ao grupo na interface e tem um temporizador de report executando para aquela associação.

  • Estado Idle Member – Quando um host pertence ao grupo na interface e não possui um temporizador executando para aquela associação.

Há cinco eventos significativos que podem causar transições de estado:

  • “join group” ocorre quando o host decide participar do grupo na interface. Pode ocorrer apenas no estado Non-Member.

  • “leave group” ocorre quando um host decide abandonar um grupo na interface. Pode acontecer apenas nos estados Delaying Member e Idle Member.

  • “query received” ocorre quando um host recebe uma mensagem Host Membership Query. Para ser válida, esta mensagem de ter pelo menos 8 octetos, ter um checksum correto e um endereço IP destino de 224.0.0.1. Uma simples consulta se aplica a todos os grupos na interface que recebe a solicitação. É ignorada para grupos nos estados Non-Member ou Delaying Member.

  • “report receive” ocorre quando o host recebe uma mensagem Host Membership Report. Para ser válida, esta de ter pelo menos 8 octetos, ter um checksum correto, e conter o mesmo endereço IP de grupo no seu campo de destino e no campo de endereço de grupo IGMP. Um report se aplica apenas para os participantes no grupo identificado pelo report, na interface onde este é recebido. É ignorado para grupos no estado Non-member ou Idle Member.

  • “timer expired” ocorre quando o temporizador de atraso para o grupo na interface expira. Só pode ocorrer no estado Delaying Member.

Há três ações possíveis que podem ser dadas em resposta aos eventos acima:

  •  “send report” para o grupo na interface.

  • “start timer” para o grupo na interface, usando uma atraso randômico entre 0 e D segundos.

  •  “stop timer” para o grupo na interface.

5. Roteamento

Como já foi visto anteriormente, a realização de multicast depende de gerenciamento de grupo. Foram mostradas maneiras de se criar e destruir grupos, além dos mecanismos que permitem os processos participar e abandonar os mesmos. Estes mecanismos não importam muito aos algoritmos de roteamento. O que realmente importa é que quando um processo passa a participar de um grupo ele informa a seu host sobre este fato. É importante que os roteadores saibam quais de seus hosts pertencem a quais grupos. Tanto os hosts podem informá-lo sobre eventuais mudanças, como podem ser consultados pelo mesmo periodicamente. Roteadores avisam a seus vizinhos, de modo que a informação se propaga pela sub-rede.

Para realizar multicast, cada roteador calcula uma spanning tree cobrindo todos os outros roteadores na sub-rede. Por exemplo, na figura 5.1 abaixo tem-se uma sub-rede com dois grupos (1 e 2). Alguns roteadores estão associados a hosts que pertençam a um ou ambos os grupos, conforme indicado na figura. A spanning tree do roteador mais a esquerda pode ser também visualizada na seqüencia em amarelo

Rede Hipotética e Construção das Spanning Trees
Figura 5.1 – Exemplo de construção da spanning tree

Quando um processo envia um pacote multicast a um grupo, o primerio roteador examina sua spanning tree e a poda, removendo todas as linhas que não levam a hosts que sejam membros do grupo. Na figura acima, pode-se visualizar a árvore resultante para o grupo 1 (em vermelho) e para o grupo 2 (em azul). Pacotes multicast são repassados apenas pelas s spanning trees apropriadas.

Outras técnicas de corte das spanning trees podem ser utilizadas. O algoritmo de roteamento vetor distância, por exemplo, utiliza-se do algoritmo básico reverse path forwarding.

Um alternativa diferente utiliza-se de core-base trees. Neste caso, uma única spanning tree por grupo é computada, com a raiz perto do meio do grupo(core). Para enviar uma mensagem multicast, o host deve enviá-la ao core que então faz o repasse do pacote pela spanning tree.

Bibliografia

Huitema, Christian. Routing in the Internet. Englewood Cliffs, NJ. Prentice Hall, 1995.

Deering, Steve. RFC 1112 – Host Extensions for IP Multicasting. Stanford University, 1989.

Tanenbaum, Andrew. Computer Networks. Upeer Sadle River, NJ. Prentice Hall, 1996.



Comente usando o Facebook!
0
0

17 comentários

Pular para o formulário de comentário

  1. Alexander Willians

    Excelente o material Marco!

    Tks!

    0

    0
  2. juniorrossetto

    Parabéns Marco, excelente material …

    abraços

    0

    0
  3. Varela

    Bahh..

    Sério, fazia muito tempo que eu procurava algo sobre multicast e só achava resumos ou traduções horríveis …

    Mando bem Marco.

    Abraços

    0

    0
  4. Carlos Almeida

    Caramba!!!

    Estava procurando algo sobre o assunto para me aprofundar mais. Este material, certamente, será a base dos meus estudos no que se refere a multicast.

    Valeu mesmo Marco!!! Mandou ver!!

    Abraço!

    0

    0
  5. Eron Melo

    É incrível como algo(pra mim) tão complexo parece ser mais fácil!!!!!! Parabéns!!!!!!!

    0

    0
  6. Henrique de Almeida Ribeiro

    Parabéns, Marco são artigos iguais a este que mantém sempre elevada a qualidade desse conceituado blog, uma forma simples, didática e direta de explicar um assunto que alguns o tornam complexo.

    0

    0
  7. Fabio Pauluci

    Marco, muito legal o material. To na classe do Diogo..hehe Vai ser de grande ajuda entender esse assunto.
    valeu!!!

    0

    0
  8. A. Carvalho

    Excelente material de estudo.

    Muito bacana o artigo e realmente bem objetivo, parabéns Marco.

    Abraços!

    0

    0
  9. Diogo Mendes

    Opa Marco, obrigado pela força! Me surpreendi com a rapidez da resposta! =D

    Multicast está sendo um assunto mais dificil de fixar do que eu imaginava, vou ter q ler, reler, fazer laboratorios…

    Com o passar do tempo mando mais sugestões!

    Abraços!

    0

    0
  10. Rodrigo Farias

    Nossa, veio na hora certa. Estou estudando Multicast e estava precisando de uma revisao dessas 🙂

    Excelente tuto! 🙂

    0

    0
  11. Israel Carlos

    Opa, sensacional Marco, tb estou pro CCNP e estava justamente na parte de Multicast.

    abs

    0

    0
  12. Alexandre Bormio

    Boa Marco!!!
    Otimo post!
    Abs.

    0

    0
  13. daviccna

    Marco,

    Excelente material….tb estou estudando multicast e vai ser de grande ajuda…
    Eu tenho acesso a uma rede de um cliente que tem multicast e vou tentar mostrar como é na prática no Cisco.(meu 1. Post…)
    Ainda não sei tudo desta rede, vou precisar da sua ajuda com alguns comandos…mas vou tentar (se o tempo deixar tb). Acho que a melhor maneira de vc aprender é tentando explicar o que sabe….vc não acha???

    Abraços.

    0

    0
  14. Cledir Justo

    Muito bom!
    estou exatamente no capitulo de Multicast do BSCI, vai ser de grande ajuda!
    Apesar de não ser o foco do blog, espero que futuramente seja postado mais assuntos de CCNP.
    abraçoss

    0

    0
  15. L.C.F.N

    Explicado detalhadamente, mas ainda sim aparenta ser um assunto complexo.

    0

    0
  16. Tiago Frigério

    Bom dia…

    Otimo tutorial… vou comecar os estudos para o CCNP e sera de grande valia esse post.

    Abracos…

    0

    0
  17. Fernando Avelino

    Valeu Marco, ótimo tutorial

    0

    0

Deixe uma resposta