Myth Busting Part 2: Theoretical vs. tested?

The art of checking the box

When deploying a new cloud networking fabric, an organization has multiple ways to find the best solution. Often, an organization may issue a Request for Proposal (RFP). They’ll outline network requirements and compare proposed solutions from potential vendors.

An RFP for a next-generation cloud networking fabric requires vendors to provide answers critical to the scale and operations of the data center fabric, such as…

When responding to an RFP, the first place to search is in the product data sheet. Data sheets are a great starting point, but they don’t always tell the whole story. A data sheet usually lists theoretical hardware limits based on the switching ASIC. They often lack nuanced limitations in a real-world deployment environment. For example, network hardware has a specific amount of TCAM memory. A vendor could report the maximum number of supported routes if they used all the TCAM, but that is unrealistic. That same memory is also used for MAC address tables, ECMP tables, multicast routing tables, etc. Therefore, a functioning network device would never be able to reach the theoretical maximum values.

When responding to RFPs, vendors typically list their highest theoretical values of the product scale to be selected as the best product suited for the project. However, as mentioned above, several factors must be considered when scaling the state of a platform’s control plane (EVPN) and data plane (VXLAN). EVPN and VXLAN are separate yet integrated technologies. EVPN is the control plane responsible for exchanging information to build a network view, while VXLAN is the data plane handling the forwarding, encapsulating, decapsulating of packets.

Below is an example of what a platform needs to know and how both control plane and data plane data work together to provide the following output.

Making sense of the specs

The scale and capabilities of the platform also vary depending on the role they play in a cloud network fabric (leaf, spine, Border-Gateway, or a combination of parts on a device such as Spine/Border-Gateway/Route Reflector).

Some networking vendors require specialized hardware and position a product based on connected workload types. For example, some vendors categorize switches based on ASIC support. Some ASIC families are designed to have large tables with deep buffering, and others are presented with a “balanced” feature set. In contrast, some ASIC families are solely focused on low latency. On the one hand, this may appear as a flexible offering to choose from, while on the other, it becomes a compromise between the scale and capabilities of the hardware and software.

Whether planning a new Data Center fabric or maintaining an existing one, you need to model the data capacity requirements on the business’s needs. NetOps teams determine the upper limits based on calculations related to the fabric’s capacity, and following these limits is very important to overall availability and quality. Overloaded devices can exhibit poor performance and function improperly, leading to outages.

Why Cisco?

Customers expect complete vendor transparency when it comes to equipment performance in a production deployment.

This is where Cisco goes above and beyond the competition, being fully transparent with publicly available verified scalability guides for cloud networking infrastructure and controllers, tested in environments using unidimensional and multidimensional configurations for single and multi-site environments. Our data sheets refer to verified scalability guides for documented hardware scale and not theoretical hardware capacity values:

Behind the scenes

Cisco engineering conducts scalability tests for each platform over several software releases, understanding the CPU impact, available memory resources, and convergence of the device and system under scale. The testing also incorporates triggers to create link failures to validate convergence.

“The verified scalability values provided in this guide are not interpreted as theoretical system limits for Cisco Nexus 9000 Series hardware or Cisco NX-OS software. These limits refer to values that Cisco has validated. They can increase over time as more testing and validation is done.”

Cisco publishes verified scalability guides for the following:

Tribal Knowledge vs. Transparency

Customers see value from Cisco’s transparency and share confidence for platform scalability meeting their requirements. Customers should not have to wait for the vendor’s tribal knowledge to be transferred to determine the platform to position.

Hardware matters…but tested hardware matters more!

Richard Licon

Principle Technical Marketing, Engineering

Product Management - Competitive Insights

Data Center