Please enable NET_L3_MASTER_DEV in kernel build by default

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:

Figure out where to set it - do we want VRF support for specific targets or for everything?

Once we know which kernel config to update we can look at creating a PR.

Disclosure - I am a novice developer with OpenWRT, but I am happy to do the PR if someone else can advise me.

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.

1 Like

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. ![:!:](https://openwrt.org/lib/images/smileys/exclaim.svg) 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…

You need to be comparing images sizes that have CONFIG_BUILDBOT (CONFIG_ALL_KMODS) settings.

be the response? Open a PR, you have been shown here how to change this.

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.

Then Opening an issue might be the course to follow.

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.

1 Like

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.

1 Like

Howels,

Thanks for chiming in on this thread (and two of the ones I linked in my initial post), it is very much appreciated!

Seems like you previously validated that the resulting image size increase is pretty close to zero:

NET_L3_MASTER_DEV is already enabled in kernel if PACKAGE_kmod-ipvlan=y/m

1 Like

Well the idea here is that I'd prefer that I don't have to do a custom build for every platform/version I want NET_L3_MASTER_DEV enabled for..

Or are you saying I can just install kmod-ipvlan from the repo on any existing platform and my kernel will magically have it enabled?

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.

Howels,

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?

1 Like

x86_64 is likely to be the easiest, suggest starting with that.

Conditional?

ifeq ($(CONFIG_SMALL_FLASH),)