Network Virtualization using Extreme Fabric Connect

Network Virtualization Using Extreme Fabric Connect
© 2019 Extreme Networks, Inc. All rights reserved. 57
Tip
With today’s CPUs, the time it takes to perform these SPF runs is less significant than the
time it takes to program the switch hardware.
A further important property of SPB is that the path used by a multicast tree from a root node to a leaf
node will always match (be congruent with) the unicast path between those same nodes in the same
BVLAN. This is important to ensure that applications running over an L2 VSN service type (where some
traffic might get initially flooded as the user MAC addresses are learned within the VSN service on the end-
point BEBs) will never suffer from out-of-sequence packet delivery.
In both cases, the state of these shortest paths and trees is stored as MAC addresses in the BVLAN MAC
tables and does not need to change unless the SPB physical topology changes or an I-SID service, which
uses multicast-trees, is modified.
Tip
In terms of scalability, Extreme Networks VSP series switching platforms support hundreds
of thousands of MAC entries in the hardware FIB (Forwarding Information Base).
Caution
Check platform release notes for exact scaling limits around SPB multicast BMACs. These
are reported as maximum number of supported multicast streams when operating as a
BCB.
An IP routed L3 VSN (or IP Shortcuts) service type always and only leverages the first SPB primitive; that is
if only IP unicast routing is required. If, however, the L3 VSN has IP Multicast enabled, then the second
primitive will be used to efficiently deliver IP Multicast streams only to where IGMP receivers exist, within
that L3 VSN.
Tip
Each IP S,G (Source, Group) Multicast stream is allocated a dedicated I-SID (from a
reserved I-SID range beginning at decimal 16,000,001) for optimal delivery across the SPB
fabric.
In a traditional network design based on PIM-SM (or Draft Rosen over MPLS-VPNs),
dedicated IP Multicast forwarding (S.G) records are used, but these tables are much more
limited in size across any and all vendors’ platforms, which in turn severely limits the
overall IP multicast scaling of the network as a whole.
A L2 VSN service type will always combine both primitives. The first primitive is to deliver unicast traffic for
user-MACs which have already been MAC learned within the VSN. The second primitive is to deliver
broadcast, non-snooped multicast and unknown-unicasts on an I-SID tree, which will forward and replicate
these packets only towards the other BEBs which are also members of the same L2 VSN. In this case, there
will be as many I-SID trees as there are BEBs terminating that L2 VSN service.
Tip
It is the combination of I-SID and Nick-name of the BEB acting as root that makes an I-SID
multicast tree unique in the SPB fabric. BEBs participating in an L2 VSN therefore all use
the same I-SID, which was configured as part of the L2 VSN configuration.
If the L2 VSN has been enabled for IP Multicast (L2 IGMP snooping within the VSN), then L3 IP multicast
traffic will also be handled using dedicated multicast I-SID trees. In this case, a stream specific I-SID will be