[j-nsp] qfabric 1536k mac address?
Eugeniu Patrascu
eugen at imacandi.net
Thu Jan 2 16:45:29 EST 2014
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; NEXTHOP
> mac1,VLAN1; QFabric nodeA (remote VM attached on nodeA)
> mac2,VLAN1; QFabric nodeA
> mac3,VLAN1; QFabric nodeA
> .
> .
> mac65536,VLAN1;QFabric nodeA
> mac65537,VLAN1; port P (locally attached VM)
> mac65538,VLAN1; port P
> mac65539,VLAN1; port P
> .
> .
> .
> mac128000,VLAN1;port P
> what'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
More information about the juniper-nsp
mailing list