Contents

Introduction

Informações de Apoio

Sinalização MLDP

Sinalização dentro da banda

Sinalização de sobreposição ou fora da banda

Label Distribution Protocol (LDP) Type Wildcard Forward Equivalence Class (FEC) # RFC5918

Topologia

Sinalização de sobreposição

Configuração

Verificar

Como construir um plano de controle?

P2MP MLDP

Conclusão

Informações Relacionadas

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

Note: Ativar o modo PIM apenas em interfaces voltadas para CE nos roteadores de borda do provedor; não é necessário no núcleo.

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

Note: Responda a solicitações de rótulo curinga digitadas recebidas do peer reproduzindo seu banco de dados de rótulos para prefixos. Utilizar Solicitações de Rótulo Curinga Digitadas para peers para solicitar uma repetição do banco de dados de rótulo correspondente para prefixos.

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

Note: O MPLS MLDP ainda não foi criado, pois o receptor ainda não está on-line.

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.

Informações Relacionadas

- https://tools.ietf.org/html/rfc5918

- https://tools.ietf.org/html/rfc4447

- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_lsm/configuration/15-sy/imc-lsm-15-sy-book.pdf

- Suporte Técnico e Documentação - Cisco Systems