Conference 7.286::fddi

704.0. "Cisco Bridging Not Fast Enough!" by SANFAN::RICHARDS_LA () Mon Sep 14 1992 17:41

CISCO ROUTERS CAN NOT BRIDGE PACKETS FAST ENOUGH TO KEEP UP WITH VAX 
6000s!!

Anyone thinking about using Cisco's boxes on a network where the Ciscos 
would have to bridge SCS traffic between cluster nodes or bridge LAST 
traffic to boot PCs PLEASE THINK AGAIN. The Ciscos will NOT perform in 
this configuration. In fact, Cisco's bridging performance is so poor that if 
you have any significant amount of bridged traffic I would recommend 
against using Cisco.

I posted a note (#555) last May about performance problems with the 
Cisco routers.  Please read that note for a detailed explanation of our 
configuration.  To summarize...  When using Ciscos to bridge packets 
between two Ethernets over the FDDI, performance was unacceptable.  Later 
we saw similar degraded performance when bridging between two ports on the 
same MEC-6 Ethernet card.

Cisco engineers have been working on the problem for over three months.
They have come to the conclusion that our problem resulted from the 
fact that the Ciscos can not forward bridge packets fast enough to 
keep up with our 6000s and therefore were dropping a significant ammount 
of packets. Cisco engineers were able to reproduce the problem in their lab 
using two VAXstation 4000-200 and some Sun workstations.  Cisco used the 
new FCIT FDDI controller, the new software (v9.1), the new processor 
(CSC-4) and new microcode on the MEC-6 in an attempt to fix our problem. 
They came to our customer last week and told them that they DO NOT have 
a fix to the problem.  They stated that they are not a bridge vendor and 
for a network such as our customers (mainly bridged protocols) they 
would not recommend a Cisco only solution.  They also stated that there 
would not be a fix to the problem anytime in the near future since it 
was a hardware problem.

The bottom line is that Cisco routers can not accept back to back 
bridged packets and will drop a significant amount, therefore greatly 
impacting those functions (i.e. cluster, PCSA) which depend on bridged 
protocols.  

Your questions and comments are welcome.

Thanks,

Laurie Richards

Cross posted from NOTED::DECNIS, for your interest.

I have just been involved in a bid to sell network services to a customer,
the customer has ciscos, so we were supported in the bid by cisco.

This particular customer had a serious problem with performance of bridging via
their ciscos. The cisco guy explained why the ciscos had problems with bridging
(well, his explanation was more on why they route better than bridge). 

This is what he said...

� bridging on the cisco is performed by the central processor, not by the
  line cards.

� the bridging performance is therefore constrained by the throughput of the
  multibus (to which the central processor is connected).
	> this is a 153Mb/s bus
	> he quoted a pps of 45K pps
	  (though I think this is for the Cbus not multibus ?)

� the bridging was made worse by the way multicast and broadcast are handled
	> the multicast/broadcast comes in via one port, is then sent to
	  the central processor, which in turn sends it to each port 
	  which is performing bridging
	> this means if a cisco is bridging 10 LANs, a multicast/broadcast
	  goes across the multibus 10 times - once in and nine times out.

� ciscos answer to this was obviously to route all traffic that could be routed.
	> when routing the forwarding can be done by the line card. This
	  not only does not involve the central processor, but also does not
	  necessarily put load on the multibus (depending on the actual cisco
	  configuration).
	> aside re:.1 The MEC6 cannot handle more the about 4 "fully loaded"
		      Ethernets...

Could someone from the DECNIS team do a "compare and contrast" of this cisco
operation with that of the DECNIS.

Cheers,
	Ian