Cisco Catalyst 9200CX now orderable!

Now is the time to make sure your network is ready for a hybrid world where the workplace is anywhere, endpoints could be anything, and applications are hosted all over the place.

Extending the power of the secure network as close to the edge as possible helps you to better respond to the unexpected… transforming the challenges of hybrid work into opportunities for innovation.

Introducing Cisco® Catalyst® 9200CX compact switches

Figure 1: Catalyst 9200CX 12 port

As part of the Catalyst 9000 family, these highly anticipated compact switches bring IOS® XE and enterprise-class access down to the very edge with an extra level of security, and the features required to handle our ever-changing world of hybrid work.

The new compact Catalyst 9200CX models are optimized for flexibility and security and are ideal for

◉ Fiber to the edge

◉ Small branches

◉ Healthcare, retail, hospitality, sports, media, and entertainment

◉ smart building retrofits

◉ places where space is at a premium and quiet operation is a must.

The smaller footprint and quiet, fan-less design means Catalyst 9200CX compact switches can go in places other switches cannot, like on or under a desk, mounted on the wall or ceiling, or in a closet, hospital room, or classroom. But at the same time, they offer many advanced features that are firsts for a compact switch:

◉ MACsec-256 encryption

◉ Full flexible NetFlow/IPFIX

◉ Plug-and-play zero-touch provisioning

◉ SD-Access edge node capabilities with 16 VNs!

And to top it off, they’re also IPsec, AVB/PTP, and BGP EVPN hardware ready. 

The Catalyst 9200CX is designed to allow you to secure your network from the inside out, applying continuous zero-trust security anywhere you need it, and often extending your network to places it has never been before.

Whether in the board room or the bedroom, at the checkout counter, or the check-in desk, don’t box in your network to a traditional workspace or workplace; embrace the future of hybrid work with Catalyst 9200CX compact switches.

Source: cisco.com

Continue reading

Cisco Catalyst 9300X – IPsec And Cisco Umbrella

In this blog, you will learn how to configure IPsec and Cisco Umbrella tunnels on a Catalyst 9300X by onboarding it with the Plug and Play (PNP) Cloud Service and Cisco DNA Center.

This capability is supported with Cisco DNA Center 2.3.4. The switch will need IOS-XE 17.8.1 for onboarding and an Advantage license. The IPsec feature on the switch requires an HSEC K9. Please refer to Part 1 of this series to understand at least three use cases that can leverage IPsec on a Catalyst switch.

PnP Cloud Service (Onboarding C9300X with IPsec)

The onboarding section below assumes that the switch only has direct internet and requires a secure connection back to Cisco DNA Center for management. Traditionally a switch has access to a local PnP Server but with this lean branch deployment with just the 9300X connectivity back to a PnP server is highly unlikely.

Figure 1. Day 0 Automation Workflow for onboarding Catalyst 9300X

Cisco has augmented the PNP Connect with Plug and Play as a Service (PnPaaS). This enhancement allows Cisco DNA Center to send the Day 0 switch configuration file to the PnP Cloud Service. Once the switch sends its PnP request to devicehelper.cisco.com, the PnP Cloud Service responds with the configuration file. This allows the switch to establish the IPsec tunnel and for Cisco DNA Center to manage the newly onboarded switch.

Figure 2. Onboard Catalyst 9300X Device using PnP Cloud

So, how do you create the Day 0 configuration file? Easy, it’s pretty straightforward. Just go to Cisco DNA Center Provision –> Services –> Secure Tunnels and click on Onboard New Device. The form will ask for a Site and a Virtual Account where the switch is associated. Once this information is confirmed, the form can be completed with the following: the switch serial number, a management IP (resulting in a loopback address on the switch), the IP address of the Head-End (or remote side), an IPsec pre-shared key, the HSEC token, and a switch hostname. If the switch already has the HSEC token pre-installed from manufacturing at the time of purchase (it requires a selection in CCW), then the HSEC token entry does not need to be filled in. To look at the configuration file prior to its implementation, select the Day-0 Configuration Preview tab.

Figure 3. Cisco DNA Center Plug and Play Status

After selecting the Onboard Device option, the onboarding status of the switch can be verified under Provision –> Network Devices –> Plug and Play. Initially, the switch will appear as Unclaimed, and the state as Planned. When the process completes (please be patient, it will take several minutes) the switch appears under Provisioned and the state as Provisioned.

Figure 4. Cisco Catalyst 9300X with IPsec in Inventory

After the switch is onboarded, it can be managed over the IPsec tunnel using the loopback by selecting Provision –> Network Devices –> Inventory.

Cisco Umbrella – Creating Secure Tunnels

Now that the switch is under Cisco DNA Center management, additional IPsec tunnels can be configured to connect to a Secure Internet Gateway (SIG). In this case, it will be to Cisco Umbrella, but it can also be to a third party like Zscaler. In order to automate both sides of the tunnel the switch and Cisco Umbrella there is a prerequisite to integrate Cisco Umbrella and Cisco DNA Center using API Keys (System –> Settings –> External Services). This topic is not covered here. Cisco DNA Center will only automate the switch portion when the API integration is not established.

Figure 5. Cisco Umbrella IPsec Tunnel Creation in Cisco DNA Center

In order to add the Cisco Umbrella tunnels, go to Cisco DNA Center Provision –> Services –> Secure Tunnels but this time click on Create Secure Tunnel. The form will require the following information: Site, Device, number of Cisco Umbrella tunnels (up to 4), Tunnel Name, and Tunnel Source Interface. In addition, a selection of the Cisco Umbrella data center location can be made, otherwise, the selection will be made based on the switch site location. If you have more than one tunnel, either the same data center or a different location can be selected.

Figure 6. Cisco Umbrella IPsec Pre-Shared Key in Cisco DNA Center

The next screen will ask for the Cisco Umbrella Tunnel Pre-Shared Key and the option to change the default IKEv2 and Transform Set values. The default values are for best practice and should not be changed unless it is for interoperability or other security reasons.

Figure 7. Handling Site Traffic using ECMP or PBR

In the next screen, traffic can be handled either by sending all traffic to Cisco Umbrella using Equal-Cost Multi-Path (ECMP) load balancing when using multiple tunnels or traffic can be steered using Policy-Based Routing (PBR). Handling the traffic in this manner should help with most use cases. Subsequently, there will be a summary screen and a selection to create the tunnel(s).

Figure 8. Cisco DNA Center and Cisco Umbrella Tunnel Confirmation

After the switch and Cisco Umbrella have been provisioned, the status of the tunnels can be verified under Cisco DNA Center Provision –> Services –> Secure Tunnels.

Figure 9. C9300X IPsec Tunnels Cisco DNA Center and Cisco Umbrella

The IPsec tunnel information to both Cisco DNA Center and Cisco Umbrella can be verified via the CLI as well. Tunnel1 is the tunnel to Cisco DNA Center and Tunnel2 is the tunnel to Cisco Umbrella.

Figure 10. Cisco Umbrella UI IPsec tunnel to C9300X

Alternatively, Cisco Umbrella can also display the IPsec tunnel established to the Catalyst 9300X.

Source: cisco.com

Continue reading

High Availability – Features in Cisco IOS XE Software Makes It Appear Seamless

High availability (HA) networks continue to function even when some components fail. A variety of features in Cisco IOS XE Software provide hardware and software redundancy that contribute to five nines (99.999%) uptime, which translates to no more than 5.26 minutes of downtime per year. That’s the kind of reliability that Cisco customers have come to expect. Thousands of Cisco engineers in offices throughout the world make it possible.

This is the first in a series of three blogs that describe significant features in Cisco IOS XE that contribute to HA in the enterprise.

Stack Manager

Cisco Stack Manager is a platform-independent discovery protocol that provides failover from active to standby switches in case the active switch experiences a failure. Available on Cisco Catalyst 9000 series, it enables a switch to discover peer nodes, verify their authenticity, raise alarms in case of a mismatch, allocate a unique switch number during discovery, and assign a HA role (e.g., active, standby, and member in one type of configuration). In case of failover, switchover, or a reload of the active switch card, the standby switch takes over.

After Stack Manager assigns roles to the switches (e.g., Active, Standby, Member), the Cisco IOS XE redundancy framework enables the control plane protocols to synchronize configuration data to the standby node. Standby protocols remain in a hot state so the standby switch can become active in case of a failure.

Stack Manager works in three different HA configurations, which will be described in an upcoming blog:

1. Switch connected via stack cable to up to eight nodes

2. Switch connected via StackWise Virtual Link to up to two nodes

3. Dedicated HA interface for wireless devices like controllers

Cluster Manager

Cluster Manager is an adaptation of Stack Manager for use with Cisco Next Gen StackWise® Virtual Link, which provides the ability to virtualize two connected switches into a single virtual switch. Cluster Manager enables the same standby/active failover features provided by Stack Manager, with the added ability to provide HA across an entire data center environment using Next Gen StackWise Virtual Link. Virtualization eliminates the need to physically stack switches on top of each other. Soon, Cluster Manager will be able to support HA in switch clusters across different geographically dispersed locations.

Redundancy Management Interface

The Stack Manager solution connects switches in a ring up to 8 switches but in configurations using StackWise Virtual Link and in wireless deployments, there is only a single interface between two nodes: one active, one standby. So, two technologies were created to handle split-brain-related HA scenarios in these configurations: Redundancy Management Interface (RMI) and Dual Active Detection (DAD).

RMI adds another interface to wireless controllers so that if one interface falters or fails, the other will take over to handle HA, first determining if it is an actual failure or just a momentary glitch. If it is an actual failure, RMI provides the redundant connection to ensure that if the active switch goes down, the standby takes over.

Dual Active Detection

For deployments using StackWise Virtual Link, if the connection between the active and standby switches is lost, if one switch fails over to the second, the Dual Active Detection (DAD) process is activated. It queries the node manager for the existence of the lost peer. If it is available, it sends a recovery handshake. Once the handshake is completed, if the lost connection was due to a momentary glitch, the standby switch goes into recovery mode. If the switch is experiencing a failure, the other switch goes into recovery mode and assumes the active role.

Operational Data Manager

All processes in active switches update the database and the database maintains the device’s state. Since the standby doesn’t communicate to the outside world, when it is updated by the active switch, it uses Operational Data Manager (ODM) to update the database. ODM uses Replication Manager to trigger all the data to sync from an active to a standby switch. The update first goes to the DB and then out to update the processes in the hot standby switch.

Symmetric Early Stacking Authentication

Symmetric Early Stacking Authentication (SESA) imposes authentication when one Catalyst 9000 series switch interacts with another and encrypts and decrypts all the remote inter-process communication between them to guard against hacking attempts. It works alongside standard stacking, StackWise Virtual Link, and wireless HA solutions and is Federal Information Processing Standards (FIPS) compliant.

Extended Fast Software Upgrade

In the past, reloading software on Cisco platforms could take 6-7 minutes. Now, with Extended Fast Software Upgrade (xFSU), the process is reduced to 30 seconds or less. This fast reload feature for Catalyst 9300 series switches decreases downtime during reload ― the hardware is never powered off and traffic keeps flowing ― while maintaining the control plane in an operational state during the reload process.

Graceful Insertion and Removal

Network admins may wish to remove a network device from the network to perform troubleshooting or upgrade operations. To remove one device and replace it with another, the Graceful Insertion and Removal (GIR) function notifies the protocols of both devices that there is a maintenance window but not to go down. When the platform undergoing maintenance comes back online, it goes immediately into production without having to recreate the sessions it missed, minimizing traffic disruption both at the time of removal from the network and during insertion back into the network.

Hot Patching

Another area that contributes to HA is hot patching. Cisco issues small micro images containing only the code necessary for a critical bug or security fix. Customers can install it on devices in a fraction of a second using hot patching without any network disruption. Hot patching doesn’t result in a device reload and the fix takes effect immediately. Because of the small size of the patches, they are easy to distribute. Because of their limited content, customers can have much higher confidence in installing these micro patches in their production network without going through the complete validation process. The Cisco IOS XE hot patching feature is a toolchain of integrated technology and is expected to provide a default hitless defect fix.

ISSU

With the in-service software upgrade (ISSU) feature, Cisco customers using Cisco IOS XE products with HA functionality, including both routing and switching platforms, can avoid disruptions from image upgrades. ISSU orchestrates the upgrade on standby and active processors one after the other and then switches between them in the control plane so that there is zero effective downtime and zero traffic loss. The Cisco IOS XE software stack has the ability to do ISSU between any–to–any releases and the development team has an elaborate feature development testing and governance process to ensure this happens without failures occurring. Cisco defines policies for a smooth ISSU experience based on platform and releases combinations.

An Ongoing Quest for High Availability

Handling failover at the device level seems straightforward, with automatic features guiding active, standby, and sometimes member switches that are all waiting in line. (For Cisco ASR 1000 routers, active and standby route processors also provide failover and HA, much like Catalyst 9000 series switches.) But for Cisco engineers working on Cisco IOS XE solutions, HA is an ongoing, complex challenge, with vulnerabilities addressed by the many solutions above.

Source: cisco.com

Continue reading

Kenna.VM Premier: Accelerate Vulnerability Management with Cisco Talos Intel and Remediation Analytics

New level unlocked. The next step for Kenna.VM users who are maturing their risk-based vulnerability management program is Kenna.VM Premier—and it’s live. 

The Cisco Kenna team is excited to release a new tier of the Kenna Security platform designed specifically for customers or prospects that have reached a point of maturity in which they can and want to do more with their vulnerability management program.

In addition to the existing Kenna features and functionality you know and love, the new Kenna.VM Premier tier includes:

◉ In-depth and actionable remediation scoring (New!)  

◉ Zero-day vulnerability intelligence, powered by Cisco Talos (New!) 

◉ Access to Kenna’s vulnerability intelligence via an API or user interface (UI) 

We’re particularly excited about the new features that are debuting with this tier. So, let’s take a closer look at everything that’s included.

Remediation scoring 

On the Kenna.VM homepage, a new metric will appear at the top right corner (Figure 1). The Remediation Score, as this measurement is known, quantifies how well an organization is addressing risk overall.

Figure 1: Remediation Score in Kenna.VM homepage

The Remediation Score itself encompasses four key measurements (Figure 2), which may sound familiar to you if you’ve been reading any of the Prioritization to Prediction reports produced by Kenna and the Cyentia Institute:  

    ◉ Coverage: Of all vulnerabilities that should be remediated, what percentage was correctly identified for remediation?  

    ◉ Efficiency: Of all vulnerabilities identified for remediation, what percentage should have been remediated? 

    ◉ Capacity: What is the average proportion of open vulnerabilities that were closed in a given period? 

◉ Velocity: What is the speed and progress of remediation?  

Figure 2: Remediation sub-scores in Kenna.VM homepage

These new remediation insights will allow organizations to shift away from relying on just the Risk Score itself as a measurement to assess the performance of remediation teams. While many organizations opt to use the Risk Score in this manner, there are inherent problems with evaluating performance based on the Risk Score—particularly for mature programs. A Risk Score can spike at any moment due to a suddenly high-risk vulnerability—a spike that isn’t a reflection on the remediation team themselves. And as organizations mature, they’re likely to reach a ‘steady state’ with their Risk Score, which makes it a difficult metric to use to measure progress.

Ultimately, these performance metrics will help customers better understand what areas of their remediation efforts are doing well and which might need to be adjusted.

Zero-day vulnerability intel—brought to you by Cisco Talos 

Another new addition to the Kenna.VM platform is zero-day vulnerability intelligence powered by Cisco Talos. Talos regularly identifies high-priority security vulnerabilities in commonly used operating systems and software. The team works with vendors to disclose more than 200 vulnerabilities every year.  

This new integration with Talos gives Kenna.VM users access to information on zero-day vulnerabilities documented by the Talos research team (and likely to be in their environment). With the “Zero Days” filter in Kenna.VM, users can isolate zero-day vulnerabilities, investigate, and take action leveraging Snort rule IDs provided by Talos, when applicable (Figure 3).

Figure 3: “Zero Days” filter isolates all zero-day vulnerabilities in Kenna.VM Explore page

Vulnerability intelligence—your way 

The last (but certainly not least) piece of the Kenna.VM Premier puzzle is the inclusion of Kenna’s recently enhanced vulnerability intelligence User Interface and API. Kenna is known for its risk scoring, but what people may not realize is just how much data we consume and turn into finished, actionable intelligence. There are more than 18+ threat and exploit intelligence feeds that power our understanding of vulnerabilities, and our vulnerability intel API and UI make of this information available to customers. 

The UI provides a dashboard to research any CVE—regardless of whether or not a scanner found that vulnerability in the customer’s environment. Meanwhile, the API allows customers to query Kenna and export as much of our vulnerability intelligence on as many vulnerabilities as they wish, and use that data to enrich any existing IT, dev or security workflows, including Cisco’s very own SecureX. The data in this set includes descriptions, publication dates, CVSS data, available exploits and fixes, insight into remote exploitable vulnerabilities, and much more. Also provided is the Kenna Risk Score for each vulnerability and an indication of whether it is predicted to be exploitable—unique data points derived by Kenna’s data science.

Figure 4: Kenna’s vulnerability intel dashboard lets you research any CVE to see its risk score and other characteristics

This intelligence, combined with our new remediation scoring and Talos zero-day intelligence, rounds out the Kenna.VM Premier tier as the ideal package for any customer or prospect who is looking to take their vulnerability management program to the next stage of maturity.

Kenna.VM Premier is available today. If you’re interested in learning more, contact your sales representatives or send us a demo request to unlock the next level of your vulnerability management journey.

Source: cisco.com

Continue reading

Using APIs to create a Multidomain Inventory for Asset Management

IT Organizations have to manage, secure, and get audited on their IT assets. The span of domains cover multiple different product sets with different operating systems by nature, and the teams are tasked to create a cohesive asset management framework. An example is a financial institution which is subject to the FFIEC guidance, which requires them to be able to conform to an audit structure that requires managing their assets and software.

A second example is the NIST publication 1800-5 on IT Asset management that describes a framework for managing assets in an organization. A number of organizations may adopt NIST as their security framework.

Within these frameworks, the NIST and FFIEC guidance don’t call out “Cisco Equipment” or “Microsoft software”, “Virtual machines”, or “Firewalls” in a vacuum. IT Administrators and security teams aren’t tasked with inventory and patch management of just their load balancers, servers, switches, or routers.

IT Administrators and their leadership are tasked with knowing, patching, and securing all of their IT infrastructure. From the physical to the virtual, from the endpoint to the cloud. Thus any single tool needs to be able to fit into a framework to be able to merge together different systems in a cohesive manner that is capable of managing multiple operating systems and vendor implementations.

The purpose of this blog is to show how this can be done practically using diverse Cisco hardware and software, and the framework would bolt in to any other third party and provide functional, easy to use code, that can create a single asset management table for products in the Cisco portfolio.

We do this by integrating ACI, Multiple DNAC, Meraki, Intersight, and SD-Wan platforms into a single table which can be cross referenced and then pushed, into Service Now. We do this using available DevNet sandboxes as of 11/2022. There is also a reference on how this can be reconciled and pushed into Service Now (so that the system of record can be updated following software changes, or reconciled).

This is functional code, which is easy to run against real sandbox environments, and can be validated and repurposed for your environment.

While we cannot control third party products and how they integrate, the framework would allow for other equipment which support Rest API to create a state table for inventory asset management. The framework is rather straightforward: capture the inventory from diverse systems using REST API, and normalize to a consistent list of all assets in those systems. From there, you can update Service Now or another system of record.

The problem we are trying to solve is further elaborated in NIST 1800-5, of the multiple frameworks a customer may be required to audit towards, and the fact that its not as simple as just running a single vendor’s report, when your responsible for an entire ecosystem of vendors and products.

So lets get to it!

What is created is a Google Colab notebook, which allows you to take and validate the code. This is possible because we are using cloud sandboxes hosted in DevNet and our cloud platforms. If you have never used Colab before, it is a Jupyter notebook in the sky that is as easy to run as clicking a button. It also allows me to easily share with you, so you can see for yourself how it works.

You can get a read only copy of the code here: We will walk through it below.

https://colab.research.google.com/drive/1DMfB_FfWPEIDggYawtJgmskLJmkVzqyM?usp=sharing

The first thing you want to do, is look at what it says at the top. What is shared is a read only copy, and to play with it, you want your own editable copy. So you want to save it, by going to File/Save a copy to drive.

The next thing to look at is there are sections, at a high level, its broken down into

1. Getting Meraki inventory

2. Getting SD-Wan inventory

3. Getting DNAC (and multi controller example… this multi controller could also be ACI domains, or Meraki networks)

4. Getting Intersight inventory

5. Getting ACI Inventory

6. Merging them all togther

7. Optional: Updating ServiceNow example. (note, this uses a developer instance which will be inactive by the time you read this, it is functional, get your own developer instance and use the URI at developer.servicenow.com)

Each of these sections can be ran as a group, by mousing over “7 cells hidden”, or you can expand each section and look at code, and what it is doing. You can click the run button below, OR expand the section. This shows the Meraki inventory.

We then go and get the info from SD-Wan, and Intersight, we go into all the groups and grab information and store them in tables, we have created the below tables:

◉ sdwan_inventory_df -> Data Frame with details from SDWAN

◉ meraki_inventory_df -> Data Frame with details from Meraki

◉ dnac_inventory_df -> Data Frame with details from DNAC

◉ intersight_inventory_df -> Data Frame with details from Intersight

◉ aci_inventory_df -> Data Frame with details from ACI

Each of these data frames include details from inventory, and we want to simplify it for the concise table. We reduce the amount of fields in each table, and rename them so they are consistent. For example, natively ACI calls hostnames in model format, as fabricNode.attributes.name. Intersight calls Hostname “HostName”. We just simplify this.

Reduce the Intersight table to just a few columns,

intersight_inventory_simple_df=intersight_inventory_df[[‘DataSource’,’SerialNumber’,’HostName’,’ModelNumber’,’Ip.Ip’,’Version’]]

Rename these columns to a consistent format:

intersight_inventory_simple_df.rename(columns={‘SerialNumber’:’Serial’,’HostName’:’Hostname’,’ModelNumber’:’Model’,’Ip.Ip’:’IP Address’,’Version’:’Version’}, inplace=True)

After concatenating all these tables, we have an inventory list with a list which we can use to audit or update our system of record.

Source: cisco.com

Continue reading

Secure the Industrial Edge with Cisco SD-WAN

The Expansion of Enterprise Networks

As networking infrastructure continues to expand in our hyper-connected world, the capabilities businesses have to deploy, secure, and manage their critical Internet of Things (IoT) devices plays an ever-increasing role in the success of their enterprise. In response to this expansion, there have been on-going innovations advancing the ways networks operate – and at the forefront of these trends is the way that SD-WAN enables and supports IoT deployments.

Networks are expanding outside traditional office buildings and into industrial spaces, resulting in more devices being connected to the internet and data centers. It is not just printers, light bulbs, and cameras anymore as IoT is moving far beyond the carpeted spaces – each day something new is added to your network and sometimes you may not even know it was there.

The rate of growth for IoT is moving so quickly that IDC estimates by 2025 there will be 55.7 billion IoT devices connected to the internet – that outnumbers the amount of humans in the world by a 7:1 ratio. Though the rise of IoT has improved and extended visibility to more operational elements of the business, it comes with a unique set of challenges that must be tackled to maintain the integrity of the network.

Challenges Surrounding IoT

Across multiple industries companies are finding it difficult to identify, manage, and secure industrial assets. The volume of IoT deployments in an enterprise can vary greatly and introduce incremental security risks. The bottom line is that to fully protect your network and enterprise, IoT devices must be secured on the same level as a data center or operating system would be.

Deployments in the field can be hard to manage with use cases like roadways and intersections, pipelines for oil and gas, and substation automation for power stations. The influx of IoT devices that are being added to networks can be a challenge for those in charge as observability becomes a bottleneck for networks operating on multiple WANs. These obstacles of observability and management can result in instances of unauthorized users accessing sensitive data and lead to high-risk vulnerabilities being exploited. In many cases, lack of consistent security policy extending through the industrial edge becomes an expensive problem.

Fortunately, Cisco SD-WAN provides users with the ability to manage, secure, and observe networks with IoT deployments of all sizes. Cisco SD-WAN provides seamless and secure connectivity far beyond your enterprise, powers automation to scale your operations, and enables visibility to keep your enterprise protected and resilient.

Cisco SD-WAN Can Help

Cisco SD-WAN provides solutions for common IoT challenges by converging security features and management tools that enable the visibility of IoT assets connected to the network while applying consistent security policies in both the enterprise as well as the industrial network extensions. With SD-WAN, encryption and segmentation of data from IoT devices can be applied so that the right people or applications with the right credentials see critical information at the right time.

Over the years, Cisco SD-WAN has made the world more connected than ever by enabling routers deployed in the field, on campus, and at home to be connected to a single network that can be managed with a single pane of glass. Now, Cisco SD-WAN allows for enterprise networks to be brought to the industrial edge to enable visibility and security needs without the need for an entirely new network or management tool.

The simplification of extending network security and routing policies to the edge of your network should be top of mind for any business looking to keep up with changing times and with Cisco SD-WAN, that power is yours.

Source: cisco.com

Continue reading

Supercharge 5G with Converged CRAN Architecture

Communication service providers (CSPs) are being challenged to deploy 5G in dense urban and high traffic environments while trying to optimize for cost and simplify capacity expansions. Centralized radio access network (CRAN) architectures are becoming critical as CSPs adopt mid-band and high-band spectrums to address 5G opportunities. CRAN architecture lowers capital expenditures (CapEx), simplifies operations, and enhances RAN performance with spectrum sharing technologies. CSPs need to look at their existing transport architecture to ensure that they realize these benefits by adopting CRAN.

Evolving the transport network is a first important step in adopting 5G on an existing 4G RAN network. The decision to either stay with distributed RAN (DRAN) architecture by expanding backhaul capacity or migrating to CRAN architecture with fronthaul investment is something every CSP must consider.

Cisco’s Converged SDN Transport architecture and product innovations are addressing these challenges with a unified transport architecture design. This way CSPs can adopt any deployment scenarios (CRAN, DRAN, or both) without changing the underlying transport protocols, management, and infrastructure services definition.

5G CRAN explained

4G is traditionally deployed with DRAN architecture, where radio baseband processing for each site is done locally (figure 1a). In CRAN, a large part of the radio baseband processing is done at a hub for multiple radio sites (figure 1b). In DRAN architecture, the RAN transport toward the mobile core is referred to as backhaul. In CRAN the transport network between the radio antenna and baseband processing units is referred to as fronthaul. Fronthaul has much more stringent latency, jitter, and synchronization requirements compared to backhaul.

Figure 1. 5G RAN architectures – DRAN and CRAN

There are several benefits with CRAN architecture, such as:

◉ Cost optimization: CRAN improves hardware utilization with centralized processing for multiple radio sites. It also reduces radio site footprint and optimizes power and cooling requirements.

◉ Spectrum gains: By processing multiple radio sites from a centralized hub location, it’s easier to process related functions like coordinated multipoint reception to remove inter-signal interference and implement carrier-aggregation techniques.

◉ Expansion and scale: CRAN simplifies capacity expansion, site acquisition, and deployment of heterogeneous networks to meet different business needs.

The benefits of CRAN are realized in dense urban and high traffic scenarios whereas DRAN is often more appropriate for rural and moderate traffic scenarios. CSPs need to consider their networks and traffic patterns in deciding between CRAN and DRAN adoption.

Building efficient RAN transport

CSPs are focused on building an xHaul transport architecture that allows them the flexibility to adopt DRAN or CRAN without worrying about the requirements of fronthaul, midhaul, or backhaul transport. They demand an architecture that meets the latency, jitter, and synchronization requirements of each of these transports – a flexible, programmable, and scalable 5G xHaul transport architecture.

As shown in figure 2, Cisco Converged SDN Transport, with Cisco NCS 540 and NCS 5700 series platforms, allows customers to build a 5G RAN transport that’s both scalable and flexible and can converge Layer 2 and Layer 3 services from the edge of the network. The architecture allows customers to offer various public and private 5G services covering eMBB, FWA, URLLC, and enterprise services.

Figure 2. Converged xHaul architecture

Extending segment routing to the cell site not only simplifies the protocol stack and allows intelligent traffic steering, but also enables service slicing, programmability, and automation capabilities on the architecture. Fronthaul traffic, which is mostly Layer 2, can be carried over an EVPN slice with a low latency path while non-latency sensitive traffic can be carried over a L3VPN slice to meet 5G ORAN specifications. Built using timing best practices, the architecture allows adopting any access topology without impacting time synchronization accuracy.

Cisco’s Converged SDN Transport architecture simplifies adoption of DRAN and CRAN with a deployment that’s independent of network level protocols, infrastructure services, or synchronization architecture.

5G xHaul transport with NCS 540 and NCS 5700 series

Cisco NCS 540 and NCS 5700 series deliver performance, density, and exceptional efficiency to address transport pre-aggregation as well as 5G CRAN deployments. Powered by the IOS XR network operating system, the architecture focuses on simplified operations with programmability, manageability, and automation to meet key characteristics of 5G xHaul transport.

High Density Interfaces for 5G CRAN

NCS 5700 platforms offer high density 10G, 25G, 50G, 100G, and 400G interfaces to aggregate access transport links as well as 5G DU or CU servers at 5G CRAN or far-edge.

At cell sites, NCS 540 platforms offer high density 1G, 10G, and 25G interfaces to connect mid-band and high-band radios over CPRI or eCPRI interfaces with 100G or 400G options for uplink connections.

Optical Support

Broad support of 400G and 100G QSFP-DD ZR/ZR+ optics across the NCS 540 and NCS 5700 portfolio enables CSPs to address bandwidth demand and scale through simplified network architecture.

ORAN Characteristics

The NCS 540 and NCS 5700 portfolio meets 5G xHaul ORAN specifications to support fronthaul, midhaul, or backhaul deployments on a converged architecture.

With consistent performance that meets stringent microsec latency, accurate Class C timing and support of advanced segment routing features, EVPN, and integrated GNSS, the solution helps customers deploy any use case scenario under a single plane of management.

Programmability and Automation

Starting with segment routing v6 and microSIDs-based programmable routing, the solution offers zero-touch provisioning (ZTP) and advanced streaming telemetry as well as YANG model support.

Platforms support modern protocols like gRPC, gNMI, protobuf; and tools based on Chef, Puppet, and Ansible to help customers integrate management layers and simplify operations across access transport and 5G CRAN/far-edge. Network operations teams can take early action, achieve faster remediation, and ensure guaranteed service level agreements (SLAs) for a better end-user experience.

Source: cisco.com

Continue reading