http://cisco.cluepon.net/index.php/Using_capture_buffer_with_ELAM http://cisco.cluepon.net/index.php/6500_SPAN_the_RP
Oh you guys are going to love this...Before I could send out the
Well even the IBGP session came up on its own now and has been up for 1 day and 1 hour, I can honestly say this is bizarre situation. I will use the above links if something like this or weird happens. Thank you all. -----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Thursday, September 17, 2009 1:11 PM To: Michael Ruiz Cc: Brian Dickson; nanog@nanog.org Subject: Re: <Keepalives are temporarily in throttle due to closed TCP window> On Thu, Sep 17, 2009 at 09:17:00AM -0500, Michael Ruiz wrote: maintenance notification for tonight to make changes, The session has been up for 21 hours. This is before I could put a packet capture server on the segment. <Sigh>
<SNIP> BGP state = Established, up for 21:29:25 Last read 00:00:24, last write 00:00:02, hold time is 180, keepalive
interval is 60 seconds
Neighbor capabilities:
You don't need to use an external sniffer, you can use "debug ip packet" to see traffic being punted to the control plane, or in the case of the 6500 you can use ELAM or ERSPAN (though this is probably a little bit on the advanced side). If this was an MTU mismatch a sniffer wouldn't reveal anything other than missing packets anyways, which you could just as easily deduce from a debug or looking at the retransmit counters on the bgp neighbor. http://cisco.cluepon.net/index.php/Using_capture_buffer_with_ELAM http://cisco.cluepon.net/index.php/6500_SPAN_the_RP My money is still on MTU mismatch. Assume the simplest and most likely explanation until proved otherwise. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)