Ai4 2024, the biggest AI industry event in North America, will bring together thousands of technology innovators and executives in Las Vegas, and we sat down with four experts for a behind-the-scenes look at what they’ll cover in their sessions and how Cisco is driving AI forward. 

​[[ Room: 111 

In prep for the big event, we sat down with these experts for a behind-the-scenes look at what they’ll cover in their sessions and how Cisco is driving AI forward.  

AI for faster detection and response: Jeff Wiedemann’s take

Jeff Wiedemann is a Technical Marketing Engineer at Cisco, focused on AI for Splunk. Jeff, a self-proclaimed nerd, works to ensure that Cisco’s products meet customer needs and are effectively communicated to the market. We talked to Jeff to learn more about the role AI plays in enhancing observability.  

How does AI help with monitoring systems and fixing issues faster?   

Jeff: As businesses grow, their environments become more complex—more services to monitor, more data to analyze, and more potential failure scenarios. This leads to tool sprawl and blind spots, which can make monitoring and responding effectively a real challenge.  

Splunk’s AI-driven solutions suggest solutions you might not have considered, and offer next steps based on real-time data analysis. This means you can quickly detect and resolve problems.  

Our AI approach is tailored specifically to your domain and takes full advantage of Splunk’s security and observability capabilities. We always keep a human in the loop to enhance decision-making, ensuring that AI supports rather than replaces human judgment. Plus, our platform is open and flexible, so you can customize and extend AI models to fit your unique needs. By using advanced AI, Splunk helps you cut through the noise to find the signals that matter so you are better equipped to withstand and quickly recover from digital disruptions.  

What’s the best way to start integrating AI-driven solutions into your ecosystem? 

Jeff: Start small and focus on specific pain points rather than trying to overhaul your entire system at once. Look for AI solutions that are ready to use, tailored to your industry, and easy to extend. These can solve common issues and provide immediate value without requiring a dedicated data science team. 

For example, you could improve your incident response by moving toward a more proactive approach. Quick wins might include things like using machine learning (ML) for anomaly detection and analyzing historical trends to make your alerts more accurate. Using solutions with advanced AI and ML built in throughout the incident response workflow, such as Splunk Observability, can help you reduce your MTTD and MTTR in every step. 

Deploying GenAI: Tips from Tushar Agrawal

Tushar Agrawal is the Senior Director of Product Management for Generative AI at Outshift, which is Cisco’s incubation engine that turns bold ideas into tomorrow’s tech. While Cisco connects and protects the world’s tech, Outshift explores emerging technologies, creating powerful solutions for IT visionaries in GenAI, quantum computing, cloud native, and beyond. 

What are some best practices or things to watch out for when deploying GenAI technologies? 

Tushar: According to the 2024 Cisco AI Readiness Index, 61% of companies believe they have one year or less to implement their AI strategies before facing negative business consequences from falling behind. To stay agile, it’s important to start small and scale quickly. Avoid getting bogged down in endless planning; instead, initiate a pilot project to gauge the waters. This allows you to determine what works and what requires adjustments. It’s also important to evaluate multiple models because different large language models (LLMs) can be better suited to different tasks. Experiment with multiple models to find the best fit for your needs.  

How can IT and business teams speed up the delivery of GenAI capabilities to maximize value?  

Tushar: Begin by initiating pilot projects to test and refine your approach. Share your successes across the organization to inspire others and foster a culture of GenAI innovation. Regular showcases that involve various departments can spark new ideas and collaborations, leading to innovative business practices. This way, you can scale quickly and effectively while keeping everyone motivated and engaged.  

Driving clearer speech, audio, and visual experiences: Chris Rowen’s vision 
 

Chris Rowen is a Silicon Valley entrepreneur and technologist known for his groundbreaking work developing RISC microprocessors, domain-specific architectures and deep learning-based software. As Vice President of Engineering for Webex Collaboration AI, Chris leads an engineering and product team focused on building smarter, clearer and more seamless speech, audio, visual and relationship intelligence experiences.  

How do you understand and apply AI techniques to natural language, audio, and video? 

Chris: You build an intuitive understanding by developing and deploying AI solutions. Not only does Cisco Collaboration have deep experience in building its own world-class audio, video, speech, and language models from scratch, but our AI team has worked with every product line in Collaboration to help engineers grasp the underlying science and to navigate the critical application choices.   

By paying attention to these three core principles, engineering teams can make widely productive customer use-cases, not just showy demos:  

Start with quantitative targets of success in customer experience.  
Ensure the data used to train and test the AI model fully represents the users you serve.  
Iterate with the models and the application of models until the behavior doesn’t just make a flashy first impression, but actually fulfills the customer’s need. 

What are the risks of using LLMs like ChatGPT, and how can they be managed in team communication and collaboration? 

Chris: LLMs are remarkably versatile and clever, but they are trained more to deliver a plausible answer than necessarily to provide correct results for YOUR query.   

Their statistical models naturally gravitate towards conventional, boring prose responses. The quality of answers is only as good as the inputs data they’re given, so if under-supplied with facts, they invent new ones. They can propagate the bias of the data they’re built with, putting some groups of users at a systematic disadvantage. If improperly managed and protected, they can leak private data to the model host. 

The superficial brilliance of LLM responses can lull users into excessive confidence in model infallibility, unless the LLM is carefully prompted, fine-tuned, and monitored. 

AI-driven security innovations: DJ Sampath’s perspective

DJ Sampath is a software engineer turned founder and CEO. He co-founded and was the CEO of Armorblox, which was later acquired by Cisco. He also helped found StackRox (now RedHat), where he served as Chief Architect and VP of Engineering. He now serves as Cisco’s VP of AI Products.  

How is Cisco using machine telemetry at scale?
 

DJ: Cisco is using machine telemetry at an unprecedented scale to gain AI-driven insights. We have a “security meets the network” advantage, which gives us access to billions of endpoints and devices and provides an unparalleled foundation for capturing real-time data from applications, networks, security events, and the broader internet.  

Using data from Cisco and Splunk, we process and analyze trillions of data points daily with AI and machine learning algorithms. This helps us proactively identify and mitigate security threats, optimize network performance, enhance application experiences, and better understand user behavior and trends. 

How do AI-driven insights contribute to simpler security and better user experiences? 

DJ: Cisco’s AI-first approach to security is transforming how we protect organizations and improve user experiences. We use AI to proactively detect and respond to threats early, simplifying security operations and reducing the risk of breaches. By analyzing trillions of data points, our AI algorithms spot anomalies and potential threats, allowing us to identify and counteract zero-day attacks before they can do any damage. 

Our AI-powered tools speed up incident response by automatically correlating security events and triggering pre-defined actions. This makes security measures seamless and unobtrusive, which improves the user experience without compromising safety. 

What innovations are being enabled through the integration of AI in security? 
 

DJ: Our commitment to AI innovation is delivering cutting-edge solutions in behavioral analytics, anomaly detection, threat intelligence, automated response, and natural language processing in response to constantly evolving threats. The bad actors never stop, so we’re always vigilant and proactive in developing technologies and solutions that adapt and improve continuously. Ultimately, this enhances security posture and improves user experiences in an integrated manner. 

Meet the experts and learn more 

Attend our sessions at Ai4 to hear from our experts live. Visit our two booths (Outshift in #220 and Splunk in #609) to see Cisco AI solutions in action. We can’t wait to see you there!  

"]]  Ai4 2024, the biggest AI industry event in North America, will bring together thousands of technology innovators and executives in Las Vegas, and we sat down with four experts for a behind-the-scenes look at what they’ll cover in their sessions and how Cisco is driving AI forward.   Read More Cisco Blogs 

Hybrid work models are not just about flexibility — they are integral to advancing sustainability and inclusivity in the workforce.

​[[{"value":"

Do you feel a bit lost when people refer to certain environmental sustainability topics and aren’t sure where to start when it comes to learning more? Sustainability 101 is a blog series that you can turn to for information about different environmental terms that may come up at work, during discussions with friends, and even at your annual holiday gathering.

“The Gartner®1Q24 Global Labor Market Survey found that 44% of workers worldwide have a hybrid work model, outnumbering the 39% of workers who work full-time in the office full-time.”*

Hybrid work is a model that combines in-office and remote work. Some companies set specific days for on-site work, while others allow employees to manage their own schedules. Hybrid work models can be associated with less frequent commutes which can lower emissions from motor vehicles.

But hybrid work can also be a key factor in advancing sustainability in the workforce — helping to create workplace environments where employees are healthy, engaged, and productive.

These practices can be a key component of a company’s overall environmental, social, and governance (ESG) program, which often includes the well-being and development of employees.

Let’s explore hybrid work trends and how these models can foster inclusive and productive workforces.

From Perk to Expectation

While flexible work models have been around for a while, remote work became commonplace during the pandemic, which led to the increased popularity of hybrid work. Many employees prefer a hybrid approach versus a full-time return to the office, seeing it as a way to support their work-life balance and general well-being.

Meanwhile, employers are also finding that flexible work models can be an important way to attract, support, and retain employees.

In a 2022 Cisco Global Hybrid Work Study, 28,000 full-time employees across 27 markets were surveyed and conveyed support for hybrid work with a collaborative approach:

62% of employees agree that their ability to work from anywhere impacts whether they stay at or leave a job
61% believe their quality of work has improved
60% have seen their productivity increase

How Cisco Powers Hybrid Work

At the heart of successful hybrid work is collaborative technology that reaches corporate headquarters and home offices — from video conferencing to messaging applications to real-time document sharing.

For example, with its market-leading platform composed of Webex, AnyConnect VPN and ThousandEyes, Cisco is providing a secure way for millions of people to work from home daily.

A Cisco-enabled remote work environment can also include a Cisco Desk Pro, a dedicated video desk device with three times the screen size of an average PC, which delivers a high-quality meeting experience. It helps make calls engaging and keeps them from becoming fatiguing– no eye squinting to see small talking heads on a small PC screen.

For office environments, Cisco can unlock sustainability potential and optimize workplaces through its Smart Building solutions that can automate workplace environments, improve space, and lower costs. By using Power over Ethernet (PoE) technology and connected Heating, Ventilation, Air-Conditioning (HVAC), security, and occupancy systems, companies can gain actionable, timely insights into building resource availability, occupancy, and energy usage.

Not only do these solutions support more sustainable hybrid work, but many of the products themselves are built with sustainability in mind.

For example, the Cisco Room Bar, a video device for office meeting rooms, was created with a circular design approach. The number of internal components was reduced by 16 tons per year, and the packaging volume was reduced by 44 percent by removing foam. The product itself has been designed to be easier to repair, refurbish, and recycle.

Cisco is applying principles like this to its whole portfolio. In fact, Cisco has set a goal that 100 percent of its new products and packaging will incorporate Circular Design Principles by its fiscal year 2025.

The Importance of Inclusivity and Productivity in a Hybrid Work Model

Cisco’s purpose is to power an inclusive future for all. Supporting hybrid and inclusive work environments — where everyone, regardless of background or circumstance, feels valued and can contribute fully — is a key aspect of the company’s purpose.

For example, Webex enhances inclusivity with features like real-time translation, closed captions, and post-meeting recaps.

Cisco is now applying industry-leading AI to further address frustrations with background noise, poor sound, and low video quality. The goal is to make it feel as if there is no real distance between colleagues, and that each participant, regardless of location, is able to fully and effectively participate.

Guiding Principles and the Future of Hybrid Work

According to an IDC study, nearly half of organizations prioritize maintaining flexible work models in order to support their transformation efforts.

Despite the momentum and prioritization of hybrid work, many organizations struggle to implement effective strategies. According to a McKinsey 2024 survey, 68 percent of organizations do not yet have detailed plans about how to handle hybrid work.

Hybrid work models can vary by region, industry, company and even business units, creating complexities for both workers and managers. It can be a new way of thinking that spans company culture, processes, and technology. Ultimately, it requires a strategic and thoughtful approach from multiple stakeholders across an organization.

Cisco’s mindset, as stated by our president and CEO Chuck Robbins is that “The office is a magnet, not a mandate.”

Hybrid work models are not just about flexibility — they are integral to advancing sustainability and inclusivity in the workforce. By leveraging advanced technology and strategic planning, companies can foster environments where employees thrive and contribute to broader sustainability goals.

Hybrid work is becoming more mainstream, and many organizations are looking for ways to achieve better outcomes. For me personally, since I began using a dedicated Webex device for managing all my remote conferencing, I have re-energized my productivity and increased my job satisfaction.

For guidance on how to take hybrid work from a ‘great experiment’ to a cornerstone of sustainability and productivity, check out Cisco’s Mastering Hybrid Work.

*Gartner, Quick Answer: Evaluating Microsoft Places for Hybrid Work Challenges, Tori Paulman, Christopher Trueman, 8 July 2024

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

"}]]  Hybrid work models are not just about flexibility — they are integral to advancing sustainability and inclusivity in the workforce.  Read More Cisco Blogs 

The upcoming implementation of the EU NIS2 Directive requires a reassessment of operational and technical security goals. Learn more about how Cisco CX helps bridge that gap and aid you in navigating these new challenges.

​[[{"value":"

Most companies acting in the European Union (EU) responsible for their own, or other, critical infrastructures already have stringent processes and procedures triggered by national and industry regulations and through implementing industry standards like IEC 62443 and IEC 62351.

However, new and evolving regulations, like the upcoming implementation of the EU NIS2 Directive in each EU Member State, force companies to reassess the current state of their organizational, operational, and technical security controls, along with their compliance readiness.

The new EU NIS2 directive is targeted for incorporation into local legislation for EU members on October 17, 2024. The pace is picking up for companies to assess how their business is touched by this directive, its legal and organizational impact, and their level of readiness and compliance.

On a tactical level, they must ask themselves questions like these to form an actionable and prioritized improvement plan:

Is what we know to be in the infrastructure correct? Do I have proper insights into my assets and communication paths and any vulnerabilities?
Have I mapped the communication flows to the right business applications? Do I know the interdependencies of the assets and application flows?
Do I have insight into the criticality of my assets, the business applications, and the financial impact on my business if a communication flow is interrupted? In case of a critical event, can I keep (other) operations going?
Is this criticality properly reflected in my end-to-end monitoring, event management, and service management tools to trigger the proper remediation and resolution processes?
Is my Security Incident Management process working? Does everyone know their role and how is communication shared between teams? Is there a single owner and coordinator? Have we tested the process?
How do we track internal and external staff access to devices and the work they perform? Is access based on roles and only to applications and parts of the network that are relevant for their role?

To be able to answer these questions, most organizations start by trying to get an understanding of how good or bad their knowledge of their current infrastructure is: You don’t know what you don’t know, but how much do I not know? Infrastructures in quite a few cases have grown organically with added parts, often siloed, by teams with different goals and responsibilities operating all too frequently in isolation. This seems to be especially true for companies where Operational Technology (“OT”) and Information Technology (“IT”) infrastructures and functions are converging.

A frequent starting point is an assessment to provide visibility into the assets deployed in the infrastructure and to compare these findings with asset databases. This will not only provide data on gaps in knowledge but also the functioning of processes like Change Enablement, Release Management, and Deployment Management.

During these assessments communication paths are captured. Mapping these paths to business applications and processes helps identify the business impact of cybersecurity attacks and outages. Understanding the criticality of business processes and the underlying applications, communication flows and infrastructure allows critical components to be identified and separated from less critical ones. Network segmentation and security zoning are key components of the IEC 62443 standard. In case of a security attack, operational business impact is restricted to specific parts of the infrastructure while keeping operations running in the unaffected areas.

Understanding critical business applications and how they communicate over the infrastructure not only helps restrict and contain security attacks; it also supports the review and optimization of the operational Incident Management and Change Enablement procedures. For example, if the communication paths all go through a single point, troubleshooting and resolving an issue on that component could result in a shutdown or reboot impacting all application data streams and processes running over this component. By untangling these flows, downtime as the result of planned proactive and preventive maintenance or unplanned reactive maintenance can be reduced.

The most crucial outcome of these assessments though is the identification of the risk exposure. For each identified asset, the vulnerability level will be determined against known vulnerabilities and threats. Combining this level with asset criticality, remediation actions can be planned and executed to reduce the overall exposure.

Additional operational assessments can include assessing the Security Incident Management processes and their effectiveness through tabletop exercises, and the configuration and integration of the supporting monitoring, Security Information and Event Management (“SIEM”), and Service Management systems. Common optimization areas are the mapping of event and incident severities to the criticality of the assets and how this is configured in integrated systems and platforms (or the lack thereof), but foremost is the functioning and effectiveness of the Security Incident Management process: Have the flows and procedures been tested end-to-end? Does everyone know these processes and procedures and their roles in them? What should be communicated between teams and who should be informed, especially in case of company-brand impacting events?

Another process with more emphasis on NIS2 is related to role-based controlled and tracked access. In a world where remote operations and applications hosted in the Cloud, even in the OT domain, become more and more dominant, restricting and controlling access to data and assets to only those that should have access is increasingly becoming more important. Again, this doesn’t limit itself to applications like Cisco Secure Equipment Access, but also the processes around defining the access levels, granting access, and monitoring activities performed. Operational assessments will help identify the status of such controls and any potential areas of optimization.

Understanding the risk exposure and responding to vulnerabilities is a continuous process. New threats will appear. Becoming aware of them, assessing their impact, and defining remediation plans as soon as possible is therefore crucial. Intelligence-led proactive cybersecurity services like Cisco’s Talos threat intelligence research organization will inform you quickly about the risk posed by newly discovered threats. However, to respond to the threat and implement remediation quickly still requires often going through an expedited release, test, and deployment procedure. This means the proper processes and procedures will need to be in place. For less critical releases and fixes, the more standard release and deployment management processes can be followed.

The NIS2 Directive is not only about becoming compliant, but also remaining compliant after implementation. This can be achieved through regularly reassessing and measuring improvements.

Acting as the bridge between strategy definition and tactical execution, Cisco is ideally positioned to share best practices with its customers and partners. Its “infrastructure up” approach augments strategy-orientated assessments with practical recommendations on how to prioritize and act on the findings of such assessments. These vendor-agnostic recommendations leverage the extensive Cisco Services experience built up over the years through advising, designing, and optimizing secure and scalable critical infrastructures, not only from a technology perspective but also from a process and people angle. Technology cannot be seen separated from the business operations and the people using it; they feed into one another.

Through a wide range of assessment, design, implementation, and lifecycle services, Cisco Services support customers on their compliance readiness journey, identifying the current security risk exposure and controls maturity gaps along with the effectiveness of security-related processes and procedures; all of which serve as a basis to translate the findings and recommendations into actionable items that can be prioritized based on business impact and available budget and resources.

Cisco Customer Experience (CX) in EMEA has brought together a team of subject matter experts with a background in utilities and other industrial domains such as oil, gas, and manufacturing. The Cisco CX EMEA Center of Excellence for Utilities Digitization assists industrial organizations with their energy digitization and transformation journeys by sharing their experiences, industry trends, and peer-to-peer priorities.

Want to learn more about how Cisco can assist you? Contact your Cisco Services Sales Specialist or email the Cisco CX EMEA Center of Excellence for Utilities Digitization. Of course, you’re welcome to simply comment below as well. I look forward to hearing your thoughts.

"}]]  The upcoming implementation of the EU NIS2 Directive requires a reassessment of operational and technical security goals. Learn more about how Cisco CX helps bridge that gap and aid you in navigating these new challenges.  Read More Cisco Blogs 

One university is using reliable and easy-to-deploy LoRaWAN technology to spur innovation in rural America. We reveal how in our latest blog.

​[[{"value":"

In areas dominated by small towns and farming, the ability to leverage innovative technologies is not always present. But for residents of Eastern North Carolina a different future is taking shape. As the region faces the multiple challenges of income inequality, elevated unemployment, and migration of youth to larger cities, a new and sustainable solution has emerged. One driven by a reliable and easy-to-deploy technology that can enable new opportunities for economic and educational development.

For Dr. Ciprian “Chip” Popoviciu, the use of LoRaWAN (long-range wide-area network) technology offers a unique opportunity to spur greater innovation in the Eastern North Carolina region. Known as Dr. Chip he spearheads the Center for IoT Engineering and Innovation (CIEI) in the College of Engineering at East Carolina University (ECU). Located in Greeneville, North Carolina the Center is dedicated to driving IoT adoption in the region to bolster economic development and address an array of environmental and societal challenges.

The PITON Initiative

Thanks to Dr. Chip’s vision, rural areas and small towns throughout Eastern North Carolina can now leverage innovative technologies to help improve their quality of life. CIEI’s core mission is to provide LoRaWAN connectivity for sensors alongside infrastructure for data hosting, visualization, and analysis. By doing so, users can leverage their sensor data and the Center’s resources to better understand their operations, automate workflows—and capture missed opportunities.

Building a LoRaWAN platform was a key component of a CIEI initiative known as the Platform for IoT Open Networks (PITON). Also led by Dr. Chip, PITON’s goal is to create a plug & play platform to:

Easily deploy and manage sensors
Automatically collect and curate real-time data
Access and share data
Implement workflow data.

The idea for PITON emerged from conversations with the communities in which ECU is embedded. “So much in our economy is still done manually – and inefficiently – and there is immense appetite in rural, under-connected communities to understand the art of the possible with technology,” says Dr. Chip.

“Let me provide an example related to smart farming that many in North Carolina will easily understand – the challenge of flooding. If their farms are flooded, traditionally farmers must physically drive to different locations across their land, manually measure the water levels,” related Dr. Chip. “Based on those measurements, they determine when to use pumps to collect excess water. Of course, because it is all done manually, it is extremely time intensive and inefficient.” But with LoRaWAN connected IoT sensors the work is automated and data is in real-time. This saves time, is more efficient, and improves decision making.

Currently, fourteen projects have emerged from PITON. “What makes this initiative so special is the extent to which CIEI is embedded in and working with the community to bring tangible solutions to eastern North Carolina, powered by Cisco technology” added Meghan Steele, vice president of U.S. Public Sector East at Cisco.

A sustainable approach to connecting across distances

Distance is often considered a significant challenge for some technologies but not for LoRaWAN due to its bandwidth, low power, and long distance capabilities, which helps increase signal reach up to thirty miles thanks to the region’s flat terrain. “We know Eastern North Carolina is home to many under-connected communities,” states Steele. “We’re proud that our technology is providing connectivity across approximately 1,500 square miles to unlock increased opportunity and economic development.”

As home to a low-lying coastal geography dotted with inlets, wetlands, and lowlands, Eastern North Carolina is much more susceptible to damage during hurricanes and flooding. That’s why CIEI is targeting the water and land management potential of the technology, as well as air quality. But the unique natural environment also presents great opportunities for the region’s economy, allowing CIEI to explore connectivity for sensor data at offshore wind farms thanks to North Carolina’s extensive coast.

CIEI is also seeking to enhance the sustainability of communities through its LoRaWAN approach. Sensors can lower the barrier of entry for users and limit environmental and wildlife impacts by reducing maintenance, travel, and pollutants. Plus, the data collected provides a baseline for monitoring environmental conditions.

LoRaWAN is helping build better communities

CIEI seeks to use LoRaWAN as a way to improve community engagement among residents living in the many rural areas and towns of the region. By educating and training local communities on the benefits of IoT, they are helping local leaders and residents understand the benefits of adopting new technologies, increasing willingness to adopt digital services.

According to Dr. Chip “The students that work on this initiative truly have their eyes opened to the power of technology.” The LoRaWAN infrastructure gives them a platform for research projects focusing on IoT and data analytics. He added, “There’s a direct tie to workforce development and opportunity, as students see a path for a career, for entrepreneurship directly impacting rural communities.”

Steele added that “The partnership between communities, researchers, educators, and the private sector is having a significant impact in eastern North Carolina, and Chip’s innovation and the model he has spearheaded has the potential to be replicated across the U.S.

Additional resources on LoRaWAN

How Cisco LoRaWAN solutions connect the unconnected
How to pick the right wireless technology for your needs
Innovative technologies for Higher Education

"}]]  One university is using reliable and easy-to-deploy LoRaWAN technology to spur innovation in rural America. We reveal how in our latest blog.  Read More Cisco Blogs 

See how to set up a working Auto-VPN architecture in a multi-cloud environment (AWS and Google Cloud). This guide provides actionable steps and techniques for designing and deploying Meraki vMX in a multi-cloud environment.

​[[{"value":"

Try this hands-on learning lab:Learn how to use Terraform with Cisco Meraki

As the Meraki Auto-VPN network becomes widely adopted for on-premises environments, the natural next step for customers will be to extend their automated SD-WAN network into their public cloud infrastructure.

Most organizations have different levels of domain expertise among engineers—those skilled in on-premises technologies may not be as proficient in public cloud environments, and vice versa. This blog aims to help bridge that gap by explaining how to set up a working Auto-VPN architecture in a multi-cloud environment (AWS and Google Cloud). Whether you’re an on-premises network engineer looking to explore cloud networking or a cloud engineer interested in Cisco’s routing capabilities, this guide will provide actionable steps and techniques. While this blog focuses on multi-cloud connectivity, learning how to set up vMX Auto-VPN in the public cloud will prepare you to do the same for on-premises MX devices.

Multi-Cloud Auto-VPN Objectives

The goal for this Proof-of-Concept (POC) is to conduct a successful Internet Control Message Protocol (ICMP) reachability test between the Amazon EC2 test instance on the AWS private subnet and the Compute Engine test instance on Google Cloud using only its internal IP address. You can use this foundational knowledge as a springboard to build a full-fledge design for your customers or organization.

Using a public cloud is a great way to conduct an Auto-VPN POC. Traditionally, preparing for Auto-VPN POCs requires at least two physical MX appliances and two IP addresses that are not CGNAT-ed by the carrier, which can be difficult to acquire unless your organization has IPs readily available. However, in the public cloud, we can readily provision an IP address obtained from the public cloud provider’s pool of external IP addresses.

For this POC, we will use ephemeral public IPv4 addresses for the WAN interface of the vMX. This means that if the vMX is shut down, the public IPv4 address will be released, and a new one will be assigned. While this is acceptable for POCs, reserved public IP addresses are preferred for production environments. In AWS, the reserved external IP address is called Elastic IP, and in Google Cloud, this is called an external static IP address.

Prepare the AWS Environment

First, we will prepare the AWS environment to deploy the vMX, connect it to the Meraki dashboard, and set up Auto-VPN to expose internal subnets.

1. Create the VPC, Subnets, and Internet Gateways

In the AWS Cloud, private resources are always hosted in a Virtual Private Cloud (VPC). In each VPC, there are subnets. The concept of subnets is similar to what many of us are familiar with in the on-premises world. Each VPC must be created with an IP address range (e.g., 192.168.0.0/16) and the subnets that live inside this VPC must share this range. For example, subnet A can be 192.168.1.0/24 and subnet B can be 192.168.2.0/24. Internet Gateway (IGW) is an AWS component that provides internet connectivity to the VPC. By adding IGW to the VPC, we are allocating the resource (e.g., internet connectivity) to the VPC. We have not yet allowed our resources to have internet reachability.

As shown below, we will create a VPC (VPC-A) in the US-East-1 region with a Classless Interdomain Routing (CIDR) range of 192.168.0.0/16.

Next, we will create two subnets in VPC-A, both having IP addresses from VPC-A’s 192.168.0.0/16 range. A-VMX (subnet) will host the vMX and A-Local-1 (subnet) will host the EC2 test instance to perform the ICMP reachability test with Google Cloud’s Compute Engine over Auto-VPN.

We will now create an IGW and attach it to VPC-A. The IGW is needed so the vMX (to be deployed in a later step) can communicate to Meraki dashboard over the internet. The vMX will also need the IGW to establish Auto-VPN connectivity over the internet with the vMX on Google Cloud.

2. Create Subnet-Specific Route Tables

In AWS, each subnet is associated with a route table. When traffic leaves the subnet, it consults its associated route table to look for the next-hop address for the destination. By default, each newly created subnet will share the VPC’s default route table. In our Auto-VPN example, the two subnets cannot share the same default route table because we need granular control of individual subnet traffic. Therefore, we will create individual subnet-specific route tables.

The two route tables shown below are each associated with a corresponding subnet. This allows traffic originating from each subnet to be routed based on its individual route table.

3. Configure the Default Route on Route Tables

In AWS, we must explicitly configure the route tables to direct traffic heading toward 0.0.0.0/0 to be sent to the IGW. Subnets with EC2 test instances that require an internet connection will need their route tables to also have a default route to the internet via the IGW.

The route table for A-VMX (subnet) is configured with a default route to the internet. This configuration is necessary for the vMX router to establish an internet connection with the Meraki dashboard. It also enables the vMX to establish an Auto-VPN connection over the internet with Google Cloud’s vMX in a later stage.

For this POC, we configured the default route for the route table A-Local-1 (subnet). During the ICMP reachability test, our local workstation will first need to SSH into the EC2 test instance. This will require the EC2 test instance to have an internet connection; therefore, the subnet it resides in needs a default route to the internet via the IGW.

4. Create Security Groups for vMX and EC2 Test Instances

In AWS, a security group is similar to the concept of distributed stateful firewalls. Every resource (i.e., EC2 and vMX) hosted in the subnet must be associated with a security group. The security group will define the inbound and outbound firewall rules to apply to the resource.

We created two security groups in preparation for the vMX and the EC2 test instances.

In the security group for the EC2 test instance, we need to allow SSH from your workstation to establish connection with and allow inbound ICMP from Google Cloud’s Compute Engine test instance for the reachability test.

On the security group for vMX, we only need to allow inbound ICMP to the vMX instance.

The Meraki dashboard maintains a list of firewall rules to enable vMX (or MX) devices to operate as intended. However, because the firewall rules specify outbound connections, we generally do not need to modify the security groups. By default, security groups allow all outgoing connections, and as a stateful firewall, outgoing traffic will be allowed inbound even if the inbound rules do not explicitly allow it. The only exception is ICMP traffic, which requires an inbound security rule to explicitly allow the ICMP traffic from the indicated sources.

Deploy vMX and Onboard to Meraki Dashboard

On your Meraki dashboard, ensure that you have sufficient vMX licenses and create a new security appliance network.

Navigate to the Appliance Status page under the Security & SD-WAN section and click Add vMX. This action informs the Meraki cloud that we intend to deploy a vMX and will require an authentication token.

The Meraki dashboard will provide an authentication token, which will be used when provisioning the vMX on AWS. The token will inform the Meraki dashboard that the vMX belongs to our Meraki organization. We will need to save this token safely somewhere to be used in the later stage.

We can now deploy the vMX via the AWS Marketplace. Deploy the vMX using the EC2 deployment process.

As part of this demonstration, this vMX will be deployed in A-VPC (VPC), in the A-VMX (subnet), and will be automatically assigned a public IP address. The instance will also be associated to the SG-A-VMX security group created earlier.

In the user data section, we will paste the authentication token (which was copied earlier) into this field. We can now deploy the vMX.

After waiting a few minutes, we should see that the vMX instance is up on AWS and the Meraki dashboard is registering that the vMX is online. Note that the WAN IP address of the vMX corresponds to the public IP address on the A-VMX instance.

Ensure that the vMX is configured in VPN passthrough/concentrator mode.

Disable Source and Destination Check on the vMX Instance

By default, AWS does not allow their EC2 instance to send and receive traffic unless the source or destination IP address is the instance itself. However, because the vMX is performing the Auto-VPN function, it will be handling traffic where the source and destination IP addresses are not the instance itself.

Selecting this check box will allow the vMX’s EC2 instance to route traffic even if the source/destination is not itself.

Understand How Traffic Received from Auto-VPN is Routed to Local Subnets

After the vMX is configured in VPN concentrator mode, the Meraki dashboard no longer allows (or restricts) the vMX to only advertise subnets that its LAN interfaces are connected to. When deployed in the public cloud, the vMXs do not behave the same as MX hardware appliances.

The following examples show the Meraki Auto-VPN GUI when the MX is configured in routed mode.

For an MX appliance operating in routed mode, the Auto-VPN will detect the LAN-facing subnets and only offer these subnets as options to advertise in Auto-VPN. In most cases, this is because the default gateway of the subnets is hosted on the Meraki MX itself, and the LAN ports are directly connected to the relevant subnets.

However, in the public cloud, vMXs do not have multiple NICs. The vMX only has one private NIC and it is associated to the A-VMX (subnet) where the vMX is hosted. The default gateway of the subnet is on the AWS router itself rather than the vMX. It is preferable to use VPN concentrator mode on the vMX because we can advertise subnets across Auto-VPN even if the vMX itself is not directly connected to the relevant subnets.

As shown in the network diagram below, the vMX is not directly connected to the local subnets and the vMX does not have additional NIC extended into the other subnets. However, we can still allow Auto-VPN to work using the AWS route table, which is the same route table associated to the A-VMX (subnet).

Assuming Auto-VPN is established and traffic sourcing from Google Cloud’s compute instance is attempting to reach AWS’s EC2 instance, the traffic has now landed on the AWS vMX. The vMX will send the traffic out from its only LAN interface even if the A-VMX (subnet) is not the destination. The vMX will trust that traffic coming out from its LAN interface and onto the A-VMX subnet will be delivered appropriately to its destination after consulting the A-VMX (subnet) route table.

The A-VMX’s route table has only two entries. One matches the VPC’s CIDR range, 192.168.0.0/16, with a target of local. The other is the default route, sending traffic for the internet via the IGW. The first entry is relevant for this discussion.

The packet sourcing from Google Cloud via Auto-VPN is likely to be destined for A-Local-1 (subnet), which falls within the IP range 192.168.0.0/16.

(Illustrated solely for the purpose of understanding the concept of VPC Router)

All subnets on AWS created under the same VPC can be natively routed without additional configuration on the route tables. For every subnet that we create, there is a default gateway, which is hosted on a virtual router known as the VPC router. This router hosts all the subnets’ default gateways under one VPC. This enables packet sourcing from Google Cloud via Auto-VPN, destined for A-Local-1 (subnet), to be routed natively from A-VMX (subnet). The entry 192.168.0.0/16 with a target “local” means that inter-VLAN routing will consult the VPC router. The VPC router will route the traffic to the correct subnet, which is the A-Local-1 subnet.

Prepare the Google Cloud Environment

1. Create the VPC and Subnets

In Google Cloud, private resources are always hosted in a VPC, and in each VPC, there are subnets. The concept of VPC and subnets are similar to what we discussed in AWS.

The first exception is that in Google Cloud, we do not need to explicitly create an internet gateway to allow internet connectivity. The VPC natively supports internet connectivity, and we will only need to configure the default route in the later stage.

The second exception is that in Google Cloud, we do not need to define a CIDR range for the VPC. The subnets are free to use any CIDR range if they do not conflict with each other.

As shown below, we created a VPC named “vpc-c.” In Google Cloud, we do not need to specify the region when creating a VPC because it spans globally in contract to AWS. However, as subnets are regional resources, we will then need to indicate the region.

As shown below, we created two subnets in vpc-c (VPC), both with addresses in a similar range (although not required). For Auto-VPN, the IP range for the subnets also should not conflict with the IP ranges over at AWS networks.

c-vmx (subnet) will host the vMX and c-local-subnet-1 (subnet) host the Compute Engine’s test instance to perform the ICMP reachability test with AWS’s EC2 over Auto-VPN.

2. Review the Route Table

The following route table is currently unpopulated for vpc-c (VPC).

In Google Cloud, all routing decisions are configured on the main route table, one per project. It has the same capabilities as AWS, except all routing configurations across subnets are configured on the same page. Traffic routing policies with source and destinations will also need to include the relevant VPC.

3. Configure the Default Route on Route Tables

In Google Cloud, we need to explicitly configure the route tables to direct traffic heading to 0.0.0.0/0 to be sent to the default internet gateway. Subnets with compute instances that require internet connection will need its route table to have a default route to the internet via the default internet gateway.

In the image below, we configured a default route entry. In a later step, the vMX instance that we create will have internet outbound connectivity to reach Meraki dashboard. This is required so that vMX can establish Auto-VPN over internet connection to AWS vMX.

For this POC, the default route will also be useful during the ICMP reachability test. Our local workstation will first need to SSH into the Compute Engine test instance. This will require the Compute Engine test instance to have an internet connection; therefore, the subnet where it resides must have a default route to the internet via the default internet gateway.

4. Create Firewall Rules for vMX and Compute Engine Test Instances

In Google Cloud, VPC firewalls are used to perform stateful firewall services specific to each VPC. In AWS, security groups are used to achieve similar outcomes.

The following image shows two security rules that we created in preparation for the Compute Engine test instance. The first rule will allow ICMP traffic sourcing from 192.168.20.0/24 (AWS) into the Compute Engine with a “test-instance” tag. The second rule will allow SSH traffic sourcing from my workstation’s IP into the Compute Engine with a “test-instance” tag.

We will use network tags in Google Cloud to apply VPC firewall rules to selected resources.
In the following image, we have added an additional rule for the vMX. This is to allow the vMX to perform its uplink connection monitoring using ICMP. Although the Meraki dashboard specifies other outbound IPs and ports to be allowed for other purposes, we do not need to explicitly configure them in the VPC firewall. Traffic outbound will be allowed by default and being a stateful firewall, return traffic will be allowed as well.

As shown below, we added an additional rule for the vMX. This is to allow the vMX to perform its uplink connection monitoring using ICMP. Although the Meraki dashboard specifies other outbound IPs and ports to be allowed for other purposes, we do not need to explicitly configure them in the VPC firewall. Traffic outbound will be allowed by default and being a stateful firewall, return traffic will be allowed as well.

Deploy the vMX and Onboard to Meraki Dashboard

On your Meraki dashboard, follow the same steps as described in the previous section to create a vMX security appliance network and obtain the authentication token.

Over at Google Cloud, we can proceed to deploy the vMX via Google Cloud Marketplace. Deploy the vMX using the Compute Engine deployment process.

As shown below, we entered the authentication token retrieved from the Meraki Dashboard into the “vMX Authentication Token” field. This vMX will also be configured in the vpc-c (VPC), c-vmx (subnet), and will obtain an ephemeral external IP address. We can now deploy the vMX.

After a few minutes, we should see the vMX instance is up on Google Cloud and the Meraki dashboard is registering that the vMX is online. Note that the WAN IP address of the vMX corresponds to the public IP address on the c-vmx instance.

Unlike AWS, there is no need to disable source/destination checks on Google Cloud’s Compute Engine vMX instance.

Ensure that the vMX is configured as VPN passthrough/concentrator mode.

Route Traffic from Auto-VPN vMX to Local Subnets

We previously discussed why vMX needs to be configured in VPN passthrough or concentrator mode, instead of routed mode. The reasoning holds true even if the environment is on Google Cloud instead of AWS.

Like the vMX on AWS, the vMX on Google Cloud only has one private NIC. The private NIC is associated with the c-vmx (subnet) where the vMX is hosted. The same concept applies to Google Cloud and the vMX does not need to be directly connected to the local subnets to allow Auto-VPN to work. The solution will use on Google Cloud’s route table to make routing decisions when traffic exits the vMX after terminating the Auto-VPN.

Assuming the Auto-VPN is established and traffic sourcing from AWS’s EC2 instance is attempting to reach Google Cloud Compute Engine’s test instance, the traffic has now landed on the Google Cloud vMX. The vMX will send the traffic out from its only LAN interface even if the c-vmx (subnet) is not the destination. The vMX will trust that traffic coming out from its LAN interface and onto the c-vmx subnet will be delivered appropriately to its destination after consulting the VPC route table.

Unlike the AWS route table, there is no entry in the Google Cloud route table to suggest that traffic within the VPC can be routed accordingly. This is an implicit behavior on Google Cloud and does not require a route entry. The VPC routing construct on Google Cloud will handle all inter-subnet communications if they are part of the same VPC.

Configure vMX to Use Auto-VPN and Advertise AWS and Google Cloud Subnet

Now we will head back to the Meraki dashboard and configure the Auto-VPN between the vMX on both AWS and Google Cloud.

At this point, we have already built an environment like the network diagram below.

On the Meraki dashboard, enable Auto-VPN by configuring the vMX as a hub. You can also enable the vMX as a spoke if your design specifies it. If your network will benefit from your sites having full mesh connectivity with your cloud environment, configuring the vMX as a hub is preferred.

Next, we will advertise the subnet that sits behind the vMX. For the vMX on AWS, we have advertised 192.168.20.0/24, and for the vMX on Google Cloud, we have advertised 10.10.20.0/24. While the vMX does not directly own (or connect) to these subnets, traffic exiting the vMX will be handled by the AWS/Google Cloud routing table.

After a few minutes, the Auto-VPN connectivity between the vMX will be established. The following image shows the status for the vMX hosted on Google Cloud. You will see a similar status for the vMX hosted on AWS.

The Meraki route table below shows that from the perspective of the vMX on Google Cloud, the next-hop address to 192.168.20.0/24 is via the Auto-VPN toward vMX on AWS.

Modify the AWS and Google Cloud Route Table to Redirect Traffic to Auto-VPN

Now that the Auto-VPN configuration is complete, we will need to inform AWS and Google Cloud that traffic destined to each other will need to be directed to the vMX. This configuration is necessary because the route tables in each public cloud do not know how to route the traffic destined for the other public cloud.

The following image shows that the route table for the A-Local-1 (subnet) on AWS has been modified. For the highlighted route entry, traffic heading toward Google Cloud’s subnet will be routed to the vMX. Specifically, the traffic is routed to the elastic network interface (ENI), which is essentially the vMX’s NIC.

In the image below, we modified the route table of Google Cloud. Unlike AWS, where we can have an individual route table per subnet, we need to use attributes such as tags to identify traffic of interest. For the highlighted entry, traffic heading toward AWS’s subnet and sourcing from Compute Engine with a “test-instance” tag will be routed toward the vMX.

Deploy Test Instances in AWS and Google Cloud

Next, we will deploy the EC2 and Compute Engine test instances on AWS and Google Cloud. This is not required from the perspective of setting up the Auto-VPN. However, this step will be useful to validate if the Auto-VPN and various cloud constructs are set up properly.

As shown below, we deployed an EC2 instance in the A-Local-1 (subnet). The assigned security group “SG-A-Local-Subnet-1” has been pre-configured to allow SSH from my workstation’s IP address, and ICMP from Google Cloud’s 10.10.20.0/24 subnet.

We also deployed a basic Compute Engine instance in the c-local-1 (subnet). We need to add the network tag “test-instance” to ensure the VPC firewall applies the relevant rules. By configuration of the firewall rules, the test instance will allow SSH from my workstation’s IP address, and ICMP from AWS’s 192.168.20.0/24 subnet.

At this stage, we have achieved a network architecture as shown below. vMX and test instances are deployed on both AWS and Google Cloud. The Auto-VPN connection has also been established between the two vMXs.

Verify Auto-VPN Connectivity Between AWS and Google Cloud

We will now conduct a simple ICMP reachability test between the test instance in AWS and Google Cloud. A successful ICMP test will show that all components, including the Meraki vMX, AWS, and Google Cloud have been properly configured to allow end-to-end reachability between the two public clouds over Auto-VPN.

As shown below, the ICMP reachability test from the AWS test instance to the Google Cloud test instance was successful. This confirms that the two cloud environments are correctly connected and can communicate with each other as intended.

I hope that this blog post provided you guidance for designing and deploying Meraki vMX in a multi-cloud environment.

Simplify Meraki Deployment with Terraform

Before you go, I recommend checking out Meraki’s support with Terraform. Because cloud operations often rely heavily on Infrastructure-as-Code (IaC), software like Terraform play a pivotal role in a multi-cloud environment. By using Terraform with Meraki’s native API capabilities, you can integrate the Meraki vMX more deeply into your cloud operations. This enables you to build deployment and configuration into your Terraform processes.

Refer to the links below for more information:

Hands-on learning lab: Learn how to use Terraform with Cisco Meraki
Meraki vMX Setup Guide for AWS
Meraki vMX Setup Guide for Google Cloud Platform
Learn more about Meraki. Visit the Meraki Developer Hub

"}]]  See how to set up a working Auto-VPN architecture in a multi-cloud environment (AWS and Google Cloud). This guide provides actionable steps and techniques for designing and deploying Meraki vMX in a multi-cloud environment.  Read More Cisco Blogs 

Discover Kyle Winters' journey from cybersecurity practitioner to Cisco technical advocate. Learn about his experiences, upcoming tutorials, and how to engage with the community.

​[[{"value":"

Hello Cisco Community! I’m thrilled to share my journey back to Cisco as a Technical Advocate focused on cybersecurity. My mission is to empower you with the knowledge and tools you need to succeed in your own cybersecurity quest.

I’m excited to announce my first tutorial on eBPF and my Snack Minute video demo. The demo will offer in-depth information and practical insights to help you advance your career in cybersecurity.

Here’s what you can look forward to:

Tutorials and guides: My first tutorial, “Introduction to eBPF,” is live. Check it out for a deep dive into this powerful technology that can enhance your cybersecurity skills.

Snack Minute videos: Take advantage of my first Snack Minute video demo, where I explore eBPF and its applications in cybersecurity. These bite-sized episodes are perfect for learning something new in just a few minutes.

Conference sessions: Stay tuned for insights and knowledge I’ll share at upcoming industry events. These sessions will provide valuable information to help you stay ahead in the ever-evolving field of cybersecurity.

I’d like to share my cybersecurity experience with you to help you better understand my background and why I’m so passionate about this field.

My cybersecurity experience

I took my first course in cybersecurity in 2012 at the University of Washington. The fast-paced, critical nature of this field across industries hooked me instantly. My hands-on experience with ethical hacking was a lightbulb moment, igniting my passion for cybersecurity and driving me to immerse myself in its many facets.

After three years of supporting network security tools at a large enterprise, I joined Cisco as a Solutions Architect. This pivotal role allowed me to gain hands-on experience with Cisco’s customers and solutions.

I became actively involved with Cisco DevNet, helping to build and deliver developer-focused content for Cisco’s diverse security portfolio. During this time, I earned my first Cisco DevNet Security Automation Specialist certification. I received a Distinguished Speaker award at Cisco Live and a Cisco CX Best of We award.

After a three-year stint with leading application security startups, I’m excited to announce my return to Cisco—this time as a Technical Advocate. I’m here to leverage my expertise to champion security solutions and empower our community.

In addition to my cybersecurity endeavors, I have a deep love for puzzles and problem-solving. Whether it’s conquering the final boss in a challenging video game (any Elden Ring fans out there?) or navigating escape rooms with friends, I thrive on finding solutions and the thrill of success. I also enjoy international travel, exploring new cultures, and understanding their historical and social traditions. When I’m not working, traveling, or solving puzzles, you can find me at home with my 14-year-old cat, Kenny, enjoying music and international cuisine or cheering for my favorite sports teams.

Navigating resources

Much like the thrill I get from solving puzzles and exploring new cultures, I find immense satisfaction in helping others navigate the complex world of cybersecurity. I’m excited to share some incredible resources Cisco offers to help you on your path.

Explore Cisco U.’s extensive resources

Cisco U. offers resources tailored to individuals at every stage of their cybersecurity career. Whether you’re just starting or looking to deepen your expertise, Cisco U. provides access to comprehensive tutorials, interactive labs, and self-paced learning paths. Dive into the Cisco U. platform and explore some of our free security tutorials and courses today!

Subscribe to Snack Minute

Are you looking to satisfy your tech cravings in a fun and bite-sized way? Subscribe to Snack Minute, Cisco’s weekly video series that includes demos, API insights, and chats with IT experts. Whether you’re working towards certifications or eager to stay ahead of the curve, these quick and quirky 10-minute episodes will leave you satisfied and primed for the next challenge! 

Earn a Cisco CyberOps certificate

In today’s dynamic threat landscape, cybersecurity operations (CyberOps) are essential for organizations facing increasingly sophisticated cyber threats. Cisco’s CyberOps certifications are designed to equip you with the fundamental knowledge and skills needed for cybersecurity operations. These certifications validate expertise in security monitoring, threat detection, forensic analysis, incident response, and more. Learn more about how you can earn your Cisco CyberOps certification.

Join the conversation and connect with peers

Cisco offers a vibrant community, where cybersecurity enthusiasts can share insights, ask questions, and collaborate on solving common challenges. Participate in online forums, attend virtual webinars, and join live events to connect with like-minded professionals, exchange ideas, and stay current on the latest cybersecurity trends and developments.

Create a free Cisco U. account: Explore Cisco’s extensive tutorials and Learning Path library.
Chat with Kyle on the Cisco Learning Network: Share your thoughts, ask questions, and connect with other cybersecurity professionals.

Engage with the community

As I embark on this new chapter, I want to ensure my work aligns with your needs and interests. What cybersecurity topics would you like me to cover? Are there specific challenges you’re facing that I can help address? Please share your thoughts in the comments below or join me on the Cisco Learning Network to continue the conversation.

Sign up for Cisco U. | Join the  Cisco Learning Network today for free.

Follow Cisco Learning & Certifications

X | Threads | Facebook | LinkedIn | Instagram | YouTube

Use  #CiscoU and #CiscoCert to join the conversation.

"}]]  Discover Kyle Winters' journey from cybersecurity practitioner to Cisco technical advocate. Learn about his experiences, upcoming tutorials, and how to engage with the community.  Read More Cisco Blogs 

Announced at Cisco Live US 2024 and available now, Cisco Identity Services Engine’s newest version: Cisco ISE 3.4, is bound to more bring more security to the network. In Cisco ISE 3.4, there are more than a dozen new features but the most catalyst-shaking is the availability of Common Policy.

​[[{"value":"

If you were at Cisco Live US in June—and even if you weren’t—you heard the good news: the release announcement of Cisco Identity Services Network (ISE) 3.4.

For a lot of network and security administrators, hearing about the new functions of the latest version of Cisco ISE can be a bit of a tease—we know that you want to get your hands on it and see how it’s going to strengthen your network. Today is the realization of those long weeks of waiting as Cisco ISE 3.4 is ready for you to download and deploy on your network.

If you haven’t heard about what’s available in the latest iteration of Cisco ISE 3.4, let this be your primer. The biggest takeaway is Common Policy which involves solving one of our customers’ biggest problems: fragmented and inconsistent policies across disparate domains.

Common Policy is designed to streamline and unify security policy enforcement across an organization’s entire network. This solution enables administrators to seamlessly apply consistent access and segmentation controls to all devices, users, and applications. These segmentation and access policies are built based on the exchanged information garnered from these end devices.

Using Cisco ISE as a central exchange hub, the solution integrates network and security domains, normalizes contextual information, and facilitates secure communication between different components. This innovative approach enhances zero-trust security across diverse access patterns and locations by simplifying the management of complex network environments. Currently in beta, Common Policy is anticipated for general release this fall.

As part of the Common Policy solution, we re-wrote our integration with Application Centric Infrastructure (ACIs), allowing the users to set up a bi-directional connection to multiple APIC Data Centers—including single pod and multi-pod fabrics—directly from Cisco ISE and start exchanging SGT/EPG/ESG context.

In addition to Common Policy, the Cisco ISE 3.4 release is jam-packed with many other features too.

Active Directory preferred DC selection

Starting with Cisco ISE 3.4, administrators can now manually prioritize Domain Controllers (DC), giving them more control over which DC is used for authentication and authorization. In the event of an Active Directory failure, Cisco ISE will automatically switch to the next DC on the list, ensuring that users can still access resources. Once the preferred DC is available again, Cisco ISE will seamlessly failback, restoring the original priority order.

Great news for those who hate waiting! With the release of Cisco ISE 3.4, system restart times have been dramatically reduced to mere minutes, varying slightly depending on the specific role of each node. No more long coffee breaks between reboots.

Building on the pxGrid Direct framework introduced in Cisco ISE 3.2, which simplified integration with Configuration Management Database (CMDB) servers lacking native pxGrid support, Cisco ISE 3.4 will bring forth several key enhancements:

Sync now: In scenarios where significant changes occur within the CMDB, administrators will no longer need to wait for scheduled updates. Cisco ISE 3.4 will empower admins to initiate on-demand synchronization, guaranteeing Cisco ISE access to the most up-to-date endpoint information.
URL pusher and persistent database: Customers will now have the flexibility to directly push a JSON file containing endpoint data into Cisco ISE’s persistent database. This opens new possibilities for those without a CMDB, as they can still leverage pxGrid Direct by conveniently pushing data into Cisco ISE. Unlike the internal endpoint database, this database will be persistent and won’t be purged.

Retention of use settings

In previous versions of Cisco ISE, any customizations to table displays, like column selection, order, or width, would be reset upon leaving the page. With Cisco ISE 3.4, the preferred table settings will be saved and retained, even when switching browsers or devices. No more repetitive adjustments – the personalized view is here to stay.

Localized ISE Installation

This enhancement allows administrators to reinstall ISE directly from a local ISO file stored on the ISE server, significantly reducing the installation time from the traditional 5-7 hours to just 1-2 hours. This streamlined process is particularly beneficial in scenarios where a reinstall is necessary, such as system recovery or upgrades. By minimizing downtime and accelerating the installation process, the Localized ISE Installation feature enhances operational efficiency, ensures quicker recovery times, and ultimately saves valuable time for IT teams. This improvement underscores Cisco’s commitment to providing robust, user-friendly solutions that optimize the performance and reliability of the network security infrastructure.

FQDN to SGT Mapping

In Cisco ISE 3.4, we’ve tackled the challenges faced by TrustSec administrators in scenarios with geo-distributed or cloud deployments, where the same Fully Qualified Domain Name (FQDN) might resolve to different IP addresses depending on the DNS server. This can make it difficult to consistently apply the same SGT to all instances of the FQDN.

Cisco ISE 3.4 introduces an enhanced FQDN-to-SGT mapping feature. Administrators can now select multiple nodes to resolve the FQDN, ensuring that all resulting IP addresses are accurately associated with the corresponding SGT. This new capability streamlines policy enforcement across diverse network environments, regardless of variations in DNS resolution.

Pac-less Communication between Cisco ISE and TrustSec NADs

Cisco ISE 3.4 introduces Pac-less Communication, a simplified approach to communication between Cisco ISE and TrustSec network devices. This innovation eliminates the need for administrators to manage PAC files, reducing overhead and streamlining the process. Pac-less communication requires Cisco IOS-XE 17.5.1 or later, on network devices, but no configuration changes are needed on the Cisco ISE side. The network devices themselves will inform Cisco ISE of their supported capabilities, further simplifying deployment and management.

Log file management

We have heard from you that troubleshooting Cisco ISE under a heavy load can be a challenge, especially when log files fill up rapidly and critical information might get buried. Cisco ISE 3.4 addresses this with enhanced log management capabilities. Now, administrators have granular control, allowing them to set both maximum file size and the number of log files to keep per component. This means no more worries about missing crucial details during peak times.

As you can tell there’s a lot packed into the latest version of Cisco ISE that is going to make your job easier. Click here for more information on Cisco ISE.

We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Security on social!

Cisco Security Social Channels

InstagramFacebookTwitterLinkedIn

"}]]  Announced at Cisco Live US 2024 and available now, Cisco Identity Services Engine’s newest version: Cisco ISE 3.4, is bound to more bring more security to the network. In Cisco ISE 3.4, there are more than a dozen new features but the most catalyst-shaking is the availability of Common Policy.  Read More Cisco Blogs 

Check out all the IOS XE sessions from the recent Cisco Live in Las Vegas. Topics include getting started with Cisco IOS XE programmability and automation, tooling with YANG Suite and Terraform, and open-source solutions for Model Driven Telemetry.

​[[{"value":"

Check out all the events and sessions from the recent Cisco Live 2024 in Las Vegas. Hopefully we’ll catch you at the next Cisco Live event coming up November 11-14, 2024 in Melbourne, Australia! Learn more and register for Cisco Live Melbourne.

These sessions cover topics ranging from getting started with Cisco IOS XE programmability and automation, tooling with YANG Suite and Terraform, and gaining hands-on experience with open-source solutions for Model Driven Telemetry. See the details of the upcoming Cisco Live sessions below:

Breakout Sessions

3 Cisco Catalyst Center and ITSM Workflows: CMDB, Incident Management, and SWIM – BRKOPS-2032

Do you have Cisco Catalyst Center in production or maybe in your lab, and you’re looking to increase efficiencies, simplify and automate tasks, or integrate with other platforms? Then this session is for you. Participants will learn about the most common, ready-to-use workflows, available with the Cisco Catalyst Center integration to ServiceNow. The session provides an overview of the Cisco Catalyst Center integration with ServiceNow, the integration architecture, software required, and compatible versions. We will review in detail all steps required to configure the configuration management database (CMDB) synchronization, network issue monitor, and enrichment and automation events (software image management) workflows. This integration will increase IT efficiencies, reduce the cost of creating and updating incidents, and decrease the time between when the network issue is detected and the network engineer starts troubleshooting. The automation events for the ITSM workflow creates change requests for network configuration changes that may impact the uptime or segmentation policies, avoiding costly unapproved configuration changes. Demos for each use case are included.

ChatBot for Catalyst Center – an Open-Source GenAI based Bot – DEVNET-3000

Do you have Cisco Catalyst Center in production or, maybe in your lab, and you are looking to increase efficiencies and visibility using Cisco Catalyst Center REST APIs? This session is for you! Participants will learn how to develop a Cisco Catalyst Center open-source AI based ChatBot. We will step-by-step build the ChatBot, reviewing the options to use real-time or near-real time data retrieved with API calls to Catalyst Center. The ChatBot allows network engineers to easily find relevant information using natural language, filtering only what is important. The open-source ChatBot will transform how we manage network infrastructure, enriching and simplifying network management tasks. Demos and Python sample code are included.

Cisco Catalyst Center Platform: APIs, Event Notifications, Integrations, and DevOps Resources – DEVNET-1087

Do you have Cisco Catalyst Center in production, in the lab, or are you just interested in getting started? This session will focus on how to manage your network infrastructure-as-code using the Catalyst Center platform. We will review the Catalyst Center REST APIs, real-time event notifications, out-of-the-box and open-source integrations, and how to build a custom integration. We will also go over the developer resources available to accelerate the consumption of Catalyst Center REST APIs. The session is use case–based, exploring the options to build innovative new solutions, services, and integrations on top of the Catalyst Center platform. Demos and Python and JavaScript sample code are included, as needed.

gRPC, gNMI, gNOI… Oh My! An Enterprise Network Automation Journey – BRKDEV-2017

How many Google API micro services are there on Cisco IOS XE, and what are their capabilities? At the end of this session not only will you be able to answer this question with confidence but you will also have a deep understanding of the solutions and real world use cases that are enabled as part of the Google Network Management API. But what about Model Driven Telemetry? What are the best practices for mutual TLS authentication and collection of large amounts of telemetry data ? This session covers the complete Programmability & Automation lifecycle of the Cisco Catalyst 9000 when managed using gRPC, gNMI and gNOI… oh my!

Let’s Talk about Catalyst Center Integrations – IBOOPS-2882

This session reviews existing ready-to-use Catalyst Center integrations, open-source integrations, and how to build custom integrations. Attendees will be able to drive the conversation toward the integrations of their choice.

We could start with the ready-to-use integrations between Cisco Catalyst Center and ITSM (ServiceNow), PagerDuty, Webex notifications, and Splunk. Details, best practices, and demos could be shared for each of these integrations.

If there is interest, we may evaluate the published, open-source integrations between Catalyst Center and Jenkins, GitHub and GitLab, as well as the architectural options for integrating with third-party platforms and how to build these integrations.

The concepts presented in this session are valuable when building integrations for real-time event notifications, asset management, network insights and dashboards, or API-based automations.

Demos and sample code are included.

Network Troubleshooting Using Cisco Catalyst Center APIs – BRKOPS-2548

Are you looking for API-based options to enhance and automate your network troubleshooting workflows?

Do you want to improve consistency, enhance visibility and compliance, while saving time troubleshooting your network? Then, this session is for you.

During the session, we will review the options available to automate common, repetitive tasks network engineers undertake while troubleshooting network issues.

Step by step, we will build a runbook environment that will be triggered when Cisco Catalyst Center identifies a new network issue. The open-source solution will call upon Cisco Catalyst Center APIs to collect all relevant information about the issue and the devices impacted, then update the network engineer. This information is very valuable, assisting the network engineer in troubleshooting the network problem based on the state of the network at the time the issue occurred. A simple troubleshooting knowledge base library will be included.

Demos and open-source sample code will be included.

Programmability, Automation Model Driven Telemetry on Cisco IOS XE with a dash of YANG Suite  – DEVNET-1283

This programmability and automation session on Cisco IOS XE and Catalyst includes an overview of the YANG based API’s and the associated YANG Suite tooling will be used extensively. The Model Driven Telemetry capabilities will also be discussed and the example Docker container for collection and visualization will be demonstrated. As well as ways to create new telemetry subscriptions using the Telegraf, Influx and Grafana stack and YANG Suite.

Stay Connected

No matter where you are on your programmability and automation journey there is always new and exciting content to help you dive even deeper while learning about new technologies and capabilities for the enterprise network.
Here are links where you can check out Cisco IOS XE programmability sessions from previous Cisco Live Events:

2024 – Amsterdam

3 Cisco Catalyst Center and ITSM Workflows: CMDB, Incident Management and SWIM – BRKOPS-2032
Automate Cisco IOS XE Device Configuration Using Terraform – DEVLIT-2083
Automation using multiple API’s in the IOS XE Device Programmability Lab – DEVLIT-1965
Catalyst 9000 Virtual topology simulation and configuration management solutions – DEVNET-1441
Cisco Catalyst Center-as-Code Network Compliance Use Cases – DEVNET-2157
Custom Workflows for the Cisco Catalyst Center Integration with ServiceNow – BRKOPS-2471
Explore and visualize YANG models with YANG Suite – DEVLIT-2787
Getting Started with Secure Zero Touch Provisioning – DEVLIT-2062
How to Become a Cisco IOS XE Terraform Expert – DEVNET-2464
Infrastructure as Code with Cisco Catalyst 9000 Virtual – BRKOPS-2455
Programmability, Automation Model Driven Telemetry on Cisco IOS XE with a dash of YANG Suite – DEVNET-1468
Version Control Tools Integrations – Cisco Catalyst Center Infrastructure-as-Code Use Cases – DEVNET-2958

 2023 – Melbourne

Catalyst 9000 Virtual topology simulation and configuration management solutions – DEVNET-2525
Cisco Catalyst Center-as-Code Network Compliance Use Cases – DEVNET-2634
How to Become a Cisco IOS XE Terraform Expert – DEVNET-2476
Version Control Tools Integrations – Cisco Catalyst Center Infrastructure-as-Code Use Cases – DEVNET-2632

 2023 – Las Vegas

3 Cisco DNA Center and ITSM Workflows: CMDB, Incident Management and SWIM – BRKOPS-2032
3 Cisco DNA Center and ITSM Workflows: CMDB, Incident Management and SWIM – BRKOPS-2032
Custom Workflows for the Cisco DNA Center Integration with ServiceNow – BRKOPS-2471
Infrastructure as Code with Cisco Catalyst 9000 Virtual – BRKOPS-2455
Jenkins Automations for Cisco DNA Center – DEVNET-2151
Secure Zero Touch Provisioning on Cisco IOS XE – DEVNET-2122
Infrastructure as Code (IAC) with Catalyst 9000 – DEVNET-2119
Test Automation with Cisco Catalyst 9000 Virtual Switch – BRKDEV-2467
Version Control Tools Integrations – Cisco DNA Center Infrastructure-as-Code Use Cases – BRKOPS-2854

 2023 – Amsterdam

3 Cisco DNA Center and ITSM Workflows: CMDB, Incident Management and SWIM – BRKOPS-2032
ClickOps to GitOps – Cisco DNA Center Infrastructure-as-Code Use Cases – DEVNET-2739
Custom Workflows for the Cisco DNA Center Integration with ServiceNow – BRKOPS-2471
Everyday Wireless Operational Headaches: Cured using Programmability! – BRKEWN-2730
Jenkins Automations for Cisco DNA Center – DEVNET-2151
Three Cisco DNA Center Integrations: Splunk, Webex Notifications, and PagerDuty – DEVNET-2031

2022 – Melbourne

Automating Enterprise Deployments with Zero Touch Provisioning – DEVNET-2569
ClickOps to GitOps – Cisco DNA Center Infrastructure-as-Code Use Cases – DEVNET-2739
Jenkins Automations for Cisco DNA Center – DEVNET-2151
Programmability and Automation with Catalyst IOS XE Platforms – DEVNET-2745
Three Cisco DNA Center Integrations: Splunk, Webex Notifications, and PagerDuty – DEVNET-2031

2022 – Las Vegas

Cisco DNA Center Integrations with 3rd Party Platforms – BRKDEV-2637
Jenkins Automations for Cisco DNA Center – DEVNET-2151
Programmability and Automation with Catalyst IOS XE Platforms – BRKDEV-2016
Programmability & Automation on Catalyst Wireless Platforms – BRKEWN-2730
Three Cisco DNA Center Automation Use Cases using Python SDK, Ansible and Terraform – DEVNET-1840
Three Cisco DNA Center Integrations: Splunk, Webex Notifications, and PagerDuty – BRKOPS-2031

2021 – Digital

Back to the Office – API-Based Pandemic Proximity Use Cases – BRKEMT-2005
DevNet: Dive into Building your Cisco DNA Center Automation Workflow – BRKDEV-2013
DevNet: Implementing Model Driven Telemetry in Your Network ? – BRKDEV-2012
Enterprise Telemetry and Automation with gRPC – BRKPRG-2330
How to Get Started with Telemetry – DEMDEV-305

2020 – Digital

APIs-enabled NOCs – DGTL-DEVNET-3008
Build Your API-Based Network Troubleshooting Kit – DGTL-BRKNMS-2497
Campus Programmability with Cisco IOS-XE – DGTL-DEMCRS-707
Cisco Catalyst Wireless – leveraging APIs & telemetry to deploy & optimize your wireless network – DGTL-BRKEWN-2050

2020 – Barcelona

Behind the scenes of the IOS XE Programmability Lab – DEVLIT-4010
Build Your API-Based Network Troubleshooting Kit – BRKSDN-2497
Operational Dashboarding with Wireless Streaming Telemetry – DEVNET-2415
Project WhatsOp – A Messaging Platform for Network Devices – DEVNET-3841
Telemetry and Programmability in the Next Generation Wireless Stack – BRKEWN-2050

2019 – San Diego

Operational Dashboarding with Wireless Streaming Telemetry – DEVNET-2415

"}]]  Check out all the IOS XE sessions from the recent Cisco Live in Las Vegas. Topics include getting started with Cisco IOS XE programmability and automation, tooling with YANG Suite and Terraform, and open-source solutions for Model Driven Telemetry.  Read More Cisco Blogs 

As part of building a resilient architecture, it is essential to include and plan for scenarios in which the endpoint or workload solution might fail.

​[[{"value":"

Building network and workload security architectures can be a daunting task. It involves not only choosing the right solution with the appropriate set of capabilities, but also ensuring that the solutions offer the right level of resilience.

Resilience is often considered a network function, where the network must be robust enough to handle failures and offer alternate paths for transmitting and receiving data. However, resilience at the endpoint or workload level is frequently overlooked. As part of building a resilient architecture, it is essential to include and plan for scenarios in which the endpoint or workload solution might fail.

When we examine the current landscape of solutions, it usually boils down to two different approaches:

Agent
Agentless

Agent-Based Approaches

When choosing a security solution to protect application workloads, the discussion often revolves around mapping business requirements to technical capabilities. These capabilities typically include security features such as microsegmentation and runtime visibility. However, one aspect that is often overlooked is the agent architecture.

Generally, there are two main approaches to agent-based architectures:

Userspace installing Kernel-Based Modules/Drivers (in-datapath)
Userspace transparent to the Kernel (off-datapath)

Secure Workload’s agent architecture was designed from the ground up to protect application workloads, even in the event of an agent malfunction, thus preventing crashes in the application workloads.

This robustness is due to our agent architecture, which operates completely in userspace without affecting the network datapath or the application libraries. Therefore, if the agent were to fail, the application would continue to function as normal, avoiding disruption to the business.

Figure 1: Secure Workload’s Agent Architecture

Another aspect of the agent architecture is that it was designed to give administrators control over how, when, and which agents they want to upgrade by leveraging configuration profiles. This approach provides the flexibility to roll out upgrades in a staged fashion, allowing for necessary testing before going into production.

Figure 2: Agent Config Profile and On-Demand Agent Upgrades

Agentless-Based Approaches

The best way to protect your application workloads is undoubtedlythrough an agent-based approach, as it yields the best outcomes. However, there are instances where installing an agent is not possible.

The main drivers for choosing agentless solutions often relate to organizational dependencies (e.g., cross-departmental collaboration), or in certain cases, the application workload’s operating system is unsupported (e.g., legacy OS, custom OS).

When opting for agentless solutions, it’s important to understand the limitations of these approaches. For instance, without an agent, it is not possible to achieve runtime visibility of application workloads.

Nevertheless, the chosen solution must still provide the necessary security features, such as comprehensive network visibility of traffic flows and network segmentation to safeguard the application workloads.

Secure Workload offers a holistic approach to getting visibility from multiple sources such as:

IPFIX
NetFlow
Secure Firewall NSEL
Secure Client Telemetry
Cloud Flow Logs
Cisco ISE
F5 and Citrix
ERSPAN
DPUs (Data Processing Units)

… and it offers multiple ways to enforce this policy:

Secure Firewall
Cloud Security Groups
DPUs (Data Processing Units)
Figure 3: Agentless Enforcement Points with Secure Workload

Key Takeaways

When choosing the right network and workload microsegmentation solution, always keep in mind the risks, including the threat landscape and the resilience of the solution itself. With Secure Workload, you get:

Resilient Agent Architecture
Application runtime visibility and enforcement with microsegmentation
Diverse feature set of agentless enforcement

Learn more about Cisco Secure Workload

We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Security on social!

Cisco Security Social Channels

InstagramFacebookTwitterLinkedIn

"}]]  As part of building a resilient architecture, it is essential to include and plan for scenarios in which the endpoint or workload solution might fail.  Read More Cisco Blogs 

Discover how Business Development Manager Shawn C.'s volunteering through the Time2Give program made a difference for sea turtles and her wellbeing, too.

​[[{"value":"

As a child growing up surrounded by the natural beauty of Colorado, my parents instilled in me a great appreciation for nature, wildlife, and the ecosystems that make up our world. They taught me the value of observing and participating in the great outdoors, a practice that has always soothed my soul and put into perspective my place in the grand scheme of life. Our family’s summer travels to the national parks across the United States were not just vacations; they were lessons in the glory and complexity of the natural world.

When my husband and I decided to move to North Padre Island, just outside of Corpus Christi, Texas, I was thrilled to discover that the Padre Island National Seashore was now “in my backyard.” This pristine stretch of coastline is home to the Sea Turtle Recovery Program, a cause that quickly captured my heart and spirit.

I still vividly remember the rush of excitement during my first Kemp’s ridley sea turtle hatchling release at the park. Witnessing those tiny, determined creatures make their way to the ocean was a transformative experience. It was then that I knew I had to become more involved with the park’s Division of Sea Turtle Science and Recovery, which focuses on the conservation of five sea turtle species: Kemp’s ridley, green, loggerhead, hawksbill, and leatherback—all federally listed as threatened or endangered.

The restoration of the Kemp’s ridley population has been a monumental effort, beginning in the 1970s with a bi-national program led by the U.S. National Park Service. The program’s success has made Padre Island National Seashore the premier nesting site for these turtles in the U.S. and paved the way for the protection and conservation of four other sea turtle species that nest in the same area. Additionally, the park initiated the Sea Turtle Stranding and Salvage Network (STSSN) in Texas, which plays a critical role in rescuing, rehabilitating, and releasing turtles affected by weather, climate, and human interactions.

The importance of this work cannot be overstated. Sea turtles are vital to marine ecosystems, helping to maintain the health of seagrass beds and coral reefs, which, in turn, support a diverse array of marine life. It is an honor to represent Cisco in these conservation efforts.

Thanks to Cisco’s Time2Give program, which provides 80 hours of paid time off in addition to our regular PTO for volunteering, I have had the incredible opportunity to be directly involved in the release of over 3,000 turtle hatchlings, assist in data collection and research, educate the public about conservation, and spend four hours a week patrolling for nesting turtles during the season. I’ve also participated in rescue operations for cold-stunned sea turtles in the Laguna Madre following freeze events on the Texas coast.

Among my most memorable experiences are finding my first nesting Kemp’s ridley turtle and a “trifecta” hatchling release, where Kemp’s ridley, green, and loggerhead hatchlings were all released under a starlit sky. These moments, shared with just a biotech, hundreds of baby turtles, and millions of stars along undeveloped coast line, underscore the beauty and fragility of nature. They serve as powerful reminders of the importance of conservation and the impact we can have as individuals.

Before I embarked on this recent volunteer journey, I was feeling the weight of stress and burnout, struggling to bring my best self to work each day. This experience has reinvigorated me, reminding me that every moment counts. It has had a profound impact on my mental health and happiness, which has, in turn, positively affected my professional and personal life. I am deeply grateful to Cisco for supporting me in this endeavor. Through this give-back opportunity, we are not just changing the world; we are also changing ourselves.

In the end, it’s not just about saving sea turtles; it’s about saving a piece of ourselves and reconnecting with the natural world that sustains us all. I am humbled, energized, and proud to be part of a company whose purpose is powering an inclusive future for all and encourages its employees to pursue their passions and contribute to their communities. Together, we can make a difference—one turtle, one person, one moment at a time.

Explore how our purpose has made a difference in the world.

Subscribe to the WeAreCisco Blog.

"}]]  Discover how Business Development Manager Shawn C.'s volunteering through the Time2Give program made a difference for sea turtles and her wellbeing, too.  Read More Cisco Blogs