Cisco ACI Reviews

Our primary use for this solution is in our data center.

This is a modern, next-generation solution, and it is where the platform is going.

I have been told that this is an easy solution to configure, but we are just starting to deploy it, so that is to be determined.

ACI is not simple, by any stretch of the imagination.

We are not following the application-centric approach, but a network-centric approach instead. It would be nice if I could specify network-centric in my design, and the system would organize and set itself up in that way. Essentially, once you go into the GUI for the first time it would prompt you, and it would build out the infrastructure to accommodate your choice.

We have been in a lot of sessions with them and have done a lot of work with it in the lab. We've seen it grow over time. The early versions of the code were buggy and flakey, but as they have gone through newer iterations, we've seen it get better. It is at the point now where were are comfortable with it going into a production data center.

Scalability is definitely something that we're looking at, and it's one of the attractive features of ACI for us. It is easy to do.

The way ACI works is it is one configuration interface. If you want to add more then you just plug it in. I would not call it plug-and-play, but they've made it to the point where it is very close. 

This is important to us because we just don't know how our business is going to grow, and change, over time. It's a moving target for us. If we buy something today, and then there is a demand for more capacity in the data center, then we just have to buy more devices and plug them in. We don't have to do anything else. The infrastructure just becomes available for us to use. This differs considerably from the traditional Cisco, which involved a lot of command lines and configuration.

We have not really dealt with technical support, yet. We are using the Cisco professional services to help us with the design and configuration.

We were using the Cisco 9000 and we reached a point where investment was needed due to depreciation in our infrastructure. We needed to get rid of the old system, and then decide whether to stay with the Cisco 9000 or move to ACI. For us, we decided to employ a hybrid solution that uses both.

The initial setup of this solution is pretty straightforward. It is a plug-and-play type of solution where you can just take it out of the box and connect the wires.

Once this system is in place then it becomes complicated. However, the initial go at it is pretty straightforward, which is nice.

We are using Cisco professional services, as well as a VAR, to help us with the implementation. In order for us to go live, we have to make sure that our VAR is ready to support that.

It is too soon for us to realize ROI.

We're a Cisco shop, so we did not evaluate solutions from other vendors. We already have our partner for purchasing, and all of our relationships were already established. For us, it was simply a design decision between Cisco 9000 and ACI.

We are currently testing this solution in a lab, preparing for our deployment into production.

We are not ready to approach this solution in an application-centric way. It's a great overall architecture, good scalability-wise, easy to configure, and a central configuration, but there are too many knobs to turn.

We were originally going to use ACI for everything. However, after we really started looking at the design and having conversations with our Cisco advanced services team, we saw that it made sense to use a hybrid solution.

My advice for anybody interested in implementing this solution is to have a good look at your data center, your architecture, and importantly your operational and support team. If you have people who are familiar with the traditional way of doing Cisco, and have never touched ACI before, then there is a steep learning curve ahead. The operational team will have to ramp up and be educated. That was definitely a factor for us.

We have a third party operational team, and we had to challenge them. We asked if it was something that they could do, and they needed to prove it to us, first. This was done before we even went into the solution. The number one thing is that you have to be able to support it. If you have only two people installing it, then you're not going to be able to run support 24/7 for when something breaks at three in the morning.

This is a good solution, but I would really like to see the network-centric philosophy of configuration to be a little bit easier. The learning curve is steep. But, being somebody who has been traditional Cisco, iOS, and command line, I can say that this is completely different. It is a complete re-write of everything that you've ever thought of from a networking standpoint. It can simplify your life if you do it right.

I would rate this solution a seven out of ten.

I am an engineer who deploys ACI. Most of the deployments cover L2 Out and L3 Out and migrations.

Some of our cloud-based customers integrate it with UCS Director or CloudCenter and are able to automate services. ACI supports automation, like Ansible automation or HTTP automation. It adds stability for cloud-deployment use cases. Cloud-based businesses don't need to create policies. They can do so with an automation orchestration tool like UCS Director or CloudCenter. A few customers are using it this way.

Some other customers are refreshing their data centers with SDN. They have a traditional data center but they want to restructure it. Cisco customers are now going for the Cisco SDN.

The most valuable features include

• microsegmentation
• L3 Out features
• the common tenant and tenancy model.

Regarding microsegmentation, generally, in Layer 2, there are restrictions between VLANs. When you do microsegmentation, by name, by IP address, or MAC address, you can create a microsegmented EPG and you can group within an EPG. Generally, all the endpoints that are part of an EPG can talk to each other. But when you create a microsegmented EPG you are creating restrictions.

Regarding the tenancy model, when you have a host data center and multiple customers and you want to build a dedicated infrastructure for a customer, you have to physically suppress the devices and you have to think a lot about security features. But with ACI, you don't need to buy a dedicated setup for each customer. Using one setup, you can create multiple tenants, and each tenant represents one customer. There are common services that are used by all the customers, like a DNS server or any web servers. You can keep the servers on the common tenant. In that way you can use the tenancy model efficiently.

They are still working on Multi-Site and Multipod but there are many customers that are looking for these in their Features page. 

We are having challenges with these features. For Multipod we need Layer 3 devices that support multicast. Customers ask: "Why can't ACI do that? Why do we need a dedicated Layer 3 device for this?" If they go for Multi-Site there is no need for that, ACI can do it. So Cisco needs to increase the Multipod features in ACI.

For one customer we found CloudCenter doesn't support Cisco Multi-Site scenarios.

I feel the stability is very good. We have had some issues but the support we get from Cisco is always good.

In terms of scalability, you can go with the two-spine and get very good bandwidth, but if you need more than this you can increase the spine count. If you need more devices you can increase the leaf count. Scalability is there.

I have been a bit disappointed with technical support from Cisco. They will often take some time to respond. But once they start they are okay. I feel they need to improve their service.

The initial setup is very straightforward. If you have some basic knowledge you will be able to deploy ACI. Some of the guys feel that it is a little complicated but if they understood tenancy more and the object structure, they would be easily able to deploy ACI.

We can deploy everything in less than two days. The difficulty is that we are working in data centers so we need to look for downtime for the customers. If they are using automation we can deploy everything in a single day. If we are doing manual, it can take three or four days.

But in real scenarios, customers cannot always give us downtime. They tell us to wait for some time and they do migration one by one.

On my team, I am the only one who does deployment. We don't need anybody's help for migration. But we expect a few team members to be involved on the customer's side, people from the server team and the network team, because we need support from them.

Maintenance is very easy. If there are two spines and you are doing an upgrade, you can shut down one spine and do the maintenance. Once that is done you bring up the one you shut down and do the second spine, and similarly for all leaves and all APICs. There is no impact to the server base and zero downtime.

I would rate ACI at ten out of ten. I don't see any bad features in it. I always think about the positive side. I don't see any negativity on the ACI side. There are a lot of features, like automation, that reduce manual efforts that would otherwise be time-consuming.

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.

The primary use case is in an environment where the customer has a very large virtual compute and a lot of physical compute as well - in terms of the number of servers - and a big heterogeneous firewall. They want to converge their racks where they have a physical firewall and a virtual firewall. They have their metal servers and VMware or Hyper-V VMs. This is the best use case. This is where ACI fits best because it can integrate the physical and virtual environments together within a single fabric. It can give a very good overview, an "aerial view" of your whole data center within your fabric. That's the best use case.

The improvement I have seen after ACI has been implemented is that companies that wanted to implement a service lifecycle of any services, or that wanted to do automation, really improved their deployment times. Once the fabric is up, then they can start doing so. Customers usually get confused and think that if they implement ACI then everything gets automated. No. That's a mistake. With ACI, you have to buy software, an automation orchestration tool like Ansible, UCSD, or vRealize - tools to automate.

The improvement is that when companies buy an automation tool with Cisco ACI, the deployment time, their designs, are really fast. 

Another improvement is that customers say that the performance is really good with their new network.

The best part of ACI is that it can integrate with a lot of virtual environments like VMware, Hyper-V, and KVM. That's the best feature that sticks out in my mind because I have worked with customers who were looking into different solutions. The biggest selling point for them, which finalized their choice of ACI, was because it supported both Microsoft and VMware.

Better troubleshooting features would be helpful. In ACI, it can be a big mess, a real headache to troubleshoot a single issue. Cisco should work on the troubleshooting part of ACI. The troubleshooting part, and the information that ACI gives you, sometimes don't give you a proper, inside picture of what's going on within the fabric.

We had an issue where the customer was not able to sync with the NTP server and we were not able to identify the problem. The NTP was just not talking to ACI. The troubleshooting part is a bit difficult in ACI, and I feel that it should have been improved a long ago, but I don't know if they're working on it or not.

Also, they have the new designs for Multipod and Multi-Site. There are a lot of good features, like static storage connections. But I have seen some customers that faced issues with connecting the storage to the fabric.

The stability is good. Initially, it was not that good, but now it's really good with the new code.

I would give the solution's scalability an eight out of ten. The scalability options are really good. You just connect the leaves to the spine and it comes up. The scalability is not an issue.

The biggest environment I've worked with has two spines, spines with 16 leaves.

In terms of the number of users on it, initially it was really difficult for customers to adopt the new technology because it was a wholly new concept. Now, with time, and as ACI comes out with the new features, and the stability is really strong, the adoption is really good. According to Cisco engineers, they have customers who have gone up to 6,000 users.

Regarding the possibility of our customers' increasing their usage of ACI, we don't see that much indication of it, because what the customers are looking is more along the lines of having their fabric be more redundant. One of the features engineers are looking for is the Endpoint Tracker, which has had some issues. It is not that user-friendly.

I love their tech support. I would rate it at eight out of ten. It's really good with ACI. Even non-ACI support is really good. If you open a P1 case, an engineer comes online within ten to 15 minutes and starts doing the debugging and troubleshooting with you. 

I had an issue with their HyperFlex solution where the issue was more an interior design issue, and not a Cisco issue, but the tech came onto the call in 10 minutes and worked with me for six hours, non-stop, to fix the issue. They do it really slowly because they don't want to impact production. Otherwise, they could probably have done it in 15 to 20 minutes.

The initial setup is really straightforward. Very easy.

In terms of implementation strategy, Cisco has a concept called the Zero Touch installation, where you just connect the fabric and it actually starts discovering its own fabric. The implementation strategy is to install ACI in a silo'ed environment first, set all the policies there, and then connect your existing network parallel to ACI so that the network has a redundant connection to ACI. Then you gradually move your network connections from the legacy to ACI. This is how Cisco recommends an implementation be done.

It usually doesn't take more than a week for all that, max. We usually do it with two people, and we do it very smoothly. Usually, when you bring the fabric up, you have to make a lot of policies, including software profiles and the like. That is time-consuming work, but once it's done you can just recall them again and again in the customer's environment. That's the only thing that we need two people for. After that, when you're done, a single engineer can get migrate the network to ACI.

Maintenance of ACI is really easy, to decommission a leaf switch or a spine switch. When you decommission a switch from your existing ACI fabric, it's straightforward. In general one engineer is required for maintenance with a second engineer as a backup. Maintenance is really easy with ACI. Even if you're upgrading your fabric to new software, it's straightforward because they have built-in connections within the fabric. There is zero downtime. We have done it many times with zero downtime in a production environment.

One of our customers is a petroleum development company in the Middle East. They have seen very good ROI by implementing ACI. Their compute was relatively very new and their network was relatively very old. They saw very good ROI by having a very good, stable fabric that gives them very good response time on the network side.

The second part is that they wanted to implement a cloud solution which would support their existing Hyper-V and Microsoft. That was where the customer saw a good ROI on the investment. They were very happy with Cisco ACI.

I'm not involved in the pricing part, but Cisco has come up with Smart Licensing, which is a bit higher. But now they're giving the customers very good discount rates to bring customers in.

We are using VMware NSX in our environment as well. We had a customer that was using both NSX and ACI in their environment.

The good thing about NSX is that it has really strong support for the virtualized environment. And now the security is an integral part of their network solution, with the Distributed Firewall and the Edge Firewall. But it has some of its own issues because in a virtual environment, when you have big data centers where there is a lot of traffic coming in from the routing site, it's usually not up to that mark. Cisco has better visibility into that. If I compare it with ACI, ACI has a very strong routing component, but it has its own shortcomings.

In terms of rating NSX, I'm going to be biased because I work in ACI. I like NSX as well, it is a great product. It has a lot of flexibility because you can use existing servers and install NSX on them and It works pretty well. I rate NSX at six out of ten. The reason I rate it a little bit less than ACI is because its only native, strong support is for VMware. ACI has native support for Hyper-V and VMware.

Plan. Don't jump to a conclusion, plan it. You should first know your infrastructure and what your targets are, what you are trying to implement because, when you are more security focused, Cisco ACI can give you a tough in implementation. If you are more into converging your fabric, you want to your data center to be very converged into a single fabric with fast convergence times, go for ACI. There are different use cases based on what the customer's priorities are. So plan well, know your target, what you're trying to achieve. If you want to deploy more VMs faster, go for NSX. Don't go for ACI for that.

As a Cisco partner, our company does training and implementations on Cisco's behalf for different customers. Sometimes Cisco needs some advanced services to help the customer to do the implementation. Sometimes the customer has a problem with the ACI service. It's a new technology so some customers are really confused with the new terms and the new deployment style of ACI. They cannot compare it with their legacy solution, and when they start comparing it they get confused. We help with how the migration should be done from the legacy to ACI.

I would rate Cisco ACI at seven out of ten. The good thing about ACI is its integration with the different hypervisors. It supports VMware, Hyper-V, and KVM. When a customer is looking into a heterogeneous environment where ACI is involved and the other part is VMware for their NSX SDN, VMware has now come up with its own heterogeneous system, NSX-V. They realized very late that they had a problem, that they could only integrate with the VMware environment. Where Cisco ACI had an edge over them was that they could integrate with the virtual environment of Hyper-V, VMware, and KVM very well. And ACI automation also helps deploy and do the integration very easily in the virtual compute part of the network.

Also with ACI, the performance of switches is really good - it's actually a hardware-based SDN - and the delays are very small. The performance is really good with ACI.

But ACI has its own shortcomings such as not having very strong native support for security. Customers always have to look into third-party security solutions to implement good security within their software-defined data centers. If you compare it with NSX, NSX comes with the Distributed Firewall and the Edge Firewall. It has its own native security. This is where ACI lacks a lot because you have to implement contracts and filters. It's a very tricky part. You have to be very careful when implementing the contracts. If you make a little mistake, it can cause a good amount troubleshooting time to debug the issue. That's the missing part.

My primary use case is for server deployment automation.

There is no need to configure all the switches, you can configure them from the device controller.

In day-to-day activity, it creates an installer for a particular VLAN to be implemented. 

Also, I don't need to monitor everything, login to every switch. I can monitor them centrally.

There are many features which are useful, like the automatic completion of the VXLAN. We don't need to configure any part of the VXLAN, which is tedious to do.

They should improve the GUI, make it simpler. They also need to improve its integration with other automation tools.

In terms of additional features, I would recommend of PTP support, which they have yet to come out with.

Right now it's stable. We haven't had to create any support issues. When doing the implementation, support was quite useful where, if somebody made a wrong connection to some other part of the network, the wrong port, they were able to track it and solve it. But in day-to-day operations, we haven't had any issues.

The scalability is very good, based on the spine-leaf structure. You can increase the number of leaves and you can also scale the spines. You can deploy four spines, eight spines.

There have not been that many hard, critical issues. There were some minor issues which were handled by technical support efficiently, but there have been no critical issues up until now.

We did not have a previous solution. We had a traditional network.

One of the reasons we looked at ACI was that the traditional network was going end-of-support. At that time we had to decide whether to go with the traditional approach or to go with SDN, which is the future, where we can do automation. 

ACI also has many benefits that network guys can make use of. We could not get that type of visibility: where the VMs are connected and which switches are connected. We didn't have that visibility. Now we can have that visibility into the virtual part as well. Also, if you want to trace a packet, there is a feature that helps troubleshoot.

The visibility helps us identify if the server is connected to the wrong feed or wrong LAN. We can immediately try to identify what the issue is, or if packets are being dropped.

For new users it has particularly new concepts, so people have to digest the implementation part and the regular use, the day-to-day operations. But once you're familiar with it, once the concepts are clear, it's quite easy to go on with day-to-day operations.

Laying the fabric-building and the policy for usage, with four spines and three controllers, can be done within a day. But the mapping and other operations take about a week, to complete the entire fabric with the proper testing and implementation.

In terms of implementation strategy, we have done two deployments. In the first, we had time to study what they were using, what VLANs, what the other requirements were. Migrating from legacy to ACI takes time. The main challenge is configuring ACI applications for visibility. It takes time to learn the traffic and then map the policies to ACI.

Day-to-day for maintenance, we have one or two people who work together in shifts, they're able to manage things.

For one of the setups we used Cisco support, which was very helpful. They have a good core team which provided us support. Cisco's team had three people on the ground. Our team consisted of two or three people for the implementation.

We evaluated VMware NSX. When we compared the technical solution of ACI and NSX, how the traffic flows from physical to virtual and virtual to physical, there were many parameters which we compared, some of which were critical.

Know exactly what you are looking for and what workloads there are. If your company has workloads based on virtualization of VMware, you should know how many physical machines there are and how many virtual machines there are. Also, you need an idea of the kind of costs you can pay for deploying the infrastructure. Look into the support, the documentation, how it would work for troubleshooting. All those things matter. Also, look at the company's relationships with the OEMs, what kind of partnership they have, what kind of support the OEMs can provide.

We have two locations where people use Cisco ACI. One has about eight to ten people for support, and the other location has seven to eight people. All are network support staff.

Once an implementation is done, it's regular day-to-day operations. If anything new comes up, new VLANs, we'll handle it. There are things in our pipeline where we are planning to have ACI deployed in our remaining data centers.

We're planning to use it as a product to sell to our customers. We are in the business of service integration. We offer solutions for our customers. We have specific customers who have a use for ACI because of the microsegmentation. They have five regional offices which all have five different people who are responsible for managing their site so we are trying to unite them and put everything under one roof and have a single place of control and visibility of the full network specifically for their data center.

Now, our customers have tiers of management that have meetings with about the simplest tasks because it has to be approved from upper management and senior management and by the time it gets to the engineer that's going to deploy it, it takes way too long. With the solution, they can delegate a person who would be in charge of running the ACI as a whole, and it will be much faster because it doesn't have to go through the whole chain of command for the simple task of deploying one little machine on one port in the data center.

It eases our deployment. Now, we use service requests when there's a project and we have to deploy it. So when the networking team gets a service request it'll be two clicks, anyone can do it. It will be less of a job, and it will be easier and faster. The main benefit is the simplicity of the deployment. On the flipside, it's also a drawback because if only one person does it and if he does something wrong, the whole system can stop working. If ten people are doing ten different things and one person messes up, it's only one error and it's easier to isolate the problem and fix it. A customer is going to deploy something on their own and more often than not, they don't have the knowledge and experience to understand what can go wrong, so they might accidentally clog the network.

If I was a customer who is using the ACI to run my network, I would like for there to be more information about it available. While using the ACI in the graphical interface, I would like if there was something that explained every step that you can click and it will tell you what you are doing in more detail. For me, I understand what's happening because I did a course, but the problem will be when our customers, who are not so versatile in this, start using it and won't know what's going on. If it works it's fine, but when they run into problems, then it's gonna be an issue. If everything works, it should be fine but if any issues come up, a lot of Cisco services will be needed.

The scalability is impressive. I think the best thing about that is the vendor-agnostic part. In the lab, we did a VMware deployment from what I heard it doesn't matter how the VM is deployed, it can integrate with ACI and you can manage it from the Epic controller.

In the lab environment, we had a setup rebuilt, it was their virtual environment. It was a small deployment. Four switches in total, two leaf and two spine switches, and three controllers. From my past experiences with those types of deployments, the setup shouldn't be an issue. The natural connectivity between them and six switches should be easy. From the controller itself, the deployment of the overlay is pretty straightforward and simple.

I would rate it an eight out of ten. 

I would advise a colleague to definitely try it. Mess around with it, test it as much as possible because it's a new solution. It's different from the traditional data center deployment so there's not a lot of internet posts about it in which you could go and Google and find out more information. The chances that someone has had your problem before and probably found a solution for it are slim so you might get stuck and you will have to go straight to Cisco.

Our primary use case is to interconnect both data centers in my corporation.

The biggest benefit has been that it has improved communication between my endpoints in the data center.

I would like to see better training. I don't have good training with this product. If I did, I probably would be able to solve all of the problems during the installations. 

It's very stable. 

Their technical support is fantastic. Whenever I have a problem, our partners at Cisco support answer quickly.

The initial setup was complex. If I didn't have my partner's support, I probably couldn't deploy Cisco ACI in my data center.

We implemented through a partner. I trust our partner, and I trust any of their recommendations and their deployments.

I would rate this solution a five out of ten. Not a ten because I don't have good training for this solution. I am now implementing Cisco ACI in the company. It's not 100% on the network. It's on 25% approx, more or less.

We started working with a customer which is in the Netherlands. They are really important for us. They started migrating the building of their CRM to ACI. We started with 2.0. We just upgraded the fabric to 3.2. In the next three months, we are aiming to migrate and upgrade the fabric plan to 4.0

Our customer has around 1,000 virtual machines and before, they were all 100 physical servers which, on our side, were obviously consuming energy and resources. Now everything is on the customer and so it's up to them to manage the size of the virtual machines. 

The straightforward migration of all of the applications and loop balancing are the two most valuable features. Also, the measurement of their customer-wide sources is very straightforward. It's another dimension of the networks.

The virtualization area needs improvement but I expect that to happen with the 4.0 version.

I would like for them to develop integration with AWS. 

Scalability is pretty good. 

Their technical support is top notch. 

We had reached the capacity in the data center. We could build a new data center or buy a new solution so we migrated to a new solution to save space. 

The setup was complex because we have a complex internet architecture. It wasn't because of the product. It was complex because of internal issues on our side. 

We had Cisco support but everything was done internally. 

We only looked at Cisco because we have all of our routing and switching infrastructure with Cisco. 

I would rate it an eight out of ten. There's room for improvement in the software version. To get to a ten, they should improve the virtualization and develop integration with AWS. 

For companies starting from scratch, ACI is the best solution in terms of the space needed and time to delivery.