Re: PIM Dense mode and NBMA

From: Ivan (ivan@iip.net)
Date: Fri Nov 03 2006 - 06:05:28 ART


        You can run Auto-RP to get the network functional, but you would
have to violate the task that says "Do not use tunneling or static RP
assignments to accomplish this."

        The problem you'll see with Auto-RP if you're using sparse-dense
mode PIM or running autorp listener is that the Auto-RP groups
224.0.1.39 and 224.0.1.40 (mapping agent and candidate RP
advertisements) will be in dense mode. R5 is the hub of the frame relay
network for R3 and R4. When R5 receives a mapping agent advertisement
in from R3 it cannot pass it on to R4 because the incoming interface
would be the same as the outgoing interface. NMBA mode will not fix
this because NBMA mode only applies to sparse mode groups.

        What you could do to get the section functional is run
224.0.1.39 and 224.0.1.40 as sparse. To do this you need to configure
static RP assignments. Something like this would work:

ip pim rp-address 150.1.3.3 1
!
access-list 1 permit 224.0.1.39
access-list 1 permit 224.0.1.40

        In this case the auto-rp groups would be sparse, and hence
candidate for distribution via NBMA mode on R5. In other words R3 could
send the mapping agent packet to R5 and R5 could send it back to R4
because of NBMA mode.

        BSR avoids this problem altogether because the RP candidates
unicast their messages to the bootstrap router(s), and the bootstrap
messages are forwarded on a hop-by-hop basis on all interfaces
*including* the one on which they were received. So with this scenario
when R5 receives a BSR message in the Serial interface from R3 it will
forward it back out the same Serial interface in order for it to reach
R4.

On Thursday 02 November 2006 20:20, Adhu Ajit wrote:
> Victor, if you go back to my first email, the scenario is about RP
> information distribution in a sparse-dense mode environment. As you might
> already know that Auto-RP actually runs in PIM dense mode fashion. The
> problem that I was having was with the distribution of RP information ...
> which would imply that we have a problem with our PIM dense mode even
> though this is not a PIM dense mode environment per-se. (Hope I did not end
> up confusing you even more)
>
> Adhu.
>
> Victor Cappuccio <vcappuccio@desca.com> wrote:
>
> Hi Adhu,
>
> Maybe I'm missing something from your email, but from my understanding
> IP PIM DENSE MODE is a Flood and Prune Technology, there is no need to
> set a RP or a Mapping Agent, since all traffic is going to be flooded
> out where they are neighbors, and prunes back the traffic in case that
> they do not have a directly connected member or a downstream routers
> that has an entry for that *,G.
>
> This link is very useful
> http://www.groupstudy.com/archives/ccielab/200502/msg00333.html
>
> Many thanks
> Victor.-
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Adhu Ajit
> Sent: Jueves, 02 de Noviembre de 2006 12:15 a.m.
> To: ccielab@groupstudy.com
> Subject: PIM Dense mode and NBMA
>
> Folks, I have a NBMA topology with Rtr A has the hub and Rtr B, C and D
> as the spokes. Nothing fancy here. Rtr A is configured with NO
> sub-interfaces and so are the other routers.
>
> In a real-world scenario I would not do the following. (A disclaimer
> to prevent a bunch of people pouncing on me that it does not make
> practical sense. :-)) However, in my lab network, I made Rtr B (one of
> the spokes) as the RP as well as the mapping agent.
>
> Now, when I do show ip pim rp mappings on B and Rtr A, the display is
> good. However, the spokes, C and D do not get the mapping information.
>
> When I do a show ip mroute on the Auto-RP mapping agent address,
> 224.0.1.40 on Rtr A, since the incoming interface is the serial
> interface the OIF does not contain the same serial interface. Makes
> sense to me. Remember that I'm NOT using sub-interfaces for each of the
> spokes. All of them are on the subnet and terminate on the same serial
> interface on the hub.
>
> Now, my comment is this. This scenario can never work. The solution is
> to change the mapping agent to be the hub router, Rtr A, or create
> sub-interfaces for each of the spoke if I still wish to keep Rtr B as
> the mapping agent/RP.
>
> Anyone care to comment ?
>
> Thanks,
> Adhu.
>
>
>
>
> ---------------------------------
> Access over 1 million songs - Yahoo! Music Unlimited Try it today.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
> ---------------------------------
> Everyone is raving about the all-new Yahoo! Mail.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

-- 
Ivan


This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:45 ART