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 AL2S GENI endpoints. GENI slices will be set up to validate this functionality and using the GeniSiteMon Controller, which is a GPO-developed controller based on POX.

The initial test plan will be executed with the GeniSiteMon Controller as the switch controller. After successful completion, the GPO may re-execute test scenarios with other controllers that experimenters may want to use (e.g. FloodLight).

Test Goals

  • Confirm FSF ability to support the GeniSiteMon Controller for various topologies.
  • Confirm FSF ability to support multiple concurrent add/delete requests with GeniSiteMon Controller.
  • Verify rate limiting,if any, on the control plane. (No rate limiting enforced on the AL2S data plane with FSFW)
  • Confirm ability to collect AL2S and FSFW usage statistics relevant to these test scenarios via SNAPP and GENI local datastore monitoring interfaces. Example statistics include total flows, flowmods/sec, VLANs throughput on switches and links, active GENI slices/slivers. See the GENI monitoring use cases for more detail on statistics not specifically related to FSF.
  • 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. The GeniSiteMon Controller was run through the Internet2 qualification process and will be used for testing scenarios in this test plan.


  • Functional testing starts with a simple 2 node topology connected to AL2S.
  • All topologies are run without an active GeniSiteMon 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 AL2S stitching is not available, we will use a combination of GENI Stitching and AL2S tools to set up and verify end-to-end connectivity.)
  • Once connectivity is verified, experiments are re-run with the GeniSiteMon Controller.
  • Some scenarios will be used to verify ability to support OpenFlow connections to endpoints that are not on AL2S. This may be necessary for sites such as University of Utah, which may not migrate to AL2S initially.
  • Each topology is verified with stitching only as a first step. Once verified, we add the GeniSiteMon Controller in AL2S and any 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 AM.
  • OESS AM may not be available, so sliver creation may be done in 2 steps:
    • AL2S circuits will be set up to connect the edge ports. (This may require manual setup by I2, because of the VLAN range restrictions for FSF)
    • Stitched slivers with fixed AL2S endpoints are created for IG sites.
  • Each test lists rack endpoints we intend to use for those tests. Other racks may be substituted if necessary due to outages or scheduled events such as tutorials, although all racks were unscheduled as of May 2.

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". (All experimenters ids are for GPO staff.)

Functional testing is executed within these simple node experiments:

  1. Create a slice which establishes VLANs between AL2S InstaGENI end-points and exchange traffic between the rack endpoints. Verify AL2S router proxy statistics.
  2. Create slices and generate traffic to use all the VLANs specified for the endpoints (see configuration information listed in Network Details). Verify VLANs are successfully created and traffic is flowing as expected in AL2S router proxy statistics. Verify traffic in GENI local data store measurements to the extent possible.
  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. Test limits configured in FSF for control plane rate limits, and verify enforcement. (This step likely requires cooperation from I2, since GPO may not have the ability to directly affect controller to attempt to exceed control plane rate limits.
  6. Query FSF status and rules via SNAPP.
  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 that request fails.

FSF-T2 AL2S interconnects tests

This test may be executed for sites the may not transition to ION in the time frame of this plan. Both slices shown will be setup using each of the 10 interconnects between ION and AL2s:

This test may only be executed if a GENI site remains on ION and has not transitioned to AL2S when this plan is executed.

ION to AL2S cross-connects

The following cross-connects will be verified in the OpenFlow topologies shown above:

  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

Conduct functional testing similar to that specified in FSF-T1 for these slices. Control plane limits and out-of-range VLAN tests from FSF-T1 will only be conducted for two simultaneously active slices, because the topology changes should not affect those tests.

FSF-T3 Linear Topologies tests

Multiple concurrent linear topologies will be set up by multiple experimenters. Topologies are run without the GeniSiteMon Controller first, to verify connectivity. Once verified that no connectivity exists without the controller, the topologies will be run GeniSiteMon Controller and traffic will be verified end-to-end:

Review of available statistics will take place to ensure that resource allocation and usage is properly captured in the available tools in AL2S Router Proxy, SNAPP, and GENI local data stores for I2 AL2S.

FSF-T4 Star Topology tests

A version of this topology will be set up to support multiple simultaneous experiments:

Test Characteristics

Experimenter Controllers

Each experiment will be run without the GeniSiteMon Controller to verify that no connectivity exists without the controller. Following that, GPO will enable the GeniSiteMon Controller to enable traffic for the AL2S sites.

Test Characteristics

  • Both raw-pc and Xen VMs will be used at InstaGENI end-points.
  • All experiments will request the default bandwidth allocation (100Mb/s), unless otherwise stated.

Experimenter Generated traffic

Iperf will be used to generate TCP and UDP traffic for short (60 second test) runs. For iperf TCP traffic, 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, we will increase or decrease bandwidth requests.

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

Last modified 4 years ago Last modified on 02/02/15 14:32:20

Attachments (4)

Download all attachments as: .zip