From: Patrick Schaaf <netdev@bof.de>
To: Patrick McHardy <kaber@trash.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Richard Weinberger <richard@nod.at>,
davem@davemloft.net, coreteam@netfilter.org,
netfilter-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, bhutchings@solarflare.com,
john.fastabend@gmail.com, herbert@gondor.apana.org.au,
vyasevic@redhat.com, jiri@resnulli.us, vfalico@gmail.com,
therbert@google.com, edumazet@google.com,
yoshfuji@linux-ipv6.org, jmorris@namei.org, kuznet@ms2.inr.ac.ru,
kadlec@blackhole.kfki.hu, pablo@netfilter.org, kay@vrfy.org,
stephen@networkplumber.org
Subject: Re: [PATCH 2/3] x_tables: Use also dev->ifalias for interface matching
Date: Mon, 12 Jan 2015 18:41:42 +0100 [thread overview]
Message-ID: <2245326.CTMNrtX3Ao@rofl> (raw)
In-Reply-To: <20150112172257.GG17329@acer.localdomain>
On Monday 12 January 2015 17:22:57 Patrick McHardy wrote:
> On 12.01, Patrick Schaaf wrote:
> >
> > Interfaces come and go through many different actions. There's the admin
> > downing and upping stuff like bridges or bonds. There's stuff like libvirt
> > / KVM / qemu creating and destroying interfaces. In all these cases, in
> > my practise, I give the interfaces useful names to that I can
> > prefix-match them in iptables rules.
> >
> > Dynamically modifying the ruleset for each such creation and destruction,
> > would be a huge burden. The base ruleset would need suitable "hooks" where
> > these rules were inserted (ordering matters!). The addition would hardly
> > be
> > atomic (with traditional iptables, unless done by generating a whole new
> > ruleset and restoring). The programs (e.g. libvirt) would need to be able
> > to call out to these specially crafted rule generator scripts. The admin
> > would need to add them as pre/post actions to their static (manual)
> > interface configuration. Loading and looking at the ruleset before
> > bringing up the interface would be impossible.
>
> devgroups seem like the best solution for this.
Could be, technically.
Is there devgroup support in libvirt, ifcfg, whatever other distros use for
their static interface configuration? Or, do I again have to write pre/post
scripts to set devgroups? Wouldn't bother me too much nowadays, I've automated
that for ifcfg style stuff in my production environment a year ago, but it's
something an admin must actively manage...
There is other stuff, apart from libvirt, that creates and destroys interfaces
on the fly. From my production environment, there's at least keepalived, which
creates macvlan interfaces on the fly for VRRP VMAC support. I can configure
the name for that, but nothing else, nor can I call a script pre/post for
that. And my iptables rules on that boxen _do_ match specially on these
interfaces.
Gooling a bit around does not immediately turn up any good documentation on it
at all (four year old iproute2 commits, once I give that as a search term
too?). Looks very sketchy (although the fundamental idea is clear to me. I'm
looking through the normal admin practise lens....)
best regards
Patrick
next prev parent reply other threads:[~2015-01-12 17:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-11 20:52 [RFC] Make predictable/persistent network interface names more handy Richard Weinberger
2015-01-11 20:52 ` [PATCH 1/3] net: Make interface aliases available for general usage Richard Weinberger
2015-01-11 22:40 ` Stephen Hemminger
2015-01-11 22:43 ` Richard Weinberger
2015-01-11 20:52 ` [PATCH 2/3] x_tables: Use also dev->ifalias for interface matching Richard Weinberger
2015-01-12 16:04 ` Eric Dumazet
2015-01-12 16:12 ` Richard Weinberger
2015-01-12 16:32 ` Jan Engelhardt
2015-01-12 16:46 ` Eric Dumazet
[not found] ` <1425960.ovH4s7sjue@rofl>
2015-01-12 16:51 ` Eric Dumazet
2015-01-12 17:19 ` Patrick Schaaf
2015-01-12 17:22 ` Patrick McHardy
2015-01-12 17:41 ` Patrick Schaaf [this message]
2015-01-11 20:52 ` [PATCH 3/3] x_tables: Factor out 16bit aligment ifname_compare() Richard Weinberger
2015-01-11 20:59 ` Joe Perches
2015-01-11 21:02 ` Richard Weinberger
2015-01-11 21:14 ` Joe Perches
2015-01-11 21:30 ` Richard Weinberger
2015-01-11 21:39 ` Joe Perches
2015-01-11 21:42 ` Richard Weinberger
2015-01-12 2:50 ` David Miller
2015-01-12 8:18 ` Richard Weinberger
2015-01-12 8:40 ` Joe Perches
2015-01-11 22:23 ` Jan Engelhardt
2015-01-11 22:42 ` [RFC] Make predictable/persistent network interface names more handy Stephen Hemminger
2015-01-11 22:47 ` Richard Weinberger
2015-01-11 22:51 ` Richard Weinberger
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=2245326.CTMNrtX3Ao@rofl \
--to=netdev@bof.de \
--cc=bhutchings@solarflare.com \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=jiri@resnulli.us \
--cc=jmorris@namei.org \
--cc=john.fastabend@gmail.com \
--cc=kaber@trash.net \
--cc=kadlec@blackhole.kfki.hu \
--cc=kay@vrfy.org \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=richard@nod.at \
--cc=stephen@networkplumber.org \
--cc=therbert@google.com \
--cc=vfalico@gmail.com \
--cc=vyasevic@redhat.com \
--cc=yoshfuji@linux-ipv6.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 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).