🚀 go-pugleaf

In comp.sys.sequent, pete@wvus.org (Pete Gregory) writes:
>Hi - PTX 1.1.1 here on 3xS27's + 2xS81's...
>
>One of our S81's has enough tcp connections that we've had to buy a second
>SCED card (each SCED card will carry up to 256 tcp connections, a hard
>limit).

I find this tcp limit very hard too believe.  What does the SCED card
have to do with TCP?  Did they move the TCP/IP code into the SCED card
for PTX?  It certainly has nothing to do with TCP in our Sequent S27
runing Dynix V3.0.17.9.

If there's a limit of 256 TCP connections I wouldn't expect it to be
in the SCED card.  It would be a kernel problem.

What happens when you reach this limit?

>The idea
>here is that some people would telnet to the first SCED card, and others to
>the second SCED card, thereby distributing the tcp-connections load evenly
>among the two SCED cards and avoiding problems by overflowing one or the
>other.

>When the two SCED cards' IP addresses are set to be 89.0.0.5 and 89.0.0.40,
>the second SCED card end up transmitting ALL outbound packets; netstat -i
>looks like this:

This is just the way TCP/IP works.  The tcp output routine uses the
routing table (netstat -r) to determine which interace to send a packet.
It will send the packet out the first interface it finds with the
correct network address.  If both your interfaces are configured for the
same network (89), then all packets will go out the first interface.
(notice that this logic has nothing to to with TCP connections).

Notice that netstat -i doesn't say anything about the number of TCP
connections associated with the card.

>Something else I've tried: using IP addresses on different network numbers
>(ie. 89.0.0.5 and 88.0.0.40), but we can't reach the 2nd SCED card, even
>when I manually put entries for the 2nd SCED card in all machines' ARP
>tables.

To distribute the load, you have to make it look like two different
ethernet cables - i.e. give them different network numbers - like you
tried above.

The problem is that the workstations assume that all hosts on the
same ethernet cable will have the same network number.  So if you
have a workstation with address 89.0.0.10, and it tries to talk
to the Sequent as 88.0.0.40, it won't work.  The workstation doesn't
know how to send packets to network 88 - and on most systems, there's
no way to assign two different network numbers to the same
ethernet interface.

What you can do is change the IP address of half of your workstaions
so they too are on the 88 network.  Then they will be able to talk
to the Sequent.  But then they will have problems talking to other
workstations that have IP address with 89 network number.

You can solve this by making the sequent act as a gateway between the
two networks (which it will do automatically.  On the workstations,
just configure the sequent as the default gateway.  If the workstation
has an 89 address, then use the 89 address of the Sequent as the
default gateway and address, and if the workstion has an 88 address,
then use the Sequent's 88 address as the gateway.  BTW, on Unix
workstations you normally define the default gateway (i.e. route) with
a command that looks something like this: "/usr/etc/route add 0
89.0.0.40 1".

The problem with this set up is any time a workstation needs to talk
to another workstation that has a different network number, all the
traffic will have to go through the Sequent, and will appear on the
cable twice.  If you have very little traffic between the other
workstaions, this might not be too bad.

But basically, all this shouldn't be required.

Curt