From: Arun Arumuganainar (aarumuga@hotmail.com)
Date: Tue Aug 23 2005 - 10:37:02 GMT-3
Yes ... You are right on top !!!
Static route to tunnel destination is a sure solution for this problem !!! I
have seen similar problem before !!! Just wanted to share with you as it is
relevant to our discussion .
se0/0---se0/0 fa1/0--fa1/0
Router1------------router2-------router3
|<----------GRE Tunnel------------->|
In the above topology ... Do the Basic configuration as follows . This is a
simple single area topology !!!
1) Configure OSPF on R1 , R2 and R3
2) Bring up GRE Tunnel between R1 and R3
3) Turn on OSPF on GRE tunnel as well .
Now the Fun Starts .... Do this peace of configuration over the base
topology.
ON R1 go to se0/0 increase the OSPF cost to very high value say for ex :
1000
Now you would see interface flapping .
Scenario Note :
~~~~~~~~~~
Playing with OSPF cost is simple way to channelise all traffic via GRE
Tunnel . However in doing so if we are not very care ful even tunnel
destination will go via GRE and this would result in Flaps .
So Best Practice Recommendation : We are free to tweak the cost but ensure
that tunnel destination does not take the tunnel route . We can just rely on
static route for tunnel destination in the respective tunnel end-points !!!
Thanks and Regards
Arun
----- Original Message -----
From: "Mitchell, TJ" <tmitchell@allianttech.com>
To: "Arun Arumuganainar" <aarumuga@hotmail.com>; "Thomwin Chen"
<thomwin_chen@yahoo.com>; "Loi, Choon Ho" <ChoonHo.Loi@getronics.com>;
<ccielab@groupstudy.com>
Sent: Tuesday, August 23, 2005 6:29 PM
Subject: RE: OSPF Virtual-Link & GRE
I know I'm new here, but I have an idea on what is going on.
On router R3 you are originally learning the route 172.16.25.x through
the virtual-link of area 1 which is fine it works. Now you are putting
the tunnel on through the virtual-link back to the backbone area 0.
The tunnel comes up and things are working great.
Now guess what happens you start learning the 172.16.25.x route through
the tunnel instead of the virtual link due to the nature of OSPF. Well
when making tunnels with OSPF you need to make sure you don't start
learning your destination networks through the tunnel otherwise the
tunnel will drop because it will lose the route because the virtual link
is now gone. Then the tunnel drops OSPF reconverges and you learn the
link again through the virtual-link, tunnels comes back up because it
has the route to the destination network, OSPF reconverges again you
lose the route and the tunnel drops again.
You see what I'm saying. Get the tunnel up and running then quickly
check the routing tables while you can still ping. You should see that
the route is learned from the tunnel and not the interface.
Like I said I'm new here and this is my thought on the deal, I would
like to know your thoughts.
Thanks
T.J. Mitchell
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Arun Arumuganainar
Sent: Tuesday, August 23, 2005 8:47 AM
To: Thomwin Chen; Loi, Choon Ho; ccielab@groupstudy.com
Subject: Re: OSPF Virtual-Link & GRE
Cool ... Pretty interesting problem though ... But I would need some
more
information to confirm my suspicion .
Pls. provide me with show ip route <tunnel destination > ... taken at
two
different times .
a)When ping packets are going through fine
b) when ping are not going through .
If my suspicion is right then your tunnel protocol state in the "show
interface tunnel 0" command should toggle between UP and DOWN state !!!
at
regular intervals.
Only work around for this problem add a following static route in tunnel
end
points .
R2 .
ip route 172.16.35.0 255.255.255.252 serial 1/1
R3
ip route 172.16.25.0 255.255.255.252 serial 1/1
This kind of problems are bound to happen especially when you enable
routing
protocols on a tunnel interface . Some times routers could have learned
a
better route for tunnel destination via tunnel interface themselves .
This
creates a loop . i.e Tunnel recurses over Tunnel destination and tunnel
destination reclurse over tunnel !!! Under this scenario there will be
flapping of tunnel interface at regular intervals !!!
Best way to address it , is to have static route for tunnel destination
alone via an interface other than Tunnel .
Pls. Note : Static route is always preferred . Hence accidental loops
will
not be introduced through Dynamic Routing protocols .
Pls. do let me know if this solves the problem .
Thanks and Regards
Arun
----- Original Message -----
From: "Thomwin Chen" <thomwin_chen@yahoo.com>
To: "Loi, Choon Ho" <ChoonHo.Loi@getronics.com>;
<ccielab@groupstudy.com>
Sent: Tuesday, August 23, 2005 3:30 PM
Subject: Re: OSPF Virtual-Link & GRE
> Choon,
>
> Have you try to put the tunnel0 interface in R2 and R3 into area 0 ?
> I saw your config, the tunnel is in area 3.
>
> Rgds,
> Thomwin
>
>
> "Loi, Choon Ho" <ChoonHo.Loi@getronics.com> wrote:
> Hi,
>
> I lab-up the following Scenario for OSPF:
>
> Area 0 | R2 -----Area 1------- R5 ------Area 2--------R3--------| Area
3
>
> Everything works fine... but, my ping drop intermittently when I try
to
> ping from Area3 to Area0.
> Anything wrong with my configuration?
>
> Thanks.
>
>
> Following is my configuration:
>
> hostname r2
> !
>
> !
> interface Loopback0
> ip address 192.2.2.2 255.255.255.0
> !
> interface Tunnel0
> ip address 23.23.23.2 255.255.255.248
> tunnel source Serial1/1
> tunnel destination 172.16.35.1
> !
> interface Serial1/1
> ip address 172.16.25.1 255.255.255.252
> encapsulation ppp
>
> router ospf 1
> router-id 2.0.0.2
> log-adjacency-changes
> area 1 virtual-link 5.0.0.5
> network 23.23.23.0 0.0.0.7 area 3
> network 172.16.25.0 0.0.0.3 area 1
> network 192.2.2.0 0.0.0.255 area 0
>
------------------------------------------------------------------------
> ---
> !
> hostname r5
>
> interface Loopback0
> ip address 100.100.100.100 255.255.255.0
> !
> interface Loopback1
> ip address 5.0.0.5 255.255.255.255
>
> interface Serial0/0
> ip address 172.16.25.2 255.255.255.252
> encapsulation ppp
> no fair-queue
> !
> interface Serial0/1
> ip address 172.16.35.2 255.255.255.252
> encapsulation ppp
> !
> router ospf 1
> router-id 5.0.0.5
> log-adjacency-changes
> area 1 virtual-link 2.0.0.2
> network 172.16.25.0 0.0.0.3 area 1
> network 172.16.35.0 0.0.0.3 area 2
> neighbor 5.5.5.2
> !
>
>
>
------------------------------------------------------------------------
> ------
> !
> hostname r3
>
> interface Loopback0
> ip address 10.10.10.3 255.255.255.255
> !
> interface Tunnel0
> ip address 23.23.23.3 255.255.255.248
> tunnel source Serial1/1
> tunnel destination 172.16.25.1
>
> interface Serial1/1
> ip address 172.16.35.1 255.255.255.252
> encapsulation ppp
> serial restart_delay 0
> clockrate 64000
>
> router ospf 1
> router-id 3.0.0.3
> log-adjacency-changes
> network 10.10.10.0 0.0.0.255 area 3
> network 23.23.23.0 0.0.0.7 area 3
> network 172.16.35.0 0.0.0.3 area 2
>
------------------------------------------------------------------------
> -------------------------------------
>
>
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:20 GMT-3