On Wed, Jun 14, 2000 at 02:36:21PM -0600, Ryan Hulsker wrote:
>
> >> Just 3 questions...
> >>
> >> Basically all of these systems are running RH6.2 with the latest fixes
> >> from RH (as of 2 weeks ago, LVS 0.9.7 ) and I am wondering if any of
> >> the functionality I need is provided in the latest versions of LVS
> >> with the newer kernel.. Is it worth it to me to upgrade my LVS boxes,
> >> and re certify the system when I have to go live at the end of the
> >> month? Or do I need to go with a NAT configuration?
> >>
> >> 1. Is it possible to use DR without having to have each webserver use
> >> a uniqe real IP address. Basically I have a DMZ with a limeted number
> >> of IP addresses and I will need most of them for VIPs.
> >
> > Technically yes, though the Real servers will not be able to intiate
> > connections to the outside world if they are sitting on RFC 1918
> > addresses. But they should be able to reply to LVSed traffic as the
> > source address apply will be set to the VIP.
>
> OK, I tried this but when I have eth0 = 192.168.x.x and lo:1 =
> 216.94.x.110 on the RSs the system wont let me set a default route of
> 216.94.x.97 which would be the default route for the VIP. I get a
> "network not accessable" error. I got around this with "route add -net
> 216.94.x.96 netmask 255.255.255.224 eth0" I can then add the proper
> default route but it still does not work, I am wondering if using
> tunneling would solve my problems. I think I am going to try that next.
This should work, alternatively as tc lewis mentioned you can set up the
gateway router to have an address on the 192.168 network and use that as
the default gw. Is 216.94.x.97 an IP address on the LVS host? If so you
need to edit some proc values so the return traffic is not rejected. People
who are not me have been successful in getting a LVS host running DR to act
as a gateway router for the real servers.
In any case I would suggest some investigation using tcpdump to see where
the return packets are going and where they get dropped.
> >> 2. I have noticed with my setup that LVS does not handle classless IPs
> >> well. when lvs starts up the VIP the mask is always /24 or /16. My
> >> range of real IPs is only a /27. Is this my error, a known issue, or
> >> somthing that has been fixed?
>
> > I am a little confused, netmask? 0.9.7 only supports a single VIP per
> > virtual server, that is netmask 255.255.255.255. Certainly if you move
> > to 0.9.10 or greater then you can use the fmwark support which will
> > allow you to assign CIDR networks for a virtaul service.
> >
> > Can you be a little more clear on where this classful netmask is
> > occuring, certainly 0.9.7 should be able to run a single VIP on a /27.
> > I have a /28 at home and have used it for testing :)
>
> Well, when LVS starts up on the load balancer it creates a VIP alias on
> eth0:1 and ifconfig reports this...
I am begining to understand the problem. You should be aware that LVS
itself does _not_ set up interfaces. Whatever you are using to invoke LVS
must have some logic in it that is bringing up these interfaces for you and
it is this that either doesn't support or needs to be specificly configured
to use classless nets.
> eth0 Link encap:Ethernet HWaddr 00:06:29:DE:78:A1
> inet addr:216.94.x.115 Bcast:216.94.x.127 Mask:255.255.255.224
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:5206396 errors:0 dropped:0 overruns:0 frame:0
> TX packets:5250899 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> Interrupt:10 Base address:0x9000
>
> eth0:1 Link encap:Ethernet HWaddr 00:06:29:DE:78:A1
> inet addr:216.94.x.110 Bcast:216.94.x.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> Interrupt:10 Base address:0x9000
>
> And in my other test setup the alias gets a netmask of 255.255.0.0.
>
> Im not sure what is causing this. I guess this should not really break
> anything as the load balancer should not communicate outbound directly using
> the VIP, but I think that these should either be /27 or /32. Although I
> could be totaly missing somthing here...
--
Horms
|