Moving to IPv6

D. Hugh Redelmeier hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org
Sat Sep 18 05:42:05 UTC 2010


| From: Anton Verevkin <anton-P5WJPa9AKEc1GQ1Ptb7lUw at public.gmane.org>

| "D. Hugh Redelmeier" <hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org> wrote:

| > | In the IPv4 case they would give you one IP address each that you set on
| 
| > | different NICs of your router and make some logic to NAT outgoing 
| > | connections to one IP or another. Reply packets get back through the 
| > | same connection where they originated.
| > 
| > How do you do load balancing?  I don't thing your last sentence is
| > correct (unfortunately).
| 
| By saying that packets return through the originating connection I meant 
| that if you have Bell IP 1.1.1.1 and Rogers IP 2.2.2.2 and you let the
| packet
| exit through the Bell link, your router makes NAT to the 1.1.1.1 address,
| and
| the reply packet will definitely get back through Bell as it will be going
| to 
| IP 1.1.1.1.

Sorry, I was thinking the reverse direction: the server being on the
subnet and the clients on the outside.

On a machine with two networks, with two IP addresses, return packets
tend to use the single default route, so only one port gets used for
outbound packets.

It is possible to do better, but I don't know a simple good way.

Reply packets ought to be crafted with source IP address taken from
the inbound packet's IP address.  If I remember correctly, this isn't
the default in the Linux stack and hence each program needs explicit
code to effecct this.  I wrote such code for Pluto in FreeS/WAN.  I
don't know how many other servers do this.

If the outbound packets have appropriate source IP addresses, it
should not be too hard to get the routing to work.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list