Re: Multicast - AutoRP and NBMA problem.

Working with Adrian, we were able to figure out that my loopbacks (source of
cRP and MA) needed to be in sparse-mode not sparse-dense-mode and the R5
s0/0/0 had to have "no ip mroute-cache". That is the only way it would work.
I'm not sure why. If anyone of the experts here knows please respond.

Basically what happened is that when I cleared the mroute on R5 (FR Hub)
only one cRP announcement from SW2 was forwarded to the MA (R1). R1 never
got any more announcements and expired the mappings after 30 seconds. I
tried spt-threshold to infinity on the cRP and R5 but same thing.

It's still a mystery for me why the mroute-cache would do work.

Thanks

Tom K.

On Sat, Jun 5, 2010 at 10:46 AM, Tom Kacprzynski <tom.kac_at_gmail.com> wrote:

> Hello everyone,
> I been stuck trying to figure out this one problem i have in the lab. I
> have a FR cloud where the mapping agent is one of the spokes and a cRP are
> behind the hub. I have ip pim nbma-mode configured on the hub (R5), i've
> tried to disable all other spokes except the mapping agent, i'm running ip
> pim autorp listener on all interfaces and ip sparse-mode (except loopbacks)
> .No one is able to get any RP mappings. What is interesting is when I clear
> the mroute on the FR hub, everything works but for only 30 sec until the
> mappings expire. I've been trying to figure this out for a while but i'm
> getting no where and I need to get this one before I can move on to the next
> lab.
>
> Below are some details and troubleshooting steps i've taken.
>
> Topology
> [R1] (MA) s0/0/0.1 ----FR----> s0/0/0 [R5] gi0/0 -----> vlan58 [SW2] (cRP)
>
>
> 1. Pim Neighbors - looks ok.
> ------------------------------------------------------------
>
> R1#sh ip pim neighbor | i 5
> 155.1.0.5 Serial0/0/0.1 12:35:27/00:01:30 v2 1 / S
>
> R5#sh ip pim neighbor
> ..
> 155.1.58.8 GigabitEthernet0/0 13:02:33/00:01:21 v2 1 / DR S
> 155.1.0.1 Serial0/0/0 12:35:48/00:01:26 v2 1 / S
>
> SW2#sh ip pim neighbor
> ..
> 155.1.58.5 Vlan58 13:03:00/00:01:43 v2 1 / S
>
>
>
> 2. IP Mroute for 224.0.1.39
> ------------------------------------------------------------
> For R5 looks ok to me.
>
> *R5*#sh ip mroute 224.0.1.39 | b \(
> (*, 224.0.1.39), 00:15:23/stopped, RP 0.0.0.0, flags: D
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> Serial0/0/1, Forward/Sparse, 00:15:23/00:00:00
> Serial0/0/0, Forward/Sparse, 00:15:23/00:00:00
> GigabitEthernet0/0, Forward/Sparse, 00:15:23/00:00:00
>
> (150.1.8.8, 224.0.1.39), 00:15:17/00:02:59, flags: T
> Incoming interface: GigabitEthernet0/0, RPF nbr 155.1.58.8
> Outgoing interface list:
> Serial0/0/0, Forward/Sparse, 00:15:17/00:00:00 <------- FR interface
> Serial0/0/1, Prune/Sparse, 00:02:37/00:00:22
>
>
> When I checked the mroute for 224.0.1.39 on the mapping agent R1, that's
> where things look little bit off, it doesn't see any of the cRP joining the
> 224.0.1.39.
>
> *R1*#sh ip mroute 224.0.1.39 | b \(
> (*, 224.0.1.39), 12:07:34/00:02:50, RP 0.0.0.0, flags: DCL
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> Serial0/0/0.1, Forward/Sparse, 12:07:34/00:00:00
> Loopback0, Forward/Sparse-Dense, 12:07:34/00:00:00
>
> I checked RPF for SW1 from R1 and it looks ok
> *R1*#sh ip rpf 150.1.8.8
> RPF information for ? (150.1.8.8)
> RPF interface: Serial0/0/0.1
> RPF neighbor: ? (155.1.0.5)
> RPF route/mask: 150.1.8.0/24
> RPF type: unicast (ospf 1)
> RPF recursion count: 0
> Doing distance-preferred lookups across tables
>
> I even check using mtrace and it looks ok to me
> *R1*#mtrace 150.1.8.8
> Type escape sequence to abort.
> Mtrace from 150.1.8.8 to 155.1.0.1 via RPF
> From source (?) to destination (?)
> Querying full reverse path...
> 0 155.1.0.1
> -1 155.1.0.1 PIM [150.1.8.0/24]
> -2 155.1.0.5 PIM [150.1.8.0/24]
> -3 155.1.58.8 PIM [150.1.8.0/24]
> -4 150.1.8.8
>
>
> I'm really stuck here without any ideas, been working on this for a while
> and still can't come up with any solutions, any help would be appreciated.
>
> thank you,
>
> Tom K.

Blogs and organic groups at http://www.ccie.net
Received on Sat Jun 05 2010 - 12:52:00 ART