Chose Cisco 9000 Series Aggregation Services Routers (ASR 9000)
Management is more comfortable with Cisco gear due to familiarity. The old adage that "Nobody was ever fired for IBM" translates perfectly to Cisco: "Nobody was ever fired for buying Cisco." In this case, our hands were forced into making a hardware upgrade. With a big leap …
Chose Cisco 9000 Series Aggregation Services Routers (ASR 9000)
We have replaced our [Cisco] 9000 [Series Aggregation Services Routers] with NCS 5500. The [Cisco] 9000 [Series Aggregation Services Routers] was able to handle the features we needed better than the NCS. We had to move our layer 2 down to Nexus switches.
Cisco Nexus Series Switches
Verified User
Consultant
Chose Cisco Nexus Series Switches
Improved software designed for high availability, performance in Data Center
Cisco 9000 Series Aggregation Services Routers (ASR 9000)
Cisco Nexus Series Switches
Likelihood to Recommend
Cisco
It is very well suited to act as your aggregator / core switch for mid to large facilities. it is flexible enough to really be useable in small environments but costs may hinder that. It has redundancy of power and management blades that does add a lot of peace of mind and security. Really the only reason you would not use a 9000 series is frankly cost and/or real requirements for performance. They have several versions of this model, plus they have an entire set of lines that can accommodate nearly as much as the 9000. Less demand or less of a budget can weigh in the decision to select this particular model.
Fairly stable and easy to operate - but I haven't any experience with other brands, so I don't have anything to compare with. Fairly fast in the OS. Easy to upgrade - but with some SW issues. Sometimes clearing of log folders is needed. Access to bash is cool. Tips & cool tricks for operations could be nice to share.
Maintenance, upgrades, and software certification can be performed without service interruptions because of the modular nature of NX-OS and features such as In-Service Software Upgrade (ISSU) and the capability for processes to restart dynamically
FabricPath:
Enables each device to build an overall view of the topology; this is similar to other link state routing protocols. Each device in the FabricPath topology is identified by a switch-id. The Layer 2 forwarding tables are built based on reachability to each switch-id, not by the MAC address. Eliminates spanning-tree to maximize network bandwidth and flexibility in topological configurations, as well as simplify operational support and configuration. This enables a tremendous amount of flexibility on the topology because you can now build FabricPath topologies for Layer 2-based networks the same as for Layer 3-based networks
Overlay Transport Virtualization (OTV): Enables the Layer 2 extension between distributed data centers over any transport Layer 3 network
[The] upgrade process [is] overly complicated compared to NX-OS or IOS. New images and the current configuration need to be compiled into "golden IOS's". If you don't include the configuration, you will have a clean device with no configuration.
[There are] major bugs in every release. We have had to cycle through all of our routers 3 times in the last year for updates due to show-stopping bugs that did not come to light until after the changes were made in production.
[It has] terrible documentation. You have to mine their site to get to any documentation for recent versions of IOS-XR. If you make the leap from 32-bit cXR to 64-bit eXR, then the documentation is more or less non-existent. Due to the internal architecture of hardware itself, technical specs can change from software version to software version, so don't expect any sort of firm scalability numbers. You'll have to rely on your sales engineer for that.
Implementing jumbo frames on interfaces of its fabric extender series (N2k, etc.) by editing the network QoS does not have to be a global configuration that would affect all its interfaces. It can be improved to become just an interface configuration.
Licensing on the NXOS is a bit complicated and expensive. I understand that the Nexus is made for core data center switching but it does not have to break the bank.
OTV technology is for Nexus only. Based on the advantage of the technology, it should be made vendor-neutral to accommodate other vendor devices.
We will use it for a long time, since they are switches with great capacity and positive results, they promote the perfect operation of our data center, I always recommend them, because they are switches with good results.
In our environment (and especially during COVID and the Work From Home era), I would really like our network devices to be more resilient [against} errors in remote configuration. Having a standard, easy to use, configure, commit/deploy, rollback system should be installed, but it's not there. Other companies have been providing this for over 20 years, and Cisco does this on some of their devices. Why not all?
These switches are very fast. They've been designed to work within the data center. We connect them to Cisco UCS-B Mini servers with the storage being directly attached. They are able to handle the data traffic pretty easily. We can also move servers pretty fast from data center to data center without overloading them. This has allowed our company to stay running during any kind of conditional outage. We have come to really rely on them for business continuity.
In some ways, the platform is a big improvement over our previous IOS and NX-OS devices: They offer version-controlled configuration staging/commits. They have a robust portfolio of network protocols and features even beyond datacenter devices. Due to the use of NPUs instead of relying entirely on ASICs for forwarding, new versions of the software are able to improve hardware performance and capacity. Unfortunately, I have run into more bugs on IOS-XR than I ever did on IOS or even NX-OS (which has a shocking number of bugs of its own) and you have to be a licensing guru to get your order right the first time.
Overall, Cisco has great products and I believe that they believe in the philosophy of a great customer experience. Although there have been a few technical support issues that caused a lot of company anxiety, in most cases, Cisco has gone above and beyond in making a valiant effort to help the customer solve any issues.
When we are integrating the ASR9000 router with other devices then there should be the same device that can cater to the throughput. We can use the Cisco 9600 Switch which can be easily integrated and can handle the speed in terms of uplinks 40G can be handled. Adding to this Cisco DNA Center can be integrated to do the automation and monitoring purposes.
The Cisco 9000 stacks up quite well against the Cisco Catalyst 3850 switches. The additional features available in the Nexus 9000, such as VPN, FCoE, 40 gigabits, give us the ability to support the future needs of the company in our data center. The Nexus 9000 allowed us to condense our core and aggregation environment that comprised of 2 Catalyst 6504 and 2 Catalyst 6509 to a port of Nexus 9000. Although the Catalyst 3850 would be sufficient to handle routing, those features in the Nexus 9000 made it the clear choice for us.
The Nexus 3000 series switches are data center switches, so I would say they have similar security ability to other switches in this segment. I don't have a lot of experience doing more than basic ACL security on switches, but I know these can be integrated into other security solutions like Cisco ISE and 802.1x authentication. It could also be integrated into an ACI solution to add micro segmentation, which would bring in other security functions.
We didn't need to buy new devices when we were increasing backbone capacity from 1G to 10G.
Due to the modular nature of the software, when there is an issue with any running services, we need not reboot the whole device which affects all clients and availability.
