Closed mattspera closed 1 year ago
NilashishC
commented
1 year ago @mattspera Thank you for reporting these issues. The first will be resolved with the changes in #731. However, I'm unsure about how the second issue occurs, i.e., how the ACE negate line that you shared is invalid. It seems to be a valid command when run in a Nexus 9300v (NX-OS 9.3.6).
Will it be possible to share the "before" state of ACLs from that device and the task which triggers this traceback?
Thank you.
mattspera
commented
1 year ago @NilashishC No problem.
Regarding the second issue (configuring bug), firstly, the ACE negate line sent to the device by Ansible in the example provided in the issue above is invalid even when running directly on the CLI on a Cisco Nexus9000 C93108TC-EX chassis NXOS: version 7.0(3)I7(3). See output below:
nexus-01(config-acl)# sh ip access-lists ACL-PLUGIN-TEST
IP access list ACL-PLUGIN-TEST
10 permit tcp 1.1.1.1/32 range 7111 9111 192.168.0.0/24 established
nexus-01(config-acl)# no 10 permit tcp host 1.1.1.1 range 7111 9111 range 192.168.0.0/24 established
^
% Invalid command at '^' marker.From observing the invalid ACE negate line, we can see that the no 10 permit tcp host 1.1.1.1 range 7111 9111 component of the line is valid, however the range 192.168.0.0/24 is invalid. The range component of this portion of the command should not be there. A valid version of the ACE negate line would look like no 10 permit tcp host 1.1.1.1 range 7111 9111 192.168.0.0/24 established.
Here is an example of the "before" state of an ACL from that device and the task which triggers this traceback:
nexus-01(config)# sh ip access-lists RH-SUPPORT-ACL
IP access list RH-SUPPORT-ACL
10 permit tcp 1.1.1.1/32 range 7111 9111 192.168.0.0/24 established
nexus-01(config)#Task to modify this ACL (updating ACE 10 destination prefix to 10.0.0.0/24)
- name: DEPLOY CISCO NX-OS ACL CONFIG
hosts: all
gather_facts: false
tasks:
- name: DEPLOY ACL - NXOS
cisco.nxos.nxos_acls:
state: replaced
config:
- afi: ipv4
acls:
- name: RH-SUPPORT-ACL
aces:
- sequence: 10
grant: permit
protocol: tcp
protocol_options:
tcp:
established: true
source:
host: 1.1.1.1
port_protocol:
range:
start: 7111
end: 9111
destination:
prefix: 10.0.0.0/24Traceback (-vvv)
fatal: [nexus-01]: FAILED! => {
"changed": false,
"module_stderr": "no 10 permit tcp host 1.1.1.1 range 7111 9111 range 192.168.0.0/24 established\r\r\n ^\r\n% Invalid command at '^' marker.\r\n\rnexus-01(config-acl)# ",
"module_stdout": "",
"msg": "MODULE FAILURE\nSee stdout/stderr for the exact error"
}@mattspera Ah, I see. I missed the "range" word in the original traceback you shared. In that case, the patch in #731 fixes both the issues for you.
Thank you!
SUMMARY
When gathering ACL facts using the
nxos_aclsmodule, if an ACL contains an ACE which contains a source host with a source port range to a destination, it is parsed incorrectly. Similarly, when attempting to configure an ACL with an ACE of that format, the module errors out.ISSUE TYPE
COMPONENT NAME
nxos_acls
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
cisco Nexus9000 C93108TC-EX chassis NXOS: version 7.0(3)I7(3)
STEPS TO REPRODUCE
GATHERING BUG
Using the
nxos_aclsmodule, gather ACL facts from an NX-OS device which contains an ACL which contains an ACE of the following format:CONFIGURING BUG
Using the
nxos_aclsmodule, attempt to deploy an ACL to an NX-OS device which contains an ACE of the following format:EXPECTED RESULTS
GATHERING BUG
It is expected the ACE is parsed correctly, like so (expected output snippet of ACL ACE in question):
CONFIGURING BUG
It is expected the ACE is deployed correctly, without error, sending the following configuration to the device:.
ACTUAL RESULTS
GATHERING BUG
Actual output snippet of ACL ACE in question:
As can be observed, the
destinationdict is parsed incorrectly, presenting anaddresskey with a value ofrangeand awildcard_bitskey with a value of the destination prefix (192.168.0.0/24).CONFIGURING BUG
An error is thrown:
As can be observed, the syntax of the command sent to the device is incorrect.