IP : Multicast

Fonte e dados dual-homed MDT no mVPN

12 Agosto 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (15 Junho 2015) | Feedback

Introdução

Este documento descreve o mVPN (rede de provedor virtual do Multicast) com fonte e dados dirigidos duplos MDT (árvore de distribuição do Multicast). Um exemplo no ® do Cisco IOS é usado a fim ilustrar o comportamento.

Contribuído por Luc De Ghein, engenheiro de TAC da Cisco.

O problema

Se uma fonte no mundo do mVPN é dupla dirigida a dois Roteadores da ponta de provedor do ingresso (PE), poderia ser possível para os dois roteadores de PE do ingresso aos ambos tráfego dianteiro para um (S, G) na nuvem do Multiprotocol Label Switching (MPLS). Isto é possível se, por exemplo, há dois roteadores de PE da saída e cada encaminhamento de caminho reverso (RPF) a um roteador de PE diferente do ingresso. Se ambos os roteadores de PE do ingresso para a frente no padrão MDT, então o mecanismo da afirmação retrocederão dentro e um ingresso PE ganha o mecanismo da afirmação e o outro perde de modo que um e somente um ingressos PE continuem a enviar o cliente (c) (S, G) no MDT. Contudo, se por qualquer razão o mecanismo da afirmação não começou no padrão MDT, a seguir é possível para ambos os roteadores de PE do ingresso começar a transmitir o c (S, G) tráfego multicast em um DATA-MDT que iniciam. Porque o tráfego está não no padrão MDT anymore, mas nos dados MDT, ambos os roteadores de PE do ingresso não recebem o c (S, G) tráfego de se na relação MDT/Tunnel. Isto pode causar o tráfego duplicado persistente rio abaixo. Este documento explica a solução a este problema.

Afirme o mecanismo no padrão MDT

A informação nesta seção guarda verdadeiro para o padrão MDT, apesar do protocolo de árvore do núcleo. O protocolo de árvore escolhido do núcleo é a transmissão múltipla independente de protocolo (PIM).

O Cisco IOS é usado para os exemplos, mas tudo que é mencionado aplica-se ingualmente para o Cisco IOS XR. Todos os grupos de transmissão múltipla usados são grupos do Source Specific Multicast (SSM).

Olhe a figura 1. Dual-Homed-Source-1. Há dois roteadores de PE do ingresso (PE1 e PE2) e dois roteadores de PE da saída (PE3 e PE4). A fonte está no CE1 com endereço IP 10.100.1.6. O CE1 é duplo dirigido ao PE1 e ao PE2.


Figura 1. Dual-Homed-Source-1

A configuração em todos os roteadores de PE (o distinguidor de rota (RD) pode ser diferente nos roteadores de PE) é:

vrf definition one
 rd 1:1
 !
 address-family ipv4
  mdt default 232.10.10.10
  route-target export 1:1
  route-target import 1:1
 exit-address-family
!

A fim conseguir ambos os roteadores de PE do ingresso começar enviar o fluxo de transmissão múltipla (10.100.1.6,232.1.1.1) para fora no padrão MDT, devem ambos receber uma junta de uma saída PE. Olhe a topologia em Figure1. Dual-Homed-Source-1. Você pode ver que à revelia, se todos os custos dos links da borda são os mesmos e todos os custos dos links do núcleo são os mesmos, a seguir PE3 RPF para o PE1 e o PE4 RPF para o PE2 para (10.100.1.6,232.1.1.1). Eles ambos RPF a seu ingresso mais próximo PE. Esta saída confirma esta:

PE3#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
  RPF interface: Tunnel0
  RPF neighbor: ? (10.100.1.1)
  RPF route/mask: 10.100.1.6/32
  RPF type: unicast (bgp 1)
  Doing distance-preferred lookups across tables
  BGP originator: 10.100.1.1
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE3 tem o RPF ao PE1.

PE4#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
  RPF interface: Tunnel0
  RPF neighbor: ? (10.100.1.2)
  RPF route/mask: 10.100.1.6/32
  RPF type: unicast (bgp 1)
  Doing distance-preferred lookups across tables
  BGP originator: 10.100.1.2
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE4 tem o RPF ao PE2. A razão que PE3 escolhe o PE1 porque o vizinho de RPF é que a rota do unicast para 10.100.1.6/32 no roteamento virtual/transmissão (VRF) um é o melhor através do PE1. PE3 recebe realmente a rota 10.100.1.6/32 do PE1 e do PE2. Todos os critérios no algoritmo do cálculo do melhor caminho do Border Gateway Protocol (BGP) são os mesmos, à exceção do custo para o endereço de próximo salto BGP.

PE3#show bgp vpnv4 unicast vrf one  10.100.1.6/32
BGP routing table entry for 1:3:10.100.1.6/32, version 333
Paths: (2 available, best #1, table one)
  Advertised to update-groups:
     21        
  Refresh Epoch 1
  Local, imported path from 1:1:10.100.1.6/32 (global)
    10.100.1.1 (metric 11) (via default) from 10.100.1.5 (10.100.1.5)
      Origin incomplete, metric 11, localpref 100, valid, internal, best
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000640200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.2.4.1:0
      Originator: 10.100.1.1, Cluster list: 10.100.1.5
      Connector Attribute: count=1
       type 1 len 12 value 1:1:10.100.1.1
      mpls labels in/out nolabel/32
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  Local, imported path from 1:2:10.100.1.6/32 (global)
    10.100.1.2 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
      Origin incomplete, metric 11, localpref 100, valid, internal
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000640200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.2.2.2:0
      Originator: 10.100.1.2, Cluster list: 10.100.1.5
      Connector Attribute: count=1
       type 1 len 12 value 1:2:10.100.1.2
      mpls labels in/out nolabel/29
      rx pathid: 0, tx pathid: 0
PE4#show bgp vpnv4 unicast vrf one  10.100.1.6/32
BGP routing table entry for 1:4:10.100.1.6/32, version 1050
Paths: (2 available, best #2, table one)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  Local, imported path from 1:1:10.100.1.6/32 (global)
    10.100.1.1 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
      Origin incomplete, metric 11, localpref 100, valid, internal
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000640200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.2.4.1:0
      Originator: 10.100.1.1, Cluster list: 10.100.1.5
      Connector Attribute: count=1
       type 1 len 12 value 1:1:10.100.1.1
      mpls labels in/out nolabel/32
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  Local, imported path from 1:2:10.100.1.6/32 (global)
    10.100.1.2 (metric 11) (via default) from 10.100.1.5 (10.100.1.5)
      Origin incomplete, metric 11, localpref 100, valid, internal, best
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000640200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.2.2.2:0
      Originator: 10.100.1.2, Cluster list: 10.100.1.5
      Connector Attribute: count=1
       type 1 len 12 value 1:2:10.100.1.2
      mpls labels in/out nolabel/29
      rx pathid: 0, tx pathid: 0x0

O melhor caminho escolhido por PE3 é o trajeto anunciado pelo PE1 porque aquele tem o mais baixo custo do Interior Gateway Protocol (IGP) (11), contra o IGP custado (21) para o PE2. Para PE4 é o reverso. A topologia revela que de PE3 ao PE1 há somente um salto, quando de PE3 ao PE2 houver dois saltos. Desde que todos os links têm o mesmo custo IGP, PE3 escolhe o trajeto do PE1 como o melhor.

A base de informação do roteamento de transmissão múltipla (MRIB) para (10.100.1.6,232.1.1.1) olha como esta no PE1 e no PE2 quando há um tráfego do no multicast contudo:

PE1#show ip mroute vrf one 232.1.1.1 10.100.1.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:00:12/00:03:17, flags: sT
  Incoming interface: Ethernet0/0, RPF nbr 10.2.1.6
  Outgoing interface list:
    Tunnel0, Forward/Sparse, 00:00:12/00:03:17
PE2#show ip mroute vrf one 232.1.1.1 10.100.1.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:00:47/00:02:55, flags: sT
  Incoming interface: Ethernet1/0, RPF nbr 10.2.2.6
  Outgoing interface list:
    Tunnel0, Forward/Sparse, 00:00:47/00:02:55

O PE1 e o PE2 ambos receberam um PIM juntam-se para (10.100.1.6,232.1.1.1). A relação do tunnel0 está na lista de interface enviada (ÓLEO) para a entrada de transmissão múltipla em ambo o Roteadores.

Os começos do tráfego multicast a fluir para (10.100.1.6,232.1.1.1). “Debugar o vrf um 232.1.1.1 do pim IP” e “debugar o vrf um 232.1.1.1 do mrouting IP” mostram-nos que a chegada do tráfego multicast no tunnel0 (no ÓLEO) de ambos os roteadores de PE do ingresso, faz com que o mecanismo da afirmação seja executado.

PE3

PIM(1): Send v2 Assert on Tunnel0 for 232.1.1.1, source 10.100.1.6, metric [110/11] 
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
MRT(1): not RPF interface, source address 10.100.1.6, group address 232.1.1.1
PIM(1): Received v2 Assert on Tunnel0 from 10.100.1.2
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PIM(1): We lose, our metric [110/11]
PIM(1): Prune Tunnel0/232.10.10.10 from (10.100.1.6/32, 232.1.1.1)
MRT(1): Delete Tunnel0/232.10.10.10 from the olist of (10.100.1.6, 232.1.1.1)
MRT(1): Reset the PIM interest flag for (10.100.1.6, 232.1.1.1)
MRT(1): set min mtu for (10.100.1.6, 232.1.1.1) 1500->18010 - deleted
PIM(1): Received v2 Join/Prune on Tunnel0 from 10.100.1.3, not to us
PIM(1): Join-list: (10.100.1.6/32, 232.1.1.1), S-bit set

PE4

PIM(1): Received v2 Assert on Tunnel0 from 10.100.1.1
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PIM(1): We win, our metric [110/11]
PIM(1): (10.100.1.6/32, 232.1.1.1) oif Tunnel0 in Forward state
PIM(1): Send v2 Assert on Tunnel0 for 232.1.1.1, source 10.100.1.6, metric [110/11]
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PIM(1): Received v2 Join/Prune on Tunnel0 from 10.100.1.3, to us
PIM(1): Join-list: (10.100.1.6/32, 232.1.1.1), S-bit set
PIM(1): Update Tunnel0/10.100.1.3 to (10.100.1.6, 232.1.1.1), Forward state, by PIM SG Join

Se a métrica e a distância são o mesmo de ambo o Roteadores para a fonte 10.100.1.6, a seguir há um tiebreaker a fim determinar o vencedor da afirmação. O tiebreaker é o endereço IP de Um ou Mais Servidores Cisco ICM NT o mais alto do vizinho de PIM no tunnel0 (padrão MDT). Neste caso, este é PE2:

PE1#show ip pim vrf one neighbor 
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
      L - DR Load-balancing Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
10.100.1.4        Tunnel0                  06:27:57/00:01:29 v2    1 / DR S P G
10.100.1.3        Tunnel0                  06:28:56/00:01:24 v2    1 / S P G
10.100.1.2        Tunnel0                  06:29:00/00:01:41 v2    1 / S P G
PE1#show ip pim vrf one interface 

Address          Interface                Ver/   Nbr    Query  DR         DR
                                          Mode   Count  Intvl  Prior
10.2.1.1         Ethernet0/0              v2/S   0      30     1          10.2.1.1
10.2.4.1         Ethernet1/0              v2/S   0      30     1          10.2.4.1
10.100.1.1       Lspvif1                  v2/S   0      30     1          10.100.1.1
10.100.1.1       Tunnel0                  v2/S   3      30     1          10.100.1.4

O tunnel0 removido PE1 do ÓLEO da entrada de transmissão múltipla devido ao afirma. Desde que o ÓLEO se tornou vazio, a entrada de transmissão múltipla é podada.

PE1#show ip mroute vrf one 232.1.1.1 10.100.1.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:17:24/00:00:01, flags: sPT
  Incoming interface: Ethernet0/0, RPF nbr 10.2.1.6
  Outgoing interface list: Null

O PE2 tem a Um-bandeira ajustada no tunnel0 da relação, porque é o vencedor da afirmação.

PE2#show ip mroute vrf one 232.1.1.1 10.100.1.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:17:20/00:02:54, flags: sT
  Incoming interface: Ethernet1/0, RPF nbr 10.2.2.6
  Outgoing interface list:
    Tunnel0, Forward/Sparse, 00:17:20/00:02:54, A

O PE2 envia periodicamente uma afirmação no tunnel0 (padrão MDT), imediatamente antes do temporizador da afirmação expira. Como tal PE2 permanece o vencedor da afirmação.

PE2#
PIM(1): Send v2 Assert on Tunnel0 for 232.1.1.1, source 10.100.1.6, metric [110/11]
PIM(1): Assert metric to source 10.100.1.6 is [110/11]

Conclusão

O mecanismo da afirmação igualmente trabalha com uma interface de túnel no ÓLEO. Afirma estão trocados sobre o padrão MDT quando os roteadores de PE do ingresso recebem c (S, G) tráfego multicast na interface de túnel associada que está no ÓLEO.

Afirme o mecanismo com dados MDT

Na maioria das vezes quando os dados MDT são configurados, o mecanismo da afirmação ainda será executado no padrão MDT como o c (S, G) tráfego é comutado somente sobre do padrão MDT aos dados MDT após três segundos. Então o mesmo ocorre como descrito anteriormente. Note que há somente uma interface de túnel pelo VRF Multicast-permitido: padrão MDT e todos os dados MDT usam uma interface de túnel somente. Esta interface de túnel é usada no ÓLEO nos roteadores de PE do ingresso ou como uma relação RPF nos roteadores de PE da saída.

Em alguns casos é possível que o mecanismo da afirmação não está provocado antes que os dados MDT estejam sinalizados. Então é possível que o c (S, G) tráfego multicast começa ser enviado em uns dados MDT nos roteadores de PE PE1 do ingresso e no PE2. Nesses casos, isto poderia conduzir à duplicata c do permanent (S, G) tráfego multicast através da rede central MPLS. A fim evitar isto, esta solução foi executada: quando um roteador de PE do ingresso vê um outro roteador de PE do ingresso anunciar uns dados MDT para que o roteador de PE é igualmente um roteador de PE do ingresso, junta-se a esses dados MDT. Em princípio, somente os roteadores de PE da saída (de que tem um receptor de downstream) juntar-se-iam aos dados MDT. Porque os roteadores de PE do ingresso se juntam aos dados MDT anunciados por outros roteadores de PE do ingresso, conduz ao roteador de PE do ingresso que recebe o tráfego multicast da interface de túnel que esta presente no ÓLEO, e daqui esta provoca o mecanismo da afirmação e condu-lo a um dos roteadores de PE do ingresso para parar de enviar o c (S, G) tráfego multicast em seus dados MDT (com a interface de túnel), quando o outro ingresso PE (vencedor da afirmação) puder continuar a enviar o c (S, G) tráfego multicast em seus dados MDT.

Para o exemplo seguinte, supõe que os roteadores de PE PE1 e PE2 do ingresso nunca viram o c (S, G) tráfego multicast de se no padrão MDT. O tráfego está no padrão MDT por somente três segundos e não é difícil compreender que este pode ocorrer se há, por exemplo, uma perda de tráfego provisória na rede central.

A configuração para os dados MDT é adicionada a todos os roteadores de PE. A configuração em todos os roteadores de PE (o RD pode ser diferente nos roteadores de PE) é:

vrf definition one
 rd 1:1
 !
 address-family ipv4
  mdt default 232.10.10.10
mdt data 232.11.11.0 0.0.0.0
  route-target export 1:1
  route-target import 1:1
 exit-address-family
!

Assim que o PE1 e o PE2 virem o tráfego da fonte, cria a corrente alternada - (S, G) entrada. Ambos os roteadores de PE do ingresso enviam o c (S, G) tráfego multicast no padrão MDT. Os roteadores de PE PE3 e PE4 da saída recebem o tráfego multicast e enviam-no. Devido a uma edição provisória, o PE2 não vê o tráfego do PE1 e vice-versa no padrão MDT. Que ambos enviam uns dados MDT juntam-se ao Type Length Value (TLV) para fora no padrão MDT.

Se não há nenhum c (S, G) tráfego, você vê este estado do Multicast nos roteadores de PE do ingresso:

PE1#show ip mroute vrf one 232.1.1.1 10.100.1.6
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:00:45/00:02:44, flags: sT
  Incoming interface: Ethernet0/0, RPF nbr 10.2.1.6
  Outgoing interface list:
    Tunnel0, Forward/Sparse, 00:00:45/00:02:42
PE2#show ip mroute vrf one 232.1.1.1 10.100.1.6  
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:02:18/00:03:28, flags: sT
  Incoming interface: Ethernet1/0, RPF nbr 10.2.2.6
  Outgoing interface list:
    Tunnel0, Forward/Sparse, 00:02:18/00:03:28

A y-bandeira não é ajustada ainda. Ambos os roteadores de PE do ingresso têm a relação do tunnel0 no ÓLEO. Isto é devido ao fato de que PE3 tem o RPF para o PE1 e o PE4 tem o RPF para o PE2 para c (S, G).

Quando tráfego multicast para o c (S, G) começa fluir para a frente, PE1 e PE2 o tráfego. O ponto inicial para os dados MDT é cruzado em ambos os roteadores de PE do ingresso e ambos mandam uns dados MDT juntam-se ao TLV e após a transmissão de um começo de três segundos em seus dados MDT. Observe que o PE1 se junta aos dados MDT originado pelo PE2 e pelo PE2 se junta aos dados MDT originado pelo PE1.

PE1#show ip mroute vrf one 232.1.1.1 10.100.1.6 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:01:26/00:03:02, flags: sTy
  Incoming interface: Ethernet0/0, RPF nbr 10.2.1.6
  Outgoing interface list:
    Tunnel0, Forward/Sparse, 00:01:26/00:03:02
PE2#show ip mroute vrf one 232.1.1.1 10.100.1.6 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:00:41/00:02:48, flags: sTy
  Incoming interface: Ethernet1/0, RPF nbr 10.2.2.6
  Outgoing interface list:
    Tunnel0, Forward/Sparse, 00:00:41/00:02:48

o PE1 e o PE recebem o tráfego para o c (S, G) na relação do tunnel0 (mas agora dos dados MDT, não do padrão MDT) e no mecanismo da afirmação retrocede dentro. Somente o PE2 continua a enviar o c (S, G) tráfego em seus dados MDT:

PE1#
PIM(1): Send v2 Assert on Tunnel0 for 232.1.1.1, source 10.100.1.6, metric [110/11]
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
MRT(1): not RPF interface, source address 10.100.1.6, group address 232.1.1.1
PIM(1): Received v2 Assert on Tunnel0 from 10.100.1.2
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PIM(1): We lose, our metric [110/11]
PIM(1): Prune Tunnel0/232.11.11.0 from (10.100.1.6/32, 232.1.1.1)
MRT(1): Delete Tunnel0/232.11.11.0 from the olist of (10.100.1.6, 232.1.1.1)
MRT(1): Reset the PIM interest flag for (10.100.1.6, 232.1.1.1)
PIM(1): MDT Tunnel0 removed from (10.100.1.6,232.1.1.1)
MRT(1): Reset the y-flag for (10.100.1.6,232.1.1.1)
PIM(1): MDT next_hop change from: 232.11.11.0 to 232.10.10.10 for (10.100.1.6, 232.1.1.1) Tunnel0
MRT(1): set min mtu for (10.100.1.6, 232.1.1.1) 1500->18010 - deleted
PIM(1): MDT threshold dropped for (10.100.1.6,232.1.1.1)
PIM(1): Receive MDT Packet (9889) from 10.100.1.2 (Tunnel0), length (ip: 44, udp: 24), ttl: 1
PIM(1): TLV type: 1 length: 16 MDT Packet length: 16
PE2#
PIM(1): Received v2 Assert on Tunnel0 from 10.100.1.1
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PIM(1): We win, our metric [110/11]
PIM(1): (10.100.1.6/32, 232.1.1.1) oif Tunnel0 in Forward state
PIM(1): Send v2 Assert on Tunnel0 for 232.1.1.1, source 10.100.1.6, metric [110/11]
PIM(1): Assert metric to source 10.100.1.6 is [110/11]
PE2#
PIM(1): Received v2 Join/Prune on Tunnel0 from 10.100.1.3, to us
PIM(1): Join-list: (10.100.1.6/32, 232.1.1.1), S-bit set
PIM(1): Update Tunnel0/10.100.1.3 to (10.100.1.6, 232.1.1.1), Forward state, by PIM SG Join
MRT(1): Update Tunnel0/232.10.10.10 in the olist of (10.100.1.6, 232.1.1.1), Forward state - MAC built
MRT(1): Set the y-flag for (10.100.1.6,232.1.1.1)
PIM(1): MDT next_hop change from: 232.10.10.10 to 232.11.11.0 for (10.100.1.6, 232.1.1.1) Tunnel0

O PE1 já não tem a interface de túnel no ÓLEO.

PE1#show ip mroute vrf one 232.1.1.1 10.100.1.6 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:10:23/00:00:04, flags: sPT
  Incoming interface: Ethernet0/0, RPF nbr 10.2.1.6
  Outgoing interface list: Null

O PE2 tem a Um-bandeira ajustada na relação do tunnel0:

PE2#show ip mroute vrf one 232.1.1.1 10.100.1.6 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 00:10:00/00:02:48, flags: sTy
  Incoming interface: Ethernet1/0, RPF nbr 10.2.2.6
  Outgoing interface list:
    Tunnel0, Forward/Sparse, 00:08:40/00:02:48, A

Conclusão

O mecanismo da afirmação igualmente trabalha quando os dados MDT são usados. Afirma estão trocados sobre o padrão MDT quando os roteadores de PE do ingresso recebem c (S, G) tráfego multicast na interface de túnel associada que está no ÓLEO.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 118986