[c-nsp] MSDP and my limited knowledge question

[Adam Vitkovsky]

It appears that the IGMP DF will not begin the PIM RP register process if
the source of the m-cast is not on a directly connected subnet.

I guess you need to trick the router into believing that the source is on a
local subnet -like NAT the source IP to 192.168.1.2 on the linux box -you
can than translate it back to 10.10.10.1 on the router.


adam
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mihai Tanasescu
Sent: Wednesday, September 05, 2012 10:09 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] MSDP and my limited knowledge question

Hi,

On 9/4/12 11:18 AM, Phil Mayers wrote:
> On 09/03/2012 07:12 PM, Mihai Tanasescu wrote:
>
>> b) if I put:
>> 10.10.10.1/29 or /32 configured on S on a Loopback interface and on 
>> C4900:
>> ip route 10.10.10.0 255.255.255.240 192.168.1.2
>
> So, to be clear, you're doing this i.e. trying to source the multicast 
> from a "virtual" IP:
>
> Linux:
>
> ip addr add 192.168.1.2/24 dev eth0
> ip addr add 10.10.10.1/23 dev lo
> send-multicast --source 10.10.10.1 --group 233.x.x.x
Yes, this is what I am trying to do (or am really doing in fact).

>
> Cisco:
>
> int Vlan123
>   ip address 192.168.1.1 255.255.255.0
>   ip pim sparse-mode
> ip route 10.10.10.1 255.255.255.255 192.168.1.2
>
> I don't think this will work. The c4900 isn't a PIM DF for 10.10.10.1, 
> so won't send PIM register packets (or MSDP advertisments).
Yeap. Didn't think about it in the beginning but after reading all these
messages and going back to the multicast theory...this seems to be the
issue.

>
> You could try adding the 10-net as a "secondary"
>
> int Vlan123
>   ip address 192.168.1.1 255.255.255.0
>   ip address 10.10.10.2 255.255.255.248 secondary
>   ip pim sparse-mode
>
> Linux by default will respond to ARP packets for any of its IPs on all 
> interfaces, so this should in theory work.
That I could also trick via arp proxy if it does not happen.
>
> Another alternative is the "proxy-register" argument, but that's only 
> available in dense mode:
>
>   ip pim dense-mode proxy-register [list x | route-map y]
>
> I wonder if the multicast stub-routing functionality will trick the 
> 4900 into being the DF?
>
> Otherwise, you'll have to run a PIM SM routing protocol on the Linux 
> box, and trust me - you don't want to do that.
I could try running XORP :) This is an experimental setup and is more a 
lab thing.
The question is..would it work to have both PIM SM and the Source on the 
same box ? (from a concept point of view..the process handling PIM SM 
would not really receive the multicast stream if it's internally source 
on the same box, no ?)

--
mihai
> _______________________________________________
> 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/