Ansible as VNF Manager for Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR

Hello my friend,

Recently I have restarted activities with Ansible (link) in order to automate some routine tasks and learn something new. In today’s article we’ll speak about NFV (network function virtualization) and how Ansible can solve certain tasks.

1
2
3
4
5

No part of this blogpost could be reproduced, stored in a
retrieval system, or transmitted in any form or by any
means, electronic, mechanical or photocopying, recording,
or otherwise, for commercial purposes without the
prior permission of the author.

Disclaimer

Initially I have written this article solely for Nokia (Alcatel-Lucent) VSR and only recently I have finalized Cisco IOS XRv part. So it might be some caveats in text, if I have missed something during update.

Brief description

One of the trends defined some ago (SDN, NFV, etc) somehow starts affecting networks finally. You remember, we have discussed a bit this concept earlier (link). But for now our main focus is on infrastructure for virtualization (NFVi).NFV and in general virtualization of the devices and network functions are defined by certain standards and has well defined architecture with all interfaces (API) described. This architecture is called MANO, what stands for Management and Orchestration, and is developed and supported by ETSI (European Telecommunications Standards Institute). It looks like as follows:

As you see, besides VNF-M there are two more components in MANO architecture. Let’s very briefly discuss them:

NFV-O (Orchestrator) is the component that manages E2E all aspects of NFV
VNF-M is responsible for lifecycle of VNF: from creating/launching till decommissioning
VIM (Virtual Infrastructure Manager) managed particular components (i.e. servers, network elements) and translates high-level VNF-M and NFV-O requests to particular commands. Examples are OpenStack, VMWare vCloud Director or even just KVM.

I don’t pretend to be 100%, because the topic is quite new for me. You can find more detailed info at sdxcentral.

I have marked up VNF (Virtual Network Function) Manager (shortly VNF-M), because it’s topic of current article.

Some more words in this introduction part, I have found at Cisco website description, what their VNF-M does:

Well, here is written Cisco, though all the vendors (Nokia as well) have their own VNF-M. Definitely not all the components I have realized in the Ansible-playbooks (yet at least), but some of them yes, and that is what we do now.

What we are going to test?

The following action items I have for you:

Onboard and deploy VNF
Undeploy VNF

Both of these actions are Ansible-playbooks, so they can be easily modified as well as source files.

The success criteria for the lab is that VNF is booted and basic provisioning (day 0) is done on it, so that it’s reachable from our management host and is ready to be provisioned further using normal modules, like vendor specific (link) or NETCONF/YANG (link).

Software version

The following components are used for the current lab:

CentOS 7 with python 2.7.
Ansible 2.4.2
Nokia (Alcatel-Lucent) SR OS 15.0.R7
Cisco IOS XRv

See the previous article to get details how to build the lab (link)

Topology

There is no particular topology, as I just using my management Linux host and then one Nokia (Alcatel-Lucent) VSR. So let’s assume we have the default topology:

For the reason mentioned behind, we don’t have any logical topology and even starting configuration files, as nothing exists besides:

For Nokia (Alcatel-Lucent): VSR image (qcow2 file) and license for it.
For Cisco: VMDK image (https://upload.cisco.com/cgi-bin/swc/fileexg/main.cgi?CONTYPES=Cisco-IOS-XRv)

But I strongly recommend to review the detailed lab setup to make sure we have the same starting position (link).

VNF-M: Onboarding and deploying

So, before we start speaking about particular Ansible playbooks, we need to understand what exactly we are doing. Here we go:

We need to create XML template, which will be used to create particular VM
We need to define parameters of our particular VM
We need to compose Ansible playbook that will:
1. Create VM based on template (1) and parameters (2)
2. Launch it
3. Update corresponding hosts tables (for Ansible and Linux)

VNF-M for Nokia (Alcatel-Lucent) VSR

AP1: XML template

Template means that we can use the same file many times without any modifications, right? To achieve this goal, we clearly need to replace some fields with variables, which later will be read from VNF definition file. You remember, we are using specific Jinja2 mark-up language for variable in Ansible (link), so I have just taken XML scheme shown recently and put variables in Jinja2 format:

Pay attention, I have created template for Nokia (Alcatel-Lucent) SR OS 15. For SR OS 14 it must be updated.

1	$ cat template-nokia-sros-15.0R7.xml

1	<code lang="xml">

1	<code lang="xml">

{{ VM1.nfvo.vnfd.vdu.memory_b }}
4194304

1	<code lang="xml">

SandyBridge
Intel

1	<code lang="xml">

1	<code lang="xml">

hvm

1	<code lang="xml">

TIMOS:address={{ VM1.nfvo.vnfd.vdu.interface0.address }}/{{ VM1.nfvo.vnfd.vdu.interface0.netmask }}@active license-file=ftp://{{ VM1.nfvo.vnfd.vdu.license.username }}:{{ VM1.nfvo.vnfd.vdu.license.password }}@{{ VM1.nfvo.vnfd.vdu.license.path }}/{{ VM1.nfvo.vnfd.vdu.license.file }} slot={{ VM1.nfvo.vnfd.vdu.chassis.slot.type }} chassis={{ VM1.nfvo.vnfd.vdu.chassis.type }} card={{ VM1.nfvo.vnfd.vdu.chassis.slot.card.type }} mda/1={{ VM1.nfvo.vnfd.vdu.chassis.slot.card.mda1.type }} mda/2={{ VM1.nfvo.vnfd.vdu.chassis.slot.card.mda2.type }}

1	<code lang="xml">

/usr/libexec/qemu-kvm

The first important point, is the path to this template. It lays in specific folder within my home directory “~/temp/”. It must be later on included into file with variables.

The next point is variables names, like “{{ VM1.nfvo.vnfd.hostname }}”. If you have read my previous articles about Ansible (like NETCONF/YANG with Ansible (link)), you understand that these names are just coming from variables list.

In reality, AP1 and AP2 are being done together. Because here you need to know the variable names, whereas in parameters you need to know what you need to define.

Also you see that some data is static. I haven’t changed them with variables, because I don’t know if it makes sense for me in my lab. If you think it makes, fill free to update as necessary.

If you are good programmer or know Anisble good, the next step might cause toothache for you. I’m not, so I’m OK with it.

Ansible by default doesn’t work with XML files and it uses YAML instead. But in the description of the module to manage KVM (called virt), we need to define XML. I tried to use provided “lookup” example”, but I haven’t succeeded. So I have converted XML to YAML in quite straightforward way (might be not the best one):

1
2
3
4

$ cat template-nokia-sros-15.0R7.yml
---
schema: {{ VM1.nfvo.vnfd.hostname }}{{ VM1.nfvo.vnfd.vdu.memory_b }}4194304SandyBridgeIntel{{ VM1.nfvo.vnfd.vdu.vcpus }}hvmTIMOS:address={{ VM1.nfvo.vnfd.vdu.interface0.address }}/{{ VM1.nfvo.vnfd.vdu.interface0.netmask }}@active license-file=ftp://{{ VM1.nfvo.vnfd.vdu.license.username }}:{{ VM1.nfvo.vnfd.vdu.license.password }}@{{ VM1.nfvo.vnfd.vdu.license.path }}/{{ VM1.nfvo.vnfd.vdu.license.file }} slot={{ VM1.nfvo.vnfd.vdu.chassis.slot.type }} chassis={{ VM1.nfvo.vnfd.vdu.chassis.type }} card={{ VM1.nfvo.vnfd.vdu.chassis.slot.card.type }} mda/1={{ VM1.nfvo.vnfd.vdu.chassis.slot.card.mda1.type }} mda/2={{ VM1.nfvo.vnfd.vdu.chassis.slot.card.mda2.type }}/usr/libexec/qemu-kvm
...

The idea is very simple: all this text is considered as single value for variable “schema”, which I will call later on from another Ansible playbook. Again. It’s just one string, though very long.

If you have better ideas, which you have tested and works for you, let me know.

AP2: VNF parameters

This point is easier than the previous one, because we have many times created files with variables (link), which were later imported in Ansible playbooks:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

$ cat input/new_vnf_nokia.yml
---
nfvo:
vnfd:
hostname: VSR7
vendor: nokia
os: sros
version: 15.0R7
vdu:
vcpus: 4
memory_b: 4194304
disk_size_gb: 1
image_name: VSR7-nokia-sros-15.0R7.qcow2
image_path:
source: ~/temp
destination: /var/lib/libvirt/images
bootup_time: 180
license:
file: sros15.lic
path: 192.168.1.1
username: nokia
password: nokianokia
chassis:
type: VSR-I
slot:
id: 0
type: A
card:
id: 0
type: cpm-v
mda1:
id: 1
type: m20-v
mda2:
id: 2
type: isa-tunnel-v
interface0:
id: 0
physical_interface: vnet0
network_name: Management
connection_point: br0
mac: 00:A1:00:15:07:00
address: 192.168.1.107
netmask: 24
vnic_type: virtio
interface1:
id: 0
physical_interface: vnet1
network_name: Data1
connection_point: br1
mac: 00:A1:00:15:07:01
vnic_type: virtio
interface2:
id: 0
physical_interface: vnet2
network_name: Data2
connection_point: br2
mac: 00:A1:00:15:07:02
vnic_type: virtio
console:
address: 0.0.0.0
port: 2517
protocol: telnet
...

First of all, pay attention that this file is located in separated folder called “input”. My idea is to use it as input folder for new VNFs (probably something else in future). In the same folder the VNF description file for Cisco is located

Technically you can structure it as you like. I tried to follow ETSI standard, chapter 6.. Though, I believe, some names I have changed or added, so it must be reviewed once more. I’d appreciate if you give me feedback on that. Also, point out that variable “{{ nfvo,vnfd.vdu.image_path.source }}” contains path to folder, where template done so far and VSR image are located, whereas “{{ nfvo,vnfd.vdu.image_path.destination }}” points to folder, where all VM images for KVM are stored. Just for the reference:

1
2
3
4
5
6
7
8

$ ls -l ~/temp/
total 1181776
-rwxrw-rw-. 1 aaa aaa 961740800 Feb 17 18:21 default-image-cisco-iosxr-6.1.2.qcow2
-rwxrw-rw-. 1 aaa aaa 248381440 Jan 11 02:51 default-image-nokia-sros-15.0R7.qcow2
-rwxrw-rw-. 1 aaa aaa 2949 Feb 17 14:31 template-cisco-iosxr-6.1.2.xml
-rwxrw-rw-. 1 aaa aaa 2585 Feb 17 14:40 template-cisco-iosxr-6.1.2.yml
-rwxrw-rw-. 1 aaa root 2640 Feb 17 14:33 template-nokia-sros-15.0R7.xml
-rwxrw-r--. 1 aaa aaa 2348 Feb 17 14:37 template-nokia-sros-15.0R7.yml

Make sure you put these files in this library or change the path!

If you are cautiously read the file above, you spotted that variables are named “{{ nfvo.vnfd.vdu.image_path }}” instead of “{{ VM1.nfvo.vnfd.vdu.image_path }}”. The prefix “VM1” is added later in main playbook.

AP3: Ansible playbook for onboarding and deploying

Now we have reached the point, when we create the playbook that brings all these pieces together. Pay attention that for now we had a “hard-coded” path to VNF descriptor in the playbook, but I’ll fix it later to:

1
2
3
4
5

$ cat transformer_on.yml
---
- hosts: linux
gather_facts: no
connection: local

1	<code lang="yaml">

vars_files:
– login/linux_host.yml

1	<code lang="yaml">

tasks:
– name: READING VNF DATA
include_vars:
file: input/new_vnf_nokia.yml
name: VM1

1	<code lang="yaml">

– name: READING VNF STRUCTURE
include_vars:
file: “{{ VM1.nfvo.vnfd.vdu.image_path.source }}/template-{{ VM1.nfvo.vnfd.vendor }}-{{ VM1.nfvo.vnfd.os }}-{{ VM1.nfvo.vnfd.version }}.yml”
name: VM1_KVM

1	<code lang="yaml">

– name: COPYING VM IMAGE TO PROPER DIRECTORY
copy:
src: “{{ VM1.nfvo.vnfd.vdu.image_path.source }}/default-image-{{ VM1.nfvo.vnfd.vendor }}-{{ VM1.nfvo.vnfd.os }}-{{ VM1.nfvo.vnfd.version }}.qcow2”
dest: “{{ VM1.nfvo.vnfd.vdu.image_path.destination }}/{{ VM1.nfvo.vnfd.vdu.image_name }}”
become: yes

1	<code lang="yaml">

– name: DEFINE VM IN KVM
virt:
name: “{{ VM1.nfvo.vnfd.hostname }}”
command: define
xml: “{{ VM1_KVM.schema }}”
become: yes

1	<code lang="yaml">

– name: LAUNCHING {{ VM1.nfvo.vnfd.hostname }} ON KVM
virt:
name: “{{ VM1.nfvo.vnfd.hostname }}”
state: running
become: yes

1	<code lang="yaml">

– name: UPDATING ANSIBLE HOSTS FOR {{ VM1.nfvo.vnfd.hostname }}
lineinfile:
path: /etc/ansible/hosts
regexp: ‘{{ VM1.nfvo.vnfd.hostname }}’
line: ‘{{ VM1.nfvo.vnfd.hostname }}’
insertafter: ‘^\[{{ VM1.nfvo.vnfd.vendor }}\]’
become: yes

1	<code lang="yaml">

– name: UPDATING LINUX HOSTS FOR {{ VM1.nfvo.vnfd.hostname }}
lineinfile:
path: /etc/hosts
regexp: ‘{{ VM1.nfvo.vnfd.vdu.interface0.address }}’
line: ‘{{ VM1.nfvo.vnfd.vdu.interface0.address }} {{ VM1.nfvo.vnfd.hostname }}’
become: yes

1	<code lang="yaml">

– name: WAITING FOR {{ VM1.nfvo.vnfd.hostname }} TO BOOT
pause:
seconds: “{{ VM1.nfvo.vnfd.vdu.bootup_time }}”

1	<code lang="yaml">

– name: ONLY FOR {{ VM1.nfvo.vnfd.vendor }} // MAKING ROUTER REACHABLE ON CLI
command: helpers/magic_wand.py
when:
– VM1.nfvo.vnfd.vendor == “cisco”
– VM1.nfvo.vnfd.os == “iosxr”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

- name: ONLY FOR {{ VM1.nfvo.vnfd.vendor }} // CONFIGURING OOB INTERFACE
telnet:
host: "{{ VM1.nfvo.vnfd.vdu.console.address }}"
port: 3517
user: cisco
password: cisco
pause: 1
login_prompt: "Username: "
prompts:
- "[>|#]"
command:
- configure terminal
- ssh server v2
- ssh server vrf MGMT
- ssh server netconf vrf default
- netconf-yang agent
- ssh
- vrf MGMT
- address-family ipv4 unicast
- interface MgmtEth0/0/CPU0/0
- ipv4 address {{ VM1.nfvo.vnfd.vdu.interface0.address }}/{{ VM1.nfvo.vnfd.vdu.interface0.netmask }}
- no shutdown
- vrf MGMT
- control-plane
- management-plane
- out-of-band
- vrf MGMT
- interface MgmtEth0/0/CPU0/0
- allow SSH
- allow NETCONF
- commit
- clear
- exit
when:
- VM1.nfvo.vnfd.vendor == "cisco"
- VM1.nfvo.vnfd.os == "iosxr"
...

The last two tasks are related to Cisco IOS XRv deployment, so I will describe later, in Cisco part.

So, initially we read VNF structure data into variable called “VM1”, that is where it comes from. We can omit it, but in case we add later on several VMs simultaneously, I decided to add this info.

Then we read VNF schema, what we have created in the first point, and add name “VM1_KVM” there. As you see, the template is also called partially using variables. In vnf.yml we has variable “{{ nfvo.vnfd.version }}” with value “15.0R7”. The logic behind is that we will have separate template for version 14.*, so proper matching between template and variables are expected (mainly for chassis, line cards and modules).

In the third task we copy VM image from the central repository to “/var/lib/libvirt/image/”, where all VMs are located. Pay attention that the path is the same as it was for XML template. Also we copy “default-image-nokia-sros-15.0R7.qcow2 ” by using the same variable in the previous point.

The forth task is the onboarding actually. We define VM inside KVM using template, which calls variables from VNF data file.

Then we just launch the VM we have defined in the previous task. It’s deployment phase.

Tasks 6 and 7 are about modifying the Ansbile and Linux hosts file by adding appropriate entries: VM name to the vendor-group and hostname with IP correspondingly.

The last task is just to wait 3 minutes and do nothing. This timeframe of “3 minutes” is configurable per VNF (i.e. it takes more time for Cisco IOS XRv to boot and load config than for Nokia (Alcatel-Lucent) VSR). This delay allows Nokia (Alcatel-Lucent) VSR to boot and be ready for further configuration

So, before we launch our play, let’s check state of VMs and data in hosts files:

GeSHi Error: GeSHi could not find the language quotbash (using path /var/www/vhosts/karneliuk.com/httpdocs/wp-content/plugins/codecolorer/lib/geshi/) (code 2)

As you see, our new VM, which is called VSR7 by the way, isn’t mentioned anywhere, as we haven’t defined it yet. So, let’s play!