Quick automation wins with Cisco DNA Center

With the investment into today’s modern and agile networks, many IT organizations are searching for intelligent tools that can help simplify the complexity that comes with the advanced capabilities of today’s networks and keep up with the business demands. Topping off the complex challenges, many organizations are facing challenges on how to bridge the growing IT skill gap and automate various aspects of their network management.

In a recent Gartner article regarding the State of Network Automation, according to the article:

◉ 41% of network activities are less than 10% automated.

◉ 31% of network activities are 11% to 25% automated.

Essentially 72% of network activities are less than 25% automated. Separately, Gartner has also identified 4 IT personas (AIOps, NetOps, SecOps, and DevOps), stating that NetOps2.0 is the evolution of network operations towards automation.

Attributes of NetOps 2.0 include an Automation-first approach, embedded analytics, SecOps integrations, and Turn-key DevOps tools.  IT organizations that embrace this approach can achieve increased IT agility, Proactive network operations, and an increased level of collaboration between common silos in IT organizations. An additional outcome is minimized friction between the NetOps, SecOps, and DevOps personas.

When it comes to automation products, the Inventor’s paradox states, “It is easier to solve a more general problem that covers the specifics of the sought-after solution”.  Organizations who transitioning to AIOps, NetOps2.0, and automation platforms, are faced with common challenges and limitations such as:

◉ Automation products are often not bi-directional with network equipment

◉ Third-party products lack Cisco’s deep understanding of the network and platforms

◉ Lack of tight integration between the hardware and software platforms

◉ Lack of cross-domain visibility between the campus, data center, and the cloud

◉ Reliance on legacy SNMP protocol which provides limited visibility and control

◉ Limited AI capabilities due to lack of data quality and domain specialization

Out-of-the-box automation with Cisco DNA Center

While there are various barriers to network automation, there are some pragmatic methods by iterating on non-change and/or non-production automation activities, leading to some “quick automation wins.” Below are some “quick automation wins” examples available out of the box with Cisco DNA Center automation.

◉ Network Device Configuration Backup and archival of all network devices.

◉ Integration with ServiceNow, which automats auto-population of trouble tickets.

◉ Automated creation of network availability baselines and compliance reporting.

◉ Automated creation of user experience baselines and reporting.

◉ Maintenance mode to enable/disable monitoring during change windows.

◉ Automated network performance testing with MRE (Machine Reasoning Engine) and features such as Truetrace and path trace to automate and expedite troubleshooting.

◉ Automated packet capture for network anomalies.

◉ Redundant Link Monitoring.

◉ RMA Automation workflows.

◉ Automated creation of application health and reporting.

◉ Software Upgrade Cycle

Granular Automation Control

In looking at Cisco DNA Center’s automation suite, Cisco DNA Center not only provides automation features but also provides the granular control to enable workflows and actions from manual to AI-assisted to selectively autonomous change management. Let’s look at the three modalities of automation possible with Cisco DNA Center:

Manual (clickOps) is where many organizations are today; all administrative actions are performed by or initiated by an operator. Numerous automated workflows need manual initiation, but they still automate numerous repetitive steps such as SWIM for software updates. Additionally, some of these can be automated through templates and EEM (Embedded Event Manager) triggers.

Figure 1. Cisco DNA Center (SWIM) Software Image Management Cycle

AI-Assisted is where leveraging the depth of knowledge, streaming telemetry, and Cisco’s vast knowledge and experience in running networks; Cisco DNA Center can identify issues and use the MRE to suggest troubleshooting steps and possible remediation. MRE is a network automation engine that uses AI (artificial intelligence) and ML (machine learning) to automate complex network operation workflows. This feature encapsulates human knowledge and expertise into a fully automated inference engine to help you perform complex root cause analysis, detects issues and vulnerabilities, and either manually or automatically perform corrective actions.

Figure 2. Cisco DNA Center Compliance automation with configuration drift

Autonomous Change Management (ACM) provides for Cisco DNA Center to be enabled to perform and enforce automated actions on the network under predefined conditions and events. As today’s networks grow at incredible rates with new demands, manually managing all aspects of the network is no longer feasible for humans. Nor do most organizations have staff watching alerts every second of the day. The integration of AI/ML into the automation engine enables Cisco DNA Center to regularly tune the network based on predictions and models, which can greatly optimize the user experience and network performance.  Compare human intervention as the ax vs. AI-driven automation doing it with a scalpel.  This can be the difference between a system taking proactive measures vs. correcting an issue after it occurred.

Doing a left shift and taking automation to the next level, depending on the intents and architecture of the network, there are several highly automated deployment models, such as the Software-Defined Access (SDA), User Defined Networking (UDN), and AI-RRM, which are highly ACM deployments within the Cisco DNA Center solutions suite.

Focusing on automation outcomes and benefits

Focusing on outcomes, as organizations embark on network automation, there are various success metrics and business outcomes that can be tracked, such as:

Tangible Metrics	Intangibles
Faster moves adds and changes Consistent Configuration Quicker MTTR Reduction in network issues Improved security posture	Team Agility Ability to scale at speed Bridging the IT skill gap

Source: cisco.com

Continue reading

Cisco DevNet Associate DEVASC 200-901 Exam: Resources You Can Use to Prepare

Earning Cisco Certified DevNet Associate certification confirms your skills in developing and managing applications created on Cisco platforms. To obtain Cisco DevNet Associate certification, you pass one DEVASC 200-901 exam that includes the basics of software development and design for Cisco platforms.

Cisco 200-901 DEVASC is a 120-minute exam. This is the only exam you need to pass to earn the DevNet Associate, and the exam is available in English and Japanese. You should also know that you will have to make an account on the Pearson VUE platform to register for it and pay $300 as an exam fee.

Cisco DEVASC 200-901 Exam: Resources You Can Use to Prepare

Official Training Course

This is one of the most useful exam preparation options. Cisco official training course “Developing Applications and Automating Workflows using Cisco Platforms (DEVASC)” takes five days. You can interact with other exam-takers and the instructor in the Instructor-led training course, and this suggests that you can get explanations from the instructor and get an immediate response. This course is recommended for anyone who wants to pass the DEVASC 200-901 exam and become an in-demand professional.

Online Videos

There are plenty of videos available online for the Cisco DevNet Associate certification exam preparation. These videos incorporate thorough explanations of exam topics. But make sure you check the content before relying on them.

Cisco DEVASC 200-901 Practice Exam

Practice tests are of great help handy when one is preparing for a Cisco exam. Practice tests help you identify your strengths and weaknesses. Practice tests simulate Cisco 200-901 exam questions that familiarize you with the core exam topics. This can also boost your confidence. Nwexam is a leading provider of Cisco practice exams.

Also Read: How to Pass Cisco 200-901 DEVASC Exam Practice Test

Books and Study Guide

Books and study guides are essential because they provide essential information that other study resources may not provide. You can buy relevant study guides and books on the Cisco press store or from amazon.

Tip to Pass Cisco DevNet Associate DEVASC 200-901 Exam

Have the Right Study Resources

It will be of no benefit if you learn from the wrong study resources. Authentic and updated study resources like an online training course, study guides, and practice tests will enable you to achieve crucial exam skills and real-life mastery. But, it should be accessed from trusted platforms.

Familiarize Yourself with Cisco DEVASC 200-901 Exam Content

Before beginning your exam preparation, make sure that you have an idea of what the exam evaluates, the skills needed, and the exam objectives in detail. This will help you carry out your preparation in an organized way.

Practical Experience

Having practical experience will allow you to soak up important concepts in your exam prep. The Cisco DevNet Associate exam objectives need to be done practically to get real-life skills.

Do Active Revision

It is not always assured that you will memorize everything you have been learning, and revising is the perfect way to soak up what you have learned. A great tip for doing a quick revision is to take short notes while studying.

Effectively Manage your Time

The exam is 120 minutes long, and you are expected to answer 90-110 questions within this time. Time management is crucial to passing Cisco DEVASC 200-901 exam. Most exam-takers fail, not because they have not learned appropriately but because of poor time management. In your exam, take as little time as possible when answering Cisco 200-901 exam questions. Answer the easy questions first; only then come to the tough ones. That will save you time.

Don’t be Afraid of Failure

Fear is the greatest enemy of applicants. Fear of failing makes you nervous and anxious. Your wish to pass the exam should be driven by enthusiasm instead of fear. During your Cisco DevNet Associate DEVASC 200-901 exam, try to stay calm and believe in yourself. If you do not crack the exam on the first attempt, take it as a challenge to make you study harder and qualify to be the best.

Conclusion

It is amazing to strive to get a flying score in Cisco 200-901 certification exam, but don’t ignore that the score you receive decides what you will achieve. Moreover, keep in mind that this is not just about passing the exam; it’s also about acquiring the best professional skills and knowledge you will require to thrive in your career. So, give your preparation the dedication it deserves and make sure you become a sought-after professional by passing the Cisco DEVASC exam.

Continue reading

Showcasing Cisco’s Commitment to Openness: VXLAN BGP EVPN with OpenConfig

The world of data center networks is evolving at an ever-increasing pace. Businesses are being faced with the growing complexity of scaling data center fabrics, while also ensuring the isolation and security of customer data. Fundamental to this isolation of customer traffic is network virtualization, of which Cisco has been a constant innovator. Over the recent years, VXLAN with BGP EVPN has emerged as the de-facto industry standard for network virtualization.

For as long as networks and virtualized networks have existed, the manageability and observability of these fabrics, have been critical concerns for network operators.

Standardization across platforms and vendors is critical to enabling network operators to achieve these goals. SNMP and syslogs have been widely used to gather data, to monitor and manage network devices. However, SNMP lacks the ability to capture the fidelity of data that operators require. Syslogs are unstructured and while easily human readable, are not easily interpreted by automation and monitoring systems.

Besides being at the cutting edge of architecting network fabrics and network overlays, Cisco has also been an innovator in open and programmable networks. The open NX-OS philosophy began with the ability to run on-switch applications, natively in NX-OS or in the isolated Guestshell environment, later adding off-switch automation solutions such as Puppet and Ansible which have seen widespread adoption. More recently industry standard APIs, models, and transports such OpenConfig, NETCONF, RESTCONF, and gNMI have become a core part of the open NX-OS strategy.

These two areas that Cisco has long been an innovator in, namely network virtualization and open programmable interfaces, came together in the most recent enhancements to the OpenConfig models, which now support VXLAN EVPN and as part of our most recent NX-OS 10.3(1)F release. Cisco built these enhancements in conjunction with industry partners, to provide simplified monitoring and automation capabilities to our customers.

EVPN: A brief explainer

In the context of an EVPN overlay, an EVPN Instance (EVI) is a Virtual Private Network (VPN). With the Cisco NX-OS VLAN-based approach to EVPN, this results in a single broadcast domain per EVI, and with this VLAN-based approach, the tenant VLAN is mapped to a single EVI. With this 1:1 mapping, the single broadcast domain or tenant is represented by a VLAN or a VNI.  The VLAN/VNI is associated with an EVI which provides the most granular control for importing routes.

What is OpenConfig?

OpenConfig is an informal working group of vendors and network operators collaborating together, to define declarative model-driven solutions for the management, monitoring and operation of networking devices. A core tenant of OpenConfig is focused on defining vendor-agnostic YANG models based to deliver a programmatic interface to achieve these goals.

EVPN with OpenConfig

Within the existing OpenConfig network-instances model, an EVI and associated constructs are now part of the existing network-instance/fdb hierarchy. The enhancements Cisco contributed to the l2rib container consists of a new container within the parent Forwarding Database (FDB) container. The L2RIB has 2 primary containers, the MAC table and the MAC-IP table as shown in Figure 1.

The MAC table represents the operational state for MAC address information, pertaining to each domain of the L2RIB. This consists of stateful leaves such as the MAC address, VLAN, EVI, and L2-VNI for a locally significant broadcast domain as well as the next hop data, such as an interface, or sub-interface.

The second container within the new L2RIB is the MAC-IP table, which consists of remote MACs learned via the control plane. Like the MAC table, it has stateful leaves such as MAC address, VLAN, EVI, and L2-VNI, but in addition, it also contains an L3-VNI and host-IP for the MAC-IP entries as shown below. This L3-VNI is used solely in the context of inter-subnet routing.

In addition to these enhancements within the L2RIB, there are also additional enhancements within the L2VPN container of the BGP Address Family Indicator/ Subsequent Address Family Indicator (AFI/SAFI) network instance, which together provide deep visibility into the overall state and routing of a Cisco NX-OS BGP EVPN fabric.

Better Together: NX-OS with OpenConfig

Cisco is excited to announce new capabilities within its VXLAN BGP EVPN solution with contributions to an opensource and industry standard solution such as OpenConfig. Cisco has a long-standing focus on industry standards and openness in mind. Together, Cisco NX-OS tied with these OpenConfig enhancements, provide deep visibility into both the routing and forwarding of an NX-OS VXLAN fabric and the applications that the fabric supports. These innovations and expanded capabilities are just the first set of results based on our contributions to OpenConfig.

Source: cisco.com

Continue reading

How to Prepare for Cisco 700-680 CSaaS Certification?

Cisco 700-680 CSaaS Exam Description:

This exam will test the knowledge of Account Manager/Presales engineers on the foundations of Cisco’s Collaboration SaaS solutions in order for them to effectively sell these cloud-based services. This exam is a requirement for the Cisco Collaboration SaaS Authorization Program.

A great way to start the Cisco Collaboration SaaS (CSaaS) preparation is to begin by properly appreciating the role that syllabus and study guide play in the Cisco 700-680 certification exam. This study guide is an instrument to get you on the same page with Cisco and understand the nature of the Cisco Collaboration SaaS Authorization Exam exam.

Cisco 700-680 Exam Overview:

• Exam Name- Cisco Collaboration SaaS Authorization Exam
• Exam Number - 700-680 CSaaS
• Exam Price- $80 USD
• Duration- 30 minutes
• Number of Questions- 35-45
• Passing Score- Variable (750-850 / 1000 Approx.)
• Recommended Training- Cisco SaaS Authorization Training
• Exam Registration- PEARSON VUE
• Sample Questions- Cisco 700-680 Sample Questions
• Practice Exam- Cisco Collaboration SaaS Practice Test

Cisco 700-680 Exam Topics:

• Webex Market Overview- 5%
• Webex Meetings, Webex Teams, Webex Devices, and Webex Edge- 30%
• Webex Calling- 5%
• Webex Control Hub, Webex security, compliance and Webex for developers- 30%
• Collaboration Flex Plan- 20%
• Overview of Ordering, Smart accounts and Webex Try and Buy- 10%

Related Article:-

Major Benefits of Investing in 700-680 CSaaS Cisco Collaboration SaaS Authorization Exam

 

Continue reading

New Learning Labs for NSO Service Development

Getting started with network automation can be tough. It is worth the effort though, when a product like Cisco Network Services Orchestrator (NSO) can to turn your network services into a powerful orchestration engine. Over the past year, we have released a series of learning labs that cover the foundational skills needed to develop with NSO:

◉ Learn NSO the Easy Way

◉ Yang for NSO

◉ XML for NSO

Now we are proud to announce the final piece of the puzzle. We’re bringing it all together with the new service development labs for NSO. If this is your first time hearing about Cisco NSO and service development, let’s review some of the context.

Why change is the only constant

Network programmability has been enhancing our networking builds, changes, and deployments for several years now. For the most part, this was inspired by Software Defined Networks – i.e., networks based on scripting methods, using standard programming languages to control and monitor your network device infrastructure.

Software-defined networking principles can deliver abstractions of existing network infrastructure. This enables faster service development and deployment. Standards such as NETCONF and YANG are currently the driving force behind these abstractions, and are enabling a significant improvement in network management. Scripting can take out a lot of laborious and repetitive tasks. However, it may still have shortfalls, as it can focus on single devices, one vendor, or one platform.

Service orchestration simplifies network operations

Service orchestration simplifies network operations and management of network services. Instead of focusing on a particular device and system configuration that builds a network service, only the important inputs are collected. The rest of the steps and processes for delivery are automated. The actual details, such as vendor-specific configurations on network devices and the correct ordering of steps, are abstracted from the user of the service. This results in consistent configurations, prevention of errors and outages, and overall cost reduction of managing a network.

Remove the complexity

With NSO services, service application maps input parameters to create, modify, and delete a service instance into the resulting native commands to devices in the network. The input parameters are given from a northbound system such as a self-service portal via an API (Application Programming Interface). This calls to NSO or a network engineer using any of the NSO User Interfaces such as the NSO CLI.

NSO Service Development Module

In this new NSO learning lab you will learn how NSO services simplify network operations, how they work, and how to develop a template-based service. You will also use Python for scripting and service development, and to develop nano services. The module is broken into three sections which will guide you through use cases of NSO Service Developments.

◉ Introduction to NSO Service Development – How NSO services simplify network operations, how they work, and how to develop a template-based service

◉ Python Scripts and NSO Service Development – Python Scripts and NSO Service Development

◉ NSO Nano Service Development – How to develop nano services in NSO

Try it yourself now

You can find the new NSO Service deployment module in the NSO Basics for Network Operations Learning Track. All these new learning labs can be run and tested in the NSO DevNet reservation sandbox.

One of the things I embrace as an engineer is that change will happen. It might happen overnight, or over an extended period of time. But, it will happen. The only constant in the networking and software industry is ‘change.’ Let’s embrace this!

Source: cisco.com

Continue reading

Service Chaining VNFs with Cloud-Native Containers Using Cisco Kubernetes

To support edge use cases such as distributed IoT ecosystems and data-intensive applications, IT needs to deploy processing closer to where data is generated instead of backhauling data to a cloud or to the campus data center. A hybrid workforce and cloud-native applications are also pushing applications from centralized data centers to the edges of the enterprise. These new generations of application workloads are being distributed across containers and across multiple clouds.

Network Functions Virtualization (NFV) focuses on decoupling individual services—such as Routing, Security, and WAN Acceleration—from the underlying hardware platform. Enabling these Network Functions to run inside virtual machines increases deployment flexibility in the network. NFV enables automation and rapid service deployment of networking functions through service-chaining, providing significant reductions in network OpEx. The capabilities described in this post extend service-chaining of Virtual Network Functions in Cisco Enterprise Network Function Virtualization Infrastructure (NFVIS) to cloud-native applications and containers.

Cisco NFVIS provides software interfaces through built-in Local Portal, Cisco vManage, REST, Netconf APIs, and CLIs. You can learn more about NFVIS at the following resources:

◉ Virtual Network Functions lifecycle management

◉ Secure Tunnel and Sharing of IP with VNFs

◉ Route-Distribution through BGP NFVIS system enables learning routes announced from the remote BGP neighbor and applying the routes to the NFVIS system; as well as announcing or withdrawing NFVIS local routes from the remote BGP neighbor.

◉ Security is embedded from installation through all software layers such as credential management, integrity and tamper protection, session management, and secure device access.

◉ Clustering combines nodes into a single cluster definition.

◉ Third-party VNFs are supported through the Cisco VNF Certification Program.

Figure 1: Capabilities of Cisco NFVIS

Virtualizing network functions sets the stage for managing container-based applications using Kubernetes (k8s). Cisco NFVIS enables service chaining for cloud-native containerized applications for edge-compute deployments to provide secure communication from data center to cloud to edge.

Integrate Cloud-Native Applications with Cisco Kubernetes

Cisco’s goal is to make it easy for both NetOps and DevOps to work together using the same dashboard to perform the entire process of registering, deploying, updating, monitoring VMs, and provision service chains with the easy-to-use Cisco Enterprise NFVIS Portal or Cisco vManage for SD-WAN. NetOps persona can perform each step of the VNF lifecycle management to deploy VNF-based service chains.

Cisco NFVIS now includes Cisco Kubernetes to provide centralized orchestration and management of containers. Cisco Kubernetes is available to download through Cisco’s NFVIS Software site. The current release supports the deployment of Cisco Kubernetes through NFVIS Local Portal and NFVIS APIs using existing NFVIS Lifecycle Management Workflows.

Cisco Kubernetes has a built-in Kubernetes Dashboard, enabling NetOps and DevOps Admins to use standard Kubernetes workflows to deploy and manage networking and application VMs. NetOps Admins acquire access tokens in NFVIS via the built-in GUI Local Portal or NFVIS CLI to access a Kubernetes Dashboard running inside Cisco Kubernetes. NetOps personas can execute their role in establishing VNFs and then hand off administration tokens to DevOps personas to access the Kubernetes Dashboard within Cisco Kubernetes. DevOps uses the dashboard to instantiate and manage their application containers. VNFs can be service chained with applications inside Cisco Kubernetes via an ingress controller that is deployed as part of a Kubernetes cluster to provide load balancing and ingress controls.

Figure 2: Kubernetes Dashboard inside Cisco Kubernetes

Cisco Kubernetes supports two deployment topologies:

◉ Single node is enabled in the current NFVIS 4.9.1 release.

◉ In future releases, multi-node topologies will enable capabilities such as high availability..

Figure 3: Cisco NFVIS Application Hosting Workflow

Collaborative Tools to Simplify Cloud Native Container Applications

Ops team collaboration is made possible by Cisco Enterprise NFVIS and Cisco Kubernetes to power tomorrow’s applications across clouds and edge use cases. Deploying service-chained VNFs has enabled NetOps to simplify support for distributed offices, devices, and applications. Now Cisco Kubernetes in Cisco Enterprise NFVIS provides DevOps with a familiar set of k8s workflows to deploy containerized applications from on-premises to cloud to edge, taking full advantage of the service-chained VNFs managed by NetOps.

Source: cisco.com

Continue reading

Rise of the Open NOS

Open networking Innovations are largely driven by an industry need to protect network platform investments, maximize supply chain diversification, reduce operating costs, and build a homogenous operational and management framework that can be consistently applied across platforms running standardized software. By virtue of its adoption by cloud scale operators and its most recent inclusion in the Linux Foundation, SONiC has gained tremendous momentum across different market segments. This blog outlines key factors relevant to SONiC adoption, its evolution in the open network operating system (NOS) ecosystem, and Cisco’s value proposition with the SONiC platform validation and support.

Why use an open NOS?

Disaggregation enables decoupling hardware and software, giving customers the ability to fully exercise plug-and-play. An open-source NOS like SONiC can provide a consistent software interface across different hardware platforms, allowing for supply chain diversity and avoiding vendor lock in, further leveraged by in-house custom automation frameworks that don’t have to be modified on a per-vendor basis. A DevOps-centric model can accelerate feature development and critical bug fixes, which in turn reduces dependency on vendor software release cycles. The open-source ecosystem can provide the necessary support and thought leadership to enable snowflake use cases prevalent in many network deployments. The freedom to choose can protect investment across both hardware and software, thus leading to significant cost savings that further reduce total cost of ownership (TCO), operating expenditures (OpEx), and capital expenditures (CapEx).

What is SONiC?

SONiC (Software for Open Networking in the Cloud) was created by Microsoft in 2016 to power their Azure cloud infrastructure connectivity. SONiC is Debian based and has a microservice based containerized architecture where all major applications are hosted within independent Docker containers. In order to abstract the underlying hardware and ASIC, SONiC is built on SAI (Switch Abstraction Interface)which is a standardized vendor neutral hardware abstraction API. The NOS provides north bound interfaces (NBIs) to manage the device and these NBIs are based on gNMI, ReST, SNMP, CLI, and Openconfig Yang models so it’s easily integrated with automation frameworks.

Figure 1. A conceptual overview of SONiC

 

Why SONiC?

With so many open-source options out there, why consider SONiC? This NOS is gaining strong community leverage with growing industry traction through its adoption by prominent players spanning different market segments such as enterprise, hyperscale data center, and service providers. Open-source contributions have honed SONiC for focused use cases, enriching feature delivery while holistically enabling different architectures. Below are a few factors that emphasize open NOS benefits as applicable to SONiC:

Open Source:

◉ Vendor independence – SONiC can run on any compatible vendor hardware

◉ Feature velocity – Custom feature additions/modifications and self-driven bug fixes

◉ Community support – Upstream code contributions benefit all SONiC consumers

◉ Cost savings – Reduced TCO, OpEx, and CapEx

Disaggregation:

◉ Modular components – Multiple independent containerized components for increased resiliency and easier plug-and-play

◉ Decoupling software functions – Individual components can be customized based on use case

Uniformity:

◉ Abstraction – SAI abstraction layer to normalize underlying hardware intricacies

◉ Portability – Feature portability as the SAI normalizes hardware complexity

DevOps:

◉ Automation – Unified orchestration/monitoring for compute and common NOS across platforms

◉ Programmability – SONiC provides options that can leverage ASIC capabilities to the fullest

Figure 2. The value proposition of SONiC

 

Where does SONiC fit in various use cases?

At a high level, the existence of a software feature on a SONiC-enabled system depends on the following three components:

1. SONiC operating system support – Community driven

2. SAI API support – Community driven

3. SDK support – Vendor driven

For a software feature to be built into SONiC, it needs to be facilitated at all the above layers to be fully productized. The current SONiC ecosystem is comprehensively built for IP/VxLAN and BGP based architectures. These technology components can be cross-leveraged to create any architecture of choice – whether it is a data center fabric or a CDN ToR. SONiC deployments today are predominantly observed in data centers and enterprises but can be easily extended to other networks that leverage similar technology components. Commonly deployed network roles and use cases with SONiC are outlined below:

Data center fabric and DCI – IP/VxLAN and BGP based:

1. Leaf (single and dual homed)

2. Spine

3. Super spine

These data center deployments are spread across different customer segments ranging from Tier1/Tier 2 hyperscalers, service providers, and larger enterprises.

Due to its strong community support, many working groups are collaborating on how to further extend SONiC for core and backbone use cases, amongst others. For example, the SONiC MPLS working group is looking at enabling MPLS and SR/SRv6 support for SONiC that are more applicable to WAN use cases.

SONiC in the real world

With all the benefits of an open-source NOS, network operators have many questions such as “Is SONiC the right fit for my use case?”, “How does support work?”, “How do I ensure code quality?”, “How do I train my team to build the skill set to manage SONiC?”, and the list goes on. Product adoption is always driven by customer experience. Any product or solution, open-source or not, will be successful only if it provides a seamless user experience. While the many merits of an open-source NOS are attractive, operators still want the security and partnership of a vendor NOS when it comes to support and field deployments. So how do we achieve the best of both worlds?

Network operators assessing SONiC either have a very strong self-driven ecosystem equipped to handle an open NOS or they’re trying to understand the deployability of an open NOS. Operators with a self-sufficient ecosystem tend to gravitate towards customized SONiC to suit their specific network requirements. This might involve customizing community SONiC to create a private distribution (BYO – build your own) or they can rely on external vendors that create commercial distributions built from community SONiC. On the other hand, operators trying to gain more experience with open NOS for relatively simpler use cases might want to rely on community SONiC, where there’s a fine balance in retaining the open-source nature of SONiC along with its validation on vendor hardware.

Figure 3. SONiC consumption model

While assessing a network rollout, there are certain evaluation criteria that an operator needs to consider. These evaluation criteria are independent whether the network solution in place is open or closed but depending upon the target ecosystem the responses to these criteria might differ.

Table 1. SONiC deployment evaluation criteria

The Cisco 8000 Series advantage

The high-performance Cisco 8000 Series of routers and switches is based on the Cisco Silicon One ASIC, making these devices three times more power efficient and twice as dense as industry incumbents. A wide variety of fixed and modular form-factors are available, while its power savings, run-time completion efficiency, and SDK portability offer unique advantages of the Cisco 8000 that greatly facilitate SONiC onboarding. As a strategic investment, every new platform is compatible with SONiC for the ability to leverage one silicon and one software end-to-end in different roles across use cases.

Figure 4. SONiC – The Cisco advantage

Support

The saying “With great power comes great responsibility” aptly applies to any open-source ecosystem. When deploying a production network, every operator is looking for holistic triage, faster resolution, predictable SLAs, and accountability. So how does this apply to SONiC?

Operationalizing SONiC on vendor hardware can be visualized as three layers. The bottom two layers consist of vendor-specific components – hardware systems at the very bottom followed by the infrastructure software that consists of SAI APIs, SDK, BSP/platform drivers, and other glue logic to seamlessly abstract hardware intricacies from the overlying operating system. By itself, SONiC looks like a constellation of open-source components and custom code, depending on whether customized SONiC is in play or not. With plug and play, accountability still sits with respective stakeholders for their components, leading to a shared responsibility support model. For Cisco-validated SONiC, every shipping platform will go through intensive customer and use case centric testing, with major and minor release cadence for community SONiC. Major releases will support newer features while minor releases provide bug fixes.

Figure 5. Shared responsibility support model

Source: cisco.com

Continue reading