This shows you the differences between two versions of the page.
snipets:solaris:net-etherstub [2012/09/21 10:32] sjorge |
snipets:solaris:net-etherstub [2014/10/09 22:02] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Etherstubs / Virtual Switches ====== | ||
- | ===== Introduction ===== | ||
- | Etherstubs seem to confuse some people. Things usually get cleared up when I compare the to vSwitches. | ||
- | |||
- | Take the following example:\\ | ||
- | {{ :snipets:solaris:etherstub-example.png?nolink|}} | ||
- | You have: | ||
- | * 1 reverse proxy to filter traffic and do loadbalancing | ||
- | * 2 applications servers | ||
- | * 2 database servers | ||
- | |||
- | 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: | ||
- | * **reduce the need for VLAN's,** this elminitating the extra complexity of your physical network. | ||
- | * **eliminate the traffic on the physical switch** | ||
- | * **security benifits**, the backend servers are not connected to the physical network. | ||
- | |||
- | Bellow I'll give some examples on how to create an etherstub and how to add vnics to it. | ||
- | |||
- | ===== Creating an etherstub ===== | ||
- | TODO | ||
- | |||
- | ===== Adding vnics to an etherstub ===== | ||
- | TODO | ||
- | |||
- | ===== Removing vnics from an etherstub ===== | ||
- | TODO | ||
- | |||
- | ===== Displaying all etherstubs ===== | ||
- | TODO | ||