Re: RPF failures on multicast over gre tunnel

From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Tue Apr 08 2008 - 11:13:02 ART

Hi Alexei,

The link has a useful reference for how rpf interfaces are calculated,
well done for posting it. Don't know what you mean about the example on
the page as I never mentioned it.

You explained how to resolve the issue, I was just explaining why it was
happening and why the static does not override the connected interface
as you thought it should.

Paul.

Alexei Monastyrnyi wrote:
> Hi Paul.
>
> It is about original Q in this thread, not about URL I sent, that one is
> quite trivial.
>
> The guy is having his GRE tunnel across FR link with tunnel interface
> sourcing off serial interface IP and static mroute pointing to the
> tunnel. Once that serial interface is PIM-enabled - RPF check fails. And
> the workaround would be to source from some loopback interface instead.
>
> Fair enough, RPF considers multicast-enabled interfaces (which happens
> to be PIM-enabled in our case), the point I tried to convey. :-)
>
> A.
>
>
>
> Paul Cosgrove said the following on 4/8/2008 2:33 PM:
>> 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
>
> _______________________________________________________________________
> 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