[VPP-2114] NAT64 Packet Duplication on Incoming Interface

[vvalderrv]

Description

I've sent a couple of messages to the vpp-dev list on this issue. This seems like the right forum, so I'm adding the information here. Since the message I sent below, I also tested with a build from master with the same results:

vpp v24.06-rc0~284-gf03d44814 built by root on d8cdbd8e-d8fe-4c08-8bef-4fb25c345ae4 at 2024-05-22T00:35:46

At this point, I've tried everything I can think of (other than moving to bare metal, which I don't currently have a system to test with) to resolve this. It doesn't seem like NAT64 is usable with recent releases and code in its current state.

Original message below:

I’m working on getting VPP setup to handle NAT64 for a small ISP. I’ve largely followed https://ipng.ch/s/articles/2021/12/23/vpp-playground.html, with some modifications for the current release (24.02) running on Ubuntu 22.04. Interfaces are assigned by PCI address directly to VPP and segmented from the management interface in a ‘dataplane’ namespace. I’m also using linux_cp and linux_nl with FRR. I’ve witnessed this behavior with every configuration of VPP I’ve tried (initially using just VPP without linux_cp/nl and FRR, and with veth interfaces routed through the main system).

NAT64 works, but each IPv6 request (using ping for testing) results in a loop on the local interface on VPP that doesn’t stop until the TTL is exhausted. In testing, this also results in that ICMP6 echo packet being processed as many times as the TTL allows (lots of DUP! reply messages coming back from the IPv4 ping target). Note that requests from a directly connected interface do not show this behavior; it’s only routed client requests that are a problem.

This is the ping request:

https://gist.github.com/justindthomas/aade7d72d7a4aa5bb816a9e14a595365

This is a packet capture on the switch interface connected to the VPP server showing that the loop is not happening outside of VPP:

https://gist.github.com/justindthomas/e1da8c7a0d702a671d1c4a2291e27472

Here is the VPP trace showing the duplicated echo request packets from packet 8 through 37 and then the response packets in 38 and 39 (the reply and a TTL exceeded message).

https://gist.github.com/justindthomas/699f731533cc957449a9a176df6e4246

Here is the VPP IP6 FIB (note that there is not currently a default route since all clients will come from 2604:2940::/32, so I only have a direct route for that – I have also configured this previously with a default route to the same destination with the same behavior):

https://gist.github.com/justindthomas/cb7c56ed25503f9c3aa161ea57630a2a

Here is the VPP IP FIB:

https://gist.github.com/justindthomas/63ced82309c6d00ecfad5792ea52564e

The bulk of the VPP config is set by this script:

https://gist.github.com/justindthomas/cc39cbf5f02e74070150097e88be494a

I’ll be happy if someone tells me that I just screwed something up and a configuration change would correct it, but it looks like a bug to me. Pings to the IPv6 interface of VPP work fine. And pings from directly connected systems also work fine. It’s just systems that are routed.

Assignee

Unassigned

Reporter

Justin Thomas

Comments

• JIRAUSER16535 (Thu, 23 May 2024 18:55:39 +0000): In further research, I've found that I'm having similar trouble with other, non-VPP IPv6 interfaces on this particular Juniper switch. I'm going to resolve this as "Unable to Reproduce" and chase down what's going on with my networking gear.

Original issue: https://jira.fd.io/browse/VPP-2114

[vvalderrv]

In further research, I've found that I'm having similar trouble with other, non-VPP IPv6 interfaces on this particular Juniper switch. I'm going to resolve this as "Unable to Reproduce" and chase down what's going on with my networking gear.