ESPECIAL EXAMEN 300-101 - CCNP

ESPECIAL EXAMEN

En el examen de Cisco os encontraréis escenarios parecidos a los que muestro aquí. Os dejo un enlace con todos los laboratorios en GNS3 ya montados con la configuración básica. Recordad que para que funcione tendréis que tener la IOS ya configurada en GNS3. Si no sabéis cómo hacerlo, podéis encontrar la imagen y una guía aquí.

Archivo con todos los laboratorios en GNS3

1. ESCENARIO EIGRP

En este escenario Cisco no nos presenta la topología, directamente nos da un show y nos hace preguntas. Aquí os presento una topología muy parecida a la que se refiere la pregunta:

El show que nos presenta es un “show ip eigrp topology all-links” desde el equipo CORE1.

Pregunta 1:

¿Qué red en el dispositivo Core1 tiene Feasible successors?

A – 172.17.0.0/30
B – 172.17.1.0/24
C – 172.17.2.0/24
D – 172.17.3.0/25
E – 172.17.3.128/25
F – 10.140.0.0/24

Aclaramos que aquí 307200 es la Feasible Distance (FD) y 281600 es la distancia reportada (RD)

Nos tenemos que fijar bien. Analicemos:

La red 172.17.3.128/25 tiene directamente 2 successor. Es decir, tienen la misma FD. Solo tiene successor, no tiene Feasible Successor. La descartamos

La red 10.140.0.0/24 vemos que tiene 1 successor pero hay 2 caminos para llegar. Ahora tenemos que ver si se cumple la regla del Feasible sucesor. Comparamos la RD del posible Feasible sucesor (172.17.10.2) y que  vemos que es 2195456 con la FD del sucesor que es 2195456. Vemos que son iguales, por lo tanto no se cumple la regla que dice que la RD del posible Feasible successor tiene que ser menos que la FD del sucesor. Aquí no se cumple, por lo tanto, esta red no tiene sucesor.

Con la 172.17.2.0 sucede lo mismo. FD y RD son iguales.

La 172.17.0.0 tampoco tiene Feasible successor ya que hay un camino con las misma RD que el FD del succesor y, el otro camino tiene una RD mayor.

NOTA: en el examen alguna red será correcta. Aquí se muestra como distinguirlo.

Pregunta 2:

Qué 3 rutas EIGRP serán instaladas para las redes 172.17.3.128/25 y 172.17.2.0/24?

A – 172.17.3.128.25 [90/28160] via 172.17.1 2, 01:26:35, FastEthernet0/2
B – 172.17.3.128/25 [90/30720] via 172.17.3.2, 01:26:35, FastEthemet0/3
C – 172.17.3.128/25 [90/30720] via 172.17.10.2, 01:26:35, FastEthernet0/1
D – 172.17.2.0/24 [90/30720] via 172.17.10.2, 02:10:11, FastEthernet0/1
E – 172.17.2.0/24 [90/28160] via 172.17.10.2, 02:10:11, FastEthernet0/1
F – 172.17.2.0/24 [90/33280] via 172.17.3.2, 02:10:11, FastEthernet0/3

La red 172.17.3.128/25 tiene 2 successors, por lo tanto se instalarán ambas rutas, tanto la que va por la 172.17.3.2 como por la 172.17.10.2.

En la 172.17.2.0/24 al tener el camino alternativo una RD igual que la FD del successor, este camino alternativo no será un Feasible Successor, por lo que no se instalará ese camino en la tabla de rutas. Hay que recordar, que si cae el enlace principal, aunque el camino alternativo no sea un Feasible Successor, el tráfico se desviará por este cuando el algoritmo recalcule.

Pregunta 3:

¿Qué 3 redes del tiene directamente conectadas el router que tiene la dirección ip 172.17.10.2?

A – 172.17.0.0/30
B – 172.17.1.0/24
C – 172.17.2.0/24
D – 172.17.3.0/25
E – 172.17.3.128/25
F – 172.17.10.0/24

Nos está preguntando por un router diferente al del show. Tenemos que averiguar cuáles.

Aquí vemos que la propia red 172.17.10.0 aparece en el show como directamente conectado. Esto quiere decir que el equipo 172.17.10.2 está en esta red. Si nos fijamos, tiene una FD de 281600. Con este dato, deberemos buscar los caminos que vayan hacia la 172.17.10.2 y, los que tengan la misma FD serán las directamente conectadas a ese router (172.17.10.2), pues es la RD para llegar a él y, por lo tanto sus interfaces conectadas nos serán advertidas con la misma RD. También lo podéis comprobar en la topología, pero esta no os la mostrarán en el examen

Con esto estaría respondido todo el escenario.

2. ESCENARIO EVALUACIÓN EIGRP

En esta pregunta Cisco nos presenta un escenario y a base de comandos show tendremos que responder a las preguntas que nos hacen.

PREGUNTA 1:

El tráfico desde la loopback de R1 a la loopback de R6 se balancea entre las rutas R1-R2-R4-R6 y R1-R3-R5-R6. ¿Cuál es el ratio de tráfico de cada ruta?

A. 1:1
B. 1:5
C. 6:8
D. 29:120

Para resolver esta pregunta tendremos que ir a R6 y ejecutar el comando:

R6#how ip route 150.1.6.6

Cómo podemos observar, el comando nos da directamente la respuesta. Esto nos muestra que el balancea de carga no es simétrico. Si nos fijamos en la configuración EIGRP, se ha introducido el comando VARIANCE.

PREGUNTA 2:

¿Qué tipo de filtro de enrutamiento hay en R6?

A. Distribute-list using an ACL
B. Distribute-list using a prefix-list
C. Distribute-list using a route-map
D. An ACL using a distance of 255

Vamos a R6 y hacemos un show running-config

El 1 del distribute-list nos dice que apunta a un Access-list.

PREGUNTA 3:

¿Qué “Key Chain” está siendo usado para la autenticación de la vecindad EIGRP entre R2 y R4?

A. CISCO
B. EIGRP
C. key
D. MD5

Mira la configuración en los equipos propuestos:

Como vemos, el Key Chain se llama “CISCO”.

PREGUNTA 4:

¿Cuál es la distancia reportada (RD) (o AD - distancia advertida, recordad que se sigue usando este término)  para la red 192.168.46.0 en R1?

A. 307200
B. 1938688
C. 1810944
D. 307456

Vamos a R1 y miramos con qué RD nos está llegando esa ruta. Si ponemos un "show ip route" solo nos dará la Distancia Reportada (RD) y la Feasible Distance (FD), la métrica. 

Es con un "show ip eigrp topology" como conseguimos ver la Distancia Reportada. También podemos ver la FD de esa ruta.

PREGUNTA 5:

¿Qué porcentaje en ancho de banda tiene permitido las interfaces de R1 en EIGRP?

A. 10
B. 20
C. 30
D. 40

Vamos a R1 y buscamos en la configuración:

Tiene un 20 % configurado.

Recordad que EIGRP tiene configurado por defecto el 50%.

3. ESCENARIO EIGRP STUB

La empresa ha extendido su negocio. Ellos configuran el router (R1) para que pueden llegar a todas las subredes. Con el fin de tener una red estable y reducir el uso de la memoria y la utilización de ancho de banda en R1, la empresa hace uso de la característica EIGRP Stub. Otro ingeniero de red es responsable de la implementación de esta solución. Sin embargo, en el proceso de configuración del EIGRP Stub se ha perdido conectividad con la red LAN de R1.

Actualmente la empresa ha configurado EIGRP en todos los routers de la red R1, R2 y R3. Tu deber es encontrar y resolver el problema de la falta de conectividad total con el router R1. A continuación, debe configurar la sumarización de rutas solo hacia el router R1 para completar la tarea después de que el problema de conectividad haya sido resuelto.

El éxito de pings de R2 a la interfaz LAN R1 demuestra que el fallo ha sido corregido y la tabla de enrutamiento IP de R3 sólo tiene que contener 2 subredes  del rango 10.0.0.0.

Vamos a R2 y vemos que el protocolo EIGRP está corriendo pero no recibimos el rango LAN de R1:

Sin embargo, Cuando examinamos los equipos vemos que en R1 existe una configuración errónea en EIGRP:

R1#sh run | s router router eigrp 500  network 10.1.2.0 0.0.0.255  network 172.16.1.0 0.0.0.255  no auto-summary  eigrp stub receive-only – aquí está el fallo

Simplemente eliminamos la configuración Stub y la volvemos a crear sin receive-only

R1(config-router)#eigrp stub – Recordad que por defecto añade las “connected y summary”

Ahora vamos a R2 y ya vemos el rango 172.16.0.0

Cuando eliminamos la configuración Stub vemos como cae y vuelve a levantar la vecindad. Cuando aplicamos la configuración Stub correctamente pasa lo mismo.

Ahora vamos a R1 y vemos la tabla de rutas:

Ahora tenemos que sumarizar en R2 para que a R1 solo le lleguen dos rangos de la red 10.0.0.0. Para ello vamos a la interface s1/0 para aplicar la sumarización EIGRP.

R2(config-if)#ip summary-address eigrp 500 10.1.0.0 255.255.0.0

Vamos  R1 y vemos la tabla de rutas con dos subredes del rango 10.0.0.0

Guardamos la configuración. Solucionado.

4. ESCENARIO REDISTRIBUCIÓN EIGRP-OSPF

Usted es un ingeniero de redes con Laboratorio.com, una pequeña empresa de tecnología. Ellos se han fusionado recientemente dos organizaciones y ahora necesitan fusionar sus redes, Una red está utilizando OSPF como IGP y el otro está utilizando EIGRP como su IGP. R4 ha sido añadido a la red OSPF existente para proporcionar la interconexión entre las redes OSPF y EIGRP. Dos enlaces se han añadido que proporcionarán redundancia.

Usted  debe poder hacer ping y telnet desde la loopback 101 en R1 a la dirección de OPSF 172.16.1.100. Todo el tráfico debe utilizar el camino más corto que ofrece el mayor ancho de banda. Las rutas redundantes de la red OSPF a la red EIGRP deben estar disponibles en caso de un fallo de enlace. No se permite el enrutamiento estático o por defecto, en ninguna red.

Un ingeniero de la red anterior se ha iniciado la ejecución de fusión y ha asignado correctamente y verificado toda direccionamiento IP y enrutamiento básico IGP. A usted le han asignado la tarea de completar la implementación y asegurar que se cumplan los requisitos de la red. Usted no puede eliminar o cambiar cualquiera de los comandos de configuración actualmente en cualquiera de los routers. Puede añadir nuevos comandos o cambiar los valores por defecto.

Cómo podemos comprobar en R1, este no está recibiendo las rutas OSPF. Tenemos que configurar R2 y R3 para que redistribuyan las rutas. Vamos a redistribuirlas:

R2#sh run | s router

router eigrp 100

 redistribute ospf 1

 network 192.168.1.0

 network 192.168.2.0

 no auto-summary

router ospf 1

 redistribute eigrp 100 subnets

 network 192.168.4.0 0.0.0.255 area 24

R3#sh run | s router

router eigrp 100

 redistribute ospf 1

 network 192.168.2.0

 no auto-summary

router ospf 1

redistribute eigrp 100 subnets

 network 192.168.3.0 0.0.0.255 area 34

Sin embargo no vemos las rutas en R1. Si nos fijamos, R4 sí que ve la Loopback 101 de R1.

Para solucionar este problema tenemos que redistribuir las rutas con la métrica apropiada. Lo primero que tenemos que ver es la interface OSPF de los equipos que redistribuyen. De ahí, sacamos la métrica:

R2#sh int s0/2 Serial0/2 is up, line protocol is up   Hardware is M4T   Internet address is 192.168.4.2/24   MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation HDLC, crc 16, loopback not set   Keepalive set (10 sec) R3#sh int e0/0 Ethernet0/0 is up, line protocol is up   Hardware is AmdP2, address is cc03.081c.0000 (bia cc03.081c.0000)   Internet address is 192.168.3.3/24   MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation ARPA, loopback not set

Y ahora redistribuimos.

R2(config-router)#redistribute ospf 1 metric 1544 2000 255 1 1500

R3(config-router)#redistribute ospf 1 metric 10000 100 255 1 1500

Recordad que el valor de Delay hay que dividirlo entre 10.

Ahora vamos a R1 y ya vemos las rutas OSPF.

Ahora vamos a R2 y vemos los caminos que tomaría para llegar a la 172.16.100.1

Como se puede apreciar, R2 está eligiendo el camino hacia R4, pero el escenario nos quiere decir que tenemos que hacer pasar el tráfico por R3.  El truco aquí es configurar en R2 una distancia administrativa para que las rutas externas (D EX) de EIGRP se redistribuyan con una métrica menor que las OSPF (AD=110). Si no modificamos nada, las rutas externas de EIGRP se están redistribuyendo con una AD de 170.

Vamos a R2 y configuramos:

R2#conf t Enter configuration commands, one per line.  End with CNTL/Z. R2(config)#router eigrp 100 R2(config-router)#distance eigrp 90 105

Vemos como se vuelve a formar la vecindad y la ruta que elige ahora es hacia R3:

Si tiramos la interface F2/0 en R3, el tráfico conmutaría y elegiría desde R2 la ruta hacia R4.

Guardamos la configuración y el ejercicio estaría terminado.

5. ESCENARIO OSPF STUB

OSPF está configurado en los routers Madrid y Barcelona . La interfaz de Madrid e0/0 y la interfaz e0/0 de Barcelona están en el área 0. La interfaz Loopback0 de Barcelona pertenece al área 2.

Su tarea consiste en configurar lo siguiente:

e0/0 de Valencia  en el área 25

e0/0 de Madrid en el área 25

Utilice la máscara adecuada en el área 25 para que solo existan en esta área las interface e0/0 de Valencia y la e0/1 de Madrid

El área 1 no debe recibir ninguna ruta externa o rutas “inter-area” (excepto la ruta por defecto).

Lo primero que tenemos que configurar es el área 25. Nos pide que usemos una máscara adecuada, así que viendo que la dirección ip de Valencia tiene una máscara /30, tendremos que convertir esto a una wildcard mask, que es el formato que se usa en OSPF.

Valencia

VALENCIA(config)#int e0/1

VALENCIA(config-if)#ip add 172.16.20.2 255.255.255.252

VALENCIA(config-if)#no sh

VALENCIA(config)#router ospf 1

VALENCIA(config-router)#net 172.16.20.0 0.0.0.3 area 25

Madrid (ojo con el número del proceso que ya está creado)

MADRID(config-router)#int e0/1

MADRID(config-if)#ip add 172.16.20.1 255.255.255.252

MADRID(config)#router ospf 75

MADRID(config-if)#ip add 172.16.20.1 255.255.255.252

Comprobamos que la vecindad se ha formado y vemos la tabla de rutas

Luego nos dice que “el área 1 no debe recibir ninguna ruta externa o rutas “inter-area”

Vemos que en Valencia recibimos las rutas externas (E2) del protocolo EIGRP y las inter-area  del área OSPF 25. Si no queremos recibir rutas externas (LSA Tipo 5) ni rutas inter-area (LSA Tipo 3 y 4), en realidad nos está pidiendo que configuremos un area TOTALLY STUBBY, que además de filtrarlas Madrid al ser el ABR (Area Border Router) nos proporcionará en el area 1 una ruta por defecto que generará  para Valencia.

Para configurarlo, vamos a Madrid:

MADRID(config-router)#area 25 stub no-summary 

Y finalmente en Valencia:

VALENCIA(config-router)#area 25 stub

Comprobamos que no nos llegan las rutas y que además Madrid nos ha generado una ruta por defecto 0.0.0.0

Guardamos la configuración. Solucionado

6. ESCENARIO EVALUACIÓN OSPF

Se le ha pedido a evaluar una configuración de red OSPF en un laboratorio de pruebas y responder a las preguntas que un cliente tiene sobre su funcionamiento. El cliente ha inhabilitado su acceso al comando show running-config.

Cisco nos inhabilita ver la configuración así que tendremos que responder a las preguntas usando comandos “show”

Pregunta 1:

¿Cuánto tiempo tiene el LSA tipo 3  del Router 3 para el área 1 en el router R5?

A. 329
B. 160
C. 354
D. 9

Para responder a esta pregunta nos vamos a R5 y usamos el comando:

R5#show ip ospf database en R5

Buscamos el campo “Age” y ahí encontramos el tiempo que lleva esa ruta instalada en la “database”.

Pregunta 2:

¿Cuál de las siguientes afirmaciones es verdadera acerca de los enlaces seriales que terminan en R3?

A. The R1-R3 link needs the neighbor command for the adjacency to stay up
B. The R2-R3 link OSPF timer values are 30, 120, 120
C. The R1-R3 link OSPF timer values should be 10,40,40
D. R3 is responsible for flooding LSUs to all the routers on the network.

Vamos a R3 y miramos el proceso OSPF en esos enlace:

Vemos los timers del enlace R2-R3.

El otro enlace es un tipo broadcast por lo que no necesita el comando “neighbor X.X.X.X” en la configuración OSPF  como los tipo non-broadcast, los cuáles debe llevar el comando neighbor para formar la vecindad. Chequead la config.

Pregunta 3:

¿Cuántas veces fue ejecutado el algoritmo SPF R4 en el Área 1?

A. 1
B. 5
C. 7
D. 20
E. 54
F. 224

Vamos a R4 y metemos el comando “sh ip ospf”

Se ve claro cuántas veces…

Pregunta 4:

Las áreas de los Routers 5 y 6 no son áreas normales. Inspecciona sus tablas de enrutamiento y determinar cuál es verdadera?

A. R5′s Loopback and R6′s Loopback are both present in R5′s Routing table
B. R5′s Loopback and R6′s Loopback are both present in R6′s Routing table
C. Only R5′s loopback is present in R5′s Routing table
D. Only R6′s loopback is present in R5′s Routing table
E. Only R5′s loopback is present in R6′s Routing table

Para responder a esta pregunta tenemos que tener en cuenta la table de los LSA de OSPF

Si vamos a R5 y miramos el proceso OSPF y la table de rutas vemos que el área 2 está configurada como NSSA (Not So Stubby Area). En la tabla vemos que ese tipo de área no permite los LSA de tipo 5, es decir, las externas y además no genera una ruta por defecto 0.0.0.0.

Si vamos a R6 vemos que el área es una STUB y no hay rutas de ningún área. Aquí vemos como se genera la ruta por defecto.

Esto también lo podemos ver en R4

La respuesta ahora queda más clara. En R5 si vemos la loopback de R6 y en R6 no vemos la loopback de R5.

Guardamos la configuración. Solucionado.

7. VIRTUAL LINK EN OSPF

Laboratorio es una empresa que tiene una red empresarial con IPv6 OSPFv3. Actualmente OSPF está configurado en todos los routers. Sin embargo, la dirección loopback de R4 (FEC0:40::4/64) no se puede ver en la tabla de enrutamiento IPv6 de R1. Su tarea es identificar la causa de esta falla y aplicar las acciones correctivas necesarias que utiliza características de OSPF sin realizar ningún cambio de las asignaciones de área actual. Usted sabrá que ha corregido el fallo cuando la dirección loopback de R4 (FEC0:40::4) se puede ver en la tabla de enrutamiento de R1.

Nota especial: Para sacar el máximo número de puntos debe quitar todas las sentencias de configuración incorrectas o innecesarias relacionados con este tema.

Comprobamos la tabla de rutas de R1  y solo vemos la loopback de R2 pero no la de R3 ni la de R4 que pertenecen al área 89.

Sabemos por la teoría que todas la áreas en OSPF deben estar conectadas al área backbone, es decir, al área 0. Para que el área 89 sea aceptada en el área 0 debe haber creado un Virtual Link.

Hacemos un show running-config en todos los equipos para investigar. Observamos que R2, R3 y R4 no están bien configurados, pues el Virtual Link tiene que ser configurado entre R2 y R3:

R2#sh run | s router ipv6 router ospf 1  router-id 2.2.2.2  log-adjacency-changes  passive-interface default  no passive-interface Ethernet0/0  no passive-interface Serial1/0  no passive-interface Loopback0

R3#sh run | s router ipv6 router ospf 1  router-id 3.3.3.3  log-adjacency-changes  area 89 virtual-link 4.4.4.4  passive-interface default  no passive-interface Ethernet0/0  no passive-interface Serial1/0  no passive-interface Loopback0

R4#sh run | s router ipv6 router ospf 1  router-id 4.4.4.4  log-adjacency-changes  area 89 virtual-link 3.3.3.3  passive-interface default  no passive-interface Ethernet0/0  no passive-interface Loopback0

Como vemos, el Virtual Link está creado entre R3 y R4. Para corregir la configuración eliminamos el Virtual Link entre R3 y R4 y, configuramos uno nuevo entre R2 y R3 ya que es el área 50 la que hará de área de tránsito para el área 89:

Eliminamos en R4:

R4(config)#ipv6 router ospf 1

R4(config-rtr)#no area 89 virtual-link 3.3.3.3

Configuramos en R2 y R3:

R2(config)#ipv6 router ospf 1

R2(config-rtr)#area 50 virtual-link 3.3.3.3

R3(config)#ipv6 router ospf 1

R3(config-rtr)#no area 89 virtual-link 4.4.4.4

R3(config-rtr)#area 50 virtual-link 2.2.2.2

Y ahora vamos a R1 y tenemos que ver las loopback. Hacer ping para comprobar:

8. FILTROS DE ENRUTAMIENTO

La empresa tiene dos enlaces para salir a Internet. Las políticas de empresa dicen que el tráfico web tiene que salir por el enlace Relay si está disponible y el resto del tráfico puede pasar por cualquiera de los dos enlaces. No se permite el enrutamiento estático o por defecto.

Para solucionar este problema tenemos que hacer uso de la utilidad route-map y declarar que para un tipo de tráfico se va por un lado y otro tipo por el otro.

Creamos el Access-list para permitir el tráfico HTTP:

EMPRESA(config)#access-list 100 permit tcp any any eq 80

Creamos el route-map, asociamos el access-list y le establecemos el next-hop apuntando hacia el ISP-FRAME-RELAY

EMPRESA(config)#route-map FILTRO-HTTP permit 10

EMPRESA(config-route-map)#match ip address 100

EMPRESA(config-route-map)#set ip next-hop 67.0.0.1

Por ultimo, lo aplicamos al interface de la parte EIGRP que es por donde se originará el tráfico y donde podremos filtrar correctamente:

EMPRESA(config)#int e0/1

EMPRESA(config-if)#ip policy route-map FILTRO-HTTP

Ahora generamos tráfico HHTP desde el equipo TEST hacia ISP-FRAME-RELAY  y vemos con el comando “show route-map” en EMPRESA cómo los paquetes HTTP  se registran. También intentamos lanzar tráfico HTTP  hacia ISP-ETHERNET  y vemos cómo no nos lo permite el policy que hemos aplicado.

En EMPRESA:

Guardamos la configuración. Solucionado