Perfil 0
Perfil 1
Perfil 3
Perfil 11
Como aprendemos com entradas anteriores, no backbone ao implementar mVPN, há sempre uma construção MDT padrão, à qual todos os roteadores PE estão conectados. As mensagens de serviço PIM (por exemplo, Bootstrap, Auto-RP), bem como o tráfego multicast personalizado, são transportados dentro deste MDT. Como resultado, alguns dispositivos PE recebem até mesmo o tráfego para o qual não assinaram.
Se você quer saber como lidar com isso - seja bem-vindo sob o gato!

A fim de melhorar a eficiência da transferência de dados, uma construção adicional é usada, que é conhecida como "Data MDT". A ideia por trás disso é a seguinte:
- Dentro da árvore, apenas o tráfego C- (S, G) é distribuído
- Apenas os PEs de saída que têm destinatários interessados tornam-se membros da árvore
- O dispositivo MDT de dados raiz é o Ingress PE (o roteador atrás do qual a fonte está localizada)
Visualmente, é assim:

Se imaginarmos uma situação em que uma fonte começa a transmitir para o segundo grupo multicast (230.1.1.2), para o qual os destinatários estão localizados apenas atrás de PE2 e PE3, então um MDT de dados adicional é criado e a imagem geral assume a forma (MDT padrão é omitido):

A sinalização para a comutação de tráfego de MDT padrão para MDT de dados é realizada exclusivamente sob demanda quando um limite predeterminado é excedido pelo Ingress PE por meio de PIM ou por meio de BGP.

Data MDT usando PIM
Se o PIM for usado para sinalização, o ingresso PE gera uma mensagem TLV PIM Data-MDT especial e a envia como parte do MDT padrão para garantir que todos os PEs possam receber a mensagem. Simultaneamente ao envio do Data MDT TLV, o Ingress PE inicia um temporizador igual a três segundos. Depois que o temporizador expirar, todos os pacotes serão transmitidos dentro do Data MDT.
Também deve ser observado que as informações contidas no Data-MDT TLV são armazenadas em cache em todos os PEs. A razão para isso é bastante trivial - mesmo que não haja destinatários de tráfego interessados em um PE em particular no momento, eles podem aparecer lá depois de um tempo. Assim, ao receber um PIM Join (dentro do C-VRF), o PE pode se conectar instantaneamente ao Data MDT já existente na rede.
Aproximadamente. Os TLVs Data-MDT são transmitidos uma vez por minuto.
Cada Data MDT é configurado para uma rota separada (S, G) dentro da VPN / VRF. O administrador deve especificar explicitamente o número máximo de MDTs de dados que podem ser gerados no dispositivo. Se em algum ponto o número de árvores recém-instaladas atingir o limite especificado, as árvores a seguir reutilizarão as já instaladas.
Aproximadamente. No momento em que este livro foi escrito, o Cisco IOS não oferece suporte à sinalização PIM sobre Data MDT. Todos os perfis com este alarme estão disponíveis apenas no sistema operacional IOS XR.
Data MDT com BGP
Ao usar o BGP em uma rede de sobreposição para sinalização de MDT de dados, os princípios básicos permanecem os mesmos (em comparação com o PIM):
- sinais de entrada de PE para todos os PEs que o tráfego para C- (S, G) será transmitido dentro do Data MDT
- egresso PE, após o recebimento de uma atualização BGP, junta-se à árvore especificada
- a família de endereçamento mVPN (sAFI 129) é usada para sinalização.
Acontece que o Ingress PE deve formar uma mensagem BGP Update especial e enviá-la a todos os PEs dentro do mVPN. Para isso, é utilizada uma rota do terceiro tipo.
Perfil 14
Vamos considerar a transição descrita usando o exemplo de nosso laboratório. Em particular, a configuração conhecida como "Perfil 14" é aplicável. Este perfil é caracterizado pelo uso de BGP mVPN AD para construir P2MP MLDP LSPs.
No PE, usaremos o seguinte modelo de configuração:
ip vrf C-ONE mdt auto-discovery mldp mdt partitioned mldp p2mp mdt overlay use-bgp mdt strict-rpf interface ! router bgp 1 address-family ipv4 mvpn neighbor 8.8.8.8 activate neighbor 8.8.8.8 send-community extended exit-address-family
Aproximadamente.
mdt strict-rpf
falaremos sobre o propósito do comando interface na próxima edição.
Auto-descoberta
Vamos ver o que acontece no PE1:
Em cada PE, é criada uma interface Lspvif0, na qual o C-PIM é ativado.
*Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up
Não há vizinhos no momento:
PE1#show ip pim vrf C-ONE int Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 172.1.11.1 GigabitEthernet2.111 v2/S 1 30 1 172.1.11.11 172.1.15.1 GigabitEthernet2.115 v2/S 1 30 1 172.1.15.15 1.1.1.1 Lspvif0 v2/S 0 30 1 1.1.1.1
Vamos ver a tabela BGP:
PE1#show bgp ipv4 mvpn all BGP table version is 39, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *> [1][1.1.1.1:1][1.1.1.1]/12 0.0.0.0 32768 ? *>i [1][1.1.1.1:1][2.2.2.2]/12 2.2.2.2 0 100 0 ? *>i [1][1.1.1.1:1][3.3.3.3]/12 3.3.3.3 0 100 0 ? *>i [1][1.1.1.1:1][4.4.4.4]/12 4.4.4.4 0 100 0 ? Route Distinguisher: 2.2.2.2:1 *>i [1][2.2.2.2:1][2.2.2.2]/12 2.2.2.2 0 100 0 ? Route Distinguisher: 3.3.3.3:1 Network Next Hop Metric LocPrf Weight Path *>i [1][3.3.3.3:1][3.3.3.3]/12 3.3.3.3 0 100 0 ? Route Distinguisher: 4.4.4.4:1 *>i [1][4.4.4.4:1][4.4.4.4]/12 4.4.4.4 0 100 0 ? Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *> [3][1.1.1.1:1][*][*][1.1.1.1]/14 0.0.0.0 32768 ? *>i [3][1.1.1.1:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? *>i [3][1.1.1.1:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? *>i [3][1.1.1.1:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ? *> [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18 0.0.0.0 32768 ? Route Distinguisher: 2.2.2.2:1 *>i [3][2.2.2.2:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? Route Distinguisher: 3.3.3.3:1 *>i [3][3.3.3.3:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 4.4.4.4:1 *>i [3][4.4.4.4:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ?
Como você pode ver, além das rotas do primeiro tipo já consideradas anteriormente, são adicionadas as rotas do terceiro tipo S-PMSI AD, que são usadas para anunciar PE como um roteador de entrada para um grupo C- (S, G) específico. No momento, o grupo é (*, *). Isso indica o desejo do PE em participar da construção do MDT particionado.
Obviamente, para que a transferência de dados funcione, as informações do ponto de encontro devem ser conhecidas no VRF. Em nosso caso, o CE15 atua como RP e BSR.
C-RP#sh run | i pim ip pim bsr-candidate Loopback0 0 ip pim rp-candidate Loopback0
Como o C-RP construiu uma vizinhança PIM com PE1, as informações sobre RP também são conhecidas neste PE1:
PE1#show ip pim vrf C-ONE rp mapping Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:25:50, expires: 00:01:26
É necessário entregar esta informação a todos os outros PE / CEs. Como fazer isso? Para melhor compreender o princípio, proponho partir do contrário e começar a olhar para as informações já conhecidas do CE2:
CE2#show ip pim rp mapping Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:27:54, expires: 00:02:26
Como você pode ver, as mensagens PIM BSR se espalharam pela infraestrutura mVPN. Vamos ver o despejo de tráfego no PE1:

Como você pode ver, o PE1 encapsula a mensagem PIM BSR dentro do MPLS e a rotula com 28. De onde ela vem? Podemos supor que, uma vez que este pacote atingiu CE2 (e, portanto, PE2), isto é, algum LSP antes de PE2.
PE2#show 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 : 04:17:40 FEC Root : 2.2.2.2 (we are the root) Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : None Expires : N/A Path Set ID : 1 Replication client(s): > MDT (VRF C-ONE) Uptime : 04:17:40 Path Set ID : None Interface : Lspvif0 RPF-ID : * LSM ID : 3 Type: P2MP Uptime : 01:30:06 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 3 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 34 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 01:30:06 Path Set ID : None Interface : Lspvif0 RPF-ID : *
A partir da análise do banco de dados mLDP, pode-se ver que no PE2 há uma determinada árvore (LSM ID: 3), cuja raiz é PE1 (IP = 1.1.1.1), Opaco = 01 0004 0001FFFF, e um rótulo local 34 foi gerado para esta árvore, que foi enviado ao vizinho R6 ( P2).
Como o PE2 sabia sobre a árvore, cuja raiz é PE1, e ainda conseguiu um Opaco para ela? A resposta é simples - usando a rota BGP tipo 3.
Quando o PE1 recebeu o PIM BSR, ele gerou uma rota BGP adicional que descreve o grupo (*, 224.0.0.13) (lembre-se de que este é um endereço reservado para o envio de todas as mensagens do serviço PIM). Esta rota serve para anunciar uma nova árvore multicast mLDP. Dentro do PTA está o valor opaco a ser usado para sinalização via mLDP.
PE1#show bgp ipv4 mvpn all route-type 3 * 224.0.0.13 1.1.1.1 BGP routing table entry for [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18, version 116 Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer) Advertised to update-groups: 1 Refresh Epoch 1 Local 0.0.0.0 from 0.0.0.0 (1.1.1.1) Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best Community: no-export Extended Community: RT:65001:1 PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null, tunnel parameters: 0600 0104 0101 0101 0007 0100 0400 01FF FF rx pathid: 0, tx pathid: 0x0
Assim, ao importar esta rota, PE2 pode iniciar a sinalização mLDP para PE1 para a árvore (*, 224.0.0.13). Para o rótulo recebido de PE2, P2 (R6) gera seu próprio local (29) e o envia para P1 (R5):
P2#show 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 : 01:40:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 5.5.5.5:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.56* Local Label (D): 29 Next Hop : 10.5.6.5 Replication client(s): 2.2.2.2:0 Uptime : 01:40:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.26* Local label (U): None Next Hop : 10.2.6.2
P1 (R5) faz o mesmo, gerando seu rótulo local para a árvore e enviando para PE1:
P1#show 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 : 01:41:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 1.1.1.1:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.15* Local Label (D): 28 Next Hop : 10.1.5.1 Replication client(s): 4.4.4.4:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.45* Local label (U): None Next Hop : 10.4.5.4 7.7.7.7:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 30 Interface : GigabitEthernet2.57* Local label (U): None Next Hop : 10.5.7.7 6.6.6.6:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 29 Interface : GigabitEthernet2.56* Local label (U): None Next Hop : 10.5.6.6
Visualmente, todo o processo é mostrado na figura abaixo:

Juntando uma árvore compartilhada e construindo uma árvore P2MP raiz (ROOT = RP-PE)
Etapa 2. Um receptor de tráfego aparece na rede. Após a saída PE (PE2) receber uma junção PIM do CE para C - (*, G), PE2 executa uma verificação de RPF para encontrar o próximo salto de BGP para C-RP. O Next-Hop encontrado (1.1.1.1) será usado como MDT ROOT particionado para mLDP.
Além disso, o PE2 cria uma interface Lspvif dentro do C-VRF:
PE2# *Dec 3 14:46:21.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to up PE2# *Dec 3 14:46:22.310: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1
Etapa 3. Egress PE (PE2) gera mensagem de mapeamento mLDP para RP-PE (ROOT P2MP MDT) usando o valor opaco da atualização BGP.
PE2#show mpls mldp database summary LSM ID Type Root Decoded Opaque Value Client Cnt. 4 P2MP 1.1.1.1 [gid 65536 (0x00010000)] 1 1 P2MP 2.2.2.2 [gid 65536 (0x00010000)] 1 3 P2MP 1.1.1.1 [gid 131071 (0x0001FFFF)] 1 PE2# PE2#show mvpn ipv4 vrf C-ONE auto-discovery s-pmsi * * detail I-PMSI - Intra-AS Inclusive-PMSI, S-PMSI - Selective-PMSI * - Indicates Wildcard source or group address [S-PMSI][1.1.1.1:1][*][*][1.1.1.1], Joined Orig: Remote Uptime: 04:44:27 Type: MLDP P2MP Root: 1.1.1.1 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][3.3.3.3:1][*][*][3.3.3.3], Orig: Remote Uptime: 04:44:22 Type: MLDP P2MP Root: 3.3.3.3 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][4.4.4.4:1][*][*][4.4.4.4], Orig: Remote Uptime: 04:44:20 Type: MLDP P2MP Root: 4.4.4.4 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][2.2.2.2:1][*][*][2.2.2.2], Joined Orig: Local Uptime: 04:44:24 Type: MLDP P2MP Root: 2.2.2.2 Fec-Opq: 1 Global-Id: 65536 (0x10000) PE2#show mpls mldp database opaque_type gid 65536 LSM ID : 4 Type: P2MP Uptime : 00:03:43 FEC Root : 1.1.1.1 Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 4 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 35 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 00:03:43 Path Set ID : None Interface : Lspvif1 RPF-ID : 0x1
Etapa 4. A saída PE gera uma sexta rota BGP (juntando-se à árvore compartilhada para RP-PE). Esta rota é importada apenas para RP-PE.
PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 230.1.1.1 BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][230.1.1.1/32]/22, version 130 Paths: (1 available, best #1, table MVPNv4-BGP-Table) Advertised to update-groups: 1 Refresh Epoch 1 Local 0.0.0.0 from 0.0.0.0 (2.2.2.2) Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best Extended Community: RT:1.1.1.1:1 rx pathid: 1, tx pathid: 0x0
Etapa 5. RP-PE traduz a rota BGP recebida do sexto tipo na junção PIM para RP. Neste ponto, o RP está pronto para enviar tráfego multicast para o Egress PE. Você precisa entregar o tráfego da origem ao RP.
PE1#show ip mroute vrf C-ONE | b \( (*, 230.1.1.1), 00:07:08/stopped, RP 15.15.15.15, flags: SG Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.15 Outgoing interface list: Lspvif0, Forward/Sparse, 00:07:08/stopped

Etapa 6. Quando o S-PE (PE4) recebe o primeiro pacote multicast da origem (CE4), o tráfego é encapsulado dentro da mensagem do Registro PIM e enviado como um pacote unicast para o C-RP (usando as regras normais do VPN MPLS L3).
Etapa 7. Após receber o Registro PIM, o C-RP inicia o processo de construção da árvore C (14.14.14.14, 230.1.1.1). RP-PE recebe a junção PIM para C- (14.14.14.14, 230.1.1.1) de C-RP. Esta mensagem é traduzida em rota BGP tipo 7. No entanto, antes de enviar para o lado da origem, você precisa construir uma nova árvore MDT particionada com PE como ROOT.

Etapa 8. RP-PE executa verificações de RPF para encontrar o próximo salto de BGP em direção à fonte. Este endereço será usado como MDT ROOT particionado para mLDP.
Etapa 9. Usando a rota BGP Next-Hop e BGP do terceiro tipo do Ingress PE, RP-PR gera uma mensagem de mapeamento mLDP para o endereço IP do Ingress PE, construindo assim a árvore P2MP raiz para o Ingress PE.
Etapa 10. RP-PE envia a rota BGP tipo 7 (junção de RP) para o Ingress PE.
Etapa 11. O Ingress PE converte a rota BGP recebida do sétimo tipo em PIM Join e a envia para a origem do tráfego.

Anexo da árvore de origem e construção P2MP (ROOT = S-PE)
Etapa 12. O Ingress PE também envia uma rota BGP Tipo 5 para todos os PEs mVPN, informando-os, assim, de que há uma fonte ativa na rede. Esta rota é um gatilho para mudar para a árvore SPT.
Etapa 13. A saída PE usa a rota BGP recebida tipo 5 para gerar a mensagem de mapeamento mLDP para a entrada PE (a informação MDT é obtida da rota BGP tipo 3).

Assim, o tráfego agora pode ser redirecionado de maneira ideal da origem ao destino usando tags mpls (mLDP).
