On Friday, January 03, 2014 09:09:53 AM giovanni rana wrote:
> Well, thanks a lot eugeniu, got it now, it's not easy to
> change your mind about L2 mechanism because they haven't
> been changed for years within standard switches.
Tell me what you think when you come across Cisco's EVC
solution :
Well, thanks a lot eugeniu, got it now, it's not easy to change your mind about
L2 mechanism because they haven't been changed for years within standard
switches.
Date: Thu, 2 Jan 2014 23:45:29 +0200
Subject: Re: [j-nsp] qfabric 1536k mac address?
From: eu...@imacandi.net
To: superburri...@hot
On Thu, Jan 2, 2014 at 11:18 PM, giovanni rana wrote:
> Ahahah that was just an example ;)) And of course i can put another
> standard L2 switch between the hosts and the qfx3500 which aggregates all
> the hosts and goes to the qfx3500 with a single 10ge port, if I don't mind
> about oversubscr.
Ahahah that was just an example ;)) And of course i can put another standard L2
switch between the hosts and the qfx3500 which aggregates all the hosts and
goes to the qfx3500 with a single 10ge port, if I don't mind about oversubscr.
ratio, but this is not about design, it's about understand
On Thu, Jan 2, 2014 at 8:10 PM, giovanni rana wrote:
> I do, but how big is my DC is not relevant, like being flat or non flat
> does not matter...Since the data sheet clearly says 1.536.000 Mac addresses
> are supported, I need to understand if we are talking of unique Mac
> addresses or that's a
I do, but how big is my DC is not relevant, like being flat or non flat does
not matter...Since the data sheet clearly says 1.536.000 Mac addresses are
supported, I need to understand if we are talking of unique Mac addresses or
that's a number made by using mac-vlan pairs (and so Overlapping MA
If the QFabric controllers can do anything it's scale up the number of MACs
that can be learned across the fabric. Their solution was novel before SDN and
I guess it's to their credit that they are not trying to market the QFabric
that way now ;)
rgds,
--r
On Jan 2, 2014, at 9:10 AM, E
On Thu, Jan 2, 2014 at 4:20 PM, giovanni rana wrote:
> Even in the case you mentioned the node shall be able to keep a table
> where there's an index Made by 1536k entries. I can understand that some
> memory can be saved by using a vpls style approach, but if I got 1536k VMs
> with unique and Mac
Even in the case you mentioned the node shall be able to keep a table where
there's an index Made by 1536k entries. I can understand that some memory can
be saved by using a vpls style approach, but if I got 1536k VMs with unique and
Mac addresses I'm still able to manage them via qfabric? Publi
At a guess I'd say it's because in Q-Fabric, the "MAC-learning" is performed by
a similar to a VPLS instance per VLAN rather than traditional per-switch CAM
tables.
I imagine this allows for better scalability/optimisation.
The switch CAM would then only need to worry about L2-adjacent QF nod
10 matches
Mail list logo
