Managing the environmental impacts of European roadways and intersections

When I was growing up in Scotland, my grandmother would pass knowledge on to me in the form of proverbs. When I’m waiting at a red traffic signal I remember one of her many sayings “If it’s fur ye, it’ll nae gae past ye”, roughly translated as “if it’s for you, it won’t go past you.” No need to worry, you’re green time will come. At traffic signals everybody loves a green light because it means “go”. I believe that for the entire smart roadways movement, green should mean go, too. There is an important focus on being green. From a transport point of view, this means careful management of the unwanted side effects of the transport process, while maximizing the good things that we desire – safety, efficiency, and great customer experience. It is a challenge to go for green while also attaining the other goals. It’s not easy, but it is absolutely possible with the right approach.

“Road transport constitutes the highest proportion of overall transport emissions (in 2019 it emitted 72% of all domestic and international transport GhG).”

What it means to be green

First, let’s define what it means to be green from a roadway point of view. The figure below captures the process that we need to follow. We can be greener by understanding challenges, developing appropriate responses, and implementing solutions that support responses.

Green has particular relevance for urban traffic signal control as every driver likes green traffic lights to keep going. More important is the ability to manage journeys through the road network in a way that optimizes traffic flow as it varies over the course of the day. Ideally, advanced traffic management will exactly align the green signal time with the traffic flow on each approach.

Greenness for roadways

Let’s discuss an ideal, one-way journey as depicted in the figure below.

The pink line represents the planned or ideal journey, the red represents the actual journey. The nodes represent stage points in the journey. They could be timing points for a transit service, or modal interchanges for a traveler. They might also be major intersections along a limited access highway. For example, at point 2, the traveler might switch from local bus to commuter rail. You can see that at point 1, the journey is taking longer than planned. Time is made up between points 1 and 2, but lost again between points 3, 4 and 5.

There are two points that I would like to make here:

1. First, the planned or ideal journey must be optimized for greenness: minimum carbon footprint, fuel consumption, and other factors that affect greenness. These include choosing the best mode of transport for the prevailing condition, matching the journey’s purpose. It also includes managing those modes as effectively as possible, adapting to changes in the demand for transport and prevailing operating conditions. It is also essential to inform travelers about the choices they have for any journey, for any purpose, and at any time. These might be pre-planned, scheduled journeys, or spontaneous travel decisions. Mobility as a Service techniques can be used to inform the traveler, help them make a single reservation across the entire journey from origin to destination and support a single, convenient electronic payment for the travel services to be used.

2. The second point is that any deviation from the ideal or planned journey can be viewed as a “loss of greenness.” In this case, the cumulative journey time increase (the red areas) could be caused by congestion or delay, reducing the journey greenness. This comparison of an ideal to actual journey is a technique used in aviation but typically not in surface transportation. In order to attain green, it will be necessary to have sufficient data collection and analytics capability to plan the optimum journey and monitor deviation from ideal during the actual journey. It will also be necessary to have the degree of situational awareness and management capability to improve the actual journey in formative, near real time ways. It is interesting to note that taking this approach to defining and measuring greenness also enables other factors to be optimized including safety, efficiency, user experience, and equity. Equity is improved by operating cost reductions making transport more accessible to all by reducing travel costs. We must go green and use management tools to stay green, for every stage of every journey.

Achieving greenness

This is complicated and yes, as I said at the start, it is not easy, but it is entirely doable. It can be done by applying information and operational technologies such as those depicted in the figure below.

The operational technology is the part of the iceberg under water, unseen but irreplaceable. Information technology consists of various elements above the water, which deliver visible impacts but rely on the unseen operational technology. Together they support the range of customer facing applications that deliver greenness. Like the iceberg, I am focusing on just the tip of the greenness issue.

Technology can enable us to determine carbon impacts for different stages in the journey and all modes of transport. We can even look at the supply chains that deliver transport infrastructure and vehicles, ensuring that we optimize the bigger picture supporting circular economic approaches. Smart roadways and intersections are crucial elements in this due to the proportional impact that effective operations have on greenness. We can not only make our roadways greener, but also the entire transport system. From better intersection management to world-class high-speed highway operations, we have the tools available now to go green.

Green is for now

So why is it important for roadways to be greener now? We want to save the planet and reduce greenhouse gases (GhG)—bold political goals have been set. Transport contributes a significant amount of GhG, especially road transport, so even a relatively small improvement would be significant. If we are to achieve these bold goals within the required time, then it’s time to start planning and implementing. There are proven technology solutions that can be implemented off the shelf including advanced traffic management, electric cars and trucks, AI based decision support and advanced sensors. Robust, trusted OT networks can underpin the attainment of bold goals.

Grandma’s guide to greenness

In addition to her many sayings, my Grandmother would also give me sage advice. One piece of her advice was that to get what you want, there are two fundamental steps required. Step one is to decide what it is you want. Step two is to ask for it. We have obviously decided that we want greener roadways and transport. So now we have to ask for it by designing, specifying, and procuring it. It’s still not easy being green, but it is now easier than ever due to bold political action and capable technologies. Let’s go for green.

Source: cisco.com

Continue reading

Migrating to 6GHz

With more than 18 billion devices in use and 4.2 billion more to be shipping in 2022, the sheer size of existing Wi-Fi deployments worldwide is just mind-boggling. In view of the new Wi-Fi 6E and 6GHz adoption push, it is critical to evaluate what are the best ways to do a migration from existing Cisco on-prem legacy networks into the new world of 6GHz deployments.

For Cisco Enterprise customers, there are several aspects that need to be evaluated for any successful migration planning:

• Existing controller type:
• is it AireOS?
• Model? (Basically, can it  run 8.5 or 8.10?)
• is it IRCM capable (2504/wism2 can’t do mobility to 9800)
• Access point Inventory:
• Are there any 802.11n models still in use? (per example, 2600, 3600, 1520, 1600, etc)
• Are there any Wave1 APs? (last generation of IOS, per example 1700, 2700, 3700)
• Mesh deployments?
• PoE support:
• What is the maximum supported power standard? (802.3bt, 802.3at, etc)
• Any power budged constraints per port?
• Or APs are powered by power injectors?
• Current 5GHz TX power
• Is my network running on average at power level 3-4?
• or it is around 1-2?

6GHz adoption is only supported in the Catalyst 9800 IOS-XE controllers, running 17.7 or higher. This imposes some additional considerations either on controller type migration, or about legacy access points that may need to either be migrated, or supported through Inter Release Controller Mobility (IRCM) solutions

Legacy Access Points

Figure 1. Legacy APs

Over the years, it has always been possible to do co-existence of previous generations of access points with the newly introduced models, ensuring both smooth network upgrades and capacity expansion. Adding new APs is normally not an issue until we hit the scenario of inter-generation gaps.

If a network that for any reason is still running devices 2 generations away (for example, a 2602 AP), and now needs to include new 802.11ax models (for example 9130) or jump to the  9136/9166/9164  for 6GHz support, this will need more complex migration paths.

When there are multiple generation gaps, if the legacy controllers can support IRCM to the IOS-XE 9800,  it is perfectly possible to design a migration plan, without the need to do a “forklift” installation.  This will ensure very little pain to users, and keep the network running until everything is migrated to the new hardware and standards

In the following table, we can see a summary of software support ranges and migration options for most access points models from 11n generation models:

Model/Series	Last AireOS Support	IOS-XE support	IOS-XE AP equivalent	Migration Notes
700/700W Series	8.10	Not supported	9105	Migration through IRCM
1040	8.3	Not supported	9115	AP needs to be replaced
1260	8.3	Not supported	9115	AP needs to be replaced
1600	8.3	Not supported	9115	Either 8.5 IRCM, or Hardware replaced
1700	8.10	17.3	9115	Migration through IRCM
2700	8.10	17.3	9120	Migration through IRCM
3700	8.10	17.3	9130	Migration through IRCM
1810/1810W	8.10	Up to 17.3	9105	Hardware replaced or IRCM between IOS-XE versions
1830/1840/1850	8.10	Supported	9105	Directly supported
AP802/AP802H	8.5	Not Supported	ISR10xx	Migration through IRCM
2600	8.5	Not Supported	1920	Migration through IRCM
2800/3800/4800	8.10	Supported		Directly supported
1540	8.10	Supported		Directly supported
1550	8.5	Not supported		Migration through IRCM
1560	8.10	Supported		Directly supported
1570	8.10	Up to 17.3		Migration through IRCM

For a complete list, you can check the Cisco Wireless Solutions Software Compatibility Matrix, alternatively, you can run the Wireless Config Analyzer Express, to check your migration readiness

Figure 2. AP Migration Decision Flow

Legacy Controllers

Figure 3. Legacy Controller

Depending on the existing controller type, the migration may take different paths. Some scenarios will be simple, allowing a smooth transition. Others may need additional steps to successfully migrate into a Wi-Fi 6E network

What to expect:

◉ “Generation 1” controllers: 5508, 8510. They can support up to 8.5 AireOS version, which will allow mobility scenarios between them and new IOS-XE 9800 controllers (Inter-release Controller Mobility, IRCM support).  Also, they will support  both IOS and AP-COS access points, from 1700 to 3800 models (Wave1, Wave2 802.11ac )

◉ “Generation 2” controllers: 5520, 8540, 3504 . All of these can support up to 8.10 AireOS, also allowing IRCM scenarios with 9800. AP support will additionally include 802.11ax models, like the new Catalyst 9105, 9120, and 9130. etc.

◉ “Generation 1” controllers without IRCM: 2504, WiSM2, vWLC, 7510. No mobility is possible between them and IOS-XE, so additional steps with different migration scenarios are needed

Figure 4. Controller Migration Decision Flow

Migration Scenarios

In general, we should try to migrate “per RF blocks”, defining it as a roaming area or domain where clients can move normally between access points, before hitting idle timeout. Basically, move these RF blocks completely, into the new APs, and IOS-XE controllers. For example, either move a building or a complete floor into the new hardware and software.  We should avoid “salt & pepper” deployments, mixing APs on different controllers at the same time. Not because it is not supported, but because mobility will be more complex, and it may lead to issues sooner or later (just a problem prevention action)

For scenarios where it is impossible to break the RF environment into differentiated blocks (for example a very large building like an airport, or a fully open space office), we will have to either set up artificial boundaries based on roaming frequency and usage or do a forklift upgrade

Figure 5. Example of RF area/building migration

What happens if the AP model is not supported in any IRCM version?

This could be the scenario of a legacy controller, still working in 8.3, with some AP models that are not supported beyond that version. For example, the scenario of 20 APs of 2700 Series, and 10 APs of 1042 Series.

The 1040s are not supported in 8.5. In this case, the preferred option is to prioritize the replacement of those APs first, moving the impacted area into 9800 as the first step. Sometimes, customers have mixed models across a given building. For example, the mix of 2700 and 2600. In those scenarios, the best option is to consolidate models per supported version, moving all APs of a given type together, so they are contained in a specific RF space  in order to facilitate migration in blocks

Scenario 1: Legacy Controller supports IRCM

This will be the most common scenario, where we have either 8.5  (5508/8510) or 8.10 (5520/3504/8540) AireOS controller.  The migration picture will start with the creation of  IRCM setup between AireOS and 9800 controllers, then either replace APs in RF areas connecting them to the new controller, allowing mobility to act when a client needs to roam between legacy and new RF areas.

This method allows the smooth coexistence of both controllers, with RF areas migrated as needed, without any overnight switchover.

Things to keep in mind:

◉ If the controller is limited to 8.5 (5508, 8510), we will need a special IRCM version (8.5.182.104), to connect them to IOS-XE

◉ In general, it is best to split the RF network into different areas, configuring different RF group names between the legacy and IOS-XE controllers. This way each group can do the best calculations that their respective version allows. We should make sure that “Avoid Foreign AP Interference” is enabled on RRM/DCA configuration (it is by default)

◉ Always configure the primary/secondary controller name in access points. The new controllers will reject unsupported APs, but if any AP could work in both controller types, this will avoid APs joining the wrong one, or flip-flopping between them, until the migration is ready to proceed

Scenario 2: Legacy Controller not supporting IRCM

If the legacy network is running on a controller model WiSM2, 2504, 7510, vWLC, it is not possible to establish an IRCM connection between the old controller to the new 9800 handling the 6E APs. This limits significantly the options that are available, and it forces a more aggressive migration process

Migration alternatives:

◉ Keep the two networks separated, and migrate physical RF areas as new APs are added, replacing the old ones. No roaming is possible, and it is very important to keep client VLANs different between controllers, to avoid ARP proxy issues between both controllers. During this process, we must take care on preventing roaming events as client identity, address, etc, will be lost on the change between controller types.  For example, the ideal scenario is to move a complete building from one controller to the new one, doing a forklift AP replacement overnight.

◉ Avoid migrations “per floor”, as in most building types, it is normal to see clients roaming between APs on different floors

◉ Temporarily, replace the legacy controller with one that supports IRCM

Scenario 3: AP is supported up to 17.3 but not in later versions

This will happen when “Wave1” APs are still present, for example, 1700/2700/3700 AP models. For this type of migration, it is possible to move all APs into IOS-XE, with the 17.3 release, then add a secondary wlc to host the new Wi-Fi 6E APs, using 17.9, and establish an IRCM link between both controllers.

On this option, it is possible to do a graceful AP replacement from Wave1, into Wi-Fi 6E models, always trying to do the technology migration, per physical roaming RF area as described (per building, floor, etc). Once all APs are migrated, the 17.3 controllers can be decommissioned

In some instances, the customer may deploy a 9800-CL in 17.3 as a temporary controller to host the legacy APs

6GHz RF Coverage vs 5GHz. AP replacement scenarios

One common discussion point is: How different is going to be the cell coverage, in 6GHz, when compared to a 5GHz AP?

People will want to take a 5GHz AP and do a 1:1 replacement with a 6GHz supported AP, this may seem reasonable, but there are some aspects to consider:

◉ As WiFi-6E uses a higher frequency, the propagation characteristics are different, the signal drops slightly faster in 6 than in 5GHz. The difference should be around 2 dBm on measurements over the same distance. Material absorption will be different as well.

◉ 6GHz has different regulatory power constraints than 5GHz. Currently, most deployments will be using Low Power APs (for simplicity sake’s, let’s say 24dBm in FCC, 23 dBm in ETSI). This means that depending on the current network AP radio’s power levels,  using 6GHz may result in a slightly lower power output

Rule of thumb:

◉ If your power level average is around 3-4, it is possible to do a 1:1 AP replacement, and have a similar coverage level in 5 and 6 GHz

◉ If the power level is in 1-2, then you may need around 10 to 20% additional access points

The easiest way to know the average power level per site is to use WCAE tool and check the “Channel Stats 5GHz” tab. This will present a summary per channel, either at controller, or site tag level, of the average power levels (among other information).  For example, this is a network where migration to 6GHz may need additional access points:

Figure 6. Example of site with low 5GHz coverage

Versus this other one, where the deployment is running on low power, so fitting without issues into 6GHz requirements:

Figure 7. Example of site with good 5GHz coverage

If you use the latest version (0.9.11) of WCAE, you can also get a “6GHz predictive” view of how the power distribution, Nearby relationships, and RSSI for clients would look, if you replaced your current APs with 6GHz capable hardware. The tool will match ETSI or FCC regulatory requirements, adapting powers and differences as needed. This is useful to get a taste of how the network would look, doing a direct migration, without adding any APs.

Figure 8. 6GHz Predictive RRM modeling

For complex or demanding deployment scenarios, the recommendation will always be: do a site survey

Source: cisco.com

Continue reading

Scale security on the fly in Microsoft Azure Cloud with Cisco Secure Firewall

The release of Microsoft Azure Gateway Load Balancer is great news for customers, empowering them to simply and easily add Cisco Secure Firewall capabilities to their Azure cloud infrastructure. By combining Azure Gateway Load Balancer with Cisco Secure Firewall, organizations can quickly scale their firewall presence across their Azure cloud environment, providing protection for infrastructure and applications exactly where and when they need it.

With applications and resources hyper-distributed across hybrid-multicloud environments, organizations require agile security to protect their environment at each control point. This integration empowers organizations to dynamically insert Cisco’s security controls and threat defense capabilities in their Azure environment, removing the clunkiness of provisioning and deploying firewalls, as well as the need to rearchitect the network. Organizations can now enjoy highly available threat defense on the fly, protecting their infrastructure and applications from known and unknown threats.

Securing cloud infrastructure while reducing complexity

Combining Secure Firewall with Azure Gateway Load Balancer offers a significant reduction in operational complexity when securing cloud infrastructure. Azure Gateway Load Balancer provides bump-in-the-wire functionality ensuring Internet traffic to and from an Azure VM, such as an application server, is inspected by Secure Firewall without requiring any routing changes. It also offers a single entry and exit point at the firewall and allows organizations to maintain visibility of the source IP address. Complementing these features, organizations can take advantage of our new Cloud-delivered Firewall Management Center. It enables organizations to manage their firewall presence 100% through the cloud with the same look and feel as they’ve grown accustomed to with Firewall Management Center. With Cloud-delivered Firewall Management Center, organizations will achieve faster time-to-value with simplified firewall deployment and management.

Benefits of Cisco Secure Firewall with Azure Gateway Load Balancer

◉ Secure Firewall lowers cloud spend with Azure Autoscale support – Quickly and seamlessly scale virtual firewall instances up and down to meet demand.

◉ De-risk projects by removing the need to re-architect – Effortlessly insert Cisco Secure Firewall in existing network architecture without changes, providing win/win outcomes across NetOps, SecOps, DevOps, and application teams.

◉ Firewalling where and when you need it – Easily deploy and remove Secure Firewall and its associated security services, including IPS, application visibility and control, malware defense, and URL filtering as needed in the network path.

◉ Greater visibility for your applications – Simplify enablement of your intended infrastructure by eliminating the need for source and destination NAT. No additional configuration needed.

◉ Health monitoring – Ensure efficient routing with continuous health-checks that monitor your virtual firewall instances via Gateway Load Balancer.

◉ Included Cisco Talos® Threat Intelligence – Protect your organization from new and emerging threats with rapid and actionable threat intelligence updated hourly from one of the world’s largest commercial threat intelligence teams, Cisco Talos.

Use-cases
Inbound

Figure 1: Inbound traffic flow to Cisco Secure Firewall with Azure Gateway Load Balancer

Figure 2: Inbound traffic flow to a stand-alone server

Outbound

Figure 3: Internal server is behind a public load balancer. Flow is the same as outbound flow for an inbound connection.

Figure 4: Outbound flow where the internal server is a stand-alone server.

Azure Gateway Load Balancer support for Cisco Secure Firewall Threat Defense Virtual is available now. To learn more about how Cisco Secure Firewall drives security resilience across your hybrid-multicloud environment, see the additional resources below and reach out to your Cisco sales representative.

Source: cisco.com

Continue reading

Get Hands-on with the Meraki API in the DevNet Sandbox

One of the strongest components of the Meraki platform is the consistent and simplified operational management of the network. The modern API, as an extension to the cloud managed service, makes it amazingly simple to programmatically control and manage all aspects of your network. There are customers that fully automate the onboarding of devices via the Meraki portal using routine automation scripts. Or, front-end systems or operational teams with lookup tools that pull analytics or data from the API. Thus, greatly streamlining operational processes required to support an organization.

This blog will showcase some of the techniques that can be used and built upon to integrate the Meraki API programmatically. To do this we will use the DevNet always-on sandbox lab. With this we will only be making read (get) requests into the always-on sandbox. And to make this easy to use, we are going to use the Google Collaboratory environment, which allows you to use Google cloud to run these examples.

Explore the Meraki API using the DevNet Sandbox

To begin exploring the Meraki API using the DevNet Sandbox, I have created a Collaboratory on Google at the below link. To use this, you will need a few things,

1. A personal Gmail account. This will share a copy of the example that you can modify in drive. If you use your corporate account, it will only allow this if your corporation has drive access.

2. You will then access the link below and file/save a copy into drive, from which point a read only copy will become writable, and modifiable to you.

Here is the link:

https://colab.research.google.com/drive/15qs6TFn8gtsTM0PTUUbuubGLYwHJw8hV

The first thing we will do is save a copy of this read only sheet into your drive, which will make it read/write. From the file menu you can click “save a copy to drive”

Once this is done you can evaluate the sheet. Within this sheet there are text blocks, code blocks, and results blocks. The code blocks are fully modifiable, and represent code running in a real python environment located in the Google cloud. To execute the code within a block, you can click the play button to the left of the block. When you do this, any results will show up.

Where this becomes particularly interesting is when we pair this cloud based development environment with the DevNet always-on Meraki Sandbox. This is a functional Meraki instance sponsored and managed through the DevNet organization. For a list of all Sandboxes, you can evaluate devnetsandbox.cisco.com.

For our particular sandbox, we will be using the always-on sandbox. This is available at the below link, but should this link change, you can find it by selecting networking sandboxes from devnetsandbox.cisco.com. (or searching Meraki, or many other ways :)).

https://devnetsandbox.cisco.com/RM/Diagram/Index/a9487767-deef-4855-b3e3-880e7f39eadc?diagramType=Topology

Setting Variables

What we will do in the below code segments, is we set a few variables we can use further on in the code. This makes it so that you can take your real Meraki environment, and change a few URLS, and search for meaningful information in these variables (such as YOUR device, or YOUR network), and use the code to create tables and graphs that you can modify as you see fit.

After setting the variables, we do a very simple get request from Meraki, that we will do many times for different information throughout the sample on Colab.

We then print the results, which will show up in a text string of JSON data.

To translate this into real JSON we can use, we use the below command and then print it so we can see.

This is exceptionally useful as we have useful data formatted as JSON. Building upon this, we can use a library called Pandas which is well known in the data science and ML communities, and is essentially “Excel on Steroids for Python.” What becomes interesting is its native support for reading in our JSON, into a table.

Using the Pandas module

Below we load the Pandas module as the name pd, which we can reference. We then import the JSON, and print out a table with the columns we are interested in. What is elegant about this is the simplicity, we import the module, read in the JSON in a single intuitive command, and create a table with the headings we are interested in.

After doing a few more operations in the code, following through the colab sheet, we make a few more get requests, store as a few different tables, and do different things. (You can explore the sheet.) We search out the network in the organization that we referenced at the outset of this sheet, and we get the top talkers for this via doing a get on the URI and storing it as JSON. Then importing into Pandas (like below), and spitting out the table.

We now have a list of clients and their bandwidth usage. We can then very easily create graphs for usage. This can also all be done easily via a webapp for your network teams. We do this using the Pandas built-in graph capability, as well as an example of using Seaborn, which is used for data visualization.

This is just a high level of some of the capabilities that can be exposed easily via the Meraki API. The purpose of the colab sheet that was created, as well as the DevNet sandbox, is to enable you to be able to play with and evaluate the API. The examples in the colab sheet are intended to be functional code, and stepping stones that reduce the barrier to leveraging programmability to create meaningful results.

I hope this blog was helpful. It explored using the Meraki API via using the always-on DevNet Sandbox. When you have an always-on sandbox, creating, sharing, and reusing examples in Google Colaboratory is a natural fit.

Source: cisco.com

Continue reading

Quick automation wins with Cisco DNA Center

With the investment into today’s modern and agile networks, many IT organizations are searching for intelligent tools that can help simplify the complexity that comes with the advanced capabilities of today’s networks and keep up with the business demands. Topping off the complex challenges, many organizations are facing challenges on how to bridge the growing IT skill gap and automate various aspects of their network management.

In a recent Gartner article regarding the State of Network Automation, according to the article:

◉ 41% of network activities are less than 10% automated.

◉ 31% of network activities are 11% to 25% automated.

Essentially 72% of network activities are less than 25% automated. Separately, Gartner has also identified 4 IT personas (AIOps, NetOps, SecOps, and DevOps), stating that NetOps2.0 is the evolution of network operations towards automation.

Attributes of NetOps 2.0 include an Automation-first approach, embedded analytics, SecOps integrations, and Turn-key DevOps tools.  IT organizations that embrace this approach can achieve increased IT agility, Proactive network operations, and an increased level of collaboration between common silos in IT organizations. An additional outcome is minimized friction between the NetOps, SecOps, and DevOps personas.

When it comes to automation products, the Inventor’s paradox states, “It is easier to solve a more general problem that covers the specifics of the sought-after solution”.  Organizations who transitioning to AIOps, NetOps2.0, and automation platforms, are faced with common challenges and limitations such as:

◉ Automation products are often not bi-directional with network equipment

◉ Third-party products lack Cisco’s deep understanding of the network and platforms

◉ Lack of tight integration between the hardware and software platforms

◉ Lack of cross-domain visibility between the campus, data center, and the cloud

◉ Reliance on legacy SNMP protocol which provides limited visibility and control

◉ Limited AI capabilities due to lack of data quality and domain specialization

Out-of-the-box automation with Cisco DNA Center

While there are various barriers to network automation, there are some pragmatic methods by iterating on non-change and/or non-production automation activities, leading to some “quick automation wins.” Below are some “quick automation wins” examples available out of the box with Cisco DNA Center automation.

◉ Network Device Configuration Backup and archival of all network devices.

◉ Integration with ServiceNow, which automats auto-population of trouble tickets.

◉ Automated creation of network availability baselines and compliance reporting.

◉ Automated creation of user experience baselines and reporting.

◉ Maintenance mode to enable/disable monitoring during change windows.

◉ Automated network performance testing with MRE (Machine Reasoning Engine) and features such as Truetrace and path trace to automate and expedite troubleshooting.

◉ Automated packet capture for network anomalies.

◉ Redundant Link Monitoring.

◉ RMA Automation workflows.

◉ Automated creation of application health and reporting.

◉ Software Upgrade Cycle

Granular Automation Control

In looking at Cisco DNA Center’s automation suite, Cisco DNA Center not only provides automation features but also provides the granular control to enable workflows and actions from manual to AI-assisted to selectively autonomous change management. Let’s look at the three modalities of automation possible with Cisco DNA Center:

Manual (clickOps) is where many organizations are today; all administrative actions are performed by or initiated by an operator. Numerous automated workflows need manual initiation, but they still automate numerous repetitive steps such as SWIM for software updates. Additionally, some of these can be automated through templates and EEM (Embedded Event Manager) triggers.

Figure 1. Cisco DNA Center (SWIM) Software Image Management Cycle

AI-Assisted is where leveraging the depth of knowledge, streaming telemetry, and Cisco’s vast knowledge and experience in running networks; Cisco DNA Center can identify issues and use the MRE to suggest troubleshooting steps and possible remediation. MRE is a network automation engine that uses AI (artificial intelligence) and ML (machine learning) to automate complex network operation workflows. This feature encapsulates human knowledge and expertise into a fully automated inference engine to help you perform complex root cause analysis, detects issues and vulnerabilities, and either manually or automatically perform corrective actions.

Figure 2. Cisco DNA Center Compliance automation with configuration drift

Autonomous Change Management (ACM) provides for Cisco DNA Center to be enabled to perform and enforce automated actions on the network under predefined conditions and events. As today’s networks grow at incredible rates with new demands, manually managing all aspects of the network is no longer feasible for humans. Nor do most organizations have staff watching alerts every second of the day. The integration of AI/ML into the automation engine enables Cisco DNA Center to regularly tune the network based on predictions and models, which can greatly optimize the user experience and network performance.  Compare human intervention as the ax vs. AI-driven automation doing it with a scalpel.  This can be the difference between a system taking proactive measures vs. correcting an issue after it occurred.

Doing a left shift and taking automation to the next level, depending on the intents and architecture of the network, there are several highly automated deployment models, such as the Software-Defined Access (SDA), User Defined Networking (UDN), and AI-RRM, which are highly ACM deployments within the Cisco DNA Center solutions suite.

Focusing on automation outcomes and benefits

Focusing on outcomes, as organizations embark on network automation, there are various success metrics and business outcomes that can be tracked, such as:

Tangible Metrics	Intangibles
Faster moves adds and changes Consistent Configuration Quicker MTTR Reduction in network issues Improved security posture	Team Agility Ability to scale at speed Bridging the IT skill gap

Source: cisco.com

Continue reading

Cisco DevNet Associate DEVASC 200-901 Exam: Resources You Can Use to Prepare

Earning Cisco Certified DevNet Associate certification confirms your skills in developing and managing applications created on Cisco platforms. To obtain Cisco DevNet Associate certification, you pass one DEVASC 200-901 exam that includes the basics of software development and design for Cisco platforms.

Cisco 200-901 DEVASC is a 120-minute exam. This is the only exam you need to pass to earn the DevNet Associate, and the exam is available in English and Japanese. You should also know that you will have to make an account on the Pearson VUE platform to register for it and pay $300 as an exam fee.

Cisco DEVASC 200-901 Exam: Resources You Can Use to Prepare

Official Training Course

This is one of the most useful exam preparation options. Cisco official training course “Developing Applications and Automating Workflows using Cisco Platforms (DEVASC)” takes five days. You can interact with other exam-takers and the instructor in the Instructor-led training course, and this suggests that you can get explanations from the instructor and get an immediate response. This course is recommended for anyone who wants to pass the DEVASC 200-901 exam and become an in-demand professional.

Online Videos

There are plenty of videos available online for the Cisco DevNet Associate certification exam preparation. These videos incorporate thorough explanations of exam topics. But make sure you check the content before relying on them.

Cisco DEVASC 200-901 Practice Exam

Practice tests are of great help handy when one is preparing for a Cisco exam. Practice tests help you identify your strengths and weaknesses. Practice tests simulate Cisco 200-901 exam questions that familiarize you with the core exam topics. This can also boost your confidence. Nwexam is a leading provider of Cisco practice exams.

Also Read: How to Pass Cisco 200-901 DEVASC Exam Practice Test

Books and Study Guide

Books and study guides are essential because they provide essential information that other study resources may not provide. You can buy relevant study guides and books on the Cisco press store or from amazon.

Tip to Pass Cisco DevNet Associate DEVASC 200-901 Exam

Have the Right Study Resources

It will be of no benefit if you learn from the wrong study resources. Authentic and updated study resources like an online training course, study guides, and practice tests will enable you to achieve crucial exam skills and real-life mastery. But, it should be accessed from trusted platforms.

Familiarize Yourself with Cisco DEVASC 200-901 Exam Content

Before beginning your exam preparation, make sure that you have an idea of what the exam evaluates, the skills needed, and the exam objectives in detail. This will help you carry out your preparation in an organized way.

Practical Experience

Having practical experience will allow you to soak up important concepts in your exam prep. The Cisco DevNet Associate exam objectives need to be done practically to get real-life skills.

Do Active Revision

It is not always assured that you will memorize everything you have been learning, and revising is the perfect way to soak up what you have learned. A great tip for doing a quick revision is to take short notes while studying.

Effectively Manage your Time

The exam is 120 minutes long, and you are expected to answer 90-110 questions within this time. Time management is crucial to passing Cisco DEVASC 200-901 exam. Most exam-takers fail, not because they have not learned appropriately but because of poor time management. In your exam, take as little time as possible when answering Cisco 200-901 exam questions. Answer the easy questions first; only then come to the tough ones. That will save you time.

Don’t be Afraid of Failure

Fear is the greatest enemy of applicants. Fear of failing makes you nervous and anxious. Your wish to pass the exam should be driven by enthusiasm instead of fear. During your Cisco DevNet Associate DEVASC 200-901 exam, try to stay calm and believe in yourself. If you do not crack the exam on the first attempt, take it as a challenge to make you study harder and qualify to be the best.

Conclusion

It is amazing to strive to get a flying score in Cisco 200-901 certification exam, but don’t ignore that the score you receive decides what you will achieve. Moreover, keep in mind that this is not just about passing the exam; it’s also about acquiring the best professional skills and knowledge you will require to thrive in your career. So, give your preparation the dedication it deserves and make sure you become a sought-after professional by passing the Cisco DEVASC exam.

Continue reading

Showcasing Cisco’s Commitment to Openness: VXLAN BGP EVPN with OpenConfig

The world of data center networks is evolving at an ever-increasing pace. Businesses are being faced with the growing complexity of scaling data center fabrics, while also ensuring the isolation and security of customer data. Fundamental to this isolation of customer traffic is network virtualization, of which Cisco has been a constant innovator. Over the recent years, VXLAN with BGP EVPN has emerged as the de-facto industry standard for network virtualization.

For as long as networks and virtualized networks have existed, the manageability and observability of these fabrics, have been critical concerns for network operators.

Standardization across platforms and vendors is critical to enabling network operators to achieve these goals. SNMP and syslogs have been widely used to gather data, to monitor and manage network devices. However, SNMP lacks the ability to capture the fidelity of data that operators require. Syslogs are unstructured and while easily human readable, are not easily interpreted by automation and monitoring systems.

Besides being at the cutting edge of architecting network fabrics and network overlays, Cisco has also been an innovator in open and programmable networks. The open NX-OS philosophy began with the ability to run on-switch applications, natively in NX-OS or in the isolated Guestshell environment, later adding off-switch automation solutions such as Puppet and Ansible which have seen widespread adoption. More recently industry standard APIs, models, and transports such OpenConfig, NETCONF, RESTCONF, and gNMI have become a core part of the open NX-OS strategy.

These two areas that Cisco has long been an innovator in, namely network virtualization and open programmable interfaces, came together in the most recent enhancements to the OpenConfig models, which now support VXLAN EVPN and as part of our most recent NX-OS 10.3(1)F release. Cisco built these enhancements in conjunction with industry partners, to provide simplified monitoring and automation capabilities to our customers.

EVPN: A brief explainer

In the context of an EVPN overlay, an EVPN Instance (EVI) is a Virtual Private Network (VPN). With the Cisco NX-OS VLAN-based approach to EVPN, this results in a single broadcast domain per EVI, and with this VLAN-based approach, the tenant VLAN is mapped to a single EVI. With this 1:1 mapping, the single broadcast domain or tenant is represented by a VLAN or a VNI.  The VLAN/VNI is associated with an EVI which provides the most granular control for importing routes.

What is OpenConfig?

OpenConfig is an informal working group of vendors and network operators collaborating together, to define declarative model-driven solutions for the management, monitoring and operation of networking devices. A core tenant of OpenConfig is focused on defining vendor-agnostic YANG models based to deliver a programmatic interface to achieve these goals.

EVPN with OpenConfig

Within the existing OpenConfig network-instances model, an EVI and associated constructs are now part of the existing network-instance/fdb hierarchy. The enhancements Cisco contributed to the l2rib container consists of a new container within the parent Forwarding Database (FDB) container. The L2RIB has 2 primary containers, the MAC table and the MAC-IP table as shown in Figure 1.

The MAC table represents the operational state for MAC address information, pertaining to each domain of the L2RIB. This consists of stateful leaves such as the MAC address, VLAN, EVI, and L2-VNI for a locally significant broadcast domain as well as the next hop data, such as an interface, or sub-interface.

The second container within the new L2RIB is the MAC-IP table, which consists of remote MACs learned via the control plane. Like the MAC table, it has stateful leaves such as MAC address, VLAN, EVI, and L2-VNI, but in addition, it also contains an L3-VNI and host-IP for the MAC-IP entries as shown below. This L3-VNI is used solely in the context of inter-subnet routing.

In addition to these enhancements within the L2RIB, there are also additional enhancements within the L2VPN container of the BGP Address Family Indicator/ Subsequent Address Family Indicator (AFI/SAFI) network instance, which together provide deep visibility into the overall state and routing of a Cisco NX-OS BGP EVPN fabric.

Better Together: NX-OS with OpenConfig

Cisco is excited to announce new capabilities within its VXLAN BGP EVPN solution with contributions to an opensource and industry standard solution such as OpenConfig. Cisco has a long-standing focus on industry standards and openness in mind. Together, Cisco NX-OS tied with these OpenConfig enhancements, provide deep visibility into both the routing and forwarding of an NX-OS VXLAN fabric and the applications that the fabric supports. These innovations and expanded capabilities are just the first set of results based on our contributions to OpenConfig.

Source: cisco.com

Continue reading