Cisco Nexus 3000 and 9000 Series NX-API REST SDK API, Release 9.3(x)

Cisco Nexus 3000 and 9000 Series NX-API REST Documentation

Configuring RPF Inteface

DME

Copy
url: {{ip}}/api/mo/sys/nbm/conf/flows.json
{
  {
    "nbmFlows": {
      "children": [
        {
          "nbmConfFlowsDom": {
            "attributes": {
              "name": "default"
            },
            "children": [ 
              {
                "nbmConfFlow": {
                  "attributes": {
                    "group": "226.1.1.1", 
                      "source": "57.1.1.1", 
                        "ingressIf": "eth1/3",
                          "status": "" 
}}}]}}]}}

Configuring NBM in PIM Passive Mode

This section describes how to configure Non-blocking Multicast (NBM) in PIM Passive mode, which ensures that the bandwidth coming into the fabric is the same as the bandwidth that is going out.

NOTE: IPFM is not supported on Nexus 3000 Series of switches.

This section contains payload examples and CLIs to demonstrate how to use the NX-API REST API to configure NBM on Cisco Nexus 9000 Series switches and to show how the REST APIs correspond to the CLI commands. For more information, see the Cisco Nexus 9000 Series NX-OS IP Fabric for Media Solution Guide, Releases 7.0(3)I4(5), 7.0(3)F2(1), and Later Releases configuration guide:

https://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-installation-and-configuration-guides-list.html/

Configuring a Flow Definition

Ingress Interface

A flow definition can be configured as Ingress Interface. The following are the methods to configure, modify, and remove an RPF Interface:

Configuring RPF Interface

Configuring RPF Inteface

CLI Commands

The CLI commands are equivalent to the payload examples displayed in the pane on the right. Click the DME tab in the top-left corner of the right pane to view the JSON payload.

Modifying RPF Interface

This interface provides the new RPF interface in the ingressIf attribute.

Modifying RPF Inteface

CLI Commands

The CLI commands are equivalent to the payload examples displayed in the pane on the right. Click the DME tab in the top-left corner of the right pane to view the JSON payload.

Attribute Definition

Group: Multicast Group Address Source: Sender of the flow ingressIf: Ingress Interface where the Multicast flow is expected to receive, that is the RPF interface

Removal of RPF Interface

Removal of RPF Inteface

CLI Commands

The CLI commands are equivalent to the payload examples displayed in the pane on the right. Click the DME tab in the top-left corner of the right pane to view the JSON payload.

Egress Interface

A flow definition can be configured as Egress Interface. The following are the methods to configure, modify, and remove an RPF Interface:

Configuring Egress Interface

Configuring Egress Inteface

Attribute Definition

Id: Egress Interface Name where the Multicast flow is expected to egress. isLhr: YES if its LHR (Last Hop Router) i.e, receiver endpoint is connected. NO for the fabric interfaces.

Add New Egress Interface

Add New Egress Inteface

Removal of Egress Interface

Removal of Egress Inteface

Policer and Bandwidth

The Policer is generally set only on First Hop Router. If a Policer is applied towards the flow, set to ENABLED. Bandwidth requirement for the flow is KBPS. This value is used if the Policer is used against the flow which also published in the Flow Telemetry Data.

The following are the methods to enable and disable the Policer, modify the bandwidth, and delete the flows:

Policer Enable

Attribute Definition

Policer: ENABLED if its FHR i.e sender endpoint is connected else DISABLE. bwKbps: Rate (kbps) at which the flow should be policed by node.

Policer Disable

Modifying Bandwidth

Delete the Flow

Establish RPF and Multiple Egress OIF in single payload

Modify RPF and Add/Delete Egress OIF in single payload

MOdify RPF and Add/Delete Egress OIF in single payload

Above single API call will change the RPF to eth1/4/1 and delete egress interfaces eth1/29/1, eth1/29/4 as well as add new egress interfaces eth1/30/2, eth1/30/3 for the above flows.

Non-Blocking Multicast Service Reflection

Multicast to Multicast Ingress NAT

The Ingress NAT allows translation of incoming (S,G) into a different source, group or both. All receivers inside the domain then can join the post translated flow. This feature is useful when multicast traffic: • enters a network from a different domain with potentially overlapping address • comes with an address that is not understood by applications in the network

The dynamic IGMP join or PIM join on a pre-translated route is not supported for ingress NAT. Multicast to Multicast Ingress NAT works only in PIM active mode. The PIM passive mode is not supported.

Multicast to Multicast Engress NAT

The Egress NAT allows translating existing flow (S,G) to different source or group address on a per outgoing interface basis. This feature is useful for multicast distribution to external entities which may only accept a certain source or group address. It can also serve as a path to hide internal address space when flows are exposed to external entities.

The dynamic IGMP join or PIM join on a post-translated route is not supported for egress NAT.

Fault MO’s are generated when there is a mismatch in bandwidth for pre-translated and post-translated flows.

In PIM-Passive mode, bandwidth management is done by an external controller for the flows and provisions both pre-translated and post-translated flows. The flow creation is made available through APIs.

Examples for ENAT PIM Passive

Setting up the Service interface loopback1

Setting up the NAT mode to Egress

Setting up the mapping interface

Setting up the SR rule

Pre-NAT flow

Multicast to Unicast NAT

Multicast to unicast NAT is used for hosting content to public cloud. The translation is required as the cloud may not support multicast. After translation, the Unicast packet gets routed as per unicast forwarding logic.

A similar use case is seen when connecting to different sites. If the core does not support multicast end to end, then the content is delivered as unicast to the different sites. The Border box translates multicast to unicast and delivers to different sites for consumption. For MU NAT, PMN will continue perform bandwidth management for pre-translated multicast flows. For the translated unicast flow, the outgoing interface will need to have unicast bandwidth reservation so that the translated unicast traffic will be sent without any disruption. PMN will also publish the Flow operational MO to indicate the NAT relationship. Since, there are three re-circulations that occur internally for every unicast translation, one must make sure that only one third of the recirculation port bandwidth is assumed. In case of any congestion on the service-reflect map interface used for re-circulation, PMN does not publish a Fault MO.

In PIM Passive mode, Controller will perform Bandwidth management and call Rest APIs to provision the pre-translated flow. PMN will publish the flow operational MO to indicate the NAT relationship.

Examples for MUNAT PIM Passive

MUNAT Rest API calls and Payload information.

1. Configure re-circ interfaces

Configure re-circ interfaces

2. Service reflect rules

Service reflect rules

3. NBM flows

NBM flows

For more information refer to Cisco Nexus 9000 Series NX-OS IP Fabric for Media Solutions Guide.