Thanks, David. Sorry for missing that in the original patch.
Jeff
On Mon, Nov 5, 2018 at 4:55 PM David Miller wrote:
>
> From: Jeff Barnhill <0xeff...@gmail.com>
> Date: Mon, 5 Nov 2018 20:36:45 +
>
> > Move the anycast.c init and cleanup functions which were inadve
Move the anycast.c init and cleanup functions which were inadvertently
added inside the CONFIG_PROC_FS definition.
Fixes: 2384d02520ff ("net/ipv6: Add anycast addresses to a global hashtable")
Signed-off-by: Jeff Barnhill <0xeff...@gmail.com>
---
net/ipv6/anycast.c | 2 +-
1
: Jeff Barnhill <0xeff...@gmail.com>
---
include/net/addrconf.h | 2 ++
include/net/if_inet6.h | 2 ++
net/ipv6/af_inet6.c| 5
net/ipv6/anycast.c | 80 +++---
4 files changed, 85 insertions(+), 4 deletions(-)
diff --git a/inclu
: Jeff Barnhill <0xeff...@gmail.com>
---
include/net/addrconf.h | 2 ++
include/net/if_inet6.h | 2 ++
net/ipv6/af_inet6.c| 5
net/ipv6/anycast.c | 80 +++---
4 files changed, 85 insertions(+), 4 deletions(-)
diff --git a/inclu
I'll follow this email with a new patch using ifacaddr6 instead of
creating a new struct. I ended up using fib6_nh.nh_dev to get the net,
instead of adding a back pointer to idev. It seems that idev was
recently removed in lieu of this, so if this is incorrect, please let
me know. Hopefully, I got
ler wrote:
>
> From: Jeff Barnhill <0xeff...@gmail.com>
> Date: Sun, 28 Oct 2018 01:51:59 +
>
> > +struct ipv6_ac_addrlist {
> > + struct in6_addr acal_addr;
> > + possible_net_t acal_pnet;
> > + refcount_t ac
: Jeff Barnhill <0xeff...@gmail.com>
---
include/net/addrconf.h | 2 +
include/net/if_inet6.h | 8
net/ipv6/af_inet6.c| 5 ++
net/ipv6/anycast.c | 121 -
4 files changed, 134 insertions(+), 2 deletions(-)
diff --git a/inclu
You are right, David...I mistook the refcount_dec_and_test() in
aca_put() as being for the fib6_info, but it's for the aca_refcnt.
Thanks! I'll submit a corrected patch.
On Sat, Oct 27, 2018 at 7:39 PM David Ahern wrote:
>
> On 10/27/18 12:02 PM, Jeff Barnhill wrote:
> > @@
: Jeff Barnhill <0xeff...@gmail.com>
---
include/net/addrconf.h | 2 +
include/net/if_inet6.h | 8
net/ipv6/af_inet6.c| 5 +++
net/ipv6/anycast.c | 120 -
4 files changed, 133 insertions(+), 2 deletions(-)
diff --git a/inclu
: Jeff Barnhill <0xeff...@gmail.com>
---
include/net/addrconf.h | 2 +
include/net/if_inet6.h | 8
net/ipv6/af_inet6.c| 5 ++
net/ipv6/anycast.c | 122 -
4 files changed, 135 insertions(+), 2 deletions(-)
diff --git a/inclu
at 11:12 PM Eric Dumazet wrote:
>
>
>
> On 10/23/2018 06:58 PM, Jeff Barnhill wrote:
> > icmp6_send() function is expensive on systems with a large number of
> > interfaces. Every time it’s called, it has to verify that the source
> > address does not correspond to an exist
: Jeff Barnhill <0xeff...@gmail.com>
---
include/net/addrconf.h | 2 +
include/net/if_inet6.h | 8 +++
net/ipv6/af_inet6.c| 5 ++
net/ipv6/anycast.c | 132 -
4 files changed, 145 insertions(+), 2 deletions(-)
diff --git a/inclu
Thanks! You are right. I mis-understood net->ifindex. I think I need
to instead hold the net pointer in the new ipv6_ac_addrlist structure.
Do you see a problem with that?
On Mon, Oct 22, 2018 at 10:26 PM Eric Dumazet wrote:
>
>
>
> On 10/22/2018 07:12 PM, Jeff Barnhill wrote:
: Jeff Barnhill <0xeff...@gmail.com>
---
include/net/addrconf.h | 2 +
include/net/if_inet6.h | 8
net/ipv6/af_inet6.c| 5 ++
net/ipv6/anycast.c | 122 -
4 files changed, 135 insertions(+), 2 deletions(-)
diff --git a/inclu
As mentioned here:
https://www.spinics.net/lists/netdev/msg505054.html
icmp6_send() can be expensive when there are a lot of devices and
anycast addresses. One solution I've prototyped is adding a global
hash table to store and allow more efficient searches for anycast
addresses. This works and p
cket, and also the use of "pos" as defined in
seq_file.txt:
The pos passed to start() will always be either zero, or the most
recent pos used in the previous session.
Signed-off-by: Jeff Barnhill <0xeff...@gmail.com>
---
net/ipv6/addrconf.c | 4 +---
1 file changed, 1 inserti
age/code hasn't been an issue.
Thanks,
Jeff
On Fri, Apr 13, 2018 at 4:31 PM, David Ahern wrote:
> On 4/13/18 2:23 PM, Jeff Barnhill wrote:
>> It seems that the ENETUNREACH response is still desirable in the VRF
>> case since the only difference (when using VRF vs. not) is that
ot using VRFs at all.
It seems that the ENETUNREACH response is still desirable in the VRF
case since the only difference (when using VRF vs. not) is that the
lookup should be restrained to a specific VRF.
Jeff
On Thu, Apr 12, 2018 at 10:25 PM, David Ahern wrote:
> On 4/12/18 10:54 AM, Jef
hat programmatically, it may not make much
difference, ie. lookup fails, but for debugging or to a user looking
at it, the difference matters. Do you (or anyone else) have any
thoughts on this?
Thanks,
Jeff
On Sun, Oct 29, 2017 at 11:48 AM, David Ahern wrote:
> On 10/27/17 8:43 PM, Jeff Bar
being processed. This change increments the counters
in ip6_forward_finish() so that it will not happen if the netfilter hook
chooses to terminate the packet, which is similar to how IPv4 works.
Signed-off-by: Jeff Barnhill <0xeff...@gmail.com>
---
net/ipv6/ip6_output.c | 7 +--
1 file c
At the end of ip6_forward(), is there a good reason why
IPSTATS_MIB_OUTFORWDATAGRAMS and IPSTATS_MIB_OUTOCTETS are incremented
before the NF_HOOK? If the hook steals or drops the packet, this
counts still go up, which seems incorrect.
v4/ip_forward() increments these counters in ip_forward_finish
FRA_L3MDEV is defined as U8, but is being added as a U32 attribute. On
big endian architecture, this results in the l3mdev entry not being
added to the FIB rules.
Fixes: 1aa6c4f6b8cd8 ("net: vrf: Add l3mdev rules on first device create")
Signed-off-by: Jeff Barnhill <0xeff
FRA_L3MDEV is defined as U8, but is being added as a U32 attribute. On
big endian architecture, this results in the l3mdev entry not being
added to the FIB rules.
Fixes: 1aa6c4f6b8cd8 ("net: vrf: Add l3mdev rules on first device create")
---
drivers/net/vrf.c | 2 +-
1 file changed, 1 insertion(+
32(skb, FRA_PRIORITY, FIB_RULE_PREF))
I was surprised that nlmsg_parse in fib_nl_newrule() didn't pick this
up, but I verified that the received value for this attribute was 0,
not 1 (w/o the patch).
Jeff
On Sun, Oct 29, 2017 at 11:48 AM, David Ahern wrote:
> On 10/27/17 8:43 PM, Jeff Barnhill wro
statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.029/0.029/0.029/0.000 ms
On Fri, Oct 27, 2017 at 6:53 PM, David Ahern wrote:
> On 10/27/17 2:59 PM, Jeff Barnhill wrote:
>> w/regards to this comment:
>>You have a remote
/ether 82:2b:08:8f:a9:f3 brd ff:ff:ff:ff:ff:ff
inet 127.0.0.1/8 scope host myvrf
valid_lft forever preferred_lft forever
On Fri, Oct 27, 2017 at 12:25 PM, David Ahern wrote:
> On 10/26/17 11:19 PM, Jeff Barnhill wrote:
>> Thanks, David.
>>
>> I corrected the stat
.0.1 myvrf: 56(84) bytes of data.
^C
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2033ms
jeff@VM2:~$ ping -I myvrf ::1
connect: Network is unreachable
Thanks,
Jeff
On Thu, Oct 26, 2017 at 1:24 PM, David Ahern wrote:
> On 10/25/17 9:28 PM, Jeff B
,
Jeff
On Wed, Oct 25, 2017 at 5:31 PM, David Ahern wrote:
> On 10/25/17 2:45 PM, Jeff Barnhill wrote:
>> Are v6/sit tunnels working with VRFs?
>>
>> For instance, I have a very simple configuration with three VMs
>> running 4.13.0-16 (Ubuntu Server 17.10) kernels. VM3 is
Are v6/sit tunnels working with VRFs?
For instance, I have a very simple configuration with three VMs
running 4.13.0-16 (Ubuntu Server 17.10) kernels. VM3 is setup as a
router for separation. VM1 and VM2 have static routes to each other
via VM3. All VMs have v4 interfaces configured. If I setu
29 matches
Mail list logo
