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:
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.