[j-nsp] BGP MTU Mismatch

[Alex]

If no one replies back with ICMP Unreach type 3 code 4 with "Next-hop MTU" then yes
http://www.faqs.org/rfcs/rfc1191.html
Cheers
Alex
  ----- Original Message ----- 
  From: Keegan Holley 
  To: Alex 
  Cc: Ido Szargel ; juniper-nsp 
  Sent: Wednesday, June 22, 2011 3:27 PM
  Subject: Re: [j-nsp] BGP MTU Mismatch


  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 [mailto: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

      _______________________________________________
      juniper-nsp mailing list juniper-nsp at puck.nether.net
      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