[SOLVED] RTNETLINK answers: File exists - Error when doing ifup on alias (eth1:1) on RHEL5
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
RTNETLINK answers: File exists - Error when doing ifup on alias (eth1:1) on RHEL5
Posting this as a solution since I didn't see the exact question when I Googled and a lot of what is written is fairly esoteric and not really germane:
I'd created an ifcfg-eth1:1 on a RHEL5.3 server. On running "ifup eth1:1" I got the following error.
"RTNETLINK answers: File exists"
A Google search mentioned this various times but nothing truly consistent and nothing directly related to what I was doing. Some mentioned routing which made me look at "netstat -rn" outuput. I saw it had added a new bogus route to the table. Also there was some discussion of the fact that message is somewhat bogus as it isn't a regular "file" that exists but rather a "file" in the broad sense that sockets, shared memory segment, et al are considered "files".
One link mentioned /usr/share/doc/initscripts<version> directory.
Reviewing documents there led me to the realization that starting any alias for an interface will attempt to also invoke the routing created for that interface. (We have a route-eth1 file for this due to the fact that default gateway is on eth0 which is the external facing NIC.)
Further read indicated there is an option for alias files to start the alias interface at same time as primary or not. The default is to start at same time.
All this along with the bogus route led me to the conclusion the "file" that "exists" is the route added at start of eth1.
Resolution was simply to "ifdown eth1:1; ifdown eth1; ifup eth1". The ifup eth1 at end starts both the primary and the alias AND only sets the route once so I didn't see the error starting this way.
Last edited by MensaWater; 03-11-2009 at 02:35 PM.
Very useful, your post pointed me at the right thing straight away.
For my setup eth1 is a secondary interface on the local LAN, 10.0.0.4, given that eth0 is the external interface the default gateway set in /etc/sysconfig/network points out that way..
I had added a line into route-eth1 defining a static route for the same LAN as eth1 is already in as I am getting the odd issue with a vpn session in not getting traffic back, despite getting assigned an IP in the same range. But after adding the route i was getting the "RTNETLINK answers: File exists". No route had been added showing the gateway 10.1.0.254 so i removed the line/route and hey presto, no error message.
Indeed, at least 3 people did just that. My point is that each could have given a well deserved extra point through the "helpful" system if it were available.
You can always click the little scales under MensaWater's name to give him Rep for the post ;-)
Well you learn something every day! That's what I did, and thanks for that tip too
wrt the error, I got the error on a CentOS box where I bonded a couple of NICs. The error was on bond0 when I did a:
Code:
# service network restart
What got me is that I've done this dozens of times and this was the only time I received the error - everything looked fine (ifconfig) and everything worked.
So then, I restarted the network again and no error. All was well in syslog too, so I still don't know what caused the error, but at least I know why it might occur if it happens again, and what I might do to alleviate the error.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.