peter/infix
1
0
Fork 0
mirror of https://github.com/kernelkit/infix.git synced 2026-08-06 15:43:02 +02:00
Code Issues Packages Projects Releases Wiki Activity

doc: split container host interface, add w/ phys-address example

Browse Source 
The container host interface text was a bit hard to understand.  This
patch splits it up in two parts, basic routed setup and an advanced
with two interfaces.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This commit is contained in:
Joachim Wiberg
2024-05-18 09:58:19 +02:00
committed by Tobias Waldekranz
parent 0df778a5f6
commit abd8621e92
2 changed files with 61 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/ChangeLog.md
+1
View File
@@ -19,6 +19,7 @@ All notable changes to the project are documented in this file.
- Add small delay in U-Boot to allow stopping boot on reference boards
- Document how to provision the bootloader and Infix on a blank board
- Use initial hostname from `/etc/os-release` as configuration fallback
- Update documentation for use of VETH pairs in containers
- Issue #454: create bridges in `factory-config` with IGMP/MLD snooping
enabled by default
doc/container.md
+60 -19
View File
@@ -390,12 +390,30 @@ network:
### Container Host Interface
Another common use-case is to move a network interface into the network
namespace of a container. Which the container bridge network type does
behind the scenes with one end of the automatically created VETH pair.
This works with regular Ethernet interfaces as well, but here we will
use a VETH pair as an example along with a regular bridge (where other
Ethernet interfaces may live as well).
Another common use-case is to move network interfaces into the network
namespace of a container[^3]. This of course works with plain Ethernet
interfaces as well, but here we will use one end of a VETH pair as an
example.
[^3]: Something which the container bridge network type does behind the
scenes with one end of an automatically created VETH pair.
#### Routed Setup
In this routed setup we reserve 192.168.0.0/24 for the network between
the host and the `ntpd` container.
_____________
| |
veth0 .1 | .2 eth0 |
\ 192.168.0.0/24 | / |
'--------------------' [ntpd] |
|_____________|
Configuration is a straight-forward VETH pair setup where we name the
container-end of pair `ntpd`. This is just a convenience for us when
reading the configuration later. The *real action* happens on the last
line where we declare the `ntpd` end as a container network interface:
admin@example:/config/> edit interface veth0
admin@example:/config/interface/veth0/> set veth peer ntpd
@@ -403,23 +421,49 @@ Ethernet interfaces may live as well).
admin@example:/config/interface/veth0/> end
admin@example:/config/> edit interface ntpd
admin@example:/config/interface/ntpd/> set ipv4 address 192.168.0.2 prefix-length 24
admin@example:/config/interface/ntpd/> set phys-address 00:c0:ff:ee:00:01
admin@example:/config/interface/ntpd/> set container-network
This is a routed setup, where we reserve 192.168.0.0/24 for the network
between the host and the `ntpd` container. A perhaps more common case
is to put `veth0` as a port in a bridge with other physical ports. The
point of the routed case is that port forwarding from the container in
this case is limited to a single interface, not *all interfaces* as is
the default in the masquerading container bridge setup.
> Notice how you can also set a custom MAC address at the same time.
When a container has multiple host interfaces it can often be useful to
have a default route installed. This can be added from the host with a
`0.0.0.0/0` route on one of the interfaces. The following is an example
when adding a second VETH pair to the container:
Adding the interface to the container is the same as before, but since
everything for host interfaces is set up in the interfaces context, we
can take a bit of a shortcut.
admin@example:/config/container/ntpd/> set network ntpd
admin@example:/config/container/ntpd/> leave
The point of the routed case is that port forwarding from the container
in this case is limited to a single interface, not *all interfaces* as
is the default in the masquerading container bridge setup.
#### Bridged Setup
A perhaps more common case is to bridge the other end of the VETH pair
with other physical ports. In this section we show how to add a new
pair to give our container two interfaces:
_______________
| | .1 br0
veth0 .1 | .2 eth0 | / \
\ 192.168.0.0/24 | / eth1 .2 | veth1b e1
'------------------' \ | 192.168.1.0/24 /
| [ntpd] '------------------'
|_______________|
We start by adding the second VETH pair:
admin@example:/config/> edit interface veth1a
admin@example:/config/interface/veth1a/> set veth peer veth1b
admin@example:/config/interface/veth1a/> set ipv4 address 192.168.1.2 prefix-length 24
> The LAN bridge (br0) in this example has IP address 192.168.1.1.
When a container has multiple host interfaces it can often be useful to
have a default route installed. This can be added from the host with a
`0.0.0.0/0` route on one of the interfaces:
admin@example:/config/interface/veth1a/> set container-network route 0.0.0.0/0 gateway 192.168.1.1
admin@example:/config/interface/veth1a/> show
type veth;
@@ -439,9 +483,6 @@ Please note, container network routes require the base interface also
have a static IP address set. Setting only the route, but no address,
means the route is skipped.
> The LAN bridge (br0) in this example has IP address 192.168.1.1.
### Host Networking
The third use-case is host networking, this is where a container share