[j-nsp] qfabric 1536k mac address?

[giovanni rana]

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: eugen at imacandi.net
To: superburriccu at hotmail.com
CC: juniper-nsp at puck.nether.net

On Thu, Jan 2, 2014 at 11:18 PM, giovanni rana <superburriccu at hotmail.com> 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. ratio, but this is not about design, it's about understanding how and where those 1536k Mac addressees are indexed, or it is just marketing?

please take the  "The QFabric Architecture - Juniper Networks" document, go to page 21, figure 17. i got 2 nodes now, node A and node B. i got also 131072 VMs with unique MAC addresses in my single /15 subnet because i like it big, VMs' are equally splitted between the nodeA and nodeB, so 65536 VMs are attached on nodeA and 65536 on nodeB. Let's forget clusters, ESXi limitations and so on. 

the table on Qfabric nodeB is made like in the figure 17:MAC,VLAN; NEXTHOPmac1,VLAN1; QFabric nodeA (remote VM attached on nodeA)mac2,VLAN1; QFabric nodeA
mac3,VLAN1; QFabric nodeA ..mac65536,VLAN1;QFabric nodeAmac65537,VLAN1; port P (locally attached VM)
mac65538,VLAN1; port P mac65539,VLAN1; port P...mac128000,VLAN1;port Pwhat's next? the qfx3500 CAM is exhausted now, how can i handle mac128001....mac131072?
 

adding nodes or changing the number of VLAN's does not make me understand how can i overcome the 128K limitation, or better, i'm missing how this "information hiding" principle works. from the document, it seems that all the entries from mac1 to mac65536 which are all pointing to nodeA can be aggregated/merged all together, because they can point to a remote unique node instead to a local port, but this doesn't mean they take less entries (or less "space") in the mac address table compared to normal entries. 


It doesn't get exhausted. This is something you fail to understand: The control node keeps track of which MAC where it belongs and the switch will forward the packet to the spine if it does not know about the MAC locally. You only need to ensure that you don't go over 128.000 MAC addresses locally on the QFX switch, that's all.

Think of it like routing: when you don't have a more specific route to a destination you send all your packets to the default gateway and the default gateway will try to figure out where to send the packets.

Look again at the link I gave you previously and it's clearly explained there how it works.
Eugniu