Hello, I just started looking at the NAT VPP plugin for a NAT64 specific use case. When employing multiple VRFs, I found that the NAT64 functionality was not working and so I started looking at the NAT64 implementation to understand the same. I had a few queries on the same.
1) In the forward path (IPv6 to IPv4 transition), when creating a bib entry (nat64_db_bib_entry_create()), we are using fib-index of 0 in the bib-key being used for populating the bib out2in hash table. Same thing is being done for ste-key when creating a ste entry and populating it in the ste out2in hash table. But in the reverse path (IPv4 to IPv6 transition), the fib-index of the rx-interface is being used in the key used for looking up the bib and ste entries in the corresponding out2in hash tables. So the lookups will be successful only if the rx-interface is in the default fib. Is this intentional? 2) Should the nat64_not_translate() function also check if the IPv6 src address indeed has the configured NAT64 prefix, and skip doing NAT64 on the packet if there is no match? This will be kind of similar to the behavior of deterministic NAT44. Thanks & Regards, Nikhil
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17456): https://lists.fd.io/g/vpp-dev/message/17456 Mute This Topic: https://lists.fd.io/mt/76926524/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
