Reflexión de servicio multidifusión con 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
ASR 1000 (R2&R4), ISR4300 (R3) e ISR2900 (R1&R5)
Configurar
A continuación, mostramos configuraciones de extremo a extremo basadas en el siguiente escenario de diagrama 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 loopback 0.
El nodo R2 se encuentra bajo el dominio de núcleo multicast de los proveedores de contenido y está ejecutando PIM-SM con la capa subyacente de OSPF.
El nodo R3 actúa como el router que ejecuta Multicast Service Replication Application y en este caso es el router de borde de multidifusión desde el cual se supone que el tráfico de datos multicast se traduce en un paquete de datos de unidifusión hacia el receptor. Utiliza OSPF y EIGRP con el Proveedor de Contenido y el ISP respectivamente y alberga el RP (Punto Rendezvouz) en su interfaz de loopback en el dominio de núcleo multicast.
El nodo R4 se encuentra bajo el control de núcleo ISP y no está habilitado para multicast y sólo entiende cómo alcanzar el nodo R3 mediante 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 tráfico multicast del router R5 con una fuente de su interfaz loopback 0 [192.168.168.168] destinada a la dirección multicast 224.1.1.1. Luego verifique las entradas de ruta multicast 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 se estén traduciendo a la dirección de destino unicast prevista en el nodo R2 mediante la función EPC (captura de paquetes integrados) 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, con regularidad, cuando realiza pings ICMP de multidifusión en "entornos de laboratorio", normalmente espera recibir de vuelta los paquetes de respuesta de eco ICMP del lado del receptor hacia el origen, suponiendo que haya disponibilidad completa entre ambos (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 que el receptor, es decir, R1 a través de EIGRP, las respuestas de eco ICMP de unidifusión no cruzarán el router R3, ya que la aplicación NAT inversa no está configurada en el MSR nodo. Podemos probar esto, tratando de realizar el anuncio de ruta EIGRP de la interfaz Vif 1 en R3 en EIGRP (routing 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 enviadas 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 seguirían fallando como se ve en la fuente 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 R 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 la respuesta de vuelta :
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ó 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 normal, normalmente no se encontraría con casos/instancias donde las aplicaciones multicast que se ejecutan en el lado servidor/origen requieren paquetes de reconocimiento inverso de los receptores en un formulario de unidifusión.
Mediante las pruebas y validaciones anteriores, debería haber dado una breve descripción general sobre cómo ejecutar la aplicación de replicación de servicios multicast en uno de los nodos de borde multicast y cómo implementar el mismo si se ampliara a una implementación a gran escala la misma que se muestra arriba.
Comentarios