Sinalização MULTICAST in-band de próxima geração (VRF MLDP: Perfil 6)
Contents
Introduction
Este documento descreve o MLDP de VRF de Sinalização em Banda que é o Perfil 6 para Multicast de Próxima Geração sobre VPN (mVPN). Ele usa um exemplo e a implementação no Cisco IOS para ilustrar o comportamento.
Informações de Apoio
A sinalização dentro da banda do Protocolo de Distribuição de Rótulo Multicast (MLDP - Multicast Label Distribution Protocol) para permitir que o núcleo MLDP crie o estado (S,G) ou (*,G) sem usar a sinalização fora da banda, como o Border Gateway Protocol (BGP) ou o Protocol Independent Multicast (PIM - Protocol Independent Multicast).
A VPN multicast suportada por MLDP (MVPN) permite que fluxos multicast de VPN sejam agregados em uma árvore específica de VPN.
Nenhum estado do cliente é criado no núcleo MLDP. Há o único estado para árvores de distribuição multicast padrão e de dados (MDTs).
Em determinados cenários, o estado criado para fluxos VPN é limitado e não parece ser um fator de risco ou de limitação. Nesses cenários, o MLDP pode criar MDTs dentro da banda que são LSPs (Traços Comutados por Rótulo) em trânsito.
As árvores usadas em um espaço VPN são MDTs. As árvores usadas na tabela global são LSPs ponto-a-multiponto (P2MP) de trânsito ou multiponto-a-multiponto (MP2MP).
Em ambos os casos, um único fluxo multicast (VPN ou não) é associado a um único LSP no núcleo MPLS. As informações de fluxo são codificadas na FEC (Forwarding Equivalence Class) do LSP. Isto é sinalização dentro da banda.
O LSM oferece benefícios quando comparado aos túneis de núcleo do GRE que são usados atualmente para transportar o tráfego do cliente no núcleo e aproveita a infraestrutura MPLS para transportar pacotes multicast IP, fornecendo um plano de dados comum para unicast e multicast.
Sinalização MLDP
A sinalização MLDP fornece duas funções:
- Descobrir a FEC (e seu valor opaco associado) para um MP LSP
- Para atribuir um fluxo multicast a um MP LSP
Sinalização dentro da banda
- Valor opaco é usado para mapear um LSP MP para um fluxo de multicast IP.
- O conteúdo do valor opaco é derivado do fluxo multicast.
Sinalização de sobreposição ou fora da banda
- Usa um protocolo de sobreposição para mapear um LSP MP para um fluxo multicast IP.
- O valor opaco pode ser atribuído pelo PE raiz de entrada ou configurado estaticamente.
- O MP LSP é criado sob demanda ou pode ser pré-configurado.
- Permite agregar fluxos multicast em um único MP LSP.
Protocolo de Distribuição de Rótulo (LDP - Label Distribution Protocol) Tipo Classe de Equivalência de Curinga (FEC - Wildcard Forward Equivalence Class) # RFC5918
O Elemento FEC Curinga Tipo refere-se a todos os FECs do tipo especificado que atendem à restrição. Especifica um "Tipo de Elemento FEC" e uma restrição opcional, que se destina a fornecer informações adicionais.
O formato do Elemento FEC Curinga Tipo é:
Curinga digitada: Tipo de elemento FEC de um octeto (0x05).
O LDP [RFC5036] distribui etiquetas para classes de equivalência de encaminhamento (FECs). O LDP usa TLVs FEC em mensagens LDP para especificar FECs.
Um TLV FEC do LDP inclui um ou mais elementos FEC. Um elemento FEC inclui um tipo FEC e um valor opcional dependente do tipo.
O RFC 5036 especifica dois tipos de FEC (Prefixo e Curinga) e outros documentos especificam tipos de FEC adicionais; por exemplo, consulte [RFC447] e [MLDP].
Conforme especificado pelo RFC 5036, o Elemento FEC Curinga refere-se a todos os FECs relativos a uma restrição opcional.
A única restrição RFC 5036 especifica é aquela que limita o escopo do Elemento FEC Curinga a "todos os FECs vinculados a um determinado rótulo".
A especificação RFC 5036 do elemento FEC curinga tem estas deficiências que limitam sua utilidade:
- O Elemento FEC Curinga não foi digitado. Há situações em que seria útil se referir a todas as FECs de um determinado tipo (como outra restrição).
- O uso do Elemento FEC Curinga é limitado somente às mensagens de Retirada de Rótulo e Liberação de Rótulo. Há situações em que seria útil ter um Elemento FEC Curinga, com restrição de tipo, em mensagens de Solicitação de Rótulo.
Topologia
Sinalização de sobreposição
Configuração
Etapa 1. Habilite MLDP MPLS nos nós do núcleo.
# mpls mldp logging
Etapa 2. Habilitar SINALIZAÇÃO DE BANDA MLDP NO NÚCLEO.
Em PE1, PE2 e PE3
# ip multicast vrf INBAND-MLDP mldp
# ip pim vrf INBAND-MLDP mpls source loopback 0
Etapa 3. Ative o PIM SM em todas as interfaces CE e interface PE VRF.
Em CE1, CE2, CE3 e todas as interfaces VRF PE1, PE2 e PE3
# interface x/x
# ip pim sparse-mode
# interface loopback x/x
# ip pim sparse-mode
Etapa 4. Ative o multicast no VRF.
Em PE1, PE2 e PE3
# ip multicast-routing vrf INBAND-MLDP
Etapa 5. Ative o VRF na interface x/x PE-CE do roteador PE.
# interface x/x
# ip vrf forwarding INBAND-MLDP
Etapa 6. Configurar o modo SSM nos nós CE e PE (somente VRF).
Nos nós CE
# ip pim ssm default
Em PE1, PE2, PE3 em VRF
# ip pim vrf INBAND-MLDP ssm default
Passo 7. Configure o grupo IGMP SSM 232.1.1.1 (receptor).
No receptor 2 e 3
CE #interface x/x
# ip pim join-group 232.1.1.1 source 10.1.0.2
Verificar
IGP, MPLS LDP, BGP é executado normalmente em toda a rede.
Nesta seção, a verificação é feita para verificar a adjacência do VPN AF na rede de núcleo/agregação. A adjacência é verificada entre o CE-PE e o plano de controle também é verificado junto com o plano de dados para tráfego VPN na rede MPLS.
Para verificar se os dispositivos locais e remotos de borda do cliente (CE) podem se comunicar através do núcleo de Multiprotocol Label Switching (MPLS), execute estas tarefas:
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 tráfego multicast de ponta a ponta.
- Verifique a vizinhança PIM com o vizinho PIM conectado.
- Verifique se o estado multicast é criado no VRF.
Na entrada mRIB VRF PE em PE1, PE2 e PE3
- Verifique se a entrada VRF (S, G) mFIB, pacote sendo incrementado no encaminhamento de software.
- Verifique se os pacotes ICMP estão chegando de CE a CE.
Tarefa 4: Verifique o NÚCLEO MPLS.
- Verifique o núcleo MPLS LSP.
- Verifique o encaminhamento de MPLS dentro do núcleo conforme o projeto.
- Verifique se o ping MPLS P2MP LSP está funcionando.
Como construir um plano de controle?
Verifique se a imposição de rótulo ocorre quando o roteador PE encaminha com base no cabeçalho IP e adiciona um rótulo MPLS ao pacote ao entrar em uma rede MPLS.
Na direção da imposição de rótulo, o roteador comuta pacotes com base em uma pesquisa na tabela CEF para localizar o próximo salto e adiciona as informações de rótulo apropriadas armazenadas no FIB para o destino. Quando um roteador executa a troca de rótulo no núcleo de um pacote MPLS, o roteador realiza uma pesquisa na tabela MPLS. O roteador deriva essa tabela MPLS (LFIB) das informações na tabela CEF e na Base de Informações de Rótulo (LIB).
A disposição do rótulo ocorre quando o roteador PE recebe um pacote MPLS, toma uma decisão de encaminhamento com base no rótulo MPLS, remove o rótulo e envia um pacote IP. O roteador PE usa o LFIB para a determinação do caminho de um pacote nessa direção.Como dito anteriormente, uma sessão especial do iBGP facilita o anúncio de prefixos VPNv4 e seus rótulos entre roteadores PE. No PE de anúncio, o BGP aloca rótulos para os prefixos VPN aprendidos localmente e os instala no LFIB, que é a tabela de encaminhamento MPLS.
Etapa 1. Depois de configurar o MLDP no núcleo. Essas mensagens são trocadas.
MLDP: P2MP Wildcard label request sent to 11.11.11.11:0 success MLDP: MP2MP Wildcard label request sent to 11.11.11.11:0 success MLDP-MFI: Enabled MLDP MFI client on Lspvif0; status = ok LDP Peer 11.11.11.11:0 re-announced MLDP-NBR: 11.11.11.11:0 UP sess_hndl: 1, (old ID: 0.0.0.0:0) mLDP-RW: Sending RW notification message to process: mLDP Process mLDP-RW: RW Tracking started for: 11.11.11.11 MLDP-LDP: [id 0] Wildcard label request from: 11.11.11.11:0 label: 0 root: 6.2.0.0 Opaque_len: 0 sess_hndl: 0x1 MLDP-LDP: [id 0] Wildcard label request from: 11.11.11.11:0 label: 0 root: 8.2.0.0 Opaque_len: 0 sess_hndl: 0x1 Neighbor 11.11.11.11 request for the label request to PE1.
Use esta depuração para verificar o estabelecimento anterior:
# debug mpls mldp all
Etapa 2. Habilitar SINALIZAÇÃO DE BANDA NO VRF.
PE1 # Config t # ip pim vrf MLDP-INBAND mpls source loopback 0 # ip multicast vrf MLDP-INBAND mpls mldp MLDP: Enabled IPv4 on Lspvif0 unnumbered with Loopback0 MLDP-MFI: Enable lsd on int failed; not registered; MLDP: Enable pim on lsp vif: Lspvif0 MLDP: Add success lsp vif: Lspvif0 address: 0.0.0.0 application: MLDP vrf_id: 1 MLDP-DB: Replaying database events for opaque type value: 250 %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up PIM(1): Check DR after interface: Lspvif0 came up! PIM(1): Changing DR for Lspvif0, from 0.0.0.0 to 1.1.1.1 (this system) %PIM-5-DRCHG: VRF MLDP-INBAND: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Lspvif0 Use this Debug to check the preceding establishment # debug ip pim vrf LDP-INBAND6 PE1#sh interfaces lspvif 0 Lspvif0 is up, line protocol is up Hardware is Interface is unnumbered. Using address of Loopback0 (1.1.1.1) MTU 17940 bytes, BW 8000000 Kbit/sec, DLY 5000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation LOOPBACK, loopback not set
Quando o receptor estiver online:
O receptor 3 entra on-line e envia as mensagens PIM JOIN (S, G) para PE3.
PIM(1): Received v2 Join/Prune on Ethernet0/2 from 10.2.0.2, to us PIM(1): Join-list: (10.1.0.2/32, 232.1.1.1), S-bit set MRT(1): Create (*,232.1.1.1), RPF (unknown, 0.0.0.0, 2147483647/0) MLDP: Interface Lspvif1 moved from VRF (default) to VRF MLDP-INBAND MLDP: Enabled IPv4 on Lspvif1 unnumbered with Loopback0 MLDP-MFI: Enabled MLDP MFI client on Lspvif1; status = ok MRT(1): Add interface Lspvif1 MLDP: Enable pim on lsp vif: Lspvif1 MLDP: Add success lsp vif: Lspvif1 address: 1.1.1.1 application: MLDP vrf_id: 1 MLDP: LDP root 1.1.1.1 added mLDP-RW: Sending RW notification message to process: mLDP Process mLDP-RW: RW Tracking started for: 1.1.1.1 MLDP: Route watch started for 1.1.1.1 topology: base ipv4 MLDP-DB: Added [vpnv4 10.1.0.2 232.1.1.1 1:1] DB Entry MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Added P2MP branch for MRIBv4(1) label %MLDP-5-ADD_BRANCH: [vpnv4 10.1.0.2 232.1.1.1 1:1] Root: 1.1.1.1, Add P2MP branch MRIBv4(1) remote label MLDP: nhop 10.0.2.2 added MLDP-NBR: 11.11.11.11:0 mapped to next_hop: 10.0.2.2 MLDP: Root 1.1.1.1 old paths: 0 new paths: 1 MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Changing peer from none to 11.11.11.11:0 MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Add accepting element nbr: 11.11.11.11:0 MLDP: [vpnv4 10.1.0.2 232.1.1.1 1:1] label mappping msg sent to 11.11.11.11:0 success MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] path to peer: 11.11.11.11:0 changed None:0.0.0.0 to Ethernet0/3:10.0.2.2
Qualquer comunicação do Receiver (S,G) Join será convertida em MLDP e todas as mensagens serão passadas em direção ao Lspvif 1
Com PIM JOIN (S,G) como o MLDP é um protocolo orientado por receptor, ele começa a criar o banco de dados MLDP do Receptor para a Origem. Esta é a alocação de Rótulo de downstream para P2MP MLDP.
P2MP MLDP
O transporte de pacotes P2MP é implementado usando o Protocolo de Reserva de Recursos (RSVP - Resource Reservation Protocol) P2MP - Engenharia de Tráfego (P2MP-TE - Traffic Engineering) e o transporte de pacotes M2M são implementados através do VPN Multicast (MVPN - Multicast VPN) IPv4 usando o Protocolo de Distribuição de Rótulo Multicast (MLDP - Multicast Label Distribution Protocol).
O pacote é transportado por três tipos de roteadores:
Roteador central: Encapsula o pacote IP com um ou mais rótulos.
Midpoint Router: Substitui o rótulo interno por um rótulo externo.
Roteador Tailend: Remove o rótulo do pacote.
Fluxo de pacote na rede MVPN baseada em MLDP Para cada pacote que entra, o MPLS cria vários rótulos de saída. Os pacotes da rede de origem são replicados ao longo do caminho até a rede de receptor. O roteador CE1 envia o tráfego IP multicast nativo. O roteador PE1 impõe um rótulo no pacote multicast de entrada e replica o pacote rotulado em direção à rede central MPLS. Quando o pacote chega ao roteador central (P), ele é replicado com os rótulos apropriados para o MDT padrão MP2MP ou o MDT de dados P2MP e transportado para todos os PEs de saída. Quando o pacote chega ao PE de saída, o rótulo é removido e o pacote multicast IP é replicado na interface VRF
PE1#sh mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 1 Type: P2MP Uptime : 00:23:11 FEC Root : 1.1.1.1 (we are the root) Opaque decoded : [vpnv4 10.1.0.2 232.1.1.1 1:1] Opaque length : 16 bytes Opaque value : FA 0010 0A010002E80101010000000100000001 Upstream client(s) : None Expires : N/A Path Set ID : 1 Replication client(s): 11.11.11.11:0 Uptime : 00:23:11 Path Set ID : None Out label (D) : 21 Interface : Ethernet0/1* Local label (U): None Next Hop : 10.0.1.2 RR-P#sh mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 2 Type: P2MP Uptime : 00:28:12 FEC Root : 1.1.1.1 Opaque decoded : [vpnv4 10.1.0.2 232.1.1.1 1:1] Opaque length : 16 bytes Opaque value : FA 0010 0A010002E80101010000000100000001 Upstream client(s) : 1.1.1.1:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : Ethernet0/1* Local Label (D): 21 Next Hop : 10.0.1.1 Replication client(s): 3.3.3.3:0 Uptime : 00:28:12 Path Set ID : None Out label (D) : 26 Interface : Ethernet0/2* Local label (U): None Next Hop : 10.0.3.1 2.2.2.2:0 Uptime : 00:24:41 Path Set ID : None Out label (D) : 25 Interface : Ethernet0/3* Local label (U): None Next Hop : 10.0.2.1 RR-P#sh mpls forwarding-table labels 21 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 21 26 [vpnv4 10.1.0.2 232.1.1.1 1:1] \ 0 Et0/2 10.0.3.1 25 [vpnv4 10.1.0.2 232.1.1.1 1:1] \ 0 Et0/3 10.0.2.1
MRIB criado em dispositivos PE:
PE1#sh ip mroute vrf MLDP-INBAND 232.1.1.1 verbose IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, U - URD, I - Received Source Specific Host Report, (10.1.0.2, 232.1.1.1), 00:00:17/00:02:42, flags: sTI Incoming interface: Ethernet0/2, RPF nbr 10.1.0.2 Outgoing interface list: Lspvif0, LSM ID: 1, Forward/Sparse, 00:00:17/00:02:42
Quando a origem inicia o fluxo :
Quando a origem multicast começa a enviar tráfego, [10.1.0.2, 232.1.1.1] acontece como mostrado nesta imagem.
Tráfego da origem 10.1.0.2 em fluxo de 232.1.1.1. Entra pela ethernet0/2.
O pacote foi encaminhado via Lspvif 0.
PIM(0): Insert (10.1.0.2,232.1.1.1) join in nbr 10.1.0.2's queue PIM(0): Building Join/Prune packet for nbr 10.1.0.2 PIM(0): Adding v2 (10.1.0.2/32, 232.1.1.1), S-bit Join PIM(0): Send v2 join/prune to 10.1.0.2 (Ethernet0/2) MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Ethernet0/2 (FS) accepted for forwarding MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Ethernet0/2 (FS) sent on Lspvif0, LSM NBMA/4
Este pacote é encapsulado no Lspvif 0.
No lado do receptor:
No lado do receptor, o pacote alcança o Lspvif 1.
MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Lspvif1 (FS) accepted for forwarding MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Lspvif1 (FS) sent on Ethernet0/0 PIM(0): Received v2 Join/Prune on Ethernet0/0 from 10.3.0.2, to us PIM(0): Join-list: (10.1.0.2/32, 232.1.1.1), S-bit set PIM(0): Update Ethernet0/0/10.3.0.2 to (10.1.0.2, 232.1.1.1), Forward state, by PIM SG Join
Quando o pacote chega ao PE1, ele verifica o ID do LSM para encaminhar o tráfego, que rótulo deve impor no pacote Multicast.
Esta imagem mostra a verificação da interface LSPVIF.
Para cada pacote que entra, o MPLS cria vários rótulos de saída. Os pacotes da rede de origem são replicados ao longo do caminho até a rede de receptor. O roteador CE1 envia o tráfego IP multicast nativo. O roteador PE1 impõe um rótulo no pacote multicast de entrada e replica o pacote rotulado em direção à rede central MPLS.
Quando o pacote chega ao roteador central (P), ele é replicado com os rótulos apropriados para o MDT padrão MP2MP ou o MDT de dados P2MP e transportado para todos os PEs de saída. Quando o pacote chega ao PE de saída, o rótulo é removido e o pacote multicast IP é replicado na interface VRF.
Conclusão
A configuração MLDP MVPN permite a entrega de pacotes multicast IPv4 usando MPLS. Essa configuração usa rótulos MPLS para construir árvores de distribuição multicast (MDTs) padrão e de dados.
A replicação MPLS é usada como um mecanismo de encaminhamento na rede central. Para que a configuração MLDP MVPN funcione, certifique-se de que a configuração global MPLS MLDP esteja habilitada.
Feedback