[c-nsp] MSDP and my limited knowledge question

[Mihai Tanasescu]

On 9/5/12 10:44 AM, Adam Vitkovsky wrote:
> 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.
I'll see what I can do.
The problem is that the other side (which is not under my control) takes 
a lot of time to change something in the setup and only the problematic 
multicast source subnet is current allowed.
I could make it directly connected on the interfaces between C4900 and 
Linux but I thought there was a way around it without adding another 
device in between at the moment when I'm just testing.

Thank you very much,
Mihai
>
>
> 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/
>