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

CCNA Practice Test Will Help You With the Real Exam

If you want to propel your IT and networking career by taking the CCNA certification exam, you have come to the right place! This article will impart complete information on all the CCNA syllabus topics, exam details, tips, and how the CCNA practice test can help you get a flying score.

Cisco 200-301 Exam Overview

The Cisco 200-301 or CCNA exam incorporates what an applicant should know to become a skilled networking professional. Cisco 200-301 exam covers the following topics:

•  Network Fundamentals (20%)
• IP Services (10%)
• IP Connectivity (25%)
• Network Access (20%)
• Security Fundamentals (15%)
• Automation and Programmability (10%)

And mastering these topics will allow applicants to obtain the well-known CCNA certification. To focus on the fundamentals, the CCNA 200-301 exam will include 90-110 questions and needs to be finished in 120 minutes. But, the journey won’t begin until you pay the application fee - $300. After that, to help you cover what will be evaluated in this Cisco exam, the vendor provides one training course with a similar name, Implementing and Administering Cisco Solutions (CCNA), that’s completely practical and actual information-based.

CCNA is an entry-level certificate offered by Cisco, as a justification for your skill to excel in a practical networking field. Moreover, it concentrates on IT technologies and combines networking skills with technical expertise to ensure successful applicants are armed with all the essential skills in just about all domains of the digital world.

Top Tips to Crack CCNA 200-301 Exam Like a Pro

1. Know the Cisco 200-301 Exam Details In-Detail

A solid starting point for the CCNA 200-301 exam is knowing the exact CCNA syllabus topics. Indeed, you are never going to pass this exam on the first attempt if you don’t understand what it will include, how much time you will be given to finish the questions, and what task formats you will confront.

2. Build a Realistic Study Plan That You’ll Actually Stick To

A study plan is excellent, but it creates monotony, whereas creating a realistic study plan will be helpful. For the Cisco 200-301 exam, determine how much time you wish to spend on every objective, what resources you will utilize, and when you want to take the exam. Planning will also help you sidestep stress and keep you stimulated.

3. Use the CCNA Practice Test

It’s good if you wish to get a feeling of the actual exam environment before the scheduled exam date. This will help you familiarize yourself with the exam structure and boost your confidence. If you can’t deal with the Cisco 200-301 exam questions, you will inevitably know what to concentrate on to help you pass the CCNA exam on the first try. Hence, taking the CCNA practice test will be crucial to shaping your path by helping you endure an exacting 2-hour-long exam.

4. Become a Part of an Online Community and Forum

You can become a member of an online community where you can meet other exam-takers and professionals with whom you can exchange knowledge and exam tips and find explanations for your doubts. One such community is the CCNA Certification Community on the Cisco Learning Network. Here you can ask queries, exchange ideas and meet with other members studying for the CCNA 200-301 exam. It also contains links to articles that relate to CCNA prep and exams.

How CCNA Practice Test Can Help You Score Much Better in Your Cisco 200-301 Exam

Following are some of the prominent reasons behind the growing importance of CCNA practice tests-

1. Imparts Clarity of the CCNA 200-301 Exam Structure

Practicing CCNA practice tests will allow you to understand the structure of the Cisco 200-301 exam and enhance your odds of passing the exam and getting your desired score in the exam.

2. Analyze Your Weak Areas by Reviewing the Result of the CCNA Practice Test

The evaluation of the performance of your CCNA practice exam can give valuable insights into the areas you need to concentrate on well. Significantly, comprehend how much time you have dedicated to the correct answers. Find shorter ways to solve such questions in less time. This can boost your analytical skills and also give you more time to focus on questions that are tough for you.

3. CCNA Practice Test Works As a Revision of the Whole Syllabus

By performing the CCNA practice test, you can revise the whole CCNA syllabus. A CCNA practice test assesses your skills for the exam and knowledge of the resources you own. Regular practice of CCNA practice tests can strengthen the frequently asked pieces of information and techniques used, and your brain becomes better at recovering them every time. This can help you prepare well for the exam with focus and perseverance.

Also Read: Make Your Resume Competitive With CCNA 200–301 Certification

4. CCNA Practice Test Helps Overcome Exam Anxiety

Finally, any exam can yield a lot of stress, mainly if one isn’t prepared adequately. A CCNA practice test helps you mentally and psychologically ready for an exam and understand how it would feel when solving it.

You learn how to control your anxiety under pressure and concentrate on answering CCNA 200-301 exam questions without worrying about the result. If you score well in a CCNA practice test, it gives you confidence while acing the actual exam.

Conclusion

It’s not possible to think about a career in IT infrastructure and networking without cracking the Cisco 200-301 exam. And to become certified as well as confirm your expertise, you should take up appropriate training and CCNA practice tests. For that, follow the top tips mentioned in this article to pass this exam like a pro. Good Luck!!

Continue reading

How NSO 6.0 Delivers Up To 9x Faster Transaction Throughput

Two years ago we set out on a quest to tune Cisco Network Services Orchestrator (NSO) for massive deployments. The primary challenge was the transaction throughput since no one wants a network that is slow or non-responsive. Customers will shout before you know it “Make your code run faster” or “My system is hanging”.

Today we are happy to announce that we have a significant performance boost for you. I almost dare to say that NSO 6.0 is “The Perfected Sword.” The magic is within the NSO Release 6.0 and the reimagined Transaction Manager. When we started the project we knew that it was our best attribute that was our greatest enemy, as well as our biggest potential. We were challenged as we had to perfect something that made us who we are. Now we are proud to claim that you will get three (3) times faster transaction throughput by only upgrading SW, and up to nine (9) times faster if you engage in optimization. If you are new to NSO and don’t care about the history, you can stop reading now, and enjoy the new version!

For those of you who have been with us for a while, or maybe struggled to scale with NSO, I will add a few layers to the history. If you want to know even more and get hands-on, sign-up for our next Automation Developer Days, Nov 29-30 in New York!

Shaping NSO for Increasing Demand

With an ever-growing network demand, we knew we had to be radical. Future networks need to push through more transactions per second than ever before. Our attempts to help customers optimize their code inside the lock were not enough. We knew about the opportunities to increase the concurrency and performance if we can reduce the time we protect transactions (a.k.a code lock). It would simply let us use the processing power more efficiently.

Things we did in the protected phase.

 

◉ FASTMAP create-code. Can be more or less efficient.

◉ Validations are model-driven constructs such as must, when, leafref, etc. These can be time-consuming.

◉ Kicker evaluations can be more or less efficient

◉ Device communication is normally time-consuming.

A transaction in NSO 5.x and earlier

 

It was tough to realize, but the merits that make NSO so unique also can impact performance at scale. We cannot expect users to write perfect validation expressions just because we know how. We also understood that we could not achieve sufficient gain unless we challenge the NSO heritage and break the transaction integrity, just enough to release the power. That is what makes our transactions fail-safe and also prevents some level of parallelism.

Can we run without locks or can we make the lock shorter? We need to manage any code that runs unprotected without adding too much complexity that eats up the cycles on the other side.

The New Concurrency Model

We put a lot of research behind the new design and the parts that control concurrency. The Transaction Manager is the central piece of this project. It is a specific function outside the database (CDB) that contains all functionality necessary for e.g FASTMAP.

The Transaction Manager controls the concurrency in NSO.

 

We knew that we could do much more in parallel if we can apply “checking” instead of “locking”. We just need to verify that the create condition is still valid when we apply “commit”.  Service invocations, Validations, Rollback file creation and more could potentially run outside the lock if we find a way to detect interference. We went from a pessimistic view of the transaction to an optimistic view to optimize concurrency.

A transaction in NSO 6.0

Conflict detection is one way to verify the conditions at commit and the basis for our new programming paradigm. We basically compare the current transaction read-set to other completed transaction write-sets. If some transaction has changed what the current transaction read, then the current transaction must abort and the services restarted. In this way, we protect existing services from being rewritten. Pretty straightforward, right? Of course, if you do your part to ensure your code is conflict-free you will avoid service restarts and NSO can run full speed.

Another less surprising example is the Commit Queue Option which proved to be very useful for moving device communication outside the lock removing dependencies.

Unexpected Outcomes

The Transaction Manager is probably one of the more well-tested code sections in NSO for a reason. Changing the core architecture can of course be risky. When you start poking around you will have to roll up your sleeves and fix old bugs as you run into them. The upside can be equally motivating as unexpected gains materialize.

◉ Lockless dry-run is one of them. The dry-run transactions will never enter the critical section, not even in LSA. It affects most actions with the dry-run option as well as service check-sync, get-modification, and deep-check-sync.

◉ Improved device locking is another one that allows us to obsoletes the wait-for-device commit parameter. The devices are locked automatically before entering the critical section which simplifies both code and operations.

◉ Improvements backported to the NSO 5.x branch

    ◉ Improved commit queue error recovery

    ◉ Internal performance improvements in CDB

    ◉ Performance Improvement for kicker evaluation

Sometimes it Pays Off to Dare a Little More

Sometimes it is worth trying the more advanced path to reach a certain goal. When you know it works you can simplify and evaluate. Now we challenge you to upgrade to NSO 6.0 and optimize your SW for faster transaction throughput. To learn more I highly recommend the new Packet Pusher podcast that uncovers the new features in NSO 6.0. As the next step, come to Developer Days in New York in November if you want to know more about the details and how you can gain performance with NSO 6.0. You will dive deeper into this topic in hands-on coding sessions led by our experts. If you can’t come to New York or want to come prepared you can always check out the NSO YouTube Channel for the latest content.  We have two particular sessions on the new concurrency model from our previous event in Stockholm. One overview session explains what we have done and one session is a deep dive that focuses on the conflict detection algorithm.

Source: cisco.com

Continue reading

CML 2.4 Now Supports Horizontal Scale With Clustering

When will CML 2 support clustering?

This was the question we heard most when we released Cisco Modeling Labs (CML) 2.0 — and it was a great one, at that. So, we listened. CML 2.4 now offers a clustering feature for CML-Enterprise and CML-Higher Education licenses, which supports the scaling of a CML 2 deployment horizontally.

But what does that mean? And what exactly is clustering? Read on to learn about the benefits of Cisco Modeling Labs’ new clustering feature in CML 2.4, how clustering works, and what we have planned for the future.

CML clustering benefits

When CML is deployed in a cluster, a lab is no longer restricted to the resources of a single computer (the all-in-one controller). Instead, the lab can use resources from multiple servers combined into a single, large bundle of Cisco Modeling Labs infrastructure.

In CML 2.4, CML-Enterprise and CML-Higher Education customers who have migrated to a CML cluster deployment can leverage clustering to run larger labs with more (or larger) nodes. In other words, a CML instance can now support more users with all their labs. And when combining multiple computers and their resources into a single CML instance, users will still have the same seamless experience as before, with the User Interface (UI) remaining the same. There is no need to select what should run where. The CML controller handles it all behind the scenes, transparently!

How clustering works in CML v2.4 (and beyond)

A CML cluster consists of two types of computers:

◉ One controller: The server that hosts the controller code, the UI, the API, and the reference platform images

◉ One or more computes: Servers that run node Virtual Machines (VMs), for instance, the routers, switches, and other nodes that make up a lab. The controller controls these machines (of course), so users will not directly interact with them. Also, a separate Layer 2 network segment connects the controller and the computes. We chose the separate network approach for security (isolation) and performance reasons. No IP addressing or other services are required on this cluster network. Everything operates automatically and transparently through the machines participating in the cluster.

This intracluster network serves many purposes, most notably:

    ◉ serving all reference platform images, node definitions, and other files from the controller via NFS sharing to all computes of a cluster.

    ◉ transporting networking traffic in a simulated network (which spans multiple computes) on the cluster network between the computes or (in case of external connector traffic) to and from the controller.

    ◉ conducting low-level API calls from the controller to the computes to start/stop VMs, for example, and operating the individual compute.

Defining a controller or a compute during CML 2.4 cluster installation

During installation, and when multiple network interface cards (NICs) are present in the server, the initial setup script will ask the user to choose which role this server should take: “controller” or “compute.” Depending on the role, the person deploying the cluster will enter additional parameters.

For a controller, the important parameters are its hostname and the secret key, which computes will use to register with the controller. Therefore, when installing a compute, the hostname and key parameters serve to establish the cluster relationship with the controller.

Every compute that uses the same cluster network (and knows the controller’s name and secret) will then automatically register with that controller as part of the CML cluster.

CML 2.4 scalability limits and recommendations

We have tested clustering with a bare metal cluster of nine UCS systems, totaling over 3.5TB of memory and more than 630 vCPUs. On such a system, the largest single lab we ran (and support) is 320 nodes. This is an artificial limitation enforced by the maximum number of node licenses a system can hold. We currently support one CML cluster with up to eight computes.

Plans for future CML releases

While some limitations still exist in this release in terms of features and scalability, remember this is only Phase 1. This means the functionality is there, and future releases promise even more features, such as the:

◉ ability to de-register compute

◉ ability to put computes in maintenance mode.

◉ ability to migrate node VMs from one compute to another.

◉ central software upgrade and management of compute

Source: cisco.com

Continue reading