Hi there --

One of our servers had opensuse 11.1 installed as an upgrade from opensuse 10.3 on Monday of this week, and has lost its network connection twice in as many days. The network cards on the server, of which one is currently in use and the other is up with the same ip address but not currently connected to the network, are the NetXtreme BCM5722 gigabit ethernet PCI express model. The cards are configured to run at 100Mbps Full Duplex with Autonegotiation turned off.

A check of the Online Update utility, with the filter set to Needed Patches, did not list anything at the present time.

The time of the disconnect from the network appears to be around 11:30 at night. This coincides with a cron job that runs a script designed to initiate the freshclam virus definition update script, and subsequently run the clamscan utility. I am suspicious of this being the cause, but it is something that deserves mention.

Has anyone seen this before, and know what the cause is as well as how it can be corrected? Thanks.

Lost its internet connection may be too vague of a description of the problem.

It may be useful to provide more information on what wasn't working when you lost the network connection. Was the interface down (e.g. eth0). Were the route, IP, gateway information altered somehow? Did the kernel driver itself fail or indicate problems in /var/log/messages?

Does the service use a static configuration or are some things supplied by DHCP? Could the problem be dns related?

Look in network related configuration files for files ending in .rpmnew. Are there any unexpected differences that you may need to investigate.

---

Could there be a problem with the switch or router the device connects to? At work we have some devices and autonegotiation will not work with a cisco switch. The switch and devices both need to be manually configured. What I'm asking here is whether network device seems to be working on the server but the connection between the switch and server is down? You may see a link light even when the server is powered down. If there is no link, the interface & switch/router interface have problems.

---

Before the connection went down, you indicated that you had other interfaces. Are you using bonding for redundancy? There was a Linux World magazine article about bonding, and the author had problems because when traffic got very heavy, a switch wouldn't respond to a message from a neighboring router in a timely fashion causing the neighbor to assume that that switch had failed. An alternate connection was enabled, increasing traffic even more, and causing another switch to be overwhelmed. The solution was to use routers in place of switches that would handle route pruning better.

I may have remembered some details incorrectly, but starting a virus scanning job of a networked share would have increased traffic dramatically, so that may have been an indirect trigger rather than a direct cause.

Hi there --

Thanks for your reply. My apologies for any missing information, and hopefully I can fill in the gaps.

The interface did not appear to be down, nor were there any alterations to the route, ip, or gateway information. I did not see anything apparent within the /var/log/messages file.

I checked the /etc/sysconfig/network/ifcfg-eth0 file, and I noticed the ETHTOOL_OPTIONS, NETMASK, and NETWORK lines contained no entries within the single quotes. One thought was to populate the lines in question to read as follows:

What are your thoughts on this approach?

The network device on the server does appear to be working by virtue of its indicator light blinking to indicate a signal has been detected by the device.

I was planning on setting up bonding for redundancy, but in light of what you described, I opted to configure the second NIC to manual rather than at boot time. The reason for manually setting the card to 100Mbps Full Duplex with Autonegotiation turned off is due to the tendency to have the network connection be at Half Duplex when autonegotiation is turned on.

As a workaround, I wrote a script that will check the first NIC by having it do a ping of a remote server. If the echo response is successful, a notification will be sent to the administrator notifying him of the results. If the echo response is negative, the ifdown and subsequent ifup commands will be run, and another notification will be sent out letting the administrator know the latter steps were undertaken to correct the problem.

I did some further checking since the my last posting, and one thing I discovered was there was an alteration in the configuration of the eth0 interface: When the card was brought back up the IP address of the gateway was missing. Due to the DNS servers being located on a different subnet, this prevent hostname resolution. Once that was corrected, everything was back in order.

The questions that follow are:
1. What file(s) do I need to modify in order to have the gateway properly configured?
2. Would this cause the problem that I initially described?
3. Is this a known issue that can be rectified?

AFAIK, normally the route is determined automatically from the IP address and netmask of the interface. Simply, if an IP address falls into the subnet of that interface, that is what the kernels route table indicates. You can enter additional routes either via the route command, the IP command, or using YaST in the device configuration dialog. The additional routes are saved in /etc/sysconfig/network/routes. I'm using DHCP, so I don't have as much to base this on by example.

For the configuration file that was in error, you might want to see which package supplies it if any. "rpm -qf /path/to/file". Then validate that package. Remember that many configuration files themselves have their own manpages.

Maybe an update made the changes. Be on the look out for notices like this in configuration files:
The same holds true for /etc/profile and others.

It is also possible that you have discovered a bug. Maybe an update modified an entry it shouldn't have.

Hi there --

The rpm -qf /etc/sysconfig/network/routes command indicated there were no packages affiliated with the file. When I checked the contents of the file in question, the output was the following:

It appears the system knows what the default gateway should be. One question: what do the two dashes signify?

I'll keep an eye on this, and I am going to modify the script that I mentioned earlier by adding the route command to ensure the correct default gateway is included when the nic is brought back up.

I don't know if this is a similar problem, I posted this on 12-03-08 11.47pm on the SUSE/Novell forum. I first thought that it was system connected, but now I find that it is not so, it is definitely a problem with SUSE 11.0, I find that if I go to surf the net when aMule is running the crash will usualy happen almost immediatly. My Broadband is 8 Gb cable so plenty of bandwith.
Is there a chance that 11.1 may be OK.any ideas ?

Open SUSE 11 losing it's net connection, particularly when using aMule.

I have been using Open SUSE 10.3 for about a year now and have been very pleased. I am now trying Open SUSE 11, it seems good, loads a lot faster than 10.3 and seems to run a little faster. I have had a few probs but they have been resolved with help from these forums. But I have a big prob remaining and I have no idea what could cause it. For no apparent reason I will lose the connection to the net.It happens mostly when running aMule, it can be downloading fine for some while when suddenly the connection to the servers is lost and it won't reconnect, and then also I can not connect to the net with Google etc. The only way to solve it seems to be to shut down, wait awhile then reboot. It will be OK for a while then the problem re-occurs. There does not seem to be a problem with anything else on the system. I know that the Modem is OK as I have three HDD - 1 running Win XP, 2 - running Open Suse 10.3. 3 - running Open Suse 11 & the prob only occurs with SUSE 11, I do not get this problem with either of the other HDD. I have tried three versions of aMule, with SUSE 11,the one given on YAST - v2.2.2-0, & others from Packman v2.2.1-0, & vSVN, the problem occurs with each version so I think it must lie with SUSE 11. I have opened ports 4662 & 4672 on the firewall, & the setup I use is identical to the one on 10.3 which works faultlessly. I use a NTL Modem connected to the PC via Ethernet. Any ideas please.