Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[nxos_prefix_lists] Fix idempotency issues caused by IP prefix notation discrepancies #894

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Miyoshi-Ryota
Copy link
Contributor

@Miyoshi-Ryota Miyoshi-Ryota commented Sep 3, 2024

SUMMARY

Fixed an issue where idempotency was not maintained due to discrepancies in the notation of IP prefixes. By introducing the ipaddress module to standardize prefixes, we ensure that the playbook and running-config prefixes are compared accurately, preventing unnecessary configuration changes.

For example, previously, a playbook specifying prefix: ::0/ and a running-config showing ipv6 prefix-list plist1 seq 10 permit 0::/0, or a playbook specifying prefix: 10.0.0.8/24 and a running-config showing ip prefix-list plist2 seq 10 permit 10.0.0.0/24, would result in unnecessary changes. With this update, such discrepancies are handled, maintaining idempotency and ensuring existing configurations are not repeatedly deleted and re-added.

Supplementary Information:
The notation you enter in configure terminal and the notation in the show run output may differ on Nexus devices. Therefore, a simple text comparison could break idempotency.

An example is shown below.

# conf t
(config)# ipv6 prefix-list plist1 seq 10 permit ::/0
(config)# ip prefix-list plist2 seq 10 permit 10.0.0.8/24
(config)# exit
# show run | inc plist 
ip prefix-list plist2 seq 10 permit 10.0.0.0/24
ipv6 prefix-list plist1 seq 10 permit 0::/0
ISSUE TYPE
  • Bugfix Pull Request
COMPONENT NAME

nxos_prefix_lists

ADDITIONAL INFORMATION

Before this change, when I executed the playbook below multiple times, the result would always be changed, and plist1 would be deleted and added each time.

- hosts: all
  gather_facts: no
  vars:
    ansible_connection: network_cli
    ansible_user: "hoo"
    ansible_password: "bar"
    ansible_network_os: cisco.nxos.nxos
  tasks:
    - name: prefixlists_always_changed
      cisco.nxos.nxos_prefix_lists:
        state: "overridden"
        config:
          - afi: ipv6
            prefix_lists:
            - entries:
              - action: permit
                prefix: ::0/0
                sequence: 10
              name: "plist1"

…on discrepancies

Fixed an issue where idempotency was not maintained due to discrepancies in the notation of IP prefixes.
By introducing the `ipaddress` module to standardize prefixes,
we ensure that the playbook and running-config prefixes are compared accurately,
preventing unnecessary configuration changes.

For example, previously, a playbook specifying `prefix: ::0/` and a running-config showing `ipv6 prefix-list plist1 seq 10 permit 0::/0`,
or a playbook specifying `prefix: 10.0.0.8/24` and a running-config showing `ip prefix-list plist2 seq 10 permit 10.0.0.0/24`,
would result in unnecessary changes. With this update, such discrepancies are handled,
maintaining idempotency and ensuring existing configurations are not repeatedly deleted and re-added.

Supplementary Information:
The notation you enter in configure terminal and the notation in the `show run` output may differ on Nexus devices.
Therefore, a simple text comparison could break idempotency.

An example is shown below.
```
(config)# ipv6 prefix-list plist1 seq 10 permit ::/0
(config)# ip prefix-list plist2 seq 10 permit 10.0.0.8/24
(config)# exit
ip prefix-list plist2 seq 10 permit 10.0.0.0/24
ipv6 prefix-list plist1 seq 10 permit 0::/0
```
@Miyoshi-Ryota
Copy link
Contributor Author

Miyoshi-Ryota commented Dec 17, 2024

@Ruchip16 Hello, what do you think about this pull request?

I believe that the fixes in this PR may not hold much value for IPv4, but they do for IPv6. In IPv6, there are many correct representations in principle. Additionally, Cisco's notation does not always seem to be the most common one.

For example, when I ask network engineers around me, they agree, and considering the existence of RFC 5952, ::/0 seems to be a more standard representation than 0::/0, which is required by current this module.

Therefore, in its current state, this module might lead to issues unless one has a deep understanding of Ansible.

Hence, I believe this PR has certain value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant