Re: best practice for advertising peering fabric routes

[Leo Bicknell <bicknell () ufp org>]

On Jan 15, 2014, at 9:37 AM, "Dobbins, Roland" <rdobbins () arbor net> wrote:

> But what I'm saying is that that whether or not they want to use jumbo frames for Internet traffic, it doesn't 
> matter, because PMTU-D is likely to be broken either at the place where the traffic is initiated, the place where the 
> traffic is received, or both - so any nonsense in the middle, especially on IXP networks in particular, isn't really 
> a significant issue in and of itself.

Your assertion does not match my deployment experience.

When I have deployed endpoints that have working PMTU-D, I have 99.999% success with the ISP's in the middle having 
working PMTU-D.  It even works fine for 9K providers connected to 1500B exchange points, because the packet-too-big 
typically originates from the input side of the router (the backbone link to the IXP router).  Indeed, the only place 
I've seen it broken is where the ISP 9K peers at an exchange, and the "far end" ISP runs a < 9K backbone (like 4470), 
so the far end IXP-router does the packet-to-big, and originates it from the exchange LAN, which because it's no longer 
in the table fails to past uRPF.

(Business class) ISP's don't break PMTU-D, end users break it with the equipment they connect.  So a smart user 
connecting equipment that is properly configured should be able to expect it to work properly.

-- 
       Leo Bicknell - bicknell () ufp org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail