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
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.
http://cisco.cluepon.net/index.php/Using_capture_buffer_with_ELAM
http://cisco.cluepon.net/index.php/6500_SPAN_the_RP
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.