Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've recently begun a new job, and have inherited an existing infrastructure with a lot of issues.

One of the issues is that the previous admin added static routes to some servers, bound to virtual interfaces, on the command line, without committing them to the server configs. I discovered this by chance, browsing the root history.

The problem I'm faced with is that the history is limited. I only have a couple of the command line entries - but not all of them. However, none of the diagnostic tools I'm familiar with will reveal what virtual interfaces routes are bound to.

To be specific, (with IP addresses mucked with for system privacy), of course:

root@web-a:/home/paul# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
14.17.24.24     10.124.74.65    255.255.255.255 UGH   0      0        0 eth0
14.17.24.23     10.124.74.65    255.255.255.255 UGH   0      0        0 eth0
18.29.146.135   10.124.74.65    255.255.255.255 UGH   0      0        0 eth0
58.21.196.19    10.124.74.65    255.255.255.255 UGH   0      0        0 eth0
10.124.74.64    0.0.0.0         255.255.255.192 U     0      0        0 eth0
0.0.0.0         10.124.74.65    0.0.0.0         UG    0      0        0 eth0

root@mweb-a:/home/paul# ip route show
14.17.24.24   via 10.124.74.65 dev eth0  src 10.124.74.73
14.17.24.23   via 10.124.74.65 dev eth0  src 10.124.74.73
18.29.146.135 via 10.124.74.65 dev eth0  src 10.124.74.73
58.21.196.19  via 10.124.74.65 dev eth0  src 10.124.74.73
10.124.74.64/26 dev eth0  proto kernel  scope link  src 10.124.74.69
default via 10.124.74.65 dev eth0

root@web-a:/home/paul# history|grep "route add"
66  2012-07-26 14:46:27 - route add -net 14.17.24.23  netmask 255.255.255.255 gw 10.124.74.65 eth0:2
67  2012-07-26 14:46:27 - route add -net 14.17.24.24  netmask 255.255.255.255 gw 10.124.74.65 eth0:2

Hopefully that came through clearly. 'route -n', 'ip route show', neither shows the actual virtual interface the route was bound to. So I have two routes that i don't know which virt interface they should go to (there are five virtual IP's on the server).

Now, an important caveat here is that I suck at routing. I understand the basics - but that's it. I've been a unix/systems admin for quite a long time, but routing has always eluded me, and I never had a need to do anything more advanced than correctly plumbing a few interfaces.

What I'm getting at is that I don't even know if it matters that the routes be bound to specific virtual interfaces. Judging by the output, I suspect that since everything is going out through the same gateway, (and all the virtual interfaces are on the same 10.124.74 network), then they don't need to be bound to individual virt interfaces - I'd think they could just be bound to the physical interface.

I'm not willing to operate on the principle of "it should be fine", however.

Help with clarity would be most appreciated.

share|improve this question
    
In my experience it isn't fine if routes aren't set up to return traffic from the ip it arrives on. Our firewall would refuse to route those ips seemingly at random. It would work fine for a while and then a change to the firewall or a reboot of our server would trigger an outage for an ip unexpectedly. @mcgorven's answer was very helpful in finally putting things right for us. –  Steve Jul 11 at 17:52

1 Answer 1

up vote 3 down vote accepted

Virtual interfaces (i.e. eth0:0) are a hack created in order to support multiple IP addresses on a single interface in ifconfig. They don't really exist -- they're just how you tell ifconfig which IP address you want to modify. The kernel and the iproute2 tools (i.e. ip) don't know about these virtual interfaces, which is why everything only mentions the real interface. The route command may have used the virtual interface to determine the source address to use, but otherwise would have just dropped it.

You should rather work with the ip tool, which supports multiple addresses on an interface, and use the src parameter to ip route if you need to set a specific source address for a route.

share|improve this answer
    
Thanks. So if I'm understanding correctly, instead of updating a particular virtual iface in /etc/network/interfaces with the route, a la "post-up route add -net 14.17.24.23 netmask 255.255.255.255 gw 10.124.74.65 eth0:2", I can safely add the declaration to the main eth0 interface as "post-up route add -net 14.17.24.23 netmask 255.255.255.255 gw 10.124.74.65 eth0". Correct? –  anastrophe Jul 27 '12 at 22:31
1  
@anastrophe If you still use the route tool you need to specify the virtual interface in order to set the correct source IP. If you use the ip tool you can use post-up ip route add 14.17.24.23/32 via 10.124.74.65 src 1.2.3.4 on the eth0 interface configuration. You can also get rid of virtual interfaces completely, and use post-up ip addr add 1.2.3.4 dev eth0 to add additional IPs. –  mgorven Jul 28 '12 at 3:06
    
Fantastic. Thank you so much for the very clear explanations, mgorven. –  anastrophe Jul 29 '12 at 0:03
    
This is great. I now understand this stuff much better. I've revamped our /etc/network/interfaces files to use this newer/better way of doing it. Thanks again for pushing me towards the right path. –  anastrophe Jul 29 '12 at 3:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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