Continuando con la senda del valor de MTU, un protocolo que nos indica este valor en un camino es EIGRP (protocolo propietario de Cisco, por ende no existe RFC asociado).


Seteamos eigrp en el AS 1 (Sistema autónnomo 1) compuesto por P1R1, P1R2 Y P1R4. Si sólo se modifica la MTU para los paquetes IP en la interface FastEthernet0/0 de P1R2 a 1498 bytes, en P1R1 la loopback del P1R4 se verá como sigue.

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.

Bueno, del post anterior queda la inquietud de para qué preocuparse de las diferencias de MTU si el protocolo IP permite la fragmentación, cierto?. Bueno, a continuación veremos un ejemplo donde se manifiesta en una sencilla configuración de OSPFv2 (RFC 2328, deja obsoletos: 2178/1583/1247/1131). Más adelante mostraremos un ejemplo de pings fragmentados.

Aprovechando la topología anterior configuramos OSPF en P1R1 y P1R2.

P1R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
P1R1(config)#router ospf 1
P1R1(config-router)#network 10.0.0.0 0.255.255.255 area 0

Una forma de determinar el MTU en un path es a través del envío de pings (ICMP Echo Requests) de diferentes tamaños, sin embargo se debe considerar las múltiples rutas para llegar a destino como la posible asimetría de regreso.

Observemos la red del post anterior (Traceroute vs Tracert) y veamos qué sucede al enviar pings de diferentes tamaños entre P1R1 y P1R4 (con el bit de don't fragment, DF, en 1). Notar que nuestra tabla de ruteo (se configuró RIPv2, RFC 2453 que deja obsoletos 1723/1388/1058) nos indica dos diferentes caminos (balanceo de carga).

P1R4#sh ip rou 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 10.1.3.3 on FastEthernet0/1, 00:00:10 ago
Routing Descriptor Blocks:
* 10.1.3.3, from 10.1.3.3, 00:00:10 ago, via FastEthernet0/1
Route metric is 2, traffic share count is 1
10.1.2.2, from 10.1.2.2, 00:00:18 ago, via FastEthernet0/0
Route metric is 2, traffic share count is 1