[c-nsp] MTU / BGP

[James Bensley]

On 20 July 2015 at 07:47, CiscoNSP List <CiscoNSP_list at hotmail.com> wrote:
> Hi Everyone,
>
>
>
> Have a new POP, 2 x ASR1000's (Acting as RR's), and 2 x ME3600's - We have another POP with 2 x ASR1000's also acting as RR's.
>
>
>
> The 2 "new" ME's are peered to the "new" ASR's RR's, but if I try to establish BGP  session with the existing RR's, session establishes, but then drops on both ME's after ~4minutes...I *think* it's due to MTU, and have tried disabling path mtu discovery, but it doesnt appear to do anything? (also tried it with it enabled, and the results are the same)
>
>
>
> i.e. no neighbour xxx.xxx.xxx.xxx transport path-mtu-discovery on the ME's, I see
>
>
>
> Datagrams (max data segment is 9036 bytes):
>
>
>
> On the ASR RR's I see
>
>
>
>
> Cheers.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


This should be easy to test for.

With the BGP sessions configured normally check the negotiated MSS
between the BGP peers, on the ME run:

device1#show bgp ipv4 uni neig 1.1.1.1 | i Datagram
Datagrams (max data segment is 1536 bytes):

Now on that ME configure:

router bgp 12345
 neighbor 1.1.1.1 transport path-mtu-discovery disable

Hard clear the TCP session then check again:

device1#show bgp ipv4 uni neig 1.1.1.1 | i Datagram
Datagrams (max data segment is 536 bytes)

If the BGP sessions is timing out with the lower MTU then its not the problem.

BGP normally uses the size of the egress interface towards the peer to
set the maximum segment size for the BGP sessions (less 40 bytes of
overhead for IP and TCP).

Cheers,
James.