Conference 7.286::fddi

555.0. "Cisco Bridging Problems!" by SANFAN::RICHARDS_LA () Mon May 04 1992 20:29

Hi there,

We have experienced major problems with Cisco AGS+ bridging...  Following 
is a simplified diagram of our customer's network configuration.  We have
high average utilization on our Ethernet backbone and are attempting to
replace the Ethernet backbone with a Cisco FDDI backbone.

Problem Description:
An SCS file transfer of approximately 450 Mbytes which takes 90 minutes 
to complete via Ethernet would take approximately 6 hours (estimated average) 
to complete via the Cisco/FDDI path.  Two DECbridge 500's were brought 
in and installed in parallel with the Ciscos. The same file transfer 
takes approximatley 1 hour to complete via the DEC Bridge 500/FDDI path. 
We believe that in the case of the DECbridges the maximum speed of
the file transfer is constrained by the disk controller and not FDDI or the
DECbridges.

PC's which remote boot from the VAX cluster take approximately 35-40
seconds to boot over Ethernet.  The same PC's took approximatley 70-75 
seconds to boot via the Cisco/FDDI path without a load on the network.  
We then added an average network load (25%) by starting up the SCS file 
transfer.  None of the PC's were able to complete their boot process via 
the Cisco/FDDI path after the network load was added.

Other major problems identified while an SCS file transfer was in progress:
1) Cluster perfomance was degraded significantly (the 6000's are part of a 
multi-lobed MIVC).  In fact, the cluster was almost useless.  When doing 
a show system we saw that many of the processes were in a RWSCS state.
2) Broadcast/multicast storm which caused a network meltdown.


Question:
Has anyone out there experienced similar problems or does anyone have 
any ideas what might be causing our problems? 


Comments:
Bottom Line...  Our multi-lobed MIVC which performs fairly well on 
existing Ethernet is rendered useless over the Cisco/FDDI 
backbone.  Other bridged protocols such as LAST & LAT were also severely 
degraded.  In fact, several times it seemed that traffic was completely blocked 
by the Ciscos which caused our cluster to crash.

Cisco has been contacted and is working on the problem.  They will be 
on site on Wednesday (5/6) to hopefully isolate and correct the problem.
 
We are VERY concerned about the performance of the Cisco bridges!!!  

All bridges used in our testing were running DEC spanning tree instead of 
802.1d spanning tree.

I will add additional information concerning this problem as soon as I 
have it.  

This note was also added to the VAX cluster notes file.

Thanks,
    
Laurie
    
    
Simplified Diagram of Network Topology: 

		VAX 6000
		   |              Thickwire Ethernet
 ====================================================================
	|				|
	|				|
     Digital			      Cisco
     LB 150			      AGS+
	|				|
	|			+===============+
	|F 			|		|
	|I			|  FDDI Bacbone |
	|B			|		|
	|E			|		|
	|R			+===============+
	|				|
     Digital			      Cisco
     LB 150			      AGS+
	|				|
 =====================================================================
			|		Thickwire Ethernet
		     VAX 6000
  
      

    Question..."Two Bridge 500 were brought in and installed in parallel
    with the Ciscos...." Do you mean..."replace the Ciscos"?
    
    Does the Cisco implement the true IEEE 802.1 standard loop detection
    as the Brdige 150 and the Bridge 100 do? If not, according to your
    diagram, the spanning tree of the bridges will not work properly and
    you will have a hard time with the network. *cast is an obvious.
    
    -dave 

    Hi Dave,
    
    Thanks for your input.  The two DECbridge 500's which were brought in
    were installed in parallel with the Ciscos.  I then used port costs so
    that the path from Ethernet to Ethernet would be through the
    DECbridges.  es and not the Ciscos.  We verified that the Ciscos were
    in backup (or blocking) mode by doing a "show spanning" on the Ciscos.   
    
    The Ciscos implement both the DEC spanning tree as well as the 802.1d
    spanning tree. We en We did verify thru DECelms that our LB150's were going
    into backup which indicates that the Ciscos are participating in the
    DEC spanning tree.
    
    Thanks again,
    
    Laurie

    Laurie,
    
    In this case, I really have doubt about the perforamnce of the Cisco 
    AGS+. What it is telling me is that apparently the Cisco takes a lot of
    overhead to forward data.
    
    If you refer to notes 186 and 340, you might find some indicators for 
    your problem. 
    
    Good luck...
    
    
    
    -dave