From: Weiping Pan <panweiping3@gmail.com>
To: Andy Gospodarek <andy@greyhouse.net>
Cc: netdev@vger.kernel.org, bonding-devel@lists.sourceforge.net,
Linda Wang <lwang@redhat.com>
Subject: Re: bonding can't change to another slave if you ifdown the active slave
Date: Mon, 07 Mar 2011 12:20:31 +0800 [thread overview]
Message-ID: <4D745D0F.9090604@gmail.com> (raw)
In-Reply-To: <20110305025332.GR11864@gospo.rdu.redhat.com>
On 03/05/2011 10:53 AM, Andy Gospodarek wrote:
> On Fri, Mar 04, 2011 at 10:15:17AM +0800, Weiping Pan wrote:
>> Hi,
>>
>> I'm doing some Linux bonding driver test, and I find a problem in
>> balance-rr mode.
>> That's it can't change to another slave if you ifdown the active slave.
>> Any comments are warmly welcomed!
>>
>> regards
>> Weiping Pan
>>
>> My host is Fedora 14, and I install VirtualBox (4.0.2), and enable 4
>> nics for the guest system.
> Does this mean you are passing 4 NICs from your host to your guest
> (maybe via direct pci-device assignment to the guest) or are you
> creating 4 virtual devices on the host that are in a bridge group on the
> host?
>
> [...]
I use bridge mode in virtualbox.
[root@localhost ~]# VBoxManage showvminfo
67b83c47-0ee2-46bc-b0ff-e0eb43edc1c2 |grep ^NIC
NIC 1: MAC: 0800270481A8, Attachment: Bridged Interface
'eth0', Cable connected: on, Trace: off (file: none), Type: 82540EM,
Reported speed: 0 Mbps, Boot priority: 0
NIC 2: MAC: 08002778F641, Attachment: Bridged Interface
'eth0', Cable connected: on, Trace: off (file: none), Type: 82540EM,
Reported speed: 0 Mbps, Boot priority: 0
NIC 3: MAC: 080027C408BA, Attachment: Bridged Interface
'eth0', Cable connected: on, Trace: off (file: none), Type: 82540EM,
Reported speed: 0 Mbps, Boot priority: 0
NIC 4: MAC: 080027DB339A, Attachment: Bridged Interface
'eth0', Cable connected: on, Trace: off (file: none), Type: 82540EM,
Reported speed: 0 Mbps, Boot priority: 0
NIC 5: disabled
NIC 6: disabled
NIC 7: disabled
NIC 8: disabled
>> [root@localhost ~]# ifconfig eth7 down
> This is not a great way to test link failure with bonding. The best way
> is to actually pull the cable so the interface is truly down.
Ok.
But I think bonding should work in such condition.
>> [root@localhost ~]# dmesg
>> [ 304.496463] bonding: Ethernet Channel Bonding Driver: v3.6.0
>> (September 26, 2009)
>> [ 304.496468] bonding: MII link monitoring set to 100 ms
>> [ 353.527680] ADDRCONF(NETDEV_UP): bond0: link is not ready
>> [ 355.321626] e1000: eth7 NIC Link is Up 1000 Mbps Full Duplex, Flow
>> Control: RX
>> [ 355.322250] bonding: bond0: enslaving eth7 as an active interface
>> with an up link.
>> [ 355.323503] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
>> [ 365.394052] bond0: no IPv6 routers present
>> [ 510.913797] e1000: eth8 NIC Link is Up 1000 Mbps Full Duplex, Flow
>> Control: RX
>> [ 510.917312] bonding: bond0: enslaving eth8 as an active interface
>> with an up link.
>> [ 592.208534] bonding: bond0: link status definitely down for interface
>> eth7, disabling it
> I suspect I know, but what does /proc/net/bonding/bond0 look like?
[root@localhost ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth7
MII Status: down
Link Failure Count: 1
Permanent HW addr: 08:00:27:04:81:a8
Slave Interface: eth8
MII Status: up
Link Failure Count: 0
Permanent HW addr: 08:00:27:db:33:9a
> [...]
>> And meanwhile,
>> [root@localhost ~]# tcpdump -i bond0 -p arp
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
>> 02:46:56.983092 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
>> length 28
>> 02:46:57.984040 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
>> length 28
>> 02:46:58.988442 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
>> length 28
>> 02:47:00.987340 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
>> length 28
>> 02:47:01.988136 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
>> length 28
>> 02:47:02.990033 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
>> length 28
>> 02:47:04.985086 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
>> length 28
>> 02:47:05.992368 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
>> length 28
>> 02:47:06.996727 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
>> length 28
>> 02:47:17.231106 ARP, Request who-has dhcp-65-32.nay.redhat.com tell
>> dhcp-65-180.nay.redhat.com, length 46
>> ^C
>> 10 packets captured
>> 10 packets received by filter
>> 0 packets dropped by kernel
>>
>>
> What does a tcpdump on eth0 look like? I'm curious if these arp
> requests make it there or if the responses are the frames being dropped
> (possibly by the connected bridge/switch).
on host,
[root@localhost ~]# tcpdump -i eth0 -p arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:18:24.885306 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:24.885320 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:26.880019 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:26.880030 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:27.881584 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:27.881593 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:28.883657 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:28.883671 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:30.881699 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:30.881709 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:31.885003 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:31.885012 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:31.942278 ARP, Request who-has dhcp-65-14.nay.redhat.com tell
corerouter.nay.redhat.com, length 46
12:18:32.721861 ARP, Request who-has dhcp-65-29.nay.redhat.com tell
corerouter.nay.redhat.com, length 46
12:18:32.888740 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
12:18:32.888748 ARP, Request who-has 192.168.1.100 tell 192.168.1.5,
length 28
[root@localhost ~]# ip route show
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
10.66.64.0/23 dev eth0 proto kernel scope link src 10.66.65.228
metric 1
default via 10.66.65.254 dev eth0 proto static
[root@localhost ~]# ip neigh show
192.168.1.5 dev eth0 lladdr 08:00:27:04:81:a8 STALE
10.66.65.254 dev eth0 lladdr 00:1d:45:20:d5:ff REACHABLE
regards
Weiping Pan
next prev parent reply other threads:[~2011-03-07 4:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-04 2:15 bonding can't change to another slave if you ifdown the active slave Weiping Pan
2011-03-05 0:38 ` Jay Vosburgh
2011-03-07 3:23 ` Weiping Pan
2011-03-05 2:53 ` Andy Gospodarek
2011-03-05 13:49 ` Nicolas de Pesloüan
2011-03-07 3:13 ` Weiping Pan
2011-03-07 21:15 ` Nicolas de Pesloüan
2011-03-07 4:20 ` Weiping Pan [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-03-08 6:52 Weiping Pan
2011-03-08 12:51 ` WANG Cong
2011-03-09 2:40 ` Weiping Pan
2011-03-09 6:02 ` Américo Wang
2011-03-09 3:38 ` Weiping Pan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D745D0F.9090604@gmail.com \
--to=panweiping3@gmail.com \
--cc=andy@greyhouse.net \
--cc=bonding-devel@lists.sourceforge.net \
--cc=lwang@redhat.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).