MULTICAST de próxima geração - GRE MDT padrão (AD BGP - PIM C: Perfil 3)
Contents
Introduction
Este documento descreve o GRE (BGP AD - PIM C) da árvore de distribuição multicast padrão (MDT - Multicast Distribution Tree) para Multicast sobre VPN (mVPN). Ele usa um exemplo e a implementação no Cisco IOS para ilustrar o comportamento.
O que é MDT padrão?
É usado para conectar multicast a todo PE em um VRF. Padrão significa que ele conecta todos os roteadores PE. Por padrão, ele transporta todo o tráfego. Todo o tráfego de controle do PIM e o tráfego do plano de dados. Exemplo: (*,G) Tráfego e tráfego (S,G). O padrão é o obrigatório. Esse MDT padrão conecta todo o roteador PE para se conectar. Isso representa multiponto para multiponto. Qualquer um pode enviar e todos podem receber da árvore.
O que é MDT de dados?
É opcional e é criado sob demanda. Ele transporta tráfego específico (S,G). Na versão mais recente do IOS, você tem o limite configurado como 0 e infinito. Sempre que um primeiro pacote atinge o VRF, o MDT de dados é inicializado e, se infinito, o MDT de dados nunca é criado, e o tráfego avança no MDT padrão. O MDT de dados é sempre a árvore de recebimento, eles nunca enviam nenhum tráfego. O MDT de dados é apenas para o tráfego (S,G).
O limite no qual o MDT de dados é criado pode ser configurado por roteador ou por VRF. Quando a transmissão multicast excede o limite definido, o roteador PE de envio cria o MDT de dados e envia uma mensagem UDP (User Datagram Protocol), que contém informações sobre o MDT de dados para todos os roteadores no MDT padrão. As estatísticas para determinar se um fluxo multicast excedeu o limite de MDT de dados são examinadas uma vez a cada segundo.
Os MDTs de dados são criados somente para entradas de rota multicast (S, G) na tabela de roteamento multicast VRF. Não são criados para entradas (*, G) independentemente do valor da taxa de dados da fonte individual
- Permite que o PE se associe diretamente a uma árvore de origem para um MDT.
- Nenhum ponto de encontro é necessário na rede.
- Os RPs são um ponto de falha potencial e sobrecargas adicionais.
- Mas permitem árvores compartilhadas e BiDir (menos estado).
- Reduza o atraso de encaminhamento.
- Evite a sobrecarga de gerenciamento para administrar o mapeamento de grupo/RP e RPs redundantes para garantir a confiabilidade.
- A troca é mais necessária.
- (S, G) para cada mVPN em um PE.
Se houver 5 PEs cada um segurando mVRF RED, há 5 x (S, G) entradas.
- Configure o comando ip pim ssm range nos roteadores P e PE (evita entradas desnecessárias (*, G) sendo criadas).
- SSM recomendado para Data-MDTs.
- Use o BiDir, se possível, para MDT padrão (o suporte a BiDir é específico da plataforma).
Se o SSM não for usado para configurar MDTs de dados:
- Cada VRF precisa ser configurado com um conjunto exclusivo de endereços P multicast; dois VRFs no mesmo MD não podem ser configurados com o mesmo conjunto de endereços.
- Muitos mais endereços IP multicast são necessários.
- Operações e gerenciamento complicados.
- O SSM exige que o PE participe de um (S, G) não (*, G).
G é conhecido como configurado, mas PE não sabe diretamente o valor de S (S, G) do MDT padrão propagado por MP-BGP.
A vantagem do SSM é que ele não depende do uso de um RP para derivar o roteador PE de origem para um grupo MDT específico.
O endereço IP do PE de origem e do grupo MDT padrão é enviado via Border Gateway Protocol (BGP)
Há duas maneiras pelas quais o BGP pode enviar essas informações:
- Comunidade estendida
- solução proprietária da Cisco
- Atributo não transitório (não adequado para inter-AS)
- MDT SAFI da família de endereços BGP (66)
- draft-nalawade-idr-mdt-safi
BGP
- PE de origem e Grupo padrão MDT codificado em NLRI de MP_REACH_NLRI.
- RD é igual ao do MVRF para o qual o Grupo Padrão MDT está configurado.
- O tipo de RD é 0 ou 1
O atributo PMSI transporta o endereço de origem e o endereço do grupo. Para formar o túnel MT.
Endereçamento multicast para o grupo SSM
232.0.0.0 - 232.255.255.255 foi reservado para aplicativos Multicast específicos de origem global.
239.0.0.0 - 239.255.255.255 é o intervalo de espaço de endereço multicast IPv4 com escopo administrativo
Escopo local da organização IPv4 - 239.192.0.0/14
O âmbito local é o âmbito mínimo envolvente e, por conseguinte, não é mais divisível.
Os intervalos 239.0.0.0/10, 239.64.0.0/10 e 239.128.0.0/10 não estão atribuídos e estão disponíveis para expansão deste espaço.
Esses intervalos devem ser deixados sem atribuição até que o espaço 239.192.0.0/14 não seja mais suficiente.
Recomendações
- O padrão-MDT deve desenhar endereços do espaço 239/8 começando com o intervalo definido com o escopo local da organização 239.192.0.0/14
- O Data-MDT deve desenhar endereços do Escopo Local Organizacional.
- Também é possível usar o intervalo global do SSM 232.0.0.0 - 232.255.255.255
- Como o SSM sempre usa um estado exclusivo (S, G), não há possibilidade de sobreposição, pois o fluxo multicast do SSM será iniciado por fontes diferentes (com endereços diferentes), estejam eles na rede do provedor ou na Internet maior.
- Use o mesmo pool de Data-MDT para cada mVRF em um domínio multicast específico (onde o Default-MDT é comum).
Por exemplo, todos os VRFs que usam Default-MDT 239.192.10.1 devem usar o mesmo intervalo de Dados MDT 239.232.1.0/24
Sinalização de sobreposição
A sinalização de sobreposição do GRE Rosen é mostrada na imagem.
Topologia
A topologia do Rosen GRE é mostrada na imagem.
Roteamento e encaminhamento de VPN multicast e domínios multicast
O MVPN apresenta informações de roteamento multicast para a tabela de roteamento e encaminhamento de VPN. Quando um roteador Provider Edge (PE) recebe dados de multicast ou pacotes de controle de um roteador Customer Edge (CE), o encaminhamento é realizado de acordo com as informações na instância Multicast VPN Routing and Forwarding (MVRF). O MVPN não usa comutação de rótulo.
Um conjunto de MVRFs que podem enviar tráfego multicast entre si constitui um domínio multicast. Por exemplo, o domínio multicast de um cliente que queria enviar certos tipos de tráfego multicast para todos os funcionários globais consistiria em todos os roteadores CE associados a essa empresa.
Tarefas de configuração
- Ative o roteamento multicast em todos os nós.
- Ative o modo sobressalente PIM (Protocol Independent Multicast) em toda a interface.
- Com o VRF existente, configure o MDT padrão.
- Configure o VRF na interface Ethernet0/x.
- Ative o roteamento multicast em VRF.
- Configure PIM SSM Default em todos os nós dentro do núcleo.
- Configure a família de endereços BGP MVPN.
- Configure o RP BSR no nó CE.
- Pré-configurado:
VRF SSM-BGP mBGP: Address family VPNv4 VRF Routing Protocol
Verificar
Tarefa 1: Verifique a conectividade física.
Verifique se toda a interface conectada está UP.
Tarefa 2: Verifique o unicast da família de endereços BGP VPNv4.
- Verifique se o BGP está ativado em todos os roteadores para unicast AF VPNv4 e os vizinhos BGP estão UP.
- Verifique se a tabela unicast do BGP VPNv4 tem todos os prefixos do cliente.
Tarefa 3: Verifique o unicast da família de endereços BGP.
- Verifique se o BGP está ativado em todos os roteadores para o MVPN IPV4 AF e os vizinhos BGP estão UP.
- Verifique se todos os PE se descobrem, com rota tipo 1.
Tarefa 4: Verifique o tráfego multicast de ponta a ponta.
- Verifique a vizinhança do PIM.
- Verifique se o estado multicast é criado no VRF.
- Verifique a entrada mRIB em PE1, PE2 e PE3.
- Verifique se a entrada (S, G) mFIB, pacote sendo incrementado no encaminhamento de software.
- Verifique se os pacotes ICMP estão chegando de CE a CE.
Como as interfaces de túnel são criadas?
Criação de túnel MDT
Depois de configurarmos o mdt padrão 239.232.0.0
O túnel 0 foi ativado e atribuiu seu endereço de loopback 0 como origem.
%LINEPROTO-5-UPDOWN: Protocolo de linha no túnel de interface0, estado alterado para ativado
PIM(1): Check DR after interface: Tunnel0 came up! PIM(1): Changing DR for Tunnel0, from 0.0.0.0 to 1.1.1.1 (this system) %PIM-5-DRCHG: VRF SSM-BGP: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel0
Esta imagem mostra a Criação de Túnel MDT.
PE1#sh int tunnel 0 Tunnel0 is up, line protocol is up Hardware is Tunnel Interface is unnumbered. Using address of Loopback0 (1.1.1.1) MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 1.1.1.1 (Loopback0) Tunnel Subblocks: src-track: Tunnel0 source tracking subblock associated with Loopback0 Set of tunnels with source Loopback0, 1 member (includes iterators), on interface <OK> Tunnel protocol/transport multi-GRE/IP Key disabled, sequencing disabled Checksumming of packets disabled
Assim que o BGP MVPN fica ATIVADO, todo o PE se descobre através da rota Tipo 1. Túnel multicast formado. O BGP transporta todos os endereços de grupo e origem do PE no atributo PMSI.
Esta imagem mostra o Exchange da rota Tipo 1.
Esta imagem mostra PCAP-1.
PE1#sh ip mroute 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, E - Extranet, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, (3.3.3.3, 239.232.0.0), 00:01:41/00:01:18, flags: sTIZ Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2 Outgoing interface list: MVRF SSM-BGP, Forward/Sparse, 00:01:41/00:01:18 (2.2.2.2, 239.232.0.0), 00:01:41/00:01:18, flags: sTIZ Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2 Outgoing interface list: MVRF SSM-BGP, Forward/Sparse, 00:01:41/00:01:18 “Z” Multicast Tunnel formed after BGP mVPN comes up, as it advertises the Source PE and Group Address in PMSI attribute.
Vizinho PIM
PE1#sh ip pim vrf SSM-BGP neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 10.1.0.2 Ethernet0/2 00:58:18/00:01:31 v2 1 / DR S P G 3.3.3.3 Tunnel0 00:27:44/00:01:32 v2 1 / S P G 2.2.2.2 Tunnel0 00:27:44/00:01:34 v2 1 / S P G
Assim que você configurar as informações de RP:
%LINEPROTO-5-UPDOWN: Protocolo de linha no Túnel da Interface1, estado alterado para ativado
A troca de mensagens de bootstrap via túnel MDT
PIM(1): Received v2 Bootstrap on Tunnel0 from 2.2.2.2 PIM(1): pim_add_prm:: 224.0.0.0/240.0.0.0, rp=22.22.22.22, repl = 0, ver =2, is_neg =0, bidir = 0, crp = 0 PIM(1): Update prm_rp->bidir_mode = 0 vs bidir = 0 (224.0.0.0/4, RP:22.22.22.22), PIMv2 *May 18 10:28:42.764: PIM(1): Received RP-Reachable on Tunnel0 from 22.22.22.22
Esta imagem mostra a troca de mensagens de bootstrap via túnel MDT.
PE2#sh int tunnel 1 Tunnel1 is up, line protocol is up Hardware is Tunnel Description: Pim Register Tunnel (Encap) for RP 22.22.22.22 on VRF SSM-BGP Interface is unnumbered. Using address of Ethernet0/2 (10.2.0.1) MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 10.2.0.1 (Ethernet0/2), destination 22.22.22.22 Tunnel Subblocks: src-track: Tunnel1 source tracking subblock associated with Ethernet0/2 Set of tunnels with source Ethernet0/2, 1 member (includes iterators), on interface <OK> Tunnel protocol/transport PIM/IPv4 Tunnel TOS/Traffic Class 0xC0, Tunnel TTL 255 Tunnel transport MTU 1472 bytes Tunnel is transmit only
Dois túneis formaram o túnel PIM register e o túnel MDT.
- O túnel 0 é usado para enviar PIM Join e tráfego multicast de banda curta.
- O túnel 1 é usado para enviar a mensagem PIM encapsulated Register.
Comando para verificar :
**MDT BGP:
PE1#sh ip pim vrf m-SSM mdt bgp
** enviar FHR de dados:
PE1#sh ip pim vrf m-SSM mdt
Feedback