Dell OS10 Switch Management: Static IP, Users and Routes

Out-of-band management is the lifeline of every production switch, yet it is often the least documented part of an initial deployment. This guide walks through the Dell SmartFabric OS10 procedure for setting up the management interface with a static IP, adding a default management route, and creating role-based admin accounts — the exact steps from the official Dell knowledge base, with verification commands for each stage.

The reason to care is simple arithmetic. A switch that is reachable only in-band becomes unreachable at exactly the moment you need it most: when the data path is broken and you are trying to fix it. A correctly built out-of-band management interface means every future incident starts with a working SSH session instead of a drive to the building.

OS10 Management Interface Basics

Dell PowerSwitch S-series switches running OS10 boot with the management interface (mgmt 1/1/1) in DHCP mode by default. Before the switch can be managed remotely over the out-of-band network, the interface needs a stable address and a route to the management network.

DHCP on a management interface is fine on the bench and wrong everywhere else. An address handed out by a lease can change after a power event, the DHCP server becomes a dependency for access to the device, and a lease mismatch is a support call waiting to happen. A static address, a documented management route and a named admin account are the three things that turn a switch into a manageable device.

The management interface on OS10 is deliberately separate from the data plane: it lives in its own routing context, uses its own route table, and never forwards traffic for the network. That separation is what makes it reliable, and it is also the source of most configuration confusion, because a normal static route does not affect management reachability at all.

Step 1: Configure a Static IP on the Management Interface

OS10# configure terminal
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 10.20.30.5/24
OS10(conf-if-ma-1/1/1)# exit
OS10(config)# management route 0.0.0.0/0 10.20.30.1
OS10(config)# end

Two details in that block matter. First, no ip address dhcp must come before the static address, because the interface cannot be in both modes; leaving DHCP in place produces an interface that appears configured but keeps getting overwritten. Second, the management route is a separate command at global configuration level, not a static route inside a VRF — the next-hop must be on the same subnet as the management interface or the route is rejected silently.

If the management subnet uses IPv6, the same interface accepts a v6 address alongside the v4 one, and management routes can be configured for both families. Keeping v6 disabled with no ipv6 enable on the management interface is a reasonable default until you have a use for it, since an autoconfigured address is one more thing that can drift.

Step 2: Verify the Management Configuration

OS10# show running-configuration interface mgmt 1/1/1
! interface mgmt1/1/1
  no shutdown
  no ip address dhcp
  ip address 10.20.30.5/24
OS10# show running-configuration management-route
! management route 0.0.0.0/0 10.20.30.1

The management route is separate from the data-plane routing table in OS10 — it must be configured under the global management route command, not as a regular static route. Three more commands complete the picture and are worth running before you close the session:

OS10# show interface mgmt 1/1/1
OS10# show ip interface brief
OS10# show ip route management
OS10# ping 10.20.30.1
OS10# ping 10.20.30.1 source 10.20.30.5

Pinging without a source tests your reachability to the gateway; pinging with source tests the switch's own management path, which is the check that actually matters. If the first succeeds from your workstation and the second fails, the problem is the management route rather than the interface addressing.

Step 3: Create Role-Based Admin Accounts

OS10 ships with default credentials (admin/admin) which must never remain in production. Create named accounts with the role keyword, choosing from sysadmin, netadmin, secadmin or netoperator depending on the job function:

OS10(config)# username test password P@ssw0rd!123 role sysadmin

Each role is deliberately scoped. sysadmin can do everything, including user and file management. netadmin covers network configuration — interfaces, routing, switching — but not security policy or user accounts. secadmin covers security-relevant configuration such as AAA, certificates and user management, but not the data-plane protocols. netoperator is effectively read-only monitoring: it can run show commands and perform limited operations such as copy, but cannot change the configuration.

In practice this maps cleanly onto job functions: one or two sysadmin accounts for break-glass access, netadmin for the network team, secadmin for whoever owns AAA and certificates, and netoperator for the NOC and for monitoring integrations. Every operator having sysadmin rights is the common shortcut and the common audit finding.

OS10(config)# end
OS10# show running-configuration users
username test password **** role sysadmin priv-lvl 15

Notice that the running configuration never shows the password in clear text. That is expected: OS10 stores a hash, and the **** in the output is the same on every switch. If a stored credential must be changed, apply a new username ... password statement rather than trying to read the old one back.

Step 4: Enable Remote Access and Harden the Device

With addressing working, the remaining work is making remote access secure and the device observable. Enable SSH and disable the legacy protocols:

OS10(config)# ip ssh server enable
OS10(config)# no telnet server enable
OS10(config)# login banner "Authorized access only"

Then set the operational basics that turn a device on the network into a device the team can operate. A hostname, an accurate clock and a syslog destination are the three that pay back immediately, because they make every subsequent log line traceable:

OS10(config)# hostname SW-ACC-01
OS10(config)# clock timezone UTC 0
OS10(config)# ntp server 10.20.30.20
OS10(config)# logging server 10.20.31.10
OS10(config)# logging source-interface mgmt 1/1/1

Sourcing syslog from the management interface keeps management-plane logs on the management network, which matters when the data plane is the thing that is broken. Always persist the configuration with write memory afterwards — an unsaved management address is a switch you cannot reach after the next reload.

Troubleshooting Management Connectivity

When the switch is not reachable, work through the layers rather than restarting things. Confirm the interface is up and has the expected address with show interface mgmt 1/1/1. Confirm the route exists with show ip route management. Confirm the upstream gateway is reachable with ping source. Confirm the SSH service is enabled and the login account is not locked. Confirm the management VLAN on the upstream switch has the address it expects, since a management interface on the wrong VLAN looks identical to a dead switch from the far end.

Two OS10-specific traps are worth knowing. First, a management route whose next hop is not on the management subnet is accepted into the configuration and simply never used — the syntax is valid, the route is inert. Second, write memory is what copies the running configuration into the startup configuration, so any change made without it exists only until the next reload. Both are avoidable with the verification commands above.

Designing the Out-of-Band Network Around It

The switch configuration is only half the job; the management network it plugs into matters just as much. The usual design gives each switch a loopback-style static management address on a dedicated management VLAN that terminates on a separate management core or a dedicated port on a firewall, with routing that reaches the management station but never the production data plane. That isolation is what makes the interface worth having: a routing failure or a spanning-tree meltdown in production does not touch the path you need to repair it.

Configuration-wise, the management interface sits in its own routing context on OS10, which is why it never appears in the data-plane routing table. The practical consequence is that you configure two things independently: addresses and routes for the data plane, and a separate address plus management route statements for the out-of-band side. Teams that expect a single default route to serve both are the ones who discover the difference during an outage.

Two design details are easy to get wrong. Do not reuse the production VLAN as the management VLAN — the whole point is independence, and sharing it means every data-plane change risks your access. And do keep the management address plan documented in the same system of record as the data-plane plan, because a management address that only exists in someone's notes is functionally unavailable the moment that person is on leave.

Management Access Verification Checklist

Before handing the switch to operations, walk this list and confirm each answer matches the design: the management interface is administratively up with the intended static address; DHCP is disabled on it; a management route exists to the management network's gateway; a ping sourced from the switch to that gateway succeeds; SSH is enabled and Telnet is disabled; a named admin account exists with the correct role and the default admin password has been changed; NTP is configured so log timestamps are trustworthy; syslog is pointed at a collector; and write memory has been run so the startup configuration matches the running one. The last item on that list prevents the most common post-deployment call there is — a switch that behaves perfectly until the first reload and then comes back on DHCP.

Next Steps

Always persist the configuration with write memory. For production deployments, pair this setup with SNMPv3 monitoring configuration and review the transaction-based configuration mode before making large changes — it lets you review a candidate config before it touches the running configuration.

Related: OS10 quick start on the S5212F-ON and the dedicated walkthrough for the OS10 default gateway and management route.

原文链接：https://www.dell.com/support/kbdoc/en-us/000201924/dell-emc-networking-os10-basic-switch-management-configuration