Joseph Mack NA3T wrote: > On Wed, 24 Oct 2007, John Donath wrote: > > >> Hi, >> >> I have setup a 2 node HA cluster based on the Streamline High >> availability and Load Balancing concept. >> >> The weird thing is that it works fantastic for tcp/80 but it doesn't >> work properly for a udp service like radius (up/1812). >> > > There are conceptual problems loadbalancing UDP, as there is > no connection (see UDP in the HOWTO, there are solutions but > all have problems). As well do you understand the many > reader/single writer problem when loadbalancing databases? > > Yes, I do. This is not a problem as only read actions are involved. >> Assume we have both the http and radius service down on the failover >> director (grind12): >> >> [EMAIL PROTECTED] ~]# ipvsadm >> IP Virtual Server version 1.2.0 (size=4096) >> Prot LocalAddress:Port Scheduler Flags >> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >> UDP 172.31.1.10:radius rr >> -> 172.31.1.11:radius Local 1 0 0 >> TCP 172.31.1.10:http rr persistent 600 >> -> 172.31.1.11:http Local 1 0 0 >> > > (not related to your problem) persistence has problems. You > could look at the -SH scheduler instead. > I will sure do. > >> I now can access the webserver but I don't get any response from the >> radius service. >> > > how can you access a service when the service is down? > > The service is down on the failover node but up on the primary. > Is Radius listening on the VIP? (it should be, see writeup > for LocalNode) > > Radius is listening on 0.0.0.0. > >> Here are results from tcpdump on both nodes when a radius request is >> initiated: >> [EMAIL PROTECTED] ~]# tcpdump -ni any -p udp and host 83.162.10.97 >> 14:41:10.069858 IP 83.162.10.97.32843 > 172.31.1.10.radius: RADIUS, >> Access Request (1), id: 0xdb length: 65 >> 14:41:10.069891 IP 172.31.1.11.radius > 83.162.10.97.32843: RADIUS, >> Access Accept (2), id: 0xdb length: 26 >> >> As you will note the wrong source address is used !! >> It's responding with the realnode IP instead of the VIP and that's >> causing the problem. >> > > No idea. I assume that Radius is listening on x.x.x.11 > (instead of x.x.x.10), in which case I can't imagine how > Radius is getting packets at all. > > >> I am puzzled why this problem does not exist when testing http (tcp/80) >> as yo can see from this: >> 14:43:53.399206 IP 83.162.10.97.41143 > 172.31.1.10.http: F 553:553(0) >> ack 268 win 1728 <nop,nop,timestamp 496389562 507325571> >> 14:43:53.399224 IP 172.31.1.10.http > 83.162.10.97.41143: . ack 554 win >> 1724 <nop,nop,timestamp 507325582 496389562> >> >> Might this be UDP related? >> > > possibly (since I have no idea what's wrong yet). > > >> [EMAIL PROTECTED] ~]# tcpdump -ni any -p udp and host 83.162.10.97 >> ** nothing of course ** >> > > I'm sorry, this went over my head. Why "of course"? > "Of course" because I don't expect any packets on the failover node as the service is only up on the primary node. So nothing will be forwarded ... > > >> If I reverse the situation - bringing down both services on the primary >> director node (grind11) and starting them up on the failover director >> (grind12) then both services are accessible. >> > > hmm. let's leave this till later. > > Just a remark - when the radius service is down on the primary but up on the failover node the radius service nicely responds to requests. > Joe > >
Thanks for your quick response. John _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
