LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

RE: TFTP Virtual Service using LVS

To: <jmack@xxxxxxxx>
Subject: RE: TFTP Virtual Service using LVS
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: "K Natarajan-A16638" <natarajan@xxxxxxxxxxxx>
Date: Fri, 26 Jan 2007 20:04:02 +0800
Joe,
 
Did you get a chance to look at my response?
 
Thanks,
Natarajan
 
 

________________________________

From: K Natarajan-A16638 
Sent: Saturday, January 13, 2007 7:35 PM
To: 'LinuxVirtualServer.org users mailing list.'
Subject: RE: TFTP Virtual Service using LVS




Joe,

Thanks for your quick response.

Please find my responses below.


-----Original Message-----
From: lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx
<mailto:lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx> ] On Behalf Of Joseph
Mack NA3T
Sent: Friday, January 12, 2007 12:22 AM
To: LinuxVirtualServer.org users mailing list.
Subject: Re: TFTP Virtual Service using LVS

On Thu, 11 Jan 2007, K Natarajan-A16638 wrote:

> LVS users,
>
> I am trying to create a TFTP virtual service using the binaries
> provided at www.ultramonkey.org. I want to support High Capacity, High
> Availability and Load Balancing on my TFTP virtual service where the
> Real servers directly respond to the client requests without having to
> go through Linux Director again.

With LVS, packets from the client go to the director before being
forwarded to the realservers.

<Natarajan> As per the link below

http://www.ultramonkey.org/3/topologies/hc-ha-lb-eg.html
<http://www.ultramonkey.org/3/topologies/hc-ha-lb-eg.html> 

I can configure a virtual service such that the real servers directly
respond to the clients with having to go through the linux director. It
can used for high capacity services. It ensures that the Linux director
does not become a bottleneck. The requests from the client comes through
the Linux director but the responses from real servers directly go to
the clients.

> I tried to create the service using the configuration provided at the
> link below.
>
> http://www.ultramonkey.org/3/topologies/hc-ha-lb-eg.html
<http://www.ultramonkey.org/3/topologies/hc-ha-lb-eg.html> 
>
> I was able to get the load balancing and high availability working

how do you know this?

<Natarajan> Sorry for the confusion.  I was trying out the different
configurations provided in the link below.

 http://www.ultramonkey.org/3/topologies
<http://www.ultramonkey.org/3/topologies>  

I was able to get the High Availability, Load Balancing configurations
provided in the link 

> but I
> could not get the TFTP service to work.

this statement is incompatible with the first half of your sentence.

<Natarajan> I was unable to get the High Capacity, High Availability and
Load Balancing configuration provided in
http://www.ultramonkey.org/3/topologies
<http://www.ultramonkey.org/3/topologies>  to work.

> Using ethereal I observed the
> following.
>
> The real server was responding to the client TFTP get request and
> sending a the first block of the file in a UDP packet with the virtual
> IP as the source IP address and arbitrary source port (say 33212). The
> TFTP client responds with an UDP acknowledgement message with the
> virtual IP address as the target IP address and the target port equal
> to 33212. This request goes to the Linux director which ignores the
> packet as it does not have any service running on 33212.

the request goes to the director, which being a router, forwards it to
the realservers.

<Natarajan> Let me try to explain it better.

Here is the setup that I have.

192.168.167.95 - Virtual Service IP address

192.168.167.96 - Active Linux Director (Linux Directors operating on HA
mode)
192.168.167.97 - Standby Linux Director



192.168.167.98 - TFTP Server-1
192.168.167.99 - TFTP Server-2

192.168.173.52 - TFTP Client IP Address

As you might be aware the TFTP server listens to requests on port 69 but
the actual data transfer will happen on some arbitary port.

Step - 1: The Client initiates a TFTP get request on the Virtual Service


(192.168.173.52,23111)      -------------------------->
(192.168.167.95, 69)
                                           TFTP GET REQUEST


The TFTP get request goes to the linux director  (192.168.167.96) on
port 69 which forwards it to the real server's port 69.

Step -2:  The real server responds by sending the first block (512
bytes) of the file in a UDP packet directly to the client with source ip
equal to the virtual ip address. The Real server chooses an arbitrary
port (33212) to do the data transfer

 
(192.168.167.95, 33212)   ----------------------------> (192.168.173.52,
23111)
                                            BLOCK 1 
 
Step -3: As per the TFTP protocol, The client sends a UDP
acknowledgement back to the server to indicate that it received the
first block.
 
(192.178.173.52, 23111) ------------------------------------>
(192.168.167.95, 33212)
                                    ACKNOWLEDGEMENT
 
This request now goes to the active linux director on port 33212. The
Linux director does not know how to handle this request because
ldirectord.cf has the virtual service configured only on port 69. It
ignores the packet. 
 
Please find the service configuration in my ldirectord.cf below.
 
# Virtual Server for TFTP
virtual=192.168.167.95:69
        real=192.168.167.98:69 gate
        real=192.168.167.99:69 gate
        service=none
        scheduler=rr
        #persistent=600
        protocol=udp
 checktype=ping

The client retries the acknowledgement multiple times and then times
out.


> Does LVS work for UDP based services?.

yes, but not many people are using it for UDP.

> How does the Linux Director
> distinguish between clients for UDP based services?.

by the client IP.

Joe
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina jmack (at) wm7d (dot)
net - azimuthal equidistant map generator at
http://www.wm7d.net/azproj.shtml <http://www.wm7d.net/azproj.shtml>
Homepage http://www.austintek.com/ <http://www.austintek.com/>  It's
GNU/Linux!
<http://www.in-addr.de/mailman/listinfo/lvs-users> 


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