On Tue, 12 Jun 2001, Joseph Mack wrote:
> I don't yet understand the model being used for the L4 test.
> Below is my nolb-14-4.pg. The only thing I've changed is the IPs
> to suite my setup.
>
> I'm running Linux-2.2.19 and 2.4.5.
>
> Client problems: the client is looking for an
> address on lo0 to bind to. I can't configure an lo0 on linux, but
> can configure lo:1..lo:255.
The default "lo0" is probably BSD specific. Use the loopback interface
name appropriate for your OS. I think it is "lo" on Linux:
addr_mask = 'lo::10.1.0.0';
Polygraph used to work with Linux aliases just fine, but I am not sure
it is still the case. The best way to test is to see whether you can
use Polygraph's aka to create and delete aliases. If you cannot,
please report a bug off the list, and we will fix it.
> So substituting client_side.addr_mask=lo:0::10.1.0.0
client_side.addr_mask = 'lo::10.1.0.0';
> and with ifconfig, adding device lo:0=10.1.0.0/16 allows the
> client to start.
You should not have to add any devices or interfaces. In our tests,
Polygraph simply adds required aliases and proceeds with the tests. As
I said, there may be problems with Linux though. At your option, you
can add the aliases yourself. Remove interface name from the address
mask above if you do (so that Polygraph will not attempt to create
aliases). The bottom line is that the client box(es) must have IP
aliases that match ClientR.addresses for robots to start correctly.
> The client starts 1001 agents with ports 3000:30000, starting
> 10.1.0.1 .. 10.1.3.228 (nothing seen in netstat -an, but not sure
> that I expect anything there)
You should get 1000 agents per PC if everything works correctly. Yes,
you should not see anything with netstat at the very beginning of
polyclt execution since robots do not open connections until they
start sending requests.
> and then dies with DnsMgr.cc:67 (s24) Too many open files.
You need to configure Linux to let you use, say, 12K filedescriptors.
You will need fewer than 6K for most of the tests.
Polygraph 2.6.1 starts DNS managers (one per robot) even if you do not
need them (and you do not because LB workloads do not use domain
names). This will be optimized in the next release. For now, each DNS
manager costs you one extra socket (filedescriptor).
> I assume this is something I have to fix, but I don't know how.
> (Any suggestions).
See Oskar's e-mail and online Linux resources?
> Assuming I handle this, I understand that the client is routing
> packets out of the client_side.hosts IP and that replies should
> return to this IP.
Yes. The packets should originate on the loopback aliases, routed to
the world through client_side.hosts IPs.
> This brings me to the server. With my .pg file, the servers want to
> bind to 192.168.128.1.
In LB workloads, servers should be configured to use "real"
interfaces, not loopback aliases. We will have an addressing scheme
that will do it for you automatically. For now, simply use
server_side.hosts for server addresses (I think the no-lb workload
does not do that correctly).
> I don't see where this address comes from in the .pg file.
> Can you enlighten me?
As virtually everything else, these addresses come from your
configuration file:
server_side.addr_mask = '192.168.1.0:8080';
vipMap.addresses = serverAddrs(asWebAxe4, TheBench);
vipMap.names = addresses;
ClientR.origins = vipMap.names;
Since asWebAxe4 is returning aliases based on addr_mask, you
probably want to replace the second line with
vipMap.addresses = server_side.hosts;
> If I put this IP on lo:1 on each server, the server starts up
> listening on 192.168.128.1:8080 (visible in netstat -an)
> and shuts down a while later
>
> shutdown reason: inactivity timeout
>
> I assume the server is not getting packets from the client(s)
Correct. You need to make robots to send traffic to the servers. If I
understand correctly, you need to increase the number of
filedescriptors available to Polygraph because your polyclt processes
quit before sending any packets.
> In the switch off, do you add these extra IP's
> (client 10.1.0.0/16, server 192.168.128.1/32) to the test machines?
Polygraph adds client-side aliases. We will use "real" IPs on the
server side. Note that we are going to use FreeBSD boxes for Polygraph
agents. You do not have to use FreeBSD, but we cannot guarantee that
there is no differences between OSes as far as switch performance
measured by Polygraph is concerned.
> Not having produced any packets yet to watch with tcpdump, I don't know
> the dst_addr of the packets produced by the client.
>
> Can you tell me
>
> at the client: src_addr, dst_addr of packets generated
> (presumably reply packets have the addresses reversed)
src_addr: whatever you set ClientR.addresses to.
dst_addr: whatever ClientR.origins resolves to (should be
vipMap.addresses in your case)
> at the server: expected src_addr, expected dst_addr of incoming packets
> src_addr, dst_addr of reply packets.
The servers do not care about request src_addr. Requests should be
directed at OriginS.addresses, just like in real life. For responses:
src_addr: whatever you set OriginS.addresses to
dst_addr: src_addr of the request, I guess.
> presumably when I know these addresses, I'll know whether to route the
> reply packets through my L4 box or directly to the client(s).
>
> It's not clear to me what the VIP (in my example 192.168.1.110) is doing
> here. Can you tell me more about this? e.g. I don't understand
> // use proxy side for VIP so that all real IPs are in one place (TheBench)
The VIP does not do anything for the no-lb workload because that
workload is designed to work with a L2 switch. TheBench still has it
as a leftover from SrvLB workload file. We should probably remove it
to avoid confusion.
Please note that the above comments are for non-DSR configurations:
all servers are bound to unique IP addresses. As far as I understand,
one cannot use a no-balancing workload with a DSR setup. They are
incompatible by design (no-balancing workload essentially uses DSR,
but without a L4+ switch because robots talk directly to servers).
We will polish the workload file by the next release. Meanwhile,
please use the comments above. A useful rule of thumb is that
Polygraph knows and does only what you tell it via PGL. There is
virtually no magic going on. Try to understand PGL files you use
(AFAIK, all object types/fields are documented). It will help you
long-term.
Thanks,
Alex.
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:19 MDT