From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Apr 27 2006 - 16:00:56 GMT-3
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.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: Nick Griffin [mailto:ngriffin@sio.midco.net]
> Sent: Thursday, April 27, 2006 11:53 AM
> To: Brian McGahan
> Cc: ccielab@groupstudy.com
> Subject: Re: IEWB 3.0 Lab19 Mcast 6.1
>
> So the issue in this particular scenario the problem is the multipoint
> interface on R5, the advertisement is received on S0/0 and cannot be
> sent back out, even with nbma mode?
>
> Thanks
>
> Brian McGahan wrote:
> > Yes there can be situations like with multipoint NBMA where a
> > candidate rp or mapping agent advertisement comes in and needs to be
> > sent back out the same interface, but can't due to the OIL
restrictions
> > (incoming and outgoing interface can't be the same). There are
> > workarounds for this like assigning default RPs for 224.0.1.39 and
> > 224.0.1.40 and using NBMA mode, but BSR avoids this completely
because
> > all the messages are sent on a hop by hop basis, unlike Auto-RP.
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> >
> >> -----Original Message-----
> >> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> >>
> > Of
> >
> >> Nick Griffin
> >> Sent: Thursday, April 27, 2006 9:59 AM
> >> To: ccielab@groupstudy.com
> >> Subject: IEWB 3.0 Lab19 Mcast 6.1
> >>
> >> Are there any scenarios where it is possible that Auto RP will not
be
> >> able to distribute the group to RP mappings utilizing sparse-mode,
ip
> >> pim autorp listener to all the necessary routers as BSR could? The
> >> solution for IEWB Lab19 Sec 6.1 utilizes BSR, I didn't see any
> >> indication why Auto RP could not be used, however I wasn't able to
get
> >> the Group to RP mappings propogated to R4. I don't see any
indications
> >> of RPF failures to the MA/RP. I'm at a loss why Auto RP will not
> >>
> > achieve
> >
> >> the desired goal. Thoughts are appreciated.
> >>
> >> NG
> >>
> >>
> >>
> >
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:59 GMT-3