EasyManuals Logo

Cisco Catalyst 3650 User Manual

Cisco Catalyst 3650
384 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Page #344 background imageLoading...
Page #344 background image
For PIM-DM and bidir-PIM, configuring ECMP multicast load splitting with the ip multicast multipath
command is only effective in topologies where the equal-cost paths are not upstream PIM neighbors on the
same LAN, but rather neighbors on different LANs or point-to-point links.
Effect of ECMP Multicast Load Splitting on the PIM Assert Process in PIM-SM and PIM-SSM
There are also cases where ECMP multicast load splitting with the ip multicast multipath command can
become ineffective due to the PIM assert process taking over, even when using PIM-SM with (*, G) or (S,
G) forwarding or PIM-SSM with (S, G) forwarding.
The figure illustrates a sample topology that is used in this section to explain the effect of ECMP multicast
load splitting on the PIM assert process in PIM-SM and PIM-SSM.
Although the following illustration and example uses routers in the configuration, any device (router or
switch) can be used.
Note
Figure 19: ECMP Multicast Load Splitting and the PIM Assert Process in PIM-SM and PIM-SSM
In the topology illustrated in the figure, if both Device 2 and Device 5 are Cisco devices and are consistently
configured for ECMP multicast load splitting with the ip multicast multipath command, then load splitting
would continue to work as expected; that is, both devices would have Device 3 and Device 4 as equal-cost
next hops and would sort the list of equal-cost paths in the same way (by IP address). When applying the
multipath hash function, for each (S, G) or (*, G) state, they would choose the same RPF neighbor (either
Device 3 or Device 4) and send their PIM joins to this neighbor.
If Device 5 and Device 2 are inconsistently configured with the ip multicast multipath command, or if Device
5 is a third-party device, then Device 2 and Device 5 may choose different RPF neighbors for some (*, G) or
(S, G) states. For example Device 2 could choose Device 3 for a particular (S, G) state or Device 5 could
choose Device 4 for a particular (S, G) state. In this scenario, Device 3 and Device 4 would both start to
forward traffic for that state onto Gigabit Ethernet interface 1/0/0, see each other’s forwarded traffic, and--to
avoid traffic duplication--start the assert process. As a result, for that (S, G) state, the device with the higher
IP address for Gigabit Ethernet interface 1/0/0 would forward the traffic. However, both Device 2 and Device
5 would be tracking the winner of the assert election and would send their PIM joins for that state to this assert
winner, even if this assert winner is not the same device as the one that they calculated in their RPF selection.
IP Multicast Routing Configuration Guide, Cisco IOS XE Release 3SE (Catalyst 3650 Switches)
322 OL-29890-01
IP Multicast Optimization: IP Multicast Load Splitting across Equal-Cost Paths
Overview of ECMP Multicast Load Splitting

Table of Contents

Other manuals for Cisco Catalyst 3650

Questions and Answers:

Question and Answer IconNeed help?

Do you have a question about the Cisco Catalyst 3650 and is the answer not in the manual?

Cisco Catalyst 3650 Specifications

General IconGeneral
Switching Capacity160 Gbps
Uplink Interfaces4 x 1G SFP or 2 x 10G SFP+
Device TypeSwitch
Form FactorRack-mountable
LayerLayer 3
DRAM4 GB
Flash Memory4 GB
Operating SystemCisco IOS XE
ModelCatalyst 3650
Ports24 or 48 10/100/1000 Ethernet ports
StackingYes
Power over Ethernet (PoE)Yes
Power Supply Options350W AC
VLANs4094

Related product manuals