Bring your personal devices to the enterprise network with Cisco User Defined Network

Are your users overloading your network with their devices? It’s no wonder. With streaming services, video game systems, virtual assistants, wireless speakers, and other devices it’s a struggle to meet demands of your network users.

Add chatty protocols such as mDNS and UPnP among others—and it just adds to the damage it can do to your enterprise network. 

The Cisco User Defined Network (UDN) solution is your savior as it helps you meet the growing demand of proliferation of wireless devices.

How does it work? It all begins on a shared network; for example you could have students in a dorm or seniors living in senior living facilities or developers and testers looking to emulate home environment. There’s a lot of devices jockeying for space on the network and not only that, these devices aren’t private. Anyone can see them, and a lot of time, anyone can access them. With Cisco UDN users get their own private partition on the network.  

Now your users can bring their home devices to the enterprise network and control their devices like they do at home. Users will now only see their personal devices on the network even when they are connected to a shared enterprise network. Not only that—and here’s the really cool thing—they can invite other users to their UDN and even share services between their personal devices and their friend’s devices while in their UDN defined partition.  

And it couldn’t be easier. All users have to do is download a new mobile app from Cisco (available for free in the Apple App and Google Play stores). This app allows them to control their UDN-defined partition, you can allow and deny access to your devices with a touch of a button. But get this, users can pre-register their personal devices before they bring them in enterprise network. That means user devices are ready to be used the minute they walk on campus. None of our competitors can say the same thing. The only thing that you have to do is enable the Cisco UDN solution from Cisco DNA Center and it works! 

Now that we told you what Cisco User Defined Network is all about, I’m sure your next question is, “How does it make my job easier and what about the network?” We’ve got you covered, check this out:  

◉ Privacy – Currently, when users connect to an enterprise network, they see all of the devices on the network—not just their own devices. With Cisco UDN, they get the peace of mind that only they can see their personal devices which they have registered through mobile app. And the flip side is no one can see their devices (see below).  

◉ Control – Currently when users authenticate to the shared network, anybody could take control of their devices because they see those devices in the network. With Cisco UDN, malicious users cannot see other devices on network, so they cannot take control of your users’ personal devices.

◉ Manage home device proliferation – You can only say no so many times to your network users to bring their home devices to the network. You know the reasons why not, but they’re not going to listen to you. To add to this frustration, this holiday season there’s a new launch of Xbox Series X, and PlayStation 5. Good luck getting anyone to keep these at home, so these devices on your network are only going to increase in numbers.

◉ Sharing – With Cisco UDN, network users can now share devices and services with each other like they used to do at home with their family and friends. So, whether it’s playing multiplayer on your game consoles, printing on a wireless printer, playing music on your roommates’ new wireless speaker or dropping files to your friend, Cisco UDN makes it just an invitation away. 

So, how does it make all of this possible? When users register their devices through the Cisco UDN mobile app, it creates a personal network for each user like a partition. Only the devices which are present in the partition can recognize each other. Users will not be able to see other devices present on the shared network. So, now they cannot start streaming to other device accidently or share something unless they absolutely want to. If they now wish to share devices with other users, they can invite those users and their selected devices to their UDN and start sharing with them. Cisco UDN gives control to invitee as well as invited user on when they want to join or leave the UDN. 

Figure 1: User Defined Networks in a shared network

Cisco User Defined Network not just helps your network users but also takes into consideration needs for an IT Admin as well in the following ways –

◉ Prevents flooding – By containing multicast traffic such as Bonjour, UPnP, and others inside their UDN partition, it prevents flooding of such packets to entire network as the traffic is now contained within a particular UDN. 

◉ Easy registration of devices – Cisco UDN provides multiple options to register the devices through mobile app via camera scanning, image scanning and other flexibilities to register from anywhere on-prem and off-prem. This gives IT admins peace of mind as they don’t have to handle registration requests when everybody tries to deploy their devices to the network.  

◉ Enablement on location of choice – Cisco UDN provides the option to be enabled only in one part of the network and need not be enabled on entire campus such as in a residential building only or only on specific SSIDs. 

◉ Provide service to subset of users – Through the integration with Active Directory, you can provide the Cisco UDN service to a subset of users and not need to enable to everyone on the network. Basically, you get to choose who can use the UDN solution. For example – you may want to enable only for students living in a dorm and not for all students.  

With Cisco User Defined Network, now you can think about allowing your users to bring any device they want to the enterprise network without having to worry about flooding or privacy. Your users can enjoy a premium home–like user experience even when they are connected to enterprise network. 

Continue reading

Watch How Riedel Networks Ensures World Events Win

Today everyone wants more and more from their network: more control, more visibility, and more security. And that’s exactly what Riedel Networks intends to give its customers, including the Olympic Games and Formula 1 as well as TV broadcasters and global enterprises.

With customers migrating data and applications, the communications networks provider decided to expand its product offerings to include a managed SD-WAN (software-defined networking in a wide area network) offering. 

Riedel Networks services some of the largest and most connected events around the world.

But with today’s security threats coming from vectors including remote workers, the additional of SD-WAN requires security gateways, both central and remote customer locations. The company needed an SD-WAN security solution for the edge.

Riedel has relied on Cisco technology since it started out connecting the headquarters of Formula 1 teams with race circuits. So, it was only natural that it turned to Cisco.

Cisco SD-WAN Security ensures every single packet on its journey to the cloud and back is kept secure without hindering performance. The Cisco technology provides everything from a broad range of connectivity options – including satellite connections and 5G mobile networks – to advanced SD-WAN routing and a full security suite.

And the vManage software controller means Riedel can manage everything centrally, over a single dashboard. With the right security controls in the right place based on policy, traffic, and location, customers have greater resiliency, no matter where they are – which is vital for businesses reliant on their networks for transferring pictures and sound as well as data.

Riedel Networks delivers customers a managed digital service including SD-WAN and SD-WAN Security for the latest in cloud networking.

The company plans to adopt Cisco’s new Catalyst 8000 Edge Platforms, which will allow Riedel Networks to deliver a secure, connected multicloud across the Cisco SD-WAN edge. Ultimately, bandwidth above one gigabyte per second means Riedel can include headquarters and data center sites in the SD-WAN.

Continue reading

Study Guide: Cisco 200-901 DevNet Associate Certification

Cisco DEVASC Exam Description:

This exam tests a candidate's knowledge of software development and design including understanding and using APIs, Cisco platforms and development, application development and security, and infrastructure and automation. The course, Developing Applications and Automating Workflows using Cisco Core Platforms, helps candidates to prepare for this exam.

Cisco 200-901 Exam Overview:

• Exam Name:- Developing Applications and Automating Workflows using Cisco Core Platforms
• Exam Number:- 200-901 DEVASC
• Exam Price:- $300 USD
• Duration:- 120 minutes
• Number of Questions:- 90-110
• Passing Score:- Variable (750-850 / 1000 Approx.)
• Recommended Training:- Developing Applications and Automating Workflows using Cisco Core Platforms (DEVASC)
• Exam Registration:- PEARSON VUE
• Sample Questions:- Cisco 200-901 Sample Questions
• Practice Exam:- Cisco Certified DevNet Associate Practice Test

Related Articles:-

• Complete Guide to Understanding Cisco DEVASC 200-901 Exam
• 200-901 DEVASC: Explore the Cisco Exam and Career Benefits
• Acing the Cisco DevNet 200-901 Exam: Top Tactics and Other Insights
• Cisco DevNet Associate 200-901 Certification: Start your DevNet Journey Today!

Continue reading

Cisco NX-OS VXLAN Innovations Part 2: Seamless Integration of EVPN(TRM) with MVPN

In today’s world, multicast senders and receivers are not limited to a single network. They can be spread across enterprise and data center locations. Multicast can be generated or consumed anywhere and can be present in various security contexts – be it a tenant of VXLAN EVPN -based data center or within a traditional IP multicast network.  

Applications expect transparency to the underlying transport architecture while security compliance demand segmentation.  Networks should enable seamless and secure connectivity without compromising security or performance. The Border Device interconnected multicast network domains are the focus of this innovation. Both the seamless integration of VXLAN EVPN with TRM (Tenant Routed Multicast) and MVPN (Multicast VPN); two flavors of the same kind. 

The Two-Node Approach

An integration in which each node acts as a border to their domain requires a two-node approach. This incurs both CapEx costs and operations burden for customers to manage two devices. The complexity is multiplied if the integration needs to happen between traditional multicast networks, VXLAN EVPN (multicast network), and MVPN networks.  

To keep OpEx and CapEx costs to a minimum, we need a simpler, single-node approach.  

We followed a step–by–step approach to provide a solution addressing all these challenges. 

◉ Cisco innovated Tenant Routed Multicast (TRM) as a first–shipped solution delivering Layer-3 multicast overlay forwarding in VXLAN EVPN networks with an Anycast Designated router (DR) for End-Points. 

◉ Cisco introduced Multicast VPN (Draft Rosen PIM/GRE) support on Cisco Nexus 3600-R and 9500-R as a steppingstone.   

◉ Cisco NX-OS 9.3(5) release delivered seamless integration between EVPN(TRM) and MVPN (Draft Rosen). Since these edge devices have functions for both TRM as well as MVPN, they act as seamless hand-off nodes for forwarding multicast between VXLAN EVPN networks and MVPN network. 

Tenant Routed Multicast 

Cisco Tenant Routed Multicast (TRM) efficiently delivers overlay Layer-3 multicast traffic in a multi-tenant VXLAN BGP EVPN data center network. Cisco TRM is based on standards-based, next-gen multicast VPN control plane (ngMVPN) as described in IETF RFC 6513 and RFC 6514 plus the extensions posted as part of IETF “draft–bess–evpn–mvpn-seamless-interop“. In VXLAN EVPN fabric, every Edge-Device act as a Distributed IP Anycast Gateway for unicast traffic as well as a Designated Router (DR) for multicast. On top of achieving scalable unicast and multicast routing, multicast forwarding is optimized by leveraging IGMP snooping on every edge-device by sending traffic only to the interested receivers. 

TRM leverages Multicast Distribution Trees (MDT) in the underlying transport network and incurs multi-tenancy with VXLAN encapsulation. A default MDT is built per-VRF and individual multicast group addresses in the overlay is mapped to respective underlay multicast groups for efficient replication and transport. TRM can leverage the same multicast infrastructure as VXLAN BUM (Broadcast, Unknown Unicast, and Multicast) traffic. Even by leveraging the same infrastructure, Rendezvous-Point (RP), the Multicast groups for BUM, and MDT are separated. The combination of TRM and Ingress Replication is also supported.  In the overlay, TRM operates as fully distributed Overlay Rendezvous-Point (RP), with seamless RP presence on every edge-device. The whole TRM–enabled VXLAN EVPN fabric acts as a single Multicast Router.   

In multicast networks, multicast sources, receivers, and Rendezvous-point (RP) reside within the fabric, across sites, inside Campus locations or over the WAN network. TRM allows seamless integration with existing multicast networks regardless of whether the sources, receivers and RP are located. TRM allows tenant-aware external connectivity using Layer-3 physical or sub-interfaces.    

TRM Multi-Site – DCI with Multicast 

Multi-site architecture

Data and application growth compelled customers to look for scale-out data center architectures as one large fabric per location brought challenges in operation and fault isolation. To improve fault and operational domains, customers started building smaller compartments of fabrics with Multi-Pod and Multi-Fabric architectures. These fabrics are interconnected with the Data Center Interconnect (DCI) technologies. The complexity of interconnecting these various compartments prevented from the rollout of such concepts with the introduction of Layer–2 and Layer–3 extensions. With a single overlay domain (end-to-end encapsulation), Multi-Pod introduced challenges with scale, fate sharing, and operational restrictions. Although Multi-Fabric provided improvements over Multi-Pod by isolating both the control and the data plane, it introduced additional challenges and operational complexity with confused mixing of different DCI technologies to extend and interconnect the overlay domains.  

TRM Multi-site

For unicast traffic, VXLAN EVPN Multi-Site architecture was introduced to address the above concerns. It allows the interconnection of multiple distinct VXLAN BGP EVPN fabrics or overlay domains, new approaches to fabric scaling, compartmentalization, and DCI. At the DCI, Border Gateways (BGW) were introduced to retain the network control points for overlay network traffic. Organizations also have a control point to steer and enforce network extension within and beyond a single data center. 

 Further, the Multi-Site architecture was extended with TRM in NX-OS 9.3(1) for seamless communication between sources and receivers spread across multiple EVPN VXLAN networks. This enables them to leverage similar benefits as that of the VXLAN EVPN Multi-site architecture.   

Tenant Routed Multicast to MVPN  

Multicast VPN (Draft Rosen – PIM/GRE)

MVPN (PIM/GRE) Draft-Rosen IETF draft “draft-rosen-vpn-mcast-10“ is an extension of BGP/MPLS IPVPN[RFC4364] and, specifies the necessary protocols and procedures for support of IPv4 Multicast. Like unicast IP VPN, MVPN allows enterprises to transparently interconnect its private network across the provider backbone without any change in enterprise network connectivity and administration for streaming multicast data. 

The NX-OS 9.3(3) release introduced MVPN (PIM/GRE) support on Cisco Nexus 9000 (R-Series) and Nexus3000 Series switches (R-Series). 

Seamless integration between EVPN (TRM) and MVPN (Draft Rosen) 

Brand new in Cisco NX-OS 9.3(5), we introduced the seamless integration between TRM capable edge-devices with Multicast VPN networks. The functionality of VXLAN VTEP and MVPN PE is brought together on the Nexus 9500-R Series and Nexus 3600-R Series. In Border PE (a combination of VXLAN Border and MPLS PE), a border device plays a VTEP role in VXLAN EVPN(TRM) network and a PE role in the MVPN network. The gateway node enables packets to be handed off between a VXLAN network (TRM or TRM Multi-Site) and an MVPN network. It acts as a central node that performs necessary packet forwarding, encapsulation, and decapsulation to send multicast traffic to the respective receivers.  The rendezvous point (RP) for the customer (overlay) network can be in any of the three networks:  VXLAN, MVPN, or IP multicast. 

Customers reap the benefits of lower OpEx and CapEx costs with a single-node approach at the border for hand-off functionality.   

Customers achieve the benefits of standards-based data center fabric deployments using VXLAN EVPN technology – scalability, performance, agility, workload mobility, and security. As data cross multiple domains or boundaries, it becomes critical for customers to achieve similar benefits without increasing costs and operational complexity. Customers are looking for a simple, flexible, manageable approach to data center operations and Cisco’s single-box solution (both VXLAN EVPN(TRM) and MVPN function on the same device) offers operational flexibility to customers.

Continue reading

Cisco NX-OS VXLAN Innovations Part 1: Inter-VNI Communication Using Downstream VNI

In this blog, we’ll look closely at VXLAN EVPN Downstream VNI for intra-site and inter-site (Inter-VNI communication using Downstream VNI).

Segmentation is one of the basic needs for Multi-Tenancy. There are many different ways to segment,  be it with VLANs in Ethernet or VRFs in IP Routing use-cases. With Virtual Extensible LAN (VXLAN), segmentation becomes more scalable with over 16 million assignable identifiers called VNI (Virtual Network Identifier). Traditionally, VXLAN segments are assigned in a symmetrical fashion, which means it must be the same to allow communication. While this symmetric assignment is generally fine, there are use cases that could benefit from a more flexible assignment and the communication across VNIs. For example, Acquisition and Mergers or  Shared Services offerings.

During Acquisition and Mergers, it is pertinent to achieve a fast and seamless integration both for the business and the IT infrastructure. In the specific case of the IT infrastructure, we are aiming to integrate without any renumbering. This broken down to VXLAN, we want to provide inter-VNI communication.

In the case of Shared Services, many deployed segments are required to reach a common service like DNS, Active Directory or similar. These shared, or extranet, services are often front-ended with a firewall which avoids the need for inter-VNI communication. Nevertheless, there are cases where specific needs dictate transparent access to this extranet service and inter-VNI communication becomes critical.

There are different methods where inter-VNI communication is used. The most common cases with attached terminology are called VRF Route Leaking. In VRF Route Leaking, the goal is to bring an IP route from one VRF and transport or leak it, into a different VRF. Different needs are present in translation cases. For example,  when you want to represent a segment with a different identifier than what was assigned (think VLAN translation).

Downstream VNI assignment for VXLAN EVPN addresses inter-VNI communication needs, be it for communication between VRFs, or is it for use-cases of translating VNIs between Sites.

Use Case Scenarios

Downstream VNI for shared services provides the functionality to selectively leak routes between VRFs. By adjusting the configuration of the VRF Route-Targets (RT), you have the option to import IP prefixes into a different VRF. Downstream VNI assignment allows the egress VTEP (Downstream) to dictate the VNI used by the ingress VTEP (Upstream). This is to reach the network advertised by the egress VTEP, which would otherwise honor the configured VNI. Downstream VNI complements and completes the need for asymmetric VNI assignment and simplifies the communication between different VRF with different VNIs. For example, the Extranet/Shared Services scenario where a service (DNS Server) sitting in service VRF needs to share the services to all the hosts (servers in different VRFs). The Shared service VRF needs to a) import the multiple VRFs into its local VRF as well as should be b) able to support the disparate value of downstream VNI.

Similar as in the shared services use-case, Downstream VNI provides a method of Translating or Normalizing VNI assignments in a VXLAN EVPN Multi-Site deployment. Where traditionally the same VNIs have to be assigned across all the Sites, with Downstream VNI we can allow inter VNI communication on the Border Gateway (BGW). By aligning the Route-Target configuration between the BGW, Sites with different VNIs will be able to communicate. Exactly as explained for the prior use-case, the egress VTEP (Downstream) dictates the VNI to be used by the ingress VTEP (Upstream) For example, Normalization/Asymmetric VNI deployment scenario, when we are adding new Sites in VXLAN EVPN Multi-Site, on new Border Gateway (BGW), it may be desirable to use and stitch completely disparate values of VNIs.

Benefits

Seamless Integration and Flexible Deployments. With Downstream VNI we have the opportunity for more seamless integration of disjoint networks with the same intent. As a result, a much more agile and time-saving approach is available. For use-cases where Extranet/Shared Service scenario exists, a more flexible deployment option exists with Downstream VNI.

How it works

1. Upon receiving a route update on the ingress VTEP (Upstream), the route is being installed with the advertised VNI from the egress VTEP (Downstream). In short, the prefix is installed with the Downstream VNI.

2. As a result, the egress VTEP dictates the VNI used by the ingress VTEP to reach the respective network advertisement done by egress VTEP. This way, the ingress VTEP uses the right VNI to reach the prefix advertised by the egress VTEP when forwarding data to this peer.

3. The process of Downstream VNI is achieved by the egress VTEP (Downstream) publishing the VNI via BGP control-plane protocol to other receiving VTEPs, which will use this downstream assigned VNI for the encapsulation instruction to send data to the egress VTEP. Data traffic will always be sent with the Downstream VNI assigned to a prefix and will override the otherwise honored configured VNI.

4. The egress VTEP dictates the VNI to be used by ingress VTEP by performing the downstream VNI assignment via the BGP EVPN control-plane protocol.

In the above example, the VTEPs have disparate VNIs i.e. 50001 and 50002. If VLAN 20 with VRF-B needs to communicate to VLAN10 of VRF-A, the VTEP-1 (L3VNI 50001) will act as a Downstream VTEP and dictate VTEP-4 to use VNI 50001 to encapsulate the packets to reach VLAN 10 and vice-versa.

What’s Next?

Stay tuned for our next blogs which cover features and benefits for VXLAN EVPN based data center fabrics such as Loop detection and mitigation in VXLAN EVPN fabrics, deliver packets in secured fashion across VXLAN EVPN sites using CloudSec and seamless integration of multicast packet (TRM) with MVPN (Draft-Rosen).

Continue reading

Bolstering Cyber Resilience in the Financial Services Industry: Part Two

As you read in part one of this blog, Cybersecurity threats have never been greater. It is imperative that your financial services organization is prepared to detect and combat even the most sophisticated cyber-attacks. Cybersecurity month brought this issue top of mind for so many in the financial services world, and now it is time to put the information into action.

Last week we starting discussing the five-point strategy to bolster cyber resilience. We walked through the first two points: Secure by Design and Zero Trust. Now let’s jump into the final three elements of this strategy.

#3) Third Party Cyber Risk Assessment

As financial services firms continue to strengthen their cyber resilience, cyber threat actors have been working hard to identify vulnerabilities both internal and external to the firm to gain access to financial data. Most financial services firms have a large ecosystem of partners (customer service, software development, equipment providers, media and internet marketing, etc.) external to the firm, who augment the firm’s products and services with their own and/or play a critical role in developing, deploying, or maintaining the firm’s products and services. These ecosystem partners are all connected to the firms network, have access to critical financial data, and are expected to comply with the firm’s risk and compliance policies. Our research has identified that “70% of Financial Third-Party Vendors have Unacceptable Compliance to Regulations” and “do not have a focus on Insider Threats and Patching”.

Cisco’s Third-Party Security Assessment Program provides financial services firms with proactive services to validate security posture within the firm’s third-party vendors and provides direction for improvement of systems, processes to each vendor, including relevant training and certification support.

#4) Security Awareness Training (Employee Training)

It’s become evident that, often, the weakest link in many cybersecurity defenses are people. In fact, according to the 2019 Gartner Magic Quadrant for Security Awareness Computer-Based Training, “People influence security more than technology or policy and cybercriminals know how to exploit human behaviors.”

So, while technology continues to evolve, the human element will always be the most unpredictable variable to secure. In order to fortify against people-enabled losses, financial services firms are turning to security awareness and training programs. Recent events have highlighted an increased need for security awareness, as the transition to a remote workforce has unveiled new, targeted threats that require employees to detect on their own.

Cisco Security Awareness is designed to help promote and apply effective cybersecurity common sense by modifying end-user behavior. Using engaging and relevant computer-based content with various simulated attack methods, this cloud-delivered product provides comprehensive simulation, training, and reporting so employee process can be continually monitored and tracked; an important part of compliance standards such as HIPAA and GDPR.

#5) Cyber Insurance

Financial services firms are at huge financial risk when a data breach occurs. To protect themselves from such an eventuality and in light of the emerging advancement in data theft and manipulation threats, it is imperative that they protect themselves with cyber insurance. Aside from providing financial cover, these cyber insurance providers also provide their customers with advanced notification of threats. Cisco is part of an industry-first offering partnering with Apple, Aon, and Allianz to bring together the key pieces needed to manage cyber risk: security technology, secure devices, cybersecurity domain expertise, and enhanced cyber insurance (select markets only).

Now What?

It is evident that there has never been a more pressing time to evaluate your cybersecurity strategy. Once you walk through the five-points above, here is one final checklist to ensure you are maximizing your cybersecurity strategy.

For a financial services firm to have a robust cyber resilient strategy:

1. The cybersecurity practices of their third party partners as well as their own have to be regularly reviewed, audited and continuously enhanced.

2. There must be a security-first mindset from the CEO down to every employee and partner in the organization.

3. Employee awareness and training sessions on cyber hygiene best practices must be held regularly to prevent exploitable vulnerabilities and help minimize the impact of any data breach.

4. Firms must collaborate with the financial services industry participants to share learnings, best practices, and develop industry wide cyber resilience strategies

Take these tips and the (above) five point cyber resilience strategy to ensure that you are doing everything you can to secure your financial services organization.

Continue reading

Enabling Integration via Webex Teams – All Together Now

Enabling Integration via Webex Teams and Cisco DNA, SD-Wan, Intersight, Thousand Eyes via Cloud API Gateway

I was really excited to have a unique opportunity to put together a team of my fellow engineers to work on a Collaboration hacking contest within Cisco. This annual event is usually in-person for a day or two in San Jose, making it out of reach for my nomadic desert comrades located in Arizona. This year, however, remote is the new normal. This unique situation made it possible for my ragtag band of misfits to participate in events regardless of our geography. So we embarked on a mission to enable webhook integration for Webex teams, so that our products can send notifications into Teams, just as they can into email.

A cloud native yet cloud agnostic solution

In order to do this we decided to make sure this wasn’t only able to support diverse products, but also, diverse clouds. A cloud native, yet cloud agnostic solution based upon serverless infrastructure supporting standard webhooks and HTTPS Post messages. We decided on Google Cloud platform and Amazon Web Services for our multi cloud endeavor.

The initial idea was actually for a separate use case – I have esp8266 modules integrated with Teams for the use case of being notified when my garage door is opened/closed, my bearded dragon’s cage is hot, etc. As these scale in number, if I ever were to change my security bot token or room ID, I would have to go re-flash all of my IoT Sensors to match. So, it creates an operational problem for leveraging Teams as a IoT device receiver or third party integrator.

Enable cloud as an API gateway

The idea was to enable cloud as an API gateway to accept requests, do advanced security checks, and decouple the Webex Teams security and context information from what is flashed onto the sensors to better manage the lifecycle. But extending this to webbooks was a natural evolution that seemed to have the most immediate impact to customers. When Demo’ing some of our cloud technologies (Intersight, Meraki), customers saw that notifications can go to webhook or email, and naturally inquired about their Webex Teams integration.

By enabling the webhook capability, we immediately added support for all of our product sets that support webhooks to integrate with Webex Teams. And do so without requiring any change on either the product, or Webex Teams. We did want to have native “handlers” in the code to handle differences in webhook formatting between different products. For our project we created handlers for Cisco DNA Center and Meraki. We had started work on Thousand Eyes but didn’t have the lab instance able to send webhooks at the time we finished the project. The amount of effort to create and modify a handler is as simple as 20 minutes worth of effort ensuring that the JSON fields that you care about, are included in what is sent to Teams.

The code is available on Github

Of note, while the code should have been very consistent between solutions, there is a difference in how Google integrates their API with their cloud functions compared to AWS. The API gateway on GCP has been out for a while, but right now integration of the API gateway on Google for cloud functions is in Beta and does require a bit more lift to setup. I expect this will normalize as it is brought to market. I also want to caveat that by noting I was seeking a functional product, closer integration with GCP teams probably would have helped with how I managed some error handling in Cloud Functions to make it integrate with API GW.

Continue reading