Two interfaces, eth0 and eth1 are part of a network bonding bond0 on CentOS 6.All worked well under CentOS 5, but after the upgrade to CentOS 6.6, keeping the same configuration, the network works fine butdespite setting /etc/modprobe.d/bonding.conf with options mode=1 or even mode=active-backup, the status from /proc/net/bonding/bond0 always shows load balancing (round-robin), not active-backup as it should.doing a ping to a LAN address (that belongs to bond0 network) for the first time after a reboot, the first frame is DUP! (duplicated), the DUP doesn't happen anymore on further pings. Likely due to round-robin instead of active-backup/etc/modprobe.d/bonding.conf:alias bond0 bondingoptions bond0 mode=1 miimon=100ifcfg-bond0:DEVICE=bond0BOOTPROTO=noneONBOOT=yesNETWORK=10.1.1.0NETMASK=255.255.255.0IPADDR=10.1.1.11USERCTL=noNM_CONTROLLED=noifcfg-eth0:DEVICE=eth0BOOTPROTO=noneHWADDR=00:22:35:12:26:18UUID=12fa32c2-e421-47f6-8d25-11414a664318TYPE=EthernetONBOOT=yesNM_CONTROLLED=noMASTER=bond0SLAVE=yesUSERCTL=noifcfg-eth1:DEVICE=eth1BOOTPROTO=noneHWADDR=00:22:35:12:26:19UUID=12fa32c2-e421-47f6-8d25-11414a664319TYPE=EthernetONBOOT=yesNM_CONTROLLED=noMASTER=bond0SLAVE=yesUSERCTL=noAll updates have been applied. NetworkManager is disabled.The main problem seems now to be the mode, round-robin instead of active-backup.
CentOS 6 interfaces bonding, round-robin instead of active-backup, duplicates frames
centos;network interface;duplicate;bonding
After some deeper investigation, found the problem for the round-robin and DUP problems. They are actually related.round robin (0) instead of active-backup (1)On CentOS 5+, and seemingly especially 6.6, it recommended / preferred to use the BONDING_OPTS parameter directly in ifcfg-bond0 (and not in the bonding module options, that makes sense)DEVICE=bond0...BONDING_OPTS=mode=1 miimon=100(mode may be specified as '1' or as 'active-backup')After adding the line, everything worked as expected.duplicated ping framesIn round-robin mode, both interfaces are used. And when the interfaces are connected to two different switches, the early ping replies may be duplicatedIt is not uncommon to observe a short burst of duplicated traffic when  the bonding device is first used, or after it has been idle for some  period of time.  This is most easily observed by issuing a ping to  some other host on the network, and noticing that the output from ping  flags duplicates (typically one per slave).For example, on a bond in active-backup mode with five slaves all  connected to one switch, the output may appear as follows:    # ping -n 10.0.4.2    PING 10.0.4.2 (10.0.4.2) from 10.0.3.10 : 56(84) bytes of data.    64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.7 ms    64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)This is not due to an error in the bonding driver, rather, it is a  side effect of how many switches update their MAC forwarding tables.After switching to active-backup, no more DUPs were observed.This is explained in details in this invaluably knowledgeable documentationhttps://www.kernel.org/doc/Documentation/networking/bonding.txt