On the one hand, this looks pretty good. On the other hand, I find it
really unfortunate that we have to create yet another kind of virtual
interface in addition to etherstubs and VNICs. I think many customers
are going to be left wondering which one of these things they should use
and why.
Is it not possible that we could integrate the functionality (perhaps as
an additional option) to etherstubs or vnics? (I'm thinking of a kind
of "attach" or "link" command that might be used to link a pair of
etherstubs together, for example: dladm link-etherstub etherstub0
etherstub1, which could have much the same kind of result, although it
wouldn't necessarily support the WiFi semantics....)
-- Garrett
Rishi Srivatsavai wrote:
On behalf of the RBridges team I am requesting feedback
from the community on our plan to introduce support for
simulated links in OpenSolaris. The document included
in-line below introduces simlinks and is in the form of
a PSARC fast-track document.
Thanks,
Rishi
Simlinks
Simulated links (simlinks) 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. Simlinks
should help in developing testsuites that can run with minimal network
hardware and test protocols and codepaths that were previously not
possible to test on a single system. This case has two components: the
new 'simlink' pseudo GLDv3 network device driver and the changes in
dladm(1M) to create, manage and destroy simlinks.
Simlinks are created by the administrator on a system using dladm(1M).
Simlinks can be of type: Ethernet or WiFi and the type is specified at
the time of creation. When creating a new simlink device the simlink
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 simlink. In other words upon
creation simlinks appear as regular Ethernet/WiFi hardware devices.
Simlink instances persist and survive reboot, unless created with the
"temporary" option.
Initially new simlink devices have no endpoint attached. No packets are
received from the device and all packets sent to the device are silently
discarded. In this configuration simlinks are of limited to no use.
Simlinks must have another simlink attached as an endpoint to simulate a
point-to-point link. In such a configuration packets transmitted on a
simlink are received at the other simlink 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.
Simlinks are different from VNICs. Simlinks 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 simlinks, 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 simlinks) 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-simlink [-t] [-m <media>] <link>
A new simlink device is created on the system with the given
linkname. Media can either be Ethernet (default) or WiFi.
modify-simlink [-t] [-e <link>] <link>
An endpoint (another simlink) is associated with an existing
simlink device. If endpoint is not given, any existing
association with another simlink is removed.
delete-simlink [-t] <link>
Delete simlink device from the system. If the simlink has another
simlink attached as the end-point the command fails.
show-simlink [-pP] [-o <field>,...] [<link>]
Lists the existing simlinks or when linkname is specified displays
the given simlink on the system. Output fields are: LINK, MEDIA,
MACADDRESS and OTHERLINK
Simlink instances are of data-link class 'DATALINK_CLASS_SIMLINK' and
the output from 'dladm show-link' lists simlink instances as belonging
to class 'simlink'. 'dladm show-link' shows the simlink partner (if
there is one) in the 'OVER' field. Simlink instances are not included in
the output of 'dladm show-phys'. Create, modify and delete simlink
operations require sys_net_config privilege.
Simlinks are expected to be used during network software development and
testing on OpenSolaris. To encourage use of simlinks for testing this
case proposes project teams introduce new private data-link properties
in the simlink driver that modify or control the response from the
device to administrative action.
For example to simulate a WiFi scan the simlink driver introduces a new
_wl_esslist private property. Before performing a WiFi scan on a WiFi
simlink, the _wl_esslist property of the device can be initialized with
test values. Performing the WiFi scan on the simlink 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 separted essid and
signal stength 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 simlinks are intended for use by the NWAM team. Simlinks
are currently in use by the RBridges team to test bridging and the TRILL
protocol. As simlinks appear as MAC-level objects they can be used for
bridging. Using several point-to-point simlinks 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 simlinks.
This case introduces simlinks with a stability level of Committed, the
private data-link properties for simlinks are Project Private and the
release binding is Minor.
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
