[c-nsp] MTU / BGP

[Adam Vitkovsky]

Hi,

Once the session is up do you see all the routes being exchanged between the new MEs and old RRs?
How many routes do the new MEs receive/advertise from/to the old RRs? (just would like to rule out the max number of prefixes trigger for session reset)

Let's try "debug ip bgp x.x.x.x" on both ends.
To find out what each end thinks is the reason for the session reset.
 

adam
> -----Original Message-----
> From: CiscoNSP List [mailto:CiscoNSP_list at hotmail.com]
> Sent: 20 July 2015 09:43
> To: Adam Vitkovsky; Mark Tinka; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] MTU / BGP
> 
> 
> 
> 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/