Network Virtualization using Extreme Fabric Connect

Network Virtualization Using Extreme Fabric Connect
© 2019 Extreme Networks, Inc. All rights reserved. 96
Figure 47 illustrates at a high level how PIM Gateway interacts with a PIM-SM network. The first striking
difference is that on the Fabric Connect side, the PIM Gateway functionality is in reality running off one of
possibly many L3 VSNs or IP Shortcut service instances, whereas PIM-SM is almost never virtualized in
VRFs (except in Draft Rosen Multicast VPNs).
Note
It is also possible to have two (or more) L3 VSNs (or IP Shortcuts) service instances
interface via PIM Gateway to the same PIM-SM cloud, which would allow all those VSNs to
be able to forward IP multicast traffic to and from PIM. However, it is never efficient to
have the same multicast streams being forwarded over separate VSNs, potentially over
the same physical infrastructure. If users across different VSNs are to receive the same
multicast streams, a more efficient approach is to designate a single L3 VSN for the
Multicast and “leak” the multicast stream on the final access hop towards the receivers in
different VSNs using Multicast VLAN Registration (MVR) as explained in Inter VSN IP
Multicast on page 99.
MSDP runs as a TCP peering between the PIM Gateway Controller node and the PIM RP router and serves
two purposes. The first purpose is to extract all the information about PIM side sources from the PIM RP
and announce those same sources into the Fabric Connect IS-IS LSDB by using the appropriate TLV and
allocating to each source a dynamically allocated I-SID. Once knowledge of the PIM sources is available in
Fabric Connect, a receiver on a Fabric BEB can request for the I-SID multicast tree to be built all the way to
the designated PIM Gateway BEB node, which will then trigger a PIM Join on that same node into the PIM
cloud in order to start receiving the multicast stream from the PIM side.
Tip
The PIM Gateway BEB immediately has knowledge of the stream’s source IP (this was
extracted from the RP via MSDP), and therefore is able to initiate PIM S.G Joins directly
towards the PIM Router where the source is located.
However, making a Fabric Connect source available to PIM receivers requires a different approach. PIM
receivers can only join streams for which the PIM RP has knowledge of the source. Hence the second
purpose of MSDP is to prime the RP with information about fabric-side sources. Once this has happened, a
PIM Router where a receiver expresses the desire to join a fabric source will trigger the usual PIM-SM
mechanics whereby that router will initiate a chain of PIM *.G joins all the way to the RP. The RP, having
knowledge of the Fabric source (received from MSDP), will then trigger its own chain of PIM S.G joins all the
way towards the PIM Gateway BEB which, in turn, will then add itself to the multicast I-SID tree within
Fabric Connect in order to start receiving the stream. As usual, once the stream starts flowing and the last
hop PIM router can infer the source IP of the stream, this router will most likely initiate another chain of PIM
S.G joins this time directly towards the PIM Gateway BEB, so as to stop forwarding the stream via the RP,
which is inefficient.
It should be noted that, unlike with Fabric Connect, PIM requires an underlying unicast IP routing table to be
in place, without which it cannot operate. It is essential that PIM be able to look up in the IP routing table
routes corresponding to the active RP as well as every IP subnet corresponding to PIM sources. For fabric
sources it is therefore essential that the relevant IP subnets must have been redistributed, by the PIM
Gateway BEB, into whatever IP routing protocol is used in the PIM cloud (typically OSPF). The same is true
in the reverse direction and correct redistribution into IS-IS of PIM-side source IP subnets will also be
required for the PIM Gateway Controller function to allocate a PIM Gateway node for the PIM source. In
short, any deployment of PIM Gateway will require a correct redistribution of IP routes between the Fabric
and PIM clouds as detailed in ISIS IP Route Types and Protocol Preference on page 67.
In many cases it will be desirable to keep control of which multicast sources are made available between
the fabric and PIM clouds, rather than making all sources available in both directions, as would be the