Conference azur::mcc

    Can you provide this info?

MCC> show bridge HLOMCC_NS:.MCC.BRIDGE.L2A1 hardware type
MCC> show bridge HLOMCC_NS:.MCC.BRIDGE.L2A1 software version

    Thanks.

    /* Ed */

MCC> show bridge HLOMCC_NS:.MCC.BRIDGE.L2A1 hardware type

Bridge HLOMCC_NS:.MCC.BRIDGE.L2A1
AT  2-SEP-1992 16:19:59 Characteristics

                          Hardware Type = DEBAM LAN Bridge 200

MCC> show bridge HLOMCC_NS:.MCC.BRIDGE.L2A1 software version

Bridge HLOMCC_NS:.MCC.BRIDGE.L2A1
AT  2-SEP-1992 16:21:26 Characteristics

                       Software Version = "V1.9"

Thanks!
tl

    Yup, we were able to reproduce it.  Entered as QAR 3410 in
    MCC_INTERNAL.

    Unfortunately, there is no way to clear the password on the LAN Bridge
    200 without resetting the bridge to factory defaults.  If you reset to
    factory defaults you lose the forwarding database entries that you
    created.

    You could save all your created entries by using

    MCC> show bridge <name> forw data static ent * all attributes, to file
    staticentries.lis
    MCC> show bridge <name> forw data multicast ent * all attributes, to file
    multicastentries.lis

    and then edit those files to create the entries again.

    Sorry about that, and thanks for finding this bug.

    /* Ed */

Ed

Thanks very much for looking into this, and finding that it wasn't operator
error :).

1) I appreciate the work around, but what is the problem?  Am I correct in 
assuming that DECmcc does not currently support any operations to bridges which
have set a password?

2) When do you expect a fix to be available?

3) If I remove passwords from all of my bridges (not a pretty thought), will
the DELETE BRIDGE forw data multi entr commands work?

Thanks!
tl

| I appreciate the work around, but what is the problem?

    The MCC Bridge AM is putting the bridge password in the wrong place in
    the RBMS request packet for Delete Forwarding Entry.

| Am I correct in
| assuming that DECmcc does not currently support any operations to bridges which
| have set a password?

    No, passwords should work OK for all the other operations.  If not,
    please post another note.

| When do you expect a fix to be available?

    Not sure.  "Will be fixed in next release," whenever that turns out to
    be.  Probably towards the end of the calendar year.

| If I remove passwords from all of my bridges (not a pretty thought), will
| the DELETE BRIDGE forw data multi entr commands work?

    Yes.  But do you really have forwarding database entries created on all
    your bridges?  Delete Forwarding Database Multicast Entry should be a
    command that is used very infrequently.

>| When do you expect a fix to be available?

>    Not sure.  "Will be fixed in next release," whenever that turns out to
>    be.  Probably towards the end of the calendar year.

Gulp.  Any chance of getting a patched version of the offending image?

>But do you really have forwarding database entries created on all
    your bridges? 

You bet.  We have ~ 40 VAXclusters on site.  Each VAXcluster is attached to a 
segment, bridged from the backbone by a LANbridge.  Every of these LANbridges
is set to filter MOP and the SCS traffic of the VAXcluster(s) on the segment.
When a power failure occurs, these bridges ensure that MOP 'load me' screams of
nearly a thousand workstations are confined to the segments on which their load
hosts are situated.  Once booted, SCS filtering ensures that cluster traffic
stays on the segment where workstation and load host live.  Were it not for this,
we would have buried our backbone several years ago.

We're using InfoServers to house and serve CDs containing:

� VAX 6000 diagnostics
� MicroVAX Diagnostic Monitor (MDM)
� VMS binary (from which VMS can be installed onto a 'virgin' system via the
  network, with no local media)

All of these use MOP.  So, I've written a sack of DCL to prompt for the source
(InfoServer service) and target of the MOP operation, find the bridges that
lie on the path between the two, 'open' them (allow MOP to pass) and close them
after a requested time interval has expired.  This procdure will be used by
Field Service to boot diagnostics, and by Software Support and others to build
new VAX systems.

So, not only do we use multicast address filtering on all bridges, I MUST be
able to delete and create forwarding database entries at will.

Thanks!
tl

    Can anyone tell me what version of the Bridge AM this problem was fixed
    in.
    
    I seem to be seeing the same problem in bridge am v1.2.1.
    
    Thanks,
    
    Jon

    It's fixed in V1.3 of the bridge AM.
    
    -Bob