Cloud Managed Networks

 View Only

  • 1.  CX Core / Aggregation Migration from Classic to New Central

    Posted Feb 26, 2026 02:00 PM

    Hi Airheads,

    Looking for input from anyone who has migrated CX core and aggregation switches from Classic Central to New Central, particularly in environments that were managed using CLI templates.

    Current setup is a mid-size campus.

    Core is 2x CX 8360 in VSX. All SVIs live there and it's the default gateway.

    Aggregation is two separate 2-member CX 6300 VSF stacks, one per building. They uplink to core with routed links and run OSPF. Access switches hang off aggregation as L2.

    Core and aggregation are managed in Classic Central using CLI templates. Access layer is mixed between UI and templates.

    Core and aggregation are currently on 10.13.x.

    We're planning to move fully to New Central for configuration and monitoring.

    A few questions:

    • For infrastructure switches like core and aggregation, is it common to keep most of the configuration at device scope in New Central, or have people successfully broken out shared elements like VLAN definitions into Library profiles without creating inheritance headaches?
    • When coming from Classic template-based groups, did you try to preserve that logical separation using Device Groups in New Central, or did you restructure around the Site / Site Collection model instead?
    • For VSX cores specifically, how are you handling VLAN and SVI definitions? Keeping VLAN global and SVI IP local seems logical, but curious if that's working cleanly in practice.
    • For VSF aggregation stacks that participate in L3 (OSPF adjacency to core), did moving from template management to profile-based management introduce anything unexpected?
    • From a migration sequencing standpoint, does it make more sense to move access switches first to get comfortable with the model, or address core and aggregation early while change windows are planned?
    • Are there any current limitations in New Central for CX switches?

    Thanks 



    -------------------------------------------


  • 2.  RE: CX Core / Aggregation Migration from Classic to New Central

    Posted Feb 27, 2026 04:07 AM
    • VLAN can be shared . The SVI definitions ,specifically SVI IP can be converted to an alias ( variable ) which can be defined at each switch seperately without creating overrides.
    • It would be best to move it in to the site model as the device function allows admin to define specific or shared config between device functions like Access, Agg , core.
    • Check #1 . The only situation we have to force overrides is when  vlan is used as L2 and L3 , one of this needs to be defined as override. 
    • It would be good to start with access and then get comfortable with the operational model , then get to agg and core.

    -------------------------------------------



  • 3.  RE: CX Core / Aggregation Migration from Classic to New Central

    Posted Feb 27, 2026 07:59 AM

    Keep in mind that you cannot create loopback interface in CNX, you will need to use an API call to create them. Do not use the CLI to create them as CNX will not be aware of them if you do. If you are using CPPM for RADIUS services, you cannot enable interim accounting through CNX and there is no API call to perform the same. It has to be enabled through the CLI. There is also currently a bug in CNX that does not enable CoA in the global config even though you configure it. You have to enable that via CLI. 

    In my opinion CNX is a lot more configurable from a UI standpoint than legacy central but is still lacking some maturity. The biggest thing is the lack of a CNX aware CLI type editor like Mukti-Edit. As of right now, CNX is not aware of any CLI configured items and makes it where you have to use the API. 

    -------------------------------------------



  • 4.  RE: CX Core / Aggregation Migration from Classic to New Central

    Posted Mar 02, 2026 12:41 PM

    @JJ-Emj358Thanks for the feedback . 

    Loopback , Radius accounting : We are working to make sure it is UI configurable in future.

    Not sure if we are missing anything on API. Existing API does  allows config of interim accounting. please check this   https://developer.arubanetworks.com/new-central-config/reference/createlocalmanagementprofilebyid 

    -------------------------------------------

    Original Message


  • 5.  RE: CX Core / Aggregation Migration from Classic to New Central

    Posted Mar 02, 2026 01:13 PM
    Thanks, Mubeeshm.

    I combed through the API documentation looking for the interim accounting settings and could not find it. I didn't think to look in the Local Management Profile settings.
    Joe Jackson
    		​​​​
    SYSTEMS ENGINEER III
    Nashville, TN
    C: 931.409.7074
    jjackson@mgt.us



    Original Message


  • 6.  RE: CX Core / Aggregation Migration from Classic to New Central

    Posted Mar 02, 2026 01:28 PM
    Mubeesh,
    That did not have the settings that I was looking for.

    We are looking for an API to set these commands:

    aaa accounting port-access start-stop group radius
    aaa accounting port-access start-stop interim 5 group radius


    Joe Jackson
    SYSTEMS ENGINEER III
    Nashville
    , 
    TN
    C: 931.409.7074



    Original Message


  • 7.  RE: CX Core / Aggregation Migration from Classic to New Central

    Posted Mar 02, 2026 05:20 PM

    looking at the link that was provided i think you need to select the record type of "interim update" and "periodic-update" of 5

    I have not tried it myself, let me know if this works.

    {
      "accounting": {
        "accounting-group": [
          {
            "record-type": "INTERIM_UPDATE"
          }
        ],
        "periodic-update": 5
      }
    }



    ------------------------------
    If my post was useful accept solution and/or give kudos.
    Any opinions expressed here are solely my own and not necessarily that of HPE or Aruba.
    ------------------------------

    Original Message


Related Content