Seleccionar página
Guía Paso a Paso: Cómo Crear tu Primera Red en Cisco Packet Tracer

Guía Paso a Paso: Cómo Crear tu Primera Red en Cisco Packet Tracer

Si estás dando tus primeros pasos en el mundo de las redes o te encuentras preparando la certificación CCNA (Cisco Certified Network Associate), dominar Cisco Packet Tracer es fundamental. Esta herramienta de simulación te permite experimentar con topologías reales sin necesidad de hardware físico.

En este artículo, aprenderás a construir una red local (LAN) básica, configurar un router, asignar direccionamiento IP estático y, finalmente, automatizar el proceso mediante un servidor DHCP.


1. Topología y Componentes de la Red

Para este laboratorio, utilizaremos los siguientes dispositivos estándar de Cisco:

  • Router 2901: Actuará como nuestra puerta de enlace (Gateway).
  • Switch 2960: El punto de interconexión para nuestros dispositivos finales.
  • Dispositivos finales: Un PC, una Laptop y, posteriormente, un servidor DHCP.

Conexión de cables:

Utilizaremos cables directos (Copper Straight-Through) para las siguientes conexiones:

  • Del Router (GigabitEthernet 0/0) al Switch (GigabitEthernet 0/1).
  • De los PCs/Laptops a los puertos FastEthernet del Switch.

2. Configuración Inicial del Router (CLI)

El router es el cerebro de nuestra red. Para configurarlo, entraremos a la interfaz de línea de comandos (CLI) y seguiremos estos pasos:

  1. Entrar al modo privilegiado y de configuración:
    enable
    configure terminal
    
  2. Asignar un nombre y configurar la IP en la interfaz:
    Accedemos a la interfaz que conecta al switch y le asignamos la dirección IP que servirá como Default Gateway para toda la red:

     

    hostname R1
    interface GigabitEthernet 0/0
    ip address 192.168.0.1 255.255.255.0
    no shutdown
    

    Nota: El comando no shutdown es vital para activar físicamente la interfaz.

  3. Guardar cambios: Ejecuta el comando write para asegurar que la configuración no se borre al reiniciar.

3. Configuración de Dispositivos Finales (IP Estática)

Para que los equipos se comuniquen, deben pertenecer al mismo segmento de red (192.168.0.x).

Dispositivo Dirección IP Máscara Gateway
PC0 192.168.0.2 255.255.255.0 192.168.0.1
Laptop 192.168.0.3 255.255.255.0 192.168.0.1

Prueba de conectividad: Abre el Command Prompt de la Laptop y escribe ping 192.168.0.1. Si recibes respuesta, ¡tu red básica está funcionando correctamente!


4. Implementación de un Servidor DHCP

Configurar IPs manualmente es ineficiente en redes grandes. Por ello, añadiremos un Servidor DHCP para automatizar la asignación.

  1. Configuración del Servidor: Asigna una IP estática al servidor (ej. 192.168.0.10).
  2. Activación del Servicio:
    • Ve a la pestaña Services > DHCP.
    • Configura el Default Gateway (192.168.0.1).
    • Establece el rango de inicio (ej. 192.168.0.100).
    • Enciende el servicio (ON) y guarda.
  3. Prueba dinámica: Conecta un nuevo PC, cambia su configuración a «DHCP» y verás cómo recibe su IP de forma automática.

Conclusión

Entender cómo fluye el tráfico desde un dispositivo hasta su Gateway es la base para conceptos más avanzados como VLANs y enrutamiento dinámico.

¿Quieres ver el proceso en acción? Mira el tutorial paso a paso aquí:
Ver video en YouTube.

¿Tienes dudas con algún comando? ¡Déjala en los comentarios!

Cómo frenar ataques en tu red (sin volverte loco)

Cómo frenar ataques en tu red (sin volverte loco)

Si administras una red (aunque sea pequeña), tarde o temprano te vas a topar con esto: un usuario que “sin querer” instala algo raro, un equipo que queda sin parches, una contraseña compartida por WhatsApp, o un servicio expuesto que nadie recordaba. La buena noticia: no necesitas ser un “hacker” para defenderte. Necesitas método, capas y hábitos.

En este artículo te explico, de forma clara y entretenida, cómo mitigar ataques de red usando prácticas reales que sí se aplican en empresas. Y lo haré con ejemplos, para que no quede en teoría.

 

1) Defensa en profundidad: no confíes en un solo candado

 

Piensa en tu red como una casa. Si solo tienes una cerradura en la puerta principal, el día que la fuerzan, se acabó. En redes, lo mismo: si solo dependes del firewall perimetral, estás dejando demasiado en manos de una sola barrera.

Defensa en profundidad significa poner varias capas: aunque una falle, otra detiene o limita el daño.

Ejemplo práctico: un usuario abre un adjunto malicioso (capa usuario falló). Si tienes EDR/antivirus actualizado (capa endpoint), puede bloquearlo. Si no lo bloquea y el malware intenta moverse a otros segmentos (capa red), VLAN + ACL limitan el movimiento lateral. Y si intenta salir a Internet a un dominio raro, el firewall/filtrado DNS lo corta (capa perímetro).

 

 

2) Backups: no son “por si acaso”, son tu plan B real

Hay ataques que no “rompen” tu red: te dejan sin red. Especialmente ransomware o corrupciones de configuración. En esos casos, la pregunta no es “¿cómo lo evito?”, sino “¿qué tan rápido me recupero?”.

Qué respaldar en redes:

• Configuración de switches, routers y firewalls

• Imágenes/firmware (IOS, FortiOS, etc.)

• Configuración de AAA (RADIUS/TACACS+), VPN, políticas

Ejemplo práctico: actualizaste un firewall y algo salió mal. Si tienes backup verificado, vuelves a la versión anterior en minutos. Si no, comienzas a reconstruir reglas “de memoria” con la empresa caída. No quieres vivir eso.

Consejo de oro: un backup que nunca se probó… es un “deseo”, no un backup. Agenda pruebas de restauración (aunque sea trimestral).

 

 

3) Parcheo y actualizaciones: el ataque más común es el más simple

Muchas intrusiones no ocurren por magia, ocurren porque el atacante encontró una vulnerabilidad conocida y el sistema seguía sin parche. Así de directo.

Ejemplo realista: un servidor con un servicio web antiguo expuesto. Sale una CVE, pasa un mes, nadie parchea. Un bot lo escanea, lo explota y listo: ya tienes un foothold dentro.

Práctica recomendada:

• Mantén inventario de versiones (equipos y software)

• Parchea por criticidad (no todo al mismo tiempo)

• Programa ventanas de mantenimiento

• Revisa firmware en equipos de red (switches y routers también importan)

 

 

4) AAA: “¿Quién eres?”, “¿Qué puedes hacer?” y “¿Qué hiciste?”

AAA suena técnico, pero es muy humano: es el control de acceso bien hecho.

AAA significa:

Autenticación: ¿quién eres?

Autorización: ¿qué estás permitido a hacer?

Contabilidad: ¿qué hiciste exactamente?

Ejemplo entretenido: imagina una tarjeta de crédito:

• Autenticación = el banco verifica que eres tú

• Autorización = te deja gastar hasta cierto límite

• Contabilidad = queda el registro de compras

En red es igual. Si todos entran al switch con la misma clave “admin123”, no hay control ni trazabilidad. Si un día aparece una VLAN cambiada o una ACL borrada, nadie sabe quién fue.

Lo correcto: usuarios individuales, roles (solo lectura vs admin), y logs de comandos (ideal con TACACS+). Eso te salva en auditorías y en incidentes.

 

 

5) Firewalls: el portero del edificio (pero no el único)

Un firewall no es “la seguridad”, pero sí es una pieza central. Controla qué entra, qué sale y qué cruza entre zonas.

Ejemplo simple: tienes una red interna y publicas un servidor web. Si pones el servidor directo en la red interna, cualquier fallo en ese servidor puede abrir la puerta al resto. Si lo pones en una DMZ, incluso si lo comprometen, el salto a la red interna es mucho más difícil.

Regla de supervivencia: “deny all” por defecto, y luego permites solo lo necesario. Lo demás es una invitación al caos.

 

 

6) Tipos de firewall (explicados sin dolor)

No todos los firewalls filtran igual. Y entenderlo te ayuda a elegir y configurar mejor.

Filtrado de paquetes: decide por IP/puerto/protocolo. Rápido, básico.

Stateful (SPI): “recuerda” conexiones. Si alguien de Internet intenta entrar sin que tú hayas iniciado sesión antes, lo bloquea. Es el estándar moderno.

Filtrado de aplicaciones: no solo ve “puerto 443”, intenta reconocer la app real (YouTube, Dropbox, VPNs raras).

Filtrado de URL: bloquea categorías o sitios (phishing, malware, etc.).

Ejemplo práctico: un usuario “solo navega”, pero cae en un sitio de phishing. Un buen filtro URL puede frenarlo antes del desastre. Si además hay inspección de aplicaciones, puedes limitar apps no deseadas que se disfrazan de tráfico web.

 

 

Tu red segura no es “perfecta”, es “resiliente”

El objetivo real no es que tu red sea invulnerable (eso no existe). El objetivo es que, cuando algo pase, el impacto sea pequeño y la recuperación sea rápida.

Si aplicas estas 6 ideas con disciplina (capas, backups probados, parches, AAA, firewalls por zonas y políticas claras), tu red deja de ser una “caja negra” frágil y se convierte en una infraestructura seria, controlada y defendible.

Si quieres, te preparo la versión 2 de este artículo con un enfoque aún más práctico: checklist de implementación, ejemplos de políticas, y un mini-lab para Packet Tracer orientado a CCNA.

Membresía eClassVirtual
DNS, DHCP y WEB en Cisco Packet Tracer

DNS, DHCP y WEB en Cisco Packet Tracer

En Cisco Packet Tracer, tres servicios básicos explican la mayoría de los escenarios de “la red no funciona”: DHCP (asignación automática de IP), DNS (resolución de nombres) y WEB/HTTP (publicación de un sitio). Si dominas estos tres, ya tienes una base sólida para laboratorios tipo CCNA.

1) DHCP: asignación automática de direcciones IP (configurado en Server en Packet Tracer)
DHCP (Dynamic Host Configuration Protocol) entrega automáticamente a los PCs los parámetros esenciales para operar en red: IP, máscara, gateway y DNS. En Packet Tracer es muy común levantar DHCP en un Server para simular un entorno real con servicios centralizados.

Escenario de ejemplo
Red: 192.168.10.0/24
Gateway: 192.168.10.1
Servidor (DHCP + DNS): 192.168.10.10
Servidor WEB: 192.168.10.20
Dominio: www.eclassvirtual.com

Configurar IP estática del Server DHCP/DNS
En el Server (pestaña Desktop > IP Configuration), asigna:
IP: 192.168.10.10
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.10.1

Configurar DHCP en Server
Ve a Services > DHCP y activa On. Luego crea el pool con estos parámetros (o equivalentes):

  • Pool Name: LAN_USUARIOS
  • Default Gateway: 192.168.10.1
  • DNS Server: 192.168.10.10
  • Start IP Address: 192.168.10.21
  • Subnet Mask: 255.255.255.0
  • Maximum Number of Users: por ejemplo 50

Con esto, cualquier PC en la LAN podrá obtener una IP automáticamente, sin tener que configurar nada a mano.

2) DNS: traducción de nombres a direcciones IP
DNS (Domain Name System) permite que el usuario navegue usando nombres fáciles (como www.eclassvirtual.com) en vez de memorizar IPs (como 192.168.10.20). En Packet Tracer también se configura desde un Server.

Configurar DNS en Server
En el mismo Server 192.168.10.10, ve a Services > DNS y activa el servicio. Agrega un registro tipo A:

  • Name: www.eclassvirtual.com
  • Address: 192.168.10.20

Eso significa: cuando un PC pregunte por www.eclassvirtual.com, el DNS responderá con la IP del servidor web 192.168.10.20.

3) WEB/HTTP: publicación de una página
El servicio WEB (HTTP) es lo que el usuario finalmente “ve”. Si DNS funciona pero no hay HTTP levantado, el navegador no cargará el sitio. En Packet Tracer puedes montar un web server en un Server dedicado.

Configurar Server WEB
En el Server WEB, asigna IP estática en Desktop > IP Configuration:
IP: 192.168.10.20
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.10.1

Luego ve a Services > HTTP y activa HTTP: On. Si quieres, edita el index.html para personalizar la página de prueba.

Pruebas finales (lo que valida que todo quedó bien)
Desde un PC cliente:

  1. Obtener IP por DHCP: en Desktop > IP Configuration selecciona DHCP.
  2. Confirmar parámetros: en Desktop > Command Prompt ejecuta ipconfig y revisa que exista IP, gateway y DNS.
  3. Probar DNS: ejecuta ping www.eclassvirtual.com (debería resolver a 192.168.10.20).
  4. Probar WEB: abre el navegador y entra a http://www.eclassvirtual.com.

Idea clave: si algo falla, aisla por capas. Primero DHCP (sin IP no hay red). Luego DNS (sin resolución, no hay nombres). Y finalmente HTTP (sin servicio web, no hay sitio). Esta secuencia de verificación te ahorra muchísimo tiempo en laboratorio y en redes reales.

VLSM en profundidad y la matemática real detrás del direccionamiento IP

VLSM en profundidad y la matemática real detrás del direccionamiento IP

VLSM (Variable Length Subnet Mask) no es un concepto “avanzado” por sí mismo.
Es la aplicación correcta de la aritmética binaria al diseño de redes IP.

 

Si entiendes la matemática que hay detrás, VLSM deja de ser confuso y pasa a ser completamente predecible.
En este artículo verás VLSM desde la base matemática, tal como Cisco espera que lo comprendas.

 

Idea clave: VLSM consiste en asignar distintas máscaras a diferentes segmentos,
ajustando el tamaño de cada subred al número real de hosts requeridos para minimizar desperdicio.

 

1) Fundamento matemático del direccionamiento IPv4

Una dirección IPv4 tiene 32 bits, divididos en dos partes:

  • Bits de red (identifican la subred)
  • Bits de host (identifican el dispositivo dentro de esa subred)

La relación matemática base es:

\(\text{Hosts utilizables} = 2^{n} - 2\)

Donde n es la cantidad de bits disponibles para hosts.
Se restan 2 direcciones: Network ID y Broadcast.

 

2) Relación entre máscara y cantidad de hosts

Para una máscara /x, los bits de host son:
n = 32 − x.

Máscara Bits host (n) Hosts utilizables (2^n − 2)
/24 8 254
/25 7 126
/26 6 62
/27 5 30
/28 4 14
/29 3 6
/30 2 2
Tip CCNA: No es una tabla “para memorizar”. Si sabes que n = 32 − x,
puedes calcular hosts con 2^n − 2.

3) ¿Por qué VLSM es necesario?

En FLSM (Fixed Length Subnet Mask) todas las subredes tienen el mismo tamaño,
aunque no lo necesiten. Matemáticamente esto produce desperdicio.

VLSM permite variar n por segmento (según requerimiento real),
optimizando el consumo de direcciones y dejando espacio para crecimiento.

4) Ejemplo completo VLSM con desarrollo matemático

Red base

192.168.50.0/24

Bits de red: 24
Bits de host: 8
Total direcciones: 2^8 = 256

Requerimientos

Segmento Hosts requeridos
Usuarios 120
Servidores 60
Gestión 12
Enlace P2P 2
Regla VLSM: Se asigna primero la subred más grande, luego las medianas, luego las pequeñas.
Esto evita que una subred grande “rompa” el espacio ya asignado.

5) Paso 1: determinar la máscara mínima por segmento

Usuarios – 120 hosts

Buscamos n tal que:

\(2^n - 2 \ge 120\)
  • \(2^6 – 2 = 62\) → no alcanza
  • \(2^7 – 2 = 126\) → alcanza

Resultado: n = 7 → máscara = 32 − 7 = /25

Servidores – 60 hosts

\(2^n - 2 \ge 60\)
  • \(2^6 – 2 = 62\) → alcanza

Resultado: n = 6 → máscara = 32 − 6 = /26

Gestión – 12 hosts

\(2^n - 2 \ge 12\)
  • \(2^4 – 2 = 14\) → alcanza

Resultado: n = 4 → máscara = 32 − 4 = /28

Enlace punto a punto – 2 hosts

\(2^2 – 2 = 2\)

Resultado: n = 2 → máscara = 32 − 2 = /30

6) Paso 2: tamaño de bloque (salto) y máscaras

Para calcular el salto (block size) en el último octeto cuando la máscara cae en ese octeto:

\(\text{Salto} = 256 - \text{octeto de la máscara}\)
Prefijo Máscara Octeto relevante Salto
/25 255.255.255.128 128 256 − 128 = 128
/26 255.255.255.192 192 256 − 192 = 64
/28 255.255.255.240 240 256 − 240 = 16
/30 255.255.255.252 252 256 − 252 = 4
Interpretación: el salto indica cada cuántas direcciones comienza una nueva subred dentro del octeto.
Por ejemplo, en /26 las subredes comienzan en 0, 64, 128, 192, etc.

7) Paso 3: asignación VLSM (red, hosts y broadcast)

Se asigna desde el inicio del bloque base, respetando saltos y sin solapar rangos.

7.1 Subred Usuarios: 192.168.50.0/25

  • Network: 192.168.50.0
  • Salto /25: 128 → siguiente red sería .128
  • Broadcast: 192.168.50.127
  • Hosts: 192.168.50.1 – 192.168.50.126

7.2 Subred Servidores: 192.168.50.128/26

  • Network: 192.168.50.128
  • Salto /26: 64 → subred cubre .128 a .191
  • Broadcast: 192.168.50.191
  • Hosts: 192.168.50.129 – 192.168.50.190

7.3 Subred Gestión: 192.168.50.192/28

  • Network: 192.168.50.192
  • Salto /28: 16 → subred cubre .192 a .207
  • Broadcast: 192.168.50.207
  • Hosts: 192.168.50.193 – 192.168.50.206

7.4 Subred Enlace P2P: 192.168.50.208/30

  • Network: 192.168.50.208
  • Salto /30: 4 → subred cubre .208 a .211
  • Broadcast: 192.168.50.211
  • Hosts: 192.168.50.209 – 192.168.50.210

Resumen de asignación

Segmento Subred Máscara Rango hosts Broadcast
Usuarios 192.168.50.0/25 255.255.255.128 192.168.50.1 – 192.168.50.126 192.168.50.127
Servidores 192.168.50.128/26 255.255.255.192 192.168.50.129 – 192.168.50.190 192.168.50.191
Gestión 192.168.50.192/28 255.255.255.240 192.168.50.193 – 192.168.50.206 192.168.50.207
P2P 192.168.50.208/30 255.255.255.252 192.168.50.209 – 192.168.50.210 192.168.50.211

8) Validación matemática final (consumo de direcciones)

Direcciones totales en /24:

\(2^8 = 256\)

Direcciones consumidas por cada prefijo (no “hosts”, sino direcciones del bloque):

  • /25 → \(2^{7} = 128\) direcciones
  • /26 → \(2^{6} = 64\) direcciones
  • /28 → \(2^{4} = 16\) direcciones
  • /30 → \(2^{2} = 4\) direcciones
\(128 + 64 + 16 + 4 = 212\)

Direcciones restantes:

\(256 - 212 = 44\)
Lectura de ingeniería: el diseño no solo cumple requerimientos, sino que deja 44 direcciones disponibles
para crecimiento (nuevas VLANs, enlaces adicionales, segmentación futura).

9) Errores matemáticos típicos en VLSM (CCNA y terreno)

  • No restar Network y Broadcast al calcular hosts (\(2^n – 2\)).
  • Elegir una máscara que no cumple \(2^n – 2 \ge \text{hosts requeridos}\).
  • No calcular el tamaño de bloque (salto) y “partir” subredes en límites inválidos.
  • Solapar rangos por asignar subredes pequeñas antes que las grandes.
  • Confundir direcciones del bloque (2^n) con hosts utilizables (2^n − 2).

Conclusión

VLSM es aritmética binaria aplicada a ingeniería de redes. Si dominas:

  • La fórmula \(2^n – 2\)
  • La relación n = 32 − prefijo
  • El tamaño de bloque (salto)
  • La asignación secuencial sin solapamiento

entonces VLSM deja de ser un “tema difícil” y se vuelve un procedimiento mecánico,
verificable y 100% auditable.

Si quieres, puedo preparar una versión adicional con:
cálculo binario bit a bit, o una guía para resolver VLSM
más rápido en el examen CCNA.

 

 

Estudia Cisco CCNA 200-301 con el Pack de Cursos más completo del mercado en https://pack.eclassvirtual.com

Pack Cisco CCNA 200-301
Troubleshooting en redes Cisco: metodología, estrategias y comandos clave

Troubleshooting en redes Cisco: metodología, estrategias y comandos clave

Troubleshooting en redes Cisco: metodología, estrategias y comandos clave

En redes Cisco, resolver incidentes no depende de “probar suerte” con comandos al azar.
Un troubleshooting efectivo se basa en método, orden y evidencia.
En este artículo veremos un enfoque técnico y educativo para diagnosticar fallas en redes Cisco,
junto con las estrategias más utilizadas en entornos reales.

 

1) Antes del CLI: define el problema con precisión

 

Antes de conectarte por consola o SSH, define el incidente en términos claros. Un diagnóstico
acertado comienza con preguntas simples:

  • ¿Qué dejó de funcionar exactamente? (servicio, aplicación, VLAN, enlace, usuario, sitio)
  • ¿Desde cuándo ocurre? (cambio reciente, mantenimiento, corte de energía, actualización)
  • ¿Es total o parcial? (afecta a todos, a un segmento, a una sede, a una VLAN)
  • ¿Hay síntomas repetibles? (intermitencia, horario, alto uso, pérdida de paquetes)

Este paso evita el error más común: diagnosticar sin entender el problema.

 

2) Estrategias de troubleshooting más usadas (y cuándo aplicarlas)

 

2.1 Top-Down (de capa alta a capa baja)

Empieza desde la aplicación y baja por las capas. Es útil cuando “la red se ve bien” pero el servicio no responde.

  • Cuándo usarlo: fallas de aplicaciones (web, ERP, Teams), problemas DNS, sesiones TCP.
  • Ventaja: detecta rápido si el problema está en servicios (DNS, puertos, certificados, etc.).

 

2.2 Bottom-Up (de capa baja a capa alta)

Comienza por lo físico (link, errores, drops) y avanza hacia IP y aplicaciones.
Es ideal para caídas totales o puertos en down.

  • Cuándo usarlo: enlace caído, interfaz down, pérdida total de conectividad.
  • Ventaja: detecta rápido problemas de cableado, SFP, negociación, errores físicos.

 

2.3 Divide and Conquer (la más usada en producción)

Se valida primero una capa “intermedia” (normalmente IP) para decidir si subir o bajar.
Es muy eficaz en redes grandes y bajo presión de tiempo.

  • Cuándo usarlo: incidentes en redes complejas, múltiples saltos, operación 24/7.
  • Ejemplo: si hay ping al gateway, el problema puede estar hacia arriba (rutas/ACL/DNS).
    Si no hay ping, baja a VLAN/trunks/físico.

 

2.4 Follow the Path (seguir el camino del tráfico)

Analiza salto por salto desde el origen al destino: dónde se pierde el tráfico y por qué.
Fundamental en escenarios intersite, MPLS/SD-WAN, túneles y ambientes segmentados.

  • Cuándo usarlo: conectividad entre sedes, rutas asimétricas, problemas inter-VLAN o WAN.
  • Ventaja: reduce con precisión el punto de falla a un nodo/enlace específico.

 

2.5 Comparación contra un estado “normal”

Compara con un equipo/enlace que funciona correctamente (misma plantilla, misma sede, mismo modelo).
Es una forma muy rápida de detectar diferencias de configuración.

  • Cuándo usarlo: fallas en un solo nodo o una sola sede “clonada”.
  • Ventaja: evidencia diferencias (VLAN permitidas, rutas, STP, ACL, etc.).

 

3) Metodología recomendada (estructura clásica)

Una secuencia de trabajo ordenada reduce errores y mejora el tiempo de resolución:

  1. Definir el problema (síntoma y alcance)
  2. Recopilar información (estado, logs, contadores, topología, cambios recientes)
  3. Analizar posibles causas (hipótesis)
  4. Probar hipótesis (validaciones controladas)
  5. Aplicar la corrección (con impacto controlado)
  6. Verificar el resultado (pruebas post-cambio)
  7. Documentar (qué se hizo, por qué, evidencia, lecciones aprendidas)

La documentación suele omitirse, pero en operación y auditoría es la diferencia entre “apagar incendios”
y mejorar el servicio.

 

4) Checklist técnico: qué revisar en una red Cisco

 

4.1 Capa física y enlace

  • Estado de interfaz (up/down)
  • Errores CRC, drops, overruns, flaps
  • Negociación (speed/duplex)
  • SFP/FO: potencia óptica (si aplica)

 

4.2 Capa 2 (VLAN, trunking y loops)

  • VLAN correcta en puerto de acceso
  • Trunk activo y VLANs permitidas
  • STP: root bridge, puertos bloqueados, cambios de topología
  • Tabla MAC: aprendizaje, flapping

 

4.3 Capa 3 (routing y forwarding)

  • Gateway correcto, ARP, reachability
  • Tabla de rutas y next-hop
  • CEF (cuando aplique) para validar forwarding
  • Asimetrías: ida por un camino y retorno por otro

 

4.4 Políticas y servicios (ACL, NAT, DNS, DHCP)

  • ACL bloqueando puertos/subredes
  • NAT (si aplica) y sesiones
  • DNS resolviendo correctamente
  • DHCP entregando IP, gateway y DNS correctos

 

5) Comandos Cisco útiles (base para diagnóstico)

 

5.1 Estado general

show ip interface brief
show interfaces status
show version

5.2 Interfaces (errores y contadores)

show interfaces
show interfaces counters errors
show interfaces description

5.3 Capa 2: VLAN, trunk y MAC

show vlan brief
show interfaces trunk
show mac address-table
show spanning-tree

5.4 Capa 3: rutas y forwarding

show ip route
show ip cef
traceroute <destino>
ping <destino> source <ip-origen>

5.5 Descubrimiento (para validar vecinos y enlaces)

show cdp neighbors detail
show lldp neighbors detail

5.6 Logs (para correlacionar eventos)

show logging
show clock

Consejo: guarda evidencia con terminal length 0 y exporta salida a un archivo cuando sea posible.

 

6) Errores típicos (y cómo evitarlos)

  • “Cambiar para probar” en producción: crea más incidentes de los que resuelve.
  • No volver al estado inicial: deja configuraciones temporales y genera problemas futuros.
  • No registrar evidencias: dificulta soporte, auditoría y lecciones aprendidas.
  • No aislar el alcance: un problema en una VLAN termina tratándose como un problema “de toda la red”.

 

Conclusión

El troubleshooting en redes Cisco es una habilidad que se desarrolla con metodología y práctica.
Aplicar estrategias como Divide and Conquer o Follow the Path, junto con un checklist por capas,
permite diagnosticar incidentes más rápido, reducir el impacto y entregar soluciones sustentables.

 

Membresia eClassVirtual

De limpiar teclados a Arquitecto de Redes: la historia real detrás de mi transformación

De limpiar teclados a Arquitecto de Redes: la historia real detrás de mi transformación

de-limpiador-de-teclados-a-arquitecto-cisco

El Rechazo ;(

Cuando recién comencé, yo ya era Ingeniero titulado. Había estudiado, me había esforzado y tenía la expectativa natural de entrar a un equipo donde pudiera aportar, aprender y crecer.

Pero la realidad fue distinta.

Un día me dijeron:

“No tienes experiencia para estar con los ingenieros. Anda con el grupo de técnicos a hacer mantención: limpiar PCs, teclados y monitores.”

Me quedé helado.

No era que no tuviera título, era que mi título no valía nada para ellos.

Sentí tristeza.
Sentí vergüenza.
Sentí impotencia.

Era como si me hubieran dicho:

“No eres lo suficientemente bueno para estar aquí.”

Sin embargo, mientras limpiaba equipos, miraba los switches, racks y routers y pensaba:

“Algún día, yo estaré del otro lado. Algún día seré quien diseña, configura y lidera estas redes.”

Ese momento —tan humilde y doloroso— fue mi punto de quiebre.


El día que decidí cambiar mi historia

No me quedé quejándome.
No me quedé esperando reconocimiento.

Tomé una decisión:

  • Me voy a certificar Cisco CCNA.
  • Voy a estudiar hasta dominar redes.
  • Voy a demostrar lo que valgo.

Empecé desde cero:

  • No entendía subnetting
  • Packet Tracer parecía otro idioma
  • No sabía configurar ni un switch sencillo

Pero todos los días aprendía un poco.
Fallé muchas veces.
Y seguí.


La certificación fue mi llave

Cuando logré el Cisco CCNA, algo cambió:

  • Mi seguridad
  • Mi credibilidad
  • Mi posición ante los demás

Pasé de ser:

“El Ingeniero que parecía técnico”

a ser:

“El profesional que diseña, configura y resuelve redes reales.”

Y con el tiempo —tras más estudio, experiencia y especialización— esa certificación me abrió puertas más grandes:

Arquitecto de Redes en una de las compañías mineras más grandes del mundo.

El mismo Ingeniero que enviaron a limpiar teclados… terminó liderando proyectos críticos, diseñando infraestructura y tomando decisiones estratégicas para miles de usuarios.


Lo que aprendí en el camino

En nuestra industria entendí algo clave:

El título importa, pero la certificación valida tu capacidad real.

CCNA no fue un simple papel. Fue:

  • Mi puente al mundo profesional real
  • El acelerador de mi carrera
  • El inicio de una transformación personal y profesional

Por eso hoy ayudo a quienes comienzan

Porque sé lo que es:

  • Sentir que te subestiman
  • Entrar con título pero sin experiencia
  • No saber por dónde empezar en redes

Y también sé lo que se siente:

  • Certificarse
  • Crecer
  • Romper límites
  • Cambiar de rol y de vida

Por eso creé el Pack Cisco CCNA de eClassVirtual.

Es el camino que yo habría querido tener:

  • Guiado
  • Práctico
  • Estructurado
  • Diseñado para quienes empiezan desde cero… incluso si ya son titulados

Porque muchos Ingenieros tienen título, pero lo que les falta es certificación, práctica y confianza real.

Si quieres transformar tu carrera como yo lo hice, aquí tienes tu puerta de entrada:

 

👉 Accede al Pack Cisco CCNA de eClassVirtual

 

Pack Cisco CCNA 200-301

 


Reflexión final

Nunca olvidaré el día en que me dijeron que:

“Yo no pertenecía al equipo de ingenieros.”

Hoy, como Arquitecto de Redes, miro atrás y sonrío:

Siempre pertenecí.
Solo necesitaba demostrárselo al mundo… y a mí mismo.

Y tú también puedes.

El título fue el inicio.
La certificación fue el camino.
La decisión fue lo que lo hizo posible.