ITS router bay switch, and fast ethernet link.
bri...@julian.uwo.ca
*** THIS NOTICE DESCRIBES CHANGES WHICH DO NOT CONCERN THE CASUAL USER ***
SYSTEM: ITS/router/switch (nsca.noc)
SUBSYSTEM: cisco router, Bay 28115 switch and fast ethernet.
SYNOPSIS:
Over the past couple of weeks, we have been attempting to establish
a fast ethernet 100baseTX half-duplex link between the 7513 cisco
router, and a Bay 28115 U (adv) ethernet switch. These tests were
prompted by the inability to complete the backbone upgrade which
would have seen this link established.
Discussion:
Here is what we've done and found out so far.
A new Bay switch came in a couple of weeks ago. This was shortly
after our aborted router/backbone 100Mb upgrade. Since we have no
device for testing with fast ethernet, we decided to use the switch
to provide a means for testing, (it has some IP services available.)
The switch could not be put into service yet, because the wiring upgrade
in our building is not complete enough to move ahead with this phase
of the project.
(At some point in the future, it would be beneficial for us to have
some kind of a machine with a fastethernet interface on it, for
testing purposes.)
A connection was established via type 5 cable from the router to the
switch, and the router was configured to enable its fastethernet
interface. Since we support the IP, IPX, appletalk, and decnet
protocols on our backbone, we decided to try configuring for all of
these on our test setup. The link didn't work. The line protocol
on the cisco fastethernet interface was unstable and kept changing
between up and down. The switch was unpingable (in the IP sense.)
We removed decnet routing from this interface, and found that we could
ping the switch and/or a PC attached to another port on the switch.
In an attempt to duplicate our situation on the backbone, we
temporarily borrowed to unused IP subnets, 129.100.220.0 as primary,
and 129.100.221.0 as secondary. The router will not permit a second
interface to be configured on a network that is already being serviced
by another interface.
With decnet removed the fastethernet interface was stable for short
times when there was activity, but after periods of quiescence, it
eventually became unstable and unusable. We put in a request for
assistance to t...@cisco.com and after about a week got some useful
feedback about possible solutions to the problems.
These are, (disable keep-alives), or (use transceivers for
communication between the devices.)
Bay Networks also confirmed the incompatibility problems which are
due to the presence of a watchdog process running on their switches.
Every so often this process resets the interface hardware by sending
some data for about a microsecond. The router thinks that it should
also reset it's interface, and the interface can be down for a minute
or more each time one of these resets is received. Bay says that
the cisco router should not respond in such a way to these signals,
and they both say that each other is obstructing the testing process.
However, apparently Ford Motor Company and Cisco have forced the
two of them to co-operate in getting the problems defined exactly,
and worked out.
Bay also has a hardware revision (H) for their switches that fixes
this problem, but our latest switch came with revision (E), and there
is some reluctance by Bay to make available this upgrade.
Keep-alives were disabled on the router's fastethernet interface,
and IPX and appletalk protocols were also enabled. The link is now
relatively stable, though there are still some carrier-drops and
output errors. With decnet enabled, the interface became unusable
again, so this means some more work with cisco. The
We will also be trying the transceiver approach in our search for
a better solution, but these devices (AUI to 100base-tx) still have
to be obtained from somewhere.
CHANGE SUMMARY:
1. Installed Bay switch, and an appropriate electrical link between
them.
2. Configured the interface on the router to temporarily use IP
addresses 129.100.220.1 and 129.100.221.101, (similar to backbone
setup.)
3. Tried various tests and protocol configuration to establish a
reliable 100base-TX link between the devices.
4. Have presently, a fairly reliable IP, IPX, appletalk (if there was
something to which it could talk for appletalk port configuration)
link available.
PEOPLE:
There is more work to come. These tests should have no noticeable
effects on the rest of the campus network.
Done by Ted Gauci and Brian Borowski.
SCHEDULE:
Done: over the period Thu Oct 3 to present 1996.
RECOVERY:
Contact the NOC, or myself, if there are problems.
USER NOTIFICATION:
Just this notice, and email to those directly concerned.
Notice generated by: mkcn V-1.1