IP : Protocolo mejorado de routing de gateway interior (EIGRP)

Problemas comunes del EIGRP del Troubleshooting

18 Junio 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (21 Abril 2016) | Comentarios

Introducción

Este documento describe cómo resolver problemas los problemas mas comunes del Enhanced Interior Gateway Routing Protocol (EIGRP).

Nota: Este documento utiliza los ejemplos y la implementación en el ® del Cisco IOS para ilustrar los diversos comportamientos que pueden ser encontrados.

Contribuido por Lucas De Ghein, ingeniero de Cisco TAC.

Antecedentes

Ésta es la topología que se utiliza para este documento:

Las secciones que siguen describen algunas de los problemas mas comunes del EIGRP y de algunas extremidades sobre cómo resolver problemas los problemas.

Cambio vecino

El solo la mayoría del problema frecuente que se encuentre con el uso del EIGRP es que no establece una vecindad correctamente. Hay varias posibles causas para esto:

  • Problema de la Unidad máxima de transmisión (MTU) (MTU)

  • Comunicación unidireccional (links unidireccionales)

  • Hay un problema de multidifusión en el link

  • Problemas del unicast

  • Problemas de calidad del link

  • Problemas de la autenticación

  • Problemas del misconfiguration

Si usted no recibe un mensaje Hello Messages del EIGRP, usted no puede ver al vecino en la lista vecina. Ingrese el comando show ip eigrp neighbors para ver la información del vecino EIGRP e identificar el problema:

R2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H   Address  Interface Hold Uptime   SRTT   RTO  Q  Seq
                       (sec)         (ms)       Cnt Num
3   10.1.1.1  Et0/0     12 00:00:48    1  5000  1  0
2   10.1.1.3  Et0/0     12 02:47:13   22   200  0  339
1   10.2.1.4  Et1/0     12 02:47:13   24   200  0  318
0   10.2.1.3  Et1/0     12 02:47:13   20   200  0  338 13   20   200  0  338

Si usted piensa que se ha formado la vecindad, pero usted no tiene los prefijos que usted debe aprender de ese vecino, marque la salida del comando anterior: Si la Q-cuenta es siempre no-cero, podría ser una indicación que los mismos paquetes EIGRP están retransmitidos continuamente. Ingrese el comando detail de los vecinos del eigrp del IP de la demostración para verificar si el mismo paquete está enviado siempre. Si el número de secuencia del primer paquete es siempre lo mismo, después el mismo paquete se retransmite indefinidamente:

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.1.1.1                Et0/0             11 00:00:08    1  4500  1  0
   Version 12.4/1.2, Retrans: 2, Retries: 2, Waiting for Init, Waiting for Init Ack
    UPDATE seq 350 ser 0-0 Sent 8040 Init Sequenced
2   10.1.1.3                Et0/0             11 02:47:56   22   200  0  339
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1   10.2.1.4                Et1/0             10 02:47:56   24   200  0  318
   Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0   10.2.1.3                Et1/0             11 02:47:56   20   200  0  338
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

Usted puede ver en la salida que el primer vecino tiene un problema, y el Uptime está reajustado.

Es importante que usted verifica si el EIGRP de proceso del router tenga el comando eigrp log-neighbor-changes. Sin embargo, esto se incluye por abandono desde el Id. de bug Cisco CSCdx67706, así que no aparece en la configuración en ese caso. Marque la entrada en los registros para ambos vecinos EIGRP en cada lado del link. En por lo menos uno de los registros, debe haber una entrada significativa.

Aquí están todas las razones posibles de un cambio de la vecindad EIGRP y de sus entradas de registro:

  • No se recibió ningunos paquetes EIGRP durante el tiempo en espera:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    holding time expired
  • Un paquete confiable del EIGRP no fue reconocido dentro del límite de la recomprobación:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    retry limit exceeded
  • El EIGRP ve la interfaz en un estado inactivo:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:
    interface down
  • El router recibió un paquete de actualización inicial y recomenzó la vecindad:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    peer restarted
  • El router recibió un paquete de actualización inicial y formó una nueva adyacencia:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
    new adjacency
  • Ingresaron al comando ip eigrp neighbor claro, que dio lugar a un claro manual:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.4 (Serial2/0) is down:
    manually cleared
  • La dirección IP en la interfaz fue cambiada:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.5 (Serial3/0) is down:
    address changed
  • Había un retardo/un cambio de ancho de banda en la interfaz:

    Nota: Esto ocurre solamente en más viejas versiones del código. No hay flap vecino desde el Id. de bug Cisco CSCdp08764.

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:
    metric changed
  • Se configuran mal los valores K o un Cierre elegante ocurre:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
    K-value mismatch
  • Un Cierre elegante ocurre:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    Interface Goodbye received
  • El eigrp del modo de autenticación del IP 1 comando del md5 fue configurado en la interfaz:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is down:
    authentication mode changed
  • Un graceful restart/Non-Stop un envío (NSF) ocurrido:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2 (FastEthernet1) is resync:
    peer graceful-restart
  • Borran a los vecinos a quienes hay interrogaciones enviadas sin una contestación recibida:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.16 (Serial3/0) is down:
    stuck in active

Problemas de red

Estos cinco problemas indican un problema de red:

  • Un estado Pegar-En-activo (SIA)

  • Un temporizador que se sostiene expirado

  • Un límite excedido de la recomprobación

  • Un par recomenzado

  • Una actualización inicial se envía antes del paquete de saludo

SIA

Refiera a la sección SIA de este documento.

Expirado sosteniendo el temporizador

Un temporizador que se sostiene expirado indica que el router no recibió ningunos paquetes EIGRP (es decir, un EIGRP hola o cualquier otros paquetes EIGRP) durante el intervalo de tiempo en espera. Hay más que probablemente un problema en el link en este caso.

Marque que el router recibe los paquetes de saludo EIGRP en este link y que el otro lado los envía. Para verificar esto, ingrese el comando de los paquetes EIGRP del debug hola.

Como alternativa al uso del comando debug, usted puede hacer ping a la dirección IP 224.0.0.10 y verificarla si ese vecino contesta.

Las posibles causas por el problema de multidifusión en el link deben interconectar los problemas, por ejemplo si un Switch intermedio bloquea los paquetes de saludo EIGRP.

Otra prueba rápida que usted puede realizar es intentar otro protocolo que utilice otro Multicast IP Address. Por ejemplo, usted puede configurar la versión 2 del Routing Information Protocol (RIP) que utiliza el Multicast IP Address 224.0.0.9.

Límite excedido de la recomprobación

Un límite excedido de la recomprobación indica que un paquete confiable del EIGRP no fue reconocido las épocas múltiples. Un paquete confiable del EIGRP es uno de estos cinco tipos de paquetes:

  • Actualización

  • Consulta

  • Contestación

  • SIA-interrogación

  • SIA-contestación

Los paquetes EIGRP confiables fueron retransmitidos por lo menos 16 veces. Un paquete es cada retransmitido retransmite el Time Out (RTO). El mínimo RTO es el ms 200 y el máximo es el ms 5,000. El RTO aumenta o disminuye dinámicamente vía la observación de la diferencia de tiempo entre el tiempo que los paquetes EIGRP confiables están enviados y el tiempo que el acuse de recibo está recibido. Cuando el paquete confiable no se reconoce, el RTO aumenta. Si persiste esto, después el RTO aumenta hasta cinco segundos rápidamente, así que el límite de la recomprobación puede alcanzar 16 x 5 segundos = 80 segundos. Sin embargo, si el tiempo en espera del EIGRP es más grande de 80 segundos, la vecindad no va abajo hasta que haya expirado el tiempo en espera. Esto puede ocurrir en los links WAN lentos donde, por ejemplo, está 180 segundos el tiempo en espera predeterminado.

Para los links con los tiempos en espera baje que 80 segundos, esto significa con eficacia que si no expira el tiempo en espera, es continuada por los paquetes de saludo EIGRP. El límite de la recomprobación puede entonces ser excedido. Esto indica que hay un Problema de MTU o un problema del unicast. Los paquetes de saludo EIGRP son pequeños; (el primer) paquete de la Actualización de EIGRP puede estar hasta el MTU lleno. Será talla del MTU completa si hay bastantes prefijos para llenar la actualización. El vecino puede ser docto vía la recepción de los paquetes de saludo EIGRP, pero la adyacencia total no pudo tener éxito si el paquete de la Actualización de EIGRP no se reconoce.

Típicamente, ésta es la salida que aparece:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
retry limit exceeded
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency

Nota: A partir del Id. de bug Cisco CSCsc72090, el EIGRP también utiliza las configuraciones de MTU IP de la interfaz. Antes de que este arreglo fuera aplicado, los paquetes EIGRP se harían fragmentos si el IP MTU fue configurado con un valor que era más bajo de 1,500. Este problema puede ocurrir típicamente en las redes del Dynamic Multipoint VPN (DMVPN).

Una segunda posibilidad es que los paquetes de saludo EIGRP la hacen porque multicasted a la dirección IP 224.0.0.10. Algunos paquetes de la Actualización de EIGRP pudieron hacerla, como pueden multicasted. Sin embargo, los paquetes confiables retransmitidos del EIGRP son siempre unicast. Si la trayectoria de datos de unidifusión al vecino está quebrada, el paquete confiable retransmitido no procesa correctamente. Haga ping el Unicast IP Address del vecino EIGRP (con el tamaño del conjunto del ping a la talla del MTU completa del link, y con no haga fragmentos del bit (DF-bit) fijan) para verificar.

Un link de un sentido puede causar este problema también. El router EIGRP pudo recibir los paquetes de saludo EIGRP, pero los paquetes que se envían de este vecino no los hacen a través del link. Si los paquetes de saludo no lo hacen, el router está inconsciente porque los paquetes de saludo no fiable se envían. Los paquetes de la Actualización de EIGRP se envían que no serán reconocidos.

Los paquetes confiables del EIGRP o el acuse de recibo pueden corromperse. Una prueba rápida es enviar los ping con la validación de la contestación habilitada:

R1#ping
Protocol [ip]:
Target IP address: 10.1.1.2
Repeat count [5]: 10
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]: yes
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
Reply data will be validated
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/24/152 ms

Permita al comando debug eigrp packets para verificar la transmisión y la recepción de los paquetes de saludo EIGRP y de los paquetes de la Actualización de EIGRP en un mínimo:

R1#debug eigrp packets ?

  SIAquery  EIGRP SIA-Query packets
  SIAreply  EIGRP SIA-Reply packets
  ack       EIGRP ack packets
  hello     EIGRP hello packets
  ipxsap    EIGRP ipxsap packets
  probe     EIGRP probe packets
  query     EIGRP query packets
  reply     EIGRP reply packets
  request   EIGRP request packets
  retry     EIGRP retransmissions
  stub      EIGRP stub packets
  terse     Display all EIGRP packets except Hellos
  update    EIGRP update packets
  verbose   Display all EIGRP packets

Aquí está un Ejemplo ejemplo típico del problema excedido límite de la recomprobación:

R2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H   Address  Interface Hold Uptime   SRTT   RTO  Q  Seq
                       (sec)         (ms)       Cnt Num
3   10.1.1.1  Et0/0     12 00:00:48    1  5000  1  0
2   10.1.1.3  Et0/0     12 02:47:13   22   200  0  339
1   10.2.1.4  Et1/0     12 02:47:13   24   200  0  318
0   10.2.1.3  Et1/0     12 02:47:13   20   200  0  338 13   20   200  0  338

Nota: Hay siempre uno o más paquetes en la cola (Q Cnt).

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.1.1.1                Et0/0             10 00:00:59    1  5000  1  0
   Version 12.4/1.2, Retrans: 12, Retries: 12, Waiting for Init, Waiting for Init Ack
    UPDATE seq 349 ser 0-0 Sent 59472 Init Sequenced
2   10.1.1.3                Et0/0             11 02:47:23   22   200  0  339
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1   10.2.1.4                Et1/0             11 02:47:23   24   200  0  318
   Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0   10.2.1.3                Et1/0             10 02:47:23   20   200  0  338
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

Tal y como se muestra en de la salida, el r2 aguarda el primer paquete de actualización (conjunto de bits del init) del vecino en la dirección IP 10.1.1.1.

En esta salida siguiente, el r2 aguarda el acuse de recibo del primer paquete de actualización (conjunto de bits del init) del vecino en la dirección IP 10.1.1.1.

Nota: El RTO está en su máximo del ms 5,000, que indica que los paquetes confiables del EIGRP no están reconocidos en el plazo de los cinco segundos.

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.1.1.1                Et0/0             11 00:01:17    1  5000  1  0
   Version 12.4/1.2, Retrans: 16, Retries: 16, Waiting for Init, Waiting for Init Ack
    UPDATE seq 349 ser 0-0 Sent 77844 Init Sequenced
2   10.1.1.3                Et0/0             12 02:47:42   22   200  0  339
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1   10.2.1.4                Et1/0             10 02:47:42   24   200  0  318
   Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0   10.2.1.3                Et1/0             11 02:47:42   20   200  0  338
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

El número de retransmisiones sube constantemente. Es siempre el mismo paquete en la cola (349 seq). Después de que el r2 haya enviado esto el mismo paquete 16 veces, la vecindad va abajo:

R2#
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
retry limit exceeded
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency

El proceso comienza de nuevo:

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
3   10.1.1.1                Et0/0             11 00:00:08    1  4500  1  0
   Version 12.4/1.2, Retrans: 2, Retries: 2, Waiting for Init, Waiting for Init Ack
    UPDATE seq 350 ser 0-0 Sent 8040 Init Sequenced
2   10.1.1.3                Et0/0             11 02:47:56   22   200  0  339
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1   10.2.1.4                Et1/0             10 02:47:56   24   200  0  318
   Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0   10.2.1.3                Et1/0             11 02:47:56   20   200  0  338
   Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

La salida del comando conciso de los paquetes EIGRP del debug muestra que el r2 envía el mismo paquete una y otra vez:

Nota: El valor de reintentos aumenta, el valor de los indicadores es 0x1, y se fija el bit del init.

R2#debug eigrp packets terse

EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

R2#
EIGRP: Sending UPDATE on Ethernet0/0 nbr 10.1.1.1, retry 14, RTO 5000
AS 1, Flags 0x1, Seq 350/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
EIGRP: Sending UPDATE on Ethernet0/0 nbr 10.1.1.1, retry 15, RTO 5000
AS 1, Flags 0x1, Seq 350/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

El tiempo en espera no expira porque los paquetes de saludo se envían y se reciben correctamente:

R2#debug eigrp packets hello
EIGRP Packets debugging is on
    (HELLO)

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.1
  AS 1, Flags 0x0, Seq 0/0 idbQ 0/0

Par recomenzado

Si usted observa a un par recomenzado en varias ocasiones en un router, indica que el router recibe los paquetes de actualización iniciales de su vecino. Sea consciente del indicador 1 en los paquetes de actualización recibidos.

R2#deb eigrp packets terse

EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

R2#
EIGRP: Received Sequence TLV from 10.1.1.1
       10.1.1.2
       address matched
      clearing CR-mode
EIGRP: Received CR sequence TLV from 10.1.1.1, sequence 479
EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1
  AS 1, Flags 0xA, Seq 479/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0,
not in CR-mode, packet discarded
EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1
  AS 1, Flags 0x1, Seq 478/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
peer restarted
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency
EIGRP: Enqueueing UPDATE on Ethernet0/0 nbr 10.1.1.1 iidbQ un/rely 0/1
peerQ un/rely 0/0

Rubrique la actualización antes hola

Aquí está un ejemplo donde el paquete de actualización inicial se recibe antes del paquete de saludo:

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2
  AS 1, Flags 0x1, Seq 3/0 idbQ 0/0
EIGRP: Neighbor(10.1.1.2) not yet found

Si ocurre esto una vez después de que un flap vecino, después esta situación no es un problema. Sin embargo, si usted la experimenta a menudo, indica que el unicast en el link es operativo, pero el Multicast en el link está quebrado. Es decir el router recibe el paquete de actualización del unicast, pero no los paquetes de saludo.

Otros problemas

Algunos otros tipos de problema incluyen:

  • Cambios de configuración

  • Problemas de la autenticación

  • Discordancías en primario y las driección IP secundarias

  • Problemas DMVPN

Estos problemas se explican minuciosamente en las secciones que siguen.

Cambios de configuración

Nota: Los resultados de los comandos que se utilizan en esta sección son lo mismo si usted configura la negación en lugar de otro (el ningún comando).

Cuando usted configura la declaración sumaria (o el automóvil summary) en la interfaz, usted observa este mensaje en el router:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:
summary configured

Aquí está un ejemplo que muestra la configuración de una lista de distribución global para el proceso EIGRP:

R1(config-router)#distribute-list 1 out
R1(config-router)#

Este mensaje se observa en el router:

Nota: Lo mismo ocurre cuando usted configura un <> de la distribuir-lista adentro también.

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:
route configuration changed

Todos los vecinos EIGRP entonces van abajo de cuando usted configura una distribuir-lista de la interfaz para el proceso EIGRP:

R1(config-router)#distribute-list 1 out ethernet 0/0

En este caso, solamente las vecindades EIGRP en esta interfaz se reajustan.

Nota: Después del Id. de bug Cisco CSCdy20284, los neighborships no se reajustan para los cambios manuales tales como resumen y filtros.

Autenticación

La autenticación se puede configurar mal o falta. Esto puede hacer la vecindad EIGRP ir abajo debido al recomprobación-límite excedido. Permita al comando debug eigrp packets para confirmar que es la autenticación de la publicación de mensaje 5 (MD5) que causa el problema:

R1#debug eigrp packets

EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,
SIAREPLY)

EIGRP: Ethernet0/0: ignored packet from 10.1.1.3, opcode = 1 (missing
authentication or key-chain missing)

Discordancía en primario y las driección IP secundarias

El EIGRP envía hola y el resto de los paquetes del IP Address principal. Los paquetes se validan del otro router si las dirección IP de origen caen en el rango de IP Address principal o el que está de los rangos de driección IP secundaria en la interfaz. Si no, se observa este mensaje de error (cuando se habilitan las registro-vecino-advertencias del eigrp):

IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 10.1.1.2 not on common subnet
for Ethernet0/0

DMVPN

Comprobación para los problemas del IPSec en las redes DMVPN. El IPSec puede hacer el EIGRP agitar si el cifrado no es limpio:

show crypto ipsec sa

   protected vrf:
   local  ident (addr/mask/prot/port):  (10.10.110.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port):  (10.10.101.1/255.255.255.255/47/0)
   current_peer: 144.23.252.1:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 190840467, #pkts encrypt: 190840467, #pkts digest 190840467
    #pkts decaps: 158102457, #pkts decrypt: 158102457, #pkts verify 158102457
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 5523, #recv errors 42

Indicadores explicados

Hay un campo de 32 bits de los indicadores en la encabezado de paquetes EIGRP, y es útil entender las indicaciones de los diversos valores del indicador.

  • Bit del init del indicador 0x1

    Este indicador se fija en el paquete de actualización inicial.
    EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1
    AS 1, Flags 0x1, Seq 478/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
  • Indicador 0x2 

    Este indicador indica que condicional reciba el modo (CR-MODE). Esto es una parte del proceso confiable del Multicast del EIGRP y se utiliza para permitir a los vecinos que no han reconocido un paquete confiable anterior para alcanzar en un link compartido. Los direccionamientos en el Type Length Value de la secuencia (TLV) son los pares que deben ignorar los paquetes de multidifusión hasta que alcancen vía los paquetes de unidifusión.
    EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2
      AS 1, Flags 0x2, Seq 21/0 idbQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 0/1,
    not in CR-mode, packet discarded
  • Indicador 0x4

    Este indicador es el bit del reinicio (RS mordido). Se fija en los paquetes de saludo y los paquetes de actualización cuando se señala el NSF. Un router que reconoce NSF ve este bit para detectar si el router vecino recomienza. El vecino que detecta entonces sabe para continuar la adyacencia del EIGRP. El router que recomienza las opiniones este indicador para determinar si el par ayuda con el reinicio.
    EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.2
    AS 1, Flags 0x4, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
  • Indicador 0x8

    Éste es el bit de la Fin-de-tabla (EOT). Este bit indica que la tabla de ruteo completa se ha enviado al vecino. Un router con capacidad para NSF ve este bit para determinar si el router vecino ha completado su reinicio. Un router con capacidad para NSF espera este bit antes de que quite las rutas añejas del router que recomienza.
    EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2
      AS 1, Flags 0x8, Seq 4/33 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
    EIGRP: NSF: AS1. Receive EOT from 10.1.1.2

Los indicadores se imprimen en un número HEXADECIMAL. Así, el indicador 0x5 significa que los indicadores 4 y 1 están fijados; El indicador 0x9 significa que los indicadores 8 y 1 están fijados; El indicador 0xA significa que los indicadores 8 y 2 están fijados.

Usted puede utilizar estos comandos para resolver problemas a los vecinos del cambio:

  • muestre el detalle de la interfaz del eigrp

  • muestre a los detalles del vecino del eigrp del IP

  • haga ping el unicast

  • haga ping con el tamaño MTU lleno

  • el ping con “verifica los datos de la contestación”

  • Multicast del ping

  • paquetes EIGRP del debug (hola)

  • show ip eigrp traffic

  • muestre el tráfico del IP | comience el EIGRP

SIA

Esta sección proporciona una descripción del estado SIA, de algunos Síntomas posibles y de las causas, y cómo resolverla problemas.

Definición del SIA

El estado SIA significa que un router EIGRP no ha recibido una contestación a una interrogación de uno o más vecinos dentro del tiempo asignado (aproximadamente tres minutos). Cuando ocurre esto, el EIGRP borra a los vecinos que no envían una contestación y registra un mensaje de error DUAL-3-SIA para la ruta que fue active.

Síntomas

Estos mensajes se pueden considerar en un o mucho Routers:

%DUAL-3-SIA: Route 10.100.1.1/32 stuck-in-active state in IP-EIGRP(0) 1.  Cleaning up

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.6 (Serial3/0) is down:
stuck in active

Si ocurre esto solamente esporádico, puede ser ignorada. Si ocurre con frecuencia, indica un problema de red persistente.

Posibles Causas

Aquí están algunas posibles causas para un estado SIA:

  • Links inestables

  • Malos links

  • Rutas inestables

  • Links congestionados

  • Diámetro de la Red grande (rango grande de la interrogación)

  • Insuficiencia de memoria

  • CPU elevada

  • Misconfiguration (valor de ancho de banda incorrecto)

Consejos de Troubleshooting

Cuando una situación SIA ocurre, hay un problema en alguna parte en la red. La causa exacta puede ser difícil de descubrir. Hay dos acercamientos:

  • Vea los prefijos que están señalados constantemente como SIA y determine las concordancias.

  • Localice al router que no puede constantemente contestar a las interrogaciones para estas rutas.

Determine si todos los prefijos para los cuales el SIA está señalado tienen concordancias. Por ejemplo, todos los puede ser que sean rutas de /32 del borde de la red (por ejemplo en las redes de dial up). Si es así puede ser que indique la ubicación del problema en la red (a saber, donde estos prefijos originados).

En última instancia, usted debe descubrir la ubicación en donde los routeres o más envían las interrogaciones y no reciben las contestaciones, mientras que el router en sentido descendente no está en este estado. Por ejemplo, el router podría enviar las interrogaciones y se reconocen, pero la contestación del router en sentido descendente no se recibe.

Usted puede utilizar el comando show ip eigrp topology active para ayudar a resolver problemas el problema SIA. Busque el pequeño r en la salida de comando. Esto significa que el router aguarda una contestación a una interrogación para ese prefijo de ese vecino.

Aquí está un ejemplo. Vea la topología. Se apagan los links R1-R6 y R1-R5. Cuando el Loopback Interface del r1 del router se apaga, el r1 envía una interrogación para el prefijo 10.100.1.1/32 al r2 y al R3. El r1 del router es activo ahora para este prefijo. El r2 del Routers y el R3 van active e interrogación a su vez el router R4, que va active y envía una interrogación al R5. El router R5 finalmente va active y envía una interrogación al R6. El router R6 debe volver una contestación al R5. El router R5 va voz pasiva y contesta al R4, que a su vez va voz pasiva y envía una contestación al r2 y al R3. Finalmente, el r2 y el R3 van voz pasiva y envían una contestación al r1, que va voz pasiva otra vez.

Si se encuentra un problema, después un router puede permanecer activo por un tiempo extendido, pues debe esperar una contestación. Para prevenir al router que espera una contestación que pudo nunca ser recibida, el router puede declarar el SIA y matar a la vecindad con la cual aguarda la contestación. Para resolver problemas el problema, ver el comando show ip eigrp topology active hizo salir y sigue el rastro del R.

Aquí está la salida para el r1 del router:

R1#show ip eigrp topology active
IP-EIGRP Topology Table for AS 1)/ID(10.100.1.1)

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

A 10.100.1.1/32, 1 successors, FD is Inaccessible
    1 replies, active 00:01:11, query-origin: Local origin
        via Connected (Infinity/Infinity), Loopback0
      Remaining replies:
         via 10.1.1.2, r, Ethernet0/0

El r1 del router es activo y aguarda una contestación del r2. Aquí está la salida para el r2 del router:

R2#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.2)

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

A 10.100.1.1/32, 1 successors, FD is Inaccessible
    1 replies, active 00:01:01, query-origin: Successor Origin
        via 10.1.1.1 (Infinity/Infinity), Ethernet0/0
        via 10.2.1.4 (Infinity/Infinity), r, Ethernet1/0, serno 524
        via 10.2.1.3 (Infinity/Infinity), Ethernet1/0, serno 523

El r2 del router es activo y aguarda una contestación del R4. Aquí está la salida para el router R4:

R4#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.4)

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

A 10.100.1.1/32, 1 successors, FD is Inaccessible
    1 replies, active 00:00:56, query-origin: Successor Origin
        via 10.2.1.2 (Infinity/Infinity), Ethernet1/0
        via 172.16.1.5 (Infinity/Infinity), r, Serial2/0, serno 562
        via 10.2.1.3 (Infinity/Infinity), Ethernet1/0, serno 560

El router R4 es activo y aguarda una contestación del R5. Aquí está la salida para el router R5:

R5#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(172.16.1.5)

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

A 10.100.1.1/32, 1 successors, FD is Inaccessible, Q
    1 replies, active 00:00:53, query-origin: Successor Origin
        via 172.16.1.4 (Infinity/Infinity), Serial2/0
      Remaining replies:
         via 192.168.1.6, r, Serial3/0

El router R5 es activo y aguarda una contestación del R6. Aquí está la salida para el router R6:

R6#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(192.168.1.6)
R6#

Como se muestra, el router R6 no es activo para el prefijo, así que el problema debe estar entre el Routers R5 y R6. Después de una cierta hora, vemos que el R5 mata a la vecindad al R6 y declara un estado SIA:

R5#
%DUAL-3-SIA: Route 10.100.1.1/32 stuck-in-active state in IP-EIGRP(0) 1.
  Cleaning up
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.6 (Serial3/0) is down:
stuck in active

Cuando usted ve la salida para el router R5, usted puede ver que hay problemas en el link hacia el R6.

Éste es nuevo código SIA, y como tal, el SIA ocurrió en un router que estaba al lado del problema. En este ejemplo, éste es el link entre el Routers R5 y R6. En más viejas versiones del código, el SIA se podría declarar en cualquier router a lo largo de la trayectoria (por ejemplo en el r2), que pudo ser distante del problema. El temporizador SIA era tres minutos. Cualquier router a lo largo de la trayectoria podría ser el primer a ir SIA y para matar a las vecindades. Con el más nuevo código, el router aguarda una contestación, intermedio envía una interrogación SIA a su vecino, y las respuestas del vecino con un SIA contestan inmediatamente. Por ejemplo, mientras que en el estado activo, el router R4 envía una interrogación SIA al R5, y las contestaciones R5 con un SIA contestan.

R5#
EIGRP: Received SIAQUERY on Serial2/0 nbr 172.16.1.4
  AS 1, Flags 0x0, Seq 456/447 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
EIGRP: Enqueueing SIAREPLY on Serial2/0 nbr 172.16.1.4 iidbQ un/rely 0/1
peerQ un/rely 0/0 serno 374-374
EIGRP: Sending SIAREPLY on Serial2/0 nbr 172.16.1.4
  AS 1, Flags 0x0, Seq 448/456 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
serno 374-374

El router R5 también envía las interrogaciones SIA al R6, pero no recibe una contestación SIA del R6.

R5#
EIGRP: Enqueueing SIAQUERY on Serial3/0 nbr 192.168.1.6 iidbQ un/rely 0/2
peerQ un/rely 5/0 serno 60-60

Una vez que el router envía una interrogación SIA pero no recibe una contestación SIA, el s aparece para ese vecino:

R5#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(172.16.1.5)

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

A 10.100.1.1/32, 1 successors, FD is Inaccessible, Qqr
    1 replies, active 00:02:36, query-origin: Successor Origin, retries(1)
        via 1172.16.1.4 (Infinity/Infinity), Serial2/0, serno 61
        via 192.168.1.6 (Infinity/Infinity), rs, q, Serial3/0, serno 60, anchored

Con el nuevo código SIA, el SIA se debe declarar en el router R5 cuando no recibe una contestación SIA. Usted debe entonces habilitar el debugging para estos dos paquetes del EIGRP SIA:

R2#debug eigrp packets SIAquery SIAreply

EIGRP Packets debugging is on
    (SIAQUERY, SIAREPLY)

R2#show deb
EIGRP:
  EIGRP Packets debugging is on
    (SIAQUERY, SIAREPLY)

En resumen, usted puede utilizar estos comandos para resolver problemas el problema SIA:

  • show ip eigrp topology active

  • muestre el IP Evento eigrp (aumente posiblemente el tamaño del registro de acontecimientos)

  • muestre el tráfico del eigrp del IP (la búsqueda para muchas interrogaciones SIA y las contestaciones SIA)

  • muestre el mem del proc

  • muestre la suma del mem

Aquí están algunas Soluciones posibles para el problema SIA:

  • Repare el problema de link.

  • Aplique el resumen (manual o automático) en las redes con muchos prefijos o un rango profundo de la interrogación.

  • Utilice las distribuir-listas para disminuir el rango de la interrogación.

  • Defina a los routeres remotos como trozos.

Prefijos que falta

Hay dos tipos de prefijos que falta: los que faltan en la tabla de ruteo (o el Routing Information Base (RIB)), y los que faltan en la tabla de topología.

Prefijos que falta en el RIB

Puede haber varias razones que un prefijo no está incluido en el RIB:

  • El prefijo es instalado en la tabla de ruteo por otro Routing Protocol con una distancia administrativa menor.

  • Una distribuir-lista bloquea el prefijo.

  • Un horizonte partido bloquea el prefijo.

Prefijo instalado por el Routing Protocol con la distancia administrativa menor

En este ejemplo, el prefijo es instalado en la tabla de ruteo por una Static ruta o un Routing Protocol con una distancia administrativa menor.

Típicamente cuando ocurre esto, el prefijo está en la tabla de topología pero no tiene ningún sucesor. Usted puede ver todas estas entradas con el comando de los cero-sucesores de la topología EIGRP del IP de la demostración. El feasible distance (FD) debe tener un valor infinito.

Ingrese el comando de la ruta de IP de la demostración <prefix> y verifique los Routing Protocol esos los propio la ruta en el RIB:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
  Routing Descriptor Blocks:
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (2297856/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 25000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
R1#show ip eigrp topology zero-successors
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

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

P 192.168.1.0/24, 0 successors, FD is Inaccessible
        via 10.3.1.6 (2681856/2169856), Serial2/0
P 192.168.100.6/32, 0 successors, FD is Inaccessible
        via 10.3.1.6 (2297856/128256), Serial2/0

La Distribuir-lista bloquea el prefijo

El EIGRP es un Distance Vector Routing Protocol. Usted puede utilizar una distribuir-lista en cualquier prefijo de bloque del router para. Usted puede utilizarlo en una interfaz para parar los prefijos de ser enviado o recepción, o usted puede configurar la distribuir-lista global bajo proceso EIGRP del router para aplicar el filtro de ruteo en todas las interfaces Eigrp-habilitadas.

Aquí tiene un ejemplo:

R1#show running-config | begin router eigrp

router eigrp 1
network 10.0.0.0
distribute-list 1 in
no auto-summary
!
access-list 1 deny   192.168.100.6
access-list 1 permit any

Prefijos que falta en la tabla de topología

Esta sección describe algunas de las razones que un prefijo pudo faltar de la tabla de topología.

Especificación de la máscara para la salida de comando apropiada

No incurra en la equivocación típica; cuando usted verifica un prefijo en la tabla de topología, especifique siempre la máscara. Esto ocurre si usted no utiliza la máscara:

R1#show ip eigrp topology 192.168.100.6   
% IP-EIGRP (AS 1): Route not in topology table

Aquí está el comando show ip eigrp topology hecho salir cuando se especifica la máscara:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
  Routing Descriptor Blocks:
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (2297856/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 25000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x
      Composite metric is (2323456/2297856), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 26000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

Como se muestra, el prefijo está presente en la tabla de topología.

El horizonte partido bloquea el prefijo

Esta sección describe otro error común. El EIGRP no es un protocolo Link-State Routing, sino que es bastante un Distance Vector Routing Protocol. La tabla de topología se debe utilizar para la operación correcta del algoritmo de actualización Diffuse (DUAL), no porque el EIGRP es un protocolo Link-State Routing; por lo tanto, requiere una base de datos. Se requiere la tabla de topología porque solamente las mejores rutas están instaladas en la tabla de ruteo, mientras que las demandas DUALES que las rutas factibles están monitoreadas también. Éstos se salvan en la tabla de topología.

Usted debe siempre tener la ruta del sucesor y las rutas factibles en la tabla de topología. Si no, hay un bug. Sin embargo, podría también haber rutas NON-posibles en la tabla de topología, mientras se reciban. Si no se reciben de un vecino, podría haber un horizonte partido que bloquea el prefijo.

La salida del comando show ip eigrp topology muestra solamente las entradas del prefijo que punta a los sucesores y a los sucesores factibles. Si usted quiere ver los prefijos que se reciben sobre todas las trayectorias (también trayectorias NON-posibles), después ingrese el comando show ip eigrp topology all-links en lugar de otro.

Aquí tiene un ejemplo:

R1#show ip eigrp topology          
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

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

P 10.3.1.0/24, 1 successors, FD is 2169856
        via Connected, Serial2/0
P 10.2.1.0/24, 2 successors, FD is 307200
        via 10.1.1.2 (307200/281600), Ethernet0/0
        via 10.1.1.3 (307200/281600), Ethernet0/0
P 10.1.1.0/24, 1 successors, FD is 281600
        via Connected, Ethernet0/0
P 172.16.1.0/24, 1 successors, FD is 2195456
        via 10.4.1.5 (2195456/2169856), Ethernet1/0
P 192.168.1.0/24, 1 successors, FD is 2195456
        via 10.4.1.5 (2195456/2169856), Ethernet1/0
        via 10.3.1.6 (2681856/2169856), Serial2/0
P 10.4.1.0/24, 1 successors, FD is 281600
        via Connected, Ethernet1/0
P 172.16.100.5/32, 1 successors, FD is 409600
        via 10.4.1.5 (409600/128256), Ethernet1/0
P 10.100.1.4/32, 2 successors, FD is 435200
        via 10.1.1.2 (435200/409600), Ethernet0/0
        via 10.1.1.3 (435200/409600), Ethernet0/0
P 10.100.1.3/32, 1 successors, FD is 409600
        via 10.1.1.3 (409600/128256), Ethernet0/0
P 10.100.1.2/32, 1 successors, FD is 409600
        via 10.1.1.2 (409600/128256), Ethernet0/0
P 10.100.1.1/32, 1 successors, FD is 128256
        via Connected, Loopback0
P 192.168.100.6/32, 1 successors, FD is 2297856
        via 10.3.1.6 (2297856/128256), Serial2/0

En esta salida usted puede ver que la porción de los todo-links del comando incluye más trayectorias:

R1#show ip eigrp topology all-links   
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

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

P 10.3.1.0/24, 1 successors, FD is 2169856, serno 43
        via Connected, Serial2/0
P 10.2.1.0/24, 2 successors, FD is 307200, serno 127
        via 10.1.1.2 (307200/281600), Ethernet0/0
        via 10.1.1.3 (307200/281600), Ethernet0/0
P 10.1.1.0/24, 1 successors, FD is 281600, serno 80
        via Connected, Ethernet0/0
P 172.16.1.0/24, 1 successors, FD is 2195456, serno 116
        via 10.4.1.5 (2195456/2169856), Ethernet1/0
        via 10.3.1.6 (3193856/2681856), Serial2/0
        via 10.1.1.2 (2221056/2195456), Ethernet0/0
        via 10.1.1.3 (2221056/2195456), Ethernet0/0
P 192.168.1.0/24, 1 successors, FD is 2195456, serno 118
        via 10.4.1.5 (2195456/2169856), Ethernet1/0
        via 10.3.1.6 (2681856/2169856), Serial2/0
P 10.4.1.0/24, 1 successors, FD is 281600, serno 70
        via Connected, Ethernet1/0
P 172.16.100.5/32, 1 successors, FD is 409600, serno 117         
        via 10.4.1.5 (409600/128256), Ethernet1/0
        via 10.3.1.6 (2809856/2297856), Serial2/0
P 10.100.1.4/32, 2 successors, FD is 435200, serno 128
        via 10.1.1.2 (435200/409600), Ethernet0/0
        via 10.1.1.3 (435200/409600), Ethernet0/0
P 10.100.1.3/32, 1 successors, FD is 409600, serno 115
        via 10.1.1.3 (409600/128256), Ethernet0/0
P 10.100.1.2/32, 1 successors, FD is 409600, serno 109
        via 10.1.1.2 (409600/128256), Ethernet0/0
P 10.100.1.1/32, 1 successors, FD is 128256, serno 4
        via Connected, Loopback0
P 192.168.100.6/32, 1 successors, FD is 2297856, serno 135
        via 10.3.1.6 (2297856/128256), Serial2/0
        via 10.4.1.5 (2323456/2297856), Ethernet1/0

Considere el prefijo más reciente de la salida anterior; la trayectoria vía 10.4.1.5 tiene (2323456/2297856). La distancia informada (medición anunciada) es 2297856, que no es más pequeña que el FD de 2297856, así que la trayectoria no es posible.

P 192.168.100.6/32, 1 successors, FD is 2297856, serno 135
        via 10.3.1.6 (2297856/128256), Serial2/0
        via 10.4.1.5 (2323456/2297856), Ethernet1/0

Aquí está un ejemplo donde un horizonte partido hace una trayectoria ser excluido de la tabla de topología para una ruta. Cuando usted ve la topología, usted puede ver que el r1 del router tiene el prefijo 192.168.100.6/32 vía el R6 y el R5 en la tabla de topología, pero no vía el r2 o el R3:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
  Routing Descriptor Blocks:
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (2297856/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 25000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
      Composite metric is (2323456/2297856), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 26000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

Esto es porque el r1 del router nunca recibió el prefijo 192.168.100.6/32 vía el r2 o el R3, pues tienen el prefijo 192.168.100.6/32 vía el r1 en la tabla de ruteo.

R2#show ip route 192.186.100.6 255.255.255.255
Routing entry for 192.168.100.6/32
  Known via "eigrp 1", distance 90, metric 2323456, type internal
  Redistributing via eigrp 1
  Last update from 10.1.1.1 on Ethernet0/0, 00:02:07 ago
  Routing Descriptor Blocks:
  * 10.1.1.1, from 10.1.1.1, 00:02:07 ago, via Ethernet0/0
      Route metric is 2323456, traffic share count is 1
      Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

R3#show ip route 192.168.100.6 255.255.255.255
Routing entry for 192.168.100.6/32
  Known via "eigrp 1", distance 90, metric 2323456, type internal
  Redistributing via eigrp 1
  Last update from 10.1.1.1 on Ethernet0/0, 00:01:58 ago
  Routing Descriptor Blocks:
  * 10.1.1.1, from 10.1.1.1, 00:01:58 ago, via Ethernet0/0
      Route metric is 2323456, traffic share count is 1
      Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

Para verificar esto, utilice la palabra clave de los todo-links en el r1 cuando usted ve la tabla de topología. El muestra todas las trayectorias para todos los prefijos, que incluye las trayectorias NON-posibles. Usted puede entonces ver que el prefijo 192.168.100.6/32 no ha sido aprendido por el r1 del router del r2 o del R3.

Métrica

Nota: El MTU y el conteo saltos no se incluyen en el cálculo de medición.

Éstas son las fórmulas que se utilizan para calcular la trayectoria métrica de una ruta:

  • Si el K5 es un valor sin cero:

    EIGRP = 256*(((K1*Bw) métrico + (K2*Bw)/(256-Load) + (K3*Delay))*(K5/(Reliability + K4)))

  • Si el K5 es igual a cero:

    EIGRP = 256*((K1*Bw) métrico + (K2*Bw)/(256-Load) + (K3*Delay))

Los valores K son las ponderaciones que se utilizan para cargar los cuatro componentes del EIGRP métrico: retardo, ancho de banda, confiabilidad, y carga. Éstos son los valores K predeterminados:

  • K1 = 1

  • K2 = 0

  • K3 = 1

  • K4 = 0

  • K5 = 0

Con los valores K predeterminados (solamente usando el ancho de banda y el retardo), la fórmula se convierte:

EIGRP métrico = 256 * (bw + retardo)

Bw= (bw 10^7/minimum en los kilobites por segundo)

Nota: El retardo se mide en las decenas de microsegundos; sin embargo, en la interfaz, se mide en los microsegundos.

Todos los cuatro componentes se pueden verificar con el comando show interface:

 R1#show interface et 0/0
Ethernet0/0 is up, line protocol is up
  Hardware is AmdP2, address is aabb.cc00.0100 (bia aabb.cc00.0100)
  Internet address is 10.1.1.1/24
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00  Last input 00:00:02, output 00:00:02,
output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     789 packets input, 76700 bytes, 0 no buffer
     Received 707 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     548 packets output, 49206 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

El retardo es acumulativo, así que significa que usted agrega el retardo de cada link a lo largo de la trayectoria. El ancho de banda no es acumulativo, tan el ancho de banda que se utiliza en la fórmula es el ancho de banda más pequeño de cualquier link a lo largo de la trayectoria.

ID de router duplicado

Para ver el Router ID que el EIGRP utiliza, ingrese el comando show ip eigrp topology en el router y vea la primera línea de la salida:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

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

P 10.3.1.0/24, 1 successors, FD is 2169856
        via Connected, Serial2/0

No utilizan al router EIGRP ID en absoluto para las rutas interno en más viejas versiones deL Cisco IOS. Un ID de router duplicado para el EIGRP no debe causar ninguna problemas si solamente se utilizan las rutas interno. En un más nuevo Cisco IOS Software, las rutas interno del EIGRP llevan al router EIGRP ID.

El Router ID para las rutas externo se puede ver en esta salida:

R1#show ip eigrp topology 192.168.1.4 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.1.4/32
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 435200
  Routing Descriptor Blocks:
  10.1.1.2 (Ethernet0/0), from 10.1.1.2, Send flag is 0x0
      Composite metric is (435200/409600), Route is External
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 7000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
      External data&colon;
        Originating router is 10.100.1.4 
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)

Si una ruta EIGRP (externa) con el mismo router EIGRP ID que el router se recibe, no genera una entrada de registro. Sin embargo, Evento eigrp el registro captura esto. Cuando usted marca para saber si hay la ruta EIGRP (externa), no aparece en la tabla de topología.

Marque Evento eigrp el registro para los mensajes posibles del ID de router duplicado:

R1#show ip eigrp events                             
Event information for AS 1:
1    08:36:35.303 Ignored route, metric: 10.33.33.33 3347456
2    08:36:35.303 Ignored route, neighbor info: 10.3.1.6 Serial2/1
3    08:36:35.303 Ignored route, dup router: 10.100.1.1
4    08:36:35.303 Rcv EOT update src/seq: 10.3.1.6 143
5    08:36:35.227 Change queue emptied, entries: 2
6    08:36:35.227 Route OBE net/refcount: 10.100.1.4/32 3
7    08:36:35.227 Route OBE net/refcount: 10.2.1.0/24 3
8    08:36:35.227 Metric set: 10.100.1.4/32 435200
9    08:36:35.227 Update reason, delay: nexthop changed 179200
10   08:36:35.227 Update sent, RD: 10.100.1.4/32 435200
11   08:36:35.227 Route install: 10.100.1.4/32 10.1.1.3
12   08:36:35.227 Route install: 10.100.1.4/32 10.1.1.2
13   08:36:35.227 RDB delete: 10.100.1.4/32 10.3.1.6

Los valores K unen mal/Cierre elegante

Cuando los valores K no son lo mismo en los routeres vecinos, se observa este mensaje:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch

Los valores K se configuran con este comando (con los valores posibles de K entre 0 y 255):

metric weights tos k1 k2 k3 k4 k5

!
router eigrp 1
network 10.0.0.0
metric weights 0 1 2 3 4 5
!

El mensaje indica que la vecindad EIGRP no está establecida debido a una discordancía en los valores K. Los valores K deben ser lo mismo en todos los routeres EIGRP en un sistema autónomo para prevenir los problemas de ruteo cuando diverso Routers utiliza los cálculos de la métrica diferente.

Marque si los valores K son lo mismo en los routeres vecinos. Si los valores K son lo mismo, el problema se pudo causar por la característica del Cierre elegante del EIGRP. En ese caso, un router envía un paquete de saludo EIGRP con los valores K fijados a 255 de modo que ocurra la discordancía de los valores K intencionalmente. Éste es indicar al router EIGRP vecino que va abajo. En el router vecino, usted vería este Mensaje de adiós recibido:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
Interface Goodbye received

Sin embargo, si el router vecino funciona con una más vieja versión del código (antes del Id. de bug Cisco CSCdr96531), no reconoce esto como mensaje del Cierre elegante, sino como una discordancía en los valores K:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch

Éste es el mismo mensaje que en el caso de una discordancía verdadera de los valores K en los routeres vecinos.

Éstos son los activadores para un Cierre elegante:

  • No se ingresa al ningún comando router eigrp.

  • No se ingresa al ningún comando network.

  • Ingresan al comando ip eigrp neighbor claro.

  • Recargan al router.

Un Cierre elegante se utiliza para acelerar la detección de un estado inactivo vecino. Sin un Cierre elegante, un vecino debe esperar hasta que expire el tiempo en espera antes de que declare al vecino estar abajo.

Equilibrio de carga del costo desigual (variación)

El Equilibrio de carga del costo desigual es posible en el EIGRP con el comando variance, pero la variación y las condiciones de viabilidad deben ser cumplidas.

La condición de la variación significa que el métrico de la ruta no es más grande que el mejor métrico multiplicado por la variación. Para que una ruta sea considerada posible, la ruta se debe haber hecho publicidad con una distancia informada que sea más baja que el feasible distance (FD). Aquí tiene un ejemplo:

!
router eigrp 1
variance 2
network 10.0.0.0
no auto-summary
!

El r1 del router tiene una variación 2 configurada. Esto significa que si el router tiene otra trayectoria para la ruta con un métrico que no sea más grande de dos veces el mejor métrico para esa ruta, debe haber Equilibrio de carga del costo desigual para esa ruta.

R1#show ip eigrp topology 172.16.100.5 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 172.16.100.5/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
  Routing Descriptor Blocks:
  10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
      Composite metric is (409600/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 6000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (435200/409600), Route is Internal <<< RD = 409600
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 7000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

Si la segunda entrada de la topología está instalada en la tabla de ruteo, el métrico de la segunda entrada de la topología es 435200. Puesto que el mejor métrico es dos veces 2 x 409600 = 819200, y 435200 < 819200, la segunda entrada de la topología está dentro del rango de la variación. La distancia informada de la segunda entrada de la topología es 409600, que no es más pequeña que FD = 409600. La segunda condición (viabilidad) no se cumple, y la segunda entrada no se puede instalar en el RIB.

R1#show ip route 172.16.100.5
Routing entry for 172.16.100.5/32
  Known via "eigrp 1", distance 90, metric 409600, type internal
  Redistributing via eigrp 1
  Last update from 10.4.1.5 on Ethernet1/0, 00:00:16 ago
  Routing Descriptor Blocks:
  * 10.4.1.5, from 10.4.1.5, 00:00:16 ago, via Ethernet1/0
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Si el RD de la segunda entrada de la topología es más pequeño entonces el FD, como en el próximo ejemplo, habría Equilibrio de carga del costo desigual.

R1#show ip eigrp topology 172.16.100.5 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 172.16.100.5/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
  Routing Descriptor Blocks:
  10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
      Composite metric is (409600/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 6000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (434944/409344), Route is Internal <<< RD = 409344
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 6990 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

Ambas entradas de la topología ahora están en la tabla de ruteo:

R1#show ip route 172.16.100.5                         
Routing entry for 172.16.100.5/32
  Known via "eigrp 1", distance 90, metric 409600, type internal
  Redistributing via eigrp 1
  Last update from 10.3.1.6 on Serial2/0, 00:00:26 ago
  Routing Descriptor Blocks:
  * 10.4.1.5, from 10.4.1.5, 00:00:26 ago, via Ethernet1/0
      Route metric is 409600, traffic share count is 120
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
    10.3.1.6, from 10.3.1.6, 00:00:26 ago, via Serial2/0
      Route metric is 434944, traffic share count is 113
      Total delay is 6990 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

Vecinos estáticos

Las configuraciones de los soportes del EIGRP con uno o más vecinos estáticos en lo mismo interfaz. Tan pronto como usted configure a un vecino EIGRP estático en la interfaz, el router envía no más los paquetes EIGRP como Multicast en esa interfaz o procesa los paquetes EIGRP multicasted recibidos. Esto significa que los paquetes hola, de la actualización, y de la interrogación ahora unicasted. Ningunos neighborships adicionales pueden ser formados a menos que el comando del vecino estático se configure explícitamente para esos vecinos en esa interfaz.

Éste es cómo configurar a un vecino EIGRP estático:

router eigrp 1
passive-interface Loopback0
network 10.0.0.0
no auto-summary
neighbor 10.1.1.1 Ethernet0/0
!

Cuando el Routers a ambos lados del link tiene el comando del vecino estático, se forma la vecindad:

R1#show ip eigrp neighbors detail
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                          (sec)         (ms)       Cnt Num
1   10.1.1.2                Et0/0             14 00:00:23   27   200  0  230
   Static neighbor
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1
0   10.3.1.6                Se2/0             14 1d02h      26   200  0  169
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 12
3   10.4.1.5                Et1/0             10 1d02h      16   200  0  234
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 7

Si solamente un router hace el comando del vecino estático configurar, usted observará que el router ignora los paquetes EIGRP multicasted y el otro router ignora los paquetes EIGRP unicasted:

R1#
EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.2
  AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
EIGRP: Ignore multicast Hello Ethernet0/0 10.1.1.2
R2#
EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.1
  AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
EIGRP: Ignore unicast Hello from Ethernet0/0 10.1.1.1

Hay comando debug especial para los vecinos estáticos del EIGRP:

R2#debug eigrp neighbors static
EIGRP Static Neighbors debugging is on

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router eigrp 1              
R2(config-router)#neighbor 10.1.1.1 et 0/0
R2(config-router)#end
R2#

EIGRP: Multicast Hello is disabled on Ethernet0/0!
EIGRP: Add new static nbr 10.1.1.1 to AS 1 Ethernet0/0

Aquí están algunas razones que los vecinos EIGRP estáticos pudieron ser configurados:

  • Usted quiere limitar o evitar los broadcasts en las redes del Non-Broadcast Multi-Access (NBMA).

  • Usted quiere limitar o evitar los Multicast en los medios de broadcast (Ethernetes).

  • Para los propósitos de Troubleshooting (usando el unicast en vez del Multicast).

Precaución: No configure el comando passive-interface así como el comando estático del vecino EIGRP.

Redistribución de la Static ruta

Cuando usted configura una Static ruta que señale a una interfaz, y a la ruta es cubierto por una declaración de la red bajo el EIGRP del router, después la Static ruta es hecha publicidad por el EIGRP como si fuera un Routeconectad. No requieren al comando redistribute static o un métrico predeterminado en este caso.

router eigrp 1
network 10.0.0.0
network 172.16.0.0
no auto-summary
!
ip route 172.16.0.0 255.255.0.0 Serial2/0
!
R1#show ip eigrp top 172.16.0.0 255.255.0.0      
IP-EIGRP (AS 1): Topology entry for 172.16.0.0/16
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2169856
  Routing Descriptor Blocks:
  0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (2169856/0), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 20000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0

Confiabilidad y carga para el cálculo de medición

Precaución: La confiabilidad y/o la carga de uso para calculan la métrica.

La confiabilidad y los parámetros de carga aparecen en la salida del comando show interface. No hay actualizaciones dinámicas para estos parámetros cuando la carga y la confiabilidad cambian. Si la carga y la confiabilidad cambian, no acciona un cambio inmediato en el métrico. Solamente si el EIGRP decide a enviar las actualizaciones a sus vecinos debido a los cambios de la topología quieren el cambio en la carga y se propague la confiabilidad. Además, el uso de la carga y de la confiabilidad para calcular el métrico puede introducir la inestabilidad, pues el ruteo adaptable entonces se realiza. Si usted desea de cambiar la encaminamiento de acuerdo con la carga de tráfico, después usted debe considerar el uso de la ingeniería de tráfico o de la encaminamiento del funcionamiento (PfR) del Multiprotocol Label Switching (MPLS).

CPU elevada

Hay tres procesos EIGRP que se ejecutan simultáneamente:

  • Router – Este proceso celebra a los pools de memoria compartida.

  • Hola – Este proceso envía y recibe los paquetes de saludo y mantiene las conexiones de peer.

  • Módulo dependiente de protocolo (PDM) – El EIGRP apoya a cuatro Conjuntos de protocolos: IP, IPv6, IPX, y APPLETALK. Cada habitación tiene su propio PDM. Aquí están las funciones primarias del PDM:

    • Mantiene el vecino y las tablas de topología de los routeres EIGRP que pertenecen a ese Conjunto de protocolos.

    • Las estructuras y traducen los paquetes del protocol específico para DUAL (transmisión y recepción de los paquetes EIGRP).

    • Las interfaces SE DOBLAN a la tabla de ruteo del protocol específico.

    • Computa el métrico y pasa la información PARA DOBLARSE (SE DOBLAN solamente las selecciones los sucesores y los sucesores factibles).

    • Filtración y listas de acceso Implements.

    • Realiza las funciones de la redistribución a y desde los otros Routing Protocol.

Aquí está una salida de ejemplo que muestra estos tres procesos:

R1#show proc cpu | include EIGRP
  89           4        24        166  0.00%  0.00%  0.00%   0 IP-EIGRP Router 
  90        1016      4406        230  0.00%  0.03%  0.00%   0 IP-EIGRP: PDM   
  91        2472      6881        359  0.00%  0.07%  0.08%   0 IP-EIGRP: HELLO

CPU elevada en el EIGRP no es normal. Si ocurre esto, o el EIGRP tiene demasiado a hacer o hay un bug en el EIGRP. En el primer caso, marque el número de prefijos en la tabla de topología y el número de pares. Marque para saber si hay inestabilidad entre las rutas EIGRP y los vecinos.

EIGRP en las redes Frame Relay (cola de broadcast)

En las redes Frame Relay donde hay Routers de los varios vecinos en una interfaz punto a multipunto, allí puede ser mucho el broadcast o los paquetes de multidifusión que deben ser transmitidos. Por este motivo, hay una cola de broadcast separada con sus propios buffers. La cola de broadcast tiene prioridad cuando transmite a una tarifa debajo del Máximo configurado y tiene una asignación de ancho de banda mínimo garantizada.

Aquí está el comando que se utiliza en este escenario:

frame-relay broadcast-queue size byte-rate packet-rate

Como regla general, comience con veinte paquetes por el identificador de conexión de link de datos (DLCI). La velocidad de byte debe ser menos que ambos:

  • El N/4 mide el tiempo de la tarifa de Acceso Remoto mínima (medida en los bytes por segundo), donde está el número N de DLCI a los cuales el broadcast deba ser replicado.

  • Un cuarto de la tarifa de Acceso local (medida en los bytes por segundo).

Si usted observa a un gran número de vecinos EIGRP el agitar, aumente el tamaño de la cola de broadcast del Frame Relay. Este problema no está presente si hay subinterfaces del Frame Relay porque cada router vecino está en una subinterfaz con una diversa subred IP. Considere esto como solución alternativa cuando hay una red Frame Relay grande, completamente adetnra.

Unido mal COMO números

Cuando usted ingresa el comando de los paquetes EIGRP del debug hola, revela que el router no recibe los paquetes de saludo.

Automóvil summary

El EIGRP usado para realizar el resumen en la red principal (redes A, B, y C) límites por abandono. Esto significa que rutas más específicas que los prefijos de /8 para la red principal teclean A, rutas más específicas que los prefijos de /16 para el tipo B de la red principal, y rutas más específicas que los prefijos de /24 para las redes principales teclean el C, se pierden cuando cruzan sus límites. Aquí está un ejemplo donde el automóvil summary causa un problema:

Como se muestra, el r1 del Routers y el R3 tienen automóvil summary bajo el EIGRP del router. El r2 del router recibe 10.0.0.0/8 del r2 del Routers y del R3 porque el r2 y el R3 son routeres delimitadores entre la red 10.0.0.0/8 y 172.16.0.0/16 de la clase importante A. El r2 del router puede tener la ruta 10.0.0.0/8 vía el r1 y el R3 si el métrico sucede ser lo mismo. Si no, el r2 tiene la ruta 10.0.0.0/8 vía el r1 o vía el R3, dependiente sobre la trayectoria que produce el menos coste. En ambos casos, si el r2 debe enviar el tráfico a ciertas subredes de 10.0.0.0/8, no puede estar totalmente seguro que el tráfico alcanza su destino, como una subred de 10.0.0.0/8 puede estar solamente en la nube de red izquierda o correcta.

Para paliar este problema, no teclee simplemente ningún automóvil summary bajo proceso EIGRP del router. El router entonces propaga las subredes de las redes principales a través del límite. En más nuevas versiones deL Cisco IOS, no hay la configuración del automóvil summary el comportamiento predeterminado.

Evento eigrp registro

Evento eigrp el registro captura los eventos del EIGRP. Es similar a cuando los debugs se habilitan para el EIGRP. Sin embargo, es menos perturbador y se ejecuta por abandono. Puede ser utilizado para capturar los eventos que son más difíciles de resolver problemas o eventos más intermitentes. Este registro es por abandono solamente 500 líneas. Para aumentarlo, ingrese el evento-registro-tamaño <0 del eigrp – el comando 209878>. Usted puede aumentar el tamaño del registro tanto como deseado, pero tiene presente la cantidad de memoria que el router tiene que ahorrar para este registro. Para borrar Evento eigrp el registro, ingrese el comando claro de los eventos del eigrp del IP.

Aquí tiene un ejemplo:

R1#show ip eigrp events
Event information for AS 1:
1    09:01:36.107 Poison squashed: 10.100.1.3/32 reverse
2    09:01:35.991 Update ACK: 10.100.1.4/32 Serial2/0
3    09:01:35.967 Update ACK: 10.100.1.4/32 Ethernet0/0
4    09:01:35.967 Update ACK: 10.100.1.4/32 Ethernet1/0
5    09:01:35.943 Update delay/poison: 179200 FALSE
6    09:01:35.943 Update transmitted: 10.100.1.4/32 Serial2/0
7    09:01:35.943 Update delay/poison: 179200 TRUE
8    09:01:35.943 Update transmitted: 10.100.1.4/32 Ethernet0/0
9    09:01:35.943 Update delay/poison: 179200 FALSE
10   09:01:35.943 Update transmitted: 10.100.1.4/32 Ethernet1/0
11   09:01:35.923 Update packetized: 10.100.1.4/32 Ethernet0/0
12   09:01:35.923 Update packetized: 10.100.1.4/32 Ethernet1/0
13   09:01:35.923 Update packetized: 10.100.1.4/32 Serial2/0
14   09:01:35.903 Change queue emptied, entries: 1
15   09:01:35.903 Route OBE net/refcount: 10.100.1.4/32 3
16   09:01:35.903 Metric set: 172.16.1.0/24 2195456
17   09:01:35.903 Route install: 172.16.1.0/24 10.4.1.5
18   09:01:35.903 FC sat rdbmet/succmet: 2195456 2169856
19   09:01:35.903 FC sat nh/ndbmet: 10.4.1.5 2195456
20   09:01:35.903 Find FS: 172.16.1.0/24 2195456

Los eventos más recientes aparecen en la cima del registro. Usted puede filtrar los tipos determinados de eventos del EIGRP, tales como DUAL, Xmit, y transporte:

eigrp log-event-type {dual | xmit | transport}

Además, usted puede habilitar el registro para uno de estos tres tipos, una combinación de dos tipos, o para los tres. Aquí está un ejemplo donde habilitan a dos tipos de registro:

router eigrp 1
redistribute connected
network 10.0.0.0
no auto-summary
eigrp log-event-type dual xmit
eigrp event-logging
eigrp event-log-size 100000
!

Precaución: Cuando usted habilita el registro de evento del eigrp, imprime el registro de evento y lo salva en la tabla de eventos. Esto puede llevar a una gran cantidad de salida impresa en la consola, similar a cuando se habilita el hacer el debug de pesado del EIGRP.

La misma red aprendida por dos sistemas autónomos EIGRP

Si una ruta es docta vía dos procesos EIGRP, después solamente uno de los procesos EIGRP puede instalar la ruta en el RIB. El proceso con la mínima distancia administrativa instala la ruta. Si la distancia administrativa es lo mismo, después el proceso con el métrico más bajo instala la ruta. Si el métrico es lo mismo también, después el proceso EIGRP con el proceso EIGRP más bajo ID instala la ruta en el RIB. La tabla de topología del otro proceso EIGRP tendrá la ruta instalada con los sucesores cero y un valor infinito FD.

Aquí tiene un ejemplo:

R1#show ip eigrp topology 192.168.1.0 255.255.255.0
IP-EIGRP (AS 1): Topology entry for 192.16.1.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2681856
  Routing Descriptor Blocks:
  10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
      Composite metric is (2681856/2169856), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 40000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
IP-EIGRP (AS 2): Topology entry for 192.16.1.0/24
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
  Routing Descriptor Blocks:
  10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
      Composite metric is (2681856/2169856), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 40000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
R1#show ip route 192.168.1.0 255.255.255.0

Routing entry for 192.168.1.0/24
  Known via "eigrp 1", distance 90, metric 2681856, type internal
  Redistributing via eigrp 1
  Last update from 10.3.1.6 on Serial2/0, 00:04:16 ago
  Routing Descriptor Blocks:
  * 10.3.1.6, from 10.3.1.6, 00:04:16 ago, via Serial2/0
      Route metric is 2681856, traffic share count is 1
      Total delay is 40000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 118974