From: Arun Arumuganainar (aarumuga@hotmail.com)
Date: Wed Aug 24 2005 - 07:29:54 GMT-3
Agreed Makes sense ... Thanks !!!
Now Back to Square one !!! By the way I tried to simulate this scnario in my
lab !!! Found that it working fine with out any modification !!! Just check
out this router trace !!! Pls let me know if I am missing any thing !!!
Here I found that for Tunnel destination prefix , two Summary routes are
Learned a) one via Physical interface ( area 2 route ) and b) the other via
tunnel ( area 3 route ) . Fotunately the metric happened to be same !!!
In such a scenario OSPF belives the route via physical interface only ( If
both routes are treated the same then route entry will be a load shared
route ) !!! Under this scenario every thing works fine !!! ANY to ANY Ping
is working just fine !!! Am I missing something
==========================================
Any body who have seen this unstable state can you pls. send me " show ip
ospf database summary " for tunnel destination !!! Router traces from my
labs are given below ....
==========================================
router3#sh ip ospf database summary 172.16.25.0
OSPF Router with ID (10.10.10.3) (Process ID 100)
Summary Net Link States (Area 2) >>>> Learned via Physical
interface !!!
Routing Bit Set on this LSA >>>> Only route via physical interface is
selected for forwarding !!!
LS age: 1082
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 172.16.25.0 (summary Network Number)
Advertising Router: 5.5.5.2
LS Seq Number: 80000001
Checksum: 0xCF7C
Length: 28
Network Mask: /24
TOS: 0 Metric: 10
Summary Net Link States (Area 3) >>>> Learned Via Tunnel
0!!!
LS age: 438
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 172.16.25.0 (summary Network Number)
Advertising Router: 192.2.2.2
LS Seq Number: 80000001
Checksum: 0x6333
Length: 28
Network Mask: /24
TOS: 0 Metric: 10
Thanks and Regards
Arun
----- Original Message -----
From: "Swaroop Potdar" <swarooppotdar@hotmail.com>
To: <aarumuga@hotmail.com>; <swm@emanon.com>; <tmitchell@allianttech.com>;
<thomwin_chen@yahoo.com>; <ChoonHo.Loi@getronics.com>;
<ccielab@groupstudy.com>
Sent: Wednesday, August 24, 2005 1:32 PM
Subject: Re: OSPF Virtual-Link & GRE
> Hi Arun,
>
> what your are saying is right but you are talking in the perspective of
> VPN's and normal best practises.
>
> If you have a broken area and try connecting it to Area0 via virtual link
or
> GRE is not recommended in normal scenarios. Its only in the lab to test
the
> understanding of a protocol and how it works.
> =====
>
> Now putting aside the VPN if you try to connect a broken Area to Area 0
>
> 1) Option one is Virtual Link ( No issues with this)
> 2) GRE (There are problems of Recursive routing if not implemented
properly)
> Here the point to be seen is OSPF prefering Intra Area routes more
> rather than Inter Area Routes, Cost comes next)
>
> If The GRE is spanning Non-OSPF Domain (Isolated OSPF with in between RIP
or
> EIGRP) then we can think of filtering as in ospf filtering is not possible
> in this manner due to the LSA's.
>
>
>
>
> >From: "Arun Arumuganainar" <aarumuga@hotmail.com>
> >Reply-To: "Arun Arumuganainar" <aarumuga@hotmail.com>
> >To: "Scott Morris" <swm@emanon.com>, "'Mitchell, TJ'"
> ><tmitchell@allianttech.com>, "'Thomwin Chen'"
<thomwin_chen@yahoo.com>,
> > "'Loi, Choon Ho'" <ChoonHo.Loi@getronics.com>,
<ccielab@groupstudy.com>
> >Subject: Re: OSPF Virtual-Link & GRE
> >Date: Wed, 24 Aug 2005 06:54:43 +0530
> >
> >Hi Scott ,
> >
> >From Exam perspective : I wish such questions will not be asked . Even in
> >the event they ask such question we can fall back to PBR if static route
is
> >prohibited !!! May be some body in group can comment if this is perfectly
> >legal .
> >
> >OK ...Let us discuss this for some time ignoring exam perspective !!!
> >
> >When ever you have GRE tunnel ... and want to have any to any
connectivity
> >via GRE , You are bound to use one static route at the least . Other wise
> >traffic would not be flowing properly ...
> >
> > > se0/0---se0/0 fa1/0--fa1/0
> > > Router1------------router2-------router3----Router4
> > > |<----------GRE Tunnel------------->|
> >
> >Let us take this example . It is Plain Vanilla single area OSPF . We runn
> >OSPF on physical interfaces and also GRE interface !!!Now what path will
> >traffic from R1 to R4 will take??? !!!
> >
> >Path will never take the tunnel route as IGP bestpath would be via
physical
> >interface . There are only three ways sending all the traffic downstream
> >to
> >R3 vial Tunnel .
> >
> >1) Runn a different protocol for example EIGRP 1) over Tunnel interfaces
2)
> >R3's interface facing R4 and 3) Router 4 . In such a case all traffic
from
> >R1 to R3 and behind will go via GRE tunnel interface . But only draw back
> >here R2 will not be aware of R4 and Tunnel IP address .
> >
> >Pls. Note : This is common technique to advertise private address over
> >Public address space ( GRE based VPN ) . In case R2 also wants access to
R4
> >and still want traffic from R1 to go via GRE interface you should fall
back
> >to Method 2 or 3
> >
> >2) Runn static route for all the address on R3 and R4 ( Only exception
> >being
> >Tunnel destination ) . This will for sure work as static route is most
> >preferred due Admin distance rule .
> >
> >3) Tweak the Metric on Physical interface ( set it to very high value say
> >1000 ) . This make all traffic go via Tunnel . But even here you need to
> >use
> >a static route to make Tunnel Destination to take path via physical
> >interface !!!
> >
> >Pls. correct me if you know any other way of achieving the same .
> >
> >In essence you can not do without static route when you want to achieve
> >any-any connectivity while using any Tunnel interface ( including GRE )
> >Only exception to above rule is MPLS -TE tunnel . Here autoroute announce
> >feature does this beautifully using TE-Topology Database .
> >
> >Pls, let me know if you have any comments .
> >
> >Thanks and Regards
> >Arun .
> >
> >
> >
> >----- Original Message -----
> >From: "Scott Morris" <swm@emanon.com>
> >To: "'Arun Arumuganainar'" <aarumuga@hotmail.com>; "'Mitchell, TJ'"
> ><tmitchell@allianttech.com>; "'Thomwin Chen'" <thomwin_chen@yahoo.com>;
> >"'Loi, Choon Ho'" <ChoonHo.Loi@getronics.com>; <ccielab@groupstudy.com>
> >Sent: Tuesday, August 23, 2005 10:31 PM
> >Subject: RE: OSPF Virtual-Link & GRE
> >
> >
> > > And here I thought static routes weren't allowed on the exam!
> > >
> > > The reason static routes fix it is because the AD is lower than OSPF
is!
> >:)
> > > So you'll likely want to figure out another reason/thought on how to
fix
> > > that in case you run into something like this on the lab!
> > >
> > > Scott
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> >Arun
> > > Arumuganainar
> > > Sent: Tuesday, August 23, 2005 9:37 AM
> > > To: Mitchell, TJ; Thomwin Chen; Loi, Choon Ho; ccielab@groupstudy.com
> > > Subject: Re: OSPF Virtual-Link & GRE
> > >
> > > 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