Conference azur::mcc

What type of bridge is .mcc.bridge.r2c2 ?   DECbridge 90?

Hi Tl,

The Last Port Heard parameter is only supported for static entries.
This is because for learned entries the Outbound Port is always the
same as the Last Port.

If you want to know the port that the station has been learned, then 
use the Outbound Port parameter.  In the example you posted the entry
has been aged out of the database.   

If this is a DECnet node then it probably means that the MAC address
has been overwritten by DECnet.   There is a formula for finding the
new MAC address by using the DECnet address.

Otherwise,  you may be able to wake up this address by doing a 
show station 08-00-2b-1d-ea-15.

I'll QAR the Bridge AM book if it indicates that dynamic entries
have the Last Port heard attribute.

Thanks,

Bob

.1>What type of bridge is .mcc.bridge.r2c2 ?   DECbridge 90?

                          Hardware Type = DEBAM LAN Bridge 200

.2>I'll QAR the Bridge AM book if it indicates that dynamic entries
.2>have the Last Port heard attribute.

"  4.8   Showing Static Entry and Dynamic Entry Attributes

  Static and dynamic entries identify individual network stations.
  The Show directive displays identifier, status, and
  characteristics information for static and dynamic entries.

  Look into a Bridge, look into Forwarding Database, look into Static Entry
  or Dynamic Entry, select an address
  Operations -> Show -> Characteristics
                          Status
                          Identifiers"

This sure says to me that Characteristics, Status and Identifiers are valid for
BOTH static and dynamic entries, where this is not the case.

.2>If you want to know the port that the station has been learned, then 
.2>use the Outbound Port parameter.  In the example you posted the entry
.2>has been aged out of the database.

Right you are!  I was looking to find the hardware address for a system on which
DECnet was active.  No wonder I didn't find it.  I had forgotten about that -
thanks!

MCC> show bridge .mcc.bridge.r2c2 for data dyn ent AA-00-04-00-2D-18 all char

Bridge HLOMCC_NS:.mcc.bridge.r2c2 Forwarding Database Dynamic Entry AA-00-04-00-
2D-18
AT 19-AUG-1992 09:57:22 Characteristics

Examination of attributes shows:
                          Outbound Port = 1
                            Disposition = Learned
MCC>

Doing a MCR NCP SHOW EXEC STATUS on the system yielded the "DECNET address",
which was seen.

Is there a way to display only the outbound port parameter?  I've tried the Help
and various pervertations of "...char outbound_port", but can't seem to find
the right one.

Thanks very much for the help!
tl

tl

--> Is there a way to display only the outbound port parameter?

    Yes, try this:

MCC> show bridge .mcc.bridge.r2c2 for data dyn ent AA-00-04-00-2D-18 -
    outbound port

Ed

Perfect.  Worked like a champ!

Thanks!
tl

Hi tl,


The section of the bridge AM book that incorrectly indicates that the 
"Last Port" attribute is supported for dynamic entries has been entered
as QAR 3382.

Thanks for finding this documentation error.

Bob

    Hi, guys,
    
    	What is the plan for implementing an autotopology tool for
    verifying and validating the network topology using the bridge
    forwarding databases and commands similar to that mentioned in .4?
    
    Seems to me that, once you have the bridge topology and appropriate LAN
    domains connected to each LINE of each bridge, the next step is to move
    through the forwarding database of each bridge, grab the physical
    addresses, resolve them using address backtranslation entries in the
    MIR or namespace, and then autoplace the entity by name in the proper LAN
    domain based on last port seen.
    
    This would be a really nice selling feature for DECmcc.
    
    Regards,
    Dan

We are currently working on a utility to do ethernet station mapping
using the spanning tree map and information from the bridge forwarding datbase.
We don't have a firm date as to when this will be ready on MCC.

Regards,

Bob

re: .8 

>We are currently working on a utility to do ethernet station mapping
>using the spanning tree map and information from the bridge forwarding datbase.

    Will the utility simply register everything as a STATION or will it
    attempt to make any determination as to whether or not the station is
    actually a:
	Terminal Server
	Bridge
	DECnet IV node (endnode, L1, L2 router)
	DECnet V node
	TCP/IP node
	etc.

    Ideally I'm thinking about something along the lines of the type of
    discovery that Ethernim does (did?), but more thorough (and maybe more
    'open-ended')...    

    Just hoping...
    /doug

	

RE: .9

>    Will the utility simply register everything as a STATION or will it
>    attempt to make any determination as to whether or not the station is
>    actually a...


  I believe that the populating that their station mapping does with Spanning
Tree is strictly Ethernet STATIONs (they already do FDDI STATION mapping).
What they're planning is an excellent start - certainly much better than
empty domains between the bridges! ).

  Even doing this first step is not without its challenges (e.g. getting the
forwarding tables from Bridges that speak ELMS + VITALINK ELMS + SNMP,
getting a complete Spanning Tree when many non-DEC bridges are present, etc).

  BTW, the ELM people looked at doing a similar thing with the FDDI-Stations
for V1.2, but couldn't find a straightforward way to do it in MCC.

  This would be a GREAT Network Application (superset of "ENIM Replacement").

						Chris  

  

  

Well I would've been remiss NOT to have asked, Chris.... 

I agree it's a great start. However, I would like to plant the seed so that
they don't "design themselves into a corner" and incremental enhancement to 
"multiprotocol, auto-topology  Nirvana" is possible....

;^)

/doug

    I like that one! :-)