Estou me preparando para a minha segunda prova do CCNP Wireless: 642-742 IUWVN. Ainda não vi o conteúdo das outras duas provas, mas arrisco dizer que essa é a mais difícil.
Dois assuntos presentes nessa etapa estão na minha pauta para conhecer mais profundamente faz algum tempo: Multicast e QoS. Desta forma, estou realizando um estudo mais profundo desses dois assuntos. Inciando por Multicast, vou escrever um artigo extenso sobre o assunto. Além da parte teórica, vou apresentar um LAB que configurei com stream de áudio e vídeo real passando por uma rede OSPF e sob a adminstração de uma das modalidades de Multicast, a mais comum, também chamada de Sparse Mode.
Multicast é parecido com Broadcast, porém,menos limitado.Broadcast é enviado para todos os hosts dentro de um domínio de broadcast. Em Layer 2 um endereço de broadcast segue o padrão FF:FF:FF:FF:FF:FF. Já em Layer 3 o endereço é 255.255.255.255.
Não há muito mais para dizer sobre Broadcast. Ele é usado por muitas aplicações conhecidas como o DHCP.
Multicast é um pouco mais elaborado. Ele também possui um endereçamento específico tanto para Layer 2 quanto para Layer 3, porém, obedece algumas regras. Multicast também possui comportamentos diferenciados, dependendo do ambiente. Ele pode se comportar tanto para One-to-Many,Many-to-many e Many-to-One. Entretando, assim como Broadast, Multicast não é roteável e precisa que os devices sejam preparados para tal.
O orgão responsável pela distribuição dos endereçamentos reservou a faixa que vai de 224.0.0.1 até 239.255.255.255, sendo que existem subdivisões. Por exemplo, os range de 224.0.0.1/24 (224.0.0.1 até 224.0.0.254) é reservado aos protocolos de roteamento. De 224.0.1.0 até 238.255.255.255 são usado globalmente. Enquanto que o range de 239.0.0.0 ate 239.255.255.255 são usado em redes locais.Por exemplo, os endereços 239.0.1.39 e 239.0.1.40 são usados dentro de uma rede Multicast para fins que veremos a seguir.
Para fins didáticos, vamos organizar os endereçamentos da seguinte forma:
224.0.0.1 - 239.255.255.255 - Range reservados para Multicast em geral
224.0.0.1 - 224.0.0.254 - Protocolo de Roteamento
224.0.1.0 - 238.255.255.255- Endereços Globais
239.0.0.0 - 239.255.255.255.Enderelis Loais
A nível de layer 2, existe um padrão que advêm da relação com o layer 3. Como o range reservado pela IANA é de 224.x.x.x, os 4 primeiros dígitos são fixos: 1110. Desta forma, esses digitos terão sempre essa configuração.
Os últimos 23 dígitos são usados para compor o endereço layer 2. Logo, 5 dígitos não serão mapeados. Esse mapeamento resulta que um endereço layer 2 pode ser mapeado para vários endereços Layer 3, até 32 mais especificamente.
Por exemplo, os endereços 224.130.0.1, 225.130.0.1, 226.130.0.1 são mapeados para o mesmo endereço 01-00-5e-02-00-01.
Isso é o suficiente em termos de endereçamento de Multicast. Existe um outro protocolo que é usado pelo Multicast para que os hosts se juntem a um grupo multicast. O IGMP (Internet Group Management Protocol). IGMP possui 3 versões a saber:
IGMP v1: Router envia queries a cada 60 segundos para todos os routers através do endereço 224.0.0.1 (All hosts). Os hosts, por sua vez, respondem a essas queries no endereço 224.0.0.2 informando quais os grupos ou qual o grupo eles pretendem associar.
Não existe solicitação para deixar o grupo, é usado timeout após 180 segundos caso o hosts não responda.
Na sua versão 2, o processo se torna um pouco mais inteligente. Agora os hosts podem tomar a iniciativa. Por sua vez, os routers pode responder ao host ao inves de responder para o endereço 224.0.0.2.
Não é dificil de perceber que na versão 2 temos uma utilização muito mais otimizada do link e uma convergência muito mais rápida dos elementos que compõe o multicast.
IGMP version 3 adiciona a capacidade do host indicar de qual origem ele quer receber informação e os endereço "All Hosts" passa de 224.0.0.2 para 224.0.0.22.
Existe um problema em se tratar multicast a nível de switches. A razão é simples. Os Switches são originalmente dispositivos de Layer 2 e como tal analisa apenass endereços MAC dos quadros. Ele observa o quadro quando sai por uma porta e associa o MAC address àquela porta. Ora, Multicast usa um MAC address "virtual" que pode estar associado a vários outros endereços de Layer 3. Desta forma, o método convencional usado pelo Switch não funciona.
Devido a esse problema, foi desenvolvido pela Cisco o CGMP e, posteriormente o IGMP para ser aplicado aos demais vendors. O IGMP passou a ser padrão, inclusive para Cisco.
Ao habilitar o IGMP o Switch passa a analisar a camada 7 de um pacote. Assim ele passa a ter conciência das transações de Multicast.
O título do artigo faz mensão a PIM-Sparse mode. Porém, até agora falamos de Multicast sem mencionar nada além disso. Mas o Multicast existem em duas formas: Dense Mode e Sparse Mode.
Dense mode é um método mais simplificado e consequentemente menos eficiente de implementação do Multicast. Ele opera muito parecido com o seu parente Broadcast enviando um query para dos os segmentos da rede. A cada 3 minutos a rede é inundada com queries enviadas pelos routers e uma mensagem de resposta chamada de prune retornada pelos hosts que não fazem parte de nenhum grupo. Com essas mensagens é montada a rede Multicast Dense mode.
Assim como o IGMP v1, Dense mode não prioriza economia no consumo de banda. Outro método de Multicast, mais inteligente, foi proposto: Sparse Mode.
Multicast Sparse Mode funciona,de certa forma, um pouco parecido com o protocolo de roteamento OSPF. Assim como o OSPF elege um Router Designado, Sparse Mode elege um Router com um nome estranho chamado Rendezvous (Em ingles se pronuncia "rondevú"). Uma das definições em ingles para o termo Rendezvous é "A meeting at a prearranged time and place". Traduzindo, "Um encontro em um horário e lugar pré determinado". Mas a palavra nitidamente vem do Francês e significa "Encontro".
Os significados são precisos em relação a função desse Router. Quando um hosts quer se comunicar com um grupo de Multicast ele envia, através de IGMP, uma requisição para seu gateway. O Gateway,por sua vez, direciona essa requisição para o Rendezvous Point, passaremos a chamar de RD. Ao receber essa requisição, o RD encaminha uma resposta para o Router e Host que fez a solicitação, indicando como alcançar o grupo solicitado. O caminho inicialmente passará pelo RD mas será adaptado assim que o fluxo for estabelecido. Veremos isso na prática em nosso LAB.
Para realizar essas validações de origem e destino, routers usam um protocolo chamado de PIM ou Protocol Independent Multicast.
O envio de pacote em unicast é realizado com base no endereço de destino mas o envio de Multicast é feito baseado no endereço de origem. O PIM, em conjunto com o RFP (Reverse Path Forwarding), tem como objetivo evitar loops de roteamento. Caso seja verificado que um pacote entrou por uma interface e está tentando voltar por outra interface, o RFP irá dropar o pacote para evitar loops.
PIM não é exclusivo de Sparse Mode, ele atua também em Dense Mode. Inclusive, a Cisco disponibiliza o comando ip pim { dense-mode | sparse-mode | sparse-dense-mode }, fazendo que o Router consiga funcionar dos dois modos.
Para iniciar sua rede Multicast é preciso que o protocolo seja habilitado em todos os Routers que farão parte da rede através do comando ip multicast-routing. Após habilitar o Multicast, será preciso definir qual o papel de cada Router na rede.
Além do Rendezvous Point, temos outro Router com papel específico chamado Mapping Agent. Como é possível existir diferentes RP em uma rede responsáveis por diferentes grupos Multicast, a função dos Mapping Agents é 'mapear' os RP através de enúncios Groupo-To-RP. Desta forma, os routers possuem uma orientação de para quem solicitar quando precisar se associar a um grupo.
Mapping Agents usam o IP 224.0.1.39 e enviam Group-To-RP para o endereço 224.0.1.40.
Bem, após essa parte teórica sobre Multicast, vamos para uma parte prática. Abaixo apresento a topologia criada no GNS3:
Essa LAB foi feito baseado no LAB presente no Blog
Multicasting with GNS3 and Virtualbox. No LAB apresentado no referido Blog, a origem do Stream foi gerado em um Ubuntu, no meu caso estou usando Wimdows XP para ambos com o VLC para gerar e abrir o Stream. A princípio funcionou perfeirtamente.
Ainda por recomendação do Blog foi usado roteadores 7200 e foi mantido os endereçamentos da núvem de roteadores. Apenas as bordas estão diferentes. No meu caso também é possível ver um servidor de monitoração em baixo a direita. Isso faz parte de um outro LAB que estou fazendo em paralelo para testar uma solução que estou emplementando em um cliente com software ClearView da RedLine. Talvez no futuro eu apresente algo aqui.
A rede é composta de 6 roteadores com OSPF divulgando todas as rede,inclusive Loopback.
!
interface Loopback1
ip address 1.1.X.1 255.255.255.255
ip pim sparse-mode
!
Todos os Routers possuem essa configuração de Loopback, sendo que o terceiro octeto é o número do roteador.
Também é preciso configurar OSPF em todos os Routers:
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
Basta que sejam executados esses comandos em todos os Routers.
Os endereçamentos das interfaces está exposto na topologia. Não preocupei em criar uma outra. O importante em se dizer aqui é que TODOS os Routers precisam ter o comando :
Outra configuração necessária é habilitar em todas as interfaces o seguinte comando:
Além dessas configurações comuns a todos os Routers, é preciso definir o Rendezvous Point e o Mapping Agent. Isso é feito com os seguintes comandos respectivamente:
!
ip pim send-rp-announce lo1 scope 15
!
e
!
ip pim send-rp-discovery lo1 scope 15
!
Como Multicast obedece a mesma regra do Broadcast e não é roteador automaticamente, um último comando é necessário em todos os Routers
!
!
Após realizar todas essas configurações, valide sua rede. Efetue ping de todos lugar para todo lugar. Conexão de rede precisa estar 100%.
Uma dificuldade que algumas pessoas podem encontrar é em como integrar as máquinas virtuais com o GNS3.
Se você também usa Virtualbox, isso é possível fazer diretamente através dessa future presente no GNS3:
Uma dica aqui. Caso você click em VM list e a lista apareça vazia, impossibilitando o mapeamento da VM, basta clicar em "Refresh VM List" que todas as VM instaladas no Virtualbox irão aparecer. Escolha áquelas que serão usadas e click em "Save".
Após isso, vá para o Dashboard do Virtualbox e adicione-as como qualquer outro host.
Ocorre as vezes dessa integração,por vezes prática, não funcionar como o esperado. Uma outra forma de faz isso é através de núvem mapeando para a interface de rede do Virtualbox. Seria como integrar com Loopback do próprio Windows.
A configuração da interface de rede das VMs não tem nenhum segredo:
Uma vez validada a conectividade do LAB e adicionado as VMs, basta ligar os XPs e instalar o software VLC em cada uma.
A frente vou mostrar as configurações em cada um.
Acima temos a configuração do Server. É preciso mapear na máquina o arquivo que queremos reproduzir no Client.
Veja que na parte inferior escolhemos a opção "Fluxo".
A próxima Janela apenas mostra a url da fonte do arquivo, no caso nossa máquina. Basta clicar em "Próximo".
Essa janela também precisa apenas de um "Próximo".
Clicando em "Próximo", podemos configurar o IP para onde será enviado o fluxo e a porta.
Na janela acima, temos uma configuração que lhe salvará de passar, como eu passei, dois dias fazendo troubleshooting no seu LAB. Na verdade eu não posso exatamente reclamar porque eu consegui aprender muito mais. Eu li 'n' materiais sobre troubleshooting e aprendi muitos comandos tentando descobrir porque o fluxo não chegava ao meu Client passando pela minha rede Multicast.
No fim, descobri que precisa do parâmetro acima indicado pela seta vermelha. Essa parâmetro não vem e é necessário. Após isso, basta clicar em "Fluxo" e pronto, teremos a janela abaixo.
E por último, temos nosso client apresentando o vídeo.
O sentido do fluxo é apresentado abaixo. Inicialmente, o fluxo passará pelo "ponto de encontro", Rendzvous e irá sentido Client. A topologia foi criada intensionalmente para que o tráfego se adapte ao ambiente assim que o protocolo PIM validar a topologia e garantir através do RFP que não há risco de loop. Logo o tráfego se adaptará à rede usando o percurso de melhor performance para a rede. Isso poderá ser observado através do Wireshark:
A princípio não haveria nenhuma razão para que o fluxo passasse no ponto indicado na topologia. Em uma situação convencional, o fluxo passaria por R3 diretamente. Vamos colocar outro ponto de captura abaixo de R1,onde o fluxo passaria em uma situação normal.
Se observarmos em um segundo ponto:
Vamos observar que já houve uma convergência na rede e o fluxo passa inteiramente pelo menor percurso. Para que haja essa mudança no tráfego, O RP envia pacotes de Register-Stop como abaixo:
Após isso, vamos o fluxo passando pelo caminho mais curto de forma contínua:
Assim encerramos esse artigo. Multicast é um assunto muito interessante e muito importante. Acredito que esse artigo é profundo o suficiente para que alguém que esteja iniciando com o assunto possa ter uma boa idéia de como esse protocolo funciona. A forma que é apresentado a parte prática é muito interessante por mostrar uma situação real de transmissão de vídeo. Os testes com icmp são possíveis mas não mostram a complexidade do protocolo. É possível afirmar que se adicionarmos mais um Client na rede, ele poderá receber o mesmo fluxo. Porém, o mais importante de se dizr é que o fluxo não precisar vir do Server. O gateway é capaz de duplicar o fluxo e envia-lo para mais de um destino possibilitando uma enorme economia de banda e possibilitando um serviço de muito melhor qualidade.
