Nexus Dashboard Orchestrator Schemas and Application Templates for ACI Fabrics, Release 4.4.1

In the main pane, select Create Object > VRF.

Alternatively, you can scroll down to the VRFs area and click Create VRF.

In the properties pane, provide the Display Name for the VRF.

(Optional) Provide a Description.

Specify Policy Control Enforcement Preference.

Note that you cannot change the Policy Control Enforcement for newly created VRFs and the setting is locked to the enforced mode.

However, you can use this to transition any VRF that you import from an APIC fabric that is configured as unenforced to the enforced mode after importing it. A typical use case is for brown field deployments where existing VRFs must be converted to enforced mode to support stretching them between fabrics. Once you have transitioned an imported VRF from unenforced to enforced in NDO, you will not be able to make further changes to this field.

(Optional) Enable IP Data-Plane Learning.

Defines if IP addresses are learned through data-plane packets for the VRF.

When disabled, IP addresses are not learned from the data-plane packets. Local and remote MAC addresses are still learned, but local IP addresses are not learned from data packets.

Regardless of whether this parameter is enabled or disabled, local IP addresses can still be learned from ARP, GARP, and ND.

(Optional) Enable L3 Multicast for the VRF.

For additional information, see Layer 3 Multicast.

(Optional) Enable vzAny for the VRF.

For additional information, see vzAny Contracts.

(Optional) Enable Preferred Group for the VRF.

For additional information, see EPG Preferred Groups Overview and Limitations.

(Optional) Enable BD Enforcement Status for the VRF.

By default, servers from an EPG of a given bridge domain can ping the SVI (subnet) of another bridge domain. If you wish to constrain a host to be able to ping only the SVI of the bridge domain to which it belongs, you can enable this BD Enforcement Status option configuration on the VRF. This blocks ICMP, TCP, and UDP traffic to the subnet IP address of bridge domains that are different from the one to which the server belongs.

In the main pane, select +Create Object > Bridge Domain.

Alternatively, you can scroll down to the Bridge Domains area and click Create Bridge Domain.

In the properties pane, provide the Display Name for the bridge domain.

(Optional) Provide a Description.

From the Virtual Routing & Forwarding drop-down, select the VRF for this BD.

(Optional) Enable L2 Stretch.

(Optional) Enable Inter-Fabric BUM Traffic Allow.

This option becomes available if you enabled L2 Stretch.

(Optional) Enable Optimized WAN Bandwidth.

This option becomes available if you enabled L2 Stretch.

(Optional) Enable Unicast Routing.

If this setting is enabled and a subnet address is configured, the fabric provides the default gateway function and routes the traffic. Enabling unicast routing also instructs the mapping database to learn the endpoint IP-to-VTEP mapping for this bridge domain. The IP learning is not dependent upon having a subnet that is configured under the bridge domain.

(Optional) Enable L3 Multicast for the BD.

For additional information about Layer 3 multicast, see Layer 3 Multicast.

(Optional) Choose L2 Unknown Unicast mode.

By default, unicast traffic is flooded to all Layer two-ports. If enabled, unicast traffic flooding is blocked at a specific port, only permitting egress traffic with MAC addresses that are known to exist on the port. The method can be Flood or Hardware Proxy.

When the BD has L2 Unknown Unicast set to Flood, if an endpoint is deleted the system deletes it from both the local leaf switches and the remote leaf switches where the BD is deployed, by selecting Clear Remote MAC Entries. Without this feature, the remote leaf switch continues to have this endpoint learned until the timer expires.

Modifying the L2 Unknown Unicast setting causes traffic to bounce (go down and up) on interfaces to devices attached to EPGs associated with this bridge domain.

(Optional) Choose Unknown Multicast Flooding mode.

This is applicable for IPv4 unknown multicast traffic and is the node forwarding parameter for Layer 3 unknown multicast destinations.

(Optional) Choose IPv6 Unknown Multicast Flooding mode.

This is applicable for IPv6 unknown multicast traffic and is the node forwarding parameter for Layer 3 unknown multicast destinations.

(Optional) Choose Multi-Destination Flooding mode.

The multiple destination forwarding method for Layer 2 multicast and broadcast traffic.

(Optional) Enable ARP Flooding.

Enables ARP flooding, so that the Layer 2 broadcast domain maps IP addresses to the MAC addresses. If flooding is disabled, unicast routing will be performed on the target IP address.

Enables ARP flooding, so that ARP request will be flooded inside the Layer 2 broadcast domain. If the BD is stretched across fabrics, enabling ARP flooding is only possible with enabling Inter-Fabric BUM Traffic Allow. When ARP flooding is disabled, the leaf switch receiving the ARP request from a locally connected endpoint forwards it directly to the remote leaf switch where the target endpoint of the ARP request is connected (if the IP for the remote endpoint is known in the endpoint table) or to the spines (if the IP for the remote endpoint is not known in the endpoint table).

If you set the L2 Unknown Unicast mode to Flood, the ARP Flooding cannot be disabled. If the L2 Unknown Unicast mode is set to Hardware Proxy, ARP flooding can be enabled or disabled.

(Optional) Provide Virtual MAC Address.

The BD virtual MAC address and the subnet virtual IP address must be the same for all ACI fabrics for that bridge domain. Multiple bridge domains can be configured to communicate across connected ACI fabrics. The virtual MAC address and the virtual IP address can be shared across bridge domains.

Virtual MAC along with virtual IP subnet should used only for migration of individual fabrics to NDO-managed multi-fabric fabric. When the migration is completed, these flags can be disabled.

Click +Add Subnet.

An Add New Subnet window opens.

Enter the subnet’s Gateway IP address and a Description for the subnet that you want to add.

If necessary, enable Treat as virtual IP address option.

This option along with the Virtual MAC Address on the BD can be used for migration scenarios from individual Common Pervasive Gateway configuration to NDO-managed Multi-Fabric deployments.

Select the Scope for the subnet.

The network visibility of the subnet.

(Optional) Enable Shared Between VRFs.

Shared between VRFs-The subnet can be shared with and exported to multiple contexts (VRFs) in the same tenant or across tenants as part of a shared service. An example of a shared service is a routed connection to an EPG present in another context (VRF) in a different tenant. This enables traffic to pass in both directions across contexts (VRFs). An EPG that provides a shared service must have its subnet that is configured under that EPG (not under a bridge domain), and its scope must be set to advertised externally, and shared between VRFs.

Shared subnets must be unique across the contexts (VRF) involved in the communication. When a subnet under an EPG provides a Layer 3 external network shared service, such a subnet must be globally unique within the entire ACI fabric.

Leave the No Default SVI Gateway option unchecked.

Enabling this option means that only the proxy route (subnet route to spine proxy) is programmed on the leaf switches and no SVI is created, which means SVI cannot be used as the gateway.

We recommend that SVI is created by the BD subnet as the gateway and the No Default SVI Gateway option is enabled on the EPG instead because EPG subnets should only be used for route leaking.

(Optional) Enable Querier option.

Enables IGMP Snooping on the subnet

(Optional) Enable Primary option to designate the subnet as primary.

There can be one primary IPv4 subnet and one primary IPv6 subnet.

Click Save.

In the main pane, select +Create Object > Application Profile.

Alternatively, you can scroll down to the Application Profile area and click Create Application Profile.

In the right pane, provide the Display Name for the application profile.

You can create application profiles with the same name in different templates without any conflicts. You cannot however create other objects (such as VRFs, BDs, EPGs) with the same name in different templates if they will be deployed to the same fabric and tenant.

(Optional) Provide a Description.

In the main pane, select +Create ObjectEPG, then select the application profile where you want to create the EPG.

Alternatively, you can scroll down to the specific Application Profile area and click Create EPG.

In the right pane, provide the Display Name for the EPG.

(Optional) Provide a Description.

Click Add Contract.

On the Add Contract dialog, enter the contract name and type.

Click SAVE.

In the Intra-EPG Contract area, click Add Contract.

On the Add Contract dialog, enter the contract name and type.

Click SAVE.

On the Add Subnet dialog, enter the Gateway IP address and a description for the subnet you plan to add.

In the Scope field select either Private to VRF or Advertised Externally.

Click the check box for Shared Between VRFs if appropriate.

Click the check box for No Default SVI Gateway if appropriate.

Click OK.

Check the uSeg EPG check box.

Click +uSeg Attribute.

Provide the Name and Type for the uSeg attribute.

Based on the attribute type you have selected, provide the attribute details.

For example, if you have selected MAC for the attribute type, provide the MAC address to identify an endpoint in this EPG.

Click SAVE.

In the main pane, select +Create Object > Filter.

Alternatively, you can scroll down to the Filters area, mouse over the tile, and click Add Filter.

In the right pane, provide the Display Name for the filter.

(Optional) Provide a Description.

In the right pane, click + Add Entry.

The filter entry is a combination of network traffic classification properties. You can specify one or more options as described in the following step.

Provide the Name for the filter.

Choose the Ether Type.

For example, ip.

Choose the IP Protocol.

For example, icmp.

Choose the Destination Port Range From and Destination Port Range To.

The start and end of the destination ports range. You can define a single port by specifying the same value in both fields or you can define a range of ports from 0 to 65535. You can also choose to specify one of the server types instead of specific port numbers, for example http.

Enable Match only fragments option.

When enabled, the rule applies to any IP fragment with an offset that is greater than 0 (all IP fragments except the first). When disabled, the rule will not apply to IP fragments with an offset greater than 0 because TCP/UDP port information can only be checked in initial fragments.

Enable Stateful option.

When this option is enabled, any traffic coming from the provider back to the consumer will always have to have the ACK bit set in the packet or else the packets will be dropped.

Specify ARP flag (Address Resolution Protocol).

The ARP Flag is used when creating a specific filter for ARP and allows you to specify ARP request or ARP reply.

Choose the Source Port Range From and Source Port Range To.

The start and end of the source ports range. You can define a single port by specifying the same value in both fields or you can define a range of ports from 0 to 65535. You can also choose to specify one of the server types instead of specific port numbers, for example http.

Specify TCP session rules.

TCP session rules are used when creating a filter for TCP traffic and allow you to configure stateful ACL behavior.

Click Ok to save the filter.

Repeat this step to create any additional filter entries for this filter.

You can create and assign multiple filter entries for each filter.

In the main pane, select +Create Object > Contract.

Alternatively, you can scroll down to the Contract area, mouse over the tile, and click Add Contract.

In the right pane, provide the Display Name for the contract.

(Optional) Provide a Description.

(Optional) Add one or more Annotations.

This allows you to add arbitrary key:value pairs of metadata to an object as annotations (tagAnnotation). Annotations are provided for any custom purposes that you may require, such as descriptions, markers for personal scripting or API calls, or flags for monitoring tools or orchestration applications such as your Cisco Nexus Dashboard Orchestrator. Because APIC ignores these annotations and merely stores them with other object data, there are no format or content restrictions that are imposed by APIC.

Select the appropriate Scope for the contract.

Contract scope limits the contract’s accessibility; the contract will not be applied to any consumer EPG outside the scope of the provider EPG:

Toggle the Apply both directions knob if you want the same filter to apply for both consumer-to-provider and provider-to-consumer directions.

If you enable this option, you must provide the filters only when and they apply for traffic in both directions. If you leave this option disabled, you must provide two sets of filter chains, one for each direction.

If you create and deploy a contract with Apply both directions enabled, you cannot simply disable the option and redeploy for the change to apply. To disable this option on an already deployed contract, you must delete the contract, deploy the template, then re-create the contract with the option that is disabled to correctly change the setting in your fabrics.

(Optional) From the Service Graph drop-down, select a service graph for this contract.

(Optional) From the QoS Level drop-down, select a value for this contract.

This value specifies the ACI QoS Level that will be assigned to the traffic using this contract. For more information, see QoS Preservation Across IPN.

If you leave this at Unspecified, the default QoS Level 3 is applied to the traffic.

In the main pane for template, select a contract. In the right pane, scroll down to the Filter Chain area and click + Add Filter to add a filter to the contract.

In the Add Filter Chain window that opens, select the filter that you added in previous step from the Name drop-down list.

Select the Action for the filter.

When adding filters, you can choose whether to permit or deny traffic that matches the filter criteria. For deny filters, you can set the priority of the filter to one of four levels: default, low, medium, or high; the permit filters always have the default priority. For more information on ACI contracts and filters, see Cisco ACI Contract Guide.

Click Ok to add the filter to the contract.

If you disabled the Apply both directions option on the contract, repeat this step for the other filter chain.

(Optional) You can create and assign multiple Filters to each Contract.

If you want to create extra filter for the same contract: