[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

1205.0. "Locating DECnet, TCP nodes in relation to bridges" by CRONIC::LEMONS (And we thank you for your support.) Mon Jul 01 1991 18:56

    I'm writing a procedure that will be used at our sites to allow Field
    Service engineers to 'open' bridges, allowing them to pass the MOP
    protocol (normally, this protocol is filtered by all of our bridges).
    This will allow F/S to boot diagnostics on systems connected
    to 'private' Ethernet segments from InfoServer 100 devices connected
    to our Ethernet backbone.  The F/S engineer will know the node name of
    the system they need to boot diagnostics on.
    
    I'm looking for a tool that will map node names (DECnet, and preferably
    TCP/IP, too) to the names of the bridge(s) between the system needing
    repair and a network control system (running DECelms, to open/close the
    bridges) on the same segment/backbone as the InfoServer 100.  Further,
    this tool must store this data in a file, as it's likely that the system
    F/S will work on won't be running when the bridge open request is
    generated.  Finally, this tool must update its data file periodically, to
    account for changing network topology.
    
    I've got a feeling that some of what I require is available in DECmcc
    and its components.  But I'm not sure which piece(s) to focus on.
    
    Any suggestions?
    
    Thanks!
    tl
T.RTitleUserPersonal
Name
DateLines
1205.1CRONIC::LEMONSAnd we thank you for your support.Mon Jul 08 1991 14:335
Is this really that hard, or am I so totally off-base that no response is
possible?

Thanks!
tl
1205.2One idea..SUBWAY::REILLYMike Reilly - New York Bank DistrictMon Jul 08 1991 15:2943
    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
    
    
    
1205.3EISNCG::OLEARYMon Jul 15 1991 18:4411
    
    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
1205.4Light dawns . . .CRONIC::LEMONSAnd we thank you for your support.Fri Jul 26 1991 20:3813
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
1205.5I see a monster DCL procedure brewing..SUBWAY::REILLYMike Reilly - New York Bank DistrictTue Jul 30 1991 00:047
    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
    
1205.6Naw, no monster.CRONIC::LEMONSAnd we thank you for your support.Wed Jul 31 1991 00:3115
    >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
1205.7Bridge FunkinessRACER::DAVEAttending The School of Comparative IrrevelevanceWed Jul 31 1991 11:4722
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.
1205.8SUBWAY::REILLYMike Reilly - New York Bank DistrictWed Jul 31 1991 12:036
    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
    
1205.9CADSYS::LEMONSAnd we thank you for your support.Mon Aug 17 1992 20:5013
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
1205.10sanity check neededCADSYS::LEMONSAnd we thank you for your support.Wed Aug 19 1992 17:1014
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
1205.11CADSYS::LEMONSAnd we thank you for your support.Tue Sep 01 1992 18:131
hello?
1205.12SLINK::CHILDSThe FringeWed Sep 02 1992 14:379
    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...