Version 16 (modified by, 10 years ago) (diff)


Internet2 FlowSpace Firewall Tests

This page outlines testing planned for the Advanced Layer 2 Services (AL2S) FlowSpace Firewall (FSF) feature.

The tests will verify the ability of FSF to provide advertised features for various scenarios that will use both ION and AL2S GENI endpoints. GENI slices will be setup to validate the functionality.

Test Goals

  • FSF ability to support a simple learning switch controller for various topologies.
  • FSF ability to support multiple concurrent add/delete learning switch controller request.
  • Verify ability to use different learning switch controller implementations (FloodLight, POX)
  • Verify rate limiting
  • Ability to query statistics for switch, links, firewall rules with FloodLight rest API.


  • Functional testing will start with simple 2 node topology connected to AL2s.
  • All topologies are run without an experimenter OpenFlow Controller first to verify connectivity.
  • Once connectivity is verified, experiments are re-run with an experimenter Learning Switch OpenFlow Controller.
  • All ION to AL2S cross-connects will be used to verify ability to support OpenFlow connections.
  • Testing assumed that GENI networks stitching is available for OESS.
  • Each topology is verify with stitching only as a first step. Once verified OpenFlow is added to the experiment.
  • End-point traffic types generated will include UDP, TCP, ICMP using various tools.

FSF-T1 Two Sites Functional tests

Initial testing will take place with two sites that are already connected to AL2S. Multiple slivers will be created by multiple experimenters.

Functional testing is executed within these simple node experiments:

  1. Create slice which results in VLANs allocation between AL2S InstaGENI end-point and exchange traffic. Verify AL2S router proxy statistics.
  2. Create slices to use configured number of VLANs, verify configuration is enforced and reflected in AL2S router proxy statistics.
  3. Delete slices and and verify release of VLANs via AL2S router proxy.
  4. Submit multiple concurrent requests to add and to delete flow spaces.
  5. Configure various rate limits and verify enforcement.
  6. Query FSF status and rules via FloodLight rest API.
  7. Generate traffic outside of pre-defined flowspace and verify that it is handled properly.
  8. Create slice requesting specific VLAN outside of FSFW range, verify rejection.
  9. Request network capacity beyond configured FSFW capacity, verify enforcement.

Network Connection details for this 2 node topology:

Missouri InstaGENI:
Site VLANs: 1150-1160 - AL2S end-point: KANS
ION cross connect:

Stanford InstaGENI:
Site VLANs: 1630-1639 - AL2S end-point: SUNN
ION cross connect:

FSF-T3 ION to AL2S interconnects tests

Both slices shown will be setup using each of the 10 interconnects between ION and AL2s:

ION to AL2S cross-connects
The following cross-connects will be verified in the OpenFlow topologies shown above are:

  1. sdn-sw.losa e1/1 <-> rtr.losa:port=et-10/0/0
  2. sdn-sw.atla e15/1 <-> rtr.atla:port=xe-0/3/0
  3. sdn-sw.chic e3/1 <-> rtr.chic:port=et-10/0/0
  4. sdn-sw.clev e5/1 <-> rtr.clev:port=et-5/0/0
  5. sdn-sw.hous e15/3 <-> rtr.hous:port=xe-0/1/3
  6. sdn-sw.kans e15/1 <-> rtr.kans:port=xe-0/0/3
  7. sdn-sw.newy32aoa e3/2 <-> rtr.newy:port=et-5/0/0
  8. sdn-sw.salt e15/1 <-> rtr.salt:port=xe-0/1/1
  9. e-2/0/0.0 <->
  10. sdn-sw.wash e5/2 <-> rtr.wash:port=et-9/0/0

FSF-T4 Linear Topologies tests

Multiple concurrent linear topologies will be set up by multiple experimenters. Topologies are run without an experimenter controller first, to verify setup. Once verified, the topologies will be run with an experimenter Learning Switch OpenFlow controller.

Review of available statistics will take place to ensure that resource allocation and usage is properly captured in the available tools AL2S Router Proxy.

FSF-T5 Star Topology tests

A version of this topology will be set up by multiple users:

Test Characteristics

Each experiment will be run without and experimenter defined OpenFlow Controller. Once shown to work, the experiment will add a user defined OpenFlow! Learning Switch controller.

Majority of OpenFlow test cases will be executed with FloodLight Learning Switch OpenFlow Controller, although other experimenter controllers will be tries, such as POX.

Test Characteristics:

  • Both raw-pc and Xen VM will be used as IG end-points.
  • All requests will run with the default bandwidth allocation (100Mb/s), unless otherwise stated.

Experimenter Generated traffic:

Iperf will be used to generate TCP and UDP traffic for 60 seconds test runs. For iperf TCP traffics, results will be collected for 1, 5 and 10 clients. Commands used:

  • iperf '1 client' scenario command: 'iperf -c dest_host -t 60'
  • iperf '5 clients' scenario command: 'iperf -c dest_host -t 60 -P 5'
  • iperf '10 clients' scenario command: 'iperf -c dest_host -t 60 -P 10'

Iperf UDP measurements will request 100 Mbits/sec, based on results will increased or decrease bandwidth requests.

Ping statistics will run got 60 seconds to capture network delay.

Attachments (4)

Download all attachments as: .zip