Conference azur::mcc

3502.0. "ELM V1.0 displays 2 NI lines on a DECbridge 600" by UTRTSC::BEEKMAN (Ton Beekman - CS/SSO - The Netherlands.) Wed Aug 05 1992 09:44

    
Hi,

A customer of mine has a DECbridge 600 with a NULL FI module.
The problem is that the third ethernet line is not seen by DECmcc
The customer is still running DECmcc BMS V1.1 and DECmcc ELM V1.0

MCC> SHOW BRIDGE .TN.BRIDGE17 ALL ATTR

BRIDGE TN_NS:.TN.BRIDGE17
AT  4-AUG-1992 14:32:51 All Attributes

                                Address = { 08-00-2B-68-E6-7A,
                                            08-00-2B-28-E6-7A,
                                            08-00-2B-28-E2-7E}
                                        .
                                        .
                                        .
                   Device Configuration = ( (        FRU Type = AP Card,
                                                    FRU State = Working,
                                                       FRU ID = N/A,
                                                 FRU Revision = Revision 8 ),
                                            (        FRU Type = Three NI Card,
                                                    FRU State = Working,
                                                       FRU ID = N/A,
                                                 FRU Revision = Revision 8 ),
                                            (        FRU Type = FI Card,
                                                    FRU State = Working,
                                                       FRU ID = N/A,
                                                 FRU Revision = Revision 4 ),
                                            (        FRU Type = QM Card,
                                                    FRU State = Working,
                                                       FRU ID = N/A,
                                                 FRU Revision = Revision 0 ),
                                            (        FRU Type = Fan,
                                                    FRU State = Working,
                                                       FRU ID = N/A,
                                                 FRU Revision = Revision 0 ) )
                       Firmware Version = V2.9.0
                          Hardware Type = DEFEB DECbridge 600
                                     ID = %X08002B28E67A
                             Port Count = 3


MCC> SHOW BRIDGE .TN.BRIDGE17 LINE * ALL ATTRIBUTES

BRIDGE TN_NS:..TN.BRIDGE17 LINE 1 
AT  4-AUG-1992 14:34:00 All Attributes

                            Port Number = 1
                          Datalink Type = FDDI Ring
                           Port Address = 08-00-2B-28-E6-FA
                                Port ID = "1"

BRIDGE TN_NS:..TN.BRIDGE17 LINE 2
AT  4-AUG-1992 14:34:12 All Attributes


                            Port Number = 2
                   Physical Medium Type = Standard AUI interface
                           Port Address = 08-00-2B-68-E6-7A
                                Port ID = "2"


BRIDGE TN_NS:..TN.BRIDGE17 LINE 3
AT  4-AUG-1992 14:34:18 All Attributes


                            Port Number = 3
                   Physical Medium Type = Standard AUI interface
                           Port Address = 08-00-2B-28-E2-7E
                                Port ID = "3"


So LINE 4 (third NI port) is missing!!!
However this line is functioning normally. Systems connected to this
ethernet can communicate with systems on the other two ethernets.

Is this problem caused by the NULL FI card or is it the DECmcc ELM V1.0 
software?

I don't have a DECbridge 600 here to reproduce this problem, 
and to eventually test it with DECmcc BMS V1.2 and DECmcc ELM V1.2

Any help would be appreciated.

Thanks in advance

Ton Beekman
    

| Is this problem caused by the NULL FI card or is it the DECmcc ELM V1.0
| software?

    I'd find it hard to believe that it's the MCC ELM software, I think we
    would have seen this problem reported before if it was.  The ELM
    software is pretty much an RBMS to MCC ILV translator, so we rely
    heavily on what the bridge returns back to us.  Getting packet dumps
    from the bridge would be useful in diagnosing this problem.

    I can try to locate a DECbridge 600 (ethernet only) here and see what
    happens.

    We found a DECbridge 600 here and were able to reproduce your problem
    in our lab.

    We understand what is happening between the bridge firmware and the MCC
    management software, and we are trying to determine the most
    appropriate solution to this problem.

    Thanks for finding the problem!

    Here is the latest information about the DECbridge 600 not being able
    to manage the last ethernet line.

    The network management folks talked to the firmware folks and we now
    agree that this is a DECmcc ELM problem.  However, we think this is a
    low priority problem for the following reasons.

    * The DECbridge 600 (three-port ethernet-only non-FDDI bridge) is a
      very low volume product -- I think we've only sold ten units so far. 

    * The agent software for the DECbridge 600 includes SNMP support, so it
      is possible to manage the bridge line that way (DECmcc V1.2
      Director and BMS both include the SNMP AM for free).

    * If you have access to DECmcc/MSU (Management Station for ULTRIX) on
      site, it is possible to manage the line using its ELMS
      interface or SNMP.

    If anyone knows of major customers who are having major customer
    satisfaction problems because of this, I can pass that on to my manager
    who may then decide to increase the priority of this bug.

    The DECbridge 600 and its last ethernet line are functioning normally. 
    Unfortunately, that line cannot be managed with the ELM AM.

    Let me know if there are any other questions or concerns about this
    issue.