Version 31 (modified by, 9 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 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 realted to FSFW.
  • 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 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 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 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 FSFW)
    • 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 will actually be 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 FSFW 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 FSFW range, verify rejection.
  9. Request network capacity beyond configured FSF capacity, verify that request fails.

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:

  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, the topologies will be run GeniSiteMon Controller.

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 connectivity. Following that, we will enable the GeniSiteMon Controllerto enable traffic for all AL2S slices.

Test Characteristics

  • Both raw-pc and Xen VMs will be used at IG end-points.
  • All experiments 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 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.

Attachments (4)

Download all attachments as: .zip