Why Being Different Is Better

At last year’s Partner Summit, Cisco Channel Chief Oliver Tuszik talked about how partners can “own their edge” to uniquely differentiate themselves and help them perform today while transforming for the future. You may also recall his hilarious comparison to a monkey. Although he and the monkey share 99% of the same DNA, the 1% makes them very different beings. That 1% difference in a business context is a competitive advantage that leads to greater partner margin, revenue, and material business outcomes for customers. It is why differentiation is a big focus for Cisco and our partners.

When we talk about differentiation within the Strategic Partner Organization, we’re referring to how we work with our global partners to create a unique competitive advantage that showcases our joint capabilities for customers. How do we do this?  We use a combination of co-developing technology, integrating platforms with APIs, creating new go-to-market initiatives, and building new solutions and joint architectures that open up new buying center budgets within customers. This differentiation is the secret sauce that gives Cisco and our partners the competitive edge to deliver business outcomes.

Differentiation at Work

Here are a few real-world examples of how Cisco and some of our global strategic partners are driving differentiated business outcomes:

NTT

NTT Ltd. provides customers with outcome-based solutions powered by investments and strategic collaboration with Cisco. Our partnership centers around the joint development of consumption and adoption models for software (and services) that delivers on the promise of client-centric, data-driven, managed services. Seamless access to accurate and actionable data is the key differentiator for NTT Ltd., which is integrating more than 160 APIs and telemetry from Cisco platforms, products and programs into their service layer and managed center portal. API integration and telemetry allow customers to realize the full value of software licenses, easily track ROI and build new opportunities for innovation and growth, while ensuring a delightful, data-driven customer experience.

SAP

Through Cisco’s AppDynamics Business IQ for SAP, customers can visualize their SAP application performance and measure how that performance impacts their business health. The solution, which also monitors non-SAP business processes, uses machine learning algorithms to flag operation bottlenecks and provide root cause analysis so customers can remediate the issue. Read our SAP Partner Executive Robert Madl’s August blog “Monitoring SAP Business Processes with Cisco AppDynamics” for more details.

Schneider Electric Industries

Industry 4.0 is enabling digital transformation and delivering business outcomes such as increased agility and productivity gains while reducing operating costs for customers in manufacturing and industrial plants. Cisco and Schneider Electric Industries are committed to take advantage of this market with our joint differentiated solution architecture EcoStruxureTM. Our latest offer, SecureConnect EcoStruxure, leverages Schneider’s market leading IIoT applications integrated with Cisco’s industrial networking, edge intelligence and end-to-end security solutions. It was recently deployed by a large global mining company, which used asset optimization and asset tracking. Additional industry use cases include predictive maintenance and remote monitoring.

Deloitte

Another example of partner differentiation is the collaboration between Cisco and Deloitte. We team together to leverage Deloitte’s cyber strategy and transformation experience with Cisco’s industry leading security portfolio of products. Combining our joint strengths, we helped a large healthcare provider bridge security capability gaps, identify and align on key security priorities, and achieve security objectives through a Security Enterprise Agreement (EA) Value Assessment. The Assessment is designed to provide an objective third-party evaluation of EA value over the agreement’s term, providing customers with data to develop an actionable strategy to realize the highest value of a Cisco Security EA.

NetApp

Our customers live in a hybrid cloud world. They seek consistent and reliable ways to manage their data—whether in the data center, at the network edge or in the public cloud. You’re likely aware that Cisco and NetApp’s converged infrastructure platform FlexPod has supported mission critical applications for over a decade. But did you know that FlexPod offers an elegant solution for modern, hybrid cloud environments? FlexPod leverages NetApp’s Data Fabric, a part of their ONTAP storage operating system, to accelerate digital transformation by simplifying and integrating data management across cloud and on-premise environments.

Continue reading

Top 5 reasons to keep your Identity and MFA providers in sync

By now, you may have heard about SecureX, Cisco’s new integrated platform that simplifies the security experience. SecureX is built into the Cisco security portfolio, and connects your entire security ecosystem for simplicity, better visibility, and greater operational efficiency. SecureX sign-on is one of the key features of SecureX – it’s giving users instant access to the platform and all of their applications and data, while keeping the identity provider (IdP) and multi-factor authentication (MFA) in sync.

Is your organization using an IdP and MFA provider? You can make life easier for your SecOps team, while strengthening your organization’s cybersecurity posture, improving compliance and increasing visibility without adding tasks to your team. This post will describe a new automated process that can do all these for you.

Background

With SecureX sign-on, we are using several identity providers (like Okta, Auth0, Azure AD and Cisco security) as our applications need and see fit. We chose Duo to be our multi-factor authentication (MFA) provider as it gave us great visibility into our customers’ security posture and is a very flexible MFA. Now we needed to have our Identity and MFA Providers in sync.

An identity provider (abbreviated IdP or IDP) is a system entity that creates, maintains, and manages identity information for principals while providing authentication services to relying applications within a federation or distributed network.

Multi-factor authentication is an authentication method in which a computer user is granted access only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism: knowledge (something only the user knows), possession (something the user and only the user has), and inherence (something the user and only the user is).

Multi-factor authentication reduces the incidence of online identity theft, because the victim’s password would no longer be enough to give a thief permanent access to their information.

Why do my Identity and MFA providers need to be synchronized?

Here are 5 reasons to keep them in sync:

1. General security hygiene. Keeping user names and deletion in sync to avoid two split brain databases is always a good idea – you never know when you are going to try to research an issue.

2. User deletion. For both compliance and security reasons, if I delete a user, I want him gone from all my databases. Almost every IDP has 50% ghost accounts and cleaning them up is important.

3. Reset user’s credentials. The number #1 reason for calls to our call centers are lost phones and mistaken registration. Allowing for a simple way to reset from one place that permeate everywhere.

4. Policy is king. Keeping the data in sync allows me to create dynamic policies that traverse the single provider.

5. Reporting. Providing meaningful reports, with groups in place I can show specific admins how their domains look like.

Why not use SCIM?

System for Cross-domain Identity Management (SCIM) is a standard for automating the exchange of user identity information between identity domains, or IT systems.

User identities synchronization can be achieved using the SCIM specification, however not all MFA providers want to use or can use SCIM. This SDK keeps users synchronized between service providers in this case.

How this works

A user can update his profile details in the IdP service.

An admin can perform the following actions in the IdP service:

◉ Create/delete a user

◉ Create/rename/delete a group

◉ Associate/disassociate a user to a group

◉ Disable/reenable a user

◉ Reset MFA for a user

◉ Supported Identity Providers

This list is expected to grow with time

◉ Okta

◉ Auth0

Supported MFA Providers

This list is expected to grow with time

◉ Duo Security

Deployment

The Webhooks endpoint can run anywhere, even on-prem.

Deployment scripts to AWS, Azure and Google Cloud are provided via Terraform.

Supported Cloud Providers

◉ AWS

◉ Azure

◉ GCP

Continue reading

Economic Benefits of Virtualizing the CCAP Core with a Microservices Based Architecture

Architecture

Service providers are going through a digitalization journey. And one aspect of that journey is the virtualization of their service delivery infrastructure. At Cisco, we are making that transition easier for our customers by creating a common virtualization platform across mobile 5G, cable vCCAP, and Telco vBNG. This helps operators reduce their cost to virtualize the infrastructure and enable them to rapidly tap into new revenue opportunities.

When it comes to virtualization for cable, we did not virtualize the legacy CCAP, we re-architected the platform from the ground up to come up with a microservices-based architecture. That is what became our Cloud-native Broadband Router(cnBR). Why? That was the only way to get to ours and our customers’ end goal which is a hybrid, Multi-cloud, and Multi-Access Edge Compute(MEC) based cable broadband platform. cnBR has four major types of microservices: Data Plane(DP), Control Plane(CP), Real-Time(RT), and Management Plane(MP) that we can deploy at any location in the network or the cloud. cnBR’s microservices-based architecture enables webscale operations such as auto-healing, autoscaling, load balancing, and fault-tolerance at the infrastructure layer.

Evolution

With cnBR’s microservices-based architecture, you can start with a simple on-prem appliance like architecture that is familiar to your operations and IT organization. And as you gain familiarity, you can evolve into a hybrid and multi-cloud world by moving some of the microservices to public cloud platforms. The move of some of the microservices to public cloud platforms such as GCP, Azure, and AWS will reduce operational burden, extend reach, and augment capacity. Figure 1 shows the phased deployment evolution of the cnBR architecture:

Figure 1: Evolution of cnBR Architecture

Phase 1: Centralized on-Prem and cloud-native appliance – In this phase, you will start with all the microservices running in the hub or Datacenter.

Phase 2: Multi-Access Edge Compute(MEC) – Here, you will slowly move some of the microservices closer to the edge in an Edge compute platform or a node that has a compute board to enable a MEC architecture. This will focus on shifting the data plane(DP) and real-time(RT) microservice to MEC platform.

Phase 3: Hybrid Cloud – This phase moves the management plane(MP) and control plane(CP) microservices to a private or public cloud and keeps data plane(DP) & Real-Time(RT) microservices at the edge

Phase 4: Multi-cloud – This phase provides flexibility in enabling the management and control plane microservices to run in any public cloud environments with minimal friction.

 Why Migrate to a Microservices based Architecture?

With microservices-based architecture, you can improve:

– Time to market: you can get features in weeks vs months, 

– Agility:  you enable hitless and maintenance windowless upgrades, 

– Scale: you gain seamless and on-demand auto-scaling which gives you unprecedented cluster level redundancy and scale,

– Cost: you can lower TCO with reduced footprint and facilities cost.

Why Cisco’s cnBR?

The virtualization of the access infrastructure is one way to add more capacity. To better understand how operators can virtualize and reap immediate business benefits with cnBR, we looked at CAPEX and standard operational costs like space, power & cooling while increasing the scale of the microservices-based architecture. We also did the same scaling and cost analysis of a legacy appliance-based CCAP solution so we can compare the savings. What we found is a compelling business value of going to a microservices-based architecture. These are additional benefits to the service/feature velocity and operational efficiency enabled by agile webscale operations of microservices-based architecure.

The analysis included scenarios where bandwidth per service group is increased from 1 Gbps to 5 Gbps in the downstream while the upstream is increased from 100 Mbps to 500 Mbps. The average Capex Savings was 29%, average OPEX savings were 42% and the average space(RU) savings were 73%. Figure 2 highlights the savings as the bandwidth scales up.

Figure 2 . Business benefits of cnBR as system bandwidth scales up

To help do your own analysis, we have created an easy to use vCCAP economics calculator. You can do your own analysis based on your current network configuration and long-range plan(LRP). Figure 3 highlights the type of summary output you can get from the vCCAP Economics Tool.

Figure 3. Summary of Capex, Opex comparison between cnBR and traditional CCAP

Continue reading

Resiliency and the Path to Automation

Look anywhere and you’ll find conversations about autonomous operations. Everyone is weighing in on how to balance the benefits from these new technologies with the perceived impact on society and our collective future, particularly in our Covid reality. What I can tell you – from an industrial IoT perspective – is that we are seeing autonomous operations having a very positive effect.

Across industries, we’re seeing autonomous operations deliver increased business resiliency, better jobs, improved working conditions, increased efficiency, and a higher quality of work/life balance across many industries.

◉ Autonomous trains: Since the first driverless trains in the late ‘90s, more and more passenger train lines are being built and converted to automated lines, delivering additional safety for passengers, operational flexibility and reduced operating costs. Driverless trains can increase throughput by increasing the frequency of trains on a metro line and at the same time, they deliver a track record for safety that human drivers are unable to match.

◉ Warehouses and distribution centers: Entirely autonomous loading systems are now taking and fulfilling orders from the supply chain. Forklifts and pickers fetch the product, deliver to the pallet, wrap for shipping, and transport to the shipping dock.

◉ O&G exploration: Once workers get a drill rig close to the target drill area, the rig can take over by itself – saving workers from a job that not only is dangerous but can take days. The autonomous drill can also quickly make on-the-fly changes, like adjusting the angle of the drill, to increase yield and efficiency.

◉ Auto manufacturing: Here manufacturers are weaving autonomous operations into their industrial automation efforts – like using RFID on to keep track of car bodies as they move across the production line and Automated Mobile Robots (AMRs) to safely move material across the factories.

◉ Amusement rides: Today the most advanced and desired rides in amusement parks are the so-called “dark rides”, where visitors hop on fully autonomous vehicles speeding up through a completely dark warehouse and where the experience is provided though immersive displays, VR googles, and incredible accelerations. The entire outdoor “amusement network” is connected by wireless access points on the vehicles and the infrastructure, all powered by rugged IoT switches and routers.

Behind each level of automation is a communication and connectivity challenge across industries.  Autonomous operations require vast quantities of real-time video and data that legacy networks simply can’t handle – and often the operations are in harsh, remote, and dangerous locations. Trains are constantly in motion across remote geographies and inside tunnels, presenting unique connectivity challenges. All this automation translates into the need for high bandwidth, high security, and high reliability.

The Foundation for Autonomous Operations – A Secure and Reliable Network

The secret power behind autonomous operations?

It starts with Cisco’s secure and reliable network for IIoT that powers the entire system and connects everything – device to vehicle to data to Cloud – making sure your autonomous operations have the right data to make the right decision at the right time. Autonomous operations rely on that perishable data at the edge that is only valuable at that moment. After an incident, it does little value to know the vehicle should have turned.

Likewise, autonomous operations are only successful if the entire system is secure. If the network were to be hacked, perpetrators could take over the autonomous operations. Imagine the mining truck being rerouted to follow the wrong path causing an accident. You have to trust your network to trust your business to autonomous operations.

The recipe for your success?

We know that automation comes with challenges as we’re right there alongside our customers in their environments. No other company has the breadth of experience inside IT/communications and industrial settings across voice, data, and video to bring IT and operations together.

Every day we work with our customers to accelerate their success by:

◉ Bringing their IT/OT ecosystems together – so that IT can leverage all that they already know about Cisco networking and OT can get projects going quickly and securely

◉ Building a strong network of industrial partners who know the ins and outs of these industrial operations – and we’re just getting started

◉ Delivering more validated designs, like our new Distribution Automation – jointly validated with Schweitzer Engineering Laboratories – that highlights advantages from new innovations to the Cisco Resilient Mesh

Next up – Take a Deep Dive into Autonomous Mining

Over the next few blogs, I’m going to take you deeper into some automation use cases – first with mining and then with ports. While it may not be your exact industry, I’ll encourage you to keep reading as there are a lot of similar challenges across these operational settings.

Continue reading

MDS 9000 Series Switch Architecture Part 1: Superior CRC Error Handling

In this blog series, we’ve discussed many unique advantages of the Cisco MDS 9000 series switches. We explored NVMe/FC support, proven investment protection, the superior security provided by anti-counterfeit technology, and the industry’s unique SAN Analytics solution. Now, let’s look at another important aspect: the Cisco MDS 9000 Series switch architecture and what makes it unique.

Switching Architectures Explained

As most of us know, there are two different types of switching architectures: Store-and-Forward and Cut-Through. In Store-and-Forward architecture, an interface receives the full-frame (header information + data + CRC + checksum, etc.) before putting it back on the wire for egress. While in Cut-Through architecture, the switch will only wait till it receives the destination WWN to put it on the wire, without waiting for other portions of the frame (data + CRC + other control parameters) to be delivered.

In both mechanisms, a CRC error check, also called Cyclic Redundancy Check, is applied. But the difference is in the next stage – action. What actions are taken when the CRC error is identified?

CRC Error Handling in Cut-Through Architecture: Identify, Report, Forward (Ugh!)

In Cut-through Technology, if a packet has a CRC error, it will increase the CRC error reporting counter and put the corrupt packet back on the wire, and move on. Thus, the switch can only report the error and put it back on the wire without taking any further action. The packet that arose with the CRC error will have to be sent again anyway from the source across the entire path. The result? Degraded performance—twice. The first is due to a bad packet, and the second is a result of resending the original bad packet.

Cut-Through technology: Corrupt packets reported and forwarded.

Ultimately, the destination server and storage Host Bus Adapter (HBA) works extra hard to detect and drop the bad packet. In the ethernet world, this may not be a major issue. But in the Fibre Channel network, we have finite pools of buffer credits. Every packet that has to be retransmitted will need buffer credits. This can create performance issues, buffer credit starvation, and spend vital CPU cycles of the switches across the network. The impact includes high TCAM usage, increased latency, and a multitude of additional issues. In other words, the whole network can be impacted and brought to a halt.

CRC Error Handling in Store-and-Forward Architecture: Identify, Report, Drop (Yay!)

In Store-and-Forward technology, if the switch interface finds any CRC errors, it will identify and drop the packet on the spot. Why? Because here, the switch receives the full-frame (header + data + CRC checksum information, etc.) before putting it on the wire for egress. It will also signal the source to resend the corrupt packet. This saves resources, including memory, CPU, bandwidth, and buffer credit across the network, plus the additional resource consumption on the server or storage devices. As a result, the performance impact is minimal.

Store-and-Forward technology: Corrupt packets reported and dropped.

We implemented Forward Error Correction (FEC) in MDS 32G FC as a standard requirement. It can do a similar job, but with some limitation. FEC can only correct up to 11 bits out of 2,112 bits of FC frame. This is useful but in extremely limited cases. Note that the smallest portion of the FC frame (start-of-frame OR end-of-frame) is 4 bytes or 32 bits. So, what if errors are more than 11 bits or about 0.6 percent? FEC will not be able to help. Therefore, CRC error checking and deploying the correct architecture is highly important.

Continue reading

Get Ready to Crack Cisco CCNP Enterprise 300-430 Certification Exam

 Cisco ENWLSI Exam Description:

The Implementing Cisco Enterprise Wireless Networks v1.0 (ENWLSI 300-430) exam is a 90-minute exam associated with the CCNP Enterprise and Cisco Certified Specialist - Enterprise Wireless Implementation certifications. This exam certifies a candidate's knowledge of wireless network implementation including FlexConnect, QoS, Multicast, advanced location services, security for client connectivity, monitoring and device hardening. The course, Implementing Cisco Enterprise Wireless Networks, helps candidates to prepare for this exam.

Cisco 300-430 Certification Exam Overview:

Exam Name: Implementing Cisco Enterprise Wireless Networks

Exam Number: 300-430 ENWLSI

Exam Price: $300 USD

Duration: 90 minutes

Number of Questions: 55-65

Passing Score: Variable (750-850 / 1000 Approx.)

Recommended Training: Implementing Cisco Enterprise Wireless Networks (ENWLSI)

Exam Registration: PEARSON VUE

Sample Questions: Cisco 300-430 Sample Questions

Practice Exam: Cisco Certified Network Professional Enterprise Practice Test

Related Articles:

• 300-430 Certification: CCNP ENWLSI | Overview & Benefits
• Become a Successful Wireless Networking Specialist by Acing Cisco 300-430 ENWLSI Test

Continue reading

Using “WhatsOp” for Network Change Management

I often find myself passionately talking with my customers about programmability and how it unlocks hidden potential to do anything we can think of – even make a cup of coffee (if you purchase an API enabled coffee machine that is :-).

Some get it right away. Others can’t think of ideas for what they would like to do differently, and that reminds me of Henry Ford’s famous quote:

The WhatsOp use case

I understood I needed to provide a few examples of the potential use-cases in order to make it real. So, my quest began. At some point I stumbled upon Gabi Zapodeanu’s DevNet Create 2018 workshop – that was a perfect example of the use-case I was looking for.

WhatsOp is a very “visible” use-case in terms of user experience. It leverages several different programmability tools available on Cisco’s platform — Embedded Event Manager, Guestshell, Python, REST APIs, Webex Teams.

How I demonstrate WhatsOp

Change management is a use-case my customer faces on a daily basis in their production networks. Many of them have a policy that defines what changes are allowed throughout the day and what changes should be done only during off-hours. For example, assigning an access port to a vlan does not require any approvals, while changes to the routing table do.

With WhatsOp, every change (or selected changes) will notify selected network administrators and ask for their approval. The network administrators will be able to approve the change, or roll-back the change – through their smartphone, thanks to Webex Teams.

Experience the potential of programmability

My intention in demonstrating WhatOp is to expose the potential of programmability. We could restrict the commands privileged users are allowed to enter using ISE as TACACS, we could leverage Prime Infrastructure to archive and compare configuration revisions. However, integrating the functionality together and making it accessible from any device (that can access Webex Teams) would be challenging. Getting the functionality to work even without connectivity to the central management systems would be very challenging.

Don’t take the WhatsOp use-case as-is. Think about modifying it to address a unique problem your organization might be facing right now – how cool would that be?

If you have an interesting use-case – let me know! I’m always looking for new challenges to solve. For now, let me encourage you to try WhatOp yourself to experience the potential of programmability. Check out these resources:

◉ Webex Teams SDK which makes life much easier and the code cleaner working with the Webex Teams API.

◉ pyATS, which is super powerful for manipulations, parsing, differences and verification of network devices. The only reason we’re NOT using pyATS for configuration differences, is because the program needs to run in Guestshell, and we wanted to make it as lean as possible.

◉ Check out the repo on GitHub.

◉ Watch my demonstration video

Breaking it down:

How did it work?

1. Detecting the change: every change we have on a Cisco device triggers a log message, such as:

Aug 16 2020 07:05:12.521 UTC: %SYS-5-CONFIG_I: Configured from console by obrigg on vty0 (10.56.56.143)

We use EEM (Embedded Event Manager) built-in IOS-XE/NX-OS to wait for this log entry and kick off the Python program.

!

event manager applet config_change

 event syslog pattern "SYS-5-CONFIG_I" maxrun 240

 action 0 cli command "enable"

 action 1 cli command "guestshell run python3 /bootflash/guest-

share/WhatsOp/config_change.py"

 action 2 cli command "exit"

 action 3 cli command "exit"

!

2. Running the Python program: We’re using Guestshell to run our program on the device itself. Guestshell is a virtualized Linux-based environment, designed to run custom Linux applications, including Python for automated control and management of Cisco devices. This container shell provides a secure environment, decoupled from the host device, in which users can install scripts or software packages and run them.

3. What’s happening in Python:

a. The program starts with gathering information from the device: The user has performed the latest change and The running configuration (a copy is saved on bootflash:).

def save_config():

    # save running configuration, use local time to create new config file

name

    run = cli('show run')

    output = run[run.find('!'):len(run)]

    timestr = time.strftime('%Y%m%d-%H%M%S')

    filename = '/bootflash/guest-share/CONFIG_FILES/' + timestr + '_shrun'

    f = open(filename, 'w')

    f.write(output)

    f.close

    f = open('/bootflash/guest-share/CONFIG_FILES/current_config_name', 'w')

    f.write(filename)

    f.close

    return filename

syslog_input = cli('show logging | in %SYS-5-CONFIG_I')

syslog_lines = syslog_input.split('\n')

lines_no = len(syslog_lines)-2

user_info = syslog_lines[lines_no]

user = user_info.split()[user_info.split().index('by')+1]

old_cfg_fn = '/bootflash/guest-share/CONFIG_FILES/base-config' 

new_cfg_fn = save_config()

f = open(old_cfg_fn)

old_cfg = f.readlines()

f.close

f = open(new_cfg_fn)

new_cfg = f.readlines()

f.close

b. Then the program compares the running config, with the last approved configuration (saved on bootflash: as well).

def compare_configs(cfg1, cfg2):

    # compare two config files

    d = difflib.unified_diff(cfg1, cfg2)

    diffstr = ''

    for line in d:

        if line.find('Current configuration') == -1:

            if line.find('Last configuration change') == -1:

                if (line.find('+++') == -1) and (line.find('---') == -1):

                    if (line.find('-!') == -1) and (line.find('+!') == -1):

                        if line.startswith('+'):

                            diffstr = diffstr + '\n' + line

                        elif line.startswith('-'):

                            diffstr = diffstr + '\n' + line

    return diffstr

c. In case there are no changes (perhaps the user changed a setting and changed it back right after) – nothing will happen. However, if the program finds a difference between the running configuration and the last approved configuration – things will become more interesting.

d. The program will use the Cisco Webex Teams API to create a new space and add the preconfigured network administrators in that space. The program will alert the space about the changes that were made, and ask the admins for an approval or decline.

if diff != '':

    # find the device hostname using RESTCONF

    device_name = cli('show run | inc hostname ').split()[1]

    print('Hostname: ' + device_name)

    # Initialize Webex Teams API

    api = WebexTeamsAPI(access_token=WEBEX_TEAMS_ACCESS_TOKEN, proxies=PROXY)

    bot = api.people.me()

    # Create a new space

    room = api.rooms.create(WEBEX_TEAMS_ROOM)

    # Add members to the space

    for WEBEX_TEAMS_MEMBER in WEBEX_TEAMS_MEMBERS:

        api.memberships.create(room.id,personEmail=WEBEX_TEAMS_MEMBER)

    # Send initial message

    api.messages.create(roomId=room.id, markdown=f"Hello <@all>,  \n# Configuration change detected!**  \nDevice hostname: **{device_name}**, detected the following changes made by user: **{user}**.")

    api.messages.create(roomId=room.id, text=diff)

    api.messages.create(roomId=room.id, markdown=f"Do you approve these changes?  \nMention me using **@{bot.nickName}** and enter '**y**' or '**n**'.")

    counter = 6  # wait for approval = 10 seconds * counter, in this case 10 sec x 6 = 60 seconds

    last_message = ""

    # start approval process

    while (last_message != "Bye Bye") and (last_message != f"{bot.nickName} n") and (last_message != f"{bot.nickName} y"):

        time.sleep(10)

        messages = api.messages.list(room.id, mentionedPeople=bot.id)

        for message in messages:

            last_message = message.text

            break

e. If the changes are approved – the running config will be marked as the last approved configuration. If the changes are not approved (declined or timed out) – the program will perform a roll-back to the last approved configuration.

        if last_message == f'{bot.nickName} n':

            cli('configure replace flash:/guest-share/CONFIG_FILES/base-config force')

            approval_result = '- - -  \n<@all>,  \nConfiguration changes **not approved**, Configuration rollback to baseline'

            print('Configuration roll back completed')

        elif last_message == f'{bot.nickName} y':

            print('Configuration change approved')

            # save new baseline running configuration

            output = cli('show run')

            filename = '/bootflash/guest-share/CONFIG_FILES/base-config'

            f = open(filename, "w")

            f.write(output)

            f.close

            print('Saved new baseline configuration')

            approval_result = '- - -  \n<@all>,  \nConfiguration changes **approved**, Saved new baseline configuration'

        else:

            print("No valid response")

            counter = counter -1

            api.messages.create(roomId=room.id, markdown=f'- - -  \n<@all>, I did not receive a valid responce. **{str(counter)} attempts left**.  \nDo you approve these changes?  \nMention me using **@{bot.nickName}** and enter "**y**" or "**n**".')

            if counter == 0:

                last_message = "Bye Bye"

                cli('configure replace flash:/guest-share/CONFIG_FILES/base-config force')

                approval_result = '<@all>,  \nApproval request **timeout**, Configuration rollback to baseline'

                print('Configuration roll back completed')

    api.messages.create(roomId=room.id, markdown=approval_result)

f. Once it’s done, the Webex Teams space will be deleted in order to prevent flooding the admins with spaces.

    api.messages.create(roomId=room.id, markdown='This room will be deleted in 30 seconds')

    time.sleep(30)

    api.rooms.delete(room.id)

Continue reading