[j-nsp] path-mtu-discovery

Bit Gossip bit.gossip at chello.nl
Fri Oct 9 04:45:51 EDT 2009


Harry, Experts,
that makes a lot of sense: mss is an indirect indication of the mtu
But what about non TCP traffic, ICMP for example, 'path-mtu-discovery'
doesn't seem to work.

Following setup shows that when jr4 pings with a packet bigger than the
MTU of the router in the middle and with the 'do-not-fragment' it
receives from the router the 'ICMP unreachabel - packet too big'

At this point it should learn the mtu=1500 for the path to the host and
if I do a ping to the host with same big packet but not
'do-not-fragment' it should fragment the packet.
It doesn't seem to do it.
Thanks,
bit.


jr4 - ge-1/3/0 ip=192.168.34.4 - mtu 1600
router - mtu 1500
host - ip=192.168.23.2 -  mtu 1500

lab at jr4> show configuration system internet-options 
path-mtu-discovery;

lab at jr4> ping source 192.168.34.4 192.168.23.2 do-not-fragment count 1
size 1473
PING 192.168.23.2 (192.168.23.2): 1473 data bytes
36 bytes from 192.168.34.3: frag needed and DF set (MTU 1500)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 05dd 7225   2 0000  3f  01 09a4 192.168.34.4  192.168.23.2


--- 192.168.23.2 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

lab at jr4> ping source 192.168.34.4 192.168.23.2 count 1 size
1473                    
PING 192.168.23.2 (192.168.23.2): 1473 data bytes



On Thu, 2009-10-08 at 09:40 -0700, Harry Reynolds wrote:
> You are correct. Its called mss (max segment size) in the show system connections, and it does not include tcp/ip OH. Note that we have some tcp noop and time-stamp options, so the tcp header tends to be > 20 bytes.
> 
> When pmtu is off you tend to see a mss of ~ 530 for off net, else it's the smallest value discovered in that direction. IIRC, bgp pmtu is off by default and has to be enabled. The default internet PMTU (internet-options path-mtu-discovery) is enabled by default. Docs indicated otherwise, and doc pr 75430 was opened to get that corrected.
> 
> Also, once we discover a reduced pmtu we do not ramp back up. The connection has to be cleared for ~7 minutes to completely age out previous pmtu state, and then we can discover a larger pmtu if things have changed.
> 
> 
> HTHs
> 
>  
> 
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Bit Gossip
> Sent: Thursday, October 08, 2009 5:08 AM
> To: juniper-nsp
> Subject: [j-nsp] path-mtu-discovery
> 
> Experts,
> I guess that the effect of this command is to maintain a cache of all the active connection and for each of them assign the discovered value of the max mtu allowed accross the path.
> At least the output of 'show system connections inet extensive'
> doesn't show any trace of PMTU;
> Anyidea of where I can find this information?
> 
> BTW: on a linux box I found that with the command:
> 'ip route show table cache'
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list