topology - Testbed Topology

Testbed topology representation.

A topology of a testbed captures what links are available between the testbed’s nodes. The link information then implies what type of topology is available.

class TopologyType

Bases: int, Enum

Supported topology types.

no_link = 0: A topology with no Traffic Generator.

one_link = 1: A topology with one physical link between the SUT node and the TG node.

two_links = 2: A topology with two physical links between the Sut node and the TG node.

default = 2: The default topology required by test cases if not specified otherwise.

classmethod get_from_value(value: int) → TopologyType

Get the corresponding instance from value.

Enums that don’t allow aliases don’t know which instance should be returned as there could be multiple valid instances. Except for the default value, TopologyType is a regular Enum. When getting an instance from value, we’re not interested in the default, since we already know the value, allowing us to remove the ambiguity.

__new__(value)

class Topology

Bases: object

Testbed topology.

The topology contains ports processed into ingress and egress ports. If there are no ports on a node, dummy ports (ports with no actual values) are stored. If there is only one link available, the ports of this link are stored as both ingress and egress ports.

The dummy ports shouldn’t be used. It’s up to DTSRunner to ensure no test case or suite requiring actual links is executed when the topology prohibits it and up to the developers to make sure that test cases not requiring any links don’t use any ports. Otherwise, the underlying methods using the ports will fail.

type

The type of the topology.