0

I have a virtual machine on top of VMware on which I run Ubuntu Server 12.04. I have two network adapters configured for the virtual machine and my /etc/network/interfaces configuration looks like this:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 10.226.83.2
netmask 255.255.255.248
gateway 10.226.83.1

# Management Interface
auto eth1
iface eth1 inet static
address 10.20.9.200
netmask 255.255.240.0
up ip route add 10.20.0.0/20 via 10.20.0.1 dev eth1 || true
up ip route add 10.21.120.0/22 via 10.20.0.1 dev eth1 || true
up ip route add 10.13.122.0/22 via 10.20.0.1 dev eth1 || true

My problem is that with this specific configuration I am unable to see the route to 10.13.122.0/22 when calling route:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use     Iface
default         10.226.83.1     0.0.0.0         UG    100    0        0 eth0
10.20.0.0       *               255.255.240.0   U     0      0        0 eth1
10.21.120.0     10.20.0.1       255.255.252.0   UG    0      0        0 eth1
10.118.233.0    10.118.233.2    255.255.255.0   UG    0      0        0 tun10000
10.118.233.2    *               255.255.255.255 UH    0      0        0 tun10000
10.226.83.0     *               255.255.255.248 U     0      0        0 eth0

What I am trying to accomplish is that traffic to and from the networks 10.20.0.0/20, 10.21.120.0/22, and 10.13.122.0/22 would traverse through eth1 towards 10.20.0.1, and otherwise traffic would go through eth0 and via 10.226.83.1. tun10000 is an adapter generated by our OpenVPN confiuration and that can be ignored in this case.

Currently everything except for 10.13.122.0/22 is working fine, which is reflected in the routing table; I cannot see 10.13.122.0/22 in the table even though the route for it was added using the same syntax as for the other two networks.

Also, when I do sudo /etc/init.d/networking restart I get the following:

$ sudo /etc/init.d/networking restart
 * Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces
 * Reconfiguring network interfaces...
                                                    ssh stop/waiting
ssh start/running, process 21240
RTNETLINK answers: File exists
RTNETLINK answers: Invalid argument
ssh stop/waiting
ssh start/running, process 21306

Even with the two RTNETLINK answers I am getting a functional interface except for the route to 10.13.122.0/22. How can I get this route to work and is there a way I would get rid of the "File exists" and "Invalid argument" messages?

5
  • Don't use the old route command; use ip route show (or ip ro sh for short). – wurtel Nov 10 '15 at 10:11
  • Just curious: How do you reach 10.20.0.1? – gf_ Nov 10 '15 at 10:14
  • @gf_ I am just guessing here since obviously this is not my comfort zone: I presumed that I am able to reach it since I am routing 10.20.0.0/20 via eth1. – treiman Nov 10 '15 at 11:18
  • @treiman: Are you able to reach 10.20.0.1 actually, for example via ping? – gf_ Nov 10 '15 at 12:06
  • @gf_: Yes I am, without any problems. – treiman Nov 10 '15 at 12:17
1

10.21.120.0/22 is 10.21.120.0-10.21.123.255, hence is identical to 10.13.122.0/22. So setting a route for 10.13.122.0/22 will give the error "File exists" (or more correctly "entry already exists").

You need to figure out your network topology a bit better.

2
  • Your answer made me realize I had the wrong mask in the configuration; swapping 10.13.122.0/22 to 10.13.122.0/23 got things working. However I am still seeing "RTNETLINK answers: File exists", which leads me to the following question: How could there still be overlap if 10.21.120.0/22 is 10.21.120.1 - 10.21.123.254 usable and 10.13.122.0/23 is 10.13.122.1 - 10.13.123.254 usable? – treiman Nov 10 '15 at 11:15
  • 1
    Haven't you answered your own question? 10.13.122.1 - 10.13.123.254 is contained in 10.21.120.1 - 10.21.123.254. You probably also need to change 10.21.120.0/22 to 10.21.120.0/23. – wurtel Nov 11 '15 at 7:42
0

I had the wrong mask in the configuration; swapping 10.13.122.0/22 to 10.13.122.0/23 got things working.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.