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

Add additional Parameters for Service-Policy and CDP/LLDP status to Cisco.ios.Interfaces. #771

Open
nspitzer opened this issue Mar 3, 2023 · 1 comment · May be fixed by #1050 or #778
Open

Add additional Parameters for Service-Policy and CDP/LLDP status to Cisco.ios.Interfaces. #771

nspitzer opened this issue Mar 3, 2023 · 1 comment · May be fixed by #1050 or #778
Labels
feature This issue/PR relates to a feature request. interfaces interfaces resource module

Comments

@nspitzer
Copy link

nspitzer commented Mar 3, 2023

SUMMARY

Add additional Parameters for Service-Policy to Cisco.ios.Interfaces.

ISSUE TYPE
  • Feature Idea
COMPONENT NAME

Cisco.ios.interfaces

ADDITIONAL INFORMATION

Requested Parameters:

  • Service Policy name
  • Service policy direction

Example config snippets used in production:

interface GigabitEthernet0/0/0
   service-policy output SHAPE_20M

An example workflow would be:

  • Determine all interfaces with Service Policy X applied - store as variable
  • Remove Service policy X from all interfaces
  • Update Service Policy X configuration
  • Apply Service Policy X to all interfaces from Step 1

Equivalent Interface IOS commands:

Interface GigabitEthernet0/0/0
 no service-policy output SHAPE_20M

Interface GigabitEthernet0/0/0
 service-policy output SHAPE_20M


@bentole
Copy link
Contributor

bentole commented Mar 11, 2023

Hi @nspitzer!

There's a plethora of parameters that would be nice to have in modules. In the process of wishing for this we often forget, me included, that Ansible is quite capable of handling rather complex operations using tasks. I believe the general rule is that tasks is to be preferred over adding parameters to modules, as long as using tasks is possible.

For instance your example workflow can be accomplished using the following tasks with the before and after parameters of ios_config. This is important to ensure idempotency.

  tasks:
    - name: Collect Interfaces with Pmap SHAPE_2M
      cisco.ios.ios_command:
        commands:
          - "show policy-map interface |
          incl ^ [A-Za-z]|Service-policy output: SHAPE_2M"
      register: pmap_intfs

    - name: Create List of Interfaces with Pmap SHAPE_2M
      set_fact:
        intfs: "{{ pmap_intfs.stdout[0] |
        regex_findall('(\\S+)\\s\n') }}"

    - name: Check Pmap SHAPE_2M
      block:
        - name: Validate and Update if Necessary
          cisco.ios.ios_config:
            before: |
              no policy-map SHAPE_2M
              {% for intf in intfs %}
               interface {{ intf }}
               no service-policy output SHAPE_2M
              {% endfor %}
            after: "{{ lookup('template', 'qos_apply.j2') }}"
            replace: block
            match: exact
            lines:
              - " class test"
              - "  bandwidth remaining percent 10"
              - " class class-default"
              - "  shape average 2000000"
              - "  fair-queue"
              - "  random-detect"
            parents:
              - policy-map SHAPE_2M
      rescue:
        - name: Reapply Pmap Upon Failure
          cisco.ios.ios_config:
            src: qos_apply.j2

Note the rescue block which is used to reapply the policies to interfaces in case the Check Pmap task fails.
I have delibaretly used the inline way and lookup to execute the j2 templates in the before and after just to illustrate
the different possibilities.

The qos_apply.j2 template file looks pretty much like the inline template just
"reversed" like this:

{% for intf in intfs %}
interface {{ intf }}
  service-policy output SHAPE_2M
{% endfor %}

Btw, I believe the service-policy is automatically removed from interfaces when issuing no policy-map SHAPE_2M, so the iteration in before is probably not necessary. However, I don't know how consistent that is across platforms and software versions so it's best to have it there just in case :)

Cheers!

@bentole bentole linked a pull request Mar 14, 2023 that will close this issue
@KB-perByte KB-perByte added feature This issue/PR relates to a feature request. interfaces interfaces resource module labels Jun 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature This issue/PR relates to a feature request. interfaces interfaces resource module
Projects
None yet
3 participants