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 <[email protected]
> 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 <[email protected]> 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 <[email protected]> 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
>>
>>
>>
>>
>>
>>
>>
>>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

http://onlinestudylist.com/mailman/listinfo/ccie_rs

Reply via email to