[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 14 Sep 2014, at 11:22, Gordon Henderson <gordon+lug@xxxxxxxxxx> wrote:
> On Sun, 14 Sep 2014, Simon Avery wrote:
>
>> Also - why not take benefit from load balancing and effectively doubling
>> your downstream (in multi-fetch uses like webpages) if it's easy?
>
> It's not always that easy )-:
>
> An issue you'll find - and I've had it in the past - is that you go to a web site,
> the load balancer sends the first request via the first ISP connection, then you
> login in/authenticate, then the next request you send goes via the 2nd ISP - and
> then the remote site goes: "woa, you changed IP addresses, login again".
>
> This happens especially with banks and some other ecommerce sites.
>
> There are ways to make is such that all data to a site is kept to one ISPs
> connection, but even then I've had issues when the remote sites use different
> servers to serve content - and if each of those servers use the same
> authentication, then that fails too. Again banks seem to be the worst for this
> sort of thing.
>
> That's not perfect as then all accesses to that particular remote site will be
> cached into that one ISPs connection - so when everyone in the office accesses
> Dilbert, it all uses one ISP connection with the other sitting idle...
>
> What you can do is arrange for the load balancing to work based on the source IP
> address - ie. the PC on the inside connecting to the outside, so that all
> transactions from that PC go via one ISP - until there have been no data
> transfered for some time then that PCs internal IP can go back into the balancing
> pool to work out which ISP connection to use for the next transaction - that's not
> perfect though and you still end up with situations like the above -either one
> ISPs line being saturated, or your time-out not being long enough so the remote
> site sees an IP address change and wants you to re-authenticate with it.
>
> But apart from sites which authenticate on every transaction that sort of load
> balancing works relatively OK and is a cheap solution.
>
> Gordon
>
== Managed vs Unmanaged ==
Unmanaged:
Using an unmanaged bonded connection for direct access to the web is trouble.
[Local—===== Internet]
you should use it only for a P2P link where the network concentrates at the other
end before going to the net. i.e. [Local—====—> Internet ]
Managed:
Most managed setups use the dual link as a simple failover or to traffic shape: thus
send traffic per a ink based on type or class of data.
i.e. send all video & audio streams via route 1 and everything else via route 2.
To do shaping you need some form of active packet inspection on the main router to
decide which onward route that packet needs to take. (or you can do this with an old
linux box with 3 nic’s. and some iptables rules.
—— Lan switch ——>< bastion host with traffic shaping & firewall & nat (nic 0) ---
forwards to
if type != UDP -> (DMZ1)router 1(Outside1) >—< ADSL
In Bridge mode <—> Internet
if type == UDP> (DMZ2)router 2(Outside2) >—< ADSL in
Bridge mode <—> Internet
Note - if the router is also the ADSL modem, it's optional to have 2 devices as most
basic ADSL Routers will work, however out of the box they will use nat and thats bad
because you don’t want to Double NAT your traffic. hence I prefer running the ADSL
in bridge mode and using the Router to initialise the pppoe and thus has a real ip
on the outside edge of the router. The inside edge can be a private route and there
will only be the the respective private ip's for DMZ 1 and DMZ 2
i.e.
Lan (nic0) : 192.168.10.1/255 (DHCP/NAT/Local DNS )
DMZ1(nic1) 10.0.2.1 & 10.0.2.254(router 1 lan) (NAT off, DHCP can be on off on a
custom range - set router address = 10.0.2.254)
DMZ2(nic2) 10.0.3.1 & 10.0.2.254(router 2 pan) (Nat off, DHCP can be on using a
custom range - set router address = 10.0.3.154 )
Outside 1 (router 1 wan) (isp assigned details or static )
Outside 2 (router 2 wan) (isp assigned details or static)
> --
> The Mailing List for the Devon & Cornwall LUG
> http://mailman.dclug.org.uk/listinfo/list
> FAQ: http://www.dcglug.org.uk/listfaq
--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq