Your Network, Your Way: A Journey to Full Cloud Management of Cisco Catalyst Products

At Cisco Live 2022 in Las Vegas, Nevada (June 12-16), there were many announcements about our newest innovations to power the new era of hybrid workspace, distributed network environments and the customers journey to the cloud. Among the revelations was our strategy to accelerate our customers transition to a cloud-managed networking experience.

Our customers asked, and we answered: Cisco announced that Catalyst customers can choose the operational model that best fits their needs: Cloud Management/Monitoring through the Meraki Dashboard or On-Prem/Public/Private Cloud with Cisco DNA Center.

Figure 1: Bringing together the best of both worlds

Note: This article heavily references the following terms:

◉ DNA Mode and Meraki Mode for Catalyst: DNA Mode is a Catalyst device using a DNA license with DNA features and Meraki Mode is a Catalyst device using a Meraki license with Meraki features.

◉ Monitor and Manage: Cloud Monitoring allows Catalyst devices to have visibility and troubleshooting tools via the Meraki dashboard, while Cloud Management for Catalyst means complete feature parity with Meraki solutions.

So WHY THIS and WHY NOW?

Our Catalyst technology remains the most powerful campus and branch networking platform and fastest growing product on the market. Also, Meraki dashboard continues to be the simplest cloud management platform, with the highest adoption and deployment on the market. How can we bring things together and give our customers the best of both worlds? Enter Cloud Management and Monitoring for Catalyst. Simplicity without compromising.

And HOW to get started?

Today we have an on-premises management offering through Cisco DNA Center, which is a do-it-yourself high-touch approach. There are now two ways to implement this: in addition to existing Cisco DNA Center physical appliances that come in multiple sizes and flavors, we announced at Cisco Live the Cisco DNA Center Virtual Appliance, which runs as VMware ESXi instances in private data centers or as a virtual machine in public cloud platforms starting with AWS.

We also have Cisco Meraki Cloud Management which provides low touch, and simplicity as Meraki’s slogan’s: Simplicity at Meraki stands for everything from how we approach product development to user experience.

Executing a Cloud Ready Strategy

Cloud Management: Common Hardware Platforms

Figure 2: Delivering the Next Generation of Networking

On the wired network side, Cisco is focusing on our fixed switching portfolio in the Cisco Catalyst 9000 series switches. We announced that starting with the Cisco Catalyst 9300 series switches they will be common hardware and operate in either DNA or Meraki mode. A Cisco Catalyst 9300 switch can be migrated from DNA Mode to Meraki Mode and fully managed by the Meraki Dashboard. While the Meraki mode of the Catalyst 9300 can be migrated back to the DNA Mode, the Meraki MS390 cannot be migrated to a DNA mode of operation.

On the wireless network side, we also announced the first common hardware Access Points, the new Cisco Catalyst 916x Series Wi-Fi 6E Access Points. Those Access Points are built with dual modes: they are capable of booting in either Meraki or DNA modes. That means a Catalyst 916x Access Point can appear on the network as either a Meraki device or a Cisco DNA device, with all the associated monitoring and management capabilities inherent in each platform. The demo goes into detail.

Cloud Migration Details

◉ Cisco IOS-XE 17.8.1 version (or later) is required for the Cisco Catalyst 9300 switch to be migrated to Meraki Mode and managed by the Meraki Dashboard.

◉ The catalyst switch or access point when put in the Meraki mode of operations, their features align with what is available in the Meraki Dashboard. For example, the Cisco Catalyst 9300 switch in Meraki Mode is aligned with the switching features available for the Cisco Meraki MS390.

◉ You can migrate a standalone or a stack of Cisco Catalyst 9300 switches to Meraki Mode.

◉ Currently, you cannot stack the migrated Cisco Catalyst 9300 with Cisco Meraki MS390.

◉ Like native Meraki devices, once a Catalyst switch or AP is in Meraki Mode, the CLI access is 

unavailable.

◉ Managed devices display their software version as Meraki MS, just like native Meraki devices.

◉ Current supported switching platforms are Cisco Catalyst C9300-24T, C9300-48T, C9300-24P, C9300-48P, C9300-24U, C9300-48U, C9300-24UX, C9300-48UXM, C9300-48UN.

◉ Currently supported modules are C9300-NM-8X, C9300-NM-2Q, C3850-NM-4X.

◉ Current supported Cisco Catalyst Access Points are the Wi-Fi 6E CW APs (9162, 9164 and 9166).

Figure 3: The Migration Process from Cisco Catalyst 9300 DNA Mode to Meraki Mode

Cloud Monitoring: Existing Cisco Catalyst 9000 fixed switches 

Starting with IOS-XE 17.3.4, Cisco Catalyst 9200, 9300 and 9500 series switches in DNA mode with a valid DNA license (Essentials or Advantage) can be added to the Meraki dashboard for monitoring and troubleshooting, providing a single pane of glass and centralized network monitoring, network device visibility, usage, topology. The Meraki dashboard also allows the ability to see alerts, port information and use of diagnostic tools, all in one place.

Figure 4: Cloud Monitoring for Catalyst

Cloud Monitoring Details

◉ Catalyst Switches in DNA mode and with a valid DNA license (single or in a stack) can be monitored via the Meraki dashboard.

◉ Once claimed in the Meraki Dashboard, the switches will be automatically tagged with “Monitor Only” in the dashboard to distinguish from fully managed Meraki switches. Aside from this difference, “Monitor Only” Catalyst switches have visibility similarly to Meraki MS switches in the dashboard, including a visual representation of connected ports and traffic information.

◉ The Meraki Dashboard displays two serial numbers in the inventory of each catalyst device. Similar to migrated Catalyst switches, all switches in monitor mode keep a Catalyst Serial Number and generate a Meraki serial number which both appear in the dashboard to help identify switches.

◉ Monitor-only devices display their software version as IOS-XE. The device is still in DNA Mode which means that the CLI is still enabled, and other DNA features are available.

◉ For monitor-only devices, other management tools can still be used to make changes to devices such as Ansible, CLI, GUI, etc.

◉ Current supported switching platforms are Cisco Catalyst 9200, 9300 and 9500 series. Other platforms are under consideration.

◉ The process to onboard Cisco Catalyst switches for monitoring is done through a guided process using the Meraki onboarding app for Mac, Windows or Linux.

Figure 5. Cloud Monitoring Capabilities

License Flexibility

Our Licensing Team has been working hard to ensure a smooth transition between Modes (DNA and Meraki) from the licensing perspective.

For the common hardware perspective, to migrate the Cisco Catalyst 9300 switch to a Meraki mode, a valid DNA license is required. You can choose between Meraki Enterprise or Advanced license depending upon enabled features during license renewal.

The Cisco Catalyst 916x series APs can be purchased with the appropriate licenses based on the management platform: DNA license for Cisco DNA Center or Meraki license for Meraki mode.

On the visibility/monitoring front: A valid DNA Essentials (for switch visibility) or Advantage license (client visibility) is required to be onboarded into the Meraki dashboard. The device can be managed by other tools such as Cisco Prime, CLI or 3rd party tools.

Customer Use Cases

Cloud Monitoring

◉ Catalyst customers not using Cisco DNA Center as the operational platform: You will be able to gain immediate value with cloud monitoring, providing a view of your network from anywhere, anytime, giving them a low-effort way to experience Meraki Cloud Dashboard.

◉ Customers who are running a hybrid network of Meraki and Catalyst: Benefit by moving their Catalyst hardware into view on the Meraki dashboard with monitoring.

Cloud Management

◉ Customers with network refresh network: Customers who already have Meraki platforms; upon refresh, they can choose to adopt Catalyst into their existing infrastructure (APs and switches)

◉ Current Cisco Catalyst 9300 customers looking to move to cloud operations and the features available in the Meraki Dashboard satisfy their use cases.

Cisco DNA Center Physical/Virtual Appliance

◉ Customers using DNA features with Air gapped or Compliance requirements

◉ Customers using DNA features and require a Public or Private Cloud deployment

◉ Customers with requirements for on-premise management platform

Why this is important?

The benefits are endless

Customers now have the operational flexibility to choose either Meraki dashboard or Cisco DNA Center for the Cisco Catalyst family, providing extensive monitoring and management capabilities while enabling the choice as to where the services are running—on-premises or in the cloud—depending on operational needs, geography, and regional data regulations.

For example, financial organizations that require air-gap protection from internet traffic can utilize an on-premises Cisco DNA Center appliance while a distributed organization that needs to support high-speed Wi-Fi access at retail outlets, branch offices, or emergency popup sites, can deploy the new Cisco Catalyst Wi-Fi 6E Access Points and manage them from the cloud-first Meraki dashboard to simplify remote operations.

Source: cisco.com

Continue reading

Perspectives on the Future of Service Provider Networking: Distributed Data Centers and Edge Services

The ongoing global pandemic, now approaching its third year, has profoundly illustrated the critical role of the internet in society, changing the way we work, live, play, and learn. This role will continue to expand as digital transformation becomes even more pervasive. However, connecting more users, devices, applications, content, and data with one another is only one dimension to this expansion.

Another is the new and emerging types of digital experiences such as cloud gaming, augmented reality/virtual reality (AR/VR), telesurgery using robotic assistance, autonomous vehicles, intelligent kiosks, and Internet of Things (IoT)-based smart cities/communities/homes. These emerging digital experiences are more interactive, bandwidth-hungry, latency-sensitive, and they generate massive amounts of data useful for valuable analytics. Hence, the performance of public and private networks will be progressively important for delivering superior digital experiences.

Network performance, however, is increasingly dependent on the complex internet topology that’s evolving from a network of networks to a network of data centers. Data centers are generally where applications, content, and data are hosted as workloads using compute, storage, and networking infrastructure. Data centers may be deployed on private premises, at colocation facilities, in the public cloud, or in a virtual private cloud and each may connect to the public internet, a private network, or both. Regardless, service providers, including but not limited to communication service providers (CSPs) that provide network connectivity services, carrier neutral providers that offer colocation/data center services, cloud providers that deliver cloud services, content providers that supply content distribution services, and software-as-a-service (SaaS) application providers all play a vital role in both digital experiences and network performance. However, each service provider can only control the performance of its own network and associated on-net infrastructure and not anything outside of its network infrastructure (i.e., off-net). For this reason, cloud providers offer dedicated network interconnects so their customers can bypass the internet and receive superior network performance for cloud services.

New and emerging digital experiences depend on proximity

In the past, service providers commonly deployed a relatively small number of large data centers and network interconnects at centralized locations. In other words, that’s one large-scale data center (with optional redundant infrastructure) per geographic region where all applicable traffic within the region would backhaul to. New and emerging digital experiences, however, as referenced above, are stressing these centralized data center and interconnect architectures given their much tighter performance requirements. At the most fundamental level, the speed of light determines how quickly traffic can traverse a network while computational power defines how fast applications and associated data can be processed. Therefore, proximity of data center workloads to users and devices where the data is generated and/or consumed is a gating factor for high quality service delivery of these emerging digital experiences.

Consider the following:

◉ High bandwidth video content such as high-definition video on demand, streaming video, and cloud-based gaming. Caching such content closer to the user not only improves network efficiency (i.e., less backhaul), but it also provides a superior digital experience given lower network latency and higher bandwidth transfer rates.

◉ Emerging AR/VR applications represent new revenue opportunities for service providers and the industry. However, they depend on ultra-low network latency and must be hosted close to the users and devices.

◉ Private 5G services including massive IoT also represent a significant new revenue opportunity for CSPs. Given the massive logical network scale and massive volume of sensor data anticipated, data center workload proximity will be required to deliver ultra-reliable low-latency communications (URLCC) and massive machine-type communications (mMTC) services as well as host 5G user plane functions so that local devices can communicate directly with one another at low latency and using high bandwidth transfer rates. Proximity also improves network efficiency by reducing backhaul traffic. That is, proximity enables the bulk of sensor data to be processed locally while only the sensor data that may be needed later is backhauled.

◉ 5G coordinated multipoint technologies can also provide advanced radio service performance in 5G and LTE-A deployments. This requires radio control functions to be deployed in proximity to the remote radio heads.

◉ Developing data localization and data residency laws are another potential driver for data center proximity to ensure user data remains in the applicable home country.

These are just a few examples that illustrate the increasing importance of proximity between applications, content, and data hosted in data centers with users/devices. They also illustrate how the delivery of new and emerging digital experiences will be dependent on the highest levels of network performance. Therefore, to satisfy these emerging network requirements and deliver superior digital experiences to customers, service providers should transform their data center and interconnect architectures from a centralized model to a highly distributed model (i.e., edge compute/edge cloud) where data center infrastructure and interconnects are deployed at all layers of the service provider network (e.g., local access, regional, national, global) and with close proximity to users/devices where the data is generated and/or consumed.

This transformation should also include the ubiquitous use of a programmable network that allows the service provider to intelligently place workloads across its distributed data center infrastructure as well as intelligently route traffic based upon service/application needs (e.g., to/from the optimal data center), a technique we refer to as intent-based networking. Further, in addition to being highly distributed, edge data centers should be heterogeneous and not one specific form factor. Rather, different categories of edge data centers should exist and be optimized for different types of services and use cases.

Four categories of edge data centers

Cisco, for example, identifies four main categories of edge data centers for edge compute services:

1. Secure access service edge (SASE) for hosting distributed workloads related to connecting and securing users and devices. For example, secure gateways, DNS, cloud firewalls, VPN, data loss prevention, Zero Trust, cloud access security broker, cloud onramp, SD-WAN, etc.

2. Application edge for hosting distributed workloads related to protecting and accelerating applications and data. For example, runtime application self-protection, web application firewalls, BoT detection, caching, content optimization, load balancing, etc.

3. Enterprise edge for hosting distributed workloads related to infrastructure platforms optimized for distributed applications and data. For example, voice/video, data center as a service (DCaaS), industrial IoT, consumer IoT, AI/ML, AR/VR, etc.

4. Carrier edge for hosting distributed workloads related to CSP edge assets (e.g., O-RAN) and services including connected cars, private LTE, 5G, localization, content and media delivery, enterprise services, etc.

Of course, applicability of these different categories of edge compute services will vary per service provider based on the specific types of services and use cases each intends to offer. Carriers/CSPs, for example, are in a unique position because they own the physical edge of the network and are on the path between the clouds, colocation/data centers, and users/devices. Of course, cloud providers and content providers are also in a unique position to bring high performance edge compute and storage closer to users/devices whether via expanding their locations and/or hosting directly on the customer’s premises. Similarly, carrier neutral providers (e.g., co-location/data centers) are also in a unique position given their dense interconnection of CSPs, cloud providers, content providers, and SaaS application providers.

Figure 1.  Distributed data centers and edge services

Benefits of distributed data centers and edge services

Service providers that deploy a highly distributed data center and interconnect architecture will benefit from:

◉ Lower network latency and higher bandwidth transfer rates resulting from edge compute proximity.

◉ Flexible and intelligent placement of edge compute workloads based on service/traffic demands.

◉ Increased network efficiencies including reduced traffic backhaul.

◉ Distributed applications/workloads which tend to be more efficient, scalable, secure, and available.

◉ Digital differentiation including superior delivery of new and emerging digital experiences.

◉ New revenue/monetization opportunities associated with the new and emerging digital experiences.

Some CSPs are already actively moving in this direction on their own or in partnership with cloud and content providers. Service providers that haven’t started their transformation toward a highly distributed edge data center and interconnect architecture need to be aware that competitors intend to fill the void. To deliver superior network performance for the emerging digital experiences, service providers should start this transformation now.

Source: cisco.com

Continue reading

Why Manufacturers duplicate IPv4 addresses and how IE switches help solve the issues

If this topic piqued your interest, you’re probably impacted by or at least curious about duplicate IP Addresses in your industrial network. You are not alone. It can be a little bewildering. There doesn’t seem to be any reason in this day and age to have duplicate IP Addresses, let alone do it on purpose. Let’s unravel the mystery.

Companies that build sophisticated machines have made the transition to Internet Protocol as the communication protocol within their machines. IPv4 is the easiest protocol to use. There are lots of software libraries in the ether based on IPv4. These companies’ core competency is the electrical and mechanical aspect of their machines, not the software that runs the machine and therefore they do not have sophisticated software teams. When you’re writing communication software and software is not your core competency, what is the easiest and least problematic way to identify the components within your machine? Answer: Static IP Addresses. The alternative to static IP Addresses is a more complicated process involving dynamic IP Address assignment, along with a complex task of identifying which IP Address the individual components received.

The IP Addresses were duplicated on purpose. The software in the machine uses static IP Addresses to identify individual machine components because it’s easier for the machine builders. Each machine they build has the same software (SW). Therefore, they use the same static IP Addresses. If you have purchased two or more of their machines, then you have duplicate IP Addresses. To be fair, it would be much harder and cost prohibitive to give each component of each machine a unique IP Address.

Figure 1: Robots represent multiple machines with identical components and software

The robots in the picture above are an example of a sophisticated machine. Each robot has the same components and the same software. Each component has its own statically assigned IP Address. This practice is not restricted to robots. Bottling machines and diaper making machines are manufactured in the same way.

Why is this a problem?

As long as you can contain the broadcasts of IPv4 Addresses of the components to stay within the machine, you should be OK. There’s always one publicly unique IPv4 address on the machine which represents the entire machine to the outside world. Again, as long as you only use this one IPv4 address to communicate with the machine, it should not present any problems. Most of the time this is how it’s done and everyone is happy.

Along comes the need to increase productivity. To increase productivity, you need more data. And where is this data? One place is inside the machine. Now you need to communicate with the components inside the machine. Once you have more than one machine, how should you communicate with the internal components that have the same IPv4 address? This is the problem.

Solutions

Before describing solutions, I’d like to uplevel the discussion to talk about Network Address Translation (NAT) in general.

Everybody should know about NAT. We use NAT every day whether we know it or not. The IPv4 router in our homes uses NAT. The IP Address assigned to your home devices (including your laptop and smartphone) is a private IP Address. This private IP Address is not routable on the Internet. Our neighbors all have in home devices with the same IPv4 addresses. It’s not a problem because our home routers use Network Address Translation (NAT) to convert private IP Addresses to a publicly routable IP Address so we can communicate with devices on the Internet. The Internet service providers use private IP Addresses for in home use because it’s easier for them. There are not enough IPv4 addresses in the world for every IP capable device to have a unique IPv4 address. And let’s face it, we have not converted to IPv6.

Your home is not the only place NAT is used. Industrial networks also need to use NAT because sophisticated machines have the same IPv4 addresses.

There are really only two ways to solve duplicate addressing problems for industrial networks. The most obvious way is to insert an additional Layer 3 device such as a firewall or router between the machine and the rest of the network—just to translate Private IP Addresses. This is similar to what you have at home. This solution requires a special network device for the purpose to convert private IPv4 addresses to publicly unique IPv4 addresses. The drawback is, that it’s an additional device to purchase and manage and, configuration and management of this Layer 3 network device can be complex, requiring someone with IT skills to setup and maintain them.

The less obvious way is to use a Cisco Industrial Ethernet (IE) switch to do the IPv4 translation. When the IE switch solves the duplicate IP addressing problem, it’s using Layer 2 NAT. Plus, in my biased opinion, configuring Layer 2 NAT on a Cisco IE switch is easier than configuring NAT on router or firewall. There’s probably an Industrial Ethernet switch in your network already connecting all the machines together. Why introduce an additional network device? Keep the same simple network architecture you have with a Cisco IE switch and solve your duplicate IPv4 addressing issues, too.

Figure 2: IE-4010 connecting multiple complex machines

In figure 2 above, each robot has the same IP Addresses for its internal components. The Cisco IE switch will translate the duplicated private IP addresses of the components of each robot (ie: complex machine) into publicly unique IP Addresses as it receives the Ethernet frames from the robots.

Sample IOS CLI configuration for the Cisco Industrial Ethernet

This is how you would configure a Cisco Industrial Ethernet switch to provide L2NAT for the first two robots on the left in Figure 2. The remaining three robots would be very similar to the first two.

You start by defining which IPv4 Addresses to translate. The Cisco IE does not know which publicly or private IP addresses you want to use. You have to tell it. You define the complete translation.

Define a translation instance for each robot. The ‘leftmost’ robot would have this translation instance for 3 of its internal components. The ‘nextleftmost’ robot would have the same private IP Addresses but unique public IP addresses.

Note: The IP Addresses for the inside hosts are the same in each of the two translation instances, and the translated public IP Addresses are unique. They have to be unique if they are to be used in the upstream network to uniquely identify the robot components.

The next step in the configuration process is to apply the translation instances to the correct interface. The ‘leftmost’ robot is connected to port Gi1/2, and the robot next to it is connected to Gi1/4.

Disclaimer: This configuration, while valid, is just an example.

When it comes to configuring anything in the IOS CLI, the example above shows how simple it can be. For those of you who do not like using the IOS CLI, the same configuration can be done using the IE’sweb based GUI.

Source: cisco.com

Continue reading

Enhancing Government Outcomes with Integrated Private 5G

Enhancing Government Outcomes with Integrated Private 5G

Private 5G is now ready to be part of your enterprise wireless communications transformation strategy. While there has been extensive focus on ultra-wideband gigabit speeds from public Mobile Network Operators, there are even greater government expectations for 5G capabilities to assure the quality of service and empower new mission-critical use cases. 3GPP standards are enabling delivery of capabilities in three strategic 5G areas: enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC). Private 5G is uniquely capable of addressing critical communications requiring interference-free spectrum, high throughput and/or low latency deterministic data delivery, and the ability to transfer terabytes of data without a metered service plan. The result will be a wide range of advanced public and private network wireless capabilities for high-definition video, advanced command and control, autonomous vehicles, and addressing previously overwhelming quantities of sensor data.

Private 5G Fundamentals

Cisco’s Private 5G solution is built on service provider class technology, tailored and optimized for enterprise consumption. For decades, Cisco has powered cellular networks around the world through advanced IP transport and 3GPP standards-based components, including our industry-leading Mobile Packet Core. Our new Private 5G solution delivers Wi-Fi-like simplicity through a cloud-native platform built on a services-based architecture and micro-services infrastructure. The solution offers a zero-touch delivery approach to on-premises elements that provide wireless connectivity between user devices and applications, while ensuring organizational and local data sovereignty. Cisco’s proven IoT platform manages the on-premises elements allowing for rapid turn-up and delivery of services, reducing government 5G learning curves and on-boarding burdens.

Better Together – An Enterprise Wireless Approach

An integrated private wireless strategy for Private 5G and Wi-Fi6 working together can deliver near-term transformative innovation as well as optimal user experiences and new mission-critical capabilities for the next generation of government mobility.

Bringing Private 5G enterprise mobility together with Enterprise IT and existing wireless infrastructures will ensure optimal quality of service, ubiquity of access, and enhanced security for mobile users. This integrated enterprise wireless approach, as depicted in the above picture, also enables the alignment and delivery of enterprise operational and security policies across your entire communications ecosystem. This “better together” story makes even more sense when you consider the vast majority of current 5G connections for voice and data access occur indoors, often where an existing Wi-Fi environment can be leveraged.

Better Together Outcomes – Optimized Experience / Minimized Costs

“Better Together” is a commonsense approach for government organizations that are bringing 5G into existing communications environments and complements the significant wireless investments that most government organizations have already made. And what could be more important in this age of hybrid work? A recent example: working in partnership with Dish Wireless, Cisco has teamed with Internet2 and Duke University to integrate Duke’s campus wireless network with Internet2’s upgraded fifth-generation national research and education network. “Rather than providing two separate infrastructures throughout campuses for cellular and Wi-Fi, the holy grail has always been for a single, common network delivering both cellular and high-speed private Wi-Fi,” said Tracy Futhey, VP and CIO at Duke University.”

This ability to deliver the right wireless technology to optimize overall experience and performance and to ensure enhanced and cost-effective mission and business outcomes are essential for government enterprises focused on user experience and security (and also meeting multiple Executive Orders and President’s Management Agenda requirement mandates).

Key Zero Trust and Security Considerations

Comprehensive, real-time visibility is needed across the wireless enterprise for optimal automation, orchestration, and performance and more importantly, delivering zero trust security. The “better together” approach fully supports Zero Trust mandates to continuously verify trust as called out in both federal mandates and the Cybersecurity and Infrastructure Security Agency’s (CISA) Zero Trust Maturity Model. This integrated Private 5G and Wi-Fi 6 approach:

◉ Enables optimal Visibility & Analytics and Automation & Orchestration to better protect workloads, applications, and data;

◉ Ensures access control is as granular as possible to isolate user environments, applications, and data;

◉ Provides richer data for more effective anomalous activity mitigation.

Source: cisco.com

Continue reading

Security Resilience in APJC

As the world continues to face formidable challenges, one of the many things impacted is cybersecurity. While recent challenges have been varied, they have all contributed to great uncertainty. How can organizations stay strong and protect their environments amidst so much volatility?

Lately we’ve been talking a lot about security resilience, and how companies can embrace it to stay the course no matter what happens. By building a resilient security strategy, organizations can more effectively address unexpected disruptions and emerge stronger.

Through our Security Outcomes Study, Volume 2, we were able to benchmark how companies around the world are doing when it comes to cyber resilience. Recent blog posts have taken a look at security resilience in the EMEA and Americas regions, and this post assesses resilience in Asia Pacific, Japan and China (APJC).

While the Security Outcomes Study focuses on a dozen outcomes that contribute to overall security program success, for this analysis, we focused on four specific outcomes that are most critical for security resilience. These include: keeping up with the demands of the business, avoiding major cyber incidents, maintaining business continuity, and retaining talented personnel.

Security performance across the region

The following chart shows the proportion of organizations in each market within APJC that reported “excelling” in these four outcomes:

Market-level comparison of reported success levels for security resilience outcomes

There is a lot of movement in this chart, but if you take a closer look, you will see that many of the percentage differences between markets are quite small. For example, 44.9% of organizations in the Philippines reported that they are proficient at keeping up with the business, with Mainland China closely following at 44.4%.

The biggest difference we see between the top spot and the bottom spot is around retaining security talent—42.4% of organizations in Australia reported that they were successful in that area, while only 18.3% of organizations in Hong Kong reported the same.

Next, we looked at the mean resilience score for each market in the region:

Market-level comparison of mean security resilience score

When we look at this, we can see the differences between the top six and bottom seven markets a bit more clearly. However, as the previous chart also showed, the differences are very slight. (When we take into account the gray error bars, they become even more slight.)

There are many factors that could contribute to these small differences when it comes to security resilience. But the most important thing to be gleaned from this data is how each market can improve its respective resilience level.

Improving resilience in APJC

The Security Outcomes Study revealed the top five practices—what we refer to as “The Fab Five”—that make the most impact when it comes to enhancing security. The following chart outlines the Fab Five, and demonstrates how each market in the APJC region ranked its own strength across these practices.

Market-level comparison of reported success levels for Fab Five security practices

If we look at Thailand, for example, 69.1% of organizations say they are adept at accurate threat detection, while only 28% of organizations in Taiwan say the same. Like in the previous charts, there is a lot of movement between how various markets reported their performance against these practices. However, it’s interesting to note that Taiwan remained consistent.

So does implementing the Fab Five improve resilience across organizations in APJC? Looking at the chart below, it’s safe to say that, yes, implementing the Fab Five does improve resilience. Organizations in APJC that did not implement any of the Fab Five practices ranked in the bottom 30% for resilience, whereas those that reported strength in all five rose to the top 30%.

Effect of implementing five leading security practices on overall resilience score

Boost your organization’s cyber resilience

While building resilience can sometimes seem like an elusive concept, we hope this data provides some concrete benchmarks to strive for in today’s security programs.

Source: cisco.com

Continue reading

6 Steps to Unlocking ThousandEyes for Catalyst 9000

Modern businesses rely on network connectivity, including across the Internet and public cloud. The more secure, stable, and reliable these networks are, the better the user experience is likely to be. Understanding WAN performance, including Internet transit networking and how it affects application delivery, is key to optimizing your network architecture and solving business-impacting issues.

Troubleshooting any technical issue in environments so distributed and fast-changing can be a difficult and tedious process. First, there is the scope of what the problem could be. Is it a configuration error? An application issue? Did someone forget to change a DNS entry? Without knowing what domain the problem resides in, it is hard to approach troubleshooting effectively.

To help enterprises meet the needs and requirements of their expanded enterprise networks, new and existing Catalyst 9300 and 9400 switches customers have a powerful entitlement in their toolkit: ThousandEyes Enterprise Agents. ThousandEyes runs on many platforms, but there are several advantages to running ThousandEyes tests from Catalyst 9000 switches.

Installing it is easy, and you can use your existing resources to monitor connectivity and digital experience as close to the end-user as possible.

Not to mention it is cost-effective. There is no extra hardware, software, or license required to leverage ThousandEyes with this entitlement.

How does this entitlement work?

The ThousandEyes entitlement is based on units. And there is a certain number of units required for each ThousandEyes test, depending on many factors like the type of agent, type of test, and frequency of the test.

Each active Advantage license from Catalyst 9300 or 9400 switch translates into an equivalent of 22 ThousandEyes units each month. These units are enough to run one test every 5 minutes and can also be pooled to run more tests and/or an increased frequency of tests. (Please note: this entitlement only corresponds to Enterprise Agents.)

These units are automatically provisioned for new switches but are also available on request for existing Catalyst 9300 or 9400 customers.

A Step-by-Step Guide on Activation

When you are ready to begin, you will need the following:

1. A Cisco Smart Software Manager (CSSM) account

2. The email address configured on your Smart Account or Virtual Account

Step 1 – Log in to Cisco Smart Software Manager (CSSM)

Navigate to Cisco.com –> Smart Software Licensing –> Manage Licenses

Navigate to Inventory –> Licenses

Step 2 – Select Licenses to upgrade

These entitlements are automatically deposited and have an expiration matching your existing DNA licenses.

Locate “ThousandEyes Enterprise Agent Tests” entry.

Note that the legend above indicates “+7 pending” licenses, representing the number of switches in your environment with unused ThousandEyes credits. This snapshot was taken in an environment with seven Catalyst 9300 switches.

Navigate to Actions –> Complete Upgrade

Step 3 – Select Licenses to upgrade

In this step, we need to select the quantity of DNA licenses we want to leverage for ThousandEyes activation. The most common use case is to select the whole quantity available.

Step 4 – Review & Submit

Click Submit

The submission automatically triggers the provisioning call to ThousandEyes. Afterward, you will be able to see the DNA licenses in your account that are used for the ThousandEyes entitlement.

Step 5 – Confirm Your Account

Your ThousandEyes Account is created, and the units are now in your account.

To get access to the ThousandEyes dashboard, you must confirm your account via the customer welcome email. To ensure you receive this confirmation email, be sure to have access to the email address configured on your Smart Account or Virtual Account.

Step 6 – Install Agent and Begin Running Tests

You are ready to install the ThousandEyes Enterprise Agent in your switch using CLI or DNA Center and start reaping the benefits of end-to-end visibility from your campus all the way to the private, cloud, and SaaS networks.

Source: cisco.com

Continue reading

Networking Demystified: Protecting Endpoints is Job #1

Enterprise networking is a constantly evolving set of technology solutions. From an engineering perspective, it presents an endless series of fascinating problems to solve as we strive to connect more people, devices, and applications around the world. Cisco customers also have a seemingly endless list of use cases that they need our help in solving as they progress through their own digital transformations. We are starting this “Networking Demystified” blog post series to explore different aspects of networking technology that impact everyone today. This first deep dive is into the “mystery” of protecting endpoints like your laptop, phone, sensors, cameras, and the other thousands of types of devices that are so critical to running our modern world. Join us on this journey and maybe you too will be the next engineer to solve the hard problems of enterprise networking.

So, what is an endpoint? In simple terms, it is a device that connects to a network to serve a purpose: from something as simple as delivering IoT sensor data, to connecting people socially or professionally, accessing SaaS and cloud applications, or performing machine to machine exchanges of information to solve complex problems. Endpoints are everywhere. In our homes, office spaces, manufacturing floors, hospitals, and retail shops—literally everywhere, serving a multitude of purposes.

The Good, the Bad, and the Ugly

In an ideal world we expect all endpoints will behave the way they are supposed to and do no harm, just like the people interacting with the endpoints. But in the real world this is not actually the case. As a result, we need to categorize endpoint behavior into The Good, The Bad, and The Ugly.

◉ Good endpoints follow all the rules for network onboarding, use secure protocols for access, have up-to-date secure software installed, and do only what they are supposed to do.

◉ Bad endpoints are those outliers that still do what they are supposed to do but have loopholes which can be exploited to create security and performance problems.

◉ Ugly endpoint behavior can be categorized as being actively exploited and creating problems from local to global scale.

So, what do we do? We reward good behavior by providing the right level of access to permitted network resources. We punish bad and ugly behavior by restricting access or completely isolating an endpoint from the network based on how it is behaving.

But wait, how do we decide on the levels of access? We need to know what the endpoint is, before giving it the required access because we cannot protect what we don’t know. A printer does not need access to financial servers. Similarly, a CT scanner in hospital does not need access to patients’ medical records. But if we do not know whether the endpoint is a printer or a CT scan machine, how can we manage their behavior? We can assign a generic access policy to endpoints so that they can do their job, but that opens up a host of security problems. So how to identify and tag endpoints to determine the right access? Follow the breadcrumbs—the trail endpoints leave on the network as they communicate with other endpoints.

Great, that seems easy! So now our endpoints and network are secured. Unfortunately, not yet. Will endpoints behave in the same way all the time? They may not! If we want to secure all endpoints, we need to continuously monitor them to identify any change in behavior so that the network can act on the next steps, which could be a warning to the endpoint owner, a restriction on access via segmentation, or a more severe punishment—such as completely cutting off network access—until the behavior is fixed.

So, we need technology that focuses on how to identify endpoints effectively to assign the right level of network access, plus continuously monitoring endpoint behavior to determine when endpoints are acting abnormally. At Cisco, we think about this a lot. At a global scale there will soon be 30 billion+ endpoints connected by various private and public networks as well as the internet. Around 30-40% of endpoints may be of an unknown type when they first connect. This creates an incredibly large threat surface available for the bad guys to compromise endpoints and networks. To defend the enormous range of endpoints requires innovative networking access protection technologies. With the biggest market share in endpoint connectivity, Cisco understands the problem of secure access to defend networks and assets.

Breadcrumbs, Surgical Procedures, and Analytics

Let’s talk about the methods that Cisco uses to identify endpoints and defend the network before diving into some of the technical details.

Each type of endpoint coming on the network uses different protocols throughout its lifetime. For some of the protocols, these details are readily available in the network and can be used to understand the endpoint type. That is one of the simplest approaches. For some protocols, the information about endpoint identity is hidden deep inside the packets and we need a surgical procedure called Deep Packet Inspection (DPI) to reveal their secrets. Like any surgical procedure when surgeons open the human body to diagnose or fix the problem, DPI opens up and examines protocol packets until enough information is extracted to enable an endpoint to be identified. Since no two protocols work in same exact way (no two operations are same, right?), the challenge is to catalog each protocol and then methodically plan protocol operations (analytics) to identify endpoints.

With this in mind, you might think that endpoint classification using DPI must require special separate hardware in the network. Fortunately, with Cisco’s innovative application recognition technology embedded in Cisco Catalyst switches, you don’t need any new hardware. All processing of endpoint types occurs within the IOS XE switching software. How cool is that? The capability adds up to a lot of CapEx savings.

With Cisco’s Deep Packet Inspection technology, we can reduce the unknown endpoint count significantly. But is that enough? Not really, because the number of endpoints connecting to a network is going to increase exponentially, with manufacturers creating new types of endpoints that use different types of protocols to communicate. Just trying to keep pace with the changing types of endpoints is going to be a huge challenge. Does it mean we leave these newer endpoints on network operating without supervision—remember, you can’t protect what you don’t know.

Bring on Cisco AI/ML Analytics, the solution to reduce the number of unknown endpoints. AI/ML Analytics identifies endpoints and groups them according to similar operating and protocol characteristics and show them in context to IT. As AI/ML Analytics learns more about millions of endpoints across enterprise networks, its understanding improves significantly to assign endpoint identities with increasing accuracy. The result is that hundreds of thousands of endpoint identities can be categorized with minimal effort from IT.

The Next Level of Access Security

The above technologies help identify endpoint types and assist in applying the right access policy for an endpoint to do its job. But the story doesn’t end there. Using continuous, anomaly-focused monitoring, any change in endpoint behavior can be detected, enabling access decisions to be automatically updated. A simple example could be an IoT sensor device that usually delivers telemetry to a controller, but is suddenly communicating with other endpoints, indicating the device may be compromised. AI/ML Analytics detects that it is not behaving as per its normal traffic pattern and raises an alert for IT to examine or quarantine the device as needed to secure the network.

So, what is Cisco doing to expand this technology? The solution offering that combines these multiple technologies is called Cisco AI Endpoint Analytics, which is destined to be the single pane of glass for understanding endpoint identity and trust. It is currently being offered as an application on Cisco DNA Center. We are also extending the technology to other Cisco solutions, such as Cisco Identity Services Engine (ISE), to enhance and automate endpoint profiling.

Figure 1. Cisco AI Endpoint Analytics on Cisco DNA Center

Join Cisco in Making IT More Secure

So how can you help? What we discussed here is just the beginning of development activities for reliably determining endpoint identity and behavioral monitoring. It is an evolving area that needs a lot of attention and exploration to continuously improve the techniques employed. In fact, many of us consider endpoint protection as Job #1. It’s an exciting area to work in, knowing the impact you can have on helping to secure our ever-more interconnected world.

If you were to join Cisco, what is there to do to make your mark in this space? A lot! We are working on four key areas in AI Endpoint Analytics: Endpoint Identity, Endpoint Behavior, Enforcement, and Endpoint Data Analytics.

So, would you like to be part of the Cisco AI Endpoint Analytics journey and proudly tell others that you help protect endpoints everywhere? Because without secure, defended endpoints, there is no network!

Source: cisco.com

Continue reading