An Update on the Evolving Cisco and SAP Strategic Partnership

As Cisco’s SAP ambassador, I’m often asked, “Tell me about the Cisco and SAP partnership.” Many may not know, but in 2019 we celebrated twenty years of Cisco and SAP working strategically together—always with the objective of benefiting our mutual customers. Innovation has been an intense focus for the partnership, which is why, for example, Cisco became a founding sponsor of the SAP co-innovation lab in 2014.

Today, the Cisco and SAP partnership touches many business units at Cisco; what began with optimizing Cisco Data Center products to run SAP software has evolved to include other strategic areas such as Internet of Things (IoT), cloud computing, big data processing, AI/ML, and collaboration.

SAP Data Hub on Cisco Container Platform

As an example of software co-innovation, Cisco Container Platform (CCP) is certified for the SAP Data Hub and includes support for use cases such as hybrid cloud big data processing. Many SAP Data Hub customers want to run in hybrid cloud environments to leverage cloud-based services, while also keeping some data on premises to meet security and governance requirements.

SAP Data Hub is SAP’s first micro services container-based application, and it enables users to orchestrate, aggregate, visualize, and generate insights from across their entire data landscape. SAP Data Hub runs anywhere Kubernetes runs.

Unfortunately, running Kubernetes on premises has its challenges. For instance, IT must  answer questions about how to manage and support Kubernetes. In addition, it’s challenging to connect the private and public cloud environments and complicated to manage user access and authorizations across multiple environments.

The integration of SAP Data Hub with CCP addresses these challenges. CCP is a production-ready Kubernetes container management platform based on 100 percent upstream Kubernetes and delivered with Cisco enterprise-class Technical Assistance Center (TAC) support. It reduces the complexity of configuring, deploying, securing, scaling, and managing containers via automation. CCP works across on-premises and public cloud environments.

The Cisco and SAP teams are working closely to bring the next iteration  of SAP’s multicloud strategy for on-premises deployments—SAP Data Intelligence, which marries SAP Data Hub to AI/ML—to fruition.

AppDynamics monitors SAP environments

Cisco has enhanced AppDynamics, its application performance monitoring product, to monitor SAP environments. This engineering effort includes giving AppDynamics code- level visibility into SAP ABAP, which is the primary programming language for SAP applications.

This new capability provides direct hooks that enable AppDynamics to measure the business process performance of SAP applications. And though SAP has its own monitoring solution, AppDynamics enables SAP customers to monitor their business processes across SAP and non-SAP solutions.

Monitoring is of special importance to SAP customers because their systems often consist of SAP and non-SAP components. For example, at a minimum, an online retail e-commerce system likely consists of a web server connected to an SAP ERP system, and slow checkout can potentially drive customers away. Unfortunately, it is time-consuming and difficult for engineering teams to diagnose where in the stack a performance issue is occurring.

Cisco DNA spaces

Everyone is talking about IoT and digital transformation. However, a big challenge in deploying an IoT strategy is the need to put sensors everywhere, which represents a huge investment of capital, time and resources.

As a leading network provider, Cisco can help customers meet this challenge, because,  in many cases, a wireless network is already in place. A wireless access point not only acts as a transmission device, but it can also sense things if enabled with Cisco DNA Spaces. For instance, an access point can track how many mobile phones are connected, for how long, and where they are located at all points in time. By combining geo-location information with enterprise data, businesses get closer to achieving the IoT promise of utilizing data from things to ultimately make better decisions.

Consider this scenario: the owner/operator of a shopping mall wants to know not only quantity of traffic but also where visitors to the mall go. By combining this data with SAP ERP data such as lease fees and analyzing it, the owner/operator can decide upon fair lease prices for shops located in lower- versus higher-traffic areas.

Through Cisco and SAP co-engineering, the rich on-location people and things data provided by Cisco DNA Spaces is now integrated with SAP software, enabling our mutual customers to gain additional insights into what’s happening in their businesses.

Cisco Data Center solutions for SAP

Finally, Cisco UCS-based converged infrastructure solutions—which were launched over a decade ago—are at the heart of the infrastructure running many SAP workloads today. These solutions blend secure connectivity, programmable computing, multicloud orchestration, and cloud-based management with operational analytics for our customers’ SAP data centers.

We continue to innovate around these data center solutions to support evolving use cases such as providing support for machine learning applications. Cisco Data Center solutions, for example, have now integrated NVIDIA GPUs and are certified to support Intel® Optane, which enables persistent memory, larger memory pools, faster caching, and faster storage.

The next twenty years …

As Cisco’s SAP ambassador, I’ve seen over and over again how Cisco and SAP’s portfolios complement each other. For example, a key SAP mission is to help its customers become intelligent enterprises, which requires robust connectivity at all customer touchpoints. This mission, of course, meshes with Cisco’s core competency as the world’s leading network provider.

As we continue to innovate, Cisco and SAP will continue our laser focus on co-engineering innovations that deliver the value our mutual customers require in their evolving business environments.

Continue reading

Service Mesh for Network Engineers

Learning never ends, and that’s never been truer for the trusty network engineer. Of late Network Engineers have been moving up the stack, changing the way we deliver network services, becoming programmatic and using new tooling.

A not so scientific graph of what network engineers need to be aware of in 2020

The driving force behind these changes is the evolution of application architectures. In the era of modular development, applications are now collections of loosely coupled microservices, independently deployable, each potentially developed and managed by a separate small team. This enables rapid and frequent change, deploying services to where it makes most sense (e.g. Data Centre, public clouds or Edge). At the same time, Kubernetes (K8s) is quickly becoming the de facto platform upon which to deploy microservices.

What does this mean for the networker engineer? Well, routing, load balancing and security have been the staple of many over the years. It’s stuff engineers know very well and are very good at. But these capabilities are now appearing in some new abstractions within the application delivery stack.

For example, K8s implements its own networking model to meet the specific requirements of the k8s architecture. Included in this model are network policies, routing pod to pod, node to node, in and out of clusters, security and load balancing. Many of these networking functions can be delivered within K8s via a Container Network Interface (CNI) like Nuage or Flannel. Alternatively, you could leverage a lower level networking abstraction such as the Cisco Application Centric Infrastructure (ACI), benefitting from using one common network fabric for bare metal, virtual machines and containers.

As K8s is a container orchestrator, designed for creating clusters and hosting pods, its networking model meets exactly those needs. However, K8s is not designed to solve the complexity of microservices networking. Additional developer tooling for microservices such as failure recovery, circuit breakers and end to end visibility is often embedded in code to address those aspects, adding significant development overhead.

Enter stage left service mesh.

“The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication”

The above poses the question: is a service mesh a network layer? Well… Kind of. The service mesh ensures that communication between different services that live in containers is reliable and secure. It is implemented as its own infrastructure layer but, unlike K8s, it is aware of the application. Some of the capabilities it delivers to the application are recognisable network functions such as traffic management and load balancing, but these are executed at the microservices layer, and need that intimate knowledge of the application and its constituent services. Equally, the service mesh relies on lower level abstractions to deliver network functions as well.

Service mesh networking vs K8s networking

To compare the capabilities of k8s and service mesh let’s look at the example of a canary deployment. The idea behind a canary deployment is that you can introduce a new version of your code into production and send a proportion of users to the new version while the rest remain on the current version. So, let’s say we send 20% of users to our v2 canary deployment and leave the other 80% on v1.

You can achieve this with k8s but requires some hand cranking. It would require you to create your new canary deployment in proportion to what already exists. For example, if you have 5 pods and want 20% to go to the V2 canary, you need 4 pods running v1 and 1 pod running V2. The Ingress load balancing will distribute load evenly across all 5 pods and you achieve your 80/20 distribution.

Canary Deployments with K8s and Service Mesh

With service mesh this is much easier. Because the service mesh is working at the microservices network layer you simply create policies to distribute traffic across your available pods. As it is application-aware, it understands which pods are V1 and which pods the V2 canaries and will distribute traffic accordingly. If you only had two pods, V1 and V2, it would still distribute the traffic with the 80/20 policy.

In terms of comparing them, we can think of as K8s provides container tooling whereas service mesh provides microservices tooling. They are not competitive. They complement each other.

Looking at the overall stack, we can see that there are now four different layers that can deliver specific networking functions – and you might need all of them.

Abstractions and more abstractions

How Does a Service Mesh Work?

There are a number of service mesh options in the market right now. Istio from Google probably gets most the headlines but there are many other credible service meshes such as Linkerd, Envoy, and Conduit.

Istio Control Plane and Sidecar Proxies

Typically, a service mesh is implemented using sidecar proxies. These are just additional containers (yellow in the diagram above) that proxy all connections to the containers where our services live (blue in the diagram above). A control plane programs the sidecars with policy to determine exactly how the traffic is managed around the cluster, secures connections between containers and provides deep insights into application performance. (We will have some follow-up blog posts going under the service mesh covers in the coming weeks).

Ok. Great stuff. But what does this mean for the network engineer?

Many of the service mesh features will be familiar concepts as a network engineer. So, you can probably see why it’s important for network teams to have an understanding of what a service mesh is, and how, why and where these different capabilities are delivered in our stack. Chances are, you may know the team that is responsible for the service mesh, you may be in that team, or end up being the team that is responsible for the service mesh.

Delivering microservices works great in an ideal world of greenfields and unicorns, but the reality is that most don’t have that luxury, with microservices being deployed alongside or integrated to existing applications, data, infrastructure stacks and operational models. Even with a service mesh, delivering microservices in a hybrid fashion across your data centre and public cloud can get mighty complex. It’s imperative that network engineers understand this new service mesh abstraction, what it means to your day job, how it makes you relevant and part of the conversation, and perhaps it spells great opportunity.

If you want to learn more then there are a number of service mesh sessions at CiscoLive Barcelona.

Service Mesh for Network Engineers – DEVNET – 1697

Understanding Istio Service Mesh on Kubernetes – DEVNET-2022

DevNet Workshop: Let’s Play with Istio – DEVWKS-2814

But..why do I need a Service mesh? – BRKCLD-2429

Continue reading

Cisco 8000 Series Powering the Internet for the Future

On December 11th 2019, Cisco announced a set of new offerings – silicon, optics, software, and routing systems – specifically designed to power the Internet for the future. In my time at Cisco, I’ve had the privilege of launching a few notable routing systems – the ASR 9000, the NCS 6000, and the NCS 5500, but introducing the new Cisco 8000 Series is an exceptional moment, both for my team and me. It’s the result of a bold decision we made five years to totally rethink our approach and revisit every assumption we were taking for granted when designing new devices.

We are thrilled to add the Cisco 8000 Series to our routing portfolio. For our customers, it complements the NCS 5500 Series, resulting in a broader choice of 100G and 400G-optimized systems. And for those speculating about the future of the NCS 5500 Series, it is not going away; we continue to strengthen our investments in these platforms. Our customer’s technology and business needs vary, and a routing portfolio that includes both the Cisco 8000 Series and the NCS 5500 Series can best address those needs. This fact was recently confirmed with a TCO analysis from ACG Research, demonstrating that each of the platforms has an economic sweet spot.

This decision to build the new Cisco 8000 Series was indisputable when we looked at IP traffic projections. The Internet traffic carried by service providers’ networks is growing exponentially, at an annual rate of 20-30%. The growth is fueled by connections – more subscribers and devices connecting to the network, and by the type of interactions, as enterprises’ push to store more data in the cloud. Meanwhile, video, a particularly bandwidth-hungry service, continues its colossal growth rate. All this means that the massive scale at which service providers operate today will grow even larger in the years to come, and it’s the very near future when the current network economics start to break.

There was no time to wait. We needed to think differently and lay the groundwork for new routing economics and new routing systems that would bring not only a quantum leap in total capacity but also deliver unprecedented economics efficiency.

With a clean-sheet design, we had the latitude to innovate across multiple dimensions – down to the “molecular” level of routers, the silicon. The Cisco 8000 Series is the result of this approach; it redefines routing with unprecedented petabit scale, trustworthiness, and cloud-enhanced technology.

Designed to build the Internet for the future

We introduced fixed and modular form-factor systems, respectively the Cisco 8200 Series and the Cisco 8800 Series.

The Cisco 8200 Series uses the new Cisco Silicon One Q100 as a Router-on-Chip (RoC) to deliver full routing functionality with a single ASIC per router. The RoC architecture supports for large forwarding tables, deep buffers, more flexible packet operations, and enhanced programmability, which differentiates it from System-on-Chip (SoC) switches.

There are 2 fixed platforms – each of these platforms providing 10.8Tb/s of network bandwidth with very lower power consumption – 4 Watts/100G:

◉ The Cisco 8201 is a 1RU fixed configuration with 24x400GbE and 12x100GbE ports

◉ The Cisco 8202 is a 2RU fixed configuration with 12x400GbE and 60x100GbE ports

In one single rack unit, the Cisco 8201 router delivers the routing capacity that once required a full rack and 15 times the power only five years ago. This steep function in efficiency enables broader market possibilities for scenarios such as CDNs, 5G sites, and colocation as 10.8 Tb/s routers can be deployed in space and power footprints once reserved for only 100s of Gb/s.

The 8800 Series provides the highest bandwidth via modular chassis with a redundant control plane and switch fabric:

◉ The Cisco Router 8808 is an 8-slot, 16RU chassis initially delivering up to 115.2 Tb/s, equivalent to 288×400 GbE ports at full line-rate

◉ The Cisco Router 8812 is a 12-slot, 21RU chassis delivering up to 172.8 Tb/s, equivalent to 432×400 GbE ports at full line-rate

◉ The Cisco Router 8818 is an 18-slot, 33RU chassis delivering up to 259.2 Tb/s, equivalent to 648×400 GbE ports at full line-rate

All these systems come without oversubscription, with full fabric redundancy, and power efficiency of 11 Watts/100G.

Designed for handling future traffic growth

The platforms shipping today support 100GbE and 400GbE connectivity at mass scale, but that’s not the end of it. The Cisco 8800 systems are engineered to deliver the capacity service providers require for at least the next decade.

Unlike platforms that support 400GbE connectivity at the end of their lifecycle, the Cisco 8800 Series routers are delivering 400GbE at the very beginning of its lifecycle. The extra space required to cool advanced optics, highly efficient power supplies and fans, and electrical connectors have been anticipated for future expansion into higher densities using 800GbE, 1.6TbE, and beyond.

Designed for cloud-enhanced network operations

Service providers need network reporting and analytics services to complement their internal network optimization and automation infrastructure.

The design of the Cisco 8000 Series incorporates cloud-enhanced network operations and currently leverages the following SaaS offerings:

◉ Crosswork Network Insight to assess network routing health

◉ Crosswork Trust Insight to gather network evidence, and visualize/report on trustworthy infrastructure

◉ Crosswork Qualification Environment to automate qualification of new OS releases in a custom-fit environment

With cloud-based SaaS services, deployment can happen quickly with low operational costs. And these services provide continuous updates enabling service providers to always operate with the most up-to-date and critical features.

Designed for trustworthy critical infrastructure

Over the last decade, network attacks have become more sophisticated. Threats continue to manifest in software, but physical tampering with hardware infrastructure is also increasing.

The best security practices demand multiple layers of defense.  Trustworthy systems are no different.

◉ Trustworthy starts by building hardware with critical infrastructure outcomes in mind; this requires tamper-proof hardware that serves as the root of trust, what we call the Trust Anchor module, which can prevent tampering with chipsets and secure storage. Cisco Chip Protection, introduced in the new Cisco 8000 Series routers, enables ‘hardware fingerprints’ and detects any physical tampering with components, like the modification or replacement of a chip (CPU, ASICs, etc…) on the router

◉ The next layer involves booting hardware from a known authentic image and booting the OS from the root of trust. Cisco Chip Protection expands the measurement of hardware integrity as part of the Cisco Secure Boot process

◉ Finally, systems stay online for long durations of time, which requires run-time checks to verify against known good behaviors of running processes. With the Trust Anchor module and Cisco Chip Protection, irregularities can be rapidly identified and flagged

Embraced by Tier-1 service and cloud providers

Contrary to some of our competitors who “future” announce new platforms, the Cisco 8000 Series is available today.

We are very pleased to see that the Cisco 8000 Series is already gaining traction with some major service providers:

◉ STC, the leading telecom services provider in the Middle East, Northern Africa region, marks the first customer deploying the new technology
◉ On-going trials include Comcast and NTT Communications among others

Hyperscale cloud operators are also very interested in the Cisco 8000 Series. Microsoft has noted how important the support of SAI (Switch Abstraction Interface) is as it rapidly onboards new systems, using the advanced programmability and scale that Cisco Silicon One delivers:

“Cisco’s support for SAI on Cisco 8000 modular routing platforms is a major step forward enabling the SONiC community to combine the latest innovations in silicon and port speed with the density and power efficiencies delivered in chassis-based systems. This greatly contributes to the continuous scale up efforts of cloud infrastructure providers in the face of unceasing traffic growth.”Yousef Khalidi , CVP, Azure Networking, Microsoft Corp

Continue reading

The Future of Meetings in 2030

Meetings of the Future

What excites me about working on the bleeding edge of technology is not the technology itself, but what it enables. Everything we do in Cisco’s Collaboration organization is to build the best tech we can to bring people together. Our technology should never be at the forefront of the interaction. If we’re doing our job right, you shouldn’t even notice it’s there. What I find truly exciting is the experience we’re creating. The feeling of togetherness.

Humans have been communicating and working together since the beginning of time. We smile, gesture, use our eyes, hands, and posture to communicate meaning. We come to life when we meet face to face. We share. We bond. We dream. We explore. We create.

Closing the Gap Between Digital Data and the Physical World

How do we replicate that experience—not the exactness of it, but the essence of it—in a fully connected, ambient experience that draws on the best, fluid blend of physical and virtual elements?

Perhaps the best way I can share this is to describe what I want a typical meeting to be like in 2030:

It’s 9:28 am. My amorphous intelligent agent, Kodi, reminds me that I have a meeting in two minutes. I turn away from the blank wall I was just looking at that held a digital representation of my work area and face the couch and couple armchairs in my bright, sunlight home office. The wall behind me reverts to a lazy afternoon view of Venice from the viewpoint of an apartment window overlooking a quiet canal. My brain-computer interface detects my upbeat mood and changes the view to overlook the bustling Grand Canal. Sensors register my reactionary microexpressions and switch to an aerial backdrop of New York’s financial district and the brisk moving pedestrians in the rising sun of morning rush hour. I smile. Infrared sensors also detect my slightly elevated heartbeat and swap the dark roast in my espresso maker for decaf as it percolates a fresh cup.

At 9:30 am a pleasant bell tone sounds and my colleague, Cullen, materializes as a photorealistic hologram seated on the couch in front of me and we exchange hellos as another tone sounds and our mutual colleague, Jia, materializes standing next to the armchair to my right. I walk over to Jia’s outstretched hand and feel the sensory feedback of resistance and pressure as we haptically share a virtual handshake. Jia and Cullen’s holograms nod to each other in greeting and Jia’s hologram takes a seat in the armchair.

As we begin talking, Kodi captures key takeaways from the meeting and cycles 2 displays of information that continuously update and refresh as the conversation evolves. The first, visible to all three of us, is a constantly updating array of resources cycling across the surface of the coffee table between us showing past meeting notes, actions, and related research and news articles. The second array is visible to me only and floats at the periphery of my view with more personally attuned information—recent conversations I’ve had or notes I’ve taken, calendar updates, and my biometric readings as well as data aggregated from the three of us reflecting the tone and mood of the room. It also indicates that my coffee is ready, so I switch from full-form mode to face-only mode and Jia and Cullen can continue to see my facial expressions in real-time as my hologram remains seated facing them, but I physically get up to grab my coffee refill. As I sit back down in my armchair I toggle back to full-form mode as I shift positions in my chair and take a sip.

As we discuss an upcoming event, my calendar flicks to the foreground of my view showing the event details and surrounding events and locations before and after. I push this view into the middle of the room which enables Cullen and Jia to see my calendar view as well, but in moving from private to shared, the details of my appointments are masked. A moment later, the shared view updates to include Jia and Cullen’s schedules as they push their views into the shared space as well. Based on the context of our conversation, Kodi overlays major industry events over the top of our calendars. Jia points out a gap in activities about a week prior and suggests we target that date for our announcement. Kodi registers from the content that we will need a final review meeting and 3 potential meeting slots highlight on our shared calendar 3 days prior. We agree on the best one and our respective calendars are updated with the invite including key takeaways from today’s meeting and links to prior discussions on the same topic.

As we’re wrapping up, Cullen mentions he has an updated version of the prototype we are planning to announce. The object materializes in front of us as Cullen enables his share feature. On Cullen’s side, he is holding the physical object, but Jia and I see an identical virtual replica as Cullen points out the changes he’s made. He then shifts from physical share to virtual share and explodes the object out to the size of the room so we can see the updates at the internal component level. I get up and walk closer to Cullen, stepping inside the object, which I can then reach out and touch to manipulate, highlight, or edit. The changes look great and I turn and give Cullen a haptic high-five.

As our conversation wraps up, I see the actions and updates Kodi has added to my calendar and to-do list in my periphery. I wave goodbye to Jia and Cullen and they fade out of my room. It’s 10 am, and according to Kodi, it’s a good time for a morning break.

Combining AR in the Collaboration Space

Okay, some of this may still be out there on the time horizon, but some components are becoming a reality today. The above experience relies on a seamless mesh of natural language processing, adaptive algorithms, connected sensors, non-invasive biometrics, brain-computer interfaces, extended reality, and haptics. While some fields, like brain-computer interfaces and haptic feedback, are still in early stages, other areas like machine learning and natural language processing are becoming table stakes today.

Extended reality (augmented, virtual, mixed) is one area I’m particularly excited about. At Cisco, our Collaboration group has been fairly vocal about enabling augmented reality experiences with our Webex and Webex Teams APIs, specifically for a remote expert use case. Where we’ve been less vocal is what mixed reality can bring to the collaboration table, but we’ve been building something in stealth mode for the last couple of years which is truly exciting.

Proof of Concept for Three-Dimensional Collaboration in Real-Time

We’re not quite ready to share what we’ve been prototyping, but it’s been exciting challenging the current concept of what a meeting is and could be. We’re tapping into our internal knowledge of hardware, software, and networking, and we’ve been working behind closed doors with industry vendors at the top of their game—paradigm shifters who are opening up a whole new world of possibilities for creators, inventors, and dreamers everywhere.

I have the pleasure and privilege of leading initiatives for our innovation team where we are asking questions like: What if you could have real-life interactions that are better than what is currently possible in real life? What if conferencing didn’t have to be limited to a 2-dimensional plane? What happens when “real” and “virtual” are no longer distinct ideas?

There’s a lot to figure out and we’re not quite ready to tell the world what we’re building, but I can tell you, you’ve never experienced anything like this before because it’s never been done before! Stay tuned; you won’t want to miss it. These are exciting times to be a dreamer because, yes, dreams really do come true.

Continue reading

Artificial Intelligence Translational Services Use Cases in Cisco Contact Centers

Artificial Intelligence and Translational Services

The world is flattening; thus, with the business becoming increasingly global, the existing language barriers demand new solutions across vertical markets, especially when dealing with a company to a consumer.

Europe, with its 24 official different languages, is certainly posing some extra challenges to those companies delivering services across countries part of the union, and that’s nothing considering that there are more than 200 languages spoken on the continent.

The language barrier is undoubtedly and historically adding complexity to international business, and this is especially true when we consider Contact Centers and the high-quality customer experience they have to deliver in business-to-consumer services. While in business to business, there is a de facto international language, which is English. If there are consumers involved, that’s no longer an option —companies have to deal with the many languages spoken across countries.

Narrowing the Call Center Gap

With new generations of new consumers speaking their mother tongue language when calling a contact center, the translation problem will not disappear anytime soon. We should even expect the problem to become further challenging because of the increasing immigration of people. In 2017 2.4 million immigrants entered the EU from non-EU countries, and a total of 22.3 million people (4.4 %) of the 512.4 million people living in the EU on 1 January 2018 were non-EU citizens*

While these new immigrants will learn the local languages, they need to access services, especially public services, and this is quite a challenge, in particular for public administrations. In theory, a Contact Center could afford these challenges employing multilanguage agents or more agents. Still, it’s rather clear that this is far to be an optimal solution, and the associated costs are not negligible.

Apart from that, we are not talking about supporting two or three different languages, but rather a multitude of idioms; to depict the complexity of such a model, consider the challenges that this poses to a European contact center service in terms of WorkForce Management and Optimizations. When delivering a satisfied Customer Experience, it’s no longer just a matter of the number of agents we need each hour of the day, of the week, and the week of the month, but rather how many different languages they can speak — an authentic nightmare.

The Growing Need for Multilanguage Agents

It is also happening quite often that the multilanguage agents might be good at speaking two or three languages but not necessary at writing those. Therefore, the challenge is even higher for Digital Contact Centers.

Recent advances in speech technology and Natural Language Understanding (NLU) have the potential to transform today’s challenges into new opportunities. Artificial Intelligence, integrated into Cisco Cognitive Contact Centers, could deliver an excellent solution to business problems like those described above. For example, a digital Cisco Cognitive Contact Centers could leverage Google AI DialogFlow capabilities to provide a Chat Translation Assistance Service, literally able to remove the language complexity and costs from the “Contact Center Work Force Optimization equation.” Let’s see how in the following proof of concept example:

Watch the Video:

This is the logical architecture used in the video.

Another use case we may want to consider as a proof of concept is when traditional audio-only contact centers are located in a country abroad, where the cost of labor is cheaper. There are agents able to speak the required language even if they aren’t mother tongue. For example, this is the case for North African French-speaking contact centers, Est European Italian contact centers, and many more.

In cases like these, Cisco Cognitive Contact Centers powered by Artificial Intelligence could deliver an Audio Transcription and Translation Agent Assistance Service meant to assist the agent in dealing with foreign languages in a more natural, quicker, and more productive way. Let’s see how in the following proof of concept example:

Watch the video:

This is the logical architecture used in the video.

Transforming Customer Experience with Contact Center AI

The Contact Center business is going through a series of significant changes driven by the technology innovation, the raise of socials, and the new consumption models that are being evaluated by most of the companies.

From a technology angle, there is very little doubt that the advent of Artificial Intelligence is transforming traditional call centers into Cognitive Call Centers. This arrival is turning an IT cost into a business strategy tool to increase Customer Experience, achieving higher customer service levels and quality, increasing the productivity of agents, and even lifting their traditional role to the new one: customer ADVISORS and CONSULTANTS.

Cisco has a portfolio of on-premise, hybrid, and cloud contact center solutions. That covers the undergoing migration to Cloud and the demand for a versatile, open, consistent architecture across on-premises, hybrid, and cloud solutions able to grant a smooth transition to the broad base of existing customers and at the same time allowing a consistent innovation adding digital channels and artificial intelligence.

Continue reading

CLEUR Preview! Source of Truth Driven Network Automation

It’s a new year and a new decade, so it’s time for a NEW BLOG about network automation. I am getting ready for Cisco Live Europe 2020 and want to give everyone a preview of some of what I’ll be talking about in my session How DevNet Sandbox Built an Automated Data Center Network in Less than 6 Months – DEVNET-1488. If you’ll be in Barcelona, please register and join me for a look at how we approached this project with a goal to “innovate up to the point of panic” and brought in a lot of new NetDevOps and network automation processes.  But don’t worry if you’re reading this from far off in the future, or aren’t attending CLEUR, this blog will still be wildly entertaining and useful!

Today’s blog I want to build on those by showing where the details that provide the INPUT to the automation comes from – something often called the Source of Truth.

What is a Source of Truth?

If you’ve been kicking around the network automation space for awhile, you may have run across this term… or maybe you haven’t, so let me break it down for you.

Let’s say you are diving into a project to automate the interface configuration for your routers.  You’re going to need 2 things (well likely more than 2, but for this argument we’ll tackle 2).

First, you’ll need to develop the “code” that applies your desired standards for interface configuration.  This often includes building some configuration template and logic to apply that template to a device.  This code might be Python, Ansible, or some other tool/language.

Second, you need to know what interfaces need to be configured, and the specifics for each interface.  This often includes the interface name (ie Ethernet1/1), IP address info, descriptions, speed/duplex, switch port mode, and so on.  This information could be stored in a YAML file (a common case for Ansible), a CSV file, dictionaries and lists in Python, or somewhere else.

Then your code from the “first” will read in the details from the “second” to complete the project.

The “Source of Truth” is that second thing.  It is simply the details that are the desired state of the network.  Every project has a “Source of Truth”, even if you don’t think of it that way.  There are many different tools/formats that your source of truth might take.

Simple Sources of Truth include YAML and CSV files and are great for small projects and when you are first getting started with automation.  However, many engineers and organizations often find themselves reaching a point in their automation journey where these simple options are no longer meeting their needs.  It could be because of the sheer amount of data becomes unwieldy.  Or maybe it’s the relationships between different types of data.  Or it could be that the entire team just isn’t comfortable working in raw text for their information.

When text based options aren’t meeting the needs anymore, organizations might turn to more feature rich applications to act as their Source of Truth.  Applications like Data Center Infrastructure Management (DCIM) and IP Address Management (IPAM) can definitely fill the role of the Source of Truth.  But there is a key difference in using a DCIM/IPAM tool as an automation Source of Truth from how we’ve traditionally used them.

How a DCIM or IPAM becomes a Source of Truth

In the past (before automation), the data and information in these tools was often entered after a network was designed, built, and configured.  The DCIM and IPAM data was a “best effort” representation of the network typically done begrudgingly by engineers who were eager to move onto the next project.  And if we are honest with ourselves, we likely never trusted the data in there anyway.  The only real “Source of Truth” for how the network was configured was the actual network itself.  Want to know what the desired configuration for a particular switch was?  Well go log into it and look.

With Source of Truth driven network automation, we spin the old way on its head.  The first place details about the network are entered isn’t at the CLI for a router, but rather into the IPAM/DCIM tool.  Planning the IP addresses for each router interface – go update the Source of Truth.  Creating the list of VLANs for a particular site – go update the Source of Truth.  Adding a new network to an existing site – go update the Source of Truth.

The reason for the change is that the code you run to build the network configuration will read in the data for each specific device from the Source of Truth at execution time.  If the data isn’t in your DCIM/IPAM tool, then the automation can’t work.  Or if the data isn’t correct in the DCIM/IPAM tool, then the automation will generate incorrect configuration.

It’s also worth noting now that a Source of Truth can be used as part of network validation and health tests as well as for configuration.  Writing a network test case with pyATS and Genie to verify all your interfaces are configured correctly?  Well how do you know what is “correct”?  You’d read it from your Source of Truth.  I call that “Source of Truth driven Network Validation” and I’ll tackle it more specifically in a future blog post.

Source of Truth Driven Automation in Action!

Enough exposition, let’s see this in action.

The Source of Truth that we use in DevNet Sandbox for most information is Netbox.  Netbox is an open source DCIM/IPAM tool originally developed by the network automation team at Digital Ocean for their own needs, and has been popular with many engineers and enterprises looking for a tool of their own.

Let’s suppose we need to add a new network to our main internal admin environment in the Sandbox with the following basic information.

◉ The name of the network will be demo-sourceoftruth

◉ It will need an IP prefix assigned to it from the appropriate IP space

◉ Ethernet 1/3 on the switch sjcpp-leaf01-1 needs to be configured as an access port for this network

The automation to do the actual configuration of the VLAN, SVI, interface config, etc is already done, what I need to do is update the Source of Truth that will drive the automation. This involves the following steps:

1. Creating a new VLAN object

2. Allocating an available prefix and assigning to the new VLAN

3. Updating the details for port Ethernet 1/33 to be an access port on this VLAN

Note: You can click on the screen images that follow to enlarge for easier viewing.

Step 1: Creating a new VLAN object

I start in Netbox at the Tenant view for our Admin environment. From here I can easily view all the DCIM and IPAM details for this environment.

I click on VLANs to see the current list of VLANs.

The “Group” column represents the VLAN Group in Netbox – which is a way to organize VLANs that are part of the same switching domain where a particular VLAN id has significance.  This new network will be in the “Internal” group.  I click on “Internal” on any of the VLANs to quickly jump to that part of Netbox so I can find an available VLAN id to use.

I see that there are 4 VLANs available between 25 and 30, and I click on the green box to add a new on in that space.

I provide the new name for this network, and indicate it’s role will be for “Sandbox Systems”.  As this new network will be part of the Admin Tenant, I select the proper Group and Tenant from the drop downs.  Netbox supports creating custom fields for data that you need, and we’ve created a field called “Layer3 Enabled on Switched Fabric” to indicate whether SVIs should be setup for a network.  In this case that is True.  After providing the details, I click “Create” to create this new VLAN.

Step 2: Allocating an available prefix and assigning to the new VLAN

Netbox is a full featured IPAM, so let’s walkthrough allocating a prefix for the VLAN.

I start at the Supernet for admin networks at this site, 10.101.0.0/21 to find an available prefix.

I click on the Available range, to jump to the “Add a New Prefix” interface.

I start by updating the Prefix to be the proper size I want, picking the Role (this matches the VLAN role), providing a good description so folks know what this is for.  I then choose the new VLAN we just created to associate this prefix to using the drop downs and search options provided in the UI.  Lastly I pick the Admin tenant and click “Create”

Now if I go back and look at the VLANs associated with the Admin Tenant, I can see our new VLAN in the list with the Prefix allocated.

Step 3: Updating the details for port Ethernet 1/3 to be an access port on this VLAN

The final step in Netbox is to indicate the physical switch interfaces that will have devices connected to this new VLAN.

I navigate in Netbox to the device details page for the relevant switch.  At the bottom of the page are all the interfaces on the device.  I find interface Ethernet 1/3 and click the “Edit” button.

I update the interface configuration with an appropriate Description, set the 802.1Q Mode to Access, and select our new VLAN as the Untagged VLAN for the port.  Then click “Update” to save the changes.

Applying the New Network Configuration

With our Source of Truth now updated with the new network information, we simply need our network automation to read this data in and configure the network.  There are many ways this could be done, including a fully automated option where a webhook from Netbox kicks off the automation.  In our environment we are adopting network automation in stages as we build experience and confidence.  Our current status is that we execute the automation to process the data from the Source of Truth to update the network configuration manually.

When I run the automation to update the network configuration with the new Source of Truth info, here are the changes to the vlan-tenant configuration for our admin environment.

hapresto@nso1-preprod(config)# load merge nso_generated_configs/vlan-tenant_admin.xml

Loading.

1.78 KiB parsed in 0.00 sec (297.66 KiB/sec)

hapresto@nso1-preprod(config)# show configuration

vlan-tenant admin

  network demo-sourceoftruth

    vlanid 26

    network 10.101.1.0/28

    layer3-on-fabric true

    connections switch-pair sjcpp-leaf01

      interface 1/3

      description "Demonstration VLAN for Blog - Interface Config"

      mode access

Here you can see the new network being created, along with the VLAN id, prefix, and even the physical interface configurations.  All this detail was pulled directly from Netbox by our automation process.

And if you’d like to see the final network configuration that will be applied to the network after processing the templates in our network service by NSO, here it is.

    device {

        name sjcpp-leaf01-1

        data vlan 26

              name demo-sourceoftruth

             !

             interface Vlan26

              no shutdown

              vrf member admin

              ip address 10.101.1.2/28

              no ip redirects

              ip router ospf 1 area 0.0.0.0

              no ipv6 redirects

              hsrp version 2

              hsrp 1 ipv4

               ip 10.101.1.1

               preempt

               priority 110

              exit

             exit

             interface Ethernet1/3

              switchport mode access

              switchport access vlan 26

              no shutdown

              description Demonstration VLAN for Blog - Interface Config

              mtu 9216

             exit

    }

    device {

        name sjcpp-spine01-1

        data vlan 26

              name demo-sourceoftruth

             !

    }

Note: The service also updates vCenter to create a new port-group for the vlan, as well as Cisco UCS, but I’m only showing the typical network configuration here.

Finishing Up!

Hopefully this gives you a better idea about how a Source of Truth fits into network automation projects, and how a tool like Netbox provides this important feature for enterprises.

Continue reading

Spinning up an NVMe over Fibre Channel Strategy

Every so often there comes a time when we witness a major shift in the networking industry that fundamentally changes the landscape, including product portfolios and investment strategies. Storage Area Networking (SAN) is undergoing one such paradigm shift that opens up a huge opportunity for those looking to refresh their SAN investments and take advantage of the latest and greatest developments in this particular space. We can think of it as a “trifecta effect.”

In this blog, we’ll discuss the latest and greatest innovations driving the SAN industry and try to paint a picture of how the SAN landscape will look five to seven years down the road, while focusing on asking the right questions prior to that critical investment. Following this, we will be posting additional blogs that will dig deeper into each of the technological advancements; but it helps to understand the bigger picture and the Cisco point of view, which we will cover here.

Why Now?

Modern enterprise applications are exerting tremendous pressure on your SAN infrastructure. Keeping up with the trends, customers are looking to invest in higher performing storage and storage networking. Combining the economic viability of All Flash Arrays and the technological advancements with NVMe over FC, there has never been a more compelling opportunity to upgrade your SAN infrastructure with investment protection and support for 64G Fibre Channel Performance.

But before we think about refreshing our SAN, we have to ask few questions ourselves:

◉ Does it support NVMe?
◉ Is it 64Gb FC ready?
◉ Do we get any sort of deep packet visibility, a.k.a SAN analytics, for monitoring, diagnostics, and troubleshooting?
◉ Do we really need to “RIPlace” our existing infrastructure?

We will elaborate more on above questions one by one in a this series of blogs.

Today, we’re going to talk about NVMe array support over FC using Cisco MDS 9000 series switches, and get to the bottom of why NVMe is so important, why there is so much excitement around NVMe, and why everyone is (storage vendors and customers) eager to implement NVMe.

NVMe has superseeded rotating/spinning disks. So with no more rotating motors or moving heads, everything is in the form of Non-Volatime Memory (NVM) based storage. This results in extremely high reads and writes. Using built-in multi-core, multi-threaded CPUs, and PCI 3.0 bus provides extreme high, low latency thoughput.

Does Cisco’s SAN solution have support for NVMe/FC?

This is a very common and top-of-mind question from customers during conversations on roadmap, feature set, or for that matter any discussion involving SAN. The good news on Cisco MDS SAN solution is – yes, we do support NVMe/FC. We support it transparently – no additional hardware/commands needed to enable it. Any current 16G/32G Cisco MDS 9700 module or any current selling 16G/32G FC fabric switch using new NX-OS 8.x release supports it. There is no additional license needed, no additional features to enable identification of NVMe commands. Cisco MDS 9000 can unleash the performance of NVMe arrays over FC or FCoE transport, connected to SCSI or NVMe initiators or targets, concurrently, across the same SAN.

Vendor Certification

From the Ecosystem support perspective, we have certified Broadcom, Emulex, Cavium and Qlogic HBAs, along with Cisco UCS C-Series servers. We have also published a Cisco validated design guide with NVMe solution which are listed at the end of the blog.

We can run SCSI and NVMe flows together through the same hardware, through the same ISL (Inter Switch Link) and Cisco MDS switches will transparently allow successful registrations and logins with NVMe Name Servers as well as I/O exchanges between SCSI and NVMe initiators and targets, together.

This way, NVMe/FC, along with Cisco MDS SAN solution provides the best possible performance across the SAN with seamless insertion of NVMe storage arrays in the existing ecosystem of MDS hardware.

NVMe/FC Support Matrix with MDS 

If you are looking for NVMe/FC and MDS integration within CVDs, here are some of the documents for you to start with:

1. Unleash the power of flash storage using Cisco UCS, Nexus, and MDS
2. FlashStack Virtual Server Infrastructure Design Guide for VMware vSphere 6.0 U2
3. Cisco UCS Integrated Infrastructure for SAP HANA
4. FlashStack Data Center with Oracle RAC 12cR2 Database
5. Cisco and Hitachi Adaptive Solutions for Converged Infrastructure Design Guide
6. VersaStack with VMware vSphere 6.7, Cisco UCS 4th Generation Fabric, and IBM FS9100 NVMe-accelerated Storage Design Guide

So, what are we waiting for? Probably nothing. The roads are ready, just get the drivers and cars on this road to make it Formula one racing track…

Continue reading