From: Jason Madsen (madsen.jason@gmail.com)
Date: Sun Jan 11 2009 - 16:14:19 ARST
Hi Nit,
I encountered a similar situation a while back. Unfortunately, I was unable
to determine what was causing it at the time and I haven't been able to
replicate the problem again since. I was using GNS3 at the time and I can
only assume that was the issue unless I fat-fingered one thing and didn't
catch it at the time.
I just labbed up your exact scenario and don't have any recursive routing
issues at all. I let it sit for a few minutes and then I changed the ospf
cost of my tunnel to 1 and then created loopback address on R1 and R3 and
advertised them into OSPF to ensure I was learning them through the
tunnel. With the setup you have described, you shouldn't even be learning
routes through your tunnel. The default OSPF cost for a GRE tunnel is
11111 and if your endpoint is only 2 hops away, your F0/0 should be
preferred over your tunnel.
Are you using GNS3? Have you tried clearing your OSPF process and routing
table? Are you in fact using /24 masks on all of your interfaces?
Jason
On Sun, Jan 11, 2009 at 6:26 AM, Nitro Drops <nitrodrops@hotmail.com> wrote:
> Hi All,
>
> Have been trying to fix my recursive routing for OSPF in the last 2 hours.
>
> R1 F0/0 .1 >> 155.1.37.0 >> .2 F0/0 R2 F0/1 .2 >> 155.1.0.0 >> .3 F0/0 R3
>
> GRE tunnel created between R1 and R3
>
> R1
> interface Tunnel0
> ip address 155.1.57.1 255.255.255.0
> tunnel source 155.1.37.1
> tunnel destination 155.1.0.3
>
> router ospf 1
> network 155.1.0.0 0.0.255.255 area 0
> distribute-list 2 in Tunnel0
>
> access-list 2 deny 155.1.0.0 0.0.0.255
> access-list 2 deny 155.1.37.0 0.0.0.255
> access-list 2 permit any
>
>
> R3
> interface Tunnel0
> ip address 155.1.57.3 255.255.255.0
> tunnel source 155.1.0.3
> tunnel destination 155.1.37.1
>
> router ospf 1
> network 155.1.0.0 0.0.255.255 area 0
>
> distribute-list 2 in Tunnel0
>
>
> access-list 2 deny 155.1.0.0 0.0.0.255
>
> access-list 2 deny 155.1.37.0 0.0.0.255
>
> access-list 2 permit any
>
>
> To prevent recursive routing, i have used a distribute-list to prevent
> learning the tunnel destination from the tunnel interface. However, my int
> tunnel keeps on flapping (Debug IP routing as attached), did i missed out
> anything on my configs or did i use the wrong method? I used the same
> method
> on RIP & EIGRP, distribute-list works fine on both of them, distribute-list
> applying in/out to stop the tunnel destination from advertising/learning
> from
> the tunnel interface.
>
> Except on OSPF, i can only prevent the router from learning from the tunnel
> destination, CANT stop advertising the tunnel destination out of the tunnel
> interface, as the OSPF distribute-list only works for inbound.
>
> Cheers
> Nit
>
>
> IP routing debugging is on
> R1#
> *Mar 1 08:54:30.021: %OSPF-5-ADJCHG: Process 1, Nbr 15.2.2.2 on Tunnel0
> from
> LOADING to FULL, Loading Done
> *Mar 1 08:54:41.541: RT: del 155.1.0.0/24 via 155.1.37.2, ospf metric
> [110/120000]
> *Mar 1 08:54:41.545: RT: delete subnet route to 155.1.0.0/24
> *Mar 1 08:54:41.549: RT: NET-RED 155.1.0.0/24
> *Mar 1 08:54:48.869: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> Tunnel0,
> changed state to down
> *Mar 1 08:54:48.881: RT: is_up: Tunnel0 0 state: 4 sub state: 1 line: 0
> has_route: True
> *Mar 1 08:54:48.885: %OSPF-5-ADJCHG: Process 1, Nbr 15.2.2.2 on Tunnel0
> from
> FULL to DOWN, Neighbor Down: Interface down or detached
> *Mar 1 08:54:48.893: RT: interface Tunnel0 removed from routing table
> *Mar 1 08:54:48.893: RT: del 155.1.57.0/24 via 0.0.0.0, connected metric
> [0/0]
> *Mar 1 08:54:48.897: RT: delete subnet route to 155.1.57.0/24
> *Mar 1 08:54:48.901: RT: NET-RED 155.1.57.0/24
> *Mar 1 08:54:51.553: RT: SET_LAST_RDB for 155.1.0.0/24
> NEW rdb: via 155.1.37.2
>
> *Mar 1 08:54:51.561: RT: add 155.1.0.0/24 via 155.1.37.2, ospf metric
> [110/120000]
> *Mar 1 08:54:51.561: RT: NET-RED 155.1.0.0/24
> *Mar 1 08:54:57.869: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> Tunnel0,
> changed state to up
> *Mar 1 08:54:57.881: RT: is_up: Tunnel0 1 state: 4 sub state: 1 line: 0
> has_route: False
> *Mar 1 08:54:57.885: RT: SET_LAST_RDB for 155.1.57.0/24
> NEW rdb: is directly connected
>
> *Mar 1 08:54:57.889: RT: add 155.1.57.0/24 via 0.0.0.0, connected metric
> [0/0]
> *Mar 1 08:54:57.893: RT: NET-RED 155.1.57.0/24
> *Mar 1 08:54:57.897: RT: interface Tunnel0 added to routing table
> *Mar 1 08:54:58.973: %OSPF-5-ADJCHG: Process 1, Nbr 15.2.2.2 on Tunnel0
> from
> LOADING to FULL, Loading Done
> *Mar 1 08:55:11.577: RT: del 155.1.0.0/24 via 155.1.37.2, ospf metric
> [110/120000]
> *Mar 1 08:55:11.581: RT: delete subnet route to 155.1.0.0/24
> *Mar 1 08:55:11.585: RT: NET-RED 155.1.0.0/24
> R1#undebug <http://155.1.0.0/24R1#undebug>
> *Mar 1 08:55:17.901: %OSPF-5-ADJCHG: Process 1, Nbr 15.2.2.2 on Tunnel0
> from
> FULL to DOWN, Neighbor Down: Interface down or detached
> *Mar 1 08:55:18.869: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> Tunnel0,
> changed state to down
> *Mar 1 08:55:18.877: RT: is_up: Tunnel0 0 state: 4 sub state: 1 line: 0
> has_route: True
> *Mar 1 08:55:18.881: RT: interface Tunnel0 removed from routing table
> *Mar 1 08:55:18.885: RT: del 155.1.57.0/24 via 0.0.0.0, connected metric
> [0/0]
> *Mar 1 08:55:18.889: RT: delete subnet route to 155.1.57.0/24
> *Mar 1 08:55:18.889: RT: NET-RED 155.1.57.0/24
> R1#undebug <http://155.1.57.0/24R1#undebug> al
> *Mar 1 08:55:21.589: RT: SET_LAST_RDB for 155.1.0.0/24
> NEW rdb: via 155.1.37.2
>
> *Mar 1 08:55:21.597: RT: add 155.1.0.0/24 via 155.1.37.2, ospf metric
> [110/120000]
> *Mar 1 08:55:21.597: RT: NET-RED 155.1.0.0/24l
> All possible debugging has been turned off
>
>
>
> _________________________________________________________________
> Messenger's gift to you! Download free emoticons today!
> http://livelife.ninemsn.com.au/article.aspx?id=669758
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:37 ARST