The following guidelines and limitations apply to host policies:

• Default host policies are configured automatically and are allowed by default.

• By default, all external receiver (PIM) and sender host policies are applied on the external links.

• Delete any custom NBM host policies before updating a default policy.

• All receiver policies are per interface for a given (S,G). Once the policy is applied on an interface for a given (S,G), it is applied to all the reporters in that subnet.

• Host policies are implemented in the software and are not applied to any physical interfaces, such as ACLs and route maps.

• An interface’s operational up and down events do not determine if a host policy is applied to the interface.

• Any valid interface with an assigned IP address has host policies that are associated with it based on the subnet IP address.

• Host policies are consulted for the senders and receivers on an interface only when the interface is in the operational up state.

• For PIM and local receiver host policies, the source or the group must be defined and should not be 0.0.0.0 (any). To allow a receiver to subscribe to all groups, use the following example:

  10 host 192.168.1.1 source 0.0.0.0 group 224.0.0.0/4 {permit | deny}
  
  

  Note	If you enter a wild card (0.0.0.0) for the host IP address for a local receiver host policy, the source IP address is also a wild card, but a valid group is required.

• If you configure sender host policies with the same host IP address and the same multicast group prefix but with a different action, the latest configuration is rejected.

  nbm host-policy
  sender
  10 host 101.1.1.3 group 229.1.1.1/32 deny
  20 host 101.1.1.3 group 229.1.1.1/32 permit ←This policy is rejected.
  
  

• If you configure external receiver (PIM) host policies with the same source IP address and the same multicast group prefix but with a different action, the latest configuration is rejected.

  nbm host-policy
  pim
  30 source 111.1.1.3 group 239.1.1.1/32 deny
  40 source 111.1.1.3 group 239.1.1.1/32 permit ←This policy is rejected.
  
  

• If you configure local receiver host policies with the same source IP address and multicast group prefix but with a different host IP address and a different action, the policy with the lowest sequence number (10) takes precedence. If you delete the policy with the lowest sequence number (10), the policy with the next lowest sequence number (20) becomes active.

  nbm host-policy
  receiver
  10 host 100.1.1.1 source 145.1.1.1 group 234.1.1.1/32 deny ←This policy takes precedence.
  20 host 100.1.1.2 source 145.1.1.1 group 234.1.1.1/32 permit
  
  

The following guidelines and limitations apply to unicast PTP:

• Configure every unicast PTP interface with a unique PTP unicast source address.

• The global PTP source and the unicast interface PTP source should not be the same.

• Unicast and multicast are not supported on the same interface.

• We recommend that you modify the default CoPP profile and increase the Committed Information Rate (CIR) of PTP from 280 kbps to 1024 kbps.

• Unicast PTP is supported only for the following platforms:

  • Cisco Nexus 9236C, 9272Q, and 92160YC-X switches

  • Cisco Nexus 93108TC-FX, 93180YC-FX, 93216TC-FX2, 93240YC-FX2, 93360YC-FX2, 9336C-FX2, 9348GC-FXP, and 9364C switches

  • Cisco Nexus 9504 and 9508 switches with -R line cards

The following guidelines and limitations apply to DCNM in general:

• Make sure that there is always connectivity to the controller by ensuring redundant paths.

• Do not use CLI commands to modify any policy that is pushed from DCNM. Make any modifications using DCNM.

• When you change any IP fabric for media-related server properties using DCNM Administration > DCNM Server > Server Properties, you must restart DCNM. For installation instructions, see the Installing Cisco DCNM for Media Controller Deployment.

• DCNM leverages the telemetry feature on the switch to stream out IP fabric for media data and uses ElasticSearch for persistence. By default, DCNM stores the historical telemetry data for up to seven days. You can adjust the data retention period using DCNM server property pmn.elasticsearch.history.days .

• When a switch is imported into DCNM, DCNM deletes all the host policies, flow policies, WAN links, ASM range, and reserved unicast bandwidth that are configured on that switch. It also resets the host policy as permit, the flow policy as 0 Kbps, and the reserved unicast bandwidth as 0%. If other switches in the same fabric already have policies and configurations that are deployed by DCNM, DCNM deploys the same set of policies and configurations (except WAN link configurations) to the newly imported switch so that the policies and configurations on all switches in the fabric are in sync.

• DCNM listens for a switch’s SNMP reload trap. When DCNM detects that a switch has been reloaded, it deletes all the host policies, flow policies, and WAN links configured on that switch. It also resets the host policy as permit, the flow policy as 0 Kbps, and the reserved unicast bandwidth as 0% and redeploys the policies and configurations that have been deployed to that switch.

• If you choose to keep the existing configurations on the switch intact during a switch import and reload, you can set DCNM server property pmn.deploy-on-import-reload.enabled to 'false' and then restart DCNM to make the change effective.

The following guidelines and limitations apply to the flow setup:

• DCNM notifies the broadcast controller or user if an API call is unsuccessful, which requires the broadcast controller or user to retry.

• Static receiver API is not supported with SVIs.

• VM snapshot is not supported. You cannot roll back to a previous DCNM snapshot.

The following guidelines and limitations apply to the flow policy:

• Make default policy changes before any flows are active on the fabric.

• Account for 5% more than the flow bit rate to accommodate a certain amount of burst without the flow being policed. For example, provision a 3G flow as 3.15 Gbps.

• Flow policies can be modified, but flows using those policies are impacted during the modification.

The following guidelines and limitations apply to the host policy:

• When a receiver host policy is applied to a host connected via a Layer 2 port and an SVI, the policy applies to all joins sent by all hosts on that VLAN and cannot be applied to a single receiver.

• Default host policies can be modified only when no custom host policies are defined. In order to modify the default policy, you have to undeploy and then delete any custom policies.

• DCNM supports a multicast range for host policies. By default, DCNM does not allow you to specify the netmask or prefix, but it automatically generates the sequence number for the host policy. If you want to specify the multicast range and manually input the sequence number for the host policy, you can set DCNM server property pmn.hostpolicy.multicast-ranges.enabled to 'true' and restart DCNM.

The following guidelines and limitations apply to network and DCNM connections:

• The DCNM HA pair must be on the same VLAN.

• Connectivity between DCNM and the switch can be done over the out-of-band management port or using in-band management.

When you configure NBM (using the nbm feature command), the system automatically creates a default NBM virtual routing and forwarding instance (VRF). You can also configure custom NBM VRFs.

NBM VRFs support multi-tenancy at the fabric level, allowing multiple customers to leverage the same IP fabric for media infrastructure simultaneously. NBM VRFs are independent of the default VRF and support all existing commands. Each VRF has its own set of policies.

You can configure your custom VRFs for either PIM active or PIM passive mode, depending on whether you want to enable active or static flow provisioning. Doing so allows the NBM fabric to form a multicast flow either with or without assistance from an external controller.

Note	You must configure all VRFs in the same mode.

See the Cisco Nexus 9000 Series NX-OS Verified Scalability Guide, Release 9.3(x) for the number of supported NBM VRFs.

You can establish a flow by creating an NBM flow definition or configuring IGMP static OIF. We recommend configuring an NBM flow definition.

To display the NBM configuration information, perform one of the following tasks.

Note	If you do not specify a VRF using the vrf vrf-name option, these commands display output for the routing context that you are in. You can set the routing context using the vrf context vrf-name command.

For sample show command output, see Sample Output for Show Commands.

To clear NBM flow statistics, perform one of the following tasks.

switch# clear nbm flows statistics
Clearing all NBM flow statistics for all VRFs ...
Done.

switch# clear nbm flows statistics vrf red
Clearing all NBM flow statistics for VRF 'red'...
Done.

switch# clear nbm flows statistics vrf all
Clearing all NBM flow statistics for all VRFs ...
Done.