Finally – IPsec On A Catalyst Switch

The new Cisco Catalyst 9000X with IPsec support is finally a reality. I will quickly cover three use cases that are relevant to branch deployments.

Cisco introduced the Catalyst 9000X series, which includes the C9300X, C9400X, C9500X, and C9600X. I will mostly focus on the C9300X which supports IPsec today as of IOS-XE 17.6.2 with Advantage licensing. The C9400X will support IPsec soon.

Figure 1. Catalyst 9300X Industry first 100G Hardware Encryption and 1 Tbps stacking

 

The C9300X comes with a new enhanced Unified Access Data Plane (UADP) ASIC called the UADPsec.  This new ASIC allows for industry-first capabilities that allow the switch to perform up to 100G of Layer 3 hardware encryption and up to 1 Tbps of stacking.  It also helps enhance support for the application hosting capabilities common to all Catalyst platforms.

Figure 2. C9300X IPSec capabilities with IOS-XE 17.6.2

 

The good news is that the C9300X supports standards-based IPv4/IPv6 IPsec (up to 128) tunnels. It also has support for NAT Traversal, Multicast routing, Layer 3 Segmentation over IPsec, Layer 2 extension over IPsec, and even EVPN over the tunnel. 

Figure 3. C9300X IPSec Site-to-SIG, Site-to-Cloud, Site-to-Site

 

So, why is this needed? If you are an SD-WAN customer, then you already have an architecture in place. The Catalyst 9300X is not meant to be an SD-WAN replacement and it is an independent solution. It is meant for customers with the intention of reducing the number of devices at the branch office. For example, removing a router and/or firewall while creating a secure tunnel connection. If so, then look no further. The Catalyst 9300X can help you achieve it.

The Catalyst 9300X can help set up multiple secure tunnels. There are three common use cases. The first is Site-to-SIG. The Secure Internet Gateway (SIG) support can be to Umbrella, Zscaler, or any other third-party provider. The second is Site-to-Cloud, which can establish a secure tunnel to your Cloud provider of choice. The third use case is Site-to-Site. The C9300X can establish a secure tunnel to your Data Center firewall, router, or even another C9300X switch. These are at least three reasons why this platform is right for you.

Source: cisco.com

Continue reading

Be on Guard This Spooking Spanning Tree Season

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

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

It was a dark and stormy night…

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

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

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

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

Here is an example syslog message related to MAC Flapping:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Identifying the root bridge for the network

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

root#show run | sec spanning

spanning-tree mode rapid-pvst

spanning-tree extend system-id

spanning-tree vlan 1-4094 priority 16384

root#show span

VLAN0001

  Spanning tree enabled protocol rstp

  Root ID    Priority    16385

             Address     5254.000e.dde8

             This bridge is the root

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

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

             Address     5254.000e.dde8

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

             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type

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

Gi0/1               Desg FWD 4         128.2    P2p 

Gi0/2               Desg FWD 4         128.3    P2p 

Gi0/3               Desg FWD 4         128.4    P2p 

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

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

switch-1#show span

VLAN0001

  Spanning tree enabled protocol rstp

  Root ID    Priority    16385

             Address     5254.000e.dde8

             Cost        4

             Port        2 (GigabitEthernet0/1)

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

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

             Address     5254.0017.ae37

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

             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type

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

Gi0/1               Root FWD 4         128.2    P2p 

Gi0/2               Desg FWD 4         128.3    P2p 

Gi0/3               Altn BLK 4         128.4    P2p 

switch-1#show cdp neighbors gigabitEthernet 0/1

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID

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

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

Stopping a new root on the block… err, network

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

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

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

switch-1#show span

VLAN0001

  Spanning tree enabled protocol rstp

  Root ID    Priority    4097

             Address     5254.001e.82a2

             Cost        4

             Port        1 (GigabitEthernet0/0)

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

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

             Address     5254.0017.ae37

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

             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type

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

Gi0/0               Root FWD 4         128.1    P2p 

Gi0/1               Desg FWD 4         128.2    P2p 

Gi0/2               Desg FWD 4         128.3    P2p 

Gi0/3               Altn BLK 4         128.4    P2p 

switch-1#show cdp neighbors gigabitEthernet 0/0

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID

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

Total cdp entries displayed : 1

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

Bringing out the Guard… root guard, that is

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

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

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

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

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

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

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

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

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

switch-1#show span

VLAN0001

  Spanning tree enabled protocol rstp

  Root ID    Priority    16385

             Address     5254.000e.dde8

             Cost        4

             Port        2 (GigabitEthernet0/1)

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

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

             Address     5254.0017.ae37

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

             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type

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

Gi0/0               Desg BKN*4         128.1    P2p *ROOT_Inc 

Gi0/1               Root FWD 4         128.2    P2p 

Gi0/2               Desg LRN 4         128.3    P2p 

Gi0/3               Altn BLK 4         128.4    P2p  

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

switch-1#show spanning-tree inconsistentports 

Name                 Interface                Inconsistency

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

VLAN0001             GigabitEthernet0/0       Root Inconsistent

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

Take the scare out of spooky spanning tree with knowledge

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

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

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

Source: cisco.com

Continue reading

Introducing Cisco Cloud Network Controller on Google Cloud Platform – Part 1

This year has been quite significant for Cisco’s multicloud networking software evolution. Earlier in the year Cisco introduced, along with other exciting software features announcements, Google Cloud Platform (GCP) support for Cisco Cloud Network Controller (CNC), formerly known as Cisco Cloud APIC. This blog series introduces the GCP support capabilities subdivided into three parts:

Part 1: Native Cloud Networking Automation

Part 2: Contract-based Routing and Firewall Rules Automation

Part 3: External Cloud Connectivity Automation

The Need for Multicloud Networking Software

While organizations are increasingly becoming more mature with their to the cloud strategies, lately there has been a shift in focus to in the cloud networking, as also observed by Gartner in their first Market Guide for Cloud Networking Software and subsequent releases. This series will show how a cloud-like policy model can help addressing inside the cloud challenges with the aim to keep improving operations in public cloud environments and augmenting native cloud networking capabilities, as needed.

High Level Architecture

Google Cloud resources are organized hierarchically, and the Project level is the most relevant from the Cisco CNC perspective as a tenant is mapped one-to-one to a GCP project. Cisco CNC is deployed from the Google Cloud Marketplace into a dedicated infra VPC (Virtual Private Cloud) contained within a project mapped to the infra tenant, while user VPCs are provisioned in dedicated or shared projects associated to their own tenants within the Cisco CNC.

The Cisco CNC architecture on GCP is similar to that of AWS and Azure, as it also supports BGP IPv4 or BGP EVPN to on-premises or other cloud sites using Cisco Cloud Router (CCR) based on Cisco Catalyst 8000v. It also supports native GCP Cloud Router with Cloud VPN gateway for external connectivity. As for internal cloud connectivity, it leverages VPC Network Peering between user VPCs within the same or across regions as illustrated on the diagram below.

Native Cloud Networking Automation

A brief overview of the Cisco CNC GUI before proceeding. The left side of the GUI contains the navigation pane which can be expanded for visualization of cloud resources or configuration. The application management tab is where one can go to make configurations, or alternatively, use the blue intent icon at the top right which provides easy access to various configuration options.

To demonstrate how Cisco CNC automates inter-region routing across VPCs, let’s build a simple scenario with two VPCs in different regions contained within the same user-tenant project called engineering. Note that the same scenario could exist with these two VPCs in the same region, as VPC networks in GCP are global resources and not associated to any region, unlike subnets which are regional resources.

Provisioning VPC Networks and Regional Subnets

The first step is to create a Tenant and map it to a GCP Project as depicted below. The access type is set to Managed Identity, which allows Cisco CNC to make changes to user-tenant projects by means of a pre-provisioned service account during the initial deployment.

The configuration below illustrates the creation of two Cloud Context Profiles used as a mapping tool for a VPC. It is contained within a Tenant and provides the region association to determine which region(s) a VPC gets deployed to, along with regional subnets. Additionally, a Cloud Context Profile is always associated to a logical VRF.

Profile for vpc-1

Profile for vpc-2

By creating these two profiles and mapping to VPCs in different regions, each with their respective CIDR and subnet(s), the Cisco CNC translates them into native constructs in the Google Cloud console under VPC networks as seen below. Note that the VRF name defines the name of the VPC, in this example, network-a and network-b.

Cisco CNC GUI provides the same level of visibility, under Application Management where additional VPCs can be created or under Cloud Resources.

Route Leaking Between VPCs

For this scenario, a route leak policy is configured to allow inter-VRF routing which is done independently of contract-based routing or security policies to be reviewed on part 2 of this blog series. As seen previously, the VRF association to a particular VPC is done within the Cloud Context Profile.

While the “Add Reverse Leak Route” option is not depicted for brevity, it is also enabled to allow for bi-directional connectivity. In this scenario, since it is only inter-VPC route leaking, VRFs are labeled as internal and all routes are leaked.

In the GCP console, it automates VPC network peering between network-a and network-b with proper imported and exported routes.

Peering routes are auto generated for both VPCs, along with default routes automated during VPC setup.

Continue reading

Vacations and IT Operations: Save Time with the Right Tools

You have just used an online travel aggregator site to plan your summer vacation. The day of your trip arrives, you’re exhausted before you even set foot on the beach. Getting to the airport, boarding the first of two flights, making a connecting flight, and picking up luggage all wear you out. Your goal is the beach, but to get to it you’ll spend considerable time on tactical, non-value add, operational logistics.

Relax. You’re a smart traveler – Your TSA Clear approval saves you that long queue at the security checkpoint. Your Platinum travel partner membership gives you priority check-in for your flight and hotel. These tools shorten the time to get to the beach while allowing flexibility in planning your schedule. Wish you could have something similar, to manage your IT operations? Stick with me.

Where ITOps Teams Lose Time

As an IT manager, you’re expected to make sure your company is providing an outstanding digital experience that’ll drive revenue and growth. That’s the end goal. But to get there you’ll have to support your DevOps team through not just the development process but the ongoing application lifecycle. Multiple tasks to get to your goal, like getting to the beach, likely wear down your team, from deploying infrastructure, figuring out how to deploy and manage containers for cloud-native apps, and making your best estimate at provisioning resources in the public cloud. Task switching between tools and learning Kubernetes takes away valuable time and slows down service delivery. A missed flight connection is like a missed task, and something you want to avoid.

Simplify deployment and delivery, anywhere

Intersight bridges the gap between ITOps and DevOps

Cisco Intersight can help you move faster and more reliably, bridging the divide between dev teams and LoB with operations, and changing the perception of IT from a “necessary cost center” to an innovation driver. From one dashboard, you can:

◉ Add resources to your virtualized datacenter.

◉ Set up a new off-the-shelf application for your users.

◉ Stand up a Kubernetes cluster at the edge in just a few clicks.

◉ Provide multi-cloud resources for your developers to deploy code.

◉ And more

Managing and deploying all physical and virtual infrastructure and supporting any workload type (VMs, K8s in VMs, bare metal K8s, serverless) in one place saves your teams from switching tools. The user-friendly automation of Intersight with API-based integration gives your internal customers flexibility to use the resources the way they want.

Integrate with DevOps to accelerate application delivery

Intersight integrates with cloud providers and supports an ecosystem of 3rd party tooling

Intersight brings together the tools your IT Operations knows and integrates with tools your dev teams are using. As an open, cloud-neutral platform it integrates with cloud providers and supports an ecosystem of third-party tooling, so your internal customers can continue using the platforms and software of their choice—without disruption.

The result? Your team can move faster and expose with IaC plans that your developers are used to working with or orchestrating across every infrastructure and workload aspect of your Intersight-managed environment while managing risk and governance. And with open API support, you can extend and integrate with ITSM tools or 3rd-party endpoints for more control.

Accelerate service delivery and flexibility with Cisco Intersight

You know how to minimize the headaches that stand between you and the beach. Now you can apply smarter ways of working to deploy and support business critical applications. Get out of the business of managing management products and focus on accelerating delivery for line-of-business.

Source: cisco.com

Continue reading

Cisco Announces Open Source Cloud-Native Offerings for Securing Modern Applications

Today at KubeCon + CloudNativeCon North America 2022 in Detroit, Cisco unveiled FunctionClarity, a new open source project which helps developers secure the serverless functions that fundamentally reduce the amount of code necessary to create and deploy cloud-native applications.

Based on SigStore, FunctionClarity lets users sign the code of serverless functions, and authenticate their integrity from a trusted pipeline, when deployed across any cloud environment. It allows both keyless and key pair methods to eliminate exposure of the code at runtime.

The launch of FunctionClarity comes as the use of serverless technologies is growing exponentially. For example, AWS (Amazon Web Services) Lambda functions are now invoked 3.5 times more often compared to just two years ago.

OpenClarity is a trio of projects

FunctionClarity is the third chapter in the OpenClarity set of open source projects which help solve problems around application security, the software supply chain, and the “Shift Left” movement in software development that fully considers security from the outset.

Chapter 1: At KubeCon North America in 2021, Cisco released APIClarity, an open source API tool for visualizing and identifying potential risks such as API drift, shadow and zombie APIs. It builds and analyzes the OpenAPI specifications for all APIs in your environment.

Chapter 2: In May at KubeCon Europe 2022, we followed with the release of KubeClarity, an open source tool for detection and management of Software Bill of Materials (SBOM) and vulnerabilities of container images and filesystems. It scans both runtime Kubernetes clusters and CI/CD pipelines for enhanced software supply chain security.

Building the Application-First Future

Modern, distributed application software solves real-world business problems. Increasingly, those software assets come from everywhere – internal, cloud, SaaS, open source – run anywhere, and are accessed from anyplace via APIs and service calls.

In this distributed environment, the expanding attack surface for these applications includes APIs and serverless interfaces, vulnerable services, and opaque software assets. It’s no surprise APIs and service endpoints have become preferred threat vectors with the average company experiencing a 95% rate of API security incidents. There has been a 540% increase in the number of API-related security vulnerabilities recorded in the OVE database between 2015 and last year.

Transparency about your software tools and assets, and the security of APIs and interfaces, from development all the way through to production are therefore critical to ensuring you, your customers and end users are protected.

Panoptica brings 360-degree visibility and remediation options to your application attack surfaces in a single, modular application-security solution. As a freemium SaaS service that’s easy to get started and consume, it connects through your application SDL workflows, toolchains, and runtime to help your teams shift everywhere. It lets developers, SREs and security experts seamlessly collaborate within the same environment.

Nikolas Mousorous, DevOps Engineer, Marlow Navigation: “Existing security solutions we had in our environment couldn’t address our transition to modern microservice-based applications. Working with Panoptica, we were able to insert security controls into our complex environment seamlessly for secure application deployment and connectivity.”

Calisti is a complementary solution that provides discoverability, connectivity, SLO, and lifecycle management across all your application services – from greenfield, cloud-native applications to hybrid, traditional, and cloud-based applications. Calisti integrates seamlessly into your cloud operating environments, and allows your SRE, DevOps and cloud platform teams to easily connect, scale and manage the performance of application services across virtual machines (VMs), Kafka instances, and Istio service meshes, across any cloud or on-premises footprint.

Cisco Leading in Open Source

Cisco is taking an increasingly leading role in open source, stepping up contributions and driving the open source movement forward across the enterprise application ecosystem.

We have been a Platinum Member of the Cloud Native Computing Foundation (CNCF) since it was founded, and we have been Diamond Sponsors of KubeCon for every year since its inception. We also serve as members of the steering committee for the Linux Foundation’s TODO Group, we are a Platinum sponsor of Open Source Security Foundation (OpenSSF), LF Networking, LF Public Health, and we are Gold or Premier for Open19, Linux Foundation, and the Bytecode Alliance.

Along with the trio of OpenClarity projects, we have launched, maintain, and contribute to many other cloud-native projects including Dex, Bank Vaults, Istio Operator, K Operator, Logging Operator, Zot, and Network Service Mesh, and we are among the top five contributors to OpenTelemetry.

Calisti and Panoptica are both built on the open source foundation of the above-mentioned projects.

Join Us at KubeCon in Detroit

Come see Cisco at KubeCon + CloudNativeCon North America 2022 this week at the Cisco Solutions Showcase, Booth D3 in Exhibit Hall B, at Huntington Place in Detroit. There you can view a demo of FunctionClarity and learn more about the emerging Security, Observability, and Connectivity solutions Cisco is building. You can also find out about the latest open source projects at Cisco, including how to contribute and collaborate.

At the Cisco booth, you can get your own personalized hoodie, choosing from multiple designs to make an amazing statement, and even watch it get printed. In addition, for every theatre session and demo attendee, Cisco will donate a pair of socks to local Detroit homeless shelters so we can all give back to the community.

Source: cisco.com

Continue reading

Free Tool Helps You Visualize and Understand YANG Models

All YANG Suite, all the time

Are you interested in automating the process of viewing operational data or configuring network devices remotely? YANG models are the foundation to automation and programmability for Cisco IOS XE devices. Not sure where to start? Cisco YANG Suite is a free tool to help understand and visualize Yet Another Next Generation (YANG) models ranging from standards-based models such as OpenConfig and IETF to Cisco native models. Start using YANG Suite today to become a programmability pro!

The previous releases of YANG Suite include the set of Core Plugins and support for NETCONF, RESTCONF, gNMI, and gRPC telemetry as well as a Python script generator for payloads created within YANG Suite. To simplify your programmability and automation journey, the third release introduces four additional features: gRPC Telemetry with TLS support, SNMP OID to YANG Xpath mapping, Ansible integrations and PIP installation.

Let’s dive into the new YANG Suite features included in the third major public release.

Secure gRPC Dial-Out using TLS

With increased security threats comes the need for secure telemetry. Now, YANG Suite provides support to upload the necessary certificates and keys to implement Transport Layer Security (TLS).

Simplify the SNMP to YANG Transition

Simple Network Management Protocol (SNMP) has been become a standard method to understand and work with network devices. However, the new approach is to use YANG models to remotely query network devices for operational data or to configure the devices. To facilitate the transition from SNMP to YANG, YANG Suite provides the option to add an object identifier (OID) and YANG Suite will perform an SNMPwalk to locate the corresponding Xpath. Additionally, you can validate that SNMP and the newly-found YANG model return the same data directly within YANG Suite—sweeeeet!

Replicate Custom YANG Payloads with Auto-Generated Ansible Playbooks

Quickly and easily generate an Ansible playbook for a NETCONF, RESTCONF, or gNMI payload built in YANG Suite. This can help you run your favorite payloads across multiple devices. All you need to do is build up a payload using our protocol of choice and select “Replays” and the “Generate ansible playbook” button. Now, sit back, relax and let YANG Suite generate Ansible playbooks for you.

Docker or Pip? You decide.

Previously, YANG Suite was accessible using Docker containers. Now, in addition to Docker, we can now install YANG Suite using PIP. Check out the examples below:

That’s a wrap!

With the third YANG Suite release, we introduce:

◉ gRPC Telemetry with TLS Support

◉ SNMP OID to YANG Xpath mapping

◉ Ansible integrations

◉ PIP installation

Source: cisco.com

Continue reading

An Introduction to Understanding FFIEC Regulations

Regulatory requirements are a key operational concern that we hear about from our financial customers. As a key provider of technology for mission-critical financial system infrastructures across the globe, Cisco is held to the highest levels of scrutiny in the financial services regulatory audit chain. We have helped customers navigate the complex requirements and landscape to help keep them protected, when 100% of their business, relies on our equipment in the value chain.

A key challenge is managing iterations of infrastructure in global financial enterprises which have spanned 50+ years of digitization. These systems are continually being updated with newer and better ones; however, it takes a long time to sunset the legacy technology.  This leads to many generations of installed technology sets with diverse hardware and software systems, all that need to be tracked and managed, secured, and audited. Regular external examination is a necessary challenge to ensure hygiene of these systems are maintained amidst a backdrop of increasing cyber risk.

Streamlining the IT audit process

The Federal Financial Institutions Examination Council—or better known as the FFIEC—is a formal U.S. government interagency body charged with helping streamline the audit process. A number of our financial institution customers are regulated by multiple, and different, regulatory bodies. In the U.S. a few agencies include the Federal Reserve (FRB), the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administration (NCUA), the Office of the Comptroller (OCC), and the Consumer Financial Protection Bureau (CFPB). Without consistency, if every agency had their own examination criteria for assessment it would be exceptionally difficult for financial institutions to get work done.

To help streamline audit, the FFIEC as an interagency body, creates uniform principles, standards, and report forms for federal examinations of financial institutions. Having a consistent set of audit criteria and forms, a financial institution can have one audit that satisfies numerous federal regulatory agencies and keeps it a level regulatory playing field. The FFIEC’s scope is much broader than simply the IT aspects of digital financials, as it includes credit markets, fraud, BSA/AML, liquidity, and other areas of interest for regulatory bodies.

IT Governance in Financial Services

Over the next few weeks and months we’ll be contributing blogs that will focus on the FFIEC’s requirements in the information technology space, covering the below distinct areas:

◉ The Cybersecurity Maturity Assessment and how to use it

◉ The 2021 Updates in the Architecture, Infrastructure, and Operations book

    ◉ Hardware and Software Lifecycles

    ◉ Common Risk Management Topics: Architecture, Data, IT

    ◉ Infrastructure Management

    ◉ Operations and Operational Processes

◉ Cisco tools that can satisfy regulatory governance requirements

The goal for this series of blogs is to help the IT teams of financial institutions be aware of the regulatory concepts dealt with further upstream in an organization, and to promote tools that simplify the hardening of systems and streamlining audits.

Source: cisco.com

Continue reading