Announcement

Collapse
No announcement yet.

networking vs. udev: The battle begins...

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
    #1

    networking vs. udev: The battle begins...

    ...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.

    Please Read Me
    Tags: None
    • Top
    • Bottom
    #2
    I had a corrupted rule in /etc/udev/rules.d change the name of my wlan0 to eth1 once.
    http://www.debianhelp.co.uk/udev.htm
    "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
    – John F. Kennedy, February 26, 1962.
    • Top
    • Bottom

    Comment

      #3
      Little bits of systemd are creeping in. Seems like you've possibly encountered a bug -- I'm pretty sure Ubuntu's implementation of systemd shouldn't go so far as to rename interfaces, and it appears that yours may have tried to do that anyway and failed partway through.

      Or perhaps it's maybe just this: http://askubuntu.com/questions/35478...ded-as-rename3
      • Top
      • Bottom

      Comment

        #4
        Yeah, I thought of that and visited that link already. Problem is my /etc/udev/rules.d/70-persistent-net.rules files looks normal. It lists eth0 and eth1, no "rename3" to be found. It's elsewhere, or some other issue is causing it. "GREP"ing revealed naught.

        I did notice during my searching the way bonding is setup in /etc/network/interfaces is different now, so I tried changing over to the new way of doing things. The results are the same.

        My suspicion is it may have something to do with the way bonding works and the order in which things are occurring. When you bond the ports, all secondary ports and the bond master inherit the Hwaddr of the first ethX port. I wonder if that confuses udev into trying to "fix" things. Possible, re-writing the rules to use another ADDR other than Hwaddr might return normal behavior.

        I have also found the delay during boot is still happening. I either recalled wrong previously, or the initial reboot was not delayed (as my memory thinks) but subsequent boots have been. As I stated, my work around is holding up for now and the 60 second delay in server boot is meaningless. I feel I should make a bug report, but further research and reporting will have to wait until after the holidays and CES.

        Please Read Me
        • Top
        • Bottom

        Comment

          #5
          Have you seen this? Predictable Network Interface Names
          Windows no longer obstructs my view.
          Using Kubuntu Linux since March 23, 2007.
          "It is a capital mistake to theorize before one has data." - Sherlock Holmes​
          • Top
          • Bottom

          Comment

            #6
            More curiosity; My desktop networking is set up in the exact same way as the server, in that it uses port bonding. Both configs are identical except the server insists on using rename3 instead of eth1. The only difference: server is 12.04.3 and desktop is 13.04. This must be a kernel issue as it was not this way until recently.

            Part of the problem with toubleshooting/fixing this is the server is headless. Making adjustments and restarting the network is time consuming to say the least! I'll have to get a keyboard attached to it before I can do much.

            Please Read Me
            • Top
            • Bottom

            Comment

            Previous template Next
            Working...
            X