Dell PowerSwitch OS10: Factory Reset and Default Gateway Configuration

Dell PowerSwitch switches running OS10 (OS10 Enterprise Edition) occasionally need a clean slate: a forgotten password, a botched configuration, or a switch being moved to a new site. This guide covers the two practical ways to reset an OS10 switch to factory defaults (CLI reset and full ONIE reinstall) and then walks through re-establishing the management IP address and default gateway so you can manage the switch again. All commands shown are real OS10 CLI commands verified against OS10 10.4/10.5 behavior.

The emphasis here is on the second half of that job. Getting an OS10 switch back to factory defaults is the easy part; proving that the default gateway actually works — and repairing it when it does not — is where most post-reset tickets are spent.

Method 1: Reset to Factory Defaults from the OS10 CLI

The quickest reset keeps the OS10 image in place and only wipes the configuration. OS10 does not use write erase; the correct way is to delete the startup configuration and reload:

OS10# delete startup-configuration
Proceed to delete startup-configuration file [confirm yes/no]: yes
OS10# reload
System configuration has been modified. Save? [yes/no]: no
Proceed to reboot the system? [confirm yes/no]: yes

After the reboot the switch boots with a fresh, empty configuration - no hostname, no users, no interfaces configured. You can confirm with show running-configuration.

Reset the admin Password Only

If you only lost the admin password, boot into the boot menu or use the recovery console to clear it. On many OS10 platforms you can break into the boot menu and select the recovery option that clears the startup configuration while preserving the image.

Method 2: Full Factory Reset via ONIE (Reinstall)

If the OS10 image itself is corrupted, boot into ONIE (Open Network Install Environment) and uninstall OS10, then reinstall:

ONIE:/ # onie-uninstall
ONIE:/ # onie-nos-install http://10.0.0.10/os10_image.bin

ONIE wipes the disk, removes the old image and all configurations, and installs a fresh OS10. This is the most thorough factory reset and is also the documented recovery path when the switch will not boot into OS10.

What the Switch Looks Like Immediately After a Reset

Knowing the default state saves a lot of second-guessing. A freshly reset OS10 switch has:

• Hostname OS10 and the default account admin with password admin.
• No VLANs beyond VLAN 1, no port-channels, no VLT, no routing protocol configuration.
• mgmt 1/1/1 administratively up but in DHCP mode.
• No management route and no static routes of any kind.
• SSH and Telnet unavailable to a remote client until an address exists on the management interface — which is why the console cable is not optional.

Because DHCP is enabled by default, the switch may already have picked up an address from a management DHCP scope. That is a useful bootstrap if the scope exists, but it is not a design: a DHCP-assigned management address on a production switch will change, and the default gateway that came with the lease disappears with it. Replace it with a static address and an explicit gateway before the switch goes into service.

Configuring the Management IP and Default Gateway

After a reset the management interface is unconfigured. OS10's management interface is mgmt1/1/1 on most PowerSwitch models:

OS10# configure terminal
OS10(config)# interface mgmt1/1/1
OS10(conf-if-ma-1/1/1)# ip address 192.168.1.100/24
OS10(conf-if-ma-1/1/1)# no shutdown
OS10(conf-if-ma-1/1/1)# exit

If the interface is still in DHCP mode, remove that statement first so the static address is not overwritten at the next lease renewal:

OS10(config)# interface mgmt1/1/1
OS10(conf-if-ma-1/1/1)# no ip address dhcp
OS10(conf-if-ma-1/1/1)# ip address 192.168.1.100/24
OS10(conf-if-ma-1/1/1)# exit

Default Gateway (Management VRF)

OS10 keeps management traffic in the management VRF. Add a default route that points at your management gateway:

OS10(config)# ip route 0.0.0.0/0 192.168.1.1 management
OS10(config)# end
OS10# write memory

For data-plane (front-panel) routing you would use the plain static route form instead:

OS10(config)# ip route 0.0.0.0/0 10.10.10.1

Both forms are legitimate but they populate different tables. The management form makes the gateway usable by the switch's own control traffic; the plain form makes it usable by routed user traffic. Installing only the plain form is the single most common reason a reset switch answers a ping to its own address but cannot be reached from any other subnet — ping 192.168.1.1 from the switch succeeds, yet the SSH session from the NOC never opens. Dell's own basic-management KB expresses the same gateway with the dedicated management route command, which is the native OS10 spelling and the one to prefer on a flat management network:

OS10(config)# management route 0.0.0.0/0 192.168.1.1

Either way, the next hop has to sit inside the management interface's own subnet and must not equal the directly-connected subnet of the management IP itself.

Verifying the Default Gateway Step by Step

Work the verification as four layers. Each layer isolates one failure mode, so a failure tells you where to look instead of leaving you with a switch you cannot reach.

Layer 1: Is the interface up with the right address?

OS10# show interface mgmt 1/1/1
OS10# show ip interface brief
OS10# show running-configuration interface mgmt 1/1/1

Expect the interface to be up, the address to match what you configured, and — critically — the running configuration to show no ip address dhcp line. A duplicate-address warning here means another device already owns the address and the switch is fighting it; resolve that before going further.

Layer 2: Is the gateway in the management routing table?

OS10# show ip management-route
OS10# show ip route vrf management
OS10# show running-configuration | grep -i management-route

The default route should appear with the next hop you configured. An empty table is the definitive signal that the gateway was never installed — usually because the command was rejected for being out of subnet, or because it was entered in configuration mode but never committed with end and write memory.

Layer 3: Does the gateway answer?

OS10# ping 192.168.1.1 source 192.168.1.100
OS10# ping 192.168.1.1 count 5 interval 1

A successful ping proves the L2 path and the gateway's own configuration. A failure at this layer is a switching or VLAN problem upstream — not a routing problem — and no amount of route configuration will fix it.

Layer 4: Does traffic beyond the gateway flow?

OS10# ping 8.8.8.8 source 192.168.1.100
OS10# traceroute 8.8.8.8 source 192.168.1.100
OS10# show ip route vrf management

Layer 4 is where the default gateway proves itself. The traceroute should show the gateway as the first hop; if the first hop is the management address itself or the trace never leaves the switch, the management route is missing or sitting in the wrong table.

Checking Upstream: Is the Gateway Itself Correct?

Before repairing anything on the switch, confirm the assumption the repair rests on: that 192.168.1.1 really is the management gateway's address. A reset switch that is handed the wrong next hop will fail every layer-3 test while looking perfectly healthy at layers 1 and 2, and the fix is on the network side rather than the switch.

OS10# show ip interface mgmt 1/1/1
OS10# show lldp neighbors interface mgmt 1/1/1
OS10# ping 192.168.1.2 source 192.168.1.100

Three quick signals settle it. LLDP output tells you which device is on the other end of the management link, so you know whether the gateway you configured even lives there. A ping to a second host in the same subnet — the management server, say — proves the L2 path is healthy and isolates the failure to the routed hop. And if a host on another subnet can ping the switch's own management address but the switch cannot ping back, the return path or an access list is dropping the new address, which no amount of local route configuration will fix.

The same reasoning applies to a duplicated address. If the management address was reused from a decommissioned device that was never removed from the network, the switch may hold an address that a neighbouring host also believes it owns; DHCP-assigned addresses from an old lease are the usual culprit after a reset. Check show ip interface mgmt 1/1/1 for duplicate-address notifications and confirm the address is free in the IPAM record before settling on it.

Repair Procedures for the Common Failures

Repairing the Gateway on a Switch You Cannot Reach

When the management gateway is broken badly enough that SSH is gone, repairs happen over the console — and the console is also the fastest place to fix them. The sequence below re-establishes a known-good management path from scratch without touching the rest of the configuration:

OS10# configure terminal
OS10(config)# no management route 0.0.0.0/0
OS10(config)# interface mgmt 1/1/1
OS10(conf-if-ma-1/1/1)# no ip address dhcp
OS10(conf-if-ma-1/1/1)# ip address 192.168.1.100/24
OS10(conf-if-ma-1/1/1)# no shutdown
OS10(conf-if-ma-1/1/1)# exit
OS10(config)# management route 0.0.0.0/0 192.168.1.1
OS10(config)# end
OS10# write memory

Removing the existing gateway before re-adding it avoids stacking two default routes in the management table, which makes the verification inconclusive. If the switch was configured with the management VRF, use the VRF form of the route instead — the differences between the two spellings are laid out in our OS10 default gateway and management route configuration article.

On a switch that needs to be wiped as well as repaired, the file-level factory reset gives the cleanest starting point: deleting startup.xml and dump.rdb from the OS10 bash shell removes configuration objects that a plain delete startup-configuration can leave behind. The procedure and its verification steps are in our OS10 factory reset by deleting configuration files guide.

Common Pitfalls

• Using write erase (IOS habit) does nothing on OS10 - use delete startup-configuration.
• Management default route must include the management keyword or it goes to the default VRF and management traffic stays unreachable.
• After ONIE uninstall the switch boots to the ONIE prompt, not OS10 - this is expected; install the image again.
• Leaving ip address dhcp in place while adding a static management address — the lease renewal wins.
• Forgetting write memory after fixing the gateway, so the repair is lost at the next maintenance reload.
• Assuming the recovery prompt restores defaults: clearing the admin password preserves the rest of the configuration, including a bad gateway.

Post-Reset Verification Checklist

[ ] show running-configuration            -> empty (CLI reset) or defaults
[ ] show interface mgmt 1/1/1             -> up, static address, no DHCP
[ ] show ip management-route              -> 0.0.0.0/0 via the gateway
[ ] ping <gateway> source <mgmt-ip>       -> replies
[ ] ping <far-host> source <mgmt-ip>      -> replies (gateway really works)
[ ] traceroute <far-host>                 -> first hop is the gateway
[ ] write memory                           -> configuration persisted

Run this list from the console, then once more over SSH from a different subnet. A management path that only works from the same subnet is not a management path.

Related reading: Dell OS10 basic switch management configuration and OS10 transaction-based configuration mode.

原文链接：https://infohub.delltechnologies.com/en-us/l/os10-enterprise-edition-10-5-3/