Wireless Access

last person joined: 16 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

651s rebooting - cfgm process died

This thread has been viewed 2 times
  • 1.  651s rebooting - cfgm process died

    Posted May 21, 2012 10:56 AM

    We're opening a case with TAC now, but I wanted to check if anyone has seen controllers randomly rebooting with "Nanny rebooted machine - cfgm process died."

     

    We just upgraded from 3.4.2.7 to 5.0.4.4 last night and several of our 651s are rebooting with that cause.  We didn't go to 5.0.4.6 because I observed odd VRRP behavior with that release in a prior upgrade in a different infrastructure.  However, there's nothing to indicate that anything like this is fixed in 5.0.4.6 anyway.

     

     

    (MIA-WLC01) #show ver
    Aruba Operating System Software.
    ArubaOS (MODEL: Aruba651-US), Version 5.0.4.4
    Website: http://www.arubanetworks.com
    Copyright (c) 2002-2012, Aruba Networks, Inc.
    Compiled on 2012-01-25 at 23:06:42 PST (build 32089) by p4build

    ROM: System Bootstrap, Version CPBoot 1.0.0.0 (build 23274)
    Built: 2010-01-19 11:11:41
    Built by: p4build@re_client_23274


    Switch uptime is 30 minutes 44 seconds
    Reboot Cause: Nanny rebooted machine - cfgm process died.
    Supervisor Card
    Processor XLS 408 (revision B1) with 906M bytes of memory.
    32K bytes of non-volatile configuration memory.
    256M bytes of Supervisor Card System flash (model=NAND 256MB).



  • 2.  RE: 651s rebooting - cfgm process died

    Posted May 21, 2012 11:15 AM

    Do you utilize the internal AP on the 651?  If not, can you disable it?  I think that will stop the reboots until Aruba fixes the underlying bug.

     

    If you do use the internal AP, you may have to downgrade.



  • 3.  RE: 651s rebooting - cfgm process died

    Posted May 21, 2012 11:48 AM

    I hope we can get away without the internal AP.  Downgrading isn't an option, everything has to run the same code.



  • 4.  RE: 651s rebooting - cfgm process died

    Posted May 21, 2012 01:39 PM

    Mike, 

     

    In order to disable the internal AP, create a new rf dot11g radio profile with radio disabled and apply it to the internal AP. 

     

     



  • 5.  RE: 651s rebooting - cfgm process died

    Posted May 21, 2012 01:44 PM

    Remember, though, when you reprovision the internal AP, the controller will reboot (only on the 651 model with the built-in AP).  

     

    Make sure you plan for that down time.



  • 6.  RE: 651s rebooting - cfgm process died

    Posted May 21, 2012 02:15 PM

    Thanks for the tips, but neither make sense.  Reprovision the internal AP to do what?  There's no option to disable it.

     

    Make a new 11g radio profile to do what?



  • 7.  RE: 651s rebooting - cfgm process died

    Posted May 21, 2012 02:24 PM

    You need to make a new AP group and the remove all of the VAPs.  Also, make a two new radio profiles and make sure the radio's are disabled.

     

    Then, reprovision the internal 651 AP into that new AP group so that it will be disabled.

     

    Any other APs that use the 651 should stay in the groups they are already provisioned into.

     

    Make sure you don't disable the radios on the production radio profiles or your APs will stop working.



  • 8.  RE: 651s rebooting - cfgm process died

    Posted May 21, 2012 02:35 PM

    Ok, that makes sense, thanks.  One point of clarity, I have about five of these and I'd rather just make one AP group for this workaround.  Is it at all relevant what LMS is in the AP system profile?  I was just going to use my master controller for that if it's ok.

     

    Before we do anything though, we're going to get final word from TAC.

     

    Honestly, I'm flat out shocked that Aruba would allow this code to even be downloadable.  You simply can't put code out for general use that is knowingly going to crash a platform in just about every single out-of-the box use case.  There at least needs to be a warning in the download directory that the code is not acceptable for use in a 651.



  • 9.  RE: 651s rebooting - cfgm process died

    Posted May 21, 2012 02:40 PM

    Definitely have TAC confirm that disabling the radio will help. 

     

    You can create the AP group and related profiles from the master and have it push to the locals.  That's not a problem.



  • 10.  RE: 651s rebooting - cfgm process died

    Posted May 21, 2012 02:43 PM

    Yes, I know I can create the group on the master, I was just wondering if it would be ok to use the master as the LMS for all five of the 651's built-in APs.  I don't see why it would be a problem, but I wanted to check.



  • 11.  RE: 651s rebooting - cfgm process died

    Posted May 21, 2012 02:49 PM

    I would leave the LMS IP blank.  The AP will "find" it's locally connected 651 via ADP.



  • 12.  RE: 651s rebooting - cfgm process died
    Best Answer

    Posted May 21, 2012 02:57 PM

    Hmmm, with ADP it could find any controller as multicast is on our entire infrastructure.  We see that with new APs coming on the network all the time.  I'll just put the master in there, it should be fine.



  • 13.  RE: 651s rebooting - cfgm process died
    Best Answer

    Posted May 24, 2012 11:20 AM

    FYI, looks like we're stable now on our 651s.  I created new 11a and 11g radio profiles to disable the radios.  Then I just put the 651 built-in APs in AP Specific groups and applied those profiles.  Thanks for all the help!



  • 14.  RE: 651s rebooting - cfgm process died

    Posted May 24, 2012 11:22 AM

    @mike.j.gallagher wrote:

    FYI, looks like we're stable now on our 651s.  I created new 11a and 11g radio profiles to disable the radios.  Then I just put the 651 built-in APs in AP Specific groups and applied those profiles.  Thanks for all the help!


    Mike, 

     

    Thanks for updating the thread. Glad to know that the 651 controller is stable. 

    --

    HT