Cisco Ethernet Switches Reviews

We use this solution for our university campus network.

The most valuable feature of this solution is the stability.

The solution is simple to configure.

The layer-2 switching is very fast.

We would like to have the option of two power supplies on these switches. It is important for us because these switches are installed in our data center and critical departments. These units have to be available all of the time.

I would like to see this solution automatically store multiple versions of the configuration file. For example, Juniper switches will save forty versions of the configuration, while Cisco will only store one. If you want to keep more than one then you need to make it manually. If you need to restore it then you will have to use the saved file to do that manually, as well. In the large switches, they do keep one primary image and the backup image, which is good, but it is not like Juniper. I can roll back to any version within the last forty that have been committed. It's a very, very nice feature that I would like to see in Cisco equipment.

This is a very stable solution. You install it and then you don't have to touch it for many years.

At this level, the edge, we are not concerned with scalability. We will be able to update the edge using the new uplink port module if we need to.

The core switches are scalable. You can add another slot of forty-eight ports with 10-gigabit each. 

On the university campus, we have approximately thirty thousand users. These are not concurrent connections. We have more than twenty thousand students, about six thousand employees, and there are guests. I can say that more than twenty thousand connections may be active at one time.

We have about one thousand switches, and we have four people in charge of maintenance. They do the installation, repairs, and all of the other tasks in the data center. Three are technicians and one is a manager.

We work with our vendor, who in turns works with the Cisco support. There are times, however, when we need to get support directly from Cisco as well.

We are satisfied with both the local vendor support and support from Cisco. When we have problems, they put the effort into it until the problem is solved.

We had a problem with the structure of the switches in the core. We weren't sure what the problem was, but we were helped at every step of the process. Cisco was in contact with us every day until the problem was solved. We are very satisfied with the support.

I have experience with Juniper LAN switches, but that was with a previous company.

The university campus had bought Juniper switches about six years ago, but they are moving completely to Cisco equipment. Cisco is more expensive than Juniper by perhaps double. The price is higher because they are more stable.

We still have about one hundred Juniper switches out of our one thousand in total.

The initial setup of this solution is very simple.

You can copy the image to the switch using FTP and run a command to install it. The process is very simple and we always upgrade our switches without any problems.

This is an expensive solution, but you are paying for stability.

We evaluated Meraki switches but they were not suitable for the university campus.

We are looking forward to the 10-gigabit uplink port, which is an improvement that we have waited for. We expect to have this new module in one or two months.

Cisco has a family of Small Business Switches called SG. For example, the SG300 model. This is a cheaper model, and although they are missing some protocols, they are very good. Out of our one thousand switches, we have about one hundred SG models. The price of these is lower than Juniper switches.

I surely recommend this product, and the new Cisco line seems to be even stronger. There are improvements in terms of new modules and power supplies, and the price is not increasing.

I would rate this solution a nine out of ten.

The hardware is rugged. We use it for the basic configuration.

Cisco has a layer three rugged switch. I don't know if they have it. The one I use is layer 2 only. Cisco should provide field switches, outdoor switches that have the capability for layer 3.

We've had hardware problems like SSDS, ports, networking, things like that.

They should maximize the number of ports. For me, that's important because we have some sites that the industrial switches lack ports so we have to install two industrial switches.

Stability is okay. 

We have around 500 switches deployed in one network. 

We haven't needed to contact their technical support. 

It's easy to deploy, just copy and paste. Installing the switches and configuring it, it takes only less than an hour. Installing the fibers takes time.

My advice to someone considering this solution would be to have a  good plan and a good design. It will go smoothly if you have a good design and a good plan. It's important.

I would rate it a seven out of ten. Not a ten because Mellanox is better compared to Ethernet switches.

We primarily use the solution for infrastructure.

The solution itself is great for our organization's infrastructure. You can connect a WiFi product and an ethernet product at the same time.

The most valuable aspect of the solution is its routing features.

The solution is compatible with many brands, such as VMware.

It offers very good durability if your configuration is good.

The interface needs improvement. The solution could use more features and more functionality.

The price could be lower. It's quite expensive.

The stability of the solution is perfect, although sometimes we have firmware problems. If we have a bug or something similar, sometimes it's hard to get a quick response to the problem.

The scalability of the solution, from what I understand, is good. We haven't actually tested the solution for scalability ourselves, however.

Technical support is good. However, we need to pay if we want to have them analyze incidents. It's not in the standard package. 

The initial setup is complex. You always need to change the configuration to adapt it to your needs. On top of that, actually adapting it is quite difficult. Deployment can take anywhere from a few hours to a few days, depending on the functionality your organization requires.

We had the assistance of a distributor for implementing the solution.

The solution is very expensive.

We did evaluate other options. We evaluated for readability, stability, price, and end of life. Cisco ultimately won out.

We use various deployment models, including on-premises and cloud.

I'd rate the solution eight out of ten.

We use this solution to connect our computers.

The most valuable features of this solution are guidance, cover sheets, and access control.

The command-line interface is easy to use.

The licensing needs to be improved. You have to know upfront what kind of license you require. If you want to check quality assurance then you need to use an IP-based license. You can get that done, but sometimes it's a nuisance. For example, if you want to run certain commands then they are not all available because it depends on your license.

On the new switches, it is a bit hard to do the SPANning. The SPAN ports on the 9K series should be improved.

The stability of this solution is good.

The scalability of this solution is fine.

We have just changed partners for technical support so we are not able to rate them yet.

We did not use another solution prior to this one. We have always used Cisco.

The initial setup of this solution is straightforward.

We do part of it manually and part of it automatically. The biggest part is the installation and the connecting and cabling. The actual deployment of the CD itself can be a couple of hours.

We use a partner for technical support.

The price of this solution is good.

In general, Cisco is ok. It's convenient and well-documented. If you have a big landscape then Cisco is a good way forward. It is well supported and a lot of engineering people know the Cisco switches. It's like the default environment, and I recommend it.

I would rate this solution an eight out of ten.

We primarily use the solution on our equipment.

The VPC feature is the solution's most valuable aspect.

The quality, like all Cisco solutions, is very high. The fact that it's Cisco is one of the reasons we chose to use it.

Cisco has a licensing procedure that is very complicated and it changes every six months.

The solution is very stable.

Scaling and upgrading the solution is easy. Our group has about 500 employees and all of them use Cisco and its switches.

Technical support is okay, but they do need to respond quicker to tickets.

I have personally previously used Dell, which is very unstable in comparison to Cisco. You must review all documents and if you don't correctly do this, you must open a ticket. It takes  a few days for a simple question about the licenses to get answered. It can be a very frustrating process and should be simplified.

The initial setup is straightforward.

I handled the implementation myself.

The cost of licensing is very expensive, especially if you compare it to Fortigate.

We're using the on-premises deployment model.

I'd recommend the solution. It has all the features we need included within it.

I'd rate the solution eight out of ten.

I have been using the newest line of Cisco switches, the 9300 series, for two or three years.

We have two different models for deployment. One is the SDN deployment model, which has to do with Software-Defined Networking and is the more recent.

The other is the traditional three-tier, via core access aggregation layer five switches with an Independent Architecture Designed environment or access layer switches where you just use them to connect users to a specific service. It depends on what the nature of the work would be and the scope of work. But generally, most traditional networks have three layers. You have switches in a core of the network, switches in the distribution or aggregation layer, or switches in the access layer. This is the Three-tier module. If it is a collapsed core then it would be just simply the core and the access.

A primary use case is you could use it to connect mostly end-users and host systems. Systems could be servers, systems could be printers, systems could be telephones, and systems could be video conferencing equipment. That's one end use of it.

Another is the use in the data center. Ethernet Switches can be used in a data center out to provide connectivity, wired connectivity for servers, database systems, platforms, other platforms systems, and storage systems. With Ethernet you could have different speeds, so you can have Ethernet running at 1Gig, you can have Ethernet at 10Gig, you can have Ethernet at 40Gig, and you have Ethernet at 100Gig. So, depending on the nature of connectivity, you have that in the data center, you can have that also in an office environment. Then you go up to have it in industrial space, monitoring of industrial machines and control systems. So again, Ethernet is widely used.

There are several situations where these switches are used. Most times if they want to move off the main site, or they want to move locations, or they want to have temporary spaces, they can use a switch. Temporary means they may want to expand connectivity from their network to a small branch office that is temporary. Temporary means they're going to run something there for six months and then after that the business won't be there.

With switches, you can expand your network with a connection aside but you can extend your network to a particular area. You can also develop a campus network, campus meaning you may have one building in there and then the company acquires another building, and then it's easy to connect the two buildings together with Fiber and a switch if you have that available. 

There is also multi-tenancy, if you're in a building when you have multiple floors, it's easy to extend the premises from one floor to another floor using a switch as well.

In terms of projects, technical projects, they are several, I mean even down to connectivity to third parties inside the data center. For example, you may find out that you need to connect to BT or you need to connect to your telco provider. Switches will facilitate your ability to connect to a third party to allow communications between two separate environments that are managed differently.

I've done projects where the switches are also used for translation. For example, one part is using Fibre, the other part is using Ethernet, and the switch can be used to communicate between the two technologies. The switch will transform the physical characteristics of the link from Fiber to Ethernet.

There are two things about this solution that I find valuable. One valuable feature is that you can string a number of switches together, and the fact that there are various methods to connect them, such as by stacking. A stack means that they operate as one switch spot. You have multiple physical switches in the stack. For example, you could have one particular physical switch and you can have many of them all connected together as if they're one switch.

Another valuable feature is that the switches can operate at different layers of the networking environment. You can have switches that operate at layer three, you can have layer four switches and also obviously layer two, data layer, is their normal operation.

These switches are versatile. They can operate as a router, but they can also operate as a switch as well. The fact that you can run routing protocols on them, and you can also run data link protocols, means that they are quite versatile enough.

At the moment the switches that you have can't scale because they've got their control plane and data plane in the same device. The problem with that is you're limited to the number of switches you can string along because of limitations with VLAN. VLAN does have limitations, but with Software-Defined Networking there is no limitation. This is bringing about changes in the networking field that are long-needed. Ultimately, I would like to see all of the switches support SDN.

Switches should be made stackable, even if they are not of the same model. Now stacking is another technology that a lot of switches can benefit from, but not all switches are capable of stacking. There are some switches that are capable of stacking, but not all switches. As a rule, in my view, I feel stacking should work between different switches and at the moment it doesn't. For example, if you want to build a stack, all the switches in the stack have to be literally the same. So that another area of technology which could be different. You could stack switches, even if they're not exactly the same, but they have a way of operating such that they can work together. It would be nice because it means people don't have to throw away things just because they can't meet what they want.

I think this solution is very stable.

These switches have been around for a long time. Before that, all the technologies used couplers, which were called BNC connectors, network taps, all those things that existed. Couplers that existed before the arrival of Ethernet, they didn't last even two, three years, whereas Ethernet has been around for more than fifteen years.

Ethernet will continue to be around, and it's a very stable technology in terms of the operation. As well, Ethernet is the way forward, and it will still be around for another ten or fifteen years.

Ethernet does not scale very well because you've got distance limitations. Ethernet can only run for about one hundred meters or less, so you have to use Couplers. This distance limitation is why we use Fibre. Fibre optics is actually a better technology than Ethernet, but it's more expensive. Everything about it, the equipment, the nature of the way the Fibre cables are prepared, is a lot more expensive compared to Ethernet.

Ideally, everybody would like to run Fiber switches because it's a better technology that carries more bandwidth. The high price is due in part to the components. All the components that make Fibre work are expensive to produce. It can be relatively cheap for what we use it for but overall, it's way more expensive than Ethernet. If it wasn't for that then Fibre would have been the best solution. Ethernet, as it is right now, the cost price point for Ethernet is very good, so it won't be going anywhere fast soon. In terms of scalability, don't have limits. If you want to scale, you need to use Fiber to scale.

In terms of users, the organization right now has more than a thousand, and the previous one had approximately five thousand.

With respect to user roles, some are call center personnel, some platform systems guys, some are software developers, some project managers, some are marketing managers, some are sales managers, and some are professional services. Department-wise you have your legal, HR, and your finance department.

To my knowledge, our business is focused on doing work for clients so I expect that our usage of Ethernet Switches will be expanding.

The technical support for this solution is very good. They're very responsive.

I have also used the Meraki MX switches, but they are more like routers and used to support the wireless systems for Meraki.

With respect to the initial setup, the complexity depends on the topology. Most times they're not complicated. What's complicated is if you need to use them as a layer three switch, then you could have some complex configurations to do. However, if it's layer two, which is data layer connectivity only, then it's easy. If it's layer three then it's a little more challenging because you combine layer two and layer three and it could involve routing protocols. It's a lot more complex. 

Generally speaking, it depends on the manner in which you want to use the switch. Some deployments took maybe two weeks, some three days, some a month, and some even up to three months.

When it comes to my implementation strategy, first of all, you have to get the physical hardware into the data center or location where it needs to be. Make sure the right structured cabling was in place to connect this equipment so that it can work in that environment. Both from a power perspective and from a cabling perspective. I got to cable this switch to other systems and make sure that the right type of cabling is in place. Also, I have to make sure of the configurations that I'm going to use and get them organized upfront. In other words, I have the configurations I am going to put on a device and the software version. 

Another important thing is the software version. Make sure that the version is the appropriate one to put on there. Ensure that it doesn't have bugs or things, the type of configuration I want to put on there doesn't have bugs or anything that could impact the operation of those configurations.

After that is complete, I make sure that all of the connectors or transceivers that I've brought are the right type of transceivers for the systems. I'm able to connect them onto the network. Now that's just the physical connectivity.

There are other things you would do in implementation to test that the switch is working fine once it's operational. There are other tests that you conduct like Ping test, IP test, or whatever to show basic connectivity exists to that switch from the management perspective. You may also have tools, such as monitoring tools that you would use. You would also configure the monitoring tools to be able to recognize that particular device on the network and maybe things like memory, CPU, all the things to do with power, all these environmental conditions around that device are being monitored as well.

Then obviously you've got documentation as part of it. If you're putting a new set of equipment in there, the site probably has existing documentation that needs to be updated to reflect the fact that the typologies changed or you're introducing new equipment into that topology. In some cases, you've done this all upfront before you start the implementation. While in some cases, some companies, for the rush of time they want you to implement first and then do the documentation later. So again, it's still part of that strategy. Implementation wise, that's the approach you would go with in my opinion. Obviously there are different implementation approaches, and the stuff we're talking about here is just hardware.

I am a specialist, and in most cases, I handle the implementation and deployment.

The time I would use another person is if the data center was far away when it's not conceivable that I would travel to that location. I'd probably use somebody from the data center or use a data center engineer who would set up the hardware. He would put the hardware in the rack, the network cage, or rack where the equipment is going to be located. He would help me physically screw the equipment, take it out of the box, and connect it into the cage, and then I'd give him instructions on where to put cable or where to plug the various cables that come with the equipment. So once he's done that, I'm able to remotely connect to the device.

Those are remote working situations where you're not physically able to go to the site and do the work there. Then yes, I would work with other people sometimes and give them some instructions on what I want to have done at that location.

What is happening in the industry is that they are separating two things that traditionally held back the growth of switches, which is the control plane aspect of the switch from the data point. What you're finding is that the newer generation of switches, you can control them with a different device separately from the switch itself. In terms of the improvements, the improvements that are going on right now, Software Defined Networking creates the basis for you to have switches that can scale, and can scale very well.

I would rate this solution a nine out of ten.

We primarily use the solution for access aggregation and IP routing.

The queue functionality is the solution's most valuable feature, specifically because we are delivering a lot of Layer 2 services. Layer 2 protocol tunnels work well on Cisco switches.

The solution needs to work on lowering the amount of bugs. We find them quite regularly.

Cisco should offer different equipment. Some features which are needed at present, for example, require making ethernet loopbacks for testing purposes are not available. They need to offer something like this.

The solution isn't quite stable. We do find a lot of bugs. 

For Level 2 switching only, it's okay. 

When you look at advanced features, from time to time we have memory issues.

Some versions of the solution can scale with a stacking option. So far, we've been satisfied with the level of scalability we can achieve. We know what we can do using the right point in the network.

We're satisfied with technical support. They answer quite fast when it comes to troubleshooting on the Cisco side. 

The initial setup was straightforward and easy.

How long deployment takes depends on the configuration of standard features. It may take a few hours. It's more complex when we are using IP or VRF light functions.

You only need one person for deployment and maintenance.

We handled the implementation internally.

The equipment we bought with a perpetual license. We're not using a monthly or yearly licensing model. Any additional costs are reasonable. The hardware and software support came with additional costs.

We are using a variety of Cisco ranges, including 2900, 3600, 3700, 4900, and 7600 series.

We use the on-premises deployment model.

In terms of advice I'd give to those considering implementing the solution, I'd say that they should know what features they want to use in order to choose the right platform. There are solutions, such as Juniper, for example, that vary in performance and in features. Be sure to ask Cisco or any other vendor lots of questions in the design phase to ensure you're choosing the right solution for your company.

I'd rate the solution eight out of ten. The solution lacks some stability but it compensates by offering great features.

We use Cisco as a business switch on a small network of about 30 users. We use it for internet sharing, as centralized management for the network and active directories, as a domain controller, and for file sharing.

This product provides us with stable security and configurable VLAN management.

The most valuable part of this solution for us VLAN (Virtual Local Area Network), MAC authentication and security.

For Cisco, the interface between fiscal small business switches and the Cisco Catalyst or Enterprise switch is a little bit different. So, I needed to take some time to understand how this will impact the network if we plan to scale it in the future and to learn the different interfaces. I think it would be better for Cisco to unify the interfaces between their products. It might make it easier for users to use different models concurrently as different versions of switches and improve scalability.

It is not really a feature of the solution itself, but I also think that the technical support directly from the company should be better in the area of handling integrations.

I am very satisfied with the stability. We have not suffered any stability issues with the product being unstable on the network and it is not difficult to support. It is a very rare thing to have something happen that is related to the stability of the product.

Once you understand how the product works, it is easy to configure. I do not see any significant limitation on the scalability of the product so long as you have chosen the right product for use in your environment.

In most cases when I need to solve an issue, I search for a solution on Google and in the internet communities. I usually find what I need there. So mostly I don't need any help from support.

When I contact support, most of the time they provide good information and they are helpful, but sometimes they will not help. The problem is with acknowledging the need for integration support. If you call about integration between products, they might say something like "this is Cisco and we do not support this other product, we are supporting only Cisco products." Cisco is not the solution for everything, and they must know that the product integrates or gets integrated into a network. They are aware of that and should have the experience to help users integrate products when their product is involved. 

So, overall I'm satisfied with technical support if I call with an issue that is related only to the Cisco product, but sometimes I'm not satisfied when an issue is related to integrating or connecting with other products.

Technical support could be better in this way.

As I moved around between three or four companies to get better jobs and positions, all of them were using Cisco. In some places, we were using HP ProCurve switches. Having that experience previously is the reason why we went with Cisco for the network at this company. It costs more, yet we get a stable product with the most features. Cisco is more reliable, especially in a critical environment.

For small networks, the initial setup is straightforward. You can simply connect the product to the network and it would work. But the configuration for VLANs, to configure specific ports, and to configure security, the product has a little different interface than other Cisco solutions. So the first time setup it easy. You just have to connect and it is plug-and-play. But the difference in the interface between models makes it harder to understand the version and adapt to the differences from the other types of Cisco switches. If the interface had been the same, it would have been very quick to set up.

Actually, I did the deployment by myself. I didn't need any help or support from the vendors. If I do ever need help, I usually go to the internet and use the community and forums. In extreme cases — and very rarely — I contact the vendor directly. 

It is certainly not the least expensive product for switching, but I think it is the best and if you have the budget it is worth it.

I evaluated other options by my previous experience, so, in a way, we did evaluate other choices, but I had already made up my mind because of what I knew.

Cisco is the better solution if someone is considering it and they are willing to pay for it. The product is expensive to buy. In my current position, the budget is not a problem. If other people are in a similar situation where they can afford Cisco, I recommend Cisco. If they do not have a big budget and they need to be more budget-minded, I can recommend the HP ProCurve (now HP Networking) and D-links (Ethernet Switches) as my first choice for less expensive options.

On a scale from one to ten where one is the worst and ten is the best, I would rate Cisco ethernet switches as an eight. It is not a ten because of the differences in the interface and the quality of integration support with other products.