Hi Filip/Ole, Any thoughts on this? For point 1) below, I have confirmed that using fib-index of 0 in the reverse path lookup key helps work around the out2in hash table lookup issue (multiple VRFs case). I guess, the ideal way to fix this would be by using the right fib-index itself when populating the out2in hash table at the entry creation time.
Nikhil On Fri, 18 Sep 2020 at 13:05, Nikhil Jagtap via lists.fd.io <nikhil.jagtap= [email protected]> wrote: > 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 (#17495): https://lists.fd.io/g/vpp-dev/message/17495 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]] -=-=-=-=-=-=-=-=-=-=-=-
