netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: David Ahern <dsahern@gmail.com>,
	Shrijeet Mukherjee <shm@cumulusnetworks.com>,
	Nicolas Dichtel <nicolas.dichtel@6wind.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Jamal Hadi Salim <hadi@mojatatu.com>,
	davem@davemloft.net,
	Stephen Hemminger <stephen@networkplumber.org>,
	netdev@vger.kernel.org
Cc: roopa@cumulusnetworks.com,
	andy gospodarek <gospo@cumulusnetworks.com>,
	jtoppins@cumulusnetworks.com, nikolay@cumulusnetworks.com
Subject: Re: [RFC net-next 0/3] Proposal for VRF-lite
Date: Mon, 08 Jun 2015 22:41:15 +0200	[thread overview]
Message-ID: <1433796075.1992197.290139129.5F4BF968@webmail.messagingengine.com> (raw)
In-Reply-To: <5575E964.7060308@gmail.com>

On Mon, Jun 8, 2015, at 21:13, David Ahern wrote:
> On 6/8/15 12:35 PM, Shrijeet Mukherjee wrote:
> > 5. Debugging is built-in as tcpdump and counters on the VRF device
> >     works as is.
> 
> Is the intent that something like this
> 
>    tcpdump -i vrf0
> 
> can be used to see vrf traffic?
> 
> vrf_handle_frame only bumps counters; it does not switch skb->dev to the 
> vrf device so for Rx path tcpdump will not get the packets. ie., tcpdump 
> only shows outbound packets.

My hope initially was that the vrf interface type would be as slim as
possible. I
am not even sure if we need packet counters, as one could easily have
user
space handle that by looking up the relations and accumulating them.
Same
for VRF traffic.

But the current model does allow to add support for that easily, so why
not? It
depends on how far we can and want to move parts of the logic into the
core
stack in the end.

Would you see this as a requirement?

Thanks,
Hannes

  parent reply	other threads:[~2015-06-08 20:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08 18:35 [RFC net-next 0/3] Proposal for VRF-lite Shrijeet Mukherjee
2015-06-08 18:35 ` [RFC net-next 1/3] Symbol preparation for VRF driver Shrijeet Mukherjee
2015-06-10 16:24   ` Alexander Duyck
2015-06-08 18:35 ` [RFC net-next 2/3] VRF driver and needed infrastructure Shrijeet Mukherjee
2015-06-08 19:08   ` David Ahern
2015-06-08 20:17   ` Hannes Frederic Sowa
2015-06-09  9:19   ` Nicolas Dichtel
2015-06-09 12:35   ` Nikolay Aleksandrov
2015-06-10  2:11     ` Shrijeet Mukherjee
2015-06-10 18:20   ` Alexander Duyck
2015-06-08 18:35 ` [RFC net-next 3/3] rcv path changes for vrf traffic Shrijeet Mukherjee
2015-06-08 19:58   ` Hannes Frederic Sowa
2015-06-08 20:00     ` Hannes Frederic Sowa
2015-06-08 20:22     ` Shrijeet Mukherjee
2015-06-08 20:33       ` Hannes Frederic Sowa
2015-06-08 22:44         ` Shrijeet Mukherjee
2015-06-09  5:41           ` Hannes Frederic Sowa
2015-06-08 22:05     ` David Miller
2015-06-08 22:13       ` Hannes Frederic Sowa
2015-06-08 22:21         ` David Miller
2015-06-09  0:36     ` David Ahern
2015-06-09  1:03     ` David Ahern
2015-06-09  5:35       ` Hannes Frederic Sowa
2015-06-10 18:31   ` Alexander Duyck
2015-06-08 18:35 ` [RFC iproute2] Add the ability to create a VRF device and specify it's table binding Shrijeet Mukherjee
2015-06-08 19:13 ` [RFC net-next 0/3] Proposal for VRF-lite David Ahern
2015-06-08 19:51   ` Shrijeet Mukherjee
2015-06-08 20:41   ` Hannes Frederic Sowa [this message]
2015-06-09  8:58 ` Nicolas Dichtel
2015-06-09 14:21   ` David Ahern
2015-06-09 14:55     ` Nicolas Dichtel
2015-06-09 17:14       ` Shrijeet Mukherjee
2015-06-09 10:15 ` Thomas Graf
2015-06-09 12:30   ` Nicolas Dichtel
2015-06-09 12:43     ` Hannes Frederic Sowa
     [not found]   ` <CAJmoNQHRTJwdMjziQiPBX07sZKrYd3Z1ASNi1xQZdgJ1Vs6bGg@mail.gmail.com>
2015-06-12  9:46     ` Thomas Graf

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=1433796075.1992197.290139129.5F4BF968@webmail.messagingengine.com \
    --to=hannes@stressinduktion.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=gospo@cumulusnetworks.com \
    --cc=hadi@mojatatu.com \
    --cc=jtoppins@cumulusnetworks.com \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    --cc=nikolay@cumulusnetworks.com \
    --cc=roopa@cumulusnetworks.com \
    --cc=shm@cumulusnetworks.com \
    --cc=stephen@networkplumber.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).