06-04-2019 05:09 AM - edited 02-21-2020 09:11 AM
Hello,
I have found a previous question related to the same error I'm getting but no answer.
I have rearranged the policy based on different new sections, different logic. I didn't changed the content of the sections, so basically the policy is the same.
Now when I'm trying to deploy the new policy, I'm getting this error:
"An error response from the device prevented successful completion of this operation. The device provided the following description: no access-list … log default Specified access-list does not exist."
This seems like a bug for me, since the access-list is the one to be deployed.
This is random error, if I'm moving the section or the rule, I'm hitting the same error on different rule.
I'm wondering if somebody had the same error at some point and how was solved it.
Many thanks in advance for your feedback!
Solved! Go to Solution.
08-22-2019 02:50 AM
Hi Jordi,
The only workaround I found is to manipulate in CLI the config directly on the ASA.
The steps I used:
1. change the deployment mode on CSM to a file instead of the device. This option is in Tools > Cisco Security Manager Administration > Deployment
2. copy the full config on your machine to file1
3. go on CLI to the ASA unable to deploy
4. <show run> and copy all access-lists to file2
5. on file2 search and replace <access-list> with <no access-list>
6. from file1 copy and paste all access-list to file3
7. from file1 copy and paste all access-group to file4
8. go back to CLI on the ASA and
a. paste file2
b. paste file3
c. paste file4
9. go back to CSM and change back the deployment from file to device
10. on the policy which you are trying to deploy on CSM, disable a not very important rule
11. save and deploy
For me worked.
Good luck!
Catalin
06-04-2019 01:55 PM
what is the version of CSM ?
is this FWSM or ASA ? if ASA what is the Code running on that ASA ?
06-05-2019 03:11 AM
CSM 4.15
ASA 9.6(3)9
08-19-2019 01:20 AM
Hello,
I have the same issue, please could you tell me how resolve this issue?
Many thanks for all
Jordi
08-22-2019 02:50 AM
Hi Jordi,
The only workaround I found is to manipulate in CLI the config directly on the ASA.
The steps I used:
1. change the deployment mode on CSM to a file instead of the device. This option is in Tools > Cisco Security Manager Administration > Deployment
2. copy the full config on your machine to file1
3. go on CLI to the ASA unable to deploy
4. <show run> and copy all access-lists to file2
5. on file2 search and replace <access-list> with <no access-list>
6. from file1 copy and paste all access-list to file3
7. from file1 copy and paste all access-group to file4
8. go back to CLI on the ASA and
a. paste file2
b. paste file3
c. paste file4
9. go back to CSM and change back the deployment from file to device
10. on the policy which you are trying to deploy on CSM, disable a not very important rule
11. save and deploy
For me worked.
Good luck!
Catalin
08-29-2019 06:01 AM
I see a lot of people have read the "recipe" but no comments. Maybe some explanation is need it. CSM cannot deploy because sees too many differences, lets say. So the idea is to limit that, replacing manually old ACLs with new ACLs generated by CSM. Like I said previously, for me it's working perfectly.
Maybe Cisco fixed this bug in newer CSM versions but I did't get the chance to test that.
09-18-2019 12:08 AM
Hello Team,
I have opened on case to Cisco TAC
This deployment is failing because of defect CSCuy23983. This is caused because the first line of the delta config change is "no access list". This fails because the ASA does not have log default appended to the ACE and the CSM is trying to negate it. This defect is impacts 4.15 and 4.16.
4.17(0.65) and 4.17(0) SP1 are both fixed versions.
workaround of this
no access-list CSM_FW_ACL_outside_3 extended permit tcp any object XXXXXX eq www log default
Which is using “log default” at the end of this rule, I have checked internally about this issue and in order to immediately fix this so that you can deploy the change, you will need to make a change to the ACL Parameters in CSM & then re-deploy the job. See steps below:
+Note about the differences between the 2 options:
Speed (default)-Increases deployment speed by sending only the delta (difference) between the new and old ACLs. This is the recommended option. By making use of ACL line numbers, this approach selectively adds, updates, or deletes ACEs at specific positions and avoids resending the entire ACL. Because the ACL being edited is still in use, there is a small chance that some traffic might be handled incorrectly between the time an ACE is removed and the time that it is added to a new position. The ACL line number feature is supported by most Cisco IOS, PIX and ASA versions, and became available in FWSM from FWSM 3.1(1).
Traffic-This approach switches ACLs seamlessly and avoids traffic interruption. However, deployment takes longer and uses more device memory before the temporary ACLs are deleted. First, a temporary copy is made of the ACL that is intended for deployment. This temporary ACL binds to the target interface. Then the old ACL is recreated with its original name but with the content of the new ACL. It also binds to the target interface. At this point, the temporary ACL is deleted.
Many thanks
Jordi
09-18-2019 01:48 AM
Hi Jordi,
Good to know about ACLs deployment option from 'speed' to 'traffic'.
Thanks for sharing!
Best regards,
Catalin
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide