[ovs-discuss] Scalability Questions in High-Density Virtualisation Environments

[Benoit ML]

Hello,

I'm permit to ask you, what's your network architecture ?  How many tunnel
?  Did you do a mesh ? centralised Vswitch ? And last but not least, how do
you do commutation between physical and virtual world ? ;)

For know, here, we have a centralised Vswitch  :
        - commutation between physical and virtual world
        - end point for all hypervisors GRE tunnels


Regards,


2011/10/1 Joseph Glanville <joseph.glanville at orionvm.com.au>

> I am using OVS to build logically seperated Layer 2 networks over the top
> of a Layer 3 network using GRE tunnels to create a fully connected mesh for
> each network.
>
> This works perfectly and is very scalable. I have had no issues creating
> pretty obscene numbers of GRE tunnels on a single host.
>
> With this setup the guest VM networks are completely abstracted from the
> physical underlying network (which in this case doesn't even support Layer 2
> Ethernet!)
>
> Due to the nature of the GRE tunnels being Layer 3, optimal routing is
> preserved and the implementation is efficient hinging on OVS being well
> behaved (which is seems to be)
>
>
> Joseph.
>
>
> On 8 September 2011 16:04, Justin Pettit <jpettit at nicira.com> wrote:
>
>> The plan is to support both models.
>>
>> --Justin
>>
>>
>> On Sep 7, 2011, at 10:54 PM, Holger Winkelmann wrote:
>>
>> > Sounds good to me too. To clarify, you 'just' Plan to support the
>> encapsulation format and control will be still the OF controller ?
>> >
>> > --
>> >
>> > Holger Winkelmann
>> > Travelping GmbH
>> > +49-171-5594745
>> >
>> > On 08.09.2011, at 07:36, Justin Pettit <jpettit at nicira.com> wrote:
>> >
>> >> Right, I agree.  I was just referring to the ability to use its UDP
>> tunneling format to get through devices that don't like GRE.  We're also
>> planning to support a mode where VXLAN is a virtual port, like GRE, and
>> traffic that is sent out it will be encapsulated (and decapsulated on
>> receive).
>> >>
>> >> --Justin
>> >>
>> >>
>> >> On Sep 7, 2011, at 10:03 PM, Nicky Fatr wrote:
>> >>
>> >>> Yes, VXLAN tunnel header is a good proposal, but for control plane
>> >>> there is serve limitation: it depend on physical network multicast for
>> >>> MAC learning. In OVS, central ovsdb controlled MAC address propagation
>> >>> is a better choice.
>> >>>
>> >>> On Wed, Sep 7, 2011 at 9:09 AM, Justin Pettit <jpettit at nicira.com>
>> wrote:
>> >>>> On Sep 7, 2011, at 9:01 AM, Nicky Fatr wrote:
>> >>>>
>> >>>>> I don't think that TRILL/802.1AQ L2 over L2 is a good option for
>> large
>> >>>>> scale deployment. L2 over L3 instead is more scalable, eliminating
>> >>>>> comlexity of physical network.
>> >>>>>
>> >>>>> maybe we can expect L2 over UDP in some future release, for UDP is
>> >>>>> more friendly than GRE in some networking configuration.
>> >>>>
>> >>>> You can already do L2-over-L3 with CAPWAP.  It doesn't support a
>> configurable context identifier (key), but a patch has been provided by
>> Valient Gough and Simon Horman that adds it.  We're also looking at
>> supporting VXLAN, which was recently announced:
>> >>>>
>> >>>>      http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-00
>> >>>>
>> >>>> --Justin
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >> _______________________________________________
>> >> discuss mailing list
>> >> discuss at openvswitch.org
>> >> http://openvswitch.org/mailman/listinfo/discuss
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss
>>
>
>
>
> --
> *
> Founder | Director | VP Research
> Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99
> 52 | Mobile: 0428 754 846
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
>


-- 
--
Benoit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20111004/e504bf67/attachment.html>