Subject: Re: Tunnels and OSPF.

From: Tal Sarfaty <[email-masked]>
Date: Tue, 5 Nov 2002 11:31:20 +0200

Sanjai,
first of all thank you very much for you comment.

i think you have missed one key item in my question - that is "no externals" should be used.
when you talk about more than one process you need redistribution between the processes and of the destination tunnel.
the reason that an ASBR solution is not good for us is that we intend to have many tunnels in the AS, so we would have many externals (two for each tunnel), that cannot be summarized and would be added to any router's route rules in the AS.

instead we are looking for an ABR solution, one process - no externals.

Thanks,
Tal.

-----Original Message-----
From: Sanjai Narain [mailto:[email-masked]] 
Sent: Monday, November 04, 2002 8:10 PM
To: [email-masked]
Subject: Re: Tunnels and OSPF.

Tal: One solution that we have successfully tried is to define the VPN as a collection of GRE tunnels. Each GRE tunnel G  is protected by an IPSec tunnel between G's physical interfaces. Now, a new OSPF process is run at each router, distinct from any other OSPF process running there. This process will only see the network of GRE tunnels, and thereby route and reroute only over these. GRE gives OSPF the illusion that tunnel end points are directly connected (as intended), so you get routing over your -secure- overlay nework. The overlay OSPF process must be a new one to avoid routing loops. This is a well known solution and typing GRE/OSPF/IPSec into Google will yield numerous case studies. 
-- Sanjai Narain 

Tal Sarfaty wrote: 

  Is it possible to force the traffic flowing between the OSPF backbone and one of the other areas, to go through a tunnel (for VPN purpose for instance)?
  That is without the use of externals and without the use of static routes of course. 

  The topology can be addressed as a classic "<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />Normal areas" "no summary" single OSPF AS, or any other. 

  Note that the naive solution would create a "recursive routing" to the destination address of the tunnel. 

  The last would cause tunnel oscillations. 

  Thanks, 

  Tal. 

-- 
   Sanjai Narain 
   Senior Research Scientist 
   Telcordia Technologies 
   445 South Street 
   Morristown, NJ 07960 
   USA 
   Tel: +1 973 829 4515 Fax: +1 973 829 5888 
   Email: [email-masked]

---

From: Yasuhiro Ohara <[email-masked]>
Date: Fri, 8 Nov 2002 16:42:00 +0900

I may ask somthing stupid, but why the "gif" is not applicable in that
case ?

from NetBSD gif(4):
DESCRIPTION
     The gif interface is a generic tunnelling pseudo device for IPv4 and
     IPv6.  It can tunnel IPv[46] traffic over IPv[46].  Therefore, there can
     be four possible configurations.  The behavior of gif is mainly based on
     RFC2893 IPv6-over-IPv4 configured tunnel.

Guessing that "recursive routing" is caused by that the intermediate
router in the tunnel path can not calculate the tunnels route ...
Using gif I guess there would be no trouble with one OSPF instance,
without using External route nor redistribute.

regards,
yasu

tal> 
tal> Sanjai,
tal> first of all thank you very much for you comment.
tal>  
tal> i think you have missed one key item in my question - that is "no externals"
tal> should be used.
tal> when you talk about more than one process you need redistribution between the
tal> processes and of the destination tunnel.
tal> the reason that an ASBR solution is not good for us is that we intend to have
tal> many tunnels in the AS, so we would have many externals (two for each tunnel),
tal> that cannot be summarized and would be added to any router's route rules in
tal> the AS.
tal>  
tal> instead we are looking for an ABR solution, one process - no externals.
tal>  
tal> Thanks,
tal> Tal.
tal>  
tal> -----Original Message-----
tal> From: Sanjai Narain [mailto:[email-masked]]
tal> Sent: Monday, November 04, 2002 8:10 PM
tal> To: [email-masked]
tal> Subject: Re: Tunnels and OSPF.
tal> 
tal>  
tal> Tal: One solution that we have successfully tried is to define the VPN as a
tal> collection of GRE tunnels. Each GRE tunnel G  is protected by an IPSec tunnel
tal> between G's physical interfaces. Now, a new OSPF process is run at each
tal> router, distinct from any other OSPF process running there. This process will
tal> only see the network of GRE tunnels, and thereby route and reroute only over
tal> these. GRE gives OSPF the illusion that tunnel end points are directly
tal> connected (as intended), so you get routing over your -secure- overlay nework.
tal> The overlay OSPF process must be a new one to avoid routing loops. This is a
tal> well known solution and typing GRE/OSPF/IPSec into Google will yield numerous
tal> case studies.
tal> 
tal> -- Sanjai Narain
tal> 
tal> Tal Sarfaty wrote:
tal> 
tal>     Is it possible to force the traffic flowing between the OSPF backbone and
tal>     one of the other areas, to go through a tunnel (for VPN purpose for
tal>     instance)?
tal> 
tal>     That is without the use of externals and without the use of static routes
tal>     of course.
tal> 
tal>     The topology can be addressed as a classic "<?xml:namespace prefix = st1
tal>     ns = "urn:schemas-microsoft-com:office:smarttags" />Normal areas" "no
tal>     summary" single OSPF AS, or any other.
tal> 
tal>     Note that the naive solution would create a "recursive routing" to the
tal>     destination address of the tunnel.
tal> 
tal>     The last would cause tunnel oscillations.
tal> 
tal>     Thanks,
tal> 
tal>     Tal.
tal> 
tal> --
tal>    Sanjai Narain
tal>    Senior Research Scientist
tal>    Telcordia Technologies
tal>    445 South Street
tal>    Morristown, NJ 07960
tal>    USA
tal>    Tel: +1 973 829 4515 Fax: +1 973 829 5888
tal>    Email: [email-masked]
tal>