Forum Discussion

Timothy_92333's avatar
Timothy_92333
Icon for Nimbostratus rankNimbostratus
Jul 07, 2014

vCMP Guests - Traffic Group shows "Initializing / Not Synced"

Folks,

 

I have two vCMP guests on a Viprion blade that were on 11.3 HF5 with no issues but as of a few minutes ago are now on 11.3 HF9. The configs have synced across peers - I have pretty green indicators in the top left hand side of the GUI. But when I navigate to Device Management -> Traffic Groups, the "Next Active Device" field says, Initializing / Not Synced." What can I do to correct this? What is the issue that has caused this to happen?

 

Thanks,

 

Timothy

 

f5 viprion
vcmp
  • hari_126827's avatar
    hari_126827
    Jul 08, 2014

    Hi Timothy,

     

    Please check below site: http://support.f5.com/kb/en-us/solutions/public/13000/900/sol13946.html

     

    Above site link will have good info which could be found for configsync DSC issues... I had seen similar issue on Viprion chassis.,but resolved after reboot of vCMPs..

     

    But the above link will provide more information specific to mcpd service.. link on core system services info: http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos_management_guide_10_1/tmos_appendix_c_system_services.html

     

  • hari_126827's avatar
    hari_126827
    Icon for Cirrus rankCirrus
    Jul 07, 2014

    Hi,

     

    Try to execute save /sys config partitions all and then see if the Next Active Device is synced..This problem occurs if we have nodes or objects mismatch in either of the sync devices.. or Are the devices rebooted after hotfix HF9?

     

  • Timothy_92333's avatar
    Timothy_92333
    Icon for Nimbostratus rankNimbostratus
    Jul 07, 2014

    I didn't explain it well to start with. I have vCMP guests that are peers on two different Viprions. They were running fine with 11.3 HF5 but with the upgrade to 11.3 HF9 they appear to be ok (I can sync the configs) but the traffic group has a status of "Initializing / Not Synced."

     

  • Timothy_92333's avatar
    Timothy_92333
    Icon for Nimbostratus rankNimbostratus
    Jul 08, 2014

    To both of the guests I have saved the config:

     

    tmsh: save sys config partitions all

     

    When navigating to Device Management -> Traffic Groups, the "Next Active Device" field still says, "Initializing / Not Synced."

     

  • Timothy_92333's avatar
    Timothy_92333
    Icon for Nimbostratus rankNimbostratus
    Jul 08, 2014

    I haven't done a comparison of the objects through the config file to know if there are objects that haven't been synchronised across peers but a glance through the GUI seems ok.

     

  • hari_126827's avatar
    hari_126827
    Icon for Cirrus rankCirrus
    Jul 08, 2014

    Hi Timothy,

     

    Please check below site: http://support.f5.com/kb/en-us/solutions/public/13000/900/sol13946.html

     

    Above site link will have good info which could be found for configsync DSC issues... I had seen similar issue on Viprion chassis.,but resolved after reboot of vCMPs..

     

    But the above link will provide more information specific to mcpd service.. link on core system services info: http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos_management_guide_10_1/tmos_appendix_c_system_services.html

     

  • Timothy_92333's avatar
    Timothy_92333
    Icon for Nimbostratus rankNimbostratus
    Jul 10, 2014

    Thanks, hari. I worked all the way through Sol13946, the doc that you referenced above, and right at the bottom was the if-all-else-fails reset trust. So I did. I had to add the peer into the failover group since it had lost trust and then I resynced the boxes and it’s happy again. Thank you for your help.

     

    Timothy

     

  • sstafford's avatar
    sstafford
    Icon for Nimbostratus rankNimbostratus
    Nov 07, 2014

    Same exact thing happened to me on a 11.6.0 upgrade. Nothing in the above thread has addressed this. Resetting device trust has no effect other than both Ltms go active until the traffic and device groups are rebuilt

     

  • sstafford's avatar
    sstafford
    Icon for Nimbostratus rankNimbostratus
    Nov 11, 2014

    More info; the result of a "tmsh show /cm traffic-group traffic-group-1 auto-failback-enabled" run on each LTM.

     

    TLDR--The active LTM does not see the standby LTM as being online. The standby LTM does view the Active LTM correctly

     

    Active config tmsh show /cm traffic-group traffic-group-1

     

    CM::Traffic-Group traffic-group-1 standbyF5.net.unc.edu offline false traffic-group-1 ActiveF5.net.unc.edu active false

     

    Standby config tmsh show /cm traffic-group traffic-group-1

     

    traffic-group-1 standbyF5.net.unc.edu standby true traffic-group-1 ActiveF5.net.unc.edu active false

     

    Both LTMs are synced, but on the Primary LTM the traffic group lists only the Active LTM--as "current device"

     

    Underneath that is "Next Active DeviceInitializing / Not Synced"

     

    Essentially, the active F5 does not see the standby as being in its traffic group, even though both appear in the HA order box, even though the standby does sees the active. The gui on each is exactly the same, save that on the standby, the correct ltm name appears as "Next Active Device"

     

    Testing this on a virtual pair with no traffic, and I found that if I force the primary to standby, 1. The previous standby LTM will go Active 2. Then the originally active LTM goes active AGAIN 3. And the previous standby LTM falls back to standby.

     

    So the standby LTM behaves as it should, but as far as the primary is concerned, it is the only active ltm in the traffic group. Auto-failback is NOT enabled on either LTM.

     

    I just upgraded three pairs of virtual LTMs from 11.4.1 to 11.6.0 on our Viprions, and each pair has the same exact problem. Also, each of the Active LTMS with the issue are hosted on the same Viprion chassis, so there may be an issue on the chassis itself forcing the behaviour, but I am damned if I can figure out what it would be.