Rebooting a SUP2T mit DFC modules and HSRP V2 hold time

[krueffer]

Guys,

I got a general question.

For a client I setup two Catalyst 6509E with SUP2Ts and DFC modules.

For HA purposes I use HSRP in the vlan connected towards their Checkpoint Firewall (and some other vlans).

While rebooting the HSRP active core I noticed, that for some vlans the switchover in HSRP took much longer than the hold time of 10 seconds.

(roughly 40 s for one instance).

This I don't understand. The only thing that comes to my mind, is that the DFC modules in the machine that was reloaded, have continued to send  HSRP V2 hellos for some time, until they have been reloaded.

Hopefully somebody can shed some light into this behaviour...

thanks

Knut

[Jon Marshall]

Knut

As far as i am aware HSRP uses control plane packets which are generated by the RP on the supervisor. So as soon as the supervisor has gone down there should be no more HSRP packets being generated. 

The amount of time sounds suspiciously close to an STP convergence. What version of STP are you running ?

Just out of interest is there a reason not to run VSS which would remove the need for HSRP ?

Jon

[krueffer]

Jon,

thanks. Well STP came to my mind too. But it should be fine. The vlan is u-shaped and it is configured to use RSTP

usc153-01#sh spanning-tree vlan 3210

VLAN3210
  Spanning tree enabled protocol rstp
  Root ID    Priority    7306
             Address     e8ba.7043.b400
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    7306   (priority 4096 sys-id-ext 3210)
             Address     e8ba.7043.b400
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 480

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po10                Desg FWD 1         128.1667 P2p
Po11                Desg FWD 1         128.1668 P2p Edge

usc153-01#

usc099-01#sh spanning-tree vlan 3210

VLAN3210
  Spanning tree enabled protocol rstp
  Root ID    Priority    7306
             Address     e8ba.7043.b400
             Cost        1
             Port        1666 (Port-channel10)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    11402  (priority 8192 sys-id-ext 3210)
             Address     e8ba.7042.cc80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 480

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po10                Root FWD 1         128.1666 P2p
Po11                Desg FWD 1         128.1667 P2p Edge

usc099-01#

- Port Channel 10 is the link between the two cores

- Port Channel 11 is the link towards the firewall

But regardless, of how fast STP converges, HSRP should become active on  the econdary router after the hold time has expired.

That is was confuses me.

Thanks

Knut

[Jon Marshall]

Knut

Hmmm, i am now wondering what order the 6500 shuts down in and i'm not sure to be honest. I m wondering if the port channel went down that is used for the firewalls but the supervisor was still active and sending HSRP hellos via it's port channel. This is assuming the port channel between the cores is using at least one port on the supervisors.

I appreciate you cannot simply test this but i was wondering what would happen if the port-channel connecting the 2 switches was shutdown ie. how quick would HSRP be then ?

Jon

[krueffer]

Jon,

I agree, the port channel on the sup could be the last port to go down and may cause this issue.

Today I was proposing to the client to execute some tests. One of those being just to shutdown the power of the HSRP primary core.

This will proove if the reload process causes the behaviour observed.

I¨ll keep you informed. By the way, we are considering to turn the dual core in a VSS setup.

Thanks!

Knut

[Jon Marshall]

Knut

No problem. I suspect this is the issue but it would be good to know for sure. And VSS is definitely a good idea not just for HSRP but it would solve that problem.

Jon

[krueffer]

Jon,

if the client is not willing to implement VSS, we may consider tracking objects to force HSRP to switch over by a change of priority. (sorry it just came to my mind)

regards

Knut