Cisco Ethernet Switches Reviews

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.

We primarily use this solution to connect networks and devices.

What I like most about this product is redundancy like Spanning Tree Protocol (STP) or resilience protocol so the datacenter continues to function when there is some level of failure.

What I would improve in this product is simulation. You can simulate switches, but you cannot really simulate industrial Cisco switches. The ability to use industrial switches is missing and I would like to see compatibility with industrial switches.

I would like to see an updated feature search toolkit. The ability to look for certain features and select the features that you want or need would help to target desired results and workflow. To know what a tool is able to provide for you and the devices that can be used with those features would make research and configuration a lot easier.

This product is stable. I have seen no bugs, glitches, or crashes. It is absolutely dependable and was designed to be that way.

I think this product is extremely scalable. I am fairly sure everyone in the world who's working with a computer is using it. Even you — whomever you are, and whether you know it or not.

I have had the opportunity to use Cisco's support for this product. If I were to rate them on a scale of one to ten with ten being the best (and separately from the product itself), I would give them a six. On some days they take and answer a question easily and they are a ten, and other days they take too long to answer or give the wrong solution. More times they are better, so that makes them a six.

Previously we used solutions from HP, MicroTech, and Dell. You name a popular product and we have some familiarity with it. We chose Cisco because we believe it is the best option.

The initial setup of this product is straightforward.

The deployment time will depend entirely on the size of the project and the plan for what needs to be accomplished.

The pricing varies widely depending on the support contract term and the type and number of the devices. The product is on the expensive side.

We evaluated other options through our past experiences.

Advice that I would give companies considering this solution is that you need to do your research, find the correct model for your needs and size the deployment correctly. If you don't think first you can pay too much and have more than you need or pay too little and not meet your needs.

On a scale from one to ten where one is the worst and ten is the best, I would rate this product as an eight. It cannot be higher than that because of the pricing.

The primary use case is for LAN networking.

This solution is also used for internet routing in small businesses.

The deployment model we used was on-premises.

Lower the pricing to compete with Aruba and HPE.

If they could provide a management solution for all systems then it would be an improvement. They have a product, but it's a license, and I have to pay for it. 

It is difficult to manage one hundred switches in many areas, without having a managing board.

I would like a management product to manage both the small business and the Catalyst.

In my business, I have all of these products and I have to configure them one by one, so the troubleshooting and the monitoring of each can be challenging.

Also with a managing board, it would improve the scalability as it would be easier to handle the traffic and monitoring several users.

This may be something that they are already working on, but it would be an improvement if they could add a layer of security to layer two and layer three to protect the server and to protect the data.

This solution is stable.

This solution is scalable. If I want to add switches to the existing one, I can easily do it. 

The technical support is good and they respond quickly. I haven't had any problems.

The initial setup is not difficult, it's easy.

The pricing is reasonable, and for small business it is acceptable.

Aruba and HPE are competitors that have a lower price than Cisco.

I would rate this solution a nine out ten.

The primary use case of this solution is for connectivity of local network LAN switching.

The deployment model is on-premises.

The most valuable feature is the complete functionality, but the most important thing is support.

Pricing could be lower.

It is difficult to look for additional features to be added because there a lot of different switches, different models, and usually each model is designed according to the number of ports. It's a satisfactory unit within the usage area for that model.

Cisco solutions are usually very, very stable.

This solution is scalable.

It depends on the customer, regarding the number of users. Recently we were awarded a contract for the Turkish military, and there will be several thousand people who will be using it.

Support is the most important. If something goes wrong then Cisco's support is outstanding.

I initially started with Cisco, only afterward, I started using a different solution.

The initial setup is straightforward.

The deployment time varies on the specific project. For example, if the project requires fewer switches it can take thirty minutes, while other projects could require one hundred and fifty switches that would take a week or ten days. 

We require four to five engineers for deployment and maintenance.

Cisco knows what they are doing and their support is great.

I would highly recommend this solution.

I would rate this solution a ten out of ten.

Our clients use this solution for monitoring and configuration purposes.

The deployment model varies from client to client.

The dashboard needs some minor improvements. Sometimes it is difficult to find items, other times it is quick, it just depends. Most of the feedback we receive are not complaints but suggestions or ideas about the dashboard.

The stability could be improved.

We have some glitches once in a while. There are times where it's a little bit slow or a bit delayed.

We have not had to scale yet, we are normally working with a fixed size. We haven't had to worry about upsizing or downsizing.

For our purposes, we are not using this, but on the client-side, we have anywhere from two to eight users, they are made up of technicians, support staff, and engineers.

For me, the initial setup was easy and straightforward, but for some of our customers who are not as familiar with networking, it can be complicated.

For a technical person, it is straightforward. Of course, now and then you have to look in the manual and read it, as nothing is completely self intuitive.

Deployment can take anywhere from one to five days, depending on the requirements.

We require two employees for deployments.

We implement this solution ourselves.

There is no favorite function or feature, it depends on what you have to do and how you do it.

My advice regarding this solution is to understand your network, definitely have a look in the manual, understand the structure and don't just rely on trial and error. It's not target-aiming, so trial and error will not work.

I would rate this solution a seven out of ten.