此外，这种设计消除了对于地址解析协议(ARP)和broadcast flooding的需要，所以流量被默认撤销了——fabric已经知道每一个端点的位置。如果所需的是特定的应用程序，就会在桥域级别有允许ARP 和broadcast flooding的规定。

　　在一个较高的水平，这就是ACI了——其是建立和维持一个网络fabric架构的方法，省去了传统网络的概念和方法，以非常大的规模提供了重要的软件控制、自动化和线速的交换机。

　　构建fabric

　　实施ACI非常简单，甚至是在大规模的建设的情况下。最繁琐的部分是布线，但这是任何fabric结构典型的特点。在ACI环境下采用Nexus 9000系列交换机运行一款修改后的被称为iNXOS的操作系统，具备ACI管理所要求的hooks脚本功能。　　

 

　　一个具备三个APICs，四个节点，两个脊的ACI fabric架构的拓扑图。

　　一旦您的Nexus脊和叶进行了正确的连接，通过叶连接到多个脊，然后脊又彼此连接，您就可以连接和启动APIC服务器，这是建立在思科UCS 1U服务器硬件上的。如果当前的服务器是APIC集群的第一个成员，该APIC启动到一个非常简单的命令行(CLI)配置脚本，要求基本的IP子网和名称信息。

　　第一个APIC控制器开始自动发现fabric的其余部分。这种情况发生得很快，甚至是在大规模的fabric上。一旦自动发现完成，ACI的Web UI显示整个fabric的逻辑布局，以及可以配置的解决方案。与此同时，其他APIC控制器可以被启动，并通过初始安装脚本分配IP地址。然后，他们将自动加入APIC集群。

　　假设布线完成后，ACI fabric从开始到结束的整个过程可能只需要几分钟的时间。加上第三方元件如负载平衡器和防火墙，一款功能性fabric可通过Web UI或API来完成。

　　配置与管理

　　这是ACI所带来的一些真正的惊喜。ACI的每一部分都可以通过RESTful API来控制。事实上，思科ACI客户不使用CLI或Web UI管理工具，而是仅用API完全照本宣科即可。此外，思科还发布了一个完整的Python SDK，使脚本ACI直截了当。

　　这应该是非常清楚的：这不是一个扣在提供的管理工具上的API，或并排运行的解决方案。API是管理工具。CLI 与Web UI均需使用API以执行每一项任务。事实上，从CLI到ACI对于思科管理员都非常熟悉，都具备通常的IOS权限和配置模式，而其只是一个使用API 的Python脚本。

　　如果您企业参与了开源社区和现代开发社区，这似乎没什么大不了的，但对思科而言，这是一个非常重要的一步。不仅是ACI成为了非常开放的架构，同时也意味着思科正在积极通过服务客户及为其他感兴趣的ACI维护代码而做出贡献。思科的GitHub的资源库包含了大量非思科雇用的开发人员所提交的资源。思科正在积极支持各地ACI社区聚会，而该社区也已经收获了思科的开放姿态所带来的回报。这是思科迈出的一大步，并为ACI带来了一个非常正面的立场。

　　使用SDK，一个Python脚本实现一个新租户的基本功能可能只有几行代码。Python的方法是精心布置、易于理解的。此外，思科还参考APIC的Web UI内置了整个API和SDK，所以他们很容易被发现。思科公司也已经在ACI Web UI内置了非常便利的开发工具。例如，有一款对象浏览器，允许开发人员通过ACI基础设施搜索和查看任何对象的所有要素，以便在脚本中使用。　　

 

　　此示例中的Python代码将通过Python SDK在 ACI创建一个租户。该代码是通过思科维护的一个开放源码的Python脚本传递的一个JSON对象编程生成的。