LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: dns + lvs dr.

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: dns + lvs dr.
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: tc lewis <tcl@xxxxxxxxx>
Date: Sun, 12 Nov 2000 15:36:59 -0500 (EST)
hi there.  see below.


On Sun, 12 Nov 2000, Julian Anastasov wrote:

> 
>       Hello,
> 
> On Sun, 12 Nov 2000, tc lewis wrote:
> 
> >
> > what issues exist with doing dns through lvs?  i'm pulling my hair out
> > over this one.
> >
> > here's a tcpdump on my real server:
> >
> > 08:37:41.004616 eth0 > 192.168.1.21.1024 > 192.203.230.10.domain: 9513 NS?
> > . (17)
> > 08:37:42.503820 eth0 B arp who-has 192.168.1.12 tell 192.168.1.2
> > 08:37:42.503842 eth0 > arp reply 192.168.1.12 (0:d0:b7:65:ec:48) is-at
> > 0:d0:b7:65:ec:48 (0:c0:95:e2:a8:b1)
> > 08:37:42.503943 eth0 < 208.219.36.76.64049 > 64.211.224.163.domain: 2106+
> > PTR? 163.224.211.64.in-addr.arpa. (45)
> > 08:37:42.504012 eth0 > 64.211.224.163 > 208.219.36.76: icmp:
> > 64.211.224.163 udp port domain unreachable [tos 0xc0]
> 
>       ICMP error => no listener?
> 
>       Before I fully understand your message (the ARP talks for
> example) one question:
> 
>       Is the DNS server in the real server(s) started before the VIPs
> are configured (in the real servers). Look at the logs (/var/log/messages?)
> whether the DNS server is listening on VIP:53. There can be a problem if
> you start your network scripts (VIPs, routes, etc) in rc.local while the
> DNS server was started long before from the rc.d levels. If you
> use "bind" I assume there is no listener(s) for the VIPs you add after
> starting the server.
> 
>       For the telnet service there is no problem. It just listens for
> 0.0.0.0 and when you add new VIP later it just works.

yeah, that stuff is all ok (it actually might not have been on that
tcpdump--not sure).  so i think it all comes back to the priority
routing thing.  cause i can't nslookup from the real server (which is the
name server) for outside domains.  but even with priority routing off
strange things happen.  ok ignore that.  check the following out.  it
looks like some odd udp problem, but tcp is ok.

director:
UDP  64.211.224.164:53 lc
  -> 192.168.1.11:53             Route   1      0          2         
TCP  64.211.224.164:53 lc
  -> 192.168.1.11:53             Route   1      0          1         

tcp to port 53:
12:18:51.332533 eth1 < 208.219.36.76.61236 > 64.211.224.164.domain: S
857678275:857678275(0) win 32120 <mss 1460,sackOK,timestamp 131143386
0,nop,wscale 0> (DF)
12:18:51.332582 eth1 > 208.219.36.76.61236 > 64.211.224.164.domain: S
857678275:857678275(0) win 32120 <mss 1460,sackOK,timestamp 131143386
0,nop,wscale 0> (DF)
12:18:51.343790 eth1 < 208.219.36.76.61236 > 64.211.224.164.domain: .
857678276:857678276(0) ack 721543635 win 32120 <nop,nop,timestamp
131143387 251713> (DF)
12:18:51.343838 eth1 > 208.219.36.76.61236 > 64.211.224.164.domain: .
0:0(0) ack 1 win 32120 <nop,nop,timestamp 131143387 251713> (DF)
12:18:53.606644 eth1 < 208.219.36.76.61236 > 64.211.224.164.domain: F
0:0(0) ack 1 win 32120 <nop,nop,timestamp 131143613 251713> (DF)
12:18:53.606688 eth1 > 208.219.36.76.61236 > 64.211.224.164.domain: F
0:0(0) ack 1 win 32120 <nop,nop,timestamp 131143613 251713> (DF)
12:18:53.617657 eth1 < 208.219.36.76.61236 > 64.211.224.164.domain: .
1:1(0) ack 2 win 32119 <nop,nop,timestamp 131143614 251940> (DF)
12:18:53.617694 eth1 > 208.219.36.76.61236 > 64.211.224.164.domain: .
1:1(0) ack 2 win 32119 <nop,nop,timestamp 131143614 251940> (DF)
12:18:56.330262 eth1 > arp who-has 192.168.1.11 tell 192.168.1.2
(0:c0:95:e2:a8:b1)
12:18:56.330399 eth1 < arp reply 192.168.1.11 is-at 0:d0:b7:65:ec:48
(0:c0:95:e2:a8:b1)
(successful)

udp to port 53 (nslookup):
12:19:09.385187 eth1 < 208.219.36.76.61214 > 64.211.224.164.domain: 50126+
PTR? 164.224.211.64.in-addr.arpa. (45)
12:19:09.385222 eth1 > 208.219.36.76.61214 > 64.211.224.164.domain: 50126+
PTR? 164.224.211.64.in-addr.arpa. (45)
(unsuccessful)



real server:
[root@phl /root]# /sbin/ipchains -L -n
Chain input (policy ACCEPT):
target     prot opt     source                destination           ports
REDIRECT   tcp  ------  0.0.0.0/0            64.211.224.164        * ->
53 => 53
REDIRECT   udp  ------  0.0.0.0/0            64.211.224.164        * ->
53 => 53
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):

(i wasn't using the horms/ipchains method before, but i am now).

tcp to port 53:
12:18:48.170150 eth0 < 208.219.36.76.61236 > 64.211.224.164.domain: S
857678275:857678275(0) win 32120 <mss 1460,sackOK,timestamp 131143386
0,nop,wscale 0> (DF)
12:18:48.170349 eth0 > 64.211.224.164.domain > 208.219.36.76.61236: S
721543634:721543634(0) ack 857678276 win 32120 <mss 1460,sackOK,timestamp
251713 131143386,nop,wscale 0> (DF)
12:18:48.181404 eth0 < 208.219.36.76.61236 > 64.211.224.164.domain: .
1:1(0) ack 1 win 32120 <nop,nop,timestamp 131143387 251713> (DF)
12:18:50.444385 eth0 < 208.219.36.76.61236 > 64.211.224.164.domain: F
1:1(0) ack 1 win 32120 <nop,nop,timestamp 131143613 251713> (DF)
12:18:50.444411 eth0 > 64.211.224.164.domain > 208.219.36.76.61236: .
1:1(0) ack 2 win 32120 <nop,nop,timestamp 251940 131143613> (DF)
12:18:50.444499 eth0 > 64.211.224.164.domain > 208.219.36.76.61236: F
1:1(0) ack 2 win 32120 <nop,nop,timestamp 251940 131143613> (DF)
12:18:50.455392 eth0 < 208.219.36.76.61236 > 64.211.224.164.domain: .
2:2(0) ack 2 win 32119 <nop,nop,timestamp 131143614 251940> (DF)
12:18:53.168113 eth0 < arp who-has 192.168.1.11 tell 192.168.1.2
12:18:53.168143 eth0 > arp reply 192.168.1.11 (0:d0:b7:65:ec:48) is-at
0:d0:b7:65:ec:48 (0:c0:95:e2:a8:b1)
(successful)

udp to port 53 (nslookup):
12:19:06.223900 eth0 < 208.219.36.76.61214 > 64.211.224.164.domain: 50126+
PTR? 164.224.211.64.in-addr.arpa. (45)
12:19:06.224186 eth0 > 192.168.1.21.domain > 208.219.36.76.61214: 50126
NXDomain 0/1/0 (116)
(unsuccessful)


i ctrl-c'd the nslookups cause they were obviously stalling, hence the
short udp tcpdump outputs.  i don't know if i can actually do a
nameservice request over tcp, as i don't really know what one looks like
to type it in, and nslookup doesn't seem to support tcp, but the port
connection itself was successful.  the udp one looks odd to me--as if the
real server is putting its rip as the source ip of the return packets,
instead of using the vip, but it does use the vip with that tcp
connection.

i built these kernels myself, so it's possible i missed something, but i
don't know what that something would be.

director is 2.2.17 with ipvs 1.0.0beta and ext3 0.0.3b (i think).
real server is 2.2.17 with ext3 0.0.3b (ditto).

comments?  i'm confused.

-tcl.



<Prev in Thread] Current Thread [Next in Thread>