Cloud Managed Networks

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 

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 

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. 

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 

@MGT-JoeThanks 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 

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. 

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 

@MGT-JoeThanks 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 

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. 

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 

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 jjackson@mgt.us

@MGT-JoeThanks 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 

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. 

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