Hi, While anycast RP is better (redundancy is faster), it's not necessary: you can just use PIM-SM with BSR & 2 RPs with hash-mask distribution for the layer 3 redundancy.
By design, igmp snooping forwards all multicast traffic to mrouter ports (that is, all router interfaces with pim activated), so to stop useless traffic between the routers, it will be necessary to do something at the layer 2 level; you can remove some of this by using something like cisco's ip pim snooping dr-flood on the layer 2 part (on the receiving vlans). regards, Olivier > Hi > > What's your recipe to implement redundant multicast (stub) routing? > Let's think about the simplest scenario. We have 2 routers, R1 and R2 > and 3 ip networks. All 3 networks are directly connected to both > routers and the routers are performing unicast routing between > networks using VRRP as the redundancy protocol. Let's disregard L2 > redundancy here and assume it works. Same goes with igmp snoop. > > net1: 192.168.1.0/24, VRRP .254, R1 .1, R2 .2 > net2: 192.168.2.0/24, VRRP .254, R1 .1, R2 .2 > net3: 192.168.3.0/24, VRRP .254, R1 .1, R2 .2 > > Say multicast source is in net1 and receiver in net2. > > If I did not need redundancy in multicast, I would just configure all > interfaces on R1 as pim passive and it would (probably) work. But if I > want the multicast routing to be redundant, what should I do? > > If I add the R2 interfaces as pim passive, the multicast is forwarded > to net2 (and net3) twice because R1 and R2 do not know about each > other. I tested this. > If I configure all R1 and R2 interfaces as pim dense, the destination > receives multicast fine, but it is flooded between R1 and R3 2 or 3 > times (because pim dense floods the multicast to all pim neighbors and > R1 and R2 are pim neighbors in all 2 networks). So, core links are > unnecessarily consumed. I tested this, too. > > One choice could be to use pim sparse and configure R1 and R2 to be > anycast RPs using loopback interface and configure MSDP peering > between them. But given the simplicity of the topology, this seems > unnecessarily complex configuration. I have not tested this yet. > > Maybe MVR could be solution but I think it will cause stream > multiplication too. I have not tested MVR yet either. > > I would like to keep the recipe as vendor agnostic as possible. > > Thanks for help :) >
