OpenNSA feature and configuration description

Topology configuration

Configuration the nrm file is typically the most confusing parts of setting up OpenNSA. In short the NRM file defines the ports available through the NSI protocol, as OpenNSA does not make everything available. An NRM is line based and typically looks like this:

# type      name    remote                              label               bandwith    interface   attributes

ethernet    ps      -                                   vlan:1780-1799,2000 1000        em0         user=johndoe@example.org
ethernet    bon     bonaire.net:topology#arb(-in|-out)  vlan:1780-1799      1000        em3         restricttransit
ethernet    cur     curacao.net:topology#arb(-in|-out)  vlan:1780-1799      1000        em3         restricttransit,hostdn=curacao.example.net

Each line describes a port.

  • Type

The port type. Only ethernet is recognized at the moment. Bidirectional is implied here.

  • Name

The name of the port. The port address will be a URN with the network and port name in it.

  • Remote

The network and port the port is connected to. Format:

network#port(-inprefix|-outprefix)

Use '-' if not connected to any network (local termination port).

  • Label

Port configuration options. Only VLANs supported for now. Can specify single values and ranges. Comma seperated.

Use '-' if no labels are to be used (i.e., trunk for vlan).

  • Bandwidth

The available bandwidth on the port (or the bandwidth that is available to OpenNSA).

  • Interface

The port on the corresponding NRM / network equipment.

  • Attributes

REST interface

URL design:

Create new connection       POST    /connections
List connections (filter)   GET     /connections
Get connection information  GET     /connections/{connection_id}
Get connection status       GET     /connections/{connection_id}/status

the /status is longpull (server won't close connection but will update continously)

Enable:

In [service] section:

rest=true


Example minimal payload to create connnection:

"""
{
  "source"        : "nordu.net:s1",
  "destination"   : "surfnet.nl:ps",
}
"""

More flags:

  start_time
  service_type
  bandwidth (megabits)
  start_time
  auto_commit
  auto_provision
  security_attributes

Date format is ISO, e.g., "2015-12-13 08:08:08Z"


No:
    nsa identity (b0rked concept anyway)
    global reservation id
    Possibility to designate connection id
    Time zones in datetime, always utc (end with Z)

Maybe:
    client correlation id

Configuration file

Edit config as follows (Configuration is different for uPAs and for aggregator. Read commented config template carefully.):

To more details about domain aggregate follow this link.

[service]
# Just suggested format of network name, eg: DOMAIN = "LOC.nsi.geant.net" and LOC = "mx1.ams.nl" or "ams" as per previous convention
# NOTE: When configuring aggregator, the domain should look like the following: DOMAIN = "nsi.geant.net".
network=DOMAIN
user=opennsa
logfile=/home/opennsa/logs/opennsa-LOC.log

## Host can often be detected.
## Default port is 9080/9443 depending on tls

host=OPENNSA_HOST_IP
port=9444 # Good practise is to use 9443 for main/aggregator process 

database=opennsa-LOC
dbuser=opennsa
dbpassword=
tls=false

# Location of topology description file
# NOTE: When configuring aggregator, NO NRM FILE should be configured. Just comment out/delete the nrmmap line.  
nrmmap=/home/opennsa/topology/opennsa-LOC-top.nrm

# Peering: with domainaggregate feature uPAs should not have any peers defined!
# peers=http://ANY_OPENNSA_HOST_IP_OF_PEER:PORT_OF_PEER/NSI/discovery.xml
#        http://ANY_OPENNSA_HOST_IP_OF_PEER:PORT_OF_PEER/NSI/discovery.xml


# Backend configuration here is for the gts Junos MX platform with ssh channel against router ...
# Always uncomment/use just one backend at the time. More description can be found on OpenNSA wiki.
# NOTE: When configuring aggregator, NO BACKEND should be configured. Just comment out/delete the backend section. 

# use this dummy backend without any further configs. Useful for testing.   
#[dud]  

# JunosMX is the backend for Juniper MX platform supporting VLAN,MPLS and port based STPs. 
[junosmx]
host=MANAGEMET_IP
user=opennsa
fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
publickey=/home/opennsa/.ssh/opennsa_rsa.key.pub
privatekey=/home/opennsa/.ssh/opennsa_rsa.key
# LOOPBACK_IP for beeing used as LSP target from different PE routers
# All routers in dataplane needs to be listed here.
routers=ROUTER_LOC1:LOOPBACK_IP # LOOPBACK_IP for beeing used as LSP target from different PE routers
  ROUTER_LOC2:LOOPBACK_IP        

#JunosEX is the backend for Juniper EX 4550 platform supporting VLAN based STPs only. 
#It supports label swapping using CCC feature.  
[junosex]
host=MANAGEMET_IP
user=opennsa
fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
publickey=/home/opennsa/.ssh/opennsa_rsa.key.pub
privatekey=/home/opennsa/.ssh/opennsa_rsa.key

#Section for JUNOS SPACE backend configuration. Uncomment just one backend config for the configured instance
[junosspace]
space_user=USERNAME
space_password=PASSWORD
space_api_url=https://IPADDR/api/space
configlet_activate_local=CONFIGLET_ID_IN_JUNOSSPACE
configlet_activate_remote=CONFIGLET_ID_IN_JUNOSSPACE
configlet_deactivate_local=CONFIGLET_ID_IN_JUNOSSPACE
configlet_deactivate_remote=CONFIGLET_ID_IN_JUNOSSPACE
# LOOPBACK_IP for beeing used as LSP target from different PE routers
# All routers in dataplane needs to be listed here.
routers=gtstest2:589838:IPADDR2 # FORMAT OF THE 3 tuple: network_name:router_id_in_junosspace:loopback_ip
 gtstest1:589834:IPADDR1

Simple CLI tool

A short primer on the onsa command line tool.

Disclaimer: There are still bugs and unfinished functionality.

Intro

The onsa command line tools allows the creation of connections and basic lifecycle management, along with query functionality.

If you cannot wait to get started, you can list the command options with:

$ onsa --help

The command line tool requires a command (e.g., reserve or provision), and a set of options, in order to carry out a command.

Defaults file

Often there will be a number of options, which will be the same or almost the same with every invocation, e.g., location of topology files, WSDL directory, identity of the client and so forth. To save time, the CLI will read on default options from a file, typically ~/.opennsa-cli, but it is possible to specify an alternate location using the -f (--defaults-file) option.

Here is an example of a .opennsa-cli defaults file:

bandwidth=200
host=localhost
port=7080
starttime=+20
endtime=+260

nsa=aruba,aruba.net:nsa,http://localhost:4080/NSI/services/CS2

The host and port options, will be used in setting up the callback URL. They will default to the value provided by "socket.getfqdn()" and 7080.

The starttime and endtime can be set to xsd datetime value, but can also be assigned a +X value, with X being the number of seconds into the future. This makes it easy to always get some usefull values when testing.

The nsa entry, allow a shorthand for specifying nsa id and service url. With the above example, one can use "-p aruba" instead "-p aruba.net:2013:nsa -u http://localhost:4080/NSI/services/CS2" This makes the command line tool a lot nicer to use. There can be multiple nsa shorthand entries.

If an option is specified both on the command line and in the defaults file, the command line value will be used.

It is possible to set all options which can be set on the command line in the defaults file, with the exception of the command to perform.

Using the tool

With a default options file created, a connection can be created like this:

$ ./onsa reserve --source northernlight.ets:ps-80 --dest northernlight.ets:ams-80 -n northernlight.ets

A connection id and global id is assigned automatically but can also be assigned using the -c and -g options.

To provision the connection:

./onsa provision -n northernlight.ets -c <connection-id>

Similarly with release and terminate, querysummary, and querydetails.

 

 

 

 

 

 

 

 

  • No labels