Cisco ACI Reviews

The primary use case is for our data centers. It has performed quite well so far. We interconnected it with our legacy infrastructure. We are now considering moving everything into the new environment, and hoping for the best.

It improved the speed of the daily business. With the preconfigured workflows, daily business task are now done more quickly than in the past. 

Automation is its most valuable feature.

I am still not quite happy with the APIC GUI, since I am more of a CLI guy. I don't really use the GUI a lot. It would be better to introduce some wizards to guide you through the whole configuration process instead of clicking through a bunch of menus with no concrete path. It is too easy to forget one or another if you configure it this way. A wizard would be a great help.

We are still struggling with some design issues, but most of these issues will be fixed in the next release.

The stability has been good so far. We still haven't brought our entire workload into ACI. We just have particular systems running on it, but they are perfectly stable. However, there is still the question mark of what will happen when we bring all our data into the new environment, and If it can carry it.

The scalability has been great. It is very easy to scale. We are quite a big customer, so we had some scalability issues with the older, multi-part environment versions of Cisco products.

The technical support is good. Though, I am not that experience with them, as I try to resolve issues on my own.

We switched to this solution to be able to automize. We were starting to migrate our old legacy network from user campuses, backbones, and data centers into SDN technology, and automation was a requirement for the new solution that we chose.

The setup was quite straightforward. Building the Fabric with the automatic discovery process doesn't require you to do a lot compared to the old legacy networks.

We used Cisco for the deployment.

We have saved time on the provisioning and configuration.

Because of timeline issues, we were focused to use Cisco products and did not consider any other vendors.

If you are still using the finger-defined networking approach, I would recommend trying this solution.

We are happy that spanning tree feature was not included in the new design.

We want to automate some of the operational tasks of our team. We have many configurations and switches. In the future, we want to deploy a solution where we can configure all our switches in one place. This is why we are looking to use Cisco ACI in the future.

• A lot of our tasks in cloud projects are now done faster than before. 
• We can implement customer requirements more quickly. 
• Our quality has improved because we have faster visibility into when faults occurs in the network.

The valuable feature is its configuration policy. We can configure it because the policy is used for all the switches. We do not have to implement all the configuration on every switch. 

Also, it fully integrates with most of our other tools, like Infoblox or vCenter, as its very powerful.

In the new version of 4.0, the management groups for updating the software is not the best way to do it. It was better in 3.2. There was a better overview of all the management groups with integrated switches. 

It is stable. The updates for Cisco ACI have been consistent with no failures.

Scalability is another point for our cloud project. We use Cisco ACI, because when we expand the network another 10 to 20 switches more, the switches are easier to implement now. We  connect the new switches to the spine infrastructure, then they are the switches are ready to configure.

Cisco technical support has been great over the last five to six years that I have worked with them. We have two open cases with them now. All issues are solved in a timely fashion. 

We were previously using the Nexus 7000. We upgraded from the Catalyst environment to the Nexus environment. Now, we want to use ACI for automation and integration of third-party hardware.

We switched to Cisco ACI because of it improvements to our operations and integrations with third-parties.

At the beginning, the initial setup was complex because it was another way of networking. After the first installation, the second and third installation with ACI Fabric was a bit easier to configure.

To install the complete ACI Fabric with all 10 to 12 switches, it takes one to two days, then it's finished. Once you configure the application, it runs. 

We deployed it in-house.

We have seen time improvement using the product.

We did not consider any other vendors. Because in the network environment, we can only buy Cisco or Juniper. However, Juniper does not have a solution for us.

The primary use case is for the data center. 

We're just starting to deploy it. We literally just bought it and we're getting ready to start. 

The fact that it's modern and that it's easy to configure are the two most valuable features. 

In terms of improvement, I would like to see some sort of way to baseline the system in a network-centric fashion. The way ACI works is that it is very application-centric but I think that a lot of people who I have spoken to that use it don't need all that application-centric focus. Cisco says you can do a network-centric approach but I want to do network-centric in my design and then have the system organize and set itself that way. That would be cool. I would like to see that. If you as the customer want a network-centric design, after you build that initial configuration and you go into the GUI for the first time and you decide which direction you want it to go in and you point it in a certain direction, then it builds out the infrastructure to accommodate that, that would be beautiful.

They are selling the system as application-centric. I think a lot of people, ourselves included, are not ready to approach it in that way. It's too many knobs to turn. It's great overall architecture, scalability-wise, has an easy configuration, central configuration, but there are too many knobs to turn.

The early versions of the code were buggy but now, they've gotten better. The code a year ago wasn't so great. Now, it's much cleaner and more stable. 

Scalability is definitely something that we are looking at and that's one of the attractive features of ACI for us. It's one configuration interface and if you want to add more interface you just buy more gear and plug it in. It's almost a plug and play solution. We just don't know how our business is going to grow and change over time. We can buy and implement something today and they can come and say that they are doing an acquisition or some sort of growth or new business venture and we need more capacity in the data center. With ACI, if you need more capacity you can just buy more and plug them in without needing to do anything else. All of the sudden that infrastructure is there for me to use, configure, and add stuff to.

We use professional services for the design configuration. 

Our investment reason was purely due to the depreciation of the existing infrastructure. We needed to get rid of the old infrastructure and we had to make a choice. We needed to decide if we were going to use 9000 or if we were going to switch to ACI. We ended up deciding to go both ways. We're going to do some stuff with the traditional 9000 and we're going to do other stuff inside ACI and so it's going to be a hybrid.

The initial setup is pretty straightforward. Because it's a plug-and-play type of solution; you can take it out of the box, you can start just connecting wires, and then have it go from the infrastructure. Once the system is there then it becomes complicated. ACI is not simple by any stretch of the imagination, but the initial go-at-it is pretty straightforward, which is nice.

We used an integrator for the deployment. 

We're a Cisco shop so we weren't going to another avenue. We already have our partner for purchasing, all these relationships were established so it wasn't really much to choose in that regard. It was more of a design decision, 9000 or ACI. Originally, we said all ACI but then as we started really getting into the design and having deep conversations with our Cisco account team and the Advanced Services Team, they told us it makes sense to do some 9000 and leave some things as ACI. This is the route we're taking. 

I would rate this solution a seven out of ten. I would really love that network-centric philosophy of configuration to be a little bit easier to do and the learning curve is steep. Being somebody who has been working with traditional Cisco IOS this is not bad at all. This is a complete rewrite of everything that you ever thought of from the networking standpoint.

The advice I would give to someone considering this solution is that you have to look at your data center. You have to look at your infrastructure. Not only that but you also have to look at the operational and support teams that are going to support this thing because if you have people that are familiar with the traditional way of the doing Cisco and have never touched ACI, then you're going to have a huge learning curve for your operational team to ramp them up and get them educated. That's definitely a factor. 

I'm in ACI operations and the current use for Cisco ACI is to host the entire server farm and all the applications which are hosted in our data center, here in Qatar, and also in different locations.

Normally, when you're configuring your core switches and your normal switching fabric, like Nexus or any of the HP platforms, you configure VLANs. If you're dividing a switch, you configure a virtual device contact. Instead of this, you have different tenants for your different environments, different segments. And you have automation on top of it if you are running virtualization domains. It removes the traditional networking configuration and gives you complete control over your switching fabric from one controller.

Also, it has APIs. You can use REST APIs and you can have configuration already built in for your XML code or GSM files. You can push it using different tools like Postman. You can have different types of Python scripts and you can have these types of automation if you want to play with the API. It will provide faster provisioning of network and faster provisioning of your applications. 

If you go for full automation, you can build your own tools. I have my own tools that I built in Python. If I want to configure EPG or interface, I configure some parameters on my script, it will push to ACI, and it will configure it.

In terms of time saved, any new provisioning of services or new applications will take less than one minute on. I gave one IP to my system team to configure the IP on the application and tag the EPG on the application data. It was just a matter of tagging.

Among the valuable features are the integration with VMM domains and their Layer 4 and Layer 7 devices, like device packages for F5, Palo Alto, and ASA.

We are also doing automation from ACI and we have integration with Azure. With the Azure stack integration we can have total automation. We can configure the EPGs from there, and we can configure load balancing functionalities from there as well. The most useful feature is that you don't need to configure anything on ACI itself. You can configure on Azure and it will provision your application. This is the highest level of automation in Microsoft.

In the second level of integration, you create the EPGs and the gateways on ACI yourself. Then, it will be configured on a SCVMM and you tag the VLANs there. It removes the hassle of configuring code groups and VLAN tags on the VMM, the virtualization domain, on the virtualization platform. You configure within ACI, and it will be visible there. It removes the networking administrative part from the system side, and you have complete control there.

You can also have microsegmentation. You can have isolation for a certain part of the EPGs.

In addition, you have a complete fabric you can connect to and you can have a static binding all over the fabric. You don't need to configure specific VLANs or run different cables. All of switches are connected to the spine, so you have complete reachability all over the fabric. You can have multi-tenancy. You can have multiple fabric configurations for different types of connectivity. You would not have this on normal switching fabric.

Where there is room for improvement from ACI is for Layer 2 and Layer 7 packages. Normally, when you're updating your ACI fabric or you're introducing new Layer 4 to Layer 7 devices and there are some constraints, there are some limitations. You need to check before you do it, as well as F5 load balances. When you are doing device packages you will not have the functionality of ASM. It's like WAF, web application firewalls. So you need to configure it manually. There is some room for improvement here.

The rest of it, for VMM domains, is improving. Cisco is introducing new features. I don't feel that it's unstable or it needs more improvement. But, for Layer 2 and Layer 7 packages, it still needs improvement. It needs quite a bit of work. 

Currently, we are using it in our test lab for Layer 4 and Layer 7 services. We are not using it in production. We are using unmanaged Layer 4 and Layer 7 devices. We are not using complete device packages.

I'm looking forward to something called Cisco Tetration. I have never worked on it but it's there now. It will map everything: What type of ports are communicated through between users and applications and between applications. It will map that on ACI automatically, at the ACI contracts level and the application level. It's like a big-data platform. It will understand the application. It will understand the port requirements, the security requirements, and it will perform some types of automation. Right now, ACI is lacking this. There's some intelligence within it but not much.

It's a very stable product in terms of switching fabric. It's quite reliable. It doesn't fail that much compared to other switching platforms. There are some things you need to be cautious of, like when you are configuring contracts. When you are configuring L4 and L7, you need to be aware of what type of configuration you're doing. Sometimes when you are configuring something which is third-party, not Cisco, you need to be aware of what the end result will be. So you need to do it in a test environment first, and then do it in production.

In terms of scalability there is just one limitation. When you want the security rules and features to be applied on the application NIC level - on the virtual NIC level, on the network interface level, on the application itself, on the virtualization domain - you cannot do that. The application needs to reach via API so you can apply the security policy. Then the security policies will be applied and then it can talk to other applications. This is one thing that is missing on ACI. But you cannot say that it's actually missing because that's the overlay approach of SDN; it's not underlay like NSX.

Technical support is quite mature. It's not bad as before. I'm the one person who has been working with ACI for a long time. Most engineers only have experience two or three years of experience with ACI. I have experience with ACI when it started from version 1.1. I have used more or less all the OS's. In the beginning, support was quite bad, but now it has improved notably. They have good engineers for the VMM. They have separate departments for separate things.

Response time is good, but it depends. If you are getting a call from the European or the American site the support is better. But if you get a call from the Indian site or from another site, it's not that mature yet.

Currently, we don't have any other SDN solutions, but I have experience with SDN in NSX. I have certification in VCIX, VCIX-NSX, and NV - network virtualization - from VMware.

The biggest difference is that NSX is running on compute. It's running on the hypervisor level. But ACI is running as an overlay, on a switching overlay fabric. This is the major difference. In NSX you can put policies closer to the application on the NIC level, but on ACI you have a constraint that you need to reach the fabric to have security policies apply.

The last setup I did was a freelance project in Dubai for Emaar. I also did one of the biggest projects here in Qatar for our company. I did one extension project at Qatar University. I have also done some document evaluation and design evaluation for a project that didn't start because of some budget constraints. It's still not completed. They are still evaluating, but I did the design evaluation from the vendor side.

In general, the setup is a little bit complex, but it will remove future complexity. In the beginning, for newcomers, for new engineers, it's a little complex. Even for me, when I was learning it, was a little bit harder for me because it doesn't have conventional switching. It's running multiple types of OS's inside the fabric, so that can cause a little bit of confusion. But, after some time, you will feel like it's more logical.

The deployment time depends on how many leaves there are and how many fabric spine switches there are and on how many applications there are. If it's migration, it takes more time. If it's a greenfield project, it will not take that much time.

I did one deployment that was a complete greenfield project. There was nothing there. There was no migration. They are building a new data center and it was a small setup. It had six switches and two small, baby spine switches. That took less than one month.

Regarding implementation strategy there are two types of approaches. There is network-centric and there's object-oriented-centric. If it's network-centric, each VLAN has its own bridge domain. But if you have a complete application-centric approach, you have one BD for everything and you can configure multiple gateways there. You will specify contracts.

The number of staff required for a deployment depends on the fabric, the leaves and spines. Deployment generally takes two or three guys. For the configuration, I'm the only one. I can do it, no problem. But for physical stacking and connectivity, it takes a number of people. For configuration, one person is more than enough.

We have plans to increase usage. We are extending our fabric all the time because we started with 14 leaves and we now have around 24 leaves. We're also planning to implement it in our DR5. All over the Middle East, there is huge demand for ACI because Cisco is pushing this platform for core data centers.

It decreases network provisioning time and application provisioning time. It also takes fewer resources to manage it. You don't need a number of consultants to manage the ACI fabric because it's a centralized system. You will have one APIC controller which can manage more than 200 leaf switches. It depends on the APIC sizing. You can have multiple switches connected to it and you can manage it.

If you compare the licensing and total cost of ACI, it's cheaper than NSX because of the licensing fees. If you are going for full NSX features it will be too expensive, especially the next-generation firewalling feature.

If somebody is planning to implement ACI, it's mostly because they want their network to be centralized and they want their network to be more organized. They want more efficient provisioning of networking and applications. By implementing ACI they will need fewer resources and will have reduced operations costs. They will have more flexibility over the network. They can have multiple types of automation on their fabric, instead of using normal switching fabric.

In terms of maintaining it, the operation is something else. It depends on the number of applications and their business criticality. You need to check if it's a 24-hour approach where you need two or three guys to have a rotation for shifts. Currently, we don't have shifts, and I'm the only one who is managing the ACI, but we have an on-call rotation. Sometimes I'm getting called, sometimes my colleagues are getting called and they are relaying the information to me. But as I built the fabric here, I set it up so that I don't need to come in urgently. Everything is redundant, everything is connected on a dual-switch basis. If one switch fails or there's a configuration issue, there will not be downtime.

We have about 3,000 end users. It's our core. All the applications are hosted there.

I would rate the solution at nine out of ten. I have very good experience with ACI. My major platform and my focus is on security and data centers. I'm pretty good with data center technology as it is one of my major points of focus. I have experience with different products, mostly Cisco security products, but I have had a good experience with ACI.

We used it as a data center switch. The company - our client - that uses it uses Cisco HyperFlex and FlexPod both connected to Cisco ACI.

It has made it simpler and easier for non-Cisco personnel to come in and configure stuff because it is easier to understand, compared to when you configure Nexus using the CLI. Configuring the ACI using the graphical interface is easier. That's one advantage. New administrators can easily jump in and manage the system.

It saves time.

It adds a layer of complication but one area where it has an advantage, a benefit, is that you're able to reuse a specific integration. If you add another server, you can use a specific integration and assign it to another port.

You can back up the configuration, restore a configuration. It's easier compared to the traditional way of keeping a text file of the configuration. With ACI the management itself has been improved since you can manage it using the graphical user interface. 

There a lot of integrations that can be done. VMware can be integrated with ACI, that's another advantage, although we did not use it as much because the client also has its own virtualization software.

One of the things that makes it a lot more complicated is the way contracts are handled in ACI. Contracts are like their own access lists. They can improve the setting up of contracts between devices a lot. It can be simplified. Because ACI re-invented something that's been working for so long - you can now have overlapping subnet - it gets really confusing when they say that you can use the same subnet for different VLANs.

They should make a standard list of best practices and that makes it easy for the people who are going to use it. That part alone, when they tried to remove subnet and VLANs, that's an integral part of networking which people have been used to for so long. They tried to remove it. I don't know why, but when they did that, it muddled up the concepts of networking, and people need time to adjust. That's why they have to put out a best-practice's guide, to make it easier for traditional-method people to adapt to ACI. 

Another area for improvement is establishing a Layer 3 Out policy. Accessing the internet is a bit complicated where, before, using Cisco devices, it was just one line of code. With ACI, it took us a few days, almost a week, to just figure it out using the GUI.

Stability-wise, we really have not had any issues with it. It's pretty stable. That's a good thing.

It's scalable because of the spine-and-leaf infrastructure. You can add spine and leaf. I haven't scaled it that much. We've only used three or four leaves into the ACI infrastructure. But I believe the scalability is good.

Cisco's technical support seems pretty good. No complaints about the response time. When we were into the implementation phase, we had two cases and they were able to respond quickly and to resolve the cases quickly.

The setup was relatively complex. It was really not straightforward at all.

The strategy was to just browse through Cisco's web site to get the setup guide. We used the initial configuration guide and we browsed through a lot of videos from people who had done it before us.

The deployment took a few days more a month. The biggest complication was establishing the routing system, how to do routing.

There were three of us from our company involved in the deployment, but the project also involved Cisco Hyperflex and Cisco FlexPod.

I'm not really so sure of how fast our client has seen return on investment. But maybe in the past three years they have seen it.

I cannot comment on how much ROI they've had. But they've established some BPO centers, call centers, using the infrastructure. I don't know how much success they've had.

If you can afford it, it's a very good solution. It's a high-end solution to put a data center on. Also, you need the right people to use it. It would be better if you had some programmers who know Python and not only people who are network engineers. If you can afford it, it is going to be the next thing, in a few years' time. It's a good solution if you have the right people and budget.

We have an ongoing interaction with the client for whom we implemented ACI. We implemented it two years ago and since then we have been constantly supporting the client with their ACI infrastructure. The people who use it are the ones accessing their data center. There are around 200 to 300 people, across the entire organization.

Two people maintain it.

In the past few years there hasn't been much increase in usage. The client has not told us of any plans for expanding their ACI infrastructure.

I would rate ACI at seven out of ten. It adds a layer of complexity that you can really do without. I can't give it a ten when the traditional way of doing things still gets the job done, especially for people with experience with Cisco. It's much easier to configure stuff the traditional way using the CLI. For me, there's really not much of an advantage. The advantage is for people who are new to Cisco and the CLI environment. Then, going into ACI and having to configure it using the GUI is better. For me, it doesn't really give me that much of a benefit.

We use it for our data center.

It has made it much easier to deploy and make changes in the data center versus the previous infrastructure, which was NX-OS based.

• Software-defined
• Ease of deployment
• Ease of change
• Ease of segmentation
• Scalability

I know Cisco is trying to move away from CLI, but I would still like to see improvements to the CLI. Troubleshooting is quite difficult using other tools, and there are still quite a lot of people with the network engineer mindset who rely on CLIs. Therefore, it would be nice to have a unified CLI. They made big improvements on this last time, but it could use additional improvements.

Here are some of the issues that we encountered:

• We had lift switches which failed to forward traffic correctly.
• We had issues in the first deployment when we tried to finish the migration from traditional networking to Cisco ACI.
• We had issues with the propagation of the routes internally. Therefore, we had destinations which were reachable, but other destinations were unreachable in the same subnet.

It took quite a lot of tries to finish the migration, because our issues were always the same. These issues were related to silent hosts.

The stability has been decent so far. We have ran into some issues: 50 percent hardware and 50 percent software, but we solved them quite quickly.

The scalability is very good. This is one of the best features, because you can add it at any time, then scale as needed.

I would rate the technical support as an eight out of ten.

We were at the end of the lifecycle for the previous solution, which was Cisco Nexus based. We knew that we would stay with Cisco, so the proposal came up to choose between traditional and NX-OS and ACI. Therefore, we chose Nexus 9000, which allowed us to do both. Then, it came down to a decision on which solution to go with, and we thought SDN is the future. Thus, we chose SDN (ACI mode).

The setup was very straightforward. It was easy to deploy. The first configuration had issues, then adding the lift switches was easy.

When we deployed, we were partnered with defense services. We had engineers on site for the couple of tries that we did for the migration. They helped us and managed to solve our issues in the end.

Ensure you have the right qualifications to deploy and operate this solution, especially in the programming area.

Our main use case is for building data center stuff, putting in equipment and provisioning it.

It has saved me a couple of times, as just a backup feature.

It can easily do a snapshot before you do any change, and if something goes wrong, you can just rollback. It's pretty smooth, and it helps.

The UI is quite intuitive.

It is still not mature and has room to grow. As with any product out there, it requires time to develop.

We run into bugs from time to time. It is more from the perspective that we're not running the default configuration, so when we try to tweak it that is where we hit issues.

The transition period when you go from standard networking to the application centric tool can be difficult because you need to understand the new terminology, but you will get through it.

Previously, the product has had its stability issues. Now, it seems more or less okay.

In the past, there were some bugs we ran into, but those have been solved. They took some time, and we had downtime due to them. However, we have quite a good connection with Cisco tech support.

It is scalable. We have a lot of devices. Our network have tens of thousands of devices.

The technical support is good. We have a dedicated team from Cisco.

We were moving from one data center to multiple pristine data centers. We started looking into what can we do better operational-wise. We wanted to save time when we needed to implement stuff, etc., and were looking at the latest and greatest solutions.

We used a reseller for the deployment.

It depends on your vision and what you want to achieve, I would recommend going for Cisco ACI. Just make sure you have time to learn and get used to the new terminology.

We are pretty satisfied with what we have.

We use Cisco ACI within our four data centers, and it has been deployed in all four. They are the backbone within our data centers.

We have an old switches and catalysts. This product makes things easier. Once everything is on Fabric, their routes are bounced around within the Fabric, so you don't have to configure new switchboards or parts. It does makes it that much easier.

Its programmability: You can do stuff to policies to make them more flexible, allowing you to connect devices in new ways. 

I would like Cisco to simplify the interaction of the controller. 

I would also like them to simplify the way you configure the Fabric. The process is quite complex. This can be a barrier to entry. For anything, where it should take two or three steps, you have ten steps.

It took quite a bit of time to learn how to use it. The learning curve is very steep.

Since I joined, we have had about two or three outages. Sometimes the controller to the device interaction can be problematic, but otherwise, it has been quite stable.

It is very scalable and easy to add new devices on, which is very good.

It is possible because we have a contract with them, they are always available. Whenever I have had to talk to them, they are very responsive. When issues have happened, there have been about four or five issues, they were able to have them solved within a day or two.

The initial setup was complex since these are brand new data centers. The topology for the network was different in the way it was set up.

Cisco did the integration. They are still adding new things and deploying. They are doing a very good job.

You can push scripts that you are writing now to set up connections in less than five to ten minutes.

We also evaluated IBM.

With the Cisco ACI technology, the programmability enables interaction. The other solutions are not really built for programmability. They don't interact with their databases directly, where Cisco ACI makes this possible. This is one of the many reasons that our organization selected it.

It is a fantastic product, but train up first. In the first six months before you deploy, if you can get your hands on a demo and attend some classes or do some studies, get yourself to a place of being competent before you start.