Awrite Dude,
I know you bought one of
the Realtek NICs from Amazon, so figured I'd send you a write up on
this in case you hit across the same frustrating mind-fucking-numblingly
stupid bug.
So, I took my NAS out of service
today to stick a new E-Sata card (and some RAM) in. That parts largely
irrelevant aside from the fact the first boot didn't appear to work, so I
power cycled without plugging a screen in to check.
As it turns out, odds are it had brought networking up.
Enter stupid bug.
When
your bond comes up, as you know, it'll set all slaves to have the same
MAC - which for the purposes of example we'll use '80:08:5'.
So, although prior to bonding you might have
Intel Nic - MAC 80:08:5
Realtek NIC - MAC 01:02:03
Once they're bonded, they'll have show in ifconfig as having MAC 80:08:5
Now,
if you power down the machine uncleanly for a reboot (by, for example,
being impatient and power-cycling), both NICs will have '80:08:5' in RAM
as they're configured MAC.
On the Intel, it
won't matter as the driver reads the permenant MAC from PHY (so flash).
So even if the Intel's true MAC was 04:05:06 it'd still work.
Realtek,
though, are a bunch of twats. The R8169 (and r8168 for that matter)
driver reads the MAC from the NICs RAM. So it'll come back up with MAC
80:08:5.
Cue your bond complaining because it
can't identify a free slave MAC to give to the bond. Systemd-udevd will
also helpfully change the interface name to something like "rename3"
rather than eth0/eth1.
The bond will come up
with a single slave (the Intel NIC) and will otherwise look happy,
unless you check it's slaves /proc/net/bonding/bond0
If
it happens, then the fix is to power the box down, unplug from the
wall, walk around swearing for 10 minutes and then power back up.
So if you find your MAC address changing after a reboot, check for that ;)
--