Network Virtualization using Extreme Fabric Connect

Network Virtualization Using Extreme Fabric Connect
© 2019 Extreme Networks, Inc. All rights reserved. 98
role should the active RP fail. All this essentially means that when implementing PIM Gateway, it might be
necessary to provision MSDP peerings with more than one PIM router. In the figure, we are assuming that
two RPs exist.
Since this is a redundant design, we also have two PIM Controllers and two PIM Gateways. Each PIM
Gateway owns one interconnect into the PIM cloud and route redistribution is performed over these links in
both directions (IS-IS ➔ OSPF in this case). The PIM Gateway will thus typically be running OSPF over
the interconnect. Since both PIM Gateways will be redistributing IS-IS routes into OSPF and OSPF routes
into IS-IS, it is important that this redistribution be done properly and according to the guidelines detailed
in ISIS IP Route Types and Protocol Preference on page 67. Failure to do so could result in route reflection
whereby a PIM source IP route gets redistributed into IS-IS by one PIM Gateway and then redistributed
back to OSPF by the other PIM Gateway. This would not prevent PIM Gateway from operating but would
compromise the ability to load balance available streams across both interconnects.
Figure 48 Redundant PIM Gateway Deployment Model
Each PIM Controller should have MSDP peerings into both PIM RPs. This offers the most resilient design, as
it ensures that the PIM Gateway functionality can survive failure of one PIM Controller + one RP at both
ends. It is worth noting that the MSDP protocol was defined with the intent of interconnecting separate
PIM-SM clouds. Since each PIM cloud is in effect an OSPF Autonomous System, the use of BGP would often
go hand-in-hand with MSDP. MSDP is therefore able to leverage the BGP AS-path information in order to
avoid loops.
However, the typical use case of Fabric Connect PIM Gateway is unlikely to make use of BGP. In the
example at hand it is much easier to let the PIM Gateways redistribute directly between OSPF and IS-IS
instead of adding BGP to the recipe. The challenge is to ensure that a PIM Controller, when it learns about a
PIM source from one PIM RP, does not re-advertise that same source to the other PIM RP. To avoid this,
both MSDP peerings defined on each PIM Controller will need to be made part of the same MSDP peer-
group.
Tip
Extreme Networks PIM Controller can run MSDP with BGP. However, a simpler approach is
not to use BGP and use MSDP peer-groups instead.
Caution
If MSDP with BGP is used, a BGP peering will be required on the PIM Controller in order to
be able to inspect multicast sources against BGP path attributes. In practice, this will
require the PIM Controller function to be co-located on the PIM Gateway so that a single
eBGP peering can be terminated there.
From a control plane perspective, the PIM Controllers will learn about PIM sources from MSDP. The PIM
Controllers will then examine which of the available PIM Gateways are redistributing into IS-IS the relevant
source IP subnets for the VSN at hand (the PIM Controller can simply inspect its own copy of the IS-IS
LSDB). If more than one PIM Gateway is available as candidate, a hash will be applied to allocate the PIM