On Sat, 6 Jan 2018 17:25:20 +0800
邢庆杰 wrote:
> We create bond0 and add eth0ð1 as slaves. Eth0 is active. Then we add
> bond0
> into br0 as a bridge port. Br0 has ip address. When eth0 is down, after
> bond0's
> failover eth1 become active. At this moment, we need br0 send a g
From: John Allen
Send gratuitous arp after any reset.
Signed-off-by: John Allen
---
drivers/net/ethernet/ibm/ibmvnic.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index 1f7cf6f..465a8fa 100644
--- a/drivers
On Wed, May 24, 2017 at 11:32 PM, Ihar Hrachyshka wrote:
> On 05/23/2017 01:56 PM, Arnd Bergmann wrote:
>>
>> This seems to have caused a build warning:
>>
>> net/ipv4/arp.c:880:35: warning: 'addr_type' may be used uninitialized
>> in this function [-Wmaybe-uninitialized]
>>
> Not sure. How do you
On 05/23/2017 01:56 PM, Arnd Bergmann wrote:
This seems to have caused a build warning:
net/ipv4/arp.c:880:35: warning: 'addr_type' may be used uninitialized
in this function [-Wmaybe-uninitialized]
Not sure. How do you reproduce it? I just did 'make net' in the latest
tree that includes the p
On Thu, May 18, 2017 at 9:41 PM, Ihar Hrachyshka wrote:
> This patchset is spurred by discussion started at
> https://patchwork.ozlabs.org/patch/760372/ where we figured that there is no
> real reason for enforcing override by gratuitous ARP packets only when
> arp_accept is 1. Same s
From: Ihar Hrachyshka
Date: Thu, 18 May 2017 12:41:17 -0700
> This patchset is spurred by discussion started at
> https://patchwork.ozlabs.org/patch/760372/ where we figured that there is no
> real reason for enforcing override by gratuitous ARP packets only when
> arp_accept is 1.
Currently, when arp_accept is 1, we always override existing neigh
entries with incoming gratuitous ARP replies. Otherwise, we override
them only if new replies satisfy _locktime_ conditional (packets arrive
not earlier than _locktime_ seconds since the last update to the neigh
entry).
The idea
This patchset is spurred by discussion started at
https://patchwork.ozlabs.org/patch/760372/ where we figured that there is no
real reason for enforcing override by gratuitous ARP packets only when
arp_accept is 1. Same should happen when it's 0 (the default value).
changelog v2: handled r
Hello,
On Wed, 17 May 2017, Ihar Hrachyshka wrote:
> Currently, when arp_accept is 1, we always override existing neigh
> entries with incoming gratuitous ARP replies. Otherwise, we override
> them only if new replies satisfy _locktime_ conditional (packets arrive
> not
Currently, when arp_accept is 1, we always override existing neigh
entries with incoming gratuitous ARP replies. Otherwise, we override
them only if new replies satisfy _locktime_ conditional (packets arrive
not earlier than _locktime_ seconds since the last update to the neigh
entry).
The idea
Good day.
This patchset is spurred by discussion started at
https://patchwork.ozlabs.org/patch/760372/ where we figured that there is no
real reason for enforcing override by gratuitous ARP packets only when
arp_accept is 1. Same should happen when it's 0 (the default value).
The first pat
when a gratuitous arp is received and arp_accept is set")
>
> There is a glitch in the patch though. RFC 2002, section 4.6, "ARP,
> Proxy ARP, and Gratuitous ARP", defines gratuitous ARPs so that they can
> be either of Request or Reply type. Those Reply gratuitous ARPs c
When arp_accept is 1, gratuitous ARPs are supposed to override matching
entries irrespective of whether they arrive during locktime. This was
implemented in commit 56022a8fdd87 ("ipv4: arp: update neighbour address
when a gratuitous arp is received and arp_accept is set")
There is a gli
When arp_accept is 1, gratuitous ARPs are supposed to override matching
entries irrespective of whether they arrive during locktime. This was
implemented in commit 56022a8fdd87 ("ipv4: arp: update neighbour address
when a gratuitous arp is received and arp_accept is set")
There is a gli
From: Ihar Hrachyshka
Date: Tue, 9 May 2017 17:16:07 -0700
> @@ -842,8 +844,20 @@ static int arp_process(struct net *net, struct sock *sk,
> struct sk_buff *skb)
> It is possible, that this option should be enabled for some
> devices (strip is candidate)
>
When arp_accept is 1, gratuitous ARPs are supposed to override matching
entries irrespective of whether they arrive during locktime. This was
implemented in commit 56022a8fdd87 ("ipv4: arp: update neighbour address
when a gratuitous arp is received and arp_accept is set")
There is a gli
From:
Date: Thu, 2 Mar 2017 14:59:47 +0100
> @@ -836,19 +843,30 @@ static int arp_process(struct net *net, struct sock
> *sk, struct sk_buff *skb)
> n = __neigh_lookup(&arp_tbl, &sip, dev, 0);
>
> if (IN_DEV_ARP_ACCEPT(in_dev)) {
> - unsigned int addr_type = inet_addr_t
From: Tomasz Dzieciol
Fix an issue where is_garp variable is not set when arp_accept option is
disabled for a net device. There might be a situation where gratuitous ARP
will be ignored when an existing neighbour is updated in a time smaller
than LOCKTIME (for example by a timer - transition
> So, assuming that proives stable, I have a workaround - but one that
> needs knowlege of A) the unterlying interface (brport) to fondle, and
> B) the macvlan MAC address that needs adding. keepalived couldn't
> easily do that "in code" because it does not know what sits under the
> bridge.
>
> N
On Thu, Apr 21, 2016 at 12:31 PM, Toshiaki Makita
wrote:
> On 2016/04/21 15:37, Patrick Schaaf wrote:
> (I understand the problem happens only if you use macvlan on the bridge
> device. If wrong, correct me.)
That is my understanding, yes. That macvlan device is created by
keepalived, which I us
keepalived, with VRRP VMAC
> - keepalived regularly sending gratuitous ARP with that VRRP VMAC
> - (new) an additional tap interface in br0, for an openvpn link
>
> In principle, everything is working fine. The base keepalived setup
> has been in operation for a long time, running directly ove
Dear netdev,
I've got a peculiar issue, and hope for clarification / workarounds here.
Scenario:
- a bridge interface br0, over some ethernet base
- a macvlan interface br0-vrrp on top, set up by keepalived, with VRRP VMAC
- keepalived regularly sending gratuitous ARP with that VRRP VMAC
-
From: Johannes Berg
Date: Thu, 4 Feb 2016 13:31:18 +0100
> From: Johannes Berg
>
> In certain 802.11 wireless deployments, there will be ARP proxies
> that use knowledge of the network to correctly answer requests.
> To prevent gratuitous ARP frames on the shared medium from be
From: Johannes Berg
In certain 802.11 wireless deployments, there will be ARP proxies
that use knowledge of the network to correctly answer requests.
To prevent gratuitous ARP frames on the shared medium from being
a problem, on such deployments wireless needs to drop them.
Enable this by
From: Johannes Berg
In certain 802.11 wireless deployments, there will be ARP proxies
that use knowledge of the network to correctly answer requests.
To prevent gratuitous ARP frames on the shared medium from being
a problem, on such deployments wireless needs to drop them.
Enable this by
On Sat, 2015-04-11 at 13:59 +0300, Julian Anastasov wrote:
>
> May be only arptable_filter can help here to
> protect ARP?
>
Finally reviving an ancient thread ...
I checked, butI don't see a way to match tip==sip. You can match on
each, but not against each other.
johannes
--
To unsub
From: Johannes Berg
In certain 802.11 wireless deployments, there will be ARP proxies
that use knowledge of the network to correctly answer requests.
To prevent gratuitous ARP frames on the shared medium from being
a problem, on such deployments wireless needs to drop them.
Enable this by
From: Venkat Venkatsubra
Date: Tue, 11 Aug 2015 07:57:23 -0700
> When the first slave is added (such as during bootup) the first
> gratuitous ARP gets dropped. We don't see this drop during a failover.
> The packet gets dropped in qdisc (noop_enqueue).
>
> The fix is to
When the first slave is added (such as during bootup) the first
gratuitous ARP gets dropped. We don't see this drop during a failover.
The packet gets dropped in qdisc (noop_enqueue).
The fix is to delay the sending of gratuitous ARPs till the bond dev's
carrier is present.
It can also
e changing, the current code "bond_send_gratuitous_arp"
> didn't take effect. It couldn't send gratuitous ARP.
> So I made a patch to fix this issue.
>
> It's my first patch for kernel.
>
> Thanks a lot for your *understanding* for any *inconvenience* caused.
Patches may o
bond_send_gratuitous_arp(bond);
+ if (bond->curr_active_slave &&
+ test_bit(__LINK_STATE_LINKWATCH_PENDING,
+ &bond->curr_active_slave->dev->state)) {
+ dprintk("del
r_active_slave->dev->state)) {
+ dprintk("delaying gratuitous arp on %s\n",
+ bond->curr_active_slave->dev->name);
+ bond->send_grat_arp = 1;
+ } else
+ bond_sen
->state)) {
+ dprintk("delaying gratuitous arp on %s\n",
+ bond->curr_active_slave->dev->name);
+ bond->send_grat_arp = 1;
+ } else
+ bond_send_gratuitous_arp(bond);
->state)) {
+ dprintk("delaying gratuitous arp on %s\n",
+ bond->curr_active_slave->dev->name);
+ bond->send_grat_arp = 1;
+ } else
+ bond_send_gratuitous_arp(bond);
&bond->curr_active_slave->dev->state)) {
+ dprintk("delaying gratuitous arp on %s\n",
+ bond->curr_active_slave->dev->name);
+ bond->send_grat_arp = 1;
+ } else
+
&bond->curr_active_slave->dev->state)) {
+ dprintk("delaying gratuitous arp on %s\n",
+ bond->curr_active_slave->dev->name);
+ bond->send_grat_arp = 1;
+ } else
+ bond_send_grat
umstances were you seeing problems that delaying
> the gratuitous ARP until linkwatch is done improves things? Is this
> really an IB thing, or did you experience problems here over regular
> ethernet?
>
I tried to figure out what is the difference in the state/flags of the device
Moni Shoua <[EMAIL PROTECTED]> wrote:
>Delay sending a gratuitous_arp when LINK_STATE_LINKWATCH_PENDING bit
>in dev->state field is on. This improves the chances for the arp packet to
>be transmitted.
Under what circumstances were you seeing problems that delaying
new_active->dev->dev_addr,
new_active->dev->addr_len);
-
- bond_send_gratuitous_arp(bond);
+ if (bond->curr_active_slave &&
+ test_bit(__LINK_STATE_LINKWATCH_PENDING,
&bond->curr_active_slave->dev->state)){
+
> before i go opening bugs with the distribution folks, could someone chime
> in as to what is the recommended approach these days? did grat arp fall
> out of favour, or is it just a case of userland not keeping up?
The ifup script in iproute2 does it in user land, but nobody uses it
directly
On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
> dean gaudet wrote:
> > On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
> >
> > > dean gaudet wrote:
> > > > hi...
> > > >
> > > > i ran into some problems recently which would have
On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
dean gaudet wrote:
On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
dean gaudet wrote:
hi...
i ran into some problems recently which would have been avoided if my box
did a gratuitous arp as it brought up all interfaces (the router took
dean gaudet wrote:
On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
dean gaudet wrote:
hi...
i ran into some problems recently which would have been avoided if my box
did a gratuitous arp as it brought up all interfaces (the router took
forever to timeout the ARP entries for interface
On Sat, 2006-11-25 at 18:31 -0800, dean gaudet wrote:
> but there's no gratuitous arp for any eth0:N aliased interfaces... and the
> cisco ARP cache on this ISP router seems to be set to a long timeout. i
> could reach eth0:N from local net, but couldn't get outside local
On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
> dean gaudet wrote:
> > hi...
> >
> > i ran into some problems recently which would have been avoided if my box
> > did a gratuitous arp as it brought up all interfaces (the router took
> > forever to time
dean gaudet wrote:
hi...
i ran into some problems recently which would have been avoided if my box
did a gratuitous arp as it brought up all interfaces (the router took
forever to timeout the ARP entries for interface aliases). so i set about
looking to see why that wasn't happening
hi...
i ran into some problems recently which would have been avoided if my box
did a gratuitous arp as it brought up all interfaces (the router took
forever to timeout the ARP entries for interface aliases). so i set about
looking to see why that wasn't happening.
i either missed i
47 matches
Mail list logo
