Showcasing Cisco’s Commitment to Openness: VXLAN BGP EVPN with OpenConfig

The world of data center networks is evolving at an ever-increasing pace. Businesses are being faced with the growing complexity of scaling data center fabrics, while also ensuring the isolation and security of customer data. Fundamental to this isolation of customer traffic is network virtualization, of which Cisco has been a constant innovator. Over the recent years, VXLAN with BGP EVPN has emerged as the de-facto industry standard for network virtualization.

For as long as networks and virtualized networks have existed, the manageability and observability of these fabrics, have been critical concerns for network operators.

Standardization across platforms and vendors is critical to enabling network operators to achieve these goals. SNMP and syslogs have been widely used to gather data, to monitor and manage network devices. However, SNMP lacks the ability to capture the fidelity of data that operators require. Syslogs are unstructured and while easily human readable, are not easily interpreted by automation and monitoring systems.

Besides being at the cutting edge of architecting network fabrics and network overlays, Cisco has also been an innovator in open and programmable networks. The open NX-OS philosophy began with the ability to run on-switch applications, natively in NX-OS or in the isolated Guestshell environment, later adding off-switch automation solutions such as Puppet and Ansible which have seen widespread adoption. More recently industry standard APIs, models, and transports such OpenConfig, NETCONF, RESTCONF, and gNMI have become a core part of the open NX-OS strategy.

These two areas that Cisco has long been an innovator in, namely network virtualization and open programmable interfaces, came together in the most recent enhancements to the OpenConfig models, which now support VXLAN EVPN and as part of our most recent NX-OS 10.3(1)F release. Cisco built these enhancements in conjunction with industry partners, to provide simplified monitoring and automation capabilities to our customers.

EVPN: A brief explainer

In the context of an EVPN overlay, an EVPN Instance (EVI) is a Virtual Private Network (VPN). With the Cisco NX-OS VLAN-based approach to EVPN, this results in a single broadcast domain per EVI, and with this VLAN-based approach, the tenant VLAN is mapped to a single EVI. With this 1:1 mapping, the single broadcast domain or tenant is represented by a VLAN or a VNI.  The VLAN/VNI is associated with an EVI which provides the most granular control for importing routes.

What is OpenConfig?

OpenConfig is an informal working group of vendors and network operators collaborating together, to define declarative model-driven solutions for the management, monitoring and operation of networking devices. A core tenant of OpenConfig is focused on defining vendor-agnostic YANG models based to deliver a programmatic interface to achieve these goals.

EVPN with OpenConfig

Within the existing OpenConfig network-instances model, an EVI and associated constructs are now part of the existing network-instance/fdb hierarchy. The enhancements Cisco contributed to the l2rib container consists of a new container within the parent Forwarding Database (FDB) container. The L2RIB has 2 primary containers, the MAC table and the MAC-IP table as shown in Figure 1.

The MAC table represents the operational state for MAC address information, pertaining to each domain of the L2RIB. This consists of stateful leaves such as the MAC address, VLAN, EVI, and L2-VNI for a locally significant broadcast domain as well as the next hop data, such as an interface, or sub-interface.

The second container within the new L2RIB is the MAC-IP table, which consists of remote MACs learned via the control plane. Like the MAC table, it has stateful leaves such as MAC address, VLAN, EVI, and L2-VNI, but in addition, it also contains an L3-VNI and host-IP for the MAC-IP entries as shown below. This L3-VNI is used solely in the context of inter-subnet routing.

In addition to these enhancements within the L2RIB, there are also additional enhancements within the L2VPN container of the BGP Address Family Indicator/ Subsequent Address Family Indicator (AFI/SAFI) network instance, which together provide deep visibility into the overall state and routing of a Cisco NX-OS BGP EVPN fabric.

Better Together: NX-OS with OpenConfig

Cisco is excited to announce new capabilities within its VXLAN BGP EVPN solution with contributions to an opensource and industry standard solution such as OpenConfig. Cisco has a long-standing focus on industry standards and openness in mind. Together, Cisco NX-OS tied with these OpenConfig enhancements, provide deep visibility into both the routing and forwarding of an NX-OS VXLAN fabric and the applications that the fabric supports. These innovations and expanded capabilities are just the first set of results based on our contributions to OpenConfig.

Source: cisco.com

Continue reading

How to Prepare for Cisco 700-680 CSaaS Certification?

Cisco 700-680 CSaaS Exam Description:

This exam will test the knowledge of Account Manager/Presales engineers on the foundations of Cisco’s Collaboration SaaS solutions in order for them to effectively sell these cloud-based services. This exam is a requirement for the Cisco Collaboration SaaS Authorization Program.

A great way to start the Cisco Collaboration SaaS (CSaaS) preparation is to begin by properly appreciating the role that syllabus and study guide play in the Cisco 700-680 certification exam. This study guide is an instrument to get you on the same page with Cisco and understand the nature of the Cisco Collaboration SaaS Authorization Exam exam.

Cisco 700-680 Exam Overview:

• Exam Name- Cisco Collaboration SaaS Authorization Exam
• Exam Number - 700-680 CSaaS
• Exam Price- $80 USD
• Duration- 30 minutes
• Number of Questions- 35-45
• Passing Score- Variable (750-850 / 1000 Approx.)
• Recommended Training- Cisco SaaS Authorization Training
• Exam Registration- PEARSON VUE
• Sample Questions- Cisco 700-680 Sample Questions
• Practice Exam- Cisco Collaboration SaaS Practice Test

Cisco 700-680 Exam Topics:

• Webex Market Overview- 5%
• Webex Meetings, Webex Teams, Webex Devices, and Webex Edge- 30%
• Webex Calling- 5%
• Webex Control Hub, Webex security, compliance and Webex for developers- 30%
• Collaboration Flex Plan- 20%
• Overview of Ordering, Smart accounts and Webex Try and Buy- 10%

Related Article:-

Major Benefits of Investing in 700-680 CSaaS Cisco Collaboration SaaS Authorization Exam

 

Continue reading

New Learning Labs for NSO Service Development

Getting started with network automation can be tough. It is worth the effort though, when a product like Cisco Network Services Orchestrator (NSO) can to turn your network services into a powerful orchestration engine. Over the past year, we have released a series of learning labs that cover the foundational skills needed to develop with NSO:

◉ Learn NSO the Easy Way

◉ Yang for NSO

◉ XML for NSO

Now we are proud to announce the final piece of the puzzle. We’re bringing it all together with the new service development labs for NSO. If this is your first time hearing about Cisco NSO and service development, let’s review some of the context.

Why change is the only constant

Network programmability has been enhancing our networking builds, changes, and deployments for several years now. For the most part, this was inspired by Software Defined Networks – i.e., networks based on scripting methods, using standard programming languages to control and monitor your network device infrastructure.

Software-defined networking principles can deliver abstractions of existing network infrastructure. This enables faster service development and deployment. Standards such as NETCONF and YANG are currently the driving force behind these abstractions, and are enabling a significant improvement in network management. Scripting can take out a lot of laborious and repetitive tasks. However, it may still have shortfalls, as it can focus on single devices, one vendor, or one platform.

Service orchestration simplifies network operations

Service orchestration simplifies network operations and management of network services. Instead of focusing on a particular device and system configuration that builds a network service, only the important inputs are collected. The rest of the steps and processes for delivery are automated. The actual details, such as vendor-specific configurations on network devices and the correct ordering of steps, are abstracted from the user of the service. This results in consistent configurations, prevention of errors and outages, and overall cost reduction of managing a network.

Remove the complexity

With NSO services, service application maps input parameters to create, modify, and delete a service instance into the resulting native commands to devices in the network. The input parameters are given from a northbound system such as a self-service portal via an API (Application Programming Interface). This calls to NSO or a network engineer using any of the NSO User Interfaces such as the NSO CLI.

NSO Service Development Module

In this new NSO learning lab you will learn how NSO services simplify network operations, how they work, and how to develop a template-based service. You will also use Python for scripting and service development, and to develop nano services. The module is broken into three sections which will guide you through use cases of NSO Service Developments.

◉ Introduction to NSO Service Development – How NSO services simplify network operations, how they work, and how to develop a template-based service

◉ Python Scripts and NSO Service Development – Python Scripts and NSO Service Development

◉ NSO Nano Service Development – How to develop nano services in NSO

Try it yourself now

You can find the new NSO Service deployment module in the NSO Basics for Network Operations Learning Track. All these new learning labs can be run and tested in the NSO DevNet reservation sandbox.

One of the things I embrace as an engineer is that change will happen. It might happen overnight, or over an extended period of time. But, it will happen. The only constant in the networking and software industry is ‘change.’ Let’s embrace this!

Source: cisco.com

Continue reading

Service Chaining VNFs with Cloud-Native Containers Using Cisco Kubernetes

To support edge use cases such as distributed IoT ecosystems and data-intensive applications, IT needs to deploy processing closer to where data is generated instead of backhauling data to a cloud or to the campus data center. A hybrid workforce and cloud-native applications are also pushing applications from centralized data centers to the edges of the enterprise. These new generations of application workloads are being distributed across containers and across multiple clouds.

Network Functions Virtualization (NFV) focuses on decoupling individual services—such as Routing, Security, and WAN Acceleration—from the underlying hardware platform. Enabling these Network Functions to run inside virtual machines increases deployment flexibility in the network. NFV enables automation and rapid service deployment of networking functions through service-chaining, providing significant reductions in network OpEx. The capabilities described in this post extend service-chaining of Virtual Network Functions in Cisco Enterprise Network Function Virtualization Infrastructure (NFVIS) to cloud-native applications and containers.

Cisco NFVIS provides software interfaces through built-in Local Portal, Cisco vManage, REST, Netconf APIs, and CLIs. You can learn more about NFVIS at the following resources:

◉ Virtual Network Functions lifecycle management

◉ Secure Tunnel and Sharing of IP with VNFs

◉ Route-Distribution through BGP NFVIS system enables learning routes announced from the remote BGP neighbor and applying the routes to the NFVIS system; as well as announcing or withdrawing NFVIS local routes from the remote BGP neighbor.

◉ Security is embedded from installation through all software layers such as credential management, integrity and tamper protection, session management, and secure device access.

◉ Clustering combines nodes into a single cluster definition.

◉ Third-party VNFs are supported through the Cisco VNF Certification Program.

Figure 1: Capabilities of Cisco NFVIS

Virtualizing network functions sets the stage for managing container-based applications using Kubernetes (k8s). Cisco NFVIS enables service chaining for cloud-native containerized applications for edge-compute deployments to provide secure communication from data center to cloud to edge.

Integrate Cloud-Native Applications with Cisco Kubernetes

Cisco’s goal is to make it easy for both NetOps and DevOps to work together using the same dashboard to perform the entire process of registering, deploying, updating, monitoring VMs, and provision service chains with the easy-to-use Cisco Enterprise NFVIS Portal or Cisco vManage for SD-WAN. NetOps persona can perform each step of the VNF lifecycle management to deploy VNF-based service chains.

Cisco NFVIS now includes Cisco Kubernetes to provide centralized orchestration and management of containers. Cisco Kubernetes is available to download through Cisco’s NFVIS Software site. The current release supports the deployment of Cisco Kubernetes through NFVIS Local Portal and NFVIS APIs using existing NFVIS Lifecycle Management Workflows.

Cisco Kubernetes has a built-in Kubernetes Dashboard, enabling NetOps and DevOps Admins to use standard Kubernetes workflows to deploy and manage networking and application VMs. NetOps Admins acquire access tokens in NFVIS via the built-in GUI Local Portal or NFVIS CLI to access a Kubernetes Dashboard running inside Cisco Kubernetes. NetOps personas can execute their role in establishing VNFs and then hand off administration tokens to DevOps personas to access the Kubernetes Dashboard within Cisco Kubernetes. DevOps uses the dashboard to instantiate and manage their application containers. VNFs can be service chained with applications inside Cisco Kubernetes via an ingress controller that is deployed as part of a Kubernetes cluster to provide load balancing and ingress controls.

Figure 2: Kubernetes Dashboard inside Cisco Kubernetes

Cisco Kubernetes supports two deployment topologies:

◉ Single node is enabled in the current NFVIS 4.9.1 release.

◉ In future releases, multi-node topologies will enable capabilities such as high availability..

Figure 3: Cisco NFVIS Application Hosting Workflow

Collaborative Tools to Simplify Cloud Native Container Applications

Ops team collaboration is made possible by Cisco Enterprise NFVIS and Cisco Kubernetes to power tomorrow’s applications across clouds and edge use cases. Deploying service-chained VNFs has enabled NetOps to simplify support for distributed offices, devices, and applications. Now Cisco Kubernetes in Cisco Enterprise NFVIS provides DevOps with a familiar set of k8s workflows to deploy containerized applications from on-premises to cloud to edge, taking full advantage of the service-chained VNFs managed by NetOps.

Source: cisco.com

Continue reading

Rise of the Open NOS

Open networking Innovations are largely driven by an industry need to protect network platform investments, maximize supply chain diversification, reduce operating costs, and build a homogenous operational and management framework that can be consistently applied across platforms running standardized software. By virtue of its adoption by cloud scale operators and its most recent inclusion in the Linux Foundation, SONiC has gained tremendous momentum across different market segments. This blog outlines key factors relevant to SONiC adoption, its evolution in the open network operating system (NOS) ecosystem, and Cisco’s value proposition with the SONiC platform validation and support.

Why use an open NOS?

Disaggregation enables decoupling hardware and software, giving customers the ability to fully exercise plug-and-play. An open-source NOS like SONiC can provide a consistent software interface across different hardware platforms, allowing for supply chain diversity and avoiding vendor lock in, further leveraged by in-house custom automation frameworks that don’t have to be modified on a per-vendor basis. A DevOps-centric model can accelerate feature development and critical bug fixes, which in turn reduces dependency on vendor software release cycles. The open-source ecosystem can provide the necessary support and thought leadership to enable snowflake use cases prevalent in many network deployments. The freedom to choose can protect investment across both hardware and software, thus leading to significant cost savings that further reduce total cost of ownership (TCO), operating expenditures (OpEx), and capital expenditures (CapEx).

What is SONiC?

SONiC (Software for Open Networking in the Cloud) was created by Microsoft in 2016 to power their Azure cloud infrastructure connectivity. SONiC is Debian based and has a microservice based containerized architecture where all major applications are hosted within independent Docker containers. In order to abstract the underlying hardware and ASIC, SONiC is built on SAI (Switch Abstraction Interface)which is a standardized vendor neutral hardware abstraction API. The NOS provides north bound interfaces (NBIs) to manage the device and these NBIs are based on gNMI, ReST, SNMP, CLI, and Openconfig Yang models so it’s easily integrated with automation frameworks.

Figure 1. A conceptual overview of SONiC

 

Why SONiC?

With so many open-source options out there, why consider SONiC? This NOS is gaining strong community leverage with growing industry traction through its adoption by prominent players spanning different market segments such as enterprise, hyperscale data center, and service providers. Open-source contributions have honed SONiC for focused use cases, enriching feature delivery while holistically enabling different architectures. Below are a few factors that emphasize open NOS benefits as applicable to SONiC:

Open Source:

◉ Vendor independence – SONiC can run on any compatible vendor hardware

◉ Feature velocity – Custom feature additions/modifications and self-driven bug fixes

◉ Community support – Upstream code contributions benefit all SONiC consumers

◉ Cost savings – Reduced TCO, OpEx, and CapEx

Disaggregation:

◉ Modular components – Multiple independent containerized components for increased resiliency and easier plug-and-play

◉ Decoupling software functions – Individual components can be customized based on use case

Uniformity:

◉ Abstraction – SAI abstraction layer to normalize underlying hardware intricacies

◉ Portability – Feature portability as the SAI normalizes hardware complexity

DevOps:

◉ Automation – Unified orchestration/monitoring for compute and common NOS across platforms

◉ Programmability – SONiC provides options that can leverage ASIC capabilities to the fullest

Figure 2. The value proposition of SONiC

 

Where does SONiC fit in various use cases?

At a high level, the existence of a software feature on a SONiC-enabled system depends on the following three components:

1. SONiC operating system support – Community driven

2. SAI API support – Community driven

3. SDK support – Vendor driven

For a software feature to be built into SONiC, it needs to be facilitated at all the above layers to be fully productized. The current SONiC ecosystem is comprehensively built for IP/VxLAN and BGP based architectures. These technology components can be cross-leveraged to create any architecture of choice – whether it is a data center fabric or a CDN ToR. SONiC deployments today are predominantly observed in data centers and enterprises but can be easily extended to other networks that leverage similar technology components. Commonly deployed network roles and use cases with SONiC are outlined below:

Data center fabric and DCI – IP/VxLAN and BGP based:

1. Leaf (single and dual homed)

2. Spine

3. Super spine

These data center deployments are spread across different customer segments ranging from Tier1/Tier 2 hyperscalers, service providers, and larger enterprises.

Due to its strong community support, many working groups are collaborating on how to further extend SONiC for core and backbone use cases, amongst others. For example, the SONiC MPLS working group is looking at enabling MPLS and SR/SRv6 support for SONiC that are more applicable to WAN use cases.

SONiC in the real world

With all the benefits of an open-source NOS, network operators have many questions such as “Is SONiC the right fit for my use case?”, “How does support work?”, “How do I ensure code quality?”, “How do I train my team to build the skill set to manage SONiC?”, and the list goes on. Product adoption is always driven by customer experience. Any product or solution, open-source or not, will be successful only if it provides a seamless user experience. While the many merits of an open-source NOS are attractive, operators still want the security and partnership of a vendor NOS when it comes to support and field deployments. So how do we achieve the best of both worlds?

Network operators assessing SONiC either have a very strong self-driven ecosystem equipped to handle an open NOS or they’re trying to understand the deployability of an open NOS. Operators with a self-sufficient ecosystem tend to gravitate towards customized SONiC to suit their specific network requirements. This might involve customizing community SONiC to create a private distribution (BYO – build your own) or they can rely on external vendors that create commercial distributions built from community SONiC. On the other hand, operators trying to gain more experience with open NOS for relatively simpler use cases might want to rely on community SONiC, where there’s a fine balance in retaining the open-source nature of SONiC along with its validation on vendor hardware.

Figure 3. SONiC consumption model

While assessing a network rollout, there are certain evaluation criteria that an operator needs to consider. These evaluation criteria are independent whether the network solution in place is open or closed but depending upon the target ecosystem the responses to these criteria might differ.

Table 1. SONiC deployment evaluation criteria

The Cisco 8000 Series advantage

The high-performance Cisco 8000 Series of routers and switches is based on the Cisco Silicon One ASIC, making these devices three times more power efficient and twice as dense as industry incumbents. A wide variety of fixed and modular form-factors are available, while its power savings, run-time completion efficiency, and SDK portability offer unique advantages of the Cisco 8000 that greatly facilitate SONiC onboarding. As a strategic investment, every new platform is compatible with SONiC for the ability to leverage one silicon and one software end-to-end in different roles across use cases.

Figure 4. SONiC – The Cisco advantage

Support

The saying “With great power comes great responsibility” aptly applies to any open-source ecosystem. When deploying a production network, every operator is looking for holistic triage, faster resolution, predictable SLAs, and accountability. So how does this apply to SONiC?

Operationalizing SONiC on vendor hardware can be visualized as three layers. The bottom two layers consist of vendor-specific components – hardware systems at the very bottom followed by the infrastructure software that consists of SAI APIs, SDK, BSP/platform drivers, and other glue logic to seamlessly abstract hardware intricacies from the overlying operating system. By itself, SONiC looks like a constellation of open-source components and custom code, depending on whether customized SONiC is in play or not. With plug and play, accountability still sits with respective stakeholders for their components, leading to a shared responsibility support model. For Cisco-validated SONiC, every shipping platform will go through intensive customer and use case centric testing, with major and minor release cadence for community SONiC. Major releases will support newer features while minor releases provide bug fixes.

Figure 5. Shared responsibility support model

Source: cisco.com

Continue reading

Cisco Project, “An-API-For-An-API,” Wins Security Award

Enterprise software developers are increasingly using a variety of APIs in their day-to-day work. With this increase in use, however, it is becoming more difficult for organizations to have a full understanding of those APIs. Are the APIs secure? Do they adhere to the organization’s policies and standards?  It would be incredibly helpful to have a suite of solutions that provides insights to these questions and more. Fortunately, Cisco has introduced our An-API-For-An-API project to address these concerns.

Introducing

An-API-For-An-API (AAFAA) is a project that controls the end-to-end cycle for enterprise API services and helps developers, from code creation to deployment into a cloud, provisioning of API gateways, and live tracking of API use while the application is in production.  Leveraging APIx Manager, an open-source project from Cisco, it combines CI/CD pipelines where API interfaces are tested to enterprise (security) policies, automatic deployment of applications behind an API gateway in a cloud system, and dynamic assessment of the API service through.

Figure 1. provides an overview of how the various pieces of the AAFAA solution fit and work together. Let’s look at the pieces and what insights they each provide the developer.

Figure 1. AAFAA Suite

APIx Manager

The central piece of the AAFAA solution suite is an open-source solution, APIx Manager, which provides API insights to developers in the day-to-day developer workflow. APIx Manager creates a browser-based view that can be shared with the DevSecOps team for a single source of truth on the quality and consistency of the APIs – bridging a critical communication gap. All these features help to manage the API life cycle to provide a better understanding of changes to the APIs we use every day. These can be viewed either through the browser or through an IDE Extension for VS Code. APIx Manager can also optionally integrate with and leverage the power of APIClarity, which brings Cloud Native visibility for APIs.

By creating dashboards and reports that integrate with the CI/CD pipeline and bring insights into APIs, developers and operations teams can have a single view of APIs. This allows them to have a common frame of reference when discussing issues such as security, API completeness, REST guideline compliance, and even inclusive language.

APIClarity

APIClarity adds another level of insights into the AAFAA solution suite by providing a view into API traffic and Kubernetes clusters. By using a Service Mesh framework, APIClarity adds the ability to compare runtime specifications of your API to the OpenAPI specification. For applications that don’t yet have a defined specification, developers can compare an API specification against the OpenAPI or company specifications or reconstruct the Spec if it is not published.

Tracking the usage of Zombie or Shadow APIs in your applications is another critical security step. By implementing APIClarity with APIx Manager, Zombie and Shadow API usage is seen within the IDE extension for VS Code. Seeing when APIs drift out of sync with OpenAPI specifications or start to use Zombie and Shadow at runtime, especially in a Cloud Native application, is vital for the improvement of the security posture of your application.

Panoptica

Adding Panoptica to your AAFAA tool kit brings even more insights into your API usage and security posture. Panoptica provides visibility into possible threats, vulnerabilities, and policy enforcement points for your Cloud Native applications. Panoptica is an important solution as well for being a bridge between development and operations teams to bring security into the CI/CD cycle earlier in the process.

Let’s think about what this means from a practical, day-to-day standpoint.

AAFAA in Practice

As enterprise application developers, we are tasked with building and deploying secure applications. Many companies today have defined rules for applications, especially Cloud Native ones. These rules include things like using quality components, e.g., third-party APIs, and not deploy applications with known vulnerabilities. These vulnerabilities can come in the form of a wide variety of areas, from the cloud security posture, application build images, application configuration, the application itself, or the way APIs are implemented.

There isn’t anything new about this. How we achieve the goal of building and deploying secure applications has changed dramatically in the past several years, with the possibility of vulnerabilities ever increasing. This is where AAFAA comes into service.

AAFAA utilizes three main components in providing insights from the very beginning all the way until the end of an application development lifecycle:

- APIx Manager

- CI/CD pipelines & automatic deployment of applications, and

- dynamic assessments of the API service through APIClarity.

APIx Manager

With its built-in integration into development tools, such as VS Code, APIx Manager is the start of the journey into AAFAA for the developer. It allows developers to gain API security and compliance insights when they are needed the most. At the beginning of the development cycle. Bringing these topics to the attention of developers earlier in the development lifecycle, shifting them left, makes them a priority in the application design and coding process. There are many advantages to implementing a Shift-Left Security design practice for the development team. It is also a tremendous benefit for the Ops teams as they can now see, through APIx Manager’s Comparison functionality, when issues were addressed and if they were a developer, Ops, or joint problem that needed to be resolved or if there was something that still needs attention. From the beginning of the software development cycle to the end, APIx Manager is a key component of AAFAA.

CI/CD Pipeline & Automatic Deployment

With the speed at which applications are being produced and updates being rolled out as part of the Agile development cycle, CI/CD pipelines are how developers are used to working. When we thought about our API solutions, we wanted to bring insights into the workflow that developers already use and are comfortable with. Introducing another app that developers must check wasn’t a realistic option. By incorporating APIx Manager, for example, into the CI/CD pipeline, we allow developers to gain insights into API security, completeness, standard compliance, and language inclusivity in their already established work stream.

There continues to be tremendous growth in Cloud Native applications. Gartner estimates that by 2025, just a short three years away, more than 95% of new digital workloads will be deployed on cloud platforms. That’s an impressive number. However, as applications move to the cloud and away from platforms that are wholly controlled by internal teams, we lose a bit of insight and control over our applications. Don’t get me wrong, there are many great things about moving to the cloud, but as developers and operation professionals, we need to be vigilant about the applications and experiences we provide to our end users.

Dynamic Assessments

APIClarity is designed to provide observability into API traffic in Kubernetes clusters. As developers make the move to Cloud Native applications and rely more and more on APIs and clusters, the visibility of our application’s security posture becomes more obscured. Tools like APIClarity improve that visibility through a Service Mesh framework which captures and analyzes API traffic to identify potential risks.

When combined with APIx Manager, we bring the assessment level right to the developer’s workflow and into the CI/CD pipeline and the IDE, currently through a VS Code extension. By providing these insights into platforms, developers are already using, we are helping to shift security to the left in the development process and provide visibility directly to developers. In addition to security matters, APIx Manager provides valuable insights into other areas such as API completeness, adherence to API standards, as well as flagging company inclusive language policies.

As part of the An-API-For-An-API suite of tools, APIx Manager and APIClarity provide dynamic analysis and Cloud Native API environment visibility, respectively.

What Else?

Several teams here at Cisco have worked side-by-side to create AAFAA. It’s been great to see it all come together as a solution that will help developers and operations with visibility into the APIs they use. The AAFAA project has also been recognized with a prestigious CSO50 Award for “security projects or initiatives that demonstrate outstanding business value and thought leadership.” Please join me in congratulating the team for such a high honor for a job well done.

Source: cisco.com

Continue reading

Optimize and secure transit fleet management with visibility to connected devices and secure remote access

Children have been singing “The wheels on the bus go round and round” since 1939. What’s new today is the tech that keeps those wheels rolling safely and on schedule.

Transit fleet operators work towards achieving on-time performance and vehicle reliability in order to attain safety, cost, and ridership goals. That requires deploying new technologies to improve operational efficiency and predictability. Who doesn’t like a bus service that’s on-time, reliable, safe to ride and has other perks such as free WiFi?

Some ways transit fleet operators are increasing operational efficiency include leveraging vehicle telematics, remotely connected devices in the vehicle, real-time vehicle location, and Internet of Things (IoT) sensors. Together these devices and information provide critical data to the operations center via the Cisco Catalyst IR1800 Rugged Series cellular and Wi-Fi router.

Some of the connected devices on buses today include:

➣ Computer-aided dispatch and automatic vehicle location (CAD/AVL). These transmit route and real-time location information so dispatchers can see if the bus is on time, ahead or behind schedule.

➣ Vehicle telematics to monitor engine temperature, oil pressure, emissions, fuel economy, etc. in support of predictive maintenance.

➣ Fare collection systems for plastic card or mobile payment.

➣ Passenger counting, which is useful for route capacity planning and complying with pandemic-related occupancy restrictions.

➣ IP security cameras that capture video triggered by events like doors opening and closing or the driver pressing a distress button in the event of a disturbance.

➣ Voice communications between the driver and dispatch center.

Operational efficiency takes a hit whenever one of these connected devices, IoT sensors or the vehicle telematics system stops working because buses are often simply taken out of service when issues like these are reported. If the CAD/AVL system goes offline, for example, the fleet operator can’t provide accurate ETAs to passengers on digital signs and online schedules. Loss of the fare collection system results in revenue loss for the transit agency as passengers ride for free. Loss of a video camera feed might prevent the counting of passengers or visibility of a potential safety threat as passengers enter and exit the bus. And an outage on a vehicle telematics system might result in a breakdown that could have been detected and prevented—inconveniencing passengers and requiring the operator to assign an on-call driver and replacement vehicle to take over the route. That’s costly and inconvenient. As fleet operators grow and the number of vehicles that need to be supported increases, these issues are further magnified.

Visibility and secure equipment access boost operational efficiency

Now, fleet operators can quickly detect, assess, and fix problems with connected equipment using the Cisco IoT Operations Dashboard. It’s a modular cloud service with a simple user interface to help operations teams view important data about the health and operational status of connected equipment and sensors, using the IR1800 cellular Wi-Fi router (see Figure 1).

Figure 1 – IoT Operations Dashboard

In the figure above, each dot represents a transit bus. A red dot indicates that one of the connected devices on the bus is malfunctioning. One click shows which system has the problem—such as an offline fare payment system, security camera or passenger counting system. With one click, the operator can learn about the status of connected devices on the bus as well as the router.

With another click the operator can learn more about the failing device and open a remote session to the device, using one of several industry standard protocols, to diagnose the problem or view the device details – providing a fast solution to many problems.

Secure equipment access protects sensitive data from intruders

IoT security is top of mind for critical infrastructure like transportation systems, and we’ve designed IoT Operations Dashboard with Secure Equipment Access (SEA) to connected equipment on the bus. Using this SEA capability, transit Operator employees, or third-party service technicians log into the IoT Operations Dashboard with multi-factor authentication through their browser and use it for remote access to connected devices using common protocols such as SSH, RDP, VNC, HTTP, or serial terminal interfaces, and can even use a native desktop application. And all communication is encrypted over the cellular & Wi-Fi router, preventing unauthorized access (see figure below). This is the essence and power of secure remote access. Lastly, the IoT Operations Dashboard enables operations teams to securely meet the scale demands of today’s fleet operators.

Figure 4 – Secure Equipment Access (SEA) schematic

To sum up, the payoff for being able to securely view, monitor, and troubleshoot all bus connected devices, and IoT sensors from one interface is increased operational efficiency and lower costs. It’s simpler than ever to make sure “the doors on the bus go open and shut, all around the town.” On time, and safely.

Source: cisco.com

Continue reading