Network Virtualization using Extreme Fabric Connect

Network Virtualization Using Extreme Fabric Connect
© 2019 Extreme Networks, Inc. All rights reserved. 99
source to one of the PIM Gateways. The hash ensures a distribution of PIM sources across all the available
PIM Gateways. The selected PIM Gateway for a given PIM source will then be responsible for advertising
and making available the PIM multicast stream into the IS-IS LSDB using the appropriate multicast TLV. So,
for PIM sources it is the PIM Controller that determines the allocation of PIM Gateway.
In the reverse direction, for fabric sources, it is IP routing in the PIM cloud that determines the PIM Gateway
to use. Once a PIM S.G join sequence is initiated on the PIM side for a fabric source, these PIM Joins will be
forwarded along the reverse path towards the IP subnet of the fabric source, using the IP routing tables of
the PIM routers to determine the path. The path will inevitably lead to one or the other PIM Gateway and
this will determine which PIM Gateway will then be used to obtain the multicast stream from the Fabric
source.
PIM Gateway with PIM-SSM
PIM-SSM is a simplified version of PIM-SM for Source Specific Multicast (SSM). The premise of PIM-SSM is
that the multicast receiver application needs to know not just the Class D Group address it wishes to join
but also the source IP of the sender, which means IGMPv3 must be used with PIM-SSM.
This means that the function of the PIM RP is no longer needed, as the PIM router where the receiver is
located can simply issue PIM S.G joins directly towards the requested source IP.
Use of Fabric Connect PIM Gateway with a PIM-SSM network is also possible and, in some ways, is simpler
since there is no need to use MSDP because there is no RP in the PIM-SSM network.
Provided that the Fabric source IP subnets have been correctly redistributed into the PIM-SSM IGP
(typically OSPF) by the PIM Gateways, in one direction things will just work out of the box. A PIM-SSM
router issuing PIM S.G joins towards a fabric source will end up hitting one of the PIM Gateway BEBs, which
can then request the Fabric multicast stream and forward it into the PIM-SSM network.
However, in the reverse direction, the Fabric IS-IS LSDB needs to be aware of the PIM-SSM sources before
any BEB can add itself as a receiver. The information about PIM sources can no longer be obtained from
MSDP, and will therefore need to be statically provisioned instead. To this effect, on the PIM Controller, it is
possible to manually enter multiple source bindings each of which will have to include the class D group
address as well as the PIM-SSM source subnet. Once this information has been entered the PIM Controller
will select an available PIM Gateway, where the given source IP subnet can be reached from, and will
allocate the PIM-SSM source to it.
Inter VSN IP Multicast
Extreme’s Fabric Connect delivers unparalleled virtualization of IP Multicast. No other networking
technology is able to virtualize IP Multicast into multiple separate logical (VSN) domains with the same
simplicity, efficiency, and scalability. And no other networking technology is able to define VSNs defined
exclusively for IP Multicast transport and where no IP unicast forwarding and addressing is even required.
It is therefore extremely easy to create separate “tenant” VSNs where each VSN can be activated for
separate IP Multicast applications. Different VSNs are completely separate and only use the same Ethernet
Fabric infrastructure. Across different L3 VSNs (and L2 VSNs), not only can the same IP unicast addressing
be used within each VSN, but also the multicast Groups addresses can be the same.
In some environments, it is sometimes desired to have a flexible approach where different VSNs can be
kept separate for unicast connectivity but are allowed to share a selection of IP Multicast streams from a
different VSN. Or, alternatively, the VSNs are interconnected via a firewall to allow some unicast traffic, but
it would not make any sense to force the IP multicast traffic across that same firewall.
Possible examples would include a video surveillance deployment, fully contained and virtualized within its
own L3 VSN, within which video recorders and security screens operate with IP Multicast, but with some
security personnel located in a different VSN (in order to reach other different applications) requiring