So, guys, there are some more seats. Please have a seat. And whenever you want, we can
start.
Okay. All right. So, let's start. Welcome, everyone. My name is Fernando. I'm a senior
software engineer at Red Hat. I work on the networking services team, mainly focused on
network management. So, today I'm going to talk how we can do networking management more
simple and how we can make the life of CIS admins a little bit better. I know that network
management can be complex, especially because most of the CIS admins need to sometimes configure
networking and maybe they are not network experts. So, all right. The first thing is
what is Network Manager. So, Network Manager is the standard Linux network configuration
tool suite. Basically, it's almost on every distribution and it configures networking.
It's just like that. It takes care of setting the IP address, all the properties, manage
routes, manage DNS, manage almost everything. Make sure that when other to modify the network
configuration, it will notify Network Manager, it will update the status, et cetera, et
cetera.
Network Manager provides Divas API and also they have their own library to communicate with
the demo, which is LibNM. And this is why there are some tools built around Network Manager.
For example, I know that some of you know them, NM-appler, NM-3, NM-CLI, or NM-Cloud
setup. And there are more and we are building more of them. So, as I said, the Network Manager
demo is the backend that we are going to use for the new tool, NM-State. And NM-State is
a little bit special because it's declarative. So, the idea here is that as an user, you
just need to define what do you want to configure. And you don't need to care about the whole.
So you need to, you can define the state, you can define what IP address do you want,
you can define what properties, if it's a bond, the bond properties, if it's a bridge,
whatever you want. And NM-State will take care of it and will resolve all the interdependencies
between the interfaces. We configure the routes, we configure everything that is needed to
make it work. And we have, we use Network Manager as a backend, we communicate with Network Manager
for applying the configuration, but we perform some operations that we are going to talk
later, and we needed NISPOR to communicate with Kana. So, we had a problem, we, initially
we were using CFS, and it was not working well, and we decided to create NISPOR, which
is another library written in Rust that allowed you to communicate with Kana and get real
time network configuration from Kana. So, well, the first question could be, why Nellink
and why not CFS? So, CFS is not an API. You need to understand that, because I know that
a lot of people build their tools parsing CFS, writing on CFS, using CFS everywhere,
and this could be problematic, because CFS is not an API, and if you read the documentation,
it's not a stable, it can break between releases. But Nellink is an API. Nellink is stable, it's
not deprecated, because CFS is deprecated, so most of the new CFS options, sorry, most
of the new network options that they are adding into Kana, they are not providing a CFS interface.
And also, Nellink use sockets, and that's great, because you don't need to open a file,
read it, parse it, and then get the proper value. Using sockets, you can get the attribute,
you know the type, you communicate through the Nellink sockets, you get the value, and
you get proper errors, so everything is better. Okay, so then let's go to the important part.
So NMS state handles everything. You don't need to do anything, you just need to define
what do you want, and ideally, you will apply that state, and everything will be configured
after some operations. Sometimes it's not like that, so we have a lot of steps in the
middle. We do, for example, validation, we do normalization, unverification, we are
going to explain them later. And also, it will point you what is going wrong, so you
can fix it. So for example, if you are configuring a MAC address, and this MAC address is not
being configured correctly, it will point you which MAC address is configured on Kana,
and what is the one that you wanted to configure, and right, you need to solve that. Also, if
you put in valid IP address, it will tell you this IP address is not valid, please change
it. Okay, for example, if you configure one, great thing is that if you configure an MTU
that is bigger than the one supported by the driver, it will let you know about that. Okay,
so one thing is that if you misconfigure something, good, we can do a rollback. Let's talk a
little bit about rollbacks. So this is already supported in Neville Manager, this is not
new from NMS state, but it's a little bit complex to use, and in NMS state, we simplify
it. So basically, all the time that you do an operation, and NMS state do the verification,
and if something goes wrong, it's rollback to the previous state. But we can also, maybe
nothing goes wrong, but you lost connectivity, because you remove the IP address, and we
cannot know if that is what you wanted or not, I mean, we as NMS state. So we allow
you to define an option which is no commit. So you can say this simple command, NMS state
CTL apply, the jammer file, we're going to see the format of the jammer file later, then
no commit, and a timeout time. If you don't specify a timeout, it's going to be 60 seconds
by default. So what happened if it went well? It's what you wanted, you have connectivity,
everything's good. Okay, then NMS state CTL commit, and the configuration will be there
permanently. But what happened if you notice that you mess up? All right, NMS state CTL
rollback, and you're going to be on the previous state. This is really great, because it's
really tiring when you misconfigure something, and then you need to undo it manually. So
this time, you just do a rollback, and everything will be like before. And what happened when
you are working remotely on a server, and you lose connectivity, and you end free travel
to the data center. Right now, with this tool, you can, with a timeout, if you lose connectivity,
you are not going to be able to do the commit. So at some point, it will rollback, and you
will have your connectivity back, hopefully. All right, and well, verification is optional,
but personally, I like it a lot, because what it does is NMS state gets the desired state
from the user, then apply it, and then get the current state that is applied to the system,
and compare them. And if they are not equal, then it's going to fail, and it's going to
rollback to the previous state automatically. This is great, because sometimes you don't
know about some options, and there are some requirements to set up these options on interface.
So what you can do is apply this if it goes wrong, because kernel is not applying the option
correctly, because they are incompatible, for example. So it does a rollback automatically,
and you don't end up with a wrong configure interface. But you can skip this using dash
dash no verify. Okay, so let's see some examples of YAML files. These are a little bit simple,
but I think they are great examples. Here, for example, we have a bone interface, and
you can just define the state, IPv4, the link aggregation options, you can define the mode,
the options of that mode, and then define the board. And one thing that is really, really
useful is that we have partial editing. So imagine that you want to change only the MAC
address, but you don't want to change the IP address. You don't need to define the IP
address, because you just define the interface and the type. So this is just enough. Then
the MAC address, I'm going to apply the state. An NMS state, we get the current status of
the interface, and we'll merge. So you won't lose any property. Alright, so then we have,
for example, another example in the middle is the Abelian interface or the ATH1 interface.
And another great thing here, as I say, is that NMS states resolve interdependencies automatically.
So basically, you don't need to know if, in which state needs to be the ATH1 when creating
the biland, it needs to be up or down. It doesn't matter. We are going to handle it. So you
don't need to worry about it. And then, for example, we have a Linux bridge with the board
and some options on the board. And also, one great thing here is that you don't need to
care about the state of the board. NMS state will resolve the dependencies and will bring
the board up if needed, or we configure as needed. Some more examples, because as I say,
NMS state is not only focused on interfaces. It's also focused on DNS, root configuration,
and also some other interfaces like OBS and OBS DPDK. So, okay, for example, here we have
our interface with the ATH1 configure with static IP address, and then we have the AdRoot.
So you can define the root and it will be applied to Kana. The same for routing policy.
It's also supported. You can define from IP2 and IP4. It will be for one mask. It will
be applied. The same thing for DNS. It's over. And as you can see there, the last example,
it's an OBS interface with an OBS bridge. So you can define it. And then the great thing
is that you don't need always to define the OBS interface. You can define only the OBS
bridge and add ports or delete ports from it. So it's quite great.
All right. So having seen these examples, I would like to do a demo. Sorry if it doesn't
work. I hope it will. I have an environment. So let's try it out. All right. So is it big
enough? I can make it bigger. Yeah? Okay. Right. So, okay, I'm using the main branch
version, which is 2.2.6. And here we have, this is really great. We have an examples
base. So you can, if you are learning how to use NMS stay, this is quite good. You can
go here and see different examples of how you should do it. So one that is really simple
is for example, this one. Right. So this one, one similar to what I showed before. So this
is an ATH one. And then you have the config, a root config for the ATH one. So let's check
before the state that we have already. Okay. This is the IP address that we have. And here
we have ATH one. ATH one is a, it's a base, but it's defined as an Ethernet. So according
to us, it will behave as an Ethernet. So let's apply the state. It's set ATH min and add
root. That's it. It's done. If we go to IPA and we go to ATH one, we can see the IP address
configure here. All right. Then if we do IPR, we are going to see the root here. One for
the IP address and the other one, the root that we set. And also, if you are wanting to
check what happened in the one manner here, you can do this. Oops. Okay. Sorry. All right.
You can, you can do this. You will notice that the device is up and we could check the connection
that we generated. But let's go to, sorry. Let's check a more complex sample. But we
need first to clean up the state. So I'm going to show you how we clean up the states. We
have ATH one, the old roots. All right. So here, for example, we just need to define
the ATH one and then define the roots with the net hop interface and a state absent.
And this will clear all the roots that are defined for that interface, which is great
because when removing something, you don't need to define everything. You just need to
define the properties that you want to match and then a state absent and it will clear
them. All right. So it's applied. Let's check it. Okay. And then we can, oh, exactly. Right.
Because we didn't bring down the ATH one interface. That's fine. But we drop the root. So let's
create a more complex one, one that I especially like. It's this one. This is going to be the
last one. So here we are going to define this. We have two ethernet interfaces that are
connected to a point interface, which has also another port, which is going to be the
other bridge and a villain over another bridge. So, all right. This is the state. We define
the villain interfaces with the ID, the linux bridge, which the port is the villain, and
then another linux bridge up and the port is going to be the bond. And then for the bond,
we have the two ethernet interfaces, ATH one and ATH two, and we have ATH one and ATH
two defined. So let's apply it. All right. This will do a little bit more. That's fine.
Right. So in network manager, everything seems set. Then we can do IPA, plenty of things.
Let me, this is the villain. Then we have here the bond with the others configure. No, sorry.
We have the bond here and the bridge 29. And we can also move them as we did with the other
example. And let me show you how it looks. Right. So this is quite simple. You just need
to define ATH one, ATH two as down because ATH one is an ethernet. Well, it's emulating
ethernet, but it's a physical device. So you cannot remove it completely. And then you
have the bond, which can be dropped, the bridge, the villain, and the other bridge. So that's
it. If you apply it, it will be gone. Check. All right. So it should be done. As you can
see, they are not any more, you cannot see any more the link, not the routes and not
the connections because we didn't, we removed also the network manager connection files.
So I think that's it. It was a little bit, a little demo about how it works. I really
encourage you to try it out. It's really simple. If you are really using network manager, you
basically do not need to do anything else because installing NMS state will be enough.
NMS state is packaged basically on Fedora, CentOS, Unreal. And well, it's, if you use
the Rust library, you can also use the create to use it whenever you want. All right. So
double bill. And now some questions. Thank you.
You basically use network manager to do all the settings and everything, but do you also
use net link? Why is it, why is it necessary? Don't you get all the information from network
manager? No, because Nebo manager is not getting real time information from kernel all the
time. It's not updating it directly. If you look to the devices, the devices doesn't have
all the properties. And in NISPO we care about all the properties that are defined on kernel.
So this is the main reason. Are there settings that you need to do the net link as well?
No, no. We don't do the settings through net link. We just get them to compare. We found
out the problem that as, our manager is a service and is listening on events of net
link, sometimes takes sometimes to update their device cache. And that's a problem because
when you do an operation, you want the result immediately.
Isn't that the bug in the network manager? Well, it isn't. And in the end you have a
very good cache and it's hard to keep everything updated. So they perform a lot of operations.
Obviously it could be improved. But right now this is the solution that we thought about.
Also, NISPO can apply settings to kernel, but we don't use it on NMSD. This is like an extra
feature that we work on it from time to time.
Hello. I would like to ask if dummy interfaces are supported and if not, are they planned
to be supported?
Dummy interfaces, yes. Dummy interfaces are supported. And that is, you can check recommendation.
I think everything is supported for dummy. Thank you.
Any more questions? All right.
I think we're good.
Yep, we're good. Thank you very much.
Thank you very much for attending. Thank you.
Thank you very much. Thank you very much.