On 20/03/11 06:38, Jim Binder wrote:
Think I finally figured it out... It was internal routing as I had expected.
Remember, eth0 (inside), eth1(admin), eth2(inet)...
The issue was that i had two interfaces on the same network 192.168.1.x... (br0
and eth1) One being the bridge (br0) and the other being the Admin interface I
was using (addr. via DHCP). Because the it was the first entry in the route
table to the network, linux wasn't sending packets from squid into the bridge.
Great catch!
This works:
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.88
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.91
default via 192.168.1.254 dev eth1
default via 192.168.1.254 dev br0
This doesn't:
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.91
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.88
default via 192.168.1.254 dev br0
default via 192.168.1.254 dev eth1
My simple solution was to release the ip addr of eth1 (dhcp -r eth1) and then
assign dhcp to br0 and then re-dhcp eth1.
Have to think about if I can craft a policy to do the right thing regardless of
order without having to release eth1. Till then it works fine.
Setting a high metric for the eth1 should do it. Though I'm not sure how
one achieves that on DHCP assignment.
You might want to update the twiki
Updated. Thank you for the details. Does this look right?
http://wiki.squid-cache.org/Features/Tproxy4#Timeouts_with_Squid_running_as_a_bridge_or_multiple-NIC
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.11
Beta testers wanted for 3.2.0.5
