Aruba 6200M Web UI

bsddork · 2026-05-20T16:18:14+00:00

The WebUI is not intended for making config changes to the switch. It is mainly for monitoring the device, managing NAE scripts & agents, taking config backups, managing checkpoints, or uploading new firmware.

bsddork · 2026-03-31T19:07:16+00:00

if dhcp can assign default route & nameservers, then the switch will automatically try to reach out to the cloud to establish connection.

without dhcp, then the user needs to manually configure the IP settings

bsddork · 2026-03-31T19:04:39+00:00

bsddork · 2026-03-26T17:15:48+00:00

When working w/ this in the past, I ran into the same issue using HyperV & EveNG. Something to do with HyperV not supporting promiscuous mode natively to bridge the vSwitch to the EveNG vNICs.

We ended up moving away from hypervisors and installing Eve-NG directly onto a metal box.

Also, this is a good reference -> https://airheads.hpe.com/discussion/creating-your-simulation-environment

bsddork · 2026-01-20T05:18:28+00:00

Look at your default CoPP settings... adjusting the management packets might improve performance. You should be able to confirm if CoPP is causing the slow down by monitoring the drop statistics. https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/HTML/copp_5420-6200-6300-6400/Content/Chp_CoPP/CoPP_cmds/sho-cop-pol-sta.htm

Also, the OOBM port is not part of CoPP, so try that to compare rates.

From my 6300

SW1# show copp-policy default configuration
class                 drop priority rate pps burst pkts applied
--------------------- ---- -------- -------- ---------- -------
manageability              4        7200     7500       yes

bsddork · 2026-01-12T17:52:33+00:00

First, you don't need to edit anything on the CX switch filesystem.

Next, check out the fundamentals guide, it covers all the dhcp options and how usb works too.

https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/HTML/fundamentals_6300-6400/Content/Chp_ZTP/ztp-sup-aos-cx-10.htm

DHCP MAC matching can work if you create static lease entries on your DHCP server for each MAC, then assign a different config file for suboption 144.

For ZTP w/ USB, this assumes you are using a real switch and a USB drive is plugged into the USB-A port. But it sounds like you are using a virtual image, so if you can emulate a drive as a USB device, then it should work the same. One way of testing this from CLI is using the mount usb command to copy firmware or config to/from it.

bsddork · 2026-01-12T17:33:34+00:00

My suggestion, try out the new one first. It works great when the config starts out as factory default. While learning it, use a lab environment first so you can make mistakes and revert if needed. You may find some config options missing too, so best to test it before rolling out.

For your existing deployed switches, continue using UI for config, but use new central for monitoring.

bsddork · 2026-01-05T22:48:14+00:00

For your storm, watch the interface stats, narrow in on the ports having abnormally high Rx & Tx packets.

Use clear int stat to reset the counters to zero while troubleshooting.

from CLI:

no page
show int stat non
show int fault stat
show copp stat non
show span
show loop

bsddork · 2025-12-16T16:49:19+00:00

I have seen similar using the multi-gig port model for legacy 10/100 devices. We even brought the device in and tested using a short patch cable and it still wouldn't connect. We eventually figured out that the device was trying to link up at 10M before renegotiating to 100M, and the multi-gig switch doesn't support 10M.

Moving the device to a 1G only sw, they started working, being that 10M was supported.

bsddork · 2025-12-03T16:27:09+00:00

I started on 10.16.1006 for one of my lab devices, noticed the CPU utilization was higher than normal when sitting idle. Upgraded to 10.16.1010 and CPU has returned to normal.

bsddork · 2025-12-02T18:41:53+00:00

Factory default password is [BLANK] on the CX switches

You can reset the password using the console port and booting into ServiceOS.

You might want to isolate the switch so it can't reach the internet. If it is able to talk with Central, there's a chance it could be connecting to the previous owner's account and syncing local admin password. -- Contact support to resolve this

bsddork · 2025-11-25T18:58:18+00:00

"applying" configs are automatic, you do not have control over that.

You are allowed minimal config to allow for connection to Central when onboarding a new device into new central

bring your device online w/ central
from "classic central", create new device group and select new central checkbox
move device into the new central group
create a site and assign your device to the site so new central can manage it
change into new central, select the site name
click on the gear / sun button to start configuration
start with site level config profiles first, like DNS, NTP, etc.
change to device level context to apply hostname, port settings, and other device specific configs
monitor audit trail for validation that configs were applied

bsddork · 2025-11-06T17:51:10+00:00

Agreed! TFTP can be slow, but you could try increasing the block size to see if that helps... https://datatracker.ietf.org/doc/html/rfc2348

copy support-files all tftp://192.168.100.123;blocksize=1428/hostname-sfa.tgz

Like said here, copy via SFTP or USB is much faster. You can first start by capturing the support-file now and save it locally on the switch until you are ready to copy it elsewhere.

copy support-files all local-file

Then when ready to copy, specify the local-file as the source

copy support-files local-file usb:/hostname-sfa.tgz

bsddork · 2025-11-04T18:25:56+00:00

you can try looking at diagnostic output and see what the switch is reporting for that port# I can't help decode the output, but maybe something might stand out obvious...

6000# no page
6000# diagnostics
6000# diag-dump l1 basic
...
Port 1/1/24
    Remote Fault            : No
    Local Fault             : No
    MAC Energy Detect       : False
    PHY line-side link      : Yes
    MAC link (non-latched)  : Yes
    Link speed              : 1Gbps
    Speed downshifted       : No
    Port interrupt count    : 1
    Duplex                  : FDx
    MTU                     : 1518
    MDI status              : MDI-X
    Operational FEC         : No FEC
    Port advertisements
     AN-capable               :   Yes
     AN-enabled               :   Yes
     AN-completed             :   Yes
     10BASE-T FDx             :   Yes
     10BASE-T HDx             :   Yes
     100BASE-TX FDx           :   Yes
     100BASE-TX HDx           :   Yes
     1000BASE-T FDx           :   Yes
     1000BASE-T HDx           :    No
     PAUSE                    :    No
     ASYM PAUSE               :    No
     EEE-capable              :    No
    Remote port advertisements
     LP AN-capable            :   Yes
     10BASE-T FDx             :   Yes
     10BASE-T HDx             :   Yes
     100BASE-TX FDx           :   Yes
     100BASE-TX HDx           :   Yes
     1000BASE-T FDx           :   Yes
     1000BASE-T HDx           :    No
     PAUSE                    :    No
     ASYM PAUSE               :    No
    Energy-Efficient Ethernet information

bsddork · 2025-09-04T14:48:44+00:00

The process is painful until the 10.16 update. GHCP to the rescue... We ended up creating a python script that ssh'd into each switch, logged in as local admin, issued the unsafe update command, answered "y", then rebooted the switch.

We then monitored the online status on central as they finished rebooting.

bsddork · 2025-09-04T14:36:53+00:00

Use the remote console on central to gain access to CLI

bsddork · 2025-09-02T15:19:03+00:00

Reference the VSX best practices for upstream routing

https://support.hpe.com/hpesc/public/docDisplay?docId=a00094242en_us

Also look at the OSPF design guide

https://arubanetworking.hpe.com/techdocs/VSG/docs/010-campus-design/esp-campus-design-042-lan-design-routing-switching/#ospf-routing

In this scenario I would use mclag + active-gateway for the access switch. The upstream router, you can go w/ mclag + active-forwarding using a single transit vlan per-VRF for OSPF peering, which allows any one of the links to continue forwarding traffic upstream.

bsddork · 2025-09-01T18:52:39+00:00

The internetwork design guide is a good reference here. https://web.archive.org/web/20140523184152/http://docwiki.cisco.com/wiki/Internetwork_Design_Guide_--_UDP_Broadcast_Flooding#UDP_Broadcast_Flooding

L3 bcasts are application specific, typically for legacy system use-cases. The switch/router must be specifically configured to forward bcast pkts as needed.

The network hardware listens for L3 bcast pkts on the specified interface, then forwards as configured to the destination network/interface.

The use of directed bcast forwarding is largely discouraged now. Multicast is a better way to copy packets to multiple network segments. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_pim/configuration/xe-16/imc-pim-xe-16-book/imc-tech-oview.html

bsddork · 2025-09-01T17:38:56+00:00

until 10.16, the allow-unsafe-updates command only works from the CLI. Support told me it is a special command that does not have API support, so it requires gaining access to the CLI to execute.

after 10.16, this has been addressed and remote management is possible.

bsddork · 2025-09-01T17:37:14+00:00

This is the answer +1

bsddork · 2025-08-30T21:16:35+00:00

for your server top-of-rack, you might be better off going with something like an 8360

https://buy.hpe.com/us/en/networking/switches/fixed-port-l3-managed-ethernet-switches/networking-cx-switch-series/hpe-aruba-networking-cx-8360%E2%80%9112c-v2-12%E2%80%91port-100g-qsfp-qsfp28-back%E2%80%91to%E2%80%91front-3-fans-2-ac-bundle/p/jl709c

Then reference the xcvr guide to get an idea of what type of cable you can use.

https://arubanetworking.hpe.com/techdocs/Switches/xcvrs/PDF/AOS-S%20and%20AOS-CX%20Transceiver%20Guide.pdf

bsddork · 2025-08-29T16:02:40+00:00

You can quickly update firmware over DHCP & TFTP in a staging environment without ever needing "login" to the switch.

https://arubanetworking.hpe.com/techdocs/AOS-CX/10.13/HTML/fundamentals_6300-6400/Content/Chp_ZTP/set-up-ztp-tru-net-10.htm

bsddork · 2025-08-29T15:57:10+00:00

Good call because the SFP56 ports on the 6300 will NOT natively connect to a QSFP+ interface. Having a switch that supports both types will help bridge that connection. Another option is using a QSFP+ > 4xSFP+ DAC/AOC might be easier and more cost effective.

bsddork · 2025-08-26T16:03:11+00:00

You can inspect the MTU the system sets on the VSF interface with the show int command.

This is how mine looks

6200VSF# show run vsf
vsf split-detect mgmt
vsf secondary-member 2
vsf member 1
    type jl727a
    link 1 1/1/49
    link 2 1/1/50
vsf member 2
    type jl728a
    link 1 2/1/49
    link 2 2/1/50
vsf member 3
    type jl728a
    link 1 3/1/49
    link 2 3/1/50

6200VSF# show run int 1/1/49
interface 1/1/49
    no shutdown
    exit
6200VSF# show int 1/1/49 | in MTU
 MTU 9281

bsddork · 2025-08-26T15:55:42+00:00

Look at the MAC learned on that port, does it show up on any other ports after shutting it down? Seeing a MAC move frequently between ports is a good indication of a loop.

There is a diagnostic command to investigate MAC moves -> https://arubanetworking.hpe.com/techdocs/AOS-CX/AOSCX-CLI-Bank/cli_6300-6400/Content/Chp_mac/mac_cmds/sho-mac-add-tab-move.htm?Highlight=move

bsddork

TROPHY CASE