lson wrote:
>
> *From:* David Ahern
> *Sent:* Thursday, September 6, 2018 5:27 PM
> *To:* D'Souza, Nelson; netdev@vger.kernel.org
> *Subject:* Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge
>
> On 9/5/18 12:00 PM, D'Souza, Nels
On 9/7/18 9:56 AM, D'Souza, Nelson wrote:
>
> *From:* David Ahern
> *Sent:* Thursday, September 6, 2018 5:27 PM
> *To:* D'Souza, Nelson; netdev@vger.kernel.org
> *Subject:* Re: [**EXTERNAL**] Re: VRF w
On 9/5/18 12:00 PM, D'Souza, Nelson wrote:
> Just following up would you be able to confirm that this is a Linux VRF
> issue?
I can confirm that I can reproduce the problem. Need to find time to dig
into it.
Hi David,
Just following up would you be able to confirm that this is a Linux VRF
issue?
Also, how do I log a VRF related defect to ensure this gets resolved in a
subsequent release.
Thanks,
Nelson
On 8/2/18, 4:12 PM, "D'Souza, Nelson" wrote:
Hi David,
Turns out the VRF
Hi David,
Turns out the VRF bridge Rx issue is triggered by a docker install.
Docker makes the following sysctl changes:
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1 <<< exposes the ipv4 VRF Rx issue
when a
David,
With Ubuntu 18.04.1 (kernel 4.15.0-29) pings sent out on test-vrf and br0 are
successful.
# uname -rv
4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018
# ping -c 1 -I test-vrf 172.16.2.2
ping: Warning: source address might be selected on device other than test-vrf.
PING
David,
To narrow down on the issue, I've been requested by our kernel team for the
following information:
"Can you clarify what kernel configuration was used for the clean 4.14.52
kernel (no changes)
The kernel configuration may be available in /proc/config.gz, or it might be
available as a
David,
I tried out the commands on an Ubuntu 17.10.1 VM.
The pings on test-vrf are successful, but the pings on br0 are not successful.
# uname -rv
4.13.0-21-generic #24-Ubuntu SMP Mon Dec 18 17:29:16 UTC 2017
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
It's strange that enslaving eth1 -> br0 -> test-vrf does not work, but
enslaving eth1->test-vrf works fine.
Nelson
On 7/24/18, 8:58 AM, "D'Souza, Nelson" wrote:
Thank you David, really appreciate the help. Most likely something specific
to my environment.
ip vrf id, does not
Thank you David, really appreciate the help. Most likely something specific to
my environment.
ip vrf id, does not report anything on my system. Here's the result after
running the command.
# ip vrf id
#
I'll follow up with a VM.
Nelson
On 7/24/18, 5:55 AM, "David Ahern" wrote:
On
On 7/23/18 7:43 PM, D'Souza, Nelson wrote:
> I copy and pasted the configs onto my device, but pings on test-vrf do not
> work in my setup.
> I'm essentially seeing the same issue as I reported before.
>
> In this case, pings sent out on test-vrf (host ns) are received and replied
> to by the
Hi David,
I copy and pasted the configs onto my device, but pings on test-vrf do not work
in my setup.
I'm essentially seeing the same issue as I reported before.
In this case, pings sent out on test-vrf (host ns) are received and replied to
by the loopback interface (foo ns). Although the
On 7/20/18 1:03 PM, D'Souza, Nelson wrote:
> Setup is as follows:
>
> ethUSB(ingress port) -> mgmtbr0 (bridge) -> mgmtvrf (vrf)
| netns foo
[ test-vrf ]|
| |
[ br0 ] 172.16.1.1 |
| |
[ veth1 ]
The Linux kernel has kernel patches applied beyond 4.14.52 but aside from that
it has no custom changes.
Currently don't have perf on the linux system, so will have to get back to you
with the perf traces.
Meanwhile, here's the ip outputs you requested.
root@x10sdv-4c-tln4f:~# ip rule ls
0:
Hi Dave,
It is good to know that this works in your case. However, I'm not able to
pinpoint what the issue is and looking for a way to narrow down to the root
cause.
Do you know if this has been an issue in the past and resolved in Linux kernel
versions after 4.14.52?
I have the same setup
15 matches
Mail list logo
