Question about bonding messages in /var/log/messages

[Dave Laurier]

Hi,

I have a question about the messages generated by the bonding device. On all of our systems the messages related to bonding appear in /var/log/messages:

kernel: tg3: eth1: Link is down.
kernel: bonding: bond0: link status definitely down for interface eth1, disabling it
kernel: bonding: bond0: making interface eth2 the new active one.

However on one of them we see that bonding is working correctly but there are no messages in /var/log/messages. Is this configurable somewhere?

Regards,

Dave

[Vitaly Karasik_1]

this message says that on of the physical interfaces lost network connection. You can check logs/status on your Ethernet switch for more details. IMHO, you should found the reason for these fails and fix it.

[Alexander Chuzhoy]

Probably all your systems have one Network interface card (that is part of the bond) without link, so the bond makes another interface active and logs messages according to definitions in syslog's config file.
The system without messages has all interfaces with link....

[Dave Laurier]

Hi,

I forgot to tell that the example messages do not just occur. They occur whenever we pull out a cable on system A so these messages are not the problem. In fact these messages indicated that the bonding is working correctly on those systems.

However, on system B we do not see these messages, not even when we pull out the cables. Therefore, I would like to know what could be the reason for not seeing these messages although functionaly the bonding is working correctly on system B.

Regards,

Dave

[Alexander Chuzhoy]

check whether syslog service is running and also see if there are differences between syslog.conf on "good machine" and this machine.

[Matti_Kurkela · Accepted solution]

The bonding messages are kernel messages, so there are two possible ways they can appear on the console:

- If the kernel console loglevel is set high enough, the kernel will output the messages directly to the console.

- Regardless of kernel console loglevel, the klogd daemon will pick the messages and forward them to syslogd, with appropriate formatting (i.e. prefixed with "kernel: ").

When the kernel starts up, the default console loglevel is 7 (=display everything, even "debug" messages). When klogd is started, it will usually reduce the kernel loglevel to avoid duplicate messages on the console. The new loglevel can be specified with the -c option of klogd.

Note that this affects only the direct output of kernel messages: the klogd daemon will always get the full set of messages and deliver them to syslogd.

If no -c option is specified, the klogd usually sets the kernel loglevel to some "catastrophic messages only" value. The exact value depends on choices made by the builder of the Linux distribution in question.

[rick jones]

I may rapidly leave my depth, but you might see what appears in dmesg output. Also, you might try with just the interface by itself without bonding - perhaps there is an issue with the driver not getting or not passing-on a link-down indication from the NIC's PHY.

[Alexander Samad]

If you unbond the interfaces and then test them individually, you can use ethtool to look at the state of the interface.

Also check the state of the port on the switch. Once that is working then try rebonding.

I have found that some times, stp can cause a problem, turn of stp for these ports

Then try running the bonded interfaces with just one cable installed. In Syslog you shoud see messages that the bond is coming up.


you can also use ifconfig it will show you any errors coming up on that inerface.