Enable CONFIG_NET_VRF

[awlx]

This would help to utilise the new power on the network side even more.

We could build better routers etc.

[pelwell]

1. Please explain what NET_VRF is and why we want it.
2. What impact does enabling the config option have on free memory after booting (both with the feature active and inactive at runtime if applicable)?
3. As 2 but for network performance - iperf would be a suitable test.

[awlx]

1. Please explain what NET_VRF is and why we want it.

To isolate Network interfaces in different VRFs aka virtual "routers". It helps isolating traffic on a device. For example in "red", "green" and "blue" zones. So we can utilise the raspberry PI as a better home router or for Freifunk projects.

Full explanation http://man7.org/linux/man-pages/man8/ip-vrf.8.html

In my example you can see, that eth0 belongs to a different routing instance thus maintains it's own routing table and can act independent from the other devices. Which is very helpful if you want to isolate for example the upstream interface from your production traffic which is going through a vpn.

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vrf_external state UP group default qlen 1000
    link/ether dc:a6:32:04:bb:ab brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.191/24 brd 192.168.20.255 scope global dynamic eth0
       valid_lft 10773sec preferred_lft 10773sec
    inet6 2003:dc:df12:b602:dea6:32ff:fe04:bbab/64 scope global dynamic mngtmpaddr
       valid_lft 85935sec preferred_lft 13935sec
    inet6 fe80::dea6:32ff:fe04:bbab/64 scope link
       valid_lft forever preferred_lft forever
4: vrf_external: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP group default qlen 1000
    link/ether c2:26:06:9a:fe:45 brd ff:ff:ff:ff:ff:ff
10: br-welt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether dc:a6:32:04:bb:ab brd ff:ff:ff:ff:ff:ff
    inet 10.80.205.157/21 brd 10.80.207.255 scope global dynamic br-welt
       valid_lft 526sec preferred_lft 526sec
    inet6 2001:608:a01:109:dea6:32ff:fe04:bbab/64 scope global dynamic mngtmpaddr
       valid_lft 1491sec preferred_lft 891sec
    inet6 fe80::dea6:32ff:fe04:bbab/64 scope link
       valid_lft forever preferred_lft forever

And here you see the different routing tables:

root@raspi-4GB:~# ip ro sh table 1023
default via 192.168.20.1 dev eth0 
broadcast 192.168.20.0 dev eth0 proto kernel scope link src 192.168.20.191 
192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.191 
local 192.168.20.191 dev eth0 proto kernel scope host src 192.168.20.191 
broadcast 192.168.20.255 dev eth0 proto kernel scope link src 192.168.20.191 
root@raspi-4GB:~# ip ro sh
default via 10.80.200.8 dev br-welt 
10.80.200.0/21 dev br-welt proto kernel scope link src 10.80.205.157 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 

You can watch the PIs performance here (sorry v6 only):
https://raspi-4gb.awlnx.space

2. What impact does enabling the config option have on free memory after booting (both with the feature active and inactive at runtime if applicable)?

I didn't see any differences on my raspberry PI4 with the feature enabled.

3. As 2 but for network performance - iperf would be a suitable test.

The network performance is only impacted if you enable a VRF and it's in the sub kbit/s range at least in my tests.

[pelwell]

Thank you - for every added feature we have to way the benefits against the costs, and a thorough summary like that greatly increases the chances of a feature being added.

The fact that adding CONFIG_NET_VRF=m only causes a module to be built (there are no changes to the static kernel) is the most important point, and it helps that the module is a modest 30kB.

See ae5fd2e.

[awlx]

Thank you!

I close this now.
Feature added via ae5fd2e