Diseñar la red de un campus universitario en Cisco Packet Tracer significa pensar como un arquitecto: varios edificios, cientos de hosts, un backbone que escala y un plan de direccionamiento que no se queda sin IPs a mitad de semestre. En esta guía construimos esa red de campus completa — topología de tres capas, VLANs por edificio, backbone OSPF multi-área, direccionamiento VLSM y ACLs — para que generes con NetPilot un .pkt que funciona Y obtengas la comprensión para defender cada decisión frente a tu profesor.
Qué necesita este proyecto de red de campus
Un proyecto de red de campus en Cisco Packet Tracer suele pedir más que "que dos PCs se hagan ping". Packet Tracer espera que demuestres un diseño jerárquico real. El alcance típico incluye:
- Varios edificios: facultades (Ingeniería, Ciencias), biblioteca, residencias estudiantiles y administración. Cada uno es su propio bloque de red.
- Una VLAN por edificio o por rol, con trunking 802.1Q entre switches y STP/RSTP para evitar bucles.
- Un backbone OSPF multi-área: área 0 en el núcleo y un área por edificio, para que la red escale sin inundar a todos con cada cambio.
- Un plan de direccionamiento VLSM que reparta el espacio de forma justa: residencias grandes obtienen subredes grandes, administración una pequeña.
- Un bloque de servidores (DNS, web, DHCP) en su propia VLAN aislada.
- DHCP por edificio para que cada PC reciba IP automáticamente.
- ACLs de seguridad que aíslen, por ejemplo, las subredes de estudiantes y residencias de las de administración y servidores.
La diferencia con una oficina pequeña es la escala: aquí se evalúa la jerarquía, la escalabilidad y un plan de subnetting bien pensado.
La forma rápida: descríbeselo a NetPilot
Antes de cablear 30 dispositivos a mano, deja que el agente de IA de NetPilot haga el primer borrador. Le describes la red en lenguaje natural y él diseña la topología, escribe la configuración Cisco IOS de cada dispositivo, exporta un .pkt funcional y te explica cada elección. Por ejemplo:
"Diseña la red de un campus universitario con cuatro edificios — Ingeniería, Biblioteca, Residencias y Administración — en un diseño de tres capas con núcleo, distribución y acceso. Una VLAN por edificio más una VLAN de servidores con DNS, web y DHCP. Usa OSPF multi-área con el núcleo en área 0 y cada edificio en su propia área. Direccionamiento VLSM desde 172.16.0.0/16 y una ACL que impida que las residencias lleguen a la subred de administración."
NetPilot interpreta eso, genera los switches de núcleo/distribución/acceso, los routers, el direccionamiento VLSM y las configuraciones completas, y te entrega el .pkt listo para abrir.
Y aquí está el porqué de cada paso: NetPilot no solo escupe configuración, sino que explica por qué el núcleo va en área 0 o por qué esa máscara /23. Además, la CLI directa siempre está disponible: puedes verificar cada configuración en una CLI real de Cisco IOL en el navegador (trayendo tu propia imagen de Cisco). El agente y la CLI son complementarios, no excluyentes.
Ese ida y vuelta con el .pkt binario es lo que distingue a NetPilot de ChatGPT: una herramienta de solo texto puede sugerirte comandos, pero no puede leer ni escribir el archivo .pkt que tu profesor abre y califica. NetPilot sí.
El diseño, explicado
Ahora construyamos el diseño a mano para entenderlo de verdad. Un proyecto de red de campus en Cisco Packet Tracer se sostiene sobre cuatro pilares: la jerarquía de capas, el plan de direccionamiento, el enrutamiento y la seguridad.
Las capas de la topología
El modelo de tres capas existe porque una red plana no escala. Lo dividimos así:
- Capa de acceso: los switches a los que se conectan PCs y puntos de acceso en cada edificio. Aquí viven las VLANs de usuario.
- Capa de distribución: un switch multicapa por edificio que agrega el acceso, hace el enrutamiento inter-VLAN local y conecta hacia el núcleo.
- Capa de núcleo: el backbone de alta velocidad que une todos los edificios — solo conmuta y enruta lo más rápido posible, sin filtrado ni lógica complicada.
En un campus pequeño puedes usar un núcleo colapsado (núcleo y distribución en el mismo equipo). Para un proyecto que pide demostrar escalabilidad, mantenerlos separados luce mejor.
Plan de VLANs y direccionamiento VLSM
VLSM (máscaras de longitud variable) evita el desperdicio: das subredes grandes donde hay muchos hosts y pequeñas donde hay pocos. Partimos de 172.16.0.0/16 y repartimos:
| Edificio / Rol | VLAN | Subred | Hosts útiles | Gateway |
|---|---|---|---|---|
| Residencias | 10 | 172.16.0.0/23 | 510 | 172.16.0.1 |
| Ingeniería | 20 | 172.16.2.0/24 | 254 | 172.16.2.1 |
| Biblioteca | 30 | 172.16.3.0/25 | 126 | 172.16.3.1 |
| Administración | 40 | 172.16.3.128/26 | 62 | 172.16.3.129 |
| Servidores | 99 | 172.16.4.0/27 | 30 | 172.16.4.1 |
Fíjate por qué: residencias recibe un /23 (más de 500 hosts) y administración un /26 (pocos equipos). Asignar un /24 a todos por igual desperdiciaría miles de direcciones.
En cada switch de acceso creas la VLAN y marcas el enlace al switch superior como trunk 802.1Q:
vlan 10
name Residencias
vlan 99
name Servidores
!
interface FastEthernet0/24
switchport mode trunk
switchport trunk allowed vlan 10,20,30,40,99El trunk transporta varias VLANs por un solo cable. Permitir explícitamente solo las VLANs necesarias es buena práctica de seguridad — y suma puntos en la rúbrica.
Enrutamiento inter-VLAN y backbone OSPF multi-área
Cada VLAN es una subred distinta, así que necesitan un router para hablar entre sí. En la capa de distribución usamos un switch multicapa con interfaces virtuales (SVI), una por VLAN, que actúa como gateway. Crea cada VLAN y su SVI con la IP de gateway del plan — incluida la VLAN 99 de servidores, para que el DNS sea alcanzable:
ip routing
!
vlan 10
name Residencias
vlan 20
name Ingenieria
vlan 30
name Biblioteca
vlan 40
name Administracion
vlan 99
name Servidores
!
interface Vlan10
ip address 172.16.0.1 255.255.254.0
interface Vlan20
ip address 172.16.2.1 255.255.255.0
interface Vlan30
ip address 172.16.3.1 255.255.255.128
interface Vlan40
ip address 172.16.3.129 255.255.255.192
interface Vlan99
ip address 172.16.4.1 255.255.255.224Para unir los edificios usamos OSPF multi-área. ¿Por qué multi-área y no área 0 para todo? Porque con un área única, cada cambio de enlace recalcula la topología de todo el campus; dividiendo en áreas, un problema en Residencias no molesta a Ingeniería. El núcleo va en el área 0 (la columna vertebral obligatoria) y cada edificio en su propia área conectada a ella. Cada router de distribución debe anunciar todas sus subredes enrutadas; si olvidas un network, esa subred queda inalcanzable desde el resto del campus:
router ospf 1
router-id 1.1.1.1
network 172.16.0.0 0.0.1.255 area 10
network 172.16.2.0 0.0.0.255 area 20
network 172.16.3.0 0.0.0.127 area 30
network 172.16.3.128 0.0.0.63 area 40
network 172.16.4.0 0.0.0.31 area 0
network 172.16.255.0 0.0.0.3 area 0Cada línea network anuncia una subred enrutada en su área: Residencias (VLAN 10) en el área 10, Ingeniería (VLAN 20) en el área 20, Biblioteca (VLAN 30) en el área 30, Administración (VLAN 40) en el área 40, la VLAN de Servidores y el enlace /30 hacia el núcleo en el área 0. Reserva ese enlace troncal del mismo plan 172.16.0.0/16 (p. ej. 172.16.255.0/30); si lo numeras fuera del plan, ninguna interfaz coincidirá con el network del área 0 y OSPF no formará adyacencia. En una topología de núcleo y distribución separados, cada switch de distribución solo anuncia las subredes que enruta y el enlace al núcleo en el área 0, repitiendo el patrón edificio por edificio.
Servicios: DHCP y DNS
Nadie configura IPs a mano en un campus. Levantamos un pool de DHCP por edificio en el router de distribución para que cada PC reciba dirección, gateway y DNS automáticamente:
ip dhcp excluded-address 172.16.0.1 172.16.0.10
ip dhcp pool RESIDENCIAS
network 172.16.0.0 255.255.254.0
default-router 172.16.0.1
dns-server 172.16.4.10El excluded-address reserva las primeras IPs para gateways y equipos fijos. El servidor DNS (172.16.4.10) vive en la VLAN 99, junto al servidor web, aislado del tráfico de usuarios.
Seguridad: ACLs entre segmentos
Un campus real no deja que un estudiante en residencias llegue a los servidores de administración. Una ACL extendida aplicada en el router de distribución de Administración bloquea ese tráfico:
ip access-list extended PROTEGER-ADMIN
deny ip 172.16.0.0 0.0.1.255 172.16.3.128 0.0.0.63
permit ip any any
!
interface Vlan40
ip access-group PROTEGER-ADMIN out
!
ip access-list extended PROTEGER-SERVIDORES
permit udp 172.16.0.0 0.0.1.255 host 172.16.4.10 eq 53
deny ip 172.16.0.0 0.0.1.255 172.16.4.0 0.0.0.31
permit ip any any
!
interface Vlan99
ip access-group PROTEGER-SERVIDORES outLa primera línea niega a la subred de residencias el acceso a la subred de administración; el permit ip any any final deja pasar todo lo demás (sin él, la ACL implícita bloquearía absolutamente todo). La dirección importa: se aplica saliente (out) en la SVI de Administración (VLAN 40) para filtrar el tráfico que va hacia administración — una ACL entrante (in) en la VLAN 40 solo filtraría el tráfico originado por los propios equipos de administración, no el de residencias. Una segunda ACL saliente en la SVI de Servidores (VLAN 99) hace lo mismo con el acceso de residencias a los servidores, permitiendo antes el DNS (172.16.4.10) para no romper la resolución de nombres. Conviene añadir también port security en los puertos de acceso para limitar las MAC por puerto y frenar conexiones no autorizadas.
Detalles de Cisco Packet Tracer a vigilar
- El switch 2960 no enruta: para SVIs e inter-VLAN necesitas un switch multicapa 3560 o 3650, no el 2960 de la capa de acceso. Si tu enrutamiento inter-VLAN no funciona, suele ser este el error.
- Activa el enrutamiento IP: en el switch multicapa, el comando
ip routingestá apagado por defecto. Sin él, las SVIs no se hablan entre sí. - OSPF tarda en converger: tras cablear, da unos segundos en modo simulación para que se formen las adyacencias antes de probar ping entre edificios.
- Cantidad de dispositivos: Packet Tracer puede ponerse lento con muchos equipos. Cablea y verifica edificio por edificio en lugar de levantar todo el campus de golpe.
FAQ
¿Cómo divido un campus con menos de 1000 hosts usando VLSM en Cisco Packet Tracer?
En Cisco Packet Tracer, empieza por la subred más grande y baja: asigna primero el bloque de mayor número de hosts (p. ej. residencias con un /23) desde tu red base como 172.16.0.0/16 y ve recortando máscaras más pequeñas para los segmentos chicos como administración. NetPilot calcula este reparto VLSM por ti y te explica por qué cada edificio recibe la máscara que recibe.
¿Por qué mi OSPF multi-área no forma adyacencia entre dos edificios en Packet Tracer?
En Cisco Packet Tracer, lo más común es que ambos lados del enlace de núcleo no estén en la misma área OSPF o que las máscaras wildcard del comando network no coincidan con la subred del enlace. Verifica que el enlace entre routers de distribución esté declarado en el área 0 en ambos extremos y que las IPs estén en la misma subred.
¿Necesito un switch multicapa para el enrutamiento inter-VLAN de mi proyecto de universidad?
Sí: en un proyecto de red de universidad en Cisco Packet Tracer necesitas un switch multicapa (3560 o 3650) con ip routing activado, o un router con router-on-a-stick, porque el switch 2960 de la capa de acceso no enruta entre VLANs. Para un campus de varios edificios, el switch multicapa en la capa de distribución es la opción que mejor escala.
¿Puede ChatGPT entregarme el archivo .pkt terminado de mi red de campus?
No: ChatGPT solo genera texto, así que puede sugerirte comandos pero no puede leer ni escribir el archivo .pkt binario que tu profesor abre y califica. NetPilot sí exporta un .pkt funcional de tu red de campus y te explica cada configuración para que la entiendas y la defiendas, no solo la entregues.
¿Cómo aíslo la red de residencias de la de administración en Cisco Packet Tracer?
En Cisco Packet Tracer, aplica una ACL extendida en la SVI de la VLAN de administración que niegue el tráfico desde la subred de residencias y permita el resto. Colócala en sentido saliente (out) en la SVI de administración (VLAN 40) — el tráfico a bloquear lo origina residencias y llega a esa SVI al salir hacia administración, así que una ACL entrante (in) ahí solo filtraría el tráfico originado por los propios equipos de administración. Termina siempre con permit ip any any para no bloquear el tráfico legítimo.
Diseñar la red de un campus universitario es uno de los proyectos más completos de Cisco Packet Tracer — y ahora tienes la jerarquía, el VLSM, el OSPF multi-área y las ACLs para construirlo entendiéndolo. Explora más ejercicios en el hub de proyectos de Packet Tracer y, si te atascas, el tutor de Packet Tracer de NetPilot te explica cada decisión paso a paso. Pruébalo gratis en https://app.netpilot.io: describe tu campus, obtén el .pkt y verifica cada config en una CLI real.