;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 t
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 :
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é: Same
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 quit
hat, 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: "jerom
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 1
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"
À: "jer
C
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:3
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
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 : Out
t 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&quo
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/CiscoD
Hello all,
I'm currently improving some stuff for the IOAM implementation, for example,
I'm trying to add the possibility to put the Hop-by-Hop extension header
containing IOAM data inside a newly created packet instead of inserting it
directly to the existing packet (i.e doing IPv6 in IPv6 enc
13 matches
Mail list logo
