| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5877.1 | Do a MCC> show bridge <ethernet_address> all attr and post output here. | STKMCC::LUND | Niklas Lund | Thu Feb 24 1994 14:25 | 0 |
| 5877.2 | info you requested | COMICS::MISTRY | | Fri Feb 25 1994 07:59 | 27 |
| Hi,
He gets exactly the same error message as before. However, if you do the
following:
MCC> show mcc 0 bridge_am all attr
He should get the following :
Available Ports = { "ln0" }
Component Version = V1.3.0
Component Identification = "DECmcc Bridge AM"
He however gets:
Cannot communicate with device ie ln0
then the component version and component id.
So i suspect the bridge am is having a problem talking to the ethernet
controller.
When you do netstat -i the ethernet device comes across as ln0*
Bipin.
|
| 5877.3 | Problem found need fix | COMICS::MISTRY | | Fri Feb 25 1994 10:12 | 13 |
| Hi,
More info:
He has 2 ethernet controllers ln0 and ln1. Now ln1 is configured ie IP address,
RUNNING and UP whereas ln0 isn't. Now I suspect the bridge access module is
looking at ln0.
Why it isn't using ln1 i'm not sure and is the code written so that it just
accesses the first device.
Bipin.
|
| 5877.4 | some info | MCDOUG::doug | Imagine whirled peas. | Fri Feb 25 1994 13:04 | 24 |
|
Can you try the command using the VIA PORT qualifier? Sounds like it could
be a bug in the AM (I.e. the AM might be handling the list of ports on the
syetem incorrectly).
The AM (I think) issues an mcc_ea_show_enet_devices() call some time before
requesting the packet to find out what the available ethernet port devices
are on the system.
According to the SRM, the mcc_ea_show_enet_devices() returns a pointer to
essentially a list (array) of ethernet interfaces on the system.
"...The array is terminated by a value of binary zero. The Ethernet
devices available in this system are returned in the order they will be
used by the Ethernet Access routines to access a target entity."
It may be possible that the AM logic is sensing the the first interface is
unavailable, and assuming that's the end of the list.
It may also be that the ln1 ethernet interface has something about it that
keeps the mcc_ea_show_enet_devices() routine from "picking it up".
What kind of device *is* ln1?
/doug
|
| 5877.5 | looks like a bug | COMICS::MISTRY | | Mon Feb 28 1994 04:29 | 7 |
| Hi,
Because there are two ports, its picking up the first one and not using ln1. I
will be spr'ing this.
Bipin
|
| 5877.6 | | TOOK::MCPHERSON | Imagine whirled peas. | Mon Feb 28 1994 10:50 | 2 |
| did you try using VIA PORT?
/doug
|
| 5877.7 | %MCC-E-MMABORT, target management | KERNEL::EVANSN | | Wed Apr 27 1994 07:35 | 19 |
| I have the same problem as in note 5877.
I can register the bridge in FCL with the VIA PORT qualifier but the bridge
cannot be managed through the iconic map (unless I have missed something).
The first device seen with netstat -in is the ln0 device which has no protocols
configured on it and has an asterisk suffix, the second is an FDDI device fza0
which is configued for both IP and DECnet.
I see from the note that the bridge AM was to be SPR'd for this problem, any
outcome on this ?
I have managed a workaround by enabling DECnet on the ln0 device but the customer
wants the luxury of being able to use both controllers and he doesn't want to
use both devices at the same time.
Regards
Neal Evans - UK Comms TSC
|
| 5877.8 | %MCC-E-MMABORT, target management thread has aborted | KERNEL::EVANSN | | Wed Apr 27 1994 12:37 | 8 |
| I have the same problem as in 5877, any progress on the SPR that was logged ?
Although I can register a bridge if I specify VIA PORT, I can then not access
the bridge via the iconic map.
Regards
Neal Evans
|
| 5877.9 | Unsupported configuration | BIKINI::KRAUSE | CSC Network Management/Hubs | Thu Apr 28 1994 06:11 | 8 |
| Did you specify the VIA PORT in the Iconic Map as well? It has to be
specified for every operation on the bridge. The VIA PORT option is
*not* stored with the entity during REGISTER.
Anyway, remember that your configuration is *UNSUPPORTED*, though it may
work with some restrictions.
*Robert
|
| 5877.10 | Exactly which bit .. | COMICS::PRICEC | J Conrad Price DTN 833-3269 | Mon Jun 27 1994 12:18 | 14 |
|
I too have a customer with twin E'nets on his MCC engine.
Could you please clarify which bit is unsupported ?
Twin ethernet I/Fs on an MCC engine using bridge AM or twin ethernets
running Decnet ????
Regards,
Conrad Price
UK CSC, WAN
|
| 5877.11 | RE: DECnet part of the question | SCCA::Dave | You think I know something about Netview? | Mon Jun 27 1994 13:51 | 12 |
| Since you dont have a diagram of the network, the only real question
that need to be asked is
"Are there ANY bridged paths between the two ethernets?"
If the reply is YES, the you CANNOT run Phase 4 DECnet on both
interfaces. DECnet (not so wisely) sets the MAC address to be an
encoding of the DECnet address for no particularly good reason,
and two ethernet controllers on the same net witrh the same address
is likly to break lots of the network.
|