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$(echo .)com \
--cc=Yanjun.Zhu@windriver$(echo .)com \
--cc=alexandre.dietsch@windriver$(echo .)com \
--cc=brian.haley@hp$(echo .)com \
--cc=clinton.slabbert@windriver$(echo .)com \
--cc=davem@redhat$(echo .)com \
--cc=jmorris@namei$(echo .)org \
--cc=kaber@trash$(echo .)net \
--cc=kuznet@ms2$(echo .)inr.ac.ru \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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