[j-nsp] BGP MTU Mismatch

[Keegan Holley]

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 <alex.arseniev at gmail.com>

> 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" <ido at oasis-tech.net>
> To: "Keegan Holley" <keegan.holley at sungard.com>; "juniper-nsp" <
> juniper-nsp at puck.nether.net>
> 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 at puck.**nether.net<juniper-nsp-bounces at puck.nether.net>[mailto:
>> juniper-nsp-bounces@**puck.nether.net<juniper-nsp-bounces at puck.nether.net>]
>> 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 juniper-nsp at puck.nether.net
>> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>>
>> ______________________________**_________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>>
>>
> ______________________________**_________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>
>