All of lore.kernel.org
 help / color / mirror / Atom feed
From: stefan novak <lms.brubaker@gmail.com>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: Eric Dumazet <dada1@cosmosbay.com>,
	linux-kernel@vger.kernel.org,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: bond interface arp, vlan and trunk / network question
Date: Mon, 20 Apr 2009 23:03:07 +0200	[thread overview]
Message-ID: <1ef444010904201403s5d583750i1ce3a5da6c6f4059@mail.gmail.com> (raw)
In-Reply-To: <7609.1240259780@death.nxdomain.ibm.com>

>
>        I believe you're seeing the expected behavior from arping here,
> and it does not automatically indicate that anything is wrong.
>
>        It's very possible that your network topology is such that
> arping -I bond0 won't work while arping -I bond0.600 does.  If the
> target you specify is reachable only on the VLAN, it's expected behavior
> that arping -I bond0 of that target won't work (because the interface
> bond0 is not attached to the VLAN, only bond0.600 is).  That doesn't
> mean that the ARPs generated internally by bonding are untagged /
> failing, as bonding itself adds VLAN tags to its own ARP probes as
> needed.

Ok. I've checked the tcpdump's on the machines and I think something is working.

tcpdump  -v -i eth0 arp
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
22:56:38.817599 arp who-has 172.21.0.254 tell 172.21.0.1
22:56:38.847597 arp who-has 172.21.0.254 tell 172.21.0.1
22:56:38.877598 arp who-has 172.21.0.254 tell 172.21.0.1
22:56:38.907596 arp who-has 172.21.0.254 tell 172.21.0.1

tcpdump  -v -i bond0.600 arp
tcpdump: listening on bond0.600, link-type EN10MB (Ethernet), capture
size 96 bytes
22:56:49.167157 arp reply 172.21.0.254 is-at 00:1d:70:d1:ad:83 (oui Unknown)
22:56:49.197162 arp reply 172.21.0.254 is-at 00:1d:70:d1:ad:83 (oui Unknown)
22:56:49.227130 arp reply 172.21.0.254 is-at 00:1d:70:d1:ad:83 (oui Unknown)
22:56:49.257144 arp reply 172.21.0.254 is-at 00:1d:70:d1:ad:83 (oui Unknown)

the arp's are sent out on eth0 and recieved via bond0.600. When they
are sent on eth0 then the switch must tag the vlan600 (private vlan).
Then they come in at the right interface. Is it normal that so many
arp's are sent?
Is there a way to check if the arp check is working right in the proc
fs oder something like that?

>        Also, are you running multiple blades with bonding behind the
> same set of switches?

Yes, 14 blades with 2 seperate(not connected) switches.

>  If you are, you probably want to set the
> arp_validate option to either "active" or "all", as the default setting
> (none) relies only on the existance of traffic on the slaves, and
> doesn't check the source of that traffic.  The end result of that is the
> probes from multiple bonding instances fool one another into thinking
> the path is up, when it is not.  With arp_validate enabled, it'll check
> that the slaves are actually receiving their own ARP traffic.

Ok, sounds right for me. I've set the arp_validate option to "all".

  reply	other threads:[~2009-04-20 21:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-20 17:50 bond interface arp, vlan and trunk / network question stefan novak
2009-04-20 18:16 ` Eric Dumazet
2009-04-20 18:37   ` Jay Vosburgh
2009-04-20 20:00     ` stefan novak
2009-04-20 20:36       ` Jay Vosburgh
2009-04-20 21:03         ` stefan novak [this message]
2009-04-20 21:15           ` Eric Dumazet
2009-04-20 21:23           ` Jay Vosburgh
2009-04-20 21:39             ` stefan novak
2009-04-21  0:01               ` Jay Vosburgh
2009-04-22  8:29                 ` stefan novak
2009-04-23  1:12                   ` Jay Vosburgh
2009-04-23  5:58                     ` Eric Dumazet
2009-04-23 15:38                       ` Jay Vosburgh
2009-04-23  7:48                     ` Jiri Pirko
2009-04-23 14:59                       ` Jay Vosburgh
2009-04-23 15:20                         ` Jiri Pirko
2009-04-23 18:34                           ` Jay Vosburgh
2009-04-23 19:22                             ` Jiri Pirko

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=1ef444010904201403s5d583750i1ce3a5da6c6f4059@mail.gmail.com \
    --to=lms.brubaker@gmail.com \
    --cc=dada1@cosmosbay.com \
    --cc=fubar@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.