Policy: VRF-Lite

[mikewiebe]

NOTE We need to re-think how we support vrf-lite. All of the information below uses the native NDFC vrf-lite functionality. We need to discuss how we use policies directly to handle the various vrf-lite scenarios.

---

Role Entry Point: https://github.com/netascode/ansible-dc-vxlan/blob/main/roles/dtc/create/tasks/ndfc/main.yml#L35

The following describes the basics of NDFC VRF Lite Setup

Topology:

In this sample topology we are setting up VRF Lite between the switch labeled BW and external n9k

• They are connected on interfaces (Eth1/3, Eth1/4) and (Eth1/1, Eth1/2)

NDFC Setup:

Two fabrics are required

• VXLAN EVPN Fabric
• External Fabric

In this case the fabric names are as follows

VRF Lite Settings Under Resources Tab on VXLAN Fabric

Boarder Switch on VXLAN Fabric

Edge Switch on External Fabric

Link must be added for VRF Lite on External Fabric

Sample Ansible Playbook:

---
- hosts: netascode_rtpfabric
  any_errors_fatal: true
  gather_facts: no

  vars:
    # This testcase field can run any test in the tests directory for the role
    test_fabric: netascode_rtpfabric
    ansible_switch1: 10.122.84.55
    ansible_switch2: 10.122.84.63
    ansible_int1: Ethernet1/3
    ansible_int2: Ethernet1/4

- name: VRF LITE- Create, Attach and Deploy new VRF - VLAN/VRF LITE EXTENSION Provided by the User in multiple switch
  cisco.dcnm.dcnm_vrf: &conf5
    fabric: "{{ test_fabric }}"
    state: merged
    config:
    - vrf_name: ansible-vrf-int2
      vrf_id: 9008015
      vrf_template: Default_VRF_Universal
      vrf_extension_template: Default_VRF_Extension_Universal
      vlan_id: 400
      attach:
      - ip_address: "{{ ansible_switch2 }}"
        vrf_lite:
          - peer_vrf: ansible-vrf-int1 # optional
            interface: "{{ ansible_int1 }}" # mandatory
            ipv4_addr: 10.33.0.2/24 # optional
            neighbor_ipv4: 10.33.0.1 # optional
            ipv6_addr: 2010::10:34:0:7/64 # optional
            neighbor_ipv6: 2010::10:34:0:3 # optional
            dot1q: 2 # dot1q can be got from dcnm
          - peer_vrf: ansible-vrf-int1 # optional
            interface: "{{ ansible_int2 }}" # mandatory
            ipv4_addr: 20.33.0.2/24 # optional
            neighbor_ipv4: 20.33.0.1 # optional
            ipv6_addr: 3010::10:34:0:7/64 # optional
            neighbor_ipv6: 3010::10:34:0:3 # optional
            dot1q: 21 # dot1q can be got from dcnm
      - ip_address: "{{ ansible_switch3 }}"
        vrf_lite:
          - peer_vrf: ansible-vrf-int3 # optional
            interface: "{{ ansible_int3 }}" # mandatory
            ipv4_addr: 40.33.0.2/24 # optional
            neighbor_ipv4: 40.33.0.1 # optional
            ipv6_addr: 5010::10:34:0:7/64 # optional
            neighbor_ipv6: 5010::10:34:0:3 # optional
            dot1q: 4 # dot1q can be got from dcnm
      deploy: true
  register: result

NOTE:

There is currently an issue where using the dcnm_vrf module, resources are not getting released properly

Example of resource not getting released (dot1q)

To get the list of resources the following API can be called to get the list

Method: GET
https://rtp-ndfc1.cisco.com/appcenter/cisco/ndfc/api/v1/lan-fabric/rest/resource-manager/fabrics/netascode_rtpfabric

API to release the resource

Request URL: https://rtp-ndfc1.cisco.com/appcenter/cisco/ndfc/api/v1/lan-fabric/rest/resource-manager/resources?id=9805 Request Method: DELETE

This needs to be fixed in the dcnm_vrf module ideally but could also be fixed addressed by an ansible task / action plugin

[mtarking]

Closing this issue in favor of a new issue on change in implementation direction.