Hi, Jerome (and everyone),
Thanks for this!
Using packet-capture + span, did indeed accomplish what I was looking for.
One useful data point: I was able to capture about 10 seconds of line-rate
10G into a pcap file, and it looks like I didn't lose any packets, on a VPP
host that was not forwarding packets.
Thanks again,
Brian
On Fri, Nov 23, 2018 at 9:06 AM Jerome Tollet (jtollet) <jtol...@cisco.com>
wrote:
> Hi Brian,
>
> I tried what I told you and I confirm that worked fine on my setup.
>
>
>
> *create packet-generator interface pg0*
>
> *packet-generator capture pg0 pcap /tmp/mycap.pcap*
>
> *set interface span SOURCE_INTF destination pg0*
>
> *set interface state pg0 up*
>
>
>
> Jerome
>
> *De : *<vpp-dev@lists.fd.io> au nom de Brian Dickson <
> brian.peter.dick...@gmail.com>
> *Date : *vendredi 23 novembre 2018 à 08:03
> *À : *"d...@barachs.net" <d...@barachs.net>
> *Cc : *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
> *Objet : *Re: [vpp-dev] Request: please add "real" pcap ability #vpp
>
>
>
>
>
> On Thu, Nov 22, 2018 at 5:30 AM <d...@barachs.net> wrote:
>
> Laying aside comments about folks who aren’t regular community
> contributors introducing themselves in random ways, here are a few thoughts:
>
>
>
> We have a plan to unify pcap tracepoints when Damjan finishes reworking
> the ethernet input node.
>
>
>
> That is very welcome news.
>
>
>
> Is there a rough timeline for Damjan's reworking, and the unification? I
> just want to factor that into my own plans, if possible.
>
>
>
>
>
> No matter what, pcap capture involves a bunch of data copying. The
> forwarding rate will clearly suffer. Full stop.
>
>
>
> Yes, I fully understand that. There's no such thing as a free lunch.
>
>
>
> In the environment in question, there's VPP hosts (doing BGP with the
> netlink and router sandbox plugins to get the routing table into VPP), and
> adjacent to them (physically upstream/downstream) we are using passive
> optical splitters.
>
>
>
> Those optical splitters feed copies of traffic to capture hosts,
> specifically dedicated to packet capture and/or other integrated analysis
> code to be developed.
>
>
>
> Our packet capture would only be using VPP without any packet forwarding,
> i.e. as a convenient way of integrating kernel offload with packet capture,
> and possibly chained with other added custom nodes.
>
>
>
> (DPDK by itself is not really friendly for doing any kind of from-scratch
> integration, and I haven't found many/any other currently maintained open
> source packages/frameworks that offer pcap. E.g. netmap-libpcap seems
> abandoned.)
>
>
>
> Having the ability to add other nodes in the graph, that do other stuff,
> possibly with zero copy, is another major reason we're looking at VPP.
>
>
>
> So, pcap is the starting point, and future work might keep the pcap
> capability (assuming the ability to control whether capture is done, and
> the ability to specify pcap filter rules), and add other custom
> functionality.
>
>
>
> To give you an idea, this is not consumer-grade stuff we are using; 12 or
> 24 core Intel boxes (with HT, appears as 24 or 48 cores), and 128GB or
> 256GB of memory, just for packet capture, onto RAIDed SSDs.
>
>
>
> Thanks for the info, and I'll definitely look at that extras/wireshark
> thing.
>
>
>
> Brian
>
>
>
>
>
> In master/latest, I’ve added pcap tracing – and a wireshark dissector – to
> the graph dispatch engine. See .../extras/wireshark/readme.md for more
> detail. The wireshark dissector isn’t finished by any means, nor do we have
> a blessed encap type number from tcpdump-workers, nor is the work
> upstreamed into wireshark.
>
>
>
> [image: cid:image001.png@01D4823D.97D176D0]
>
>
>
>
>
>
>
> *From:* vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *
> brian.peter.dick...@gmail.com
> *Sent:* Wednesday, November 21, 2018 6:59 PM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] Request: please add "real" pcap ability #vpp
>
>
>
> Hi, dev folks,
>
> Apologies for my first message being kind of demanding.
>
> However, I think this is a reasonable request.
>
> What I am interested in, and I think this is likely to be a fairly
> universal desire, is the ability to properly integrate some kind of pcap
> packet capture to the full VPP graph.
>
> The current available mechanisms (pcap drop trace and pcap tx trace) do
> not apply to packets that are only "handled" by the host in question, i.e.
> neither originate or terminate on the local host.
>
> In particular, I'm interested in something that can run on a bare metal
> host and, presuming sufficient resources can be given to it (cores, memory,
> etc), do packet capture at line rate.
>
> Thus, any restriction ("run it on a VM") is not adequate.
>
> Given that there is already stuff for handling the pcap file already (in
> vnet/unix IIRC), this should not be a lot of work.
>
> There are two use cases I have:
>
> · debugging data plane stuff on a vpp-based router (i.e. using the vppsb
> netlink and router projects)
>
> · packet capture at line rate (a vpp host that only listens/drops
> traffic, incidental to the packet capture, i.e. a single-purpose host,
> bypassing kernel/driver limitations, to take all ethernet traffic on a port
> and stuff it into a pcap file.)
>
> oNB: for scaling purposes, it is reasonable to implement the pcap
> captures using RSS/RFS to multiple cores and having each core be a thread
> doing pcap file writing; how that would be put into the "vpp graph" might
> be a little less than trivial, but should be straightforward, IMHO)
>
> Thanks in advance.
>
> Brian Dickson
>
> P.S. There is a SERIOUS lack of useful documentation on how to actually do
> this, as a potential ad-hoc contributor. Not sure if you guys have gotten
> this feedback from anyone else.
> P.P.S. I'm using 18.07 because that is the last version that builds
> alongside the vppsb netlink and router plugins.
> P.P.P.S. Even getting 18.07 and vppsb to build was a nightmare. You should
> try doing this from scratch, i.e. put yourselves in the shoes of someone
> who just discovered vpp...
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11397): https://lists.fd.io/g/vpp-dev/message/11397
Mute This Topic: https://lists.fd.io/mt/28282785/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
