Reflexión del servicio de multidifusión usando PIM-SM en IOS-XE : Multidifusión a unidifusión
Contenido
Introducción
El propósito de este artículo es proporcionarle una comprensión del funcionamiento básico de MSR (Multicast Service Replication) usando plataformas IOS-XE, a través de la forma de una guía de laboratorio de configuración.
Prerequisites
Requirements
Comprensión básica de PIM-SM
Componentes Utilizados
ASR1000 (R2&R4), ISR4300 (R3), ISR2900 (R1&R5)
Configurar
A continuación mostraríamos configuraciones integrales basadas en el siguiente escenario diagramático para traducir la multidifusión.
Diagrama de la red
Configuraciones
En el diagrama anterior, el nodo R1 actúa como el receptor que se supone que sólo obtiene la fuente de datos de multidifusión de unidifusión del origen de multidifusión.
El nodo R5 actúa como el origen de multidifusión que genera tráfico ICMP de multidifusión originado en su interfaz de loopback 0.
El nodo R2 está bajo el dominio de núcleo multicast de los proveedores de contenido y ejecuta PIM-SM con la capa subyacente de OSPF.
El nodo R3 actúa como el router que ejecuta la aplicación de replicación de servicio multidifusión y es, en este caso, el router de borde multidifusión desde el cual se supone que el tráfico de datos multidifusión se traduce en un paquete de datos de unidifusión hacia el receptor. Utiliza OSPF y EIGRP con el proveedor de contenido e ISP respectivamente y aloja el RP (punto Rendezvouz) en su interfaz de loopback en el dominio de núcleo de multidifusión.
El nodo R4 está bajo el control de núcleo del ISP y no está habilitado para multidifusión y solo entiende cómo alcanzar el nodo R3 usando el ruteo EIGRP subyacente.
A continuación, puede encontrar las configuraciones relevantes presentes en los nodos presentes en el diagrama de topología anterior :
R1:
!
no ip domain lookup
ip cef
no ipv6 cef
!
interface GigabitEthernet0/2
ip address 10.10.20.1 255.255.255.0
duplex auto
speed auto
end
!
router eigrp 100
network 10.10.20.0 0.0.0.255
!R2:
!
interface GigabitEthernet0/0/0
ip address 10.10.20.2 255.255.255.0
negotiation auto
!
interface GigabitEthernet0/0/2
ip address 10.10.10.1 255.255.255.0
negotiation auto
!
router eigrp 100
network 10.10.10.0 0.0.0.255
network 10.10.20.0 0.0.0.255
!R3:
!
ip multicast-routing distributed
!
interface Loopback0
ip address 192.168.2.1 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface GigabitEthernet0/0/0
ip address 192.168.30.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet0/0/1
ip address 10.10.10.2 255.255.255.0
negotiation auto
!
interface Vif1
ip address 192.169.169.1 255.255.255.0
ip pim sparse-mode
ip service reflect GigabitEthernet0/0/0 destination 224.1.1.0 to 10.10.20.0 mask-len 24 source 192.169.169.169 <<<<
ip igmp static-group 224.1.1.1
ip ospf 1 area 0
!
router eigrp 100
network 10.10.10.0 0.0.0.255
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!R4:
!
ip multicast-routing distributed
!
interface GigabitEthernet0/0/0
ip address 192.168.30.2 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet0/0/2
ip address 192.168.20.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!R5:
!
ip multicast-routing
ip cef
no ipv6 cef
!
interface Loopback0
ip address 192.168.168.168 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface GigabitEthernet0/2
ip address 192.168.20.2 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!Verificación
Podemos validar las configuraciones realizando un ping de prueba para simular el tráfico multicast del router R5 con un origen de su interfaz loopback 0 [192.168.168.168] destinado a la dirección multicast 224.1.1.1. Luego verifique las entradas mroute en el nodo que está ejecutando la aplicación MSR, es decir, R3 :
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
.............................R3#sh ip mroute 224.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, c - PFP-SA cache created entry
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:47:41/stopped, RP 192.168.2.1, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vif1, Forward/Sparse, 00:46:36/00:01:23 <<<<
(192.168.168.168, 224.1.1.1), 00:00:20/00:02:43, flags: T
Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.30.2
Outgoing interface list:
Vif1, Forward/Sparse, 00:00:20/00:02:39 <<<<R3#sh ip mroute 224.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 2938 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: 224.1.1.1, Source count: 1, Packets forwarded: 1455, Packets received: 1458 <<<<
RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
Source: 192.168.168.168/32, Forwarding: 1454/1/113/0, Other: 1457/3/0
R3#sh ip mroute 224.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 2938 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: 224.1.1.1, Source count: 1, Packets forwarded: 1465, Packets received: 1468 <<<<
RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
Source: 192.168.168.168/32, Forwarding: 1464/1/113/0, Other: 1467/3/0Además, puede tomar capturas para verificar que los paquetes efectivamente se están traduciendo a la dirección de destino de unidifusión deseada en el nodo R2 mediante el uso de la función EPC (Captura de paquetes incorporada) en el router IOS-XE :
R2#mon cap TAC int gi 0/0/2 both match any
R2#mon cap TAC buff siz 50 circular
R2#mon cap TAC start
Started capture point : TAC
R2#
*Aug 12 06:50:40.195: %BUFCAP-6-ENABLE: Capture Point TAC enabled.
R2#sh mon cap TAC buff br | i ICMP
6 114 10.684022 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
7 114 10.684022 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
8 114 12.683015 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
9 114 12.683015 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<Aquí, el punto importante a tener en cuenta es que regularmente cuando realiza pings de ICMP multicast en "entornos de laboratorio", generalmente esperaría que reciba nuevamente los paquetes de respuesta de eco ICMP desde el lado del receptor hacia el origen, suponiendo que haya una disponibilidad completa entre los dos (origen y receptor). Sin embargo, en este escenario es importante tener en cuenta que incluso si tratamos de anunciar la dirección de origen NATted para los paquetes ICMP multicast, es decir, 192.169.169.169 hasta el final hasta el receptor, es decir, R1 a través de EIGRP, aún las respuestas de eco ICMP unicast no cruzarán el router R3, ya que la NAT inversa no está configurada en el nodo de aplicación MSR. Podemos probar esto, al intentar realizar el anuncio de ruta EIGRP de la interfaz Vif 1 en R3 en EIGRP (ruteo de núcleo ISP) :
ISR4351(config)#router eigrp 100
ISR4351(config-router)#network 192.169.169.0 0.0.0.255 <<<<Ahora, podemos verificar las capturas tomadas en el nodo R2 en las respuestas de eco ICMP que se envían hacia R3 :
R2#sh mon cap TAC buff br | i ICMP
249 114 317.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
250 114 317.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
251 114 317.847948 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
252 114 317.847948 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
253 114 319.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
254 114 319.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
255 114 319.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
256 114 319.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
259 114 321.848955 192.169.169.169 -> 10.10.20.1 0 BE ICMP
260 114 321.848955 192.169.169.169 -> 10.10.20.1 0 BE ICMP
261 114 321.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
262 114 321.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<< Pero los pings aún fallarían como se ve en el origen R5 :
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................
......................................................................
Ahora para que las respuestas lleguen hasta el origen, podemos configurar el reenvío de puertos NAT en el nodo de aplicación MSR R3 para traducir el tráfico destinado hacia 192.169.169.169 a 192.168.168.168, configurando NAT extensible :
R3(config)#int gi 0/0/1
R3(config-if)#ip nat out
R3(config-if)#int gi 0/0/0
R3(config-if)#ip nat ins
R3(config-if)#exit
R3(config)#ip nat inside source static 192.168.168.168 192.169.169.169 extendable <<<<Ahora, al verificar el nodo R5 de origen, podemos ver que la respuesta regresa :
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................
Reply to request 716 from 10.10.20.1, 1 ms
Reply to request 716 from 10.10.20.1, 1 ms
Reply to request 717 from 10.10.20.1, 1 ms
Reply to request 717 from 10.10.20.1, 1 ms
Reply to request 718 from 10.10.20.1, 1 ms
Reply to request 718 from 10.10.20.1, 1 ms Lo anterior se realizó simplemente para explicar el flujo de paquetes y para entender cómo establecer el trayecto/flujo de unidifusión inverso para el tráfico de datos y el tráfico de multidifusión descendente. Dado que en el escenario de producción regular, normalmente no se encontraría con casos/instancias donde las aplicaciones multicast que se ejecutan en el lado del servidor/origen requieren un reconocimiento inverso de los paquetes de los receptores en una forma de unidifusión.
Con las pruebas y validaciones anteriores, debería haber proporcionado una breve descripción general sobre cómo ejecutar la aplicación de replicación de servicios de multidifusión en uno de los nodos de borde de multidifusión y cómo implementar lo mismo si lo mismo que se muestra anteriormente se expandiera a una implementación a gran escala.
Comentarios