Conference azur::mcc

Hi Ania,

The LAN BU is doing a Spanning Tree FM that maps relationships between
Bridges (looks pretty slick, actually).

I thought I heard something (during EFT Training) to the effect that
the Bridges would have Domains between them (representing LANs, no doubt),
which could contain the Station|Node4|Terminal_Server|whatever entities
on each LAN. No mention of auto-populating these domains in the first
version...

BTW, the FDDI Ring Mapping FM (also being done by LAN BU) apparently will
auto-map all stations on a FDDI Ring...

					Chris

    Thanks a lot. Could you give me a contact name of the LAN BU people?
    
    Ania

    Contact Mark Collett (DELNI::COLLETT) - LANBU product manager
    

Hi Ania,


I am the project leader for DECmcc ELM V1.1.  This release will contain 
the spanning tree map and FDDI ring map auto-topology FM's.  It will also
include the FDDI AM, and updated bridge and concentrator AMs.

Chris's description in .1 of the functionality is accurate.  For the first
release the spanning tree map will only support RBMS bridges.   The LAN segments
between bridges will be domain icons, but there is currently no capability to
automap the stations on ethernet segments.

The FDDI ring map FM will map all of the stations on the FDDI ring.

If you have any further questions feel free to contact me.


Regards, 

Bob Harokopus

>>Re .1
>>For the first release the spanning tree map will only support RBMS bridges.
>>
    
    Watch out for Vitalink bridges which also respond to RBMS queries.
    Translans will send back invalid spanning tree information for ports
    which are not configured. Here is a example of the output from a
    Vitalink with only 2 ports configured:
    
    MCC> show bridge .bridge.broad30b line * all spanning char
    
    BRIDGE JPM_DEV:.bridge.broad30b LINE 1
    AT 30-OCT-1991 17:20:28 Spanning Characteristics
    
                                 Bad Hellos = 0
                       Designated Bridge ID = 08-00-7C-00-0C-AE
                 Designated Bridge Priority = 130
                     Designated Port Number = 1
                        Designated Root Age = 0 Seconds
                         Designated Root ID = 08-00-7C-00-0B-8F << O.K
                   Designated Root Priority = 10
                          Port Module State = Forwarding
                         Possible Loop Flag = False
                             Root Path Cost = 75
           Topology Change Acknowledge Flag = False
                             Disable Switch = False
             Management Sets Allowed Switch = True
    
    BRIDGE JPM_DEV:.bridge.broad30b LINE 2
    AT 30-OCT-1991 17:20:29 Spanning Characteristics
    
                                 Bad Hellos = 0
                       Designated Bridge ID = 08-00-7C-00-0B-8F
                 Designated Bridge Priority = 10
                     Designated Port Number = 2
                        Designated Root Age = 0 Seconds
                         Designated Root ID = 08-00-7C-00-0B-8F << O.K
                   Designated Root Priority = 10
                          Port Module State = Forwarding
                         Possible Loop Flag = False
                             Root Path Cost = 0
           Topology Change Acknowledge Flag = False
                             Disable Switch = False
             Management Sets Allowed Switch = True
    
    BRIDGE JPM_DEV:.bridge.broad30b LINE 3
    AT 30-OCT-1991 17:20:31 Spanning Characteristics
    
                                 Bad Hellos = 0
                       Designated Bridge ID = 08-00-7C-00-0C-AE
                 Designated Bridge Priority = 130
                     Designated Port Number = 3
                        Designated Root Age = 0 Seconds
                         Designated Root ID = 08-00-7C-00-0C-AE << Wrong
                   Designated Root Priority = 130
                          Port Module State = Forwarding
                         Possible Loop Flag = False
                             Root Path Cost = 0
           Topology Change Acknowledge Flag = False
                             Disable Switch = False
             Management Sets Allowed Switch = True
    
    
    Ports 3 thru 9 report the wrong root bridge!!!! 
    
    Hopefully you have already seen this.
    
    Regards,
    Mike

re:  <<< Note 1728.5 by SUBWAY::REILLY "Mike Reilly - New York Bank District" >>>
                               -< Vitalinks ??? >-

>    Watch out for Vitalink bridges which also respond to RBMS queries.
>    Translans will send back invalid spanning tree information for ports
>    which are not configured. Here is a example of the output from a
>    Vitalink with only 2 ports configured:
>   

I'm pretty sure that if the network is running with Translans at 6.10 or
better, you shouldn't get *any* of that data back.   If I remember correctly
from our initial testing, the BRIDGE AM can only decode packets from Translans
running 6.9.7 or lower. (a schism in the RBSM implementation...)

/doug

I assume that the auto config is querying those boxes _registered_ as being of
class BRIDGE?  Yes?   If so, then no worry. (unless you had the bad taste to
register a TRANSLAN as a BRIDGE; then you'll finally get what you deserve! ;^)
)

/doug

    I guess I had the 'bad taste' to register the TRANSLANs as a
    bridge!  I knew it was too good to last..
    
    - Mike

Re: .4

>  The LAN segments
>between bridges will be domain icons, but there is currently no capability to
>automap the stations on ethernet segments.

Why not?

I recall using a command procedure 5 years or so ago which interrogated bridges 
via RBMS, built the spanning tree structure and placed most stations on their
correct segment (those which had never transmitted off segment could not be
correctly placed as none of the bridges' forwarding db's knew about 'em).

Now it didn't place all stations, but what it did certainly saved an enormous
amount of work.  This procedure (or at least a similar algorithm) became less
of a hack with its incorporation into POPENIM (an ASSET) - where it was used 
to place stations on their respective segments in an ETHERNIM database.

So how come this functionality hasn't made it into the spanning tree map FM?

Paul

Re: .4

>>  The LAN segments
>>between bridges will be domain icons, but there is currently no capability to
>>automap the stations on ethernet segments.

>Why not?

>I recall using a command procedure 5 years or so ago which interrogated bridges 
>via RBMS, built the spanning tree structure and placed most stations on their
>correct segment (those which had never transmitted off segment could not be
>correctly placed as none of the bridges' forwarding db's knew about 'em).

>Now it didn't place all stations, but what it did certainly saved an enormous
>amount of work.  This procedure (or at least a similar algorithm) became less
>of a hack with its incorporation into POPENIM (an ASSET) - where it was used 
>to place stations on their respective segments in an ETHERNIM database.

>So how come this functionality hasn't made it into the spanning tree map FM?

>Paul


Hi Paul,

This is something we plan to add in the next release.  Determining the stations
on each segment is relatively easy as you have indicated.  The problem is 
drawing a reasonable looking IMPM map of that information.  We just don't have 
time to solve this problem right now.  Remember that there could
be hundreds (or more) stations on each segment.  


.5 and .6 Thanks for the info on Vitalink bridges.  Vitalink support is also
something we plan to add but using the Vitalink AM.  I'll make sure I check
for Vitalink bridges registered as class Bridge.

Bob

>This is something we plan to add in the next release.  Determining the stations
>on each segment is relatively easy as you have indicated.  The problem is 
>drawing a reasonable looking IMPM map of that information.  We just don't have 
>time to solve this problem right now.  Remember that there could
>be hundreds (or more) stations on each segment.  

Well, I partially agree with this. Yes, it is not easy to write a general
algorithm that makes a nice looking map of an extended lan, but if you have
the right information in the right place certain things could be done on a
short term. We already did something similar in the past for Ethernim where
we used ,as paul indicated, POPENIM to place the stations on the right
segments, and ENIM_GRAPH to draw a 'nice'(?) looking map out of this. The 
big difference (and problem) that I see at the moment , between the Ethernim
database and the DECmcc MIR is, that Ethernim stored all the connectivity
information for all components as attributes for the components, while
the connectivity information in DECmcc can only be deducted from the map
file . And what about inactive components (dempr, despr, delni) in DECmcc?
How do figure out how these are connected. 

I understood that in V1.2 the line objects on the map will represent real
objects in the MIR. Does that mean that icons will get attributes, indicating
to which line objects they are connected. ? I think a first step should be
to store the connectivity information in an easy way. If that's done , than
you can start thinking about how to draw a nice looking map out of this, 
without crossing lines,overlaying icons etc.etc.

FWIW

Timo

    Even if you can't DRAW a map, you could put them all in the correct
    domains and let the user make the map for the first version??
    
    s/rob

    In v1.2 there will be a new module called the Circuit AM. This module
    will do just waht .11 is talking about. It will provide a mechanism for
    putting "circuits" on the map while providing management functions on
    them.Functions such as allowing the manager to set up information in
    the MIR descirbing the entity, and generating events any time the
    attributes are modified (thus allowing rules or notifications to be
    generated and icons to turn colors on the map based upon these
    changes).