0% found this document useful (0 votes)

32 views316 pages

ADVNSO - v4.2 Student Guide

The Advanced Cisco Network Services Orchestrator (NSO) Student Guide provides an overview of Cisco NSO, focusing on service design and orchestration using Network Function Virtualization (NFV). It covers various service models, APIs, and mapping logic necessary for developing and deploying services, including VPNs and cloud services. The guide emphasizes the importance of flexibility, scalability, and rapid service development in modern network environments.

Uploaded by

azaiez

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

32 views316 pages

ADVNSO - v4.2 Student Guide

Uploaded by

azaiez

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 316

ADVNSO

Advanced Cisco Network

Services Orchestrator
Student Guide
Version 4.2
Americas Headquarters Asia Pacific Headquarters Europe Headquarters
Cisco Systems, Inc. Cisco Systems (USA) Pte. Ltd. Cisco Systems International BV
San Jose, CA Singapore Amsterdam,
The Netherlands

Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at
www.cisco.com/go/offices.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the United States and other
countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned
are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco
and any other company. (1110R)

DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO
WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY, OR
IN ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO
SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY,
NONINFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING,
USAGE, OR TRADE PRACTICE. This learning product may contain early release content, and while Cisco believes it to be
accurate, it falls subject to the disclaimer above.
Table of Content
Course Introduction 1-1
Service Provider VPN Service Design with NSO 1-3
NSO Application Framework................................................................................... 1-5
Service Applications 1-6
Python API 1-14
Demo Example: Python and Template 1-31
Java NAVU API 1-41
Demo Example: Java and Template 1-51
MAAPI Changes 1-61
Summary 1-63
Layer 3 MPLS VPN Service Design ...................................................................... 1-65
L3 MPLS VPN Service Design 1-71
L3 MPLS VPN Mapping Logic 1-91
L3 MPLS VPN Service Deployment 1-101
L3 MPLS VPN Service Upgrade 1-111
Deleted elements 1-112
Added elements 1-112
Re-ordered elements 1-112
Type changes 1-112
Hash changes 1-113
Key changes 1-113
Default values 1-113
Adding/Removing namespaces 1-113
Changing to/from operational 1-113
Callpoint changes 1-113
Summary 1-118
Layer 2 MPLS VPN Service Design .................................................................... 1-119
P2P L2 VPN Service Review 1-120
Service Optimization 1-131
External Resources with Reactive FASTMAP 1-140
Reactive FASTMAP Example 1-145
Kicker 1-156
Summary 1-159

Cloud VPN Service Design 2-1

Cloud VPN ................................................................................................................ 2-3
Cloud VPN Overview 2-4
Cloud VPN Network Topologies 2-10
Architecture Overview 2-17
Cisco Elastic Services Controller (Cisco ESC) 2-23
Scenario 1: Deploying VNFs (creating images and flavors through Cisco ESC) 2-34
Scenario 2: Deploying VNFs (using out-of-band images and flavors) 2-34
Scenario 3: Deploying VNFs with Service Registration 2-34
Positional arguments: 2-43
Optional arguments: 2-43
Arguments of OpenStack where to bootstrap Cisco ESC VM: 2-44
Arguments of OpenStack that Cisco ESC Manager works with: 2-44
High-availability arguments: 2-44
Cluster arguments: 2-45
Network arguments: 2-45
Summary 2-64
Simple Cloud VPN Service Design ....................................................................... 2-65
Stacked Services 2-66
Designing a vQoS Service 2-96
Summary 2-104

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO i
Service Chaining Design ..................................................................................... 2-105
Complex Service Design 2-106
Direct Resource Allocation 2-108
Resource Allocation Service 2-115
VM Management Service 2-122
Stacked Services 2-125
NFVO Bundle 2-133
Common Application Types 2-148
Summary 2-152

ii © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Course Introduction
Overview
Cisco Network Services Orchestrator provides a flexible framework for rapid service development. Today
many services depend on Network Function Virtualization to achieve better scalability and faster time-to-
market. In combination with Cisco Elastic Services Controller, Cisco NSO allows developers to design end-
to-end services, easily making use of VNF functionality. Additional extensibility is achieved through a set of
APIs with bindings for Python and Java programming languages. This course’s goal is to cover these topics
through a set of real-world use-cases with topics like VLAN and IP address allocation, VPN service design,
virtual routing and firewall functions etc.
1-2 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Module 1

Service Provider VPN Service

Design with NSO

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-3
1-4 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Lesson 1-1

NSO Application Framework

Overview
Cisco NSO services streamline network provisioning and provide abstraction for device configuration. We
call them resource-facing services. Customer-facing services on the other hand group multiple resource-
facing services into a single service to be used by customers. For complex services, we make use of Java
NAVU or Python Maagic API which allow greater flexibility and control over how a service is managed.

Objectives
Upon completing this lesson, you will be able to meet these objectives:
 Explain the difference between customer-facing and resource-facing services
 Describe how code-based mappings can be used to extend resource-facing services
 Describe various APIs
 Learn how NAVU or Maagic API can be used to access data models

Tasks of the Service Application

Define Inputs (YANG): Video Streaming config OK?
 Parameter names
 Validation (must, leafref, …)

Mapping Logic: Turn the knobs on devices to

 The heart of the NSO make it happen.
service manager
 XML templates

Application:
 Provide custom behavior / validation
Application Network
 Service test method External
Server Switch
Storage
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 4

The main goal of using Cisco Network Services Orchestrator (Cisco NSO) is to write service applications.
From a high-level perspective, a service application consists of three mandatory components:
 Service Model: A model of the service you want to provide.
 Service Validation Logic: A set of validation rules incorporated into your model. They can be
incorporated inside the YANG model itself using constraints and must statements, or they can be a part
of the Java code.
 Service Mapping Logic: A Java class mapping that maps the service model on the device layer,
typically with the help of XML template files.
Optionally, we can also write our own applications that are going to be a part of the service. For example, we
want to check whether our Video Streaming service is actually working correctly after it is deployed in
production.

1-6 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Catalog and Resource-Facing Services
admin@ncs% show services web-site admin@ncs% show services properties
web-site volvo-global { properties {
description "Volvo public web .com"; web-site {
url www.volvo.com; profile bronze {
ip 136.15.64.11; description "1 Web server";
port 80; lb lb0;
backend www0;
lb-profile gold;
}
}
profile gold {
web-site volvo-sweden { description "3 Web servers";
description "Volvo public web .se"; lb lb0;
url www.volvo.se; backend www0;
ip 136.15.64.16; backend www1;
port 80; backend www2;
lb-profile silver; }
} profile silver {
description "2 Web servers";
lb lb0;
Resource-facing backend www1;
backend www2;
services – RFS …
Service catalog
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 5

The service catalog is basically a database of available service models. Only after these models get
instantiated are they called resource-facing services (RFS).
In the example, we have defined a service model named “web-site.” In addition to the model, we store
several profiles in the configuration database (CDB). These will be used as parameters when creating
instances of the “web-site” service. The combination of the model and the parameters comprises the service
catalog.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-7
Customers and Customer-Facing Services
admin@ncs% show customers Customer admin@ncs% show services customer-service
customer exxon { customer-service volvo-public-web {
rank 12; customer volvo;
status inactive; Customer- service /services/wse:web-site
} facing service [name='volvo-global'];
customer spotify { service /services/wse:web-site
rank 5; Each [name='volvo-sweden'];
status prospective; customer- service /services/sec:security
} facing service [name='volvo-threat-level-2'];
customer volvo { }
rank 10;
points to
status active; one or more
New resource facing services can be prepared in
} resource- advance, tested and then deployed by just
facing changing a reference in the customer facing
services. service.
The CFS concepts are
entirely optional to use in admin@ncs% set services customer-service
Cisco NSO. volvo-public-web service
/services/sec:security [name='volvo-
threat-level-4']
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 6

Another type of services is a customer-facing service (CFS). The customer-facing service is assigned to a
customer and consists of several resource-facing services. This concept is completely optional and is not
enforced in Cisco NSO. It is used to differentiate services that are seen and used by the customer on the
northbound interface from services that are used to configure resources on the southbound interfaces. These
services are called resource-facing services.
Note that the term “Customers” is used within Cisco NSO context here. Other systems may use a different
terminology for this: BSS may refer to customers, OSS may refer to subscribers, and the application layer
may simply refer to users.
The complete model for the optional customer construct can be seen in the tailf-ncs-customers.yang file, part
of Cisco NSO’s internal YANG models.

1-8 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Services
 Service design goal is simplicity for the operator:
 Minimum set of parameters for the service (optimization)
 Strict enforcement of parameters to minimize human error (standardization)
 Use the ncs-make-package command to create a service package
 Develop the service model (YANG) and the service application (mapping logic)
 Often requires access to external resources and applications through code
 NFV Orchestration
 IP address management

A service package includes YANG code that models a NSO service and Java/Python code that implements
the service.
The ncs-make-package command will generate skeleton files for our service models and for our service
application. The generated package includes a skeleton service model (YANG file), an implementation of the
service application (mapping logic), and the files necessary to build the package.
With the use of the skeleton package and a simulated environment in netsim, you can start developing the
necessary components immediately.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-9
Network Function Virtualization
 Decoupling network function from hardware.
 Standard (existing) virtualization technologies.

 Service providers – reduce costs (OPEX), more agility

 Common infrastructure, shorter time to market for new services.
 Simplified multi-tenancy.

 Use cases:
 vCPE – all L3 functionality within the cloud gateway
 Mobility packet core – Quantum vPC
 WAN optimization

Network Function Virtualization (NFV) technology, in combination with Software Defined Networking
(SDN), promises to help transform today's carrier networks. It will transform how they are deployed and
managed, and the way services are delivered. The ultimate goal is to enable service providers to reduce cost,
increase business agility, and accelerate the time to market of new services.
NFV decouples network functions from the underlying hardware so that they run as software images on
commercial off-the-shelf and purpose-built hardware. It does so by using standard virtualization technologies
(compute, network, and storage) to virtualize the network functions. The objective is to reduce dependence
on dedicated, specialized physical devices by allocating and using the physical and virtual resources only
when and where needed. With this approach, service providers can reduce overall costs by shifting more
components to a common physical infrastructure while optimizing its use. It allows service providers to
respond more dynamically to changing market demands by deploying new applications and services as
needed. The virtualization of network functions also enables the acceleration of time to market for new
services because it allows for a more automated and streamlined approach to service delivery.
Simple examples demonstrating the benefit of an NFV service are a virtualized firewall or a load balancer.
Instead of installing and operating a dedicated appliance to perform the network function, NFV allows
operators to simply load the software image on a virtual machine (VM) on demand. In a mobile network,
examples include virtualizing the mobile packet core functions such as packet data network gateway (PGW),
serving gateway (SGW), mobile management entity (MME), and other elements.

1-10 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Mapping Approaches
Template only (XML template):
Service  Only simple mappings.
Model
 Implemented in minutes (e.g. in CLI).

Custom code only:

Implemented in:
Mapping

 Template  Most expressive power, but also requires

 Custom code
most work.
 Code + Template  Make calls to external applications.
 Execute complex algorithms.

Custom code instantiating template:

Device  Do the complex computations in Java/Python.
Models  Export results to the XML template.
 Apply the bulk of the settings with template.
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 9

Mapping logic defines how service-related operations are reflected on the devices. This involves mapping the
service attributes to available attributes on devices. For example, when you add an access link to a VPN, how
is this reflected on Customer Edge (CE) and Provider Edge (PE) routers?
It is important to note here that the mapping logic implementation at this point does not directly interact with
the device native configuration or management interface (be it NETCONF, CLI, or some other API). The
mapping transforms the service parameters to the device configuration according to the device YANG
models. This unique to Cisco NSO approach allows the service developers to develop device-agnostic
service models and declarative mapping independent of the device interface. The Device Manager transforms
the device configuration into device native configuration commands.
This can be done using templates when the mapping is a pure data-model mapping exercise. When logic is
required, Java can be used to do the mapping.
Cisco Network Services Orchestrator (Cisco NSO) supports three approaches when it comes to services to
device mapping:
1. The XML template-based approach: It is the simplest to use and the fastest to implement. The
templates contain device configuration, according to the schema defined in the device model(s). It is
possible to use Cisco NSO CLI to obtain the XML directly, using the CLI commands.
2. The Java-based approach: It offers the highest amount of flexibility and expressing power but it is also
the most demanding to work with. This approach is necessary when complex algorithms need to be
implemented and when calls to external applications (like database access) need to be made. Device
configuration is provided by the service application via the NAVU API.

3. A combination of both approaches: Java code can implement complex algorithms and access external
applications to obtain values for service parameters. These parameters can then be passed from Java code
to the XML template.

The XML templates used in service packages are called config templates. The templates reside in XML files,
within a package. The templates can change any part of the configuration database (CDB) – you are not
limited to configuring only devices, but other services as well. In contrast, device templates are defined
within Cisco NSO, are stored in the CDB, and can only modify the device configuration.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-11
Java Service Engine
 Services make use of Java code through designated service class.
 Defined in package-meta-data.xml and implements create() callback.
 XML can define additional components, like custom applications.
<component>
<name>MyService</name>
<callback>
<java-class-name>com.example.myrfs.myrfs</java-class-name>
</callback>
</component>
<component>
<name>MyApplication</name>
<application>
<java-class-name>com.example.myservice.app1</java-class-name>
</application>
</component>

Developers use Java application programming interfaces (APIs) when developing service applications,
especially the NAVU API, (Navigation Utilities, com.tailf.navu). NAVU is an abstraction on top of Java
MAAPI and it provides a lazy Document Object Model (DOM) representing the model.
In order to develop a new service application based on a YANG model, a developer only implements the
create callback method which corresponds to the service point in the YANG model. This simplistic method
abstracts one of the unique and game-changing features of Cisco NSO. The amount of code to map the
service model to the device model is extremely small. The developer only has to define how to create the
service, all other scenarios like change and set are automatically derived from the “create template”. This is a
huge benefit compared to traditional stub-generators. This algorithm is called FASTMAP.
The service mapping logic of the service engine is expressed using the Java language. For each service, a
Java class is created. This class should implement the create() callback method from the Service-Callback
interface. This method will be called to set up the mappings for the service instance.

1-12 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Python Service Engine
 Cisco NSO runs Python VMs <ncs-package xmlns="http://tail-f.com/ns/ncs-packages">
for Python packages. <name>snakey</name>
<package-version>1.0</package-version>
<description>Generated Python package</description>
 Similar to Java, python- <ncs-min-version>2.2</ncs-min-version>
<python-package><vm-name>vm</vm-name></python-package>
class-name in package- <component>
meta-data.xml file defines <name>service</name>
<application>
service class. <python-class-name>Service</python-class-name>
</application>
 Multiple packages can run in </component>
</ncs-package>
the same VM if desired.

cisco@NCS:~/ncs-run/packages/$ ncs-make-package --python-skeleton snakey

--component-name service

Cisco NSO is capable of starting one or several Python VMs where Python code in user-provided packages
can run.
A Cisco NSO package containing a Python directory will be considered to be a Python Package. By default,
a Python VM will be started for each Python package that has a python-class-name defined in its
package-meta-data.xml file.
Any required-package listed in the package-meta-data.xml will be included in the PYTHONPATH of the
started Python VM, so its accompanying Python code will be accessible.
Several Python packages can be started in the same Python VM if their corresponding
package-meta-data.xml files contains the same python-package/vm-name.
A Python package skeleton can be created by making use of the ncs-make-package command:

Python Low-Level APIs

Low level APIs:
MAAPI
 MAAPI NSO
 Transactions Service Manager
YANG Service models
 Used by CLI, north-bound APIs
 CDB Device Manager
YANG Device models
CDB
 Internal use by services
 DP DP CDBA
API PI
 For extensions / integration
Direct mapping of C APIs.
Contained in _ncs parent python module.

The Cisco NSO Python library contains a variety of APIs for different purposes. The Python modules fall
into two groups, the low-level and high-level APIs.
The low-level APIs are a direct mapping of the NSO C APIs. Their equivalent implementations exists in
other programming languages supported by Cisco NSO.
The low-level modules are contained in the _ncs parent python module. For documentation, refer to the
python modules documentation, as well as the confd_lib manpages.
>>> import _ncs
>>> help(ncs)
Help on package _ncs:

NAME
_ncs - Common functions for applications connecting to NCS.

FILE
/Users/markoz/nso-4.2/src/ncs/pyapi/_ncs/__init__.py

DESCRIPTION
The module is used to connect to NCS. It describes functions and data
structures that are not specific to any of the APIs described in the
submodules.

1-14 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
This documentation should be read together with the confd_lib_lib(3) man
page.

N.B. If a custom NCS listening port is set with the environment variable
NCS_IPC_PORT, the constant _ncs.PORT will be set to that value.

PACKAGE CONTENTS
_ncs_py2
_ncs_py3
deprecated (package)

SUBMODULES
cdb
dp
error
events
ha
maapi

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-15
Python High-Level APIs
High level APIs:
MAAPI
 MAAPI NSO
 Maagic Service Manager
YANG Service models
 Service, Action Callbacks
Device Manager
 Subscriber wrapper YANG Device models
CDB

DP CDBA
Provide abstraction layer
API PI
Contained in ncs parent python module.
Python High-Level

The high-level APIs provide an abstraction layer on top of the low-level APIs making them easier to use.
The high-level Maapi API allows you to work with MAAPI session in a Pythonic way.
The high-level modules are contained in the ncs parent python module. For documentation, refer to the
python modules documentation.
>>> import ncs
>>> help(ncs)
Help on package ncs:

NAME
ncs - NCS Python high level module.

FILE
/Users/markoz/nso-4.2/src/ncs/pyapi/ncs/__init__.py

DESCRIPTION
This top module imports the following modules:

application -- module for implementing packages and services

dp -- data provider, actions
log -- logging utilities
maagic -- data access module
maapi -- MAAPI interface
template -- module for working with templates

1-16 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
PACKAGE CONTENTS
application
childlist
dp
experimental
fsm
keypath
log
maagic
maapi
template
tm

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-17
High-Level MAAPI API
Open a new MAAPI
Single transaction session for admin, start
import ncs write transaction
with ncs.maapi.single_write_trans('admin', 'python') as t:
ncs_version = t.get_elem('/ncs-state/version')
print 'NSO version %s' % ncs_version
t.set_elem('42', '/test/oper-write')
t.apply()

Open a new MAAPI

session for admin
MAAPI session for multiple transactions
with ncs.maapi.Maapi() as m: Start first write transaction
with ncs.maapi.Session(m, 'admin', 'python'):
with m.start_write_trans() as t:
value = t.get_elem('/devices/device{c0}/address')
t.set_elem('1.2.3.4', '/devices/device{c0}/address') Start second write
t.apply()
transaction
with m.start_write_trans() as t:
t.set_elem(value, '/devices/device{c0}/address')
t.apply()
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 15

The Python high-level MAAPI API provides an easy to use interface for accessing NSO. Its main targets is
to encapsulate the sockets, transaction handles, data type conversions and the possibility to use the Python
with statement for proper resource cleanup.
The module for the high-level MAAPI API is ncs.maapi. Using the module, it is possible to open a new
MAAPI session towards NSO with a specified username and context. The module also contains helpers for
starting transactions within the MAAPI session.
The simplest way of using the module is in combination with Python’s built-in context managers. Using the
with statement, it is possible to create objects for a new runtime context (block of code). The objects will be
properly disposed of when exiting the context. The first example shows using a context-managed MAAPI
session with a single-use write transaction.
In the second example, we start a new context-managed MAAPI session, but start a new write transaction
separately. After the transaction is finished, we can reuse the same session to start another.

1-18 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
High-Level Maagic API
 Navigating the model tree with MAAPI XPaths is complicated
 Uses Python objects (dot notation) instead
 Still uses MAAPI / Transaction in the backend

 Read / write data and execute actions

with ncs.maapi.single_write_trans('admin', 'python') as t: Open a new MAAPI

# Construct root object session for admin, start
write transaction
root = ncs.maagic.get_root(t)
# Use root for navigating data
device = root.devices.device['c0']

Use root’s properties to

access data

Maagic is a module provided as part of the NSO Python APIs. It reduces the complexity of programming
towards NSO, is used on top of the MAAPI high-level API and addresses areas which require more
programming. First, it helps in navigating in the model, using standard Python object dot notation, giving
very clear and easily read code. The context handlers removes the need to close sockets, user sessions and
transactions and the problems when they are forgotten and kept open. Finally it removes the need to know
the data types of the leafs, helping you to focus on the data to be set.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-19
Maagic: Node Class
 Node: base class for all nodes
 _name – yang name of the node
 _path – keypath in string format
 _parent – parent node (or None)
 _cs_node – schema node of this node
 Implements Python magic methods to enable traversal
 Low-level API methods used on high-level API objects
 Implemented with Python __getattr__() method

The Maagic class Node is the base class of all high-level Python API objects, representing different node
types.
It defines some common attributes known for all node types, and contains Python magic methods to allow
model traversal.

1-20 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Maagic: Leaf Nodes
Leaf values represented with native Python types:
 string, numeric types, boolean, None
 Writing converts to string using str()

with ncs.maapi.single_write_trans('admin', 'python') as t:

root = ncs.maagic.get_root(t)
device = root.devices.device['c0']
Both of these work;
print device.address
values are first
10.1.2.3 converted to string
device.port = 22
device.port = '22'
When writing data, remember
t.apply()
to commit transaction

Writing data using Maagic is straightforward. You will just specify the leaf you are interested in and assign a
value. Any data type can be sent as input, as the str function is called, converting it to a string. The format is
depending on the data type. If the final type validation fails an Error exception is thrown.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-21
Maagic: Containers, Lists
# Access item in a list (e.g. device)
 List: YANG list
pe_router = root.devices.device['R1']
 Container
# Check if item with given key exists
 YANG container
'R1' in root.devices.device # returns True of False
 List entry
# Create list item (e.g. configure a new service instance)

root.services.l2vpn.create('ACME')
 Presence containers # Properties of list items accessed just like containers
 Create with .create() root.services.l2vpn['ACME'].pw_id = 1000
 Check with .exists() # Access item with a combined key

list_entry = root.some_list['k1', 'k2']

# Remove list item (e.g. deprovision a service instance)

del root.services.l2vpn['ACME']

The Container class has two uses in the high-level Maagic API:
 Refer to YANG container nodes
 Refer to YANG list entries
On a presence container, the create method has effect; otherwise an empty container would be ignored.
Creating or retrieving a list entry with a specified key also returns a Container object.

1-22 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Presence Containers
 YANG containers with statement presence true
 May contain other nodes, like normal container
 Keeps track if container itself is configured (true / false)

container bgp {
description "Enables and configures BGP";
presence true;
leaf as-number { … }
}

admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# bgp # Enable BGP by creating container
admin@ncs(config-bgp)# as-number 65000 # Set a parameter inside container

YANG containers that set presence attribute to true are called presence containers. They differ from other
containers by keeping a special value of their own. This value tracks information if container is configured
(defined), similar to leaf type empty. So the value has only two states; is container present or not.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-23
Maagic: Enumerations and leafrefs
 Enum: YANG enumeration
 Leafref: YANG leaf of type leafref
 Same type as the leaf it is pointing to

root.devices.device['c0'].state.admin_state # Enum object

root.devices.device['c0'].state.admin_state.string # Returns string, e.g. 'unlocked'
root.devices.device['c0'].state.admin_state.value # Returns internal numeric value, e.g. 1

root.services.loopback['test'].device = 'c0' # Use leafref’s target data type, e.g. string

YANG enumerations are accessed with the Maagic API through the Enum class. In that way, it is possible to
read and write values using either strings or integers.
Leafrefs are read as regular leafs and the returned data type corresponds to the referred leaf. Leafrefs are set
as the referred leaf. Data type is validates when setting the value, but the references are only validated when
committing the transaction.

1-24 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Maagic: Actions
 Action objects are callable
 Access input/output data with get_input(), get_output() methods
 Use MAAPI session, not transaction

import ncs
with ncs.maapi.Maapi() as m:
with ncs.maapi.Session(m, 'admin', 'python'):
root = ncs.maagic.get_root(m)
input = root.test_action.get_input()
input.number = 21
output = root.test_action(input)
print(output.result)

YANG RPC operations are accessed through the Action class in Maagic API. The objects of the class are
callable (implement __call__() Python magic method). To supply inputs to the action, first access the input
node tree with the get_input() method on the action, then execute the action with the input parameter. Any
output parameters can be accessed though the output node tree, returned by the get_output() method.
Internally in Cisco NSO, actions are executed using the MAAPI API. A transaction is not always required,
depending on the type of the action.
Below, we provide an example of a script “maagic_create_device.py” used for adding a new Cisco IOS
device into NSO Device Manager. The script also executes actions to fetch the SSH host keys, and sync the
running configuration from the device. A single MAAPI session is opened towards Cisco NSO to make the
changes to the device configuration within a transaction, and execute the actions.
import argparse
import ncs

def parseArgs():
parser = argparse.ArgumentParser()
parser.add_argument('--name', help="device name", required=True)
parser.add_argument('--address', help="device address",
required=True)
parser.add_argument('--port', help="device address", type=int,
default=22)
parser.add_argument('--desc', help="device description",
default="Device created by maagic_create_device.py")
parser.add_argument('--auth', help="device authgroup",
default="default")
return parser.parse_args()

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-25
def main(args):
with ncs.maapi.Maapi() as m:
with ncs.maapi.Session(m, 'admin', 'python'):
with m.start_write_trans() as t:
root = ncs.maagic.get_root(t)
print("Setting device '%s' configuration..." % args.name)
# Get a reference to the device list
device_list = root.devices.device
device = device_list.create(args.name)
device.address = args.address
device.port = args.port
device.description = args.desc
device.authgroup = args.auth
dev_type = device.device_type.cli.create()
dev_type.ned_id = 'cisco-ios'
device.state.admin_state = 'unlocked'

print('Committing the device configuration...')

t.apply()
print("Committed")
# This transaction is no longer valid

#
# fetch-host-keys and sync-from does not require a
transaction # continue using the Maapi object
#
root = ncs.maagic.get_root(m)
device = root.devices.device[args.name]
print("Fetching SSH keys...")
output = device.ssh.fetch_host_keys()
print("Result: %s" % output.result)
print("Syncing configuration...")
output = device.sync_from()
print("Result: %s" % output.result)
if not output.result:
print("Error: %s" % output.info)

if __name__ == '__main__':
main(parseArgs())

1-26 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Maagic: Deleting Data

Delete implemented with delattr() magic method on Node class

del root.devices.device['ce0'] # List element

del root.devices.device['ce0'].name # Leaf

del root.devices.device['ce0'].device_type.cli # Presence container

Note: Deleting a variable with del function will only remove the object from Python namespace!
var_cli_value = root.devices.device['ce0'].device_type.cli # Assign to var_cli_variable variable

del var_cli_value # Removes var_cli_value variable but root.devices.device['ce0'].device_type.cli stays as-is

Data is deleted the Python way of using the del function. Use the function on any maagic Node object to
delete a leaf value, list entry or a container.
Be careful when using del on a single variable – the object will only be removed from the Python local or
global namespace!

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-27
Service Application in Python
 Use ncs-make-package to create package
[cisco@ncs packages]$ ncs-make-package --python-skeleton l2vpn
--component-name L2vpn --service-example

l2vpn
├── package-meta-data.xml
├── python Python code resides in
│ └── l2vpn.py python directory
├── README
├── src
│ ├── Makefile
│ └── yang src/yang directory contains
│ └── l2vpn.yang YANG model definitions
└── templates
└── l2vpn-template.xml

Python service skeleton is created with ncs-make-package. This command creates directory structure that
contains Python code inside python directory and YANG files inside src/yang directory.
Optionally, we can add XML template files to templates directory. These templates can then be used from
Python code.

1-28 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Python Service Application
import ncs, ncs.template
from ncs.application import Service

class ServiceCallbacks(Service):
@Service.create
def cb_create(self, tctx, root, service, proplist):
self.log.info('Service create(service=', service._path, ')')

# Assign specified PW id to a variable

psuedowire_id = service.pw_id

# Set up variables to be exported

tvars = ncs.template.Variables()
tvars.add('VPN-TYPE', 'L2VPN')
tvars.add('PW-ID', psuedowire_id)

# Apply configuration in XML file, making use of exported variables

template = ncs.template.Template(service)
template.apply('l2vpn-template', tvars)
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 25

cb_create method is called for service provisioning. It will contain logging and template instantiation code.

# Tell NSO to run above cb_create() code for our service

class L2vpn(ncs.application.Application):
def setup(self):
self.log.info('L2vpn RUNNING')
self.register_service('l2vpn-servicepoint', ServiceCallbacks)

def teardown(self):
self.log.info('L2vpn FINISHED')

Note: Service code can also be a Python module

 Useful for splitting code into multiple files for complex services

The Python class specified in the package-meta-data.xml file will be started in a Python thread, which we
will call a component thread. Therefore, this class should have an __init__ and run method. The actual code
implementing the service application logic will run in a separate worker thread, called user thread.
The example above extends Application class, which provides all thread management. It creates component
thread and calls setup method. Inside setup we use register_service to specify the code to run in user
threads.
There are two important reasons component thread wants to communicate with the NSO part of the Python
VM:
 Logging: Where to log and with what level can be controlled from Cisco NSO. The user code can get
hold of functions that will log information to the right place and with the chosen level.
 Shutdown: A Python VM will not terminate until all (non daemon) Python threads have terminated. So,
it is important that the NSO can inform the user code that a shutdown should take place.
The communication between the user code and the NSO code is made possible by the NcsPyVM object that
needs to be set up in the __init__ method, as shown in the example on the slide.
By using the self._ncs.reg_finish function, a callback function is registered with NSO. This callback function
will be called when the system is to be shutdown. The NcsPyVM object also contains an unreg_finish
function that can be used to unregister the finish callback function.
For a complete service application example in Python, refer to sample code that is part of Cisco NSO
installation:
examples.ncs/getting-started/developing-with-ncs/17-mpls-vpn-python

1-30 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Demo Example: Python and Template

Create the Loopback Service Package

 Very simple service application using Python + templates.
 Use the ncs-make-package command to create the loopback skeleton:
[user@nso example]$ cd packages/
[user@nso packages]$ ncs-make-package --python-skeleton --service-example --component-
name Loopback loopback

Parameters:
 component-name: name of Python class implementing mapping logic

We will create a very simple service application for configuring an IP address on a loopback interface. Our
service application will consist of a service model (YANG), configuration (XML), and the code in Python to
apply the template.
Start by changing the directory to the current project directory. In the packages subdirectory, run the
ncs-make-package command, to create a service skeleton.

Note The ncs-make-package command can be used for developing other types of packages as well, as can be
seen from the help output:

[user@nso ~]$ ncs-make-package –help

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-31
Designing the Service Model
 Service description: “provide service for operators to set an IP address on a
loopback interface”

Parameter name Type Default value Mandatory

name string x
device leafref x
interface-id string x
ip-address inet:ipv4-address x
network-mask Inet:ipv4-address 255.255.255.255

L loopback

K name R device interface-id ip-address network-mask

We are using the top-down service design methodology. Starting from a service description: “provide a
service for operators to set an IP address on a loopback interface”, we extract the input parameters required
to create a service instance.
The operator will need to specify the device name, loopback interface ID, the new IP address, and optionally,
provide a network mask.
An additional parameter is needed to provide a unique key for the list of loopback services – name. The
result is a tabular list of service input parameters, with defined data types and any additional restrictions/rules
for validation.
In the next step, we have created a graphical representation of the service model – how the YANG file will
be structured.
At the top level, we create a list loopback, with the child leaves name, device, interface-id, ip-address, and
network-mask.

1-32 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Designing the Service Model (Cont.)
module loopback { …
namespace uses ncs:service-data;
"http://com/example/loopback"; ncs:servicepoint
prefix loopback; loopback-servicepoint;
import ietf-inet-types { prefix inet; leaf interface-id {
} mandatory true;
import tailf-common { prefix tailf; } type string;
import tailf-ncs { prefix ncs; } }
leaf ip-address {
augment /ncs:services { mandatory true;
list loopback { type inet:ipv4-address;
description "This is an }
RFS skeleton service"; leaf network-mask {
key name; default 255.255.255.255;
leaf name { type string; } type inet:ipv4-address;
leaf device { }
type leafref { }
path }
"/ncs:devices/ncs:device/ncs:name"; }
}
}
…

The slide displays the complete printout of the loopback service model. We started by opening the skeleton
loopback.yang file, and added the nodes defined in the previous slide.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-33
Creating the XML Template
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# devices device c0 config ios:interface Loopback 0 ip address 1.2.3.4
255.255.255.255
admin@ncs(config-if)# commit dry-run outformat xml
device c0
<interface xmlns="urn:ios">
<Loopback>
<name>0</name>
<ip>
<address>
<primary>
<mask>255.255.255.255</mask>
<address>1.2.3.4</address>
</primary>
</address>
</ip>
</Loopback>
</interface>

In this step, we are going to create the XML configuration template. Use the Cisco NSO CLI to configure a
sample configuration on a device. In this example, we are using a netsim-simulated Cisco IOS device c0.
Finally, after configuration, do not commit the changes, but execute the commit dry-run outformat xml
command to obtain the XML.
The same XML can be used in the configuration template, with parameters.

1-34 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Parametrizing the XML Template
<config-template xmlns="http://tail-f.com/ns/config/1.0">
• Template
<devices API
xmlns="http://tail-f.com/ns/ncs">
<device>
<name>{/device}</name>
<config>
<interface xmlns="urn:ios">
<Loopback>
<name>{/interface-id}</name>
<ip><address>
<primary>
<mask>{$NETMASK}</mask>
<address>{$IP-ADDRESS}</address>
</primary>
</address></ip>
</Loopback>
</interface>
</config>
</device>
</devices>
</config-template>

The XML configuration we obtained in the previous step can be directly used in the templates/loopback.xml
template file. But, to make it universal for all service instances, we must substitute the dummy configuration
values with variables or expressions.
Expressions in an XML template occur inside the curly braces – { … }. The string between the curly braces is
treated as an XPath 1.0 expression. The simplest form of an XPath expression is a plain XPath variable –
{$NETMASK}, for example. Values for the variables must be provided when using the template via the
Template API:
Template myTemplate = new Template(context, "loopback");
TemplateVariables myVars = new TemplateVariables();
myVars.putQuoted(”NETMASK", ”255.255.255.255");
myTemplate.apply(service, myVars);
If the expression does not start with a dollar sign ($), the XPath query is evaluated in the context of the
current service root node (loopback list entry in this example). The expression {/device} therefore evaluates
to the value of the device leaf for the service parameters.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-35
Applying the XML Template
class ServiceCallbacks(Service):
• Template API
# The create() callback is invoked inside NCS FASTMAP and
# must always exist.
@Service.create
def cb_create(self, tctx, root, service, proplist):
self.log.info('Service create(service=', service._path, ')') 1. Read service parameters.

ip_address = service.ip_address
netmask = service.network_mask
tvars = ncs.template.Variables() 2. Provide values for variables.
tvars.add('IP-ADDRESS', ip_address)
tvars.add('NETMASK', netmask)

# service maagic node defines the root for XPath expressions

template = ncs.template.Template(service) 3. Create Template object.
template.apply('loopback-template', tvars)

4. Apply the template.

In this step, we are going to apply the previously created XML template using the Template API in Python.
The final component of our service application is to develop the mapping logic in Python– the cb_create()
method.
The cb_create() method is called every time the transformation from service input parameters to device
configuration is required. The changes performed in the create method – either through the Maagic API, by
applying the template, or some other API – are part of the service device-modifications, and thus part of
FASTMAP.
In the example code, we must load the “loopback.xml” template, and provide the values for the
IP-ADDRESS and NETMASK variables.
Explanation of statements in the slide example:
1. In the first two statements, we use the Maagic API to read the values for the IP address and network
mask from the service parameters, using the service Maagic Node to start the queries. We store the
resulting values in variables. Note that when using Maagic, a node value will be returned using the
appropriate native Python type.

2. In the second two statements, we create an instance of theTemplateVariables class.

3. In the third part, we provide the values for the XPath variables.
4. In the fourth part, we apply the template.

The parameters for the cb_create() method are described in the documentation for the @Service.create
decorator:
"""Decorator for the cb_create callback.
Using this decorator alters the signature of the cb_create callback and passes in maagic.Node objects for root
and service. The maagic.Node objects received in 'root' and 'service' are backed by a MAAPI connection with
the FASTMAP handle attached. To update 'proplist' simply return it from this function.

1-36 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Example of a decorated cb_create:
@Service.create
def cb_create(self, tctx, root, service, proplist):
pass

Keyword arguments:
tctx - transaction context (TransCtxRef)
root -- root node (maagic.Node)
service -- service node (maagic.Node)
proplist - properties (list(tuple(str, str)))
"""

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-37
Testing the Loopback Service
[user@nso example]$ make -C packages/loopback/src/
/Users/markoz/nso-4.2/bin/ncsc `ls loopback-ann.yang > /dev/null 2>&1 && echo "-a
loopback-ann.yang"` \ -c -o ../load-dir/loopback.fxs yang/loopback.yang

[user@nso example]$ pylint --disable=R,C --reports=n packages/loopback/python/loopback.py

No config file found, using default configuration
************* Module loopback
W: 16,49: Access to a protected member _path of a client class (protected-access)

[user@nso example]$ ncs_cli -u admin

admin@ncs# packages reload
reload-result {
package cisco-ios
result true
}
reload-result {
package loopback
result true
}

As a final step, we will test the service application.

Since Python code is not compiled using the instructions in the Makefile, we need to manually check the
syntax. If installed on the development server, the pylint tool can be used for syntax checking and also
conformance to Python style guidelines (PEP8).
We must compile the new service using the prepared skeleton Make file, and load the new package into a test
Cisco NSO instance. The compilation must succeed and the package reload command must return a true
result for all packages before we can proceed.
You can also verify the package status with the show package command at a later stage:
admin@ncs# show packages package loopback
packages package loopback
package-version 1.0
description "Generated Python package"
ncs-min-version [ 4.2 ]
directory ./state/packages-in-use/1/loopback
component loopback
application python-class-name Loopback
application start-phase phase2
oper-status up

1-38 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Testing the Loopback Service (Cont.)
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# services loopback test device c0 interface-id 0 ip-address 1.1.1.1
network-mask 255.255.255.255
admin@ncs(config)# commit dry-run outformat native
device c0
interface Loopback0
ip address 1.1.1.1 255.255.255.255
exit
admin@ncs(config)# commit
Commit complete.

Finally, we can create a test service instance using the CLI.

If the commit command returns an error, it usually means there is an error in the code (create() method). All
Java exceptions (and other logging messages) are logged to ncs-java-vm.log.
If there are no exceptions or errors, but the configuration is missing, you can also use the debug command
when committing: commit | debug template
It will contain debug information related to evaluating the expressions in XML templates. Below is an
example output.
admin@ncs(config)# commit dry-run outformat native | debug template
Evaluating "/device" (from file "loopback.xml", line 4)
Context node: /services/loopback:loopback[name='test']
Result:
For /services/loopback:loopback[name='test'], it evaluates to "c0"
Operation 'merge' on existing node: /devices/device[name='c0'] (from file
"loopback.xml", line 4)
Evaluating "/interface-id" (from file "loopback.xml", line 8)
Context node: /services/loopback:loopback[name='test']
Result:
For /services/loopback:loopback[name='test'], it evaluates to "0"
Operation 'merge' on existing node:
/devices/device[name='c0']/config/ios:interface/Loopback[name='0'] (from
file "loopback.xml", line 8)
Operation 'merge' on non-existing node:
/devices/device[name='c0']/config/ios:interface/Loopback[name='0']/ip/add
ress/primary/address (from file "loopback.xml", line 12)
Evaluating "$IP-ADDRESS" (from file "loopback.xml", line 12)

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-39
Context node: /services/loopback:loopback[name='test']
Result: "1.1.1.1"
Setting
/devices/device[name='c0']/config/ios:interface/Loopback[name='0']/ip/add
ress/primary/address to "1.1.1.1"
Operation 'merge' on non-existing node:
/devices/device[name='c0']/config/ios:interface/Loopback[name='0']/ip/add
ress/primary/mask (from file "loopback.xml", line 13)
Evaluating "$NETMASK" (from file "loopback.xml", line 13)
Context node: /services/loopback:loopback[name='test']
Result: "255.255.255.255"
Setting
/devices/device[name='c0']/config/ios:interface/Loopback[name='0']/ip/add
ress/primary/mask to "255.255.255.255"
device c0
interface Loopback0
ip address 1.1.1.1 255.255.255.255
exit

1-40 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Java NAVU API

NAVU API
 Services need a way to interact with NSO data (API)
 NAVU – Utilities for YANG model navigation in Java
 DOM-based database traversal, like HTML/XML
 Implements lazy data loading
 Minimizes performance impact
 Data loaded on-demand

 Typically services use NAVU when called by FASTMAP

 But NAVU can also be used elsewhere with Cisco NSO

The NAVU API provides a DOM-driven approach to navigate Cisco NSO service and device models. The
main features of the NAVU API are dynamic schema loading at startup and lazy loading of instance data.
The navigation model is based on the YANG language structure. In addition to navigation and reading of
values, NAVU also provides methods to modify the data model. Furthermore, it supports the execution of
actions modeled in the service model.
By using NAVU, it is easy to drill down through tree structures with minimal effort using the node-by-node
navigation primitives. Alternatively, we can use the NAVU search feature. This feature is especially useful
when we need to find information deep down in the model structures.
The service models are loaded at startup and are always the latest version. The models are always traversed
in a lazy fashion; i.e. data is only loaded when it is needed. The reason for this is to minimize the amount of
data transferred between Cisco NSO and the service applications.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-41
NAVU API (Cont.)
 NAVU needs to know two things:
1. How to communicate with Cisco NSO.
2. What is the Root node where actual data starts.

 NavuContext class
 Defines connection to Cisco NSO (type / R/RW / port etc.)
 Already defined when using FastMap

 NavuContainer class
 A representation of a YANG structure, used for navigation
 Root node or module
 A container

This is already provided for you in the service create() / cb_create() method.
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 29

Before you can use the NAVU API, you need to set up two objects, the NavuContext and the root
NavuContainer, where all queries will start from.
NavuContext stores the connection information to Cisco NSO. There are multiple ways of creating the
NavuContext object, depending on the connection type and the need for transactions.
 MAAPI: Provide the constructor with a MAAPI connection, and a transaction handler. You can access
configuration and operational data (nodes marked with config false in the models). All changes made to
the data in the CDB are buffered in a transaction that must either be committed or discarded at the end.
This is the so-called northbound NAVU integration.
 Cdb: Provide the constructor with a Cdb connection. The API will internally create a new CdbSession.
You can access configuration an operational data. All changes made to the data in the CDB are persisted
as they happen—note that this means that during an open Cdb connection, the CDB is locked. This is the
so-called eastbound integration.
 CdbSession: Provide the constructor directly with a CdbSession.
Note that these two objects are already set up when using NAVU in your service application in the create()
method.

The most important classes of NAVU are the classes implementing the YANG node types. These are used to
navigate the DOM. These classes are as follows:
 NavuContainer: The NavuContainer is a container representing either the root of model, a YANG
module root, or a YANG container.
 NavuList: The NavuList represents a YANG list node.
 NavuListEntry: A list node entry.
 NavuLeaf: The NavuLeaf represents a YANG leaf node.

1-42 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
NAVU Basics
 NAVU maps all YANG data nodes into corresponding classes.
 Starts from root NavuContainer and selects elements from YANG hierarchy.
module root { NavuContainer bgpConfig =
... root.container("bgp");
container bgp { These two
leaf as-number { … } bgpConfig.leaf("as-number");
statements
list neighbor { root.container("bgp")
key name; .leaf("as-number"); are the same.
leaf name {
type string; bgpConfig.list("neighbor")
} .elem("Core-02")
leaf ip { .leaf("ip");
type inet:ip-address; NAVU checks
} existence of
} list items.
...
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 30

When using NAVU, the navigation starting point is usually the root container. From there, NAVU can
navigate through YANG nodes and check existence of keys. Traversing the elements does not mean that the
values get collected.
To actually retrieve the value of the leaf in the example, you would have to call the value() or
valueAsString() method on the resulting NavuLeaf.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-43
NAVU Basics (Cont.)
 NavuContainer is used to represent both the container and single list item.
 Also used for modules.
 NavuList is used to represent a list.
 NavuLeaf is used to represent a leaf.
 NavuNode is used to navigate through the YANG model tree.
 Same as Python Node.

YANG model(s) Java Code

module tailf-ncs { ...
namespace "http://tail- // This obtains the NSO root container
f.com/ns/ncs"; NavuContainer ncsRoot = new NavuContainer(ctxt)
... .container(new Ncs().hash());
}
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 31

When navigating using NAVU, we always start from the top by creating a NavuContainer. The
NavuContainer resembles the YANG container node type. It is also used to represent the YANG module.
NAVU maps the YANG node types; container, list, leaf, and leaf-list into its own structure. NavuContainer
is used to represent both the module and the container node type. The NavuListEntry is also used to represent
a list node instance.
To read and update a leaf, we simply navigate to the leaf and request the value. We can update the value in
the same manner.

1-44 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
NAVU Node Access: Direct
YANG model(s) Java Code
module tailf-ncs { // Selecting nodes by name
... NavuContainer edge_router_device =
container devices { ncsRoot.container("devices")
list device { .list("device")
key name; .elem("PE12");
leaf name {
type string; // Selecting nodes by namespace class
} edge_router_device =
... ncsRoot.container(Ncs._devices_)
} .list(Ncs._device_)
} .elem("PE12");

There are multiple ways of traversing the DOM exposed by NAVU. The most straightforward one is by
directly specifying the full list of nodes (see previous example).
If the purpose is, for example, to directly access a list node, we would typically do a direct navigation to the
list element using the NAVU primitives.

When referencing nodes in the data tree, we have two options:

 Named nodes
 Precompiled namespace classes
In the first example in the figure, nodes in the data model are referenced by type and string name. As a result,
the compiler cannot check the validity of the node type nor the existence of the node based on the name. If a
coding error is generated, it will only be picked up at run time.
In the second example, we use the namespace classes generated by the ncsc compiler. Some of these
namespace classes have been precompiled. By using the namespace classes, you get a less error-prone code.
If some of the nodes in your model are changed, it will be reflected on the ncsc-generated classes at compile
time leading to compile time errors. Thus, we can refer to the YANG container in the tailf-ncs.yang module
as x.container(Ncs._type_) instead of as x.container("type").

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-45
NAVU Node Access: Development and Troubleshooting

 String names: Wrong Wrong

NavuList managedDevices = ncsRoot.container("XYdevices").container("device");

cisco@NCS:~/ncs-run/packages/l3mplspvn/src$ make
cd java && ant -q all

BUILD SUCCESSFUL Not detected by compiler.

Total time: 1 second
cisco@NCS:~/ncs-run/packages/l3mplspvn/src$

 Wrong node names and node types do not result in compilation errors.
 Errors will be picked up at run time.

The example illustrates how we may not be able to quickly detect an error if we use names to reference
nodes.

1-46 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
NAVU Node Access: Development and Troubleshooting
(Cont.)
 Precompiled classes: Wrong Wrong
NavuList managedDevices = ncsRoot.container(Ncs._XYdevices_).container(Ncs._device_);

cisco@NCS:~/ncs-run/packages/l3mplspvn/src$ make
cd java && ant -q all
[javac] /home/cisco/ncs-3.3/ncs-run/…/l3mplspvn/l3mplspvnRFS.java:77: error: cannot find symbol
[javac] NavuList managedDevices = ncsRoot.container(Ncs._XYdevices_).container(Ncs._device_);
[javac] symbol: variable _XYdevices_
[javac] location: class Ncs
[javac] 1 error
Compiler indicates
location of mistake.
BUILD FAILED
/home/cisco/ncs-3.3/ncs-run/packages/l3mplspvn/src/java/build.xml:45: Compile failed; see the
compiler error output for details.

Total time: 1 second

make: *** [javac] Error 1
cisco@NCS:~/ncs-run/packages/l3mplspvn/src$

If, however, we use precompiled namespace classes, we will be able to spot an error earlier than it will be
provided by the compiler.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-47
NAVU Node Access: Development and Troubleshooting
(Cont.)
 Precompiled classes: Wrong
NavuList managedDevices = ncsRoot.container(Ncs._devices_).container(Ncs._device_);

BUILD FAILED
/home/cisco/ncs-3.3/ncs-run/packages/l3mplspvn/src/java/build.xml:45: Compile failed; see
the compiler error output for details.

Total time: 1 second

make: *** [javac] Error 1
cisco@NCS:~/ncs-run/packages/l3mplspvn/src$

The compiler will not only allow us to determine that there is a coding error but it will also suggest the
correct node type.

1-48 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
NAVU Node Access: Select
YANG model(s) Java Code
module tailf-ncs { // Node from which we start select
... NavuContainer devices =
container devices { ncsRoot.container("devices");
list device {
key name; // Selecting nodes by select()
leaf name { for (NavuNode node: devices.select("dev.*/.*"))
type string; {
} NavuContainer router = (NavuContainer)node;
... }
} // Selecting nodes by xPathSelect()
} for (NavuNode node:
devices.xPathSelect("device/*"))
{
NavuContainer router = (NavuContainer)node;
}

If we know what we want, we use direct access. If we want to apply something to a large amount of nodes,
we use select(). An alternative method is to use the xPathSelect(), where an XPath query could be issued
instead.
If the purpose is to drill down deep into a structure, we should use the select() method. The select() offers a
wild-card-based search, using a regular expression. The search is relative and can be performed from any
node in the structure.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-49
Setting Up NAVU
 Create NavuContext with NAVU system root container (superRoot).
 Select module with all NSO configuration (ncsRoot).
 Also called schema root.

// Create container with Maapi session

NavuContainer superRoot = new NavuContainer(new NavuContext(maapi, th));

// OR

// Create container with CDB session

NavuContainer superRoot = new NavuContainer(new NavuContext(cdb));

// Finally create container that is the schema root

NavuContainer ncsRoot = superRoot.container(new Ncs().hash());

FastMap logic is not the only place where NAVU is useful. Any Java code that interacts with Cisco NSO can
utilize the power of NAVU.
However, in order to use NAVU outside FastMap, it needs to be configured. Context and Root must be
defined.

1-50 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Demo Example: Java and Template

Create the Loopback Service Package

 Very simple service application using Java + templates.
 Use the ncs-make-package command to create the loopback skeleton:
[user@nso example]$ cd packages/
[user@nso packages]$ ncs-make-package --service-skeleton java-and-template loopback

 Prepare the Eclipse project (optional).

[user@nso example]$ ncs-setup --eclipse-setup
Generate /private/tmp/example/.project
Generate /private/tmp/example/.classpath

We will create a very simple service application for configuring an IP address on a loopback interface. Our
service application will consist of a service model (YANG), configuration (XML), and the code in Java to
apply the template.
Start by changing the directory to the current project directory. In the packages subdirectory, run the
ncs-make-package command, to create a service skeleton.

Note The ncs-make-package command can be used for developing other types of packages as well, as can be
seen from the help output:

[user@nso ~]$ ncs-make-package –help

Usage: ncs-make-package [options] package-name
ncs-make-package --netconf-ned DIR package-name
ncs-make-package --snmp-ned DIR package-name
ncs-make-package --service-skeleton [java | template | java-and-
template] package-name
ncs-make-package --data-provider-skeleton package-name
ncs-make-package --generic-ned-skeleton package-name
After the skeleton package is created, you can verify and examine the files and folders using the ls command.
In the next step, we are going to prepare the development environment (Eclipse). This step is completely
optional, as you can edit the YANG and Java source files with any text editor. By using an IDE with support
for the languages as opposed to a regular text editor, we get more advanced functionalities, like syntax
checking and proper formatting.
Change the directory back to the project running directory, and execute the ncs-setup –eclipse-setup
command. This will prepare the Eclipse project files, enabling you to directly import the project into Eclipse.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-51
Designing the Service Model
 Service description: “provide service for operators to set an IP address on a
loopback interface”

Parameter name Type Default value Mandatory

name string x
device leafref x
interface-id string x
ip-address inet:ipv4-address x
network-mask Inet:ipv4-address 255.255.255.255

L loopback

K name R device interface-id ip-address network-mask

We are using the top-down service design methodology. Starting from a service description: “provide a
service for operators to set an IP address on a loopback interface,” we extract the input parameters required
to create a service instance.
The operator will need to specify the device name, loopback interface ID, the new IP address, and optionally,
provide a network mask.
An additional parameter is needed to provide a unique key for the list of loopback services – name. The
result is a tabular list of service input parameters, with defined data types and any additional restrictions/rules
for validation.
In the next step, we have created a graphical representation of the service model – how the YANG file will
be structured.
At the top level, we create a list loopback, with the child leaves name, device, interface-id, ip-address, and
network-mask.

1-52 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Designing the Service Model (Cont.)
module loopback { …
namespace uses ncs:service-data;
"http://com/example/loopback"; ncs:servicepoint
prefix loopback; loopback-servicepoint;
import ietf-inet-types { prefix inet; leaf interface-id {
} mandatory true;
import tailf-common { prefix tailf; } type string;
import tailf-ncs { prefix ncs; } }
leaf ip-address {
augment /ncs:services { mandatory true;
list loopback { type inet:ipv4-address;
description "This is an }
RFS skeleton service"; leaf network-mask {
key name; default 255.255.255.255;
leaf name { type string; } type inet:ipv4-address;
leaf device { }
type leafref { }
path }
"/ncs:devices/ncs:device/ncs:name"; }
}
}
…

The slide displays the complete printout of the loopback service model. We started by opening the skeleton
loopback.yang file, and added the nodes defined in the previous slide.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-53
Creating the XML Template
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# devices device c0 config ios:interface Loopback 0 ip address 1.2.3.4
255.255.255.255
admin@ncs(config-if)# commit dry-run outformat xml
device c0
<interface xmlns="urn:ios">
<Loopback>
<name>0</name>
<ip>
<address>
<primary>
<mask>255.255.255.255</mask>
<address>1.2.3.4</address>
</primary>
</address>
</ip>
</Loopback>
</interface>

1-54 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Parametrizing the XML Template
<config-template xmlns="http://tail-f.com/ns/config/1.0">
• Template
<devices API
xmlns="http://tail-f.com/ns/ncs">
<device>
<name>{/device}</name>
<config>
<interface xmlns="urn:ios">
<Loopback>
<name>{/interface-id}</name>
<ip><address>
<primary>
<mask>{$NETMASK}</mask>
<address>{$IP-ADDRESS}</address>
</primary>
</address></ip>
</Loopback>
</interface>
</config>
</device>
</devices>
</config-template>

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-55
Applying the XML Template
@ServiceCallback(servicePoint
• Template API = "loopback-servicepoint", callType = ServiceCBType.CREATE)
public Properties create(ServiceContext context, NavuNode service, NavuNode ncsRoot,
Properties opaque) throws ConfException
1. Read service parameters.
{
String ipAddress = service.leaf(loopback._ip_address_).valueAsString();
String netmask = service.leaf(loopback._network_mask_).valueAsString();

Template myTemplate = new Template(context, "loopback");

TemplateVariables myVars = new TemplateVariables(); 2. Create Template object.

try {
myVars.putQuoted("IP-ADDRESS", ipAddress);
myVars.putQuoted("NETMASK", netmask);
3. Provide values for variables.
myTemplate.apply(service, myVars);
} catch (Exception e) {
throw new DpCallbackException(e.getMessage(), e);
} 4. Apply the template.
return opaque;
}

In this step, we are going to apply the previously created XML template using the Template API in Java. The
final component of our service application is to develop the mapping logic in Java – the create() method.
The create() method is called every time the transformation from service input parameters to device
configuration is required. The changes performed in the create method – either through the NAVU API, by
applying the template, or some other API – are part of the service device-modifications, and thus part of
Fastmap.
In the example code, we must load the “loopback.xml” template, and provide the values for the
IP-ADDRESS and NETMASK variables.
Explanation of statements in the slide example:
1. In the first two statements, we use the NAVU API to read the values for the IP address and network mask
from the service parameters, using the service NavuNode to start the NAVU queries. We store the
resulting values in String variables. Note that when using NAVU, a node value can always be read as a
string, but often times, it may be beneficial to use a more specific data type. Consult the javadoc for the
description of the ConfValue class and its subclasses.

2. In the second two statements, we create instances of the Template and TemplateVariables classes.
3. In the third part, we provide the values for the XPath variables.
4. In the fourth part, we apply the template.

The parameters for the create method are described in the javadoc:
/**
* Create callback method. This method is called when a service instance
* committed due to a create or update event.
*
* This method returns a opaque as a Properties object that can be null. If
* not null it is stored persistently by Ncs. This object is then
delivered

1-56 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
* as argument to new calls of the create method for this service (fastmap
* algorithm). This way the user can store and later modify persistent data
* outside the service model that might be needed.
*
* @param context
* - The current ServiceContext object
* @param service
* - The NavuNode references the service node.
* @param ncsRoot
* - This NavuNode references the ncs root.
* @param opaque
* - Parameter contains a Properties object. This object may be
* used to transfer additional information between consecutive
* calls to the create callback. It is always null in the first
* call. I.e. when the service is first created.
* @return Properties the returning opaque instance
* @throws ConfException
*/

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-57
Testing the Loopback Service
[user@nso example]$ make -C packages/loopback/src/
/tmp/nso-4.1/bin/ncsc `ls loopback-ann.yang > /dev/null 2>&1 && echo "-a loopback-
ann.yang"` \
--yangpath yang -c -o ../load-dir/loopback.fxs yang/loopback.yang
/tmp/nso-4.1/bin/ncsc --java-disable-prefix --exclude-enums --fail-on-warnings --java-
package com.example.loopback.namespaces --emit-java
java/src/com/example/loopback/namespaces/loopback.java ../load-dir/loopback.fxs
cd java && ant -q all
BUILD SUCCESSFUL
Total time: 1 second
[user@nso example]$ ncs_cli -u admin
admin@ncs# packages reload
reload-result {
package cisco-ios
result true
}
reload-result {
package loopback
result true
}

As a final step, we will test the service application.

We must compile the new service using the prepared skeleton Make file, and load the new package into a test
Cisco NSO instance. The compilation must succeed and the package reload command must return a true
result for all packages before we can proceed.
You can also verify the package status with the show package command at a later stage:
admin@ncs# show packages package loopback
packages
package loopback
package-version 1.0
description "Skeleton for a java- and template-based resource facing
service”
ncs-min-version [ 3.0 ]
directory ./state/packages-in-use/1/loopback
templates [ loopback ]
component RFSSkeleton
callback java-class-name [ com.example.loopback.loopbackRFS ]
oper-status up

1-58 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Testing the Loopback Service (Cont.)
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# services loopback test device c0 interface-id 0 ip-address 1.1.1.1
network-mask 255.255.255.255
admin@ncs(config)# commit dry-run outformat native
device c0
interface Loopback0
ip address 1.1.1.1 255.255.255.255
exit
admin@ncs(config)# commit
Commit complete.

Finally, we can create a test service instance using the CLI.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-59
Context node: /services/loopback:loopback[name='test']
Result: "1.1.1.1"
Setting
/devices/device[name='c0']/config/ios:interface/Loopback[name='0']/ip/add
ress/primary/address to "1.1.1.1"
Operation 'merge' on non-existing node:
/devices/device[name='c0']/config/ios:interface/Loopback[name='0']/ip/add
ress/primary/mask (from file "loopback.xml", line 13)
Evaluating "$NETMASK" (from file "loopback.xml", line 13)
Context node: /services/loopback:loopback[name='test']
Result: "255.255.255.255"
Setting
/devices/device[name='c0']/config/ios:interface/Loopback[name='0']/ip/add
ress/primary/mask to "255.255.255.255"
device c0
interface Loopback0
ip address 1.1.1.1 255.255.255.255
exit

1-60 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
MAAPI Changes

Java MAAPI Changes

 Full support for writable-oper transaction in MAAPI
 Deprecates NavuContext(cdbSession)
Existing MAAPI session
NavuContext operCtx = new NavuContext(cdbSession);
NavuContext operCtx = new NavuContext(maapi);

operCtx.startOperationalTrans(Conf.MODE_READ_WRITE);

NavuContainer cdbRoot = new NavuContainer(operCtx).container(Ncs.hash);

// /services/l2vpn{first}/pw-id is an operational (persistent) leaf Set operational leaf

cdbRoot.container("services").list("l2vpn").elem("first").leaf("pw-id").set("123");;

operCtx.applyClearTrans();

Apply transaction

A significant Java API change in NSO 4.2 allows starting writable-oper transactions using MAAPI.
The example on the slide shows the new approach to working with operational data with NAVU. Start with
an existing MAAPI session, and instantiate a new NavuContext. On this context, execute the
startOperationalTrans, to access the operational datastore. Afterwards, continue with NAVU usage (set up
schema root, access operational data).
At the end, execute the applyClearTrans() method on the context. The method will apply any changes in the
transaction and finish it. If the operational transaction was started in read-only mode, the method to finish is
finishClearTrans().
As a result of this API change, the NavuContext(Cdb cdbSession) was deprecated.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-61
Python MAAPI Improvements
 Support for starting MAAPI operational transactions
 Can use Maagic on top of transaction

import ncs
with ncs.maapi.single_write_trans('admin', 'system', db=ncs.OPERATIONAL) as t:
t.set_elem('123', '/test/some-oper-data')
t.apply()

The Python high-level MAAPI API also allows starting read and read-write operational transactions. On top
of the started transaction, you can also use Maagic to work with the dat

1-62 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Summary
This topic summarizes the key points that were discussed in this lesson.
 Service applications not only provide configurations, but complete service lifecycle management.
 A service catalog comprises customer-facing services, which define an interface to the northbound users.
 Complex service behavior is implemented in code with Python Maagic API or Java NAVU API.
 The NAVU and Maagic API provide a mechanism to navigate the service and device models.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-63
1-64 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Lesson 1-2

Layer 3 MPLS VPN Service

Design
Overview
During service lifetime, it may become necessary to update the service with either new configuration or new
functionality. In this lesson, we discuss service upgrade, as well as service migration, with the help of Layer
3 MPLS VPN service we design.

Objectives
Upon completing this lesson, you will be able to meet these objectives:
 Design Layer 3 MPLS VPN service and device models using Cisco NSO
 Use service create callbacks to implement service mapping logic
 Understand different design patterns for services
 Migrate an existing service to Cisco NSO
 Implement service upgrade procedures

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-65
Virtual Private Networks
 VPNs replace dedicated point-to-point links with emulated point-to-point links
that share a common infrastructure.
 Customers use VPNs primarily to reduce their operational costs when
interconnecting their sites.

Customer Site A PE Devices Customer Site C

P Core
CE Router Devices CE Router

PE Router PE Router
Customer Site B Customer Site D
P Router

CE Router CE Router

Virtual Private Networks (VPNs) were introduced very early in the history of data communications with
technologies such as Frame Relay, which uses virtual circuits (VCs) to establish the end-to-end connection
over a shared service provider infrastructure. Although Frame Relay is sometimes considered obsolete, it still
shares these basic benefits with modern VPNs:
 The dedicated links of traditional router-based networks have been replaced with a common
infrastructure that emulates point-to-point links for the customer, resulting in statistical sharing of the
service provider infrastructure.
 Statistical sharing of the infrastructure enables the service provider to offer connectivity at a lower price,
resulting in lower operational costs for the end user. The figure shows the statistical sharing, where the
customer premises equipment (CPE) router on the left has one physical connection to the provider edge
(PE) device and two VCs have been provisioned. VC 1 provides connectivity to the top CPE router on
the right. VC 2 provides connectivity to the bottom CPE router on the right.

1-66 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
VPN Terminology
Customer Site PE Devices Large Customer Site

P Core Devices

Other
PE CE
Customer
Router Router Routers
P Router
CE Router

P device: The device in the provider network with no

customer connectivity
PE device: The device in the provider network to which the
customer devices are connected
CE device: The device in the customer network that links
to the provider network (sometimes also called CPE)
PE-CE link: A link between a PE router and a CE router.
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 4

Here is a description of the devices that enable the overall VPN solution. The devices are named based on
their position in the network:
 P device: Service provider devices that provide only data transport across the service provider backbone,
and have no customers that are attached to them, are called provider devices (P devices). In traditional
switched WAN implementations, these devices would be core (or transit) switches. In a Multiprotocol
Label Switching (MPLS) implementation, these devices would be label switch routers (LSRs).
 PE device: Service provider devices to which customer devices are attached are called PE devices. In
traditional switched WAN implementations, these devices would be Frame Relay or X.25 edge switches.
In an MPLS implementation, these devices would be edge LSRs.
 CE device: The customer router that connects the customer site to the service provider network is called
a customer edge (CE) router, or CE device. Traditionally, this device is called CPE.
 PE-CE link: A link between a PE router and a CE router.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-67
Advantages of MPLS VPNs
 Cost savings:
 Replacing expensive long-distance leased lines with much less expensive dedicated
connection to the service provider (DSL, fiber).
 Offloading support costs.
 Scalability:
 Adding a new branch office is fast and simple by adding an additional link to the ISP (adding a
site to the customer VPN).
 Edge PE routers carry a separate set of routes for each customer (similar to the dedicated PE
router approach).
 Core P routers do not have customer route information.

VPNs give an organization the advantage of creating secure channels of communication while at the same
time reducing costs, improving security, increasing performance, and providing greater access to remote
users:
 Cost savings: Dedicated circuits (leased lines) are quite expensive, so replacing leased lines with a much
less expensive dedicated connection to the service provider can significantly decrease costs.
 Scalability: A company with two branch offices can deploy just one dedicated line to connect the two
locations. If a third branch office needs to come online, two additional lines will be required to directly
connect that location to the other two. However, by adding more branch offices to the network, the
number of leased lines increases dramatically (four branch offices require six lines for full connectivity;
five offices require ten lines, and so on). VPNs avoid this problem by simply adopting one link to ISP per
branch office.
An MPLS-enabled core and edge network provides a very fast and efficient data switching environment
based on MPLS labels.
PE routers exchange routing information with customer CE routers and use separate isolated routing tables
for each customer. Special routing protocol contexts are used for route exchange between PE and CE routers.
Routes are then exchanged between PE devices using the Multiprotocol BGP (MP-BGP) routing algorithm.
For scalability reasons, service provider core routers do not have any customer routing information. PE
routers label packets with MPLS labels and P routers use these labels for fast label-switching packets.

1-68 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Layer 3 MPLS VPN Operation
Customer Site A PE Devices Customer Site C

P Core
CE Router Devices CE Router

PE Router PE Router
Customer Site B Customer Site D
P Router

CE Router CE Router

 CE routers route traffic to PE routers.

 Each customer has its own isolated routing table instance on a PE router.
 PE routers guarantee optimum routing between sites, using label switching.
 Customers can use overlapping addresses.
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 6

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-69
Layer 3 MPLS VPN Service Design Overview
 Service Design
 Service Model
 Mapping Logic

 Service Deployment
 Service Migration Manage Plan
 Service Upgrade

Build

This lesson will cover not just the service design and implementation but also some other common aspects of
a service lifecycle such as service migrations and upgrades.

1-70 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
L3 MPLS VPN
Service Design
This topic describes the high-level overview of Layer-3 MPLS VPN service design for NSO.

Sample Layer 3 MPLS VPN Service Overview

Characteristics of Layer 3 MPLS VPNs:

 Any-to-any connectivity between sites of the same VPN.
 Customers can use any addressing inside their VPN.
 A set of routing options is available to customers (e.g. BGP, static).
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 9

The most basic definition of a Layer-3 MPLS VPN is that a service provider ensures any-to-any connectivity
to all sites belonging to the same VPN on OSI Layer 3 (i.e. IP). The figure illustrates four sites of VPN
VPNA that are interconnected across a service provider network by using Multiprotocol Label Switching
(MPLS) Virtual Private Network (VPNs) technology.
Typically, it is up to the customer to decide what IP addressing will be used inside the VPN although it is
also common for the service provider to determine the addressing (in agreement with the customer) of the
links connecting customer edge (CE) and provider edge (PE) routers.
Additionally, service providers can support multiple routing options that a customer can choose from in order
to ensure any-to-any routing. Typical examples of routing options are BGP (eBGP), OSPF, RIPv2, or static
routing.

Routing IP Device

Interface RD & RT

ACME

Customer Service instance

The figure illustrates the technical parameters and metadata describing an MPLS VPN service instance,
which includes at least the following:
 Customer
 Service instance identifier (e.g. name)
 Route distinguisher(s) and route target(s)
 PE-CE links that consist of multiple parameters:
— PE device
— Interface on the PE device
— IP subnet on the link
— VLAN (optional)
— Routing option

1-72 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cisco NSO is Never the Only Management System
TM Forum Business Process Framework (eTOM) Operations
Operations Support Fulfillment Assurance Billing
and Readiness
Strategy Infrastructure & Product

Customer Most NSO deployments require integration

Order
Relationship BSS with other systems to comply with SP's
Handling
Management
operations and business processes.
Service
Service Management Service Monitoring
Management
Service Inventory Service Reporting
and Operations
OSS OSS
NSO
Resource
Management Resource Allocation
and Operations and Configuration
Supplier & Partner
Relationship
Management

Every service provider has a variety of systems that support business and operations processes. The figure
illustrates the TM Forum's Business Process Framework (eTOM), which tries to consolidate and describe the
different functions that may be present in a service provider environment in order to support the business
processes. A number of operations support systems (OSS) and business support systems (BSS) may be
present in the environment and Cisco NSO will be required to integrate with a few of them in order to
provide for the necessary functions.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-73
Source of Service Parameters
Resource
Inventory
Routing IP Device

Interface RD & RT

ACME

Customer Service instance

 NSO service parameters must be
Service
CRM Inventory in sync with other systems
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 12

A service provider may have an existing system that controls the allocation of virtual/logical resources to
customers. In the case of Layer 3 MPLS VPNs, that may include the following, among others:
 Numbering scheme for RD and RT
 Numbering scheme for VLANs
 Addressing scheme for PE-CE links
 Interface allocation
 Site SLA allocation (e.g. bandwidth allocation)
These systems may have to be reused and Cisco NSO can be integrated with them in order to maintain the
existing processes and procedures for service instance management, billing, reporting, etc.

1-74 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cisco NSO Framework
 Cisco NSO roles:
 Configuration management using network-wide transactions.
 Integration with other systems according to SP's business processes.

 Cisco NSO framework enables easy and flexible interaction with other systems.
 Service, Transaction, and/or Data callbacks can be used to integrate with
external data providers.

Cisco NSO plays two major roles:

 Configuration management using network-wide transactions is the primary role of Cisco NSO.
 Integration with other systems according to SP's business processes is the necessary addition to the task
of designers and implementers.
Some of the capabilities of Cisco NSO will be covered in this lesson: Service, Transaction, and Data
callbacks.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-75
Data Providers
 For operational data stored outside Cisco NSO.
 Responsible for providing data to Cisco NSO on request:
 Data not stored in Cisco NSO.
 Fetched only when asked for.

Model

NSO Mux
Java application

callback Java application

get_elem
Java application

The data provider (DP) API makes it possible to create callback hooks, which are called when certain events
occur in Cisco NSO. As the name of the API indicates, it is possible to write data provider callback hooks
that provide data to Cisco NSO that is stored externally. However, this is only one of several callback types
that this API provides.
By default, Cisco NSO stores all configuration data in its CDB data store. We may wish to store and
configure other data in NSO than what is defined by the NSO built-in YANG models. Alternatively, we may
wish to store parts of Cisco NSO tree outside Cisco NSO (CDB)—i.e. in an external database. Say, for
example, that we have our customer database stored in a relational database outside the NSO. To implement
this, we must do a number of things: We must define a callpoint somewhere in the configuration tree, and we
must implement what is referred to as a data provider. Also Cisco NSO executes all configuration changes
inside transactions and if we want Cisco NSO (CDB) and our external database to participate in the same
two-phase commit transactions, we must also implement a transaction callback. Altogether, it will appear as
if the external data is part of the overall Cisco NSO configuration, so the service model data can refer directly
to this external data – typically in order to validate service instances.
The basic idea for a data provider is that it participates entirely in each Cisco NSO transaction, and it is also
responsible for reading and writing all data in the configuration tree below the callpoint. Before explaining
how to write a data provider and what the responsibilities of a data provider are, we must explain how Cisco
NSO transaction manager drives all participants in a lock-step manner through the phases of a transaction.

1-76 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Data Provider Example
 Define a part of the model to provide data for.
container work { @DataCallback(callPoint=work.callpoint_workPoint,
tailf:callpoint workPoint; callType=DataCBType.GET_ELEM)
list item { public ConfValue getElem(DpTrans trans, ConfObject[] keyPath)
key key; throws DpCallbackException {
leaf key { ConfInt32 kv = (ConfInt32)
type int32; ((ConfKey)keyPath[1]).elementAt(0);
}
Item i = MyDb.findItem( kv.intValue() );
leaf title {
if (i == null) return null; // not found
type string;
} // switch on xml elem tag
leaf responsible { ConfTag leaf = (ConfTag) keyPath[0];
type string; switch (leaf.getTagHash()) {
} case work._key:
leaf comment { return new ConfInt32(i.key);
type string; ...
} case work._comment:
} return new ConfBuf(i.comment);
} default:
throw new DpCallbackException("xml tag not handled");
}
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 15

Note the callpoint directive in the model. It indicates that an external Java callback must register itself using
that name. That callback will be responsible for all data below the callpoint.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-77
Data Provider Transaction States and Callbacks
 CallPoint determines the NAVU
Start finish()
location in the configuration tree.
init()
get_next()  CallType determines the callback
get_elem() Read
type:
trans_unlock() trans_lock()
get_next()  INIT
get_elem() Validate  TRANS_LOCK
write_start()  TRANS_UNLOCK
set_elem()
create() Write  PREPARE
remove()
prepare()  ABORT
 COMMIT
Prepared
 FINISH State
commit() abort()
transaction_callback()
Commit Abort data_callback()
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 16

By default, Cisco NSO stores all configuration data in its CDB data store. We may wish to store and
configure other data in NSO than what is defined by the NSO built-in YANG models. Alternatively we may
wish store parts of the NSO tree outside NSO (CDB)—i.e. in an external database. Say, for example, that we
have our customer database stored in a relational database disjunct from NSO. To implement this, we must
do a number of things: we must define a callpoint somewhere in the configuration tree, and we must
implement what is referred to as a data provider. Also, NSO executes all configuration changes inside
transactions and if we want NSO (CDB) and our external database to participate in the same two-phase
commit transactions we must also implement a transaction callback. All together it will appear as if the
external data is part of the overall NSO configuration, thus the service model data can refer directly into this
external data - typically in order to validate service instances.
The figure above illustrates the two sets of callbacks and the transitions in the transaction state machine:
 Transaction callbacks
 Data provider callbacks

1-78 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Example: DP + SQL
NSO Transaction
 Cisco NSO transactions can be
Start finish() mapped to external transactions
init() (SQL transactions in the example).
get_next()
get_elem() Read
trans_unlock() trans_lock()
get_next()
get_elem() Validate
BEGIN;
write_start() INSERT INTO "public"."Services" ("CustomerID","ServiceID")
set_elem() VALUES (5,3)
create() Write
remove()
prepare()

Prepared
COMMIT; commit() abort() ABORT;

Commit Abort
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 17

The figure illustrates how we can hook the required callbacks in order to map the Cisco NSO transaction and
data handling logic into the logic of an external system – a transaction SQL in the example. Note that the
figure does not illustrate the number of other callbacks that must be implemented in order to cover any
possible data handling scenario in Cisco NSO.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-79
Service Parameter Acquisition Customer:
IP:
ACME
172.31.5.64/30
Example 1 RD&RT:
VLAN:
1:100357
357
1.
2.

Devices: PE10, PE11, … OSS Inventory

Interfaces: Gi1/0/0/10-20, … 2. 3. DB
Customer: ACME
IP: 172.31.5.64/30
4. RD&RT: 1:100357
Deploy VLAN: 357
Device: PE21
NSO Interface: GigabitEthernet1/0/0/12.357

1. Operator initiates service instance deployment through an existing OSS.

2. OSS allocates:
 Parameters from inventory databases: customer, IP subnet, RD & RT number, VLAN number, BW, etc.
 Selection options from Cisco NSO: interfaces, routing options, etc.
OSS responsible for creations, modifications, and deletions in inventory
3. Operator submits service instance deployment request.
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 18

When integrating Cisco NSO into an existing environment that includes OSS, network management system
(NMS) and other systems, we can take several approaches. The figure illustrates an approach with a
minimum involvement of Cisco NSO in the existing environment, especially when dealing with existing
inventories. Given an environment where the OSS is already integrated with other systems, it may be easier
to make use of this integration for all service parameters that are required to be allocated and tracked in the
inventory database. This allows the OSS to pass the required attributes to Cisco NSO, which is simply
responsible for service instance deployment using network-wide transactions.
The limitation of this approach is that the allocation, modification, and de-allocation of parameters is
implemented through the OSS (i.e. it may be more complex than doing it through Cisco NSO).

1-80 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Parameter Acquisition
Example 2
1.

Customer: ACME
Devices: PE10, PE11, … OSS IP: 172.31.5.64/30
Interfaces: Gi1/0/0/10-20, … 2. 3. RD&RT: 1:100357
VLAN: 357
5. 4.
Deploy

NSO Inventory
DB
1. Operator initiates service instance deployment through an OSS.
2. OSS retrieves service selection options from Cisco NSO: interfaces, routing, …
3. Operator submits service instance deployment request.
4. Cisco NSO allocates additional service parameters from inventory; NSO is responsible for
creations, modifications and deletions in inventory.
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 15

An alternative approach is to make Cisco NSO control the allocation, modification, and de-allocation of
service instance parameters. This means that the OSS simply needs to have good integration with Cisco
NSO, while Cisco NSO handles all the complexities of service instance creation, modification, or deletion,
including external repositories.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-81
Example 1 Example 2 Combination
 OSS ensures  OSS requires smart  Reuse existing
configuration user interface functionality of OSS
consistency across integration with and its integration
OSS and NMS NSO. with other systems.
systems.
 NSO ensures  Implement everything
 NSO ensures configuration else/new in NSO.
configuration consistency across
 OSS complexity: low
consistency with all stakeholders
devices. (devices, OSS and  NSO complexity: low
NMS systems). to medium
 OSS complexity: high
 OSS complexity: low
 NSO complexity: low
 NSO complexity:
medium
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 16

Depending on the requirements and capabilities, we should decide to implement the management
environment with minimum complexity but still ensuring that we have enough flexibility for to support
future service additions and changes. Cisco NSO will most commonly handle the configuration management
while leaving other parts of the service lifecycle management to other (existing) BSS/OSSs.

1-82 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Sample Layer 3 MPLS VPN Design
 Service provider requires certain parameters to be allocated from their existing
inventory databases.
 Cisco NSO will be integrated with the inventory DB to allocate parameters.
 Cisco NSO will locally handle other parameters.

This topic describes a sample service model to support the management of Layer-3 MPLS VPN service
which was described in the previous topic. One of the requirements in the sample environment is that we
need to integrate the service with external systems or provide complex algorithms to provide the technical
parameters needed to configure network devices.


© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-83
High-Level Service Design
Sample Layer 3 MPLS VPN Service
Service Model
L l3mplsvpn

K vpn-id vpn-name R customer

L link

K link-id U interface E routing-protocol R device

L static

K prefix K mask

 Each VPN instance is associated with a customer and has multiple sites associated with it.
 Each site is connected to a PE router over a selected interface and requires addressing and
routing configuration.

The figure visualizes the service model:

 A list (“l3mplsvpn”) is used to hold the configuration data for multiple service instances.
 The list uses a leaf with unique numbers as the key (“vpn-id”).
 Additionally, each service instance is associated with a customer and is given a descriptive name (“vpn-
name”).
 Each instance should have two or more customer-facing links associated with it (“link” list).
 Each link has a key (“link-id”), an edge router (“device”), a customer-facing interface (“interface”) and a
choice of a routing protocol (“routing-protocol”).
 Additionally/Optionally, we may add static routes to the configuration.

1-84 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Sample Inventory Database Use Case

Services
Inventory:
Customers
Used for billing, reporting, marketing, etc.
L3 VPN Service
Instances

Used for reporting,

Resource Resource Resource
Inventory: Inventory: Inventory: capacity planning,
VLANs Interfaces Devices troubleshooting, etc.

 The required service parameters may reside in multiple external systems.

As we have existing repositories used by the service provider, we are required to integrate NSO with those
systems in order to ensure a single source of data for each parameter without unnecessary manual
duplication.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-85
Cisco NSO Integration with External Repository

Service Model Customers

L l3mplsvpn

K vpn-id vpn-name R customer

Devices
L link

K link-id interface E routing-protocol R device

Inventory
L static DB
Interfaces
K prefix K mask

Services

The figure illustrates which service parameters will be dependent on external data sources.

1-86 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Instance Parameters
Parameter Source Constraints Primary Parameter
Location
Customer Selected from repository SQL
Device Selected from managed devices Only PE routers CDB
Link ID Auto-generated CDB / Calculated
Interface Selected from device's interfaces Per-device CDB
RD Auto-generated Globally unique CDB / Calculated
RT Equals RD CDB / Calculated
PE-CE IP subnet Auto-generated Per customer unique CDB / Calculated
…

NSO Inventory
CDB DB
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 21

In the table above, we have a set of requirements concerning our Layer 3 MPLS VPN service model. The
parameters can be divided into three categories:
 Parameters that the operator enters
 Parameters that are automatically generated
 Parameters that are retrieved from an external database

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-87
Layer 3 MPLS VPN Service Model
module l3mplsvpn{
namespace
"http://com/example/l3mplsvpn";  Each Layer 3 MPLS VPN service
prefix l3mplsvpn;
import ietf-inet-types { prefix inet; } instance can have multiple PE-CE
import tailf-ncs { prefix ncs; }
import tailf-common { prefix tailf; } links.
augment /ncs:services {
list l3mplsvpn {  Each link requires:
leaf vpn-name { ... }
leaf vpn-id { ... }  PE device
leaf customer { ... }
 Interface on PE device
list link {
leaf link-name { ... }  Addressing
leaf link-id { ... }
leaf device { ... }  Routing: BGP, RIPv2, or static
leaf interface { ... }
leaf routing-protocol { ... }
leaf site-name { ... }
list static {
leaf prefix { ... }
leaf mask { ... }
}
}
}
}
}
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 22

The YANG model above illustrates the main statements that describe our informal design. The above
statements should provide enough information to describe the service and pass the necessary parameters to
the device manager for the service to be properly configured on network devices.
The following printout contains the entire service model for our sample Layer-3 MPLS VPN service.
module l3mplsvpn {
namespace "http://com/example/l3mplsvpn";
prefix l3mplsvpn;

import ietf-inet-types { prefix inet; }

import tailf-ncs { prefix ncs; }
import tailf-common { prefix tailf; }

augment /ncs:services {
list l3mplsvpn {
tailf:info "Layer-3 MPLS VPN Service";
key vpn-id;
unique "vpn-name customer";

uses ncs:service-data;
ncs:servicepoint "l3mplsvpn";

leaf vpn-name {
tailf:info "Service Instance Name";
type string;
1-88 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
}

leaf vpn-id {
tailf:info "Service Instance ID (10001 to 19999)";
type uint32 {
range "10001..19999";
}
}

leaf customer {
tailf:info "VPN Customer";
type leafref {
path "/ncs:customers/ncs:customer/ncs:id";
}
}

// Each VPN service instance can have one or more interfaces

list link {
tailf:info "PE-CE Attachment Point";
key link-id;
unique "device interface";

leaf link-name {
tailf:info "Link Name";
type string;
}

leaf link-id {
tailf:info "Link ID";
type uint32 {
range "1..255";
}
}

leaf device {
tailf:info "PE Router";
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-89
leaf interface {
tailf:info "Customer Facing Interface";
type string;
must "not (/l3mplsvn[vpn-id != current()/../../vpn-
id]/link[device = current()/../device][interface=current()])"
{
error-message "Interface already used.";
tailf:dependency ".";
}
}

leaf routing-protocol {
tailf:info "Routing option for the PE-CE link";
type enumeration {
enum bgp;
enum rip;
enum static;
}
}

list static {
tailf:info "Static Route";
key "prefix mask";
when "../routing-protocol='static'";

leaf prefix {
tailf:info "Static Route Prefix";
type inet:ipv4-address;
}

leaf mask {
tailf:info "Static Route Subnet Mask";
type inet:ipv4-address;
}
}
}
}
}
}

1-90 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
L3 MPLS VPN
Mapping Logic

Service to Device Mapping Options

 Template-based:
 CDB can optionally be synced to external repositories out of YANG XML
band (e.g. using northbound NSO APIs).

 Code-based using service callbacks: YANG

 Java/Python is used for mapping of service parameters directly
into the device configuration. Java/Python: create()
 Code-based using service callbacks and templates:
 Useful for locally calculated or allocated parameters. YANG XML
 Code is used for mapping service parameters into variables
Java/Python: create()
that are then referenced in device templates.

 Code-based using data provider callbacks: YANG

 Tight integration of Cisco NSO with external data providers with
full FASTMAP integration to support create, modify, and delete Java/Python: init(), transLock(),
operations. transUnlock(), writeStart(), prepare(),
commit(), abort(), finish(), get_elem(),
 External repository is the primary service parameter storage.
get_next(), set_elem(), …
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 24

Based on the requirements of our service and especially the requirements to integrate Cisco Network
Services Orchestrator (Cisco NSO) with other systems, we can choose the implementation approach. The
figure describes four options ordered from the simplest and also least powerful to the most complex and also
the most powerful:
 Template-based: Simple and fast service mapping development; may not have enough functionality.
 Code-based using service callbacks: Does not require a template but may result in longer code due to
direct writing of configuration into device Network Element Drivers (NEDs).
 Code-based using service callbacks and templates: Mixes the simplicity of generating XML templates
and the power of Java or Python to extract service parameters.
 Code-based using data provider callbacks: May result in more code due to the number of states and
transitions, which can all be controlled through their callbacks.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-91
Service Create Code Callbacks
 CallPoint determines the NAVU location in the configuration tree.
 CallType determines the callback type:
 CREATE
 PRE_MODIFICATION
 POST_MODIFICATION

// YANG // Python
module l3mplsvpn { class L2vpn(ncs.application.Application):
... def setup(self):
augment /ncs:services { self.register_service('l3mplsvpn-servicepoint',
uses ncs:service-data; ServiceCallbacks)
ncs:servicepoint
l3mplsvpn-servicepoint; // Java
... @ServiceCallback(servicePoint="l3mplsvpn-servicepoint",
} callType=ServiceCBType.CREATE)
} public Properties create(...) {
}

The most common and fastest way to develop service mappings is to use the service create callback. The
figure illustrates two options:
 Using Python programming language.
 Using Java programming language.

Both approaches make use of FASTMAP so that the developer only needs to consider the creation aspect of
service management. The service class can have three methods:
 preModification(…)
 create(…)
 postModification(…)

For Java, Cisco NSO is able to find the methods via reflection, by finding the ServiceCallback attribute.
Therefore, it is important that the values for the servicePoint field in Java and the value for the
ncs:servicepoint node in the service model match. This is also true for Python code.
The methods are executed in the order listed. Recall that the changes made to the CDB within the create()
method are part of the service device-modifications (part of FastMap), and will thus be removed when the
service instance is removed. The second issue you could face as a result of Fastmap is that in the create()
method, there is no way of telling whether the service instance is being created for the first time or is being
modified.
We have a couple of additional functionalities to work around these behaviors, if desired:
1. In contrast, the changes made to the CDB within the pre- and postModification methods are not part of
FastMap, and will not be removed when the service instance is removed. One use case for such behavior
is simple resource allocation that does not require integration with external systems: in the
preModification method, a check is first performed if the service instance exists. If the service instance is
first created, we allocate the resource in the preModification method, and then use it in the create()
method on subsequent runs.

1-92 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
2. Notice that the return type for all three methods is Properties. This is a standard Java key-value string
map that can be used to persist values between invocations of all three methods.

In the example Layer 3 MPLS VPN service, we use the preModification method to provide a unique
identifier (global counter) for the links in a virtual private network. In that way, the operator does not have to
provide unique numeric IDs, the system allocates them when a new service instance is created.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-93
Case Study: Java-Based Service
cisco@NCS:~/ncs-run/packages$ ncs-make-package --service-skeleton java-and-template l3mplsvpn
cisco@NCS:~/ncs-run/packages$ cd l3mplsvpn/src/java/src/com/example/l3mplsvpn/
cisco@NCS:~/ncs-run/packages/l3mplsvpn/src/java/src/com/example/l3mplsvpn$ vim
l3mplsvpnRFS.java

 Create a Java-based service skeleton.

 Implement the service model using the YANG file.
 Implement the service mapping using:
 Option 1: Java with direct device configuration
 Option 2: Java and configuration templates

To showcase programmable model navigation we will create a service package. In this case, we have decided
to use Java for mapping the service parameters to device configuration, so we will create a Java-based
service skeleton.

1-94 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Option 1: Service Callback and Direct Mapping into Device
Configuration
package com.example.l3mplsvpn;

import com.example.l3mplsvpn.namespaces.*;
import java.util.Properties;
import com.tailf.conf.*;
import com.tailf.navu.*;
import com.tailf.dp.*;
import com.tailf.dp.annotations.*;
import com.tailf.dp.proto.*;
import com.tailf.dp.services.*; Register the create
public class l3mplsvpnRFS { callback.
// REGISTER CALLBACK
@ServiceCallback(servicePoint="l3mplsvpn", callType=ServiceCBType.CREATE)
public Properties create(ServiceContext context, NavuNode service, NavuNode ncsRoot,
Properties opaque) throws DpCallbackException {

<code to map service parameters directly into device configuration> 

}
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 27

In our sample Layer-3 MPLS VPN service, we have decided to implement a service create callback and
perform as much auto-generation of technical service parameters in order to reduce the number of editable
service parameters to a minimum.
The figure illustrates the top level of the Java skeleton that registers the create callback.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-95
Option 1: Service Callback and Direct Mapping into Device
Configuration (Cont.)
// CONFIGURE SERVICE
String servicePath = null;
try {
servicePath = service.getKeyPath();
NavuList managedDevices = ncsRoot.container("devices").list("device");
// GET GLOBAL SERVICE INSTANCE PARAMETERS
String vpn_name = service.leaf("vpn-name").valueAsString();
String vpn_id = service.leaf("vpn-id" ).valueAsString(); Retrieve global service
String customer = service.leaf("customer").valueAsString(); instance parameters
NavuList links = service.list("link" );
// CONFIGURE DEVICES WITH SERVICE PARAMETERS
for (NavuContainer link: links.elements()){
String device = link.leaf("device").valueAsString();
NavuNode node1 = managedDevices.elem(device).
container("device-type").container("cli");
NavuContainer nc1 = (NavuContainer) node1;
String type = nc1.leaf("ned-id").valueAsString();
System.out.println(" DEVICE: " + device + " type: " + type); Loop
// GET LINK PARAMETERS
link_id = Integer.parseInt(link.leaf("link-id").valueAsString()); through
link_name = link.leaf("link-name" ).valueAsString(); all link
iface = link.leaf("interface" ).valueAsString(); instances
routing_protocol = link.leaf("routing-protocol").valueAsString();
// IOS-SPECIFIC CONFIG
if (type.equals("ios-id:cisco-ios")){ … }
// IOS-XR-SPECIFIC CONFIG
© 2016 Cisco and/orif (type.equals("cisco-ios-xr-id:cisco-ios-xr")){
its affiliates. All rights reserved. … }

Advanced Cisco Network Services Orchestrator v4.2 28

Inside the service create callback, we must perform two actions:

 Extract service parameters
 Configure the devices using the required parameters:
— From service parameters
— From an external source
— Calculated from other parameters
In the example, you may also see that the choice to directly configure devices requires us to consider the
specifics of each device type used for the service. The next page will drill into the code that handles the
configuration of Cisco IOS routers for Layer 3 MPLS VPN service instance deployment.
Note that the matching device type using NED ID is not always a viable option, especially when using
NETCONF devices. Refer to Lab 2 to see an example of how device type should be checked.

1-96 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Option 1: Service Callback and Direct Mapping into Device Configuration (Cont.)
// IOS-SPECIFIC CONFIG
if (type.equals("ios-id:cisco-ios")){
// VRF CONFIGURATION
NavuNode node2 = managedDevices.elem(device).container("config").container("ios:vrf").
list("definition").sharedCreate("vpn" + vpn_id );
NavuContainer vrfnode = (NavuContainer)node2;
System.out.println(" VRF: " + vrfnode.toString());
vrfnode.leaf("description").set("L3 MPLS VPN for customer " + customer);
vrfnode.leaf("rd").set("1:"+vpn_id);
vrfnode.container("route-target").list("import").sharedCreate("1:" + vpn_id);
vrfnode.container("route-target").list("export").sharedCreate("1:" + vpn_id);
vrfnode.container("address-family").container("ipv4").sharedCreate();
// INTERFACE CONFIGURATION
NavuNode node3 =
managedDevices.elem(device).container("config").container("ios:interface").
list("GigabitEthernet").elem(link.leaf("interface").valueAsString());
NavuContainer ifnode = (NavuContainer)node3;
System.out.println(" Intf: " + ifnode.toString());  Convert Link-ID to three
// Calculate IP address from unique link ID: 172.x.y.z octets used for IP
int pe_ip_o2 = 31 - (link_id * 4) / 4096; addressing
int pe_ip_o3 = ((link_id * 4) % 4096) / 64;  Complex operations like
int pe_ip_o4 = ((link_id * 4) % 4096) % 64 + 1;
String link_ip = "172." + pe_ip_o2 + "." + pe_ip_o3 + "." + pe_ip_o4; this cannot be performed
in templates using XPath
System.out.println(" IP: " + link_ip);
ifnode.container("ip").container("address").container("primary").leaf("address").set(link_ip)
;
ifnode.container("ip").container("address").container("primary").leaf("mask").set("255.255.25
5.252");
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 29
…

The above Java code illustrates how to configure a L3 MPLS VPN service instance given the service
parameters. It equals this native Cisco IOS configuration:
vrf definition vpn10001
rd 1:100
route-target both 1:10001
!
address-family ipv4
!
interface GigabitEthernet4
description Connection to vpn10001
vrf forwarding vpn10001
ip address 172.31.1.1 255.255.255.252
!
router bgp 1
bgp log-neighbor-changes
address-family ipv4 vrf vpn10001
redistribute connected
redistribute static
...

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-97
Option 1: Service Callback and Direct Mapping into Device Configuration (Cont.)
…
// ROUTING CONFIGURATION
System.out.println(" RP: " + routing_protocol);
// ROUTING CONFIGURATION: BGP
if (routing_protocol.equals("bgp")) {
for (NavuNode node4: managedDevices.elem(device).xPathSelect(
"config/ios:router/bgp[as-no='1']/address-family/with-vrf/ipv4[unicast-multicast='unicast']")){
int ce_ip_o4 = pe_ip_o4 + 1; // Neighbor address is +1 of our previously calculated intf address
String bgp_nei = "172." + pe_ip_o2 + "." + pe_ip_o3 + "." + ce_ip_o4;
NavuContainer bgprnode = (NavuContainer) node4;
NavuContainer bgpvnode = bgprnode.list("vrf").sharedCreate("vpn"+vpn_id);
NavuContainer bgpnnode = bgpvnode.list("neighbor").sharedCreate(bgp_nei);
bgpnnode.leaf("remote-as").set("65001");
NavuContainer bgpstatnode = bgpvnode.container("redistribute").container("static").sharedCreate();
NavuContainer bgprednd = bgpvnode.container("redistribute").container("connected").sharedCreate();
}
}
// ROUTING CONFIGURATION: RIP
if (routing_protocol == "rip") { … }
// ROUTING CONFIGURATION: STATIC
if (routing_protocol == "static") { … }
}© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 30

The last part of the configuration shows the routing configuration (partially). As you can see, we used a
complex calculation for optimal IP address allocation, which would not be possible using templates and
XPath.

1-98 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Option 2: Service Callback and Configuration Templates
Java Code
package com.example.l3mplsvpn;
import com.tailf.ncs.template.Template;
import com.tailf.ncs.template.TemplateVariables;
...

// REGISTER CALLBACK
@ServiceCallback(servicePoint="l3mplsvpn", callType=ServiceCBType.CREATE)
public Properties create(ServiceContext context, NavuNode service, NavuNode ncsRoot,
Properties opaque) throws DpCallbackException {
...
String vpn_name = service.leaf("name").valueAsString(); Read parameter values.
String customer = service.leaf("customer").valueAsString();

TemplateVariables tvars= new TemplateVariables();

tvars.putQuoted("SERVICE", vpn_name); Assign values to variables
tvars.putQuoted("CUSTOMER", customer); from the service instance.
...

Template template = new Template(context, "l3mplsvpn"); Apply variables to the

template.apply(service, l3vars); template.
...
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 31

The partial Java code shown in the figure contains the following major components:
 An XML device configuration template is loaded from the package's templates directory.
 Variables are populated with values. In the example, we only see variables that are retrieved from the
service instance where the operator provided the values. Alternatively, we can use other means of
calculating or allocating some values, but we have to implement this by using Reactive FASTMAP.
 Finally, the configuration template is populated with service instance parameters (i.e. variables in the
template are replaced by supplied values).
This approach provides the most scalability and simplicity by allowing all static parts of the configuration to
be simply added or changed in template files (note that there is no need to recompile and reload packages
upon template change).

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-99
Option 2: Service Callback and Configuration Templates
Python Code
import ncs, ncs.template
from ncs.application import Service

class ServiceCallbacks(Service):
@Service.create
def cb_create(self, tctx, root, service, proplist):
...
vpn_name = service.name Read parameter values.
customer = service.customer

tvars = ncs.template.Variables() Assign values to variables

tvars.add('SERVICE', vpn_name)
from the service instance.
tvars.add('CUSTOMER', customer)

template = ncs.template.Template(service) Apply variables to the

template.apply('l3mplsvpn', tvars) template.
...
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 32

1-100 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
L3 MPLS VPN
Service Deployment
This topic describes the service deployment options and requirements.

Greenfield Service Deployment

 No migration procedure required.

 Fully greenfield deployment is ideal – Cisco NSO is the only management
system on devices.
 If multiple management systems are used to manage devices:
 Ensure they do not overlap in configuration sections.
 Ensure NEDs do not see the configuration of other systems (otherwise, sync will fail).

The preferred approach to deploying Cisco Network Services Orchestrator (Cisco NSO) and services is to
manage a so-called greenfield environment where Cisco NSO is used to manage new services. Ideally, there
should also be no other management system that manages the same set of devices. If, however, there is
another system, we should make sure that the two systems do not have overlapping areas of configuration.
Furthermore, Cisco NSO Network Element Drivers (NEDs) should be modified to exclude any part of the
configuration that other systems manage in order to ensure that the visible configuration is always in sync
between Cisco NSO and the devices.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-101
Service Migration:
Existing Services Instances Migrated to Cisco NSO
 Why?
 Cisco NSO is to be used as the only configuration management system.
 Existing services with existing instances should now be managed using Cisco NSO.

 How?
 Design a service model that produces identical configurations to existing service instances.
 Retrieve data for existing service instances:
 Service inventory system or

Device configurations or …
 Script bulk import procedure using Cisco NSO APIs

 Warning: Automate only if you save time by automating!

Why?
Another use case scenario for Cisco NSO is to manage existing services. This is a more challenging situation
where we need to “import” the existing service instances in addition to designing a service model that maps
identically to existing configurations. This can be achieved by retrieving a list of existing service instances
and parameters and creating a script that will generate the required service instances in CDB.
One of the most frequently asked questions is “how do you discover all the services that were already on the
network before Cisco NSO was deployed, so that Cisco NSO can take over the management of these
services?” The answer is “with great difficulty.” Note that this will apply to all orchestration/provisioning
systems. Problems include:
If services have been provisioned manually, then there may not be much of a pattern – they may vary greatly.
The orchestration/provisioning system can only discover services which are configured in exactly the same
way as the service implementation in the provisioning system. This means that the more
flexible/customizable/extensible the orchestration/provisioning system is, the more
flexible/customizable/extensible the service discovery mechanism must be.
Only data present in the network devices can be discovered from the network (a tautology! :-) ). Business
data cannot be discovered unless it has been put in description fields, or names, etc.
The law of diminishing returns applies – automate only if you save time by automating. In the example
below, the forensics are done manually. That may be the best solution in smaller networks.

1-102 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Migration:
Designing a Service Model
 The most difficult part is designing a service
model that maps to all possible existing Cisco NSO must be able to
service options: produce configs for existing
 Gather device configurations.
services/service instances.
 Determine all service deployment options.
 Model the service.
 Map service model to device configurations.
 Repeat the above for all device types. Service
Config

 Many ad-hoc service instance modifications may prevent us from modeling all
possible options.
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 36

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-103
Service Migration:
Designing a Service Model (Cont.)

Get the configs (sync from).

 Identify service instance

components (e.g. VRFs,
interfaces, addresses).
 Identify all service instance
Design a service model. options (e.g. different
routing protocols).
Service  Identify all device types.
Config
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 37

1-104 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Import Procedure
Device
NSO
1. Sync from device Org Sync Org
From
device device PE11 sync-from Config Config

Org Org
2. Deploy service instance without networking: Config Config
Refcount=2
commit no-networking Service
Config

3. Un-deploy the instance without networking and Org

ignoring the Refcount: Config
services l3mplsvpn 123 un-deploy no-networking ignore-refcount

4. Re-deploy the instance without networking: Service

= Org
services l3mplsvpn 12312 re-deploy no-networking Config Config
Refcount=1
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 38

The figure illustrates the steps needed to import a single service instance into CDB for an existing
configuration on a managed device:
1. In the first step, we have to retrieve the configuration from a device by syncing from the device.
2. In the second step, we provision this same service instance into CDB only by using the no-networking
option with the commit command. Now we have the same set of configuration commands for the service
instance referenced twice: the original synced configuration and the Cisco NSO-provisioned service
instance in CDB. This is shown by looking at the Refcount value in the CDB.
3. In the third step, we need to un-deploy the service instance by ignoring the Refcount, which means that
both virtual configuration instances will be remove.
4. In the last step, we re-deploy the service instance thus having the correct Refcount value and the
configuration that should be identical to the original configuration residing on the end device.
5. The following is an example of a migration of existing Layer 3 MPLS VPN services.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-105
Service Import Procedure Example
admin@ncs(config)# services l3mplsvpn 12312
admin@ncs(config-l3mplsvpn-12312)# vpn-name test
admin@ncs(config-l3mplsvpn-12312)# customer ACME
admin@ncs(config-l3mplsvpn-12312)# link 12
admin@ncs(config-link-12)# link-name l12
admin@ncs(config-link-12)# device PE11
admin@ncs(config-link-12)# interface 0/9
admin@ncs(config-link-12)# routing-protocol bgp
admin@ncs(config-link-12)# exit
admin@ncs(config-l3mplsvpn-12312)# link 13
admin@ncs(config-link-13)# link-name l13
admin@ncs(config-link-13)# device PE31
admin@ncs(config-link-13)# interface 0/9
admin@ncs(config-link-13)# routing-protocol bgp
admin@ncs(config-link-13)# top
admin@ncs(config)# commit no-networking
admin@ncs# show running-config devices device PE11 | display service-meta-data
devices device PE11
...
!
/* Refcount: 2 */
/* Backpointer: [ /ncs:services/l3mplsvpn:l3mplsvpn[l3mplsvpn:vpn-id='12312'] ] */
ios:vrf definition vpn12312
description L3 MPLS VPN for customer ACME
rd 1:12312
/* Refcount: 2 */
/* Backpointer: [ /ncs:services/l3mplsvpn:l3mplsvpn[l3mplsvpn:vpn-id='12312'] ] */
address-family ipv4
exit-address-family
!
route-target export 1:12312
route-target import 1:12312
...
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 39

The figure shows an example of importing an existing configuration of Layer 3 MPLS VPNs (Step 2 from
the previous slide). As you may observe, there is now an incorrect Refcount value of 2 because this same
configuration has already been there from the original device synchronization.

1-106 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Import Procedure Example (Cont.)
admin@ncs(config)# services l3mplsvpn 12312 un-deploy no-networking ignore-refcount
admin@ncs(config)# services l3mplsvpn 12312 re-deploy no-networking
admin@ncs# show running-config devices device PE11 | display service-meta-data
devices device PE11
...
!
/* Refcount: 1 */
/* Backpointer: [ /ncs:services/l3mplsvpn:l3mplsvpn[l3mplsvpn:vpn-id='12312'] ] */
ios:vrf definition vpn12312
description L3 MPLS VPN for customer ACME
rd 1:12312
/* Refcount: 1 */
/* Backpointer: [ /ncs:services/l3mplsvpn:l3mplsvpn[l3mplsvpn:vpn-id='12312'] ] */
address-family ipv4
exit-address-family
!
route-target export 1:12312
route-target import 1:12312
...

The continuation of the example (Steps 3 and 4) shows how to ensure that we have the right Refcount for the
virtually deployed Layer 3 MPLS VPN instance.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-107
Service Import Procedure (NSO >= 4.2)
Device
NSO
1. Sync from device Org Sync Org
From
device device PE11 sync-from Config Config

Org Org
2. Deploy service instance without networking: Config Config
Refcount=2
commit no-networking Service
Config

3. Un-deploy the instance without networking and

Org
ignoring the Refcount: Config
services l3mplsvpn 123 un-deploy no-networking ignore-refcount

4. Re-deploy the instance without networking: Service

= Org
services l3mplsvpn 12312 re-deploy no-networking Config Config
Refcount=1
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 45

The slide shows the manual steps of reconciliation of service configuration in NSO versions prior to NSO
4.2. In NSO 4.2, there is a new command that replaces steps 3 and 4.
Below is the old procedure, for manual reconciliation of service instance configuration.
The figure illustrates the steps needed to import a single service instance into CDB for an existing
configuration on a managed device:
1. In the first step, we have to retrieve the configuration from a device by syncing from the device.
2. In the second step, we provision this same service instance into CDB only by using the no-networking
option with the commit command. Now we have the same set of configuration commands for the service
instance referenced twice: the original synced configuration and the Cisco NSO-provisioned service
instance in CDB. This is shown by looking at the Refcount value in the CDB.
3. In the third step, we need to un-deploy the service instance by ignoring the Refcount, which means that
both virtual configuration instances will be remove.
4. In the last step, we re-deploy the service instance thus having the correct Refcount value and the
configuration that should be identical to the original configuration residing on the end device.

The following is an example of a migration of existing Layer 3 MPLS VPN services.

1-108 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Import Procedure (NSO >= 4.2)
Device
NSO
1. Sync from device Org Sync Org
From
device device PE11 sync-from Config Config

Org Org
2. Deploy service instance without networking: Config Config
Refcount=2
commit no-networking Service
Config

3. Re-deploy the instance & reconcile:

Service Org
services l3mplsvpn * re-deploy reconcile
Config
= Config
Refcount=1

The slide shows the manual steps of reconciliation of service configuration in NSO versions prior to NSO
4.2. In NSO 4.2, there is a new command that replaces steps 3 and 4.
Below is the old procedure, for manual reconciliation of service instance configuration.
The figure illustrates the steps needed to import a single service instance into CDB for an existing
configuration on a managed device:
1. In the first step, we have to retrieve the configuration from a device by syncing from the device.
2. In the second step, we provision this same service instance into CDB only by using the no-networking
option with the commit command. Now we have the same set of configuration commands for the service
instance referenced twice: the original synced configuration and the Cisco NSO-provisioned service
instance in CDB. This is shown by looking at the Refcount value in the CDB.
3. In the last step, we re-deploy the service instance with the new reconcile command, thus having the
correct Refcount value and the configuration that should be identical to the original configuration
residing on the end device.
The following is an example of a migration of existing Layer 3 MPLS VPN services.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-109
Service Migration: Existing Services to NSO
 Scripted bulk import based on described service import procedure.
 Disabled networking prevents any unwanted disruption in the production
environment.
 Checking of diff for any deviation from modeled service.
 Many and differing ad-hoc customizations may prevent the introduction of
standardized service models.

The service migration procedure, as show on previous pages, can be scripted and executed to enable a bulk
import of existing service instances. Disabled networking prevents any unwanted disruption in the production
environment in case some instances would not result in identical configurations. The diff of the
configurations should be checked to ensure we have properly modeled the existing service. Many and
differing ad-hoc customizations in the past may prevent the introduction of standardized service models.

1-110 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
L3 MPLS VPN
Service Upgrade
This topic describes the possibilities for performing service upgrades.

Service Upgrade Actions

 Default: Automatic upgrade if possible
 Alternative 1: Using init XML files to update existing service instances in CDB
 Alternative 2: Using an upgrade procedure in Java to modify the data in CDB

Every time a package is reloaded, Cisco Network Services Orchestrator (Cisco NSO) will perform an
automated service upgrade procedure. This procedure, however, may not be successful in case of significant
changes to the service model. As an alternative, we can use the init XML files to change the current contents
of service instance data before performing the model upgrade. Another alternative is to program the upgrade
procedure using Java and the upgrade callback.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-111
Automatic Service Package Upgrade
 Every package reload action triggers a service upgrade process.
 Automatic service upgrade succeeds in the following cases:
 Deleted nodes: always succeeds; deletes nodes from the data tree
 Added nodes: succeeds if not mandatory without default
 Re-ordered nodes: always succeeds
 Type changes: succeeds if smart type conversion succeeds or there is a default value
 Key changes: succeeds if modified key leaf is still unique
 Default values: always succeeds with changes to nodes that still use a default value
 Adding/removing namespaces: existing nodes in removed namespace are removed, new
nodes initialized with default values
 Changing to/from operational: data removed/added according to default rules
 Callpoint changes: data removed/added according to default rules

The configuration database (CDB) can automatically handle the following changes to the schema:

Deleted elements
When an element is deleted from the schema, CDB simply deletes it (and any children) from the database.

Added elements
If a new element is added to the schema, it needs to either be optional, dynamic, or have a default value. New
elements with a default are added set to their default value. New dynamic or optional elements are simply
noted as a schema change.

Re-ordered elements
An element with the same name, but in a different position on the same level, is considered to be the same
element. If its type has not changed, it will retain its value, but if the type has changed, it will be upgraded as
described below.

Type changes
If a leaf is still present but its type has changed, automatic coercions are performed. So, for example, integers
may be transformed to their string representation if the type changed from, for example, int32 to string.
Automatic type conversion succeeds as long as the string representation of the current value can be parsed
into its new type. (Which, of course, also implies that a change from a smaller integer type, for example, int8,
to a larger type, for example, int32, succeeds for any value – while the opposite will not hold, but might!). If
the coercion fails, any supplied default value will be used. If no default value is present in the new schema,
the automatic upgrade will fail. Type changes when user-defined types are used are also handled
automatically, provided that some straightforward rules are followed for the type definitions. Read more
about user-defined types in the confd_types(3) manual page, which also describes these rules.

1-112 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Hash changes
When a hash value of a particular element has changed (due to an addition of, or a change to, a tailf:id-value
statement), CDB will update that element.

Key changes
When a key of a list is modified, CDB tries to upgrade the key using the same rules as explained above for
adding, deleting, re-ordering, change of type, and change of hash value. If an automatic upgrade of a key
fails, the entire list instance will be deleted.

Default values
If a leaf has a default value, which has not been changed from its default, the automatic upgrade will use the
new default value (if any). If the leaf value has been changed from the old default, then that value will be
kept.

Adding/Removing namespaces
If a namespace is no longer is present after an upgrade, CDB removes all data in that namespace. When CDB
detects a new namespace, it is initialized with the default values.

Changing to/from operational

Elements that previously had config false set and are changed into database elements will be treated as added
elements. In the opposite case, where data elements in the new data model are tagged with config false, the
elements will be deleted from the database.

Callpoint changes
CDB only considers the part of the data model in YANG modules that do not have external data callpoints.
But while upgrading, CDB does handle moving subtrees into CDB from a callpoint and vice versa. CDB
simply considers these as added and deleted schema elements. Thus, an application can be developed using
CDB in the first development cycle. When the external database component is ready, it can easily replace
CDB without changing the schema. Should the automatic upgrade fail, exit codes and log-entries will
indicate the reason.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-113
Upgrade Procedure in Java
public class UpgradeService {
public UpgradeService() {
}
public static void main(String[] args) throws Exception {
Socket s1 = new Socket("localhost", Conf.NCS_PORT);
Cdb cdb = new Cdb("cdb-upgrade-sock", s1);
cdb.setUseForCdbUpgrade();
CdbSession cdbsess = cdb.startSession(CdbDBType.CDB_RUNNING);
Socket s2 = new Socket("localhost", Conf.NCS_PORT);
Maapi maapi = new Maapi(s2);
int th = maapi.attachInit();
int no = cdbsess.getNumberOfInstances("/services/l3mplsvpn");
for(int i = 0; i < no; i++) {
// Loop through all service instances and update data
…
}
}
}

 A skeleton of a service upgrade procedure

When the package reload is requested, the packages in the load-path is copied to the state directory. The old
state directory is scratched so that packages that no longer exist in the load-path are removed and new
packages are added. Obviously, unchanged packages will be unchanged. Automatic schema CDB upgrades
will be performed, and afterwards, for all packages which have and upgrade component and for which at
least one YANG model was changed, this upgrade component will be executed. Also, for added packages
that have an upgrade component, this component will be executed. Hence, the upgrade component needs to
be programmed in such a way that care is taken for both the new and upgrade package scenarios.

1-114 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Upgrade Procedure in Java (Cont.)
<ncs-package xmlns="http://tail-f.com/ns/ncs-packages">
<name>l3mplsvpn</name>
<package-version>1.0</package-version>
<description>Layer-3 MPLS VPN Service Model</description>
<ncs-min-version>3.0</ncs-min-version>
<required-package>
<name>router</name>
</required-package>
<component>
<name>L3 MPLS VPN RFS</name>
<callback>
<java-class-name>com.example.l3mplsvpn.l3mplsvpnRFS</java-class-name>
</callback>
</component>
<component>
<name>upgrade-service</name>
<upgrade>
<java-class-name>com.example.l3mplsvpn.UpgradeService</java-class-name>
</upgrade>
</component>
</ncs-package>

 Modify the package-meta-data.xml file to include the upgrade class.

As with any package component types, the upgrade component has to be defined in the package-
metadata.xml file.

Service create Device upgrade redeploy

model CDB Device
model Config Config
(XML and/or
(YANG)
Java)

After change: After XML change:

 Recompile  Reload
 Reload  Re-deploy, if needed

After Java change:

 Recompile
 Reload
 Re-deploy, if needed

 A re-deploy of the upgraded service is needed when the service change results
in changed device commands.
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 47

The figure illustrates the path of data from the service model down to the device configuration. Any change
in any of the involved pieces of logic may require some actions in order to make those changes active.

1-116 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Upgrade Actions
 Default: Automatic upgrade if possible
admin@ncs# packages reload
reload-result {
package l3mplsvpn
result true
}
admin@ncs#

 Alternative 1: Using init XML files to update existing service instances in CDB
local install system install
cisco@NCS:~/ncs-3.3/ncs-run$ ncs --stop cisco@NCS:~$ /etc/init.d/ncs stop
cisco@NCS:~/ncs-3.3/ncs-run$ ncs cisco@NCS:~$ /etc/init.d/ncs start

 Alternative 2: Using an upgrade procedure in Java to modify the data

admin@ncs# packages reload
reload-result {
package l3mplsvpn
result true
}
admin@ncs#

The figure illustrates the commands needed to perform the upgrade procedures:
 A reload of packages is needed to trigger the upgrade to a new service model.
 If using the init XML file, you should precede the reload by restarting the server to trigger the init
process.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-117
Summary
This topic summarizes the key points that were discussed in this lesson.
 Mapping logic for more complex services is implemented using combination of Java / Python code and
XML templates.
 Virtually any service logic can be implemented by using Java / Python code, and it is automatically a part
of the service application.
 Configuration parameters can be assigned by northbound OSS, directly by Cisco NSO, or a combination
of both.
 Consider all service lifecycle aspects when designing and implementing a service:
— Service migration
— Service upgrades

1-118 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Lesson 1-3

Layer 2 MPLS VPN Service

Design
Overview
Lesson focuses on service optimization for Layer 2 P2P VPN service. We consider automating parameter
allocation, advanced YANG model validation, and supporting new device types from a different vendor for
existing services. For parameter allocation, one of the most commonly used approaches is Reactive
FastMAP.

Objectives
Upon completing this lesson, you will be able to meet these objectives:
 Revisit the Layer 2 VPN service from the Basic NSO course
 Explain how that service can be extended to support additional vendors
 Describe how that service can use external applications

Layer 2 Point-to-Point VPNs

 Provide isolated P2P communication between customer sites
 Customers run their own routing protocols over VPN link (pseudo-wire)

Bi-directional traffic between CE21 and CE11 CE11 CE12

Bi-directional traffic between CE21 and CE12
Bi-directional traffic between CE21 and CE31

Each VPN instance

has two attachments. PE12 PE12

IOS XR
CE21 PE21 PE31 CE31
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 4

A Layer 2 circuit is a point-to-point (P2P) Layer 2 connection transported using Multiprotocol Label
Switching (MPLS) or other tunneling technology on the service provider’s network. Multiple VCs are
transported over a single shared label-switched path (LSP) tunnel between two (Provider Edge) PE routers.
This functionality is provided by the MPLS switching in the provider‘s core. This way, the allocation of a
separate dedicated LSP can be avoided.

1-120 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Layer 2 Point-to-Point VPNs (Cont.)
CE11 CE12

To configure a P2P circuit

between CE21 and CE31,
we need to configure PE21
and PE31. PE12 PE12

CE21 PE21 PE31 CE31

 Access interfaces: How and where PE and CE devices are connected

 Encapsulation: How data is encapsulated over the pseudowire
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 5

For each P2P circuit, we need to configure the PE routers that the Customer Edge (CE) routers, which
represent the endpoints of the circuit are attached to.
Configuration will consist of few parameters that are needed in order to provision a service instance. The
parameters can be divided as follows:
 Access interface configuration where we may have a variety of interface types.
 Encapsulation of the tunneling method for the data in the pseudowire.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-121
Informal Service Design: Service Configuration
Cisco IOS  The configuration is provided by the
interface GigabitEthernet0/9 network engineer.
description Link to CE11
xconnect 10.0.0.21 1001121 encapsulation mpls  Different devices have different
configuration for the same service.
Cisco IOS XR
l2vpn
xconnect group ACME
p2p CE11-to-CE21
interface GigabitEthernet0/0/0/9
neighbor 10.0.0.11 pw-id 1001121
!
!
!
interface GigabitEthernet0/0/0/9
description Link to CE21
l2transport
!
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 6

The figure illustrates the Cisco IOS configuration provided by the network engineer. It contains all
configuration options needed to deploy the service instance using manual configuration. From the
configuration, we can determine the set of parameters and options that will guide us when designing a service
model.

1-122 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Informal Service Design: Service Configuration
This is a unique identifier describing an instance of a deployed P2P Layer 2 MPLS VPN.
VPN Instance Name
It is used to provide a descriptive name for the service instance.
This is a unique number that is used to identify the pseudowire connection across MPLS between two
Pseudowire Identifier PE routers.

2x Attachment Circuit
Each attachment circuit is connected to a device (PE router).

Device Currently, there are two device types used for PE routers:
 Cisco IOS routers
 Cisco IOS XR routers
Each attachment circuit contains an interface or a subinterface.
Interface
Currently, only GigabitEthernet interfaces are used for the service.
Each attachment circuit is connected to a remote end identified by the loopback address of the other
Remote IP PE router.
All PE routers in the network have Loopback0 addresses in the 10.0.0.X/24 network.

The figure lists all the parameters that we need to know to be able to configure a single Layer 2 VPN P2P
connection.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-123
Create and Test the Service in the Development Lab
 Finalize service parameters with the architects and engineers.

 Perform manual deployment of a sample service instance using Cisco NSO CLI
instead of the device CLI:
 In a lab environment
or
 Using the netsim tool (faster, easier, fewer resources required)

 Generate XML template with commit dry-run or show running-config commands,

using XML output.
 Extract variable parameters from XML and model them with YANG.

When we have acquired the device configurations, finalized the informal service design, and created the list
of service parameters, we can proceed to convert these into the formal service design using YANG to model
the service.

1-124 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Device Configuration Using Cisco NSO CLI
Cisco IOS XR Configuration
admin@ncs(config)# devices device PE21 config cisco-ios-xr:l2vpn
admin@ncs(config-l2vpn)# xconnect group ACME p2p CE11-to-CE21
admin@ncs(config-l2vpn-xc-p2p)# interface GigabitEthernet0/0/0/9
admin@ncs(config-l2vpn-xc-p2p)# neighbor 10.0.0.11 pw-id 1001121
admin@ncs(config-l2vpn-xc-p2p-pw)# top
admin@ncs(config)# devices device PE21 config
admin@ncs(config-config)# cisco-ios-xr:interface GigabitEthernet0/0/0/9
admin@ncs(config-if)# l2transport
admin@ncs(config-if-l2)# top
admin@ncs(config)# commit dry-run outformat xml

Cisco IOS Configuration

admin@ncs(config)# devices device PE11 config ios:interface GigabitEthernet 0/9
admin@ncs(config-if)# xconnect 10.0.0.21 1001121 encapsulation mpls

The figure illustrates the configuration of the Layer 2 MPLS VPN service through the Cisco Network
Services Orchestrator (NSO) CLI.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-125
Device Configuration Template
XML Template
<config-template xmlns="http://tail-f.com/ns/config/1.0">
<devices xmlns="http://tail-f.com/ns/ncs">
<device tags="nocreate">
<name>{$DEVICE}</name>
<config>
<interface xmlns="urn:ios">
<GigabitEthernet>
<name>{$INTERFACE-ID}</name>
<xconnect tags="merge">
<encapsulation>mpls</encapsulation>
<vcid>{$PW-ID}</vcid>
<address>{$REMOTE-IP}</address>
</xconnect>
</GigabitEthernet>
</interface>
<!– Cisco IOS XR Config omitted -->

The figure illustrates the configuration of the Layer 2 MPLS VPN service through the Cisco NSO CLI.

1-126 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Device Configuration Using Cisco NSO CLI: XPath
 XPath output can be used to help when navigating using NAVU / Maagic API.
 When writing mapping code, we are navigating these same models.

Cisco IOS Configuration  XPATH

admin@ncs(config)# show full-configuration devices device IOSXR1 | display xpath
…
/devices/device[name='IOS1']/config/ios:interface/FastEthernet[name='1/0']/xconnect/address 10.0.0.1
/devices/device[name='IOS1']/config/ios:interface/FastEthernet[name='1/0']/xconnect/vcid 12914
/devices/device[name='IOS1']/config/ios:interface/FastEthernet[name='1/0']/xconnect/encapsulation mpls
…

Cisco IOS XR Configuration  XPATH

admin@ncs(config)# show full-configuration devices device IOSXR1 | display xpath
…
/devices/device[name='IOSXR1']/config/cisco-ios-xr:interface/GigabitEthernet[id='0/0/0/9']/description Test
/devices/device[name='IOSXR1']/config/cisco-ios-xr:l2vpn/xconnect/group[name='Customer2']/p2p[name='link']/
interface[name='0/0/0/9']
/devices/device[name='IOSXR1']/config/cisco-ios-xr:l2vpn/xconnect/group[name='Customer2']/p2p[name='link']/
neighbor[address='10.0.0.2'][pw-id='124']/ip-version ipv4
…
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 11

When the configuration is entered into Cisco NSO, we can use the display xpath pipe to help us navigate
through the device configuration. This is helpful when writing Java mapping code.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-127
Informal Service Design: Service Configuration
This is a unique identifier describing an instance of a deployed P2P Layer 2 MPLS VPN.
VPN Instance Name
It is used to provide a descriptive name for the service instance.
This is a unique number that is used to identify the pseudowire connection across MPLS between two
Pseudowire Identifier PE routers.
2x Attachment Circuit
Each attachment circuit is connected to a device (PE router).

The figure lists all the parameters that we need to know to be able to configure a single Layer 2 VPN P2P
connection.

1-128 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Layer 2 P2P VPN Service Model
Data path in l2vpn:
There can be many Each VPN instance
 pw-id VPN instances of Each VPN instance can is assigned to a
the service. have two links (P2P). customer.
 vpn-name (key)
 customer (reference*)
 link/ L l2vpn
 link/device (reference)
K name R customer Pw-id
 link/intf-number
 link/remoteip L link

K device U intf-number R remoteip

Based on the service characteristics and parameters we can create an informal design as illustrated in the
figure above. The figure illustrates YANG statements where, for example, a list statement ("L" in the figure)
is used for any object where we can have multiple instances (e.g. VPN instances, link instances within a VPN
instance, and static routes for individual links within a VPN instance). Each list requires a key leaf ("K" in
the figure) which is used as identifier in the example above. The model also references NSO resources such
as customers (optional but recommended) and devices (required in order to be able to link the service to the
actual devices that will eventually be configured with the right commands).
The hierarchy of the informal model can also be represented in text (e.g. similar to directories) which will
help in referencing the data later on using XPath.
This informal design can now be "translated" into YANG.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-129
Layer 2 P2P VPN Service Model (Cont.)
module l2vpn{ YANG statements representing our
namespace "http://com/example/l2vpn";
prefix l2vpn; informal design:
import ietf-inet-types { prefix inet; }
import tailf-ncs { prefix ncs; }  There can be many service instances.
import tailf-common { prefix tailf; }
augment /ncs:services {  Each instance has exactly two PE-CE links.
list l2vpn{
leaf intf-name { ... }
leaf pw-id { ... }
leaf customer { ... }

list link {
min-elements 2;
max-elements 2;
leafref device { ... }
leaf intf-number { ... }
leaf remoteip { ... }
}
}
}
}
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 14

The informal design from the previous page has now been converted into YANG. The figure only illustrates
the main statements and the hierarchy of objects. The final detailed YANG service model will be covered in
the last section.

1-130 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Optimization

Service Optimization Challenges

 Challenges:
 Automate allocation of pseudowire IDs
 Calculation of IP addresses for remote IPs
 Inventory of customer-facing interfaces
 Add support for another vendor

 Solutions:
 Make calls to an external allocator – programming library.
 Use mapping APIs to augment XML template.
 Use an external inventory system.
 Extend the mappings for new vendor.

When we are faced with the optimization of service parameters, we may have a challenge of how to create
certain values automatically so that we do not unnecessarily burden the operator and also minimize the
chances of human error when service instances are being provisioned.

In the sample service, we see that there is a need to find remote IP addresses. The question is — how are
going to do that?
 One solution may be to augment the template-based service model by adding a programmatic chunk that
calculates the values for the purpose of configuring the IP remote addresses on the link.
 Alternatively, we may change the rules (i.e. simplify them) so that we can achieve a working solution
without needing to add code to do the more complex calculation.
 The third option is to let the operator enter the IP address, which is suitable if Cisco NSO is integrated
with a frontend that is also integrated with an existing inventory system.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-131
Service Optimization Implementation
 Automate allocation of pseudowire IDs:
 Integrate with an external system using Reactive FastMAP.

 Calculation of IP addresses for remote IPs:

 Use IP address configured on remote router loopback interface.
 Default to Loopback0 IP.
 Part of the lab exercises.

 Inventory of customer-facing interfaces:

 Update service YANG model to perform additional checks.

 Add support for another vendor:

 Implement JunOS mappings.

In the final implementation of Layer 2 P2P VPN service we will cover all four optimization challenges.
Firstly, we are going to update service YANG model to include additional checks for selected customer-
facing interfaces. This will prevent operators from selecting the wrong values, e.g. interfaces that do not exist
on a chosen device.
Then, we will show how mapping logic can be easily extended through XML templates mechanism, adding
support for Juniper devices.
Later we will also discuss Reactive FastMAP approach. It will be used for integration with an external
pseudowire ID allocator system, automating allocation of this particular resource.
Lastly, you will obtain the IP addresses of remote routers automatically inside mapping logic. This will be
done as part of the lab exercises and will streamline service provisioning. By implementing programmatic
logic to do these tedious tasks instead of operators, we can avoid a lot of configuration mistakes.

1-132 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Layer 2 P2P VPN Service Model
…
list l2vpn {
The first part of the service model
key name; contains parameters describing the
unique pw-id; service instance:
uses ncs:service-data;
ncs:servicepoint "l2vpn";  Service instance name
leaf name {
tailf:info "Service Instance Name";  Service instance ID
mandatory true;
type string;
}
leaf pw-id {
tailf:info "Unique Pseudowire ID";
mandatory true;
type uint32 {
range "1..4294967295";
}
}
..
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 18

The first part of the YANG model describes the service instance.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-133
Layer 2 P2P VPN Service Model (Cont.)
… The second part of the service model
list link { contains the list statement for
tailf:info "Attachment Circuits"; attachment circuits.
min-elements 2;
max-elements 2;  There are two attachment circuits
key device; per VPN instance.
leaf device {
tailf:info "PE Router";  Each attachment circuit is defined by
mandatory true; the originating PE router.
type leafref {
path  The list of available devices is
"/ncs:devices/ncs:device/ncs:name"; obtained by referencing the NSO
} model.
}
…

The next part contains a list of links that define individual connections.

1-134 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Layer 2 P2P VPN Service Model (Cont.)
… The third part of the service model is
container ios {
when used to reference existing interfaces on
"/ncs:devices/ncs:device[ncs:name=current()/ supported device types.
../device]/ncs:device-type/ncs:cli/ncs:ned-
id='ios-id:cisco-ios'";
leaf intf-number {  YANG traversal using XPATH is used
tailf:info "GigabitEthernet to reference the actual interfaces.
Interface ID";
mandatory true;
type leafref {  This part is used to reference Cisco
path IOS interfaces using leafref.
"/ncs:devices/ncs:device[ncs:name=current()/
../../device]/ncs:config/ios:interface/ios:G
igabitEthernet/ios:name";
}
}
}
…

Finally, we need to reference specific device types. Note that this is only needed when we want to have a list
of available interfaces on the device available when we are configuring a service. Normally, we would want
our service model to be truly independent of underlying devices and avoid putting in any device model
dependency. The interface selection would be done either automatically within code or provided by the
northbound applications.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-135
Layer 2 P2P VPN Service Model (Cont.)
…  This part is used to reference Cisco
container iosxr {
when IOS XR interfaces.
"/ncs:devices/ncs:device[ncs:name=current()/
../device]/ncs:device-type/ncs:cli/ncs:ned-
id='cisco-ios-xr-id:cisco-ios-xr'";
leaf intf-number {
tailf:info "GigabitEthernet
Interface ID";
mandatory true;
type leafref {
path
"/ncs:devices/ncs:device[ncs:name=current()/
../../device]/ncs:config/cisco-ios-
xr:interface/cisco-ios-
xr:GigabitEthernet/cisco-ios-xr:id";
}
}
}
…

1-136 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Support for Juniper Service Configuration
JUNOS  The configuration is provided by the
ge-0/1/1 { network engineer.
encapsulation ethernet-ccc;
unit 0;  Different devices have different
} configuration for the same service.
protocols {
l2circuit {
neighbor 10.0.0.1 {
interface ge-0/1/1 {
virtual-circuit-id 1001121;
}
}
}
}

The figure illustrates the JUNOS configuration provided by the network engineer. It contains all
configuration options needed to deploy a Layer 2 MPLS VPN service instance using manual configuration.
From the configuration we can determine the set of parameters and options that will guide us when designing
a service model.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-137
Device Configuration Using Cisco NSO CLI
Juniper Configuration using Cisco CLI
admin@ncs(config)# devices device JUNOS0
admin@ncs(config-device-JUNOS0)# config junos:configuration interfaces interface ge-0/1/1
admin@ncs(config-interface-ge-0/1/1)# encapsulation ethernet-ccc
admin@ncs(config-interface-ge-0/1/1)# exit
admin@ncs(config-config)# junos:configuration protocols l2circuit neighbor 10.0.0.1
interface ge-0/1/1 virtual-circuit-id 12345
admin@ncs(config-config)# commit

 Essentially, we are able to use Cisco CLI to configure Juniper devices from within
Cisco NSO.
 The CLI navigates through the JUNOS YANG device model.

The figure illustrates the configuration of the Layer 2 MPLS VPN service through the Cisco NSO CLI.

1-138 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Device Configuration Template – JunOS
JUNOS XML Template
<config-template xmlns="http://tail-f.com/ns/config/1.0"> <protocols>
<devices xmlns="http://tail-f.com/ns/ncs"> <l2circuit>
<device tags="nocreate"> <neighbor>
<name>{$DEVICE}</name> <name>{$REMOTE-IP}</name>
<config> <interface>
<configuration <name>ge-{$INTERFACE-ID}</name>
xmlns="http://xml.juniper.net/xnm/1.1/xnm"> <virtual-circuit-id>{$PW-ID}</virtual-circuit-id>
<interfaces> </interface>
<interface> </neighbor>
<name>ge-{$INTERFACE-ID}</name> </l2circuit>
<encapsulation>ethernet-ccc</encapsulation> </protocols>
</interface> </configuration>
</interfaces> </config>
... </device>
</devices>
</config-template>

The figure illustrates the configuration of the Layer 2 MPLS VPN Juniper device through XML template.

Reactive FASTMAP
 It is a service activation approach used when not all data is available in a single
provisioning step such as:
 Service activation requires two or more stages
 Integrating with external resource allocating inventories
 Service need to adapt to changes in environment (e.g. VMs are rehosted)

 Core concept: service redeploy from external trigger, same create() method runs

By definition, a FASTMAP service is not allowed to perform function calls that have side effects – in effect,
the create() method must be idempotent. This is not exactly a limitation, as from the developer’s perspective,
the development process for service lifecycle management is greatly simplified, but sometimes, one still
needs to work around this design.
A popular counter-example for FASTMAP is a service that requires multiple configuration stages to activate.
The stages themselves may be dependent on systems external to Cisco NSO, and completing each stage may
take a considerable amount of time.
The Reactive FASTMAP design pattern can be applied in use cases like this. This pattern is also applicable
in use cases where the service needs to adapt to a changing environment. If, for example, the Cloud Manager
decides to move a virtual machine (VM) from one host to another, the service trigger application would
notice and request the affected services to be redeployed. The service application would then re-compute the
device configurations required to uphold the service in the new environment. Cisco NSO Device Manager
would then send out the net change to all affected devices, potentially even spinning up or down VMs as
necessary. If the service application is designed for this purpose, this adaptation may go on throughout the
entire life of the service.

1-140 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Reactive FASTMAP (Cont.)
Service Order Request
1. Service request arrives.
1
2. Service instance is created, but it
requires VM resources first. 5
Service Model
CDB
3. Device Manager first contacts the
Cloud Manager, which spins up 2 4
VMs.
Device Model
4. Once VM is ready, a service trigger
application invokes the service
6 6 6
application again.
3
5. Service redeploy is issued.
6. Now devices can be configured. Cloud Infrastructure Cloud Manager

1. A service order comes in from operator or operations support system (OSS).

2. Service application reads service instance data and configures network elements accordingly. If new
VMs (or other environment setup) are required before the actual network devices can be reached, the
service application configures the Cloud Manager to have additional VMs.
3. Cisco NSO Device Manager sends the first incarnation of this transaction to the network, requesting the
Cloud manager to spin up new VM(s).
4. A service trigger application is listening for VM change events and is notified when the new VM is
ready. The service trigger application starts a new NSO transaction, configures the new device VMs in
the NSO device list and commits.
5. The service trigger application issues a service redeploy on the service(s) that are pending the VM
creation. This will invoke the service application again, like in Step 2.
6. Only this time, all the necessary resources are available, and the service application will configure them
with the appropriate configuration. Cisco NSO Device Manager sends out the second incarnation of this
transaction to the network.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-141
Reactive FASTMAP Usage Guidelines
When to use Reactive FASTMAP When NOT to use Reactive FASTMAP
 Spinning up VMs first and configuring them  Configuration can be done at once
when available.  use regular FASTMAP.
 When some devices are not reachable until  Several service instances may configure
parts of the service have been set up. overlapping aspects of the devices or
underlying services
 Service automatically responds to changes  use pre- and post-modification callbacks.
in the environment (e.g. VM mobility,
network connectivity).  Events to wait for involve complex
interaction with people like service
 Service automatically responds to changes technicians
in service parameters (e.g. service catalog,  use a workflow engine.
policy).
 Service takes a long time to activate and
you do not want to lock the database.

1-142 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Subscribing to Changes
 Subscribe to changes in a specific subtree of the model.
Model
 All changes below that point will trigger the subscription.
 Two types of subscription:
 NavuCdbConfigSubscriber - configuration
 NavuCdbOperSubscriber - alarms, states etc.

 Both require the implementation of a diff interface:

 NavuCdbConfigDiffIterate Interface
 NavuCdbOperDiffIterate Interface

Subscribe to the subtree.

Subscriptions are a fundamental property of the configuration database (CDB), and can be used in many
scenarios. The CDB subscription mechanism allows an external Java program to be notified when different
parts of the configuration change. For such a notification, it is also possible to iterate through the change set
in CDB for that notification.
Subscriptions are typically used as part of Reactive FASTMAP process.
The first thing to do is to register in the CDB to which paths should be subscribed. This is accomplished with
the CdbSubscription.subscribe(...) method. Each registered path returns a subscription point identifier. Each
subscriber can have multiple subscription points, and there can be many different subscribers.
Every point is defined through a path – similar to the paths we use for read operations, with the difference
that instead of fully instantiated paths to list instances we can choose to use tag paths, i.e. leave out key value
parts to be able to subscribe on all instances. We can subscribe either to specific leaves, or entire sub-trees.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-143
Subscribing to Changes with NAVU (Cont.) Iterate over changes.
public DiffIterateResultFlag iterate(
 Use Cdb to connect Integer subId,
NavuContainer root,
 Register Callback ConfObject[] kp,
DiffIterateOperFlag op,
ConfValue oldValue,
 Cdb cdb = new Cdb("mycdb",socket); ConfValue newValue) {
//Navigate to our alarmlist
NavuList alarmList = root.
container(NcsAlarms._alarms_).
Set up subscriptions.
container(NcsAlarms._alarm_list_container_).
//Create the subscriber list(NcsAlarms._alarm_);
NavuCdbOperSubscriber sub =
new NavuCdbOperSubscriber(cdb,new //Get our modified alarm-id i.e. which alarm
NcsAlarms(),"AlarmSubscriber"); //was modifyed or added.
String kpString = Conf.kpToString(kp);
//Register a subscription point ConfKey key = (ConfKey)kp[0];
boolean regstatus =
sub.register(new MyIterate(), // check if the current alarm was added
"/alarms/alarm-list- // or changed state.
container/alarms", switch(op){
new NcsAlarms()); case MOP_CREATED:{ . . . }
sub.start();Iterate over changers case MOP_MODIFIED: { . . . }
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 30

It is often useful to add several subscription points to the same YANG node with different priorities. This can
be used to handle deletes before modifications and so on.

1-144 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Reactive FASTMAP Example

Reactive FASTMAP – VLAN Example

Service Order Request
1. Service request comes to the Service
1
Manager.
2. Service instance is created in CDB 5
Service Model
using create(). CDB
3. Create() notifies external application. 2 4
4. External allocates a new VLAN and
Device Model
writes it to CDB.
5. External application re-deploys the 6 6 6
service. 3
6. The create() method reads the
allocated parameter from CDB and
sets the parameters. Network Infrastructure Subscriber App

In this example application, we are going to provision new VLANs to the network infrastructure. List of
available VLAN identifiers (VLAN IDs) is stored and provided by an external application and is assigned to
each service instance automatically. When the instance gets deleted it is also automatically de-allocated. The
operator does not need to enter the VLAN ID and this is a common behavior when we are designing services
since we want to automate the service provisioning process as much as possible.
The main idea is to split the service into two components. The first is the actual service application, which
implements the create() method. The second is a custom application, which is going to subscribe to changes
in the configuration database (CDB) for this service type and assign VLAN IDs on service instance creation.
It will also de-allocate the VLAN IDs after the service instance gets deleted.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-145
Reactive FASTMAP – VLAN Example (Cont.)
Service Order Request

1
5
Service Model
CDB

Service (regular 2 4 Application Code

FASTMAP code) Steps:
3 4 5
Steps: Device Model
1 2 6
6 6 6
3

Network Infrastructure Subscriber App

Reactive FASTMAP is a design pattern that fits well when all data for a service is not yet available. In the
services discussed previously in this chapter, the service was modeled in such a way so that all required
parameters were given to the service instance. The mapping logic code could immediately do its work.
Sometimes this is not possible. When something must be allocated, maybe an IP address or vlan-id must be
allocated from some external system, it is not possible to do this allocation from within the normal
FASTMAP create() code. If we do that, there are no good ways to de-allocate. Furthermore, the create()
code runs within the transaction lock. We want to spend as little time as possible in the create() code.
To achieve what we want, we write our own application, which extends the service code. We take care of
resource allocation and de-allocation from within that application and pass the data back to the create()
method.

1-146 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Reactive FASTMAP Example – The YANG Model
 Enhance the module alloc-vlan-service { list alloc-vlan {
list alloc-vlan-data { key name;
YANG model to key name;
leaf name {
tailf:info "Unique service
include auxiliary leaf name { id";
type string; tailf:cli-allow-range;
structure. } type string;
container request-allocate-vid }
 VLAND ID leaf iface {
{ type string;
presence "Request a vlan
parameter is not id to be allocated"; }
mandatory true;
configurable – leaf vlan-id {
type uint16; leaf description {
config false. config false;
type string;
mandatory true;
tailf:cdb-oper { }
 Instruct Cisco tailf:persistent leaf-list arp {
type enumeration {
NSO that this true;
} enum no-gratuitous-arp-reply;
data will be } request;
enum no-gratuitous-arp-

handled internally } }
} }
– tailf:cdb-oper. … }
}
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 34

The example service will be used to assign an interface to a new VLAN. The input parameters for the service
are listed on the right side of the slide:
 alloc-vlan – service instance list
— name – string leaf
— iface – string leaf
— description – string leaf
— arp – enumeration leaf
In addition to the service model, the same YANG module (same file) contains an auxiliary structure for
storing VLAN allocation requests. This data needs to be hidden from the operator, as it is allocated by the
system. We accomplish this by marking the vlan-id as operational data, using the config false statement in
the auxiliary model. In addition, we also use the tailf:cdb-oper statement to persist the data in the CDB (by
default, operation data is not persisted). The model can be seen on the left side of the slide:
 alloc-vlan-data – resource request list
— name – string leaf
— request-allocate-vid – resource request container
— vlan-id – int leaf for the allocation result (operational data)
Shown here is the output of the yanger –f tree vlan.yang command, displaying the same structure:
module: vlan
+--rw alloc-vlan-data* [name]
+--rw name string
+--rw request-allocate-vid!
+--ro vlan-id? uint16
augment /ncs:services:

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-147
+--rw alloc-vlan* [name]
+--rw name? string
+--rw iface string
+--rw description string
+--rw arp* enumeration

1-148 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Reactive FASTMAP Example – The Service
 We call the sharedCreate() function to obtain a VLAN ID from the Application.
 The code below is placed within the create() function.

// Request resource (VLAN ID)

NavuContainer getVid = ncsRoot.list("alloc-vlan-data").
1 2
.sharedCreate(serviceKey.toString()) // Create list entry
.container("request-allocate-vid").sharedCreate(); // Create container
// Check for response (read operational data)
try {
vlanVal = cdbRoot.list("alloc-vlan-data").elem(serviceKey.toString()).
container("request-allocate-vid").leaf("vlan-id").value();
} catch (NullReferenceException e) { }
// Check for response (read operational data), wait for redeploy Exit if resource not
if (vlanVal == null) allocated
return;
// Use result in device config
6
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 35

The basic idea is to let the create() code not just write data in the /ncs:devices tree, but also write data in
some auxiliary data structure. A CDB subscriber subscribes to that auxiliary data structure and perform the
actual side effect, for example, a resource allocation. The response is written to CDB as operational data
where the service can read it during subsequent invocations.
The sample code on the slide is an excerpt from the beginning of the create() method, where a VLAN ID
resource is allocated. For understanding the hierarchy of nodes, refer to the explanation of the augmented
service model.
1. Service instance is created in CDB using create().
2. Create() notifies external application.
6. The create() method reads the allocated parameter from CDB and sets the parameters.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-149
Reactive FASTMAP Example – The Service (Cont.)
// Create help data
1
NavuList dataList = vlan.getParent().getParent().list("alloc-vlan-data");
NavuContainer data = dataList.sharedCreate(serviceKey);
// Create this reactive FASTMAP request and trigger the application
NavuContainer getUnit = data.container("request-allocate-unit").sharedCreate(); 2
...
try {
vlanVal = cdbRoot.list("alloc-vlan-data").
elem(serviceKey.toString()).
container("request-allocate-vid").
leaf("vlan-id").value();
}
catch (Exception e) {} 6
...
if (vlanVal != null) {
unit.leaf("vlan-id").sharedSet(vlanVal);
unit.leaf("enabled").sharedSet(new ConfBool(true));
ConfValue arp = vlan.leaf("arp").value();
if (arp != null)
unit.leaf("arp").sharedSet(arp);
}
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 36

1. Service instance is created in CDB using create().

2. Create() notifies external application.

6. The create() method reads the allocated parameter from CDB and sets the parameters.

1-150 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Reactive FASTMAP Example – The Subscriber Application
sub = cdb.newSubscription();
 VLAN ID must be int subid = sub.subscribe(1, new allocVlanService(), "/avl:alloc-
allocated by an vlan-data");
// tell CDB we are ready for notifications 3
external system. sub.subscribeDone();
...
 The create() code will if ((req.op == Operation.CREATE) && (req.t == Type.VID)) {
// This is the position in the code where the FM code
not handle resource // requests that we allocate a vlan-id, let's do that
de-allocation. int vid = alloc_vid(); 4
// Write the result and redeploy
System.out.println("SET: " + req.path + "/vlan-id ->" + vid);
 CDB subscriptions CDBsession.setElem(new ConfUInt16(vid), req.path + "/vlan-id");
are used to intercept // redeploy the service that consumes this data
redeploy("/avl:alloc-vlan{%x}/reactive-re-deploy", req.key,
CREATE service maapi);
requests. } 5
...
if (req.op == Operation.DELETE) {
 Resource // clean up oper data, and de-allocate vlan-id
de-allocation is try {
ConfValue v = wsess.getElem(req.path + "/vlan-id");
handled when a deallocate_vid(v);
DELETE request is CDBsession.delete(req.path + "/vlan-id");
}
intercepted. ...
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 37

The subscriber application is part of the same VLAN service package. The subscriber is implemented in a
separate class, which must implement the ApplicationComponent interface (extends Runnable). The interface
defines three methods that will run in a separate thread in the NSO Java VM:
1. init()—This method is called by the NSO Java VM before the thread is started. It is typically used to set
up sockets to the CDB, and set up the Subscription API.

2. finish()—This method is called by the NSO Java VM when the thread should be stopped. It is typically
used to clean up any open resources.
3. run()—This method is called by the NSO Java VM in a separate thread. This is where the subscription
implementation lies.
On the slide above, we have an example of the subscriber application. In the first part is a section of the init()
method – subscription setup.
In the second part is the evaluation of notifications on the subscription—resource allocation and
de-allocation.
3. Create() notifies external application: This is done using CDB subscribers.

4. External allocates a new VLAN and writes it to CDB: This is done by a custom function.
5. External application redeploys the service.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-151
Reactive FASTMAP Service and Subscriber
Init
Request
Resource
while
true

Check No
Resource Read
Yes subscription

Configure Allocate resource

+ redeploy

Done
Finish
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 38

The figure illustrates the configuration of the Layer 2 MPLS VPN service through use of Reactive
FASTMAP.

1-152 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Reactive FASTMAP Status
 Reactive FASTMAP service takes time to complete provisioning
 Service only partially configured when commit returns
 Needs to communicate status to operators

 Use service plan to report progress

 Plan defines components
 Starts with init state and finishes with ready state
 Different components may be doing provisioning in parallel
 Special component self represents the service
 All done when self reaches ready state

Reactive FASTMAP services typically take some time to finish provisioning. During configuration of such
services, commit starts the provisioning process and return almost immediately. How would an operator
know when this process completed and service is ready for use? Or, if an error was encountered during one
of the provisioning stages, how is it communicated back to the operator?

Cisco NSO provides a mechanism for communication of service status to operators, called service plans. On
creation each service instance defines a number of steps required (plan components) and starts provisioning
them, possibly in parallel. Every component starts in an init state and finishes in ready state. There may in
fact be other states component has to transition before reaching ready.

For interoperability reasons, a special self component should be defined for every service. It represents the
overall service progress. When self reaches ready state, service is ready for use.

Each of the steps in the provisioning process could also encounter an error. In such a case, service would
mark one or more of the states as failed. These state transitions provide a time stamp to help operators in
troubleshooting.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-153
Service Plan Example
admin@ncs# show services duo-vpn ACME plan
NAME TYPE STATE STATUS WHEN
-------------------------------------------------------
self self init reached 2016-08-16T14:40:08
ready not-reached -
vpn-1 l2vpn init reached 2016-08-16T14:48:19
ready reached 2016-08-16T14:48:19
vpn-2 l2vpn init reached 2016-08-16T14:48:19
ready not-reached -

admin@ncs#

 Service is still provisioning – self ready is not-reached.

 vpn-1 is configured (ready), still waiting on vpn-2.

The figure illustrates example plan output during provisioning of a service that uses Reactive FASTMAP.
Service is not yet provisioned as signified by component self. ready state is not yet reached.
There are two other components being provisioned; vpn-1 and vpn-2. The first one has completed, as both
init and ready states have been reached. The second one was also started (init reached) but we are still
waiting for it to finish (ready not-reached).

1-154 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Plan Usage
// YANG
uses ncs:service-data;
uses ncs:plan-data;

// Java
import com.tailf.ncs.PlanComponent;

PlanComponent self_plan = new PlanComponent(service, "self", "ncs:self");

self_plan.appendState("ncs:init");
self_plan.appendState("ncs:ready");
self_plan.setReached("ncs:init");
self_plan.setFailed("ncs:ready");

// Python
from ncs.application import PlanComponent

self_plan = PlanComponent(service, 'self', 'ncs:self')

self_plan.append_state('ncs:init')
self_plan.append_state('ncs:ready')
self_plan.set_reached('ncs:init')
self_plan.set_failed('ncs:ready')
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 41

Kicker

Kicker allows for triggering an action on configuration/operational data change in CDB

Create entry
L foo-service 1 L foo-data

K name K id
Set state
reactive-re-deploy CREATE Callback E state 2
Resource
Allocator

4 “kick” action 3 Detect change

kicker

Kicker support makes it possible to trigger an action whenever configuration or operational data changes in
CDB or any other data provider - this without any need to write and install a CDB subscriber, instead just
specify the name of the action and an xpath expression specifying when to trigger the action as an entry in
the tailf-kicker.yang data model.
This is useful in the general case of subscribers but even more useful for Reactive Fastmap Programming.
In the example on the slide, the service foo-service will create an entry in the auxiliary data structure foo-
data, to signal an external resource allocation request. The Resource Allocator will perform the operation,
and change the state of the request to done. This change will be detected by the kicker, triggering the
reactive-re-deploy action on the service instance. The kicker configuration enabling this process is shown on
the next slide.

1-156 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Kicker Model
module: tailf-kicker
+--rw kickers
+--rw data-kicker* [id]
+--rw id string
+--rw monitor nacm:node-instance-identifier
+--rw trigger-expr? yang:xpath1.0
+--rw trigger-type? enumeration
+--rw kick-node union
+--rw action-name yang:yang-identifier

kickers data-kicker foo-data-kicker

monitor /foo-data/state
trigger-expr . = 'done’
trigger-type enter
kick-node /foo-service[name=current()/../id]
action-name reactive-re-deploy

The kicker model allows configuring multiple observers to changes to data in the CDB.
The properties for configuring a single data-kicker are:
 id: unique ID for this data kicker
 monitor: node to monitor. Type is instance-identifier, but a list may be specified without any keys, and
will be treated as a wildcard matching all entries.
 trigger-expr: XPath 1.0 expression evaluated with the node that matched ‘monitor’ as the context node.
Can be used to trigger conditionally.
 trigger-type: Trigger the kicker whenever the trigger-expr changes value from false to true (value enter),
or in both cases (value enter-and-leave).
 kick-node: action-name will be invoked on the kick-node instance, or in the case of an XPath expression,
on the resulting node set.
 action-name: name of the action to invoke on kick-node.
In the example configuration on the slide, the monitored node is /foo-data/state for all list entries in the /foo-
data list. The additional trigger-expr will only kick the action when the state node changes to done. With the
use of the trigger-type true setting, the action is only kicked when the condition in the expression changes
from false to true. The kick-node is an XPath expression that finds the list entry in the list of foo-service
service instances for the instance that requested the resource. The context for the XPath expression is the
monitor node (state leaf), thus we are able to retrieve the current id (sibling of state). The action-name is the
name of the action on the kick-node. In this case, we are executing reactive-re-deploy to implement Rective
FASTMAP.

 Kicker model is hidden from NB interfaces (tailf:hidden debug)!

 Typically configured through APIs (apply template)

<config xmlns="http://tail-f.com/ns/config/1.0">
<kickers xmlns="http://tail-f.com/ns/kicker">
<data-kicker>
<id>foo-instance-resource-kicker</id>
<monitor>/foo-data/state</monitor>
<trigger-expr>.='done’</trigger-expr>
<kick-node>/foo-service[name=current()/../id]</kick-node>
<action-name>reactive-re-deploy</action-name>
</data-kicker>
</kickers>
</config>

The model for configuring kickers is hidden from northbound interfaces in NSO 4.2. Typically, kicker is
configured programmatically, using one of the APIs. On the slide, we show the XML configuration that may
be used from the service mapping logic in the form of a template.
If you want to access kicker configuration using the NB APIs (for example CLI), you have to unhide the
kickers node. First, NSO startup configuration ncs.conf must allow unhiding the debug group. Add a <hide-
group> with the debug name to the startup config, and the use the unhide command in the CLI.

1-158 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Summary
This topic summarizes the key points that were discussed in this lesson.
 Optimize service models to make operator's job easier.
 For P2P Layer 2 VPN service, the whole process of service activation can be reduced to selecting two PE
routers on the network edge.
 Services can be easily extended to support new vendors simply by providing additional service to device
mappings (XML).
 Reactive FASTMAP design pattern is used for services that require staged deployment.
 CDB subscribers are used to trigger custom code when certain events happen in the CDB. Subscriptions
can be placed in different places in the CDB and used for different actions.

© 2016 Cisco Systems, Inc. Service Provider VPN Service Design with NSO 1-159
1-160 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Module 2

Cloud VPN Service Design

2-2 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Lesson 2-1

Cloud VPN
Overview
This lesson introduces a more complex service application – Cloud VPN. In the second part, we describe
Cisco Elastic Services Controller (ESC) and explain how it integrates with Cisco NSO.

Objectives
Upon completing this lesson, you will be able to describe Cloud VPN and Cisco ESC. This ability includes
being able to meet these objectives:
 Describe how automation using Cloud VPN can improve the ability of fulfilling resource requests across
the service provider infrastructure
 Identify new business models available with Cloud VPN
 Explain end-to-end service orchestration
 Identify different Cloud VPN service topologies
 Explain Cisco ESC role in the NFV architecture
 Use Cisco ESC from Cisco NSO

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-3

Cloud VPN Overview

Business Case for Cloud VPN

 Service provider:
 Wants efficiency in service operation and maintenance (lower cost)
 Wants agility in service design and deployment (short time to market)
 Wants competitive services (more revenue)

 Customer:
 Wants the service(s); usually does not care how they are implemented
 Preferably at a lower price than before
 Can order cloud-based services instead of buying and maintaining physical appliances
(firewalls, IPS, etc.)

Service providers are looking for ways to deliver new services to customers more efficiently. They expect
more streamlined, preferably even real-time service lifecycle management at a lower cost. This results in
shorter time to market and ultimately in competitive offering and more revenue.
On the other hand, customers do not really care how services are implemented and how the service provider
manages the service lifecycle. They expect services that are reasonably priced, simple to use, and offer great
user experience.

Cisco Cloud Virtual Private Network (VPN) takes into configuration both the service provider and customer
requirements and delivers a service that offers:
 Simple and quick access and activation of Telco grade service in the Cloud.
 Simple, quick, automatic, and user-friendly VPN access for office and home.
 Secure communication—on-demand security features as new enterprise-app in the Cloud for all
locations—Dynamic QoS across secure VPN locations Managed NG-Firewall as new enterprise-app in
the Cloud.
 Simple and real-time traffic prioritization for crucial business applications.
 Self-serviced portal with great user-experience.
 Self-managed secure VPN communication between local and international branches.

2-4 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
What Does Cloud VPN Do?
 Uses VNFs to implement traditional network services in data centers, such as:
 Virtual PE (vPE) in data center instead of PE with complex MPLS/MP-BGP setup
 Virtual security appliances (e.g. network firewall, IPS, web security)

 Provides service operation tools for provisioning and self-provisioning of network

functions:
 Physical network devices (traditional): L2 and L3 MPLS VPNs
 Virtualized network functions: L2 (L2TPv3, Keyed IPv6) and L3 (IPsec, GRE, L2TP) VPNs
across the network terminating at virtual PE routers (vPE)

The Cloud VPN service provides new and existing customers with a customer premises equipment (CPE)
which quickly and easily installs behind their broadband routers or modems. Using automated technologies,
the CPE self-installs and ensures that all cloud applications and services run seamlessly. As a prerequisite, all
customer locations only need to have Internet access.
The benefit of this installation option means that no additional client software is required as all users on the
company Broadband line use VPN seamlessly.

Cloud VPN provides the following services:

1. Self-service portal: Self-manage browser-based customer portal with all Cloud VPN-managed
functionalities and features.

2. Auto VPN:
 Add/Remove VPN location:
— Customer enters the shipping address of the location the customer wants to connect in VPN
— Order goes to order management system where CPE is sent to customer location (shipping
address)
— Customer connects CPE into their network and is automatically configured and connected in
VPN
— If the customer already has a supported CPE, the customer has the possibility to register their
existing CPE and is automatically connected in VPN
— Auto-provisioning of VPN (secure connection between customer location and DATA center)
— VPN site-to-site connectivity – all sites are established through one click and by entering the
branch address or selecting an already registered branch
— Automatically (pre)configured VPN parameters (zero-touch provisioning from customer side)
— Configuration interface for NAT/PAT (e.g. port release, exposed host)

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-5

— Real-time view of VPN site connectivity
— Provisioning of SSL VPN username/passwords for remote access VPN.
3. Managed Security
 Intrusion detection (protecting a network against malicious entities and threats) – only with the option
Next-Generation Intrusion Prevention System (NG-IPS)
 Antivirus functionality with configuration possibilities for
— Real-time malware detection
— Anti-malware scanning engine
— Layer 4 traffic monitoring
 Mail security
 DDOS Protection
 Web content filtering functionality with configuration possibility for
— Web usage controls (URL/content based)
— Application visibility and control
— Data loss prevention
 Interface for firewall configuration to manage connectivity between sites and the Internet, and between
remote users and CPE-based sites on different granularity levels:
— FW rules on TCP/IP level
— Per Applications for predefined applications or application classes
— Per End-Points Device types (PC, Smart phones, and Tablets)
4. Quality of service
 Traffic prioritizing per location (Customer can define uploading or downloading bandwidth speed per
location based on business requirements)
 Traffic prioritizing per application (Customer can define uploading or downloading bandwidth speed
per Desktop or Smartphone application based on business requirements)
 Traffic prioritizing per end user (Customer can define uploading or downloading bandwidth speed per
end user on business requirements)
 Traffic prioritizing per device (Customer can define uploading or downloading bandwidth speed per
device on business requirements – e.g. PC has higher bandwidth speed priority than Smart phone and
Tablets)
5. Monitor & reporting:
 Per location traffic usage
 Real-time view of VPN site connectivity
 Traffic usage per application, end-point, device type and per web-content (e.g. URL domain)
 Advanced monitoring with automatic notification (e.g. if Customer reaches a specific limit for traffic or
bandwidth speed (based on defined thresholds or rules) per location/application/end user/device or
traffic/bandwidth priority has been changed, Customer gets automatic e-mail notification
 Connectivity status
 Reporting:

2-6 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
— Time periods:
 Real time
 Customer-defined time period
— Aggregation:
 For one site
 Aggregated for customer-defined group of sites
— Report types:
 Bandwidth reports (per location, application, end device )
 QoS reports
 This cannot be done at this time. Investigate as per previous comment R6
 This cannot be done at this time. Investigate as per previous comment R6.
 Phase 2 or beyond
 Need to discuss, traffic per-user/device not possible.
 May not be possible

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-7

Cloud VPN Network Topologies
Tunneling across provider network
SP Data Center

L3 or L2
RTR FW Internet
SP Network VM VM
CPE Internet
Gateway

Day-0 provisioning WSA

NG-IPS
VM VM

VNFs: provisioning (instantiation

 Orchestration of many components and configuration)

 Dependencies between components

Cloud VPN supports several network topologies within the data center. Each of the nodes in the topology is
automatically instantiated and configured.

2-8 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
High-Level Design
User Interface Front End

Auth/Roles integration Model to UI API

Logging integration Portal
Billing integration Interface App/Business Logic Back-End Logic
CRM DataBase integration API
Others

Orchestrator NSO Orchestration

RTR FW
CPE NG-IPS WSA Internet
VM VM VM VM
Gateway
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 7

Cisco Network Services Orchestrator (Cisco NSO) provides the network orchestration layer between the
higher-level business systems, which implement the business logic and provide user interfaces, and the
underlying networking and compute components, which provide network services and connectivity.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-9

Cloud VPN Network Topologies

Cloud VPN Service Topologies

Sample Service 1: FW + Internet
Layer-3
IOS Firewall
Tunneling

IPsec
Internet
SP Network RTR
CPE VM Internet
Gateway
VPN aggregation using
IPsec (CSR1k)
 Services:  SLA:
 Internet Access  Bandwidth [Mbps]: 10, 25, 50, 100, …
 Network Firewall (IOS)

As a service, Cloud VPN comes in different packages. Each of those packages adds new functionality on top
the basic VPN connectivity, and also dictates a new topology.

2-10 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cloud VPN Service Topologies
Sample Service 2: FW + RA + Internet
Network firewall Remote access service
service (ASAv) using IPsec or SSL

IPsec
Internet
SP Network RTR FW
CPE VM VM Internet
Gateway
VPN aggregation
using IPsec (CSR1k)
 Services:  SLA:
 Network Firewall  Bandwidth [Mbps]: 10, 25, 50, 100, …
 Internet Access  RA users: 10, 50, 100, …
 Remote Access

Cloud VPN can support one premise CPE connectivity as well as remote access users. In this scenario, a
virtual firewall is added to the network topology to support the remote user access.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-11

Cloud VPN Service Topologies
Sample Service 3: FW + RA + WSA + Internet

IPsec
Internet
SP Network RTR FW
CPE VM VM Internet
Gateway

Virtual Web Security Appliance

 Services: (vWSA):
 Network Firewall  Advanced malware protection
 Web reputation filters
 Web Firewall WSA
VM
 Internet Access
 Remote Access

As an additional service, a Web Security Appliance (WSA) can be chosen. This dictates that WSA be added
to the network topology.

2-12 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cloud VPN Service Topologies
Sample Service 4: FW + RA + IPS+ Internet

IPsec
Internet
SP Network RTR FW
CPE VM VM Internet
Gateway
WCCPv2
NG-IPS (Sourcefire):
 Services:  Real-time contextual awareness
 Network Firewall  Advanced threat protection
 Intelligent security automation
 Intrusion Prevention System NG-IPS
VM  Application Control and URL
 Internet Access Filtering and Advanced
 Malware Protection
 Remote Access

As an additional service, an Intrusion Prevention System (IPS) can be chosen. This dictates that an NG-IPS
be added to the network topology.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-13

Cloud VPN Service Topologies
Sample Service 5: FW + RA + IPS+ Internet
Layer 2 VPP for aggregation of
Tunneling L2 tunnels

L2TPv3 L2
SP Network vPE RTR FW
Internet
CPE VM VM Internet
Gateway
L2

 Services:
 Layer 2 connectivity between CPE and SP DC
 Network Firewall NG-IPS
VM
 Intrusion Prevention System
 …

As an alternative to Layer 3 IPsec, L2TPv3 can be used to create Layer 2 connectivity between the customer
site and the data center. This dictates that the Layer 2 tunnels be terminated on a virtual provider edge (vPE)
router instead. This is an alternative to directly terminating Layer 3 tunnels on customer´s virtual router.

2-14 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cloud VPN Service Topologies
Sample Service 6: Locally Redundant
Routing and HSRP for Firewall cluster (active/active
redundancy or active/standby)

RTR FW
VM VM Internet
SP Network HSRP A/A or A/S HSRP Gateway Internet
CPE

RTR FW
VM VM Internet
Gateway
 Prevents single points of failure (except entire DC failure)
 Optionally uses redundant CPEs
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 14

Cloud VPN can avoid failure by providing locally redundant topologies and/or dual-homed CPEs.
Optionally, even redundant CPEs can be used to provide redundant Cloud VPN connectivity.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-15

Cloud VPN Service Topologies
Sample Service 7: Geographically Redundant
Routing for redundancy

RTR FW
VM VM Internet
Gateway

IPsec
CPE SP Network Internet

CPE

RTR FW
VM VM Internet
Gateway
 Prevents single points of failure
 Optionally uses redundant CPEs
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 15

The figure shows an example of a geographically redundant Cloud VPN, hosted in two different data centers.

2-16 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Architecture Overview

Software-Driven Architecture
User Self-Service Portals Business Operations, OSS/BSS
Data Model
Driven
Adaptation

abstraction stack
e2e services

decomposition
S automation
Control: Real-Time Network OSS, Orchestration controllers

plugins
D Programmability: YANG over NETCONF, RESTCONF, RESTful , JSON agents

services
Logical: IP and Overlay Transport, (Virtualized) Service Creation topologies
N devices
Physical: IP Network, x86 Compute topologies

Real-time SDN
Packet Network Orchestration and OSS
User All
Area Access
Data Center
LTE DC
Internet
MSAN

OLT DC
Services

© 2016 Cisco and/or its affiliates. All rights reserved.

Packet flows Internet peerings Advanced Cisco Network Services Orchestrator v2.0 17

Cloud VPN uses a layered architecture that is directly related to commonly proposed Software-Defined
Networking (SDN) architectures.
 The Control or Specification Layer: Contains the service logic. Operations support systems (OSS)
reside at this layer.
 The Network Operating System Layer: Provides network programmability and abstraction. Cisco
NSO resides at this layer.
 The forwarding layer is split into:
— Logical Layer: Provides Overlay topologies and Network Function Virtualization (NFV).
Cloud Manager and vSwitch reside at this layer.
— The Physical Layer: Represented by physical network infrastructure like MW links, Fiber,
servers, switches, routers and so on.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-17

Layered Approach
 The Service Layer is independent of the device layer
 There are no limitations to the number of layers
 Multilayered services
 Topology layer
 IETF compliant!
CPE1 Tunnel 0 Service Layer
CPE2 Tunnel 1

CPE3 Tunnel 2 vRouter vFirewall

Internet
Router

Packet Network Device Layer

User All
Area Access
Data Center
LTE DC
Internet
MSAN

OLT DC
Services

© 2016 Cisco and/or its affiliates. All rights reserved.

Packet flows Internet peerings Advanced Cisco Network Services Orchestrator v2.0 18

The layered approach makes it possible for services to be completely independent of the physical layer. This
is made possible by using YANG modeling within Cisco NSO. An additional layer is introduced according
to the Internet Engineering Task Force (IETF) drafts, which makes it possible to apply services to any
topology. Cisco NSO specifies three layers described by YANG:
 Service,
 Topology
 Device

2-18 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Software-Driven Architecture (Cont.)
 Reduces or even eliminates the marginal cost of service creation
 Eliminates human operator intervention
 Enables custom back-end integration
 Examples:
 Self-service portals: ~0 marginal cost, no operator intervention
 OSS/BSS integration: minimal cost, minimal operator intervention, more robust systems,
cheaper upgrades
 Order fulfillment happens in real time: changes applied end to end, without waiting for a
technician

The result of using a layered approach is the reduction or even elimination of marginal cost of service
creation. By providing an end-to-end service orchestration across all layers, it also eliminates human operator
error or intervention and makes a real-time service activation possible. Thanks to abstractions, the system can
easily be integrated with other back-end systems and the customer can also use self-service portals, which
reduces operator intervention to a bare minimum.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-19

Cloud VPN Business Services Use Case #1: Virtual Firewall
Service Provisioning
Cloud-hosted
NFV service chain:
management,
scalable, elastic,  Create: VR terminating
on-demand
overlay tunnels from CPE
Inet  Create: vFW with:
VR vFW GW
 NAT and Policy
CPE  IPsec/SSL for remote access
Internet including remote end-host
SP CLOUD
posture assessment

 Create: Internet gateway

CPE connecting to the Internet
CPE Overlay Packet Tunnels
 Keyed IPv6 tunnels
© 2016 Cisco and/or its affiliates. All rights reserved.
 IPsec tunnels Advanced Cisco Network Services Orchestrator v2.0 20

The figure illustrates an example of initial service provisioning within Cloud VPN.

2-20 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cloud VPN Business Services Use Case #2: Virtual Firewall + IPS
Service Modification
Cloud-hosted
NFV service chain addition:
management
scalable, elastic,  Create: vNG-IPS
on-demand
(SourceFire) for advanced
threat protection and real-time
Inet
VR vFW GW contextual awareness
vIPS
CPE
Internet
SP CLOUD

 Single-click provisioning
 Automated creation and
CPE
configuration
CPE

The figure illustrates an example of service modification or service update within Cloud VPN.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-21

CloudVPN Business Services Use Case #3: vFW + vWSA
Service Deletion
Cloud-hosted
NFV service chain replacement:
management
scalable, elastic,  Create: WSAv for enhanced
on-demand
web security
Inet  Delete: vIPS for advanced
VR vFW GW
threat protection
WSAv
CPE
Internet
SP CLOUD

CPE

CPE
 Single-click de-provisioning
 Automated deletion
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 22

The figure illustrates an example of service de-provisioning within Cloud VPN.

2-22 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cisco Elastic Services Controller (Cisco ESC)

NFV Orchestration
 Traditional orchestration – coordination of business and operational processes
in order to deliver a service.
 NFV orchestration requirements:
 Rapid configuration, provisioning, and chaining of VNFs.
 Intelligent service placement – optimal physical/virtual location.
 Dynamic and elastic scaling of services.
 Full lifecycle management of VNFs.

NFV decouples the network function from the hardware. However, extracting maximum value from
NFV‑based services requires new orchestration capabilities.
Traditional orchestration, in the broader context of service fulfillment, is the process of coordinating and
aligning business and operational processes in designing, creating, and delivering a defined service. This
orchestration process involves the use and management of complex systems and tools such as order,
inventory, and resource management systems. It also includes configuration and provisioning tools and
operating support systems (OSSs) combined with the processes associated with these tools and systems.
Orchestration solutions play a critical role for service providers by automating tasks across technologies and
organizations by integrating with business support systems (BSSs) and customer-relationship-management
(CRM) systems orchestration and by ultimately reducing order-to-revenue time.

NFV orchestration has unique requirements based on the need to automate the highly dynamic delivery of
virtualized network services based on service intent, compared to traditional orchestration for services on
physical appliances. These requirements include:
 Rapid configuration, provisioning, and chaining of virtual network functions (VNFs): In addition to
other resources required for the service, the ability to chain several VNFs together is an important and
differentiating feature to create innovative and customized services.
 Intelligent service placement: A key benefit of NFV orchestration is automating the determination and
selection of an optimal physical location and platform on which to place the VNFs. This determination
depends on various business and network parameters such as cost, performance, and user experience. A
VNF can be placed on various devices in the network – in a data center, in a network node, or even on
customer premises.
 Dynamic and elastic scaling of services: The orchestration process maps the instantiation of VNFs
against real-time demand. This capability frees up physical capacity to be used by other services. In
doing so, service providers use their infrastructure more efficiently. They can also achieve a more
predictable and optimized return on investment (ROI) by deploying additional network services without

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-23

unnecessary equipment cost. This ROI is especially beneficial for service providers with limited
subscriber populations and faced with having to add hardware that may significantly exceed the demand
for services in the foreseeable future.
 Full lifecycle management of VNFs: This management includes the creation, instantiation, and
monitoring of the VNF until it is decommissioned.

2-24 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
NFV Management and Orchestration Architecture
Service, VNF, and
Service Catalog OSS Infrastructure
Description

NFV
Services Orchestrator Orchestrator

VNF Manager Third-party VNFM VNF Manager

Virtual
Openstack VMware SDN Controller Infrastructure
Managers

vCPE ASAv Third-party VNF VNF Library

The figure illustrates the three key functional building blocks that provide NFV management and
orchestration functions. The architecture follows the ETSI MANO (Management and Orchestration)
framework.
The Services Orchestrator operates at the resource-facing services (RFS) layer and is responsible for
providing the overall lifecycle management at the network service level. It uses model-based workflows that
enable the design of services based on predefined service elements and the reuse of existing service
templates, allowing service providers to rapidly fulfill a wide variety of services. The Services Orchestrator
provides a standards-based northbound interface for transparent integration with systems that operate at the
customer-facing services (CFS) layer such as the service catalog or RT-OSS . The actual implementation will
depend on the customer’s specific deployment requirements.
The Services Orchestrator also provides intelligent workload automation by using real-time analytics and
performance monitoring. Based on factors such as hardware and VM usage data as well as inventory, fault,
performance, and analytics data for the deployed VNFs, services can be strategically placed in the most
optimal locations across the infrastructure. This placement enhances service performance and availability
while optimizing the use of resources.
The Services Orchestrator also enables policy-directed capacity management, which involves the setting and
enforcement of policies and the use of resources based on business considerations, compliance requirements,
and service-level agreements (SLAs). For example, service providers can set thresholds on the run rate (cost
of operations) of implementing an NFV service in alignment with their business objectives. A compliance
requirement may include ensuring a level of security provisioned with a VNF to comply with industry or
government regulations, whereas SLAs may require specific bandwidth or quality-of-service (QoS) settings.
The VNF Manager provides scalable, automated VNF lifecycle management, including the creation,
provisioning, and monitoring of both Cisco and third-party VNFs. Unlike many other vendor solutions, the
Cisco implementation is agentless, helping optimize the overall performance in VNF management.
The VNF Manager is also responsible for the scale-up and scale-down of VNFs based on dynamic and
fluctuating service demands. It uses cloud-computing resource managers such as OpenStack and VMware at
the Virtualized Infrastructure Manager (VIM) layer to configure and provision compute and storage
resources across multivendor data center networks.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-25

The SDN Controller is responsible for connecting the virtualized services (a VNF or a set of chained VNFs)
to the service provider VPNs, the Internet, or both. It is designed around open standards and APIs and uses a
holistic systems-based approach to managing multivendor and multitenant data centers, and a common
policy-based operating model to drastically reduce costs and complexity.

Other functions of NFV management and orchestration include, but are not limited to:
 Assigning IP addresses to physical and virtual resources
 Loading new device and service models (a software image on a VM would be required to deploy a VNF)
 Updating service model attributes (default attributes may be available, but the operator may want to
modify these attributes based on the specific service requirement)
 Ensuring certificate authority; system identity; authentication, authorization, and accounting (AAA)
management; and crypto functions for authorization purposes and for the enforcement of licensing

2-26 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
ETSI MANO
 ETSI MANO is a framework, specifying components and interfaces
required to implement management and orchestration of VNFs.
 Three functional layers:
1. NFV Orchestrator (NFVO)
2. VNF Managers (VNFM)
3. Virtual Infrastructure Managers (VIM)

 Modularity of the architecture allows for building a multi-vendor

infrastructure.

NFV MANO (or ETSI MANO) is a reference architecture, published by the Network Function Virtualization
(NFV) group, part of the European Telecommunications Standards Institute (ETSI). The architecture
specifies the components that are part of an architecture for management and orchestration (MANO) of
Virtual Network Functions (VNFs).

The framework defines three functional layers on the management and orchestration side:
 NFV Orchestrator (NFVO): The orchestrator provides lifecycle management of the network services,
which includes instantiation, scale-out/-in (called elastic scaling), performance measurements, event
correlation, resource management, validation and authorization for resource requests, and policy
management. In Cisco Virtual Managed Services (Cisco vMS) solution, for example, Network Services
Orchestrator (NSO) is used as the sole orchestrator.
 VNF Managers (VNFMs): The VNF managers handle the configuration, lifecycle management, and
element management of the virtualized network functions. In Cisco vMS solution, Elastic Services
Controller (ESC) is used as VNFM.
 Virtualized Infrastructure Managers (VIMs): This layer handles the virtualization of physical
hardware in the data center by integrating with virtual-machine managers. Using a hypervisor, the
virtual-machine manager provides the ability to create multiple virtual compute, network, and storage
elements. The virtual machines provide lifecycle management functions (create, edit, delete, start, and
stop) for the virtual data center elements related to compute, network, and storage functions. In Cisco
vMS solution, OpenStack is used as VIM.
Because the reference architecture is modular and not tied to any specific implementation or vendor, it can be
used to build a multi-vendor NFV infrastructure with relative ease.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-27

ETSI MANO (Cont.)
NSO

ESC

Openstack

The figure displays the ongoing ETSI MANO framework and the components described in the introduction.

2-28 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cisco Elastic Services Controller
 Cisco ESC is a VNFM for managing NFVO
Cisco and third-party VNFs
(agentless)
 Model-driven (based on ConfD) NETCONF REST

 Integration with any NFVO in Cisco ESC

northbound via NETCONF, REST,
Portal Openstack/
VMware
KVM
 Integration with Openstack and
VMware VIMs in southbound
VIM

Cisco Elastic Services Controller (ESC) is built as an open and modular architecture that allows OSS, and
multi-vendor support. It performs lifecycle management of the VNFs, that is, VNF onboarding, configuring
the VNFs, monitoring them, and making VNF-level lifecycle decisions such as healing and scaling based on
the KPI requirements. Cisco ESC and its managed VNFs are deployed as VMs running within a VIM.
Currently, OpenStack and vCenter 5.5 are the supported VIMs. Cisco ESC core engine manages transactions,
validations, policies, workflows, VM state machines, and rollbacks. The monitoring and actions service
engine in Cisco ESC performs monitoring based on several monitoring methods. Events are triggered based
on the monitoring actions. The monitoring engine also supports custom monitoring plugins.
Cisco ESC interacts with the top orchestration layer using the REST and NETCONF/YANG NB APIs. The
orchestration layer can be a Cisco NSO or any third party OSS. ConfD enables integration with Cisco NSO
by adding NETCONF/YANG northbound interface support. A configuration template, Virtual Network
Function Descriptor (VNFD) file is used to describe the deployment parameters and operational behaviors of
the VNFs.
Cisco ESC fully integrates with Cisco and other third-party applications. As a standalone product, Cisco ESC
can be deployed as a VNF Manager. Cisco ESC integrates with Cisco NSO to provide VNF management
along with orchestration. Cisco ESC as a VNF Manager targets the virtually managed services and all service
provider NFV deployments such as virtual video, Wi-Fi, authentication and so on. Complex services include
multiple VMs that are orchestrated as a single service with dependencies between them. These multiple VMs
are managed as a single entity, such as, Cisco Virtually Managed Services (vMS) 1.0 and later.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-29

Key Features of Cisco Elastic Services Controller
 Modular architecture allows multi-vendor OSS, VNF, and VIM support
 End-to-end dynamic provisioning and monitoring of virtualized services.
 Customization of different phases of VNFs (day0/day1/day2
operations).
 Agentless monitoring with a complex rules engine for taking actions
 Scale in/out options based on the VNF load

The key features of Cisco ESC are:

 Provides an open and modular architecture, which allows multi-vendor OSS, VNF and VIM support.
 Provides end-to-end dynamic provisioning and monitoring of virtualized services using a single point of
configuration.
 Provides customization across different phases of lifecycle management; while monitoring the VM,
service advertisement, and custom actions.
 Provides agentless monitoring with an integrated Monitoring Actions (MONA) engine. The monitoring
engine provides simple and complex rules, to decide scale in and scale out of VMs.
 Provides scale in and scale out options based on the load of the network.
 Deploys or removes VMs based on the monitoring errors and threshold conditions detected as part of
healing (also called as recovery).
 Supports service agility by providing faster VNF deployment and lifecycle management.
 Supports multi-tenant environments.
 Supports REST and NETCONF/YANG interfaces to provide better hierarchical configuration and data
modularity.

2-30 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Key Features of Elastic Services Controller (Cont.)
 Deploys or removes VMs based on the monitoring errors and threshold
conditions detected as part of healing (recovery)
 Supports service agility by providing faster VNF deployment and
lifecycle management
 Support for multi-tenant environments
 Model-driven northbound REST and NETCONF/YANG interfaces to
provide better hierarchical configuration and data modularity

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-31

VNF Lifecycle Management
Onboard

Un-deploy Deploy

ESC
Update Monitor

Fault
Scale
Recover

Cisco Elastic Services Controller (Cisco ESC) provides a single point of control to manage all aspects of
Virtual Network Function (VNF) lifecycle for generic VNFs in a dynamic environment. It provides advanced
VNF life cycle management capabilities through an open, standards-based platform that conforms to the
ETSI VNF management and orchestration (MANO) reference architecture.
In Cisco ESC Release 2.0, you can orchestrate VNFs within a virtual infrastructure domain—either in an
OpenStack or ESXi 5.5 environment. A VNF deployment is initiated as a service request. The service request
comprises templates that consist of XML payloads. Hybrid VNF deployment is not yet possible in the current
version.

The VNF lifecycle diagram shown displays the following phases:

 Onboarding: In Cisco ESC, you can onboard any new VNF type as long as it meets the prerequisites for
supporting it in an OpenStack and VMware environment. For example, in OpenStack environment,
Cisco ESC supports the QCOW2 image format and config drive support for the VNF bootstrap
mechanism. You can define the XML template for the new VNF type to onboard the VNF with Cisco
ESC.
 Deploying: When a VNF is deployed, Cisco ESC applies “day-zero” configuration for a new service. A
typical configuration includes credentials, licensing, connectivity information (IP address, gateway), and
other static parameters to make the new virtual resource available to the system. It also activates licenses
for the new VNFs.
 Monitoring: Cisco ESC integrates with the host hypervisor, whether KVM/OpenStack or VMware, to
monitor the health of virtual machines. It tracks performance metrics such as CPU use, memory
consumption, and other core parameters. The requester can specify all of the characteristics (for example,
vCPU, memory, disk, monitoring KPIs, and more) typically associated with spinning up and managing a
virtual machine in an XML template. It also provides an elaborate framework to monitor service
performance-related metrics and other key parameters that you define.
 Healing: Cisco ESC heals the VNFs when there is a failure. The failure scenarios are configured in the
KPI section of the datamodel. Cisco ESC uses KPI to monitor the VM and the events are triggered based
on the KPI conditions. The actions to be taken for every event that is triggered is configured in the rules
section during the deployment.
2-32 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
 Updating: Starting from Cisco ESC Release 1.1 and onwards, Cisco ESC allows deployment updates
during deployment. You can either perform all the updates (that is, add or delete a vm_group, add or
delete an ephemeral network in a vm_group, and add or delete an interface in a vm_group) in a single
deployment or individually.
 Un-deploy: Cisco ESC allows you to un-deploy an already deployed VNF. This operation is either done
using the northbound APIs or through the Cisco ESC portal.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-33

Deploying Virtual Network Functions in OpenStack
 Deploy a VNF to a particular tenant
 Three different deployment scenarios:
1. Deploying VNFs (creating images and flavors through Cisco ESC)
2. Deploying VNFs (using out-of-band images and flavors)
3. Deploying VNFs with Service Registration

In Cisco ESC, VNF deployment is initiated as a service request either originating from the Cisco ESC portal
or the northbound interfaces. The service request comprises templates that consist of XML payloads. These
resources must either be available in OpenStack or can be created in Cisco ESC using the Cisco ESC portal
or the northbound interfaces. The deployment datamodel refers to the resources to deploy VNFs in the
OpenStack environment.

In general, the deployment scenarios are split into two groups:

 Standalone VNFs or groups of VNFs
 Service oriented VNFs or groups of VNFs

Scenario 1: Deploying VNFs (creating images and flavors through Cisco

ESC)
You can deploy VNFs without a service registration process. In this scenario, the OpenStack images and
flavors are defined and created and managed through Cisco ESC. The advantage of this approach is that you
can reuse the same image and flavor definitions by multiple deployments, and manage them from a central
location (Cisco ESC). A northbound system sends a request to Cisco ESC describing the deployment,
images, and flavors.

Scenario 2: Deploying VNFs (using out-of-band images and flavors)

This scenario is similar to Scenario 1 in the sense that deployments are still not defined through a service, but
rather on an individual basis. The OpenStack images and flavors must already exist in the OpenStack
environment, otherwise, the deployment will fail. A northbound system sends a request to Cisco ESC
describing the deployment.

Scenario 3: Deploying VNFs with Service Registration

In this scenario, VNF deployment is a two-step process. In the first step, the service is registered, containing
a description of the deployment, images, and flavors to be used. In subsequent steps, service instances are
2-34 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
created in the form of deployments. A northbound system sends a request to Cisco ESC describing the
deployment, but in this case, a service defines the defaults and constraints for deployment parameters.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-35

Cisco ESC Notifications – NETCONF
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# devices device esc0 netconf-notifications subscription vm-status stream
escEvent local-user admin reconnect-interval 5

admin@ncs# show devices device esc0 netconf-notifications received-notifications

netconf-notifications received-notifications notification 2016-01-14T13:57:31.625+00:00 0
user admin
subscription vm-status
stream escEvent
received-time 2016-01-14T13:57:32.012128+00:00
data escEvent status SUCCESS
data escEvent status_code 200
data escEvent status_message "Service group deployment completed successfully!"
data escEvent depname second-deployment
data escEvent tenant esc-lab
data escEvent depid 9df3c2f4-c40a-4fef-bbf9-5f93ea8896c3
data escEvent event type SERVICE_ALIVE

During a VNF lifecycle, every event is tracked within Cisco Elastic Services Controller (Cisco ESC). Other
systems (NFVO for example) can be notified of such notifications via two mechanisms:
 NETCONF notifications
 REST callbacks
NETCONF notifications are built into the protocol. If the northbound orchestrator is integrated with Cisco
ESC via NETCONF, it simply has to subscribe to receive notifications from Cisco ESC event stream.
For example, if the NFVO is Cisco Network Services Orchestrator (Cisco NSO), the following commands
can be used to subscribe to and examine the notifications:
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# devices device esc0 netconf-notifications subscription
vm-status stream escEvent local-user admin reconnect-interval 5

admin@ncs# show devices device esc0 netconf-notifications received-

notifications
netconf-notifications received-notifications notification 2016-01-
14T13:57:31.625+00:00 0
user admin
subscription vm-status
stream escEvent
received-time 2016-01-14T13:57:32.012128+00:00
data escEvent status SUCCESS
data escEvent status_code 200
data escEvent status_message "Service group deployment completed
successfully!"

2-36 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
data escEvent depname second-deployment
data escEvent tenant esc-lab
data escEvent depid 9df3c2f4-c40a-4fef-bbf9-5f93ea8896c3
data escEvent event type SERVICE_ALIVE
This example notification – SERVICE_ALIVE in particular, is sent by Cisco ESC at the end of a successful
deployment, when all VNFs in a deployment are operational.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-37

Cisco ESC Notifications – REST Callback
 NFVO -> ESC via REST
POST /v0/deployments/123 HTTP/1.1
Host: client.host.com
Content-Type: application/xml
Accept: application/xml
Client-Transaction-Id: 123456
Callback:/deployservicecallback
Callback-ESC-Events:/escevents
<datamodel>
<version>1.0</version>
<service_definition>
. . .
</service_definition>
</datamodel>

REST callbacks can be used in the case NFVO is integrated with Cisco ESC via the REST API. Along with a
deployment request, the northbound orchestrator sends a callback URL, to be notified of deployment status
by Cisco ESC.
Sample request from NFVO to ESC for a new deployment, including the callback URLs:
POST /v0/deployments/123 HTTP/1.1
Host: client.host.com
Content-Type: application/xml
Accept: application/xml
Client-Transaction-Id: 123456
Callback:/deployservicecallback
Callback-ESC-Events:/escevents
<datamodel>
<version>1.0</version>
<service_definition>
. . .
</service_definition>
</datamodel>
After a status change in the deployment, Cisco ESC posts data back to NFVO on the specified URL with a
notification:
HTTP/1.1 200 OK
Content-Type: application/xml; charset=UTF-8
Content-Length: 1488
ESC-Status-Message: VM successfully created
Date: Sun, 1 Jan 2011 9:00:00 GMT
2-38 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
ESC-Transaction-Id: 123456
<?xml version="1.0" encoding="UTF-8"?>
<deployment>
<deployment_stage>VM_DEPLOYED</deployment_ stage>
<deployment_details>
<vm_uuid>26ebf6a5-812e-4034-8a50-588c6579f70a</vm_uuid>
<host_uuid>rereea5-812e-4034-8a50-588c6579f70a</host_uuid>
<interfaces>
<interface>
<network_uuid>0e89b2ed-5e79-47b2-9ff1-07018fc417ef</network_uuid>
<ip_address>10.0.3.58</ip_address>
<port_uuid>c806c915-d5af-4269-bb6b-b76b66c720e1</port_uuid>
<subnet_uuid>fd96c915-d5af-4269-bb6b-b76b66c720e1</subnet_uuid>
<mac_address>fa:16:3e:01:ed:13</mac_address>
</interface>
</interfaces>
<management_ip_address>10.0.3.58</management_ip_address>
<vm_name>sample-service-definition__sample-tenant-01__dep-sample-
01__Group_0__sample_vm1__0</vm_name>
</deployment_details>
<external_deployment_id>9866330f-a4e0-4d29-9ce2-
ef90b94a65e8</external_deployment_id>
<external_service_registration_id>2dee7003-8f9d-4a1c-b2eb-
f2de1d3daafb</external_service_registration_id>

<external_tenant_id>4f384dfc667a4776bc3169da27d09db5</external_tenant_id>
<internal_deployment_id>dep-sample-01</internal_deployment_id>
<internal_service_registration_id>reg-
sample</internal_service_registration_id>
<internal_tenant_id>sample-tenant-01</internal_tenant_id>
</deployment>

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-39

Cisco ESC Installation – Prerequisites
 Prerequisites:
 ESC Release Package:
 ESC-version.qcow2
 bootvm.py
 OpenStack parameters:
 Tenant, network
 Flavor (4 vCPU, 8 GB RAM, 30 GB disk)

Before installing Cisco ESC, make sure you complete the prerequisites checklist, available in the
documentation.

The Cisco recommended settings for a virtual machine running Cisco ESC is (for an estimated 1000 VNFs):
 4 vCPUs
 8 GB RAM
 30 GB disk space

Using this recommendation, create a flavor for Cisco ESC in OpenStack, using either the nova flavor-create
command, or the management web interface.
$ nova flavor-create ESC_FLAVOR_NAME ESC_FLAVOR_ID 8192 30 4
Next, import the ESC image into Glance, using the CLI or the web interface.
$ glance image-create --name <image_name> --is-public=<True or False> --
disk-format <disk_format> --container-format <container_format> --file
<file>
To actually create the instance of the ESC VM, use the bootvm.py script.

2-40 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cisco ESC Installation – bootvm.py
 bootvm.py – CLI tool for instantiating ESC (standalone or HA)
 Uses environment variables for OpenStack settings by default
 Network setup
 High Availability setup
 Logging, security, ESC functionalities enable/disable

cisco@openstack$ ./bootvm.py --version

ESC-2_1_4_39

cisco@openstack$ ./bootvm.py esc-instance --image ESC-2_1_4_39 --net mgmt --ipaddr 10.1.0.10

--gateway_ip 10.1.0.1 –flavor m1.medium --esc_ui_startup=True
…

The bootvm.py CLI tool eases deployment of Cisco ESC into an OpenStack environment.
Cisco ESC supports two modes of deployment: standalone or with high availability. High availability is
implemented in the form of a primary and standby model. Two ESC instances are deployed in the network to
prevent ESC failure and provide uninterrupted ESC service. In case the primary ESC instance fails, the
standby instance automatically takes over the ESC services.
By, default, OpenStack settings (authentication parameters, tenant) are read from the environment variables,
but you have the option of overriding them via command parameters. The full list of bootvm.py parameters is
displayed below.
cisco@openstack:~/esc$ ./bootvm-2_1_4_39.py --help
usage: bootvm-2_1_4_39.py [-h] [--dryrun] [--version] [--poll] [--secure]
[--bs_os_auth_url BS_OS_AUTH_URL]
[--bs_os_tenant_name BS_OS_TENANT_NAME]
[--bs_os_username BS_OS_USERNAME]
[--bs_os_password BS_OS_PASSWORD]
[--os_auth_url OS_AUTH_URL]
[--os_tenant_name OS_TENANT_NAME]
[--os_username OS_USERNAME]
[--os_password OS_PASSWORD] [--ha HA]
[--cluster [CLUSTER]] [--vip VIP]
[--kad_vip KAD_VIP] [--kad_vif KAD_VIF]
[--kad_vri KAD_VRI]
[--kad_notification_email_from
KAD_NOTIFICATION_EMAIL_FROM]
[--kad_smtp_server KAD_SMTP_SERVER]

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-41

[--kad_notification_email
KAD_NOTIFICATION_EMAIL]
[--bgp_local_ip BGP_LOCAL_IP]
[--bgp_anycast_ip BGP_ANYCAST_IP]
[--bgp_remote_ip BGP_REMOTE_IP]
[--bgp_local_as BGP_LOCAL_AS]
[--bgp_remote_as BGP_REMOTE_AS]
[--bgp_local_router_id BGP_LOCAL_ROUTER_ID]
[--bgp_md5 BGP_MD5] [--net [NET [NET ...]]]
[--ipaddr [IPADDR [IPADDR ...]]]
[--peer_ipaddr [PEER_IPADDR [PEER_IPADDR ...]]]
[--ha_node_list [HA_NODE_LIST [HA_NODE_LIST
...]]]
[--gateway_ip [GATEWAY_IP]] [--defroute
DEFROUTE]
[--domain DOMAIN] [--search SEARCH]
[--nameserver [NAMESERVER [NAMESERVER ...]]]
[--ntp_server [NTP_SERVER [NTP_SERVER ...]]]
[--rsyslog_server RSYSLOG_SERVER]
[--rsyslog_server_port RSYSLOG_SERVER_PORT]
[--rsyslog_server_protocol
RSYSLOG_SERVER_PROTOCOL]
--image IMAGE [--group GROUP]
[--avail_zone AVAIL_ZONE] [--flavor FLAVOR]
[--db_volume_id DB_VOLUME_ID]
[--security_rules_file SECURITY_RULES_FILE]
[--db_volume_id DB_VOLUME_ID]
[--security_rules_file SECURITY_RULES_FILE]
[--esc_params_file ESC_PARAMS_FILE]
[--host_mapping_file HOST_MAPPING_FILE]
[--etc_hosts_file ETC_HOSTS_FILE]
[--user_pass [USER_PASS [USER_PASS ...]]]
[--user_confd_pass [USER_CONFD_PASS
[USER_CONFD_PASS ...]]]
[--esc_ui_startup ESC_UI_STARTUP] [--log LOG]
[--esc_monitor_check_ips [ESC_MONITOR_CHECK_IPS
[ESC_MONITOR_CHECK_IPS ...]]]
[--enable-http-rest] [--enable-https-rest]
esc_hostname
Boot Cisco ESC VM into an OpenStack.

2-42 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Positional arguments:
Argument Specification

esc_hostname Host name for the new ESC VM.

Optional arguments:
Argument Specification

-h, --help Show this help message and exit.

--dryrun Display only, do not execute.

--version Print the bootvm.py version and exit.

--poll Blocks while instance builds so progress can be reported.

--secure Enable secure configuration for ESC VM.

--rsyslog_server RSYSLOG_SERVER Specify the server of rsyslogd.

--rsyslog_server_port Specify the server port of rsyslogd.

RSYSLOG_SERVER_PORT
--rsyslog_server_protocol Specify the server protocol of rsyslogd (TCP/UDP).
RSYSLOG_SERVER_PROTOCOL
--image IMAGE Boot the ESC VM with this image ID or name.

--group GROUP Specify OpenStack affinity or anti-affinity group.

--avail_zone AVAIL_ZONE The availability zone for ESC VM placement.

--flavor FLAVOR Name or ID of flavor.

--db_volume_id DB_VOLUME_ID The database volume attached to ESC VM.

--security_rules_file Openstack Security Group rules in JSON format

SECURITY_RULES_FILE
--esc_params_file ESC_PARAMS_FILE ESC Openstack parameters (credentials)

--host_mapping_file HOST_MAPPING_FILE Host mapping file in JSON format

--etc_hosts_file ETC_HOSTS_FILE Entries to add to /etc/hosts

--user_pass [USER_PASS [USER_PASS ...]] Add a user for access to esc vm. Format
user_name:password[:key] This option can be repeated.
Without this argument, default user is added.
admin:cisco123—With this argument, default user is not
added.

--user_confd_pass [USER_CONFD_PASS Add or modify a confd users.

[USER_CONFD_PASS ...]] Chapter 1 Format user_name:password. This option can
be repeated. Without this argument, default user_confd
is added.
Chapter 2 admin:admin—With this argument, default
user_confd is not added.

--esc_ui_startup ESC_UI_STARTUP Startup ESC UI.

--log LOG Specifies the log file. By default, log to stdout.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-43

--esc_monitor_check_ips esc_monitor_check_ips
[ESC_MONITOR_CHECK_IPS
[ESC_MONITOR_CHECK_IPS ...]]
--enable-http-rest INSECURE! - NOT Enable external REST interface over HTTP on port 8080.
FOR PRODUCTION!
--enable-https-rest Enable external REST interface over HTTPS on port 8443.

Arguments of OpenStack where to bootstrap Cisco ESC VM:

Argument Specification

--bs_os_auth_url BS_OS_AUTH_URL Defaults to env[OS_AUTH_URL].

--bs_os_tenant_name BS_OS_TENANT_NAME Defaults to env[OS_TENANT_NAME].

--bs_os_username BS_OS_USERNAME Defaults to env[OS_USERNAME].

--bs_os_password BS_OS_PASSWORD Defaults to env[OS_PASSWORD].

Arguments of OpenStack that Cisco ESC Manager works with:

Argument Specification

--os_auth_url OS_AUTH_URL Defaults to env[OS_AUTH_URL].

--os_tenant_name OS_TENANT_NAME Defaults to env[OS_TENANT_NAME].

--os_username OS_USERNAME Defaults to env[OS_USERNAME].

--os_password OS_PASSWORD Defaults to env[OS_PASSWORD].

High-availability arguments:
Argument Specification

--ha HA Define the HA mode.

Chapter 3 0: No HA,
Chapter 4 1: Shared Cinder Volume,
Chapter 5 2: Built-in DRBD,
Chapter 6 3: DRBD over Cinder Volume.

--kad_vip KAD_VIP Virtual ip address of vrrp instance.

--kad_vif KAD_VIF Interface of vrrp instance.

--kad_vri KAD_VRI virtual router id of vrrp instance. Use the last byte of vip if it
is not specified.

--kad_notification_email_from Notification_email_from
KAD_NOTIFICATION_EMAIL_FROM
--kad_smtp_server KAD_SMTP_SERVER smtp_server

--kad_notification_email notification_email
KAD_NOTIFICATION_EMAIL

2-44 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
--bgp_local_ip BGP_LOCAL_IP bgp_local_ip

--bgp_anycast_ip BGP_ANYCAST_IP bgp_anycast_ip

--bgp_remote_ip BGP_REMOTE_IP bgp_remote_ip

--bgp_local_as BGP_LOCAL_AS bgp_local_as

--bgp_remote_as BGP_REMOTE_AS bgp_remote_as

--bgp_local_router_id bgp_local_router_id
BGP_LOCAL_ROUTER_ID
--bgp_md5 BGP_MD5 bgp_md5

Cluster arguments:
Argument Specification

--cluster [CLUSTER] Enable cluster.

--vip VIP virtual ipaddress of esc cluster

Network arguments:
Argument Specification

--net [NET [NET ...]] On the ESC VM, create a NIC attached to network with
this ID or name.
--ipaddr [IPADDR [IPADDR ...]] Boot the ESC VM with this static ip.

--peer_ipaddr [PEER_IPADDR [PEER_IPADDR Specify the ip address of the peer node while deploying
...]] HA if want to deploy two nodes at one time.

--ha_node_list [HA_NODE_LIST Specify the ip addresses of nodes while deploying HA.

[HA_NODE_LIST ...]]
--gateway_ip [GATEWAY_IP] Define the gateway ip.

--defroute DEFROUTE Specify which interface is the default route.

--domain DOMAIN Domain

--search SEARCH Search

--nameserver [NAMESERVER [NAMESERVER Nameservers

...]]
--ntp_server [NTP_SERVER [NTP_SERVER Ntp server
...]]

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-45

Cisco ESC Installation – Post-Installation
 Change ESC admin credentials.
cisco@openstack$ ssh admin@esc-instance
admin@esc-instance$ /opt/confd-5.2.1/bin/confd_cli -u admin
admin@esc> configure
admin@esc% set aaa authentication users user admin password <newpassword>
admin@esc% commit

 Verify management interface.

 Integrate with Cisco NSO
 Log in via the web interface: http://esc:9000

After the bootvm.py script successfully created the Cisco ESC instance, it is recommended to change the
administrator credentials.
The defaults are admin:cisco123
To change them, SSH into the newly created VM, and use the confd_cli tool to connect to the Cisco ESC
ConfD daemon. From there, change the password for the admin username, and commit the changes.
The final step in the installation process is verification—log in to Cisco ESC via any of its management
interfaces.

2-46 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Integration with Cisco NSO
1. ESC NED for NSO available, reload packages.
2. Add ESC device into NSO CDB, NETCONF device type.
3. Subscribe to notifications.
4. Develop service and subscriber application.

See sample Virtual MPLS VPN service in:

examples.ncs/service-provider/virtual-mpls-vpn

Since the Cisco Elastic Services Controller (Cisco ESC) exposes a NETCONF interface in the northbound
direction, integration with Cisco Network Services Orchestrator (Cisco NSO) is very straightforward.
The first step is to obtain the Network Element Driver (NED) for Cisco ESC. The NED contains all the
YANG models exposed and used by Cisco ESC. After the NED package is successfully loaded in Cisco
NSO, add a new device for Cisco ESC using the NETCONF device type. Optionally, also subscribe the
notifications. A sample minimal configuration for Cisco ESC is show below:
admin@ncs# show running-config devices device esc0
devices device esc0
address 10.1.0.11
port 830
authgroup esc
device-type netconf
state admin-state unlocked
netconf-notifications subscription vm-status
stream escEvent
local-user admin
reconnect-interval 5
The next step is to develop the services to enable virtual machine management through Cisco NSO and also
subscribers to enable reacting to events on the virtual infrastructure.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-47

Cisco NSO Integration: Load NED
 Build the Cisco ESC NED for ESC version.
cisco@nso$ mkdir esc-yang
cisco@nso$ scp admin@esc:/opt/cisco/esc/esc-confd/YANGmodels-tailf/*.yang esc-yang
cisco@nso$ ncs-make-package --netconf-ned esc-yang esc
cisco@nso$ make –C esc/src
…

 Load the package in Cisco NSO.

admin@ncs# packages reload
reload-result {
package esc
result true
}

The first step required to integrate Cisco ESC with Cisco NSO is to obtain the Network Element Driver
(NED). If a NED is not available for the version of Cisco ESC you are using, you can build the NED
yourself.

Start by copying the ESC YANG models to the NSO server:

cisco@nso$ scp admin@esc:/opt/cisco/esc/esc-confd/YANGmodels-tailf/*.yang
esc-yang
Next, create the NED package using the ncs-make-package command:
cisco@nso$ ncs-make-package --netconf-ned esc-yang esc
Finally, compile the package and reload packages in NSO
cisco@nso$ make –C esc/src
cisco@nso$ ncs_cli –u admin <<EOF
request packages reload
EOF

2-48 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cisco NSO Integration: Create Device
 Create the authgroup and device.
admin@ncs(config)# devices authgroups group esc default-map remote-name admin remote-password
admin
admin@ncs(config)# devices device esc0 address 10.1.0.10 port 830 state admin-state unlocked
admin@ncs(config-device-esc0)# device-type netconf
admin@ncs(config-device-esc0)# authgroup esc
admin@ncs(config-device-esc0)# commit
Commit complete.

 Sync from the device.

admin@ncs# devices device esc0 sync-from
result true

The next step is to create the device in Cisco NSO Device Manager. First, you need an authgroup for storing
the NETCONF credentials. Create an authgroup named esc:
admin@ncs(config)# devices authgroups group esc default-map remote-name
admin remote-password admin
The newly created device will have the following parameters:
 address: 10.1.0.10 (ESC management IP)
 port: 830
 device-type: netconf
 authgroup: esc
 state admin-state: unlocked

After creating the device with these parameters, you should be able to execute a sync-from command on the
device.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-49

Cisco NSO Integration: Create Tenant
 Create a Cisco ESC and OpenStack tenant.
admin@ncs(config)# devices device esc0 config esc:esc_datamodel tenants tenant new-tenant
admin@ncs(config-tenant-new-tenant)# commit
Commit complete.

 Verify the tenant in OpenStack.

When Cisco ESC is properly installed and integrated with Cisco NSO, you can test the installation by
creating a tenant. Use Cisco NSO CLI to create a tenant for the esc0 device configuration:
admin@ncs(config)# devices device esc0 config esc:esc_datamodel tenants
tenant new-tenant
Verify that the tenant is created in Cisco ESC Web UI and Openstack, using the CLI or the Web UI.
Another verifications step is to check the received NETCONF notification. This requires that Cisco NSO is
previously subscribed to receive NETCONF notifications from Cisco ESC:
admin@ncs(config)# devices device esc0 netconf-notifications subscription
vm-status stream escEvent local-user admin
admin@ncs(config)# commit

admin@ncs# show devices device esc0 netconf-notifications received-

notifications
netconf-notifications received-notifications notification 2016-01-
30T18:43:13.663+00:00 0
user admin
subscription vm-status
stream escEvent
received-time 2016-02-02T13:47:15.906407+00:00
data escEvent status SUCCESS
data escEvent status_code 200
data escEvent status_message "Tenant successfully created"
data escEvent tenant new-tenant
data escEvent event type CREATE_TENANT

2-50 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cisco NSO Integration: Deploy VNF in OpenStack
<devices xmlns="http://tail-f.com/ns/ncs">
<device tags="nocreate">
<name>esc0</name>
<config>
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<tenants tags="merge">
<tenant>
<name>new-tenant</name>
<deployments>
<deployment>
<name>test-deployment</name>
<vm_group>
<name>group1</name>
<flavor>csr</flavor>
<image>csr-image</image>
…
<config_data>
<configuration>
<dst>iosxe_config.txt</dst>
<file>http://1.2.3.4/csr_config.txt</file>
</configuration>
</config_data>
…
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 42

We can create a new deployment in the new OpenStack tenant. Displayed on the slide is the Cisco NSO
configuration in the XML format, which is required to create a new deployment.
The configuration creates a new deployment, named test-deployment. The deployment contains one group,
named group1, with a single csr VNF. Cisco ESC gets the day0 configuration from the URL, and replaces
the variables with generated values.
The full XML configuration is listed below:
<config-template xmlns="http://tail-f.com/ns/config/1.0">
<devices xmlns="http://tail-f.com/ns/ncs">
<device tags="nocreate">
<name>esc0</name>
<config>
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<tenants tags="merge">
<tenant>
<name>new-tenant</name>
<deployments>
<deployment>
<name>test-deployment</name>
<vm_group>
<name>group1</name>
<flavor>csr</flavor>
<image>csr-image</image>
<bootup_time>600</bootup_time>
<recovery_wait_time>0</recovery_wait_time>

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-51

<kpi_data>
<kpi>
<event_name>VM_ALIVE</event_name>
<metric_value>60</metric_value>
<metric_cond>GT</metric_cond>
<metric_type>UINT32</metric_type>
<metric_collector>
<type>ICMPPing</type>
<nicid>0</nicid>
<poll_frequency>3</poll_frequency>
<polling_unit>seconds</polling_unit>
<continuous_alarm>false</continuous_alarm>
</metric_collector>
</kpi>
</kpi_data>
<rules>
<admin_rules>
<rule>
<event_name>VM_ALIVE</event_name>
<action>'ALWAYS log'</action>
<action>'TRUE servicebooted.sh'</action>
</rule>
</admin_rules>
</rules>
<config_data>
<configuration>
<dst>iosxe_config.txt</dst>
<file>http://12.3.4/csr_config.txt</file>
</configuration>
</config_data>
<scaling>
<min_active>1</min_active>
<max_active>1</max_active>
<elastic>true</elastic>
</scaling>
</vm_group>
</deployment>
</deployments>
</tenant>
</tenants>

2-52 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
</esc_datamodel>
</config>
<netconf-notifications tags="merge">
<subscription>
<name>vm-status</name>
<stream>escEvent</stream>
<local-user>admin</local-user>
</subscription>
</netconf-notifications>
</device>
</devices>
</config-template>

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-53

Cisco NSO Integration: Deploy VNF in OpenStack
Verification
 Check NETCONF notifications.
1. CREATE_TENANT
2. VM_DEPLOYED
3. VM_ALIVE
4. SERVICE_ALIVE
 Implement the subscriber application to react to notifications.
 Subscribe to /ncs:devices/ncs:device{esc0}/ncs:netconf-notifications/ncs:received-
notifications

After requesting a VNF deployment through Cisco NSO, the request is relayed to Cisco ESC via NETCONF.
The commit command in Cisco NSO completes before the VNF is provisioned and available, because the
deployment configuration only represents the service intent. Cisco ESC will then send NETCONF
notification back to Cisco NSO, notifying it of the stages of VNF provisioning.

In a normal process, Cisco ESC will send four notifications:

 CREATE_TENANT—after the tenant was successfully created in Openstack.
 VM_DEPLOYED—after the VNF was successfully deployed in Openstack. Note that this is a success
from the perspective of the hypervisor, not the service. The VM for the VNF was created, but the service
may not be running yet.
 VM_ALIVE—after the VNF is reachable through its management interface.
 SERVICE_ALIVE—after all VNFs in the group are deployed, and the service is available.

Each of the notifications may contain additional data. Below is a printout of all four notification types for a
test VNF deployment:
<config xmlns="http://tail-f.com/ns/config/1.0">
<devices xmlns="http://tail-f.com/ns/ncs">
<device>
<name>esc0</name>
<netconf-notifications>
<subscription refcounter="2" backpointer="[ /vmm:vm-
manager/escm:esc[escm:name='admin_vFirewall-test_CSR'] ]" >
<name>vm-status</name>
<stream refcounter="2" original-
value="escEvent">escEvent</stream>

2-54 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
<local-user refcounter="2" original-
value="admin">admin</local-user>
<status>running</status>
</subscription>
<stream>
<name>NETCONF</name>
<description>default NETCONF event stream</description>
<replay-support>false</replay-support>
</stream>
<stream>
<name>escEvent</name>
<description>ESC notifications</description>
<replay-support>true</replay-support>
<replay-log-creation-time>2016-01-30T17:19:13+00:00</replay-
log-creation-time>
<replay-log-aged-time>2016-01-30T19:12:12.274+00:00</replay-
log-aged-time>
</stream>
<stream>
<name>lwmonEvent</name>
<description>Lwmon notifications</description>
<replay-support>true</replay-support>
<replay-log-creation-time>2016-01-30T17:19:13+00:00</replay-
log-creation-time>
</stream>
<notification-name>
<name>escEvent</name>
<uri>http://www.cisco.com/esc/esc</uri>
</notification-name>
<received-notifications>
<notification>
<event-time>2016-01-30T18:43:13.663+00:00</event-time>
<sequence-no>1</sequence-no>
<user>admin</user>
<subscription>vm-status</subscription>
<stream>escEvent</stream>
<received-time>2016-02-02T13:48:56.010841+00:00</received-
time>
<data>
<escEvent xmlns="http://www.cisco.com/esc/esc">
<status>SUCCESS</status>

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-55

<status_code>200</status_code>
<status_message>Tenant successfully
created</status_message>
<tenant>new-tenant</tenant>
<event>
<type>CREATE_TENANT</type>
</event>
</escEvent>
</data>
</notification>
<notification>
<event-time>2016-02-01T21:40:45.428+00:00</event-time>
<sequence-no>0</sequence-no>
<user>admin</user>
<subscription>vm-status</subscription>
<stream>escEvent</stream>
<received-time>2016-02-02T13:48:55.965615+00:00</received-
time>
<data>
<escEvent xmlns="http://www.cisco.com/esc/esc">
<status>SUCCESS</status>
<status_code>200</status_code>
<status_message>VIM Driver: VM successfully created, VM
Name: [SystemAdminTena_CSR_0_453a6a50-37d1-49d9-932d-
5bb43d42a20e]</status_message>
<depname>vFirewall-test</depname>
<tenant>admin</tenant>
<depid>a4822e9b-19b4-4bc6-be5f-6b03945fa269</depid>
<vm_group>CSR</vm_group>
<vm_source>
<vmid>a3aae31c-def8-4354-bcaf-474c7930a196</vmid>

2-56 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
<subnet>ee82ff6b-44e1-4058-af7c-
b6d614dbbb17</subnet>
<ip_address>10.1.0.31</ip_address>
<mac_address>fa:16:3e:00:a9:e7</mac_address>
<netmask>255.255.255.0</netmask>
<gateway>10.1.0.1</gateway>
</interface>
<interface>
<nicid>1</nicid>
<port_id>fef2a3ab-3061-4e86-b41f-
d80fff24687a</port_id>
<network>231b4d14-e43b-4678-81ea-
a220fdad4a53</network>
<subnet>f50ab459-cbf7-4834-9251-
63355ad01313</subnet>
<ip_address>20.0.0.13</ip_address>
<mac_address>fa:16:3e:d9:55:6f</mac_address>
<netmask>255.255.255.0</netmask>
<gateway>20.0.0.1</gateway>
</interface>
<interface>
<nicid>2</nicid>
<port_id>c32ef9c3-65d6-4e74-b243-
99fc24967ee8</port_id>
<network>77c37411-8a8a-4841-ad96-
fa91cef2b48f</network>
<subnet>c582f0e8-aeaa-49e2-af12-
979f81a4d5b2</subnet>
<ip_address>30.0.0.15</ip_address>
<mac_address>fa:16:3e:30:2e:24</mac_address>
<netmask>255.255.255.0</netmask>
<gateway>30.0.0.1</gateway>
</interface>
</interfaces>
</vm_source>
<event>
<type>VM_DEPLOYED</type>
</event>
</escEvent>
</data>
</notification>
<notification>

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-57

<event-time>2016-02-01T21:44:22.709+00:00</event-time>
<sequence-no>0</sequence-no>
<user>admin</user>
<subscription>vm-status</subscription>
<stream>escEvent</stream>
<received-time>2016-02-02T13:48:55.981231+00:00</received-
time>
<data>
<escEvent xmlns="http://www.cisco.com/esc/esc">
<status>SUCCESS</status>
<status_code>200</status_code>
<status_message>VM_Alive event received, VM ID:
[SystemAdminTena_CSR_0_453a6a50-37d1-49d9-932d-
5bb43d42a20e]</status_message>
<depname>vFirewall-test</depname>
<tenant>admin</tenant>
<depid>a4822e9b-19b4-4bc6-be5f-6b03945fa269</depid>
<vm_group>CSR</vm_group>
<vm_source>
<vmid>a3aae31c-def8-4354-bcaf-474c7930a196</vmid>

<hostid>bf70c8520b044d043dd5780d25eecb8c62267bf13ff7cb9129389fb1</hostid>
<hostname>nso-stack</hostname>
<interfaces>
<interface>
<nicid>0</nicid>
<port_id>a5a202cf-6258-4fec-a124-
873b99278321</port_id>
<network>482bc899-4a83-4d07-bceb-
ce51e111d0d6</network>
<subnet>ee82ff6b-44e1-4058-af7c-
b6d614dbbb17</subnet>
<ip_address>10.1.0.31</ip_address>
<mac_address>fa:16:3e:00:a9:e7</mac_address>
<netmask>255.255.255.0</netmask>
<gateway>10.1.0.1</gateway>
</interface>
<interface>
<nicid>1</nicid>
<port_id>fef2a3ab-3061-4e86-b41f-
d80fff24687a</port_id>

2-58 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
<network>231b4d14-e43b-4678-81ea-
a220fdad4a53</network>
<subnet>f50ab459-cbf7-4834-9251-
63355ad01313</subnet>
<ip_address>20.0.0.13</ip_address>
<mac_address>fa:16:3e:d9:55:6f</mac_address>
<netmask>255.255.255.0</netmask>
<gateway>20.0.0.1</gateway>
</interface>
<interface>
<nicid>2</nicid>
<port_id>c32ef9c3-65d6-4e74-b243-
99fc24967ee8</port_id>
<network>77c37411-8a8a-4841-ad96-
fa91cef2b48f</network>
<subnet>c582f0e8-aeaa-49e2-af12-
979f81a4d5b2</subnet>
<ip_address>30.0.0.15</ip_address>
<mac_address>fa:16:3e:30:2e:24</mac_address>
<netmask>255.255.255.0</netmask>
<gateway>30.0.0.1</gateway>
</interface>
</interfaces>
</vm_source>
<event>
<type>VM_ALIVE</type>
</event>
</escEvent>
</data>
</notification>
<notification>
<event-time>2016-02-01T21:44:23.133+00:00</event-time>
<sequence-no>0</sequence-no>
<user>admin</user>
<subscription>vm-status</subscription>
<stream>escEvent</stream>
<received-time>2016-02-02T13:48:55.987396+00:00</received-
time>
<data>
<escEvent xmlns="http://www.cisco.com/esc/esc">
<status>SUCCESS</status>
<status_code>200</status_code>
© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-59
<status_message>Service group deployment completed
successfully!</status_message>
<depname>vFirewall-test</depname>
<tenant>admin</tenant>
<depid>a4822e9b-19b4-4bc6-be5f-6b03945fa269</depid>
<event>
<type>SERVICE_ALIVE</type>
</event>
</escEvent>
</data>
</notification>
</received-notifications>
</netconf-notifications>
</device>
</devices>
</config>

2-60 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cisco NSO Integration: Deploy VNF in OpenStack
Verification (Cont.)
admin@ncs# show devices device esc0 netconf-notifications received-notifications
netconf-notifications received-notifications
notification 2016-02-01T21:44:23.133+00:00 0
user admin
subscription vm-status
stream escEvent
received-time 2016-02-02T13:48:55.987396+00:00
data escEvent status SUCCESS
data escEvent status_code 200
data escEvent status_message "Service group deployment completed successfully!”
data escEvent depname vFirewall-test
data escEvent tenant admin
data escEvent depid a4822e9b-19b4-4bc6-be5f-6b03945fa269
data escEvent event type SERVICE_ALIVE

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-61

Cisco NSO Integration: Deploy VNF in OpenStack
Verification (Cont.)

2-62 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cisco NSO and Cloud VPN Architecture
Order
Order
management BSS/OSS Other
Other systems Northbound integration:
management systems
 Custom portals
Model-driven service consumer portal for self-service service lifecycle :
create, modify, redeploy, delete

Self-Service

YANG java YANG

Portal Service
Models
Reactive
NSO YANG
FASTMAP
FASTMAP
Network Service Lifecycle Device
Models

Southbound integration:
 Devices directly
DC
Services
Orchestration &  Virtual devices:
vNF1 vNF2 vNF3 Cloud Automation  Provisioned through
CPE
Infrastructure OpenStack
DC
WAN network Cloud Manager  Managed directly
and Internet Infrastructure

Public
Network
Internet
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 44

Cisco NSO lies at the heart Cloud VPN. It serves as a multidomain orchestration layer, taking over both
network and compute orchestration. It provides a single view of the cloud and network infrastructure to
higher layer applications, and takes care of end-to-end service provisioning.

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-63

Summary
This topic summarizes the key points that were discussed in this lesson.
 Cloud VPN provides a complex service consisting of a number of managed resources.
 Cisco NSO is used as a multidomain orchestration layer to manage the configuration of physical and
virtual resources.
 Cloud VPN uses a layered approach, which makes services independent of physical devices and
topologies.
 Cloud VPN is completely model-driven.
 ETSI Management and Orchestration (MANO) is a framework defining the solution layers and
components:
— NFV Orchestrator
— VNF Manager
— Virtualized Infrastructure Manager
 Cisco ESC is an implementation of a VNF Manager.
 Cisco ESC manages OpenStack and VMware infrastructure, exposing a model‑driven API to northbound
consumers.

2-64 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Lesson 2-2

Simple Cloud VPN Service

Design
Overview
This lesson explains the concept of stacked services, using examples of vRouter, vFirewall and vQos service

Objectives
Upon completing this lesson, you will be able to explain the concept of stacked services. This ability includes
being able to meet these objectives:
 Use stacked service models
 Design a vRouter service
 Design a vFirewall service
 Design a vQoS service

© 2016 Cisco Systems, Inc. Cloud VPN Service Design 2-65

Stacked Services

Stacked Services
 Cloud VPN consists of a bundle of interdependent services:
 Service bundles
and/or
 Self-service by selecting individual components

 Each service instance consists of two main components:

 Aggregation of customer connections
 Virtual network functions in the data center

Any larger and more complex service or a set of services should be split into manageable chunks of service
models in order to accommodate a more manageable environment. Cloud VPN can be seen as a set of
individual network functions that can each be modeled separately. Customer services can then be created by
combining an arbitrary set of these second-layer services.

Cloud VPN can in general be split into two major components:

 Aggregation of customer connections over the service provider network or even the Internet. There are a
number of technologies that can be used to accomplish this, such as IP Security (IPsec), Generic Routing
Encapsulation (GRE), GRE over IPsec, Layer 2 Tunneling Protocol version 2 (L2TPv2), L2TPv2 over
IPsec, L2TPv3, L2TPv3 over IPsec, etc.
 Inside the service provider data center we can provide the customers with a number of network services
that are based on the usage of network function virtualization (NFV) technologies such as virtual router,
virtual network firewall, virtual web firewall, virtual intrusion prevention system, etc. In addition to this,
we can combine this services with other services such as Internet access, hosted virtual servers,
SaaS-based services, etc.

2-66 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Sample Cloud VPN Network Topology

SP Data Center

L3 (IPsec) or L2 (Keyed IPv6)

SP Network vR vFW Internet

VM VM
CPE Internet
Gateway

vNG-IPS vWSA
VM VM

 Service model modularity is recommended for easing maintenance and

providing the ability to combine different NFVs into customer service instances.

The figure illustrates a sample Cloud VPN environment with two types of connections along with four types
of network function virtualization (NFV).

Sample customer connection types:

 Layer 3 connectivity using IPsec
 Layer 2 connectivity using Keyed IPv6

Network functions provided using virtual appliances:

 Virtual router (vRouter or vR): Used to aggregate customer connections
 Virtual network firewall (vFirewall or vFW): Used to secure access to the Internet and optionally
provide remote access to users over the Internet using IPsec or SSL remote access VPNs.
 Virtual next-generation intrusion prevention system (vNG-IPS): Used to provide advanced security
to all traffic passing through the virtual demilitarized zone (DMZ).
 Virtual web security appliance: Used to provide advanced security mechanisms to protect web
sessions.

Cloud VPN Managed Components

Customer
Customer
Customer  One or more customer services.
Service
Service
Service  Each service contains one or more resources.

Resource
Resource
Resource
Service  One or more resource services (e.g. vR, vFW, vIPS).
Service
Service

Resource  One or more resource pools (e.g. IP addresses, subnets,

Resource
Resource VLANs).
Pools
Pools
Pools  Can perform local allocation or use an external repository.

The figure illustrates a possible hierarchical approach to designing Cloud VPN services where we can have
two or three levels in the hierarchy:
 The top-level service model is what the operator uses to fill in service instance parameters in order to
provision the required service to an end customer.
 The second level consists of a number of NFV service models for all the required services.
 An optional third level can be used to implement resource allocating services that can be used to further
automate the allocation of some service parameters, or to integrate the system with an existing external
resource inventory. The most common parameters that can be automatically generated or retrieved from
an external inventory are VLANs to provide internal and external connectivity to physical network
devices, IP address for virtual devices (management ports, data ports), IP networks, service instance
identifiers, etc.

Service Model A: Service Model B:

vR + vFW vR + vFW + vIPS

Service Model Service Model Service Model Service Model

CPE vR vFW vNG-IPS

Two-stage process (reactive FASTMAP):

Configures CPE after
 Instantiate VM
Day-0 provisioning
 Configure VM

 Top-level service model defines customer service bundles.

The figure illustrates our sample Cloud VPN service set where we have several different service instances
with different selections of second-level services (NFVs). Each of the individual services can have its own
implementation of resource allocations depending on the specifics of the service:
 vRouter, vFirewall, and vNG-IPS are all based on virtual machines that require a two-stage process. We
first need to instantiate a virtual machine and provide it with the minimum configuration (e.g.
management address and connectivity) and then configure the device through the management
connection.
 CPE can be configured once it has been deployed at a customer site and has acquired the minimum
configuration (i.e. day-0 configuration), which allows Cisco Network Services Orchestrator (Cisco NSO)
to access it and perform the full configuration.
In all of the above cases, we need to make use of the Reactive FASTMAP in order to implement the required
two-stage process.

– Designing a vRouter Service

vRouter Service Configuration Requirements

Internal 3
 Connectivity:
 Layer 3 connectivity such as:
 IPsec-based Layer 3 connectivity (in any flavor)
Internal 1 Internal 2
 GRE (+ IPsec)
vR
 IP routing (in case VPNs are provided by MPLS in the network) VM
 Layer 2 connectivity such as:
 L2TPv3 (+ IPsec)
 Keyed IPv6 Management
 Routing: IPv4 and/or IPv6 static or dynamic routing
 Interface addressing: IPv4 and/or IPv6 (service and management)
 Provider and customer access credential configuration (static and/or
AAA)
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 9

This topic discusses the design considerations for implementing a virtual router (vRouter) service to provide
customer aggregation services and optionally other services (e.g. IOS firewall, quality of services [QoS]).
The vRouter service is based on Cisco Cloud Service Router (Cisco CSR) 1000V, which uses Cisco IOS XE
inside a virtual machine.

As noted earlier, we can implement any of a number of technologies to aggregate customer connections
inside the isolated environment in the date center:
 IPsec can be used to provide secure connectivity across any type of network (service provider core or the
Internet).
 IPsec can be combined with Generic Routing Encapsulation (GRE) to provide Layer 3 routing and
optionally multi-protocol support.
 Layer 2 Tunneling Protocol version 2 (L2TPv2), L2TPv3 or Keyed IPv6 to provide Layer 2 connectivity
across a Layer 3 network.

The virtual router requires a number of parameters to be configured in order to become functional. Some of
them are:
 Management IP addresses on a separate and isolated management network.
 Routing configuration to ensure end-to-end connectivity (e.g. static default routes in simple
environments or dynamic routing in more complex environments such as OSPF or BGP).
 Authentication, authorization and accounting (AAA) configuration to secure administrative access to the
virtual device.

2-70 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Sample vRouter Service Definition
SP Data Center
10.123.5.0/24 0.0.0.0/0
IPsec

SP Network vR FW Internet
VM VM
CPE Internet
Gateway

192.168.50.0/24
 Connectivity requirements:
 Connect to the management network
 Connect to the SP core router
 Connect to the next NFV (e.g. vFW)

The figure illustrates main service requirements for the vRouter service:
 Aggregating IPsec sessions from CPEs.
 Routing traffic between the CPEs and the Internet:
— Default route pointing towards the Internet (i.e. the vFirewall appliance if it is also part of the
overall service instance).
— Static route for customer networks pointing towards the physical edge router.
 Providing management access in order for the vRouter to be accessible from Cisco Network Services
Orchestrator (Cisco NSO) and other management systems (e.g. Network Time Protocol [NTP] server,
Syslog server, AAA server).

vRouter Service Provisioning Process

Create VM: CSR1k & connections

1.
OpenStack
3. ( Cisco ESC  Nova  Neutron)
4. VM created.
2.
NSO
Instantiate VM (CSR1k).

Configure VM (CSR1k).
vR
VM

The figure illustrate the minimum set of steps in the provisioning process for the vRouter service:
1. An operator initiates a provisioning process and Cisco NSO first needs to ensure that a virtual machine
with Cisco CSR 1000V software is instantiated and provisioned with the initial minimum configuration
(internal connectivity, management interface, and IP address and access credential). This step requires
Cisco NSO to trigger the instantiation with the external system that manages the virtual environment
(OpenStack in the example).
2. OpenStack is responsible for instantiating a new virtual machine. The solution may consist of different
components such as the Cisco Elastic Services Controller (Cisco ESC) that further communicates with
OpenStack's computing fabric controller (Nova) and network management controller (Neutron).
3. Once the VM is instantiated and the minimum configuration deployed on the new vRouter, Cisco NSO is
informed of the state …
4. … and can issue a re-deploy of the service, which results in the completion of the service configuration
transaction by deploying the full configuration on the new vRouter machine.

Reactive FASTMAP is used to enable this multi-stage transaction to be completed.

2-72 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Mapping Architecture: Java + Templates

Service
Parameters
Device Configuration Templates with Variables
vR Common vR Routing
vR IPsec Config vR Qos Config
Service Model Config
Template
Config
Template
Template Template

Assign parameters to variables.

FASTMAP
CREATE Callback Assign parameters from resource pools
(local or external).
Reactive
FASTMAP
vR
© 2016 Cisco and/or its affiliates. All rights reserved. VM Advanced Cisco Network Services Orchestrator v2.0 12

The actual service model describing the vRouter service can be implemented in several different ways. The
figure illustrates one of the possibilities:
 The service model consists of parameters that are provided by the service operator.
 Device configuration contains a number of commands, some of which must be combined with the
parameters provided by the service mode. There are also many other commands that are part of the
service design and will be the same for every instance. These configuration commands can be provided
through a single configuration template or can be logically split into multiple configuration template files
(i.e. grouped according to their meaning).
 The Java code in the FASTMAP's CREATE callback combines the templates with the service
parameters, generating the device configuration that can be pushed down to the device. Reactive
FASTMAP can be used to provide additional code that automatically generates or allocates some
parameters form a local or an external resource inventory.

Sample vRouter Service Model
Link to customer list Link to device list
L vrouter

K router-id hostname R customer R device

C mgmt intf ip mask gw

L interfaces intf ip mask gw

L tunnels rem-loop-ip rem-net rem-mask key

C sla bw

 Service model defines variables

 The rest of the vR configuration is static and is part of the configuration template

The high-level service model lists some of the parameters that can be used to describe the vRouter service
model:
 Global router parameters
 Management access parameters
 Data interfaces interconnecting NFVs and physical devices
 IPsec tunnels to CPE devices
 QoS and service-level agreement (SLA) parameters

2-74 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Sample vRouter Service Model (Cont.)
list vRouter { …
key router-id; list tunnels {
leaf rem-loop-ip { type inet:ipv4-address; }
leaf router-id { type string; } leaf rem-net { type inet:ipv4-address; }
leaf hostname { type string; } leaf rem-mask { type inet:ipv4-address; }
leaf customer { type leafref { leaf key { type string; }
path }
"/ncs:customers/ncs:customer/ncs:id"; }
} container sla {
leaf device { type leafref { leaf bw {
path type enumeration {
"/ncs:devices/ncs:device/ncs:name"; } enum "10Mbps";
} enum "50Mbps";
enum "100Mbps";
container mgmt { }
leaf intf { type string { pattern }
"\d+/\d+"; } } }
leaf ip { type inet:ipv4-address; }
leaf mask { type inet:ipv4-address; } …
leaf gw { type inet:ipv4-address; }
list interfaces {
key intf;
leaf intf { type string { pattern
"\d+/\d+"; } }
leaf ip { type inet:ipv4-address; }
leaf mask { type inet:ipv4-address; }
leaf gw { type inet:ipv4-address; }
} Cisco and/or its affiliates. All rights reserved.
© 2016 Advanced Cisco Network Services Orchestrator v2.0 14

The sample YANG service model illustrates the service model from the previous page.

Sample vRouter Service Model (Cont.)
list vRouter {
key router-id;  Optimize (simplify) the model.
leaf router-id { type string; }
leaf hostname { type string; }  Use a resource management service
leaf customer { type leafref {
path to automatically allocate some
"/ncs:customers/ncs:customer/ncs:id"; }
} parameters (e.g. IP addresses,
leaf device { type leafref { encryption keys).
path
"/ncs:devices/ncs:device/ncs:name"; }
}
container mgmt {
leaf intf { type string { pattern
"\d+\/\d+"; } }
leaf ip { type ipv4-address; }
leaf mask { type ipv4-address; }
leaf gw { type ipv4-address; }
}
list interfaces {
key intf;
leaf intf { type string { pattern
"\d+\/\d+"; } }
leaf ip { type ipv4-address; }
leaf mask { type ipv4-address; }
leaf gw { type ipv4-address; }
} Cisco and/or its affiliates. All rights reserved.
© 2016 Advanced Cisco Network Services Orchestrator v2.0 15

When using a local or external resource inventory or generation code, we may reduce the number of service
parameters in the vRouter service.

Note The service parameters may be retained in the YANG model but are not accessible to the operator for
entry. Custom Java code can be used to calculate or allocate the service parameters using Reactive
FASTMAP. An example of a resource manager implementation will be described in the next lesson.

2-76 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Using Device Configuration Templates
package com.example.cvpn.vr;
…
import com.tailf.ncs.template.Template;
import com.tailf.ncs.template.TemplateVariables;
…
@ServiceCallback(servicePoint="l3vpn-servicepoint", callType=ServiceCBType.CREATE)
public Properties create(ServiceContext context, NavuNode service, NavuNode ncsRoot,
Properties opaque)
throws ConfException {
…
String customer = service.leaf("customer").valueAsString(); Load the configuration template.
String hostname = service.leaf("device").valueAsString();

Template vrConfig = new Template(context, "vR_config_template"); Assign values to variables

TemplateVariables vrVars= new TemplateVariables(); from the service instance.
vrVars.putQuoted(„ROUTER", service.leaf("device").valueAsString());
vrVars.putQuoted("MGMT_IP", service.container("mgmt").leaf("ip").valueAsString());
…

vrConfig.apply(virto, interfaceVariables); Apply variables to the

… template.

The partial Java code shown in the figure contains the following major components:
 An XML device configuration template is loaded from the templates directory of the package.
 Variables are populated with values. In the example, we only see variables that are retrieved from the
service instance where the operator provided the values. Alternatively, we can use other means of
calculating or allocating some values but we have to implement them by using Reactive FASTMAP.
 Finally, the configuration template is populated with service instance parameters (i.e. variables in the
template are replaced by supplied values).

This approach provides the most scalability and simplicity by allowing all static parts of the configuration to
be simply added or changed in template files (note that there is no need to recompile and reload packages
upon template change).

– Designing a vFirewall Service

Informal Service Design: vFirewall as a Black Box

 A service model is a set of parameters required to describe a service.
 It has nothing to do with the actual service implementation on the device.
 Our firewall service does four things:
 Permits traffic classes originating from the trusted side of the network
 Permits returning traffic
 Blocks traffic classes from the trusted side of the network
 Blocks traffic from the Internet

Trusted Internet
Allowed Traffic Out Allowed Traffic Out

Allowed Traffic In Allowed Traffic In

Blocked Traffic Out Blocked Traffic In

When we are using the top-down approach in a service design, we need to keep in mind that a service is
nothing more than a set of parameters that describe it. In all other aspects, the service is a black box and has
nothing to do with the network topology or device vendor. A firewall basically splits a network into several
parts, each with its own security policy. Note that there is always also the management interface, which
should be separated from both the Trusted side and the Internet and should implement their own security
policies. However, the customer does not see this interface, and it comes pre-provisioned on the device.

2-78 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Informal Service Design: vFirewall as a Black Box
 This set of parameters is required to describe the Firewall service:
 Allowed Traffic classification
 From Trusted to Internet
 From Internet to Trusted

 Blocked Traffic classification

 From Trusted to Internet
 From Internet to Trusted

Trusted Internet
Allowed Traffic Out Allowed Traffic Out

Allowed Traffic In Allowed Traffic In

Blocked Traffic Out Blocked Traffic In

For Cloud VPN purposes, it is enough to split the firewall into two parts: Trusted and Internet. A firewall
service can be summed up by providing information on:
1. Which traffic is all allowed from Trusted to Internet
2. Which traffic is allowed from Internet to Trusted

Informal Service Design: vFirewall
 Two possible implementation scenarios:
 ACL-based firewall
 ACL rules: Traffic matching rules and actions (permit/deny)
 Zone-based firewall
 Security Zones: Define a group of interfaces that have a similar security policy.
 Security Policies: Inspection of traffic and actions (drop/pass/inspect)

 Common service parameters:

 Internal interface/Trusted Zone: Defines where the secure network is
 External interface/Internet Zone: Defines where the unsecure network is
 Device name: The device where the rules need to be implemented

After we define our security policies and identify which traffic is allowed where, we realize that there are
actually two very different ways of implementing a firewall service.
One is by using access control lists (ACLs) and the other is by implementing a zone-based firewall. An ACL-
based firewall uses a list of rules that match traffic by source and destination IP addresses and declares the
action as either permit or deny. Though being very explicit, ACL can quickly become hard to manage. One
of the main downsides of using ACLs is that they have to be applied both on the Trusted as well as the
Internet interface to allow returning traffic to flow. A zone-based firewall works differently. It will
automatically inspect traffic and identify return traffic flows and allow them automatically. Instead of ACLs,
a zone-based firewall defines security zones and policies between them – for example, to allow HTTP from
Trusted to Internet. A zone-based firewall is also stateful, meaning it is able to expect and be aware of
sessions higher than the IP Layer. ACL-based firewall stops after Layer 3.
After discussing with network engineers which one to use, a decision is made that a combination of both
approaches will work best.

2-80 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Informal Service Design: vFirewall – ACL Based

Internet
Interface ACL

IPsec
Internet
SP Network RTR
CPE VM Internet
Trusted
Interface ACL Gateway

 Trusted Interface:  Internet Interface:

 Permit HTTP and SMTP  Permit HTTP and SMTP
 Deny access to vFW and VM interfaces  Deny access to vFW and VM interfaces

The figure shows an example Firewall service instance using an ACL-based firewall.

Informal Service Design: vFirewall – Zone Based

Trusted Internet
IPsec
Internet
SP Network RTR
CPE VM Internet
Gateway

 Trusted Zone  Internet Interface:

 Inspect traffic from Trusted to Internet  Permit returning traffic
 Block the rest

The figure shows an example Firewall service instance using a zone-based firewall.

2-82 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Configuration – ACL
This is a unique identifier describing an instance of a deployed firewall service.
Firewall Name
It is used to provide a descriptive name for the service instance.

Device List This is a list of devices which the firewall services will be applied to.

Customer Reference to the customer within Cisco NSO.

ACL
This is a list of Access Control Lists (ACLs).

This a list of ACL rules that need to be applied

Number Unique rule number
Action Action (permit/deny)
Rule Protocol Predefined list of protocols
Source IP Source IP Address
Source Port Source Port
Destination IP Destination IP Address
Destination Port Destination Port
This is the interface to which we will apply the rules.
Interface
© 2016 Cisco and/or its affiliates. All rights reserved. Direction: we either apply the rules for incoming or outgoing traffic. Advanced Cisco Network Services Orchestrator v2.0 23

The table above lists the parameters required to configure an ACL-based firewall.

Service Configuration – Zone Based
Firewall Name This is a unique identifier describing an instance of a deployed firewall service.

Customer Reference to the customer within Cisco NSO.

Device List This is a list of devices which the firewall services will be applied to.

A list of security zones.

Security Zones
Interfaces belonging to each security zone.

Traffic class is described by a class map.

Traffic Classes Each class map defines a set of protocols or access lists to classify traffic.

Optionally, each class may also define an ACL to classify traffic.

Security policies are described by a policy map.

Security Policy A policy map defines what to do with a certain type of traffic (drop, pass, inspect).

The policy also defines zone pairing and traffic direction.

The table above lists the parameters required to configure a zone-based firewall.

2-84 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
vFirewall Service Model – ACL Based
Data path in the model: L vfirewall
 name (key)
 device K name R customer R device
 customer
 acl L ACL
 acl/name
K name R interface E direction
 acl/interface
 acl/direction
L rules
 acl/rules/
 acl/rules/number (key)
 acl/rules/action K number E action E protocol
 acl/rules/protocol
 acl/rules/source-ip source-ip source-port destination-ip
 acl/rules/source-port
destination-port
 acl/rules/destination-ip
 acl/rules/destination-port
 acl/rules/interface
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 25

The figure shows a YANG model structure for an ACL-based firewall.

vFirewall Service Model – ACL Based (Cont.)
module firewall{
YANG statements representing our
list firewall {
leaf name { ... } informal design:
list devices {
leaf device { type leafref ... }
 There can be many service instances.
}  Each instance can be applied to several
list acl {
devices.
leaf name { ... }  Each instance has several ACLs.
leaf interface {type leafref ...
}
leaf direction{ ... }
list rule {
leaf number { ... }
leaf src-ip { ... }
leaf dst-ip { ... }
leaf src-port { ... }
leaf dst-port { ... }
leaf protocol { ... }
leaf action { ... }
}
}
}
}
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 26

The figure shows a YANG model structure for an ACL-based firewall.

2-86 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
vFirewall Service Model – Zone Based
Data path in the model: L vfirewall
 name (key)
K name R customer R device
 device
 customer L security-policies
 security-policies/
E destination zone E source-zone
 security-policies/destination-zone
 security-policies/source-zone K name
 security-policies/name
L traffic-class
 security-policies/traffic-class
 security-policies/traffic-class/name K name R ACL E action
 security-policies/traffic-class/ACL
L match
 security-policies/traffic-class/action
 security-policies/traffic-class/match EK protocol
 security-policies/traffic-class/match/protocol
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 27

The figure shows a YANG model structure for a zone-based firewall.

vFirewall Service Model – Zone Based (Cont.)
module firewall{
YANG statements representing our
list firewall {
leaf name { ... } informal design:
list devices {  There can be many service instances.
leaf device { type leafref ... }
 Each instance can be applied to several
} devices.
list security-policies {  Each instance defines a security policy.
leaf name { ... }
leaf source-zone { ... }  A security policy defines traffic classes and
leaf destination-zone { ... }
what to do with them.
list traffic-class {
leaf name { ... }
leaf action { ... }
leaf ACL { ... }
list match {
leaf protocol { ... }
}
}
}
}
}
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 28

The figure shows a YANG model structure for a zone-based firewall.

2-88 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Consolidating Our Model
 Two types of firewall: Zone based and ACL based
 A combination of both can be used.
 We need to consolidate both models into a single service.
 Some parameters are shared:
 Device-list
 The interface where we apply to
 Traffic class/protocol

After looking at the parameter list, we can identify that some of them could be consolidated since they are
shared between the two approaches.

Service Parameter Definition – ACL
Parameter Value YANG Statement YANG Data Type
Firewall Name The alphanumeric name Leaf (key) String
Customer Reference to the customer Leaf Leafref
Devices — List —
Device Link to a device in NSO Leaf Leafref
Access Lists — List —
Name The alphanumeric name Leaf (key) String
Interface The interface in the Firewall Leaf Leafref
Direction In or Out Leaf Enumerate
Rules — List —
Number Positive number Leaf (key) uint32
Source IP Any valid IPv4 prefix Leaf inet:ip-prefix
Source Port Positive number Leaf uint16
Destination IP Any valid IPv4 prefix Leaf inet:ip-prefix
Destination Port Positive number Leaf uint16
Protocol IP, TCP, UDP, ICMP Leaf Enumerate
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 30
Action Permit, Deny Leaf Enumerate

The table defines YANG data types for an ACL-based firewall YANG model.

2-90 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Parameter Definition – Zone Based
Parameter Value YANG Statement YANG Data Type
Firewall Name The alphanumeric name Leaf (key) String
Customer Reference to the customer Leaf Leafref
Devices — List —
Device Mandatory Leaf Leafref
Security Policies — List —
Name The alphanumeric name Leaf (key) String
Source Zone Trusted or Internet Leaf Enumerate
Destination Zone Trusted or Internet Leaf Enumerate
Traffic Classes — List —
Name The alphanumeric name Leaf (key) String
Action Inspect, Pass or Drop Leaf Enumerate
Match — List —
Protocol A list of protocols Leaf (key) Enumerate

The table defines YANG data types for the zone-based firewall YANG model.

Consolidating Our Model
module firewall{
These are module firewall{
common
list firewall { parameters. list firewall {
leaf name { ... } leaf name { ... }
leaf customer {type leafref ... } leaf customer {type leafref ... }
leaf device {type leafref ... } leaf device {type leafref ... }
list acl {
list security-policies {
leaf name { ... } leaf name { ... }
leaf source-zone { ... } leaf interface {type leafref ... }
leaf destination-zone { ... } leaf direction { ... }
list traffic-class { list rule {
leaf name { ... }
leaf action { ... } leaf number { ... }
leaf ACL { ... } leaf src-ip { ... }
ACL has already leaf dst-ip { ... }
list match { been defined. leaf src-port { ... }
leaf protocol { ... } leaf dst-port { ... }
} leaf protocol { ... }
} leaf action { ... }
} }
} }
} }
}
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 32

The figure shows common elements between the YANG models for an ACL- and zone-based firewall.

2-92 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Consolidating Our Model (Cont.)
module firewall{ …
list firewall { list ac-list {
leaf name { ... }
leaf name { ... }
leaf customer { type leafref ... } leaf interface {type leafref ... }
leaf direction { ... }
leaf device { type leafref ... }
list rule {
list security-policies { leaf number { ... }
leaf name { ... } leaf src-ip { ... }
leaf source-zone { ... } leaf dst-ip { ... }
leaf destination-zone { ... } leaf src-port { ... }
leaf dst-port { ... }
list traffic-class { leaf protocol { ... }
leaf name { ... } leaf action { ... }
leaf action { ... } }
leaf ACL { type leafref ... } }
}
list match {
leaf protocol { ... }
}
}
}
}
…
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 33

The figure shows a single YANG model for an ACL- and zone-based firewall.

Informal Service Design: Sample Service Configuration
Zone Based  The same set of parameters as with
! Match by protocol
class-map type inspect match-any INTERNAL Cisco IOS
match protocol http
match protocol ftp
match protocol sip
match access-group name HOSTS
! Match by access list
ip access-list extended HOSTS ACL Based
permit ip 10.0.0.0 255.255.0.0 any interface GigabitEthernet1
! ip access-group Test in
exit
policy-map type inspect POLICY ip access-list extended Test
class INTERNAL permit ip 10.10.0.0 0.0.255.255 10.10.0.0
inspect 0.0.255.255 eq 8080
zone-pair security TrustedToInternet source
Trusted destination Internet service-policy
type inspect POLICY
! Assigning interfaces to security zones
interface GigabitEthernet0/0
zone-member security Trusted Nothing to do with
!
interface GigabitEthernet0/1 service parameters
zone-member security Internet
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 34

2-94 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Informal Service Design: vFirewall
 Finally:
 Finish the YANG model by describing the leaves.
 Write the Java code to set the configuration.
 Compile and load into Cisco NSO.
 Test the new service package.

After we finish our YANG models, we need to implement the device mapping either using XML templates,
Java code, or a combination of both. Then we compile the new package, load it into Cisco NSO, and test if it
works correctly.

Designing a vQoS Service

Self-Service SLA

Layer 3 IOS Traffic

Tunneling Policer

IPsec
Internet
SP Network RTR
CPE VM Internet
Gateway
IOS Traffic Shaper
 Select SLA bundle:
 Bandwidth [Mbps]: 10, 25, 50, 100, …

User Self-Service Portals

Customers should be able to use a self-service portal to change their service-level agreement (SLA) levels.
When they change a new SLA level, Cisco Network Services Orchestrator (Cisco NSO) needs to apply
changes on the customer’s vRouter and implement traffic policing.

Layer 3 IOS Traffic

Tunneling Policer

IPsec
Internet
SP Network RTR
CPE VM Internet
Gateway
IOS Traffic Shaper
 Select QoS bundle:
 HTTP bandwidth: 25%
 VoIP bandwidth: 50%
User Self-Service Portals  …

Customers should also be able to choose quality-of-service (QoS) levels for their traffic. This is also done
over a self-service portal and based on the request from the portal, Cisco NSO needs to implement a Traffic
Shaper in the customer service chain.

Informal Service Design: vQoS
 A service model is a set of parameters required to describe a service.
 It has nothing to do with the actual service implementation on the device.
 Our QoS service does the following:
 Police traffic coming from CPE according to their SLA bundle.
 Shapes traffic from CPE according to the QoS bundle.

Customer Bundle

SLA: 5 Mbps
QoS: HTTP 50%, VoIP 25%

To implement the Traffic Policer/Shaper and keep treating it as a black box, the following parameters are
required:
 Customer SLA level
 QoS level per traffic class

2-98 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Service Configuration – vQoS
This is a unique identifier describing an instance of a deployed service
Service Name
It is used to provide a descriptive name for the service instance.

Customer Reference to the cusotmer.

Device List This is a list of devices to which the service will be applied.

SLA
This is a set of pre-defined SLA levels.

This is a list of QoS traffic classes.

QoS Traffic Class The traffic class, already defined by the firewall service.
Bandwidth Percentage of available bandwidth.
Interface This is the interface to which we will apply the rules.

The table above specifies parameters required to implement the Traffic Shaper/Policer service.

vQoS Service Model
Data path in the model: L vQoS

 name (key) R customer R device

K name
 device
 customer
 sla
 qos
 qos/traffic-class (key) E sla

 qos/bandwidth
L qos

RK traffic-class

E bandwidth

The figure above shows an outline of the Traffic Policer/Shaper YANG model.

2-100 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
vQoS Service Model (Cont.)
module traffic{ YANG statements representing our
list traffic {
leaf name { ... } informal design:
leaf customer { type leafref ... }  There can be many service instances.
list devices {  Each instance can be applied to several
leaf device { type leafref ... } devices.
}
leaf sla { ... }  Each instance has several ACLs.
list qos {
leaf traffic-class { type leafref ... }
leaf bandwidth { ... }
}
}
}

The figure above shows a Traffic Policer/Shaper YANG model.

Parameter Definition: vQoS
Parameter Value YANG Statement YANG Data Type
Name The alphanumeric name Leaf (key) String
Customer Link to the customer within Leaf Leafref
Cisco NSO
Devices — List —
Device Link to the device within NSO Leaf Leafref
SLA 1, 5, 10, 100 Leaf Enumerate
QoS — List —
traffic-class Link to the traffic class Leaf (key) Leafref
defined by the firewall service
bandwidth 1–100% Leaf Percentage (typedef)

The table above specifies YANG data types required to implement the Traffic Shaper/Policer service.

2-102 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Informal Service Design: Sample Service Configuration
Traffic Shaping (QoS)  The same set of parameters as with
class-map type inspect match-any WEB Cisco IOS
match protocol ftp
match protocol http
match protocol smtp
!
class-map type inspect match-any VOIP
Traffic Policing (SLA)
match protocol rtp
match protocol sip Traffic class-map match-any SLA
! match any
classification
policy-map POLICY already done
class VOIP interface GigabitEthernet0/0
service-policy input POLICY
bandwidth percent 25 exit
! policy-map SLA
class WEB class SLA
bandwidth percent 50 shape average 10000000
! !
!
interface GigabitEthernet0/0
service-policy input POLICY
exit
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 44

The output above shows Traffic Shaper and Traffic Policer configuration on Cisco IOS devices.

Summary
This topic summarizes the key points that were discussed in this lesson.
 Services should always be treated as black boxes—either when designing them for the first time or using
them in a stacked service model. What matters is their YANG model interface.
 Using the stacked services approach reduces complexity and provides a higher-level abstraction that
enables complex service implementation and management.

Service Chaining Design

Overview
This lesson expands on the concept of stacked services with examples of resource allocation and more
complex service bundle design.

Objectives
Upon completing this lesson, you will be able to design a service bundle composed of multiple stacked
services, using resource allocation. This ability includes being able to meet these objectives:
 Understand the requirements of designing Cisco NSO for complex services
 Use Reactive FASTMAP for stacked service models
 Describe how resource allocation services are used to provision common resources
 Describe how service stacking is used

Complex Service Design

Complex Service Design Requirements

 Complex services have several requirements:
 Interdependency requiring two or more provisioning stages
 Integration with external resource inventories
 Reuse of service models: stacked services

 Possible approaches:
 Regular FASTMAP: Preferred approach
 Reactive FASTMAP: Alternative approach; use when regular FASTMAP cannot be used:
 Spinning up VMs first and configuring them when they become available
 When devices are not reachable until parts of the service have been set up
 Service automatically responds to changes in the environment (e.g. VM mobility, network connectivity)
 Service automatically responds to changes in service parameters (e.g. service catalog, policy)
 Service takes a long time to activate and you do not want to block operators

Apart from the YANG model and Java or XML mapping templates, a complex service will have a number of
additional requirements. It may require:
 Staging in service provisioning: For example, when you want your Provider Edge (PE) routers to be
provisioned before Customer Edge (CE) routers when configuring a Multiprotocol Label Switching
Virtual Private Network (MPLS VPN) – or you want to make sure Virtual Machines (VM) are up and
running before configuring Virtual Network Functions (VNFs).
 Integration with external inventories: For example, IP addresses need to be received from an external
inventory system.
 Existing service models may need to be reused to build a higher level service model: For example, a
Cloud VPN Medium package consists of a Virtual Router (vRouter) and a Virtual Firewall (vFirewall)
service.

When staging or an external resource access is required, the Reactive FASTMAP design pattern needs to be
used. When reusing existing service models, there are two paths you can take:
 Create a high-level service and use Reactive FASTMAP to instantiate lower-level services.
 Create a high-level service, reuse low-level service YANG models and templates, but write a single
service application code that will touch the devices.

2-106 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Reactive FASTMAP
 Implemented in a single service Example 1: Example 2:
1. Instantiate VM. 1. Request IP address.
 Use cases: 2. Configure VM 2. Configure VM when
 Interdependency of provisioned when VM available. IP address allocated.
objects (two or more stages)
 Integration with resource Service Model Service Model
inventories vRouter vRouter
Reactive (Reactive
FASTMAP FASTMAP)
Integration with Local application for IP
VM management address allocation

Can also be integrated with

Regular FASTMAP is not suitable for integration with external resource inventories because it does not
allow the handling of deletions (only the CREATE event is customizable). A shared Java package can be
used to directly allocate resources without subscribing to Configuration Database (CDB) changes and the use
of Reactive FASTMAP for resources that can be locally calculated and returned immediately. The resource
values must be stored in CDB, though, so they can be removed by FASTMAP if the service instance is
deleted.

Direct Resource Allocation

Resource Allocation Requirements and Restrictions

 Resources are part of a service model.
 Some resources are shared among multiple service models (e.g. IP address
pools).
 Some resources are stored in external systems (e.g. existing SP inventory
databases).
 Some resources take time to be allocated (e.g. VM instantiation).
 Some resources are prerequisites for other parts of a service instance (e.g. VM
instantiation).

Most services will require some type of resource to be assigned to each service instance. Most resources
should be automatically assigned, if possible, to unburden the operator and prevent human error. The
automatically allocated resources are generally assigned in one of the two ways:
 Allocated from a repository of available resources (e.g. interfaces on individual routers, IP addresses or
subnets from an address range). These repositories are not necessarily implemented on Cisco Network
Services Orchestrator (Cisco NSO) alone as the service provider may have existing repositories and
Cisco NSO must be integrated with them.
 Calculated based on a criteria that is part of the service model design.

2-108 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Resources Within Service Models
 Preferred approach as it purely relies on
FASTMAP. leaf ip-address {
tailf:info “PE-CE IP Address";
 Use Java to automate resource allocation. type inet:ipv4-address;
}

L3 MPLS VPN Example: Calculate PE-CE addressing from a unique site ID.
// Calculate IP address from unique site ID: 172.x.y.z
int pe_ip_o2 = 31 - (link_id * 4) / 4096; // Second octet
int pe_ip_o3 = ((link_id * 4) % 4096) / 64; // Third octet
int pe_ip_o4 = ((link_id * 4) % 4096) % 64 + 1; // Fourth octet for PE side
int ce_ip_o4 = pe_ip_o4 + 1; // Fourth octet for CE side ( = PE + 1 )
String link_ip = "172." + pe_ip_o2 + "." + pe_ip_o3 + "." + pe_ip_o4; // Link IP address
String peer_ip = "172." + pe_ip_o2 + "." + pe_ip_o3 + "." + ce_ip_o4; // Peer IP address
used in BGP config
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 8

The figure illustrates how we can add an algorithm to calculate IP addresses for a service model without
having to use any resource pool. This method relies on the designed service model algorithm.

Shared Resources Among Multiple Service Models
module resources {
 The same resource pool (e.g. …
interfaces) can be used by multiple container resources {
service models. list mgmt-ip-addr { Resource value
key name;
 Resource utilization is tracked using leaf name { type inet:ipv4-address; }
the instance-identifier type. leaf in-use-by { type instance-identifier; }
}
}
} Optional back-reference for
Example: Retrieve an available management
IP address from the resource pool.
easier troubleshooting
// Retrieve unique management IP address from resource pool
for (NavuNode n1: ncsRoot.container("services").xPathSelect("res:resources/res:mgmt-ip-addresses")) {
…
Find an available IP address.
// Store the allocated address in resource pool
ncsRoot.container("services").container("resources").list("mgmt-ip-addresses").sharedCreate(ipAddr);

Store the allocated IP address in the resource pool.

This figure illustrates an approach where a separate resource allocation service is used to store the allocated
resources. As there is not algorithm to ensure uniqueness, we must store allocated IP addresses in a shared
repository.
The Java code snippet illustrates the two tasks that need to be accomplished:
 Determine an available IP address based on the currently allocated IP addresses.
 Store the newly allocated IP address in the shared repository.

2-110 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Alternative Approaches
 Reactive FASTMAP and CDB subscriber:
 Longer processing
 Order dependency (e.g. VM instantiation)

 Use of pre- and post-modification callbacks

 Ensure proper cleanup of external resources

When the use of regular FASTMAP is not possible, we need to resort to other techniques:
 A post-modification callback can be used in combination with regular FASTMAP to implement the
de-allocation of resources when they are obtained from an external repository.
 Reactive FASTMAP can be used when there is a requirement for more stages in the provisioning process
or when the process is time-consuming and we do not want to block the operator.

Reactive FASTMAP and CDB Subscriber Process
Service Model Application Component
L vrouter
init()
CDB
C intf-mgmt Subscriber  Subscribe to CDB changes in
/ncs:services/resources/ip-addresses
1. change
ip-address run(): CREATE, DELETE operations
write 2.
3.  Allocate IP address
 De-allocate IP address

finish()
CREATE callback  Unsubscribe from CDB changes and cleanup

Reactive FASTMAP

The figure illustrates the components required to implement the Reactive FASTMAP pattern.

2-112 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Allocating Resources to a Service Using Reactive FASTMAP
 Service instance CREATE callback:
 Trigger resource request(s).
 Wait until resources available (Reactive FASTMAP).
 Service-to-device mapping configuration …

 Resource CDB subscriber:

 Subscribe to resources.
 Allocate or de-allocate resources upon request.
 Java code for allocation can be reused for many dependent service models (e.g. VM
instantiation is the same for all types of NFVs).

Resource allocation is triggered from the CREATE callback within the regular FASTMAP code. The
FASTMAP code tries to create the resource and an application that is running outside the CREATE code will
pick up the CREATE event, provision the resource, and let the regular FASTMAP code continue once it is
done. This application is a CDB subscriber, which will subscribe to the data tree for the service we are
implementing and wait for CREATE or DELETE events. Once a CREATE or DELETE event is caught, it is
up to the CDB subscriber application code to provision or de-provision the resource accordingly.

Application Component for Resource Allocation
package com.example.vrouter;

public class NavuConfigSubscriber implements ApplicationComponent {

private static final Logger log = Logger.getLogger(NavuConfigSubscriber.class);
private NavuCdbSubscriber navuCfgSubscriber;
private volatile boolean doRun = false;

Subscribe to the data tree.

public void init ( ) { … }
System.out.println("Starting the CDB Connection...");
try {
wsess = wcdb.startSession(CdbDBType.CDB_OPERATIONAL);

…
} Process resource requests.
public void run( ) { … }
Unsubscribe and clean up.
public void finish( ) { … }

The figure shows an example of the CDB Subscriber code.

Resource Allocation Service

 Use for shared resource pools
Service Model Service Model
 Can create a resource vRouter vFirewall
allocation model for a number Reactive Reactive
of resources FASTMAP FASTMAP
 ID
 IP Address Subnet Resource
Allocation
Local or External Service
Resource
Repository

Single service for multiple resources (e.g. IP

An alternative approach to using dedicated CDB subscribers is to use a Resource Allocation Service. This
service can allocate different resources such as IP addresses, VLAN numbers, and so on. A single service can
take care of allocating several different resources shared between different services. For example, both the
vRouter and vFirewall service require the management interface IP address allocation. It makes sense to
implement a single Resource Allocation Service and use it for both the vRouter and the vFirewall service.

C resource-pools
Resource Allocation Service
L ip-address-pool

 Cisco NSO packages in L allocation

examples.ncs:
C request
 resource-manager
 id-allocator subnet-size
 ip-address-allocator C response

subnet

L id-pool

L allocation

C request

C response

An implementation of a Resource Allocations Service is included with Cisco NSO installation. The packages
resource-manager, id-allocator and ip-address-allocator are provided with the
service-provider/virtual-mpls-vpn example. To use the service in your own code, load the packages in Cisco
NSO and reference the Java code from your packages.

2-116 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Resource Allocation Service Configuration – ID Pool
L id-pool
 Resource pools must be preconfigured in the CDB.
C range
 ID Pool:
start end
 Name
 Range (start and end) C exclude

 Excludes Configure an ID pool.

start end

admin@ncs(config)# resource-pools id-pool cats range start 1 end 99

admin@ncs(config-id-pool-cats)# exclude range 2 10
admin@ncs(config-id-pool-cats)# commit
admin@ncs# show resource-pools id-pool cats
NAME ID ERROR ID
---------------------------
cats Mitsu - 1 Show current allocations (operational data).
Snowball - 11

Configuration for an ID pool requires setting a pool name, the range (start and end numbers), and possible
excludes. The configuration must be present in the CDB before requesting a new ID from the pool;
otherwise, the allocation will fail.
After allocations are made, you can examine the current ID pool exhaustion with the show resource-pools
id-pool <name> command. The show command shows operational data – the numeric IDs allocated, along
with the allocation IDs. If you want to display the services, examine the configuration data with the show
running-config resource-pools command.
admin@ncs# show running-config resource-pools id-pool cats
resource-pools id-pool cats
allocation Mitsu
allocating-service /services/kitten:kitten[name='Mitsu']
!
allocation Snowball
allocating-service /services/kitten:kitten[name='Snowball']
!
range start 1
range end 99
exclude 2 2
!

Resource Allocation Service Configuration – Subnet Pool
L ip-address-pool
 Subnet Pool:
C subnet
 Name
 Subnets address cidrmask
 Excludes C exclude
Configure a subnet pool.
address cidrmask

admin@ncs(config)# resource-pools ip-address-pool management-cats subnet 172.16.0.0 16

admin@ncs(config-ip-address-pool-management-cats)# exclude 172.16.0.1 32
admin@ncs(config-id-pool-cats)# commit
admin@ncs# show resource-pools ip-address-pool management-cats
NAME ID ERROR SUBNET FROM
-----------------------------------------------------------------
management-cats Mitsu - 172.16.0.16/28 172.16.0.0/16
Snowball - 172.16.1.0/24 172.16.0.0/16

Show current allocations (operational data).
Advanced Cisco Network Services Orchestrator v2.0 18

Configuration for an IP Subnet pool requires setting a pool name, the subnets and possible excludes. The
configuration must be present in the CDB before requesting a new subnet from the pool; otherwise, the
allocation will fail.
The subnet allocator automatically splits the larger configured subnet into smaller ones upon request. In the
example below, we have configured the pool management-cats with the subnet 172.16.0.0/16, and excluded
the IP address 172.16.0.1.
The first allocation request for a subnet for the Mitsu service with a CIDR mask of /28 returned the subnet
172.16.0.16/28, because the first /28 block of addresses was marked as not available with the exclude
statement.
The second allocation request for a subnet for the Snowball service with a CIDR mask of /24 returned the
subnet 172.16.1.0/24, because the first /24 block of addresses was already allocated elsewhere.
After allocations are made, you can examine the current subnet pool exhaustion with the show
resource-pools ip-address-pool <name> command. The show command shows operational data—the
subnets allocated, along with the allocation IDs. If you want to display the services, examine the
configuration data with the show running-config resource-pools command.
admin@ncs# show running-config resource-pools ip-address-pool management-
cats
resource-pools ip-address-pool management-cats
allocation Mitsu
allocating-service /services/kitten:kitten[name='Mitsu']
request subnet-size 28
!
allocation Snowball
allocating-service /services/kitten:kitten[name='Snowball']
request subnet-size 24
!
2-118 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
subnet 172.16.0.0 16
exclude 172.16.0.1 32
!

Reactive FASTMAP and CDB Subscriber Process
CDB
subscription
Service Model Resource Allocating Service to requests

L vrouter C resource-pools
Resource usage
inventory 2.
C intf-mgmt L ip-address-pool

ip-address Resource L allocation Allocate IP

Allocator address
Request IP address C request
1.
Re-deploy service
3. C response
Retrieve IP address
4.
CREATE callback
Can also be integrated with Inventory
an external inventory database
Reactive FASTMAP

This figure shows the call flow when a Resource Allocating Service is used to allocate IP addresses.

2-120 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Resource Allocation Service
package com.cisco.resourcemanager; Shared package
public class ResourceAllocator {
Process management subnet requests
public static void subnetRequrst(NavuNode service, NavuNode root, String poolName, int
cidrMask, String id)
throws NavuException, ConfException, ResourceException {

} Return allocated management subnet

public static ConfIPPrefix subnetRead(Cdb cdb, String poolName, String id)

throws ResourceException, NavuException, ConfException {

} Repeat for all different resource pools

…

The figure above illustrates how the code for a Resource Allocation Service is structured.

VM Management Service

VM Management Service Request for new VNF

 Composed of multiple C vm-manager

packages: vm-manager
L start
 vm-manager
 vm-manager-esc ESC-specific service

 ESC NED Reactive C vm-manager

vm-manager-esc FASTMAP
 Subscribers: L esc
 vmCdbSubscriber
 notifCdbSubscriber
C devices
ESC NED
L device

esc_datamodel
ESC configuration

A sample implementation of a VM Management service is also included in Cisco Network Services

Orchestrator (Cisco NSO) examples, using Cisco Elastic Services Controller (Cisco ESC) as the virtual
machine (VM) lifecycle manager.
The example is a bundle of two services, vm-manager and vm-manager-esc.
The top-level service defines an interface for requesting a new virtual machine, or deployment. In the model
vm-manager.yang, a list of start requests is defined. This list is used by other services, to request a new
virtual machine, independent of the underlying Virtual Network Function Manager (VNF Manager or
VNFM).
In the vm-manager-esc package, a CDB subscriber (vmCdbSubscriber) is implemented, subscribing to the
path /vmm:vm-manager/vmm:start. When a new start request is created, the subscriber copies the request
data to the list /vmm:vm-manager/vmm:esc. The esc list is actually a service (looking at the
esc-manager.yang package model, we see the servicepoint statement). When a new list entry is created, the
mapping logic for the vm-manager-esc service is run. It transforms the request for a new virtual machine into
Cisco ESC device configuration.
By using the additional layer of abstraction between vm-manager-esc and the services requiring virtual
machines, we can make sure that the process of requesting a new virtual machine and removing it is
asynchronous. The start request for a new virtual machine is part of the device modifications for the top-level
service, and as such part of the FASTMAP process. Even when the top-level service instance is removed,
only the start request is removed in the same transaction. This ensures that any potential virtual device
configuration can be successfully removed before the virtual machine itself is deleted.
Using the Cisco ESC Network Element Driver (NED), the request for a new virtual machine is relayed to
Cisco ESC via NETCONF.
Another subscriber (notifCdbSubscriber) is part of the vm-manager-esc package. This subscriber is
responsible for parsing NETCONF notifications coming back from Cisco ESC, regarding the status of the
virtual machine deployment. For example, when Cisco ESC sends the VM_ALIVE notification, the
subscriber will add the new device into Cisco NSO, and perform a sync-from operation.
2-122 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
There are a couple of important benefits of this solution:
The top-level service is independent of the underlying implementation of the VNFM.
The request for a new virtual machine is asynchronous (implemented using Reactive FASTMAP), since the
process of provisioning a new virtual machine takes some time.
The asynchronous process works in reverse as well – when the request for a new virtual machine is removed,
it is picked up by the subscriber and the virtual machine is removed asynchronously.

Reactive FASTMAP and CDB Subscriber Process
CDB
Service Model vm-manager subscription vm-manager-esc
to requests
L vrouter C vm-manager C vm-manager

R device L start 2. L esc 4.

Request new VNF Create esc VM

1. 3. Configure ESC

vmCdbSubscriber CREATE callback

CREATE callback
C devices
Reactive FASTMAP Re-deploy service L device
5.
notifCdbSubscriber esc_datamodel

This figure shows the call flow when the VM Manager Service is used to request a new VNF deployment.

Stacked Services
 Cloud VPN consists of a bundle of interdependent services:
 Service bundles and/or self-service by selecting individual components
 Resource inventories (e.g. VLANs, IP addresses and subnets)

 Stacked Services: A high-level service creates instances of low-level

(resource-facing) services

The final goal of Cloud VPN is to offer service bundles. A service bundle is a set of individual primitive
service instances like vFirewall, quality of service (QoS), and so on. Customers and operators should be able
to activate service bundles without having to configure each of the primitive service instances individually.
This is called service stacking – a high-level service instantiates one or more lower-level service instances.
Additionally, these instances need to communicate with common resource inventories for actions such as
VLAN and IP address allocation.
It is possible for one high-level service to create another low-level service instance. In this case, the low-level
service is FASTMAPed similar to how the data in /ncs:devices/device is FASTMAPed when a normal
resource-facing service (RFS) manipulates the device tree. We can imagine a high-level service (maybe a
customer facing service [CFS]) called CloudVPN that in its turn creates real RFS services vRouter and/or
vFirewall.
The same principles apply on the FASTMAP data when services are stacked as in the regular RFS service
scenario. The most important principle is that the data created by a FASTMAP service is owned by the
service code. Regardless of whether we use a template-based service or a Java-based service, the service
code creates data, and that data is then associated with the service instance. If the user deletes a service
instance, FASTMAP will automatically delete whatever the service created, including any other services. So,
if the operator directly manipulates data that a service created, the service becomes "out of sync". Each
service instance has a "check-sync" action associated to it. This action checks if all the data that the service
creates or writes is still there.
This is especially important to realize with stacked services. In this case, the low-level service data is under
the control of the high-level service. Consequentially, it is forbidden to directly manipulate that data. Only
the high-level service code may manipulate that data. Cisco Network Services Orchestrator (Cisco NSO) has
no built-in mechanism that would detect when data created by service code is manipulated "out of band".

Cloud VPN Network Topologies

SP Data Center

L3 or L2
SP Network
vR vFW Internet
CPE VM VM Internet
Gateway

vNG-IPS vWSA
VM VM

 Several bundles of Cloud VPN are available

Technically, there are numerous bundles of Cloud VPNs that could be made available to the customer. Any
combination of Layer 3 or Layer 2 connectivity, firewall, Intrusion Prevention Systems (IPS), Web Security
Appliance (WSA), and other services such as QoS could be made available, and all of these bundles should
be activated and configured end to end.

2-126 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Sample Service Provisioning Sequence
1. VLAN 519 1. Allocate resources: VLANs, IP addresses,
2001:DB8:0207::/64
etc.

VM
2. Create a VM.

3.
3. Configure connectivity: virtual switch
VLAN 519 (including management access to VM).
VM

4.
2001:DB8:0207::1/64 4. Configure a virtual router: IPsec aggregation
VLAN 519 vR (prerequisite: management access).
VM
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v2.0 27

The above figure shows a typical sequence for service provisioning within Cloud VPN.

Cloud VPN Managed Components – Stacked Services

Customer
Customer
Customer
Service  One or more customer services
Service
Service  Each service contains one or more resources

Resource
Resource
Resource
Service  One or more resource services (e.g. vR, vFW, vIPS)
Service
Service

Resource  One or more resource pools (e.g. IP addresses, subnets,

Resource
Resource VLANs)
Pools
Pools
Pools  Can perform local allocation or use an external repository

From the perspective of Cisco Network Services Orchestrator (Cisco NSO), the Cloud VPN deployment
consists of three major building blocks:
 Customer service (or the service bundle)
 Resource-facing services (such as vFirewall, vRouter, and so on)
 Resource pools (IP address allocation, VLAN ID allocation, and so on).

2-128 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Cloud VPN: Stacked Service Models
Service Model A: Service Model B:
vR + vFW vR + vFW + vIPS

Service Model Service Model Service Model Service Model

CPE vR vFW vIPS

Configures CPE after Two-stage process (reactive FASTMAP):

Resource VM
Day-0 provisioning  Instantiate VM
Manager Management
Service Service  Configure VM

 Top-level service model defines customer services or service bundles.

The figure above shows a high-level design of end-to-end service lifecycle management within Cisco NSO.

Stacked Services (Cont.)
 A high-level service interfaces other services through their YANG models:
 A high-level service simply sets values inside the YANG model

 Low-level services are treated as a black box and inherit:

 The mapping logic (Java and/or XML)
 Applications in the service package

YANG models serve as the sole interface between high-level and low-level services.

2-130 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Stacked Services (Cont.)
High Level Service Low Level Services
CREATE callback
L bundle L vrouter or XML templates

vrouter C intf-mgmt

vfirewall ip-address

L vfirewall
CREATE callback
or XML templates
C intf-mgmt

CREATE callback ip-address

(Java Code)

The figure illustrates how a high-level service can interface low-level services. In the example above, we
have a high-level service called “bundle”, which can represent one of the service bundles of Cloud VPN. In
this case, it is the base bundle, which includes a virtual router (vRouter) and a virtual firewall (vFirewall).
The Bundle service is defined by the presence of vrouter and vfirewall leafs in its YANG model. Both of the
leaves are of Boolean type and indicate the presence of the vrouter and vfirewall service in the bundle. The
operator simply needs to tick which low-level services to include in the bundle.
To instantiate the lower-level services, the high-level service create callback code needs to create service
instances in the ncs:services list and set values for leaves required to define a service instance for vrouter and
vfirewall. Once the values are set, the service to device mappings take place the same way they would if the
service was instantiated in a standalone manner. Similarly, all the applications that are part of the service
package, such as Configuration Database (CDB) subscribers and resource allocators, are initiated and run.

Stacked Services (Cont.)
@ServiceCallback(servicePoint="bundle-servicepoint",
callType=ServiceCBType.CREATE)
public Properties create(ServiceContext context,
NavuNode service,
NavuNode ncsRoot,
Properties opaque) Create the
throws DpCallbackException { service
…
instance.
NavuList services = Set the leaf
ncsRoot.container("services").list("vrouter");
value.
NavuContainer srvc = services.sharedCreate(<key value>);
srvc.container("intf-mgmt").leaf("ip-address").set("10.1.1.1");

services =
ncsRoot.container("services").list("vfirewall");
NavuContainer srvc = services.sharedCreate(<key value>);
srvc.container("intf-mgmt").leaf("ip-address").set("10.1.1.2");
..

The figure above illustrates the create callback of a high-level service called “bundle”.

NFVO Bundle

 “VM Manager” using ETSI MANO compliant components

 VNFD -> VNFR
 NSD -> NSR
 Bundle packages:
 tailf-nfvo
 tailf-nfvo-esc

The NFVO Bundle (the Bundle) enables use of MANO compliant VNFDs and NSDs in NSO. It also enables
onboarding and instantiation of these on ESC. Further, if the VNF are to be managed by NSO, the Bundle
handles device creation/deletion in the NSO device tree.
In the MANO context a descriptor describes the metadata for a VNF or NS and supplies the general data
describing these, examples are number of virtual CPUs, memory requirements etc. A record on the other
hand describes the runtime data needed to instantiate a VNF or a NS. This can for example be IP addresses,
the actual network names which the VNF connects to, etc.

ETSI MANO Terms

 VNFD
 VDU
 VDU Connection Point
 VLD, VLR

A VNF Descriptor (VNFD) is a deployment template which describes a VNF in terms of deployment and
operational behavior requirements. The VNFD also contains connectivity, interface and KPIs requirements
that can be used by NFV-MANO functional blocks to establish appropriate Virtual Links within the NFVI
between VNFC instances, or between a VNF instance and the endpoint interface to other Network Functions.
The Virtualization Deployment Unit (VDU) contains specification for deployment of a single component.
The VLD provides a description of each Virtual Link. This type of information can be used by the NFVO to
determine the appropriate placement of a VNF instance, and by the VIM responsible for managing the
virtualized resources of the selected placement to determine the allocation of required virtualized resources
on a host with adequate network infrastructure. The VIM, or another Network Controller, can also use this
information to establish the appropriate paths and VLANs.

L vnfd

K id L deployment-flavor

L vdu K id

K id L internal-connection-point L vdu-profile

L virtual-storage L virtual-link K vdu

external-connection-
C virtual-compute L point K min-number-of-instances

max-number-of-
C virtual-cpu K instances

C virtual-memory L instantiation-level

L vdu-level

A VNF Descriptor (VNFD) is a deployment template which describes a VNF in terms of deployment and
operational behavior requirements. It also contains connectivity, interface and virtualized resource
requirements.
The Virtualization Deployment Unit (VDU) is a construct supporting the description of the deployment and
operational behavior of a VNF component, or the entire VNF if it was not componentized in components.
An internal-connection-point element is a type of connection point and describes network connectivity
between a VDU instance and an internal Virtual Link or an external connection point.
The Deployment Flavor describes a specific deployment version of a VNF with specific requirements for
capacity and performance. The VDU Profile holds additional instantiation data for a given VDU in a
deployment flavor.
The Instantiation Level information element describes a given level of resources to be instantiated within a
deployment flavor in terms of the number of VNF instances to be created from each VDU. All the VDUs
referenced in the level shall be part of the corresponding deployment flavor and their number shall be within
the range (min/max) for this deployment flavor.
The slide shows a part of the VNFD model as defined by NFV MANO. The complete model is shown below:
module: tailf-nfvo
+--rw nfvo
+--rw vnfd* [id]
+--rw id string
+--rw name? string
+--rw provider? string
+--rw version? string
+--rw description? string
+--rw vdu* [id]
| +--rw id string
| +--rw description? string

2-136 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
| +--rw id string
| +--rw description? string
| +--rw vdu-level* [vdu]
| +--rw vdu -> ../../../../vdu/id
| +--rw number-of-instances uint16
+--rw default-instantiation-level? -> ../instantiation-level/id

CSR VNFD

nfvo vnfd CSR1kv software-image name "CSR 1kv"

name "CSR 1000v" software-image container-format bare
provider Cisco software-image disk-format qcow2
version 1.0 software-image image http://10.131.1.72:8081/csr1k.qcow2
description "Cloud router" device-type cli ned-id ios-id:cisco-ios
vdu CSR bootup-time 300
internal-connection-point left recovery-wait-time 120
external-connection-point left day0 iosxe_config.txt
interface-id 1 mandatory
! !
internal-connection-point mgmt !
external-connection-point mgmt external-connection-point left
interface-id 0 !
! external-connection-point mgmt
internal-connection-point right management
external-connection-point right !
interface-id 2 external-connection-point right
! deployment-flavor basic
virtual-compute virtual-memory virtual-memory-size 4.0 vdu-profile CSR
virtual-compute virtual-cpu number-of-virtual-cpus 2 min-number-of-instances 1
virtual-storage root max-number-of-instances 1
type-of-storage root !
size-of-storage 8 instantiation-level basic
! vdu-level CSR
number-of-instances 1
default-instantiation-level basic
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator v4.2 5

The configuration on the slide shows a sample VNFD configuration for a CSR VNFD, consisting of a single
VDU. The CSR VDU has three network interfaces, connected to the three external connection points (left,
mgmt, right). Additionally, the VDU configuration contains the configuration that can be used for
onboarding the image (software-image) and flavor (virtual-compute and virtual-storage).

L vnfr
K,R id leafref to VNFD R vnfd-flavor

L vdu R instantiation-level
leafref to VDU
K,R id L day-0 L vnfd-connection-point

image-name K destination K,R id

flavor-name ? source R vlr

connection-point-
L address url
leafref to VNFD
K,R id leafref to VDU data external connection
connection point point
Leafref to VLR

A VNF Record is an entry holding information specific for a VNF deployment. The model refers to many
parameters defined in the VNFD and its VDUs.
Each VNFR can consist of multiple VDUs. For each VDU, we can specify image, flavor and day0
configuration (refer to tailf-nfvo-esc.yang YANG model for all options).
Using the VNFR, we also connect VNFD external connection points with Virtual Link Records (VLRs).

CSR VNFR

nfvo vnfr esc vnf-deployment admin branch-office esc0 vnfd-connection-point left

username admin vlr p_net
vnfr CSR1kv !
vnfd-flavor basic vnfd-connection-point mgmt
instantiation-level basic vlr mgmt
managed !
vdu CSR vnfd-connection-point right
image-name csr1000v-universalk9.03.17.00.S.156- vlr ce_net
1.S-std !
flavor-name cisco-csr !
day0 iosxe_config.txt !
url http://10.131.1.72:8081/csr_config.txt
variable NAME
value [ volvo_volvo_NewYorkrouter_CSR_esc0 ]
!
!
authgroup csr
connection-point-address mgmt
start 10.1.0.14
end 10.1.0.14
!
!

The configuration on the slide shows a sample VNFR configuration for a CSR VNFR, consisting of a single
VDU. The VNFR is referring to the VNFD, image and flavor defined in the previous slides.
The external connection points are associated with the Virtual Link Records (VLRs) defined in the NFVO
configuration.

 /nvfo/vnfr/esc/vnf-deployment is
a service model
 Creating an instance triggers ESC
deployment.
 netconf_notif.py is a
subscriber, processing
NETCONF notifications from
ESC.

Image source: NFVO Bundle documentation

The NFVO Bundle defines a service model at the /nfvo/vnfr/esc/vnf-deployment node. Creating a service
instance will trigger the mapping logic for the service and create ESC deployment configuration with a
combination of parameters from the referenced VNFD and VNFR.
Another part of the NFVO Bundle is a NETCONF notification subscriber. The subscriber parses notifications
sent by ESC regarding the deployment. It is responsible for adding managing the managed virtual device, and
setting operational data describing the current status of the VNF.
The list of ESC NETCONF notifications occurring during a VNF lifecycle is described below.
1. The VNFR service writes configuration data to ESC for one or more VDUs.
2. When OpenStack has deployed the VM, ESC sends VM_DEPLOYED. The VNFR service creates the
device and marks it as deploying.
3. When ESC can contact the VM it sends VM_ALIVE. The VNFR service marks the device as ready. If
the device is managed, the service sets up SSH and syncs from the device.
4. When all VMs in the deployment are alive, ESC sends SERVICE_ALIVE. The VNFR service marks
itself as ready and redeploys northbound services.

5. In case ESC loses connection with the VM, ESC will send VM_RECOVERY_INIT to indicate it is
trying to recover the VM. The VNFR service marks the device as recovering.
6. If the VM is rebuilt from scratch with only day0 configuration, ESC sends
VM_RECOVERY_DEPLOYED. The VNFR service updates the device table with the new device and
redeploys northbound services to allow re-application of day-n configuration.
7. When the VM is recovered, ESC sends VM_RECOVERY_COMPLETE. The VNFR service redeploys
northbound services to allow them to reapply day-n configuration.
8. The deployment configuration is deleted from ESC.
9. For each VM, ESC send VM_UNDEPLOYED. The VNFR service removes data from the device table.

10. When the entire deployment is deleted, ESC sends SERVICE_UNDEPLOYED.

2-142 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Onboarding New Flavor in ESC – Part 1

1. Create VNFD with VDU

admin@ncs(config)# show full-configuration nfvo vnfd ubuntu-esc vdu ubuntu-esc
nfvo vnfd ubuntu-esc
vdu ubuntu-esc
...
virtual-compute virtual-memory virtual-memory-size 1.0
virtual-compute virtual-cpu number-of-virtual-cpus 1
virtual-storage root
type-of-storage root
size-of-storage 8
...

Onboarding a new flavor in OpenStack using the NFVO Bundle is a two-step process. In the first step, create
a VNFD with at least one VDU. This VDU must specify the requirements for compute and storage with the
virtual-compute and virtual-storage nodes.

Onboarding New Flavor in ESC – Part 2

2. Create NFVO ESC Onboarding configuration

admin@ncs(config)# nfvo onboarding esc flavor ubuntu-esc-flavor vnfd ubuntu-esc vdu ubuntu-
esc esc-device esc0
admin@ncs(config-esc-device-esc0)# commit dry-run
cli devices {
device esc0 {
config {
esc:esc_datamodel {
flavors {
+ flavor ubuntu-esc-flavor {
+ description "Flavor generated by NSO from VNFD 'ubuntu-esc' and
VDU 'ubuntu-esc'";
+ vcpus 1;
+ memory_mb 1024;
+ root_disk_mb 8192;
+ }
}
}
...
© 2016 Cisco and/or its affiliates. All rights reserved. Advanced Cisco Network Services Orchestrator – Python v4.2 56

In the second step, create the NFVO ESC Onboarding configuration. Creating an entry in the onboarding list
will actually create an onboarding service instance. The mapping logic for the service will create the ESC
flavor configuration for the managed ESC device specified as an input parameter.
The parameters (vcpus, memory_mb, root_disk_mb) for the new ESC-managed flavor will be gathered from
the VDU defined in a VNFD, and the description will be generated automatically by the service.

2-144 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Onboarding New Image in ESC – Part 1

1. Create VNFD with VDU

admin@ncs(config)# show full-configuration nfvo vnfd ubuntu-esc vdu ubuntu-esc
nfvo vnfd ubuntu-esc
vdu ubuntu-esc
...
software-image name "Ubuntu Image"
software-image container-format bare
software-image disk-format qcow2
software-image image http://10.131.1.72:8081/ubuntu-esc.img
...

Onboarding a new image in OpenStack using the NFVO Bundle is a two-step process. In the first step, create
a VNFD with at least one VDU. This VDU must specify specification for the image using the software-
image node. In addition to the properties shown on the slide (name, image, container-format, disk-format),
the model allow setting the following properties through the optional additional_settings container:
 serial_console
 e1000_net
 virtio_net
 disk_bus

Onboarding New Image in ESC – Part 2

2. Create NFVO ESC Onboarding configuration

admin@ncs(config)# nfvo onboarding esc image ubuntu-esc-image vnfd ubuntu-esc vdu ubuntu-esc
esc-device esc0
admin@ncs(config-esc-device-esc0)# commit dry-run
cli devices {
device esc0 {
config {
esc:esc_datamodel {
images {
+ image ubuntu-esc-image {
+ src http://10.131.1.72:8081/ubuntu-esc.img;
+ disk_format qcow2;
+ container_format bare;
+ }
}
}
...

In the second step, create the NFVO ESC Onboarding configuration. Creating an entry in the onboarding list
will actually create an onboarding service instance. The mapping logic for the service will create the ESC
image configuration for the managed ESC device specified as an input parameter.
The parameters (src, disk_format and container_format) for the new ESC-managed flavor will be gathered
from the VDU defined in a VNFD. Additional custom properties will also be passed to ESC and OpenStack
Glance, as long as they are supported (list of supported properties on previous slide).

 tailf-nfvo-examples package contains examples:

 CSR-service-python
 CSR-service-java
 fw-router-service
 tailf-nfvo-staged-delete-example contains sample subscriber
for performing staged delete (2 steps)

Using the NVFO Bundle is very similar to using the VM Manager packages. To help you with development,
the bundle also contains a variety of examples for the Java and Python implementation of the service
mapping logic.
The first package, tailf-nvfo-examples package contains three services that work with VNFDs, VNFRs and
NSRs.
The second package contains an example subscriber that can be used to implement a staged delete. For
example, before the VNF is actually removed, it may be necessary to de-allocate any consumable resources
(licenses).

Common Application Types

Common Applications Roles

Service Application: Translates Action Provider: Provides implementation
service-level changes to device configuration of operator actions, e.g. software upgrade, clear
changes. Uses: MAAPI/NAVU alarm, etc. Uses: DPAPI (action parts)

Network Element Driver: Communicates External database: Plugging in external

with a device within a product family. databases so it becomes accessible to operators
Uses: NEDAPI and applications through MAAPI, i.e. an integral
part of the Cisco NSO system. Uses: DPAPI
Subscriber: Reacts to configuration
changes. Uses: CDBAPI. Validator: Called during commit sequence to
check validity of (some part/aspect of) the
Data Provider: Provides current value of configuration. Uses: MAAPI
some status/information. Uses: DPAPI
(read-only parts)

2-148 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Common Applications Roles (Cont.)
Set hook: Application that triggers when Event Receiver: Application that receives
particular leaves are modified; may update the events, e.g. SNMP Traps, and creates alarms or
transaction. Use with extreme caution, it easily takes other actions. Uses: ALARM API,
ruins the transactional integrity. Uses: MAAPI SYSTEM API

Transaction hook: Application that Transform: Application that translates

modifies the contents of a transaction. Use with bi-directionally between two data models,
extreme caution, it easily ruins the transactional typically for different management interface
integrity. Uses: MAAPI standards. Uses: DPAPI + MAAPI

Data feeder: An application that is Policy, Command and Post-commit

repeatedly storing operational data, e.g. script: Scripts to enforce policies or perform
performance readings, into a database table. additional actions at commit time or when
Uses: CDBAPI. specific commands are executed. Uses: MAAPI

Common Applications Roles (Cont.)
Discovery Application: Discovers hosts, Authorization callback: Application that
links, topology, or something else, and authorizes individual commands or data access
populates result in Cisco NSO. Uses: MAAPI in the system. Uses: SYSTEM API

Scheduler: Runs some application or action Completion plugin: Application that alters
at regular or configured times. Uses: MAAPI the standard TAB-completion behavior in the
Command Line Interfaces (CLIs).
Management agent: For example, custom Uses: SYSTEM API
WebUI, MTOSI or SOAP interface, self-service
portal, integration with northbound workflow User Type plugin: Application
engine. Uses: MAAPI implementing an additional base type that can
be used in the YANG models. Uses: SYSTEM
Authentication plugin: Calls out to an API
external RADIUS, TACACS, LDAP, etc. server
to authenticate users. Uses: AAAAPI

2-150 © 2016 Cisco Systems, Inc. Advanced Cisco Network Services Orchestrator (ADVNSO) v4.2
Common Applications Roles (Cont.)
Upgrade client: Application that participates Inter-process communications
in a software upgrade campaign to update the plugin: Application to replace the default IPC
data stored in CDB beyond the automatic mechanism (TCP sockets) used between Cisco
conversion. Uses: CDBAPI NSO and applications. Useful if clients need to
use, for example, UNIX-domain sockets or
Message formatters: Application TIPC. Uses: SYSTEM API
reformatting or translating operator messages,
e.g. error messages. Uses: SYSTEM API Wizard: Application that lets operator fill in a
few values, then computes reasonable defaults
for the rest. Uses: MAAPI

Summary
This topic summarizes the key points that were discussed in this lesson.
 Reactive FASTMAP is one of the key components when designing Cloud VPN. It is used whenever a
VM needs to be instantiated to accommodate a new Virtual Network Function (VNF).
 Resource allocation can be done using Resource Allocation Services.
 VNF management performed by Cisco Elastic Services Controller, through VM Manager services.
 Cloud VPN can accommodate several network topologies and service combinations, all of which can be
provisioned end to end.
 Stacked services can be used to modularize the services into reusable building blocks.
 Stacked services can be implemented by referencing service YANG models through the use NAVU API.
 Low-level services act as black boxes to high-lever services and only expose their YANG interface.
 Templates API can be used to combine Java-based mappings with XML mapping templates.
 There are several types of applications within the Cisco NSO ecosystem and they all use Cisco NSO-
provided APIs.

NSO20 StudentGuide PDF
100% (1)
NSO20 StudentGuide PDF
476 pages
Disabled Toilet Alarm Setup Guide
100% (1)
Disabled Toilet Alarm Setup Guide
3 pages
Nso Lsa-6.0
No ratings yet
Nso Lsa-6.0
36 pages
B ACI Fundamentals
No ratings yet
B ACI Fundamentals
164 pages
Nso Development-5.3 PDF
0% (1)
Nso Development-5.3 PDF
382 pages
Nickel Ore Pre-Shipment Analysis
No ratings yet
Nickel Ore Pre-Shipment Analysis
1 page
Artificial Intelligence Questions
No ratings yet
Artificial Intelligence Questions
15 pages
Cranes&Hoists For Mining Industry
No ratings yet
Cranes&Hoists For Mining Industry
2 pages
51 Cutover Templates
100% (2)
51 Cutover Templates
13 pages
The Impact of Cloud Computing On Organisational Ag
No ratings yet
The Impact of Cloud Computing On Organisational Ag
18 pages
NFV - Nso - Esc - Virtual - Services - v1 - IMP
No ratings yet
NFV - Nso - Esc - Virtual - Services - v1 - IMP
25 pages
Nsobasic 4.2 LG PDF
No ratings yet
Nsobasic 4.2 LG PDF
80 pages
Cisco - Update On Server Load Balancing-Cisco Systems (1998)
No ratings yet
Cisco - Update On Server Load Balancing-Cisco Systems (1998)
15 pages
White Paper c11 734298
No ratings yet
White Paper c11 734298
105 pages
Datasheet c78 734576
No ratings yet
Datasheet c78 734576
7 pages
NSO 5.3 Getting Started Guide: Americas Headquarters
No ratings yet
NSO 5.3 Getting Started Guide: Americas Headquarters
76 pages
Nso Northbound-5.2.3.8
No ratings yet
Nso Northbound-5.2.3.8
106 pages
Cisco Nso
100% (1)
Cisco Nso
15 pages
DC Design Guidelines
No ratings yet
DC Design Guidelines
180 pages
Word Processing in Indian Offices
No ratings yet
Word Processing in Indian Offices
86 pages
Pony Preservation Project - Voice - A Guide
No ratings yet
Pony Preservation Project - Voice - A Guide
23 pages
Lesson Plan-Communication Systems
No ratings yet
Lesson Plan-Communication Systems
8 pages
Datasheet c78 734669
No ratings yet
Datasheet c78 734669
7 pages
NSO Essentials For Programmers and Network Architects (NSO201) v3.0
No ratings yet
NSO Essentials For Programmers and Network Architects (NSO201) v3.0
5 pages
ACI Service Graph Design PDF
No ratings yet
ACI Service Graph Design PDF
101 pages
MCQ Ec-405
No ratings yet
MCQ Ec-405
2 pages
Amor de Siempre (Audiotree Live Version) : Download Print
No ratings yet
Amor de Siempre (Audiotree Live Version) : Download Print
1 page
Python Lab
No ratings yet
Python Lab
21 pages
VDS Ou DVS - Resumo
No ratings yet
VDS Ou DVS - Resumo
32 pages
Learning@Cisco NSO Advanced For Python Programmers: Duration
No ratings yet
Learning@Cisco NSO Advanced For Python Programmers: Duration
4 pages
LCD TV/DVD: Service Manual Circuit Diagrams
No ratings yet
LCD TV/DVD: Service Manual Circuit Diagrams
31 pages
A Must Sap Abap Tutorials Document For Beginners
50% (2)
A Must Sap Abap Tutorials Document For Beginners
508 pages
Cisco Data Center Design Guide
100% (2)
Cisco Data Center Design Guide
180 pages
NSO Layered Service Architecture: Americas Headquarters
No ratings yet
NSO Layered Service Architecture: Americas Headquarters
34 pages
Cisco Network Services Orchestrator (NSO)
No ratings yet
Cisco Network Services Orchestrator (NSO)
7 pages
Cisco Update On Server Load Balancing
No ratings yet
Cisco Update On Server Load Balancing
15 pages
Lesson 3 Transportation Problem
No ratings yet
Lesson 3 Transportation Problem
41 pages
Datasheet NSO
No ratings yet
Datasheet NSO
7 pages
Cisco UCS Data Center Growth & Features
No ratings yet
Cisco UCS Data Center Growth & Features
49 pages
Exploring English Learners Experiences of Using M
No ratings yet
Exploring English Learners Experiences of Using M
15 pages
Cisco Data Center Infrastructure 2.5 Design Guide
No ratings yet
Cisco Data Center Infrastructure 2.5 Design Guide
180 pages
DSP LAB Manual - ECE - KNCET
No ratings yet
DSP LAB Manual - ECE - KNCET
60 pages
Contact ID Codes
No ratings yet
Contact ID Codes
6 pages
Cisco - Nso Solution Overview
No ratings yet
Cisco - Nso Solution Overview
6 pages
Virtualized Multiservice Data Center (VMDC) Virtual Services Architecture (VSA) 1.0 Design Guide
No ratings yet
Virtualized Multiservice Data Center (VMDC) Virtual Services Architecture (VSA) 1.0 Design Guide
64 pages
Erp Briefing
No ratings yet
Erp Briefing
4 pages
NFV Solution
No ratings yet
NFV Solution
9 pages
B l2vpn CG 73x ncs540
No ratings yet
B l2vpn CG 73x ncs540
430 pages
Nso 5
No ratings yet
Nso 5
79 pages
BRKRST 2558
No ratings yet
BRKRST 2558
98 pages
Audison Thesis Car Audio
100% (3)
Audison Thesis Car Audio
5 pages
Federated Anomaly Detection Insights
No ratings yet
Federated Anomaly Detection Insights
21 pages
Vsphere Distributed Switch Best Practices
No ratings yet
Vsphere Distributed Switch Best Practices
30 pages
Maintenance Manual mb491 PDF
No ratings yet
Maintenance Manual mb491 PDF
298 pages
LTRSDN 2713
No ratings yet
LTRSDN 2713
41 pages
Bobobaba
No ratings yet
Bobobaba
67 pages
Deployment Case Study of SDN and NFV Transformation
No ratings yet
Deployment Case Study of SDN and NFV Transformation
25 pages
Cisco Network Services Orchestrator: Lab Guide
No ratings yet
Cisco Network Services Orchestrator: Lab Guide
76 pages
Using Elastic Services Controller With NSO: Figure 1. The ETSI NFV Architecture
No ratings yet
Using Elastic Services Controller With NSO: Figure 1. The ETSI NFV Architecture
9 pages
Cisco Network Design Exam Guide
No ratings yet
Cisco Network Design Exam Guide
4 pages
NIC Scientist Job Application
No ratings yet
NIC Scientist Job Application
5 pages
Data Center High Availability Clusters Design Guide PDF
No ratings yet
Data Center High Availability Clusters Design Guide PDF
222 pages
NSO Layered Service Architecture: Americas Headquarters
No ratings yet
NSO Layered Service Architecture: Americas Headquarters
26 pages
Cisco Network Service Orchestrator: Enabled by Tail-F Technology
No ratings yet
Cisco Network Service Orchestrator: Enabled by Tail-F Technology
19 pages
Encrypted Text Analysis
No ratings yet
Encrypted Text Analysis
77 pages
Tecnms 4175 PDF
No ratings yet
Tecnms 4175 PDF
205 pages
3842 PDF
No ratings yet
3842 PDF
8 pages
Create All Time Zone Tables in HANA Schema SYSTEM
No ratings yet
Create All Time Zone Tables in HANA Schema SYSTEM
4 pages
Networking A To Z For VMware
No ratings yet
Networking A To Z For VMware
314 pages
Overview History R
No ratings yet
Overview History R
15 pages
FAX236S Brochure 2
No ratings yet
FAX236S Brochure 2
1 page
Virtualized Multiservice Data Center (VMDC) Data Center Interconnect (DCI) 1.0 Design Guide
No ratings yet
Virtualized Multiservice Data Center (VMDC) Data Center Interconnect (DCI) 1.0 Design Guide
78 pages
V8: Net-Ing A Greener Data Center
No ratings yet
V8: Net-Ing A Greener Data Center
24 pages
B ACI-Fundamentals PDF
No ratings yet
B ACI-Fundamentals PDF
290 pages
Cisco Virtualized Multiservice Data Center 2.3
No ratings yet
Cisco Virtualized Multiservice Data Center 2.3
82 pages
Philips Pet716 Service Manual
No ratings yet
Philips Pet716 Service Manual
31 pages
BRKSDN 2063
No ratings yet
BRKSDN 2063
68 pages
Data Center Aggregation Layer Design and Configuration With Cisco Nexus Switches and Virtual Portchannels
No ratings yet
Data Center Aggregation Layer Design and Configuration With Cisco Nexus Switches and Virtual Portchannels
32 pages
Cisco Press - IP Quality of Service - Vegesna (2001)
No ratings yet
Cisco Press - IP Quality of Service - Vegesna (2001)
232 pages
Cisco CSR in Aws Whitepaper
No ratings yet
Cisco CSR in Aws Whitepaper
21 pages
Disaster Recovery As A Service (Draas) 2.0 Design Guide: Building Architectures To Solve Business Problems
No ratings yet
Disaster Recovery As A Service (Draas) 2.0 Design Guide: Building Architectures To Solve Business Problems
68 pages
Cisco 6500-Virtual Switch Sysetm-S6367 - Vss - Tech - Talk - Final
No ratings yet
Cisco 6500-Virtual Switch Sysetm-S6367 - Vss - Tech - Talk - Final
31 pages
Introduction To Computing Using Python An Application Development Focus 2nd Edition Perkovic Test Bank PDF Download
No ratings yet
Introduction To Computing Using Python An Application Development Focus 2nd Edition Perkovic Test Bank PDF Download
401 pages

ADVNSO - v4.2 Student Guide

Uploaded by

ADVNSO - v4.2 Student Guide

Uploaded by

ADVNSO

Advanced Cisco Network

Cloud VPN Service Design 2-1

Service Provider VPN Service

NSO Application Framework

Tasks of the Service Application

Mapping Logic: Turn the knobs on devices to

 Service providers – reduce costs (OPEX), more agility

Custom code only:

 Template  Most expressive power, but also requires

Custom code instantiating template:

cisco@NCS:~/ncs-run/packages/$ ncs-make-package --python-skeleton snakey

Python Low-Level APIs

application -- module for implementing packages and services

Open a new MAAPI

 Read / write data and execute actions

with ncs.maapi.single_write_trans('admin', 'python') as t: Open a new MAAPI

Use root’s properties to

with ncs.maapi.single_write_trans('admin', 'python') as t:

list_entry = root.some_list['k1', 'k2']

root.devices.device['c0'].state.admin_state # Enum object

root.services.loopback['test'].device = 'c0' # Use leafref’s target data type, e.g. string

print('Committing the device configuration...')

Delete implemented with __delattr__() magic method on Node class

del root.devices.device['ce0'] # List element

del root.devices.device['ce0'].name # Leaf

del root.devices.device['ce0'].device_type.cli # Presence container

del var_cli_value # Removes var_cli_value variable but root.devices.device['ce0'].device_type.cli stays as-is

# Assign specified PW id to a variable

# Set up variables to be exported

# Apply configuration in XML file, making use of exported variables

# Tell NSO to run above cb_create() code for our service

Note: Service code can also be a Python module

Create the Loopback Service Package

[user@nso ~]$ ncs-make-package –help

Parameter name Type Default value Mandatory

K name R device interface-id ip-address network-mask

# service maagic node defines the root for XPath expressions

4. Apply the template.

2. In the second two statements, we create an instance of theTemplateVariables class.

[user@nso example]$ pylint --disable=R,C --reports=n packages/loopback/python/loopback.py

[user@nso example]$ ncs_cli -u admin

As a final step, we will test the service application.

Finally, we can create a test service instance using the CLI.

 Typically services use NAVU when called by FASTMAP

YANG model(s) Java Code

When referencing nodes in the data tree, we have two options:

 String names: Wrong Wrong

BUILD SUCCESSFUL Not detected by compiler.

Total time: 1 second

Total time: 1 second

// Create container with Maapi session

// Create container with CDB session

// Finally create container that is the schema root

Create the Loopback Service Package

 Prepare the Eclipse project (optional).

[user@nso ~]$ ncs-make-package –help

Parameter name Type Default value Mandatory

K name R device interface-id ip-address network-mask

Template myTemplate = new Template(context, "loopback");

As a final step, we will test the service application.

Finally, we can create a test service instance using the CLI.

Java MAAPI Changes

NavuContainer cdbRoot = new NavuContainer(operCtx).container(Ncs.hash);

// /services/l2vpn{first}/pw-id is an operational (persistent) leaf Set operational leaf

Layer 3 MPLS VPN Service

Customer Site A PE Devices Customer Site C

P device: The device in the provider network with no

 CE routers route traffic to PE routers.

Sample Layer 3 MPLS VPN Service Overview

Characteristics of Layer 3 MPLS VPNs:

Customer Service instance

Customer Most NSO deployments require integration

Customer Service instance

Cisco NSO plays two major roles:

callback Java application

Delete implemented with delattr() magic method on Node class