Remote Working: Endpoints Have Left the Building

Got DNS?

So, my first answer to address this challenge often surprises them; does your agency have DNS for your remote workforce? Talking it over, most agree that many remote employees consume web and cloud applications without turning on their VPN. This means that roaming users will likely be at the mercy of a random, unknown DNS provider. Why would anyone accept this risk?

Enhancing your agency’s endpoints with DNS security should be a no-brainer. Cisco Umbrella Roaming protects employees when they are off the enterprise VPN by:

◉ Blocking malicious domain requests and IP responses while DNS queries are resolved

◉ Enforcing security at the DNS-layer so malicious connections cannot be established and malicious files will not be downloaded

◉ Preventing malware from infecting laptops and command & control (C2) callbacks, or phishing from exfiltrating data over any port

◉ Plus, any infected laptop that exhibits any C2 activity can be immediately identified.

Hence, with an integrated, security-minded approach to DNS, Cisco Umbrella protects users from malicious Internet destinations whether they are on the enterprise VPN or roaming off the network. Delivered from the cloud, Umbrella makes it easy to protect users everywhere in minutes – without any performance degradation. Even better, Umbrella Roaming is fully integrated into AnyConnect client for Windows or Mac OS X.

How to secure endpoint access

After my friends pull me down off my soapbox about needing DNS for your remote workforce, our discussion changes to what you should expect from your VPN. It’s one thing for a VPN to simply enable an employee to work outside the office and provide the means to securely connect to the corporate network. However, any modern, security-minded VPN should enable a wide range of security services—to include functions such as remote access, posture enforcement, web security features, and roaming protection.

For government customers whose endpoints must maintain a level of posture compliancy, advances in VPN technology now enable security checks to be conducted on endpoints to ensure they meet posture requirements before connecting to the enterprise.

In the context of Department of Defense (DoD) Comply-to-Connect (C2C) efforts, I have previously discussed the need to think “bigger picture” in terms of adopting a Zero Trust lifestyle. Much more than a VPN, Cisco AnyConnect VPN Client, among its security capabilities, contains an endpoint compliance module that includes significant functionality essential to Federal C2C efforts and taking a Zero Trust approach. The Federal government can take advantage of a Remote Access VPN that enables the very foundation of C2C endpoint compliance and an essential Zero Trust capability via the same desktop application.

Simply put, far more than a VPN, Cisco AnyConnect Secure Mobility Client empowers remote working from anywhere on government laptops or mobile devices; whether connected to the enterprise or when needing roaming DNS protection. It also provides visibility and control for Federal agency enterprise operators and security teams to identify who (what devices and the compliance status of those devices) is accessing the enterprise infrastructure.

Remote working needs multi-factor authentication

It almost goes without saying, but multi-factor authentication is a must these days, especially for remote working. It is a must to verify the identity of all users with effective, strong authentication (two-factor authentication) before granting access to your agency’s enterprise VPN, applications and data resources.

Duo Security enables agencies to verify users’ identities and establish device trust before granting access to applications and data. By employing a Zero Trust model, Duo decreases the attack surface and reduces risk by helping to define and enforce policies that limit access to the users and devices according to a Federal agency’s risk tolerance levels.

Cybersecurity for remote working

Although it may sound daunting, when it comes to remote working, Federal agencies must be able to defend against threats, no matter where they are and no matter where their employees are working. This can be done using:

◉ Duo’s adaptive multi-factor authentication (MFA) provides the means for verifying user identities in order to gain secure remote access

◉ Cisco Umbrella Roaming, extends protection when employees are roaming off the enterprise VPN

◉ Integrated with Cisco AnyConnect Secure Mobility Client, employees can not only securely access enterprise resources, but network security teams can also prevent noncompliant devices from accessing the network in accordance with C2C Policy and according to a Zero Trust lifestyle.

Continue reading

Cisco Announces Kubeflow Starter Pack

Recently the Kubeflow Community released Kubeflow 1.0. Kubeflow brings together features such as TensorFlow, PyTorch, and other machine learning capabilities into a cohesive tool – from data ingestion to inferencing. Cisco is one of the top contributors to Kubeflow, helping to make operationalizing machine learning for large scale deployments easier for everyone. As a result, we are announcing Cisco Kubeflow Starter Pack.

Here are are the major components of Kubeflow 1.0:

Jupyter Notebook

Many data science teams live on Jupyter notebook since it allows them to collaborate and share their projects, with multi-tenant support. Personally, I use it to develop Python code because I like its ability to single step my code, with immediate results. Within the data science context, Jupyter becomes the primary user interface for data scientists, machine learning engineers.

TensorFlow and Other Deep Learning Frameworks

Originally designed to only support TensorFlow, Kubeflow version 1.0 now supports other deep learning frameworks, including PyTorch. These are two of the leading deep learning frameworks that customers are asking about today.

Model Serving

Once a machine learning model is created, the data science team often must create an application or web page to feed new data and execute the trained model.  With Kubeflow, there are built-in capabilities with TFServing enabling models to be used without worrying about the detailed logistics of a custom application.  As you can see in the screen shot below, the data pipeline enables data model to be served.  In fact, the model can be called through a URL.

Kubeflow Data Pipeline. Note the Deploy Stage for Trained Model Serving

Kubeflow Model Serving. Note the “Service endpoint” URL where the trained model can be accessed

Other Components

There are many other components to Kubeflow, including integration with other open source projects that enable more advanced model inferencing, such as Seldon Core. The Kubeflow Pipelines platform, currently in beta, allows users to define a machine learning workflow from data ingestion through training and inferencing.

As you can see, Kubeflow is an open source integrated tool chain for data science teams.  At the same time, Kubeflow enables the IT team to manage the infrastructure for the resulting data pipeline.

Cisco Kubeflow Starter Pack

To enable IT teams to work more closely with their data science counterparts, Cisco is introducing the Cisco Kubeflow Starter Pack, which provides IT teams with a baseline set of tools to get started with Kubeflow. The Cisco Kubeflow Starter Pack includes:

     ◉ Kubeflow Installer: Deploys Kubeflow on Cisco UCS and HyperFlex

     ◉ Kubeflow Ready Checker: Checks the system requirements for Kubeflow deployment. It also checks whether the particular prescribed Kubernetes distribution is able to support Kubeflow.

     ◉ Sample Kubeflow Data Pipelines: Cisco will be releasing multiple Kubeflow pipelines to provide data science teams working Kubeflow use cases for them to experiment with and enhance.

     ◉ Cisco Kubeflow Community Support:  Cisco will be providing free community support for Cisco customers who would like to check out Kubeflow.

Continue reading

Simplify Multi-domain Automation with Cisco Action Orchestrator

I’ve been working in software development/IT/technology my entire 17-year career. Time and time again I’m confronted with what ends up being the same challenge: how do I/we cobble together different pieces of software, platforms, and/or functionality to build one cohesive and observable solution.

Piecing solutions together

My first development job out of school was with a mortgage origination software company.  We provided custom installations depending on how your bank did business.  To provide viable tools for our bank customers to use, we had to piece together credit reporting, payment, and government regulation systems all onto our platform.

A few years later, I had a similar experience at a hospital billing software firm.  In this instance, we had to manage connections from scanned OCR documents, Medicare, insurance billing, and mainframe hospital systems. (The software that interacted with the mainframe emulators was SO COOL!)  These fed into a common billing database that took into account the incongruencies of all of those systems.

Finally, I’ve come across this same kind of challenge at least a half dozen times in my career here at Cisco!  Likely we all have, whether we realize or not. Because that’s what IT solutions (hardware and/or software) really are.

A multi-domain solution consolidates deployments

That brings us to the concept of Multi-domain solutions.  Cisco products cover enterprise/campus, data center, security, and WAN.  Depending on the need, these products are deployed individually or as a combination for a larger solution.  Organizations then choose to manage these deployments via the device, the controller GUI, or API.  A multi-domain solution consolidates these deployments “as one.” This offers the capability of provisioning and configuring all necessary components of the solution.

The Scenario

Consider we have a number of retail branches being set up and a centralized data center.  The POS system at each branch needs secure access to the datacenter price list.  In addition, there is a need for a local network at the sites, requiring wireless access over a standardized SSID.  Finally, a local web server and ad server is required for advertisement.  This scenario is ripe for a multi-domain solution.

First, let’s look at access to the data center.  This is achieved through Cisco SD-WAN (or Cisco Meraki), and makes each added branch device part of the organization’s WAN.  Next, we provision wireless networking devices at the branches through Cisco DNA Center (or Cisco Meraki). This provides our local network SSID.  Finally, we deploy our branch host servers via Cisco UCS and manage their application connectivity via Cisco ACI.  Now, we could deploy and provision all of these elements for each branch manually through various GUIs for each platform. But why? There is a better way!

Multi-Domain Automation with Cisco Action Orchestrator

All of the platforms mentioned above have robust APIs as part of their platforms.  This allows for applications and scripts to be written to automate repeatable tasks.  Now, a network automation engineer may take a look at this problem and think, “well, I could script all of this out in Python using REST APIs. Or maybe Ansible would be a good solution.”  Those would both be valid tactics. But they could take some time to develop, and come with a list of requirements. This is where Cisco Action Orchestrator can help.

Cisco Action Orchestrator saves time and effort in automation tasks

Cisco Action Orchestrator (CAO) allows a network automation engineer to create individual tasks, like making calls to REST APIs, that can be linked together to repeatedly perform complex linear and parallel workflows.  In our example, tasks can be created to call Cisco SD-WAN vManage API. And when that completes (or in parallel) the task to call Cisco DNA Center intent APIs to setup wireless networks is triggered.  We can also implement messages to platforms like Webex Teams for monitoring the success of the tasks and workflows.  CAO abstracts the necessity of writing code or YAML from scratch and lets you focus on building the solution.

Continue reading

How To Make 100G Pluggable Optics In Massive Volume

We’ve been talking about Single-Lambda 100G and why it’s so important for the next generation of 100G pluggable optics. I use the term “pluggable optics” because even though 100G is all about the QSFP28 form factor these days, the next generation should be an SFP of some sort.

Let’s back up a little and get back to where the previous post left off. We said that we’re working toward the vision of simpler 100G pluggable optics. And to facilitate that, we’re using PAM4 modulation so that we can get by with only one laser instead of four, and therefore one wavelength (a.k.a. “lambda”), to carry a full 100Gb/s stream of data.

Why is it important to minimize the components in the module? Consider the diagram in Figure 1. It shows what goes into today’s 100G QSFP28 pluggable optical modules. Notice that they are inherently four-channel devices, both in the optical interface facing right, and the electrical interface facing left. Each of the four channels carries 25G of NRZ data, for a total of 100G.

Figure 1. Block diagram and application of a typical 100G QSFP28 transceiver for duplex SMF.

Compare this with the diagram in Figure 2, a typical 10G SFP+ transceiver. It’s pretty simple. There is only one lane that carries 10G of data. There is typically only a laser, a photodiode, and simple driver circuits for optical-to-electrical and electrical-to-optical conversion. This simplicity is key to why manufacturers are able to make 20 million 10G SFP+ modules per year.

Figure 2. Block diagram and application of a typical 10G SFP+ pluggable transceiver module.

Eventually, when 100G SerDes (serializer – deserializer) is available on switch and router ports, the ASIC behind the ports can take over the FEC (Forward Error Correction) and PAM4 (Pulse Amplitude Modulation with 4 levels) functionality, leaving the pluggable module to perform only the optical-to-electrical and electrical-to-optical conversion. Then we could increase faceplate bandwidth density by using the smaller SFP form factor, with a single 100G lane on the electrical side that interfaces with the switch or router port. This form factor will likely be called SFP112 (Figure 3). Note that the block diagrams in Figures 2 and 3 look nearly the same.

Figure 3. Block diagram and application of a future 100G SFP pluggable transceiver module. It will likely be called SFP112.

We’re not there yet, though. In the meantime, we have QSFP28 modules that perform the FEC and PAM4 inside the module, as well as convert the electrical 4x25G lanes to the single 100G lane. This is what happens in our recently released QSFP28 100G FR module. The benefit of adopting this QSFP28 now is that when the SFP112 becomes available, today’s switches and routers using QSFP28 modules will interoperate with the future ones that accept SFP112 modules. And there won’t be any need for 4x25G-to-100G conversion because both the electrical interface and the optical signal will be single-lane 100G. This forward compatibility is highly advantageous for network upgrade strategies, as it prevents your existing QSFP28 modules from becoming obsolete as you add new SFP112-based hardware.

Continue reading

AI for Networking: Separating the Hype from Reality

Networks support explosive growth in traffic volume, connected mobile and IoT devices, and interconnected applications and microservices needed to deliver required services. Today’s networks generate massive amounts of data that exceed the ability of human operators to manage, much less understand.

With unprecedented increases in network complexity and scale, AI is no longer just “a nice to have” – it is becoming essential to helping NetOps teams maintain service and network assurance. Network strategists already know this: More than 50% identify AI as a priority investment needed to deliver their ideal network.

AI: What can’t it do?

However, there are also a lot of over-blown expectations. As the engineering lead on AI for networking at Cisco, I often find myself in conversations about very futuristic, and somewhat unrealistic AI-enabled scenarios. It can be quite entertaining – but we also need to remember that today’s AI technology is not a panacea for every networking ailment.

For now, and for the next few years, AI will only help fully automate a limited set of straightforward use cases. In most cases, that require more complex and flexible analysis, AI will simply help human operators make quantifiably better and faster decisions.

AI: What can it do?

So, what can AI help us do today? One of the most common AI techniques, machine learning (ML) offers unique capabilities that operators can use to assure required network performance.

ML algorithms are certainly very powerful, but they also have a reputation of being difficult to design, tune, and adapt to a variety of situations and sometimes have been known to produce results that may be difficult to interpret.

With Cisco AI Network Analytics, we have created a learning platform that solves issues where ML provides an indisputable and impactful benefit for network operators over existing technologies and approaches. This is possible thanks to the combination of two factors: (1) decades of experience in building some the world’s largest and most advanced networks and (2) deep expertise in ML algorithms that can effectively process networking data.

AI and ML have some useful applications

Let’s look at one of the more useful ML use cases – complex event processing. When applying ML to network telemetry, it is possible to establish dynamic baselines of what constitutes normal operating conditions for a given intent.

For example, the ML model(s) may be used to predict what should be the lower-upper bounds for a given KPI, for example, Wi-Fi on-boarding times. On-boarding refers to the set of complex tasks triggered when a wireless client attempts to join a wireless network.  Joining a network successfully and seamlessly contributes significantly to the Quality of Experience for the end user. Being able to monitor such complex, multidimensional KPIs so as to detect abnormal onboarding times, along with determining potential root causes should an issue occur, is a fundamental task for IT teams.

In this instance, Machine Learning (ML) allows for computing models used to predict the upper and lower bounds of the KPIs for on-boarding. KPIs falling outside a prediction as provided by the ML model would be considered “abnormal” for that unique network involved, and thus would be candidates for raising an alarm (that is, an alarm based on a learned bound, not based on a static value).

The figure below shows a predicted “band” (shown in green) of normal values for the percentage of failed onboarding sessions. As we can see, at some point the percentage of failed onboarding sessions (blue line) became abnormal (falling outside the green band), considering a number of network variables involved, as analyzed by the ML algorithm in use. This departure from normal to abnormal behavior for this network is denoted by the red section of the time-line in the diagram shown.

Predicted range of normal values for the percentage of failed onboarding sessions

A second ML use case that has a lot of potential is correlated insights. ML can provide deeper insights and visibility into the operation of the network and even help predict when an anomalous condition is likely to occur in the future.

A third important use case would be root-causing. In some cases, an ML algorithm may be able to detect anomalies with associated root causing, whereas in other situations more than one ML algorithm may be used in conjunction with anomaly detection to provide root causing.

IBN and AI as disrupters

AI and advanced networking technologies like IBN are disrupting how things are done, especially for networking operations. Testing of new applications can be done in minutes instead of weeks. Troubleshooting gets significantly easier when an assurance engine identifies root causes and recommends fixes. In fact, when armed with powerful dashboards that offer actionable insights, a future network operator may only need to look in a handful of places, as opposed to plowing through heaps of possible causes.

The intent-based networking (IBN) vision is that network teams will simply define the required behavior, and the network will know how to continuously align itself with what the business needs.

Continue reading

How to quickly capture share of the SD-WAN Managed Services market

Early in the 21st century, the subject of applications being delivered across the WAN was being researched.  It took more than 10 years for computing power to increase sufficiently to support analysis of the network traffic in order to make informed decisions in real-time.  This increase enables support of an overlay network that could function as traditional WAN did – but at a much lower cost. In 2014, the term software-defined WAN, or SD-WAN, was being used to describe this overlay network.

The benefits to customers of SD-WAN are significant, but the opportunity for solution partners of all types is vast and profitable. For some partners, providing a managed service for SD-WAN is new territory and they currently don’t have the depth of knowledge on SD-WAN implementations –  and customers may select competing partners that tout more expertise in the service.  A lost opportunity isn’t just the SD-WAN service, it’s also complementary services that can be provided by the service provider.

Just having enough expertise to implement an SD-WAN infrastructure for a customer is not enough.  You need the capacity to deliver and maintain connectivity to applications over the WAN – often to one or more clouds.  With Over-the-Top (OTT) services consuming greater bandwidth, adjusting for the ebbs and flows of business can become a challenge in providing the Application Quality of Experience (AppQoE) your customers need in a multicloud world.

SD-WAN Delivery Models

There are 4 main delivery models for SD-WAN:

1. Re-sell – it’s still the most common in the market. However, the market is changing from large Enterprises buying SD-WAN appliances using CapEx funds and attempting to implement it themselves to one that extends down-market, uses an OpEx model and is managed by a service provider.

Managed Services Practice Models

2. Build – Offering SD-WAN bundled with additional professional services and network connectivity options. The service providers build the SD-WAN infrastructure to a customer’s requirements and provides services for that customer.  This option has the longest ‘time to market’.

3. Co-deliver – This model involves a partner working with an SD-WAN vendor. Partnering with Cisco expands the technical workforce capabilities.  It has a slightly faster time to market than the ‘Build’ model.

4. “As A Service” – This model is based on consumption and addresses the complete lifecycle of deployment. A service provider or system integrator engages a company such as ngena (net) who offers the complete SD-WAN infrastructure, full lifecycle expertise, and flexible options to ensure successful deployments.  This model has some unique benefits for both customers and partners and is our focus for the rest of this discussion.

Let’s say you are a strictly SD-WAN resell partner today and want to take advantage of profitable opportunities delivering managed services for SD-WAN.  You’ll need a Business and Go-to-market plan, you need SD-WAN expertise and the understanding of how OTT services will impact the customer. You need to build out capacity to deliver and support the infrastructure, you will need new billing models, and you will need to implement consumption tracking.  In this fast-moving market, the service offering build-out time could negatively impact your market share, ability to expand service offerings and capture new recurring revenue streams.  Creating new services requires a significant investment in time and resources to develop and can be fraught with risks.

Working with an “As A Service” Partner

Providers can partner with ngena for faster design and implementation, ability to leverage a scalable portfolio of solutions built on Cisco’s SD-WAN products, have confidence in a future proof delivery model, and leverage white label deployments.

Here’s an analogy: You are building a home for a client.  You are the general contractor.  Maybe you have some skills in electrical work too – maybe enough to do the work yourself, but that will take time from you overseeing the rest of the project and keeping to a delivery date.  As the general contractor, you hire an electrician to wire everything up.  The electrician is ngena.  You get expertise and confidence the work will be done correctly – and you save time and get to focus on what you need to focus on.

Partnering with ngena, you are ready to sell now, and it provides the consumption model that allows you to build Monthly Recurring Revenue (MRR) streams.  ngena offers wholesale prices to partners with zero CapEx investment which provides an incremental margin opportunity.  The ngena offering is a Cisco SD-WAN solution which provides a predictable application experience (AppQoE), and security that is built-in to provide secure segmentation across the entire network stack.  Cisco’s SD-WAN is enterprise-grade and provides intent-based networking with multi-domain policy.  CRN honored Cisco SD-WAN with the SD-WAN Product of the Year award for 2019.

ngena delivers the service through a single portal with worldwide orchestrated operations featuring pre-defined services, intelligent automation and predictive analytics, and is DevOps ready.  They offer a global presence through dedicated global infrastructure, backbone and the ability to take care of local loop connectivity as well.  Full lifecycle management enables scalability to address the needs of any migration.

Interested in quick GTM and expanding your service offerings?  ngena provides a global end-to-end managed platform that is truly unique in the industry – delivering secure SD-WANaaS for any category of partner.  Regardless if your scope is just your domestic market or serving international markets, ngena provides that coverage.

Continue reading

What do ‘Owning Your Edge’ and ‘Customer Experience’ have in common?

It’s not easy to be in the resell and network integration business. For decades, our partners have been wrestling each other for differentiation and relevance in a crowded and unforgiving landscape. We often ask partners “Why do customers buy from you?”, and while the answers vary, they are often predictable, generic, and unconvincing. “We have the greatest engineers” or “We have amazing customer relationships and we do whatever it takes to support them.”

How do partners recognize their differentiation, define their uniqueness and own their edge?

At Cisco Partner Summit 2019, Oliver Tuszik displayed a picture of himself next to a monkey and declared (to the audience’s laughter) that although 99% of their DNA is shared, they are very different indeed. One is relaxed and eating a banana, while the other has an accelerated heart rate and is on stage presenting to 3,000 people. Although the DNA differences are very small, those differences are extremely significant, and a great illustration of what it means to have an edge. The Cisco Partner Consulting & Innovation team has worked with countless partners to help them realize just that. We’ve utilized our Unique Value Proposition (UVP) workshops to help many partners define their edge. For some, their edge is clearly understood, but most struggle with defining and communicating it.

So, what does that have to do with Customer Experience (CX)?

To understand a partner’s edge, it’s important to identify their strengths and align these strengths to what their customers care about. At the heart of it all is the challenge of quantifying how they provide a complete lifecycle experience to their customers. Understanding the technology, managing the product/service/software ordering and billing process are not easy but they are table stakes to be in this business. This, by no means, is an attempt at trivializing these functions. For some partners, their edge is their ability to address fulfillment faster, easier, and cheaper.

For most partners, the opportunity to differentiate happens after landing the deal. Their edge is in how they interact with the customer to implement and adopt the technology purchased. Their edge is demonstrated as they ensure that the customer maximizes the return on the investment they made, and it’s defined in the partner’s ability to manage risk and proactively help the customer achieve their business goals. These lifecycle activities are not new to our partners. It’s in these areas where they can enjoy the margin-rich professional services and managed services they possess. Partners generate (on average) 15% margin with their resell business, but they obtain upwards of 30% margin on their partner-branded and delivered service(s).

For many years, partners have honed their customer relationships so they can build upon the stickiness that post-sales activities promise. Cisco CX defines the steps that partners have followed intuitively for decades. CX identifies the lifecycle milestones and defines the steps for true adoption – where customers are choosing, using, and loving Cisco. It provides the process for systematic execution and holds the promise of automation to lead to the seamless renewal stage. CX also enables the lifecycle and demonstrates to our partners that we not only understand how they define their edge, but we now speak the same language, and lead together. As one partner executive told me at Partner Summit – “Cisco finally understands our world.”

CX fuels the lifecycle that partners embrace to own their edge.

Continue reading