enger@europa.asd.contel.com (Robert M. Enger) (05/21/91)
Hello There Cisco fans: I am posting three questions: 1) Should an FDDI interface in 'wrap' state SERIOUSLY debilitate an AGS+? 2) Which buffers are controlled by Hold-QUE: system or interface? 3) Is there a known problem storing HOLD-QUE commands in memory? If these are old questions or common knowledge, I apologise for having wasted everyone's time. Configuration: AGS+ with (among other interfaces) FDDI and MEC6. Software 8.2(3). cBus Type 3.0, uCode 1.0. FDDI hw 4.0, firmware 128.43 FIRST QUESTION We are using two AGS+ with FDDI interfaces in a demonstration network. These two AGS+ are the only devices on the FDDI. Each AGS+ is equipped with an MEC6. Currently one ethernet interface is being used locally on each cisco. A number of Sun workstations and other equipment are attached to each of the two Ethernets. After installing all the equipment I ran ttcp between two Sun SS's (one on each Ethernet) and found abysmal results. Examination of the packet flow showed that packets were being lost. Cisco customer support suggested that I increase the 'hold-que OUT' parameter for each of the interfaces in operation. (more on this later) No improvement. I noticed that the interfaces were accumulating 'ignored' errors (as well as some dropped). I was puzzled and began to poke around to see if I could find a cause. When the system was originally installed only 1 FDDI cable was available. So, the two AGS+s had been running with their FDDI interface(s) 'wrapped'. As I was running out of other things to try, I located a second FDDI cable and plugged it in. Voila 7+Mbps from ttcp. No more dropped packets. Just to make sure that I didn't have a bad FDDI assembly, I unplugged the original cable and re-ran the test: the old abysmal performance! Apparently operating the FDDI in the 'wrapped' state seriously debilitates throughput. Does anyone know why? More curious: If I run tests between two Ethernet ports on the SAME MEC6 (obviously on the SAME AGS+) I noticed that if I unplug one of the (supposedly uninvolved) FDDI cables (forcing 'wrap' state) that the throughput is cut in half! It's as if the FDDI adapter is dragging down the router. (is the FDDI 'firmware' buggy or executed on the cBus controller?) SECOND QUESTION The manual indicates that there are TWO forms of buffering used in the AGS+: system buffers, and 'interface hardware internal buffers'. Does anyone know which of these is affected by settings of the HOLD-QUE parameter? Can anyone offer any insight on the organization/use of the various buffers? THIRD QUESTION In following the advice of cisco Tech Support I configured the interfaces for increased values of HOLD-QUE and saved the changes to memory. I then reloaded the router and found that my changes were NOT in effect. Show config reveals that the instructions are in memory, but show interface indicates that they are not in effect. (I did a Show Interface before the reload and the changes WERE in effect). Thus it appears that the parser/interpreter that reads the configuration commands from memory after a reload is not listening to the HOLD-QUE command. Is this a known bug? I do not see it listed in the release notes. Maybe 'operator error'?? Thanks in advance! Bob Enger Contel Federal Systems enger@seka.scc.com (internet) -- Robert M. Enger CONTEL Federal Systems enger@seka.scc.com (Internet)