Juan, I didn’t see your clarification mail - what I wrote still stands but the external ICMP is of course different, so please disregard my mail, and I will go get more coffee. :)
--a > On 11 Jan 2018, at 10:20, Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES > at Cisco) <matfa...@cisco.com> wrote: > > It goes to to ip4-lookup because it is translated from IPv6 to IPv4. There is > currently one workaround, you need to set nat64 inside interface on loopback > interface, add route for NAT64 prefix and use “nat64 add prefix 1:2:3::/96 > interface loop0”. We have plan to change this behaviour. > > Regards, > Matus > > > From: Juan Salmon [mailto:salmonju...@gmail.com] > Sent: Thursday, January 11, 2018 10:08 AM > To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) > <matfa...@cisco.com> > Cc: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] nat64 local ping problem > > I run with following configuration: > > set int state GigabitEthernet0/4/0 up > set int state GigabitEthernet0/5/0 up > set int ip address GigabitEthernet0/4/0 2002::2/64 > set int ip address GigabitEthernet0/5/0 192.168.5.2/24 > ip route add ::/0 via 2002::1 > set int nat64 in GigabitEthernet0/4/0 > set int nat64 out GigabitEthernet0/5/0 > nat64 add prefix 1:2:3::/96 > nat64 add pool address 192.168.50.1 - 192.168.50.19 > trace add dpdk-input 100 > > > when nat64 is enabled, and I run ping6 2002::2%3 in In inside node, the > traffic goes to nat64-in2out and drop packets. > > sample trace: > > > 00:00:34:663182: dpdk-input > GigabitEthernet0/4/0 rx queue 0 > buffer 0x4839: current data 14, length 104, free-list 0, clone-count 0, > totlen-nifb 0, trace 0x4 > PKT MBUF: port 0, nb_segs 1, pkt_len 118 > buf_len 2176, data_len 118, ol_flags 0x0, data_off 128, phys_addr > 0x6a220e80 > packet_type 0x0 > IP6: 52:54:00:93:37:e8 -> 52:54:00:94:26:53 > ICMP6: 2002::1 -> 2002::2 > tos 0x00, flow label 0xead44, hop limit 64, payload length 64 > ICMP echo_request checksum 0x71c9 > 00:00:34:663198: ip6-input > ICMP6: 2002::1 -> 2002::2 > tos 0x00, flow label 0xead44, hop limit 64, payload length 64 > ICMP echo_request checksum 0x71c9 > 00:00:34:663201: nat64-in2out > NAT64-in2out: sw_if_index 1, next index 0 > 00:00:34:663203: ip4-lookup > fib 0 dpo-idx 0 flow hash: 0x00000000 > ICMP: 192.168.50.1 -> 0.0.0.2 > tos 0x00, ttl 64, length 84, checksum 0x87fe > fragment id 0x0000 > ICMP echo_request checksum 0x54dd > 00:00:34:663203: ip4-drop > ICMP: 192.168.50.1 -> 0.0.0.2 > tos 0x00, ttl 64, length 84, checksum 0x87fe > fragment id 0x0000 > ICMP echo_request checksum 0x54dd > 00:00:34:663204: error-drop > ip4-input: ip4 adjacency drop > > > > I think it should go to ip6-lookup not ip4-lookup. > > > > > Best Regards, > Juan Salmon. > > On Thu, Jan 11, 2018 at 12:17 PM, Matus Fabian -X (matfabia - PANTHEON > TECHNOLOGIES at Cisco) <matfa...@cisco.com> wrote: > Hi Juan, > > What do you mean by that? Do you have packet trace? > > Regards, > Matus > > > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On > Behalf Of Juan Salmon > Sent: Thursday, January 11, 2018 8:45 AM > To: vpp-dev@lists.fd.io > Subject: [vpp-dev] nat64 local ping problem > > Hi, > > Does nat64 support local ping? It's failed in my test. > > Best Regards, > Juan Salmon. > > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
