Very Computer

I have a problem that I have been able to reproduce on multiple
segments of our network. Whenever I attempt to FTP from a SCO box (ODT
2.0, ODT 3.0 or OSR 5.0) using a 3COM Etherlink III (I think) card to
a box on another BNC segment using ANY other NIC besides the 3COM
Etherlink III card the FTP rates are on the order of 9K/sec. Normal
transfer rates are on the order of 300-600K/sec. An Asante hub
connects these segments. When I use any other hub the problem
disappears. I have tried isolating the segments, moving the segments,
moving servers to other segments. Nada. I have contacted Asante about
this and they have not had the time to set up a test. If any one else
has a similar setup, I would be curious if you are having any similar
symptoms.

Thanks
Larry Webb

Quote:webb writes:
>I have a problem that I have been able to reproduce on multiple
>segments of our network. Whenever I attempt to FTP from a SCO box (ODT
>2.0, ODT 3.0 or OSR 5.0) using a 3COM Etherlink III (I think) card to
>a box on another BNC segment using ANY other NIC besides the 3COM
>Etherlink III card the FTP rates are on the order of 9K/sec. Normal
>transfer rates are on the order of 300-600K/sec. An Asante hub
>connects these segments. When I use any other hub the problem
>disappears. I have tried isolating the segments, moving the segments,
>moving servers to other segments. Nada. I have contacted Asante about
>this and they have not had the time to set up a test. If any one else
>has a similar setup, I would be curious if you are having any similar
>symptoms.

use netstat -i, note the ierr, oerr, and collis fields.  The reason the
transfer is slow is probably due to collisions and errors.  You probably
have a defective hub.

With a shared media network, it is often nearly impossible to isolate problems
and fix them.  We have been going through that here for a year now.  One
of my networks (enc01)  just up and dies for 2 seconds up to 20 minutes.
err, oerr, and collis all go up rapidly for a long period of time; but NOT
long enough for me to be able to actually test anything.  It often heals
itself, or I can "heal" it by copying some large files from the main system
to the auxilliary system over that network.

My point?  Shared media is a nightmare!!!  Can't wait to replace all this
stuff with fiber optic with each office being their own network on a
fiber switch.   I'm working on it now, with 1,000,000 other projects.

--
  /--------------------------------------------------------------------------\
  | Mark A. Davis     | Lake Taylor Hospital | Norfolk,VA (757)-461-5001x431 |

  \--------------------------------------------------------------------------/

: transfer rates are on the order of 300-600K/sec. An Asante hub
: connects these segments. When I use any other hub the problem
: disappears. I have tried isolating the segments, moving the segments,
: moving servers to other segments. Nada. I have contacted Asante about
: this and they have not had the time to set up a test. If any one else
: has a similar setup, I would be curious if you are having any similar
: symptoms.

Check the error rates on the SCO end with:
        llistat
If it's a managed hub with SNMP, telnet into the box and watch
the numbers pile up.  Also, do some traffic analysis even if
means watching the lights flash.  If there is lots of traffic
showing but nothing is moving, you have a problem worth of a
Protocol Analyzer.

I'm going to make a guess that your problem is either:
1.  Duplicated IP address somewhere.
2.  Overlapping IP address ranges on multiple cards in the SCO
server address space.
3.  Misconfigured overlapping broadcast address on the SCO box.
4.  Router loop.
5.  Hub loop.  (multiple hubs connected in a loop).

Every one of these can do amazing things to a network.  You
were on the right track by seperating the network segments.
However, that won't work if the cards are misconfigured.
Turn the cards off one at a time with software.  Run:
        ifconfig net0 down
to turn off an interface.  Note that this does NOT disable
routing through this interface so you may need to also run:
        route delete whatever_you_have_going
to disarm that monster.  Let the server run on only one for
a while and see if it fixes the problem.

Duplicated IP addresses can be found with protocol analyzers.
OSR5 will complain loudly if it finds one.  You can also run:
        arp -a
multiple times and look for an IP address with constantly
changing MAC address.  This is a bit tedious but effective.

One of my customers is heavily infested with Asante hardware.
Lots of MacIntosh cards, hubs and 10baseT/100baseT switches.
It's good stuff, quite reliable and cheap.

There is also a small chance that the reason the problem
goes away with another hub is that some device (3Com card)
is belching mutilated packets and the Asante hub is more
sensitive than the un-named replacement.  This is where
a managed hub or running llistat will show corrupted packets.

[x] Email to author  [ ] To mailing list  [x] Posted to newsgroup
--
# Jeff Liebermann  Liebermann Design  150 Felker St #D  Santa Cruz  CA  95060

# 408.699.0483 digital_pager    73557,2074  cis [don't]