cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
285
Views
0
Helpful
2
Replies

Dear Cisco engineers, kindly update Integrated-Versions in CSCvz70310

tvotna
Spotlight
Spotlight

And also bug description is not correct for the following reasons:
- this issue affects regular NAT configurations and not only net-snmp
- it always happens when tmatch compile thread is running, no matter how many NAT rules you have

So, true conditions are:
- NAT transactional commit is enabled
- tmatch compile thread is running (e.g. after reboot or during failover config sync)
- new partially overlapping twice NAT rules are added as shown below, even though config is 100% valid (e.g. when startup-config is processed by the standalone unit after reload or by the standby unit during config sync)

The issue is not seen when either:
- NAT transactional commit is disabled or
- tmatch compile is not running

The end result is that partially overlapping NAT rule is lost on either standalone unit or standby unit in a failover pair.

Repro steps:

ASA/CONTEXT/pri/act(config)# show run asp rule-engine transactional-commit nat
asp rule-engine transactional-commit nat
ASA/CONTEXT/pri/act(config)#
ASA/CONTEXT/pri/act(config)# copy /noconfirm disk0:/nat2.cfg running-config

..................................................................................................................................................................................................................
Cryptochecksum (changed): 2fa15e80 9d6e308e a3147293 c45bc715

432043 bytes copied in 15.210 secs (28802 bytes/sec)
ASA/pri/act(config)#
ASA/CONTEXT/pri/act(config)# changeto system
ASA/pri/act(config)# show proc cpu-usage sorted non-zero | i tmatch
0x00005564665d2fe3 0x00007f1d862c0860 49.4% 19.5% 10.8% tmatch compile thread
ASA/pri/act(config)#
ASA/pri/act(config)# changeto c CONTEXT
ASA/CONTEXT/pri/act(config)#
ASA/CONTEXT/pri/act(config)# nat (inside,outside) source static obj-192.168.0.1 obj-192.168.0.1 destination static obj-172.16.0.1 obj-10.0.0.1 service obj-tcp-dest-eq-10001 obj-tcp-dest-eq-10001
ASA/CONTEXT/pri/act(config)# nat (inside,outside) source static obj-192.168.0.2 obj-192.168.0.2 destination static obj-172.16.0.1 obj-10.0.0.1 service obj-tcp-dest-eq-10001 obj-tcp-dest-eq-10001
ERROR: NAT unable to reserve ports.

ASA/CONTEXT/pri/act(config)#
ASA/CONTEXT/pri/act(config)# show nat | i obj-192.168.0.[12]
2512 (inside) to (outside) source static obj-192.168.0.1 obj-192.168.0.1 destination static obj-172.16.0.1 obj-10.0.0.1 service obj-tcp-dest-eq-10001 obj-tcp-dest-eq-10001
ASA/CONTEXT/pri/act(config)#
ASA/pri/act(config)# changeto system
ASA/pri/act(config)# show proc cpu-usage sorted non-zero | i tmatch
0x00005564665d38dc 0x00007f1d862c0860 0.0% 11.6% 12.9% tmatch compile thread
ASA/pri/act(config)#
ASA/pri/act(config)# changeto c CONTEXT
ASA/CONTEXT/pri/act(config)#
ASA/CONTEXT/pri/act(config)# nat (inside,outside) source static obj-192.168.0.1 obj-192.168.0.1 destination static obj-172.16.0.1 obj-10.0.0.1 service obj-tcp-dest-eq-10001 obj-tcp-dest-eq-10001
ASA/CONTEXT/pri/act(config)# nat (inside,outside) source static obj-192.168.0.2 obj-192.168.0.2 destination static obj-172.16.0.1 obj-10.0.0.1 service obj-tcp-dest-eq-10001 obj-tcp-dest-eq-10001
WARNING: mapped-address 172.16.0.1/10001-0 overlaps with existing static NAT in Section 1, rule 2512.
ASA/CONTEXT/pri/act(config)#
ASA/CONTEXT/pri/act(config)# show nat | i obj-192.168.0.[12]
2512 (inside) to (outside) source static obj-192.168.0.1 obj-192.168.0.1 destination static obj-172.16.0.1 obj-10.0.0.1 service obj-tcp-dest-eq-10001 obj-tcp-dest-eq-10001
2513 (inside) to (outside) source static obj-192.168.0.2 obj-192.168.0.2 destination static obj-172.16.0.1 obj-10.0.0.1 service obj-tcp-dest-eq-10001 obj-tcp-dest-eq-10001
ASA/CONTEXT/pri/act(config)#

 

1 Accepted Solution

Accepted Solutions

tvotna
Spotlight
Spotlight

Ok. The bug fix will be included into the next 9.16.4.x interim release due out this March.

 

View solution in original post

2 Replies 2

Ramblin Tech
Spotlight
Spotlight

The most effective way to communicate with Cisco's Development Engineers about a CDETS/DDTS ID is via a TAC Case. If this particular defect impacted you, open a TAC Service Request to report your issue. If you already have an SR open, use that as the vehicle to communicate this info. It is extremely unlikely that any DE associated with this particular defect is actually monitoring this space.

It should also be noted that a defect's "headline" (ie, bug ID title) and  text summary often do not exactly match all the triggers that impacted customers see, as these only represent the proverbial tip of the iceberg with regard to all of the internal defect notes that are not externally visible to customers. Often the headline only represents an assessment of the first report of the defect and not any kind of root-cause analysis that comes from DEs working on the defect for some time.

Disclaimer: I am long in CSCO

tvotna
Spotlight
Spotlight

Ok. The bug fix will be included into the next 9.16.4.x interim release due out this March.

 

Review Cisco Networking for a $25 gift card