Bond & Team: RX Dropped Packets

Home » CentOS » Bond & Team: RX Dropped Packets
CentOS 1 Comment

Hi all,

we are testing CentOS 7 in order to migrate from Scientific Linux 6 /
CentOS 6 and we are facing an issue with the network. Trying to configure network with teaming in activebackup mode or also with bonding in mode=1
(active backup as well) we see many RX dropped packets in the bond0
interface (around 10% of the total), 100% RX drops in the backup interface and 0% in the active interface. Current kernel is
3.10.0-229.7.2.el7.x86_64, and I tried with included ixgbe driver (4.0.1)
and with by compiling the newest version (ixgbe-4.1.1-1.x86_64), results are the same. We use tagged VLANs, but switch has configured a correct VLAN, a we saw no problems when this machine was running Scientific Linux 6
(CentOS 6-like system).

Any ideas?

[root@dc106 ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: enp6s0 (primary_reselect always)
Currently Active Slave: enp6s0
MII Status: up MII Polling Interval (ms): 100
Up Delay (ms): 600000
Down Delay (ms): 0

Slave Interface: enp6s0
MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0
Permanent HW addr: 00:1b:21:91:aa:c5
Slave queue ID: 0

Slave Interface: enp7s0f0
MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0
Permanent HW addr: 00:25:90:1a:2d:aa Slave queue ID: 0

[root@dc106 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=193.109.172.106
NETMASK=255.255.255.128
USERCTL=no BOOTPROTO=none ONBOOT=yes MTU=9000
IPV6ADDR=2001:67c:1148:200::106
TYPE=Bond BONDING_MASTER=yes NM_CONTROLLED=no BONDING_OPTS=”options bonding mode=1 primary=enp6s0 miimon=100
updelay=600000″

[root@dc106 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp7s0f0
# Network slave interface DEVICE=enp7s0f0
USERCTL=no ONBOOT=yes MASTER=bond0
SLAVE=yes BOOTPROTO=none HWADDR=00:25:90:1A:2D:AA
NM_CONTROLLED=no

[root@dc106 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp6s0
# Network slave interface DEVICE=enp6s0
USERCTL=no ONBOOT=yes MASTER=bond0
SLAVE=yes BOOTPROTO=none HWADDR=00:1B:21:91:AA:C5
NM_CONTROLLED=no

[root@dc106 ~]# ifconfig enp6s0
enp6s0: flags=6211 mtu 9000
ether 00:1b:21:91:aa:c5 txqueuelen 50000 (Ethernet)
RX packets 19815269 bytes 1317959345 (1.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 126023402 bytes 1134827686804 (1.0 TiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

[root@dc106 ~]# ifconfig enp7s0f0
enp7s0f0: flags=6211 mtu 9000
ether 00:1b:21:91:aa:c5 txqueuelen 50000 (Ethernet)
RX packets 29436 bytes 1768642 (1.6 MiB)
RX errors 0 dropped 29436 overruns 0 frame 0
TX packets 10 bytes 1275 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xfafe0000-faffffff

[root@dc106 ~]# ifconfig bond0
bond0: flags=5187 mtu 9000
inet 193.109.172.106 netmask 255.255.255.128 broadcast
193.109.172.127
ether 00:1b:21:91:aa:c5 txqueuelen 50000 (Ethernet)
RX packets 19844789 bytes 1319735635 (1.2 GiB)
RX errors 0 dropped 1960770 overruns 0 frame 0
TX packets 126023464 bytes 1134827699315 (1.0 TiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Thanks a lot,
—
Marc Caubet Serrabou PIC (Port d’Informació Científica)
Campus UAB, Edificio D
E-08193 Bellaterra, Barcelona Tel: +34 93 581 33 22
Fax: +34 93 581 41 10
http://www.pic.es Avis – Aviso – Legal Notice: http://www.ifae.es/legal.html

One thought on - Bond & Team: RX Dropped Packets

  • I had this issue with an oracle linux and mode 6. They told me that the new driver version was counting as dropped packets all the packets that where not intended for a bond member… Quoting:

    “This is not a bug. All kernels prior to 2.6.37 do not record packets that are received on an interface for which there is no handler. Recording all dropped packets is by design and is intentional from
    2.6.37.In the case of active-backup bonds, this includes all packets sent to passive interface. Other packets that will be dropped include broadcast packets that are of no interest to the host.

    Note that the “dropped” in ifconfig count situations where a packet was successfully received, but the kernel *chose* to drop the packet because it had no handler for the data in the packet. So, the drop counters are entirely normal (if strange-looking); however, they can point to traffic being on the network that isn’t intended to be there
    (such as misconfigured/rogue hosts).”

    —
    Marcelo

    “¿No será acaso que esta vida moderna está teniendo más de moderna que de vida?” (Mafalda)