From: Ulf Samuelsson <ulf.samuelsson@ericsson.com>
To: David Miller <davem@redhat.com>, <Yanjun.Zhu@windriver.com>
Cc: <brian.haley@hp.com>, <alexandre.dietsch@windriver.com>,
<clinton.slabbert@windriver.com>, <kuznet@ms2.inr.ac.ru>,
<jmorris@namei.org>, <kaber@trash.net>, <netdev@vger.kernel.org>
Subject: Re: [PATCH V2 0/1] neighbour: Support broadcast ARP in neighbor PROPE state
Date: Mon, 16 Mar 2015 13:39:47 +0100 [thread overview]
Message-ID: <5506CF13.5070501@ericsson.com> (raw)
In-Reply-To: <20150312.152247.1607789216159086520.davem@redhat.com>
On 03/12/2015 08:22 PM, David Miller wrote:
> Like Yoshifuji and others I agree that:
>
> 1) You can get working behavior by adjusting existing sysctls.
>
> 2) IPV4 ARP and IPV6 NDISC are not different in this regard.
>
> I'm really tired of all of these ARP hacks being submitted recently,
> and I want people to think more deeply about what they are proposing
> first.
Which sysctls are you referring to?
As I can see it, there are three sysctls that control this.
ucast_solicit.
mcast_solicit
app_solicit.
If you think any other sysctl is useful here, which one?
From Documentation/networking/ip-sysctl.txt.
+++++++++++++
app_solicit - INTEGER
The maximum number of probes to send to the user space ARP daemon
via netlink before dropping back to multicast probes (see
mcast_solicit). Defaults to 0.
----------------------------
so that ain't it.
If you disagree, what should the Documentation look like?
=============================================
From net/core/neighbour.c(timer_handler):
if ((neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) &&
atomic_read(&neigh->probes) >= neigh_max_probes(neigh)) {
neigh->nud_state = NUD_FAILED;
notify = 1;
neigh_invalidate(neigh);
goto out;
}
From net/core/neighbour.c(neigh_max_probes):
static __inline__ int neigh_max_probes(struct neighbour *n)
{
struct neigh_parms *p = n->parms;
int max_probes = NEIGH_VAR(p, UCAST_PROBES) + NEIGH_VAR(p, APP_PROBES);
if (!(n->nud_state & NUD_PROBE))
max_probes += NEIGH_VAR(p, MCAST_PROBES);
return max_probes;
}
=============================================
If we simplify this when we are in NUD_PROBE state we see:
=============================================
if (atomic_read(&neigh->probes) >= NEIGH_VAR(p, UCAST_PROBES) +
NEIGH_VAR(p, APP_PROBES)) {
neigh->nud_state = NUD_FAILED;
notify = 1;
neigh_invalidate(neigh);
goto out;
}
=============================================
Since APP_PROBES is 0, and according to documentation has nothing to do
with Broadcast:
=============================================
if (atomic_read(&neigh->probes) >= NEIGH_VAR(p, UCAST_PROBES)) {
neigh->nud_state = NUD_FAILED;
notify = 1;
neigh_invalidate(neigh);
goto out;
}
=============================================
so we will send out "ucast_solicit" unikcast probes, and then we will
enter FAILED state.
mcast_solicit is ignored when in NUD_PROBE state.
"mcast_solicit" is only used when in NUD_INCOMPLETE state, and
broadcasts will never
be sent out by the stack for an entry, once it is in NUD_REACHABLE for
the first time.
I would be happy, if you can show me that I have misunderstood something.
Best Regards,
Ulf Samuelsson
next prev parent reply other threads:[~2015-03-16 12:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-12 6:58 [PATCH V2 0/1] neighbour: Support broadcast ARP in neighbor PROPE state Zhu Yanjun
2015-03-12 6:58 ` [PATCH V2 1/1] " Zhu Yanjun
2015-03-12 10:05 ` YOSHIFUJI Hideaki/吉藤英明
2015-03-12 7:10 ` [PATCH V2 0/1] " yzhu1
2015-03-12 8:42 ` YOSHIFUJI Hideaki
2015-03-12 8:59 ` Ulf samuelsson
2015-03-12 9:28 ` YOSHIFUJI Hideaki/吉藤英明
2015-03-12 9:45 ` Ulf samuelsson
2015-03-12 10:16 ` YOSHIFUJI Hideaki
2015-03-18 8:51 ` Ulf Samuelsson
2015-03-18 10:34 ` YOSHIFUJI Hideaki/吉藤英明
2015-03-18 12:15 ` Ulf Samuelsson
2015-03-18 13:22 ` YOSHIFUJI Hideaki/吉藤英明
2015-03-18 15:12 ` Ulf Samuelsson
2015-03-19 2:42 ` yzhu1
2015-03-19 2:14 ` yzhu1
2015-03-19 2:24 ` yzhu1
2015-03-12 19:22 ` David Miller
2015-03-16 12:39 ` Ulf Samuelsson [this message]
2015-03-19 5:52 ` yzhu1
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=5506CF13.5070501@ericsson.com \
--to=ulf.samuelsson@ericsson.com \
--cc=Yanjun.Zhu@windriver.com \
--cc=alexandre.dietsch@windriver.com \
--cc=brian.haley@hp.com \
--cc=clinton.slabbert@windriver.com \
--cc=davem@redhat.com \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--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.