Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 446606 - sys-apps/openrc: Routing policy rules need to be set before routes
Summary: sys-apps/openrc: Routing policy rules need to be set before routes
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: netifrc (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: netifrc Team
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2012-12-09 14:27 UTC by Thomas Deutschmann
Modified: 2013-08-24 01:20 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
This patch moves setting IP policy rules from post_start to pre_start (earlier_ip_pr_support.patch,1.07 KB, patch)
2012-12-09 14:29 UTC, Thomas Deutschmann
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Deutschmann gentoo-dev Security 2012-12-09 14:27:23 UTC
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 ]
Comment 1 Thomas Deutschmann gentoo-dev Security 2012-12-09 14:29:43 UTC
Created attachment 331878 [details, diff]
This patch moves setting IP policy rules from post_start to pre_start
Comment 2 Thomas Deutschmann gentoo-dev Security 2013-01-15 00:54:20 UTC
Can I get a feedback on this? Do you consider to add the patch to upcoming OpenRC releases?
Comment 3 William Hubbs gentoo-dev 2013-01-15 01:09:13 UTC
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?
Comment 4 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2013-01-15 02:57:13 UTC
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.
Comment 5 Thomas Deutschmann gentoo-dev Security 2013-01-15 16:34:42 UTC
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.
Comment 6 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2013-01-15 18:39:53 UTC
(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.
Comment 7 Thomas Deutschmann gentoo-dev Security 2013-01-15 20:33:29 UTC
(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.
Comment 8 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2013-08-24 01:20:05 UTC
InGit.