From: Arun Arumuganainar (aarumuga@hotmail.com)
Date: Thu May 04 2006 - 04:28:03 ART
Let us take the following example .
Pls. Note : By reading your mail I could not really understand what is your
over all objective . I have assumed you problem statement might look like
this . Pls. correct if I am wrong in interpreting your requirement .
R0---R1----R2-----R3----R4
|--------------|
Gre Tun
Lets us assume the case R0, R1 , R2 , R3 , R4 are serially connected as in
the figure . Here the objective is to use GRE Tunnel for all traffic from R0
to R4 and from R4 to R0 . This type of requirement is very common under
couple of circumstances .
1) You wanted to do easy accounting of traffic running between R0 and R4.
2) R0-R1 and R3-R4 are configured with different address-space than the rest
of the network ( This is typically VPN scenario ) .
Under this circumsatances we will normally employ two kinds of solution . I
will explain this in detail .
Solution 1 : Two protocol solution .
-------------------------------------
Here you configure two protocols on R1 and R3 . This is typically done when
you are trying to solve objective 2 ( VPN Requirement ) .Configuration in
such a case will look like the one listed below .
a) Protocol A : Runs on R0, R4 , R1 ( only on Interface facing R0 and
Tun interface ) & R3 ( only on Interface facing R4 and Tun interface )
b) Protocol B : Runs on R2 , R1 & R3 ( only on interface facing R2 )
Pls. Note : Care should be taken that R1's physical interface facing R2
should not leaked in to Tunnel interface at any cost !!! When this is
ensured things will work just fine
Solution 2 : Single protocol Solution ( Solves Accounting problems ) .
--------------------------------------------------------------------
Here you will configure the r1 and R3 in the following fashion .
1) Enable the protocol on all interfaces including the Tunnel interface and
Physical interface facing R2
2) Configure Worser metric on Physical interface so that route learned via
tunnel end point is always Preferred .
3) Configure a static Host route for the tunnel destination address on R1
and R3 and point it towards physical interface facing R2.
Some Gotchas for this scenario :-
~~~~~~~~~~~~~~~~~~~~~~~
a) If you do not alter the metric on the physical interface , Route learned
from physical interface will always be preferred . And Tunnel interface will
never be used .
b) After Configuring higher metric if you do not configure the static host
route ( point 3 ) then you will notice that tunnel interface will flap
continuously and traffic will not really go through .
Pls. Note : In case you have configured MPLS TE Tunnel instead of GRE tunnel
You need not go through Step 2 and 3 as described above . What you have to
do in this case is to simply turn on auto-route-announce on the TE tunnel .
Hope this helps .
Thanks and Regards
Arun
----- Original Message -----
From: <darbyweaver@yahoo.com>
To: <ccielab@groupstudy.com>
Sent: Thursday, May 04, 2006 8:51 AM
Subject: Recursive Routing
> Options for Resolving the issue:
>
> The logic seems to be to never learn about the destination of the tunnel
through the tunnel itself.
>
> Here is my list of options to stop the recursive routing issue.
>
> 1) Filter the route from being sent down the tunnel or learned through the
tunnel.
> 2) Use static routes to reach the destination of the tunnel to override
the dynamic route learned via the tunnel (might not be an option)
> 3) Do not use the same routing protocol within the tunnel that is being
used to learn the destination of the tunnel.
> 4) Alter the metric so that the dynamic route learned via the tunnel is
never preferred (i.e. with the Distance Command - aka Route Poison)
>
>
> Anyone want to add more?
>
> Thanks
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:20 ART