This article is Part 3 of a 3-part series:

• Part 1: When Networks Understand What You Want – The MCP Protocol Revolution
• Part 2: Network MCP Docker Suite – Seven MCP Servers for AI-Driven Network Operations
• Part 3 (you are here): From NetDevOps to AgenticOps – Real-World Use Cases with the Network MCP Docker Suite

In Part 1, I explained the Model Context Protocol (MCP). In Part 2, I introduced the Network MCP Docker Suite and walked through a live troubleshooting demo. In this final part, I focus on real-world use cases, practical scenarios, and the shift towards AgenticOps.

Key Use Cases Transforming Network Operations

1. Unified Network Operations

Today, engineers can manage Meraki cloud networks, on-premises infrastructure, Catalyst Center deployments, and direct IOS-XE devices through a single conversational interface. As a result, constant context switching between dashboards and CLI tools becomes unnecessary.

Example prompt: “Show me all switches in Building A with uptime less than 30 days.”

2. AI-Powered Network Management

Natural language queries now automatically gather, correlate, and analyze data from multiple network management systems.

Example prompt: “Generate a report of devices that don’t match between NetBox documentation and Catalyst Center inventory.”

3. Automated Troubleshooting

Instead of running commands manually, I can let AI assistants investigate network issues by querying multiple systems, correlating data, and suggesting remediation steps.

Example prompt: “Why is our main website experiencing high latency from Europe?” (Uses ThousandEyes + Catalyst Center.)

4. Security & Compliance Operations

It is also possible to monitor security compliance across the network infrastructure with unified access to ISE, Catalyst Center, and configuration management.

Example prompt: “Show me all non-compliant devices and their authorization profiles.”

5. Infrastructure Documentation Automation

Keeping network documentation synchronized automatically is another powerful use case. AI can continuously detect discrepancies between DCIM (NetBox) and the actual network state.

Example prompt: “Update NetBox with all devices discovered in Catalyst Center over the past week.”

Real-World Success Stories

Scenario 1: Network Troubleshooting

Challenge: A NOC engineer needs to investigate why a critical access point is showing as unreachable in Catalyst Center.

Solution: Using an AI assistant connected to both Catalyst Center and IOS XE MCP servers, the engineer simply asks what’s wrong. The AI automatically:

1. Checks device status in Catalyst Center
2. SSHs into the device via IOS XE MCP
3. Verifies physical connectivity via CDP
4. Identifies an IP address mismatch as the root cause
5. Suggests correction steps

Result: The issue is resolved in under 2 minutes instead of 20+.

Scenario 2: Infrastructure Documentation Sync

Challenge: A system administrator needs to ensure NetBox documentation matches the actual network state after several device deployments.

Solution: I simply query the AI: “Compare devices in Catalyst Center with NetBox and highlight discrepancies.”

The AI uses both the Catalyst Center MCP and NetBox MCP servers to automatically identify missing devices, outdated IP addresses, and incorrect site assignments.

Result: Documentation is updated in minutes with zero manual cross-referencing.

Scenario 3: Compliance Reporting

Challenge: An IT manager needs a quarterly compliance report showing device inventory, security posture, and policy compliance.

Solution: A single AI query is enough: “Generate compliance report showing all devices, their compliance status, and any ISE authorization issues.”

The AI correlates data from Catalyst Center (compliance), ISE (authorization), and NetBox (inventory) to generate a comprehensive report.

Result: The report is generated in minutes instead of days of manual data collection.

From NetDevOps to AgenticOps: The Evolution Continues

The Challenge: Traditional Ops is Outpaced

Today’s network operations teams face significant challenges:

• Massive technology disruption: cloud, AI, mobility, and internet convergence
• Skill shortage: many organizations face a shortage of experienced network and automation engineers
• Proliferation of agents: enterprises will run large numbers of AI agents across domains
• Speed requirements: traditional operations are outpaced, and AI is often the only way to keep up

Because of these forces, moving beyond traditional NetOps into NetDevOps and, eventually, AgenticOps is not just interesting – it becomes necessary.

Cisco AI Canvas and Deep Network Model

While the Network MCP Docker Suite provides open-source MCP servers for network operations, Cisco is also investing heavily in AI platforms such as
AI Canvas (intro video) and the Deep Network Model. These are designed to bring AgenticOps concepts into production environments at scale.

• Deep Network Model: a purpose-built networking model that aims to answer networking questions more accurately than general-purpose LLMs
• Trusted training: built on decades of Cisco networking expertise and learning content
• Cross-domain operations: designed to span campus, branch, data center, security, and observability domains

My Network MCP Docker Suite is not an official Cisco product; it is an open-source project I created to make these concepts tangible and usable in labs and real environments today.

How the Network MCP Docker Suite Fits In

For me, the Network MCP Docker Suite provides:

• An open-source foundation for building AI-ready network operations
• A concrete MCP protocol implementation that works with multiple AI assistants
• Multi-system integration (Cisco platforms, NetBox, ThousandEyes, Splunk)
• A learning platform for understanding AgenticOps concepts end to end
• Production-ready containers that can run in lab or real environments

The Future of Network Operations

The Network MCP Docker Suite represents a shift in how we interact with network infrastructure. As AI assistants become more capable, the gap between human intent and technical implementation shrinks dramatically.

Imagine a future where:

• Network issues are detected, diagnosed, and often resolved autonomously
• Documentation updates itself automatically as the network evolves
• Security compliance is continuously verified across all platforms
• Capacity planning uses AI to predict needs before they become critical
• Multi-vendor network ecosystems work together seamlessly
• Junior engineers operate with senior-level expertise through AI augmentation
• Mean time to resolution (MTTR) drops from hours to minutes

With MCP and practical projects like the Network MCP Docker Suite, I believe this future is much closer than many expect.

Get Started Today

If you want to explore these ideas hands-on, you can start with the open-source code:

Network MCP Docker Suite on GitHub

The repository includes everything you need to deploy the MCP servers, connect them to AI assistants, and try out the use cases I’ve described in this series.

Key Takeaways

1. MCP is a Protocol, Not an AI

Model Context Protocol (MCP) is an open standard that enables consistent interaction between AI agents and external data and tools – comparable to TCP for data. It is not an AI itself; it is the communication layer that makes AI-powered operations possible.

2. AI is Already Reshaping Network Operations

We are moving from traditional NetOps → NetDevOps → NetAIOps / AgenticOps. Manual operations alone are not enough anymore, and AI is becoming a required part of the toolkit.

3. The Network MCP Docker Suite Makes AIOps Accessible

With seven production-ready MCP servers, containerized deployment, and documentation, you can start implementing AI-driven network operations today.

4. Multi-System Correlation is the Killer Feature

The real power comes from correlating data across multiple systems – Catalyst Center, IOS XE, NetBox, ThousandEyes, ISE, Splunk, and more – and letting the AI reason over the combined context.

5. Open Standards Enable Innovation

By building on MCP, the suite works with any MCP-compatible AI assistant (Cursor, Claude Desktop, LibreChat, and future tools), which keeps the approach flexible and future-proof.

If you missed any part of the series, you can go back here:

• Part 1: When Networks Understand What You Want – The MCP Protocol Revolution
• Part 2: Network MCP Docker Suite – Seven MCP Servers for AI-Driven Network Operations

Note: The Network MCP Docker Suite is a personal open-source project created for demonstration purposes. It is not an official Cisco product. The examples and code are provided “as is” to illustrate how AI agents can interact with network APIs through the Model Context Protocol (MCP).

The post From NetDevOps to AgenticOps: Real-World Use Cases with the Network MCP Docker Suite appeared first on Cisco Switzerland Technology Blog.

This article is Part 2 of a 3-part series:

• Part 1: When Networks Understand What You Want – The MCP Protocol Revolution
• Part 2 (you are here): Network MCP Docker Suite – Seven MCP Servers for AI-Driven Network Operations
• Part 3: From NetDevOps to AgenticOps – Real-World Use Cases with the Network MCP Docker Suite

Real-World Problem Solving

Before explaining what the Network MCP Docker Suite is, let’s start with a typical problem many network-operations teams face.

Traditional Troubleshooting Workflow

Picture this scenario: a NOC engineer receives an alert that a network device is unreachable from Cisco Catalyst Center. The traditional troubleshooting workflow often looks like this:

1. Log into Catalyst Center
2. Navigate to the device
3. Check status and metrics
4. Open an SSH client
5. Connect to the device and run diagnostic commands
6. Check neighbors and interfaces
7. Cross-reference with documentation
8. Identify and fix the issue

Time consumed: 15–30 minutes or more, especially if data sources are scattered.

AI-Powered Troubleshooting with MCP

Now imagine the same engineer simply asking an AI assistant:

Engineer: “Check why wlsn-access-1.dna.its-best.ch is unreachable from Cisco Catalyst Center.”

AI-driven troubleshooting in action: natural-language queries automatically investigate and resolve issues through multiple MCP servers.

The assistant, connected to multiple MCP servers, can:

1. Query Catalyst Center for device status and known issues
2. Connect to the device via SSH using the IOS XE MCP Server
3. Verify connectivity and neighbors
4. Correlate data from both systems using AI reasoning
5. Identify the root cause (e.g., inventory IP mismatch)
6. Suggest corrective steps

Time consumed: often under two minutes.

This is the kind of workflow I wanted to enable in a repeatable, easily deployable way. That’s where the Network MCP Docker Suite comes in.

What is the Network MCP Docker Suite?

In Part 1, I introduced the Model Context Protocol (MCP) – an open standard that lets AI agents interact with tools and data sources consistently.

To bring these concepts to life, I built a community open-source project — the Network MCP Docker Suite — showing how AI agents can talk to network APIs using MCP.

The Network MCP Docker Suite is an open-source, Docker-based collection of seven MCP servers that enable AI-driven network operations through integration with Cisco platforms, NetBox, ThousandEyes, and Splunk.

Think of it as a universal translator that lets AI assistants like Cursor, LibreChat, and Claude Desktop communicate directly with your infrastructure using natural language – all powered by MCP.

The Seven Network MCP Servers

• Meraki MCP Server: Cloud network management via Meraki Dashboard API
• NetBox MCP Server: DCIM/IPAM documentation and management
• Catalyst Center MCP Server: Enterprise network management and assurance
• IOS XE MCP Server: Direct device access via SSH
• ThousandEyes MCP Server: Performance monitoring and path visualization
• ISE MCP Server: Identity and access control operations
• Splunk MCP Server: Log analysis and operational intelligence

Each server exposes MCP tools that the AI assistant can call. Because they all speak MCP, an AI assistant can orchestrate them together in a single flow – just like in the example above.

Getting Started with the Network MCP Docker Suite

If you want to try this in your own lab, the Network MCP Docker Suite is available on GitHub with setup guides and examples.

GitHub Repository: github.com/pamosima/network-mcp-docker-suite

The repository includes:

• Pre-built Docker containers for all seven servers
• Setup guides and configuration examples
• Flexible deployment profiles (all, Cisco, monitoring, security)
• Environment templates for quick start
• Integration examples for Cursor, LibreChat, and Claude Desktop
• Troubleshooting tips and documentation

The Network MCP Docker Suite was also featured in a recent live stream on the Cisco DevNet YouTube channel, where we explored how AI agents interact with network APIs through MCP servers.

Watch the Cisco DevNet live session on YouTube

What Comes Next?

The Network MCP Docker Suite focuses on making MCP tangible for network engineers and operations teams. In Part 3, I explore how these capabilities connect to the broader vision of AgenticOps – including Cisco’s AI Canvas and Deep Network Model.

Continue reading the series:

• Back to Part 1: When Networks Understand What You Want – The MCP Protocol Revolution
• Next – Part 3: From NetDevOps to AgenticOps – Real-World Use Cases with the Network MCP Docker Suite

Note: The Network MCP Docker Suite is a personal open-source project created for demonstration purposes. It is not an official Cisco product. The examples and code are provided “as is” to illustrate how AI agents can interact with network APIs through the Model Context Protocol (MCP).

The post Network MCP Docker Suite: Seven MCP Servers for AI-Driven Network Operations appeared first on Cisco Switzerland Technology Blog.

This article is Part 1 of a 3-part series:

• Part 1 (you are here): When Networks Understand What You Want – The MCP Protocol Revolution
• Part 2: Network MCP Docker Suite – Seven MCP Servers for AI-Driven Network Operations
• Part 3: From NetDevOps to AgenticOps – Real-World Use Cases with the Network MCP Docker Suite

The Dawn of AIOps in Network Management

Network administrators face an increasingly complex challenge: managing hybrid infrastructures spanning cloud and on-premises environments, juggling multiple management platforms, and responding to issues faster than ever before. What if you could simply ask your network what’s wrong, and have an AI assistant investigate, correlate data across multiple systems, and provide actionable solutions?

This is the promise of AIOps (Artificial Intelligence for IT Operations). In this series, I explore how the Model Context Protocol (MCP) and the Network MCP Docker Suite make this a reality in real-world network environments.

Understanding MCP: The USB-C for AI Agents

Before I talk about the Network MCP Docker Suite, I want to explain the foundational technology that makes it all possible: Model Context Protocol (MCP).

What is MCP?

Model Context Protocol (MCP) is an open standard developed by Anthropic that connects AI agents with external data and tools. I like to describe it as the “USB-C for AI Agents” – a universal connector that enables AI assistants to interact with any system in a standardized way.

Important: MCP is a Protocol, Not an AI

Let me clear up a common misconception right away:

• MCP is not an AI Agent
• MCP is not an AI Assistant
• MCP is not an LLM (Large Language Model)
• MCP is a Protocol – just like TCP, UDP, or HTTP

Just as HTTP defines how web browsers communicate with web servers, MCP defines how AI agents communicate with tools, databases, and APIs.

The Problem MCP Solves: API Consistency

Traditional approach:

The problem: If Service #1 changes its API, dependent applications may stop working. API consistency is always a challenge in traditional integrations.

With MCP:

The solution: MCP servers act as “translators” between the standardized MCP protocol and the specific APIs of each service. When an API changes, you only need to update the MCP server, not every application that uses it.

MCP Client (The AI Assistant)

• Examples: Claude Desktop, Cursor IDE, Cisco AI Agent, LibreChat
• Integrated with LLM models for reasoning
• Understands natural language queries
• Orchestrates conversation flow
• Determines which MCP servers to query

MCP Server (The Translator)

• Examples: Catalyst Center MCP, IOS XE MCP, NetBox MCP, and more
• Translates MCP protocol to native APIs (REST, SSH/CLI, etc.)
• Maintained by service/tool providers
• Handles authentication and authorization
• Adapts when backend APIs change – protecting applications from disruption

Real-World Example: Network Troubleshooting with MCP

When you ask an AI assistant: “Help me troubleshoot the P1 issue on Catalyst Center.”

All of this happens in seconds, with the MCP protocol ensuring consistent, reliable communication between the AI and your network infrastructure.

Why MCP Matters for Network Operations

• Universal Standard: One protocol works with many AI assistants
• Security Gateway: MCP servers control and audit API access
• API Abstraction: Changes to backend APIs don’t break AI integrations
• Future-proof: Works with current and future AI models
• Interoperability: Mix and match AI assistants and network platforms
• Context-rich: Provides AI with the data it needs to reason effectively

Continue reading the series:

• Next – Part 2: Network MCP Docker Suite – Seven MCP Servers for AI-Driven Network Operations
• Part 3: From NetDevOps to AgenticOps – Real-World Use Cases with the Network MCP Docker Suite

Note: The Network MCP Docker Suite is a personal open-source project created for demonstration purposes. It is not an official Cisco product. The examples and code are provided “as is” to illustrate how AI agents can interact with network APIs through the Model Context Protocol (MCP).

The post When Networks Understand What You Want – Not Just What You Say: The MCP Protocol Revolution appeared first on Cisco Switzerland Technology Blog.

1. 4k Content Sharing
2. FullHD 1080p Video
3. Sign Language Interpretation
4. Simultaneous interpretation
5. Share a selected part of your screen only
6. Multistream (Streaming Speaker and Group view at the same time)
7. Directional Audio, know where the active speaker is displayed
8. Persistant Chat before, during and after the Meeting
9. Best in class combination of Application and Devices with e.g. pair, share, control a device via proximity, Companion Mode, Visual Watermarking
10. Customised Lobby
11. Client-less Meetings (Video)
12. PSTN Dial-in is included e.g. Start a Scheduled Webex Meeting by Phone
13. Hybrid Deployment options with e.g. Video Mesh Node
14. Hands on Labs, a feature of Training Center (yes, it’s still out there and rocking!!!) I discovered by a partner.
15. Slido, included in the meeting license
16. Cloud registration for our devices and all the amazing features coming with Control Hub (this would fill more than a chapter)
17. Device Cloud Promotion (this link is available to partners only) helps you getting great conditions for Cisco Video devices.

Let us know if you are interested in any additional detail, I’m sure you, your users / customers would benefit from one or multiple points from above…

The post Why using Webex Meetings or the value the Active User Meeting license can provide appeared first on Cisco Switzerland Technology Blog.

Problem Statement

Receiving constant notifications of network issues can be overwhelming, especially if you only need status information at specific times of the day. Network administrators require a more targeted notification approach that provides them with the information they need when they need it.

Cisco DNA Center to Webex Real-Time Notifications

Challenges

The primary challenge with this approach is creating an efficient and customizable way to monitor network devices and report any issues that arise. The application must also be able to send notifications via Webex or SMS using eCall REST API.

Solution

The solution to these challenges is a small Python application that utilizes the Cisco DNA Center Python SDK which leverages the Cisco DNA Center Platform Intent-APIs to access Assurance information. By utilizing these APIs, we can create a Python application that reports any issues that arise on network devices managed by Cisco DNA Center.

The application can be configured to run at specific intervals using crontab, providing network administrators with the information they need when they need it. The application can also send notifications via Webex or SMS using eCall REST API.

Network Issue Reporting with the Python Application to Webex.

To get started with the sample code, you can install it from GitHub by following these steps:

1. Clone the repository:

git clone https://github.com/pamosima/dnac_issue_report.git

2. Install the necessary packages

3. Update the configuration file with your Cisco DNA Center credentials, Webex or SMS information, and any other desired settings.

4. Run the application either from the console or crontab

Benefits

The Python application provides several benefits for network administrators:

1. Targeted Notifications: Administrators can receive notifications at specific times of the day, reducing distractions and preventing critical alerts from being missed.

2. Customizable: The application can be configured to meet the specific needs of individual network administrators.

3. Automation: The application automates the process of monitoring network devices, freeing up network administrators to focus on other critical tasks.

4. Efficient: The application only sends notifications when necessary, reducing unnecessary notifications and preventing alert fatigue.

Conclusion

The Python application that utilizes the Cisco DNA Center API to report network device issues managed by Cisco DNA Center is an effective way to simplify network issue reporting. By utilizing the Cisco DNA Center API, we can create an efficient and customizable method to access Automation and Assurance workflows. By configuring the application to run at specific intervals using crontab, network administrators can receive notifications at the times they need them. This targeted notification approach can reduce distractions, prevent critical alerts from being missed, and improve overall network efficiency.

Additional information

• DNAC Issue Report Application on GitHub
• Cisco DNA Center Platform Python SDK
• Webex Teams Python SDK

The post Simplify Network Issue Reporting with a Python Application and Cisco DNA Center API appeared first on Cisco Switzerland Technology Blog.

As organizations continue to embrace digital transformation, the importance of network automation has become more significant than ever. With an increasing number of devices connecting to the network, the process of onboarding them has become complex and time-consuming, resulting in delays and inefficiencies. In this blog post, we will discuss the problem statement, challenges, and our solution for automating network device onboarding using Cisco DNA Center and webhook notifications.

Problem statement

Traditionally, the process of onboarding network devices involved manual configuration, which was time-consuming, error-prone, and complex. Network engineers had to manually configure the devices, update software versions, and configure security policies before they could connect to the network. This process was prone to errors, which resulted in network downtime and inefficiencies.

With the increasing number of devices connecting to the network, the onboarding process has become even more complex. Devices may have different configurations, and network engineers may not have the serial numbers or other identifying information for each device in advance. This creates a challenge for network engineers to onboard these devices efficiently and effectively.

Challenges

The process of onboarding network devices poses several challenges, including:

1. Lack of identifying information: In some cases, network engineers may not have the serial number or other identifying information for each device in advance, making it challenging to onboard them.
2. Manual Configuration: Manually configuring each device can be time-consuming and error-prone, leading to network downtime and inefficiencies.
3. Complex Network: As networks become more complex, the onboarding process becomes more challenging. Configuring devices across multiple locations and subnets can be a daunting task, requiring significant manual effort.

Solution

To automate the network device onboarding process, we’ve developed a Python Flask application that utilizes webhook notifications in Cisco DNA Center. The application listens for notifications and automatically onboards unclaimed devices as they connect to the network.

The following is an overview of the solution

1. Device Onboarding Process: When a new device connects to the network, it securely connects to Cisco DNA Center. The device is initially marked as “unclaimed” in Cisco DNA Center.

2. Webhook Notification: Cisco DNA Center sends a webhook notification to our Flask application when a new device connects to the Cisco DNA Center. The notification contains the device’s IP address and serial number.

3. Flask Application: Our Flask application listens for webhook notifications from Cisco DNA Center. When a notification is received, the application parses the information and determines if the device is eligible for onboarding.

5. Mapping IP Subnets: To determine if the device is eligible for onboarding, the Flask application maps the device’s IP address to the appropriate IP subnet. The mapping is based on a mapping file that includes parameter mapping to variables.
6. Device Onboarding: Once the device’s IP address has been mapped to the appropriate IP subnet, the Flask application claims the device in Cisco DNA Center. This involves configuring the device with the necessary software versions, security policies, and other settings required for it to connect to the network. This ensures that the device is recognized by the network and can communicate with other devices.

Benefits

Our solution provides several benefits to organizations looking to automate their network device onboarding process, including:

1. Efficiency: By automating the onboarding process, our solution reduces manual effort and improves efficiency.
2. Scalability: Our solution is scalable and can handle large numbers of devices connecting to the network.
3. Reliability: Our solution is reliable and reduces network downtime and inefficiencies.
4. Customizable: Our solution is customizable, allowing organizations to tailor it to their specific requirements and network configurations.

Conclusion

Automating the network device onboarding process is crucial to improving network provisioning time, reducing manual effort, and enhancing network reliability. Our solution, which utilizes webhook notifications in Cisco DNA Center and a Python Flask application, provides an efficient and scalable solution to automate the device onboarding process.

Additional information

• PnPAutoClaim: Python Flask Application on GitHub
• Cisco DNA Center User Guide: Onboard and Provision Devices with Plug and Play
• Cisco DNA Center platform: Events and notifications

The post Cisco DNA Center PnP Onboarding Automation Using Webhook Notification appeared first on Cisco Switzerland Technology Blog.

One of my favorite Partner Summit moments has always been recognizing our partners for the amazing things they do every day with our customers.  It is a moment where we can take a step back, reflect on everything we have worked on together and acknowledge our great achievements.

With that, it is my great pleasure to announce that the following Partners have been recognized as 2022 Cisco Central Theatre Award Winners:

Celebrating with our 2022 Central Theatre Award Winners

Huge congratulations!

To all the awarded Partners, let me say that I am truly humbled by your loyalty, hard work and tremendous commitment to our partnership and our customers. I am continuously inspired by your ability to innovate and deliver outstanding results together with us. Thank you!

The theme of this year’s Partner Summit is “Let’s Own It”. I think this short phrase perfectly describes our joint mindset and aspiration. Yes, we operate in an environment that is challenging in many different ways, but the opportunity to help our customers accelerate their digital transformation is there, and it is ours. To all our incredible partners: “Let’s Own It”!

The post Cisco Partner Summit 2022: Announcing the 2022 Cisco Central Theatre Award Winners appeared first on Cisco Switzerland Technology Blog.

Our mission consists of 4 Pillars: Power, Future, Inclusion & For All – unified into one common purpose.

For the last 15 years, Cisco has committed itself to these four pillars by designing a roadmap of commitments & actions to improve our sustainability strategy and set a new standard. An infinite journey refueled by new opportunities to pursue and new challenges to overcome.

Sustainability is fundamental to achieving that mission. Our customers’ ecological footprint is our footprint. We believe technology plays a key role in shaping an integrative and fair future sustainably and digitally.

Our focus is on renewable energy, the energy efficiency of our products & supply chain, and a circular economy. Our goal is to be net zero across all scopes of emissions by 2040, including our products, operations, and supply chain.

Achieving net zero requires us to think beyond just our Scope 1 and 2 emissions but also address the largest share of our greenhouse gas emissions – knowingly, the use of our products by our customers in their infrastructures and data centers.

Our technologies build the basis of nearly every major cloud, mobile network, video call, and digital transaction worldwide. A critical component in reaching our net zero goal will therefore be continuous innovation to increase the energy efficiency of our products and to lower our Scope 3 emissions.

We are convinced that with our technology, people, and global span, we can effectively lead change and be a role model in driving the twin transitions.

How our society consumes resources, plans cities, manages waste, and designs transportation systems leads us to believe there are significant hurdles to be found on our way.

Transportation is currently the largest producer of energy-related CO₂ emissions, accounting for 24%. This demand is expected to grow all across the world and in Switzerland in the coming decades as the global population increases, incomes rise, and more people can afford cars, trains, and flights.

The way cities are structured has multiple impacts, including their level of ability to adapt to climate -change. We are seeing emerging urban models, like the 15-minute city, that promote a human-centric and environmentally sustainable urban future. Mobility must be rethought.

The Swiss mobility paradigm is a key societal behavior that will benefit from innovative urban models and smart cities. To facilitate officials’ planning and decision-making process to improve the daily lives of citizens, it is crucial to monitor and collect data (sensors), transport this data (network infrastructure) and analyze it (compute).  To get an understanding, with the help of innovative AI algorithms, of how the system is used.

Through innovation, the Swiss industry and Cisco Switzerland have a unique opportunity to actively shape the societal transition to a digital transformation and a green future. It will accelerate mobility, meet sustainability goals, and help adapt to a low-carbon circular economy.

Cisco has a long history of setting and achieving environmental, social and
governance (ESG) goals. We published our first Corporate Citizenship Report
in 2005, and we continue to report our emissions data annually.

Read the Cisco 2021 Purpose Report

More information can be found on our Cisco ESG Reporting Hub

The post Cisco Sustainability: Committed to Powering an Inclusive Future for All appeared first on Cisco Switzerland Technology Blog.

Our mission consists of 4 Pillars: Power, Future, Inclusion & For All – unified into one common purpose.

For the last 15 years, Cisco has committed itself to these four pillars by designing a roadmap of commitments & actions to improve our sustainability strategy and set a new standard. An infinite journey refueled by new opportunities to pursue and new challenges to overcome.

Sustainability is fundamental to achieving that mission. Our customers’ ecological footprint is our footprint. We believe technology plays a key role in shaping an integrative and fair future sustainably and digitally.

Our focus is on renewable energy, the energy efficiency of our products & supply chain, and a circular economy. Our goal is to be net zero across all scopes of emissions by 2040, including our products, operations, and supply chain.

Achieving net zero requires us to think beyond just our Scope 1 and 2 emissions but also address the largest share of our greenhouse gas emissions – knowingly, the use of our products by our customers in their infrastructures and data centers.

Our technologies build the basis of nearly every major cloud, mobile network, video call, and digital transaction worldwide. A critical component in reaching our net zero goal will therefore be continuous innovation to increase the energy efficiency of our products and to lower our Scope 3 emissions.

We are convinced that with our technology, people, and global span, we can effectively lead change and be a role model in driving the twin transitions.

How our society consumes resources, plans cities, manages waste, and designs transportation systems leads us to believe there are significant hurdles to be found on our way.

Transportation is currently the largest producer of energy-related CO₂ emissions, accounting for 24%. This demand is expected to grow all across the world and in Switzerland in the coming decades as the global population increases, incomes rise, and more people can afford cars, trains, and flights.

The way cities are structured has multiple impacts, including their level of ability to adapt to climate -change. We are seeing emerging urban models, like the 15-minute city, that promote a human-centric and environmentally sustainable urban future. Mobility must be rethought.

The Swiss mobility paradigm is a key societal behavior that will benefit from innovative urban models and smart cities. To facilitate officials’ planning and decision-making process to improve the daily lives of citizens, it is crucial to monitor and collect data (sensors), transport this data (network infrastructure) and analyze it (compute).  To get an understanding, with the help of innovative AI algorithms, of how the system is used.

Through innovation, the Swiss industry and Cisco Switzerland have a unique opportunity to actively shape the societal transition to a digital transformation and a green future. It will accelerate mobility, meet sustainability goals, and help adapt to a low-carbon circular economy.

Cisco has a long history of setting and achieving environmental, social and
governance (ESG) goals. We published our first Corporate Citizenship Report
in 2005, and we continue to report our emissions data annually.

Read the Cisco 2021 Purpose Report

More information can be found on our Cisco ESG Reporting Hub

The post Cisco Sustainability: Committed to Powering an Inclusive Future for All appeared first on Cisco Switzerland Technology Blog.

At the moment, energy efficiency and sustainability are probably the number one topic across Europe or even worldwide. In general, the Cisco Catalyst 9000 Switches have multiple benefits regarding energy efficiency like platinum-rated power supply which are more efficient and lowering operating power costs or supporting features like Energy Efficient Ethernet (EEE) which is an IEEE 802.3az standard that is designed to reduce power consumption in Ethernet networks during idle periods.

However, there is not a single day a customer is asking how they can reduce the power consumption of their network. This led me to write this blog post.

The challenge

We started brainstorming in our team what we could do with our technology to help our customers. One idea was the optimized cooling of server or network cabinets with the help of Cisco Meraki Sensors, another idea was to disable devices which are powered with PoE during off business hours. That’s exactly what I’m already doing at home for some of my APs. At home I’m using a simple Embedded Event Manager applet on my Catalyst Switch to disable PoE on all my switch ports. So I took that as a starting point. Let’s look at the Embedded Event Manager on the Catalyst Switches in general:

Cisco IOS Embedded Event Manager

Cisco IOS ® Embedded Event Manager (EEM) is a unique subsystem within Cisco IOS Software. EEM is a powerful and flexible tool to automate tasks and customize the behavior of Cisco IOS Software and the operation of the device. Customers can use EEM to create and run programs or scripts directly on a router or switch. The scripts are referred to as EEM policies and can be programmed using a simple Command-Line-Interface (CLI)-based interface or using a scripting language called Tool Command Language (Tcl). EEM allows customers to harness the significant intelligence within Cisco IOS Software to respond to real-time events, automate tasks, create customized commands, and take local automated action based on conditions detected by the Cisco IOS Software itself.

The Solution

Besides running scripts based on events it’s also possible to use cron job based event timers. This gives us the possibility to run a script at a specific time. My goal is to run a script at 7 pm to disable PoE on switch interfaces with a specific description. The reason for that could be that some of the interfaces still needs PoE for emergency phones. So in my example I decided to use the word of PowerSave in the interface description to disable PoE during off business. This brings me to the following EEM script:

event manager applet EnablePowerSave
event timer cron cron-entry "0 19 * * *"
action 1.0 set _interface_counter "0"
action 1.1 cli command "enable"
action 1.2 info type interface-names include "Ethernet"
action 1.3 foreach _interface "$_info_interface_names"
action 2.2 cli command "show run interface $_interface | i description"
action 2.3 string match nocase "*PowerSave*" "$_cli_result"
action 2.5 if $_string_result ge "1"
action 3.1 cli command "conf t"
action 3.2 cli command "interface $_interface"
action 3.3 cli command "power inline never"
action 3.4 cli command "end"
action 3.5 increment _interface_counter 1
action 3.6 end
action 4 end
action 4.1 puts "PoE disabled on $_interface_counter Interface(s) by PowerSaverEEM"
action 4.2 syslog priority critical msg "PoE disabled on $_interface_counter Interface(s) by PowerSaverEEM"

Let’s look under the hood:

event manager applet EnablePowerSave

this is the name of the applet

event timer cron cron-entry "0 19 * * *"

This means the the applet will be triggered by a timer every day at 7 pm.

action 1.0 set _interface_counter "0"

This will set variable _interface_counter to the value 0. I will use that to count the number of interfaces where PoE will be disabled.

action 1.1 cli command “enable”

For the upcoming cli commands we need to be in enable mode.

action 1.2 info type interface-names include "Ethernet"

To obtain interface names when an Embedded Event Manager (EEM) applet is triggered, use the action info type interface-names command in applet configuration mode. With the include command we can limit it to Ethernet interfaces and filter other interfaces like Loopback interfaces.

action 1.3 foreach _interface "$_info_interface_names"

To specify the iteration of interface names using the delimiter as a tokenizing pattern.

action 2.2 cli command “show run interface $_interface | i description”
action 2.3 string match nocase “*PowerSave*” “$_cli_result”
action 2.5 if $_string_result ge “1”

Using those actions to filter for interfaces with “PowerSave” in the description.

action 3.1 cli command "conf t"
action 3.2 cli command "interface $_interface"
action 3.3 cli command "power inline never"
action 3.4 cli command "end"

If the Value PowerSave was found we will disable PoE.

action 3.5 increment _interface_counter 1
action 3.6 end
action 4 end
action 4.1 puts "PoE disabled on $_interface_counter Interface(s) by PowerSaverEEM"
action 4.2 syslog priority critical msg "PoE disabled on $_interface_counter Interface(s) by PowerSaverEEM"

Counting the number of interfaces where PoE gets disabled and send a message to the console and via syslog.

Enabling PoE again

And on the other side at 7 am during weekdays I will enable PoE again:

event manager applet DisablePowerSave
event timer cron cron-entry "0 7 * * 1-5"
action 1.1 cli command "enable"
action 1.2 info type interface-names include "Ethernet"
action 1.3 foreach _interface "$_info_interface_names"
action 2.2 cli command "show run interface $_interface | i description"
action 2.3 string match nocase "*PowerSave*" "$_cli_result"
action 2.4 puts "$_interface $_cli_result $_string_result"
action 2.5 if $_string_result ge "1"
action 3.1 cli command "conf t"
action 3.2 cli command "interface $_interface"
action 3.3 cli command "no power inline never"
action 3.4 cli command "end"
action 3.5 increment _interface_counter 1
action 3.6 end
action 4 end
action 4.1 puts "PoE enabled on $_interface_counter Interface(s) by PowerSaverEEM"
action 4.2 syslog priority critical msg "PoE enabled on $_interface_counter Interface(s) by PowerSaverEEM"

Both scripts can be deployed to your network with the help of Cisco DNA Center and a CLI template:

Additional information

• EEM Script on GitHub
• Cisco Meraki Sensors
• Cisco IOS Embedded Event Manager Command Reference
• Catalyst 9000 sustainability
• Configuring EEE
• Smart Buildings with Cisco Catalyst 9000 Switches Certified Green Testing – Miercom Certified Green

The post Energy reduction on Cisco Catalyst Series Switches appeared first on Cisco Switzerland Technology Blog.