wiki:GENIFlowSpaceFirewallTests

Version 25 (modified by lnevers@bbn.com, 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.

Assumptions

  • 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.
  • 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.
  • Layer 2 hardware matching is validated, there is no Layer 3 matching at this time.
  • Tests are described in this plan with the assumption that GENI networks 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 fixed AL2S endpoint 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: urn:publicid:IDN+ion.internet2.edu+interface+rtr.kans:xe-0/0/3:missouri-ig

Stanford InstaGENI:
Site VLANs: 1630-1639 - AL2S end-point: SUNN
ION cross connect: urn:publicid:IDN+ion.internet2.edu+interface+rtr.salt:xe-0/1/1:stanford-ig


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. sdn-sw.seat e-2/0/0.0 <-> rtr.seat:port=et-5/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