HP VAN SDN Controller 2.4.

5 Release Notes

Abstract
This document contains supplemental information for the HP VAN SDN Controller Release 2.4.5.

HP Part Number: 5998-7077

Published: November 2014
Edition: 1

 Copyright 2013, 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's
standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty
statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable
for technical or editorial errors or omissions contained herein.
The HP VAN SDN Controller license text is in /opt/sdn/legal/EULA.txt. The HP VAN SDN Controller incorporates materials from several Open Source
software projects. Therefore, the use of these materials by the HP VAN SDN Controller is governed by different Open Source licenses. Refer to
/opt/sdn/legal/HP-SDN-CONTROLLER-OPENSOURCE-LIST.pdf for a complete list of the materials used.
Acknowledgements
UNIX is a registered trademark of the Open Group.
Java and Oracle are registered trademarks of Oracle and/or its affiliates.
OpenFlow is a trademark of the Open Networking Foundation. Open Source is a trademark of the Open Source Initiative. Linux is a trademark of Linus
Torvalds. Ubuntu is a trademark of Canonical Group Limited.
Warranty
For the software end user license agreement and the hardware limited warranty information for HP Networking products, visit http://www.hp.com/
networking/support.
Open Source Software
For information on licenses for the open source software used by the HP VAN SDN Controller, see the HP VAN SDN Controller Open Source and
Third-Party Software License Agreements document.
For information on acquiring the open source code for the HP VAN SDN Controller, send an email to [email protected].
HP Security Policy and Release Notes
A Security Bulletin is the first published notification of security vulnerabilities and is the only communication vehicle for security vulnerabilities.
Fixes for security vulnerabilities are not documented in manuals, release notes, or other forms of product documentation.
A Security Bulletin is released once all vulnerable products still in support life have publicly available images that contain the fix for the security vulnerability.
To find any Security Bulletins for the HP VAN SDN Controller, visit the HP Support Center at
www.hp.com/go/hpsc and do the following.
1.

In the Search: HP Support Center field in the upper right quadrant of the page, enter J9863AAE and hit the Enter key.

2.

Click on Advanced Search.

3.

Under Search only:, deselect all checkboxes except Advisories, bulletins, announcements and Security bulletins (Archive).

4.

Click on Search.

To initiate a subscription to receive further HP Security Bulletin alerts via email, visit the HP Support Center atwww.hp.com/go/hpsc and do the following:
1.

Under Enter a product name or number enter J9863AAE.

2.

Click on Go.

3.

Click on Sign up now for customized driver, security, patch and support email alerts.

4.

Scroll to the bottom of the page, enter the required information, and click on Subscribe.

HP VAN SDN Controller Software Release 2.4.5

Description
For the latest version of these release notes and HP VAN SDN Controller 2.4 user guides, see the HP
Networking support search site.
1. Open your browser and go to: www.hp.com/support/manuals.
2. Use the tools provided to search by product name (for example, VAN SDN Controller) or product
number.
Detailed information about the selected product displays, including a list of Support options in
the left column.

Update recommendation
Recommended

Supersede information
Supersedes HP VAN SDN Controller release 2.4.3 and 2.4.4 (never released).

Enhancements
None

Release 2.4.5 Fixes

The controller process was brought down in some cases when using the system console (CR_161380)
Input to the system console caused the SDNA (Admin) process and the SDNC (controller) to go down.
Using Telnet/SSH to access the system for controller installation avoided the problem.
Controller installation and verification fails (CR_161462) Using sudo dpkg l hp-sdn-ctl in
the controller installation process indicated a controller installation failure. A dependency on the arping
package conflicted with the iputils-arping package prevented correct controller installation.
The controller generates an unsupported flow exception for a flow supported in table 200 on ProVision
OpenFlow switches (CR_161512) For switches running software release x.15.16.nnnn the controller
was limited to accepting only flows for set-fields supported in software release x.15.15.nnnn. In release
2.4.3, overriding this problem required specifying table ID 200, which caused the flow mod facet to
be skipped. Release 2.4.5 removes the problem by enabling the setting of any set-field that the switch
itself reports in the OpenFlow handshake.

Release 2.4.5 issues and workarounds

NOTE:

This set of issues and workarounds applies to both release 2.4.3 and 2.4.5.

Switches operating under an SDN controller while also connected to uncontrolled switches may result
in network loop inside the controller-operated switches (CR_141580) Allowing such connections
can create broadcast loops inside the OpenFlow network. Workaround: Avoid connecting OpenFlow
switches in a controller domain in a loop topology with switches outside the domain.
Intermittent schema disagreement exception in log files (CR_148457) This exception occurs in the
database server version 1.2.3, and the only visible symptom is an exception in the controller log file.
Workaround: Restart the controller.
Intermittant data loss when connectivity to a team node is lost (CR_153341) This can result in a loss
of the team leader and information for links, nodes, or devices. Workaround: Restart the controllers.
The correct discovery of the network topology by OpenFlow and the SDN controller can be hampered
by various factors (CR_155071) Workaround: A white paper titled HP SDN Controller Link Discovery,

HP VAN SDN Controller Software Release 2.4.5

which recommends best practices to follow and known issues to avoid, is available in the HP SDN
Information Library at http://www.hp.com/go/sdn/infolib.
5500HI/EI switches forwarding packets with an LLDP_multicast MAC (link-local MAC) injected by the
controller to one OpenFlow port and out other OpenFlow ports (CR_156231) . Workaround: Fixed
in 5500HI software release R5501P05. For information on 5500EI operation, see the latest version
of the HP VAN SDN Controller and Applications Support Matrix.
Loss of packets through the network (CR_156810) Occurs if controller release 2.3 is used with
switch software releases x.15.16 Workaround: If using switch software release x.15.16 in your
network, upgrade the controller to release 2.4.3 or greater.
(CR_156992) Host move results in lost contact The path paved to the host at its original location is
only removed from the switch after 60 seconds of the match field not being hit. If traffic is constantly
going to the host, then its old path does not get deleted, resulting in all traffic being forwarded to the
host's old location and getting dropped. Workaround: Configure the hard timeout so that the switch
deletes the flow after the hard timeout, which results in ARP flows being paved appropriately based
on the new host location.
Path paving does not forward at line-rate on the 3500 switches (or on any PVOS v1 switch modules,
such as the 5400/8200 switches) (CR_157856) This is a data-plane performance issue in
OpenFlow-only mode. Workaround: The following steps fix the issue and set path paving functions
properly at line-rate. In this case, edit the constraint entries to match what is shown below:
1. Change the priorities and cookie value for the following constraints in
/opt/sdn/condig/ctl/flow-constraints.xml:
<constraint id="com.hp.sdn.l3.path" type="ABSOLUTE" priority="29999"
cookie="fffa"/>
<constraint id="com.hp.sdn.l2.path" type="ABSOLUTE" priority="28888"
cookie="fffe"/>
2. Restart the controller with sudo service sdnc restart.
Path paving flows have incorrect flow class association (CR_157868) When paths are paved by a
controller with the hybrid.mode = false setting, the PathDaemon uses two different flow classes to pave
paths. For release 2.4.3 and greater, L2 path paving is done at priority 29999 and L3 path paving
is done at priority 28888 (see CR157856 for a related issue). Workaround: Apply the workaround
provided for CR_157856, above. Note that this solution exchanges the cookie values.
Firewall rules not updated correctly (CR_158475) When the controller OS reboots, the default drop
rule used to secure the team message bus may be removed. Workaround: Manually re-add the rule
after the OS restarts:

iptables -A INPUT -p tcp --dport 5700 -j REJECT

iptables -A OUTPUT -p tcp --dport 5700 -j REJECT

HP VAN SDN Controller Software Release 2.4.4

Never released.

HP VAN SDN Controller Software Release 2.4.3

Enhancements
Path Daemon changes from release 2.3 to release 2.4.3

In release 2.3, Path Daemon paved L2 paths by pushing flowmods to match source and destination
Mac addresses. In release 2.4.3 and greater, Path Daemon paves L3 paths if packets eth type

HP VAN SDN Controller Software Release 2.4.3

is IPv4 and pushes flow mods to match source and destination IP addresses. This change optimizes
forwarding for PVOS devices, and improves Node learning performance.

In release 2.3, even though Path Daemon only paved paths in pure Openflow mode, it still handled
all PACKET_INs. If it received a packet that it did not explicitly request for, it would send a
PACKET_OUT with forward Normal rule. But in release 2.4.3, any PACKET_INs received in
Hybrid mode that it had not explicitly requested for will be dropped. The rationale behind this
change is that the SDN VAN Controller only handles packets for which it is familiar. This will
cause cbench-style tests to show the controller as handling zero PACKET_IN messages while this
behavior is now expected because the controller did not push rules to the switch which would
have caused the packets to be stolen to the controller.

Topology Manager changes from release 2.3 to release 2.4.3

com.hp.sdn.ctl.topo.impl package has been revised; topology computation and cluster computation
methods have been moved to the com.hp.sdn.topo package.

Following are the specific API changes in Topology Data, DefaultTopologyData, and
TopologyService Java interfaces.

TopologyData in com.hp.sdn.topo
New APIs :
Table 1
New API

Description

Map<com.hp.ds.graph.Vertex,Set<com.hp.ds.graph.Edge>> For a given Device Id, get a map of devices and links on
broadcastPoints(DeviceId deviceId)
which a packet can be broadcast from the given deviceId.
Set<Path> getPaths(DeviceId src, DeviceId dst)

Returns the paths from the given source vertex to a given

destination vertex

Set<Path> getPaths(DeviceId src, DeviceId dst, LinkWeight

linkweight)

Get the set of shortest paths computed using the supplied

edge weight.

Modified APIs:
Table 2
Old API

Description

com.hp.ds.graph.GraphPathSearch.Result Returns the graph path

searchResults(DeviceId deviceId)
search result containing
paths from the given
source vertex to all other
vertexes.

New API

Description

com.hp.ds.graph.Graph
graph()

Returns the graph model of

the network

DefaultTopologyData in com.hp.sdn.topo.compute.impl
New APIs:
Table 3
New API

Description

Map<com.hp.ds.graph.Vertex,Set<com.hp.ds.graph.Edge>> For a given Device Id, get a map of devices and links on
broadcastPoints(DeviceId deviceId)
which a packet can be broadcast from the given deviceId.
Set<Path> getPaths(DeviceId src, DeviceId dst)

Returns the paths from the given source vertex to a given

destination vertex

Set<Path> getPaths(DeviceId src, DeviceId dst, LinkWeight

linkweight)

Get the set of shortest paths computed using the supplied

edge weight.

Modified APIs:
HP VAN SDN Controller Software Release 2.4.3

Table 4
Old API

Description

New API

Description

com.hp.ds.graph.GraphPathSearch.Result
searchResults(DeviceId deviceId)

Returns the graph path com.hp.ds.graph.Graph Returns the graph model of

search result containing graph()
the network
paths from the given
source vertex to all other
vertexes.

TopologyService in com.hp.sdn.topo
New APIs:
Table 5
New API

Description

Topology getTopology();

Returns the current topology information

Set<Path> getPaths(DeviceId src, DeviceId dst);

Returns all shortest paths between the specified source and

destination infrastructure devices, measuring link edge weight
using hop count

Set<Path> getPaths(DeviceId src, DeviceId dst, LinkWeight

weight);

Returns all shortest paths between the specified source and

destination infrastructure devices using the supplied link edge
weight function.
NOTE: The L2Path path(DataPathId source, DataPathId dest)
API has been removed. However, the getPaths(DeviceId src,
DeviceId dst, LinkWeight weight); API provides equivalent
functionality.

Set<TopologyListener> getListeners();

Returns the set of listeners for topology-related events

Set<DeviceId> getClusterDevices(TopologyCluster cluster);

Returns the set of devices contained within the specified cluster

Modified APIs:
Table 6

Old API

Description

boolean pathExists(DataPathId source,

DataPathId dest);

Verifies if a L2
boolean pathExists(DeviceId src, DeviceId
path exists
dst);
between given
source and
destination switch.

boolean participateInBroadcast(DataPathId
switchDpid, BigPortNumber portId);

Indicates if the
given switch-port
pair can
participate in
flood action

boolean isConnectionPoint(DataPathId
switchDpid,BigPortNumber portId);

Indicates if the
boolean isInfrastructure(ConnectionPoint
given port,
point);
belonging to the
specified node is
participating in an
interconnect link

HP VAN SDN Controller Software Release 2.4.3

New API

Description
Indicates,
whether a
path exists
or not
between
two
infrastructure
devices.

boolean
Indicates
isBroadcastAllowed(ConnectionPoint point); whether or
not the
specified
connection
point is
allowed to
be used for
traffic
broadcast
Indicates
whether or
not the
specified
connection
point is part

Table 6 (continued)
Old API

Description

New API

Description
of
infrastructure,
This means
it has been
detected as
end-point of
at least one
direct or
tunnel
infrastructure
link.

List<TopologyCluster> clusters();

Provides list of
Set<TopologyCluster> getClusters();
clusters of strongly
connected nodes

Returns the
set of
clusters in
the current
topology

TopologyCluster cluster(DataPathId
switchDpid);

Retrieves the
TopologyCluster getCluster(DeviceId
cluster to which
deviceId);
the infrastructure
device belongs to

Retrieves
the cluster
in which the
specified
infrastructure
device is
located

Removed APIs:
Table 7
Removed API

Description

Map<DataPathId, Link> tree(long clusterId);

Represents set of nodes and the link which it contributes to

the tree for the given cluster

String getAppId();

Return the application ID for the application providing this

service.

Set<BigPortNumber> ports(DataPathId switchDpid):

List of ports learned by Topology Service for a given switch

node.

JVM metrics
The set of JVM metrics that are persisted as per-minute time series data to assist with supportability
and troubleshooting has been reduced. It was noticed in release 2.3 that, for a given instantiation of
the controller JVM, some of the metrics never changed value from that which they reported initially;
thus persisting their value every minute resulted in wasted system resources. The metrics are still kept
in memory, and during the time that the JVM is running may be retrieved using the support report; the
support report shows the last "snapshot" value of each metric, but since these metrics don't change
value the value seen in the support report will be the same as that seen at any other time during the
JVM's instantiation.The metrics that are no longer persisted include the initial and maximum values for
total, heap, and non-heap memory allocated to the JVM, the usage of the NIO direct and mapped
memory (always reported by the JVM as 100% of the allocated capacity), and the maximum number
of file descriptors allocated on the system. For more on this topic, see the appendix titled Examples
of metrics in the HP VAN SDN Controller Administrator Guide for software release 2.4.

High availability (HA), controller teaming, and regions technology preview

High Availability (HA) and the associated REST APIs, as well as the Teaming and Regional operation
functionality are provided as a technology preview. For information regarding this technology, refer

HP VAN SDN Controller Software Release 2.4.3

to the latest HP VAN SDN Controller Administrator Guide. For new developments in this topic check
future controller product release notes as they become available.
Auxillary connections
As of software release 2.4.3, the HP VAN SDN Controller does not support the auxiliary connections
as described in the OpenFlow 1.3 switch specification.

Fixes
Learned links not shared after a failover/failback cycle in HA/Teaming environment (CR_146171)
All learned links were not shared across all team members in every instance.
Controller default ARP timeout did not match PVOS switch default arp-age (CR_148453) If the
controller def.ARPtimeout setting did not match the IP-ARP-age setting on the controlled switches, then
information learned by the controller from ARP traffic was aged out of the controller's knowledge base
before it is aged out of the infrastructure. At the default setting, this means the controller would need
to wait up to 15 minutes to see ARP traffic again for a given host.
All IPv6 traffic is dropped when the controller is configured with hybrid.mode=false (OpenFlow-only)
(CR_148658) When IPv6 traffic was switched or routed through a controlled device, the device
deferred the forwarding decision to the controller. The controller did not track IPv6 addresses and
dropped such packets so that a flooding storm did not occur if the topology was physically looped.
The controller considered IPv6 to be an unsupported protocol when hybrid.mode = false, so all such
packets were dropped when in that mode.
When a node in a team was suspended due to a lack of quorum, the REST API was not available (error
503 returned) (CR_152068) When a controller loses contact with the team, it will now be accessible
via the REST API for troubleshooting purposes only. (The controller will not be acting as a network
controller.)
java.util.ConcurrentModificationException (hp.of.ctl.pktseq) seen in log file (CR_152735) Occasionally
when the PathDaemon tried to pave a path in an environment where hybrid.mode=false, the code hit
a ConcurrentModificationException while iterating the link cache. This would result in one path not
getting paved.
Config Component LinkDiscovery requires an App disable/enable to take effect (CR_152842)
OpenFlowLinkDiscoveryComponent configuration changes now take effect as soon as they are applied.
Multi-hop link not discovered from a 5500 OpenFlow instance to a PVOS switch OpenFlow instance
(CR_153056) This was a switch 5500HI/EI defect. The verified software releases containing the
fix are:

5500HI - Version 5.20.99 Release 5501p02 and later

5500EI - Version 5.20.00 Release 2221p04 and later

Database access very slow under load (CR_153276) Updates related to connecting a large number
of devices to the controller and subsequently disconnecting devices took a long time due to repeated
drops of the connection between EclipseLink (JPA) and Postgresql.
Attempts to restart the HA sub-system service failed due to port 5700 being reported as in use
(CR_154305) This was caused by the HA sub-system service stopping without closing port 5700,
but reporting the shutdown as successful.
Empty flow class IDs on the Openflow Monitor Flows screen (CR_154901) Applies to HP 2920
switches running either OpenFlow 1.1 or 1.3 in releases prior to WB.15.16. HP 2920 switches were
byte-swapping the cookie being sent. This is now fixed in switch software release WB.15.16 and the
flow class IDs are now displayed correctly.
UDP socket used for device discovery is not properly closed when discovery is complete (CR_155259)
Over time, restart of sdnc was necessary to recover resources.
GUI malfunctions when flow.mod.enforcement parameter is set to strong (CR_155345) The possible
enforcement levels for Flow Class registration are "none", "weak", or "strict" with the default setting
8

HP VAN SDN Controller Software Release 2.4.3

of "weak". The SDN controller UI and REST API accept only one of these three strings when setting
this configuration parameter. If any other string is supplied, an invalid configuration exception occurs.
Logs contain error message reporting "Failed to emit BDDP" (CR_155795) The OFlinkdiscovery task
received an error when trying to send a discovery packet to the OF device. In all cases this happened
when the link discovery task was trying to send milliseconds after the device had disconnected. The
code has been changed to check datapath status immediately before sending the packets, and to log
the exception at the debug level if there is still a problem sending.
Unable to fetch nodes on vid=0 via RSdoc (CR_155801) When submitting a REST query to
https://<IP>:8443/sdn/v2.0/net/nodes with vid=0, the controller would respond with an empty list,
even if nodes which had vid=0 were returned by https://<IP>:8443/sdn/v2.0/net/nodes with no
vid specified.
The path paved on a ProVision 2920 switch experienced traffic loss when using the pure OpenFlow
configuration (CR_155916) In the ProVision 2920 and other V1 switch families, such as the 3500,
whenever the flow was inserted that matched in src and dst mac address, the flow ended up in software.
To make the Path Daemon path paving more compatible with line rate performance on HPN switches,
the paths are now paved based upon src/dst MAC addresses for non-IP packets and src/dst IP
addresses for all IP packets.

Release 2.4.3 issues and workarounds

NOTE:

This set of issues and workarounds applies to both release 2.4.3 and 2.4.5.

Switches operating under an SDN controller while also connected to uncontrolled switches may result
in network loop inside the controller-operated switches (CR_141580) Allowing such connections
can create broadcast loops inside the OpenFlow network. Workaround: Avoid connecting OpenFlow
switches in a controller domain in a loop topology with switches outside the domain.
Intermittent schema disagreement exception in log files (CR_148457) This exception occurs in the
database server release 1.2.3, and the only visible symptom is an exception in the controller log file.
Workaround: Restart the controller.
Intermittant data loss when connectivity to a team node is lost (CR_153341) This can result in a loss
of the team leader and information for links, nodes, or devices. Workaround: Restart the controllers.
The correct discovery of the network topology by OpenFlow and the SDN controller can be hampered
by various factors (CR_155071) Workaround: A white paper titled HP SDN Controller Link Discovery,
which recommends best practices to follow and known issues to avoid, is available in the HP SDN
Information Library at http://www.hp.com/go/sdn/infolib.
5500HI/EI switches forwarding packets with an LLDP_multicast MAC (link-local MAC) injected by the
controller to one OpenFlow port and out other OpenFlow ports (CR_156231) . Workaround: Fixed
in 5500HI software release R5501P05. For information on 5500EI operation, see the latest version
of the HP VAN SDN Controller and Applications Support Matrix.
Loss of packets through the network (CR_156810) Occurs if controller release 2.3 is used with
switch software releases x.15.16 Workaround: If using switch software release x.15.16 in your
network, upgrade the controller to release 2.4.3 or greater.
(CR_156992) Host move results in lost contact The path paved to the host at its original location is
only removed from the switch after 60 seconds of the match field not being hit. If traffic is constantly
going to the host, then its old path does not get deleted, resulting in all traffic being forwarded to the
host's old location and getting dropped. Workaround: Configure the hard timeout so that the switch
deletes the flow after the hard timeout, which results in ARP flows being paved appropriately based
on the new host location.
Path paving does not forward at line-rate on the 3500 switches (or on any PVOS v1 switch modules,
such as the 5400/8200 switches) (CR_157856) This is a data-plane performance issue in
OpenFlow-only mode. Workaround: The following steps fix the issue and set path paving functions
properly at line-rate. In this case, edit the constraint entries to match what is shown below:
HP VAN SDN Controller Software Release 2.4.3

1.

2.

Change the priorities and cookie value for the following constraints in
/opt/sdn/condig/ctl/flow-constraints.xml:
<constraint id="com.hp.sdn.l3.path" type="ABSOLUTE" priority="29999"
cookie="fffa"/>
<constraint id="com.hp.sdn.l2.path" type="ABSOLUTE" priority="28888"
cookie="fffe"/>
Restart the controller with sudo service sdnc restart.

Path paving flows have incorrect flow class association (CR_157868) When paths are paved by a
controller with the hybrid.mode = false setting, the PathDaemon uses two different flow classes to pave
paths. For release 2.4.3 and greater, L2 path paving is done at priority 29999 and L3 path paving
is done at priority 28888 (see CR157856 for a related issue). Workaround: Apply the workaround
provided for CR_157856, above. Note that this solution exchanges the cookie values.
Firewall rules not updated correctly (CR_158475) When the controller OS reboots, the default drop
rule used to secure the team message bus may be removed. Workaround: Manually re-add the rule
after the OS restarts:

10

iptables -A INPUT -p tcp --dport 5700 -j REJECT

iptables -A OUTPUT -p tcp --dport 5700 -j REJECT

HP VAN SDN Controller Software Release 2.4.3

HP VAN SDN Software Release 2.3

Overview
The base SDN Controller Appliance serves as a delivery vehicle for SDN solutions. It aims to provide
a platform for developing various flavors of network controllers, e.g. data center, public cloud, private
cloud, campus edge networks, etc. This includes being an open platform for development of
experimental and special-purpose network control protocols using a built-in OpenFlow controller.
The SDN Controller Appliance meets certain minimum scalability requirements and provides the ability
to achieve higher scaling and high-availability requirements via a scale-out teaming model. In this
model, the same set of policies are applied to a region of network infrastructure by a team of such
appliances, which coordinate and divide their control responsibilities into separate partitions of the
control domain for scaling, load-balancing and fail-over purposes.
The principal software stack of the appliance uses OSGi framework (Equinox) and a container (the
controller log file) as a basis for modular software deployment and to enforce service provider/consumer
separation. The software running in the principal OSGi container may interact with other components
running as other processes on the appliance. Preferably, such IPC interactions occur using a standard
off-the shelf mechanism, e.g. RabbitMQ, but they may exploit any means of IPC best suited to the
external component at hand.
Regardless of the specific personality of the controller, the software stack consists of two major tiers.
The upper Administrator tier hosts functionality related to policy deployment, management, personae
interactions and external application interactions, i.e. slow-path, deliberating operations. The lower
Controller tier, on the other hand, hosts policy enforcement, sensing, device interactions, flow
interactions, i.e. fast-path, reflex, muscle-memory like operations. The interface(s) between the two tiers
provide a design firewall and are elastic in that they can change along with the personality of the
overall controller appliance. Also, they are governed by a rule that no enforcement-related synchronous
interaction crosses from the Controller to Administrator tier.
The Administration tier of the controller appliance hosts a web-layer through which software modules
installed on the appliance can expose REST API to other external entities. Similarly, modules can extend
the available web-based GUI to allow network administrators and other personae to directly interact
with the features of the software running on the SDN Controller Appliance.

HP VAN SDN Software Release 2.3

11

New in release 2.3

Features

As long as the keystone server is configured to use UUID token_format, current versions of
OpenStack Keystone (specifically the Icehouse version) are supported.

The Keystone server can be local or remote.

Keystone configuration (default user/roles/tenants) is no longer taken care of by the installer. The
configuration of Keystone is now decoupled from the controller.

Using environment variables, the location of the Keystone server can be provided at installation.
1-way SSL can be used and set up in the same fashion.

The environment variables required to use a custom Keystone server (without variables,
localhost is assumed and checked to be running Keystone):

AUTH_ENDPOINT - In the format http(s)://<ip address>:<port>/v2.0.

AUTH_TOKEN - Not required. Assumed to be ADMIN (Keystone package default).

TRUSTSTORE - Required if using https in endpoint.

TRUSTSTORE_PASS - Required if using https.

The Keystone configuration can be modified after install if there is a need to change (endpoint,
truststore, etc). The controller must be restarted for this to take effect.

When installing a new system, the user will not be able to log in to the controller until Keystone
users/roles/tenants are configured. These do not have to be sdn/skyline (which they probably
wont be in a deployed environment)

REST enhancements

Performance

Full duplex

Asynchronous resources

AppStore Features

12

Link to Launch AppStore from Applications view

Link to Login to AppStore allows you to view a list of purchased applications

HP VAN SDN Software Release 2.3

AppShelf supports install or upgrade of applications

Support for proxy configuration

/etc/init/sdnc.conf
env JAVA_OPTS="-Xms512m -Xmx4096m -XX:MaxPermSize=512m-Dhttps.proxyHost=web-proxy.rose.hp.com
-Dhttps.proxyPort=8088-Dhttp.nonProxyHosts=127.0.0.1|localhost|15.255.121.172|15.255.126.13|15.255.127.5|15.255.123.6-DHPWS_DEV=true"

http.nonProxyHosts value must be provided for the team member controllers and the team's
north-bound IP.

Support for single switch from production to development AppStore:

/etc/init/sdnc.conf
env JAVA_OPTS="-Xms512m -Xmx4096m-XX:MaxPermSize=512m
-Dhttps.proxyHost=web-proxy.rose.hp.com-Dhttps.proxyPort=8088-Dhttp.nonProxyHosts=127.0.01.
|localhost|15.2551.21.72|15.2551.261.3|15.2551.27.5|15.2551.23.6-DHPWS_DEV=true"

This toggles the browser/client URLs as well as the server-side URLs.

Three new demo applications submitted to development AppStore portal.

"<id>_v<version>.zip" naming convention workaround (i.e.

com.hp.sdn.test.alertgen_v1.0.0.zip) is used.

Two are signed; one unsigned.

application.zip verification for submitted and downloaded applications

More verbose error handling in UI

The user interface added a Refresh button: the browser refresh forces users to re-authenticate with
the HPWS portal.

Licensing features

UI dialog added to allow copy-paste of uninstall key after a license has been deactivated

Application installer

Capability between debian and zip-based apps extended

Support signing of application .zip packages (in addition to the zip's internal Java artifacts)

By default the check for signed application zip files is disabled

To Turn on signed zip verification

UI console "Configurations" - under "AppManager"

Set "verifyZips" parameter to true

The public certificate used to sign the zip file must be installed in "sdnjar_trust.jks" (in
/opt/sdn/admin).

UI enhancements added to the error handling dialogs.

UI added Refresh button

The use case of upload via REST API and then installing via the UI is not supported. The UI performs
an upload and deploy atomically. If the upload is performed via the REST API, the install must be
performed via the REST API. If the application is uploaded via the REST API, but not followed by
an install, the UI will show the application as "Staged" and the only operation that can be
performed from the UI is uninstall.

HP VAN SDN Software Release 2.3

13

Supportability/Manageability

JVM metrics are now being persisted over time using the metrics subsystem, which provide some
built-in troubleshooting capabilities that were only accessible before when using supplemental
tools (e.g. JConsole, VisualVM, profilers, etc). Some supplemental tools cannot be run on headless
systems, some affect the operation of the system they're monitoring, and none are a part of the
SDN Controllers basic system requirements. In contrast, these JVM metrics are always available
for both pre-release troubleshooting and profiling and for post-release troubleshooting and analysis.

There are about fortyfive metrics that encompass various measures of memory, NIO, threads,
garbage collection, and pertinent operating system values (e.g. CPU and file descriptor use).

Each is persisted every minute, kept by default for a week, and can be retrieved using the
/metrics REST API. Thus the metrics can be used to monitor the JVM's changing consumption
of resources over time as it runs, and because the metric values are persisted they can be
used for post-crash or post-hang investigations leading up to a failure. The metrics are also
preserved after a controller restart, so even after a failed controller has been restarted some
forensic analysis is still possible.

The last "snapshot" of metric values can be seen as part of the support report via the /support
REST API for an on-demand view of resource consumption.

The metrics can be used to guide troubleshooting investigations and analyses. They may also be
used to "profile" various controller builds against one another to gauge performance changes
between builds, or to gauge the impact of running a specific application or combination of
applications on the controller's JVM.

Network services
Improvements have been added for both link manager and node manager.

14

Introduced com.hp.sdn.link.LinkService API and implementation of SupplierService API.

Introduced com.hp.sdn.node.NodeService API and implementation of SupplierService API.

Link and node discovery out-of-the-box are handled by OpenFlow Link Discovery and OpenFlow
Node Discovery apps.

Support added for 3rd party node and link supplier applications via LinkSupplierService and
NodeSupplierService API's.

Removed com.hp.sdn.ctl.linkdisco.LinkService API.

Removed com.hp.sdn.ctl.nodemgr.NodeService API.

Slight adjustments to /net/links REST API: Removing link_state from response and changing link
type from uppercase to lowercase.

NodeService utilizes new teaming infrastructure.

NodeManagerComponent configuration refactored (split) into OfArpDiscoveryComponent,

OfDhcpDiscoveryComponent, and OfIpDiscoveryComponent. Any tests which were configuring
"arp.age", "dhcp.age", or "ip.learn" will need to configure via these new components.

LinkService utilizes new teaming infrastructure

HP VAN SDN Software Release 2.3

Appliance

OVA for field and partner use

Data Model

Device holds onto interfaces.

Each InterfaceId is unique only in the context of a device.

REST APIs exist to retrieve, create, and delete devices.

REST APIs exist to retrieve interfaces.

DeviceService is implemented as a publicly accessible OSGi component along with DeviceId. This is
fully implemented with the device objects being cached for the time being.
NOTE: Although the Device interface supports the connection for interfaces, no implementation yet
exists to allow a caller to retrieve or create interfaces.

Core Controller
Java API changes

ControllerService - added methods to register initial flow contributors.

InitialFlowContributor - provides new interface for flow contributors.

SequencedPacketListener - event() callback now returns void (not boolean).

MessageContext - added isSent() predicate.

MessageContext.PacketOut - added send() method.

OfmMutableFlowMod - added methods to clear actions/instructions.

UI enhancements

FlowClass meta data is now included in the Datapath/Flows view detail panes.

Datapath connect sequence

The datapath initial connection mechanism has been expanded to use the Device Service to
determine a type for the datapath, and to install initial flows contributed by other subsystems.

The complete sequence looks like this:

1. Datapath connects to the controller
2. OpenFlow handshake performed (Hello, Hello, FeaturesRequest, FeaturesReply)
3. Extended handshake performed (MP-request for Description, Ports, TableFeatures)
4. Event emits DATAPATH_CONNECTED.
5. Device Service determines device type.
6. Flow tracker sends FlowMod/DELETE (all tables) command to datapath.
7. Flow tracker generates "core" contributed flowmods (via device driver subsystem).
8. Flow tracker collects initial flowmods from contributors (NodeManager,
LinkManager).
9. Initial flowmods validated (via flow-class subsystem).
10. Initial flowmods adjusted (via device driver subsystem).
11. Initial flowmods are sent to the datapath, along with a barrier request.
12. On receipt of the barrier reply, emits DATAPATH_READY.

HP VAN SDN Software Release 2.3

15

Device Drivers

VLAN handler is in place.

Executed on the fly (not persisted).

Reads pre-configured VLANs on the device (cannot create or change via the device driver).

Manual discovery is now used on all devices to get supplemental information via SNMP.

If snmp is not on, fields such as serial number, etc, are copied from the DataPathInfo object.

H3C devices are now supported by the FlowMod facet.

Generic Event dispatch mechanism is now in place.

Receives events and passes them through to the listeners; no adjustments or analysis is done
on them.

SNMP driver now uses credentials and finds its own, if possible, if none are given.

All flow mod adjustment now goes through the device driver's flow mod facet.

Includes any flow created and sent to FlowTrk through sendConfirmedFlowMod.

Generation of default flows, when an OF instance connects, is done through the device
drivers.
When an app gets installed, if it has default flows that switches should have upon
connection, it can register itself as an InitialFlowContributor and send in flows that should
be installed as default.

The SDN controller installs the basic flows (table misses, forward normal, or steal, based
on hybrid setting).

NodeManager and LinkManager each contribute their ARP/DHCP and BDDP flows.

Interface facet is complete.

Based on OF messages, interfaces can be added, deleted, and updated in association with
a device.

IpDiscovery reference implementation and basic supplier is implemented.

The device driver framework is in place and consists of xml files specifying known device types plus
the specific implementation of each of the facets they support.
Currently defined device types include:

3800

3500

2920

5400

8200
These device types are readable through a REST API in the DeviceDriverDemoApp.
Currently accessible facets include:

16

GenericDeviceIdentity

HpDeviceIdentity

DefaultOpenflow facet

Openflow facet for chassis switches in v2 only mode

Openflow facet for v1 supported mode

HP VAN SDN Software Release 2.3

Current drivers:

SNMPDriver is written to obtain sysoid and serial number, etc. from the switch for identification.

Device types are "evolved" by gathering enough information so that a device can be mapped to
a specific device type in an xml file.

NOTE: The SNMPDriver currently supports v2 only and does not have an interface definition. It has
to be instantiated before it can be used.
NOTE: Device Keys can be specified through a REST API accessible through the RSDOC and
DeviceDriverDemoApp, allowing gets, posts, and deletes.
NOTE:

These keys are currently used as community names only (credentials).

The following interfaces have been defined to support future facet development: VLAN, VXLAN,
interface, flowmod
OfDeviceDiscovery acts as the supplier of device information. It is an OSGi component which gets
invoked when a data path event is received by an external module. With the data path information,
it determines the device type and then stores the device info about that specific device with its device
type. It uses the device identity facet to evolve to the best device type. The device type itself holds
information about which facets and which implementations of those facets are supported.
OfDeviceDiscovery collects all the interfaces of the device that are part of the OF instances and
associates them onto the device. Port events such as add, remove or modify are handled by
OfDeviceDiscovery.

HA and teaming updates

NOTE: High Availability (HA) and the associated REST APIs, as well as the Teaming and Regional
operation functionality are provided as a technology preview. For information regarding this technology,
refer to the latest HP VAN SDN Controller Administrator Guide. For new developments in this topic,
check future controller product release notes as they become available.
The new HA framework happy path will be available for use to allow the platform services to be
updated to the new APIs. The systems status field helps improve troubleshooting in teamed environments.

The following modules containing public APIs have been removed:

hp-util-dbus

hp-util-dkvs

package: com.hp.dist.lock

hp-util-dsync

package: com.hp.dist.keystore

hp-util-dlock

package: com.hp.dist.bus

package: com.hp.dist.sync

The following public services have been removed:

com.hp.sdn.ha.HAService

com.hp.sdn.team.TeamConfigurationService

com.hp.sdn.team.TemInformationService

HP VAN SDN Software Release 2.3

17

com.hp.sdn.team.TeamConfigBootstrapService

com.hp.sdn.team.TeamingService

The following modules containing public APIs have been added:

hp-util-dcord-api

package: com.hp.util.dcord

The following public services have been added:

com.hp.util.dcord.CoordinationService: Replaces com.hp.sdn.ha.HAService and

com.hp.sdn.team.TeamingService.

com.hp.sdn.teaming.TeamAdminService: Replaces
com.hp.sdn.team.TeamConfigurationService, com.hp.sdn.team.TemInformationService,
com.hp.sdn.team.TeamConfigBootstrapService and com.hp.sdn.team.TeamingService.

NOTE: As part of the transition, com.hp.sdn.teaming.TeamAdminService has been renamed to

com.hp.sdn.team.TeamAdminService.

The following REST interfaces for Teaming have been removed:

GET /team/status - Status for team/systems should be retrieved directly from /system interface

GET /team/version - Version is included in response for general GET /team request

com.hp.sdn.rs.TeamConfigResource has been removed and replaced with

com.hp.sdn.rs.TeamAdminResource for this REST change

Backup/Restore
The new callback framework allows applications to register/unregister callbacks to perform their own
backup/restore activities.
New Java API
BackupRestoreService and BackupRestoreListener
REST API changes
/backups has been deleted and all backup/restore related functionality has been removed from
/systems. The new set of APIs is as follows:

18

/backup GET for downloading the backup file

/backup/status GET for retrieving the status of the backup

/backup/checksum GET for retrieving the checksum of the backup file currently on the controller

/backup POST to start the backup

/restore/backup POST to upload the backup on to the controller

/restore/status GET to retrieve the backup status

/restore POST to start the restore

HP VAN SDN Software Release 2.3

Security notes

Team communication currently does not support cryptographic authentication of team

members. Firewall rules are automatically added when the team is created to allow team
communication to occur only between team members.

Team communication currently does not support cryptographic encryption between team
members. To help protect this communication, the interfaces used for team communication should
be on a trusted network or dedicated VLAN with appropriate Access Control protections.

VNI reservation service

A VNI reservation service has been added. The service is intended to provide a simple mechanism
for marking VNIs that are used or intend to be used by applications so that applications do not attempt
to use/configure a VNI that is already in use by another application. A lightweight implementation
of the service is available, but is only for a single node, and does not include teaming, persistence,
or REST API.
Data persistence and teaming for VNI reservations are available and a private/sideways REST API
has been added for intra-team coordination.

Release 2.3 issues and workarounds

HP SDN App Store access: Until the App Store becomes available, the following buttons in the
controller Application display do not access App Store features:

Log in to view applications

Launch App Store

Recovering from Partial Team Creation If the team is not successfully created in all controllers,
it is not possible to fix the failed controllers without disbanding the team. Workaround: To recover
from this failure it is recommended to delete the team, fix the problem in the controllers where the
create operation failed, and try again.

Recovering from Partial Team Deletion If the team is not successfully deleted in all controllers,
the failed controllers might go to suspended mode because they might not have quorum. That is,
they wont be able to connect to those controllers where the operation was a success.Workaround:
To recover from this failure it is recommended to delete the team on each failed controller so
configuration files are removed and the controllers transition to standalone mode.

A direct REST API query for a device interface state shows interfaces up for that device when
the device is offline (CR 152840) HP recommends checking the device status first and then
querying for interface information. That is, query device status through the
v2.0/sdn//net/devices REST API. If the device is online, then query interface information
for that device through the/net/devices/devid/interfaces REST API. For devices that are
offline, the interface information can be queried through the same REST API but the interface
information displayed is from the last time the device was online.

Config Component LinkDiscovery requires an App disable/enable to take effect (CR 152842)
com.hp.sdn.disco.of.link.impl.OpenflowLinkDiscoveryComponent changes only take place when
you manually disable and enable through OpenFlow Link Discovery undo applications.

HP VAN SDN Software Release 2.3

19

HP VAN SDN Software Release 2.2.5

Issues occurring when the controller is configured with hybrid.mode=false:

ARP, ICMP request, and other communication to a switch data-plane IP fails (CR147704)Currently,
the controller does not support direct communication with controlled switches. The only supported
communication is through the controlled switches and not to the controlled switches. When a host
on the network sends an ARP request, the controller assumes that the ARP request is intended for
another host on the network (and not a controlled switch). The controller instructs the controlled
switch to forward the packet elsewhere in the network and does not instruct the controlled switch
to directly respond to the packet.
To resolve this:
1. Change the hybrid.mode setting of the controller to true and restart the controller.
2. See the user documentation for information on how this change affects the controlled network.

Data plane traffic to or from a host indirectly connected to a controlled switch is not forwarded
at line-rate (CR148324) A host is indirectly connected to a controlled switch when there is an
uncontrolled switch between the edge-most controlled switch and the host. When a host is
connected to the controlled network in this manner, the controller does not learn where the host
is located because the controller assumes that no hosts will appear on infrastructure ports. Since
the controller does not learn where the host is located, any traffic that flows to or from this host
cannot be paved, and is therefore handled by the controller at each hop through the controlled
network. If a single packet to or from such a host needs to cross a number of controlled switches,
then the controller will be consulted those many times for the same packet. The actual throughput
rate depends upon the load of other processing on the controller and the number of hops that
such flows take through the controlled network.
To resolve this:
1. Change the hybrid.mode setting of the controller to true and restart the controller.
2. See the user documentation for information on how this change affects the controlled network.
3. If step 1 cannot be implemented, then connect all hosts to ports of controlled switches that
are not connected to other controlled switches.
Do not connect multiple controlled switches to ports on the same VLAN of a router, especially
a gateway router.

Packets are not properly forwarded through a controlled router (CR148326) The controller is
not aware of the data plane MAC addressing or IP addressing of a controlled L3 router. The
controller is also unaware of whether a packet received by the data plane of a controlled switch
should be switched, routed, or consumed. Additionally, the controller is not aware of the data
plane subnetting, static routes, or routing protocol information that provides information necessary
to properly route traffic.
To resolve this:
1. Change the hybrid.mode setting of the controller to true and restart the controller.
2. See the user documentation for information on how this change affects the controlled network.
3. If step 1 cannot be implemented, then change the configuration of the OpenFlow instance
on the router so that it is no longer controlled by the controller.

20

Traffic between two hosts crossing a switch configured with a multi-VLAN and the aggregate
OpenFlow instance in a controlled network is not forwarded at line-rate (CR148389) HP switches,
including those from the 2920/3500/3800/5400/6200/6600/8200 series, support an
aggregate OpenFlow instance. This instance contains all VLANs on the controlled switch. When
the controller attempts to pave a path across such a switch configured with this aggregate instance,
the controller does not send the VLAN ID to which the path paving flow-mod applies. Any switch
configured with multiple VLANs in an aggregate instance will reject the flow-mod because the
ingress VLAN was not specified. Since the flow-mod is never accepted by the switch, all future

HP VAN SDN Software Release 2.2.5

forwarding decisions for such packets are delegated to the controller by the controlled switch.
The controller makes the forwarding decision for every packet which needs to cross a controlled
switch with a multi-VLAN aggregate OpenFlow instance. If a single packet needs to cross a number
of such switches, then the controller will be consulted those many times for the same packet. The
actual throughput rate depends upon the load of other processing on the controller and the number
of hops that such flows take through the controlled network.
To resolve this:
1. Change the hybrid.mode setting of the controller to true and restart the controller.
2. See the user documentation for information on how this change affects the controlled network.
3. If step 1 cannot be implemented, then change the switch configuration to use an OpenFlow
instance per VLAN instead of a single aggregate instance for all VLANs.

Traffic between two hosts in a partially-controlled network is not forwarded at line-rate (CR148385)
The controller is responsible for the forwarding decision of every packet that enters a switch
it controls. When the controller observes a packet for any given flow, it attempts to pave the path
through the network through the OpenFlow forwarding rules for that flow, so that all future packets
of the same flow are handled by the switch according to the forwarding rule. In cases where two
controlled switches are separated by a multi-hop link, the controller does not pave the path across
that multi-hop link because it paves only a single path and the controller cannot be guaranteed
that multiple paths do not exist if multiple multi-hop links exist.
As a result, the controller will not pave any paths across a multi-hop link. The controller makes
the forwarding decision for every packet which needs to cross a multi-hop link. If a single packet
needs to cross a number of multi-hop links, then the controller will be consulted those many times
for the same packet. The actual throughput rate depends on the load of other processing on the
controller and the number of hops that such flows take through the controlled network.
To resolve this:
1. Change the hybrid.mode setting of the controller to true and restart the controller.
2. See the user documentation for information on how this change affects the controlled network.
3. If step 1 cannot be implemented, then connect switches in such a manner that there are no
uncontrolled switches (multi-hop links) between controlled switches in the controlled network.

All IPv6 traffic is dropped (CR148658) The HP VAN SDN Controller does not recognize the
devices that use only the IPv6 addresses on the control plane. The controller and the devices with
which it communicates must use the IPv4 addresses on the control plane. IPv6 traffic running in
the data plane of an OpenFlow-hybrid network is supported when the controller is operating with
hybrid.mode set to true (the default). Under these conditions, the data plane forwarding decision
for IPv6 packets is made without involvement by the default controller applications. However, if
hybrid.mode is set to false, all packets are sent to the controller and the default controller
applications drop all the IPv6 packets.
Similar to any protocol that is not supported by the default controller applications, if the IPv6 data
plane traffic support is required, then write and install the application in the controller to provide
switches with the desired flows to let the controller observe and direct the forwarding decision.
To resolve this:
1. Change the hybrid.mode setting of the controller to true and restart the controller.
2. See the user documentation for information on how this change affects the controlled network.

Host is unable to ping some other hosts on the network when multiple VLANs are used when the
controller is configured with hybrid.mode=false (OpenFlow-only) (CR148179) When mutiple
VLANs are used with a controller that is configured for hybrid.mode=false, a host might not be
able to ping some other hosts on the network.
To resolve this:
1. Change the hybrid.mode setting of the controller to true and restart the controller.
2. See the user documentation for information on how this change affects the controlled network.
HP VAN SDN Software Release 2.2.5

21

Other issues in release 2.2.5

Controller loses knowledge of hosts on the network, but those hosts are actively communicating
through or with the network infrastructure (CR148453) The default setting for the controller's
ARP timeout is 5 minutes. The default setting of ip arp-age for ProVision switches is 20 minutes.
If the controller setting does not match the setting on the controlled switches, then information
learned by the controller from ARP traffic is aged out of the controller's knowledge base before
it is aged out of the infrastructure. The controller needs to wait for up to 15 minutes to see ARP
traffic again for a given host. If the controller is unaware of the host's location on the network,
other problems may occur with traffic forwarded to or from that host depending upon the
applications and forwarding decisions that the controller is responsible for.
To resolve this:
1. Change the controller's arp.age setting on the controller UI under
com.hp.sdn.ctl.nodemgr.impl.NodeManager to be greater than or equal to the ip arp-age
setting of the controlled switches.
2. If step 1 cannot be implemented, then change the ip arp-age setting of the controlled switches
to match the arp.age setting on the controller.

HP VAN SDN Controller becomes unresponsive when the HP Network Optimizer SDN Application
session database has around 1M entries (CR148578) The HP VAN SDN Controller crashes in
JVM and becomes unresponsive when the HP Network Optimizer SDN Application session
database has about 1M entries in it. Read the HP Network Optimizer Release Notes to learn
more about the JVM memory size.

When trying to access OpenFlow Topology using Firefox browser, error 500 occurs (CR147973)
When trying to access the OpenFlow Topology using the Firefox browser, the "Server Error 500: Internal Server Error" error message appears. The topology appears after that error is closed.

HA teamingAfter failover or failback all the links learned are not shared across all the team
members all the time (CR146171) In an HA teaming configuration, after failover or failback,
all the links learned are not shared across all the team members all the time. This behavior can
occur when there is a very large number of links between switches (over12,000) and a large
number of switches (over 500) in the controller domain.
NOTE: High Availability (HA) and the associated REST APIs, as well as the Teaming and Regional
operation functionality are provided as a technology preview. For information regarding this
technology, refer to the latest HP VAN SDN Controller Administrator Guide. For new developments
in this topic, check future controller product release notes as they become available.

22

Pin All option does not pin all data paths and nodes (CR146165) On the HP VAN SDN Controller
UI, in Topology viewer, the Pin All option under View does not pin all data paths and nodes.

The database fails to free disk space occupied by removed records (CR146155) The database
fails to free disk space occupied by removed records.

Topology viewer displays moving switch (CR146636) When connecting a single physical switch
to the controller and bringing it up in the Topology viewer on the GUI, it occasionally shows the
switch moving around the screen before any end hosts have been discovered on the switch.

When performing the backup and restore operations, the restore operation is not logged
(CR148809) When you perform the backup and restore operations and check the audit logs
for these operations, the restore operation is not logged.

Schema disagreement exception for database observed in log files (CR148457) The schema
disagreement exception for the database occurs when a keyspace is created on all nodes of the
controller. This happens when a schema configuration is in progress on one node of the cluster

HP VAN SDN Software Release 2.2.5

and the same schema is configured on another node of the same cluster. This issue is intermittent
and has no impact on the functioning of the controller.

The OpenFlow Topology view of any single controller does not display the entire team-wide
topology (CR148644) The OpenFlow Topology view shows the switches and the respective
end-nodes that are connected to the controller. In a controller team environment, the entire
team-wide topology is not shown in the OpenFlow Topology view of any single controller.

NIO direct buffers will not be garbage collected before running out of space (CR148470) There
is a possibility that the NIO direct buffers will not be garbage collected before running out of
space because of the way the JVM garbage collection is implemented with respect to NIO direct
buffers. The NIO buffer garbage collection is triggered to run only when the normal Java heap
garbage collection runs. If the normal Java heap remains steady and never invokes the garbage
collection, the NIO directly allocated buffers will never be freed.

Controller database log files are not captured as part of the support log zip file (CR159054)
The database log file needs to be added to the zip file capture to aid in troubleshooting.
Workaround: To capture the database log files, log in to each controller using SSH or any other
access tool, then copy the /opt/sdn/cassandra/log/system.log file to a storage location.

HP VAN SDN Software Release 2.2.5

23

HP VAN SDN Controller Software Release 2.1

Never released.

HP VAN SDN Controller Software Release 2.004253

24

REST call to get all the ports takes 5 seconds when the number of ports is 40k (CR141008) The
REST call to get all ports takes more time as the number of ports increases.

Auxiliary connections established by the device to the controller are not visible via REST or the UI
(CR140089)Manage the device auxiliary connections to the controller from the switch by
telneting to the switch.

When using Internet Explorer 9 or Internet Explorer 10, the controller console is blank (CR138915)
Currently, IE 9 is not supported, and IE 10 has limited support. In IE 10, OpenFlow Topology
is unavailable.

When restarting the sdncservice database, exceptions are reported in logs (CR141589) When
the controller starts for the first time, EclipseLink (JPA implementation) creates the database schema
by scanning the entities defined in the controller code. (For example, AlertEntity, AuditLogEntity,
SustemInformationEntity, etc.) After the schema has been created, each time the controller restarts,
EclipseLink tries to create the schema again. However, if a table has already been created, it is
not altered to preserve the current data. This event causes the warnings to be logged. These log
entries are actually added by EcliseLink, they are expected and they do not cause any unexpected
behavior. Note that these exceptions are expected only at the initialization phase. If an
org.postgresql.util.PSQLException or org.eclipse.persistence.exceptions.DatabaseException occurs
during this phase of operation, they represent unexpected conditions. The following errors are
expected only during the initialization phase, and do not describe any unexpected behavior:

[2013-10-03 11:31:39.890] INFO t Resolve Thread (Bundle 81)

System.outInternal Exception: org.postgresql.util.PSQLException:
ERROR: relation "X" already exists...

[2013-10-03 11:31:39.899] INFO t Resolve Thread (Bundle 81)

System.out[EL Warning]: ServerSession(2136794997)--Exception
[EclipseLink-4002] (Eclipse Persistence Services 2.4.2.v20130514-5956486):
org.eclipse.persistence.exceptions.DatabaseException

Topology Map fails to display network-wide computed trees (CR137780) The topology viewer
in HP VAN SDN Controller 2.0 topology UI shows only the devices discovered by the controller
pointed to by the browser, not the entire topology discovered by a team of controllers.

OpenFlow topology GUI is not optimal when a large number of hosts or devices are connected
(CR140798) The HP VAN SDN Controller 2.0 topology UI is not intended to represent large
topologies consisting of hundreds of elements.

On team reboot, suppressed ports are lost (CR137854) Suppressed ports information (specifying
the ports on which want to stop LLDP traffic) is not stored in persistence, and is lost whenever the
controller reboots. HP recommends that you maintain a backup of your suppressed ports
configuration.

Comware switch OpenFlow behavior (CR138462) When a flow is pushed to a extensibility

table with apply_actions as the instruction type, and the retrieved Flow Statistics using Multipart
Request apply_actions is correct, the CLI always shows Write actions.

Tagged link between two devices is not discovered (CR138547) If a link exists between a pair
of ports tagged to two different VLAN instances in Aggregate mode in OpenFlow, links are
discovered correctly in the HP VAN SDN Controller between only one of the VLAN instances.
The link between the other instances is not discovered. This issue does not occur in Virtualized
mode.

HP VAN SDN Controller Software Release 2.1

Link Discovery displays link across two OpenFlow instances (CR139375) The Link Discovery
application in the HP VAN SDN Controller shows links between two OpenFlow instances when
the same port is tagged to two different s associated with the two OpenFlow instances in Comware
(5900) devices.

Group/meter create/update/delete require optional and redundant command attribute (CR141930)

When using the REST API for creating/updating/deleting a group/meter, including the JSON
request in the command field is required.

During installation through the Ubuntu software center, the HP VAN SDN Controller Debian package
displays a Package is of bad quality error message (CR141745) HP VAN SDN Controller
installation through the Ubuntu software center is not supported.

Output of REST API to fetch application with name parameter is inconsistent (CR141736) The
HP VAN SDN Controller Application Manager REST API for fetching applications currently fetches
all applications. There is no support for a filter based on query parameters.

Jconsole utility is not available in openjdk-7jre-headless, which is a dependency before installing

the HP VAN SDN ControllerIf you create metrics in the HP VAN SDN Controller, and then try
to open the Jconsole to see the metrics, a message displays saying that Jconsole cannot be found.

HP VAN SDN Controller failed to delete clean start memento /tmp/HPN Van Controller.clean,
error message in the log.log file (CR142605) This is a temporary file that is only created during
a restore or upgrade during normal operation when the OSGi controller log file container is
restarted with the clean option.

Zookeeper warning logged during initialization (CR138057) The HP VAN SDN Controller 2.0
includes ZooKeeper connection logs. Failed connection attempts are normal during Controller
initialization and configuration changes and can be ignored.

Delete failed error exception is noticed from teaming module in the log.log file (CR142603)
The HP VAN SDN Controller 2.0 tries to cleanup internal data structures during Controller
initialization and configuration changes and logs error message if data is not found. This is normal
during Controller initialization and configuration changes and can be ignored.

Backup/Restore fails when manual upload/download of backup files when file owner changes
to anyone other than sdn user (CR138689) Any manual operation on the VAN SDN Controller,
other than using the REST APIs through curl can change the file attributes from sdn username to
Operator username. The backup/restore fails if you perform a manual upload/download of files.
To avoid this, always perform any manual operation via curl using the REST APIs.

Keystone-related SDN user password changes are not restored properly (CR141586) If the
default sdn password is changed from skyline using keystone and the backup operation is
done, you cannot login with the new password after restore operation. You must still use the
default password (skyline) for login.

Installation guide calls for AMD64 processor but processors from other manufacturers can be
usedThe hardware requirements listed in the HP VAN SDN Controller Installation Guide
incorrectly specify that an AMD64 server or desktop machine is required. No specific processor
manufacturer is required. You can use x86-64 processors from other manufacturers.

Flow is not added or retrieved correctly (CR138494) The _VID: PRESENT bit is not set for
ID, which indicates an incorrectly formed _VID match field from a Match structure in a
MultipartReply / FlowStats.element.

Unable to modify _vid in table 101 (CR140524) A switch error occurs if you push Flow Mod
with the vlan_vid value as part of set-fields.

Connected Links disappear between the OpenFlow switches when spanning tree is enabled
(CR140755)When enabling spanning tree in OpenFlow switches, controller-sent LLDP packets
are not being forwarded from STP_BLOCKED ports, causing the discovered links to be deleted
and link rediscovery to not occur on the ports.
HP VAN SDN Controller Software Release 2.004253

25

Openflow 1.3 badly formed MultipartReply/FLOW stats message (CR142663)

java.lang.IllegalStateException: Timed-out waiting for response might appear when the REST
API is invoked to list all flows on a datapath from the SDN Controller. This occurs due to the
information sent from the switch firmware.

When RESTAPi /stats/ports/ is executed with dpid & portid filter, an exception is thrown with
response code 500 (CR142114) HTTP/1.1 500 Internal Server Error might appear when the
REST API is invoked to get stats for a port (GET /stats/ports) in a datapath from the SDN Controller.
This appears due to the incorrect information from the Openflow devices (Switch CR 131910:dpctl
stats-port <port> command displays empty stats.)

The RESTAPi /datapaths/{dpid}/ports/{port_id}/action fails to change the state of the port

(CR140753) The port state does not get changed when the REST API is invoked to change the
state of a port in a datapath from the SDN Controller due to the design in the Provision switches.

Related information
Documentation
To find networking documentation, browse to the Manuals page of the HP Business Support Center
website: www.hp.com/support/manuals.

For networking documentation, navigate to the Networking section, and select a networking
category.

For a complete list of acronyms and their definitions, see HP FlexNetwork Technology Acronyms.

Documentation related to controller software release 2.4

The HP VAN SDN Controller 2.4 documentation set includes the following publications available in
the SDN Information Library:

HP VAN SDN Controller Release Notes

HP VAN SDN Controller and Applications Support Matrix

HP VAN SDN Controller Installation Guide

HP VAN SDN Controller Administrator Guide

HP VAN SDN Controller Programming Guide

HP VAN SDN Controller REST API Reference

HP VAN SDN Controller Open Source and Third-Party Software License Agreements

Documentation feedback
HP is committed to providing documentation that meets your needs. To help us improve the
documentation, send any errors, suggestions, or comments to Documentation Feedback
([email protected]). Include the document title and part number, version number, or the URL when
submitting your feedback.

26

Related information