Linux Networking Configuration in the Enterprise: RHEL, SUSE, Ubuntu and CIDR

Linux networking is one of those areas where the underlying concepts remain remarkably stable while the administration tools continue to evolve. Whether you are working with Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Ubuntu Server, or a cloud-focused distribution, the fundamentals are the same: Interface → IP address → subnet → routing → gateway → DNS → applications. What changes between distributions is how these settings are declared, stored, activated, and automated.

The Linux Networking Stack

A simplified Linux networking architecture looks like this:

                    Application
                         |
                  TCP / UDP / HTTP
                         |
                    Socket API
                         |
                  Linux Network Stack
                         |
              +----------+----------+
              |                     |
           Routing              Netfilter
           Tables              / Firewall
              |                     |
              +----------+----------+
                         |
                    Network Device
                         |
              +----------+----------+
              |                     |
          Physical NIC          Virtual NIC
              |                     |
           Ethernet          Bridge / VLAN / Bond
              |
            Switch
              |
          Router / Gateway
              |
        Other Networks / Internet

At the lowest level, the Linux kernel manages interfaces, addresses, routes and packet processing.

The primary command-line interface for inspecting this state is ip, provided by the iproute2 package.

ip link
ip addr
ip route

These commands work across virtually all modern enterprise Linux distributions.

ip addr show enp1s0
ip route show
ip route get 8.8.8.8

The distinction between runtime state and persistent configuration is important.

Running:

sudo ip addr add 192.168.10.50/24 dev enp1s0

changes the current kernel networking state.

It does not necessarily create the persistent configuration that will survive a reboot.

That persistent layer is where distributions differ.

RHEL: NetworkManager and nmcli

Modern Red Hat Enterprise Linux uses NetworkManager as its primary networking framework.

RHEL 10 stores NetworkManager connection profiles in keyfile format. The old ifcfg-* format is no longer supported in RHEL 10. Red Hat recommends tools such as nmcli, nmtui, nmstate, and RHEL system roles for network configuration and automation.

Inspect the current configuration

nmcli device status
nmcli connection show
nmcli connection show "Wired connection 1"

Typical output:

DEVICE   TYPE      STATE      CONNECTION
enp1s0   ethernet  connected  Internal-LAN
lo       loopback  unmanaged  --

Configure a static IPv4 address

sudo nmcli connection add \
    type ethernet \
    con-name Internal-LAN \
    ifname enp1s0 \
    ipv4.method manual \
    ipv4.addresses 192.168.10.50/24 \
    ipv4.gateway 192.168.10.1 \
    ipv4.dns "192.168.10.10 1.1.1.1"

Activate it:

sudo nmcli connection up Internal-LAN

Verify:

ip addr show enp1s0
ip route
nmcli connection show Internal-LAN

The important conceptual point is that nmcli modifies a connection profile, while ip shows the resulting kernel networking state.

Add a static route

sudo nmcli connection modify Internal-LAN \
    +ipv4.routes "10.20.0.0/16 192.168.10.1"

Then reactivate the connection if required:

sudo nmcli connection up Internal-LAN

RHEL also supports more advanced configurations such as bonding, VLANs, bridges, routing rules and policy-based routing.

For automation, nmstate and RHEL system roles are particularly useful.

SUSE: NetworkManager in SLES 16

SUSE Linux Enterprise Server has historically used the wicked networking service extensively. However, current SLES 16 documentation uses NetworkManager as the networking management framework and provides nmcli and nmtui for administration.

Check the service:

systemctl status NetworkManager

Check devices:

nmcli device status

Check connection profiles:

nmcli connection show

Configure a static address

sudo nmcli connection modify eth0 \
    ipv4.method manual \
    ipv4.addresses 192.168.20.50/24 \
    ipv4.gateway 192.168.20.1 \
    ipv4.dns "192.168.20.10 1.1.1.1"

Bring the connection online:

sudo nmcli connection up eth0

Verify:

ip addr show eth0
ip route
nmcli networking connectivity

SLES therefore looks increasingly familiar to administrators coming from RHEL.

However, when troubleshooting an existing SLES installation, do not assume which networking service is active. Always check first.

systemctl is-active NetworkManager
systemctl is-active wicked

Ubuntu Server: Netplan as the Declarative Layer

Ubuntu Server takes a different approach.

Modern Ubuntu uses Netplan as the high-level declarative networking layer. Netplan generates configuration for a backend such as systemd-networkd or NetworkManager.

This gives administrators a YAML-based configuration model.

network:
  version: 2

  ethernets:
    enp1s0:
      addresses:
        - 192.168.30.50/24

      routes:
        - to: default
          via: 192.168.30.1

      nameservers:
        addresses:
          - 192.168.30.10
          - 1.1.1.1

Save the configuration under:

/etc/netplan/

For example:

/etc/netplan/01-network.yaml

Apply the configuration:

sudo netplan apply

For safer remote administration, especially over SSH, netplan try can be useful because it provides a rollback mechanism if the new configuration is not confirmed.

sudo netplan try

Verify:

netplan status
ip addr
ip route

Ubuntu 26.04 LTS includes Netplan 1.2, continuing the declarative networking model. Netplan can work with both systemd-networkd and NetworkManager as renderers.

RHEL vs SUSE vs Ubuntu: Administrator Cheat Sheet

The key takeaway is that the kernel-level commands are largely common, while the persistent configuration layer differs.

CIDR: The Most Important Networking Notation

CIDR stands for Classless Inter-Domain Routing.

Instead of representing a network using a traditional subnet mask:

192.168.10.50
255.255.255.0

CIDR expresses the same information as:

192.168.10.50/24

The /24 represents the number of bits used for the network prefix.

For IPv4:

IPv4 address = 32 bits

192.168.10.50/24

Network bits = 24
Host bits    = 8

Therefore:

Network:      192.168.10.0
First host:   192.168.10.1
Last host:    192.168.10.254
Broadcast:    192.168.10.255

For a traditional IPv4 subnet, the number of addresses is:

2^(32 - prefix)

For /24:

2^(32-24) = 256 addresses

For /26:

2^(32-26) = 64 addresses

For /30:

2^(32-30) = 4 addresses

The usable host count for a conventional IPv4 subnet is normally two fewer than the total because the network and broadcast addresses are reserved.

CIDR Cheat Sheet

CIDR is not limited to host configuration.

It appears everywhere in modern infrastructure:

Linux routes
AWS VPCs
Azure VNets
Kubernetes networks
Docker networks
Firewalls
Load balancers
VPNs
BGP
Cloud security groups

Understanding CIDR therefore becomes a foundational skill for both Linux administration and cloud engineering.

A Practical Enterprise Network Example

Consider a server with the following configuration:

Server IP:       10.10.20.50/24
Gateway:         10.10.20.1
DNS:             10.10.10.10
Application:     TCP/443

The network architecture might look like this:

                         Internet
                            |
                       Edge Firewall
                            |
                     10.10.10.1/24
                            |
                    Core Router / L3
                            |
              +-------------+-------------+
              |                           |
        10.10.10.0/24              10.10.20.0/24
              |                           |
          DNS Server                  Linux Server
       10.10.10.10                 10.10.20.50
                                          |
                                     TCP/443
                                          |
                                      Application

When the application server sends traffic to 10.10.10.10, Linux examines its routing table.

ip route get 10.10.10.10

If the destination is outside the local 10.10.20.0/24 network, Linux forwards the packet towards the configured gateway.

This is the fundamental relationship between CIDR and routing.

Linux Networking Troubleshooting Workflow

When a server cannot communicate with another host, do not immediately start modifying configuration files.

Work from the bottom up.

Step 1: Is the interface up?

ip link show

Look for:

state UP

Step 2: Does the interface have the expected IP?

ip addr show enp1s0

Check:

192.168.20.50/24

Step 3: Is the route present?

ip route

You should see something similar to:

default via 192.168.20.1 dev enp1s0
192.168.20.0/24 dev enp1s0 proto kernel scope link

Step 4: Can the server reach the gateway?

ping 192.168.20.1

Step 5: Can it reach the destination?

ping 10.10.10.10

Step 6: Which route will Linux actually use?

ip route get 10.10.10.10

This command is particularly useful on multi-interface servers.

Step 7: Is DNS working?

resolvectl status
getent hosts example.com

Step 8: Is the application listening?

ss -lntup

For HTTPS:

ss -lntp | grep ':443'

Step 9: Check packet flow

When required:

sudo tcpdump -ni enp1s0 host 10.10.10.10

This lets you determine whether packets are actually entering or leaving the interface.

The Troubleshooting Decision Tree

A practical troubleshooting sequence can be visualised as:

                 Application unavailable
                          |
                          v
                  Is service running?
                    /           \
                  No             Yes
                  |               |
             Fix service          v
                              Is port listening?
                               /          \
                             No            Yes
                             |              |
                        Fix application     v
                                      Check firewall
                                           |
                                           v
                                     Check DNS
                                           |
                                           v
                                     Check routing
                                           |
                                           v
                                   Check gateway
                                           |
                                           v
                                   Check interface
                                           |
                                           v
                                   Check physical/
                                  virtual connectivity

This approach avoids changing five configuration layers when only one is broken.

Static Routes: Where CIDR Meets Real Networking

Suppose the server has:

Interface:  enp1s0
Address:    10.10.20.50/24
Gateway:    10.10.20.1

But an internal application network exists at:

10.50.0.0/16

The administrator can add a route.

On RHEL or SLES using NetworkManager:

sudo nmcli connection modify Internal-LAN \
    +ipv4.routes "10.50.0.0/16 10.10.20.1"

The resulting routing table might contain:

10.10.20.0/24 dev enp1s0
10.50.0.0/16 via 10.10.20.1 dev enp1s0
default via 10.10.20.1 dev enp1s0

Linux now knows that traffic destined for 10.50.0.0/16 should use the specified next hop.

Why Engineers Should Understand the ip Command

Distribution-specific tools change.

The ip command has remained a common interface to Linux networking.

These commands are worth memorising:

ip link
ip addr
ip route
ip neigh
ip route get 
ip -4 addr
ip -6 addr
ip -4 route
ip -6 route

For example:

ip route get 10.50.20.25

can immediately answer:

Which interface?
Which gateway?
Which source IP?
Which route?

That makes it one of the most useful commands for troubleshooting multi-homed Linux servers.

Enterprise Networking Is Moving Beyond Simple IP Configuration

Modern Linux servers increasingly participate in more complex network architectures:

                Cloud / Data Centre
                        |
              +---------+---------+
              |                   |
           VLANs               VXLAN
              |                   |
          Bonding              Bridges
              |                   |
          Linux NICs          Containers
              |                   |
              +---------+---------+
                        |
                    Linux Kernel
                        |
              +---------+---------+
              |                   |
           Routing            Netfilter
              |                   |
          Applications       Firewall

The same fundamentals continue to apply.

An interface still has an address.

An address still belongs to a CIDR prefix.

Packets still follow routes.

A gateway is still a next-hop device.

DNS still translates names into addresses.

The complexity is primarily in how these components are combined.

Final Takeaway

Linux networking administration is becoming less about memorising distribution-specific configuration files and more about understanding the networking model.

For RHEL administrators, learn:

NetworkManager
nmcli
nmstate
RHEL system roles

For SLES administrators:

NetworkManager
nmcli
nmtui
SUSE networking architecture

For Ubuntu administrators:

Netplan
YAML
systemd-networkd
NetworkManager
cloud-init

For everyone:

ip
ss
ping
ip route
ip neigh
tcpdump
CIDR
DNS
routing

The most valuable skill is not knowing where an IP address is stored on a particular distribution.

It is being able to answer these questions quickly:

• What interface am I using?
• What IP address and CIDR prefix does it have?
• Which route will Linux select?
• What is the next hop?
• Can I reach the gateway?
• Can I resolve the destination name?
• Is the application actually listening?

Once those questions become second nature, moving between RHEL, SLES, Ubuntu, cloud platforms, virtual machines and containers becomes much easier.

Linux networking changes at the tooling layer.

The fundamentals do not.