SupIV redundancy question (Cat4507R) - weird...

[joneswill]

Hi

I have a pair of 4507Rs, each with a pair of SUP-IVs.  I have configured sso redundancy mode.  It fails over correctly.

My problem is weird...

When I test resiliency I pull the primary Supervisor engine.  When I do this, although the secondary takes over, one of the interfaces on one of the other modules (ws-x4506-gb-t) in the chassis goes from "connected" to "not-connected".

This interface is terminating a wan circuit.  It is configured as a L3 interface and also has an EIGRP summary-address configured.

I cannot figure out why, when I pull the primary supervisor, this interface fails. 

Anyone?

[glen.grant]

Is there any kind of tracking statement pointing to an interface on the supervisor you pull out that might disable that link?

[joneswill]

nope,

just to add, the interface that is failing has this config:

int g4/1

no switch

ip add 172.16.x.x 255.255.x.x

ip summary-address eigrp 10 172.16.x.x 255.255.x.x 5

I have two other eigrp peers connected to the switch, neither fails.  One is via a PortChannel, one is via a Vlan.  The one that fails is via a phys interface.

[kapathak]

Does this happen on both the 4500s that you have?

If yes, is it always the same interface that goes down on the same module?

Once it goes down, are you able to bring it back up (without switching back to the former primary sup)?

What is the code being used on the 4500s?

[kapathak]

Can you post the sh mod too?

[joneswill]

The WAN circuit comes into g4/1 on the primary 4500.  It will be another few weeks before the secondary WAN circuit comes in, and that will go into the secondary 4500.

When the supervisor fails over the g4/1 goes down and will not come backup.  The only way it comes up is when I swap back to the primary supervisor.

Chassis Type : WS-C4507R

Power consumed by backplane : 40 Watts

Mod Ports Card Type                              Model              Serial No.

---+-----+--------------------------------------+------------------+-----------

1     2  Supervisor IV 1000BaseX (GBIC)         WS-X4515           JAE110550E5

2     2  Supervisor IV 1000BaseX (GBIC)         WS-X4515           JAE0932HJUX

3     6  SFP, 10/100/1000BaseT (RJ45)V, Cisco/I WS-X4506-GB-T      JAE1331F7WS

4     6  SFP, 10/100/1000BaseT (RJ45)V, Cisco/I WS-X4506-GB-T      JAE1252493V

5     6  SFP, 10/100/1000BaseT (RJ45)V, Cisco/I WS-X4506-GB-T      JAE125249EB

6    48  10/100/1000BaseT (RJ45)                WS-X4548-GB-RJ45   JAE0932HEUT

M MAC addresses                    Hw  Fw           Sw               Status

--+--------------------------------+---+------------+----------------+---------

1 0012.7fc2.da00 to 0012.7fc2.da01 5.2 12.2(20r)EW1 12.2(54)SG1      Ok

2 0012.7fc2.da02 to 0012.7fc2.da03 4.2 12.2(20r)EW1 12.2(54)SG1      Ok

3 001b.539b.596c to 001b.539b.5971 1.4                               Ok

4 001b.539b.3248 to 001b.539b.324d 1.4                               Ok

5 001b.539b.3206 to 001b.539b.320b 1.4                               Ok

6 0014.f2f1.bfd0 to 0014.f2f1.bfff 2.1                               Ok

Mod  Redundancy role     Operating mode      Redundancy status

----+-------------------+-------------------+----------------------------------

1   Active Supervisor   SSO                 Active

2   Standby Supervisor  SSO                 Standby hot

[Reza Sharifi]

Do you have the same exact IOS version and feature set with the same license installed on both sups?

[joneswill]

Yes.  I couldnt get sso working without that.

[kapathak]

I have seen a similar issue in the past where the problem would follow the supervisor i.e, if the standby supervisor would take over as active, the interface would fail. If the supervisor was moved around and swapped to a different slot, the problem would still persist if that supervisor took over as active. The fix was a supervisor replacement which is why I want to know if you see the same behavior on both of these 4500s. Maybe, for testing and isolation, you could try swapping out the supervisor in slot 2 with a spare (or if possible, from the other 4500) to see if the problem goes away.

[joneswill]

Interesting.  I have some spare SupIVs so I will try them out.

Will report back next week.

thanks

[joneswill]

Update:

It turned out that my 6-port gig line-card was faulty.

thanks all for your help.

[manju.cisco]

Hi Joneswill,

Just for better understanding on this fault reason, you said your card/module 4 was faulty, here may i ask you didn't the earlier active supervisor (on slot 1) identify this module 4 as faulty ?

Here what i im confused with is, with active SUP on slot 1 the module 4 was functioning properly, and when sup on slot 2 was active the same module was is faulty......??

I am wondering why SUP on slot 1 when active did see the module as functioning correctly ??

[joneswill]

Hi.

It was only when I tried using another 6-port line card that my problem went away.  Cisco believe the problem is the phys port on the line card, and not either supervisor module.