NTAP2 Network Performance Test USAGE: testpilot.py | [] DEFINING THE TESTPATH [with hosts]: -s, --host1IP test initiator's IP address, e.g. 141.200.1.50 -m, --host1Netmask test initiator's netmask, e.g. 255.255.255.0 -d, --host2IP test target's IP address -n, --host2Netmask test target's netmask DEFINING THE TESTPATH [from file]: -p, --pathmap an arbitrary number of waypoints can be specified to build a test path of PMPs. must have 'anchorHost1' and 'anchorHost2' defined in the file, along with any number of optional 'waypointHost' entries. see the example file "manual-testpath.conf". this flag can only be used once. FLAGS WITHOUT ARGUMENTS: --dryrun do everything BUT run the actual tests [IMPLIES --nosave] --bidir instead of one, make two serial, antiparallel test schedules. --noldap do not use the LDAP directory; ONLY meaningful with -p/--pmps --nodiscovery do not discover intermediate PMPs; ONLY perform an end-to-end (i.e. one-hop) test. ONLY meaningful with -p/--pmps or -r/--routers. --nosave do not attempt to save results to the output database. --tmpsave attempt to save results to the tempfile named "/tmp/testpilot--tmp-save.ldif" instead of the output db. --saveldif do not delete the raw LDIF file of test results after saving. --exit-on-error stop at the first test error encountered --continue-on-error even if a test application fails, keep trying others [DEFAULT] FLAGS WITH ARGUMENTS: --userdn "DN" refers to the kX.509-style distinguished name of the user who invoked the test. This is recorded in output data. --testlabel "name" represents an informal label for the overall set of tests, e.g., "Nightly-iperf-test" or "Router-core-TCP-test". This is recorded in output data. --program an arbitrary number of programs can be run (serially) at each (hop-wise) round of testing. this flag can be used multiple times, each time with a valid application- specific configuration file as an argument. "iperf.conf" is a demo (and the default) setup used by `testpilot.py'. --pathmod "mod" refers to additional hop-tests that get scheduled along the test path. valid modifications are: ends IN ADDITION to all the adjacent-hops' tests, schedule an extra test between the two anchor hosts. e.g. "a,b - b,c - c,d" would also add the test "a,d" to the schedule. cascade INSTEAD OF running the adjacent-hops' tests (use the above example of "a,b - b,c - c,d"), schedule the tests as a cascade from the first anchor to the far one. So, the previous example would become "a,b - a,c - a,d" -- a little cascade, as it were. --ldap use alternate LDAP server for router/PMP discovery. --tracer a tracer is, e.g., traceroute -- used for path discovery. current valid options are "traceroute" [DEFAULT] and "tcptraceroute". "localtraceroute" runs from the portal. --savepathmap save to "file" a '--pathmap'-compatible file of the anchors and waypoints used in the test. --mode "mode" refers to the manner in which PMP interfaces are chosen during testing. valid modenames are: simple don't choose VIFs based on trying to accurately proxy endhost traffic; instead, just use the PMPs' default IP addresses (i.e., don't attempt to proxy). source "source QoS" -- try to minimize asymmetric routes by emphasizing 'forward' traffic. that is, try to accurately proxy traffic going from host1 -> host2, but merely 'reflect' traffic back upstream on the same subnet/VLAN as it came in on. please see the web. full "full QoS" -- doesn't worry about asymmetric paths beyond the first-hop router; instead, accurate proxying is favored. in terms of difficulty-of-proxying, this it the hardest; that is, it is the most dependent on having good subnets/VLANs available.