Security Is Essential (Especially in the Cloud)

In an era where cloud computing has become the backbone of enterprise IT infrastructure, we cannot overstate the significance of a robust security posture that evolves with emerging technologies.

Cisco recognizes the multifaceted nature of today’s cloud environments and has taken a step forward with three new certifications designed to empower IT professionals across the full lifecycle of multicloud ecosystems.

These groundbreaking certifications are created to address the three pillars of cloud mastery: connecting to the cloud, securing the cloud, and monitoring the cloud. In this blog, I’ll focus on the certification that involves securing the cloud.

Securing the cloud

The new Cisco Secure Cloud Access (SCAZT) Specialist Certification dives into the heart of cloud security. As threats become more sophisticated and regulatory demands become stricter, this certification underscores the importance of a security-first approach.

As Cisco’s first-ever Professional-level cloud security certification, this certification is aimed at network engineers, cloud administrators, security analysts, and other IT professionals. And it validates the skills necessary to secure cloud environments effectively.

While the SCAZT exam contains the basics of cloud architecture (you can find its concepts in most cloud deployments), the thing that makes this certification unique is it uses the Cisco equipment and portfolio that some infrastructures already have in their network to secure their cloud.

Plus, the certification is part of the cloud lifecycle—connecting, securing, and monitoring the infrastructure. Most companies cover a single component. But Cisco covers all three elements. So, when you are certified in the security aspect in conjunction with the other two cloud certifications, you can be assured you’re covering the whole cloud lifecycle.

CCNP Security certification alignment

This new cloud security certification is also part of the CCNP Security certification track. This means you can receive a standalone Specialist certification, or combine this cert with the Implementing and Operating Cisco Security Core Technologies (SCOR) exam to earn the CCNP Security certification, which also counts toward recertification and Continuing Education (CE) credits.

Inside the 300-740 SCAZT exam 

Cisco certification exam topics are designed to group topics logically. When you follow the domains and tasks during your studies, you’ll get a comprehensive understanding, plus it connects the chapters you need to study.

The SCAZT 300-740 exam covers cloud security architecture, user and device security, network and cloud security, application and data security, visibility and assurance, and threat response.

Cisco exam topics emphasize hands-on technical questions, theoretical concepts, and critical thinking, always from a job role perspective. The certification focuses primarily on the following protocols, architectures, technologies, and platforms:

Training from Cisco U.

Cisco U. has launched a new Learning Path that’s designed to match the SCAZT exam and provide you with the best possible experience. It requires around 48 hours to complete, eligible for 40 CE credits.

You can watch presentations about concepts, complete hands-on labs, and review designs and examples. At the end of each topic, an assessment is available to test your knowledge.

Cloud Security job roles

Since most applications and infrastructures are moving to the cloud, if you’re working in a role where cloud concepts are included (whether in an on-premises or hybrid environment), you’re going to need security in every shape and form.

Network security engineers will especially find this certification valuable because it focuses on protocols, architectures, technologies, and platforms relevant to their jobs.

Possible job roles where this certification applies are:

◉ Cloud Security Architect

◉ Cloud Security Engineer

◉ Cloud Security Advisor

◉ Cloud Solutions Architect

◉ Cloud Architect

◉ Cloud Associate

◉ Cloud Engineer

◉ Security Administrator

◉ Security Architect

◉ Security Consultant

◉ Security Engineer

◉ Security Manager

◉ Systems Architect

◉ Systems Engineer

◉ Network Security Engineer

◉ Security Project Manager

Source: cisco.com

Continue reading

Mastering CCNP Security 300-740 Exam: An In-Depth Look

In the ever-evolving field of network security, standing out as an IT professional requires not just skill, but validation of that skill. The CCNP Security 300-740 certification emerges as a beacon for those dedicated to mastering Cisco networks' security. This coveted credential is more than a certificate; it's a badge of honor that signifies your prowess in deploying and managing cutting-edge security measures in the cyber world.

Diving Deep into the CCNP Security 300-740 Exam

At the heart of the CCNP Security certification lies the 300-740 exam, a rigorous test that probes your knowledge across various pivotal security domains such as secure network access, content security, and navigating the complexities of cloud security. Crafted meticulously, the 300-740 SCAZT exam ensures that those who pass can shield network infrastructures against the threats of today and tomorrow.

300-740 SCAZT Exam Breakdown:

• Duration: 90 minutes

• Question Count: Between 55 to 65

• Passing Score: Typically falls between 750 and 850 out of 1000

• Format: A mix of multiple-choice and simulation-based questions

• Validity: 3 years before renewal is required

CCNP Security Exam Preparation Pathways

• Official Cisco Resources: Dive into the wealth of knowledge provided through Cisco's own training courses. These not only cover the theoretical aspects but also offer practical lab exercises.

• Comprehensive Study Guides: Bolster your preparation with detailed study materials that go in-depth into each 300-740 exam topic.

• Practice Makes Perfect: Regular practice exams are invaluable. They pinpoint areas needing improvement and familiarize you with the Cisco SCAZT exam's structure and pacing.

• Community Engagement: Connect with peers through forums and study groups. Sharing insights and experiences can provide unique perspectives and study tips.

Best Tips to 300-740 Triumph

• Know What's Expected: Thoroughly understanding the 300-740 SCAZT exam objectives can give you a clear roadmap of what to study.

• Strategic Study Plan: Allocate your study time wisely, ensuring each topic gets the attention it deserves, with regular reviews.

• Real-World Application: There's no substitute for hands-on experience. Create a lab environment to practice real-world security scenarios on Cisco networks.

• Stay Informed: The cybersecurity landscape is dynamic. Keep abreast of the latest trends and technologies that could be included in the CCNP Security exam.

Career Advancement Post-Certification

Earning the CCNP Security 300-740 certification can significantly propel your career forward, marking you as a seasoned professional ready to tackle complex security challenges. Career doors that may open include roles as a Network Security Engineer, Security Analyst, Cybersecurity Specialist, or Network Administrator with a security focus.

Benefits of Being CCNP Security Certified:

• Industry Credibility: CCNP Security certification is a gold standard in IT, highlighting your expertise in Cisco's security solutions.

• Career Growth: It paves the way for advanced roles, showcasing your dedication to professional growth and security mastery.

• Skill Enhancement: Preparing for the 300-740 SCAZT exam deepens your understanding of network security, from principles to best practices.

• Salary Upside: Certified professionals often enjoy higher salaries and better job prospects.

• Global Recognition: Cisco's certifications are acknowledged worldwide, opening international career opportunities.

Considering the Challenges:

• Investment Required: Achieving certification comes with its costs, including exam fees and study materials.

• Time Management: The extensive study required demands a significant time commitment.

• Keeping Pace with Technology: As security technologies evolve, so must your knowledge, necessitating continuous learning.

• Exam Rigor: The CCNP Security exam's challenging nature demands a solid grasp of complex concepts and hands-on experience.

• Specialization: While highly valuable for those in network security, it might not offer the same benefits for individuals in non-Cisco environments or different IT areas.

Conclusion

The journey towards obtaining the CCNP Security 300-740 certification requires dedication, consistent studying, and practical application. It is a path that not only enhances your professional life but also distinguishes you as an expert in the vital field of network security. By embracing the challenge and making the most of the resources available, you can unlock a new realm of career opportunities and personal growth in the IT security domain.

Continue reading

How Cisco’s SaaS Solutions on AWS Deliver Unbeatable Value to Customers and Partners

The cloud has become a vital tool for businesses of all sizes, providing flexibility, scalability, and cost-effectiveness that are necessary to compete in today’s fast-paced digital landscape. However, as more companies move their applications and data to the cloud, they face new challenges in terms of security, connectivity, observability, optimization. That’s where Cisco comes in.

“Cisco is meeting customers where they are by offering end-to-end solutions for their cloud journeys, including cloud security, connectivity, observability, and remote work.”

As a leading provider of  networking, cybersecurity and observability solutions, Cisco has become a trusted partner for businesses looking to navigate their cloud journeys. Cisco offers end-to-end solutions for customers’ cloud journeys, including cloud connectivity, cloud security, cloud observability, cloud optimization, and remote work.

Cisco is making it easier for customers and partners to take advantage of its solutions by offering them on AWS Marketplace. Cisco SaaS solutions on AWS provide greater flexibility for customers and partners, making procurement easier. With the AWS Marketplace channel program, CPPO (Channel Partner Private Offer), partners can sell more Cisco SaaS solutions on AWS to customers. Most of Cisco’s SaaS solutions run on AWS, providing customers with greater flexibility and convenience in terms of procurement, leveraging their EDP commitments, and accessing the robust ecosystem support provided by Cisco and AWS.

Cisco’s SaaS solutions on AWS cover a wide range of areas, including cloud security, connectivity, observability, and hybrid work solutions. Cisco SaaS solutions on AWS are designed to work seamlessly with AWS services, making it easier for customers and partners to integrate them into their existing cloud environments. For cloud security, Cisco offers zero trust, SSE, SASE, infrastructure protection, application security, and XDR solutions, which can help customers secure their cloud environments and protect their data from cyber threats.

In terms of cloud connectivity, Cisco offers SD-WAN and simplified cloud connectivity solutions that help customers connect their on-premises and cloud environments.

Additionally, Cisco’s cloud observability solutions offer full-stack observability that covers infrastructure, internet, applications, business, code-to-cloud, and cloud optimization. This helps customers gain better visibility into their cloud environments and optimize their cloud resources for cost and performance.

Lastly, Cisco’s end-to-end hybrid work solutions help customers support remote work and collaboration. This includes solutions for secure remote access, video conferencing, and team collaboration.

Cisco’s SaaS Key Solutions Use cases

The Cisco and AWS partnership offers numerous benefits for customers and partners who are looking to migrate to the cloud or optimize their existing cloud environments. One of the most significant advantages of this partnership is the ability to access Cisco’s SaaS solutions on the AWS Marketplace.

In conclusion, By offering its solutions on AWS, Cisco is making it easier for businesses to take advantage of the latest technologies and innovations and stay ahead of the curve in their respective industries. The Cisco and AWS partnership is a powerful combination that can help customers and partners optimize their cloud environments and achieve their business objectives. To learn more about the AWS and Cisco partnership, and how you can benefit from Cisco’s SaaS solutions on AWS, visit the AWS and Cisco partnership page, as well as Cisco’s solutions for AWS.

Source: cisco.com

Continue reading

Launch Your Cybersecurity Career with Cisco CyberOps Certifications | Part 1

Every day, organizations worldwide contend with increasing malicious activity by criminal organizations and nation-state sponsored threat actors. There is a tremendous demand for security professionals who are trained to defend against these malicious threats. These professionals are the backbone of effective security teams. 

When organizations build security teams to address sophisticated cyber threats, they typically begin by constructing a security operations center (SOC). Modern organizations rely on SOC teams to vigilantly monitor security systems, rapidly detect breaches, and quickly respond to and remediate security incidents. To succeed in these crucial tasks, SOCs are desperately seeking more qualified cybersecurity professionals.

Cisco CyberOps Certification Evolution

In 2016, Cisco introduced the Global Cybersecurity Scholarship program to help close this cybersecurity skills gap. Alongside an investment of $10 million in the program to increase the pool of talent with critical cybersecurity proficiency, Cisco also introduced a new CCNA CyberOps certification to prepare candidates to begin a career working with associate-level cybersecurity analysts within SOCs. At the time, candidates had to pass two exams (SECFND + SECOPS) to earn this valuable certification. 

In 2020, Cisco redesigned the certification requirements and introduced the one-exam CCNA certification. For example, to earn the CCNA CyberOps certification, candidates had to only pass the CBROPS exam. At the professional level, candidates still had to pass two exams: for CCNP CyberOps, those exams were and still are the CBRCOR core exam and the CBRFIR concentration exam. 

In 2022, with the release of the new Cisco U. digital learning experience, the SOC Tier 1 Analyst learning path was introduced. The Cisco U. digital learning experience is built around the learner and the SOC Tier 1 Analyst learning path is specifically designed to ready learners for the SOC environment. With targeted quick-start pre-skill assessments, modular learning that addressed various aspects of the SOC experience, advanced search to refresh skills and topics, and a focus on goal setting, Cisco U. is designed to work for everyone’s unique journey.   

Cisco SOC Tier 1 Analyst Learning Path 

The SOC Tier 1 analyst role is the entry-level position within the security operations center. The SOC Tier 1 analyst, or triage specialist, has sysadmin and scripting programming skills, as well as one or more relevant cybersecurity-related certifications, such as the Cisco Certified CyberOps Associate, Cisco Certified CyberOps Professional, or CCNA. To help grow the skills necessary to operate effectively as a SOC Tier 1 analyst, Cisco created the Security Operations Center (SOC) Tier 1 analyst Learning Path training. This learning path is a collection of courses designed to help learners master the concepts and tasks needed for the SOC Tier 1 analyst job role and functions as a roadmap, guiding learners and providing visibility into their mastery of necessary SOC analyst skills and concepts.  

The goal of Cisco’s SOC Tier 1 Analyst Learning Path training is to teach the fundamental skills required to begin a career working as an entry-level associate SOC analyst within a threat-centric security operations center.

The training explores common attack vectors, malicious activities, and patterns of suspicious behaviors typically encountered within a threat-centric security operation center. It includes videos, example scenarios, hands-on-labs, and knowledge assessments (review questions). As the student advances down the learning path, they will be exposed to the foundational concepts and practices behind a security operations center and will gain the tactical knowledge and skills that SOC teams require to effectively detect and respond to the growing numbers of cybersecurity threats.  

Note: The SOC Tier 1 Analyst Learning Path consists of the CBROPS course with some additional cyber security content, plus some CCNA Implementing and Administering Cisco Solutions 1.0 content. 

SOC Analyst Job Outlook 

According to the U.S. Bureau of Labor Statistics, employment of information security analysts is projected to grow 33 percent from 2020 to 2030, much faster than the average for all occupations.   

Cisco CyberOps certifications are designed to satisfy the actual needs of SOC teams. CCNA and CCNP certifications prepare individuals to pursue a career working as an analyst in the SOC and the different levels of certification are intended to develop the skills necessary for advancement.  Below is a recent Cisco job posting for a SOC Cyber Security Analyst opening with the job position overview and responsibilities. Successfully completing the Cisco CCNA/CCNP Cyber Ops certifications fulfills many of the job requirements.

Source: cisco.com

Continue reading

Be on Guard This Spooking Spanning Tree Season

It’s Halloween — a time for too much candy, scary movies, kids in fun costumes, and lots of tricks and treats. As I thought about what to write for my blog this month, I quickly went to one of the scariest things for every network engineer: SPANNING TREE!!!! That’s right… can anything else bring the same level of dread and cold sweats as the potential for a bridging loop?!

Fear not. With a bit of good practical design and configuration practices, spanning tree doesn’t have to be scary. However, even the best engineers (or moderately decent ones like myself) can forget a best practice or two. Let me set the spooky scene for you…

It was a dark and stormy night…

The following anecdote took place about three or four years ago when I was part of the DevNet Sandbox team. We had recently stood up a new data center for hosting labs, and I had returned home from California after spending several weeks onsite, standing up the network and systems at the data center. I was feeling quite good about how well things had gone. Particularly, the speed and efficiency we were able to bring things online, thanks to a heavy amount of automation and programmability. In retrospect, I should have known something was going to go wrong…

I think the first sign there might be a problem in the network was when I noticed my remote connection into the new location started to get really laggy. I even got disconnected from some servers. It would clear up fairly quickly. But when the issues repeated several times, I started to wonder what might be the cause.

I checked other monitoring systems. Intermittent network issues had recently started showing up; slow response from systems, occasional disconnects that would clear up fairly quickly, that sort of thing. Nothing overly drastic, but they certainly were symptoms that indicated something might not be perfectly healthy in the network. I began to poke around a bit more. Eventually, I stumbled across a few things that pointed to a possible issue somewhere in the layer 2 parts of the network.

It was quite a while ago, so the details are a little fuzzy. I think I was on one of the top of rack Nexus 9000 switches in a hardware hosting rack when syslog messages hit the terminal about MAC flapping occurring. Now, MACs will move around a network occasionally. However, a flapping MAC address happens when a switch sees it changing back and forth between two ports. This is not normal. It often points to a network loop — something spanning tree is supposed to prevent from occurring.

Here is an example syslog message related to MAC Flapping:

*Apr 5 18:17:43.242 GMT: %SW_MATM-4-MACFLAP_NOTIF: Host d8e6.a5cd.3f41 in vlan 61 is flapping between port Ethernet1/23 and port Ethernet1/24

After a bit more troubleshooting, I also noticed that the network was reconverging spanning tree, changing the root bridge over and over again. This was definitely a problem. Even “rapid” spanning tree convergence is noticeable to network users who find themselves waiting for a port to transition to forwarding after ports change state.

Enough of the trick already, Hank… where’s the treat?

Long story short, the root of the problem (pun TOTALLY intended) was a new physical switch that was being added to the network for one of the hardware labs we were setting up.

The new switch hadn’t been fully configured for its new role yet, and the upstream switches it was connected to already had the ports enabled in preparation for the new lab gear being added. The lab topology had multiple ports connected between this new switch and the data center fabric for different purposes and networks, but none of the final configuration had been applied yet. There were actually some remnants of old configuration applied to the switch, which resulted in the bridging loop and MACFLAP log messages.

Furthermore, this switch had previously served as the spanning tree root in a previous network and had a lower (i.e., better) priority than the actual spanning-tree root in our data center. Between connections being made/removed, ports getting errdisabled for different reasons, and other instabilities, the root was bouncing between this new switch and the main distribution switches in the data center every couple of minutes.

I was able to quickly stop the problems from occurring by shutting down the ports connected to this new switch until it was correctly configured and ready to be made an active part of the network. So, problem solved… kinda.  

The bigger problem was that I had overlooked the critical spanning tree design and best practices for the configuration step in bringing the new data center network up and online. Had I remembered my fundamentals, this problem wouldn’t have happened: The network would have automatically blocked ports that were behaving in unexpected ways.

You are NOT root: Preventing unexpected root bridges with root guard

Consider this very simple triangle of switches as a quick review of the importance of the root bridge in a spanning-tree network. 

Switches connected together with layer 2 links use BPDUs (bridge protocol data units) to learn about each other and determine where the “root” of the spanning tree will be placed. The switch that has the best (i.e., lowest) priority becomes root. With the root bridge identified, switches begin the process of breaking loops in the network by blocking ports that spanning tree identifies as having the worst priority on redundant links.

A full discussion on the spanning-tree process for building the tree is out of scope for this blog post. It is a very important topic for network engineers to understand, so I might return to spanning tree in future blog posts. If you’d like to dive deeper into the topic now, check out our CCNA and ENCOR courses.

The process of electing the root bridge and converging on a loop-free network can take tens of seconds to even a minute (or more) in large networks, depending on which version of spanning tree is used and how well the network is designed. During the process of convergence, the network prevents bridging loops by defaulting to blocking traffic on ports. This will result in significant disruption to any users and applications that are actively using the network. Remember in my example above, how my network access had gotten “laggy” and my connections had even become disconnected? As long as the root bridge remains stable and does NOT change, adding a new switch to a network is a non-disruptive activity.

So, how does a network engineer prevent the root bridge from changing in the network? I’m glad you asked.

Identifying the root bridge for the network

The first step is to look at the network design and identify which switch makes the most logical sense to be the root, explicitly configuring it to have the best (i.e., lowest) priority. Here, I configure my root switch to run rapid per-vlan spanning tree (rapid-pvst) and set the priority to 16384.

root#show run | sec spanning

spanning-tree mode rapid-pvst

spanning-tree extend system-id

spanning-tree vlan 1-4094 priority 16384

root#show span

VLAN0001

  Spanning tree enabled protocol rstp

  Root ID    Priority    16385

             Address     5254.000e.dde8

             This bridge is the root

             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    16385  (priority 16384 sys-id-ext 1)

             Address     5254.000e.dde8

             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------

Gi0/1               Desg FWD 4         128.2    P2p 

Gi0/2               Desg FWD 4         128.3    P2p 

Gi0/3               Desg FWD 4         128.4    P2p 

Note: With “per-vlan spanning-tree” every VLAN will have its own spanning-tree constructed. The priority of each bridge is the configured priority plus the VLAN number. So for VLAN 1, the priority is 16384+1 or 16385.

If we look at the spanning-tree state on one of the other switches in the network, we can confirm the root bridge and the creation of a loop-free network.

switch-1#show span

VLAN0001

  Spanning tree enabled protocol rstp

  Root ID    Priority    16385

             Address     5254.000e.dde8

             Cost        4

             Port        2 (GigabitEthernet0/1)

             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)

             Address     5254.0017.ae37

             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------

Gi0/1               Root FWD 4         128.2    P2p 

Gi0/2               Desg FWD 4         128.3    P2p 

Gi0/3               Altn BLK 4         128.4    P2p 

switch-1#show cdp neighbors gigabitEthernet 0/1

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID

root             Gig 0/1           146             R S I            Gig 0/1

If you compare the address of the root bridge shown on switch-1 to the output above from root, you will see that the Address and Priority for the root bridge match. Also, notice that interface G0/1 has the role of “Root” — this is the interface on the switch that has the best path back to the root bridge. And as the output from CDP shows, it is actually directly connected to the root.

Stopping a new root on the block… err, network

Identifying an intended root bridge for your network is great, but it doesn’t prevent a newly added switch from causing trouble.

Consider back to my example from my anecdote where a new switch was being added to the network that had previously been configured as the root in another network. While it could be argued that it is best practice and important to clear old configuration from a switch before adding it to the network, the reality is… things like this happen. It is important to engineer a network to handle events like this.

First, let’s see what happens to the spanning-tree network when bad-root is cabled into the network without any extra configuration protecting the spanning-tree network.

switch-1#show span

VLAN0001

  Spanning tree enabled protocol rstp

  Root ID    Priority    4097

             Address     5254.001e.82a2

             Cost        4

             Port        1 (GigabitEthernet0/0)

             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)

             Address     5254.0017.ae37

             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------

Gi0/0               Root FWD 4         128.1    P2p 

Gi0/1               Desg FWD 4         128.2    P2p 

Gi0/2               Desg FWD 4         128.3    P2p 

Gi0/3               Altn BLK 4         128.4    P2p 

switch-1#show cdp neighbors gigabitEthernet 0/0

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID

bad-root         Gig 0/0           154             R S I            Gig 0/1

Total cdp entries displayed : 1

Notice how the address and priority for the root bridge have changed, and that port Gi0/0 is now the “Root” port for switch-1. This is definitely not what we would want to happen if a bad-root were connected to the network.

Bringing out the Guard… root guard, that is

We can leverage root guard to prevent this from happening. Root guard is one of the “optional spanning-tree features” that really shouldn’t be considered “optional” in most network designs.

As a network engineer, you should be able to look at your network and know which ports “should be” the root port on each switch. Then consider the redundancy that you’ve built into the network and identify which port should become the root port if the primary port were to have problems. Every other port on each switch should never become the root port. Those are the ports that should be configured with root guard.

Note: The root bridge in a network has NO root ports as it is the root of the tree. Therefore ALL PORTS of the root bridge should have root guard enabled.

Now we’ll go ahead and enable root guard on interface Gig0/0 on both switch-1 and switch-2.

switch-1(config)#interface gigabitEthernet 0/0

switch-1(config-if)#spanning-tree guard root 

*Oct 13 15:06:28.893: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port GigabitEthernet0/0.

*Oct 13 15:06:28.909: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port GigabitEthernet0/0 on VLAN0001. 

And look at that. As soon as it is enabled, we see syslog messages indicating that root guard has begun blocking the port. If we check the status of spanning tree on switch-1 we can verify that the root of the spanning tree has returned to the correct root switch.

switch-1#show span

VLAN0001

  Spanning tree enabled protocol rstp

  Root ID    Priority    16385

             Address     5254.000e.dde8

             Cost        4

             Port        2 (GigabitEthernet0/1)

             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)

             Address     5254.0017.ae37

             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------

Gi0/0               Desg BKN*4         128.1    P2p *ROOT_Inc 

Gi0/1               Root FWD 4         128.2    P2p 

Gi0/2               Desg LRN 4         128.3    P2p 

Gi0/3               Altn BLK 4         128.4    P2p  

There’s one other command that is handy to know when troubleshooting spanning-tree ports that aren’t behaving as expected:

switch-1#show spanning-tree inconsistentports 

Name                 Interface                Inconsistency

-------------------- ------------------------ ------------------

VLAN0001             GigabitEthernet0/0       Root Inconsistent

Number of inconsistent ports (segments) in the system : 1  

Take the scare out of spooky spanning tree with knowledge

Hopefully, this post helps to lower your heart rate a little the next time you think about making changes to the network that might impact your spanning-tree network. But I also hope it shows you, as a network engineer, the importance of recalling the fundamental skills and knowledge you have learned as you move onward to more specialized areas of networking. I was definitely kicking myself when I realized that I had completely overlooked ensuring that our spanning-tree network was well-designed and protected from unexpected or unintended changes.

While no one wants to have a network outage or even a minor disruption, they will happen. What is important, is that we learn from them. And we become better network engineers for them.

Do you have a spooky network ghost story from your own work as a network engineer? Ever had a scary encounter with a network outage or problem that helped you learn a lesson you’ll never forget? Share them in the comments. Trick or treat!

Source: cisco.com

Continue reading

How Cisco DNA Assurance Proves It’s ‘Not a Network Issue’

When something in your house breaks, it’s your problem. When something in your network breaks, it’s everyone’s problem. At least, that’s how it can feel when the sudden influx of support tickets, angry phone calls, and so on start rolling in. They quickly remind you that those numbers behind the traffic visualizations are more than numbers alone. They represent individuals. That includes individuals who don’t notice how the infrastructure supports them until suddenly… it’s not.

The adage that “time is money” applies here, and maybe better than anywhere else. Because when users on the network cannot do what they came to do, the value of their halted actions can add up quickly. That means reaction can’t be the first strategy for preserving a network. Instead, proactive measures that prevent problems (ha, alliteration) become first-order priorities.

That’s where Cisco DNA Center and Assurance comes in, and along with it, Leveraging Cisco Intent-Based Networking DNA Assurance (DNAAS) v2.0, the DNAAS course.

Let’s Start with Intent

This will come as no surprise to anyone, but networks are built for a purpose. From a top-down perspective, the network provides the infrastructure necessary to support business intent. Cisco DNA Center allows network admins and operators to make sure that the business intent is translated into network design and functionality. This ensures that the network is actually accomplishing what is needed. Cisco DNA Center has a load of tools, configs, and templates to make the network functional.

What is Cisco DNA Assurance?

Cisco DNA Assurance is the tool that keeps the network live. With it, we can use analytics, machine learning, and AI to understand the health of the intent-based network. DNA Assurance can identify problems before they manifest into critical issues. DNA Assurance allows us to gauge the overall health of the network across clients, devices, and applications and establish an idea of overall health. From there, we can troubleshoot and identify consistent issues compared to the baseline health of the network — before those issues have a significant impact. We don’t have to wait for an outage to act. (Or react.)

We’re no longer stuck in this red-light or green-light situation, where the network is either working or it’s not. When the light goes from green to yellow, we can start saying, “Hey, why is that happening? Let’s get to the root cause and fix it.”

Obviously, this was all-important before the big shift to hybrid work environments, but it’s even more critical now. When you have a problem, you can’t just walk down the hall to the IT guy, you’re sort of stranded on an island, hoping someone else can figure out what’s wrong. And on the other hand, when you’re the person tasked with fixing those problems, you want to know what’s going on as quickly as possible.

One customer I worked with installed Cisco DNA Assurance to ‘prove the innocence of the network.’ He felt that being able to quickly identify the network problem, especially if it was not necessarily a network issue, helped to get fixes done more quickly and efficiently. DNA Assurance helped to rule out the network or ‘prove it was innocent’ and allow him to narrow his troubleshooting focus.

Another benefit of DNA Assurance is that it’s built on Cisco’s expertise. 30+ years of experience with troubleshooting networks and devices have gone into developing Assurance. Its technology doesn’t just give you an overview of the network, it lets you know where things are going wrong and helps you discover solutions.

About the DNAAS course

Leveraging Cisco Intent-Based Networking DNA Assurance (DNAAS) v2.0 is the technology training course we developed to teach users about Cisco DNA Assurance. The course is designed to give a clear understanding of what DNA Assurance can do and to build a deep knowledge of the capabilities of the technology. It’s meant to give new users a firm handle on the technology while increasing the expertise of existing users and empowering them to further optimize their implementation of DNA Assurance.

One of the things we wanted to do was highlight some of the areas that users may not have touched on before. We give them a chance to experience those things and potentially roll them into tangible solutions on their own network. It’s all meant to be immediately actionable. Users can take this course and instantly turn back around and do something with the knowledge.

Labs are one of the ways that we’ve focused on bringing more of the experience to users who are taking the course. New users are going to interact with a real DNA Center instance, and experienced users are going to have the chance to see new configurations. We build out the fundamental skills necessary to use DNA Assurance, rather than focusing on strict use cases.

We treated it like learning to drive a car. We could teach you all the specifics about one highly specialized vehicle, or we could give you the foundational skills necessary to drive anything and allow you to work towards your specific needs.

Overall, students are going to expand their practical knowledge of DNA Assurance and gain actionable skills they can immediately use. DNAAS is an excellent entry into the technology for new users and an equally excellent learning opportunity for experienced users. It helps build important skills that help users to get the most out of the technology and keep their networks running smoothly.

Source: cisco.com

Continue reading

ChatOps: How to Build Your First Webex Bot

In this post, you’ll learn how to create a Webex bot, register a Webhook in Webex, and configure your bot to listen to Webhook – all with plenty of code examples. Check back for more as we build new use cases that leverage different aspects of automation using chat-driven interfaces.

In the DevOps world, we’re always looking for new ways to drive automation around communication. When we deploy new code, scale our deployments, or manage our feature flags – we want our teams to know about it. The Webex API makes it easy to build announcement flows triggered by successful events in our infrastructure. However, if we can trigger those events from Webex as well, then we’ve entered the world of ChatOps.

More Info: 300-835: Automating Cisco Collaboration Solutions (CLAUTO)

ChatOps is the use of chat clients like Webex Teams, chatbots, and real-time communication tools to facilitate how software development and operation tasks are communicated and executed. Using Webex APIs, we can build bots that allow us to enter commands that manage our infrastructure, trigger approval workflows, deploy code, and much more.

Security Disclaimer

Security is a top concern here at Cisco. In normal application development, security should always be built into the initial steps of getting code up and running. Today, we’re going to keep it simple and focus on the basics. Then, we’ll cover how to authenticate and authorize Webhook requests. We’ll hold off on security until the next blog post in our ChatOps series, once we’ve proven an end-to-end connection. 

How to create a Webex bot

First, let’s create a Webex bot using the Webex Developer UI.

Webex for Developers has a great step-by-step guide here to help you get up and running.

Some important things to consider:

◉ Think about what you want to name your bot. It should be intuitive, but unique. Depending on how you set up your Webhook, you may be typing the bot’s name a lot, so take that into account.

◉ The secret token that’s auto-generated for your bot is used for authenticating with the Webex API. When you use this token, Webex will treat your bot like a real user who can create messages, join rooms, or be tagged by other users.

◉ Will this bot interact with a lot of people? Will it have a very public presence, or will it only communicate with a few users? The answer to that question may have an impact on how you want to name it, what icon you select, etc.

Once you’ve taken all of that into account and filled out the bot creation form, you should see something like this, which includes the all-important access token:

How to receive Webhook Events locally

Next, you’ll need to host your bot where it can be accessed by Webex via API calls. If you’re developing locally and want to run a server that’s accessible to the internet, the Webex guide recommends localtunnel.me or ngrok. I went with localtunnel.me for my local environment.

$ npm i -g localtunnel

$ lt --port 3000

The resulting output is the public domain name that you can use to tunnel through to a local port on your machine:

Note: If you’re having trouble running localtunnel via the command line after installing (as a few people have reported here), make sure your PATH includes the directory where NPM installs your binaries. For example, on a Mac, that’s /usr/local/bin. This command might help:

$ npm config set prefix /usr/local

$ npm i -g localtunnel

$ lt --port 3000

How to register a Webhook

Once your internet-accessible endpoint has been set up, you now have a domain that you can use to register a Webex Webhook. Your Webex Webhook will listen to specific events that take place within the Webex platform and notify your web service via HTTP POST requests.

There are multiple ways to register a webhook. Under the hood, however, they all boil down to making your own HTTP POST request. I’ve posted a Postman collection that you can use to make this process a little easier. Fill in your own environment’s variables as you go and include the access token used in the header.

This is what my Postman request looks like:

Feel free to use whatever technology you like, including good old-fashion CURL:

curl --location --request POST 'https://webexapis.com/v1/webhooks' \

--header 'Authorization: Bearer $BOT_TOKEN \

--header 'Content-Type: application/json' \

--data-raw '{

    "name": "simple-webhook",

    "targetUrl": "https://tidy-falcon-64.loca.lt",

    "resource": "messages",

    "event": "created",

    "filter": "mentionedPeople=me"

}'

What’s important to note, is that Webex will send notifications to the domain that you specify in your POST request. If you’re using a tunnel into your local environment, list the domain that was given to you when you activated your proxy.

A very impactful part of your Webhook will be the filter property. This determines which Webex events are sent to your bot as notifications (and which are filtered out). To keep things simple, my bot is only notified when users send a message that specifically mentions it in a Webex Teams Room:

Webex has a nice, convenient tag for this: me uses the authorization token from the request to determine the identity of the user making that request (in this case, our bot), and applies that identity wherever it sees me referenced.

Alternatively, you can set a filter that only triggers notifications for direct messages to your bot, as opposed to mentions in Webex rooms. Since the goal of this post is to broaden visibility into the various processes, these examples show interactions in a Webex Teams Room, however, both are equally viable options.

When you send your POST request, Webex will respond with a body that contains an ID for your Webhook. While you can use the Webex API to GET a list of your Webhooks, it might be a good idea to hold onto this, in case you want to quickly update or delete this Webhook in the future. The Postman collection linked above stores the most recently created Webhook ID in an active_webhook environment variable automatically, which then powers the DELETE call in that collection.

How to create your bot server

For simple use cases, you may want to use the Webex Node Bot Framework, which is great for quick implementation. In order to get more familiar with the different components involved in this series, we’ll start from scratch, diving into the step that powers your Webex bot.

Getting Started with Express

Let’s set up a web server that can listen for POST requests from the Webex Webhook that we’ll create in a minute. This doesn’t have to be complicated for now, just something to demonstrate that we’re able to receive requests. For simplicity, we can use the ExpressJS generator, but you can use any web framework or technology that you like.

$ npm i -g express-generator

$ cd where/you/want/your/project

$ express

Since my IDE handles JavaScript Modules a lot better than it handles require statements, I opted to go with a more modern approach for my dependency management. This is totally optional and has no bearing on how you set up your code. However, if you want to follow the code snippets as I’ve laid them out, you’ll want to do the same. The first step is to add the following key/value pair to your package.json file, anywhere in the root of the JSON object:

"type": "module",

A lot of the boilerplate code can be stripped out if you like – we won’t need a favicon, a public/ folder, or a users route handler. Here’s what my code looked like after I stripped a lot of the simple stuff out:

// in app.js

// notice that I changed the require statements to use JS modules import statements

import express from 'express';

import logger from 'morgan';

import indexRouter from './routes/index.js';

const app = express();

app.use(logger('dev'));

app.use(express.json());

app.use(express.urlencoded({ extended: false }));

app.use('/', indexRouter);

// boilerplate error code didn’t change

// …

// **be sure to remember to set app as the default export at the end of the file**

export default app;

Since I’m using JS Modules, I also had to change the executed file in an Express app www/bin to www/bin.js, and revise the boilerplate require statements there as well to use import syntax:

// in www/bin.js

/**

* Module dependencies.

*/

import app from '../app.js';

import _debugger from 'debug';

const debug = _debugger('chatops-webhook:server');

import http from 'http';

// nothing else in this file needed to change

Adding a Route Handler

That takes care of the majority of the boilerplate. At this point, I only have four files in my codebase, despite how many Express gives me out of the box:

◉ app.js

◉ package.json

◉ bin/www.js

◉ routes/index.js

We’ll want to add a route handler that lets us know when we’ve received a POST request from our Webex Webhook. It can be a simple function that prints the request body to the application console – nothing complicated, just a few lines of code:

// in routes/index.js

import express from 'express'

const router = express.Router();

router.post('/', async function(req, res) {

  console.log(`Received a POST`, req.body);

  res.statusCode = 201;

  res.end();

});

export default router;

Give it a try

You now have all of the important components for receiving message notifications from Webex:

◉ A bot to act as an identity for your Webex interactions

◉ If applicable, a network tunnel to expose your local web service to the public internet

◉ A Webhook set up by your bot to receive Webex notifications

◉ A web service to receive Webex notifications on a POST endpoint

Let’s test it out! To keep things simple for now, create a new room in Webex Teams and add your bot as a member. Next, start typing your message, mentioning your Bot (you can use the @ symbol or type its name) as part of the text. When you hit enter, after a brief pause, you should see a request come through to your running web service, which should log the POST body that it received in its console output:

Congratulations, you’ve just set up your very own Webex bot!

What’s next

As promised, our next post will walk through the extremely important aspect of securing our bot. We’ll make sure that only Webex can access it and only authorized users can trigger automation. After that, we’ll move on to new and exciting ways that you can automate everyday workflows right from a Webex Teams Room!

Learn, train, and certify in Cisco Collaboration

As you make your way through this ChatOps series, consider validating your skills with a Cisco Certification.

The 300-835 CLAUTO: Automating and Programming Cisco Collaboration Solutions is a 90-minute exam that counts toward three certifications — the CCNP Collaboration, Cisco Certified DevNet Professional, and Cisco Certified DevNet Specialist – Collaboration Automation and Programmability certifications. Check out the CLAUTO exam topics, and you’ll find that 25% of the exam covers Cloud Collaboration technologies. Before we meet again, take some time to browse through the free CLAUTO Study Materials available on the Cisco Learning Network, which will help you solidify today’s ChatOps focus on building your first Webex bot.

Source: cisco.com

Continue reading