Feat(eos_cli_config_gen): Add support for ingress in system.control_plane.ipv4/6_access_group #4481

Vibhu-gslab · 2024-09-17T10:25:17Z

Change Summary

Add support for ingress in system.control_plane.ipv4/6_access_group

s1-spine1(config-system-cp)#ip access-group ?
  WORD     Access list name
  ingress  Specify default CP ACL for inbound packets

s1-spine1(config-system-cp)#ipv6 access-group ?
  WORD     Access list name
  ingress  Specify default CP ACL for inbound packets

Related Issue(s)

Fixes #4467

Component(s) name

arista.avd.eos_cli_config_gen

How to test

CI

Checklist

Repository Checklist

My code has been rebased from devel before I start
I have read the CONTRIBUTING document.
My change requires a change to the documentation and documentation have been updated accordingly.
I have updated molecule CI testing accordingly. (check the box if not applicable)

github-actions · 2024-09-17T10:25:30Z

Review docs on Read the Docs

To test this pull request:

# Create virtual environment for this testing below the current directory
python -m venv test-avd-pr-4481
# Activate the virtual environment
source test-avd-pr-4481/bin/activate
# Install all requirements including PyAVD
pip install "pyavd[ansible] @ git+https://github.com/Vibhu-gslab/avd.git@ingress#subdirectory=python-avd" --force
# Point Ansible collections path to the Python virtual environment
export ANSIBLE_COLLECTIONS_PATH=$VIRTUAL_ENV/ansible_collections
# Install Ansible collection
ansible-galaxy collection install git+https://github.com/Vibhu-gslab/avd.git#/ansible_collections/arista/avd/,ingress --force
# Optional: Install AVD examples
cd test-avd-pr-4481
ansible-playbook arista.avd.install_examples

python-avd/pyavd/_eos_cli_config_gen/schema/schema_fragments/system.schema.yml

python-avd/pyavd/_eos_cli_config_gen/j2templates/eos/system.j2

python-avd/pyavd/_eos_cli_config_gen/schema/schema_fragments/system.schema.yml

…l_plane.ipv4/6_access_group

github-actions · 2024-10-17T11:43:30Z

This pull request has conflicts, please resolve those before we can evaluate the pull request.

github-actions · 2024-10-21T07:06:51Z

Conflicts have been resolved. A maintainer will review the pull request shortly.

MaheshGSLAB · 2024-10-25T12:37:08Z

python-avd/pyavd/_eos_cli_config_gen/j2templates/eos/system.j2

-{%         set cp_ipv4_access_grp = "ip access-group " ~ acl_set.acl_name %}
-{%         if acl_set.vrf is arista.avd.defined %}
-{%             set cp_ipv4_access_grp = cp_ipv4_access_grp ~ " vrf " ~ acl_set.vrf %}
+{%     for acl_set in system.control_plane.ipv4_access_groups | arista.avd.natural_sort %}


can you fix the j2 template for vrf default and none case. So if vrf is default or none then we have to render the only last command.
Like from your example
ipv4_access_groups:
- acl_name: "acl4_1"
- acl_name: "acl4_3"
vrf: default
it should render the only below config:
ip access-group acl4_3 in

We can as well optionally simply pick first IPv4 and IPv6 out of all with either "missing" VRF or those where it is set to default. EoS takes last line from overlapping commands pushed to conf or conf session because it simply overwrites previous ones. As we generate designed configuration state for the device - we should probably avoid generating commands which would be overwriting each other (although EoS would be OK with it).

MaheshGSLAB · 2024-10-25T12:38:00Z

ansible_collections/arista/avd/molecule/eos_cli_config_gen/intended/configs/system.cfg

+   ip access-group acl4_3 vrf default in
+   ip access-group ingress default acl4_4
+   ip access-group acl4_5 vrf red_3 in
+   ip access-group ingress vrf red_4 in


order is not correct

s1-leaf1(config-system-cp)#sh ac system control-plane tcp mss ceiling ipv4 1344 ipv6 1366 ip access-group ingress default acl4_4 ip access-group acl4_3 in ip access-group acl4_2 vrf red in ip access-group acl4_2 vrf red_1 in ip access-group acl4_5 vrf red_3 in ip access-group ingress vrf red_4 in ipv6 access-group ingress default acl6_4 ipv6 access-group acl6_3 in ipv6 access-group acl6_2 vrf blue in ipv6 access-group acl6_2 vrf blue_1 in ipv6 access-group ingress vrf blue_2 in s1-leaf1(config-system-cp)#

ansible_collections/arista/avd/molecule/eos_cli_config_gen/documentation/devices/system.md

alexeygorbunov · 2024-10-31T02:37:35Z

python-avd/pyavd/_eos_cli_config_gen/j2templates/eos/system.j2

-{%             set cp_ipv4_access_grp = cp_ipv4_access_grp ~ " vrf " ~ acl_set.vrf %}
+{%     for acl_set in system.control_plane.ipv4_access_groups | arista.avd.natural_sort %}
+{%         if acl_set.ingress_default is arista.avd.defined(true) %}
+{%             set cp_ipv4_access_grp = "ip access-group ingress default " ~ acl_set.acl_name %}


Right now neither schema nor J2 enforces only one default ingress ACL for IPv4 and IPv6 (although EoS will only allow one, because there can be only one implicit per ipv4/iv6).

Defining multiple ACLs as ingress_default: true renders all lines:

ipv4_access_groups: - acl_name: "acl4_4" vrf: red_2 ingress_default: true - acl_name: "acl4_6" vrf: red_5 ingress_default: true ipv6_access_groups: - acl_name: "acl6_4" ingress_default: true - acl_name: "acl6_6" ingress_default: true

ip access-group ingress default acl4_4 ip access-group ingress default acl4_6 ipv6 access-group ingress default acl6_4 ipv6 access-group ingress default acl6_6

Maybe we could at least only render first "ingress default" per address family, and treat all others as regular (per-vrf ACLs)

# Line 8 + {% set ns = namespace(ipv4_ingress_default_set=false, ipv6_ingress_default_set=false) %} # Line [29:] -{% for acl_set in system.control_plane.ipv4_access_groups | arista.avd.natural_sort %} +{% for acl_set in sorted_ipv4_access_groups | arista.avd.natural_sort %} -{% if acl_set.ingress_default is arista.avd.defined(true) %} +{% if acl_set.ingress_default is arista.avd.defined(true) and ns.ipv4_ingress_default_set is not arista.avd.defined(true) %} {% set cp_ipv4_access_grp = "ip access-group ingress default " ~ acl_set.acl_name %} +{% set ns.ipv4_ingress_default_set = true %} {% else %} {% set cp_ipv4_access_grp = "ip access-group " ~ acl_set.acl_name %} {% if acl_set.vrf is arista.avd.defined %} {% set cp_ipv4_access_grp = cp_ipv4_access_grp ~ " vrf " ~ acl_set.vrf %} {% endif %} {% set cp_ipv4_access_grp = cp_ipv4_access_grp ~ " in" %} {% endif %} {{ cp_ipv4_access_grp }} {% endfor %} {# control_plane access_groups ipv6 #} {% if system.control_plane.ipv6_access_groups is arista.avd.defined %} {% set with_vrf_non_default = system.control_plane.ipv6_access_groups | selectattr('vrf', 'arista.avd.defined') | rejectattr('vrf', 'equalto', 'default') | arista.avd.natural_sort | arista.avd.natural_sort('vrf') %} {% set without_vrf = system.control_plane.ipv6_access_groups | rejectattr('vrf', 'arista.avd.defined') | arista.avd.natural_sort %} {% set with_vrf_default = system.control_plane.ipv6_access_groups | selectattr('vrf', 'arista.avd.defined') | selectattr('vrf', 'equalto', 'default') | arista.avd.natural_sort %} {% set sorted_ipv6_access_groups = without_vrf | list + with_vrf_default | list + with_vrf_non_default | list %} {% endif %} -{% for acl_set in system.control_plane.ipv6_access_groups | arista.avd.natural_sort %} +{% for acl_set in sorted_ipv6_access_groups | arista.avd.natural_sort %} -{% if acl_set.ingress_default is arista.avd.defined(true) %} +{% if acl_set.ingress_default is arista.avd.defined(true) and ns.ipv6_ingress_default_set is not arista.avd.defined(true) %} {% set cp_ipv6_access_grp = "ipv6 access-group ingress default " ~ acl_set.acl_name %} +{% set ns.ipv6_ingress_default_set = true %} {% else %} {% set cp_ipv6_access_grp = "ipv6 access-group " ~ acl_set.acl_name %} {% if acl_set.vrf is arista.avd.defined %} {% set cp_ipv6_access_grp = cp_ipv6_access_grp ~ " vrf " ~ acl_set.vrf %} {% endif %} {% set cp_ipv6_access_grp = cp_ipv6_access_grp ~ " in" %} {% endif %} {{ cp_ipv6_access_grp }} {% endfor %}

The default here is the default VRF, so I think there are some misunderstandings about the data model and EOS CLI.

EDIT:

So there are

[no|default] ip access-group ACL_NAME [ ( VRF_VRF_KW ( VRF_VRF_DYNAMIC | VRF_VRF_DEFAULT ) ) ] in [no|default] ip access-group ingress default ACL_NAME [no|default] ipv6 access-group ACL_NAME [ ( VRF_VRF_KW ( VRF_VRF_DYNAMIC | VRF_VRF_DEFAULT ) ) ] in [no|default] ipv6 access-group ingress default ACL_NAME

We should have ipv4_access_group_ingress_default: <str> and ipv6_access_group_ingress_default: <str>.
And then keep the vrf access groups as they are Today.

alexeygorbunov · 2024-10-31T03:04:26Z

ansible_collections/arista/avd/molecule/eos_cli_config_gen/intended/configs/system.cfg

+   ip access-group acl4_3 vrf default in
+   ip access-group ingress default acl4_4
+   ip access-group acl4_5 vrf red_3 in
+   ip access-group ingress vrf red_4 in


Just to add to this comment:

EoS treats missing VRF and VRF default as the same.

ip access-group acl4_1 in ip access-group acl4_3 vrf default in

will end up in running-config as ip access-group acl4_3 in (last command overwrites previous ones)

Order seems to be the following:

tcp mss ceiling.*

ip access-group ingress default.*

ip access-group <IPv4_ACL_NAME> in # IPv4 ACL for default` VRF. Can be only one

ip access-group <IPv4_ACL_NAME> vrf <VRF_NAME> in # Sorted by VRF name

Same ordering applies to IPv6.

Example:

avd-ci-leaf2(config-s-s19)#system control-plane avd-ci-leaf2(config-s-s19-system-cp)# tcp mss ceiling ipv4 1344 ipv6 1366 avd-ci-leaf2(config-s-s19-system-cp)# ip access-group acl4_1 in avd-ci-leaf2(config-s-s19-system-cp)# ip access-group acl4_2 vrf red in avd-ci-leaf2(config-s-s19-system-cp)# ip access-group acl4_2 vrf red_1 in avd-ci-leaf2(config-s-s19-system-cp)# ip access-group acl4_3 vrf default in avd-ci-leaf2(config-s-s19-system-cp)# ip access-group ingress default acl4_4 avd-ci-leaf2(config-s-s19-system-cp)# ip access-group acl4_5 vrf red_3 in avd-ci-leaf2(config-s-s19-system-cp)# ip access-group acl4_6 vrf red_5 in avd-ci-leaf2(config-s-s19-system-cp)# ip access-group ingress vrf red_4 in avd-ci-leaf2(config-s-s19-system-cp)# ipv6 access-group acl6_1 in avd-ci-leaf2(config-s-s19-system-cp)# ipv6 access-group acl6_2 vrf blue in avd-ci-leaf2(config-s-s19-system-cp)# ipv6 access-group acl6_2 vrf blue_1 in avd-ci-leaf2(config-s-s19-system-cp)# ipv6 access-group acl6_3 vrf default in avd-ci-leaf2(config-s-s19-system-cp)# ipv6 access-group ingress default acl6_4 avd-ci-leaf2(config-s-s19-system-cp)# ipv6 access-group acl6_6 in avd-ci-leaf2(config-s-s19-system-cp)# ipv6 access-group ingress vrf blue_2 in avd-ci-leaf2(config-s-s19-system-cp)#show session-config diffs --- system:/running-config +++ session:/s19-session-config +system control-plane + tcp mss ceiling ipv4 1344 ipv6 1366 + ip access-group ingress default acl4_4 + ip access-group acl4_3 in + ip access-group acl4_2 vrf red in + ip access-group acl4_2 vrf red_1 in + ip access-group acl4_5 vrf red_3 in + ip access-group ingress vrf red_4 in + ip access-group acl4_6 vrf red_5 in + ipv6 access-group ingress default acl6_4 + ipv6 access-group acl6_6 in + ipv6 access-group acl6_2 vrf blue in + ipv6 access-group acl6_2 vrf blue_1 in + ipv6 access-group ingress vrf blue_2 in avd-ci-leaf2(config-s-s19-system-cp)#

alexeygorbunov · 2024-10-31T03:05:22Z

python-avd/pyavd/_eos_cli_config_gen/j2templates/eos/system.j2

-{%         set cp_ipv4_access_grp = "ip access-group " ~ acl_set.acl_name %}
-{%         if acl_set.vrf is arista.avd.defined %}
-{%             set cp_ipv4_access_grp = cp_ipv4_access_grp ~ " vrf " ~ acl_set.vrf %}
+{%     for acl_set in system.control_plane.ipv4_access_groups | arista.avd.natural_sort %}


We can as well optionally simply pick first IPv4 and IPv6 out of all with either "missing" VRF or those where it is set to default. EoS takes last line from overlapping commands pushed to conf or conf session because it simply overwrites previous ones. As we generate designed configuration state for the device - we should probably avoid generating commands which would be overwriting each other (although EoS would be OK with it).

github-actions · 2024-11-08T10:23:31Z

This pull request has conflicts, please resolve those before we can evaluate the pull request.

github-actions · 2024-11-08T12:05:08Z

Conflicts have been resolved. A maintainer will review the pull request shortly.

sonarcloud · 2024-11-08T12:05:45Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

ClausHolbechArista · 2024-11-11T08:25:17Z

Moving to draft since we the changes needs to be reworked to match EOS CLI. Reach out if we need to discuss.

Vibhu-gslab · 2024-11-11T14:24:59Z

Closing this PR and fixing the issue in PR: #4710

Vibhu-gslab self-assigned this Sep 17, 2024

github-actions bot added role: eos_cli_config_gen issue related to eos_cli_config_gen role state: CI Updated CI scenario have been updated in the PR state: Documentation role Updated labels Sep 17, 2024

Vibhu-gslab changed the title ~~Refactor(eos_cli_config_gen):Add support for ingress in system.control_plane.ipv4/6_access_group~~ Refactor(eos_cli_config_gen): Add support for ingress in system.control_plane.ipv4/6_access_group Sep 17, 2024

Vibhu-gslab force-pushed the ingress branch from c3a5661 to b0e17eb Compare September 17, 2024 10:26

MaheshGSLAB reviewed Sep 17, 2024

View reviewed changes

python-avd/pyavd/_eos_cli_config_gen/schema/schema_fragments/system.schema.yml Show resolved Hide resolved

python-avd/pyavd/_eos_cli_config_gen/j2templates/eos/system.j2 Outdated Show resolved Hide resolved

Vibhu-gslab force-pushed the ingress branch 2 times, most recently from ae22994 to b6f6e0f Compare September 19, 2024 04:46

Vibhu-gslab force-pushed the ingress branch from 214b9f9 to e21f86a Compare October 15, 2024 06:55

Vibhu-gslab marked this pull request as ready for review October 15, 2024 07:01

Vibhu-gslab requested review from a team as code owners October 15, 2024 07:01

laxmikantchintakindi reviewed Oct 16, 2024

View reviewed changes

python-avd/pyavd/_eos_cli_config_gen/schema/schema_fragments/system.schema.yml Outdated Show resolved Hide resolved

Vibhu-gslab force-pushed the ingress branch from e21f86a to a113c8b Compare October 16, 2024 10:54

Vibhu-gslab added 3 commits October 17, 2024 13:13

Refactor(eos_cli_config_gen):Add support for ingress in system.contro…

6d95a59

…l_plane.ipv4/6_access_group

updating description

9ed0ed1

addressing comments

3e124d8

Vibhu-gslab force-pushed the ingress branch from da512f3 to 3e124d8 Compare October 17, 2024 07:43

github-actions bot added the state: conflict PR with conflict label Oct 17, 2024

Merge branch 'devel' into ingress

3214096

github-actions bot removed the state: conflict PR with conflict label Oct 21, 2024

Vibhu-gslab added 3 commits October 22, 2024 08:26

Merge branch 'devel' into ingress

80e6eab

Merge branch 'devel' into ingress

80590c8

Merge branch 'devel' into ingress

d0d53fc

MaheshGSLAB reviewed Oct 25, 2024

View reviewed changes

Merge branch 'devel' into ingress

22a54e5

alexeygorbunov reviewed Oct 31, 2024

View reviewed changes

Vibhu-gslab added 3 commits November 4, 2024 15:10

Merge branch 'devel' into ingress

1457838

Merge branch 'devel' into ingress

53af345

Merge branch 'devel' into ingress

0a6995d

Vibhu-gslab marked this pull request as draft November 5, 2024 09:24

Vibhu-gslab and others added 2 commits November 5, 2024 17:18

Merge branch 'devel' into ingress

932b032

fixing comments

7a47340

Vibhu-gslab force-pushed the ingress branch from 2d49f86 to 7a47340 Compare November 7, 2024 08:44

Vibhu-gslab added 2 commits November 7, 2024 14:14

Merge branch 'devel' into ingress

c92077c

Merge branch 'devel' into ingress

2464b30

Vibhu-gslab marked this pull request as ready for review November 7, 2024 11:18

adding files to hosts

805308a

github-actions bot added the state: conflict PR with conflict label Nov 8, 2024

Merge branch 'devel' into ingress

161e7b2

github-actions bot removed the state: conflict PR with conflict label Nov 8, 2024

ClausHolbechArista changed the title ~~Refactor(eos_cli_config_gen): Add support for ingress in system.control_plane.ipv4/6_access_group~~ Feat(eos_cli_config_gen): Add support for ingress in system.control_plane.ipv4/6_access_group Nov 8, 2024

ClausHolbechArista marked this pull request as draft November 11, 2024 08:25

Vibhu-gslab closed this Nov 11, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat(eos_cli_config_gen): Add support for ingress in system.control_plane.ipv4/6_access_group #4481

Feat(eos_cli_config_gen): Add support for ingress in system.control_plane.ipv4/6_access_group #4481

Vibhu-gslab commented Sep 17, 2024

github-actions bot commented Sep 17, 2024

github-actions bot commented Oct 17, 2024

github-actions bot commented Oct 21, 2024

MaheshGSLAB Oct 25, 2024

alexeygorbunov Oct 31, 2024

MaheshGSLAB Oct 25, 2024

alexeygorbunov Oct 31, 2024

ClausHolbechArista Nov 11, 2024 •

edited

Loading

alexeygorbunov Oct 31, 2024

alexeygorbunov Oct 31, 2024

github-actions bot commented Nov 8, 2024

github-actions bot commented Nov 8, 2024

sonarcloud bot commented Nov 8, 2024

ClausHolbechArista commented Nov 11, 2024

Vibhu-gslab commented Nov 11, 2024

Feat(eos_cli_config_gen): Add support for ingress in system.control_plane.ipv4/6_access_group #4481

Feat(eos_cli_config_gen): Add support for ingress in system.control_plane.ipv4/6_access_group #4481

Conversation

Vibhu-gslab commented Sep 17, 2024

Change Summary

Related Issue(s)

Component(s) name

How to test

Checklist

Repository Checklist

github-actions bot commented Sep 17, 2024

github-actions bot commented Oct 17, 2024

github-actions bot commented Oct 21, 2024

MaheshGSLAB Oct 25, 2024

Choose a reason for hiding this comment

alexeygorbunov Oct 31, 2024

Choose a reason for hiding this comment

MaheshGSLAB Oct 25, 2024

Choose a reason for hiding this comment

alexeygorbunov Oct 31, 2024

Choose a reason for hiding this comment

ClausHolbechArista Nov 11, 2024 • edited Loading

Choose a reason for hiding this comment

alexeygorbunov Oct 31, 2024

Choose a reason for hiding this comment

alexeygorbunov Oct 31, 2024

Choose a reason for hiding this comment

github-actions bot commented Nov 8, 2024

github-actions bot commented Nov 8, 2024

sonarcloud bot commented Nov 8, 2024

Quality Gate passed

ClausHolbechArista commented Nov 11, 2024

Vibhu-gslab commented Nov 11, 2024

ClausHolbechArista Nov 11, 2024 •

edited

Loading