[c-nsp] Trouble 6509s, can't establish BGP on point to point link

Wed Mar 30 15:42:34 EDT 2011

 Keegan,

   As always you're right on top of stuff - I am looking at the following as
needing correcting before anything else. And this link has never behaved
properly. Never occurred to me that promiscuous redistribution would cause
such troubles, but I didn't build this one and it's the Aegean Stables of
networks so I'd been letting this slide in favor of other, more pressing
tasks.

router ospf 1
 log-adjacency-changes detail
 redistribute connected subnets
 redistribute static subnets

                  Neal

On Wed, Mar 30, 2011 at 2:29 PM, Keegan Holley <keegan.holley at sungard.com>wrote:

>
> On Wed, Mar 30, 2011 at 1:33 PM, Neal Rauhauser <neal.rauhauser at gmail.com>wrote:
>
>> I have the following two 6509s connected via a short single mode fiber run
>> -
>> they're about a hundred yards apart.
>
>
> Are you sure the fiber and path are ok?  patch panels, sfp's etc..  I've
> replaced "good" fiber with another piece of "good" fiber and had problems
> magically disappear.
>
>
>> BGP sessions between them bounce on the
>> BGP timer and never properly establish. This link carries a lot of traffic
>> and it never stumbles, not in terms of anything in logs, no errors on the
>> interface, no visible effect. It's just BGP.
>>
>
> I'm not sure I understand.  How is traffic forwarding if BGP bounces?  NSF?
>  Is it a P-router?
>
>>
>>
>>  One of the machines has a production BGP setup and it works fine. The
>> other
>> knows its world via OSPF.
>>
>
> Not sure I get this one either.  Is one redistributing into BGP?  Is BGP
> just there for management?  Please elaborate.
>
>>
>>
>>  If I issue a “clear ip bgp *” on VT6509 I lose the ability to ping &
>> telnet
>> to the machine on the other end of the link. Customers experience no
>> traffic
>> interuption – it appears to be purely a problem with the supervisor's IP
>> stack. I can't reproduce the problem without BGP in the mix.
>>
>
> That's strange.  Are you peering with an interface address, vlan interface
> or a loopback?  When BGP bounces where does the route to it go?  Are you
> saying that you can't ping something directly connected when BGP is
> bouncing?  Did you try tracing to it?  Without any other info it sounds like
> a routing loop. If it's a vlan interface it could also be a problem with the
> layer-2 path.
>
>>
>>
>>
>>  What do I do next? Time for a new image? Which one, given these engines
>> and
>> revision levels? We have BGP, OSPF, VRRP, and for reasons I am ashamed to
>> explain one of these devices has NAT running on it. I don't envision the
>> requirements changing all that much.
>>
>
> Is neighbor transition logging turned on?  What status code do you get when
> the neighbor bounces?  That's usually a dead giveway?  Also, how is RAM and
> proc on the box.  I've seen some problems with 720's and full tables despite
> all the spec sheets.
>
>>
>>
>>  Some words of wisdom here would be greatly appreciated ...
>>
>
> If this used to work and suddenly doesn't
>
>>
>>
>>
>>  VP6509
>>
>> IOS (tm) s222_rp Software (s222_rp-ADVIPSERVICESK9_WAN-M), Version
>> 12.2(18)SXF17a, RELEASE SOFTWARE (fc1)
>>
>> BOOTLDR: s222_rp Software (s222_rp-ADVIPSERVICESK9_WAN-M), Version
>> 12.2(18)SXF17a, RELEASE SOFTWARE (fc1)
>>
>> System image file is "disk0:s222-advipservicesk9_wan-mz.122-18.SXF17a.bin"
>>
>> cisco WS-C6509 (R7000) processor (revision 2.0) with 458752K/65536K bytes
>> of
>> memory.
>>
>> Processor board ID SCA0338003S
>>
>> R7000 CPU at 300Mhz, Implementation 0x27, Rev 3.3, 256KB L2, 1024KB L3
>> Cache
>>
>>
>>  NAME: "1", DESCR: "WS-X6K-SUP2-2GE 2 ports Catalyst 6000 supervisor 2
>> Rev.
>> 4.3"
>>
>> PID: WS-X6K-SUP2-2GE
>>
>> NAME: "msfc sub-module of 1", DESCR: "WS-F6K-MSFC2 Cat6k MSFC 2
>> daughterboard Rev. 2.5"
>>
>> PID: WS-F6K-MSFC2
>>
>> NAME: "switching engine sub-module of 1", DESCR: "WS-F6K-PFC2 Policy
>> Feature
>> Card 2 Rev. 3.4"
>>
>> PID: WS-F6K-PFC2
>>
>> NAME: "2", DESCR: "WS-X6408-GBIC 8 port 1000mb ethernet Rev. 2.3"
>>
>> PID: WS-X6408-GBIC
>>
>>
>>
>>  VT6509
>>
>> IOS (tm) s222_rp Software (s222_rp-ADVIPSERVICESK9_WAN-M), Version
>> 12.2(18)SXF17a, RELEASE SOFTWARE (fc1)
>>
>> BOOTLDR: s222_rp Software (s222_rp-ADVIPSERVICESK9_WAN-M), Version
>> 12.2(18)SXF17a, RELEASE SOFTWARE (fc1)
>>
>> System image file is "disk0:s222-advipservicesk9_wan-mz.122-18.SXF17a.bin"
>>
>> cisco WS-C6509 (R7000) processor (revision 2.0) with 458752K/65536K bytes
>> of
>> memory.
>>
>> Processor board ID SCA044200US
>>
>> R7000 CPU at 300Mhz, Implementation 0x27, Rev 2.1, 256KB L2, 1024KB L3
>> Cache
>>
>>
>>  NAME: "1", DESCR: "WS-X6K-SUP2-2GE 2 ports Catalyst 6000 supervisor 2
>> Rev.
>> 5.1"
>>
>> PID: WS-X6K-SUP2-2GE
>>
>> NAME: "msfc sub-module of 1", DESCR: "WS-F6K-MSFC2 Cat6k MSFC 2
>> daughterboard Rev. 1.2"
>>
>> PID: WS-F6K-MSFC2
>>
>> NAME: "switching engine sub-module of 1", DESCR: "WS-F6K-PFC2 Policy
>> Feature
>> Card 2 Rev. 3.5
>>
>> PID: WS-F6K-PFC2
>>
>> NAME: "2", DESCR: "WS-X6408-GBIC 8 port 1000mb ethernet Rev. 2.4"
>>
>> PID: WS-X6408-GBIC
>>
>>
>>
>>
>>  !VP6509
>>
>> interface Loopback0
>>
>> ip address 192.168.200.1 255.255.255.255
>>
>>
>>  interface GigabitEthernet2/1
>>
>> ip address 192.168.200.34 255.255.255.252
>>
>> no ip redirects
>>
>> ip nat inside
>>
>> ip route 192.168.200.2 255.255.255.255 192.168.200.33
>>
>>
>>  !VT6509
>>
>> interface Loopback0
>>
>> ip address 192.168.200.2 255.255.255.255
>>
>> interface GigabitEthernet2/1
>>
>> ip address 192.168.200.33 255.255.255.252
>>
>> load-interval 30
>>
>> ip route 192.168.200.1 255.255.255.255 192.168.200.34
>> _______________________________________________
>> 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/
>>
>>
>