EIGRP: Balanceando carga

Objetivo del laboratorio:

  • Revisión de configuración básica de EIGRP.
  • Explorar la tabla de topología de EIGRP.
  • Aprender a identificar successors, feasible successors y feasible distances.
  • Aprender a usar los comandos DEBUG con la tabla de topología de EIGRP.
  • Configurar y verificar el balanceo de carga con igual coste con EIGRP.
  • Configurar y verificar el balanceo de carga con diferente coste con EIGRP.

Requisitos:

  • GNS3 (versión usada 0.5)
  • IOS: versión mínima: 12.3(2)T (versión usada 12.4-21)
  • Ficheros del laboratorio (descargar zip con el laboratorio completo) NOTA 1: se recomienda hacer el laboratorio desde cero, en vez de copiar y pegar, para aprender. NOTA 2: los path del fichero .net se deben ajustar a los de tu ordenador.

Esquema:

EIGRP: Balanceando carga

Paso 1: configurar las interfaces Loopback y las interfaces Serie.

Primero configuramos las interfaces Loopback de los 3 routers:

R1:
interface Loopback1
 ip address 10.10.10.1 255.255.255.252
!
interface Loopback5
 ip address 10.10.10.5 255.255.255.252
!
interface Loopback9
 ip address 10.10.10.9 255.255.255.252

R2:
interface Loopback1
 ip address 10.10.20.1 255.255.255.252
!
interface Loopback5
 ip address 10.10.20.5 255.255.255.252
!
interface Loopback9
 ip address 10.10.20.9 255.255.255.252

R3:
interface Loopback1
 ip address 10.10.30.1 255.255.255.252
!
interface Loopback5
 ip address 10.10.30.5 255.255.255.252
!
interface Loopback9
 ip address 10.10.30.9 255.255.255.252

Segundo configuramos las interfaces serie configurando el reloj a 64 kbps y el ancho de banda de las interfaces también a 64 kbps. Añadimos una descripción a las interfaces indicando que router une dicha interface. Para comprobar el estado de las interfaces en cada router podemos usar el comando "show ip interface bri".

R1:
interface Serial1/2
 description R1-R2
 bandwidth 64
 ip address 10.10.12.1 255.255.255.248
 clock rate 64000
 no shutdown
!
interface Serial1/3
 description R1-R3
 bandwidth 64
 ip address 10.10.13.1 255.255.255.248
 no shutdown

R2:
interface Serial1/1
 description R2-R1
 bandwidth 64
 ip address 10.10.12.2 255.255.255.248
 no shutdown
!
interface Serial1/3
 description R2-R3
 bandwidth 64
 ip address 10.10.23.2 255.255.255.248
 clock rate 64000
 no shutdown

R3:
interface Serial1/1
 description R3-R1
 bandwidth 64
 ip address 10.10.13.3 255.255.255.248
 clock rate 64000
 no shutdown
!
interface Serial1/2
 description R3-R2
 bandwidth 64
 ip address 10.10.23.3 255.255.255.248
 no shutdown

Y tercero comprobamos con un script TCLSH (ver artículo) que hacemos ping a todas las IPs de todos los routers desde todos los routers. El script TCLSH es el siguiente (se omite la salida para evitar que se extienda el artículo):

foreach ips {
10.10.10.1
10.10.10.5
10.10.10.9
10.10.20.1
10.10.20.5
10.10.20.9
10.10.30.1
10.10.30.5
10.10.30.9
10.10.12.1
10.10.13.1
10.10.12.2
10.10.23.2
10.10.23.3
10.10.13.3
} {
ping $ips
}

Evidentemente como no hay ningún protocolo de rutado configurado no se alcanzan todas las IPs, cada router verá las suyas (Loopbacks y serie) y las serie de sus vecinos directos.

Paso 2: Configuración de EIGRP.

Configuramos EIGRP con sistema autónomo 100 como ya hemos visto en otros laboratorios:

R1,R2 y R3:
router eigrp 100
network 10.0.0.0

Ahora podemos comprobar que está todo correcto con diversos comandos, como por ejemplo mirar los vecinos de cada router:

R3#show ip eigrp neighbors 100
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   10.10.13.1              Se1/1             10 00:06:17   28  2280  0  9
0   10.10.23.2              Se1/2             14 00:06:17   31  2280  0  9

También podemos comprobar que obtenemos todas las redes configuradas en todos los routers:

R3#show ip route eigrp 100
     10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
D       10.10.10.8/30 [90/40640000] via 10.10.13.1, 00:07:33, Serial1/1
D       10.10.10.0/30 [90/40640000] via 10.10.13.1, 00:07:33, Serial1/1
D       10.10.12.0/29 [90/41024000] via 10.10.23.2, 00:07:33, Serial1/2
                      [90/41024000] via 10.10.13.1, 00:07:33, Serial1/1
D       10.10.10.4/30 [90/40640000] via 10.10.13.1, 00:07:33, Serial1/1
D       10.10.20.4/30 [90/40640000] via 10.10.23.2, 00:07:33, Serial1/2
D       10.10.20.0/30 [90/40640000] via 10.10.23.2, 00:07:33, Serial1/2
D       10.10.20.8/30 [90/40640000] via 10.10.23.2, 00:07:33, Serial1/2

También podemos usar el script TCLSH que antes no veía todas las IPs y comprobar que ahora si las vé.

Y por último podemos activar el debug para ver todo el proceso de EIGRP (es interesante activar el debug en todos los router antes de configurar EIGRP para ver todo el proceso). El comando a usar para activar el debug es "debug ip eigrp 100" (se omite la salida por que es demasiado larga) y para desactivarlo "undebug all".

Paso 3: Tabla de topología de EIGRP.

EIGRP construye una tabla de topología donde mantiene las rutas de todos los sucesores. Para ver la tabla de topología usamos el comando:

R2#show ip eigrp topology
IP-EIGRP Topology Table for AS(100)/ID(10.10.20.9)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 10.10.10.8/30, 1 successors, FD is 40640000
        via 10.10.12.1 (40640000/128256), Serial1/1
P 10.10.10.0/30, 1 successors, FD is 40640000
        via 10.10.12.1 (40640000/128256), Serial1/1
P 10.10.12.0/29, 1 successors, FD is 40512000
        via Connected, Serial1/1
P 10.10.13.0/29, 2 successors, FD is 41024000
        via 10.10.12.1 (41024000/40512000), Serial1/1
        via 10.10.23.3 (41024000/40512000), Serial1/3
P 10.10.10.4/30, 1 successors, FD is 40640000
        via 10.10.12.1 (40640000/128256), Serial1/1
P 10.10.20.4/30, 1 successors, FD is 128256
        via Connected, Loopback5
P 10.10.20.0/30, 1 successors, FD is 128256
        via Connected, Loopback1
P 10.10.30.8/30, 1 successors, FD is 40640000
        via 10.10.23.3 (40640000/128256), Serial1/3
P 10.10.23.0/29, 1 successors, FD is 40512000
        via Connected, Serial1/3
P 10.10.30.4/30, 1 successors, FD is 40640000
        via 10.10.23.3 (40640000/128256), Serial1/3
P 10.10.20.8/30, 1 successors, FD is 128256
        via Connected, Loopback9
P 10.10.30.0/30, 1 successors, FD is 40640000
        via 10.10.23.3 (40640000/128256), Serial1/3

Aquí podemos ver Feasible Distance (FD) de cada ruta y un punto importante son los 2 sucesores (marcados en negrita) de la ruta 10.10.13.0/29 que es anunciada tanto por R1 como R3 con la misma distancia (41024000) por lo que ambos sucesores están en la tabla de topología.

Para ver la información que EIGRP ha recibido sobre la red 10.10.13.0/29 de los routers R1 y R3 podemos usar el comando:

R2#show ip eigrp topology 10.10.13.0/29
IP-EIGRP (AS 100): Topology entry for 10.10.13.0/29
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 41024000
  Routing Descriptor Blocks:
  10.10.12.1 (Serial1/1), from 10.10.12.1, Send flag is 0x0
      Composite metric is (41024000/40512000), Route is Internal
      Vector metric:
        Minimum bandwidth is 64 Kbit
        Total delay is 40000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.10.23.3 (Serial1/3), from 10.10.23.3, Send flag is 0x0
      Composite metric is (41024000/40512000), Route is Internal
      Vector metric:
        Minimum bandwidth is 64 Kbit
        Total delay is 40000 microseconds
        Reliability is 255/255
        Load is 3/255
        Minimum MTU is 1500
        Hop count is 1

Aquí vemos la métrica compuesta además de los valores individuales que a continuación se explica:

  • Bandwidth, representa el mínimo ancho de banda sobre el camino a la red de destino.
  • Delay metric, representa la espera total sobre el camino.
  • MTU, representa el mínimo de la unidad de trasmisión máxima sobre el camino.
  • The hop count, muestra el número de saltos o dispositivos que hay entre el router y la red de destino.

Paso 4: Balanceo de carga con mismo coste.

EIGRP produce balanceo de carga con mismo coste a la red de destino (en el caso anterior 10.10.12.1 desde R3) pero como desde que las últimas versiones de IOS viene activado por defecto CEF (Cisco Express Forwarding) que permite conmutación rápida de paquetes basado en arquitectura de conmutado por destino, El primer paquete en un flujo es enrutado y el resto son conmutados. Este comportamiento es el preferido en la mayoría de circunstancias. Pero en este caso desde R3 no vemos el balanceo de carga ya que CEF trata las 5 series de un ping como un solo flujo. por lo que si hacemos un ping desde R3 a 10.10.12.1 veremos que siempre va por el mismo camino, para ello activaremos "debug ip packet" antes del ping:

*Mar  1 00:00:55.767: IP: tableid=0, s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), routed via FIB
*Mar  1 00:00:55.767: IP: s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), len 100, sending
*Mar  1 00:00:55.771: IP: tableid=0, s=10.10.12.1 (Serial1/1), d=10.10.23.3 (Serial1/2), routed via RIB
*Mar  1 00:00:55.771: IP: s=10.10.12.1 (Serial1/1), d=10.10.23.3, len 100, rcvd 4
*Mar  1 00:00:55.771: IP: tableid=0, s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), routed via FIB
*Mar  1 00:00:55.771: IP: s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), len 100, sending
*Mar  1 00:00:55.779: IP: tableid=0, s=10.10.12.1 (Serial1/1), d=10.10.23.3 (Serial1/2), routed via RIB
*Mar  1 00:00:55.779: IP: s=10.10.12.1 (Serial1/1), d=10.10.23.3, len 100, rcvd 4
*Mar  1 00:00:55.779: IP: tableid=0, s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), routed via FIB
*Mar  1 00:00:55.779: IP: s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), len 100, sending
*Mar  1 00:00:55.787: IP: tableid=0, s=10.10.12.1 (Serial1/1), d=10.10.23.3 (Serial1/2), routed via RIB
*Mar  1 00:00:55.787: IP: s=10.10.12.1 (Serial1/1), d=10.10.23.3, len 100, rcvd 4
*Mar  1 00:00:55.787: IP: tableid=0, s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), routed via FIB
*Mar  1 00:00:55.787: IP: s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), len 100, sending
*Mar  1 00:00:55.791: IP: tableid=0, s=10.10.12.1 (Serial1/1), d=10.10.23.3 (Serial1/2), routed via RIB
*Mar  1 00:00:55.791: IP: s=10.10.12.1 (Serial1/1), d=10.10.23.3, len 100, rcvd 4
*Mar  1 00:00:55.791: IP: tableid=0, s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), routed via FIB
*Mar  1 00:00:55.791: IP: s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), len 100, sending
*Mar  1 00:00:55.799: IP: tableid=0, s=10.10.12.1 (Serial1/1), d=10.10.23.3 (Serial1/2), routed via RIB
*Mar  1 00:00:55.799: IP: s=10.10.12.1 (Serial1/1), d=10.10.23.3, len 100, rcvd 4

Ahora primero desactivaremos CEF (para ver que realmente hay balanceo de carga pero en un entorno de producción lo dejaremos activado) con el comando "no ip cef" en modo configuración y repetiremos el ping (con el debug aún activado):

*Mar  1 00:04:59.103: IP: tableid=0, s=10.10.13.3 (local), d=10.10.12.1 (Serial1/1), routed via RIB
*Mar  1 00:04:59.107: IP: s=10.10.13.3 (local), d=10.10.12.1 (Serial1/1), len 100, sending
*Mar  1 00:04:59.111: IP: tableid=0, s=10.10.12.1 (Serial1/1), d=10.10.13.3 (Serial1/1), routed via RIB
*Mar  1 00:04:59.111: IP: s=10.10.12.1 (Serial1/1), d=10.10.13.3 (Serial1/1), len 100, rcvd 3
*Mar  1 00:04:59.111: IP: tableid=0, s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), routed via RIB
*Mar  1 00:04:59.111: IP: s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), len 100, sending
*Mar  1 00:04:59.119: IP: tableid=0, s=10.10.12.1 (Serial1/1), d=10.10.23.3 (Serial1/2), routed via RIB
*Mar  1 00:04:59.119: IP: s=10.10.12.1 (Serial1/1), d=10.10.23.3, len 100, rcvd 4
*Mar  1 00:04:59.119: IP: tableid=0, s=10.10.13.3 (local), d=10.10.12.1 (Serial1/1), routed via RIB
*Mar  1 00:04:59.119: IP: s=10.10.13.3 (local), d=10.10.12.1 (Serial1/1), len 100, sending
*Mar  1 00:04:59.123: IP: tableid=0, s=10.10.12.1 (Serial1/1), d=10.10.13.3 (Serial1/1), routed via RIB
*Mar  1 00:04:59.123: IP: s=10.10.12.1 (Serial1/1), d=10.10.13.3 (Serial1/1), len 100, rcvd 3
*Mar  1 00:04:59.123: IP: tableid=0, s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), routed via RIB
*Mar  1 00:04:59.123: IP: s=10.10.23.3 (local), d=10.10.12.1 (Serial1/2), len 100, sending
*Mar  1 00:04:59.127: IP: tableid=0, s=10.10.12.1 (Serial1/1), d=10.10.23.3 (Serial1/2), routed via RIB
*Mar  1 00:04:59.131: IP: s=10.10.12.1 (Serial1/1), d=10.10.23.3, len 100, rcvd 4
*Mar  1 00:04:59.131: IP: tableid=0, s=10.10.13.3 (local), d=10.10.12.1 (Serial1/1), routed via RIB
*Mar  1 00:04:59.131: IP: s=10.10.13.3 (local), d=10.10.12.1 (Serial1/1), len 100, sending
*Mar  1 00:04:59.135: IP: tableid=0, s=10.10.12.1 (Serial1/1), d=10.10.13.3 (Serial1/1), routed via RIB
*Mar  1 00:04:59.135: IP: s=10.10.12.1 (Serial1/1), d=10.10.13.3 (Serial1/1), len 100, rcvd 3

Aquí ya vemos como si hay balanceo de carga e intercala los 2 posibles caminos.

Paso 5: Caminos alternativos de EIGRP que NO están en la tabla de topología.

Antes en el paso 3 hemos visto la tabla de topología peor si nos fijamos bien no están TODOS los posible caminos, para verlos todos debemos añadir all-links al final:

R2#sh ip eigrp topology  all-links
IP-EIGRP Topology Table for AS(100)/ID(10.10.20.9)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 10.10.10.8/30, 1 successors, FD is 40640000, serno 9
        via 10.10.12.1 (40640000/128256), Serial1/1
        via 10.10.23.3 (41152000/40640000), Serial1/3
P 10.10.10.0/30, 1 successors, FD is 40640000, serno 7
        via 10.10.12.1 (40640000/128256), Serial1/1
        via 10.10.23.3 (41152000/40640000), Serial1/3
P 10.10.12.0/29, 1 successors, FD is 40512000, serno 1
        via Connected, Serial1/1
P 10.10.13.0/29, 2 successors, FD is 41024000, serno 10
        via 10.10.12.1 (41024000/40512000), Serial1/1
        via 10.10.23.3 (41024000/40512000), Serial1/3
P 10.10.10.4/30, 1 successors, FD is 40640000, serno 8
        via 10.10.12.1 (40640000/128256), Serial1/1
        via 10.10.23.3 (41152000/40640000), Serial1/3
P 10.10.20.4/30, 1 successors, FD is 128256, serno 4
        via Connected, Loopback5
P 10.10.20.0/30, 1 successors, FD is 128256, serno 3
        via Connected, Loopback1
P 10.10.30.8/30, 1 successors, FD is 40640000, serno 13
        via 10.10.23.3 (40640000/128256), Serial1/3
        via 10.10.12.1 (41152000/40640000), Serial1/1
P 10.10.23.0/29, 1 successors, FD is 40512000, serno 2
        via Connected, Serial1/3
P 10.10.30.4/30, 1 successors, FD is 40640000, serno 12
        via 10.10.23.3 (40640000/128256), Serial1/3
        via 10.10.12.1 (41152000/40640000), Serial1/1
P 10.10.20.8/30, 1 successors, FD is 128256, serno 5
        via Connected, Loopback9
P 10.10.30.0/30, 1 successors, FD is 40640000, serno 11
        via 10.10.23.3 (40640000/128256), Serial1/3
        via 10.10.12.1 (41152000/40640000), Serial1/1

Paso 6: Balanceo de carga con diferente coste.

Retomando la salida (reusmida) de la tabla de topología del paso 3, tenemos que:

R2#show ip eigrp topology
...
P 10.10.30.0/30, 1 successors, FD is 40640000
        via 10.10.23.3 (40640000/128256), Serial1/3
...

R2#sh ip eigrp topology 10.10.30.0/30
IP-EIGRP (AS 100): Topology entry for 10.10.30.0/30
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 40640000
  Routing Descriptor Blocks:
  10.10.23.3 (Serial1/3), from 10.10.23.3, Send flag is 0x0
      Composite metric is (40640000/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 64 Kbit
        Total delay is 25000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.10.12.1 (Serial1/1), from 10.10.12.1, Send flag is 0x0
      Composite metric is (41152000/40640000), Route is Internal
      Vector metric:
        Minimum bandwidth is 64 Kbit
        Total delay is 45000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

Vemos que 10.10.12.1 no es es ruta sucesora debido a que feasible distance (FD) es superior.

Retro

Lugares

Redes

Sistemas

Varios