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
