RE: <Keepalives are temporarily in throttle due to closed TCP window>
And is that the one that traverses the 3550 with the 1500 byte MTU? Both connection traver through the 3550. I will disable the command on 7206 vxr. thanks -----Original Message----- From: "Richard A Steenbergen" <ras@e-gerbil.net> To: "Michael Ruiz" <mruiz@telwestservices.com> Cc: "Brian Dickson" <Brian.Dickson@concertia.com>; "nanog@nanog.org" <nanog@nanog.org> Sent: 9/16/09 8:58 PM Subject: Re: <Keepalives are temporarily in throttle due to closed TCP window> On Wed, Sep 16, 2009 at 06:47:10PM -0500, Michael Ruiz wrote:
Either a) you have the mtu misconfigured on that 7206vxr
That part is where I am at a loss. How is it the 6509 can establish a IBGP session with a 7606 when it has to go through the 7206 VXR? The DS-3s are connected to the 7206 VXR. To add more depth to the story. I have 8 IBGP sessions that are connected to the 7206 VXR that have been up and running for over a year. Some of the sessions traverse the DS-3s and or a GigE long haul connections. There are a total 10 Core routers that are mixture of Cisco 7606, 6509s, 7206 VXR w/ NPE400s or G1s. Only this one IBGP session out of 9 routers is not being established. Since I have a switch between the 7606 and 7206, I plan to put a packet capture server and see what I can see.
And is that the one that traverses the 3550 with the 1500 byte MTU? Re-read what we said. You should be able to test the MTU theory by disabling path-mtu-discovery, which will cause MSS to fail back to the minimum 576. -- 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)
Oh you guys are going to love this...Before I could send out the 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: -----Original Message----- From: Michael Ruiz Sent: Thursday, September 17, 2009 7:47 AM To: Richard A Steenbergen; Michael Ruiz Cc: Brian Dickson; nanog@nanog.org Subject: RE: <Keepalives are temporarily in throttle due to closed TCP window> And is that the one that traverses the 3550 with the 1500 byte MTU? Both connection traver through the 3550. I will disable the command on 7206 vxr. thanks -----Original Message----- From: "Richard A Steenbergen" <ras@e-gerbil.net> To: "Michael Ruiz" <mruiz@telwestservices.com> Cc: "Brian Dickson" <Brian.Dickson@concertia.com>; "nanog@nanog.org" <nanog@nanog.org> Sent: 9/16/09 8:58 PM Subject: Re: <Keepalives are temporarily in throttle due to closed TCP window> On Wed, Sep 16, 2009 at 06:47:10PM -0500, Michael Ruiz wrote:
Either a) you have the mtu misconfigured on that 7206vxr
That part is where I am at a loss. How is it the 6509 can establish a IBGP session with a 7606 when it has to go through the 7206 VXR? The DS-3s are connected to the 7206 VXR. To add more depth to the story. I have 8 IBGP sessions that are connected to the 7206 VXR that have been up and running for over a year. Some of the sessions traverse the DS-3s and or a GigE long haul connections. There are a total 10 Core routers that are mixture of Cisco 7606, 6509s, 7206 VXR w/ NPE400s or G1s. Only this one IBGP session out of 9 routers is not being established. Since I have a switch between the 7606 and 7206, I plan to put a packet capture server and see what I can see.
And is that the one that traverses the 3550 with the 1500 byte MTU? Re-read what we said. You should be able to test the MTU theory by disabling path-mtu-discovery, which will cause MSS to fail back to the minimum 576. -- 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)
On Thu, Sep 17, 2009 at 09:17:00AM -0500, Michael Ruiz wrote:
Oh you guys are going to love this...Before I could send out the 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)
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)
participants (2)
-
Michael Ruiz -
Richard A Steenbergen