IP : Multidifusión

Fuente y datos dual-homed MDT en el mVPN

13 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (15 Junio 2015) | Comentarios

Introducción

Este documento describe el mVPN (Red proveedora virtual del Multicast) con la fuente y los datos dirigidos duales MDT (árbol de distribución del Multicast). Un ejemplo en el ® del Cisco IOS se utiliza para ilustrar el comportamiento.

Contribuido por Lucas De Ghein, ingeniero de Cisco TAC.

El problema

Si una fuente en el mundo del mVPN es dual dirigida a dos Routers del borde del proveedor del ingreso (PE), podría ser posible para el dos Routers del ingreso PE a ambos tráfico delantero para uno (S, G) en la nube del Multiprotocol Label Switching (MPLS). Esto es posible si, por ejemplo, hay dos Routers y cada reenvío de trayecto inverso (RPF) de la salida PE a un diverso router del ingreso PE. Si ambo Routers del ingreso PE adelante sobre el valor por defecto MDT, entonces el mecanismo de la afirmación golpea con el pie adentro y un ingreso PE gana el mecanismo de la afirmación y el otro pierde de modo que un y solamente un ingreso PE continúe remitiendo al cliente (c) (S, G) sobre el MDT. Sin embargo, si por cualquier motivo el mecanismo de la afirmación no comenzó en el valor por defecto MDT, después es posible que ambo Routers del ingreso PE comience a transmitir la c (S, G) tráfico Multicast sobre un DATA-MDT que él inicia. Porque el tráfico está no en el valor por defecto MDT más, sino en los datos MDT, ambo Routers del ingreso PE no recibe la c (S, G) tráfico de uno a en la interfaz MDT/Tunnel. Esto puede causar el tráfico duplicado persistente rio abajo. Este documento explica la solución a este problema.

Afirme el mecanismo en el valor por defecto MDT

La información en esta sección es verdad para el valor por defecto MDT, sin importar el protocolo de árbol de la base. El protocolo de árbol elegido de la base es la multidifusión independiente de protocolo (PIM).

El Cisco IOS se utiliza para los ejemplos, pero todo se menciona que solicita igualmente el Cisco IOS XR. Todos los grupos de multidifusión usados son grupos del Source Specific Multicast (SSM).

Mire el cuadro 1. Dual-Homed-Source-1. Hay dos Routers del ingreso PE (PE1 y PE2) y dos Routers de la salida PE (PE3 y PE4). La fuente está en el CE1 con la dirección IP 10.100.1.6. El CE1 es dual dirigido al PE1 y al PE2.


Cuadro 1. Dual-Homed-Source-1

La configuración en todo el Routers PE (el Route Distinguisher (RD) puede ser diferente en el Routers PE) es:

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
!

Para conseguir a ambo Routers del ingreso PE comenzar a remitir la secuencia de multidifusión (10.100.1.6,232.1.1.1) hacia fuera sobre el valor por defecto MDT, él debe ambos recibir un unir a de una salida PE. Mire la topología en Figure1. Dual-Homed-Source-1. Usted puede ver que por abandono, si todos los costes de los links del borde son lo mismo y todos los costes de los links de la base son lo mismo, después PE3 RPF hacia el PE1 y PE4 RPF hacia el PE2 para (10.100.1.6,232.1.1.1). Ellos ambos RPF a su ingreso más cercano PE. Esta salida confirma esto:

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 tiene RPF al 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 tiene RPF al PE2. La razón que PE3 escoge el PE1 pues el vecino RPF es que la ruta del unicast hacia 10.100.1.6/32 en el ruteo virtual/la expedición (VRF) uno es el mejor vía el PE1. PE3 recibe realmente la ruta 10.100.1.6/32 del PE1 y del PE2. Todos los criterios en el algoritmo del cálculo del mejor trayecto del Border Gateway Protocol (BGP) son lo mismo, a excepción del coste hacia la dirección del salto siguiente 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

El mejor trayecto elegido por PE3 es la trayectoria de divulgación por el PE1 porque ése tiene el coste más bajo del Interior Gateway Protocol (IGP) (11), contra el IGP costado (21) hacia el PE2. Para PE4 es el revés. La topología revela que de PE3 al PE1 hay solamente un salto, mientras que de PE3 al PE2 hay dos saltos. Puesto que todos los links tienen el mismo coste IGP, PE3 escoge la trayectoria del PE1 como el mejor.

La base de información del ruteo multicast (MRIB) para (10.100.1.6,232.1.1.1) parece esto en el PE1 y el PE2 cuando hay tráfico del no multicast con todo:

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

El PE1 y el PE2 ambos recibieron un PIM se unen a para (10.100.1.6,232.1.1.1). La interfaz del tunnel0 está en la lista de interfaz de salida (ACEITE) para la entrada de multidifusión en ambo Routers.

El comienzo del tráfico Multicast a fluir para (10.100.1.6,232.1.1.1). “El vrf uno 232.1.1.1 del pim del IP del debug” y “el vrf uno 232.1.1.1 del mrouting del IP del debug” nos muestran que la llegada del tráfico Multicast sobre el tunnel0 (en el ACEITE) de ambo Routers del ingreso PE, hace el mecanismo de la afirmación ejecutarse.

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

Si el métrico y la distancia es lo mismo de ambo Routers hacia la fuente 10.100.1.6, después hay cortacircuítos del lazo para determinar al ganador de la afirmación. Los cortacircuítos del lazo son la dirección IP más alta del vecino del PIM en el tunnel0 (MDT predeterminado). En este caso, éste es 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

El tunnel0 quitado PE1 del ACEITE de la entrada de multidifusión debido a afirma. Puesto que el ACEITE llegó a estar vacío, se poda la entrada de multidifusión.

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

El PE2 tiene el Uno-indicador fijado en el tunnel0 de la interfaz, porque es el ganador de la afirmación.

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

El PE2 envía periódicamente una afirmación en el tunnel0 (MDT predeterminado), momentos antes del temporizador de la afirmación expira. Como tal PE2 sigue siendo el ganador de la afirmación.

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]

Conclusión

El mecanismo de la afirmación también trabaja con una interfaz del túnel en el ACEITE. Afirma se intercambian sobre el valor por defecto MDT cuando el Routers del ingreso PE recibe c (S, G) tráfico Multicast en la interfaz del túnel asociada que está en el ACEITE.

Afirme el mecanismo con los datos MDT

La mayor parte del tiempo cuando se configuran los datos MDT, el mecanismo de la afirmación todavía se ejecutará en el valor por defecto MDT como la c (S, G) tráfico se conmuta solamente encima del valor por defecto MDT a los datos MDT después de tres segundos. Entonces lo mismo ocurre según lo descrito previamente. Observe que hay solamente una interfaz del túnel por el VRF habilitado para multicast: el valor por defecto MDT y todos los datos MDT utilizan una interfaz del túnel solamente. Esta interfaz del túnel se utiliza en el ACEITE en el Routers del ingreso PE o como interfaz RPF en el Routers de la salida PE.

Es en algunos casos posible que el mecanismo de la afirmación no está accionado antes de que se señalen los datos MDT. Entonces es posible que la c (S, G) tráfico Multicast comienza a ser remitido en los datos MDT sobre el Routers PE1 del ingreso PE y el PE2. En estos casos, esto podría llevar al duplicado c (S de la permanente, G) tráfico Multicast a través de la red del núcleo MPLS. Para evitar esto, esta solución fue implementada: cuando un router del ingreso PE ve a otro router del ingreso PE anunciar los datos MDT para las cuales el router PE es también un router del ingreso PE, se une a esos datos MDT. En principio, solamente el Routers de la salida PE (que tiene un receptor descendente) se uniría a los datos MDT. Porque el Routers del ingreso PE se une a los datos MDT anunciados por el otro Routers del ingreso PE, lleva al router del ingreso PE que recibe el tráfico Multicast de la interfaz del túnel que está presente en el ACEITE, y por lo tanto ésta acciona el mecanismo de la afirmación y lleva a uno del Routers del ingreso PE para parar el remitir de la c (S, G) tráfico Multicast sobre sus datos MDT (con la interfaz del túnel), mientras que el otro ingreso PE (el ganador de la afirmación) puede continuar remitiendo la c (S, G) tráfico Multicast sobre sus datos MDT.

Para el próximo ejemplo, asuma que el Routers PE1 y PE2 del ingreso PE nunca vio la c (S, G) tráfico Multicast de uno a en el valor por defecto MDT. El tráfico está en el valor por defecto MDT por solamente tres segundos y no es difícil entender que éste puede ocurrir si hay, por ejemplo, pérdida de tráfico temporal en la red del núcleo.

La configuración para los datos MDT se agrega a todo el Routers PE. La configuración en todo el Routers PE (el RD puede ser diferente en el Routers PE) es:

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
!

Tan pronto como el PE1 y el PE2 vean el tráfico de la fuente, crean el A.C. - (S, G) entrada. Ambo Routers del ingreso PE remite la c (S, G) tráfico Multicast sobre el valor por defecto MDT. El Routers PE3 y PE4 de la salida PE recibe el tráfico Multicast y lo remite. Debido a un problema temporal, el PE2 no ve el tráfico del PE1 y viceversa en el valor por defecto MDT. Que ambos envían los datos MDT se unen al Type Length Value (TLV) hacia fuera en el valor por defecto MDT.

Si no hay c (S, G) tráfico, usted ve este estado del Multicast en el Routers del ingreso PE:

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

El y-indicador todavía no se fija. Ambo Routers del ingreso PE tiene la interfaz del tunnel0 en el ACEITE. Esto es debido al hecho de que PE3 tiene RPF hacia el PE1 y PE4 tiene RPF hacia el PE2 para c (S, G).

Cuando tráfico Multicast para la c (S, G) comienza a fluir, PE1 y PE2 adelante el tráfico. El umbral para datos MDT se cruza en el Routers del ingreso PE y ambos envían los datos MDT se unen al TLV y después de la expedición del comienzo de tres segundos sobre sus datos MDT. Note que el PE1 se une a los datos que origina MDT por el PE2 y el PE2 se une a los datos que origina MDT por el 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

El PE1 y el PE reciben el tráfico para la c (S, G) en la interfaz del tunnel0 (pero ahora de los datos MDT, no del valor por defecto MDT) y el mecanismo de la afirmación golpea con el pie adentro. Solamente el PE2 continúa remitiendo la c (S, G) tráfico en sus datos 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

El PE1 tiene no más la interfaz del túnel en el ACEITE.

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

El PE2 tiene el Uno-indicador fijado en la interfaz del 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

Conclusión

El mecanismo de la afirmación también trabaja cuando se utilizan los datos MDT. Afirma se intercambian sobre el valor por defecto MDT cuando el Routers del ingreso PE recibe c (S, G) tráfico Multicast en la interfaz del túnel asociada que está en el ACEITE.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 118986