Using VRF to limit 'ip monitor' and 'iw event' messages

Using VRF to limit 'ip monitor' and 'iw event' messages

[Ben Greear]

Hello David,

We are interested in filtering out iw and ip netlink events for processes bound
to VRFs.

For instance, Chromium starts spewing errors when we try to run it on a system with many
network interfaces, we guess because it is being confused by all of the other network devices
going up and down.

I think the crux of the problem is to know if a netlink listener socket is bound
to a VRF or not, and also to know if the generator of the message is bound to
a particular VRF.

Do you have any suggestions for how we might go about this?  We'll be happy to post
the resulting patches for consideration to be included upstream.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Using VRF to limit 'ip monitor' and 'iw event' messages

[David Ahern]

On 5/18/26 3:51 PM, Ben Greear wrote:
> Hello David,
> 
> We are interested in filtering out iw and ip netlink events for
> processes bound
> to VRFs.

are you trying to filter out the events kernel side or in `ip monitor`?


> 
> For instance, Chromium starts spewing errors when we try to run it on a
> system with many
> network interfaces, we guess because it is being confused by all of the
> other network devices
> going up and down.
> 
> I think the crux of the problem is to know if a netlink listener socket
> is bound
> to a VRF or not, and also to know if the generator of the message is
> bound to
> a particular VRF.

so you are running `ip vrf exec` on ip monitor? ie., how is the netlink
socket getting bound to a device?

VRF is only a Layer 3 construct, and a netlink socket is not AF_INET or
AF_INET6.

> 
> Do you have any suggestions for how we might go about this?  We'll be
> happy to post
> the resulting patches for consideration to be included upstream.

You could add try a filter in `ip monitor` that looks at the device
index and only emit a message if "sk_bound_dev_if == N" where N is 0 for
default VRF or the VRF device ifindex. From there, you would have to
parse the message, identify the dump type, find the netdevice attribute
and then figure out if it is a VRF device or a port of a VRF device.
Going to be complicated.

Kernel side, netlink layer has no knowledge of the attributes, so I
don't see how a filter could work at that layer.

This reminds of the kind of filtering (ie., fine details) that Jamal
wanted to do for tc. Kind of hard to do given the various layers.

Re: Using VRF to limit 'ip monitor' and 'iw event' messages

[Ben Greear]

On 5/18/26 19:59, David Ahern wrote:
> On 5/18/26 3:51 PM, Ben Greear wrote:
>> Hello David,
>>
>> We are interested in filtering out iw and ip netlink events for
>> processes bound
>> to VRFs.
> 
> are you trying to filter out the events kernel side or in `ip monitor`?

For us, it needs to be kernel side, because it is not really ip monitor we
want filtered, but instead we want Chromium (or some other beastly program
that cannot easily be changed) to be filtered.

>> For instance, Chromium starts spewing errors when we try to run it on a
>> system with many
>> network interfaces, we guess because it is being confused by all of the
>> other network devices
>> going up and down.
>>
>> I think the crux of the problem is to know if a netlink listener socket
>> is bound
>> to a VRF or not, and also to know if the generator of the message is
>> bound to
>> a particular VRF.
> 
> so you are running `ip vrf exec` on ip monitor? ie., how is the netlink
> socket getting bound to a device?
> 
> VRF is only a Layer 3 construct, and a netlink socket is not AF_INET or
> AF_INET6.

So we'd have to plumb down into cgroups with a BPF program like
vrf exec for AF_INET works now, perhaps?

At least many ip events are related to a network interface, so we could
add meta data about that to the netlink msg path and then filter
before it gets sent to the listener netlink sockets...

Given a network device, is there an efficient way to get the vrf-id
to which it belongs?

Thanks for assistance!

--Ben

>> Do you have any suggestions for how we might go about this?  We'll be
>> happy to post
>> the resulting patches for consideration to be included upstream.
> 
> You could add try a filter in `ip monitor` that looks at the device
> index and only emit a message if "sk_bound_dev_if == N" where N is 0 for
> default VRF or the VRF device ifindex. From there, you would have to
> parse the message, identify the dump type, find the netdevice attribute
> and then figure out if it is a VRF device or a port of a VRF device.
> Going to be complicated.
> 
> Kernel side, netlink layer has no knowledge of the attributes, so I
> don't see how a filter could work at that layer.
> 
> This reminds of the kind of filtering (ie., fine details) that Jamal
> wanted to do for tc. Kind of hard to do given the various layers.
> 

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Using VRF to limit 'ip monitor' and 'iw event' messages

[David Ahern]

On 5/19/26 8:04 AM, Ben Greear wrote:
> 
> At least many ip events are related to a network interface, so we could
> add meta data about that to the netlink msg path and then filter
> before it gets sent to the listener netlink sockets...

As I recall this problem has been discussed a few times.

There can be many netlink listeners - e.g., ip monitor, frr, ...

The lower level code (ie., the one generating the notification) has no
idea how many sockets will receive the message and which ones will want
some filter to be applied to the message before attaching to the socket.

The higher level code (netlink sockets) has no idea of the content of
the message, so the ability to run a generic filter that is appropriate
for netlink level is really difficult.

> 
> Given a network device, is there an efficient way to get the vrf-id
> to which it belongs?
> 

yes, that is true for ip route, link, neigh, addr, tc, ... not so much
for other netlink users.

Re: Using VRF to limit 'ip monitor' and 'iw event' messages

[Ben Greear]

On 5/19/26 17:15, David Ahern wrote:
> On 5/19/26 8:04 AM, Ben Greear wrote:
>>
>> At least many ip events are related to a network interface, so we could
>> add meta data about that to the netlink msg path and then filter
>> before it gets sent to the listener netlink sockets...
> 
> As I recall this problem has been discussed a few times.
> 
> There can be many netlink listeners - e.g., ip monitor, frr, ...
> 
> The lower level code (ie., the one generating the notification) has no
> idea how many sockets will receive the message and which ones will want
> some filter to be applied to the message before attaching to the socket.
> 
> The higher level code (netlink sockets) has no idea of the content of
> the message, so the ability to run a generic filter that is appropriate
> for netlink level is really difficult.
> 
>>
>> Given a network device, is there an efficient way to get the vrf-id
>> to which it belongs?
>>
> 
> yes, that is true for ip route, link, neigh, addr, tc, ... not so much
> for other netlink users.

We have it at least partially working now, it seems like it will not be as bad as I had feared.

For our purposes, filtering most of the unwanted messages should be sufficient, and anything
we cannot easily figure out the ifindex for, we'll just pass on to the socket.

We'll post a patch for consideration once we get some more edge cases sorted out
and some more testing completed.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com