P2 · Qhapaq Ñan

Su sistema autónomo se conecta al resto del mundo con BGP. Primero contra un mundo simulado que corre en su laptop y después, en el hackathon, contra los demás equipos. Se usa lo visto en las semanas 6 y 7. Entrega en la semana 9.

Lo que reciben

• mundo/: una topología con los vecinos de su AS, de números privados: dos proveedores, un peer y dos clientes. También incluye un host externo, afuera, y un AS, pirata, que más adelante anuncia prefijos que no le corresponden.
• as/vecinos.env: quién es cada vecino.
• as/vty.sh: vtysh para usar desde un setup.sh sin pisarse con la carga de frr.conf.
• as/politicas.md: la plantilla de su informe.

Copien su carpeta as/ de P1 sobre la de este enunciado, sin borrar esos tres archivos.

                       afuera
                         |
              .------ troncal ------.------ pirata
              |          |          |
              pa        peer        pb
          proveedor A    |      proveedor B
              |          |          |
     c1 ---- r4          |          r2 ---- c2
   cliente 1   \         |         /   cliente 2
                 '---- su AS -----'

Cada vecino va siempre en el mismo router y la misma interfaz, en los dos mundos:

El resto de su red no cambia: los mismos nodos y las mismas interfaces de P1. La única diferencia es que ext ya no existe. r4:eth3 sigue ahí, pero no hay nada enchufado. Los enlaces con los vecinos usan direcciones de 100.64.0.0/16, que no son de ningún equipo.

Lo que deben hacer

1. Sesiones. Abrir eBGP con cada vecino desde r2 y r4, e iBGP entre sus routers.
2. Anuncio. Anunciar solo el agregado 100.(64 + X).0.0/16, nunca las direcciones privadas.
3. Importación. Preferir rutas de clientes, luego de peers y por último de proveedores, con local-preference.
4. Exportación. Las rutas de clientes y las propias, a todos. Las de peers y proveedores, solo a clientes. Usen comunidades de BGP para marcar el origen.
5. Ingeniería de tráfico. Salir por el proveedor A mientras exista, y usar el proveedor B solo como respaldo.
6. Defensa. Aceptar de cada cliente solo sus prefijos, con prefix-list. Rechazar los prefijos propios cuando vengan de afuera.
7. Borde. Ahora la oficina puede salir por r2 o por r4, según qué proveedor esté vivo. Hagan que nunca salga con su dirección privada y que nadie de afuera entre a ella, por ninguna interfaz hacia afuera. El NAT y el filtro de P1 solo cuidan r4:eth3, así que no alcanzan. Pueden poner NAT y filtro en cada router de borde, o un solo NAT más adentro y filtros en el borde: expliquen su decisión en el informe.
8. Informe. En as/politicas.md, explicar cada política en términos de quién paga a quién.

Tres cosas de P1 que van a estorbar

• La ruta por defecto hacia ext. Quítenla, y también su anuncio en OSPF. Si queda, los routers sin iBGP igual llegan a todas partes por r4, y no se dan cuenta de lo que les falta.
• Una dirección para r2. Si su NAT queda también en r2, necesita una dirección pública propia, en OSPF, igual que la de r4. La respuesta a un paquete que salió por un lado puede entrar por el otro.
• Una ruta hacia el agregado. BGP solo anuncia un prefijo que está en la tabla. Ningún router de P1 tiene el /16 completo: creen una ruta a Null0. No le gana a nada de OSPF, porque las de su red son más específicas.

as/vecinos.env

Es lo único que cambia el día del hackathon, y lo escribe el docente. Por eso todo lo que depende del vecino debe salir de ese archivo y no puede estar escrito en frr.conf: su dirección en el enlace, la del vecino, su AS y los prefijos de un cliente.

PROVEEDOR_A_DIR=100.64.71.2/30     # su dirección en el enlace, con su máscara
PROVEEDOR_A_VECINO=100.64.71.1     # la del vecino
PROVEEDOR_A_AS=64801               # el AS del vecino
CLIENTE_1_PREFIJOS="198.18.16.0/22 198.18.40.0/24"    # solo en clientes: lo que puede anunciarles

• Un rol sin vecino queda con sus valores vacíos, y su interfaz no existe. No todos los equipos tendrán los cinco.
• En el hackathon, un proveedor recibe en _PREFIJOS el bloque de su cliente y también los de los clientes de su cliente.
• frr.conf se monta de solo lectura. La forma natural es dejar en frr.conf lo que no cambia (los route-map, las comunidades, iBGP) y que r2/setup.sh y r4/setup.sh lean /as/vecinos.env y abran las sesiones. Corren con BusyBox sh, después de que el nodo tiene sus interfaces:

. /as/vecinos.env
if [ -n "$PROVEEDOR_A_VECINO" ]; then
    sh /as/vty.sh -c 'configure terminal' -c 'interface eth4' -c "ip address $PROVEEDOR_A_DIR" -c exit \
        -c 'router bgp 65017' -c "neighbor $PROVEEDOR_A_VECINO remote-as $PROVEEDOR_A_AS"
fi

Usen as/vty.sh, no vtysh directo. Cuando setup.sh corre, FRRouting todavía puede estar cargando frr.conf. Dos cargas a la vez terminan en could not lock running DS, a veces solo en una laptop lenta.

Hasta el hackathon no le cambien los valores: son los del mundo simulado.

Reglas que revisan las pruebas

Sesiones

• Todas las sesiones quedan en Established, solo en r2 y r4 hacia afuera, y el AS alcanza a todos los prefijos del mundo.
• Malla completa o reflector de rutas: cada router tiene sesiones iBGP, y todas arriba. Los cuatro aprenden el mundo por BGP, no por OSPF. Ningún router tiene ruta por defecto.
• El hold time de las sesiones eBGP es de 10 s o menos. Con el valor normal, un enlace que deja de pasar paquetes demoraría 3 minutos en notarse.
• Si cae un enlace del núcleo, el AS no pierde el mundo: iBGP no puede depender de un enlace en particular.

Lo que sale

• Cada vecino recibe su agregado, tal cual: ni direcciones privadas, ni otro largo, ni las direcciones de los enlaces.
• Un proveedor no recibe rutas aprendidas del otro proveedor ni del peer. El peer tampoco recibe las de los proveedores. Solo reciben las propias y las de clientes.
• Los clientes reciben todo y tienen tránsito: llegan a afuera, y desde afuera se llega a ellos.
• En r1, que solo oye iBGP, las rutas de clientes, peer y proveedores llegan con comunidades distintas.

Lo que se elige

• La local-preference va cliente, peer y proveedor, en los cuatro routers.
• Con la misma ruta disponible desde un cliente y desde un proveedor, gana el cliente, aunque su AS_PATH sea el más largo. Sin el cliente gana el peer; sin el peer, un proveedor.
• Se sale por A en los cuatro routers, aunque el camino por B sea más corto, y aunque r2 tenga a B al lado.

Lo que entra

• Si un cliente anuncia un prefijo ajeno, uno del otro cliente, o uno más específico que lo autorizado, no entra a su tabla.
• Si alguien anuncia sus prefijos propios, de cualquier largo, públicos o privados, no entran, venga de quien venga.

Fallas

• Si cae el proveedor A, el tráfico sale por B y vuelve a A cuando se recupera. Se corta de las dos formas de P1: bajando la interfaz y sin que las interfaces lo noten.
• Un host de afuera alcanza a su servidor de la DMZ durante todo eso, salvo una interrupción breve: menos de 20 s entre dos ping que llegan.

Borde

• La oficina llega a todos los vecinos y a afuera con una dirección de su bloque público, en TCP y UDP, con A arriba y con A caído. Ningún vecino ve un paquete con origen privado.
• Cada vecino le manda paquetes a la oficina, como ext en P1. A ningún host de la oficina le llegan, ni por r4 ni por r2.
• Desde cada vecino se alcanza la DMZ, sin traducir.

P1 sigue valiendo

• Las direcciones están en sus bloques, salvo las de los enlaces con vecinos. El plan menciona toda subred, incluidas las nuevas, salvo esas. Sigue OSPF en Full, dentro del AS no se traduce, e invitados no llega a personal.

Integración

• make test corre una segunda tanda: copia as/ y mundo/ a otra carpeta, con otras direcciones y otros AS en vecinos.env, otros prefijos para c1 y sin cliente 2. Las sesiones deben subir y todo debe seguir funcionando sin tocar nada más.

Hackathon de la semana 9

Traigan su carpeta as/. El docente la integra con la de los demás equipos en una sola topología. Para esto, su configuración no puede depender de nada fuera de as/, y sus vecinos reales se asignan el día del hackathon en as/vecinos.env.

En el hackathon, al otro lado de cada sesión hay otro equipo, y las sesiones suben solas al levantar la red, si su as/ lee bien el archivo. Dejen también timers connect bajo en cada sesión eBGP (por ejemplo, 5 s): por omisión, tras una caída, BGP puede demorar 2 minutos en volver a intentarlo.

Archivos

as/topo.clab.yml de P1 ya no se usa: esta entrega usa mundo/topo.clab.yml.

Cómo se corren las pruebas

Dentro del contenedor del curso (env/run.sh), desde esta carpeta:

make             # revisa la sintaxis, el número de equipo y que estén los archivos
make test        # corre las dos tandas, cada una con la red desde cero, y la destruye también si algo falla o con Ctrl+C
make clean       # destruye la red y borra lo generado

make test demora unos cuatro minutos. Las pruebas miran lo que pasa en la red, y no exigen una forma de hacer las cosas. Tienen márgenes amplios, y si una se queda esperando, falla sola. Agreguen sus pruebas en archivos test_*.py: corren en la primera tanda, con la red arriba.

La revisión corre además pruebas privadas con otros casos de falla y de tráfico.

Trabajar a mano

make topo-up                 # levanta su AS en el mundo con lo que hay en as/
make vtysh N=r4              # vtysh en r4; también sirve con N=pa, N=c1...
make sh N=h1                 # una shell en un nodo
make topo-down

Para ver lo que le llega a un vecino: make vtysh N=pa, y dentro, show bgp ipv4 unicast neighbors 100.64.71.2 received-routes.

Si una prueba falla

• La sesión queda en Active o Connect. Revisen show bgp neighbors. La dirección del enlace debe salir de vecinos.env, y el AS también. as/r4/setup.sh guarda su salida en /tmp/setup.log.
• could not lock running DS en la salida de setup.sh. Usen sh /as/vty.sh, no vtysh directo.
• r1 tiene la ruta en show bgp pero sin >, o no la instala. El next hop de iBGP debe ser alcanzable: next-hop-self, o los enlaces con vecinos en OSPF.
• Con A caído, se pierde todo por unos minutos. Revisen el hold time, que es lo único que nota un corte silencioso.
• Tras reparar A, el tráfico sigue por B demasiado. Es el tiempo entre intentos de abrir la sesión: revisen timers connect.
• Un proveedor recibe rutas de B o del peer. Lo que entró en otro router llega por iBGP: revisen que las comunidades se conserven y que el filtro de salida las mire.
• Corrigen una prefix-list a mano y no pasa nada. Lo ya recibido no se vuelve a evaluar: clear bgp ipv4 unicast <vecino> soft in.
• Con A caído, afuera ve una dirección privada, o nadie responde. Es el NAT: por r2 no se está traduciendo.
• Con NAT más adentro, una adyacencia de OSPF se cae o queda en Init, a veces sí y a veces no. Una regla de NAT con un origen muy amplio también traduce los Hello del propio router, si su dirección cae en ese rango. Traduzcan solo las subredes de la oficina.
• Funciona en la primera tanda y falla en la segunda. Algo de un vecino quedó escrito fuera de vecinos.env, o setup.sh toca una interfaz de un rol vacío.