Cisco NDFC One View – Centralized Management of the Global SAN Infrastructure

Cisco Nexus Dashboard Fabric Controller (NDFC) is a scalable application for managing Fibre Channel SAN. However, in some cases a single NDFC server may not be efficient. For example, it may be a better solution for large global environments to utilize a dedicated NDFC server for each region or department. But how do you get a centralized view of the global SAN infrastructure when using multiple instances of NDFC managing separate regions or departments?

The answer is NDFC One View. It delivers the centralized management and visualization of multiple SAN environments that are managed by different NDFC servers.

What does NDFC One View offer?

NDFC One View provides insights into what is happening within the Fibre Channel SANs at multiple locations in a single pane of glass. It offers the following:

◉ Executive Dashboard: Important and relevant information.

◉ Faster Troubleshooting: Centralized view of the fabric and switch health.

◉ Increased Collaboration: Define the access using Role-Based Access Control (RBAC).

◉ High Availability: Each participating NDFC server can run on a 3-node active-active Nexus Dashboard cluster.

◉ Simplicity: Single Sign-On (SSO) allows seamless click-thru navigation to any of the servers that participate within NDFC One View.

◉ One View in Context: One View is always just a click away via a breadcrumb regardless of the participating NDFC server.

Figure 1: Nexus Dashboard SAN Controller One View

You can view a summary of all the SAN switches across the globe on the NDFC One View Dashboard.  However, for making a change on any of the switches, such as creating a zone, you must do that from the NDFC server that manages that switch. NDFC One View simplifies this inter-cluster navigation with a single log in, so you do not have to remember which switches are managed by which Nexus Dashboard (ND) clusters.

How does NDFC One View work?

NDFC One View is an intuitive presentation layer. Only when accessed, it uses the RESTful APIs over HTTPS transport for retrieving the data from the participating NDFC servers. NDFC One View doesn’t store any additional data, or increase the storage requirement of the ND clusters.

No Extra Licensing Requirements for NDFC One View

Unlike other competing solutions, there is no extra license for NDFC One View. If you already have DCNM advanced license for managing Fibre Channel switches, you can start using NDFC One View today with no added cost.

How is NDFC One View different from Cisco Nexus Dashboard One View?

Cisco Nexus Dashboard (ND) One View and NDFC One View are different features. ND One View provides centralized management of Nexus Dashboard itself, which is a hosting platform in which applications such as NDFC can run. In contrast, NDFC One View provides centralized management of the global SAN Infrastructure that is managed by different NDFC servers.

How is NDFC One View different from DCNM Federation?

DCNM SAN, the predecessor of NDFC, provides high availability using a Federation. The participating DCNM servers in a federation must use an externally shared Oracle RAC database, which increases the total cost of ownership. In contrast, Nexus Dashboard integrates all the required services, including the distributed database services, which provide native active-active clustering. This design makes NDFC One View even more affordable.

How-to setup NDFC One View?

It’s easy. First, configure remote authentication for the Nexus Dashboard clusters. Then, add the address and the credentials under Infrastructure > Cluster Configuration > Multi Cluster Connectivity.

Source: cisco.com

Continue reading

Got Windows… But Jonesing For Linux?

I suspect most people are aware of the Windows Subsystem for Linux (WSL). And how you can use it to install a distribution like Ubuntu on Windows. That will get you all the command-line features of Linux, which are many. Most people I know use vi as their console-based editor. I prefer Joe’s Own Editor (joe), which I have customized to use my favorite keystroke commands. And then there’s Midnight Commander (mc), which is a favorite for file and directory navigation.

But what about the powerful GUI applications? This blog entry shows you how to get them working on Windows 10 and Windows 11.

I’ve been a Linux guy for decades now. But when I began my career at Cisco with Developer Support, I chose Windows 10 as my operating system. At that time, David Staudt had Linux covered and David Nguyen had a Mac, so I filled in the gap. I like Windows 10. I like Windows 11 even more. It puts the virtual desktop chooser at the bottom of the screen, like Windows 10 originally did it.

But I’m still a Linux guy at heart

So, when it comes time to get a laptop refresh, I will be getting a Mac. No, it’s not Linux, but OS X has a lot of BSD (Berkely Software Distribution) in it (and/or FreeBSD, depending on who you ask), so it is a familiar platform for Linux users like me.

Why does the Mac build on FreeBSD and not Linux? My friend Brett Glass made very strong arguments for FreeBSD over Linux back in the day. He pointed out that you can build proprietary code on top of FreeBSD and make money doing it. Steve Jobs, when forced out of Apple, started up NeXT, a computer that ran on a BSD-based OS. So, the foundation for making money on BSD was already laid. Apple simply continued the evolution.

That’s hard to do with Linux. The GNU Public License (GPL) constrains Linux proprietary use, because (for the most part) you must share your Linux code free of charge. The way to make money is to charge for support. Of course, that’s an over-simplified comparison of BSD vs Linux, but that’s the gist.

While I can clearly see the advantages of an open-source operating system like Linux, I’m beyond caring about the philosophical differences, these days. I just prefer a UNIX-like operating system for my personal use over Windows. So, the Mac is a great choice for me.

In the meantime, while I wait for a laptop refresh, there’s a way to run Linux on Windows, and that’s what this blog entry is about.

Here’s how to start:

First, you must make sure your computer BIOS settings allow your CPU to support virtualization. If you can’t do that, then I can’t predict how the rest of these instructions will work out.

Then you need to install some optional Windows features, if they aren’t already installed. There are different ways to get to the Windows optional feature installation dialog, so I’ll just jump right to it and assume you know how.

Install Hyper-V, Virtual Machine Platform and Windows Hypervisor Platform shown in these two sample screen shots:

Some may say, like chicken soup, one or more of these wouldn’t help, but it wouldn’t hurt. Click OK and do whatever Windows tells you to do if anything.

Now, make sure you have the latest graphics drivers installed. I have a Radeon 5700 XT on my personal computer running Windows 11. My company laptop has an Nvidia Quadro display adapter.

Open the Microsoft Store and “get” a copy of Ubuntu. I recommend Ubuntu 22.04.1 LTS, unless a later version is available by the time you read this. Run it, and the installation will ask you for your language, a username and password, and not much else.

Open a Windows PowerShell console with administrator privileges. Perform these operations:

C:>wsl –list

C:> wsl --set-version Ubuntu-22.04 2

C:> wsl --set-default-version 2

It is possible those are already the default settings (and that last command is probably redundant), but it’s worth making sure.

Now launch Ubuntu from the Windows menu, and enter these commands:

$ sudo apt update

$ sudo apt dist-upgrade

You can use “upgrade” instead of “dist-upgrade”, but “dist-upgrade” is more comprehensive. It removes unnecessary files and adds newly needed files. The “upgrade” option only upgrades what you already have on your system.

Let’s install some sample apps. If you’re like me and prefer the KDE Plasma desktop on Linux, install the KDE editor, kate.

$ sudo apt install kate

If you’re a fan of GNOME, install gedit instead.

$ sudo apt install gedit

And just for fun, install some basic X11 GUI apps.

$ sudo apt install x11-apps

You can install whatever other Linux GUI apps you like, but the above will get you started. The one thing you cannot do is install a graphical desktop, like Xfce, KDE Plasma, GNOME, Cinnamon, or any of the many other desktops. But you can run almost any graphical application.

You need to set an environment variable for the X11 display. So back in the Ubuntu terminal type:

$ export DISPLAY=:0.0

That’s only good for this one Ubuntu terminal session, so edit your .bashrc file and add this line somewhere at the top of the file:

DISPLAY=:0.0

STOP, do not turn the page until told to do so

If you are running Windows 11 or some super-secret double probation version of Windows 10, you can stop installing, open an Ubuntu terminal window and happily run your Linux GUI applications. For example, start kate or gedit (the ampersand launches the app and returns you to the prompt):

$ kate &

$ gedit &

If, on the other hand, you’re on Windows 10, there’s more for you to do. There are several different ways you can get Linux GUI apps working on Windows 10, but here’s what I have found to be the easiest. Download and install MobaXTerm. You can install the free home version or the paid version if it is for business purposes.

Once you have it installed, launch MobaXTerm. You should see something like this:

You see that X server icon in the upper right? If it’s in color, you’re gold. If it’s black and white, click it to start the X server.

You can see that MobaXTerm is aware that you have Ubuntu-22.04 installed. Double-Click on that to bring up a terminal for Ubuntu-22.04. DO NOT use the “Start local terminal” button. That way lies madness.

You should see something like this:

Now go ahead and start kate or gedit, or whichever app you like. I started xeyes and kate. Yes, kate complains about missing theme items, but I can install those later.

Voila, I now have access to graphical Linux apps:

And there you have it. All the pleasure of using Linux graphical applications on a Windows computer.

Source: cisco.com

Continue reading

Leveraging the Cloud to Scale your Industrial DMZ

The iDMZ (industrial demilitarized zone) is a critical layer in a comprehensive end-to-end security strategy for an industrial operations environment. The primary function of the iDMZ is the enforcement of a secure boundary between the internal trusted operations environment and external entities that may need to exchange data with services that support the operation.

One of the challenges with an exclusively on-site iDMZ is the limited ability around expansion to meet future demand and capabilities. With the growth of Industrial IoT (IIoT), it will be necessary for hardware and resource growth to meet the demands of increasing data. This translates to a consistently increasing hardware footprint and utilities to provide cooling and power, which can be in limited supply on premises. In addition, operators must explore new ways to obtain deeper insights and introduce enhancements to the operation, which may require tighter alignment with partners and/or the ability to securely consume XaaS offers.

Operators also have a safety-first culture, keeping people out of the “line of fire.” Vendors and partners may need to maintain on-site hardware, applications and services, potentially exposing people to risk through their presence on-site. For heavy industry environments, accessibility to site and the equipment residing on it is not necessarily an easily accomplished task. Many industrial sites require site safety training and approved work permits as a prerequisite for physical access.

Finally, a lack of iDMZ consistency when comparing multiple sites, from a hardware and feature composition, creates challenges for operations staff. In some instances, product and feature selection is made locally. This impacts the ability to deliver consistent policies and end user experiences. It also complicates support across the operation for staff responsible for troubleshooting and minimizing time to resolution and maintaining different SOPs and training documents.

Operators exploring options to gain operational efficiencies through modern service offerings may benefit from exploring how to extend their iDMZ beyond the “four walls” of the operation.

One deployment alternative for iDMZ is extending the architecture to leverage a hybrid-cloud model. A hybrid cloud iDMZ model can be deployed as a centralized model or repeated regionally, based on geographic presence and/or regulatory or compliance requirements. While migrating the entirety of the iDMZ and its capabilities to the cloud may not be an option, a hybrid cloud iDMZ architecture does offer operational benefits and mitigates previously raised challenges.

First, the hybrid cloud iDMZ can secure the operation, and mitigate risk and exposure. Similar to an on-prem iDMZ, multiple tools and applications should be leveraged to take a holistic approach for enforcing security. This can include:

◉ Services that support a secure and encrypted pipe between an operations site and a regional iDMZ

◉ Segmentation and possible options for multi-tenancy

◉ Visibility to monitor applications and flows traversing the industrial zone

The solution should also include tools for consistently configuring, deploying, enforcing policies, and managing assets.

In addition to providing a holistic security strategy, a hybrid cloud iDMZ offers the benefit of shared resources and assets, as opposed to entirely duplicating unique stand-alone iDMZ deployments per site. The regional based approach offers a more repeatable and consistent architecture, delivering consistent policies, as well as easing the operational overhead and complexity mentioned previously.

A hybrid cloud solution offers more flexibility to expand, and contract based on evolving requirements and demand. By leveraging public cloud services as part of the iDMZ architecture, operators have the ability to increase capabilities without physically maintaining hardware and space to house equipment. This approach affords the unique opportunity to foster tighter engagements with partners and ecosystem vendors, while leveraging cloud services to drive innovation, deeper operational insights and efficiencies. Adding tools like Thousand Eyes and App Dynamics, operators can verify adherence to application SLAs/SLOs, in accordance with operational requirements.

Finally, a hybrid cloud iDMZ aligns with the concept of the ROC (Regional Operations Center), which is top of mind for some industrial organizations, especially those with a global footprint. A ROC model seeks to leverage more automation and remote operations, thus reducing on-site headcount to mission essential resources, improving on-site safety and driving more operational efficiencies. With a regional based iDMZ deployment, the process of aggregating and presenting the status and data for operations within the region can become more streamlined and a regionally distributed model can facilitate compliance with local industry regulations, if applicable.

For more details on how to build a hybrid cloud iDMZ architecture and its benefits for securing industrial operations, we have just published a short white paper that you should read on the Hybrid Cloud Industrial DMZ. We’ll also be discussing this in a free webinar on September 20, 2022.

Source: cisco.com

Continue reading

Cisco DNA Center and Device configuration management

In my conversations with customers and partners, there are two topics that are different but somewhat related: compliance and device configuration management. In my latest blog, “Compliant or not? Cisco DNA Center will help you figure this out”, we discussed compliance capabilities in Cisco DNA Center 2.3.3. In this blog, I will address device configuration management.

Let me start by saying that DNA Center always has the latest device configuration in its internal databases. This has always been the case. The configuration of a device is first collected and stored when the device is added to the inventory, it’s then updated by periodic triggers as well as event-based triggers. Event-based triggers happen when there is a change in the configuration. DNA Center uses these up-to-date configurations for all its capabilities including, but not restricted to, assurance, device replacement, and compliance. Network administrators can also leverage these configurations so, in this blog, we will explore different ways to access them.

Visualize Configuration in Inventory

For certain device types, like switches, DNA Center has the option to show and export the full device configuration. This allows the network administrator to have quick visibility into the configuration. For security reasons, sensitive data is masked which means that we can’t directly use this device config to restore a device.

Figure 1: Configuration Visualization in Inventory: sensitive data is masked

Export the device configuration

Configuration archive is the DNA Center feature that allows network administrators to export raw configurations to an external server. Raw configurations are useful to restore a device for example.

Figure 2: Configuration Archive: exporting raw configurations to an external server

Device configuration backup can be scheduled with the desired recurrence and the configurations are sent to an external server. For each configuration backup, DNA Center creates a password-protected zip file. This zip file contains one directory per device and each directory contains three files: running-config, startup-config, and VLAN database.

Figure 3: Password-protected zip file

Figure 4: One directory per device containing running config, startup configs and VLAN DB

APIs to retrieve device configuration

Another way to access the clear text device configurations is via APIs. The API available in Cisco DNA Center allows to retrieve raw startup, running configs, and VLAN DB in the form of a zip file in a similar way as the configuration archive capability.

API details:

POST /network-device-archive/cleartext

Visualize Configuration Drifts

Arguably, I’m leaving the most interesting capability for last!

At the beginning of the blog, we mentioned that DNA Center stores the device configuration and updates the configurations periodically and upon changes. Every time there is a change in the configuration, DNA Center will store and timestamp this new configuration for a maximum of 50. We call these configurations config drifts. Moreover, DNA Center can show differences between these stored configurations to help the network administrator identify any changes. For out-of-band changes, Config Drift tool will also show the username of the person that made the change.

In the example below, we are comparing two configurations taken on September 2nd, 2022, one at 1:56pm and the other at 2:57pm. We can see in the latter, that a “description” command was removed from “interface GigabitEthernet 1/0/10”. Once we identify these changes in the running configuration, the network administrator can take specific actions to remediate the issue. For example, the device can be re-provisioned.

Figure 5: Config Drift

We can also identify and label a specific configuration that we deem “standard”. That way, it will be easier to compare the current running configuration with the selected labeled configuration.

In the example below, we will first select the preferred configuration and name it with the label of our choice, in this case, “TBRANCH-Std-Config“:

Figure 6: Label Config

Once we label our standard configuration, we can then compare it to the current configuration. In this example, the current running configuration is identified as “September 2nd at 3:10pm”. In this case, both running configuration and standard configurations match.

Figure 7: Comparing running-config to labeled config

Continue reading

WLAN/SSID Security Migration into 6GHz Networks

With the introduction of Wi-Fi 6E/6GHz, there is a huge increase in available RF space, multiplying the overall total capacity of any wireless network, and at the same time, removing sources of interference and noise. This increase in performance and quality of the wireless connections will be really exciting and bring multiple opportunities, but this will come with the price of new and better security requirements for our WLAN/SSID configuration migration.

The new standard did not leave security out of the picture and any new device supporting 6GHz, will be required to “only” support the following security standards while in the new band:

◉ WPA3: this enforces mandatory Protected Management Frames (PMF/802.11w)

◉ Opportunistic Key Encryption (OWE). This replaces the concept of “Open SSID”, and allows to have encryption across devices, without any authentication

◉ Simultaneous Authentication of Equals (SAE). This takes the role of PSK (also called “personal”) authentication methods but makes it resistant to offline password attacks, with improved cryptographic algorithms

There are as well provisions for more advanced encryption methods (WPA3 Enterprise-192), and several mandatory things that must “not be supported“, for example:  PMF disabled/optional, TKIP, WEP, etc.

What does this mean for 6GHz deployments?

Well… in the rare case of a greenfield 6GHz deployment, it would be just “awesome, we get new improved security standards by default”…

The problem is that almost deployments will not be greenfield.  You will have to support the coexistence of all current networks and devices with the new standard and migrate existing networks to include the new 6GHz access points and clients.

What is more: with few honorable exceptions, most of the current WLAN/SSIDs configured out there for 2.4 and 5, will “not” work over 6GHz radios, as they do not meet the new security requirements.

This means that your SSID supporting WPA2 Enterprise (802.1x), can’t be broadcasted directly in 6GHz… same for any existing Webauth or WPA2-PSK SSIDs. All of them will need to be changed to conform to the new standard. In order to ensure things can be done properly, this will need planning, and quite possibly, careful testing.

Changes also mean concerns about backward compatibility, and any older devices may not like or support the new security settings, so this is not just a matter of flipping a configuration switch and hoping it works.

The good thing is that there are different options on how to handle brownfield scenarios, with proper and natural coexistence of the new APs and clients supporting WPA3 and 6GHz, with older devices still stuck supporting WPA2 or older standards. Each one has its benefits and implementation costs, so it is important to plan properly.

Figure 1. Radio Policy and 6GHz support

Transition mode

Some people may come back with “But transition mode is available, we should be able to set this WLAN with WPA2/WPA3 transition and get it done”, unfortunately,  things are not so simple. This mode was created to introduce WPA3 into legacy bands, not to make it easy for 6GHz adoption.

WPA3 describes transition mode as a kind of hybrid WPA2/WPA3 scenario, with PMF set to optional, and the group key using legacy crypto, but this is not allowed in 6GHz, so we can’t just flip the existing WLAN from WPA2 to transition mode and get it done…it simply can’t be supported in the new band.

Transition mode is an excellent way to handle a migration into a more secure standard in the legacy band. Older devices can coexist on the same SSID with new devices supporting WPA3/PMF, allowing a smoother migration, but the price to pay is compatibility. Multiple clients may behave erratically, or simply, fail to connect to a transition mode SSID, even if what they support is still allowed, plus this alone can’t solve the 6GHz  security mandatory requirements.

One word of caution: There is a related feature called “Transition Disable”, which can be set in the WLAN Security tab, in the WPA Parameters area.

Figure 2. Transition Disable location

This setting tells the client, that once it has connected successfully to WPA3, it should migrate its SSID profile to support “only” WPA3, and not connect back to WPA2 if that is the only option available. On one side, this is good for security, as it will migrate all client devices to WPA3 only, as they join the transition mode WLAN, but if the network is composed of multiple physical locations, for example, some are set to WPA2, others to WPA3/WPA2 transition mode, this will cause the migrated clients to fail when moved to a location with WPA2 only.

This is a possible scenario for some large networks, with the same SSID covering different controllers/AP setups and with configurations not matching  100%.  The largest example would be Eduroam, which shares the same SSID name worldwide. Setting this could have serious issues for clients  moving across different network providers, so please use this with care, and only if you can ensure the same security setting is set properly across all network locations

So, what options do we have?

Option 1: Everybody Moves

This is the most radical solution. Here we move all SSIDs to WPA3, SAE, or OWE, with a single SSID across all bands. This means that all legacy security support will be removed across all SSIDs.

This is only feasible for the Greenfield scenario, or when we have absolute control of all clients’ device versions and configurations. It is highly probable that customers will never go this route.

Client support

◉ Apple IOS: on 15.1, it does support WPA3/PMF, and SAE, but it does not support OWE. SAE support is not compatible with 6GHz requirements

◉ Android: Supports WPA3/PMF/SAE since version 10

◉ Windows: supported in 11, but should work on version 10-2004

Cons

◉ There is a large list of compatibility issues regarding some of the requirements, and implementing this option will lead to compatibility issues as soon as any older device tries to connect

◉ Migrating the SSID profile on clients may be problematic, depending on operating systems. Several devices will use right away the higher security offerings, others will need to be adjusted

Pros

◉ No need for additional SSIDs

◉ Removes any older low-security SSIDs

Option 2: Tailored SSIDs

In this scenario,  the idea is to create new SSIDs, specifically focused on functionality, with support on each band as needed. New SSIDs would be created for 6GHz support, optionally broadcasted in other bands.

This maximizes backward compatibility, as it leaves anything existing  “untouched”.

For example, a company may have an existing SSID design as:

◉ Legacy SSID: mycompany, broadcasted in 5 GHz supporting WPA2 Enterprise

◉ Guest SSID: mycompanyGuest, supporting webauth in 2.4 and 5 GHz

◉ IoT: mycompanyIOT, with WPA2-PSK, for restricted sensor/telemetry devices in 2.4 GHz

What we would add:

◉ Wi-Fi 6 specific SSID: mycompanyNG, broadcasted on 5 and 6GHz, using WPA3 with 802.1x authentication and PMF

Cons

◉ A new SSID will need to be created and broadcasted

◉ Additional profile configuration across devices. Depending on client management being available, this can be a daunting task

◉ SSID names are a sensitive subject for customers. Selecting a new name may not be simple in some instances

Pros

◉ No impact on anything already existing

◉ You can have a gradual migration of devices supporting the new security standards (WPA3) to the new SSID, without having to do a risky forklift in the client profile configuration

◉ Fast roaming supported between bands for the same WLAN

Option 3:  Same SSID, two WLAN profiles, using transition mode

Keeping the same SSID across bands, touches your existing WLAN profile changing it to WPA3 transition mode and restricting it to 2.4 and 5GHz. Plus adds a new profile, just for 6GHz, with the required security settings.

Following on our previous example:

◉ Legacy SSID: mycompany, WLAN profile mycompany, broadcasted in 5 GHz. Modified now to supporting WPA2 Enterprise and WPA3 in transition mode

◉ Guest SSID: mycompanyGuest, supporting webauth in 2.4 GHz

◉ IoT: mycompanyIOT, with WPA2-PSK, for restricted sensor/telemetry devices in 2.4 GHz

What we would add:

◉ Wi-Fi 6 specific WLAN profile: same mycompany, SSID, with different profile name, mycompanyNG  broadcasted on 6GHz, using WPA3 with 802.1x authentication and PMF

Cons

◉ Several client vendors have issues handling WPA3 transition mode properly

◉ Clients may not like the same SSID with different security settings across bands.

◉ Roaming is not supported across WLANs. A client authenticated in 5 GHz, will have to do full authentication when moving into 6

Pros

◉ No new SSIDs on the client side to be managed

◉ Devices supporting WPA3 will connect in legacy bands with the higher security standard. This will help with security migration

◉ As we have the same SSID name across bands, clients will be able to fallback from 6 to 2.4/5, in case of any coverage problem

Option 4:  Same SSID, two WLAN profiles, no transition

This is basically a small variation of option 3.  The existing profile is left untouched, and we add a 6GHz specific WLAN profile:

◉ Legacy SSID: mycompany, WLAN profile mycompany, broadcasted in 5 GHz. WPA2-Enterprise

◉ Guest SSID: mycompanyGuest, supporting webauth in 2.4 GHz

◉ IoT: mycompanyIOT, with WPA2-PSK, for restricted sensor/telemetry devices in 2.4 GHz

What we would add:

◉ Wi-Fi 6 specific WLAN profile: same mycompany, SSID, with different profile name, mycompanyNG  broadcasted on 6GHz, using WPA3 with 802.1x authentication and PMF

Cons

◉ Clients may not like the same SSID with different security settings across bands. This is yet to be confirmed, so far, no issues reported in testing

◉ Roaming across WLANs is not supported. A client authenticated in 5 GHz, will have to do full authentication when moving into 6

◉ Legacy bands will be stuck on lower security protocols

Pros

◉ No new SSIDs to be managed on the client side

◉ As we have the same SSID name across bands, clients will be able to fallback from 6 to 2.4/5, in case of any coverage problem

◉ Avoids any client interoperability issues with transition mode

Too many options, but which is the best?

For most customers, option 4 (new WLAN profile, same name, new security), is what will be implemented most of the time, as it allows deployments, reducing most risks.

For customers that want better security, option 2 (specific SSID), or option 3 (change to transition mode, add new profile for 6), will be the best suited.

And for sure, don’t move WPA2 networks to WPA2/WPA3 transition mode, without validating with your existing clients, especially if there are any legacy or custom devices present.

Source: cisco.com

Continue reading

Cisco ACI Best Practices: Upgrade your Fabric with Confidence

Cisco first launched the Application Centric Infrastructure (ACI) in November of 2014. Since that launch, the solution has proven to be a tremendous success in the Data Center. I don’t say this to blow our own horn, but rather to make a point that in the past 8 years, Cisco ACI has been widely deployed by customers large and small (and every size in between) across any vertical or industry you can think of. Internally our engineering team has done a tremendous amount of work to bring new features, capabilities, and topologies at a very rapid pace. All of this while, fixing bugs and addressing security concerns as they are discovered.

The result of such a large install base and choice of software release is that over time we find every possible mix of hardware and software version, feature, and deployment type. The question I ask myself is this: “Are customers realizing the fullest potential and best outcomes with their investment in ACI?” In many cases, I can say yes. But there is still room for improvement. We see many customers on what I would consider older code. This not such a bad thing but it makes me wonder why. I have a few assumptions. Maybe upgrading ACI is seen as complex, or maybe it takes too long, or perhaps the confidence and knowledge in the process isn’t there yet (after all we don’t upgrade every day). I can sympathize. ACI fabrics are the foundation of all the important and business critical workloads that run our customers’ businesses. Upgrades should be approached with planning and care and should be designed for zero to near-zero disruption. Furthermore, there is a constant balance between feature velocity and code maturity such that there is never one approach that fits all customers.

If you are with me so far, I have some good news to share on a few fronts.

New Software Lifecycle and Cadence

One of the most asked questions we get is “What version of code do you recommend I should be running?” 

That question can sometimes make me sweat a little bit because every customer’s datacenter is unique and built to solve specific requirements and needs. Everyone’s configuration is different enough that there may not be a one-size fits all answer. As with anything in IT, it depends.

Imagine a range of customers where on one end you have a profile that cares more about features and capabilities. We have many of these types of customers, some of them quite large and sophisticated. They move fast and prefer to push the boundaries of what is possible because it tends to give them an edge in what they are trying to achieve. On the other end we have a customer profile that is mostly concerned with uptime and stability. This type is careful, and risk averse but with very good reason. Mission critical workloads want to avoid any kind of chance of interruption or inconsistency.

Internally, we’ve come up with a new approach that offers a choice to satisfy both types. With ACI version 6.0, we will introduce a new release cadence (see figure 1).

Figure 1: New ACI and NX-OS Release Cadence

The general idea is to provide clear version lifecycle visibility with consistent timing for when we add or enhance features versus when we are strictly identifying and fixing bugs.

Each major release (6.0, 6.1, 7.0 and beyond) will have a pre-defined lifetime of 4 years. This way everyone knows upfront where they may be in the cycle with a lot of time to plan for future upgrades when it makes sense to do so. Furthermore, within each major release, the first 12 months will be all about introducing or enhancing features. Our engineering teams publish point releases every 3-4 months on average. The result is that 6.0.1, 6.0.2 and 6.0.3 will all be feature releases. This is great for those customers who desire features most. Once we pass that year mark, we will move into a maintenance cycle where we no longer introduce features but focus solely on fixing bugs, enhancing stability and hardening security.

In parallel we are working on the next major release that follows the same pattern but staggered to release a year later. If you are a profile that desires features first, you can choose to move up to the next major release (from 6.0.x to 6.1.x) but if you are a customer who prioritizes code stability first and foremost, you can continue with the current release across the remainder of its lifetime. Customers can then upgrade years later when those newer major releases have moved into their respective maintenance cycle (and thus get features and stability as they do so).

Upgrade Best Practices

When the time comes to actually do an upgrade, it is best to plan accordingly and go into it with eyes-open for the best results. Over the years, Cisco has published many documents and technotes detailing the process. One of the things we’ve realized is that these documents were not all gathered in the same place online and making it hard for customers to have all the info they might need at their fingertips. In the last year, we’ve re-organized, updated and collected everything related to upgrades and made it available from one landing page.

Even better, we’ve created an online checklist that details each step in the process with links to more information about that step (see figure 2). This makes it a lot easier to plan, prepare and do the upgrade with minimal or even no downtime. Following this checklist is the upgrade best practice and we strongly encourage its use.

Figure 2: Cisco ACI Upgrade Checklist

Finally, to help add more color and share experiences, we’ve been delivering webinars to customers and partners about ACI upgrade best practices. We’ve posted the video recordings of such events in multiple places.

Useful Tools To Help You Upgrade

The last bit of good news on this topic is that we’ve released a few useful tools that can add more visibility, pre-checks and guidance. I’ll share details about three items here.

1. On our DC App Center Portal, we’ve included an app called the Pre-Upgrade Validator. This is a free app that you can install and run right on APIC. It offers an easy and visual way to run a pre-check of various aspects of your fabric against the version of code you are planning to upgrade to. While not exhaustive, it includes checks for faults and common recommended configurations (like nodes not in a VPC pair).

2. On Cisco’s Github repository for Datacenter we’ve published the ACI-Pre-Upgrade-Validation-Script. This is a free Python script that you can copy to your APIC and run from the CLI. Don’t worry if you are not familiar with Python, the process is extremely easy and well documented at the link above. This script is in the same spirit as the visual application from the DC App Center. However, the script runs a number of added checks and is more frequently updated. If you have your own Github account, you can even open feature requests for added checks that you want and our developers will consider them. Both the app and script are fully supported by Cisco. I prefer the script given it can do a bit more.

3. Nexus Dashboard Insights (see figure 3) – Firmware Update Analysis feature is one of those useful capabilities of Nexus Dashboard Insights specifically designed to address and care about the many operational details in your environment and where they intersect an upgrade. I’d say this is the most comprehensive tool and recommended if you have Nexus Dashboard Insights deployed in your environment. It goes a fair bit deeper than the other tools I mentioned because it leverages more of the correlation and machine learning that is at the core of the platform. It performs detailed checks before and after an upgrade, including a review of available versions with an eye on relevant bugs including links to bug details and release notes. It records the health, policy, and operational states of your fabric before the upgrade, and then runs an additional delta analysis after the upgrade to see if anything has changed or is not as expected. If something is amiss, Nexus Dashboard Insights will let you dig in and quickly learn about where, what, when, and even recommendations on how to correct things.

Figure 3: Firmware Update Analysis in Nexus Dashboard Insights

If you want to know more about applications like Nexus Dashboard Insights, this is a good place to start: https://www.cisco.com/go/nexusinsights

Final Thoughts

Upgrading your ACI Fabric has never been easier. You can approach an upgrade with intelligence, insight, and a clear plan. There is no reason not to upgrade to the most recent version you are comfortable with. You gain features, stability, security and ultimately realize the best return on your investment in Cisco ACI.

Source: cisco.com

Continue reading

Demonstrating Trust and Transparency in Mergers and Acquisitions

Demonstrating Trust and Transparency in Mergers and Acquisitions 

All good relationships are built on trust. Add in transparency, and the union becomes even more substantial. “Trust and transparency underpin everything we do,” says Button, “Cisco takes security, trust, and transparency very seriously, and it’s part of our team’s fabric.”

When Cisco acquires a company, the Security and Trust M&A team looks at not only what they can offer in the way of security but also what unique qualities the acquired company brings to Cisco. These qualities might be related to security, but they’re also found in the acquired company’s culture, technical knowledge, and processes.

In all acquisitions, the M&A team needs to move fast. In fact, the Cisco team is committed to pushing even faster as long as they never compromise on security. Around 2020, Button and his team began taking stock of how it does things. They evaluated everything from the ground up, willing to tease out what is working and toss out what isn’t.

The team is also on a trajectory of identifying how it can digitize and automate security.

“If we were going to do things differently, we needed to be bold about it,” says Mohammad Iqbal, information security architect in the Security and Trust M&A team. One of the changes Iqbal proposed to his colleagues is to ensure that an acquired company is integrated into Cisco’s critical security controls within three months after the acquisition deal closes.

Focus on Non-Integrated Risks

To successfully meet the three-month target, the M&A team works closely with the acquired company to identify and address all non-integrated risks (NIRs) that Cisco inherits from an acquisition and encompass:

◉ Visibility to get the acquired company integrated into the governance process; includes risk assessments and familiarity with all the players involved in the acquisition

◉ Vulnerability management to identify and remediate vulnerabilities. Where do the acquisition’s crown jewels reside? What does the external attack surface look like? Has it been patched?

◉ Security operations to determine such functions as identity, administrative access, multifactor authentication, and basic monitoring.

NIRs are a subset of eight security domains, or operating norms, that align with Cisco’s security and trust objectives and top priorities of the larger security community (Figure 1). The M&A team’s focus on NIRs steers the due diligence conversation away from identifying the acquisition’s security deficiencies and towards understanding the inherent risks associated with the acquisition and measuring the security liability.

“Acquisitions are coming in with these risks, and so we must address NIRs early when we’re signing non-disclosure agreements. In doing so, we help put these companies in a position to integrate successfully with all the security domains. And this integration should be done in the shortest time possible within a year of close,” Iqbal says.

Figure 1. Cisco’s Eight Security Domains

Building trust and being transparent early on is critical so the acquired company knows what’s expected of them and is ready to accomplish its three-month and first-year goals.

“I wish this type of conversation was offered to me when Cisco acquired Duo,” Button says. “Being on the Duo side of that deal, I would’ve been able to say with confidence, ‘OK, I get it. I know what’s expected of me. I know where to go. I know what I need to do with my team.’”

“We have a limited time window to make sure an acquisition company is heading down the right route. We want to get in there early and quickly and make it easy,” adds Button.

Time Is of the Essence

Reducing the manual intervention required by the acquired company is integral to helping the acquisition meet the three-month goal. Here’s where automation can play a significant role and the M&A team is looking toward innovation.

“We’re working on bringing in automated processes to lessen the burden on the acquired company,” says Iqbal. The M&A team realizes that much of the automation can be applied in instrumenting the security controls and associated APIs to help the team move beyond what they have already assessed at acquisition day 0 and gain the visibility they need to get the acquired company to its three-month goal. For example, they can automate getting the acquired company on Cisco’s vulnerability scans, using internal tools, or attaining administrative access privileges.

So, Iqbal, Button, and the rest of the team are working on automating processes—developing the appropriate architecture pipeline and workflows—that help acquired companies integrate critical security controls. While the ability to automate integration with security controls is not novel, the innovation that the M&A team brings to the table is the ability to position an acquired target to integrate with security controls in the most expedited way possible.

Automation in Discovery

As with due diligence, the M&A team strives to complete the discovery phase before the acquisition deal close. Here’s another step where digitization and automation can simplify and shorten processes. Take the acquisition company questionnaire, for instance.

“Instead of asking dozens of questions, we could give the company an audit script to run in their environment,” Iqbal says. “Then, all they have to do is give us the results.”

Also, the questionnaire can be dynamically rendered through a dashboard, improving the user experience, and shortening completion time. For example, the number of questions about containers could automatically retract if the acquired company uses Azure Kubernetes Service.

After the Close

Many teams within Cisco compete for an acquired company’s time before and after an acquisition deal closes. The acquired company is pulled in several different directions. That’s why the Security and Trust M&A team doesn’t stop looking for ways to digitize and automate security processes after the close—to continue to help make the acquired company’s transition more manageable.

“If we can make processes simple, people will use them and see the value in them within days, not weeks or quarters,” says Button.

“The majority of companies we acquire are smaller,” Button says. “They don’t have large security teams. We want them to tap our plethora of security experts. We want to enable an acquired company to apply Cisco’s ability to scale security at their company. Again, we want things to be simple for them.”

The M&A team helps facilitate simplicity by telling a consistent story (maintaining consistent messaging unique to the acquired company) to all the groups at Cisco involved in the acquisition, including M&A’s extended Security and Trust partners such as corporate security, IT, and supply chain. Because each group deals with different security aspects of the integration plan, it’s essential that everyone is on the same page and understands the changes, improvements, and benefits of the acquisition that are relevant to them. Maintaining a consistent message can go a long way toward reducing complexity.

It’s All About Balance

The human element can easily get overlooked throughout an acquisition’s myriad business, technical, and administrative facets. Balancing the human aspect with business goals and priorities is essential to Button and the entire Security and Trust M&A team. They want to bring the human connection to the table. In this way, trust and transparency are on their side.

“Emotions can run the gamut in an acquisition. Some people will be happy. Others will be scared. If you don’t make a human connection, you’ll lose so much value in the acquisition,” Button says. “You can lose people, skillsets, efforts. If we don’t make that human connection, then we lose that balance, and we won’t be off to a great start.”

One way the M&A team helps maintain that balance is by embracing the things that make the acquired company unique. “It’s vital to identify those things early on so we can protect and nurture them,” says Button.

He also wants to remind companies that they don’t have to be experts at everything asked of them during acquisition. “Cisco has been here for a while. We have entire teams within M&A that are dedicated to doing one thing. We can help acquired companies find out where they’re struggling. We can handle the things they don’t want to deal with.”

“M&A is complex, but complexity is off the chart when you talk about M&A and security. Our team won’t be successful if we can’t find a way to make things easier for the acquired company. They need to understand where they’re headed and why,” Button says. “It’s up to us to motivate them towards a successful outcome.”

Source: cisco.com

Continue reading