Conference azur::mcc

Is this really that hard, or am I so totally off-base that no response is
possible?

Thanks!
tl

    This is not so easy.  Multi segment LANS normally don't have a
    static configuration. If you determine the path between your load
    host and the target system and store it in a file, there is a very
    good chance that this is not the path which will be in use when you
    need it.  
    
    Any tool you develop will have to determine the current bridge
    configuration before it attempts to change the filters.  
    
    Assuming you are only using DEC bridges on your LAN, the following
    procedure may work.  
    
    Power up the target machine and let it issue a load request. This
    will place it's address in the bridge forwarding tables. You stated
    that ALL your bridges filter out MOP requests.  If this is so then
    only bridges attached to the segment that the target machine resided
    on will hear the MOP request and add the address to it's forwarding
    tables. Using ELMS or DECmcc you can query each bridge on your LAN
    and ask if the bridge has your target machine in it's forwarding
    table.  Bridges that know about the target machine are attached to
    the same segment. 
    
    With this info you now known the name of a bridge attached
    to the segment the target machine resides on.
    
    Trace the path from this bridge up to the root bridge.  This is
    accomplished by asking the bridge to show it's root bridge and it's
    designated bridge.  It's designated bridge is the next step on the
    way to the root bridge.  Check both line 1 and line 2 of each bridge
    as only one of the lines will be pointing to the real designated
    bridge. You will now have a list of bridges which connect the target
    segment with the root segment.
    
    Perform the same trace from the segment attached to the InfoServer.
    Compare the two lists of bridges and locate the first bridge common
    to both lists.  The bridges between this common bridge and the end 
    segments must have the MOP filter removed for a down-line load to
    work.
    
    - Mike
    
    
    

    
    I may be wrong, but I thought a network Assets tool known as POPENIM
    did a function "similar" to what you are looking for.  From what I've
    been described, POPENIM used RBMS data to correctly place nodes on the
    NMCC/VAX ETHERnim map (database).  I do know that POPENIM no longer
    works with some of the later releases, but you might be able to get
    some hints/ideas from the code.  
    
    Network assets tools are discussed in the HORUS::NASSETS conference.
    
    Mike

Mike

Thanks again for your suggestions in .2!  I'm finally writing the procedure
to accomplish .0, and I have a question:

> Check both line 1 and line 2 of each bridge as only one of the lines will be
> pointing to the real designated bridge.

And how can I tell which line points to the real designated bridge? By choosing
the line with the lowest Root Path Cost?  Or is there another way?

Thanks!
tl

    Check both of the lines as the designated bridge for one of the
    lines will be the bridge itself.  Be careful with LB200's as they
    have two addresses and either address can be returned as the
    designated bridge.
    
    - Mike
    

    >Check both of the lines as the designated bridge for one of the
    >lines will be the bridge itself.
    
    You're right (I checked).  One line showed a designated bridge of the
    real designated bridge; the other line showed itself as the designated
    bridge.
    
    >Be careful with LB200's as they
    >have two addresses and either address can be returned as the
    >designated bridge.
    
    Sorry, I'm not sure I understand your point.
    
    Thanks!
    tl

LB200's use two different address ROM's, one for each port.
In the normal case, you will see two addresses that are sequential,
e.g.

	08-00-2b-13-de-4b and 08--00-2b-13-de-4c

Note that there is NOTHING that enforces this, it is only a quirk
of the manufacturing line procedures that this is true.  One could
just as well see a LB200 that has completely different address that
appeared to be totally random.

DECbridge-500's use the "shadow" address to give the "other" port
its address.  E.g. the address of one port will be, for example,
08-00-2b-15-e4-5f, and the other address will be that address ORed with
%X'40-00-00', i.e. 08-00-2b-55-e4-5f. (The shadow address is on the Ethernet
side.)

I am not sure what the new FDDI to Ether bridge will do with its three
port cards, as I have not noticed on on the net here in LKG.  I know there
is one, however, and I guess I should go figure out what it does for
addresses.

    A LB200 has a different ethernet address on each line.  If the
    designated bridge for the device your are examining is a LB200 the
    designated bridge address returned can be either of the LB200's addresses.
    
    	- Mike
    

Re .2

Good advice.  My situation is additionally complicated in two ways:

1) the ~ 40 bridges on my LAN may or may not be filtering MOP at the time I
run my procedure, and
2) it would be nice to have the procedure work on nodes that are running, or
were just shutdown (a running node may have been known to many bridges, depending
on which noes it was communicating with).

Other thoughts?  Has anyone written a tool like this already?

tl

Let's say I do the following:

MCC> show bridge *   for dat dyn ent <source-address> outbound port, to file a.a
MCC> show bridge *   for dat dyn ent <target-address> outbound port, to file b.b

Then I compare these two files.  Where I find a bridge that hears the source and
target on different ports, I know that this bridge stands between the two.  For
my purposes, I then set this bridge or these bridges to pass MOP, and I'm off
and flying.

Or am I missing something here?

Thanks!
tl

hello?

    Hello. :-)

    I'm not sure that the folks that can best answer your questions about
    this are here reading this file.  You might want to ask in
    NAC::RBMS_LANBRIDGE100.  That conferences is more specific to the inner
    workings of bridges, this conference is mostly bridge management as it
    relates to DECmcc.

    Press <Select> or <KP7> to add to your notebook...