| Summary: | sys-apps/openrc: Routing policy rules need to be set before routes | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Thomas Deutschmann (RETIRED) <whissi> |
| Component: | netifrc | Assignee: | netifrc Team <netifrc> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | PATCH |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | This patch moves setting IP policy rules from post_start to pre_start | ||
Created attachment 331878 [details, diff]
This patch moves setting IP policy rules from post_start to pre_start
Can I get a feedback on this? Do you consider to add the patch to upcoming OpenRC releases? Hello, I have actually been told there are times when routing policy rules need to be set after routes as well, so this will have to be configurable. @robbat2: Can you comment more on this? Why would we want to configure routing policy rules before or after routes? If you are modifying the rules/routes on a live system, there are cases that your start will not fail, but you will cut off connectivity temporarily because the new route is not yet in place. It does really need to be configurable. The real solution would be to interleave rules & routes, but that would be extremely difficult without horribly overloading our handling of either. Hi, I am not sure, if I get your point. (In reply to comment #4) > If you are modifying the rules/routes on a live system, there are cases that > your start will not fail, but you will cut off connectivity temporarily > because the new route is not yet in place. Is that really a problem? I mean, when you bring up your network for the first time (e.g. after system start), there is no connectivity you can interrupt. When you change network configuration on a live system, would you really call /etc/init.d/<interface> restart? This will definitely kill any existing connectivity temporarily. If you don't want this, you would change your network by hand and only update /etc/conf.d/net so in case you really need to (re)start your network again (after a reboot), your new configuration will be in place. > It does really need to be configurable. Seems like you know a scenario, when setting rules before setting routes might be a problem. Can you tell it to me? I really cannot imagine a situation where setting a rule before setting a route can be a problem. (In reply to comment #5) > (In reply to comment #4) > > If you are modifying the rules/routes on a live system, there are cases that > > your start will not fail, but you will cut off connectivity temporarily > > because the new route is not yet in place. > Is that really a problem? > > I mean, when you bring up your network for the first time (e.g. after system > start), there is no connectivity you can interrupt. System start is the only case where the order only needs to be correct in loading. > When you change network configuration on a live system, would you really > call /etc/init.d/<interface> restart? This will definitely kill any existing > connectivity temporarily. If you don't want this, you would change your > network by hand and only update /etc/conf.d/net so in case you really need > to (re)start your network again (after a reboot), your new configuration > will be in place. Read this configuration: http://dev.gentoo.org/~robbat2/conf.d-net/multihomed-enterprise.txt It dates from where I implemented RPDB prior to merging it into oldnet. > > It does really need to be configurable. > > Seems like you know a scenario, when setting rules before setting routes > might be a problem. Can you tell it to me? > > I really cannot imagine a situation where setting a rule before setting a > route can be a problem. If you have this case: # ip rule add from 172.16.0.0/16 nat 1.2.3.4 priority 100 # ip route add default via 1.2.3.1 dev eth0 anything from 172.16/16 will not be routed prior to the route being added. Also, If you change your config from: config_eth0="172.16.0.123/32" to: config_eth0="172.16.0.123/16" Your route should not change anymore. (In reply to comment #6) > Read this configuration: > http://dev.gentoo.org/~robbat2/conf.d-net/multihomed-enterprise.txt Thanks. This was interesting. > > I really cannot imagine a situation where setting a rule before setting a > > route can be a problem. > > If you have this case: > # ip rule add from 172.16.0.0/16 nat 1.2.3.4 priority 100 > # ip route add default via 1.2.3.1 dev eth0 > anything from 172.16/16 will not be routed prior to the route being added. Right, but why would you do that? :) You agreed, that system start is special. So we don't need to talk about system start. But is restarting the interface not the same? I think it is the same. So the same things applying to system start also apply to "/etc/init.d/net.<interface> restart". And on a live system? Where does 172.16/16 come from? - It is a new network? See system start. There are no connections we could interrupt. - The network already exist? If you now want to add NAT (because the provided service is moving), you would run the commands by hand, won't you? So I don't understand why changing the order OpenRC will bring up an interface, which is only needed when the interface will start (=there are no connections we could interrupt) could break something. So I am not sure that your scenario is valid at all. :) Again, I don't disagree with you, that sometimes setting a rule before a route can interrupt existing connections. But I say that this will only affect active networks. When starting a network, I cannot imagine a scenario, where setting a rule before a route can be a problem. But I can imagine scenarios, where setting a route before a rule won't work :-) When applying a changed network configuration via restarting the interface, you don't care about existing connections. So why should OpenRC (which is only used when you start an interface) care about that? > Also, > If you change your config from: > config_eth0="172.16.0.123/32" > to: > config_eth0="172.16.0.123/16" > > Your route should not change anymore. You are right. With the default route for 172.16/16, my configuration from #1 will work with OpenRC. But there was a reason why I wanted to prevent the kernel from creating the default route for 172.16 (that's why I used /32), I don't remember at the moment. InGit. |
Hello, setting a route (gateway) for a custom routing table will fail, when the kernel doesn't know how to reach the gateway. Therefor you would set routing policy rules (ip rule add ...). This is supported by OpenRC. But because sys-apps/openrc currently sets rules *after* routes, this doesn't work. Solution: Set rules before routes. I will attach a patch. Reproducible: Always Steps to Reproduce: 1. echo "1 intern" >> /etc/iproute2/rt_tables 2. cat /etc/conf.d/net modules_eth0="iproute2" config_eth0="172.16.0.123/32" rules_eth0=" from 172.16.0.0/16 table intern priority 100 to 172.16.0.0/16 table intern priority 100 " routes_eth0=" 172.16.0.0/16 dev eth0 src 172.16.0.123 table intern default via 172.16.0.1 dev eth0 table intern " modules_eth1="iproute2" config_eth1="8.8.8.10/32" routes_eth1=" 8.8.8.8/29 dev eth1 src 8.8.8.10 default via 8.8.8.9 " 3. /etc/init.d/net.eth0 start Actual Results: * Bringing up interface eth0 * Loaded modules: apipa arping bonding tuntap ccwgroup macvlan macchanger macnet wpa_supplicant ssidnet iproute2 system vlan udhcpc ip6to4 * Configuring eth0 for MAC address 00:XX:XX:XX:XX:XX ... [ ok ] * 172.16.0.123/32 ... * ip addr add 172.16.0.123/32 broadcast + dev eth0 [ ok ] * Adding routes * 172.16.0.0/16 dev eth0 src 172.16.0.123 table intern ... [ ok ] * default via 172.16.0.1 dev eth0 table intern ... [ !! ] * Adding IPv4 RPDB rules * add from 172.16.0.0/16 table intern priority 100 ... [ ok ] * add to 172.16.0.0/16 table intern priority 100 ... [ ok ] Expected Results: * Bringing up interface eth0 * Loaded modules: apipa arping bonding tuntap ccwgroup macvlan macchanger macnet wpa_supplicant ssidnet iproute2 system vlan udhcpc ip6to4 * Configuring eth0 for MAC address 00:XX:XX:XX:XX:XX ... [ ok ] * 172.16.0.123/32 ... * ip addr add 172.16.0.123/32 broadcast + dev eth0 [ ok ] * Adding IPv4 RPDB rules * add from 172.16.0.0/16 table intern priority 100 ... [ ok ] * add to 172.16.0.0/16 table intern priority 100 ... [ ok ] * Adding routes * 172.16.0.0/16 dev eth0 src 172.16.0.123 table intern ... [ ok ] * default via 172.16.0.1 dev eth0 table intern ... [ OK ]