> On 21 May 2021, at 17:15, Neale Ranns <ne...@graphiant.com> wrote: > > > 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.
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 > /neale > > > From: jerome.bay...@student.uliege.be <jerome.bay...@student.uliege.be> > Date: Friday, 21 May 2021 at 17:06 > To: Neale Ranns <ne...@graphiant.com> > Cc: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>, Justin Iurman > <justin.iur...@uliege.be> > 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" <ne...@graphiant.com> > À: "jerome bayaux" <jerome.bay...@student.uliege.be> > Cc: vpp-dev@lists.fd.io, "Justin Iurman" <justin.iur...@uliege.be> > 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 <jerome.bay...@student.uliege.be> > Date: Friday, 21 May 2021 at 16:04 > To: Neale Ranns <ne...@graphiant.com> > Cc: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>, Justin Iurman > <justin.iur...@uliege.be> > 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" <jerome.bay...@student.uliege.be> > À: "Neale Ranns" <ne...@graphiant.com> > Cc: vpp-dev@lists.fd.io, "Justin Iurman" <justin.iur...@uliege.be> > 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 0x20000001 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: 0x00000000 > 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: 0x00000000 > 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: 0x00000000 > 00000000: 08000000e36e02fe666cf11e86dd600aaa8d0100003fdb010000000000000000 > 00000020: 000000000001db02000000000000000000000000000229120000318e00010001 > 00000040: 5802f0f000000000000000000000000000000000000000000000000000000000 > 00000060: 00000000000000000000000000000000000000000000000000000000 > 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" <ne...@graphiant.com> > À: "jerome bayaux" <jerome.bay...@student.uliege.be>, vpp-dev@lists.fd.io > Cc: "Justin Iurman" <justin.iur...@uliege.be> > 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 <vpp-dev@lists.fd.io> on behalf of jerome.bayaux > via lists.fd.io <jerome.bayaux=student.uliege...@lists.fd.io> > Date: Friday, 21 May 2021 at 13:05 > To: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> > Cc: Justin Iurman <justin.iur...@uliege.be> > 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/Reply Online (#19431): https://lists.fd.io/g/vpp-dev/message/19431 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] -=-=-=-=-=-=-=-=-=-=-=-
