Forum Discussion

FredO_01_141598's avatar
FredO_01_141598
Icon for Nimbostratus rankNimbostratus
Apr 24, 2015

Viprion2400-remove bad card slot 1, slot 2 does not send any monitor probes-all Vir servers down!

we had a bad card in slot of our 2400(running as HA secondary), configured in two card chassis cluster. has been replaced 3 times. We suspect slot is bad. Per F5 instructions, we were told to remove bad card, reboot, and once slot2 comes up, then install replacement card in slot 1.

 

Issue is that after reboot, and prior to new slot 1 being inserted, slot 2 is cluster master but does not process traffic.

 

tcpdump shows no probes being sent on any route domain. This is unexpected behavior in that why are two slots required to process traffic? had this chassis been HA primary, and a slot failed, we would have immediately required an HA failover.

 

Code is 10.2.4 HF10. Need some F5 input here since this appears to be unexpected behavior.

 

application delivery
LTM
management

2 Replies

Sort By
  • pete_71470's avatar
    pete_71470
    Icon for Cirrostratus rankCirrostratus
    Apr 24, 2015

    An event similar to what you're experiencing happened at our site, except we were running v11 and single-bladed. When moving the blade to a different slot, no monitor traffic would pass. The absence of monitor traffic was related to the interface definitions not being changed -- while in slot 2, the interface definitions still had 1/mgmt, 1/1.1, 1/1.2, etc instead of 2/mgmt, 2/1.1, 2/1.2, etc). A bug according to F5, but we didn't want to spend time experimenting with this theory -- an iffy Standby was better than none!

     

    In the end, after all the blade RMA's, the chassis was replaced and no issues since. A year later, we discovered that most of the RMA's weren't necessary -- release notes revealed that bogus voltage alarms and other power events were determined to be code flaws and nothing was really wrong with the hardware.

     

  • FredO_01_141598's avatar
    FredO_01_141598
    Icon for Nimbostratus rankNimbostratus
    Apr 24, 2015

    Thanks for your answer-interface definitions were correct on slot 2: 2/1.1 and 2/1.2 were up and available in a port channel(one member being active on slot 2, the others down on slot 1 which was absent). Slot 2 saw all interfaces undefined on slot 1 which it should since slot 1 wasnt plugged in.

     

    what I neglected to mention: virtual servers and pool members could be pinged from CLI from subject LTM when only one slot was active but no monitor traffic was sent, and thus all virtual servers down on secondary. So there had to be network connectivity in the data plane

     

    I agree it sounds like a bug but if youre on v11 and it you still saw it, bug still may be unresolved.