You could try the buffer metadata tracking plugin, which should tell you which buffer metadata fields are touched in the graph trajectory you're using.
I haven't tested it in a long time, so "caveat emptor." FWIW... Dave -----Original Message----- From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Benoit Ganne (bganne) via lists.fd.io Sent: Tuesday, March 16, 2021 6:21 AM To: jerome.bay...@student.uliege.be; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Unexpected behavior of Classifier Hi Jerome, Thanks. If I understand the issue correctly, what you are observing is the classifier does set the correct value in the ip6-inacl node but by the time the packet hits the ip6-hop-by-hop node, this value has been overwritten. If this is correct, the most likely culprit is the union in vnet_opaque_t structure have changed, and you should be able to pinpoint where it gets overwritten and why by using hardware watchpoint. For example in gdb, we can put a breakpoint right after the opaque_index is set in ip6-inacl node and then put a watchpoint on the opaque_index location. When it is overwritten later, the watchpoint should break in gdb and you should see why: ~# gdb -p $(pidof gdb) (gdb) l src/vnet/ip/ip_in_out_acl.c:642 637 638 e0 = vnet_classify_find_entry_inline (t0, (u8 *) h0, hash0, now); 639 if (e0) 640 { 641 vnet_buffer (b[0])->l2_classify.opaque_index = e0->opaque_index; 642 vlib_buffer_advance (b[0], e0->advance); 643 644 next0 = (e0->next_index < n_next_nodes) ? 645 e0->next_index : next0; 646 (gdb) b src/vnet/ip/ip_in_out_acl.c:642 (gdb) continue ... Inject 1 packet with bad behavior. ... gdb should break in ip6-inacl node right after the opaque_index is set. (gdb) watch -l vb(b[0])->l2_classify.opaque_index (gdb) continue ... Hopefully the watchpoint will break when opaque_index is overwritten and you can see the offensive line. Hope this helps, ben > -----Original Message----- > From: jerome.bay...@student.uliege.be > <jerome.bay...@student.uliege.be> > Sent: lundi 15 mars 2021 12:35 > To: Benoit Ganne (bganne) <bga...@cisco.com>; vpp-dev@lists.fd.io > Subject: Re: Unexpected behavior of Classifier > > Hello Benoit, > > Here is the packet trace I gathered : > > Packet 1 > > 00:00:09:235345: memif-input > memif: hw_if_index 1 next-index 4 > slot: ring 0 > 00:00:09:235349: ethernet-input > IP6: 02:fe:94:4a:87:eb -> 02:fe:ea:c3:43:da > 00:00:09:235368: ip6-input > IP6_HOP_BY_HOP_OPTIONS: db00::1 -> db02::2 > tos 0x00, flow label 0x0, hop limit 253, payload length 132 > 00:00:09:235384: ip6-inacl > INACL: sw_if_index 1, next_index 1, table 0, offset 1216 > 00:00:09:235412: ip6-lookup > fib 0 dpo-idx 7 flow hash: 0x00000000 > IP6_HOP_BY_HOP_OPTIONS: db00::1 -> db02::2 > tos 0x00, flow label 0x0, hop limit 253, payload length 132 > 00:00:09:235431: ip6-hop-by-hop > IP6_HOP_BY_HOP: next index 5 len 56 traced 56 namespace id 2, trace > type 0x1f, 0 elts left, 20 bytes per node > [0], ttl: 0xfd, node id short: 0x2, ingress sw: 1, egress sw: 2, > timestamp (s): 0x604f458d, timestamp (sub-sec): 0x604f458d, transit > delay > (ns): 0xffffffff > [1], ttl: 0xfe, node id short: 0x1, ingress sw: 1, egress sw: 2, > timestamp (s): 0x604f458d, timestamp (sub-sec): 0x604f458d, transit > delay > (ns): 0xffffffff > 00:00:09:235450: ip6-rewrite > tx_sw_if_index 2 adj-idx 7 : ipv6 via db02::2 memif2/0: mtu:9000 > next:4 > flags: > [] 02fe538a6ec702fe95c9987b86dd flow hash: 0x00000000 > 00000000: > 02fe538a6ec702fe95c9987b86dd60000000008400fcdb000000000000000000 > 00000020: > 000000000001db0200000000000000000000000000023a060000313200010002 > 00000040: > 280000001f00fd00000200010002604f458d604f458dfffffffffe0000010001 > 00000060: 0002604f458d604f458dffffffff80007dfe8a310001c7014ba24516 > 00:00:09:235470: memif2/0-output > memif2/0 > IP6: 02:fe:95:c9:98:7b -> 02:fe:53:8a:6e:c7 > IP6_HOP_BY_HOP_OPTIONS: db00::1 -> db02::2 > tos 0x00, flow label 0x0, hop limit 252, payload length 132 > > You will maybe notice some differences on your side if you tried to > run traffic that includes IOAM data because I used a "fresh" > implementation of IOAM I worked on these last months with another > person. Anyway, the issue I talked about is still present as you can > see it in the packet trace here above and it was also present before we > modified IOAM implementation. > > I was not able to perform the test with the "old" IOAM implementation > (i.e the one still present currently in VPP repo) because it does not > seem to work anymore in recent VPP releases.. > > ________________________________ > > De: "Benoit Ganne (bganne)" <bga...@cisco.com> > À: "jerome bayaux" <jerome.bay...@student.uliege.be>, > vpp-dev@lists.fd.io > Envoyé: Vendredi 12 Mars 2021 15:35:28 > Objet: RE: Unexpected behavior of Classifier > > > Hi Jerome, > > Could you share a packet trace of a packet that is being classified > but not correctly redirected? Eg. if you use dpdk: > ~# vppctl clear trace > ~# vppctl trace add dpdk-input 10 > <run your traffic> > ~# vppctl show trace > > Best > ben > > > -----Original Message----- > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of > > jerome.bay...@student.uliege.be > > Sent: vendredi 12 mars 2021 12:12 > > To: vpp-dev@lists.fd.io > > Subject: [vpp-dev] Unexpected behavior of Classifier > > > > Hello all, > > > > I think I found a bug/ an unexpected behavior of the classifier when > > I > use > > it for IOAM encapsulation/decapsulation. > > > > Indeed, I used the classifier to select packets for IOAM > > encapsulation > or > > decapsulation, as it is done in the example described here : > > > > > https://github.com/CiscoDevNet/iOAM/tree/master/scripts/vpp_sandbox/ex > ampl > > e/simple-ip6 > > > > More precisely, here are the commands we are interested in, when it > comes > > to decapsulation : > > > > classify table miss-next ip6-node ip6-lookup mask l3 ip6 dst > > classify session acl-hit-next ip6-node ip6-lookup table-index 0 > > match l3 > > ip6 dst db03::02 ioam-decap test1 > > set int input acl intfc host-l_c2 ip6-table 0 set int input acl > > intfc host-l_c1 ip6-table 0 > > > > This set of commands (more specifically the "classify session" one) > > is supposed to set the value of the "vnet_buffer (b0)- > > >l2_classify.opaque_index" that will be checked in the > > "vnet/ip/ip6_forward.c" file, in the "ip6_hop_by_hop_node" node (at > > line > > 2666 for single loop implementation). The issue is that the value of > > the "opaque_index" does not seem to be set anymore when the check > > occurs, leading to no redirection of the packet towards the > > "ip6_pop_hop_by_hop_node" so no decapsulation of IOAM data as it should. > > To find the origin of the problem, I tried to trace the value of > > this "opaque_index" as the packet traverses different VPP nodes and > > I noticed the following : > > > > It seems that the classifier does its job correctly and sets the > > "opaque_index" to a value that will make true the condition at line > > 2666 in "ip6_forward.c". However, as I said here above, when it > > arrives at > this > > condition, the "opaque_index" appears to be equal to a null value... > > > > I was not able to find why it behaves like this, can someone try to > > help me to solve this issue ? > > > > Thanks, > > > > Jérôme
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18940): https://lists.fd.io/g/vpp-dev/message/18940 Mute This Topic: https://lists.fd.io/mt/81276451/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-