Adding rule for for MTU validations

[juarocha]

Related Issue(s)

Solves Issue #470

Related Collection Role

• cisco.nac_dc_vxlan.validate
• cisco.nac_dc_vxlan.dtc.create
• cisco.nac_dc_vxlan.dtc.deploy
• cisco.nac_dc_vxlan.dtc.remove
• other

Related Data Model Element

• vxlan.fabric
• vxlan.global
• vxlan.topology
• vxlan.underlay
• vxlan.overlay
• vxlan.overlay_extensions
• vxlan.policy
• vxlan.multisite
• defaults.vxlan
• other

Proposed Changes

Validation script for:

• Fabric interfaces MTU : accepted value must be an even number in the range 1550 and 9216. minimum should be 1550 due to VXLAN header (Fragmentation is not supported).
• L2 interfaces MTU: accepted values are 1500, 9216, default(1500) and jumbo(as defined on global value: ). Value must be can be either default or jumbo.
• L3 interfaces MTU: accepted value must be an even number in the range 1500 and 9216.
• Global values:
  • layer2_host_interface_mtu: accepted value must be an even number in the range 1550 and 9216 and 'default'(1500)
  • Sub interface MTU must be lower/equal than the parent interface

Test Notes

Cisco NDFC Version

12.2.3

Checklist

• Latest commit is rebased from develop with merge conflicts resolved
• New or updates to documentation has been made accordingly
• Assigned the proper reviewers

[mikewiebe]

@juarocha I spent some time testing this today and it looks good but I think we still have some work to do to map this all the way through to the module.

If I have the following interface in my data model:

          - name: Ethernet1/16
            mode: trunk
            description: "NAC_INT Trunk PO Member Interface"
            enabled: true
            mtu: 9000
            speed: 10gb
            duplex: full

Your rule will catch it and tell me to set the mtu to 9216 but the module still rejects this with the following message:

    "msg": "Invalid parameters in playbook: while processing interface Ethernet1/16, 9216 : Invalid choice [ 9216 ] provided for param [ mtu ]"

I think we might need to map this to jumbo when we generate the payload for the module

Update: Never mind. This is not an issue. I was testing in my branch that does not have your changes.