Lost Packets – Bond

Home » CentOS » Lost Packets – Bond
CentOS 2 Comments

Guys, good afternoon

I’m using in my bond interfaces as active backup, in theory, should assume an interface (or work) only when another interface is down.

But I’m just lost packets on the interface that is not being used and is generating packet loss on bond.

What can that be?

Follow my settings bond

[root@xxxxx ~]# ifconfig bond0 ; ifconfig eth0 ; ifconfig eth1
bond0 Link encap:Ethernet HWaddr 2C:59:E5:3C:71:68
inet addr:10.104.x.x Bcast:10.104.172.255 Mask:255.255.255.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:38386574 errors:0 dropped:1295024 overruns:0 frame:0
TX packets:34733102 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:23626317629 (22.0 GiB) TX bytes:21028389425 (19.5 GiB)

eth0 Link encap:Ethernet HWaddr 2C:59:E5:3C:71:68
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:37091397 errors:0 dropped:0 overruns:0 frame:0
TX packets:34732869 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:23524827730 (21.9 GiB) TX bytes:21028299937 (19.5 GiB)

eth1 Link encap:Ethernet HWaddr 2C:59:E5:3C:71:68
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1295179 errors:0 dropped:1294944 overruns:0 frame:0
TX packets:237 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:101490019 (96.7 MiB) TX bytes:90360 (88.2 KiB)

[root@xxxxx ~]#

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

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None Currently Active Slave: eth0
MII Status: up MII Polling Interval (ms): 1000
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth0
MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0
Permanent HW addr: 2c:59:e5:3c:71:68
Slave queue ID: 0

Slave Interface: eth1
MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0
Permanent HW addr: 2c:59:e5:3c:71:6c Slave queue ID: 0

[root@xxxxx ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR.104.x.x NETMASK%5.255.255.0
ONBOOT=yes BOOTPROTO=none USERCTL=no BONDING_OPTS=”mode=1 miimon00″

In /var/log/messages I have a lot martian source ….

[root@xxxxx ~]# tail -f /var/log/messages Sep 17 13:26:38 xxxxx kernel: IPv4: martian source 10.104.172.0 from 0.0.0.0, on dev bond0
Sep 17 13:26:38 xxxxx kernel: ll header: 00000000: ff ff ff ff ff ff 00 00 00 00 5b
00 08 00 ……….[… Sep 17 13:26:39 xxxxx kernel: IPv4: martian source 10.104.172.0 from 0.0.0.0, on dev bond0
Sep 17 13:26:39 xxxxx kernel: ll header: 00000000: ff ff ff ff ff ff 00 00 00 00 5b
01 08 00 ……….[… Sep 17 13:26:39 xxxxx kernel: IPv4: martian source 10.104.172.0 from 0.0.0.0, on dev bond0
Sep 17 13:26:39 xxxxx kernel: ll header: 00000000: ff ff ff ff ff ff 00 00 00 00 5b
00 08 00 ……….[… Sep 17 13:26:39 xxxxx kernel: IPv4: martian source 10.104.172.0 from 0.0.0.0, on dev bond0
Sep 17 13:26:39 xxxxx kernel: ll header: 00000000: ff ff ff ff ff ff 00 00 00 00 5b
00 08 00 ……….[… Sep 17 13:26:39 xxxxx kernel: IPv4: martian source 10.104.172.0 from 0.0.0.0, on dev bond0
Sep 17 13:26:39 xxxxx kernel: ll header: 00000000: ff ff ff ff ff ff 00 00 00 00 5b
01 08 00 ……….[… Sep 17 13:26:43 xxxxx kernel: net_ratelimit: 69 callbacks suppressed

Thks ….

2 thoughts on - Lost Packets – Bond

  • My suspicion is that the bonding may be irrelevant here. You can drop packets with our without bonding.

    There are many reasons why packets can be dropped, but one common one is a too-slow consumer of those packets. For example, say you are trying to watch a streaming ultra-high-definition video on a system with low memory and a slow CPU: the kernel can only buffer so many packets before it has to start dropping them.

    It’s hard to suggest a solution without knowing the exact cause. But one thing to try (as much for debugging as an actual solution) is to increase your buffer sizes.

  • If memory serves, all those martians are accounted as drops. Please check that number of drops against netstat -s output, there will be a line for martian source drops. Hope the numbers match (at least closely).

    Yet, broadcasts using such source address are not expected, are they?

    Marcelo