[ninux-Firenze] Smart Gateways

[Alessio]

Scusate la poca partecipazione è un periodo un po' incasinato. 

Il 28 io ci sarò, il 5 non so dirlo al momento. 

--
Sent from my mobile device. 

> Il giorno 23/apr/2014, alle ore 19:29, Salvatore <salvatoremoretti at tiscali.it> ha scritto:
> 
> Per me va bene sia il 28 che il 5.
>  
> 
> 
> 
> Il 22/04/2014 21:32, Salvatore ha scritto:
>> 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
>> 
>> 
>> _______________________________________________
>> Firenze mailing list
>> Firenze at ml.ninux.org
>> http://ml.ninux.org/mailman/listinfo/firenze
> 
> -- 
> Salvatore
> 
> www.TrenodelleIdee.it
> _______________________________________________
> Firenze mailing list
> Firenze at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/firenze
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/firenze/attachments/20140427/f65d0c0d/attachment-0002.html>