Sie sind auf Seite 1von 129

||||||||||||||||||||

||||||||||||||||||||
||||||||||||||||||||

Cisco CCIE Evolving Technologies V1.1


CCIE Written Exam Cert Guide Series

Muhammad Afaq Khan, CCIE #9070

1st Edition,

||||||||||||||||||||
||||||||||||||||||||

||||||||||||||||||||
||||||||||||||||||||

Contents at a Glance

Part I
Chapter 1: Compare and contrast public, private, hybrid, and multi-cloud design
considerations
Chapter 2: Describe cloud infrastructure and operations

Part II
Chapter 3: Describe architectural and operational considerations for a programmable
network

Part III
Chapter 4: Describe architectural framework and deployment considerations for IoT

||||||||||||||||||||
||||||||||||||||||||

Table of Contents
Preface
What this Exam Cert Guide covers
How to use this Exam Cert Guide
What's available on the CCIEin8Weeks.com
Background
Topics Added in V1.1
Topics Removed in V1.1
OpenStack and Intercloud
Part I: Cloud
Chapter 1: Compare and Contrast Public, Private, Hybrid, and Multi-cloud Design Considerations
Public Cloud
Private Cloud
Virtual Private Cloud (VPC)
Hybrid Cloud
Multi-cloud
Infrastructure as a service (IaaS)
Platform as a service (PaaS)
Software as a Service (SaaS)
Consolidation
Virtualization
Automation
Performance, Scalability, and High Availability
Performance
Scalability and High Availability
Security Implications, Compliance, and Policy
Workload Migration
Chapter 2: Describe Cloud Infrastructure and Operations
Compute Virtualization (Containers and Virtual Machines)
Installing Docker
Using Docker Commands
Connectivity (Virtual Switches, SD-WAN and SD-Access)
Virtual Switches
Virtual Machine Device Queues (VMDq)
Single Root IO Virtualization (SR-IOV)
SD-WAN and SD-Access
Cisco SD-WAN Solution (formerly Viptela)
Software-Defined Access (or SD-Access)
Virtualization Functions (NFVI, VNF, and L4/L1)
NFVI and VNFs
Virtual Topology Forwarder (VTF)
Automation and Orchestration Tools (CloudCenter, DNA-center, and Kubernetes)
Cisco CloudCenter Manager and Orchestrator

||||||||||||||||||||
||||||||||||||||||||

Cisco DNA Center


Kubernetes
Exam Essentials
Further Reading
Part II: Network Programmability
Chapter 3: Describe Architectural and Operational Considerations for a Programmable Network
Data Models and Structures (YANG, JSON and XML)
YANG
YAML
JSON
JSON Example
XML
XML Example
Device Programmability (gRPC, NETCONF and RESTCONF)
gRPC
NETCONF
NETCONF Example
RESTCONF
Using RESTCONF to Retrieve Full Running Configuration
Using RESTCONF to Retrieve Interface Specific Attributes
Controller Based Network Design (Policy Driven Configuration and Northbound/Southbound APIs)
Policy-driven Configuration
Northbound and Southbound APIs
Configuration Management Tools (Agent and Agentless) and Version Control Systems (Git and SVN)
Configuration Management Tools (Agent and Agentless)
Version Control Systems (Git and SVN)
Creating Configuration Change
Building New Configuration
Testing New Configuration
Deploying New Configuration
Exam Essentials
Further Reading
Part III: Internet of Things
Chapter 4: Describe Architectural Framework and Deployment Considerations for Internet of Things
(IoT)
IoT Technology Stack (IoT Network Hierarchy, Data Acquisition and Flow)
Embedded Systems Layer
Multi-Service Edge (or Access) Layer
Core Network Layer
Data Center Cloud Layer
Data Acquisition and Flow
IoT Standards and Protocols (characteristics within IT and OT environment)
IoT Security (network segmentation, device profiling, and secure remote access)
IoT Edge and Fog Computing (data aggregation and edge intelligence)
Data Aggregation
Edge Intelligence
Exam Essentials
Further Reading

||||||||||||||||||||
||||||||||||||||||||

||||||||||||||||||||
||||||||||||||||||||

Preface
Congratulations. You have taken your first step towards passing your CCIE written
exam. This written exam cert guide will help you prepare for Evolving Technologies
section which carries 10% weight in all CCIE and CCDE written exams.

||||||||||||||||||||
||||||||||||||||||||

What this Exam Cert Guide covers


As you may already have noticed on the "Contents at a Glance" page that this guide
covers Evolving Technologies V1.1 and has been formatted around the Cisco's official
Evolving Technologies (V1.1) blueprint exam topics that went into effect on August 30th
2018. Why does the formatting matter? Well, if you ever need to know where you're
within your test prep journey, all you have to do is to pull up the official exam topics
and you will know. It makes your learning so much easier.

Each exam topic has an “Exam Essentials” and a "Further Reading" section, which you
can refer to if you are looking for key exam related takeaways and more in-depth details
respectively. “Further Reading” web links are handpicked and contain in-depth
information on some of the exam topics and we have done the research for you.

||||||||||||||||||||
||||||||||||||||||||

How to use this Exam Cert Guide


This guide is for anyone who's studying for the CCIE written exam and feels that he or
she could take some help with regard to Cloud, Network Programmability and IoT
related topics. These are areas that most network engineers do not work on in their day
to day lives. Having said that, using whatever resources you prefer, please be sure to
brush up on exam topics that are specific to your track. In some cases where there is
more than one correct answer, let’s say challenges or benefits for IoT, I have picked the
answer(s) that’s endorsed by Cisco.

I strongly suggest that you take a methodical approach for exam preparation, i.e. start
with a target date as to when you would like to sit for your exam and then work
backwards to see what kind of study plan would work for you.

||||||||||||||||||||
||||||||||||||||||||

What's available on the


CCIEin8Weeks.com
CCIEin8Weeks.com is a home to thousands of test takers and learners worldwide. As a
small token of appreciation for purchasing this book, each customer is entitled to FREE
access to our Evolving Technologies V1.1 web Quiz.

Please share with us your Amazon Kindle or paperback Order # as a proof of purchase.
Please sign up on our website and request your complementary access by going to our
contact us page (https://www.cciein8weeks.com/company/support/). Our support staff
will provision your access within 72 hours.

CCIEin8Weeks.com also carries the extras, sold separately, that go hand in hand with
this exam cert guide to further ensure your exam and career success. We offer exam prep
material for R&S V5.1, DC V2.1, Security V5.0, SP V4.1 and Collaboration V2.1
exams.

Let me list down the additional resources that are available on our website.

Practice quizzes, each quiz contains questions that are broken down into
sections as per Cisco’s official written exam blueprint. For example, if you
are preparing for CCIE R&S written exam, you will find seven different
quizzes in your membership area, i.e.
Network Principles

||||||||||||||||||||
||||||||||||||||||||

L2 Technologies
L3 Technologies
VPN Technologies
Infrastructure Security
Infrastructure Services
Evolving Technologies (V1.1)

Our quiz engine is web-based and can be used from desktop as well as mobile
devices. You can check out our sample questions by going to product pages for
each track.

Study guides, much like this one, each CCIE written exam guide is organized
around the Cisco’s official blueprint so you can track and pace your exam
prep journey
Study plans, to help you organize your learning goals and stay motivated
CCIE blog, where we regularly publish articles in the areas of networking
industry and technologies as well as CCIE related news
Last but not least, we also offer a curated list of CCIE books as well as free
resources that you can optionally tap into to round out your learning and test
prep

||||||||||||||||||||
||||||||||||||||||||

Background
As you may recall that Cisco added Evolving Technologies v1.0 (ET v1.0) section
around mid-2016 to entire CCIE/CCDE program to keep pace with the rapidly changing
technology arena and in order to keep CCXX program relevant for Cisco certified
experts. ET section primarily focuses on cloud, network programmability (i.e. SDN,
NFV etc.) and Internet of Things (IOT). Cisco recently announced a update (v1.1) to
their initial list of topics in order to achieve the above stated goal.

I am happy to see that Cisco has taken a step in the right direction by adding newer
topics and making the overall section more meaningful this time around. Now, as far as I
am concerned, I’d like to see Cisco turn Cloud into Cloud architecture and
implementation whereas network programmability into more of a primer on network
automation and NetDevOps and increase ET weight to at least 20% across both written
and lab exam formats. What do I mean by that? There is still some room to improve,
but we’re heading in the right direction.

Overall, it seems that Cisco has added 18 topics whereas removed about 10. Let me
summarize the topics that are added or removed in Evolving Technologies v1.1 by each
domain of knowledge.

||||||||||||||||||||
||||||||||||||||||||

Topics Added in V1.1


Cloud
Scalability
High Availability
Compliance
Compute Virtualization (Containers)
Connectivity (virtual switches, SD-WAN and SD-Access)
NFVI, VNF and L4-L7
Orchestration Tools (CloudCenter, DNA Center, and Kubernetes)
Network Programmability
Models and Structures (YANG, JSON, and XML)
Device Programmability (qRPC, NETCONF, and RESTCONF)
Policy-Driven configuration
Management Tools (Agent and Agentless)
Version Control Systems (Git and SVN)
Internet of Things (IOT)
Network Hierarchy and Data Acquisition and Flow
Characteristics Within IT and OT Environments
IoT Security (Network Segmentation, Device Profiling, and
Secure Remote Access)
IoT Edge and Fog Computing (Data Aggregation and Edge
Intelligence)

||||||||||||||||||||
||||||||||||||||||||

Topics Removed in V1.1


Cloud
Interoperability
OpenStack components
Intercloud
Network Programmability
DevOps tools
Internet of Things (IOT)
Performance, availability, and scaling considerations
Performance, reliability and scalability
Mobility
Security and privacy
Standards and compliance
Migration
Environmental impacts on the network

OpenStack and Intercloud

It is not surprising that “OpenStack Components” and Intercloud sub-sections from V1.0
blueprint have been dropped. If you recall, Cisco abandoned OpenStack-based
InterCloud efforts back in September 2016. Cisco has replaced that with CloudCenter,
DNA Center, and Kubernetes topics.

||||||||||||||||||||
||||||||||||||||||||

||||||||||||||||||||
||||||||||||||||||||

Part I: Cloud

This part covers the following exam topics from Cisco's official Evolving Technologies
(v1.1) written exam curriculum.

Chapter 1: Compare and Contrast Public, Private, Hybrid, and Multi-cloud Design
Considerations
Infrastructure, platform, and software as a service (XaaS)
Performance, scalability, and high availability
Security implications, compliance, and policy
Workload migration

Chapter 2: Describe Cloud Infrastructure and Operations


Compute virtualization (containers and virtual machines)
Connectivity (virtual switches, SD-WAN and SD-Access)
Virtualization functions (NFVi, VNF, and L4/L1)
Automation and orchestration tools (cloud center, DNA-center, and
Kubernetes)

||||||||||||||||||||
||||||||||||||||||||

Part I: Cloud

||||||||||||||||||||
||||||||||||||||||||

Chapter 1: Compare and Contrast Public, Private,


Hybrid, and Multi-cloud Design Considerations
Cloud computing is the result of a well thought out infrastructure by the providers, in the
same way that electricity, water, and gas are the result of decades of infrastructural
development by the utility providers. Cloud computing is made available through
network connections in the same way that public utilities have been made available
through networks of pipes and wires. By definition, all clouds are scalable (resources
are added as demand rises) and elastic (grow or shrink resources as demand rises or
falls).

It is estimated that AWS, Azure and GCE will have 52%, 21% and 18% market share by
2020.

||||||||||||||||||||
||||||||||||||||||||

Cisco’s definition of cloud defines the following four aspects as must-have for a cloud
service, i.e.

On-demand, means resources follow demand pattern, they are provisioned


and deprovisioned with increasing and decreasing demands respectively
At-scale, means cloud provider has enough supply of resources to meet
demands from all its customers, i.e. providing cloud services at-scale.
Multitenant, means cloud services are inherently multi-tenant out of the box
Elastic, means that corresponding cloud services will grow or shrink based
on customer’s demand patterns

Before we dive into the “design considerations” for each cloud deployment model, let’s
first understand each type of the cloud that exists out there.

Public Cloud

The public cloud is defined as computing services offered by third-party providers,


such as AWS, over the public Internet, making them available to anyone who wants to
use or purchase them. Cloud services may be free or sold on-demand i.e. pay-as-you-
go, allowing customers to pay only per usage for the CPU cycles, storage, or bandwidth
they actually use. Public cloud users simply sign up for a service, use the resources
made available to them, and pay for what they used within a given amount of time.

As per CLOUD VISION 2020 survey, digital transformation, IT agility and DevOps are
the top drivers for public cloud adoption.

||||||||||||||||||||
||||||||||||||||||||

Technically speaking, a public cloud is a pool of virtual resources that include compute,
storage and networking, all developed from commodity hardware owned and managed
by a third-party provider such as AWS or Azure, that is automatically provisioned and
allocated among multiple customers in a multi-tenant fashion through a self-service
interface. It’s an economically compelling way to scale out workloads that experience
unexpected demand fluctuations.

A public cloud is the simplest form of all cloud deployments: A customer that needs
more resources and platforms such as servers or storage, or services simply pays a
public cloud vendor by the hour or the minute, to get access to what’s needed when it’s
needed. Infrastructure, computing power, storage, or cloud applications are decoupled
from underlying hardware with the help of virtualization by the vendor, orchestrated
mostly by open source management and automation software. Connectivity to a public
cloud generally happens via the internet (obviously, encrypted) but also through
dedicated low latency network connections available at large colocation data centers,
much like AWS Direct Connect.

Private Cloud

The private cloud is about offering computing services either over the Internet or a
private internal network, such as WAN. In terms of service offering, private cloud is no
different than public cloud, but dedicated to the needs and goals of a single enterprise as
opposed to being shared and multi-tenant. It is worth mentioning that private cloud is not
to be confused with its location, because it can be located on-premise (internal) or off-
premise (hosted).

Due to single-tenant provisioning and dedicated use of resources, private clouds deliver
higher degree of control and customization, as well as higher level of security and
privacy. Private cloud also provides better service SLAs and data security when hosted
on-premise or what is known as an internal cloud.

One drawback of an internal cloud is that the company’s central IT department is held
responsible for the cost and accountability of managing the cloud leading to similar
staffing, management, and maintenance expenses as traditional data center ownership.
Private clouds can be either self or provider-managed such as Rackspace.

||||||||||||||||||||
||||||||||||||||||||

Virtual Private Cloud (VPC)

Virtual private cloud (or VPC) is a private cloud carved out inside a public cloud for
the sole purpose of being used by a single tenant. It provides isolation of data both in
transit and at-rest resulting in enhanced security and data control.

Cloud provider will let you provision a cloud router and a firewall, so you can connect
remote or on-premise resources to a VPC. AWS provides features such as security
groups, ACLs and flow logs that capture information about the IP traffic going to and
from network interfaces within your VPC.

Hybrid Cloud

A hybrid cloud combines the benefits of public and private clouds by allowing data and
applications to be shared between them. When workload demand changes, hybrid cloud
computing allows businesses the ability to seamlessly scale using public cloud and thus
handle overflow or demand bursts without giving third-party service provider access to
the totality of their data.

Hybrid cloud architecture is a best of both worlds approach and that is what allows
enterprises to run critical workloads in the private cloud and lower risk workloads in
the public cloud and allocate resources from either environment as desired in an
automated fashion via APIs. It’s a setup that minimizes data exposure and allows
medium to large enterprises to maintain a scalable, elastic, and secure portfolio of IT
resources and services.

Using a hybrid cloud helps companies eliminate the need to make CAPEX investment to
handle short-term or seasonal spikes in demand as well as when the business needs to
free up on-premise resources for more sensitive data or applications. In summary,
hybrid cloud computing delivers flexibility, scalability, elasticity and cost efficiencies

||||||||||||||||||||
||||||||||||||||||||

with the lowest possible risk of data exposure.

As per Cisco, there are five major challenges involved with deploying and managing a
hybrid cloud, i.e.

Cloud management
OPEX
Security
No common ground
Lack of expertise within IT

Multi-cloud

Multi-cloud is not yet another cloud model per se, but rather a cloud deployment
approach made up of multiple cloud services, from multiple cloud service providers,
public or private.

By definition, “multi” cloud refers to the presence of more than one cloud deployment of
the same type. Unlike hybrid cloud, multi-cloud refers to the presence of multiple clouds
of the same type, e.g. two private clouds or two public clouds. The drivers behind the
trends are avoiding vendor lock-in, cost savings, performance, better defenses against
Distributed Denial of Service (DDoS) attacks, improved reliability and perhaps the
existence of shadow IT.

IDC predicted that more than 85% of Enterprise IT organizations will chalk up a plan to
use multi-cloud architectures by 2018. Cisco also said that a small number of gigantic
hyperscale data centers would hold just over half of all data center servers, and account
for 69% of all data center processing power, and 65% of all data stored in data centers.
Primarily on the basis of multi-cloud, Gartner also expects 80% of enterprises will
have shut down their traditional data centers by 2025, up from just 10 percent today.

||||||||||||||||||||
||||||||||||||||||||

Let us compare the two major cloud models side by side in the critical areas of
capacity, control, cost, service SLAs, security and customization.

Public Private
Capacity Multi-tenant, nearly unlimited Single-tenant, limited
resources resources (matched to
demand)
Control Shared with cloud service Complete control to
provider configure and manage
resources
TCO Shared resources, highest return Non-shared resources with
on investment with no upfront upfront costs, but
costs predictable

Everything is OPEX CAPEX + OPEX


Reliability or >= 99.99% (AWS) Up to 99.999%
Service SLA >= 99.99% (GCE)
Security Shared resources, lower Non-shared resources,
highest
Customization Shared resources, limited Non-shared resources,
unlimited
Infrastructure as a service (IaaS)

Infrastructure as a service (IaaS) is a cloud service model where compute, storage and

||||||||||||||||||||
||||||||||||||||||||

networking resources and capabilities are owned and hosted by a service provider and
offered to customers on-demand. Using a self-service interface, customers are able to
self-provision and self-manage this infrastructure, using a web-based interface that
serves as an IT single-pane of management for the overall environment.

Public cloud providers also facilitate REST API access to the infrastructure so IT
departments can manage those off-premise resources using their existing tools. IaaS
solutions also form the basis for PaaS and SaaS service models. Compared to SaaS and
PaaS, IaaS users are responsible for managing applications, data, runtime, middleware,
and OSes. Providers still manage the lower layers of virtualization (i.e. the hypervisor),
physical servers, disk drives, storage volumes, and network connectivity.

Platform as a service (PaaS)

Platform as a Service (PaaS) allow developers to build, run and manage applications in
the cloud. PaaS provides a framework which developers can to build customize
applications. PaaS makes the dev/test, and deployment of applications quick and cost-
effective. With PaaS enterprise IT no longer have to manage OSes, virtualization,
servers, storage, networking, including the PaaS software itself.

Popular examples of PaaS include Google App Engine (GAE), Microsoft Azure .NET
and Heroku. GAE allows up to 25 free and unlimited paid applications, you can code
your apps in Java, Python, Go, PHP and tons of other languages.

The cloud offers several unique benefits to developers and service users as opposed to
using on-premise, namely scalability, availability, collaboration, and portability.

||||||||||||||||||||
||||||||||||||||||||

Software as a Service (SaaS)

Software as a service (or SaaS) is a way of delivering centrally hosted applications


over the Internet, as a service as opposed to locally installed. SaaS applications run on
a SaaS provider’s servers.

With SaaS, you don’t have to install or maintain software, you simply access it via the
Internet. This allows enterprise IT teams to reclaim both CAPEX and OPEX that would
have otherwise be used to manage complex software and hardware in order to support
applications if they were hosted on-premise. The provider manages not only the access
to the application, but also security, availability, and performance. SaaS business
applications are accessed by end users using a web browser over secure SSL transport.
Popular examples of SaaS include Web email platforms such as Gmail, CRM, HRM,
and Unified Communication software such as Cisco WebEx.

Let us compare the three major cloud service models side by side in the critical areas of
cost, control, application software management, upgrades, security and data controls.

Cloud Service IaaS PaaS SaaS

||||||||||||||||||||
||||||||||||||||||||

Models
TCO (per app user) Lowest High Highest
Control Highest High Lowest
Software Stack Mostly Mix of provider and Mostly
Management & customer customer managed provider
Upgrades managed managed
Subscription Model PAYG PAYG PAYG
Software Stack Mostly Mix of provider and Mostly
Security and Data customer customer managed provider
managed managed
Top Vendors AWS, Azure Azure Salesforce

In Cisco’s view, data center evolution towards service-oriented or software-defined


should happen in three different phases, i.e.

Consolidation
It is about breaking down of resources silos and reduce the number of physical data
centers as a result. Consolidation of resources include servers, storage and networking.
Virtualization
Virtualization is the foundation technology behind cloud where compute, storage and

||||||||||||||||||||
||||||||||||||||||||

networking resources can be dynamically partitioned, provisioned and assigned to


applications. Virtualized resources pools of compute and storage can be far more easily
allocated on-demand and in an elastic fashion as opposed to their physical variant, for
example a cloud server versus a bare-metal.
Automation
Service automation enters once resources are consolidated and virtualized. It allows an
intelligent network fabric to rapidly and automatically find and respond to application
resource requirements, i.e. provision processing, storage and security resources on-
demand.
Performance, Scalability, and High Availability
Performance

In order to benchmark cloud performance, let’s first break it down to its most
fundamental components, i.e. compute, storage, and networking and the overall SLA
depending on the service model, that is guaranteed to you by your service provider.
Obviously, the performance of your instances in a cloud, public or private, is bounded
by the actual underlying hardware. In case of public cloud, you are sharing resources in
a multi-tenant fashion, however that doesn’t mean that you will not receive your
allocated resources. Now, if your application is consistently trying to request more than
what your chosen instance allows for, then your application performance may degrade,
and your only recourse could be to upgrade to a larger compute instance. On AWS, you
can use CloudWatch metrics to monitor your CPU load in case if your workload is
running continuously “hot”.

There is another lesser known term known as CPU steal time, which is nothing but the
percentage of time a vCPU has to wait for the real CPU. You can see your VM’s steal
time using the Linux “top” command. If your VM consistently displays a high %st (steal
time), this means CPU cycles are being taken away from your VM to serve others. You
may be using more than your share of CPU resources, or the physical server where VM
is located, may be overprovisioned. If steal time remains high, try giving your VM more
CPU resources or move to a different physical server. Applications that need short
bursts of CPU resources, e.g. Web apps, will see serious performance degradation
during periods of high steal time.

||||||||||||||||||||
||||||||||||||||||||

You can monitor and benchmark cloud performance by either using cloud provider’s
built-in tools or using a third-party tool such as CloudHarmony.

IaaS (All deployment models)


Compute CPU units and DRAM
Storage IOPS and RW latency
Network Bandwidth and latency
Service SLA, monthly Must be equal to or greater than four 9s (99.99%), 4
billing cycle minutes of downtime per month

When you move your on-premise application into a PaaS cloud, you need to ensure that
they are performant and secure. There are several considerations that you would need to
factor into your decision that may be incrementally or entirely different from how you
manage your application performance on-premise or inside your data center.

For PaaS and SaaS, overall service SLA uptime is still useful but not enough on its own.
With PaaS and SaaS, you must take into account the application performance because
service SLA (or uptime) is insufficient to guarantee an excellent end user experience.

PaaS (All deployment models)


Application Performance Vendor (could be built into PaaS stack or a third-party
Management (APM) APM)
Deployment method (could be within the cloud or on-
premise)
Application types (Java, .NET or Ruby)

Service SLA, monthly billing Must be equal to or greater than four 9s (99.99%), 4
cycle minutes of downtime per month

SaaS is one of the most mature segments of cloud computing market where likes of
Salesforce, Workday and WebEx dominate CRM, HRM/HCM and Unified
Communication verticals respectively. SaaS provides faster time to market, reduces
TCO and comes with seamless upgrades. However, those benefits don’t hold much
value if your SaaS applications are unable to provide a quality user experience. In case

||||||||||||||||||||
||||||||||||||||||||

of SaaS, your cloud provider can’t dictate to you what constitutes acceptable
performance for your business.

SaaS (All deployment models)


Application Performance Application(s) must meet business driven thresholds
Management (APM)
Service SLA, monthly billing Must be equal to or greater than three 9s (99.9%), 10
cycle minutes of downtime per month

Scalability and High Availability

Cloud scalability refers to the phenomenon where workload increase leads to addition
of more incremental resources whereas elasticity refers to how workload increase or
decrease dictates the provisioning as well as deprovisioning (or shrinking) of
resources. You can achieve elasticity in AWS by configuring auto scaling for your EC2
instance.

With most IaaS cloud providers, you should be able to configure auto scaling in a
variety of different ways, i.e.

You can use auto scaling group to maintain a minimum or a specified number
of running instances at all times
You can use manual scaling to specify the maximum, minimum, or desired
capacity of your auto scaling group
You can also perform scaling by calendar schedule, i.e. scaling actions are
performed automatically as a function of time and date
You can also do scaling by policy, where you define the parameters that in
turn control the scaling

High availability, in the cloud, is achieved by creating multiple instances of your


application and directing traffic (or load) to them on an elastic load sharing basis. For
fault tolerance reasons, you can also place those instances in different Availability
Zones (or AZs) within or across regions.

IaaS cloud deployment model provides you with the most control over your cloud
application scalability and high availability as opposed to PaaS and SaaS where you

Technet24
||||||||||||||||||||
||||||||||||||||||||

naturally depend on your provider. In case of PaaS and SaaS, infrastructure such as
compute, storage and networking are pre-provisioned for you. In case of PaaS, you can
create multiple instances in separate geographies with shared storage. However, in case
SaaS, your provider configures and maintains scalability and HA for you.
Security Implications, Compliance, and Policy

Security has been the #1 issue cited hindering cloud adoption for a long time.
Obviously, IT teams must take into account the needs for security and compliance based
on the business and government policies for the given vertical (e.g. financial vs
technology) and geography. Cloud Security Alliance (or CSA) publishes best practices
for providing security assurance and compliance for cloud computing.

Cloud security primarily refers to either security to the cloud or security for the cloud.
Keep in mind that any security solution technically can be delivered from the cloud.
Cloud security threats fall into four main categories.

Malware and ransomware


Gaps in visibility and coverage
Compromised accounts and malicious insiders
Data breaches and compliance

Cloud security requires a coordinated approach across the three main pillars of
networks, endpoints and the cloud. Each of these pillars have a specific set of
deployment form-factors that can be utilized based on an organization’s needs.

Depending on the cloud deployment model, responsibility for security in the cloud is
shared between your central IT department as well as your cloud provider.

IaaS PaaS SaaS


Your responsibility as Apps / Apps / Apps /
a Customer Customer Customer Customer
Content Content Content
Data Data Data
Software Software
platform platform
OS
Compute
Storage

||||||||||||||||||||
||||||||||||||||||||

Networking
Database
Provider Physical infra OS Software
responsibility Compute platform
Storage OS
Networking Compute
Database Storage
Physical infra Networking
Database
Physical infra

Large number of security threats are associated with the data itself, i.e.

Confidentiality
Access controls
Integrity

Likewise, there are numerous laws and regulations out there relating to the storage and
use of data. In the US, these privacy protection laws include the following.

PCI-DSS
HIPAA
SOX
FISMA

In order to meet those compliance requirements, cloud providers need to maintain the
following.

Business continuity and data recovery


Log and audit trail
Geo fencing and data placement (including GDPR in Europe)
Workload Migration

Cloud workload migration is entirely dependent on your cloud deployment model, i.e.
IaaS, PaaS or SaaS. As per Cloud Vision 2020 survey, it is estimated that over 80% of
enterprise workloads will be in the cloud by 2020.

Technet24
||||||||||||||||||||
||||||||||||||||||||

In case of IaaS, your workload consumes resources in the form of compute and storage
units where PaaS/SaaS workload is about the software stack. Workload here refers to
one of the following entities.

Physical machine
Virtual machine (VM)
Container
Application + Data

There can be four major types of workload migration pattern, i.e.

Physical to virtual (P2V)


Virtual to cloud (V2C)
Cloud to virtual (C2V)
Cloud to cloud (C2C)

Following are the common drivers for on-premise to cloud workload migration.

Decreasing OPEX (ability to match supply and demand in an automated


fashion)
Improving workforce productivity (no wait for infrastructure and out-of-the-
box services)
Eliminating CAPEX (no hardware refresh)
Improved scalability and HA (multiple zones, regions across the world)
Faster Time to Market (TTM)

||||||||||||||||||||
||||||||||||||||||||

Workload migration to the cloud, needs to be driven by the business value that would
have been gained by the cloud user (e.g. better user experience) as well as the central IT
(e.g. reduced cost, avoiding vendor lock-in, improved HA etc.). You need to gain a
thorough understanding of which migration strategy will be best suited for your existing
infra and apps.

Following are the common migration strategies for on-premise to cloud workload
migration broken down by the cloud deployment models.

Ways to Move from IaaS PaaS SaaS


On-Premise IT to Cloud Service
Rehost (lift and shift) Applicable Applicable N/A
Replatform (lift, tinker and shift), N/A Applicable N/A
software
Repurchase (drop and shop), software N/A Applicable Applicable
Refactor / Re-architect, software N/A Applicable N/A
Retire, turn off hardware or software Applicable Applicable Applicable
Retain N/A Applicable Applicable

Technet24
||||||||||||||||||||
||||||||||||||||||||

||||||||||||||||||||
||||||||||||||||||||

Chapter 2: Describe Cloud Infrastructure and Operations

Compute Virtualization (Containers and Virtual Machines)

Compute virtualization is a simplification of legacy architecture to reduce the total


number of physical servers. Server virtualization allows us to run multiple operating
systems on a single physical machine, where each OS can run inside a separate virtual
machine or VM. x86 server virtualization was pioneered by VMware in the late 1990s.

There are numerous benefits of compute virtualization including but not limited to the
following.

Improved security
Easier administration
Cost savings
Consolidation and centralization of physical servers
Faster TTM

Technet24
||||||||||||||||||||
||||||||||||||||||||

A container image is a lightweight, portable and executable package of software that


consists of code, runtime libraries, system tools and libraries etc. Containers are
available for both Linux and Windows based apps. There are a variety of container
technologies that exist today.

Docker containers
Java containers
Unikernels
LXD (LXD is based on liblxc, its purpose is to control some lxc with added
capabilities, like snapshots or live migration)
OpenVZ
Rkt
Windows server containers
Hyper-V containers

It is worth noting that LXCs (Linux Containers) are an OS-level virtualization


mechanism for running multiple isolated Linux systems (or containers) on a control host
using a single Linux kernel. LXD isn't a repackaging of LXC, in fact it was built on top
of LXC to provide a new, better user experience. Technically speaking, LXD uses LXC
through liblxc and its Go binding to create and manage the containers.

Docker is an open platform for developers and sysadmins to build, ship, and run
distributed applications, whether on laptops, data center VMs, or the cloud. Docker can
build images automatically by reading the instructions from a Dockerfile. A Dockerfile
is a text file that contains all the commands a user could call on the command line to
assemble an image. In Docker, everything is based on Images. An image is a
combination of a file system and parameters. A container is a runtime instance of an
image. Dockerfile is used to build the image when you run “docker build”.

By default, docker related files are located under /var/lib/docker folder.

Container image contains executable package of a piece of software that includes


everything needed to run it: code, runtime, system tools, system libraries, settings.

||||||||||||||||||||
||||||||||||||||||||

It is crucial to understand the difference between a VM and a container. Containers are


an abstraction at the app layer that packages code and dependencies together whereas
VMs are an abstraction of physical hardware, turning one server into many virtual ones.

Virtual Machine (VM) Docker Container


Host OS Yes N/A
Hypervisor Yes N/A
Guest OS Yes N/A
Bins/Libraries Yes Yes
Application Yes Yes
Typical Size (bytes) Tens of GBs Tens of MBs
Startup time Slower Faster

Installing Docker

Docker comes in community (free) and enterprise (paid) editions. While you can install
Docker on just about every Linux distribution and even windows, however in this
example, we’re going to use Ubuntu Linux.

First off, if you’ve previously installed some older versions of Docker, i.e. “docker” or
“docker-engine” or “docker.io”, you’d need to uninstall them first using the apt-get
command.

$ sudo apt-get remove docker docker-engine docker.io

The contents of /var/lib/docker includes images, containers, volumes and networks.


Docker CE edition is now known as “docker-ce”. When installing docker for the first

Technet24
||||||||||||||||||||
||||||||||||||||||||

time, you’d need to set up the repository. This process includes updating the APT repo,
add HTTPS to transport, add GPG key. Once that’s done, you can add the docker
repository.

$ sudo apt-get update

$ sudo apt-get install \


apt-transport-https\
ca-certificates\
curl\
software-properties-common\

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key


add -

$ sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"

Finally, you can install the latest version of Docker CE.

$ sudo apt install docker-ce

Using Docker Commands

After installation, you can verify if Docker is running or not with “docker ps”. As you
can see from the docker, there are three containers running inside docker, i.e. drone-
agent, drone-server and gitea-server.

||||||||||||||||||||
||||||||||||||||||||

You can check your docker version using “docker --version” command.

You can also check your local list of containers using “docker image ls”.

You can use “docker stop <container-id>” and “docker kill <container-id>“ to stop and
kill docker processes or containers. Now, in order to remove a docker image, you’d
need to use “docker rm <container-id>” command.

Connectivity (Virtual Switches, SD-WAN and SD-Access)

Network virtualization is about combining hardware and software network resources

Technet24
||||||||||||||||||||
||||||||||||||||||||

and functions into a software-based entity which can be managed by virtualization


management tools. It can be divided into two main categories, i.e.

External virtualization, traffic can span multiple servers and/or switches


Internet virtualization, traffic stays on a single server or a switch and never
leaves the virtual network

External virtualization is about combining many networks into a virtual unit spanning
multiple servers or switches, whereas internal refers to providing network connectivity
to VMs or containers located on a single physical server. External network
virtualization units are generally carved out as VLANs, while internal virtualization
uses pseudo-interfaces such as Virtualized Network Interface Card (or vNIC) to emulate
a physical network.

Now, in the world of external virtualization, there are also several network-based
techniques that are used to provide virtualization or separation of traffic carried over a
single physical network. Let’s review some of those before we move to virtual
switches.

802.1Q VRF VXLAN NVGRE OTV


Layer 2 based Yes
Layer 3 based Yes Yes Yes Yes
Encapsulation VLAN ID None or MAC in IP MAC in MAC in
L3VPN IP/GRE IP

802.1Q or dot1q is the standard that brought us VLANs based on IEEE 802.3 standard.
This is what defined the VLAN tagging for ethernet frames.

Virtual Routing and Forwarding (or VRF) is a way to segment IP traffic with or without
L3 VPNs (such as MPLS VPNs). It is also known as VRF-Lite when used without L3
VPNs.

Virtual Extensible VLAN (or VXLAN) is used to create virtual overlays on top of a
physical underlay. VXLAN uses MAC in IP/UDP tunneling to extend L2 segments over
IP networks. VXLAN uses flood and learn mechanism much like ethernet itself. Ethernet
VPNs (or EVPNs) is a variation where VXLANs are used along with BGP to
accomplish routing between endpoints.

Network Virtualization using GRE (or NVGRE) uses MAC in GRE encapsulation to

||||||||||||||||||||
||||||||||||||||||||

extend L2 segments over routed network. It uses a subnet identified within the GRE
header to accomplish L2 extensions. NVGRE and VXLANs target the same use case.

Overlay Transport Virtualization (or OTV) uses MAC in IP encapsulation to create L2


overlays and provides support for multicast traffic.

Virtual Switches

Virtual switch is a piece of software that runs inside the hypervisor and allows one VM
to communicate with another. There are three well known virtual switches: VMware
virtual switch (available in standard & distributed packaging), Cisco Nexus 1000V, and
Open vSwitch (or OVS). Standard or standalone VMware vSwitch is meant to run on a
single ESX host, whereas a distributed vSwitch can manage up to 500 hosts.

Open vSwitch was created by Nicira which was subsequently acquired by VMware in
2012. OVS has its root within the open source community and with Linux-based
hypervisors, such as KVM and XEN. OVS is now also included within the OpenStack
distribution. OVS doesn’t come with a controller unlike Cisco’s VSM (for N1Kv) or
vCenter (for VMware distributed virtual switch). Open vSwitch is managed by third
party controllers and managers (e.g. OpenStack Neutron plug-in or OpenDaylight SDN
controller).

Intel DPDK implements a run to completion model for packet processing, where all
resources must be allocated prior to calling Data Plane applications, running as
execution units on logical processing cores. With LXCs and KVM, the TUN/TAP
subsystem creates a virtual ethernet interface attached to a process.

With the rise of 10Gbps and beyond, packet rates tend to exceed what a host is capable

Technet24
||||||||||||||||||||
||||||||||||||||||||

of when I/O virtualization is software based and the hypervisor (or VMM) permanently
reside in the data path between the physical NIC and the vNIC. In order to keep up with
increasing speeds, a combination of software and hardware features are used. It is
important to understand while server virtualization helped de-couple application
software stack from the underlying hardware, it led to increased CPU utilization and
reduction in I/O throughput, thus putting a limit on VM concentration per server.

Like with bare-metal hosts and NICs, in a virtualized environment, getting packets off
the wire for processing is also interrupt driven. When traffic is received by the NIC, an
interrupt request is sent to host CPU, which then must stop doing what it’s doing to help
retrieve the data. “CPU” here refers to CPU core running the hypervisor as well as the
CPU cores allocated to the VM that data is destined to. Now, obviously, that’s a double
hit. Historically speaking, two major techniques were developed to address this
bottleneck, i.e.

Virtual Machine Device Queues (VMDq)


Single Root IO Virtualization (SR-IOV)

Virtual Machine Device Queues (VMDq)

VMDq allows hypervisor to assign a queue in the physical NIC for each VM, thus
eliminating the need for the first interrupt destined to hypervisor. With this approach,
only CPU that’s running the VM, is interrupted and packets are then copied directly into
VM user space memory. This means packets are only touched once, resulting in higher
throughput and lower CPU utilization. In case if you were wondering how the frames
are classified to correct VMs, there is no magic and it happens via MAC or VLAN tag
found inside the incoming frame.

However, due to VMM still managing the I/O queues in the NIC for each VM, the
handoff still requires extra CPU utilization. This is where we enter SR-IOV.

Single Root IO Virtualization (SR-IOV)

SR-IOV is an extension of PCI Express (or PCIe) specification, unlike VMDq queue per
VM approach, SR-IO goes a one step further and creates a virtual function (or VF) that
behaves as if each VM has its own physical NIC. Each VF is allocated a descriptor that
knows where the corresponding VM user space memory is located. SR-IOV data
transfer happens via Direct Memory Access (or DMA). This approach results in several
benefits, i.e. it bypasses the virtual switch and the VMM, thus providing an interrupt-

||||||||||||||||||||
||||||||||||||||||||

free operation for extremely fast data I/O speeds.

SD-WAN and SD-Access

The software-defined wide-area network (or SD-WAN) is a variant of software-defined


networking (SDN) applied to WAN connections.

The “software-defined” connotation means that decisions about how traffic is steered
among all the sites in the WAN is determined by policy which helps it adapt to the real-
time condition of the WAN as opposed to being dictated by a pre-configured fixed or
static configuration. The “wide area” part refers to the fact that the sites/networks you
are looking to connect aren’t local to one another. There is another related term known
as SD-Access which refers to the edge or access part of technologies bringing in the
users in a software-defined fashion using wired, wireless or VPN transport.

Technet24
||||||||||||||||||||
||||||||||||||||||||

Cisco SD-WAN Solution (formerly Viptela)

Cisco SD-WAN (formerly Viptela) solution comprises of four main components.

vSmart Controller
vEdge Routers
vManage
vBond

vSmart controller forms the centralized control plane and policy orchestrator for the
SD-WAN solution.

||||||||||||||||||||
||||||||||||||||||||

vEdge router is a branch device that gets its policy from the centralized vSmart
controller service. Each edge router request about 100Kbps of bandwidth to the
controller.

vManage is the single point of policy management that also provides visibility and
analytics. You can drill down into individual vEdge devices by navigating through
vEdge up/down status part of the dashboard as shown below.

vBond technology is used for vEdge devices to find vSmart controllers. It is the
middleman that connects and bonds edge and control plane service together.

Technet24
||||||||||||||||||||
||||||||||||||||||||

Cisco SD-WAN virtual IP fabric transforms a complex legacy network into an easy-to-
manage, scalable network in five steps:

1. Separate transport from the service side of the network.

2. Centralize routing intelligence and enable segmentation.

3. Secure the network automatically.

4. Influence reachability through centralized policy.

5. Simplify orchestration and provisioning.

vEdge devices and vSmart controller connect with each other via a TLS based control
plane. You can configure certificates within vManage for encrypted and authenticated
communication. Each vEdge device can send traffic directly to another without
exchanging any reachability information. In order to provide scale, SD-WAN solution
uses IEEE’s Overlay Management Protocol (or OMP) that carries QoS, routing policy,
multicast and IPSec keys.

||||||||||||||||||||
||||||||||||||||||||

Cisco SD-WAN solution supports IPSec ESP and GRE encapsulations for its overlay
network. There is no IKE needed since key exchange is handled by OMP. Absence of
IKE helps speed up vEdge to vEdge tunnel setup time. The solution can classify traffic
based on ports, protocols, IP addresses and IP DSCP values. It can also classify traffic
based on applications. Policies are configured via vManage dashboard, and once done,
are communicated to vSmart controller, which in turn communicates them to vEdge
devices. If a vSmart controller goes down, affected vEdge devices can continue with the
last known good configuration.

Zero-touch provisioning relies on vBond which allows vEdge devices to connect into
vSmart controller without any prior configuration. Each vEdge device contains an SSL
certificate. All vEdge devices must be trusted by the vManage before they can be
managed by the vSmart controller.

For brownfield deployment, solution allows integration with VRF/VLAN by using a 4-


byte shim header known as label, which is part of each packet in the overlay and
functions as sort of a membership ID.

Here are the resources requirements for vBond, vEdge, vManage and vSmart Controller
components. Please note that vBond, vManage and vSmart Controller requirements
depend on the vEdge devices that are needed to be provisioned. Cisco provides
complete hardware and software installation guideline and requirements.

1-50 vBond vEdge vManage vSmart Controller


Devices Orchestrator
vCPUs 2 2 16 2

Technet24
||||||||||||||||||||
||||||||||||||||||||

vRAM 4 2 32 4
(GB)
SSD (GB) 10 10 20 16
Bandwidth 1 Up to 2 25 2
(Mbps)
Hypervisor ESXi / KVM

Software-Defined Access (or SD-Access)

Cisco’s SD-Access is an intent-based network solution for the enterprise. Intent-based


network is envisioned as a single system that provides the translation and validation of
business goals (referred to as “intent”) into actual network policies and insights. SD-
Access provides automated services such as network segmentation, QoS, analytics for
everything that connects into the network for example a user, device, or application
traffic.

SDA is needed because while network requirements have changed, but underlying
technologies and operations have not leading to slower service roll outs. As per Cisco,
following are the direct benefits of SD-Access solution.

Automated policy and provisioning for the management of wired/wireless


network
Automated group-based policies and network segmentation
Faster issue resolution and capacity planning
Open programmable interfaces for integration with third-party solutions

SDA is implemented with Cisco DNA Center which brings together all the elements of
design, policy definition for a wired and wireless network. We can divide the overall
solution into two layers, i.e.

SDA Fabric
DNA Center

||||||||||||||||||||
||||||||||||||||||||

SDA network fabric is made up of an overlay and an underlay. This provides a clear
separation of responsibilities and simplifies deployment and operations by virtue of
policy changes only affecting the overlay. Underlay consists of all of the physical
devices such as switches, routers, wireless LAN controllers and glued together with a
layer 3 routing protocol. Cisco DNA center LAN automation uses IS-IS routed design.
IS-IS is protocol agnostic, can work with loopback interfaces (without requiring an
address on each L3 link), and supports an extensible TLV format for future use cases.

SDA fabric overlay is the logical or virtual topology and consists of three main
components, i.e.

Fabric data plane, VXLAN and Group Policy Option (GPO)


Fabric control plane, LISP performs the mapping and resolution of users and
devices associated with VXLAN VTEPs
Fabric policy plane, with Scalable Group Tags (SGT), business goals or
intent are translated into a network policy

SDA has the ability to instantiate logical network policy obviously depending on and
what’s supported by the network fabric. Those services include security, QoS, and
application visibility among others.

Cisco DNA Center acts as the central management plane for building and maintaining
SDA fabric. DNA Center provides two key functions, i.e. automation and assurance.

Technet24
||||||||||||||||||||
||||||||||||||||||||

You can define and manage SDA group-based policies using DNA Center automation. It
also integrates with Cisco ISE to provide host onboarding and policy enforcement.
Network assurance helps quantify the network availability along with a comprehensive
set of network analytics. DNA Center assurance collects a variety of telemetry, in the
form of SNMP, NetFlow and Syslog as well as using NETCONF and streaming
telemetry.

SDA solution supports three levels of APIs, namely

Device APIs, for access to configuration on individual devices


DNA Center APIs, for network-level automation and orchestration
ISE APIs, for contextual information about user and device access

Cisco SDA solution is supported on most of the Cisco switching product line including
Nexus 7000, and Catalyst 3650 series switches.

||||||||||||||||||||
||||||||||||||||||||

Virtualization Functions (NFVI, VNF, and L4/L1)

NFVI and VNFs

European Telecommunication Standards Institute (ETSI), along with ATT and DT, put
together Network functions virtualization (NFV) framework which defines standards for
compute, storage, and networking resources that form the basis for virtualized network
functions or VNFs. NFV Infrastructure (NFVI) is a key component of the ETSI NFV
architecture that lays out the hardware and software components on which virtual
network functions or VNFs are created. NFVI framework has mostly standard and some
proprietary interfaces which are like glue that brings the overall framework together.
However, there is no room to build a vendor lock-in thanks to software-defined nature
of VNFs.

Historically, software and proprietary hardware are tightly coupled in a network device
such as a router or a switch from Cisco. These physical devices need to be manually
inserted into the network which creates operational challenges and raises OPEX. Now,
VNF refers to the implementation of a network function say firewall or load balancer
where software is decoupled from the underlying hardware (mostly a commodity x86
server). This approach obviously leads to simplified operations and significant OPEX
reduction. Individual network functions are productized in the form of a VM.

VNF functions generally include OSI layer 4 to 7 services such as firewalls and load
balancers. NFV services are deployed on commercial off-the-shelf (COTS) hardware
platform, typically run on Intel x86-based hardware and standard switching hardware.

Technet24
||||||||||||||||||||
||||||||||||||||||||

VIM is to NFVI what VNFM is to VNFs. VNFM manages VNFs and is also responsible
for the Fault, Configuration, Accounting, Performance and Security (FCAPs) of VNFs. If
a VNF needs scaling up or down of resources, VNFM would help accomplish that.

NFV Orchestrator (or NFVO) performs lifecycle management of the network services. It
is responsible for NS lifecycle management; global resource management; validation
and authorization of network functions virtualization infrastructure (NFVI) resource
requests.

Cisco Virtual Topology Systems (or VTS) is an optional Cisco NFVI application that
uses OpenStack neutron driver. It is a standard-based and open overlay management
system. It uses policy-based approach for network provisioning. You can manage VTS
using the GUI it comes with or using REST APIs.

Cisco VTS provides the following key functions, i.e. fabric automation, network
programmability that is supported on all Nexus series switches.

In terms of architecture, Cisco VTS includes two primary components, i.e. policy and
control planes. Policy plane allows for a declarative policy model which captures the
intent and render the user into a specific device-level construct. The control plane
component includes the SDN control subsystem that helps program the data planes
including the Cisco Virtual Topology Forwarders (VTFs) running on top of Cisco UCS
servers.

Virtual Topology Forwarder (VTF)

||||||||||||||||||||
||||||||||||||||||||

VTF runs on each compute node in the data center and ensures connectivity for all tenant
VMs hosted on the physical server. VTF facilitates both intra and inter DC connectivity.

In terms of architecture, VTF has two main components, i.e. Cisco Vector Packet
Processing (or VPP) and VPFA (FIB agent running on VMM). VTF is deployed as a VM
or in a vhost mode if high performance software-based data plane is needed.

Cisco has yet another NFVI solution that’s known as Cisco NFI Solution or NFVIS.
NFVIS is a virtualization platform that integrates VM lifecycle management. It is based
on KVM hypervisor running on top of CentOS Linux. It is bundled with drivers to
support various hardware including Cisco UCS and NICs.

Technet24
||||||||||||||||||||
||||||||||||||||||||

NFVIS provides the following benefits, i.e.

It provides zero-touch deployment for branch sites including the VNFs that
may be deployed there.
It manages entire VNF lifecycle, i.e. you can create or delete VNFs etc.
It provides service chaining of VNFs
It is open and programmable for service orchestration. It supports both
REST and NETCONF APIs.

NFV Infrastructure Software is the main OS for the Cisco Enterprise Network Computer
System (ENCS). It is supported on Cisco UCS E and C series chassis as well as Cisco
ENCS computer system, i.e. ENCS5406, ENCS5408, and ENCS5412.

In addition to above, NFVIS also includes various open source components, i.e.

NFVIS
Linux distribution CentOS 7.x
Kernel 3.10.x
LibVirt 1.2.x
OVS 2.3.x
QEMU 1.5.x

||||||||||||||||||||
||||||||||||||||||||

Technet24
||||||||||||||||||||
||||||||||||||||||||

Automation and Orchestration Tools (CloudCenter, DNA-center, and


Kubernetes)
Cisco CloudCenter Manager and Orchestrator

CloudCenter (formerly CliQr) is a multi-cloud management platform that can facilitate


provisioning of infrastructure, applications and corresponding data for private and
public cloud environments.
CloudCenter solution supports a variety of scenarios in enterprise IT organizations, i.e.
application migration, DevOps automation across various cloud environments, and
dynamic capacity augmentation within or between clouds.
CloudCenter consists of two major components, known as CloudCenter Manager and
Orchestrator.
CloudCenter Manager allows users to model, deploy, and manage applications that are
located on on-premise data center or cloud, in addition to providing administrators
control over clouds, users, and governance policies. CloudCenter users and admins can
access the manager through a web browser, CLI or even REST APIs. Managers can be
linked to Orchestrators in a 1:1 or 1:n relationship allowing them to simultaneously
support thousands of applications
CloudCenter Orchestrator is present in every data center or cloud region. It helps
automate application deployment as well as computing, storage, and networking
infrastructure provisioning and configuration based on the end-user application
requirements. Orchestrator uses REST APIs to connect with CloudCenter Manager.
Each CloudCenter Manager supports up to 2 CloudCenter Orchestrators and 100
CloudCenter VMs.

Application profile is about the CPU, memory and storage needs of a given application.
Today, cloud native applications are the new normal. There is another related cloud
native application or service concept here that is known as microservices.

Microservices is a unique method of developing software systems that focuses on


building single-function modules with well-defined interfaces and operations. The
microservice architecture enables the continuous delivery and deployment of large and
often complex applications. It also helps an organization to evolve its technology stack
towards agile and one that fully leverages DevOps.

||||||||||||||||||||
||||||||||||||||||||

Cisco ONE Enterprise Cloud Suite offers an open and flexible approach to multi-cloud
management. It includes four modules consisting of infrastructure automation, cloud
management (i.e. CloudCenter Manager and Orchestrator), workload optimization, and
service management.

Cisco DNA Center

DNA Center is the controller and analytics platform at the core of Cisco’s intent-based
network. DNA Center can be used to express the “intent” for multiple use cases,
including features such as automation, fabric provisioning, policy-driven segmentation
and context via Analytics and Assurance within the enterprise network. The primary
goals for DNA center are to ensure faster deployment, quicker problem resolution and
safety and security through threat defense mechanism.

Technet24
||||||||||||||||||||
||||||||||||||||||||

Once you log into the DNA center, and on the home page, you are presented with four
main options or activities that you can perform.

Design
Policy
Provision
Assurance

Design option allows you to create structure of your network including the physical
topology, network settings and device type profiles that you can apply to everything in
your network.

Policy option allows, you to create policies and this is where you as an admin define
the “intent”. DNA center converts policy into network and device specific
configurations.

||||||||||||||||||||
||||||||||||||||||||

Provision is where actual configuration of devices takes place. This is where you also
add devices into DNA Center inventory.

Last but not least, Assurance is about actionable insights about the performance and
health of the network infrastructure, including applications and user endpoints. Insights
provided by assurance are actionable and predictive.

DNA Center also allows you to perform a global search, something that you can use to
serch devices, hosts, users and IP pools within your entire network.

Kubernetes

Kubernetes is an open source platform for orchestrating container-based workloads and


microservices. It facilitates declarative configuration as well as automation. Kubernetes
services, support, and tools are widely available, thanks to its large, rapidly growing
ecosystem. Google open sourced Kubernetes in 2014, something they have been using
internally for quite some time. It is important to understand that Kubernetes is not a
legacy all-inclusive PaaS system.

Kubernetes has three major features, i.e. it can be used as

a container platform
a microservices platform
a portable cloud platform

Legacy way to deploy applications is to install the applications on a host using the
operating-system package manager. This had the disadvantage of mixing the
applications’ executables, configuration, libraries, and lifecycles with each other and
the underlying host OS.

Technet24
||||||||||||||||||||
||||||||||||||||||||

Now, technically you could obviously repurpose virtual-machine images in an


immutable manner in order to achieve predictable rollouts and rollbacks, but VMs don’t
share the inherent benefits of containers in the areas of portability and faster startup
times. Immutable refers to replacing components as opposed to changing them,
enterprise IT services and software are generally updated (or changed) in an
incremental way making them mutable.

With containers, it is possible to deploy applications based on operating-system-level


virtualization rather than using a hypervisor or hardware virtualization. Containers are
isolated individually from each other as well as from the underlying host. They are
easier to build and totally portable across clouds and OSs as opposed to VMs.

Let’s now go over some of the key Kubernetes concepts.

Container is the smallest unit in the Kubernetes jargon. Well, the main purpose of
kubernetes is to manage and deploy containers. Please keep in mind that Kubernetes
management is not just limited to Docker containers.

Node is the host where containers run, much like a physical server that’s also known as
host where VMs reside. Pod is a management unit in the Kubernetes world. It is
comprised of one or more containers and has its own IP address and storage
namespaces. All containers running inside a pod share those networking and storage
resources. When a pod is deleted, it will go away forever. Pod is defined using a YAML
file.

<code>
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.2
</code>

Deployment is how you handle HA in Kubernetes. While a pod by itself is mortal, but
with “deployment”, Kubernetes can ensure that desired number of pods are always up

||||||||||||||||||||
||||||||||||||||||||

and running. Again, “deployment” is defined using a YAML file.

<code>
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.2
</code>

Kubernetes service, also known as micro-service, is an abstraction which defines a


logical set of pods and policy which dictates how to access them.

Kubernetes architecture also includes something known as label. This isn’t your MPLS
label. Here, label refers to a semantic tag which can be attached to Kubernetes objects
to mark them as part of a group. Labels are assigned as key/value pairs.

Kubernetes annotations are similar to labels, but they allow you to attach an arbitrary
key-value information to an object. Unlike labels, annotations are free form and can
contain less structured data, you can think them as a way of attaching rich meta-data to
an object.

Technet24
||||||||||||||||||||
||||||||||||||||||||

Now, let me walk you through a small Kubernetes hands-on lab. In this lab, I am using
“minikube” which is an easy way to run Kubernetes locally. Minikube runs a single-
node cluster inside a VM on your machine. You will see reference to “kubectl” which is
nothing but a CLI tool to deploy and manage applications on top of Kubernetes. You can
create, delete, and update resources inside your cluster using “kubectl”.

Anyhow, once kubernetes is installed, you can check the current version using
“minikube version”.

Now, we will start a Kubernetes cluster by using “minikube start” command.

||||||||||||||||||||
||||||||||||||||||||

Minikube started a VM and a Kubernetes cluster is now running within that VM. You
can use “kubectl version” to see both the version of the client as well as the server.

Now, let’s peek into our cluster and see what we’ve there. The URL below points to
Kubernetes dashboard.

Let’s now run “kubectl get nodes” to list our nodes, and it shows that we have one node
that is ready for application deployment.

Technet24
||||||||||||||||||||
||||||||||||||||||||

Let’s now deploy our first application on Kubernetes with “kubectl run” command.
Please note that “run” will help create a new “Deployment”.

You can view your “deployments” using “kubectl get deployments” command. You can
notice that it is showing the application that we just deployed.

Now, in order to peek inside the application, we need to create a proxy. Pods that are
running inside Kubernetes are run on a private network which is not visible to anyone
outside the pods. “kubectl” is interacting with the Kubernetes environment using an API,
hence we need a proxy which forward communication into the private network.

Now that we’ve a proxy running, let’s pull Kubernetes version using “curl
http://localhost:8001/version” command.

||||||||||||||||||||
||||||||||||||||||||

Now, let’s create a new service and “expose” it to outside world traffic using “kubectl
expose” command. You can see that service “kubernetes-bootcamp” is exposed.

Technet24
||||||||||||||||||||
||||||||||||||||||||

You can also find the port information for exposed service using “kubectl describe”
command.

||||||||||||||||||||
||||||||||||||||||||

Now, we assign NODE_PORT the actual Node port and then query our service
“kubernetes-bootcamp” from outside the cluster.

Now, if you issue “kubectl describe deployment” command, you can see the label
assigned to our service, which is “run=kubernetes-bootcamp”.

Once we know our service label, we can get our service information using label “-l”
option.

You can also apply a new label to a service using “kubectl label pod $POD_NAME
app=v1” command, notice that POD_NAME is an environment variable that we created
earlier.

Once our new label is attached, we can query list of pods using the new label using
“kubectl get pods -l app=v1”.

Technet24
||||||||||||||||||||
||||||||||||||||||||

Now, let’s try to delete our service using “kubectl delete service”.

You can also curl on the NODE_PORT to double confirm that service is indeed gone,
and route is not exposed anymore.

While the service is gone, our app is still functional however only accessible from
within the cluster, i.e. no longer exposed.

Now, let’s try to scale an environment for the purposes of load balancing. Our
deployment shows one pod.

Now, let’s create 4 more replicas and scale the environment using “kubectl scale”

||||||||||||||||||||
||||||||||||||||||||

command. Here you can see that we have successfully scaled to 4 replicas and all of
them are running across 4 pods.

Finally, you can also use “kubectl describe deployments/kubernetes-bootcamp” to view


replicas. Please note some of the output below is truncated for the sake of brevity.

Now, let’s verify if the service is load balancing traffic. Once you’ve exposed the IP

Technet24
||||||||||||||||||||
||||||||||||||||||||

and port, you can execute “curl $(minikube ip):$NODE_PORT to see if we’re sitting a
different pod each time.

Now, let’s scale down our service to 2 replicas. Notice the “terminating” in the output
below, that confirms that 2 pods were terminated.

||||||||||||||||||||
||||||||||||||||||||

You can also update the image for your app using rolling upgrade with “kubectl set
image” command.

You can verify the use of new images using “kubectl get pods” command.

Notice the app version changed to “v2” as described by us when setting the new image.

Technet24
||||||||||||||||||||
||||||||||||||||||||

You can also verify it using the “kubectl rollout status” command. You can also use
“kubectl undo” to reverse or undo the roll out.

||||||||||||||||||||
||||||||||||||||||||

Exam Essentials

The cloud offers several unique benefits to developers and service users as
opposed to using on-premise
Scalability: you can scale your application up or down easily
Availability: single VM or server failure doesn’t result in service
failures
Collaboration: developers can collaborate easily with cloud tools
such as Slack
Portability: applications can be moved around
A hybrid cloud combines the benefits of public and private clouds by
allowing data and applications to be shared between them
Infrastructure as a service (IaaS) is a cloud service model where compute,
storage and networking resources and capabilities are owned and hosted by
a service provider and offered to customers on-demand. In this cloud
service model, cloud provider only manages physical servers, storage,
networking devices and virtualization layer.
Platform as a Service (PaaS) allow developers to build, run and manage
applications in the cloud. In this cloud service model, customer only
manages data and applications.
Software as a service (or SaaS) is a way of delivering centrally hosted
applications over the Internet, as a service as opposed to locally installed
CloudCenter allows you deploy and manage applications across multiple
clouds and data center environments. Each CloudCenter Manager supports
up to 2 CloudCenter Orchestrators and 100 CloudCenter VMs.
Cisco ONE Enterprise Cloud Suite offers an open and flexible approach to
multi-cloud management. The overall solution comprises of four modules.
Infrastructure Automation: It includes Cisco UCS Director, UCS
Central, and Cisco Integrated Management Controller (IMC)/
Cloud Management: It includes CloudCenter Manager,
CloudCenter Orchestrators, and CloudCenter VMs.
Workload Optimization: It includes Cisco Workload Optimization
Manager.
Service Management: It includes Cisco Prime Service Catalog
and Cisco Process Orchestrator.
A container image is a lightweight, stand-alone, executable package of a
piece of software that includes everything needed to run it: code, runtime,
system tools, system libraries, settings

Technet24
||||||||||||||||||||
||||||||||||||||||||

Docker is an open platform for developers and sysadmins to build, ship, and
run distributed applications, whether on laptops, data center VMs, or the
cloud.
Docker can build images automatically by reading the instructions from a
Dockerfile. A Dockerfile is a text file that contains all the commands a user
could call on the command line to assemble an image
In Docker, everything is based on Images. An image is a combination of a
file system and parameters. A container is a runtime instance of an image.
VIM is to NFVI what VNFM is to VNFs. VNFM manages VNFs and is also
responsible for the Fault, Configuration, Accounting, Performance and
Security (FCAPs) of VNFs. If a VNF needs scaling up or down of resources,
VNFM would help accomplish that.
NFV Orchestrator (or NFVO) performs lifecycle management of the network
services. It is responsible for NS lifecycle management; global resource
management; validation and authorization of network functions virtualization
infrastructure (NFVI) resource requests
ETSI is the standard body that addresses the development of NFVI and
NFVO.
NFV is the overall concept of network function virtualization whereas
OpenStack and KVM are the enablers providing Cloud OS and hypervisor
functionalities respectively
NFV services are deployed on commercial off-the-shelf (COTS) hardware
platform, typically run on Intel X86-based hardware and standard switching
hardware.
Intel DPDK implements a run to completion model for packet processing,
where all resources must be allocated prior to calling Data Plane
applications, running as execution units on logical processing cores
With LXCs and KVM, the TUN/TAP subsystem creates a virtual ethernet
interface attached to a process.

Further Reading

http://goo.gl/GuF1So
http://goo.gl/ujoI4T
https://goo.gl/r2XGH2
http://goo.gl/TsPxUT
http://goo.gl/WtpKGE

||||||||||||||||||||
||||||||||||||||||||

Technet24
||||||||||||||||||||
||||||||||||||||||||

Part II: Network Programmability

This chapter covers the following exam topics from Cisco's official Evolving
Technologies (v1.1) written exam curriculum.

Chapter 3: Describe Architectural and Operational Considerations for a Programmable


Network
Data models and structures (YANG, JSON and XML)
Device programmability (gRPC, NETCONF and RESTCONF)
Controller based network design (policy driven configuration and
northbound/ southbound APIs)
Configuration management tools (agent and agentless) and version
control systems (Git and SVN)

||||||||||||||||||||
||||||||||||||||||||

Part II: Network Programmability

Technet24
||||||||||||||||||||
||||||||||||||||||||

Chapter 3: Describe Architectural and Operational


Considerations for a Programmable Network
Data Models and Structures (YANG, JSON and XML)

SNMP has been around for over 30 years. Over this time, it has been the de-facto way
to monitor networks. It worked great when networks were small and polling a device
every 15-30 minutes met operational requirements. SNMP MIBs are a type of data
model defining a collection of information that is organized in a hierarchical format that
is used along with SNMP. Anyhow, SNMP did work great for monitoring devices every
few minutes, but it never caught on for configuration management purposes due to
custom or proprietary MIBs.

In addition to SNMP, there has always been the network command line interface or CLI.
Access to the CLI happens via console, Telnet, or SSH, and it has been the de-facto way
of managing configuration of networking devices for the past 20+ years. If you tally up
the way devices have been managed for 20 years, you can see that there has been no
good way to handle machine to machine mechanism i.e. using software to configure
network devices.

Expect and TCL scripting and custom parsers and screen scrapers were the best the
industry had to offer over that time, you can call it poor man’s way to automation when
there was no better way. It is now unacceptable as the rate of change continues to
increase, there are more devices, and higher demands being placed on the network.
Now, if you put it all together along with where we are with regard to business
requirement today, you can summarize following to be the desired requirements for
today’s configuration management.

Easier to use API-based management interfaces that can be consumed with


open source tools (REST, RESTCONF, NETCONF, gRPC)
Decouple configuration from operational data
Both human and machine friendly for consumption
Support variety of transport protocols (HTTP/S, SSL, SSH)
Support variety of data encoding formats (JSON and XML)

It is important to understand the difference between configuration and operational data.


Configuration data tells the device (e.g. a router) what to do, so if you do a “show run”,
you’re looking at configuration data. Now, operational data tells us how a device is
operating, so if you do a “show interface g1/1/0”, the output tells you operational state

||||||||||||||||||||
||||||||||||||||||||

of the interface as an example. You can read and write to/from configuration data;
however, you can only read operational data.

This brings us to model driven programmatic network management interface.

YANG

Yet Another Next Generation (YANG) modules are for NETCONF (or RESTCONF) to
what MIBs are for SNMP however more readable than MIBs. YANG is a full-blown
language. YANG is not used to express process or for actual transport. YANG data
model describes how data is represented and accessed. In YANG, data models are
represented by definition hierarchies.

YANG modules are available from standard organizations such as the IETF, open
source ecosystem, such as OpenDaylight, or vendor- specific modules from likes of
Cisco or Juniper.
All YANG modules are publicly available for free. You can see the largest collection of
models on GitHub at: https://github.com/YangModels/yang. This repository includes
models from the IEEE, IETF and respective vendors.

Let’s now go over the steps to configure a device for YANG and then access it using

Technet24
||||||||||||||||||||
||||||||||||||||||||

YANG Explorer.

1. Configure “netconf-yang” on your switch or a router and set up a local user


id and password that you can use to SSH into the box. You will also need
“aaa authorization exec default local” to edit configuration.

2. Verify that NETCONF/YANG are running on the box.

Switch3K# show platform software yang-management process

confd : Running
nesd : Running
syncfd : Running
ncsshd : Running
dmiauthd : Running
vtyserverutild : Running
opdatamgrd : Running
ngnix : Running

3. Make sure that you have a laptop where you can install YANG explorer and
that it is accessible to the switch configured with NETCONF/YANG. Please
note that NETCONF uses TCP 830.
4. Download and install YANG explorer on your laptop, it supported on both
macOS and Linux. You can download using the following link:
https://github.com/CiscoDevNet/yang-explorer. You can use YANG explorer
to upload YANG data models, build and execute NETCONF RPCs, and
browse data model trees and inspect YANG properties.
5. Once installed, you can fire up YANG explorer by going to
https://localhost:8088/static/YangExplorer.html
6. You will need to enter switch IP address as well as login credentials before
you can retrieve Capabilities.

||||||||||||||||||||
||||||||||||||||||||

Loading YANG data models.

Subscribing to NETCONF notifications.

Technet24
||||||||||||||||||||
||||||||||||||||||||

Sending a custom RPC via NETCONF.

You can perform data retrieval, configuration (e.g. shut or unshut an interface) etc. Last
but not least, you can also download pyang tool (https://github.com/mbj4668/pyang)
which is a validator, converter and code generator written in python. You can even use
it to convert JSON encoding format into XML or vice versa.

YAML

YAML Ain’t Markup Language (YAML) is a human friendly data serialization language
that can be used with just about any programming language. You should be able to find
libraries for C/C++, python, ruby, Java and Golang just as an example.

YAML is much simpler and easier to write than XML or even JSON. Ansible playbooks
are expressed in YAML. Every YAML file starts with a list, where each item is written
as key/value pair. All YAML files start with “---” and end with “…”. All members of a
list are written on their own lines beginning at the same indentation level and starting
with “-“ (dash and a space).

---
# a list of vegetables
veggies:
- carrots
- turnip
- cucumber
- onions

||||||||||||||||||||
||||||||||||||||||||

---
router:
bgp:
- id: 100
bgp:
router_id: 1.1.1.1
fast_external_fallover: null
update_delay: 15
neighbor:
- id: 2.2.2.2
remote_as: 200
- id: 3.3.3.3
remote_as: 300
redistribute:
connected: {}

If you want to write scripts for network programmability, then learning YAML is a must.
YAML lists can be easily converted into python dictionaries.

JSON

There are two main data encoding formats that are commonly used in APIs. They are
XML and JSON (pronounced as Jay-sun). JavaScript Object Notation (or JSON) is both
human friendly and machine-readable format and sends data in name-value pairs. JSON
is best known for the curly brace syntax. JSON is popular, because it is easier to read
and natively maps to Python dictionary data structure.
JSON Example

{
"persons": [
{
"name": "Jeff Bezos",
"gender": "male"
},

Technet24
||||||||||||||||||||
||||||||||||||||||||

{
"name": "Elon Musk",
"gender": "male"
},
{
"name": "Jessica Alba",
"gender": "female"
}
]
}
Now, let’s convert above JSON into YAML.
{
"persons": [
{
"name": "Jeff Bezos",
"gender": "male"
},
{
"name": "Elon Musk",
"gender": "male"
},
{
"name": "Jessica Alba",
"gender": "female"
}
]
}
XML

||||||||||||||||||||
||||||||||||||||||||

Extensible Markup Language (or XML) is also human readable but not as friendly as
JSON. Visually, XML formatting is similar to HTML. XML namespaces are fairly
common when using XML APIs on network devices.

Each of those formats provides a structured way using data formatting to send data
between two systems. As you can see, it is in complete contrast to using CLI commands
with Telnet or SSH, in which data is sent as raw text, such as, strings over the wire.

XML Example

<persons>
<person>
<name>Jeff Bezos</name>
<gender>male</gender>
</person>
<person>
<name>Elon Musk</name>
<gender>male</gender>
</person>
<person>
<name>Jessica Alba</name>
<gender>female</gender>
</person>
</persons>

Device Programmability (gRPC, NETCONF and RESTCONF)

Application Programming Interface (or API) is a standard based way to interact with a
software application or an OS such as Cisco IOS or NX-OS. API client connects to API
server thus providing a programmatic way to configure or retrieve data from the API
server (running within the application or the OS). Having a programmatic interface into
various devices makes automation possible.

Representational Transfer (or REST) API is a standard API that uses HTTP methods
such as GET, POST, PUT and DELETE using a Universal Resource Identifier (or URI)
format. Both HTTP and REST are stateless which means state is not maintained on the
API server.

Technet24
||||||||||||||||||||
||||||||||||||||||||

gRPC

gRPC is a modern API originally developed by Google but eventually contributed into
open source much like what happened with Kubernetes. Cisco includes support for
gRPC on IOS-XR devices running IOS XR v6.1 or later.

gRPC’s secret sauce lies in the way the serialization is handled. It is based on Protocol
Buffers also from Google, an open source mechanism for serializing structured data,
which is both language and platform neutral. Please note that gpb is the compiler for
protocol buffers.
gRPC much like RESTCONF, is a functional subset of NETCONF and uses HTTP/2
(HTTP protocol version 2). However, gRPC is more advanced and improved in the
areas of security and support for bi-directional streaming. When compared to
REST/JSON combination, gRPC offers better performance and security.
gRPC promotes the use of SSL/TLS to authenticate the server and to encrypt all the data
exchanged between the client and the server. Last but not least, please note that gRPC is
not a standard.

Let’s now go through an example of how to program an IOS XR device using the gRPC
framework. In this example, we will use a gRPC library for IOS XR written in Go
language.

First step is to configure the router for gRPC.

grpc
port 57344
tls
!
address-family ipv4
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.0.2.1 255.255.255.0
no shut
!

Once that’s done, you need to copy the content of /misc/config/grpc/ems.pem file. You’d
also need to install Go using apt-get command if you’re on Ubuntu or Debian (likewise

||||||||||||||||||||
||||||||||||||||||||

on other distros). Be sure to create and set up environment variables for workspace
directory. You can verify Go using “go version” command.

Now, let’s also pull the gRPC library for Cisco IOS XR, after that, you’re ready to go.

go get github.com/nleiva/xrgrpc

Now, we will use GetConfig RPC to request the config of the IOS XR device for the
YANG paths as per yangpaths.json.

{
"Cisco-IOS-XR-ifmgr-cfg:interface-configurations": [null],
"Cisco-IOS-XR-telemetry-model-driven-cfg:telemetry-model-driven": [null],
"Cisco-IOS-XR-ipv4-bgp-cfg:bgp": [null],
"Cisco-IOS-XR-clns-isis-cfg:isis": [null]
}

Now, you need to copy the PEM file (ems.pem) into a folder along with your JSON file.
Once that’s done, you can issue “go build” to kick off the build. Once your binary is
ready, you need to launch it from the shell.

./myapp

You will see the following result (IOS XR interface config) as a result of the execution.

Config from 10.0.2.1:57344


{
"data": {
"Cisco-IOS-XR-ifmgr-cfg:interface-configurations": {
"interface-configuration": [
{
"active": "act",
"interface-name": "MgmtEth0/RP0/CPU0/0",
"Cisco-IOS-XR-ipv4-io-cfg:ipv4-network": {
"addresses": {
"dhcp": [
null
]
}
}

Technet24
||||||||||||||||||||
||||||||||||||||||||

},
{
"active": "act",
"interface-name": "GigabitEthernet0/0/0/0",
"Cisco-IOS-XR-ipv4-io-cfg:ipv4-network": {
"addresses": {
"primary": {
"address": "192.0.2.1",
"netmask": "255.255.255.0"
}
}
}
}
]
}
}
}

NETCONF

NETCONF is a network management protocol that is designed specifically for


transactional-based network management and can be considered as a successor to
SNMP.

NETCONF makes a distinction between configuration and state data. It uses three
different data stores, i.e. candidate, running and startup configuration. It uses RPC for
messages and SSH (TCP 830) for secure transport.

NETCONF is session oriented and stateful unlike REST and RESTCONF which are
stateless. NETCONF protocol contains four layers.

Protocol (SSH as transport)


Messages (XML encoding)
Operations (each device and platforms support a given number of
operations)

NETCONF Operations layer defines a set of base protocol operations invoked as RPC
methods with XML-encoded parameters. As per the RFC, Messages layer provides a
simple, transport-independent framing mechanism for encoding RPCs and notifications.

||||||||||||||||||||
||||||||||||||||||||

The Secure Transport layer provides a communication path between the client and
server. NETCONF can be layered over any transport protocol that provides a set of
basic requirements. The Content layer is outside the scope of RFC.

NETCONF can carry out four main operations, i.e.

<get>, similar to “show” CLI, it retrieves running configuration and device


state information
<get-config>, similar to “show run” CLI, it retrieves all or part of a
specified configuration
<edit-config>, similar to “config terminal” commands, it loads all or part of
a configuration to the specified configuration datastore
<delete-config>, similar to “no” or delete config, it simply deletes a
configuration datastore

NETCONF contains three datastores.

Running, running-config (it is a mandatory datastore)


Start-up, startup-config
Candidate, work place for creating and manipulating configuration data

NETCONF Example

<copy-config>
<source>
<url>file://my-candidate-config.cfg</url>
</source>
<target>
<candidate/>

</target>
</copy-config>

Technet24
||||||||||||||||||||
||||||||||||||||||||

RESTCONF

RESTCONF is nothing but an addition of REST API, which is very popular, to


NETCONF. YANG models are used as when you use RESTCONF, and thus the URLs,
HTTP verbs, and Request bodies are automatically derived from the associated YANG
model.

Unlike NETCONF, RESTCONF supports both XML and JSON encoding formats. It is
worth noting that RESTCONF is an IETF standard that not only adapts YANG
specification to a RESTful API interface but can also function as a southbound API
when network devices support RESTCONF interfaces directly and can expose them to
an Orchestrator upstream.

RESTCONF protocol, much like REST API, operations include GET, POST, PUT,
PATCH and DELETE.

RESTCONF NETCONF
GET <get>, <get-config>
POST <edit-config>, create
PUT <edit-config>, create or replace
PATCH <edit-config>, update
DELETE <delete-config>

Using RESTCONF to Retrieve Full Running Configuration

GET http://csr1kv/restconf/api/config/native

Using RESTCONF to Retrieve Interface Specific Attributes


GET http://csr1kv/restconf/api/config/native/interface

Controller Based Network Design (Policy Driven Configuration and

||||||||||||||||||||
||||||||||||||||||||

Northbound/Southbound APIs)
SDN is about network programmability on the basis of disaggregation. As per Cisco,
there could be at least four different types of SDN models out there.
Distributed control plane model, which simply outlines how things were
before SDN came along. Before SDN, each router or switch relies on its
own control plane information to make routing and forwarding decisions.
Augmented control plane model, where centralized controller can apply
policy by injecting IP prefixes, PBR or ACLs objects. This model represents
an incremental change from the distributed control plane model or shall we
call it pre-SDN status quo. PfR controller is an example of augmented
control plane model.
Hybrid control plane model, which is an extension of augmented model
except that controller is now able to control the entire network as opposed
to just the “parts”. Cisco APIC is an example of such model, in which
failure of the centralized controller causes end devices to use their own
control plane intelligence.
Centralized control plane model is what most of relate with the SDN, i.e. a
single controller controls the entire topology and directly manipulates the
forwarding decision making or data plane.

Policy-driven Configuration

In a policy-driven configuration mode, policy describes the desired network state in a


declarative way, abstracted from the actions that lead to that state. This is in sharp
contrast to OpenFlow based SDN model, where controller directly controls forwarding
decision-making by way of flow entries in each device within the given topology.

Cisco ACI fabric is an example of a system that uses policy driven configuration and it
dynamically translates the application policies into actions that are comprehensive to
both, the APIC controller and the fabric. Cisco ACI managed objects are considered
part of its “logical model” whereas the actual fabric where the policy is implemented is
known as “concrete model”.

Technet24
||||||||||||||||||||
||||||||||||||||||||

Northbound and Southbound APIs

Session Border Controller (SBC) and Wireless LAN (WLAN) controller are examples
of centralized control and management that predate the modern SDN movement.

Southbound APIs facilitate efficient control over the network infrastructure and enable
the SDN controller to dynamically make changes to device’s data plane. SDN controller
is the central process that communicates with network devices using southbound APIs.
You can think of SDN controller conceptually consisting of control and management
planes in an SDN network.

OpenFlow was the first and probably most well-known southbound interface. With
OpenFlow protocol, entries can be added and removed to the internal flow-table of
switches and potentially routers to make the network more responsive to real-time
traffic demands. Besides OpenFlow, Cisco OpFlex is also a well-known southbound
API. It is worth pointing out that Cisco APIC doesn't manipulate the data path directly,
Instead, it centralizes the policy definition automating the entire process of installing
and ensuring the policy.

More established networking protocols have also found their ways to run in an SDN
environment as southbound protocols, such as BGP-LS and PCEP. BGP-LS is a
southbound protocol that can be used to export IGP information from the network to the
SDN controller. BGP-LS is an extension to BGP for distributing the network's link-state
(LS) topology model to external entities.

OpenDaylight (ODL) is an open source and modular SDN controller for customizing

||||||||||||||||||||
||||||||||||||||||||

and automating networks of any size and scale. Cisco Open SDN controller supports
OVSDB, OpenFlow, BGP-LS, NETCONF and PCEP as southbound protocols. It
represents hardened, validated, and supported OpenDaylight distribution. OpenContrail
and ONOS are also examples of SDN controllers, geared more for carrier-grade
environments.

OpFlex was designed to augment rather than replace tools (such as OVSDB) by
focusing on additional requirements of the network and policies that must span multiple
network devices. It includes a native mechanism for identity resolution used to define
declarative policies between two different network endpoints. It is an open and
extensible policy protocol for transferring abstract policy in XML or JSON between a
network policy controller such as the Cisco APIC and any device, including hypervisor
switches, physical switches, and Layer 4 through 7 network services.

Northbound APIs are perhaps the most critical APIs in the SDN environment since the
value of SDN is also tied to the innovative applications it can potentially support and
enable. Northbound APIs utilize REST APIs.

The Cisco Virtual Topology System (VTS) is an open, standards-based overlay


management and provisioning system for data center networks. It automates fabric
provisioning for both physical and virtual workloads.

The Virtual Topology System extends a robust set of SDN capabilities to the entire
Cisco Nexus portfolio by bringing automation and programmability to the Cisco Nexus
2000 Series Fabric Extenders and Cisco Nexus 3000, 5000, 7000, and 9000 series
switches as discussed earlier.

Configuration Management Tools (Agent and Agentless) and Version

Technet24
||||||||||||||||||||
||||||||||||||||||||

Control Systems (Git and SVN)

Configuration Management Tools (Agent and Agentless)

Configuration management is about automating the provisioning and deployment of


applications and infrastructure. It leverages some of the following software
development practices for deployments.

Version control
Design patterns
Testing

Configuration management tools include Puppet, Chef and Ansible and they are well
known in the DevOps circles. These tools enable you to automate applications,
infrastructure, and networks to a high degree without the need to do any manual
programming.
Puppet is written in Ruby and refers to its automation instruction set as Puppet
manifests. The major point to note here is that Puppet is agent-based. Agent- based
means a software agent needs to be installed on all devices you want to manage with
Puppet. “Devices” here refers to servers, routers, switches, firewalls, and the like. It is
often not possible to load an agent on many networking devices. Hence, this requirement
limits the number of devices that can be used with Puppet out of the box. Agent
requirement raises the barriers to deployment for Puppet as far as networking is
concerned. Furthermore, with some investment and cultural change, DevOps virtuous
cycle brings with it the benefits of improved scalability, reliability, maintainability, and
faster release rollouts with higher quality.

Chef, another popular configuration management tool, follows much of the same model
as Puppet. Chef is written in Ruby and uses a declarative model, is also agent-based.
Chef refers to its automation instruction as recipes and when they are grouped, are
known as cookbooks.

||||||||||||||||||||
||||||||||||||||||||

The two notable differences between Puppet, Chef, and Ansible are that Ansible is
written in Python and that it is natively agentless. Being agentless significantly lowers
the barrier to deployment from an automation perspective.

Ansible can integrate and automate any device using any API. For example, integrations
can use REST APIs, NETCONF, SSH, or even SNMP, if desired. Ansible sets of tasks
(instructions) are known as playbooks. Each playbook is made up of one or more plays,
where each play consists of individual tasks.

Chef Puppet Ansible


Who Chef Labs Puppet Labs Red Hat
owns it
Agent Required Required Not Required
Language Ruby Ruby Python
written
in
Tasks are recipes manifests plays
known as
Group of cookbooks modules playbooks
tasks
known as
Config Custom Custom YAML
Language

Technet24
||||||||||||||||||||
||||||||||||||||||||

Ease of Steep Steep learning curve Easier


Use learning with DSL/Ruby
curve
Pricing Free (Chef Free (Open Source) Free (CLI), unlimited nodes
Basics), up to 10 nodes,
$72/node $120/node Free (Ansible Tower) up to
afterwards afterwards 10 nodes, paid afterwards
with or without support

When using the configuration management tools, from a RESTful service standpoint, for
an operation (or service call) to be idempotent, clients can make that same call
repeatedly while producing the same result.
Version Control Systems (Git and SVN)

Version control systems enable efficient collaboration for developer contributing to a


software project. Imaging yourself working as a developer in a team setting, without
version control systems, you’re probably working with shared folders containing the
whole project. In a situation like this, multiple people on your team may end up working
on the same file at the same time, potentially causing many unpredictable issues.

The first Version Control system was developed around the 1970s. Since then, many
VCSs have been developed, and today there are many available possibilities for those
organizations who want to use Version Control. Git was originally built to support the
Linux Kernel development by Linus Torvalds.
Apache SubVersioN (SVN) was created as an alternative to CVS. SVN uses atomic
operations, meaning that either all changes that are made to the source code are applied
or none are applied. No partial changes are allowed, avoiding many potential issues. A
drawback of SVN is its slower speed of due to its centralized nature.
Git is a distributed version control software that keeps track of every modification to
the code. If a mistake is made, developers can look back and compare earlier versions
of code to help fix the mistake minimizing disruption to all team members.

Version control protects source code from any kind of errors that may have serious
consequences if not handled properly. Git may be a little daunting for new users to learn
with all the jargon and learning curve around commits but is powerful once you
understand it.

||||||||||||||||||||
||||||||||||||||||||

Git Architecture is composed of several different components: Remote Repository,


Local Repository, Staging Area, and Working Directory.
Remote Repository: A remote repository is where the files of the project reside, and it
is also where all other local copies are pulled from. It can be stored on an internal
private server or hosted on a public repository such as GitHub or BitBucket.
Local Repository: A local repository is where snapshots, or commits, are stored on
each individual person's local machine.
Staging Area: The Staging Area is where all the changes you actually want to perform
are placed. You, as a project member, decide which files Git should track. For example,
you can decide to add and commit files to fully become part of your local repository by
moving them to the staging area first, without including all files in your project.
Working Directory: A Working Directory is a directory that is controlled by git. Git will
track differences between your working directory and local repository, and between
your local repository and the remote repository.

Last but not least, let’s compare Git and SVN side by side.

Git SVN

Technet24
||||||||||||||||||||
||||||||||||||||||||

Architecture Distributed Centralized


Checkout entity Entire repo Sub-tree or branches
Staging area Yes No
Scale Extreme Moderate
Merge operations Straightforward Complex
Support for binary files Complex Straightforward
Speed Faster Slower

Now, let’s say we want to perform a small configuration change (say you want to change
SNMP RW strings or add a static route) using DevOps pipeline using the Git, Ansible,
and a build server known as Drone.

There are four major steps that you’d need to perform to accomplish this.

Creating Configuration Change


Building New Configuration
Testing New Configuration
Deploying New Configuration

Now, let me break these steps down for you.

Creating Configuration Change

During this stage, you are creating a configuration change. Now, in order to accomplish
this task, you will utilize a Software Control Management (or SCM) tool such as
GitHub or Gogs or Gitea or another similar tool of your choice.

For the purpose of this discussion, let’s say you’re using Gitea which is a self-hosted
version of Git service available free of cost. Gogs and Gitea are Open Source, single-
binary Go implementations of a Github-like git repository hosting system which you can
use privately or in a team setting. Both are light on system requirements.

Building New Configuration

||||||||||||||||||||
||||||||||||||||||||

There are two set of tools that are utilized during this stage. You have a build server that
runs through your Continuous Integration and Continuous Delivery (CICD) pipeline as
defined in the pipeline file i.e. .drone.yml.

There are many open source options for build and integration tooling, you can use Drone
or Jenkins or even Travis CI which is now free for open source and private projects.
However, Drone is a popular continuous integration and delivery platform built in Go. It
integrates with many version control services such as GitHub, GitLab, and obviously
Gitea and Gogs.

Drone agent watches for code changes and will automatically build and test changes as
soon as they are committed. Drone is primarily distributed as a Docker image, so you
will need to use Docker Compose to manage the CI server containers by creating the
“docker-compose.yml” file. In order to monitor code changes to trigger build and test
stages, Drone will need access to your source code repository inside Gitea or Gogs.
The Drone Docker image is a unified container that can be run in a few different ways.

Now, it is recommended to run one container that operates as the Drone server, which
coordinates repository access, hosts the web UI, and serves the API. In addition to that,
you can run another container as a Drone agent with pretty much the same settings,
which is responsible for building and testing software from the configured repositories.
The “drone-server” service starts the main Drone server container listening on default
port 8000 and likewise the “drone-agent” service uses the same image but started with
the “agent” command.

You will also need to set up server and agent environments using the respective .env
files as well as Systemd unit using a service file before you can fire up Drone. Both
Gitea and Gogs don’t support OAUTH2 so you will be prompted for user id and
password each time you kick off CICD pipeline, little bit annoying but not too bad.

You can also additionally configure nginx or apache as reverse proxy server to have
Drone send request through the proxy server and use SSL to secure communication
between Drone and your version control system.

Testing New Configuration

Broadly speaking, there are three types of tests involved during the CICD pipeline
execution, i.e. Unit, Integration and Production testing. Unit testing is simply done using
a single node which can be a router, switch or a firewall, whereas integration and

Technet24
||||||||||||||||||||
||||||||||||||||||||

production testing include a more realistic simulation network topology with multiple
nodes that closely mimic the real network.
In order to create test networks, you can either use Cisco VIRL or GNS3. Cisco VIRL
integration with Drone is simple as Cisco provides a plugin that you can tap into.

Deploying New Configuration

There are multiple ways to deploy your configuration, however the mostly used and
preferred tool is Ansible. Ansible consists of YAML data files as well as Jinja template
which contains variables that can be replaced with your YAML data file.

Ansible playbooks can declare configurations and launch tasks synchronously or


asynchronously. For each “play” in a playbook, you get to choose which devices in your
infrastructure to target and what remote user to complete the steps (or tasks) as.

Now, in order to use GNS3 with Drone, you can simply integrate GNS3 using the GNS3
server RESTful APIs directly into Drone CICD .drone.yml pipeline file along with the
project information to start and stop your simulated network topologies. You can use
Ansible playbooks to deploy your configurations into simulated networks.

Now, let’s put our Ansible, YAML and CICD knowledge to use and commit a real-life
IOS configuration change. In this example, I will actually modify SNMP RW strings on
my router, check in my changes and kick off my CICD pipeline. CICD will run unit and
integration testing before my changes can be committed into master branch and new IOS
configuration is allowed into production.

I am using Gitea within a Docker container that’s running inside my VirtualBox VM


which is running on my Ubuntu Linux distro. You can run Git on just about any platform
where Go would provide you with an independent binary which obviously includes
Linux, Windows and macOS/OSX.

Installing Gitea inside a docker container is pretty straightforward. After starting the
Docker setup via docker-compose Gitea should be available using your browser to
finalize the installation. You can connect to it using http://localhost:3000 and follow the
installation wizard. If you are coming from Gogs, you can refer to details here. You can
do a ls docker container to get the details of your installation. It should look similar to
what I have below on my machine.

||||||||||||||||||||
||||||||||||||||||||

When you log in, you will come to the following Gitea dashboard.

As you can notice, Gitea has a dashboard and separate links for issues, pull requests
and explore. Dashboard features a summary of your config/code integration activity. In
my case, I have a dev_branch where I make all my changes, then my Drone server
facilitates the testing using dev_branch, followed by testing using a realistic topology
and if everything finishes successfully, then merge dev-branch into master before
pushing that out to production network.

Let’s now go through an example of the integration part of that NetDevOps pipeline. The

Technet24
||||||||||||||||||||
||||||||||||||||||||

handoff between Gitea (CI) and Drone (CI/CD) happens when I commit my config
change into dev-branch. As we previously discussed, since Gitea doesn’t support
OAUTH2 for a seamless handover between CI and CD stages per se, I have to manually
enter my user password each time a commit is permitted to proceed from Gitea to
Drone.

CI benefits NetDevOps the most because it allows for config-as-code produced to be


automatically tested and continuously “integrated” with other NetDevOps members’
code, and with the existing config or codebase. The NetDevOps team benefits from
receiving continuous and immediate feedback regarding their config changes and
integration errors. As a member addresses these errors, automated testing tools such as
Drone (along with GNS3 or Cisco VIRL) in this stage will report if the errors were
successfully fixed and when the config change is accepted. This continuous feedback
loop dramatically increases a NetDevOps member’s productivity for making frequent
network changes while decreasing the likelihood of a network downtime.

Unless a network change is all about housekeeping, Continuous Delivery benefits the
business itself who are supposed to benefit from the resulting network changes because
as soon as config is successfully accepted in the CI stage and a can be tested, it is
deployed to given networking devices. Optionally, business groups can verify that
changes meet their expectations and provide feedback to NetDevOps team who then
address the feedback in this stage.

Anyhow, now let’s go back to making our first network change. In my example, I will be
modifying read and write SNMP community strings to showcase my NetDevOps
Gitea/Drone CICD pipeline.

I manually edited my all.yml file that contains the global variables used in my Ansible

||||||||||||||||||||
||||||||||||||||||||

playbooks. I edited the file and modified the SNMP community string values to
NewSecureReadJuly4th and 4NewSecureWriteJuly4th. This was done prior to issuing
git add and commit. git add adds your modified files to the queue to be committed later
whereas git commit commits the files that have been added and creates a new revision
with a log. If you do not add any files, git will not commit anything. You can combine
both actions with “git commit -a”.

Now, the final step before Gitea CI will trigger the Drone CI, involves pushing the
config change using git push. git push pushes your changes to the remote repository. You
can see what happens once I issue git push in the screenshot below.

Using above, I pushed my changes into dev_branch and it triggered the CI stage in both
Gitea as well as Drone which is my build server. You can see 4 objects, since my
change calls for removal of two SNMP CLIs which sets the READ and WRITE
community strings and then replace them with newer values.

Let’s now look at what happened on Gitea server after my git push.

Technet24
||||||||||||||||||||
||||||||||||||||||||

||||||||||||||||||||
||||||||||||||||||||

You can see “-” and “+” denoting what was removed versus added from the
configuration, it also shows +2/-2 to describe the same information. 10.0.10.1 is my
switch IP address where these changes are to be tested and then committed.

Let’s now look at what happened on Drone server after my git push.

If you follow the commit message, “FullStackNetworker #1”, you can see the there was
an initial build->test cycle for dev_branch and after successful completion, it was
repeated for master branch before finally deploying it to my switches.

Technet24
||||||||||||||||||||
||||||||||||||||||||

Let’s zoom into each dev_branch first on Drone server. On the right side it shows the
steps taken around the Gitea/Drone handoff as part of “Clone” stage within my CICD
pipeline configuration. My pipeline consists of build start stage, followed by integration
testing and merge change into master and then notify NetDevOps team via Slack.

You can see that for 4 lines of change, the entire pipeline for dev_branch and master
branch take only about 3 minutes or so. If your config changes are larger, or your
pipeline is longer or more complex, it will take longer. Drone server simply works as
an orchestrator and follows the flow of control within your pipeline file. We will
discuss the pipeline in more details in the future posts.

Below is a screenshot from my Slack channel which shows that NetDevOps team was
notified for dev_branch and master build completion and pipeline execution success.

||||||||||||||||||||
||||||||||||||||||||

Technet24
||||||||||||||||||||
||||||||||||||||||||

Exam Essentials

SDN controller is the central process that communicates with network


devices using southbound APIs
OpenDaylight is an open source project under the Linux Foundation with the
mutual goal of furthering the adoption and innovation of Software Defined
Networking (SDN) through the creation of a common industry supported
framework.
OpenDaylight (ODL) is an open source and modular SDN controller for
customizing and automating networks of any size and scale
SBC and WLAN controller are examples of centralized control and
management that predate the modern SDN movement
OpenFlow is an open source and standard southbound protocol and API
Chef is an open source tool for configuration management, focused on the
developer side for its user base.
Puppet is one of the long-standing tools in the full-fledged configuration
management space
Ansible is an open source agentless tool used to deploy applications to
remote nodes and provision servers in a repeatable way
BGP-LS is a southbound protocol that can be used to export IGP information
from the network to the SDN controller. BGP-LS is an extension to BGP for
distributing the network's link-state (LS) topology model to external entities.
APIC doesn't manipulate the data path directly, Instead, it centralizes the
policy definition automating the entire process of installing and ensuring the
policy.
Cisco Open SDN controller supports OVSDB, OpenFlow, BGP-LS,
NETCONF and PCEP as southbound protocols. It represents hardened,
validated, and supported OpenDaylight distribution
SDN controller defines the control and management planes in an SDN
network
OpFlex was designed to augment rather than replace tools (such as OVSDB)
by focusing on additional requirements of the network and policies that must
span multiple network devices. It includes a native mechanism for identity
resolution used to define declarative policies between two different network
endpoints. It is an open and extensible policy protocol for transferring
abstract policy in XML or JavaScript Object Notation (JSON) between a
network policy controller such as the Cisco APIC and any device, including
hypervisor switches, physical switches, and Layer 4 through 7 network

||||||||||||||||||||
||||||||||||||||||||

services
OpenContrail and ONOS are examples of SDN controller
RESTCONF is an IETF standard that describes how to map a YANG
specification to a RESTful API interface (southbound, when network
devices support RESTCONF interfaces directly and can expose them to an
Orchestrator upstream)
NETCONF Operations layer defines a set of base protocol operations
invoked as RPC methods with XML-encoded parameters. The Messages
layer provides a simple, transport-independent framing mechanism for
encoding RPCs and notifications. The Secure Transport layer provides a
communication path between the client and server.
NETCONF can be layered over any transport protocol that provides a set of
basic requirements. The Content layer is outside the scope of RFC. It is
expected that separate efforts to standardize NETCONF data models will be
undertaken.
The Cisco Virtual Topology System (VTS) is an open, standards-based
overlay management and provisioning system for data center networks. It
automates fabric provisioning for both physical and virtual workloads.
The Virtual Topology System extends a robust set of SDN capabilities to the
entire Cisco Nexus portfolio by bringing automation and programmability to
the Cisco Nexus 2000 Series Fabric Extenders and Cisco Nexus 3000,
5000, 7000, and 9000 series switches

Further Reading
http://goo.gl/MOnV7k
https://goo.gl/G9bU2I
http://goo.gl/upqwQN
http://goo.gl/frsD4S
https://goo.gl/81wYFV
https://goo.gl/LE7gW4
http://goo.gl/L9IbcE
http://goo.gl/xP5TTw
https://goo.gl/L4aovI
https://goo.gl/wMmv0K
http://goo.gl/KzoKUo
http://goo.gl/j83bVa

Technet24
||||||||||||||||||||
||||||||||||||||||||

||||||||||||||||||||
||||||||||||||||||||

Part III: Internet of Things

This chapter covers the following exam topics from Cisco's official Evolving
Technologies (v1.1) written exam curriculum.
Chapter 4: Describe Architectural Framework and Deployment Considerations for
Internet of Things (IoT)
IoT technology stack (IoT Network Hierarchy, data acquisition and
flow)
IoT standards and protocols (characteristics within IT and OT
environment)
IoT security (network segmentation, device profiling, and secure
remote access)
IoT edge and fog computing (data aggregation and edge intelligence)

Technet24
||||||||||||||||||||
||||||||||||||||||||

Part III: Internet of Things

||||||||||||||||||||
||||||||||||||||||||

Chapter 4: Describe Architectural Framework and


Deployment Considerations for Internet of Things (IoT)
The Internet of Things, or IoT, refers to the set of devices and systems that interconnect
real-world sensors and actuators to the Internet. Here are a few examples.

connected cars (e.g. Tesla EVs)


wearable devices (e.g. Apple Watch)
smart meters (e.g. utility meters)
home automation systems (e.g. Nest)
smartphones
wireless sensor networks

Lower power and Lossy Networks (LLN) devices share the following common
characteristics, i.e.

They are bandwidth constraints


They can be highly unreliable due to numerous vendors and software stack
involved
They are generally small in size with limited resources
They are deployed in a very high number

Cisco estimates that number of internet connected devices have already overtaken
human population back in 2010 and they are expected to grow to 50B by 2020.

As per Cisco, biggest barriers and challenges to IoT deployments are

Technet24
||||||||||||||||||||
||||||||||||||||||||

Deployment of IPv6
Sensor energy or power
Agreement on standards

There are three types of devices that make up the IoT architecture.

IoT devices
IoT services
IoT gateway (low power aggregators or bridges)

IoT devices can also be classified into several categories.

Small devices with embedded SOC controllers (e.g. Arduino)


Small devices with ARM chips (e.g. small routers running embedded Linux)
Full-blown devices with 64-bit platforms (e.g. Raspberry Pi running full
blown Linux or Android). These devices may also be gateway.

IoT devices can communicate among themselves or with the gateway using some of the
following protocols.

Direct wired or wireless connectivity using TCP/IP


Bluetooth Low Energy
Near-Field Communication (NFC)
Zigbee (or mesh radio)
SRF and p2p radio links
UART

||||||||||||||||||||
||||||||||||||||||||

SPI or I2C wired

Cisco IoT architectural framework includes the key components and addresses how IoT
networking can be intelligent, automated, and secure from edge to cloud.

Standard way for IoT devices to communicate with each other


IoT device scale
IoT device management
IoT device security and access controls

Six key areas of the Cisco IoT system are as follows.

Network connectivity: routing, switching, and wireless products for


ruggedized or harsh environments and non-ruggedized form factors
Fog computing: it is a s a distributed computing infrastructure for the IoT
which extends computing capability to the edge of networks.
Security: it unifies cyber and physical security to increase the protection of
both physical and digital assets
Data analytics: it provides an infrastructure to implement analytics, so you
can get the actionable data
Management and automation: it provides enhanced control and support for
endpoints and applications
Application enablement platform: it offers a set of APIs for partners and
third-party vendors to design, develop and deploy their own applications

Speaking of security for IoT, as per Cloud Security Alliance (or CSA), following are
the recommended security controls for IoT
Adopt privacy by design approach
Apply Secure Systems Engineering
Implement layer security protections
Implement data protections

Technet24
||||||||||||||||||||
||||||||||||||||||||

Define lifecycle controls


Define and implement authentication and authorization framework
Define and implement logging and audit framework

Given the real-world exposure and scale of IoT devices, following must be kept in mind
as design considerations when designing devices, applications or networks for IoT.

Software, hardware and certification requirements for your application


Size and performance requirements for your device
Communication requirements for your device (wired/wireless, range, GPS
or not, RF etc.)
Power requirements (direct power, battery-powered, battery life etc.)
Environmental requirements (hot/cold, wet/dry, harsh or hazardous etc.)
Security requirements (access control, encryption, secure transport etc.)
Certification requirements (EMI/EMC, FCC etc.)

By adding network intelligence, convergence, orchestration, and analytics with a secure


connection between devices, the Internet of Everything promises to augment the
exponential growth and power of the Internet of Things (or IoT).

Last but not least, success with IoT lies in the following five fundamental principles
Shift to service
Use the cloud
Plan to scale
Automate as much as possible
Learn from industry best practices

IoT Technology Stack (IoT Network Hierarchy, Data Acquisition and


Flow)

When it comes to networking, IoT has unique challenges due to the nature of the
endpoints and the sheer scale of aggregation. In order to meet those challenges, Cisco
IoT/M2M architecture consists of four layers.

Embedded Systems Layer

This layer comprises of embedded systems, sensors and actuators. These are small
devices with a wide variety of operating systems, CPU types, memory to name a few.

||||||||||||||||||||
||||||||||||||||||||

These small endpoint (e.g. temperature or pressure sensors) are inexpensive and single
function devices with basic networking built into them. In terms of location, they can be
in remote or inaccessible places where human intervention for configuration or
troubleshooting may not be possible.

By nature, sensors are embedded into whatever they are sensing which means they are
likely to be included at the time of construction, i.e. network must have some redundant
secondary links for connectivity in case the primary link fails after the installation is
completed.

In case of wireless, devices may utilize either a long-range communication system, such
as LTE. They may also use short range communication protocols that provide better
performance such as WiFi. There is yet another type of communication paradigm which
is short range with very limited bandwidth such as what are defined under IEEE
802.15.4.

Multi-Service Edge (or Access) Layer

Given the variability of endpoint devices and the enormous scale, requires that you have
a multi-service edge that is multi-modal supporting both wired and wireless
connectivity. This layer must support protocols such as Zigbee, IEEE 802.11, 3G/4G-
LTE to accommodate the connectivity needs. In some cases, those devices may not even
have security services such as encryption or authentication, so this layer must be able to
provide that security and be modular to scale to meet growth requirements. Modularity
of building blocks within this layer will also help with quicker deployments.

IoT gateways can perform a variety of functions, including but not limited to the
following

Harmonizing two heterogenous domains, if devices in one network use


protocol A and the other use protocol B, then it is gateway’s job to ensure
that protocol translation takes place
Protocol translation can also take place for various features, they can
include routing or address translation or even management functions.
End to end connectivity across two disparate networks

Technet24
||||||||||||||||||||
||||||||||||||||||||

Core Network Layer

Core networking layer is the same as it is in the conventional networks, i.e. redundant
paths to carry and exchange data between multiple sites. However, the key difference
between IoT and conventional networking is the underlying traffic profile. In case of
IoT, traffic would consist of bunch of different protocols with variable packet sizes.
This layer must also ensure the following.

Protection against Man-in-the-Middle (MiTM) attack, to ensure that IoT data


is not tampered with or compromised
Protection against Spoofing, to ensure an attacker who has compromised an
identity can’t send malicious traffic to victim endpoints on the network
Data confidentiality, with encryption
Protection against anti-replay attack, so data can’t be replayed on the
network to an already established session

Data Center Cloud Layer

The function of this layer is to host applications that are critical in providing services
and support end to end IoT architecture. All services in the DC must be secure and
hardened to ensure that end to end IoT architecture is safe and secure.

In terms of security, the purpose of this layer is to protect hosted services against the
following attack vectors.

DoS against services hosted in the data center


Protection against buffer overflow and remote code execution

Data Acquisition and Flow

The IoT architecture is modular as different scenarios require different approaches. The
overall system is divided into different functional components.

Data Acquisition: Interacting with devices (IP or non-IP protocol), receiving


data from the device, and handling the initial processing
Data Retention: Data can be stored, transformed, and retrieved on demand
Data Transport: Reliable delivery and transformation of data
Data Processing: There are three scenarios here where data could be

||||||||||||||||||||
||||||||||||||||||||

processed at the edge, or at the aggregation point or in the backend data


center hosting the services. All options are available with this system.
Data Leverage: Enabling the consumer of the data to leverage it quickly and
effectively.
Control: The system must be secure

The modularity of the system provides independence and decoupling between the
different subsystems and adds great value to the customer through the lifetime of the
system by allowing for growth using new modules from Cisco or third parties or
combining Cisco software with other third-party software as needed. This is an open
system supporting both proprietary and standard interfaces, with metadata management
throughout the system.

For each of these functions there are a rich variety of options and processing modules
that can be invoked to customize the system to the customers’ exact needs.

An IoT gateway sends data to a broker, e.g. Cisco Kinetic Edge or EFM module. This
gateway facilitates communication between IoT network and the business applications
or services. IoT gateways also have their API controls which can be tapped in by the
developers say using Kinetic EFM for programmability and automation cases. This
allows for IoT data that can now be consumed by manufacturing applications.

Technet24
||||||||||||||||||||
||||||||||||||||||||

IoT Standards and Protocols (characteristics within IT and OT


environment)

IoT utilizes the existing networking infrastructure, technologies and protocols along
with a ton of new ones. First, let us take a look at a comparison of the internet (or
TCP/IP) versus the IoT networking stack.

Following is a summary of IoT protocols, grouped together in a few layers.

Layer Protocol(s)
Infra 6LowPAN, IPv4/IPv6, RPL

||||||||||||||||||||
||||||||||||||||||||

Identification EPC, uCode, IPv6, URIs


Communication / Transport Wifi, Bluetooth, LPWAN, LoRa
Discovery Physical Web, mDNS, DNS-SD
Data Protocols MQTT, CoAP, AMQP, Websocket, Node
Device Management TR-069, OMA-DM
Semantics JSON-LD, Web Thing Model
Multi-layer frameworks Alljoyn, IoTivity, Weave, Homekit

Now, let’s go over each of those IoT specific protocols.

6LoWPAN stands for IPv6 over Low power Wireless Personal Area Networks. It is an
adaption layer for IPv6 over IEEE 802.15.4 links. This protocol operates in the 2.4
GHz frequency spectrum and at lower data rates of up to 250 kbps.

6LoWPAN can communicate with 802.15.4 devices as well as other types of devices on
an IP network link like WiFi. A bridge device can connect the two network types. It’s
the newest alternative to ZigBee. It provides MTU correction, header compression,
mesh routing and supports MAC level retransmissions.

LoRa technology enables low power wide area network coverage at the cost of reduced
data rate and sticks to strict spectrum use. It uses star topology for connectivity hence
there is no need for a routing protocol.

LoRa builds stars or star of stars topologies, eliminating need for routing protocol and
multi-hop communication.

Quick UDP Internet Connections (QUIC) supports a set of multiplexed connections


between two endpoints over UDP, along with data protection via TLS/SSL and reduced
connection and transport latency.

The uIP is an open source TCP/IP stack capable of being used with tiny 8- and 16-bit
microcontrollers.

ROLL / RPL (IPv6 routing for low power/lossy networks). RPL is the distance vector
routing protocol IPv6 for Low-Power and Lossy Networks (or LLN) as defined in RFC
6550. The RPL-LLN is supported on Cisco IOS software.

Technet24
||||||||||||||||||||
||||||||||||||||||||

NanoIP was created to bring IP-like networking services, without the overhead of
TCP/IP, to sensor devices.

Message Queuing Telemetry Transport (MQTT) protocol provides a publisher /


subscriber messaging model in a very lightweight way for IoT and M2M networks.

Constrained Application Protocol (CoAP) is an application layer protocol that is


purpose built for use in resource-constrained internet devices. CoAP is designed to
easily translate to HTTP for simplified integration with the web.

CoAP uses RESTful protocol design and supports the discovery of resources provided
by known CoAP services. To protect the transmission of confidential data secure CoAP
uses datagram transport layer security (DTLS) as the security protocol for
communication and authentication of communicating devices. CoAP supports
NAT64/DNS64 along with LDAP authentication. It uses UDP 5683 or 5684 ports for
transport.

CoAP supports multicast and provides with faster response times to client.

Advanced Message Queuing Protocol (AMQP) is a yet another open standard


application layer protocol for message-oriented middleware. AMQP provides
orientation, queuing, routing (i.e. p2p and p2s), reliability and security.

ZigBee protocol uses the IEEE 802.15.4 standard and also operates in the 2.4 GHz
frequency spectrum with speeds up to 250kbps. Within 200m range, it can support to 1K
nodes. It supports 128-bit AES encryption.
IoT Security (network segmentation, device profiling, and secure
remote access)

Segmentation is about building a secure place to protect what you have from the known
and the unknown risks on the network, and then with improved visibility you can
identify and protect the IoT devices you discover. Segmentation puts these devices out
of the reach of attackers and prevents these devices from being used as pivot points to
move through the network if they are compromised.

Cisco ISE provides Id-based access control along with context, and visibility of IoT
devices and users throughout the network. Cisco ISE acts as a controller and an
orchestrator for TrustSec-based software-based segmentation policies.

||||||||||||||||||||
||||||||||||||||||||

With Cisco TrustSec, you can control access to network segments and resources using
the networking devices such as switches, routers and firewalls you already have. These
role-based access control policies allow you to dynamically segment your network
without the complexity of VLANs and manual LAN switch configurations.

Increased connectivity has arguably more benefits than drawbacks, so it’s no surprise
that many equipment vendors, such as industrial and healthcare equipment vendors,
require remote support in their support contracts. It saves the vendor's operational costs
when they do not need to send a technician on-site, and remote support can reduce
downtime for customers as the technician gets to work while still on the phone with the
customer.

IoT Threat Defense provides secure communications from the remote party to the
network and employs segmentation, visibility, and analysis to make sure remote users
do not introduce threats but access only the systems for which they are allowed access.

As per Cisco, there are two major threat surfaces that lie within IoT domain, i.e.

Old and archaic equipment and/or technology


Inherently insecure design found in the IoT devices
IoT Edge and Fog Computing (data aggregation and edge
intelligence)

Cisco Kinetic is an IoT software-based data fabric. Kinetic is created to extract,


compute, and transport data from the things that make up the IoT to the various
applications or services where it can provide tangible value. Fog computing is a s a
distributed computing infrastructure for the IoT which extends computing capability to
the edge of networks.

Fog computing is a standard that defines how edge computing should work, and it
facilitates the operation of compute, storage and networking services between end
devices and cloud computing data centers.

The core Kinetic platform includes three software modules that carry out the actions of
extraction, compute and transport.
Gateway Management Module (GMM)
Edge & Fog Processing Module (EFM)
Data Control Module (DCM)

Technet24
||||||||||||||||||||
||||||||||||||||||||

EFM performs complex rules on data in motion to intelligently reduce, compress,


normalize, and transmit data in optimal ways. It enables a new class of IoT applications
for advanced monitoring and diagnostics that can improve your overall equipment
efficiency. EFM is open and modular, able to incorporate micro-services from any
third-party vendor. You can use EFM in both connected environments as well offline
environments that have no internet connectivity.

As a result of edge and fog computing, data processing becomes distributed. IoT
workloads are different from cloud computing workloads. Unlike cloud, IoT workloads
are not as forgiving. Given the expanding role of data as precious commodity, it is super
crucial to process data close to the device that originated it if possible.

The need for speed and the value of edge computing are on the rise. IoT uses are broad
and apply to most every aspect of a government. Imagine events such as sudden onset of
severe weather which requires actions such as closing of the gates or activating
emergency door locks for human safety. The edge fog computing holds the keys to faster
response times that required in those situations.

Data Aggregation

Data aggregation is a big challenge in IoT networks due to the sheer scale of IoT
devices. As per Cisco’s IoT architecture, data filtering, aggregation and compression
are supposed to be performed at the edge, in the fog or at the core. There are at least
three main reasons for performing data aggregation.

to conserve bandwidth
to reduce power consumption
to reduce data footprint and thus storage requirements

Data aggregation happens both at the physical layer protocols as well as higher layers
above it. Let’s summarize the overall aggregation points that exist out there.

Direct transmission, in smaller deployments, all nodes send their data


directly back to base station.
Low-energy adaptive clustering hierarchy (or LEACH) is a TDMA-based
MAC protocol which is built within clustering along with a routing protocol
in wireless sensor networks. The goal is to lower the energy consumption

||||||||||||||||||||
||||||||||||||||||||

required to create and maintain clusters in order to improve life span of a


sensor. Cluster Head (CH) is nominated to act as an aggregation node. All
nodes send traffic into CH and CH communicates in turn with the base
station in sort of a long-haul fashion. CH also supports data aggregation
function and thus reduces traffic sent into upstream.
LEACH-Centralized (LEACH-C) is a variant of LEACH that centralizes the
CH selection. Nodes report back their location information as well as
energy levels back to the base station.
Threshold-sensitive Energy Efficiency Network (TEEN) is a reactive
protocol, where radio stays off until there is significant change that can be
sent back. It is best suited for time critical applications such as intrusion or
explosion detection.
Minimum Transmission of Energy (MTE), MTE is computationally more
complex than PEGASIS, the nodes closest to the base station are used to
route a large number of data messages to the base station.
Power Efficient Gathering in Sensor Info Systems (PEGASIS) is based on a
round-robin topology where each node sends data to only its neighbor. There
is no CH role in PEGASIS as all nodes function together but only one node
communicates with the base station.
Unlike TEEN and LEACH, Static clustering is another approach that
requires creating clusters which act as aggregators.
Distributed Energy Efficient Clustering (DEEC) and Developed DEEC are
similar to static clustering. It calls out for two types of nodes variations, one
that’s known as “normal” and the other as “advanced”. The only difference
between DEEC and DDEEC is around CH selection, which DDEEC
considers both the initial and remaining levels of energy in consideration for
CH selection.
Edge Intelligence
The concept of edge intelligence or EI is a paradigm shift with respect to acquisition,
storage and processing of data, where data processing is move upstream from the cloud
data center all the up to the edge of the network, i.e. between data source (which is
typically a sensor) and the IoT core. It is worth noting that data can and will still be
stored in the backend data center, however the data “crunching” part is something that is
moved to the edge. This helps provide better experience and gain highly granular
insights.

According to BI Intelligence data, IoT devices connected to edge computing models


will explode in the near future, from a mere 570 million in 2015 to 5.6 billion devices

Technet24
||||||||||||||||||||
||||||||||||||||||||

in 2020.

||||||||||||||||||||
||||||||||||||||||||

Exam Essentials

Fog computing is a s a distributed computing infrastructure for the IoT which


extends computing capability to the edge of networks.
As per Cisco, biggest barriers and challenges to IoT deployments are
Deployment of IPv6
Sensor energy or power
Agreement on standards
The Cisco IoT System comprises six critical technology elements or ‘pillars'
Network connectivity
Fog computing
Security
Data analytics
Management and automation
Application enablement platform
By adding network intelligence, convergence, orchestration, and analytics
with a secure connection between devices, the Internet of Everything
promises to augment the exponential growth and power of the Internet of
Things (or IoT).
IoT provides infrastructure security, intelligence and analytics as network of
networks
As per Cisco, IoT is just one of four dimensions — people, process, data,
and things.
DTLS is used to secure CoAP communication
RPL is a distance vector IPv6 Routing Protocol for LLN (Low-Power and
Lossy Networks) as defined in RFC 6550
Sensors, control points and routers are critical components of RPL
Zigbee protocol is designed for short distance wireless communication and
is very different from 802.11 WiFi protocol
CoAP allows resource constrained IoT devices to communicate efficiently
6LowPAN is a low throughput, limited buffering and datagrams that are one-
tenth of IPv6 minimum MTU make header compression and data
fragmentation a necessity
CoAP supports NAT64/DNS64 along with LDAP authentication. It uses UDP
5683 or 5684 ports for transport.
Sensors/actuators, smart objects, or smart devices are example of
constraints nodes in an IoT network leading to constraints on the network

Technet24
||||||||||||||||||||
||||||||||||||||||||

they are part of


As per Cloud Security Alliance (or CSA), following are the recommended
security controls for IoT
Adopt privacy by design approach
Apply Secure Systems Engineering
Implement layer security protections
Implement data protections
Define lifecycle controls
Define and implement authentication and authorization framework
Define and implement logging and audit framework
The Cisco FAN supports Advanced Meter Infrastructure (AMI), Distribution
Automation, and Workforce Automation use cases. It consists of three main
components
Connected Grid endpoint
Ruggedized modular 1000 Series Connected Grid Router
IoT Field Network Director
Fog computing is a standard that defines how edge computing should work,
and it facilitates the operation of compute, storage and networking services
between end devices and cloud computing data centers
Success with IoT lies in the five fundamental principles
Shift to service
Use the cloud
Plan to scale
Automate as much as possible
Learn from industry best practices
LoRa builds stars or star of stars topologies, eliminating need for routing
protocol and multi-hop communication
Further Reading
https://goo.gl/CLjI9X
http://goo.gl/nY8gib
http://goo.gl/tirJtw
http://goo.gl/c8OlKI
http://goo.gl/rulV7f
https://goo.gl/sfM4ak

||||||||||||||||||||