En este ejemplo tenemos un switch de FR simulando un ISP, que nos provee los siguientes circuitos:
del puerto 0 con dlci 101 al puerto 1 con dlci 202
del puerto 0 con dlci 102 al puerto 2 con dlci 203
Nótese que el puerto 0 cuenta con 2 DLCI, por lo que se trata de una interface multipunto.
La configuración consiste en fijar la encapsulación como Frame-Relay, con un tipo de lmi ANSI para este caso, y algo muy importante, hacemos el mapeo del circuito físico local a la IP remota, para el caso de R1 hice el mapeo de un DLCI a la IP local para poder hacer ping a la interface serial, como podemos ver en la validación, el ping es exitoso. Se agrega la instrucción broadcast para que la interface soporte el multicast de EIGRP y se formen las adyacencias.
En el caso de R2 no existe el mapeo de la IP local, por lo que el ping a su propia interface no es exitoso. Existe el mapeo del DLCI local a la IP de R1 indicando que soporta broadcast y el mapeo a R3 sin esta indicación, esto es importante porque para llegar a R3 pasamos por R1 y el tráfico de multicast no es reenviado pro R1 hacia R3, por lo que no habría un correcto funcionamiento si utilizamos la indicación de broadcast.
La lógica de funcionamiento es similar a los túneles generados en el ejemplo de DMVPN, donde se mapea el tráfico multicast a la interface física, y se debe indicar el modo de funcionamiento de la interface (broadcast, non-broadcast, point-to-point. point-to-multipoint). Otra solución es hacer subinterfaces, pero implica un manejo lógico de dos interfaces distintas con diferente IP que carece del problema de split-horizon, y que utilizaría diferentes segmentos de red; en este ejemplo las 3 interfaces están en el misma red.
Este laboratorio ejecuta EIGRP, que sabemos que no puede regresar anuncios de rutas por la misma interface por la que llegan, así que en este caso especial deshabilitamos la regla de split-horizon para que las rutas aprendidas de R3 puedan ser enviadas por R1 a R2, y viceversa.
Ahora, las configuraciones de ejemplo:
