All things related to multicast

[Zenon Mousmoulas <>]

On 24 Ιουλ 2008, at 4:10 ΠΜ, Greg Shepherd wrote:

On 7/23/08, Pekka Savola <> wrote:

On Wed, 23 Jul 2008, Zenon Mousmoulas wrote:

We have a client site that wants to receive multicast, but they want to limit traffic to specific groups. As is usual for most clients, they don't have their own PIM domain, but instead they rely on our national PIM domain (by use of GRNET's anycast RP).

The only easy way I've found to do this is by using a configuration that statically maps the few groups they want to the correct RP address, and everything else to a "fake" RP address, actually some interface of their own border router.

I don't know about that, but if the intent is also to limit receiving except from specific groups, maybe 'ip multicast boundary [acl]' would do it?

Pekka

Yes, the boundary statement would do it, but only after attracting the traffic. Using an RP-of-last-resort (as proposed) set to a loopback on the router then no joins propagate past the last hop router.

That is what I also thought, so I didn't pay any attention to this one. However I just tried it and, strangely enough, it does work! It does prevent PIM joins to propagate beyond the border interface: the next router won't show it in the OIFs of the particular mroute.

It even works for SSM: on 12.4 you can use an extended acl that is granular enough to specify S,G.

I still wonder why the RP-of-last -resort solution failed though. We didn't use a loopback for the fake RP but a real interface. Could this be related?

Btw, while googling for ip multicast boundary I came across this quite interesting Cisco presentation on the topic of multicast security:

http://www.surfnet.nl/Documents/boers.ppt

I feel indeed that we still have too little control today over multicast traffic. This is probably a good reason why many sites and admins still don't feel comfortable with multicast: they would like to enable it on the border with GRNET, but they are afraid it will saturate their internet connection. This is especially true for sites that don't enjoy the luxury of overprovisioned/uncongested links (>= 1 Gbps).

Anyway, sorry for going off-topic...

Thanks,

Z.