>I have been providing this using an SLES8
> iptables server
> [...]

Your current method is pretty reasonable. Don't change it.

> I am
> curious why 6 point-2-point is a recommended maximum? Would
> this statement
> also apply to guest lan?

The major reason is the consumption of IP addresses and the general
complexity of managing that many PTP links in a single network. PTP
connections technically should have a unique IP address for each end of the
connection to avoid confusing routing protocols.  While configurations that
share a single IP addresss at the center "hub" machine work, they're hard to
debug, and you get odd results if you try to do complicated routing things
with that configuration.

We've run configurations with upwards of 100 CTCs on one guest, and I
wouldn't recommend it to anyone. It's a record-keeping nightmare, and that's
just the beginning.  If you've got a lot of guests to connect, use GLANs.

> Is this also taken to the previous
> layer of VM
> TCP/IP so an additional stack should be defined when more
> that 6?

We started seeing some strange behavior with more than 64 CTCs connecting to
a single VM stack, but that was on VM/ESA 2.4, and since guest LANs became
available, we haven't tried it again. We have a few z/VM 3.x customers who
use CTC; most have converted to IUCV if they can't use GLANs. I'd recommend
this if you don't have to talk to something that only understands CTCs. Rule
of thumb (YMMV): about 32 CTC links per VM stack, but look at your data and
see.

>I saw the
> picture in a previous posting using VLAN and switching to
> forward requests
> from guestlan back to the external firewall but I did not see
> how this was
> simpler.

It's not simpler -- in fact it's complicated. Using VLAN tagging over a
common transport to separate the traffic uses fewer physical adapters. It
consumes less physical hardware, but is no simpler to operate.

This is really more a problem of explaining to people that it's a LAN
segment just like their Ethernets, but without the ability to sniff traffic.

-- db

Reply via email to