[P4-dev] P4 support for PCAP
antonin at barefootnetworks.com
Tue Jul 18 20:44:59 EDT 2017
I think you can do exactly what you are describing using P4 and bmv2. Just
choose a special port number (0xFF works fine) where you will unicast
packets of interest then "attach" a virtual interface to this port number
when starting simple_switch using the -i command-line option (just like for
any other data port). You can capture packets going out on this interface
and save them to a pcap file.
In P4 I would define an action "capture" which sets the egress destination
to your special port. You can use it as the default action for forwarding
tables, etc. You can also call it when the TTL == 0.
As for parser errors, things are a little tricky. The bmv2 parser
implementation implements the standard library parser errors described in
the P4_16 specification, as well as the verify built-in parser statement.
However, the v1model architecture model (
https://github.com/p4lang/p4c/blob/master/p4include/v1model.p4), as well as
bmv2 simple_switch, do not support accessing the parser error "register" in
the match-action pipeline (i.e. in the ingress & egress control flows). In
a nutshell, this means that you cannot drop / capture packets based on
parser failures. I believe this will be fixed in PSA (
https://github.com/p4lang/p4c/blob/master/p4include/psa.p4), but there is
no bmv2 PSA implementation yet.
It is pretty straightforward to extend simple_switch to expose parser
errors to the ingress control-flow, you can look into it if it's important
On Sun, Jul 16, 2017 at 6:42 AM, James Bensley <jwbensley at gmail.com> wrote:
> On 14 July 2017 at 23:17, Antonin Bas <antonin at barefootnetworks.com>
> > Hi James,
> > At this point, I am not sure how you would be able to achieve this.
> > errors like the ones you mention should result in a bmv2 error log
> > (although some errors may not be supported at this stage). We can
> imagine in
> > the future supporting a command-line option that will log those incorrect
> > packets to a special pcap file, but so far you are the only one that has
> > expressed interest in such a feature. Fee free to open an issue in the
> > repo requesting this feature and tag it as "improvement".
> > Thanks,
> > Antonin
> Hi Antonin,
> Many thanks for your response. Initially I am thinking about the
> scenario of writing p4 code and building it on x86 for testing
> purposes, and having the ability to capture packets to a PCAP file but
> only those of "interest" (packets with errors, packets with specific
> properties like TTL == 0, no route in the forwarding table etc).
> Further down the line, in the case of building to a hardware target
> like a router or switch, some NPUs set the next-hop/egress interface
> to a special drop index like 0xFF when there is a problem with the
> packet or there is a lookup failure (no route to destination). I'd
> like to be able to set the next hop interface index it to a physical
> interface of my chosing (or logical interface like over a GRE tunnel
> for example) to capture those packets with errors or issues to debug
> the P4 program on the target device.
> I'm not sure how practicle this is. If you think it's a good idea I
> can open a feature requests on GitHub.
> P4-dev mailing list
> P4-dev at lists.p4.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the P4-dev