...This is really more for discussion rather than caring about an actual solution. Although, the answer to the problem may be needed eventually.
I was trouble shooting a network wiring issue today at my switch and I noticed one of the NIC's on my server was off-line. I did notice an excessive delay during network startup a couple weeks ago when I rebooted the server, but I ignored it.
Curious, I logged in to the server and did a quick ifconfig and sure enough, only one was listed. I added "-a" to the ifconfig and saw that eth1 wasn't there, but some interface name "rename3" was. Don't have to be a genius to figure out the "what?" - udev renamed my second NIC. dmesg confirms this. But the "why?" is still in the unknown.
First thing was to verify it wasn't some sort of hardware failure. I figured the best way to test that was to try and bring the "rename3" device up.
BTW: I use port aggregation (AKA bonding) on my server and my primary desktop using the "round-robin" policy. Which basically means both NIC's are used to double effective transfer rate, but if one fails the other takes the full load. This is why I hadn't noticed the failed NIC.
So, I added "rename3" to the list of ifenslave devices and rebooted. No real surprise: The boot time network start was back to the old speedy level and ifconfig showed eth0 and rename3 nicely enslaved and the lights on the switch confirmed same.
This is rather newish behavior as the first time I noticed the delay at boot time was only a few weeks ago. I'm not sure this rises to the level of "bug" but it's damned annoying and unnecessary for sure. My understanding of the issue is I can re-write the udev net rule and fix it, but why should I have too? Besides, I have no guarantee udev won't throw me a curve ball and change the name again. I suspect it might have something to do with the port bonding and cloned MAC addresses, but I'm not sure. Irksome at best. At worst: stomping around while throwing my hands in the air and swearing profusely.
So at this point - since I'm planning on upgrading to 14.04 when it settles - I'm probably not going to fix this beyond what I've already done until and unless Trusty exhibits the same behavior, because I'm rather busy at the moment and my work around is doing the job. I posted it just in case others new a solid fix or were having the same issue. Thanks for reading.
I was trouble shooting a network wiring issue today at my switch and I noticed one of the NIC's on my server was off-line. I did notice an excessive delay during network startup a couple weeks ago when I rebooted the server, but I ignored it.
Curious, I logged in to the server and did a quick ifconfig and sure enough, only one was listed. I added "-a" to the ifconfig and saw that eth1 wasn't there, but some interface name "rename3" was. Don't have to be a genius to figure out the "what?" - udev renamed my second NIC. dmesg confirms this. But the "why?" is still in the unknown.
First thing was to verify it wasn't some sort of hardware failure. I figured the best way to test that was to try and bring the "rename3" device up.
BTW: I use port aggregation (AKA bonding) on my server and my primary desktop using the "round-robin" policy. Which basically means both NIC's are used to double effective transfer rate, but if one fails the other takes the full load. This is why I hadn't noticed the failed NIC.
So, I added "rename3" to the list of ifenslave devices and rebooted. No real surprise: The boot time network start was back to the old speedy level and ifconfig showed eth0 and rename3 nicely enslaved and the lights on the switch confirmed same.
This is rather newish behavior as the first time I noticed the delay at boot time was only a few weeks ago. I'm not sure this rises to the level of "bug" but it's damned annoying and unnecessary for sure. My understanding of the issue is I can re-write the udev net rule and fix it, but why should I have too? Besides, I have no guarantee udev won't throw me a curve ball and change the name again. I suspect it might have something to do with the port bonding and cloned MAC addresses, but I'm not sure. Irksome at best. At worst: stomping around while throwing my hands in the air and swearing profusely.
So at this point - since I'm planning on upgrading to 14.04 when it settles - I'm probably not going to fix this beyond what I've already done until and unless Trusty exhibits the same behavior, because I'm rather busy at the moment and my work around is doing the job. I posted it just in case others new a solid fix or were having the same issue. Thanks for reading.
Comment