Network management implementation details

This is a wikified post documenting the system level logic behind the network interface management in Rockstor. If you are a Linux or NetworkManager expert and like to suggest improvements, please feel free to edit this post or reply.

The process described below will take effect in 3.8-8. Code has already been merged into master by pr #884 and available in testing repo.

##User story
User can configure network interfaces on the system from the Web-UI. DHCP and Static IP configurations must be supported for ethernet devices. User can also restrict all Web-UI management to be possible only through one interface.

##System level tools used
NetworkManager is the primary application used by the backend, which is default in CentOS. Specifically, nmcli is used to interact with NetworkManager for all configuration management.

##NetworkManager documentation
I found RHEL7 documentation to be a very good reference. Of all the ways to interact with NetworkManager, nmcli is the obvious winner.

##Assumptions and Conventions
Currently, only ethernet devices are supported. So device type mentioned below is always ethernet. Also, connection name, interface name and device name are the same. We can use different naming, but since it’s one to one mapping, we are keeping things simple.

##Config process
User configures basic networking during OS install, may configure just one interface, which is required by Rockstor. Once setup is finished in the Web-UI, backend fetches current configuration information of the system using nmcli. So configuration made outside of the Web-UI using nmcli is honored by Rockstor.

When user edits configuration of a connection/interface, the existing connection is deleted and a new connection by the same name is added. The command used to delete is nmcli c delete <name>. The command to add is different based on dhcp or static configuration.

I am not sure if deleting and then adding a new connection is reliable as the connection can be deleted but error out on add. In my testing it’s been reliable, no loss of connections or any interruption. And it keeps the code clean and simple.

##Auto/DHCP config
When the user edits a connection to use Auto/DHCP, the command to create the new connection is nmcli c add type <device type> con-name <connection name> ifname <interface name>. That is all! If there is any error at nmcli level, it’s bubbled up to the Web-UI.

##Manual/Static IP config
In case of static IP configuration, we do basic input validation for subnet mask etc., but for the most part just pipe the user input to nmcli.

First, a new connection is created with nmcli c add type <device type> con-name <connection name> ifname <interface name> ip4 <ip_address>/<subnet_bits> gw4 <gateway ip address> command. gateway is optional and only used if the user provided a value.

dns_servers is also optional, but if provided, the following command is executed nmcli c mod <connection name> ipv4.dns <comma separated dns server ip's>

Just like in Auto/DHCP config, if there is any error at nmcli level, it’s bubbled up to the Web-UI.

##Link aggregation.
Coming soon, I played with teaming and it seems to be the recommended option over bonding.

##Misc notes
Since Web-UI itself requires network communication to function, certain edits may cause temporary disruption or may need the user to ssh or connect to terminal in someway to fix. There are appropriate tooltips and warnings on the Web-UI for such scenarios, and they can all be easily avoided. Suggestions for improvement are welcome, as always!

1 Like

though teaming is recommended over bonding i would still love to be able to use bonding which is for poor people who cant afford link aggregation switches throughout their infrastructure. Afaik mostly all bonding modes work without any specific switch features, mostly all teaming features dont work without 802.3ad. FreeNAS only has Teaming, bonding would be a great “competitor” feature if you want to call it like that.

In speed terms they are mostly on par, but teaming (obviously) supports more features, but sadly lacks alb/tlb, this gives a nice overview.

1 Like

I have disabled my wireless network device using ONBOOT=“no”, but I still get a 30 second hang at boot because of missing firmware (btw it wasn’t missing in earlier releases).

What’s the status on adding support for link aggregation?

Thanks for asking @ryan, it is planned but not at the top of the list right now.

If you’d like to see it sooner than later, there are two ways you can contribute (1) Configure it manually on Rockstor and share the detailed steps here on the forum or (2) Implement it and open a pull request.

1 Like