Siguiendo la línea del análisis del tamaño de los paquetes, pronto publicaremos los efectos en otros dos protocolos de ruteo:

1. Integrated ISIS (ISO/IEC 10589:2002), que si bien no un standandard del stack TCP/IP, la IEFT publicó el RFC 1142 (OSI IS-IS Intra-domain Routing Protocol) para la comunidad de Internet, como también el RFC 1195 (Use of OSI IS-IS for Routing in TCP/IP and Dual Environments). En relación a distintos valores de MTU veremos en acción los comandos: clns mtu y isis hello padding.

2. BGP (RFC 4271, deja obsoletos: 1771/1654). En particular intentaré reproducir un escenario donde las sesiones BGP flapean (suben y bajan repetidamente) en relación a distintos valores de MTU y el comando ip tcp path-mtu-discovery. Una referencia interesante es el RFC 2923 (TCP Problems with Path MTU Discovery)

Por ahora un sencillo ejemplo de la fragmentación en curso.

Enviamos dos pings con el bit de don't fragment (DF) seteado a 1, para dos tamaños de paquete desde un servidor a un router directamente conectado (Ethernet, MTU 1500 bytes):

1. 1472 bytes (+20 IP + 8 ICMP = 1500 bytes)

[root@server ~]# ping -Mdo -c2 -s1472 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 1472(1500) bytes of data.
1480 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.948 ms
1480 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=1.14 ms

--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.948/1.047/1.146/0.099 ms

Se revisa el detalle de los paquetes recibidos con tcpdump, filtrando aquellos de interes (ICMP).

[root@server folder]# tcpdump -v -nt icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 1500) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 59398, seq 1, length 1480
IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto: ICMP (1), length: 1500) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 59398, seq 1, length 1480
IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 1500) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 59398, seq 2, length 1480
IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto: ICMP (1), length: 1500) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 59398, seq 2, length 1480

2. 1473 bytes (+ 20 IP + 8 ICMP = 1501 bytes)

[root@server ~]# ping -Mdo -c2 -s1473 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 1473(1501) bytes of data.
From 10.0.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.0.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)

--- 10.0.0.1 ping statistics ---
0 packets transmitted, 0 received, +2 errors

Efectivamente los paquetes han sido dropeado. Veamos qué sucede en cambio si la fragmentación es permitida.

1. 1472 bytes (+ 20 IP + 8 ICMP = 1500 bytes)

[root@server ~]# ping -Mdont -c2 -s1472 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 1472(1500) bytes of data.
1480 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.850 ms
1480 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=1.13 ms

--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.850/0.994/1.138/0.144 m

El detalle.

[root@server folder]# tcpdump -v -nt icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
IP (tos 0x0, ttl  64, id 43460, offset 0, flags [none], proto: ICMP (1), length: 1500) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 62726, seq 1, length 1480
IP (tos 0x0, ttl 255, id 43460, offset 0, flags [none], proto: ICMP (1), length: 1500) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 62726, seq 1, length 1480
IP (tos 0x0, ttl  64, id 43461, offset 0, flags [none], proto: ICMP (1), length: 1500) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 62726, seq 2, length 1480
IP (tos 0x0, ttl 255, id 43461, offset 0, flags [none], proto: ICMP (1), length: 1500) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 62726, seq 2, length 1480

2. 1473 bytes (+ 20 IP + 8 ICMP = 1501 bytes)

[root@server ~]# ping -Mdont -c2 -s1473 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 1473(1501) bytes of data.
1481 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=1.36 ms
1481 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=1.07 ms

--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 1.076/1.218/1.360/0.142 ms

Se ve todo ok. El detalle revelará la fragmentación en curso

[root@server folder]# tcpdump -v -nt icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
IP (tos 0x0, ttl  64, id 43458, offset 0, flags [+], proto: ICMP (1), length: 1500) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 61702, seq 1, length 1480
IP (tos 0x0, ttl  64, id 43458, offset 1480, flags [none], proto: ICMP (1), length: 21) 10.0.0.2 > 10.0.0.1: icmp
IP (tos 0x0, ttl 255, id 43458, offset 0, flags [+], proto: ICMP (1), length: 1500) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 61702, seq 1, length 1480
IP (tos 0x0, ttl 255, id 43458, offset 1480, flags [none], proto: ICMP (1), length: 21) 10.0.0.1 > 10.0.0.2: icmp
IP (tos 0x0, ttl  64, id 43459, offset 0, flags [+], proto: ICMP (1), length: 1500) 10.0.0.2 > 10.0.0.1: ICMP echo request, id 61702, seq 2, length 1480
IP (tos 0x0, ttl  64, id 43459, offset 1480, flags [none], proto: ICMP (1), length: 21) 10.0.0.2 > 10.0.0.1: icmp
IP (tos 0x0, ttl 255, id 43459, offset 0, flags [+], proto: ICMP (1), length: 1500) 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 61702, seq 2, length 1480
IP (tos 0x0, ttl 255, id 43459, offset 1480, flags [none], proto: ICMP (1), length: 21) 10.0.0.1 > 10.0.0.2: icmp

Efectivamente cada ping ha sido particionado en 2. El primer fragmento tiene payload de 1480, compuesto por el encabezado ICMP (8 bytes) + los primero 1472 bytes de nuestro ping. El siguiente fragmento tan sólo aportará con el byte restante. Entonces hemos enviado los 1473 bytes que le indicamos al ping, más el encabezado ICMP + dos veces el encabezado IP por cada ping (20 bytes), por lo que si bien la fragmentación puede ser útil, hay que considerar que no sólo consume CPU si no también ancho de banda (bandwidth).