From: Ben Greear <greearb@candelatech.com>
To: sowmini varadhan <sowmini05@gmail.com>
Cc: Lorenzo Colitti <lorenzo@google.com>,
netdev <netdev@vger.kernel.org>, JP Abgrall <jpa@google.com>,
David Miller <davem@davemloft.net>, Julian Anastasov <ja@ssi.bg>,
Hannes Frederic Sowa <hannes@stressinduktion.org>
Subject: Re: [PATCH 0/3] Make mark-based routing work better with multiple separate networks.
Date: Tue, 13 May 2014 09:09:12 -0700 [thread overview]
Message-ID: <537243A8.2060007@candelatech.com> (raw)
In-Reply-To: <CACP96tSF=3ogg+Gv6GiOuUxF=kL_6FE0f_P1Efcg7-RKWs++yA@mail.gmail.com>
On 05/13/2014 08:38 AM, sowmini varadhan wrote:
> On Tue, May 13, 2014 at 11:28 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>
>> You can't use macvlan if you're not using interfaces that don't have
>> MAC addresses such as tun devices, 4G interfaces, and so on.
>
> So to repeat, "what problem do you need to solve?" You indicated
> that
> " As described in the patch cover letter, one of the things I'm trying
> to do is have fwmarks select between multiple separate networks, which
> may be on multiple physical interfaces. I also want applications to be
> able to listen for connections from all networks using a single
> listening socket. I don't care about network isolation."
For what it's worth, we have had good luck doing something similar to the
marking rules with a private patch some years ago. Then, we backed that out
and ran similar rules based on source/dest ports and IP addrs. You can do these
routing tricks using standard kernels, but it is not very efficient because you
end up with hundreds or thousands of ip rules.
We found this approach much easier to deal with than using namespaces, though
when we started namespaces did not even exist so maybe we are biased.
If I ever have time to hack on this again, I'd like to optimize the ip rules
so that they can be bound to a specific interface so that the cost of having
lots of rules is not so high...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2014-05-13 16:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 17:36 [PATCH 0/3] Make mark-based routing work better with multiple separate networks Lorenzo Colitti
2014-05-09 17:36 ` [PATCH 1/3] net: add a sysctl to reflect the fwmark on replies Lorenzo Colitti
2014-05-09 17:37 ` [PATCH 2/3] net: Use fwmark reflection in PMTU discovery Lorenzo Colitti
2014-05-09 17:37 ` [PATCH 3/3] net: support marking accepting TCP sockets Lorenzo Colitti
2014-05-09 18:05 ` Eric Dumazet
2014-05-12 12:21 ` [PATCH 0/3] Make mark-based routing work better with multiple separate networks sowmini varadhan
2014-05-12 19:58 ` Lorenzo Colitti
2014-05-12 21:09 ` sowmini varadhan
2014-05-12 22:53 ` Lorenzo Colitti
2014-05-13 10:49 ` sowmini varadhan
2014-05-13 15:28 ` Lorenzo Colitti
2014-05-13 15:38 ` sowmini varadhan
2014-05-13 16:09 ` Ben Greear [this message]
2014-05-13 17:12 ` David Ahern
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=537243A8.2060007@candelatech.com \
--to=greearb@candelatech.com \
--cc=davem@davemloft.net \
--cc=hannes@stressinduktion.org \
--cc=ja@ssi.bg \
--cc=jpa@google.com \
--cc=lorenzo@google.com \
--cc=netdev@vger.kernel.org \
--cc=sowmini05@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).