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

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

1801.0. "FDDI delay? remote boot LAVC with DECbridge 900MX" by IJSAPL::ROLING () Wed Dec 21 1994 10:02

Hi,

Can someone explain he following phenomena:

My customer uses a LAVC with the follwoing network config:

VAX6xxx      +LB150+      +LB150+      LAVC member
   |         |     |      |     |      |
===============   ==========   ==========

Boottime takes 2'45"
Low network load on all segements
                                
                                
New network                 concentrator 900MX
                           ________
                          /        \
VAX6XXX           DB900MX|   FDDI   |DB900MX      LAVC member
   |              |       \        /       |       |
===================        --------       ==========

Boottime takes  2'45"
Only the concentrator does the ring purge. No other trafic on the ring
low network load on ethernet segments


                                DA30
                                |
                        concentrator 900MX
                           ________
                          /        \
VAX6XXX           DB900MX|   FDDI   |DB900MX      LAVC member
   |              |       \        /       |       |
===================        --------       ==========


BUT when the customer loads the FDDI ring with a Wandel&Golterman DA30 analyzer
with 40% load the boot time increases to 5 minutes!



Is this to be expected?
What is going wrong?
What should a proper test look like
Where to find the full Bradner test results



regards jos


T.RTitleUserPersonal
Name
DateLines
1801.1Flooding that 40%?NETCAD::SLAWRENCEWed Dec 21 1994 13:3110
    
    What is the load that's being put onto the FDDI?
    
    If it is sending packets that need to be flooded by the bridges (that
    is, either multicast packets or packets to an unknown DA), then it
    _may_ be slowing down the bridges.  Try modifying the test by sending
    the FDDI traffic from the W&G to a MAC address of another device on the
    FDDI (one that sends a packet at least every few seconds so that the
    bridges don't age out its address).