|
On Tuesday 30 April 2002 17:13, you wrote:
> fine. How are you handling the calls to CIP:6000 from the realservers?
I don't need to handling it, because the realserver connects the client-IP
direct. In the XMDCP request is also the client IP - I think ;-)
> I don't know. It can't be timeouts, as it's happening when you initiate
> a new session.
I have log the UDP-packets with tcpdump and it look like this:
This is a normal request:
15:24:36.039733 freebsd.comre.itris.ch.32898 > 192.168.120.140.xdmcp
15:24:36.073968 node1.xdmcp > freebsd.comre.itris.ch.32898
15:24:37.395949 freebsd.comre.itris.ch.32898 > node1.xdmcp
15:24:37.398992 node1.xdmcp > freebsd.comre.itris.ch.32898
15:24:37.399308 freebsd.comre.itris.ch.32898 > node1.xdmcp
Finish!
Bad request:
15:38:55.964810 solloz-u.comre.itris.ch.32821 > 192.168.120.140.xdmcp
15:38:55.964841 solloz-u.comre.itris.ch.32821 > 192.168.120.140.xdmcp
15:38:56.130882 node2.xdmcp > solloz-u.comre.itris.ch.32821
15:38:56.131022 192.168.120.140.xdmcp > solloz-u.comre.itris.ch.32821
15:38:57.647529 solloz-u.comre.itris.ch.32821 > node2.xdmcp
15:38:57.647640 solloz-u.comre.itris.ch.32821 > node2.xdmcp
15:38:57.650216 node2.xdmcp > solloz-u.comre.itris.ch.32821
15:38:57.650249 192.168.120.140.xdmcp > solloz-u.comre.itris.ch.32821
15:38:57.652217 solloz-u.comre.itris.ch.32821 > node2.xdmcp
15:38:57.652225 solloz-u.comre.itris.ch.32821 > node2.xdmcp
15:38:57.652533 node2.xdmcp > solloz-u.comre.itris.ch.32821
15:38:57.652544 192.168.120.140.xdmcp > solloz-u.comre.itris.ch.32821
15:38:59.663349 solloz-u.comre.itris.ch.32821 > node2.xdmcp
15:38:59.663395 solloz-u.comre.itris.ch.32821 > node2.xdmcp
15:38:59.663395 solloz-u.comre.itris.ch.32821 > node2.xdmcp
Not Finish! After the this last UDP-package, the "solloz-u.comre.itris.ch"
host bombards the node1 with UDP packages. I can shut down the X11-server on
the workstation, but the flood dosn't stop. I think there must be a loop
between the two nodes.
(The 192.168.120.140 IP is the VIP)
The real-server is also the failover-server (director 2) and there is also a
active ipvsadm-table on it. Can the second table generate this error!? I'm
deaktivating the table now and hey it works, but the system has ran before
too with this settings - I think. I must test this next morning, it's to late
now.
> it might be better to use the -dh scheduler than to use persistence. You
> will need to set the TCPIP timeouts to a long time, in case the people walk
> away from the keyboard.
OK I will test it.
--
Gruss: Severin Olloz
|
