In the past bridge devices used to be created with a generated MAC address
thwarting the inheritance of the first slave's MAC address. This has been
changed by commit [1] some time ago. Reflect that behavioral change in the
documentation.
[1] deb2cfa4c6 ("networkd: do not generate MAC for bridge device.")
This allows to limit units to machines that run on a certain firmware
type. For device tree defined machines checking against the machine's
compatible is also possible.
`AllowedIPs=` only affects "routing inside the network interface
itself", as in, which wireguard peer packets with a specific destination
address are sent to, and what source addresses are accepted from which
peer.
To cause packets to be sent via wireguard in first place, a route via
that interface needs to be added - either in the `[Routes]` section on
the `.network` matching the wireguard interface, or outside of networkd.
This is a common cause of misunderstanding, because tools like wg-quick
also add routes to the interface. However, those tools are meant as a
"extremely simple script for easily bringing up a WireGuard interface,
suitable for a few common use cases (from their manpage).
Networkd also should support other usecases - like setting AllowedIPs to
0.0.0.0/0 and ::/0 and having a dynamic routing protocol setting more
specific routes (or the user manually setting them).
Reported-In: https://github.com/systemd/systemd/issues/14176
In NEWS, the new option was described twice, most likely because the first
description was tucked away in a paragraph about some other subject.
While at it, improve the descriptions in the man page to make it easier to grok
what that option really does.
Let's use the new flag wherever we read key material/passphrases/hashes
off disk, so that people can plug in their own IPC service as backend if
they like, easily.
(My main goal was actually to support this for crypttab key files — i.e.
that you can specify AF_UNIX sockets as third column in crypttab — but
that's harder to implement, since the keys are read via libcryptsetup's
API, not ours.)
Add support for creating a MACVLAN interface in "source" mode by
specifying Mode=source in the [MACVLAN] section of a .netdev file.
A list of allowed MAC addresses for the corresponding MACVLAN can also
be specified with the SourceMACAddress= option of the [MACVLAN] section.
An example .netdev file:
[NetDev]
Name=macvlan0
Kind=macvlan
MACAddress=02:DE:AD:BE:EF:00
[MACVLAN]
Mode=source
SourceMACAddress=02:AB:AB:AB:AB:01 02:CD:CD:CD:CD:01
SourceMACAddress=02:EF:EF:EF:EF:01
The same keys can also be specified in [MACVTAP] for MACVTAP kinds of
interfaces, with the same semantics.
For users, the square brackets already serve as markup and clearly delineate
the section name from surrounding text. Putting additional markup around that
only adds clutter. Also, we were very inconsistent in using the quotes. Let's
just drop them altogether.
Since kernel 5.2, netdevsim creation/destruction via netlink is removed.
So, let's remove the netdevsim support from our documents.
See below commit for more details.
e05b2d141f
Intermediate Functional Block
The Intermediate Functional Block (ifb) pseudo network interface acts as a QoS concentrator for multiple different sources of traffic. Packets from or to other interfaces have to be redirected to it using the mirred action in order to be handled, regularly routed traffic will be dropped. This way, a single stack of qdiscs, classes and filters can be shared between multiple interfaces.
Here's a simple example to feed incoming traffic from multiple interfaces through a Stochastic Fairness Queue (sfq):
(1) # modprobe ifb
(2) # ip link set ifb0 up
(3) # tc qdisc add dev ifb0 root sfq
