The easiest way to implement this access list would be to use Ansible. We have already looked at Ansible in the last two chapters, but it is worth repeating the advantages of using Ansible in this scenario:

• Easier management: For a long access list, we are able to utilize the include statement to break the long access list into more manageable pieces. The smaller pieces can then be managed by other teams or service owners.
• Idempotency: We can schedule the playbook at a regular interval and only the necessary changes will be made.
• Each task is explicit: We can separate the construct of the entries as well as apply the access list to the proper interface.
• Reusability: In the future, if we add additional external facing interfaces, we just need to add the device to the list of devices for the access list.
• Extensible: You will notice that we can use the same playbook for constructing the access list and apply it to the right interface. We can start small and expand to separate playbooks in the future as needed.

The host file is pretty standard:

[nxosv-devices]
nx-osv-1 ansible_host=172.16.1.155 ansible_username=cisco ansible_password=cisco

We will declare the variables in the playbook for the time being:

---
- name: Configure Access List
  hosts: "nxosv-devices"
  gather_facts: false
  connection: local

  vars:
    cli:
      host: "{{ ansible_host }}"
      username: "{{ ansible_username }}"
      password: "{{ ansible_password }}"
      transport: cli

To save space, we will illustrate denying the RFC 1918 space only. Implementing the denying of RFC 3030 and our own space will be identical to the steps used for the RFP 1918 space. Note that we did not deny 10.0.0.0/8 in our playbook, because our configuration currently uses 10.0.0.0 network for addressing. Of course, we perform the single host permit first and deny 10.0.0.0/8 for completeness, but in this example, we just choose to omit it:

tasks:
  - nxos_acl:
      name: border_inbound
      seq: 20
      action: deny
      proto: tcp
      src: 172.16.0.0/12
      dest: any
      log: enable
      state: present
      provider: "{{ cli }}"
  - nxos_acl:
      name: border_inbound
      seq: 40
      action: permit
      proto: tcp
      src: any
      dest: 10.0.0.14/32
      dest_port_op: eq
      dest_port1: 22
      state: present
      log: enable
      provider: "{{ cli }}"
  - nxos_acl:
      name: border_inbound
      seq: 50
      action: permit
      proto: tcp
      src: any
      dest: 10.0.0.14/32
      dest_port_op: eq
      dest_port1: 80
      state: present
      log: enable
      provider: "{{ cli }}"
  - nxos_acl:
      name: border_inbound
      seq: 60
      action: permit
      proto: tcp
      src: any
      dest: any
      state: present
      log: enable
      established: enable
      provider: "{{ cli }}"
  - nxos_acl:
      name: border_inbound
      seq: 1000
      action: deny
      proto: ip
      src: any
      dest: any
      state: present
      log: enable
      provider: "{{ cli }}"

Notice that we are allowing the established connection sourcing from the server inside to be allowed back in. We use the final explicit deny ip any any statement as a high sequence number (1000), so we can insert any new entries later on.

We can then apply the access list to the right interface:

- name: apply ingress acl to Ethernet 2/2
  nxos_acl_interface:
    name: border_inbound
    interface: Ethernet2/2
    direction: ingress
    state: present
    provider: "{{ cli }}"

This might seem to be a lot of work for a single access list. For an experienced engineer, using Ansible to do this task will take longer than just logging into the device and configuring the access list. However, remember that this playbook can be reused many times in the future, so it will save you time in the long run.

It is in my experience that many times for a long access list, a few entries will be for one service, a few entries will be for another, and so on. The access lists tend to grow organically over time, and it becomes very hard to keep track of the origin and purpose of each entry. The fact that we can break them apart makes management of a long access list much simpler.