Version 26 (modified by, 5 years ago) (diff)

minor rewording

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 set up to validate this functionality.

The initial test plan will use a very basic Floodlight Controller as a GENI learning switch controller. After finishing the testplan once successfully to evaluate FSFW, we may re-execute with other controllers that experimenters may want to use (e.g. POX)

Test Goals

  • Confirm FSF ability to support a simple GENI learning switch controller for various topologies.
  • Confirm FSF ability to support multiple concurrent add/delete learning switch controller requests.
  • Verify rate limiting
  • Confirm ability to query statistics for switch, links, firewall rules with FloodLight rest API.
  • Run through Internet2 procedures for qualifying and running an experimenter controller in AL2S and provide feedback to I2 to streamline the procedures as much as possible, and ensure experimenters can get complete and accurate documentation to help guide them through procedures.


  • Functional testing starts with a simple 2 node topology connected to AL2S.
  • All topologies are run without an active GENI OpenFlow Controller first to verify connectivity (i.e. endpoints are connected using GENI stitching and test data is exchanged to verify end-to-end connectivity. If GENI OESS stitching is not available, we will use a combination of GENI Stitching and OESS tools to set up and verify end-to-end connectivity.)
  • Once connectivity is verified, experiments are re-run with an experimenter Learning Switch OpenFlow Controller in AL2S.
  • All ION to AL2S cross-connects are used to verify ability to support OpenFlow connections to endpoints that are not on AL2S.
  • Each topology is verified with stitching only as a first step. Once verified, we add the experimenter OpenFlow controller in AL2S and other relevant OpenFlow controllers outside AL2S to the experiment.
  • End-point traffic types generated include UDP, TCP, and ICMP.
  • Layer 2 hardware matching is validated. There is no Layer 3 matching at this time. (Layer 3 matching tests will be done when AL2S makes that capability available.)
  • Tests are described in this plan with the assumption that GENI network stitching is available from OESS.
  • OESS may not be available, so sliver creation may be done in 2 steps:
    • AL2S circuits will be set up to connect the edge ports.
    • Stitched slivers with fixed AL2S endpoints are created for IG sites.

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 a slice which results in VLANs allocation between AL2S InstaGENI end-points 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 FSF range, verify rejection.
  9. Request network capacity beyond configured FSF 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-T2 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-T3 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-T4 Star Topology tests

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

Test Characteristics

Experimenter Controllers

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 0.90 Learning Switch OpenFlow Controller, although other experimenter controllers will be tries, such as POX 0.1.0.

Test Characteristics

  • Both raw-pc and Xen VM will be used as IG end-points.
  • All experiment will request the default bandwidth allocation (100Mb/s), unless otherwise stated.
  • All 10 ION to AL2S cross-connects will be verified, but the majority of testing will use LOSA, KANS, and ATLA cross-connects.

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 for 60 seconds to capture network delay.

Attachments (4)

Download all attachments as: .zip