New Cisco FindIT 2.0 Network Manager and Probe

The Cisco Small Business and the Cisco FindIT Product Teams are very pleased to announce the release of version 2.0 of the Cisco FindIT Network Manager and Probe. Some of the improvements mean that some use cases are now in play especially with larger scale scenarios. We think you all will be impressed by what the team has been able to accomplish!

This is a major update to Cisco FindIT and brings a couple of big improvements:

◈ A completely revised interaction model that greatly improves your ability to perform multi-site management. You can view, report and act on devices across multiple sites at the same time, and configuration profiles can now also be applied across multiple sites.

◈ Managed Services Providers will like the introduction of organizations. These allow you to group your customers’ networks together and filter your view to a single customer.  You can also limit individual users to being able to view and manage only a single organization or a subset of organizations.  This means you can even give your customers direct access to FindIT so they can see their networks without having any concerns that they will see the networks of any other customer.

◈ In-house IT Organizations will also love the new improvements of the multi-site, multi-tenancy as well the ability to manage separate sites easier, quicker and with greater efficiency. This allows organizations to do more with less.

In addition to these big changes, there are a number of smaller enhancements, including:

◈ Wireless reports are now more flexible and interactive, and keep a greatly extended history; up to two years’ worth of network data

◈ The FindIT Monitoring Dashboard has been reworked to allow it to be customized more easily and intuitively

◈ Cisco FindIT Network Manager now scales more flexibly than before. Previously, the limitation was by the number of sites, now this limitation is by the total number of devices under management

◈ Privacy controls have been added so you can explicitly control how and when any data gets shared with Cisco

◈ The installer packages and virtual machine images have been cryptographically signed to give you confidence that the software has not been modified or tampered with in any way

◈ In addition, numerous other enhancements and improvements have been made throughout the application.

Finally, for those of you who are interested in using our Cisco FindIT 2.0 Network Plug and Play for doing zero-touch deployments (No need to pre-configure or pre-stage) of your network hardware, we have put together the Network Plug and Play Solution Guide for SMB that goes through everything that you need to get the zero-touch process up and running. This is a big improvement!

Our team is very excited by this release, and we hope you think so too. For existing users, you should already have been notified about the update through the FindIT Manager user interface. For new users, go to https://www.cisco.com/go/findit-sw to download the software and try it out, or search for ‘Cisco FindIT’ in the AWS Marketplace. Remember, you may download and try FindIT for up to 90 days without any obligation.

Continue reading

Happy Birthday, Threat Response: Only a year old, but boy have you seen some things!

Cisco Threat Response: For security analysts, by one of their own

The work of a security analyst is arduous and time consuming but rewarding too. I know, I spent a good part of my career sitting in a seat, investigating and responding to threats in a Security Operations Center (SOC). I spent way too many hours and weekends moving from console to console piecing together information from disparate systems to investigate a single threat. The various SOCs I was part of were made up of millions of dollars in the latest, best-of-breed technologies alongside open source components and scripts that were supposed to work together but too often didn’t.

That’s why I’ve been focused on designing and building systems to make the lives of the security analyst easier and their work more effective. It’s rewarding to see the products we’ve built have a positive impact on an analyst’s abilty to do their job effectively. A year ago, we introduced a new application for security analysts to make security investigations fast and easy. It pulls content for detection and response from across the security stack: from the cloud, network, endpoint together in a central location. We call it Cisco Threat Response.

Rapid Adoption

Since we released the first version of Threat Response a year ago, it has been used in more than 3,600 SOCs, and has even added value in organizations without full blown SOCs. The feedback has been incredible and has given us so much confidence in Cisco Threat Response, we’re giving it away at no cost to existing customers. It’s included with the license for any Cisco Security product that integrates with it. As good as our Cisco Security products perform on their own, we know that they are even more effective when they’re used together. It’s all about making your SOC operations run faster: from detection, through investigation, to remediation. How? It’s all API-driven.

API-Driven

Cisco Security products have used APIs for years. The difference now is that Cisco Threat Response pulls them together so you don’t have to. With long lists of observables to investigate, Threat Response gets you immediate answers by calling both threat intelligence and our security portfolio APIs — confirming threats and showing you exactly where you’re affected — delivering a clear view of what’s happening.

Customers are excited to learn they can also utilize these APIs to integrate Threat Response directly into their existing Security Incident and Event Management systems (SIEMs) and Security Orchestration, Automation, and Response tools (SOARs). Customers even report they see Threat Response reducing the burden on their SIEMs.

And our customers seem to love this approach. One customer wrote to us “I like quickly being able to see infections on my network and this presents them in a really nice fashion…” Another said, “You cannot hit a target you cannot see. Threat Response simplifies security analysis”

Security integrations that simplify SOC operations

Picture a typical investigation that happens many times a day in SOCs around the world: A potential Emotet malware outbreak. Maybe you’ve investigated it yourself. Emotet a well-known banking trojan that attackers love, keeps coming back in fresh, new forms. The Indicators of Compromise associated with it include a very, very long list of known file hashes, distribution domains, and command-and-control IP Addresses. Investigating these observables one at a time to see if you’re affected can take hours.

Cisco Threat Response calls threat intelligence APIs to gather the all the dispositions for each one at once. Then it calls the Cisco Security products’ APIs and learns what each one knows about every observable. Cisco AMP for Endpoints knows what systems have the malicious file hashes. Cisco Umbrella knows which devices called out to malicious domains. Integrating your Email Security Appliance (ESA) lets you know who received that attachment or phishing URL and so forth until it gathers everything necessary to show you exactly what is happening in your environment.

More than a Pretty Face

Threat Response reflects years of back-end integration work by engineering. It begins and ends with a highly integrated architecture of world-class threat intelligence coupled the integration of advanced security technologies covering the attack surface across the cloud, network and endpoint. This is critical for effective, consistent detection and response across the critical points of your architecture.

Borrowing from the earlier example, an unknown file in an Emotet variant gets analyzed by our Threat Grid Malware Analysis engine and finds malicious behavior. Our architecture allows Threat Grid to share this intelligence across the entire portfolio so this file is blocked at the endpoint, in email, on the network for every customer around the world in a matter of minutes. And Threat Response shows you exactly every place where you were targeted by that file and confirms where it was blocked or detected.

Getting the Full Picture – the Relations Graph

That clear view we provide is perhaps the most compelling technology in Cisco Threat Response. By visually depicting the relationships among the observables and dispositions, the affected systems in your environment (called Targets and shown in purple), and the other systems that are related to the outbreak, you’ll know immediately whether you’re affected and how. Skip the hours and hours of investigation time.

Plus, you can take action directly from the Relations Graph. It provides actions (called Pivot Menus) from which you can continue the investigation in the other products’ consoles (taking you there seamlessly) or call their APIs directly to take action. Those Targets shown in purple? Maybe you want to quarantine those hosts through AMP for Endpoints, which you can do with a single click. Those malicious C2 domains? Maybe you want to tell Umbrella to block, at the DNS layer, everything on your network from connecting to them, which you can with another click.

Sources of Detection

Threat Response is driven by the individual Cisco Security products and threat intelligence sources that feed into it. Cisco Talos research and Threat Grid for threat intelligence, Threat Grid for static and dynamic file analysis, AMP for Endpoints for dynamic and retrospective endpoint detection and response, Email Security (the number one vector of attack), Umbrella for internet domain intelligence and blocking, and Next Generation Firewall for network detection and blocking. Threat Response brings these products together to bring you context about the events seen in your environment allowing you to further enrich this context with your own intelligence sources.

Operationalizing Threat Intelligence

One of the most popular features is the browser plug in we’ve developed that takes unstructured data from any webpage or application, finds the observables or indicators of compromise and automatically renders a verdict on that observable (clean, malicious, unknown) based on our threat intelligence. Like that Talos blog example we used earlier: one click pulls all the observables mentioned on that page without the need to manually cut and paste each one (and there are 634 observables mentioned – I had them counted!) Moreover, you can access the Threat Response pivot menu, including domain blocking, without ever leaving the page.

The best part about Threat Response is rate of innovation within the application. The endgame is better cybersecurity through better SOC operations: faster detections, simpler investigations, and immediate responses. We love what we have released to date and even more excited about our roadmap. Our engineering teams are delivering new enhancements, including new features and product integrations every two weeks. There’s much more to say about Threat Response than I can detail in a blog. I encourage you to experience it for yourself. The work of the SOC teams is too important to be tedious and increasing their efficiency will have better security outcomes for everyone.

Continue reading

When you request a .jpg and get ransomware

Security Operations Center at RSAC APJ 2019

For the 3rd year, RSAConference 2019 APJ created an educational exhibit, sponsored by RSA, Cisco and M.Tech, to monitor the RSA Conference public Wi-Fi network provided by the Marina Bay Sands (MBS). This exhibit was created in the form of the RSA Conference Security Operations Center (SOC). RSA and Cisco provided technology and staffing to monitor the network for threats, but also to educate attendees on the risks of free Wi-Fi.

What is the difference between a SOC and a NOC?

Network Operations Center

The NOC is usually responsible for monitoring and maintaining the overall network infrastructure—its primary function is to ensure uninterrupted network service

Security Operations Center

The SOC is responsible for protecting networks, as well as web sites, applications, databases, servers and data centers and other technologies

RSA and Cisco provided the SOC. The NOC was provided by the MBS.

The mission of the RSAC SOC was to ensure the conference Wi-Fi is not attacked (denial of service, laterally spreading malware, etc.). We did not block malicious DNS traffic, downloads or attachments; as this was a learning and demonstration environment. We make sure that network is protected from attackers. We locate (when we can) and advise users when they are at risk.

What technology is in the RSAC SOC?

MBS provided the RSAC SOC a span of all network traffic from the .RSACONFERENCE network, which was passed through the Cisco Next Generation Firewall / ISP and then split the traffic to NetWitness Packets NetWitness Packets and the Cisco Stealthwatch teams.

RSA used NetWitness Packets to collect and investigate all traffic on the Wi-Fi network, from the firewall; to detect deviations from normal behavior and create a probability-weighted risk score for alerts based on these results. NetWitness inspects every network packet session for threat indicators at time of collection and enriches this data with threat intelligence and business context. At the end of the conference, all of this data was wiped from NetWitness.

For suspicious files that might be malicious, NetWitness Packets checks a community AV lookup, some static analysis and its own network intelligence. Then NetWitness Malware Analysis sends the files to Cisco Threat Grid for dynamic malware analysis.

Threat Grid combines advanced sandboxing with threat intelligence into one unified solution to protect organizations from malware. Threat Grid analyzes the behavior of a file against millions of samples and billions of malware artifacts. The SOC team had a global and historical view of the malware, what it’s doing and how large a threat it posed to the RSAC network.

Threat Grid identifies key behavioral indicators of malware and their associated campaigns. The SOC team was able to save time by quickly prioritizing attacks with the biggest potential impact. We used tools like Glovebox, to safely interact with samples and observe malware behavior directly. In addition, we used Cisco Umbrella to have visibility in all DNS activity. We also used the Threat Intelligence of Cisco Threat Response and Talos Intelligence.

When the Cisco team found a potential threat, they handed it off to the RSA team for further investigation. In summary, the technology stack was:

◈ Firewall – Cisco Next Generation Firewall with IPS

◈ Full Packet Capture and Investigation – RSA NetWitness Packets

◈ Dynamic File Analysis – Cisco Threat Grid

◈ DNS / IP Intelligence – Cisco Umbrella / Cisco Umbrella Investigate

◈ Encrypted Traffic Analytics – Cisco Stealthwatch

◈ Threat Intelligence – Cisco Threat Response / Talos Intelligence

Perimeter Defences: Stopping Threats That Matter

Cisco’s Next-Generation Firewall running Firepower Threat Defence (FTD) software was set up as the perimeter security device. The firewall inspected all wireless guest traffic from event attendees, configured in monitor-only mode. FTD offers breach detection, threat discovery and security automation. Rich contextual information (such as Applications, Operating Systems, Vulnerabilities, Intrusions, and Transferred Files) served the SOC to help uncover threats lurking in the environment.

Discovered Applications

Discovered Files

Intrusion Information

During the conference, several intrusion events were recorded by FTD. Automated event analysis correlated threat events with contextual endpoint data, to identify IPS events that require immediate investigation. Whenever a working exploit targeted a vulnerable host on the guest network, an Impact 1 event was raised. For the SOC, that helped cut through the noise and focus attention to save previous time.

Multiple events were categorized as high priority.

One of the Impact Flag 1 events shown below, signalling about suspicious .bit query going over DNS, and associated with a Network Trojan.

The FTD would drop this communication, if it were in a production environment and configured in the active blocking mode. Reviewing the host profile, we confirmed that the target host had a large number of high-severity vulnerabilities associated with unpatched software versions. It may have been infected by malware attempting to control it remotely.

When you request a .jpg and get ransomware

On the first day of the Conference, the SOC team observed a .JPG file served to a conference attendee who connected to a website. The .JPG file was extracted by NetWitness and found to actually have a file header of MZ, used for executables.

Since it was an executable, it was automatically sent for analysis. The static analysis had a score of 0 and 50 from the RSA Malware Analysis Community lookup, meaning it had never been detected by dozens of AV vendors.

The Dynamic Analysis/Sandbox score from Threat Grid was 100, meaning confirmed malicious based on behavior. The team went into action to assess the threat.

The supposed .JPG file was assigned a Threat Score of 100 for the Behavior of Troldesh Ransomware Detected. Troldesh, also known as Shade, is a Russian-targeted Ransomware variant written in Visual Basic. It will encrypt user files and request a ransom to be delivered after contacting a supplied e-mail address. All encrypted files will have an .xtbl extension appended to them.

We also noted the sample attempted to hide itself as a Windows system file, opened up a Personal VPN – Proxy/Anonymizer and wrote files to a USB drive.

We pivoted to Threat Response to learn more and determine if it had been seen before.

With Threat Response we were able to have a global view of the file, that it was first seen November 2018. In a production environment, this threat intelligence would have blocked the file on all integrated Cisco Security platforms.

The NetWitness team investigated the machine that requested the .jpg and confirmed it downloaded other suspicious files.

One of those was titled Memorandum of Sale, but also was an executable that attempts to steal Firefox passwords.

Phishing attack

We also saw a phishing attack, masquerading as a banking email. NetWitness reconstructed the email and sent the attachments to Threat Grid for analysis.

The Payment Advice attachment was actually the LokiBot malware.

Standing up a malicious domain for 24 hours

On the first day of the conference, we noticed some suspicious DNS traffic in Umbrella to a newly created domain. The requests happened throughout the day.

We moved to Umbrella Investigate to learn more and confirmed the sudden malicious activity of 0 DNS requests to over 120,000 global requests.

The requests spiked to 151,000 over the 24-hour period and then they stopped, globally.

We could see the domain was registered in Russia and the distribution of the requesters.

Looking at the NetWitness logs, we could see all requests from RSAC came from Android devices.

Outbound traffic for hostname rousema[.]com [208.67.220.220] we can see 13 sessions from 10:50 AM - 16:50 PM SGT Tues 16th/Jul.

service type UDP DNS & HTTPS

This is originating from 3 IPs

10.10.1.143 Android 9 Samsung Phone sm-g955f running dalvik/2.1.0, Samsung M1client daylite/3.0.05.9 & x86_64 Linux - 11:06 AM SGT - 15:23 PM - (All traffic from IP from 10:31 AM - 16:59 PM)

10.10.5.9 Android 7.0 Phone trt-l21a running dalvik/2.1.0 & Android 2.2 - 10:50 AM SGT - 17:06 PM - (All traffic from IP from 10:51 AM - 23:19 PM)

10.10.2.31 x86_64 Linux & Android 9 Samsung Phone sm-n950f running dalvik/2.1.0(13:12 AM SGT - 13:12 PM - (All traffic from IP from 10:31 AM - 14:16 PM)

Dalvik is the discontinued process Virtual Machine in Android 4.4 and earlier

It was a textbook example of a temporary domain infrastructure that would be blocked in a production environment.

Overall, we saw over 5m DNS requests during RSAC APJ. A couple of thousand would have been blocked in a production environment.

We were also able to have visibility in the 2,001 apps that had DNS activity during the conference.

Stealthwatch brings additional network visibility

Stealthwatch detected insider threat activities like Command & Control activity and Data Exfiltration just over the baseline period of two days, indicating potential threats on the network.

The solution with its unique ability to look at encrypted traffic without decryption, also detected users with unknown TLS version.

Now we can extend this comprehensive visibility to cloud networks as well with an offering called Stealthwatch Cloud.

Continue reading

Optimizing Multi-Cloud Connectivity with Cisco SD-WAN Cloud onRamp for Colocation

Enterprises are busy implementing SD-WAN to provide cost-effective, secure, and application-aware connectivity to multiple cloud platforms for branches and remote offices. The results are clear: a distributed workforce obtains superior Quality of Experience (QoE) for multi-cloud and SaaS applications with a full security stack built-in to the edge routers to protect data and privacy. Choosing direct internet or direct cloud connectivity options reduces latency to provide appropriate levels of QoE for SaaS applications while eliminating the expense of backhauling all branch traffic to distant enterprise data centers. For many organizations with a network of remote sites, implementing Cisco SD-WAN at each branch is a perfect union of control, cost effectiveness, and security.

However, aggregating access to multi-cloud applications from multiple branches to regional CoLocation facilities may be a better solution for:

◈ Multi-national organizations that prohibit using direct internet connections to cloud and SaaS platforms at the branch level due to data security restrictions and international privacy regulations for cross-border sharing of personal information.

◈ Global organizations, such as financial institutions, that often have thousands of branch offices spread over multiple geographic regions, each one requiring high application QoE with granular security over traffic segmentation and application access; providing each site with an edge router may not be the most cost-effective implementation.

◈ Partners and vendors, who are not using SD-WAN, still need connectivity to their customers’ enterprise resources and applications but do not want to install a customer’s SD-WAN routing appliance in each of their sites to provide secure access.

◈ Remote workers—at home offices or mobile—need secure VPN connections to enterprise resources over inexpensive direct internet links without backhauling traffic to a VPN firewall at a central data center and incurring additional latency that affects application performance and voice/video quality.

In these cases, it can be more efficient and economical to regionalize SD-WAN services in colocation facilities that are physically closer to the branches and often may even host the cloud resources they need to access. Creating a software-defined virtualized multi-cloud onRamp for CoLocation facilities to serve groups of regional branch offices, partners, and a remote workforce, provides consolidation, control, and security for large distributed organizations and those with regulatory compliance challenges.

Consolidation, Control, and Security

To simplify the deployment and management of SD-WAN for multiple branches distributed over several regions, Cisco is introducing the Cisco SD-WAN Cloud onRamp for CoLocation. This new capability expands Cisco SD-WAN onRamp features that make it easy to optimize IaaS and SaaS performance. The platform of virtualized network functions (VNFs) and trusted hardware runs in a colocation facility to provide connectivity to multi-cloud applications, along with an integrated security stack and cloud orchestration for remote management.

A typical use case for implementing a Cloud onRamp for CoLocation is an enterprise that has dozens of distributed branch offices, clustered around major cities, spread over several countries. The goal is to tie each branch to enterprise data center databases, SaaS applications, and multi-cloud services while meeting SLAs and application QoE expectations. Each region encompassing the target cities uses a colocation IaaS provider that hosts the Cisco Cloud onRamp for CoLocation, which consists of physical and virtual components:

◈ Cisco SD-WAN vManage for centralized management of the SD-WAN Fabric, the Cloud onRamp for CoLocation feature makes it easy to manage policy and deploy VNFs in a colocation facility.

◈ Cisco Cloud Services Platform (CSP) 5444 for hosting the VNFs.

◈ Cisco Catalyst 9500-40 Switches provide multi-gigabit backplane switching to VNFs, redundancy, inbound/outbound WAN connectivity, and access to colocation management tools.

With Cisco SD-WAN Cloud onRamp for CoLocation operating regionally, connections from colocation facilities to branches are set up and configured according to traffic loads (video vs web browsing vs email), SLAs (requirements for low latency/jitter), and Quality of Experience for optimizing cloud application performance. Each branch or private data center is equipped with a network interface that provides a secure tunnel to the regional colocation facility. In turn, the Cloud onRamp for CoLocation establishes secure tunnels to SaaS application platforms, multi-cloud platform services, and enterprise data centers. All traffic is securely routed through the Cloud onRamp for CoLocation stack which includes security features such as application-aware firewalls, URL-filtering, intrusion detection/prevention, DNS-layer security, and Advanced Malware Protection (AMP) Threat Grid, as well as other network services such as load-balancing and Wide Area Application Services.

The platform also enables non-SD-WAN-managed traffic from partners, for example, to funnel through the colocation facility on the way to other branches, data centers, or SaaS applications, taking advantage of the Cloud onRamp’s security and policy management. A remote-office or mobile workforce can use SSL VPN tunnels to access the colocation facility directly, and from there the services and platforms connected via the SD-WAN. If a partner organization has an existing physical link to the colocation facility, the Cisco Cloud onRamp for CoLocation is capable of terminating the link to join the service chain.

Multi-Cloud, Multi-SaaS Connectivity with Security and Trust

With virtualized Cisco SD-WAN running on regional colocation centers, the branch workforce has access to applications and data residing in AWS, Azure, and Google cloud platforms as well as SaaS providers such as Microsoft 365 and Salesforce—transparently and securely. Distributing SD-WAN functionality over a regional architecture also brings processing power closer to where data is being generated—at the Cloud Edge. It’s at this intersection of the network, cloud, and security where businesses face greater risks, inconsistent application performance, and increasing complexity. The Cisco Cloud OnRamp for CoLocation applies consistent security policies across branches, devices, and people depending on authorized access requirements, even when multiple service providers are routing traffic.

With the SD-WAN functionality hosted in a colocation facility, ensuring that router appliances and software are original Cisco products and have not been tampered with at any stage of installation and operation is a critical consideration. That’s why Cisco embeds an encrypted Secure Unique Device Identifier (SUDI) in tamper-resistant silicon in SD-WAN router appliances. This foundational level of trust is complimented with VNF image signing, secure boot, and the Cisco Secure Development Lifecycle to ensure software and hardware are tamper-proof. With this built-in level of trust established, IT can remotely configure and manage Cisco Cloud onRamp for CoLocation installations from the other side of the world with confidence that the target Cisco hardware and software are original and uncorrupted.

Open Architecture Integrates Third-Party Functionality

Recognizing that enterprises with distributed workforces and regional offices often rely on a variety of networking products, the Cisco Cloud onRamp for CoLocation has an open architecture, enabling third-party VNFs to integrate with the SD-WAN fabric. For example, even though Cisco SD-WAN comes with an integrated security stack, an organization may already have trained and programmed a third-party security firewall or Intrusion Protection solution and wish to integrate those services in each Cloud onRamp for CoLocation. Other VNFs such as Load Balancers and Web Application Security can be added as needed to conform to an enterprise’s existing configurations and security policies. The Cisco Cloud onRamp for CoLocation fully supports custom applications as well, using a custom packaging tool to bundle the specialized apps and integrate them into a service chain.

Secure Multi-Cloud Connectivity—Everywhere You Need It

Whether deploying SD-WAN at the cloud edge to serve an individual branch office or via colocation facilities to serve multiple regional sites, Cisco provides simplified orchestration and automation of enterprise WAN service chains. Our software-defined architecture ties together a distributed workforce with multi-cloud applications using VNFs that can be rapidly provisioned and expanded on flexible colocation platforms to meet evolving business needs and regulatory requirements. Keeping regional offices connected and productive is more cost effective and easier to manage than ever.

Continue reading

Using DCNM 11 for Easy Provisioning of Networks and VRF’s

As you might remember from our last post within our DCNM 11 series, we discussed provisioning underlay for VXLAN EVPN fabric using fabric builder in DCNM 11. Today, we’re continuing the discussion by featuring how Cisco’s Data Center Network Manager (DCNM) empowers Easy Provisioning of Overlays using pre-defined, best practice, out-of-box templates.

Once the underlay has been deployed via the DCNM fabric builder, overlay-related networks and VRF configurations need to be provisioned on the appropriate devices. DCNM provides simple workflows for provisioning of overlays in multiple fabrics, using flexible, customizable profile templates. Beyond the creation of Networks and VRFs for end-point attachment, Data Center Interconnect (DCI) and external connectivity like Inter-AS Option A (aka VRF-lite) can be configured with minimal user input. Various resources required for Layer-3 hand-off configuration are auto-generated from user-defined pools, making the setup of external connectivity a breeze.

In the case of DCI using VXLAN EVPN Multi-Site technology, DCNM provides a simple way to auto-configure the border gateway and core device peerings. Overlay provisioning workflows have enough built-in intelligence to abstract out the various kinds of underlays and greatly aid the network administrators in the migration of the centralized gateway employed in legacy environments, to the distributed IP anycast gateway in VXLAN EVPN environments.

Networks and VRFs in DCNM 11.2

DCNM allows users to create a Layer-2/Layer-3 Network and its associated VLAN, VRF and VNI, using out-of-box best practice templates. A Layer-2 network can be incrementally migrated to Layer-3 by mapping that Network to an appropriate VRF. DCNM automatically deploys a VRF to a switch when a Layer-3 network associated with that VRF is deployed to that switch. Appropriate references and states are maintained on a per switch, per network and per VRF basis.

For ease of deployment, DCNM provides a “Propose VLAN” option that provides the next available VLAN not being used across all switches within a fabric; this in turn can be mapped to a new Network. Similarly, when multicast is chosen as an option to carry BUM traffic within a given fabric, DCNM manages the user-defined multicast pool and provides flexible options of mapping multicast groups to networks and VRFs. Various configuration knobs are available that can be incrementally added/edited post network creation and/or deployment. These include features such as ARP suppression, IPv6 enablement, secondary gateway IPs, DHCP relays, Tenant Routed Multicast, VXLAN OAM etc.

Creating Networks in DCNM 11.2

During Network and VRF deployment, users can select multiple switches at the same time, either through the topology view or the tabular view. With DCNM, the save, preview (optional), and deploy continuum works in the same way for overlays as is the case for any other configuration. With the preview option in the Network and VRF workflow, there is relevant overlay configuration for review before the changes are pushed to the respective switches. The complete history of what changes were deployed by whom, when and where are maintained on a per switch, per interface, per network, and per VRF basis.

Deploying Networks and VRFs in DCNM 11.2

Networks and VRFs once deployed are seen in a tabular view as well as captured in the Resource Manager, thereby maintaining state of the configurations. This allows DCNM to provide the next set of available overlay resources from user-defined pools thereby preventing any misconfigurations in overlay provisioning. DCNM supports consistent porting of underlay and overlay configurations to a new switch when the RMA workflow is triggered for a faulty switch. Overlay network and VRF configuration are automatically gleaned from switches in an existing VXLAN EVPN fabric when using the powerful brownfield import feature in DCNM.

List of Networks created using DCNM 11.2

List of VRFs created using DCNM 11.2

DCNM allows users to schedule backups at a fabric level where DCNM captures the config and state of each switch, thereby having a complete notion of which Networks and VRFs are deployed where. These come in handy when doing a restore of the configs and state at a fabric level.

In addition to the web-based user interface and REST APIs, DCNM also supports bulk creation of networks and VRFs via a csv file import option with pre-defined overlay network and VRF definitions. To keep changes at hand, all network/VRF definitions including their current and historical deployment status, are available as a report.

Continue reading

How to prepare for ICND1 100-105 Certification Exam?

Exam Name: Interconnecting Cisco Networking Devices Part 1

Exam Code/Number: 100-105 ICND1

Exam Overview: This exam tests a candidate's knowledge and skills related to network fundamentals, LAN switching technologies, routing technologies, infrastructure services, and infrastructure maintenance.

Practice Exam: Cisco Certified Entry Networking Technician Practice Test

Sample Questions: Cisco 100-105 Sample Questions

Continue reading

How To Provision a Production-Grade Kubernetes Cluster From Anywhere, With Just One Button (Literally)

Do you remember?

I bet all of you who are working or playing with Kubernetes still remember perfectly the first time you tried to install it.

And then the second time.

And then the third time.

…

And finally, the one that it worked.

And most likely, if you’re a professional you also remember the long path that brought you to own the required expertise on Kubernetes in order to set up and fine-tune production-grade clusters to run apps.

Or, if Kubernetes is not part of your job’s scope, you probably remember how much time it took for you to find someone able to perform a valid Kubernetes install…and how much it costed.

To save all this time and effort to our customers Cisco released Cisco Container Platform (CCP), a turnkey solution to easily provision production-grade Kubernetes clusters on-prem or in the cloud in minutes, with few mouse clicks and requiring little to no knowledge of K8s. All the required integrations in terms of network, storage and security are done automatically by CCP so that the provisioned K8s clusters are ready to run in production.  Clusters provisioned by CCP are already equipped with properly-configured monitoring and logging tools like ElasticSearch, FluentD, Kibana. Through the Container Network Interface (CNI) you can choose whether to leverage Cisco ACI as network infrastructure or other ones such as Contiv or Calico (no dependence on the underlying infrastructure). With CCP you can take care of the full life-cycle of the K8s cluster: you can easily perform Kubernetes software upgrades, nodes upgrade, cluster scale up or down and cluster deletion.

This is already good and if you are following our cloud announcements you might already know this, so I thought I’d create a demo that may push the simplicity of those “few mouse clicks” to its limit, making possible to create a production-grade cluster in just one click – literally.

Introducing the Kubernetes dash button.

The concept is fairly simple: build a dash button that, once pressed, creates a production-grade Kubernetes cluster ready to use.

Leveraging the rich set of the Cisco Container Platform (CCP) APIs this is even too easy, so I thought to add some more feature on top:

◈ I wanted to provision the cluster and access it just through the dash button. So, I wanted CCP to display on the dash button itself the IP address of the master node of the cluster created

◈ I wanted bi-directional communications between the dash-button and CCP itself, so that I can check on the dash button if CCP correctly received the provisioning request, and make sure that the provisioning process has started and then finished.

◈ I wanted a fair battery life that would avoid me having to recharge the button every day, so I needed to have electronics able to sleep or hibernate

◈ My lab, where I have the infrastructure and CCP, is behind a proxy, and therefore not accessible from the outside world, which meant I had to find a way to have my lab initiate communication with the dash button by actively checking the press of the button

◈ I wanted to use the button everywhere I go without worrying about the local Wi-Fi settings

How it works

To satisfy all the above requirements I added a couple of elements in the picture, ending up with the following architecture:

The button is based on an Arduino ESP 32 board, it connects via Wi-Fi to my smartphone and uses its internet connection, this way I can use the button everywhere my phone has data signal. A publish-subscribe message service (MQTT) on the internet is used to bypass the proxy limitations. I hosted the MQTT at home but you can provision one on AWS or use a free MQTT service on the cloud. Once pressed, the button publishes a special message on the MQTT service. Inside my lab, a couple of scripts are constantly polling the MQTT service and, as soon as they detect the special message, they invoke the right API in the Cisco Container Platform to trigger the provisioning of a shiny new Kubernetes cluster. Once the cluster is provisioned, the IP address of the master node is returned, through the MQTT service, to the dash button that shows it on its display, and, at this point the Kubernetes cluster is ready to accept connections and run applications.

I went to town with it and added a 3D printed enclosure to complete my project; I initially downloaded an existing model but then I decided to  leverage the capabilities of CCP to deploy K8s clusters on-prem and  in the cloud, so I designed the two different enclosures as you can see in the picture below, so I can have two different dash buttons for the two different deployment targets. 

Now, every time before I present my demo, I ask to my customers: “How much time and effort does it take you to install a production-grade, fully operationalized and secured Kubernetes cluster?” and whatever answer I get, I know I can answer “I can do it in 2 minutes blindfolded and cuffed”.

Continue reading