Bug 145464

Created attachment 109934 [details]
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).

Created attachment 109935 [details]
ifdown-gre script

Created attachment 111038 [details]
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.

*** Bug 119950 has been marked as a duplicate of this bug. ***

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.

Created attachment 113948 [details]
alternative ifup-gre script

Created attachment 113949 [details]
alternative ifdown-gre script

Created attachment 113952 [details]
alternate example GRE tunnel configuration

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

Created attachment 113981 [details]
alternative ifup-gre script

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

Created attachment 113982 [details]
alternative ifdown-gre script

updated to match alternative ifup-gre

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.

Created attachment 115086 [details]
yet another ifup-gre script

ifup-gre, based on the previous two scripts

Created attachment 115087 [details]
yet another if-down gre script

Another ifdown-gre script, based on the previous two

Created attachment 115088 [details]
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.

Created attachment 115089 [details]
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.

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

Agreed. A generic ifup/down-tunnel with a TYPE= var would make better sense.

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?

This problem is being considered for a future major release of Red Hat
Enterprise Linux. Red Hat does not currently plan to provide a resolution for
this in a Red Hat Enterprise Linux update for currently deployed systems.

With the goal of minimizing risk of change for deployed systems, and in response
to customer and partner requirements, Red Hat takes a conservative approach when
evaluating changes for inclusion in maintenance updates for currently deployed
products. The primary objectives of update releases are to enable new hardware
platform support and to resolve critical defects. 

I've just seen in RHEL 5 that ifup-tunnel and if-down tunnel have been updated
and do the job like a charm.
Thanks to everyone at RH.