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

P1R4#ping
Protocol [ip]:
Target IP address: 1.1.1.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]: y
Sweep min size [76]: 1498
Sweep max size [18024]: 1501
Sweep interval [1]:
Type escape sequence to abort.
Sending 4, [1498..1501]-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet has IP options:  Total option bytes= 39, padded length=40
Record route: <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)

Reply to request 0 (16 ms) (size 1498).  Received packet has options
Total option bytes= 40, padded length=40
Record route:
P1R4-F0.1 (10.1.3.4)
   P1R3-F0 (10.1.1.3)
   P1R1-L0 (1.1.1.1)
   P1R1-F0.0 (10.1.1.1)
   P1R3 (10.1.3.3)
   P1R4-F0.1 (10.1.3.4) <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list

Reply to request 1 (8 ms) (size 1499).  Received packet has options
Total option bytes= 40, padded length=40
Record route:
   P1R4-F0.0 (10.1.2.4)
   P1R2-F0.1 (10.1.0.2)
   P1R1-L0 (1.1.1.1)
   P1R1-F0.1 (10.1.0.1)
   P1R2-F0.0 (10.1.2.2)
   P1R4-F0.0 (10.1.2.4) <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list

Reply to request 2 (12 ms) (size 1500).  Received packet has options
Total option bytes= 40, padded length=40
Record route:
P1R4-F0.1 (10.1.3.4)
P1R3-F0 (10.1.1.3)
P1R1-L0 (1.1.1.1)
P1R1-F0.0 (10.1.1.1)
P1R3 (10.1.3.3)
P1R4-F0.1 (10.1.3.4) <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list

Request 3 timed out (size 1501)
Success rate is 75 percent (3/4), round-trip min/avg/max = 8/12/16 ms

Se puede ver en acción el balanceo de carga y además que el MTU de ambos paths es de 1500 bytes u octetos. Bajemos el MTU de los paquetes IP en la F0/1 de P1R2.

P1R2#conf t

Enter configuration commands, one per line.  End with CNTL/Z.
P1R2(config)#int f0/1
P1R2(config-if)#ip mtu 1498

Se realiza entonces la misma prueba (se elimina parte del output por simplicidad):

P1R4#ping
Protocol [ip]:
Target IP address: 1.1.1.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:

Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]: y
Sweep min size [76]: 1498
Sweep max size [18024]: 1501
Sweep interval [1]:
Type escape sequence to abort.
Sending 4, [1498..1501]-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Reply to request 0 (8 ms) (size 1498).  Received packet has options
Total option bytes= 40, padded length=40

Reply to request 1 (12 ms) (size 1499).  Received packet has options
Total option bytes= 40, padded length=40

Unreachable from 10.1.2.2, maximum MTU 1498 (size 1500).  Received packet has options
 Total option bytes= 39, padded length=40

Request 3 timed out (size 1501)
Success rate is 50 percent (2/4), round-trip min/avg/max = 8/10/12 ms

Notamos que sólo al tercer ping nos damos cuenta que en alguna parte está el camino restringido a paquetes IP de valor igual o menor a 1498 bytes. Esto por que el primer ping toma el path con restricción y cumple con las expectativas, el segundo con 1499 toma el camino alternativo y cumple con el MTU de 1500 y es recién el tercer paquete que nota la restricción al tomar el primer path.

Vamos a simplificar las cosas y forzaremos una única vía de comunicación. Para esto aumentaremos la métrica (hop count) de los anuncios respectivos de cada loopback a P1R3 y forzaremos como origen de los paquetes la loopback 0 de P1R4. De esta forma P1R2 será el next hop en ambos sentidos.

P1R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
P1R4(config)#access-list 1 permit 4.4.4.4
P1R4(config)#router rip
P1R4(config-router)#offset-list 1 out 14 fastEthernet 0/1

P1R1#conf t
Enter configuration commands, one per l
ine.  End with CNTL/Z.
P1R1(config)#access-list 1 permit 1.1.1.1
P1R1(config)#router rip
P1R1(config-router)#offset-list 1 out 14 FastEthernet 0/0

Veamos las tablas de ruteo de P1R1 y P1R4 para que podamos estar seguros que se eligirá un único camino:

P1R1#sh ip rou 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 10.1.0.2 on FastEthernet0/1, 00:00:24 ago
Routing Descriptor Blocks:
* 10.1.0.2, from 10.1.0.2, 00:00:24 ago, via FastEthernet0/1
Route metric is 2, traffic share count is 1

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.2.2 on FastEthernet0/0, 00:00:20 ago
Routing Descriptor Blocks:
* 10.1.2.2, from 10.1.2.2, 00:00:20 ago, via FastEthernet0/0
Route metric is 2, traffic share count is 1

Se prueba entonces con pings en el rango entre 1495 y 1501 (sin incluir el record esta vez).

P1R4#ping
Protocol [ip]:
Target IP address: 1.1.1.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 4.4.4.4
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1495
Sweep max size [18024]: 1501
Sweep interval [1]:
Type escape sequence to abort.
Sending 7, [1495..1501]-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!M
Success rate is 57 percent (4/7), round-trip min/avg/max = 4/5/8 ms

Unreachable from 10.1.2.2, maximum MTU 1498 (size 1499).  Received packet has options

Efectivamente hemos forzado el path y podemos notar que cualquier intento por pasar los 1498 bytes es advertido. Pero ¿qué pasaría si los caminos de ida y regreso no fuesen iguales, aunque fuesen únicos respectivamente?. OK, para estose cambia el offset generado en P1R1 de F0/0 a F0/1, con esto el camino de ida será por P1R3 (el camino de regreso se mantien intacto por P1R2).

P1R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
P1R1(config)#router rip
P1R1(config-router)#no offset-list 1 out 14 FastEthernet0/0
P1R1(config-router)#offset-list 1 out 14 FastEthernet0/1

Revisando las tablas de ruteo abajo se comprueba que nuestro cambio tuve el efecto deseado (cambió el next-hop para 1.1.1.1 en P1R 4)

P1R1#sh ip rou 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 10.1.0.2 on FastEthernet0/1, 00:00:14 ago
Routing Descriptor Blocks:
* 10.1.0.2, from 10.1.0.2, 00:00:14 ago, via FastEthernet0/1
Route metric is 2, traffic share count is 1

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:06 ago
Routing Descriptor Blocks:
* 10.1.3.3, from 10.1.3.3, 00:00:06 ago, via FastEthernet0/1
Route metric is 2, traffic share count is 1

Veamos qué sucede ahora con la misma prueba.

P1R4#ping
Protocol [ip]:
Target IP address: 1.1.1.1

Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 4.4.4.4
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1495
Sweep max size [18024]: 1501
Sweep interval [1]:
Type escape sequence to abort.
Sending 7, [1495..1501]-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!!.
Success rate is 85 percent (6/7), round-trip min/avg/max = 4/7/12 ms

Sólo falló el paquete de 1501 bytes!!!... ¿Por qué?, básicamente si se anliza el flujo circular de los paquetes notarán que las interfaces involucradas (interfaces salientes, quienes responden los pings) son: P1R4-F0/1-->P1R3-F0-->P1R1-F0/1-->P1R2-F0/0, por ende P1R2-F0/1 no aporta información, lo que puede atentar contra nuestra interpretación del funcionamiento de la red.


Para clarificar esto podemos modificar el MTU en cualquiera de las interfaces involucradas y podremos ver los resultados, por ejemplo P1R3-F0.

P1R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
P1R3(config)#int f0
P1R3(config-if)#ip mtu 1497

P1R4#ping
Protocol [ip]:
Target IP address: 1.1.1.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 4.4.4.4
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]: y
Sweep min size [76]: 1496
Sweep max size [18024]: 1501
Sweep interval [1]:
Type escape sequence to abort.
Sending 6, [1496..1501]-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet has IP options:  Total option bytes= 39, padded length=40
Record route: <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)

Reply to request 0 (8 ms) (size 1496).  Received packet has options
Total option bytes= 40, padded length=40
Record route:
P1R4-F0.1 (10.1.3.4)
P1R3-F0 (10.1.1.3)
P1R1-L0 (1.1.1.1)
P1R1-F0.1 (10.1.0.1)
P1R2 (10.1.2.2)
(4.4.4.4) <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list

Reply to request 1 (12 ms) (size 1497).  Received packet has options
Total option bytes= 40, padded length=40
Record route:
P1R4-F0.1 (10.1.3.4)
P1R3-F0 (10.1.1.3)
P1R1-L0 (1.1.1.1)
P1R1-F0.1 (10.1.0.1)
P1R2 (10.1.2.2)
(4.4.4.4) <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list

Unreachable from 10.1.3.3, maximum MTU 1497 (size 1498).  Received packet has options
Total option bytes= 39, padded length=40
Record route: <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
!!!Resto del output eliminado por simplicidad

*Apr  6 21:02:52.204: IP: s=4.4.4.4 (local), d=1.1.1.1 (FastEthernet0/1), len 1496, sending
*Apr  6 21:02:52.204:     ICMP type=8, code=0
*Apr  6 21:02:52.212: IP: s=1.1.1.1 (FastEthernet0/0), d=4.4.4.4, len 1496, rcvd 4
*Apr  6 21:02:52.212:     ICMP type=0, code=0
*Apr  6 21:02:52.220: IP: s=4.4.4.4 (local), d=1.1.1.1 (FastEthernet0/1), len 1497, sending
*Apr  6 21:02:52.220:     ICMP type=8, code=0
*Apr  6 21:02:52.228: IP: s=1.1.1.1 (FastEthernet0/0), d=4.4.4.4, len 1497, rcvd 4
*Apr  6 21:02:52.228:     ICMP type=0, code=0
*Apr  6 21:02:52.232: IP: s=4.4.4.4 (local), d=1.1.1.1 (FastEthernet0/1), len 1498, sending
*Apr  6 21:02:52.232:     ICMP type=8, code=0
*Apr  6 21:02:52.240: IP: s=10.1.3.3 (FastEthernet0/0), d=4.4.4.4, len 96, rcvd 4
*Apr  6 21:02:52.240:     ICMP type=3, code=4

Como se puede ver, para paquetes de tamaño igual o inferior a 1497 bytes recibimos de vuelta un mensaje ICMP type 0 code 0, sin embargo para el de 1498 un ICMP type 3 code 4 ("fragmentation needed and DF set").

En resumen, para cualquier verificación de MTU se debe tener claridad de cómo están siendo ruteados los paquetes en ambos sentidos. Nuevamente, estos ejemplos son méramente académicos. Para un método más prolijo, referirsea a: Path MTU Discovery (RFC 1191)