I don't think this is correct. PMTU discovery uses probes with the DF bit set, the largest one to make it end to end is assumed to be the MTU.
http://en.wikipedia.org/wiki/Path_MTU_Discovery 2011/6/22 Alex <[email protected]> > PMTU relies on someone in the path telling you what the MTU is. > And there is no way to check if this someone is telling the truth :-( > I saw this in complex environments such as BGP over GRE over IPSec tunnel. > In this case, the sp-* interface carrying GRE tunnel has to have > mtu-discovery itself enabled. > Otherwise it will assume 9192 bytes. > Cheers > Alex > > > ----- Original Message ----- From: "Ido Szargel" <[email protected]> > To: "Keegan Holley" <[email protected]>; "juniper-nsp" < > [email protected]> > Sent: Wednesday, June 22, 2011 9:50 AM > Subject: Re: [j-nsp] BGP MTU Mismatch > > > > Hi Keegan, >> >> What is most likely to happen is that the session established since those >> are small packets, then the routers try to send the route messages which are >> large in case you are sharing full routing table, those messages do not >> arrive to the other side because of the MTU mismatch, thus causing the >> keepalive messages to be delayed as well, then when the dead interval kicks >> in the session flaps. >> PMTU under the BGP group/neighbor should normally be enough to solve it. >> >> Regards, >> Ido. >> >> -----Original Message----- >> From: >> juniper-nsp-bounces@puck.**nether.net<[email protected]>[mailto: >> juniper-nsp-bounces@**puck.nether.net<[email protected]>] >> On Behalf Of Keegan Holley >> Sent: Wednesday, June 22, 2011 11:38 AM >> To: juniper-nsp >> Subject: [j-nsp] BGP MTU Mismatch >> >> Does anyone know why a BGP session would constantly flap because of an MTU >> mismatch. I'm sure it's MTU since that is what fixed the problem. The >> peering is between a cisco and a juniper and both support PMTU discovery. I >> would assume any mismatches would be settled by the TCP MSS negotiation or >> fragmentation (admittedly bad). The peering flapped almost every three >> minutes on the mark so it never made it past the first dead timer interval. >> Just curious if someone out there had ever gotten to the bottom of this >> problem. >> ______________________________**_________________ >> juniper-nsp mailing list [email protected] >> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp> >> >> ______________________________**_________________ >> juniper-nsp mailing list [email protected] >> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp> >> >> > ______________________________**_________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp> > > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
