From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Thu Mar 30 2006 - 20:35:29 GMT-3
Alexei,
I'm not sure I get exactly the same results.
What I was referring to was the use of bidir, what problems it can fix in
NBMA networks and when/why you might want to use it.
The way I test this is to have a 4 router setup. R1 is the hub with
frame-relay spokes to R3 and R4. R2 is direcely connected to R1 over a
separate HDLC or ethernet link.
Next make the loopbacks of all routers members of different groups,
230.1.1.1 for R1. 230.2.2.2 for R2 etc.
Set it up with static RP s to start and make sure you can ping all groups
from R2, basically ensuring you are not running in to any fast switching
issues that need you to put no ip mroute-cache on an interface to pass
multicast traffic.
Then move through auto-rp and BSR, both with and without bidir and see when
you need ip pim nbma mode to enable R2 to ping all groups. Don't forget to
clear ip mrout * between tests. You should see that bidir is an alternative
to nbma mode to enable R2 to ping all groups.
To make it more interesting, take off bidir make each of the frame
interfaces members of a group, and see which ones R2 can ping, you should
find that it cannot ping one of them. Show ip pim nei on R1 gives the
answer, it shows a difference between the frame interface you can ping and
the frame interface you can't ping
Chris
On 3/30/06, Alexei Monastyrnyi <alexeim@orcsoftware.com> wrote:
>
> 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