WiFi-6E 6GHz- WiFi Spectrum Unleashed

In April 2020, the Federal Communications Commission (FCC) allocated 1,200 megahertz of spectrum for unlicensed use in the 6GHz band. That was the largest fleet of spectrum approved for WiFi since 1989. This Opening of the 6 GHz band more than doubles the amount of spectrum available for Wi-Fi, allowing for less congested airwaves, broader channels, and higher-speed connections and enabling a range of innovations across industries. Since the FCC decision to open the 6 GHz band, 70 countries with 3.4B people have approved or have 6 GHz regulations under consideration (Source- WiFi-Alliance)

Currently, as organizations increase their use of bandwidth-hungry video, cope with increasing numbers of client and IoT devices connecting to their networks and speed up their network edge. As a result, wireless networks are becoming oversubscribed, throttling application performance. This frustrates all network users by negatively impacting the user experience, reduces productivity.

Throughout this post, I have tried to cover the basics and the operating rules for Wi-Fi 6E in the 6 GHz band.

What is the “E” in Wifi6E?

The 802.11ax standard (Wi-Fi 6) also operates in the 2.4 GHz and 5 GHz bands. Due to this, Wi-Fi in the 6 GHz band will be identified by the name of WiFi-6E. This naming was chosen by the WiFi-Alliance to avoid confusion for 802.11ax devices that also support 6 GHz. The “6” represents the sixth generation of Wi-Fi and the “E” represents extended.

WIFI-6E: Increase in number of channels

The 6 GHz band represents 1200 MHz of spectrum that will be available from 5.925 GHz to 7.125 GHz. Knowing that 2.4 GHz band only had 11 channels, with the new spectrum, Wi-Fi will have access to 59 20-MHz channels, 29 40-MHz channels, 14 80-MHz channels, and 7 160-MHz channels. In addition to 2.4GHz and 5GHz, this not only represents a lot of channels, but also a lot of wide channels to operate on high speeds.

Advantage of a huge spectrum

Wi-Fi has always had a very less amount of spectrum. Typically, Wi-Fi had only 80 MHz of spectrum in the 2.4 GHz band and 500 MHz in the 5 GHz band. DFS channel occupy a part of the 500MHz on 5GHz band.

This left very limited contiguous spectrum. It made it difficult to find or enable 80 MHz or 160 MHz channel width, but the maximum Wi-Fi data speeds can only be achieved with these channel widths.

With the 59 20-MHz channels, Wi-Fi 6E will effectively remove congestion issues. At least for the foreseeable future, there will always be at least one 20 MHz channel available without congestion. Thanks to the contiguous spectrum and the 14 80-MHz channels or the 7 160-MHz channels to choose from, a radio will be able to find a channel available, free of congestion. This enables the technology to deliver the highest speeds.

Background on Wi-Fi Standards

Two main groups are responsible for shaping Wi-Fi’s evolution. The Wi-Fi Alliance and IEEE. The IEEE 802.11 defines the technical specifications of the wireless LAN standard. The WiFi-Alliance focuses on certification of Wi-Fi devices for compliance and interoperability, as well as the marketing of Wi-Fi technology

Over time, different classifications of WiFi networks were given different naming conventions by the Wi-Fi Alliance. Rather than “802.11b”, it’s just “WiFi 1.” Much like how mobile phone companies refer to 3G and 5G as different network speeds even though the term is almost always just a marketing tool. This classification is supposed to help make it easier for consumers to understand — instead of understanding a whole alphabet soup, users can just look for “WiFi 4” or “WiFi 6” as what they need.

The IEEE 802.11ax standard for high efficiency (or HE) covers MAC and PHY layer operation in the 2.4 GHz, 5 GHz and 6 GHz bands.

IEEE Rules for WIFI-6E

HE (High Efficiency) only operation in the 6 G

One of the most important decisions made by the IEEE 802.11ax group is that it disallows older generation Wi-Fi devices in the 6 GHz band. This is very important because it means that only high efficiency 802.11ax devices will be able to operate in this band.

Generally, upcoming Wi-Fi standards have always provided backward compatibility with previous standards. This was a boon to customers as well as vendors, since network equipment doesn’t need to be completely overhauled at each new standard. The flip side to this is it will be a source of congestion on the protocol, since legacy equipment is also sharing the available spectrum with the newer devices. In the 6 GHz however, only new high efficiency devices will be allowed to operate.

When using the analogy of road transport to describe Wi-Fi, the 2.4 GHz and 5 GHz band can be compared to congested roads where both fast and slow vehicles travel, while the 6 GHz band is the equivalent of a new, large highway that only allows the fastest cars.

Fast Passive Scanning

With 1200 MHz of spectrum and 59 new 20 MHz channels, a station with a dwell time of 100 ms per channel would require almost 6 seconds to complete a passive scan of the entire band. The standard implements a new efficient process for clients to discover nearby access points (APs). In Wi-Fi 6E, a process called fast passive scanning is being used to focus on a reduced set of channels called preferred scanning channels (PSC). For 6 GHz-only operation, a specific subset of channels will be identified as preferred scanning channels (PSC) where the primary channel of a wide channel BSS should reside, limiting the channels a client needs to scan to discover a 6 GHz-only AP. PSCs are spaced 80 MHz apart, so a client would only need to scan 15 channels

Out of band discovery

Dual-band or tri-band APs operating in the 6 GHz band as well as in a lower band (2.4 GHz or 5 GHz) will be discoverable by scanning the lower bands. In the lower band, APs will include information about the 6 GHz BSS in a reduced neighbour report in beacons and probe response frames. The client will first go into the lower bands, discover the AP there and then move to the 6 GHz band. This will reduce the probe requests that are sent by stations just trying to find APs because it will not be allowed unless it is a PSC channel.

Wi-Fi 6E Channelization

The 802.11ax standard defines channel allocations for the 6 GHz band. This allocation determines the center frequencies for 20 MHz, 40 MHz, 80 MHz, and 160 MHz channels over the entire 6 GHz band. However, regulatory domains specifications take precedence over the IEEE specification and channels that are falling on frequencies or overlapping on frequencies that are not supported in a regulatory domain cannot be used.

AFC and Avoiding Incumbent Users

The FCC defines two types of device classifications with very different transmit power rules. The goal here is to avoid potential interference with existing 6 GHz incumbents. Several classes of APs are being defined to adapt to the U-NII bands and conditions where they will be operating. The standard power (SP) AP and the low power indoor (LPI) AP and very low power (VLP) AP. The low power APs, as the name implies, have reduced power levels since they are only used indoors.

The outdoor, or standard power APs, have a serious potential of interfering with existing 6 GHz users in the geographic area. Fixed satellite services (FSS) used in the broadcast and cable industries might already have a license for the channels in use. Therefore, any new unlicensed users (Wi-Fi) must ensure they do not impact the current services. The answer to this is to create a way to coordinate the spectrum use to avoid interference issues. The basic concept would be that a new wireless device (access point) will consult a registered database to confirm its operation will not impact a registered user. For 6 GHz operation, this is called an Automated Frequency Coordination (AFC) provider.

Standard power APs must use an AFC service to protect incumbent 6 GHz operations from RF interference.

Source: cisco.com

Continue reading

Miercom validates deployment simplicity of Cisco’s SASE solution

With the digital transformation of businesses, security is moving to the cloud. This is driving a need for converged services to reduce complexity, improve speed and agility, enable multicloud networking and secure the new SD-WAN-enabled architecture. Secure Access Service Edge (SASE) is the convergence of networking and security that is transforming the way organizations are delivering these services from the cloud. One of the key functions in SASE is SD-WAN that enables customers to connect users securely to applications and data regardless of location. Miercom recently did an independent study validating the setup simplicity of Cisco SD-WAN powered by Viptela with Cisco Umbrella integration, offering customers a foolproof, intelligible and complete Secure Access Service Edge (SASE) solution. 

Read More: 350-901: Developing Applications Using Cisco Core Platforms and APIs (DEVCOR)

In today’s fast paced technology driven world, customers want a simplistic and seamless experience and expect the solution to be easy to deploy right from day 0 to day N setup. Cisco’s solution is simple to setup, intuitive and includes a true zero-touch SD-WAN solution that is faster to deploy and configure. Conversely, Competition setups are complex with multiple touchpoints which require manual intervention with no automated process, lacks template-based guided workflows and is more confusing to navigate. Cisco offers a cloud-hosting subscription where customers can self-provision SD-WAN controllers after order submission through a simple workflow on Cisco SD-WAN self-service portal (SSP) which incorporates vManage, vSmart and vBond in public cloud with secondary vBond and vSmart for high availability on desired region. The customers can sit back and relax while control plane/management plane setup is done via the cloud infrastructure automation tool and without any support intervention. Cisco’s SD-WAN integration with Cisco Umbrella via Cisco Smart Account licensing allows for template-based configuration workflows and automated secure tunnel deployment between SD- WAN routers and the nearest Cisco Umbrella data center. As validated by Miercom, Cisco proved more efficient in unified management mostly from a single platform (vManage), making it simple for even lean IT teams to manage via preloaded templates and troubleshooting features.

Conversely, the competition offers complex integration between its SD-WAN and cloud security offerings which involves multiple touchpoints/steps making the process time consuming and requires support intervention at multiple stages during setup. To start with, the competition requires multiple accounts leading to complexity for customers even before entering the deployment stage. Also, during the deployment stage, lot of technical expertise is required in terms of integration process of the competitive SASE solution, making it complicated for customers. Also, the competition requires support intervention in multiple stages during the Day 0, Day 1 experience that it takes days instead of a couple of hours for the whole deployment process. 

 Cisco also provides multiple browser options (i.e., Google Chrome, Safari, Firefox), providing flexibility to customers for accessing the vManage dashboard. Cisco vManage dashboard offers customers a network topology with guided workflows for troubleshooting to make it easy for customers to remediate issues. The competition out there has browser dependencies and does not offer the same flexibility as Cisco. Troubleshooting process for competition was proven to be basic and ineffective by Miercom. 

 When we look at Cloud OnRamp IaaS/SaaS setup, Cisco provides template-based configuration workflows within Cisco vManage that, once complete, integrates with AWS to automatically deploy virtual instances of Cisco SD-WAN routers within defined AWS data centers. These routers are deployed with redundancy and dynamic routing services. When it comes to the competition, Cloud OnRamp for IaaS/SaaS has a manual configuration process, with no templates or automated workflows for ease of deployment.

Finally, Cisco SD-WAN presents the customer with plethora of deployment options for the control/management plane which the competition fails to offer. Customers can either choose to deploy the SD-WAN controllers on their premises with virtual machine options or they can utilize the Cloud Ops deployment – a completely cloud-hosted solution where every component of the control plane is deployed transparently by Cisco and handed over to the customer for management. 

Cisco Viptela SD-WAN with Umbrella offers an easy to deploy, flexible, robust and cost-effective SASE solution making it a perfect choice for customers.

Source: cisco.com

Continue reading

Trust Analytics and Anti-Spoofing Protection: It’s Already in Your Network

Nearly every day we can read about “ransomware” holding another organization’s data hostage, shutting their operations down, or disrupting their supply chain. Commercial enterprises. Major utilities. Large healthcare providers. Processing facilities. Even small businesses aren’t safe from being the target of these attacks.

The key to preventing your organization from falling prey to ransomware is to keep several steps ahead of hackers. In many cases, the tools you need to protect your data are already available in your network. With the recent introduction of Continuous Trusted Access and the new Cisco Trust Analytics you can now secure your network from several potential attack vectors.

Trust Analytics is part of Cisco SD-Access, Cisco’s best-of-breed Zero Trust solution for the workplace. Trust Analytics detects traffic from endpoints that are exhibiting unusual behavior by pretending to be trusted endpoints using MAC Spoofing, Probe Spoofing, or Man-in-the-Middle techniques.

When anomalies in the network are detected (see Figure 1), Trust Analytics lowers the Trust Score for the endpoint to limit or completely deny access to the network through integration with Cisco Identify Services Engine (ISE). In this blog, we will describe how Trust Analytics can help to secure your network.

Figure 1: When anomalies in the network are detected, Trust Analytics lowers the Trust Score for the endpoint to limit or completely deny access to the network.

Device Spoofing

One tactic used by hackers and ransomware to gain unauthorized access to a network is to take over or spoof the identity of a trusted device. An example of an identity takeover is when someone opens an email and unleashes ransomware that gives control of the device to hackers. The ransomware then moves laterally through the network, infecting as many devices as possible. The spread of ransomware can be very fast, shutting the network down before IT is even aware of the threat.

An alternative to taking over a device is to spoof or steal its identity. In this case, a rogue device pretends to be a trusted device to gain access to the network. Common methods for spoofing endpoints include:

MAC spoofing is a means for stealing the identity of an endpoint. Trusted endpoints are identified either by a secure method like 802.1x authentication or by a simple list of trusted MAC addresses such as with MAC Authentication Bypass (MAB). MAB is useful for authenticating IoT devices that are not capable of 802.1x or that do not have a user. However, MAB leaves an opening for a rogue device to impersonate the MAC address of an authorized endpoint to gain that device’s access and privileges. Often, the hacker will disconnect the authorized endpoint, making the attack easier to carry out and harder to detect.

Probe spoofing involves a rogue device pretending to be a legitimate endpoint of a trusted class like IP phones and video cameras. Often these devices are identified from their traffic profile (i.e., MAC address manufacturer, DHCP options, etc.) By impersonating a trusted class of device, a rogue device may be able to gain privileged network access.

Man-in-the-Middle spoofing is an attack where the rogue device is physically inserted between the endpoint and access point (AP). The endpoint is still able to communicate with the AP but now the rogue device can inspect traffic and inject traffic into the flow.

Zero Trust

When a rogue device successfully spoofs the identity of an endpoint, it is able to exploit the trust the endpoint has been granted. The best defense, then, is to dynamically assess the trustworthiness of each endpoint. This is a key pillar to deploying a “zero trust” network. Certainly, devices must be granted trust so that work can get done. However, because spoofing is a potential threat, the trust for each device must be reevaluated on a continuous basis.

Figure 2: A hacker attempts to spoof the identity of a camera to gain network access. When the hacked camera begins to uncharacteristically reach out into the network, the anti-spoofing engine identifies the activity as an anomaly. The Trust Score for the hacked camera is then dynamically adjusted to prevent the device from communicating with other devices and spreading ransomware.

Figure 2 shows how the trust level of devices can be continuously monitored in a network. In this example, a hacker has taken over or spoofed the identity of a camera. The hacker then attempts to use the network access and privileges granted to the camera to gain further access into the network.

In this case, however, anti-spoofing detection is in place. The camera is part of a trusted class of device with well-known operating characteristics which have been captured in a baseline profile. Through artificial intelligence (AI) and machine learning (ML), the Cisco anti-spoofing AI/ML engine verifies that current operation matches expected behaviors.

A fully trusted device (Trust Score of 10) has full access and privileges. When the hacked camera begins to uncharacteristically reach out into the network, the anti-spoofing engine identifies the activity as outside of the camera’s baseline.

As the device deviates from its baseline, its Trust Score dynamically drops. At a Trust Score of 4 to 7, for example, network access could be limited by dynamically changing the device’s Scalable Group Tag (SGT). This could allow the device to continue to send data but with all privileges revoked until the device can be evaluated or a remediation action taken. In the case of a camera, network access could be limited to providing video tagged with an alert while peer-to-peer traffic is halted to prevent the device from communicating with other devices and spreading ransomware. At a low level (Trust Score of 1 to 3), the device may be denied access altogether until the cause of its rouge behavior can be identified.

The engine also evaluates activity in terms of other factors that can impact the Trust Score, including threat metrics, known spoofing behaviors, vulnerability status, anomalous behavior, and posture metrics. Depending upon the result, the anti-spoofing engine may dynamically adjust the Trust Score for the device.

Anti-spoofing is powerful technology and, as part of Cisco SD-Access, works in conjunction with other Cisco security solutions to better protect your organization. Because anti-spoofing detection is implemented on a device-by-device basis, only the device deviating from its baseline has its Trust Score, network access, and privileges reduced. In addition, deviations are detected as they happen, enabling a Cisco SDA-enabled network to take immediate action to isolate hacked devices and prevent a full ransomware outbreak. This is Cisco’s Continuous Trusted Access.

Already in Your Network

Trust Analytics is yet another powerful tool from Cisco for deploying secure networks. The anti-spoofing capabilities of Trust Analytics are a part of Cisco Software-Defined Access, a solution with Cisco Digital Network Architecture (Cisco DNA). With these technologies, IT can manage the complete lifecycle for Zero Trust to better protect their network.

One of the best things is that Trust Analytics, through DNA Center, is already in your network. You don’t have to add a new box or start a new subscription to deploy Cisco’s AI/ML spoofing detection and protection. All it takes is enabling the capability under endpoint analytics in DNA Center.

Leverage the full power of your Cisco network to provide better security through DNA Center.

Source: cisco.com

Continue reading

Preventing Network Loops! A Feature You Need to be Aware of

No matter how secured or precise the configurations are, there are some problems you can’t almost avoid, particularly L2 loops. The looped frames have no TTL to decrement and nothing else to lose. It unleashes at a perfect time, a critical production hour or perhaps Friday nights!

A common approach is to tighten STP configuration and enable BPDU guard, root guard, loop guard, Unidirectional Link Detection (UDLD), storm-control or disable unused ports, where ever applicable.

Even with the right configurations in place, incorrect STP port transitions, hardware issues, misplaced root bridge etc., can still cause loops. And not to forget the mysterious unmanaged switches that occasionally show up on the network.

The STP loopguard will only react if a root or Alternate port stops receiving BPDUs. But nothing that explicitly detects and stops an ongoing loop.

One such feature is the Loop Detection Guard on the catalyst 9000 switches. The function is simple, send a frame out of one port and see if it returns on another. The feature is introduced on 17.2.x & later releases and supported on all Catalyst 9000 platforms.

So how does the Loop Detection Guard work?

A port enabled with Loop Detection Guard sends out a loopback frame and checks if it returns to the switch. If it does, the switch error disables source port or destination port, whichever is the configured action. The loop detect frames are L2 frames with Ethertype loopback. The loopback frames have the source interface mac as the source mac and switch base mac address as the destination mac.

A recipient device typically drops these frames as the destination MAC address is different. If the frame is forwarded back to the originating switch, the loop detect guard will kick in.

The loopback frames are untagged, it doesn’t matter what VLAN the frame is sent on, it just shouldn’t return to the originating switch.

Configuration & Implementation Flexibility

The configuration guide for Loop Detection guard provides the CLI and options. The loop detection guard feature needs to be defined explicitly per port. Unlike STP, there’s no global configuration line for this feature and there is a good reason why; you will know as you read on.

Strictly speaking STP should prevent loops at the first place; but if STP fails for any reason and causes a network loop, the loop detect guard (if enabled) can kick in to stop.

On detecting a loop, option to disable either the source or the destination port provides implementation flexibility. What that means is the feature can be enabled on only key ports of a switch and let the feature take action on rest of the other ports.

Let’s say there is a loop in the network between the uplink and one of the downlink ports. The Loop Detect Guard can be enabled only on the uplink ports. And if the actionable port is set to destination port, it will err-disable the downlink port that is participating in a loop with the uplink. The downlink ports need not have this feature explicitly enabled.

The loop detection guard can be configured on all ports as well, but the configuration is simpler if it is enabled only on the uplink or any other key ports and let the feature take action on the downlinks. I recommend it to be tested before it is implemented in production.

STP Loopguard vs Loop Detection Guard

Here’s a quick comparison of feature names and its functions:

If a port configured with STP loopguard stops receiving BPDU’s, the blocked port will transition to loop-inconsistent state only after max age expires. At this point ports stop processing user traffic until BPDUs arrive.

Loop detection guard has default timer value at 5 seconds and configurable maximum of 10 seconds. The loop detect feature reacts to a loop more quickly than STP loop guard and provides option to shut down only ports in question.

Source: cisco.com

Continue reading

Practical Study Tips for CCNA 200-301 Exam Prep That Includes Practice Tests

Getting through a Cisco Certification exam is not as simple as any other certification exam you can think of. Professional with Cisco CCNA 200-301 certifications are not just intended to connect a few monitors to several CPUs or server systems but are expected to build and manage a networking system that requires constant monitoring. That’s why Cisco CCNA 200-301 exam is designed so that an applicant with comprehensive networking skills and knowledge could only crack the exam.

When you own a certification like CCNA in front of you to pass, you must possess great knowledge of the subject. Be it CCNA tutorial, PDFs, Official books, or certified trainer’s guidance; you need all of them to pass the certification exam on the first shot.

Why Get CCNA 200-301 Certified?

Professionals today actively engaged in the networking domains go for Cisco certifications to prove their knowledge and boost the possibilities of getting hired. As, 

• A substantial percentage of organizations globally use Cisco products and services and so demand professionals with CCNA certification and distinct skills to execute, install, monitor, and manage them. 
• Cisco CCNA certification delivers you the skills you require to launch your career in the networking domain and grants you the appreciation you need. 
• CCNA exam syllabus is consistently updated corresponding to the most recent in networking; passing the exam is an amazing way to hold your importance.
• CCNA certified professionals get a better salary than non-certified professionals. Also, they are proposed exciting job opportunities consisting of mentorship and leadership positions at the workplace.

Here are some tips which will assuredly work for CCNA 200-301 Exam with a proper approach:

1. Trust Yourself

Entitle yourself with a frame of mind for excellence to pass the Cisco CCNA 200-301 qualifying exam and thus pass them with excellent scores.

2. Learn from Valid Resources

Cisco Self-learning resources will enhance your learning with profound knowledge and equip you with so-craved confidence. Though these resources can’t be contemplated as a developed learning set, they shall work as a sturdy learning portal. Engage in the Cisco study group to boost your study with peers.

• E-learning. There are many online resources readily available for Cisco exam preparation. You can find online training courses, Ebooks, study guides, and much more. According to your learning preference, choose the study resources wisely.
• Hands-On Practice. Try to pass your CCNA exam through the actual certification path or benefit from Cisco learning labs for the 200-301 exam.
• CCNA 200-301 Practice tests. Practice tests are the best means when evaluating your knowledge gaps because answering the questions can help you interpret your weak areas. You can get the best and updated practice tests from the trusted platforms. Practice tests are created to feel the absolute exam presence and thus test themselves in an actual environment.

3. Study the CCNA 200-301 Exam Structure and Summarize the Information

This is one of the most critical steps you should consider in your preparation process. Having a picture of the exam is a perfect technique of getting prepared to answer the CCNA exam questions correctly.

Final Takeaway

Cisco certifications are universally acknowledged when it comes to networking technology. Passing the CCNA 200-301 certification is an ideal step in penetrating the world of technology. The skills you gain with passing Cisco 200-301 are all you need to solve real-world problems.

Make your career discovery by obtaining the CCNA certification and get prepared with practice tests and other valid study resources available on reliable platforms!

Continue reading

Nanosecond Buffer Visibility with Hardware-Based Microburst Detection

What Are Microbursts and Why Do They Matter?

Ever wondered why a switch interface shows an average utilization of well below wire rate, and yet egress discards are incrementing? Most likely, that interface is experiencing microbursts. Often, when multiple input interfaces simultaneously receive traffic destined to a single egress interface – a so-called “incast” traffic pattern – no problem arises because the instantaneous receive rate is low enough that the output interface can handle the load.

The term “microburst” refers to the same situation, but where the receive rate of those interfaces in aggregate exceeds the wire rate of the output interface for some time. In this case, the excess traffic must be buffered. If enough such traffic arrives simultaneously, the buffer on the output interface can fill and potentially overflow, resulting in discards. Figure 1 illustrates the microburst concept.

Figure 1: Microburst Concept

In the example shown in Figure 1, three interfaces simultaneously receive a series of back-to-back packets with a minimum inter-packet gap (IPG). The destination must transmit those packets but can only transmit at the maximum rate of the output interface. In this case, all four interfaces are the same speed, so the transmit interface is forced to buffer the excess traffic. If the burst is short-lived, the transmit interface will eventually empty the buffer and only a small latency penalty is paid. But if these traffic bursts last long enough, the buffer can overflow, resulting in egress discards. While at times packet drops are benign or at least productive – for example, randomly dropping frames to prevent congestion buildup while avoiding TCP window synchronization – they can also negatively impact application performance, not to mention simply causing concern among network operations staff.

If egress interface discards are incrementing, how can it be confirmed that microbursts are indeed occurring, and if so, how often and how long-lived they are? Is congestion only occasional, or is a given interface perennially congested, which might warrant workload redistribution, configuration changes, or other action? Traditional methods such as monitoring interface counters do not offer the needed visibility – such counters are typically read by software at relatively long intervals (often 10 seconds or more) and therefore tend to “smooth out” bursty traffic patterns. That’s where the Cisco Nexus 9000 series Data Center switches come into the picture.

What Is Hardware-Based Microburst Detection and How Does It Work?

Cisco Nexus 9000 series Data Center switches, including both fixed-form-factor Nexus 9300-EX/FX/FX2/FX3/GX (as well as the 9364C and 9332C) and modular Nexus 9500-EX/FX/GX platforms, provide advanced hardware capabilities that make detecting and measuring microbursts easy. Based on custom Cisco silicon known as the Cloud Scale ASIC family, these switches provide granular per-interface per-queue monitoring for hard-to-identify traffic microbursts, for both unicast and multicast traffic.

Each queue is instrumented with trigger-based microburst measurement capabilities. When the buffer utilization for a monitored queue crosses a configurable “rising” threshold, the silicon captures the exact moment that threshold was reached using a nanosecond granularity timestamp; as the buffer continues to fill, the “peak” depth of that queue is recorded along with another timestamp; and finally, as the queue drains, a third and final timestamp is recorded as the queue drops below a “falling” threshold. The result is a series of raw records that looks like the output in Figure 2.

Figure 2: Raw microburst records (NX-OS)

Consuming Microburst Data for Analysis

Now that we’re able to detect when, how often, and how severe microburst activity is, what can we do with that data? Of course, you can always observe the burst data directly on the switch (running NX-OS software), using the “show queuing burst-detect” command. This option is the most basic and may suffice for certain situations – a quick spot check of activity on an interface or queue for example – but in most cases, you’ll want to retrieve the data from the switch for consumption and analysis by other systems.

The powerful streaming telemetry capability in NX-OS software offers an excellent option for getting microburst data off of the switching infrastructure and into other systems for further analysis, trending, correlation, and visualization. NX-OS software streams telemetry data using JSON or Google Protocol Buffer (GPB) encoding over a variety of transport options, allowing platforms provided by Cisco, third parties, or developed directly by IT to easily ingest and parse the data generated by the switching infrastructure.

The Cisco Nexus Dashboard Insights application easily handles configuration, consumption, and analysis of microburst data from one or more switch fabrics—both NX-OS based as well as ACI based—quickly alerting network operators of excessive microburst activity across the network. Figure 3 shows an example of a microburst-related anomaly generated by Nexus Dashboard Insights upon observing multiple microburst events occurring on a given interface over a short period of time.

Figure 3: Nexus Dashboard Insights Microburst Anomaly

As shown in Figure 3, Nexus Dashboard Insights not only identifies the device, interface, and queue experiencing microbursts, but also correlates those burst events to monitored flows traversing the interface that may have contributed to the burstiness, based on flows with the largest measured max burst values. This detailed information provides an unprecedented level of visibility into network behavior, enabling network operators to quickly identify and remediate congestion hot-spots network-wide.

Key Takeaways

Sometimes, the whole is greater than the parts – that’s certainly the case with the advanced hardware capabilities of Cisco Nexus 9000 series switches, the standards-based streaming telemetry provided by NX-OS, and the cutting-edge microservices-based Day 2 Operations functions provided by the Nexus Dashboard Insights application. Together, these technologies greatly simplify the process of identifying congestion in the network before it becomes a significant problem, making network operations teams more productive and more effective than ever before!

Source: cisco.com

Continue reading

Reinventing Small to Medium Wi-Fi 6 Deployments

As many organizations are looking at wireless refreshes that include both expansion and upgrades to Wi-Fi 6, those with small, medium or branch locations have some cool (and very useful) new options to consider and should seriously rethink the deployment model.

Historically, small, medium and branch wireless deployments have been an operational challenge for many organizations. Some of those challenges include:

◉ Solution cost including procurement, deployment, and maintenance,

◉ Management complexity

◉ Lack of visibility into the user experience

◉ Limited feature sets, including security limitations, that force a compromise on features in smaller sites to uphold cost effectiveness

◉ Approaching smaller sites as home Wi-Fi setups for lack of better solutions

I wanted to emphasize that size does not matter, meaning that the deployments representing smaller locations can easily represent significant cash flow where user experience is key.  I have personally struggled in the past with the need to purchase multiple wireless controllers for sites with 10 to 20 access points.

Today, things are looking a little different for smaller enterprise grade deployments. Cisco’s latest enhancements of the Cisco Embedded Wireless Controller (EWC) licensing model means its easy and cost effective to deploy these smaller networks without the need for a physical or even a cloud-based controller. Some might say it’s a game changer, and for those with small to medium wireless deployments up to 100 access points, it really is.

It is important to note that 100 access points is a large site. In my opinion, most deployments will consist of a handful of access points but it’s good to know the EWC can scale up to 100 APs if needed. Add in Cisco’s recent announcement that AireOS is going into sunset mode and you can see why EWC is a much-needed solution to support smaller sites. It also provides an exit strategy for some of the smaller site controllers like the 2504.

Full featured wireless controller integrated into the AP

As stated earlier, I think it is time to reinvent how we think and deploy these smaller wireless networks. With EWC we have the full enterprise features and management capabilities of a standalone (HA capable) controller(s), integrated into the Cisco Catalyst 9100 series access points. Previous embedded solutions were somewhat cumbersome to use and suffered feature parities, I know this because I’ve used them. With the latest EWC capabilities, Cisco really scored a home run thats worthy of taking a closer look at.

The EWC leverages the same IOS-XE software that runs on the Cisco Catalyst 9800 wireless controllers, so what you get is essentially controller without the appliance or licenses. And beyond supporting Catalyst APs, the EWC also supports many of Cisco’s existing AC Wave 2 access points including the 18xx, 28xx, 38xx, 48xx. While these Aironet APs can be part of the EWC network serving clients, they cannot function as the EWC controllers, that privilege is reserved for the Catalyst 91oo series access points.

With the EWC you can move to the new 9800 platform and still make use of your older access points.

Getting started

I find it’s best to start by adding two Catalyst 9100 EWC access points to your network as an HA controller pair. This gives you the flexibility to upgrade the rest of the access points as needed, on your timeline and budget. Making the migration process even easier, the EWC GUI has a configuration conversion utility that allows you to take your AireOS configuration and migrate it to the new Catalyst 9800 wireless controller platform configuration; it’s a quick process that saves a ton of time and effort. What makes this solution especially cool is that the EWC access points can be used as both a controller and to service clients, without any noticeable lag or experience issues.

Requirements and settings

The EWC deployment resembles FlexConnect local switching mode, meaning the controller is only the control plane and all data originates from the wireless access points onto the network. You can change the access point mode to a trunk interface if you use AAA override or utilize multiple VLANS.

While you can run the EWC network with a single access point, if you installed at least two Catalyst EWC access points, they auto enable High Availability mode and if the wireless network can continue to operate and be fully managed if one of the EWC access points becomes unavailable.

Now given the EWC is running the Cisco Catalyst 9800 software you have full access to all the enterprise features you would expect. This includes DNA Center for monitoring, Assurance, AI/ML and management, DNA Spaces for location services and engagement. For sites with higher security requirements, Cisco Umbrella is also available. Please note, these capabilities do not come standard with the EWC and require additional licensing, and in the case of DNA Center, a physical appliance.

What else is exciting, is that with the purchase of DNA licensing, you can turn on the multi-site management feature. This means that you can have multiple sites each with at least one EWC access point and manage them as a single network across all sites. This allows for some level of wireless service survivability if one of the sites loses connectivity to the WAN but still has Internet access. Multisite capabilities can also create a uniform user experience across all sites.

What comes standard the EWC is a host of tools that make setting up and maintaining your small but critical wireless network easy and cost-effective while providing Cisco enterprise-class features, security, and reliability.

Source: cisco.com

Continue reading