Start Test

The Start Test API functions allow you to define and start Network Virtualization tests.

The following test modes are supported:

  • NTX Mode: Run a test using the network configuration specified in an .ntxx file.
  • Custom Mode: Run a test using a network configuration specified in the API call.
  • Location Based Mode: Run a test using a location created in the NV Location Editor.

NTX Mode

This API allows the use of predefined .ntxx files created in NV Test Manager and the NV Global Library.

Note: .ntxx files used for this API function must contain client and server IP ranges.

Request

Parameters:

Mode: Sets emulation mode to SINGLE_USER or MULTI_USER. This parameter is optional and by default set to Multi User mode.

overrideIp: Set to true or false. False by default. If set to true, allows you to override the client IP defined in the .ntxx file with an ActiveAdapter value. If this parameter is true, it requires the .ntxx file to be single flow and the mode to be SINGLE_USER only.

Note: The first Start determines the mode; if a test was started in one mode following tests must use the same mode.

JSON

URL http://ip:port/shunra/api/emulation/ntx?mode=MULTI_USER&overrideIp=false
HTTP Method POST
HTTP Headers

Content-Type: multipart/form-data

Accept: application/json

Authorization: See Web Services Authentication.

Form Data

Two form data objects should be provided:

  1. "fileUpload" with .ntxx file.

  2. "metadata":
    {"testName":"myNtx",”networkScenario”:”3G”,"description":"This is my ntx"}

See RFC 1867, "Form-based File Upload in HTML"

www.ietf.org/rfc/rfc1867.txt

XML

URL http://ip:port/shunra/api/emulation/ntx?mode=MULTI_USER&overrideIp=false
HTTP Method POST
HTTP Headers

Content-Type: multipart/form-data

Accept: application/xml

Authorization: See Web Services Authentication.

Form Data

Two form data objects should be provided:

  1. "fileUpload" with .ntxx file.

  2. "metadata":
    <testMetadata>
       <testName>myNtx</testName>
       <description>This is my ntx</description>
       <networkScenario>3G</networkScenario>
    </testMetadata>
    

See RFC 1867, "Form-based File Upload in HTML"

www.ietf.org/rfc/rfc1867.txt

 

Response

On success, the Response body will contain a test token for the test that has started.

JSON

HTTP Response Code 201 - Created
HTTP Headers

Content-Type: application/json; charset=UTF-8

Location: http://ip:port/shunra/emulation/ntx/testToken

HTTP Body
{"testToken":"133a1a9e-2885-443f-9ea5-4de373d4a57a372572b2-0d25-4852-91f8-fb849056c89a"}

XML

HTTP Response Code 201 - Created
HTTP Headers

Content-Type: application/xml; charset=UTF-8

Location: http://ip:port/shunra/emulation/ntx/testToken

HTTP Body
<emulationResponse>
    <testToken>
        b00b960c-ee8b-4965-8d41-572a3da5c6e1071776abd448-4f0e-8834-8f3057a6c072
    </testToken>
</emulationResponse>

Custom Mode

This API is used to define custom values for latency, packet loss and bandwidth without using a predefined .ntxx file.

Request

The Query parameter sets the emulation mode as either Single User or Multi user. This parameter is optional and by default set to Multi User mode.

Note: The first Start determines the mode; if a test was started in one mode following tests must use the same mode.

The body of the HTTP request defines the flow parameters: flow ID, source IP, destination IP, latency, loss, bandwidth-in, bandwidth-out and capture client PL. In addition, one of the flows can be defined as a default flow.

A flow represents traffic conditions between two locations or different networks and is defined by:

  • Flow ID: a unique identifier that will be used later on by the user for real time update, statistics and other requests. Flow ID is a mandatory parameter. No special characters allowed.
  • Source IP/Source IP Range: (optional) defines the client IP address; if no value is provided, the Source IP takes the IP of the Active Adapter. Either a Source IP or a Source IP Range can be used per flow.
  • Destination IP/Destination IP Range: (optional) defines the server IP address; if no value is provided, the Destination IP will be translated to the entire network (0.0.0.1-255.255.255.255), excluding all Sources IPs in the emulation, to prevent ambiguity. Either a Destination IP or a Destination IP Range can be used per flow.
  • isCaptureClientPL: determines if the packet list is captured or not captured in a specific flow
  • Default flow mode: defines the default network emulation conditions without defining any Source and Destination IP addresses. When the only flow currently running is the default one, all traffic on the NV Test Manager machine undergoes the network conditions defined in this flow. If the default flow is running in addition to other flows only traffic that does not fit any flow, will obtain the default flow conditions. Default flow is supported only in Single User mode, and cannot be changed using a Real Time Update request. The exclude range protocol and port settings cannot be set for a default flow.
  • testMetadata: (optional) Represents test display properties as they appear when viewing the test from the Network Virtualization UI.
  • Query parameter: sets the entire test mode: SINGLE_USER mode or MULTI_USER, i.e. the first start is the one that counts. If the mode parameter is omitted the default value is MULTI_USER.

Limitations

  • "Default flow" is only allowed in one flow and only in Single User mode.

  • An empty source IP is accepted only if the destination IP is also empty; this is a shortcut to get the active adapter in the Source IP and the entire network (0.0.0.1-255.255.255.255) in the Destination IP.

  • Both the Source and the Destination IP can be empty only if the request contains only one flow. In this case the Source is assigned as the Active Adapter and the Destination is [0.0.0.1-255.255.255.255, with the exception of the Active Adapter].
    If more than one flow is sent on the Play or Add Flows request, the Source IP must be present. In this case, if the Destination IP is blank, the IP is set at [0.0.0.1-255.255.255.255, except for the Source IP].

  • When using IP ranges do not leave the Source or Destinatoin IP address empty.

  • It is not recommended to leave both the Source and the Destintation IP blank when using Multi User mode since it will affect only the first user; later requests will cause ambiguity and the test will not start.

Request (All Parameters are Given)

The test contains two flows that use the emulation parameters defined by the user.

URL http://ip:port/shunra/api/emulation/custom?mode=MULTI_USER&useProxy=[true/false]
HTTP Method POST
HTTP Headers

Content-Type: application/json

Accept: application/json

Authorization: See Web Services Authentication.

Body
{
    "flows": [{
        "flowId": "my_flow",
        "srcIp": "1.1.1.1",
        "destIp": "2.2.2.2",
        "latency": 500,
        "packetloss": 20.0,
        "bandwidthIn": 2048.0,
        "bandwidthOut": 2048.0,
        "isCaptureClientPL": "true"
    }, {
        "flowId": "my_flow2",
        "srcIp": "1.1.2.2",
        "destIp": "2.1.1.1",
        "latency": 500,
        "packetloss": 10.0,
        "bandwidthIn": 2048.0,
        "bandwidthOut": 148.0,
        "isCaptureClientPL": "true"
        "shareBandwidth" : "true/false"
    }],
    "testMetadata": {
        "testName":"myNtx",
        "description":"it is my ntx",
        "networkScenario":"3G"
    }
}

Request (Empty Source and/or Destination IP in a Single Flow)

A single flow with an empty source IP and an empty destination IP is interpreted as a flow with the active adapter IP in the client Endpoint and the entire network (0.0.0.1-255.255.255.255) excluded active adapter in the server Endpoint.

JSON

URL http://ip:port/shunra/api/emulation/custom?mode=MULTI_USER&useProxy=[true/false]
HTTP Method POST
HTTP Headers

Content-Type: application/json

Accept: application/json

Authorization: See Web Services Authentication.

Body
{
    "flows": [{
        "flowId": "my_flow",
        "latency": 500,
        "packetloss": 20.0,
        "bandwidthIn": 2048.0,
        "bandwidthOut": 2048.0,
        "isCaptureClientPL": "true"
    }],
    "testMetadata": {
        "testName":"myNtx",
        "description":"it is my ntx",
        "networkScenario":"3G"
    }
}

XML

URL http://ip:port/shunra/api/emulation/custom?mode=MULTI_USER&useProxy=[true/false]
HTTP Method POST
HTTP Headers

Content-Type: application/xml

Accept: application/xml

Authorization: See Web Services Authentication.

Body
<emulationCustomRequest>
    <flows>
        <flowId>my_flow</flowId>
        <latency>500.0</latency>
        <packetloss>20.0</packetloss>
        <bandwidthIn>2048.0</bandwidthIn>
        <bandwidthOut>2048.0</bandwidthOut>
        <isCaptureClientPL>true</isCaptureClientPL>
    </flows>
    <testMetadata>
        <testName>myNtx</testName>
        <description>it is my ntx</description>
        <networkScenario>3G</networkScenario>
    </testMetadata>
</emulationCustomRequest>

Request (Empty Destination IP in Single and Multi User Flows)

A flow with an empty destination IP is interpreted as a flow with destination IP range to entire network (0.0.0.1-255.255.255.255). It excludes all sources IPs in the emulation, in order to pass validation.

JSON

URL http://ip:port/shunra/api/emulation/custom?mode=MULTI_USER&useProxy=[true/false]
HTTP Method POST
HTTP Headers

Content-Type: application/json

Accept: application/json

Authorization: See Web Services Authentication.

Body
{
    "flows": [{
        "flowId": "flow33",
        "srcIp": "1.1.1.1",
        "latency": 500,
        "packetloss": 20.0,
        "bandwidthIn": 2048.0,
        "bandwidthOut": 2048.0,
        "isCaptureClientPL": "false"
    }],
    "testMetadata": {
        "testName":"myNtx",
        "description":"it is my ntx",
        "networkScenario":"3G"
    }
}

XML

URL http://ip:port/shunra/api/emulation/custom?mode=MULTI_USER&useProxy=[true/false]
HTTP Method POST
HTTP Headers

Content-Type: application/xml

Accept: application/xml

Authorization: See Web Services Authentication.

Body
<emulationCustomRequest>
    <flows>
        <flowId>my_flow2</flowId>
        <srcIp>1.1.1.1</srcIp>
        <latency>500.0</latency>
        <packetloss>10.0</packetloss>
        <bandwidthIn>2048.0</bandwidthIn>
        <bandwidthOut>148.0</bandwidthOut>
        <isCaptureClientPL>false</isCaptureClientPL>
    </flows>
    <testMetadata>
        <testName>myNtx</testName>
        <description>it is my ntx</description>
        <networkScenario>3G</networkScenario>
    </testMetadata>
</emulationCustomRequest>

Request (Default Flow Mode)

This flag is supported in Single User mode only. The given IPs are ignored since the default flow mode set all traffic to be emulated.

JSON

URL http://ip:port/shunra/api/emulation/custom?mode=SINGLE_USER
HTTP Method POST
HTTP Headers

Content-Type: application/json

Accept: application/json

Authorization: See Web Services Authentication.

Body
{
    "flows": [{
        "flowId": "flow33",
        "srcIp": "1.1.1.1",
        "latency": 500,
        "packetloss": 20.0,
        "bandwidthIn": 2048.0,
        "bandwidthOut": 2048.0,
        "isCaptureClientPL": "true",
        "isDefaultFlow": "true"
    }],
    "testMetadata": {
        "testName":"myNtx",
        "description":"it is my ntx",
        "networkScenario":"3G"
    }
}

XML

URL http://ip:port/shunra/api/emulation/custom?mode=SINGLE_USER
HTTP Method POST
HTTP Headers

Content-Type: application/xml

Accept: application/xml

Authorization: See Web Services Authentication.

Body
<emulationCustomRequest>
    <flows>
        <flowId>my_flow</flowId>
        <srcIp>1.1.1.1</srcIp>
        <latency>500.0</latency>
        <packetloss>20.0</packetloss>
        <bandwidthIn>2048.0</bandwidthIn>
        <bandwidthOut>2048.0</bandwidthOut>
        <isCaptureClientPL>true</isCaptureClientPL>
        <isDefaultFlow>true</isDefaultFlow>
    </flows>
    <testMetadata>
        <testName>myNtx</testName>
        <description>it is my ntx</description>
        <networkScenario>3G</networkScenario>
    </testMetadata>
</emulationCustomRequest>

Request (Source IP in Range Format)

In order to pass a range of IPs, the request contains the optional property "srcIpRange", with the list of exclude and include ranges.

This functionality can be applied on the destination IP in the exact same way, under the property "destIpRange".

JSON

URL http://ip:port/shunra/api/emulation/custom?mode=SINGLE_USER
HTTP Method POST
HTTP Headers

Content-Type: application/json

Accept: application/json

Authorization: See Web Services Authentication.

Body
{
    "flows": [{
        "flowId": "flow33",
        "srcIpRange": {
            "include": [{
                "from": "1.1.1.1",
                "to": "7.7.7.7",
                "port": 5555,
                "protocol": 17
            }, {
                "from": "172.30.4.5",
                "to": "198.168.4.5",
                "port": 5555,
                "protocol": 17
            }],
            "exclude": [{
                "from": "1.2.3.4",
                "to": "1.3.4.5",
                "port": 5555,
                "protocol": 17
            }]
        },
        "latency": 500,
        "packetloss": 20.0,
        "bandwidthIn": 2048.0,
        "bandwidthOut": 2048.0,
        "isCaptureClientPL": "true"
    }],
    "testMetadata": {
        "testName":"myNtx",
        "description":"it is my ntx",
        "networkScenario":"3G"
    }
}

XML

URL http://ip:port/shunra/api/emulation/custom?mode=SINGLE_USER
HTTP Method POST
HTTP Headers

Content-Type: application/xml

Accept: application/xml

Authorization: See Web Services Authentication.

Body
<emulationCustomRequest>
    <flows>
        <flowId>my_flow</flowId>
        <destIp>2.2.2.2</destIp>
        <srcIpRange>
            <include>
                <from>1.1.8.1</from>
                <to>1.1.10.1</to>
                <port>80</port>
                <protocol>17</protocol>
            </include>
            <exclude>
                <from>1.2.3.4</from>
                <to>1.3.4.5</to>
                <port>5555</port>
                <protocol>17</protocol>
            </exclude>
        </srcIpRange>
        <latency>500.0</latency>
        <packetloss>20.0</packetloss>
        <bandwidthIn>2048.0</bandwidthIn>
        <bandwidthOut>2048.0</bandwidthOut>
        <isCaptureClientPL>true</isCaptureClientPL>
        <isDefaultFlow>false</isDefaultFlow>
    </flows>
    <testMetadata>
        <testName>myNtx</testName>
        <description>it is my ntx</description>
        <networkScenario>3G</networkScenario>
    </testMetadata>
</emulationCustomRequest>

Response

On success, the response body will contain the test token for the running test.

JSON

HTTP Response Code 201 - Created
HTTP Headers

Content-Type: application/json; charset=UTF-8

Location: http://ip:port/shunra/emulation/ntx/92d8ebb2-012d-4fef-94ac-b8c0e3288918f8572958-833a-4cb7-84d9-97ad5ff7aa67

HTTP Body
{"testToken":"133a1a9e-2885-443f-9ea5-4de373d4a57a372572b2-0d25-4852-91f8-fb849056c89a"}

XML

HTTP Response Code 201 - Created
HTTP Headers

Content-Type: application/xml; charset=UTF-8

Location: http://ip:port/shunra/emulation/ntx/92d8ebb2-012d-4fef-94ac-b8c0e3288918f8572958-833a-4cb7-84d9-97ad5ff7aa67

HTTP Body
<emulationResponse>
    <testToken>
        b00b960c-ee8b-4965-8d41-572a3da5c6e1071776ab-d448-4f0e-8834-8f3057a6c072
    </testToken>
</emulationResponse>

Location Based Mode

The API is used to start an emulation based on predefined locations generated in the NV Location Editor.

Request

  • Locations: the request body should contain a list of the Locations’ metadata as returned by the NV Location Editor. Each Location must have a unique "ID".
  • Locations’ Source IPs and Destination IPs: Source IP (“srcIp”) or Source IP Range (“srcIpRange”) and Destination IP (“destIp”) or Destination IP Range (“destIpRange”) can be defined for each Location in one of the following methods:
    • Both Source and Destination IP/IP Range are defined.
    • Only a “srcIp”is defined for a location, its Destination IP Range will automatically be completed with the entire IP range (0.0.0.1-255.255.255.255) excluding all of the Locations’“srcIp”(to prevent ambiguity between the Locations).

      Automatic Destination IP Range is not supported when using “srcIpRange”. In Single-User mode, Automatic Destination IP Range is supported only when there is a single Location in the request.

    • Both Source and Destination IPs are not defined; in this case the Dynamic Filter functionality will be used. Dynamic Filter functionality is explained in the end of the section.
  • isCaptureClientPl: set “isCaptureClientPl” to True for capturing packets for a location. Set the flag to False in order to disable packet capture. The parameter is optional and its default value is false.
  • excludeIPRange: Excluded IP ranges define traffic that should not be affected by emulation. It will be added to all Locations in the request.

    Note: Note: Do not define an excluded IP range if you are going to use the Dynamic Filter functionality.

  • Query parameter “mode”: sets the emulation mode as either Single-User (“SINGLE_USER”) or Multi-User (“MULTI_USER”). This parameter is optional and its default value is Multi-User.

Note:  

  • Real Time Updates are not supported if the test was started in the Location Based Mode.
  • The first Start Test request determines whether NV is in Single-User mode or Multi-User mode.
  • Playing recorded data, dynamic filter and non-shared bandwidth functionality are supported only in Single User mode and not supported in Multi-User mode.

Request

JSON

URL http://ip:port/shunra/api/emulation/bylocations?mode=SINGLE_USER
HTTP Method POST
HTTP Headers

Content-Type: application/json

Accept: application/json

Authorization: See Web Services Authentication.

Body
{
    "locations": [{
        "id": "My_uniq_Id",
        "locationMetadata": {
            "id": "My_uniq_Id",
            "type": "CUSTOM",
            "latency": 10,
            "packetloss": 12.5,
            "bandwidthIn": 0.0,
            "bandwidthOut": 0.0,
            "isCaptureClientPl": false,
            "sharedBandwidth": true
        },
        "destIp": "5.6.7.8",
        "srcIpRange": {
            "include": [{
                "from": "8.8.8.8",
                "to": "8.8.8.9",
                "port": 8183,
                "protocol": 6
            }],
            "exclude": []
        }
    }, {
        "id": "My_uniq_Id2",
        "locationMetadata": {
            "id": "My_uniq_Id2",
            "type": "CUSTOM",
            "latency": 12,
            "packetloss": 15.0,
            "bandwidthIn": 0.0,
            "bandwidthOut": 0.0,
            "isCaptureClientPl": false,
            "sharedBandwidth": true
        },
        "destIp": "5.6.7.9",
        "srcIpRange": {
            "include": [{
                "from": "8.8.8.3",
                "to": "8.8.8.4",
                "port": 8183,
                "protocol": 6
            }],
            "exclude": []
        }
    }],
    "excludeIpRange": [{
        "from": "1.1.1.1",
        "to": "2.2.2.2",
        "protocol": 6,
        "port": 8182
    }],
    "isCaptureClientPl": false
}

XML

URL http://ip:port/shunra/api/emulation/bylocations?mode=SINGLE_USER
HTTP Method POST
HTTP Headers

Content-Type: application/xml

Accept: application/xml

Authorization: See Web Services Authentication.

Body
<emulationByLocationsRequest>
	<locations>
		<id>My_uniq_Id</id>
		<locationMetadata>
			<id>My_uniq_Id</id>
			<type>CUSTOM</type>
			<latency>10</latency>
			<packetloss>12.5</packetloss>
			<bandwidthIn>0</bandwidthIn>
			<bandwidthOut>0</bandwidthOut>
			<isCaptureClientPl>false</isCaptureClientPl>
			<sharedBandwidth>true</sharedBandwidth>
		</locationMetadata>
		<destIp>5.6.7.8</destIp>
		<srcIpRange>
			<include>
				<from>8.8.8.8</from>
				<to>8.8.8.9</to>
				<port>8183</port>
				<protocol>6</protocol>
			</include>
		</srcIpRange>
	</locations>
	<locations>
		<id>My_uniq_Id2</id>
		<locationMetadata>
			<id>My_uniq_Id2</id>
			<type>CUSTOM</type>
			<latency>12</latency>
			<packetloss>15</packetloss>
			<bandwidthIn>0</bandwidthIn>
			<bandwidthOut>0</bandwidthOut>
			<isCaptureClientPl>false</isCaptureClientPl>
			<sharedBandwidth>true</sharedBandwidth>
		</locationMetadata>
		<destIp>5.6.7.9</destIp>
		<srcIpRange>
			<include>
				<from>8.8.8.3</from>
				<to>8.8.8.4</to>
				<port>8183</port>
				<protocol>6</protocol>
			</include>
		</srcIpRange>
	</locations>
	<excludeIpRange>
		<from>1.1.1.1</from>
		<to>2.2.2.2</to>
		<protocol>6</protocol>
		<port>8182</port>
	</excludeIpRange>
	<isCaptureClientPl>false</isCaptureClientPl>
	
</emulationByLocationsRequest>

Response

On success, the response body will contain Test Token for the started test.

JSON

HTTP Response Code 201 - Created
HTTP Headers Content-Type: application/json; charset=UTF-8
HTTP Body
{
    "testToken": "133a1a9e-2885-443f-9ea5-4de373d4a57a372572b2-0d25-4852-91f8-fb849056c89a"
}

XML

HTTP Response Code 201 - Created
HTTP Headers Content-Type: application/xml; charset=UTF-8
HTTP Body
<emulationResponse>
    <testToken>b00b960c-ee8b-4965-8d41-572a3da5c6e1071776abd448-4f0e-8834-8f3057a6c072</testToken>
</emulationResponse>

Dynamic Filter

Dynamic filters are designed to support testing concurrent process instances, where each instance may create multiple TCP connections without prior knowledge of connection details (i.e. <IP:port> pair). This is achieved by setting up locations with predefined network conditions but without IP range specifications. Whenever a given process instance starts a TCP connection, it provides its assigned location ID using the addDynamicFilter API, and thus the emulation agent will know which flow to use for traffic carried on that connection.

For tests with heavy loads with where new connections are created very frequently (up to a few thousand per second) Real Time Updates in these situations are not efficient. The API to connect and disconnect Dynamic Filter is not a web API, but is a Java-based API. Therefore, no validations are performed on Connect or Disconnect requests. This API is used to assign and unassign the IP\Ports dynamically and to communicate with the native emulation engine code.

Once a location-based emulation has been started without a Source and Destination IP\Range, the test runs in Dynamic Filter mode. In this mode the Source and Destination IPs can be added dynamically.

Public API Usage

To call the public Java API:

From your code, reference the dynamicfilter.jar library. This jar is located under <NV Test Manager installation>/lib/shunra/vcat folder.

The API implements class ’com.shunra.dynamicfilter.impl.DynamicFilterProxy’. Use it from your code.

The class has three public methods:

  • public void configure(String configFile)

    Use to initialize the class by snvcontroller.properties file location; a one-time call at test start. Snvcontroller.properties file is located in <NV Test Manager installation>\conf folder.

  • public int addDynamicFilter(String clientIp, String serverIp, short clientPort, short serverPort, String locationId, short userId);

    Use it to add a dynamic filter whenever a new TCP connection is initiated. If possible, we recommend tying a hook to the socket Connect function for this purpose.

    If a system call hooking is not supported by the development environment, or if the developer decides not to use it, the second best option is to call it immediately after successful return from socket connect. Note that with the second option the connection establishment exchange is not affected by emulation.

    The locationId is the value that was returned during the createLocation operation. If you do not know the exact client side IP, you can provide 0.0.0.0 and NV agent will determine it according to the traffic. If no port is provided, the default value=allPorts is used.

    userId: This is very important when dynamic filters are used in conjunction with non-shared bandwidth. There may be many users (process instances) assigned the same location. The emulation driver will allocate bandwidth based on user ID, such that there will be no competition for bandwidth between users (only between different connections for the same user). Assuming a process instance simulates a virtual user, a unique user ID should be assigned to each such instance. Note that there is no significance to the number in userID, provided that it is unique in the test scope.

  • public int deleteDynamicFilter(String clientIp, String serverIp, short clientPort, short serverPort);

    use to remove the dynamic filter after the socket is closed.

The example of java API usage:

try {
    DynamicFilterProxy proxy = new DynamicFilterProxy();
    proxy.configure("<NV Test Manager home>\conf\snvcontroller.properties");
    short cport = 0;
    short sport = 0;
    short uid = 0;
    proxy.addDynamicFilter("172.30.2.80", "172.30.2.101", cport, sport, "myLocation_id", uid);
} catch (Exception e) {
    System.out.println("Operation failed: " + e.getMessage());
}

Command Line Execution

The Command Line used when integrating with non-Java applications.

The API can be executed by the command line from <NV Test Manager installation>/lib/shunra/vcat folder:

To connect a new Client-Server IP\Port pair (example):

java -classpath dynamicfilter.jar com.shunra.dynamicfilter.impl.DynamicFilterProxy -operation connect -clientIp 172.30.2.80 -serverIp 172.30.2.101 -clientPort 0 -serverPort 0 -locationId My_location_uniq_Id -userId 0

The locationId is the value that was returned during the createLocation operation. If you do not know the exact client side IP, you can provide 0.0.0.0 and Network Virtualization will determine it according to the traffic. If no port is provided, the default value=allPorts is used.

The example above will add the IPs for location My_location_uniq_Id according to the clientIp, serverIp, clientPort, serverPort parameters.

To disconnect (example):

java -classpath dynamicfilter.jar com.shunra.dynamicfilter.impl.DynamicFilterProxy -operation disconnect -clientIp 172.30.2.80 -serverIp 172.30.2.101 -clientPort 0 -serverPort 0