currently: vmAdmin@NETM06:~$ uname -r 5.0.0-1018-azure
vmAdmin@NETM06:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS" I don't keep a history of kernel versions on test but I noticed it had gone to kernel 5 and stopped working - I'm about 80% sure that happened at the same time - I'll try and dig out some logs today to see what I can find for you as Linux is fairly new to me Gareth From: David Ahern <dsah...@gmail.com> Sent: 11 September 2019 17:09 To: Gowen <go...@potatocomputing.co.uk>; Alexis Bauvin <abau...@online.net>; mmann...@vyatta.att-mail.com <mmann...@vyatta.att-mail.com> Cc: netdev@vger.kernel.org <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 &> > ~/straceFileOfVrfHost.txt) , but as I'm on an Azure machine using > netplan, this file isn't updated with DNS servers. I have added my DNS > server to resolv.conf and now can update the cache with "sudo ip vrf > exec sudo apt update", if I am correct (which I'm not sure about as not > really my area) then this might be affecting more than just me. > > Also still not able to fix the updating cache from global VRF - which > would cause bother in prod environment to others as well so think it > would be good to get an RCA for it? > > thanks for your help so far, has been really interesting. > > Gareth > > > ------------------------------------------------------------------------ > *From:* Gowen <go...@potatocomputing.co.uk> > *Sent:* 11 September 2019 13:48 > *To:* David Ahern <dsah...@gmail.com>; Alexis Bauvin > <abau...@online.net>; mmann...@vyatta.att-mail.com > <mmann...@vyatta.att-mail.com> > *Cc:* netdev@vger.kernel.org <netdev@vger.kernel.org> > *Subject:* Re: VRF Issue Since kernel 5 > > yep no problem: > > Admin@NETM06:~$ sudo sysctl -a | grep l3mdev > net.ipv4.raw_l3mdev_accept = 1 > net.ipv4.tcp_l3mdev_accept = 1 > net.ipv4.udp_l3mdev_accept = 1 > > > The source of the DNS issue in the vrf exec command is something to do > with networkd managing the DNS servers, I can fix it by explicitly > mentioning the DNS server: > > systemd-resolve --status --no-page > > <OUTPUT OMITTED> > > Link 4 (mgmt-vrf) > Current Scopes: none > LLMNR setting: yes > MulticastDNS setting: no > DNSSEC setting: no > DNSSEC supported: no > > Link 3 (eth1) > Current Scopes: DNS > LLMNR setting: yes > MulticastDNS setting: no > DNSSEC setting: no > DNSSEC supported: no > DNS Servers: 10.24.65.203 > 10.24.65.204 > 10.25.65.203 > 10.25.65.204 > DNS Domain: reddog.microsoft.com > > Link 2 (eth0) > Current Scopes: DNS > LLMNR setting: yes > MulticastDNS setting: no > DNSSEC setting: no > DNSSEC supported: no > DNS Servers: 10.24.65.203 > 10.24.65.204 > 10.25.65.203 > 10.25.65.204 > DNS Domain: reddog.microsoft.com > > there is no DNS server when I use ip vrf exec command (tcpdump shows > only loopback traffic when invoked without my DNS sever explicitly > entered) - odd as mgmt-vrf isnt L3 device so thought it would pick up > eth0 DNS servers? > > I dont think this helps with my update cache traffic from global vrf > though on port 80 > Let's back up a bit: your subject line says vrf issue since kernel 5. Did you update / change the OS as well? ie., the previous version that worked what is the OS and kernel version? What is the OS and kernel version with the problem?
