Respuestas de foro creadas
-
Entradas
-
Hola Ricardo
En la pregunta 1117 en realidad debería ser acceso, ya que simplemente tenemos una VLAN con un SSID, no hay necesidad que sea troncal.
Respecto a la 1112, podriamos intentar con el método de descarte: la opción B no podría ser ya que no vemos gran cantidad de paquetes broadcast capturados, apenas 267. La C provocaría que existan colisiones, y vemos que existen 0 colisiones. La A no puede ser ya que vemos que la NIC esta funcionando sin errores registrados, tenemos paquetes transmitidos y paquetes recibidos. Lo que nos deja como opción a la D, cuando veas reliability 255/255, txload 255/255, rxload 255/255, básicamente significa saturación en la interface (alto throughput, se consume todo el ancho de banda), se esta utilizado al máximo a la interface.
quedamos atentos a cualquier comentario.
Saludos! =)
Felicitamos a Juan Rodriguez Rincon de Colombia que logró su certificación CCNA! =)
Ánimos al resto.
Saludos!
Buenos días Gabriel! =)
No, no evalúan nada sobre modelos específicos, así que no te preocupes sobre esos datos.
Saludos! =)
¡Hola Eduardo, bienvenido! =)
Respecto a tu pregunta, la opción A no puede ser ya que no se transmiten todas las tramas recibidas a cada dispositivo conectado, ese es el comportamiento de un hub. La B no puede ser, ya que un switch no mantiene estados de las transacciones que se realizan. La opción D por supuesto que es incorrecta ya que también se transmite la información con full duplex. Nos queda la opción C que es la correcta, ya que puedes armar un «link bundling» hacia servidores, acá se está refiriendo a Etherchannels.
Espero que quede claro.
¡Saludos! =)
Hola William, es correcto. Ese campo corresponde al header de la trama Ethernet y permite identificar el protocolo de capa superior, ya sea IP, IPv6, ARP, etc. El valor de 0x0800 corresponde al protocolo IPv4.
Saludos! =)
Hola Andrea, hemos dado una segunda revisión a todos los archivos del curso, y no deberían existir problemas. Ambos laboratorios de OSPF mostraban el error que mencionabas. De todas formas si encuentras alguna otra observación, estamos atentos para corregirla.
Saludos cordiales.
Hola William, no, el puerto debe estar encendido (no shutdown) para que pueda otorgar energía (PoE) al dispositivo conectado.
Saludos! =)
Hola William!
No, no son lo mismo.
BPDU Guard es una característica que bloquea un puerto cuando recibe un BPDU. Esto significa que te protege por ejemplo cuando alguien introduce un switch no autorizado a tus puertos de acceso.
Root Guard es una característica que evita que el puerto se convierta en Root Port. Esto significa que te protege por ejemplo cuando alguien introduce un switch no autorizado en tus puertos de acceso, y este switch quiere convertirse en Root Bridge.
La diferencia está en que Root Guard permite que otros switches sean conectados a tus puertos, simplemente actuara en el momento que otro switch quiera convertirse en Root Bridge. BPDU Guard no permite que ningún switch sea conectado a tus puertos ya que los switches generaran BPDUs, y al recibirlos BPDU guard deshabilita el puerto.
Espero que ahora quede claro.
Quedamos atentos.
Saludos! =)
Hola Alejandro, primero muchas felicidades por la certificación y por tu titulación en tu carrera de ingeniería!! También muchísimas gracias por tus palabras que nos alegran el día, los logros de los estudiantes son también nuestros, así que muy felices. Si quieres regalarnos una recomendación como mencionas, puedes hacerla acá: https://www.facebook.com/netwgeeks/reviews =)
Y por supuesto que te esperamos para futuras certificaciones que estamos seguros las necesitaras más adelante en tu camino profesional.
¡Saludos cordiales, y a festejar! =)
Hola José.
La verdad al hablar de redes inalámbricas hay muchos ángulos que se deben atacar para mejorar la señal, ya sea disminuir potencia, cambiar de frecuencia, analizar el espectro por interferencias, posicionamiento de antenas, etc. Unas de las herramientas que nos ayudan en el tema de interferencias, es como mencionas RRM. Sin embargo, como también le mencionaba a otro compañero en otra clase, y como tú mismo has experimentado en tus site surveys, RRM no hace magia, RRM no puede arreglar una red mal diseñada, y no es una herramienta creada para solucionar por completo las interferencias. De hecho, según Cisco, el uso de estas herramientas puede mejorar hasta un 40% los problemas de interferencia co canal, así que ya lo ves.
Además, recuerda que una red diseñada hace años, no es la misma que tienes hoy en día; tu red sí puede ser la misma, pero la proliferación de dispositivos inalámbricos que se van teniendo cada año, hace que tu red inalámbrica ya no tenga el mismo espacio de espectro electromagnético. Cuantas personas conoces hoy en día que tienen relojes wifi, autos con conexión wifi, electrodomésticos, conexiones compartidas de celular… entonces cada vez hay más puntos de acceso activos que hacen más difícil el tema de RRM.
Si recomiendo tenerlo activo, pero no es una solución que la activas y te olvidas de tu red, toca hacer optimizaciones todo el tiempo, y más aún si trabajas en 2.4Ghz y en ambientes saturados; siempre debes estar monitoreando el rendimiento, y haciendo diferentes optimizaciones.
Te dejo acá un documento de RRM donde hablan entre muchas cosas, sobre lo que te mencione respecto a las dificultades que tiene esta herramienta en entornos saturados: https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-3/b_RRM_White_Paper/rrm.html
Saludos! =)
Hola José!
Bienvenido a la plataforma, gracias por el comentario. Esperamos que los cursos sean de tu agrado, y estamos al pendiente para cualquier duda que tengas sobre el contenido.
Saludos cordiales!
Hola Hugo!
Puedes verlo acá en la sección de EIGRP: https://netwgeeks.com/topic/eigrp-filtering-distribution-lists-with-route-maps/
Quedamos atentos.
Saludos!
Hola Andrea!
Gracias por la observación, ya hemos corregido el archivo, podrías validar por favor?
Saludos!
Hola Patrick, puedes verlo acá: https://netwgeeks.com/topic/ip-sla-icmp-echo-operation-with-track/ , está en el modulo 4 del curso.
Saludos! =)
Hola Alejandro! =)
Lo que pasa es que no podemos comparar métricas que corresponden a diferentes protocolos de enrutamiento, ¿una métrica de 10 de EIGRP es mejor a una métrica de 10 de OSPF? ¿una métrica de 1 de RIP es mejor a una métrica de 1 de OSPF?… si solo consideramos a la métrica, la respuesta es que no lo sabemos. Es por ello que la «métrica menos preferida», corresponde al protocolo de enrutamiento que sea el «menos preferido», y ¿cómo sabemos cuál de todos los protocolos de enrutamiento es el menos preferido en este caso?, pues a través de la distancia administrativa. Es por eso que la respuesta es la D.
Espero que ahora quede claro.
Saludos! =)
