- Este debate tiene 119 respuestas, 11 mensajes y ha sido actualizado por última vez el hace 3 días, 2 horas por
.
-
Entradas
-
¡Hola Adrian!
Es una buena observación, sin embargo, este valor ya te lo dice Cisco en sus guías de configuración, por ejemplo acá: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bfd/configuration/xe-3s/irb-xe-3s-book/irb-bi-fwd-det.html
Puedes ver en la primera parte: «BFD packets carries precedence of 7, and get prioritized by default.» Por lo tanto la opción correcta sigue siendo la D.
Quedo atento a cualquier otro comentario.
Saludos cordiales! =)
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?
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?
Hola Adrián, no te preocupes por la cantidad de preguntas, para esto es esta sección, además que nos ayuda a identificar preguntas que se nos hayan podido escapar, como veras son muchísimas entre todos los bancos, y algunas se nos pueden ir.
Respecto a la 427, la verdad el enunciado no es muy claro, no sabemos con certeza si habla del dominio BGP, o si habla del PE hacia los clientes, o si habla del plano de control o de datos. De acuerdo a tu interpretación cualquier opción podría ser correcta (menos VNI), o ninguna podría serlo, ya que, si hablamos del plano de datos el VPN label nos sirve para conmutar la información al cliente correcto desde el PE. RD lo utilizamos en L3VPN para distinguir las rutas cuando son redistribuidas a iBGP, nos sirve para mantener únicos a los prefijos. La pregunta nos dice: «forward the packet to the correct customer (desde el PE)», yo me inclino a pensar que esto se refiere a la etiqueta que se utiliza para enviar la ruta al cliente/VRF correcto, y para esto se utiliza el RT, pero de nuevo, podríamos elegir interpretar la pregunta de otra forma, y la respuesta cambiaría. Como mencionas sí es redundante que nos pongan extended comnmunities como una opción, pero aun así me parece que RT es algo más específico.
Saludos! =)
Hola Adrián!
Respecto a la 399 esa si se nos fue, es la opción C, ya la hemos corregido.
Cuando tienes el comando «no exec» en la linea vty e intentas hacer un telnet desde otro dispositivo, este sera el resultado:
*Mar 18 14:56:13.323: %SYS-5-CONFIG_I: Configured from console by console R1#telnet 1.1.1.2 Trying 1.1.1.2 ... Open [Connection to 1.1.1.2 closed by foreign host]Gracias, saludos! =)
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?
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 Adrían!
Respecto a la 624, la ruta debe instalarse en el Head Office ya que es el punto de conexión con Internet y redistribuirse desde acá, esto daría como respuesta correcta la D (no la A). Y lo segundo, acá al trabajar con Dual Stack, lo correcto es asumir que se está implementando la configuración actualizada empleando Address-Families. En ese sentido la configuración del comando default-information debe hacerse desde el modo config-router-af (Address-family), lo que da como resultado la opción B. Ya fueron corregidas las opciones.
¡Gracias y saludos! =)
Hola Adrían!
Respecto a la 89, lo que queda claro acá es que las opciones C y D son incorrectas. Por otro lado, la E no me parece correcta ya que nos dice que se utiliza la VPNv4 address para enviar la etiqueta MPLS VPN Label, sin embargo, son 2 cosas diferentes. La dirección VPNv4 address se utiliza para el plano de control, y la etiqueta VPN Label se utiliza para el plano de datos. La VPNv4 address tiene un tamaño de 12 bytes, mientras que la etiqueta VPN Label tiene un tamaño de 4 bytes, ambos datos se envían a través de MP-BGP como parte del NLRI en campos diferentes.
Si tienes razón en que la opción B no cuenta como «propósito», pero aún así creo que son las únicas opciones posibles de todas las existentes.
Quedo atento.
Saludos!
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 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»?
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 Á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?
Hola Adrían!
Es correcta tu observación para la 704, la opción A se mantiene, sin embargo como mencionas, el comando aplicado en el router R2 debería apuntar a la IP :1, así que el comando correcto es: 2001::1 next-hop-self.
Respecto a la 735, es correcto, la mejor opción es la A: https://www.cisco.com/c/en/us/td/docs/routers/7600/ios/15S/configuration/guide/7600_15_0s_book/IPv6_Security.pdf.
Respecto a la 737, la opción A no puede ser ya que es suficiente el ejecutar el comando default-information originate. La opción D tampoco es correcta, ya que no hace falta propagar esa ruta desde el ABR-Rtr. Respecto a la opción B, no veo diferencia en que sea Stub o Stubby, en ambos casos se va realizar la propagación de la ruta por defecto. Según las configuraciones, no hay nada malo en ellas respecto a la definición del área Stub; si solo nos fijamos en ello, debería funcionar. Y acá pues ya entra tu propia interpretación del enunciado, la opción C podría ser correcta si el tipo de red del ABR-RTr no es compatible con el resto de interfaces, pero como mencionas, en ese caso se perderían todas las adyacencias. Otra interpretación que podrías tener, es que el enunciado este incompleto o erróneo, ya que si te fijas, no hay un comando «network» que defina la adyacencia en el router ABR-RTr con su vecino R1-RTr (todas las demás existen). Por ahora me parece que la C es la «mas» correcta, pero de nuevo, dependerá de tu propia interpretación.
Y finalmente respecto a la 743, esta la he configurado en mis equipos ya que me causaba ruido. La A y la B no tienen nada que ver. La C como mencionas nos sirve para iniciar sesiones TFTP, no tiene influencia cuando el dispositivo es el propio servidor. Lo que nos deja como opción correcta a la D. Sin embargo, algo que mencionas es que definamos el servidor TFTP hacia un VRF específico, pero NO existe tal comando en los dispositivos con SO IOS (si en XR), eso tómalo en cuenta. Configurando simplemente el comando «tftp-server flash:» sin definición de un VRF ya funciona la transferencia de datos bajo las condiciones mostradas en el enunciado.
Quedo atento a cualquier otra observación, saludos! =)
- Debes estar registrado para responder a este debate.