Para conectarse a la transmisión Multicast, clic aquí

Si no consigue visualizar la transmisión, puede descargar un plugin de IP/TV. Clic aquí
Este archivo está comprimido en formato ZIP. Una vez abierto, debe ejecutar el archivo "setup.exe".

Características de las pruebas multicast

La transmisión multicast a la que se conectarán se origina en REUNA desde el servidor Cisco IP/TV. El grupo multicast escogido pertenece al rango de numeración IP multicast para transmisiones nacionales (239.0.0.0/8).

Es necesario que el router de acceso de la Universidad esté configurado apropiadamente. Para eso realice las siguientes verificaciones y/o configuraciones:

1) Esté configurado con multicast-routing (ya lo están todos).

2) Pueda llegar al router RP que maneja la creación de rutas multicast del dominio nacional.

Este router es el RCNacional y tiene la IP 146.83.240.13. Verificar con ping:

RA_Reuna#ping 146.83.240.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 146.83.240.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

3) Esté configurado el router RP.

Para esto en la configuración del router deben aparecer las siguientes configuraciones:

ip pim rp-address 146.83.240.13 Multicast-Nacional
!
ip access-list standard Multicast-Nacional
permit 239.0.0.0 0.255.255.255
!

Si no lo está, debe hacerse.

4) La interfaz del router de acceso por donde se conecta a la Universidad o por donde se quiera conectar la transmisión multicast debe estar corriendo el protocolo PIM en modo sparse.

Verificar que en la configuración aparezca lo siguiente, a modo de ejemplo usaremos la interface F0/0.

interface FastEthernet0/0
ip pim sparse-mode"
!

Si no lo está, debe hacerse. Esto es lo que dará paso al tráfico multicast a la red interna. Para cortar el paso de tráfico multicast, lo único que debería hacerse es eliminar la configuración anterior con "no ip pim sparse-mode".

5) Verificar que al menos las interfases de acceso a la Universidad y la de acceso al backbone estén corriendo PIM sparse-mode.

Usar el comando "sh ip pim interface".

RA_Reuna#sh ip pim interface

Address Interface Version/Mode Nbr
Query DR
Count Intvl
146.83.188.1 FastEthernet0/0 v2/Sparse 0 30
146.83.188.1
146.83.240.64 ATM1/0.3 v2/Sparse 14 30
146.83.240.73

6) Verificar que el router de acceso tenga vecindad PIM con el router RP (RCNacional=240.13)

RA_Reuna#sh ip pim neighbor
PIM Neighbor Table
Neighbor Address Interface Uptime Expires Ver Mode
146.83.240.56 ATM1/0.3 05:13:48 00:01:33 v2
146.83.240.59 ATM1/0.3 1d03h 00:01:22 v2
146.83.240.70 ATM1/0.3 2d04h 00:01:33 v2
146.83.240.72 ATM1/0.3 2d04h 00:01:14 v2
146.83.240.71 ATM1/0.3 2d04h 00:01:35 v2
146.83.240.58 ATM1/0.3 2d04h 00:01:37 v2
146.83.240.69 ATM1/0.3 2d04h 00:01:34 v2
146.83.240.13 ATM1/0.3 2d04h 00:01:41 v2
146.83.240.57 ATM1/0.3 2d04h 00:01:25 v2
146.83.240.55 ATM1/0.3 2d04h 00:01:38 v2
146.83.240.60 ATM1/0.3 2d04h 00:01:36 v2
146.83.240.73 ATM1/0.3 2d04h 00:01:37 v2
(DR)
146.83.240.67 ATM1/0.3 2d07h 00:01:31 v2
146.83.240.66 ATM1/0.3 2d08h 00:01:34 v2

7) Multicast y cortafuegos (firewalls)

Generalmente, el tráfico multicast es atajado por los cortafuegos a menos que tengan un soporte especial para este tipo de tráfico. Lo más probable es que no lo tenga o que sea un módulo adicional que, por lo general, se vende por separado. Además del inconveniente anterior, y dado que el rendimiento del cortafuego podría verse afectado, generalmente las soluciones multicast al interior de las redes evitan pasar por ellos.

Si en la entrada de la red del campus hay cortafuegos, verifiquen que éste permita pasar multicast. Si es posible configurar esta regla, permitan que deje pasar todo el tráfico cuya dirección destino sea 239.0.0.0 mask 255.0.0.0. Si el cortafuego no lo soporta, la única forma de probar multicast desde REUNA, es tratar de aislar un segmento de red para saltarlo.

8) Multicast y Swiches L2

El tráfico multicast es interpretado por los switches como tipo broadcast. Por tanto, y haciendo caso a los principios de bridging transparente 802.1d, este tipo de tráfico es copiado (flooding) por todas las puertas del switch, excepto por la que ingresó (filtering).

Para evitar esa inundación de tráfico por la LAN, hay dos mecanismos que el Switch podría tener incorporado y cuya existencia se debe verificar. El primero se llama IGMP Snooping y el segundo CGMP (Cisco). Se recomienda IGMP Snooping.

Generalmente, el IGMP Snooping cuando viene incorporado como "features" en los Switches, corre por defecto. CGMP es un poco más complicado de configurar y requiere de la complicidad del Router que recibe el tráfico multicast antes de entrar al dominio LAN. Es este caso, debemos ponernos de acuerdo para configurarlo. Lo más probable es que CGMP sólo corra en Switches LAN Cisco, tipo Catalyst.

Cualquier duda o apoyo que necesiten para realizar estas pruebas, nos avisan.

Gerencia Técnica REUNA

Canadá 239, Providencia, Santiago de Chile
Fono (56-2) 337 0300 Fax (56-2) 204 0865
Sitio Internet optimizado para una resolución de pantalla de 800x600 pixeles
y navegadores en versión 4 o posterior.

Diseño y Desarrollo
REUNA - Gerencia de Comunicaciones