[c-nsp] Multicast trickery

Wed Oct 21 03:41:25 EDT 2009

Dear All

Paul, thank you for your reply!

I will test some of this today.

What I am missing in my understanding of this is 2 major things.

How would I get the SVI toward the flooding multicast provider to know
what floods it is receiving? ip mroute? or does it learn when a
certain packet is recieved? Perhaps I have not waited long enough?
What would a static multicast route look like, all my attempts
indicate that I don not understand how it works :p

Best regards
Mattias Gyllenvarg
Omnitron

2009/10/20 Paul Cosgrove <paul.cosgrove.nsp at gmail.com>:
> 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/
>
>