[c-nsp] MTU / BGP

Mon Jul 20 04:42:52 EDT 2015

Hi Adam/Mark - Unfortunately that command isnt available on the ME3600

I enabled:

debug ip bgp xxx.xxx.xxx.213 updates

debug ip bgp events

Results below...latency and jitter the cause?  (Strange, as I can send 5000 x 1500byte pings from ME->"old" ASR, and not get one loss, nor any huge fluctuations in latency?) - And I have a "stable" BGP session from the "new" RR's -> another PE, that is approx 20m/sec away?

i.e.

Success rate is 100 percent (5000/5000), round-trip min/avg/max = 28/32/76 ms

Ive been working on multiple things today, little sleep, so may be missing something completely obvious to some fresh eyes :)

.212 and .213 are the "old" RR's......203 is one of the "new" ME's

Jul 20 2015 18:22:06.391 GMTEST: %BGP-5-ADJCHANGE: neighbor xxx.xxx.xxx.212 Down BGP Notification sent

Jul 20 2015 18:22:06.391 GMTEST: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.xxx.212 VPNv6 Unicast topology base removed from session  BGP Notification sent

Jul 20 2015 18:22:06.391 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:1) Removed topology VPNv6 Unicast:base

Jul 20 2015 18:22:06.391 GMTEST: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.xxx.212 VPNv4 Unicast topology base removed from session  BGP Notification sent

Jul 20 2015 18:22:06.391 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:1) Removed topology VPNv4 Unicast:base

Jul 20 2015 18:22:06.391 GMTEST: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.xxx.212 IPv4 Unicast topology base removed from session  BGP Notification sent

Jul 20 2015 18:22:06.391 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:1) Removed topology IPv4 Unicast:base

Jul 20 2015 18:22:06.391 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:1) Removed last topology

Jul 20 2015 18:22:06.391 GMTEST: BGP: nbr global xxx.xxx.xxx.212 Open active delayed 9216ms (35000ms max, 60% jitter)

Jul 20 2015 18:22:06.391 GMTEST: BGP: nbr global xxx.xxx.xxx.212 Active open failed - open timer running

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive open to xxx.xxx.xxx.203

Jul 20 2015 18:22:12.811 GMTEST: BGP: Fetched peer xxx.xxx.xxx.212 from tcb

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive went from Idle to Connect

Jul 20 2015 18:22:12.811 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:0) pas Setting open delay timer to 60 seconds.

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive rcv message type 1, length (excl. header) 80

Jul 20 2015 18:22:12.811 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:0) pas Receive OPEN

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive rcv OPEN, version 4, holdtime 180 seconds

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive rcv OPEN w/ OPTION parameter len: 70

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has CAPABILITY code: 1, length 4

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has MP_EXT CAP for afi/safi: 2/128

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has CAPABILITY code: 1, length 4

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has MP_EXT CAP for afi/safi: 1/128

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has CAPABILITY code: 1, length 4

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has MP_EXT CAP for afi/safi: 1/1

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has CAPABILITY code: 128, length 0

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has ROUTE-REFRESH capability(old) for all address-families

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has CAPABILITY code: 2, length 0

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has ROUTE-REFRESH capability(new) for all address-families

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 16

Jul 20 2015 18:22:12.811 GMTEST: BGP: xxx.xxx.xxx.212 passive OPEN has CAPABILITY code: 64, length 14

Jul 20 2015 18:22:12.811 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:0) pas NSF OPEN has GR cap

Jul 20 2015 18:22:12.811 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:0) pas NSF Peer has not restarted. Restart Time: 120

Jul 20 2015 18:22:12.811 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:0) pas NSF Address family VPNv6 Unicast is NOT preserved

Jul 20 2015 18:22:12.811 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:0) pas NSF Address family VPNv6 Unicast is NOT SET for nbit

Jul 20 2015 18:22:12.811 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:0) pas NSF Address family VPNv4 Unicast is NOT preserved

Jul 20 2015 18:22:12.811 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:0) pas NSF Address family VPNv4 Unicast is NOT SET for nbit

Jul 20 2015 18:22:12.811 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:0) pas NSF Address family IPv4 Unicast is NOT preserved

Jul 20 2015 18:22:12.811 GMTEST: BGP: ses global xxx.xxx.xxx.212 (0xCBF3828:0) pas NSF Address family IPv4 Unicast is NOT SET for nbit

Cheers

________________________________________
From: Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
Sent: Monday, 20 July 2015 5:11 PM
To: CiscoNSP List; Mark Tinka; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] MTU / BGP

Hi,

Cmd: "ip tcp mss" affects TCP sessions only so BGP however also LDP sessions.

What does the log says is the reason for the session drop please?
If there's nothing obvious can you do "debug ip bgp x.x.x.x session" to see more details.

adam
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> CiscoNSP List
> Sent: 20 July 2015 08:02
> To: Mark Tinka; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] MTU / BGP
>
>
> Thanks Mark - I have existing OSPF/MPLS/BGP sessions running over the
> links (Apart from the "new" ME's to the "old" RR's) - Adjusting MTU on the
> new ME's(Only), will it break any of those existing sessions? (As OSPF is very
> particular about MTU)
>
>
> ________________________________________
> From: Mark Tinka <mark.tinka at seacom.mu>
> Sent: Monday, 20 July 2015 4:56 PM
> To: CiscoNSP List; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] MTU / BGP
>
> On 20/Jul/15 08:47, CiscoNSP List 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
> >
> >
> >
> > Datagrams (max data segment is 1940 bytes):
> >
> >
> >
> >
> > Any suggestions are greatly appreciated.
>
> If you think it is MTU, configure "ip tcp mss" to something like 1000
> and test again.
>
> Mark.
> _______________________________________________
> 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/