Re: RPF failures on multicast over gre tunnel

From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Tue Apr 08 2008 - 09:33:19 ART

Hi Alexei,

Connected routes have an AD of 0 so will be checked first during the RPF
determination algorithm. The table on the link you sent is about what
happens if multiple routes with equal ADs are found, and does not
mention Connected routes at all. It would of course be unusual to have
multiple router NICs within the same subnet.

The rpf check is used to determine which interfaces you expect
multicasts to arrive on, and (indirectly) which you will send received
multicasts out. If you do not run pim on the interface, then you will
not route multicasts received on that interface.

Incidently IOS XR does not perform this AD check.

Paul.

Alexei Monastyrnyi wrote:
> 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
>>>
>>
>>
> 

-- 
HEAnet Limited
Ireland's Education & Research Network
5 George's Dock, IFSC, Dublin 1, Ireland
Tel:  +353.1.6609040
Web:  http://www.heanet.ie
Company registered in Ireland: 275301

Please consider the environment before printing this e-mail.

This archive was generated by hypermail 2.1.4 : Thu May 01 2008 - 08:25:50 ART