Your right I May be incorrect let me look it up and see if we can find the 
answer.
He command reference says the ttl attribute sets the time to live on the 
message sent by the mapping agent.  224.0.0.4/24 is link local which is outside 
the range used by the mapping agent.  What happens when you debug IP mpacket on 
the hub?  
Sent from my iPhone

On 20/12/2012, at 6:14 PM, "Michael Davis - Webquor" <[email protected]> 
wrote:

> Auto RP mapping agent traffic had a ttl of 1.  You cannot change that.  Hub 
> must be MA.
> 
> Sent from my iPhone
> 
> On 20/12/2012, at 4:13 PM, "Baldeep Birdy" <[email protected]> wrote:
> 
>> So I've been spending a lot of time on multicasting and today was playing 
>> with the deployment of AutoRP within a FR Cloud. I have my RP at the hub 
>> site, with my MA deployed at a spoke. Straight away I ran into issues with 
>> my MA announcements, on 224.0.1.40, being sent to my other spoke routers, to 
>> the hub site no issues. Note, that this was intended to further cement my 
>> understanding of frame-relay concepts and also mcast. 
>> 
>> Now my thought process was that the 224.0.1.40 annoucements are not getting 
>> to my spoke, they are being sent to the hub who is not forwarding them on. I 
>> then remembered that these announcements are sent to your PIM neighbours 
>> only, and my initial thought was that enabling autorp listener on the hub 
>> would resolve the issue. Alas no, would like someone to explain this. 
>> 
>> Second though, ok I need to get the spokes to become neighbours, I 
>> configured frame-relay map ip statements, with the broadcast command, 
>> between my spokes but again no result. 
>> 
>> Final thought, setup a GRE tunnel between them and configure PIM on the 
>> tunnel, with the required static mroute to fix my RFP failure, result 
>> worked. 
>> 
>> So going back I'm now a little confused about points 1 and 2. Clearly I've 
>> got a gap in my theory. 
>> 
>> 1. AutoRP listener, causes the router to flood autorp messages within the 
>> environment, so why not from the hub down to spokes? I configured no ip 
>> split horizon on the interface thinking is it a split horizon issue, but 
>> this is for routing right? so a red herring?
>> 
>> 2. With the frame-relay map statements, why didn't my spokes become 
>> neighbours? I have broadcast statements so the packets would have been 
>> unicasted out? 
>> 
>> I've read that the MA SHOULD be placed at the hub, so it has full 
>> communication. Short of using a GRE tunnel is this my only option? There has 
>> to be an alternative, what am I missing. 
>> 
>> Thanks
>> Bal
>> 
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training, please 
>> visit www.ipexpert.com
>> 
>> Are you a CCNP or CCIE and looking for a job? Check out 
>> www.PlatinumPlacement.com
>> 
>> http://onlinestudylist.com/mailman/listinfo/ccie_rs
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please 
> visit www.ipexpert.com
> 
> Are you a CCNP or CCIE and looking for a job? Check out 
> www.PlatinumPlacement.com
> 
> http://onlinestudylist.com/mailman/listinfo/ccie_rs
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

http://onlinestudylist.com/mailman/listinfo/ccie_rs

Reply via email to