Cannot set aggregate interface or subinterface zone

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Cannot set aggregate interface or subinterface zone

L1 Bithead

Hello,

 

I'm trying to update or create an aggregate interface or subinterface with a zone_name parameter.

 

Something like:

---

- hosts: all
name: CONFIGURE NEW AGGREGATE AND SUBINTERFACE IN EXISTING ZONE
connection: local
gather_facts: False

collections:
- paloaltonetworks.panos

vars:
ansible_python_interpreter: /var/lib/awx/venv/ansible/bin/python3

tasks:
- name: Configure aggregate interface
panos_aggregate_interface:
provider: '{{ provider }}'
template: "test"
if_name: ae2
zone_name: Access 

Whether the interface exists or not, whether the zone already exists or not, whether the interface is already in the target zone or not, I get the following:

The full traceback is:
File "/tmp/ansible_panos_aggregate_interface_payload_m7t77c6e/ansible_panos_aggregate_interface_payload.zip/ansible_collections/paloaltonetworks/panos/plugins/modules/panos_aggregate_interface.py", line 296, in main
File "/var/lib/awx/venv/ansible/lib/python3.6/site-packages/panos/network.py", line 1063, in set_zone
zone_name, mode, refresh, update, running_config, return_type
File "/var/lib/awx/venv/ansible/lib/python3.6/site-packages/panos/network.py", line 393, in set_zone
mode=mode,
File "/var/lib/awx/venv/ansible/lib/python3.6/site-packages/panos/base.py", line 1639, in _set_reference
obj.update(reference_var)
File "/var/lib/awx/venv/ansible/lib/python3.6/site-packages/panos/base.py", line 702, in update
retry_on_peer=self.HA_SYNC,
File "/var/lib/awx/venv/ansible/lib/python3.6/site-packages/panos/base.py", line 3682, in method
raise the_exception

and

 

 "msg": "Failed setref: layer3 'ae2' is not a valid reference"

 

If I try something similar with panos_l3_subinterface, I get the same error (slightly different line number references in the calling code).

 

Environment is

paloaltonetworks.panos collection 2.9.0

pan-os-python 1.6.0

pandevice 0.14.0

ansible 2.9.11

Python 3.6.8

 

 

 

 

2 accepted solutions

Accepted Solutions

Hi @plonergan, the answers lie in PAN-OS configuration schema. The other items are attributes of an interface, whist the zone is not. An interface is an attribute of a zone, which is contained inside a VSYS. We attach (import) an interface to a zone. The task to create an interface has to (under the hood) first create the interface with its IP address and other attributes, then assign that interface to the zone. Hope that helps? (FYI: I've submitted a change to the docs to cover this kind of scenario.)

Help the community: "Like" helpful comments, and click "Accept as Solution" if you found your answer 🙂

View solution in original post

L5 Sessionator

Thanks Peter. I understand your comment, and I've raised an issue on the module repo to track improving this in future.

Help the community: "Like" helpful comments, and click "Accept as Solution" if you found your answer 🙂

View solution in original post

6 REPLIES 6

L5 Sessionator

Hi @plonergan, I can replicate this, and it is the same in PAN-OS (go to the zone, try to add an aggregate or sub-interface in the Interfaces list, they are not in the drop-down list). I'll see if I can investigate this a little more...

Help the community: "Like" helpful comments, and click "Accept as Solution" if you found your answer 🙂

I got it @plonergan...
The VSYS needs to be included in the task. Without this, the newly created AE will have vsys=null, and will not be "imported" into the correct VSYS in which your zone is defined. Panorama works at a layer of abstraction that needs to be able to cope with all scenarios, including single-VSYS and multi-VSYS. This explains why in both GUI and Ansible the reference was invalid. If you are not working with a multi-VSYS system, just include this in your task as VSYS1 is the default:

vsys: "vsys1"

 

Here's a full example:

  tasks:
    - name: Configure aggregate interface
      panos_aggregate_interface:
        provider: '{{ device }}'
        template: "pa-5260-template"
        vsys: "vsys1"
        if_name: ae2
        zone_name: 5260_dmz

    - name: Configure sub-interface
      panos_l3_subinterface:
        provider: '{{ device }}'
        template: "pa-5260-template"
        vsys: "vsys1"
        name: "ae2.3"
        tag: 300
        enable_dhcp: false
        ip: ["10.1.1.1/24"]
        zone_name: "5260_dmz"

 

Help the community: "Like" helpful comments, and click "Accept as Solution" if you found your answer 🙂

Jimmy,

 

That fixed the problem - thanks, I've been banging my head against the wall for two weeks on that one.  However, I'm still left with two questions:

 

1) Why is the vsys required to set the zone, but not to create the interface, add a comment, vrouter, IP address, etc.?  All those worked fine without the vsys parameter.

2) If I try to assign a zone without the vsys parameter, and trigger the error as above, all the other task parameters (comment, vrouter, IP address, etc.) are effective, even though the task fails.  Doesn't that violate the Ansible philosophy that tasks should be atomic, and either succeed or be completely backed out?

Hi @plonergan, the answers lie in PAN-OS configuration schema. The other items are attributes of an interface, whist the zone is not. An interface is an attribute of a zone, which is contained inside a VSYS. We attach (import) an interface to a zone. The task to create an interface has to (under the hood) first create the interface with its IP address and other attributes, then assign that interface to the zone. Hope that helps? (FYI: I've submitted a change to the docs to cover this kind of scenario.)

Help the community: "Like" helpful comments, and click "Accept as Solution" if you found your answer 🙂

Jimmy,

 

The documentation update addresses my follow-up question #1.  What about #2, the atomicity of the task?  It seems you wouldn't want to leave the interface partially configured if the task fails.  At least, I wouldn't want to.

 

Peter

L5 Sessionator

Thanks Peter. I understand your comment, and I've raised an issue on the module repo to track improving this in future.

Help the community: "Like" helpful comments, and click "Accept as Solution" if you found your answer 🙂
  • 2 accepted solutions
  • 4106 Views
  • 6 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!