Bug 1937823

Hi Thomas,

is this from a customer request or just for completeness？

(In reply to Gris Ge from comment #2)
> Hi Thomas,
> 
> is this from a customer request or just for completeness？

It's not a customer request, because no customer case is attached.

It's not only for completeness, because it's a useful feature.

> While at it, consider whether it isn't easier to add support for several times at the same time. But note that other types might behave different in subtle ways, so supporting multiple types in the same WIP requires to take care.


We want to add all route-types, the only problem is to consider whether there is something special about a particular route type. Considering and finding out whether that is the case, might be effort and we might therefore add one type at a time.

For example, it seems clear that "blackhole" type is very similar to "unreachable" routes, at least from NetworkManager's point of view. Those two, certainly can be added at the same time. Preferably, we add more types at the same time, if we can verify that the don't have special cases (or that we identify them and handle them).

If not already mentioned in a private comment before, case #03046378 makes this partially a customer case.

We need at least complete 'blackhole' support (support for 'unreachable' and 'prohibit' might be technically quite similar on the implementation level) in NetworkManager in order to be able to use RHEL 8 with NetworkManager (rather deprecated/legacy /etc/init.d/network) on our Linux routers with e.g. BIRD (being used for BGP), especially as systemd-networkd was declared as not mature enough in bug #1650342, but supports these route types since 2017. Real-world example from a RHEL 7 system with /etc/init.d/network, that doesn't seem to be equally configurable with NetworkManager <= 1.34 (tested with CentOS 9 Stream):

[root@cr-01 ~]# cat /etc/sysconfig/network-scripts/route-lo 
# IPv4 martians, based on https://en.wikipedia.org/wiki/Martian_packet#IPv4
blackhole 0.0.0.0/8
blackhole 10.0.0.0/8
blackhole 100.64.0.0/10
blackhole 169.254.0.0/16
blackhole 172.16.0.0/12
blackhole 192.0.0.0/24
blackhole 192.0.2.0/24
blackhole 192.168.0.0/16
blackhole 198.18.0.0/15
blackhole 198.51.100.0/24
blackhole 203.0.113.0/24
blackhole 224.0.0.0/4
blackhole 240.0.0.0/4
blackhole 255.255.255.255/32
[root@cr-01 ~]# cat /etc/sysconfig/network-scripts/route6-lo 
# IPv6 martians, based on https://en.wikipedia.org/wiki/Martian_packet#IPv6
blackhole 100::/64
blackhole 2001:db8::/32
blackhole fc00::/7
blackhole fe80::/10
blackhole fec0::/10
blackhole ff00::/8
[root@cr-01 ~]#

Sorry for the noise, I forgot another current real-world example: "blackhole 2001:db8:42::/48 table 42"

(In reply to Robert Scheck from comment #7)
> Sorry for the noise, I forgot another current real-world example: "blackhole
> 2001:db8:42::/48 table 42"

Thank you for the specific examples. There is now a new bug to track the blackhole route feature specifically: https://bugzilla.redhat.com/show_bug.cgi?id=2013587

Hi Robert Scheck,

In your comments, you seems only require the support of blackhole.

If there is no real customer request on unreachable route type, I would like to close this bug as won't fix due to development capacity concern.

Gris, we've been pointed by GSS/CEE to this RFE coming from the lack of complete blackhole support in NetworkManager. However, since your question, I've checked all of our RHEL 7 systems with /etc/init.d/network and figured out that we need complete "unreachable" and "prohibit" support in NetworkManager, too. Please let me know if this requires a separate GSS/CEE ticket.

Hi Robert,

Thanks for the information!
We will pursue this with medium priority and do blackhole first in bug 2013587.

(In reply to Robert Scheck from comment #11)
> Gris, we've been pointed by GSS/CEE to this RFE coming from the lack of
> complete blackhole support in NetworkManager. However, since your question,
> I've checked all of our RHEL 7 systems with /etc/init.d/network and figured
> out that we need complete "unreachable" and "prohibit" support in

Robert, we are migrating to capture requirements for features as user stories and acceptance criteria. Would you be willing to explain what you would like to achieve with prohibit and unreachable routes? Can you also share examples?

Thanks
Till

Obfuscated shortened real-world example (due to public unicast IP addresses, cases of different entries reduced to one per type) from another Linux router/firewall system than in comment #6:

$ cat /etc/sysconfig/network-scripts/route-lo 
prohibit 192.0.2.0/24 table 7
unreachable 198.51.100.0/24
$ 

$ cat /etc/sysconfig/network-scripts/route6-lo
prohibit 2001:db8:42::/48
unreachable 2001:db8::/48 table 7
$ 

In these cases, blackhole isn't suitable, because the generated ICMP errors "administratively prohibited" and "host unreachable" are explicitly desired. The first especially to ease debugging purposes in the remote network in conjunction with private network interconnects (e.g. with a peering partner who still has a false route). The second is quite widely used to cause a "meaningless" message (also to end users in some cases), but here mainly on routers to make a smaller destination prefix unreachable for different reasons, when just having a default gateway rather a default free zone with BGP (to effectively block smaller amounts of specific destination prefixes).

fixed upstream by https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1083

Tested using nmcli. It works fine and didn't detect any regression.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:1985