[148106] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Redundant multicast routing

daemon@ATHENA.MIT.EDU (Olivier Benghozi)
Tue Jan 3 11:10:17 2012

From: Olivier Benghozi <olivier.benghozi@wifirst.fr>
In-Reply-To: <CAE79DopeZEvK3+yiw3B=DXuM0ON2sxcoyq2Pf7cbofZhqnBdpw@mail.gmail.com>
Date: Tue, 3 Jan 2012 17:09:22 +0100
To: Mark Smith <markrefresh12@gmail.com>,
 NANOG list <NANOG@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

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
>=20
> 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.
>=20
> 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
>=20
> Say multicast source is in net1 and receiver in net2.
>=20
> 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?
>=20
> 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.
>=20
> 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.
>=20
> Maybe MVR could be solution but I think it will cause stream
> multiplication too. I have not tested MVR yet either.
>=20
> I would like to keep the recipe as vendor agnostic as possible.
>=20
> Thanks for help :)
>=20



home help back first fref pref prev next nref lref last post