- personal
- snipets
- openbsd
- linux
- solaris
- configuration
This is an old revision of the document!
Etherstubs seem to confuse some people. Things usually get cleared up when I compare the to vSwitches.
Take the following example:
You have:
Say you run each component in either zone or KVM instance, you can then give each a vnic that is linked to your main network interface. But will put more traffic on your physical switch and also open up some security issues. You could ofcourse use VLAN's but that again adds more administrative complexity.
To solve this you can use an etherstub with vnics for the database and application servers. The proxy will also have a vnic on the etherstub and one on the physical interface.
This approuce will:
Bellow I'll give some examples on how to create an etherstub and how to add vnics to it.
dladm create-etherstub vSwitch0
Please see VNIC's and vlanning, just provide the name of the etherstub instead of the physical interface/aggr/… after the -l
flag.
dladm show-etherstub
dladm delete-etherstub vSwitch0
Here is an example for the setup displayed above. This creates the etherstub, 2 vnics for the proxy vm, 1 vnic for each database and application servers.
dladm create-etherstub vsw0 dladm create-vnic -l trunk0 vpr0 dladm create-vnic -l vsw0 vpr1 dladm create-vnic -l vsw0 zdb0 dladm create-vnic -l vsw0 zdb1 dladm create-vnic -l vsw0 zapp0 dladm create-vnic -l vsw0 zapp1 dladm set-linkprop -p protection=mac-nospoof vpr0 dladm set-linkprop -p protection=mac-nospoof vpr1 dladm set-linkprop -p protection=mac-nospoof zdb0 dladm set-linkprop -p protection=mac-nospoof zdb1 dladm set-linkprop -p protection=mac-nospoof zapp0 dladm set-linkprop -p protection=mac-nospoof zapp1