[ninux-Firenze] Smart Gateways

[Salvatore]

Ciao ml ,
  visto l'interesse di ieri per l'argomento SMART GATEWAYS è probabile che
  questo stralcio da
https://github.com/servalproject/olsr/blob/master/README-Olsr-Extensions
possa essere di aiuto  come introduzione all'argomento e come spunto per un
  howto


5.) Smart gateways (asymmetric gateway tunnels)
*******************************************************
5.1) Introduction
The smart gateway mechanism was written by Markus Kittenberger and
Henning Rogge to allow an OLSR user to directly choose their default
Internet gateway instead of relying on the hop by hop decisions on
the way to the gateway. OLSRd 0.6.0 can create an IPIP tunnel
to the gateway's OLSRd address to side-step the same nasty effects
described in the NAT-Threshold section.
The smart gateway code can be split into two sections, one is
responsible for announcing the existence of a smart gateway uplink
and one (on the client nodes) to choose an uplink and create the
tunnel to the gateway. The announcing code uses a modified (but
backward compatible) special HNA to signal the gateways to the
clients. The clients can use a plugin (or the integrated default
code) to choose one of the available gateways and change it if
necessary.
The smart gateway system is setup by several configuration parameters,
most of them with a sane default setting. The whole system can be
switched on/off by the following parameter:
SmartGateway <yes/no>
All other parameters will be ignored if SmartGateway is set to "no"
(the default is "no").
5.2) Client Side
1- SmartGatewayAllowNAT controls whether you want to allow the selection
of an outgoing ipv4 gateway with NAT (Network Address Translation).
The default setting is "yes".
2- SmartGatewayPeriod determines the period (in milliseconds) on which
a new smart gateway selection is performed.
The default setting is 10000 milliseconds.
3- SmartGatewayStableCount determines the number of times the link state
database must be stable before a new smart gateway is selected.
The default setting is 6.
4- SmartGatewayThreshold controls whether you want to allow re-selection
of a new outgoing gateway if its routing cost is lower or equal to the
configured percentage of the routing cost of the current gateway.
The default setting is 0, which disables it.
5- SmartGatewayWeightExitLinkUp, SmartGatewayWeightExitLinkDown,
SmartGatewayWeightEtx and SmartGatewayDividerEtx control the weighing
of gateway bandwidth and ETX costs.
If SmartGatewayDividerEtx is zero then no weighing is performed (classical
behaviour). Classical behaviour only takes ETX costs into account when
choosing a gateway (select the 'nearest' gateway).
The weighing also takes the gateway bandwidths into account (select the
'nearest fat pipe' gateway).
Gateways that have zero bandwidth for either their uplink or downlink are
ignored.
* The Weighing Process
======================
** Configuration Parameters =
=========================== =
SmartGatewayWeightExitLinkUp =
SmartGatewayWeightExitLinkDown =
SmartGatewayWeightEtx
SmartGatewayDividerEtx
** Gateway Parameters = gateway exit link uplink , in Mbps
=========================== = gateway exit link downlink, in Mbps
gw->uplink
(Mbps)
gw->downlink (Mbps)
gateway exit link uplink weight
gateway exit link downlink weight
ETX path cost weight
ETX path cost divider
** Weighing Formula
===================
path_cost_weighed =
SmartGatewayWeightExitLinkUp
---------------------------- +
gw->uplink (Mbps)
SmartGatewayWeightExitLinkDown
------------------------------ +
gw->downlink (Mbps)
SmartGatewayWeightEtx
---------------------- * path_cost
SmartGatewayDividerEtx
** Recommended Configuration Parameter Settings
===============================================
SmartGatewayWeightExitLinkUp
= 1 (default is 1)
SmartGatewayWeightExitLinkDown = 1 (default is 1)
SmartGatewayWeightEtx
= 1 (default is 1)
SmartGatewayDividerEtx
= 4 (default is 0)
5.3) Uplink Side
1- SmartGatewayUplink defines which kind of uplink is exported to the
other mesh nodes. The existence of the uplink is detected by looking
for a local HNA of 0.0.0.0/0, ::ffff:0:0/96 or 2000::/3. The default
setting is "both".
2- SmartGatewayUplinkNAT defines if the ipv4 part of the uplink uses NAT.
The default of this setting is "yes".
3- SmartGatewaySpeed sets the uplink and downlink speed of the gateway,
which could be used by a plugin to choose the right gateway for a
client. The default is 128/1024 kbit/s.
4- SmartGatewayPrefix can be used to signal the external IPv6 prefix of
the uplink to the clients. This might allow a client to change it's
local IPv6 address to use the IPv6 gateway without any kind of address
translation. The maximum prefix length is 64 bits,
the default is ::/0 (no prefix).
5.4) Architecture & Notes
On the smart gateway server (the OLSR instance announcing 'Internet 
here!' via
HNA 0/0 or similar) the implicit tunl0 interface is used to forward incoming
packets originating on smart gateway clients to the Internet route. This 
may be
protected by the sysctl rp_filter setting. Note, that at least with RedHat
kernel 2.6.18, the net.ipv4.conf.tunl0.rp_filter sysctl file is not present
after loading the "ipip" kernel module, which prevents OLSRd from 
switching off
the filter. As a workaround, add an "ip addr add 0.0.0.0/32 dev tunl0" after
the "modprobe ipip" line in your OLSRd startup script.
While the smart gateway function does a fine job on stand-alone PCs, system
builders should keep in mind the following facts when setting up routing,
firewalls and gateways:
a) The smart gateway tunnel communicates asymmetrically. An IP packet 
destined
for an Internet server is sent via the IPIP tunnel but returned via the
standard OLSRd host route.
b) On the smart gateway server, you should double check your firewall 
rules and
rp_filter defaults. While it's normally not possible to simply encapsulate
(for example) a "telnet 127.0.0.1" into IPIP and sent that to the smart
gateway server, your specific configuration may open up such attack vectors
for an intruder.
c) Do not forget to open up the firewall for tunl0->Internet traffic and (if
required to NAT/MASQUERADE) this communication path.
d) While the smart gateway server does not use special routing, the smart
gateway client inserts policy routing rules for it's function. By using the
default configuration, the OLSRd standard default route is maintained in
table 223 and the OLSRd smart gateway default route in table 224. Both
tables are examined only, if you do not have a default route in the main
table (visible with "ip route ls"). Use "ip route ls table 223" or
"ip route ls table 224" for debugging/monitoring. You may also activate the
txtinfo plugin and do a "wget -O - http://localhost:2006/gateway".
e) For a standalone client (a notebook user running OLSRd in order to 
browse)
the lowered IPIP tunnel MTU is no problem. If you do proxy routing, e.g. for
attached LAN clients without OLSRd, you may want MSS-clamping for the tunnel
interface created by OLSRd. Because OLSRd uses an arbitrary name for the
tunnel interface (e.g. tnl_7c41c668) you may want to include a wildcard
iptables rule. Example:

iptables -A FORWARD -o tnl_+ -p tcp --tcp-flags SYN,RST SYN  -j TCPMSS 
--clamp-mss-to-pmtu

Furthermore (or alternatively) you might consider (on your gateway nodes)
clamping all traffic leaving your mesh to your ipip mtu (regardless if the
traffic comes out of the smart gateway tunnel or not!). Example:

iptables -A FORWARD -o [your_gateway_interface] -p tcp  --tcp-flags 
SYN,RST SYN -j TCPMSS --set-mss 1480

Especially as during OLSRd startup, before an smart gateway is chosen 
(which is
delayed), new connections would use a larger MSS than the smart gateway 
tunnel
can handle. So the approach to clamp on the gateways should give better 
results.
But if you don't NAT on your gateways (but want to use smart gateway for 
some
special reason), you would have to do this on ALL gateways (even on gateways
that do not provide the smart gateway functionality!).

6.) NatThreshold
************************
The NatThreshold option was introduced by Sven Ola to suppress a very 
annoying
problem with OLSRd, switching default gateways. If a router is located 
between
two Internet gateways with similar path costs the default route (0.0.0.0/0)
will constantly switch between the two gateways due to normal 
fluctuations of
the link metrics. Whenever OLSRd decides that the other NAT gateway is
"better", then switching to this new gateway will result in termination 
of all
connected sessions (TCP and HTTP).
The user experience will be rather painful and users will experience hanging
SSH and HTTP sessions (or anything using TCP).
NatThreshold
choosing the
a lower cost
NatThreshold
In short:
tries to
route to
than the
the node
help by introducing a hysteresis factor for
the default gateway. Only if the new gateway has
current gateways path cost multiplied by
will switch the gateway.


if (cost(new_gateway) < cost(current_gw)*NatThreshold)) {
switch_gateway();
}



Practical experience shows that this leads to much better quality of default
gateway selection, even if (in theory) a small NatThreshold together with
Fisheye can lead to persistent routing loops.
Please note that even with NatThreshold enabled, some users will still
experience gateway switching. However, most users will not.
Smart Gateways can replace NatThreshold all together because they allow 
sending
traffic directly to a gateway circumventing the problems described above 
which
stem from a hop-by-hop routing approach

-- 

*Salvatore*

*www.TrenodelleIdee.it*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/firenze/attachments/20140422/f74de220/attachment-0001.html>