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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to