IP : Multidifusión

Estricto revisión de "RPF" para el mVPN

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe la característica estricta del reenvío de trayecto inverso (RPF) para el Multicast sobre VPN (mVPN). Este documento utiliza un ejemplo y la implementación en el ® del Cisco IOS para ilustrar el comportamiento.

Contribuido por Lucas De Ghein, ingeniero de Cisco TAC.

Antecedentes

El RPF implica que la interfaz entrante está marcada hacia la fuente. Aunque la interfaz se marque para determinar que es la correcta hacia la fuente, no se marca para determinar que es el vecino RPF correcto en esa interfaz. En una interfaz multiaccesa, podría haber más de un vecino a quien usted podría RPF. El resultado podría ser que el router recibe dos veces la misma secuencia de multidifusión en esa interfaz y adelante ambas.

En las redes adonde la multidifusión independiente de protocolo (PIM) se ejecuta en la interfaz multiaccesa, esto no es un problema, porque la secuencia de multidifusión duplicado hace el mecanismo de la afirmación ejecutarse y una secuencia de multidifusión será recibida no más. En algunos casos, el PIM no se ejecuta en el árbol de distribución del Multicast (MDT), que es una interfaz multiaccesa. En esos casos, el Border Gateway Protocol (BGP) es el Signaling Protocol del recubrimiento.

En los perfiles con el MDT dividido, incluso si el PIM se ejecuta como el protocolo del recubrimiento, puede ser imposible tener afirma. La razón de esto es que un borde del proveedor del ingreso (PE) no se une al MDT dividido de otro ingreso PE en los escenarios donde hay dos o más Routers del ingreso PE. Cada router del ingreso PE puede remitir la secuencia de multidifusión sobre su MDT dividido sin el otro router del ingreso PE que ve el tráfico Multicast. El hecho de que dos diverso Routers cada uno de la salida PE se una a un MDT hacia un diverso router del ingreso PE para la misma secuencia de multidifusión es un escenario válido: se llama Anycast Source. Esto permite que diversos receptores se unan a la misma secuencia de multidifusión pero sobre una diversa trayectoria en la base del Multiprotocol Label Switching (MPLS). Véase el cuadro 1 para un ejemplo de la fuente del Anycast.

Figura 1

Hay dos Routers del ingreso PE: PE1 y PE2. Hay dos Routers de la salida PE: PE3 y PE4. Cada router de la salida PE tiene un diverso router del ingreso PE como su vecino RPF. PE3 tiene PE1 como su vecino RPF. PE4 tiene PE2 como su vecino RPF. El Routers de la salida PE escoge a su router más cercano del ingreso PE como su vecino RPF.

La secuencia (S1,G) irá del s1 al receptor 1 sobre la trayectoria superior y del s1 al receptor 2 sobre la trayectoria inferior. No hay intersección de las dos secuencias sobre las dos trayectorias (cada trayectoria en la base MPLS es un diverso MDT dividido).

Si el MDT fuera un valor por defecto MDT - tal como adentro adentro los perfiles del valor por defecto MDT - entonces éste no trabajaría porque las dos secuencias de multidifusión estarían en el mismo valor por defecto MDT y el mecanismo de la afirmación se ejecutaría. Si el MDT es los datos MDT en los perfiles del valor por defecto MDT, después todo el Routers del ingreso PE se une a los datos MDT del otro Routers del ingreso PE y como tal ve el tráfico Multicast de uno a y del mecanismo de la afirmación se ejecuta otra vez. Si el protocolo del recubrimiento es BGP, después hay selección por aguas arriba del salto del Multicast (UMH) y seleccionan a solamente un router del ingreso PE como el promotor, pero éste está por el MDT.

La fuente del Anycast es una de las ventajas grandes de ejecutar el MDT dividido.

Problema

El asiduo revisión de "RPF" confirma que los paquetes llegan el router de la interfaz correcta RPF. No hay control para confirmar que los paquetes están recibidos del vecino RPF correcto en esa interfaz.

Véase el cuadro 2. Muestra a problema adonde el tráfico del duplicado se remite persistente en un escenario con el MDT dividido. Muestra que el asiduo revisión de "RPF" en el caso del MDT dividido no es suficiente para evitar el tráfico duplicado.

Figura 2

Hay dos receptores. El primer receptor se configura para recibir el tráfico para (S1,G) y (S2,G). El segundo receptor se configura para recibir el tráfico para (S2,G) solamente. Hay MDT dividido, y el BGP es el Signaling Protocol del recubrimiento. Observe que el s1 de la fuente es accesible vía el PE1 y el PE2. El protocolo del memoria-árbol es Label Distribution Protocol de múltiples puntos (mLDP).

Cada router PE hace publicidad de una ruta del mVPN del IPv4 del tipo 1 BGP, que indica que es un candidato a ser la raíz de un MDT dividido.

PE3#show bgp ipv4 mvpn vrf one              
BGP table version is 257, local router ID is 10.100.1.3
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-pah, c RIB-compressed,
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:3 (default for vrf one)
*>i [1][1:3][10.100.1.1]/12
                      10.100.1.1               0   100     0 ?
*>i [1][1:3][10.100.1.2]/12
                       10.100.1.2               0   100     0 ?
*> [1][1:3][10.100.1.3]/12
                       0.0.0.0                           32768 ?
*>i [1][1:3][10.100.1.4]/12
                       10.100.1.4               0   100     0 ?

PE3 encuentra el PE1 como el vecino RPF para el s1 después de que las operaciones de búsqueda para la ruta del unicast para el s1.

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 16
Paths: (2 available, best #2, table one)
Advertised to update-groups:
     5       
Refresh Epoch 2
65001, 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 0, localpref 100, valid, internal
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/20
     rx pathid: 0, tx pathid: 0
Refresh Epoch 2
65001, 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 0, localpref 100, valid, internal, best
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.1:1
     Originator: 10.100.1.1, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0x0
PE3#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
RPF interface: Lspvif0
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
RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE3 selecciona el PE1 como el vecino RPF para (S1,G) y se une al MDT dividido con el PE1 como raíz. PE3 selecciona el PE2 como el vecino RPF para (S2,G) y se une al MDT dividido con el PE2 como raíz.

PE3#show bgp vpnv4 unicast vrf one 10.100.1.7/32
BGP routing table entry for 1:3:10.100.1.7/32, version 18
Paths: (1 available, best #1, table one)
Advertised to update-groups:
     6       
Refresh Epoch 2
65002, imported path from 1:2:10.100.1.7/32 (global)
     10.100.1.2 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal, best
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0x0
PE3#show ip rpf vrf one 10.100.1.7
RPF information for ? (10.100.1.7)
RPF interface: Lspvif0
RPF neighbor: ? (10.100.1.2)
RPF route/mask: 10.100.1.7/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE4 selecciona el PE2 como el vecino RPF para (S1,G) y se une al MDT dividido con el PE1 como raíz.

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 138
Paths: (2 available, best #1, table one)
Advertised to update-groups:
     2       
Refresh Epoch 2
65001, 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 0, localpref 100, valid, internal, best
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/20
     rx pathid: 0, tx pathid: 0x0
Refresh Epoch 2
65001, 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 0, localpref 100, valid, internal
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.1:1
     Originator: 10.100.1.1, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0
PE4#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
RPF interface: Lspvif0
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
RPF topology: ipv4 multicast base, originated from ipv4 unicast base

Note que la interfaz RPF es Lspvif0 para el s1 (10.100.1.6) y el s2 (10.100.1.7).

PE3 se une al MDT dividido del PE2 para (S2,G), y PE4 se une al MDT dividido del PE2 para (S1,G). El PE1 se une al MDT dividido del PE1 para (S1,G). Usted puede ver esto por las rutas del mVPN del IPv4 del tipo 7 BGP recibidas en el PE1 y el PE2.

PE1#show bgp ipv4 mvpn vrf one
BGP table version is 302, local router ID is 10.100.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,
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 (default for vrf one)
*>i [7][1:1][1][10.100.1.6/32][232.1.1.1/32]/22
                       10.100.1.3               0   100     0 ?
PE2#show bgp ipv4 mvpn vrf one
BGP table version is 329, local router ID is 10.100.1.2
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,
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:2 (default for vrf one)
*>i [7][1:2][1][10.100.1.6/32][232.1.1.1/32]/22
                       10.100.1.4               0   100     0 ?
*>i [7][1:2][1][10.100.1.7/32][232.1.1.1/32]/22
                       10.100.1.3               0   100     0 ?

Las entradas de multidifusión en PE3 y PE4:

PE3#show ip mroute vrf one 232.1.1.1
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.7, 232.1.1.1), 21:18:24/00:02:46, flags: sTg
Incoming interface: Lspvif0, RPF nbr 10.100.1.2
Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 00:11:48/00:02:46

(10.100.1.6, 232.1.1.1), 21:18:27/00:03:17, flags: sTg
Incoming interface: Lspvif0, RPF nbr 10.100.1.1
Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 00:11:48/00:03:17
PE4#show ip mroute vrf one 232.1.1.1
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), 20:50:13/00:02:37, flags: sTg
Incoming interface: Lspvif0, RPF nbr 10.100.1.2
Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 20:50:13/00:02:37

Esto muestra que PE3 se une al árbol de la punta a de múltiples puntos (P2MP) arraigado en el PE1 y también el árbol arraigado en el PE2:

PE3#show mpls mldp database
* Indicates MLDP recursive forwarding is enabled

LSM ID : A   Type: P2MP   Uptime : 00:18:40
FEC Root           : 10.100.1.1
Opaque decoded     : [gid 65536 (0x00010000)]
Opaque length     : 4 bytes
Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.1:0   [Active]
     Expires       : Never         Path Set ID : A
     Out Label (U) : None         Interface   : Ethernet5/0*
     Local Label (D): 29           Next Hop     : 10.1.5.1
Replication client(s):
   MDT (VRF one)
     Uptime         : 00:18:40     Path Set ID : None
     Interface     : Lspvif0      

LSM ID : B   Type: P2MP   Uptime : 00:18:40
FEC Root           : 10.100.1.2
Opaque decoded     : [gid 65536 (0x00010000)]
Opaque length     : 4 bytes
Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.5:0  [Active]
     Expires       : Never         Path Set ID : B
     Out Label (U) : None         Interface   : Ethernet6/0*
     Local Label (D): 30           Next Hop     : 10.1.3.5
Replication client(s):
   MDT (VRF one)
     Uptime       : 00:18:40     Path Set ID : None
     Interface     : Lspvif0      

Esto muestra que PE4 se une al árbol P2MP arraigado en el PE2:

PE4#show mpls mldp database      
* Indicates MLDP recursive forwarding is enabled

LSM ID : 3   Type: P2MP   Uptime : 21:17:06
FEC Root           : 10.100.1.2
Opaque decoded     : [gid 65536 (0x00010000)]

Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.2:0   [Active]
     Expires       : Never         Path Set ID : 3
     Out Label (U) : None         Interface   : Ethernet5/0*
     Local Label (D): 29           Next Hop     : 10.1.6.2
Replication client(s):
   MDT (VRF one)
     Uptime         : 21:17:06     Path Set ID : None
     Interface     : Lspvif0      

El s1 y el s2 fluyen para el grupo 232.1.1.1 con 10 pps. Usted puede ver las secuencias en PE3 y PE4. Sin embargo, en PE3, usted puede ver la tarifa para (S1,G) como 20 pps.

PE3#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
3 routes using 1692 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 232.1.1.1, Source count: 2, Packets forwarded: 1399687, Packets received:
2071455
Source: 10.100.1.7/32, Forwarding: 691517/10/28/2, Other: 691517/0/0
Source: 10.100.1.6/32, Forwarding: 708170/20/28/4, Other: 1379938/671768/0
PE4#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
2 routes using 1246 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 232.1.1.1, Source count: 1, Packets forwarded: 688820, Packets received:
688820
Source: 10.100.1.6/32, Forwarding: 688820/10/28/2, Other: 688820/0/0
PE3#show interfaces ethernet0/0 | include rate
Queueing strategy: fifo
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 9000 bits/sec, 30 packets/sec

Hay una secuencia duplicado. Esta duplicación es el resultado de la presencia de la secuencia (S1,G) en el MDT dividido del PE1 y en el MDT dividido del PE2. Este MDT dividido segundo, del PE2, fue unido a por PE3 para conseguir la secuencia (S2,G). Pero, porque PE4 se unió al MDT dividido del PE2 para conseguir (S1,G), (S1,G) está también presente en el MDT dividido del PE2. Por lo tanto, PE3 recibe la secuencia (S1,G) de ambos MDT divididos que se unió a.

PE3 no puede discriminar entre los paquetes para (S1,G) él recibe del PE1 y del PE2. Ambas secuencias se reciben en la interfaz correcta RPF: Lspvif0.

PE3#show ip multicast vrf one mpls vif

Interface   Next-hop            Application     Ref-Count   Table / VRF name   Flags
Lspvif0     0.0.0.0             MDT               N/A       1   (vrf one) 0x1

Los paquetes podían llegar en diversas interfaces físicas entrantes en PE3 o en la misma interfaz. En todo caso, los paquetes de las diversas secuencias para (S1,G) llegan con una diversa escritura de la etiqueta MPLS PE3:

PE3#show mpls forwarding-table vrf one
Local     Outgoing   Prefix           Bytes Label   Outgoing   Next Hop 
Label     Label     or Tunnel Id     Switched     interface           
29   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       768684       aggregate/one
30   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       1535940       aggregate/one

[T]     Forwarding through a LSP tunnel.
       View additional labelling info with the 'detail' option

Solución

La solución es tener un RPF más estricto. Con el RPF estricto, el router marca de qué vecino se reciben los paquetes en la interfaz RPF. Sin el RPF estricto, el único control es determinar si la interfaz entrante es la interfaz RPF, pero no si los paquetes se reciben del vecino RPF correcto en esa interfaz.

Notas para el Cisco IOS

Aquí están algunas NOTAS IMPORTANTES sobre el RPF con el Cisco IOS.

  • Cuando usted cambia a/desde el modo estricto RPF, cualquier configuración él antes de que usted configure el MDT dividido o el BGP claro. Si usted configura solamente el comando RPF estricto, no creará otra interfaz de Lspvif inmediatamente.

  • El RPF estricto no se habilita por abandono en el Cisco IOS.

  • No se soporta para tener el comando estricto-RPF con los perfiles predeterminados MDT.

Configuración

Usted puede configurar el RPF estricto en PE3 para el ruteo virtual y la expedición (VRF).

vrf definition one
rd 1:3
!
address-family ipv4
mdt auto-discovery mldp
mdt strict-rpf interface
mdt partitioned mldp p2mp
mdt overlay use-bgp
route-target export 1:1
route-target import 1:1
exit-address-family
!

La información RPF ha cambiado:

PE3#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
RPF interface: Lspvif0
Strict-RPF interface: Lspvif1
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
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
PE3#show ip rpf vrf one 10.100.1.7
RPF information for ? (10.100.1.7)
RPF interface: Lspvif0
Strict-RPF interface: Lspvif2
RPF neighbor: ? (10.100.1.2)
RPF route/mask: 10.100.1.7/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE3 creó una interfaz de Lspvif por el ingreso PE. La interfaz de Lspvif se crea por el ingreso PE, por la familia del direccionamiento (AF), y por el VRF. El RPF para 10.100.1.6 ahora señala para interconectar Lspvif1 y el RPF para 10.100.1.7 ahora señala para interconectar Lspvif2.

PE3#show ip multicast vrf one mpls vif

Interface   Next-hop           Application     Ref-Count   Table / VRF name   Flags
Lspvif0     0.0.0.0             MDT               N/A       1   (vrf one) 0x1
Lspvif1     10.100.1.1           MDT               N/A       1   (vrf one) 0x1
Lspvif2     10.100.1.2           MDT               N/A       1   (vrf one) 0x1

Ahora, revisión de "RPF" para los paquetes (S1,G) del PE1 se marcan contra la interfaz Lspvif1 RPF. Estos paquetes vienen adentro con la escritura de la etiqueta 29 MPLS. Revisión de "RPF" para los paquetes (S2,G) del PE2 se marcan contra la interfaz Lspvif2 RPF. Estos paquetes vienen adentro con la escritura de la etiqueta 30 MPLS. Las secuencias llegan en PE3 a través de diversas interfaces entrantes, pero ésta podría también ser la misma interfaz. Sin embargo, debido al hecho de que el mLDP nunca utilice el Penultimate Hop Popping (PHP), hay siempre una escritura de la etiqueta regular MPLS encima de los paquetes de multidifusión. Los paquetes (S1,G) que llegan del PE1 y del PE2 están en dos diversos MDT divididos y por lo tanto tienen una diversa escritura de la etiqueta MPLS. Por lo tanto, PE3 puede discriminar entre la secuencia (S1,G) que viene del PE1 y de la secuencia (S1,G) que viene del PE2. De esta manera, los paquetes se pueden mantener separados por PE3 y un RPF se puede realizar contra diverso Routers del ingreso PE.

La base de datos del mLDP en PE3 ahora muestra las diversas interfaces de Lspvif por el ingreso PE.

PE3#show mpls mldp database
* Indicates MLDP recursive forwarding is enabled

LSM ID : C   Type: P2MP   Uptime : 00:05:58
FEC Root           : 10.100.1.1
Opaque decoded     : [gid 65536 (0x00010000)]
Opaque length     : 4 bytes
Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.1:0   [Active]
     Expires       : Never         Path Set ID : C
     Out Label (U) : None         Interface   : Ethernet5/0*
     Local Label (D): 29           Next Hop     : 10.1.5.1
Replication client(s):
   MDT (VRF one)
     Uptime         : 00:05:58     Path Set ID : None
     Interface     : Lspvif1      

LSM ID : D   Type: P2MP   Uptime : 00:05:58
FEC Root           : 10.100.1.2
Opaque decoded     : [gid 65536 (0x00010000)]
Opaque length     : 4 bytes
Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.5:0   [Active]
     Expires       : Never         Path Set ID : D
     Out Label (U) : None         Interface   : Ethernet6/0*
     Local Label (D): 30           Next Hop     : 10.1.3.5
Replication client(s):
   MDT (VRF one)
     Uptime         : 00:05:58     Path Set ID : None
     Interface     : Lspvif2      

RPF estricto o RPF por los trabajos del ingreso PE debido al hecho de que las secuencias de multidifusión vengan adentro al ingreso PE con una diversa escritura de la etiqueta MPLS por el ingreso PE:

PE3#show mpls forwarding-table vrf one
Local     Outgoing   Prefix           Bytes Label   Outgoing   Next Hop 
Label     Label     or Tunnel Id     Switched     interface           
29   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       162708       aggregate/one
30   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       162750       aggregate/one

[T]     Forwarding through a LSP tunnel.
       View additional labelling info with the 'detail' option

La prueba que el RPF estricto trabaja es que hay no más una secuencia duplicado (S1,G) remitida en PE3. La secuencia duplicado todavía llega en PE3, pero es caído debido a la falla de RPF. La falla de RPF contador está en 676255 y los aumentos constantemente hasta una tasa de 10 pps.

PE3#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
3 routes using 1692 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 232.1.1.1, Source count: 2, Packets forwarded: 1443260, Packets received:
2119515
Source: 10.100.1.7/32, Forwarding: 707523/10/28/2, Other: 707523/0/0
Source: 10.100.1.6/32, Forwarding: 735737/10/28/2, Other: 1411992/676255/0

La velocidad de salida en PE3 ahora es 20 pps, que es 10 pps para cada secuencia (S1,G) y (S2,G):

PE3#show interfaces ethernet0/0 | include rate
Queueing strategy: fifo
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 6000 bits/sec, 20 packets/sec

Conclusión

Estricto revisión de "RPF" debe ser utilizado para los modelos de despliegue del mVPN que utilizan el MDT dividido.

Las cosas pudieron aparecer trabajar, incluso si usted no configura el estricto revisión de "RPF" para los modelos de despliegue del mVPN con el MDT dividido: las secuencias de multidifusión se entregan a los receptores. Sin embargo, hay la posibilidad que hay tráfico Multicast duplicado cuando las fuentes están conectadas con el Routers múltiple del ingreso PE. Esto lleva a una pérdida de ancho de banda en la red y puede afectar al contrario a la aplicación de multidifusión en los receptores. Por lo tanto, es una necesidad para configurar estricto revisión de "RPF" para los modelos de despliegue del mVPN que utilice el MDT dividido.



Document ID: 118677