A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve a sinalização in-band VRF MLDP que é o perfil 6 para o Multicast da próxima geração sobre VPN (mVPN). Usa um exemplo e a aplicação no Cisco IOS a fim ilustrar o comportamento.
Em-faixa do protocolo da distribuição de rótulo do Multicast (MLDP) que sinaliza para permitir o núcleo MLDP de criar (S, G) ou (*, G) estado sem usar a sinalização fora da banda tal como o Border Gateway Protocol (BGP) ou a transmissão múltipla independente de protocolo (PIM).
o VPN multicast MLDP-apoiado (MVPN) permite que os fluxos de transmissão múltipla VPN sejam agregados sobre uma árvore VPN-específica.
Nenhum estado do cliente é criado no núcleo MLDP, há o único estado para as árvores de distribuição do Multicast do padrão e dos dados (MDT).
Em determinadas encenações, o estado criado para córregos VPN é limitado e não parece ser um risco ou um fator limitante. Nestas encenações, MLDP pode construir a em-faixa MDT que é os caminhos comutados por rótulo do trânsito (LSP).
As árvores usadas em um espaço VPN são MDT. As árvores usadas na tabela global são o ponto a multiponto do trânsito (P2MP) ou (MP2MP) LSP multiponto-à-multipontos.
Em ambos os casos, um único fluxo de transmissão múltipla (VPN ou não) é associado com um único LSP no núcleo MPLS. A informação do córrego é codificada no Forwarding Equivalence Class (FEC) do LSP. Esta é sinalização da em-faixa.
O LS fornece benefícios quando comparado aos túneis do núcleo GRE que são usados atualmente para transportar o tráfego de cliente no núcleo e leverages a infraestrutura de MPLS para transportar pacotes do Protocolo IP multicast, fornecendo uns dados comuns aplana para o unicast e o Multicast.
A sinalização MLDP fornece duas funções:
O elemento datilografado do convite FEC refere todos os FEC do tipo especificado que encontram a limitação. Especifica “um tipo de elemento FEC” e uma limitação opcional, que seja pretendida fornecer a informação adicional.
O formato do elemento datilografado do convite FEC é:
Convite datilografado: Tipo de elemento do octeto FEC (0x05).
LDP [RFC5036] distribui etiquetas para enviar as classes de equivalência (FEC). O LDP usa FEC TLV em mensagens LDP para especificar FEC.
Um LDP FEC TLV inclui uns ou vários elementos FEC. Um elemento FEC inclui um tipo FEC e um valor tipo-dependente opcional.
O RFC 5036 especifica dois tipos FEC (prefixo e convite), e outros documentos especificam tipos adicionais FEC; por exemplo, veja o [RFC4447]and [MLDP].
Como especificado pelo RFC 5036, o elemento do convite FEC refere todos os FEC relativo a uma limitação opcional.
O único RFC 5036 da limitação especifica é um que limita o espaço do elemento do convite FEC a “todos os FEC limitado a uma etiqueta dada”.
A especificação do RFC 5036 do elemento do convite FEC tem estas deficiências que limitam sua utilidade:
Etapa 1. Permita MPLS MLDP em Nós do núcleo.
# registro do mldp dos mpls
Etapa 2. Permita a SINALIZAÇÃO DE INBAND MLDP no NÚCLEO.
No PE1, no PE2 e no PE3
# mldp dos mpls do vrf INBAND-MLDP do Protocolo IP multicast
# laço de retorno 0 da fonte dos mpls do vrf INBAND-MLDP do pim IP
Etapa 3. Permita PIM S em todas as interfaces CE e em relação PE VRF.
No CE1, o CE2, o CE3 e todas as relações PE1 VRF, PE2 e PE3
# relação x/x
# ip pim sparse-mode
# loopback de interface x/x
# ip pim sparse-mode
Note: Permita o modo de PIM somente no CE que enfrenta relações em roteadores de extremidade do provedor; não exigido no núcleo.
Etapa 4. Permita o Multicast no VRF.
No PE1, no PE2 e no PE3
# vrf INBAND-MLDP do roteamento de transmissão múltipla IP
Etapa 5. Permita o VRF na relação x/x PE-CE do roteador de PE.
# relação x/x
# vrf IP que envia INBAND-MLDP
Etapa 6. Configurar o modo SS nos Nós CE e PE (VRF somente).
Em Nós CE
# padrão ssm do pim IP
No PE1, PE2, PE3 sob o VRF
# padrão ssm do vrf INBAND-MLDP do pim IP
Etapa 7. Configurar o grupo de IGMP SS 232.1.1.1 (receptor).
No receptor 2 e 3
#interface x/x CE
# fonte 10.1.0.2 de 232.1.1.1 do juntar-grupo do pim IP
O IGP, MPLS LDP, BGP é executado muito bem através de nossa extremidade de rede para terminar.
Nesta seção, a verificação é feita para verificar a adjacência VPN AF na rede do núcleo/agregação. A adjacência é verificada entre o CE-PE e o controle plano é verificado igualmente junto com o plano dos dados o tráfego VPN sobre a rede MPLS.
Para verificar que os dispositivos da borda do local e do cliente remoto (CE) podem se comunicar através do núcleo do Multiprotocol Label Switching (MPLS), execute estas tarefas:
Tarefa 1: Verifique a conectividade física.
Tarefa 2: Verifique o unicast do VPNv4 da família do endereço BGP.
Tarefa 3: Verifique o End to End do tráfego multicast.
Na entrada do mRIB PE VRF no PE1, no PE2 e no PE3
Tarefa 4: Verifique o NÚCLEO MPLS.
Verifique o plano do controle que a imposição de rótulo ocorre quando o roteador de PE baseado para a frente no cabeçalho IP e adiciona uma etiqueta MPLS ao pacote em cima de entrar em uma rede MPLS.
Na direção da imposição de rótulo, os pacotes dos switch do roteador baseados em uma consulta de tabela de CEF para encontrar o salto seguinte e adicionam a informação apropriada da etiqueta armazenada MENTIR para o destino. Quando um roteador executa a etiqueta que troca no núcleo em um pacote de MPLS, o roteador faz uma consulta da tabela MPLS. O roteador deriva esta tabela MPLS (LFIB) da informação na tabela de CEF e no Label Information Base (LIB).
A disposição de rótulo ocorre quando o roteador de PE recebe um pacote de MPLS, faz uma decisão de encaminhamento baseada na etiqueta MPLS, remove a etiqueta, e envia um pacote IP. O roteador de PE usa o LFIB para a determinação de caminho para um pacote neste sentido. Como indicado previamente, uma sessão especial do iBGP facilita a propaganda de prefixos do VPNv4 e de suas etiquetas entre roteadores de PE. No PE de anúncio, o BGP atribui etiquetas para os prefixos VPN aprendidos localmente e instala-os no LFIB, que é a tabela do forwarding MPLS.
Etapa 1. Uma vez que você configura o MLDP no núcleo. Troca destas mensagens.
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 isto debugam para verificar o estabelecimento precedente:
# debugar o mldp todo dos mpls
Note: Responda aos pedidos datilografados da etiqueta do convite recebidos do par replaying seu base de dados da etiqueta para prefixos. Utilize pedidos datilografados da etiqueta do convite para pares pedir uma repetição do base de dados da etiqueta do par para prefixos.
Etapa 2. Permita a SINALIZAÇÃO DE INBAND 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
Note: O MPLS MLDP não é criado ainda porque o receptor não é em linha ainda.
Quando o receptor vier em linha:
O receptor 3 vem em linha e envia o PIM JUNTA-SE (S, G) mensagens a 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
Alguma comunicação do receptor (S, G) se junta, será convertido a MLDP e todas as mensagens são transversais para o Lspvif 1
Com PIM JUNTE-SE (S, G) como MLDP é protocolo receptor-conduzido, começa construir o base de dados MLDP do receptor à fonte. Esta é atribuição a jusante da etiqueta para P2MP MLDP.
O transporte de pacote P2MP é executado usando o Resource Reservation Protocol (RSVP) P2MP – a engenharia de tráfego (P2MP-TE) e o transporte de pacote M2M é executado com o VPN multicast do IPv4 (MVPN) que usa o protocolo da distribuição de rótulo do Multicast (MLDP).
O pacote é transportado sobre três tipos de Roteadores:
• Roteador do fim do cabeçalho: Encapsula o pacote IP com umas ou várias etiquetas.
• Roteador do ponto médio: Substitui a em-etiqueta com uma para fora-etiqueta.
• Roteador da extremidade final: Remove a etiqueta do pacote.
O fluxo de pacote de informação na rede MLDP-baseada MVPN para cada pacote que entra, MPLS cria para fora-etiquetas múltiplas. Os pacotes da rede da fonte replicated ao longo do trajeto à rede do receptor. O roteador CE1 manda o tráfego multicast do IP nativo. O roteador PE1 impõe uma etiqueta no pacote de transmissão múltipla entrante e replicates o pacote rotulado para a rede central MPLS. Quando o pacote alcança o roteador central (P), o pacote replicated com as etiquetas apropriadas para o padrão MDT MP2MP ou os dados MDT P2MP e está transportado a toda a saída PE. Uma vez que o pacote alcança a saída PE, a etiqueta está removida e o pacote do Protocolo IP multicast replicated na relação 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 fonte começar fluir:
Quando o origem de transmissão múltipla começa enviar o tráfego, [10.1.0.2, 232.1.1.1] aconteça segundo as indicações desta imagem.
Trafique da fonte 10.1.0.2 que flui de 232.1.1.1. Entra com ethernet0/2.
O pacote obtém enviado através de 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 obtém em túnel no Lspvif 0.
No lado do receptor:
No lado do receptor o alcance do pacote no 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 bateu o PE1, verifica o LS ID para enviar o tráfego, que etiquetam para impor no pacote de transmissão múltipla.
Esta imagem mostra a verificação da relação LSPVIF.
Para cada pacote que entra, o MPLS cria para fora-etiquetas múltiplas. Os pacotes da rede da fonte replicated ao longo do trajeto à rede do receptor. O roteador CE1 manda o tráfego multicast do IP nativo. O roteador PE1 impõe uma etiqueta no pacote de transmissão múltipla entrante e replicates o pacote rotulado para a rede central MPLS.
Quando o pacote alcança o roteador central (P), o pacote replicated com as etiquetas apropriadas para o padrão MDT MP2MP ou os dados MDT P2MP e está transportado a toda a saída PE. Uma vez que o pacote alcança a saída PE, a etiqueta está removida e o pacote do Protocolo IP multicast replicated na relação VRF.
A configuração MVPN MLDP permite a entrega do pacote de transmissão múltipla do IPv4 usando o MPLS. Esta configuração usa etiquetas MPLS para construir as árvores de distribuição do Multicast do padrão e dos dados (MDT).
A replicação MPLS é usada como um mecanismo de forwarding na rede central. Para que a configuração MVPN MLDP trabalhe, assegure-se de que a configuração global MPLS MLDP esteja permitida.