Results 1 to 2 of 2
Hi everyone! I have an interesting situation on my CentOS 4 server. I have a number of virtual adapters (e.g. eth0:1, eth0:2 etc), and for some reason all outbound traffic ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 03-24-2009 #1
- Join Date
- Mar 2009
Default outbound IP address with virtual IPs
I have an interesting situation on my CentOS 4 server. I have a number of virtual adapters (e.g. eth0:1, eth0:2 etc), and for some reason all outbound traffic is going through one of these, not eth0. If I go to ipchicken.com, it shows the ipaddress of a virtual adapter, not the normal eth0 adapter.
I have been looking around for information on how to set the default adapter to eth0, but I can't seem to find anything. I can't reboot yet, as it's a production server, so I have to wait for 'scheduled maintenance'. If that's the solution, I can try it, but I am sure there is another underlying issue/routine here.
Is there a way, while live, to set the outbound adapter back to eth0?
Please note, that I have only just realized this has happened. In fact, it has been this way since November. I can tell because server name stamps on Email messages sent from this server indicate a virtual domain at that IP address. I recall I had done some work around that time, which had involved me ifup'ing and ifdown'ing some of these adapters (but not eth0, or the eth0:100 adapter (if I recall correctly) that is now the default).
Also note that I have groups of eth0 adapters, such like:
It's the eth0:100 adapter that is now the default.
I appreciate any help anyone can offer.
- 03-25-2009 #2
- Join Date
- Mar 2009
Fixed (sort of)
I decided to try disabling the interface of the IP address it was using to go out with, and low and behold, it started using the correct eth0 address. I re-enabled the virtual interface, and it started using the incorrect address again.
I rebooted (after 360days uptime ), it is now using the correct eth0 interface for outbound traffic.
Two of the virtual interfaces (e.g. eth0:103 and eth0:104) that have "ONBOOT=no" decided they should be on, and were active after the reboot.
This strikes me as very odd behavior for Linux...curiouser and curiouser...
If this happens again, I'll try just restarting the network to see if it helps.