From: David Ahern <dsahern@gmail.com>
To: Gowen <gowen@potatocomputing.co.uk>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: VRF Issue Since kernel 5
Date: Fri, 13 Sep 2019 11:41:09 -0600 [thread overview]
Message-ID: <73b535a0-1f0c-14a9-95ab-faef66ae758b@gmail.com> (raw)
In-Reply-To: <CWLP265MB15547011D9510DEA6475B469FDB00@CWLP265MB1554.GBRP265.PROD.OUTLOOK.COM>
[ 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 - 10.24.65.203 10.25.65.203, so should hit the route leak rule as below (if I've put the 10.24.64.0/24 subnet anywhere it is a typo)
>
> vmAdmin@NETM06:~$ ip ro get 10.24.65.203 fibmatch
> 10.24.65.0/24 via 10.24.12.1 dev eth0
>
>
> I've added the 127/8 route - no difference.
you mean address on mgmt-vrf right?
>
> The reason for what you might think is an odd design is that I wanted any non-VRF aware users to be able to come in and run all commands in default context without issue, while production and mgmt traffic was separated still
>
> DNS is now working as long as /etc/resolv.conf is populated with my DNS servers - a lot of people would be using this on Azure which uses netplan, so they'll have the same issue, is there documentation I could update or raise a bug to check the systemd-resolve servers as well?
That is going to be the fundamental system problem: handing DNS queries
off to systemd is losing the VRF context of the process doing the DNS
query.
prev parent reply other threads:[~2019-09-13 17:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-09 7:46 VRF Issue Since kernel 5 Gowen
2019-09-09 9:28 ` Alexis Bauvin
[not found] ` <CWLP265MB1554B902B7F3B43E6E75FD0DFDB70@CWLP265MB1554.GBRP265.PROD.OUTLOOK.COM>
2019-09-09 12:01 ` Alexis Bauvin
2019-09-09 19:43 ` Gowen
2019-09-10 14:22 ` Gowen
2019-09-10 16:36 ` David Ahern
2019-09-11 5:09 ` Gowen
2019-09-11 11:19 ` Gowen
2019-09-11 11:49 ` Gowen
2019-09-11 12:15 ` Mike Manning
[not found] ` <CWLP265MB155485682829AD9B66AB66FCFDB10@CWLP265MB1554.GBRP265.PROD.OUTLOOK.COM>
[not found] ` <CWLP265MB155424EF95E39E98C4502F86FDB10@CWLP265MB1554.GBRP265.PROD.OUTLOOK.COM>
2019-09-11 16:09 ` David Ahern
2019-09-12 6:54 ` Gowen
2020-03-10 20:47 ` Maximilian Bosch
2020-03-12 1:06 ` David Ahern
2020-04-01 18:16 ` Maximilian Bosch
2020-04-01 19:18 ` David Ahern
2020-04-01 20:35 ` Maximilian Bosch
2020-04-01 20:41 ` David Ahern
2020-04-02 23:02 ` Maximilian Bosch
2020-04-05 16:52 ` David Ahern
2020-04-08 10:07 ` Mike Manning
2020-04-08 15:36 ` David Ahern
2020-04-19 20:35 ` Maximilian Bosch
2019-09-11 16:53 ` David Ahern
2019-09-10 16:39 ` David Ahern
2019-09-11 17:02 ` David Ahern
2019-09-12 6:50 ` Gowen
2019-09-13 17:41 ` David Ahern [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=73b535a0-1f0c-14a9-95ab-faef66ae758b@gmail.com \
--to=dsahern@gmail.com \
--cc=gowen@potatocomputing.co.uk \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.