[c-nsp] transport path-mtu-discovery - ME3600....too unpredictable to use?

[CiscoNSP List]

Cheers Dan (apologies for top post, on phone) - Ill check all Ints for no ip unreachables (I dont believe any have it configured)...We have some relatively unpredictable carriers that supply interpop links unfortunately, and no matter how many assurances they provide that circuit X will support MTU Y, and will not change....6 months down the track, someone fat fingers a transit device, and defaults MTU to 1500, and we are left with all sorts of fun and games with OSPF/MPLS/BGP...so unfortunately, we deal with each link individually, hope it doesnt change, and set MTU based on carriers provisioning docs....hence why I think that living with disabling PMTUD/default MSS is the "safest" option for us (At least for BGP :) )

Is having a much smaller segment size going to pose that much of an issue in a small network? we take 4-6 full tables, have a number of peering links, and also have 50-100 customer BGP sessions in VRF's predominantly

Side note - Im still a little uncertain "when/how often" PMTUD calculates, or re-calculates it values....If someone could point me to some docco that details it, that would be fantastic.

Thanks.


Hi,

Make sure that you don't have 'no ip unreachables' configured on any of
your core interfaces. This can screw up PMTUD as it relies on routers in
the path sending back 'ICMP type 3 Fragmentation Needed' packets to the
source when the egress interface MTU is too small to send the packet.

Having circuit MTU's that are smaller than defined interface MTU's will
also screw it up. Can you not set a consistent MTU across the network
that you know will be supported on every core circuit? If not, then I
think you will have to disable PMTUD and live with the default MSS.

Cheers,

Dan
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/