[ninux-Firenze] Smart Gateways

[Salvatore]

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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/firenze/attachments/20140423/5c97c294/attachment-0001.html>