You are not logged in.
Hello,
I've recently installed Arch Linux and am trying to get used to the systemd and networkd way of doing things. Please do not suggest using anything other than networkd in this thread, because I have been proceeding entirely in networkd and do not want multiple network configurations spread out across my whole system.
My standard ethernet adapter is called enp3s0. I want this adapter to be assigned an ip through DHCP. I want all outbound traffic from this machine to prefer this adapter's gateway over all other routes. It's defined as such:
/etc/systemd/network/wired.network
[Match]
Name=enp3s0
[Network]
DHCP=ipv4
I've created an additional ethernet adapter, /etc/systemd/network/eth0.netdev. I want it to be statically assigned an IP
[NetDev]
Name=eth0
Kind=bridge
/etc/systemd/network/strict-wired.network
[Match]
Name=eth0
[Address]
X.X.X.X/24
[Route]
Gateway=X.X.X.1
Everything's good so far, except for the order in which it processes the default routes.
When I do an 'ip route show', the static network's gateway is the first route.
default via X.X.X.1 dev eth0 proto static
default via D.D.D.1 dev enp3s0 proto dhcp src D.D.D.D metric 1024
...
I want to permanently remove the first route so that it isn't added at boot. I understand that I can remove the route with the ip command for now, but I want a permanent solution.
Thanks.
Last edited by Axoren (2015-09-02 20:43:26)
Offline
So remove the [Route] section from the eth0 network profile?
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
So remove the [Route] section from the eth0 network profile?
I could have sworn that this entry is mandatory from the wiki.
https://wiki.archlinux.org/index.php/Sy … 5D_section
This option is mandatory unless DHCP is used.
Will removing this section prevent me from responding to incoming connections over the eth0 adapter?
Ideally, I'd rather have the route stay on the list, just not as the first default route.
Offline
I could be wrong, but it should only be mandatory if you need the gateway set up Perhaps you have to keep the [Route] section but just leave the `Gateway` directive out.
It won't prevent incoming connections on the eth0 interface, but you'll only be able to respond to addresses in the same subnet on eth0 (eg, X.X.X.X/24 hosts).
The other option is to add a `Metric` option to force the metric to be higher than 1024 (which is the metric for the DHCP gateway looking at the output you posted above).
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
I could be wrong, but it should only be mandatory if you need the gateway set up
Perhaps you have to keep the [Route] section but just leave the `Gateway` directive out.
It won't prevent incoming connections on the eth0 interface, but you'll only be able to respond to addresses in the same subnet on eth0 (eg, X.X.X.X/24 hosts).
The other option is to add a `Metric` option to force the metric to be higher than 1024 (which is the metric for the DHCP gateway looking at the output you posted above).
Well, as of right now, I've lost access to the machine until tomorrow. Removing the [Route] section and restarting the systemd-networkd.service kicked me out and won't let me back in. Serves me right for changing the network settings over SSH.
Offline
Is there more subnets than just X.X.X.X/24 connected to the eth0 interface? Is there actually a gateway there? I think you need to describe your network better to help us understand.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Is there more subnets than just X.X.X.X/24 connected to the eth0 interface? Is there actually a gateway there? I think you need to describe your network better to help us understand.
The gateway for the X.X.X.X IP is X.X.X.1, subnet mask 255.255.255.0. I censored the octets because those are external ips on the internet.
In reality, both D.D.D.D and X.X.X.X share the same first two octets, so the Dynamic IP is really X.X.D.D. This adapter isn't a problem.
There's really no other network information that's necessary. The problem is in the configuration. I don't want the static adapter's route to come before the dynamic adapter's route in priority.
When setting the metric value, does lower correspond to a higher priority? Is it a distance or a score metric?
Offline
There's really no other network information that's necessary.
Apparently there is -- if I'd known there were additional networks connected to eth0, and that you were accessing the host via eth0, I wouldn't have suggested removing the gateway!
You will need to add static routes for whatever networks you do want to access via eth0, otherwise you will only be able to access the directly connected /24 via eth0, and that includes return traffic (which is probably why you can't access it now).
When setting the metric value, does lower correspond to a higher priority? Is it a distance or a score metric?
Lower metric = higher "priority". Think of the metric as a cost -- higher cost makes it less preferable, with all other things being equal.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Axoren wrote:There's really no other network information that's necessary.
Apparently there is -- if I'd known there were additional networks connected to eth0, and that you were accessing the host via eth0, I wouldn't have suggested removing the gateway!
You will need to add static routes for whatever networks you do want to access via eth0, otherwise you will only be able to access the directly connected /24 via eth0, and that includes return traffic (which is probably why you can't access it now).
I actually wasn't connected over eth0. It was just the act of restarting the systemd-networkd.service kicked me off of both interfaces. I've since gotten a colleague to help me reconnect over SSH to my machine.
Removing the [Route] section did indeed remove the default route from the routes list. In fact, it may have actually removed the default route while leaving the return traffic open.
ip route show
default via X.X.D.1 dev enp3s0 proto dhcp src X.X.D.D metric 1024
X.X.D.0/23 dev enp3s0 proto kernel scope link src X.X.D.D
X.X.D.1 dev enp3s0 proto dhcp scope link src X.X.D.D metric 1024
X.X.X.0/24 dev eth0 proto kernel scope link src X.X.X.X
Axoren wrote:When setting the metric value, does lower correspond to a higher priority? Is it a distance or a score metric?
Lower metric = higher "priority". Think of the metric as a cost -- higher cost makes it less preferable, with all other things being equal.
Alright, so the metric in this case is a distance/cost. In favor of keeping both routes open, but preferring the Dynamic adapter, I'll set the DHCP adapter to have a significantly low one, like 1 or 2 while giving the other one 1024 (this is the default, right?)
The RouteMetric directive is part of the [DHCP] tag. Under which tag and directive would I put the metric value for the Static adapter?
I'll have to wait until tomorrow to be sure that this issue is resolved. Without physical access to the machine, all I have going for me is "it looks right".
Offline
Check `man systemd.network` for how to configure the Metrics. But, there's no point having the second route with the manipulated metric, unless you expect that the DHCP interface may go down and you want the default route to failover to the gateway on eth0? The higher-cost default gateway will *never* get used so long as the other route is still in place.
What you have now seems right?
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
It seems right for the exclusion of the route entirely, however, all I have to go on is the output from 'ip routes show' and not an actual test of whether or not it's still sending traffic over the enp3s0 adapter.
Ideally, I'd like it as a fail-over in the future, which is why I'm pursuing the metric option as well.
When I confirm tomorrow that the first solution is successful, I'll mark the topic as [SOLVED].
Offline
The removal of the [Route] section from eth0 causes the machine to fail at boot to connect to the either ethernet adapter. This is resolved by taking down eth0 and bringing it back up with 'ip link set eth0 down' and 'ip link set eth0 up'.
Although promising-looking, that didn't solve my problem.
Offline