From: Alexei Monastyrnyi (alexeim@orcsoftware.com)
Date: Mon Oct 30 2006 - 13:12:53 ART
Hi.
mroute would work as well, I guess.
Just thought you wanted to reach some kind of load-balancing here. :-)
A.
WorkerBee wrote:
> How about ip mroute 150.1.6.6 255.255.255.255 155.1.0.1?
>
> Since R5 failed the RPF check to R1, we can add ip mroute to overcome
> the RPF failure.
>
> On 10/29/06, Alexei Monastyrnyi <alexeim@orcsoftware.com> wrote:
>> Hi.
>> You could add a tunnel interface R6-R5 and enable PIM on that tunnel
>> from both sides instead of physical interfaces, if you are not
>> prohibited to do so.
>>
>> HTH
>> A.
>>
>> Jung-I Lin wrote:
>> > Dear GS folks,
>> >
>> > I have a question about multicast rpf problem.
>> > The topology as following
>> >
>> >
>> > /------------------------R4---------------------\
>> > / \
>> > R6 R5
>> > \ /
>> > \------------------------R1---------------------/
>> > The IGP is eigrp on all routers.
>> > R5 has two equal cost path to R6's loop0 which is bsr+rp-candidate.
>> > R1,R4 can accept the bsr and choose R6's loop0 to be the RP.
>> > But R5 will not accept this BSR messages, and complaints about not
>> from
>> RPF
>> > interface.
>> > on R5
>> > #sh ip route
>> > D EX 150.1.6.0 [170/2300416] via 155.1.45.4, 00:19:27, Serial1/1
>> > [170/2300416] via 155.1.0.1, 00:19:27, Serial1/0
>> >
>> > Rack1R5(config)#do sh ip rpf 150.1.6.6
>> > RPF information for ? (150.1.6.6)
>> > RPF interface: Serial1/1
>> > RPF neighbor: ? (155.1.45.4)
>> > RPF route/mask: 150.1.6.0/24
>> > RPF type: unicast (eigrp 10)
>> > RPF recursion count: 0
>> > Doing distance-preferred lookups across tables
>> >
>> > *Mar 1 02:18:13.539: PIM-BSR(0): 150.1.6.6 bootstrap forwarded on
>> Serial1/0
>> > *Mar 1 02:18:13.567: PIM-BSR(0): bootstrap on non-RPF path Serial1/0
>> >
>> > All I can do to have R5 accept this BSR messages is to turn on
>> "multicast
>> > multipath"
>> > Then BSR messages is accepted by R5 and R6's loop0 is choose to be
>> the RP
>> > for R5.
>> > Rack1R5(config)#ip multicast multipath
>> > Rack1R5(config)#
>> > Rack1R5(config)#do sh ip rpf 150.1.6.6
>> > RPF information for ? (150.1.6.6)
>> > RPF interface: Serial1/0
>> > RPF neighbor: ? (155.1.0.1)
>> > RPF route/mask: 150.1.6.0/24
>> > RPF type: unicast (eigrp 10)
>> > RPF recursion count: 0
>> > Doing distance-preferred lookups across tables
>> > Multicast Multipath enabled
>> > Rack1R5(config)#
>> > Rack1R5(config)#
>> > *Mar 1 02:20:13.563: PIM-BSR(0): 150.1.6.6 bootstrap forwarded on
>> Serial1/1
>> > *Mar 1 02:20:13.567: PIM-BSR(0): bootstrap on non-RPF path Serial1/1
>> > Rack1R5(config)#do sh ip pim rp map
>> > PIM Group-to-RP Mappings
>> >
>> > Group(s) 224.0.0.0/4
>> > RP 150.1.6.6 (?), v2
>> > Info source: 150.1.6.6 (?), via bootstrap, priority 0, holdtime
>> 150
>> > Uptime: 00:02:11, expires: 00:02:14
>> >
>> > My question is wouldn't the RPF check take all IGP paths into account?
>> > Is there any other ways except "multicast multipath" could be use
>> to solve
>> > this RPF failure?
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Nov 01 2006 - 07:29:07 ART