Re: bgp pmtud

From: Imran Ali <immrccie_at_gmail.com>
Date: Thu, 1 Nov 2012 20:48:24 +0300

thanks sundeep,

i was thinking from lab point of veiw where ibgp routers are multiple hops
away ...and thier tcp session can be re-routed via multiple paths primary
pos with MTU of 4470 and in case of POS failure via FE with 1500 bytes MTU.

the feature i got is Pmtud enabled by *defult*and in case when MSS is
higher than
any of underlying links..then update message is fragmented and sent.

 i am not sure of the affect of IP TCP PATH-mtu-discovery global config
command on bgp sessions?

On Thu, Nov 1, 2012 at 8:21 PM, sundeep sadhwani <sundeep.sadhwani_at_gmail.com
> wrote:

> Hi Imran,
>
> 1) DF bit is not set for the BGP update message.
>
> From my experience, You can see BGP flapping in case you have device in
> between like transmission devices or a switch working as a pure layer 2
> device which are dropping the packets if they dont support packet of 1500
> bytes). The MTU supported by the routers will be 1500 bytes so MSS would be
> 1460(Excluding 20 bytes IP and 20 bytes TCP)
>
> I had faced this issue for one of my customer. BGP neighbor was flapping
> every 3 minutes(Keepalives getting lost). After troubleshooting we found
> out that the keepalive messages were getting queued behind the BGP update
> messages(Considering BGP update message payload to be 1460 bytes.). We had
> to ping and check the MTU supported by the underlying devices. Then we
> manually adjusted the value of tcp mss using the global command on cisco
> router(The interface level didnt help as it wont affect locally originated
> traffic).
>
> 2) I am not sure about how path MTU discovery will work in this scenario
> as it will only come into picture when you have devices that understand IP
> in between the BGP neighbors. I am not sure what will happen if the
> transmission devices or layer 2 devices in between are dropping the packets
> of 1500 bytes silently(It means the IP router at the other is not receiving
> icmp packets hence there will not be any ICMP unreachable message generated
> from the IP router).
>
>
> Regards.
>
>
>
> On Thu, Nov 1, 2012 at 8:24 PM, Tom Kacprzynski <tom.kac_at_gmail.com> wrote:
>
>> I think this a very good question to be tested in GNS3 with wireshark.
>> Doing things you'll learn so much better than just reading about it.
>> Please
>> let us know what you find out.
>>
>> Regards,
>>
>> Tom
>>
>> On Thu, Nov 1, 2012 at 8:51 AM, Imran Ali <immrccie_at_gmail.com> wrote:
>>
>> > Hi all,
>> >
>> > By default when bgp router sends update ...does it sets DF bit ?
>> > question 1
>> >
>> > in this case if the size of update packet let say is larger than
>> > MTU of any of transit links ..then any transit router upon reception
>> of
>> > DF marked bgp update packet send an ICMP error , if icmp is filtered
>> due
>> > to any firewall then originating router will not reduce the MSS and
>> this
>> > results in oscilaitng bgp sessions
>> >
>> >
>> >
>> http://nagendrakumar-nagendra.blogspot.com/2010/03/bgp-path-mtu-discovery.html
>> >
>> > does any one have experinced the same or can comment on this ?
>> >
>> >
>> > 2) if bgp path mtu is enabled by default ..then do the router
>> undergo
>> > path mtu discovery ..and figures out lowest mtu of transit links and
>> then
>> > adjusts the [mss = lowes mtu - (ip headers) - (tcp headers) ] ..?
>> >
>> >
>> > Blogs and organic groups at http://www.ccie.net
>> >
>> > _______________________________________________________________________
>> > Subscription information may be found at:
>> > http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Thu Nov 01 2012 - 20:48:24 ART

This archive was generated by hypermail 2.2.0 : Sat Dec 01 2012 - 07:27:50 ART