iperf2 vs iperf3: What’s the difference?

At first glance, you might be tempted to use iperf3 simply because it is one more than iperf2 (don’t worry, I’m guilty of this crime as well). It’s not an unfair assumption to think that iperf3 is the most recent version of the software, because of the name. It’s common to have two different versions of software in parallel existence, so the new one can take hold while the older version slowly dies away. Python2 and Python3 come to mind. This is not the case with iperf, however.

I recently wrote a post on how to use iperf3 to test bandwidth. Shortly after that one of the authors of iperf2, Bob McMahon, reached out to me. He pointed out that iperf2 is very much actively developed with some cool new features having been added recently. Under the surface they are very different projects, maintained by different teams with different goals.

Today we’ll take a look at some of the differences between the two.

Topology

Ubuntu 20.04 and Rocky Linux 8.5 VM’s in GNS3

We have a really basic topology here, Ubuntu 20.04 and Rocky Linux 8.5 connected on a single link with IP subnet 10.0.0.0/30. Both VM’s have iperf2 and iperf3 installed.

Bandwidth Test

For a bandwidth test, the two are almost identical. You can perform a bandwidth test using either with the same commands. For this test, the Ubuntu VM will be the client, and Rocky the server. Start the server on Rocky like this:

iperf -s

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

And from Ubuntu perform a test like this:

iperf -c 10.0.0.2
------------------------------------------------------------
Client connecting to 10.0.0.2, TCP port 5001
TCP window size:  238 KByte (default)
------------------------------------------------------------
[  3] local 10.0.0.1 port 36528 connected with 10.0.0.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.90 GBytes  1.63 Gbits/sec

These commands will work using iperf2 or iperf3, however it should be noted you can’t use an iperf2 client with an iperf3 server, and vice-versa. Also, they use different TCP ports by default. Even if you used an iperf3 client with an iperf2 server and manually set the TCP port to be the same, you will get an error. They are not compatible:

iperf3 -c 10.0.0.2 -p 5001
iperf3: error - received an unknown control message

Supported Operating Systems

iperf2 is the clear winner here, primarily because it has up-to-date Windows packages available for easy download right on the sourceforge page. I avoid Windows when I can, but it has a tendency to be unavoidable due to it’s sheer installation base. iperf3 apparently had some unofficial builds a while back but nothing officially supported. You’ll need to compile it yourself to work on Windows which can be an inconvenience at best.

iperf2 downloads page

For Linux, many operating systems come with iperf2 preinstalled, Ubuntu 20.04 is one such example. iperf3 is just a command away though, with package managers. For macOS, the Homebrew package manager can quickly get you iperf2 or iperf3.

Feature: iperf3 authentication (not encryption)

Description of authentication features in iperf3

iperf3 supports authenticating clients to the server using public key/private key as well as a users file. I decided to try it out. To avoid a hassle I just used the exact commands they provided in the man file. You first generate a public key and private key on the server:

openssl genrsa -des3 -out private.pem 2048
openssl rsa -in private.pem -outform PEM -pubout -out public.pem
openssl rsa -in private.pem -out private_not_protected.pem -outform PEM

Then create a “credentials.csv” file with hashed passwords. The following commands will get a hashed password for you:

S_USER=james S_PASSWD=james
echo -n "{$S_USER}$S_PASSWD" | sha256sum | awk '{ print $1 }'
----
0b0c98028105e9e4d3f100280eac29bba90af614d1c75612729228e4d160c601 #This is the hash of "james"

Then create a “credentials.csv” file that looks like this:

username,sha256
james,0b0c98028105e9e4d3f100280eac29bba90af614d1c75612729228e4d160c601

Now start the server:

iperf3 -s --rsa-private-key-path ./private_not_protected.pem --authorized-users-path ./credentials.csv

Then from the client, copy the public key over:

scp james@10.0.0.1:public.pem .

Then run the client:

iperf3 -c 10.0.0.1 --rsa-public-key-path ./public.pem --username james

You’ll be asked for the password. If you get it right, the server will display a message that authentication succeeded:

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Authentication successed for user 'james' ts 1639396545
Accepted connection from 10.0.0.2, port 32784
[  5] local 10.0.0.1 port 5201 connected to 10.0.0.2 port 32786
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   194 MBytes  1.63 Gbits/sec                  
[  5]   1.00-2.00   sec   204 MBytes  1.71 Gbits/sec

Feature: iperf2 isochronous mode

One of the coolest features of iperf2 is its “isochronous” option. This option is designed to simulate video streaming network traffic. You can hear Bob McMahon explain it himself on his youtube video on this feature.

Using the parameters and commands he describes in his video, we’ll run on a test. The Ubuntu server will be the iperf2 server:

iperf -s -e -i 1

Then on Rocky Linux we’ll run the client test:

[james@localhost ~]$ iperf -c 10.0.0.1 -i 1 --isochronous=60:40m,10m
------------------------------------------------------------
Client connecting to 10.0.0.1, TCP port 5001 with pid 1640
UDP isochronous: 60 frames/sec mean=40.0 Mbit/s, stddev=10.0 Mbit/s, Period/IPG=16.67/0.005 ms
TCP window size:  340 KByte (default)
------------------------------------------------------------
[  3] local 10.0.0.2 port 49150 connected with 10.0.0.1 port 5001 (ct=1.44 ms)
[ ID] Interval        Transfer    Bandwidth       Write/Err  Rtry     Cwnd/RTT        NetPwr
[  3] 0.00-1.00 sec   214 MBytes  1.79 Gbits/sec  1708/0          0       67K/562 us  398346.93
[  3] 1.00-2.00 sec   217 MBytes  1.82 Gbits/sec  1738/0        230      145K/608 us  374676.21
[  3] 2.00-3.00 sec   205 MBytes  1.72 Gbits/sec  1640/0        427      142K/583 us  368710.26
[  3] 3.00-4.00 sec   212 MBytes  1.78 Gbits/sec  1697/0        575      118K/920 us  241770.85
[  3] 4.00-5.00 sec   200 MBytes  1.68 Gbits/sec  1599/0        371      134K/853 us  245702.38
[  3] 5.00-6.00 sec   200 MBytes  1.68 Gbits/sec  1598/0        423      117K/529 us  395941.50

On the server we get our output:

james@u20vm:~$ iperf -s -e -i 1
------------------------------------------------------------
Server listening on TCP port 5001 with pid 3045
Read buffer size:  128 KByte
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49150
[ ID] Interval            Transfer    Bandwidth       Reads   Dist(bin=16.0K)
[  4] 0.0000-1.0000 sec   213 MBytes  1.79 Gbits/sec  4631    503:1500:1008:577:276:191:138:438
[  4] 1.0000-2.0000 sec   217 MBytes  1.82 Gbits/sec  4018    570:838:812:502:255:231:164:646
[  4] 2.0000-3.0000 sec   204 MBytes  1.71 Gbits/sec  5074    590:1537:1637:511:316:152:115:216
[  4] 3.0000-4.0000 sec   212 MBytes  1.78 Gbits/sec  3924    599:805:717:464:266:264:246:563
[  4] 4.0000-5.0000 sec   200 MBytes  1.68 Gbits/sec  3876    575:953:672:462:258:242:188:526
[  4] 5.0000-6.0000 sec   200 MBytes  1.68 Gbits/sec  4046    656:1040:687:476:258:242:238:449

Unfortunately the version of iperf that is available in Ubuntu 20.04 repositories (2.0.13) doesn’t support isochronous TCP mode mentioned in the video. You would need to compile from source or use Windows for that. A newer version will be included (probably already has been by the time you’re reading this) in Ubuntu 22.04 LTS.

Various smaller differences

There are many other spots that iperf2 and iperf3 are different.

  • iperf2 supports an “enhanced output mode” using -e that is totally revamped (used it above in the isochronous section).
  • iperf3 supports json output using the -j option.
  • iperf2 supports a bidirectional test which performs tests from the client and server simultaneously using -d
  • iperf2 uses a multi-threaded architecture, while iperf3 uses single-threaded. To be honest, I haven’t seen any way that this actually affects performance of the application. I’d be really curious if anyone has some input on this.

I hope this was helpful, and I hope I did both of these cool programs a small amount of justice. I’m really curious to see if anyone has any other input or differences they know about. Please fee free to comment or reach out directly.

How To Install Free Range Routing (FRR) on Ubuntu 20.04 and Rocky Linux 8.5

The latest version of my favorite routing protocol software, Free Range Routing 8.1 was recently released on November 9th.

Free Range Routing is a fork of the Quagga project that improves upon it and adds lots more features and new protocols. My favorite protocol that is added is EIGRP, which was originally a Cisco proprietary protocol until Cisco released a draft RFC in 2013. Free Range Routing makes it easy to spin up a Linux router and exchange routes via EIGRP. Since Cisco routers speak EIGRP, you can also exchange routes with them too! Today we’ll just exchange routes between Ubuntu 20.04 and Rocky Linux 8.5 via EIGRP.

Topology

Ubuntu and Rocky Linux in GNS3

We have a simple network here with an Ubuntu and Rocky Linux VM’s acting as IP routers. Without adding routes, Ubuntu does not know about 172.16.0.0/24, and Rocky does not know about 192.168.0.0/24. EIGRP can educate them. I should mention – each of the Alpine nodes has a default route pointing to the .1 in their subnet (Ubuntu and Rocky), which is a typical setup in most networks.

Installation

In a previous post, I installed FRR on Ubuntu 18.04 via the snap store. You can still do that, but it looks like the snap version hasn’t been updated with 8.1. I’m sure it will be updated soon, but let’s install it via the binary packages that FRR provides just to do something different.

For Rocky Linux, you can find instructions here. They are RPM packages for CentOS, and in my testing I found them to work fine for Rocky Linux. Per their instructions, we’ll run these commands:

FRRVER="frr-stable"
curl -O https://rpm.frrouting.org/repo/$FRRVER-repo-1-0.el8.noarch.rpm
sudo yum install ./$FRRVER*
sudo yum install frr frr-pythontools

We’ll need to modify /etc/frr/daemons and turn on the protocols we want, in this case EIGRP:

vi /etc/frr/daemons
---

eigrpd=yes #find this line and set to yes

Then you’ll need to restart frr:

systemctl restart frr

The process is similar on Ubuntu. The debian-based instructions are on this page. Following those, we’ll run these commands:

curl -s https://deb.frrouting.org/frr/keys.asc | sudo apt-key add -
FRRVER="frr-stable"
echo deb https://deb.frrouting.org/frr $(lsb_release -s -c) $FRRVER | sudo tee -a /etc/apt/sources.list.d/frr.list
sudo apt update && sudo apt install frr frr-pythontools

We’ll need do modify the daemons file similar to above and run the exact same systemctl command to restart frr.

Installation is complete!

Configure FRR and EIGRP

To setup EIGRP routing, we’ll enter the FRR vtysh configuration tool that should be familiar if you’ve used either Quagga or Cisco IOS routers. On Ubuntu we’ll do this:

vtysh
---

Hello, this is FRRouting (version 8.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

u20vm# conf t
u20vm(config)# router eigrp 10
u20vm(config-router)# network 10.0.0.0/30
u20vm(config-router)# network 192.168.0.0/24
u20vm(config-router)# ^Z
u20vm# exit

On Rocky Linux, it’s almost exactly the same but the second network to add is 172.16.0.0/24:

vtysh
---

Hello, this is FRRouting (version 8.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

rl85vm# conf t
rl85vm(config)# router eigrp 10
rl85vm(config-router)# network 10.0.0.0/30
rl85vm(config-router)# network 172.16.0.0/24
rl85vm(config-router)# ^Z
rl85vm# exit

Since Rocky is runnning firewalld by default, you’ll need to either stop it with systemctl stop firewalld or go through the process to allow EIGRP-related traffic through the firewall.

We should be able to see that each router has the other’s connected route now installed in its table. On Ubuntu we can see 172.16.0.0/24 is installed from vtysh with show ip route (edited somewhat for brevity):

u20vm# show ip route
---

E   10.0.0.0/30 [90/28160] is directly connected, ens3, weight 1, 00:41:19
C>* 10.0.0.0/30 is directly connected, ens3, 00:41:57
E>* 172.16.0.0/24 [90/30720] via 10.0.0.2, ens3, weight 1, 00:40:55
E   192.168.0.0/24 [90/28160] is directly connected, ens4, weight 1, 00:40:43
C>* 192.168.0.0/24 is directly connected, ens4, 00:41:57

And likewise on Rocky Linux we can see 192.168.0.0/24 is installed:

rl85vm# show ip route
---

E   10.0.0.0/30 [90/28160] is directly connected, ens3, weight 1, 00:43:07
C>* 10.0.0.0/30 is directly connected, ens3, 00:43:45
E   172.16.0.0/24 [90/28160] is directly connected, ens4, weight 1, 00:42:50
C>* 172.16.0.0/24 is directly connected, ens4, 00:43:45
E>* 192.168.0.0/24 [90/30720] via 10.0.0.1, ens3, weight 1, 00:42:38
localhost.localdomain# 

A wireshark (if you’re running GNS3) will show the EIGRP messages flowing. If you catch it right at the start, you can see updates messages and not just hellos:

Wireshark capture of EIGRP traffic between Ubuntu and Rocky Linux

Verify

This should be easy, we’ll just ping between the Alpine Linux nodes. (make sure each has a default route pointing to .1)

/ # ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: seq=0 ttl=63 time=2.662 ms

It works!

Hope you liked it.

How To Test Network Bandwidth With iperf3 in Linux

Testing network bandwidth in multiple flavors in Linux is simple with a tool called iperf. There’s two main versions – iperf2 and iperf3. Project maintainers apparently completely rewrote iperf3 from scratch to make the the tool simpler and to support some new features.

Update 12/12/2021: One of the authors of iperf2 reached out to me. Iperf2 is currently very much actively developed. You can find the most recent code on its sourceforge.net page. Iperf3 was indeed rewritten from scratch as the wikipedia page says, but mostly to meet the U.S. Department of Energy’s use cases. Iperf3’s github page clearly states the the DoE owns the project.

For testing bandwidth properly, you need to be running in server mode on one endpoint and client mode on the other. For this experiement, we will run the server on Rocky Linux 8.5 and the client on Ubuntu 20.04.

Topology

iperf3 test in GNS3

This is about as simple of a topology as I can think of. Two nodes on either end of a single link, Ubuntu at 10.0.0.1/30 running iperf3 client and Rocky at 10.0.0.2/30 running iperf3 server.

Iperf3 installation

On Ubuntu, iperf3 can be installed from distribution sources with apt-get:

apt-get install iperf3

Same on Rocky Linux but with yum:

yum install iperf3

Run iperf3 bandwidth test

First we need to start the server process on Rocky Linux with one command:

iperf3 -s

Then you should see the server listening for incoming tests:

iperf3 server listening on Rocky Linux 8.5

Then from the Ubuntu client, one command will run the test:

iperf3 -c 10.0.0.2

The output will give us our bandwith test results, which can be see on either the client or server:

Connecting to host 10.0.0.2, port 5201
[  5] local 10.0.0.1 port 59628 connected to 10.0.0.2 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   176 MBytes  1.48 Gbits/sec  685    230 KBytes       
[  5]   1.00-2.00   sec   173 MBytes  1.45 Gbits/sec  738    113 KBytes       
[  5]   2.00-3.00   sec   170 MBytes  1.42 Gbits/sec  1004    191 KBytes       
[  5]   3.00-4.00   sec   175 MBytes  1.47 Gbits/sec  714    123 KBytes       
[  5]   4.00-5.00   sec   182 MBytes  1.52 Gbits/sec  458    163 KBytes       
[  5]   5.00-6.00   sec   204 MBytes  1.71 Gbits/sec  443    314 KBytes       
[  5]   6.00-7.00   sec   180 MBytes  1.51 Gbits/sec  910    130 KBytes       
[  5]   7.00-8.00   sec   191 MBytes  1.60 Gbits/sec  849    123 KBytes       
[  5]   8.00-9.00   sec   172 MBytes  1.44 Gbits/sec  564    170 KBytes       
[  5]   9.00-10.00  sec   184 MBytes  1.54 Gbits/sec  412    225 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.76 GBytes  1.52 Gbits/sec  6777             sender
[  5]   0.00-10.04  sec  1.76 GBytes  1.51 Gbits/sec                  receiver

iperf Done.

A wireshark capture in GNS3 between the two hosts (or tcpdump on the links if you’re not in GNS3) will show the packets flying while the test is running:

Wireshark capture from GNS3 of iperf3 test

Hope you liked it!

How To Install (and lab) Keepalived on Ubuntu 20.04 and Rocky Linux 8.5

Keepalived is an open source software project that can do many things related to high availability. One of these many things is the Virtual Router Redundancy Protocol, which provides for high availability for IP networking. In other words, you can have two routers and if one goes down, the second one kicks in automatically.

The way this works is two or more routers exchange VRRP messages on a subnet and based on their configuration, decide who is the master and who is the backup. Once this is decided they will agree on a pre-configured “virtual” IP, or an IP that is not configured on an interface, but a floating one that either router can assume responsibility for should the other one fail for some reason and VRRP messages stop flowing.

Topology

VRRP lab in GNS3

The relevant network here is on the bottom half, where a subnet of 192.168.0.0/24 is configured. The Ubuntu server has 192.168.0.2/24 on its ens3 interface, while Rocky has 192.168.0.3/24 on its ens3 interface. They will both have keepalived installed and through VRRP share virtual IP of 192.168.0.1/24. The Alpine linux “PC” at the bottom which is acting as a workstation or desktop computer will have its default route configured to point to 192.168.0.1, the VRRP address.

Ubuntu 20.04 configuration

On the Ubuntu server we’ll install the keepalived available from the package manager with this:

apt-get install keepalived

Once that’s installed, we’ll write the configuration file which is in /etc/keepalived/keepalived.conf. You’ll need to create the keepalived.conf file:

vrrp_instance VI_1 {
	state MASTER
	interface ens3
	virtual_router_id 51
	priority 100
	advert_int 1
	authentication {
		auth_type PASS
		auth_pass james
	}
	virtual_ipaddress {
		192.168.0.1/24
	}
}

I’ll go through the parameters here:

  • state MASTER: the state that the router will start in.
  • interface ens3: VRRP protocol messages should flow is ens3.
  • virtual_router_id: An integer that both routers should have configured to the same thing.
  • priority: who wins the master/backup election – higher numerical means higher priority.
  • advert_int: backup waits this long (multiplied by 3) after messages from master fail before becoming master
  • authentication: a clear text password authentication.
  • virtual_ipaddress: the agreed-upon virtual IP that the routers will share

Restart keepalived to load the config:

systemctl restart keepalived

Rock Linux configuration

Since Rocky uses yum for package management, we install keepalived like this:

yum install keepalived

And in the /etc/keepalived/keepalived.conf file we’ll write this:

vrrp_instance VI_1 {
	state BACKUP
	interface ens3
	virtual_router_id 51
	priority 99
	advert_int 1
	authentication {
		auth_type PASS
		auth_pass james
	}
	virtual_ipaddress {
		192.168.0.1/24
	}
}

Make sure to restart keepalived to load the config:

systemctl restart keepalived

The only parameters that are different are the state and the priority.

Verify keepalived and VRRP

The first thing you can check on Ubuntu is the /var/log/syslog file to make sure keepalived started and is in the correct state:

tail /var/log/syslog
---
Dec  1 12:23:47 u20vm Keepalived[12349]: Opening file '/etc/keepalived/keepalived.conf'.
Dec  1 12:23:47 u20vm Keepalived[12349]: Starting VRRP child process, pid=12360
Dec  1 12:23:47 u20vm Keepalived_vrrp[12360]: Registering Kernel netlink reflector
Dec  1 12:23:47 u20vm Keepalived_vrrp[12360]: Registering Kernel netlink command channel
Dec  1 12:23:47 u20vm Keepalived_vrrp[12360]: Opening file '/etc/keepalived/keepalived.conf'.
Dec  1 12:23:47 u20vm Keepalived_vrrp[12360]: Registering gratuitous ARP shared channel
Dec  1 12:23:47 u20vm Keepalived_vrrp[12360]: (VI_1) Entering BACKUP STATE (init)
Dec  1 12:23:48 u20vm Keepalived_vrrp[12360]: (VI_1) received lower priority (99) advert from 192.168.0.3 - discarding
Dec  1 12:23:51 u20vm Keepalived_vrrp[12360]: message repeated 3 times: [ (VI_1) received lower priority (99) advert from 192.168.0.3 - discarding]
Dec  1 12:23:51 u20vm Keepalived_vrrp[12360]: (VI_1) Entering MASTER STATE

On Rocky the journalctl -e command showed me the keepalived logs.

Once you’ve confirmed that keepalived is in the right state, you can prove it further with a wireshark capture. If you’re doing this lab in GNS3 like I am, it’s easy, just right click the link (in this case, between the Ubuntu server and the switch) and capture on it. Otherwise you can use something like tcpdump on the Ubuntu/Rocky routers themselves. Right when you restart the keepalived process you will see packets going back and forth. That’s the master election process and exchange of parameters/neighbor establishment:

VRRP election in wireshark

But once the routers are in agreement and VRRP is working, packets will only flow from the master to the designated (in the RFC) VRRP multicast address at 224.0.0.18:

VRRP keepalives in wireshark

We can also further prove that when we initiate a ping to 8.8.8.8 from the Alpine “PC” (it’s a docker container), we can see that traffic is flowing through the Ubuntu router.

Simulate a failure

We’ll simulate a failure by shutting the ens3 interface on the Ubuntu router, like so:

ip link set ens3 down

The Rocky router will observe that VRRP “hello” messages are no longer going to 224.0.0.18, and quickly assume the role of master and take over for 192.168.0.1. I did a continuous ping on the Alpine PC and it didn’t actually show any failed pings! We can see that traffic is now flowing through the Rocky router:

Now let’s “fail back” to the Ubuntu router by re-enabling the ens3 interface:

ip link set ens3 up
ip addr add 192.168.0.1/24 dev ens3

And we should be able to see keepalived resuming master responsibilities in the Ubuntu /var/log/syslog:

Dec  1 12:44:53 u20vm Keepalived_vrrp[12379]: Netlink reports ens3 up
Dec  1 12:44:53 u20vm systemd-networkd[602]: ens3: Gained carrier
Dec  1 12:44:55 u20vm systemd-networkd[602]: ens3: Gained IPv6LL
Dec  1 12:45:04 u20vm Keepalived_vrrp[12379]: (VI_1) Entering BACKUP STATE
Dec  1 12:45:04 u20vm Keepalived_vrrp[12379]: (VI_1) received lower priority (99) advert from 192.168.0.3 - discarding
Dec  1 12:45:07 u20vm Keepalived_vrrp[12379]: message repeated 3 times: [ (VI_1) received lower priority (99) advert from 192.168.0.3 - discarding]
Dec  1 12:45:08 u20vm Keepalived_vrrp[12379]: (VI_1) Entering MASTER STATE

While the Rocky log will show a similar message about becoming backup. We can see that pings are once again flowing through the Ubuntu router:

Hope you liked it.

Rocky Linux 8.5 Installation

Since Redhat has decided to sunset CentOS, it is being replaced by Rocky Linux. You might be surprised at how quickly you can get a server up and running. We’ll also install the nginx webserver just to see how quickly we can get that going as well.

Let’s get right into it.

Download the installer

Rocky Linux Download Page

You can get the installer from https://rockylinux.org/download/ painlessly by downloading the minimal .iso image, it’s about 2GB. Once you have that, load it up on a USB (or a DVD, I guess. Does anybody still use those?!) or in my case, Qemu in GNS3 for a VM.

Follow the prompts

We’ll immediately be taken to the installer.

Initial installer page

Just select “Install Rocky Linux 8”. There’s just one page where you select your locale, software to install, partitions, etc. We can get through it minimally by just setting the user name and click “Begin Installation”, but feel free to play with the settings.

Installation takes about 5 minutes, depending on what is being installed and how much juice your system has.

Installing Rocky Linux
Installation complete

Reboot, and we’re ready to log in!

Install nginx web server

My login prompt came right up:

Login prompt

If you neglected to connect the network on the installation settings page like I did, you’ll need to do that now, using network manager’s nmcli.

nmcli connection modify ens3 ipv4.method auto
nmcli connection down ens3
nmcli connection up ens3

And with that we’re able to get an IP address via DHCP as well as DNS configuration, so Internet is good to go.

Let’s do something interesting – we’ll install nginx web server. If you’re familiar with Redhat commands, it uses the “yum” package manager to allow for quick installation of pre-built binaries. We can install nginx with one command:

sudo yum install nginx

Just that command will get it installed.

Nginx web server installation

We’ll need to start it up with systemd:

sudo systemctl start nginx

We’ll need to allow traffic to come through the firewall. For me this is a test server in a test environment, so I had no issue with turning off the firewall completely. If you are using this in production or it has a public IP address, obviously don’t do that – configure firewalld responsibly to only allow permitted web traffic. To turn the firewall off, just issue this command for systemd:

sudo systemctl stop firewalld

And now I can access the Rocky Linux Nginx default page!

Nginx web server default page customized for Rocky Linux

Enjoy your fresh installation of Rocky!