Dell S-Series SONiC 4.0: Basic Switch Management Setup - 夜莺博客

Dell S-Series SONiC 4.0: Basic Switch Management Setup

Dell S-Series open networking switches can run Enterprise SONiC, and the basic management setup is straightforward once you know the right command flow. This guide from the Dell knowledge base walks through the factory-default configuration steps: logging in with the default credentials, starting the SONiC CLI with sonic-cli, assigning a static IP and default gateway to the management interface, verifying the change, and saving it with write memory. The same pattern applies across S-Series platforms running SONiC 4.0.

The steps are short, but there are three things that trip people up on the first build: remembering that the management port is not a data port and behaves differently, knowing that write memory is what makes a change survive a reload, and being able to tell the Linux shell apart from the SONiC CLI when the prompt changes under you.

Background: SONiC on Dell S-Series

SONiC is an open source network operating system built around a Redis-backed configuration database. Every CLI command you type ultimately writes entries into that database rather than into a monolithic text configuration file, which is why SONiC has no equivalent of a single “show run” that means exactly what it means on IOS. Enterprise SONiC is the commercially supported Dell distribution, and version 4.0 is the release this procedure targets.

The management interface is the out-of-band path you use to reach the switch before any data interfaces are configured. In SONiC it is exposed as Management 0 in the CLI, which maps to the Linux interface eth0 in the underlying system. Data ports are separate objects, which is why the command below is written against Management 0 and not an Ethernet port.

Prerequisites

  • Console access to the switch (serial, USB or a terminal server). A factory-default switch has no reachable IP address, so the console is the only way in.
  • An IP address and prefix for the management port, plus the correct default gateway for that subnet — a wrong gateway is the single most common cause of a switch that “configures fine but cannot be reached”.
  • Default credentials. The factory default is admin with the default password documented by Dell for the platform; you will be prompted to change it on first login.
  • A management VLAN or switch port already provisioned for this device, and a free address in your IPAM.
  • The switch patched and powered for at least a couple of minutes so the container-based services have finished starting.

Step 1: Logging In and Starting the SONiC CLI

Debian GNU/Linux 9 sonic ttyS0

sonic login: admin
Password:
...
-- Software for Open Networking in the Cloud --

admin@sonic:~$ sonic-cli
sonic#

Two prompts are worth recognising immediately. The admin@sonic:~$ prompt is the ordinary Linux shell underneath — useful for log files, docker commands and troubleshooting, but not where you configure the switch. Typing sonic-cli moves you into the network CLI, and its prompt is sonic# in exec mode. If you are ever unsure which world you are standing in, exit returns you to the Linux shell.

Before changing anything, capture the current state so you have a reference point for the rest of the build:

sonic# show version
sonic# show interfaces status
sonic# show ip interface
sonic# show running-configuration

Step 2: Configuring the Management Interface

Enter configuration mode and check the current management interface state:

sonic# configure terminal
sonic(config)# interface Management 0
sonic(conf-if-eth0)# ip address 1.1.1.2/24 gwaddr 1.1.1.1
sonic(conf-if-eth0)# end

Note the prompt change to sonic(conf-if-eth0): the CLI is telling you that Management 0 and the Linux eth0 are the same object. The gwaddr keyword is specific to the management interface and is the reason you do not need a separate static route entry to reach the rest of the world from the out-of-band path.

If you need to replace an existing address rather than add one, remove the old one first and then apply the new one, checking the syntax with tab completion in your own build:

sonic(config)# interface Management 0
sonic(conf-if-eth0)# no ip address
sonic(conf-if-eth0)# ip address 1.1.1.2/24 gwaddr 1.1.1.1
sonic(conf-if-eth0)# end

Step 3: Verifying and Saving

sonic# show running-configuration interface Management 0
!
interface Management 0
 description Management0
 mtu 1500
 autoneg on
 speed 1000
 ip address 1.1.1.2/24 gwaddr 1.1.1.1
sonic#
sonic# write memory

The gwaddr parameter sets the default gateway in one line, and write memory persists the running configuration to startup configuration so the management IP survives a reboot. This is the step people skip. On SONiC the running configuration and the saved configuration are genuinely different things — a perfectly working management address that was never written to memory is gone after the next reload, and you are back on the console wondering what happened.

Verifying Connectivity End to End

Do not declare success from a single show command. Work outwards from the switch.

sonic# ping 1.1.1.1
sonic# ping 8.8.8.8
sonic# show ip route

A successful ping to the gateway but a failure to anything beyond it almost always means the gwaddr value is wrong or points at a device that does not route, not that the interface address is wrong. Then confirm from the other direction: from a workstation on the management network, ping the switch and open an SSH session to it, which proves both layer 3 reachability and that the management service is listening.

ssh admin@1.1.1.2

Finally, reload the switch in a maintenance window and confirm the address comes back on its own. That is the only test that proves persistence, and it is much better to discover a missing write memory during a planned window than during an incident.

Where the Configuration Actually Lives

It helps to know that write memory is writing to the SONiC configuration database rather than to a flat file in the IOS sense. The persisted form is config_db.json, and knowing how to save, reload and replace that file safely is the difference between a clean restore and a switch that boots into an unexpected state. See SONiC config_db.json: Save, Reload and Replace Safely for that workflow, and SONiC CLI Cheat Sheet: Management VRF and Database Commands for the management-side command surface.

Why the Management Port Is Separate

The management interface sits in its own routing context — a management VRF — which is why it can hold an address, a gateway and a route table that have nothing to do with the data plane. The practical consequences are worth knowing on day one. Front-panel routes and protocols such as BGP or OSPF do not install routes that the management interface can use, so you cannot accidentally advertise or learn a path over the out-of-band port. Equally, a misconfigured data-plane default route will not knock you off the switch, because the management path is not part of that routing table. That separation is the reason a switch that has lost all its data-plane connectivity is still reachable for remediation.

Addressing is also handled differently. The gwaddr keyword attaches the next hop directly to the interface, which is why the procedure above never asks you to create a static route. On a switch with a large multi-VRF configuration this keeps the out-of-band path simple and independent of everything else you build later.

Recovering a Switch You Cannot Reach

If the management address is lost or a change was saved incorrectly, the console is the recovery path and nothing has been destroyed — the configuration still exists, you simply cannot reach it over the network. Connect to the serial console, log in with a local account, enter sonic-cli, and inspect the current state before changing anything:

sonic# show running-configuration interface Management 0
sonic# show ip interface
sonic# show version

Then re-apply a correct address and gateway and save:

sonic# configure terminal
sonic(config)# interface Management 0
sonic(conf-if-eth0)# ip address 1.1.1.2/24 gwaddr 1.1.1.1
sonic(conf-if-eth0)# end
sonic# write memory

If the device has been made unreachable by a configuration database change rather than by the management address alone, the recovery procedure is a database-level operation rather than a CLI fix, which is exactly the scenario the config_db.json workflow above is written for. Keep a copy of a known-good management configuration on your workstation for every switch model you operate — it turns a console session under pressure into a copy and paste.

Rollback and Recovery

Because the management address is a single object, rolling back is a matter of replacing it and saving again.

sonic# configure terminal
sonic(config)# interface Management 0
sonic(conf-if-eth0)# no ip address
sonic(conf-if-eth0)# ip address 10.0.0.5/24 gwaddr 10.0.0.1
sonic(conf-if-eth0)# end
sonic# write memory

Keep the console cable connected until you have confirmed the new address from a second host — if you change the management IP and save a typo, the console is your only way back. For a full reset, SONiC supports reverting to a known configuration database and, at the extreme, reinstalling or factory resetting the platform through ONIE. The general SONiC troubleshooting and recovery paths are covered in SONiC Troubleshooting: Packet Drops and Link Issues, and the equivalent first-build procedure for the other Dell open networking operating system is in Dell OS10 Basic Switch Management: CLI Configuration Guide.

Common Issues and FAQ

The interface will not accept the address. Check the prefix length — 1.1.1.2/24, not 1.1.1.2 — and confirm you are actually inside the interface Management 0 context by reading the prompt.

The address is configured but disappears after reboot. write memory was not run, or was run in the Linux shell rather than in sonic-cli. Re-enter the CLI, verify with show running-configuration interface Management 0, and save again.

Ping to the gateway works, nothing else does. The gwaddr is wrong or the upstream device is not routing that subnet. This is a routing problem, not a switch problem.

What is the difference between the two prompts? admin@sonic:~$ is Debian Linux; sonic# is the SONiC network CLI started by sonic-cli. Configuration changes belong in the second one.

Which interfaces should I use for data traffic? Not the management port. The Management 0 interface is deliberately outside the switching data path; front-panel ports are configured as Ethernet interfaces with a different command set, covered in the SONiC command references above.

Should I change the default password? Yes, immediately. The switch is on an out-of-band network that usually has weaker monitoring than the production data plane.

Related open-networking topics: the SONiC troubleshooting guide, getting started with Mellanox switches, and setting the management IP on Dell EMC ME4084. If you are new to the CLI itself, SONiC CLI Commands: show, config and sonic-cli Modes and SONiC CLI Cheat Sheet: Show, Config and Config-DB Commands are the natural next reads.

原文链接:https://www.dell.com/support/kbdoc/en-us/000201926/dell-emc-networking-s-series-basic-switch-management-configuration-sonic-4-0