Thanks for the update. Feel free to contribute to the documentation or wiki on that point 😉 Jerome
De : <vpp-dev@lists.fd.io> au nom de Brian Dickson <brian.peter.dick...@gmail.com> Date : dimanche 25 novembre 2018 à 19:36 À : Jerome Tollet <jtol...@cisco.com> Cc : "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Objet : Re: [vpp-dev] Request: please add "real" pcap ability #vpp 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<mailto: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<mailto:vpp-dev@lists.fd.io>> au nom de Brian Dickson <brian.peter.dick...@gmail.com<mailto:brian.peter.dick...@gmail.com>> Date : vendredi 23 novembre 2018 à 08:03 À : "d...@barachs.net<mailto:d...@barachs.net>" <d...@barachs.net<mailto:d...@barachs.net>> Cc : "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io<mailto: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<mailto: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. Erreur ! Nom du fichier non spécifié. From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of brian.peter.dick...@gmail.com<mailto:brian.peter.dick...@gmail.com> Sent: Wednesday, November 21, 2018 6:59 PM To: vpp-dev@lists.fd.io<mailto: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 (#11402): https://lists.fd.io/g/vpp-dev/message/11402 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] -=-=-=-=-=-=-=-=-=-=-=-
