On Demand Routing (ODR)

Ahora vamos a ver un protocolo de enrutamiento que es casi una curiosidad, no está muy difundido y no conozco que se tome en ninguna certificación.

Es más, solo lo vas a poder usar si:

• Todo tu equipamiento es Cisco.


• Usas CDP en tu toda red o bien sos muy vago como para desactivarlo.


• La topología lógica es Hub n' Spoke o estrella.


• Los equipos no tienen tanto CPU para lidiar con todo eso del protocolo híbrido, estado enlace o el Bellman-Ford.


• Te encantan los protocolos de enrutamiento no autenticados e inseguros.


• Tu religión no te permite un protocolo de enrutamiento con PDU de capa 3 y no querés aprender las simbologías extrañas del IS-IS integrado.


• Querés jugar o aprender un chiche nuevo para guardar en el maletín de soluciones.

Si todas o la mayoría de los ítems presentados anteriormente son afirmativos en tu caso, es hora de aprender ODR!.



On Demand Routing es un protocolo que se vale del CDP (Cisco Discovery Protocol) para propagar prefijos IP. Las tramas CDP contienen un campo para transportar 4 bytes, o sea que puede enviar la máscara por lo que soporta VLSM y su configuración es muy sencilla.

Lamentablemente sólo funciona en redes Hub & Spoke, en donde los Spokes son stub, o sea que no se conectan a ningún otro router que no sea el HUB o centro de la estrella.

Veamos un diagrama para clarificar:

 

[caption id="attachment_186" align="aligncenter" width="392" caption="Diagrama de Topología con On Demand Routing"][/caption]

Obviamente el tiempo de convergencia es horrible, ya que se el HUB se limita a esperar las tramas de CDP (que por defecto se envían cada 60 segundos) pero esto no quita que bajemos el timer de envío de CDP de cada equipo para que los anuncios se reenvíen en intervalos de tiempo más cortos.

Vamos a las configuraciones:

HUB:

HUB#sh run
Building configuration...

Current configuration : 1451 bytes
!
![...]
!
interface FastEthernet0/0
 description Enlace a LAN
 ip address 192.168.2.1 255.255.255.0
 duplex half
 no keepalive
!
interface Serial1/0
 description Enlace a Spoke1 S1/0
 bandwidth 128
 ip address 192.168.1.5 255.255.255.252
 serial restart-delay 0
!
interface Serial1/1
 description Enlace a Spoke2 S1/0
 bandwidth 128
 ip address 192.168.1.1 255.255.255.252
 serial restart-delay 0
![...]
!
router odr
!
end

SPOKE1:

SPOKE1#sh run
Building configuration...

Current configuration : 1365 bytes
!
![...]
!
interface FastEthernet0/0
 description LAN
 ip address 192.168.3.1 255.255.255.0
 duplex half
 no keepalive
!
interface Serial1/0
 description Enlace a HUB S1/0
 bandwidth 128
 ip address 192.168.1.2 255.255.255.252
 serial restart-delay 0
!
![...]
!
end

SPOKE2:

SPOKE2#sh run
Building configuration...

Current configuration : 1374 bytes
!
![...]
!
interface FastEthernet0/0
 description Enlace a LAN
 ip address 192.168.4.1 255.255.255.0
 duplex half
 no keepalive
!
interface Serial1/0
 description Enlace a HUB S1/0
 bandwidth 128
 ip address 192.168.1.6 255.255.255.252
 serial restart-delay 0
!
![...]
!
end

Difícil... ¿no?.

Solo hizo falta un comando en el router HUB. Veamos si funciona:

HUB#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

o    192.168.4.0/24 [160/1] via 192.168.1.6, 00:00:00
     192.168.1.0/30 is subnetted, 2 subnets
C       192.168.1.0 is directly connected, Serial1/1
C       192.168.1.4 is directly connected, Serial1/0
C    192.168.2.0/24 is directly connected, FastEthernet0/0
o    192.168.3.0/24 [160/1] via 192.168.1.2, 00:00:59

Notamos que a diferencia de la O mayúscula que denota OSPF, aquí vemos una o minúscula que indica ODR.

También podemos ver que los timers se resetean cada vez que llegan las tramas de CDP, por lo tanto una vez pasado los 59 segundos, vuelven a 00:00:00.

Ahora, ¿qué pasa en los Spoke?... Veamos:

SPOKE2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.1.1 to network 0.0.0.0

C    192.168.4.0/24 is directly connected, FastEthernet0/0
     192.168.1.0/30 is subnetted, 1 subnets
C       192.168.1.4 is directly connected, Serial1/0
o*   0.0.0.0/0 [160/1] via 192.168.1.1, 00:00:35

Tenemos una ruta por defecto (eso es lo que indica el *) con una distancia administrativa de 160, una métrica de 1 y aprendida por ODR.

El router spoke se comporta tal cual como si fuese un área totalmente stub de OSPF. Sólo aprende la default por ODR.

Créanme que el Spoke1 tenía aprendido lo mismo.

Ahora, ¿se pueden hacer algunas cosas interesantes con este protocolo?

¡¡Claro que si!!.

Algunas cosas son:

• Cambiar los timers.


• Filtrar anuncios entrantes con un distribute list.


• Redistribuír ODR en otro protocolo (OSPF, EIGRP, etc).


• Cambiarle la distancia administrativa.

Espero que les haya gustado el artículo y que lo usen en el escenario más adecuado.

De yapa dejo el lab para usar en Dynamips.