Laboratorio — Entorno de trabajo

Todo el trabajo práctico del curso se hace en su laptop, sin equipos de red físicos. Un contenedor Docker trae el compilador de C, las herramientas de red y Containerlab. Cada router de los laboratorios es a su vez otro contenedor, con FRRouting. Así evitamos el “en mi computadora sí funciona”: si las pruebas pasan en el contenedor, pasan en la revisión.

1. Requisitos

Recomendación: 8 GB de memoria RAM, con al menos 4 GB disponibles para Docker, y unos 4 GB libres de disco. Una topología de 24 routers usa alrededor de 700 MB.

Las imágenes son nativas: corren como ARM en un procesador ARM y como x86-64 en uno Intel o AMD, sin emulación.

2. Levantar el contenedor

Desde la carpeta del repositorio del curso:

./env/run.sh                 # la primera vez construye las imágenes (unos minutos)
env/smoke/check.sh           # dentro del contenedor: comprueba que todo funciona

check.sh debe terminar con todas las líneas en ok. run.sh monta la carpeta actual en la misma ruta que tiene en su computadora. Los archivos se editan con su editor de siempre y se ejecutan en el contenedor. También acepta un comando:

./env/run.sh make test       # corre las pruebas de la carpeta actual
./env/run.sh --rebuild       # reconstruye las imágenes

Si su proyecto está en otra carpeta, llamen a run.sh con su ruta completa desde allí. Si el contenedor ya está abierto y corren run.sh en otra terminal, se abre otra shell en el mismo contenedor.

Un contenedor con muchos permisos. Containerlab exige --privileged, y que el contenedor pueda hablar con el Docker de su computadora. Por eso, usen este contenedor solo para el curso y no corran dentro de él código en el que no confíen.

3. Topologías con Containerlab

Cada laboratorio trae un archivo <nombre>.clab.yml:

containerlab deploy -t lab.clab.yml            # levanta la red
docker exec -it clab-<lab>-r1 vtysh            # entra a la consola del router r1
docker exec clab-<lab>-r1 ip route             # corre un comando en r1
containerlab destroy -t lab.clab.yml --cleanup # la destruye

Dentro de vtysh, los comandos más usados son show ip route, show ip ospf neighbor y show bgp summary.

4. Capturas de tráfico

Capturen con tcpdump dentro del nodo que quieran observar, y abran el archivo en Wireshark:

docker exec clab-<lab>-r1 tcpdump -i eth1 -w /tmp/r1.pcap   # Ctrl+C para terminar
docker cp clab-<lab>-r1:/tmp/r1.pcap .

tshark también está en el contenedor, para quienes prefieran quedarse en la terminal.

5. Límites que conviene conocer

• traceroute hacia Internet: dentro del contenedor, Docker Desktop no deja ver los saltos intermedios y solo aparecen asteriscos. Córranlo en la terminal de su computadora. Dentro de las topologías del curso sí funciona.
• BBR: el kernel de Docker Desktop puede no incluirlo. Revisen con cat /proc/sys/net/ipv4/tcp_available_congestion_control. Los laboratorios solo exigen Reno y CUBIC.
• Mediciones: los resultados dependen de cada computadora. Comparen tendencias, no cifras exactas.

6. Pruebas

Cada carpeta de código (code/week-NN/) y cada entrega del proyecto trae un Makefile:

make           # compila o prepara
make test      # corre los ejemplos y las pruebas
make clean     # borra lo generado y destruye sus topologías

7. Solución de problemas