Hi Drew. 2009/3/12 Drew Weaver <[email protected]>: > > We are trying to find ways of moving our load balancing services off of our > distribution/edge and into the core of the network. > > The problem with this obviously is that we do not want to put the load > balancers in-line between the border and the core. >
Presumably, this type of configuration is not going to be workable with your traffic levels, although it would probably be the simplest solution. > > We would like to hang the load balancers off of the core. > > My question is that if the load balancers are not in-line is there any way > to retain the same functionality? > > I.e. so that the source-IP addresses don't get swapped for the IP of the > load balancer, etc. > As you suggest, the most common way to do this is in the wild is source-NAT, changing the source-IP of the connection to the LB interface IP. Some people do this and add the x-forwarded-for header to HTTP connections, keeping the source IP in logs with some custom apache logging. Obviously, this is less than ideal, especially if you are selling this as a service to end-users. Another possibility is to route everything through the LB, using it as the default gateway for the servers. This is basically a layer 3 inline solution, so presumably the same problems will apply as standard inline mode (all server traffic needs to pass through the LB). DSR may give you what you need, depending on your topology. You need to configure the LB VIP as a loopback on the real servers. Packets flow in through the LB, but the responses go straight back from the real server to the client over the normal routing path, without needing any translation etc. There are config examples for DSR on Linux, Windows and Solaris in the SLB guide. Be aware that DSR involves asymmetric routing by design, so this may cause problems if you use firewalls or other stateful devices internally. There are some other, more creative ways to force return-routing through the load balancer without using source-NAT, but this is usually done on the server side. For example; Linux has policy-based routing (iproute2) that will enable you to return-route any connection received on a particular server interface through a separate routing table. In simple terms, you can configure eth0 to use the standard routing table, and then a new interface eth0:1 to use a different routing table - one that default routes through the LB. You then configure the LB to direct packets to the real server IP of eth0:1 and the return packets will come back through the LB. Meanwhile all regular traffic is going through the normal routing path, bypassing the LB. Hope this is of some help. Regards, Lee _______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
