Parcial de práctica — Computación Centrada en Redes

Temas: partes 1 a 3 del curso (semanas 1 a 7) · Duración: 2 horas

Este es un examen de práctica con el formato del parcial. Sirve para medir cuánto tiempo les toma cada tipo de pregunta: resuélvanlo de una sola vez y con el reloj corriendo. El formato general está en exams/README.md.

Indicaciones

• Muestren el procedimiento y justifiquen cada resultado.
• 1 Mbps son 10⁶ bits por segundo, y 1 byte son 8 bits. Salvo que la pregunta diga otra cosa, la velocidad de propagación es 2×10⁸ m/s.
• Las salidas de la parte E y la de la pregunta 15 son de ejecuciones reales en topologías de Containerlab. Los tiempos dependen de la máquina. Los recortes están indicados.
• Las partes C, D y E usan la misma red, la de la figura de la parte C.

Parte A — Cálculos

Pregunta 1 — Retardo y throughput

Un host A envía paquetes de 1500 bytes a un host B, a través de un router R que trabaja con store-and-forward:

    A ───────────────── R ───────────────── B
       20 Mbps, 400 km     5 Mbps, 3000 km

No hay otro tráfico. Ignoren el retardo de procesamiento y los encabezados.

a) ¿Cuánto tarda un solo paquete, desde que A empieza a transmitirlo hasta que llega completo a B? Separen los cuatro términos.

b) A envía 2000 paquetes seguidos, a toda la velocidad de su enlace, y el buffer de R es lo bastante grande para no perder ninguno. ¿En qué instante termina de llegar el último? ¿Dónde se forma la cola? ¿Qué throughput promedio ve B, y a qué valor tiende si el archivo crece?

c) Ahora A envía a un ritmo constante de 450 paquetes por segundo, y el buffer de salida de R tiene lugar para 100 paquetes. Calculen la intensidad de tráfico ρ de la cola de salida de R. En régimen permanente, ¿qué fracción de los paquetes se pierde? ¿Cuál es, aproximadamente, el retardo de cola de los que pasan?

d) Un servidor con 1 Gbps de subida le envía a un cliente con 200 Mbps de bajada, por un enlace troncal de 10 Gbps que comparten n flujos iguales. ¿Cuál es el throughput de un flujo con n = 40? ¿Y con n = 80? ¿Dónde está el cuello de botella en cada caso?

Pregunta 2 — CRC

Datos D = 10110011, generador G = 10011.

a) Calculen el CRC por división módulo 2, mostrando cada paso, y escriban la cadena que se transmite.

b) El receptor recibe por separado estas dos cadenas. Para cada una, calculen el residuo, digan cuántos bits cambiaron respecto de lo transmitido y si el error se detecta:

• R1 = 101111010100
• R2 = 101110101100

Con esa evidencia, ¿tiene G a x + 1 como factor? ¿Qué ráfagas detecta siempre este CRC?

c) Un router con una falla de memoria daña un paquete mientras lo copia del puerto de entrada al de salida. ¿Lo detecta el CRC del enlace siguiente? ¿Quién podría detectarlo? Relaciónenlo con el argumento end-to-end.

Pregunta 3 — Subredes con CIDR

Una facultad recibió 10.212.64.0/22 y necesita, en este orden de tamaño, una LAN de 300 hosts, una de 110, una de 50 y dos enlaces entre routers. Las cantidades ya incluyen la interfaz del router.

a) Asignen los bloques de mayor a menor, empezando por la primera dirección del bloque. Para cada uno, den el prefijo, el rango de direcciones y cuántos hosts útiles admite. Los enlaces no usan /31. ¿Cuál es la primera dirección que queda libre?

b) Para la LAN de 110 hosts, den la máscara en decimal y la dirección de broadcast. ¿Por qué 10.212.66.70/25 no nombra una subred?

c) ¿Se pueden resumir 10.212.65.0/24 y 10.212.66.0/24 en un solo prefijo sin incluir otras direcciones? ¿Y 10.212.66.128/26 y 10.212.66.192/26? Si se puede, escriban el resumen.

Pregunta 4 — Longest prefix match

La forwarding table de un router es esta:

a) ¿Por dónde sale cada dirección? Muestren en binario el byte que decide en al menos dos de los casos.

10.212.70.200, 10.212.70.201, 10.212.70.12, 10.212.72.1, 10.212.200.9, 10.213.0.1

b) Se retira la ruta de D. ¿Qué cambia? ¿Hay que reordenar la tabla para que el resultado sea correcto? Si dos protocolos ofrecen rutas al mismo prefijo 10.212.68.0/22, ¿longest prefix match elige entre ellas?

Parte B — Algoritmos a mano

Pregunta 5 — Dijkstra

La red tiene seis routers, y los costos son iguales en los dos sentidos:

        g ──2── h ──6── k ──6── n
         \      │      /│      /
        4 \   2 │   3 / │ 1   / 2
           \    │    /  │    /
            \   │   /   │   /
              ─ j ──7── m ─

Los enlaces son: g-h 2, g-j 4, h-j 2, h-k 6, j-k 3, j-m 7, k-m 1, k-n 6 y m-n 2.

a) Corran Dijkstra desde g. Escriban una tabla con una fila por paso, con N’ y D(v),p(v) para cada nodo. Si dos caminos empatan, anoten los dos predecesores.

b) Escriban la forwarding table de g: destino, costo y next hop. Expliquen qué significa que una entrada tenga dos next hop, y cómo se reparte el tráfico entre ellos.

c) Se cae el enlace j-k. Sin rehacer toda la tabla, justifiquen los nuevos costos y next hop de g hacia k, m y n. ¿Le basta a g con saber que cayó ese enlace, o todos los routers tienen que recalcular?

Pregunta 6 — Vector de distancias

Usen el modelo de dv_sim de los apuntes: en cada ronda todos anuncian a la vez, cada uno con la tabla que tenía al empezar la ronda. Lo que dice el next hop actual se acepta siempre, aunque sea peor. Lo que dice otro vecino se acepta solo si mejora estrictamente lo que se tiene.

a) La red tiene los enlaces e-f 1, f-g 2, g-h 3, e-g 7 y f-h 8. Escriban la tabla de la ronda 0, en la que cada router conoce solo a sus vecinos, y las de las rondas siguientes, hasta que deje de cambiar. Cada celda es costo/next hop. ¿En cuántas rondas converge?

b) Otro triángulo tiene los enlaces t-u 3, u-v 2 y t-v 40, y la red ya convergió. Miren solo el destino t. El enlace t-u sube de 3 a 15. Escriban u y v, ronda por ronda, hasta que deje de cambiar, y marquen las rondas en las que hay un ciclo. ¿Con qué valores termina?

c) Repitan (b) con poison reverse. ¿Cuántas rondas toma? ¿Por qué esa técnica no alcanza en general, y qué agrega BGP para resolverlo?

Parte C — Seguir un paquete

Esta es la red de las partes C, D y E. Cada router es un sistema autónomo distinto.

                t1 (65410) ========== t2 (65420)        ===== peers
                 /      \              /      \         │     arriba el proveedor,
                /        \            /        \        │     abajo el cliente
               /          \          /          \
       m1 (65431)          m3 (65433)        m2 (65432)
         │ ║                   │                 ║ │
         │ ╚═══════════════════╪═════════════════╝ │     m1 y m2 también son peers
         │                     │                   │
         └───── s1 (65441) ────┘                s2 (65442)
                    │                               │
                    │ eth1, trunk (30 y 40)         │  100.64.242.0/25
                   sw2                             web  100.64.242.80:8080
                    ║ trunk (30 y 40)
                   sw1
                  /   \
                 h1    h2

Proveedor → cliente: t1 → m1, t1 → m3, t2 → m3, t2 → m2, m1 → s1, m3 → s1, m2 → s2. Peers: t1–t2 y m1–m2.

Cada AS tiene el prefijo que sale en esta tabla. s1 traduce con NAT lo que sale de 10.212.0.0/16 por sus enlaces a m1 y m3, con origen 100.64.241.1. No traduce lo que va de una VLAN a la otra.

Pregunta 7

a) Todas las tablas ARP están vacías, y los switches ya conocen a todos. h1 hace un ping de 56 bytes de datos a h2. Llenen una fila por cada tramo que recorre el echo request:

¿Qué consultas ARP aparecen antes de que el echo request llegue a h2? ¿Por quién pregunta h1, y por qué no por h2? ¿Hace h2 una consulta ARP para contestar?

b) h1 abre una conexión TCP desde su puerto 40000 hacia 100.64.242.80:8080. Enseguida, y con la primera aún en la tabla, h2 abre otra desde su propio puerto 40000 hacia el mismo destino. s1 saca las dos por m1, y el camino sigue por m2 y s2.

• Escriban la tabla de traducción de s1: adentro, afuera y destino. Si un puerto se tiene que cambiar, llámenlo p.
• Para el SYN de h1, digan cómo cambian en cada router, hasta web: el TTL, la IP de origen, el puerto de origen, el checksum del encabezado IP, el checksum de TCP y el número de secuencia.
• ¿Qué IP y qué puerto ve web en las dos conexiones? ¿Cómo decide s1 a quién entregar la respuesta de la segunda?

c) Desde web, que no tiene ninguna conexión abierta con h1, se intenta http://100.64.241.1:8080/ y http://10.212.30.7:8080/, y h1 sí tiene un servidor en ese puerto. Las dos fallan. Para cada una, ¿hasta dónde llega el SYN, y qué responde quién? ¿Protege el NAT a h1 como lo haría un firewall?

Parte D — Políticas de BGP

Pregunta 8

Todos los AS de la figura siguen las reglas de los apuntes. Importación: prefieren la ruta de un cliente, luego la de un peer y luego la de un proveedor, y a igualdad de preferencia, el AS_PATH más corto. Exportación: las rutas propias y de clientes van a todos; las de peers y proveedores, solo a clientes.

a) ¿Qué prefijos le anuncia m1 a t1? ¿Y a m2? ¿Y a s1? (A s1 no le cuenten su propio prefijo.) Justifiquen cada caso con una regla.

b) Para el prefijo de s2, 100.64.242.0/24, digan qué AS_PATH elige cada uno de estos AS, qué otras rutas conoce y qué criterio decide: t2, t1, m3 y s1.

c) ¿Cuáles de estos caminos de AS son valle-libres? Justifiquen los que no lo son.

1. s1 m3 t2 m2 s2
2. s2 m2 m1 s1
3. t1 m1 m2 t2
4. m3 s1 m1
5. m1 m2 t2 t1

d) s1 quiere que el tráfico hacia su prefijo le llegue por m1 y no por m3. Para eso repite su número al anunciarle a m3, de modo que m3 recibe 65441 65441 65441 (AS path prepending). ¿Qué camino elige t1 hacia 100.64.241.0/24? ¿Y t2? ¿Cuál de los dos obedece al alargue, y cuál no, y por qué? ¿Qué le dice eso a s1 sobre esta técnica?

e) s1 pierde su política de salida hacia m3, y le anuncia todo lo que tiene, incluida su ruta 65431 65432 65442 hacia el prefijo de s2. ¿Qué camino eligen ahora hacia ese prefijo m3, t1 y t2? ¿Por qué m3 acepta esa ruta y la prefiere? ¿Cómo se llama este problema? ¿Lo habría detenido RPKI? ¿Quién lo podría cortar con un filtro?

Parte E — Leer salidas reales

Pregunta 9 — show bgp

Tabla de m1 en la red de la figura, con las políticas de la pregunta 8 y sin el prepending. Se omiten la leyenda y las líneas de encabezado.

$ docker exec clab-xp-parcial-m1 vtysh -c 'show bgp ipv4 unicast'
     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.64.210.0/24  100.64.210.133           0    100      0 65410 i
 *>  100.64.220.0/24  100.64.210.133                100      0 65410 65420 i
 *>  100.64.231.0/24  0.0.0.0                  0         32768 i
 *>  100.64.232.0/24  100.64.231.130           0    200      0 65432 i
 *                    100.64.210.133                100      0 65410 65420 65432 i
 *>  100.64.233.0/24  100.64.210.133                100      0 65410 65433 i
 *>  100.64.241.0/24  100.64.231.134           0    300      0 65441 i
 *>  100.64.242.0/24  100.64.231.130                200      0 65432 65442 i
 *                    100.64.210.133                100      0 65410 65420 65432 65442 i

Displayed 7 routes and 9 total paths

a) Sin mirar la figura, ¿qué relación tiene m1 con cada uno de sus tres vecinos? ¿De qué columna lo sacan, y por qué esa columna sí se puede comparar dentro del AS?

b) ¿Por qué ganó la primera ruta hacia 100.64.242.0/24? Si la ruta por t1 fuera más corta que la otra, ¿cambiaría el resultado?

c) ¿Por qué la columna Metric trae un 0 en 65410 i y está vacía en 65410 65420 i? ¿Qué significa 32768?

d) m2 conoce 100.64.220.0/24, porque es el prefijo de su proveedor. ¿Por qué m1 no tiene una ruta hacia ese prefijo por m2, que sería igual de larga?

Pregunta 10 — traceroute

Desde h1, durante una corrida en la que uno de los enlaces emula un cable largo (el retardo se emuló con tc netem):

$ docker exec clab-xp-parcial-h1 traceroute -n -w 1 100.64.242.80
traceroute to 100.64.242.80 (100.64.242.80), 30 hops max, 46 byte packets
 1  10.212.30.1  0.004 ms  0.003 ms  0.003 ms
 2  100.64.231.133  0.001 ms  0.001 ms  0.002 ms
 3  100.64.231.130  42.190 ms  42.063 ms  42.014 ms
 4  *  *  *
 5  100.64.242.80  43.570 ms  42.339 ms  46.081 ms

a) ¿A qué nodo de la figura corresponde cada salto? (Los next hop de la tabla de la pregunta 9 ayudan.) ¿Por qué no aparecen sw1 y sw2?

b) ¿Qué significa el salto 4? ¿Se perdieron esos paquetes? ¿Cómo lo saben?

c) ¿En qué enlace está el retardo, y por qué lo creen real y no un router lento para contestar? Con s = 2×10⁸ m/s, ¿cuál es la distancia máxima que puede tener ese enlace?

d) traceroute se basa en el TTL. Si h1 está detrás de un NAT, ¿qué dirección de origen trae la sonda al llegar a m1, y a qué dirección le contesta m1 con su Time exceeded? ¿Qué lleva ese mensaje que le permite a s1 saber que es para h1? ¿Esta traza dice algo sobre el camino de vuelta?

Pregunta 11 — Una captura

El SYN de h1 de la pregunta 7(b), capturado en el trunk, en sw1:

$ tcpdump -t -e -n -xx -c 1 -r trunk.pcap 'vlan and tcp[tcpflags] == tcp-syn'
02:00:00:00:30:07 > 02:00:00:00:00:fe, ethertype 802.1Q (0x8100), length 78: vlan 30, p 0, ethertype IPv4 (0x0800), 10.212.30.7.40000 > 100.64.242.80.8080: Flags [S], seq 4266241682, win 64240, options [mss 1460,sackOK,TS val 4100817467 ecr 0,nop,wscale 7], length 0
	0x0000:  0200 0000 00fe 0200 0000 3007 8100 001e
	0x0010:  0800 4500 003c cac0 4000 4006 f08f 0ad4
	0x0020:  1e07 6440 f250 9c40 1f90 fe49 ae92 0000
	0x0030:  0000 a002 faf0 ee4c 0000 0204 05b4 0402
	0x0040:  080a f46d 823b 0000 0000 0103 0307

Y el mismo paquete con tcpdump -t -e -n -v, en otros dos puntos (s1 hacia m1, y web):

[s1 eth2]
aa:c1:ab:05:77:30 > aa:c1:ab:03:05:29, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 63, id 51904, offset 0, flags [DF], proto TCP (6), length 60)
    100.64.241.1.40000 > 100.64.242.80.8080: Flags [S], cksum 0xc1e5 (correct), seq 4266241682, win 64240, options [mss 1460,sackOK,TS val 4100817467 ecr 0,nop,wscale 7], length 0
[web eth1]
02:00:00:00:24:01 > 02:00:00:00:24:80, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 60, id 51904, offset 0, flags [DF], proto TCP (6), length 60)
    100.64.241.1.40000 > 100.64.242.80.8080: Flags [S], cksum 0xc1e5 (correct), seq 4266241682, win 64240, options [mss 1460,sackOK,TS val 4100817467 ecr 0,nop,wscale 7], length 0

a) Solo con los bytes en hexadecimal, y diciendo en qué posición está cada campo: el VID, el EtherType que sigue a la etiqueta, el largo total del datagrama, el TTL, el protocolo, las dos direcciones IP, los dos puertos y el largo del encabezado TCP.

b) Comprueben a mano el checksum del encabezado IP: sumen sus diez palabras de 16 bits, con el acarreo circular, y digan qué debe dar.

c) Sumen los encabezados y expliquen el length 78 y el length 74. ¿Cuánto mediría cada frame en un cable real, con el FCS?

d) ¿Cuántos routers cruzó el paquete hasta web, y cómo se sabe solo con esta salida? ¿Por qué cambia cksum entre el trunk y s1 eth2, y no entre s1 eth2 y web, aunque el TTL sí cambió?

Parte F — Preguntas cortas

Respondan cada una en tres o cuatro líneas.

Pregunta 12

Un cliente TCP hace tres send seguidos de 200 bytes cada uno. El servidor llama a recv(fd, buf, 1024, 0) en un bucle. ¿Cuántos bytes puede devolver la primera llamada? ¿Qué debe agregar el protocolo de la aplicación para saber dónde termina cada mensaje? ¿Qué cambia si el cliente manda tres datagramas UDP? ¿Sobre cuál socket hace recv el servidor TCP, y de dónde salió?

Pregunta 13

Tres switches forman un triángulo, con STP y todos los enlaces del mismo costo. Las prioridades son: sw-a 12288, sw-b 8192 y sw-c 4096. ¿Cuál es la raíz? ¿Qué puerto se bloquea, y por qué? Si se corta el enlace sw-b–sw-c sin que sw-a lo note, ¿cuánto tarda en volver el tráfico entre sw-a y sw-b, con los temporizadores por defecto? En un ciclo de routers, en cambio, un paquete no da vueltas para siempre. ¿Qué campo lo evita?

Pregunta 14

Un datagrama IPv4 de 1500 bytes en total (20 de encabezado) y sin DF llega a un enlace con MTU 620. Escriban, para cada fragmento, el largo total, el valor del campo offset y el bit MF. ¿Qué pasa si trae DF? ¿Qué hace un router IPv6 con un paquete que no cabe? ¿Qué campo de IPv4 no existe en IPv6, y por eso no hay que rehacerlo en cada salto?

Pregunta 15

Esta es parte de la tabla de un router, tomada de la semana 5 (se quitaron líneas):

$ docker exec clab-w05-six-a vtysh -c 'show ip route ospf'
O>* 10.205.0.2/32 [110/3] via 10.205.12.2, eth1, weight 1, 00:00:02
O>* 10.205.0.5/32 [110/6] via 10.205.12.2, eth1, weight 1, 00:00:02
  *                       via 10.205.13.2, eth2, weight 1, 00:00:02
O   10.205.12.0/30 [110/3] is directly connected, eth1, weight 1, 00:00:22

¿Qué significan el 110 y el 6? ¿Por qué 10.205.0.5/32 tiene dos líneas, y por qué ese reparto se hace por flujo y no por paquete? ¿Por qué 10.205.12.0/30 no lleva >*? Si el enlace por eth1 deja de pasar tráfico sin que la interfaz se caiga, con Hello de 10 s y Dead de 40 s, ¿entre cuántos segundos se detecta?

Pregunta 16

El único VRP publicado para esta zona es 100.64.250.0/23, largo máximo 24, AS 65450. Clasifiquen cada anuncio como valid, invalid o not found:

El AS 65460 es un atacante. ¿Qué tiene de engañosa la última fila? En una red sin validación de origen, ¿por qué un /25 originado por 65460 atraería el tráfico de todos los que lo acepten, aunque la ruta legítima hacia el /24 tenga un AS_PATH más corto?