Guidance on Cisco ACI CNI Plugin Integration with Red Hat OpenShift – Architecture, Design, and Offi

[zafarali]

Hello Community,

I am currently working on a deployment where we need to integrate Cisco ACI with Red Hat OpenShift Container Platform (OCP) using the Cisco ACI CNI (Container Network Interface) plugin. I have been reviewing Cisco’s official documentation, specifically the “Cisco ACI CNI Plugin for Red Hat OpenShift Container Platform – Architecture and Design Guide” (Cisco link), and I am seeking clarification and guidance from the Red Hat side.

My main points and questions are:

1. Integration Architecture

   • How does Red Hat officially view the Cisco ACI CNI plugin integration compared to OpenShift’s default SDN or OVN-Kubernetes CNI?

   • Are there any Red Hat-tested reference architectures for OCP 4.x clusters running with Cisco ACI?

2. Operational Considerations

   • What are the recommended best practices from Red Hat for managing IPAM, pod networking, and external connectivity when Cisco ACI provides the underlying fabric?

   • Are there any Red Hat Knowledge Base articles or field experience documents that address EPG-level isolation, network policies, and distributed load balancers in Cisco ACI-integrated clusters?

3. Support Boundaries

   • Since Cisco provides the CNI plugin, where does Red Hat support end and Cisco support begin in case of networking or connectivity issues?

   • Is there an official Red Hat support statement (similar to the Certified Ecosystem documentation) for Cisco ACI as a supported CNI plugin?

4. Deployment Models

   • Does Red Hat provide any validation for the “nested-inside” deployment option (where OpenShift nodes are themselves running inside an ACI-integrated environment)?

   • Are there design guides or playbooks (Ansible, RHACM, etc.) that Red Hat recommends to streamline this deployment?

Goal:
I want to ensure that we design our OpenShift clusters in line with both Cisco’s recommendations and Red Hat’s supportability guidelines. If possible, I would like to reference any Red Hat official documentation, or field guides that specifically mention Cisco ACI + OpenShift integration.

Thank you in advance for your insights and any documentation pointers.

[Chetan_Tiwary_]

@zafarali You might not get an RH expert analysis and answer on this peculiar design scenario here in RHLC.

However, You can reach out RH experts here who can help you better : https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform#contact-form  

You also wont get a dedicated KB article specifically on this topic authored by Red Hat. OVN-K is the supported default and yes third party CNIs are allowed if certified :

https://catalog.redhat.com/en/software/container-stacks/detail/5ec54ea38b6f188e53644c5a 

https://access.redhat.com/articles/5436171 

Red Hat supports the OpenShift platform whereas CNI dataplane issues are the vendor’s responsibility : https://access.redhat.com/articles/third-party-software-support 

Once you plan to decide on CNI, you cannot plan a later swap to OVN-K, it’s not supported : https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html/networking/ovn-kuber... 

[zafarali]

Thanks for the clarification and the references. I’ve reviewed the KB articles and the Red Hat catalog entry, and I now understand that:

• OVN-Kubernetes is the default supported CNI.

• Cisco ACI is allowed as a certified third-party CNI, with dataplane support falling under Cisco.

• Red Hat supports the OpenShift platform, but not the CNI internals.

To ensure I stay aligned with both Red Hat and Cisco recommendations, I’d still like to check if Red Hat has:

• Any tested reference architectures or field guides for OpenShift 4.x on Cisco ACI.

• Guidance for “nested-inside” deployments (OpenShift nodes hosted on ACI-integrated environments).

• Any validated automation or playbooks (Ansible, RHACM) recommended for Cisco ACI + OpenShift.

[Chetan_Tiwary_]

@zafarali yes, it will be best to open a formal request with RH support in this case.