Learn › RHCSA (EX200) › Basic Networking
nmcli - a hands-on Linux lab on a real virtual machine.
Give a RHEL 10 server a persistent static IPv4 address with nmcli, the tool that survives a reboot where ip addr add does not. Build the whole connection in one line with nmcli con add (type, ifname, con-name, ipv4.method manual, ipv4.addresses IP/prefix, ipv4.gateway, ipv4.dns), list profiles with nmcli con show and devices with nmcli dev status, read back and verify the four ipv4. lines with nmcli con show NAME, change a value later with nmcli con mod, and apply edits with nmcli con up. Serves EX200 networking: configure IPv4 and IPv6 addresses.
It is exam hour. The task says: give this server the static address 192.168.50.10, gateway 192.168.50.1, DNS 192.168.50.53, and make it survive a reboot. You know ip addr add from Foundations, so you type it, the address appears, and you move on. Then the grader reboots the machine and your address is gone. Zero points. The ip command sets an address in the running kernel only. Nothing wrote it to disk, so the reboot wiped it clean.
On RHEL 10, the tool that makes network settings persist is nmcli, the command-line front end for NetworkManager. NetworkManager is the service that owns every interface and saves each configuration to a file. This lesson takes you from a raw interface to a fully addressed, persistent static IPv4 connection, then reads it back to prove it. This exact task shows up on the exam, and losing it to a reboot is one of the most common ways people drop points.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2). To avoid cutting the live link, the capture was done on a throwaway interface named dummy0 with a connection named demo. On the exam you run the same command against your real NIC, which is usually named something like ens3 or enp1s0. Interface names, and the interface rows in the listing commands, differ from machine to machine, so read those as illustrative and focus on the SHAPE of each command.
nmcli stands for NetworkManager command-line interface. NetworkManager is the RHEL service that configures and remembers your network. Think of it as the building superintendent: it holds the master keys to every network port, decides which one is switched on, and keeps a written record of each one's settings so nothing is lost overnight.
The record NetworkManager keeps is called a connection, sometimes called a connection profile. A connection is a named bundle of settings (address, gateway, DNS, on-or-off-at-boot) that gets attached to a device. The key idea: a device is the physical port, a connection is the saved configuration you bind to it. You configure connections with nmcli, and NetworkManager writes each one to a file so it comes back after a reboot.
You reach for nmcli any time a network setting has to outlive the current boot. Setting a server's permanent address, pointing it at the right DNS resolver, changing a gateway: all of it goes through nmcli so NetworkManager can save it. The ip command is still useful for a quick look or a throwaway test, but it never persists.
There is a second reason it matters on the exam: nmcli is fully scriptable and non-interactive. One long command creates a whole connection with its address, gateway, and DNS in a single line, no menus, no editor. That is exactly what a timed practical rewards. Learn the one-line form and you can build a static connection from memory in seconds.
The workhorse is nmcli con add. In one command you name the connection, bind it to a device, and set every IPv4 property. Read the pieces left to right. type is the kind of device, ifname is the interface to bind to, and con-name is the name you give this profile. Then ipv4.method manual means a static address (not DHCP), and ipv4.addresses, ipv4.gateway, and ipv4.dns carry the values. The address is written as IP/prefix, so 192.168.50.10/24 is the address plus its subnet mask.
Create a static connection named demo. On this sandbox it binds to a dummy0 interface so the live link stays up:
nmcli con add type dummy ifname dummy0 con-name demo ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1 ipv4.dns 192.168.50.53
prompt: [root@servera ~]# answer: nmcli con add type dummy ifname dummy0 con-name demo ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1 ipv4.dns 192.168.50.53 output: hint: The builder is nmcli con add, then type, ifname, con-name, ipv4.method manual, and the ipv4.addresses/gateway/dns values.
The command prints nothing extra beyond a one-line confirmation, which means it worked: NetworkManager created a connection profile named demo, bound it to dummy0, and saved it to disk with the static address, gateway, and DNS you supplied. ipv4.method manual is the switch that makes it static; leave it out and the connection would try DHCP instead. Every value went in from one line, no interactive prompts. That single-line habit is what earns the marks under time pressure.
On a real exam machine you swap two words and nothing else. Instead of type dummy ifname dummy0 you write type ethernet ifname ens3, using your real NIC's name (find it with nmcli dev status or ip link). So the exam form reads: nmcli con add type ethernet con-name static0 ifname ens3 ipv4.method manual ipv4.addresses A.B.C.D/NN ipv4.gateway ... ipv4.dns .... The dummy type here only exists so this sandbox can teach the command without dropping the live connection. Your interface name will differ.
Now list what NetworkManager knows about. nmcli con show prints every connection profile. The plain form prints a wide table; adding -t -f NAME,DEVICE,TYPE makes it terse and picks just three fields, which is easier to read. -t means terse (colon-separated, one line each) and -f means fields, followed by the columns you want.
List the connections, showing name, device, and type:
nmcli -t -f NAME,DEVICE,TYPE con show
prompt: [root@servera ~]# answer: nmcli -t -f NAME,DEVICE,TYPE con show output: Wired connection 1:ens3:802-3-ethernet demo:dummy0:dummy lo:lo:loopback enp1s0::802-3-ethernet hint: The lister is nmcli con show; add -t for terse and -f NAME,DEVICE,TYPE to pick the columns.
Each line is one connection in NAME:DEVICE:TYPE form because -t used a colon separator. Your new demo:dummy0:dummy row is right there: the connection you just built, bound to dummy0. Above it, Wired connection 1:ens3:802-3-ethernet is this image's real primary NIC. The enp1s0::802-3-ethernet row has an empty device field, meaning that interface has a profile but is not currently bound. On your machine the real NIC name and the exact rows will differ; what stays true is that your new connection appears by the name you gave it.
nmcli con show lists profiles; nmcli dev status lists the actual hardware devices and which connection each one is running. This is the view that answers is this interface up, and what is it running. It prints four columns: DEVICE (the interface), TYPE, STATE (connected or not), and CONNECTION (the active profile on it).
Check the device status:
nmcli dev status
prompt: [root@servera ~]# answer: nmcli dev status output: DEVICE TYPE STATE CONNECTION ens3 ethernet connected Wired connection 1 dummy0 dummy connected demo lo loopback connected lo hint: The device view is nmcli dev status; it lists DEVICE, TYPE, STATE, and CONNECTION.
Four columns, one row per device. The dummy0 dummy connected demo row proves your work landed: the dummy0 device is connected and running the demo connection you built. The ens3 row shows the real NIC connected to Wired connection 1, and lo is the loopback that is always present. STATE reads connected when a device has an active connection bound and up. This command is how you find your NIC's real name on the exam, since the DEVICE column names every interface the machine has.
Give nmcli con show a connection name instead of no argument and it dumps every property of that one connection, dozens of lines. To verify a static IPv4 setup you care about four of them: ipv4.method, ipv4.addresses, ipv4.gateway, and ipv4.dns. On the exam you scroll to those lines (or pipe through grep ipv4) and confirm each value matches the task.
Read back the demo connection and confirm its IPv4 block:
nmcli con show demo
prompt: [root@servera ~]# answer: nmcli con show demo output: ipv4.method: manual ipv4.addresses: 192.168.50.10/24 ipv4.gateway: 192.168.50.1 ipv4.dns: 192.168.50.53 hint: Give nmcli con show a name to dump that one profile; the four ipv4. lines are what you verify.
These four lines are the whole verification. ipv4.method: manual confirms the connection is static, not DHCP. ipv4.addresses: 192.168.50.10/24 is the address and prefix you set. ipv4.gateway: 192.168.50.1 is the default route, and ipv4.dns: 192.168.50.53 is the resolver. When a task says configure a static address and verify, this readout, matched against what was asked, is the verify. The full output has many more lines; these four are the ones that answer the question.
Setting values on a connection is not the same as applying them. A brand-new connection from con add usually activates on its own. But after you EDIT an existing one with nmcli con mod, the change is written to disk while the live interface keeps its old settings. It stays that way until you run nmcli con up demo, which re-activates the connection and loads the new values. The classic exam slip is to con mod an address, never run con up, then wonder why the interface still shows the old one. Modify, then bring it up.
To change one property of a connection that already exists, use nmcli con mod, short for modify. The shape is nmcli con mod NAME property value. You do not rebuild the whole connection; you touch just the field that changed. To swap the static address on demo to a new one you would write nmcli con mod demo ipv4.addresses 192.168.50.20/24, then apply it with nmcli con up demo from the warning above.
con mod is also how you switch a DHCP connection to static: set ipv4.method manual and the addresses in the same or separate con mod calls. Because it edits in place, con mod is the everyday tool for fixing a wrong gateway or updating a DNS server without disturbing the rest of the profile.
Scaffolding off. No command is printed this time. You have every piece you need.
You just built a connection called demo. The task tells you to prove it really carries the static settings you were asked for: method manual, address 192.168.50.10/24, the right gateway, and the right DNS, all in one readout. You do not want the wide list of every connection, and you do not want the device table. You want the full property dump of that one connection, demo, so you can read its four ipv4. lines. Which single command prints it?
prompt: [root@servera ~]# answer: nmcli con show demo output: ipv4.method: manual ipv4.addresses: 192.168.50.10/24 ipv4.gateway: 192.168.50.1 ipv4.dns: 192.168.50.53 hint: It is nmcli con show with the connection NAME after it, not the terse list and not dev status: nmcli con show demo.
nmcli con show demo dumps every property of the demo connection, and the four ipv4. lines are the ones that answer the task: method manual, addresses 192.168.50.10/24, gateway 192.168.50.1, dns 192.168.50.53. Bare nmcli con show would have listed all connections without their details, and nmcli dev status would have shown devices, not this profile's IPv4 block. When a task says configure and verify, nmcli con show NAME is what earns the verify.
You earned this cheat sheet. Every row is a form you just ran or built:
The one thing to burn in for the exam: ip addr add is temporary and dies at reboot; only nmcli persists. Set ipv4.method manual for a static address, and after any con mod run con up to apply it.
On the exam you rarely know your NIC's name ahead of time. Run nmcli dev status first, read the real DEVICE name from the table, and use that exact name for ifname. Then verify with nmcli con show NAME before you move on. Guessing the interface name is a common way to waste minutes.
The practice terminal walked you through the whole loop. nmcli con add to build a persistent static connection in one line, nmcli -t -f NAME,DEVICE,TYPE con show to list your profiles, nmcli dev status to map connections onto real devices, nmcli con show NAME to read back and verify the four IPv4 lines, and nmcli con mod plus nmcli con up to change a value later and apply it. Every one of those you typed yourself.
Operation Uplink is where you run these against a real RHEL 10 machine. A full VM boots for you, with its own real interfaces waiting to be configured. The mission hands you objectives that use exactly what you practiced here. Find the interface name, build a static IPv4 connection with the right address, gateway, and DNS, and verify it with nmcli con show. One difference from this lesson: the mission shows no commands. You read the objective, recall the nmcli con add and con show forms, and type them. That recall is what makes it stick on exam day.
Finish the other basic-networking lessons, then go configure a real interface in Operation Uplink.
Practice nmcli: Static IPv4 Configuration in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.