Bug 1789475

I don't think this should be done.


As far as kernel is concerned, a routing table is only a u32 bit number. Only iproute2 honors name mappings in /etc/iproute2/rt_tables (and tools that use iproute2).


When you configure a profile in NetworkManager, then the profile should be self contained as much as possible. Having additional name to number mappings in /etc/iproute2/rt_tables seems very bad to me, because the meaning of the profile depends on additional files.


Also, NetworkManager couldn't verify that the setting is correct. Because a missing alias in rt_tables must not fail validation of the profile entirely (it would be bad if today the profile works, then you edit a line in rt_tables, and after reboot the profil no longer validates -- meaning: it cannot be loaded). Instead, if the value is not in rt_tables, the profile would have partially invalid configuration, that is hard to handle.

Also, NM would have to load the file to resolve the names. Should it cache the file in memory, or reload it everytime when resolving the name? When a profile activates, it would have to resolve the names, but it also would have to cache the name mapping until the profile goes down again.


This makes everything complicated. Having multiple names for the same thing adds complexity. Double so, when the name mappings can change any time.



Note that since [1], for routing rules, we accept the names "main", "local", and "default". But those names are not resolved via /etc/iproute2/rt_tables, they are always hardcoded to the respective numbers that they commonly have.

[1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=70b23c7979566f4be46d138dedfa59e215cec44b



> If altering "ipv4.route-table" is not desired, then a new string key name, for example "ipv4.route-table-name" could have the same above meaning.

This not only applies to `ipv4.route-table`. It also applies to properties like `ipv4.routes` and `ipv4.routing-rules`, which can have tables too.

(In reply to Thomas Haller from comment #1)
> I don't think this should be done.
> 
> 
> As far as kernel is concerned, a routing table is only a u32 bit number.
> Only iproute2 honors name mappings in /etc/iproute2/rt_tables (and tools
> that use iproute2).
> 

I never said this is not true or something different

> 
> When you configure a profile in NetworkManager, then the profile should be
> self contained as much as possible. Having additional name to number
> mappings in /etc/iproute2/rt_tables seems very bad to me, because the
> meaning of the profile depends on additional files.
> 

all tutorials on the internet suggest editing rt_tables and giving the tables meaningful names instead of just using kernel numbers

> 
> Also, NetworkManager couldn't verify that the setting is correct. Because a
> missing alias in rt_tables must not fail validation of the profile entirely
> (it would be bad if today the profile works, then you edit a line in
> rt_tables, and after reboot the profil no longer validates -- meaning: it
> cannot be loaded). Instead, if the value is not in rt_tables, the profile
> would have partially invalid configuration, that is hard to handle.
> 

If the editing is done at connection activation, then the value is always generated so even if someone deletes it, at next boot when NM brings up the connection it also generates name and number. How can generating a name/number pair at connection startup make the connection fail validation, when valid names+number have just been generated in the process of activating the connection?

> Also, NM would have to load the file to resolve the names. Should it cache
> the file in memory, or reload it everytime when resolving the name? When a
> profile activates, it would have to resolve the names, but it also would
> have to cache the name mapping until the profile goes down again.
> 

Why should it cache? The kernel/filesystem determines if the file should be cached, I don't understand what sense it would make for NM to cache filesystem file contents.

> 
> This makes everything complicated. Having multiple names for the same thing
> adds complexity. Double so, when the name mappings can change any time.
> 

it does, but until NM can handle rt_tables the user still has to go to two places to configure policy routing, so until then NM still has not full support for policy routing.

I mean, NM does talk to kernel directly and sets up a rule priority number to a table number, but the user would still go anyway check the status with 'ip' (ip route, ip rule) because NM does not show the effective kernel rule list when you look with <nmcli connection show "connname">

>> Also, NM would have to load the file to resolve the names. Should it cache
>> the file in memory, or reload it everytime when resolving the name? When a
>> profile activates, it would have to resolve the names, but it also would
>> have to cache the name mapping until the profile goes down again.
>> 
>
>Why should it cache? The kernel/filesystem determines if the file should be cached, I don't understand what sense it would make for NM to cache filesystem file contents.

sorry I misunderstood this one.
it should work under the assumption that user knows what is doing like modifying the file while there are NM connections that use policy routing.
so NM should behave identically to when an user modifies the ifcfg-interface0 files.

I agree with Thomas' comment, allowing table names that must be resolved through an external file that can change at any time makes the connection profiles not self-contained and can introduce problems hard to debug every time the file is touched externally.

I agree with Thomas and Beniamino, as this won't make it in NM closing the bz.