EasyManuals Logo

Cisco Catalyst 3850 series User Manual

Cisco Catalyst 3850 series
424 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 #382 background imageLoading...
Page #382 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 20: 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 3.6E (Catalyst 3850 Switches)
358 OL-32598-01
IP Multicast Optimization: IP Multicast Load Splitting across Equal-Cost Paths
Overview of ECMP Multicast Load Splitting

Table of Contents

Questions and Answers:

Question and Answer IconNeed help?

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

Cisco Catalyst 3850 series Specifications

General IconGeneral
ModelCisco Catalyst 3850 Series
RAM4 GB
Flash Memory4 GB
Stacking Bandwidth480 Gbps
Device TypeSwitch
Enclosure TypeRack-mountable
Routing ProtocolOSPF, EIGRP, BGP, RIP
Remote Management ProtocolSNMP, CLI, HTTP, HTTPS
FeaturesQuality of Service (QoS)
StackingYes
Memory4 GB RAM
Operating SystemCisco IOS
Relative Humidity10 - 95% (non-condensing)
Power Supply OptionsAC or DC
Ports24 or 48 10/100/1000 Ethernet ports

Related product manuals