PaloAltoNetworks/pan-os-ansible

Not providing an address prefix to panos_bgp_policy_rule results in NoneType error.

Closed this issue · 2 comments

Describe the bug

Not providing an address prefix to panos_bgp_policy_rule results in NoneType error.

Expected behavior

Expected to add rule to PA appliance as is without an address prefix. Verified appliance running software version 9.1.12 allows BGP policy rules without address prefix

Current behavior

Ansible playbook errors out with NoneType error:

An exception occurred during task execution. To see the full traceback, use -vvv. The error was: TypeError: 'NoneType' object is not iterable
fatal: [playbook]: FAILED! => {"changed": false, "module_stderr": "Traceback (most recent call last):
File "/root/.ansible/tmp/ansible-tmp-1648475077.4205122-46833-230470489806833/AnsiballZ_panos_bgp_policy_rule.py", line 100, in
_ansiballz_main()\n File "/root/.ansible/tmp/ansible-tmp-1648475077.4205122-46833-230470489806833/AnsiballZ_panos_bgp_policy_rule.py", line 92, in _ansiballz_main
invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)
File "/root/.ansible/tmp/ansible-tmp-1648475077.4205122-46833-230470489806833/AnsiballZ_panos_bgp_policy_rule.py", line 41, in invoke_module
run_name='main', alter_sys=True)
File "/usr/lib/python3.6/runpy.py", line 205, in run_module
return _run_module_code(code, init_globals, run_name, mod_spec)
File "/usr/lib/python3.6/runpy.py", line 96, in _run_module_code
mod_name, mod_spec, pkg_name, script_name)
File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/tmp/ansible_panos_bgp_policy_rule_payload_i_muidrc/ansible_panos_bgp_policy_rule_payload.zip/ansible_collections/paloaltonetworks/panos/plugins/modules/panos_bgp_policy_rule.py", line 403, in
File "/tmp/ansible_panos_bgp_policy_rule_payload_i_muidrc/ansible_panos_bgp_policy_rule_payload.zip/ansible_collections/paloaltonetworks/panos/plugins/modules/panos_bgp_policy_rule.py", line 379, in main
TypeError: 'NoneType' object is not iterable
", "module_stdout": "", "msg": "MODULE FAILURE
See stdout/stderr for the exact error", "rc": 1}

Possible solution

Verify address prefix is being passed before attempting to work with it or simply document that this is a required field for the script.

Steps to reproduce

Add the following to an ansible playbook.

- name: BGP Policy
  panos_bgp_policy_rule:
    provider: '{{ provider }}'
    vr_name: 'default'
    name: 'Export'
    type: 'export'
    used_by: ['network1','network 2']
    action_as_path_type: 'remove'
    match_as_path_regex: '{{ pod_as_number }'
    action: 'allow'
    commit: false

Screenshots

Context

I am using the Palo alto as a transit firewall between two cisco ACI L3 out instances that are in separate tenants within the same pod, although each leaf /tenant has its own BGP AS number, the pod itself has its own AS Number. I need to strip off the AS path for routes advertised through the Palo alto from 'network 1' and 'network 2' otherwise ACI recognizes that the routes originate from within the pod and will not accept them even though the routing is being preformed between two separate routing instances. I was attempting to keep the playbook as clean as possible and as the firewall itself does not require an address prefix for the rule I assumed the module also did not.

Your Environment

  • Collection: paloaltonetworks.panos 2.9.0
  • Python: Python 3.6.9
  • Ansible: 2.11.9
  • PAN-OS Python Library & version (e.g. pandevice 0.14.0, pan-os-python 1.0.2): pan-os-python (1.6.0)

Hi @CrimsonBinome24, I wasn't able to reproduce this one, although things have changed somewhat since this was originally raised as an Issue. I used the following task based on your original description:

    - name: BGP Policy
      paloaltonetworks.panos.panos_bgp_policy_rule:
        provider: '{{ device }}'
        vr_name: 'new-vrouter'
        name: 'Export'
        type: 'export'
        used_by: ['network1', 'network2']
        action_as_path_type: 'remove'
        match_as_path_regex: '12345'
        action: 'allow'
        commit: false

And got this successful result:

PLAY [host_labfw] **********************************************************************************************************************************

TASK [Gathering Facts] *****************************************************************************************************************************
ok: [host_labfw]

TASK [BGP Policy] **********************************************************************************************************************************
changed: [host_labfw]

PLAY RECAP *****************************************************************************************************************************************
host_labfw                 : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Screenshot 2023-02-14 at 19 27 35
Screenshot 2023-02-14 at 19 27 49

Could you re-test, or if this is no longer relevant can we close it off? Thanks

I tore down my old environment but as far as I can tell this issue has been resolved in later versions.