From: Alexei Monastyrnyi (alexeim@orcsoftware.com)
Date: Thu Mar 30 2006 - 11:47:02 GMT-3
Cris,
I have tried that with BSR + ip pim nbma-mode on FR hub router and
RP-candidate on one of the spokes.
Groups registered on the same spoke as RP-candidate were not available
from another spoke. Though groups registered on the hub router were.
I guess it happens because BSR/RP-candidate for some operations still
uses extended features of PIMv2 over the same local-link multicast
address 224.0.0.13 (all PIM routers) which has a TTL 1, hence cannot
travel from spoke to spoke. I will probably dig more if I have some
free time next week.
Below we run PIM sparse-mode across the board (r2<->r1<->r3).
12.12.123.0/24 is an NBMA subnet, 12.12.X.X/24 are lo 0 interface for
rX. Each router joins its lo 0 interface to 239.X.X.X group.
r1 is the hub router with
ip pim bsr-candidate Loopback0 0
and
ip pim nbma-mode on its NBMA interface.
r3 has
ip pim rp-candidate Loopback0 group-list 5
access-list 5 permit 239.3.3.3
access-list 5 permit 239.2.2.2
access-list 5 permit 239.1.1.1
Non-RP spoke (r2) does send a unicast register request to RP-spoke (r3)
r2#ping 239.3.3.3
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.3.3.3, timeout is 2 seconds:
02:15:22: PIM(0): Send v2 Register to 12.12.3.3 for 12.12.2.2, group
239.3.3.3.
r3#
02:20:22: PIM(0): Received v2 Register on Serial0 from 12.12.123.2
02:20:22: for 12.12.2.2, group 239.3.3.3
02:20:22: PIM(0): Forward decapsulated data packet for 239.3.3.3 on
Loopback0
02:20:22: PIM(0): Building Periodic Join/Prune message for 239.1.1.1
On the hub router we periodically have
r1#
02:20:11: PIM: Building Join/Prune message for 239.3.3.3
02:20:11: PIM: No sources in join or prune list
but with no time correlation... Time is in NTP sync between the routers.
A.
on 29/03/2006 16:18 Chris Lewis wrote:
> Restricting this to the encapsulations found in the lab, ip pim nbma-mode is
> only configurable for frame-relay interfaces (ATM is no longer in the exam),
> and as you as you point out, those interfaces have a broadcast queue.
>
> Outside of the exam, some of the higher end hardware based forwarding
> platforms have a separate queue at the interface level that is used by
> multicast, but this is out of scope for the R&S exam.
>
> An interesting experiment to try is you've pointed out that this command
> keeps track of join and leave messages based on destination not interface,
> which can be useful not only for regular multicast groups, but the special
> auto-RP groups too. If you have to configure an RP on a spoke, but are using
> BSR instead of auto-RP, have you thought how you could enable messages to go
> in and out of a frame relay hub to allow BSR to function properly?
>
> Chris
>
>
> On 3/29/06, Alexei Monastyrnyi <alexeim@orcsoftware.com> wrote:
>
>> Hi Folks!
>>
>> I know two things about the subj.
>>
>> 1. It is designed to treat join-leave messages separately for NBMA
>> serial interfaces with PIM sparse mode.
>>
>> 2. It is designed to re-classify multicast packets to go via normal
>> hardware queue out of serial interface. It is also said that there is a
>> special "broadcast hardware queue" for serial interfaces, and multicast
>> is treated as a broadcast, which might make this to be an issue for slow
>> serial links.
>>
>> The second thing rises a kind of doubts ... I have checked available
>> books and CCO and couldn't find any references regarding "broadcast
>> hardware queue on serial interfaces".
>>
>> Would appreciate any hints here.
>>
>> A.
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:40 GMT-3