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 p
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
>From "lib/mac-learning.h":
#define MAC_MAX 2048
--Justin
On Sep 7, 2011, at 11:57 PM, sachin sharma wrote:
> Hi Justin,
>
> In your reply to scalability question, you answered that we can modify the
> limit of 2K MAC addresses to any value by changing a #define at openvswitch
> cod
Hi Justin,
In your reply to scalability question, you answered that we can modify the
limit of 2K MAC addresses to any value by changing a #define at openvswitch
code.
Can you please let me know the file name where I can modify this limit?
Thanks & Regards,Sachin Sharma
> ? What is the sca
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
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 wrote:
> Right, I agree. I was just referring to the ability to use
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).
--
Yeah, I think that's right. Of course, Open vSwitch will be able to
support both eventually. But for large deployments, managing the edge
MAC tables, as well as tunneling and tagging rules (and any other
filtering or QoS policy) will almost certainly require a centralized
component. Also, as
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 wrote:
> On Sep 7, 201
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
> mor
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.
On
Thanks for the detailed write-up. I agree with what you've said earlier, so
I'll strip this down to your essential questions:
> • What is the scalability of a large OVS deployment and what
> abstraction measures are taken to avoid the “virtual” domain having CAM
> exhaustion risks on the
Hello,
I've the same kind of question ...
Moreover most of physical switch doesn't support more than 1024 Vlan...
Idealy, I'm thinking about a new approach : Build a virtual mesh network
between hypervisor and use Openvswitch (VM Connectivity) and openflow (deal
with network flow)
If you know a
Hi All,
I have a couple of questions concerning the scalability of OVS when used in
high-density virtualisation environments.
To elaborate futher, a bit of background.
Most virtualisation implementations do not go far enough in reality to
abstract the virtual from the physical network environme
14 matches
Mail list logo