Updated case proposal with the new name is included below.
Simnet - Simulated network device
Simulated network devices (simnet) are pseudo GLDv3 network devices that
aid in the creation of point-to-point network links on a system. They
are intended to be a testing resource for OpenSolaris developers.
Simnets should help in developing test suites that can run with minimal
network hardware to test protocols and codepaths that were previously
not possible to test on a single system. This case has two components:
the new 'simnet' pseudo GLDv3 network device driver and the changes in
dladm(1M) to create, modify and delete simnets.
Simnets are created by the administrator on a system using dladm(1M).
Simnets can be of type: Ethernet or WiFi and the type is specified at
the time of creation. When creating a new simnet device the simnet
driver uses a random MAC address and registers the device as a new MAC
on the system. Once created administrators can plumb IP, snoop and
create VLANs using the new simnet. In other words upon creation simnets
appear as regular Ethernet/WiFi hardware devices. Simnet instances
persist and survive reboot, unless created with the "temporary" option.
Initially new simnet devices have no peer link attached. No packets are
received from the device and all packets sent to the device are
silently discarded. In this configuration simnets are of limited to
no use. Simnets must have another simnet attached to simulate a
point-to-point link. In such a configuration packets transmitted on a
simnet are received at the other simnet and vice-versa, simulating a
full-duplex point-to-point link. Using a combination of such links one
can simulate a number of network configurations within a single system.
The point-to-point nature of the device allows us to write test software
that can send and capture packets at both the end-points and verify
network software without the distractions that arise from the need and
the use of actual network hardware.
Simnets are different from VNICs. Simnets are used to simulate
point-to-point links and are MAC-level objects that appear to consumers
as real Ethernet/WiFi devices. Therefore, you may create an aggregation
on top of a collection of simnets, while such a thing is not possible
with VNICs or the existing Etherstubs. Such a configuration would allow
the testing of aggregations (and LACP signaling) without having to set
up multiple physical point-to-point connections between two systems. A
VNIC on the other hand is created over an Etherstub or other existing
MAC-level objects (such as Simnets) to provide bandwidth control of
traffic on the underlying link. Etherstubs do not have MAC addresses
associated with them and are not suitable to simulate a single link.
The following dladm sub-commands are introduced by this case:
create-simnet [-t] [-m <media>] <link>
A new simnet device is created on the system with the given
linkname. Media can either be Ethernet (default) or WiFi.
modify-simnet [-t] [-p <peer>] <link>
Another simnet is associated as the peer link of an existing
simnet. If the -p option is not specified any existing peer
link associated with the simnet instance is removed.
delete-simnet [-t] <link>
Delete simnet instance from the system. If the simnet has
a peer simnet associated with it the command fails.
show-simnet [-pP] [-o <field>,...] [<link>]
Lists the existing simnets or when linkname is specified displays
the given simnet on the system. Output fields are: LINK, MEDIA,
MACADDRESS and OTHERLINK
Simnet instances are of data-link class 'DATALINK_CLASS_SIMNET' and the
output from 'dladm show-link' lists simnet instances as belonging to
class 'simnet'. 'dladm show-link' shows the simnet peer (if there is
one) in the 'OVER' field. Simnet instances are not included in the
output of 'dladm show-phys'. Create, modify and delete simnet operations
require sys_net_config privilege.
Simnets are expected to be used during network software development and
testing on OpenSolaris. To encourage use of simnets for testing this
case proposes project teams introduce new private data-link properties
in the simnet driver that modify or control the response from the device
to administrative action.
For example to simulate a WiFi scan the simnet driver introduces a new
_wl_esslist private property. Before performing a WiFi scan on a WiFi
simnet, the _wl_esslist property of the device can be initialized with
test values. Performing the WiFi scan on the simnet will return results
using the values set in _wl_esslist property. This case proposes to
introduce the following two private properties with a stability level of
Project Private and are listed below as examples. As the intended
usage is with testing scripts the stability level for the private
properties shouldn't be a problem. A future project might introduce more
interactive APIs in addition to or in place of the proposed properties.
_wl_esslist WiFi scan results. Comma separated essid and
signal strength pair to set a WiFi scan result.
This property can be set multiple times (max 10)
for multiple WiFi scan results.
_wl_connected Toggle to indicate the device is connected
to a WiFi access point.
Wifi apsects of simnets are intended for use by the NWAM team. Simnets
are currently in use by the RBridges team to test bridging and the TRILL
protocol. As simnets appear as MAC-level objects they can be used for
bridging. Using several point-to-point simnets testing multiple bridged
LANs running the TRILL protocol can be done on a single box.
----------- ------------
<red0>---<red1> | RBridge 1 | <blue0>---<blue1> | RBridge 2 | ....
----------- ------------
red0 and red1, blue0 and blue1 are simnets.
This case introduces simnets with a stability level of Uncommitted, the
private data-link properties for simnets are Project Private and the
release binding is Minor.
