[ FYI: you should not 'top post' in responses to netdev; rather comment
inline with the previous message ]
On 9/12/19 7:50 AM, Gowen wrote:
>
> Hi David -thanks for getting back to me
>
>
>
> The DNS servers are 10.24.65.203 or 10.24.64.203 which you want to go
>
> out mgmt-vrf. correct? No -
@vyatta.att-mail.com
Cc: netdev@vger.kernel.org
Subject: Re: VRF Issue Since kernel 5
On 9/11/19 3:01 PM, Gowen wrote:
> Hi all,
>
> It looks like ip vrf exec checks /etc/resolv.conf (found with strace -e
> trace=file sudo ip vrf exec mgmt-vrf host www.google.co.uk &>
>
eck the systemd-resolve servers as well?
Gareth
From: David Ahern
Sent: 11 September 2019 18:02
To: Gowen ; netdev@vger.kernel.org
Subject: Re: VRF Issue Since kernel 5
At LPC this week and just now getting a chance to process the data you sent.
On 9/9/19 8:46 AM, Gowen wrote:
&
At LPC this week and just now getting a chance to process the data you sent.
On 9/9/19 8:46 AM, Gowen wrote:
> the production traffic is all in the 10.0.0.0/8 network (eth1 global VRF)
> except for a few subnets (DNS) which are routed out eth0 (mgmt-vrf)
>
>
> Admin@NETM06:~$ ip route show
> de
On 9/9/19 10:28 AM, Alexis Bauvin wrote:
> Also, your `unreachable default metric 4278198272` route looks odd to me.
>
New recommendation from FRR group. See
https://www.kernel.org/doc/Documentation/networking/vrf.txt and search
for 4278198272
gt;
> *From:* Gowen
> *Sent:* 11 September 2019 13:48
> *To:* David Ahern ; Alexis Bauvin
> ; mmann...@vyatta.att-mail.com
>
> *Cc:* netdev@vger.kernel.org
> *Subject:* Re: VRF Issue Since kernel 5
&g
Hi Gareth,
Could you please also check that all the following are set to 1, I
appreciate you've confirmed that the one for tcp is set to 1, and by
default the one for raw is also set to 1:
sudo sysctl -a | grep l3mdev
If not,
sudo sysctl net.ipv4.raw_l3mdev_accept=1
sudo sysctl net.ipv4.udp_l3mde
previously mentioned attchements
From: Gowen
Sent: 11 September 2019 12:19
To: David Ahern ; Alexis Bauvin
Cc: netdev@vger.kernel.org
Subject: Re: VRF Issue Since kernel 5
Hi there,
Your perf command:
isc-worker 20261 [000] 2215.013849: fib:fib_table_lookup: table 10
Gowen
Sent: 11 September 2019 06:09
To: David Ahern ; Alexis Bauvin
Cc: netdev@vger.kernel.org
Subject: RE: VRF Issue Since kernel 5
Thanks for the link - that's really useful. I did re-order ip rules Friday (I
think) - no change
-Original Message-
From: David Aher
Thanks for the link - that's really useful. I did re-order ip rules Friday (I
think) - no change
-Original Message-
From: David Ahern
Sent: 10 September 2019 17:36
To: Alexis Bauvin ; Gowen
Cc: netdev@vger.kernel.org
Subject: Re: VRF Issue Since kernel 5
On 9/9/19 1:01 PM, A
On 9/9/19 8:46 AM, Gowen wrote:
>
> I can run:
>
>
> Admin@NETM06:~$ host www.google.co.uk
> www.google.co.uk has address 172.217.169.3
> www.google.co.uk has IPv6 address 2a00:1450:4009:80d::2003
>
>
> but I get a timeout for:
>
>
> sudo ip vrf exec mgmt-vrf host www.google.co.uk
sudo per
On 9/9/19 1:01 PM, Alexis Bauvin wrote:
> Could you try swapping the local and l3mdev rules?
>
> `ip rule del pref 0; ip rule add from all lookup local pref 1001`
yes, the rules should be re-ordered so that local rule is after l3mdev
rule (VRF is implemented as policy routing). In general, I woul
0.0/8
0.0.0.0/0LOG flags 0 level 4 prefix "LOG-SECURITY"
From: Gowen
Sent: 09 September 2019 20:43
To: Alexis Bauvin
Cc: netdev@vger.kernel.org
Subject: RE: VRF Issue Since kernel 5
Hi alexis,
I did this earlier today and no change.
I’ll look at trying to se
?
Gareth
-Original Message-
From: Alexis Bauvin
Sent: 09 September 2019 13:02
To: Gowen
Cc: netdev@vger.kernel.org
Subject: Re: VRF Issue Since kernel 5
Hi,
I guess all routing from the management VRF itself is working correctly (i.e.
cURLing an IP from this VRF or digging any DNS), and it
if I set the
> policy to ACCEPT and flush all the rules, the behaviour remains the same.
>
> Is it possible that the TCP stack isn't aware of the session (as is mapped to
> wrong VRF internally or something to that effect) and is therefore sending
> the RST?
>
> Gareth
&
Hi,
There has been some changes regarding VRF isolation in Linux 5 IIRC, namely
proper
isolation of the default VRF.
Some things you may try:
- looking at the l3mdev_accept sysctls (e.g. `net.ipv4.tcp_l3mdev_accept`)
- querying stuff from the management vrf through `ip vrf exec vrf-mgmt `
e.g
16 matches
Mail list logo
