Respuestas de foro creadas
-
Entradas
-
Hola Álvaro! Última pregunta (de momennto jeje).
Ahora es con la 743.
El test marca como correcta la opción C (configurar el source-interface en R11). Creo que esto es un error: ese comando se usa para forzar la IP cuando el router actúa como cliente, pero aquí R11 es el servidor.
Como el ping desde R10 funciona, hay conectividad. El problema real es que los servicios del IOS (como TFTP) escuchan por defecto en la tabla global. Al estar la interfaz de R11 en la VRF «TFTP», el servidor ignora las peticiones.
Para mí la correcta es claramente la D: hay que vincular el servicio a la VRF explícitamente (tftp-server vrf TFTP…).
Es así? Que opinas?
Tengo otra pregunta para continuar con la batería de dudas jeje
Ahora es con la 737
La solución marca como correcta la opción C (cambiar el network type a broadcast), pero creo que es un error del test. Si hubiera un problema con el tipo de red, fallaría toda la adyacencia o el cálculo SPF, dejando al área sin ninguna ruta, no solo sin las de Internet. Además, cambiar a broadcast no evita que el área Stub siga bloqueando los LSA Tipo 5 del ASBR.
Para mí la correcta debería ser la B (area 10 stub no-summary). Al hacerla «Totally Stubby», obligamos al ABR a inyectar una ruta por defecto (LSA Tipo 3) hacia el área, lo cual sí soluciona directamente el problema de salida a Internet.
Es correcto mi razonamiento o se me escapa algún caso extraño donde la C tenga sentido?
Hola otra vez!
Ahora tengo una duda con la pregunta 735, sobre qué tipo de puertos protege IPv6 Source Guard.
Entiendo que esta característica de seguridad (dentro de la suite IPv6 First-Hop Security) funciona mediante snooping e inspecciona el tráfico basándose en una tabla de vinculación a nivel de conmutación de red. Sé que teóricamente esto opera estrictamente en Capa 2.
Sin embargo, la solución marca la opción B («Access ports») como correcta y creo que esto es un error o una trampa del examen.
Por lógica, al configurarse a nivel de conmutación, la opción A («Layer 2 ports») englobaría tanto los puertos de acceso como los troncales (donde también se puede aplicar para proteger enlaces hacia switches no gestionados). Para mí, la A debería ser la respuesta más exacta y completa.
Es como pienso o hay algún motivo de diseño de Cisco para forzar la respuesta de «Access ports»?
Hola de nuevo Álvaro! Gracias por tus respuestas.
Ahora tengo una duda con la pregunta 704
Entiendo que el problema es que R1 aprende la ruta por iBGP pero el next-hop original (2001::4) es inalcanzable, invalidando la ruta. Sé que la solución teórica es usar next-hop-self en el router de borde (R2).
Sin embargo, la Opción A (marcada como correcta) usa el comando neighbor 2001::4 next-hop-self. Creo que esto tiene una errata grave: al apuntar a la IP de R4, modifica el próximo salto de las actualizaciones que van hacia R4, lo cual no soluciona el problema interno de R1.
Por lógica, el comando en R2 debería apuntar a su vecino interno (ej. neighbor 2001::1 next-hop-self) para que R1 reciba la IP de R2 como próximo salto.
Estoy en lo cierto?
Hola de nuevo!
Ahora me surge una duda sobre la pregunta 89.
La pregunta nos pide elegir dos propósitos de usar las configuraciones de las familias de direcciones IPv4 y VPNv4 en una MPLS VPN de Capa 3. Yo entiendo que la clave aquí está en la palabra «propósito» (purpose) de habilitar estas configuraciones en el router.
Según las respuestas las correctas son la A y la B, las cuales dicen que el RD se añade a la ruta IPv4 para hacerla única (A) y que la dirección VPNv4 consiste en un RD de 64 bits añadido al prefijo IPv4 (B). Esto creo que es erróneo debido a que, si bien la B es una afirmación técnicamente correcta, es una simple definición de formato y no el «propósito» por el cual habilitamos la familia de direcciones. No configuramos VPNv4 con el propósito de que «consista en 64 bits».
Por este motivo, yo creo que las correctas deberían ser la A y la E. Así mantenemos la A como la función real de la familia IPv4 en la VRF, y con la E describimos una acción y propósito real: usar la familia de direcciones VPNv4 para poder anunciar y propagar las etiquetas MPLS VPN (inner labels) a través de la red del proveedor.
Que opinas?
Hola de nuevo Álvaro! Gracias por las aclaraciones de las preguntas anteriores.
Ahora es sobre la pregunta 624.
La pregunta nos dice que el PC de la nueva sucursal (R12) no está aprendiendo la ruta IPv6 de Internet a través de OSPF, y nos pide elegir dos acciones para resolverlo. Yo creo que para que OSPF inyecte una ruta por defecto, el router principal (R11) primero debe tener una ruta estática hacia Internet (Opción D) y luego redistribuirla al resto de la red.
Según las respuestas las correctas son la A y la C, las cuales dicen que debemos configurar la ruta estática directamente en el router de la sucursal (A) y usar el comando default-information originate bajo la instancia global de OSPFv3 (C). Esto creo que es erróneo debido a que, si configuramos la ruta estática en R12 (A), el router ya sabría salir a Internet y no necesitaría aprenderla vía OSPF, contradiciendo el enunciado.
Por este motivo, yo creo que las correctas deberían ser la B y la D. Así creamos la ruta en la central (D) y la inyectamos usando la sintaxis moderna de Cisco bajo el address-family de IPv6 (B), logrando que la sucursal la aprenda dinámicamente.
Estoy en lo cierto?
Buenas Álvaro!
Tenía una duda, y es que tu crees que servirá si configuro el VRF de la forma moderna (vrf definition)? Es que es como lo he aprendido y ya lo hago de manera automática así, por lo que seguro que en el examen me sale solo hacerlo de esta manera.
Hola de nuevo Álvaro! Disculpa tanta pregunta, pero es que necesito aclarar.
Ahora es sobre la 399.
La pregunta nos dice que al intentar abrir una sesión con Telnet hacia R2, el cual esta configurado con un «enable secret» y una «password command» obtenemos el log «[Connection to 10.1.1.2 closed by foreign host]». Esto yo creo que es causado debido a que tenemos el comando «no exec» en la línea vty, debido a que por este motivo el host remoto cierra la sesión.
Según las respuestas la correcta es la A, la cual dice que debemos establecer el comando «login local». Esto creo que es erróneo debido a que al iniciar nos pediría credenciales en vez de echarnos directamente de la sesión.
Estoy en lo cierto?
Gracias Álvaro! Ya me queda esa clara.
Me surge otra pregunta respecto a la 427.
Sabiendo que esta pregunta mezcla el plano de control con el de datos y omite la verdadera etiqueta VPN, el RD (Route Distinguisher) es el identificador de 64 bits que se utiliza para hacer que un prefijo sea globalmente único en BGP, logrando así distinguir las redes idénticas de distintos clientes. Por ello, creo que la respuesta más lógica por descarte apunta a la opción A.
La opción C (que según las soluciones es la correcta) creo que no sería correcta debido a que el Route Target (RT) es, estructuralmente y de forma literal, un atributo BGP de tipo Extended-community. Al estar también la opción D (Extended-community) presente, ambas opciones significan técnicamente lo mismo y se anularían mutuamente en una pregunta de opción única.
Que opinas?
Disculpa pero creia que me dejaba editar el comentario para añadir otra pregunta, pero tengo que subir otro comentario.
Ahora es respecto a la pregunta 734.
Sabiendo que BFD es un protocolo diseñado para detectar fallos en la red de forma extremadamente rápida, la infraestructura debe darle un trato preferencial para evitar descartes en caso de congestión. Por ello, creo que los dispositivos marcan este tráfico crítico de control de enrutamiento (al igual que BGP u OSPF) con el valor de IP Precedence 6, lo que apunta a la opción C.
La opción D (que según las soluciones es la correcta) creo que no sería correcta debido a que el valor 7 de IP Precedence me parece que esta estrictamente reservado para el tráfico de control puramente local del dispositivo o de Capa 2 (como mensajes de Spanning Tree o keepalives a nivel de hardware), y no para protocolos IP como BFD.
Gracias Álvaro!
Me ha surgido otra cuestión, esta vez con la pregunta 738.
Como se ve en la imagen, el ping tiene una pérdida de paquetes severa, pero no total. Con lo cual, sabiendo que en el enunciado dicen que la Capa 2 es estable, creo que el problema recae en que el switch esta fallando al procesar o reenviar las tramas multicast, lo que apunta a un fallo de hardware que requiere sustiuir el equipo (opción C).
La opción D (que según las soluciones es la correcta) creo que no sería correcta debido a que si una falta de configuración estuviese bloqueando el multicast, el tráfico fallaría al 100%, y no dejaría pasar ningún paquete (como si vemos que pasa según la imagen).
Es correcto mi razonamiento?
Hola buenas tardes.
Tengo una duda sobre la pregunta 681, debido a que queremos aplicar una ACL de ipv6 a la interface, pero al ser ipv6 debería ser «Traffic Filter», siendo así más correcta la opción B (ya que es más exacta) que la opción C. Sin embargo en las soluciones se da como correcta la C.
Estoy en lo correcto o me pierdo algo?
En el ejemplo que das en el minuto 6:10 dices que la máscara que debe recibir del prefijo tiene que ser una /29 (255.255.255.248), sin embargo, en la ACL se ve 255.255.248.0 con wildcard 0.0.7.255. No debería ser que permite rutas desde /21 o superior? Ya que según entendí, para que permitiese rutas /29 o superior la wildcard debería ser 0.0.0.7.