Make Your WAN Connectivity an Extraordinary Experience

Alan Dapré, author of more than 60 children’s books said, “Why be ordinary when you can be extraordinary?” You may be thinking that “extraordinary” is not a term commonly associated with network connectivity. Shouldn’t it just be like water coming out of the faucet? A utility that is … well … ordinary?

Extraordinary is an enhanced experience. And the Cisco Networking Cloud vision enables you to create an enhanced experience that your users refer to as extraordinary. With our latest SD-WAN product enhancements, we’ve made it easier for you to deliver that exceptional experience to them.

SD-WAN: New name and additional deployment option

At Cisco Live in Las Vegas, we announced the rebranding of the Viptela technology solution from Cisco SD-WAN to Cisco Catalyst SD-WAN. The Catalyst brand has always stood for the industry’s most powerful switching, wireless, and routing platforms. This name change not only provides consistent alignment with the Catalyst brand of our routing hardware, but also with our access, data center, and cloud solutions—and drives brand simplification. Cisco’s SD-WAN portfolio includes both Catalyst SD-WAN and Meraki SD-WAN fabrics to provide the most versatile solutions regardless of your use case.

Deployment options for SD-WAN connectivity

Until now, Cisco has offered two ways for you to consume Cisco Catalyst SD-WAN. First, an on-premises deployment would reside in your own data center or a managed service provider’s data center. The second option was to deploy in a Cisco hosted environment with either an AWS or Microsoft Azure cloud infrastructure.

A third deployment option is now available. Cisco Catalyst SD-WAN can be cloud-delivered to align to your infrastructure strategy. Why cloud-delivered? We recognize that operating models are changing. Organizations demand simplicity, agility, flexibility, and scalability. Cloud-delivered Catalyst SD-WAN provides a cloud-first experience with automated, rapid on-boarding and single sign-on.

Cisco provides zero-touch life cycle deployment and management of the infrastructure via Cisco’s Cloud Operations team. Customers will experience end-to-end service delivery, providing automated provisioning of the SD-WAN fabric. Cisco provides the management, monitoring, upgrades, and backup and restore. We’ve included access to end-to-end actionable insights that measure, predict, understand, and remediate potential issues, so there’s no need to implement it later. You can now consume SD-WAN with a flexible subscription model that scales to your needs and enables more precise OpEx planning and lower TCO.

Elevating the application experience

Nary a business has been unaffected by the need to support hybrid work requirements. The importance of delivering an exceptional experience to your users has risen with this trend, and the accelerated adoption of digital services has transformed enterprise IT. Unless every one of your users work from the office and all applications they access are on premises, you no longer fully control the end-to-end infrastructure, yet you are still accountable for delivering optimal digital experiences. These new capabilities and solutions help you elevate the application experience.

ThousandEyes Service Assurance helps your organization ensure top-notch digital experiences through end-to-end network visibility and proactive insights that empower you to pinpoint, troubleshoot, resolve, and optimize performance across every network domain that matters to them—whether on premises, the internet, or cloud.

Cisco is announcing expanded support with ThousandEyes, providing visibility into public cloud networks, internet routing, and enterprise sites with new vantage points from Meraki MX (and Webex RoomOS) devices. You’ll enhance operations with automated event detection and problem isolation, and unmatched insights of your cloud connectivity.

As organizations adapt to hybrid work, IT is expected to support workers at the branch, campus, and remotely. The Meraki Z4 gateways allow IT teams to securely provide connectivity to remote workers and simultaneously manage SD-branch infrastructure across global locations on a unique cloud platform that consolidates security, SD-WAN, access, and IoT.

Simplifying IT

Technology should never get in the way of conducting business and has two essential requirements: work as expected and be simple to use.

The latest enhancements in SD-WAN management and analytics include new Circuit and SecOps dashboards—along with step-by-step configuration templates to expedite the implementation and management of security policies. They include enhanced visibility into circuits and traffic patterns with a visual interface. An enhanced topology view has been added, and real-time tracking of network and path conditions by application-aware routing provides faster brownout detection.

We are introducing closed-loop automation capabilities to Predictive Path Recommendations (PPR). As an integral component of Cisco predictive networks, PPR delivers a predictive network solution, enabling IT personnel to proactively improve application experience. Leveraging advanced algorithms and predictive models, PPR determines the performance and policy compliance of the paths carrying the site application traffic. When performance is below historical benchmarks or SLA, PPR can make recommendations to the IT personnel and automatically implement corrective actions—before impacting users.

Granular Role-Based Access Control (RBAC) enables service providers to offer a robust co-managed SD-WAN service. Both service providers and their tenants can share or split responsibilities while maintaining accountability via auditing functionality in managing an SD-WAN overlay.

Cisco Catalyst SD-WAN now supports Cisco Umbrella’s multi-org integration, allowing customers to easily manage multiple child organizations or regions from a single Umbrella dashboard. This enables the integration of multiple Umbrella organizations with a single-tenant Cisco Catalyst SD-WAN deployment by configuring the Umbrella API integration for DNS and SIG on a per-device basis. By creating customized security policies tailored to specific needs of different regions or organizational units, customers can simplify the security management process, improve network security, and reduce the risk of security breaches. A centralized view of multiple networks reduces the time and effort to manage multiple networks and improves the user experience.

Cloud and middle-mile connectivity

Cisco SD-WAN Cloud Hub with AWS Cloud WAN provides a dynamic WAN service that allows building of a global network in a simplified and fully automated manner, within minutes. The solution delivers a secure, on-demand, flexible, and highly available middle-mile, leveraging the global AWS backbone, intent-based network management, and advanced security through a central policy framework.

Our multicloud solutions start with our enhanced cloud router—the Catalyst 8000V—a virtual router that is optimized for scale and performance for compute instances across the cloud and backbone providers. You can consume this software from public cloud marketplaces with pay-as-you-go (PAYG) licenses or bring your own license (BYOL), purchased directly from Cisco.

During Cisco Live, we announced a network-as-a-service consumption model for middle-mile services with Megaport. This PAYG model allows customers to be billed by Cisco according to the usage of their Megaport services. We also announced the availability of Megaport Ports on Cisco’s Global Price List (GPL). Customers will be able to purchase ports globally for private connectivity to Megaport Virtual Edge and for provisioning global backbones through Cisco Catalyst SD-WAN. With PAYG and Megaport Ports, you gain private connectivity to virtual edges from your data centers or sites. PAYG is important for customers because you only pay if you use them. There is no upfront commitment and no overage.

Efficiency and cost savings for service providers

Cisco Multitenant Edge for Cisco Catalyst SD-WAN platforms enables providers to securely host multiple tenants on a single physical or virtual SD-WAN platform. It simplifies and accelerates SD-WAN design and deployment, while also providing CapEx and OpEx savings. This also helps you meet your sustainability goals by powering fewer WAN appliances.

Clearly, network connectivity is no longer just an ordinary, basic utility. As we continue to build on our vision for Cisco Networking Cloud, we are enabling elevated experiences that allow you to provide connectivity experiences for your users that are truly extraordinary.

Source: cisco.com

Continue reading

To the Cloud and Beyond―A Comprehensive Model for Enhanced NetOps and User Experience

Cloud computing has become wildly popular among IT organizations for a number of reasons, including its ability to enhance efficiency, security, agility, and cost-effectiveness. But now cloud features and principles have also become the building blocks of something even bigger and more all-encompassing: a unified IT operating model that spans people, devices, networks, applications, and things across the digital infrastructure.

With end-to-end visibility and centralized, cloud-based management, IT can monitor, manage, and control an organization’s entire networking, cloud, and security infrastructure. A unified cloud operating model makes it easier for organizations to pivot as their needs change. Organizations can quickly deploy innovative applications, respond to disruptions and threats, and scale performance and capacity. The model is an antidote to separate, complex, operational silos on-premises, on the internet, and in the cloud. The overall goal of the model is to dramatically improve the efficiency, reliability, and resiliency of IT operations, as well as the quality of user experience.

The Need for a Comprehensive Operating Model 

Recent research conducted by IDC has found IT staff worldwide engaged in a struggle with highly specialized, complex, and manual management tools and procedures in use across on-premises, internet, cloud, and security silos. Between all of the silos are management and security gaps. Integration is limited. Efficiency and time-to-market suffer.

Meanwhile, IT is being asked to innovate in the use of applications and data intelligence, to create great and secure user experiences, to scale up or down in response to demand, and to do it all efficiently and cost-effectively.

Enter the cloud operating model.

With the cloud operating model, cloud principles like anywhere access, self-service dashboards, policy automation, end-to-end visibility, microservices, continuous integration, and continuous delivery (CI/CD), and extensibility can be applied across the entire digital infrastructure from access to internet to cloud (Figure 1). That includes all endpoints and systems whether they are on-premises, in the cloud, in remote offices, or mobile.

Figure 1. The Cloud Operating Model

With consistent policies and governance within and across operational domains, the cloud operating model can improve cross-functional collaboration, eliminating disparate processes and disjointed efforts that hamper better business outcomes.

An Ongoing Journey

Achieving a cloud operating model is a journey for organizations requiring a significant shift in how they approach their IT operations:

• A shift in thinking from viewing cloud and on-premises environments as separate entities to looking at how the best features of both can converge
• A cultural shift that embraces breaking down silos, promoting collaboration, and encouraging cross-functional innovation
• New skills, tools, and processes to manage infrastructure, such as automation, DevOps, and agile methodologies
• Integration of cloud management platforms with legacy systems, which requires careful assessment and a migration strategy

Achieving a cloud operating model is not a one-time event but rather an ongoing journey of continuous improvement across the entire IT environment. Cloud features and a unified management platform provide the means to monitor, optimize, and innovate to help ensure that organizations are getting the most value from their investments.

Where to Begin?

Start by evaluating which cloud principles exist in which domains. At Cisco, we’re developing a new tool that helps organizations define their various infrastructure principles within the access network, software-defined WAN (SD-WAN), and data center. By overlaying principles on infrastructures, an organization can identify opportunities to integrate silos to help meet business and operational objectives.

Some organizations are starting the journey to the cloud operating model by extending SD-WAN connectivity across multiple clouds for simpler IT management and a better application experience. With a distributed SD-WAN, they can apply policy, visibility, control, and zero trust consistently across all clouds, software-as-a-service (SaaS), and middle-mile providers. Other organizations are planning to use this SD-WAN foundation to transition to a secure access service edge (SASE) architecture to connect network and security domains across branches and remote clients.

With our broad cloud and networking platform portfolio, Cisco provides a comprehensive set of solutions with the visibility, consistent policy governance, and insights-driven automation necessary to support an effective cloud operating model. For example, in campus networking, the Cisco Meraki platform supports many key cloud principles.

The Meraki dashboard provides cloud-based management for connected access points and IoT devices, plus monitoring and management of switches. Through the dashboard, configuration and access policies can be defined and automated throughout the network. The dashboard interface is a visual representation of all connected devices, showing the real-time status of each device. And Meraki has a marketplace of partner applications that leverage APIs to extend these capabilities across the network.

Source: cisco.com

Continue reading

Unifying Experiences Starts By Unifying SASE

Over the years, advancements in technology and the endless waves of new innovations have created an unintended problem for most organizations today—overcomplexity. 53% of senior decision-makers say their IT environment is more complex than it was just two years ago.

I explained how Secure Access Service Edge (SASE) and the convergence of networking and security are key to reducing operational complexity. Now, more than ever, organizations need an efficient way to securely connect distributed workforces and build a consistent operational model that extends from on-premises to the cloud, bridging a hyper-dispersed landscape and creating secure and seamless experiences anywhere.

Answering that call are two general SASE approaches that may deliver those desired outcomes. The first, a “best of breed” solution, is comprised of separate networking (SD-WAN) and security service edge (SSE) products, typically from multiple vendors, which inherently will lack a consistent operational model, leading to a more fragmented experience given the increased integration required to produce a complete SASE solution. This may also lead to a solution that is less secure.

The second approach is a unified SASE solution that delivers networking and security components as a simplified, turnkey cloud service featuring unified management from a single dashboard. A well-designed SASE solution removes complexity by providing centralized management with intelligent and consistent distributed enforcement, along with controls and visibility across endpoints, enterprise edge, and cloud edge to deliver a more secure end-to-end solution that further enhances the end-user experience. Unified SASE embraces a platform approach, seamlessly converging networking and security technologies into one experience that makes management easy.

Acknowledging the importance of a unified, single-vendor approach, Gartner predicts that… “By 2025, 50% of new SD-WAN purchases will be part of a single-vendor SASE offering, up from 10% in 2022.” 

Converging the Best of Networking with Security on a Single Platform

Cisco+ Secure Connect is Cisco’s premier unified solution that provides a blueprint for SASE made easy. This unified SASE solution is built on a converged cloud-first platform that connects Cisco’s industry-leading networking and security technology and delivers several key outcomes:

◉ Creates a streamlined IT management experience, which in turn helps deliver a more seamless experience for end users so they can access the resources they need, wherever and whenever they need them

◉ Simplifies the management of networking and security domains within a single dashboard, providing greater visibility and insight to ITand allowing them to proactively stay on top of threats and vulnerabilities across the network, ensuring greater resiliency and security

◉ Harmonizes the networking and security domains by interconnecting everything and providing security everywhere to build a unified SASE fabric, removing complexity and creating a simple, consistent operating model

Figure 1. Cisco+ Secure Connect Dashboard

Every organization has an installed technology base, and there may be a temptation to simply add the missing SASE functionalities to whatever currently exists. However, it’s important to note that SASE is a long-term strategic choice and simply deploying all the components of a SASE model without a high level of integration does not constitute a fully functional SASE solution and will not deliver the desired outcomes. For this reason, unified SASE is the simplest and easiest path to realizing true SASE benefits that “stick” – ultimately, delivering better experiences.

Source: cisco.com

Continue reading

Something New: AP Discovery Methods for 6GHz Wi-Fi – Part 2

In Part 1 (Something Old) we looked at basic changes to the physical layer provided by wave 1 of 801.11ax, how these changes can affect performance, and how OFDMA enables the optimal use of the 6GHz spectrum. In this second article, we’ll explore “something new:” the challenges of discovery in 6GHz, new methods used for solving this, and how these new methods open 6GHz for many different use cases.

Is There Anybody Out There?

In previous generations, Wi-Fi clients would scan channels and send unsolicited probe requests to discover access points (APs). Scanning channels can be a timely process as beacons are only broadcast every 102400us so the client must dwell long enough to detect the beacon. At 6GHz this is 102400us x 59 channels (there are 59 20MHz channels in the new 6GHz spectrum) which is over 6 seconds. For the client, this loss in time represents a disruption in communication. Creating intolerable latency in voice and lost opportunity to hundreds of megabytes of data every time the client decides to scan. Furthermore, the previous process would be to send unsolicited probe requests (wildcard requests) to see how APs would respond. Now, remember, this is all a contention-based medium, so these probe requests and responses on every channel for every client create a significant amount of interference and at the very least, inefficient use of the spectrum.

Read More: 300-710: Securing Networks with Cisco Firepower (SNCF)

Over the years the IEEE has introduced measures to address these roaming challenges. 802.11k was introduced to provide clients with a list of neighboring APs, 802.11v was introduced to provide a recommended AP candidate, and 802.11r was introduced to reduce the roaming time for 802.1x clients. Not all clients and infrastructure support these measures so while they helped, they did not eliminate the need for clients to send unsolicited probes.

While these IEEE updates are still available for 6GHz, the strategy for AP discovery fundamentally changes. To start with, unsolicited probe requests are no longer allowed (with one limited exception we will discuss shortly).

Three New Methods to Improve AP Discovery

Since we have already established scanning channels at 6GHz is not allowed, there are three new methods introduced in Wi-Fi 6E for finding AP candidates.

The primary method (and the one that clients typically respond to best) is called Reduced Neighbor Report (RNR). Since most, if not all, clients will have legacy band capability, there is an Information Element (IE) embedded in the legacy band beacons that list the 6GHz SSID(s) that are available on the serving AP. The client first scans the 5GHz or 2.4GHz channels and looks for this RNR element. The RNR report contains information about the 6GHz channel, SSID, BSSID, a bit of information on the AP, and the allowed power levels (Power Spectral Density). This effectively makes the 2.4GHz and 5GHz channels a control channel for the 6GHz. Clients can then send a directed probe request to those channels that are learned in the RNR to determine which 6GHz AP to join. It is important to note there can be multiple 6GHz SSIDs included in the RNR and they do not have to match the legacy SSIDs.

The information contained in an RNR is very similar to the information provided in the previously introduced 802.11v action frame. The RNR below is from a 5GHz beacon and is advertising two SSIDs on the 6GHz channel number 5. The legacy 802.11v action report below shows similar information to the RNR but the fundamental difference is twofold:

◉ This is an action frame not part of the beacon like the RNR. It is a request-response type transaction. An RNR is broadcast in the legacy band beacons.

◉ The information in the 802.11v action frame contains information about other APs on the same frequency band. The RNR only lists SSIDs broadcasted from the 6GHz band (different frequency band) as this same AP.

Figure 1: RNR on 5GHz beacon

Figure 2: 802.11v Action Frame

What if the AP is only broadcasting 6GHz? This is an unlikely condition, but nonetheless a potential one. First, scanning can be reduced by limiting the number of channels to be scanned. This is called Preferred Scanning Channels (PSC). The PSCs are the primary channels (20MHz subchannel) of the 80MHz channels. This works well since 80MHz will often be the preferred bandwidth to operate for reasons previously discussed in part 1 of this blog series. If however, lower bandwidth channels are used without RNR or additional support from the methods below, it would be very easy for a client to miss this channel which should be a consideration when using PSC with narrower band channels.

Figure 3: Preferred Scanning Channels (red)

There are two mutually exclusive options to further enhance the AP discovery in which the AP will broadcast messages an additional 4 times between the beacons or about every 20ms (configurable from 5ms to 25ms). The first method is called Fast Initial Link Setup (FILS) and is based on a previous standard of 802.11ai. This is a very lightweight message (somewhere around 100 bytes as compared to a beacon which is 500+ bytes). The second method is called “Broadcast Probe Response” or “Unsolicited Probe Response” (UPR). Like FILS, this advertisement will be broadcast at a higher rate than the beacon. However, the UPR broadcasts everything in the probe response so while it supplies the client with more information, it is a bit heavier in the amount of data transmitted repeatedly.

Teamwork Makes the Discovery Dream Work

So how do these four methods work together? First, if there are legacy band SSIDs transmitted on the AP the expectation is that the RNR will do the work of discovering the 6GHz channel, and no other method is required. In the case where only 6GHz is broadcast from the AP the most likely scenario would be the use of PSC with either FILS or UPR. Notice UPR and FILS are exclusive options, you can only use one or the other. Early testing of client devices has seen some issues with 6GHz standalone APs not being discovered with only PSC and it is needed to have FILS (or UPR) enabled to assist a client in discovering the AP. This may change over time but for the early implementations, deploying 6GHz with only 80MHz channels and PSC enabled is a good option. This allows the primary channel to match the PSC channels. In addition, enabling FILS can provide further assistance for discovery with minimal impact on performance.

Source: cisco.com

Continue reading

Wi-Fi 6E, Something Old, Something New, Something Borrowed, Something Blue – Part 1

With the recent release of a number of Wi-Fi 6E-enabled devices at the Consumer Electronics Show (CES), now is a good time to take into account some of the benefits that Wi-Fi 6/6E provides. Wi-Fi 6/6E was not an “incremental” change, it was a major leap forward with the new innovations and most importantly, the addition of the newly allocated 6GHz spectrum (which varies across regions). In this series, we will provide the reader with an in-depth understanding of some of these advanced features in Wi-Fi 6 and how some of these features benefit them. Furthermore, we will discuss some of the new innovations built around the Wi-Fi 6E standard and how IT leaders are just starting to realize the potential for 6GHz wireless.

“Something Old”

While the ability to support multiple simultaneous users has been available prior to Wi-Fi 6E this is one “old” feature that becomes enhanced in Wi-Fi 6E. In part 1 we want to look at some of the changes to the physical layer, what changed, and how this helps your WiFi performance.

Of all the features added to Wi-Fi 6, one, in particular, will have a very significant effect on the new 6GHz band and deserves some in-depth consideration and that is OFDMA. Remember all that old 802.11ax optional capability is now mandatory at 6GHz as there is no requirement for brownfield support. There were other technologies added to the legacy bands in Wi-Fi 6 that really paved the way for substantial improvements in performance. For example, increased modulation rates (up to 1024 QAM, think of this as higher maximum throughput), better spatial isolation (BSSID Coloring/OBSS and multiple timers for IBSS and OBSS, think of this as better performance in an area with lots of clients and APs), Target Wait Time (better battery life for clients), and others.

Digging into OFDM – The Virtual Wires of Wi-Fi

OFDM is the “baseband” signal which is the underlying waveform that is used to generate the RF signal we think of as Wi-Fi from the digital input. This baseband signal is comprised of multiple “tones”. The combination of these tones is called Orthogonal Frequency Division Multiplexing (OFDM). Each tone is orthogonal to the other tones which means the information on that tone can be detected with limited interference from other tones even though they are tightly spaced together. Think of each of these tones as a wire that information can be conducted. Fewer tones mean fewer wires but higher throughput for any one wire, more tones mean more wires but lower throughput per wire. The total “available” throughput, in either case, ends up being basically the same. In 802.11ax a change was made to move from 64 tones to 256 tones (4x) in a 20MHz channel.

Figure 1. OFDM changes from Wi-Fi 5 to Wi-Fi 6

As discussed, this increase in tones has very little impact on the link available throughput but, there are other trade-offs. First, the 4x increase in tones improves the robustness of multipath (improved resistance to inter-symbol interference) but loses some effectiveness in a high-speed mobile environment (doppler shift). So, under typical indoor use, we get a benefit of a more reliable connection. The second, and biggest change is the ability to better “sub-channelize” the physical layer. This access method is called Orthogonal Frequency Division Multiple Access or OFDMA. A sub-channel or group of tones at a given time slot is considered a “resource unit” often referred to as an “RU”.

Since the ratio of the number of tones is relative to the bandwidth, in a 20MHz channel there can be up to 9 RUs (26 tone groups) for any one frame and in a 160MHz channel this could go up to 74 RUs (notice this is not 72 as there are some efficiencies due to higher ratio of usable tones at higher bandwidths). RUs can come in larger sizes also to match the resource demand. For example, with a 20Hz channel, you can additionally have 52 tones, 106 tones, or the full band on 242 tones. Furthermore, you can to some degree mix and match these different-sized RUs in the same frame. These RUs provide a mechanism to transmit to multi-users (MU) at the same time without having to rely on spatial diversity. Let’s put a number to why this is important. Take a 64-byte packet operating at some typical rate like 256 QAM with ¾ rate coding (MCS8). With 40MHz channels, one slot is capable of around 380 bytes. What happens if a 64-byte packet (typical packet) is transmitted over this 40MHz channel? Less than 20% of the channel is used, and over 80% of that resource is wasted! With the use of RU’s, we can send multiple packets at the same time and pretty much eliminate that inefficiency. Granted not all packets are 64 bytes but larger packets are broken into smaller physical layer packets called Protocol Data Units (PDUs) to be transmitted and again will not fill up the entire spectrum for all PDUs.

So how does the AP signal the client when and where its RUs are allocated since there are now multiple client packets in a time slot? This is accomplished using two mechanisms. First, there is now a new field in the preamble that provides the “where” called SIG-B. This field provides how the resource units are allocated over the slot and the per-client information that specifies which resource units are allocated for my specific client.

There are really 3 options to transmit multi-user packets at the same time:

◉ Multiple simultaneous users’ signals are transmitted using the full band but the spatial characteristics of the channel allow them to communicate with limited interference (spatial separation).

◉ Multi-User with different users assigned to different RUs (frequency separation).

◉ A combination of both.

Option 1 is a multiplier – If the channel permits sending multiple streams over the same channel the capacity of the channel grows proportional to the number of users. There are limitations to this, for example, the number of uplink spatial streams is equal to or less than the number of uplink receivers in the access point. If the AP and the environment support option 1 it would typically be used.

Option 2 is an optimization – If the network has multiple clients that support Wi-Fi 6 that have traffic to send at the same time the network will optimize by sending the traffic at the same time.

The second function that facilitates the “when” the use of multiple clients is the “trigger frame”. When the AP is ready for the clients to simultaneously send uplink information it transmits a trigger frame with the client information. The client waits for one short interframe spacing (SIF) and then transmits the uplink data on the appropriate RUs. The AP can then send back a “multi-Station ACK” allowing the multiple client uplink packets to be acknowledged simultaneously. Uplink ACKs are transmitted similarly to the uplink data with a trigger frame on the allocated RUs.

Figure 2. Trigger Frame Sequence

Given 6GHz has a much larger block of spectrum and the most common FCC regulation to deploy is based on power spectral density (PSD), which allows for more power with wider channels, it is expected that most deployments will use 80MHz or 160MHz (see 6-GHz Unlicensed Spectrum Regulations and Deployment Options White Paper). With the previous generation of one packet per time slot, 80MHz channels became very inefficient, and hence why you rarely saw this type of operation for multiple access. With 802.11ax the ability to do both frequency and spatial division, the clients can be assigned only the resources necessary for their needs no matter how wide the channel is thus making the use of these wider channels much more effective. In the 2.4GHz and 5GHz bands clients capable of supporting OFDMA had to contend for a slot with legacy clients and of course since it requires more than one client to participate in “multiple access” it would only contend for a multiuser slot if there were multiple clients that could support OFDMA with packets to transfer. At 6GHz all clients support OFDMA and hence no need to contend with legacy clients for access, every slot can transmit multiple packets. With the addition of the 6GHz channels, we will just now begin to fully benefit from the use of OFDMA.

With Wi-Fi 6 the link can now be divided into both bandwidth and time so specific chunks of resources can be “scheduled” for delivery further improving efficiency and latency (see Figure 2 below).

In addition to the improvement of efficiency in the wider band channels the “triggered multi-user access” allows for the scheduling of packets in a much more predictable manner. The 802.11ax standard does not dictate all the necessary details for managing the packet scheduling and hence this is an area where there can be some differentiation in performance between implementations. Cisco, a company with a rich history of packet scheduling and optimization is obviously exploring this area also. For example, in the data below we can see the latency comparison between a typical Wi-Fi 5 network, a Wi-Fi 6 network, and a Wi-Fi 6 network with optimization in scheduling. Notice with Wi-Fi 6 there is a substantial reduction in outlying packets exceeding the 25ms delay bound and with some optimization, a further reduction in latency can be seen. This is an example of the value of optimized scheduling with 802.11ax multi-user capability provides.

Figure 3. Packet Scheduling Improvements

Wi-Fi 6E provided a leap forward in capability. Some we could not fully recognize until 6GHz was made available. Benefits in capacity, latency, and stability are all a part of the 802.11ax update. In addition, vendors like Cisco can provide optimized packet scheduling to further enhance the user’s experience. Deploying Wi-Fi 6E capable access points will allow the operator to begin to experience these significant new enhancements in performance.

Source: cisco.com

Continue reading

Get Hands-on with the Meraki API in the DevNet Sandbox

One of the strongest components of the Meraki platform is the consistent and simplified operational management of the network. The modern API, as an extension to the cloud managed service, makes it amazingly simple to programmatically control and manage all aspects of your network. There are customers that fully automate the onboarding of devices via the Meraki portal using routine automation scripts. Or, front-end systems or operational teams with lookup tools that pull analytics or data from the API. Thus, greatly streamlining operational processes required to support an organization.

This blog will showcase some of the techniques that can be used and built upon to integrate the Meraki API programmatically. To do this we will use the DevNet always-on sandbox lab. With this we will only be making read (get) requests into the always-on sandbox. And to make this easy to use, we are going to use the Google Collaboratory environment, which allows you to use Google cloud to run these examples.

Explore the Meraki API using the DevNet Sandbox

To begin exploring the Meraki API using the DevNet Sandbox, I have created a Collaboratory on Google at the below link. To use this, you will need a few things,

1. A personal Gmail account. This will share a copy of the example that you can modify in drive. If you use your corporate account, it will only allow this if your corporation has drive access.

2. You will then access the link below and file/save a copy into drive, from which point a read only copy will become writable, and modifiable to you.

Here is the link:

https://colab.research.google.com/drive/15qs6TFn8gtsTM0PTUUbuubGLYwHJw8hV

The first thing we will do is save a copy of this read only sheet into your drive, which will make it read/write. From the file menu you can click “save a copy to drive”

Once this is done you can evaluate the sheet. Within this sheet there are text blocks, code blocks, and results blocks. The code blocks are fully modifiable, and represent code running in a real python environment located in the Google cloud. To execute the code within a block, you can click the play button to the left of the block. When you do this, any results will show up.

Where this becomes particularly interesting is when we pair this cloud based development environment with the DevNet always-on Meraki Sandbox. This is a functional Meraki instance sponsored and managed through the DevNet organization. For a list of all Sandboxes, you can evaluate devnetsandbox.cisco.com.

For our particular sandbox, we will be using the always-on sandbox. This is available at the below link, but should this link change, you can find it by selecting networking sandboxes from devnetsandbox.cisco.com. (or searching Meraki, or many other ways :)).

https://devnetsandbox.cisco.com/RM/Diagram/Index/a9487767-deef-4855-b3e3-880e7f39eadc?diagramType=Topology

Setting Variables

What we will do in the below code segments, is we set a few variables we can use further on in the code. This makes it so that you can take your real Meraki environment, and change a few URLS, and search for meaningful information in these variables (such as YOUR device, or YOUR network), and use the code to create tables and graphs that you can modify as you see fit.

After setting the variables, we do a very simple get request from Meraki, that we will do many times for different information throughout the sample on Colab.

We then print the results, which will show up in a text string of JSON data.

To translate this into real JSON we can use, we use the below command and then print it so we can see.

This is exceptionally useful as we have useful data formatted as JSON. Building upon this, we can use a library called Pandas which is well known in the data science and ML communities, and is essentially “Excel on Steroids for Python.” What becomes interesting is its native support for reading in our JSON, into a table.

Using the Pandas module

Below we load the Pandas module as the name pd, which we can reference. We then import the JSON, and print out a table with the columns we are interested in. What is elegant about this is the simplicity, we import the module, read in the JSON in a single intuitive command, and create a table with the headings we are interested in.

After doing a few more operations in the code, following through the colab sheet, we make a few more get requests, store as a few different tables, and do different things. (You can explore the sheet.) We search out the network in the organization that we referenced at the outset of this sheet, and we get the top talkers for this via doing a get on the URI and storing it as JSON. Then importing into Pandas (like below), and spitting out the table.

We now have a list of clients and their bandwidth usage. We can then very easily create graphs for usage. This can also all be done easily via a webapp for your network teams. We do this using the Pandas built-in graph capability, as well as an example of using Seaborn, which is used for data visualization.

This is just a high level of some of the capabilities that can be exposed easily via the Meraki API. The purpose of the colab sheet that was created, as well as the DevNet sandbox, is to enable you to be able to play with and evaluate the API. The examples in the colab sheet are intended to be functional code, and stepping stones that reduce the barrier to leveraging programmability to create meaningful results.

I hope this blog was helpful. It explored using the Meraki API via using the always-on DevNet Sandbox. When you have an always-on sandbox, creating, sharing, and reusing examples in Google Colaboratory is a natural fit.

Source: cisco.com

Continue reading

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

Streamlining Connectivity for a Multi-Region Hybrid World

Multi-region cloud deployments create complexity

The combination of a hybrid cloud migration and the long-term needs of a hybrid workforce are shining a spotlight on the need for consistently secure, high quality access to on-demand compute resources.

Requirements for low latency across geographically distributed workloads, resiliency, and compliance with data privacy regulations are driving organizations towards multi-region deployments in the cloud. While this can be done manually by using VPC peering and static routes, management complexity increases with scale and can be error-prone. To make networks streamlined and scalable, organizations need a dynamic and central way to manage their multi-region deployments.

Multi-region cloud deployments: complex, manual static routes and VPC peering

All the hybrids: cloud and work

Cisco Meraki has a globally-proven cloud platform that unifies secure SD-WAN, Access, and IoT technologies—empowering enterprises to deliver high quality hybrid work experiences. The platform allows secure and optimized SD-WAN connectivity to hybrid cloud environments, including AWS, in just three clicks. This Meraki SD-WAN capability is delivered through MX appliances that are available in physical and virtual (vMX) form factors where the latter can be spun up within AWS. Remote workers can also easily connect to vMX appliances in hybrid clouds with a dedicated teleworker appliance or via Cisco AnyConnect.

For customers making this investment into cloud platforms, there are a few ways they can use Meraki to accelerate their cloud journey with AWS. Specifically, for multi-region deployments, Meraki SD-WAN offers deep integration into the newly launched AWS Cloud WAN service and AWS Transit Gateway to significantly streamline workflows to connect users to their cloud resources. For organizations looking to connect their on-prem sites to workloads across regions, we also announced support for AWS Outposts at AWS re:Invent 2021 in December.

Meraki SD-WAN and AWS Transit Gateway

First, the Meraki vMX integration with AWS Transit Gateway lets customers extend their SD-WAN fabric to AWS workloads in an automated manner using AWS Quickstarts.

Dynamic routes and VPC peering with Meraki SD-WAN and AWS Transit Gateway

◉ The architecture consists of a SD-WAN VPC with two vMXs deployed in different availability zones to achieve a highly available architecture.

◉ In addition, a Transit Gateway (TGW) is deployed to extend connectivity to workload resources across different regions. The SD-WAN VPC is linked to the TGW via a VPC and customers can leverage their existing workflows to connect their workload VPCs to the Transit Gateway.

◉ On the Meraki Dashboard, each vMX is configured as a Hub to the branch sites and statically advertises all of the subnets available in Amazon AWS into Auto VPN.

◉ Finally, an AWS Lambda function is used to monitor the state of the vMX instances and update the SD-WAN VPC and the Transit Gateway route tables for the Auto VPN routes with the appropriate vMX as the next hop.

Meraki SD-WAN and AWS Cloud WAN

AWS recently launched AWS Cloud WAN at AWS Re:Invent. Cisco Meraki is one of the first partners to integrate with the new service. Cloud WAN is AWS’s managed wide area networking (WAN) solution that makes it easy for customers to build, manage, and monitor their global networks across the AWS backbone.

Organizations with Meraki SD-WAN can leverage the new AWS Cloud WAN service to extend their SD-WAN fabric across the unified AWS global network.

Meraki vMX integrates with AWS Cloud WAN to allow admins to define a multi-region, segmented, dynamically routed global network with intent-driven policies. This allows organizations to scale across different regions without worrying about managing the complexity of peering.

Dynamically routed global network with Meraki SD-WAN and AWS Cloud WAN

Instead of having to manage peering connections between different AWS Transit Gateways across multiple regions, a single Cloud WAN core network is deployed that spans across multiple regions with the following:

◉ Core Network Edges (CNE), deployed in each region of the core network

◉ Two segments, one for SD-WAN overlay and one for the customer workloads.

◉ Core Network Policy (CNP), which defines the global configuration of the core network

◉ The SD-WAN VPC and the workload VPCs are connected to the core-network as VPC attachments.

Multi-tenancy and Scale using AWS Outposts

Customers also need a secure way to connect their on-prem sites to workloads across different regions in the cloud. Using Meraki’s vMX solution, customers can easily extend their SD-WAN fabric to their public and private cloud environments.

Customers also need a secure way to connect their on-prem sites to workloads across different regions in the cloud. Using Meraki’s vMX solution, customers can easily extend their SD-WAN fabric to their public and private cloud environments.

AWS recently announced new Outposts Server Form Factors at AWS Re:Invent and Cisco Meraki will be one of the first launch partners to support the 2U servers with vMX (coming soon).

Customers looking for edge computing and even datacenter computing can leverage vMX on Outpost with the benefit of a fully managed infrastructure with native AWS APIs and the simplicity and security of Meraki.

Without Outposts, customers need to procure and manage multiple hardware for compute and networking making management cumbersome and difficult.

If you’re investing in a multi-cloud architecture and need a more scalable, flexible, and manageable SD-WAN fabric, we encourage you to learn more about the Meraki platform. Meraki combines SD-WAN with Wi-Fi, access switching, and IoT on a cloud-native platform that reduces the complexity of building a hybrid cloud architecture.

Source: cisco.com

Continue reading