Skip to content

Testing

Jump to bottom
AndriiDovhan edited this page Mar 5, 2020 · 27 revisions

Kilda consists of next testing layers:

Each module has a comprehensive README file, describing the purpose, how to run, etc.
Currently we actively develop 'unit tests' and 'functional tests' modules. ATDD-staging contains high-level cucumber scenarios which we run as smoke set and rarely update.

Coverage

It's really difficult to assess the coverage rate. We compiled a list of high-level test-cases, marked which ones are covered by automation and compiled a percentage 'rate' of how much is covered. But one should understand that provided numbers is a rough estimate.

Defects

Defects are logged to the backlog and assigned to the 'Open Kilda Board' project. Each defect should also have label 'Bug' and one of the 'priority' labels. As usual, defect should have steps to reproduce, expected and actual result.
If possible, it is preferable to provide a branch with functional-test that reproduces the issue.

Test Cases

This section contains description of all test cases that are currently covered by automation.

FeatureTogglesV2

Feature Toggles is a special lever that allows to turn on/off certain Kilda features. For example, we can disable creation of new flows via Northbound API. This spec verifies that Feature Toggle restrictions are applied correctly.

  • System forbids creating new flows when 'create_flow' toggle is set to false

    Given: Existing flow

    When: Set create_flow toggle to false

    And: Try to create a new flow

    Then: Error response is returned, explaining that feature toggle doesn't allow such operation

    And: Update of previously existing flow is still possible

    And: Delete of previously existing flow is still possible

    And: Cleanup: set create_flow toggle back to true

  • System forbids updating flows when 'update_flow' toggle is set to false

    Given: Existing flow

    When: Set update_flow toggle to false

    And: Try to update the flow

    Then: Error response is returned, explaining that feature toggle doesn't allow such operation

    And: Creating new flow is still possible

    And: Deleting of flows is still possible

    And: Cleanup: set update_flow toggle back to true

  • System forbids deleting flows when 'delete_flow' toggle is set to false

    Given: Existing flow

    When: Set delete_flow toggle to false

    And: Try to delete the flow

    Then: Error response is returned, explaining that feature toggle doesn't allow such operation

    And: Creating new flow is still possible

    And: Updating of flow is still possible

    When: Set delete_flow toggle back to true

    Then: Able to delete flows

FeatureToggles

Feature Toggles is a special lever that allows to turn on/off certain Kilda features. For example, we can disable creation of new flows via Northbound API. This spec verifies that Feature Toggle restrictions are applied correctly.

  • System forbids creating new flows when 'create_flow' toggle is set to false

    Given: Existing flow

    When: Set create_flow toggle to false

    And: Try to create a new flow

    Then: Error response is returned, explaining that feature toggle doesn't allow such operation

    And: Update of previously existing flow is still possible

    And: Delete of previously existing flow is still possible

    And: Cleanup: set create_flow toggle back to true

  • System forbids updating flows when 'update_flow' toggle is set to false

    Given: Existing flow

    When: Set update_flow toggle to false

    And: Try to update the flow

    Then: Error response is returned, explaining that feature toggle doesn't allow such operation

    And: Creating new flow is still possible

    And: Deleting of flows is still possible

    And: Cleanup: set update_flow toggle back to true

  • System forbids deleting flows when 'delete_flow' toggle is set to false

    Given: Existing flow

    When: Set delete_flow toggle to false

    And: Try to delete the flow

    Then: Error response is returned, explaining that feature toggle doesn't allow such operation

    And: Creating new flow is still possible

    And: Updating of flow is still possible

    When: Set delete_flow toggle back to true

    Then: Able to delete flows

Switches

  • System is able to return a list of all switches

    Expect: System can return list of all switches

  • System is able to return a certain switch info by its id

    When: Request info about certain switch from Northbound

    Then: Switch information is returned

  • Informative error is returned when requesting switch info with non-existing id

    When: Request info about non-existing switch from Northbound

    Then: Not Found error is returned

  • Systems allows to get a flow that goes through a switch

    Given: Two active not neighboring switches with two diverse paths at least

    And: A protected flow

    And: A single switch flow

    When: Get all flows going through the involved switches

    Then: The created flows are in the response list from the src switch

    And: Only the protectedFlow is in the response list from the involved switch(except the src switch)

    When: Get all flows going through the src switch based on the port of the main path

    Then: Only the protected flow is in the response list

    When: Get all flows going through the src switch based on the port of the protected path

    Then: Only the protected flow is in the response list

    When: Get all flows going through the src switch based on the dstPort of the single switch flow

    Then: Only the single switch flow is in the response list

    When: Get all flows going through the dst switch based on the dstPort of the protected flow

    Then: Only the protected flow is in the response list

    When: Bring down all ports on src switch to make flow DOWN

    And: Get all flows going through the src switch

    Then: The created flows are in the response list

    And: Cleanup: Delete the flows

  • Informative error is returned when requesting all flows going through non-existing switch

    When: Get all flows going through non-existing switch

    Then: Human readable error is returned

  • Systems allows to get all flows that goes through a DEACTIVATED switch

    Given: Two active not neighboring switches

    And: A simple flow

    And: A single switch flow

    When: Deactivate the src switch

    And: Get all flows going through the deactivated src switch

    Then: The created flows are in the response list from the deactivated src switch

    And: Cleanup: Revive the src switch and delete the flows

SwitchValidation

This test suite checks the switch validate feature followed by switch synchronization for different type of rules and different rules states. Rules states: excess, missing, proper. Rule types: ingress, egress, transit, special (protected path rules, connected devices rules etc.) Note that 'default' rules are not covered by this spec. Description of fields:

  • missing - those meters/rules, which are NOT present on a switch, but are present in db
  • misconfigured - those meters which have different value (on a switch and in db) for the same parameter
  • excess - those meters/rules, which are present on a switch, but are NOT present in db
  • proper - meters/rules values are the same on a switch and in db

  • Able to validate and sync a terminating switch with proper rules and meters

    Given: A flow

    Expect: Validate switch for src and dst contains expected meters data in 'proper' section

    And: The rest fields in the 'meter' section are empty

    And: Created rules are stored in the 'proper' section

    And: The rest fields in the 'rule' section are empty

    And: Able to perform switch sync which does nothing

    When: Delete the flow

    Then: Switch validate request returns only default rules information

  • Able to validate and sync a transit switch with proper rules and no meters

    Given: Two active not neighboring switches

    When: Create an intermediate-switch flow

    Then: The intermediate switch does not contain any information about meter

    And: Rules are stored in the 'proper' section on the transit switch

    And: Able to perform switch sync which does nothing

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Able to validate switch with 'misconfigured' meters

    When: Create a flow

    And: Change bandwidth for the created flow directly in DB so that system thinks the installed meter is misconfigured

    And: Validate src and dst switches

    Then: Meters info is moved into the 'misconfigured' section

    And: Reason is specified why meter is misconfigured

    And: The rest fields of 'meter' section are empty

    And: Created rules are still stored in the 'proper' section

    And: Flow validation shows discrepancies

    When: Restore correct bandwidth via DB

    Then: Misconfigured meters are moved into the 'proper' section

    And: Flow validation shows no discrepancies

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Able to validate and sync a switch with missing ingress rule + meter

    When: Create a flow

    And: Remove created meter on the srcSwitch

    Then: Meters info/rules are moved into the 'missing' section on the srcSwitch

    And: Meters info/rules are NOT moved into the 'missing' section on the dstSwitch

    When: Synchronize switch with missing rule and meter

    Then: Repeated validation shows no missing entities

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Able to validate and sync a switch with missing ingress rule (unmetered)

    When: Create a flow

    And: Remove ingress rule on the srcSwitch

    Then: Ingress rule is moved into the 'missing' section on the srcSwitch

    When: Synchronize switch with missing unmetered rule

    Then: Repeated validation shows no missing entities

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Able to validate and sync a switch with missing transit rule

    Given: Two active not neighboring switches

    And: Create an intermediate-switch flow

    When: Delete created rules on the transit

    Then: Rule info is moved into the 'missing' section

    When: Synchronize the switch

    Then: Repeated validation shows no discrepancies

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections on all involved switches

  • Able to validate and sync a switch with missing egress rule

    Given: Two active not neighboring switches

    And: Create an intermediate-switch flow

    When: Delete created rules on the srcSwitch

    Then: Rule info is moved into the 'missing' section on the srcSwitch

    And: Rule info is NOT moved into the 'missing' section on the dstSwitch and transit switches

    When: Synchronize the switch

    Then: Repeated validation shows no discrepancies

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections on all involved switches

  • Able to validate and sync an excess ingress/egress/transit rule + meter

    Given: Two active not neighboring switches

    And: Create an intermediate-switch flow

    When: Create excess rules on switches

    Then: Switch validation shows excess rules and store them in the 'excess' section

    And: Excess meter is shown on the srcSwitch only

    When: Try to synchronize every involved switch

    Then: System deletes excess rules and meters

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections on all involved switches

    Cleanup: ----

  • Able to validate and sync a switch with missing 'vxlan' ingress/transit/egress rule + meter

    Given: Two active not neighboring Noviflow switches

    And: Create a flow with vxlan encapsulation

    And: Remove required rules and meters from switches

    Expect: Switch validation shows missing rules and meters on every related switch

    When: Try to synchronize all switches

    Then: System installs missing rules and meters

    And: Switch validation doesn't complain about missing rules and meters

    And: Rules are synced correctly

    And: Delete the flow

  • Able to validate and sync a missing 'protected path' egress rule

    Given: A flow with protected path

    When: Validate rules on the switches

    Then: Rules are stored in the 'proper' section

    When: Delete rule of protected path on the srcSwitch (egress)

    Then: Deleted rule is moved to the 'missing' section on the srcSwitch

    And: Rest switches are not affected by deleting the rule on the srcSwitch

    When: Synchronize switch with a missing protected path egress rule

    Then: Switch validation no longer shows missing rules

    And: Cleanup: delete the flow

  • Able to validate and sync a missing 'connected device' LLDP rule

    Given: A flow with enabled connected devices

    Expect: Switch validation puts connected device lldp rule into 'proper' section

    When: Remove the connected device lldp rule

    Then: Switch validation puts connected device lldp rule into 'missing' section

    When: Synchronize the switch

    Then: Switch validation no longer shows any discrepancies in rules

    When: Delete the flow

    Then: Switch validation is empty

  • Able to validate and sync a missing 'connected device' LLDP rule + meter

    Given: A flow with enabled connected devices

    Expect: Switch validation puts connected device lldp rule into 'proper' section

    When: Remove the connected device lldp meter

    Then: Switch validation puts connected device lldp rule and meter into 'missing' section

    When: Synchronize the switch

    Then: Switch validation no longer shows any discrepancies in rules nor meters

    When: Delete the flow

    Then: Switch validation is empty

SwitchValidationSingleSwFlow

This test suite checks the switch validate feature on a single flow switch. Description of fields:

  • missing - those meters/rules, which are NOT present on a switch, but are present in db
  • misconfigured - those meters which have different value (on a switch and in db) for the same parameter
  • excess - those meters/rules, which are present on a switch, but are NOT present in db
  • proper - meters/rules values are the same on a switch and in db

  • Switch validation is able to store correct information on a Centec switch in the 'proper' section

    Given: Select a Centec switch and retrieve default meters

    When: Create a flow

    Then: Two meters are automatically created.

    And: The correct info is stored in the 'proper' section

    And: Created rules are stored in the 'proper' section

    And: The rest fields in the 'rule' section are empty

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to store correct information on a Noviflow switch in the 'proper' section

    Given: Select a Noviflow switch and retrieve default meters

    When: Create a flow

    Then: Two meters are automatically created.

    And: The correct info is stored in the 'proper' section

    And: Created rules are stored in the 'proper' section

    And: The rest fields in the 'rule' section are empty

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to store correct information on a Noviflow(Wb5164) switch in the 'proper' section

    Given: Select a Noviflow(Wb5164) switch and retrieve default meters

    When: Create a flow

    Then: Two meters are automatically created.

    And: The correct info is stored in the 'proper' section

    And: Created rules are stored in the 'proper' section

    And: The rest fields in the 'rule' section are empty

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to store correct information on a OVS switch in the 'proper' section

    Given: Select a OVS switch and retrieve default meters

    When: Create a flow

    Then: Two meters are automatically created.

    And: The correct info is stored in the 'proper' section

    And: Created rules are stored in the 'proper' section

    And: The rest fields in the 'rule' section are empty

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'misconfigured' section on a Centec switch

    Given: Select a Centec switch and retrieve default meters

    When: Create a flow

    And: Change bandwidth for the created flow directly in DB

    Then: Meters info is moved into the 'misconfigured' section

    And: Reason is specified why meters are misconfigured

    And: The rest fields are empty

    And: Created rules are still stored in the 'proper' section

    And: Flow validation shows discrepancies

    When: Restore correct bandwidth via DB

    Then: Misconfigured meters are moved into the 'proper' section

    And: Flow validation shows no discrepancies

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'misconfigured' section on a Noviflow switch

    Given: Select a Noviflow switch and retrieve default meters

    When: Create a flow

    And: Change bandwidth for the created flow directly in DB

    Then: Meters info is moved into the 'misconfigured' section

    And: Reason is specified why meters are misconfigured

    And: The rest fields are empty

    And: Created rules are still stored in the 'proper' section

    And: Flow validation shows discrepancies

    When: Restore correct bandwidth via DB

    Then: Misconfigured meters are moved into the 'proper' section

    And: Flow validation shows no discrepancies

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'misconfigured' section on a Noviflow(Wb5164) switch

    Given: Select a Noviflow(Wb5164) switch and retrieve default meters

    When: Create a flow

    And: Change bandwidth for the created flow directly in DB

    Then: Meters info is moved into the 'misconfigured' section

    And: Reason is specified why meters are misconfigured

    And: The rest fields are empty

    And: Created rules are still stored in the 'proper' section

    And: Flow validation shows discrepancies

    When: Restore correct bandwidth via DB

    Then: Misconfigured meters are moved into the 'proper' section

    And: Flow validation shows no discrepancies

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'misconfigured' section on a OVS switch

    Given: Select a OVS switch and retrieve default meters

    When: Create a flow

    And: Change bandwidth for the created flow directly in DB

    Then: Meters info is moved into the 'misconfigured' section

    And: Reason is specified why meters are misconfigured

    And: The rest fields are empty

    And: Created rules are still stored in the 'proper' section

    And: Flow validation shows discrepancies

    When: Restore correct bandwidth via DB

    Then: Misconfigured meters are moved into the 'proper' section

    And: Flow validation shows no discrepancies

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'missing' section on a Centec switch

    Given: Select a Centec switch and retrieve default meters

    When: Create a flow

    And: Remove created meter

    Then: Meters info/rules are moved into the 'missing' section

    And: The rest fields are empty

    When: Try to synchronize the switch

    Then: System detects missing rules and meters, then installs them

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'missing' section on a Noviflow switch

    Given: Select a Noviflow switch and retrieve default meters

    When: Create a flow

    And: Remove created meter

    Then: Meters info/rules are moved into the 'missing' section

    And: The rest fields are empty

    When: Try to synchronize the switch

    Then: System detects missing rules and meters, then installs them

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'missing' section on a Noviflow(Wb5164) switch

    Given: Select a Noviflow(Wb5164) switch and retrieve default meters

    When: Create a flow

    And: Remove created meter

    Then: Meters info/rules are moved into the 'missing' section

    And: The rest fields are empty

    When: Try to synchronize the switch

    Then: System detects missing rules and meters, then installs them

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'missing' section on a OVS switch

    Given: Select a OVS switch and retrieve default meters

    When: Create a flow

    And: Remove created meter

    Then: Meters info/rules are moved into the 'missing' section

    And: The rest fields are empty

    When: Try to synchronize the switch

    Then: System detects missing rules and meters, then installs them

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'excess' section on a Centec switch

    Given: Select a Centec switch and retrieve default meters

    When: Create a flow

    Then: Rules and meters are created

    When: Update meterId for created flow directly via db

    Then: Origin meters are moved into the 'excess' section

    And: Updated meters are stored in the 'missing' section

    And: Rules still exist in the 'proper' section

    When: Delete the flow

    And: Delete excess meters

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'excess' section on a Noviflow switch

    Given: Select a Noviflow switch and retrieve default meters

    When: Create a flow

    Then: Rules and meters are created

    When: Update meterId for created flow directly via db

    Then: Origin meters are moved into the 'excess' section

    And: Updated meters are stored in the 'missing' section

    And: Rules still exist in the 'proper' section

    When: Delete the flow

    And: Delete excess meters

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'excess' section on a Noviflow(Wb5164) switch

    Given: Select a Noviflow(Wb5164) switch and retrieve default meters

    When: Create a flow

    Then: Rules and meters are created

    When: Update meterId for created flow directly via db

    Then: Origin meters are moved into the 'excess' section

    And: Updated meters are stored in the 'missing' section

    And: Rules still exist in the 'proper' section

    When: Delete the flow

    And: Delete excess meters

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect meter info into the 'excess' section on a OVS switch

    Given: Select a OVS switch and retrieve default meters

    When: Create a flow

    Then: Rules and meters are created

    When: Update meterId for created flow directly via db

    Then: Origin meters are moved into the 'excess' section

    And: Updated meters are stored in the 'missing' section

    And: Rules still exist in the 'proper' section

    When: Delete the flow

    And: Delete excess meters

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect rule info into the 'missing' section on a Centec switch

    Given: Select a Centec switch and retrieve default meters

    When: Create a flow

    And: Delete created rules

    Then: Rule info is moved into the 'missing' section

    And: The rest fields in the 'rule' section are empty

    When: Try to synchronize the switch

    Then: System detects missing rules, then installs them

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect rule info into the 'missing' section on a Noviflow switch

    Given: Select a Noviflow switch and retrieve default meters

    When: Create a flow

    And: Delete created rules

    Then: Rule info is moved into the 'missing' section

    And: The rest fields in the 'rule' section are empty

    When: Try to synchronize the switch

    Then: System detects missing rules, then installs them

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect rule info into the 'missing' section on a Noviflow(Wb5164) switch

    Given: Select a Noviflow(Wb5164) switch and retrieve default meters

    When: Create a flow

    And: Delete created rules

    Then: Rule info is moved into the 'missing' section

    And: The rest fields in the 'rule' section are empty

    When: Try to synchronize the switch

    Then: System detects missing rules, then installs them

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect rule info into the 'missing' section on a OVS switch

    Given: Select a OVS switch and retrieve default meters

    When: Create a flow

    And: Delete created rules

    Then: Rule info is moved into the 'missing' section

    And: The rest fields in the 'rule' section are empty

    When: Try to synchronize the switch

    Then: System detects missing rules, then installs them

    When: Delete the flow

    Then: Check that the switch validate request returns empty sections

  • Switch validation is able to detect rule info into the 'excess' section on a Centec switch

    Given: Select a Centec switch and no meters/rules exist on a switch

    When: Create excess rules directly via kafka

    Then: System detects created rules as excess rules

    And: System detects one meter as excess

    When: Try to synchronize the switch

    Then: System detects excess rules and meters, then deletes them

    And: Switch validation doesn't complain about excess rules and meters

    Cleanup: ----

  • Switch validation is able to detect rule info into the 'excess' section on a Noviflow switch

    Given: Select a Noviflow switch and no meters/rules exist on a switch

    When: Create excess rules directly via kafka

    Then: System detects created rules as excess rules

    And: System detects one meter as excess

    When: Try to synchronize the switch

    Then: System detects excess rules and meters, then deletes them

    And: Switch validation doesn't complain about excess rules and meters

    Cleanup: ----

  • Switch validation is able to detect rule info into the 'excess' section on a Noviflow(Wb5164) switch

    Given: Select a Noviflow(Wb5164) switch and no meters/rules exist on a switch

    When: Create excess rules directly via kafka

    Then: System detects created rules as excess rules

    And: System detects one meter as excess

    When: Try to synchronize the switch

    Then: System detects excess rules and meters, then deletes them

    And: Switch validation doesn't complain about excess rules and meters

    Cleanup: ----

  • Switch validation is able to detect rule info into the 'excess' section on a OVS switch

    Given: Select a OVS switch and no meters/rules exist on a switch

    When: Create excess rules directly via kafka

    Then: System detects created rules as excess rules

    And: System detects one meter as excess

    When: Try to synchronize the switch

    Then: System detects excess rules and meters, then deletes them

    And: Switch validation doesn't complain about excess rules and meters

    Cleanup: ----

  • Able to get the switch validate info on a NOT supported switch

    Given: Not supported switch

    When: Try to invoke the switch validate request

    Then: Response without meter section is returned

  • Able to validate and sync a Centec switch having missing rules of single-port single-switch flow

    Given: A single-port single-switch flow

    When: Remove flow rules from the switch, so that they become missing

    Then: Switch validation shows missing rules

    When: Synchronize switch

    Then: Switch validation shows no discrepancies

    When: Delete the flow

    Then: Switch validation returns empty sections

  • Able to validate and sync a Noviflow switch having missing rules of single-port single-switch flow

    Given: A single-port single-switch flow

    When: Remove flow rules from the switch, so that they become missing

    Then: Switch validation shows missing rules

    When: Synchronize switch

    Then: Switch validation shows no discrepancies

    When: Delete the flow

    Then: Switch validation returns empty sections

  • Able to validate and sync a Noviflow(Wb5164) switch having missing rules of single-port single-switch flow

    Given: A single-port single-switch flow

    When: Remove flow rules from the switch, so that they become missing

    Then: Switch validation shows missing rules

    When: Synchronize switch

    Then: Switch validation shows no discrepancies

    When: Delete the flow

    Then: Switch validation returns empty sections

  • Able to validate and sync a OVS switch having missing rules of single-port single-switch flow

    Given: A single-port single-switch flow

    When: Remove flow rules from the switch, so that they become missing

    Then: Switch validation shows missing rules

    When: Synchronize switch

    Then: Switch validation shows no discrepancies

    When: Delete the flow

    Then: Switch validation returns empty sections

SwitchSync

  • Able to synchronize switch without any rule and meter discrepancies (removeExcess=false)

    Given: An active switch

    When: Synchronize the switch that doesn't have any rule and meter discrepancies

    Then: Operation is successful

  • Able to synchronize switch without any rule and meter discrepancies (removeExcess=true)

    Given: An active switch

    When: Synchronize the switch that doesn't have any rule and meter discrepancies

    Then: Operation is successful

  • Able to synchronize switch (install missing rules and meters)

    Given: Two active not neighboring switches

    And: Create an intermediate-switch flow

    And: Drop all rules an meters from related switches (both default and non-default)

    When: Try to synchronize all switches

    Then: System detects missing rules and meters (both default and flow-related), then installs them

    And: Switch validation doesn't complain about any missing rules and meters

    And: Delete the flow

  • Able to synchronize switch (delete excess rules and meters)

    Given: Two active not neighboring switches

    And: Create an intermediate-switch flow

    And: Reproduce situation when switches have excess rules and meters

    When: Try to synchronize all switches

    Then: System detects excess rules and meters, then deletes them

    And: Switch validation doesn't complain about excess rules and meters

    And: Delete the flow

  • Able to synchronize switch with 'vxlan' rule(install missing rules and meters)

    Given: Two active not neighboring Noviflow switches

    And: Create a flow with vxlan encapsulation

    And: Reproduce situation when switches have missing rules and meters

    When: Try to synchronize all switches

    Then: System detects missing rules and meters, then installs them

    And: Switch validation doesn't complain about missing rules and meters

    And: Rules are synced correctly

    And: Delete the flow

SwitchProperties

Switch properties are created automatically once switch is connected to the controller and deleted once switch is deleted. Properties can be read/updated via API '/api/v1/switches/:switch-id/properties'. Main purpose of that is to understand which feature is supported by a switch(encapsulation type, multi table)

  • Able to manipulate with switch properties

    Given: A switch that supports VXLAN

    When: Update switch properties

    Then: Correct response is returned

    And: Switch properties is really updated

    Cleanup: Restore init switch properties on the switch

  • Informative error is returned when trying to get/update switch properties with non-existing id

    When: Try to get switch properties info for non-existing switch

    Then: Human readable error is returned

    When: Try to update switch properties info for non-existing switch

    Then: Human readable error is returned

  • Informative error is returned when trying to update switch properties with incorrect information

    Given: A switch

    When: Try to update switch properties info for non-existing switch

    Then: Human readable error is returned

  • System forbids to turn on VXLAN encap type on switch that does not support it

    Given: Switch that does not support VXLAN feature

    When: Try to turn on VXLAN encap type on that switch

    Then: Error is returned

    Cleanup: ----

SwitchPortConfig

Verify that Kilda allows to properly control port state on switches (bring ports up or down).

  • Able to bring ISL-busy port down/up on an OF_13 switch(00:00:00:00:00:00:00:02)

    When: Bring port down on the switch

    Then: Forward and reverse ISLs between switches becomes 'FAILED'

    And: Port failure is logged in OpenTSDB

    When: Bring port up on the switch

    Then: Forward and reverse ISLs between switches becomes 'DISCOVERED'

    And: Port UP event is logged in OpenTSDB

    And: Cleanup: reset costs

SwitchMaintenance

  • Maintenance mode can be set/unset for a particular switch

    Given: An active switch

    When: Set maintenance mode for the switch

    Then: Maintenance flag for the switch is really set

    And: Maintenance flag for all ISLs going through the switch is set as well

    And: Cost for ISLs is not changed

    When: Unset maintenance mode from the switch

    Then: Maintenance flag for the switch is really unset

    And: Maintenance flag for all ISLs going through the switch is unset as well

    And: Cost for ISLs is not changed

  • Flows can be evacuated (rerouted) from a particular switch when setting maintenance mode for it

    Given: Two active not neighboring switches with two possible paths at least

    And: Create a couple of flows going through these switches

    When: Set maintenance mode without flows evacuation flag for some intermediate switch involved in flow paths

    Then: Flows are not evacuated (rerouted) and have the same paths

    When: Set maintenance mode again with flows evacuation flag for the same switch

    Then: Flows are evacuated (rerouted)

    And: Switch under maintenance is not involved in new flow paths

    And: Delete flows and unset maintenance mode

  • Link discovered by a switch under maintenance is marked as maintained

    Given: An active link

    And: Bring port down on the switch to fail the link

    And: Delete the link

    When: Set maintenance mode for the switch

    And: Bring port up to discover the deleted link

    Then: The link is discovered and marked as maintained

    And: Unset maintenance mode and reset costs

  • System is correctly handling actions performing on a maintained switch disconnected from the controller

    Given: An active switch under maintenance disconnected from the controller

    When: Try to get switch info

    Then: Detailed switch info is returned

    When: Try to get switch rules

    Then: An error is received (404 code)

    When: Try to create a flow, using the switch

    Then: An error is received (404 code)

    And: Connect the switch back to the controller and unset maintenance mode

SwitchFailures

This spec verifies different situations when Kilda switches suddenly disconnect from the controller. Note: For now it is only runnable on virtual env due to no ability to disconnect hardware switches

  • ISL is still able to properly fail even after switches were reconnected

    Given: A flow

    When: Two neighbouring switches of the flow go down simultaneously

    And: ISL between those switches looses connection

    And: Switches go back up

    Then: ISL still remains up right before discovery timeout should end

    And: ISL fails after discovery timeout

    And: The flow goes down OR changes path to avoid failed ISL after reroute timeout

    And: Cleanup: restore connection, remove the flow

  • System can handle situation when switch reconnects while flow is being created

    Given: Source and destination switches

    When: Start creating a flow between these switches

    And: One of the switches goes down without waiting for flow's UP status

    And: Goes back up in 2 seconds

    Then: The flow is UP and valid

    And: Rules are valid on the knocked out switch

    And: Remove the flow

  • System can handle situation when switch reconnects while flow is being rerouted

    Given: A flow with alternative paths available

    And: There is a more preferable alternative path

    When: Init reroute of the flow to a better path

    And: Immediately disconnect a switch on the new path

    And: Reconnect it back in a couple of seconds

    Then: The flow is UP and valid

    And: Rules are valid on the knocked out switch

    And: Remove the flow and delete link props

SwitchDelete

  • Unable to delete a nonexistent switch

    When: Try to delete a nonexistent switch

    Then: Get 404 NotFound error

  • Unable to delete an active switch

    Given: An active switch

    When: Try to delete the switch

    Then: Get 400 BadRequest error because the switch must be deactivated first

  • Unable to delete an inactive switch with active ISLs

    Given: An inactive switch with ISLs

    When: Try to delete the switch

    Then: Get 400 BadRequest error because the switch has ISLs

    And: Cleanup: activate the switch back

  • Unable to delete an inactive switch with inactive ISLs (ISL ports are down)

    Given: An inactive switch with ISLs

    When: Try to delete the switch

    Then: Get 400 BadRequest error because the switch has ISLs

    And: Cleanup: activate the switch back and reset costs

  • Unable to delete an inactive switch with a single-switch flow assigned

    Given: A flow going through a switch

    When: Deactivate the switch

    And: Try to delete the switch

    Then: Got 400 BadRequest error because the switch has the flow assigned

    And: Cleanup: activate the switch back and remove the flow

  • Unable to delete an inactive switch with a casual flow assigned

    Given: A flow going through a switch

    When: Deactivate the switch

    And: Try to delete the switch

    Then: Got 400 BadRequest error because the switch has the flow assigned

    And: Cleanup: activate the switch back and remove the flow

  • Able to delete an inactive switch without any ISLs

    Given: An inactive switch without any ISLs

    When: Try to delete the switch

    Then: The switch is actually deleted

    And: Cleanup: activate the switch back, restore ISLs and reset costs

  • Able to delete an active switch with active ISLs if using force delete

    Given: An active switch with active ISLs

    When: Try to force delete the switch

    Then: The switch is actually deleted

    And: Cleanup: restore the switch, ISLs and reset costs

SwitchActivation

  • Missing flow rules/meters are installed on a new switch before connecting to the controller

    Given: A switch with missing flow rules/meters and not connected to the controller

    When: Connect the switch to the controller

    Then: Missing flow rules/meters were synced during switch activation

    And: Cleanup: Delete the flow

  • Excess rules/meters are synced from a new switch before connecting to the controller

    Given: A switch with excess rules/meters and not connected to the controller

    When: Connect the switch to the controller

    Then: Excess meters/rules were synced during switch activation

  • New connected switch is properly discovered with related ISLs in a reasonable time

    Given: Disconnect one of the switches and remove it from DB. Pretend this switch never existed

    When: New switch connects

    Then: Switch is activated

    And: Related ISLs are discovered without antiflap

PortProperties

Some switch ports should not be used in network discovery process. By default all ports on all switches are available for discovery. Admin has ability to enable/disable discovery on a specific port on a switch using Northbound REST API.

This spec assumes that port discovery property is enabled for all available ports.

  • Able to manipulate port properties

    Given: A port with port properties

    When: Update port discovery property

    Then: Correct response is returned

    And: Port discovery property is really updated

    Cleanup: Restore init port discovery property on the port

  • Informative error is returned when trying to get/update port properties with non-existing switch

    When: Try to get port properties info for non-existing switch

    Then: Human readable error is returned

    When: Try to update port discovery property for non-existing switch

    Then: Human readable error is returned

  • Informative error is returned when trying to update port properties with non-existing port number

    When: Try to get port properties info for non-existing port

    Then: No error, default port propreties information is returned

    When: Try to update port discovery property for non-existing port

    Then: Human readable error is returned

  • System doesn't discover link when port discovery property is disabled

    Given: A deleted link

    When: Disable port discovery property on the src and dst switches

    And: Bring port up on the src switch

    Then: Link is not detected

    When: Deactivate/activate src switch

    Then: Link is still not detected

    When: Enable port discovery property on the src switch

    Then: Link is detected and status of one-way ISL is FAILED

    When: Enable port discovery property on the dst switch

    Then: Link status is changed to DISCOVERED

  • Link is stopped from being discovered after disabling port discovery property

    Given: An active link

    When: Disable port discovery property on the dst switch

    Then: One-way ISL status is changed to FAILED

    When: Enable port discovery property on the dst switch

    Then: Link state is changed to DISCOVERED

    Cleanup: Restore discovery port property on the port

PortHistory

Verify that port history is created for the port up/down actions.

  • Port history are created for the port down/up actions when link is direct

    Given: A link

    When: Execute port DOWN on the src switch

    Then: Port history is created on the src switch

    When: Execute port UP on the src switch

    Then: Port history is updated on the src switch

    And: Port history on the dst switch is not empty when link is direct

    And: Port history on the src switch is also available using default timeline

  • Port history are created for the port down/up actions when link is a-switch

    Given: A link

    When: Execute port DOWN on the src switch

    Then: Port history is created on the src switch

    When: Execute port UP on the src switch

    Then: Port history is updated on the src switch

    And: Port history on the dst switch is not empty when link is direct

    And: Port history on the src switch is also available using default timeline

  • Port history should not be returned in case timeline is incorrect (timeBefore > timeAfter)

    Given: A direct link with port history

    When: Get port history on the src switch for incorrect timeline

    Then: Port history is NOT returned

  • Port history should not be returned in case port/switch have never existed

    When: Try to get port history for incorrect port and switch

    Then: Port history is empty

  • Port history is available when switch is DEACTIVATED

    Given: A direct link

    When: Execute port DOWN/UP on the src switch

    And: Deactivate the src switch

    Then: Port history on the src switch is still available

    And: Cleanup: Revive the src switch

  • Port history is able to show ANTI_FLAP statistic

    Given: floodlightRoutePeriodicSync is disabled

    And: A port in a stable state

    When: Execute port DOWN on the port

    Then: Port history is created for that port

    When: Blink port to generate antiflap statistic

    Then: Antiflap statistic is available in port history

    And: Cleanup: revert system to original state

  • System shows antiflap statistic in the ANTI_FLAP_DEACTIVATED event when antiflap is deactivated before collecting ANTI_FLAP_PERIODIC_STATS

    Given: A direct link

    When: Execute port DOWN on the src switch for activating antiflap

    And: Generate antiflap statistic

    Then: Antiflap statistic is available in port history inside the ANTI_FLAP_DEACTIVATED event

    And: Cleanup: revert system to original state

PortAntiflap

Anti-flap feature is aimed to address the problem of blinking ports. Sometimes it happens that certain port on a switch begins to blink for a very short period of time. If it is a short-time behavior, then we don't want to init a port down event and reroute the flow. Otherwise we wait for 'antiflapWarmup' time and assign that blinking port a DOWN status. Then, when it comes back up it should remain in a stable 'up' state for at least 'antiflapCooldown' seconds to actually become UP for the rest of the system. Initially, port is considered 'flapping' if it changes status quicker than once in 'antiflap.min' seconds (port will change status from UP to DOWN only after 'antiflap.min' in case of a single-time change of status)

  • Flapping port is brought down only after antiflap warmup and stable port is brought up only after cooldown timeout

    Given: Switch, port and ISL related to that port

    When: ISL port begins to blink

    Then: Right before warmup timeout runs out the related ISL remains up

    And: After warmup timeout the related ISL goes down

    And: ISL remains down even after cooldown timeout

    When: Port stops flapping, ending in UP state

    Then: Right before cooldown timeout runs out the ISL remains down

    And: After cooldown timeout the ISL goes up

    Cleanup: ----

  • Port goes down in 'antiflap.min' seconds if no flapping occurs

    Given: Switch, port and ISL related to that port

    When: Port goes down

    Then: Related ISL goes down in about 'antiflapMin' seconds

    And: Cleanup: bring port up

  • System properly registers events order when port flaps incredibly fast (end with Up)

    When: Port blinks rapidly for longer than 'antiflapWarmup' seconds, ending in UP state

    Then: Related ISL is FAILED

    And: After the port cools down the ISL is discovered again

  • System properly registers events order when port flaps incredibly fast (end with Down)

    When: Port blinks rapidly for longer than 'antiflapWarmup' seconds, ending in DOWN state

    Then: Related ISL is FAILED

    And: ISL remains failed even after the port cools down

    And: cleanup: restore broken ISL

Meters

The test suite checks if traffic meters, including default, are set and deleted in a correct way. Note that many tests are bind to meter implementations of certain hardware manufacturers.

  • Able to delete a meter from a Centec switch

    Given: Select a Centec switch and retrieve default meters

    When: A flow is created and its meter is deleted

    Then: Delete operation should be successful

    And: Delete the flow

    And: Check if no excessive meters are installed on the switch

  • Able to delete a meter from a Noviflow switch

    Given: Select a Noviflow switch and retrieve default meters

    When: A flow is created and its meter is deleted

    Then: Delete operation should be successful

    And: Delete the flow

    And: Check if no excessive meters are installed on the switch

  • Able to delete a meter from a Noviflow(Wb5164) switch

    Given: Select a Noviflow(Wb5164) switch and retrieve default meters

    When: A flow is created and its meter is deleted

    Then: Delete operation should be successful

    And: Delete the flow

    And: Check if no excessive meters are installed on the switch

  • Able to delete a meter from a OVS switch

    Given: Select a OVS switch and retrieve default meters

    When: A flow is created and its meter is deleted

    Then: Delete operation should be successful

    And: Delete the flow

    And: Check if no excessive meters are installed on the switch

  • Unable to delete a meter with invalid ID=-1 on a Noviflow switch

    When: Try to delete meter with invalid ID

    Then: Got BadRequest because meter ID is invalid

  • Unable to delete a meter with invalid ID=0 on a Noviflow switch

    When: Try to delete meter with invalid ID

    Then: Got BadRequest because meter ID is invalid

  • Unable to delete a meter with invalid ID=-1 on a Centec switch

    When: Try to delete meter with invalid ID

    Then: Got BadRequest because meter ID is invalid

  • Unable to delete a meter with invalid ID=0 on a Centec switch

    When: Try to delete meter with invalid ID

    Then: Got BadRequest because meter ID is invalid

  • Unable to delete a meter with invalid ID=-1 on a Noviflow(Wb5164) switch

    When: Try to delete meter with invalid ID

    Then: Got BadRequest because meter ID is invalid

  • Unable to delete a meter with invalid ID=0 on a Noviflow(Wb5164) switch

    When: Try to delete meter with invalid ID

    Then: Got BadRequest because meter ID is invalid

  • Unable to delete a meter with invalid ID=-1 on a OVS switch

    When: Try to delete meter with invalid ID

    Then: Got BadRequest because meter ID is invalid

  • Unable to delete a meter with invalid ID=0 on a OVS switch

    When: Try to delete meter with invalid ID

    Then: Got BadRequest because meter ID is invalid

  • Meters are created/deleted when creating/deleting a single-switch flow with ignore_bandwidth=false on a Centec switch

    Given: A Centec switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow

    Then: New meters should appear after flow setup

    And: All new meters should have KBPS, BURST and STATS flags installed

    And: All new meters rate should be equal to flow's rate

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    When: Delete the flow

    Then: New meters should disappear from the switch

  • Meters are created/deleted when creating/deleting a single-switch flow with ignore_bandwidth=true on a Centec switch

    Given: A Centec switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow

    Then: New meters should appear after flow setup

    And: All new meters should have KBPS, BURST and STATS flags installed

    And: All new meters rate should be equal to flow's rate

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    When: Delete the flow

    Then: New meters should disappear from the switch

  • Meters are created/deleted when creating/deleting a single-switch flow with ignore_bandwidth=false on a Noviflow switch

    Given: A Noviflow switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow

    Then: New meters should appear after flow setup

    And: All new meters should have KBPS, BURST and STATS flags installed

    And: All new meters rate should be equal to flow's rate

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    When: Delete the flow

    Then: New meters should disappear from the switch

  • Meters are created/deleted when creating/deleting a single-switch flow with ignore_bandwidth=true on a Noviflow switch

    Given: A Noviflow switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow

    Then: New meters should appear after flow setup

    And: All new meters should have KBPS, BURST and STATS flags installed

    And: All new meters rate should be equal to flow's rate

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    When: Delete the flow

    Then: New meters should disappear from the switch

  • Meters are created/deleted when creating/deleting a single-switch flow with ignore_bandwidth=false on a Noviflow(Wb5164) switch

    Given: A Noviflow(Wb5164) switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow

    Then: New meters should appear after flow setup

    And: All new meters should have KBPS, BURST and STATS flags installed

    And: All new meters rate should be equal to flow's rate

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    When: Delete the flow

    Then: New meters should disappear from the switch

  • Meters are created/deleted when creating/deleting a single-switch flow with ignore_bandwidth=true on a Noviflow(Wb5164) switch

    Given: A Noviflow(Wb5164) switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow

    Then: New meters should appear after flow setup

    And: All new meters should have KBPS, BURST and STATS flags installed

    And: All new meters rate should be equal to flow's rate

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    When: Delete the flow

    Then: New meters should disappear from the switch

  • Meters are created/deleted when creating/deleting a single-switch flow with ignore_bandwidth=false on a OVS switch

    Given: A OVS switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow

    Then: New meters should appear after flow setup

    And: All new meters should have KBPS, BURST and STATS flags installed

    And: All new meters rate should be equal to flow's rate

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    When: Delete the flow

    Then: New meters should disappear from the switch

  • Meters are created/deleted when creating/deleting a single-switch flow with ignore_bandwidth=true on a OVS switch

    Given: A OVS switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow

    Then: New meters should appear after flow setup

    And: All new meters should have KBPS, BURST and STATS flags installed

    And: All new meters rate should be equal to flow's rate

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    When: Delete the flow

    Then: New meters should disappear from the switch

  • Meters are not created when creating a single-switch flow with maximum_bandwidth=0 on a Centec switch

    Given: A Centec switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow with maximum_bandwidth=0

    Then: Ony default meters should be present on the switch and new meters should not appear after flow setup

    And: Delete the flow

  • Meters are not created when creating a single-switch flow with maximum_bandwidth=0 on a Noviflow switch

    Given: A Noviflow switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow with maximum_bandwidth=0

    Then: Ony default meters should be present on the switch and new meters should not appear after flow setup

    And: Delete the flow

  • Meters are not created when creating a single-switch flow with maximum_bandwidth=0 on a Noviflow(Wb5164) switch

    Given: A Noviflow(Wb5164) switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow with maximum_bandwidth=0

    Then: Ony default meters should be present on the switch and new meters should not appear after flow setup

    And: Delete the flow

  • Meters are not created when creating a single-switch flow with maximum_bandwidth=0 on a OVS switch

    Given: A OVS switch with OpenFlow 1.3 support

    When: Get default meters from the switch

    And: Create a single-switch flow with maximum_bandwidth=0

    Then: Ony default meters should be present on the switch and new meters should not appear after flow setup

    And: Delete the flow

  • Source/destination switches have meters only in flow ingress rule and intermediate switches don't have meters in flow rules at all (Centec-Centec flow)

    When: Create a flow between given switches

    Then: The source and destination switches have only one meter in the flow's ingress rule

    And: The source and destination switches have no meters in the flow's egress rule

    And: Intermediate switches don't have meters in flow rules at all

    And: Delete the flow

  • Source/destination switches have meters only in flow ingress rule and intermediate switches don't have meters in flow rules at all (Noviflow-Noviflow flow)

    When: Create a flow between given switches

    Then: The source and destination switches have only one meter in the flow's ingress rule

    And: The source and destination switches have no meters in the flow's egress rule

    And: Intermediate switches don't have meters in flow rules at all

    And: Delete the flow

  • Source/destination switches have meters only in flow ingress rule and intermediate switches don't have meters in flow rules at all (Centec-Noviflow flow)

    When: Create a flow between given switches

    Then: The source and destination switches have only one meter in the flow's ingress rule

    And: The source and destination switches have no meters in the flow's egress rule

    And: Intermediate switches don't have meters in flow rules at all

    And: Delete the flow

  • Source/destination switches have meters only in flow ingress rule and intermediate switches don't have meters in flow rules at all (Noviflow_Wb5164-Noviflow_Wb5164 flow)

    When: Create a flow between given switches

    Then: The source and destination switches have only one meter in the flow's ingress rule

    And: The source and destination switches have no meters in the flow's egress rule

    And: Intermediate switches don't have meters in flow rules at all

    And: Delete the flow

  • Source/destination switches have meters only in flow ingress rule and intermediate switches don't have meters in flow rules at all (OVS-OVS flow)

    When: Create a flow between given switches

    Then: The source and destination switches have only one meter in the flow's ingress rule

    And: The source and destination switches have no meters in the flow's egress rule

    And: Intermediate switches don't have meters in flow rules at all

    And: Delete the flow

  • Meter burst size is correctly set on Noviflow switches for 150 flow rate

    Given: A single-switch flow with 150 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 150 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on Noviflow switches for 1000 flow rate

    Given: A single-switch flow with 1000 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 1000 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on Noviflow switches for 1024 flow rate

    Given: A single-switch flow with 1024 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 1024 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on Noviflow switches for 5120 flow rate

    Given: A single-switch flow with 5120 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 5120 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on Noviflow switches for 10240 flow rate

    Given: A single-switch flow with 10240 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 10240 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on Noviflow switches for 2480 flow rate

    Given: A single-switch flow with 2480 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 2480 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on Noviflow switches for 960000 flow rate

    Given: A single-switch flow with 960000 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 960000 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on OVS switches for 150 flow rate

    Given: A single-switch flow with 150 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 150 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on OVS switches for 1000 flow rate

    Given: A single-switch flow with 1000 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 1000 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on OVS switches for 1024 flow rate

    Given: A single-switch flow with 1024 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 1024 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on OVS switches for 5120 flow rate

    Given: A single-switch flow with 5120 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 5120 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on OVS switches for 10240 flow rate

    Given: A single-switch flow with 10240 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 10240 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on OVS switches for 2480 flow rate

    Given: A single-switch flow with 2480 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 2480 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • Meter burst size is correctly set on OVS switches for 960000 flow rate

    Given: A single-switch flow with 960000 kbps bandwidth is created on OpenFlow 1.3 compatible switch

    When: Update flow bandwidth to 960000 kbps

    Then: New meters should be installed on the switch

    And: New meters rate should be equal to flow bandwidth

    And: New meters burst size matches the expected value for given switch model

    And: Switch validation shows no discrepancies in meters

    And: Flow validation shows no discrepancies in meters

    Cleanup: Delete the flow

  • System allows to reset meter values to defaults without reinstalling rules for #data.description flow

    Given: Switches combination (#data.description)

    And: A flow with custom meter rate and burst, that differ from defaults

    When: Ask system to reset meters for the flow

    Then: Response contains correct info about new meter values

    And: Non-default meter rate and burst are actually changed to expected values both on src and dst switch

    And: Default meters are unchanged

    And: Switch rules are unchanged

    And: Cleanup: delete flow

  • Try to reset meters for unmetered flow

    Given: A flow with the 'bandwidth: 0' and 'ignoreBandwidth: true' fields

    When: Resetting meter burst and rate to default

    Then: Human readable error is returned

    Then: Delete the created flow

FlowRules

Verify how Kilda behaves with switch rules (either flow rules or default rules) under different circumstances: e.g. persisting rules on newly connected switch, installing default rules on new switch etc.

  • Pre-installed flow rules are not deleted from a new switch connected to the controller

    Given: A switch with proper flow rules installed (including default) and not connected to the controller

    When: Connect the switch to the controller

    Then: Previously installed rules are not deleted from the switch

    And: Cleanup: Delete the flow

  • Able to delete rules from a switch (delete-action=DROP_ALL)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch (delete-action=DROP_ALL_ADD_DEFAULTS)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch (delete-action=IGNORE_DEFAULTS)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch (delete-action=OVERWRITE_DEFAULTS)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch (delete-action=REMOVE_DEFAULTS)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch (delete-action=REMOVE_ADD_DEFAULTS)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch with multi table mode (delete-action=DROP_ALL)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch with multi table mode (delete-action=DROP_ALL_ADD_DEFAULTS)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch with multi table mode (delete-action=IGNORE_DEFAULTS)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch with multi table mode (delete-action=OVERWRITE_DEFAULTS)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch with multi table mode (delete-action=REMOVE_DEFAULTS)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete rules from a switch with multi table mode (delete-action=REMOVE_ADD_DEFAULTS)

    Given: A switch with some flow rules installed

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Delete the flow

    And: Install default rules if necessary

  • Able to delete switch rules by cookie

    Given: A switch with some flow rules installed

    When: Delete switch rules by cookie

    Then: The requested rules are really deleted

    And: Delete the flow

  • Able to delete switch rules by priority

    Given: A switch with some flow rules installed

    When: Delete switch rules by priority

    Then: The requested rules are really deleted

    And: Delete the flow

  • Attempt to delete switch rules by supplying non-existing cookie leaves all rules intact

    Given: A switch with some flow rules installed

    When: Delete switch rules by non-existing cookie

    Then: All rules are kept intact

    And: Delete the flow

  • Attempt to delete switch rules by supplying non-existing priority leaves all rules intact

    Given: A switch with some flow rules installed

    When: Delete switch rules by non-existing priority

    Then: All rules are kept intact

    And: Delete the flow

  • Able to delete switch rules by inPort

    Given: A switch with some flow rules installed

    When: Delete switch rules by inPort

    Then: The requested rules are really deleted

    And: Delete the flow

  • Able to delete switch rules by inVlan

    Given: A switch with some flow rules installed

    When: Delete switch rules by inVlan

    Then: The requested rules are really deleted

    And: Delete the flow

  • Able to delete switch rules by inPort and inVlan

    Given: A switch with some flow rules installed

    When: Delete switch rules by inPort and inVlan

    Then: The requested rules are really deleted

    And: Delete the flow

  • Able to delete switch rules by outPort

    Given: A switch with some flow rules installed

    When: Delete switch rules by outPort

    Then: The requested rules are really deleted

    And: Delete the flow

  • Attempt to delete switch rules by supplying non-existing inPort leaves all rules intact

    Given: A switch with some flow rules installed

    When: Delete switch rules by non-existing inPort

    Then: All rules are kept intact

    And: Delete the flow

  • Attempt to delete switch rules by supplying non-existing inVlan leaves all rules intact

    Given: A switch with some flow rules installed

    When: Delete switch rules by non-existing inVlan

    Then: All rules are kept intact

    And: Delete the flow

  • Attempt to delete switch rules by supplying non-existing inPort and inVlan leaves all rules intact

    Given: A switch with some flow rules installed

    When: Delete switch rules by non-existing inPort and inVlan

    Then: All rules are kept intact

    And: Delete the flow

  • Attempt to delete switch rules by supplying non-existing outPort leaves all rules intact

    Given: A switch with some flow rules installed

    When: Delete switch rules by non-existing outPort

    Then: All rules are kept intact

    And: Delete the flow

  • Able to validate and sync missing rules for a flow on terminating/transit switches

    Given: Two active not neighboring switches with the longest available path

    And: Create a transit-switch flow going through these switches

    And: Reproduce situation when switches have missing rules by deleting flow rules from them

    When: Synchronize rules on switches

    Then: The corresponding rules are installed on switches

    And: No missing rules were found after rules validation

    And: Cleanup: delete the flow and reset costs

  • Able to validate and sync missing rules for an unmetered flow on terminating/transit switches

    Given: Two active not neighboring switches with the longest available path

    And: Create a transit-switch flow going through these switches

    And: Reproduce situation when switches have missing rules by deleting flow rules from them

    When: Synchronize rules on switches

    Then: The corresponding rules are installed on switches

    And: No missing rules were found after rules validation

    And: Cleanup: delete the flow and reset costs

  • Unable to synchronize rules on a non-existent switch

    When: Try to synchronize rules on a non-existent switch

    Then: An error is received (404 code)

  • Unable to validate rules on a non-existent switch

    When: Try to validate rules on a non-existent switch

    Then: An error is received (404 code)

  • Able to synchronize rules for a flow with protected path

    Given: Two active not neighboring switches

    And: Create a flow with protected path

    And: Delete flow rules(for main and protected paths) on involved switches for creating missing rules

    When: Synchronize rules on switches

    Then: No missing rules were found after rules synchronization

    And: Delete the flow

  • Traffic counters in ingress rule are reset on flow rerouting

    Given: Two active neighboring switches and two possible flow paths at least

    And: Create a flow going through these switches

    When: Ping the flow

    Then: Operation is successful

    And: Traffic counters in ingress rule on source and destination switches represent packets movement

    When: Break the flow ISL (bring switch port down) to cause flow rerouting

    Then: The flow was rerouted after reroute timeout

    And: Traffic counters in ingress rule on source and destination switches are reset

    And: Revive the ISL back (bring switch port up), delete the flow and reset costs

  • Able to synchronize rules for a flow with VXLAN encapsulation

    Given: Two active not neighboring Noviflow switches

    And: Create a flow with vxlan encapsulation

    And: Reproduce situation when switches have missing rules by deleting flow rules from them

    When: Synchronize rules on switches

    Then: The corresponding rules are installed on switches

    And: Rules are synced correctly

    And: No missing rules were found after rules validation

    And: Cleanup: delete the flow and reset costs

DefaultRulesValidation

This test suite checks the switch validate and rule validate features regarding default rules. System should be able to detect missing, misconfigured, proper and excess default rules. The real-life usecase is that we should properly detect and distinguish 'duplicate' default rules with the same cookie but different match/priority/etc.

  • Switch and rule validation can properly detect default rules to 'proper' section (ofsw2)

    Given: Clean switch without customer flows

    Expect: Switch validation shows all expected default rules in 'proper' section

    And: Rule validation shows all expected default rules in 'proper' section

DefaultRules

  • Default rules are installed on an OF_13 switch(00:00:00:00:00:00:00:02)

    Expect: Default rules are installed on the switch

  • Default rules are installed when a new switch is connected

    Given: A switch with no rules installed and not connected to the controller

    When: Connect the switch to the controller

    Then: Default rules are installed on the switch

  • Able to install default rule on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_DROP)

    Given: A switch without any rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

    And: Install missing default rules

  • Able to install default rule on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_UNICAST)

    Given: A switch without any rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

    And: Install missing default rules

  • Able to install default rule on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_BFD_CATCH)

    Given: A switch without any rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

    And: Install missing default rules

  • Able to install default rule on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_ROUND_TRIP_LATENCY)

    Given: A switch without any rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

    And: Install missing default rules

  • Able to install default rule on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_UNICAST_VXLAN)

    Given: A switch without any rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

    And: Install missing default rules

  • Able to install default multitable rule on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_MULTITABLE_PRE_INGRESS_PASS_THROUGH)

    Given: A switch without rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

    And: Cleanup: Install missing default rules and restore switch properties

  • Able to install default multitable rule on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_MULTITABLE_INGRESS_DROP)

    Given: A switch without rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

    And: Cleanup: Install missing default rules and restore switch properties

  • Able to install default multitable rule on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_MULTITABLE_POST_INGRESS_DROP)

    Given: A switch without rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

    And: Cleanup: Install missing default rules and restore switch properties

  • Able to install default multitable rule on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_MULTITABLE_EGRESS_PASS_THROUGH)

    Given: A switch without rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

    And: Cleanup: Install missing default rules and restore switch properties

  • Able to install default multitable rule on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_MULTITABLE_TRANSIT_DROP)

    Given: A switch without rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

    And: Cleanup: Install missing default rules and restore switch properties

  • Able to install default rules on an OF_13 switch(00:00:00:00:00:00:00:02, install-action=INSTALL_DEFAULTS)

    Given: A switch without any rules

    When: Install rules on the switch

    Then: The corresponding rules are really installed

  • Able to delete default rule from an OF_13 switch (00:00:00:00:00:00:00:02, delete-action=REMOVE_DROP)

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Switch and rules validation shows that corresponding default rule is missing

    And: Install default rules back

  • Able to delete default rule from an OF_13 switch (00:00:00:00:00:00:00:02, delete-action=REMOVE_BROADCAST)

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Switch and rules validation shows that corresponding default rule is missing

    And: Install default rules back

  • Able to delete default rule from an OF_13 switch (00:00:00:00:00:00:00:02, delete-action=REMOVE_UNICAST)

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Switch and rules validation shows that corresponding default rule is missing

    And: Install default rules back

  • Able to delete default rule from an OF_13 switch (00:00:00:00:00:00:00:02, delete-action=REMOVE_VERIFICATION_LOOP)

    When: Delete rules from the switch

    Then: The corresponding rules are really deleted

    And: Switch and rules validation shows that corresponding default rule is missing

    And: Install default rules back

  • Able to delete default multitable rule from an OF_13 switch (00:00:00:00:00:00:00:02, delete-action=REMOVE_MULTITABLE_PRE_INGRESS_PASS_THROUGH)

    When: Delete rule from the switch

    Then: The corresponding rule is really deleted

    And: Switch and rules validation shows that corresponding default rule is missing

    And: Cleanup: Install default rules back

  • Able to delete default multitable rule from an OF_13 switch (00:00:00:00:00:00:00:02, delete-action=REMOVE_MULTITABLE_INGRESS_DROP)

    When: Delete rule from the switch

    Then: The corresponding rule is really deleted

    And: Switch and rules validation shows that corresponding default rule is missing

    And: Cleanup: Install default rules back

  • Able to delete default multitable rule from an OF_13 switch (00:00:00:00:00:00:00:02, delete-action=REMOVE_MULTITABLE_POST_INGRESS_DROP)

    When: Delete rule from the switch

    Then: The corresponding rule is really deleted

    And: Switch and rules validation shows that corresponding default rule is missing

    And: Cleanup: Install default rules back

  • Able to delete default multitable rule from an OF_13 switch (00:00:00:00:00:00:00:02, delete-action=REMOVE_MULTITABLE_EGRESS_PASS_THROUGH)

    When: Delete rule from the switch

    Then: The corresponding rule is really deleted

    And: Switch and rules validation shows that corresponding default rule is missing

    And: Cleanup: Install default rules back

  • Able to delete default multitable rule from an OF_13 switch (00:00:00:00:00:00:00:02, delete-action=REMOVE_MULTITABLE_TRANSIT_DROP)

    When: Delete rule from the switch

    Then: The corresponding rule is really deleted

    And: Switch and rules validation shows that corresponding default rule is missing

    And: Cleanup: Install default rules back

SimulateStats

In this spec we'll try to simulate certain stats entries by pushing them directly to Kafka and then checking that they are correctly processed and saved to Otsdb.

  • Flow stats with big values are properly being saved to stats db (noviflow boundaries)

    Given: A flow

    When: Flow stats information with noviflow-specific right boundary packet/byte counts is written to kafka

    Then: Corresponding entries appear in otsdb

    And: Remove flow

    Cleanup: ----

OpenTsdb

Verify that basic stats logging happens.

  • Stats are being logged for metric:kilda.switch.rx-bytes, tags:[switchid:SW0000000000000002]

    Expect: At least 1 result in the past 5 minutes

  • Stats are being logged for metric:kilda.switch.rx-bits, tags:[switchid:SW0000000000000002]

    Expect: At least 1 result in the past 5 minutes

  • Stats are being logged for metric:kilda.switch.rx-packets, tags:[switchid:SW0000000000000002]

    Expect: At least 1 result in the past 5 minutes

  • Stats are being logged for metric:kilda.switch.tx-bytes, tags:[switchid:SW0000000000000002]

    Expect: At least 1 result in the past 5 minutes

  • Stats are being logged for metric:kilda.switch.tx-bits, tags:[switchid:SW0000000000000002]

    Expect: At least 1 result in the past 5 minutes

  • Stats are being logged for metric:kilda.switch.tx-packets, tags:[switchid:SW0000000000000002]

    Expect: At least 1 result in the past 5 minutes

  • Stats are being logged for metric:kilda.isl.rtt, tags:[src_switch:SW0000000000000002]

    Expect: At least 1 result in the past 5 minutes

  • Stats are being logged for metric:kilda.isl.rtt, tags:[dst_switch:SW0000000000000002]

    Expect: At least 1 result in the past 5 minutes

  • Stats are being logged for metric:kilda.switch.flow.system.packets, tags:[cookieHex:0x8000000000000002]

    Expect: At least 1 result in the past 5 minutes

  • Stats are being logged for metric:kilda.switch.flow.system.bytes, tags:[cookieHex:0x8000000000000002]

    Expect: At least 1 result in the past 5 minutes

  • Stats are being logged for metric:kilda.switch.flow.system.bits, tags:[cookieHex:0x8000000000000002]

    Expect: At least 1 result in the past 5 minutes

MflStat

Now we have two FL instances: Management and Statistics.

  • FL Stats: collect statistics only from the switches.
  • FL Management: do the other work and can collect statistics as well when a switch doesn't connect to FL Stats.

  • System is able to collect stats from the statistic and management controllers

    Given: A flow

    When: Generate traffic on the given flow

    Then: Stat in openTSDB is created

    When: Set only management controller on the src switch

    And: Generate traffic on the given flow

    Then: Stat on the src switch should be collected because management controller is set

    When: Set only statistic controller on the src switch

    And: Generate traffic on the given flow

    Then: Stat on the src switch should be collected because statistic controller is set

    When: Disconnect the src switch from the management and statistic controllers

    And: Generate traffic on the given flow

    Then: Stat on the src switch should not be collected because it is disconnected from controllers

    When: Restore default controllers on the src switches

    Then: Old statistic should be collected

    And: Cleanup: Delete the flow

  • System is able to collect stats from the statistic and management controllers (v2)

    Given: A flow

    When: Generate traffic on the given flow

    Then: Stat in openTSDB is created

    When: Set only management controller on the src switch

    And: Generate traffic on the given flow

    Then: Stat on the src switch should be collected because management controller is set

    When: Set only statistic controller on the src switch

    And: Generate traffic on the given flow

    Then: Stat on the src switch should be collected because statistic controller is set

    When: Disconnect the src switch from the management and statistic controllers

    And: Generate traffic on the given flow

    Then: Stat on the src switch should not be collected because it is disconnected from controllers

    When: Restore default controllers on the src switches

    Then: Old statistic should be collected

    And: Cleanup: Delete the flow

FlowStat

Verify that statistic is collected for different type of flow

  • System is able to collect stats after intentional swapping flow path to protected

    Given: Two active neighboring switches with two diverse paths at least

    And: Flow with protected path

    When: Generate traffic on the given flow

    Then: Stats collects stat for main path cookies

    And: System collects stats for egress cookie of protected path with zero value

    When: Swap main and protected path

    And: Generate traffic on the flow

    Then: System collects stats for previous egress cookie of protected path with non zero value

    And: System doesn't collect stats anymore for previous ingress/egress cookie of main path

    And: Cleanup: revert system to original state

  • System collects stats when a protected flow was intentionally rerouted

    Given: Two active not neighboring switches with three diverse paths at least

    And: A flow with protected path

    When: Generate traffic on the given flow

    Then: Stats is not empty for main path cookies

    And: Stats is empty for protected path egress cookie

    When: Make the current and protected path less preferable than alternatives

    And: Init intentional reroute

    And: Generate traffic on the flow

    Then: Stats is not empty for new main path cookies

    And: Stats is empty for a new protected path egress cookie

    And: Cleanup: revert system to original state

  • System collects stats when a protected flow was automatically rerouted

    Given: Two active not neighboring switches with three not overlapping paths at least

    And: A flow with protected path

    When: Generate traffic on the given flow

    Then: System collects stats for main path cookies

    And: System collects stats for egress cookie of protected path with zero value

    When: Break ISL on the main path (bring port down) to init auto swap

    And: Generate traffic on the flow

    Then: System collects stats for previous egress cookie of protected path with non zero value

    And: System doesn't collect stats for previous main path cookies due to main path is broken

    And: Cleanup: revert system to original state

  • System collects stat when protected flow is DEGRADED

    Given: Two active not neighboring switches with two not overlapping paths at least

    And: A flow with protected path

    And: All alternative paths are unavailable (bring ports down on the source switch)

    When: Break ISL on a protected path (bring port down) for changing the flow state to DEGRADED

    And: Generate traffic on the given flow

    Then: System collects stats for a new main path cookies

    And: Cleanup: Restore topology, delete flows and reset costs

  • System collects stats when flow is pinned and unmetered

    Given: Two active not neighboring switches

    And: An unmetered flow

    When: Generate traffic on the given flow

    Then: System collects stats for egress/ingress cookies

    And: Cleanup: Delete the flow

StormHeavyLoad

  • Storm does not fail under heavy load of topo.disco topic

    When: Produce massive amount of messages into topo.disco topic

    Then: Still able to create and delete flows while Storm is swallowing the messages

    And: Topology is unchanged at the end

    Cleanup: ----

FloodlightKafkaConnection

  • System survives temporary connection outage between Floodlight and Kafka

    When: Controller loses connection to Kafka

    Then: Right before controller alive timeout switches are still active and links are discovered

    And: After controller alive timeout switches become inactive but links are still discovered

    When: System remains in this state for discovery timeout for ISLs

    Then: All links are still discovered

    When: Controller restores connection to Kafka

    Then: All links are discovered and switches become active

    And: System is able to successfully create a valid flow

    And: Cleanup: remove the flow

    Cleanup: ----

  • System can detect switch changes if they happen while Floodlight was disconnected after it reconnects

    When: Controller loses connection to kafka

    And: Switch port for certain ISL goes down

    And: Controller restores connection to kafka

    Then: System detects that certain port has been brought down and fails the related link

    And: Cleanup: restore the broken link

ContentionV2

This spec is aimed to test different race conditions and system behavior in a concurrent environment (using v2 APIs)

  • Parallel flow creation requests with the same name creates only 1 flow

    When: Create the same flow in parallel multiple times

    Then: One flow is created

    And: Other requests have received a decline

    Cleanup: Remove flow

  • Parallel flow crud requests properly allocate/deallocate bandwidth resources

    When: Create multiple flows on the same ISLs concurrently

    Then: Available bandwidth on related isls is reduced based on bandwidth of created flows

    When: Simultaneously remove all the flows

    Then: Available bandwidth on all related isls is reverted back to normal

  • Reroute can be simultaneously performed with sync rules requests and not cause any rule discrepancies

    Given: A flow with reroute potential

    When: Flow reroute is simultaneously requested together with sync rules requests for all related switches

    Then: Flow is Up and path has changed

    And: Related switches have no rule discrepancies

    And: Flow is healthy

    And: Cleanup: remove flow and reset costs

Contention

This spec is aimed to test different race conditions and system behavior in a concurrent environment.

  • Parallel flow creation requests with the same name creates only 1 flow

    When: Create the same flow in parallel multiple times

    Then: One flow is created

    And: Other requests have received a decline

    Cleanup: Remove flow

  • Parallel flow crud requests properly allocate/deallocate bandwidth resources

    When: Create multiple flows on the same ISLs concurrently

    Then: Available bandwidth on related isls is reduced based on bandwidth of created flows

    When: Simultaneously remove all the flows

    Then: Available bandwidth on all related isls is reverted back to normal

  • Reroute can be simultaneously performed with sync rules requests and not cause any rule discrepancies

    Given: A flow with reroute potential

    When: Flow reroute is simultaneously requested together with sync rules requests for all related switches

    Then: Flow is Up and path has changed

    And: Related switches have no rule discrepancies

    And: Flow is healthy

    And: Cleanup: remove flow and reset costs

Chaos

Test system behavior under different factors or events that randomly appear across the topology

  • Nothing breaks when multiple flows get rerouted due to randomly failing ISLs

    Given: Create multiple random flows

    When: Random ISLs 'blink' for some time

    Then: All flows remain up and valid

    And: Cleanup: remove flows and reset costs

Paths

  • Get paths between not neighboring switches

    Given: Two active not neighboring switches

    And: Create a flow to reduce available bandwidth on some path between these two switches

    When: Get paths between switches

    Then: Paths will be sorted by bandwidth (descending order) and then by latency (ascending order)

    And: Cleanup: delete flow

  • Unable to get paths between one switch

    Given: An active switch

    When: Try to get paths between one switch

    Then: Get 400 BadRequest error because request is invalid

  • Unable to get paths between nonexistent switch

    Given: An active switch

    When: Try to get paths between real switch and nonexistent switch

    Then: Get 404 NotFound error

MultitableSwitchRules

  • Switch migration to multi table mode and vice-versa leave no discrepancies in default rules

    Given: An active switch with disabled multi-table mode

    When: Update switch properties(multi_table: true)

    Then: Default rules are recreated in multi table mode

    And: Switch pass switch validation

    When: Update switch properties(multi_table: false)

    Then: Default rules are recreated in single table mode

    And: Switch pass switch validation

    Cleanup: Revert system to origin state

CheckLogging

This specification ensures that all logging facilities are up and running after Kilda deployment

  • Check Floodlight logging

    When: Retrieve Floodlight logs for last 5 minutes

    Then: There should be discovery messages

  • Check Northbound logging

    When: A non-existent switch is requested

    Then: An error is received (404 code)

    And: Northbound should log these actions within 30 seconds

  • Check Storm logging

    When: A non-existent flow is requested

    Then: An error is received (404 code)

    And: Storm should log these actions within 30 seconds

Link

  • Link (not BFD) status is properly changed when link connectivity is broken (not port down)

    Given: A link going through a-switch

    When: Remove a one-way flow on an a-switch for simulating lost connection(not port down)

    Then: Status of the link is not changed to FAILED until discoveryTimeout is exceeded

    And: Status of the link is changed to FAILED, actual status remains DISCOVERED for the alive direction

    When: Fail the other part of ISL

    Then: Status remains FAILED and actual status is changed to failed for both directions

    When: Add the removed flow rules for one direction

    Then: The link remains FAILED, but actual status for one direction is DISCOVERED

    When: Add the remaining missing rules on a-switch

    Then: Link status and actual status both changed to DISCOVERED in both directions

  • Get all flows (UP/DOWN) going through a particular link

    Given: Two active not neighboring switches

    And: Forward flow from source switch to destination switch

    And: Reverse flow from destination switch to source switch

    And: Forward flow from source switch to some 'internal' switch

    And: Reverse flow from 'internal' switch to source switch

    When: Get all flows going through the link from source switch to 'internal' switch

    Then: All created flows are in the response list

    When: Get all flows going through the link from some 'internal' switch to destination switch

    Then: Only the first and second flows are in the response list

    When: Bring all ports down on source switch that are involved in current and alternative paths

    Then: All flows go to 'Down' status

    When: Get all flows going through the link from source switch to 'internal' switch

    Then: All created flows are in the response list

    When: Get all flows going through the link from 'internal' switch to destination switch

    Then: Only the first and second flows are in the response list

    When: Bring ports up

    Then: All flows go to 'Up' status

    And: Delete all created flows and reset costs

  • ISL should immediately fail if the port went down while switch was disconnected

    When: A switch disconnects

    And: One of its ports goes down

    And: The switch reconnects back with a port being down

    Then: The related ISL immediately goes down

    When: The switch disconnects again

    And: The DOWN port is brought back to UP state

    And: The switch reconnects back with a port being up

    Then: The related ISL is discovered again

  • Unable to get flows for NOT existing link (src_switch doesn't exist)

    When: Get flows for NOT existing link

    Then: An error is received (404 code)

  • Unable to get flows for NOT existing link (src_port doesn't exist)

    When: Get flows for NOT existing link

    Then: An error is received (404 code)

  • Unable to get flows for NOT existing link (dst_switch doesn't exist)

    When: Get flows for NOT existing link

    Then: An error is received (404 code)

  • Unable to get flows for NOT existing link (dst_port doesn't exist)

    When: Get flows for NOT existing link

    Then: An error is received (404 code)

  • Unable to get flows with specifying invalid query parameters (src_port is invalid)

    When: Get flows with specifying invalid src_port

    Then: An error is received (400 code)

  • Unable to get flows with specifying invalid query parameters (dst_port is invalid)

    When: Get flows with specifying invalid dst_port

    Then: An error is received (400 code)

  • Unable to get flows with specifying invalid query parameters (src_port & dst_port is invalid)

    When: Get flows with specifying invalid src_port & dst_port

    Then: An error is received (400 code)

  • Unable to get flows without full specifying a particular link (src_switch is missing)

    When: Get flows without specifying src_switch

    Then: An error is received (400 code)

  • Unable to get flows without full specifying a particular link (src_port is missing)

    When: Get flows without specifying src_port

    Then: An error is received (400 code)

  • Unable to get flows without full specifying a particular link (dst_switch is missing)

    When: Get flows without specifying dst_switch

    Then: An error is received (400 code)

  • Unable to get flows without full specifying a particular link (dst_port is missing)

    When: Get flows without specifying dst_port

    Then: An error is received (400 code)

  • Unable to delete a nonexistent link

    Given: Parameters of nonexistent link

    When: Try to delete nonexistent link

    Then: Get 404 NotFound error

  • Unable to delete an active link

    Given: An active link

    When: Try to delete the link

    Then: Get 400 BadRequest error because the link is active

  • Able to delete an inactive direct link and re-discover it back afterwards

    Given: An inactive link

    When: Try to delete the link

    Then: The link is actually deleted

    When: Removed link becomes active again (port brought UP)

    Then: The link is rediscovered in both directions

  • Able to delete an inactive a-switch link and re-discover it back afterwards

    Given: An inactive link

    When: Try to delete the link

    Then: The link is actually deleted

    When: Removed link becomes active again (port brought UP)

    Then: The link is rediscovered in both directions

  • Reroute all flows going through a particular link

    Given: Two active not neighboring switches with two possible paths at least

    And: Make the first path more preferable than others by setting corresponding link props

    And: Create a couple of flows going through these switches

    And: Delete link props from all links of alternative paths to allow rerouting flows

    And: Make the current flows path not preferable

    When: Submit request for rerouting flows

    Then: Flows are rerouted

    And: Delete flows and delete link props

  • Unable to reroute flows with specifying NOT existing link (src_switch doesn't exist)

    When: Reroute flows with specifying NOT existing link

    Then: An error is received (404 code)

  • Unable to reroute flows with specifying NOT existing link (src_port doesn't exist)

    When: Reroute flows with specifying NOT existing link

    Then: An error is received (404 code)

  • Unable to reroute flows with specifying NOT existing link (dst_switch doesn't exist)

    When: Reroute flows with specifying NOT existing link

    Then: An error is received (404 code)

  • Unable to reroute flows with specifying NOT existing link (dst_port doesn't exist)

    When: Reroute flows with specifying NOT existing link

    Then: An error is received (404 code)

  • Unable to reroute flows with specifying invalid query parameters (src_port is invalid)

    When: Reroute flows with specifying invalid src_port

    Then: An error is received (400 code)

  • Unable to reroute flows with specifying invalid query parameters (dst_port is invalid)

    When: Reroute flows with specifying invalid dst_port

    Then: An error is received (400 code)

  • Unable to reroute flows with specifying invalid query parameters (src_port & dst_port is invalid)

    When: Reroute flows with specifying invalid src_port & dst_port

    Then: An error is received (400 code)

  • Unable to reroute flows without full specifying a particular link (src_switch is missing)

    When: Reroute flows without specifying src_switch

    Then: An error is received (400 code)

  • Unable to reroute flows without full specifying a particular link (src_port is missing)

    When: Reroute flows without specifying src_port

    Then: An error is received (400 code)

  • Unable to reroute flows without full specifying a particular link (dst_switch is missing)

    When: Reroute flows without specifying dst_switch

    Then: An error is received (400 code)

  • Unable to reroute flows without full specifying a particular link (dst_port is missing)

    When: Reroute flows without specifying dst_port

    Then: An error is received (400 code)

  • Get links with specifying query parameters [0]

    When: Get links with specifying query parameters

    Then: The corresponding list of links is returned

  • Get links with specifying query parameters [1]

    When: Get links with specifying query parameters

    Then: The corresponding list of links is returned

  • Get links with specifying query parameters [2]

    When: Get links with specifying query parameters

    Then: The corresponding list of links is returned

  • Get links with specifying query parameters [3]

    When: Get links with specifying query parameters

    Then: The corresponding list of links is returned

  • Get links with specifying query parameters [4]

    When: Get links with specifying query parameters

    Then: The corresponding list of links is returned

  • Get links with specifying NOT existing query parameters (src_switch doesn't exist)

    When: Get links with specifying NOT existing query parameters

    Then: An empty list of links is returned

  • Get links with specifying NOT existing query parameters (src_port doesn't exist)

    When: Get links with specifying NOT existing query parameters

    Then: An empty list of links is returned

  • Get links with specifying NOT existing query parameters (dst_switch doesn't exist)

    When: Get links with specifying NOT existing query parameters

    Then: An empty list of links is returned

  • Get links with specifying NOT existing query parameters (dst_port doesn't exist)

    When: Get links with specifying NOT existing query parameters

    Then: An empty list of links is returned

  • Unable to get links with specifying invalid query parameters (src_port is invalid)

    When: Get links with specifying invalid src_port

    Then: An error is received (400 code)

  • Unable to get links with specifying invalid query parameters (dst_port is invalid)

    When: Get links with specifying invalid dst_port

    Then: An error is received (400 code)

  • Unable to get links with specifying invalid query parameters (src_port & dst_port is invalid)

    When: Get links with specifying invalid src_port & dst_port

    Then: An error is received (400 code)

  • ISL is able to properly fail when both src and dst switches suddenly disconnect

    Given: An active ISL

    When: Source and destination switches of the ISL suddenly disconnect

    Then: ISL gets failed after discovery timeout

    And: Restore broken switches and revive ISL

  • Able to update max bandwidth for a link

    Given: An active ISL

    When: Create a flow going through this ISL

    And: Update max bandwidth for the link

    Then: Max bandwidth is really updated and available bandwidth is also recalculated

    And: The corresponding link props are created

    When: Update max bandwidth to a value lesser than max bandwidth of the created flow

    Then: An error is received (400 code)

    When: Update max bandwidth to the value equal to max bandwidth of the created flow

    Then: Max bandwidth is really updated and available bandwidth is also recalculated

    And: Link props are also updated

    When: Update max bandwidth to the initial value

    Then: Max bandwidth is really updated and available bandwidth is also recalculated

    And: Link props are also updated

    When: Delete link props

    Then: Max bandwidth and available bandwidth are not changed

    And: Delete the flow

  • Unable to update max bandwidth with specifying invalid query parameters (src_port is invalid)

    When: Update max bandwidth with specifying invalid src_port

    Then: An error is received (400 code)

  • Unable to update max bandwidth with specifying invalid query parameters (dst_port is invalid)

    When: Update max bandwidth with specifying invalid dst_port

    Then: An error is received (400 code)

  • Unable to update max bandwidth with specifying invalid query parameters (src_port & dst_port is invalid)

    When: Update max bandwidth with specifying invalid src_port & dst_port

    Then: An error is received (400 code)

  • Unable to update max bandwidth without full specifying a particular link (src_switch is missing)

    When: Update max bandwidth without specifying src_switch

    Then: An error is received (400 code)

  • Unable to update max bandwidth without full specifying a particular link (src_port is missing)

    When: Update max bandwidth without specifying src_port

    Then: An error is received (400 code)

  • Unable to update max bandwidth without full specifying a particular link (dst_switch is missing)

    When: Update max bandwidth without specifying dst_switch

    Then: An error is received (400 code)

  • Unable to update max bandwidth without full specifying a particular link (dst_port is missing)

    When: Update max bandwidth without specifying dst_port

    Then: An error is received (400 code)

LinkProperties

  • Empty list is returned if there are no properties

    Expect: Get link properties is empty for no properties

  • Link props are created with empty values when sending not a valid link props key

    When: Send link property request with invalid character

    Then: Response states that operation succeeded

    And: Link props are created but with empty values

    And: Delete created link props

  • Unable to create link property with invalid switchId format

    When: Try creating link property with invalid switchId format

    Then: Response with error is received

  • Unable to create link property with non-numeric value for cost

    When: Try creating link property with non-numeric values

    Then: Response with error is received

  • Unable to create link property with non-numeric value for max_bandwidth

    When: Try creating link property with non-numeric values

    Then: Response with error is received

  • Searching for link props with src switch and src port (single result)

    When: Get link properties with search query

    Then: Returned props list match expected

  • Searching for link props with src switch and src port (multiple results)

    When: Get link properties with search query

    Then: Returned props list match expected

  • Searching for link props with dst switch and dst port (single result)

    When: Get link properties with search query

    Then: Returned props list match expected

  • Searching for link props with dst switch and dst port (multiple results)

    When: Get link properties with search query

    Then: Returned props list match expected

  • Searching for link props with src switch and src port (no results)

    When: Get link properties with search query

    Then: Returned props list match expected

  • Searching for link props with dst switch and dst port (no results)

    When: Get link properties with search query

    Then: Returned props list match expected

  • Searching for link props with src and dst switch (different switches)

    When: Get link properties with search query

    Then: Returned props list match expected

  • Searching for link props with src and dst switch (same switch)

    When: Get link properties with search query

    Then: Returned props list match expected

  • Searching for link props with src and dst port

    When: Get link properties with search query

    Then: Returned props list match expected

  • Searching for link props with full match

    When: Get link properties with search query

    Then: Returned props list match expected

  • Updating cost and max bandwidth via link props actually updates cost and max bandwidth on ISLs

    Given: An active ISL

    When: Create link props of ISL to update cost and max bandwidth on the forward and reverse directions

    Then: Cost on forward and reverse ISLs is really updated

    And: Max bandwidth on forward and reverse ISLs is really updated as well

    When: Update link props on the forward direction of ISL to update cost one more time

    Then: Forward and reverse directions of the link props are really updated

    And: Cost on forward and reverse ISLs is really updated

    When: Delete link props

    Then: Cost on ISLs is changed to the default value

    And: Max bandwidth on forward and reverse ISLs is changed to the initial value as well

  • Newly discovered link gets cost and max bandwidth from link props

    Given: An active ISL

    And: Bring port down on the source switch

    And: Delete the link

    And: Set cost and max bandwidth on the deleted link via link props

    When: Bring port up on the source switch to discover the deleted link

    Then: The discovered link gets cost from link props

    And: The discovered link gets max bandwidth from link props as well

    And: Delete link props

LinkMaintenance

  • Maintenance mode can be set/unset for a particular link

    Given: An active link

    When: Set maintenance mode for the link

    Then: Maintenance flag for forward and reverse ISLs is really set

    And: Cost for ISLs is not changed

    When: Unset maintenance mode from the link

    Then: Maintenance flag for forward and reverse ISLs is really unset

    And: Cost for ISLs is changed to the default value

  • Flows can be evacuated (rerouted) from a particular link when setting maintenance mode for it

    Given: Two active not neighboring switches with two possible paths at least

    And: Create a couple of flows going through these switches

    When: Set maintenance mode without flows evacuation flag for the first link involved in flow paths

    Then: Flows are not evacuated (rerouted) and have the same paths

    When: Set maintenance mode again with flows evacuation flag for the same link

    Then: Flows are evacuated (rerouted)

    And: Link under maintenance is not involved in new flow paths

    And: Delete flows and unset maintenance mode

  • Flows are rerouted to a path with link under maintenance when there are no other paths available

    Given: Two active not neighboring switches with two possible paths at least

    And: Create a couple of flows going through these switches

    And: Make only one alternative path available for both flows

    And: Set maintenance mode for the first link involved in alternative path

    When: Force flows to reroute by bringing port down on the source switch

    Then: Flows are rerouted to alternative path with link under maintenance

    And: Restore topology, delete flows, unset maintenance mode and reset costs

IslReplug

Verify scenarios around replugging ISLs between different switches/ports.

  • ISL status changes to MOVED when replugging ISL into another switch

    Given: A connected a-switch link

    And: A non-connected a-switch link

    When: Replug one end of the connected link to the not connected one

    Then: Replugged ISL status changes to MOVED

    And: New ISL becomes DISCOVERED

    When: Replug the link back where it was

    Then: Original ISL becomes DISCOVERED again

    And: Replugged ISL status changes to MOVED

    When: Remove the MOVED ISL

    Then: Moved ISL is removed

    And: The src and dst switches of the isl pass switch validation

  • New potential self-loop ISL (the same port on the same switch) is not getting discovered when replugging

    Given: A connected a-switch link

    When: Replug one end of the link into 'itself'

    Then: Replugged ISL status changes to FAILED

    And: The potential self-loop ISL is not present in the list of ISLs

    When: Replug the link back where it was

    Then: Original ISL becomes DISCOVERED again

  • New potential self-loop ISL (different ports on the same switch) is not getting discovered when replugging

    Given: Two a-switch links on a single switch

    When: Plug an ISL between two ports on the same switch

    Then: The potential self-loop ISL is not present in the list of ISLs (wait for discovery interval)

    And: Self-loop rule packet counter is incremented and logged in otsdb

    And: Unplug the link how it was before

IslMinPortSpeed

Minimal port speed value is chosen for ISL capacity. Sometimes an ISL have different port speed on its edges. In that case, we need to set ISL capacity and all bandwidth parameters according to minimal speed value. Eg. 10G on one side, and 1G on another side, the ISL should have a 1G capacity.

  • System sets min port speed for isl capacity

    Given: Two ports with different port speed

    When: Replug one end of the connected link to the destination switch(isl.srcSwitchId -> newDst.srcSwitchId)

    Then: Max bandwidth of new ISL is equal to the minimal port speed

    And: Cleanup: Replug the link back and delete the moved ISL

IslCost

  • Cost of a direct ISL is not increased due to bringing port down on a switch

    Given: An active ISL with created link props

    When: Bring port down on the source switch

    Then: ISL status becomes 'FAILED'

    And: Cost of forward and reverse ISLs after bringing port down is increased

    And: Cost on corresponding link props is not increased as well

    And: Bring port up on the source switch and reset costs

    Cleanup: ----

  • Cost of an a-switch ISL is not increased due to bringing port down on a switch

    Given: An active ISL with created link props

    When: Bring port down on the source switch

    Then: ISL status becomes 'FAILED'

    And: Cost of forward and reverse ISLs after bringing port down is increased

    And: Cost on corresponding link props is not increased as well

    And: Bring port up on the source switch and reset costs

    Cleanup: ----

  • ISL cost is NOT increased due to failing connection between switches (not port down)

    Given: ISL going through a-switch with link props created

    When: Remove a-switch rules to break link between switches

    Then: Status of forward and reverse ISLs becomes 'FAILED'

    And: Cost of forward and reverse ISLs after failing connection is not increased

    And: Cost on link props is not increased as well

    And: Add a-switch rules to restore connection

    Cleanup: ----

  • ISL cost is NOT increased due to deactivating/activating switch

    Given: A switch

    And: Cost of related ISLs

    When: Deactivate the switch

    And: Activate the switch

    Then: ISL cost is not increased

    Cleanup: ----

  • System takes isl time_unstable info into account while creating a flow

    Given: Two active neighboring switches with two parallel links

    And: Two possible paths for further manipulation with them

    And: All alternative paths are unavailable (bring ports down on the srcSwitch)

    And: First path is unstable (due to bringing port down/up)

    And: Cost of stable path more preferable than the cost of unstable path

    When: Create a flow

    Then: Flow is created on the stable path(secondPath)

    When: Mark first path as stable(update the 'time_unstable' field in db)

    And: Reroute the flow

    Then: Flow is rerouted

    And: Restore topology, delete the flow and reset costs

LogicalPort

This test suite checks the CRUD actions on a logical port. Logical ports are defined by associating a single physical port to them to define Bidirectional Forwarding Detection(BFD) ports or by associating a list of physical ports to them to create Link Aggregation Groups (LAG) or a list of BFD ports to them to create a LAG for fast-failover for BFD sessions.

NOTE: The GRPC implementation supports the LAG type only and it is set by default.

Log

This test suite checks that we are able to enable/disable:

  • log messages;
  • OF log messages. And checks that we are able to do the CRUD actions with the remote log server configuration.

License

NoviWare software license file is used to activate the basic and licensed features. If you want to test full functionality then you have to perform the following manual tests: - set license by 'file name'. File name is a file with license on switch. - set license by 'license data'

GrpcCommon

VxlanFlowV2

This spec checks basic functionality(simple flow(rules, ping, traffic, validate), pinned flow, flow with protected path, default flow) for a flow with VXLAN encapsulation.

NOTE: A flow with the 'VXLAN' encapsulation is supported on a Noviflow switches. So, flow can be created on a Noviflow(src/dst/transit) switches only.

  • Able to CRUD a pinned flow with 'VXLAN' encapsulation

    When: Create a flow

    Then: Flow is created

    When: Update the flow (pinned=false)

    Then: The pinned option is disabled

    And: Cleanup: Delete the flow

  • Able to CRUD a vxlan flow with protected path

    Given: Two active Noviflow switches with two available path at least

    When: Create a flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    When: Update flow: disable protected path(allocateProtectedPath=false)

    Then: Protected path is disabled

    And: Rules for protected path are deleted

    And: And rules for main path are recreacted

    And: Validation of flow must be successful

    And: Cleanup: Delete the flow and reset costs

  • System allows tagged traffic via default flow(0<->0) with 'VXLAN' encapsulation

    Given: Noviflow switches

    When: Create a default flow

    Then: System allows tagged traffic on the default flow

    And: Cleanup: Delete the flow

  • Unable to create a VXLAN flow when src and dst switches do not support it

    Given: Src and dst switches do not support VXLAN

    When: Try to create a VXLAN flow

    Then: Human readable error is returned

    When: Create a VLAN flow

    And: Try updated its encap type to VXLAN

    Then: Human readable error is returned

    Cleanup: ----

  • System selects longer path if shorter path does not support required encapsulation type

    Given: Shortest path transit switch does not support VXLAN and alt paths with VXLAN are available

    When: Create a VXLAN flow

    Then: Flow is built through vxlan-enabled path, even though it is not the shortest

    Cleanup: Restore all the changed sw props and remove the flow

  • Unable to create a vxlan flow when dst switch does not support it

    Given: Noviflow and non-Noviflow switches

    When: Try to create a flow

    Then: Human readable error is returned

VxlanFlow

This spec checks basic functionality(simple flow(rules, ping, traffic, validate), pinned flow, flow with protected path, default flow) for a flow with VXLAN encapsulation.

NOTE: A flow with the 'VXLAN' encapsulation is supported on a Noviflow switches. So, flow can be created on a Noviflow(src/dst/transit) switches only.

  • Able to CRUD a metered pinned flow with 'VXLAN' encapsulation

    When: Create a flow

    Then: Flow is created

    When: Update the flow (pinned=false)

    Then: The pinned option is disabled

    And: Cleanup: Delete the flow

  • Able to CRUD a vxlan flow with protected path

    Given: Two active Noviflow switches with two available path at least

    When: Create a flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    When: Update flow: disable protected path(allocateProtectedPath=false)

    Then: Protected path is disabled

    And: Rules for protected path are deleted

    And: Rules for protected path are deleted

    And: Rules for main path are recreated

    And: Validation of flow must be successful

    And: Cleanup: Delete the flow and reset costs

  • System allows tagged traffic via default flow(0<->0) with 'VXLAN' encapsulation

    Given: Noviflow switches

    When: Create a default flow

    Then: System allows tagged traffic on the default flow

    And: Cleanup: Delete the flow

  • System doesn't allow to create a flow with 'VXLAN' encapsulation on a non-noviflow switches

    Given: ----

    When: Try to create a flow

    Then: Human readable error is returned

  • System doesn't allow to create a vxlan flow when transit switch is not Noviflow

    Given: ----

    When: Try to create a flow

    Then: Human readable error is returned

    And: Cleanup: Reset costs

  • System doesn't allow to create a vxlan flow when dst switch is not Noviflow

    Given: Noviflow and non-Noviflow switches

    When: Try to create a flow

    Then: Human readable error is returned

  • System doesn't allow to enable a flow with 'VXLAN' encapsulation on a non-noviflow switch

    Given: A flow with 'TRANSIT_VLAN' encapsulation

    When: Try to change the encapsulation type to VXLAN

    Then: Human readable error is returned

    And: Cleanup: Delete the flow

ThrottlingReroute

This test verifies that we do not perform a reroute as soon as we receive a reroute request (we talk only about automatic reroutes here; manual reroutes are still performed instantly). Instead, system waits for 'reroute.delay' seconds and if no new reroute requests are issued, it performs ONE reroute for each requested flowId. If ANY new reroute is issued during 'reroute.delay' the timer is refreshed. System should stop refreshing the timer if 'reroute.hardtimeout' is reached and perform all the queued reroutes (unique for each flowId).

  • Reroute is not performed while new reroutes are being issued

    Given: Multiple flows that can be rerouted independently (use short unique paths)

    When: All flows break one by one

    Then: The oldest broken flow is still not rerouted before rerouteDelay run out

    And: The oldest broken flow is rerouted when the rerouteDelay runs out

    And: The rest of the flows are rerouted too

    And: cleanup: restore broken paths and delete flows

  • Reroute is performed after hard timeout even though new reroutes are still being issued

    Given: Multiple flows that can be rerouted independently (use short unique paths)

    When: All flows begin to continuously reroute in a loop

    Then: Right until hard timeout should run out no flow reroutes happen

    And: Flows should start to reroute after hard timeout, eventhough reroutes are still being triggered

    And: cleanup: delete flows

    Cleanup: revive all paths

  • Flow can be safely deleted while it is in the reroute window waiting for reroute

    Given: A flow

    When: Init a flow reroute by breaking current path

    And: Immediately remove the flow before reroute delay runs out and flow is actually rerouted

    Then: The flow is not present in NB

    And: Related switches have no excess rules

    And: cleanup: restore broken path

SwapEndpoint

  • Able to swap endpoints(no vlan vs vlan on the same port on src switch)

    Given: Some flows in the system according to preconditions

    When: Try to swap endpoints with null

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any rule discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints(same port, swap vlans on dst switch + third idle novlan flow on that port)

    Given: Some flows in the system according to preconditions

    When: Try to swap endpoints with null

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any rule discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints(vlan on src1 <-> vlan on dst2, same port numbers)

    Given: Some flows in the system according to preconditions

    When: Try to swap endpoints with null

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any rule discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints(port on dst1 <-> port on src2, vlans are equal)

    Given: Some flows in the system according to preconditions

    When: Try to swap endpoints with null

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any rule discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints(switch on src1 <-> switch on dst2, other params random)

    Given: Some flows in the system according to preconditions

    When: Try to swap endpoints with null

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any rule discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints(both endpoints swap, same switches)

    Given: Some flows in the system according to preconditions

    When: Try to swap endpoints with null

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any rule discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints(endpoints src1 <-> dst2, same switches)

    Given: Some flows in the system according to preconditions

    When: Try to swap endpoints with null

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any rule discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints(endpoints src1 <-> src2, different src switches, same dst)

    Given: Some flows in the system according to preconditions

    When: Try to swap endpoints with null

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any rule discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap vlans (src1 <-> dst2, dst1 <-> src2) for two flows with the same source and different destination switches

    Given: Two flows with the same source and different destination switches

    When: Try to swap vlans for flows

    Then: Vlans are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap ports (src1 <-> dst2, dst1 <-> src2) for two flows with the same source and different destination switches

    Given: Two flows with the same source and different destination switches

    When: Try to swap ports for flows

    Then: Ports are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap switches (src1 <-> dst2, dst1 <-> src2) for two flows with the same source and different destination switches

    Given: Two flows with the same source and different destination switches

    When: Try to swap switches for flows

    Then: Switches are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (src1 <-> src2) for two flows with the same source and different destination switches

    Given: Two flows with the same source and different destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (dst1 <-> dst2) for two flows with the same source and different destination switches

    Given: Two flows with the same source and different destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (src1 <-> dst2) for two flows with the same source and different destination switches

    Given: Two flows with the same source and different destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (dst1 <-> src2) for two flows with the same source and different destination switches

    Given: Two flows with the same source and different destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap vlans (src1 <-> dst2, dst1 <-> src2) for two flows with different source and the same destination switches

    Given: Two flows with different source and the same destination switches

    When: Try to swap vlans for flows

    Then: Vlans are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap ports (src1 <-> dst2, dst1 <-> src2) for two flows with different source and the same destination switches

    Given: Two flows with different source and the same destination switches

    When: Try to swap ports for flows

    Then: Ports are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap switches (src1 <-> dst2, dst1 <-> src2) for two flows with different source and the same destination switches

    Given: Two flows with different source and the same destination switches

    When: Try to swap switches for flows

    Then: Switches are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap vlans (src1 <-> dst2, dst1 <-> src2) for two flows with different source and destination switches

    Given: Two flows with different source and destination switches

    When: Try to swap vlans for flows

    Then: Vlans are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap ports (src1 <-> dst2, dst1 <-> src2) for two flows with different source and destination switches

    Given: Two flows with different source and destination switches

    When: Try to swap ports for flows

    Then: Ports are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap switches (src1 <-> dst2, dst1 <-> src2) for two flows with different source and destination switches

    Given: Two flows with different source and destination switches

    When: Try to swap switches for flows

    Then: Switches are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (src1 <-> src2) for two flows with different source and destination switches

    Given: Two flows with different source and destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (dst1 <-> dst2) for two flows with different source and destination switches

    Given: Two flows with different source and destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (src1 <-> dst2) for two flows with different source and destination switches

    Given: Two flows with different source and destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (dst1 <-> src2) for two flows with different source and destination switches

    Given: Two flows with different source and destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Unable to swap endpoints for existing flow and non-existing flow

    Given: An active flow

    When: Try to swap endpoints for existing flow and non-existing flow

    Then: An error is received (404 code)

    And: Delete the flow

  • Unable to swap ports and vlans for two flows (the same ports and vlans on src switch)

    Given: Three active flows

    When: Try to swap ports and vlans for two flows

    Then: An error is received (409 code)

    And: Delete flows

  • Unable to swap ports and vlans for two flows (the same ports and vlans on dst switch)

    Given: Three active flows

    When: Try to swap ports and vlans for two flows

    Then: An error is received (409 code)

    And: Delete flows

  • Unable to swap vlans for two flows (the same vlans on the same port on src switch)

    Given: Three active flows

    When: Try to swap vlans for two flows

    Then: An error is received (409 code)

    And: Delete flows

  • Unable to swap vlans for two flows (the same vlans on the same port on dst switch)

    Given: Three active flows

    When: Try to swap vlans for two flows

    Then: An error is received (409 code)

    And: Delete flows

  • Unable to swap ports for two flows (no vlans, both flows are on the same port on src switch)

    Given: Three active flows

    When: Try to swap ports for two flows

    Then: An error is received (409 code)

    And: Delete flows

  • Unable to swap ports for two flows (no vlans, both flows are on the same port on dst switch)

    Given: Three active flows

    When: Try to swap ports for two flows

    Then: An error is received (409 code)

    And: Delete flows

  • Unable to swap endpoints for two flows (the same src endpoint for flows)

    Given: Two active flows

    When: Try to swap endpoints for two flows

    Then: An error is received (400 code)

    And: Delete flows

  • Unable to swap endpoints for two flows (the same dst endpoint for flows)

    Given: Two active flows

    When: Try to swap endpoints for two flows

    Then: An error is received (400 code)

    And: Delete flows

  • Unable to swap ports for two flows (port is occupied by ISL on src switch)

    Given: Two active flows

    When: Try to swap ports for two flows

    Then: An error is received (400 code)

    And: Delete flows

  • Unable to swap ports for two flows (port is occupied by ISL on dst switch)

    Given: Two active flows

    When: Try to swap ports for two flows

    Then: An error is received (400 code)

    And: Delete flows

  • Able to swap endpoints for two flows when all bandwidth on ISL is consumed

    Given: Create two flows with different source and the same destination switches

    And: Update the first flow so that it consumes all bandwidth on the link

    And: Break all alternative paths for the first flow

    And: Update max bandwidth for the second flow's link so that it is equal to max bandwidth of the first flow

    And: Break all alternative paths for the second flow

    When: Try to swap endpoints for two flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Restore topology and delete flows

  • Unable to swap endpoints for two flows when not enough bandwidth on ISL

    Given: Create two flows with different source and the same destination switches

    And: Update the first flow so that it consumes all bandwidth on the link

    And: Break all alternative paths for the first flow

    And: Update max bandwidth for the second flow's link so that it is not enough bandwidth for the first flow

    And: Break all alternative paths for the second flow

    When: Try to swap endpoints for two flows

    Then: An error is received (400 code)

    And: Restore topology and delete flows

  • Able to swap endpoints for two flows when not enough bandwidth on ISL and ignore_bandwidth=true

    Given: Create two flows with different source and the same destination switches

    And: Update the first flow so that it consumes all bandwidth on the link

    And: Break all alternative paths for the first flow

    And: Update max bandwidth for the second flow's link so that it is not enough bandwidth for the first flow

    And: Break all alternative paths for the second flow

    When: Try to swap endpoints for two flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Restore topology and delete flows

  • Unable to swap endpoints for two flows when one of them is inactive

    Given: Create two flows with different source and the same destination switches

    And: Break all paths for the first flow

    When: Try to swap endpoints for two flows

    Then: An error is received (400 code)

    And: Restore topology and delete flows

  • Able to swap endpoints (src1 <-> src2) for two protected flows

    Given: Two protected flows with different source and destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (dst1 <-> dst2) for two protected flows

    Given: Two protected flows with different source and destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (src1 <-> dst2) for two protected flows

    Given: Two protected flows with different source and destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • Able to swap endpoints (dst1 <-> src2) for two protected flows

    Given: Two protected flows with different source and destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: Delete flows

  • A protected flow with swapped endpoint allows traffic on main and protected paths

    Given: Two protected flows with different source and destination switches

    When: Try to swap endpoints for flows

    Then: Endpoints are successfully swapped

    And: Flows validation doesn't show any discrepancies

    And: Switch validation doesn't show any missing/excess rules and meters

    And: The first flow allows traffic on the main path

    And: The first flow allows traffic on the protected path

    And: Delete flows

ProtectedPathV2

Protected path - it is pre-calculated, reserved, and deployed (except ingress rule), so we can switch traffic fast.

  • flow object is extended with a boolean parameter 'allocate_protected_path' with values false(default)
  • /flows/{flow-id}/path returns 'main_path' + 'protected_path'.

System can start to use protected path in two case:

  • main path is down;
  • we send the 'swap' request for a flow with protected path('/v1/flows/{flow_id}/swap')

A flow has the status degraded in case when the main path is up and the protected path is down.

Main and protected paths can't use the same link.

  • Able to create a flow with protected path when maximumBandwidth=1000, vlan=3378

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    And: Cleanup: delete the flow

  • Able to create a flow with protected path when maximumBandwidth=0, vlan=3378

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    And: Cleanup: delete the flow

  • Able to create a flow with protected path when maximumBandwidth=1000, vlan=0

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    And: Cleanup: delete the flow

  • Able to create a flow with protected path when maximumBandwidth=0, vlan=0

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    And: Cleanup: delete the flow

  • Able to enable/disable protected path on a flow

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow without protected path

    Then: Flow is created without protected path

    When: Update flow: enable protected path(allocateProtectedPath=true)

    Then: Protected path is enabled

    And: Rules for main and protected paths are created

    When: Update flow: disable protected path(allocateProtectedPath=false)

    Then: Protected path is disabled

    And: Rules for protected path are deleted

    And: Cleanup: delete the flow

  • Unable to create a single switch flow with protected path

    Given: A switch

    When: Create single switch flow

    Then: Human readable error is returned

  • Unable to update a single switch flow to enable protected path

    Given: A switch

    And: A flow without protected path

    When: Update flow: enable protected path

    Then: Human readable error is returned

    And: Cleanup: revert system to original state

  • System is able to switch a metered flow to protected path

    Given: Two active not neighboring switches with three diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Current path is not equal to protected path

    And: Bandwidth is reserved for protected path on involved ISLs

    When: Break ISL on the main path (bring port down) to init auto swap

    Then: Flow is switched to protected path

    When: Restore port status

    Then: Path of the flow is not changed

    And: Cleanup: revert system to original state

  • System is able to switch an unmetered flow to protected path

    Given: Two active not neighboring switches with three diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Current path is not equal to protected path

    And: Bandwidth is reserved for protected path on involved ISLs

    When: Break ISL on the main path (bring port down) to init auto swap

    Then: Flow is switched to protected path

    When: Restore port status

    Then: Path of the flow is not changed

    And: Cleanup: revert system to original state

  • System reroutes a metered flow to more preferable path and ignores protected path when reroute is intentional

    Given: Two active neighboring switches with four diverse paths at least

    And: A flow with protected path

    When: Make the current and protected path less preferable than alternatives

    And: Init intentional reroute

    Then: Flow is rerouted

    And: Path is not changed to protected path

    And: Cleanup: revert system to original state

  • System reroutes an unmetered flow to more preferable path and ignores protected path when reroute is intentional

    Given: Two active neighboring switches with four diverse paths at least

    And: A flow with protected path

    When: Make the current and protected path less preferable than alternatives

    And: Init intentional reroute

    Then: Flow is rerouted

    And: Path is not changed to protected path

    And: Cleanup: revert system to original state

  • System is able to switch a metered flow to protected path and ignores more preferable path when reroute is automatical

    Given: Two active not neighboring switches with three diverse paths at least

    And: A flow with protected path

    When: Make the current and protected path less preferable than alternatives

    And: Break ISL on the main path (bring port down) to init auto swap

    Then: Flow is switched to protected path

    When: Restore port status

    Then: Path of the flow is not changed

    And: Cleanup: revert system to original state

  • System is able to switch an unmetered flow to protected path and ignores more preferable path when reroute is automatical

    Given: Two active not neighboring switches with three diverse paths at least

    And: A flow with protected path

    When: Make the current and protected path less preferable than alternatives

    And: Break ISL on the main path (bring port down) to init auto swap

    Then: Flow is switched to protected path

    When: Restore port status

    Then: Path of the flow is not changed

    And: Cleanup: revert system to original state

  • A flow with protected path does not get rerouted if already on the best path

    Given: Two active neighboring switches and a flow

    When: Init intentional reroute

    Then: Flow is not rerouted

    And: Cleanup: revert system to original state

  • Unable to create a flow with protected path when there is not enough bandwidth

    Given: Two active neighboring switches

    And: Update all ISLs which can be used by protected path

    When: Create flow with protected path

    Then: Human readable error is returned

    And: Cleanup: restore available bandwidth

  • Unable to update a flow to enable protected path when there is not enough bandwidth

    Given: Two active neighboring switches

    And: Update all ISLs which can be used by protected path

    When: Create flow without protected path

    Then: Flow is created without protected path

    When: Update flow: enable protected path

    Then: Human readable error is returned

    And: Cleanup: delete the flow and restore available bandwidth

  • Able to create a flow with protected path when there is not enough bandwidth and ignoreBandwidth=true

    Given: Two active neighboring switches

    And: Update all ISLs which can be used by protected path

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: One transit vlan is created for main and protected paths

    And: Cleanup: delete the flow and restore available bandwidth

  • System is able to recalculate protected path when protected path is broken

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create a flow with protected path

    Then: Flow is created with protected path

    When: Break ISL on the protected path (bring port down) to init the recalculate procedure

    Then: Protected path is recalculated

    And: Current path is not changed

    And: Bandwidth is reserved for new protected path on involved ISLs

    And: Reservation is deleted on the broken ISL

    When: Restore port status

    Then: Path is not recalculated again

    And: Cleanup: revert system to original state

  • Unable to create a metered flow with protected path if all alternative paths are unavailable

    Given: Two active neighboring switches without alt paths

    When: Try to create a new flow with protected path

    Then: Human readable error is returned

    And: Restore topology, delete flows and reset costs

  • Unable to create an unmetered flow with protected path if all alternative paths are unavailable

    Given: Two active neighboring switches without alt paths

    When: Try to create a new flow with protected path

    Then: Human readable error is returned

    And: Restore topology, delete flows and reset costs

  • Unable to update a metered flow to enable protected path if all alternative paths are unavailable

    Given: Two active neighboring switches with two not overlapping paths at least

    And: A flow without protected path

    And: All alternative paths are unavailable (bring ports down on the source switch)

    When: Update flow: enable protected path(allocateProtectedPath=true)

    Then: Human readable error is returned

    And: Restore topology, delete flows and reset costs

  • Unable to update an unmetered flow to enable protected path if all alternative paths are unavailable

    Given: Two active neighboring switches with two not overlapping paths at least

    And: A flow without protected path

    And: All alternative paths are unavailable (bring ports down on the source switch)

    When: Update flow: enable protected path(allocateProtectedPath=true)

    Then: Human readable error is returned

    And: Restore topology, delete flows and reset costs

  • Able to swap main and protected paths manually

    Given: A simple flow

    And: Cookies are created by flow

    When: Update flow: enable protected path(allocateProtectedPath=true)

    Then: Protected path is enabled

    And: Rules for main and protected paths are created

    And: No rule discrepancies on every switch of the flow on the main path

    And: No rule discrepancies on every switch of the flow on the protected path)

    And: The flow allows traffic(on the main path)

    When: Swap flow paths

    Then: Flow paths are swapped

    And: New meter is created on the src and dst switches

    And: Rules are updated

    And: Old meter is deleted on the src and dst switches

    And: Transit switches store the correct info about rules and meters

    And: No rule discrepancies when doing flow validation

    And: All rules for main and protected paths are updated

    And: No rule discrepancies on every switch of the flow on the main path

    And: No rule discrepancies on every switch of the flow on the protected path)

    And: The flow allows traffic(on the protected path)

    And: Cleanup: revert system to original state

  • Unable to perform the 'swap' request for a flow without protected path

    Given: Two active neighboring switches

    And: A flow without protected path

    When: Try to swap paths for flow that doesn't have protected path

    Then: Human readable error is returned

    And: Cleanup: revert system to original state

  • Unable to swap paths for a non-existent flow

    When: Try to swap path on a non-existent flow

    Then: Human readable error is returned

  • Unable to swap paths for an inactive flow

    Given: Two active neighboring switches with two not overlapping paths at least

    And: A flow with protected path

    And: All alternative paths are unavailable (bring ports down on the source switch)

    When: Break ISL on a protected path (bring port down) for changing the flow state to DEGRADED

    Then: Flow state is changed to DEGRADED

    When: Break ISL on the main path (bring port down) for changing the flow state to DOWN

    Then: Flow state is changed to DOWN

    When: Try to swap paths when main/protected paths are not available

    Then: Human readable error is returned

    When: Restore ISL for the main path only

    Then: Flow state is still DEGRADED

    When: Try to swap paths when the main path is available and the protected path is not available

    Then: Human readable error is returned

    When: Restore ISL for the protected path

    Then: Flow state is changed to UP

    And: Cleanup: Restore topology, delete flows and reset costs

  • System doesn't reroute main flow path when protected path is broken and new alt path is available(altPath is more preferable than mainPath)

    Given: Two active neighboring switches with three diverse paths at least

    And: A flow with protected path

    And: All alternative paths are unavailable (bring ports down on the source switch)

    And: ISL on a protected path is broken(bring port down) for changing the flow state to DEGRADED

    When: Make the current path less preferable than alternative path

    And: Make alternative path available(bring port up on the source switch)

    Then: Flow state is changed to UP

    And: Protected path is recalculated only

    And: Cleanup: Restore topology, delete flow and reset costs

  • A metered flow is DEGRADED when protected and alternative paths are not available

    Given: Two active neighboring switches with two not overlapping paths at least

    And: A flow with protected path

    When: All alternative paths are unavailable (bring ports down on the source switch and on the protected path)

    Then: Flow status is DEGRADED

    When: Update flow: disable protected path(allocateProtectedPath=false)

    Then: Flow status is UP

    And: Cleanup: Restore topology, delete flow and reset costs

  • An unmetered flow is DEGRADED when protected and alternative paths are not available

    Given: Two active neighboring switches with two not overlapping paths at least

    And: A flow with protected path

    When: All alternative paths are unavailable (bring ports down on the source switch and on the protected path)

    Then: Flow status is DEGRADED

    When: Update flow: disable protected path(allocateProtectedPath=false)

    Then: Flow status is UP

    And: Cleanup: Restore topology, delete flow and reset costs

  • System doesn't allow to enable the pinned flag on a protected flow

    Given: A protected flow

    When: Update flow: enable the pinned flag(pinned=true)

    Then: Human readable error is returned

    And: Cleanup: Delete the flow

  • System reuses current protected path when can't find new non overlapping protected path while intentional rerouting

    Given: Two active neighboring switches with three diverse paths

    And: A flow with protected path

    When: Make the current and protected path less preferable than alternatives

    And: Init intentional reroute

    Then: Flow should be rerouted

    And: Flow main path should be rerouted to a new path and ignore protected path

    And: Flow protected path shouldn't be rerouted due to lack of non overlapping path

    And: Flow and both its paths are UP

    And: Cleanup: revert system to original state

ProtectedPath

Protected path - it is pre-calculated, reserved, and deployed (except ingress rule), so we can switch traffic fast.

  • flow object is extended with a boolean parameter 'allocate_protected_path' with values false(default)
  • /flows/{flow-id}/path returns 'main_path' + 'protected_path'.

System can start to use protected path in two case:

  • main path is down;
  • we send the 'swap' request for a flow with protected path('/v1/flows/{flow_id}/swap')

A flow has the status degraded in case when the main path is up and the protected path is down.

Main and protected paths can't use the same link.

  • Able to create a flow with protected path when maximumBandwidth=1000, vlan=3378

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    And: Cleanup: delete the flow

  • Able to create a flow with protected path when maximumBandwidth=0, vlan=3378

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    And: Cleanup: delete the flow

  • Able to create a flow with protected path when maximumBandwidth=1000, vlan=0

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    And: Cleanup: delete the flow

  • Able to create a flow with protected path when maximumBandwidth=0, vlan=0

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    And: Cleanup: delete the flow

  • Able to enable/disable protected path on a flow

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow without protected path

    Then: Flow is created without protected path

    When: Update flow: enable protected path(allocateProtectedPath=true)

    Then: Protected path is enabled

    And: Rules for main and protected paths are created

    When: Update flow: disable protected path(allocateProtectedPath=false)

    Then: Protected path is disabled

    And: Rules for protected path are deleted

    And: Cleanup: delete the flow

  • Unable to create a single switch flow with protected path

    Given: A switch

    When: Create single switch flow

    Then: Human readable error is returned

  • Unable to update a single switch flow to enable protected path

    Given: A switch

    And: A flow without protected path

    When: Update flow: enable protected path

    Then: Human readable error is returned

    And: Cleanup: revert system to original state

  • System is able to switch a metered flow to protected path

    Given: Two active not neighboring switches with three diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Current path is not equal to protected path

    And: Bandwidth is reserved for protected path on involved ISLs

    When: Break ISL on the main path (bring port down) to init auto swap

    Then: Flow is switched to protected path

    When: Restore port status

    Then: Path of the flow is not changed

    And: Cleanup: revert system to original state

  • System is able to switch an unmetered flow to protected path

    Given: Two active not neighboring switches with three diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Current path is not equal to protected path

    And: Bandwidth is reserved for protected path on involved ISLs

    When: Break ISL on the main path (bring port down) to init auto swap

    Then: Flow is switched to protected path

    When: Restore port status

    Then: Path of the flow is not changed

    And: Cleanup: revert system to original state

  • System reroutes a metered flow to more preferable path and ignores protected path when reroute is intentional

    Given: Two active neighboring switches with four diverse paths at least

    And: A flow with protected path

    When: Make the current and protected path less preferable than alternatives

    And: Init intentional reroute

    Then: Flow is rerouted

    And: Path is not changed to protected path

    And: Cleanup: revert system to original state

  • System reroutes an unmetered flow to more preferable path and ignores protected path when reroute is intentional

    Given: Two active neighboring switches with four diverse paths at least

    And: A flow with protected path

    When: Make the current and protected path less preferable than alternatives

    And: Init intentional reroute

    Then: Flow is rerouted

    And: Path is not changed to protected path

    And: Cleanup: revert system to original state

  • System is able to switch a metered flow to protected path and ignores more preferable path when reroute is automatical

    Given: Two active not neighboring switches with three diverse paths at least

    And: A flow with protected path

    When: Make the current and protected path less preferable than alternatives

    And: Break ISL on the main path (bring port down) to init auto swap

    Then: Flow is switched to protected path

    When: Restore port status

    Then: Path of the flow is not changed

    And: Cleanup: revert system to original state

  • System is able to switch an unmetered flow to protected path and ignores more preferable path when reroute is automatical

    Given: Two active not neighboring switches with three diverse paths at least

    And: A flow with protected path

    When: Make the current and protected path less preferable than alternatives

    And: Break ISL on the main path (bring port down) to init auto swap

    Then: Flow is switched to protected path

    When: Restore port status

    Then: Path of the flow is not changed

    And: Cleanup: revert system to original state

  • A flow with protected path does not get rerouted if already on the best path

    Given: Two active neighboring switches and a flow

    When: Init intentional reroute

    Then: Flow is not rerouted

    And: Cleanup: revert system to original state

  • Unable to create a flow with protected path when there is not enough bandwidth

    Given: Two active neighboring switches

    And: Update all ISLs which can be used by protected path

    When: Create flow with protected path

    Then: Human readable error is returned

    And: Cleanup: restore available bandwidth

  • Unable to update a flow to enable protected path when there is not enough bandwidth

    Given: Two active neighboring switches

    And: Update all ISLs which can be used by protected path

    When: Create flow without protected path

    Then: Flow is created without protected path

    When: Update flow: enable protected path

    Then: Human readable error is returned

    And: Cleanup: delete the flow and restore available bandwidth

  • Able to create a flow with protected path when there is not enough bandwidth and ignoreBandwidth=true

    Given: Two active neighboring switches

    And: Update all ISLs which can be used by protected path

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: One transit vlan is created for main and protected paths

    And: Cleanup: delete the flow and restore available bandwidth

  • System is able to recalculate protected path when protected path is broken

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create a flow with protected path

    Then: Flow is created with protected path

    When: Break ISL on the protected path (bring port down) to init the recalculate procedure

    Then: Protected path is recalculated

    And: Current path is not changed

    And: Bandwidth is reserved for new protected path on involved ISLs

    And: Reservation is deleted on the broken ISL

    When: Restore port status

    Then: Path is not recalculated again

    And: Cleanup: revert system to original state

  • Unable to create a metered flow with protected path if all alternative paths are unavailable

    Given: Two active neighboring switches without alt paths

    When: Try to create a new flow with protected path

    Then: Human readable error is returned

    And: Restore topology, delete flows and reset costs

  • Unable to create an unmetered flow with protected path if all alternative paths are unavailable

    Given: Two active neighboring switches without alt paths

    When: Try to create a new flow with protected path

    Then: Human readable error is returned

    And: Restore topology, delete flows and reset costs

  • Unable to update a metered flow to enable protected path if all alternative paths are unavailable

    Given: Two active neighboring switches with two not overlapping paths at least

    And: A flow without protected path

    And: All alternative paths are unavailable (bring ports down on the source switch)

    When: Update flow: enable protected path(allocateProtectedPath=true)

    Then: Human readable error is returned

    And: Restore topology, delete flows and reset costs

  • Unable to update an unmetered flow to enable protected path if all alternative paths are unavailable

    Given: Two active neighboring switches with two not overlapping paths at least

    And: A flow without protected path

    And: All alternative paths are unavailable (bring ports down on the source switch)

    When: Update flow: enable protected path(allocateProtectedPath=true)

    Then: Human readable error is returned

    And: Restore topology, delete flows and reset costs

  • Able to swap main and protected paths manually

    Given: A simple flow

    And: Cookies are created by flow

    When: Update flow: enable protected path(allocateProtectedPath=true)

    Then: Protected path is enabled

    And: Rules for main and protected paths are created

    And: No rule discrepancies on every switch of the flow on the main path

    And: No rule discrepancies on every switch of the flow on the protected path)

    And: The flow allows traffic(on the main path)

    When: Swap flow paths

    Then: Flow paths are swapped

    And: New meter is created on the src and dst switches

    And: Rules are updated

    And: Old meter is deleted on the src and dst switches

    And: Transit switches store the correct info about rules and meters

    And: No rule discrepancies when doing flow validation

    And: All rules for main and protected paths are updated

    And: No rule discrepancies on every switch of the flow on the main path

    And: No rule discrepancies on every switch of the flow on the protected path)

    And: The flow allows traffic(on the protected path)

    And: Cleanup: revert system to original state

  • Unable to perform the 'swap' request for a flow without protected path

    Given: Two active neighboring switches

    And: A flow without protected path

    When: Try to swap paths for flow that doesn't have protected path

    Then: Human readable error is returned

    And: Cleanup: revert system to original state

  • Unable to swap paths for a non-existent flow

    When: Try to swap path on a non-existent flow

    Then: Human readable error is returned

  • Unable to swap paths for an inactive flow

    Given: Two active neighboring switches with two not overlapping paths at least

    And: A flow with protected path

    And: All alternative paths are unavailable (bring ports down on the source switch)

    When: Break ISL on a protected path (bring port down) for changing the flow state to DEGRADED

    Then: Flow state is changed to DEGRADED

    When: Break ISL on the main path (bring port down) for changing the flow state to DOWN

    Then: Flow state is changed to DOWN

    When: Try to swap paths when main/protected paths are not available

    Then: Human readable error is returned

    When: Restore ISL for the main path only

    Then: Flow state is still DEGRADED

    When: Try to swap paths when the main path is available and the protected path is not available

    Then: Human readable error is returned

    When: Restore ISL for the protected path

    Then: Flow state is changed to UP

    And: Cleanup: Restore topology, delete flows and reset costs

  • System doesn't reroute main flow path when protected path is broken and new alt path is available(altPath is more preferable than mainPath)

    Given: Two active neighboring switches with three diverse paths at least

    And: A flow with protected path

    And: All alternative paths are unavailable (bring ports down on the source switch)

    And: ISL on a protected path is broken(bring port down) for changing the flow state to DEGRADED

    When: Make the current path less preferable than alternative path

    And: Make alternative path available(bring port up on the source switch)

    Then: Flow state is changed to UP

    And: Protected path is recalculated only

    And: Cleanup: Restore topology, delete flow and reset costs

  • A metered flow is DEGRADED when protected and alternative paths are not available

    Given: Two active neighboring switches with two not overlapping paths at least

    And: A flow with protected path

    When: All alternative paths are unavailable (bring ports down on the source switch and on the protected path)

    Then: Flow status is DEGRADED

    When: Update flow: disable protected path(allocateProtectedPath=false)

    Then: Flow status is UP

    And: Cleanup: Restore topology, delete flow and reset costs

  • An unmetered flow is DEGRADED when protected and alternative paths are not available

    Given: Two active neighboring switches with two not overlapping paths at least

    And: A flow with protected path

    When: All alternative paths are unavailable (bring ports down on the source switch and on the protected path)

    Then: Flow status is DEGRADED

    When: Update flow: disable protected path(allocateProtectedPath=false)

    Then: Flow status is UP

    And: Cleanup: Restore topology, delete flow and reset costs

  • System doesn't allow to enable the pinned flag on a protected flow

    Given: A protected flow

    When: Update flow: enable the pinned flag(pinned=true)

    Then: Human readable error is returned

    And: Cleanup: Delete the flow

  • System reuses current protected path when can't find new non overlapping protected path while intentional rerouting

    Given: Two active neighboring switches with three diverse paths

    And: A flow with protected path

    When: Make the current and protected path less preferable than alternatives

    And: Init intentional reroute

    Then: Flow should be rerouted

    And: Flow main path should be rerouted to a new path and ignore protected path

    And: Flow protected path shouldn't be rerouted due to lack of non overlapping path

    And: Flow and both its paths are UP

    And: Cleanup: revert system to original state

PinnedFlowV2

A new flag of flow that indicates that flow shouldn't be rerouted in case of auto-reroute.

  • In case of isl down such flow should be marked as DOWN.
  • On Isl up event such flow shouldn't be re-routed as well. Instead kilda should verify that it's path is online and mark flow as UP.

  • System doesn't reroute(automatically) pinned flow when flow path is partially broken

    Given: A pinned flow going through a long not preferable path

    When: Make alt path more preferable than current path

    And: Init reroute by bringing current path's ISL down one by one

    Then: Flow is not rerouted and marked as DOWN when the first ISL is broken

    And: Rules and meters are not changed

    When: The broken ISLs are restored one by one

    Then: Flow is marked as UP when the last ISL is restored

    And: Cleanup: revert system to original state

  • System is able to reroute(intentionally) pinned flow

    Given: A pinned flow with alt path available

    When: Make another path more preferable

    And: Init reroute(manually)

    Then: Flow is rerouted

    And: Cleanup: revert system to original state

  • System doesn't allow to create pinned and protected flow at the same time

    When: Try to create pinned and protected flow

    Then: Human readable error is returned

  • System doesn't allow to enable the protected path flag on a pinned flow

    Given: A pinned flow

    When: Update flow: enable the allocateProtectedPath flag(allocateProtectedPath=true)

    Then: Human readable error is returned

    And: Cleanup: Delete the flow

PinnedFlow

A new flag of flow that indicates that flow shouldn't be rerouted in case of auto-reroute.

  • In case of isl down such flow should be marked as DOWN.
  • On Isl up event such flow shouldn't be re-routed as well. Instead kilda should verify that it's path is online and mark flow as UP.

  • System doesn't reroute(automatically) pinned flow when flow path is partially broken

    Given: A pinned flow going through a long not preferable path

    When: Make alt path more preferable than current path

    And: Init reroute by bringing current path's ISL down one by one

    Then: Flow is not rerouted and marked as DOWN when the first ISL is broken

    And: Rules and meters are not changed

    When: The broken ISLs are restored one by one

    Then: Flow is marked as UP when the last ISL is restored

    And: Cleanup: revert system to original state

  • System is able to reroute(intentionally) pinned flow

    Given: A pinned flow with alt path available

    When: Make another path more preferable

    And: Init reroute(manually)

    Then: Flow is rerouted

    And: Cleanup: revert system to original state

  • System doesn't allow to create pinned and protected flow at the same time

    When: Try to create pinned and protected flow

    Then: Human readable error is returned

  • System doesn't allow to enable the protected path flag on a pinned flow

    Given: A pinned flow

    When: Update flow: enable the allocateProtectedPath flag(allocateProtectedPath=true)

    Then: Human readable error is returned

    And: Cleanup: Delete the flow

MultiReroute

  • Simultaneous reroute of multiple flows should not oversubscribe any ISLs

    Given: Two flows on the same path, with alt paths available

    When: Make another path more preferable

    And: Make preferable path's ISL to have not enough bandwidth to handle 2 flows together, but enough for 1 flow

    And: Init simultaneous reroute of both flows by bringing current path's ISL down

    Then: Both flows change their paths (or go Down if no path)

    And: 'Thin' ISL is not oversubscribed

    And: Only one flow goes through a preferred path

    And: Cleanup: revert system to original state

IntentionalRerouteV2

Verify that on-demand reroute operations are performed accurately.

  • Not able to reroute to a path with not enough bandwidth available

    Given: A flow with alternate paths available

    When: Make the current path less preferable than alternatives

    And: Make all alternative paths to have not enough bandwidth to handle the flow

    And: Init a reroute to a more preferable path

    Then: The flow is NOT rerouted because of not enough bandwidth on alternative paths

    And: Remove the flow, restore the bandwidth on ISLs, reset costs

  • Able to reroute to a better path if it has enough bandwidth

    Given: A flow with alternate paths available

    When: Make one of the alternative paths to be the most preferable among all others

    And: Make the future path to have exact bandwidth to handle the flow

    And: Init a reroute of the flow

    Then: The flow is successfully rerouted and goes through the preferable path

    And: 'Thin' ISL has 0 available bandwidth left

    And: Remove the flow, restore bandwidths on ISLs, reset costs

  • Intentional flow reroute is not causing any packet loss

    Given: An unmetered flow going through a long not preferable path(reroute potential)

    When: Start traffic examination

    And: While traffic flow is active, request a flow reroute

    Then: Flow is rerouted

    And: Traffic examination result shows acceptable packet loss percentage

    And: Remove the flow

  • Able to reroute to a path with not enough bandwidth available in case ignoreBandwidth=true

    Given: A flow with alternate paths available

    When: Make the current path less preferable than alternatives

    And: Make all alternative paths to have not enough bandwidth to handle the flow

    And: Init a reroute to a more preferable path

    Then: The flow is rerouted because ignoreBandwidth=true

    And: Available bandwidth was not changed while rerouting due to ignoreBandwidth=true

    And: Remove the flow, restore the bandwidth on ISLs, reset costs

  • Intentional flow reroute with VXLAN encapsulation is not causing any packet loss

    Given: A vxlan flow

    When: Start traffic examination

    And: While traffic flow is active, request a flow reroute

    Then: Flow is rerouted

    And: Traffic examination result shows acceptable packet loss percentage

    And: Remove the flow

IntentionalReroute

Verify that on-demand reroute operations are performed accurately.

  • Not able to reroute to a path with not enough bandwidth available

    Given: A flow with alternate paths available

    When: Make the current path less preferable than alternatives

    And: Make all alternative paths to have not enough bandwidth to handle the flow

    And: Init a reroute to a more preferable path

    Then: The flow is NOT rerouted because of not enough bandwidth on alternative paths

    And: Remove the flow, restore the bandwidth on ISLs, reset costs

  • Able to reroute to a better path if it has enough bandwidth

    Given: A flow with alternate paths available

    When: Make one of the alternative paths to be the most preferable among all others

    And: Make the future path to have exact bandwidth to handle the flow

    And: Init a reroute of the flow

    Then: The flow is successfully rerouted and goes through the preferable path

    And: 'Thin' ISL has 0 available bandwidth left

    And: Remove the flow, restore bandwidths on ISLs, reset costs

  • Intentional flow reroute is not causing any packet loss

    Given: An unmetered flow going through a long not preferable path(reroute potential)

    When: Start traffic examination

    And: While traffic flow is active, request a flow reroute

    Then: Flow is rerouted

    And: Traffic examination result shows acceptable packet loss percentage

    And: Remove the flow

  • Able to reroute to a path with not enough bandwidth available in case ignoreBandwidth=true

    Given: A flow with alternate paths available

    When: Make the current path less preferable than alternatives

    And: Make all alternative paths to have not enough bandwidth to handle the flow

    And: Init a reroute to a more preferable path

    Then: The flow is rerouted because ignoreBandwidth=true

    And: Available bandwidth was not changed while rerouting due to ignoreBandwidth=true

    And: Remove the flow, restore the bandwidth on ISLs, reset costs

  • Intentional flow reroute with VXLAN encapsulation is not causing any packet loss

    Given: A vxlan flow

    When: Start traffic examination

    And: While traffic flow is active, request a flow reroute

    Then: Flow is rerouted

    And: Traffic examination result shows acceptable packet loss percentage

    And: Remove the flow

FlowValidationNegativeV2

The specification covers the following scenarios: -- Deleting flow rule from a switch and check if switch and flow validation fails. -- Failed switch validation should not cause validation errors for flows with all rules in place. Test case permutations (full-factored): - forward and reverse flows - ingress, transit and egress switches - Single switch, two switch and three+ switch flow spans.

  • Flow and switch validation should fail in case of missing rules with single switch configuration

    Given: Two flows with single switch configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on single switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with single switch configuration

    Given: Two flows with single switch configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on single switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with neighbouring configuration

    Given: Two flows with neighbouring configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on first switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with neighbouring configuration

    Given: Two flows with neighbouring configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on first switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with neighbouring configuration

    Given: Two flows with neighbouring configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on last switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with neighbouring configuration

    Given: Two flows with neighbouring configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on last switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on first switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on first switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on middle switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on middle switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on last switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on last switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Unable to get a non-existent flow

    When: Trying to get a non-existent flow

    Then: An error is received (404 code)

  • Unable to reroute a non-existent flow

    When: Trying to reroute a non-existent flow

    Then: An error is received (404 code)

  • Unable to validate a non-existent flow

    When: Trying to validate a non-existent flow

    Then: An error is received (404 code)

  • Unable to synchronize a non-existent flow

    When: Trying to synchronize a non-existent flow

    Then: An error is received (404 code)

  • Able to detect discrepancies for a flow with protected path

    When: Create a flow with protected path

    Then: Flow with protected path is created

    And: Validation of flow with protected path must be successful

    When: Delete rule of protected path on the srcSwitch

    Then: Flow validate detects discrepancies

    When: Delete all rules except default on the all involved switches

    Then: Flow validate detects discrepancies for all deleted rules

    And: Cleanup: delete the flow

FlowValidationNegative

The specification covers the following scenarios: -- Deleting flow rule from a switch and check if switch and flow validation fails. -- Failed switch validation should not cause validation errors for flows with all rules in place. Test case permutations (full-factored): - forward and reverse flows - ingress, transit and egress switches - Single switch, two switch and three+ switch flow spans.

  • Flow and switch validation should fail in case of missing rules with single switch configuration

    Given: Two flows with single switch configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on single switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with single switch configuration

    Given: Two flows with single switch configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on single switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with neighbouring configuration

    Given: Two flows with neighbouring configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on first switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with neighbouring configuration

    Given: Two flows with neighbouring configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on first switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with neighbouring configuration

    Given: Two flows with neighbouring configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on last switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with neighbouring configuration

    Given: Two flows with neighbouring configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on last switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on first switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on first switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on middle switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on middle switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: forward flow rule from first flow on last switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged forward flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Flow and switch validation should fail in case of missing rules with transit configuration

    Given: Two flows with transit configuration

    And: Both flows have the same switches in path

    When: reverse flow rule from first flow on last switch gets deleted

    Then: Intact flow should be validated successfully

    And: Damaged reverse flow validation should fail, while other direction should be validated successfully

    And: Flow rule discrepancy should contain dpID of the affected switch and cookie of the damaged flow

    And: Affected switch should have one missing rule with the same cookie as the damaged flow

    And: There should be no excess rules on the affected switch

    And: Validation of non-affected switches (if any) should succeed

    And: Delete the flows

  • Unable to get a non-existent flow

    When: Trying to get a non-existent flow

    Then: An error is received (404 code)

  • Unable to reroute a non-existent flow

    When: Trying to reroute a non-existent flow

    Then: An error is received (404 code)

  • Unable to validate a non-existent flow

    When: Trying to validate a non-existent flow

    Then: An error is received (404 code)

  • Unable to synchronize a non-existent flow

    When: Trying to synchronize a non-existent flow

    Then: An error is received (404 code)

  • Able to detect discrepancies for a flow with protected path

    When: Create a flow with protected path

    Then: Flow with protected path is created

    And: Validation of flow with protected path must be successful

    When: Delete rule of protected path on the srcSwitch

    Then: Flow validate detects discrepancies

    When: Delete all rules except default on the all involved switches

    Then: Flow validate detects discrepancies for all deleted rules

    And: Cleanup: delete the flow

FlowSyncV2

  • Able to synchronize a flow (install missing flow rules, reinstall existing) without rerouting

    Given: An intermediate-switch flow with deleted rules on src switch

    When: Synchronize the flow

    Then: The flow is not rerouted

    And: Missing flow rules are installed (existing ones are reinstalled) on all switches

    And: Flow is valid

    And: Delete the flow

  • Able to synchronize a flow (install missing flow rules, reinstall existing) with rerouting

    Given: An intermediate-switch flow with two possible paths at least and deleted rules on src switch

    And: Make one of the alternative flow paths more preferable than the current one

    When: Synchronize the flow

    Then: The flow is rerouted

    And: Flow rules are installed/reinstalled on switches remained from the original flow path

    And: Flow rules are installed on new switches involved in the current flow path

    And: Flow rules are deleted from switches that are NOT involved in the current flow path

    And: Flow is valid

    And: Delete the flow and link props, reset link costs

FlowSync

  • Able to synchronize a flow (install missing flow rules, reinstall existing) without rerouting

    Given: An intermediate-switch flow with deleted rules on src switch

    When: Synchronize the flow

    Then: The flow is not rerouted

    And: Missing flow rules are installed (existing ones are reinstalled) on all switches

    And: Flow is valid

    And: Delete the flow

  • Able to synchronize a flow (install missing flow rules, reinstall existing) with rerouting

    Given: An intermediate-switch flow with two possible paths at least and deleted rules on src switch

    And: Make one of the alternative flow paths more preferable than the current one

    When: Synchronize the flow

    Then: The flow is rerouted

    And: Flow rules are installed/reinstalled on switches remained from the original flow path

    And: Flow rules are installed on new switches involved in the current flow path

    And: Flow rules are deleted from switches that are NOT involved in the current flow path

    And: Flow is valid

    And: Delete the flow and link props, reset link costs

FlowPriorityReroute

  • System is able to reroute(automatically) flow #info in the correct order based on the priority field

    Given: Three flows on the same path, with alt paths available

    When: Init simultaneous reroute for all flows by bringing current path's ISL down

    Then: Flows were rerouted

    And: Reroute procedure was done based on the priority field

    And: Cleanup: revert system to original state

  • System is able to reroute(intentional) flow in the correct order based on the priority field

    Given: Three flows on the same path, with alt paths available

    When: Make another path more preferable

    And: Init simultaneous reroute for all flows

    Then: Flows were rerouted

    And: Reroute procedure was done based on the priority field

    And: Cleanup: revert system to original state

FlowPing

This spec tests all the functionality related to flow pings. Flow ping feature sends a 'ping' packet at the one end of the flow, expecting that this packet will be delivered at the other end. 'Pings' the flow in both directions(forward and reverse).

  • Able to ping a flow with vlan between switches 00:00:00:00:00:00:00:03 - 00:00:00:00:00:00:00:02

    Given: A flow with random vlan

    When: Ping the flow

    Then: Ping is successful

    And: No errors

    And: Unicast rule packet count is increased and logged to otsdb

    Cleanup: Remove the flow

  • Able to ping a flow with no vlan between switches 00:00:00:00:00:00:00:03 - 00:00:00:00:00:00:00:02

    Given: A flow with no vlan

    When: Ping the flow

    Then: Ping is successful

    And: No errors

    Cleanup: Remove the flow

  • Flow ping can detect a broken forward path with 2000ms timeout

    Given: A flow with at least 1 a-switch link

    When: Break the flow by removing rules from a-switch

    And: Ping the flow

    Then: Ping response properly shows that certain direction is unpingable

    Cleanup: Restore rules, costs and remove the flow

  • Flow ping can detect a broken reverse path with 2000ms timeout

    Given: A flow with at least 1 a-switch link

    When: Break the flow by removing rules from a-switch

    And: Ping the flow

    Then: Ping response properly shows that certain direction is unpingable

    Cleanup: Restore rules, costs and remove the flow

  • Flow ping can detect a broken forward and reverse path with 2000ms timeout

    Given: A flow with at least 1 a-switch link

    When: Break the flow by removing rules from a-switch

    And: Ping the flow

    Then: Ping response properly shows that certain direction is unpingable

    Cleanup: Restore rules, costs and remove the flow

  • Flow ping can detect a broken forward path with 4000ms timeout

    Given: A flow with at least 1 a-switch link

    When: Break the flow by removing rules from a-switch

    And: Ping the flow

    Then: Ping response properly shows that certain direction is unpingable

    Cleanup: Restore rules, costs and remove the flow

  • Flow ping can detect a broken reverse path with 4000ms timeout

    Given: A flow with at least 1 a-switch link

    When: Break the flow by removing rules from a-switch

    And: Ping the flow

    Then: Ping response properly shows that certain direction is unpingable

    Cleanup: Restore rules, costs and remove the flow

  • Flow ping can detect a broken forward and reverse path with 4000ms timeout

    Given: A flow with at least 1 a-switch link

    When: Break the flow by removing rules from a-switch

    And: Ping the flow

    Then: Ping response properly shows that certain direction is unpingable

    Cleanup: Restore rules, costs and remove the flow

  • Able to ping a single-switch flow

    Given: A single-switch flow

    When: Ping the flow

    Then: The flow is pingable

    And: No errors are present

    Cleanup: Remove the flow

  • Verify error if try to ping with wrong flowId

    When: Send ping request with non-existing flowId

    Then: Receive error response

FlowHistoryV2

Verify that history records are created for the create/update actions. History record is created in case the create/update action is completed successfully.

  • History records are created for the create/update actions using custom timeline

    When: Create a flow

    Then: History record is created

    When: Update the created flow

    Then: History record is created after updating the flow

    When: Delete the updated flow

    Then: History is still available for the deleted flow

  • History records are created for the create/update actions using custom timeline (v2)

    When: Create a flow

    Then: History record is created

    When: Update the created flow

    Then: History record is created after updating the flow

    When: Delete the updated flow

    Then: History is still available for the deleted flow

  • History records are created for the create/update actions using default timeline

    When: Create a flow

    Then: History record is created

    When: Update the created flow

    Then: History record is created after updating the flow

    When: Delete the updated flow

    Then: History is still available for the deleted flow

  • History should not be returned in case timeline is incorrect (timeBefore > timeAfter)

    When: Create a flow

    Then: History record is created

    When: Try to get history for incorrect timeline

    Then: History record is NOT returned

    And: Cleanup: restore default state(remove created flow)

  • History should not be returned in case flow was never created

    When: Try to get history for incorrect flowId

    Then: History record is NOT returned

FlowHistory

Verify that history records are created for the create/update actions. History record is created in case the create/update action is completed successfully.

  • History records are created for the create/update actions using custom timeline

    When: Create a flow

    Then: History record is created

    When: Update the created flow

    Then: History record is created after updating the flow

    When: Delete the updated flow

    Then: History is still available for the deleted flow

  • History records are created for the create/update actions using default timeline

    When: Create a flow

    Then: History record is created

    When: Update the created flow

    Then: History record is created after updating the flow

    When: Delete the updated flow

    Then: History is still available for the deleted flow

  • History should not be returned in case timeline is incorrect (timeBefore > timeAfter)

    When: Create a flow

    Then: History record is created

    When: Try to get history for incorrect timeline

    Then: History record is NOT returned

    And: Cleanup: restore default state(remove created flow)

  • History should not be returned in case flow was never created

    When: Try to get history for incorrect flowId

    Then: History record is NOT returned

FlowDiversityV2

This test suite verifies the ability to create diverse flows in the system. Diverse flows are flows that should not overlap at all or the overlapping should be minimal. Such flows form a so-called diversity group. Ideally, the diversity group should not have flows with overlapping paths. But it depends on the cost of paths. The paths of flows from the same diversity group may overlap if the cost of each non-overlapping path is more than the cost of the overlapping path. The cost of paths for diverse flows is calculated in real time and consists of the following parameters:

  1. The cost of ISL involved in the flow path (taken from DB);
  2. (diversity.switch.weight) * (the number of diverse flows going through this switch);
  3. (diversity.isl.weight) * (the number of diverse flows going through this ISL).

Refer to https://github.com/telstra/open-kilda/issues/1231 for more details.

  • Able to create diverse flows

    Given: Two active neighboring switches with three not overlapping paths at least

    When: Create three flows with diversity enabled

    Then: All flows have diverse flow IDs in response

    And: All flows have different paths

    And: Delete flows

  • Able to update flows to become diverse

    Given: Two active neighboring switches with three not overlapping paths at least

    And: Create three flows

    When: Update the second flow to become diverse

    Then: The flow became diverse and changed the path

    And: All flows except last one have the 'diverse_with' field

    When: Update the third flow to become diverse

    Then: The flow became diverse and all flows have different paths

    And: Delete flows

  • Able to update flows to become not diverse

    Given: Two active neighboring switches with three not overlapping paths at least

    And: Create three flows with diversity enabled

    When: Update the second flow to become not diverse

    Then: The flow became not diverse and rerouted to the more preferable path (path of the first flow)

    And: The 'diverse_with' field is removed

    When: Update the third flow to become not diverse

    Then: The flow became not diverse and rerouted to the more preferable path (path of the first flow)

    And: The 'diverse_with' field is removed

    And: Delete flows

  • Diverse flows are built through the same path if there are no alternative paths available

    Given: Two active neighboring switches with two not overlapping paths at least

    And: Create a flow going through these switches

    And: Make all alternative paths unavailable (bring ports down on the source switch)

    When: Create the second flow with diversity enabled

    Then: The second flow is built through the same path as the first flow

    And: Restore topology, delete flows and reset costs

  • Links and switches get extra cost that is considered while calculating diverse flow paths

    Given: Two active neighboring switches with three not overlapping paths at least

    And: Create a flow going through these switches

    And: Make each alternative path less preferable than the first flow path

    When: Create the second flow with diversity enabled

    Then: The flow is built through the most preferable path (path of the first flow)

    When: Create the third flow with diversity enabled

    Then: The flow is built through one of alternative paths because they are preferable already

    And: Delete flows and link props

  • Able to get flow paths with correct overlapping segments stats (casual flows)

    Given: Two active neighboring switches with three not overlapping paths at least

    And: Create three flows with diversity enabled

    When: Get flow path for all flows

    Then: Flow path response for all flows has correct overlapping segments stats

    And: Delete flows

  • Able to get flow paths with correct overlapping segments stats (single-switch flows)

    Given: Two active switches

    And: Create two single-switch flows with diversity enabled on the first switch

    And: Create the third single-switch flow with diversity enabled on the second switch

    When: Get flow path for all flows

    Then: Flow path response for all flows has correct overlapping segments stats

    And: Delete flows

  • Able to get flow paths with correct overlapping segments stats (casual + single-switch flows)

    Given: Two active not neighboring switches

    And: Create a casual flow going through these switches

    And: Create a single-switch with diversity enabled on the source switch of the first flow

    And: Create a single-switch with diversity enabled on the destination switch of the first flow

    When: Get flow path for all flows

    Then: Flow path response for all flows has correct overlapping segments stats

    And: Delete flows

FlowDiversity

This test suite verifies the ability to create diverse flows in the system. Diverse flows are flows that should not overlap at all or the overlapping should be minimal. Such flows form a so-called diversity group. Ideally, the diversity group should not have flows with overlapping paths. But it depends on the cost of paths. The paths of flows from the same diversity group may overlap if the cost of each non-overlapping path is more than the cost of the overlapping path. The cost of paths for diverse flows is calculated in real time and consists of the following parameters:

  1. The cost of ISL involved in the flow path (taken from DB);
  2. (diversity.switch.weight) * (the number of diverse flows going through this switch);
  3. (diversity.isl.weight) * (the number of diverse flows going through this ISL).

Refer to https://github.com/telstra/open-kilda/issues/1231 for more details.

  • Able to create diverse flows

    Given: Two active neighboring switches with three not overlapping paths at least

    When: Create three flows with diversity enabled

    Then: All flows have diverse flow IDs in response

    And: All flows have different paths

    And: Delete flows

  • Able to update flows to become diverse

    Given: Two active neighboring switches with three not overlapping paths at least

    And: Create three flows

    When: Update the second flow to become diverse

    Then: The flow became diverse and changed the path

    And: All flows except last one have the 'diverse_with' field

    When: Update the third flow to become diverse

    Then: The flow became diverse and all flows have different paths

    And: Delete flows

  • Able to update flows to become not diverse

    Given: Two active neighboring switches with three not overlapping paths at least

    And: Create three flows with diversity enabled

    When: Update the second flow to become not diverse

    Then: The flow became not diverse and rerouted to the more preferable path (path of the first flow)

    And: The 'diverse_with' field is removed

    When: Update the third flow to become not diverse

    Then: The flow became not diverse and rerouted to the more preferable path (path of the first flow)

    And: The 'diverse_with' field is removed

    And: Delete flows

  • Diverse flows are built through the same path if there are no alternative paths available

    Given: Two active neighboring switches with two not overlapping paths at least

    And: Create a flow going through these switches

    And: Make all alternative paths unavailable (bring ports down on the source switch)

    When: Create the second flow with diversity enabled

    Then: The second flow is built through the same path as the first flow

    And: Restore topology, delete flows and reset costs

  • Links and switches get extra cost that is considered while calculating diverse flow paths

    Given: Two active neighboring switches with three not overlapping paths at least

    And: Create a flow going through these switches

    And: Make each alternative path less preferable than the first flow path

    When: Create the second flow with diversity enabled

    Then: The flow is built through the most preferable path (path of the first flow)

    When: Create the third flow with diversity enabled

    Then: The flow is built through one of alternative paths because they are preferable already

    And: Delete flows and link props

  • Able to get flow paths with correct overlapping segments stats (casual flows)

    Given: Two active neighboring switches with three not overlapping paths at least

    And: Create three flows with diversity enabled

    When: Get flow path for all flows

    Then: Flow path response for all flows has correct overlapping segments stats

    And: Delete flows

  • Able to get flow paths with correct overlapping segments stats (single-switch flows)

    Given: Two active switches

    And: Create two single-switch flows with diversity enabled on the first switch

    And: Create the third single-switch flow with diversity enabled on the second switch

    When: Get flow path for all flows

    Then: Flow path response for all flows has correct overlapping segments stats

    And: Delete flows

  • Able to get flow paths with correct overlapping segments stats (casual + single-switch flows)

    Given: Two active not neighboring switches

    And: Create a casual flow going through these switches

    And: Create a single-switch with diversity enabled on the source switch of the first flow

    And: Create a single-switch with diversity enabled on the destination switch of the first flow

    When: Get flow path for all flows

    Then: Flow path response for all flows has correct overlapping segments stats

    And: Delete flows

FlowCrudV2

Verify CRUD operations and health of most typical types of flows on different types of switches.

  • System marks flow as UP when and only when all the rules are actually set on all involved switches

    Given: Two active not neighbouring switches

    When: Create a flow

    Then: Flow is created

    And: All needed rules are installed on all involved switches

    And: Cleanup: Delete the flow

  • Valid flow without transit switch and with random vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid flow without transit switch and without vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid flow without transit switch and vlan only on src has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid flow with transit switch and random vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:07 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid flow with transit switch and no vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:07 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid flow with transit switch and vlan only on dst has traffic and no rule discrepancies (00:00:00:00:00:00:00:07 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid single-switch flow with vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:08)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid single-switch flow without vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:08)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid single-switch flow with vlan only on dst has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:08)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Able to create a second flow if same switch-port but vlans on src and dst are swapped

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with same switch-port but vlans on src and dst are swapped

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if same switch-port but vlans on src and dst are different

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with same switch-port but vlans on src and dst are different

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if vlan-port of new src = vlan-port of existing dst (+ different src)

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with vlan-port of new src = vlan-port of existing dst (+ different src)

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if vlan-port of new dst = vlan-port of existing src (but different switches)

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with vlan-port of new dst = vlan-port of existing src (but different switches)

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if vlan of new dst = vlan of existing src and port of new dst = port of existing dst

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with vlan of new dst = vlan of existing src and port of new dst = port of existing dst

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if default and tagged flows on the same port on dst switch

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with default and tagged flows on the same port on dst switch

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if default and tagged flows on the same port on src switch

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with default and tagged flows on the same port on src switch

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if tagged and default flows on the same port on dst switch

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with tagged and default flows on the same port on dst switch

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if tagged and default flows on the same port on src switch

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with tagged and default flows on the same port on src switch

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if default and tagged flows on the same ports on src and dst switches

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with default and tagged flows on the same ports on src and dst switches

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if tagged and default flows on the same ports on src and dst switches

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with tagged and default flows on the same ports on src and dst switches

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create single switch single port flow with different vlan (00:00:00:00:00:00:00:02)

    Given: A flow

    Expect: No rule discrepancies on the switch

    And: No discrepancies when doing flow validation

    When: Remove the flow

    Then: The flow is not present in NB

    And: No rule discrepancies on the switch after delete

  • Able to validate flow with zero bandwidth

    Given: A flow with zero bandwidth

    When: Create a flow with zero bandwidth

    Then: Validation of flow with zero bandwidth must be succeed

    And: Cleanup: delete the flow

  • Unable to create single-switch flow with the same ports and vlans on both sides

    Given: Potential single-switch flow with the same ports and vlans on both sides

    When: Try creating such flow

    Then: Error is returned, stating a readable reason

  • Unable to create flow with the same vlans on the same port on src switch

    Given: A potential flow

    And: Another potential flow with the same vlans on the same port on src switch

    When: Create the first flow

    And: Try creating the second flow which conflicts

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete the dominant flow

  • Unable to create flow with the same vlans on the same port on dst switch

    Given: A potential flow

    And: Another potential flow with the same vlans on the same port on dst switch

    When: Create the first flow

    And: Try creating the second flow which conflicts

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete the dominant flow

  • Unable to create flow with no vlan, both flows are on the same port on src switch

    Given: A potential flow

    And: Another potential flow with no vlan, both flows are on the same port on src switch

    When: Create the first flow

    And: Try creating the second flow which conflicts

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete the dominant flow

  • Unable to create flow with no vlan, both flows are on the same port on dst switch

    Given: A potential flow

    And: Another potential flow with no vlan, both flows are on the same port on dst switch

    When: Create the first flow

    And: Try creating the second flow which conflicts

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete the dominant flow

  • Unable to create flow with the same flow ID

    Given: A potential flow

    And: Another potential flow with the same flow ID

    When: Create the first flow

    And: Try creating the second flow which conflicts

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete the dominant flow

  • A flow cannot be created with asymmetric forward and reverse paths

    Given: Two active neighboring switches with two possible flow paths at least and different number of hops

    And: Make all shorter forward paths not preferable. Shorter reverse paths are still preferable

    When: Create a flow

    Then: The flow is built through one of the long paths

    And: The flow has symmetric forward and reverse paths even though there is a more preferable reverse path

    And: Delete the flow and reset costs

  • Error is returned if there is no available path to source switch

    Given: A switch that has no connection to other switches

    When: Try building a flow using the isolated switch

    Then: Error is returned, stating that there is no path found for such flow

    And: Cleanup: restore connection to the isolated switch and reset costs

  • Error is returned if there is no available path to destination switch

    Given: A switch that has no connection to other switches

    When: Try building a flow using the isolated switch

    Then: Error is returned, stating that there is no path found for such flow

    And: Cleanup: restore connection to the isolated switch and reset costs

  • Removing flow while it is still in progress of being set up should not cause rule discrepancies

    Given: A potential flow

    When: Init creation of a new flow

    And: Immediately remove the flow

    Then: System returns error as being unable to remove in progress flow

    And: Flow is not removed

    And: Flow eventually gets into UP state

    And: All related switches have no discrepancies in rules

    Cleanup: Remove the flow

  • Unable to create a flow on an isl port in case port is occupied on a source switch

    Given: An isl

    When: Try to create a flow using isl port

    Then: Flow is not created

  • Unable to create a flow on an isl port in case port is occupied on a destination switch

    Given: An isl

    When: Try to create a flow using isl port

    Then: Flow is not created

  • Unable to update a flow in case new port is an isl port on a source switch

    Given: An isl

    And: A flow

    When: Try to edit port to isl port

    Then: Cleanup: delete the flow

  • Unable to update a flow in case new port is an isl port on a destination switch

    Given: An isl

    And: A flow

    When: Try to edit port to isl port

    Then: Cleanup: delete the flow

  • Unable to create a flow on an isl port when ISL status is FAILED

    Given: An inactive isl with failed state

    When: Try to create a flow using ISL src port

    Then: Flow is not created

    And: Cleanup: Restore state of the ISL

  • Unable to create a flow on an isl port when ISL status is MOVED

    Given: An inactive isl with moved state

    When: Try to create a flow using ISL src port

    Then: Flow is not created

    And: Cleanup: Restore status of the ISL and delete new created ISL

  • Able to CRUD unmetered one-switch pinned flow

    When: Create a flow

    Then: Pinned flow is created

    When: Update the flow (pinned=false)

    Then: The pinned option is disabled

    And: Cleanup: Delete the flow

  • Able to CRUD pinned flow

    When: Create a flow

    Then: Pinned flow is created

    When: Update the flow (pinned=false)

    Then: The pinned option is disabled

    And: Cleanup: Delete the flow

  • System doesn't allow to create a one-switch flow on a DEACTIVATED switch

    Given: Disconnected switch

    When: Try to create a one-switch flow on a deactivated switch

    Then: Human readable error is returned

    And: Cleanup: Connect switch back to the controller

  • System allows to CRUD protected flow

    Given: Two active not neighboring switches with two diverse paths at least

    When: Create flow with protected path

    Then: Flow is created with protected path

    And: Rules for main and protected paths are created

    And: Validation of flow must be successful

    When: Update flow: disable protected path(allocateProtectedPath=false)

    Then: Protected path is disabled

    And: Rules for protected path are deleted

    And: Cleanup: delete the flow

  • System allows to create diverse flows

    Given: Two active not neighboring switches with three diverse paths at least

    When: Create three flows with diversity enabled

    Then: All flows have diverse flow IDs in response

    And: All flows have different paths

    And: Delete flows

  • System allows to set/update description/priority/max-latency for a flow

    Given: Two active neighboring switches

    And: Value for each field

    When: Create a flow with predefined values

    Then: Flow is created with needed values

    When: Update predefined values

    Then: Flow is updated correctly

    And: Cleanup: Delete the flow

  • Systems allows to pass traffic via default and vlan flow when they are on the same port

    Given: At least 3 traffGen switches

    When: Create a vlan flow

    And: Create a default flow with the same srcSwitch and different dstSwitch

    Then: The default flow has less priority than the vlan flow

    And: System allows traffic on the vlan flow

    And: System allows traffic on the default flow

    And: Cleanup: Delete the flows

  • System doesn't ignore encapsulationType when flow is created with ignoreBandwidth = true

    Given: Two active switches

    When: Create a flow with not supported encapsulation type on the switches

    Then: Human readable error is returned

FlowCrud

Verify CRUD operations and health of most typical types of flows on different types of switches.

  • Valid flow without transit switch and with random vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid flow without transit switch and without vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid flow without transit switch and vlan only on src has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid flow with transit switch and random vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:07 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid flow with transit switch and no vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:07 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid flow with transit switch and vlan only on dst has traffic and no rule discrepancies (00:00:00:00:00:00:00:07 - 00:00:00:00:00:00:00:03)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid single-switch flow with vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:08)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid single-switch flow without vlans has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:08)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Valid single-switch flow with vlan only on dst has traffic and no rule discrepancies (00:00:00:00:00:00:00:08 - 00:00:00:00:00:00:00:08)

    Given: A flow

    Expect: No rule discrepancies on every switch of the flow

    And: No discrepancies when doing flow validation

    And: The flow allows traffic (only applicable flows are checked)

    When: Remove the flow

    Then: The flow is not present in NB

    And: ISL bandwidth is restored

    And: No rule discrepancies on every switch of the flow

  • Able to create a second flow if same switch-port but vlans on src and dst are swapped

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with same switch-port but vlans on src and dst are swapped

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if same switch-port but vlans on src and dst are different

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with same switch-port but vlans on src and dst are different

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if vlan-port of new src = vlan-port of existing dst (+ different src)

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with vlan-port of new src = vlan-port of existing dst (+ different src)

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if vlan-port of new dst = vlan-port of existing src (but different switches)

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with vlan-port of new dst = vlan-port of existing src (but different switches)

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if vlan of new dst = vlan of existing src and port of new dst = port of existing dst

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with vlan of new dst = vlan of existing src and port of new dst = port of existing dst

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if default and tagged flows on the same port on dst switch

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with default and tagged flows on the same port on dst switch

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if default and tagged flows on the same port on src switch

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with default and tagged flows on the same port on src switch

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if tagged and default flows on the same port on dst switch

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with tagged and default flows on the same port on dst switch

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if tagged and default flows on the same port on src switch

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with tagged and default flows on the same port on src switch

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if default and tagged flows on the same ports on src and dst switches

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with default and tagged flows on the same ports on src and dst switches

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create a second flow if tagged and default flows on the same ports on src and dst switches

    Given: Two potential flows that should not conflict

    When: Create the first flow

    And: Try creating a second flow with tagged and default flows on the same ports on src and dst switches

    Then: Both flows are successfully created

    And: Cleanup: delete flows

  • Able to create single switch single port flow with different vlan (00:00:00:00:00:00:00:02)

    Given: A flow

    Expect: No rule discrepancies on the switch

    And: No discrepancies when doing flow validation

    When: Remove the flow

    Then: The flow is not present in NB

    And: No rule discrepancies on the switch after delete

  • Able to validate flow with zero bandwidth

    Given: A flow with zero bandwidth

    When: Create a flow with zero bandwidth

    Then: Validation of flow with zero bandwidth must be succeed

    And: Cleanup: delete the flow

  • Unable to create single-switch flow with the same ports and vlans on both sides

    Given: Potential single-switch flow with the same ports and vlans on both sides

    When: Try creating such flow

    Then: Error is returned, stating a readable reason

  • Unable to create flow with the same vlans on the same port on src switch

    Given: A potential flow

    And: Another potential flow with the same vlans on the same port on src switch

    When: Create the first flow

    And: Try creating the second flow which conflicts

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete the dominant flow

  • Unable to create flow with the same vlans on the same port on dst switch

    Given: A potential flow

    And: Another potential flow with the same vlans on the same port on dst switch

    When: Create the first flow

    And: Try creating the second flow which conflicts

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete the dominant flow

  • Unable to create flow with no vlan, both flows are on the same port on src switch

    Given: A potential flow

    And: Another potential flow with no vlan, both flows are on the same port on src switch

    When: Create the first flow

    And: Try creating the second flow which conflicts

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete the dominant flow

  • Unable to create flow with no vlan, both flows are on the same port on dst switch

    Given: A potential flow

    And: Another potential flow with no vlan, both flows are on the same port on dst switch

    When: Create the first flow

    And: Try creating the second flow which conflicts

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete the dominant flow

  • Unable to create flow with the same flow ID

    Given: A potential flow

    And: Another potential flow with the same flow ID

    When: Create the first flow

    And: Try creating the second flow which conflicts

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete the dominant flow

  • Unable to update flow (the same vlans on the same port on src switch)

    Given: Two potential flows

    When: Create two flows

    And: Try updating the second flow which should conflict with the first one

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete flows

  • Unable to update flow (the same vlans on the same port on dst switch)

    Given: Two potential flows

    When: Create two flows

    And: Try updating the second flow which should conflict with the first one

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete flows

  • Unable to update flow (no vlan, both flows are on the same port on src switch)

    Given: Two potential flows

    When: Create two flows

    And: Try updating the second flow which should conflict with the first one

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete flows

  • Unable to update flow (no vlan, both flows are on the same port on dst switch)

    Given: Two potential flows

    When: Create two flows

    And: Try updating the second flow which should conflict with the first one

    Then: Error is returned, stating a readable reason of conflict

    And: Cleanup: delete flows

  • A flow cannot be created with asymmetric forward and reverse paths

    Given: Two active neighboring switches with two possible flow paths at least and different number of hops

    And: Make all shorter forward paths not preferable. Shorter reverse paths are still preferable

    When: Create a flow

    Then: The flow is built through one of the long paths

    And: The flow has symmetric forward and reverse paths even though there is a more preferable reverse path

    And: Delete the flow and reset costs

  • Error is returned if there is no available path to source switch

    Given: A switch that has no connection to other switches

    When: Try building a flow using the isolated switch

    Then: Error is returned, stating that there is no path found for such flow

    And: Cleanup: restore connection to the isolated switch and reset costs

  • Error is returned if there is no available path to destination switch

    Given: A switch that has no connection to other switches

    When: Try building a flow using the isolated switch

    Then: Error is returned, stating that there is no path found for such flow

    And: Cleanup: restore connection to the isolated switch and reset costs

  • Removing flow while it is still in progress of being created should not cause rule discrepancies

    Given: A potential flow

    When: Init creation of a new flow

    And: Immediately remove the flow

    Then: All related switches have no discrepancies in rules

  • Unable to create a flow on an isl port in case port is occupied on a source switch

    Given: An isl

    When: Try to create a flow using isl port

    Then: Flow is not created

  • Unable to create a flow on an isl port in case port is occupied on a destination switch

    Given: An isl

    When: Try to create a flow using isl port

    Then: Flow is not created

  • Unable to update a flow in case new port is an isl port on a source switch

    Given: An isl

    And: A flow

    When: Try to edit port to isl port

    Then: Cleanup: delete the flow

  • Unable to update a flow in case new port is an isl port on a destination switch

    Given: An isl

    And: A flow

    When: Try to edit port to isl port

    Then: Cleanup: delete the flow

  • Unable to create a flow on an isl port when ISL status is FAILED

    Given: An inactive isl with failed state

    When: Try to create a flow using ISL src port

    Then: Flow is not created

    And: Cleanup: Restore state of the ISL

  • Unable to create a flow on an isl port when ISL status is MOVED

    Given: An inactive isl with moved state

    When: Try to create a flow using ISL src port

    Then: Flow is not created

    And: Cleanup: Restore status of the ISL and delete new created ISL

  • Able to CRUD a metered single switch pinned flow

    When: Create a flow

    Then: Pinned flow is created

    When: Update the flow (pinned=false)

    Then: The pinned option is disabled

    And: Cleanup: Delete the flow

  • Able to CRUD an unmetered single switch pinned flow

    When: Create a flow

    Then: Pinned flow is created

    When: Update the flow (pinned=false)

    Then: The pinned option is disabled

    And: Cleanup: Delete the flow

  • Able to CRUD a metered pinned flow

    When: Create a flow

    Then: Pinned flow is created

    When: Update the flow (pinned=false)

    Then: The pinned option is disabled

    And: Cleanup: Delete the flow

  • Able to CRUD an unmetered pinned flow

    When: Create a flow

    Then: Pinned flow is created

    When: Update the flow (pinned=false)

    Then: The pinned option is disabled

    And: Cleanup: Delete the flow

  • System doesn't allow to create a one-switch flow on a DEACTIVATED switch

    Given: A deactivated switch

    When: Create a flow

    Then: Human readable error is returned

    And: Cleanup: Activate the switch and reset costs

  • System recreates excess meter when flow is created with the same meterId

    Given: A Noviflow switch

    And: Create excess meters on the given switch

    When: Create several flows

    Then: Needed amount of flow was created

    And: Needed amount of meter was recreated

    And: Cleanup: Delete the flows and excess meters

  • System doesn't create flow when reverse path has different bandwidth than forward path on the second link

    Given: Two active not neighboring switches

    And: Select path for further manipulation with it

    And: Make all alternative paths unavailable (bring ports down on the src/intermediate switches)

    And: Update reverse path to have not enough bandwidth to handle the flow

    When: Create a flow

    Then: Flow is not created

    And: Restore topology, delete the flow and reset costs

FlowConnectedDevice

Verify ability to detect connected devices per flow endpoint (src/dst). Verify allocated Connected Devices resources and installed rules.

  • Able to create a TRANSIT_VLAN flow with srcLldp=false and dstLldp=true

    Given: A flow with enabled or disabled connected devices

    When: Create a flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint if enabled

    And: Delete the flow

    Then: Delete action removed all rules and meters

  • Able to create a TRANSIT_VLAN protected flow with srcLldp=true and dstLldp=false

    Given: A flow with enabled or disabled connected devices

    When: Create a flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint if enabled

    And: Delete the flow

    Then: Delete action removed all rules and meters

  • Able to create a VXLAN flow with srcLldp=false and dstLldp=true

    Given: A flow with enabled or disabled connected devices

    When: Create a flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint if enabled

    And: Delete the flow

    Then: Delete action removed all rules and meters

  • Able to create a VXLAN protected oneSwitch flow with srcLldp=true and dstLldp=false

    Given: A flow with enabled or disabled connected devices

    When: Create a flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint if enabled

    And: Delete the flow

    Then: Delete action removed all rules and meters

  • Able to create a TRANSIT_VLAN flow with srcLldp=true and dstLldp=true

    Given: A flow with enabled or disabled connected devices

    When: Create a flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint if enabled

    And: Delete the flow

    Then: Delete action removed all rules and meters

  • Able to create a TRANSIT_VLAN oneSwitch flow with srcLldp=true and dstLldp=true

    Given: A flow with enabled or disabled connected devices

    When: Create a flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint if enabled

    And: Delete the flow

    Then: Delete action removed all rules and meters

  • Able to create a VXLAN protected flow with srcLldp=true and dstLldp=true

    Given: A flow with enabled or disabled connected devices

    When: Create a flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint if enabled

    And: Delete the flow

    Then: Delete action removed all rules and meters

  • Able to update flow from srcLldpDevices=false, dstLldpDevices=false to srcLldpDevices=false, dstLldpDevices=false

    Given: Created flow with enabled or disabled connected devices

    When: Update the flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint according to updated status

    And: Cleanup: delete the flow

  • Able to update flow from srcLldpDevices=true, dstLldpDevices=true to srcLldpDevices=true, dstLldpDevices=true

    Given: Created flow with enabled or disabled connected devices

    When: Update the flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint according to updated status

    And: Cleanup: delete the flow

  • Able to update flow from srcLldpDevices=true, dstLldpDevices=true to srcLldpDevices=false, dstLldpDevices=false

    Given: Created flow with enabled or disabled connected devices

    When: Update the flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint according to updated status

    And: Cleanup: delete the flow

  • Able to update flow from srcLldpDevices=false, dstLldpDevices=false to srcLldpDevices=true, dstLldpDevices=true

    Given: Created flow with enabled or disabled connected devices

    When: Update the flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint according to updated status

    And: Cleanup: delete the flow

  • Able to update flow from srcLldpDevices=false, dstLldpDevices=true to srcLldpDevices=true, dstLldpDevices=false

    Given: Created flow with enabled or disabled connected devices

    When: Update the flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint according to updated status

    And: Cleanup: delete the flow

  • Able to update flow from srcLldpDevices=true, dstLldpDevices=true to srcLldpDevices=false, dstLldpDevices=true

    Given: Created flow with enabled or disabled connected devices

    When: Update the flow with connected devices

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint according to updated status

    And: Cleanup: delete the flow

  • Able to detect devices on a single-switch different-port flow

    Given: A flow between different ports on the same switch

    When: A device connects to src endpoint and sends lldp

    Then: Connected device is recognized and saved

    When: Remove the flow

    And: Try to get connected devices for removed flow

    Then: Error is returned

  • Able to swap flow paths with connected devices (srcLldpDevices=true, dstLldpDevices=false)

    Given: Created protected flow with enabled or disabled connected devices

    When: Swap flow paths

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint

    And: Cleanup: delete the flow

  • Able to swap flow paths with connected devices (srcLldpDevices=true, dstLldpDevices=true)

    Given: Created protected flow with enabled or disabled connected devices

    When: Swap flow paths

    Then: Flow and src/dst switches are valid

    And: LLDP meters must be installed

    And: Ingress and LLDP rules must be installed

    When: Two devices send lldp packet on each flow endpoint

    Then: Getting connecting devices shows corresponding devices on each endpoint

    And: Cleanup: delete the flow

  • Able to handle 'timeLastSeen' field when receive repeating packets from the same device

    Given: Flow that detects connected devices

    And: A connected device

    When: Device sends lldp packet

    Then: Device is registered for the flow, with timeLastSeen and timeFirstSeen values

    When: Same packet is sent again

    Then: timeLastSeen is updated, timeFirstSeen remains the same

    Cleanup: Disconnect the device and remove the flow

  • Able to detect different devices on the same port

    Given: Flow that detects connected devices

    And: A connected device

    When: Two completely different lldp packets are sent

    Then: 2 devices are registered for the flow

    When: Same device (same mac address) sends lldp packet with updated port number

    Then: Device is recognized as new one and total of 3 devices are registered for the flow

    When: Request devices list with 'since' param equal to last registered device

    Then: Only 1 device is returned (the latest registered)

    Cleanup: Disconnect the device and remove the flow

DefaultFlowV2

System allows to create default port(vlan=0) and simple flow(vlan=) on the same port. Default flow has lower priority than simple flow. Also system allows to pass tagged traffic via default flow.

  • Systems allows to pass traffic via default and vlan flow when they are on the same port

    Given: At least 3 traffGen switches

    When: Create a vlan flow

    And: Create a default flow with the same srcSwitch and different dstSwitch

    Then: The default flow has less priority than the vlan flow

    And: System allows traffic on the vlan flow

    And: System allows traffic on the default flow

    And: Cleanup: Delete the flows

  • System allows tagged traffic via default flow(0<->0)

    When: Create a default flow

    Then: System allows tagged traffic on the default flow

    And: Cleanup: Delete the flows

  • Unable to send traffic from simple flow into default flow and vice versa

    Given: A default flow

    And: A simple flow

    When: Try to send traffic from simple flow into default flow and vice versa

    Then: System doesn't allow to send traffic in these directions

    And: Cleanup: Delete the flows

  • Unable to create two default flow on the same port

    When: Create first default flow

    And: Try to create second default flow on the same port

    Then: Human readable error is returned

    And: Cleanup: Delete the flow

DefaultFlow

System allows to create default port(vlan=0) and simple flow(vlan=) on the same port. Default flow has lower priority than simple flow. Also system allows to pass tagged traffic via default flow.

  • Systems allows to pass traffic via default and vlan flow when they are on the same port

    Given: At least 3 traffGen switches

    When: Create a vlan flow

    And: Create a default flow with the same srcSwitch and different dstSwitch

    Then: The default flow has less priority than the vlan flow

    And: System allows traffic on the vlan flow

    And: System allows traffic on the default flow

    And: Cleanup: Delete the flows

  • System allows tagged traffic via default flow(0<->0)

    When: Create a default flow

    Then: System allows tagged traffic on the default flow

    And: Cleanup: Delete the flows

  • Unable to send traffic from simple flow into default flow and vice versa

    Given: A default flow

    And: A simple flow

    When: Try to send traffic from simple flow into default flow and vice versa

    Then: System doesn't allow to send traffic in these directions

    And: Cleanup: Delete the flows

  • Unable to create two default flow on the same port

    When: Create first default flow

    And: Try to create second default flow on the same port

    Then: Human readable error is returned

    And: Cleanup: Delete the flow

BandwidthV2

Verify that ISL's bandwidth behaves consistently and does not allow any oversubscribtions etc.

  • Available bandwidth on ISLs changes respectively when creating/updating/deleting a flow

    Given: Two active not neighboring switches

    When: Create a flow with a valid bandwidth

    Then: Available bandwidth on ISLs is changed in accordance with flow maximum bandwidth

    When: Update the flow with a valid bandwidth

    Then: The flow is successfully updated and has 'Up' status

    And: Available bandwidth on ISLs is changed in accordance with new flow maximum bandwidth

    When: Delete the flow

    Then: Available bandwidth on ISLs is changed to the initial value before flow creation

  • Longer path is chosen in case of not enough available bandwidth on a shorter path

    Given: Two active switches with two possible flow paths at least

    When: Create a flow to reduce available bandwidth on links of the expected preferable path

    Then: The flow is really built through the expected preferable path

    When: Create another flow. One path is shorter but available bandwidth is not enough, another path is longer

    Then: The flow is built through longer path where available bandwidth is enough

    And: Delete created flows

  • Unable to exceed bandwidth limit on ISL when creating a flow

    Given: Two active switches

    When: Create a flow with a bandwidth that exceeds available bandwidth on ISL

    Then: The flow is not created because flow path should not be found

  • Unable to exceed bandwidth limit on ISL when updating a flow

    Given: Two active switches

    When: Create a flow with a valid bandwidth

    And: Update the flow with a bandwidth that exceeds available bandwidth on ISL

    Then: The flow is not updated because flow path should not be found

    And: Delete the flow

  • Able to exceed bandwidth limit on ISL when creating/updating a flow with ignore_bandwidth=true

    Given: Two active switches

    When: Create a flow with a bandwidth that exceeds available bandwidth on ISL (ignore_bandwidth=true)

    Then: Available bandwidth on ISLs is not changed in accordance with flow maximum bandwidth

    When: Update the flow with a bandwidth that exceeds available bandwidth on ISL (ignore_bandwidth = true)

    Then: The flow is successfully updated and has 'Up' status

    And: Available bandwidth on ISLs is not changed in accordance with new flow maximum bandwidth

    And: Delete the flow

  • Able to update bandwidth to maximum link speed without using alternate links

    Given: Two active neighboring switches

    When: Create a flow with a valid small bandwidth

    Then: Only one link is involved in flow path

    When: Update flow bandwidth to maximum link speed

    Then: The flow is successfully updated and has 'Up' status

    And: The same path is used by updated flow

    And: Delete the flow

Bandwidth

Verify that ISL's bandwidth behaves consistently and does not allow any oversubscribtions etc.

  • Available bandwidth on ISLs changes respectively when creating/updating/deleting a flow

    Given: Two active not neighboring switches

    When: Create a flow with a valid bandwidth

    Then: Available bandwidth on ISLs is changed in accordance with flow maximum bandwidth

    When: Update the flow with a valid bandwidth

    Then: The flow is successfully updated and has 'Up' status

    And: Available bandwidth on ISLs is changed in accordance with new flow maximum bandwidth

    When: Delete the flow

    Then: Available bandwidth on ISLs is changed to the initial value before flow creation

  • Longer path is chosen in case of not enough available bandwidth on a shorter path

    Given: Two active switches with two possible flow paths at least

    When: Create a flow to reduce available bandwidth on links of the expected preferable path

    Then: The flow is really built through the expected preferable path

    When: Create another flow. One path is shorter but available bandwidth is not enough, another path is longer

    Then: The flow is built through longer path where available bandwidth is enough

    And: Delete created flows

  • Unable to exceed bandwidth limit on ISL when creating a flow

    Given: Two active switches

    When: Create a flow with a bandwidth that exceeds available bandwidth on ISL

    Then: The flow is not created because flow path should not be found

  • Unable to exceed bandwidth limit on ISL when updating a flow

    Given: Two active switches

    When: Create a flow with a valid bandwidth

    And: Update the flow with a bandwidth that exceeds available bandwidth on ISL

    Then: The flow is not updated because flow path should not be found

    And: Delete the flow

  • Able to exceed bandwidth limit on ISL when creating/updating a flow with ignore_bandwidth=true

    Given: Two active switches

    When: Create a flow with a bandwidth that exceeds available bandwidth on ISL (ignore_bandwidth=true)

    Then: Available bandwidth on ISLs is not changed in accordance with flow maximum bandwidth

    When: Update the flow with a bandwidth that exceeds available bandwidth on ISL (ignore_bandwidth = true)

    Then: The flow is successfully updated and has 'Up' status

    And: Available bandwidth on ISLs is not changed in accordance with new flow maximum bandwidth

    And: Delete the flow

  • Able to update bandwidth to maximum link speed without using alternate links

    Given: Two active neighboring switches

    When: Create a flow with a valid small bandwidth

    Then: Only one link is involved in flow path

    When: Update flow bandwidth to maximum link speed

    Then: The flow is successfully updated and has 'Up' status

    And: The same path is used by updated flow

    And: Delete the flow

AutoRerouteV2

Verify different cases when Kilda is supposed to automatically reroute certain flow(s).

  • Flow is rerouted when one of the flow ISLs fails

    Given: A flow with one alternative path at least

    When: Fail a flow ISL (bring switch port down)

    Then: The flow was rerouted after reroute timeout

    And: Revive the ISL back (bring switch port up) and delete the flow

  • Flow goes to 'Down' status when one of the flow ISLs fails and there is no ability to reroute

    Given: A flow without alternative paths

    When: One of the flow ISLs goes down

    Then: The flow becomes 'Down'

    When: ISL goes back up

    Then: The flow becomes 'Up'

    And: Restore topology to the original state, remove the flow

  • Flow is rerouted when an intermediate switch is disconnected

    Given: An intermediate-switch flow with one alternative path at least

    When: An intermediate switch is disconnected

    Then: All ISLs going through the intermediate switch are 'FAILED'

    And: The flow was rerouted after reroute timeout

    And: Connect the intermediate switch back and delete the flow

  • Flow goes to 'Down' status when single switch is disconnected (single-switch flow)

    Given: Single-switch flow

    When: The single switch is disconnected

    Then: The flow becomes 'Down'

    When: The single switch is connected back

    Then: The flow becomes 'Up'

    And: Remove the flow

  • Flow goes to 'Down' status when source switch is disconnected (no-intermediate-switch flow)

    Given: No-intermediate-switch flow

    When: The source switch is disconnected

    Then: The flow becomes 'Down'

    When: The source switch is connected back

    Then: The flow becomes 'Up'

    And: Remove the flow

  • Flow goes to 'Down' status when destination switch is disconnected (no-intermediate-switch flow)

    Given: No-intermediate-switch flow

    When: The destination switch is disconnected

    Then: The flow becomes 'Down'

    When: The destination switch is connected back

    Then: The flow becomes 'Up'

    And: Remove the flow

  • Flow goes to 'Down' status when source switch is disconnected (intermediate-switch flow)

    Given: Intermediate-switch flow

    When: The source switch is disconnected

    Then: The flow becomes 'Down'

    When: The source switch is connected back

    Then: The flow becomes 'Up'

    And: Remove the flow

  • Flow goes to 'Down' status when destination switch is disconnected (intermediate-switch flow)

    Given: Intermediate-switch flow

    When: The destination switch is disconnected

    Then: The flow becomes 'Down'

    When: The destination switch is connected back

    Then: The flow becomes 'Up'

    And: Remove the flow

  • Flow goes to 'Down' status when an intermediate switch is disconnected and there is no ability to reroute [0]

    Given: An intermediate-switch flow without alternative paths

    When: The intermediate switch is disconnected

    Then: The flow becomes 'Down'

    When: Set flowsRerouteOnIslDiscovery=true

    And: Connect the intermediate switch back

    Then: The flow is Up

    And: Restore topology to the original state, remove the flow, reset toggles

  • Flow goes to 'Down' status when an intermediate switch is disconnected and there is no ability to reroute [1]

    Given: An intermediate-switch flow without alternative paths

    When: The intermediate switch is disconnected

    Then: The flow becomes 'Down'

    When: Set flowsRerouteOnIslDiscovery=false

    And: Connect the intermediate switch back

    Then: The flow is Down

    And: Restore topology to the original state, remove the flow, reset toggles

  • Flow in 'Down' status is rerouted when discovering a new ISL

    Given: An intermediate-switch flow with one alternative path at least

    When: Bring all ports down on the source switch that are involved in the current and alternative paths

    Then: The flow goes to 'Down' status

    When: Bring all ports up on the source switch that are involved in the alternative paths

    Then: The flow goes to 'Up' status

    And: The flow was rerouted

    And: Bring port involved in the original path up and delete the flow

  • Flow in 'Up' status is not rerouted when discovering a new ISL and more preferable path is available

    Given: A flow with one alternative path at least

    And: Make the current flow path less preferable than others

    When: One of the links not used by flow goes down

    Then: Link status becomes 'FAILED'

    When: Failed link goes up

    Then: Link status becomes 'DISCOVERED'

    And: The flow is not rerouted and doesn't use more preferable path

    And: Delete the flow

  • Flow in 'Up' status is not rerouted when connecting a new switch and more preferable path is available

    Given: A flow with one alternative path at least

    And: Make the current flow path less preferable than others

    When: Disconnect one of the switches not used by flow

    Then: The switch is really disconnected from the controller

    When: Connect the switch back to the controller

    Then: The switch is really connected to the controller

    And: The flow is not rerouted and doesn't use more preferable path

    And: Delete the flow

  • Flow is not rerouted when one of the flow ports goes down

    Given: An intermediate-switch flow with one alternative path at least

    And: Make the current flow path less preferable than others

    When: Bring the flow port down on the source switch

    Then: The flow is not rerouted

    When: Bring the flow port down on the destination switch

    Then: The flow is not rerouted

    And: Bring flow ports up and delete the flow

  • System doesn't reroute flow to a path with not enough bandwidth available

    Given: A flow with alt path available

    And: Bring all ports down on the source switch that are not involved in the current and alternative paths

    When: Make alt path ISLs to have not enough bandwidth to handle the flow

    And: Break isl on the main path(bring port down on the source switch) to init auto reroute

    Then: Flow state is changed to DOWN

    And: Flow is not rerouted

    And: Cleanup: Restore topology, delete flow and reset costs/bandwidth

AutoReroute

Verify different cases when Kilda is supposed to automatically reroute certain flow(s).

  • Flow is rerouted when one of the flow ISLs fails

    Given: A flow with one alternative path at least

    When: Fail a flow ISL (bring switch port down)

    Then: The flow was rerouted after reroute timeout

    And: Revive the ISL back (bring switch port up) and delete the flow

  • Flow goes to 'Down' status when one of the flow ISLs fails and there is no ability to reroute

    Given: A flow without alternative paths

    When: One of the flow ISLs goes down

    Then: The flow becomes 'Down'

    When: ISL goes back up

    Then: The flow becomes 'Up'

    And: Restore topology to the original state, remove the flow

  • Flow is rerouted when an intermediate switch is disconnected

    Given: An intermediate-switch flow with one alternative path at least

    When: An intermediate switch is disconnected

    Then: All ISLs going through the intermediate switch are 'FAILED'

    And: The flow was rerouted after reroute timeout

    And: Connect the intermediate switch back and delete the flow

  • Flow goes to 'Down' status when single switch is disconnected (single-switch flow)

    Given: Single-switch flow

    When: The single switch is disconnected

    Then: The flow becomes 'Down'

    When: The single switch is connected back

    Then: The flow becomes 'Up'

    And: Remove the flow

  • Flow goes to 'Down' status when source switch is disconnected (no-intermediate-switch flow)

    Given: No-intermediate-switch flow

    When: The source switch is disconnected

    Then: The flow becomes 'Down'

    When: The source switch is connected back

    Then: The flow becomes 'Up'

    And: Remove the flow

  • Flow goes to 'Down' status when destination switch is disconnected (no-intermediate-switch flow)

    Given: No-intermediate-switch flow

    When: The destination switch is disconnected

    Then: The flow becomes 'Down'

    When: The destination switch is connected back

    Then: The flow becomes 'Up'

    And: Remove the flow

  • Flow goes to 'Down' status when source switch is disconnected (intermediate-switch flow)

    Given: Intermediate-switch flow

    When: The source switch is disconnected

    Then: The flow becomes 'Down'

    When: The source switch is connected back

    Then: The flow becomes 'Up'

    And: Remove the flow

  • Flow goes to 'Down' status when destination switch is disconnected (intermediate-switch flow)

    Given: Intermediate-switch flow

    When: The destination switch is disconnected

    Then: The flow becomes 'Down'

    When: The destination switch is connected back

    Then: The flow becomes 'Up'

    And: Remove the flow

  • Flow goes to 'Down' status when an intermediate switch is disconnected and there is no ability to reroute [0]

    Given: An intermediate-switch flow without alternative paths

    When: The intermediate switch is disconnected

    Then: The flow becomes 'Down'

    When: Set flowsRerouteOnIslDiscovery=true

    And: Connect the intermediate switch back

    Then: The flow is Up

    And: Restore topology to the original state, remove the flow, reset toggles

  • Flow goes to 'Down' status when an intermediate switch is disconnected and there is no ability to reroute [1]

    Given: An intermediate-switch flow without alternative paths

    When: The intermediate switch is disconnected

    Then: The flow becomes 'Down'

    When: Set flowsRerouteOnIslDiscovery=false

    And: Connect the intermediate switch back

    Then: The flow is Down

    And: Restore topology to the original state, remove the flow, reset toggles

  • Flow in 'Down' status is rerouted when discovering a new ISL

    Given: An intermediate-switch flow with one alternative path at least

    When: Bring all ports down on the source switch that are involved in the current and alternative paths

    Then: The flow goes to 'Down' status

    When: Bring all ports up on the source switch that are involved in the alternative paths

    Then: The flow goes to 'Up' status

    And: The flow was rerouted

    And: Bring port involved in the original path up and delete the flow

  • Flow in 'Up' status is not rerouted when discovering a new ISL and more preferable path is available

    Given: A flow with one alternative path at least

    And: Make the current flow path less preferable than others

    When: One of the links not used by flow goes down

    Then: Link status becomes 'FAILED'

    When: Failed link goes up

    Then: Link status becomes 'DISCOVERED'

    And: The flow is not rerouted and doesn't use more preferable path

    And: Delete the flow

  • Flow in 'Up' status is not rerouted when connecting a new switch and more preferable path is available

    Given: A flow with one alternative path at least

    And: Make the current flow path less preferable than others

    When: Disconnect one of the switches not used by flow

    Then: The switch is really disconnected from the controller

    When: Connect the switch back to the controller

    Then: The switch is really connected to the controller

    And: The flow is not rerouted and doesn't use more preferable path

    And: Delete the flow

  • Flow is not rerouted when one of the flow ports goes down

    Given: An intermediate-switch flow with one alternative path at least

    And: Make the current flow path less preferable than others

    When: Bring the flow port down on the source switch

    Then: The flow is not rerouted

    When: Bring the flow port down on the destination switch

    Then: The flow is not rerouted

    And: Bring flow ports up and delete the flow

  • System doesn't reroute flow to a path with not enough bandwidth available

    Given: A flow with alt path available

    And: Bring all ports down on the source switch that are not involved in the current and alternative paths

    When: Make alt path ISLs to have not enough bandwidth to handle the flow

    And: Break isl on the main path(bring port down on the source switch) to init auto reroute

    Then: Flow state is changed to DOWN

    And: Flow is not rerouted

    And: Cleanup: Restore topology, delete flow and reset costs/bandwidth

Configuration

Kilda configuration is a special lever that allows to change default flow encapsulation type while creating. This spec assumes that 'transit_vlan' is always default type

  • System takes into account default flow encapsulation type while creating a flow

    When: Create a flow without encapsulation type

    Then: Flow is created with current default encapsulation type(transit_vlan)

    When: Update default flow encapsulation type

    Then: Correct response is returned

    And: Kilda configuration is really updated

    When: Create a flow without encapsulation type

    Then: Flow is created with new default encapsulation type(vxlan)

    Cleanup: Restore default configuration and delete the flow

  • System doesn't allow to update kilda configuration with wrong flow encapsulation type

    When: Try to set wrong flow encapsulation type

    Then: Human readable error is returned

    Cleanup: Restore default configuration

  • System takes into account default multi table value while connecting a new switch

    Expect: Already added switch was discovered according to the multi table field in kilda configuration

    When: Disconnect one of the switches and remove it from DB. Pretend this switch never existed

    And: Update the multi table field in kilda configuration

    And: New switch connects

    Then: Switch is added with switch property according to the kilda configuration

    Cleanup: Revert system to origin state

Clone this wiki locally