From: Alexei Monastyrnyi (alexeim@orcsoftware.com)
Date: Tue Apr 08 2008 - 09:04:18 ART
Exactly. And according to preference list during RPF check mroute should 
override any static unicast route (or connected for that matter), and so 
does it:
R1(config)#do sh ip route 172.16.123.3
Routing entry for 172.16.123.0/29
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Serial1/0
      Route metric is 0, traffic share count is 1
R1(config)#do sh run | in mroute     
ip mroute 172.16.123.3 255.255.255.255 Tunnel13
R1(config)#do sh run in ser 1/0
Building configuration...
Current configuration : 221 bytes
!
interface Serial1/0
 ip address 172.16.123.1 255.255.255.248
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay map ip 172.16.123.1 103
 frame-relay map ip 172.16.123.3 103
 no frame-relay inverse-arp
end
       
R1(config)#do sh ip rpf 172.16.123.3 
RPF information for ? (172.16.123.3)
  RPF interface: Tunnel13
  RPF neighbor: ? (172.16.123.3)
  RPF route/mask: 172.16.123.3/32
  RPF type: static
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
But what we see is if this directly connected interface is declared as 
PIM interface, it takes over that RPF check with mroute still in place:
R1(config)#in ser 1/0              
R1(config-if)#ip pim dense-mode         
R1(config-if)#do sh ip rpf 172.16.123.3
RPF information for ? (172.16.123.3)
  RPF interface: Serial1/0
  RPF neighbor: ? (172.16.123.3) - directly connected
  RPF route/mask: 172.16.123.0/29
  RPF type: unicast (connected)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
Huh? :-)
A.
Paul Cosgrove said the following on 4/8/2008 1:31 PM:
> When a router running traditional IOS is determining the RPF 
> interface, it first looks at routes to the source with the lowest AD.  
> Connected will win over a static.
>
> Alexei Monastyrnyi wrote:
>> Hi.
>>
>> On R5 if you source your ping 224.2.2.2 from interface other than 
>> tunnel source while having a proper mroute for that IP on the other 
>> side, you'll get it alright. So the workaround for you would be in 
>> sourcing your tunnel from loopback interface.
>>
>> http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094b55.shtml#noforwardrpffail 
>>
>>
>> But it seems like the RPF check sequence has a higher preference for 
>> directly connected interfaces with PIM enabled, not mentioned in the 
>> doc though. :-)
>>
>> 172.16.103.1 (lo103) R3 (Se 1/0) 172.16.123.3 ---FR--- 172.16.123.1 
>> (Se 1/0) R1 (fa 0/0 172.16.11.1 joined 224.12.2.2)
>>
>> R1#conf t
>> R1(config-if)#do sh run in tu 13 Building configuration...
>>
>> Current configuration : 152 bytes
>> !
>> interface Tunnel13
>> ip unnumbered Serial1/0
>> ip pim dr-priority 255
>> ip pim dense-mode
>> tunnel source Serial1/0
>> tunnel destination 172.16.123.3
>> end
>>
>> R1(config-if)#do sh run in ser 1/0
>> Building configuration...
>>
>> Current configuration : 221 bytes
>> !
>> interface Serial1/0
>> ip address 172.16.123.1 255.255.255.248
>> encapsulation frame-relay
>> serial restart-delay 0
>> frame-relay map ip 172.16.123.1 103
>> frame-relay map ip 172.16.123.3 103
>> no frame-relay inverse-arp
>> end
>>
>> R1(config-if)#do sh run | in mroute
>> ip mroute 172.16.123.3 255.255.255.255 Tunnel13
>>
>> R1(config-if)#do sh ip rpf 172.16.123.3
>> RPF information for ? (172.16.123.3)
>>  RPF interface: Tunnel13
>>  RPF neighbor: ? (172.16.123.3)
>>  RPF route/mask: 172.16.123.3/32
>>  RPF type: static
>>  RPF recursion count: 0
>>  Doing distance-preferred lookups across tables
>>
>> R1(config)#in ser 1/0  R1(config-if)#ip pim dense-mode
>> R1(config-if)#do sh ip rpf 172.16.123.3
>> RPF information for ? (172.16.123.3)
>>  RPF interface: Serial1/0
>>  RPF neighbor: ? (172.16.123.3) - directly connected
>>  RPF route/mask: 172.16.123.0/29
>>  RPF type: unicast (connected)
>>  RPF recursion count: 0
>>  Doing distance-preferred lookups across tables
>>
>> HTH
>> A.
>>
>> theKonqueror said the following on 4/8/2008 11:57 AM:
>>> Well, thats what the question says. "Enable pim dense mode on the link
>>> between R4 and R5". The only link between the two is frame-relay. 
>>> Solution
>>> guide has same config as I do, so I wonder they didn't check it?
>>>
>>> I'm running 12.4 adv-enterprise on routers btw...
>>>
>>> On Tue, Apr 8, 2008 at 3:17 PM, Sadiq Yakasai <sadiqtanko@gmail.com> 
>>> wrote:
>>>
>>>  
>>>> Hmmm,
>>>>
>>>> But if you are not mapping broadcast on the FR maps, then whats the
>>>> point of enabling PIM on the serial interfaces?
>>
>> _______________________________________________________________________
>> Subscription information may be found at: 
>> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu May 01 2008 - 08:25:50 ART