cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1223
Views
15
Helpful
9
Replies

NAT64 Dropping IPv6 to IPv4 Packets

claurie
Level 1
Level 1

Hi Team,

I have Configured NAT64 on an ASR. It appears everything is working as required until the outgoing DNS64 Addressed IPv6 packets 'hit the NAT64 server (ASR)' on Int GE0/0/0. Int GE0/0/3.31211 is connected to the IPv6 only host. Keen to hear what the Community has in the way of advice.

 

See sh nat64 statistics output below.

 

Edge.TR.M1#sh nat64 statistics
NAT64 Statistics

Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Sessions found: 179796
Sessions created: 12225
Expired translations: 12225
Global Stats:
Packets translated (IPv4 -> IPv6)
Stateless: 0
Stateful: 65316
MAP-T: 0
Packets translated (IPv6 -> IPv4)
Stateless: 0
Stateful: 126705
MAP-T: 0

Interface Statistics
GigabitEthernet0/0/0 (IPv4 configured, IPv6 configured):
Packets translated (IPv4 -> IPv6)
Stateless: 0
Stateful: 65316
MAP-T: 0
Packets translated (IPv6 -> IPv4)
Stateless: 0
Stateful: 0
MAP-T: 0
Packets dropped: 1393902
GigabitEthernet0/0/3.31211 (IPv4 configured, IPv6 configured):
Packets translated (IPv4 -> IPv6)
Stateless: 0
Stateful: 0
MAP-T: 0
Packets translated (IPv6 -> IPv4)
Stateless: 0
Stateful: 126705
MAP-T: 0
Packets dropped: 278
Dynamic Mapping Statistics
v6v4
access-list nat64-acl pool pool1 refcount 0
pool pool1:
start 103.102.222.241 end 103.102.222.254
total addresses 14, allocated 0 (0%)
address exhaustion packet count 0
Limit Statistics

 

Please note: My (Public) DNS64 is using the WKP to create the manufactured AAAA records thus there is no prefix explicitly configured.

Here is the related NAT64 Configuration elements

 

ipv6 unicast-routing
ipv6 dhcp pool M1_Customers
prefix-delegation pool Global_M1_Pool
dns-server 2001:4860:4860::6464
dns-server 2001:4860:4860::64
option include-all

 

interface GigabitEthernet0/0/0
description Internet Transit
bandwidth 100000
ip address 49.xxx.xxx.82 255.255.255.252
ip nbar protocol-discovery
ip access-group TRAFFIC in
ip access-group TRAFFIC out
negotiation auto
nat64 enable
ipv6 address 2402:xxxx:3000::1/126
ipv6 enable
no mop enabled

!

interface GigabitEthernet0/0/3.31211
description test host int
encapsulation dot1Q 3121 second-dot1q 3501
ip address 103.xxx.xxx.237 255.255.255.252
nat64 enable
ipv6 address 2406:xxxx:2000:1::1/64
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
ipv6 dhcp server M1_Customers

!

ipv6 access-list nat64-acl
permit ipv6 any any

!

nat64 v4 pool pool1 103.xxx.xxx.241 103.xxx.xxx.254
nat64 v6v4 list nat64-acl pool pool1 overload

1 Accepted Solution

Accepted Solutions

Hi Craig,

 

As you have most likely already seen, my Internet facing IPv6 Interface is a Dual Stack interface.

 

It is fine to have this interface as dual stack. This is not a problem.

 

Not previously advised, I also have an IPv4 only Interface connecting to a second ISP.

 

You should configure "nat64 enable" on this interface. If any traffic comes back through this interface and nat64 is not enabled, this traffic will not be translated back, which could explain what you are seeing.

 

A question: should I statically route outgoing NAT64 translated IPv4 packet via the second IPv4 only interface?

 

This is not required.

 

Could not explicitly directing NAT64 translated IPv4 packets to either ISP interfaces be resulting in the dropped NAT64 packets? 

 

Just make sure you have "nat64 enable" on all Internet facing interfaces through which the traffic might come back and you should be fine.

 

Regards,

 

 

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

View solution in original post

9 Replies 9

Harold Ritter
Cisco Employee
Cisco Employee

Hi Craig,

 

Can you tell us a bit more about what is not working? Can you ping 64:ff9b::8.8.8.8 from the IPv6 only host.

 

Also, could you please post the output from a "show nat64 trans"

 

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hi Harold,
At the user level, some websites are loading without issue, other will not. Some sites load, but when user tries to log into "customer account" there is no response. My guess, based on below, NAT64 is not actually 'translating'.
"sh nat64 translations" indicates no translations occurred:
Edge.TR.M1#sh nat64 settings translations

Proto Original IPv4 Translated IPv4
Translated IPv6 Original IPv6
----------------------------------------------------------------------------


Total number of translations: 0

Hello,

 

what does your routing look like ?

 

nat64 route ?

ipv6 route ?

Hi Georg, thanks for your interest. IPv6 Internet reachability is 100%.
sh nat64 routes; sh nat64 routes int and sh ipv6 route outputs shown below.
#sh nat64 routes
IPv4 Prefix Adj. Address Enabled Output IF
Global IPv6 Prefix
#sh nat64 routes int
IF
NAT64 Route IPv4 Prefixes
GigabitEthernet0/0/0:
GigabitEthernet0/0/3:
GigabitEthernet0/0/3.31211:
#sh ipv6 route
IPv6 Routing Table - default - 17 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, RL - RPL, O - OSPF Intra, OI - OSPF Inter
OE1 - OSPF ext 1, OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1
ON2 - OSPF NSSA ext 2, la - LISP alt, lr - LISP site-registrations
ld - LISP dyn-eid, lA - LISP away, le - LISP extranet-policy
a - Application
B ::/0 [20/0]
via FE80::AA0C:DFF:FE37:A2F2, GigabitEthernet0/0/0
S 64:FF9B::/96 [1/0]
via ::100.0.0.2, NVI0
C 2402:7800:3000::/126 [0/0]
via GigabitEthernet0/0/0, directly connected
L 2402:7800:3000::1/128 [0/0]
via GigabitEthernet0/0/0, receive
S 2406:93C0::/33 [1/0]
via Null0, directly connected
O 2406:93C0:0:9::/126 [110/6]
via FE80::868A:8DFF:FEED:F2E4, GigabitEthernet0/0/4
O 2406:93C0:0:A::/126 [110/6]

Hi Georg and Harold,

As you have most likely already seen, my Internet facing IPv6 Interface is a Dual Stack interface. Not previously advised, I also have an IPv4 only Interface connecting to a second ISP. A question: should I statically route outgoing NAT64 translated IPv4 packet via the second IPv4 only interface? Could not explicitly directing NAT64 translated IPv4 packets to either ISP interfaces be resulting in the dropped NAT64 packets? I am racking my brain trying to think of causes, as I believe I have NAT64 configured correctly.

Thanks for assisting!

Hi Craig,

 

As you have most likely already seen, my Internet facing IPv6 Interface is a Dual Stack interface.

 

It is fine to have this interface as dual stack. This is not a problem.

 

Not previously advised, I also have an IPv4 only Interface connecting to a second ISP.

 

You should configure "nat64 enable" on this interface. If any traffic comes back through this interface and nat64 is not enabled, this traffic will not be translated back, which could explain what you are seeing.

 

A question: should I statically route outgoing NAT64 translated IPv4 packet via the second IPv4 only interface?

 

This is not required.

 

Could not explicitly directing NAT64 translated IPv4 packets to either ISP interfaces be resulting in the dropped NAT64 packets? 

 

Just make sure you have "nat64 enable" on all Internet facing interfaces through which the traffic might come back and you should be fine.

 

Regards,

 

 

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hi Harold,

Thanks! As the saying goes: I couldn't see the forest for the trees.

Whilst I am yet to test again, I believe your advice has "hit the nail on the head". Some of the services that were not working were MS Office 365 and MS Teams. We peer directly with MS over an interface that had not been considered. I have now enabled NAT64 on the 2nd ISP Interface and the 'peering' interface and will test ASAP. I will let you know, but I think you have identified my failure!

Cheers

claurie
Level 1
Level 1

Hi Harold,

Sorry for the delay. Enabling NAT64 on all Internet Facing interfaces worked a treat. Full Public Internet IPv6 and IPv4 host access has been achieved. Thanks Again!

You are very welcome Craig.

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card