Varnish and multiple interfaces

[Bradley Falzon]

On Tue, Oct 4, 2011 at 10:40 PM, Henry M. Umansky <humansky at princeton.edu>wrote:

> Let me know if this doesn't make sense or if I'm over-architecting the
> system...which I've been known to do :-)
>

You *could* add another route, tell the kernel to use the eth0:0 IP address
for specific routes:

[root at ellahgrace ~]# ip route
192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.100

tcpdump of ping request (notice the source IP is 192.168.2.100)
08:36:15.945374 IP 192.168.2.100 > 192.168.2.254: ICMP echo request, id
45145, seq 1, length 64
08:36:15.946212 IP 192.168.2.254 > 192.168.2.100: ICMP echo reply, id 45145,
seq 1, length 64

[root at ellahgrace ~]# ip route add 192.168.2.254/32 dev eth1 proto static
scope link src 192.168.2.101
[root at ellahgrace ~]# ip route
192.168.2.254 dev eth1  proto static  scope link  src 192.168.2.101
192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.100

Now all packets to 192.168.2.254 should come with the src 192.168.2.101, as
you can see here:

08:44:57.841931 IP 192.168.2.101 > 192.168.2.254: ICMP echo request, id
14171, seq 3, length 64
08:44:57.842533 IP 192.168.2.254 > 192.168.2.101: ICMP echo reply, id 14171,
seq 3, length 64

When the interface belonging to 192.168.2.101 (in my case eth1:1 - yours is
probably eth0:0) goes down, so does the route and future packets will just
come from any available interface. The static route just needs to be added
when your aliased interface gets added, the kernel will take it away when it
is not longer available.

IMHO, I think this will just cause more problems than what it's worth. It's
common, in my experience, to see VIP / Load Balanced setups come from
different interfaces.

IMHO, as for your trusted proxy configurations, just match a subnet, like
192.168.1.0/27 or similar.

-- 
Bradley Falzon
brad at teambrad.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20111005/3ec48044/attachment-0003.html>