Re: [vpp-dev] Buffer chains and pre-data area
Hello Benoit, Thank you for your answer about buffer allocation in batches, my solution is way more efficient now. However, I still want to try to change the value of the " PRE_DATA_SIZE " cmake variable to see how it behaves with a greater value (i.e 256 instead of 128). To do so, I followed the method given in the documentation at the following url : [ https://fd.io/docs/vpp/master/gettingstarted/developers/buildsystem/cmakeandninja.html#tinkering-with-build-options-ccmake | https://fd.io/docs/vpp/master/gettingstarted/developers/buildsystem/cmakeandninja.html#tinkering-with-build-options-ccmake ] . The issue is that once I've changed the value of the " PRE_DATA_SIZE " variable, I press "c" to regenerate files that need to be regenerated and then I get this error in cmake output : CMake Error at cmake/misc.cmake:27 (_message): [1;31mDPDK RTE_PKTMBUF_HEADROOM (128) ;must be equal to PRE_DATA_SIZE (256)[m Call Stack (most recent call first): plugins/dpdk/CMakeLists.txt:65 (message) I guess I should also modify the value of " DPDK RTE_PKTMBUF_HEADROOM" but I don't know how I can do it ? Indeed, I can't find where this variable is defined. Jérôme De: "Benoit Ganne (bganne)" À: "jerome bayaux" , vpp-dev@lists.fd.io Cc: "Justin Iurman" Envoyé: Jeudi 15 Juillet 2021 19:16:32 Objet: RE: Buffer chains and pre-data area Hi Jerome, > However, when I tried to perform some performance tests I was quite > disappointed by the results : the buffer allocation for each packet is not > efficient at all. My question is then : Is there any way to increase the > performances ? To allocate buffers, I use the function "vlib_buffer_alloc" > defined in "buffer_funcs.h" but is it the right function to use ? Do you allocate buffers in batch? Let's say you want to encapsulate a batch of packets, instead of doing: while (n_left) u32 bi vlib_buffer_t *b vlib_buffer_alloc(vm, , 1) b = vlib_get_buffer (vm, bi) add b to the chain ... You should do something like (allocation error checking etc. is left as an exercise): u32 bi[VLIB_FRAME_SIZE] vlib_buffer_t *bufs[VLIB_FRAME_SIZE] vlib_buffer_alloc (vm, bi, n_left) vlib_get_buffers (vm, bi, bufs, n_left) while (n_left) add bufs[i] to the chain ... > In my case, the best option would be to have more space available in the > buffer's pre-data area but VPP does not seem to be built in a way that > allows easy modifications of the "PRE_DATA_SIZE" value. Am I right or is > there any "clean" method to change this value ? It is define as a cmake variable and can be customize through eg. cmake-gui. ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19821): https://lists.fd.io/g/vpp-dev/message/19821 Mute This Topic: https://lists.fd.io/mt/84230132/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Buffer chains and pre-data area
Dear vpp-dev, I'm trying to do some IPv6 in IPv6 encapsulation with no tunnel configuration. The objective is to encapsulate the received packet in an other IPv6 packet that will also "contain" a Hop-by-hop extension header. In summary, the structure of the final packet will look like this : Outer-IP6-Header -> Hop-by-hop-extension-header -> Original packet. The main concern here is that the size of the outer IP6 header + the size of the extension header > 128 bytes sometimes. When it arrives, I cannot write my data inside the buffer pre-data area because it has a size of 128 bytes. I already asked for solutions previously and I was adviced to either increase the size of the pre-data area by recompiling VPP or create a new buffer for my data and then chain it to the original one. I was able to create a buffer chain that seemed to work perfectly fine. However, when I tried to perform some performance tests I was quite disappointed by the results : the buffer allocation for each packet is not efficient at all. My question is then : Is there any way to increase the performances ? To allocate buffers, I use the function " vlib_buffer_alloc " defined in " buffer_funcs.h " but is it the right function to use ? In my case, the best option would be to have more space available in the buffer's pre-data area but VPP does not seem to be built in a way that allows easy modifications of the " PRE_DATA_SIZE" value. Am I right or is there any "clean" method to change this value ? Thank you all already for your help, Jérôme -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19790): https://lists.fd.io/g/vpp-dev/message/19790 Mute This Topic: https://lists.fd.io/mt/84230132/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] IPv6 Encapsulation - Buffer chains
Ole, I thought I did it correctly, but apparently not. I did again this part of the implementation starting from zero and this time everything works as it should ! Thanks for the help, Jérôme De: "Ole Troan" À: "jerome bayaux" Cc: vpp-dev@lists.fd.io Envoyé: Samedi 29 Mai 2021 17:14:45 Objet: Re: [vpp-dev] IPv6 Encapsulation - Buffer chains Jérôme, Did you remember to enqueue the new head buffer’s buffer index to the next node instead of the original? Cheers Ole On 29 May 2021, at 13:31, jerome.bay...@student.uliege.be wrote: BQ_BEGIN Hello all, As I explained it in a previous thread, I'm trying to do some IPv6 in IPv6 encapsulation. In addition to the outer IPv6 header that I'm adding for the encapsulation, I'm also adding an Hop-by-hop extension header. Since the size of the outer IPv6 header + the HBH header can be quite large, I need to use a new buffer to store the corresponding data. Then, I need to create a buffer chain to link the original buffer and the new one. It is relatively easy to add a buffer at the end of a chain : I've already done it and it worked fine. However, here in my case, I need to add the new buffer at the beginning of the chain because it carries the outer IPv6 header that obviously needs to come on top of the existing packet. My issue is that I'm not able to prepend properly my new buffer to the chain. Indeed, when I simply add the new buffer at the beginning of the chain without changing any fields in the buffer's metadata but the minimum required to make the chain (i.e next_buffer, total_length_not_including_first_buffer, etc.), the next VPP nodes seem to ignore my buffer and directly use the next one in the chain (i.e the original buffer in my case). I assume that I should set some buffer's metadata accordingly but I don't know which one ? More generally speaking, what should be configured in a newly created buffer when one wants to add it as the first buffer of a chain ? Thank you for your help, Jérôme BQ_END -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19508): https://lists.fd.io/g/vpp-dev/message/19508 Mute This Topic: https://lists.fd.io/mt/83168416/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] IPv6 Encapsulation - Buffer chains
Hello all, As I explained it in a previous thread, I'm trying to do some IPv6 in IPv6 encapsulation. In addition to the outer IPv6 header that I'm adding for the encapsulation, I'm also adding an Hop-by-hop extension header. Since the size of the outer IPv6 header + the HBH header can be quite large, I need to use a new buffer to store the corresponding data. Then, I need to create a buffer chain to link the original buffer and the new one. It is relatively easy to add a buffer at the end of a chain : I've already done it and it worked fine. However, here in my case, I need to add the new buffer at the beginning of the chain because it carries the outer IPv6 header that obviously needs to come on top of the existing packet. My issue is that I'm not able to prepend properly my new buffer to the chain. Indeed, when I simply add the new buffer at the beginning of the chain without changing any fields in the buffer's metadata but the minimum required to make the chain (i.e next_buffer, total_length_not_including_first_buffer, etc.), the next VPP nodes seem to ignore my buffer and directly use the next one in the chain (i.e the original buffer in my case). I assume that I should set some buffer's metadata accordingly but I don't know which one ? More generally speaking, what should be configured in a newly created buffer when one wants to add it as the first buffer of a chain ? Thank you for your help, Jérôme -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19502): https://lists.fd.io/g/vpp-dev/message/19502 Mute This Topic: https://lists.fd.io/mt/83168416/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] IPv6 in IPv6 Encapsulation
Hello Ole, I implemented the solution you suggested (i.e chaining the buffers) and it seems to work correctly now so thank you ! However, I had another issue : when some TCP or UDP packets arrive in VPP, the latter seems to set their checksum to zero and it also sets the "offload" flag of the associated buffer. In the last VPP nodes the packet traverses, the checksum is recomputed just before the packet is forwarded and everything is fine. Firstly, I don't really understand why it does that ? I create a veth interface on my ubuntu and then I link this interface to VPP by using an "host-interface". Maybe I need to configure something about the interfaces to disable this behavior ? Secondly, in a "normal" case, as I said here above, VPP is able to recompute the checksum at the end of the graph and nothing bad happens. The problem is that, in my case, I need to create a buffer chain and when I do so, VPP is not able to recompute the checksums (probably because some information from the buffer metadata it is usually using are invalidated because of the buffer chains ?). Thanks again for your help, Jérôme De: "jerome bayaux" À: "Ole Troan" Cc: vpp-dev@lists.fd.io, "Neale Ranns" , "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 18:20:31 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Changing the PRE_DATA_SIZE value in src/vlib/CMakeLists.txt does not appear to be that easy.. Indeed, it seems to require several other changes like the value of DPDK_RTE_PKTMBUF_HEADROOM that appears in src/plugins/dpdk/CMakeLists.txt, and some static assert fail by saying : "save_rewrite_length member must be able to hold the max value of rewrite length". Thus, the best solution is probably the one given by Ole ? Could you help me (guide me) a little bit by pointing me files of interest or by redirecting me towards some examples if some exist ? For instance, I'm not sure to see which functions I should use to create a new buffer and then to chain it to the "main" one. Jérôme De: "Ole Troan" À: "jerome bayaux" Cc: vpp-dev@lists.fd.io, "Neale Ranns" , "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 17:21:32 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation On 21 May 2021, at 17:15, Neale Ranns wrote: BQ_BEGIN Right, there’s only so much space available. You’ll need to recompile VPP to get more space. Change the PRE_DATA_SIZE value in src/vlib/CMakeLists.txt. BQ_END Alternatively use a new buffer for the new IPv6 header and extension header chain and chain the buffers together. You might want to look at the ioam plugin too btw. Cheers Ole BQ_BEGIN /neale From: jerome.bay...@student.uliege.be Date: Friday, 21 May 2021 at 17:06 To: Neale Ranns Cc: vpp-dev@lists.fd.io , Justin Iurman Subject: Re: [vpp-dev] IPv6 in IPv6 Encapsulation I've just run few tests to be sure : It's exactly that ! As long as the extension header is smaller or exactly equal to 128 bytes, everything is fine. Once it gets bigger than 128 bytes, it starts to go wrong and funky. Jérôme De: "Neale Ranns" À: "jerome bayaux" Cc: vpp-dev@lists.fd.io, "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 16:38:02 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Does it all start to go wrong when the extension header gets to about 128 bytes? /neale From: jerome.bay...@student.uliege.be Date: Friday, 21 May 2021 at 16:04 To: Neale Ranns Cc: vpp-dev@lists.fd.io , Justin Iurman Subject: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi again Neale, Here are some additional observations I've noticed and that could be useful for you to help me : 1) The error only shows up when the Hop-by-Hop extension header I add is big enough (I can give you a more accurate definition of "enough" if you need). When it is quite small, everything seems fine. 2) The faulty MAC address seems to follow a "pattern" : it is always of the form " X:00:00:00:e3:6e ", where byte X is a number that increases for the following packets. Moreover, the bytes " e3:6e " (i.e last 16 bytes of MAC address) are correct and correspond to the last 16 bytes of the expected and thus correct destination MAC address. Thank you for the help, Jérôme De: "jerome bayaux" À: "Neale Ranns" Cc: vpp-dev@lists.fd.io, "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 14:36:43 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi Neale, Here is a trace of a simple ping packet entering into VPP (let me know if you need more information about the topology I used) : Packet 8 00:00:38:194824: af-packet-input af_packet: hw_if_index 1 next-index 4 tpacket2_hdr: status 0x2001 len 118 s
Re: [vpp-dev] IPv6 in IPv6 Encapsulation
Changing the PRE_DATA_SIZE value in src/vlib/CMakeLists.txt does not appear to be that easy.. Indeed, it seems to require several other changes like the value of DPDK_RTE_PKTMBUF_HEADROOM that appears in src/plugins/dpdk/CMakeLists.txt, and some static assert fail by saying : "save_rewrite_length member must be able to hold the max value of rewrite length". Thus, the best solution is probably the one given by Ole ? Could you help me (guide me) a little bit by pointing me files of interest or by redirecting me towards some examples if some exist ? For instance, I'm not sure to see which functions I should use to create a new buffer and then to chain it to the "main" one. Jérôme De: "Ole Troan" À: "jerome bayaux" Cc: vpp-dev@lists.fd.io, "Neale Ranns" , "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 17:21:32 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation On 21 May 2021, at 17:15, Neale Ranns wrote: BQ_BEGIN Right, there’s only so much space available. You’ll need to recompile VPP to get more space. Change the PRE_DATA_SIZE value in src/vlib/CMakeLists.txt. BQ_END Alternatively use a new buffer for the new IPv6 header and extension header chain and chain the buffers together. You might want to look at the ioam plugin too btw. Cheers Ole BQ_BEGIN /neale From: jerome.bay...@student.uliege.be Date: Friday, 21 May 2021 at 17:06 To: Neale Ranns Cc: vpp-dev@lists.fd.io , Justin Iurman Subject: Re: [vpp-dev] IPv6 in IPv6 Encapsulation I've just run few tests to be sure : It's exactly that ! As long as the extension header is smaller or exactly equal to 128 bytes, everything is fine. Once it gets bigger than 128 bytes, it starts to go wrong and funky. Jérôme De: "Neale Ranns" À: "jerome bayaux" Cc: vpp-dev@lists.fd.io, "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 16:38:02 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Does it all start to go wrong when the extension header gets to about 128 bytes? /neale From: jerome.bay...@student.uliege.be Date: Friday, 21 May 2021 at 16:04 To: Neale Ranns Cc: vpp-dev@lists.fd.io , Justin Iurman Subject: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi again Neale, Here are some additional observations I've noticed and that could be useful for you to help me : 1) The error only shows up when the Hop-by-Hop extension header I add is big enough (I can give you a more accurate definition of "enough" if you need). When it is quite small, everything seems fine. 2) The faulty MAC address seems to follow a "pattern" : it is always of the form " X:00:00:00:e3:6e ", where byte X is a number that increases for the following packets. Moreover, the bytes " e3:6e " (i.e last 16 bytes of MAC address) are correct and correspond to the last 16 bytes of the expected and thus correct destination MAC address. Thank you for the help, Jérôme De: "jerome bayaux" À: "Neale Ranns" Cc: vpp-dev@lists.fd.io, "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 14:36:43 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi Neale, Here is a trace of a simple ping packet entering into VPP (let me know if you need more information about the topology I used) : Packet 8 00:00:38:194824: af-packet-input af_packet: hw_if_index 1 next-index 4 tpacket2_hdr: status 0x2001 len 118 snaplen 118 mac 66 net 80 sec 0x60a7a2bd nsec 0x35392422 vlan 0 vlan_tpid 0 00:00:38:194826: ethernet-input IP6: 8a:f6:cc:53:06:db -> 02:fe:6b:c4:db:06 00:00:38:194848: ip6-input ICMP6: db00::2 -> db03::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 64 ICMP echo_request checksum 0x26b9 00:00:38:194871: ip6-inacl INACL: sw_if_index 1, next_index 1, table 0, offset 1216 00:00:38:194916: ip6-add-hop-by-hop IP6_ADD_HOP_BY_HOP: next index 2 00:00:38:194955: ip6-lookup fib 0 dpo-idx 19 flow hash: 0x IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 256 00:00:38:194993: ip6-load-balance fib 0 dpo-idx 6 flow hash: 0x IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 256 00:00:38:195032: ip6-hop-by-hop IP6_HOP_BY_HOP: next index 5 len 152 traced 152 namespace id 1, trace type 0xf0f000, 2 elts left, 44 bytes per node [0], ttl: 0x0, node id short: 0x0, ingress sw: 0, egress sw: 0, timestamp (s): 0x0, timestamp (sub-sec): 0x0, ttl: 0x0, node id wide: 0x0, ingress hw: 0, egress hw: 0, appdata wide: 0x0, buffers avail able: 0 [1], ttl: 0x0, node id short: 0x0, ingress sw: 0, egress sw: 0, timestamp (s): 0x0, timestamp (sub-sec): 0x0, ttl: 0x0, node id wide: 0x0, ingress hw: 0, egress hw: 0, appdata wide: 0x0, buffers avail a
Re: [vpp-dev] IPv6 in IPv6 Encapsulation
I've just run few tests to be sure : It's exactly that ! As long as the extension header is smaller or exactly equal to 128 bytes, everything is fine. Once it gets bigger than 128 bytes, it starts to go wrong and funky. Jérôme De: "Neale Ranns" À: "jerome bayaux" Cc: vpp-dev@lists.fd.io, "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 16:38:02 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Does it all start to go wrong when the extension header gets to about 128 bytes? /neale From: jerome.bay...@student.uliege.be Date: Friday, 21 May 2021 at 16:04 To: Neale Ranns Cc: vpp-dev@lists.fd.io , Justin Iurman Subject: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi again Neale, Here are some additional observations I've noticed and that could be useful for you to help me : 1) The error only shows up when the Hop-by-Hop extension header I add is big enough (I can give you a more accurate definition of "enough" if you need). When it is quite small, everything seems fine. 2) The faulty MAC address seems to follow a "pattern" : it is always of the form " X:00:00:00:e3:6e ", where byte X is a number that increases for the following packets. Moreover, the bytes " e3:6e " (i.e last 16 bytes of MAC address) are correct and correspond to the last 16 bytes of the expected and thus correct destination MAC address. Thank you for the help, Jérôme De: "jerome bayaux" À: "Neale Ranns" Cc: vpp-dev@lists.fd.io, "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 14:36:43 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi Neale, Here is a trace of a simple ping packet entering into VPP (let me know if you need more information about the topology I used) : Packet 8 00:00:38:194824: af-packet-input af_packet: hw_if_index 1 next-index 4 tpacket2_hdr: status 0x2001 len 118 snaplen 118 mac 66 net 80 sec 0x60a7a2bd nsec 0x35392422 vlan 0 vlan_tpid 0 00:00:38:194826: ethernet-input IP6: 8a:f6:cc:53:06:db -> 02:fe:6b:c4:db:06 00:00:38:194848: ip6-input ICMP6: db00::2 -> db03::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 64 ICMP echo_request checksum 0x26b9 00:00:38:194871: ip6-inacl INACL: sw_if_index 1, next_index 1, table 0, offset 1216 00:00:38:194916: ip6-add-hop-by-hop IP6_ADD_HOP_BY_HOP: next index 2 00:00:38:194955: ip6-lookup fib 0 dpo-idx 19 flow hash: 0x IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 256 00:00:38:194993: ip6-load-balance fib 0 dpo-idx 6 flow hash: 0x IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 256 00:00:38:195032: ip6-hop-by-hop IP6_HOP_BY_HOP: next index 5 len 152 traced 152 namespace id 1, trace type 0xf0f000, 2 elts left, 44 bytes per node [0], ttl: 0x0, node id short: 0x0, ingress sw: 0, egress sw: 0, timestamp (s): 0x0, timestamp (sub-sec): 0x0, ttl: 0x0, node id wide: 0x0, ingress hw: 0, egress hw: 0, appdata wide: 0x0, buffers avail able: 0 [1], ttl: 0x0, node id short: 0x0, ingress sw: 0, egress sw: 0, timestamp (s): 0x0, timestamp (sub-sec): 0x0, ttl: 0x0, node id wide: 0x0, ingress hw: 0, egress hw: 0, appdata wide: 0x0, buffers avail able: 0 [2], ttl: 0x40, node id short: 0x1, ingress sw: 1, egress sw: 2, timestamp (s): 0x60a7a2bd, timestamp (sub-sec): 0x60a7a2bd, ttl: 0x40, node id wide: 0x1, ingress hw: 1, egress hw: 2, appdata wide: 0x 3, buffers available: 16288 unrecognized option 172 length 240 Packet 9 00:00:38:195078: handoff_trace HANDED-OFF: from thread 225 trace index 10354178 00:00:38:195078: ip6-rewrite tx_sw_if_index 2 adj-idx 6 : ipv6 via db01::2 memif1/0: mtu:9000 next:4 flags:[] 02fe9de1e36e02fe666cf11e86dd flow hash: 0x : 0800e36e02fe666cf11e86dd600aaa8d013fdb01 0020: 0001db0200022912318e00010001 0040: 5802f0f0 0060: 00:00:38:195130: memif1/0-output memif1/0 IP6: 02:fe:66:6c:f1:1e -> 08:00:00:00:e3:6e IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 63, payload length 256 I've just noticed that the packet is interpreted as 2 packets in the vpp trace output which is weird I guess. Maybe it's a first clue about my issue. As you can see in the last few lines, the destination MAC address is set to " 08:00:00:00:e3:6e " which is not the expected value in that case. Jérôme De: "Neale Ranns" À: "jerome bayaux" , vpp-dev@lists.fd.io Cc: "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 13:34:32 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi Jérôme, A packet tr
Re: [vpp-dev] IPv6 in IPv6 Encapsulation
Hi again Neale, Here are some additional observations I've noticed and that could be useful for you to help me : 1) The error only shows up when the Hop-by-Hop extension header I add is big enough (I can give you a more accurate definition of "enough" if you need). When it is quite small, everything seems fine. 2) The faulty MAC address seems to follow a "pattern" : it is always of the form " X :00:00:00:e3:6e ", where byte X is a number that increases for the following packets. Moreover, the bytes " e3:6e " (i.e last 16 bytes of MAC address) are correct and correspond to the last 16 bytes of the expected and thus correct destination MAC address. Thank you for the help, Jérôme De: "jerome bayaux" À: "Neale Ranns" Cc: vpp-dev@lists.fd.io, "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 14:36:43 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi Neale, Here is a trace of a simple ping packet entering into VPP (let me know if you need more information about the topology I used) : Packet 8 00:00:38:194824: af-packet-input af_packet: hw_if_index 1 next-index 4 tpacket2_hdr: status 0x2001 len 118 snaplen 118 mac 66 net 80 sec 0x60a7a2bd nsec 0x35392422 vlan 0 vlan_tpid 0 00:00:38:194826: ethernet-input IP6: 8a:f6:cc:53:06:db -> 02:fe:6b:c4:db:06 00:00:38:194848: ip6-input ICMP6: db00::2 -> db03::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 64 ICMP echo_request checksum 0x26b9 00:00:38:194871: ip6-inacl INACL: sw_if_index 1, next_index 1, table 0, offset 1216 00:00:38:194916: ip6-add-hop-by-hop IP6_ADD_HOP_BY_HOP: next index 2 00:00:38:194955: ip6-lookup fib 0 dpo-idx 19 flow hash: 0x IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 256 00:00:38:194993: ip6-load-balance fib 0 dpo-idx 6 flow hash: 0x IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 256 00:00:38:195032: ip6-hop-by-hop IP6_HOP_BY_HOP: next index 5 len 152 traced 152 namespace id 1, trace type 0xf0f000, 2 elts left, 44 bytes per node [0], ttl: 0x0, node id short: 0x0, ingress sw: 0, egress sw: 0, timestamp (s): 0x0, timestamp (sub-sec): 0x0, ttl: 0x0, node id wide: 0x0, ingress hw: 0, egress hw: 0, appdata wide: 0x0, buffers avail able: 0 [1], ttl: 0x0, node id short: 0x0, ingress sw: 0, egress sw: 0, timestamp (s): 0x0, timestamp (sub-sec): 0x0, ttl: 0x0, node id wide: 0x0, ingress hw: 0, egress hw: 0, appdata wide: 0x0, buffers avail able: 0 [2], ttl: 0x40, node id short: 0x1, ingress sw: 1, egress sw: 2, timestamp (s): 0x60a7a2bd, timestamp (sub-sec): 0x60a7a2bd, ttl: 0x40, node id wide: 0x1, ingress hw: 1, egress hw: 2, appdata wide: 0x 3, buffers available: 16288 unrecognized option 172 length 240 Packet 9 00:00:38:195078: handoff_trace HANDED-OFF: from thread 225 trace index 10354178 00:00:38:195078: ip6-rewrite tx_sw_if_index 2 adj-idx 6 : ipv6 via db01::2 memif1/0: mtu:9000 next:4 flags:[] 02fe9de1e36e02fe666cf11e86dd flow hash: 0x : 0800e36e02fe666cf11e86dd600aaa8d013fdb01 0020: 0001db0200022912318e00010001 0040: 5802f0f0 0060: 00:00:38:195130: memif1/0-output memif1/0 IP6: 02:fe:66:6c:f1:1e -> 08:00:00:00:e3:6e IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 63, payload length 256 I've just noticed that the packet is interpreted as 2 packets in the vpp trace output which is weird I guess. Maybe it's a first clue about my issue. As you can see in the last few lines, the destination MAC address is set to " 08:00:00:00:e3:6e " which is not the expected value in that case. Jérôme De: "Neale Ranns" À: "jerome bayaux" , vpp-dev@lists.fd.io Cc: "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 13:34:32 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi Jérôme, A packet trace would help us help you in this case /neale From: vpp-dev@lists.fd.io on behalf of jerome.bayaux via lists.fd.io Date: Friday, 21 May 2021 at 13:05 To: vpp-dev@lists.fd.io Cc: Justin Iurman Subject: [vpp-dev] IPv6 in IPv6 Encapsulation Hello all, I'm trying to do some IPv6 in IPv6 encapsulation with no tunnel configuration. The objective is to encapsulate the received packet in an other IPv6 packet that will also "contain" a Hop-by-hop extension header. In summary, the structure of the final packet will look like this : Outer-IP6-Header -> Hop-by-hop-extension-header -> Original packet. To do so, I use an access list to redirect packets to my VPP node that encapsulates the received packets. My node is located be
Re: [vpp-dev] IPv6 in IPv6 Encapsulation
Hi Neale, Here is a trace of a simple ping packet entering into VPP (let me know if you need more information about the topology I used) : Packet 8 00:00:38:194824: af-packet-input af_packet: hw_if_index 1 next-index 4 tpacket2_hdr: status 0x2001 len 118 snaplen 118 mac 66 net 80 sec 0x60a7a2bd nsec 0x35392422 vlan 0 vlan_tpid 0 00:00:38:194826: ethernet-input IP6: 8a:f6:cc:53:06:db -> 02:fe:6b:c4:db:06 00:00:38:194848: ip6-input ICMP6: db00::2 -> db03::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 64 ICMP echo_request checksum 0x26b9 00:00:38:194871: ip6-inacl INACL: sw_if_index 1, next_index 1, table 0, offset 1216 00:00:38:194916: ip6-add-hop-by-hop IP6_ADD_HOP_BY_HOP: next index 2 00:00:38:194955: ip6-lookup fib 0 dpo-idx 19 flow hash: 0x IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 256 00:00:38:194993: ip6-load-balance fib 0 dpo-idx 6 flow hash: 0x IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 64, payload length 256 00:00:38:195032: ip6-hop-by-hop IP6_HOP_BY_HOP: next index 5 len 152 traced 152 namespace id 1, trace type 0xf0f000, 2 elts left, 44 bytes per node [0], ttl: 0x0, node id short: 0x0, ingress sw: 0, egress sw: 0, timestamp (s): 0x0, timestamp (sub-sec): 0x0, ttl: 0x0, node id wide: 0x0, ingress hw: 0, egress hw: 0, appdata wide: 0x0, buffers avail able: 0 [1], ttl: 0x0, node id short: 0x0, ingress sw: 0, egress sw: 0, timestamp (s): 0x0, timestamp (sub-sec): 0x0, ttl: 0x0, node id wide: 0x0, ingress hw: 0, egress hw: 0, appdata wide: 0x0, buffers avail able: 0 [2], ttl: 0x40, node id short: 0x1, ingress sw: 1, egress sw: 2, timestamp (s): 0x60a7a2bd, timestamp (sub-sec): 0x60a7a2bd, ttl: 0x40, node id wide: 0x1, ingress hw: 1, egress hw: 2, appdata wide: 0x 3, buffers available: 16288 unrecognized option 172 length 240 Packet 9 00:00:38:195078: handoff_trace HANDED-OFF: from thread 225 trace index 10354178 00:00:38:195078: ip6-rewrite tx_sw_if_index 2 adj-idx 6 : ipv6 via db01::2 memif1/0: mtu:9000 next:4 flags:[] 02fe9de1e36e02fe666cf11e86dd flow hash: 0x : 0800e36e02fe666cf11e86dd600aaa8d013fdb01 0020: 0001db0200022912318e00010001 0040: 5802f0f0 0060: 00:00:38:195130: memif1/0-output memif1/0 IP6: 02:fe:66:6c:f1:1e -> 08:00:00:00:e3:6e IP6_HOP_BY_HOP_OPTIONS: db01::1 -> db02::2 tos 0x00, flow label 0xaaa8d, hop limit 63, payload length 256 I've just noticed that the packet is interpreted as 2 packets in the vpp trace output which is weird I guess. Maybe it's a first clue about my issue. As you can see in the last few lines, the destination MAC address is set to " 08:00:00:00:e3:6e " which is not the expected value in that case. Jérôme De: "Neale Ranns" À: "jerome bayaux" , vpp-dev@lists.fd.io Cc: "Justin Iurman" Envoyé: Vendredi 21 Mai 2021 13:34:32 Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation Hi Jérôme, A packet trace would help us help you in this case /neale From: vpp-dev@lists.fd.io on behalf of jerome.bayaux via lists.fd.io Date: Friday, 21 May 2021 at 13:05 To: vpp-dev@lists.fd.io Cc: Justin Iurman Subject: [vpp-dev] IPv6 in IPv6 Encapsulation Hello all, I'm trying to do some IPv6 in IPv6 encapsulation with no tunnel configuration. The objective is to encapsulate the received packet in an other IPv6 packet that will also "contain" a Hop-by-hop extension header. In summary, the structure of the final packet will look like this : Outer-IP6-Header -> Hop-by-hop-extension-header -> Original packet. To do so, I use an access list to redirect packets to my VPP node that encapsulates the received packets. My node is located between the "ip6-inacl" node and the "ip6-lookup" node. Here is the path that is thus taken by the packet : "ethernet-input" -> "ip6-input" -> "ip6-inacl" -> "My VPP node" -> "ip6-lookup" -> etc. The issue I have is the following : The packets that leave VPP after being encapsulated have some issues regarding their MAC addresses. Indeed, for example, the destination MAC is not the expected one (and is not even a valid one according to the topology I use). It looks like there is an issue with the resolution of the MAC addresses or something like that but I'm not sure. Should I do anything in my implementation to kind of "warn" VPP that I am performing an IPv6 encapsulation or something ? Thanks for your answers, Jérôme -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Rep
[vpp-dev] IPv6 in IPv6 Encapsulation
Hello all, I'm trying to do some IPv6 in IPv6 encapsulation with no tunnel configuration. The objective is to encapsulate the received packet in an other IPv6 packet that will also "contain" a Hop-by-hop extension header. In summary, the structure of the final packet will look like this : Outer-IP6-Header -> Hop-by-hop-extension-header -> Original packet. To do so, I use an access list to redirect packets to my VPP node that encapsulates the received packets. My node is located between the "ip6-inacl" node and the "ip6-lookup" node. Here is the path that is thus taken by the packet : "ethernet-input" -> "ip6-input" -> "ip6-inacl" -> "My VPP node" -> "ip6-lookup" -> etc. The issue I have is the following : The packets that leave VPP after being encapsulated have some issues regarding their MAC addresses. Indeed, for example, the destination MAC is not the expected one (and is not even a valid one according to the topology I use). It looks like there is an issue with the resolution of the MAC addresses or something like that but I'm not sure. Should I do anything in my implementation to kind of "warn" VPP that I am performing an IPv6 encapsulation or something ? Thanks for your answers, Jérôme -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19423): https://lists.fd.io/g/vpp-dev/message/19423 Mute This Topic: https://lists.fd.io/mt/82983110/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] 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: 0x 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): 0x [1], ttl: 0xfe, node id short: 0x1, ingress sw: 1, egress sw: 2, timestamp ( s): 0x604f458d, timestamp (sub-sec): 0x604f458d, transit delay (ns): 0x 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: 0x : 02fe538a6ec702fe95c9987b86dd608400fcdb00 0020: 0001db0200023a06313200010002 0040: 28001f00fd0200010002604f458d604f458dfe010001 0060: 0002604f458d604f458d80007dfe8a310001c7014ba24516 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)" À: "jerome bayaux" , 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 ~# vppctl show trace Best ben > -Original Message- > From: 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 n
[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/example/simple-ip6 | https://github.com/CiscoDevNet/iOAM/tree/master/scripts/vpp_sandbox/example/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 (#18907): https://lists.fd.io/g/vpp-dev/message/18907 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] -=-=-=-=-=-=-=-=-=-=-=-
