Detecting and Mitigating Loops in VXLAN Networks

The Problem with Looping

First-generation Layer-2 Ethernet networks could not natively detect or mitigate looped topologies, while modern Layer-2 Overlays implicitly build loop-free topologies. Overlays do not have any need for loop detection and mitigation as long as no first-gen Layer-2 network is attached, which is common in complex data center networks. When loops occur, data frames can exist indefinitely, disrupting network stability and degrading performance. Loops introduce broadcast radiation, increasing utilization of CPU and network bandwidth, which results in a degradation of user application access experience. In multi-site networks a loop can span multiple data centers, causing disruptions that are difficult to pinpoint. In other words, loops are bad news. Before we look at how a modern network fabric minimizes looping, let’s examine previous attempts at preventing loops in topologies.

Spanning Tree Protocols (STP) counteract the loop problem in first-gen Layer-2 Ethernet network. Over time, other approaches evolved by moving networks from “looped topologies” to “loop-free topologies”. This evolution reduced the dependence on Loop Prevention protocols, so they are now employed mostly as a failsafe mechanism. Today with Network Virtualization Overlays, the dependency on Loop Prevention protocols is almost entirely eliminated. However, even though virtualized overlay networks such as VXLAN EVPN are loop free, having a failsafe loop detection and mitigation method is still desirable because loops can be introduced by topologies connected to the overlay network.

Loop-free VXLAN overlays may be connected to an Ethernet segment that can result in network loops, requiring detection and mitigation in conjunction with the overlay.

Many Solutions to Loop Prevention, But Which is the Best?

The Spanning Tree Protocol enables network designs that include redundant links to provide fault tolerance but avoid the presence of bridging loops. STP builds a single tree that calculates the relationship of network nodes and bridges within a layer 2 network to avoid creating loops.

An alternate approach to prevent loops in layer 2 networks uses link bundles between two neighboring bridges. This technique improves performance (Link Aggregation – LAG) and provides link redundancy (member link failure in a LAG). When multiple bridges exist, link bundles are extended to provide peering between multiple bridges (Multi-Chassis Link Aggregation – MLAG), increasing bridge node resiliency along with link redundancy and performance. In both of these cases, the link bundles are treated by STP as a single logical link and the creation of a loop is prevented (loop free). In each of these cases, STP acts as a failsafe.

While LAG and MLAG were in use for many years, other approaches for building loop free topologies arose by using ECMP (Equal Cost Multi-Path), either at the MAC layer or IP layer. FabricPath or TRILL (Transparent Interconnect of Lots of Links) are MAC layer ECMP approaches that emerged in the last decade. More recently, Network Virtualization Overlays that build loop free topologies on top of IP layer ECMP became the state-of-the-art. VXLAN is the most prevalent network virtualization protocol in use today that builds loop free topologies.

A loop-free VXLAN overlay network.

While a VXLAN Overlay provides a loop free layer 2 service over IP ECMP, a layer 2 loop may still be introduced by connecting an L2 Ethernet network. VXLAN Edge-Devices act as bridges between VXLAN and Ethernet, known as Layer 2 Gateways (L2GW). A loop on the Ethernet network side can still introduce harmful broadcast radiation to the loop-free overlay network. If a loop is accidentally configured, physically or logically, the absence of a Loop Prevention protocol in VXLAN could allow the existence of a loop. While the layer 2 service in the VXLAN overlay network does not participate in the Spanning Tree Protocol, even if it could, blocking of a link in a loop-free overlay network would not prevent a loop but might cause additional harm, such as loss of service.

While proposals exist to integrate the overlay network with STP, these proposals are considering all Edge-Devices representing a single STP root bridge – Layer 2 Gateway STP (L2G-STP). While this approach is valid, it introduces rigidity into the deployment of modern overlay networks, reducing flexibility. With L2G-STP or similar approaches, the location of the STP root is predefined and hence can’t adjust to network designs that require a different location for this function. While L2G-STP can be used as a separate feature, the same functionality can be configured with a common STP root priority on the Edge-Device and the use of STP Root Guard.

In order to maintain the flexibility of overlay network deployments with VXLAN but have the ability to detect and protect against potential loops, Cisco provides an innovation: VXLAN EVPN Southbound Loop Detection and Mitigation.

Southbound Loop Detection and Mitigation

Let’s look at a VXLAN network in a spine/leaf topology to define “southbound looping”. The leaf is acting as Network Virtualization Edge-Device that is hosting the VXLAN Tunnel Endpoint (VTEP) function. In this topology, the VXLAN network represents the “northbound” portion of the network. The network from the leaf or Edge-Device to the “south” is most commonly the Ethernet network. As loops are potentially formed in this “southbound” network, the goal is to detect and mitigate loops that are introduced by the “southbound” network.

North and south network topology.

Operations, Administration, and Maintenance (OAM) provides a framework for Connectivity Fault Management (CFM) defined in IEEE 802.1ag. Within this protocol framework and specifications, a continuous check message traverses intermediate bridges. This is a key criteria for enabling uninterrupted transfer of signaling across north-south borders. Based on well-defined triggers that span from initial port up to duplicate MAC detection (RFC7432 Section 15.1), check message probes are sent in a focused manner to detect if and where loops exist.

Loop detection is provided exclusively by the Edge-Devices that form the “northbound” VXLAN and bridge to the “southbound” Ethernet network. If the probe is not returned to the sending Edge-Devices, then no southbound Loop exists. If a southbound probe is returned, the existence of a loop is validated. As Edge-Devices become aware of a detected loop, notifications are shared with network operators and mitigation actions initiated.  

A probe uncovers a loop in a southbound Ethernet network.

Loop Mitigation and Recovery

As part of the mitigation, the “southbound” Ethernet interfaces that participate in a loop are identified. As loops can exist in some VLANs but not in others, the granularity of control on a Port, VLAN basis is significant. In the action of mitigation, only the specific offending combination of VLAN and port is suppressed to break the detected loop and stop traffic radiation without disrupting other traffic on the port. Breaking the loop updates the topology which can affect the accuracy of the MAC address table. Therefore, a MAC-flush is initiated in the VLAN with the detected loop to enable proper re-learning and forwarding subsequent to the loop mitigation.

Once a loop has been mitigated, it can be difficult to know if the recovery—the unsuspending of a Port,VLAN combination—will reintroduce the loop. In order to prevent a false-recovery and loop reintroduction, a probe is sent prior to initiating the recovery while the Port,VLAN combination stays suspended (doesn’t forward traffic). If the probe still reports an indication of an existing southbound loop, the recovery process is stopped and the Port,VLAN stays suspended. After a given interval, loop detection is reinitiated. The recovery process continues until no loop is detected. Appropriate configuration, notification, and override commands are available to the Network Operator.

VXLAN EVPN with Built-In Southbound Loop Detection and Mitigation

Cisco NX-OS 9.3(5) provides native southbound loop detection and mitigation for VXLAN EVPN fabrics. The functionality extends the loop-free behavior of VXLAN EVPN’s Network Virtualization Overlay with existing Ethernet networks. While there are many use-cases that require loop detection and mitigation in a single fabric, the same functionality is available for VXLAN EVPN Multi-Site deployments. For these Multi-Site deployments, loop detection and mitigation supports the detection of backdoor links, the most prevalent cause of multi-site outages during extension or migrations.  

While many loop protection solutions support detecting the existence of loops in the overall topology and shutting down the offending ports, VXLAN EVPN Loop Detection and Mitigation defines the topology at the “VLAN-level”. Similar to Per-VLAN Spanning Tree variations (PVST+ and PVRST/802.1w) the functionality of VXLAN EVPN Loop Detection and Mitigation acts with comparable granularity. Differing from Spanning Tree, no pro-active calculation of a forwarding tree is built, but precautions are made to avoid the existence of loops and introducing them into the Overlay. VXLAN EVPN southbound loop detection and mitigation aims to ensure network uptime and avoid unnecessary risks due to loop creation, whether it is within a single fabric or across multiple fabrics with VXLAN EVPN Multi-Site.

Looping can be accidentally introduced into multi-site fabrics through backdoor links.

Innovative Solutions for Increasing Data Center Resiliency

Increasing the stability of data center fabrics is key to supporting business resiliency — whether for a single on-premise brownfield fabric or when adding new multi-site greenfield fabrics. In order to optimize application performance and network stability, modern networks need to build upon a consistent, up-to-date platform instead of relying on a patchwork of technologies that can cause more conflicts than resolutions.

Even though modern VXLAN EVPN overlays prevent most looping scenarios natively, combining them with older network topologies can still introduce the risk of corrosive loops. Even carefully designed multi-site VXLAN EVPN data center fabrics can still accidentally create backdoor links, leading to looping-related performance issues. Cisco Nexus 9000 Series based NX-OS VXLAN implementation addresses the most prevalent loop scenarios within and among multi-site data centers to build and maintain a stable and resilient network architecture for your organization.

Continue reading

Why SOAR Is the Future of Your IT Security

The threat landscape evolves constantly, with new and increasingly sophisticated cyberattacks launching with growing frequency across network, cloud, and software-as-a-service environments.

As threats continue to stack up against organizations, IT teams face the challenge of managing heterogeneous end-user device environments composed of various network-connected devices, operating systems, and applications. They must ensure that consistent, organizationally-sanctioned controls are applied across these environments.

While this is achievable with the right security expertise, there is also a global cybersecurity skills shortage. In fact, 3.5 million cybersecurity positions are expected to remain unfulfilled by 2021.

These challenges are not insurmountable. They can be conquered with the security operations and incident response approach called SOAR.

What is SOAR?

SOAR refers to a solution stack of compatible software that allows organizations to orchestrate and automate different parts of security management and operations to improve the accuracy, consistency, and efficiency of security processes and workflows with automated responses to threats.

How does SOAR work?

Security orchestration

The first component of SOAR, security orchestration, involves leveraging the different, compatible products for use within a solution stack to orchestrate the management and operations activities through standardized workflows. These security solutions automatically aggregate data from multiple sources, add context to that data to identify potential weaknesses, and use risk modeling scenarios to enable automated threat detection.  Recognizing this, more and more organizations are prioritizing the need for effective integration between security technologies to enable rapid threat detection and response.

Security automation

The second component is security automation, which involves automating many of the repetitive actions involved in the threat detection process.

Traditionally, security analysts within an organization would handle threat alerts manually, usually multi-tasking to size up alerts from numerous point solutions. This increases the likelihood of human error, inconsistent threat response, and high severity threats being overlooked.

SOAR, on the other hand, automates gathering enrichment and intelligence data on an event, can perform common investigative steps on behalf of the analyst to help triage events, and consistently delivers on the orchestration and response of the incident response lifecycle.

Security response

The third component, security response, involves triage, containment, and eradication of threats.

Response methods depend on the type and scope of the threat. Some threat responses can be automated for faster results, such as quarantining files, blocking file hashes across the organization, isolating a host or disabling access to compromised accounts.

However, sophisticated cyber-attacks require sophisticated responses. This is where security playbooks come in.

With Cisco Managed Detection and Response (MDR), automation is supported by defined investigation and response playbooks, containing overviews of known threat scenarios and best practices for responding to different types of threats. The role of automation is to rapidly execute these playbooks.

What does a threat detection and response process look like with SOAR?

Let’s start with an example based on AMP for Endpoints identifying a file as potentially malicious. SOAR would be able to begin the investigation process, start answering questions, and performing tasks automatically such as:

◉ Was the file quarantined?

◉ Was the file executed?

◉ Where else has this file been seen in the network?

◉ Detonate the file in a Cisco Threat Grid sandboxing environment

◉ Investigate using available context related to connection, file, and source at relevant technologies, such as Umbrella and Stealthwatch Cloud

◉ Retrieve any available threat intelligence information on the file and check for occurrences of known indicators of compromise (IOCs)

◉ Collect identification information on the host and username

The answers to these questions provide contextual information to the investigator to aid in determining the legitimacy, impact, urgency, and scope of the incident. This information in turn determines appropriate response actions, which may include:

◉ Quarantining the host on the network

◉ Blocking the file hash across the network

◉ Blocking IOCs

◉ Scanning and cleaning any devices with occurrences of IOCs

Betting on SOAR

The cybersecurity skills shortage, tight IT budgets, the dynamic nature of the threat landscape, and the need to optimize security operations make SOAR a compelling proposition.

With Cisco MDR, security alerts, correlation, and enrichment are automated; blocked items are propagated for instant containment; and indicators of compromise are reported near-instantly for blocking, hunting, and follow-up.

The result is streamlined security operations and a stronger security posture without breaking the IT budget or having to recruit a team of security analysts.

Continue reading

Threat Landscape Trends: Endpoint Security, Part 1

Part 1: Critical severity threats and MITRE ATT&CK tactics

In the ongoing battle to defend your organization, deciding where to dedicate resources is vital. To do so efficiently, you need to have a solid understanding of your local network topology, cloud implementations, software and hardware assets, and the security policies in place. On top of that, you need to have an understanding of what’s traveling through and residing in your environment, and how to respond when something is found that shouldn’t be there.

This is why threat intelligence is so vital. Not only can threat intelligence help to defend what you have, it can tell you where you’re potentially vulnerable, as well as where you’ve been attacked in the past. It can ultimately help inform where to dedicate your security resources.

What threat intelligence can’t tell you is exactly where you’ll be attacked next. The fact is that  there’s no perfect way to predict an attacker’s next move. The closest you can come is knowing what’s happening out in the larger threat landscape—how attackers are targeting organizations across the board. From there it’s possible to make those critical, informed decisions based on the data at hand.

This is the purpose of this new blog series, Threat Landscape Trends. In it, we’ll be taking a look at activity in the threat landscape and sharing the latest trends we see. By doing so, we hope to shed light on areas where you can quickly have an impact defending your assets, especially if dealing with limited security resources.

To do this, we’ll dive into various Cisco Security technologies that monitor, alert, and block suspected malicious activity. Each release will focus on a different product, given the unique view of activity each can provide, informing you on different aspects of the threat landscape.

Beginning at the endpoint

To kick off the series, we’ll begin with Cisco’s Endpoint Security solution. Over the course of two blog posts we’ll examine what sort of activity we’ve seen on the endpoint in the first half of 2020. In the first, we’ll look at critical severity threats and the MITRE ATT&CK framework. In part two, to be published in the coming weeks, we’ll dive deeper into the data, providing more technical detail on threat types and the tools used by attackers.

To protect an endpoint, Cisco’s Endpoint Security solution leverages a protection lattice comprised of several technologies that work together. We’ll drill down into telemetry from one of these technologies here: the Cloud Indication of Compromise (IoC) feature, which can detect suspicious behaviors observed on endpoints and look for patterns related to malicious activity.

In terms of methodology for the analysis that follows, the data is similar to alerts you would see within the dashboard of Cisco’s Endpoint Security solution, only aggregated across organizations to get the percentage of organizations that have encountered particular IoCs as a baseline. The data set covers the first half of 2020, from January 1st through June 30th. We’ll cover this in more detail in the Methodology section at the end of this post, but for now, let’s dive into the data.

Threat severity

When using Cisco’s Endpoint Security solution, one of the first things you’ll notice in the dashboards is that alerts are sorted into four threat severity categories: low, medium, high, and critical. Here is a breakdown of these severity categories in terms of the frequency that organizations encountered IoC alerts:

Percentage of low, medium, high, and critical severity IoCs

As you might expect, the vast majority of alerts fall into the low and medium categories. There’s a wide variety of IoCs within these severities. How serious a threat the activity leading to these alerts pose depends on a number of factors, which we’ll look at more broadly in part two of this blog series.

For now, let’s start with the most serious IoCs that Cisco’s Endpoint Security solution will alert on: the critical severity IoCs. While these make up a small portion of the overall IoC alerts, they’re arguably the most destructive, requiring immediate attention if seen.

Critical severity IoCs

Sorting the critical IoCs into similar groups, the most common threat category seen was fileless malware. These IoCs indicate the presence of fileless threats—malicious code that runs in memory after initial infection, rather than through files stored on the hard drive. Here, Cisco’s Endpoint Security solution detects activity such as suspicious process injections and registry activity. Some threats often seen here include Kovter, Poweliks, Divergent, and LemonDuck.

Coming in second are dual-use tools leveraged for both exploitation and post-exploitation tasks. PowerShell Empire, CobaltStrike, Powersploit, and Metasploit are four such tools currently seen here. While these tools can very well be used for non-malicious activity, such as penetration testing, bad actors frequently utilize them. If you receive such an alert, and do not have any such active cybersecurity exercises in play, an immediate investigation is in order.

The third–most frequently seen IoC group is another category of dual-used tools. Credential dumping is the process used by malicious actors to scrape login credentials from a compromised computer. The most commonly seen of these tools in the first half of 2020 is Mimikatz, which Cisco’s Endpoint Security solution caught dumping credentials from memory.

All told, these first three categories comprise 75 percent of the critical severity IoCs seen. The remaining 25 percent contains a mix of behaviors known to be carried out by well-known threat types:

• Ransomware threats like Ryuk, Maze, BitPaymer, and others
• Worms such as Ramnit and Qakbot
• Remote access trojans like Corebot and Glupteba
• Banking trojans like Cridex, Dyre, Astaroth, and Azorult
• …and finally, a mix of downloaders, wipers, and rootkits

MITRE ATT&CK tactics

Another way to look at the IoC data is by using the tactic categories laid out in the MITRE ATT&CK framework. Within Cisco’s Endpoint Security solution, each IoC includes information about the MITRE ATT&CK tactics employed. These tactics can provide context on the objectives of different parts of an attack, such as moving laterally through a network or exfiltrating confidential information.

Multiple tactics can also apply to a single IoC. For example, an IoC that covers a dual-use tool such as PowerShell Empire covers three tactics:

• Defense Evasion: It can hide its activities from being detected.
• Execution: It can run further modules to carry out malicious tasks.
• Credential Access: It can load modules that steal credentials.

With this overlap in mind, let’s look at each tactic as a percentage of all IoCs seen:

IoCs grouped by MITRE ATT&CK tactics

By far the most common tactic, Defensive Evasion appears in 57 percent of IoC alerts seen. This isn’t surprising, as actively attempting to avoid detection is a key component of most modern attacks.

Execution also appears frequently, at 41 percent, as bad actors often launch further malicious code during multi-stage attacks. For example, an attacker that has established persistence using a dual-use tool may follow up by downloading and executing a credential dumping tool or ransomware on the compromised computer.

Two tactics commonly used to gain a foothold, Initial Access and Persistence, come in third and fourth, showing up 11 and 12 percent of the time, respectively. Communication through Command and Control rounds out the top 5 tactics, appearing in 10 percent of the IoCs seen.

Critical tactics

While this paints an interesting picture of the threat landscape, things become even more interesting when combining MITRE ATT&CK tactics with IoCs of a critical severity.

Critical severity IoCs grouped by MITRE ATT&CK tactics

For starters, two of the tactics were not seen in the critical severity IoCs at all, and two more registered less than one percent. This effectively removes a third of the tactics from focus.

What’s also interesting is how the frequency has been shuffled around. The top three remains the same, but Execution is more common amongst critical severity IoCs than Defense Evasion. Other significant moves when filtering by critical severity include:

• Persistence appears in 38 percent of critical IoCs, as opposed to 12 percent of IoCs overall.
• Lateral Movement jumps from 4 percent of IoCs seen to 22 percent.
• Credential Access moves up three spots, increasing from 4 percent to 21 percent.
• The Impact and Collections tactics both see modest increases.
• Privilege Escalation plummets from 8 percent to 0.3 percent.
• Initial Access drops off the list entirely, previously appearing fourth.

Defending against the critical

This wraps up our high-level rundown of the IoC data. So armed with this information about the common threat categories and tactics, what can you do to defend your endpoints? Here are a few suggestions about things to look at:

Limit execution of unknown files

If malicious files can’t be executed, they can’t carry out malicious activity. Use group policies and/or “allow lists” for applications that are permitted to run on endpoints in your environment. That’s not to say that every control available should be leveraged in order to completely lock an endpoint down—limiting end-user permissions too severely can create entirely different usability problems.

If your organization utilizes dual-use tools for activities like remote management, do severely limit the number of accounts that are permitted to run the tools, only granting temporary access when the tools are needed.

Monitor processes and the registry

Registry modification and process injection are two primary techniques used by fileless malware to hide its activity. Monitoring the registry for unusual changes and looking for strange process injection attempts will go a long way towards preventing such threats from gaining a foothold.

Monitor connections between endpoints

Keep an eye on the connections between different endpoints, as well as connections to servers within the environment. Investigate if two machines are connecting that shouldn’t, or an endpoint is talking to a server in a way that it doesn’t normally. This could be a sign that bad actors are attempting to move laterally across a network.

Continue reading

How to Prepare for Cisco CCNP Enterprise 350-401 Certification?

Cisco ENCOR Exam Description:

This exam tests a candidate's knowledge of implementing core enterprise network technologies including dual stack (IPv4 and IPv6) architecture, virtualization, infrastructure, network assurance, security and automation. The course, Implementing Cisco Enterprise Network Core Technologies, helps candidates to prepare for this exam.

Cisco 350-401 Exam Overview:

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

Related Article:

• Make Way for the CCNP Enterprise 350-401 Exam!
  
  
• What Everyone Should Know About Cisco 350-401 Exam

Continue reading

Extend secure, automated branch office networking to AWS with Cisco SD-WAN Cloud OnRamp

According to a Cisco study, by 2021, there will be 20 zettabytes of traffic between the DC/branch to the clouds, as companies use popular public cloud platforms like Amazon Web Services (AWS). Meanwhile, “IaaS is forecast to grow 24% year over year, which is the highest growth rate across all market segments,” according to Gartner.

However, while a cloud strategy creates more agility, it also presents challenges for IaaS deployments. Below are three primary concerns cloud users face regularly:

Inconsistent connectivity

Large-scale networks may traverse multiple slow public and/or expensive private connections to get to the cloud deployments, while smaller networks may need to battle out a slow, jittery internet to get to the clouds. In either case, customers will need to find the fastest and most reliable link while confirming a secure transport.

Complexity with governance

No real uniformity exists as to how different platforms handle their governance and compliance. This maze of rules and frameworks can create consistency problems with companies trying to utilize more than one cloud platform, especially with (but not exclusive to) IaaS. Finally, each cloud vendor has its own policy, security and segmentation process. These variances from vendor to vendor add another layer of complexity that must be managed.

Visibility problems

Different cloud platforms also use various protocols for analytics, metrics and insights. This variance can effectively reduce visibility for companies, making it more challenging to optimize usage across the network.

Cisco’s SD-WAN Cloud OnRamp automates and optimizes the enterprise SD-WAN to IaaS and SaaS

Cloud OnRamp is a cloud networking solution and a functionality of Cisco SD-WAN through which enterprises can network their branch sites to workloads deployed in cloud environments. Cloud OnRamp provides seamless, secure and automated networking for IaaS as well as an optimized experience for various SaaS applications.

One proven way to overcome the challenges of a cloud strategy is by implementing a consistent fabric across a company’s entire WAN network using Cisco SD-WAN Cloud OnRamp. Cisco SD-WAN provides a secure WAN architecture that can extend consistent policy enforcement, segmentation and security across both on-premises and cloud networks. Cloud OnRamp simplifies the experience further through the power of automation, using vManage as the single pane of glass management platform to create a SD-WAN transit network in the cloud provider’s environment.

Advantages of Cisco SD-WAN Cloud OnRamp

◉ Greater automation — With Cloud OnRamp, users can expect to automate SD-WAN extension to the cloud in minutes with just a few clicks.

◉ Improved security – Cloud OnRamp reduces security risks by leveraging graular segmentation and streamlined policy enforcement that can control and segment the traffic that flows through the network, guarding against external and internal threats to the data.

◉ Ease of management – Cloud OnRamp provides end-to-end data sharing between cloud and branch and establishes inter-regional visibility across transit data and network telemetry.

Cisco SD-WAN Cloud OnRamp Integration with AWS Transit Gateway

Cisco has partnered with AWS to provide end-to-end solutions for joint customers to create the best possible user experience. Customers benefit from fully automated networking to workloads in AWS Cloud and native integration between Cisco SD-WAN and AWS Transit Gateway and Transit Gateway Network Manager.

Sneak peek of the new features and benefits:

◉ Fully automated Cisco SD-WAN fabric extension to AWS Cloud: instead of spending hours of time per region and going through error-prone manual processes, now enterprise customers can bridge their branches to AWS workloads through a fully secure Cisco SD-WAN network in just minutes.

◉ Single pane of glass management through Cloud OnRamp: jumping back and forth between different management consoles of Cisco and AWS to orchestrate networking resources can be challenging and ineffective. With this new integration, enterprise customers will be able to manage both the Cisco SD-WAN virtual router and AWS Transit Gateway through Cloud OnRamp.

◉ Extending enterprise segmentation to AWS Cloud: one important aspect of secure networking is to ensure consistent enterprise segmentation across the entire network. By using the GUI-based Intent Management feature in Cloud OnRamp, enterprise customers can easily manage VPN to VPC and VPC to VPC communications through simple clicks.

◉ End-to-end visibility: by populating elements of both the SD-WAN network and AWS cloud network into AWS Network Manager, enterprise customers will have a unified and visualized view of both branch and cloud sites.

Watch AWS, Cisco and joint customer ENGIE discuss the benefits of integrating Cisco SD-WAN with AWS Transit Gateway Network Manager in a recent webinar and learn how to get started.

With more than half of enterprise workloads expected to be deployed in public clouds within the next year, cloud computing is a growing opportunity and challenge for today’s enterprises. By deploying an integrated solution like Cisco’s Cloud OnRamp for IaaS, companies will stay competitive by making their cloud strategy more productive, consistent and secure.

Continue reading

API-Based Tools Make Cisco Device Management and Monitoring Easier

Cisco’s Intent-Based Networking (IBNG) Innovation Team is responsible for providing training labs, bootcamps and demos for customers, partners, internal sales at individual and public events. After each training we have to reset hundreds of devices and multiple controllers like Cisco DNA Center, ISE, DHCP, WLC etc. This manual reset takes the team a lot of time. During some of our events, we are required to reset multiple times a week or daily. To minimize the manual work and be more efficient, we created some API based tools that can complete the whole process in less than 30 minutes.

If you have any requirement for similar use cases, you can try our API-based tools that can save you time and reduce the tedious work!

We have 20-30 pods in each training lab. A pod is an individual testbed that contains different devices, such as edge/access, distribution and core devices.  These devices mimic a small customer Enterprise environment, with Catalyst3k and 9k switches, ASR and ISR routers and wireless controllers. During the lab, the devices are configured per various use cases.  Post each event, the devices need to be brought back to the beginning state. With the help of the APIs and scripts, we automated this reset process.

API-based Tools

For resetting devices such as Cat9ks, Cat3ks, ASRs and ISRs we are using SecureCRT APIs which can reset the device to a default state or configure the device to a base state. Using these scripts if a switch is in configuration mode, enable mode or in any other mode it will do necessary configuration changes and do the reset on the devices. Sometimes after reset we want to provide additional configuration that is not part of the base. For that we will use another script which can simultaneously run on multiple devices.

We also created a button bar in secure CRT and pointed the script to this button. This button bar is a quick way to run scripts, send strings and issue protocol commands on multiple sessions simultaneously. Step by step instructions for configuring this button can be referred here. Whenever we want to execute a script on any number of sessions just clicking on the button will execute the script on all the sessions opened. The following is an example for mapping a python script to a button in a button bar. All the links to these scripts is referred in What Next? section.

Next step is to reset Cisco DNA Center. For Cisco DNA Center, we are using Cisco DNA Center internal APIs to perform the backup and restore operations. We can also use these APIs to check the status of backups and restoration operations. Currently backup/restore APIs are for internal purposes only, these will be published in future. We also integrated these backup/restore scripts with Webex teams. So, if you execute any backup or restore script it will send a notification to the Webex teams and everyone in that Webex group will be aware of the changes.

Next step is to reset other controllers such as ISE/DHCP/DNS/Cat9800. We installed these controllers as VMs on ESXI hosts. To reset these VMs, we are using the snapshots and non-persistent modes for the VMs. Using the PowerCLI cmdlets we are creating new VMs from the snapshots and resetting the VMs for non-persistent mode. The following is an example to reset the controllers and create VMs from snapshots. All the links to these scripts is referred in What Next? section.

Monitoring API-Based Tools

After the reset process has completed, we are also monitoring the devices by using python applications.  If something happens to the device, such as a link or switch goes down, we will be notified in Webex Teams of this issue. We integrated Cisco DNA Center with Webex teams and configured the events on Cisco DNA Center to notify us of these alerts. If any issue happens, we will get a notification in the webex teams as alert. The following is an example for the switch unreachable notification in Webex teams that DNAC has sent via APIs.

The following is an example to subscribe to an event in Cisco DNA center and provide receiver details for sending the alerts. You can subscribe to specific events that may occur in your network. After your subscription, if the event does occur you will receive a notification by REST APIs. You can refer here for more details on how to subscribe to events.

Continue reading

Cisco 500-440 Sample Questions | Syllabus | UCCED Practice Test

Cisco UCCED Exam Description:

This exam tests a candidate's knowledge of design considerations and guidelines for deploying Cisco Unified Contact Center Enterprise (Cisco Unified CCE) solutions. Cisco Unified CCE is part of Cisco Unified Communications application suite, which delivers intelligent call routing, network-to-desktop computer telephony integration (CTI), and multichannel contact management to contact center agents over an IP network.

Cisco 500-440 Exam Overview:

• Exam Name: Designing Cisco Unified Contact Center Enterprise
• Exam Number: 500-440 UCCED
• Exam Price: $300 USD
• Duration: 75 minutes
• Number of Questions: 65-75
• Passing Score: Variable (750-850 / 1000 Approx.)
• Recommended Training:
• Administering Cisco Unified Contact Center Enterprise Part 1 (AUCCE1) 2.0
• Administering Cisco Unified Contact Center Enterprise Part 2 (AUCCE2) 2.0
• Deploying Cisco Unified Contact Center Enterprise (DUCCE) 2.0
• Exam Registration: PEARSON VUE
• Sample Questions: Cisco 500-440 Sample Questions
• Practice Exam: Cisco Unified Contact Center Enterprise Specialist Practice Test

Continue reading