[c-nsp] Multicast trickery

[Paul Cosgrove]

Hi Mattias

If I understand your topology correctly, the configuration should be very
similar to what you would use for any other internal source.  The difference
in this case that the source in this case is the provider network, and being
untrusted requires additional precautions on the input interface (only).

Considering a conventional Anycast RP multicast topology for a moment, when
the multicast packets are received by the DR, the DR encapsulates the
packets as unicast register messages and sends them to the nearest RP for
that group.  The RP effectively converts the first register messages to a
source active message, and then sends the SA to each configured MSDP peer.
In this example the SA is originated because a register messages has been
received for a new source.  The register message is sent to that router
because it is a active RP for the group.

Since you are using BSR you have only one active RP for each group, and is
may be important which that is in this case.  Is your second C-RP is the
active RP for the group you are having problems with?  Tested a topology
with a combined DR and RP, some years ago.   It may work if you run PIM-SM
and the RP is the DR for the subnet, but if I recall correctly, behaviour
differed between different routers/software versions and it did not work
well/often.  You should be able to test this easily enough by debugging msdp
and pinging an unused multicast group from a router connected to your RP.
With pim-sm enabled on the RP's input interface, and the RP elected as DR,
you may still find that no SA is originated.

You could try to persuade your second provider to provide MSDP and BGP
information, but I guess you have already tried that approach.
Alternatively attach another router to your RP and have the provider present
the multicast stream on that.  As well as the bsr boundary, and acls to stop
pim (inc unicast pim), make sure you have pim register rate-limit applied.
You must also make sure that traffic to the auto rp groups is not permitted
into your network.  IP multicast boundary is useful.

The method in the link that Hans provided should also work, though I would
think it wise to test in a lab first if you are thinking of applying it to
one of your main C-RP routers; or apply it on another router entirely.  The
acl you mentioned will not stop multicast packets sent by the router on
which it is applied, and that is likely to be why multicast traffic is still
leaking through.  If this router is the RP for a particular multicast group,
when one of your sources begins sending to a group, the first packet the RP
router receives is as a unicast register message, which it decapsulates
before transmission. The path of the packet through the router is not the
same as for native multicast, since it is unicast to the RP and has to be
punted to the CPU; it may be that these decapsulated packets are not being
filtered.  If you have static RP definitions anywhere in your network,
traffic to groups without a configured RP might also be leaking out.  IP
multicast boundary may help.

You mentioned Anycast-RP, and using that with static RP definitions is quite
straightforward to configure and maintain, perhaps easier than you think.

Paul.

On Tue, Oct 20, 2009 at 6:03 PM, Wyatt Mattias Gyllenvarg <
wyatt.eliasson at gmail.com> wrote:

> Hi Hans
>
> I have set BSR-BORDER on the interface, so that should not be it.
>
> I want too run PIM-DM but as long as I send PIM-packets I can not.
>
> Anyone have a theory about the filter not biting?
> Im not at work now but it looks something like.
> Deny ip pim any any
> Deny ip any <multicast>
> Permit any any
>
> Best regards
> Mattias Gyllenvarg
>
> 2009/10/20 Hans Verkerk <HVerkerk at winitu.com>:
> > Hi,
> >
> > " If I run PIM-DM they call me in a hurry and tell me that my PIM
> > packets are disturbing the network." Maybe your BSR packets are
> > interfering with SP2's network, so include "ip pim bsr-border" on
> > interface facing SP2.
> >
> > PIM DM sources can be distributed as follows into MSDP:
> >
> > http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_msdp
> > _im_pim_sm_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp105549
> > 3
> >
> >
> > HTH,
> > Hans
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Wyatt Mattias
> > Gyllenvarg
> > Sent: Tuesday, October 20, 2009 6:23 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] Multicast trickery
> >
> > Hi All
> >
> > I am in need of pointers regarding a multicast configuration that does
> > not fit the models found online or in the literature I have at hand.
> >
> > The network is built on PIM-SM with 2 BSR-RP routers (core1 and core2).
> >
> > At Core1 we receive a set of Multicast streams from IPTV-Provider 1
> > via PIM-SM and MSDP, this works fine.
> > The mroutes are announced to Core2 via MSDP, works fine.
> > At Core2 we receive a set of Multicasts that are flooded too us, this
> > is the problem source.
> >
> > I can't distribute this in MSDP if I run PIM-SM.
> > If I run PIM-DM they call me in a hurry and tell me that my PIM
> > packets are disturbing the network.
> >  - So long I have not been able to filter out PIM packets with
> > outbound acls on the SVI.
> > I have used IP IGMP unidirectional...  but that broke MSDP between the
> > cores.
> > Trying ip mroute gave me "invalid source address"
> >
> > How should I proceed too accept the multicast streams and inject them
> > into MDSP.
> >
> > My hope is that I will get to a point where I can use MSDP between
> > cores and ANYCAST my RPs.
> >
> > Best regards
> > Mattias Gyllenvarg
> > Omnitron
> > Sweden
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>