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