Myself, and several others in recent history would like to use kmod-vrf (which already exists as a package) in OpenWRT.
Trouble is, the kernel option NET_L3_MASTER_DEV remains unconfigured in the default kernel build of OpenWRT, which prevents kmod-vrf from working.
This kernel configuration option itself seems very trivial and seems to add minimal size (100 bytes, or so?) to the resulting kernel/system. Can anyone explain why it is not enabled by default, and/or help with a proper PR to get it enabled by default? I am clearly not the only person with interest here:
The kmod-vrf package is setup to depend on the OpenWrt kernel config symbol KERNEL_NET_L3_MASTER_DEV, so you need to configure OpenWrt to build with KERNEL_NET_L3_MASTER_DEV=y, otherwise OpenWrt will overwrite kernel config and unset that option.
If you think it should be activated by default for some (kernel) architectures, and/or OpenWrt targets, you can do that via a default option:
If it does only add tens of bytes to images, and is broadly useful, you could consider removing the Config-kernel.in option, and setting CONFIG_NET_L3_MASTER_DEV=y under the package KCONFIG options in netsupport.mk. Keep in mind, given how the buildbot works (ALL_KMODS), this would enable CONFIG_NET_L3_MASTER_DEV in every buildbot image. There will always be more resistance to increasing size of all images, as many devices have small flash or kernel partitions, and some need to get dropped for increasing sizes each release.
Given the apparent minimal additional footprint (100 bytes?) to the kernel, and how useful VRF capability can be on a router, is there some reason we donāt simply:
Then if someone wants to set up some vrf tables they simply install kmod-vrf and enjoy. Given the other threads Iāve linked that have almost no response this is an appeal to the developer community in general.
Perhaps there is some other reason Iām not aware of that enabling NET_L3_MASTER_DEV out of the box globally is a bad idea??
Edit: The reason I prefer to just have it enabled by default is this note in the build docs:
Note that make kernel_menuconfig modifies the Kernel configuration templates of the build tree and clearing the build_dir will not revert them.  Also you won't be able to install kernel packages from the official repositories when you make changes here.
Iād much prefer to be able to use VRF and not have to recompile my kernel again because I want another kmod later onā¦
Unfortunately Iām not much of a developer and donāt know enough about the OpenWRT kernel build process itself to know if this change is āsafeā to just enable en masse. Hence, my request for comments.
What I am sure about is that Iād like to be able to configure VRF without having to recompile an entire build by hand, every time.
So, which targets are we looking at? x86 is the obvious one but which others? Lots of my MT7621 and MT7622 devices have plenty of storage which allows for larger kernels plus FRR and other packages.
A few which spring to mind (for me, anyway) are:
ath79, mediatek, mvebu, ramips, rockchip, x86
If the change is small enough to be considered insignificant, though, why not just throw the switch for all targets? Or is that overly cumbersome or complicated to do? Apologies for my lack of intelligence on the development process here.
More and more it seems like I need to find or make some time to dig deeper into the structure and process of OpenWRT development, perhaps.
As others have pointed out, changing the kernel for all targets will provoke considerable push-back from maintainers of targets already facing challenges with space moving from kernel 5.15 to 6.6 for the next release.
Yes, and for some platforms it's going to have minimal resistance but there's already targets which are having to cut everything but the absolute minimum from their build cos the bootloader and firmware layout imposes a hard upper limit on kernel size.
Also, from the logistical point of view the change is much easier to get approved if you identify a small number of targets, then have discussions with those people first. IPVLAN, VRF and other items are not really applicable for 90% of OpenWRT use cases and although I use these tools a lot I can see why some tiny pocket routers would not need the feature. However the opposite is true and as OpenWRT finds itself on ever-more-powerful platforms the ability to separate routing tables and use advanced IP functions has a place.
A couple of years ago no-one really considered dynamic routing on OpenWRT but here we are with a fully-featured FRR build allowing for OSPF, BGP, RIP all in OpenWRT. Pretty amazing and separate VRFs are useful to have here.
Your points are sound and taken. Youāre probably right in that a large contingent of users donāt care about dynamic or more complex routing; they just want a solid AP or basic router for home/small office use.
I admit this was also me, originally. After toying with a bunch of other canned routing platforms (*sense, MikroTik, VyOS, roll-your-own) Iāve decided that OpenWRT is my favorite flavor. MikroTik is a close second, but it simply canāt give me the flexibility, control and wifi performance that OpenWRT does. Itās not even close.
Now Iām digging deeper and want to lab up OpenWRT with more complicated scenarios; DMVPN, FRR suite and yes, VRF.
Was very happy to find kmod-vrf and then immediately saddened to discover the small kernel option it requires necessitates a manual build. Iāve certainly done manual builds so I can test that way, but it makes upgrading and the ability to add more kmods later a bit painful.
Iām currently running and testing against a nanopi-r5s, an edgerouter-x, x86 (old pcengines apu1c4). My APs are Zyxel NWA50AX and an old Ubiquiti AP-PRO (which still runs great).
Ideally Iād like to try VRF on all of those (except the APs, maybeā¦ I do trunk vlans to them so that might be interesting too).
Apologies for the long winded reply. Again, Iām not much of a dev but have started learning more about git, to begin with. Despite my current lack of skills and knowledge with OpenWRT development please let me know if I can help in some way.
What platforms are you working with? Do you think trying to get this enabled for rockchip, mediatek/ramips and x86_64 is too tall an order to begin with?