Sunday 11 October 2020

Top 5 reasons to keep your Identity and MFA providers in sync

Cisco Learning, Cisco Tutorial and Material, Cisco Exam Prep, Cisco Tutorial and Material

By now, you may have heard about SecureX, Cisco’s new integrated platform that simplifies the security experience. SecureX is built into the Cisco security portfolio, and connects your entire security ecosystem for simplicity, better visibility, and greater operational efficiency. SecureX sign-on is one of the key features of SecureX – it’s giving users instant access to the platform and all of their applications and data, while keeping the identity provider (IdP) and multi-factor authentication (MFA) in sync.

Is your organization using an IdP and MFA provider? You can make life easier for your SecOps team, while strengthening your organization’s cybersecurity posture, improving compliance and increasing visibility without adding tasks to your team. This post will describe a new automated process that can do all these for you.

Background

With SecureX sign-on, we are using several identity providers (like Okta, Auth0, Azure AD and Cisco security) as our applications need and see fit. We chose Duo to be our multi-factor authentication (MFA) provider as it gave us great visibility into our customers’ security posture and is a very flexible MFA. Now we needed to have our Identity and MFA Providers in sync.

An identity provider (abbreviated IdP or IDP) is a system entity that creates, maintains, and manages identity information for principals while providing authentication services to relying applications within a federation or distributed network.

Multi-factor authentication is an authentication method in which a computer user is granted access only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism: knowledge (something only the user knows), possession (something the user and only the user has), and inherence (something the user and only the user is).

Multi-factor authentication reduces the incidence of online identity theft, because the victim’s password would no longer be enough to give a thief permanent access to their information.

Why do my Identity and MFA providers need to be synchronized?

Cisco Learning, Cisco Tutorial and Material, Cisco Exam Prep, Cisco Tutorial and Material

Here are 5 reasons to keep them in sync:

1. General security hygiene. Keeping user names and deletion in sync to avoid two split brain databases is always a good idea – you never know when you are going to try to research an issue.

2. User deletion. For both compliance and security reasons, if I delete a user, I want him gone from all my databases. Almost every IDP has 50% ghost accounts and cleaning them up is important.

3. Reset user’s credentials. The number #1 reason for calls to our call centers are lost phones and mistaken registration. Allowing for a simple way to reset from one place that permeate everywhere.

4. Policy is king. Keeping the data in sync allows me to create dynamic policies that traverse the single provider.

5. Reporting. Providing meaningful reports, with groups in place I can show specific admins how their domains look like.

Why not use SCIM?


System for Cross-domain Identity Management (SCIM) is a standard for automating the exchange of user identity information between identity domains, or IT systems.

User identities synchronization can be achieved using the SCIM specification, however not all MFA providers want to use or can use SCIM. This SDK keeps users synchronized between service providers in this case.

How this works


Cisco Learning, Cisco Tutorial and Material, Cisco Exam Prep, Cisco Tutorial and Material

A user can update his profile details in the IdP service.

An admin can perform the following actions in the IdP service:

◉ Create/delete a user
◉ Create/rename/delete a group
◉ Associate/disassociate a user to a group
◉ Disable/reenable a user
◉ Reset MFA for a user
◉ Supported Identity Providers

This list is expected to grow with time

◉ Okta
◉ Auth0

Supported MFA Providers

This list is expected to grow with time

◉ Duo Security

Deployment

The Webhooks endpoint can run anywhere, even on-prem.

Deployment scripts to AWS, Azure and Google Cloud are provided via Terraform.

Supported Cloud Providers

◉ AWS
◉ Azure
◉ GCP

Saturday 10 October 2020

Economic Benefits of Virtualizing the CCAP Core with a Microservices Based Architecture

Cisco Prep, Cisco Learning, Cisco Certification, Cisco Tutorial and Material, Cisco Cert Exam

Architecture

Service providers are going through a digitalization journey. And one aspect of that journey is the virtualization of their service delivery infrastructure. At Cisco, we are making that transition easier for our customers by creating a common virtualization platform across mobile 5G, cable vCCAP, and Telco vBNG. This helps operators reduce their cost to virtualize the infrastructure and enable them to rapidly tap into new revenue opportunities.

When it comes to virtualization for cable, we did not virtualize the legacy CCAP, we re-architected the platform from the ground up to come up with a microservices-based architecture. That is what became our Cloud-native Broadband Router(cnBR). Why? That was the only way to get to ours and our customers’ end goal which is a hybrid, Multi-cloud, and Multi-Access Edge Compute(MEC) based cable broadband platform. cnBR has four major types of microservices: Data Plane(DP), Control Plane(CP), Real-Time(RT), and Management Plane(MP) that we can deploy at any location in the network or the cloud. cnBR’s microservices-based architecture enables webscale operations such as auto-healing, autoscaling, load balancing, and fault-tolerance at the infrastructure layer.

Evolution

With cnBR’s microservices-based architecture, you can start with a simple on-prem appliance like architecture that is familiar to your operations and IT organization. And as you gain familiarity, you can evolve into a hybrid and multi-cloud world by moving some of the microservices to public cloud platforms. The move of some of the microservices to public cloud platforms such as GCP, Azure, and AWS will reduce operational burden, extend reach, and augment capacity. Figure 1 shows the phased deployment evolution of the cnBR architecture:

Cisco Prep, Cisco Learning, Cisco Certification, Cisco Tutorial and Material, Cisco Cert Exam

Figure 1: Evolution of cnBR Architecture

Phase 1: Centralized on-Prem and cloud-native appliance – In this phase, you will start with all the microservices running in the hub or Datacenter.

Phase 2: Multi-Access Edge Compute(MEC) – Here, you will slowly move some of the microservices closer to the edge in an Edge compute platform or a node that has a compute board to enable a MEC architecture. This will focus on shifting the data plane(DP) and real-time(RT) microservice to MEC platform.

Phase 3: Hybrid Cloud – This phase moves the management plane(MP) and control plane(CP) microservices to a private or public cloud and keeps data plane(DP) & Real-Time(RT) microservices at the edge

Phase 4: Multi-cloud – This phase provides flexibility in enabling the management and control plane microservices to run in any public cloud environments with minimal friction.

 Why Migrate to a Microservices based Architecture?

With microservices-based architecture, you can improve:

– Time to market: you can get features in weeks vs months, 

– Agility:  you enable hitless and maintenance windowless upgrades, 

– Scale: you gain seamless and on-demand auto-scaling which gives you unprecedented cluster level redundancy and scale,

– Cost: you can lower TCO with reduced footprint and facilities cost.

Why Cisco’s cnBR?

The virtualization of the access infrastructure is one way to add more capacity. To better understand how operators can virtualize and reap immediate business benefits with cnBR, we looked at CAPEX and standard operational costs like space, power & cooling while increasing the scale of the microservices-based architecture. We also did the same scaling and cost analysis of a legacy appliance-based CCAP solution so we can compare the savings. What we found is a compelling business value of going to a microservices-based architecture. These are additional benefits to the service/feature velocity and operational efficiency enabled by agile webscale operations of microservices-based architecure.

The analysis included scenarios where bandwidth per service group is increased from 1 Gbps to 5 Gbps in the downstream while the upstream is increased from 100 Mbps to 500 Mbps. The average Capex Savings was 29%, average OPEX savings were 42% and the average space(RU) savings were 73%. Figure 2 highlights the savings as the bandwidth scales up.

Cisco Prep, Cisco Learning, Cisco Certification, Cisco Tutorial and Material, Cisco Cert Exam

Figure 2 . Business benefits of cnBR as system bandwidth scales up

To help do your own analysis, we have created an easy to use vCCAP economics calculator. You can do your own analysis based on your current network configuration and long-range plan(LRP). Figure 3 highlights the type of summary output you can get from the vCCAP Economics Tool.

Cisco Prep, Cisco Learning, Cisco Certification, Cisco Tutorial and Material, Cisco Cert Exam

Figure 3. Summary of Capex, Opex comparison between cnBR and traditional CCAP

Friday 9 October 2020

Resiliency and the Path to Automation 

Cisco Prep, Cisco Learning, Cisco Guides, Cisco Tutorial and Material, Cisco Prep

Look anywhere and you’ll find conversations about autonomous operations. Everyone is weighing in on how to balance the benefits from these new technologies with the perceived impact on society and our collective future, particularly in our Covid reality. What I can tell you – from an industrial IoT perspective – is that we are seeing autonomous operations having a very positive effect.

Across industries, we’re seeing autonomous operations deliver increased business resiliency, better jobs, improved working conditions, increased efficiency, and a higher quality of work/life balance across many industries.

◉ Autonomous trains: Since the first driverless trains in the late ‘90s, more and more passenger train lines are being built and converted to automated lines, delivering additional safety for passengers, operational flexibility and reduced operating costs. Driverless trains can increase throughput by increasing the frequency of trains on a metro line and at the same time, they deliver a track record for safety that human drivers are unable to match.

◉ Warehouses and distribution centers: Entirely autonomous loading systems are now taking and fulfilling orders from the supply chain. Forklifts and pickers fetch the product, deliver to the pallet, wrap for shipping, and transport to the shipping dock.

◉ O&G exploration: Once workers get a drill rig close to the target drill area, the rig can take over by itself – saving workers from a job that not only is dangerous but can take days. The autonomous drill can also quickly make on-the-fly changes, like adjusting the angle of the drill, to increase yield and efficiency.

◉ Auto manufacturing: Here manufacturers are weaving autonomous operations into their industrial automation efforts – like using RFID on to keep track of car bodies as they move across the production line and Automated Mobile Robots (AMRs) to safely move material across the factories.

◉ Amusement rides: Today the most advanced and desired rides in amusement parks are the so-called “dark rides”, where visitors hop on fully autonomous vehicles speeding up through a completely dark warehouse and where the experience is provided though immersive displays, VR googles, and incredible accelerations. The entire outdoor “amusement network” is connected by wireless access points on the vehicles and the infrastructure, all powered by rugged IoT switches and routers.

Cisco Prep, Cisco Learning, Cisco Guides, Cisco Tutorial and Material, Cisco Prep

Behind each level of automation is a communication and connectivity challenge across industries.  Autonomous operations require vast quantities of real-time video and data that legacy networks simply can’t handle – and often the operations are in harsh, remote, and dangerous locations. Trains are constantly in motion across remote geographies and inside tunnels, presenting unique connectivity challenges. All this automation translates into the need for high bandwidth, high security, and high reliability.

The Foundation for Autonomous Operations – A Secure and Reliable Network


The secret power behind autonomous operations?

It starts with Cisco’s secure and reliable network for IIoT that powers the entire system and connects everything – device to vehicle to data to Cloud – making sure your autonomous operations have the right data to make the right decision at the right time. Autonomous operations rely on that perishable data at the edge that is only valuable at that moment. After an incident, it does little value to know the vehicle should have turned.

Likewise, autonomous operations are only successful if the entire system is secure. If the network were to be hacked, perpetrators could take over the autonomous operations. Imagine the mining truck being rerouted to follow the wrong path causing an accident. You have to trust your network to trust your business to autonomous operations.

The recipe for your success?

We know that automation comes with challenges as we’re right there alongside our customers in their environments. No other company has the breadth of experience inside IT/communications and industrial settings across voice, data, and video to bring IT and operations together.

Every day we work with our customers to accelerate their success by:

◉ Bringing their IT/OT ecosystems together – so that IT can leverage all that they already know about Cisco networking and OT can get projects going quickly and securely

◉ Building a strong network of industrial partners who know the ins and outs of these industrial operations – and we’re just getting started

◉ Delivering more validated designs, like our new Distribution Automation – jointly validated with Schweitzer Engineering Laboratories – that highlights advantages from new innovations to the Cisco Resilient Mesh

Next up – Take a Deep Dive into Autonomous Mining

Over the next few blogs, I’m going to take you deeper into some automation use cases – first with mining and then with ports. While it may not be your exact industry, I’ll encourage you to keep reading as there are a lot of similar challenges across these operational settings.

Thursday 8 October 2020

MDS 9000 Series Switch Architecture Part 1: Superior CRC Error Handling

In this blog series, we’ve discussed many unique advantages of the Cisco MDS 9000 series switches. We explored NVMe/FC support, proven investment protection, the superior security provided by anti-counterfeit technology, and the industry’s unique SAN Analytics solution. Now, let’s look at another important aspect: the Cisco MDS 9000 Series switch architecture and what makes it unique.

Switching Architectures Explained

As most of us know, there are two different types of switching architectures: Store-and-Forward and Cut-Through. In Store-and-Forward architecture, an interface receives the full-frame (header information + data + CRC + checksum, etc.) before putting it back on the wire for egress. While in Cut-Through architecture, the switch will only wait till it receives the destination WWN to put it on the wire, without waiting for other portions of the frame (data + CRC + other control parameters) to be delivered.

In both mechanisms, a CRC error check, also called Cyclic Redundancy Check, is applied. But the difference is in the next stage – action. What actions are taken when the CRC error is identified?

CRC Error Handling in Cut-Through Architecture: Identify, Report, Forward (Ugh!)

In Cut-through Technology, if a packet has a CRC error, it will increase the CRC error reporting counter and put the corrupt packet back on the wire, and move on. Thus, the switch can only report the error and put it back on the wire without taking any further action. The packet that arose with the CRC error will have to be sent again anyway from the source across the entire path. The result? Degraded performance—twice. The first is due to a bad packet, and the second is a result of resending the original bad packet.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Exam Prep
Cut-Through technology: Corrupt packets reported and forwarded.

Ultimately, the destination server and storage Host Bus Adapter (HBA) works extra hard to detect and drop the bad packet. In the ethernet world, this may not be a major issue. But in the Fibre Channel network, we have finite pools of buffer credits. Every packet that has to be retransmitted will need buffer credits. This can create performance issues, buffer credit starvation, and spend vital CPU cycles of the switches across the network. The impact includes high TCAM usage, increased latency, and a multitude of additional issues. In other words, the whole network can be impacted and brought to a halt.

CRC Error Handling in Store-and-Forward Architecture: Identify, Report, Drop (Yay!)

In Store-and-Forward technology, if the switch interface finds any CRC errors, it will identify and drop the packet on the spot. Why? Because here, the switch receives the full-frame (header + data + CRC checksum information, etc.) before putting it on the wire for egress. It will also signal the source to resend the corrupt packet. This saves resources, including memory, CPU, bandwidth, and buffer credit across the network, plus the additional resource consumption on the server or storage devices. As a result, the performance impact is minimal.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Exam Prep
Store-and-Forward technology: Corrupt packets reported and dropped.

We implemented Forward Error Correction (FEC) in MDS 32G FC as a standard requirement. It can do a similar job, but with some limitation. FEC can only correct up to 11 bits out of 2,112 bits of FC frame. This is useful but in extremely limited cases. Note that the smallest portion of the FC frame (start-of-frame OR end-of-frame) is 4 bytes or 32 bits. So, what if errors are more than 11 bits or about 0.6 percent? FEC will not be able to help. Therefore, CRC error checking and deploying the correct architecture is highly important.

Wednesday 7 October 2020

Get Ready to Crack Cisco CCNP Enterprise 300-430 Certification Exam

 Cisco ENWLSI Exam Description:

The Implementing Cisco Enterprise Wireless Networks v1.0 (ENWLSI 300-430) exam is a 90-minute exam associated with the CCNP Enterprise and Cisco Certified Specialist - Enterprise Wireless Implementation certifications. This exam certifies a candidate's knowledge of wireless network implementation including FlexConnect, QoS, Multicast, advanced location services, security for client connectivity, monitoring and device hardening. The course, Implementing Cisco Enterprise Wireless Networks, helps candidates to prepare for this exam.

Cisco 300-430 Certification Exam Overview:

Exam Name: Implementing Cisco Enterprise Wireless Networks
Exam Number: 300-430 ENWLSI
Exam Price: $300 USD
Duration: 90 minutes
Number of Questions: 55-65
Passing Score: Variable (750-850 / 1000 Approx.)
Exam Registration: PEARSON VUE

Related Articles:

Tuesday 6 October 2020

Using “WhatsOp” for Network Change Management

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides, Cisco Certification, Cisco Exam Prep

I often find myself passionately talking with my customers about programmability and how it unlocks hidden potential to do anything we can think of – even make a cup of coffee (if you purchase an API enabled coffee machine that is :-).

Some get it right away. Others can’t think of ideas for what they would like to do differently, and that reminds me of Henry Ford’s famous quote:

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides, Cisco Certification, Cisco Exam Prep

The WhatsOp use case


I understood I needed to provide a few examples of the potential use-cases in order to make it real. So, my quest began. At some point I stumbled upon Gabi Zapodeanu’s DevNet Create 2018 workshop – that was a perfect example of the use-case I was looking for.

WhatsOp is a very “visible” use-case in terms of user experience. It leverages several different programmability tools available on Cisco’s platform — Embedded Event Manager, Guestshell, Python, REST APIs, Webex Teams.

Cisco Prep, Cisco Learning, Cisco Tutorial and Material, Cisco Guides, Cisco Certification, Cisco Exam Prep

How I demonstrate WhatsOp


Change management is a use-case my customer faces on a daily basis in their production networks. Many of them have a policy that defines what changes are allowed throughout the day and what changes should be done only during off-hours. For example, assigning an access port to a vlan does not require any approvals, while changes to the routing table do.

With WhatsOp, every change (or selected changes) will notify selected network administrators and ask for their approval. The network administrators will be able to approve the change, or roll-back the change – through their smartphone, thanks to Webex Teams.

Experience the potential of programmability


My intention in demonstrating WhatOp is to expose the potential of programmability. We could restrict the commands privileged users are allowed to enter using ISE as TACACS, we could leverage Prime Infrastructure to archive and compare configuration revisions. However, integrating the functionality together and making it accessible from any device (that can access Webex Teams) would be challenging. Getting the functionality to work even without connectivity to the central management systems would be very challenging.

Don’t take the WhatsOp use-case as-is. Think about modifying it to address a unique problem your organization might be facing right now – how cool would that be?

If you have an interesting use-case – let me know! I’m always looking for new challenges to solve. For now, let me encourage you to try WhatOp yourself to experience the potential of programmability. Check out these resources:

◉ Webex Teams SDK which makes life much easier and the code cleaner working with the Webex Teams API.

◉ pyATS, which is super powerful for manipulations, parsing, differences and verification of network devices. The only reason we’re NOT using pyATS for configuration differences, is because the program needs to run in Guestshell, and we wanted to make it as lean as possible.

◉ Check out the repo on GitHub.

◉ Watch my demonstration video


Breaking it down:


How did it work?

1. Detecting the change: every change we have on a Cisco device triggers a log message, such as:
Aug 16 2020 07:05:12.521 UTC: %SYS-5-CONFIG_I: Configured from console by obrigg on vty0 (10.56.56.143)

We use EEM (Embedded Event Manager) built-in IOS-XE/NX-OS to wait for this log entry and kick off the Python program.

!
event manager applet config_change
 event syslog pattern "SYS-5-CONFIG_I" maxrun 240
 action 0 cli command "enable"
 action 1 cli command "guestshell run python3 /bootflash/guest-

share/WhatsOp/config_change.py"
 action 2 cli command "exit"
 action 3 cli command "exit"
!

2. Running the Python program: We’re using Guestshell to run our program on the device itself. Guestshell is a virtualized Linux-based environment, designed to run custom Linux applications, including Python for automated control and management of Cisco devices. This container shell provides a secure environment, decoupled from the host device, in which users can install scripts or software packages and run them.

3. What’s happening in Python:

a. The program starts with gathering information from the device: The user has performed the latest change and The running configuration (a copy is saved on bootflash:).

def save_config():
    # save running configuration, use local time to create new config file
name
    run = cli('show run')
    output = run[run.find('!'):len(run)]
    timestr = time.strftime('%Y%m%d-%H%M%S')
    filename = '/bootflash/guest-share/CONFIG_FILES/' + timestr + '_shrun'
    f = open(filename, 'w')
    f.write(output)
    f.close
    f = open('/bootflash/guest-share/CONFIG_FILES/current_config_name', 'w')
    f.write(filename)
    f.close
    return filename

syslog_input = cli('show logging | in %SYS-5-CONFIG_I')
syslog_lines = syslog_input.split('\n')
lines_no = len(syslog_lines)-2
user_info = syslog_lines[lines_no]
user = user_info.split()[user_info.split().index('by')+1]

old_cfg_fn = '/bootflash/guest-share/CONFIG_FILES/base-config' 
new_cfg_fn = save_config()

f = open(old_cfg_fn)
old_cfg = f.readlines()
f.close

f = open(new_cfg_fn)
new_cfg = f.readlines()
f.close

b. Then the program compares the running config, with the last approved configuration (saved on bootflash: as well).

def compare_configs(cfg1, cfg2):
    # compare two config files
    d = difflib.unified_diff(cfg1, cfg2)
    diffstr = ''
    for line in d:
        if line.find('Current configuration') == -1:
            if line.find('Last configuration change') == -1:
                if (line.find('+++') == -1) and (line.find('---') == -1):
                    if (line.find('-!') == -1) and (line.find('+!') == -1):
                        if line.startswith('+'):
                            diffstr = diffstr + '\n' + line
                        elif line.startswith('-'):
                            diffstr = diffstr + '\n' + line
    return diffstr

c. In case there are no changes (perhaps the user changed a setting and changed it back right after) – nothing will happen. However, if the program finds a difference between the running configuration and the last approved configuration – things will become more interesting.

d. The program will use the Cisco Webex Teams API to create a new space and add the preconfigured network administrators in that space. The program will alert the space about the changes that were made, and ask the admins for an approval or decline.

if diff != '':
    # find the device hostname using RESTCONF
    device_name = cli('show run | inc hostname ').split()[1]
    print('Hostname: ' + device_name)
    # Initialize Webex Teams API
    api = WebexTeamsAPI(access_token=WEBEX_TEAMS_ACCESS_TOKEN, proxies=PROXY)
    bot = api.people.me()
    # Create a new space
    room = api.rooms.create(WEBEX_TEAMS_ROOM)
    # Add members to the space
    for WEBEX_TEAMS_MEMBER in WEBEX_TEAMS_MEMBERS:
        api.memberships.create(room.id,personEmail=WEBEX_TEAMS_MEMBER)
    # Send initial message
    api.messages.create(roomId=room.id, markdown=f"Hello <@all>,  \n# Configuration change detected!**  \nDevice hostname: **{device_name}**, detected the following changes made by user: **{user}**.")
    api.messages.create(roomId=room.id, text=diff)
    api.messages.create(roomId=room.id, markdown=f"Do you approve these changes?  \nMention me using **@{bot.nickName}** and enter '**y**' or '**n**'.")
    counter = 6  # wait for approval = 10 seconds * counter, in this case 10 sec x 6 = 60 seconds
    last_message = ""
    # start approval process
    while (last_message != "Bye Bye") and (last_message != f"{bot.nickName} n") and (last_message != f"{bot.nickName} y"):
        time.sleep(10)
        messages = api.messages.list(room.id, mentionedPeople=bot.id)
        for message in messages:
            last_message = message.text
            break

e. If the changes are approved – the running config will be marked as the last approved configuration. If the changes are not approved (declined or timed out) – the program will perform a roll-back to the last approved configuration.

        if last_message == f'{bot.nickName} n':
            cli('configure replace flash:/guest-share/CONFIG_FILES/base-config force')
            approval_result = '- - -  \n<@all>,  \nConfiguration changes **not approved**, Configuration rollback to baseline'
            print('Configuration roll back completed')

        elif last_message == f'{bot.nickName} y':
            print('Configuration change approved')
            # save new baseline running configuration
            output = cli('show run')
            filename = '/bootflash/guest-share/CONFIG_FILES/base-config'
            f = open(filename, "w")
            f.write(output)
            f.close
            print('Saved new baseline configuration')
            approval_result = '- - -  \n<@all>,  \nConfiguration changes **approved**, Saved new baseline configuration'

        else:
            print("No valid response")
            counter = counter -1
            api.messages.create(roomId=room.id, markdown=f'- - -  \n<@all>, I did not receive a valid responce. **{str(counter)} attempts left**.  \nDo you approve these changes?  \nMention me using **@{bot.nickName}** and enter "**y**" or "**n**".')
            if counter == 0:
                last_message = "Bye Bye"
                cli('configure replace flash:/guest-share/CONFIG_FILES/base-config force')
                approval_result = '<@all>,  \nApproval request **timeout**, Configuration rollback to baseline'
                print('Configuration roll back completed')

    api.messages.create(roomId=room.id, markdown=approval_result)

f. Once it’s done, the Webex Teams space will be deleted in order to prevent flooding the admins with spaces.

    api.messages.create(roomId=room.id, markdown='This room will be deleted in 30 seconds')
    time.sleep(30)
    api.rooms.delete(room.id)

Saturday 3 October 2020

Cisco’s Magic Glue Binds the Pieces of the OvRAN Puzzle

Open Virtualized Radio Access Network i.e. “O-vRAN” has been a buzzword in the industry for quite some time now. To date, many renowned mobile industry analysts and researchers have conducted surveys on O-vRAN and revealed about the strong momentum of Mobile Network Operators (MNO) towards Commercial Off the Shelf (COTS) hardware, Software Defined Networks (SDN), and Virtualization. More and more MNOs are adopting or planning to modernize their Radio Access Networks (RAN) with Open vRAN architecture.

Cisco Prep, Cisco Tutorial and Material, Cisco Certification, Cisco Exam Prep, Cisco Guides

The decision to choose O-vRAN path by MNOs is a no-brainer. An operator survey by Senza Fili in 2019 tells that the key drivers behind the Open vRAN adoption are a reduction in Total Cost of Ownership (TCO) due to the increased vendor competition and deployment flexibilities that open architecture offers. Also, by decomposing, disaggregating, and virtualizing RAN components, MNOs are transforming their networks to future proof 5G ready networks.

Cisco’s Journey in O-vRAN


Cisco Prep, Cisco Tutorial and Material, Cisco Certification, Cisco Exam Prep, Cisco Guides

Cisco’s Contribution to Open vRAN Standards


Cisco an early advocate of Open Virtualized RAN, had launched “Open vRAN Ecosystem” way back in February 2018 at MWC Barcelona. With this launch, Cisco started its Open vRAN journey with like-minded partners e.g. Altiostar, Mavenir, Phazr, Tech Mahindra to name a few. The focus was to create an ecosystem that is designed to accelerate the viability and adoption of Open vRAN solution. Since then Cisco is working on architecting and building solutions, demos and trials with MNOs and helping to define open interfaces and management.

Early 2018, xRAN Forum defined the use of IETF’s NETCONF / YANG standard for programmatically configuring and managing its lower layer split RAN architecture. Cisco took a lead role working with operators and ecosystem partners, in helping the xRAN Forum define the use of NETCONF/YANG by the 5G Radio Unit. This laid the foundation for cross-domain orchestration of the RAN with other domains that had already adopted NETCONF / YANG.

Cisco’s Value Proposition


Cisco has a significant role in the Open Virtualized RAN ecosystem in the areas of automation, virtualization, software integration, infrastructure and lead integrator of the solution components. Cisco becomes the technology glue to bring together these modules thereby arriving at an end to end solution.

Cisco’s Magic Glue Binds the Pieces of the OvRAN Puzzle

◉ Choice of virtualization & NFV

◉ Automation & Orchestration

◉ Systems integration

◉ Industry leading infrastructure

◉ Multiple choice of fronthaul, midhaul & backhaul solutions

◉ Most widely deployed mobile core solutions

Industry Trials, Demonstrations and Pilots


The UK government, in March 2018 funded testbed for the prestigious project “5G RuralFirst” to help the country take a leading position in 5G. The challenge was to provide secure and reliable mobile connectivity to the rural area and support rural communities and industries like agriculture, broadcasting, and utilities. Cisco led this project and supported with its 5G Core Network and Cloud service while Parallel Wireless was the part of the ecosystem with its multi-technology Open RAN solution.

In September 2018 MWC Americas at LA, Cisco demonstrated industry-first 5G SA data call using Phazr’s virtualized RAN and Cisco’s Cloud Native 5G Core. The solution also included MEC and Synamedia. (Earlier Cisco’s Service Provider Video Software Solution). In the same event, Cisco showcased a pre-certified, pre-integrated, ready to deploy end to end open vRAN system. Tech Mahindra, Altiostar and Cisco led this solution and proved that the open multivendor vRAN solutions were possible.

Recently in June 2020, Cisco and Telenor joined hands to strengthen the focus on areas like 5G, Open vRAN, and distributed Cloud to support critical infrastructure transitions for Telcos. The companies are continuing the exploration of new 5G architectures and have started an Open vRAN trial at Telenor headquarters in Norway to further investigate using a virtualized, open infrastructure to improve cost efficiency for service rollouts. A new round of financing of the joint venture, Working Group 2 (WG2) was also announced. WG2 offers a carrier-grade, cloud-native mobile core solution that enables rapid service innovation MNOs, MVNOs, and enterprises. Using open APIs and cross-network interoperability, WG2 radically transforms the ability of mobile operators to innovate quickly.

Real-World Deployments and Recognitions


While we had many demonstrations and trials of the Open vRAN solution at prominent events across the globe, the most rewarding for Cisco was the commercial deployment for Rakuten Japan in February 2019. The first-ever network that is fully virtualized from RAN to Core, leveraging mobile edge computing with end to end automation for both network and services. Cisco played a very critical role in this exciting journey alongside Rakuten and was well appreciated by the MNO emphasizing the crucial role of common and distributed telco cloud platform used to host many virtualized applications including Altiostar’s virtualized RAN applications vCU and vDU. End to end automation solution with Zero Touch Provisioning (ZTP) enabled instantiation of vRAN to fully operationalize a cell site in a matter of minutes with no manual intervention, helping Rakuen to scale the network in the future at a very faster rate.

In November 2018, Cisco was recognized for its 5G leadership by winning the Fierce Innovations Award for “NextGen Deployment Wireless” for its fully virtualized deployment and E2E automation with Rakuten. This was the 3rd industry award for Cisco 5G software-defined network in 2019. The first two given to Rakuten were the Light Reading Leading Lights awards for “Most Innovative Telco Cloud Strategy by an operator” and “Most Innovative Automation Strategy by an Operator.”

The Open vRAN wave is certainly building now. More and more MNOs are thinking about getting rid of legacy architectures and embrace Open vRAN.

Bharti Airtel, India’s leading MNO decided to take this path and in April this year announced its Open vRAN deployment with Cisco and Altiostar. Bharti became the first Indian Mobile Network Operator to deploy vRAN based 4G Network that is open that is seamlessly upgradeable to 5G.

Etisalat, one of the world’s leading telecom groups, announced the successful launch of Open vRAN early this year to become the first operator to adopt the technology in the Middle East. The success of this deployment was possible with the collaboration of Etisalat, Cisco, Altiostar and NEC.

Similarly, for one of its kind projects in the aviation industry, Gogo, a supplier of broadband connectivity products and services for Aviation, last year announced Cisco, Airspan, and First RF as its partners to supply elements for its air-to-ground (ATG) 5G network for use on business aviation aircraft and commercial regional jets operating within the United States and Canada.

Collaboration with WWT and Altiostar


World Wide Technology (WWT) is a technology solution provider that provides innovative technology and supply chain solutions to large public and private organizations. WWT, from their Advanced Technology Center brings integration and deployment capabilities for operators. Recently, in April 2020, World Wide Technology (WWT) announced a collaboration with Cisco and Altiostar to develop an Open vRAN blueprint and validation lab. WWT will be taking a lead role to integrate, validate, and deliver multi-vendor solutions Thus, Service Providers will be able to see the Open vRAN solution in operation, get their hands on it, and test features that they require helping faster validation and deployment.

Source: cisco.com