Today I encountered a scenario in which an HPE Aruba ProCurve switch (AOS-S), used as an access switch in a classic three-tier network topology, declares certain VLANs (in this case, VLAN 16) as root bridges. However, on the core switch, all VLANs are configured with a spanning tree priority of 4096 — see VLANs 12 and 53.

  VLAN  Root Mac        Root       Root       Root                 Hello
  ID    Address         Priority   Path-Cost  Port                 Time(sec)
  ----- --------------- ---------- ---------- -------------------- ---------
  1     f8f8f8-c3c3c3   32,768     0          This switch is root  2
  998   f8f8f8-c3c3c3   32,768     0          This switch is root  2
  999   f8f8f8-c3c3c3   32,768     0          This switch is root  2
  53    1bfdec-1bfdec   4096       2250       Trk1                 2
  12    1bfdec-1bfdec   4096       2250       Trk1                 2
  16    f8f8f8-c3c3c3   32,768     0          This switch is root  2

If you think about it, the reason is relatively clear. All VLANs that have been created on the switch participate in Rapid Per-VLAN Spanning Tree formation and also send different BPDUs per VLAN over a trunk link. If the VLAN is not permitted on the trunk, the BPDUs for that VLAN will never be sent over the trunk and therefore cannot negotiate with the neighboring switch to determine who will be the root bridge.

The startup configuration can be bypassed by booting into ROMMON or during normal operation. In either case, a reboot is required.

This is particularly useful, for example, if you need to perform a password recovery because you have forgotten your password, or for troubleshooting purposes.

Configuration in IOS

Switch# configure terminal
! to activate
Switch(config)# system ignore startup-config

! to deactivate
Switch(config)# no system ignore startup-config

Configuration in ROMMON

In the background, the IOS command simply sets the ROMMON variable SWITCH_IGNORE_STARTUP_CONFIG to 1 or 0 which we can also do manually.

We had an issue where our domain controller lost its domain network profile after a reboot. When it came back up it was set to public instead of domain.

The problem occurred only when Windows NIC teaming (switch-independent) was used in combination with two network adapters in the team. As soon as one network adapter was disabled from the team (while the other remained active), the network profile (domain) was recognized correctly.