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/exampl > 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 (#18918): https://lists.fd.io/g/vpp-dev/message/18918 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] -=-=-=-=-=-=-=-=-=-=-=-
