
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">

<div><br>

</div>

<div>

<div>On Oct 4, 2011, at 1:29 AM, Poul-Henning Kamp wrote:</div>

<br>

<blockquote type="cite">

<div>The main we have not added a facility to bind backend connections<br>

to a particular IP# is that it is a recipe for reachability problems<br>

and kind of hard to imagine a legit case for wanting to do it in<br>

the first place, so can I get you to describe (possibly in private<br>

email) why you need to do this ?<br>

<br>

</div>

</blockquote>

</div>

<br>

<div>Hello Poul,</div>

<div>Thank you for confirming this, I suspected as much, just wasn't absolutely sure. I'll be happy to explain my use case. I'm trying to create a redundant, highly-available architecture using varnish as the front-end caching server and load-balancer. I have

 two machines, webproxy01 and webproxy02 that shares a VIP (the aliased interface, eth0:0) via heartbeat, so only one machine will have the appropriate IP at any given time. That being said, I was hoping that all upstream servers will see the IP address of

 the VIP and not the IP address for the actual machine, that way each machine is interchangeable and abstracted from the stack. If I need to swap out one of the  front-ends with another front-end with a different IP address, I don't want to update all the "trusted

 gateway" scripts on the backend servers. As long as it is coming from the VIP, it is a trusted gateway. Let me know if this doesn't make sense or if I'm over-architecting the system...which I've been known to do :-)</div>

<div><br>

</div>

<div>Henry Umansky<br>

Web Development Services<br>

Princeton University<br>

<a href="mailto:humansky@princeton.edu">humansky@princeton.edu</a><br>

609-258-1674</div>

</body>

</html>