Implementando VPN Multicast no Cisco IOS (Parte 5 - Apresentando dados / MDT particionado)

Em versões anteriores:



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).










All Articles