lunes, abril 18, 2016

OSPF: forzando la elección de un nuevo Designated Router (DR) y Backup Designated Router (BDR)

Si utilizamos el protocolo de enrutamiento OSPF en nuestra red sabremos que, dependiendo del tipo de red que tengamos (y en particular en redes multiacceso con broadcast, como puede ser una red Ethernet), OSPF puede necesitar que uno de los routers en la red funcione como Designated Router (DR) de su segmento de red y otro como Backup Designated Router (BDR). El resto de routers de la red en ese segmento solo formará adyacencia con el DR y el BDR, cuya finalidad es servir como punto central de difusión de rutas, el DR como punto principal y el BDR como respaldo en caso de caída del DR. Con esto lo que se consigue es que si tenemos varios routers en un mismo segmento no se intercambien información todos entre sí, reduciendo el tráfico que genera OSPF y agilizando la difusión de rutas.

La elección del DR y el BDR

OSPF sigue un procedimiento sencillo para elegir tanto al DR como al BDR:

  1. El router con la mayor prioridad OSPF es elegido como DR. El router con la segunda mayor prioridad OSP es elegido como BDR. Por defecto todos los routers tienen la misma prioridad, 1.
  2. A igualdad de prioridad, es elegido como DR el router con mayor Router Id, y como BDR el router con segundo mayor Router Id. El Router Id en OSPF es un parámetro que identifica el router y que si no se configura manualmente se escoge como la IP más elevada configurada en las interfaces loopback de los routers, y si no hay interfaces loopback configuradas, como la IP más elevada de entre las interfaces físicas.

Si no hemos planificado nuestra red adecuadamente o si hemos hecho cambios posteriores es posible que acabemos con un router que es DR o BDR que no sea el más conveniente para dicha tarea o que sencillamente queramos cambiarlo por alguna razón. Para ello podemos cambiar o bien el Router Id o, quizás más sencillamente, la prioridad de la interfaz del segmento del que se quiere que el router sea DR o BDR. Luego habrá que reiniciar el proceso OSPF en los routers para que la elección del DR y BDR tenga lugar de nuevo, lo que implica corte en el tráfico, por lo que debería realizarse en una ventana de mantenimiento. Veámoslo con un ejemplo.

Ejemplo: influyendo en la elección del DR y BDR

Tenemos la siguiente red, con los routers RouterD, RouterE y RouterF viéndose entre sí a través de una red multiacceso y sobre el direccionamiento 192.168.6.0/24, y acceso a otras redes que no nos interesan para el caso:


Veamos el estado de las interfaces del segmento que nos interesa de cada cada router (las salidas del comando show ip ospf interface <interface> se han recortado para una mejor comprensión):

RouterD#show ip ospf interface fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
  Internet Address 192.168.6.4/24, Area 2
  Process ID 1, Router ID 192.168.6.4, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State DROTHER, Priority 1
  Designated Router (ID) 192.168.7.6, Interface address 192.168.6.6
  Backup Designated router (ID) 192.168.6.5, Interface address 192.168.6.5
  [...]

RouterE#show ip ospf interface fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
  Internet Address 192.168.6.5/24, Area 2
  Process ID 1, Router ID 192.168.6.5, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 192.168.7.6, Interface address 192.168.6.6
  Backup Designated router (ID) 192.168.6.5, Interface address 192.168.6.5
  [...]

RouterF#show ip ospf interface f0/0
FastEthernet0/0 is up, line protocol is up
  Internet Address 192.168.6.6/24, Area 2
  Process ID 1, Router ID 192.168.7.6, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 192.168.7.6, Interface address 192.168.6.6
  Backup Designated router (ID) 192.168.6.5, Interface address 192.168.6.5
  [...]


Puede verse que RouterF es el DR en virtud de su mayor Router Id (192.168.7.6, la IP más elevada de entre todas las interfaces que tiene configuradas el router) al tener todos los routers la misma prioridad (1). El BDR es RouterE al tener el segundo mayor Router Id (192.168.6.5) de entre los tres routers. Mientras, RouterD está en estado DROTHER, lo que significa que no es ni el DR ni el BDR.

Ahora supongamos que queremos que el DR sea RouterD. Vamos a modificar la prioridad de la interfaz de RouterD que pertenece al segmento compartido con los otros dos routers, aumentándola a 10:

RouterD#conf t
RouterD(config)#interface fastEthernet 0/1
RouterD(config-if)#ip ospf priority 10


Si hacemos una verificación con show ip interface fast0/1 vemos que nada ha cambiado salvo que la prioridad de la interfaz para OSPF es 10:

RouterD#show ip ospf interface fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
  Internet Address 192.168.6.4/24, Area 2
  Process ID 1, Router ID 192.168.6.4, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State DROTHER, Priority 10


Esto es así porque OSPF no volverá a recalcular quién es el DR y quién el BDR hasta que haya un cambio que haga necesario dicho recálculo, como la caída de los routers o la pérdida de línea. El cambio puede forzarse también mediante el comando clear ip ospf process, que resetea el proceso OSPF, y esto es lo que haremos si queremos aplicar el cambio de DR. El comando se ejecutará en los actuales DR y BDR para que ambos se pierdan y el recálculo se ejecute:

RouterF#clear ip ospf process
Reset ALL OSPF processes? [no]: yes

RouterE#clear ip ospf process
Reset ALL OSPF processes? [no]: yes


Veamos qué ha ocurrido con el estado de las interfaces:

RouterD#show ip ospf interface fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
  Internet Address 192.168.6.4/24, Area 2
  Process ID 1, Router ID 192.168.6.4, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State DR, Priority 10
  Designated Router (ID) 192.168.6.4, Interface address 192.168.6.4
  Backup Designated router (ID) 192.168.6.5, Interface address 192.168.6.5
  [...]

RouterE#show ip ospf interface fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
  Internet Address 192.168.6.5/24, Area 2
  Process ID 1, Router ID 192.168.6.5, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State DROTHER, Priority 1
  Designated Router (ID) 192.168.6.4, Interface address 192.168.6.4
  Backup Designated router (ID) 192.168.7.6, Interface address 192.168.6.6
  [...]

RouterF#show ip ospf interface fastEthernet 0/0
FastEthernet0/0 is up, line protocol is up
  Internet Address 192.168.6.6/24, Area 2
  Process ID 1, Router ID 192.168.7.6, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 192.168.6.4, Interface address 192.168.6.4
  Backup Designated router (ID) 192.168.7.6, Interface address 192.168.6.6
  [...]


Tras el reinicio del proceso OSPF, RouterD se ha convertido en el DR gracias a su prioridad de 10 y RouterF es el BDR al tener la IP más alta de entre los dos routers restantes, ambos con una prioridad de 1.

sábado, abril 09, 2016

El problema de las redes discontiguas y "no auto-summary"

Se define red discontigua (discontiguous network) como aquella que tiene dos o más subredes de una red completa (classful) separadas por una red distinta. El problema con este tipo de redes es que si no utilizamos un protocolo de routing que soporte VLSM (variable length subnet masks), es decir, que envíe la máscara de la red junto con las actualizaciones de las rutas, los routers simplemente no entenderán a dónde enviar el tráfico de dichas subredes y no habrá visibilidad entre ellas. Ejemplos de protocolos de routing incapaces de usar VLSM son IGRP y RIP, mientras que protocolos como EIGRP y OSPF lo usan sin ningún problema, pero por defecto no lo utilizan hasta que es habilitado.

El problema de las redes discontiguas se ve mejor con ejemplos.

Ejemplo 1


Tomemos esta red:


Tenemos dos routers, R1 y R2, conectados a través de interfaces serie por la red 192.168.1.0/24 y de los que a su vez cuelgan cuatro subredes creadas a partir de la clase 10.0.0.0/8:

10.1.0.0/16
10.2.0.0/16
10.3.0.0/16
10.4.0.0/16

Vamos a configurar EIGRP entre R1 y R2, poniendo en ambos:


router eigrp 1
 network 10.0.0.0
 network 192.168.1.0



Así es como ve cada router la red:

R1

R1#show ip route
 

[...]

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C       10.2.0.0/16 is directly connected, FastEthernet0/1
D       10.0.0.0/8 is a summary, 00:03:51, Null0
C       10.1.0.0/16 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Serial0/0


R2

R2#show ip route

[...]

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C       10.3.0.0/16 is directly connected, FastEthernet0/0
D       10.0.0.0/8 is a summary, 00:07:23, Null0
C       10.4.0.0/16 is directly connected, FastEthernet0/1
C    192.168.1.0/24 is directly connected, Serial0/0



Puede verse que cada router ve las distintas subredes 10.x.0.0/16 que le corresponden como directamente conectadas (marcadas con una "C" en la tabla de rutas), mientras que la ruta anunciada mediante EIGRP (marcada con una "D" en la tabla) está sumarizada, es decir, se envía como una red completa, anunciando las redes 10.x.0.0/16 como 10.0.0.0/8, y va a Null0, con lo que en realidad las subredes no se están anunciado y las de un lado no se ven con las del otro. Por ejemplo, el host PC1 tiene como IP 10.1.0.10, mientras que PC4 tiene la IP 10.4.0.10. Si intentamos llegar de uno a otro:

PC1> ping 10.4.0.10

*10.1.0.1 icmp_seq=1 ttl=255 time=9.656 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.0.1 icmp_seq=2 ttl=255 time=7.378 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.0.1 icmp_seq=3 ttl=255 time=8.445 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.0.1 icmp_seq=4 ttl=255 time=9.475 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.0.1 icmp_seq=5 ttl=255 time=7.548 ms (ICMP type:3, code:1, Destination host unreachable)



El host PC1 no sabe cómo llegar a PC4 y de ahí el "Destination host unreachable".

Debemos indicarle a los routers que no queremos que envíen las rutas sumarizadas para que las subredes puedan anunciarse como es debido utilizando el comando "no auto-summary":


router eigrp 1
 network 10.0.0.0
 network 192.168.1.0

 auto-summary

Veamos cómo quedan las rutas ahora:

R1

R1#show ip route

[...]

Gateway of last resort is not set

     10.0.0.0/16 is subnetted, 4 subnets
C       10.2.0.0 is directly connected, FastEthernet0/1
D       10.3.0.0 [90/2195456] via 192.168.1.2, 00:03:18, Serial0/0
C       10.1.0.0 is directly connected, FastEthernet0/0
D       10.4.0.0 [90/2195456] via 192.168.1.2, 00:03:18, Serial0/0
C    192.168.1.0/24 is directly connected, Serial0/0


R2

R2#show ip route
 

[...]

Gateway of last resort is not set

     10.0.0.0/16 is subnetted, 4 subnets
D       10.2.0.0 [90/2195456] via 192.168.1.1, 00:04:42, Serial0/0
C       10.3.0.0 is directly connected, FastEthernet0/0
D       10.1.0.0 [90/2195456] via 192.168.1.1, 00:04:42, Serial0/0
C       10.4.0.0 is directly connected, FastEthernet0/1
C    192.168.1.0/24 is directly connected, Serial0/0


Se ve perfectamente cómo ya se anuncian las subredes específicas y cómo cada router ve las subredes del otro lado. Ahora los hosts de ambos lados se ven sin ningún problema:

PC1> ping 10.4.0.10

84 bytes from 10.4.0.10 icmp_seq=1 ttl=62 time=20.764 ms
84 bytes from 10.4.0.10 icmp_seq=2 ttl=62 time=11.925 ms
84 bytes from 10.4.0.10 icmp_seq=3 ttl=62 time=8.549 ms
84 bytes from 10.4.0.10 icmp_seq=4 ttl=62 time=8.061 ms
84 bytes from 10.4.0.10 icmp_seq=5 ttl=62 time=9.814 ms


Ejemplo 2


Se puede ver el mismo problema con un ejemplo un poco más complicado:


Tenemos aquí cinco routers (RouterA, RouterB, RouterC, RouterD y RouterE) interconectados por redes 192.168.x.0/24 y tres redes a LAN, una de ellas perteneciente a la misma clase que las redes de interconexión y las otras dos son subredes (10.1.0.0/16 y 10.2.0.0/16) pertenecientes a la clase 10.0.0.0/8 y que por tanto son las redes discontiguas en este esquema.

Todos los routers tienen configurado EIGRP y están anunciando todas las rutas, pero desde el host PC1 (que tiene como IP 10.1.0.10) no se llega al host PC2 (que tiene IP 10.2.0.10):

PC1> ping 10.2.0.10

*10.1.0.1 icmp_seq=1 ttl=255 time=8.767 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.0.1 icmp_seq=2 ttl=255 time=6.082 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.0.1 icmp_seq=3 ttl=255 time=8.230 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.0.1 icmp_seq=4 ttl=255 time=10.109 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.0.1 icmp_seq=5 ttl=255 time=4.687 ms (ICMP type:3, code:1, Destination host unreachable)


Veamos qué hay en la tabla de rutas de los routers RouterA, RouterD y RouterC:

RouterA#show ip route
[...]
Gateway of last resort is not set

C    192.168.4.0/24 is directly connected, FastEthernet0/1
D    192.168.5.0/24 [90/307200] via 192.168.4.2, 03:19:27, FastEthernet0/1
     10.0.0.0/8 is subnetted, 1 subnets
D       10.0.0.0 [90/307200] via 192.168.1.2, 00:36:54, FastEthernet0/0
D    192.168.6.0/24 [90/2221056] via 192.168.4.2, 03:19:27, FastEthernet0/1
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/2195456] via 192.168.1.2, 03:19:27, FastEthernet0/0
D    192.168.3.0/24 [90/2221056] via 192.168.1.2, 03:19:29, FastEthernet0/0



RouterD#show ip route

[...]
Gateway of last resort is not set

C    192.168.4.0/24 is directly connected, FastEthernet0/1
C    192.168.5.0/24 is directly connected, FastEthernet0/0
D    10.0.0.0/8 [90/307200] via 192.168.5.2, 00:37:34, FastEthernet0/0
D    192.168.6.0/24 [90/2195456] via 192.168.5.2, 03:17:58, FastEthernet0/0
D    192.168.1.0/24 [90/307200] via 192.168.4.1, 03:17:57, FastEthernet0/1
D    192.168.2.0/24 [90/2221056] via 192.168.4.1, 03:17:57, FastEthernet0/1
D    192.168.3.0/24 [90/2221056] via 192.168.5.2, 03:17:57, FastEthernet0/0


RouterC#show ip route

[...]

Gateway of last resort is not set

D    192.168.4.0/24 [90/2221056] via 192.168.6.2, 03:15:59, Serial0/0
                    [90/2221056] via 192.168.2.1, 03:15:59, Serial0/1
D    192.168.5.0/24 [90/2195456] via 192.168.6.2, 03:15:58, Serial0/0
     10.0.0.0/8 is subnetted, 1 subnets
D       10.0.0.0 [90/2195456] via 192.168.6.2, 00:37:55, Serial0/0
                 [90/2195456] via 192.168.2.1, 00:37:55, Serial0/
1
C    192.168.6.0/24 is directly connected, Serial0/0
D    192.168.1.0/24 [90/2195456] via 192.168.2.1, 03:15:58, Serial0/1
C    192.168.2.0/24 is directly connected, Serial0/1
C    192.168.3.0/24 is directly connected, FastEthernet0/0


Puede verse que no hay rastro de las subredes 10.x.0.0/16 en la tabla de rutas y que en su lugar se está anunciando la red 10.0.0.0/8 completa, tal como era de esperar al no estar en marcha la sumarización. Además RouterC ve la red completa a través de sus dos caminos hacia RouterB y RouterE, donde residen las subredes, lo cual es razonable, pero existe el problema adicional de que RoutarA y RouterD ven la red completa cada uno por un camino distinto: RouterA lo ve por su interfaz Fast0/0 hacia RouterB, y RouterD por su interfaz Fast0/0 hacia RouterE, por lo que no hay consistencia en la transmisión de las rutas. La solución, como ya sabemos, es habilitar la sumarización en todos los routers:

RouterA(config)#router eigrp 1
RouterA(config-router)#no auto-summary

RouterB(config)#router eigrp 1
RouterB(config-router)#no auto-summary

RouterC(config)#router eigrp 1
RouterC(config-router)#no auto-summary

RouterD(config)#router eigrp 1
RouterD(config-router)#no auto-summary

RouterE(config)#router eigrp 1
RouterE(config-router)#no auto-summary


Veamos ahora el aspecto de las rutas:

RouterA#show ip route
[...]
Gateway of last resort is not set

C    192.168.4.0/24 is directly connected, FastEthernet0/1
D    192.168.5.0/24 [90/307200] via 192.168.4.2, 03:39:47, FastEthernet0/1
     10.0.0.0/16 is subnetted, 2 subnets
D       10.2.0.0 [90/332800] via 192.168.4.2, 00:00:53, FastEthernet0/1
D       10.1.0.0 [90/307200] via 192.168.1.2, 00:01:23, FastEthernet0/0

D    192.168.6.0/24 [90/2221056] via 192.168.4.2, 03:39:47, FastEthernet0/1
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/2195456] via 192.168.1.2, 03:39:48, FastEthernet0/0
D    192.168.3.0/24 [90/2221056] via 192.168.1.2, 03:39:48, FastEthernet0/0

RouterD#show ip route
[...]
Gateway of last resort is not set

C    192.168.4.0/24 is directly connected, FastEthernet0/1
C    192.168.5.0/24 is directly connected, FastEthernet0/0
     10.0.0.0/16 is subnetted, 2 subnets
D       10.2.0.0 [90/307200] via 192.168.5.2, 00:01:24, FastEthernet0/0
D       10.1.0.0 [90/332800] via 192.168.4.1, 00:01:54, FastEthernet0/1

D    192.168.6.0/24 [90/2195456] via 192.168.5.2, 03:38:08, FastEthernet0/0
D    192.168.1.0/24 [90/307200] via 192.168.4.1, 03:38:08, FastEthernet0/1
D    192.168.2.0/24 [90/2221056] via 192.168.4.1, 03:38:08, FastEthernet0/1
D    192.168.3.0/24 [90/2221056] via 192.168.5.2, 03:38:09, FastEthernet0/0

RouterC#show ip route
[...]
Gateway of last resort is not set

D    192.168.4.0/24 [90/2221056] via 192.168.6.2, 03:36:08, Serial0/0
                    [90/2221056] via 192.168.2.1, 03:36:08, Serial0/1
D    192.168.5.0/24 [90/2195456] via 192.168.6.2, 03:36:08, Serial0/0
     10.0.0.0/16 is subnetted, 2 subnets
D       10.2.0.0 [90/2195456] via 192.168.6.2, 00:01:44, Serial0/0
D       10.1.0.0 [90/2195456] via 192.168.2.1, 00:01:44, Serial0/1

C    192.168.6.0/24 is directly connected, Serial0/0
D    192.168.1.0/24 [90/2195456] via 192.168.2.1, 03:36:08, Serial0/1
C    192.168.2.0/24 is directly connected, Serial0/1
C    192.168.3.0/24 is directly connected, FastEthernet0/0


Como era de esperar, las subredes ya se están anunciando correctamente, con su máscara, en lugar de anunciarse la red completa. Veamos si ahora desde PC1 se llega a PC2:

PC1> ping 10.2.0.10

84 bytes from 10.2.0.10 icmp_seq=1 ttl=60 time=47.678 ms
84 bytes from 10.2.0.10 icmp_seq=2 ttl=60 time=49.870 ms
84 bytes from 10.2.0.10 icmp_seq=3 ttl=60 time=49.376 ms
84 bytes from 10.2.0.10 icmp_seq=4 ttl=60 time=48.834 ms
84 bytes from 10.2.0.10 icmp_seq=5 ttl=60 time=50.356 ms


Ahora hay visibilidad entre ambas redes discontiguas y los hosts pueden verse sin problemas.

Conclusión

El uso de protocolos de routing capaces de utilizar VLSM aporta flexibilidad al diseño de nuestra red, al permitirnos utilizar redes discontiguas y un potencial mejor aprovechamiento del direccionamiento de red del que dispongamos, por lo que siempre es deseable utilizarlo mediante el comando "no auto-summary".