Wireless Security Solutions Overview

Enterprise network is undergoing digitization through multiple technological transitions that include explosion of connected and IoT devices in the network and the movement of applications and services to the cloud. Of the 29.3 billion networking devices that are forecasted to be seen in the network by 2023, 50% are expected to be IoT devices. Cloud based applications and services are expected to be accessed from multiple sites and locations, both on and off of the Enterprise network. These new trends and network transitions have not only increased the threat surface but also has advanced the sophistication of the attacks. Securing and protecting the Enterprise infrastructure has become top of the mind for network administrators and customers. With the advances and ratifications in the Wi-Fi standard, wireless has become the de facto standard of access technology in the Enterprise network. However, due to the inherent nature of the wireless networks, it becomes even more important to detect and protect not only the network infrastructure and users, but also to secure the air.

Wireless Security Solutions

At Cisco, all solutions are built with end-to-end security in mind. In this blog, we discuss some of the security initiatives and solutions that play a role in securing the Enterprise wireless networks. These components form various pieces of the security puzzle addressing over the air security, infrastructure security and provide end-to-end visibility.

Securing the Air using Rogue Management and aWIPS Solution

Rogue management and Advanced Wireless Intrusion Prevention System (aWIPS) is a wireless intrusion, threat detection and mitigation mechanism that secures the air. Rogue management solution provides protection against AP impersonation, AP Mac spoofing, Honeypot and Rogue on wire. Auto/manual containment enables the attacks to be contained before the actual damage happens. Rogue and aWIPS together provides security against denial-of-service attacks, management frame attacks and tools-based attacks to name a few.

Rogue Management and aWIPS Solution

Rogue Management and aWIPS solution architecture comprises of:

◉ Access points: Monitors the air and detects threats using advanced configurable signature-based techniques

◉ Wireless controller: Configures the access points; receives aWIPS alarms and rogue information from the AP; does rogue classification and sends consolidated report to the Cisco DNA Center

◉ Cisco DNA Center: Provides simple and intuitive dashboard for configuration and customization of aWIPS and rogue rules. Cisco DNA Center also monitors, aggregates and consolidates events and alarms in a single pane of glass

In conjunction with Cisco DNA Center, users can customize the Rogue detection and management and also fine-tune aWIPS signatures and thresholds based on individual network needs. To meet compliance requirements and also for post-analysis of the attacks happening in the network, per-signature forensic packet capture knob is provided through Cisco DNA center. DNA Center aggregates, correlates and summarizes the attacks across the managed network on the unified Rogue management and aWIPS dashboard.

Device profiling with Endpoint-Analytics

As we embark the new wave of digital transformation, more and more devices (including IoT devices) are being added to the network. A malicious user in the network is just required to find a single vulnerable entry point in the network to breach and exploit the entire network. Once that is done, the threats can spread throughout the network from device to device in a matter of seconds. Such vulnerabilities in the network mandates granular network segmentation thereby preventing the lateral spread of threats. The first step towards achieving granular network segmentation is to identify and profile the devices and endpoints that are present in the network so that segmentation and other policies can then be enforced on these groups of devices. 

Cisco AI Endpoint Analytics is the next-generation endpoint visibility solution. It gathers context from the network and enables the visibility of the endpoints to the administrator through “behavioral-based device classification”. Following techniques are used to achieve that:

◉ Deep packet inspection (DPI): uses enhanced NBAR technology to inspect and understand the applications and the protocols the endpoints are sending over the network to gather deeper context on the endpoint

◉ Machine Learning (ML): constructs for intuitive grouping of the endpoints which have common attributes 

◉ Integration with Cisco and third-party products for additional context

Cisco AI Endpoint Analytics

Cisco’s DPI based profiling capabilities is supported in Catalyst 9800 series Wireless Controller platforms. The controller does deep packet inspection and generates telemetry data to the DNA Center to perform analytics. This enables the users to group the endpoints for segmentation and policy enforcement.

Insight into Encrypted Traffic using Encrypted Traffic Analytics 

The rapid rise in the encrypted traffic is changing the security landscape. A significant number of services and applications are using encryption as the primary method for securing information. As a result, malware detection using traditional flow monitoring techniques will no longer be feasible. Traditional way of inspecting the flows with decryption, analysis and re-encryption is not always feasible and also compromises on data integrity and privacy. Encrypted Traffic Analytics (ETA) provides insight into the encrypted traffic without decryption using passive monitoring. This insight enables us to identify and detect malware present in encrypted network connections. 

Cisco Secure Network Analytics

Encrypted traffic analytics (ETA) extracts four data elements: Initial data packet (IDP), sequence of packet lengths and times, byte distribution and TLS-specific features. These four data elements are embedded as vendor-specific data elements in enhanced Netflow records and are sent to Cisco Secure network analytics engine for further analysis. Secure network analytics analyzes these new data elements by applying machine learning algorithms and statistical modeling techniques to pinpoint malicious patterns in the encrypted traffic and help identify threats.

Cisco Catalyst 9800 Wireless Controllers support exporting of the enhanced Netflow records to security network analytics engine for further analytics and threat detection.

Securing the Network using Umbrella 

Cisco Umbrella is a cloud delivered network security service that uses DNS queries to determine if traffic to a particular domain should be allowed, dropped or needs to be inspected further. Cisco Umbrella uses DNS to stop threats across all protocols and ports. It stops malware and attackers (in real time) if infected machines connect to the network. Cisco Umbrella uses evolving big data and data mining methods to proactively predict attacks and does category-based filtering. 

Cisco Umbrella Solution with Catalyst 9800

Cisco 9800 Wireless Controllers and Cisco Embedded Wireless Controllers (EWC) support Umbrella network security service. WLC intercepts the DNS requests from the clients and redirects the queries to the Cisco Umbrella server in the cloud, along with the identity. The Umbrella service resolves the query and enforces category-based filtering rules on a per-identity basis. Policies can be enabled on individual SSIDs with separate policy for each SSID.

Umbrella can be enabled using DNA center dashboard and can be actively monitored using simplistic statistics dashboard. Umbrella enables customers to block threats at DNS layer and secures endpoints and users.

Nano Segmentation with User-Defined Network

Wireless being a shared network, there is no easy way for an end-user to communicate only with his devices or deterministically discover and limit access to only the devices that belong to them. This results in security concerns where in, a user knowingly or unknowingly may take control of devices that belong to other users.

Cisco User Defined Network

Cisco’s User Defined Network (UDN), enables simple, secure and remote on-boarding of wireless clients on to the shared network environment to give a personal network-like experience. UDN allows an end-user to create their own personal network, consisting of only their devices thereby enabling End-User driven network segmentation. This will help in limiting service discovery scope, realize traffic segmentation and enforcing of access control policies at a group level. This creation of nano-segments in a shared media provides a closed group. In addition, UDN’s ability to invite other trusted users into their personal network gives them the ability to collaborate and share their devices with select set of friends. 

Cisco’s UDN solution is supported on Catalyst 9800 controllers in centrally switched mode. Wireless controller along with the APs enables the containment of link-local multicast and broadcast traffic and optionally unicast traffic. This solution works with both Cisco and 3rd party switching infrastructure and for both IPv4 and IPv6 traffic. The SSID on which UDN profile can be enabled should have either MAC-filtering enabled or should be an 802.1x SSID.

Security is the first line of defense for protecting users, devices and data from malicious actors. The wireless security solutions discussed above detect and protect the users, devices, applications and data. It addition, it enables traffic segmentation along with end-to-end user and application visibility and network analytics.

Source: cisco.com

Continue reading

Make Your Career Bright with Cisco 350-801 CLCOR Certification Exam

Cisco CLCOR Exam Description:

This Cisco CCNP Collaboration exam tests a candidate's knowledge of implementing core collaboration technologies including infrastructure and design, protocols, codecs, and endpoints, Cisco IOS XE gateway and media resources, Call Control, QoS, and collaboration applications. The course, Implementing Cisco Collaboration Core Technologies, helps candidates to prepare for this exam.

Cisco 350-801 Exam Overview:

• Exam Name- Implementing Cisco Collaboration Core Technologies
• Exam Number- 350-801 CLCOR
• Exam Price- $400 USD
• Duration- 120 minutes
• Number of Questions- 90-110
• Passing Score- Variable (750-850 / 1000 Approx.)
• Recommended Training- Implementing Cisco Collaboration Core Technologies (CLCOR)
• Exam Registration- PEARSON VUE
• Sample Questions- Cisco 350-801 Sample Questions
• Practice Exam- Cisco Certified Network Professional Collaboration Practice Test

Related Articles:-

• Which is the Simplest Way to Pass Your Cisco 350-801 CLCOR Exam
• Your Journey to Being CCNP Collaboration 350-801 Certified Made Easier
• Know the Study Secret to Ace Cisco 350-801 CLCOR Exam

Continue reading

What Do Network Operators Need for Profitable Growth?

For the past 30 years, service providers have built networks using technology that was limited in terms of speed, cost, and performance. Historically, optical and routing platforms evolved independently, forcing operators to build networks using separate architectures and on different timelines. This resulted in a solution that drives up complexity and Total Cost of Ownership (TCO).

Current multi-layer networks made up of Dense Wavelength Division Multiplexing (DWDM), Reconfigurable Optical Add-Drop Multiplexers (ROADMs), transponders, and routers suffer from current generational technology constraints and head-spinning complexity. Additionally, operators face a highly competitive pricing environment with flat Average Revenue Per User (ARPU) but enormous increases in usage. This requires re-evaluating network architecture to support massive scale in an economically and operationally viable way to improve TCO.

Here are a few factors that contribute to high network TCO:

◉ Redundant resiliency in each network layer leading to poor resource utilization

◉ Siloed infrastructure relying on large volumes of line cards for traffic handoff between layers

◉ High complexity due to multiple switching points, control, and management planes

◉ Layered architecture requiring manual service stitching across network domains that presents challenges to end-to-end cross-loop automation needed for remediation and shorter lead times

But now we live in a different world, and we have technology that can address these problems and more. We envision a network that is simpler and much more cost-effective, where optical and IP networks can operate as one. Rather than having two different networks that need to be deployed and maintained with disparate operational support tools, we’re moving toward greater IP and optical integration within the network.

Advances in technology enabling a fully integrated routing and optical layer

Service provider business profitability runs through best-in-class network processing and coherent optical technology advancements, enabling higher network capacities with lower power and space requirements. These, coupled with software providing robust automation and telemetry, will simplify the network and lead to greater utilization and monetization. Applications like Multi-access Edge Computing (MEC) that require every operator office to become a data center continue to increase the importance of delivering higher capacities.

We’ve made great strides in technology advancements across switching, Network Processing Unit (NPU) silicon, and digital coherent optics. Last year we introduced Cisco Silicon One, an exciting new switching and routing silicon used in the Cisco 8000 Series of devices that can also be purchased as merchant silicon.

Cisco Silicon One allows us to build switches and routers that can scale to 100s of Terabits. It also means the scalability is optimized for 400G and 800G coherent optics.

Figure 1. The basics of Cisco Routed Optical Networking

What can Cisco Routed Optical Networking do for you?

The technology advancements I mentioned now enable a new network architecture for operators that we call Cisco Routed Optical Networking. We designed this solution to help service providers scale their networks more effectively to meet future traffic demands. This new architecture will lead to simplification and drive higher scale and lower TCO for IP services.

It features the integration of 400G coherent transponder functions into routing devices, meaning convergence of IP routing and coherent DWDM by leveraging the advancement of silicon photonics. You can now realize 400G coherent transport in a compact Quad Small Form-factor Pluggable-Double Density (QSFP-DD) on high-scale routing platforms. This enables service line cards that aren’t compromised in routing port density or capacity relative to their gray optical counterparts.

Other features include:

◉ Massive network simplification and higher fiber utilization by leveraging hop-by-hop IP core architecture that avoids the complexity of contentionless ROADMs and reduces compromise in fiber resource utilization to maximize network monetization

◉ Removes barriers to automated network infrastructure via closed-loop automation framework across a single converged IP and optical infrastructure for service path computation, activation, orchestration, remediation, and optimization

◉ Assimilation of private line/Optical Transport Network (OTN) services and photonic switching into a single converged IP/Multi-Protocol Label Switching (MPLS) network layer with single forwarding and control plane that leverages segment routing for sub-50ms service resiliency

Figure 2. Traditional architecture vs. integrated optics with hop-by-hop digital ROADM

 

Cisco Routed Optical Networking can provide up to 40 percent savings on TCO versus current layered network architectures. It’s also a lower TCO solution for IP aggregation for mobile backhaul applications based on coherent DWDM interface integration into IP aggregation devices. This can help service providers realize cost savings of up to 40 percent in Capital Expenditure (CapEx) and 60 percent in Operating Expenditure (OpEx).

ROADM-enabled “optical bypass” was introduced around 2005 to mitigate the cost of scaling router platforms, but this new NPU silicon, along with 400G-plus digital coherent interfaces, has changed the economics. Operators can now adopt architectures that remove their higher cost and complex ROADM-based photonic layer in favor of simplified hop-by-hop designs. However, if some network operators still prefer to maintain a ROADM-based photonic layer, they may now connect that layer directly into the router, thus eliminating the pervasive need for a discrete optical network switch or transponder layer.

Overall, these technology advancements enable new architecture and design options for operators that simplify the network and provide cost-effective ways to route traffic to intended destinations. These optimized architectures can then be built with modern software such as our IOS XR7 operating system and Crosswork automation solutions, which simplify network operation and accelerate monetization by leveraging robust APIs, model-driven provisioning, and streaming telemetry.

Our investment and strategy alignment

We’ve positioned ourselves as industry leaders in technology advancements that enable network operators to find future profitability and success. We’ll continue to lead the way through key investments and a clear strategy.

Our development of Cisco Silicon One, IOS XR7, and CrossWork are but a few examples. In March 2021 we completed the purchase of Acacia, a component supplier and manufacturer of high-speed optical networking technology. Since 2010 we’ve spent $6 billion in acquisitions and inorganic investment across optical/coherent and switching/routing silicon.

Service providers realize that the bulk of services now consuming their network capacity result in traffic increases but flat ARPU, which is not commensurate with the cost of building network infrastructure that scales to support growth at an exponential rate. There’s a need to leverage automation, Software-Defined Networking (SDN), telemetry, and machine learning to lower OpEx. Our investment and strategy, more than other suppliers, is directly aligned with enabling service provider profitability and market share growth.

Source: cisco.com

Continue reading

Cisco introduces Dynamic Ingress Rate Limiting – A Real Solution for SAN Congestion

I’m sure we all agree Information Technology (IT) and acronyms are strongly tied together since the beginning. Considering the amount of Three Letter Acronyms (TLAs) we can build is limited and now exhausted, it comes with no surprise that FLAs are the new trend. You already understood that FLA means Four Letter Acronym, right? But maybe you don’t know that the ancient Romans loved four letter acronyms and created some famous ones: S.P.Q.R. and I.N.R.I.. As a technology innovator, Cisco is also a big contributor to new acronyms and I’m pleased to share with you the latest one I heard: DIRL. Pronounce it the way you like.

Please welcome DIRL

DIRL stands for Dynamic Ingress Rate Limiting. It represents a nice and powerful new capability coming with the recently posted NX-OS 8.5(1) release for MDS 9000 Fibre Channel switches. DIRL adds to the long list of features that fall in the bucket of SAN congestion avoidance and slow drain mitigation. Over the years, a number of solutions have been proposed and implemented to counteract those negative occurrences on top of Fibre Channel networks. No single solution is perfect, otherwise there would be no need for a second one. In reality every solution is best to tackle a specific situation and offer a better compromise, but maybe suboptimal in other situations. Having options to chose from is a good thing.

DIRL represents the newest and shining arrow in the quiver of the professional MDS 9000 storage network administrator. It complements existing technologies like Virtual Output Queues (VOQs), Congestion Drop, No credit drop, slow device congestion isolation (quarantine) and recovery, portguard and shutdown of guilty devices. Most of the existing mitigation mechanisms are quite severe and because of that they are not widely implemented. DIRL is a great new addition to the list of possible mitigation techniques because it makes sure only the bad device is impacted without removing it from the network. The rest of devices sharing the same network are not impacted in any way and will enjoy a happy life. With DIRL, data rate is measured and incremental, such that the level of ingress rate limiting is matched to the device continuing to cause congestion. Getting guidance from experts on what mitigation technique to use remains a best practice of course, but DIRL seems best for long lasting slow drain and overutilization conditions, localizing impact to a single end device.

The main idea behind DIRL

DIRL would deserve a very detailed explanation and I’m not sure you would keep reading. So I will just drive attention to the main concept which is quite simple actually and can be considered the proverbial egg of Columbus. Congestion in a fabric manifests when there is more data to deliver to a device than the device itself is able to absorb. This can happen under two specific circumstances: the slow drain condition and the solicited microburst condition (a.k.a. overutilization). In the SCSI/NVMe protocols, data does not move without being requested to move. Devices solicit the data they will receive via SCSI/NVMe Read commands (for hosts) or XFR_RDYs frames (for targets). So by reducing the number of data solicitation commands and frames, that will in turn reduce the amount of data being transmitted back to that device. This reduction will be enough to reduce or even eliminate the congestion. This is the basic idea behind DIRL. Simple, right?

The real implementation is a clever combination of hardware and software features. It makes use of the static ingress rate limiting capability that is available for years on MDS 9000 ASICs and combines that with the enhanced version of Port Monitor feature for detecting when specific counters (Tx-datarate, Tx-datarate-burst and TxWait) reach some upper or lower threshold. Add a smart algorithm on top, part of the Fabric Performance Monitor (FPM), and you get a dynamic approach for ingress rate limiting (DIRL).

DIRL is an innovative slow drain and overutilization mitigation mechanism that is both minimally disruptive to the end device and non-impactful to other devices in the SAN. DIRL solution is about reducing those inbound SCSI Read commands (coming from hosts) or XFR_RDY frames (coming from targets) so that solicited egress data from the switch is in turn reduced. This brings the data being solicited by any specific device more in line with its capability to receive the data. This in turn would eliminate the congestion that occurs in the SAN due to these devices. With DIRL, MDS 9000 switches can now rate limit an interface from about 0.01% to 100% of its maximum utilization and periodically adjust the interface rate dynamically up or down, based on detected congestion conditions. Too cool to be true? Well, there is more. Despite being unique and quite powerful, the feature is provided at no extra cost on Cisco MDS 9000 gear. No license is needed.

Why DIRL is so great

By default, when enabled, DIRL will only work on hosts. Having it operate on targets is also allowed, but considering that most congestion problems are on hosts/initiators and the fact a single target port has a possible impact on multiple hosts, this needs to be explicitly configured by the administrator. With DIRL, no Fibre Channel frames are dropped and no change is needed on hosts nor targets. It is compatible with hosts and targets of any vendor and any generation. It’s agentless. It is a fabric-centric approach. It is all controlled and governed by the embedded intelligence of MDS 9000 devices. Customers may chose to enable DIRL on single switch deployments or large fabrics. Even in multiswitch deployments or large fabrics DIRL can deployed on only a single switch if desired (for example for evaluation). Clearly DIRL operates in the lower layers of the Fibre Channel stack and this makes it suitable for operation with both SCSI and NVMe protocols.

DIRL makes dynamic changes to the ingress rate of frames for specific ports and it operates on two different time scales. It is reasonably fast (seconds) to reduce the rate with 50% steps and it is slower (minutes) to increase it with 25% steps. The timers, thresholds and steps have been carefully selected and optimized based on real networks where it was initially tested and trialed with support by Cisco engineering team. But they are also configurable to meet different user requirements.

The detailed timeline of operation for DIRL

To explain the behavior, let’s consider an MDS 9000 port connected to a host. The host mostly sends SCSI Read Commands and gets data back, potentially in big quantities. On the MDS 9000 port, that would be reflected as a low ingress throughput and a high egress throughput. For this example, let’s say that Port Monitor has its TxWait counter configured with the two thresholds as follows:

Rising-threshold – 30% – This is the upper threshold and defines where the MDS 9000 takes action to decrease the ingress rate.

Falling-threshold – 10% – This is the lower threshold and defines where the MDS 9000 gradually recovers the port by increasing the ingress rate.

The stasis area sits between these two thresholds, where DIRL is not making any change and leaves the current ingress rate limit as-is.

The crossing of TxWait rising-threshold indicates the host is slow to release R_RDY primitives and frames are waiting in the MDS 9000 output buffers longer than usual. This implies the host is becoming unable to handle the full data flow directed to it.

The timeline of events in the diagram is like this:

T0: normal operation

T1: TxWait threshold crossed, start action to reduce ingress rate by 50%

T1+1 sec: ingress rate reduced by 50%, egress rate also reduced by some amount, TxWait counter still above threshold

T1+2 sec: ingress rate reduced by another 50%, egress rate also reduced by some amount, TxWait counter now down to zero, congestion eliminated

T5: Port has had no congestion indications for the recovery interval. Ingress rate increased by 10%, egress rate increases as well by some amount, TxWait still zero

T5 + 1 min: Port to have no congestion indications for the recovery interval. Ingress rate increased by another 10%, egress rate increases as well by some amount, TxWait still zero

T5 + 2 min: Port to have no congestion indications for the recovery interval. Ingress rate increased by another 10%, egress rate increases as well by some amount, TxWait jumps to 8% but still below falling-threshold.

T5 + 3 min: ingress rate increased by another 10%, egress rate increases as well by some amount, TxWait jumps to 20%. This puts TxWait between the two thresholds. At this point recovery stops and the current ingress rate limit is maintained.

T5 + 4 min: ingress rate was not changed, egress rate experienced a minor change, but TxWait jumped above upper threshold, congestion is back again and remediation action would start again.

Source: cisco.com

Continue reading

Native or Open-source Data Models? Use Both for Software-Defined Enterprise Networks.

Enterprise IT administrators with hundreds, thousands, or even more networking devices and services to manage are turning to programmable, automated, deployment, provisioning, and management to scale their operations without having to scale their costs. Using structured data models and programmable interfaces that talk directly to devices―bypassing the command line interface (CLI)―is becoming an integral part of software-defined networking.

As part of this transformation, operators must choose:

◉ A network management protocol (e.g., Netconf or Restconf) that is fully supported in Cisco IOS XE 

◉ Data models for configuration and management of devices 

One path being explored by many operators is to use Google Remote Procedure Calls (gRPC), gRPC Network Management Interface (gNMI) as the network management protocol. But which data models can be used with gNMI? Originally it didn’t support the use of anything other than OpenConfig models. Now that it does, many developers might not realize that and think that choosing gNMI will result in limited data model options. Cisco IOS XE has been ungraded to fully support both our native models and OpenConfig models when gNMI is the network management protocol.  

Here’s a look at how Cisco IOS XE supports both YANG and native data models with the “mixed schema” approach made possible with gNMI.  

Vendor-neutral and Native Data Models 

Cisco has defined data models that are native to all enterprise gear running Cisco IOS XE and other Cisco IOS versions for data center and wireless environments. Other vendors have similar native data models for their equipment. The IETF has its own guidelines based on YANG data models for network topologies. So too does a consortium of service providers led by Google, whose OpenConfig has defined standardized, vendor-neutral data modeling schemas based on the operational use cases and requirements of multiple network operators.   

The decision of what data models to use in the programmable enterprise network typically comes down to a choice between using vendor-neutral models or models native to a particular device manufacturer. But rather than forcing operators to choose between vendor-neutral and native options, Cisco IOS XE with gNMI offers an alternative, “mixed-schema” approach that can be used when enterprises migrate to model-driven programmability. 

Pros and Cons of Different Models 

The native configuration data models provided by hardware and software vendors support networking features that are specific to a vendor or a platform. Native models may also provide access to new features and data before the IETF and OpenConfig models are updated to support them. 

Vendor neutral models define common attributes that should work across all vendors. However, the current reality is that despite the growing scope of these open, vendor-neutral models, many network operators still struggle to achieve complete coverage for all their configuration and operational data requirements.  

At Cisco we have our own native data models that encompass our rich feature sets for all devices supported by IOS XE. Within every feature are most, if not all, of the attributes defined by IETF and OpenConfig, plus extra features that our customers find useful and haven’t yet been or won’t be added to vendor-neutral models. 

With each passing release of Cisco IOS XE there has been significant and steady growth both in the number of native YANG models supported and in the number of configuration paths supported (Figures 1 and 2). The number of paths provides an insight into the vast feature coverage we have in IOS –XE. As of IOS XE release 17.5.1, there are approximately 232000 XPaths covering a diverse set of features ranging from newer ones like segment routing to older ones like Routing Information Protocol (RIP). 

Figure 1. Quantity of YANG Data Models Per IOS XE Release

Figure 2. Quantity of YANG Configuration Paths Per IOS XE Release

Complete information on Cisco IOSXE YANG model coverage can be found in the public GitHub repository. The information there is updated with data from every new IOS XE release. 

For customers evaluating gNMI as their network management protocol it may feel like a dead-end when OpenConfig models are insufficient to handle a use case. It is important to understand that gNMI is not limited to OpenConfig models and vendors can make their native models available with gNMI.  

But are you stuck with having to choose between using OpenConfig or native models? No, the  mixed-schema approach to data modeling offers the best of both worlds. 

The gNMI Mixed Schema Approach 

The gNMI specification of RPCs and behaviors for managing the state on network devices was proposed by OpenConfig. It’s built on the open source gRPC framework and uses the protocol buffers interactive data language (Protobuf IDL). 

At Cisco we believe that our customers should have the best of both native and vendor-neutral data modeling worlds. Enterprise admins can consider using vendor-neutral models to standardize the core elements of configurations and then provide other functionality using the native device models. 

With the mixed–schema approach, operators can mix IETF, OpenConfig, and native models without sacrificing many of the advantages of a model-driven approach to configuration and operational data. Operators can disambiguate the schema source using the gNMI “origin” fields defined by the network device vendor.  

You don’t lose any transactional benefits when using a mixed-schema approach. This is critical as it means that an operator can, for example, issue a gNMI Set that combines configuration from an OpenConfig and native model in a single transaction. Any failure will cause the entire transaction to fail and removes the need for the operator to deal with complicated configuration rollback scenarios 

Support for gNMI in IOS XE 

The mixed schema approach is supported in IOS XE using the “openconfig” origin field for OpenConfig models and “rfc7951” for native models. Here is an example where a gNMI Set request is used to enable NTP on a network device.  

In this scenario, the operator relies on NTP configurations that are not specified in the OpenConfig model. The first update in the request is completely vendor-neutral and enables NTP on any device that supports the openconfig-system model. The second update is specific to Cisco IOS XE and is easily distinguished via the origin field. The two updates are combined in a single request which means that both must be successful for the whole Set transaction to succeed. There is no need for the operator to perform any complicated roll-back of the device configuration if one of the updates were to fail. 

update: < 

        path: < 

            origin: “openconfig“ 

            elem: < 

                name: “system” 

            > 

            elem: < 

                name: “ntp“ 

            > 

            elem: < 

                name: “config” 

            > 

       > 

        val: < 

            json_ietf_val:”{\”enabled\“:true,\”ntp-source-address\”:\”10.1.1.1\”,\”enable-ntp-auth\”:false}”  

        > 

    > 

  update: < 

        path: < 

            origin: “rfc7951” 

            elem: < 

                name: “Cisco-IOS-XE-native:native“ 

            > 

            elem: < 

                name: “ntp“ 

            > 

        > 

        val: < 

            json_ietf_val:”{\”Cisco-IOS-XE-ntp:mindistance\”:2,\”Cisco-IOS-XE-ntp:maxdistance\”:10}” 

        > 

    > 

This type of mixed-schema approach will work just as well for gNMI Get requests. 

Find Out More About gNMI  

The gNMI mixed-schema approach with Cisco IOS XE is an extremely useful tool that network operators can use to ease the transition to a model-driven, programmable, and automated network infrastructure. I highly recommend that every enterprise network administrator familiarize yourself with the gNMI specification and models. We’re moving to software-driven deployment and management, with software running in the cloud and on devices that automate network management. With two types of options available for data model-driven network management, you now don’t have to choose among them. You can have the best of both worlds.

Source: cisco.com

Continue reading

Building Hybrid Work Experiences: Details Matter

The Shift From Remote Work to a New Hybrid Work Environment

It’s exciting to see more organizations start to make the shift from remote work to a new hybrid work environment, but it’s a transition that comes with a new set of questions and challenges. How many people will return to the office, and what will that environment look like? Increasingly, we’re hearing that teams are feeling fatigued and disconnected – what tools can help to solve for that? And perhaps most importantly, how can we ensure that employees continuing to work remotely have the same connected and inclusive experience as those that return to the office?

When we think about delivering positive employee experiences, it’s the details that matter. This month, we’re rolling out new Webex features that solve for a few challenges that might be overlooked and yet play an important role in the new hybrid working model.

Give More and Get More From Your Meeting Experiences

Whether in the office or working remotely, no one wants to sit in meeting after meeting listening to a presenter drone on. Or worse, participating in a video meeting where there are so many talking heads and content being shared that you just don’t know where to focus. Making meetings more engaging is important in the world of hybrid work.

We’re expanding our Webex custom layouts functionality to include greater host controls, resulting in a more personalized and engaging meeting experience. As a meeting host or co-host, you have the ability to hide participants who are not on video, bringing greater focus to facial expressions and interactions with video users. Using the slider feature, you are able to show all participants on screen, or focus on just a few. And now hosts and co-hosts can curate and synchronize the content and speakers you want your attendees to focus on, and then push that view to all participants. This allows you to set a common “stage” and establish a more engaging meeting experience for all.

Setting the stage and sharing great content is one half of the equation – but wouldn’t it be helpful to know what your audience thinks about your meeting as well? Yesterday we announced the close of our acquisition of Slido, which brings best-in-class audience interaction capabilities to the Webex platform. With the ability to crowdsource questions, launch polls and quizzes, and solicit real-time feedback from your audience, the meeting experience just became a lot more interesting and valuable to both those hosting and those attending.

Work More Efficiently with Personalized Webex Work Modes

Your morning routine might start with a review of your meeting schedule, or checking unread messages. Or maybe you spend the majority of your time on calls. As a Webex user, you now have the flexibility to modify settings to default to the work mode that’s most important to you, allowing you to work your way more efficiently. And because all work modes come together seamlessly on the Webex platform, you can transition between messaging, calling and meeting with ease.

If you’re like me, you might rely on your message inbox as a To Do list that reminds you where to prioritize your time. To better support this workstyle preference, Webex now offers the ability to easily mark a message as unread, even if you’ve already read it. This visual reminder allows you to work efficiently and effectively – keeping up to speed on conversations, while ensuring that action items don’t fall off your radar.

Reimagining the Workplace

When it comes to planning for a safe and successful return to the office, business leaders are faced with new challenges large and small – everything from reconfiguring workspaces for a hybrid workforce to ensuring that shared surfaces and devices are kept clean and sanitized.

To ensure inclusive collaboration between employees in the office and those working remotely, we’re making it easier for all meeting attendees to be seen and heard. The Webex Room Kit Mini now offers a more powerful 5x digital zoom camera and optimized audio via internal microphones, providing clear audio up to 4 meters away. And the Webex Room Panorama is now configurable for low ceiling height and features flexible placement of content screens, enabling a wider variety of workspaces to support boardroom-style meeting experiences.

And talk about attention to details: Webex now enables easy sanitation of shared devices, with features like medical-grade, alcohol-resistant removable covers for phones and a wipe-down metal grill option on Webex Room Kit Mini devices.

Source: cisco.com

Continue reading

8 Reasons why you should pick Cisco Viptela SD-WAN

20 years ago, I used to work as a network engineer for a fast-growing company that had multiple data centers and many remote offices, and I remember all the work required to simply onboard a remote site. Basically, it took months of planning and execution which included ordering circuits, getting connectivity up and spending hours, and sometimes days, deploying complex configurations to secure the connectivity by establishing encrypted tunnels and steering the right traffic across them. Obviously, all this work was manual. At the time I was very proud of the fact that I was able to do such complex configurations that required so many lines of CLI but that was the way things were done.

Read More: 300-420: Designing Cisco Enterprise Networks (ENSLD)

During the decade that followed, we saw a slew of WAN and encryption technologies become available to help with the demand and scale for secure network traffic. MPLS, along with frame Relay, became extremely popular and IPsec-related encryption technologies became the norm. All this was predicated on the fact that most traffic was destined to one clear location and that is the data center that every company had to build to store all its jewels including applications, databases and critical data. The data center also served as the gateway to the internet.

From a security perspective, the model was simple and had clear boundaries. All infrastructure within the enterprise was trusted and everything outside including the internet and DMZ was labeled as untrusted, so firewalls and other proper security devices were deployed at these boundaries mainly at the data center in order to protect the organization.

The decade that followed brought some disrupting trends. We moved from desktops to laptops and then mobile devices became the norm. We became more dependent on voice and video services which meant regular infrastructure updates were frequently needed to deal with increasing demands for bandwidth.

As WAN services became more critical, businesses had to invest in expensive redundant links of which the secondary link was sitting idle designed as a backup link in case of a primary link failure. Although there were some challenges, this model worked out pretty well for some time.

The rise of Cloud Computing

Although Cloud Computing has been around since the early 2000s, rapid adoption did not materialize until recently due to multiple factors including general lack of trust and security concerns. Over the last 5 years, however, a new trend picked up and many organizations started to see benefits to cloud computing that allowed for cost saving and more flexibility. For example, a small company can now have their servers run on a cloud Service provider (CSP) the likes of AWS or Azure rather than having to spend tons of Capex money to build a data center. Basically, mindsets are changing even in conservative sectors such as Financials as per the following quote from a banking customer.

“In 2020, we left our data centers behind and moved to the public cloud to create exceptional banking experiences for our customers. The agility, scalability and elasticity of the cloud are helping us build the bank of the future”

In addition, Software as a Service (SaaS) is another trend that is also changing the way we consume applications. A long list of critical applications that include Office 365, Salesforce, WebEx, Box and many more are now being served from the cloud.

While moving to the cloud trend has been accelerating over the last 5 years the COVID pandemic has sure made this trend accelerate exponentially and with it the need for a new architecture that is better suited to address these new diverse challenges.

The need for SD-WAN

As organizations increasingly adopt SaaS and IaaS, the old model of networking will no longer work for the main reason that services are no longer residing in one place but are now distributed across the internet on multiple clouds. Basically, we can no longer rely on the data center as the gateway to the internet because going that route no longer gives us the optimal path and thus introduces more latency culminating in sub-optimal user application experience. Also Increased traffic at the data center requires expensive links as well as network and security equipment that can support the throughput.

In addition, the customer consumption model for connectivity is changing and rather than spending a lot of money on expensive MPLS links, companies now can utilize their branch backup links or go with cheaper ones at a fraction of the cost. Although direct internet links (DIA) provide a great way to offload noncritical internet traffic, using it beyond that will require those links to be secured and to do so brings more challenge to IT organizations.

Software Defined WAN was introduced to solve all these problems by decoupling the data plane from the control and management plane, creating a secure overlay and, similar to a car GPS, providing the intelligence to route a packet to the right destination avoiding traffic congestion attributed to loss, latency and jitter. Most importantly, it relies on a single management interface that made the provisioning and management of WAN extremely simple.

Why Cisco Viptela?

Cisco acquired Viptela, a leading SD-WAN provider in 2017. Since then, Cisco has integrated the solution into its long line of WAN routers, introduced the Catalyst 8K family (a new router platform that was designed specifically for SD-WAN and Cloud), added a long list of cloud innovations by working with leading Cloud Service Providers (CSPs) and deployed the solution at thousands of customer sites. In order to better understand the benefit that Cisco Viptela brings let’s breakdown the conversation into the following 8 key areas:

Centralized Management: One of the key benefits that Cisco Viptela provides is the use of centralized management using vManage to not only provision and monitor SD-WAN fabric policies but to also provide capabilities to integrate with external systems such as provisioning transit gateways on AWS and automating tunnel creation to a Secure Internet Gateway (SIG) thus providing the administrator with one tool to simplify solution roll out.

Bandwidth Augmentation: The ability to offload traffic from expensive MPLS links can be achieved due to the fact that Viptela SD-WAN is link agnostic so multiple internet links can achieve the same availability and performance as a single premium link at the fraction of the price and can still meet the same SLA

Application Performance Optimization: Applications have different requirements when it comes to quality of service. Some may have issues with little delay, some are sensitive to loss and some behave poorly if there is jitter. SD-WAN features such as TCP optimization, DRE and Application-aware routing are among the tools that we can use to get around congestion issues and allows us to deliver optimal quality of experience.

Secure Direct Internet Access: Leveraging many years of security expertise, the Cisco Security stack which includes Firewall, IPS, URL filtering, TLS Proxy and advanced malware protection can be deployed at the branch or on Cloud using Cisco Umbrella which gives customers the confidence to utilize branch breakout links, saving cost and enhancing the overall application experience especially for cloud-based services.

Middle Mile Optimization: Colo presence provides a lot of value to customers that include direct access to CSPs through express routes, allows service chaining and much more. In this situation, Cisco SD-WAN extends the fabric and provides a management interface to onboard and manage the environment.

Cloud OnRamp for IaaS: The key benefit of this feature is that it not only allows us to use the same simple flow to automate connectivity to all key Cloud Service Providers which include AWS, Azure and GCP, but once the SD-WAN Fabric is extended to the cloud, then customers will get to use all the features available to SD-WAN on the Cloud and all configurations can be done from the same vManage Console. In certain cases, the CSP provider network can be used as a backbone for passing site-to-site traffic thus reducing latency to a specific destination.

Cloud onRamp for SaaS: This feature provides optimal experience for SaaS applications by utilizing internal probing and external telemetry received from SaaS application vendors. Microsoft Office 365 offers a great example of this feature. In addition to the probing intelligence built into SD-WAN, Microsoft will send key URLs along with new recommendations based on internal dynamic data.

Analytics: The Cisco vAnalytics platform is offered as a Service and provides a graphical interface of the fabric performance with the ability to drill down into specific areas such as network availability, carrier, tunnel and application performance. Other Cisco applications such as Cisco StealthWatch and Cisco ThousandEyes can also be used to provide more analytics.

In summary, as the future of networking turn into the cloud, the internet will now play a critical role similar to the role that LAN played in the past. Cisco Viptela SD-WAN a highly reliable and resilient solution with its rich features integrating Cloud optimization, security and advanced analytics can play a major role in helping organizations manage this disruptive WAN phase and will be the foundation for Secure Edge Service Edge (SASE), but that will be another discussion for another blog.

Source: cisco.com

Continue reading