Вы находитесь на странице: 1из 697

Creating

HPE Software-defined Networks eBook


(Exam HPE2-Z38)
Hpepress.hpe.com

Creating HPE Software-defined Networks


(Exam HPE2-Z38)
2015 Hewlett Packard Enterprise Development LP
Published by:
Hewlett Packard Enterprise Press
660 4th Street, #802
San Francisco, CA 94107
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or by any information storage and retrieval
system, without written permission from the publisher, except for the inclusion of brief quotations in a
review.
ISBN: 978-1-942741-22-0
WARNING AND DISCLAIMER
This book provides information about the topics covered in the covered in the Creating HP Softwaredefined Networks eBook (Exam HPE2-Z38) certification exam. Every effort has been made to make this
book as complete and as accurate as possible, but no warranty or fitness is implied.
The information is provided on an as is basis. The author, and Hewlett Packard Enterprise Press, shall
have neither liability nor responsibility to any person or entity with respect to any loss or damages arising
from the information contained in this book or from the use of the discs or programs that may accompany
it.
The opinions expressed in this book belong to the author and are not necessarily those of Hewlett Packard
Enterprise Press.
Note: Books and courses developed prior to the Hewlett-Packard Company separation contain branding,
logos, web page links, and other elements/information that has not been updated for each HP Inc. and
Hewlett Packard Enterprise. The general knowledge and skills are still considered of value to HP Inc.
and Hewlett Packard Enterprise employees (partners/customers) respectively, so these legacy materials
are being made available here. Plans are in place for updating the most highly-used content for each HP
Inc. and Hewlett Packard Enterprise.
TRADEMARK ACKNOWLEDGEMENTS
All third-party trademarks contained herein are the property of their respective owner(s).
GOVERNMENT AND EDUCATION SALES
This publisher offers discounts on this book when ordered in quantity for bulk purchases, which may
include electronic versions. For more information, please contact U.S. Government and Education Sales
1-855-447-2665 or email sales@hpepressbooks.com.

Feedback Information
At HPE Press, our goal is to create in-depth reference books of the best quality and value. Each book is
crafted with care and precision, undergoing rigorous development that involves the expertise of members
from the professional technical community.

Readers feedback is a continuation of the process. If you have any comments regarding how
we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact
us through email at hpepress@epac.com. Please make sure to include the book title and ISBN in your
message.
We appreciate your feedback.
Publisher: Hewlett Packard Enterprise Press
HPE Contributors: Wim Groeneveld, Gerhard Roets, Antonio Mingrone, Peter Kilgour
HPE Press Program Manager: Michael Bishop

Introduction
This study guide helps you prepare for the Creating HPE Software-defined Networks exam (HPE2-Z38).
The exam is for candidates who want to acquire the HPE ASE - FlexNetwork Architect V2 or the HPE
ASE - FlexNetwork Integrator V1 certifications. In addition, this study guide helps you prepare for the
SDN-related portion of the Master ASE FlexNetwork Solutions V2 certification exam (HPE0-Y53).
The book explains how to architect and implement HPE Software-defined Networks. Topics include
OpenFlow, Software-defined Network (SDN) use cases, installing and configuring the SDN controller,
and designing SDN solutions with HPE applications such as the HPE Network Protector SDN
Application.

Certification and Learning


Hewlett Packard Enterprise Partner Ready Certification and Learning provides end-to-end continuous
learning programs and professional certifications that can help you open doors and succeed in the New
Style of Business. We provide continuous learning activities and job-role based learning plans to help
you keep pace with the demands of the dynamic, fast paced IT industry; professional sales and technical
training and certifications to give you the critical skills needed to design, manage and implement the most
sought-after IT disciplines; and training to help you navigate and seize opportunities within the top IT
transformation areas that enable business advantage today.
As a Partner Ready Certification and Learning certified member, your skills, knowledge, and real-world
experience are recognized and valued in the marketplace. To continue your professional and career
growth, you have access to our large HPE community of world-class IT professionals, trend-makers and
decision-makers. Share ideas, best practices, business insights, and challenges as you gain professional
connections globally.
To learn more about HPE Partner Ready Certification and Learning certifications and continuous learning
programs, please visit
http://certification-learning.hpe.com

Audience
This study guide is designed for networking and IT professionals who want to build on their experience
implementing networking protocols and learn how to design HPE SDN solutions based on customer
needs. It helps qualified candidates prepare to take the HPE2-Z38 exam, which tests their ability to
architect and implement SDN solutions.

Assumed Knowledge
The certification exam is designed for candidates with (on the job) experience. The associated training
course, which includes numerous design and hands-on lab activities, provides a foundation, but you are
expected to have experience in the real world as well.

Relevant Certifications

After you pass these exams, your achievement may be applicable toward more than one certification. To
determine which certifications can be credited with this achievement, log in to The Learning Center and
view the certifications listed on the exams More Details tab. You might be on your way to achieving
additional HPE certifications.

Preparing for Exam HPE2-Z38


This self-study guide does not guarantee that you will have all the knowledge you need to pass the exam.
It is expected that you will also draw on real-world experience and would benefit from completing the
hands-on lab activities provided in the instructor-led training.

Recommended HPE Training


Recommended training to prepare for each exam is accessible from the exams page in The Learning
Center. See the exam attachment, (Supporting courses,) to view and register for the courses.

Obtain Hands-on Experience


You are not required to take the recommended supported courses and completion of training does not
guarantee that you will pass the exams. HPE strongly recommends a combination of training, thorough
review of courseware and additional study references, and sufficient on-the-job experience prior to
taking an exam.

Exam Registration
To register for an exam, go to http://certification-learning.hpe.com/tr/learn_more_about_exams.html

Study Guide Introduction


Study Guide Overview
This guide helps you prepare for taking the Creating HP Software-defined Networks (HPE2-Z38) exam.
The guide introduces you to:
HP VAN SDN Controller
OpenFlow
HP SDN Applications
Through a combination of descriptive and instructional content, you will learn how to install and
configure the HP SDN VAN Controller and HP SDN Applications. Furthermore, you will obtain
knowledge on how OpenFlow enables the communication between the HP switches and the HP VAN SDN
Controller. You can also take the four-day HP training course, Creating HP Software-Defined Networks,
which includes numerous hands-on labs.

Study Guide design


This guide focuses on SDN solutions and the steps you must take to install and configure them. We
recommend that you download the trial versions of HP VAN SDN Controller and Mininet that are
available to you so that you can practice completing the steps you find in this guide.

HP ExpertOne
The HP ExpertOne program offers a full range of networking curricula, from beginning-level courses all
the way up to Master ASE classes. You will also find fast-track programs that let you leverage your
current industry certifications from Cisco and other companies, building on the investment you have
already made in networking education.
As a participant in the HP ExpertOne networking training and certification program, you will gain:
Proven practices for networking interoperability
Differentiation in the job market
Rapid professional cross-certification
Before taking the Creating HP Software-defined Networks class, you should meet the prerequisites.
These include:
HP ATPFlexNetwork Solutions V3 certification by completing the HP Network Fundamentals, Rev
15.21 course and the associated exam HP0-Y52
We recommend completing either of the following two courses before taking Creating HPE Softwaredefined Networks:
Architecting HP FlexNetwork Solutions, Rev 14.21 (Exam HP0-Y50)
Deploying HP FlexNetwork Core Technologies, Rev 14.31 (Exam HP0-Y47)

After you complete the Creating HPE Software-defined Networks course and either of the two courses
mentioned above and pass the corresponding exams (HPE2-Z38 and HP0-Y50 or HP0-Y47), you will
obtain the HP ASEFlexNetwork Architect V2 or HP ASEFlexNetwork Integrator V1 certification.
HP ExpertOne is now known as HPE Partner Ready Certification and Learning. For more information
about the program and other HPE certifications, visit: http://certification-learning.hpe.com/TR/Index.html

Augmented Realitywhats in it for you?

Figure intro-1: HP ExpertOne Augmented Reality App


Continuing to drive innovation across our portfolio of technologies, HP ExpertOne and HP Aurasma have
come together to enhance the way you learn, bringing embedded digital content to your printed material.
All you have to do is download the HP ExpertOne App powered by Aurasma, open the app, and point the
viewfinder at the icon displayed in Figure intro-1 to launch your extra content.
What do you need to do?
1. Download the HP ExpertOne App for your iPhone or Android device (smartphone and tablet).
2. Install the app
3. Open the app and scan the image with the HP ExpertOne icon until you can see the video starting.
4. You can watch the video on your smartphone or tablet even when you do not have your device close
to the image.

Chapter 1
Introduction to Software-defined Networking
EXAM OBJECTIVES
In this chapter, you learn to:
Explain what is driving the need for Software-defined Networking (SDN)
Explain the fundamentals of SDN and OpenFlow
Explain how SDN abstracts the network infrastructure
Discuss the differences between views of SDN
Explain the advantages of using OpenFlow and SDN

Assumed knowledge
HP ProVision and HP Comware switch command line interface (CLI)
IP addressing

Introduction
SDN has become a popular topic in networking-related websites and magazines. You cannot browse such
publications without finding multiple articles about SDN. Likewise, networking vendors are hosting
webinars that focus on SDN and the advantages it might offer in the future.
As it often happens with emerging technologies, commentators and vendors do not always agree on what
SDN is. Some focus on only one aspect of SDN but may not provide the complete big picture of SDN.
This chapter introduces you to SDN, explaining why it is needed and outlining how it fundamentally
changes networking. You will learn how SDN enables organizations to react to changes and to provision
the network more quickly. You will also see how it enables developers to innovate new applications.
In the chapters that follow you will learn about the SDN solutions HP has released.
Note
SDN is a rapidly changing technology area. It is good practice to refer to the HP website for the
latest information.

Legacy networks
The world is moving faster than ever. Transactions must be processed at lightning speed. Customers want

exceptional service. Employees want access to information and applications from any device. Delivering
on these expectations requires data centers that are more powerful, agile, and automated than ever before,
and a campus environment that responds to a dynamic and changing workforce.
Server and storage architectures have modernized to keep pace with the ever-growing expectations of an
always-on world, but the underlying network has not. The data center network itself, while certainly
bigger and faster, has largely been built the same way for two decades. Evolution of campus networks has
been slow, despite the mobility revolution.
Whether in the data center or on the campus, when legacy networks are pushed to the limit, they become
fragile, difficult to manage, vulnerable, and expensive to operate. Manual configuration and operation
simply would not scale to the demands of todays applications, users, and business requirements.
Businesses whose networks are at this breaking point risk missing the next wave of opportunity.

Problem
Legacy networks cannot keep up with demands from cloud, security, mobility, and big data. Figure 1-1
highlights some of the problems companies face.
SDN gives you an intelligent, responsive, programmable, and centrally controlled network design.

Figure 1-1: Legacy networks

Software-defined networking
SDN is easier to manage, and it keeps pace with todays diverse, growing workloads. HP SDN provides
a programmable network that is aligned to business applications and based on open standards. And our
industry-first SDN App Store provides a marketplace for SDN applications and a platform to share
innovations.

Server virtualization and innovation


Before you delve into the technical details offside, you should understand industry trends that are driving
the move to SDN, which are highlighted in Figure 1-2.

Figure 1-2: Server virtualization and innovation


Networks are increasingly complex and that does not imply just bigger networks, faster networks, and
longer uptime. Through virtualization and other industry trends, silos are coming down between
networking, storage, software, and compute. This plays to HP strengths as HP works in all these areas and
has the scale to meet the new challenges.
Can networks adapt to the changes taking place? The issue that is often encountered is network
complexity. Other industry segments (compute, storage, and software) have been tackling their
complexity. They have been addressing some of their management issues and their operating expense
(OPEX) issues, but networking has lagged behind. Networks today are still complex. They have stayed
expensive and the OPEX seems to be increasing rather than decreasing.
Note
In this chapter, you will review case studies of how Google and USA National Security Agency
(NSA) faced these issues. Googles networking unit costs were increasing rather than decreasing,
unlike its compute and storage units where scale provided per unit cost reductions. Google then
used OpenFlow and SDN to reduce network OPEX. The NSA is also using OpenFlow and SDN to
reduce costs and better control its network.

Server changes
In contrast, in the server arena, virtualization technologies such as VMware have revolutionized server
deployment and setup. No longer do server administrators have to spend days or weeks sourcing a
physical server, using CDs or DVDs to install operating systems, downloading patches, and installing
various software components such as Exchange or SQL server. They can simply provision a server in
minutes or seconds using VMware virtual machines.
This kind of rapid innovation and quick deployment is still lacking in networking today. Network
administrators often still configure networks in a laborious and time-consuming manner via the CLI. The
CLI is used to configure VLANs, routing, IP addresses, and to implement how policies are deployed
(think about access control lists [ACLs], for example). Management options such as Simple Network
Management Protocol (SNMP) have helped with network management, but this is just another method of
configuring the localized control plane on each device rather than changing the way networks operate.

Abstraction
Looking back at the changes in servers, one can see a definite evolution toward abstraction.
Ten or fifteen years ago, servers were where we are today in networking. These were the days before x86
based systems running virtualization. Typically servers were proprietary and had their own chip sets such
as Sparc from Sun, Alpha from DEC, Power from IBM, and the PA RISC architecture from HP. Millions
of dollars went into these chip designs. From a software point of view, UNIX had a range of proprietary
operating systemsSolaris from Sun, UX from HP, AIX from IBM, and so on. Compounding the issue,
the applications were generally proprietary and they took advantage of proprietary middleware that the
operating systems supported.
So, from a server point of view, if you had a Sun Microsystems environment and you had an Oracle
database or a SAP database or some other application, and an HP account manager offered you a great
deal on HP UX and PA RISC architecture, would moving to the HP products be easy and painless? The
answer is of course, no. It was very difficult to move from one vendor to another, given all the propriety
technology used and the cost and expenses associated with purchasing that proprietary equipment.
However, things have changed today. Businesses no longer host a majority of their server environments
on proprietary platforms. Businesses today run standards-based Intel or AMD x86 systems. The servers
use standard interfaces for memory, for storage, for BIOS, and so forth. There are also fairly standard
operating systems such as Linux or Microsoft Windows. There are also standard sets of application
programming interfaces (APIs) that you can develop applications to use. This is once again, an
abstraction layer.
We have abstracted the hardware from the actual operating system and software so that the applications
do not need to be aware of the actual hardware being used. It does not matter if the physical hardware is a
HP DL380, or a HP BL660c Gen8 Blade server, or a virtual machine, or a physical or blade server from
another vendor.
An application programmer developing software for an operating system such as Windows does not need
to be aware of hardware (hard drives, network interface cards, monitor, mouse model, and so forth) as
the underlying hardware is abstracted.
If a business in todays environment is running Oracle on Windows or on Linux, and the hardware is Dell
and a HP account manager now offers a great deal on x86 blade servers, would the customer be interested
in moving? How difficult is the migration from one vendor to another today? The answer is that it is a
straightforward migration. There is very little involvement from the application point of view. Everything
just works seamlessly, and it is very hardware independent.
This is because the industry has done a good job of migrating to an open architecture.

Virtualization
The server environment has been further abstracted with virtual servers. Moving to virtual servers allows
systems administrators to deploy servers in minutes or in seconds. In addition, they can easily move
virtual servers from one physical host to another using technologies such as VMware vMotion. A virtual
server can also be moved dynamically, based on resource use. That is, if a virtual server needs more
resources or the resources on a particular server become overloaded, the virtual server is automatically
moved to server hardware that has available resources.
Storage has had a similar evolution: storage no longer relies on physical disks in each individual server.

Storage is abstracted with logical storage and physical storage components. To provide fast and reliable
storage for computing and data processing, disks are now housed in storage arrays. Systems
administrators access logical storage without regard to the physical storage structure.
For both servers and storage, abstraction has provided flexibility and agility and opened the door for
innovation.

A new (virtualized) style of network control


Server proprietary stacks
You would need to look in a museum today to find server architectures built on proprietary hardware,
proprietary operating systems (OSs), and proprietary applications all bundled as a single product.
Customers do not purchase the hardware, OS, and application as a single bundle anymore.
Customers are able to buy the applications and install them on certified operating systems. This is
installed on often price-shopped hardware purchased based on needs, volume pricing, and other factors.
Figure 1-3 shows how customers have migrated from proprietary hardware to virtualized systems.

Figure 1-3: A new (virtualized) style of network control

Network proprietary stacks


But if you look at networking, networking has not enjoyed the same sort of virtualized
compartmentalization of product components as servers have. Networks are often purchased today in the
identical way that servers were purchased in the past.
Customers determine what network applications and features they needfor example, multicast, VLANs,
Layer 3 services, and so forth. Customers then put these requirements into a request for information (RFI),
or request for proposal (RFP), and ask vendors to submit accordingly. The customer then chooses a
vendor who supports the most features and functionality for what the customer determines is the best
price.
Vendors then deliver a device like a router or a switch (hardware device), bundled with an operating
system (ProVision, Comware, and IOS) that includes operating-system-specific features. The features the
customer gets are determined by both the hardware and the software bundled in this single package.

History repeating itself?

When thinking about networking today, remember what has happened in both the server and storage
markets. We are starting to see these same sorts of pressures and innovations come to the networking
market.

When?
There is often the discussion of how quickly or how slowly SDN will arrive. Remember that the industry
has seen virtualization a couple of times alreadyonce with servers and again with storage. This is not
an unfamiliar concept.
Note
HP Networking already has SDN products and applications that can be deployed today in both
enterprise and datacenter networks. You will learn more about these in this study guide.

Example 1
Here is an extreme example of virtualized networking that illustrates the vision of SDN:
Assume that you went to an electronics store and purchased four low-end switches for US $60 each. You
then added these switches to your companys existing network. As long as the switches support
OpenFlow, which is a standard protocol between the control plane and the switches, you can program the
switches to forward traffic as the external application dictates.
The application could program the switch via the SDN controller to configure a switch to route packets
from port 1 to port 2. The switch may not have the intelligence to understand routing, but a higher level
application with the intelligence has programmed the switch to route based on packet headers received.
The application, rather than the switches, has the routing capability in this example. All the switch does is
match packets containing specific headers and change them according to the instructions provided via the
OpenFlow protocol. These forwarding settings are written to an OpenFlow table via OpenFlow entries.
In this example, four low-end switches without routing capability are able to route based on the
intelligence of an external application. The control plane (network intelligence or network brain) is
running on an external device, while the forwarding plane (data plane/switching plane) with less
intelligence is following instructions given to it.
This example may not be implemented in your network today, but is one of the visions of SDN many are
pursuing.

Example 2
Another example that may be implemented in your network today is extending the functionality of basic
edge switches. Edge switches generally do not contain DNS interception capabilities and databases of
malicious websites.
However, a flow entry could be programmed on a switch to forward all DNS traffic to an external
controller running an application that does have this intelligence. This is what the HP Network Protector
SDN Application provides. Switches still switch or route as usual, but their functionality is extended by
leveraging OpenFlow, external controllers, and external applications.
In this study guide, virtualized networking or SDN refers to the ability to take network features and

functions, install them somewhere in the network and then apply them to boxes (switches, routers, and
others) that are general-purpose processing engines.

Software centric solutions


Rather than concentrating on operating systems like Comware, ProVision, or IOS and then comparing the
features and functionality of each operating system, SDN de-emphasizes the operating system and focuses
on extending the capability of network devices using software. This software may be running on an x86
platform, written in Java, Python, or a multitude of other languages. Features can be added to the
networking device programmatically via open APIs like OpenFlow and others.
SDN changes the paradigm:
Do not bundle as many features as possible into an operating system that only runs on specific
hardware (ASICSs) and has the added risk that the operating system and hardware will become
obsolete in a few years.
Rather, enhance network features by adding these to external servers and then programmatically
extending the feature sets of network devices without the devices having to understand all features.

Not all hardware is equal


The differentiation between the network devices is now not so much the features that an individual
operating system supports, but how quickly a device can process traffic and commands. The hardware
will still determine throughput and speed of setup and tear down. The hardware will also determine the
price of the features.
There are advantages and disadvantages to using merchant silicon (off-the-shelf components and ASICs).
The advantage to using merchant silicon such as Broadcom, Marvell, and Fulcrum is that it provides a
base platform that multiple vendors use. The disadvantage of merchant silicon is that the flexibility to
implement enhanced hardware features is very limited.
The advantage of creating a custom ASIC is that an organization can provide enhancements in hardware
faster than the rest of the industry. The disadvantage of custom ASICs is that the organization must pay a
premium to develop and manufacture these.
That said, however, there is a trend today for multiple manufacturers to use the same off-the-shelf
merchant silicon.
HP uses merchant silicon in some switches (HP 5900AF) and custom ASICs in other switches (HP3800).

Network function virtualization


Network function virtualization (NFV) takes virtualization a step further by virtualizing device hardware
in a similar way to how servers have been virtualized. Rather than deploying physical servers each
servicing a function, today virtual machines are most often hosted by hypervisors. A single physical
server may run multiple virtual servers offering different features such as e-mail services, database
services, web services, and others.
NFV offers a new way to design, deploy, and manage networking services by decoupling network
functions from proprietary hardware appliances. Rather than dedicated routing devices or firewall
appliances, virtual machines running on x86 servers provide these features. Examples include the HP
Virtual Services Router (VSR), which provides both switching and routing functionality without being

constrained to a physical hardware device.

Multiple SDN views


It is important to define what SDN actually is because there are competing viewpoints, as Figure 1-4
shows.
In the past, there were competing technologies and standards for high definition replacements of DVDs:
Blu-ray versus HD-VD. Before that, if you are old enough to remember, there was a battle between
competing technologies and formats for video cassettes: VHS versus Betamax.
With both these examples, you had to make your choice based on whatever your criteria wascost,
quality, company reputation, and so forth. You then had to get the player that supported the format of your
choice and then you had to make sure that every disc you purchased supported the format you selected
(Blu-ray or HD-VD).
Something similar is happening with SDN. There are competing viewpoints and definitionssome of
which are open standards based, and some which are proprietary. Figure 1-4 displays these standards.

Figure 1-4: Multiple SDN views


This is not just a history lesson, but has implications on which version of SDN you chose and what you
will be able to do with it.

HP and OpenFlow
The Clean Slate program asked the question: if we were to begin building networks anewwithout any
existing traditional methodshow would we build them? Would networking technology look like it does
today, or would it look different?
The answer arrived at by Clean Slate, as with other technologies, is that there should be a control and
management system running the show. The network itself should be driven by network-level objectives
(rather than distributed device configurations). And furthermore, that this centralized system would be
able to look at the entire network and make optimal, intelligent, and predictable decisions about how
traffic should be forwarded and routed throughout the network.

This central control systemcalled Ethaneused policy information and a database of various
information (topology, registration, and bindings) to administer rules regarding network access by
individual devices.
In this way, Ethane is a sort of a network access control (NAC) solution. Typical NAC systems require
control functionality on the device (for example, RADIUS or captive portal), or else functionality in a
special in-line appliance, to achieve their desired functionality. This solution was achieved with no
special software on the device or the applianceit was all done with simple devices that exposed their
flow tables to the central controller.
Note
If you are interested in reading more
http://yuba.stanford.edu/ethane/files/ms_ethane.ppt

about

Ethane,

please

visit:

In 2006 HP and Stanford collaborated on the Ethane project. Stanford and HP are right next to each other.
There was cross pollination of ideas between Stanford researchers and HP about making networks more
programmable. Ethane was the precursor to OpenFlow, which allows a developer to access the
forwarding logic of a switch and then programmatically change the switchs forwarding behavior.
One of the problems facing the Stanford researchers was that it is difficult to deploy new concepts and
operating extensions like OpenFlow on hardware switches. This is especially true with the closed,
proprietary operating systems used by networking vendors at the time. They also did not have access to
manufacturing facilities and other resources to simply go out and create new production grade, scalable,
hardware switches.
However, the concept of replacing the operating system of a switch with software is a powerful concept.
Thus, some of the researchers at Stanford started a company called Nicira. The premise of their company
was to create a programmable switch that was software only and that could be deployed on various
hardware platforms like the x86 platform.
In the meantime, Pothers at Stanford and other networking vendors were working on OpenFlow and an
industry organization was formed to further OpenFlow. This is called the Open Networking Foundation
(ONF) and in 2011, OpenFlow 1.0 was released.

Nicira and VMware


This shift in the market was observed by multiple vendors with great interest. There was a lot of buzz in
the marketplace at the time. VMware (also a software company) offered $1.26 billion for Nicira. The
Nicira technology has now been rebranded VMware NSX.
NSX implements a version of SDN where a virtual network is overlaid (overlay network) on the
traditional physical network (underlay network) using Virtual Extensible LAN (VXLAN) tunnels. This
allows a server administrator to dynamically create virtual networks between ESXi servers without
having to ask network administrators to configure and permit VLANs. VXLANs also support 16 million
VLANs compared to 4096 supported by 802.1Q.

Note
The HP VAN SDN Controller and VMware NSX controller federate. The federated SDN and
network virtualization solution provides a common infrastructure and operations model across
physical and virtual networks.
For more information visit: http://bit.ly/1S0WPFH.

Insieme and Cisco


A startup funded by Cisco, Insieme was a separate company fully funded by Cisco. The company was
subsequently purchased by Cisco in 2013.
Insieme employees had a lot of experience and expertise around ASICs and programmable arrays.
Insieme chose to do software-defined programming in ASICs.
This version of SDNApplication Centric Infrastructure (ACI)is largely hardware-based, relying on
ASICs to implement SDN. This has become the Nexus 9000 product line. It uses a proprietary protocol
(OpFlex) instead of OpenFlow.

Standards
The ONF uses OpenFlow as a protocol. VMware uses VXLAN and Cisco uses OpFlex.
The promise of OpenFlow and the ONF version of SDN is interoperability and openness. You are not
locked into a single vendor. This is the original vision of SDN.
As an analogy, a universal remote in your living room should be able to program Blu-ray or DVD players
from multiple vendors. If your Blu-ray player fails, you should be able to replace it with another player
from a different vendor. With some minor reprogramming on your universal remote, you should be able to
control the new player in the same way as the previous unit. This is possible because of an open standard
interface.
As discussed, in compute, you are able to replace a failed server from one vendor with a different
vendors hardware. Applications can be migrated from one physical server to another without great
concern as the operating system (Windows/Linux) is supported by the hardware manufacturers.
In hardware, a network interface card or a hard disk drive can easily be replaced with another because
hardware vendors have agreed on standards. USB technology allows you to move data easily from one
computer to another without much regard to who manufactured the USB drive or from which or to which
computer the data will be moved. Because of standards, these are not of much concern today.
Unfortunately with SDN, some vendors have chosen to implement proprietary versions of SDN. With
SDN, you need to be aware of vendor support, open standards support, and interoperabilityand you
must be careful of vendor lock in because of proprietary implementations.
What this means for you is that if you select one of these types of SDN, you must limit the types of
products you can put in your network based on support for that version of SDN. You are also limited to
the relationships that each vendor has created.
At the time of this writing, VMware has about 19 vendors that they have partnered with. If you decide to
use NSX, you are limiting yourself to about 19 vendors products.

With Cisco, you have about 40 vendors (at the time of this writing) that Cisco has signed a strategic
relationship with.
If you go with the ONF version of SDN, you get well over 150 vendors.
It does become important as to which SDN you want to put in your network. If your goal is to avoid
vendor lock in and to use open standards, you need to choose carefully.

Software versus hardware


It is also important to note that the ONF and VMware versions of SDN are software based. It is therefore
possible that these two versions can be connected and work together. HP and VMware have done this
their controllers federate with each other. The result of this is that you have over 170 vendors to choose
from.
ACI is however ASIC based. You may need to pay royalty payments and purchase licenses to use ACI.
This goes against the original vision of SDN, which envisioned general purpose hardware being
controlled by open standard interfaces and interoperability between multiple vendors.

OpenFlow versions
As discussed, in 2006, Stanford PhD student Martin Casado and others developed Ethane. This used the
idea and approach of centrally managing global network policy. Ethane used a flow-based network and
central controller with a focus on network security. Ethane later inspired the concept of OpenFlow.
The implementation was aided by a number of vendors, including HP, which implemented specifications
in its devices that allowed it to make its forwarding functionality available to a central control system.
OpenFlow is managed by the ONF. It is a standards-based protocol allowing for a centralized-control
plane in a separate device (the controller). OpenFlow provides hardware abstraction, providing the
controller a method to communicate with multiple-vendor devices and multiple-hardware types (routers,
switches, load balancers, and so forth), and uses a standard interface. This takes the control logic on
performing packet forwarding and packet rules and puts these rules down into a hardware abstraction
where they can be followed by the individual network device.
Figure 1-5 summarizes the release of OpenFlow versions, starting with 2006.

Figure 1-5: OpenFlow versions

Note
We will be discussing OpenFlow in detail later in this study guide. If you want to read the details of
OpenFlow now, please visit the ONF technical library:
https://www.opennetworking.org/sdn-resources/technical-library

Note
The HP VAN SDN Controller supports OpenFlow versions 1.0 and 1.3.

Traditional switching
Figure 1-6 shows a traditional switching environment using traditional switch mechanisms.

Figure 1-6: Traditional switching


In a traditional layer 2 switching environment, switching is performed based on destination MAC
address. Each switch has its own MAC address table and learns where devices are located.
1. The basic processing of frames through the network is as follows: Frame arrives at Switch 1 from PC
A (MAC = AAAA-AAAA-AAAA) to PC B (MAC = BBBB-BBBB-BBBB).
2. MAC address table is checked for location of PC B.
3. Entry is found in forwarding table.
4. Frame is transmitted out of port 2.
This process is repeated at every switch in the network.

Flow-based switching
In a pure OpenFlow environment, flow tables are used by devices rather than routing or MAC address
tables. In other words, a switch has an OpenFlow pipeline for processing packets, rather than a
traditional pipeline using traditional switching mechanisms. Figure 1-7 illustrates how this process works
conceptually.

Figure 1-7: Flow-based switching

Important
HP switches support both an OpenFlow pipeline and a traditional pipeline. This is referred to as a
hybrid switch in the OpenFlow specification.
In addition, HP switches support hybrid mode. In hybrid mode, a switch uses both an OpenFlow
pipeline and traditional pipeline for frame or packet processing.
In hybrid mode, a hybrid switch processes most traffic via traditional mechanisms, but OpenFlow
can use to override traditional forwarding. Specific actions like dropping traffic or forwarding it
differently can be implemented in addition to traditional processing.

OpenFlow entries
An entry in a basic OpenFlow table has three fields:
A packet header that defines the flowfor example, Transport Control Protocol (TCP) port 80. This
flow is matched based on the defined match criteria.
The action that defines how the packets should be processed (forward out-of-port G1/0/1).
Statistics that keep track of the number of packets and bytes for each flow (e.g., 100 packets, 8000
bytes). The time since the last packet matched the flow is recorded to remove inactive flows. This can
be configured within the HP VAN SDN Controller.

Actions and instructions


Each flow entry has an action associated with it. The three actions that all dedicated OpenFlow switches

must support are the following:


Forward: The first option is to forward the packets of a flow to a given port (or a set of ports). This
allows the packets to be switched through the network. In most switches, this takes place at line-rate
speeds.
Redirect: The second option is to encapsulate the packet and forward the packets to the SDN
controller. The packet is delivered via a TCP channel or secure channel using TLS. The controller
makes a decision and forwards the packet back to the switch. Typically, this method is only used for
the first packet in a new flow, so a controller can decide if the flow should be added to the flow table.
On the other hand, it could be used to forward all packets to a controller for processing if an
application requires that functionality.
Drop: The third option is to drop the flows packets. This can be used for security reasons, which are
to block unauthorized traffic, stop denial of service attacks, or reduce spurious broadcast traffic from
end-hosts. The HP Network Protector application can be used for this purpose.
Note
You will learn the difference between actions and instructions later in this study guide.

SDN architecture
OpenFlow is a standards based protocol allowing for a centralized control plane in a separate device
(the controller). OpenFlow provides hardware abstraction where details of individual ASICs or
individual hardware are hidden from the controller using a standard API (OpenFlow). This gives the
controller a method to communicate with multiple vendor devices and multiple hardware types (routers,
switches, load balancers, and others) using a standard interface.
As shown in Figure 1-8, SDN decouples the control logic from network devices. Packet forwarding logic
and packet rules are moved to a separate device (the controller). Switches and other devices implement
the forwarding of traffic as instructed by the controller.

Figure 1-8: SDN architecture


Most initial SDN devices are routers and switches. However, OpenFlow and SDN make provision for

many device types and are not restricted to only routers or switches. Other devices such as load
balancers, firewalls, and WAN optimization devices may also support SDN in future. Any network
forwarding device that can be programmed to perform a variety of activities may be part of SDN and
OpenFlow in the future.
The OpenFlow protocol is a specification that defines what the API used by individual network devices
looks like. This API can be used to define what traffic should be matched (based on a set of rules) and
once a match is made, what actions should be taken.

OpenFlow switch
As Figure 1-9 shows, an OpenFlow switch consists of one or more flow tables and a group table, which
perform packet lookups and forwarding, and an OpenFlow channel to an external controller. The switch
communicates with the controller and the controller manages the switch via the OpenFlow protocol.

Figure 1-9: OpenFlow switch


The OpenFlow protocol can be secured using Transport Layer Security (TLS) which is the successor to
Secure Sockets Layer (SSL).
Using the OpenFlow protocol, the controller can add, update, and delete flow entries in flow tables, both
reactively (in response to packets) and proactively. Each flow table in the switch contains a set of flow
entries; each flow entry consists of match fields, counters, and a set of instructions to apply to matching
packets.
Matching starts at the first flow table and may continue to additional flow tables (OpenFlow Version 1.1
and later). Flow entries match packets in priority order, with the first matching entry in each table being
used. If a matching entry is found, then the instructions associated with the specific flow entry are
executed. If no match is found in a flow table, then the outcome depends on configuration of the table-miss
flow entry; for example, the packet may be forwarded to the controller over the OpenFlow channel,
dropped, or may continue to the next flow table.
Instructions associated with each flow entry either contain actions or modify pipeline processing. Actions
included in instructions describe packet forwarding, packet modification, and group table processing.
Pipeline processing instructions allow the packets to be sent to subsequent tables for further processing
and allow information, in the form of metadata, to be communicated between tables. Table pipeline
processing stops when the instruction set associated with a matching flow entry does not specify a next
table. At this point, the packet is usually modified and forwarded.

Proactive versus reactive flows


What happens to the packet flow after the rules are defined? Does every packet need to go to a controller
for processing? Can a packet be forwarded directly by a switch?
As illustrated in Figure 1-10, OpenFlow supports two methods of flow insertion: proactive and reactive.

Figure 1-10: Proactive versus reactive flows


Reactive flow insertion occurs when a packet reaches an OpenFlow switch without a matching flow. The
packet is sent to the controller, which evaluates it, adds the appropriate flows, and lets the switch
continue its forwarding.
Alternatively, flows can be inserted proactively by the controller in switches before packets arrive.
Important
Do not forget that the HP VAN SDN Controller and HP switches support hybrid mode.
The hybrid mode setting determines which packet-forwarding decisions are made by controlled
OpenFlow switches and which of these decisions are made by the controller itself.
If hybrid mode is enabled (the default setting), the controller delegates normal packet
forwarding to the controlled switches, but overrides these switches for nonstandard packetforwarding decisions required by installed applications for specific packet types. In this mode,
the controller relies on the controlled switches to resolve loops and determine forwarding paths
by using traditional networking mechanisms (such as Spanning Tree Protocol [STP] or Open
Shortest Path First [OSPF] Protocol).
If hybrid mode is disabled, the controller makes the forwarding decisions for all packets in the
OpenFlow-controlled network. In this state, the controller resolves network loops and
determines forwarding paths.

HP Networking is empowering the enterprise


Discover the power of network simplicity: The New Style of IT is here. For cloud, big data, security,

mobility, and more, learn how HP and our partners are bringing technology solutions and game-changing
innovations that are transforming the way you do business.

Figure 1-11: HP Networking is empowering the enterprise[1]


HP networking delivers transformational technologies with the broadest SDN-enabled network
infrastructure portfolio. HP Networking delivers wired and wireless unification to software-defined
networking and virtual management.
Figure 1-11 highlights HPs accomplishments: to date HP has shipped more than 30 million SDN-enabled
ports and has grown active connections 53%.
HP network announcements include the following:
HP has completed the acquisition of Aruba Networks, a leading provider of next-generation network
access solutions for the mobile enterprise, for $24.67 per share in cash. The equity value of this
acquisition is approximately $3.0 billion, and the value net of cash and debt is approximately $2.7
billion.
Combining Aruba and HP creates a leader in enterprise mobility, positioning HP to enable and
accelerate the enterprise transition to a converged campus network. Together, HP and Aruba will
deliver next-generation converged campus solutions, leveraging the strong Aruba brand.
The best customer experience:
The biggest compliment around the HP Networking gear that we purchased was on improved
performance and perception from our users that the network was performing better.
Karamu Ford, American Airlines
The biggest benefit received from choosing HP Networking was the standardized network design
topology, which made the network consistent from the data center, through the campus, to the end user.
Alex Munro, Pacific Life Insurance

Enterprises are moving to a new style of IT


Simplify and transform with SDN
At HP Networking, we have been leading the way in simplifying and transforming the network to meet
your organizations needs for mobility, virtualization, high-definition video, rich-media collaboration
tools, and cloud computing (see Figure 1-12). With the HP FlexNetwork architecture, your business gains
an open and standards-based network solution designed to scale on three dimensionssecurity, agility,
and consistency.

Figure 1-12: Enterprises are moving to a New Style of IT


By embracing a software-defined network, you will be able to reap the full value of your network
investment. SDN, delivered through our market-leading solutions, will help your users and organization
experience applications as never before. It will free your IT administrators from the drudgery of manual
network configuration and reconfiguration because the network will be automatically tuned to application
and business needs. Your IT staff can focus more on the quality of the business experience and spend less
time managing the details of the underlying networking infrastructure.
Our SDN strategy is built on the foundation of our open and scalable HP FlexNetwork architecture, which
covers the entire path from the end user to the data center, as well as the technology stack from
infrastructure to management.
HP Virtual Application Networks (VANs) are at the core of our SDN strategy. With HP Virtual
Application Networks, you can move to service-centric management and orchestration and gain business
agility. To help ease your move to an SDN architecture, we have enabled OpenFlow in more than 50 of
our switch models. And we plan to extend support across the FlexNetwork architecture. We are also
building a vibrant third-party SDN developer ecosystem to further drive the open and extensible nature of
the HP Virtual Application Networks SDN Controller.

Journey to SDN
HP provides end-to-end SDN solutions to automate the network from data center to campus and branch.
Expanding the innovation of SDN, HP SDN ecosystem delivers resources to develop and create a market
place for SDN applications.
The HP SDN ecosystem delivers the following benefits:
Simple: Extending simplicity of programmability across the network with OpenFlow-enabled devices.
Open: Raising the value of SDN with an open environment delivered by SDN Software Development
Kit (SDK).
Enterprise ready: Fostering innovations with industrys first SDN App Store marketplace for SDN
applications.

History
Figure 1-13 summarizes some of the major milestones HP has achieved in developing SDN solutions. In
2005, HP had programmable ASICs. To broaden the flexibility of the chip at that time, a programmable
function was included in some areas of its packet processing. This programmability provided network

processor-like capability, giving the HP switch designers the opportunity to make some future changes or
additions in the packet processing features of the ASIC by downloading new software into it. Thus, new
features needing high-performance ASIC processing could be accommodated, extending the useful life of
the switch without the need to upgrade or replace the hardware.

Figure 1-13: Journey to SDN


HP has been a leader in SDN since its inception. As discussed, dating back to the 2007, HP Networking
started working with Stanford to deliver Ethanethe precursor to OpenFlow. In 2008, HP delivered the
industrys first OpenFlow demo software for our switches. This is at least 6 years before any other
vendor even started talking about OpenFlowlet alone deliver working switch code.
In 2009, HP Networking was able to scale R&D lighthouse customers to 10. By 2010, HP had 60 R&D
lighthouse customers.
In 2011, HP delivered industrys first enterprise-class commercial software. HP was the first tier-1
networking vendor to deliver this capability.
In 2012, HP announced the industrys first complete SDN solution spanning all three architectural layers
infrastructure, control and applicationsand lead the industry in OpenFlow-enabled switches with
more than 40 and 10 routers. And the industrys first cloud network technology that enables the
deployment of cloud applications in minutes rather than months with Virtual Application Networks.
HP delivered to market the HP VAN SDN Controller in September 2013 and delivered enterprise ready
applications like the HP Network Protector SDN Application and the HP Network Optimizer SDN
Application for Microsoft Lync in 2014.

Figure 1-14: The history of HPs involvement with SDN


The HP SDN App Store was also launched in 2014 providing HP ecosystem partners a go-to-market
platform together with consulting and support services that will enable customers to realize the business
value of SDN.
In 2015, HP released HP Network Visualizer SDN Application and new versions of the HP VAN SDN
Controller including version 2.5 discussed in this course.

HP commitment to Open SDN


HP is committed to leading and contributing to the SDN standards and standard bodies, some of which
are shown in Figure 1-15:
Open Networking Foundation (ONF):
Founding member
Extensibility workgroup chair
Technical Advisory Group member
OPNFV:
Platinum memberhighest level
Current chair
OpenDaylight
Platinum memberhighest level
Board member

Figure 1-15: HP commitment to Open SDN


A large number of HP devices support OpenFlow
Over 30 million SDN-enabled ports
Over 50 OpenFlow-enabled devices
European Telecom Standards Institute (ETSI) member driving NFV standard
400 Global SP customers
HP is number one in SP network mediation, availability
OpenStack
Platinum OpenStack member
HP is a Top 5 code committer
HP is the number one contributor by employee
InCNTRE:
InCNTRE founding member.
InCNTREs SDN Interoperability Lab at Indiana University is a neutral, third-party facility that
encourages the development and adoption of standards-based SDN technologies such as OpenFlow.
InCNTRE works in collaboration with Indiana Universitys Global Research Network Operations
Center.

Making it easy for customers


Figure 1-16 shows the SDN architecture and the solutions HP is providing, based on that architecture.
The core of HPs SDN strategy is the Virtual Application Networks (VAN), a framework for automating
network operations using SDN technology. HP VAN is designed to provide service-centric management
and orchestration and make the network more agile.

Figure 1-16: Making it easy for customers

Infrastructure layer
At the infrastructure layer, HP has eased the move to an SDN architecture by providing OpenFlow
support in more than 50 existing switch models. OpenFlow, as mentioned earlier, is one of the key
enablers for SDN. The HP VAN SDN Controller uses OpenFlow to program the infrastructure control
plane.
Because HP is adding OpenFlow support to the switch software of existing switches, you do not have to
wait as HP rolls out new hardware and then replaces your entire existing network infrastructure. If your
network already includes these switches, you can simply upgrade the switch software. Because the SDN
Controller is built on open standards, it will work with other vendor devices that implement the
OpenFlow specification (Open vSwitch, for example).
You can also migrate to SDN as slowly or as quickly as you want. HP SDN solutions support hybrid
switches that run hybrid mode. This allows you to manage your migration to SDN without disrupting
existing network operations.
HP also has a couple of wireless APs that support OpenFlow.
Note
Please refer to the HP website for the latest developments with regards to HPs acquisition of
Aruba and Aruba wireless OpenFlow and SDN support.
HP Virtual Services Routers (VSR) and HP Multi-Service Routers (MSR) also support OpenFlow. There
are over 10 models including the HP MSR 2000, 3000, and 4000 series routers.

Control layer
At the control layer, HP provides the HP VAN SDN Controller, which is the centralized control platform
for the software-defined network. It interfaces with the network infrastructure using open-standard
interfaces and control protocols, such as OpenFlow, NetConf, SNMP, and OVSDB. Network devices are
exposed as an abstracted and centralized control plane to network applications allowing for easier

application development.
The HP VAN SDN Controller also provides a platform for SDN applications, which have been built and
integrated into the controller to provide network services such as network virtualization, security, QoS,
traffic engineering, and others.
The HP VAN SDN Controller mediates between these applications (which collect information and make
decisions) and the infrastructure devices (which execute decisions). HP provides programmable
interfaces to the control plane (the HP VAN SDN Controller), allowing third-party developers to create
their own applications for installation as internal applications on the controller. Or they can integrate
external applications with the controller through RESTful APIs. In this way, businesses deploy
applications that rapidly adapt the network to meet the needs of businesses. You will learn about some of
these applications in this study guide and discuss how SDN enhances existing security, cloud, and unified
communications and collaboration (UC&C) applications.

Application layer
Applications developed by HP and by the partner ecosystem are available from the HP App Store. We
will discuss some of the applications in the next chapter.

Management
For SDN management, HP has added a module to HP Intelligent Management Center (IMC) called SDN
Manager (SDNM). IMC provides consistent policy-based management of both OpenFlow and nonOpenFlow networks.
IMC VAN SDN Manager will feature full-fault, configuration, accounting, performance, and security
management for HP-enabled SDN domains.
Enable deployment, monitoring, and management of HP OpenFlow-enabled switches
Visualize traffic flow and performance monitoring in HP SDN domains
Backup and restore configurations and software of HP SDN controllers
Provide graphical OpenFlow troubleshooting with path analysis
Taking advantage of the IMC platform features, IMC SDN Manager leverages the flow monitoring,
topology mapping, and troubleshooting features to provide full SDN management capabilities in the same
interface as the wired, wireless, physical, and virtual network. You will be able to manage both types
SDN as well as traditional interfacesfrom the same console, which lends to the operational efficiencies
required for network administration.

SDN customer solution


To help you practice using the skills and knowledge you gain through this study guide, you will consider
an example scenario in which you will assume the role of a companys IT manager. Interwoven
throughout this study guide, the scenario will be used to help you understand how to implement an SDN
solution for a particular company. As Figure 1-17 shows, the scenario is designed to help you prepare for
a presentation for the fictitious company described throughout this study guide.

Scenario
Your manager (who has a server and storage background) has asked you to help prepare a presentation

about SDN technologies for your companys leadership. Company leaders have heard a lot about SDN
online and in the press and are looking for guidance on the deployment of SDN in the companys network.

Figure 1-17: The scenario for your presentation


You will collect the data you will need to create this presentation as you go through this study guide; the
end goal is to acquire the knowledge and skills you would need to create such a presentation. The
presentation itself is beyond this study guides scope. Your presentation should discuss the following:
SDN, OpenFlow, NFV, and other related terminology
Explain how SDN and related technologies impact and enhance networks.
Determine the migration path from traditional networks to SDN based networks.
Explain the technical details of how switches are configured to work with SDN controllers.
Provide both high-level and in-depth technical presentations.
In addition, the company leaders would like to see a demonstration of SDN technologies to help explain
both business objectives and technical setup. Your presentation should demonstrate potential SDN use
cases and working SDN applications.
Your presentation should be aimed at a nontechnical audience that includes the management team.
Your presentation should also explain technical details, including the solutions effect on the current
network. The technical team includes network, compute, and storage staff skilled up to the networking
Master Accredited Solutions Expert (MASE) level.
In addition, the companys CTO has read online that he may able to leverage your companys in-house
Java and Python development skills to develop and sell potential SDN applications. Prepare part of your
presentation to explain networking and SDN technologies to the development team.

The development team would like a virtualized network environment so that it can develop applications
in a way that is similar to the way it is using virtualized machines for its Linux web server development
projects.
We encourage you to download a trial copy of HP VAN SDN Controller and Mininet, a network emulator
that allows you to create small or large OpenFlow-enabled networks on your laptop. You can use these
resources to follow the instructions on a virtual network. We have included instructions for setting up a
test network in Appendix 1Test Network Setup.

SDN example scenario: Understand the issues companies face


This section presents a series of questions and possible answers intended to help you understand the
types of challenges companies face and the types of questions they have about these challenges. It also
helps you practice discussing the challenges.

Your managers question


The door to the demonstration room opens and your manager walks into the room.
He sees that you have your computer connected to the console of a switch in the demonstration room and
a switch command prompt displayed in your terminal emulation program.
He asks: Why are routers and switches often still configured individually using the command line
interface (CLI) in a terminal emulation program? It seems like very little has changed in the last 10 to 15
years?
I remember the days when I was good at disk operating system (DOS). I could type really quickly in the
DOS command prompt and I had to remember a large number of commands in those days. It seems to me
like networking is still stuck in the DOS days while servers have moved onto using graphical user
interfaces and multiple automation tools.
How would you respond to your manager?

Possible response
Some network engineers trust individual CLI device configurations. This has worked well in the past
why change something that works?

Your managers question


Your manager wants to know more and asks you: What are the reasons for network engineers still
configuring devices individually via the CLI rather than using an orchestration tool like in the server
world? Is there a reason why a console cable or Telnet/SSH is used rather than programmatically
configuring devices using orchestration tools? In the server world, we use tools like HP CloudSystem
when configuring many servers.
How would you respond to your manager?

Possible response
Some network engineers prefer using the CLI rather than scripts or network management applications.
The CLI provides very fine-grained control of individual device configurations.
Other network engineers may also prefer the power and control they have over the configuration of

network devices using a local CLI. This is also historically the way network engineers have been taught
in networking classesconnect to the console or the telnet/SSH to a device. Navigate to the right context
or mode and enter commands to configure options such as ACLs, quality of service (QoS) policies,
routing protocols, and so on.
One of the issues often raised in SDN discussions is that individual, manual device configuration is not
scalable or cost effective, and in addition, is prone to human error. Use cases of SDN and OpenFlow
include network scaling, cost reduction, and enhanced functionality.
Note
IMC is an HP enterprise management solution that supports both traditional networks and SDNenabled networks. With HP solutions, OpenFlow and SDN can be implemented gradually with a
traditional network. Hybrid mode was discussed briefly in this study guide, and will be discussed
again in more detail later.

Your managers question


Your manager asks:How long does it take for a change to be made on a core switch or router?, What is
the longest time you have had to wait for a configuration change to be made?
He then grumbles to himself:When I ask for a network change because we have added extra virtual
machines and servers, it just seems to take so long to get things donelike provisioning VLANs.
Then, looking back at you and looking very puzzled, he says: It seems strange to me that configuration
changes can take days or weeks to be authorized, but you allow programmatic, automated, dynamic
changes to routing tables via routing protocols. And in addition, you allow a switch that you call the root
bridge to dynamically shut ports down in the network when you use spanning tree!
The root bridge doesnt shut the ports down: you reply, correcting him. Ports stop transmitting or
receiving traffic based on costs to the root bridge. The local switch blocks its own ports based on a
spanning tree calculation.
Your manager replies: Well, its all the same to me .You block ports dynamically then.
He then goes on to tell you the story of the time in his previous company where a network engineer added
a switch to the network and it brought the entire network to a halt, something about all VLANs being
dynamically removed because this switch had a lower revision number of some sort.
He then says the following in one last burst of frustration: I just wish the server team could dynamically
update things on the network like QoS for Lync calls or security for mobile devices. And just by using a
graphical user interface rather than having to ask the network team to make manual changes to switch
access lists and the like.
And in addition, I wish we could just create a virtual network and not involve the network team at all. I
heard HP has something like that. I must ask them about it. Whats the longest you have had to wait to get a
configuration change approved?
How would you respond to your manager?

Possible response

Network configuration changes may take a long time to be authorized. This may take days or weeks
depending on the change control process, number of people involved, risk assessment, and other factors.
It is possible that a change request could be passed back and forth over 100 times before agreement and
implementation.
When you configure OSPF and Spanning Tree Protocol (STP), they will determine routing of traffic based
on preconfigured values such as bandwidth, position of the root switch, and other factors such as current
state of different network devices in the topology.
A network engineer may trust OSPF or STP to make dynamic changes after they have been configured.
Some network engineers may answer that these protocols have matured over a long period of time and are
therefore reliable.
However, most engineers have stories to tell of network issues caused by Spanning Tree or other
protocols. These are often caused by the unpredictability of the decisions made by various protocols. STP
and OSPF, for example, will automatically determine new paths or routes based on their local
calculations of what they perceive the network to look like. These calculations very often do not have a
full and complete view of the entire network.
Are you really sure you know what will happen to traffic in every situation?

Your managers question


Your manager has calmed down a bit and wants to know even more.
He says: When I install an application like Microsoft Word or a business application of some type on a
Windows machine, I can move that application to another machine without any concerns about the
underlying hardware."
I can for example buy an x86 HP server to replace a server from another vendor and simply install
Microsoft Windows or Linux on that server. I dont have the issue today like I did many years ago where
the applications, operating system, and hardware were part of a proprietary package, which made it
difficult to source hardware from different vendors.
He then continues talking about the good old days of proprietary UNIX systems and servers that took up
entire buildings.
But at this point, your mind starts drifting to what you are going to do this weekend, which seems much
more interesting than his old war stories.
Fortunately, you start listening again just as he asks the question: Do network devices like routers and
switches have an abstraction layer like this, one that hides the underlying hardware from applications,
allowing applications to dictate where traffic is forwarded?
How would you respond to your manager?

Possible response
Traditional network devices do not have an abstraction layer that provides an open API for changing the
forwarding of traffic. This is often seen as one of the reasons to implement an SDN controller-based
solution. The controller provides an abstraction layer to the underlying network devices, allowing for
quicker and easier application development and deployment.
OpenFlow is the protocol used by the SDN controller to program the flow tables of devices to change

forwarding behavior.
Some of the advantages of using a controller as the abstraction layer include the following:
The controller provides high-level APIs, making it easier for application developers to write
applications quickly.
Application developers are able to program multiple devices from different vendors using the same
high-level API without concern about the underlying hardwareit may be an Open vSwitch virtual
switch, an HP ProVision switch, an HP Comware router, an HP VSR, or even a wireless access point,
but they are programmed in the same or a very similar way.
Multiple differences between OpenFlow versions are hidden (1.0 versus 1.3, for example). An
application developer does not need to be concerned about the low-level OpenFlow version
differences (packet format, meaning of bits on the wire, and so forth).
ASIC and other hardware differences can be abstracted by the SDN controller. An application
developer can simply state that a flow be added to a switch without concern about tables available.
Note
Please note that there are some differences between ASIC implementations that a developer may
need to be aware of, but a large amount of complexity has been abstracted. In some cases, the
developer can simply ignore the selection of hardware tables and leave it to the controller to
decide the optimum place to store flow entries.
Your managers phone rings and he has to leave the room. He says he will be back later to continue the
conversation.
You breathe a sigh of relief as this gives you some time to continue configuring your network devices.

Your managers question


Your manager also asks: I have been online researching for our company presentation. Is Open Shortest
Path First Protocol (OSPF) an open standard?
How would you respond to your manager?

Possible answer
Yes, OSPF is an open standard protocol. See RFC 2328 (IPv4) and RFC 5340 (IPv6) if you are
interested in more detail.

Your managers question


Your manager asks:How does OSPF calculate routes?
How would you respond to your manager?

Possible answer
OSPF calculates routes based on interface bandwidth. A high-speed link is deemed to be better than a
low-speed link.

Note
Some devices assign a fixed cost per VLAN and will not take the speed of the link into account.
This will, therefore, affect the OSPF path calculation.

Your managers question


Your manager looks perplexed and shows you a network diagram (see Figure 1-18). He then asks: Does
that mean that OSPF cannot take factors like customer traffic types or time of day into account, or the load
of links? How will OSPF route traffic from Router1 to Router7 and Router8 in the following figure?

Figure 1-18: Classical fish routing problem


How would you respond to your manager?

Possible answer
As Figure 1-19 shows, OSPF will route traffic on the path R1-R2-R3-R6-R7 or R1-R2-R3-R6-R8. OSPF
cannot make routing decisions based on time of day, load, or customer traffic types.

Figure 1-19: OSPF routing

Your managers question


Looking more perplexed, he asks multiple questions: That means that no traffic is taking the lower link in
the diagram when sent from R1 to R7 or R8, right? Does that not mean that you are wasting potential
bandwidth in your network? Is it possible using other methods to send traffic along path R1-R2-R4-R5R6-R7 and R1-R2-R4-R5-R6-R8 at the same time? And how would you do it? And is it a scalable
solution for a large network? And is it easy to implement?
How would you respond to your manager?

Possible answer
OSPF does not support traffic engineering based on anything apart from bandwidth. You could use policybased routing or Multiple Protocol Label Switching (MPLS) to direct traffic based on other criteria.
However, policy-based routing is a very static implementation and is not scalable. Traffic throughput is
also often very slow when policy-based routing is used.
MPLS traffic engineering (MPLS-TE) is complex and is not supported on all switch models (for example,
ProVision switches). MPLS-TE can support forwarding of traffic across both the upper and lower links
in Figure 1-18, but it is not suitable for a lot of enterprise networks due to its complexity and device
requirements.

Your managers question


Your manager then asks: Is it possible to use an API on the routers to create our own routing protocol, or
send traffic via a different path? Are routers and switches software open source?
How would you respond to your manager?

Possible answer
Vendor equipment and operating systems are mostly proprietary. In the past, there has not been an open
API on network devices for creating new routing protocols.
One of the visions of the original work on SDN and OpenFlow at Stanford University and subsequently

within the ONF was to create an open API on vendor equipment. This open standard API would allow
customers to program their network devices via a centralized controller. OpenFlow is the protocol for
programming networking devices that support the OpenFlow API. This would allow a programmer to
direct the flow of traffic on multiple vendor devices including the example topology in Figure 1-18.

Your managers question


Your manager then says: I recently watched a YouTube video presented by Urs Hoelszle from Google
(senior vice president of technical infrastructure). Google is getting close to 100% network utilization in
its network, which is amazing.
Urs explained Google has used OpenFlow in its core network since around 2010. He said that they
found that networking costs do not go down when devices scale. He states that running a datacenter at
scale has a massive savings compared to small implementations.
Urs said, however, that that networking costs stay linear, or increase, unlike servers and storage, where
the per-device cost goes down as you scale. It is hard to save money even when you have a large
implementation and many devices networking. Why is that? your manager asks you.
If you want to, watch the video your manger is referring to on YouTube. (View from 3:30 to around 7:00
of the video.)
Note
OpenFlow @ Google
https://www.youtube.com/watch?v=VLHJUfgxEO4
Presentation slides: http://opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf
Note
In the next chapter, you will revisit the Google OpenFlow use case in more detail. Google shared
more details of its implementation and experience in a 2015 presentation.
How would you respond to your manager?

Possible answer
Reasons mentioned in the discussion with your manager should include the following:
1. Manageability issuesmany routers need to be set up and configured by hand. This results in a linear
growth of cost with the number of devices.
2. The cost of devices increasesthey tend to be more expensive per unit as you scale up. You need to
buy expensive CPUs to manage large network routing tables.
3. You cannot manage 10,000 routing devices in the same way you can manage 10,000 compute
resources. You do not manage 10,000 virtual machines individually, but you manage them as a pool.
This allows for automation of tasks. The difference between managing 5000 devices versus 10,000
compute devices is very similar. This is however not true of networking devices. Network devices

are still manually configured in a lot of cases.


This study guide will provide instructions for configuring the network as shown in Figure 1-7. This will
help demonstrate the integration between the OpenFlow-enabled devices and non-OpenFlow-enabled
devices.

Your managers question


Your manager tells you: I was so worried that during our presentation management would ask about
OpenFlow and SDN security, but I just found something amazing.
Yes? you say, not quite sure what to expect.
Can you believe it? The NSA uses OpenFlow and SDN and is talking about it publicly. I found a video
on YouTube! The NSA is openly talking about its network! he continues excitedly.
I can hardly believe it!
Note
The NSA is the USA National Security Agency, an intelligence organization of the US government,
responsible for global monitoring, collection, and processing of information and data for foreign
intelligence and counterintelligence purposes. Website: https://www.nsa.gov
He continues: Bryan Larish is the technical director of Enterprise Connectivity and Specialized IT
Services at the NSA and he gave a talk about it.
He was told by his boss (when he took his job), that NSA needed a bigger, faster networktomorrow.
But he was also told that his budget was being slashed, his manpower was being slashed. He was told to
go and figure it out. Thats how he started his job at the NSA.
Bryan said that the NSA has the same IT challenges as other large organizations and they therefore talk
to other organizations about solutions. He said the reason others are looking at and implementing SDN are
budget, manpower, and new capabilities. These are the same challenges he faces at the NSA.
And he as a director at the NSA has additional challengeslots of bureaucracy and a culture not open to
change.
Then, smiling broadly, your manager says: Bryan said that at the NSA, they have decided that
centralization via OpenFlow is key.
The reason for this is control. They require predictability and efficiency to make the network secure, and
to support mission critical workloads that run over the network.
They are all in on OpenFlow as it seemed to them that OpenFlow with centralized control is the only
viable way to technically implement their requirements. This is the path they are pursuing.
Keys for them are simplicity and centralized control, which allows the agency to be ruthless in
simplifying the network. This also allows it to add new capabilitiesespecially in the area of network
security.
In a secure network, you should know where everything is. NSA is now able to implement policies
where it knows exactly where devices like DHCP servers are in the network and dictate where traffic
goes to get to the servers. There is no dynamic learningthe network is very predictable and

deterministic. Thus when something breaks, it is very easy to find out what broke and why.
The NSA is deploying OpenFlow in its data centers, campuses, and branch offices.
If you want to, watch the video your manger is referring to on YouTube. (View from 12:50 to around
25:30 of the video.)
Note
SDN in Enterprises: https://www.youtube.com/watch?v=C0DxR4IMd20
Your manager looks at his watch and says: I have to go. Its almost time for my round of golf this
afternoon and I dont want to be late. The sun is shining and it is a lovely day. You finish configuring and
working on our presentation. I expect you to work late, because this presentation is really important.
We cannot write here what you are thinking at this point, except that the room is dark and cold and you are
hungry.
Perhaps this SDN thing will mean shorter days, but for whom?

Summary
In this chapter, you learned how SDN helps enhance and improve networks. You learned the needs
driving SDN and reviewed some initial use cases of OpenFlow and SDN.
You learned some of the fundamentals of SDN and OpenFlow and learned how SDN abstracts the
network infrastructure, allowing software developers to programmatically implement business policies.
You also reviewed some differing viewpoints of what SDN is and then learned some of the advantages of
an open standards based, multivendor OpenFlow-enabled SDN.
For additional information, view the following video: Software-defined networking (An
introduction) http://bit.ly/1MwN0sr

Learning check
Take a moment to think about what you have learned about SDN and OpenFlow. Answer each of the
following questions.
1. Which company increased bandwidth utilization dramatically using OpenFlow?
2. Is it possible to run a traditional network and OpenFlow-enabled network at the same time?
3. Do HP network devices become dumb devices with no control plane when running OpenFlow?
4. Which USA government organization uses OpenFlow and an SDN controller to better secure its
enterprise network?
5. Do HP and VMware have a federated SDN solution?

Learning check answers

1. Google
2. Yes, HP switches are hybrid OpenFlow switches, which support both an OpenFlow pipeline as well
as a traditional pipeline.
3. No. If hybrid mode is enabled (the default setting), the controller delegates normal packet forwarding
to the controlled switches, but overrides these switches for nonstandard packet-forwarding decisions
required by installed applications for specific packet types. In this mode, the controller relies on the
controlled switches to resolve loops and determine forwarding paths by using traditional networking
mechanisms (such as STP and OSPF).
4. NSA
5. Yes, HP and VMware have a federated SDN solution for both the virtual overlay network and the
underlay network.

Chapter 2
SDN Case Studies
EXAM OBJECTIVES
In this chapter, you learn to:
Compare Software-defined Networking (SDN) campus, data center, and cloud solutions
Describe the HP SDN App Store
Describe the OpenDaylight (ODL) SDN controller
Explain the features of HP SDN campus applications:
HP Network Protector SDN Application
HP Network Optimizer SDN Application
HP Visualizer SDN Application
Describe data center and cloud SDN solutions
HP Virtual Application Networks (VAN) SDN Controller and VMware NSX federation
HP VCN
HP DCN

Note
This chapter only introduces various HP SDN applications and technologies and is not a
comprehensive guide or a technical document.
Some of the applications, such as Network Protector and Network Visualizer, are discussed in
much greater detail later in this course, while the details of others can be found on the HP website.
A good place to start for more information is http://www.hp.com/sdn.

Introduction
The initial release of the HP VAN SDN Controller was in November 2013, and multiple SDN
applications were released in the spring of 2014. Since that time, the adoption of HP Networking (HPN),
the HP VAN SDN Controller, and HP SDN Application solutions has resulted in several publicly
available customer case studies, which illustrate real-life user, IT management, and business-case
justification benefits.
In this chapter, we will introduce various HP SDN applications for the campus, data center, and cloud.

You will learn about the HP SDN App Store and various applications available via the App Store.

HP SDN App Store


Campus SDN
In the first part of this chapter, we will discuss campus SDN applications and solutions. In the later part,
we will discuss data center SDN solutions.

Background
The HP SDN App Store provides HPs ecosystem partners a go-to-market platform together with
consulting and support services that will enable customers to benefit from the business value of SDN.

Figure 2-1: HP SDN App Store


Figure 2-1 displays a handful of the 120 vendors who are creating the products that support Open
Networking Foundation (ONF) software-defined networking (SDN). IDC predicts that the market for
SDN network applications will reach $1.1 billion by 2017, increasing network application vendors need
for a scalable, open marketplace to monetize their innovations. As the first enterprise-grade SDN
application ecosystem on the market, the HP SDN App Store redefines the networking business model,
offering the developer community a centralized platform for connecting to customers around the world.
Customers can now easily discover, learn, and purchase specific network applications and download
them to their environments for testing and live deployment.

HP SDN App Store


HP hosts an app store for the delivery of SDN applications. Applications from HP AllianceONE partners
and the community at large are made available in the HP SDN App Store. All apps can be purchased with
a credit card, and selected HP and HP Partner apps can be purchased through the traditional channels
with delivery through the HP SDN App Store.

Software development kit (SDK)


HP has made a SDK available with the HP VAN SDN Controller. The SDK gives developers all the tools
necessary to build SDN applications for the HP controller. It includes documentation for both the Java
and the REST APIs as well as all of the jar files necessary during compilation. Sample applications are

also included.
A remote lab is also available to AllianceONE partners for testing SDN applications with real hardware.
HP also hosts and monitors a developer forum where developers can collaborate to get answers to
questions. For more information and help with developing a new application, please go to
sdndevcenter.hp.com.

HP SDN ecosystem
As Figure 2-2 illustrates, HP is building an entire SDN ecosystem, which at present includes the
following:
Over 30 million SDN-ready ports in production, providing customers a rapid path to the new style of
business while providing developers a large market
Over 5000 downloads of the HP VAN SDN controller
Over 100 APIsand not only the APIs, but a full developer community, support, services, and a sales
model
Over 5000 man hours in certification of SDN apps
Five developer events globally providing support to our growing community
A total of 5000 downloads of the HP developer kit
Over 30 ecosystem partners

Figure 2-2: HP SDN ecosystem

App Store circles


The HP SDN App Store offers independent software vendors an easy way to bring creative solutions to
market, enabling IT managers who embrace the SDN architecture to solve their unique network
challenges through these vendors applications.

Figure 2-3: App Store circles


To help customers easily navigate the HP SDN App Store, HP offers three categories of applications,
which are defined by their support and test processes. Figure 2-3 provides a screen capture that
illustrates the following HP App Store circles:
The HP Circle, with applications built and tested exclusively by HP
The Partner Circle, encompassing applications that have been self-tested by HP partners and reviewed
by HP
The Community Circle, offering open-access and community-supported applications to demonstrate
open source and concept SDN applications

OpenDaylight (ODL)
HP announced the availability of ODL in the HP App Store in July 2015. (See Figure 2-4 for a screen
capture that illustrates ODL availability.)

Figure 2-4: OpenDaylight (ODL)

Questions and answers


Here are some frequently asked questions about ODL:
Q : What is being announced?
A: To continue with our leadership, we are releasing an experimental version of the ODL controller
(based on Lithium) on the HP SDN App Store. HPs SDN App Store will now host applications that run
on both the HP VAN SDN Controller and the ODL controller.
Q: How long has HP been involved with open source and open standards in SDN?
A: HP has been a leader in driving SDN innovation. Dating back to 2007, HPN started working with
Stanford to deliver Ethanethe precursor to OpenFlowand delivered the industrys first OpenFlow
demo software for its switches in 2008. In 2013, HP announced the first SDN Open Ecosystem, which
included HP VAN SDN Controller, giving developers all the tools to innovate as well as the industrys
first enterprise-grade SDN app store as a marketplace for customers and developers of SDN.
Q: What is the ODL project?
A: The ODL project is a collaborative open source project that aims to accelerate adoption of SDN and
create a solid foundation for network functions virtualization (NFV) for a more transparent approach that
fosters community innovation and reduces risk.
Q: What has HPs participation in ODL been to date?
A: HP is a founding member of ODL. It has been a silver member since the projects inception and was
instrumental in its founding, legal and organizational setup, and in the creation of its technical governance
model. HP raised its level of support to become a platinum member in May 2014 and is investing
substantial development and test resources in the core platform.
Recently, HP also acquired ConteXtream, which has been developing solutions based on ODL and also
contributing back to the community since the first ODL release. The ConteXtream solution is not currently
available on the HP SDN App Store and is separate and distinct from the experimental version that is
posted.
Q: What does this announcement mean for customers?
A: With the expanded ecosystem that includes ODL developers, customers now have the opportunity to
discover and explore more SDN innovations at HP SDN App Store. They can see a new category at the

HP SDN App Store hosting the community version of ODL controller and the SDN Apps based on ODL.
Q: What is HPs position on open source with respect to networking?
A: The networking market is rapidly evolving and HP has been at the forefront of the change toward
increasing openness, standardization, and interoperability. HP has a proven ability to drive, adopt,
productize, and plug into open source, as evidenced by its leadership in Linux, OpenStack, and various
other open source projects. HP believes open source speeds up innovation and provides customers with
flexibility in solutions and vendors.
Q: What is HPs SDN strategy?
A: HP SDN provides an end-to-end solution to solve compelling customer problems. HPs overall SDN
solution strategy is to enable the network to deliver business objectives for data center, campus, and
branch, as well as for communications service provider customers who require increased network agility
and automation in addition to enhanced security, optimization, visibility, and orchestration on their
existing network infrastructuresall without single vendor lock-in. HPs solution architectures allow for
inclusion of various SDN controllers depending on our customers needs.
Expanding the innovations with SDN, HP SDN Open Ecosystem was created to deliver the resources to
develop and create a marketplace for SDN applications. This ecosystem is now expanding to add ODL.
Q: Will both the HP VAN SDN Controller and ODL Controller be available in the HP SDN App
Store?
A: Our customers and ecosystem partners can now access both ODL Controller and the HP VAN SDN
Controller on the HP SDN App Store. Adding the ODL controller allows developers to experiment with
this platform and deliver concept applications to customers.
The ODL Controller is the open source community version; hence, the ODL Controller and the ODL
Controller-based applications are not validated and supported by HP. The HP VAN SDN Controller was
commercialized 18 months ago and is in production use at a number of enterprise customers sites
worldwide. HP will continue to enrich the HP VAN SDN Controller with new capabilities to make it the
industrys leading platform for SDN application development and production deployment. As part of our
ODL contribution, we will bring the best of VAN SDN Controller innovations, interfaces, practices, and
support from HP to the larger SDN community.
Q: What will be HPs key contribution areas to the HP controller based on ODL?
HP is contributing to a number of projects, including Amiga Advanced Architecture (AAA), device
drivers, OpenFlow, and hybrid mode, and clustering for high availability (HA). It is also contributing to
multiapplication support, including the Network Intent Composition (NIC) API, persistence, service
function chaining, OpenStack integration, and federation of controllers. In addition, HP is involved in
establishing a continuous integration (CI) test framework and performance profiling of the ODL
controller.
Q: What is the relationship between ODL and OpenStack?
A: ODL interfaces with OpenStack using the Neutron networking framework. A strong and growing
overlap of companies and individual contributors are working on both OpenStack Neutron and ODL. In
addition, ODL, by virtue of being a liberally licensed open source project, is poised to become the de
facto SDN controller for OpenStack test and deployment environments, and several companies are
productizing full-stack solutions for OpenStack that include an SDN controller powered by ODL.

Q: I am a customer who has SDN applications running in production on the HP VAN SDN
Controller. What does this announcement mean to me?
A: You are in good shape. HP continues to lead in controller technologies and SDN ecosystems and is
committed to supporting new and existing VAN SDN controller customers who deploy SDN applications
in production networks. The HP VAN SDN Controller is the premier enterprise-grade controller in the
market right now.
Q: I am a developer and have written or ported an app to the HP VAN SDN Controller. What does
this announcement mean to me?
A: You are in great shape. With this announcement, you are able to access an even larger market within
the same ecosystem while working with a partner like HPa leader in SDN innovation. Please contact
the HPN SDN team for more information about your app via ODL.

HP applications
As Figure 2-5 illustrates, at the time of this writing, HP has three major applications in the HP SDN App
Store:
HP Network Protector SDN Application: provides protection against real-time security threats
HP Network Optimizer SDN Application: provides application-driven quality of service (QoS)
HP Visualizer SDN Application: provides network visibility

Figure 2-5: HP applications

HP Network Protector SDN application


Introduction
The Network Protector SDN application enables automated network posture assessment and real-time
security across an SDN-enabled network, providing simple security for bring-your-own-device (BYOD).

Figure 2-6: HP Network Protector SDN application


Figure 2-6 illustrates a number of other services the application provides. The Network Protector SDN
Application uses the HP VAN SDN Controller to program the network infrastructure with security
intelligence from the TippingPoint Reputation Digital Vaccine (RepDV) Labs database.
This turns network infrastructure devices into security-enforcement devices, providing visibility and
threat protection against more than one million malicious botnets, malware, and spyware sites.
The HP Network Protector SDN Application stops threats at the network access layer before they can
cause damage. Network Protector can be used in any network environment where security is a concern,
including BYOD, data center, and cloud computing environments. HP envisions a network where
Network Protector can be implemented on any network device, anywhere in the network for
unprecedented network visibility, event correlation accuracy, and security control.

Features
Simple security for BYOD
The Network Protector SDN application brings a new level of threat visibility, automation, and control to
organizations that support BYOD for network connectivity.
The application scales up to thousands of endpoints, supporting enterprise organizations.
The Network Protector SDN application decreases the time IT spends on security problems, from days or
weeks to hours.

Enables automated network-posture assessment


The Network Protector SDN application improves your network visibility and accuracy. The application
prioritizes specific Domain Name Service (DNS) traffic (for example, business critical) and restricts
noncritical DNS traffic (for example, social media).

Provides real-time threat detection across enterprise campus networks


The Network Protector SDN application protects from over one million malicious botnet, malware, and
spyware sites. The application enables real-time threat characterization with the HP TippingPoint RepDV

cloud service database.


The Network Protector SDN application can address cloud-based threat intelligence.

Proactive IT management of threats


The HP Network Protector SDN application allows flow-based dynamic access control lists (ACL),
bringing security to the next level. The application allows for per switch and device inspection throttling.
The application provides enhanced white/black/gray list user policy routing.

Dashboard
Figure 2-7 provides a screen capture of the HP Network Protector dashboard. Features and benefits of the
HP Network Protector SDN application include the following:
Quarantine thresholds can be configured on per client DNS requests per second or on total number of
unique malicious connections per client, resulting in IP redirection or dropping of all client traffic.
Malicious identity displays the IP addresses associated with quarantined or blocked clients or reveals
user-id when integrated with IMC.
Custom whitelist allows administrators to bypass reputation check for configured domains.
Custom blacklist allows the administrator to block configured domains. This can be configured to
block at specified periods of time.
The top-infected VLANs display provides visibility into the relative health of VLAN clients.
The top-infected endpoints display provides visibility into the source of malicious traffic.
Inspection throttling ensures that network performance is not impacted by bursts of heavy traffic.
Group policy supports individual reputation levels for blocking or quarantining members of the group.
The email alerts feature notifies the administrator of quarantined clients or malicious connection
attempts.
HP ArcSight integration allows logging of malicious activity in common event format (CEF) syslog
format (optional capability).

Figure 2-7: Dashboard

HP Network Optimizer SDN application


Deploying trusted and granular QoS can be extremely complex and requires implementing tedious and
time-intensive manual configurations on a device-by-device basis. In fact, it is nearly impossible to
implement consistent end-to-end traffic policies using deep packet inspection (DPI) for soft clients with
legacy networks. Session Initiation Protocol (SIP) Transport Layer Security (TLS) encryption and
dynamic application ports, used by unified communications (UC) applications, result in poor application
traffic visibility.

Figure 2-8: HP Network Optimizer SDN application


Figure 2-8 illustrates how the HP Network Optimizer SDN application reduces complexity and improves
QoS. It automates policy deployment dynamically on a per session basis for voice, video, and application
sharing to deliver a better user experience and reduce operational costs. When a desktop sharing, voice,
or video session is initiated using a Microsoft Lync client in the campus or branch office, the Lync Server
in the data center provides the HP Network Optimizer SDN application with session details. These
include the source and destination IP addresses, protocol type, application ports, and bandwidth
requirements at the start and end of every call via the Lync SDN API. HP Network Optimizer then uses
these per session application details to dynamically provision QoS policy in a trusted manner via the HP
VAN SDN Controller using OpenFlow.
The HP Network Optimizer SDN application uses the intelligence from Lync Server and the Lync SDN
API along with the robust capabilities of the HP VAN SDN Controller to dynamically prioritize traffic at
the edge of a network using OpenFlow. This allows the network administrator to implement consistent
and trusted QoS policies across the network. This is done dynamically through a central point of control,
eliminating the need for manual, device-by-device configuration via the CLI, which greatly simplifies
policy deployment and reduces the likelihood of human errors.
In addition, HP Network Optimizer displays a graphical dashboard of Lync call quality metrics to
provide an intuitive way to understand Lync call statistics in your network. This includes the number of
active sessions and peak-call time, quality of experience metrics for completed calls, and poor call
quality analysis details to assist with monitoring and diagnosing Lync call-quality issues.

HP Network Optimizer SDN application


The HP Network Optimizer SDN application uses OpenFlow to dynamically prioritize traffic at the edge
of a network. There are four traditional ways that unified communications can be identified and
prioritized on the network:
The first method prioritizes all traffic from a device. This method is used with traditional VoIP phones
by placing the phone in a voice VLAN and prioritizing all traffic in this VLAN. This solution is not
possible with Microsoft Lync in wholesale deployments because the voice client is usually the Lync
software client running on a PC.

The second method uses a predefined Transport Control Protocol (TCP) or User Datagram Protocol
(UDP) port number or range where traffic matching these ports can be prioritized. This is not an ideal
solution because it increases Lync and network management overheads as well as raises the potential
of port mapping conflicts on the client PCs. (See Figure 2-9 for a graphic illustration of Microsoft
Lync communications on a network.)
The third method uses a DPI engine to analyze and determine the packets nature. However, in the case
of Lync, this is not feasible because all Lync control traffic is encrypted in TLS sessions. This makes
DPI analysis impossible or unreliable in its ability to isolate business Lync traffic from nonbusiness
voice or video communications.
Finally, the client can mark traffic as important and configure the network to trust the tags. While this
will work and Lync does support it, it requires a level of trust from network clients that is not
recommended. As soon as the network trusts a client, there will be users who abuse the trust and
attempt to prioritize all of their traffic. In other words, a user could use a companys network to watch
movies or download BitTorrent files at high priority.

Figure 2-9: HP Network Optimizer SDN Application


The above solutions led HP and Microsoft to develop a better method to prioritize important Lync traffic.
The Lync Server had detailed knowledge of UC session information happening in an environment and HP
SDN controllers had detailed knowledge of physical topology. Microsoft, in collaboration with HP,
developed an API that installs on the Lync Server and can make RESTful API calls to the HP Network
Optimizer SDN application with all of the call details, including users, type of call, and bandwidth
requirements. HP Network Optimizer can then use OpenFlow to dynamically prioritize traffic on the
network for the duration of the call.
The HP Network Optimizer SDN application uses OpenFlow-hybrid mode and only the edge, or access
devices need to be OpenFlow enabled. In this case, the HP Network Optimizer SDN solution does
Differentiated Services Code Point (DSCP) remarking at the edge of the network and the rest of the
network is configured to honor the markings supplied by the access layer device. Previously, trusting end
user QoS values was a bad idea but with the access-layer devices doing the QoS marking, it is the
network core that honors QoS markings received from the network edge. When the HP Network
Optimizer application boots, a default flow is pushed to all access devices. This remarks all traffic to
normal priority in the specified VLANs. It is then possible for HP Network Optimizer to dynamically
prioritize the Lync traffic to an administratively assigned priority.
Out-of-the-box, this solution will work without any additional configuration required on clients that are

attached to OpenFlow-enabled devices. If a client is not directly connected to an OpenFlow-enabled


device, it is possible for a network administrator to configure a gateway for a known group of devices.
This enables prioritization to be dynamically assigned for the network under an administrators control.

HP Network Optimizerdashboard
Value proposition
HP Network Optimizer provides an enhanced Enterprise Voice user experience with Microsoft Lync soft
clients that users have come to expect with traditional PBX voice connections and VoIP-based on hard
phones. This allows an enterprise to support the mobility demanded by users and offered by Microsoft
Lync Enterprise Voice and still get the experience they want. Calls are dynamically provisioned without
administrative involvement.

Figure 2-10: HP Network Optimizerdashboard


HP Network Optimizer also enables the IT administrator to rapidly define and adjust the priorities of
Lync traffic on the network with granular control of both DSCP markings and 802.1p priorities. No longer
does the network administrator need to touch every switch to deploy a unified communications QoS
adjustment. (See Figure 2-10 for a screen capture of the HP Network Optimizer application dashboard
and a quick list of other salient features.)

Performance
An instance of HP Network Optimizer can support an infrastructure with up to 2000 OpenFlow-enabled
network devices and up to 10,000 users. These numbers assume minimum system requirements of a quadcore processor, 8 GB of RAM, and 64 GB of available disk space. Additional instances of HP Network
Optimizer can be deployed to support a larger number of OpenFlow-enabled network devices and users.

Redundancy
In the current release of HP Network Optimizer, HA is not supported. To help maximize network
availability, the OpenFlow-enabled devices in a network should be configured to fail open in the case of
controller unavailability. HP Network Optimizer is designed to operate in a hybrid SDN mode. This
means traffic is forwarded using traditional networking methods based on destination MAC address or
destination IP address. When a switch fails open, these same traditional forwarding mechanisms will
continue to forward traffic as expected.

Security
Network security has been a critical concern for a very long time and does not change with the advent of
SDN. The methods of securing a network require an evaluation. There are several mechanisms that aid in
securing an SDN environment. First, the connection between a switch and a controller should be passed
onto a dedicated management VLAN or, for additional security, be handled on a completely out-of-band
network. An out-of-band network is likely not possible in a campus LAN but may be possible in a data
center. Second, the communication between an OpenFlow device and the controller should be
authenticated and encrypted. The HP VAN SDN Controller and HP switches support mutual authentication
using certificates and TLS. Access to the controller for management purposes is also encrypted using TLS
and authenticated using OpenStack Keystone.

Frequently asked questions


Q. What is required to implement HP Network Optimizer?
Answer: HP Network Optimizer requires OpenFlow-enabled switches at or near the access layer of the
network. It is installed as an application on the HP VAN SDN Controller, which can be deployed as a
virtual machine or on a bare metal server. However, higher network throughput can be supported when
installed on a bare-metal server. It is also necessary to configure QoS on the distribution and core
devices in a network to trust the DSCP markings that are set at the edge of the network. This solution also
requires the Microsoft SDN API and SDN Manager to be installed in the Lync environment.
Q. How does HP Network Optimizer work with Lync Optimized IP phones?
Answer: It maintains an installed and configured voice VLAN for hard phones. In collaboration with HP
Network Optimizer, this will decrease the access control list (ACL) resource impact of the solution
where Lync Optimized IP phones are used. HP Network Optimizer will automatically provide dynamic
provisioning for Lync Optimized IP phones in addition to soft phones, unless excluded.
Q. How does HP Network Optimizer scale?
Answer: An instance of HP Network Optimizer can support an infrastructure up to 2000 OpenFlowenabled network devices and up to 10,000 users.
Q. Where should HP Network Optimizer be deployed?
Answer: HP Network Optimizer should be deployed local to the LAN it is configured to provision. Any
additional latency introduced by deploying the SDN application remotely could delay QoS provisioning
and affect the user experience at the start of a new session.
Video demonstration
v=byMtYpmh1xQ

of

Network

Optimizer:

https://www.youtube.com/watch?

Current troubleshooting tools challenges


Current troubleshooting tools challenges include the following:
Increasing network complexity, harder to troubleshoot
Manual and costly network tools for network monitoring and troubleshooting
Time-consuming processes that require low-level details as inputs
Figure 2-11 provides a graphical representation of this list.

Figure 2-11: Current troubleshooting tools challenges

HP Network Visualizer benefits


As Figure 2-12 explains, the HP Network Visualizer Application provides visibility of network traffic
and offers a flexible solution for obtaining copies of network packets for auditing, verification, and
dynamic troubleshooting purposes.

Figure 2-12: HP Network Visualizer benefits


You can get copies of network packets from multiple source devices and forward captured packets to a
collection device located almost anywhere in the network using a generic routing encapsulation (GRE)
tunnel.

The Network Visualizer dynamically installs OpenFlow rules to monitor the network traffic using the
filter criteria specified by a network administrator via the graphic user interface (GUI). Filter criteria are
specified with SDN policy attributes built on ACL networking match attributes and legacy actions.

Figure 2-13: HP Network Visualizer benefits


As Figure 2-13 illustrates, the Network Visualizer dashboard provides a graphic representation of current
capture session configuration, capture session failures, and discovered devices by type and operating
system (OS).
The dashboard displays the following charts along with a link below Sessions and Capture Sessions.
Failure charts provide additional details:
Sessions
Capture Sessions Failure
Discovered Devices by OS
Discovered Devices by Type

Bluecat DNS director


Domain Name System (DNS) is a highly critical network service that enables device-to-app, app-to-app,
and device-to-device communication. DNS is built on trust and assumes that both the DNS server and its
response can be trusted, making DNS a widely used attack vector and a powerful tool for data
exfiltration.

Figure 2-14: Bluecat DNS director


Traditional network infrastructures not only perpetuate this trust model, but also are mostly designed for
known and trusted corporate-issued devices. Ongoing transformations, such as BYOD, are breaking this
chain of trust, allowing users to connect any device to the network regardless of behavior or network
access.
This combination of trust-as-a-foundation and traditional network infrastructure introduces significant
security risks for both BYOD and non-BYOD networks and represents an ideal environment for DNS to
be used as an attack vector.
Bluecats DNS Director and the HP SDN architecture provide you with programmatic control of your
DNS services to prevent DNS tunneling and ensure secure application access across all devices, through
automated and centrally deployed DNS policies. Figure 2-14 illustrates an SDN architecture that includes
Bluecat and HP VAN SDN Controller.
The solutions centralized network view and dynamically programmable DNS capabilities, combined
with Bluecats DNS Threat Protection, deliver the added agility, security, and scalability required to
support the business demands of your mobile-cloud environment.

Kemp LoadMaster
Network traffic densities are increasingconstantly. The adoption of SDN technology is on the rise for
the powerful control over network infrastructure it offers.

Figure 2-15: Kemp LoadMaster


There will be a transitional period in which the elements of SDN are used alongside traditional
networking technologies and newer overlay solutions. As SDN adoption continues, application delivery
controllers (ADCs) or load balancers will play a critical role in providing the required intelligence for
flexible and increasingly effective network deployments.
In traditional networks, there is no end-to-end visibility of network paths, and applications are not always
routed optimally. The KEMP Adaptive Load Balancer App, integrated with the HP Virtual Application
Network (VAN) SDN Controller solution, solves this problem by making available critical flow pattern
data. This way, applications can be routed dynamically across the most optimal server and switching
infrastructure. (Figure 2-15 provides a SDN architecture that includes Kemp LoadMaster and HP VAN
SDN Controller.)
The KEMP-HP combined SDN solution enables:
Application visibility to network
Network data being pulled by ADC
Adaptive HA load balancing
Dynamic application delivery
The principles of SDN are focused on the lower layers of the network, and load balancers operate chiefly
at L4L7. This puts load balancers in a prime location to bridge the gap that exists between the
application and the network to influence the SDN controller. Upper-layer intelligence can be pushed to
the SDN controller from the KEMP ADC, helping the controller to make better decisions.
Inversely, circuit information can be pulled from the SDN controller across the northbound interface.
This allows the ADC to make better application load-balancing decisions by aggregating its native
application intelligence with the information provided by the SDN controller. The solution focuses on the
latter as a first step to SDN adaptive load balancing.
An important augmentation benefit of the KEMP-HP combined SDN solution is to improve performance

of a new application across existing infrastructure. The KEMP adaptive load balancer applications
RESTful API allows for third-party innovation within the HP VAN topology so that customized solutions
can be tailored to specific enterprise network needs.

HP SDN case studies


HP has multiple case studies available, including the case studies you see in Figure 2-16.

Figure 2-16: HP SDN case studies

SDN example solution: Case studies and request for information


The following scenario provides real-world use cases and case studies that illustrate SDN
implementations in production environments.

Scenario: Request for information


Your manager phones you from the golf course and says: I forgot to mention, we need some good
documentation to help with our SDN presentation. The company leadership is asking for an SDN request
for information (RFI) document and I dont know where to start. Put something together that we can use.
Fortunately, you have found this document on the HP website to help:
Note
Mock RFI for Enterprise SDN Solutions
Direct
HP
link:
1162ENW&cc=us&lc=en

http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA5-

Short link: http://bit.ly/1I0scWT


The mock RFI includes the diagram you see in Figure 2-17, which illustrates the ONFs SDN

architecture:

Figure 2-17: ONF SDN architecture


From the diagram and the mock SDN RFI, you learn several important things.
Northbound API: You learn that, relative to Figure 2-17, the northbound API is the API that enables
communications between the control layer and the application layer.
Southbound API: Also relative to Figure 2-17, you learn the southbound API is the API that enables
communications between the control layer and the infrastructure layer.
Upgrades to support OpenFlow : HP offers a free upgrade of switch software to HPs OpenFlowenabled software (on specific supported switches). Costs other vendors charge may vary.
Virtual and physical switch support: The HP solution supports any standards-based infrastructure.
HP VAN SDN Controller price: The HP VAN SDN Ctrl SW Base SW w/ 50-node E-LTU costs $495
USD (price may change). A demo license is also available.
Management: Intelligent Management Center (IMC) can be used to manage both a HP Software-defined
Network and a traditional non-OpenFlow-enabled network.

Scenario: case studies


The next day back in the office, your manager approaches you and says: We need some practical
examples of SDN in the real world. Get some case studies we can use as references in our presentation.
You recall that you and your manager have already briefly discussed Googles SDN implementation.
Google has been implementing OpenFlow and SDN since 2010.
Both Google and Microsoft presented at the Open Networking Summit 2015 and discussed how they are
using SDN to better manage their networks:
Google wanted to manage networks, servers, and storage as single block units rather than as thousands of
individual devices. It has built its own control plane for network devices rather than using Open Shortest
Path First (OSPF) and other existing protocols. Google therefore uses a central control plane for device

management.
You can watch the following video:
Note
Google (ONS 2015Amin Vahdat)
YouTube: https://www.youtube.com/watch?v=FaAZAII2x0w Unified Wired-WLAN APs only
operate in controlled mode.
You can also recall from your and your managers previous discussion that Microsoft has turned to SDN
to manage its network because of the massive growth and scale it is experiencing with its Azure cloud
offering. Microsoft, in a similar way to what we are discussing, uses applications to program rules via a
controller into switches at the data plane.
You might also want to watch a video about Microsofts implementation:
Note
Microsoft Azure (ONS 2015Mark Russinovich)
YouTube: http://bit.ly/1TFKzYE
Your manager says: But these examples are cloud-based solutions. I need some enterprise examples in
addition to the NSA example I found. Keep looking.
You can use the HP Enterprise Information Library to look at some of the HP case studies:
Note
HP Enterprise Information Library: http://www.hp.com/go/sdn/infolib

Important
The HP Enterprise Information Library is an important URL to bookmark as it contains the latest HP
SDN related documentation: Another important URL to bookmark is http://www.hp.com/sdn
You can jot down a few of the case studies you find:
HP Networking InteropNet Architecture
https://vimeo.com/108016389
Ballarat Grammar (Network Protector)
PDF: http://bit.ly/1M8regF
YouTube: http://bit.ly/1HxJtJ1

Deltion College (Network Optimizer, KEMP load balancer)


PDF: http://bit.ly/1M8riwO
PDF: http://bit.ly/1EarQvj
YouTube : http://youtu.be/i7bkcHyyBBg
YouTube: http://bit.ly/1At0uo0
South Washington Country Schools (Network Protector)
PDF: http://bit.ly/1e3wvba
YouTube: http://bit.ly/1I6QmVa
Via Group (Network Optimizer, IMC)
PDF: http://bit.ly/1CGfDDs
Bama Companies (Network Optimizer, Bluecat, Hyperglance)
PDF: http://bit.ly/1BonZcN
YouTube: http://bit.ly/1gEfZk3
Istanbul Kultur University (Network Optimizer, IMC)
PDF: http://bit.ly/1f8P2no
RMIT University
YouTube: http://bit.ly/1CGePi0
Note
The white paper section of HP Enterprise Information Library contains technical product
information which you may find useful.
Whitepapers: http://www.hp.com/go/sdn/infolib
As you read the case studies you find, you can collect the following customer quotes:
Customer quotes
In delivering frozen dough products to some of the largest retail chains in the world, its important to
ensure that our communication applications are reliable. We are currently deploying Microsoft Lync with
HPs SDN optimizer, which provides a higher performance in terms of user experience and lowers our
overall IT infrastructure cost.
Eric Spille, Manager of Technical Services, The Bama Companies
HP Network Protector SDN Application takes away a lot of the manual labor that we used to do by
ensuring student devices are protected. Weve now added the Kemp application to intelligently manage
network traffic for our SharePoint infrastructure, improving access for all members of our school
community.
Gregory Bell, Head of Technical Services, Ballarat Grammar

As the sole person responsible for managing the sprawling district network infrastructure, I can attest
that HP and SDN are the way forward in the rapidly changing and growing mobile environment.
Jeff Dietsche, Systems and Infrastructure Manager, South Washington County Schools
Once we learned about HP SDN, we decided to start with an entirely new and more innovative network
concept. We now see our network not as a burden that we have to maintain, but as a new realm of
possibility.
Ender Ekici, Head of IT, Istanbul Kultur University

What is NFV?
NFV offers a new way for communications service providers (CSPs) to design, deploy, and manage
networking services.

Overview
By decoupling the network functions from proprietary hardware appliances, as illustrated in Figure 2-18,
CSPs can accelerate the introduction of new, compelling services quickly and cost-effectively. NFV
enables CSPs to reset the cost base of their network operations and create the flexible service delivery
environments they need to drive revenue and reduce costs.

Figure 2-18: Network functions virtualization


The HP OpenNFV Program provides CSPs and their supplierssuch as network equipment providers
(NEPs), independent software vendors (ISVs), and system integrators (SIs)the foundation upon which
to build a dynamic service and network environment. HPs OpenNFV platform accelerates the design,
proof-of-concept, trial, and deployment of new cloud-enabled network services and innovations while
lowering capital expenditures, operating expenditures, and risk.
One lens we can look through to understand the future of NFV is a view on what has happened in
enterprise IT. NFV uses traditional IT virtualization techniques on commodity hardware (compute,
storage, and networking) to consolidate network applications onto industry high-volume servers and
storage, which allows the industry to gain from both cost and innovation dynamics of traditional IT. It is
possible today to use commercial-off-the-shelf IT infrastructure to do complex tasks that have
traditionally required custom hardware builds on specialized application-specific integrated circuit

(ASIC) or digital signal processing (DSP) devices (thanks to recent technologies such as the packet
processing capabilities found in the latest CPUs).
Within enterprise IT applications, server and storage sprawl and complexity cause most organizations to
spend more than 70% of their budgets and resources on maintenance and operationsand less than 30%
of their time and money on innovation, the things that help the business be more competitive. As a result,
most IT organizations have seen a widening gap between what the business demands and what IT can
deliver. They lack the agility to respond to business requests in a timely manner.
At HP, we believe that the only way for enterprise IT and networks to shift resources from operations to
innovation is through infrastructure convergence. Therefore, we are developing the blueprint for the data
center of the future, which accelerates the provisioning of IT services and applications by integrating
servers, storage, networking, security, power, cooling, and facilities into shared pools of interoperable
resources, all managed through a common management platform.

Figure 2-19: HP converged infrastructure


Figure 2-19 illustrates the steps organizations must take to achieve infrastructure convergence. The first
step for most organizations has been one of standardizationto increase the quality and speed of IT
service delivery with lower cost of operations and better, more efficient management. This could include
moving to a small number of approved standard configurations that are based on industry standards with
reusable components and implemented in a consistent fashion with consistent management tools. The end
result of this step is a more standards-based, modular, and reusable infrastructure.
The second step for IT has been one of virtualization, moving from physical server, storage, and
networking environments to virtualizing the entire data center, increasing the QoS delivered, and making
IT more responsive and aligned to the needs of the business.
What virtualization and automation have achieved in the data center is what NFV aims to achieve for the
revenue-generating applications run by CSPs. Thus, NFV will build on the journey that enterprise IT has
undertaken. Virtualization is a step on the journey to cloud, and in the world of enterprise IT, applications

are evolving to services, and the role of the CIO is evolving to become that of a service broker.

NFV versus SDN


NFV is complementary to SDN, although NFV can be implemented without SDN. SDN allows IT and
network operations to apply business logic directly to emerging software-based networks and
dynamically introduce new services faster with lower management costs and with less complexity. SDN
unlocks overprovisioned, underutilized, and constrained networks to gain value from them. It enables
network simplification by abstracting away complexity.
NFV and SDN can be combined to create greater value as SDN extends to the network infrastructure the
agility that server virtualization brings to the compute infrastructure. HP foresees that functions being
virtualized today eventually become virtualized network services within a SDN architecture.
Demonstrating in-depth integration of the two is a key requirement fulfilled within the HP architecture.
Table 2-1 provides an NFV and SDN comparison:
Table 2-1: NFV and SDN comparison
Network functions virtualization (NFV)

Software-defined networking (SDN)

By leveraging standard IT virtualization technology


to consolidate many network equipment types onto
industry-standard high-volume servers, switches,
and storage, NFV provides a model to meet CSP
challenges around reducing capital expenditures
(CapEx), improving manageability, decreasing
time-to-market, and encouraging a wider ecosystem.

SDN enables the emerging software-based


networks that allow IT and network operations to
apply business logic directly and dynamically to
introduce new services faster, lower management
costs with less complexity, and commoditize many
network functions, reducing CapEx. SDN is an
enabling technology that challenges current
practices by decoupling the control plane from the
data-forwarding mechanisms.

Note
For more information about NFV, visit: http://www8.hp.com/us/en/cloud/nfv-overview.html

SDN in the Data Center and Cloud


Overview
From enterprise to service providers, IT customers require tailored network virtualization solutions that
fit specific business outcomes. To meet this unique requirement, HP provides a three-part offering that
frees you from legacy networks, improves your service velocity, and lowers cost.

Figure 2-20: SDN in the data center and the cloud


Built on the industrys most comprehensive network virtualization portfolio and backed by world-class
service and support, HP is uniquely positioned to navigate you safely through this technology and
business transformation.
Each of the solutions you see in Figure 2-20 provides an open, standards-based foundation for customers
to (optionally) move toward broader SDN application deployment. HPs open SDN ecosystem and HP
SDN App Store help customers to quickly drive bottom-line value and improve end-user application
experience.
Note
If you would prefer watching videos, the following videos provide a great overview of the SDN
solutions discussed in Chapters 1 and 2 of this study guide. Videos 19 to 33 cover data center and
cloud SDN solutions: SDN (An introduction) http://bit.ly/1MwN0sr

Virtual Cloud Networking (VCN)


In June 2014, HP announced the Virtual Cloud Networking (VCN) SDN application and its integration
into HPs Helion OpenStack distribution. VCN offers an OpenStack Neutron distribution with unique
enhancements such as multihypervisor support, distributed virtual routing, HA, Virtual Extensible LAN
(VXLAN) gateway, VPN as a service (VPNaaS), and security group enhancements. It also provides
improved scalability. Many of these enhancements have been contributed back to the open source
community.
HP is now a top contributor to OpenStack Neutron, with ongoing work planned to support additional

hypervisors, bare metal functions, service chaining, and SDN application integration to support network
and security operations.

HP-VMware networking solution (NSX Federation)


The HP-VMware networking solution delivers an interoperable SDN and network virtualization solution
that provides customers unified automation and visibility into virtual and physical networks in VMware
centric data centers. The solution combines the HP VAN SDN Controller and VMware NSX network
virtualization platform through federation APIs to deliver SDN automation across physical and virtual
data center networks.
Note
HP Networking Chief Technologist, Mark Pearson, and VMware Engineering Architect, Scott
Lowe, recently discussed this codeveloped solution at VMworld SFO 2014
http://youtu.be/ejhyte5e7YY

HP Distributed Cloud Networking (DCN)


With HP DCN, large enterprises and service providers can unify private, public, and hybrid data centers
through SDN. DCN helps communication service providers (CSPs) accelerate their journeys to NFV by
optimizing network resources, increasing agility, and speeding time-to-market through dynamic, servicedriven configuration.
Note
For more information about HP SDN network virtualization, visit the following:
http://www8.hp.com/us/en/networking/sdn/network-virtualization.html

HP-VMware networking solution


Overview
HP and VMware are collaborating to provide the industrys first interoperable SDN solution. As
illustrated in Figure 2-21, the solution federates the HP VAN SDN Controller with the VMware NSX
network virtualization platform to provide customers with an integrated approach for automating their
physical and virtual network infrastructures.

Figure 2-21: The HP-VMware networking solution

Network virtualization
SDN, as defined by the ONF, is the physical separation of the network control plane from the forwarding
plane and where the control plane controls several devices. When it comes to network virtualization, the
SDN approach allows the network provider to integrate physical and virtual environments; and, if done
correctly, it also unlocks never-before realized capabilities, intelligence, and visibility. Network
providers have a choice in how this integration is accomplisheda choice that has direct implications on
whether they will merely solve their network virtualization problems or whether they will place
themselves on a path to unlock the full potential of an intelligent, SDN-enabled converged infrastructure.
There is no standard that defines network virtualization. One of the better definitions is Gartners
definition:
Network virtualization is the process of combining hardware and software network resources and functionality into a single virtual network.
This offers access to routing features and data streams that can provide newer, service-aware, resilient solutions; newer security services that
are native within network elements; support for subscriber-aware policy control for peer-to-peer traffic management; and application-aware,
real-time session control for converged voice and video applications with guaranteed on-demand bandwidth.

(http://www.gartner.com/it-glossary/network-virtualization)

VMware
VMware led the industry into a new virtual computing era in the data center. Virtual machines (VMs),
services, and workloads are now being brought up and down continually, which has led to a new level of
automation not seen before. As virtualized data centers grew, virtualized workloads began to span
multiple server racks that were spanning across a large networking domain. These virtualized workloads
also needed virtual domains to exist to provide logical traffic separation. They expanded past the server
into the network in the form of VLANs. The need for a large number of VLANs began to grow along with
the growth in workloads moving to virtualized environments, and this started to expand past the limit
allowed on the network. Also, the rise in moving VMs from one server to another, VM mobility, created a
requirement on the networking infrastructure to support the movement of IP/MAC addresses across the
network infrastructure. Further, leaving everything to hardware slows the rapid pace of innovation
allowed in software.
To address the requirements for automation, large numbers of virtual domains, and VM mobility, there
were several decisions to be made. New networking technologies, such as Transparent Interconnection of

Lots of Links (TRILL), created one flat layer-2 domain across the network and alleviated the VM
mobility problem. This left the issues of automation and VLAN scale. PBB originally started to address
the scale issue with MAC-in-MAC encapsulation. However, it addressed only part of the problem and
along with TRILL did not address the real need to move to a software-defined strategy to unlock faster
innovation that the network has lacked.

Overlay and underlay networks


To address the VLAN scale within the timeframes and flexibility required by rapidly scaling public
clouds, Virtual Extensible LAN (VXLAN) was created to provide established tunnels between endpoints
with a large scale of virtual domains. VXLAN created a new header to the packets forming tunnels
between physical and virtual endpoints. The overlay was managed through a communication and control
protocol on the physical network, and it happened largely independently of the actual virtual environment.

HP and VMware
With VAN SDN and NSX federation, HP and VMware are enabling organizations to:
Unify virtual and physical devices
Bridge virtual and physical networks
Simplify network lifecycle management
Deploy additional bandwidth rapidly
Provide end-to-end visibility into availability and performance
Rapidly identify network problems, analyze them, and troubleshoot to resolve them
As shown in Figure 2-21, key components of the solution include:
VMware NSX network virtualization platform
Federation APIs
HP Virtual Application Networks (VAN) SDN Controller
HP IMC SDN Manager
HP IMC with vCenter plug-in
HP Converged Control SDN application
HP FlexFabric 5930 Top-of-Rack Switch
HP IMC with SDN Manager and integrated VMware vCenter plug-in provide a single pane-of-glass
management for both virtual and physical networks. The solutions allow organizations to control the
entire data center network.

VMware NSX
As Figure 2-22 illustrates, the VMware NSX network virtualization platform allows you to create a
network completely in software, and this virtual network overlays your physical network.

Figure 2-22: VMware NSX


You create a virtual network by defining a logical switch, which provides Layer 2 services on the virtual
network. You can attach VMs to the logical switch and configure additional network services, such as
Logical routers
Logical firewalls
Logical load balancers
Logical virtual private networks (VPNs)
When a VM that is attached to a logical switch sends traffic, the NSX switch checks the ingress rules and
determines how the traffic should be handled. If the traffic is allowed, the NSX switch encapsulates it and
sends it across the physical network to the destinationwhich is another NSX switch. The destination
NSX switch checks its egress rules to ensure the traffic is allowed. If the traffic is allowed, it is
forwarded or routed to the appropriate VM.
Like other VMware products, VMware NSX allows you to easily move the VMs. If you move a VM from
one physical host to another, the network services that you have defined for the VM move with it.
VMware NSX is policy based: that is, you can create policies and apply them to VMs. This allows you to
easily provision VMs as they are added to the logical network environment.

Integration and communication


The federation APIs provide the framework for integrating the HP VAN SDN Controller and the VMware
NSX network virtualization platform. Through the federation APIs, the HP VAN SDN Controller
integrates with VMware NSX to deliver SDN applications across virtual networks. Applications can
query the federation APIs and receive information from the applicable application within the solution.
VMware NSX uses the Open vSwitch Database (OVSDB) management protocol to communicate with the
HP VAN SDN Controller, which supports OVSDB. A component of Open vSwitch, the OVSDB
management protocol enables management of open source virtual switches. Essentially, the OVSDB
management protocol manipulates a set of tables containing switch configuration data. (Designed for

virtualized server environments, Open vSwitch forwards traffic between VMs on the same server
hardware, eliminating the need to send the traffic to the physical network for handling. If VMs send traffic
to other destinationsnot on the server hardwareOpen vSwitch forwards that traffic to the physical
network, typically a switch. Open vSwitch is licensed under open source Apache 2.0.)
Using OVSDB, VMware NSX shares virtual tunnel state information with the HP VAN SDN Controllers
centralized control plane. VMware NSX also uses OVSDB to set up virtual network tunnel endpoints on
physical network devices such as the HP FlexFabric 5930 Switch with Virtual Extensible LAN
(VXLAN). VXLAN is an encapsulation protocol that supports virtual networks across Layer 3 networks.
VXLAN adds a 24-bit segment ID to the Ethernet frame. VXLAN enables you to set up as many as 16
million virtual networks across a Layer 3 network.
Note
For more information about the HP-VMware networking
http://www8.hp.com/us/en/networking/sdn/network-virtualization.html

solution,

visit:

HP Virtual Cloud Networking


Cloud computing is increasingly attractive to businesses because of the agility, cost savings, and
efficiency it provides. However, these same businesses are finding themselves limited by the complexity
and disjointed architectures of legacy networks: not only are legacy networks complex, they are also
slow to provision new services and are labor intensive. They do not have the agility to meet the
challenges of The New Style of Business, characterized by the interrelated trends of cloud, security,
mobility, and big data.

Figure 2-23: HP Virtual Cloud Networking (VCN)


To meet the constantly evolving needs of your customers, you need a network infrastructure that works
with you, not against youone that not only is agile enough to deliver robust and scalable services but
also simple enough to lower costs and limit complexity.
The HP VCN SDN application can help you do just that. The HP VCN SDN application is the enhanced
networking module of HP Helion OpenStack (see Figure 2-23), delivering network virtualization enabled
by SDN and orchestrating the entire data center infrastructure.
The VCN SDN application helps cloud providers and enterprises build a robust multitenant networking
infrastructure that is able to deliver ready-to-use compute, storage, and networking. It provides:

Scalable, secure, and hardened enterprise cloud networking


Complete access to an open SDN ecosystem that includes HP and third-party SDN applications
The HP VCN SDN application integrates with the HP VAN SDN Controller and leverages OpenFlow to
create a unified control for the deployment of dynamic policy on both the virtual (Open vSwitch) and
physical (HP and third-party) networks.
VCN provides a multitenant network virtualization service for Kernel-based Virtual Machine (KVM) and
VMware ESX multihypervisor data center applications, offering organizations both open source and
proprietary solutions. Multitenant isolation is provided by centrally orchestrated VLAN or VXLANbased virtual networks operating over standard L2 or L3 data center fabrics.
Bare-metal (nonvirtualized) servers and appliances can be supported in a VXLAN environment with the
addition of HP 5930 switches to provide the hardware tunnel endpoint function. In a fully virtualized
deployment, the existing data center switching infrastructure can be retained without the need for costly
upgrades. OpenFlow 1.3enabled devices are recommended to realize the full benefit of SDNbased data
center applications.

HP VCN components
To understand how HP VCN works, you must understand its components, which you see illustrated in
Figure 2-24.
The HP VCN application itself resides on the HP VAN SDN Controller as an internal application. It can
consume all of the controller services, such as flow management, packet listening, business logic
processing, data persistence, and HA.

Figure 2-24: HP VCN components


The application uses RESTful APIs to communicate with an HP VCN Plug-in on the OpenStack
controller. HP offers an enterprise-ready OpenStack-compliant controller, which you will learn about in a
moment, but customers can install the HP VCN Plug-in on any OpenStack controller they choose.

The HP VAN SDN Controller provides the Neutron L2 Agent and L3 Agent APIs. These APIs let HP
VCN communicate with VCN agents installed on virtual hosts. Each compute node hosting VMs requires
a VCN Compute Node (CN) agent, and each network node hosting virtual network appliances requires a
VCN Network Node (NN) agent.
When HP VCN receives provisioning requests from the OpenStack controller, HP VCN uses its built-in
business intelligence and knowledge of the infrastructure to construct a plan for executing the request. It
then programs the proper settings by making RESTful API calls to the CN and NN agents. It can use
platform services to alter traffic flows on the physical infrastructure, if required.

HP Helion OpenStack and CloudSystem


In many enterprises, IT is on the defensive, reacting to problems and putting out fires. But what if you
could turn the tables and make your IT department a proactive force that creates solutions and guides the
company into the future?
Now you can. Built on a foundation of OpenStack technology, HP Helion boosts your organizations
productivity so that you can make the most of your IT budget and give your developers the power to
deploy new applications faster than everall while keeping your data as available and secure as it
should be.

Figure 2-25: HP Helion OpenStack and CloudSystem


As Figure 2-25 suggests, HP Helion OpenStack is an open and extensible scale-out cloud platform for
building and consuming hybrid clouds. This solution is a hardened and curated commercial-grade product
designed to deliver open-source cloud computing technology in a resilient, maintainable, and easy to
install solution.
Open: Move, integrate, and deliver applications across any environmentpublic, private, traditional IT,
or a hybrid combination. And because HP believes in an open community, you can choose from a vast
global ecosystem of hardware, software, and services for your cloud computing needs.
Agile: HP Helion gives you the flexibility to deploy applications and cloud solutions in minutes. That
cool new product or service? Launch it. That cost-saving business process? Roll it out. Add users.
Subtract users. Pay as you go, or pay for what you use.
Secure: With HP Helion, you are safe in knowing that all products and services provide the visibility,

control, and governance you need across a hybrid environment. Plus, we deliver world-class security and
reliability scalable to millions of nodes.
Note
For more information about HP Helion, please visit: http://www8.hp.com/us/en/cloud/helionoverview.html

HP Distributed Cloud Networking (DCN)


Figure 2-26 illustrates the antithesis of what service providers and large organizations need to build
distributed, scale-out, multidata center environments in a simple, standard, and agile method using SDN
and networking virtualization. HP DCN, on the other hand, is exactly what they need. It is a complete and
comprehensive networking solution that virtualizes existing data centers and allows network resources to
be easily controlled with a la carte management platforms such as HP CloudSystem, OpenStack,
CloudStack, or vCenter.
Leveraging the programmability of business logic and policy engines, the platform allows an open and
agile solution that scales to solve the stringent needs of multitenant DCs. Using the full ecosystem of HP
SDN application partners, HP DCN allows third-party features and functions to enrich networking
capabilities.

Figure 2-26: HP Distributed Cloud Networking (DCN)


The solution is composed of a network layer both physical and virtual, a control layer with federated
controllers that can interconnect using Border Gateway Protocol-Multiprotocol (BGP-MP) within and
across data centers, and a service directory layer with advanced, programmable policies, and analytics
where IT administrators can define, visualize, and control the network without being burdened by
network implementation details. They can implement security, load balancing, and user access policy
with a high level of abstraction, instead of manual command line interface (CLI) and IP address
assignment. Once defined, these policies can dynamically be used to govern network behavior on an asneeded basis triggered by compute instance creation, migration, and deletion. It also provides extensive

service insight with an analytics engine based on Hadoop technology that collects and stores per tenant,
per VPN, and per VM statistics.
HP DCN provides business agility while controlling infrastructure costs. It uses embedded advanced
networking features that select the fastest path to help optimize bandwidth usage and latency automatically
while decreasing the bottleneck of external routers or gateways.

HP Distributed Cloud Networking (DCN)


Overview
As Figure 2-27 illustrates, HP DCN provides a foundation that enables service providers and large
organizations to manage a distributed, multidata-center environment in a simple, open, and agile way
using software-defined networking and network virtualization. With underlay and overlay networks fully
integrated, you can lower total cost of ownership (TCO) by combining intelligent workload management
with policy automation.

Figure 2-27: HP Distributed Cloud Networking (DCN)


DCN is also accelerating communication service providers journeys to NFV by optimizing network
resources, increasing agility, and speeding time-to-market through dynamic, service-driven configuration.

Features
Unify private, public, and hybrid data centers with SDN
Through SDN and network virtualization, HP DCN enables network administrators to control the
distributed network environment from one central location, whether the organization incorporates private,
public, or hybrid data centers. It:

Supports policy-based network provisioning to automate and speed application deployments


Deploys distributed, data center networks in minutes vs. months
Operate multiple data centers into a single point of management
HP DCN has plug-ins available for OpenStack, CloudStack, HP Cloud OS, and HP Helion for increased
flexibility in your choice of environments.
New applications are onboarded quickly through application-centric service definition and creation that
is decoupled from network-centric implementation details.
Perapplication views for self-service establishment of network services are automatically in line with
enterprise security policies and the applications business logic.
Provides business agility while controlling infrastructure costs
HP DCN is a full layer 2 to layer 4 virtualization platform that optimizes the network by removing
inefficiencies.
It automatically selects the fastest path to optimize bandwidth usage and latency while decreasing the
bottleneck of the external router or gateway.
Policy functions align network deployment with application needs in an automated way, offering users the
ability to configure the network in an application friendly way.

DCN: Solving the following table stakes


What is needed to support such networking functionality? As Figure 2-28 illustrates, the answer is this:
AbstractionNetwork connectivity should be able to function without any physical binding to the
underlying network. It should provide similar functionality to that of VLAN, abstracting physical
network provisioning.
AutomationEndpoint to endpoint network provisioningmultiple endpointsvirtual and physical,
within and across data centers.
ControlClear separation of network segments and security enforcement policies.
VisibilityEndpoint to endpoint network performance view from capacity planning and debug
perspective.

Figure 2-28: DCN: Solving the following table stakes

Summary
In this chapter, you were introduced to various HP SDN applications for the campus, data center, and
cloud. You learned about the HP SDN App Store, the various circles available in the SDN App Store,
and various applications available in the App Store.
We briefly discussed the following applications and solutions:
ODL SDN Controller
HP Network Protector SDN Application
HP Network Optimizer SDN Application for Microsoft Lync
HP Visualizer SDN Application
HP VMware NSX federation
HP VCN
HP DCN
HP has multiple SDN solutions and applications to meet the needs of business in the campus, data center,
and cloud.

Chapter 3
HP VAN SDN Controller Overview
EXAM OBJECTIVES
In this chapter you will learn to:
Describe HP VAN SDN Controller hardware and software requirements.
Describe controller modes.
Explain the process for downloading and installing the HP VAN SDN Controller software.
Install an HP SDN application from the HP SDN App Store.
Verify the successful installation.
Integrate Mininet with the HP VAN SDN Controller and use Mininet to create a virtual switching
network.
Integrate HP switches with the HP VAN SDN Controller.
Describe the HP VAN SDN Controller graphical user interface (GUI).
Update flow entries on OpenFlow switches using an SDN application.

Assumed knowledge
HP Comware and HP ProVision switch command line interface (CLI)
IP addressing
Basic routing protocols
Basic Internet protocols

Introduction
This chapter introduces the HP Virtual Application Network Software-Defined Networking (VAN SDN)
Controller, which is a Java-based software-defined networking (SDN) controller. The HP VAN SDN
Controller software is installed on a system running Ubuntu version 12.04 LTS 64-bit server and provides
a platform for developers to write applications that interact with and program OpenFlow enabled
networks.
This chapter also introduces Mininet, which uses Open vSwitch, an open source, OpenFlow-enabled
software switch.

Overview of the HP VAN SDN Controller

Introduction
The HP VAN SDN Controller provides a unified control point in an OpenFlow-enabled network,
simplifying management, provisioning, and orchestration and enabling delivery of a new generation of
application-based network services.
In the HP SDN architecture (see Figure 3-1), the control and data planes of the network are decoupled,
centralizing network intelligence and abstracting the underlying network infrastructure from applications.
Controller software directly provisions physical and virtual switches under its control via the industrystandard OpenFlow protocol. Network ports, links, and topologies are all directly visible, enabling
centralized policy administration and more effective path selection based on a dynamic, global view of
the network.

Figure 3-1: Overview of the HP VAN SDN Controller


This dramatically simplifies the orchestration of multitenant environments and the enforcement of network
policy for both mobile clients and servers.
The HP VAN SDN Controller is designed to operate in a variety of computing environments, including
campus, data center, service provider, private cloud, and public cloud. The HP VAN SDN Controller
features:
An enterprise-class platform for the delivery of a broad range of network innovations
Extensible, scalable, and resilient controller architecture
Compliance with OpenFlow 1.0 and 1.3 protocols
Support for HP ProVision, HP Comware, and Open vSwitch OpenFlow-enabled switches
Secure authentication using a local or a remote Keystone server

Controller teaming for distributed platform high availability (HA) and scalability
Embedded applications that provide common network services
Open APIs to enable third-party SDN application developers to deliver innovative solutions to
dynamically link business requirements to network infrastructure using either custom Java programs
or general-purpose RESTful control interfaces, including functions to extend the controller
Representational State Transfer (REST) API and UI

Embedded applications
The HP VAN SDN Controller includes a default set of core network service applications that are
installed as modules on the controller. The following applications are embedded in the controller and are
installed when you install the controller:
OpenFlow Link Discovery
OpenFlow Node Discovery
Path Daemon
Path Diagnostics

Controller architecture
The HP VAN SDN Controller is designed as a platform for custom solutions and extended functions. The
controller provides Java and REST API interfaces for applications to interface with and to program the
network.
The HP controller software is built upon off-the-shelf Ubuntu Linux, Java 1.7, and OSGi (Virgo stack and
Equinox framework). The HP stack resides on top of these platforms.
Components that make up the HP VAN SDN Controller include:
Keystone: Keystone is an external service that provides authentication and high-level authorization
services. It supports token-based authentication, which is used to secure the RESTful web services
(REST APIs) and the web user interfaces.
Important
Ubuntu usernames and passwords are not used for controller GUI and API authentication. Keystone
is used for identity management and is separate from Ubuntu authentication mechanisms.
REST API Shell/Framework : In the REST architectural style, data and functionality are considered
resources, and these resources are accessed using Uniform Resource Identifiers (URIs), typically
links on the web. REST-style architectures conventionally consist of clients and servers, and they are
designed to use a stateless communication protocol, typically HTTP. Clients initiate requests to
servers; servers process requests and return appropriate responses. Requests and responses are built
around the transfer of representations of resources. Clients and servers exchange representations of
resources using a standardized interface and protocol. These principles encourage RESTful
applications to be simple, lightweight, and have high performance.
GUI Shell/Framework: The HP VAN SDN Controller also offers a framework to develop web-based

user interfaces: the SKI Framework. For more information, refer to the HP VAN SDN Controller 2.5
Programmers Guide.
PostgreSQL : PostgreSQL is used for persisting controller and application data.
App Deployment: The controller Application Manager enables installing, upgrading, enabling
(starting), disabling (stopping), and uninstalling SDN applications on the controller.
Audit Log: The audit log records events related to activities, operations, and configuration changes
initiated by an authorized user. The audit log is managed by the controller audit log service.
Alerts: The alert log records information about events that affect controller operation and, in some
cases, indicate that some action is needed to correct a condition. Alerts are managed by the controller
alert service.
Topology: The controller uses the embedded applications Topology Manager and Topology Viewer to
collect and display information about the OpenFlow network.
Backup and restore framework (not shown): The HP VAN SDN Controller provides a framework to
back up and restore controller and application state in a backup file. The backup file can be copied
and stored for later use. The stored backup file can be uploaded to the controller.
Distributed Coordination Framework: The Distributed Coordination Framework is one of the highavailability features of the controller. It provides the infrastructure for controller-to-controller
communication and coordination of state information for controllers in a controller team.
Teaming:The HP VAN SDN Controller can be configured in a team. The teaming services of the
controller keeps the runtime state of each controller in the team (active, unreachable, or suspended) up
to date and is used by other parts of the controller for functions related to HA.
Device Drivers: The device drivers model the capabilities of the devices and provide APIs for
interacting with different device types.
Discovery: The controller uses the embedded applications OpenFlow Link Discovery and OpenFlow
Node Discovery to discover information about the OpenFlow network.
OpenFlow Controller: The OpenFlow controller (also called the core controller) handles the
connections from OpenFlow devices and provides the means for upper layers of software to interact
with these devices.
Cassandra: Apache Cassandra is a high-performance, extremely scalable, fault-tolerant (no single
point of failure), distributed postrelational database solution. Cassandra combines all the benefits of
Google Bigtable and Amazon Dynamo to handle the types of database management needs that
traditional RDBMS vendors cannot support. Cassandra is used for persisting application data.
OSGi (Virgo/Equinox): The principal software stack of the controller uses an OSGi framework
(Equinox) and a container (Virgo) as a basis for modular software deployment and to enforce service
provider/consumer separation. The software running in the principal OSGi container can interact with
other components running as other processes on the controller. Virgo, based on Tomcat, is a chapterbased Java application server that is designed to run enterprise Java applications with a high degree
of flexibility and reliability.

Note
For information, see the HP VAN SDN Controller 2.5 Administrator Guide:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647289 and HP VAN SDN
Controller 2.5 Programming Guide: http://h20564.www2.hpe.com/hpsc/doc/public/display?
docId=c04647292

HP VAN SDN Controller documentation


A large amount of useful and in-depth technical information is available on the HP website and links to
documentation will be provided throughout this study guide.
Caution
SDN is a rapidly changing technology area. It is good practice to refer to the HP website for the
latest information.
Examples include
HP Enterprise Information Library:
http://www.hp.com/go/sdn/infolib
HP VAN SDN Controller and Applications Support Matrix http://bit.ly/1fG72pG
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647298
HP VAN SDN Controller 2.5 Installation Guide:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647290
HP VAN SDN Controller 2.5.20 Release Notes:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647293
HP VAN SDN Controller 2.5 Programming Guide:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647292
HP VAN SDN Controller 2.5 REST API Reference:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647295
Download software:
http://bit.ly/1H7h1Rg

HP VAN SDN Controller installation instructions


This section includes instructions for installing HP VAN SDN Controller. It also includes the
preinstallation information that comes from the HP VAN SDN Controller support matrix. We will use IP
addresses in Figure 3-2 in installation examples.

Figure 3-2: Example topology


Installation of the HP VAN SDN Controller software and prerequisites requires Internet connectivity from
the HP VAN SDN Controller server.

Installation resources and instructions


Installation Guide
The HP VAN SDN Controller installation process may vary depending on which version you are
installing. It is good practice to review the installation guide before installation.
Visit the following URL to review the Installation Guide and answer the questions below:
Note
HP
VAN
SDN
Controller
2.5.20
Installation
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647290

Guide:

To download the HP VAN SDN Controller software:


1. Go to the HP Networking support site at www.hp.com/networking/support.
2. Enter the HP VAN SDN base product number J9863AAE in the Auto Search field.
3. Select the check box next to the HP VAN SDN Controller product and then click Display selected.
4. In the lower right quadrant of the product display screen, click Software downloads.
5. On the My Networking Download software screen, select and download the
VAN_SDN_Controller_v2.5.X software package (.zip file) to your local computer.

6. Unzip the software package.

Direct link
You could also use the following direct link:
Note
HP
VAN
SDN
Controller
2.5.20
Installation
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647290

Guide:

Installation videos
Various videos are available to demonstrate the installation and configuration of the HP VAN SDN
Controller and Mininet on VirtualBox. This allows you to install and configure an OpenFlow-enabled
network on a laptop or PC for learning purposes.
Figure 3-3 displays steps for installing a controller with a local Keystone server. It also launches a video
that explains these steps.

Figure 3-3: New install with a local Keystone server


Figure 3-4 launches an Augmented Reality video that explains how to download and install Virtual Box
and Ubuntu.

Figure 3-4: Installing the Keystone server


Figure 3-5 launches an Augmented Reality video that discusses how to create a virtual network to test
switches using Mininet.

Figure 3-5: Installing the Keystone server (continued)


Figure 3-6 launches a video that enables you to view more information about installing and configuring
the HP VAN SDN Controller.

Figure 3-6: Unpacking the controller software


Other figures in this chapter that launch Augmented Reality videos are:
Figure 3-11, which explains how to install the controller after youve completed pre-installation steps
Figure 3-20, which provides a Mininet overview
Figure 3-39, which explains how to install SDN applications on the controller

Support matrix
Before installing the HP VAN SDN Controller, review server and network requirements by reviewing
sections of the Support Matrix document. This guide includes answers to several support-related
questions. For answers to additional questions, visit the following URL to download the document:
Note
HP
VAN
SDN
Controller
and
Applications
Support
Matrix:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647298 or http://bit.ly/1H7h1Rg

Questions
Following is a series of questions and answers to help you remember some of the important bits of
information you have learned in this section.
Question:Which operating system does the HP VAN SDN Controller require (page 7)?
Answer:As of version 2.5 of the HP VAN SDN Controller, the only supported operating system is Ubuntu
12.04 LTS 64-bit Server.
Question:Can the controller run as a virtual machine? Which hypervisors are supported (page 7)?
Answer:Yes. Supported hypervisors (if operating system is run on a virtual machine):
KVM Version 2.4.5-1 and greater
ESXi Versions 5.0.0 and greater
Question:Which software is automatically installed as part of the HP VAN SDN Controller installation
process (page 7)?
Answer:The following software is installed automatically as part of the version 2.5 HP VAN SDN

Controller installation process:


The most recent patch of OpenJDK version 7.
The Open Java Development Kit is a free and open source implementation of the Java Platform.
PostgreSQL 9.1
A database server that is an object relational database management system.
Keystone Identity 2012.2.1 or later versions that support the v2 API and the UUID provider type
An Open Stack project used for authentication and authorization. Keystone supports token-based
authentication.
Question:Which web browsers are supported by the HP VAN SDN Controller (page 8)?
Answer:When connecting to a version 2.5 HP VAN SDN Controller, only Google Chrome 41.0.2272.89
and Firefox 36 are supported; in addition, only the following operating systems are supported with the
browser:
Ubuntu 12.04
Windows Server 2008 R2 Enterprise
Windows 7 and Windows 8
Note
Read the important notice on page 8 regarding web browser support.
Question:OpenFlow will be discussed in more detail later in this study guide. However, which versions
of OpenFlow are supported by the HP VAN SDN Controller (page 8)?
Answer:OpenFlow versions 1.3.2 and OpenFlow 1.0.1 are supported. Switches may negotiate to use
different versions with the same HP VAN SDN Controller.
WARNING
When controller teaming is configured, OpenFlow 1.0.1 is not supported. See the teaming chapter
for more information
Question:OpenFlow-only and Hybrid modes will be discussed later in the study guide. Which HP
ProVision and Comware switches are supported in OpenFlow-only mode with the version 2.5 Controller
(page 10)? Has this changed in the latest version of the HP VAN SDN Controller?
Answer:Version 2.5 Controller OpenFlow-only support:
ProVision switches supported: 2920, 3500, 3800, 5400zl, 5400R, 6200, 6600, 8200zl
Comware switches supported: 5130, 5500EI, 5500HI, 5900, 5920, 5930, 10504, 12508, 12910 EA,
12910 EB, 12910 EC, 12910 FC.
At the time of this writing, version 2.5 of the Controller is the latest release. This may change.

HP VAN SDN Controller installation check


Following are steps you can take to verify your HP VAN SDN Controller installation. Example IP
addresses and other particulars are taken from the example topology at the beginning of this section
(Figure 3-2).

Instructions
You will need a terminal emulator if you plan to follow along using trial versions of the software.
Following are instructions for using PuTTY, which you can download from www.putty.org and install on
your laptop or desktop.
1. Double click the PuTTY shortcut on the Windows desktop to open a new Putty session. Figure 3-7
displays a screen capture of the shortcut:

Figure 3-7: PuTTY shortcut


2. Connect to the HP VAN SDN Controller server using SSH. Figure 3-8 displays a screen capture of the
PuTTY configuration interface with the following settings:
IP address: 192.168.56.11
Port number: 22
Protocol: SSH

Figure 3-8: SSH to the controller Ubuntu server


3. If prompted, click Yes to accept the server public key, as illustrated in Figure 3-9:

Figure 3-9: Accept public key


4. When prompted, login with the following credentials:

Username: sdn
Password: skyline
The Ubuntu session should display a confirmation that looks something like the following example:
login as: sdn
sdn@192.168.56.11's password:
Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.13.0-32-generic x86_64)
* Documentation: https://help.ubuntu.com/
Last login: Thu Jun 18 13:50:29 2015 from 192.168.56.5
sdn@sdnctl1:~$$

5. Use the sudo dpkg -l hp-sdn-ctl command to check if the HP VAN SDN Controller software is
installed (enter a password if prompted):
Result if the controller software is not installed:
sdn@sdnctl1:~$ sudo dpkg -l hp-sdn-ctl
[sudo] password for sdn:
No packages found matching hp-sdn-ctl.
sdn@sdnctl1:~$

Result if the controller software is installed:


sdn@sdnctl1:~$ sudo dpkg -l hp-sdn-ctl
[sudo] password for sdn:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================
ii hp-sdn-ctl 2.5.15.1175 HP VAN SDN Controller
sdn@sdnctl1:~$

A value of ii in the left-most output indicates that the software has installed correctly.

Questions
Following is a series of questions based on the installation information we have discussed so far:
Question 1: Which operating system is required by the HP VAN SDN Controller?
_________________________________________________________________
Question 2: Which versions of OpenFlow does the HP VAN SDN Controller support?
_________________________________________________________________

_________________________________________________________________
Question 3: Which service provides user authentication in the HP VAN SDN Controller?
_________________________________________________________________
_________________________________________________________________
Question.4:Which database is used for persisting controller and application data?
_________________________________________________________________
Question 5 : Which SDN applications are discussed in the support matrix?
_________________________________________________________________
_________________________________________________________________
Question 1 answer
The supported operating system is Ubuntu 12.04 LTS 64-bit Server
Question 2 answer
Supported versions of OpenFlow:
OpenFlow 1.3.2
OpenFlow 1.0.1
Question 3 answer
The HP VAN SDN Controller uses OpenStack Keystone as an identity management service for managing
users, generating tokens, as well as token validation.
Keystone is an external service that provides authentication and high-level authorization services. It
supports token-based authentication, which is used to secure the RESTful web services (REST APIs) and
the web user interfaces.
Question 4 answer
PostgreSQL is used for persisting controller and application data.
Question 5 answer
HP VAN SDN Controller and Applications Support Matrix (June 2015) discusses the following:
HP VAN SDN Controller
HP Network Optimizer SDN ApplicationMicrosoft Lync
HP Network Protector SDN Application
HP Network Visualizer SDN Application
Later versions may discuss additional applications.

Controller modes
As Figure 3-10 indicates, you can configure controllers to operate in one of two modes. It is helpful if
you decide on an operational mode before you begin the installation process.
Standalone mode(Required) creates a single, standalone controller. Using one standalone controller

in a network does not provide HA and automatic failover. The controller represents a single point of
failure, and if the controller goes down, the network becomes unmanaged.
Team modeCreates a team of HA controllers with automatic failover, resulting in a continuously
managed network in the event that one controller in the team goes down. Teaming three HP VAN SDN
Controller instances together minimizes the impact of a controller failure by providing automatic
failover from the current leader instance to another controller instance.

Figure 3-10: Controller modes


Team mode also provides centralized controller configuration and monitoring.
To operate in team mode, you:
1. Install the software on a single controller as described in this chapter.
2. Repeat the process to install two additional controllers on separate nodes in preparation for team
operation.
3. Configure a group of installed controllers to operate in a team, as described in the teaming chapter.
Note
An HP VAN SDN Controller team consists of three controllers.

Controller authentication
Beginning with controller software release 2.3, the HP VAN SDN Controller supports both local and
remote Keystone authentication servers.
For a new installation, the Keystone server can be installed either locally with the controller, or on a
remote machine.

Note
Keystone provides the OpenStack Identity Service used for controller authentication. For more
information on Keystone operation, see the chapter titled Security Features in the HP VAN SDN
Controller Administrator Guide.
For information on a specific Keystone version, visit http://docs.openstack.org/developer/keystone/
and see the documentation for the OpenStack Keystone version you are using. The controller
supports v2.0 of the Keystone REST API.

New install with a local Keystone server


This section describes installing a Keystone server and the controller on the same (local) machine and
running the configuration script included in the controller download package. Figure 3-11 provides IP
addresses for the examples you will see in connection with this type of installation. Using the local
installation option automatically configures the Keystone server.

Figure 3-11: Example topology with Augmented Reality image for video installation instructions
If you want your controller to operate with a previously configured, remote Keystone server, then refer to
the Installing the controller to operate with a remote Keystone server section of the HP VAN SDN
Controller 2.5 Installation Guide.

Note
HP
VAN
SDN
Controller
2.5.20
Installation
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647290

Guide:

For most controller installations, HP recommends using a local Keystone server as described in this
chapter. Doing so avoids the need to address certain security implications associated with using a remote
Keystone server.
The configured Keystone server must be accessible and responsive to basic Keystone REST API queries.
The controller supports v2.0 of the Keystone REST API.
The first step is to install the local Keystone server as follows:
Update the Ubuntu 12.04 LTS system to latest patches and point the Ubuntu system to the most recent
package meta-data:
~$ sudo apt-get update

Use the following commands to install the Keystone server on the local machine.
~$ sudo apt-get install python-software-properties
~$ sudo apt-get install ubuntu-cloud-keyring
~$ sudo add-apt-repository cloud-archive:icehouse

If the following message appears, press Enter before continuing:


Press [ENTER] to continue or ctrl-c to cancel adding it

Note
HP recommends using the icehouse version of the OpenStack Keystone server, as shown in the
above command. However, you can use any of the following Keystone server options:
icehouse (recommended)
havana
grizzly
folsom

Continue the installation as follows:


~$ sudo apt-get update
~$ sudo apt-get install keystone

For information on a specific Keystone version, visit http://docs.openstack.org/developer/keystone/ and


see the documentation for the OpenStack Keystone version you are using. For information on the keystore
and truststore features, see the chapter titled SDN Controller 2.1 Installing the local Keystone server 9
security features in the latest edition of the HP VAN SDN Controller Administrator Guide.

Unpacking the controller software


This instruction set assumes that the HP VAN SDN Controller software has not been installed previously
on the Ubuntu server. See step 5 in the HP VAN SDN Controller installation check section of this guide
to verify this.
WARNING
Do NOT try to install the controller software if it is already installed.
Only type the following command if the controller software has not been installed yet.
Check that the HP VAN SDN Controller software is available:
sdn@sdnctl1:~$ ls
hp-sdn-ctl_2.5.15.1175_amd64.deb

Caution
The HP VAN SDN Controller software is downloaded as part of a zip file. You will need to
extract the Debian file from the zip file before installation.
Do the following to prepare the downloaded HP VAN SDN Controller software package for installation:
Ensure that you have root access on the Ubuntu system using the sudo command.
Unpack the HP VAN SDN Controller from the directory in which the package is stored.
Note
In the following command, two hyphens precede the unpack keyword; that is, --unpack.
Command:
~$ sudo dpkg -unpack hp-sdn-ctl_2.5.x.yyyy_amd64.deb

Where x.yyyy completes the actual release version number of the controller2.5.15.1175, for example.

Verifying hardware requirements


The VAN SDN Controller verifies that your hardware system meets the minimum requirements needed for
operation for a small to medium production environment of 100500 devices, links, and hosts. If the
installation detects that the hardware does not meet these minimum requirements, you will see an Error
message and output similar to the following:
Error! This controller has X cores! (8 cores required)
Error! This controller has X.yyyyy GB of RAM! (16 GB required)
Error! This controller has X.yyyyy GB of available storage! (64 GB required)

This hardware platform doesn't meet the minimum requirements for a production deployment.
Please see the Support Matrix for additional hardware requirements for sizing production
deployments:
http://h20564.ww2.hp.com/portal//site/hpsc/public/kb/docDisplay/?docEd=c04219768
To override this check, run the following command before installation:
'touch /tmp/override.txt'
Overriding this check is useful for demonstrations and small test environments. Some
features may not work properly without a controller that meets minimum hardware
requirements.
An installation using this check should not be used in production networks and will not be
supported by HP support.

Note
If the above message appears, the controller hardware does not meet the minimum requirements for
number of cores, free RAM, and/or available storage for a production environment.
If you are installing a controller for operation in a production network, you should halt the
installation process and start over with controller hardware that meets the requirements for your
system. For full information on controller hardware requirements, see the section titled Hardware
requirements and recommendations in the latest edition of the HP VAN SDN Controller and
Applications Support Matrix

Override hardware check


Overriding the hardware check is useful for demonstrations and small test environments. Some features
may not work properly without a controller that meets minimum hardware requirements. An installation
overriding this check should not be used in production networks and will not be supported by HP support.
If you choose to override hardware verification, run the touch command and rerun the dpkg--unpack
command as shown below:
~$ touch /tmp/override.txt

Rerun the command:


~$ sudo dpkg -unpack hp-sdn-ctl_2.5.x.yyyy_amd64.deb

Where x.yyyy completes the actual release version number of the controller2.5.15.1175, for example.
Note
In the above command, two hyphens precede the unpack keyword; that is,--unpack.

Install controller and verify


Execute the following command to install software dependencies and complete the installation:

~$ sudo apt-get install -f

If the system prompt appears (~$), proceed to the next step.


If you are prompted with Do you want to continue [Y/n]? press Y and continue to the next step. Following
is an example of the installation-process display:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
ca-certificates-java fontconfig-config iputils-arping java-common libasyncns0 libavahiclient3 libavahi-common-data libavahi-common3 libcap2 libcups2 libflac8 libfontconfig1
libjpeg-turbo8 libjpeg8 libjson0 liblcms2-2 libnspr4 libnss3 libnss3-1d libogg0 libopts25
libpcsclite1 libpq5 libpulse0 libsndfile1 libsysfs2 libvorbis0a libvorbisenc2 ntp openjdk7-jre-headless postgresql postgresql-9.1 postgresql-client postgresql-client-9.1
postgresql-client-common postgresql-common ttf-dejavu-core tzdata tzdata-java unzip
Suggested packages:
default-jre equivs cups-common liblcms2-utils pcscd pulseaudio ntp-doc icedtea-7-jre-jamvm
libnss-mdns sun-java6-fonts ttf-dejavu-extra fonts-ipafont-gothic fonts-ipafont-mincho
ttf-wqy-microhei ttf-wqy-zenhei ttf-indic-fonts-core ttf-telugu-fonts ttf-oriya-fonts ttfkannada-fonts ttf-bengali-fonts oidentd ident-server locales-all postgresql-doc-9.1 zip
The following NEW packages will be installed:
ca-certificates-java fontconfig-config iputils-arping java-common libasyncns0 libavahiclient3 libavahi-common-data libavahi-common3 libcap2 libcups2 libflac8 libfontconfig1
libjpeg-turbo8 libjpeg8 libjson0 liblcms2-2 libnspr4 libnss3 libnss3-1d libogg0 libopts25
libpcsclite1 libpq5 libpulse0 libsndfile1 libsysfs2 libvorbis0a libvorbisenc2 ntp openjdk7-jre-headless postgresql postgresql-9.1 postgresql-client postgresql-client-9.1
postgresql-client-common postgresql-common ttf-dejavu-core tzdata-java unzip
The following packages will be upgraded:
tzdata
1 upgraded, 39 newly installed, 0 to remove and 84 not upgraded.
1 not fully installed or removed.
Need to get 53.2 MB of archives.
After this operation, 88.9 MB of additional disk space will be used.
Do you want to continue [Y/n]? y

Verify the controller installation:


~$ sudo dpkg -l hp-sdn-ctl

If the HP VAN SDN Controller package is properly installed, output similar to the following appears:
ii hp-sdn-ctl 2.5.14.1169 HP VAN SDN Controller

The value ii should be displayed in the left-most output to indicate that the installation has installed
correctly. The first letter indicates desired package state (selection state). "i" means the package should

be installed. The second letter indicates the current package state. "i" means the package was installed
"ii" thus means that the package should have been installed and in this case, was installed successfully.
Note
The HP VAN SDN Controller uses Keystone for username and password authentication. This is
separate and different from the Linux operating system username and password.
The HP VAN SDN Controller does include the /opt/sdn/admin/config_local_keystone script which
creates a user, tenant, password and role variables in the Keystone server. If desired, use this script to
create a default user of sdn with a password of skyline.
Only type the following command if the controller software has not been installed yet. (See the step 5 in
the HP VAN SDN Controller installation check section of this guide.)
sdn@sdnctl1:~$ sudo /opt/sdn/admin/config_local_keystone
Adding SDN-related items to Keystone...
keystone stop/waiting
keystone start/running, process 7352
Finalize configuration for keystone...
...done.
sdn@sdnctl1:~$

Use the sudo dpkg -l hp-sdn-ctl command to check if the HP VAN SDN Controller software is installed
(enter a password of skyline if prompted):
Result if the controller software is installed correctly:
sdn@sdnctl1:~$ dpkg -l hp-sdn-ctl
[sudo] password for sdn:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-=============================
ii hp-sdn-ctl 2.5.15.1175 HP VAN SDN Controller
No packages found matching hp-sdn-ctl.
sdn@sdnctl1:~$

Note
The ii in the above output line indicates a successful controller installation. Any other characters
appearing instead of ii (such as iU) indicates that the controller is not correctly installed. In this
case, see the Troubleshooting section of the HP VAN SDN Controller 2.5 Installation Guide.
In the command line window, verify that the sdnc service is started:
~$ sudo service sdnc status

You should see the following output, which indicates that the sdnc service is started:
~$ sdnc start/running, process nnnn
Where: nnnn is the process ID assigned to the main HP VAN SDN Controller process (sdnc).

Configure a userlocal Keystone server


This procedure uses the /opt/sdn/admin/config_local_keystone script provided in the controller software
download to configure user, tenant, password, and role variables in the Keystone server.
1. If a web proxy is set on the machine running the controller, record and remove any http_proxy and
https_proxy settings, as follows:
a. Use this command to list the current environmental variables:
~$ export
Search the resulting listing for any https or http proxy variables in the current environment. If present,
these variables will appear similar to the following:
declare x http_proxy="http://webproxy.mycompany.com:8888/
declare x
https_proxy="https://webproxy.mycompany.com:8888/
b. Record any variables listed for https_proxy and http_proxy and save them for restoration after you
complete the user configuration procedure. Using the above example output, you would record these
two variables:
"http://web-proxy.mycompany.com:8888/
"https://web-proxy.mycompany.com:8888/
c. Use this command to remove the proxy settings:
~$ unset https_proxy http_proxy
2. Use the following command to run the script:
~$ sudo /opt/sdn/admin/config_local_keystone

Note
This step configures the controller user name as sdn and the password as skyline. If you want to
configure a different user name or password, see Changing a user password of the HP VAN SDN
Controller 2.5 Installation Guide after completing the installation process (you could also edit the
script).
Run the script only once on a given installation. If you need to rerun the script, first use sudo dpkg-P
keystone to uninstall the Keystone server, and then repeat the install process. The above script sets
the provider type to UUID by the Keystone server. The PKI provider type is also supported on the
HP VAN SDN Controller.
The script enforces these settings, which enable the controller to access the local Keystone server:
user:
AUTH_TOKEN: ADMIN
AUTH_ENDPOINT: 127.0.0.1
PORT: 35357
tenant: sdn
password: skyline
roles: sdn-admin and sdn-user
3. Use the following commands to restore any web proxy settings that you removed in step 1.
export http_proxy="http://web-proxy.entity:web-proxy-port/
export https_proxy="https://web-proxy.entity:web-proxy-port/

For example, you would use these commands to restore the web proxy settings for an entity known as
mycompany.com and a web proxy port of 8888:
~$ export http_proxy=http://web-proxy.mycompany.com:8888/
~$ export https_proxy=https://web-proxy.mycompany.com:8888/

Verifying the NTP configuration


The Network Time Protocol (NTP) is required to keep the controller in synchronization with your
network hardware and virtual devices. It is automatically installed with the controller unless already
installed on your machine. In most cases NTP will already be installed and configured. (A new NTP
installation synchronizes with default time servers if your machine is not already configured for specific
time servers.) To verify that NTP is configured on your system, do the following:
Run this command:
~ $ ntpdc -c peers

If the command output returns a server list similar to the following, one or more NTP servers are
configured on the system.

remote local st poll reach delay offset disp


===================================================================
=clock.example.net 192.0.2.105 16 64 0 0.000000 0.000000 3.99217
=myco.altopt.ca 192.0.2.137 16 64 0 0.000000 0.000000 3.99217

Questions
Answer the following questions to reinforce what you have learned in this section.
Question 1: Which command can be used to determine if the controller has been installed?
_________________________________________________________________
Question 2 : Which command updates the Ubuntu package index?
_________________________________________________________________
Question 3 : Which version of Keystone is recommended?
_________________________________________________________________
Question 4: Which command overrides the controller hardware check?
_________________________________________________________________
Question 5: Which command installs software dependencies and completes the controller installation?
_________________________________________________________________
Question 6 : Which command verifies that the controller service is running?
_________________________________________________________________
Question 7 : Which protocol is required to synchronize time?
_________________________________________________________________
Question 1 answer
The sudo dpkg -l hp-sdn-ctl command is used to determine if the controller software has been installed.
Result if the controller software is installed:
sdn@sdnctl1:~$ dpkg -l hp-sdn-ctl
[sudo] password for sdn:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================
ii hp-sdn-ctl 2.5.15.1175 HP VAN SDN Controller
sdn@sdnctl1:~$

The supported operating system is Ubuntu 12.04 LTS 64-bit Server.

Question 2 answer
Update the Package Index: The APT package index is essentially a database of available packages from
the repositories defined in the /etc/apt/sources.list file and in the /etc/apt/sources.list.d directory. To
update the local package index with the latest changes made in the repositories, type the following:
sudo apt-get update

Note
Source: https://help.ubuntu.com/lts/serverguide/apt-get.html
Question 3 answer
HP recommends using the icehouse version of the OpenStack Keystone server. However, you can use
any of the following Keystone server options: icehouse (recommended), havana, grizzly, folsom.
Question 4 answer
If you install on an unsupported hardware platform, you will receive the following message:
This hardware platform doesnt meet the minimum requirements for a production deployment.
Please see the Support Matrix for additional hardware requirements for sizing production
deployments:
http://h20564.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay/?docId=c04219768
To override this check, run the following command before installation:
'touch /tmp/override.txt'
Overriding this check is useful for demonstrations and small test environments. Some
features may not work properly without a controller that meets minimum hardware
requirements. An installation overriding this check should not be used in production
networks and will not be supported by HP support.

Use the touch /tmp/override.txt command to override the hardware check.


Question 5 answer
Install the downloaded HP VAN SDN Controller software using the sudo apt-get install -f command. This
command will install software dependencies and complete the installation:
Question 6 answer
The sudo service sdnc status command is used to verify that the core controller service has started.
The command output should display start/running and "process ####" (where #### = process ID).
sdnc is the main SDN controller service.
sdna is the SDN administrator service used for remote administration via the REST API (controller
stop, start, restart, log download, reboot, and so forth).
sdn@sdnctl:~$ sudo service sdnc status
sdnc start/running, process 1629
sdn@sdnctl:~$

sdn@sdnctl:~$ sudo service sdna status


sdna start/running, process 1624
sdn@sdnctl:~$

Question 7 answer
The NTP is required to keep the controller in synchronization with your network hardware and virtual
devices. It is automatically installed with the controller unless already installed on your machine. In most
cases, NTP will already be installed and configured. (A new NTP installation synchronizes with default
time servers if your machine is not already configured for specific time servers.) To verify that NTP is
configured on your system, use the ntpdc -c peers command.

Verify HP VAN SDN Controller services


After you have installed the controller and verified that its services are running via the sudo service sdnc
status and sudo service sdna status commands, you can check to make sure the controllers services are
running. To do this, use Chrome to navigate to the web-based controller interface. (Figure 3-12 illustrates
this step.) Use the controller IP address concatenated with the port number and /sdn/ui. For example, if
the IP address is 192.168.56.11, you can navigate to the interface using the following address:
192.168.56.11/8443/sdn/ui.
The HP VAN SDN Controller uses a self-signed certificate by default. Your browser may therefore
display a Privacy Error if the certificate was not previously accepted.
To accept the certificate, click Advanced:

Figure 3-12: Warning message


Click on the Proceed to <controller IP address> link, which is illustrated in Figure 3-13.

Figure 3-13: Browser warning


When prompted as you see in Figure 3-14, log in with your Keystone username and password. In some of
the previous versions of HP VAN SDN Controller, a default username of sdn and a password of skyline
were created in Keystone. This is not true for version 2.5 of the HP VAN SDN Controller.

Figure 3-14: Controller login prompt

Note
The HP VAN SDN Controller uses Keystone for username and password authentication. This is
separate and different from the Linux operating system username and password.
Optional information: Read the following information about Keystone if you are interested. Otherwise,
go to the next step:
The SDN Controller uses OpenStack Keystone as an identity management mechanism for managing users,
generating tokens, and token validation.

The controller supports Keystone releases supporting the 2.0 REST API from Folsom up to the Juno
release. It supports the following token authentication providers:
UUID32 character string (all Keystone releases)
PKICMS message containing service catalog, user roles, and metadata (Grizzly and later)
PKIZZLIB compressed PKI token (Juno and later)
The controller is configured by default to auto detect the token provider. It can also be forced to use a
specific provider.
The auto detection logic determines that any token longer than 32 characters is PKI or PKIZ.
Distinguishing between PKI and PKIZ is accomplished by detecting the PKIZ prefix which is prepended
to PKIZ compressed tokens.
Note
You will learn more about cURL and tokens later in this study guide.
To assign a user the sdn-admin role and give the user access to the desired SDN Controller:
1. Create a tenant:
curl H X-Auth-Token:ADMIN H Contant-Type: application/json d {"tenant":
{"enabled": true, "name": "test-tenant", "description": Test Tenant}}
http://controller-ip:35357/v2.0/tenants

2. List tenants:
curl H X-Auth-Token:ADMIN http://controller-ip:35357/v2.0/tenants

3. Create a user:
curl H X-Auth-Token:ADMIN H Contant-Type: application/json d {"user": {"email":
tester@test.rose.hp.com, "password": somepass, "enabled": true, "name": "test-user",
"tenantId":"2c851897a09f483fa452e2de11511f71"}} http://controller-ip:35357/v2.0/users

4. List users:
curl H X-Auth-Token:ADMIN http://controller-ip:35357/v2.0/users

5. Create a role:
curl H X-Auth-Token:ADMIN H Contant-Type: application/json d {"role": {"name":
"test-role"}} http://controller-ip:35357/v2.0/OS-KSADM/roles

6. List roles:
curl H X-Auth-Token:ADMIN http://controller-ip:35357/v2.0/roles

7. Assign a role:
curl X PUT H X-Auth-Token:ADMIN http://controller-ip:35357/v2.0/tenants/<tenantid>/users/<user-id>/roles/OS-KSADM/<role-id>

8. List roles for a user:

curl H X-Auth-Token:ADMIN http://controller-ip:35357/v2.0/OS-KSADM/roles/<user-id>

Optional reading: For more information about Keystone, refer to the HP VAN SDN Controller 2.5
Administrator
Guide,
Sections
8.6.18.6.9
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647289&lang=en-us&cc=us or
http://bit.ly/1MMz40K
The controller GUI presents the Alerts view by default. Click on the username in the upper right corner of
this view. (See the arrow in Figure 3-15.)

Figure 3-15: Alerts view


The SDN user window displays as in Figure 3-16.

Figure 3-16: SDN user window


The SDN Information Library link goes to the information library (http://www.hp.com/go/sdn/infolib)
on the HP SDN website. The HP SDN information library provides SDN Information Library links to the
technical documentation for the HP VAN SDN Controller and the HP SDN applications. The HP SDN
website provides fact sheets, case studies, white papers, product summaries, technical and business
documentation, and other information to help you identify SDN solutions for your business needs.
The SDN Community link goes to the HP SDN community discussion forum website
(http://hp.com/networking/sdnforum) within the HP Enterprise Business Community. This site offers
resources such as:
SDN Community
SDN discussion boards
SDN development information
An SDN knowledge base
Click the arrow to collapse the window, as you see in Figure 3-17.

Figure 3-17: SDN user window


Click OpenFlow Monitor (see the arrow in Figure 3-18). At the moment, no OpenFlow-enabled network
devices have connected to the HP VAN SDN Controller. In most cases in an OpenFlow environment,
OpenFlow switches contact the Controller using a predefined port number (Transport Control Protocol
[TCP] 6633 for OpenFlow 1.3.2).

Figure 3-18: OpenFlow Monitor


Click OpenFlow Topology (see the arrow in Figure 3-19). Once again, at the moment, no network
devices are connected to the HP VAN SDN Controller.

Figure 3-19: OpenFlow Topology


You now know the HP VAN SDN Controller has successfully started because the services have started
and you are able to connect to the controller GUI.

Mininet overview
As Figure 3-20 illustrates, Mininet is a network emulator. The figure also launches an Augmented Reality
video that discusses how to download and install Mininet. Mininet emulates various network topologies

consisting of virtual hosts (end-hosts), switches, and controllers and links on a single Linux kernel.
Mininet is a network emulator rather than a simulator.

Figure 3-20: Mininet overview


An emulator for this discussion is defined as follows: running unmodified code interactively, on virtual
hardware, on a regular PC. This provides convenience and realism at low cost (with some limitations
such as speed).
The command sudo mn will start the Mininet environment. This virtualizes the network of devices and
hosts which operate like real devices. You can run applications on host devices (such as a web server) or
view the OpenFlow tables on switches. Programs on the hosts can send packets through switch interfaces
which may be configured with different link speeds and delays. Packets get processed by what appears to
be a real Ethernet switch or router with a given amount of queuing. Applications such as iperf can also be
used to measure performance.
Mininet supports research, development, demonstrations, learning, prototyping, testing, debugging, and
any other tasks that could benefit from having a complete experimental network on a laptop or other PC.
Topologies of different sizes can be started with simple commands such as sudo mn (one switch and two
hosts) or sudo mn --topo linear,4 (four switches and four hosts). This allows for quick editing, running,
and testing of different SDN environments.
Custom topologies can also be created to simulate very large data centers or other large networks. Up to
4096 host devices have been successfully booted using Mininet.
Real programs can also be run on Mininet hosts such as a web server, DNS server, TCP window
monitoring tools, or Wireshark. Anything that runs on Linux can be run on Mininet.
The Mininet switches are programmable using the OpenFlow protocol. Mininet supports remote
(installed on a different server) and external controllers (external to Mininet). In this study guide, we will
use the HP VAN SDN Controller to manage the Mininet switches. Custom SDN network designs can be
modeled using Mininet and SDN applications tested before being deployed to hardware OpenFlow
switches. This is analogous to mobile development. For example, a mobile developer may develop and
test iPhone or Android mobile apps using a mobile emulator running on a laptop before transferring the
code to a physical phone.
Mininet can run on various physical devices such as laptops, servers, VMware, Virtual Box, Parallels, or
even in the cloud using hosted platforms such as Amazon EC2.

Mininet can be installed natively from GitHub or installed using Mininet packages on recent Ubuntu
releases. Visit mininet.org for installation details.

Mininet advantages
Like many other network virtualization systems available for physical routers and switches, such as the
HP VSR or Simware, a major advantage of Mininet is that complex networks can be created for
demonstration, learning, and testing purposes. As Figure 3-21 illustrates, rather than having to use
physical network devices, or virtual machines running operating systems such as Windows or Linux for
host devices, or trying to connect to a remote network, a full topology can be created quickly and easily
on a single computer.

Figure 3-21: Topology with only Mininet (virtual) switches


In this study guide, we will discuss the integration of Mininet and the HP VAN SDN Controller, which
provides multiple advantages including:
Mininet is based on Open vSwitch. Mininet is not a simulator, but a switch emulator. Open vSwitch is
a production, multilayer virtual switch similar to VMwares vSwitch, the HP VSR, or the Cisco
Nexus 1000V. For more information about Open vSwitch, visit openvswitch.org.
Mininet integrates with the HP VAN SDN Controller. This allows you to view topologies using the
controller OpenFlow topology viewer. Flow entries on Mininet switches can also be viewed and
manipulated using the controller APIs.
Switches and topologies boot within seconds rather than minutes.
Networks of hundreds of hosts and switches can be created.
Mininet networks created on a single PC are more scalable than running each host in a separate VM.
There is no need to transport physical equipment or connect to remote labs when demonstrating
OpenFlow and SDN technologies.
It is very quick and easy to reconfigure and restart topologies.
SDN applications can be tested on various topologies without recabling.

Mininet limitations
Mininet-based networks cannot exceed the CPU or bandwidth available on a single server. Mininet can
also only run Linux-compatible OpenFlow switches or applications.
There are limitations on Mininet, such as the resources available to Mininet and the resource limits of the
host system. Resources on a single system will be shared between the Mininet hosts and switches running
on that system.

Mininet uses a single Linux kernel for all virtual hostsno software that depends on other operating
systems such as Microsoft Windows are supported.
Mininet interacts with OpenFlow controllers. A controller can be used to update flow tables on Mininet
switches. In this study guide, the HP VAN SDN Controller is used.
Mininet is open source, and the source code can be found at: https://github.com/mininet.

How it works
The following technical details are from the mininet.org website and are included here for those who are
interested:
Nearly every operating system virtualizes computing resources using a process of abstraction. Mininet
uses process-based virtualization to run many hosts and switches on a single OS kernel. Since version
2.2.26, Linux has supported network namespaces, a lightweight virtualization feature that provides
individual processes with separate network interfaces, routing tables, and ARP tables.
The full Linux container architecture adds chroot() jails, processes, user namespaces, and CPU and
memory limits to provide full OS-level virtualization, but Mininet does not require these additional
features. Mininet can create kernel or user-space OpenFlow switches, controllers to control the switches,
and hosts to communicate over the simulated network. Mininet connects switches and hosts using virtual
Ethernet (veth) pairs. While Mininet currently depends on the Linux kernel, in the future, it may support
other operating systems with process-based virtualization, such Solaris containers or FreeBSD jails.
Mininets code is almost entirely Python, except for a short C utility.

Mininet connection to virtual OpenFlow switches


This section provides instructions for using Mininet to connect virtual OpenFlow switches to an HP VAN
SDN Controller. For this discussion, assume that Mininet OVA is loaded on a network server and you are
using PuTTY on a Windows VM to connect to the Mininet server using SSH. Also, assume that your
username and password are both mininet. If you successfully connect using this username and password,
you should see something similar to the following example output:
login as: mininet
mininet@192.168.56.55's password:
Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.13.0-24-generic x86_64)
* Documentation: https://help.ubuntu.com/
Last login: Mon Jun 22 08:29:04 2015 from 192.168.56.5
mininet@mininet-vm:~$

Test your connection


You can use the ping c command to test your connection to the controller from Mininet. Following is an
example:
mininet@mininet-vm:~$ ping -c 5 192.168.56.11
PING 192.168.56.11 (192.168.56.11) 56(84) bytes of data.
64 bytes from 192.168.56.11: icmp_seq=1 ttl=64 time=1.62 ms

64 bytes from 192.168.56.11: icmp_seq=2 ttl=64 time=0.351 ms


64 bytes from 192.168.56.11: icmp_seq=3 ttl=64 time=0.471 ms
64 bytes from 192.168.56.11: icmp_seq=4 ttl=64 time=0.533 ms
64 bytes from 192.168.56.11: icmp_seq=5 ttl=64 time=0.423 ms
--- 192.168.56.11 ping statistics --5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 0.351/0.681/1.629/0.478 ms
mininet@mininet-vm:~$

Clear Mininet topologies


It is good practice to clear Mininet topologies to remove any phantom processes using the sudo mn c
command. Do this to ensure no previous topologies remain in memory. Following is an example:
mininet@mininet-vm:~$ sudo mn -c
*** Removing excess controllers/ofprotocols/ofdatapaths/pings/noxes
killall controller of protocol of datapath ping nox_core lt-nox_core ovs-openflowd ovscontroller udpbwtest mnexec ivs 2> /dev/null
...<omitted>...
*** Removing all links of the pattern foo-ethX
ip link show | egrep -o '([-_.[:alnum:]]+-eth[[:digit:]]+)'
*** Killing stale mininet node processes
pkill -9 -f mininet:
*** Shutting down stale tunnels
pkill -9 -f Tunnel=Ethernet
pkill -9 -f .ssh/mn
rm -f ~/.ssh/mn/*
*** Cleanup complete.
mininet@mininet-vm:~$

Mininet commands
Table 3-1 explains the Mininet commands you can expect to see in this study guide. Commands are case
sensitive.

Table 3-1: Mininet commands


Command Value

Meaning

sudo

Sudo or substitute user id do allows users to run programs with the security
privileges of another userin this case with root privileges.
Mininet application.
Use a remote OpenFlow controller rather than the local built-in Mininet
controller.
Example IP address of the HP VAN SDN Controller used in this study guide.

mn
--controller=remote
ip=192.168.56.11
--topo=linear,4

Create a linear topology of four switches. In a linear topology, each switch has
a single host attached and is connected back-to-back to other switches in the
topology.
exit
Exit Mininet
-c
Clear Mininet processes
--mac
Assigns each host a sequential MAC address
--controller=remote, ip= Option for using a remote controller
<controller_ip_address>
\
Option for splitting commands across multiple lines
--switch=ovsk
Option for using kernel mode Open vSwitch
Protocols=OpenFlow13 Option to negotiate with the controller to use OpenFlow 1.3

Linear topology
To create a topology with four switches connected in a linear fashion (back-to-back), each having a
single host connected to it, use the command:
sdn@ubuntu:~$ sudo mn --controller=remote,ip=192.168.56.11
--topo=linear,4

Command shown in a single line:


sudo mn --controller=remote,ip=192.168.56.11 --topo=linear,4

Same command shown with \ character to indicate a single line, but split over multiple lines for
readability
sudo mn \
--controller=remote,ip=192.168.56.11 \
--topo=linear,4

SDN commands are often shown using the \ character.


Command result:
*** Creating network

*** Adding controller


*** Adding hosts:
h1 h2 h3 h4
*** Adding switches:
s1 s2 s3 s4
*** Adding links:
(h1, s1) (h2, s2) (h3, s3) (h4, s4) (s1, s2) (s2, s3) (s3, s4)
*** Configuring hosts
h1 h2 h3 h4
*** Starting controller
*** Starting 4 switches
s1 s2 s3 s4
*** Starting CLI:
mininet>

Mininet ping
As previously mentioned, ping can be used to verify connectivity between devices within Mininet. This is
also useful for generating traffic to view and manipulate flows on the Mininet switches.
The command h1 ping h2 , for example, starts a continuous ping from h1 to h2.
The command h1 ping c 1 h2 sends a single ping from h1 to h2.
The command pingall tests connectivity between all host devices:
mininet> pingall
*** Ping: testing ping reachability
h1 -> h2 h3 h4
h2 -> h1 h3 h4
h3 -> h1 h2 h4
h4 -> h1 h2 h3
*** Results: 0% dropped (12/12 received)
mininet>

Linear topology result


To view the created topology in Mininet, use the net command:
mininet> net
h1 h1-eth0:s1-eth1
h2 h2-eth0:s2-eth1

h3 h3-eth0:s3-eth1
h4 h4-eth0:s4-eth1
s1 lo: s1-eth1:h1-eth0 s1-eth2:s2-eth2
s2 lo: s2-eth1:h2-eth0 s2-eth2:s1-eth2 s2-eth3:s3-eth2
s3 lo: s3-eth1:h3-eth0 s3-eth2:s2-eth3 s3-eth3:s4-eth2
s4 lo: s4-eth1:h4-eth0 s4-eth2:s3-eth3
c0
mininet>

Mininet does not have a GUI that dynamically updates. Use the HP VAN SDN Controller OpenFlow
Topology diagram to view the created topology. Figure 3-22 provides a screen capture of this page.

Figure 3-22: Linear topology result, as seen via the HP VAN SDN Controller Topology page
The Mininet switches contact the SDN controller using the default OpenFlow port of 6633. The switches
will thus automatically appear in the Controller OpenFlow diagram.
The controller can only discover hosts when they send ARP, DHCP, or other traffic to OpenFlow-enabled
switches. Hosts do not appear in the OpenFlow Topology diagram as Mininet hosts do not generate
traffic until instructed to. Mininet needs to be explicitly instructed to send host traffic for the hosts to be
discovered.

Note
The IANA has now allocated TCP port 6653 to the Open Networking Foundation (ONF) to be used
by the OpenFlow switch protocol. The port number changed from OpenFlow version 1.4.0
(October 15, 2013). Refer to B.14.17 of the 1.4.0 specification.
The ONF has also updated other versions of OpenFlow such as 1.3.3 (December 18, 2013) and
OpenFlow 1.0.2 (ErrataNovember 1, 2013) with the new IANA assigned port number.
Currently the HP VAN SDN Controller uses port 6633. This may change in future to use the IANA
specified port number.

Keyboard shortcuts
The HP VAN SDN Controller Topology page includes the keyboard shortcuts you see displayed in Figure
3-23, which can be viewed by clicking the question mark character (?) at the top of the page.

Figure 3-23: Keyboard shortcuts available via the HP VAN SDN Controller Topology page
For example, the p key toggles port numbers and the n key shows end station nodes as IP, MAC, or no
label. Figure 3-24 illustrates the result of pressing the p key.

Figure 3-24: The result of pressing the p key


Figure 3-25 illustrates the result of pressing the n key once.

Figure 3-25: The node IP view results from pressing the n key
Figure 3-26 shows the result of pressing the n key again.

Figure 3-26: The node MAC view results from pressing the n key again

Easy to read MAC addresses


By default, hosts start with randomly assigned MAC addresses. This can make debugging difficult. As
Figure 3-27 indicates, every time the Mininet topology is created, the MACs change, so correlating
control traffic with specific hosts is tough.

Figure 3-27: Configure easy-to-read MAC addresses


The --mac option assigns each host a sequential MAC address, matching its IP address.

Mininet options
Mininet supports OpenFlow version 1.3. The commands in the following figure (Figure 3-28) show
various options that are available when creating a Mininet topology.

Figure 3-28: Options for creating Mininet topologies


In the illustrated example, an external controller with IP address 192.168.56.11 is used rather than the
built-in Mininet controller. A linear topology of four switches is created, and the switches are configured
to use OpenFlow 1.3 with the controller.
WARNING
The Mininet command shown in the figure is case sensitive. Ensure you type it correctly.

OpenFlow Monitor view


The HP VAN SDN Controller OpenFlow Monitor view includes basic information about the OpenFlow
switches that are configured on the controller.

Figure 3-29: OpenFlow Monitor view on the HP VAN SDN Controller GUI
For example, the OpenFlow Monitor view in Figure 3-29 shows that the negotiated version of
OpenFlow is 1.0.0. The HP VAN SDN Controller supports OpenFlow versions from 1.0 to 1.3. HP
ProVision switches support OpenFlow 1.0 and 1.3. HP Comware switches support OpenFlow 1.3 only.
Mininet supports OpenFlow 1.0 and 1.3
The figure also shows that Nicira Inc. (which has been acquired by VMware) manufactured all of the
switches, the hardware version of these switches is Open vSwitch, and the software version is 2.0.2.
Note
Mininet runs Open vSwitch (OVS) which is an open source, multilayer, OpenFlow-enabled, virtual
switch. This is conceptually similar to VMwares vNetwork distributed vSwitch, but OVS supports
OpenFlow. For more information, visit http://openvswitch.org.
OpenFlow switches are identified by Data Path IDs (DPIDs). This is a 64-bit number consisting of two
parts:
Most significant 16 bits are vendor specific. Mininet switches set this to 00:00 by default.
Least significant 48 bits: Switch MAC address. Mininet switches use easy to read values such as
00:00:00:00:00:01.
If you were to select a switch that has a DPID of 00:00:00:00:00:00:00:01 and then click Summary, the
view would display various information about the switch, including the capabilities, negotiated
OpenFlow version, and supported actions. Figure 3-30 provides a screen capture of this view.

Figure 3-30: OpenFlow Monitor Summary view

Note
Details of the fields shown here will be discussed in detail later in the OpenFlow chapter. We will
use Wireshark to capture packets and see the full negotiation of messages and learn their meaning.
Selecting the Ports view gives you a summary of all the ports available on the switch. The screen capture
in Figure 3-31 provides a screen capture of this view.

Figure 3-31: OpenFlow Monitor Ports view


Three ports are available on the switch in Figure 3-31. Ports 1 and 2 are Ethernet ports. These would be
physical ports on a physical OpenFlow switch. The Local port is the management interface on the switch.
Other information, such as the spanning tree state and speed are shown. These will be discussed in more
detail later in this study guide.
Clicking Flows provides a view of the OpenFlow flow table, as illustrated in Figure 3-32.

Figure 3-32: OpenFlow Monitor Flows view


Following is a brief summary of table items:

Table ID
The Table ID is set to n/a in this example as OpenFlow 1.0 is used. In OpenFlow 1.0, a switch is seen as
having a single flow table and the controller has no visibility of flow tables in the pipeline. In subsequent
versions of OpenFlow, multiple tables are available in the pipeline.

Match
The Match field is used to match incoming traffic. This matches fields in the packet header such as source
MAC address, destination IP address, source port number, and others, which we will discuss in more
detail later in the study guide.
The first two entries in Figure 3-32 match DHCP traffic.
The third entry matches Broadcast Domain Discovery Protocol (BDDP) which is used to discover links
between switches. We will discuss BDDP in more detail later.
The fourth entry matches ARP traffic and is used to discover hosts (nodes) in the topology.
The last entry is called a table miss. This matches everything (blank Match field). In this example, traffic
is forwarded to the NORMAL port which sends traffic to the traditional routing and switching pipeline on
the switch.

Actions/Instructions
An Action (OpenFlow 1.0) or Instruction (OpenFlow 1.3) determines what happens with the traffic.
DHCP traffic in this example is output to the NORMAL port (sent to traditional switch pipeline) and to
the controller. This is known as a copy and allows the controller to learn about hosts (nodes) in the
network.
The BDDP entry is known as a steal and redirects BDDP traffic to the HP VAN SDN Controller. This
allows the HP VAN SDN Controller to remove BDDP traffic from the network. Hence the only output port
is Controller.

BDDP is used to discover the network topology. It will be discussed in more detail later in this study
guide.
The ARP entry is also copied to both the traditional switch pipeline (NORMAL port) and the controller
(CONTROLLER port).

Priority
The Priority field determines the order of flows. The higher the priority of a matching flow entry, the
more likely it is that the entry will be matched.

Exit Mininet
Using the exit command is analogous to powering down all devices in a physical network.
mininet> exit
*** Stopping 1 controllers
c0
*** Stopping 4 switches
s1 ..s2 ...s3 ...s4 ..
*** Stopping 7 links
*** Stopping 4 hosts
h1 h2 h3 h4
*** Done
completed in 3776.970 seconds
mininet@mininet-vm:~$

When you enter this command, the devices in the HP VAN SDN Controller OpenFlow Topology view
should first go gray as you see in Figure 3-33, then disappear, as you see in Figure 3-34.

Figure 3-33: Devices first go gray

Figure 3-34: Devices disappear from the topology

Questions
The following questions and their answers will help you retain what you learned about Mininet in this
section.
Question 1: On which switch platform is Mininet based?
_________________________________________________________________
Question 2: Is it possible to create custom Mininet network topologies?
_________________________________________________________________

Question 3 : Is Mininet open source software?


_________________________________________________________________
Question 4 : Which table was displayed on the HP controller when Mininet was configured to use
version 1.0 of OpenFlow? And when OpenFlow 1.3 was negotiated?
_________________________________________________________________
Question 5: How are switches identified in OpenFlow?
_________________________________________________________________
Question 6 : What would happen to traffic from a host with source IP address 10.1.1.1/32 in the
following flow table?
Table ID

Priority Match

Action

n/a

20000

Src IP:
10.1.1.1/32
60000 Src IP:
10.1.1.1/32
Priority Match

Drop

20000

Drop

n/a
Question 7: What would happen to traffic from a host with
source IP address 10.1.1.1/32 in the following flow table?
Table ID
n/a
n/a

60000

n/a

30000

n/a

Src IP:
10.1.1.3/32
Src IP:
10.1.1.2/32
Src IP:
10.1.1.4/32

OutPut:
CONTROLLER
Action

OutPut:
CONTROLLER
Drop
OutPut:
NORMAL

Question 1 answer
Mininet is based on Open vSwitch. Mininet is not a simulator, but a switch emulator. Open vSwitch is a
production, multilayer virtual switch similar to VMwares vSwitch, the HP VSR, or the Cisco Nexus
1000V. For more information about Open vSwitch, visit openvswitch.org
Question 2 answer
Custom topologies can also be created to simulate very large data centers or other large networks. Up to
4096 host devices have been successfully booted using Mininet.
You can create your own topologies using a GUI builder:
https://github.com/mininet/mininet/wiki/Mininet-Apps

MiniEdit:

Figure 3-35 displays a screen capture of the MiniEdit interface. MiniEdit is an evolution of the
miniedit.py example script included with Mininet. It adds all kinds of capabilities to new controller, host,
switch and link options.
It gives you the option to save your topology and also export as a Mininet python script.
Available at http://gregorygee.wordpress.com/category/miniedit/

Figure 3-35: MiniEdit


Visual Network Description
Figure 3-36 displays a screen capture of the Visual Network DescriptionVNDinterface. VND
(http://www.ramonfontes.com/vnd) is a GUI tool that allows automatic creation of Mininet and
OpenFlow controllers scripts.

Figure 3-36: VND


Question 3 answer
Yes, Mininet is open source software.
For more information, visit the following:
https://github.com/mininet/mininet
http://mininet.org

Question 4 answer
As the screen capture in Figure 3-37 illustrates, the table number is n/a when OpenFlow version 1.0 is
used:

Figure 3-37: Table ID for OpenFlow 1.0


The following screen capture (Figure 3-38) shows that a table number of zero is displayed when
OpenFlow 1.3 is negotiated:

Figure 3-38: Table ID for OpenFlow 1.3


Question 5 answer
OpenFlow switches are identified by their datapath identifiers (DPIDs). To be precise, a DPID
represents an OpenFlow instance as a single HP switch. DPIDs may be configured with multiple
OpenFlow instances.
Question 6 answer
In this example, both entries match the same source IP address. However, because the second flow entry

has a higher priority in the table, it takes precedence over the first entry. Traffic from a source IP address
of 10.1.1.1 will be forwarded to the controller.
Question 7 answer
In this example, traffic from a source IP address of 10.1.1.1/32 is output to the NORMAL port and is then
processed by the traditional switch pipeline. A flow entry with a priority of 0 and a blank match statement
is called a table miss entry and matches all traffic not previously matched by higher priority flow entries.
No other flow entries in this example match traffic with a source IP address of 10.1.1.1/32. The table
miss entry is therefore used for traffic forwarding, and the output action is send to NORMAL.

Installing a new application via the App Store


The Application Manager supports default and add-on network services and enables installing,
upgrading, enabling (starting), disabling (stopping), and uninstalling SDN applications. Figure 3-39
shows the HP VAN SDN Controller Application Manager GUI. It also launches an Augmented Reality
video that explains how to install SDN applications.

Figure 3-39: Installing a new application via the App Store


To access the Application Manager, launch the HP VAN SDN Controller GUI and click Applications. The
view displays a list of the applications that are already installed on the controller.
The HP VAN SDN Controller has some built-in (embedded) applications that help the controller discover
nodes and links in the network topology.
Here is a brief overview of the OpenFlow Link Discovery Application:
The OpenFlow Link Discovery application updates the switch OpenFlow flow tables to steal
discovery packets, injects discovery packets to all ports on all switches, and discovers links on the
controlled network by processing PACKET_IN messages (discussed later). It discovers two types of
links:

Direct links: links between two directly connected OpenFlow switches


Multihop links: links between two OpenFlow switches that are separated by a non-OpenFlow
switch
Note
For more information about the HP VAN SDN Controller embedded applications, refer to the HP
VAN
SDN
Controller
2.5
Administrator
Guide,
Section
2:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647289&lang=en-us&cc=us or
http://bit.ly/1MMz40K
You can purchase and download applications for your controller from the HP SDN App Store. You can
install applications on the HP VAN SDN Controller directly from the HP APP store or manually from
your local computer.
Note
When controllers are operating in a team, actions performed on one controller are propagated to the
other controllers in the team. Actions you select in the Applications window for one controller,
such as Install, Enable, and Disable, are propagated to the other controllers.
To install an application, in the HP VAN SDN Controller GUI, click Applicationsand then click Log in to
view applications...
A new browser window opens and you will need to enter your HP SDN App Store credentials (you may
need to turn off pop-up blockers). Figure 3-40 illustrates the authentication process. This authentication is
taking place from your local computer to the App Store. This requires your PC to have Internet access.

Figure 3-40: Installing a new application (continued)


Once authenticated, a token is given to the controller, allowing it to download the app directly from the
App Store. This requires the controller to have Internet access.
Once the application has been downloaded from the App Store, you can click Deploy to install the
application on the controller.

As Figure 3-41 illustrates, purchased applications are shown on the controller as ready for installation.

Figure 3-41: Installing a new application (continued)


In the default state, or when an application has been started, it is in the ACTIVE state and is servicing
requests. See Figure 3-42 for an example of how the HP VAN SDN Controller interface displays
applications that are in the active state.

Figure 3-42: HP VAN SDN controllers that are in the active state
Table 3-2 provides a list of application states.
Table 3-2: Application states
State
ACTIVE
STAGED

Description

The application is running and servicing requests.


A new application has been downloaded to the controller and is ready to be
installed.
UPGRADE_STAGED A new version of an existing running application has been downloaded to the
controller and the new version is ready to be installed (upgrade/downgrade).

INSTALLING
UPGRADING
CANCELING
DISABLING
DISABLED
ENABLING
UNINSTALLING
RESOLVED

A transitive state indicating a new application is in the process of being installed.


A transitive state indicating the existing application is being stopped and a new
version of the application is being installed.
A transitive state indicating a noninstalled version of an application is being
deleted from the controller.
A transitive state indicating the application is in the process of being disabled
(stopping).
The application is disabled (stopped). A disabled application is not
automatically started when the controller is restarted.
A transitive state indicating the application is being started.
A transitive state indication an application is being stopped and completely
removed from the controller.
The application is stopped and not servicing requests. An application can only be
in this state when it is stopped externally to the HP VAN SDN Controller (e.g., the
virgo console).

In the following figure (Figure 3-43), the HP Network Protector SDN Application has been downloaded
from the HP SDN App Store to a local PC. The application is then uploaded to the controller from the
local PC rather than the HP VAN SDN Controller downloading it directly from the HP SDN App Store.

Figure 3-43: Installation steps

Example application installation


Suppose you have already downloaded a new application called Flow Maker Deluxe from the App Store
and you now want to install it. The following instructions and examples will help you install this

application, add flows to switches using the application, and test your network to determine the effect of
adding these flows. All examples assume that you are using virtual devices via Mininet, as the topology
in Figure 3-44 illustrates.

Figure 3-44: Example topology

Basic instructions
To install the application, do the following:
1. Click Applications on the HP VAN SDN Controller menu and click New. (See the arrow in Figure 345 to locate the New option.)

Figure 3-45: Controller applications


2. Click Browse, as indicated by the arrow in Figure 3-46.

Figure 3-46: New application


Browse to the location of the application zip file and select the file. Figure 3-47 provides an example
location for the application on a Windows-based machine.

Figure 3-47: Upload the application


3. Click Upload to upload the file. See the arrow in Figure 3-48 for the location of Upload. Wait for the
Completed message to appear.

Figure 3-48: Upload an application


4. Click Deploy to deploy and activate the application. Figure 3-49 displays the location of Deploy.

Figure 3-49: Click Deploy


5. The application should deploy and appear in the Applications list as ACTIVE. Figure 3-50 illustrates
successful application deployment as seen in the HP VAN SDN Controller interface.

Figure 3-50: Application successfully installed


After you refresh your browser, Flow Maker Deluxe will also appear in the HP VAN SDN Controller
interfaces menu, as shown in Figure 3-51.

Figure 3-51: New application appears in left-hand menu pane

New application flows


SDN applications such as Flow Maker Deluxe can create flows on OpenFlow switches. The following
instructions show you how to create flows using this applications interface. The following example
illustrates the results of creating a flow that blocks a host.

Example 1: Create a flow that blocks a host


To add a new flow from the Flow Maker Deluxe interface, click a switch in the Flow Maker Deluxe
General view. This view is displayed in Figure 3-51. For example, click the switch with DPID
00:00:00:00:00:00:00:01. Flows on the switch are displayed.
1. Click Add as shown in Figure 3-52 to add a new flow.

Figure 3-52: Add a new flow


Before updating the flow table of the switch, you can check connectivity by pinging from host 1 (10.0.0.1)
to host 4 (10.0.0.4) in Mininet as follows:
mininet> h1 ping -c 5 h4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=1.00 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=64 time=0.157 ms
64 bytes from 10.0.0.4: icmp_seq=3 ttl=64 time=0.160 ms
64 bytes from 10.0.0.4: icmp_seq=4 ttl=64 time=0.137 ms
64 bytes from 10.0.0.4: icmp_seq=5 ttl=64 time=0.206 ms
--- 10.0.0.4 ping statistics --5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 0.137/0.332/1.000/0.334 ms
mininet>

2. In Flow Maker, add a flow entry with the following attributes and then click Add . Figure 3-53
provides a screen capture of the flow-entry interface.
Table ID:0

Priority: 100
In Port: 1
Save Flow: True

Figure 3-53: The flow entry interface

Note
Ensure that you have clicked Add at the top of the Flow Maker page to add the flow to the switch.
The Flow Table is updated with the new flow entry, as shown by the flow with the green frame in Figure
3-54.

Figure 3-54: Flow table updated


To test the new flow, try pinging from host 1 (10.0.0.1) to host 4 (10.0.0.4) in Mininet:
mininet> h1 ping -c 5 h4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
--- 10.0.0.4 ping statistics --5 packets transmitted, 0 received, 100% packet loss, time 4032ms
mininet>

As you see, the ping failed. To further test the result of adding the flow, you might try pinging from host 1
to host 2:
mininet> h1 ping -c 2 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
--- 10.0.0.2 ping statistics --2 packets transmitted, 0 received, 100% packet loss, time 999ms
mininet>

Result : Pings fail. The flow entry you created is matching all traffic that arrives on port 1 and drops it.
You can send pings between all devices in Mininet. Following is an example of what happens when you
try this:
mininet> pingall
*** Ping: testing ping reachability

h1 -> X X X
h2 -> X h3 h4
h3 -> X h2 h4
h4 -> X h2 h3
*** Results: 50% dropped (6/12 received)
mininet>

Result : An X in the output implies failure. Pings between h2, h3, and h4 succeed. However, pings to or
from h1 fail. Ping relies on echo and echo reply messages to succeed, and the flow entry you created is
blocking all traffic from h1, so the pings fail to h1 or from h2.
This is a static and very basic example of a host that is blocked from the network. More complex
applications such as the HP Network Protector application can do this dynamically.
3. In Flow Maker, click on the flow entry you created and click Delete. Figure 3-55 illustrates the
selected flow and the Delete selection. Confirm the flow deletion:

Figure 3-55: Delete flow


Deleting the flow should allow traffic to host 1. You can check this by sending pings between all devices
in Mininet again:
mininet> pingall

*** Ping: testing ping reachability


h1 -> h2 h3 h4
h2 -> h1 h3 h4
h3 -> h1 h2 h4
h4 -> h1 h2 h3
*** Results: 0% dropped (12/12 received)
mininet>

Result : Pings now succeed. If you lose a few pings, try using the pingall command again.

Example 2: Create a flow that matches Internet Control Message Protocol traffic
In the following example, we create a flow that matches Internet Control Message Protocol (ICMP)
traffic and test the results of this flow.
1. In Flow Maker, click Add to add a new Flow Entry to switch 00:00:00:00:00:001.
2. Create a flow entry with the following attributes and then click Add. Figure 3-56 illustrates this entry.
Table ID:0
Priority: 100
IP Protocol: ICMP
Ethernet Type: IPv4
Save Flow: True

Figure 3-56: Add flow in Flow Maker Deluxe


As Figure 3-57 illustrates, this updates the Flow Maker Deluxe flow table with the new entry.

Figure 3-57: Updated flow table


3. In Mininet, start a web server on h4 as follows:
mininet> h4 python -m SimpleHTTPServer 80 &
4. Make an HTTP GET request from h1 to h4 as follows:
mininet> h1 wget -O - h4
Note
The O is an uppercase letter o and not a zero 0. There is a space between the character O
and the dash - and the dash - and h4.
mininet> h1 wget -O - h4
--2015-06-23 07:10:02-- http://10.0.0.4/
Connecting to 10.0.0.4:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 802 [text/html]
Saving to: STDOUT
0% [ ] 0 --.-K/s <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>

<h2>Directory listing for /</h2>


<hr>
... <output ommitted> ...
<li><a href="oftest/">oftest/</a>
<li><a href="openflow/">openflow/</a>
<li><a href="pox/">pox/</a>
<hr>
</body>
</html>
100%[======================================>] 802 --.-K/s in 0s
2015-06-23 07:10:02 (52.9 MB/s) - written to stdout [802/802]
mininet>

Result : The HTTP GET request succeeds. You can test the results of this flow using ping.
Try pinging from host 1 (10.0.0.1) to host 4 (10.0.0.4) in Mininet:
mininet> h1 ping -c 2 h4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
--- 10.0.0.4 ping statistics --2 packets transmitted, 0 received, 100% packet loss, time 1000ms
mininet>

Result : Pings fail. You can check to see if the new flow entry has handled packets via the HP VAN SDN
Controller GUI.
5. In the HP VAN SDN Controller GUI, click OpenFlow Monitor. Figure 3-58 indicates the location of
this menu selection.

Figure 3-58: OpenFlow Monitor


6. Select the switch with DPID 00:00:00:00:00:00:00:01 and then click Flows. Figure 3-59 shows the
flow you created using Flow Maker Deluxe.

Figure 3-59: OpenFlow Monitor with new flow


Result : The flow entry you created is shown. There have been two packet matches. Check the number of
packet matches after sending two pings from host 1 to host 4:
mininet> h1 ping -c 2 h4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
--- 10.0.0.4 ping statistics --2 packets transmitted, 0 received, 100% packet loss, time 1000ms
mininet>

Figure 3-60 shows the resulting packet count in OpenFlow Monitor.

Figure 3-60: Updated packet count


7. If you are following these examples using a test network, use Flow Maker Deluxe to delete the new
flow (as you did in the first example), and exit and clear Mininet

New topology view


Example 3: Create a multiple host, single-switch topology in Mininet
The following example shows you how to create a topology wherein multiple hosts are connected to a
single switch.
1. Click OpenFlow Topology on the HP VAN SDN Controller interface. If you have cleared Mininet,
this view should be blank, as illustrated in Figure 3-61.

Figure 3-61: The OpenFlow Topology view after clearing Mininet


2. Start Mininet again, but in this case, change the topology type to a single switch with eight hosts:
sudo mn --controller=remote,ip=192.168.56.11 --topo=single,8 \
--switch=ovsk,protocols=OpenFlow13 --mac
mininet@mininet-vm:~$ sudo mn
--controller=remote,ip=192.168.56.11 --topo=single,8
--switch=ovsk,protocols=OpenFlow13 --mac
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2 h3 h4 h5 h6 h7 h8
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1) (h3, s1) (h4, s1) (h5, s1) (h6, s1) (h7, s1) (h8, s1)
*** Configuring hosts
h1 h2 h3 h4 h5 h6 h7 h8
*** Starting controller
c0
*** Starting 1 switches
s1

*** Starting CLI:


mininet>

You can use ping to check your connections between the switch and the hosts:
mininet> pingall
*** Ping: testing ping reachability
h1 -> h2 h3 h4 h5 h6 h7 h8
h2 -> h1 h3 h4 h5 h6 h7 h8
h3 -> h1 h2 h4 h5 h6 h7 h8
h4 -> h1 h2 h3 h5 h6 h7 h8
h5 -> h1 h2 h3 h4 h6 h7 h8
h6 -> h1 h2 h3 h4 h5 h7 h8
h7 -> h1 h2 h3 h4 h5 h6 h8
h8 -> h1 h2 h3 h4 h5 h6 h7
*** Results: 0% dropped (56/56 received)
mininet>

Troubleshooting
If pings fail, verify that you have removed the flow you created previously in Flow Maker. If that
does not resolve the issue, exit Mininet and clear any Mininet processes using the command: sudo
mn -c.
3. The OpenFlow Topology view is updated to show the devices (use keys n and p to show host IP
addresses and switch port numbers), as demonstrated in Figure 3-62.

Figure 3-62: Updated OpenFlow Topology view


4. If you are following these examples using a test network, exit and clear Mininet.

Questions
Following are a few questions that will help you retain what you have learned in this section.
Question 1
Refer to Figure 3-63.
What is the result of the following flow entries?
-ICMP traffic from 10.1.1.1 to 10.1.1.2
-HTTP traffic from 10.1.1.2 to 10.1.1.1

Figure 3-63: Figure for Question 1


_________________________________________________________________
_________________________________________________________________
Question 2
Refer to Figure 3-64.
What is the result of the following flow entries?
-ICMP traffic from 10.1.1.1 to 10.1.1.2
-HTTP traffic from 10.1.1.2 to 10.1.1.1

Figure 3-64: Question 2


_________________________________________________________________
_________________________________________________________________
Question 3
Refer to Figure 3-65.
What is the result of the following flow entries?
-ICMP traffic from 10.1.1.1 to 10.1.1.2
-HTTP traffic from 10.1.1.2 to 10.1.1.1

Figure 3-65: Question 3


_________________________________________________________________

_________________________________________________________________
Question 1 answer
OpenFlow 1.0 has been negotiated with the switch and thus the table number is shown as n/a.
ICMP traffic from 10.1.1.1 to 10.1.1.2 matches the following flow entry only:

The traffic is therefore forwarded out of port 3.


HTTP traffic from 10.1.1.2 to 10.1.1.1 matches both of the following entries:

The entry with the highest priority is selected. HTTP traffic is therefore forwarded out of port 2.
Question 2 answer
OpenFlow 1.0 has been negotiated with the switch and thus the table number is shown as n/a.
ICMP traffic from 10.1.1.1 to 10.1.1.2 matches the following entries:

Because entry eth_type:ipv4 has a higher priority (300) than the table miss entry (priority 0, blank match),
it is selected. In other words, the entry matching eth_type: ipv4 is selected and the action/instruction for
that entry applied. In this case there is no action/instruction, so ICMP traffic is dropped by the switch.
Analogy: think of entries in the table sorted in Excel by highest priority. Entries with a higher priority are
selected before entries with a low priority.
For traffic from 10.1.1.2 to 10.1.1.1, the following entries match:

The entry with the highest priority is selected (300). As there is no action/instruction, the traffic is
dropped.

Question 3 answer
OpenFlow 1.3 has been negotiated with the switch and thus the table number is shown as 0.
ICMP traffic from 10.1.1.1 to 10.1.1.2 matches only the entry in table 0 with priority 0. This is the table
miss entry and forwards traffic out of port 4. ICMP traffic is matched by the table miss and forwarded out
of port 4.
HTTP traffic from 10.1.1.2 to 10.1.1.1 matches the entry in table 0 with priority 400. As there is no
Action/Instruction, the traffic is dropped.

Mininet integration with physical network

Figure 3-66: Topology for integrating physical and Mininet devices


Using the topology in Figure 3-66, this section will provide instructions for and examples of integrating a
Mininet network with a physical network. This integration demonstrates how network function
virtualization (NFV) devices can interact with physical devices.
1. View the interfaces on the Ubuntu server running Mininet:
mininet@mininet-vm:~$ ifconfig | more
eth0 Link encap:Ethernet HWaddr 00:0c:29:ba:c2:00
inet addr:192.168.56.55 Bcast:192.168.56.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4576 errors:0 dropped:0 overruns:0 frame:0
TX packets:4150 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000

RX bytes:744361 (744.3 KB) TX bytes:556045 (556.0 KB)


eth1 Link encap:Ethernet HWaddr 00:0c:29:ba:c2:0a
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1895 errors:0 dropped:0 overruns:0 frame:0
TX packets:82 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:286481 (286.4 KB) TX bytes:28044 (28.0 KB)
lo Link encap:Local Loopback
... <omitted> ...
mininet@mininet-vm:~$

Result : There are two physical Ethernet interfaces on the Ubuntu server.
2. Start a small Mininet topology of two switches and set the network to use 192.168.56.0/24:
sudo mn --controller=remote,ip=192.168.56.11 --topo=linear,2 \
--switch=ovsk,protocols=OpenFlow13 --mac \
--ipbase=192.168.56.0/24

Result: A Mininet network will start.


3. What IP address are h1 and h2 using? Use the ifconfig command, as illustrated in the example output:
mininet> h1 ifconfig
h1-eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:01
inet addr:192.168.56.1 Bcast:192.168.56.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:1/64 Scope:Link
...<ommitted>...
mininet>
mininet> h2 ifconfig
h2-eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:02
inet addr:192.168.56.2 Bcast:192.168.56.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:2/64 Scope:Link
...<ommitted>...
mininet>

Answer : h1 = 192.168.56.1/24 and h2 = 192.168.56.2/24.


4. Can h1 ping h2 (192.168.56.2)? Use the ping c 5 <ip address> command, as in the following
example output.
mininet> h1 ping -c 5 192.168.56.2
PING 192.168.56.2 (192.168.56.2) 56(84) bytes of data.

64 bytes from 192.168.56.2: icmp_seq=1 ttl=64 time=5.40 ms


64 bytes from 192.168.56.2: icmp_seq=2 ttl=64 time=0.136 ms
64 bytes from 192.168.56.2: icmp_seq=3 ttl=64 time=0.115 ms
64 bytes from 192.168.56.2: icmp_seq=4 ttl=64 time=0.121 ms
64 bytes from 192.168.56.2: icmp_seq=5 ttl=64 time=0.094 ms
--- 192.168.56.2 ping statistics --5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 0.094/1.173/5.401/2.114 ms
mininet>

Result : Yes, host 1 can ping host 2.


5. Can host 1 (h1) ping 192.168.56.11 (The HP VAN SDN Controller)?
mininet> h1 ping -c 5 192.168.56.11
PING 192.168.56.11 (192.168.56.11) 56(84) bytes of data.
From 192.168.56.1 icmp_seq=1 Destination Host Unreachable
From 192.168.56.1 icmp_seq=2 Destination Host Unreachable
From 192.168.56.1 icmp_seq=3 Destination Host Unreachable
From 192.168.56.1 icmp_seq=4 Destination Host Unreachable
From 192.168.56.1 icmp_seq=5 Destination Host Unreachable
--- 192.168.56.11 ping statistics --5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4009ms
pipe 3
mininet>

Answer : No, pings fail.


6. Use PuTTY on your Windows VM (Jumphost) to open another SSH session to the Mininet server:
IP address: 192.168.56.55
Port number: 22
Protocol: SSH
7. When prompted, login with the following credentials:
Username: mininet
Password: mininet
8. View the interfaces that are currently used by Open vSwitch using the sudo ovs-vsctl show command,
as in the following example output:
mininet@mininet-vm:~$ sudo ovs-vsctl show
1077578e-f495-46a1-a96b-441223e7cc22

Bridge "s2"
Controller "ptcp:6635"
Controller "tcp:192.168.56.11:6633"
is_connected: true
fail_mode: secure
Port "s2-eth1"
Interface "s2-eth1"
Port "s2"
Interface "s2"
type: internal
Port "s2-eth2"
Interface "s2-eth2"
Bridge "s1"
Controller "tcp:192.168.56.11:6633"
is_connected: true
Controller "ptcp:6634"
fail_mode: secure
Port "s1"
Interface "s1"
type: internal
Port "s1-eth2"
Interface "s1-eth2"
Port "s1-eth1"
Interface "s1-eth1"
ovs_version: "2.0.2"
mininet@mininet-vm:~$

Result : In the output, you will see that both switch S1 and switch S2 have ports eth1 and eth2. Both
switches are also connected via TCP to the HP VAN SDN Controller (IP address 192.168.56.11) using
OpenFlow (port 6633). This connection is using the traditional routing and switching network and is
separate from the virtualized OpenFlow network.
9. Connect the Ubuntu physical interface eth1 to S1 so that the virtual network is connected to the
physical network using the sudo ovs-vsctl add command as illustrated in the following example:
mininet@mininet-vm:~$ sudo ovs-vsctl add-port s1 eth1

10. Go back to the previous SSH session where you have Mininet running. Can host1 ping the HP VAN
SDN Controller now?

mininet> h1 ping -c 3 192.168.56.11


PING 192.168.56.11 (192.168.56.11) 56(84) bytes of data.
64 bytes from 192.168.56.11: icmp_seq=1 ttl=64 time=0.986 ms
64 bytes from 192.168.56.11: icmp_seq=2 ttl=64 time=1.11 ms
64 bytes from 192.168.56.11: icmp_seq=3 ttl=64 time=0.707 ms
--- 192.168.56.11 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.707/0.937/1.119/0.173 ms
mininet>

Result : The virtual host can ping the HP VAN SDN Controller.
11. Can host1 ping the physical HP switch c1 (HP Comware switch 1)?
mininet> h1 ping -c 3 192.168.56.251
PING 192.168.56.251 (192.168.56.251) 56(84) bytes of data.
64 bytes from 192.168.56.251: icmp_seq=1 ttl=255 time=7.44 ms
64 bytes from 192.168.56.251: icmp_seq=2 ttl=255 time=1.72 ms
64 bytes from 192.168.56.251: icmp_seq=3 ttl=255 time=1.85 ms
--- 192.168.56.251 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 1.723/3.676/7.447/2.667 ms
mininet>

Result : The virtual host can ping physical switches through a virtual OpenFlow enabled network.
12. View the updated OpenFlow Topology in the HP VAN SDN Controller interface (see Figure 3-67
for the view related to this sections example topology.):

Figure 3-67: OpenFlow Topology view


Result : Both virtual Mininet hosts (192.168.56.1, 192.168.56.1) and other devices such as physical HP
switches (192.168.56.251, 192.168.56.253) and the Windows Jumphost (192.168.56.5) are visible in the
topology. The HP switches display as nodes as OpenFlow is not enabled on them yet.

Summary
Mininet is a nice way to test and learn OpenFlow using a single virtual machine that creates networks of
different sizes. However, you probably want to see OpenFlow and SDN technologies in a network
consisting of real switches.
In the next section, you will learn how to configure physical HP switches to use OpenFlow, install a
powerful SDN Application (HP Network Protector), and test traffic in a physical network.

ProVisionOpenFlow configuration
Preparing for configuration
Plan your network, including production and OpenFlow VLANs, OpenFlow instances, OpenFlow
controller ports, naming, and numbering strategy.
Plan the number of VLANs configured for OpenFlow versus non-OpenFlow.

OpenFlow is activated on an instance only when both of the following are true:
1. OpenFlow is enabled on the OpenFlow instance.
2. OpenFlow is enabled globally on the switch.

Command overview
Following is command-reference information that you can use to configure HP ProVision and Comware
switches:

Command reference information


To configure OpenFlow in system-view, use the openflow instance command and specify an instance.
This takes you to global OpenFlow configuration options:
<C2>system-view
System View: return to User View with Ctrl+Z.
[C2]openflow instance 1

On ProVision switches, there is a one-to-one mapping between instances and VLANs. In other words,
every VLAN requires a separate OpenFlow instance. This is not true for Comware switches (multiple
VLANs can be mapped to a single OpenFlow instance).
The instance specified here will also affect the switch Data Path ID (DPID). OpenFlow switches are
identified by DPIDs. This is a 64-bit number consisting of two parts:
Most significant 16 bits are vendor specific. On HP Comware switches, this equals the OpenFlow
instance number configured. If a number of 10 is configured, this equates to a in hexadecimal. The
switches will thus have a DPID that starts with: 00:0a if instance 10 is configured.
Least significant 48 bits: Switch MAC address.
Associate a single VLAN or multiple VLANs to the instance using the classification vlan command:
[C2-of-inst-1]classification vlan 20

This command is not effective until the active instance command is issued.
[C2-of-inst-1]

A controller ID and IP address must to be specified. You could configure multiple controllers for
redundancy and load balancing. In this case, only one controller is configured:
[C2-of-inst-1]controller 1 address ip 192.168.56.11

The last step is to activate the instance:


[C2-of-inst-1]active instance

Use the display openflow instance command to display detailed information for an OpenFlow instance.
Syntax:
display openflow instance [ instance-id ]
instance-id:

The instance-id command specifies an OpenFlow instance by its ID in the range of 1 to 4094.

Command output
Description: Description of the OpenFlow instance.
Active status: Activation status of the OpenFlow instance.
Inactive configuration: Inactive OpenFlow instance configuration.
Active configuration: Active OpenFlow instance configuration.
Classification VLAN, loosen mode, total VLANs: VLANs associated with the OpenFlow instance, the
total number of VLANs, and the loosen mode.
In-band management VLAN, total VLANs: In-band management VLANs and the total number of in-band
management VLANs. An empty VLAN is displayed when no in-band management VLAN is configured.
Mac-address learning: Whether MAC address learning is enabled in the VLANs associated with the
OpenFlow instance:
PermitMAC address learning is enabled in the VLANs associated with the OpenFlow instance.
ForbidMAC address learning is disabled in the VLANs associated with the OpenFlow instance.
Flow-entry max-limit: Maximum number of flow entries allowed in the extensibility flow table.
Datapath ID: Datapath ID of the OpenFlow instance.
Port information: Ports added to the OpenFlow instance.
Flow table: Flow table information of the OpenFlow instance.
Table ID(type): Flow table ID (flow table type). The flow table type can be MAC-IP or Extensibility.
count: Total number of flow entries in the flow table.
Active channel information: Information about active control channels.
Controller id IP address: Brief information of controllers which have established connections to the
OpenFlow instance. This field is displayed only when the OpenFlow instance has established
connections to controllers.
Failopen mode: Connection interruption mode when the OpenFlow instance is disconnected from all
controllers (this field is displayed only when the OpenFlow instance is disconnected from all
controllers):
SecureThe OpenFlow switch uses flow tables for traffic forwarding after it is disconnected from all
controllers.
StandaloneThe OpenFlow switch uses the normal forwarding process after it is disconnected from
all controllers.
Use the display openflow controller command to display controller information for an OpenFlow
instance.
The controller information includes connection information and packet statistics.
instance-id: Specifies an OpenFlow instance ID in the range of 164.
controller-id: Specifies a controller by its ID in the range of 063. If no controller ID is specified, this

command displays information about all controllers for an OpenFlow instance.


Reconnect interval: Reconnection interval (in seconds) for an OpenFlow instance to reconnect to all
controllers.
Echo interval: Interval (in seconds) at which an OpenFlow instance sends an Echo Request message to
all controllers.
Controller ID: ID configured for this controller.
Controller IP address: IP address of the controller.
Controller port: Destination port number used for communication with the OpenFlow Controller. Default
is 6633.
Controller role: Role of the controller:
EqualThe controller has the same mode as other controllers that are specified for the OpenFlow
instance.
MasterThe controller is the master controller for the OpenFlow instance.
SlaveThe controller is a slave controller for the OpenFlow instance.
If the controller is not configured with any role, this field displays two hyphens (--).
Connect type: Type of the connection between the OpenFlow instance and the controller: TCP or SSL.
Connect state: State of the connection between the OpenFlow instance and the controller: Idle or
Established.
Packets sent: Number of packets that have been sent to the controller.
Packets received: Number of packets that have been received from the controller.
SSL policy: Name of the SSL client policy used for SSL connections. If no SSL client policy controller is
configured, this field displays two hyphens (--).

Enable OpenFlow globally on a ProVision switch


To configure OpenFlow, in global configuration mode, type the command openflow.
This takes you to the OpenFlow context:
P1> enable
P1# configure
P1(config)# openflow
P1(openflow)#

Both a controller ID and IP address are required. You could configure multiple controllers for redundancy
and load balancing. In this case, only one controller is configured based on the topology you see in Figure
3-68. The VLAN used for communication with the controller is VLAN 1:
P1(openflow)# controller-id 1 ip 192.168.56.11 controller-interface vlan 1

The next step is to configure an OpenFlow instance. On ProVision switches, there is a one-to-one
mapping between instances and VLANs (when virtualization mode is used). In other words, every VLAN

requires a separate OpenFlow instance.


This is not true for Comware switches as multiple VLANs can be mapped to a single OpenFlow instance.
When aggregate mode is used on ProVision switches, all VLANs (except the VLAN used for
communication with the controller) are mapped to a single OpenFlow instance.
In this example, an instance with the name vlan30 has been created:
P1(openflow)# instance vlan30
P1(of-inst-vlan30)#

Map a VLAN to the instance using the member vlan command:


P1(of-inst-vlan30)# member vlan 30

Associate the controller with the instance:


P1(of-inst-vlan30)# controller-id 1

The default version of OpenFlow used by HP ProVision switches is 1.0. In this example, version 1.3 has
been specified. There are multiple advantages to using OpenFlow 1.3 including multiple table support
(pipeline).
P1(of-inst-vlan30)# version 1.3

The OpenFlow instance has to be enabled. You could have multiple instances (VLANs) and have
OpenFlow enabled on some of the VLANs and disabled on other VLANs. In this example, the OpenFlow
instance for VLAN 30 is enabled as follows:
P1(of-inst-vlan30)# enable

OpenFlow then needs to be enabled globally on the switch:


P1(of-inst-vlan30)# exit
P1(openflow)# enable

This is a basic OpenFlow configuration on a HP ProVision switch.

ComwareOpenFlow configuration
Command overview
To configure OpenFlow, in system-view, use the openflow instance command and specify an instance.
This takes you to global OpenFlow configuration options:
<C2> system-view
System View: return to User View with Ctrl+Z.
[C2] openflow instance 1

The instance specified here will also affect the switch Data Path ID (DPID). OpenFlow switches are
identified by DPIDs. This is a 64-bit number consisting of two parts:
Most significant 16 bits are vendor specific. On HP Comware switches, this equals the OpenFlow
instance number configured. If a number of 10 is configured, this equates to a in hexadecimal. The

switches will thus have a DPID that starts with: 00:0a.


Least significant 48 bits: Switch MAC address.
Associate a single VLAN or multiple VLANs to the instance using the classification vlan command:
[C2-of-inst-1] classification vlan 20
This command isn't effective until the active instance command is issued.
[C2-of-inst-1]

A controller ID and IP address must to be specified. You could configure multiple controllers for
redundancy and load balancing. In this case, only one controller is configured, based on the topology in
Figure 3-68.
[C2-of-inst-1] controller 1 address ip 192.168.56.11

The last step is to activate the instance. Changes are not active (applied) without this command:
[C2-of-inst-1] active instance

Adding flows

Figure 3-68: Topology for adding flows to HP ProVision and Comware switches
In this section, you will learn how to configure flows on the following HP switches. The example
topology in Figure 3-68 illustrates the switches locations.
Comware Switch 2 (C2)
ProVision Switch 1 (P1)
ProVision Switch 2 (P2)

You will view OpenFlow tables and flow entries on both Comware and ProVision and see how a
network containing OpenFlow and non-OpenFlow switches interacts.
In the following example, instructions will also use Flow Maker Deluxe to add and delete flows to HP
switches and test effects of OpenFlow flow entries on traffic forwarding.

View the OpenFlow instance on a Comware switch


In the preceding section, you learned to activate an OpenFlow instance on a Comware switch. To then
view this instance, use the display openflow instance command. Following is example output from this
command for instance 1, which you learned to configure in the previous section:
[C2] display openflow instance 1
Instance 1 information:
Configuration information:
Description : -Active status : Active
Inactive configuration:
None
Active configuration:
Classification: VLAN, total VLANs(1)
20
In-band management VLAN, total VLANs(0)
Empty VLAN
Connect mode: Multiple
MAC address learning: Enabled
Flow table:
Table ID(type): 0(Extensibility), count: 5
Flow-entry max-limit: 65535
Datapath ID: 0x0001784859392f96
Port information:
Ten-GigabitEthernet1/0/2
Ten-GigabitEthernet1/0/4
Active channel information:
Controller 1 IP address: 192.168.56.11 port: 6633
[C2]

As this example output suggests, you should see an active channel to the controller that is listening on port
6633, which is the OpenFlow port. You can view OpenFlow controller information for an instance 1 by
typing the display openflow instance <instance number> controller command. Following is an example of

this commands output using instance 1:


[C2] display openflow instance 1 controller
Instance 1 controller information:
Reconnect interval: 60 (s)
Echo interval : 5 (s)
Controller ID : 1
Controller IP address : 192.168.56.11
Controller port : 6633
Controller role : Equal
Connect type : TCP
Connect state : Established
Packets sent : 4370
Packets received : 1598
SSL policy : -VRF name : -[C2]

As the example output suggests, the output should show an established connection to the controller using
TCP port 6633.

View OpenFlow information on a ProVision switch


Use the show openflow command to view OpenFlow information on ProVision switches. Following is
example output using OpenFlow switch P1.
OpenFlow : Enabled
IP Control Table Mode : Disabled
Egress Only Ports Mode : Disabled
Instance Information

P1#

As you see from the example output, the show openflow command displays all OpenFlow instances
configured on the switch with their statuses and flow data. In the example, the negotiated version of
OpenFlow, for instance, vlan30the only instance configured on this switchis 1.3. This is dependent
on the versions supported by both the switch and the controller.

The operational status of this instance is Up. The status can be Down if there is a communication issue
between the controller and the switch. The number of hardware (6) and software flows (4) are also
shown.
To view information about a specific instance, use the show openflow instance command. Following is
output for this command using switch P1 and instance vlan30:
Configured OF Version : 1.3
Negotiated OF Version : 1.3
Instance Name : vlan30
Admin. Status : Enabled
Member List : VLAN 30
Listen Port : None
Oper. Status : Up
Oper. Status Reason : NA
Datapath ID : 001e1458d0f0db80
Mode : Active
Flow Location : Hardware and Software
No. of Hw Flows : 6
No. of Sw Flows : 4
Hw. Rate Limit : 0 kbps
Sw. Rate Limit : 100 pps
Conn. Interrupt Mode : Fail-Secure
Maximum Backoff Interval : 60 seconds
Probe Interval : 10 seconds
Hw. Table Miss Count : NA
No. of Sw Flow Tables : 1
Egress Only Ports : None
Table Model : Policy Engine and Software

P1#

Use the show openflow controllers command to view controller information for ProVision switches.
Following is example output for P1
P1# show openflow controllers

Controller Information

P1#

If you were to now configure instance vlan40 on switch P2 using the following commands and then launch
the controller interface, you would see three switches in the interfaces Topology view: C1, P1, and P2.
Figure 3-69 displays the topology. By default, the interface displays the switches as <IP address>:
<OpenFlow instance number>. You can change this display by pressing the n key.
In the figure, no connections are shown between the switches because they are separated by a nonOpenFlow enabled routing device (C1).

Figure 3-69: Topology view of switches C2, P1, and P2

Add flows using Flow Maker Deluxe


You can use the Flow Maker Deluxe SDN application to manually add flows to HP ProVision and
Comware switches. As you learned in the previous sections, when you install SDN applications on an HP
VAN SDN Controller, they are available in the controllers interface, as the screen capture in Figure 3-70
illustrates. To add a flow, open Flow Maker Deluxe by clicking it in the interface menu.

Figure 3-70: Flow Maker Deluxe


Select the switch on which you want to add the flow. When you have selected the switch, click Add.
Flow Maker Deluxe displays the Add dialog box, which enables you to enter the details of the flow.
Figure 3-71 displays the interface with the following flow details.
Table ID:200
Priority: 61000
Source IP: 10.30.30.3
Source Netmask: 255.255.255.255
Dest. IP: 10.40.40.4
Dest. Netmask: 255.255.255.255
IP Protocol: ICMP
Ethernet Type: IPv4
Save Flow: True

Figure 3-71: Flow Maker Deluxe Add dialog


Flow Maker Deluxe adds the new flow, as illustrated in Figure 3-72. The new flow entry is framed in
green. Could a user successfully ping a work station 10.40.40.4 from a 10.30.30.3? If you refer to the new
flow, you will see the answer to this question is yes, as illustrated in the following example output:
C:\Users\Student> ping 10.40.40.4
Pinging 10.40.40.4 with 32 bytes of data:
Reply from 10.40.40.4: bytes=32 time=2ms TTL=255
Reply from 10.40.40.4: bytes=32 time<1ms TTL=255
Reply from 10.40.40.4: bytes=32 time<1ms TTL=255
Reply from 10.40.40.4: bytes=32 time<1ms TTL=255
Ping statistics for 10.40.40.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 0ms
C:\Users\Student>

Figure 3-72: Updated flow table


Even though the new flow has a higher priority, it is in table 200, which is checked after table 100 in the
OpenFlow pipeline. Pings succeed because they match the miss rule in table 100 which sends traffic to
the traditional pipeline. The new flow entry is not read in this example.
If you were to update a switchs flow table to include the flow outlined in green in Figure 3-73, however,
a ping from 10.30.30.3 to 10.40.40.4 would fail because it would match the new entry. This entry has no
action. The switch would therefore drop the ping.

Figure 3-73: Updated flow table


If you were to refresh the flow table in Figure 3-73 by clicking Refresh on the menu, you would see the
number of packets the switch received for the flow entry increase to 4, as Figure 3-74 illustrates.

Figure 3-74: Refresh after ping


If you were to delete this flow and add the flow illustrated in Figure 3-75, which is outlined in green,
could a user ping Facebook.com (192.168.56.53) from workstation 10.20.20.2? In this example, traffic
matches the new flow entry, and because the new entry has no action, the switch drops it. This flow
prevents the user from accessing Facebook.com.

Figure 3-75: Table with new Facebook flow

Questions
The following questions will help you retain what you have learned in this section.
Question 1
Refer to Figure 3-76.
What is the result of the following flow entries?
ICMP traffic from 10.1.1.1 to 10.1.1.2
HTTP traffic from 10.1.1.2 to 10.1.1.1

Figure 3-76: Reference flow for Question 1


_________________________________________________________________
_________________________________________________________________
Question 2
Refer to Figure 3-77.
What is the result of the following flow entries?
-ICMP traffic from 10.1.1.1 to 10.1.1.2
-HTTP traffic from 10.1.1.2 to 10.1.1.1

Figure 3-77: Reference flow for Question 2


_________________________________________________________________

_________________________________________________________________
Question 3
Refer to Figure 3-78.
What is the result of the following flow entries?
-ICMP traffic from 10.1.1.1 to 10.1.1.2
-HTTP traffic from 10.1.1.2 to 10.1.1.1

Figure 3-78: Reference flow table for Question 3


_________________________________________________________________
_________________________________________________________________
Question 4
Refer to Figure 3-79.
Which version of OpenFlow has been negotiated by the HP switches?

Figure 3-79: Reference for Question 4


_________________________________________________________________

_________________________________________________________________
Question 5
Refer to the OpenFlow flow in Figure 3-80.
Explain how ICMP traffic is processed in this switch pipeline. Assume that traffic arrives on port 2 of the
switch.

Figure 3-80: Reference screen capture (Flow Monitor Flows view) for Question 5
_________________________________________________________________
_________________________________________________________________
Question 1 answer
The OpenFlow pipeline has tables 100, 150, and 200. Table 100 is the first table in the pipeline.
ICMP traffic from 10.1.1.1 to 10.1.1.2 matches the entry in table 100 with priority 100. The traffic is
forwarded to table 200 for processing. ICMP is matched by entry with priority 100 in table 200 and is

forwarded out port 1.


HTTP traffic from 10.1.1.2 to 10.1.1.1 matches the entry in table 100 with priority 200. The action is
blank, and thus the traffic is dropped.
Question 2 answer
The OpenFlow pipeline has tables 100 and 200. Table 100 is the first table in the pipeline.
ICMP traffic from 10.1.1.1 to 10.1.1.2 does not match any entries in table 100. There is also no table miss
entry in table 100. The traffic is therefore dropped.
HTTP traffic from 10.1.1.2 to 10.1.1.1 matches the entry in table 100 with priority 200. The traffic is
forwarded to table 200 for processing. There is no explicit match for HTTP in table 200. There is
however a table miss entry in table 200 (priority 0, empty match). HTTP traffic is matched by the table
miss and forwarded out of port 2.
Question 3 answer
The OpenFlow pipeline has tables 100 and 200.
Table 100 is the first table in the pipeline. ICMP traffic from 10.1.1.1 to 10.1.1.2 matches the three
entries in table 100. However, the flow entry with the highest priority is selected. In this case, flow entry
with priority 200 is used to forward the traffic out of port 3.
HTTP traffic from 10.1.1.2 to 10.1.1.1 only matches the table miss entry in table 100. The traffic is
forwarded out of port 2.
Question 4 answer
Three switches are displayed. The switches have negotiated to use OpenFlow 1.3.
Question 5 answer
In the flow table (Figure 3-80) the following takes place:
1. Port 2 is an OpenFlow-enabled port. ICMP traffic arriving on the port will therefore use the OpenFlow
pipeline for forwarding decisions.
2. Arriving traffic is first matched on the entries in the first OpenFlow table in the pipeline (Table 0).
This table has a single entry which is a table miss entry. A table miss entry has a blank match field which
implies match everything and has a priority of zero.
The entry has a goto statement to send traffic to table 100.
ICMP traffic matches this flow entry and is sent to table 100 for further processing.
3. The ICMP traffic is then checked against entries in table 100 in descending priority order. The highest
priority entry is 60,000. That however is matching BDDP and thus ICMP traffic does not match this entry.
Entries with priority 31,500 are only matching DHCP traffic and entry with priority 31,000 is matching
ARP traffic.
ICMP traffic is therefore not matched by any table entries in table 100 except for the table miss (match
everything).
The table miss entry (priority 0) has a apply_action of output to NORMAL. This OpenFlow port sends
traffic to the traditional routing and switching pipeline.
4. The ICMP traffic is then switched based on information stored in the traditional pipeline tables (MAC

address table, routing table, and so forth).


The ICMP traffic is not switched in software using table 200 in this example, but is switched by an ASIC
using information in table 100.

Summary
In this chapter, you learned how to check the software and hardware requirements for the HP VAN SDN
Controller using the HP VAN SDN Controller support matrix.
There are specific network, OpenFlow, hardware, and software requirements for the controller. These
should be in place before HP VAN SDN Controller software is installed.
You also learned where to download the controller software and how to install both the prerequisite
software and the actual HP VAN SDN Controller Debian package. You then learned how to verify the
successful installation of the HP VAN SDN Controller.
In addition, you learned how to integrate Mininet and the HP VAN SDN Controller and about options
available on the OpenFlow topology diagram.
You learned about the steps you would need to take to install a HP SDN App Store application on the HP
VAN SDN Controller and about the steps you would take to use the application to manipulate flow entries
on both Mininet virtual switches and HP switches.

Figure 3-81: The SDN architecture


You saw a practical implementation of the SDN architecture of applications (Flow Maker), controller
(HP VAN SDN Controller), and infrastructure (Mininet and HP switches), as illustrated in Figure 3-81.

Learning check
The following questions will help you review the concepts you have learned in this chapter.
1. A controller is configured with IP address 192.168.56.7. What is the correct URL for the controller
user interface?
a. http://192.168.56.7:8443/sdn/ui

b. https://192.168.56.7:8080/sdn/ui
c. https://192.168.56.7:8443/sdn/ui
d. https://192.168.56.7:8443/ui
e. https://192.168.56.7:8080/sdn/
2. An HP Comware switch has a Datapath ID of 0x000a44319261000e. How was the DPID calculated?
a. The switch has a MAC address of a44319261000e. An instance of OpenFlow was enabled on
VLAN 10.
b. The switch has a MAC address of 000a44319261. An instance of OpenFlow was enabled with
instance number 14.
c. The switch has a MAC address of 44319261000e. An instance of OpenFlow was enabled with
instance number 10.
d. The switch has a MAC address of 000a44319261. An instance of OpenFlow was enabled with
instance number 14.
3. An HP ProVision switch running K/KA15.17 is configured with an OpenFlow instance sales. The
command version 1.3 has been configured on the instance. Which version of OpenFlow will be used
by the switch instance?
a. The switch will negotiate with a configured controller to always use OpenFlow 1.3. If the
controller does not support OpenFlow 1.3, the switch will continue to use traditional pipeline
processing.
b. The switch will negotiate with a configured controller to use the highest supported OpenFlow
version. If the controller supports OpenFlow 1.3, the version of OpenFlow used will be
OpenFlow 1.3.
c. OpenFlow version 1.0 will be used as version 1.0 is the highest supported version. The command
will be accepted by the switch, but not activated until a supported version of firmware is loaded
on the switch.
d. The switch will negotiate with a configured controller to use the highest supported OpenFlow
version. If the controller supports OpenFlow 1.0, the version of OpenFlow used will be
OpenFlow 1.3.

Learning check answers


1. c
2. c
3. b

Chapter 4
HP Network Protector SDN Application
EXAM OBJECTIVES
In this chapter, you learn to:
Install and configure the HP Network Protector Application
Explain Network Protector licensing
Integrate Network Protector with HP switches
Explain and configure Network Protector features including
DNS interception
Redirection servers
Custom blacklists, graylists, and whitelists
Quality of service (QoS)
Access Control List (ACL) Manager

Assumed knowledge
HP Comware and HP ProVision switch command line interface (CLI)
IP addressing
Basic routing protocols
Basic Internet protocols

Introduction
In this chapter, you will learn about the HP Network Protector SDN Application (version 1.3). The HP
Network Protector SDN Application leverages HP Networking, TippingPoint, and ArcSight products to
deliver a converged solution that addresses security threats in a completely new way by leveraging the
network itself.

Figure 4-1: Overview of the HP Network Protector SDN Application


Network Protector uses OpenFlow on access layer switches. When a switch boots and connects to an HP
VAN SDN Controller with Network Protector, a default flow is pushed to the device. This is in addition
to the flows installed on the device by the base controller to support a hybrid environment. The flow entry
forwards all IP-UDP Port 53 (Domain Name ServiceDNS) traffic to the Network Protector
Application on the controller. Figure 4-1 illustrates the Network Protector architecture.
When a switch receives DNS traffic, it is forwarded to the controller. On the controller, the request is
compared to the TippingPoint Reputation Database (RepDV). If there is a match, meaning the traffic is
malicious in nature, Network Protector creates a DNS response and sends it to the switch to be
forwarded to the client. Multiple response types can be returned, including host not found. This provides
an immediate failure to the requesting client so that it does not have to wait for a timeout or attempt
further resolution. Another option is to redirect a client to a server of the administrators choice. In this
case, the client could be provided feedback that the request was blocked due to company security policy.
With either option, the malicious traffic will be blocked.
If the DNS request does not match the RepDV database or other custom blacklists or graylistsmeaning
the traffic should be permittedNetwork Protector instructs the switch to forward the traffic normally.

HP VAN SDN Controller


HP Network Protector is deployed as an application that runs on top of the HP VAN SDN Controller. As a
stand-alone application bundled with the controller, it leverages several controller features and
subsystems, such as application manager, pipeline manager, licensing infrastructure, Cassandra database,
SKI UI framework, Representational State Transfer (REST) API framework, audit, alert, support logs,
and others.

OpenFlow-enabled switches
One of the basic requirements for the application is OpenFlow-enabled switches. OpenFlow is the
mechanism by which the application instructs the discovered switches to redirect all DNS traffic toward
itself. There are several security policies supported in the application, which are implemented by using
the OpenFlow protocol to push desired flows on the switches. Currently, OpenFlow 1.0 and OpenFlow
1.3 are supported.

The switch firmware plays an important role in the proper functioning of the application. ProVision
switch firmware version 15.15 and above supports an additional switch feature called service insertion,
which helps send DNS data traffic to the switch using switch hardware, bypassing the switch CPU and
therefore enhancing performance. Packet processing using the switch CPU is slower than packet
processing using switch hardware.
Switch capabilities and extensions or lack thereof have significant impact on how much actual packet
processing needs to be handled by the application. A base level OpenFlow switch with no service
insertion is the most rudimentary environment, and all inspected traffic and control is shared on the
OpenFlow interface port. Best performance is achieved with switches that support OpenFlow and
service insertion.
Network Protector provides value by blocking malicious traffic as close to the source as possiblethus
stopping the traffic from traversing the network and possibly infecting other clients. This also reduces the
consumption of bandwidth on the network and of resources on a centrally located intrusion protection
system (IPS).
Network Protector complements a properly deployed IPS solution but does not eliminate the need for
IPSs.

ArcSight CEF Logger


ArcSight is a universal log management solution that unifies logs across the network for the purpose of
collecting, storing, and searching them. HP ArcSight Logger can improve compliance, risk management,
security intelligence, IT operations, and efforts that prevent insider and advanced persistent threats. This
universal log management solution collects machine data from any log-generating source and unifies the
data for searching, indexing, reporting, analysis, and retention. And in the age of bring-your-own-device
(BYOD) and mobility, it enables comprehensive management of an increasing volume of log data from an
increasing number of sources.
HP Network Protector supports ArcSight Common Event Format (CEF) syslog output so events can be
sent directly to ArcSight Logger for enterprise visibility. ArcSight CEF is compatible with many generic
syslog servers and supports all standard syslog servers.

HP Intelligent Management Center


HP Network Protector exposes a REST interface that Intelligent Management Center (IMC) can use to get
information about policies and statistics. The application can also use the IMC User Access Management
(UAM) modules REST API for getting end user correlations using the IP and MAC addresses of the end
points as collected from the DNS packets received in the application.

Frequently asked questions


What is required to implement Network Protector?
Network Protector requires OpenFlow-enabled switches at the access layer of the network. It is installed
as an application on the HP VAN SDN Controller. The controller can be deployed as a virtual machine or
on a bare metal server. However, higher network throughputs can be supported when it is installed on a
bare metal server.

Does Network Protector eliminate the need for an IPS?

No, Network Protector uses the reputation services from TippingPoint. A TippingPoint IPS can enforce
vulnerability assessment in addition to reputation.

Where should Network Protector be deployed?


Network Protector should be deployed local to the LAN it is configured to protect. Network Protector
works by redirecting network DNS requests to the Network Protector application. Any additional latency
added by a remote connection could impact the user experience.

HP TippingPoint Reputation DV service


TippingPoint Reputation Digital Vaccine (RepDV) is a subscription service that enables organizations to
monitor and block inbound and outbound communications with known malicious and undesirable hosts.
RepDV is a robust security intelligence feed powered by advanced analytics and a global reputation
database of IPv4, IPv6, and DNS names.

Figure 4-2: HP TippingPoint Reputation DV service


The RepDV database includes more than a million known malicious or undesirable hosts collected from
HP TippingPoint ThreatLinQ global intelligence network, DVLabs malware repository and honeypot
network, third-party commercial sources, and open source blacklists (see Figure 4-2). A threat score of
1100 is assigned to each entry based on DVLabs analysis of the activity, source, category, and threat.
Customers can tune RepDV policies based on reputation score, category, or geolocation to meet custom
security requirements. RepDV is updated multiple times a day to stay ahead of emerging threats and
reduce customers security risks.
The application interfaces with the RepDV cloud service to download the RepDV database and update its
local copy of the same. After it is filtered based on policies defined within the application, this database

forms the basis of DNS hostname comparisons. The application polls the service for updates every 2
hours (adjustable from the GUI) to keep itself updated with the latest threats.

Service insertion tunnels


Overview
Network Protector uses OpenFlow protocol to redirect DNS traffic from the switch to the application and
there compares it against TippingPoint RepDV to make forwarding or blocking decisions (see Figure 43). However, packets of new flows need to be copied to switch CPUs for processing and then redirected
to the Network Protector application, limiting performance in the range of tens of megabits per second.

Figure 4-3: Service insertion tunnels


To maximize the performance and keep the switch doing what it does best, packets switching, the switch
hardware is used to pipe traffic directly to the Network Protector application, yielding potential
performance improvement in the gigabits-per-second range or line rate. In other words, packets are
forwarded by switch hardware through a service insertion tunnel instead of by a switch CPU via the
OpenFlow port. The desired best performance for the application is achieved with switches that support
OpenFlow and tunnel technology for service insertion.

Hardware IP tunnels
Hardware IP tunnels are used to enable service insertion. They are presented as virtual ports to the
OpenFlow agent running on the switch. Once a tunnel is created (by the HP Network Protector SDN
Application, for example) the OpenFlow agent is notified about the presence of the new interface. The
OpenFlow agent communicates this interface as a new logical port to the SDN controller. This logical
port is advertised over all OpenFlow version 1.3 instances configured on the switch.
If the OpenFlow output port action for a flow rule points to a tunnel logical port, the packets matching this

flow rule are diverted to the configured tunnel endpoint via the tunnel interface.
When a frame is encapsulated and sent to the controller, the frame includes the MAC headers and the
VLAN tag. Even if the original frame was not VLAN tagged, the switch VLAN tags this frame with the
VLAN-ID set to the incoming ports default VLAN before encapsulating it. Since frames are
encapsulated, the path that the encapsulated packet traverses must be configured with a larger maximum
transmission unit (MTU).
Up to 16 unique tunnel interfaces can be created to actively forward traffic.

Hardware IP tunnels
Tunnels can be created using Simple Network Management Protocol (SNMP). The switch manages
tunnels, with each tunnel being represented by a unique interface index. The first step is for the
application (such as the HP Network Protector SDN Application) to query a switch to determine if it
supports configuring tunnels. This is accomplished via an SNMP object that returns the number of tunnel
interfaces supported on the switch. Once it is determined that tunnels can be configured, the controller can
move to the next stepcreating the appropriate interface.
Note
For more information, see the HP Service Insertion Guide Wired Switches K/KA/WB 15.18:
h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04777815

Installation
This section explains how to install HP Network Protector SDN Application. But before you install it,
you need to ensure that HP VAN SDN Controller hybrid settings are correctly configured. The following
scenario is intended to help you understand these settings.

SDN example scenario: Understand controller hybrid settings


Your managers question
Your manager found the website www.opennetworking.org while researching OpenFlow. He has some
technical questions for you and asks What is an OpenFlow NORMAL port?
Note
If you are unsure of the answers, download version 1.3.2 of the OpenFlow specification:
http://bit.ly/1Lze7FV

Response
OpenFlow specification:
NORMAL: Represents the traditional non-OpenFlow pipeline of the switch. Can be used only as an
output port and processes the packet using the normal pipeline. If the switch cannot forward packets from
the OpenFlow pipeline to the normal pipeline, it must indicate that it does not support this action.

Note
OpenFlow Switch Specification, Version 1.3.2, 4.5 Reserved Ports, page 12. Available at:
http://bit.ly/1Lze7FV

Your managers question


Your manager then asks: What is an OpenFlow hybrid switch?

Response
OpenFlow specification:
OpenFlow-compliant switches come in two types: OpenFlow-only and OpenFlow-hybrid. OpenFlowonly switches support only OpenFlow operation, in these switches all packets are processed by the
OpenFlow pipeline, and cannot be processed otherwise.
OpenFlow-hybrid switches support both OpenFlow operation and normal Ethernet switching operation,
that is, traditional L2 Ethernet switching, VLAN isolation, L3 routing (IPv4 routing and IPv6 routing), and
ACL and QoS processing. These switches must provide a classification mechanism outside of OpenFlow
that routes traffic to either the OpenFlow pipeline or the normal pipeline. For example, a switch may use
the VLAN tag or input port of the packet to decide whether to process the packet using one pipeline or the
other, or it may direct all packets to the OpenFlow pipeline. This classification mechanism is outside the
scope of this specification.
An OpenFlow-hybrid switch may also allow a packet to go from the OpenFlow pipeline to the normal
pipeline through the NORMAL and FLOOD reserved ports.
Note
OpenFlow Switch Specification, Version 1.3.2, 5.1 Pipeline Processing, page 13. Available at:
http://bit.ly/1Lze7FV

Your managers question


The HP VAN SDN Controller and switches support an additional hybrid mode. How is that different
than the OpenFlow specification?

Response
OpenFlow specification
OpenFlow-hybrid switches support both OpenFlow operation and normal Ethernet switching operation.
That is, traditional L2 Ethernet switching, VLAN isolation, L3 routing (IPv4 routing, IPv6 routing, and
ACL, and QoS processing.
HP VAN SDN Controller Administrator Guide
The hybrid mode setting determines which packet-forwarding decisions are made by controlled
OpenFlow switches and which of these decisions are made by the controller itself.

If hybrid mode is enabled (the default setting), the controller delegates normal packet forwarding to the
controlled switches, but overrides these switches for nonstandard packet-forwarding decisions
required by installed applications for specific packet types. In this mode, the controller relies on the
controlled switches to resolve loops and determine forwarding paths by using traditional networking
mechanisms (such as Spanning Tree Protocol [STP] and Open Shortest Path First [OSPF]).
If hybrid mode is disabled, the controller makes the forwarding decisions for all packets in the
OpenFlow-controlled network. In this state, the controller resolves network loops and determines
forwarding paths.
Note
HP VAN SDN Controller 2.5 Administrator Guide, page
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647289

65.

Available

at:

Resource
The following technical whitepaper explains hybrid processing mode:
Note
Technical white paper: HP SDN hybrid network architecture:
Link: http://bit.ly/1OusKIG

Verify that hybrid mode is enabled on the controller


The following instructions will show you how to confirm that hybrid mode is enabled on HP VAN SDN
Controllers.
1. Open Google Chrome on a Windows desktop:
2. Navigate to: https://<controller IP address>:8443/sdn/ui
3. The HP VAN SDN Controller uses a self-signed certificate by default. Accept the certificate and
proceed to log in.
4. If prompted, log in with the following credentials:
Username: sdn
Password: skyline
5. Click Configurations, as illustrated in Figure 4-4:

Figure 4-4: HP VAN SDN Controller Configurations menu selection


6. Select com.hp.sdn.ctl.of.impl.ControllerManager.

Figure 4-5: HP ControllerManager settings


If hybrid mode is enabled, the value of the hybrid.mode key is true, as illustrated in Figure 4-5.

Setting options
Setting options are
true (the default): Enables hybrid mode. The controller makes packet-forwarding decisions only as
required by installed applications.
false: Disables hybrid mode. The controller makes all forwarding decisions.
Important
HP recommends that hybrid mode be set to true when controlling traditional, established networks.
In these cases, the HP VAN SDN Controller and SDN applications-related traffic is responsible for
only a subset of the overall traffic load on the network.
Hybrid mode is commonly enabled in established networks where new applications are installed
on the controller and need to override normal switching behavior for specific flows

Support matrix
Confirm current requirements for the HP Network Protector SDN Application by reviewing sections of
the Support Matrix document.
Note
HP
VAN
SDN
Controller
and
Applications
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647298

Support

Matrix

Questions and answers


Question
Which version of HP Network Protector is supported on version 2.5 of the HP VAN SDN Controller?
Answer
Version 2.5 of the HP VAN SDN Controller supports version 1.3 of the HP Network Protector
Application.
(HP VAN SDN Controller and Applications Support Matrix, Section 3.1, page 19. Available at:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647298)
Question
Is controller teaming supported in version 1.3 of the HP Network Protector SDN Application?
Answer
No, teaming is not supported in version 1.3, but may be supported in later releases.
Note
HP VAN SDN Controller and Applications Support Matrix, Section 3.1, page 19. Available at:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647298
Question
Does the HP Network Protector SDN Application require hybrid-mode on the HP VAN SDN Controller
and HP switches?
Answer
Yes, the HP Network Protector SDN Application requires OpenFlow-hybrid networks.

Note
HP VAN SDN Controller and Applications Support Matrix, Section 3.5.1, page 20. Available at:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647298
Question
Which switches are supported in version 1.3 of the HP Network Protector SDN Application?
Answer
ProVision switches: 2920, 3500, 3800, 5400zl, 5400R, 6200, 6600, 8200zl.
Comware switches: 5500HI
Others: Open vSwitch
Note
HP VAN SDN Controller and Applications Support Matrix, Section 3.5.2. Available at:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647298

Install the HP Network Protector SDN Application


The HP Network Protector SDN Application is installed via the HP VAN SDN Controller GUI interface,
just as Flow Maker Deluxe was in Chapter 3.
1. To log in to the HP VAN SDN Controller, open a browser window and enter the following web
address: https://<IP_Address_of_controller>:8443/sdn/ui
2. Enter username and password credentials and click Login.
3. The main HP VAN SDN Controller page appears.
4. Navigate to GeneralApplications.
5. Select NewBrowse. Navigate to the location where the application zip file
(com.hp.sdn.app.networkprotector_v1.3.X.YYY.zip) is saved on your machine and click Open.
6. Select Upload to upload the application.
7. Select Deploy to deploy the application.
The application is installed, as shown in Figure 4-6.

Figure 4-6: HP Network Protector SDN Application is installed

Summary
In this section, you learned about hybrid switches and hybrid mode. You learned that a hybrid switch
supports both an OpenFlow pipeline (OpenFlow only) and a traditional routing and switching pipeline.
You also learned about hybrid processing mode (or hybrid mode), which enhances traditional routing and
switching functionality rather than replacing it.
You learned to install HP Network Protector SDN Application on an HP VAN SDN Controller.

Questions
The following questions will help you retain the concepts and information you learned in this section.
Figure 4-7 lists the major concepts.

Figure 4-7: Example topology


Question 1: What is the NORMAL OpenFlow port?
_________________________________________________________________
Question 2: What is the difference between a hybrid switch according to the OpenFlow specification and
HPs hybrid processing mode as defined on an OpenFlow instance?
_________________________________________________________________
Question 3: Is hybrid mode the default mode on an HP VAN SDN Controller (version 2.5)?
_________________________________________________________________
Question 4: Is the HP Network Protector SDN Application an internal application or an external
application?
_________________________________________________________________
Question 5: Which traffic does HP Network Protector SDN Application intercept by updating flow
tables on OpenFlow switches?
_________________________________________________________________
Question 6: Which OpenFlow switch mode does the HP Network Protector SDN Application require?
_________________________________________________________________
Question 7: Which subscription based service database contains over one million malicious domains?
_________________________________________________________________
Question 8: Which HP hardware-based switch feature increases throughput for intercepted packets
forwarded to the HP VAN SDN Controller?

_________________________________________________________________
Question 9: Which switch feature requires SNMP v3 for dynamic configuration by the HP Network
Protector SDN Application?
_________________________________________________________________
Question 10: Can HP Network Protector SDN Application be used without the RepDV database?
_________________________________________________________________
Question 11: What type of tunnel is a service insertion tunnel?
_________________________________________________________________
Question 12: Which HP VAN SDN Controller version does HP Network Protector SDN Application
version 1.3 require?
_________________________________________________________________
Question 1 answer
NORMAL: Represents the traditional non-OpenFlow pipeline of the switch. Can be used only as an
output port and processes the packet using the normal pipeline. If the switch cannot forward packets from
the OpenFlow pipeline to the normal pipeline, it must indicate that it does not support this action.
Question 2 answer
HP Hybrid mode: If hybrid mode is enabled (the default setting), the controller delegates normal packet
forwarding to the controlled switches, but overrides these switches for nonstandard packet-forwarding
decisions required by installed applications for specific packet types.
OpenFlow specification: OpenFlow-hybrid switches support both OpenFlow operation and normal
Ethernet switching operation, that is, traditional L2 Ethernet switching, VLAN isolation, L3 routing (IPv4
routing and IPv6 routing), and ACL and QoS processing. These switches must provide a classification
mechanism outside of OpenFlow that routes traffic to either the OpenFlow pipeline or the normal
pipeline.
An OpenFlow-hybrid switch may also allow a packet to go from the OpenFlow pipeline to the normal
pipeline through the NORMAL and FLOOD reserved ports.
Question 3 answer
Yes. Hybrid mode is the default mode on version 2.5 of the HP VAN SDN Controller (this has been true
since version 2.2).
Question 4 answer
The HP Network Protector SDN Application is an internal SDN application. Internal applications are
installed via the controller graphical user interface (GUI). These applications are typically written in
Java and use the controller Java API. Examples include the HP Network Protector, HP Network
Visualizer, and HP Optimizer SDN applications. These applications provide reactive and proactive
services. In other words, they can react to OpenFlow events such as a packet-in message from an
OpenFlow switch.
Question 5 answer
OpenFlow is the mechanism by which HP Network Protector SDN Application instructs OpenFlow

switches to redirect all DNS traffic toward itself (via the HP VAN SDN Controller).
Question 6 answer
The HP Network Protector SDN Application requires OpenFlow-hybrid networks.
Question 7 answer
TippingPoint RepDV is a subscription service that enables organizations to monitor and block inbound
and outbound communications with known malicious and undesirable hosts.
The RepDV database includes more than a million known malicious or undesirable hosts collected from
HP TippingPoint ThreatLinQ global intelligence network, DVLabs malware repository and honeypot
network, third-party commercial sources, and open source blacklists.
Question 8 answer
Service insertion helps send DNS data traffic to the switch using switch hardware, bypassing the switch
CPU, thereby enhancing performance. Packet processing using the switch CPU is slower than the packet
processing using switch hardware.
Switch capabilities and extensions or lack thereof have significant impact on how much actual packet
processing needs to be handled by the application. The base level OpenFlow switch with no service
insertion is the most rudimentary environment and all inspected traffic and control is shared on the
OpenFlow interface port. Best performance is achieved with switches that support OpenFlow and
service insertion.
Question 9 answer
Service insertion tunnels are created using SNMP. If you do not provide SNMPv3 credentials, then the
application communicates with the switch through the OpenFlow channel.
Question 10 answer
Yes, in addition to the RepDV database, you can add blacklist entries of host names to restrict access.
When a user accesses a domain listed in the blacklist, the application drops the traffic and the statistics of
end users trying to access the blacklist sites is updated in the logs. When you generate reports based on
the total number of blocked DNS requests or malicious DNS requests, then the reports contain the
blacklist DNS entries along with the RepDV database.
Note
You will not have access to all Network Protector features without the RepDV subscription
service.
Question 11 answer
A service insertion tunnel is a Generic Routing Encapsulation (GRE) tunnel.
Question 12 answer
HP Network Protector SDN Application 1.3 requires version 2.5 of the HP VAN SDN Controller.

HP VAN SDN Controller Licenses

The following licenses are available for the HP VAN SDN Controller, as shown in Figure 4-8.

Figure 4-8: HP VAN SDN Controller licenses

Base controller license


HP VAN SDN Ctrl Base SW w/ 50node E-LTU
Enables the HP VAN SDN Controller to communicate with up to 50 OpenFlow datapath IDs (DPIDs).
This license is a prerequisite for the other licenses and must be installed for you to receive technical
support during your first 90 days of use.

Base controller plus 50 Add Nodes license


HP VAN SDN Ctrl 50node E-LTU
Extends by 50 the number of DPIDs the base controller can communicate with using OpenFlow. In
addition, you can install the Add Nodes license multiple times. For example:
1. If you install one Add Nodes license on an HP VAN SDN Controller with a base license present, the
total number of OpenFlow switches supported is 100.
2. If you install three Add Nodes licenses on an HP VAN SDN controller with a base license, the total
number of OpenFlow switches supported is 200.

High Availability Add Controller license


HP VAN SDN Ctrl HA E-LTU
Enables the HP VAN SDN Controller to form a team for increased availability. The following guidelines
apply:
1. The minimum number of team members for an HP VAN SDN Controller team is three.
2. When forming a team, only one HP VAN SDN Controller base license is required, along with at least
two High Availability licenses. Once a team is formed, Add Nodes licenses can be added to the team
leader for increased support. In addition, you must:
Use unlicensed controller installations to form the team.
Use a new hardware platform (or virtual machine) with a new installation of the HP VAN SDN

Controller.
Run the same software version on all controllers.

HP Network Protector SDN licenses


The HP Network Protector SDN Application uses electronic licenses. You must have the HP VAN SDN
Controller licenses installed before you can install the HP Network Protector licenses. Figure 4-9 and
Table 4-1 display further information about HP Network Protector SDN licenses.

Figure 4-9: HP Network Protector SDN Application licenses

Table 4-1: HP Network Protector SDN application licenses


Product
number
JL004AAE
JL005AAE
JL006AAE
JL007AAE
JL008AAE
JL092AAE
JL093AAE
JL094AAE

Product description

Validity

HP Network Protector SDN Application 250 Concurrent Users E-LTU


HP Network Protector RepDV Subscription 250 Concurrent Users 1 Year ELTU
HP Network Protector RepDV Subscription 1000 Concurrent Users 1 Year ELTU
HP Network Protector RepDV Subscription 2000 Concurrent Users 1 Year ELTU

Perpetual
1 year

HP Network Protector RepDV Subscription 4000 Concurrent Users 1 Year ELTU


HP Network Protector RepDV Subscription 8000 Concurrent Users 1 Year ELTU
HP Network Protector RepDV Subscription 20,000 Concurrent Users 1 Year
E-LTU
HP Network Protector RepDV Subscription 40,000 Concurrent Users 1 Year
E-LTU

1 year

1 year
1 year

1 year
1 year
1 year

Some license considerations:


Multiple Network Protector Base licenses can be purchased
4 Network Protector Base licenses = 4 250 = 1000 users
What Network Protector Base license quantity do I need?
Answer: Number of users in a Network Protector active session of 15-minutes duration
Which Network Protector Subscription license do I need?
A subscription license whose quantity is equal to or greater than the Base license quantity
Network Protector allows the Base license count to be greater than the RepDV count during the course
of the RepDV subscription. When the RepDV subscription expires, a higher count RepDV
subscription would be required to match the base license count
The Network Protector SDN application has two types of electronic licenses:

HP Net Protector SDN App 250 User E-LTU


JL004AAE HP Net Protector SDN App 250 User E-LTU is an HP Network Protector base license. The
application base license that you purchase never expires. You need to purchase at least one application
base license. The number of base licenses you need is determined by the maximum number of concurrent
users using the application in an active session. The duration of each active session is 15 minutes.
For example, if you buy four 250user HP Network Protector SDN Application base licenses, the
maximum number of users with the application in an active session is 1000 (4 250).

Note
The HP Network Protector SDN Application user is a unique pair of a MAC and an IP addresses.

HP Net Protector RepDV subscription license


Use the HP Net Protector RepDV licenses to subscribe to the RepDV database. The HP Network
Protector RepDV subscription licenses expire after a period of 1 year. There are four HP Network
Protector RepDV subscription licenses, which cater to 250, 1000, 2000, 4000, 20,000 and 40,000 users.
The HP Network Protector RepDV subscription license you need is determined by the number of users
using the application base licenses. The HP Network Protector SDN Application user is a unique pair of
a MAC and an IP address.
For example, if you buy four 250user HP Network Protector base licenses (1000 users), then you
purchase the HP Network Protector RepDV subscription licenses for 1000 or more than 1000 users.
If you do not buy HP Network Protector RepDV subscription license, you can use the application with
your own custom lists, such as blacklist or whitelist entries. However, you will not be able to access the
TippingPoint RepDV database. If you do not renew your HP Network Protector RepDV subscription
licenses after expiry, you can access the RepDV database, but you will not receive RepDV updates from
the TippingPoint server.
During the course of the RepDV subscription, users can access RepDV subscription license counts
greater than the HP Network Protector base license count. After the RepDV subscription expires, a higher
RepDV license subscription is required to match the base license count.

HP Network Protector URLs


You add licenses to the HP VAN SDN controller as follows. Also see Figure 4-10:
HP SDN Controller Base license key:
https://<sdn_controller_ip_address>:8443/sdn/ui
HP Network Protector Application Base license key:
https://<sdn_controller_ip_address>:8443/networkprotector/ui

Figure 4-10: HP Network Protector URLs


You can obtain your product license keys from the HP My Networking portal. After purchasing the HP
Network Protector electronic licenses, you can register them on the My Networking Portal by using the
HP VAN SDN Controller Install ID and obtaining the application product license keys (see Figure 4-10
for the URL). You can also use the My Networking Portal to transfer the application licenses from one
machine to another.
For more information about how to register production licenses on the My Networking Portal, see
section 3 of the HP Network Protector SDN Application1.3 Administrator Guide available here:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647299

Check HP VAN SDN Controller license installation


Following are the instructions for checking HP VAN SDN Controller licenses.
1. Click Licenses (see Figure 4-11 for the location of the Licenses menu item):

Figure 4-11: The Licenses menu selection

In Figure 4-11, the example license is a demo license for 50 nodes.


Note
Each controller installation generates a unique Install ID that is used for licensing activities.
The license in this example is associated with install ID: 6195953439111.
Note
In the HP VAN SDN Controller version 2.5, a license is consumed per datapath identifier (DPID).
In other words, a single HP switch configured with multiple OpenFlow instances will require one
license per OpenFlow instance.

Install a test HP Network Protector SDN Application license


If you have downloaded evaluation copies of HP VAN SDN Controller and Mininet so that you can
follow the instructions in this study guide, you can also install an evaluation license of HP Network
Protector.
Use the App Store and install the Trial Mode SDN applications.
1. Install the application.
2. Log on to My Networking Portal at http://hp.com/networking/mynetworking and select SDN
Evaluation Licenses.
3. Enter your install-id. My Networking Portal generates an evaluation license for your install id.
4. Apply the relevant licenses to the application.
Note
For more information about how to register production licenses on the My Networking Portal, see
section 3 of the HP Network Protector SDN Application1.3 Administrator Guide available
here: http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647299
Following is an example of the notification you receive when you generate a Network Protector base
license. The notification includes the Controller Install ID and the license key (see Figure 4-12):
This is a confirmation of your registration with the license details:
License key:
AEETMFRDFRCBO-NJTFY7S2ARTOQ-NVM4QKEQZQKGB-RCUESCAAJEEAA
Registration ID: PCR3GVH-J8R7TTW-QDRJBDK-K6RXY89
Product number: JL004AAE
Product name: HP Net Protector SDN App 250 User E-LTU

License quantity: 1
Install ID: 6195953439111
Status: Active
Activation date: 22-Jun-2015
Expiration date: 21-Jun-2016
Friendly name: Net Protector
Customer notes:

Figure 4-12: Controller Install ID


5. Copy the license key, paste it into the Enter License box on the controller (see Figure 4-13), and click
Add:

Figure 4-13: License key pasted into the Enter License box
The license is added to the controller, as illustrated in Figure 4-14:

Figure 4-14: Successful license install for Network Protector

Network Protector Setup Wizard


To set up the application, you will need the RepDV license key and the SNMPv3 credentials of at least
one switch on your network. (Figure 4-15 illustrates an example network topology.) You can enter the
SNMPv3 credentials of up to three switches on your network. The application uses the credentials to
communicate with the switch and extract switch details. It uses these details to configure service insertion
tunnels.
If you do not provide the SNMPv3 credentials, then the application communicates with the switch through
the OpenFlow channel.

Figure 4-15: Example topography for HP Network Protector setup


Use a supported browser to access the application user interface at the following IP address:

https://<system ip_addr:8443>/networkprotector/ui, where ip_addr is the IP address of the system on


which you have installed the application.
For example: https://192.168.56.7:8443/networkprotector/ui
As Figure 4-16 illustrates, a setup wizard appears when you log in to the application for the first time.

Figure 4-16: HP Network Protector Setup Wizard


Enter the RepDV license key in the TippingPoint RepDV Activation Key field (see Figure 4-17). The
TippingPoint RepDV activation key page is displayed. Before registering the HP Network Protector
RepDV subscription license, you need to ensure that you have registered and activated the HP Network
Protector base license. The Controller requires Internet access to reach the TippingPoint RepDV Server
to check the validity of the license and to download the RepDV database.

Figure 4-17: TippingPoint RepDV details


1. Enter the proxy server and proxy port details if required (see Figure 4-17).
2. Click Next.
3. Enter SNMPv3 credentials of at least one switch. SNMPv3 credentials are used by Network
Protector to communicate with devices on the network. Figure 4-18 illustrates the Add SNMP
credentials interface. For HP Network Protector to provide protection on the network, these
configurations are required. A maximum of three SNMPv3 credentials can be entered and at least one
should be entered here.

Figure 4-18: Add SNMP credentials


Example details for entering SNMPv3 credentials:
Username: sdn
Authentication type: MD5
Authentication Password: skyline

Privacy Type: DES


Privacy Password: skyline
Timeout (ms): 10000
Retries: 2
4. Click OK.
5. Click Add.
6. Click Finish.

The HP Network Protector console


The HP Network Protector Console appears when you have successfully installed and completed the
Network Protector initial setup wizard (see Figure 4-19).

Figure 4-19: HP Network Protector Console, System Status view

Administration view
To access the HP Network Protector Console Administration views Overview page, click
Administration then click Overview. Among many other things, this view displays the status of Tipping
RepDV database updates. In the following example screen capture (Figure 4-20), you will see that the
database has not been successfully updated.

Figure 4-20: HP Network Protector Console overview page


A functioning TippingPoint database would look like the screen capture in Figure 4-21. Note the
following:
TippingPoint license is valid
TippingPoint database contains over 2 million entries.

Figure 4-21: Database successfully updated

Questions
The following questions will help you retain the information and concepts you learned in this section.
Question 1: A customer has a network consisting of the following:
40 DPIDs (one OpenFlow instance per switch) running OpenFlow 1.0
High availability is not required
Which licenses would you recommend the customer purchase (and in what quantity)?
J9863AAEHP VAN SDN Ctrl Base SW w/50-node E-LTU
J9864AAEHP VAN SDN Ctrl 50-node E-LTU
J9865AAEHP VAN SDN Ctrl HA E-LTU
_________________________________________________________________
Question 2: A customer has a network consisting of the following:
500 DPIDs (one OpenFlow instance per switch)
High availability is required
Which licenses would you recommend the customer purchase (and in what quantity)?

J9863AAEHP VAN SDN Ctrl Base SW w/ 50-node E-LTU


J9864AAEHP VAN SDN Ctrl 50-node E-LTU
J9865AAEHP VAN SDN Ctrl HA E-LTU
_________________________________________________________________
Question 3: A customer has a network consisting of the following:
100 DPIDs (One OpenFlow instance per switch) running OpenFlow 1.3
Network Protector Application with automatic reputation scores required
250 users in the network
What licenses would you recommend the customer purchase (and in what quantity)?
J9863AAEHP VAN SDN Ctrl Base SW w/ 50-node E-LTU
J9864AAEHP VAN SDN Ctrl 50-node E-LTU
J9865AAEHP VAN SDN Ctrl HA E-LTU
JL004AAEHP Net Protector SDN App 250 User E-LTU
JL005AAEHP Net Protector RepDV 250 User 1yr E-LTU
_________________________________________________________________
Question 4: Does the TippingPoint database require Internet access to function?
_________________________________________________________________
Question 5: Does Network Protector require a controller base license?
_________________________________________________________________
Question 6: Are demo licenses available?
_________________________________________________________________
Question 1 answer:
A J9863AAE license is a prerequisite for the other licenses and one license needs to be purchased. This
includes licenses for 50 DPIDs which is enough for the 40 switches (DPIDs) in the customer network.
The version of OpenFlow used by the switches does not affect licensing.
In this example, high availability is not required, so no more licenses need to be purchased.
Question 2 answer
A J9863AAE license is a prerequisite for the other licenses and one license needs to be purchased. This
includes 50 nodes (DPIDs).
The customer has 500 switches, so licenses for an additional 450 nodes (DPIDs) are required. Nine
J9864AAE (50 nodes) licenses need to be purchased.
In this example, high availability is required, so two J9865AAE (HA) licenses need to be purchased.
Version 2.5 of the HP VAN SDN Controller supports a team of three controllers.
Node licenses are shared among controllers in a team, so the above licenses are enough.
Question 3 answer

A J9863AAE license is a prerequisite for the other licenses and one license needs to be purchased. This
includes 50 nodes (DPIDs).
The customer has 100 switches (DPIDs), so licenses for an additional 50 nodes are required. 1
J9864AAE (50 nodes) license needs to be purchased.
The version of OpenFlow used by the switches does not affect licensing.
As Network Protector is required, a base Network Protector license is required (1 JL004AAEHP
Net Protector SDN App 250 User E-LTU).
Automatic reputation scores are also required. This means that 1 year RepDV license is required (1
JL005AAEHP Net Protector RepDV 250 User 1yr E-LTU).
Question 4 answer
Internet access is required to authenticate the TippingPoint RepDV license and to update the database.
After the license has been checked and the database updated, the system can be used offline. However,
this means the database entries may be outdated.
Question 5 answer
Yes. Network Protector requires an HP VAN SDN Controller base license. You need to license the
controller before licensing Network Protector.
Question 6 answer
Evaluation licenses are available.
You can use the evaluation license to install HP Network Protector and use and evaluate the product. If
you are using the App Store, install the Trial Mode SDN applications.
Install the application.
Log on to My Networking Portal at http://hp.com/networking/mynetworking and select SDN
Evaluation Licenses.
Enter your install-id.
My Networking Portal generates evaluation license for that install id.
Apply the relevant licenses to the application.

Switch configuration
OpenFlow version
OpenFlow is required on the switches in the network for HP Network Protector SDN Application to
intercept DNS queries.
In the Figure 4-22, version 1.3 of OpenFlow is used for OpenFlow instance vlan20.

Figure 4-22: Switch configuration

SNMP v3 configuration
SNMPv3 configuration on ProVision switches is required for Network Protector to operate correctly.
(Figure 4-23 provides an example SNMPv3 configuration.)

Figure 4-23: SNMP v3 configuration

WARNING
Do not use the SNMP wizard for user configuration. Enable SNMP and then manually create the
required user account (sdn in this example). It is recommended that the created initial user be
deleted unless explicitly required.
Following is an example of SNMPv3 configuration on a 3800 series switch:
P1(config)# snmpv3 enable
SNMPv3 Initialization process.

Creating user 'initial'


Authentication Protocol: MD5
Enter authentication password: *******
Privacy protocol is DES
Enter privacy password: *******
User 'initial' has been created
Would you like to create a user that uses SHA? [y/n] n
User creation is done. SNMPv3 is now functional.
Would you like to restrict SNMPv1 and SNMPv2c messages to have read only access (you can
set this later by the command 'snmpv3 restricted-access')? [y/n] y
P1(config)# snmpv3 user sdn auth md5 skyline priv des skyline
P1(config)# snmpv3 group ManagerPriv user sdn sec-model ver3

Note
The command snmpv3 restricted-access is optional.

Configure the switch to use the licensed HP Network Protector controller


The following example configuration shows you how to configure your SNMPv3-configured switch to
use the Network Protector controller:
P1(config)# openflow
P1(openflow)# controller-id 2 ip 192.168.56.12 controller-interface vlan 1
P1(openflow)# instance vlan30
P1(of-inst-vlan30)# disable
P1(of-inst-vlan30)# no controller-id 1
P1(of-inst-vlan30)# controller-id 2
P1(of-inst-vlan30)# enable
P1(of-inst-vlan30)# end
P1#

OpenFlow commands
Following is a series of commands that you can use to view OpenFlow information from the switch
interface.
show openflow instance <instance>
In the following example, the switch is configured with OpenFlow instance vlan30. You can use the
show openflow instance command to check the controllers status. Following is an example of this

commands output.
P1# show openflow instance vlan30
Configured OF Version : 1.3
Negotiated OF Version : 1.3
Instance Name : vlan30
Admin. Status : Enabled
Member List : VLAN 30
...<omitted>...
Controller Id Connection Status Connection State Secure Role
------------- ----------------- ---------------- ------ -----2 Connected Active No Equal
P1#

In this example, the switch has an active connection to controller 192.168.56.12.


show openflow <instance> flows
You can view flows on the switch and find a matching DNS using the show openflow <instance>
flows command. The following example output of this command is for instance vlan30.
...<omitted>...
Flow 6
Match
Incoming Port : Any Ethernet Type : IP
Source MAC : Any Destination MAC : Any
Destination MAC Mask : 000000-000000
VLAN ID : Any VLAN priority : Any
Source IP Address : Any
Destination IP Address : Any
IP Protocol : UDP
IP ECN : Any IP DSCP : Any
Source Port : Any Destination Port : 53
Attributes
Priority : 50301 Duration : 0 seconds
Hard Timeout : 8 seconds Idle Timeout : 0 seconds
Byte Count : NA Packet Count : 21
Flow Table ID : 100 Controller ID : 2
Cookie : 0xbadbabe

Hardware Index: 1
Instructions
Apply Actions
Output : ServiceTunnel01

show interfaces tunnel type intercept


In this example, DNS traffic is sent to the service insertion tunnel. If the example displayed output
from a 3500 switch, it would show the controller port as the output port.
If your switch is using a service insertion tunnel, you can use the show interfaces tunnel type intercept
command to view details about the tunnel. Following is example output from this command:
P1# show interfaces tunnel type intercept
Status - Service Tunnel Information Brief
Max. Supported Tunnels : 16
Total Tunnels : 1
Interface Index : 100664146
Name : ServiceTunnel01
Key : 51966
Local Address : 10.1.1.253
Remote Address : 192.168.56.12
Interface State : Up
P1#

The interface index number is displayed for the service insertion tunnel. This is the same number
shown on the HP VAN SDN Controller user interface.
show interfaces tunnel
As the following example of switch CLI shows, this command displays further details about tunnel
interfaces.
P1# show interfaces tunnel
Tunnel Configuration :
Tunnel : 100664146
Tunnel Name : ServiceTunnel01
Tunnel Status : Enabled
Source Address : 10.1.1.253
Destination Address : 192.168.56.12
Mode : Service Tunnel
TOS : 0
TTL : 64

IPv6 : n/a
MTU : 1468
Current Tunnel Status :
Interface State : Up
Destination Address Route : 0.0.0.0/0
Next Hop IP : 10.1.1.251
Next Hop Interface : vlan-1
Next Hop IP Link Status : Up
Source Address : 10.1.1.253
P1#

show interfaces tunnel type intercept statistics


As the example output for this command shows, it displays the IP address of the switch and the
controller, among many other details:
P1# show interfaces tunnel type intercept statistics
Service Tunnel Information
Aggregate Statistics
Fragmented Packets Dropped (Rx) : 0
Packets to Non-Existent Tunnel : 0
Unknown Source MAC Packets Dropped (Rx) : 0
MTU Violation Drop : 0
Service Tunnel Statistics
Interface Index : 100664146
Name : ServiceTunnel01
Rx Packets : 8468
Tx Packets : 10078
Rx 5 Minute Weighted Average Rate (Pkts/sec) : 0
Tx 5 Minute Weighted Average Rate (Pkts/sec) : 0
Rx Heartbeat : 8038
Tx Heartbeat : 8038
Last Received Heartbeat Timestamp : 10/05/00 06:18:02
P1#

Network Protector Console


Overview

The HP Network Protector console provides at-a-glance insight into your network security status with
charts and graphs that continuously update to reflect the health, status, and events related to your
network traffic (see Figure 4-24). The console also provides the status of all the switches and the
VLANs communicating with the application. This overview, composed of configurable color-coded
charts and tables, is the starting point for:
Monitoring the health and status of the devices and VLANs.
Monitoring security alerts or issues.
Troubleshooting events and issues on your network.

Figure 4-24: Network Protector Console

Logging into the console


As mentioned in the previous section, use a supported browser to access the application user interface
at the following IP address:
https://<ip_addr>:8443/networkprotector/ui
Where ip_addr is the IP address of the system on which you have installed the Network Protector
application.
For example:
https://127.0.0.1:8443/networkprotector/ui
Enter user name and password credentials, and then click Login.
The main application page displays.

The Network Protector application console provides configurable panels that enable you to view,
monitor, and analyze health, status, and events at system and switch levels. These panels provide a
high-level warning system for potential health and performance problems with your system and
devices. The system status tools monitor characteristics of system health and report on the basic health
and status of the network.

System Status panel


The System Status panel provides a graphical representation of the following system parameters. This
information is refreshed every minute.
Top ten users with most malicious queries during the past 24 hours.
Total DNS requests per hour during the past 24 hours.
Incoming DNS requests per second.
Top four VLAN groups with most malicious queries during the past 24 hours.
The latest ten blocked or quarantined hosts along with their IP addresses, MAC addresses, statuses,
and time stamps.

Device Status panel


Select Device Status to display details of the switch and the health status of the VLAN configured on
the switch, as the screen capture in Figure 4-25 illustrates.
Details include (but are not limited to):
The IP and MAC addresses of the switch
The manufacturer and model details of the switch
The firmware installed on the switch and the system integration (SI) status of the switch
Switch connection status on the VLAN

Figure 4-25: The Device Status panel


Click on the arrows to expand the details, as you see in Figure 4-25.
The application uses switch firmware information to decide if the communication with the switch is
through an OpenFlow channel or through the service insertion tunnel. For firmware versions K.15.14
and lower, Network Protector communicates with the switch through the OpenFlow channel. For
firmware versions KA.15.15.0015 and greater, Network Protector can communicate with the switch
either through the OpenFlow channel or service insertion tunnel. Figure 4-25 shows that the switch is
using a service insertion tunnel. Only switches that have version 2 ASICs and later support service
insertion. We will discuss ASICs in more detail later in this study guide. Most of the examples in this
guide use either 3800 or 3500 switches. One of these switches supports service insertion and one does
not:
3800 = v2 ASIC switch, service insertion is supported
3500 = v1 ASIC switch, service insertion is not supported
Health Status colors are as follows:
Green: The status of all the VLANs configured on the switch is Green.
Yellow: The status of one or more VLANs configured on the switch is not green. One of the VLANs
configured on the switch has been disabled from DNS inspection.
Gray: The status of all the VLANs configured on the switch is Gray.
To check the health status of the VLANs configured on the switch, select Device Status. Four colors
green, red, yellow, and graydisplay the health status of the VLANs.
1. Select Device Status on the console. The Device Status page displays the list of switches
configured.
2. Click the arrow icon next to the IP address of the switch. The list of all the VLANs configured on
the switch appears.
Hover over the Health Status of the switch connection to view the health status of the switch

connections configured on the VLAN. Table 4-2 lists VLAN health statuses.
Table 4-2: VLAN health statuses
Health status of
VLANs
Green

Red

Yellow

Gray

Description
All the conditions are true:
The VLAN is active
The VLAN instance is connected
The SNMPv3 credentials to the switch are correct
The VLAN link is stable
The current mode is reported as the maximum mode
Any one of the conditions is true:
The VLAN instance is not active
The VLAN instance is active but not connected
The SNMPv3 credentials to the switch are incorrect or not working
Generally indicates service insertion tunnel issues and any one of the
conditions is true:
The VLAN instance is not active
The link is unstable
The current inspection mode
The VLAN has been disabled from DNS inspection

Integration
Figure 4-26 shows flows programmed on a switch that has negotiated OpenFlow 1.3 with the HP VAN
SDN Controller. OpenFlow 1.3 is required for service insertion. A service insertion tunnel is
indicated in the output action of the flow that is framed in blue.

Figure 4-26: Integration


The screen capture in Figure 4-26 is from the HP VAN SDN Controller OpenFlow Monitor page. It
shows the DNS Redirect Flow (flow priority 50301) that was added by the Network Protector
application.
In this case, the flow entry sends all DNS traffic to the service insertion tunnel (output: 100664146)
and in turn to the Network Protector application.
Other flows shown have been added by the HP VAN SDN Controller core modules.

Figure 4-27: Expanded flow details


As Figure 4-27 illustrates, this flow has been configured with a hard timeout of 8 seconds. This means
that the flow entry will be removed after 8 seconds. You may see two flow entries in the switch table.
This is because of the HP Network Protector refresh interval. This ensures that if the HP Network
Protector SDN Application goes down, or the HP VAN SDN Controller goes down, flow entries will
be removed after at most 8 seconds and DNS traffic will revert to normal forwarding with Network
Protector monitoring.

Hard timeouts
Here are the details about hard timeouts from the HP Network Protector Administration guide:
Network Protector uses a rule refresher mechanism to refresh the DNS redirect rule pushed down to
the OpenFlow switches.
The purpose of this rule refresher is to age out the DNS Divert rule on all the controlled switches in
the event that the application becomes unavailable. A failure to refresh the rule effectively disables
DNS inspection after 8 seconds, at which time the DNS traffic would be forwarded directly to the
DNS server.
You cannot change the values in the rule refresher configuration section. These values can be changed
only by the HP support personnel for troubleshooting purposes (see Table 4-3).
Table 4-3: Components for timeout rules
Component

Description

hard.timeout

Time interval until which the switch will wait for the refresher signal from the
application. After the lapse of the timeout hard.timeout interval, the switch
falls back to the normal working flow and the data is not monitored by the
application. The default value is 8 seconds.
refresh.interval
The interval in seconds at which the application will refresh the DNS redirect
and normal rule on the switch. The default value is 3 seconds.
rule.refresher.enabled You can enable or disable the rule refresher. By default, the rule refresher is
enabled.

VLAN Status
Click VLAN Status to view the details of the DNS requests originating from each VLAN (see Figure
4-28). The DNS details are represented graphically and provide the details of DNS requests
originating from each VLAN configured in the network. You can tune the policies for each VLAN
based on the following reports and threat types:
Total and malicious DNS requests
The average DNS requests
The top malicious DNS requests

Figure 4-28: VLAN Status

Note
For Open Virtual Switches (OVS) discovered by Network Protector, the VLAN is captured as
UNKNOWN_VLAN (4097). No statistics are captured by the application for this
UNKNOWN_VLAN, and the VLAN Status page will not display this VLAN in the VLAN dropdown list.
You can choose to enable or disable the application on VLANs. When you disable the application on a
VLAN, the DNS traffic on the VLAN is not monitored by the application and the traffic flows
normally. Disabling the application on a VLAN does not affect the configuration and operation of the
VLAN on the connected switches.
1. Click VLAN Status on the console page. The VLAN Status page appears.
2. Select the VLAN you want to disable from the Enable or Disable VLAN DNS list.
3. Click Enable or Disable VLAN DNS to disable the application on the VLAN. When the
application is disabled on the VLAN, it does not monitor traffic on the VLAN.

Enable and disable HP Network Protector SDN Application


You can disable or enable HP Network Protector SDN Application from the top menu bar of the HP
Network Protector Console. See Figure 4-29 for the location of the Disable DNS Protector button.
This button toggles. If the application is already enabled, you see the Disable button. If it is already
disabled, you see the Enable button.

Figure 4-29: Disable and enable the HP Network Protector SDN Application
When you click this button, the console displays a confirmation dialog box. Click OK to dismiss it
(see Figure 4-30).

Figure 4-30: Confirmation dialog box


Following are a few examples of what happens to DNS traffic based on the example topology in
Figure 4-31.

Figure 4-31: Example topology


In the following examples, assume that UserVM2, UserVM3, and UserVM4 are all connected to
switches that are connected to an HP VAN SDN Controller that is running HP Network Protector SDN
Application. Also assume HP Network Protector is enabled. Finally, assume that all DNS caches have
been flushed.
To flush the DNS cache, type ipconfig /flushdns at the Windows system prompt. Following is an
example:
1. Flush the DNS cache:
C:\Windows\system32> ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
C:\Windows\system32>

Now suppose that the site howtodoitman.com is a malware site that is in the HP TippingPoint RepDV
database. Figure 4-32 is an example of what UserVM3 might see if he were to try going to this site:

Figure 4-32: howtodoitman.com is blocked and therefore not accessible


As the figure displays, this site is not accessible. The host connection fails.
Note
The reason clients cannot access the howtodoitman.com website is because Network Protector
has been enabled and is intercepting DNS queries.
Now suppose the user attempted to access various malware sites using nslookup on his Windows
client. Following are examples that illustrate what will happen if HP Network Protector is blocking
these sites.
anyhome.ca
C:\Windows\system32> nslookup anyhome.ca
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
*** UnKnown can't find anyhome.ca: Non-existent domain

If this user attempted to reach anyhome.ca from her browser, it would display something like the
webpage in Figure 4-33:

Figure 4-33: Webpage is not available


stopitplz.com
C:\Windows\system32> nslookup stopitplz.com
...
*** UnKnown can't find stopitplz.com: Non-existent domain
C:\Windows\system32> nslookup austinportal.us
...
*** UnKnown can't find austinportal.us: Non-existent domain

Now assume the user on VM4 attempted to use nslookup to access the following three malware sites:
C:\Windows\system32> nslookup howtodoitman.com
C:\Windows\system32> nslookup stopitplz.com
C:\Windows\system32> nslookup austinportal.us

And then this same user tried to access austinportal.us four times via nslookup.
C:\Windows\system32> nslookup austinportal.us
C:\Windows\system32> nslookup austinportal.us
C:\Windows\system32> nslookup austinportal.us
C:\Windows\system32> nslookup austinportal.us

If you were to go to the home page on the HP Network Protector Console, you might see something like
the information you see in Figure 4-34.

Figure 4-34: Network Protector home page


The console shows that two hosts have been sending malicious DNS requests in the network:
10.30.30.3 (UserVM3) and 10.40.40.4 (UserVM4). The number of DNS requests per hour is displayed
and a real-time DNS queries gauge.
If you were to now click VLAN Status, you would see that information for VLAN 30 is displayed, as
in Figure 4-35.

Figure 4-35: Network Protector VLAN Status


Now if you were to select VLAN 40 in this example, you would see information something like the
information you see in Figure 4-36:

Figure 4-36: Network Protector VLAN Status

Questions
The following questions will help you retain the concepts and information you learned in past few
sections.

Question 1: What are four requirements for a service insertion tunnel?


_________________________________________________________________
Question 2: Will DNS interception flow entries be removed if the Network Protector Controller
fails?
_________________________________________________________________
Question 3: Will new malicious sites be blocked automatically when the RepDV service is active?
_________________________________________________________________
Question 1 answer
Service insertion mode requires the following:
At least version 2 ASICs (3800 switch, not 3500, for example)
SNMPv3
OpenFlow 1.3
K15.15 or higher
Question 2 answer
Yes, the rules will be removed.
Network Protector uses a rule refresher mechanism to refresh the DNS redirect rule pushed down to
the OpenFlow switches.
The purpose of this rule refresher is to age out the DNS Divert rule on all the controlled switches in
the event that the application becomes unavailable. A failure to refresh the rule effectively disables
DNS inspection after 8 seconds, at which time the DNS traffic would be forwarded directly to the
DNS server.
Question 3 answer
Yes, if Network Protector is using the RepDV database. In other words, any malicious sites listed in
the RepDV database will be automatically blocked by Network Protector without a user having to add
the domains.

Redirection Server
Overview
When a user tries to access a potentially harmful domain or a webpage, you can configure the policy
enforcement settings to one of the following options (see Figure 4-37):
NXDOMAIN: Set this option to send a nonexistent domain (NXDOMAIN) DNS response to users.
By default, the DNS response type is set to Nonexistent Domain.
Redirection Server: Select the Redirection Server option to redirect the host to a known safe site.
When you set this option, the application redirection server resolves the harmful or malicious
domain names to the redirect server IP address. HP Network Protector sends back to users a DNS
message that presents the redirection server IP as a resolved IP for the DNS request. When users
try to access the resolved IP address from the browser, the redirect server displays the default

webpage.

Figure 4-37: Redirection Server selection


When you install the application, a default redirect web server is installed at the following location
/opt/networkprotector/webserver.
The default redirect web server service npwebserver starts automatically after installation. The web
server serves a default page for the browsers accessing malicious websites using either HTTPS or
HTTP. Figure 4-38 displays a sample default webpage.

Figure 4-38: Sample Redirection Server webpage


This server serves requests for both blacklist and graylist sites. All HTTP requests are serviced at
port 80 and the secure HTTPS requests are serviced at port 443. These are default ports for the two
HTTP protocols.

Note
Refer to the HP Network Protector SDN Application1.3
Administrator Guide for more options: http://h20564.www2.hpe.com/hpsc/doc/public/display?
docId=c04647299

Figure 4-39: Redirect users to a safe site on your own network


You can also redirect users to a server in your network, as illustrated in Figure 4-39. HP Network
Protector will return the configured IP address for the DNS resolution of malicious sites. A DNS reply
message with the redirection server IP as a resolved IP for the DNS request is returned to the user.

Configuration
To configure policy enforcement settings, do the following:
1. Select Administration then click Policy Enforcement Settings. The Policies/Policy
Enforcement Settings page displays. This page is illustrated in Figure 4-40.

Figure 4-40: The Administration/Policy Enforcement Settings view


2. Click the Edit button to edit the policy enforcement settings.
3. Enter the time in seconds in the TTL (sec) text box.
4. Select Non-existent Domain option to display a message that the domain does not exist.
Or
5. Select Redirection Server option to redirect the host to a known safe site (see Figure 4-41).
Note
By default, the IP address of the local host on which the application is installed is populated for
both blacklist and graylist redirection server address text boxes.

Figure 4-41: Screen capture of the DNS Response Configuration dialog


6. To change the blacklist redirection address, enter the IP address of the server in the DNS Blacklist
Redirection Server Address text box.
7. To change the graylist redirection address, enter the IP address of the server in the DNS Graylist
Redirection Server Address text box.
8. In the HP Network Protector Console, click Administration and then Local Redirection Server.
In the Local Redirection Server Message box, edit the default message that the webserver
displays when the user is redirected to it. (See Figure 4-42 for a screen capture that illustrates this
step.)
9. Click Save to save the setting.

Figure 4-42: Edit the local Redirection Server message

Configuration scenarios
Suppose you have set up a test network like the example network in Figure 4-43.

Figure 4-43: Example network topology


This section will present example scenarios that will help you explore the results of configuring the
following three settings:

No redirect (NXDOMAIN)
Internal redirection server
External redirection server

Scenario 1
Suppose HP Network Protector is properly installed on the example network and the following two
sites are in the TippingPoint RepDV database: anyhome.ca and howtodoitman.com. You have
configured the Redirection Server to display the following message: The page you are trying to access
has been blocked by the HP Network Protector. Please contact your IT administrator if you need
access to this site.
If any of the users on network (see the sample topology in Figure 4-43) were to send their web
browsers to anyhome.ca or howtodoitman.com, they would see the message displayed in Figure 4-38.
The following output is an example of what you would see if you used nslookup to confirm the DNS
response messages received for anyhome.ca and howtodoitman.com:
C:\Users\Student>nslookup anyhome.ca
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Non-authoritative answer:
Name: anyhome.ca
Addresses: 192.168.56.12
192.168.56.12
C:\Users\Student>nslookup howtodoitman.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Non-authoritative answer:
Name: howtodoitman.com
Addresses: 192.168.56.12
192.168.56.12
C:\Users\Student>

As the example output illustrates, DNS response would be IP address 192.168.56.12, which is the IP
address of the HP VAN SDN Controller (see Figure 4-43). Network Protector is intercepting the DNS
queries and replying with its own IP address as the resolved IP address.

Scenario 2
You now edit the policy enforcement settings in Network Protector Console by clicking Edit in the
Administration/Policy Enforcement Settings view and set the DNS blacklist and graylists
redirection addresses to 192.168.56.51, which is HPs IP address (see Figure 4-44).

Figure 4-44: Change blacklist and graylists Redirection Server addresses

Note
We will discuss blacklists, graylists, and whitelists in more detail shortly.
You click Save and use nslookup to check DNS resolution. Following is the output you would see
based on this scenario:
C:\Users\Student> nslookup anyhome.ca
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Non-authoritative answer:
Name: anyhome.ca

Addresses: 192.168.56.51
192.168.56.51
C:\Users\Student> nslookup howtodoitman.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Non-authoritative answer:
Name: howtodoitman.com
Addresses: 192.168.56.51
192.168.56.51
C:\Users\Student>

Now if you were to browse to anyhome.ca and howtodoitman.com, you would see the HP webpage
you see in Figure 4-39.
Note
In a production environment it would be better to display a warning message similar to the builtin Network Protector message, or another legally compliant, country-specific message,
informing users why their traffic has been redirected.

Questions
The following questions will help you retain the information and concepts you learned in the preceding
section.
Question 1: Is the redirection server enabled by default?
_________________________________________________________________
Question 2: Does HP Network Protector have a built-in redirection server?
_________________________________________________________________
Question 3 : Can different redirect servers be configured?
_________________________________________________________________
Question 1 answer
No, the default setting is for HP Network Protector to reply with a Nonexistent Domain DNS response.
Question 2 answer
Yes, the default redirect webserver service npwebserver starts automatically after installation. The
webserver serves a default page for browsers accessing malicious websites using either HTTPS or
HTTP.

Question 3 answer
Yes, a redirection server can be configured for blacklist entries and a different server configured for
graylists.

Groups, profiles, and policies


You may want to manage categories of users, DNS traffic, or VLANs differently. You may also want to
manage traffic differently during different times of the day or week.
For example, you may want to create a policy that allows certain users to access the Internet sites
needed to do their duties, but block them from sites that might use too much network bandwidth or
otherwise might reduce worker productivity.

Figure 4-45: Groups


You will learn to use groups and profiles to create a set of policies for a specific VLAN or a group of
VLANs. Figure 4-45 shows a group called Students that is set up on VLAN 40.

Inspection policies
You can add customized inspection policies to inspect DNS traffic in your network and take suitable
action. For example, an inspection policy might allow some traffic but block or drop traffic to
malicious domains. The inspection policy can be applied to VLAN groups in your network. You can
apply schedules for the customized inspection policies.
To create an inspection policy and apply it to a VLAN, apply a blacklist and graylist to the policy and
assign a RepDV profile. When the DNS traffic is generated from a VLAN that is part of the VLAN
group associated with the inspection policy, and when the generated DNS is listed either in a blacklist
or a graylist, or if it matches the RepDv filter that is associated with the policy, then the application
performs the specified action, such as dropping the DNS traffic, notifying the administrator, or both.

Default policy
The default policy is similar to the inspection policy except that it is active all the time. You can apply
the default policy only to an internal (default) VLAN group. No other VLAN group can be attached to

this policy. This policy checks incoming DNS packets to the default RepDV filter only. You cannot
attach any other RepDV filter to it.
You can assign blacklists and graylists to the default policy. All the DNS traffic in the network is
continuously compared with the profiles attached to the default policy. If the traffic in the network
matches the default policy, then the policy is applied to the DNS network traffic.
Unlike the other policies, where you can assign a schedule to allow or block access based on time, the
default policy is always active.

VLAN groups
As mentioned earlier in this section, you can group VLANs into logical groups to assign policies. You
can create policies for each VLAN group based on the requirements.
For example, in a university campus, you can create two VLAN groups. You can group all the VLANs
in the main university campus into one group and all the VLANs in the dormitory into the other group.
You can apply customized policies to manage both groups.

Create VLAN groups


1. To create a new VLAN group, do the following:
2. Select Profiles and then select VLAN Groups.
3. Click the New button as shown in Figure 4-46. The Create new group page displays.

Figure 4-46: The HP Network Protector Console Profiles view


4. Type a logical name for the group in the Group Name text box, Staff, for example (see Figure 447).

Figure 4-47: The Staff VLAN


5. Select the VLANs that you want to group from the list of available VLANs. VLAN30 is selected in
Figure 4-47.
6. Click the arrow to move the selected VLANs to the group.
7. To add a VLAN that is not listed, enter the VLAN number in the Manual VLAN text box, and click
Add (see Figure 4-47).
8. Click OK. The group is added to the Groups view.

Custom blacklists
In addition to restricting access via the RepDV database, you can add blacklist entries to restrict
access (see Figure 4-48). When a user accesses a domain listed in the blacklist, the application drops
the traffic and updates its log with the statistics it generates when end users try to access blacklisted
sites.
When you generate reports based on the total number of blocked DNS requests or malicious DNS
requests, the reports contain the blacklist DNS entries along with the RepDV database entries.

Figure 4-48: Custom blacklists


You can work with four types of custom lists to manage traffic in your network:
Whitelist
Priority whitelist
Blacklist
Graylist
In addition to the RepDV database, you can add blacklist host-name entries to restrict access to the
named hosts. When a user accesses a domain listed in the blacklist, the application drops the traffic
and updates its statistics about end users who have tried to access the blacklisted sites. When you
generate reports based on the total number of blocked DNS requests or malicious DNS requests, then
the reports contain the blacklist DNS entries along with the RepDV database entries.
Whitelists, priority whitelists and graylists will be discussed later in this chapter.

Custom lists and RepDV search order


The HP Network Protector SDN Application performs a sequential search for allowed and blocked
domains before it allows the host to access external host names. This is the sequence it uses: whitelist,
blacklist, and finally the RepDV database.
When the application finds a domain name in the whitelist, it stops looking for the entry in the blacklist
or in the RepDV database and allows the user to access the domain name. If a domain name is listed in
the whitelist and the blacklist or the RepDV database, the application allows the user to access the
domain name.
For example, if you add example.com in the whitelist and if example.com is listed as a malicious site
in the RepDV database, you will still be able to access this site. Whitelist domains override the
blacklist domains and domains in the RepDV database.

Default policy

As mentioned, HP Network Protector is policy-based. The default policy is similar to other inspection
policies except that it is active all the time. You can apply the default policy only to the Internal
(default) VLAN group. No other VLAN group can be attached to this policy. This policy checks
incoming DNS packets to the Default RepDV filter only. You cannot attach any other RepDV filter to
it. You can assign a blacklist and a graylist to the default policy. All the DNS traffic in the network is
continuously compared with the profiles attached to the default policy. If the traffic in the network
matches the default policy, then the policy is applied to the DNS network traffic. Unlike the other
policies, where you can assign a schedule to allow or block when users can access the sites, the
default policy is always active. You will learn how to configure default policies in the following
section: Configuring custom blacklists.

Search the TippingPoint RepDV database


Before you configure a custom blacklist, it is interesting to know if the sites you intend to include are
already in the TippingPoint RepDV database. However, performing a search on the database tells you
more than whether the domain in which you are interested is there. It also tells you why it is there. For
example, it tells you the domains reputation score (scores above 79 are blocked by default) and the
threat typevirus, for example.
In the following example instructions for performing a database search, the search domain anyhome.ca
is already in the TippingPoint RepDV database.
Search for domain anyhome.ca as follows:
1. In the HP Network Protector Console, click Administration and then click Search. These two
menu selections are highlighted in Figure 4-49.

Figure 4-49: Database search


2. Type the domain name anyhome.ca in the Domain Name field (see Figure 4-50 as you read these

instructions).

Figure 4-50
3. Click the checkmark ( ) to select all databases.
4. Click the magnifying glass ( ) to perform the search.
5. Click the arrow ( ) to show more details.
As the example screen capture for these instructions (Figure 4-51) shows, anyhome.ca is in the
TippingPoint database. It has a reputation score of 90, and the threat type is Network Worm.
As previously mentioned, the RepDV database is a subscription service that enables the application to
monitor and block outbound communications with known malicious and undesirable host names. The
RepDV database includes hundreds of thousands of known malicious or undesirable hosts. A threat
score of 0100 is assigned to each host name based on an analysis of the activity, source, category, and
threat.
Note
RepDV filters will be explained shortly.
If you were to search the RepDV database for Facebook and Mininet, you would not find these
domains listed. In these cases, the search would return no results (see Figure 4-51).

Figure 4-51: Search for Facebook yields no results

Profile settings
To view current profile settings, click Profiles and then RepDV Filters in the HP Network
Protector Console (see Figure 4-52). Expand details for the default RepDV filter by clicking on the
arrow ( ) (see Figure 4-52).
As Figure 4-52 illustrates, all listed threat types have a reputation score that is greater the 79 and are
therefore denied.

Figure 4-52: The Profiles/RepDV Filters view

RepDV filters

The RepDV service provides DNS security intelligence feeds from a global reputation database so
that you can actively enforce and manage reputation security policies. The HP Network Protector SDN
Application uses the reputation scores to inspect traffic in real time and enforce security policies.
You can customize the reputation scores and apply the customization to the inspection policy to protect
your network. Table 4-4 lists the various threat types:

Table 4-4: Threat types


Threat
type
Botnet

Meaning
Malicious software is installed on your computer through the Internet without your
knowledge and your computer is used to perform repetitive tasks. The tasks can include
sending out spam mails, spreading malicious software, and performing other illegal
activities. When performing these tasks, the performance of your computer might slow
down.

Malware

Malware is the abbreviation for malicious software.


Malware is installed on your computer without your knowledge to disrupt your computer
operation or to gather sensitive information. The information gathered can be used to
display unsolicited advertisements or redirect affiliate marketing revenues to the
malware creator.
Misuse and Misuse and abuse of network resources. This is similar to the peer-to-peer protocols
Abuse
where the network resource and bandwidth are primarily used to share music and video
files.
Network
A network worm is a standalone malware computer program that replicates itself to
Worm
spread to other computers. It often uses a computer network to spread itself, relying on
security failures on the target computer to access it. Unlike a computer virus, it does not
need to attach itself to an existing program.
Peer-toPeer-to-peer protocols are primarily used to share music and video files, and essentially
Peer (P2P) turn a personal computer into a file server which makes its resources and those of its
host network available to the peer-to-peer community.
Spam
Electronic spamming is the use of electronic messaging systems to send unsolicited bulk
messages (spam), especially advertising, indiscriminately.
Spyware
Spyware is a type of software that transmits information without the users knowledge or
permission. Spyware may be the result of a virus infection or may be installed along with
other applications. Spyware often consumes vast resources and can slow systems and, in
some cases, cause systems to become unstable or unusable.
Web
Web application attackers generally look for vulnerabilities in a network. Writing
Application malicious code, they try to find the weak points in a network security system to bypass
Attackers filters and reach data and services. These attackers seek to use intrusion methods against
areas such as software backdoors and poorly protected hosts and ports.
Worm
A worm is also malicious software that spreads from one computer to another, leaving
infections as it travels. Worms use either the network vulnerability or social engineering
to trick the user into spreading them. Network worms are capable of damaging data or
software and causing denial-of-service (DoS) conditions.

Creating and configuring custom blacklists


This section contains instructions for configuring custom blacklists. Examples are based on the sample
topology illustrated in Figure 4-53.

Figure 4-53: Example topology for configuring custom blacklists

Scenario 1
Assume that your organization has created two VLAN groups: Staff and Student. Also, assume that
staff members are testing Mininet and do not want students accessing the mininet.com domain.
Following is the result of an nslookup command from UserVM4 (see Figure 4-53) to test the name
resolution of the mininet.com domain name:
C:\Windows\system32> nslookup mininet.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Name: mininet.com
Address: 192.168.56.54
C:\Windows\system32>

As you see, the main name resolves to 192.168.56.54.


In the next few steps you will learn how to block student access to the Mininet.com domain. Statistics
should be logged to monitor unauthorized access attempts. To do this, you will create a custom
blacklist as follows:
1. In the Network Protector Console, click Profiles and then List. These menu selections are
illustrated in Figure 4-54.

Figure 4-54: Profiles/List


As Figure 4-54 illustrates, a default profile exists.
2. Click New and create a custom blacklist as follows, then click OK:
Name: CustomStudentBlacklist
Type: Blacklist
Description: Block Student VLAN
3. Click Add, and add a name of *.mininet.com. Figure 4-55 illustrates item placement in the Edit
List dialog box.

Figure 4-55: Create a new blacklist


Following is the nslookup output from UserVM4:
C:\Windows\system32> nslookup mininet.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Name: mininet.com
Address: 192.168.56.54
C:\Windows\system32>

As you see, the domain is still resolved. Further, when you perform a RepDV search, you do not find
the mininet.com domain in the database, as shown in Figure 4-56.

Figure 56: Database search for mininet.com


Following are the instructions for setting up a new policy that includes the blacklist we created.
1. Click the Policies menu and then the submenu Polices, as illustrated in Figure 4-57:

Figure 4-57: Policies


2. Click default policy and then click Edit, as illustrated in Figure 4-58:

Figure 4-58: The default policy


In this example, the default policy does not include a blacklist or a graylists profile.
3. Click Cancel and then click New.
In this example, we will create a new policy with the following details. We will then click OK to
accept the new policy. Figure 4-59 illustrates placement of these details:
Name: StudentsGroupPolicy
Policy Type: Inspection Policy
Description: Inspect Students Group
VLAN Group: Students
Blacklist Profile: CustomStudentBlacklist
RepDV Profile: Default
Time Range: ALWAYS
Action: Drop

Figure 4-59: The Edit Policy dialog box


In this example, we used the Drop action. The following actions are available on HP Network
Protector:
Drop: The application drops the DNS traffic when a user accesses a domain name that is listed in the
blacklist or graylist, or that matches the threat profile.
Notify: The application sends out a notification to the administrator in the form of email if a user
accesses a host name that is listed in the blacklist or graylist, or that matches the RepDV threat profile.
The event is logged in the application log. The application does not drop the traffic to the domain and
the user continues to access the domain.
Drop and Notify: The application sends out an email notification to the administrator if a user
accesses a domain name that is listed in the blacklist or that matches RepDV threat criteria. The
application drops the traffic to the domain.
Now that we have applied the new policy, the mininet.com domain resolves to the redirection server
(192.168.56.51) rather than the Mininet server (192.168.56.54). The following nslookup output
illustrates this:
C:\Windows\system32> nslookup mininet.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50

Non-authoritative answer:
Name: mininet.com
Addresses: 192.168.56.51
192.168.56.51
C:\Windows\system32>

In this example, when users on the student VLAN point their browsers to mininet.com, the HP Network
Protector Redirection Server redirects their requests. Users on the staff VLAN, however, can still
access the site, as illustrated in the following nslookup output from UserVM3, which is on the staff
VLAN:
C:\Users\Staff> nslookup mininet.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Name: mininet.com
Address: 192.168.56.54
C:\Users\Staff>

Further, as Figure 4-60 illustrates, if you were to repeat a database search against all lists, search
results include mininet.com:

Figure 4-60: Search results now include *.mininet.com

HP Network Protector Console reports

Still using our example topography, we try accessing Mininet.com several times from the Student
VLAN. Following are a few of the reports that illustrate these attempts to resolve the mininet.com
domain on UserVM3:
When we click Dashboard and then Home on the HP Network Protector Console, we see the output in
Figure 4-61:

Figure 4-61: The Dashboard view displays malicious queries from 10.40.40.4, the Students group.
When we click VLAN Status and then select VLAN 40, the Network Protector Console displays the
charts and statistics that indicate malicious site requests from the Student group (see Figure 4-62):

Figure 4-62: VLAN Status

Questions
The following questions will help you retain the information and concepts you learned in the previous
three sections:
Question 1: HP Network Protector automatically blocks sites that score above what reputation score
in the RepDV database?
_________________________________________________________________
Question 2: Are custom blacklist statistics logged?
_________________________________________________________________
Question 3: An administrator adds the domain facebook.com to a custom blacklist. The action is set
to Notify. Will users be able to access facebook.com?
_________________________________________________________________
Question 1 answer
Sites with a reputation score greater than (>) 79 are filtered.
Question 2 answer
Yes, when a user accesses a domain listed in the blacklist, the application drops the traffic and updates
its logs with the statistics of end users who tried to access the blacklist sites.
Question 3 answer
Yes, when the action is Notify, Network Protector sends out an email notification to the administrator
if a user accesses a host name that is listed in the blacklist or graylist, or that matches the RepDV

threat profile. The event is logged in the application log. The application does not drop the traffic to
the domain and the user continues to access the domain.

Graylists
You can include host names in the graylist that are not harmful to your network but might be blocked to
adhere to business policies (see Figure 4-63). You can also add host names to graylists to restrict
access to certain sites during specific times of the day. When you add host names to the graylist, the
user will not be able to access the host. Unlike a blacklist, the application does not save the statistics
of users who tried to access graylist entries as malicious DNS requests.
For example, in a university campus, you can set the graylist to restrict access to social media sites
which are a distraction during class hours. Restricting access to social media sites encourages the staff
and students to engage more with each other during class hours.

Figure 4-63: Graylists


In the following section, you will learn how to create and configure a custom graylist.

Create and configure custom graylists

Figure 4-64: Example topography for configuring graylists


The following examples show you how to configure and apply graylists.
If you want to watch a video that shows the steps outlined in this section, access the HP Aurasma
application on your smartphone and use the application to focus on Figure 4-64. This action will
launch the video.
Assume that UserVM4 in the example topology (Figure 4-64) is in a student VLAN (VLAN 40) and
that the student can currently access facebook.com. Also assume that UserVM3 in the topology is in a
staff VLAN (VLAN 30), and that this user can also currently access facebook.com.
You will now learn how to prevent VLAN 30 access to facebook.com.

Create a custom graylist


The first step is to create a graylist that includes the facebook.com domain:
1. In the Network Protector Console, click Profiles and then List. Then click New.
2. Click New and create a custom blacklist. The following example information adds the
facebook.com domain to a graylist. Figure 4-65 illustrates where to add this information in the
Create New List dialog box.
Name: CustomStudentGraylist
Type: Graylist
Description: Block social media
Click Add, and add a name of *.facebook.com

Figure 4-65: Add facebook.com to a new graylists


3. Click OK.
4. Click the Policies menu and then the submenu Polices. In this example, we want to add the graylist
to an existing policy called StudentGroupPolicy (see Figure 4-66).

Figure 4-66: Existing policies


5. Click StudentsGroupPolicy and then click Edit.
6. In the Edit Policy dialog box, set the Graylist Profile to CustomStudentGraylist and click OK.
Figure 4-67 illustrates this step.

Figure 4-67: The Edit Policy dialog box

Test configurations
If you are using a test version of HP VAN SDN Controller, HP Network Protector SDN Application,
and Mininet and have followed instructions for adding a custom graylist, you can test the success of
your actions by:
1. Pointing your browser to facebook.com from UserVM4 (which is on the Student VLAN). This
action should redirect the browser to a safe site or display a message that indicates the site is not
accessible.
2. Pointing your browser to facebook.com from UserVM3 (which is on the Staff VLAN). Staff
members should be able to access facebook.com.
You can also test the results students and staff members experience when you change DNS response
settings (see the section of this chapter titled Redirection Server).
Display the warning message for staff and students, rather than redirecting them to hp.com for blacklist
sites.
1. In the Network Protector Console, click Administration and then Policy Enforcement Settings
(see Figure 4-68).

Figure 4-68: The Administration/Policy Enforcement Settings view


2. Click Edit and then set the following URLs for blacklist and graylist redirection (see Figure 4-69):
DNS Blacklist Redirection Server: 192.168.56.12
DNS Graylist Redirection Server: 192.168.56.51
3. Click Save.

Figure 4-69: Add URLs to blacklist and greylist redirection entries


The DNS Response Type is now set to DNS Blacklist Redirection Server.
4. Check access to facebook.com and anyhome.ca from UserVM4 (which is in the Student VLAN). In

both cases, you should be redirected to the safe sites you configured for graylist responses and
blacklist responses, depending on which site you attempted to access. These can be different sites.
5. Check access to facebook.com and anyhome.ca from UserVM3 (which is the Staff VLAN). You
should be able to access the Facebook site, but should be redirected to the blacklist safe site when
you point your browser to anyhome.ca.

Questions
The following questions will help you retain the information and concepts you learned in the preceding
section.
Question 1: What is the difference between a blacklist and a graylist?
_________________________________________________________________
Question 2: Can a different redirection server be used with blacklists and graylists?
_________________________________________________________________
Question 1 answer
Unlike blacklist requests, the application does not save statistics for users who try to access graylist
entries as malicious DNS requests.
Question 2 answer
Yes, a redirection server can be configured for blacklist entries and a different server configured for
graylists.

Custom whitelists
You can add host names to the whitelist (see Figure 4-70). The application compares the host names
on this list and allows access to the host names without examining the blacklist or the RepDV
database. You can add host names to the whitelist when you want the application to skip looking for
the host names in the blacklist and the RepDV database. You can also override the RepDV database
entries with whitelist host name entries. Unlike the blacklist or graylist, where you can set time ranges,
the whitelist is always active.

Figure 4-70: Custom whitelists


You must edit the default list to add whitelist entries. You cannot delete the default list.

Create a custom whitelist


In this section, you will learn how to create and apply a custom whitelist. You will then learn to test
that whitelists override all blacklists.
Instructions will be based on examples that use the topology in Figure 4-71.

Figure 4-71: Example topology for creating a custom whitelist

For the following instructions, assume that UserVM4 is on VLAN 40 (which is the Student VLAN) and
UserVM3 is on VLAN 30 (the Staff VLAN). Also assume that you have configured the mininet.com
domain on the blacklist, and that the domains anyhome.ca and howtodoitman.com are in the RepDV
database as malicious sites. If you were to test the verity of these assumptions using nslookup, the
output would look something like what you see in the following examples:
For mininet.com
C:\Windows\system32> nslookup mininet.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Non-authoritative answer:
Name: mininet.com
Addresses: 192.168.56.12
192.168.56.12

UserVM4 cannot access mininet.com.


For anyhome.ca
C:\Windows\system32> nslookup anyhome.ca
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Non-authoritative answer:
Name: anyhome.ca
Addresses: 192.168.56.12
192.168.56.12
C:\Windows\system32>

UserVM4 cannot access anyhome.ca.

Create a whitelist
1. In the HP Network Protector Console, select Profiles and then select List.
2. Select default Whitelist and click Edit (see Figure 4-72):

Figure 4-72: Edit whitelist


3. Add the following domains to the whitelist and click OK:
Override the custom blacklist: *.mininet.com
Override the RepDV blacklist: *.anyhome.ca
Figure 4-73 illustrates these additions.

Figure 4-73: Add domains to the whitelist

Test configurations
1. You can use a browser on UserVM4 to verify that students can now access the mininet.com
domain. You can also use nslookup. If you did, you would see the following output:
C:\Windows\system32> nslookup mininet.com
DNS request timed out.

timeout was 2 seconds.


Server: UnKnown
Address: 192.168.56.50
Name: mininet.com
Address: 192.168.56.54
C:\Windows\system32>

As you see, students can access mininet.com. The whitelist has overridden the custom blacklist.
2. You can use a browser on UserVM4 to verify that students cannot access anyhome.ca. You can also
use nslookup, in which case the output from UserVM4 would look something like this:
C:\Windows\system32> nslookup anyhome.ca
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Name: anyhome.ca
Address: 192.168.56.52
C:\Windows\system32>

Students can access anyhome.ca. The whitelist has overridden the RepDV blacklist.
3. You can use the browser on UserVM3 to test if staff members can access anyhome.ca (RepDV
blacklist). You can also use nslookup. If you were to test access using nslookup in this example,
you would see something like the following output:
C:\Windows\system32> nslookup anyhome.ca
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.50
Name: anyhome.ca
Address: 192.168.56.52
C:\Windows\system32>

Staff can access anyhome.ca. The whitelist has overridden the RepDV blacklist.
4. If you were to check staff access to howtodoitman.com using nslookup, however, you would see
something like the following output:
C:\Users\Student> nslookup howtodoitman.com
DNS request timed out.

timeout was 2 seconds.


Server: UnKnown
Address: 192.168.56.50
Non-authoritative answer:
Name: howtodoitman.com
Addresses: 192.168.56.12
192.168.56.12
C:\Users\Student>

As you see, staff members cannot access howtodoitmain.com. The RepDV blacklist is still used for
blocking domains that are not overridden by the whitelist.

Questions
The following questions will help you retain the information and concepts you learned in this section.
Question 1: Can a whitelist use time ranges?
_________________________________________________________________
Question 2: Does a whitelist override the RepDV database?
_________________________________________________________________
Question 1 answer
Unlike the blacklist or graylist, where you can set time ranges, the whitelist is always active.
Question 2 answer
Yes, a whitelist overrides the RepDV database.
You can add host names to the whitelist. The application compares the host names on this list and
allows access to the host names without examining the blacklist or the RepDV database.

Quality of service
Traffic in networks does not have equal importance or priority. In other words, some traffic types are
business critical, while others are not. Without QoS, all traffic competes for a set amount and possibly
limited amount of bandwidth. QoS provides preferential treatment to specific traffic types such as
Voice over IP (VoIP).

Figure 4-74: Quality of service


To manage critical traffic and provide preferential treatment to it, you can create whitelist entries and
attach QoS priorities to the traffic (see Figure 4-74). Based on the QoS value and the priority, the
application treats the various types of data streams that flow across your network traffic differently.
Note
You can create a maximum of 20 whitelists and each whitelist can contain up to ten domain list
entries.
Various Differentiated Service Code Point (DSCP) or Priority Code Point (PCP) values can be
configured for matched traffic. DSCP provides for traffic classification marking at Layer 3 and PCP at
Layer 2.
Devices configured to match the DSCP or PCP values can prioritize traffic according to business
policies.
For example, you may want to tag all social media site traffic with a lower DSCP/PCP value so that
traffic to facebook.com and other social media sites is not processed at the detriment of business
critical traffic.

Figure 4-75: QoS flows


After you apply the priority whitelist policy to a priority whitelist, HP Network Protector creates
flows on the switches that tag matched traffic with the configured DSCP and PCP value. See Figure 475 for an example of this.
Network Protector does not perform routing or prioritization of the traffic based on the DSCP or PCP
value. Traditional QoS mechanisms are used to route or prioritize traffic based on the values set in the
OpenFlow table.

QoS priority whitelist


In this section, you will learn to configure QoS on a HP Network Protector whitelist. Instructions will
use the example topology you see in Figure 4-76.

Figure 4-76: QoS topology

Instructions for creating a QoS priority whitelist


1. In the HP Network Protector Console, click Profiles and then List. Click New to create a new
policy, as illustrated in Figure 4-77.

Figure 4-77: HP Network Protector Console


2. Fill in details for the new policy and click OK. The following list contains example details:
Name: QoS Policy List
Type: Priority Whitelist

Description: Priority Whitelist of important domains


Add the domain to the list. In the example illustrated in Figure 4-78, the domain is hp.com. Press
Enter if necessary before clicking OK.

Figure 4-78: Priority whitelist


3. Click the Policies menu and then the submenu Policies. Click New to create a new policy (see
Figure 4-79).

Figure 4-79: Policies


4. Fill in details for the new policy and click OK. Following is a list of example details, which you
see in Figure 4-80.
Name: QoSPolicyStaff
Type: Priority White List Policy
Description: Priority Whitelist of important domains

VLAN Group: Staff


Priority Whitelist Profile: QoS Policy List
Time Range: ALWAYS
DSCP Setting: 34 (AF41)
L2 Priority: 4

Figure 4-80: Policy details for a priority whitelist

Note
When you click OK, Network Protector does a DNS lookup of the DNS entries in the Policy List
and translates the domain names to IP addresses. Flows are programmed on the switch with
resolved IP addresses as the destination IP address match and IP_DSCP and VLAN_PCP set to
the value specified in the QoS policy.

View new flows


Network protector adds new flows based on your QoS configurations. To view these flows:
1. In the HP VAN SDN Controller Console, click OpenFlow Monitor and select a switch, then click
Flows. In this example, we will select ProVision Switch 1 (10.1.1.253).

Figure 4-81: OpenFlow Monitor


Switches are listed by their DPIDs (see Figure 4-81). Figure 4-82 shows the selected switch and the
location of the Flows selection.

Figure 4-82: Selected switch and Flows selection


As Figure 4-83 illustrates, a new flow has been added to the switch:

Figure 4-83: New flows


In Figure 4-83, the new flow matches IPv4 traffic with destination IP address of 192.168.56.51.
Matching traffic has the DSCP value set to 34 and the COS/PCP value set to 4. Traffic is sent to the
traditional routing and switching pipeline for further processing.
Note
This flow was only added to ProVision Switch 1 (P1) and not to ProVision Switch 2 (P2) as P2
does not have VLAN 30 configured on it.

Instructions for viewing flows on the switch CLI


1. Use the show openflow instance <instance> flows command to view the new flow on the console
of the switch. Following is an example of output from switch P1:
P1# show openflow instance vlan30 flows
OpenFlow Flow Table
Flow 2
Match
Incoming Port : Any Ethernet Type : IP
Source MAC : Any Destination MAC : Any
Destination MAC Mask : 000000-000000
VLAN ID : Any VLAN priority : Any
Source IP Address : Any
Destination IP Address : 192.168.56.51/32
IP Protocol : Any

IP ECN : Any IP DSCP : Any


Source Port : Any Destination Port : Any
Attributes
Priority : 30020 Duration : 1118 seconds
Hard Timeout : 43349 seconds Idle Timeout : 0 seconds
Byte Count : NA Packet Count : 0
Flow Table ID : 100 Controller ID : 2
Cookie : 0xebabe
Hardware Index: 17
Instructions
Apply Actions
Modify IP DSCP : 34
Modify VLAN PCP : 4
Normal

Note
The application only does QoS classification and marking. Queuing and other QoS functions are
performed by traditional switch methods. You would need to configure priority queuing on
Comware Switch 1 (C1) in Figure 4-76, for example, to prioritize the traffic destined to HP.com.

ACL Manager
ACL Manager leverages five-tuple packet attributes and the VLAN ID to create access control
policies.
The five attributes are
Source IP address
Source port (any)
Destination IP address
Destination port (80 or 443)
Destination protocol (typically TCP)

Figure 4-84: ACL Manager


Access control policies are based on packet attributes, which are listed in the preceding paragraph
and in Figure 4-84. If the incoming packet matches the access control policy, the application either
drops the packet or forwards it based on the policy action you have set. You can also use the ACL
Manager to apply network masks on source or destination IP addresses.
You can enter the tuple attributes such as IP address, subnet address, and the port number of the source
or destination to create the ACL rule. If you set the source or destination subnet IP address, then the
application matches the entire subnet for the entered IP address for both source or destination and
blocks or allows any traffic for the subnet. If you set only the fields name and action then the rule
applies to any IPv4 traffic, blocking or allowing it depending on the selected action.
Note
If you set the rule to block packets from IP source 10.40.40.3 and set the Bidirectional rule to
TRUE, then packets to the destination IP address 10.40.40.3 are also blocked.
In Figure 4-85, a flow entry has been created that matches the following details:
Ethernet type = IPv4
IPv4 source address: 10.40.40.0/24
IPv4 destination address: 10.30.30.0/24

Figure 4-85: New flow entry


In the figure, the apply_action instruction is blank, which means that matched traffic is dropped by the
switch.

Create an ACL
Access control policies enable Network Protector to perform Deep Packet Inspection (DPI).

Figure 4-86: Example topology for ACL Manager instructions


In this section, you will learn to configure an ACL to block students from accessing staff computers.
This will be done by blocking traffic sent to the staff subnet from the student subnet.

You will also learn how to test that the ACL works.

Instructions
The following instructions are based on an example scenario that uses the topology in Figure 4-86.
Assume that UserVM4 (10.40.40.4) in the Student VLAN can successfully ping UserVM3 (10.30.30.3)
in the Staff VLAN. If you were to check this assumption from UserVM4, you would see the following
output from your ping command.
C:\Windows\system32> ping 10.30.30.3
Pinging 10.30.30.3 with 32 bytes of data:
Reply from 10.30.30.3: bytes=32 time=4ms TTL=127
Reply from 10.30.30.3: bytes=32 time<1ms TTL=127
Reply from 10.30.30.3: bytes=32 time<1ms TTL=127
Reply from 10.30.30.3: bytes=32 time<1ms TTL=127
Ping statistics for 10.30.30.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 4ms, Average = 1ms
C:\Windows\system32>

1. In the Network Protector Console, click Administration and then ACL Manager.

Figure 4-87: The Administration/ACL Manager view


As shown in Figure 4-87, no ACLs are configured by default.
2. Click Add to add a new ACL and fill in the details and then click OK. Following are example
details, which you can see in Figure 4-88:
Name: BlockUserComms

IP Source: 10.40.40.4 (The Subnet mask setting will result in the OpenFlow flow entry being
converted to 10.40.40.0 when you click OK)
IP Destination: 10.30.30.3 (The Subnet mask setting will result in the OpenFlow flow entry being
converted to 10.30.30.0 when you click OK)
Source Subnet: 255.255.255.0
Destination Subnet: 255.255.255.0
Action: Block

Figure 4-88: Add ACL Rule dialog box

Note
If you set the rule to block packets from IP source 10.40.40.4 and set the Bidirectional rule to
TRUE, then packets to the destination IP address 10.40.40.4 are also blocked.
3. Check to see if your ACL configuration worked. In the example, UserVM4 (10.40.40.4) in the
Student VLAN cannot ping UserVM3 (10.30.30.3) in the Staff VLAN. In this case, the following
output would result from a ping command:
C:\Windows\system32> ping 10.30.30.3
Pinging 10.30.30.3 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.

Request timed out.


Ping statistics for 10.30.30.3:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\system32>

The configuration is successful, and a flow has been written to the switch, as illustrated in Figure 489.

Figure 4-89: New flow


The example flow matches IPv4 traffic from a source network 10.40.40.0/24 and destination network
10.30.30.0/24. Matched traffic is dropped (apply_action = blank).

View the new flow on the switch console


1. To view a flow on the switch console, use the show openflow instance <vlan> flows command.
Following is the example output you would receive from the switch P2 console:
P2# show openflow instance vlan40 flows
Flow 2
Match
Incoming Port : Any Ethernet Type : IP
Source MAC : Any Destination MAC : Any
Destination MAC Mask : 000000-000000
VLAN ID : Any VLAN priority : Any
Source IP Address : 10.40.40.0/24
Destination IP Address : 10.30.30.0/24
IP Protocol : Any
IP ECN : Any IP DSCP : Any

Source Port : Any Destination Port : Any


Attributes
Priority : 34050 Duration : 622 seconds
Hard Timeout : 3600 seconds Idle Timeout : 0 seconds
Byte Count : NA Packet Count : 4
Flow Table ID : 100 Controller ID : 2
Cookie : 0xcebcbeef
Hardware Index: 0
Instructions
Apply Actions

Because Apply Actions is blank, matching traffic is dropped.

Delete an ACL
You can delete the example ACL in the Network Protector Console, as illustrated in Figure 4-90.

Figure 4-90: Delete ACL

Private VLAN example


In this section, you will learn how to configure an additional ACL that will block traffic within a
VLAN. This is similar in concept to private VLANs created by traditional ACLs (see Figure 4-91).

Figure 4-91: Example topology for configuring private VLANs


In our example, students will not be able to access other devices within the same subnet, but will be
able to access servers such as hp.com.
Assume User VM4 (10.40.40.4) in the Student VLAN can ping UserVM3 (10.30.30.3) in the Staff
VLAN. If you were to test this assumption using a ping command, based on our example, you would
see the following output:
C:\Windows\system32> ping 10.30.30.3
Pinging 10.30.30.3 with 32 bytes of data:
Reply from 10.30.30.3: bytes=32 time=4ms TTL=127
Reply from 10.30.30.3: bytes=32 time<1ms TTL=127
Reply from 10.30.30.3: bytes=32 time<1ms TTL=127
Reply from 10.30.30.3: bytes=32 time<1ms TTL=127
Ping statistics for 10.30.30.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 4ms, Average = 1ms
C:\Windows\system32>

1. In the Network Protector Console, click Administration and then ACL Manager. No ACLs are
configured by default.
2. Click Add to add a new ACL and fill in the details. Following are example details, which you can
see in Figure 4-92.

Name: BlockUserComms
IP Source: 10.40.40.4 (The Subnet mask setting will result in the OpenFlow flow entry being
converted to 10.40.40.0 when you click OK)
IP Destination: 10.30.30.3 (The Subnet mask setting will result in the OpenFlow flow entry being
converted to 10.30.30.0 when you click OK)
Source Subnet: 255.255.255.0
Destination Subnet: 255.255.255.0
Action: Block

Figure 4-92: The Add ACL Rule dialog box with example details

Note
If you set the rule to block packets from IP source 10.40.40.4 and set the Bidirectional rule to
TRUE, then packets to the destination IP address 10.40.40.4 are also blocked.

Test the private ACL list


1. You can check to make sure your new private ACL list performs as planned by sending a ping
command from a workstation to a blocked workstation. In our example, UserVM4 (10.40.40.4) in
the Student VLAN pings UserVM3 (10.30.30.3) in the Staff VLAN. This ping should show that
traffic is blocked, as it does in the following example output:
C:\Windows\system32> ping 10.30.30.3
Pinging 10.30.30.3 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.30.30.3:


Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\system32>

View new flows in the HP VAN SDN Controller Console


Private ACLs create new flow entries. You can check these entries in the HP VAN SDN Controller
Console. The new flow for our example is illustrated in Figure 4-93.

Figure 4-93: New flows from private ACL


As Figure 4-93 shows, a flow has been created matching IPv4 traffic from a source network
10.40.40.0/24 and destination network 10.30.30.0/24. Matched traffic is dropped (apply_action =
blank).

View new flows on the switch console


1. Use the show openflow instance <vlan> flows command to view flows on the console of the
switch. Following is example output from switch P2:
P2# show openflow instance vlan40 flows
Flow 2
Match
Incoming Port : Any Ethernet Type : IP
Source MAC : Any Destination MAC : Any
Destination MAC Mask : 000000-000000
VLAN ID : Any VLAN priority : Any
Source IP Address : 10.40.40.0/24
Destination IP Address : 10.30.30.0/24
IP Protocol : Any

IP ECN : Any IP DSCP : Any


Source Port : Any Destination Port : Any
Attributes
Priority : 34050 Duration : 622 seconds
Hard Timeout : 3600 seconds Idle Timeout : 0 seconds
Byte Count : NA Packet Count : 4
Flow Table ID : 100 Controller ID : 2
Cookie : 0xcebcbeef
Hardware Index: 0
Instructions
Apply Actions

Because Apply Action is blank, matching traffic is dropped.

Delete private ACLs


Following are the instructions for deleting private ACLs:
1. In the Network Protector Console, delete the ACL (see Figure 4-94).

Figure 4-94: Delete ACL

Questions
The following questions will help you retain the information and concepts you have learned in the last
three sections.
Question 1: Can you block traffic based on a destination port number?

_________________________________________________________________
Question 2: What does the bidirectional option mean?
_________________________________________________________________
Question 3: Can traffic be blocked within a VLAN?
_________________________________________________________________
Question 1 answer
Yes, the Network Protector ACL manager allows you to block traffic based on destination port
number.
ACL Manager leverages five tuple packet attributes and the VLAN ID to create access control
policies.
The five attributes are
Source IP address
Source port (any)
Destination IP address
Destination port (80 or 443)
Destination protocol (typically TCP)
Question 2 answer
Both traffic to and from the host is blocked.
For example, if you set the rule to block packets from IP source 10.40.40.3 and set the Bidirectional
rule to TRUE, then packets to the destination IP address 10.40.40.3 are also blocked
Question 3 answer
Yes, traffic can be blocked within a VLAN.

Summary
In this chapter, you learned about the HP Network Protector SDN Application, which is a commercial,
enterprise SDN application. The application leverages an OpenFlow-enabled network to enhance
network features and functionality.
Network Protector does not require OpenFlow on all network devices, but rather only at the edge of
the network. Network Protector adds an additional layer of security by leveraging OpenFlow-enabled
edge switches running in hybrid mode. Flow tables are updated by the HP VAN SDN Controller to use
normal forwarding for most traffic. Network Protector adds an additional flow entry with a higher
priority to forward DNS traffic to the controller and then in turn to Network Protector for inspection.
The TippingPoint RepDV database is used as it contains hundreds of thousands of malicious website
entries.
By integrating Network Protector with an OpenFlow-enabled network, an additional layer of security
is added to block traffic to malicious websites.
In this chapter, you learned how to install, configure, and implement some of the features available

with Network Protector including:


DNS interception
Redirection servers
Custom blacklists, graylists, and whitelists
QoS
ACL Manager
In the next chapter, another enterprise SDN application is discussedthe HP Network Visualizer SDN
application.

Learning check
Answer each of following questions.
1. Which HP feature leverages switch ASICs for high throughput to the HP VAN SDN Controller?
a. Controller port
b. Service insertion tunnel
c. OpenFlow tunnel
d. IPSec tunnel
2. What is the minimum version of OpenFlow required on an HP ProVision switch to support service
insertion tunnels?
a. 1.0
b. 1.1
c. 1.3
d. 1.4
3. Which of the following is a requirement for service insertion tunnels on HP ProVision switches?
a. SNMPv3
b. Version 1.0 ASICs or later
c. OpenFlow 1.1 or later
d. Firmware 15.14

Learning check answers


1. b Service insertion tunnel
2. c 1.3
3. a SNMPv3

Chapter 5
HP Network Visualizer SDN Application
EXAM OBJECTIVES
In this chapter you will learn to:
Explain Network Visualizer benefits
Install and configure the HP Network Visualizer application
Explain Network Visualizer licensing
Integrate Network Visualizer with HP switches
Explain and configure Network Visualizer features, including:
Using the Capture Session wizard
Monitoring and analyzing the network
Network visibility
Event logs

Assumed knowledge
HP Comware and HP ProVision switch command line interface (CLI)
IP addressing
Basic routing protocols
Basic Internet protocols

Introduction
The Network Visualizer application is installed on the HP Controller and can dynamically forward traffic
to a monitoring device located in either an OpenFlow or non-OpenFlow-enabled network.
The network monitoring device could even be separated from the monitored devices by a wide area
network (WAN). This would require enough bandwidth for captured traffic, IP connectivity from the
OpenFlow-enabled switch to the capture device, and Generic Routing Encapsulation (GRE) tunnels
permitted by firewalls.
Automatic captures can be scheduled to take place at specific times in the future.

HP Network Visualizer SDN Appvisibility


The HP Network Visualizer Application provides visibility of network traffic and offers a flexible

solution for obtaining copies of network packets for auditing, verification, and dynamic troubleshooting
purposes (see Figure 5-1).

Figure 5-1: HP Network Visualizer SDN Appvisibility


You can get copies of network packets from multiple source devices and forward captured packets to a
collection device located almost anywhere in the network using a GRE tunnel.
Network Visualizer dynamically installs OpenFlow rules to monitor the network traffic using the filter
criteria specified by the network administrator via the graphical user interface (GUI). Filter criteria is
specified with SDN policy attributes built on access control list (ACL) networking match attributes and
legacy actions. The SDN policy attributes are the following:
Users
User devices
Location
Application
Status of network
Time
The Network Visualizer obtains the integration information on user devices from HP VAN SDN
Controller.

HP Network Visualizer key features


The major features of Network Visualizer, outlined in Figure 5-2, are the following:

Figure 5-2: HP Network Visualizer key features


Monitor and analyze the network: You can narrow down the source of network problems, know the
traffic peaks from any network device, and validate network connectivity.
Visibility: The Network Visualizer uses tshark for providing network visibility by capturing session
activity, status, and summary information. A combination of the following features provides network
visibility:
Client address identification
GUI-based real-time monitoring of captured packets
Dashboard charts
Detailed capture session view
Network visibility ensures that a given capture session is functional on a per network device basis. If not
functional, the reason for capture session failure is noted.
You can view the most recent 100 packets in the packet capture (pcap) file for a session. To view all of
the packets and to analyze the packets, open the pcap file in tshark.
Event Logs: The network visibility and monitoring tool must be reliable and provide good debugging
abilities. Event logs are a primary source of debug information. For example, if a capture session is
active and no packet is captured, the network administrator must be informed that there is no matching
traffic sent from the monitored source. The event log captures the source and reason for capture
failure. The event log retains the event entries for 180 days. The Network Visualizer generates an alert
when the event log is purged by the network administrator or the system.
Create Capture Session wizard: This is a step-by-step configuration wizard to create a new capture
session. The following modes of configuration are supported:
CustomConfigure the source/destination IP address, source/destination MAC address, port, and
protocol for a capture session.
UserConfigure the user, user group, device(s), and application for a capture session.

The Network Visualizer supports anonymity to hide user identity.


The Network Visualizer supports physical OpenFlow-enabled network devices along with Open
vSwitch (OVS) devices.

Installation
Install the HP Network Visualizer SDN Application from the HP VAN SDN Controller GUI, as illustrated
in Figure 5-3.

Figure 5-3: Installation


To install Network Visualizer:
1. Log in to the controller platform as a user with administrator privileges.
2. In the navigation tree, click General and then click Applications.
3. Click New to open the New Application window.
4. Click Browse, and then choose the target zip file containing the Network Visualizer.
5. Click Upload.
6. Click Deploy to deploy Network Visualizer.
On successful install, the Network Visualizer entry appears in the applications list.
Verify the following to ensure that the installation is successful:

The version of the Network Visualizer in the applications list is the same as the target version.
The state of the Network Visualizer application is ACTIVE in the applications list.

Network Visualizer installation instructions


This section provides instructions on how to install and license the HP Network Visualizer Application
on an HP VAN SDN Controller. The instructions use the IP addresses and configuration illustrated in
Figure 5-4.

Figure 5-4: Network Visualizer installation instructions


Before installation, it is recommended to first confirm current requirements for the HP Network
Visualizer application by reviewing sections of the Support Matrix document. This document was already
discussed in previous chapters and is reviewed here. It can be accessed by visiting the following links:
Note
HP
VAN
SDN
Controller
and
Applications
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647298

Support

Matrix

Questions and answers


Following are a series of questions to help you practice using the Support Matrix document.
Question: Which HP VAN SDN Controller version is supported by HP Network Visualizer 1.0?
Answer: Version 2.5 of the HP VAN SDN Controller supports version 1.0 of the HP Network Visualizer
Application.
Question: Is controller teaming supported in version 1.0 of the HP Network Visualizer Application?

Answer: No, teaming is not supported in version 1.0, but may be supported in later releases.
Question: The Network Visualizer supports integration with Microsoft Active Directory using
Lightweight Directory Access Protocol (LDAP) to obtain user groups. What does the network require for
this integration?
Answer: Requirements are the following:
Microsoft Active Directory: The server on which Microsoft Active Directory is installed must have
the following software installed: Windows Server 2012, Windows Server 2012 R2, or Windows
Server 2008 R2 with Windows Management Framework (WMF) 4.0.
A Secure Shell (SSH) Server.
Question: What are other software requirements for Network Visualizer?
Answer: Requirements are the following:
The same software requirements as the HP VAN SDN Controller (see section 1.2.1 of the support
matrix).
An SSH server: Ubuntu servers that host Destinations must have cURL and tshark (which is part of the
Wireshark distribution) installed.
Neither the HP Network Optimizer SDN ApplicationMicrosoft Lync application nor the HP
Network Protector applications can be installed on the controller on which the HP Network Visualizer
is installed.
Question: Does the HP Network Visualizer SDN Application require hybrid-mode on the HP VAN SDN
Controller and HP switches?
Answer: Yes, the HP Network Visualizer SDN Application requires OpenFlow-hybrid networks.
Question: Can Network Visualizer be installed on the same controller as Network Protector?
Answer: None of the following applications can be installed on the controller on which HP Network
Visualizer SDN Application is installed: HP Network Optimizer SDN Application, the Microsoft Lync
application, and the HP Network Protector SDN Application.
Question: Which switches are supported in version 1.0 of the HP Network Visualizer application?
Answer:
ProVision switches: 2920, 3800, 5400zl v2 modules only, 5400R zl2 v2 or v3 modules, 8200zl v2
modules only.
Others: Open vSwitch
This may change in future releases.
Question: Which switch software version is required?
Answer: K/KA/KB/WB.15.17.0007 or later

Install the HP Network Visualizer Application


This section outlines steps you can take to install the HP Network Visualizer Application on an HP VAN
SDN Controller, in this example, 192.168.56.13. It also provides steps for licensing the application.

Remember that, in the topology outlined in Figure 5-4, OpenFlow is only enabled on the edge switches
and only on untagged/access ports (user-facing VLANS). No uplink links (tagged/trunk ports) have
OpenFlow enabled.
1. Use Google Chrome on the Windows Jumphost to navigate to: http://192.168.56.13:8443/sdn/ui.
2. If asked, accept the self-signed certificate and proceed to log in to the server.
3. If prompted, log in with the following credentials:
Username: sdn
Password: skyline
4. In the HP VAN SDN Controller GUI, click Applications, as illustrated in Figure 5-5:

Figure 5-5: Controller applications.

WARNING
As Network Visualizer cannot be installed on a controller with either HP Network Protector or
Network Optimizer, make sure those applications are not installed. If they are, uninstall them first.
5. You need to install the HP Network Visualizer manually if you have no Internet access. If you have
Internet access, you can install the application directly from the HP App Store.
6. Click New, as illustrated in Figure 5-6:

Figure 5-6: Controller applications


7. Click Browse, illustrated in Figure 5-7:

Figure 5-7: New Application


8. Browse to the Desktop and open the necessary folder, in this example, the SDN Lab Files folder. Then
open the Software folder.
WARNING
The Network Visualizer software is downloaded as part of a zip file that also contains the release
note documentation. Ensure you select the right zip file as listed below which was unzipped from
the original downloaded zip file.
9. Browse to the Visualizer directory: hp-net-visualizer-v1.0.7-x64

10. Select the com.hp.networkvisualizer_v1.0.7.1499.zip file and click Open, as illustrated in Figure
5-8:

Figure 5-8: Upload an application


11. Click Upload, illustrated in Figure 5-9:

Figure 5-9: Upload an application


12. When the application has uploaded, click Deploy, illustrated in Figure 5-10:

Figure 5-10: Click Deploy


13. When the application is deployed, the controller page will update to show that Network Visualizer
was deployed successfully and will show a state of ACTIVE, illustrated in Figure 5-11:

Figure 5-11: Application install successful


14. Click Network Visualizer (if the menu does not show, refresh your browser) and then click
Dashboard, illustrated in Figure 5-12:

Figure 5-12: Network Visualizer


At the moment, no session data is displayed.
15. Click General and then Licenses, illustrated in Figure 5-13:

Figure 5-13: Controller licenses


No licenses are currently installed.
16. Network Visualizer requires an electronic license to enable its functionality. The following
licenses are required:
A VAN SDN Controller Base license
A Network Visualizer license
The following licenses are available for purchase:
JL091AAE HP Network Visualizer SDN App E-LTU

J9863AAE HP VAN SDN Controller Base Software with 50-node License E-LTU
The purchased licenses do not expire.
17. You do not need to, but if you want to install a local copy of Network Visualizer, you can obtain an
evaluation license.
Free 60-day evaluation licenses are available. These licenses are intended for product evaluation prior to
purchase. To obtain an evaluations license, follow this process:
Install the HP VAN SDN Controller.
Install the SDN Applications that you would like to evaluate. If you are using the AppStore,
install the Trial Mode SDN applications.
Go to the My Networking Portal http://www.hp.com/networking/mynetworking and select SDN
Evaluation Licenses.
Enter your install id. MNP generates every evaluation license possible for this install id.
Apply the relevant licenses to the controller and applications.
The following Network Visualizer Base License was generated for the Controller Install ID used in the
topology:
Notification from HP Networking:
This is a confirmation of your registration with the license details:
License key: BUYRMEYNO5CBO-NJTFY7S4NBTPN-YWA4QKEQZXAGB-RCUFS4OBKCMKA
Registration ID: CF7MHX2-X6QP79T-FJ4VFVY-4MCWXC8
Product number: JL091AAE
Product name: HP Network Visualizer SDN App E-LTU
License quantity: 1
Install ID: 61951246538401
Status: Active
Activation date: 22-Jun-2015
Expiration date: 21-Jun-2016
Friendly name: Visualizer App
Customer notes:

Is this License key the right one for the Install ID? Check Figure 5-14.

Figure 5-14: License information


Answer: Yes, this is the right license key.
18. Copy the license key on the Windows Jumphost from the necessary file, in this example:
\Desktop\SDN Lab Files\Software\Network Visualizer license Key.txt
19. Paste both license keys (one at a time and in order) into the Enter License box on the controller
(see Figure 5-15) and then click Add, illustrated in Figure 5-16:

Figure 5-15: Base license key

Figure 5-16: Visualizer license key


Result: Licenses are added to the controller, illustrated in Figure 5-17:

Figure 5-17: Licenses added

Questions
The following questions will help you retain the information and concepts you learned in the preceding
sections.
Question 1: Can Network Visualizer integrate with Active Directory?
_________________________________________________________________
Question 2: Is hybrid mode required for Network Visualizer?
_________________________________________________________________
Question 3: Which ProVision software version is required for Network Visualizer?
_________________________________________________________________

Answers
Question 1 answer
Yes, Network Visualizer supports integration with Microsoft Active Directory using LDAP to obtain user
groups.
Question 2 answer

Yes, Network Visualizer requires hybrid mode on switches and controller.


Question 3 answer
K/KA/KB/WB.15.17.0007 or later.

SNMP
Network Visualizer supports the configuration of SNMPv2 and SNMPv3 credentials for interaction with
network devices. You can create more than one set of SNMP profiles, but only one SNMP profile per
network device.
To create an SNMP profile, as illustrated in Figure 5-18:

Figure 5-18: SNMP


1. In the Configurations page, click the arrow to the left of SNMP Profiles.
2. Choose the SNMP Type (snmpv2 or snmpv3) from the drop-down list.
3. Enter the following credentials:
NameName of the SNMP profile
TypeType of SNMP profile
Read CommunityCommunity name for read access
Write CommunityCommunity name for write access
User NameName of the user
Auth TypeAuthentication protocol
Authentication PasswordAuthentication password
Privacy TypePrivacy protocol

Privacy PasswordPrivacy password


4. Click Add.

Switch configuration
Network Visualizer requires that OpenFlow be configured on switches that the application will capture
traffic from.
In Figure 5-19, version 1.3 of OpenFlow is used for OpenFlow instance vlan20 (HP ProVision switch).

Figure 5-19: Switch configuration


SNMPv3 configuration, as outlined in Figure 5-20, is recommended on ProVision switches.

Figure 5-20: Switch configuration

WARNING
Do not use the SNMP wizard for user configuration. Enable SNMP and then manually create the
required user account (sdn in this example). It is recommended that the created initial user be
deleted unless explicitly required.
This is an example of SNMPv3 configuration on a 3800 series switch:
P1(config)# snmpv3 enable
SNMPv3 Initialization process.
Creating user 'initial'
Authentication Protocol: MD5
Enter authentication password: *******
Privacy protocol is DES
Enter privacy password: *******
User 'initial' has been created
Would you like to create a user that uses SHA? [y/n] n
User creation is done. SNMPv3 is now functional.
Would you like to restrict SNMPv1 and SNMPv2c messages to have read only access (you can
set this later by the command 'snmpv3 restricted-access')? [y/n] y
P1(config)# snmpv3 user sdn auth md5 skyline priv des skyline
P1(config)# snmpv3 group ManagerPriv user sdn sec-model ver3

Note
The command snmpv3 restricted-access is optional.

Capture destinations
A destination or pcap repository is the receiver for the copied traffic. It can be on a local or a remote
system. You can configure a destination as follows:
Managed destination: Runs as a daemon service that receives capture packets and persists them in
pcap format. A local managed destination is installed when you install Network Visualizer. You must
configure and deploy remote destinations from Network Visualizer.
Unmanaged destination: You can run a program or solution to process the incoming copy traffic from
the network device.
For successful installations, the State shows connected in the Destinations panel, as shown in Figure 521.

Figure 5-21: Capture destinations

Custom mode capture


The Network Visualizer Create Capture Session wizard is a step-by-step configuration wizard to create
a new capture session (see Figure 5-22). The following modes of configuration are supported:
Custom: Configure the source/destination IP address, source/destination MAC address, port, and
protocol for a capture session.
User: Configure the user, user group, device(s), and application for a capture session.

Figure 5-22: Custom Mode capture


You can create capture sessions using the Create Capture Session wizard and then select the filter policy,

destination, and schedule to monitor a session. To access the wizard, click Create Capture Session from
the Network Visualizer navigation tree.
In the first step, add the session name and choose the session mode in the Session Name panel. Enter the
capture session name in the Session Name text box. By default, the session mode is User. Click the radio
button to the left of one of the following session modes:
User
Custom
In the second step, set the filter criteria, as shown in Figure 5-23:

Figure 5-23: Custom Mode capture (continued)


Switch IP: IP address of the network device
Bidirectional: Select the traffic capture direction by clicking one of the following:
Yes: Captures packets sent and received by the user
No: Captures packets sent by the user
Source IP: IP address of the source (for example, 10.40.40.4)
Destination IP: IP address of the destination (for example, 192.168.56.51)
Source MAC: MAC address of the source (for example, aa:bb:cc:dd:ee:ff)
Destination MAC: MAC address of the destination (for example, aa:bb:cc:dd:ee:ff)
Protocol: Network protocol. By default, protocol is All
Source Port: Layer 4 port for the source
Destination Port: Layer 4 port for the destination
File Name: Name of the pcap file in which to save the packets

Configure the schedule for monitoring the capture session in the Schedule panel, as shown in Figure 5-24.

Figure 5-24: Custom Mode capture


Schedule options:
No Selection: Monitoring of a capture session is not scheduled.
Once: Monitor the capture session once. Specify the Start Time and Stop Time.
Everyday: Monitor the capture session everyday. Specify the repeat interval in Repeat every (days),
Start Time, Stop Time, and End Date.
Weekday (Monday to Friday): Monitor the capture session on weekdays. Specify the Start Time,
Stop Time, and End Date.
Weekend (Saturday and Sunday): Monitor the capture session on weekends. Specify the Start Time,
Stop Time, and End Date.
Weekly: Monitor the capture session on a weekly basis. Select the days of the week to capture the
sessions with Repeat on check boxes. Specify the Start Time, Stop Time, and End Date.
The last step in the wizard is to activate the session, as shown in Figure 5-25. Captures can be started
immediately or scheduled.

Figure 5-25: Custom Mode capture (continued)


Behavior after activation:
Nonscheduled session: Capture rule is installed right away if devices are discovered.
Scheduled session: Scheduled session is saved, and once time range is reached, capture rule is
installed if devices are discovered.
In both cases, the system updates the number of runs.

Session Monitor
The Session Monitor provides detailed information about the capture sessions and allows session
management, as shown in Figure 5-26.

Figure 5-26: Session Monitor


Options include the following:
Click the radio button next to a session to view the Destination and Flow Entries.
Click View to view the last 100 packets captured by the Destination.
Click Refresh to refresh the table.
Click Filter to filter a session by name from the table.
Click Export All to export all of the monitor session details to a .csv file.
Click Create to launch the Create Capture Session wizard.
Click Delete to delete the session.
Click Activate or Deactivate to activate or deactivate a session.
Click Enable or Disable to enable or disable the scheduled session.

Real-time traffic
With Session Monitor, you can view captures in real time (see Figure 5-27).

Figure 5-27: Real-time traffic


Clicking View displays the last 100 packets captured by the selected active session. Click Refresh to
view the next 100 packets.

Network Visualizer Dashboard


Overview
The Network Visualizer dashboard provides the graphic representation of the current capture session
configuration, capture session failures, and discovered devices by type and operating system (OS).
The dashboard displays the following charts along with a link below Sessions and Capture Sessions, as
illustrated in Figure 5-28.

Figure 5-28: Network Visualizer Dashboard

Failure charts provide additional details:


Sessions
Capture sessions failure
Discovered devices by OS
Discovered devices by type
To access the dashboard, click Dashboard from the Network Visualizer navigation tree.

Sessions chart
The semidonut Sessions chart, as shown in Figure 5-29, displays the current state of all the capture
sessions. The sessions can be in any one of the following states at any given time:

Figure 5-29: Session chart


CreatedNumber of created capture sessions
ActiveNumber of active capture sessions
InactiveNumber of inactive capture sessions
PartialNumber of sessions for which the network traffic capture failed on a few devices
FailedNumber of sessions for which the network traffic capture failed
ScheduledNumber of sessions for which network traffic capture is scheduled

Capture Sessions Failure chart


The Capture Sessions Failure stacked chart, shown in Figure 5-30, displays information about the
deployment of monitoring policies across configured network devices for the most recent five unique
sessions.

Figure 5-30: Capture Sessions Failure chart


The y-axis indicates the number of configured network devices for a session and the x-axis indicates the
name of the sessions. The stacked bar indicates the number of network devices on which monitor
configuration deployment succeeded and failed for each session.
The chart displays the following information:
Success: Displays the total number of network devices on which the monitor configuration deployment
succeeded for a session.
Failure: Displays the total number of network devices on which the monitor configuration deployment
failed for a session.

Discovered devices
The Discovered Devices by OS chart displays the share of discovered devices by operating systems as a
pie chart (see Figure 5-31).

Figure 5-31: Network Visualizer Dashboard


In the chart, you can view the following information:
Android: Indicates the number of devices with Android operating system.
Windows: Indicates the number of devices with Windows operating system.
IOS: Indicates the number of devices with iOS operating system.
Others: Indicates the number of devices with any other operating system.
The Discovered Devices by Type chart displays the share of device types discovered by the Network
Visualizer as a pie chart:
In the chart, you can view the following information:
Laptop/Desktop: Indicates the number of discovered laptops and desktops.
Mobiles/Tablets: Indicates the number of discovered mobile devices and tablets.
Servers: Indicates the number of discovered servers.
Unknown: Indicates the number of discovered unknown devices.

Network Visualizer physical switch integration instructions


This section outlines how to integrate the Network Visualizer with the existing HP network. This requires
SNMP configuration on both the HP switches (configured previously) and Network Visualizer. Figure 532 illustrates the topology used for the instructions.

Figure 5-32: Example topology for instructions


You will also review how to set up a capture session and forward captured traffic to the Jumphost
running Wireshark, as well as how to view the OpenFlow flow entries created by Network Visualizer.
These instructions are for 3800 series switches.

Instructions
1. As already discussed, ProVision switches P1 and P2 require version 15.17 of switch software. Which
software version are the ProVision switches using? Following is example output for switch P1:
P1# show version
Image stamp:
/ws/swbuildm/rel_orlando_qaoff/code/build/tam(swbuildm_rel_orlando_qaoff_rel_orlando)
Jan 30 2015 18:59:40
KA.15.16.0006
79
Boot Image: Primary
P1#
P2# show version
Image stamp:
/ws/swbuildm/rel_orlando_qaoff/code/build/tam(swbuildm_rel_orlando_qaoff_rel_orlando)
Jan 30 2015 18:59:40

KA.15.16.0006
79
Boot Image: Primary
P2#

Result: Your switches may be using 15.16 software.


2. Check software versions in flashconfirm that 15.17 is available:
P1# show flash
Image Size (bytes) Date Version
----------------- ------------ -------- -------------Primary Image : 16364977 01/30/15 KA.15.16.0006
Secondary Image : 16909523 06/17/15 KA.15.17.0007
Boot ROM Version : KA.15.09
Default Boot : Primary
P1#
P2# show flash
Image Size (bytes) Date Version
----------------- ------------ -------- -------------Primary Image : 16364977 01/30/15 KA.15.16.0006
Secondary Image : 16909523 06/17/15 KA.15.17.0007
Boot ROM Version : KA.15.09
Default Boot : Primary
P2#

Result: Version 15.17 is available in secondary flash.


3. Boot the ProVision switches (P1 and P2) using 15.17:
P1# boot system flash secondary
System will be rebooted from secondary image. Do you want to continue [y/n]? y
P2# boot system flash secondary
System will be rebooted from secondary image. Do you want to continue [y/n]? y

Result: Switches reboot using 15.17 of software.


4. Confirm that switches are using 15.17:
P1# show version
Image stamp:

/ws/swbuildm/rel_portland_qaoff/code/build/tam(swbuildm_rel_portland_qaoff_rel_portland)
Jun 17 2015 16:04:30
KA.15.17.0007
238
Boot Image: Secondary
Boot ROM Version: KA.15.09
Active Boot ROM: Primary
P1#
P2# show version
Image stamp:
/ws/swbuildm/rel_portland_qaoff/code/build/tam(swbuildm_rel_portland_qaoff_rel_portland)
Jun 17 2015 16:04:30
KA.15.17.0007
238
Boot Image: Secondary
Boot ROM Version: KA.15.09
Active Boot ROM: Primary
P2#

5. On the HP Controller GUI, click Network Visualizer and then click Configuration, as shown in
Figure 5-33:

Figure 5-33: Network Visualizer Configuration


6. Network Visualizer supports configuration of SNMPv2 and SNMPv3 credentials for interaction with
network devices. As SNMPv3 was previously configured on the switches in this example, SNMPv3
will be used. Click SNMP Profiles and create a profile with the following details and then click Add,

as shown in Figure 5-34:


Name: SNMPv3Profile
Type: snmpv3
Username: sdn
Auth Type: MD5
Authentication Password: skyline
Privacy Type: DES
Privacy Password: skyline

Figure 5-34: SNMPv3 configuration


Result: SNMP Profile is added (see Figure 5-35):

Figure 5-35: SNMPv3 results


7. Use PuTTY on the Jumphost to connect to the HP VAN SDN Controller server using SSH as follows:
IP address: 192.168.56.13
Port number: 22
Protocol: SSH
Verify that the HP VAN SDN Controller can ping all the HP switches in your environment:
sdn@sdnctl3:~$ ping 192.168.56.251
PING 192.168.56.251 (192.168.56.251) 56(84) bytes of data.
64 bytes from 192.168.56.251: icmp_req=1 ttl=255 time=4.38 ms
64 bytes from 192.168.56.251: icmp_req=2 ttl=255 time=0.906 ms
^C
--- 192.168.56.251 ping statistics --2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.906/2.647/4.389/1.742 ms
sdn@sdnctl3:~$ ping 10.1.1.252
PING 10.1.1.252 (10.1.1.252) 56(84) bytes of data.
64 bytes from 10.1.1.252: icmp_req=1 ttl=254 time=0.973 ms
64 bytes from 10.1.1.252: icmp_req=2 ttl=254 time=0.951 ms

^C
--- 10.1.1.252 ping statistics --2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.951/0.962/0.973/0.011 ms
sdn@sdnctl3:~$ ping 10.1.1.253
PING 10.1.1.253 (10.1.1.253) 56(84) bytes of data.
64 bytes from 10.1.1.253: icmp_req=1 ttl=254 time=0.973 ms
64 bytes from 10.1.1.253: icmp_req=2 ttl=254 time=0.951 ms
^C
--- 10.1.1.252 ping statistics --2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.951/0.962/0.973/0.011 ms
sdn@sdnctl3:~$ ping 10.1.1.254
PING 10.1.1.254 (10.1.1.254) 56(84) bytes of data.
64 bytes from 10.1.1.254: icmp_req=1 ttl=254 time=0.456 ms
^C
--- 10.1.1.254 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.456/0.456/0.456/0.000 ms
sdn@sdnctl3:~$

Result: All pings should succeed.


8. Configure ProVision switch 1 (P1) to use the Network Visualizer Controller (192.168.56.13):
P1# conf
P1(config)# openflow
P1(openflow)# controller-id 3 ip 192.168.56.13 controller-interface vlan 1
P1(openflow)# instance vlan30
P1(of-inst-vlan30)# disable
P1(of-inst-vlan30)# no controller-id 2
P1(of-inst-vlan30)# controller-id 3
P1(of-inst-vlan30)# enable
P1(of-inst-vlan30)# end
P1#

9. View the switch configuration and verify that the OpenFlow and SNMP configuration is the same as

the following:
P1# show running-config
...<omitted>
snmp-server community "public" unrestricted
snmpv3 enable
snmpv3 restricted-access
snmpv3 group managerpriv user "sdn" sec-model ver3
snmpv3 user "initial"
snmpv3 user "sdn"
openflow
controller-id 1 ip 192.168.56.11 controller-interface vlan 1
controller-id 2 ip 192.168.56.12 controller-interface vlan 1
controller-id 3 ip 192.168.56.13 controller-interface vlan 1
instance "vlan30"
member vlan 30
controller-id 3
version 1.3
enable
exit
enable
exit

10. Check controller status:


P1# show openflow instance vlan30
Configured OF Version : 1.3
Negotiated OF Version : 1.3
Instance Name : vlan30
Admin. Status : Enabled
Member List : VLAN 30
... <omitted>...
Controller Id Connection Status Connection State Secure Role
------------- ----------------- ---------------- ------ -----3 Connected Active No Equal
P1#

Result: Switch has an active connection to controller 192.168.56.13.


11. Configure ProVision switch 2 (P2) to use the Network Visualizer Controller:
P2# conf
P2(config)# openflow
P2(openflow)# controller-id 3 ip 192.168.56.13 controller-interface vlan 1
P2(openflow)# instance vlan40
P2(of-inst-vlan40)# disable
P2(of-inst-vlan40)# no controller-id 2
P2(of-inst-vlan40)# controller-id 3
P2(of-inst-vlan40)# enable
P2(of-inst-vlan40)# end
P2#

12. View the switch configuration and verify that the OpenFlow configuration is the same as the
following:
P2# show running-config
...<omitted>
snmp-server community "public" unrestricted
snmpv3 enable
snmpv3 restricted-access
snmpv3 group managerpriv user "sdn" sec-model ver3
snmpv3 user "initial"
snmpv3 user "sdn"
openflow
controller-id 1 ip 192.168.56.11 controller-interface vlan 1
controller-id 2 ip 192.168.56.12 controller-interface vlan 1
controller-id 3 ip 192.168.56.13 controller-interface vlan 1
instance "vlan40"
member vlan 40
controller-id 3
version 1.3
enable
exit
enable

exit

13. Check controller status:


P2# show openflow instance vlan40
Configured OF Version : 1.3
Negotiated OF Version : 1.3
Instance Name : vlan40
Admin. Status : Enabled
Member List : VLAN 40
...<omitted>...
Controller Id Connection Status Connection State Secure Role
------------- ----------------- ---------------- ------ -----3 Connected Active No Equal
P2#

Result: Switch has an active connection to controller 192.168.56.13.


14. In the Network Visualizer GUI, click Event Logs, as shown in Figure 5-36:

Figure 5-36: Event logs


Result: Switches 10.1.1.253 and 10.1.1.254 are discovered.
15. Click Configuration and then Destinations.
16. Configure the following values and click Add:
Destination Name: Jumphost
IP address: 192.168.56.5 (this is the IP address of the Jumphost PC)

Managed = Unchecked (off)


Click Add (see Figure 5-37):

Figure 5-37: Destinations


17. You can create capture sessions using the Create Capture Session wizard. You can select the filter
policy, destination, and schedule to monitor a session. To access the wizard, click Create Capture
Session (see Figure 5-38):

Figure 5-38: Capture Session


18. In the first step in the wizard a session name and mode are configured.
Sessions can be configured as either User or Custom:
User: You can configure the user, user group, device, and application for capture session
monitoring.
Custom: You can configure the source/destination IP address, source/destination MAC address,
port, and protocol for capture session monitoring.
Add a session name of UserVM4 and set the session mode to Custom, as shown in Figure 5-39, and click
Next:

Figure 5-39: Session name


19. In the second step, a Filter Policy is configured. Set the following values, shown in Figure 5-40:
Switch IP: 10.1.1.254
Bidirectional: Yes
Source IP: 10.40.40.4
Destination IP: 192.168.56.51
Protocol: TCP
Leave other options and default values and click Next:

Figure 5-40: Filter Policy


Filter Policy information:
Switch IP: IP address of the network device
Bidirectional: Select the traffic capture direction by clicking one of the following:
YesCaptures packets sent and received by the user
NoCaptures packets sent by the user
Source IP: IP address of the source (for example, 10.40.40.4)
Destination IP: IP address of the destination (for example, 192.168.56.51)
Source MAC: MAC address of the source (for example, aa:bb:cc:dd:ee:ff)
Destination MAC: MAC address of the destination (for example, aa:bb:cc:dd:ee:ff)
Protocol: Network protocol; by default, protocol is All
Source Port: Layer 4 port for the source
Destination Port: Layer 4 port for the destination
File Name: Name of the pcap file to save the packets
20. The third step in the wizard is Destination. Specify Jumphost and click Next (see Figure 5-41):

Figure 5-41: Destination


21. The fourth step is Schedule. Do not set a schedule for captures (No Selection) and click Next (see
Figure 5-42):

Figure 5-42: Schedule

Schedule options:
No Selection: Monitoring of capture session is not scheduled.
Once: Monitor the capture session once. Specify the Start Time and Stop Time.
Everyday: Monitor the capture session without day restrictions. Specify the repeat interval in
Repeat every (days), Start Time, Stop Time, and End Date.
Weekday (Monday to Friday): Monitor the capture session on weekdays. Specify the Start Time,
Stop Time, and End Date.
Weekend (Saturday and Sunday): Monitor the capture session on weekends. Specify the Start
Time, Stop Time, and End Date.
Weekly: Monitor the capture session on a weekly basis. Select the days of the week to capture the
sessions with Repeat on check boxes. Specify the Start Time, Stop Time, and End Date.
Explanation:
Start Time is when the session capture starts.
Stop Time is when the session capture stops.
End Date is the day when the schedule ends.
22. A summary of options selected is shown. Review the summary information and click Finish (see
Figure 5-43):

Figure 5-43: Summary

Activate the session


1. Before activating the session, start Wireshark. The icon is shown in Figure 5-44:

Figure 5-44: Start Wireshark


2. Click Capture and then Interfaces (see Figure 5-45).

Figure 5-45: Wireshark interfaces


3. Select the correct network, in this example, Lab Network, and click Options (see Figure 5-46).

Figure 5-46: Wireshark interfaces


4. Cancel the selection of Use promiscuous mode on all interfaces and click Start (see Figure 5-47).
Promiscuous mode is not required as traffic will be forwarded to the PC directly using a GRE tunnel:

Figure 5-47: Wireshark Capture Options


5. In Network Visualizer, click Activate to start the session (see Figure 5-48):

Figure 5-48: Session status


6. The Session Monitor displays showing capture information (see Figure 5-49):

Figure 5-49: Session Monitor


7. On UserVM4 (10.40.40.4), browse to hp.com (see Figure 5-50).

Figure 5-50: Test site hp.com


Result: Browsing succeeds.
8. Wireshark is capturing lots of data, so apply the following filter, shown in Figure 5-51:
ip.src == 10.40.40.4 || ip.dst == 10.40.40.4 and click Apply:

You may prefer using the following shorter Wireshark filter:


ip.addr == 10.40.40.4

Both options will result in traffic to or from 10.40.40.4 being displayed.

Figure 5-51: Wireshark filter


Result: Traffic destined to or from 10.40.40.4 is displayed.
9. If no traffic is received, verify that a default gateway of 192.168.56.251 is configured on the Jumphost.
You can also change the Wireshark filter to GRE to check if GRE tunnel packets are being received.
10. Stop the Wireshark capture (see Figure 5-52):

Figure 5-52: Wireshark capture

11. View the details of a captured packet. In Figure 5-53 the following can be seen:
Layer 2: Ethernet Frame with source MAC address of an HP switch and the destination a
VMware virtual machine (Jumphost)
Layer 3: IP source of 10.1.1.254 (ProVision P2) and IP destination of 192.168.56.5 (Jumphost)
Layer 4: GRE tunnel
Encapsulated Layer 2: Source MAC address of VMware host (UserVM4) and destination MAC
address of an HP switch (Comware switch C1)
Encapsulated 802.1Q VLAN information
Encapsulated Layer 3: Source IP address of 10.40.40.4 (UserVM4) and destination IP address of
192.168.56.51 (hp.com test website)
Encapsulated Layer 4: TCP destination port 80

Figure 5-53: Wireshark capture


12. On the HP Controller GUI, click General and then OpenFlow Monitor (see Figure 5-54). Select
ProVision Switch 2 (10.1.1.254).

Figure 5-54: OpenFlow Monitor


13. Click Flows to view the flow table of the switch (see Figure 5-55):

Figure 5-55: Added flows


Result: Flow entries were added by the Network Visualizer Application. The flows forward traffic to a
service insertion tunnel. Two flow entries are added because bidirectional was selected.
This can also be seen on the console of the switch:
P2# show openflow instance vlan40 flows
Flow 2
Match
Incoming Port : Any Ethernet Type : IP
Source MAC : Any Destination MAC : Any
Source MAC Mask : 000000-000000
Destination MAC Mask : 000000-000000

VLAN ID : Any VLAN priority : Any


Source IP Address : 10.40.40.4/32
Destination IP Address : 192.168.56.51/32
IP Protocol : TCP
IP ECN : Any IP DSCP : Any
Source Port : Any Destination Port : Any
Attributes
Priority : 30500 Duration : 1420 seconds
Hard Timeout : 0 seconds Idle Timeout : 0 seconds
Byte Count : NA Packet Count : 13
Flow Table ID : 100 Controller ID : 3
Cookie : 0x3cb7c
Hardware Index: 17
Instructions
Apply Actions
Output : ServiceTunnel18
Normal
Flow 3
Match
Incoming Port : Any Ethernet Type : IP
Source MAC : Any Destination MAC : Any
Source MAC Mask : 000000-000000
Destination MAC Mask : 000000-000000
VLAN ID : Any VLAN priority : Any
Source IP Address : 192.168.56.51/32
Destination IP Address : 10.40.40.4/32
IP Protocol : TCP
IP ECN : Any IP DSCP : Any
Source Port : Any Destination Port : Any
Attributes
Priority : 30501 Duration : 1420 seconds
Hard Timeout : 0 seconds Idle Timeout : 0 seconds
Byte Count : NA Packet Count : 11
Flow Table ID : 100 Controller ID : 3

Cookie : 0x3cb7c
Hardware Index: 17
Instructions
Apply Actions
Output : ServiceTunnel18
Normal

14. In Wireshark, add http && to the filter to view only HTTP packets, as shown in Figure 5-56.
Filter: http && ip.src == 10.40.40.4 || ip.dst == 10.40.40.4

Figure 5-56: HTTP GET


Result: In the figure above, an HTTP GET packet is shown. In Figure 5-57, HTML from the server is
shown.

Figure 5-57: HTML from server


15. In Network Visualizer, deactivate the UserVM4 session by clicking Deactivate (see Figure 5-58):

Figure 5-58: Deactivate session


16. Set up a new capture session by clicking Create Capture Session. Add a Session Name of
UserVM3.

17. Select a Session Mode of Custom and click Next (see Figure 5-59).

Figure 5-59: Session name


18. Create a Filter Policy with the following values, shown in Figure 5-60:
Switch IP: 10.1.1.253
Bidirectional: Yes
Source IP: 10.30.30.3
Leave other options and default values and click Next:

Figure 5-60: Filter policy


19. For the Destination, select Jumphost and click Next (see Figure 5-61).

Figure 5-61: Destination


20. Do not set a schedule for captures (No Selection) and click Next (see Figure 5-62).

Figure 5-62: Schedule

21. Review the summary information and click Finish (see Figure 5-63).

Figure 5-63: Summary


22. Click Activate to start the session (see Figure 5-64):

Figure 5-64: Session status


23. The Session Monitor displays capture information, as shown in Figure 5-65.

Figure 5-65: Session monitor


24. Start a new Wireshark capture (see Figure 5-66).

Figure 5-66: Start Capture


25. Click Continue without Saving (see Figure 5-67).

Figure 5-67: Continue without Saving


26. Clear the Wireshark filter (see Figure 5-68).

Figure 5-68: Wireshark filter


27. On UserVM3 (10.30.30.3), ping 192.168.56.11:
C:\Users\Student>ping 192.168.56.11
Pinging 192.168.56.11 with 32 bytes of data:
Reply from 192.168.56.11: bytes=32 time<1ms TTL=63
Reply from 192.168.56.11: bytes=32 time<1ms TTL=63
Reply from 192.168.56.11: bytes=32 time<1ms TTL=63
Reply from 192.168.56.11: bytes=32 time<1ms TTL=63
Ping statistics for 192.168.56.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Users\Student>

Result: Ping succeeds.


28. Stop the Wireshark capture:
29. Apply the following filter: icmp (see Figure 5-69)

Figure 5-69: Wireshark filter


30. Find an ICMP message from 10.30.30.3 to 192.168.56.11 (see Figure 5-70).

Figure 5-70: Wireshark filter


In Figure 5-70 above the following can be seen:
Layer 2: Ethernet Frame with source MAC address of an HP switch and the destination a VMware
virtual machine (Jumphost)
Layer 3: IP source of 10.1.1.253 (ProVision S1) and IP destination of 192.168.56.5 (Jumphost)
Layer 4: GRE tunnel
Encapsulated Layer 2: Source MAC address of VMware host (UserVM3) and destination MAC
address of an HP switch (Comware switch 1)
Encapsulated 802.1Q VLAN information
Encapsulated Layer 3: Source IP address of 10.30.30.3 (UserVM4) and destination IP address of
192.168.56.11 (HP VAN SDN Controller)
Encapsulated Layer 4: ICMP echo request message
31. Find the echo reply message (see Figure 5-71).

Figure 5-71: Wireshark capture


Result: An echo reply message from 192.168.56.11 to 10.30.30.3 can be seen in the above figure. The
packet shows the original echo reply packet encapsulated in a GRE packet.
32. On the HP Controller GUI, click General and then OpenFlow Monitor (see Figure 5-72). Select
ProVision Switch 1 (10.1.1.253).

Figure 5-72: OpenFlow Monitor


33. Click Flows to view the flow table of the switch (see Figure 5-73).

Figure 5-73: Flows


Result: Flow entries have been added by the Network Visualizer application forwarding traffic to a

service insertion tunnel for a source and destination of 10.30.30.3.


This can also be seen on the console of the switch:
P1# show openflow instance vlan30 flows
Flow 2
Match
Incoming Port : Any Ethernet Type : IP
Source MAC : Any Destination MAC : Any
Source MAC Mask : 000000-000000
Destination MAC Mask : 000000-000000
VLAN ID : Any VLAN priority : Any
Source IP Address : Any
Destination IP Address : 10.30.30.3/32
IP Protocol : Any
IP ECN : Any IP DSCP : Any
Source Port : Any Destination Port : Any
Attributes
Priority : 30501 Duration : 2840 seconds
Hard Timeout : 0 seconds Idle Timeout : 0 seconds
Byte Count : NA Packet Count : 24
Flow Table ID : 100 Controller ID : 3
Cookie : 0x3cb7c
Hardware Index: 17
Instructions
Apply Actions
Output : ServiceTunnel18
Normal
Flow 8
Match
Incoming Port : Any Ethernet Type : IP
Source MAC : Any Destination MAC : Any
Source MAC Mask : 000000-000000
Destination MAC Mask : 000000-000000
VLAN ID : Any VLAN priority : Any
Source IP Address : 10.30.30.3/32

Destination IP Address : Any


IP Protocol : Any
IP ECN : Any IP DSCP : Any
Source Port : Any Destination Port : Any
Attributes
Priority : 30500 Duration : 3092 seconds
Hard Timeout : 0 seconds Idle Timeout : 0 seconds
Byte Count : NA Packet Count : 153
Flow Table ID : 100 Controller ID : 3
Cookie : 0x3cb7c
Hardware Index: 17
Instructions
Apply Actions
Output : ServiceTunnel18
Normal

Open vSwitch
In addition to HP switches, Network Visualizer supports Open vSwitches (see Figure 5-74). As
previously discussed, Open vSwitch is a multilayer, open source, software switch.

Figure 5-74: Open vSwitch

Start two capture sessions simultaneously instructions


This section provides instructions on how to integrate Network Visualizer with Open vSwitch running in
a Mininet environment. You will review how to set up a capture session and forward captured traffic to
the Jumphost running Wireshark. You will also view the OpenFlow flow entries created by Network
Visualizer. The topology shown in Figure 5-75 is used for this section.

Figure 5-75: Start two capture sessions simultaneously instructions


These instructions require 3800 series switches.

Instructions
1. In Network Visualizer, ensure that both UserVM3 and UserVM4 sessions are activated (see Figure 576):

Figure 5-76: Activate session


2. Click Dashboard to view the active sessions and discovered devices (see Figure 5-77).

Figure 5-77: Dashboard


Result: Two sessions are currently active (UserVM3 and UserVM4). No iOS or Android devices are
discovered in this example.
A production network output may look like Figure 5-78.

Figure 5-78: Production examples


3. Start a new Wireshark capture (see Figure 5-79).

Figure 5-79: Start Capture


4. Click Continue without Saving (see Figure 5-80).

Figure 5-80: Continue without Saving


5. Clear the Wireshark filter (see Figure 5-81).

Figure 5-81: Wireshark filter


6. On UserVM3 (10.30.30.3), browse to hp.com (see Figure 5-82).

Figure 5-82: Test site hp.com


7. On UserVM4 (10.40.40.4), browse to hp.com (see Figure 5-83).

Figure 5-83: Test site hp.com


8. Change the filer in Wireshark to http && ip.dst==192.168.56.51.
9. Select a captured packet from 10.30.30.3 and 10.40.40.4, as shown in Figure 5-84 and Figure 5-85.

Figure 5-84: UserVM3 traffic capture

Figure 5-85: UserVM4 traffic capture


Result: HTTP traffic from both 10.30.30.3 and 10.40.40.4 can be captured simultaneously. This traffic is
captured at different points in the network (ProVision switches P1 and P2) and forwarded via service
insertion tunnels to the Windows PC running Wireshark.
Note
You captured traffic from various points in your network across a non-OpenFlow-enabled network.
OpenFlow is only enabled on the edge ports of the ProVision switches.
10. In Network Visualizer, deactivate both sessions by selecting each session and clicking Deactivate
(see Figure 5-86).

Figure 5-86: Deactivate sessions

Active Directory integration


HP Network Visualizer supports integration with Microsoft Active Directory using LDAP protocol to
obtain user groups. You can configure only one LDAP profile. This LDAP profile can be updated. Any
time the LDAP profile is added or updated, the records from the last 1 hour are synced from the Active
Directory.
Information on the LDAP profile is shown in Figure 5-87.

Figure 5-87: Active Directoryintegration


To create the LDAP profile, do the following:
1. In the Configurations page, click the arrow to the left of LDAP Profile.
2. Enter the following:
Profile Name: Name of the profile
User Name: Active Directory account name; user must have read access to Active Directory event
logs
Password: Active Directory system password
Domain Name: Active Directory system domain name
IP Address: Active Directory system IP address
Authorization Port: Port on which Active Directory is configured; default port is 389
Directory Sync (in Minutes): The sync up interval to fetch user records from Active Directory
Health Check Interval (in Minutes): The interval to check the health of SSH connection between

Network Visualizer and Active Directory

Users
Network administrators configure the users for traffic capturing by specifying the names and MAC
addresses of the devices owned by the user. Network administrators can specify the system login name as
a user name if an LDAP profile is configured. If an LDAP profile is configured, specifying the MAC
address is optional (see Figure 5-88).

Figure 5-88: Users


Click Import to import a user from a .csv file. In the Import Users window, click Browse to specify the
path of the.csv file and click Upload.
The following is a sample .csv file:
Name,mac
User1,d8:9d:67:ce:0c:38
User2,d8:9d:67:ce:0c:39

Capture sessionuser mode


Add the session name and choose the session mode in the Session Name panel, as shown in Figure 5-89.
Enter the capture session name in the Session Name text box. By default, the session mode is Useryou
can configure the user, user group, device, and application for a capture session.

Figure 5-89: Capture sessionuser mode


Specify the filter criteria for the capture session in the Filter Policy panel. Configure the following filter
criteria for user capture session mode, as shown in Figure 5-90.

Figure 5-90: Capture sessionuser mode (continued)


Group: Monitor a group of users. You must configure LDAP Profile for monitoring user groups. By
default, the group is set to unknown.
User: Monitor a user, group of users, or all users. Select the users from the drop-down list.

Device: Monitor a device or all devices for the selected user, group of users, or all users. Select the
devices from the drop-down list. The devices are displayed when one user is selected. For more than
one user, all devices are selected by default.
Bidirectional: Select the traffic capture direction by clicking one of the following:
Yes: Captures packets sent and received by the user.
No: Captures packets sent by the user.
Application: Monitor an application or all applications. Select the applications from the drop-down
list.
File Name: Name of the pcap file to save the packets.

Anonymity mode
The Network Visualizer supports anonymity for network administrators to monitor user devices
anonymously. User identity is not displayed if anonymity mode is enabled. User identity is not restored
when anonymity mode is disabled.
To enable or disable Anonymous Mode (see Figure 5-91):

Figure 5-91: Anonymity mode


1. In the Configurations page, click the arrow to the left of Anonymous Mode.
2. Select the Enable anonymity to hide identity information on views checkbox and then click the
Submit button.
Note
You cannot enable or disable anonymity if sessions are configured. Users added after enabling
anonymity are part of UNKNOWN group.

Summary
In this chapter, you learned about the HP Network Visualizer SDN Application. This is one of the
commercial, enterprise SDN applications available from HP. The application leverages an OpenFlowenabled network to enhance network features and functionality.
Network Visualizer provides visibility into the network and offers a flexible solution to obtain a copy of
network packets for auditing, verification, and dynamic troubleshooting purposes. You can get the copy of
network packets from multiple source devices and forward the captured packets to monitoring devices in
a different location.
In this chapter you learned how to install, license, and configure HP Network Visualizer. You also learned
how to implement and use various features including:
Capture Session wizard
Monitor and analyze network traffic
Network visibility
Event logs

Learning check
To prepare for the exam, answer each of the questions below.
1. Which capture modes are available in the HP Network Visualizer SDN Application? (Select 2)
a. Local
b. Custom
c. Remote
d. User
2. Which capture destinations are supported in the HP Network Visualizer SDN Application? (Select 2)
a. Managed destination
b. Local
c. Unmanaged destination
d. Flood
3. How many packets can be viewed via the HP Network Visualizer SDN Application GUI?
a. 10
b. 100
c. 1000

d. 10,000
4. Which protocol is used to encapsulate captured packets and forward them to a remote monitoring
station?
a. IPSec
b. IPIP
c. GRE
d. L2TP

Learning check answers


1. Answers: b, d
Explanation:
Create Capture Session wizardStep-by-step configuration wizard to create a new capture session. The
following modes of configuration are supported:
Custom: Configure the source/destination IP address, source/destination MAC address, port, and
protocol for a capture session.
User: Configure the user, user group, device(s), and application for a capture session.
2. Answer: a, c
Explanation:
A destination or pcap repository is the receiver for the copied traffic. It can be on a local or a remote
system. You can configure a destination as follows:
Managed destination: Runs as a daemon service that receives capture packets and stores them in
pcap format. A local managed destination is installed when you install Network Visualizer. You
must configure and deploy remote destinations from Network Visualizer.
Unmanaged destination: You can run a program or a solution to process the incoming copy traffic
from the network device.
3. Answer: b
Explanation:
You can view the most recent 100 packets in the pcap file for a session. To view all the packets and to
analyze the packets, open the pcap file in tshark.
4. Answer: c
Explanation:
GRE is a tunneling protocol that can encapsulate a wide variety of network layer protocols inside virtual
point-to-point links over an Internet Protocol network. GRE is used by the HP Network Visualizer SDN
Application to tunnel captured packets to a remote monitoring station.

Chapter 6
OpenFlow Deep Dive
EXAM OBJECTIVES
In this chapter you learn to:
Use Wireshark to interpret OpenFlow messages:
Hello
Feature request and reply
Broadcast Domain Discovery Protocol (BDDP)
Packet in
Packet out
Flow mod
Barrier request and reply
Flow removed
Error
Multipart request and response
Explain how OpenFlow versions are configured and negotiated.
View and explain Open vSwitch, Comware, and ProVision DPIDs.
Explain table-miss entries.
Explain OpenFlow pipeline processing.
Explain ProVision V1, V2, and V3 application specific integrated circuit (ASIC) OpenFlow pipelines
and capabilities.
Explain Comware OpenFlow pipelines.
Explain packet buffering.
Explain OpenFlow auxiliary connections.
Explain how Spanning Tree Protocol (STP) and OpenFlow interact.
Explain link aggregation and OpenFlow interaction.

Assumed knowledge
HP Comware and HP ProVision switch command line interface (CLI)

IP addressing
Basic routing protocols
Basic Internet protocols

Introduction
This chapter is a deep dive in the OpenFlow protocol. You will learn about OpenFlow negotiation,
communication channels, switch architecture, and a whole lot more. You are diving deep here and looking
at this from a networking engineers point of view using Wireshark to capture messages.

Open Networking Foundation


The Open Networking Foundation (ONF) is a nonprofit, userdriven organization dedicated to
accelerating the adoption of open softwaredefined networking (SDN). The ONF views SDN as a
disruptive approach to networking that will change how virtually every company with a network
operates. Figure 6-1 illustrates resources that ONF makes available.

Figure 6-1: ONF resources


The ONF was launched in 2011 by Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and
Yahoo!
The ONF is also in charge of the OpenFlow specification and details of various versions of OpenFlow
can be found on its website.
Note
ONF Technical Library: https://www.opennetworking.org/sdn-resources/technical-library

At the time of this writing, the ONF board of directors included the following companies and
organizations:
Facebook
Deutsche Telecom AG
Yahoo!
Microsoft
Google
Verizon
Stanford University
Princeton University
Goldman Sachs
Note
No traditional networking vendors are on the board of directors. Customers are driving the
innovation at the ONF.
HP and many other vendors are members of the ONF.
Note
Member listing: https://www.opennetworking.org/our-members
The following overview of the ONF is available on the organizations website:
SDN is a new approach to networking in which network control is decoupled from the data forwarding
function and is directly programmable. The result is an extremely dynamic, manageable, cost-effective,
and adaptable architecture that gives administrators unprecedented programmability, automation, and
control. Implementing SDN via an open standard enables extraordinary agility while reducing service
development and operational costs, and frees network administrators to integrate best-of-breed
technology as it is developed.
The ONF emphasizes an open, collaborative development process that is driven from the end-user
perspective. Our signature accomplishment to date is introducing the OpenFlow Standard, which
enables remote programming of the forwarding plane. The OpenFlow Standard is the first SDN standard
and a vital element of an open SDN architecture.
Today, our Technical Communities continue to analyze SDN requirements, evolve the OpenFlow
Standard to address the needs of commercial deployments, and research new standards to expand SDN
benefits.

Main components of an OpenFlow switch

Switch architecture
As Figure 6-2 illustrates, an OpenFlow switch consists of one or more flow tables and a group table,
which perform packet lookups and forwarding. OpenFlow switches also consist of an OpenFlow channel
to an external controller. The switch communicates with the controller, and the controller manages the
switch via the OpenFlow protocol.

Figure 6-2: Main components of OpenFlow switches

Note
This chapter contains multiple extracts from the OpenFlow specification document.
It is well worth reading for detailed technical information. Or, as is often said in jest in networking
circles, it may help you along with Request for Comments (RFCs) to sleep at night.

OpenFlow versions
At the time of this writing, the latest version of OpenFlow supported by the HP Virtual Area Network
(VAN) SDN Controller and HP switches is 1.3.2. This is, therefore, the version of OpenFlow discussed
in this study guide.
Note
OpenFlow Switch Specification, Version 1.3.2 is available at: http://bit.ly/1Lze7FV.

OpenFlow protocol

Using the OpenFlow protocol, the controller can add, update, and delete flow entries in flow tables, both
reactively (in response to packets) and proactively. Each flow table in the switch contains a set of flow
entries; each flow entry consists of match fields, counters, and a set of instructions to apply to matching
packets.
Matching starts at the first flow table and may continue to additional flow tables. Flow entries match
packets in priority order, with the first matching entry in each table being used. If a matching entry is
found, the instructions associated with the specific flow entry are executed. If no match is found in a flow
table, the outcome depends on configuration of the table-miss flow entry: for example, the packet may be
forwarded to the controller over the OpenFlow channel, be dropped, or continue to the next flow table.

OpenFlow channel
The OpenFlow channel is the interface that connects each OpenFlow switch to a controller. Through this
interface, the controller configures and manages the switch, receives events from the switch, and sends
packets out of the switch. Figure 6-3 illustrates the interactions between the switches and the controller.

Figure 6-3: OpenFlow channel


Between the datapath and the OpenFlow channel, the interface is implementation-specific; however, all
OpenFlow channel messages must be formatted according to the OpenFlow protocol. The OpenFlow
channel is usually encrypted using Transport Layer Security (TLS), but may be run directly over
Transport Control Protocol (TCP).
The TLS connection is initiated by the switch on startup to the controller, which is located by default on
TCP port 6633. The switch and controller mutually authenticate by exchanging certificates signed by a
site-specific private key.
Each switch must be user configurable with two certificates: one certificate for authenticating the

controller (the controller certificate) and the other for authenticating to the controller (the switch
certificate).
The switch and controller may optionally communicate using plain TCP. The TCP connection is initiated
by the switch on startup to the controller, which is located by default on TCP port 6633. When using plain
TCP, it is recommended that you use alternative security measures to prevent eavesdropping, controller
impersonation, or other attacks on the OpenFlow channel.
The Internet Assigned Numbers Authority (IANA) has now allocated TCP port 6653 to the ONF to be
used by the OpenFlow switch protocol. The port number changed with OpenFlow version 1.4.0 (15
October 2013). Refer to B.14.17 of the 1.4.0 specification.
The ONF has also updated other versions of OpenFlow, such as OpenFlow 1.3.3 (18 December 2013)
and OpenFlow 1.0.2 (Errata1 November 2013), with the new IANA assigned port number.
Currently, the HP VAN SDN Controller uses port 6633. This may change in the future to use the IANA
specified port number.

OpenFlow Ports
Overview
OpenFlow ports are the network interfaces for passing packets between switch OpenFlow processing and
the rest of the network. OpenFlow switches connect logically to each other via their OpenFlow ports.
An OpenFlow switch makes a number of OpenFlow ports available for OpenFlow processing. The set of
OpenFlow ports may not be identical to the set of network interfaces provided by the switch hardware as
some network interfaces may be disabled for OpenFlow, and the OpenFlow switch may define additional
OpenFlow ports. Figure 6-4 illustrates the types of OpenFlow ports.

Figure 6-4: OpenFlow ports


OpenFlow packets are received on an ingress port and processed by the OpenFlow pipeline, which may
forward them to an output port. The packet ingress port is a property of the packet throughout the
OpenFlow pipeline and represents the OpenFlow port on which the packet was received into the
OpenFlow switch.
The ingress port can be used when matching packets. The OpenFlow pipeline can decide to send the

packet on an output port using the output action, which defines how the packet goes back to the network.

Port types
An OpenFlow switch must support three types of OpenFlow ports: physical ports, logical ports, and
reserved ports.
Physical ports: The OpenFlow physical ports are switch-defined ports that correspond to a hardware
interface of the switch. For example, on an Ethernet switch, physical ports map one-to-one to the Ethernet
interfaces. In some deployments, the OpenFlow switch may be virtualized over the switch hardware. In
these cases, an OpenFlow physical port may represent a virtual slice of the corresponding hardware
interface of the switch.
Logical ports: The OpenFlow logical ports are switch defined ports that do not correspond directly to a
hardware interface of the switch. Logical ports are higher-level abstractions that may be defined in the
switch using non-OpenFlow methods (link aggregation groups, tunnels, and loopback interfaces, for
example).
Reserved ports: The OpenFlow reserved ports are defined by the OpenFlow specification. They specify
generic forwarding actions such as sending to the controller, flooding, or forwarding using nonOpenFlow methods, such as normal switch processing.

Reserved ports
A switch is not required to support all reserved ports, but it must support ports marked Required in the
specification. Following is a list of required and optional ports:
Required: ALLrepresents all ports the switch can use for forwarding a specific packet. Can be used
only as an output port. In this case, a copy of the packet is sent to all standard ports, excluding the
packet ingress port and ports that are configured OFPPC_NO_FWD. The OFPPC_NO_FWD bit
indicates that OpenFlow should not send packets to that port.
Required: CONTROLLERrepresents the control channel with the OpenFlow controller. Can be
used as an ingress port or as an output port. When used as an output port, CONTROLLER
encapsulates the packet in a packet-in message and sends it using the OpenFlow protocol. When used
as an ingress port, CONTROLLER identifies a packet originating from the controller.
Required: TABLErepresents the start of the OpenFlow pipeline. This port is only valid in an output
action in the action list of a packet-out message. It submits the packet to the first flow table so that the
packet can be processed through the regular OpenFlow pipeline.
Required: IN PORTrepresents the packet ingress port. It can be used only as an output port and
sends the packet out through its ingress port.
Required: ANYis a special value used in some OpenFlow commands when no port is specified
(that is, the port is wildcarded). It can neither be used as an ingress port nor as an output port.
Optional: LOCALrepresents the switchs local networking stack and its management stack.
Optional: NORMALrepresents the traditional non-OpenFlow pipeline of the switch. It can be used
only as an output port and processes packets using the normal pipeline. If the switch cannot forward
packets from the OpenFlow pipeline to the normal pipeline, it must indicate that it does not support
this action.

Optional: FLOODrepresents flooding using the normal pipeline of the switch. It can be used only as
an output port. In general, this port will send packets out on all standard ports. But it will not send
packets out to the ingress port or to ports that are in OFPPS_BLOCKED state. The
OFPPS_BLOCKED bit indicates that a switch protocol outside of OpenFlow, such as 802.1D STP, is
preventing the use of the port with OFPP_FLOOD. The switch may also use the packet VLAN ID to
select which ports to flood.

OpenFlow messages
The OpenFlow protocol supports the following three message types (each with multiple subtypes, as
Figure 6-5 illustrates):
Controller-to-switch
Asynchronous
Symmetric

Figure 6-5: OpenFlow messages


Controller-to-switch messages are initiated by the controller and used to directly manage or inspect the
state of the switch. These messages may or may not require a response from the switch.
Asynchronous messages are sent without solicitation from the controller. Switches send asynchronous
messages to controllers to denote a packet arrival, switch state change, or an error.
Symmetric messages are initiated by either the switch or the controller and are sent without solicitation.

Symmetric OpenFlow messages


Symmetric messages are sent without solicitation in either direction and include the following messages
(see Figure 6-6):
Hello: Hello messages are exchanged between the switch and controller upon connection startup.
Echo: Echo request/reply messages can be sent from either the switch or the controller and must return
an echo reply. They are mainly used to verify the liveness of a controller-switch connection, and they
may as well be used to measure the connections latency or bandwidth.
Experimenter: Experimenter messages provide a standard way for OpenFlow switches to offer

additional functionality within the OpenFlow message type space. This is a staging area for features
meant for future OpenFlow revisions.

Figure 6-6: Symmetric OpenFlow messages

Capture OpenFlow messages


In this section, you will learn to use Wireshark to capture OpenFlow messages sent between the HP VAN
SDN Controller and OpenFlow switches.
You will learn to capture initial OpenFlow messages and compare the actual OpenFlow implementation
in a network with information contained in the OpenFlow specification document. Figure 6-7 illustrates
the IP addresses and configuration these instructions use.
Comware switch C2 and ProVision switch P1 are configured to communicate with HP VAN SDN
Controller 192.168.56.11. You will learn to capture OpenFlow messages using Wireshark on the
Jumphost (192.168.56.5).

Figure 6-7: Topology for instructions


See Table 6-1 for additional IP addresses used in instructions for this section.
Table 6-1: IP addresses used for instructions
Device

Description

IP Address

C1 (Comware switch 1) HP Comware switch VLAN 1: 10.1.1.251


VLAN 20: 10.20.20.251
VLAN 30: 10.30.30.251
VLAN 40: 10.40.40.251
VLAN 192: 192.168.56.251
If you have installed evaluation copies of HP VAN SDN Controller, Mininet, and Network Protector on
your PC so that you could follow instructions in the previous chapters, you will need to disable Network
Protector for the following instruction set. Following are instructions for doing this.
1. Disable Network Protector on the HP VAN SDN Controller. Browse to https://<controller IP
address>/sdn/ui and click Applications. If Network Protector is active, select the application and
click Disable to disable it (see Figure 6-8).

Figure 6-8: Disable Network Protector


Figure 6-9 illustrates the relationship between the controller and an OpenFlow switch.

Figure 6-9: OpenFlow switch


As quoted earlier in this chapter: An OpenFlow Switch consists of one or more flow tables and a group
table, which perform packet lookups and forwarding, and an OpenFlow channel to an external controller.
The switch communicates with the controller and the controller manages the switch via the OpenFlow
protocol.
Following is the source of this quotation:
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1, OpenFlow Protocol
Overview, page 25. Available at: http://bit.ly/1Lze7FV
Earlier in this chapter, you also learned that the OpenFlow protocol supports three message types. Which
three message types does the OpenFlow protocol support?
Answer : The OpenFlow protocol supports three message types: controller-to-switch, asynchronous, and

symmetric. Each of the following three types has multiple subtypes.


Controller-to-switch messages are initiated by the controller and used to directly manage or inspect
the state of the switch.
Asynchronous messages are initiated by the switch and used to update the controller of network events
and changes to the switch state.
Symmetric messages are initiated by either the switch or the controller and sent without solicitation.
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1, OpenFlow Protocol
Overview, page 25. Available at: http://bit.ly/1Lze7FV
OpenFlow will be disabled and then re-enabled so you can view the OpenFlow channel negotiation
between the switch and the HP VAN SDN Controller. An OpenFlow channel is the TCP or TLS session
between the switch and the controller used for sending and receiving OpenFlow messages.
Initial OpenFlow messages we will capture and view in Wireshark include:
Switch to Controller = Hello
Controller to Switch = Hello
Controller to Switch = Features request
Switch to Controller = Features reply
Controller to Switch = Set config
Switch to Controller = Error
2. Disable OpenFlow on Comware 2 (C2):
<C2> system-view
[C2] openflow instance 1
[C2-of-inst-1] undo classification
[C2-of-inst-1] active instance

Note
In later releases of the Comware operating system, the command undo active instance is
supported.
3. Disable OpenFlow on ProVision 1 (P1):
P1# config
P1(config)# openflow
P1(openflow)# disable

4. Disable OpenFlow on ProVision 2 (P2):


P2# config
P2(config)# openflow
P2(openflow)# disable

5. These instructions will use Wireshark extensively to capture messages sent between the switches
and the HP VAN SDN Controller. We started Wireshark on the Windows Jumphost, as illustrated
in Figure 6-10.

Figure 6-10: Screen capture of Wireshark Network Analyzer interface

Note
The VMware ESXi server has promiscuous mode enabled on the VMware vSwitch. Your Windows
virtual machine (Jumphost) is thus able to capture OpenFlow messages destined for the HP VAN
SDN Controller.
6. Click Capture and then Interfaces, as illustrated in Figure 6-11.

Figure 6-11: Wireshark interfaces


7. Select Lab Network and click Options, as illustrated in Figure 6-12.

Figure 6-12: Wireshark capture interfaces


8. Ensure that Use promiscuous mode on all interfaces is enabled and click Start (see Figure 6-13).

Figure 6-13: Wireshark capture options

Note
If prompted, don't save any captures. Click Continue without Saving.

9. Specify the following filter: openflow_v4 and click Apply. See Figure 6-14. This filter will display
OpenFlow 1.3 packets:

Figure 6-14: Wireshark OpenFlow filter


Result: At the moment no OpenFlow packets are seen because OpenFlow is disabled on the switches.
10. Enable OpenFlow on Comware 2 (C2):
[C2-of-inst-1] classification vlan 20
[C2-of-inst-1] active instance

11. Stop the Wireshark capture (see Figure 6-15).

Figure 6-15: Stop capture


12. Find the OFPT_HELLO message (first OpenFlow message) (check Figure 6-16). Which version of
OpenFlow is the hello message?

Figure 6-16: OpenFlow Hello message


Answer : The version of OpenFlow is 1.3 (0x04).

OpenFlow specification
The version specifies the OpenFlow protocol version being used. During the earlier draft phase of the
OpenFlow Protocol, the most significant bit was set to indicate an experimental version. The lower bits
indicate the revision number of the protocol. The version of the protocol described by the current
specification is 1.3.2, and its ofp version is (0x04).
Note
Source: OpenFlow Switch Specification, Version 1.3.2, 7.1, OpenFlow Header, page 40. Available
at: http://bit.ly/1Lze7FV
13. This first OpenFlow message is a Hello message. Is this a controller-to-switch, asynchronous, or
symmetric message type? Check Figure 6-17.

Figure 6-17: Switch Hello message


Answer: This message is a Hello message with code = 0. There are other OpenFlow messages listed
below and which we will discuss.
This is a symmetric message. Symmetric messages are initiated by either the switch or the controller and
sent without solicitation.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1, OpenFlow Protocol
Overview, page 25. Available at: http://bit.ly/1Lze7FV

Optional reading
The following extract from the OpenFlow specification provides more detail of message types:
The length field indicates the total length of the message, so no additional framing is used to distinguish
one frame from the next. The type can have the following values:
enum ofp_type {
/* Immutable messages. */
OFPT_HELLO = 0, /* Symmetric message */
OFPT_ERROR = 1, /* Symmetric message */
OFPT_ECHO_REQUEST = 2, /* Symmetric message */
OFPT_ECHO_REPLY = 3, /* Symmetric message */
OFPT_EXPERIMENTER = 4, /* Symmetric message */
/* Switch configuration messages. */
OFPT_FEATURES_REQUEST = 5, /* Controller/switch message */

OFPT_FEATURES_REPLY = 6, /* Controller/switch message */


OFPT_GET_CONFIG_REQUEST = 7, /* Controller/switch message */
OFPT_GET_CONFIG_REPLY = 8, /* Controller/switch message */
OFPT_SET_CONFIG = 9, /* Controller/switch message */
/* Asynchronous messages. */
OFPT_PACKET_IN = 10, /* Async message */
OFPT_FLOW_REMOVED = 11, /* Async message */
OFPT_PORT_STATUS = 12, /* Async message */
/* Controller command messages. */
OFPT_PACKET_OUT = 13, /* Controller/switch message */
OFPT_FLOW_MOD = 14, /* Controller/switch message */
OFPT_GROUP_MOD = 15, /* Controller/switch message */
OFPT_PORT_MOD = 16, /* Controller/switch message */
OFPT_TABLE_MOD = 17, /* Controller/switch message */
/* Multipart messages. */
OFPT_MULTIPART_REQUEST = 18, /* Controller/switch message */
OFPT_MULTIPART_REPLY = 19, /* Controller/switch message */
/* Barrier messages. */
OFPT_BARRIER_REQUEST = 20, /* Controller/switch message */
OFPT_BARRIER_REPLY = 21, /* Controller/switch message */
/* Queue Configuration messages. */
OFPT_QUEUE_GET_CONFIG_REQUEST = 22, /* Controller/switch message */
OFPT_QUEUE_GET_CONFIG_REPLY = 23, /* Controller/switch message */
/* Controller role change request messages. */
OFPT_ROLE_REQUEST = 24, /* Controller/switch message */
OFPT_ROLE_REPLY = 25, /* Controller/switch message */
/* Asynchronous message configuration. */
OFPT_GET_ASYNC_REQUEST = 26, /* Controller/switch message */
OFPT_GET_ASYNC_REPLY = 27, /* Controller/switch message */
OFPT_SET_ASYNC = 28, /* Controller/switch message */
/* Meters and rate limiters configuration messages. */
OFPT_METER_MOD = 29, /* Controller/switch message */
};

Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.1, OpenFlow Header, page 40.
Available at: http://bit.ly/1Lze7FV
14. Which device initiated the connection? Check Figure 6-18.

Figure 6-18: Switch Hello message


Answer: The Comware switch C2 (10.1.1.252) sent this message. In other words, the switch initiated
the connection to the controller.
15. Can a routed, non-OpenFlow, transit network be used for the OpenFlow channel between the switch
and the controller?
Answer: A non-OpenFlow, routed network can be used as the transit network for the OpenFlow
Channel between the switch and the controller. Comware switch C1 is not running OpenFlow and is
routing traffic from VLAN 1 to VLAN 192.
16. Optional: Watch the following video explaining how HP configured a network for Interop. In this
example the HP VAN SDN Controller was on one coast of the USA and the OpenFlow switches were
on the other coast of the USA:
Note
HP Networking InteropNet Architecture : https://vimeo.com/108016389

OpenFlow specification
An OpenFlow controller typically manages an OpenFlow switch remotely over one or more networks.
The specification of the networks used for the OpenFlow channels is outside the scope of the present

specification. It may be a separate dedicated network, or the OpenFlow channel may use the network
managed by the OpenFlow switch (in-band controller connection). The only requirement is that it should
provide TCP/IP connectivity.
The OpenFlow channel is usually instantiated as a single network connection between the switch and the
controller, using TLS or plain TCP. Alternatively, the OpenFlow channel may be composed of multiple
network connections to exploit parallelism. The OpenFlow switch must be able to create an OpenFlow
channel by initiating a connection to an OpenFlow controller. Some switch implementations may
optionally allow an OpenFlow controller to connect to the OpenFlow switch, in this case the switch
usually should restrict itself to secured connections to prevent unauthorized connections.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.3, OpenFlow Channel
Connections, page 28. Available at: http://bit.ly/1Lze7FV
We will discuss auxiliary connections and teaming later.
17. Which Layer 4 protocol is used? Check Figure 6-19.

Figure 6-19: Switch Hello message


Answer: TCP was used for this connection.
18. How did the switch learn the HP VAN SDN Controller IP address?
Answer: The switch was manually configured with the IP address of the controller with the following
command: controller 1 address ip 192.168.56.11. OpenFlow controllers are not automatically or
dynamically discovered by switches.

OpenFlow specification
The switch must be able to establish communication with a controller at a user-configurable (but
otherwise fixed) IP address, using either a user-specified transport port or the default transport port. If the
switch is configured with the IP address of the controller to connect to, the switch initiates a standard
TLS or TCP connection to the controller. Traffic to and from the OpenFlow channel is not run through the
OpenFlow pipeline. Therefore, the switch must identify incoming traffic as local before checking it
against the flow tables.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.3.1, Connection Setup, page 29.
Available at: http://bit.ly/1Lze7FV
19. View the Hello message sent by the controller to the switch (next message) (see Figure 6-20).

Figure 6-20: Controller Hello message


Result: This Hello message also has a version of 1.3.
20. When a switch supports OpenFlow 1.0 and 1.3, what is the version field set to when communicating
with the controller (see Figure 6-21)?

Figure 6-21: Switch informs the controller of its highest supported version
Answer: The switch will inform the controller of its highest supported version (1.3 in this example).
21. How is the version of OpenFlow used between the switch and the controller determined?
Answers: The switch and controller negotiate to use the highest supported version of OpenFlow.
22. What does the OFNET_VERSIONBITMAP determine? (see Figure 6-22).

Figure 6-22: Controller Hello message


Answer: The OFNET_VERSIONBITMAP determines if the highest number or lowest number is used.

OpenFlow specification
When an OpenFlow connection is first established, each side of the connection must immediately send an
OFPT_HELLO message with the version field set to the highest OpenFlow protocol version supported by

the sender. This Hello message may optionally include some OpenFlow elements to help connection
setup.
Upon receipt of this message, the recipient must calculate the OpenFlow protocol version to be used. If
both the Hello message sent and the Hello message received contained a OFPHET_VERSIONBITMAP
hello element, and if those bitmaps have some common bits set, the negotiated version must be the highest
version set in both bitmaps. Otherwise, the negotiated version must be the smaller of the version number
that was sent and the one that was received in the version fields.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.3.1, Connection Setup, page 29.
Available at: http://bit.ly/1Lze7FV
23. Optional reading (skip this step if you prefer):
a. Review the details of the OpenFlow Hello message (see Figure 6-23).

Figure 6-23: Controller Hello message


You may find it beneficial to understand how the OpenFlow version bitmap is calculated. A brief
summary is shown here and then details for the OpenFlow specification are shown.
Each OpenFlow version has an internal version number as follows:
OpenFlow version 1.0 is represented as 1
OpenFlow version 1.1 is represented as 2
OpenFlow version 1.2 is represented as 3
OpenFlow version 1.3 is represented as 4
This is what you see in some of the Wireshark captures.
The version bitmap OFPHET_VERSIONBITMAP is created by adding the representation for all

supported versions (see Table 6-2).


Table 6-2: OFPHET_VERSIONBITMAP values

Note
Bit 0 is always zero, and this may look counterintuitive, but that is how OpenFlow is designed.
If a device supports both OpenFlow 1.0 (that is, if the second bit, or bit 1 is set) and OpenFlow 1.3
(that is, if the fifth bit, or bit 4 is set), then you need to add the following values (see Table 6-3):
Table 6-3: Additional OFPHET_VERSIONBITMAP values

Result: In the Wireshark capture you see a bitmap of 00000012 (hexadecimal).

Figure 6-24: Controller Hello message


The OFPT_HELLO message consists of an OpenFlow header plus a set of variable sized Hello elements.
/* OFPT_HELLO. This message includes zero or more hello elements having variable size.
Unknown elements types must be ignored/skipped to allow for future extensions. */
struct ofp_hello {
struct ofp_header header;
/* Hello element list */
struct ofp_hello_elem_header elements[0]; /* List of elements - 0 or more */
};
OFP_ASSERT(sizeof(struct ofp_hello) == 8);

The version field part of the header field must be set to the highest OpenFlow protocol version supported
by the sender.
The elements field is a set of Hello elements, containing optional data to inform the initial handshake of
the connection. Implementations must ignore (skip) all elements of a Hello message that they do not
support. The list of hello elements types that are currently defined are:
/* Hello elements types.
*/
enum ofp_hello_elem_type {
OFPHET_VERSIONBITMAP = 1, /* Bitmap of version supported.*/
};

An element definition contains the element type, length, and any associated data as illustrated by the
following output:
/* Common header for all Hello Elements */

struct ofp_hello_elem_header {
uint16_t type; /* One of OFPHET_*. */
uint16_t length; /* Length in bytes of this element. */
};
OFP_ASSERT(sizeof(struct ofp_hello_elem_header) == 4);

The OFPHET_VERSIONBITMAP element uses the following structure and fields:


/* Version bitmap Hello Element */
struct ofp_hello_elem_versionbitmap {
uint16_t type; /* OFPHET_VERSIONBITMAP. */
uint16_t length; /* Length in bytes of this element. */
/* Followed by:
* - Exactly (length - 4) bytes containing the bitmaps, then
*- Exactly (length + 7)/8*8 - (length) (between 0 and 7)
bytes of all-zero bytes * * *
uint32_t bitmaps[0]; /* List of bitmaps - supported versions */
};
OFP_ASSERT(sizeof(struct ofp_hello_elem_versionbitmap) == 4);

The bitmaps field indicates the set of versions of the OpenFlow switch protocol a device supports, and it
may be used during version negotiations. The bits of the set of bitmaps are indexed by the ofp version
number of the protocol; if the bit identified by the number of left bit shift is equal to a ofp, a version
number is set, and this OpenFlow version is supported. The number of bitmaps included in the field
depends on the highest version number supported: ofp versions 0 to 31 are encoded in the first bitmap,
ofp versions 32 to 63 are encoded in the second bitmap, and so on. For example, if a switch supports only
version 1.0 (ofp version=0x01) and version 1.3 (ofp version = 0x04), the first bitmap would be set to 0 x
00000012.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.5.1, Hello, page 103. Available
at: http://bit.ly/1Lze7FV
b. What is the default version of OpenFlow used by HP ProVision and Comware switches?
Answers:
ProVision: OpenFlow 1.0
Comware: OpenFlow 1.3
c. What determines the version of OpenFlow negotiated by ProVision switches?
Answer: ProVision switches use OpenFlow 1.0 by default but can be configured to use either 1.0 or 1.3,

or 1.3 only:
openflow
controller-id 1 ip 192.168.56.11 controller-interface vlan 1
controller-id 2 ip 192.168.56.12 controller-interface vlan 1
controller-id 3 ip 192.168.56.13 controller-interface vlan 1
instance "vlan30"
member vlan 30
controller-id 3
version 1.3
enable
exit
enable
exit

On a per OpenFlow instance basis, the version command determines the version used by the switch. Use
the version ? command to view options:
P1(of-inst-vlan30)# version ?
1.0 OpenFlow version 1.0.
1.3 OpenFlow version 1.3.

Note
You would not see the ? character displayed on a switch. It is shown here for completeness.
P1(of-inst-vlan30)# version 1.3 ?
onlyAdvertises the specified version only.
<cr>

Setting OpenFlow protocol version Syntax


P1(of-inst-vlan30)# version 1.0|1.3 only

This is the OpenFlow protocol version supported by the instance.


This command lets you choose which version of OpenFlow the instance will use to negotiate with the
controller. The command also allows for supported earlier versions of OpenFlow to be used in
negotiations with the controller unless the option only is specified.
Default: version 1.0

Note
Source: HP Switch Software OpenFlow v1.3 Administrator Guide K/KA/WB 15.17, page 17.
Available at: http://bit.ly/1GV7TJ9
d. Can Open vSwitch be configured to negotiate version 1.0 or 1.3 of OpenFlow?
Answer: Yes, by default Open vSwitch (OVS) will use OpenFlow 1.0. The following command
configures OVS to negotiate to use either OpenFlow 1.0 or 1.3:
sudo ovs-vsctl set bridge ovsbr0 \ protocols=OpenFlow10,OpenFlow13

e. Can you configure the version of OpenFlow that Comware uses?


Answer: No, currently only OpenFlow 1.3 is supported.
f. What happens if the switch and controller cannot negotiate to use a specific version?
Answer: If the negotiated version is supported by the recipient, then the connection proceeds.
Otherwise, the recipient must reply with an OFPT_ERROR message with a type field of
OFPET_HELLO_FAILED, a code field of OFPHFC_INCOMPATIBLE, and optionally an ASCII
string explaining the situation in data. The recipient must then terminate the connection.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.3.1, Connection Setup, page 29.
Available at: http://bit.ly/1Lze7FV
24. Optional: You can configure Mininet to use OpenFlow 1.2, which will result in Mininet failing to
negotiate with the HP VAN SDN Controller. The HP VAN SDN Controller expects either OpenFlow
1.0 or OpenFlow 1.3.
The following command configures Mininet to use OpenFlow 1.2:
sudo mn --controller=remote,ip=192.168.56.11 --topo=linear,4 -switch=ovsk,protocols=OpenFlow12 --mac

The HP VAN SDN Controller OpenFlow Trace tool or Wireshark could be used to view the negotiation
failure (see Figure 6-25).

Figure 6-25: OpenFlow Trace


25. Click on the magnifying glass icon to view details of the negotiation.

Figure 6-26: Message details


Result: The HP VAN SDN Controller and Mininet cannot negotiate a compatible version (see Figure 626) and the following error is displayed:
{ofm:[V_1_2,ERROR,48,83445],HELLO_FAILED/INCOMPATIBLE, 'Controller supports 1.0 and 1.3
only'}

26. What happens after the switch and the controller have negotiated a version of OpenFlow to use? Check
Figure 6-27.
Select the Features Request message in the Wireshark capture:

Figure 6-27: Controller Features Request


Answer: The Controller will send the switch a Features Request message after the Hello message is
received from the switch and a reply is sent.
This is a controller to switch message
After the switch and the controller have exchanged OFPT_HELLO messages and successfully negotiated
a common version number, the connection setup is done and standard OpenFlow messages can be
exchanged over the connection. One of the first things that the controller should do is to send a
OFPT_FEATURES_REQUEST message to get the datapath ID of the switch.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.3.1, Connection Setup, page 29.
Available at: http://bit.ly/1Lze7FV
OpenFlow specification
7.3 Controller-to-Switch Messages
7.3.1 Handshake
The OFPT_FEATURES_REQUEST message is used by the controller to identify the switch and read its
basic capabilities. Upon session establishment, the controller should send an
OFPT_FEATURES_REQUEST message. This message does not contain a body beyond the OpenFlow
header.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.1, Handshake, page 62.
Available at: http://bit.ly/1Lze7FV

Questions
Question 1: What are the three types of OpenFlow messages?
_________________________________________________________________
Question 2: A switch is configured to use either OpenFlow 1.0 or OpenFlow 1.3. Which version of
OpenFlow will be negotiated with version 2.5 of the HP VAN SDN Controller?
_________________________________________________________________
Question 3: Does OpenFlow support encrypted sessions between a switch and a controller? How would
this be implemented?
_________________________________________________________________
Question 4: Are controllers dynamically discovered?
_________________________________________________________________
Question 5: Which version of OpenFlow does a ProVision switch use by default?
_________________________________________________________________
Question 1 answer
The OpenFlow protocol supports three message types: controller-to-switch, asynchronous, and
symmetric. Each type has multiple subtypes.
Controller-to-switch messages are initiated by the controller and used to directly manage or inspect
the state of the switch.
Asynchronous messages are initiated by the switch and used to update the controller with network
events and changes to the switch state.
Symmetric messages are initiated by either the switch or the controller and sent without solicitation.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1, OpenFlow Protocol
Overview, page 25, Available at: http://bit.ly/1Lze7FV
Question 2 answer
The switch and controller negotiate to use the highest supported version of OpenFlow. In this case
OpenFlow 1.3.
Question 3 answer
Yes, encrypted sessions are supported.
The switch and controller may communicate through a TLS connection. The TLS connection is initiated
by the switch on startup to the controller. By default, the connection is located on TCP port 6633. The
switch and controller mutually authenticate by exchanging certificates signed by a site-specific private
key.
Each switch must be user-configurable with one certificate for authenticating the controller (controller

certificate) and the other for authenticating to the controller (switch certificate).
The switch and controller may optionally communicate using plain TCP. The TCP connection is initiated
by the switch on startup to the controller. The connection is located by default on TCP port 6633. When
using plain TCP, it is recommended to use alternative security measures to prevent eavesdropping,
controller impersonation, or other attacks on the OpenFlow channel.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.3.3, Encryption, page 30.
Available at: http://bit.ly/1Lze7FV
Question 4 answer
OpenFlow controllers are not automatically or dynamically discovered by switches.
OpenFlow specification
The switch must be able to establish communication with a controller at a user-configurable (but
otherwise fixed) IP address, using either a user-specified transport port or the default transport port. If the
switch is configured with the IP address of the controller to connect to, the switch initiates a standard
TLS or TCP connection to the controller. Traffic to and from the OpenFlow channel is not run through the
OpenFlow pipeline. Therefore, the switch must identify incoming traffic as local before checking it
against the flow tables.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.3.1, Connection Setup, page 29.
Available at: http://bit.ly/1Lze7FV
Question 5 answer: ProVision switches use OpenFlow 1.0 by default, but can be configured to use either
1.0 or 1.3, or 1.3 only:
openflow
controller-id 1 ip 192.168.56.11 controller-interface vlan 1
controller-id 2 ip 192.168.56.12 controller-interface vlan 1
controller-id 3 ip 192.168.56.13 controller-interface vlan 1
instance "vlan30"
member vlan 30
controller-id 3
version 1.3
enable
exit
enable

exit

OpenFlow channel
The Initial OpenFlow messages we will capture in the instructions and then view in Wireshark include
the following:
Switch to controller = Hello
Controller to switch = Hello
Controller to switch = Features request
Switch to controller = Features reply
Controller to switch = Set config
Switch to controller = Error
Figure 6-28 illustrates the flow channels through which these messages pass.

Figure 6-28: OpenFlow channel

OpenFlow messagescontroller to switch


Controller to switch messages are initiated by the controller and may or may not require a response from
the switch. As illustrated in Figure 6-29, messages include the following:
Features: The controller may request the identity and the basic capabilities of a switch by sending a
features request. The switch must respond with a features reply that specifies the identity and basic
capabilities of the switch. This is commonly performed upon establishment of the OpenFlow channel.

Configuration: The controller is able to set and query configuration parameters in the switch. The
switch only responds to a query from the controller.
Modify-State: Modify-State messages are sent by the controller to manage state on the switches. Their
primary purpose is to add, delete, and modify flow/group entries in the OpenFlow tables and to set
switch port properties.
Read-State: Read-State messages are used by the controller to collect various information from the
switch, such as current configuration, statistics, and capabilities.
Packet-out: These messages are used by the controller to send packets out of a specified port on the
switch and to forward packets received via Packet-in messages. Packet-out messages must contain a
full packet or a buffer ID referencing a packet stored in the switch. The message must also contain a
list of actions to be applied in the order they are specified. An empty action list drops the packet.

Figure 6-29: OpenFlow messagescontroller to switch

Additional OpenFlow messagescontroller to switch


As Figure 6-30 illustrates, additional controller-to-switch messages include the following:
Barrier: Barrier request/reply messages are used by the controller to ensure message dependencies
have been met or to receive notifications for completed operations.
Role-Request: Role-Request messages are used by the controller to set the role of its OpenFlow
channel, or to query this role. This is mostly useful when the switch connects to multiple controllers.
Asynchronous-Configuration: Asynchronous-Configuration messages are used by the controller to set
an additional filter on the asynchronous messages that it wants to receive on its OpenFlow channel, or
to query this filter. This is mostly useful when the switch connects to multiple controllers and is
commonly performed upon establishment of the OpenFlow channel.

Figure 6-30: OpenFlow messagescontroller-to-switch

Messagesasynchronous
Asynchronous messages are sent without a controller soliciting them from a switch. Switches send
asynchronous messages to controllers to denote a packet arrival, switch state change, or error. Figure 631 illustrates the four main asynchronous message types. The following definitions are excerpted from the
OpenFlow specification:
Packet-in: Transfer the control of a packet to the controller. For all packets forwarded to the
CONTROLLER reserved port using a flow entry or the table-miss flow entry, a packet-in event is
always sent to controllers. Other processing, such as TTL checking, may also generate packet-in
events to send packets to the controller. Packet-in events can be configured to buffer packets. For
packet-in generated by an output action in flow entries or a group bucket, it can be specified
individually in the output action itself, for other packet-in it can be configured in the switch
configuration. If the packet-in event is configured to buffer packets and the switch has sufficient
memory to buffer them, the packet-in events contain only some fraction of the packet header and a
buffer ID to be used by a controller when it is ready for the switch to forward the packet.
Switches that do not support internal buffering are configured to not buffer packets for the packet-in event,
or have run out of internal buffering, must send the full packet to controllers as part of the event. Buffered
packets will usually be processed via a Packet-out message from a controller, or automatically expired
after some time. If the packet is buffered, the number of bytes of the original packet to include in the
packet-in can be configured. By default, it is 128 bytes. For packet-in generated by an output action in a
flow entries or a group bucket, it can be specified individually in the output action itself, for other packetin it can be configured in the switch configuration.
Flow-Removed: Inform the controller about the removal of a flow entry from a flow table. FlowRemoved messages are only sent for flow entries with the OFPFF_SEND_FLOW_REM flag set. They
are generated as the result of controller flow delete requests or the switch flow expiry process when
one of the flow timeouts is exceeded.
Port-status: Inform the controller of a change on a port. The switch is expected to send port-status
messages to controllers as port configuration or port state changes. These events include change in
port configuration events, for example, if it was brought down directly by a user, and port state change
events, for example, if the link went down.

Error: The switch is able to notify controllers of problems using error messages.

Figure 6-31: Messagesasynchronous

Multiple table pipeline processing


OpenFlow-compliant switches come in two types: OpenFlow-only and OpenFlow-hybrid. OpenFlowonly switches support only OpenFlow operation. In these switches, all packets are processed by the
OpenFlow pipeline and cannot be processed otherwise.
OpenFlow-hybrid switches support both OpenFlow operation and normal Ethernet switching operation
that is, traditional L2 Ethernet switching, VLAN isolation, L3 routing (IPv4 routing and IPv6 routing),
access control list (ACL), and quality of service (QoS) processing. These switches must provide a
classification mechanism outside of OpenFlow that routes traffic to either the OpenFlow pipeline or the
normal pipeline. For example, a switch may use the VLAN tag or input port of the packet to decide
whether to process the packet using one pipeline or the other, or it may direct all packets to the OpenFlow
pipeline. This classification mechanism is outside the scope of this specification.

Figure 6-32: Multiple table pipeline processing


An OpenFlow-hybrid switch may also allow a packet to go from the OpenFlow pipeline to the normal
pipeline through the NORMAL and FLOOD reserved ports.
The OpenFlow pipeline of every OpenFlow switch contains multiple flow tables (see Figure 6-32). Each
flow table contains multiple flow entries. OpenFlow pipeline processing defines how packets interact
with these flow tables. An OpenFlow switch is required to have at least one flow table and can
optionally have more flow tables. An OpenFlow switch with only a single flow table is valid. In this
case, pipeline processing is greatly simplified.
The flow tables of an OpenFlow switch are sequentially numbered, starting at 0. Pipeline processing
always starts at the first flow table: the packet is first matched against flow entries of flow Table 0. Other
flow tables may be used depending on the outcome of the match in the first table.

Pipeline processing for flow tables


When processed by a flow table, the packet is matched against the flow entries of the flow table to select
a flow entry. If a flow entry is found, the instruction set included in that flow entry is executed. These
instructions may explicitly direct the packet to another flow table (using the Goto instruction), where the
same process is repeated. (Figure 6-33 presents a pipeline processing flow chart.) A flow entry can only
direct a packet to a flow table number that is greater than its own flow table number, in other words
pipeline processing can only go forward and not backward. Obviously, the flow entries of the last table
of the pipeline cannot include the Goto instruction. If the matching flow entry does not direct packets to
another flow table, pipeline processing stops at this table. When pipeline processing stops, the packet is
processed with its associated action set and usually forwarded.
If a packet does not match a flow entry in a flow table, this is a table miss. The behavior on a table miss
depends on the table configuration. A table-miss flow entry in the flow table can specify how to process

unmatched packets: options include dropping them, passing them to another table, and sending them to the
controller over the control channel via packet-in messages.

Figure 6-33: Pipeline processing for flow tables


The OpenFlow pipeline and various OpenFlow operations process packets of a specific type in
conformance with the specifications defined for that packet type, unless the present specification or the
OpenFlow configuration specifies otherwise. For example, the Ethernet header definition used by
OpenFlow must conform to IEEE specifications, and the TCP/IP header definition used by OpenFlow
must conform to RFC specifications. Additionally, packet reordering in an OpenFlow switch must
conform to the requirements of IEEE specifications, provided that the packets are processed by the same
flow entries, group bucket, and meter band.

Multiple tables
OpenFlow 1.1 added a number of significant features to OpenFlow. Perhaps the most significant feature
is the definition of multiple tables. Remember that OpenFlow 1.0 had just one flow table. OpenFlow 1.1
allows for multiple tables, which can be chained together via any logic defined by the application.
One use of this feature is to have different tables serve different purposes. The tables are linked in a
series, as shown in Figure 6-34.
Packets arrive and are passed through the authentication table, which determines if the user (whose
identity is based on his MAC address) is allowed into the network. If users are allowed, then the
VLAN is appropriately set to policies that apply to them.
Packets are then passed through the next table, which determines what QoS to set for this user. The
matches could be based on the type of traffic, the incoming VLAN, the existing priority (class of
service (CoS) or type of service (ToS)), or whatever. Based on this, the priority gets set (or reset).

The last table could be used for setting the rate-limits. Prior to OpenFlow 1.3, per-flow meters were
not available. However, HP switches had these available so we use them in the example here, where
rate-limits are set for the user.

Figure 6-34: Multiple tables


Imagine setting all of these features using one table. You would need a huge number of flows because you
would need a specific entry for every single possible combination. You would end up with numerous
devices, such as X VLAN, X Protocol, X CoS, and so forth. This would fill up any flow table quite
quickly. Using multiple tables greatly reduces the number of flows required.
Consider most learning switch applications, which end up setting two flows for each sourcedestination
pair. The number of flows required for this type of application will be (number of devices) (number of
devices 1). So, for example, if there are six devices, the number of flows will be 6 5 = 30. If there
are 60 devices, the number of flows required will be 60 59 = 3540. Using multiple tables, one for
source and one for destination, the number of flows for 6 devices would be 12 (rather than 30) and 120
(rather than 3540). The savings in number of flows grows significantly as the number of devices
increases.
Note
For a detailed discussion of why multiple tables are useful, refer to the following ONF document:
The Benefits of Multiple Flow Tables and TTPs: http://bit.ly/1GEfFdo

Instructions
Instructions are attached to a flow entry and describe the OpenFlow processing that happens when a
packet matches the flow entry (see Figure 6-35). An instruction either modifies pipeline processing, such
as directing the packet to another flow table, contains a set of actions to add to the action set, or contains
a list of actions to apply immediately to the packet.

Figure 6-35: Instructions


An Action is an operation that forwards the packet to a port or modifies the packet, such as decrementing
the TTL field. Actions may be specified as part of the instruction set associated with a flow entry or in an
action bucket associated with a group entry. Actions may be accumulated in the action set of the packet or
applied immediately to the packet.
An Action Set is a set of actions associated with the packet. Actions are accumulated while the packet is
processed by each table. They are executed when the instruction set instructs the packet to exit the
processing pipeline.
A switch is not required to support all instruction types, but rather just those marked Required
Instruction in the OpenFlow specification. The controller can also query the switch about which of the
Optional Instruction types it supports.
Optional instruction: Meter meter_idDirects packets to the specified meter. As the result of the
metering, the packet may be dropped (depending on meter configuration and state).
Optional instruction: Apply-Actions action(s)Applies the specific action(s) immediately, without
any change to the action set. This instruction may be used to modify the packet between two tables or
to execute multiple actions of the same type. The actions are specified as an action list.
Optional instruction: Clear-ActionsClears all the actions in the action set immediately.
Required instruction: Write-Actions action(s)Merges the specified action(s) into the current action
set. If an action of the given type exists in the current set, overwrite it, otherwise add it.
Optional instruction: Write-Metadata metadata/maskWrites the masked metadata value into the
metadata field. The mask specifies which bits of the metadata register should be modified.
Required instruction: Goto-Table next-table-idIndicates the next table in the processing pipeline.
The table-id must be greater than the current table-id. The flow entries of the last table of the pipeline
cannot include this instruction. OpenFlow switches with only a single flow table are not required to
implement this instruction.
The instruction set associated with a flow entry contains a maximum of one instruction of each type. The
instructions of the set execute in the order specified by the preceding list. In practice, the only constraints
are the following: the Meter instruction is executed before the Apply-Actions instruction, the ClearActions instruction is executed before the Write-Actions instruction, and the Goto-Table is executed last.
A switch must reject a flow entry if it is unable to execute the instructions associated with the flow entry.

In this case, the switch must return an unsupported flow error. Flow tables may not support every match,
every instruction, or every action.

Instructions for investigating OpenFlow negotiations


In this section, you will continue investigating OpenFlow negotiation using Wireshark captures. You will
compare the captured packets with information contained in the OpenFlow specification document.
You will learn about:
Switch features
Switch datapath IDs (DPIDs)
Packet in messages
Buffering
Tables and pipelines
Flow modifications (Flow mod)
Error messages
Instructions for this section will use the IP addresses and network topology in Figure 6-36. If you have
downloaded trial versions of HP VAN SDN Controller and Mininet and plan to follow along with the
instructions in this chapter, refer to Appendix 2Switch configurations for Chapter 6 for switch
configurations.

Figure 6-36: Topology and IP addresses for instructions


1. Disable OpenFlow on Comware 2 (C2):

<C2> system-view
[C2] openflow instance 1
[C2-of-inst-1] undo classification
[C2-of-inst-1] active instance
[C2-of-inst-1] quit

Note
In later releases of the Comware operating system, the command undo active instance is
supported.
2. Configure ProVision 1 (P1) to use controller 192.168.56.11 (but do not enable the instance yet):
P1# config
P1(config)# openflow
P1(openflow)# instance vlan30
P1(of-inst-vlan30)# disable
P1(of-inst-vlan30)# no controller-id 3
P1(of-inst-vlan30)# controller-id 1

3. Start a new Wireshark capture, as illustrated in Figure 6-37.

Figure 6-37: Wireshark capture


4. Enable OpenFlow on ProVision switch 1 (P1):
P1(of-inst-vlan30)# enable
P1(of-inst-vlan30)# exit
P1(openflow)# enable

5. Enable OpenFlow on Comware switch 2 (C2):


[C2-of-inst-1] classification vlan 20
[C2-of-inst-1] active instance

6. Clear the Address Resolution Protocol (ARP) cache on UserVM3 (PC connected to ProVision Switch
P1), as shown in Figure 6-38:

Figure 6-38: Start command prompt as administrator


C:\Windows\system32> arp -a -d
C:\Windows\system32>

7. Ping UserVM3s default gateway and hp.com:


C:\Windows\system32> ping 10.30.30.251

Pinging 10.30.30.251 with 32 bytes of data:
Reply from 10.30.30.251: bytes=32 time=1ms TTL=255
Reply from 10.30.30.251: bytes=32 time<1ms TTL=255
Reply from 10.30.30.251: bytes=32 time<1ms TTL=255
Reply from 10.30.30.251: bytes=32 time<1ms TTL=255

Ping statistics for 10.30.30.251:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

C:\Windows\system32> ping hp.com
Pinging hp.com [192.168.56.51] with 32 bytes of data:
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63

Ping statistics for 192.168.56.51:


Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Windows\system32>

8. Stop the Wireshark capture, as illustrated in Figure 6-39.

Figure 6-39: Stop Wireshark capture


9. Which device determines the switch DPID (controller or switch)?
Specify the following Wireshark filter and click Apply:
openflow_v4.switch_features.capabilities
Select the Features Reply message from 10.1.1.253 in the Wireshark capture, as illustrated in Figure 640.

Figure 6-40: Provision switch Features Reply


Select the Features Reply message from 10.1.1.252 in the Wireshark capture, as illustrated in Figure 641.

Figure 6-41: Comware switch Features Reply


Answer: The switch determines its own DPID.
Note
Output is switch- and version-dependent. Your supported capabilities may be different from the
output in the above screenshots.
OpenFlow specification
The datapath_id field uniquely identifies a datapath. The lower 48 bits are intended for the switch MAC
address, while the top 16 bits are up to the implementer. An example use of the top 16 bits would be a
VLAN ID to distinguish multiple virtual switch instances on a single physical switch. This field should be
treated as an opaque bit string by controllers.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.1, Handshake, page 63.
Available at: http://bit.ly/1Lze7FV

Optional reading
The switch must respond with an OFPT_FEATURES_REPLY message:
/* Switch features. */
struct ofp_switch_features {
struct ofp_header header;
uint64_t datapath_id; /* Datapath unique ID. The lower 48- bits are for a MAC address,
while the upper 16-bits are implementer-defined. */

uint32_t n_buffers; /* Max packets buffered at once. */


uint8_t n_tables; /* Number of tables supported by datapath. */
uint8_t auxiliary_id; /* Identify auxiliary connections */
uint8_t pad[2]; /* Align to 64-bits. */
/* Features. */
uint32_t capabilities; /* Bitmap of support "ofp_capabilities". */
uint32_t reserved;
};
OFP_ASSERT(sizeof(struct ofp_switch_features) == 32);

Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.1, Handshake, page 62.
Available at: http://bit.ly/1Lze7FV
10. How are ProVision switch DPIDs calculated?
Answer: ProVision switches
The most significant 16 bits are the VLAN number associated with the OpenFlow instance. So for the
OpenFlow instance configured on VLAN 30, this number will be 1E. (30 in decimal equates to 1E
in hexadecimal). Hence the switches are identified by 00:1E.
Least significant 48 bits are the switch MAC address.
Figure 6-42 shows ProVision switch 2 (P2) in our example topology with instance 30:

Figure 6-42: OpenFlow Monitor


Figure 6-43 shows an example of a 5406zl switch configured with instance 11.

Figure 6-43: OpenFlow Monitor


11. How are Comware switch DPIDs calculated?
DPIDs on Comware switches:
Comprised of the instance ID and the bridge MAC address. The most significant 16 bits are the
instance ID.
The least significant 48 bits are the bridge MAC address.
Figure 6-44 shows a 5920 switch configured with instance 1:

Figure 6-44: OpenFlow Monitor


How are Open vSwitch DPIDs calculated?
Open vSwitch switch DPIDs:
Comprised of 00:00 and the MAC address of the OVS bridge.
Figure 6-45 shows OVS running KVM.

Figure 6-45: OVS running KM


sdn@KVMServer1:~$ ifconfig
...
ovsbr0Link encap:EthernetHWaddr 00:0c:29:e8:22:de
inet addr:172.16.1.13 Bcast:172.16.1.255 Mask:255.255.255.0

Note
The ifconfig command will be deprecated in favor of the ip address command in Linux.
12. What is a packet_in message?
Specify the following filter and click Apply:
openflow_v4.packet_in.reason

Figure 6-46: Packet_in


In the Wireshark capture in Figure 6-46, a packet_in message is displayed. This is an ARP message that is
encapsulated in OpenFlow and forwarded to the controller for processing.
Answer (OpenFlow specification)
Asynchronous messages are sent without a controller soliciting them from a switch. Switches send
asynchronous messages to controllers to denote a packet arrival, switch state change, or error.
Packet-in: Transfer the control of a packet to the controller. For all packets forwarded to the
CONTROLLER reserved port using a flow entry or the table-miss flow entry, a packet-in event is always
sent to controllers. Other processing, such as TTL checking, may also generate packet-in events to send
packets to the controller.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1.2, Asynchronous, page 26.
Available at: http://bit.ly/1Lze7FV
13. Why was this packet sent to the controller? Check Figure 6-47.

Figure 6-47: Packet_in


Answer: The reason given for forwarding the packet to the controller is: OFPR_ACTION (1) which
means this was explicitly programmed to forward traffic to the controller.

Optional reading
The OpenFlow specification provides the following detail:
The reason field can be any of these values:
/* Why is this packet being sent to the controller? */
enum ofp_packet_in_reason {
OFPR_NO_MATCH = 0, /* No matching flow (table-miss flow entry). */
OFPR_ACTION = 1, /* Action explicitly output to controller. */
OFPR_INVALID_TTL = 2, /* Packet has invalid TTL */
};

Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.4.1, Packet-In Message, page 95.
Available at: http://bit.ly/1Lze7FV

This matches the flow entry programmed by the controller. To see this, click OpenFlow Monitor in the
HP VAN SDN Controller GUI, as illustrated in Figure 6-48.

Figure 6-48: OpenFlow Monitor


Select ProVision Switch 1 (10.1.1.253) and select Flows (see Figure 6-49). Find the ARP entry in table
100 and then expand the flow entry.

Figure 6-49: ProVision switch flow table

Result: The controller is copying ARP messages so that it can discover hosts on the network.
14. Which entry is the table-miss flow entry in an OpenFlow table?
Answer: The table-miss flow entry for table 100 is shown in Figure 6-50.
15. What priority does a table miss have? What does it match on?
Answer: The table-miss flow entry has a priority of 0 and a blank match field.
Find the table-miss flow entry in Table 100 (table 100, priority 0, match field = blank). Expand the flow
entry as shown in Figure 6-50.

Figure 6-50: ProVision table miss


Result
The table-miss entry will output traffic that does not match any other flow entries in the flow table to the
NORMAL port.
OpenFlow specification
Every flow table must support a table-miss flow entry to process table misses. The table-miss flow
entry specifies how to process packets unmatched by other flow entries in the flow table, and may, for
example, send packets to the controller, drop packets or direct packets to a subsequent table.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 5.4, Table Miss, page 16.
Available at: http://bit.ly/1Lze7FV
View the table-miss entry on Comware C2, as shown in Figure 6-51.

Figure 6-51: Comware table miss


OpenFlow specification
The table-miss flow entry is identified by its match and its priority, it wildcards all match fields (all
fields omitted) and has the lowest priority (0).
The match of the table-miss flow entry may fall outside the normal range of matches supported by a flow
table, for example, an exact match table would not support wildcards for other flow entries but must
support the table-miss flow entry wildcarding all fields.
The table-miss flow entry may not have the same capability as regular flow entry. The table-miss flow
entry must support at least sending packets to the controller using the CONTROLLER reserved port and
dropping packets using the Clear-Actions instruction. Implementations are encouraged to support
directing packets to a subsequent table when possible for compatibility with earlier versions of this
specification.
16. View the Flow tables of ProVision Switch P1 in Figure 6-52. Why does the ProVision switch have
multiple entries with a priority of zero?

Figure 6-52: ProVision table miss


Answer: Each table has a table-miss entry. There are three tables in the ProVision switch output
(Table 0, Table 100, and Table 200). Each table as a separate table-miss entry and according
action.
17. Is a table-miss entry required?
Answer
OpenFlow specification
The table-miss flow entry behaves in most ways like any other flow entry: it does not exist by default in a
flow table, the controller may add it or remove it at any time, and it may expire.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 5.4, Table-miss, page 16.
Available at: http://bit.ly/1Lze7FV
18. What happens if there is no table-miss entry?
Answer

OpenFlow specification
If the table-miss flow entry does not exist, by default packets unmatched by flow entries are dropped
(discarded). A switch configuration, for example, using the OpenFlow Configuration Protocol, may
override this default and specify another behavior.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 5.4, page 16. Available at:
http://bit.ly/1Lze7FV
19. How many OpenFlow tables must a compliant OpenFlow switch have?
Answer: An OpenFlow switch must have at least one OpenFlow table.
20. What is the maximum number of OpenFlow tables a switch may have?
Answer: A switch may have up to 255 OpenFlow tables.
21. How is traffic forwarded from one OpenFlow table to another?
Answer: The Goto instruction forwards traffic to another OpenFlow table.
22. Can traffic be forwarded from Table 200 to Table 100 in an OpenFlow switch?
Answer: Traffic can only be directed to tables with a higher number (cannot go backward).
OpenFlow specification
Figure 6-53 shows an OpenFlow switch pipeline as per the OpenFlow specification:

Figure 6-53: OpenFlow pipeline


The OpenFlow pipeline of every OpenFlow switch contains multiple flow tables, each flow table
containing multiple flow entries. The OpenFlow pipeline processing defines how packets interact with

those flow tables. An OpenFlow switch is required to have at least one flow table and can optionally
have more flow tables. An OpenFlow switch with only a single flow table is valid; in this case pipeline
processing is greatly simplified.
The flow tables of an OpenFlow switch are sequentially numbered, starting at 0. Pipeline processing
always starts at the first flow table: the packet is first matched against flow entries of flow Table 0. Other
flow tables may be used depending on the outcome of the match in the first table.
When processed by a flow table, the packet is matched against the flow entries of the flow table to select
a flow entry. If a flow entry is found, the instruction set included in that flow entry is executed. These
instructions may explicitly direct the packet to another flow table (using the Goto Instruction), where the
same process is repeated again. A flow entry can only direct a packet to a flow table number that is
greater than its own flow table number, in other words pipeline processing can only go forward and not
backward. Obviously, the flow entries of the last table of the pipeline cannot include the Goto instruction.
If the matching flow entry does not direct packets to another flow table, pipeline processing stops at this
table. When pipeline processing stops, the packet is processed with its associated action set and usually
forwarded.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 5.1, Pipeline Processing, page 13,
14. Available at: http://bit.ly/1Lze7FV
23. What does the n_tables field show?
Specify the following filter and click Apply:
openflow_v4.switch_features.n_buffers
Select the Features Reply message from 10.1.1.253 in the Wireshark capture.

Figure 6-54: ProVision switch P1 Features Reply

Result: In the Wireshark capture (see Figure 6-54), three tables are specified. This is because this
Wireshark capture is for an HP ProVision switch. HP ProVision switches support three tables by
default in the OpenFlow pipeline. This will be discussed in more detail shortly.
Select the Features Reply message from 10.1.1.252 in the Wireshark capture in Figure 6-55.

Figure 6-55: Comware switch C2 Features Reply


Result: In the Wireshark capture, a single table is specified. This is because this Wireshark capture is
for an HP Comware switch. HP Comware switches support a single table by default in the
OpenFlow pipeline. This will be discussed in more detail shortly.
OpenFlow specification
The n_tables field describes the number of tables supported by the switch, each of which can have a
different set of supported match fields, actions, and number of entries. When the controller and switch
first communicate, the controller will find out how many tables the switch supports from the Features
Reply. If it wishes to understand the size, types, and order in which tables are consulted, the controller
sends an OFPMP_TABLE_FEATURES multipart request. A switch must return these tables in the order
the packets traverse the tables.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.1, Handshake, page 62.
Available at: http://bit.ly/1Lze7FV
The OFPMP_TABLE_FEATURES multipart type allows a controller to both query for the capabilities of

existing tables and to optionally ask the switch to reconfigure its tables to match a supplied configuration.
In general, the table feature capabilities represents all possible features of a table; however, some
features may be mutually exclusive and the current capabilities structures do not allow us to represent
such exclusions.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.5.5, Table Features, page 79.
Available at: http://bit.ly/1Lze7FV
This can be seen once again on the HP VAN SDN Controller OpenFlow Monitor. Click switch Summary
information (see Figure 6-56).

Figure 6-56: OpenFlow MonitorP1 summary


Figure 6-57 displays the summary for C1, which is the Comware switch.

Figure 6-57: OpenFlow MonitorC1 summary


24. View the flow table of the ProVision switch P1 (10.1.1.253) on the HP VAN SDN Controller (see
Figure 6-58). Explain how DHCP messages are processed in the ProVision switch OpenFlow
pipeline.
Answer: The answer given here is based on a 3800 series switch: In the flow table below, the
following takes place:
(1) Arriving traffic is first matched on the entries in the first OpenFlow table in the pipeline (Table
0). This table has a single entry, which is a table-miss entry (priority zero, match anything). The
entry has a goto statement to send traffic to Table 100.
(2) DHCP traffic will match either of the entries in Table 100 with priority of 31500. The entries
have a goto statement to send traffic to Table 200.
There are two DHCP entriesUDP port 67 is the client DHCP listen port and UDP port 68 is the
server DHCP listen port. Two entries have been added to match flows in both directions.
(3) DHCP traffic will match either of the entries in Table 200 with priority of 31500. The entries
have an apply action of both output to CONTROLLER and output NORMAL. Thus, DHCP traffic
is sent to the normal pipeline (traditional routing and switching) and is also copied to the
controller.
Note
Copied in this context means creating a copy of the packet before the packet egresses the switch and
then encapsulating the copy into an OpenFlow packet-in message which is then sent to the
controller.

Figure 6-58: ProVision flow


25. View the tables on the ProVision switch P1 console:
P1# show openflow instance vlan30 flow-table
OpenFlow Instance Flow Table Information

P1#

26. Figure 6-59 is taken from the HP OpenFlow 1.3 Administrator Guide and summarizes the tables
used:

Figure 6-59: ProVision pipeline


Result: In an HP ProVision switch, Table 0 and Table 100 are hardware tables (ASICs) and Tables
200 to 203 are software tables. By default, a single software table (200) is used.
Note
Source: HP Switch Software OpenFlow v1.3 Administrator Guide K/KA/WB 15.17, page 17.
Available at: http://bit.ly/1GV7TJ9
27. Save your current Wireshark capture for later use. See Figure 6-60. Use the following filename:
Wireshark OpenFlow capture 1.pcapng.

Figure 6-60: Save Wireshark capture


28. Start a new Wireshark Capture, as illustrated in Figure 6-61.

Figure 6-61: New Wireshark capture


29. In the Flow Maker application, select ProVision switch 1 (10.1.1.253), as illustrated in Figure 6-62.

Figure 6-62: Flow Maker application


30. Click Add to add a new flow, as illustrated in Figure 6-63.

Figure 6-63: Add new flow


31. Program a new flow entry in Table 0 of the ProVision switch 1 (P1) that drops all ingress traffic on
port 2.
Will this rule work?
Add a flow entry with the following attributes and then click Add (see Figure 6-64).
Table ID:0
Priority: 100
In Port: 2
Instructions: Apply Action
Action 1: No Action
Save Flow = True

Figure 6-64: Program a flow entry


Result: The flow is rejected by the OpenFlow switch.
32. In Wireshark, specify the following filter and click Apply (see Figure 6-65).
openflow_v4.error.type

Figure 6-65: Flow entry added


An error displays with the following type and code:
Type: OFPET_BAD_MATCH = 4
Code: OFPBMC_BAD_TYPE = 0

OpenFlow specification
If the match in a flow mod message specifies a field that is unsupported in the table, the switch must
return an ofp_error_msg with OFPET_BAD_MATCH type and OFPBMC_BAD_TYPE code.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, 6.4, Flow Table Modification Messages,
page 36. Available at: http://bit.ly/1Lze7FV
Optional reading
For the OFPET_BAD_MATCH error type, the following codes are currently defined:
/* ofp_error_msg code values for OFPET_BAD_MATCH. data contains at least
* the first 64 bytes of the failed request. */
enum ofp_bad_match_code {
OFPBMC_BAD_TYPE = 0, /* Unsupported match type specified by the match */
OFPBMC_BAD_LEN = 1, /* Length problem in match. */
OFPBMC_BAD_TAG = 2, /* Match uses an unsupported tag/encap. */
OFPBMC_BAD_DL_ADDR_MASK = 3, /* Unsupported datalink addr mask - switch does not support
arbitrary datalink address mask. */
OFPBMC_BAD_NW_ADDR_MASK = 4, /* Unsupported network addr mask - switch does not support
arbitrary network address mask. */
OFPBMC_BAD_WILDCARDS = 5, /* Unsupported combination of fields masked or omitted in the
match. */
OFPBMC_BAD_FIELD = 6, /* Unsupported field type in the match. */
OFPBMC_BAD_VALUE = 7, /* Unsupported value in a match field. */
OFPBMC_BAD_MASK = 8, /* Unsupported mask specified in the match,
field is not dl-address or nw-address. */
OFPBMC_BAD_PREREQ = 9, /* A prerequisite was not met. */
OFPBMC_DUP_FIELD = 10, /* A field type was duplicated. */
OFPBMC_EPERM = 11, /* Permissions error. */
};

Note
Source: OpenFlow Switch Specification, Version 1.3.2, 7.4.4, Error Message, page 99. Available
at: http://bit.ly/1Lze7FV
The HP OpenFlow 1.3 Administrator Guide states the following:

When programming flows via a controller, error messages may be returned based on implementation
restrictions in the OpenFlow switch.
Examples relevant to OpenFlow 1.3 include:
Table 0 restrictions: Table 0, a read-only table, in the OpenFlow 1.3 multiple pipeline represents the
start of the pipeline.
Note
Source: HP Switch Software OpenFlow v1.3 Administrator Guide K/KA/WB 15.17, page 83.
Available at: http://bit.ly/1GV7TJ9
33. Look at the table capability on the switch console:
P1# show openflow instance vlan30 flow-table 0 table-capability
OpenFlow Flow Table Properties

Table Match Capabilities:
Table Instructions:
Table-Miss Instructions:
GoTo 100
P1#

Result: Rules such as the one we configured through Flow Maker cannot be written to Table 0 on HP
ProVision switches using V1 or V2 ASICs. The only capability is table miss and sending traffic to
Table 100.
34. In the Flow Maker application, add a match for source MAC address to Table 100 of the ProVision
switch.
Will this rule work?
Add a flow entry with the following attributes and then click Add (see Figure 6-66).
Table ID: 100
Priority: 100
Src Mac: aaaabbbbcccc
Instructions: Apply Action
Action 1: No Action
Save Flow = True

Figure 6-66: Program a flow entry


35. The result depends on the hardware you are using. If you are using an HP 3800 switch, the flow entry
will be accepted. An HP 3500 switch will not accept the flow entry.
Note
You will be using Wireshark to capture and view a successful flow modification message later in
this chapter.
If you are using a 3500 series switch, you will see a message similar to the following:

Figure 6-67: Flow entry added

The same error code displays:


Type: OFPET_BAD_MATCH = 4
Code: OFPBMC_BAD_TYPE = 0
OpenFlow specification:
If the match in a flow mod message specifies a field that is unsupported in the table, the switch must
return an ofp_error_msg with OFPET_BAD_MATCH type and OFPBMC_BAD_FIELD code.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, 6.4, Flow Table Modification Messages,
page 36. Available at: http://bit.ly/1Lze7FV
OpenFlow specification:
For the OFPET_BAD_MATCH error type, the following codes are currently defined:
/* ofp_error_msg code values for OFPET_BAD_MATCH. data contains at least
* the first 64 bytes of the failed request. */
enum ofp_bad_match_code {
OFPBMC_BAD_TYPE = 0, /* Unsupported match type specified by the
match */
OFPBMC_BAD_LEN = 1, /* Length problem in match. */
OFPBMC_BAD_TAG = 2, /* Match uses an unsupported tag/encap. */
};

Note
Source: OpenFlow Switch Specification, Version 1.3.2, 7.4.4, Error Message, page 99. Available
at: http://bit.ly/1Lze7FV
36. Why do some switches like the 3500 return an error code and others like the 3800 do not?
37. As discussed previously, a 3800 switch uses V2 ASICs and a 3500 uses V1 ASICs. There are
restrictions on the flow entries that can be written with V1 ASICs, including matching on source
MAC address.
Figure 6-68 is taken from the HP OpenFlow 1.3 Administrator Guide and shows OpenFlow v1.3 support
when using V1 ASICs:

Figure 6-68: ProVision V1 ASIC table support

Note
Source: HP Switch Software OpenFlow v1.3 Administrator Guide K/KA/WB 15.17, page 92.
Available at: http://bit.ly/1GV7TJ9
Details in Figure 6-68:
Tables: 0 (read-only), Table 100 (TCAM), Table 200 (Software)
Values that can be matched in hardware: in port, VLAN ID , Ethernet type, IP source address (IPv4
and IPv6), IP destination address (IPv4 and IPv6), IP protocol, TCP/UDP source port, and
TCP/UDP destination port
Actions that can be executed in hardware: destination port (single port), modify VLAN priority,
and modify IP differentiated services code point (DSCP)
Result: A switch using V1 ASICs can only match on the fields shown above and modify port, VLAN
priority, and DSCP in hardware (Table 100). Source MAC address matching is not permitted in
hardware. A 3500 ProVision switch is an example of this switch type.
Figure 6-69 shows V2 ASICs supported match and actions in hardware (OpenFlow 1.3).

Figure 6-69: ProVision V2 ASIC table support

Note
Source: HP Switch Software OpenFlow v1.3 Administrator Guide K/KA/WB 15.17, page 92.
Available at: http://bit.ly/1GV7TJ9
Result: A switch using V2 ASICs can match on many more fields, including source MAC address in
hardware. More actions are also supported. A 3800 ProVision switch is an example of this switch
type.
The switch still uses three tables by default:
Tables: 0 (Read-only), Table 100 (TCAM), and Table 200 (Software)
The full 12 tuples can be matched on:
Ingress Port
VLAN ID
VLAN Priority
Source MAC
Destination MAC
Ethertype
IP source address (IPv4/IPv6)
IP destination address (IPv4/IPv6)
IP protocol
IP DSCP
TCP/UDP source port
TCP/UDP destination port
Not all 12 tuples can be actioned in hardware (six supported):
Destination port (one or more ports)
Modify source MAC address
Modify destination MAC address
Modify VLAN ID
Modify VLAN priority
Modify IP DSCP
Figure 6-70 shows V3 ASICs supported match and actions in hardware (OpenFlow 1.3):

Figure 6-70: ProVision V3 ASIC table support

Note
Source: HP Switch Software OpenFlow v1.3 Administrator Guide K/KA/WB 15.17, page 92.
Available at: http://bit.ly/1GV7TJ9
Result: A switch with V3 ASICs only, like the HP ProVision 5406R, can match on all 12 tuple fields.
Additional actions can also be supported.
The OpenFlow tables can be configured dynamically by SDN Applications (discussed shortly).
The full 12 tuples can be matched on:
Ingress port
VLAN ID
VLAN priority
Source MAC
Destination MAC
Ethertype
IP source address (IPv4/IPv6)
IP destination address (IPv4/IPv6)
IP protocol
IP DSCP
TCP/UDP source port
TCP/UDP destination port
The following may be actioned in hardware:

Destination port (one or more ports)


Modify source MAC address
Modify destination MAC address
Modify VLAN ID
Modify VLAN priority
Modify IP DSCP
Modify IPv4 source address
Modify IPv4 destination address
Modify TCP/UDP source address (IPv4)
Modify TCP/UDP destination address (IPv4)
38. We will now look at the table capability on our ProVision switch 1 (P1)this will vary depending on
the switch used:
3800 example
P1# show openflow instance vlan30 flow-table 100 table-capability
OpenFlow Flow Table Properties
Table Match Capabilities:

Table Instructions:
Metering
Apply Actions
Set-Field
Ethernet DestinationEthernet Source
VLAN IDVLAN PCP
IP DSCP
Output
GoTo 200

Table-Miss Instructions:
Metering
Apply Actions
Output
GoTo 200
P1#

5406zl example
5406zl# show openflow instance vlan30 flow-table 100 table-capability
OpenFlow Flow Table Properties
Table Match Capabilities:
Incoming PortEthernet Type
VLAN IDIP DSCP
P1# show openflow instance vlan30 flow-table 100 table-capability
OpenFlow Flow Table Properties
Table Match Capabilities:

Table Instructions:
Metering
Apply Actions
Set-Field
Ethernet DestinationEthernet Source
VLAN IDVLAN PCP
IP DSCP
Output
GoTo 200
Table-Miss Instructions:

Metering
Apply Actions
Output
GoTo 200
P1#

Table Instructions:
Metering
Apply Actions
Set-Field
VLAN PCPIP DSCP
Output
GoTo 200
Table-Miss Instructions:
Metering
Apply Actions
Output
GoTo 200
HP-5406zl#

39. If the flow entry was added by your switch (3800), delete it in Flow Maker (see Figure 6-71).

Figure 6-71: OpenFlow pipeline


40. In summary, the HP OpenFlow 1.3 Administrator Guide (see Figure 6-72) shows the tables used by
default on ProVision switches that use V1 or V2 ASICs. Supported matches and actions are ASIC
dependent.

Figure 6-72: ProVision default pipeline


Tables in pipeline:
Table 0: Read-only
Table 100 (TCAM)
Table 200 (Software)
An additional mode called IP Control table mode is also available on ProVision switches. This
extends the number of tables available in the pipeline (see Figure 6-73).

Figure 6-73: Pipeline

Caution
IP control table mode is not supported on version 2.5 of the HP VAN SDN Controller (but may be in
later controller releases). It will therefore not be discussed further in this study guide.
41. ProVision V3 ASIC switches such as the 5406R support more tables and also support the dynamic
creation of tables. By default tables 0, 1, 2, and 3 are available. But, in addition, rather than a switch
informing a controller of the tables available, the controller can tell the switch which tables to create.
An application requiring a specific pipeline can tell the switch which tables to create, as illustrated
in Figure 6-74.

Figure 6-74: Default pipeline


42. What is the default table number used in Comware?
Answer: Comware uses a default table number of zero (OpenFlow 1.3). This is a hardware table.

43. Is this a hardware or a software table?


Answer: Comware switches use a hardware table. Comware switches currently only support
hardware tables.
44. Do Comware switches support hardware and software tables?
Answer: Comware switches currently only support hardware tables.
45. If the switch only has a single OpenFlow table, will the switch be complaint with the OpenFlow
specification?
Answer: Yes, to be compliant with the OpenFlow specification, a switch must support at least one
table.
View the OpenFlow tables on Comware switch 2 (C2), as Figure 6-75 illustrates.

Figure 6-75: OpenFlow Monitor

Note
Comware switches do support the configuration of two hardware tables. However, as this is not
supported with version 2.5 of the HP VAN SDN Controller, it will not be discussed here. This may
change in future.
46. Open your saved Wireshark capture Wireshark OpenFlow capture 1.pcapng.
47. After a switch and a controller have sent Hello messages to each other, the controller requests features
from the switch. The switch replies with features and this includes buffer support information, as
illustrated in Figure 6-76.

Figure 6-76: ProVision n_buffers


To see only buffer information of both switches, specify the following filter and click Apply (see Figure
6-77 and Figure 6-78): openflow_v4.switch_features.n_buffers.

Figure 6-77: ProVision number of buffers

Figure 6-78: Comware number of buffers


48. What is the value of the n_buffers field?
Answer: On the HP ProVision switch the n_buffers field is set to zero. On the HP Comware switch the
n_buffers field is set to 1024.
49. Do ProVision switches support packet buffering?
Answer: No, at the time of this writing, ProVision switches using either V1 or V2 ASICs do not
support packet buffering (V1 or V2 ASICs, up to version 15.17 of software).
50. Do Comware switches support packet buffering?
Answer: Comware switches do support packet buffering.
51. If a switch buffers a packet, what is sent to the controller?
Answers: Only header information is sent to the controller.
n_buffers:
The n_buffers field specifies the maximum number of packets the switch can buffer when sending packets
to the controller using packet-in messages.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.1, Handshake, page 63.
Available at: http://bit.ly/1Lze7FV
Table-miss
If a packet does not match a flow entry in a flow table, this is a table miss. The behavior on a table miss
depends on the table configuration. A table-miss flow entry in the flow table can specify how to process
unmatched packets: options include dropping them, passing them to another table, or sending them to the
controller over the control channel via packet-in messages.

Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 5.1, Pipeline Processing, page 14.
Available at: http://bit.ly/1Lze7FV
Packet-in and buffering (excerpted from the OpenFlow Switch Specification)
Packet-in events can be configured to buffer packets. For packet-in generated by an output action in flow
entries or a group bucket, it can be specified individually in the output action itself, for other packet-in it
can be configured in the switch configuration. If the packet-in event is configured to buffer packets and the
switch has sufficient memory to buffer them, the packet-in events contain only some fraction of the packet
header and a buffer ID to be used by a controller when it is ready for the switch to forward the packet.
Switches that do not support internal buffering, are configured to not buffer packets for the packet-in
event, or have run out of internal buffering, must send the full packet to controllers as part of the event.
Buffered packets will usually be processed via a Packet-out message from a controller, or automatically
expired after some time. If the packet is buffered, the number of bytes of the original packet to include in
the packet-in can be configured. By default, it is 128 bytes. For packet-in generated by an output action in
flow entries or a group bucket, it can be specified individually in the output action itself, for other packetin it can be configured in the switch configuration.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1.2, Asynchronous, page 26.
Available at: http://bit.ly/1Lze7FV
Support for the miss_len field in switch configuration messages
The switch implementation does not honor the miss_len miss_send_len field specified in the packet-in
switch configuration messages. This is because the switch does not buffer packets. Due to this, the
controller will see the entire packet copied in packet-in message with buffer_id set as
OFP_NO_BUFFER.
Note
Source: HP Switch Software, OpenFlow v1.3 Administrator Guide, K/KA/WB 15.17, page 99.
Available at: http://bit.ly/1GV7TJ9
This can be seen on the HP VAN SDN Controller OpenFlow Monitor, as illustrated in Figure 6-79 and
Figure 6-80.

Figure 6-79: ProVision n_buffers

Figure 6-80: Comware n_buffers


Result: The ProVision switch does not buffer. The Comware switch has 1024 buffers.
52. Clear the Wireshark filter and then start a new Wireshark Capture, as illustrated in Figure 6-81.

Figure 6-81: Start the Wireshark capture

53. In the Flow Maker application, add a match for the same source MAC address, but in this case, write
the entry to Table 200 of the ProVision switch.
Will this rule work?
Add a flow entry with the following attributes and then click Add, as illustrated in Figure 6-82.
Table ID: 200
Priority: 100
Src Mac: aaaabbbbcccc
Instructions: Apply Actions
Action 1: No Action
Save Flow = True

Figure 6-82: Program a flow entry


54. The flow entry is added to the flow table of the switch (both 3500 and 3800 switches) (see Figure 683).

Figure 6-83: Flow entry added


Result: No error shows in Wireshark as the flow entry is accepted. Software tables allow for
matching and apply actions on the full 12 tuples.
55. Select the Comware switch (10.1.1.252) in Flow Maker and add the following flow entry, as
illustrated in Figure 6-84.
Table ID: 0
Priority: 100
Src Mac: bbbbccccdddd
Instructions: Apply Actions
Action 1: No Action
Save Flow = True

Figure 6-84: Program a flow entry


56. The flow entry is added to the flow table of the switch, as illustrated in Figure 6-85.

Figure 6-85: Flow entry added


Result: No error shows in Wireshark because the flow entry is accepted.

57. Stop the Wireshark capture (see Figure 6-86).

Figure 6-86: Stop the Wireshark capture


58. Change the filter in Wireshark, as illustrated in Figure 6-87.
Set the Wireshark filter to: openflow_v4.flowmod.command.
Click Apply.

Figure 6-87: Modify the Wireshark filter


59. What is a flow mod?
Answer:
One of the controller-to-switch messages is Modify State:
Modify-State messages are sent by the controller to manage state on the switches. Their primary purpose
is to add, delete, and modify flow and group entries in the OpenFlow tables and to set switch port
properties.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1.1, Controller-to-Switch, page
26. Available at: http://bit.ly/1Lze7FV
Flow modification messages can have the following types:
enum ofp_flow_mod_command {
OFPFC_ADD = 0, /* New flow. */
OFPFC_MODIFY = 1, /* Modify all matching flows. */
OFPFC_MODIFY_STRICT = 2, /* Modify entry strictly matching wildcards and priority.*/
OFPFC_DELETE = 3, /* Delete all matching flows. */
OFPFC_DELETE_STRICT = 4, /* Delete entry strictly matching wildcards and priority. */
};

Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.4, Flow Table Modification
Messages, page 34. Available at: http://bit.ly/1Lze7F
60. View the second messagethe flow mod sent to Comware switch 10.1.1.252, shown in Figure 6-88.
This message was sent from the controller to the switch.

Figure 6-88: Message sent to the controller


Result: This is an OFPFC_ADD message. The controller is adding a new flow to the switch.
Note
You can use the following Wireshark filter to reduce the number of OpenFlow messages displayed:
openflow_v4.oxm.field == 4
61. View the result of the flow mod sent to ProVision switch 10.1.1.253, which is illustrated in Figure 689. This message is sent from the controller to the switch.

Figure 6-89: Flow modification


Result: This is also an OFPFC_ADD message.
Note the packet number if you need to find it in the capture (see Figure 6-90).

Figure 6-90: Packet number


62. Change the Wireshark filter to openflow_4 and click Apply, as illustrated in Figure 6-91.

Figure 6-91: Apply filter


63. Find the barrier request message. This is after the flow mod and called:
OFPT_MULTIPART_REQUEST, OFPMP_FLOW (see Figure 6-92).

Figure 6-92: Barrier request


Controller-to-switch messages are initiated by the controller and may or may not require a response from
the switch.
Barrier: Barrier request/reply messages are used by the controller to ensure message dependencies have
been met or to receive notifications for completed operations.

Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1.1, Controller-to-Switch, page
26. Available at: http://bit.ly/1Lze7FV
Message ordering: Ordering can be ensured through the use of barrier messages. In the absence of
barrier messages, switches may arbitrarily reord messages to maximize performance. Hence,
controllers should not depend on a specific processing order. In particular, flow entries may be
inserted in tables in an order different from that of flow mod messages received by the switch.
Messages must not be reordered across a barrier message and the barrier message must be
processed only when all prior messages have been processed. More precisely:
1. Messages before a barrier must be fully processed before the barrier, including sending any
resulting replies or errors.
2. The barrier must then be processed and a barrier reply sent.
3. Messages after the barrier may then begin processing.
If two messages from the controller depend on each other, they must be separated by a barrier
message. Examples of such message dependencies include a group mod add with a flow mod add
referencing the group, a port mod with a packet-out forwarding to the port, or a flow mod add with a
following packet-out to OFPP_TABLE.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.2, Message Handling, page 28,
Available at: http://bit.ly/1Lze7FV
64. Find the barrier reply message (after the barrier requestsee Figure 6-93).

Figure 6-93: Barrier reply

65. Does a switch notify the controller when an OpenFlow entry is deleted?
Start the Wireshark capture (see Figure 6-94) and continue without saving.

Figure 6-94: Start a Wireshark capture


66. In Flow Maker, delete the flow entry you added from the Comware switch (see Figure 95).

Figure 6-95: Delete flow entry


67. Delete the flow you added from the ProVision switch (see Figure 6-96).

Figure 6-96: Delete flow entry


68. Change the Wireshark filter to openflow_v4.flow_removed.reason and click Apply (see Figure 697).

Figure 6-97: Flow removed


69. A message from the switch (10.1.1.252) was sent to the controller, as illustrated in Figure 6-98.

Figure 6-98: Flow removed


In the Wireshark capture, the switch is informing the controller of the flow removal
(OFPT_FLOW_REMOVED) and the reason for the removal (OFPRR_DELETE (2)).
OpenFlow specification
Flow entries are removed from flow tables in two ways, either at the request of the controller or via the
switch flow expiry mechanism.
The switch flow expiry mechanism is run by the switch independently of the controller and is based on
the state and configuration of flow entries. Each flow entry has an idle_timeout and a hard_timeout
associated with it.
The controller may actively remove flow entries from flow tables by sending delete flow table
modification messages (OFPFC_DELETE or OFPFC_DELETE_STRICT).
When a flow entry is removed, either by the controller or the flow expiry mechanism, the switch must
check the flow entrys OFPFF_SEND_FLOW_REM flag. If this flag is set, the switch must send a flow
removed message to the controller. Each flow removed message contains a complete description of the
flow entry, the reason for removal (expiry or delete), the flow entry duration at the time of removal, and
the flow statistics at the time of removal.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 5.5, Flow Removal, page 16.
Available at: http://bit.ly/1Lze7FV
70. Change the Wireshark filter to openflow_v4 and click apply. A flow mod message from the controller
to the switch is seen immediately before the flow removed message (see Figure 6-99).

Figure 6-99: Flow_mod


Look at the flow_mod message. The application instructed the controller to do a flow_mod using
OFPFC_DELETE_STRICT (4), as illustrated in Figure 6-100.

Figure 6-100: Flow_mod


Flow table modification messages can have the following types:
enum ofp_flow_mod_command {
OFPFC_ADD =0,/* New flow. */
OFPFC_MODIFY =1, /* Modify all matching flows. */
OFPFC_MODIFY_STRICT = 2, /* Modify entry strictly matching wildcards and priority. */
OFPFC_DELETE =3,/* Delete all matching flows. */
OFPFC_DELETE_STRICT = 4, /* Delete entry strictly matching wildcards and priority. */
};

For delete requests (OFPFC_DELETE or OFPFC_DELETE_STRICT), if a matching entry exists in the


table, it must be deleted, and if the entry has the OFPFF_SEND_FLOW_REM flag set, it should generate

a flow removed message. For delete requests, if no flow entry currently residing in the requested table
matches the request, no error is recorded and no flow table modification occurs.
Codes:
Type: OFPT_FLOW_MOD = 14
Command: OFPFC_DELETE_STRICT = 4
In the Wireshark capture, a OFPT_FLOW_MOD (14) message was sent by the controller to the switch
and the command is set to OFPFC_DELETE_STRICT (4). The switch therefore removes the flow entry
and informs the controller of the flow removal.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.4, Flow Table Modification
Messages, page 34, 35. Available at: http://bit.ly/1Lze7FV
71. What happens when you try to send traffic from a valid table to a nonexistent table in the OpenFlow
pipeline (goto_table instruction)?
Set the following in Wireshark (see Figure 6-101):
Set the Wireshark filter to: openflow_v4.error.type
Click Apply
Click Restart a new live capture

Figure 6-101: Wireshark filter


In Flow Maker, add a flow entry with the following attributes to the Provision Switch (10.1.1.253)
and then click Add (see Figure 6-102):
Table ID: 100
Priority: 100
In Port: 2
Instructions: Goto Table
Table: 150
Save Flow: True

Figure 6-102: Program a flow entry


The switch responds with a bad table message, as illustrated in Figure 6-103.

Figure 6-103: Error from switch


Result: If the instructions requested contain goto_table and the next-table-id refers to an invalid table, the
switch must return an OFP_ERROR_MSG message with an OFPET_BAD_INSTRUCTION type and a
OFPBIC_BAD_TABLE_ID code.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.4, Flow Table Modification
Messages, page 34. Available at: http://bit.ly/1Lze7FV

72. What happens when you try to push a duplicate flow entry to the switch?
Add a flow entry to the ProVision switch (10.1.1.253) with the following attributes and then click
Add (see Figure 6-104):
Table ID: 100
Priority: 0
Instructions: Apply Actions
Save Flow: True

Figure 6-104: Program a flow entry


Result: The switch responds with a OFPMFC_OVERLAP message, as illustrated in Figure 6-105.

Figure 6-105: Error from switch


For add requests (OFPFC_ADD) with the OFPFF_CHECK_OVERLAP flag set, the switch must first
check for any overlapping flow entries in the requested table. Two flow entries overlap if a single packet
may match both, and both entries have the same priority. If an overlap conflict exists between an existing
flow entry and the add request, the switch must refuse the addition and respond with an ofp_error_msg
message with the OFPET_FLOW_MOD_FAILED type and OFPFMFC_OVERLAP code.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.4, Flow Table Modification
Messages, page 34. Available at: http://bit.ly/1Lze7FV
73. Where are flow statistics stored, on the controller or on a switch?
Stop the Wireshark Capture (see Figure 6-106).

Figure 6-106: Stop capture


Set the following in Wireshark (see Figures 6-107 and 6-108).
Set the Wireshark filter to: openflow_v4.flow_stats.priority
Click Apply
Click Start to start a new live capture
Click Continue without Saving

Figure 6-107: Wireshark filter

Figure 6-108: Continue without Saving


In the Controller GUI, click OpenFlow Monitor, as illustrated in Figure 6-109 .

Figure 6-109: OpenFlow Monitor


Select the Comware switch (C2) and then click Flows (see Figure 6-110).

Figure 6-110: Flows


View the message in the Wireshark capture (see Figure 6-111).

Figure 6-111: Wireshark capture


In this example, both the Wireshark capture and the controller interface show the following:
Packet count: 1644
This message was sent from the switch (10.1.1.252) to the controller (192.168.56.11).
Refresh the page on the controller (see Figure 6-112).

Figure 6-112: Flow entries


The updated packet count is shown in the Wireshark capture (1651 packets in this example) (see Figure
6-113).

Figure 6-113: Wireshark capture


74. Stop the Wireshark capture.

Questions
The following questions will help you retain the concepts and information you learned in the preceding
section.
Question 1 : What is the priority of a table miss?
_________________________________________________________________
Question 2 : What is the minimum number of OpenFlow tables an OpenFlow switch may have to be
compliant?
_________________________________________________________________
Question 3 : How many tables does a ProVision switch (3800) have in the OpenFlow pipeline by
default?
_________________________________________________________________
Question 4 : How many tables does a Comware switch (5920) have in the OpenFlow pipeline by
default?
_________________________________________________________________
Question 5: What is the n_buffers field?
_________________________________________________________________
Question 6: Which OpenFlow message does an HP VAN SDN Controller use to ensure that a switch has
completed an operation?
_________________________________________________________________
Question 7: Which two timers determine when a flow entry is removed from the flow table of an
OpenFlow switch?
_________________________________________________________________
Question 8: Which OpenFlow instruction sends matched traffic to another table in the pipeline?
_________________________________________________________________
Question 9 : An SDN application is written to send traffic from Table 200 to Table 100 in the OpenFlow
pipeline of an HP ProVision switch. Will this be accepted by the switch? Why or why not?
_________________________________________________________________
Question 1 answer
The table-miss flow entry has a priority of 0 and a blank match field.
Question 2 answer
An OpenFlow switch must have at least one OpenFlow table to be compliant.
Question 3 answer
HP ProVision switches support three tables by default in the OpenFlow pipeline.
Question 4 answer
HP Comware switches support a single table by default in the OpenFlow pipeline.

Question 5 answer
The n_buffers field specifies the maximum number of packets the switch can buffer when sending packets
to the controller using packet-in messages.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.1, Handshake, page 63.
Available at: http://bit.ly/1Lze7FV
Question 6 answer
Barrier: Barrier request/reply messages are used by the controller to ensure message dependencies have
been met or to receive notifications for completed operations.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1.1, Controller-to-Switch, page
26. Available at: http://bit.ly/1Lze7FV
Question 7 answer
Flow entries are removed from flow tables in two ways, either at the request of the controller or via the
switch flow expiry mechanism.
The switch flow expiry mechanism is run by the switch independently of the controller and is based on
the state and configuration of flow entries. Each flow entry has an idle_timeout and a hard_timeout
associated with it.
The controller may actively remove flow entries from flow tables by sending delete flow table
modification messages (OFPFC_DELETE or OFPFC_DELETE_STRICT).
When a flow entry is removed, either by the controller or the flow expiry mechanism, the switch must
check the flow entrys OFPFF_SEND_FLOW_REM flag. If this flag is set, the switch must send a flow
removed message to the controller. Each flow removed message contains a complete description of the
flow entry, the reason for removal (expiry or delete), the flow entry duration at the time of removal, and
the flow statistics at the time of removal.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 5.5, Flow Removal, page 16.
Available at: http://bit.ly/1Lze7FV
Question 8 answer
The Goto instruction forwards traffic to another OpenFlow table.
Question 9 answer
Traffic can only be directed to tables with a higher number (they cannot go backward). The switch will

reject the flow rule and an error will be generated.

Auxiliary connections
By default, the OpenFlow channel between an OpenFlow switch and an OpenFlow controller is a single
network connection. The OpenFlow channel may also be composed of a main connection and multiple
auxiliary connections. Auxiliary connections are created by the OpenFlow switch and are helpful to
improve the switch processing performance and exploit the parallelism of most switch implementations.
Each connection from the switch to the controller is identified by the switch DPID and an auxiliary ID.
The main connection must have its auxiliary ID set to zero, whereas auxiliary connections must have
nonzero auxiliary IDs and the same DPID. Auxiliary connections must use the same source IP address as
the main connection, but they can use a different transport protocol.
The auxiliary connection should have the same destination IP address and same transport destination port
as the main connection, unless the switch configuration specifies otherwise. The controller must
recognize incoming connections with nonzero auxiliary IDs as auxiliary connections and bind them to the
main connection with the same DPID.

Spanning Tree Protocol and OpenFlow


The OFPC_PORT_BLOCKED bit indicates that a switch protocol outside of OpenFlow, such as 802.1D
STP, will detect topology loops and block ports to prevent packet loops (see Figure 6-114). If this bit is
not set, in most cases, the controller should implement a mechanism to prevent packet loops.

Figure 6-114: STP and OpenFlow


The port state bits represent the state of the physical link or switch protocols outside of OpenFlow. The
OFPPS_LINK_DOWN bit indicates the physical link is not present. The OFPPS_BLOCKED bit
indicates that a switch protocol outside of OpenFlow, such as 802.1D STP, is preventing the use of the
port with OFPP_FLOOD (see Figure 6-115).

Figure 6-115: Spanning Tree and OpenFlow


All port state bits are read-only and cannot be changed by the controller. When the port flags are changed,
the switch sends an OFPT_PORT_STATUS message to notify the controller of the change.

Instructions
In this section, you will continue capturing OpenFlow messages from an HP VAN SDN Controller and HP
switches and comparing the messages with information contained in the OpenFlow specification
document.
You will learn about:
Auxiliary connections
Spanning Tree and OpenFlow interaction
Controller attempted configuration of a nonsupported switch feature

Figure 6-116: Topology and IP addresses for instructions


The following instructions use the IP addresses and topology illustrated in Figure 6-116.
1. Open your saved Wireshark capture from the previous instruction set: Wireshark OpenFlow capture
1.pcapng.
2. Set the Wireshark filter to openflow_v4.
3. Initial OpenFlow messages are the following:
Switch to controller = hello
Controller to switch = hello
Controller to switch = features request
Switch to controller = features reply
Example replies for openflow_v4 are illustrated in Figure 6-117.

Figure 6-117: Switch features reply


We have already discussed the following in the features reply message:
Datapath_id
n_buffers
n_tables
4. What is the auxiliary ID and why is it set to zero, as illustrated in Figure 6-118?

Figure 6-118: Switch features reply


Answer: An auxiliary connection is a second TCP (or TLS) connection from the OpenFlow switch to the
HP VAN SDN Controller. OpenFlow messages can be sent via two channels at the same time to the
controller rather than just using the single primary connection.
This is means that rather than all messages being put into a single channel (primary channel) and arriving
one behind the other, two channels are opened and multiple messages can arrive at the same time
(parallel connections). HP ProVision switches support a single auxiliary connection, but the standard
allows for multiple auxiliary connections.
As an analogy, rather than having a single line (a queue or channel, for example) at a supermarket
checkout, two or multiple lines are opened, allowing for multiple customers to arrive and be helped at the
same time.
OpenFlow specification details
The auxiliary_id field identifies the type of connection from the switch to the controller. The main
connection has this field set to zero, and an auxiliary connection has this field set to a nonzero value.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.1, Handshake, page 63.
Available at: http://bit.ly/1Lze7FV
By default, the OpenFlow channel between an OpenFlow switch and an OpenFlow controller is a single
network connection. The OpenFlow channel may also be composed of a main connection and multiple

auxiliary connections. Auxiliary connections are created by the OpenFlow switch and are helpful to
improve the switch processing performance and exploit the parallelism of most switch implementations.
Each connection from the switch to the controller is identified by the switch DPID and an auxiliary ID.
The main connection must have its auxiliary ID set to zero, whereas auxiliary connection must have a
nonzero auxiliary ID and the same Datapath ID. Auxiliary connections must use the same source IP
address as the main connection, but can use a different transport protocol. For example, auxiliary
connections can use TLS, TCP, Datagram Transport Layer Security (DTLS), or UDP, depending on the
switch configuration. The auxiliary connection should have the same destination IP address and the same
transport destination port as the main connection, unless the switch configuration specifies otherwise. The
controller must recognize incoming connections with nonzero auxiliary IDs as auxiliary connections and
bind them to the main connection with the same Datapath ID.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.3.5, Auxiliary Connections, page
32. Available at: http://bit.ly/1Lze7FV
5. Will the switch assist in creating a loop-free topology (see Figure 6-119)?

Figure 6-119: Switch features reply


Controller-to-switch messages are initiated by the controller and may or may not require a response from
the switch.

Features: The controller may request the identity and the basic capabilities of a switch by sending a
features request; the switch must respond with a features reply that specifies the identity and basic
capabilities of the switch. This is commonly performed upon establishment of the OpenFlow channel.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1.1, Controller-to-switch
messages, pages 26 and 27. Available at: http://bit.ly/1Lze7FV
The capabilities field uses a combination of the following flags:
/* Capabilities supported by the datapath. */
enum ofp_capabilities {
OFPC_FLOW_STATS =1<<0, /* Flow statistics. */
OFPC_TABLE_STATS =1<<1, /* Table statistics. */
OFPC_PORT_STATS =1<<2, /* Port statistics. */
OFPC_GROUP_STATS=1<<3, /* Group statistics. */
OFPC_IP_REASM =1<<5, /* Can reassemble IP fragments. */
OFPC_QUEUE_STATS=1<<6, /* Queue statistics. */
OFPC_PORT_BLOCKED=1<<8 /* Switch will block looping ports. */

The OFPC_PORT_BLOCKED bit indicates that a switch protocol outside of OpenFlow, such as 802.1D
STP, will detect topology loops and block ports to prevent packet loops. In most cases, if this bit is not
set, the controller should implement a mechanism to prevent packet loops.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.1, Controller-to-switch
messages, page 63. Available at: http://bit.ly/1Lze7FV
This can be seen on the HP VAN SDN Controller OpenFlow Monitor when you view the ProVision
switch 1 (P1) summary information illustrated in Figure 6-120.

Figure 6-120: OpenFlow Monitor


6. At the moment, ProVision switch 1 (P1) is connected to Comware switch 1 (C1) using port 7. Enable
port 8 and tag VLAN 30 across port 8 as in the following example. This is in addition to the currently
configured port 7.
P1# config
P1(config)# vlan 30
P1(vlan-30)# tag 8
P1(vlan-30)# interface 8
P1(eth-8)# enable
P1(eth-8)# end
P1#

7. Enable port 8 on Comware Switch 1 (C1):


<C1> system-view
[C1] interface Ten-GigabitEthernet 1/0/8
[C1-Ten-GigabitEthernet1/0/8] port link-mode bridge
[C1-Ten-GigabitEthernet1/0/8] port link-type trunk
[C1-Ten-GigabitEthernet1/0/8] port trunk permit vlan 1 30
[C1-Ten-GigabitEthernet1/0/8] undo shutdown
[C1-Ten-GigabitEthernet1/0/8] quit
[C1]

8. View the STP forwarding state on C1:

Result: All ports are forwarding.


9. View the STP forwarding state on P1:
P1# show spanning-tree
Multiple Spanning Tree (MST) Information
STP Enabled : Yes
Force Version : MSTP-operation
IST Mapped VLANs : 1-4094
Switch MAC Address : 1458d0-f0db80
Switch Priority : 32768
Max Age : 20
Max Hops : 20
Forward Delay : 15

Topology Change Count : 3
Time Since Last Change : 4 mins

CST Root MAC Address : 784859-37a48e
CST Root Priority : 0
CST Root Path Cost : 20000
CST Root Port : 7

IST Regional Root MAC Address : 1458d0-f0db80
IST Regional Root Priority : 32768
IST Regional Root Path Cost : 0
IST Remaining Hops : 20

...<omitted>...

...<omitted>...

Result: Port 8 is blocking.


10. View the ports of ProVision switch 1 (P1) on the HP VAN SDN Controller OpenFlow Monitor page,
as illustrated in Figure 6-121.

Figure 6-121: OpenFlow Monitor


Result: Port 8 is shown as blocked (or may show link down) on the HP VAN SDN Controller.
11. How are blocked ports viewed in OpenFlow on the switch?
P1# show openflow instance vlan30 port-statistics
Number of Ports :3
Port 2: Up
Status
Admin. Status : EnabledFlood : NA

Receive : EnabledForward : Enabled


Packet_in : Enabled
Statistics
Collisions : 0
Rx Packets : 3312Tx Packets : 28863
Rx Bytes : 446757Tx Bytes : 3334911
Rx Dropped : 0Tx Dropped : 0
Rx Errors : 0Tx Errors : 0
Frame Errors : 0
CRC Errors : 0
Overrun Errors : 0
Port 7: Up
Status
Admin. Status :Enabled Flood : NA
Receive : EnabledForward : Enabled
Packet_in : Enabled
Statistics
Collisions : 0
Rx Packets : 52456Tx Packets : 26742
Rx Bytes : 6869828Tx Bytes : 2360886
Rx Dropped : 0Tx Dropped : 0
Rx Errors : 0Tx Errors : 0
Frame Errors : 0
CRC Errors : 0
Overrun Errors : 0
Port 8: Down
Status
Admin. Status : EnabledFlood : NA
Receive : EnabledForward : Enabled
Packet_in : Enabled
Statistics
Collisions : 0
Rx Packets : 801Tx Packets : 33
Rx Bytes : 88251Tx Bytes : 7858

Rx Dropped : 0Tx Dropped : 0


Rx Errors : 0Tx Errors : 0
Frame Errors : 0
CRC Errors : 0
Overrun Errors : 0
P1#

Result: Port 8 is seen as down in the OpenFlow table on the switch.


12. Configure a Wireshark filter of openflow_v4 and view the messages to and from the ProVision switch,
as illustrated in Figure 6-122.

Figure 6-122: OpenFlow initial messages


Result: Initial OpenFlow messages are
Switch to controller = hello
Controller to switch = hello
Controller to switch = features request
Switch to controller = features reply
Controller to switch = set config
Switch to controller = error (in this example)
The next message is a multipart request table features message.
13. The controller sends a multipart request message, as illustrated in Figure 6-123.

Figure 6-123: OpenFlow requests


The controller is requesting the following from the switch:
OFPMP_DESC
OFPMP_PORT_DESC
OFPMP_TABLE_FEATURES
Multipart messages are used to encode requests or replies that potentially carry a large amount of data
and would not always fit in a single OpenFlow message, which is limited to 64 KB. The request or reply
is encoded as a sequence of multipart messages with a specific multipart type and reassembled by the
receiver. Multipart messages are primarily used to request statistics or state information from the switch.
The switch responds with one or more OFPT_MULTIPART_REPLY messages.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.5 page 73. Available at:
http://bit.ly/1Lze7FV
14. In this case, the switch responds with multiple OFPT_MULTIPART_REPLY messages. As Figure 6124 illustrates, this first message is OFPMP_DESC.

Figure 6-124: Description


Result: The switch hardware description, software description, and other information are returned. In
Figure 6-124, software version KA.15.17.007 is shown.
OpenFlow specification
Information about the switch manufacturer, hardware revision, software revision, serial number, and a
description field is available from the OFPMP_DESC multipart request type, as the following example
output illustrates:
/* Body of reply to OFPMP_DESC request. Each entry is a NULL-terminated
* ASCII string. */
struct ofp_desc {
char mfr_desc[DESC_STR_LEN]; /* Manufacturer description. */
char hw_desc[DESC_STR_LEN]; /* Hardware description. */
char sw_desc[DESC_STR_LEN]; /* Software description. */
char serial_num[SERIAL_NUM_LEN]; /* Serial number. */
char dp_desc[DESC_STR_LEN]; /* Human readable description of datapath. */
};
OFP_ASSERT(sizeof(struct ofp_desc) == 1056);

Each entry is ASCII formatted and padded on the right with null bytes (\0). DESC_STR_LEN is 256 and
SERIAL_NUM_LEN is 32. The dp_desc field is a free-form string to describe the datapath for debugging
purposesfor example, switch3 in room 3120. As such, it is not guaranteed to be unique and should
not be used as the primary identifier for the datapathuse the datapath_id field from the switch features
instead.

Note
Source: OpenFlow Switch Specification, Version 1.3.2, section 7.3.5.1 page 76. Available at:
http://bit.ly/1Lze7FV
15. This second message is OFPMP_PORT_DESC, as illustrated in Figure 6-125.

Figure 6-125: Port description


Result: Port information is sent to the controller. Port 7 information is shown in Figure 6-125. This
includes information to indicate if the port is live, blocked, or down. State information and other
information is also provided.
16. The third message is OFPMP_TABLE_FEATURES (see Figure 6-126).

Figure 6-126: OpenFlow table features


Result: In Figure 6-126, Table 100 information is displayed. For example, the GO_TO_TABLE
instruction is supported in this table. The maximum number of rules that this table supports is 1000.
Optional: OpenFlow specification
The OFPMP_TABLE_FEATURES multipart type allows a controller to both query for the capabilities of
existing tables and to optionally ask the switch to reconfigure its tables to match supplied configurations.
In general, the table-feature capabilities represent all possible features of a table. However, some
features may be mutually exclusive and the current capabilities structures do not allow us to represent
such exclusions.
If the OFPMP_TABLE_FEATURES request body is empty, the switch will return an array of struct
ofp_table_features containing the capabilities of the currently configured flow tables.
If the request body contains an array of one or more ofp_table_features structs, the switch will attempt to
change its flow tables to match the requested flow table configuration. This operation configures the
entire pipeline, and the set of flow tables in the pipeline must match the set in the request or an error must
be returned. In particular, if the requested configuration does not contain an ofp_table_features struct for
one or more flow tables that the switch supports, these flow tables are to be removed from the pipeline if
the configuration is successfully set. A successful configuration change will modify the features for all
flow tables in the request. That is, either all the flow tables specified in the request are modified or none
are modified, and the new capabilities for each flow table must be either a superset of or equal to the
requested capabilities. If the flow table configuration is successful, flow entries from flow tables that
have been removed or flow tables that have had their capabilities change between the prior and the new
configuration are removed from the flow table. However, no ofp_flow_removed messages are sent. The
switch then replies with the new configuration. If the switch is unable to set the requested configuration,
an error of type OFPET_TABLE_FEATURES_FAILED is returned with the appropriate error code.

Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 7.3.5.5, 7.3.5.5.1 page 79.
Available at: http://bit.ly/1Lze7FV
17. The controller then programs the flow tables on the switch. Look at the various flow_mod messages in
Figure 6-127. In this example, Table 0 is programmed with a goto Table 100 flow entry:

Figure 6-127: OpenFlow flow programmed

ProVision configuration
Figure 6-128 shows a link aggregation example as configured on an HP ProVision switch.

Figure 6-128: ProVision configuration


How does OpenFlow treat link aggregated interfaces? The OpenFlow 1.3 specification states the
following:
The OpenFlow logical ports are switch defined ports that don't correspond directly to a hardware
interface of the switch. Logical ports are higher level abstractions that may be defined in the switch using
non-OpenFlow methods (e.g., link aggregation groups, tunnels, loopback interfaces).
The specification further states (Section 2): Flow entries may forward to a port. This is usually a
physical port, but it may also be a logical port defined by the switch or a reserved port defined by this
specification. Reserved ports may specify generic forwarding actions such as sending to the controller,
flooding, or forwarding using non-OpenFlow methods, such as normal switch processing, while switchdefined logical ports may specify link aggregation groups, tunnels, or loopback interfaces.
In summary, a link aggregated interface is treated as a logical single interface. Flows are sent to the
aggregated interface and not to the individual ports that form part of the link aggregation. The controller is
unaware if individual physical ports in a link aggregation go down while the logical interface is still up.
Link aggregated interfaces are set up as per traditional forwarding and the traditional load-sharing
algorithms used on the link aggregated interfaces are still used.

ProVision output
As Figure 6-129 illustrates, output of the show lacp command on the HP ProVision switch shows that the
trunks are up. In this example, there are two operation keys: 562 (Trk1) and 563 (Trk2).

Figure 6-129: ProVision output


The command display link-aggregation interface on Comware will display the operation key of a
Comware device.

Controller view: LAG links


Figure 6-130 shows the view on the HP VAN SDN Controller. On the ProVision switch in this example,
the interface number 562 is shown. This equals the operational keys of the link aggregation interface (in
this example).

Figure 6-130: Controller view of LAG links


The controller is once again unaware of the physical ports that form part of the link aggregation, or of
their status (up or down). It is also not aware of the load-sharing algorithm used by the switch.

Instructions for configuring link aggregation

In this section, you will learn to configure link aggregation and see how it affects OpenFlow processing.
Instructions will rely upon the example topography and IP addresses illustrated in Figure 6-131.

Figure 6-131: Example topology and IP addresses for instructions

Instructions
1. Before enabling link aggregation, configure and enable interface Ten-GigabitEthernet1/0/5 on
Comware switches C1 and C2:
C1 configuration:
<C1> system-view
[C1] interface Ten-GigabitEthernet 1/0/5
[C1-Ten-GigabitEthernet1/0/5] port link-mode bridge
[C1-Ten-GigabitEthernet1/0/5] port link-type trunk
[C1-Ten-GigabitEthernet1/0/5] port trunk permit vlan 1 20
[C1-Ten-GigabitEthernet1/0/5] undo shutdown
[C1-Ten-GigabitEthernet1/0/5] quit
[C1]

C2 configuration:
<C2> system-view
[C2] interface Ten-GigabitEthernet 1/0/5

[C2-Ten-GigabitEthernet1/0/5] port link-mode bridge


[C2-Ten-GigabitEthernet1/0/5] port link-type trunk
[C2-Ten-GigabitEthernet1/0/5] port trunk permit vlan 1 20
[C2-Ten-GigabitEthernet1/0/5] undo shutdown
[C2-Ten-GigabitEthernet1/0/5] quit
[C2]

2. View STP information on C2:

Result: Port Ten-GigabitEthernet 1/0/5 is in the discarding state.


3. View the ports of Comware switch 2 (C2) on the HP VAN SDN Controller OpenFlow Monitor (see
Figure 6-132).

Figure 6-132: OpenFlow Monitor


Result: Port 5 (Ten-GigabitEthernet 1/0/5) is in the blocking state.
4. View the ports of ProVision switch 1 (P1), as illustrated in Figure 6-133.

Figure 6-133: OpenFlow Monitor


Result: Port 8 is in the blocking state. This was configured previously.
5. Start a Wireshark capture and set a filter of openflow_v4.port.sate (note that sate is correct; it is not
state) (see Figure 6-134).

Figure 6-134: Wireshark capture


6. Shut down interfaces Ten-GigabitEthernet 1/0/4 and 1/0/7 on Comware switch 1 (C1):
[C1] interface Ten-GigabitEthernet 1/0/4
[C1-Ten-GigabitEthernet1/0/4] shutdown
[C1-Ten-GigabitEthernet1/0/4] quit
[C1] interface Ten-GigabitEthernet 1/0/7
[C1-Ten-GigabitEthernet1/0/7] shutdown

7. View the changes on the HP VAN SDN Controller:


Comware switch C2:

Figure 6-135: OpenFlow Monitor


Result: As Figure 6-135 illustrates, port 4 is down. However, STP has unblocked port 5, which is
now forwarding.
ProVision switch P1:

Figure 6-136: OpenFlow Monitor


Result: As Figure 6-136 illustrates, port 7 is down, but STP has unblocked port 8 which is now
forwarding.
8. View the Wireshark messages.

Figure 6-137: Port status change


Result: Figure 6-137 shows that port 4 is down.

Figure 6-138: Port status change


Result: Figure 6-138 shows that port 7 is down.
The OpenFlow specification states the following about link aggregation:
The OpenFlow logical ports are switch defined ports that do not correspond directly to a hardware
interface of the switch. Logical ports are higher-level abstractions that may be defined in the switch using
non-OpenFlow methods (for example, link aggregation groups, tunnels, and loopback interfaces).
Logical ports may include packet encapsulation and may map to various physical ports. The processing
done by the logical port must be transparent to OpenFlow processing and those ports must interact with
OpenFlow processing like OpenFlow physical ports.
The only differences between physical ports and logical ports are that a packet associated with a logical
port may have an extra metadata field called tunnel-ID associated with it and when a packet received on a
logical port is sent to the controller, both its logical port and its underlying physical port are reported to
the controller.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, section 4.4 page 11. Available at:
http://bit.ly/1Lze7FV

9. Enable link aggregation on ProVision switch 1 (P1):


P1# config
P1(config)# interface 7,8
P1(eth-7-8)# disable
P1(eth-7-8)# exit
P1(config)# trunk 7,8 trk1 lacp
P1(config)# vlan 30
P1(vlan-30)# tag trk1
P1(vlan-30)# exit
P1(config)#

10. Enable link aggregation on Comware switch 2 (C2):


[C2] interface range Ten-GigabitEthernet 1/0/4 Ten-GigabitEthernet 1/0/5
[C2-if-range] default
[C2-if-range] shutdown
[C2-if-range] quit
[C2] interface Bridge-Aggregation 1
[C2-Bridge-Aggregation1] link-aggregation mode dynamic
[C2-Bridge-Aggregation1] quit
[C2] interface range Ten-GigabitEthernet 1/0/4 Ten-GigabitEthernet 1/0/5
[C2-if-range] port link-aggregation group 1
[c2-if-range] quit
[C2] interface Bridge-Aggregation 1
[C2-Bridge-Aggregation1] port link-type trunk
[C2-Bridge-Aggregation1] port trunk permit vlan 1 20
[C2-Bridge-Aggregation1] quit
[C2]

11. Enable link aggregation on Comware switch 1 (C1):


[C1] interface Bridge-Aggregation 1
[C1-Bridge-Aggregation1] link-aggregation mode dynamic
[C1-Bridge-Aggregation1] quit
[C1] interface Bridge-Aggregation 2
[C1-Bridge-Aggregation2] link-aggregation mode dynamic
[C1-Bridge-Aggregation2] quit

[C1] interface range Ten-GigabitEthernet 1/0/4 Ten-GigabitEthernet 1/0/5


[C1-if-range] default
[C1-if-range] port link-aggregation group 1
[C1] interface Bridge-Aggregation 1
[C1-Bridge-Aggregation1] port link-type trunk
[C1-Bridge-Aggregation1] port trunk permit vlan 1 20
[C1-Bridge-Aggregation1] quit
[C1] interface range Ten-GigabitEthernet 1/0/7 Ten-GigabitEthernet 1/0/8
[C1-if-range] default
[C1-if-range] port link-aggregation group 2
[C1] interface Bridge-Aggregation 2
[C1-Bridge-Aggregation1] port link-type trunk
[C1-Bridge-Aggregation1] port trunk permit vlan 1 30
[C1-Bridge-Aggregation1] quit

12. Enable interfaces on Comware switch 2 (C2):


[C2] interface range Ten-GigabitEthernet 1/0/4 Ten-GigabitEthernet 1/0/5
[C2-if-range] undo shutdown
[C2-if-range] quit
[C2]

13. Enable interfaces on ProVision switch 1 (P1):


P1(config)# interface 7,8
P1(eth-7-8)# enable

14. Display the link aggregation on Comware switch 1:


[C1]display link-aggregation summary
Aggregation Interface Type:
BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation
Aggregation Mode: S -- Static, D -- Dynamic
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Actor System ID: 0x8000, 7848-5937-a48e

[C1]

Result: Each bridge aggregation has two selected ports.


15. Display the link aggregation on Comware switch 2:
[C2] display link-aggregation summary
Aggregation Interface Type:
BAGG -- Bridge-Aggregation, RAGG -- Route-Aggregation
Aggregation Mode: S -- Static, D -- Dynamic
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Actor System ID: 0x8000, 7848-5939-2f96

Result: Both ports are selected in the bridge aggregation.


16. View the STP ports on Comware switch 2 (C2):

Result: The bridge aggregation is forwarding.


Result: Both ports are part of Trk1.
17. View the changes on the HP VAN SDN Controller:
18. Output for ProVision switch 1(P1):

Figure 6-139: OpenFlow Monitor


Result: As Figure 6-139 shows, an interface with a port ID of 562 is Trk1. This port is live.
Figure 6-140 shows output for Comware switch 2(C2).

Figure 6-140: OpenFlow Monitor


Result: An interface with Port ID of 972 is shown. This port is live. The rate is shown as rate_other.
19. Restart the Wireshark capture (still using a filter of: openflow_v4.port.sate). See Figure 6-141.

Figure 6-141: Wireshark capture

20. Shut down interface Ten-GigabitEthernet 1/0/4 on Comware switch 1 (C1):


[C1] interface Ten-GigabitEthernet 1/0/4
[C1-Ten-GigabitEthernet1/0/4] shutdown

21. Check the results on Comware switch 2 (C2):


[C2] display interface brief
Brief information on interface(s) under route mode:
.. <omitted>...
Brief information on interface(s) under bridge mode:
Link: ADM - administratively down; Stby - standby
Speed or Duplex: (a)/A - auto; H - half; F - full
Type: A - access; T - trunk; H - hybrid
[C2] display interface brief
Brief information on interface(s) under route mode:
.. <omitted>...
Brief information on interface(s) under bridge mode:
Link: ADM - administratively down; Stby - standby
Speed or Duplex: (a)/A - auto; H - half; F - full
Type: A - access; T - trunk; H - hybrid

Result: BAGG1 has a speed of 10 G


22. Did the controller get a notification? Check Figure 6-142.

Figure 6-142: Speed change


Result: Yes, the switch informs the controller that the interface is up, but the current speed is 10000000.
23. The controller shows the new speed (see Figure 6-143).

Figure 6-143: OpenFlow Monitor


24. Enable interface Ten-GigabitEthernet 1/0/4 on Comware switch 1 (C1).
[C1] interface Ten-GigabitEthernet 1/0/4
[C1-Ten-GigabitEthernet1/0/4] undo shutdown

25. What is the speed on Comware switch 2 (C2)?


[C2] display interface brief
Brief information on interface(s) under route mode:
.. <omitted>...
Link: ADM - administratively down; Stby - standby
Speed or Duplex: (a)/A - auto; H - half; F - full
Type: A - access; T - trunk; H - hybrid

Result: BAGG1 has a speed of 20 G.


26. The controller is informed of the speed change (see Figure 6-144).

Figure 6-144: Speed change


Result: The switch informs the controller that the interface is up, but the current speed is 20000000.
27. Shut down interface Ten-GigabitEthernet 1/0/7 on Comware switch 1 (C1).

[C1-Ten-GigabitEthernet1/0/4] quit
[C1]interface Ten-GigabitEthernet 1/0/7
[C1-Ten-GigabitEthernet1/0/7] shutdown

Wait a few seconds and then enable the interface again.


[C1-Ten-GigabitEthernet1/0/7] undo shutdown
[C1-Ten-GigabitEthernet1/0/7] quit

28. In this case, no Wireshark message was displayed because the ProVision switches did not calculate
the speed change.
Conclusion: The controller does not see a physical interface go down. It is simply notified that the speed
of the link has changed in some cases.

OpenFlow link discovery


The HPN SDN Controller injects packets into the controlled network and observes them to discover links
between OpenFlow instances. Discovered links may be either one of the following two types (see Figure
6-145):
Direct: links that span from one OpenFlow instance port to another, with no intermediate switches.
Multihop: links that span from one OpenFlow instance port to another, traversing intermediate
uncontrolled switches. An uncontrolled switch is a switch that has no defined OpenFlow instances or
that is not connected to the controller (or team) that is attempting to discover the link.

Figure 6-145: OpenFlow link discovery


The HP VAN SDN Controller discovers links and distinguishes link types by injecting two packets into
each port in an OpenFlow instance. These packets have the same Ethernet type (0 8999), but they are

sent to different destination MAC addresses. The content of these packets is proprietary, but generally
includes identification of the OpenFlow instance and the port where the packet originated. The packets
are injected immediately after the switch connects to the controller and periodically thereafter.
Link Layer Discovery Protocol (LLDP) Ethertype:
Rather than using an Ethernet type of 0 8999, previous versions of the controller injected packets with
an Ethernet type of LLDP (0 88cc). By using this Ethernet type for direct link discovery packets, all
direct links would be correctly discovered because LLDP is defined as being below the 802.1Q vlan
tagging layer. This approach is no longer considered an option because LLDP is also used by end-hosts
for other purposes, such as Power over Ethernet (PoE). If the controller injects LLDP packets that reach
end-hosts, these LLDP packets will cause issues with technologies that depend on LLDP for configuration
data, such as Voice over IP (VoIP) phones and wireless access points (among others). In testing, it was
discovered that injection of LLDP packets from the controller for discovery purposes caused IP phones
and PoE devices to malfunction.
The controller instructs switches to send BDDP packets to discover neighboring devices, as illustrated in
Figure 6-146.

Figure 6-146: OpenFlow link discovery


The Controller sends packets to the switches (packet-out) directing them to forward the packets out of
their interfaces. These messages are used by the controller to discover links in the topology.
OpenFlow-enabled switches that receive the BDDP messages forward them to the controller, as
illustrated in Figure 6-147.

Figure 6-147: OpenFlow link discovery


When the controller is configured for hybrid.mode=true, the controller installs a flow rule on every
OpenFlow instance to steal BDDP packets (see Figure 6-148).

Figure 6-148: Flow that steals BDDP packets


Packets which match this flow rule are forwarded to the controller from the OpenFlow instance and port
where they were received.
Using the origin information contained within the received packet, the controller derives the source and
destination of the link that this packet traversed and records a link between the OpenFlow instances. The

link type is derived from the destination MAC address of the packet (direct or multihop), as illustrated in
Figure 6-149.

Figure 6-149: OpenFlow link discovery


If a link is direct, it will be discovered as both direct and multihop from the reporting OpenFlow
instance, but the type of direct has precedence over the type of multihop, so the link is recorded as
direct.

OpenFlow link and node discovery


In this section, you will learn more about how an HP VAN SDN Controller discovers links between
OpenFlow switches using BDDP. You will also see how nodes are discovered with copied ARP
messages.

Figure 6-150: Link and node discovery using OpenFlow


This section also provides instructions for using Mininet and Wireshark for a closer look at how links are
discovered. You will also learn to use the HP VAN SDN Controller OpenFlow Trace tool to capture
packets. Instructions will use the topology and IP addresses in Figure 6-150.

Instructions
1. Disable OpenFlow on Comware switch 2 (C2).
<C2> system-view
[C2] openflow instance 1
[C2-of-inst-1] undo classification
[C2-of-inst-1] active instance

Note
In later releases of the Comware operating system, the command undo active instance is
supported.
2. Disable OpenFlow on ProVision switch 1 (P1).
P1# config
P1(config)# openflow
P1(openflow)# disable

3. Start the Wireshark capture and configure a filter of: openflow_v4 (illustrated in Figure 6-151).

Figure 6-151: Start Wireshark capture


4. Use PuTTy on the Windows VM (Jumphost) to connect to the Mininet server using SSH as follows:
IP address: 192.168.56.55
Port number: 22
Protocol: SSH
5. When prompted, log in with the following credentials:
Username: mininet
Password: mininet
6. Clear Mininet to ensure no previous topologies remain in memory:
mininet@mininet-vm:~$ sudo mn -c

*** Removing excess controllers/ofprotocols/ofdatapaths/pings/noxes


killall controller ofprotocol ofdatapath ping nox_core lt-nox_core ovs-openflowd ovscontroller udpbwtest mnexec ivs 2> /dev/null
...<omitted>...
pkill -9 -f .ssh/mn
rm -f ~/.ssh/mn/*
*** Cleanup complete.
mininet@mininet-vm:~$

7. Start a basic Mininet topology of two switches:


mininet@mininet-vm:~$ sudo mn \
--controller=remote,ip=192.168.56.11 --topo=linear,2 \
--switch=ovsk,protocols=OpenFlow13 --mac

8. Figure 6-152 illustrates the topology created by Mininet.

Figure 6-152: Mininet network consisting of two switches


9. Send a single ping from h1 to h2:
mininet> h1 ping -c 1 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.500 ms
--- 10.0.0.2 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.500/0.500/0.500/0.000 ms
mininet>

10. When hosts are discovered, the topology will look like the topology in Figure 6-153.

Figure 6-153: Mininet network with hosts


11. Stop the Wireshark capture (see Figure 6-154).

Figure 6-154: Stop Wireshark capture


12. Various OpenFlow messages are displayed. We have already discussed the following messages:
Hello
Features request and reply
Multipart request and reply
Error
Flow mod
Barrier request and reply
Port status
These can be seen in the Wireshark capture in Figure 6-155. The controller and the Mininet switches are
negotiating the OpenFlow channel and exchanging information.

Figure 6-155: OpenFlow messages


13. What are packet-out messages?
Answer:
Packet-out: These are used by the controller to send packets out of a specified port on the switch and to
forward packets received via packet-in messages. Packet-out messages must contain a full packet or a
buffer ID that references a packet that is stored in the switch. The message must also contain a list of
actions to be applied in the order they are specified. An empty action list drops the packet.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.1, page 26. Available at:
http://bit.ly/1Lze7FV
14. Find a packet-out message and view the details. Check Figure 6-156.

Figure 6-156: BDDP message


Result: The packet-out message in Figure 6-156 uses an unknown type: 0 8999 and is sent to the
LLDP multicast address.
Find another packet-out message with a destination MAC address of HP and type 0 8999 (see Figure 6157).

Figure 6-157: BDDP message


Result: Figure 6-157 shows a packet-out message with an HP destination MAC address and an
Ethernet type of 0 8999.
The controller is sending packets to the switches (packet-out) and directing them to forward the messages
out of their interfaces. These messages are used by the controller to discover links in the topology. As you
will recall, link discovery works as follows:
The HP VAN SDN Controller injects packets and observes them in the controlled network to discover
links between OpenFlow instances. Discovered links may be either one of the following types:
Direct: links that span from one OpenFlow instance port to another with no intermediate switches
Multihop: links that span from one OpenFlow instance port to another, traversing intermediate
uncontrolled switches; an uncontrolled switch is a switch that does not have OpenFlow instances
defined or that is not connected to the controller (or team) that is attempting to discover the link.
The HP VAN SDN Controller discovers links and distinguishes link types by injecting two packets to
each port in an OpenFlow instance. These packets have the same Ethernet type (0 8999) but are sent to
different destination MAC addresses. The content of these packets is proprietary but generally includes
an identification of the OpenFlow instance and the port where the packet originated. The packets are
injected immediately after the switch connects to the controller and periodically thereafter.
Note
Source:
White
paper:
HPN
SDN
Controller
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04495141.

Link

Discovery:

The controller is directing the switches to send BDDP messages to each other. In the Wireshark captures
shown above, one switch sends two BDDP messages out of its ports to discover attached network
devices. Figure 6-158 illustrates this.

Figure 6-158: Mininet network with hosts


15. The second switch receives the BDDP messages and forwards them to the controller because of the
following flow entry in the OpenFlow table (see Figure 6-159).

Figure 6-159: BDDP flow entry (steal)


16. This can be seen in Wireshark as a packet_in message, as illustrated in Figure 6-160.

Figure 6-160: BDDP message using LLDP multicast


Result: The BDDP message sent by S1 is received by S2 and is forwarded to the HP VAN SDN
Controller.
17. The HP VAN SDN Controller is able to work out that S1 and S2 are directly connected to each other.
If they were not directly connected, but were instead separated by an intermediate switch that had
been LLDP-enabled, the intermediate switch would consume the BDDP message sent to the LLDP
address.
However, a BDDP message is also sent to the HP address. This would be forwarded and received by S2.
The controller would therefore know that S1 and S2 were separated by a non-OpenFlow switch
(multihop link).
In the Mininet topology, however, both BDDP messages are received by S2, as illustrated in Figure 6161.

Figure 6-161: BDDP message using HP MAC address


Result: BDDP message to HP MAC address also received by S2 and forwarded to the HP VAN SDN
Controller.
Note
In some cases, switches may look like they are directly connected even though they are not because
of tunnels created between intermediate devices.
18. The controller will send BDDP packet-out messages to both switches to discover infrastructure links.
The switches will then forward the BDDP packets out of their ports, as illustrated in Figure 6-162.

Figure 6-162: BDDP messages


19. When hosts send ARP or DHCP traffic, this matches flow entries in the switch flow table, as
illustrated in Figure 6-163.

Figure 6-163: ARP flow entry (copy)


20. Find the packet-in message in Wireshark (check Figure 6-164).

Figure 6-164: Packet-in


Result: ARP broadcast is forwarded to the controller. In Figure 6-164, a node (host) with IP address
10.0.0.1 is requesting the MAC address of a host with IP address 10.0.0.2.
The controller is able to learn that host 10.0.0.1 is located on port 1 of switch S1.
21. Exit Mininet:
mininet> exit
*** Stopping 1 controllers
c0
*** Stopping 2 switches
s1 ..s2 ..
...<omitted>...
h1 h2
*** Done
completed in 5867.513 seconds
mininet@mininet-vm:~$

22. To change the trace timeout value, in the HP VAN SDN Controller GUI, click Configurations and then
com.hp.sdn.ctl.of.impl.TraceManager (see Figure 6-165).
Then click Modify.

Figure 6-165: TraceManager configuration options


Change the timeout value and click Apply, as illustrated in Figure 6-166.

Figure 6-166: TraceManager configuration options


23. Click OpenFlow Trace. Click the play button (see Figure 6-167).

Figure 6-167: OpenFlow trace

Note
The controller only captures OpenFlow messages for 10 seconds by default. Rerun the trace if
necessary to capture messages or set the trace timeout to a higher value.
24. Start the basic Mininet topology again:
mininet@mininet-vm:~$ sudo mn \
--controller=remote,ip=192.168.56.11 --topo=linear,2 \
--switch=ovsk,protocols=OpenFlow13 --mac

25. OpenFlow messages are captured. Click a HELLO message and click the magnifying glass to view
details, as shown in Figure 6-168.

Figure 6-168: Messages captured


26. Details of the OpenFlow message are displayed (see Figure 6-169).

Figure 6-169: Hello message


Result: The switch supports version 1.3 of OpenFlow.
27. Find a packet-out message and view the details (see Figure 6-170).

Figure 6-170: Packet-out message


Result: The message type of BDDP is shown.
28. Find a packet-in message and view the details (see Figure 6-171).

Figure 6-171: Packet-in message


Result: The message type of BDDP is shown.
With OpenFlow Trace, you can view OpenFlow messages sent between OpenFlow switches and the HP
VAN SDN Controller without any additional software, such as Wireshark. This may be useful when

connecting to a remote site.


29. Exit Mininet:
mininet> exit
*** Stopping 1 controllers
c0
*** Stopping 2 switches
s1 ..s2 ..
*** Stopping 3 links
*** Stopping 2 hosts
h1 h2
*** Done
completed in 5867.513 seconds
mininet@mininet-vm:~$

30. Enable OpenFlow on ProVision switch 1 (P1) and save your configurations:
P1(openflow)# enable
P1(openflow)# end
P1# wr mem

31. Enable OpenFlow on Comware switch 2 (C2) and save your configurations:
<C2> sys
[C2] openflow instance 1
[C2-of-inst-1] classification vlan 20
[C2-of-inst-1] active instance
[C2-of-inst-1] quit
[C2] save safely force

32. Save the configuration of P2 and C1:


<C1> save safely force
P2# wr mem

Group action and group table


OpenFlow 1.3 introduces a new action: group. The group action is a bit like the output action. However,
rather than indicating the egress port ID, as the output action does, the group action indicates a name or a
group ID (see Figure 6-172).

Figure 6-172: Group action and group table


The group ID corresponds to an entry in the switchs single group table, and this entry indicates how the
switch forwards the traffic. In this way, the switch can execute more complicated forwarding actions such
as flooding traffic over a customized set of ports or forwarding traffic over alternating ports within a set
of redundant links. The group action can even promote greater abstraction for a single port (essentially a
group of one).
The precise way in which the switch forwards traffic that matches a group table entry depends on the
group type and the action buckets. The examples on the next pages illustrate various use cases.

Creating multiple abstract distribution trees


An OpenFlow entry can specify a flood action, which forwards traffic along a distribution tree of ports
with the flood parameter set. However, this approach allows only one distribution tree for
multidestination traffic. An optimized Layer 2 network should permit multipathing of multidestination
traffic over meshes of redundant links.
The group table and the all group type provide one way for achieving this goal (see Figure 6-173).
Each distribution tree is associated with a group, and rather than specify a flood action, the flow entry
specifies a group action for the desired tree.

Figure 6-173: Creating multiple abstract distribution trees


When a packet matches a group entry of this type, the controller executes every action bucket in the list.
However, if an action bucket indicates that the controller should forward the packet on the ingress port,
the controller ignores that action.
In the example shown in the figure, the controller has created two distribution trees, one for VLAN 10 and
one for VLAN 20. The controller could also create different trees based on other criteria. On each
switch, the group table has an all group for each tree. The action buckets for each tree specify an output
action for each of the switchs ports in the associated tree.
Distribution of broadcasts, multicasts, and unicasts with unknown destinations forms the primary use case
for the all type group, but developers can use it for other purposes as well. It provides an action for any
circumstance in which the application needs to clone a packet and forward it over multiple ports.
Note
HP ProVision switches execute group actions in the software. Therefore, you might take a slightly
different approach to programming distribution switches on these switches to maintain fast
hardware processing.

Forwarding on redundant paths (load-balancing)


The HP switches can forward OpenFlow traffic over a link aggregation, which the OpenFlow table treats
like a single port. When possible, you should use link aggregations. Sometimes, however, a switch has
two ports that offer redundant paths to different uplink devices, and a traditional link aggregation is not
possible. The group table provides a solution for this scenario.
In this example, ports 5 and 6 connect to upstream switches that offer an equal cost path to various
destinations, including 10.1.0.0/24, as illustrated in Figure 6-174.

Figure 6-174: Forwarding on redundant paths (load balancing)


The OpenFlow controller creates a group called ActiveActive1, which has two action buckets: One
outputs traffic on port 5 and the other outputs traffic on port 6. The group type is selected because the
designers want the switch to use both links. With this group type, OpenFlow executes just one of the
buckets for any one packet. The bucket it selects depends on the switch, which can use a round-robin
mechanism or a hashing mechanism similar to one used for a link aggregation. HP ProVision switches use
the round-robin mechanism.
Note
Check your HP switch OpenFlow manual for specifications on its maximum number of group table
entries and its maximum number of action buckets per entry.

Forwarding on redundant paths (active/standby)


Even if you do not want to implement load balancing over alternate paths, you should typically set up
group entries for them. If you do not, failover to an alternate link could incur delays:
The OpenFlow switch detects that a port has failed.
The OpenFlow switch informs the controller.
The controller calculates new output ports for flows.
The controller sends flow mod packets to update the OpenFlow switchs paths.
With the group table, the OpenFlow controller determines in advance which ports offer alternate paths
and creates a fast failover group for forwarding traffic on these ports. If a problem occurs with the
active link, the switch can immediately failover to a live link without waiting for instructions (see Figure
6-175).

Figure 6-175: Forwarding on redundant paths (active/standby)


For example, on the switch in Figure 6-175, port 5 offers the best path to various destinations, including
10.1.1.0/24, and port 6 offers an alternate path. Just as in the example on the previous page, the controller
creates a group entry with two action buckets, outputting traffic on port 5 and on port 6. The fast
failover group type, however, always selects the first action bucket with a live output action. It is up
to the switch to determine whether an action bucket is live, which generally means that the output port
is up. Because the switch monitors the live status locally, it can respond to a change more quickly.
(OpenFlow switches might use similar liveness mechanisms for other group types such as the select
type.)
As you see, when the switch needs to execute the group ActiveStandby1 action, it forwards the traffic
on port 5. However, if port 5 goes down, the switch immediately starts forwarding traffic on port 6.

Abstracting a port
Finally, the group table permits developers to abstract port IDs so that the OpenFlow controller can more
easily maintain multiple flow entries with the same forwarding port. Rather than specify an output <port
ID> action in many flow entries, the controller specifies a group <group ID> action. The group ID
indicates an indirect group, which is simply a group with a single action bucket that is always executed
(see Figure 6-176).

Figure 6-176: Abstracting a port


For example, this switch needs to forward traffic destined for many IP addresses to the same next hop
router. The controller creates an indirect group table entry for this router, which indicates the output
port for reaching the router. If the router moves, the controller simply updates the group table entry,
leaving the flow tables intact.
The type of group entry might offer an alternative approach to the two flow table approach that you
looked at in an earlier example. (Of course, the general principle continues to apply. Separating functions
into different tables helps to keep tables concise and stable.)

Summary
In this chapter, you learned about details of the OpenFlow protocol. You learned about OpenFlow
negotiation, communication channels, switch architecture, and a whole lot more. You dived deep and
looked at this from a networking engineers point of view using Wireshark to capture messages.
You learned how to do the following things:
Use Wireshark to interpret OpenFlow messages:
Hello
Feature request and reply
BDDP
Packet in
Packet out
Flow mod
Barrier request and reply
Flow removed

Error
Multipart request and response
Explain how OpenFlow versions are configured and negotiated
View and explain Open vSwitch, Comware and ProVision DPIDs
Explain table miss entries
Explain OpenFlow pipeline processing
Explain ProVision V1, V2 and V3 ASIC OpenFlow pipelines and capabilities
Explain Comware OpenFlow pipelines
Explain packet buffering
Explain OpenFlow auxiliary connections
Explain how STP and OpenFlow interact
Explain link aggregation and OpenFlow interaction

Chapter 7
REST API
EXAM OBJECTIVES
After completing this chapter, you should be able to:
Describe the HP VAN SDN Controller RESTful API
Explain how OpenStack Keystone tokens are retrieved
Use the RSdoc graphical user interface (GUI)
Use cURL to authenticate accounts and receive a token
Use cURL to list datapaths
Manipulate flows using cURL

Assumed knowledge
HP Comware and HP ProVision switch command line interface (CLI)
IP addressing

Introduction
This chapter introduces the HP VAN SDN Controller RESTful application programming interface (API),
which is used by external applications to interact with the controller.
The HP VAN SDN Controller is an extensible platform that supports native applications (sometimes
referred to as modules) and external applications. Native applications are authored in Java or a bytecode compatible language and are deployed on the controller as collections of OSGi bundles.
Native applications use the Java services that are exported and advertised by the controller platform and
by other applications. Native applications can dynamically extend the controller Representational State
Transfer (REST) API surface, extend the controllers graphical user interface (GUI), and integrate with
the controller authentication and authorization framework. Native applications are well suited when the
application needs frequent and low-latency interactions with network devices.
External applications can be developed in any language. They can be deployed on a platform outside the
controller platform or on the same platform as the controller.
External applications interact with the controller using the REST API services that are exported and
advertised by the controller platform and by native applications deployed on the controller. Because
external applications are deployed outside the controller platform, they cannot extend the REST API or

GUI surface of the controller.


External applications are suitable for applications that have relatively infrequent and high-latency control
interactions with network devices and for deploying on a different platform when this is required.

HP VAN SDN Controller APIs


Introduction
The HP VAN SDN Controller supports the following two main types of applications:
Internal applications: Installed via the controller GUI. These applications are typically written in
Java and use the controller Java API. Examples include the HP Network Protector, HP Network
Visualizer, and HP Optimizer SDN applications. These applications provide reactive and proactive
services (see Figure 7-1). In other words, they can react to network events such as a packet-in
message from a switch.
External applications: Installed externally from the controller. These applications are typically
installed on a different server. They can be written in many different programming languages,
including Python. These applications interact with the HP VAN SDN Controller via the REST API.
You will see an example of a REST API application in this chapter. External applications cannot react
to network events such as packet-in messages. They proactively program the network and cannot be
used to write reactive applications.

Figure 7-1: HP VAN SDN Controller APIs

Internal applications
Internal applications, which are also called native applications or modules, have the following
characteristics:
Installed on the controller and deployed as collections of OSGi bundles
Authored in Java or a byte-code compatible language, such as Scala, or Scala DSL
Use services (Java APIs) that are exported and advertised by the platform and by other applications
Export and advertise services (Java APIs) to allow interactions with other applications
Do not use the HP VAN SDN Controller REST APIs. Instead, they extend them by defining their own
RESTful web services

Dynamically extend the controller GUI by adding navigation categories, items, views, and so on.
Integrate with the controller authentication and authorization framework
Integrate with the controller Persistency and Distributed Coordination API
Internal applications are ideal to exert relatively fine-grained, frequent, and low-latency control
interactions with the environment, such as handling packet-in events
Note
For more information about programming internal applications, refer to the HP VAN SDN
Controller 2.5 Programming Guide located at the following URL: http://h20628.www2.hp.com/kmext/kmcsdirect/emr_na-c04647292-3.pdf

External applications
External applications can have the following characteristics:
They are not installed on the controller.
They use the REST APIs that are exported and advertised by the controller and by other applications.
They can be written in any language capable of establishing a secure HTTP connection, such as Java,
C, C++, Python, Ruby, C#, Bash, and so forth.
They can be deployed on a platform of choice outside of the controller platform.
They do not extend the Java APIs, REST APIs, or GUI of the controller.
External, web-based applications are suitable for relatively coarse-grained, infrequent, and high-latency
control interactions with the environment, such as path provisioning and flow inspections.
For example, an application based in the data center might be designed to move five terabytes of data
from one side of the data center over a mesh of switches to the other side of data center without
interrupting real-time applications such as voice and video:
The application can provision a path for five terabytes of data by inspecting the topology and creating
a route through the network for this large amount of data. This path-planning application can take time
to plan the route, to lay down the flows within the network devices, and to specify that the flows will
last for a number of hours or days.
The application can then inform another application that the path has been configured and is ready for
use. The second application can in turn start a backup of the data using the prepared path.
There is no latency requirement for the path-planning application and it therefore does not need to be
running natively on the controller.
This kind of application can be programmed via a REST API.
Note
For detailed REST API information, refer to the HP VAN SDN Controller 2.5 REST API Reference
Guide: http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647295.

Why you need to use the REST API


The REST API is a northbound controller interface used for programming the network or configuring the
HP VAN SDN Controller. The HP VAN SDN Controller does not have a CLI in the traditional sense like
network switches or routers do. The REST API is a programmatic API that is used to configure options
such as controller teaming, or controller backup and restore. It can also be used to retrieve information
about OpenFlow devices and hosts in the network (see Figure 7-2).

Figure 7-2: Why you need to use the REST API


Your options for managing and extracting information from the controller are the following:
Controller GUI: Very basic interface
REST API: Rich, programmatic interface
You could write applications to automate functions like extracting a list of connected switches or
connected hosts and then displaying this information in a different format. This may be a requirement in
large environments where more granular reporting is required than what is available via the HP VAN
SDN Controller GUI.
HPs Intelligent Management Center (IMC) uses the REST API to interact with the HP VAN SDN
Controller.

RESTful Application Program Interface (API)


REST defines a set of architectural principles by which web services are designed. (Figure 7-3 lists
several facts about REST.) REST focuses on a systems resources, including how resource states are
addressed and transferred over HTTP by a wide range of clients written in different languages.
REST is a simple way to organize interactions between independent systems. It allows for interaction
with minimal overhead between clients and servers. REST has less overhead than comparable protocols
such as Simple Object Access Protocol (SOAP).
The developers of the HP SDN Controller chose REST because of its simplicity, scalability, and
interoperability. Many cloud services such as Twitter, Netflix, Google, and eBay use REST for these
reasons.

Figure 7-3: RESTful API


It is important to realize that REST is stateless. This is one of the core concepts that enable scalability in
RESTful APIs. There are various other HTTP mechanisms available to ensure that the statelessness
works.
Concrete implementation of a RESTful web service follows the following four basic design principles:
Use HTTP methods explicitly
Be stateless
Expose directory structure-like URIs
Transfer Extensible Markup Language (XML), JavaScript Object Notation (JSON), or both
One of the important characteristics of a RESTful web service is the explicit use of HTTP. HTTP GET,
for example, is defined as a data-producing method intended to be used by a client application to retrieve
a resource, to fetch data from a web server, or to execute a query with the expectation that the web server
will look for and respond with a set of matching resources.
This basic REST design principle establishes a one-to-one mapping between create, read, update, and
delete (CRUD) operations and HTTP methods. According to this mapping, you would use REST in the
following ways:
To create a resource, use POST.
To retrieve or read a resource, use GET.
To change the state of a resource or to update it, use PUT.
To remove or delete a resource, use DELETE.
Internal applications do not make use of the HP VAN SDN Controllers REST API. They extend it by
defining their own RESTful web services. Internal applications make use of the business services (Java
APIs) published by the controller.
Note
To
learn
more
about
REST
http://en.wikipedia.org/wiki/Representational_state_transfer.

SDN Controller REST API security

concepts,

see:

The HP VAN SDN Controller uses OpenStack Keystone to provide token-based authentication (see
Figure 7-4).

Figure 7-4: HP VAN SDN Controller REST API security


This security mechanism:
Provides user authentication
Completely isolates the security mechanism from the underlying REST API
Exposes a REST API to allow any authentication server that implements this REST API to be hosted
elsewhere (outside the SDN controller)
This security mechanism does not:
Provide authorization; internal applications can be written by developers to provide authorization
functions
Support filtering functions such as blacklisting or rate limiting
To achieve the isolation of security aspects from the API, authentication information is encapsulated by a
token that a user receives by presenting his or her credentials to an authentication server. The user then
uses this token (via the RESTful API header X-Auth-Token) in any API call that requires authentication.
The token is validated by an authentication filter that fronts the requested API resource.
Upon successful authentication, requests are forwarded to the RESTful APIs with the authentication
information such as the following:
User ID
User name

User roles
Expiration date
Upon unsuccessful authentication (caused by either no token or an invalid token), it is up to the
application to deny or allow access to its resource. This flexibility allows the application to implement
its own authorization mechanism, such as access control list (ACL)-based authentication. It can even
allow anonymous operations on certain resources.
The REST APIs need to be secure. Transport Layer Security (TLS) is used to secure the connection and a
token-based authentication mechanism is used to secure the API. The mechanism used to secure the APIs
is OpenStack Keystone.
The SDN Controller is shipped with OpenStack Keystone and requires the OpenStack Keystone version 2
API. This is a separate piece of software from the core controller software. Every time an API call is
made, the API call is authenticated by Keystone using a token. This token can be reused for different API
calls, but every call needs to be authenticated. The token expires after 24 hours.
The flow of token-based authentication in the HP VAN SDN Controller can be summarized as illustrated
in Figure 7-4.
The SDN appliance in this figure represents the HP SDN Controller, which has a Keystone service
embedded. An external Keystone server could also be used. This is represented by the External
Authentication Server box in the figure. An external server could be used in an enterprise environment
where a customer has a separate, external authentication server. Keystone supports Lightweight Directory
Access Protocol (LDAP), so the external server could also be integrated with Microsoft Active Directory
(AD). Here is how authentication works:
1. The API client presents credentials (username/password) to the X-Auth-Token REST API.
2. Authentication is performed by the authentication server. The HP VAN SDN Controller supports a
local Keystone-based authentication server, but the authentication server can also be hosted
elsewhere by the customer (and it can be integrated with an enterprise directory such as LDAP), as
long as it implements the X-Auth-Token REST API. The external authentication server use-case is
shown by the dotted-line interactions in Figure 7-4.
3. The authentication server returns the token to the API client.
4. The API client includes this token in the X-Auth-Token header when it makes a request to the HP
VAN SDN Controllers RESTful API.
5. The token is intercepted by the authentication filter (servlet filter).
6. The authentication filter validates the token with the authentication server via a different X-AuthToken REST API.
7. The authentication filter returns the validation status back to the REST API.
8. If the validation is unsuccessful (there is no token or an invalid token), then the HP VAN SDN
Controller returns status 401 (Unauthorized) back to the API client.
9. If the validation is successful, then the API clients HP VAN SDN Controller REST API request is
invoked and the business logic related to the request is executed.
To isolate services and applications from Keystone specifics, two APIs that are in charge of providing
authentication services (X-Auth-Token REST APIs) are published:

Public API
1. Create token. This accepts username/password credentials and returns back a unique token with some
expiration.

Service API
1. Revoke token: This revokes a given token.
2. Validate token: This validates a given token and returns back the appropriate principals information.
Authentication services have been split into these two APIs to limit sensitive services (via the
service API) to only authorized clients.

RSdoc discovery
The HP VAN SDN Controller REST API documentation is accessible from a web browser through the
controller RSdoc API explorer (see Figure 7-5) and in PDF format in the HP SDN information library.

Figure 7-5: RSdoc discovery

Note
HP SDN information library: http://www.hp.com/go/sdn/infolib
RSdoc is semiautomated interactive RESTful API documentation. It offers a useful way to interact with
REST APIs.
To view RSdoc information, navigate to https://ControllerIPAddress:8443/api where
ControllerIPAddress is the IP address of the HP VAN SDN Controller.
RSdoc is useful as an API online documentation tool and helps you learn the HP VAN SDN Controller
APIs. This provides a catalog of all the REST APIs on the SDN controller.

Note
Although the RSdoc API explorer interacts directly with the controller REST API, RSdoc is not
intended as a management or configuration interface. Use caution when using the Try it out! button
for POST or PUT methods because this action can result in changes to your current controller
environment.

RSdoc discoverydatapaths
In Figure 7-6, information about the /datapaths API is displayedimplementation information,
parameters, and other useful information, for example.
Clicking the Try it out! button allows you to test this functionality.

Figure 7-6: RSdoc discoverydatapaths

RSdoc discoveryauthentication
In Figure 7-7, an error response of 401 is shown. This is because authentication has failed.
To ensure scalability, REST does not provide detailed error information, but rather responds with codes
such as 401.

Figure 7-7: RSdoc discoveryauthentication


Values in the 200 code range (2XX) mean success. Values in the 400 code range (4XX) mean an error
occurred (bad request). Your JSON code format, for example, may be incorrect. Codes in the 500 (5XX)
range mean a server side error.
Refer to the HP VAN SDN Controller REST API guide for specific response codes for individual REST
APIs.
Following are some example response codes:
Normal: OK (200)
Error: Not Found (404), Service Unavailable (503)
Note
HP
VAN
SDN
Controller
2.5
REST
API
Reference
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647295

Guide:

Retrieve a token via RSdoc


To get an authorization token using RSdoc, do the following:
1. Open a browser at https://<sdn controller address>:8443/api, where sdn controller address is the IP
address for your controller.
2. Click /auth, then click POST. The /auth API is displayed.
3. For the login parameter, use JSON encoding to enter a domain, user name, and password. This
example uses the following default values for user, password, and domain: {"login":

{"user":"sdn","password":"skyline","domain":"sdn"}}
4. Click Try it out! (see Figure 7-8).

Figure 7-8: Retrieve a token via RSdoc


A 200 response code should be received to indicate successful execution of the command, as illustrated
in Figure 7-9.
The received token can then be copied and used for authentication of REST API calls.

Figure 7-9: Retrieve token via RSdoc

Paste token and click Explore


The token received can now be pasted into the X-Auth-Token box within RSdoc and can then be used for
subsequent API calls. The token is valid for 24 hours. Figure 7-10 displays the location of the X-AuthToken box.

Figure 7-10: Paste token and click Explore

REST API call successful

The datapaths API call will now be successful (as illustrated in Figure 7-11) because token information
has been sent correctly.

Figure 7-11: REST API call is successful

REST API response


Information regarding /datapaths is displayed in RSdoc in a similar way to the way cURL or a
programming language like Python that is leveraging the REST API would be displayed. Figure 7-12
illustrates this.

Figure 7-12: REST API response

REST API authentication


cURL is a command line tool for transferring data using various protocols. This allows for the sending of
files via the CLI using uniform resource locator (URL) syntax, as illustrated in Figure 7-13.

Figure 7-13: REST API authentication


However, before any data can be retrieved from the HP VAN SDN Controller, a token is required. Use the
following command to request a token:
curl --noproxy controller_ip -X POST --fail -ksSfL --url
"https://controller_ip:8443/sdn/v2.0/auth" -H "Content-Type:
application/json" --data-binary '{"login": {"domain":
"domain","user": "user","password": "password"}}'

Note
The cURL options are shown here for completeness. You do not need to learn these.

cURL options
--noproxy <no-proxy-list>

This option provides a comma-separated list of hosts that do not use a proxy, if one is specified. The only
wildcard is a single asterisk (*) character, which matches all hosts and effectively disables the proxy.
Each name in this list is matched as either a domain that contains the hostname or the hostname itself. For
example, local.com would match local.com, local.com:80, and www.local.com, but not match
www.notlocal.com.
-X, --request <command>

(HTTP) This option specifies a custom request method to use when communicating with the HTTP server.
The specified request method will be used instead of the method otherwise used (which is GET by
default). Read the HTTP 1.1 specification for details and explanations. Common additional HTTP
requests include PUT and DELETE, but related technologies like web-distributed authoring and
versioning (WebDAV) offers PROPFIND, COPY, MOVE, and others.
-s, --silent

This option specifies silent or quiet mode. It does not show a progress meter or error messages. It makes
cURL mute. It will still output the data you ask for, potentially even to the terminal/stdout unless you
redirect it.
-k, --insecure

(SSL) This option explicitly allows cURL to perform insecure SSL connections and transfers. All SSL
connections are attempted to be made secure by using the CA certificate bundle installed by default. This
makes all connections considered insecure fail unless -k, --insecure is used.
--url <URL>

This option allows you to specify a URL to fetch. It is mostly handy when you want to specify URLs in a
configuration file.
-H, --header <header>

(HTTP) This option provides an extra header to use when getting a web page. You may specify any
number of extra headers. Note that if you should add a custom header that has the same name as one of the
internal ones cURL would use, your externally set header will be used instead of the internal one. This
allows you to make even trickier stuff than cURL would normally allow you to do. You should not replace
internally set headers without knowing perfectly well what you are doing. Remove an internal header by
giving a replacement header without content on the right side of the colon, as in the following: -H
Host:. If you send the custom header with no-value, then its header must be terminated with a
semicolon, such as -H "X-Custom-Header;" to send "X-Custom-Header:".
cURL will make sure that each header you add or replace is sent with the proper end-of-line marker, you
should thus not add this marker as a part of the header content: do not add new lines or carriage returns,
they will only mess things up for you.
-d, --data <data>

(HTTP) This option sends the specified data in a POST request to the HTTP server in the same way that a
browser does when a user has filled in an HTML form and presses the submit button. This will cause
cURL to pass the data to the server using the following content-type: application/x-www-formurlencoded. Compare to -F, --form.
--data-binary <data>

(HTTP) This option posts data exactly as specified with no extra processing whatsoever.
If you start the data with the symbol @, the rest should be a filename. Data is posted in a manner similar
to the manner in which --data ascii posts data, except that new lines and carriage returns are preserved
and conversions are never done.
If this option is used several times, the ones following the first will append data as described in -d, -data.
Note
For
more
information
about
http://curl.haxx.se/docs/manpage.html

cURL,

visit:

http://curl.haxx.se

and

Example: Retrieving a token via cURL


In the following example, a username of sdn and password of skyline is used (see Figure 7-14):
~$ curl --noproxy 192.168.56.31 -X POST --fail -ksSfL --url
"https://192.168.56.31:8443/sdn/v2.0/auth" -H "Content-Type:application/json" --databinary '{"login":{"user":"sdn","password":"skyline","domain":"sdn"}}'

{"record":
{"token":"ccf1e5aedb6d4ae19f1480c55907d970","expiration":1437557415000,"expirationDate":"20
07-22 05-30-15
-0400","userId":"9c081cbe3eeb4dbab658090bb70d08f0","userName":"sdn","domainId":"118c46e61b4
["sdn-user","sdn-admin"]}}sdn@sdn-ctl:~/scripts$

Figure 7-14: Exampleretrieving a token via cURL


The token returned by the controller in this example is this: ccf1e5aedb6d4ae19f1480c55907d970.
This would be used in subsequent REST API calls to create a controller team, back up a controller, and
so forth.

Use cURL to query the controller REST API


The token received from the controller can now be used to query information on the controllerfor
example, retrieving a list of registered OpenFlow switches, as Figure 7-15 illustrates.

Figure 7-15: Use cURL to query the controller REST API


Use the following command to do this:
~$ curl -sk -H "X-Auth-Token:ccf1e5aedb6d4ae19f1480c55907d970"
https://192.168.56.11:8443/sdn/v2.0/of/datapaths

Note
Tokens are valid for 24 hours only. You would need to replace the token in the preceding command
with the token the controller has allocated.
The resulting output displays. However, the output is not formatted as clearly as it is using the REST API.
Further, REST information is compacted:
~$ curl -sk -H "X-Auth-Token:ccf1e5aedb6d4ae19f1480c55907d970"
https://192.168.56.11:8443/sdn/v2.0/of/datapaths

{"datapaths":
[{"dpid":"00:00:00:00:00:00:00:01","negotiated_version":"1.0.0","ready":"2015-0722T08:45:03.765Z","last_message":"2015-0722T08:45:05.820Z","num_buffers":256,"num_tables":254,"mfr":"Nicira, Inc.","hw":"Open
vSwitch","sw":"2.0.2","serial":"None","desc":"None","device_ip":"192.168.56.55","device_por
["flow_stats","table_stats","port_stats","queue_stats","arp_match_ip"]},
{"dpid":"00:00:00:00:00:00:00:02","negotiated_version":"1.0.0","ready":"2015-0722T08:45:03.800Z","last_message":"2015-0722T08:45:05.872Z","num_buffers":256,"num_tables":254,"mfr":"Nicira, Inc.","hw":"Open
vSwitch","sw":"2.0.2","serial":"None","desc":"None","device_ip":"19...<output omitted>...

JSON is used to format the text in a human readable format. A developer could use the JSON tools
available with Python or other languages to format the output in an easy to read format.
The data returned by the controller can be piped as follows:
~$ curl -sk -H "X-Auth-Token:ccf1e5aedb6d4ae19f1480c55907d970"
https://192.168.56.11:8443/sdn/v2.0/of/datapaths|python-mjson.tool|more
{

"datapaths": [
{
"capabilities": [
"flow_stats",
"table_stats",
"port_stats",
"queue_stats",
"arp_match_ip"
],
"desc": "None",
"device_ip": "192.168.56.55",
"device_port": 35012,
"dpid": "00:00:00:00:00:00:00:01",
"hw": "Open vSwitch",
"last_message": "2015-07-22T08:49:24.180Z",
"mfr": "Nicira, Inc.",
"negotiated_version": "1.0.0",
"num_buffers": 256,
"num_tables": 254,
"ready": "2015-07-22T08:45:03.765Z",
"serial": "None",
"sw": "2.0.2"
--More--

Result: It is much easier to read the returned information.

Questions: cURL commands


The following questions will help you understand and retain the information and concepts you have
learned in this chapter so far.

Figure 7-16: QuestionscURL commands


Question 1:
What will be returned by the commands in Figure 7-16?
Answer:
Command 1
Assuming that the authentication succeeds and that the HP VAN SDN Controller is available at IP address
192.168.56.7, the controller will return a token in reply to this cURL command.
Example:
~$curl -sk -H 'Content-Type:application/json' -d '{"login":
{"user":"sdn","password":"skyline","domain":"sdn"}}'
https://192.168.56.7:8443/sdn/v2.0/auth

{"record":
{"token":"721e0e0cad654d8d96229d7766a4e608","expiration":1398237956000,"expirationDate":"20
04-23 00-25-56
-0700","userId":"42bd79abd226408abbe928c1c42d7847","userName":"sdn","domainId":"1ef2a1bbeae
sdn@sdnctl:~/bin$

Command 2
Assuming that the HP VAN SDN Controller is available at IP address 192.168.56.7, the controller will
return an error because no token has been presented in the API call. An X-Auth-Token must be presented
with this API call.
Incorrect format:
sdn@sdnctl:~/bin$ curl -sk https://192.168.56.7:8443/sdn/v2.0/of/datapaths
{"error":"com.hp.api.auth.AuthenticationException","message":"Authentication
required"}
sdn@sdnctl:~/bin$

Correct format:
~$ curl -sk -H "X-Auth-Token:ccf1e5aedb6d4ae19f1480c55907d970"

https://192.168.56.31:8443/sdn/v2.0/of/datapaths

{"datapaths":
[{"dpid":"00:00:00:00:00:00:00:01","negotiated_version":"1.0.0","ready":"2015-0722T08:45:03.765Z","last_message":"2015-0722T08:52:49.178Z","num_buffers":256,"num_tables":254,"mfr":"Nicira, Inc.","hw":"Open
vSwitch","sw":"2.0.2","serial":"None","desc":"None","device_ip":"192.168.56.55","device_por
["flow_stats","table_stats","port_stats","queue_stats","arp_match_ip"]},
{"dpid":"00:00:00:00:00:00:00:02","negotiated_version":"1.0.0","ready":"2015-0722T08:45:03.800Z","last_message":"2015-0722T08:52:49.178Z","num_buffers":256,"num_tables":254,"mfr":"Nicira, Inc.","hw":"Open
vSwitch","sw":"2.0.2","serial":"None","desc":"None","device_ip":"192.168.56.55","device_por
["flow_stats","table_stats","port_stats","queue_stats","arp_match_ip"]},
{"dpid":"00:00:00:00:00:00:00:03","negotiated_version":"1.0.0","ready":"2015-0722T08:45:03.868Z","last_message":"2015-0722T08:52:49.179Z","num_buffers":256,"num_tables":254,"mfr":"Nicira, Inc.","hw":"Open
vSwitch","sw":"2.0.2","serial":"None","desc":"None","device_ip":"192.168.56.55","device_por
["flow_stats","table_stats","port_stats","queue_stats","arp_match_ip"]},
{"dpid":"00:00:00:00:00:00:00:04","negotiated_version":"1.0.0","ready":"2015-0722T08:45:03.954Z","last_message":"2015-0722T08:52:49.179Z","num_buffers":256,"num_tables":254,"mfr":"Nicira, ...<output omitted>...

REST API basics and RSdoc


In this section, you will learn to use the controller REST API and RSdoc to extract information from the
controller about the network. You will also learn to use an external REST API application.
You will start by authenticating the sdn user and retrieving a token to use for API calls. This will be done
using the RSdoc GUI. You will also explore basic RSdoc features and functionality.
cURL will then be used to authenticate the sdn user, retrieve a token, and list datapaths registered with the
HP VAN SDN Controller.
The examples and instructions in this section will use the topology and IP addresses illustrated in Figure
7-17.

Figure 7-17: Example topology for REST API

The three switches in the topology (C2, P1, and P2) are configured with OpenFlow. Comware switch 1
(C1) does not have OpenFlow enabled. There are also three HP VAN SDN Controllers, including
192.168.56.11, which is shown in Figure 7-17.
We will now discuss the REST API and then use RSdoc to interact with the HP VAN SDN Controller
RESTful API. Again, RSdoc is a graphical, semiautomated, interactive RESTful API interface providing
RESTful API documentation. It offers a useful way to interact with and learn the HP VAN SDN Controller
RESTful APIs.

Questions
Question 1: How do you connect to a switch or a router in a traditional environment to make changes?
Question 1 answer
In a traditional environment, connections are often made using a console cable, telnet, Secure Shell
(SSH), and IMC. Figure 7-18 illustrates an example connection using SSH.

Figure 7-18: SSH to switch


The interface used for configuration would be something like a ProVision or Comware CLI. Following is
an example:
<C2> system-view
[C2]ospf
[C2-ospf-1]area 0
[C2-ospf-1-area-0.0.0.0]network 0.0.0.0 255.255.255.255
[C2-ospf-1-area-0.0.0.0]end
^
% Unrecognized command found at '^' position.

[C2-ospf-1-area-0.0.0.0]quit
[C2-ospf-1]

Note
When you type an unrecognized command like the command in the above example, the CLI informs
you.
The REST API is one of the popular interfaces used for programmatic configuration of devices today
because it has less overhead than comparable protocols, including SOAP.
REST has gained popularity in recent years as a distributed, scalable programming interface. Many cloud
services such as Twitter, Netflix, Google, and eBay use REST for these reasons. REST provides a
modern, programmable interface and a lightweight data model specification that is simple, remote,
secure, and extensible.
REST is used in multiple HP products including HP ProLiant Gen9 server, IMC, OneView, and the HP
VAN SDN Controller.
An application developer can write an application in many different languages, including Python, PHP,
Perl, C, and many others, and can then use the RESTful API on the controller to make changes or retrieve
information from the controller (see Figure 7-19).

Figure 7-19: REST to controller


Question 2: Why do you need to use the RESTful API?
Question 2 answer
The HP VAN SDN Controller does not have a CLI in the way that a router or a switch has. The RESTful
API is in the external interface for making changes to the controller. This can be used, for example, to
configure teaming, retrieve a list of connected OpenFlow switches, program flows, or back up the
controller.
Up until this point, you have been learning about internal applications that are installed on the controller

via the controller GUI. These applications use the Java API to interact with the HP VAN SDN Controller.
Example internal applications include the HP Network Protector, HP Network Visualizer, and the HP
Optimizer (see Figure 7-20). Example external applications include Hyperglance or HP IMC.

Figure 7-20: Internal applications


External (RESTful API) applications are not installed via the controller GUI and are typically installed
on an external server (see Figure 7-21).

Figure 7-21: External applications

Instructions
1. In the same way that there are CLI command reference guides for switches and routers, there is a
REST API reference guide for the controller. This provides details of the REST API if you are
interested in learning about it.

Note
The HP VAN SDN Controller 2.5 REST API Reference Guide is available at:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647295
2. As discussed, you can also use RSdoc to interact with the controller RESTful API (see Figure 7-22).
Use Google Chrome on the Windows Jumphost to navigate to: https://192.168.56.11:8443/api

Figure 7-22: RSdoc GUI

Note
Make sure you have selected the HP VAN SDN Controller API V2.2 in the RSdoc drop-down.
Otherwise you may be viewing the REST APIs of other applications.
3. The HP VAN SDN Controller REST API requires authentication of requests by using a token. The
token is valid for 24 hours.
To retrieve a token, you need to be authenticated. Select /auth in RSdoc and then POST (see Figure 723).

Figure 7-23: RSdoc /auth


4. Enter the following login information in the login box:
{"login":{"user":"sdn","password":"skyline","domain":"sdn"}}

This will send a username and password to the controller and retrieve a token.
Click the Try it out! button (see Figure 7-24).

Figure 7-24: Authentication information


5. Copy the token from the Response Body and then paste the token (without the inverted commas) into
the X-Auth-Token box at the top of the page (see Figure 7-25). Then click the Explore button.

Figure 7-25: Paste token into RSdoc


Result: The RSdoc page will refresh when the token is accepted. In the background, the token sent from
RSdoc to the controller is authenticated.
6. Select /datapaths (scroll to the end of the RSdoc page to find this) and then click GET
/of/datapaths.
Click the Try it out! button (see Figure 7-26).

Figure 7-26: /datapaths URL


7. This should now return a response code of 200 and should display the datapath ID (DPID)
information. This shows a list of registered OpenFlow switches. In Figure 7-27, Comware switch 2
(C2) information is displayed.

Figure 7-27: /datapaths success

Note
Values in the 200 code range (2XX) mean success. Values in the 400 code range (4XX) mean an
error occurred (bad request). Codes in the 500 (5XX) range mean server side error.
8. Check if the controller is part of a team. Select /team and then click GET /team.
Then click the Try it out! button (see Figure 7-28).

Figure 7-28: GET /team


9. A response of { } is returned, as illustrated in Figure 7-29. This means that the controller is not part
of a team.

Figure 7-29: Controller is not part of a team

Questions
Question 1: Which API is used by internal applications?
_________________________________________________________________
Question 2: Are REST API applications installed via the controller GUI?
_________________________________________________________________
Question 3: Can REST applications provide reactive functionality?
_________________________________________________________________
Question 4: Can you write RESTful applications in Python?
_________________________________________________________________
Question 5: What is RSdoc?
_________________________________________________________________
Question 1 answer
The Java API is used by internal applications. The REST API is used by external applications.
Question 2 answer
REST API applications are not installed on the controller. They are typically installed on external
servers. Even if a REST API application were installed on the same Ubuntu server as the HP VAN SDN
Controller, it would still be deemed to be external to the controller software and would use the REST
API to interact with the controller.
Question 3 answer
External, RESTful applications cannot react to OpenFlow messages such as packet-in messages from the
HP VAN SDN Controller. They can also not reprogram flows due to link down events from the HP VAN
SDN Controller received via OpenFlow. Listener applications that are subscribed to controller events
need to be written in Java and installed on the controller as internal applications.

Note
A RESTful application could use Simple Network Management Protocol (SNMP) to react to events
directly from switches.
Question 4 answer
RESTful applications can be written in any language capable of establishing a secure HTTP connection,
such as Java, C, C++, Python, Ruby, C#, Bash, and so forth.
Question 5 answer
RSdoc is semiautomated interactive RESTful API documentation. It offers a useful way to interact with
REST APIs.

Instructions for using external applications and cURL


In this section, you will learn to use both an external REST API application and scripts to interact with
the REST API. The script uses cURL to retrieve information from the HP VAN SDN Controller.
Note
RSdoc interacts with the same HP VAN SDN Controller REST API as cURL or other external
applications do. RSdoc is a nice way to learn the REST API, but should not be used by applications
that should instead interact directly with the HP VAN SDN Controller REST API.
1. Open another tab in Chrome and browse to 192.168.56.54 and log in with the following credentials:
Username: sdn
Password: skyline
2. This application (SDN Toolkit) is an external application running on a separate server from the HP
VAN SDN Controller. The application uses the REST API to interact with the controller. Click Add
Controllers to add a new controller, as illustrated in Figure 7-30.

Figure 7-30: Add Controller


3. Fill in the following details and click Save (see Figure 7-31).
Name of Controller: Controller1

IP Address: 192.168.56.11
Username: sdn
Password: skyline
Domain: sdn

Figure 7-31: Add Controller details


4. Select Manage Switches and then select Controller1 (see Figure 7-32).

Figure 7-32: Manage Switches


5. Switches registered with the Controller are shown, as illustrated in Figure 7-33. Click View Ports
on the ProVision switch P1 to view OpenFlow enabled ports.

Figure 7-33: Registered switches


Result: The application has used the HP VAN SDN Controller REST API to retrieve a list of registered
OpenFlow switches. Information about the switches, including the hostname if available via OpenFlow,
is also shown.
6. The OpenFlow-enabled ports on the switch are shown, as illustrated in Figure 7-34.

Figure 7-34: ProVision switch 1 (P1) OpenFlow ports


Result: The switch port information was retrieved from the HP VAN SDN Controller using the REST
API. In Figure 7-34, port 2 and Trk 1 are shown as being part of an OpenFlow instance. The port states
are live, and speed information is shown for the physical interface.
7. View the port information of the Comware switch (click Manage Switches, select Controller1, and
click View Ports). Figure 7-35 illustrates the result.

Figure 7-35: Comware switch 2 (C2) OpenFlow ports


8. Use PuTTY to SSH to the Mininet server from the Jumphost:
IP address: 192.168.56.55
Username: mininet
Password: mininet
9. Clean up Mininet:
mininet@mininet-vm:~$ sudo mn -c

10. Start a Mininet topology of 4 linear hosts:


sudo mn --controller=remote,ip=192.168.56.11 --topo=linear,4 \
--switch=ovsk,protocols=OpenFlow13 --mac

11. View the switches available in the SDN Toolkit application. (Click Manage Switches and select
Controller1, as shown in Figure 7-36.)

Figure 7-36: Registered switches


Result: Both Mininet and HP switches are displayed.
12. In Mininet ping all hosts:

mininet>pingall

Result: Pings succeed.


13. Send pings from h1 to h2:
mininet> h1 ping h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.297 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.056 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.052 ms

Result: Pings succeed.


14. In the SDN Toolkit application, click Manage Nodes and select your controller (see Figure 7-37).

Figure 7-37: Discovered hosts


Result: Discovered hosts are displayed.
15. Block host1 (10.0.0.1) by clicking the Block Host button and then clicking OK (see Figure 7-38).

Figure 7-38: Block a host


Results: The host is shown as blocked and pings fail in Mininet (see Figure 7-39).

Figure 7-39: Host is blocked


mininet> h1 ping h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.

16. View the added flow using the HP VAN SDN Controller GUI by navigating to
https://192.168.56.11:8443/sdn/ui.
Click OpenFlow Monitor, then select switch 00:00:00:00:00:00:00:01 and click Flows to view the
switch flow table, as illustrated in Figure 7-40.

Figure 7-40: New flow


Result: The application communicated with the HP VAN SDN Controller via the REST API and
requested that a flow be added. The controller in turn added a flow entry to the switch using OpenFlow.
17. Exit Mininet:
mininet>exit

18. cURL is a command line tool for transferring data using various protocols. This allows for the
sending of files via the CLI using URL syntax.
More information
From the cURL website: cURL is used in command lines or scripts to transfer data. It is also used
in cars, television sets, routers, printers, audio equipment, mobile phones, tablets, set-top boxes,
media players, and it is the Internet transfer backbone for thousands of software applications totally
affecting more than one billion users.
For more information about cURL, visit http://curl.haxx.se.
19. Open the get-token script using Notepad++ (right click on the file and select Edit with Notepad++)
(see Figure 7-41).
In this example, the file is on the Desktop of the Windows Jumphost as follows:
Folder: \Desktop\SDN Lab Files\Software\2.5 scripts\
File Name: get-token

Figure 7-41: Edit file get-token

Note
You will not need to edit this file.
20. The Bash script uses cURL to interact with the HP VAN SDN Controller in a similar way that
RSdoc interacts. The script has the following statement, which uses cURL to authenticate with the HP
VAN SDN Controller and retrieve a token:
curl -sk -H 'Content-Type:application/json' \
-d '{"login":{"user":"sdn","password":"skyline","domain":"sdn"}}' \
https://192.168.56.11:8443/sdn/v2.0/auth\
| python -mjson.tool

Table 7-1 contains command explanations (you do not need to learn cURL options for the exam).

Table 7-1: cURL command explanations


Command Value

Meaning

curl

Use cURL to send commands to the HP VAN


SDN Controller.
-s
Silent or quiet mode: Does not show progress
meter or error messages. Makes cURL mute. It
will still output the data you ask for, potentially
even to the terminal/stdout unless you redirect it.
-k
Insecure: (SSL) This option explicitly allows
cURL to perform insecure SSL connections
and transfers. All SSL connections are attempted
to be made secure by using the CA certificate
bundle installed by default. This makes all
connections considered insecure fail unless k, --insecure is used.
-H
(H = Header) This option specifies that the data
content is an application.
\
In Linux, the \ character allows you to split a
command across multiple lines.
-d
(HTTP) This option sends the specified data in a
POST request to the HTTP server in the same
way that a browser does when a user has filled
in an HTML form and presses the submit button.
'{"login":
Authentication information: Information is
{"user":"sdn","password":"skyline","domain":"sdn"}}' encoded in JSON format. The HP VAN SDN
Controller uses JSON, but other REST
interfaces may use XML based data or other
options.
https://192.168.56.11:8443/sdn/v2.0/auth
HP VAN SDN Controller authentication REST
API.
| python -mjson.tool
Format returned data in a human readable
format.
21. Close Notepad++.
22. Start FileZilla on the Jumphost PC. Figure 7-42 displays the FileZilla shortcut icon.

Figure 7-42: Controller applications


23. Open Site Manager as illustrated in Figure 7-43.

Figure 7-43: Controller applications


24. Select DNS and click Connect, as illustrated in Figure 7-44.

Figure 7-44: Site Manager connections


25. Upload the get-token file to the DNS server (see Figure 7-45):
Folder: \Desktop\SDN Lab Files\Software\2.5 scripts\
File Name: get-token

Figure 7-45: Upload dialog box


26. Use PuTTy to SSH to the DNS server:
IP address: 192.168.56.50
Username: sdn
Password: skyline
27. Use the ls command to view files:
sdn@CoreDHCPDNSNTP:~$ ls
get-token
sdn@CoreDHCPDNSNTP:~$

Result: The get-token file is shown.


28. Run the file (enter a password of skyline if prompted):
sdn@CoreDHCPDNSNTP:~$ sudo bash ./get-token
{
"record": {
"domainId": "44127e689fa640e887ccdf46f5becad9",
"domainName": "sdn",

"expiration": 1436504462000,
"expirationDate": "2015-07-09 22-01-02 -0700",
"roles": [
"sdn-user",
"sdn-admin"
],
"token": "9e1e303fdc3b4e2da9b263b6358fb290",
"userId": "2e00893fe7534b88a15d74a6de1a2f2c",
"userName": "sdn"
}
}
sdn@CoreDHCPDNSNTP:~$

Result: A token is returned by the controller. This is similar to what we did previously with RSdoc. In
this case, however, a script has been executed and used cURL to connect to the controller and retrieve the
token information.
29. Upload the get-datapaths file from the Windows PC to the DNS server (see Figure 7-46).

Figure 7-46: Upload dialog box


30. Run the file in the PuTTY session to the DNS server:
sdn@CoreDHCPDNSNTP:~$ sudo bash ./get-datapaths
===============================================================
{
"datapaths": [

{
"capabilities": [
"flow_stats",
"table_stats",
"port_stats",
"group_stats",
"ip_reasm",
"queue_stats",
"port_blocked"
],
"desc": "",
"device_ip": "10.1.1.252",
"device_port": 36488,
"dpid": "00:01:78:48:59:39:2f:96",
"hw": "HP 5920AF-24XG Switch",
"last_message": "2015-07-10T04:11:55.521Z",
"mfr": "HP",
--More--

Result: OpenFlow switches that have currently registered with the HP VAN SDN Controller are shown.
This is similar to the SDN Toolkit that showed OpenFlow-enabled switches.
31. In the next chapter (Chapter 8 High Availability), you will use the cURL and the REST API to
configure controller teaming and switch regions.
32. Optional information:
If you are interested, open the get-datapaths script in Notepad++ and view the REST API URL used to
retrieve OpenFlow-enabled switches.
You can also view REST information directly on the controller by navigating to:
https://<Controller_IP_Address>:8443/sdn/v2.0/models.
If you are interested in using the controller REST and Java APIs for further automation and programming,
please refer to the REST API guide and programming guide:
Note
The HP VAN SDN Controller 2.5 REST API Reference Guide is available at:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647295

Note
The HP VAN SDN Controller 2.5 Programming Guide
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647292

is

available

at:

If you want to learn more about the REST API and programming, please refer to the following resources.

Gen9 Servers
HP RESTful API
The following link includes a 2.5-minute video demonstrating the process of accessing a Gen9 Server via
iLO4 2.0 f/w onward using REST:
Note
Simplify
programmatic
computing
standardizing
server
http://www8.hp.com/us/en/products/servers/proliant/restful-interface-tool.html
Or: http://bit.ly/1J0VWZy

interactions

HP OneView REST API Docs


Note
HP
OneView
1.20
REST
API
Scripting
Help
http://h17007.www1.hp.com/docs/enterprise/servers/oneview1.2/cic-rest/en/content/index.html
Or: http://bit.ly/1W5msVl

OpenStack
Note
General information: http://www.openstack.org

Note
OpenStack API Quick Start: http://docs.openstack.org/api/quick-start/content/

Other useful links:

Note
https://en.wikipedia.org/wiki/Representational_state_transfer
http://www.restapitutorial.com/
http://curl.haxx.se/
https://developer.nest.com/documentation/cloud/rest-guide/

Python
Note
Documentation: https://www.python.org/doc/

Note
A hands-on introduction to Python for beginning programmers

Note
Python TrainingGetting Started with Python
From http://www.youtube.com/watch?v=B9MvjMFokLc

Note
Chris Young blog with lots of links:
http://kontrolissues.net/python-for-network-engineers-resources/

Summary
In this chapter, you learned about the HP VAN SDN Controller RESTful API features and functions. You
learned how to interact with the API and make REST calls using cURL.
External applications can be developed in any language and are deployed on a platform outside the
controller platform. They can also be deployed on the same platform as the controller, but they are not
installed via the controller GUI.
External applications interact with the controller using the REST API services exported and advertised
by the controller platform and by native applications deployed on the controller.
Because external applications are deployed outside the controller platform, they cannot extend the REST
API or GUI surface of the controller.
External applications are suitable for applications that have relatively infrequent and high-latency control
interactions with network devices, and when deploying on a different platform is required.

Before certain API calls can be made, a token must to be retrieved from the HP VAN SDN Controller. To
retrieve a token, user authentication is required. You learned how to use cURL to authenticate and retrieve
tokens for subsequent API calls.
You then learned how to list datapaths in a network using the RESTful API. This chapter laid a foundation
for future learning that requires knowledge of the REST API.

Learning check
The following questions test what you learned in this chapter and will help you prepare for the exam:
1. An administrator is trying to list ports on specific DPID. What needs to be presented with the API
call?
a. SDN username and password
b. System-token
c. X-Auth-Token
d. Internal-token
e. REST token
f. SSL certificate
2. A developer is trying to update the flows on a switch. Which of the following cURL commands is
valid for an API call made against the HP VAN SDN Controller? Assume that a default installation
has been completed and that all environment variables are correctly configured.
a. curl -sk -H https://192.168.56.31:8443/sdn/v2.0/of/datapaths
b.

curl
-sk
-H
"X-Auth-Token:ccf1e5aedb6d4ae19f1480c55907d970"
https://192.168.56.31/sdn/v2.0/of/datapaths

c.

curl
-H
"X-Auth-Token:ccf1e5aedb6d4ae19f1480c55907d970"
https://192.168.56.31:8443/sdn/v2.0/of/datapaths

d.

curl
-sk
-H
"X-Auth-Token:ccf1e5aedb6d4ae19f1480c55907d970"
http://192.168.56.31:8443/sdn/v2.0/of/datapaths

e.

curl
-sk
-H
"X-Auth-Token:ccf1e5aedb6d4ae19f1480c55907d970"
https://192.168.56.31:8443/sdn/v2.0/of/datapaths

f.

curl
-sk
-H
https://:8443/sdn/v2.0/of/datapaths

"X-Auth-Token:ccf1e5aedb6d4ae19f1480c55907d970"

Learning check answers


1. Answer: c
The controller uses an X-Auth-Token for REST API authentication.
2. Answer: d
Explanations:
Answer A is missing the X-Auth-Token. The controller will reject this request.

Answer B is using port 80 rather than port 8443. The controller will reject this request.
Answer C is missing the -sk options. cURL will not accept a self-signed certificate by default.
Answer D is using http rather than https. The controller will reject this request.
Answer E is correct.
Answer F is missing the IP address of the controller. The command will fail.

Chapter 8
High Availability
EXAM OBJECTIVES
In this chapter you will learn to:
Explain how the HP VAN SDN Controller teaming feature works
Explain team sizing and team behavior on loss of a controller
Configure teaming
Configure regions and owners
Understand the integration of regions and teaming
Verify teaming and regions

Assumed knowledge
OpenFlow
Controller teaming
IP addressing

Introduction
In this chapter, you will learn about HP VAN SDN Controller high availability (HA) using controller
teaming and regions.
Standalone controller operation provides management for the OpenFlow switches in a network.
However, it does not provide HA, with the result that if a controller fails, the network is left in an
unmanaged state. Configuring a team of controllers and one or more corresponding controller regions
creates a HA network with failover capability, resulting in a continuously managed network in the event
that a controller in the team goes down. Controller teaming also provides centralized controller
configuration and monitoring.

Standalone controller
Introduction
A standalone HP VAN SDN Controller managing a network can be a single point of failure, as shown in
Figure 8-1.

Figure 8-1: Standalone controller


What happens when an OpenFlow switch loses connection to that single controller? The answer is this:
HP switches operate in one of two modes and the mode determines the switch behavior:
Fail-secure (default mode): If an OpenFlow instance on the switch loses connection with all
controllers, packets and messages intended for controllers are dropped. Flows continue to expire
according to their time-outs.
Fail-standalone: If an OpenFlow instance on the switch loses connection with all controllers, packets
of new flows are handled by the legacy switching and routing functions. Existing flows of this
OpenFlow instance are removed.
Controller teaming is used for fault-tolerance. If one controller in the team experiences a failure or a loss
of connection to network devices, the other controllers in the team can continue to control the network.
If a controller is not configured as part of a team, it is considered a standalone controller or a
controller in a standalone environment.
If a controller is configured as part of a team, it is considered a teamed controller or a controller in a
teamed environment.

Instructions for testing the result of a single controller failure


This section includes instructions for testing the effect of the failure of a standalone controller (see Figure
8-2). You will first review the OpenFlow specification definition of switch behavior when the switch
loses connection to all controllers. Then you will review how to test how this actually works in practice
when using hybrid mode on HP switches.

Figure 8-2: Standalone controller


You will also review how to determine flow behavior when the connection is lost and be able to answer
the following questions:
Are packets lost?
Are flows removed?
What is the effect of the hard-timeout value?
What is the effect of the idle-timeout value?
Later, you will learn how to configure controller teaming and test controller redundancy.

Instructions
Up until this point, switches have been controlled by a single controller. In Figure 8-3, three new
controllers are configured in a team. These controllers are currently standalone controllers with no
applications installed.

Figure 8-3: OpenFlow sessions


1. Configure ProVision switch 2 (P2) to use HP controller 192.168.56.12 (Network Protector
Controller). If you prefer, view the full configuration in the next step:
P2# configure
P2(config)# openflow
P2(openflow)# instance vlan40
P2(of-inst-vlan40)# disable
P2(of-inst-vlan40)# no controller-id 3
P2(of-inst-vlan40)# controller-id 2
P2(of-inst-vlan40)# enable
P2(of-inst-vlan40)# exit
P2(openflow)# enable
P2(openflow)# end
P2#

a. View the switch configuration and verify that the OpenFlow configuration is the same as the
following:
P2# show running-config
...<omitted>...
openflow

controller-id 1 ip 192.168.56.11 controller-interface vlan 1


controller-id 2 ip 192.168.56.12 controller-interface vlan 1
controller-id 3 ip 192.168.56.13 controller-interface vlan 1
instance "vlan40"
member vlan 40
controller-id 2
version 1.3
enable
exit
enable
exit

b. Confirm that ProVision switch 2 (P2) is connected to HP controller 192.168.56.12:


P2# show openflow instance vlan40
Configured OF Version : 1.3
Negotiated OF Version : 1.3
Instance Name : vlan40
Data-path Description :
Admin. Status : Enabled
Member List : VLAN 40
Pipeline Model : Standard Match
Listen Port : None
Oper. Status : Up
Oper. Status Reason : NA
Datapath ID : 00281458d0f0bc80
Mode : Active
Flow Location : Hardware and Software
No. of Hw Flows : 6
No. of Sw Flows : 4
Hw. Rate Limit : 0 kbps
Sw. Rate Limit : 100 pps
Conn. Interrupt Mode : Fail-Secure
Maximum Backoff Interval : 60 seconds
Probe Interval : 10 seconds

Hw. Table Miss Count : NA


No. of Sw Flow Tables : 1
Egress Only Ports : None
Table Model : Policy Engine and Software

P2#

Result: The switch has an active connection to the controller.

Questions
Question 1: What will a switch with one connection to a controller do if the controller fails?
Question 1 answer: This depends on the mode used by the switch. The default mode is fail-secure.

OpenFlow specification
The OpenFlow specification states the following:
In the case that a switch loses contact with all controllers, as a result of echo request timeouts, TLS
session timeouts, or other disconnections, the switch must immediately enter either fail secure mode or
fail standalone mode, depending upon the switch implementation and configuration.
In fail secure mode, the only change to switch behavior is that packets and messages destined to the
controllers are dropped. Flow entries should continue to expire according to their timeouts in fail secure
mode.
In fail standalone mode, the switch processes all packets using the OFPP_NORMAL reserved port; in
other words, the switch acts as a legacy Ethernet switch or router. The fail standalone mode is usually
only available on Hybrid switches.
Upon connecting to a controller again, the existing flow entries remain. The controller then has the
option of deleting all flow entries, if desired.
The first time a switch starts up, it will operate in either fail secure mode or fail standalone mode
until it successfully connects to a controller. Configuration of the default set of flow entries to be used at
startup is outside the scope of the OpenFlow protocol.
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.3.2, Connection Interruption,
page 29. Available at: http://bit.ly/1Lze7FV

ProVision instructions
1. View ProVision switch 1 (P1) configuration and verify that the OpenFlow configuration is the same as

the following:
P1# show running-config
...<omitted>...
openflow
controller-id 1 ip 192.168.56.11 controller-interface vlan 1
controller-id 2 ip 192.168.56.12 controller-interface vlan 1
controller-id 3 ip 192.168.56.13 controller-interface vlan 1
instance "vlan30"
member vlan 30
controller-id 1
version 1.3
enable
exit
enable
exit

Questions
Question 1: Which mode does a ProVision switch use by default?
Question 1 Answer: ProVision switches use fail-secure mode by default. See the following for switch
output.
Check the mode that ProVision switch 1 (P1) is using and the controller the switch is communicating
with:
P1# show openflow controllers
Controller Information

P1# show openflow instance vlan30


Configured OF Version : 1.3
Negotiated OF Version : 1.3
Instance Name : vlan30
Data-path Description :

Admin. Status : Enabled


Member List : VLAN 30
Pipeline Model : Standard Match
Listen Port : None
Oper. Status : Up
Oper. Status Reason : NA
Datapath ID : 001e1458d0f0db80
Mode : Active
Flow Location : Hardware and Software
No. of Hw Flows : 6
No. of Sw Flows : 4
Hw. Rate Limit : 0 kbps
Sw. Rate Limit : 100 pps
Conn. Interrupt Mode : Fail-Secure
Maximum Backoff Interval : 60 seconds
Probe Interval : 10 seconds
Hw. Table Miss Count : NA
No. of Sw Flow Tables : 1
Egress Only Ports : None
Table Model : Policy Engine and Software

ProVision switches are configured to use fail-secure mode by default. The switch in this example is
communicating with a Controller with an IP address of 192.168.56.11. This is the only controller to
which the switch has an active connection.

Comware instructions
2. View Comware switch 2 (C2) configuration and verify that the OpenFlow configuration is the same as
the following:
[C2] display current-configuration
...<omitted>...
openflow instance 1
classification vlan 20
controller 1 address ip 192.168.56.11

active instance

a. Check that Comware switch 2 (C2) connected to controller 192.168.56.11:


[C2] display openflow instance
Instance 1 information:
Configuration information:
Description : -Active status : Active
Inactive configuration:
None
Active configuration:
Classification: VLAN, total VLANs(1)
20
In-band management VLAN, total VLANs(0)
Empty VLAN
Connect mode: Multiple
MAC address learning: Enabled
Flow table:
Table ID(type): 0(Extensibility), count: 5
Flow-entry max-limit: 65535
Datapath ID: 0x0001784859392f96
Port information:
Ten-GigabitEthernet1/0/2
Bridge-Aggregation1
Active channel information:
Controller 1 IP address: 192.168.56.11 port: 6633
[C2]

Result: An active connection exists to 192.168.56.11. Comware switches use fail-secure mode by
default.
b. Start continuous pings from UserVM3 to UserVM2, UserVM4, and hp.com:
UserVM3 pinging UserVM2:
C:\Users\Student> ping 10.20.20.2 -t
Pinging 10.20.20.2 with 32 bytes of data:
Reply from 10.20.20.2: bytes=32 time<1ms TTL=128

Reply from 10.20.20.2: bytes=32 time<1ms TTL=128


Reply from 10.20.20.2: bytes=32 time<1ms TTL=128
UserVM3 pinging UserVM4:
C:\Users\Student> ping 10.40.40.4 -t
Pinging 10.40.40.4 with 32 bytes of data:
Reply from 10.40.40.4: bytes=32 time<1ms TTL=127
Reply from 10.40.40.4: bytes=32 time<1ms TTL=127
Reply from 10.40.40.4: bytes=32 time<1ms TTL=127
Reply from 10.40.40.4: bytes=32 time<1ms TTL=127
UserVM3 pinging hp.com:
C:\Users\Student>ping hp.com -t
Pinging hp.com [192.168.56.51] with 32 bytes of data:
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63

c. Use PuTTY on your Windows VM (Jumphost) to connect to the controller using SSH as follows:
IP address: 192.168.56.11
Port number: 22
Protocol: SSH
d. When prompted, log in with the following credentials:
Username: sdn
Password: skyline
e. Stop the controller service (use a password of skyline if prompted):
sdn@sdnctl1:~$ sudo service sdnc stop
[sudo] password for sdn:
sdnc stop/waiting
sdn@sdnctl1:~$

Note
You are stopping the controller that both switch C2 and P1 are registered to using OpenFlow.

Questions
Following is a series of questions that will help you retain the information and concepts you have learned
thus far:
Question 1: Were pings affected? If not, why?
Question1 answer:
Reply from 10.20.20.2: bytes=32 time<1ms TTL=128
Reply from 10.20.20.2: bytes=32 time<1ms TTL=128
Reply from 10.20.20.2: bytes=32 time<1ms TTL=128
...
Reply from 10.40.40.4: bytes=32 time<1ms TTL=127
Reply from 10.40.40.4: bytes=32 time=1ms TTL=127
Reply from 10.40.40.4: bytes=32 time<1ms TTL=127
...
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63
Reply from 192.168.56.51: bytes=32 time<1ms TTL=63

Ping traffic is not affected because the current table miss entry is set to send traffic to the normal port (that
is, the traditional pipeline). The ping traffic is therefore processed using traditional mechanisms.
Question 2: What is the connection state on the Comware switch 2 (C2) and ProVision switch 1 (P1)?
Question 2 answer:
<C2> display openflow instance
Instance 1 information:
Configuration information:
Description : -Active status : Active
Inactive configuration:
None
Active configuration:
Classification: VLAN, total VLANs(1)
20
In-band management VLAN, total VLANs(0)
Empty VLAN
Connect mode: Multiple
MAC address learning: Enabled

Flow table:
Table ID(type): 0(Extensibility), count: 5
Flow-entry max-limit: 65535
Datapath ID: 0x0001784859392f96
Port information:
Ten-GigabitEthernet1/0/2
Bridge-Aggregation1
Active channel information:
Failopen mode: Secure
<C2>
P1# show openflow instance vlan30
Configured OF Version : 1.3
Negotiated OF Version : 1.3
Instance Name : vlan30
Data-path Description :
Admin. Status : Enabled
Member List : VLAN 30
Pipeline Model : Standard Match
Listen Port : None
Oper. Status : Up
Oper. Status Reason : NA
Datapath ID : 001e1458d0f0db80
Mode : Active
Flow Location : Hardware and Software
No. of Hw Flows : 6
No. of Sw Flows : 4
Hw. Rate Limit : 0 kbps
Sw. Rate Limit : 100 pps
Conn. Interrupt Mode : Fail-Secure
Maximum Backoff Interval : 60 seconds
Probe Interval : 10 seconds
Hw. Table Miss Count : NA
No. of Sw Flow Tables : 1
Egress Only Ports : None

Table Model : Policy Engine and Software

Question 3: Do flows still exist in the switch OpenFlow flow tables?


Question 3 answer:
Comware C2:
<C2> display openflow instance 1 flow-table
Instance 1 flow table information:
Table 0 information:
Table type: Extensibility, flow entry count: 5, total flow entry count: 5
MissRule flow entry information:
cookie: 0xffff000000000000, priority: 0, hard time: 0, idle time: 0, flags:
flow_send_rem, byte count: --, packet count: 4435
Match information: any
Instruction information:
Write actions:
Output interface: Normal
Flow entry 5 information:
cookie: 0xfffc0000babadada, priority: 31500, hard time: 0, idle time: 0,
flags: none, byte count: --, packet count: 0
Match information:
Ethernet type: 0x0800
IP protocol: 17
UDP source port: 68, mask: 0xffff
UDP destination port: 67, mask: 0xffff
Instruction information:
Apply actions:
Output interface: Controller, send length: 65509 bytes
Write actions:

Output interface: Normal


...<omitted>...
ProVision P1:
P1# show openflow instance vlan30 flows
OpenFlow Flow Table
Flow 1
Match
Incoming Port : AnyEthernet Type : Any
Source MAC : AnyDestination MAC : Any
Source MAC Mask : 000000-000000
Destination MAC Mask : 000000-000000
VLAN ID : AnyVLAN priority : Any
Source IP Address : Any
Destination IP Address : Any
IP Protocol : Any
IP ECN : AnyIP DSCP : Any
Source Port : AnyDestination Port : Any
Attributes
Priority : 0Duration : 1434 seconds
Hard Timeout : 0 secondsIdle Timeout : 0 seconds
Byte Count : 0Packet Count : NA
Flow Table ID : 0Controller ID : 1
Cookie : 0xffff000000000000
Hardware Index: NA
Instructions
Goto Table ID: 100
Flow 2
... <omitted>...
Flow 6
Match
Incoming Port : AnyEthernet Type : Any
Source MAC : AnyDestination MAC : Any
Source MAC Mask: 000000-000000
Destination MAC Mask: 000000-000000

VLAN ID : AnyVLAN priority : Any


Source IP Address : Any
Destination IP Address : Any
IP Protocol : Any
IP ECN : AnyIP DSCP : Any
Source Port : AnyDestination Port : Any
Attributes
Priority : 0Duration : 2322 seconds
Hard Timeout : 0 secondsIdle Timeout : 0 seconds
Byte Count : NAPacket Count : 2166
Flow Table ID : 100Controller ID : 1
Cookie : 0xffff000000000000
Hardware Index: NA
Instructions
Apply Actions
Normal

Yes. Flows are still kept in the OpenFlow table on the switches.
Question 4: Why have the flows not timed out?
Question 4 answer: Fail-secure mode is used by the switches. Flows are therefore kept in the flow table
until they timeout based on the idle timeout or hard timeout values. Multiple flow entries in the table have
a hard timeout value of zero, which means that the flows will not time out.
Question 5: Are the switches C2 and P1 currently managed by a controller?
Question 5 answer: No, the switches are unmanaged because they do not have active connections to any
controller.
Question 6: Is ProVision switch 2 (P2) currently managed by a controller?
Question 6 answer:
P2# show openflow instance vlan40
Configured OF Version : 1.3
Negotiated OF Version : 1.3
Instance Name : vlan40
Data-path Description :
Admin. Status : Enabled
Member List : VLAN 40
Pipeline Model : Standard Match

Listen Port : None


Oper. Status : Up
Oper. Status Reason : NA
Datapath ID : 00281458d0f0bc80
Mode : Active
Flow Location : Hardware and Software
No. of Hw Flows : 6
No. of Sw Flows : 4
Hw. Rate Limit : 0 kbps
Sw. Rate Limit : 100 pps
Conn. Interrupt Mode : Fail-Secure
Maximum Backoff Interval : 60 seconds
Probe Interval : 10 seconds
Hw. Table Miss Count : NA
No. of Sw Flow Tables : 1
Egress Only Ports : None
Table Model : Policy Engine and Software

Yes. Currently, ProVision switch 2 is still managed by HP VAN SDN Controller


192.168.56.12.

Question 7: Activate the controller service on controller 192.168.56.11:


sdn@sdnctl1:~$ sudo service sdnc start
[sudo] password for sdn:
sdnc start/running, process 13600
sdn@sdnctl1:~$

Note
It may take a few minutes for the controller services to start.
Does Comware switch 1 (C1) have OpenFlow enabled?

Question 7 answer:
<C1> display openflow summary
OFP is not configured.
<C1>

No, OpenFlow is not enabled on C1.


Question 8: At the moment, the default gateway of the OpenFlow instances is Comware switch 1 (C1),
which has not been enabled for OpenFlow.
Would enabling OpenFlow on Comware 1 (C1) have a negative effect on the network?
Question 8 answer: The next steps will show you the answer to this question.
WARNING
In this example, you will make changes on the core switch while running a continuous ping between
user virtual machines. In a production environment a scheduled maintenance window is advised for
configuration changes of this nature.
3. Configure OpenFlow on Comware 1 (C1) on VLAN 30 only:
<C1> system-view
[C1] openflow instance 1
[C1-of-inst-1] controller 1 address ip 192.168.56.11
[C1-of-inst-1] classification vlan 30

WARNING
Do not activate the C1 OpenFlow instance before the HP VAN SDN Controller 192.168.56.11 is
back online. To verify this, use the display openflow instance 1 command on Comware switch C2
and show openflow instance vlan30 command on ProVision switch P1.
Activate OpenFlow on Comware 1 (C1) once HP VAN SDN Controller 192.168.56.11 is back online:
[C1-of-inst-1] active instance

Did UserVM3 lose any pings?


Yes. One ping was lost when Comware switch 1 (C1) was enabled for OpenFlow.
Question 9: Does Comware switch C1 have an active connection to the controller?
Question 9 answer: Check the status of the OpenFlow connection:
[C1] display openflow summary
Fail-open mode: Se - Secure mode, Sa - Standalone mode

[C1]

Result: The switch has an active connection to the controller.


Question 10: When would teaming be required?
Question 10 answer: Teaming would be required if switches should still be managed by a controller
team on a controller failure. Up to this point, when the controller failed, switches were left in the
unmanaged state.
No applications are able to manage the network if the controller has failed. An external application using
the REST API, for example, should still be able to create flows on the switches if a controller fails
hence a team of controllers is required.

Instructions for testing DNS flow entries


4. Find the DNS flow entry on ProVision switch 2 (P2):
P2# show openflow instance vlan40 flows
...<omitted>...
Flow 6
Match
Incoming Port : AnyEthernet Type : IP
Source MAC : AnyDestination MAC : Any
Source MAC Mask : 000000-000000
Destination MAC Mask : 000000-000000
VLAN ID :Any VLAN priority : Any
Source IP Address :Any
Destination IP Address :Any
IP Protocol :UDP
IP ECN : Any IP DSCP :Any
Source Port : AnyDestination Port : 53
Attributes
Priority : 50301Duration : 1 seconds
Hard Timeout : 8 secondsIdle Timeout : 0 seconds
Byte Count : NAPacket Count : 0
Flow Table ID : 100Controller ID : listen-port
Cookie : 0xbadbabe
Hardware Index: 1

Instructions
Apply Actions
Output : ServiceTunnel01
Normal

Result: A flow entry intercepting DNS has been added to the flow table of ProVision switch 2 (P2). The
hard timeout for this flow entry is 8 seconds.
5. Test DNS interception on UserVM4:
C:\Users\Student>nslookup howtodoitman.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.56.12
C:\Users\Student>

Result: The DNS query was intercepted, and the redirection server IP address was returned by Network
Protector.
6. Use PuTTY on the Windows Jumphost to SSH to the Network Protector controller:
IP address: 192.168.56.12
Port number: 22
Protocol: SSH
7. When prompted, log in with the following credentials:
Username: sdn
Password: skyline
8. Stop the controller service (use a password of skyline if prompted):
sdn@sdnctl2:~$ sudo service sdnc stop
[sudo] password for sdn:
sdnc stop/waiting
sdn@sdnctl2:~$

9. Test DNS interception on UserVM4:


C:\Users\Student>nslookup howtodoitman.com
DNS request timed out.
timeout was 2 seconds.

Server: UnKnown
Address: 192.168.56.50
Name: anyhome.ca
Address: 192.168.56.52
C:\Users\Student>

Result: The DNS server returned the server IP address. The DNS query was not intercepted.
10. Check if flow entries are still in the OpenFlow table of ProVision switch 2 (P2):
P2# show openflow instance vlan40 flows
OpenFlow Flow Table
Flow 1
Match
Incoming Port : Any Ethernet Type : Any
Source MAC : Any Destination MAC : Any
Source MAC Mask : 000000-000000
Destination MAC Mask : 000000-000000
VLAN ID : Any VLAN priority : Any
Source IP Address : Any
Destination IP Address : Any
IP Protocol : Any
IP ECN : Any IP DSCP : Any
Source Port : Any Destination Port : Any
Attributes
Priority : 0 Duration : 61507 seconds
Hard Timeout : 0 seconds Idle Timeout : 0 seconds
Byte Count : 0 Packet Count : NA
Flow Table ID : 0 Controller ID : listen-port
Cookie : 0xffff000000000000
Hardware Index: NA
Instructions
Goto Table ID : 100
...<omitted>...

Result: Flow entries are still in the flow table of the switch.

11. Is the DNS flow entry still in the table?


You can check this by filtering output:
P2# show openflow instance vlan40 flows | include 53
P2#

Result: No DNS entry is found in the OpenFlow flow table.


12. Start the controller service (use a password of skyline if prompted):
sdn@sdnctl2:~$ sudo service sdnc start
sdnc start/running, process 10183
sdn@sdnctl2:~$

13. External SDN applications are reliant on the HP VAN SDN Controller being available. If the
controller goes down, external applications will not be able to make changes to the flow tables of
switches using the controller northbound interface.
For example, in the SDN Toolkit application, you configured the controller IP address of 192.168.56.11,
as shown in Figure 8-4 (you do not have to configure anything in this step).
If the controller configured in the application was not available, the application would no longer function.

Figure 8-4: SDN Controller details in an external SDN application

Block a host using a script instructions


Instead of using a graphical REST API application, you could use a script to block a host using cURL and
the REST API.

Instructions
1. View controller 192.168.56.11 connected switches. Use Google Chrome on the Windows Jumphost to
navigate to: https://192.168.56.11:8443/sdn/ui

2. Click OpenFlow Monitor and select the Comware switch (10.1.1.252) as shown in Figure 8-5.

Figure 8-5: OpenFlow Monitor


3. Select Flows to view the flows on the switch. Copy the DPID of the switch (see Figure 8-6).

Figure 8-6: OpenFlow Monitor


4. On the Windows Jumphost, open the block-UserVM3 script using Notepad++ (right click on file and
select Edit with Notepad++).
The file is on the desktop of the Windows Jumphost as follows:
Folder: \Desktop\SDN Lab Files\Software\2.5 scripts\
File Name: block-UserVM3 (see Figure 8-7)

Figure 8-7: Edit file


This script is using the REST API to block traffic. The parameter CTL="192.168.56.11" determines to
which controller REST API calls will be made.
The parameter DPID1="00:01:78:48:59:39:2f:96", as shown in Figure 8-8, determines the switch to
which controller REST API calls will be made.
Replace the value of DPID1 with the DPID of Comware switch 2 (C2) that you copied and then save the
file.

Figure 8-8: Change DPID value


Result: The controller IP address used is 192.168.56.11. The DPID is the Comware switch.
5. Start FileZilla on the Jumphost PC.
6. Open Site Manager (see Figure 8-9).

Figure 8-9: Controller applications


7. Select DNS and click Connect (see Figure 8-10):

Figure 8-10: Site Manager connections


8. Upload the block-UserVM3 file to the DNS server (see Figure 8-11) as follows:
Folder: \Desktop\SDN Lab Files\Software\2.5 scripts\
File Name: drop-UserVM3

Figure 8-11: Upload file


9. If not already open, use PuTTY to SSH to the DNS server:
IP address: 192.168.56.50
Username: sdn
Password: skyline
10. Run the block-UserVM3 script as follows:
sdn@CoreDHCPDNSNTP:~$ sudo bash ./block-UserVM3
===============================================================
Setting flows...
Finished
===============================================================
sdn@CoreDHCPDNSNTP:~$

Result: The script updates flows on the switches.


11. Refresh the Flows on the Comware switch 1(C1) (see Figure 8-12).

Figure 8-12: Flow entries


Result: A flow entry blocking network 10.30.30.0/24 sending traffic to 192.168.56.0/24 has been added.
12. Expand the flow entry (see Figure 8-13).

Figure 8-13: Idle timeout


Result: The flow entry added by the script has a hard timeout of 300 seconds. It will therefore be
removed even if traffic matches.
This application is making a REST API call against controller 192.168.56.11. If this controller goes
down, the application will not be able to update or delete flows.

Questions
The following questions will help you prepare for the exam.
Question 1: Will a network stop functioning when the controller fails?
Question 2: Will flows be removed when a controller fails?
Question 3: What determines if flows are removed?
Question 4: Why were pings not dropped when the controller failed?
Question 5: Why were DNS interception flows removed?

Question 1 answer:
In hybrid mode, switches continue using traditional mechanisms and only use OpenFlow for exception
processing. The default mode used by HP switches is hybrid mode and fail-secure OpenFlow mode. This
means that flow entries that match the table-miss entry are forwarded to the NORMAL port and will
continue being processed by the local switch regardless of the availability of an HP VAN SDN
Controller. The default flow entries added by the HP VAN SDN Controller are not removed from the
switch flow table as they have an idle and hard timeout of zero (do not time out).
The network will thus continue to function.
Be aware, however, that flow entry timeouts for flows added by applications such as the HP Network
Protector SDN Application, depend on the setting of the idle or hard timeouts. In the scenario, flow
entries added by Network Protector that matched DNS were removed after the hard timeout expired.
Flow entries added by the Bash script were removed after the idle timeout expired.
Traffic that matched these entries was forwarded normally based on the table-miss entry. This did not
break the network, but did affect traffic behavior.
If a network is using OpenFlow-only, however, the switches are reliant on the controller to determine
packet forwarding and cannot make local decisions. With fail-secure mode, new flows are not added to
the switch because the controller is unavailable. Therefore, new traffic flows will be dropped.
With fail-standalone, the switch has to relearn where MAC addresses reside in the network and this
results in flooding. There is also the potential of broadcast storms if Spanning Tree Protocol (STP) is not
enabled and the topology has loops.
It is therefore recommend in most cases that a hybrid mode network be deployed.
Question 2 answer:
This is dependent on a number of factors, including which mode is used. If fail-secure mode (the default
mode) is used, packets and messages intended for controllers are dropped. Flows continue to expire
according to their timeouts (hard and idle timeouts).
If fail-standalone mode is used, packets of new flows are handled by the legacy switching and routing
functions. Existing flows of this OpenFlow instance are removed.
Question 3 answer:
The first thing that determines if the flow will be removed is the mode. Specifically, it is one of the
following modes:
Fail-secure
Fail-standalone
The second thing that determines flow removal is this: if fail-standalone is used, all flow entries are
removed on loss of connection to the controller.
In fail-secure mode, flows continue to expire according to their timeouts (hard and idle timeouts).
Question 4 answer:
Ping traffic was not matched by any flow entries in the switch flow tables apart from the table-miss flow
entry. The table-miss flow entry was configured with an instruction to forward traffic to the NORMAL
portin other words, the traditional routing and switching pipeline. Internet Control Message Protocol

(ICMP) traffic was thus processed using traditional mechanisms and in this case, pings succeeded.
Question 5 answer:
In the example, flow entries added by Network Protector that matched DNS were removed after the hard
timeout expired. The Network Protector application set the hard timeout of the flow entries to 8 seconds
and once this expired, the flow entries were removed by the switches. Because the controller was offline
and unavailable, the flow entry was not refreshed and thus DNS traffic was not intercepted after the
timeout expired.

Controller high availability


Introduction
In a network managed by a controller, the controller can be a single point of failure. The HP VAN SDN
Controller provides multiple features to enable the controller and applications to remain available in the
event of a single controller failure.
The main features include:
Fault-tolerance for a single controller failure through the use of controller teams, regions, and
infrastructure that orchestrates the roles of the controllers in the team in response to changing network
and controller situations.
Load balancing, which is achieved by configuring regions to distribute ownership of network devices
among the controllers in a controller team.
Infrastructure and services that enable you to program your application to handle various failure and
recovery situations and to coordinate among multiple application instances across the controllers in
the team.

Team management
Each controller belonging to a team is called a team member. To centralize team management and control,
one controller is designated as the team leader. The team leader is also sometimes called the team master,
but this should not be confused with the master used with the region configuration. The term that should be
used for the northbound API is team leader and team members. For the southbound APIs (to switches), the
terms master and slaves are used.
Teaming is configured on one controller, and the configuration is automatically propagated to the other
controllers in the team, regardless of which controller becomes the team leader.
After a team is configured, you can configure and monitor each team member. If the team leader goes
down, another active controller becomes the team leader. If a team leader fails and then recovers, it
resumes operation as a team member.

Team operating requirements


HP VAN SDN Controller teams have the following requirements and best practices:
If a controller is not configured as part of a team, it is considered a standalone controller or a
controller in a standalone environment.
If a controller is configured as part of a team, it is considered a teamed controller or a controller in a

teamed environment.
A controller team consists of three controllers.
A controller can only be part of one team.
All controllers in a team must be running the same HP VAN SDN Controller software version.
Only OpenFlow 1.3 devices are supported when the controller is teamed.
After the team is created, controllers will adopt the data of one of the members of the team. There
should be no or minimal data at that point.
The administrator must create the teams and the regions.

cURL
In the HP VAN SDN Controller, teaming is configured using the REST API. This chapter explains the
configuration of a controller team using cURL commands.

Licensing and software applications


Ensure that the team is fully operational before applying licensing or installing apps on any of the
controllers.
Teaming requires two HP VAN SDN Controller HA E-LTU licenses.
Note
A team of controllers consists of three controllers. However, only two HA licenses are required for
the team of three controllers.

Team leader
A controller team has one leader and two members, as shown in Figure 8-14, and includes the following
requirements:

Figure 8-14: Team leader


One controller is elected as the team leader.
The team leader role is determined internally and an administrator cannot influence this by changing
values like priorities, which may have been possible in older releases of the controller.
Once a team is configured, the configuration and monitoring of team members and their associated
OpenFlow switches is performed by the team leader. If the team leader fails, another controller in the
team becomes the team leader. If a team leader fails and then recovers, it resumes operation as a team
member only.
A team requires one IP address for each controller, plus one IP address assigned to the team. If the
current team leader goes down, the failover process includes keeping the team IP address active on
the new team leader.
The team leader is configured to have the team IP address, also called the northbound IP address. This
IP address is provided by the controller administrator during team creation. The team IP address
enables external applications to have a single point of contact with the team, treating the team as a
single unit. However, controllers are still accessible via their own IP addresses.

Team alias node


An IP address (northbound IP address) alias is created on the node that is elected as team leader to
allow a controller team to be accessible with a single IP address no matter which controller is the
leader.
This IP address is provided as part of the team configuration when creating a team.
Note
Refer to the HP VAN SDN Controller 2.5 Administrator Guide for more information:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647289.

Controller fault tolerance

When the leader fails, another controller is elected as the new leader and the team IP address is adopted
by the new leader (see Figure 8-15). Applications experience a loss of connection while the new leader
is elected.

Figure 8-15: Controller fault tolerance


The threshold for controller fault tolerance is 2n+1, where n is the number of failed controllers allowed
in an active team. HP VAN SDN Controller teaming supports a team of three controllers. In a team of
three controllers, n = 1; one controller in a team of three can fail without suspending team operation.
If one such controller does go down, a stateful failover occurs in which the remaining two members
resume together from the point of failure and the team continues to operate. As long as any two of the
teamed controllers in the network are active, the network remains in a managed state.

Suspended state
The team must have a quorum, which is a minimum of two functioning controllers, to remain operational.
If two controllers in a team fail (see Figure 8-16), the third controller does not operate as a standalone
controller. Instead, the third controller loses its membership in the team quorum so the sequencer initiates
the suspend sequence, which includes stopping all applications. When the suspend sequence completes,
the sequencer remains in the Team stage until another controller completes the Team startup stage and
joins the team. After a team quorum is formed, the sequencer attempts the next stage of the startup
sequence (discussed in more detail later in this chapter).

Figure 8-16: Controller fault tolerance (continued)

All team members in a teamed environment must be active before you can make configuration, licensing,
or application changes, or changes to regions. Because changes attempted when a team member is
initializing or is disconnected are not guaranteed to be consistent, such changes are blocked through the
REST API and the user interface. Changes attempted through the REST API result in HTTP error code
403 and the UnsafeConfigurationException exception.
WARNING
The network is no longer managed by the team when two controllers in the team fail. The remaining
controller moves to the suspended state and does not manage any network devices.

Controller status
Version 2.5 of the HP VAN SDN Controller groups components into categories, and these component
groups are initialized in order as the startup sequencer moves through the stages in the startup sequence.
During the operational phase, the OpenFlow port is opened. Core services are the first to be initialized,
and they are always active. System Information Service is part of the core services and thus the controller
status cannot be determined or reported until the core services complete the initialization phase.
The controller states are:
INITIALIZING: The sequencer completed the startup sequence through the team stage and the
controller is part of the team quorum (connected to at least one other active controller in the team), but
has not yet deployed and initialized the operational group services. At this point, the OpenFlow port
is not open.
ACTIVE: The sequencer completed all stages of the startup sequence and the OpenFlow port is open.
If the controller is a member of a team, it is part of the team quorum (connected to at least one other
team member that has started its teaming services).
SUSPENDED: The sequencer completed all stages in the suspend sequence. The sequencer initiates
the suspend sequence when a monitored core service reports an unhealthy status or a teamed
controller loses its membership in the team quorum. Core services are started. Teaming services are
started but are waiting until the controller can become a member of a team quorum. The OpenFlow
port is closed.
UNREACHABLE: A controller sees a remote controller as unreachable if the connection to the
remote controller is broken. A controller never sees itself as unreachable.
If an application reports an unhealthy status, an alert is generated but the controller remains in the active
state. If two controllers in a team fail, the third controller does not operate as a standalone controller.
Instead, the third controller loses its membership in the team quorum, and the sequencer initiates the
suspend sequence.

Team creation process


To configure a team, do the following:
1. Install and start three standalone controllers in the network.

2. Select any one of the controllers to use for configuring the team.
3. On the selected controller, acquire an Authentication Token.
4. Use cURL command to create a team on the selected controller.
5. Apply licenses
The HA Add Controller license (HP VAN SDN Ctrl HA E-LTU) enables the controller to form a team
for increased availability. The following guidelines apply:
The number of team members for an HP VAN SDN Controller team is three.
When forming a team, only one HP VAN SDN Controller base license is required, along with at least
two HA licenses, all on the same master controller. Once a team is formed, Add Nodes licenses can
be added to the team leader for increased support.
In addition, you must:
Use nonpreviously licensed controller installations to form the team.
Use a new hardware platform or virtual machine (VM) with a new installation of the HP VAN
SDN Controller.
Run the same software version on all controllers.

REST API authentication


Select any one of the controllers to use for configuring the team.
On the selected controller, acquire an Authentication Token. Use the following cURL command, with the
controller IP address, to acquire the token (see Figure 8-17).

Figure 8-17: REST API authentication


curl --noproxycontroller_ip -X POST --fail -ksSfL --url
"https://controller_ip:8443/sdn/v2.0/auth" -H "Content-Type:
application/json" --data-binary '{"login": {"domain":
"domain","user": "user","password": "password"}}'

In this example, a username of "sdn" and password of "skyline" are used:


~$ curl --noproxy 192.168.56.31 -X POST --fail -ksSfL --url
"https://192.168.56.31:8443/sdn/v2.0/auth" -H "Content-Type: application/json" --databinary '{"login":{"user":"sdn","password":"skyline","domain":"sdn"}}'

{"record":
{"token":"ccf1e5aedb6d4ae19f1480c55907d970","expiration":1437557415000,"expirationDate":"20
07-22 05-30-15
-0400","userId":"9c081cbe3eeb4dbab658090bb70d08f0","userName":"sdn","domainId":"118c46e61b4
["sdn-user","sdn-admin"]}}sdn@sdn-ctl:~/scripts$

The token returned by the controller in this example is: ccf1e5aedb6d4ae19f1480c55907d970


Note
For more information about cURL, visit:
http://curl.haxx.se and http://curl.haxx.se/docs/manpage.html.

Team configuration
Using the same controller that a token was received from, create the team using the following command
(see Figure 8-18):

Figure 8-18: Team configuration


curl --noproxy member-ip --header X-Auth-Token:auth_token--fail -ksS--request POST --url
https://ip-addr:8443/sdn/v2.0/team --data-binary'{"team":{"ip":"team-ip","members":
[{"ip":"member-1-ip"},{"ip":"member-2-ip"}, {"ip":"member-3-ip"}]}}'

Example
The following example configures a team of three controllers:
~$ curl --noproxy 192.168.56.14 \
--header X-Auth-Token:ccf1e5aedb6d4ae19f1480c55907d970\
--fail -ksS --request POST \
--url https://192.168.56.14:8443/sdn/v2.0/team \

--Data-binary '{"team":{"ip":"192.168.56.10","members": \
[{"ip":"192.168.56.14"},\
{"ip":"192.168.56.15"}, \
{"ip":"192.168.56.16"}]}}'

Result: This script will create a team of three controllers (192.168.56.14, 192.168.56.15 and
192.168.56.16) with a team IP address of 192.168.56.10.
Note
The backslash (\) character at the end of the line indicates that the command continues on the next
line. In the Bash shell, which you use to enter curl commands, a backslash character that is
followed by the newline character is removed from the input stream automatically such that the
command is processed as if it were entered on a single line.
Examples of cURL commands in this study guide use the --noproxy option, which is appropriate
where execution of cURL commands does not need a proxy to access controllers. If your network is
set up such that a proxy is needed to access controllers, use the --proxy option.

View team
Steps
To view the team information, do the following (see Figure 8-19):

Figure 8-19: View team


1. Acquire an authentication token from one of the controllers.
2. Using the token acquired in the preceding step, execute this cURL command to display the team

configuration:
curl --noproxy 192.168.56.10 --header "X-Auth-Token:auth_token" --fail -ksSfL --request
GET --url https://192.168.56.10:8443/sdn/v2.0/team

Example
To view the controllers in the sample topology, the following command could be used:
~$ curl --noproxy 192.168.56.10 \
--header "X-Auth-Token:auth_token" \
--fail -ksSfL --request GET \
--url https://192.168.56.10:8443/sdn/v2.0/team\
| python-mjson.tool
{
"team": {
"ip": "192.168.56.10",
"members": [
{
"ip": "192.168.56.16"
},
{
"ip": "192.168.56.15"
},
{
"ip": "192.168.56.14"
}
],
"revision": 0
}
}

Controller team information


You can view your team and region configuration from the View screen. To access the View screen, click
Team in the controller navigation pane. The View screen is read-only and includes:
Team status (top banner)
Team configuration and controller status (top section)
Region configuration (middle section)

Device owners (bottom section)

Team status
You can view your team status from the top banner of the View screen. The team status indicator refreshes
dynamically to immediately notify you of important team status changes, such as when a 3-node team
changes to a 2-node team. The team status banner displays one of the following for team status:

ACTIVE status
All three controllers are actively operating and a healthy team status message is displayed (see Figure 820).

Figure 8-20: ACTIVE status

Unknown status:
The status is unknown when a team status cannot be determined. An unknown team status message is
displayed (see Figure 8-21).

Figure 8-21: Unknown status

Unreachable status
An unreachable status obtains when any single controller of a team is not able to communicate with the
rest of the team members. A degraded status message will be displayed (see Figure 8-22).

Figure 8-22: Unreachable status

Controller status
From the View screen, the team configuration and controller status (top section) displays the following
fields:
IP: The IP address of the controller
Role: A member or a leader. A team can only have one leader and at most three controllers
Status: The controller status, which can be one of the following:
initializing
active
suspended
unreachable
Version: The build version of the SDN controller software running on the controller
CDV: (core data version) A field that is incremented every time the controller experiences a change in
configuration; HA uses this field to determine which controller to synchronize with when a controller
joins a cluster
CDV Timestamp: The date and time at which the controller experienced its last change in configuration

Create a team of HP VAN SDN Controllers instructions


This section will focus on creating a controller team. Three new controllers (192.168.56.14,
192.168.56.15 and 192.168.56.16) will be used to form a team, as illustrated in Figure 8-23.

Figure 8-23: Create a team of HP VAN SDN Controllers instructions

If you want to watch a video that shows the steps for setting up a controller team, access the HP
Aurasma application on your smartphone and use the application to focus on Figure 8-23. This action will
launch the video.
The instructions will guide you through how to use a Bash script to create the team. The script uses cURL
and the REST API as discussed earlier in this chapter. You will then verify that the team has been created.
Redundancy will be tested by disabling the sdnc service (a core controller service) on members in the
team. Both controller and team states will be viewed.
In a later section, you will review how to configure HP switches to use the new team.

Questions
This section contains questions that will help you retain the information and concepts you learned in
preceding sections.
Question 1: How many controllers are required in a team (version 2.5 of the HP controller)?
Question 1 answer: A controller team requires three controllers.
Note
Source: HP VAN SDN Controller 2.5 Administrator Guide, Section 9.1, page 97. Available at:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647289

Question 2: How many controllers can fail for a team to continue managing OpenFlow switches in the
network?
Question 2 answer: A single controller failure will allow a team to continue to manage switches. If two
controllers fail, the remaining controller moves to the suspend state and the network is no longer managed
by the team.
Note
Source: HP VAN SDN Controller 2.5 Administrator
Guide, Section 9.1, page 97. Available at: http://h20564.www2.hpe.com/hpsc/doc/public/display?
docId=c04647289
Question 3: Is OpenFlow version 1.0 supported with teaming?
Question 3 answer: No, only OpenFlow 1.3 devices are supported when the controllers are teamed.
Note
Source: HP VAN SDN Controller 2.5 Administrator Guide, Section 9.1, page 97. Available at:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647289
Question 4: How many IP addresses need to be allocated to form a team of controllers?
Question 4 answer: Four IP addresses are required for a controller teamone per team member
(controller) and one for the team.
Note
Source: HP VAN SDN Controller 2.5 Administrator Guide, Section 9, page 98. Available at:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04647289

Instructions
1. Check to see if the new controllers are part of a team. Use Google Chrome on the Windows Jumphost
to navigate to: https://192.168.56.14:8443/sdn/ui
When prompted, log in with the following credentials:
Username: sdn
Password: skyline
2. Click Team to view teaming information (see Figure 8-24).

Figure 8-24: Teaming configuration


Result: No team is configured.
3. Open a new tab in Chrome and navigate to: https://192.168.56.15:8443/sdn/ui
When prompted, log in with the following credentials:
Username: sdn
Password: skyline
4. Click Team to view teaming information (see Figure 8-25).

Figure 8-25: Teaming configuration


Result: No team is configured.
5. Open a new tab in Chrome and navigate to: https://192.168.56.16:8443/sdn/ui

When prompted, log in with the following credentials:


Username: sdn
Password: skyline
6. Click Team to view teaming information (see Figure 8-26).

Figure 8-26: Teaming configuration


Result: No team is configured.
7. Currently, each controller has been installed as a standalone controller. Teaming has not been
configured. The controller REST API needs to be used to configure a team.
On the Windows Jumphost, open the make-team script using Notepad++ (right click on the file and
select Edit with Notepad++).
In this example, the file is on the desktop of the Windows Jumphost (see Figure 8-27) as follows:
Folder: \Desktop\SDN Lab Files\Software\2.5 scripts\
File Name: make-team

Figure 8-27: Edit file

Note
If you are following these instructions using a test network, you do not need to edit this file as the
controller values have been preconfigured.
8. This script is using the REST API /sdn/v2.0/team to create the controller team. The following
parameters are required:
Team IP: 192.168.56.10
Controller 1 IP: 192.168.56.14
Controller 2 IP: 192.168.56.15
Controller 3 IP 192.168.56.16
The script uses the cURL to connect to the team uniform resource identifier (URI) and form the team:
curl --noproxy 192.168.56.14 \
--header X-Auth-Token:$token \
--fail -ksS --request POST \
--url https://192.168.56.14:8443/sdn/v2.0/team \
--Data-binary '{"team":{"ip":"192.168.56.10","members": \
[{"ip":"192.168.56.14"},\
{"ip":"192.168.56.15"}, \
{"ip":"192.168.56.16"} \
]}}'

Result: This script will create a team of three controllers (192.168.56.14, 192.168.56.15, and
192.168.56.16) with a team IP address of 192.168.56.10.
Note
The team IP address is only used by the REST API. Neither the Java API nor the OpenFlow
channels from the switches used the team IP address. Three controller connections are configured
on switches to provide redundancy on the southbound API.
9. Upload the make-team file to the DNS server (see Figure 8-28).
Folder: \Desktop\SDN Lab Files\Software\2.5 scripts\
File Name: make-team

Figure 8-28: Upload file


10. If not already open, use PuTTY to SSH to the DNS server:
IP address: 192.168.56.50
Username: sdn
Password: skyline
11. Run the make-team script (the team formation may take a while) as follows:
sdn@CoreDHCPDNSNTP:~$ sudo bash ./make-team
===============================================================
Token:
581e40d25f794c83ba17d2218f6a76ce
Creating Team...
Team creation script finished
Verifying team...
{
"team": {
"ip": "192.168.56.10",
"members": [
{
"ip": "192.168.56.16"
},
{
"ip": "192.168.56.15"

},
{
"ip": "192.168.56.14"
}
],
"revision": 0
}
}
===============================================================
sdn@CoreDHCPDNSNTP:~$

Result: The team is created.


12. The GUIs of the controllers will not be available while the team forms. Refresh the controller pages
after a while to see the team status. You may see the message illustrated in Figure 8-29 until the team
has been formed:

Figure 8-29: Controller team not available yet


13. Start a ping to the controller team IP address. This will be an indication of when the controller team
has formed (this may take a while).
sdn@CoreDHCPDNSNTP:~$ ping 192.168.56.10
PING 192.168.56.10 (192.168.56.10) 56(84) bytes of data.
From 192.168.56.50 icmp_seq=1 Destination Host Unreachable
From 192.168.56.50 icmp_seq=2 Destination Host Unreachable
From 192.168.56.50 icmp_seq=3 Destination Host Unreachable
.. <ommitted>...
64 bytes from 192.168.56.10: icmp_req=1 ttl=64 time=0.479 ms
64 bytes from 192.168.56.10: icmp_req=2 ttl=64 time=0.149 ms

14. Open a new tab in Chrome and navigate to: https://192.168.56.10:8443/sdn/ui.


When prompted, log in with the following credentials:

Username: sdn
Password: skyline
15. Click Team to view the team information (see Figure 8-30).

Figure 8-30: Teaming information


The team configuration and controller status (top section) displays the following fields:
IP: IP address of the controller
Role: A member or a leader; a team consists of three controllers, one of which is the leader
Status: The controller status, which can be one of the following:
initializing
active
suspended
unreachable
Version: The build version of the SDN controller software running on the controller
CDV: A field that is incremented every time the controller experiences a change in configuration; HA
uses this field to determine which controller to synchronize with when a controller joins a cluster
CDV Timestamp: The date and time at which the controller experienced its last change in
configuration

Questions
The following questions will help you retain what you have learned in this section.
Question 1: Which controller became the team leader?
Question 1 answer: The team leader is calculated internally by controller algorithms and cannot be
manually configured. Your team leader may be a different controller. In this example, controller
192.168.56.14 became the team leader.

Question 2: What is team health status?


Question 2 answer: (see Figure 8-31)

Figure 8-31: Teaming status


Result: The team is healthyall controllers are ACTIVE.
For version 2.5 HP VAN SDN Controllers, the team states are:
ACTIVE: All three controllers are actively operating. For example, teamed controllers are active
when all controllers are able to communicate with each other.
UNREACHABLE: Any single controller of a team is not able to communicate with the rest of the
team members. This status occurs because of either of the following two possible situations:
The sdnc service stopped working or a controller got rebooted.
A network partition happened and a controller in a team is separated from the other team members.
UNKNOWN: A team status cannot be determined because of either of the following possible
situations:
A communication failure with a REST service component
A network failure caused the controller to be suspended
16. Use PuTTY on the Windows Jumphost to SSH to the leader of the team:
IP address: 192.168.56.14 (Or the leader in your team)
Port number: 22
Protocol: SSH
Username: sdn
Password: skyline

17. Stop the controller service as in the following example (use a password of skyline if prompted):
sdn@sdnctl4:~$ sudo service sdnc stop
[sudo] password for sdn:
sdnc stop/waiting
sdn@sdnctl4:~$

Result: A message displays indicating a controller team issue (see Figure 8-32).

Figure 8-32: Team Status unknown


The sdnc service
A network partition
A communication failure
A network failure
The team status indicator refreshes dynamically to immediately notify you of important team status
changes, such as when a three-node team changes to a two-node team. The team status banner displays
one of the following team statuses, which are shown in Figure 8-33:

Figure 8-33: Team status


18. Refresh the team page. In the example shown in Figure 8-34, the leader failed, so the leadership role
has changed. You will need to log in again.

Figure 8-34: Team status unreachable


Result: The team shows a degraded status. Member 192.168.56.14 is shown as unreachable. The
remaining two members are shown as active.
A new leader is elected. In the above figure, 192.168.56.16 has become the new leader.
19. Start the controller service (use a password of skyline if prompted):
sdn@sdnctl4:~$ sudo service sdnc start
sdnc start/running, process 3059
sdn@sdnctl4:~$

20. Refresh the page when the status changes to show that the one member is initializing (see Figure 835).

Figure 8-35: Team status unknown

Note
It may take a few minutes for the controller services to start and for the controller to join the team.

21. After a while the team status should change back to ACTIVE, as shown in Figure 8-36. Refresh the
page to update the controller Status and CDV information.

Figure 8-36: Team active.


Result: The previous leader (192.168.56.14) has joined the team as a member. The current leader
(192.168.56.16) remains the leader.

Questions
Answering the following questions will help you prepare for the exam.
Question 1: How many controllers are required in a team?
Question 2:How many controllers can fail for a team to still manage OpenFlow switches?
Question 3: Can an administrator influence controller leadership?
Question 4: When a team leader is rebooted, will it become the leader again when it rejoins the team?
Question 1 answer: A controller team consists of three controllers.
Question 2 answer: The threshold for controller fault tolerance is 2n+1, where n is the number of failed
controllers allowed in an active team. HP VAN SDN Controller teaming supports a team of three
controllers. In a team of three controllers, n = 1 which means that one controller in a team of three can fail
without suspending team operation.
Question 3 answer: Team leaders are elected using controller internal mechanisms. An administrator
cannot configure a value like priority to influence team leader selection.
Question 4 answer: If the team leader fails, the team will elect a new team leader. If the original team
leader returns to operation, it will join the team as a member. It will not become the team leader.

Regions
Overview
To support HA of controllers for OpenFlow switches, create region configurations in the team using the
REST APIs provided by the Device Owner Service. A region groups devices together with their
controllers. Every region has a unique identifier (UID) assigned upon creation. Some REST commands
will require the UID to manage the region.
A region must have three controllers which must be specified in priority order for all devices within the

region (master, primary slave, and secondary slave), which is illustrated in Figure 8-37. Devices in a
region can be expressed as a list of individual IPv4 addresses, a list of IPv4 ranges, or a combination of
both.

Figure 8-37: Regions


The Device Owner Service provides HA between devices and controllers and ensures the availability of
a controller to the devices. The Device Owner Service also provides a measure of security; only devices
explicitly included in a region can connect to the regions controllers. Thus, if no regions are defined for
the teamed controllers, then no devices will be able to connect to the controllers.
Putting the region configurations in place for a controller team ensures seamless failover and failback
among the configured controllers for the specified network devices in a region. That is, when a controller
experiences a fault, the Device Owner Service ensures that a slave controller immediately assumes the
master role over the group of network devices for which the failed controller was master.
Once the failed controller recovers and rejoins the team, the Device Owner Service ensures restoration
of this controllers role. That is, the rejoining controller takes back the role for which it was configured
with respect to the other network devices. If the controller was configured to operate as the master in a
region, then it would be restored to the master role. If it was configured to operate in the slave role, it
would resume operation in the slave role.
Once the region definitions are in place, the Device Owner Service ensures that a master controller is
always available to the respective network elements even if the configured master fails, or there is a
disruption of the communication channel between the controller and the network devices.

Prerequisite
OpenFlow 1.3 devices must be configured with the IP addresses of the three controllers in the team. This
allows one of the controllers to later, once the controller team is formed and the regions are configured on
the controllers, assert itself as the master of a given device. The device then automatically assigns a role
of slave to the other two configured controllers. This ensures that the master knows of all events
happening on the device while the slaves are kept up to date on a subset of events.
A region cannot be created until a team has formed.

Failover
Device Owner Service triggers the failover operation in two cases:
Controller failure: The Device Owner Service detects a controller failure in a team through

notifications from the teaming subsystem. If Device Owner Service determines that the failed
controller instance was a master for any devices within a region, it immediately elects an appropriate
backup (slave) controller to assume the master role over the affected devices.
Device disconnect: The Device Owner Service instance in a controller is notified of a communication
failure with network devices through the Controller Service notifications. It communicates with all
Device Owner Service instances in the team to determine if the network devices in question are still
connected to any of the backup (slave) controllers within the team. If that is the case, it elects one of
the slaves to assume the master role over the affected network devices. The first slave will be chosen
as master if it still has connectivity with the devices, and the second slave will be chosen as master if
neither the configured master nor first slave has connectivity with the devices.

REST API authentication


A token is required for the REST API region configuration. Acquire a token using either the team IP
address or one of the team member IP addresses.
Use the following cURL command to acquire the token (see Figure 8-38):

Figure 8-38: REST API authentication


curl --noproxycontroller_ip -X POST --fail -ksSfL --url
"https://controller_ip:8443/sdn/v2.0/auth" -H "Content-Type:
application/json" --data-binary '{"login": {"domain":
"domain","user": "user","password": "password"}}'

In this example, a username of sdn and password of skyline is used:


~$ curl --noproxy 192.168.56.31 -X POST --fail -ksSfL --url
"https://192.168.56.31:8443/sdn/v2.0/auth" -H "Content-Type:application/json" --databinary '{"login":{"user":"sdn","password":"skyline","domain":"sdn"}}'

{"record":
{"token":"ccf1e5aedb6d4ae19f1480c55907d970","expiration":1437557415000,"expirationDate":"20
07-22 05-30-15
-0400","userId":"9c081cbe3eeb4dbab658090bb70d08f0","userName":"sdn","domainId":"118c46e61b4
["sdn-user","sdn-admin"]}}sdn@sdn-ctl:~/scripts$

The token returned by the controller in this example is: ccf1e5aedb6d4ae19f1480c55907d970

Note
For
more
information
about
http://curl.haxx.se/docs/manpage.html.

cURL,

visit:

http://curl.haxx.se

and

Region configuration
This POST command adds a region to devices configured on the controller and propagates the
modifications to each controller in the team. All controllers configured for the team must be available for
such a configuration change to be permitted.
In this example, we are adding a region that has three controllers: 192.168.56.14 (master), 192.168.56.15
(primary slave), and 192.168.56.16 (secondary slave). Two devices are part of the region:
192.168.56.251 and 10.1.1.252 (see Figure 8-39).

Figure 8-39: Region configuration


curl --noproxy 192.168.56.10 --header "X-Auth-Token:$token" \
--header "Content-Type:application/json" --fail -ksS \
--request POST \
--url https://192.168.56.10:8443/sdn/v2.0/owners/ \
--data-binary '
{
"region": {
"name": "Region252",
"prioritizedControllerIps":[
"192.168.56.14",

"192.168.56.15",
"192.168.56.16"
],
"deviceIps": [
"192.168.56.251",
"10.1.1.252"
]}}'

The following message is returned on successful region creation:


{"region":{"uid":"4c3bbe5f-bab2-460f-a54ef0cd21d5a6df","name":"Region252","prioritizedControllerIps":
["192.168.56.14","192.168.56.15","192.168.56.16"],"deviceIps":
["10.1.1.252","192.168.56.101"]}}

View regions
From the Team view screen, the region configuration (middle section) displays the following fields:
Name: Name of the region
Controller by Priority: First controller (in bold) is the master controller for the region. The master
controller handles the flows and packet-ins. The following controllers (grayed out) are slaves. If the
highest priority controller is unavailable, HA failsover to the next highest priority device in the region
configuration for that device.
Region UID: Identifies a region, used by certain REST API commands (see Figure 8-40)

Figure 8-40: Region UID in the Team view

To view a regions details, click on the desired region (see Figure 8-41).

Figure 8-41: Region details


The regions details include the following fields:
Ranges: The configured ranges (IP ranges)
Devices: List of IP addresses one-by-one

Comware configuration
Multiple controllers
Figure 8-42 shows the configuration of multiple controllers on an HP Comware switch. In this example,
three controllers in the team are configured on the switch. The switch does not determine which
controller is its master controllerthe controllers inform the switch.

Figure 8-42: Comware configuration


This is done using OpenFlow Role-Request messages. Role-Request messages are used by the controller
to set the role of its OpenFlow channel, or to query this role.
The OpenFlow specification states the following:

The switch may establish communication with a single controller, or may establish communication with
multiple controllers. Having multiple controllers improves reliability, as the switch can continue to
operate in OpenFlow mode if one controller or controller connection fails. The hand-over between
controllers is entirely managed by the controllers themselves, which enables fast recovery from failure
and also controller load balancing. The controllers coordinate the management of the switch amongst
themselves via mechanisms outside the scope of the present specification, and the goal of the multiple
controller functionality is only to help synchronize controller handoffs performed by the controllers. The
multiple controller functionality only addresses controller fail-over and load balancing, and doesn't
address virtualization which can be done outside the OpenFlow protocol.
The default role of a controller is OFPCR_ROLE_EQUAL. In this role, the controller has full access to
the switch and is equal to other controllers in the same role. By default, the controller receives all the
switch asynchronous messages (such as packet-in and flow-removed messages). The controller can send
controller-to-switch commands to modify the state of the switch. The switch does not do any arbitration
or resource sharing between controllers.
A controller can request its role to be changed to OFPCR_ROLE_SLAVE. In this role, the controller has
read-only access to the switch.
A controller can request its role to be changed to OFPCR_ROLE_MASTER. This role is similar to
OFPCR_ROLE_EQUAL and has full access to the switch, the difference is that the switch ensures it is
the only controller in this role. When a controller changes its role to OFPCR_ROLE_MASTER, the
switch changes all other controllers with the role OFPCR_ROLE_MASTER to have the role
OFPCR_ROLE_SLAVE, but does not affect controllers with role OFPCR_ROLE_EQUAL. When the
switch performs such role changes, no message is generated to the controller whose role is changed (in
most cases that controller is no longer reachable).
Note
Source: OpenFlow Switch Specification, Version 1.3.2, Section 6.3.4, Multiple Controllers, page
30. Available at: http://bit.ly/1Lze7FV

Controller mode
Use the controller mode command to configure the connection mode for an OpenFlow instance to
establish connections to controllers.
The following connection modes are available:
Single: When the connection mode is single, an OpenFlow device establishes a connection to only one
controller at a time, and the other controllers back up this controller. When the current connection is
broken, the OpenFlow instance attempts to connect to the next controller until it successfully
establishes a connection.
Multiple: (default mode) When the connection mode is multiple, an OpenFlow device can establish
connections to multiple controllers at a time. When the OpenFlow instance fails to connect to a
controller or the connection to a controller is broken, the OpenFlow instance attempts to reconnect to
the controller after the reconnection interval expires until it successfully establishes a connection to
the controller.

Echo-request interval
An HP Comware OpenFlow switch supports a connection detection interval which is the interval at
which the OpenFlow switch sends an echo request message to a controller. The OpenFlow switch can
send up to three echo request messages. If none of the requests receive a reply, the OpenFlow switch is
disconnected from the controller.
Use controller echo-request interval to set a connection detection interval for an OpenFlow switch.
The default connection detection interval is 5 seconds.

Connect interval
An HP Comware OpenFlow switch supports a reconnection interval, which is the interval for the
OpenFlow switch to wait before it attempts to reconnect to a controller.
Use controller connect interval to set a reconnection interval for an OpenFlow switch. Use undo
controller connect interval to restore the default.
The default reconnection interval is 60 seconds.

ProVision configuration
Multiple controllers
Figure 8-43 shows the configuration of multiple controllers on an HP ProVision switch. In this example,
three controllers in the team are configured on the switch. As discussed, the switch does not determine
which controller is its master controller. This is determined by the controllers, which then inform the
switch.

Figure 8-43: ProVision configuration

Probe-interval

The probe interval is the time between two consecutive probes sent from an instance to the controller.
The default value is 10 seconds.

Max-backoff-interval
You can specify the maximum interval between two consecutive attempts to connect to a controller by an
OpenFlow instance. The interval between two consecutive attempts increases exponentially until it
reaches the specified value. All subsequent attempts use the specified value.
The default value is 60 seconds.

View owners
The Device Owners portion of the View screen (bottom section) displays the following fields (see Figure
8-44):

Figure 8-44: Device Owners section of the View screen


Device: The device IP
Owner Controller: The controller that is considered the current owner of the device (for example, the
configured OpenFlow master)
Region: The region that the device belongs to
Datapath ID: Datapath identifier for the device; a device can have multiple datapaths
Datapath ready: Default flows have been pushed

Integrate HP switches with a team of HP controllers instructions


In this section, you will follow the instructions to configure device regions and configure OpenFlow
switches to connect to multiple controllers, as shown in Figure 8-45.

Figure 8-45: Integrate HP switches with a team of HP controllers instructions

If you want to watch a video that shows the steps for setting up a controller team, access the HP
Aurasma application on your smartphone and use the application to focus on Figure 8-45. This action will
launch the video.
The steps will teach you how to then test that what happens when the master controller fails. Switches
should continue using OpenFlow and use the slave controller as their new master. Failback will also be
tested.
REST API applications should still be able to use the team IP address after the team leader fails. You
will verify that this is the case.

Introduction
To support HA of controllers for OpenFlow switches, you will need to create regions. This is done via
the REST API.
A region groups devices together with their controllers. Every region has a UID assigned upon creation.
Some REST commands will require the UID to manage the region. A region must have three controllers
which must be specified in priority order for all devices within the region (master, primary slave, and
secondary slave). Devices in a region can be expressed as a list of individual IPv4 addresses, a list of
IPv4 ranges, or a combination of both.
The Device Owner Service provides HA between devices and controllers and ensures the availability of
a controller to the devices in a region. The Device Owner Service also provides a measure of security;
only devices explicitly included in a region can connect to the regions controllers. Thus, if no regions are
defined for the teamed controllers, then no devices will be able to connect to the controllers.

Important
Teaming only supports OpenFlow 1.3. Switches need to use OpenFlow 1.3 and regions must be
configured with three controller IP addresses.

Instructions
1. At the moment, no Regions or Owners are configured (see Figure 8-46).

Figure 8-46: Regions


2. On the Windows Jumphost, open the make-regions script using Notepad++ (right click on the file and
select Edit with Notepad++).
The file is on the desktop of the Windows Jumphost as follows:
Folder: \Desktop\SDN Lab Files\Software\2.5 scripts\
File Name: make-regions (see Figure 8-47)

Figure 8-47: Edit file

Note
You will not need to edit this file.
3. This script is using the REST API to create three regions.

Each region has three controllers (which are ordered differently).


Each region has different switches.
In this example, the four switches are configured with OpenFlow:
C1: 192.168.56.251
C2: 10.1.1.252
P1: 10.1.1.253
P2: 10.1.1.254
The two Comware switches will be put in region Region252, Provision switch 1 (P1) will be put in
Region253 and ProVision switch 2 (P2) will be put in Region254. In a production environment, configure
region names that are more descriptive of your environment.
All switches could have been put in a single region if preferred. In this example, three regions are created
to demonstrate that each controller can be the master for a region. There is no requirement that Comware
switches be grouped in the same region.
curl --noproxy 192.168.56.10 --header "X-Auth-Token:$token" \
--header "Content-Type:application/json" --fail -ksS \
--request POST \
--url https://192.168.56.10:8443/sdn/v2.0/owners/ \
--data-binary '
{
"region": {
"name": "Region252",
"prioritizedControllerIps":[
"192.168.56.14",
"192.168.56.15",
"192.168.56.16"
],
"deviceIps": [
"192.168.56.251",
"10.1.1.252"
]}}'
curl --noproxy 192.168.56.10 --header "X-Auth-Token:$token" \
--header "Content-Type:application/json" --fail -ksS \
--request POST \
--url https://192.168.56.10:8443/sdn/v2.0/owners/ \
--data-binary '

{
"region": {
"name": "Region253",
"prioritizedControllerIps":[
"192.168.56.15",
"192.168.56.14",
"192.168.56.16"
],
"deviceIps": [
"10.1.1.253"
]}}'
curl --noproxy 192.168.56.10 --header "X-Auth-Token:$token" \
--header "Content-Type:application/json" --fail -ksS \
--request POST \
--url https://192.168.56.10:8443/sdn/v2.0/owners/ \
--data-binary '
{
"region": {
"name": "Region252",
"prioritizedControllerIps":[
"192.168.56.16",
"192.168.56.15",
"192.168.56.14"
],
"deviceIps": [
"10.1.1.254"
]}}'

4. Upload the make-regions file to the DNS server using FileZilla as follows:
Folder: \Desktop\SDN Lab Files\Software\2.5 scripts\
File name: make-regions (see Figure 8-48)

Figure 8-48: Upload file


5. If it is not already open, use PuTTY to SSH to the DNS server:
IP address: 192.168.56.50
Username: sdn
Password: skyline
6. Run the make-regions script:
sdn@CoreDHCPDNSNTP:~$ sudo bash ./make-regions
===============================================================
Creating regions
===============================================================
{"region":{"uid":"4c3bbe5f-bab2-460f-a54ef0cd21d5a6df","name":"Region252","prioritizedControllerIps":
["192.168.56.14","192.168.56.15","192.168.56.16"],"deviceIps":
["10.1.1.252","192.168.56.101"]}}
{"region":{"uid":"84787caf-9572-4ab9-b37791f08c009296","name":"Region253","prioritizedControllerIps":
["192.168.56.15","192.168.56.14","192.168.56.16"],"deviceIps":["10.1.1.253"]}}
{"region":{"uid":"ec060771-33b9-49ab-be39d1c1f0accd30","name":"Region254","prioritizedControllerIps":
["192.168.56.16","192.168.56.15","192.168.56.14"],"deviceIps":["10.1.1.254"]}}
===============================================================
Finished region creation
===============================================================
sdn@CoreDHCPDNSNTP:~$

Result: The regions are created.


7. View the team information on the controller (192.168.56.10) (see Figure 8-49):

Figure 8-49: Regions created


Result: Three regions have been created. The Controllers By Priority information is also displayed.
8. Click on the region arrows to show devices configured in the region (see Figure 8-50).

Figure 8-50: Region devices


9. Use PuTTY on the Jumphost to SSH to each controller:
Controller 4:
IP address: 192.168.56.14
Username: sdn
Password: skyline

Controller 5:
IP address: 192.168.56.15
Username: sdn
Password: skyline
Controller 6:
IP address: 192.168.56.16
Username: sdn
Password: skyline
10. Verify IP connectivity from each controller to each HP switch:
Controller 4:
sdn@sdnctl4:~$ ping 192.168.56.251
sdn@sdnctl4:~$ ping 10.1.1.252
sdn@sdnctl4:~$ ping 10.1.1.253
sdn@sdnctl4:~$ ping 10.1.1.254

Controller 5:
sdn@sdnctl5:~$ ping 192.168.56.251
sdn@sdnctl5:~$ ping 10.1.1.252
sdn@sdnctl5:~$ ping 10.1.1.253
sdn@sdnctl5:~$ ping 10.1.1.254

Controller 6:
sdn@sdnctl6:~$ ping 192.168.56.251
sdn@sdnctl6:~$ ping 10.1.1.252
sdn@sdnctl6:~$ ping 10.1.1.253
sdn@sdnctl6:~$ ping 10.1.1.254

Results: Pings should succeed.


11. Configure Comware switch 1 with the three new controllers:
<C1> system-view
[C1] undo openflow instance 1
[C1] openflow instance 1
[C1-of-inst-1] controller 14 address ip 192.168.56.14
[C1-of-inst-1] controller 15 address ip 192.168.56.15
[C1-of-inst-1] controller 16 address ip 192.168.56.16

[C1-of-inst-1] controller mode multiple


[C1-of-inst-1] controller echo-request interval 1
[C1-of-inst-1] controller connect interval 10
[C1-of-inst-1] classification vlan 30
[C1-of-inst-1] active instance
[C1-of-inst-1] quit
[C1]

The echo request and connect interval commands are configured for quicker controller failover detection.
Controller mode: Use controller mode to configure the connection mode for an OpenFlow instance to
establish connections to controllers.
12. Comware switch C1 is shown as registered to the team (see Figure 8-51).

Figure 8-51: Owners

Note
If the switch does not register with the team, wait a few minutes.
13. View the OpenFlow controller information:
[C1] display openflow instance 1 controller
Instance 1 controller information:
Reconnect interval: 10 (s)
Echo interval : 1 (s)
Controller ID : 14
Controller IP address : 192.168.56.14

Controller port : 6633


Controller role : Master
Connect type : TCP
Connect state : Established
Packets sent : 583
Packets received : 577
SSL policy : -VRF name : -Controller ID : 15
Controller IP address : 192.168.56.15
Controller port : 6633
Controller role : Slave
Connect type : TCP
Connect state : Established
Packets sent : 315
Packets received : 317
SSL policy : -VRF name : -Controller ID : 16
Controller IP address : 192.168.56.16
Controller port : 6633
Controller role : Slave
Connect type : TCP
Connect state : Established
Packets sent : 315
Packets received : 317
SSL policy : -VRF name : -[C1]

Result: Controller 192.168.56.14 is the master controller and 192.168.56.15 and 192.168.56.16 are
slave controllers.
14. Configure Comware switch 2 (C2) with the three new controllers:
<C2> system-view

[C2] undo openflow instance 1


[C2] openflow instance 1
[C2-of-inst-1] controller 14 address ip 192.168.56.14
[C2-of-inst-1] controller 15 address ip 192.168.56.15
[C2-of-inst-1] controller 16 address ip 192.168.56.16
[C2-of-inst-1] controller mode multiple
[C2-of-inst-1] controller echo-request interval 1
[C2-of-inst-1] controller connect interval 10
[C2-of-inst-1] classification vlan 20
[C2-of-inst-1] active instance
[C2-of-inst-1] quit
[C2]

15. Configure OpenFlow on ProVision switch 1 (P1):


P1# conf
P1(config)# no openflow
All OpenFlow configuration will be deleted.
Continue (y/n)? y
P1(config)# openflow
P1(openflow)# controller-id 14 ip 192.168.56.14 controller-interface vlan 1
P1(openflow)# controller-id 15 ip 192.168.56.15 controller-interface vlan 1
P1(openflow)# controller-id 16 ip 192.168.56.16 controller-interface vlan 1
P1(openflow)# instance vlan30
P1(of-inst-vlan30)# controller-id 14
P1(of-inst-vlan30)# controller-id 15
P1(of-inst-vlan30)# controller-id 16
P1(of-inst-vlan30)# version 1.3
P1(of-inst-vlan30)# probe-interval 1
P1(of-inst-vlan30)# max-backoff-interval 3
P1(of-inst-vlan30)# member vlan 30
P1(of-inst-vlan30)# enable
P1(of-inst-vlan30)# exit
P1(openflow)# enable
P1(openflow)# end

P1#

Important
Teaming in version 2.5 of the HP VAN SDN Controller only supports OpenFlow version 1.3. By
default, ProVision switches use OpenFlow version 1.0. Make sure you configure version 1.3 on the
ProVision switches.
16. View the updated switch information on the controller team page, shown in Figure 8-52.

Figure 8-52: Owners


Result: Three switches are shown. C1 (192.168.56.251) and C2 (10.1.1.252) are in region Region252
and P1 (10.1.1.253) is in region Region253.
17. Configure OpenFlow on ProVision Switch 2 (P2):
P2# conf
P2(config)# no openflow
All OpenFlow configuration will be deleted.
Continue (y/n)? y
P2(config)# openflow
P2(openflow)# controller-id 14 ip 192.168.56.14 controller-interface vlan 1
P2(openflow)# controller-id 15 ip 192.168.56.15 controller-interface vlan 1
P2(openflow)# controller-id 16 ip 192.168.56.16 controller-interface vlan 1
P2(openflow)# instance vlan40
P2(of-inst-vlan40)# controller-id 14
P2(of-inst-vlan40)# controller-id 15
P2(of-inst-vlan40)# controller-id 16
P2(of-inst-vlan40)# probe-interval 1
P2(of-inst-vlan40)# version 1.3
P2(of-inst-vlan40)# max-backoff-interval 3
P2(of-inst-vlan40)# member vlan 40
P2(of-inst-vlan40)# enable
P2(of-inst-vlan40)# exit

P2(openflow)# enable
P2(openflow)# end
P2#

18. View the updated switch information on the controller team page, shown in Figure 8-53.

Figure 8-53: Owners


Result: The four switches are registered with the controller.
19. If not already open, use PuTTY on your Windows VM (Jumphost) to connect to Controller
192.168.56.14 using SSH as follows:
IP address: 192.168.56.14
Port number: 22
Protocol: SSH
Username: sdn
Password: skyline
20. Stop the controller service (use a password of skyline if prompted):
sdn@sdnctl4:~$ sudo service sdnc stop
[sudo] password for sdn:
sdnc stop/waiting
sdn@sdnctl4:~$

21. View the change on the HP controller (see Figure 8-54).

Figure 8-54: Owners.

Questions
Question 1: Which controller is the master controller for the Comware switches?
Question 1 answer: The master controller for region 252the region that includes the Comware
switchesis 192.168.56.14.
Question 2: Which controller is the owning controller for the Comware switches? Why was this
controller selected?
Question 2 answer: The owning controller for the Comware switches is 192.168.56.15. This controller
is the primary backup controller in the region. Thus, when the master controller failed, this controller
became the master.

Instructions cont.
1. View the controller information on Comware switch 1 (C1):
[C1]display openflow instance 1 controller
Instance 1 controller information:
Reconnect interval: 10 (s)
Echo interval : 1 (s)
Controller ID : 14
Controller IP address : 192.168.56.14

Controller port : 6633


Controller role : -Connect type : TCP
Connect state : Idle
Packets sent : 0
Packets received : 0
SSL policy : -VRF name : -Controller ID : 15
Controller IP address : 192.168.56.15
Controller port : 6633
Controller role : Master
Connect type : TCP
Connect state : Established
Packets sent : 1946
Packets received : 1911
SSL policy : -VRF name : -Controller ID : 16
Controller IP address : 192.168.56.16
Controller port : 6633
Controller role : Slave
Connect type : TCP
Connect state : Established
Packets sent : 1869
Packets received : 1871
SSL policy : -VRF name : -[C1]

Result: Controller 192.168.56.14 is idle. Controller 192.168.56.15 is the master controller and
192.168.56.16 is a slave controller.
2. View the controller information on ProVision switch 1 (P1):
P1# show openflow instance vlan30

Configured OF Version : 1.3


Negotiated OF Version : 1.3
Instance Name : vlan30
Data-path Description :
...<omitted>...
Probe Interval : 1 seconds
Hw. Table Miss Count : NA
No. of Sw Flow Tables : 1
Egress Only Ports : None
Table Model : Policy Engine and Software

P1#

Result: Controller 14 is disconnected.


3. Start the controller service:
sdn@sdnctl4:~$ sudo service sdnc start
sdnc start/running, process 5194
sdn@sdnctl4:~$

4. Once the controller has joined the team, determine which controller is the master controller for the
Comware switches (see Figure 8-55). Why was this controller selected?

Figure 8-55: Owners


[C1] display openflow instance 1 controller
Instance 1 controller information:
Reconnect interval: 10 (s)
Echo interval : 1 (s)
Controller ID : 14
Controller IP address : 192.168.56.14
Controller port : 6633
Controller role : Master
Connect type : TCP
Connect state : Established
Packets sent : 247
Packets received : 209
SSL policy : -VRF name : -Controller ID : 15
Controller IP address : 192.168.56.15
Controller port : 6633
Controller role : Slave

Connect type : TCP


Connect state : Established
Packets sent : 2539
Packets received : 2442
SSL policy : -VRF name : -Controller ID : 16
Controller IP address : 192.168.56.16
Controller port : 6633
Controller role : Slave
Connect type : TCP
Connect state : Established
Packets sent : 2338
Packets received : 2340
SSL policy : -VRF name : -[C1]

The master controller is 192.168.56.14. This controller is the primary controller in the region. When it
rejoins the team, it becomes the master controller again.
5. If not already open, open another tab in Chrome, browse to the SDN Toolkit application
(192.168.56.54), and log in with the following credentials:
Username: sdn
Password: skyline
6. Add the teaming IP address to the SDN Toolkit application (see Figure 8-56):

Figure 8-56: Add controller


7. Fill in the following details and click Save:
Name of Controller: Team
IP Address: 192.168.56.10

Username: sdn
Password: skyline
Domain: sdn(see Figure 8-57)

Figure 8-57: Add Controller details


8. Select Manage Switches and then select Team (see Figure 8-58).

Figure 8-58: Manage switches


9. Switches registered with the team are shown in Figure 8-59:

Figure 8-59: Registered switches


Result: The application has used the HP VAN SDN Controller team northbound IP address to retrieve
information.
10. Optionally, you can use cURL to retrieve registered switches. On the Windows Jumphost, open the
get-team-datapaths script using Notepad++ (right click on file and select Edit with Notepad++) (see
Figure 8-60).
The file is on the desktop of the Windows Jumphost as follows:
Folder: \Desktop\SDN Lab Files\Software\2.5 scripts\
File Name: get-team-datapaths

Figure 8-60: Edit the file, get-team-datapaths

Note
You will not need to edit this file.
11. This script is once again using the REST API to retrieve OpenFlow switch DPIDs. However, the
controller against which the REST API made its call is the team IP address rather than a single

controller.
curl -sk -H "X-Auth-Token:$token" \ https://192.168.56.10:8443/sdn/v2.0/of/datapaths \
| python -mjson.tool | more

12. Upload the get-team-datapaths file to the DNS server as follows:


Folder: \Desktop\SDN Lab Files\Software\2.5 scripts\
File Name: get-team-datapaths (see Figure 8-61)

Figure 8-61: Upload file


13. If not already open, use PuTTY to SSH to the DNS server:
IP address: 192.168.56.50
Username: sdn
Password: skyline
14. Run the get-team-datapaths script:
sdn@CoreDHCPDNSNTP:~$ sudo bash ./get-team-datapaths
===============================================================
{
"datapaths": [
{
"capabilities": [
&quo