Yeah that feature is only in OpenSolaris. Once S10 goes away, I'm sure a lot of the VSW infrastructure will leverage Crossbow, which changes things and makes networking easier in virtualized environments.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Virtualization Architect and Consultant Web: http://unixconsole.blogspot.com E-Mail: [email protected] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ________________________________ From: Steffen Weiberle <[email protected]> To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Sent: Mon, October 4, 2010 11:44:32 AM Subject: Re: [ldoms-discuss] Network related questions concerning vsw spanning tree The design document at http://hub.opensolaris.org/bin/view/Project+rbridges/ states that the bridging support would be responsible for loop detection. However, at this time it does not do so. So care should be taken if enabling this non-default feature in a domain. Steffen On 10/04/10 11:52, Steffen Weiberle wrote: I am not a certified network engineer, however, as Octave says, only one NIC can be attached to a vswitch. Thus there is no L2 forwarding of broadcasts in current domains, only layer 3, via IP forwarding. As said, that would involve a different MAC address. > >With the bridging bridging work that is in progress (or may be completed) on >Nevada (don't know the current state), it would be possible for a domain to >forward a broadcast. Only then could an ethernet frame sent in on one >interface >actually come out on another. Not sure if that would require the bridging >framework to do loop detection. I would think that is not an LDom function at >that point--the forwarding is being done as a service higher up. > >Steffen > >On 10/04/10 10:53, Octave Orgeron wrote: >Hi, >> >>I could be wrong about this, but my understanding of the VSW implementation >>is >>that it can only be attached to one physical NIC, VNIC (with Crossbow), or >>Link >>Aggregation to run upon. As a result, there shouldn't be an issue of a loop >>from >>that end. Now in the case of using IPMP in the guest domains where you have >>two >>separate VSWs that are attached to their own physical NIC on the same >>network, >>you won't have a loop either as the MAC addresses of those physical links are >>different. So again, no looping happening. >> >>Now is it possible to connect multiple VSWs together? Yes it is, but it >>requires >>an I/O domain to act as a router between them for traffic to be routed. >>Otherwise, it would be no different than a multi-homed server connected to >>multiple networks, but providing no routing between them. >> >> >>It is important to understand that the VSW is a dumb layer-2 switch, it's >>like >>going to Best Buy and getting a cheap Linksys, Netgear, or DLink switch. The >>big >>difference is that you're not limited on the number of ports, no special >>management features, and it's at the speed of memory and LDCs. So unlike >>VMware >>which tries to emulated a switch with ports and settings, VSWs are much >>simpler. >> >>If you want to understand it better, probably a good place to look is the >>UltraSPARC Hypervisor API document on our community site which talks about >>some >>of the low-level functionality happening there. >> >> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* >>Octave J. Orgeron >>Solaris Virtualization Architect and Consultant >>Web: http://unixconsole.blogspot.com >>E-Mail: [email protected] >>*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* >> >> >> >> >> ________________________________ From: "[email protected]" <[email protected]> >>To: [email protected]; [email protected]; >>[email protected]; [email protected]; >>[email protected]; [email protected] >>Sent: Mon, October 4, 2010 6:28:46 AM >>Subject: [ldoms-discuss] Network related questions concerning vsw spanning tree >> >> >>Hi there thank you for your answers below. Still some questions: >> >>My concern regarding virtual switches is the fact that from a network >>perspective I don’t have control, but I am responsible if network attached >>servers cause network issues. >> >>Primary concern is the fact that in theory it is possible to create layer-2 >>loops with vswitches. Therefore I would like to know from Oracle/Sun what >>measures they have taken in order to avoid the creation of Layer-2 loops with >>virtual switches. I would like to have some documentation of Sun regarding >>the >>virtual network implementation within T5240. Please see the splendid vmware >>documentation reqarding “virtual networking concepts” for example. >> >> >>Here my requirements for virtual switch implementations within servers: >> >>-virtual switch isolation is required. It should not be possible to connect 2 >>or >>more virtual switches in the same server with each other. What mechanisms are >>in >>place on the T5240 to prevent this? >>-suppose that a virtual switch has 2 fysical uplinks, what mechanisms are in >>place to prevent the forwarding of a frame coming in on >> >>uplink1 to uplink2 (thereby creating a layer-2 loop) >> >>It would be apriciated, for our network guys to get a satisfied answer for >this. >> >>Thanks in adv >> >>Anne Adema >> >>Martin Qoute:” >> >> >>Hi, >> >>For a PoC we're running with LDOMs 1.3 and LDOMs 2.0 I have some questions >>that >>hopefully someone can help me with. We're using Solaris 10 9/10 (u9) for >>control/service domain and guest domains. >> >>1. Does the vswitch participate in Spanning-tree? >> If yes, can this be disabled? >> Any differences for LDOMs 1.3 and 2.0 here? >>No idea, I never observed spanning- tree behaviour of vswitches >> >> >> >> >>2. How can the bandwidth that a VNIC consumes be limited? >> (Case: we're creating multiple non-global zones in 1 LDOM guest and >> want to prevent that one non-global zone can take up all bandwidth for a >> single VNIC). >>OTOH no way to do this in an I/O domain only without Crossbow. >> >> >> >> >>3. How can we configure "IP Multipathing" for the vswitch with LDOMs 1.3? >> I know LDOMs 2.0 has this capability... >>Question: do you want to connect a guest redundantly to the outside world or >>do >>you want to connect whole vswitch redundantly to the outside world? >> >> >> >> >>4. Using VLAN tagging on the vswitch, van I assign one VLAN to a VNIC in a >> guest domain? So that there's a VLAN between the vswitch and the guest, >> accessible as a VNIC from the guest? >>Yes. IIRC possible since v1.2, described in the slides on LDOMs >>under https://sunspace.sfbay.sun.com/x/c9VnDg (sorry only accessible from the >>Oracle intranet) >> >>“ >> >>Stefan Quote”: >> >>1. Does the vswitch participate in Spanning-tree? >> If yes, can this be disabled? >> Any differences for LDOMs 1.3 and 2.0 here? >>No idea, I never observed spanning- tree behaviour of vswitches >> >>It doesn't have to. It can not be configured to create loops, so we don't >>need >>to spanning-tree to protect against them. Externally, it appears as a normal >>ethernet port, so the real switches at the other end of the cable can do >>their >>spanning tree stuff, if they're so inclined. >> >>Turning it off completly should'nt be supported on any switch. I assume you >>mean turning off the spanning tree checking before taking a port online. >>Cisco >>switches used to do this, and you could turn this off, as in "go online >>first, >>check later, then, if loop detected, take port offline". This would speed up >>the onlining of ports, but not disable spanning tree checking completely. >> >> >>2. How can the bandwidth that a VNIC consumes be limited? >> (Case: we're creating multiple non-global zones in 1 LDOM guest and >> want to prevent that one non-global zone can take up all bandwidth for a >> single VNIC). >>OTOH no way to do this in an I/O domain only without Crossbow. >> >>you'll need crossbow for that, as martin already said” >> >> >> >> >> ________________________________ _______________________________________________ ldoms-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
_______________________________________________ ldoms-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
