From: Rich Collins (nilsi2002@gmail.com)
Date: Tue Apr 08 2008 - 10:27:46 ART
I was wondering about typical GRE tunnel configurations.
Normally you see either some defined unique subnet for the addressing or "ip
unnumbered Loop (or other interface) but not the tunnel source interface).
In this example S1/0 is used for both. Does it work and isn't there some
risk of recursion?
interface Tunnel13
ip unnumbered S1/0
tunnel source s1/0
-Rich
On 4/8/08, Alexei Monastyrnyi <alexeim@orcsoftware.com> 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
This archive was generated by hypermail 2.1.4 : Thu May 01 2008 - 08:25:50 ART