+++ This bug was initially created as a clone of Bug #145464 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111
Firefox/1.0

Description of problem:
There are no network scripts for GRE tunnels.
I've tried creating some by adapting from the sit ones.

I've attached them to this bug and also attached an example ifcfg-gre1 file.

Version-Release number of selected component (if applicable):
initscripts-7.93.5-1

How reproducible:
Always

Steps to Reproduce:
Try to configure the vpn interface for automatic start and it won't work. There
are no ifcfg-gre standard, no ifup-gre and no ifdown-gre script.

Actual Results:  Nothing

Expected Results:  A method to do this configuration in a standard way.

Additional info:

-- Additional comment from razvan.vilt on 2005-01-18 13:55 EST --
Created an attachment (id=109934)
ifup-gre script

Can be extended and modified to meet the requirements for an inclusion in the
package if so requested. It should work on Fedora Core 3 (tested) and RHEL 3
(tested).

-- Additional comment from razvan.vilt on 2005-01-18 13:57 EST --
Created an attachment (id=109935)
ifdown-gre script


-- Additional comment from razvan.vilt on 2005-02-13 10:22 EST --
Created an attachment (id=111038)
Example of a gre configuration

It just works right now. I can tweak-it/improve-it if anyone @redhat is
interested to include-it in the initscripts. I can add support for for other
tunnel types.

-- Additional comment from notting on 2005-02-14 13:40 EST --
*** Bug 119950 has been marked as a duplicate of this bug. ***

-- Additional comment from edh+bugzilla.edu on 2005-05-02 17:34 EST --
I second the call for a GRE tunnel script, but have a few concerns.
We're using GRE tunnels and I too have written my own if{up,down}
scripts.  It took me a while to nail down a scheme which worked well for
satellite nodes, i.e. GRE peers not exporting a network of their own.
I specifically wanted the nodes of the private network to be able to
access the satellite systems by their public IP addresses, without
transiting the public network.  This can be done, but requires the use
of a routing table applicable only to the private network.  See the
forthcoming attachments for the details.

I also wished to avoid the necessity of exposing the gateway's address
on the private network and fabricating unique special-purpose address
for the satellite nodes.  I admit that this is more of an aesthetic than
practical point.  In our setup, the inner and outer addresses of the
tunnel are the same.  The routing solution previously mentioned makes
this feasible.

I appreciate the desire for consistency I see in the use of the standard
variable names such as IPADDR and NETMASK, but when there are four
variables all ending in IPADDR, the drawbacks of potential confusion
outweighs the benefits, IMHO.  The TUNNEL_* variables are especially
confusing.  Every address in the config file relates to the tunnel and
the TUNNEL_* variables aren't even the addresses I most closely associate
with the tunnel, those /of/ the tunnel rather than those /used by/ the
tunnel.  I would really like to see variable names which more clearly
show the relationship.  The best I could think of were INNER and OUTER,
but LOGICAL and PUBLIC or something of the kind would also do well.
The only drawback of INNER and OUTER that I see is that it introduces a
dimension of locality which conflicts with LOCAL and REMOTE, but then
I am content with MY and PEER as alternatives.  I use _NET instead of
_NETWORK intentionally, since unlike the old NETWORK variable, these
should contain both network and netmask (e.g 10.0.0.0/24).  This allows
multiple routing targets to be specified sanely.

I think that it would also be appropriate to automatically poke holes
in the firewall as needed, but I think it a lesser point.

-- Additional comment from edh+bugzilla.edu on 2005-05-02 17:36 EST --
Created an attachment (id=113948)
alternative ifup-gre script


-- Additional comment from edh+bugzilla.edu on 2005-05-02 17:38 EST --
Created an attachment (id=113949)
alternative ifdown-gre script


-- Additional comment from edh+bugzilla.edu on 2005-05-02 17:41 EST --
Created an attachment (id=113952)
alternate example GRE tunnel configuration

This is an example configuration from one of our satellite nodes.

-- Additional comment from edh+bugzilla.edu on 2005-05-03 15:44 EST --
Created an attachment (id=113981)
alternative ifup-gre script

Improve comments, omit peer inner ip instead of deleting automatic route

-- Additional comment from edh+bugzilla.edu on 2005-05-03 15:50 EST --
Created an attachment (id=113982)
alternative ifdown-gre script

updated to match alternative ifup-gre

-- Additional comment from sean on 2005-06-02 10:13 EST --
I too have need of ifup-gre and ifdown-gre scripts.  I looked at the original
scripts submitted and the alternates and decided that neither would do what I
needed.

Regarding the original set submitted by Razvan Corneliu C.R. VILT, I agreed with 
Aaron Hope that the configuration variables weren't as clear as they could be.
Also, there was no support for adding routes for reaching multiple remote
networks over the tunnel, something which I have need for.  There were also
things left over in it from the ifup-sit script which I thought could use some
cleaning up.

As far as the second set by Aaron Hope, I was pretty impressed with it and my
scripts are, for the most part, based around it.  I removed the requirement to 
specify the MY_OUTER_IPADDR variable because in all my testing I didn't find it 
necessary to specify it.  I modified it in form in an attempt to have it more 
closely match the type of scripts that Red Hat is currently writing for the 
other network scripts.  I removed all the references to iptables.  In my opinion 
it is the administrators job to ensure that the firewalling is set properly.  I 
don't want my iptables rules modified by my interface scripts.  If the iptables 
rules are to be modified, then surely it should be done as in ifup-post and only  
to the RH-Lokkit rules.  Same reasoning for the forwarding - if I want it I know  
where it shoudl be set.  Doing it here violates the rule of least surprise, in 
my opinion.

The one part of Aaron's script which I left but didn't test or modify was the 
for loop that modifies the routing policy rules.  The reasoning as explained 
made sense so I left it but I wasn't setup to test it.

Many thanks to both of the original submitters for doing most of the leg work I 
used to craft these.  I plan to use them in production shortly without any 
additional adjustment.

I will attach these shortly as the "yetanother" series of attachments.

-- Additional comment from sean on 2005-06-02 10:15 EST --
Created an attachment (id=115086)
yet another ifup-gre script

ifup-gre, based on the previous two scripts

-- Additional comment from sean on 2005-06-02 10:16 EST --
Created an attachment (id=115087)
yet another if-down gre script

Another ifdown-gre script, based on the previous two

-- Additional comment from sean on 2005-06-02 10:19 EST --
Created an attachment (id=115088)
patch to support GRE devicetype in network-functions

In order to be able to use 'TYPE=GRE' in the configuration this patch to
/etc/sysconfig/network-scripts/network-functions is required.

I am actually not going to run with this patch but instead specify
DEVICETYPE=gre
in my ifcfg script, but I include it here for completeness.

-- Additional comment from sean on 2005-06-02 10:21 EST --
Created an attachment (id=115089)
yet another ifcfg sample, with comments

I have tried to comment all the options you would want to specify, with the
exception of the 'MY_PRIVATE_NET' one I took straight from Aaron's script but
have never used/tested and didn't feel qualified to try to summarize.


-- Additional comment from razvan.vilt on 2005-06-02 15:56 EST --
I saw some very good points raised here, this bug is actually starting to sound
interesting.
I think that the gre tunnels script should be a generic iproute tunnel script. A
simple variable should mention if it's a gre or ipip or some other type of
tunnel. I am actually saying this because there are some other folks out there
that use other tunnel types (ipip to cisco routers for example) and this would
really give them a helping hand. This is because no matter the tunnel type, the
ip command usage is almost identical. This would simplify the life for the other
guys and would be shooting two rabbits at once. I'll look at the other scripts
and try to figure out a way to have all these things together + a patch for
system-config-network if I have the time. I make no promises though.

Best regards

-- Additional comment from dr on 2005-06-04 18:44 EST --
Agreed. A generic ifup/down-tunnel with a TYPE= var would make better sense.

-- Additional comment from edh+bugzilla.edu on 2005-07-15 22:56 EST --
I have looked over Sean E. Millichamp's versions, and don't have any real
objections.  Regarding MY_OUTER_IPADDR, I agree that it is not usually
necessary.  My intent was for most people to need to specify {MY,PEER}_IPADDR
only, in which case MY_OUTER_IPADDR would pick up a sensible default.  It might
have been there to support some whacky corner case, but it's been to long for me
to remember.

I notice that most of the quoting has been removed.  This is one of those things
that I consider a good habit.  What is the rationale here?  

To the best of my knowledge, the scripts are compliant posix shell scripts,
going so far as to favor grep -E over egrep, so I would prefer to keep #!/bin/sh.  

I have no objections regarding the forwarding and firewall mutation removal.  I
put it in partly as a convenience, and partly because I hadn't realized that the
firewall could contain references to as-yet-non-existent interfaces.

As for the ifcfg sample MY_PRIVATE_NET description, how about this:
# MY_PRIVATE_NET: One or more networks which we wish to expose to the remote
#   gateway.  Without this, outgoing traffic to the remote networks will be
#   routed correctly, but traffic addressed to the remote gateway itself may
#   not be.  Multiple networks can be specified by separating each network with
#   a space.
MY_PRIVATE_NET="192.168.2.0/24 10.10.10.0/24"

A larger concern of mine is the nomenclature.  When I first looked at these
scripts today, the INNER/OUTER distinction seemed completely backwards, until
the whole picture inverted like seeing the other image in an optical illusion. 
The the LAN-centric view of internal/external, the protocol nesting view, and
the linear traffic path view are all valid, but contradictory.  If they're that
arbitrary, I think that INNER and OUTER really ought to go.  How about a
stratification analogy instead: the pre-existing addresses as substratum
logically "below" the new addresses introduced by the tunnel?  Or perhaps
degrees of substance? Some possibilities:
  PRIVATE / PUBLIC
  LOWER   / UPPER
  SUB     / HYPER
  INFRA   / SUPER
  BASE    / ABSTRACT
  BASE    / CONSTRUCT
I'm not fully satisfied by any of those, but I guess I like PRIVATE / PUBLIC the
best.  Thoughts?