<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Ciao ml ,<br>
visto l'interesse di ieri per l'argomento SMART GATEWAYS č
probabile che <br>
questo stralcio da <br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-15">
<a
href="https://github.com/servalproject/olsr/blob/master/README-Olsr-Extensions">https://github.com/servalproject/olsr/blob/master/README-Olsr-Extensions</a><br>
possa essere di aiuto come introduzione all'argomento e come spunto
per un<br>
howto<br>
<br>
<br>
5.) Smart gateways (asymmetric gateway tunnels)<br>
*******************************************************<br>
5.1) Introduction<br>
The smart gateway mechanism was written by Markus Kittenberger and<br>
Henning Rogge to allow an OLSR user to directly choose their default<br>
Internet gateway instead of relying on the hop by hop decisions on<br>
the way to the gateway. OLSRd 0.6.0 can create an IPIP tunnel<br>
to the gateway's OLSRd address to side-step the same nasty effects<br>
described in the NAT-Threshold section.<br>
The smart gateway code can be split into two sections, one is<br>
responsible for announcing the existence of a smart gateway uplink<br>
and one (on the client nodes) to choose an uplink and create the<br>
tunnel to the gateway. The announcing code uses a modified (but<br>
backward compatible) special HNA to signal the gateways to the<br>
clients. The clients can use a plugin (or the integrated default<br>
code) to choose one of the available gateways and change it if<br>
necessary.<br>
The smart gateway system is setup by several configuration
parameters,<br>
most of them with a sane default setting. The whole system can be<br>
switched on/off by the following parameter:<br>
SmartGateway <yes/no><br>
All other parameters will be ignored if SmartGateway is set to "no"<br>
(the default is "no").<br>
5.2) Client Side<br>
1- SmartGatewayAllowNAT controls whether you want to allow the
selection<br>
of an outgoing ipv4 gateway with NAT (Network Address Translation).<br>
The default setting is "yes".<br>
2- SmartGatewayPeriod determines the period (in milliseconds) on
which<br>
a new smart gateway selection is performed.<br>
The default setting is 10000 milliseconds.<br>
3- SmartGatewayStableCount determines the number of times the link
state<br>
database must be stable before a new smart gateway is selected.<br>
The default setting is 6.<br>
4- SmartGatewayThreshold controls whether you want to allow
re-selection<br>
of a new outgoing gateway if its routing cost is lower or equal to
the<br>
configured percentage of the routing cost of the current gateway.<br>
The default setting is 0, which disables it.<br>
5- SmartGatewayWeightExitLinkUp, SmartGatewayWeightExitLinkDown,<br>
SmartGatewayWeightEtx and SmartGatewayDividerEtx control the
weighing<br>
of gateway bandwidth and ETX costs.<br>
If SmartGatewayDividerEtx is zero then no weighing is performed
(classical<br>
behaviour). Classical behaviour only takes ETX costs into account
when<br>
choosing a gateway (select the 'nearest' gateway).<br>
The weighing also takes the gateway bandwidths into account (select
the<br>
'nearest fat pipe' gateway).<br>
Gateways that have zero bandwidth for either their uplink or
downlink are<br>
ignored.<br>
* The Weighing Process<br>
======================<br>
** Configuration Parameters =<br>
=========================== =<br>
SmartGatewayWeightExitLinkUp =<br>
SmartGatewayWeightExitLinkDown =<br>
SmartGatewayWeightEtx <br>
SmartGatewayDividerEtx <br>
** Gateway Parameters = gateway exit link uplink , in Mbps<br>
=========================== = gateway exit link downlink, in Mbps<br>
gw->uplink <br>
(Mbps) <br>
gw->downlink (Mbps) <br>
gateway exit link uplink weight<br>
gateway exit link downlink weight<br>
ETX path cost weight<br>
ETX path cost divider<br>
** Weighing Formula<br>
===================<br>
path_cost_weighed =<br>
SmartGatewayWeightExitLinkUp<br>
---------------------------- +<br>
gw->uplink (Mbps)<br>
SmartGatewayWeightExitLinkDown<br>
------------------------------ +<br>
gw->downlink (Mbps)<br>
SmartGatewayWeightEtx<br>
---------------------- * path_cost<br>
SmartGatewayDividerEtx<br>
** Recommended Configuration Parameter Settings<br>
===============================================<br>
SmartGatewayWeightExitLinkUp<br>
= 1 (default is 1)<br>
SmartGatewayWeightExitLinkDown = 1 (default is 1)<br>
SmartGatewayWeightEtx<br>
= 1 (default is 1)<br>
SmartGatewayDividerEtx<br>
= 4 (default is 0)<br>
5.3) Uplink Side<br>
1- SmartGatewayUplink defines which kind of uplink is exported to
the<br>
other mesh nodes. The existence of the uplink is detected by looking<br>
for a local HNA of 0.0.0.0/0, ::ffff:0:0/96 or 2000::/3. The default<br>
setting is "both".<br>
2- SmartGatewayUplinkNAT defines if the ipv4 part of the uplink uses
NAT.<br>
The default of this setting is "yes".<br>
3- SmartGatewaySpeed sets the uplink and downlink speed of the
gateway,<br>
which could be used by a plugin to choose the right gateway for a<br>
client. The default is 128/1024 kbit/s.<br>
4- SmartGatewayPrefix can be used to signal the external IPv6 prefix
of<br>
the uplink to the clients. This might allow a client to change it's<br>
local IPv6 address to use the IPv6 gateway without any kind of
address<br>
translation. The maximum prefix length is 64 bits,<br>
the default is ::/0 (no prefix).<br>
5.4) Architecture & Notes<br>
On the smart gateway server (the OLSR instance announcing 'Internet
here!' via<br>
HNA 0/0 or similar) the implicit tunl0 interface is used to forward
incoming<br>
packets originating on smart gateway clients to the Internet route.
This may be<br>
protected by the sysctl rp_filter setting. Note, that at least with
RedHat<br>
kernel 2.6.18, the net.ipv4.conf.tunl0.rp_filter sysctl file is not
present<br>
after loading the "ipip" kernel module, which prevents OLSRd from
switching off<br>
the filter. As a workaround, add an "ip addr add 0.0.0.0/32 dev
tunl0" after<br>
the "modprobe ipip" line in your OLSRd startup script.<br>
While the smart gateway function does a fine job on stand-alone PCs,
system<br>
builders should keep in mind the following facts when setting up
routing,<br>
firewalls and gateways:<br>
a) The smart gateway tunnel communicates asymmetrically. An IP
packet destined<br>
for an Internet server is sent via the IPIP tunnel but returned via
the<br>
standard OLSRd host route.<br>
b) On the smart gateway server, you should double check your
firewall rules and<br>
rp_filter defaults. While it's normally not possible to simply
encapsulate<br>
(for example) a "telnet 127.0.0.1" into IPIP and sent that to the
smart<br>
gateway server, your specific configuration may open up such attack
vectors<br>
for an intruder.<br>
c) Do not forget to open up the firewall for tunl0->Internet
traffic and (if<br>
required to NAT/MASQUERADE) this communication path.<br>
d) While the smart gateway server does not use special routing, the
smart<br>
gateway client inserts policy routing rules for it's function. By
using the<br>
default configuration, the OLSRd standard default route is
maintained in<br>
table 223 and the OLSRd smart gateway default route in table 224.
Both<br>
tables are examined only, if you do not have a default route in the
main<br>
table (visible with "ip route ls"). Use "ip route ls table 223" or<br>
"ip route ls table 224" for debugging/monitoring. You may also
activate the<br>
txtinfo plugin and do a "wget -O - <a class="moz-txt-link-freetext" href="http://localhost:2006/gateway">http://localhost:2006/gateway</a>".<br>
e) For a standalone client (a notebook user running OLSRd in order
to browse)<br>
the lowered IPIP tunnel MTU is no problem. If you do proxy routing,
e.g. for<br>
attached LAN clients without OLSRd, you may want MSS-clamping for
the tunnel<br>
interface created by OLSRd. Because OLSRd uses an arbitrary name for
the<br>
tunnel interface (e.g. tnl_7c41c668) you may want to include a
wildcard<br>
iptables rule. Example:<br>
<br>
iptables -A FORWARD -o tnl_+ -p tcp --tcp-flags SYN,RST SYN -j
TCPMSS --clamp-mss-to-pmtu<br>
<br>
Furthermore (or alternatively) you might consider (on your gateway
nodes)<br>
clamping all traffic leaving your mesh to your ipip mtu (regardless
if the<br>
traffic comes out of the smart gateway tunnel or not!). Example:<br>
<br>
iptables -A FORWARD -o [your_gateway_interface] -p tcp --tcp-flags
SYN,RST SYN -j TCPMSS --set-mss 1480<br>
<br>
Especially as during OLSRd startup, before an smart gateway is
chosen (which is<br>
delayed), new connections would use a larger MSS than the smart
gateway tunnel<br>
can handle. So the approach to clamp on the gateways should give
better results.<br>
But if you don't NAT on your gateways (but want to use smart gateway
for some<br>
special reason), you would have to do this on ALL gateways (even on
gateways<br>
that do not provide the smart gateway functionality!).<br>
<br>
6.) NatThreshold<br>
************************<br>
The NatThreshold option was introduced by Sven Ola to suppress a
very annoying<br>
problem with OLSRd, switching default gateways. If a router is
located between<br>
two Internet gateways with similar path costs the default route
(0.0.0.0/0)<br>
will constantly switch between the two gateways due to normal
fluctuations of<br>
the link metrics. Whenever OLSRd decides that the other NAT gateway
is<br>
"better", then switching to this new gateway will result in
termination of all<br>
connected sessions (TCP and HTTP).<br>
The user experience will be rather painful and users will experience
hanging<br>
SSH and HTTP sessions (or anything using TCP).<br>
NatThreshold<br>
choosing the<br>
a lower cost<br>
NatThreshold<br>
In short:<br>
tries to<br>
route to<br>
than the<br>
the node<br>
help by introducing a hysteresis factor for<br>
the default gateway. Only if the new gateway has<br>
current gateways path cost multiplied by<br>
will switch the gateway.<br>
<br>
<br>
if (cost(new_gateway) < cost(current_gw)*NatThreshold)) {<br>
switch_gateway();<br>
}<br>
<br>
<br>
<br>
Practical experience shows that this leads to much better quality of
default<br>
gateway selection, even if (in theory) a small NatThreshold together
with<br>
Fisheye can lead to persistent routing loops.<br>
Please note that even with NatThreshold enabled, some users will
still<br>
experience gateway switching. However, most users will not.<br>
Smart Gateways can replace NatThreshold all together because they
allow sending<br>
traffic directly to a gateway circumventing the problems described
above which<br>
stem from a hop-by-hop routing approach<br>
<br>
<div class="moz-signature">-- <br>
<span style="color:blue">
<p><b>Salvatore</b></p>
</span>
<span style="color:green"><b href="http://www.trenodelleidee.it"><a class="moz-txt-link-abbreviated" href="http://www.TrenodelleIdee.it">www.TrenodelleIdee.it</a></b></span>
</div>
</body>
</html>