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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If I may say one last thing - actually two. THANK YOU. This should be a straight install. I've installed the OS on all of the servers from CentOS 3 through 7.3. Only two have done this and they are both Super Micro H8DAR-i mobo's with dual Operton 278's. They aren't heavily loaded and have Virtouzzo on top AFTER the OS is successfully loaded. It acts as a buffer between the booting OS and the containers for added security. This also saves on power supplies. Instead of rebooting the hardware we reboot a container either through SSH or KVM/IP. We have remote APC's in the event that we have no other choice.
We are a non-profit 501(c)(3) organization. Legitimately. I don't earn a living at all from this. I built this network and know it well! It has a Cisco switch for the external IP's and another for the private IP network. This has worked since 2007. All is well with CentOS 5.9 but we know that it is EOL. I can't install 5.9 because I can't find a repo for the 64-bit version or I would install it. That's what was on there before the RAID went unrecoverable. The Virtuozzo (the commercial version of OpenVZ) backups need to go to the same server. The folks at CentOS ridiculed me for trying backwards from 6.9 trying to get a version to load.
The enterprise grade hardware firewall blocks damn near everything to the hardware node so as long as we keep the container OS and Plesk current we're somewhat secure. Nothing is foolproof and I know that. I have given you what I can partly to show that I am not a complete bozo. Please don't go there...
I have run 200 web server containers, one ftp/sftp server, and one DNS server all on OpenVZ containers using the kernel for RHEL 6 from the OpenVZ site. The containers were CentOS 6 and CentOS 7. They all worked just fine, and the containers are compatible with your virtuozzo commercial product.
My understanding right along is that this problem is at the host (CTID=0) level and expresses BEFORE you replace the kernel.
On hardware available to me I am not able to replicate the issue, but I do not have hardware like yours. Your ifup command appears to be failing, this that message, because the interface it is trying to raise is already up. Yet sshd can communicate on that port AFTER than failure but not BEFORE.
If I have anything incorrect here, please let me know.
If this interfaces al come up on boot, and the services come up on boot, and the routing does not change when you run that command and get the error, this issue should not happen.
If I still had hair, this might make me lose some. I will watch for someone else to weigh in and see what else can be checked.
I wish you were local to me, I would love to come look at this box. (Not that it would do any good, but any hardware more stubborn than my cat deserves to be recognized.)
It would be interesting to see the output of netstat -rn before running ifup.
You never posted the ifcfg-eth1 file.
The pid for ssh is different before and after you run the ifup command. Although the boot messages showed everything started ok have you looked at the logs?
If you can not ping the host then your problem appears to be more of a networking issue then sshd specific.
It would be interesting to see the output of netstat -rn before running ifup.
You never posted the ifcfg-eth1 file.
The pid for ssh is different before and after you run the ifup command. Although the boot messages showed everything started ok have you looked at the logs?
If you can not ping the host then your problem appears to be more of a networking issue then sshd specific.
Code:
[root@hw001 ~]# cat netstat-rn.txt
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.220.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
65.44.220.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 192.168.220.1 0.0.0.0 UG 0 0 0 eth1
Code:
It was...
[root@hw001 ~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.220.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
65.44.220.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 65.44.220.1 0.0.0.0 UG 0 0 0 eth0
[root@hw001 ~]#
Fascinating! Do you see? Your default route CHANGES! Your default route should only be set ONCE and on the proper interface to reach the default router. There is your smoking gun.
Fascinating! Do you see? Your default route CHANGES! Your default route should only be set ONCE and on the proper interface to reach the default router. There is your smoking gun.
That's great!!! But I'm not doing anything to cause it. And I don't see a route change. 169.254.0.0 is ICANN. More importantly how do I correct it? I'm ready to reload the server. I've pulled all of my hair out.
BTW, the reason you see an added IP and "venet0" is because the server that is fully functional has Virtuozzo loaded and running. As you know Virtuozzo like KVM and other applications create a virtual ethernet port.
Yes. I have used OpenVZ for years and it has that same characteristic as it is the free version form the same development team.
Code:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.220.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
65.44.220.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 192.168.220.1 0.0.0.0 UG 0 0 0 eth1
explains this problem perfectly. When your networking is NOT working the default route is to the wrong address and the wrong interface.
Make sure that the correct default gateway is set in the eth0 configuration.
Remove the default gateway setting from eth1 so that this WRONG information does not get picked up and eth0 sets the default gateway and port.
This and a network restart and your issue should be resolved.
Yes. I have used OpenVZ for years and it has that same characteristic as it is the free version form the same development team.
Code:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.220.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
65.44.220.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 192.168.220.1 0.0.0.0 UG 0 0 0 eth1
explains this problem perfectly. When your networking is NOT working the default route is to the wrong address and the wrong interface.
Make sure that the correct default gateway is set in the eth0 configuration.
Remove the default gateway setting from eth1 so that this WRONG information does not get picked up and eth0 sets the default gateway and port.
This and a network restart and your issue should be resolved.
Do you know how?
I took the "wrong" gateway out and still no CLI. The default gateway is and has always been 65.44.220.1. I have entered it the same way on all servers. I have used Setup as well. Please explain why I have 24 other servers functioning properly. My IP range is 65.44.220.0-65.44.221.255 - a /23. The netmask is 255.255.254.0. I can use my subnet calculator and arrive at the same IP. Please explain why this is wrong. The default gateway is the first IP + one. Here is another fully functional server:
Code:
[root@hw004 ~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.220.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
65.44.220.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 65.44.220.1 0.0.0.0 UG 0 0 0 eth0
Please understand that I'm not trying to be argumentative but inquisitive. I've setup all of these servers and the gateway has always been what you see. If it is wrong what is right?
+1 for Krazybob for the online subnet calculator link. I provided links earlier, but perhaps less effective.
If you look at what you provided, and what I quoted, when the box boots it is picking up the wrong routing. The default route is to gateway 192.168.220.1 on eth1. THIS is what must be removed.
After you run your ifup command, the gateway is 65.44.220.1 on eth0, and this is clearly the correct value.
I cannot say how this was arrived at, but generally when you set up the second interface and specify things that should be left at default is likely. How it got this way matters less than fixing it.
We now know what to do: find where the BED default gate is being set, and get rid of it. It may be specified in more than one place. (It should not be, but you have a problem that should not be, so expect the unexpected.) Make sure that the RIGHT default gate should be set, and verify that it is set correctly.
Finally we have spoken the same dialect of geek! I didn't realize that I had set the gateway on eth1. Now I see it. Now I see it and feel completely stupid. Dueling gateways. I was so certain I hadn't made a mistake that I didn't see it. I simply edited
Code:
cat /etc/sysconfig/network-scripts/ifcfg-eth1
and removed the GATEWAY line and eth0 came right up after restarting the network. God bless KVM's!
OK. I should probably open a new thread by I'll try asking here first.
My data center is 2 hours away. I'm in Los Angeles and traffic is terrible. I tried a yum -u upgrade and it fails. So does an update. I get file not found errors. Now that I know why 6.9 failed I can drive to the DC and install 6.9 (I can't get to 7.3 yet as I migrate containers) and thought I'd upgrade via KVM.
Code:
Error: Package: matahari-host-0.4.4-11.el6.x86_64 (@anaconda-CentOS-201112091719.x86_64/6.2)
Requires: libqpidclient.so.5()(64bit)
Removing: qpid-cpp-client-0.12-6.el6.x86_64 (@anaconda-CentOS-201112091719.x86_64/6.2)
libqpidclient.so.5()(64bit)
Updated By: qpid-cpp-client-0.14-22.el6_3.x86_64 (base)
Not found
Multiple errors. I know that I can try using --skip-broken to work around the problem but I don't like to kludge the OS.
Technically it does deserve a new thread and this one should be marked SOLVED.
Until then:
It looks like a mismatch and the repo records. In case it is on your end AND you have not modified the repos on that machine out of sync, try this:
Code:
yum clean all
and then try the update again. This will clear all cache and local records, forcing a reload of the lists from the repos.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
