|
Hello,
On Wed, 7 Dec 2005, John Line wrote:
> With debug level 12, for WPAD request:
> IPVS: lookup/in TCP <clientaddr>:2486->131.111.8.68:80 hit
> IPVS: Incoming packet: TCP <clientaddr>:2486->131.111.8.68:80
> Enter: ip_vs_dr_xmit, net/ipv4/ipvs/ip_vs_xmit.c line 451
> ip_rt_bug: <clientaddr> -> 131.111.8.68, eth1
> Leave: ip_vs_dr_xmit, net/ipv4/ipvs/ip_vs_xmit.c line 487
May be some rerouting happens in LOCAL_OUT where saddr=client IP,
do you have any iptables rules in OUTPUT that mangle/modify something in
packet to real server?
> Other observations:
>
> (a) The "short" WPAD log entries are often *not* preceded by "long"
> entries for the same client, which seems odd and maybe wrong (since it
> suggests they are being passed back to the main IP routing code
> when they've never been assigned to a real-server).
IPVS: new dst 131.111.8.96, refcnt=3, rtos=0
means IPVS just cached new dst entry for the real server, old was
obsolete/expired. When such line is shown then we just got fresh
dst entry with output routing call, if such line is missing then
we use the cached value - we save one routing call per packet.
> (b) After stopping heartbeat/ldirectord (and manually unloading the ip_vs*
> modules to avoid continued logging of details about packets that IPVS was
> seeing but leaving for normal routing), I was puzzled by the quantity of
>
> IPVS: Unbind-dest TCP c:<clientaddr>:4942 v:131.111.8.68:80 d:131.111.8.96:80
> fwd:R s:3 flg:183 cnt:1 destcnt:11
>
> messages being logged. My first thought was that some might be remnants from
> earlier tests (since I didn't know whether the state data structures would
> survive between tests), but trying another brief test after rebooting the
> system showed the same apparent mismatch:
>
> 6 ip_rt_bug messages for WPAD
> 1 Bind-dest message for WPAD
> 15 Unbind-dest messages for WPAD
unbind-dest happens when connection timer expires, sometimes
2mins after conn is finished.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
