Conference netcad::hub_mgnt

>VAX_A and VAX_B both have two ethernet cards, running DECnet Function license. 

This will NOT work, because when you start DECnet on both controllers
they will both get the same Ethernet address. To be precise, it would
work a little, but with awfully bad performance due to many retries.
This has nothing to do with the forwarding database in the bridge -
other than you'd confuse the hell out of it because of the double
address. 

*Robert

My finding is a little different than your comment. 

I used a terminal on Segment_A to sign on to VAX_A, then copied a 20K block file
from VAX_A to VAX_B. It took about 5 minutes. When I took a look at the LEDs of 
the UTP ports the VAXes connected to, all four LEDs were flashing like hell (I
believe it's a healthy sign.) The NCP counters of the VAXes together with the
LEDs of 900MXes show that the file was sent from both Ethernet controllers of
VAX_A and received by both Ethernet controllers of VAX_B.

I ran the same test again. But this time I disconnected the FDDI cable between
the 900 bridges. The result was identical !!!!

From my understanding of Ethernet and bridging, the configuration as shown in
.0 should be illegal. Because both VAXes will be seen at both Ethernet port 
and FDDI port of a 900MX. As such, when a packet comes in from a UTP port, it 
will be forwarded to the other UPT port, as well as to the FDDI ring. So the 
other VAX will receive the same packet twice. But the test result is contrary
to this. The only way I can explain this is that the 900MX maintains only one
address table?!

Would you (or some other noter) please help clarify how the 900MX will handle 
situation like this? 

If someone is interested, please also comment what will happen if LANbridge 
200 is used to connect Segment_A and Segment_B. Will spanning tree be running?


Many thanks in advance.

Richard

    Hello;
    
    This system will work very nicely for you.  I have it running at two
    different customer sites, and it just requires some tuning.
    
    First, the response in .1 is correct, You Cannot run DECnet PhaseIV on
    two ports of a VAX unless that VAX is a router, and the ports are on
    different networks.  The DECbridge 900MX is a BRIDGE which makes all of
    the attached segments appear in the same broadcast domain.  You CANNOT
    put a bridge in parallel with a router.
    
    If the Bridge sees ANOTHER BRIDGE (or it's own BPDU messages) then it
    will shut down all but the designated bridge port that LAN segment. 
    This is part of the Spanning Tree Protocol.  Routers (such as VAXes
    running DECnet) don't participate in STP because they aren't bridges.
    I believe (someone correct me if I am wrong) that the bridge stores all
    of it's address data in ONE TABLE.
    
    Such as this bridge Address table from a LANBridge 150.
    Learned Physical Address Entries          As of:  7-SEP-1994 20:22:11
     Name: ELMS$08002B083324                 Address: 08-00-2B-08-33-24
    Address       Outbound      Last     Disposition   Set by   Aging
                  Line          Seen
                                On Line
    
     AA-00-04-00-FF-93  1       1     LEARNED LINE 1  LEARNING DYNAMIC
     AA-00-04-00-FF-91  1       1     LEARNED LINE 1  LEARNING DYNAMIC
     AA-00-04-00-FF-87  2       2     LEARNED LINE 2  LEARNING DYNAMIC
     AA-00-04-00-FF-84  2       2     LEARNED LINE 2  LEARNING DYNAMIC
     AA-00-04-00-FE-FF  1       1     LEARNED LINE 1  LEARNING DYNAMIC
     AA-00-04-00-FE-90  1       1     LEARNED LINE 1  LEARNING DYNAMIC
     AA-00-04-00-FE-86  1       1     LEARNED LINE 1  LEARNING DYNAMIC
     AA-00-04-00-FD-FB  2       2     LEARNED LINE 2  LEARNING DYNAMIC
    
    
    As you see, the bridge appears to learn an address, and stick the port
    number of the line where that SOURCE address appeared in the database. 
    I would hope that the DB900mx uses a VERY LARGE table, and a simple
    notation about what port that address was last seen from, and some NEAT
    mathmatical quick-search algorythm that I don't comprehend to search
    this table and forward the packet when the source and dest are on
    different ports.
    
    It is my gues that your DB900mx was a very busy camper.  Each time that
    a packet from your VAX with an addres of AA-00-04-my-vax showed up, it
    would LEARN that packet with a source of LINE 2.  And moments later, it
    would see a packet from that SAME AA-xxx address, and RE-LEARN the
    address on a different LINE, and dutifully update it's forwarding
    table.  So the data would get there, and many duplicate packets would
    arrive at both of your VAXes.  Unfortunately, there is NO WAY to see
    how many DUPLICATE PACKETS were received on each VAX.  (This is not one
    of the counters you can find from NCP, or SHOW LAN /COUNT.)  The VAX
    would just ignore the DUPs, and carry on (good old DECnet), creating a
    large amount of extra CPU and LAN overhead.
    
    Therefore you must disable DECNET on one of the Ethernet controllers on
    your VAX.  You CAN run LAT, and LAVC on both ports however, which will
    work nicely, if you do some small configuration changes.
    
    WARNING:    YOUR CONFIGURATION WILL NOT WORK CORRECTLY USING THE GENERIC
    		AUTOMATIC PARAMETERS assigned during the VMS autoconfigs.
    
    You must:  a)  Disable DECnet on One of the EThernet Controllers:
    		   I have arbritrality chosen to delete DECnet assignment
    		   for the second Ethernet controller in this example: 
    	
    			$ MCR NCP
    			NCP>  show know lines
    			Known Line Volatile Summary as of  7-SEP-1994 19:25:29
    			   Line             State
    			  MNA-0             on
    			  MNA-1		    on
    			NCP>  show known cir
        		Known Circuit Volatile Summary as of 7-SEP-1994
    			   Circuit          State
    			  MNA-0             on
    			  MNA-1             on
    
    			NCP> set exec state shut
    			NCP> set circuit MNA-1 state off
    			NCP> Clear circuit MNA-1
    			NCP> purge circuit MNA-1
    				All circuit parameters (Y, N): y
    				%NCP-I-SUCCESS,  Success
    				circuit = MNA-1
    				%NML-I-RECDELET, Database entry deleted
    			NCP> clear LINE mna-1
    			NCP> purge line mna-1
    				All line parameters (Y, N): y
    				%NCP-I-SUCCESS,  Success
    				Line = MNA-1
    				%NML-I-RECDELET, Database entry deleted
    			NCP> exit
    			$ @sys$manager:startnet
    	   Now the controller will no Longer assign DECnet to that interface.
    	   And It will come up with it's HARDWARE MAC Address, not the
           AA-00-04 address.  This will confuse LAT, so you must:
    
    b) fix the LAT LINK assignment in the LAT$SYSTARTUP.COM file.
 
       
    		$ edit sys$startup:lat$systartup.com
    			
    	change the line that creates a link on the second controller to 
    	include the flag:   /NODECNET
    
    		$ lcp := $latcp
    		$ lcp 
    		CREATE LINK MAIN_LAN  /DEVICE=XEA0: /STATE=ON
    		CREATE LINK OTHER_LAN /DEVICE=XEB0: /STATE=ON  /NODECNET
    		EXIT
    		$ 
    
    
    	Now, Reboot your System.   You will have DECnet running on only one
    controller.   You will have LAT, and LAVC running on both.  LAVC is
    smart enough to experiment and find the fastest path between nodes and
    use it's favorite.  DECnet will not work if the primary line drops.  SO
    your redundancy is manual.  You must enable DECnet on the backup line
    by hand, or through a command procedure.   If you Upgrade to DECnet/OSI
    you can run both DECnet ports at once, and it will be happy.  If you
    are running UCX or another IP stack, you must assign a separate IP
    address to each interface, and act like an IP router.
    
    I have a VAXcluster with several VAX9000's and Alphas running in this 
    exact configuration.  There are two DECbridge900MX's, and several 
    DECNIS600's and the customer is very happy with the performance.  The "PE"
    (Personal Ethernet) concept is very valid, and helped my customer to
    understand the importance of network bandwidth.  We had totally
    overwhelmed three Ethernets (more than 70% util on each) before this 
    upgrade.  Now the Ethernets are running at 5% each, and the VAXcluster
    traffic stays inside the FDDI and the two DECbridges. 
    
    This is an interrim but very cost-effective step in the overall
    migration plan to installing an FDDI controller on each big host.  But
    it works very nicely for older machines or (ughh) Q-BUS hosts that
    cannot handle the throughput of FDDI. 
       
    Good Luck
    
    JR
    

>When I took a look at the LEDs of 
>the UTP ports the VAXes connected to, all four LEDs were flashing like hell (I
>believe it's a healthy sign.)
    
    I assume you mean the traffic LED and not the port state LED.  This
    indicates that traffic was being seen on these ports.
    
>From my understanding of Ethernet and bridging, the configuration as shown in
>.0 should be illegal. Because both VAXes will be seen at both Ethernet port 
>and FDDI port of a 900MX. As such, when a packet comes in from a UTP port, it 
>will be forwarded to the other UPT port, as well as to the FDDI ring. So the 
>other VAX will receive the same packet twice. But the test result is contrary
>to this. The only way I can explain this is that the 900MX maintains only one
>address table?!
    
    Firstly, I don't understand the reason for this configuration. 
    However the number of address tables is not the issue - bridges
    usually have a single address table regarldess of the number of ports.
    The address table associates an address with a port.  A packet will
    not be sent out of two ports as you explained above, but only the
    port which the address is currently associated with.
    
    Given your configuration, both VAX A and B could possibly be learnt on
    2 ports -- the port on which it is connected, and the FDDI port.  It
    will flip-flop based on the traffic.  However, the packet will always
    get there since there is always a good path to it!  That is, regardless
    of where the bridge currently thinks a VAX is, it will send the
    packet to it and it will get it.  When you removed the FDDI, there
    was only one path to it which continued to work.  Take a look at
    the port packet counters to see which ports are actually doing most
    of the forwarding.  This config is not recommended, obviously.
    
>If someone is interested, please also comment what will happen if LANbridge 
>200 is used to connect Segment_A and Segment_B. Will spanning tree be running?
    
    Yes, spanning tree will run and resolve the loop.  This would be
    a much better way to provide the redundancy you seem to be looking
    for.  You could also, instead of using a LB100, create
    a LAN between the two ports rather than directly connecting the
    VAX to the two ports (by using a DELNI or 10BaseT repeater between them,
    for example) and connect the VAX to the LAN - this would be much more
    cost-effective than a LB200 and spanning tree will still resolve
    the loop between the DB900MX's.
    
    Anil

John and Anil,

Many thanks taking time to give my customer such clear explaination.

Anil,

The reason the customer wants the VAXes connected to the bridges rather than
Segment_A and Segment_B is that he wants full 20 mbps between the VAXes.

Two more questions...

When you say STP will be running, do you mean one of the 900 bridges will 
become standby, assuming that the cost of the LAN bridge 200 is the lowest. If
that's true, each VAX will have one of its Ethernet cards doing nothing
then. Am I right?

Furthermore, if I remove the FDDI connection between the 900MX bridges, and 
connect Segment_A and Segment_B together with a LAN bridge 200, will STP
still be running among these three bridges. 


Many thanks in advance.

Richard
 

Hello;

	IF I understand your config, It looks kinda like this


	DB900======fddi=========DB900
	| | |			| | |
	| | |			//  |
        | |  \______VAX1_______//   |
	| \______VAX2__________/    |
	|			    |
enet1   |		      enet2 |
++++++++++++++              ++++++++++++
   	    \                  /
	     \_____LB200_____ /


This is a perfectly good configuration,
and is a good backup, in case the FDDI goes
down.  You need a network management package
such as DECelms, or DECmcc to set up the DEBAM
to be the "most expensive" path, so that it will
shut down it's ports.  It is likely that the 
DEBAM (If it's been around a while) has a lower
address number than the DB900mx, so the LB200 will
become the root, and therefore not disable itself.

You need to set the costs of the LB200 lines to some
really high number (like 100) instead of the default
cost of 10.  This will cause the DB900 to service the
enets, and the LB200 will put it's highest port into
stand-by mode. 

It's a shame, but you need several management tools to
make such a network perform the way that you wish.


Good Luck.

JR

>The reason the customer wants the VAXes connected to the bridges rather than
>Segment_A and Segment_B is that he wants full 20 mbps between the VAXes.
    
    I don't believe this can be made to work.
    
>When you say STP will be running, do you mean one of the 900 bridges will 
>become standby, assuming that the cost of the LAN bridge 200 is the lowest. If
>that's true, each VAX will have one of its Ethernet cards doing nothing
>then. Am I right?
    
    Couple things - a bridge doesn't becomes standby, it's a bridge
    port that becomes standby.  The distinction is an important one,
    esp for multiport bridges.  And, in your scenario with the LB200
    it will be one of the LB100 ports OR one of the DB900MX's FDDI ports
    that will go into standby -- not any of the ports connected to the
    VAXes.  You can visually tell a standby port by looking at its port
    state LED - it will blink once a second rather than stay on.
    
>Furthermore, if I remove the FDDI connection between the 900MX bridges, and 
>connect Segment_A and Segment_B together with a LAN bridge 200, will STP
>still be running among these three bridges.
    
    Yup.
    
    For more detail on spanning tree, please see Chapter 3 of the
    "Bridge and Extended LAN Reference Manual" which gets into all this
    very clearly.
    
    Anil

Hi Anil,

In the second part of your reply (.7), What made you think STP would still be 
running even if the two 900MX are not connected via FDDI.

According to my .6 , the config would be like this (Thanks to John for the 
diagram) :


        DB900                   DB900
        | | |                   | | |
        | | |                   //  |
        | |  \______VAX1_______//   |
        | \______VAX2__________/    |
        |                           |
enet1   |                     enet2 |
  ++++++++++++++              ++++++++++++
            \                  /
             \_____LB200_____ /


Since the VAXes do not pass 'inter-bridge messages', there should be no loop 
in the topology. As such, all bridge ports should be active and forwarding 
packets happily? Do you agree ?


Richard

    The Spanning Tree ALWAYS runs.  It is the method (one packet every
    hello interval) that tells the bridges that the ROOT is available and
    that the Tree is configured properly.  
    
    You are correct, that in the case where the FDDI is removed, then no
    loop is created, so no PORTS will be disabled, but it is through the
    STP that the bridges discover this fact.  You need to read the document
    listed in .7 for a detailed explanation of STP.  The Spanning Tree
    ALWAYS runs.  It is individual bridge ports that are placed in
    BACKUP mode, listening for hellos, in case the tree changes.
    
    Some Vocabulary for you to research:
    	ROOT BRIDGE
    	DESIGNATED BRIDGE
    	Spanning Tree
    	Cost to Root
    	Root Priority
    	Line Cost
    	Hello Interval
    	Bad Hello Count
    	Learning
        Pre-Forwarding
    	Forwarding
    	Backup
    
    Once you understand these vocabulary words, the Spanning Tree
    autodetection becomes very intuitive and easy to understand. Your
    homwork assignment is to attach a definition to each of the terms
    above, and then explain them to us. 
    
    Happy Reading.
    
    JR

    re: The Bridge and Extended LAN Ref Man, is such a thing online?
    
    thanx,
    hw

    I copied it off the net somewhere a year or so ago, but I've lost the 
    pointer. It  could be elsewhere in this conference.
    
    The Order Number is EK-DEBAM-HR-003
    
    jack