[nsp] Fast Ethernet problems with 11.3(4)

From: sthaug@nethelp.no
Date: Tue Jul 07 1998 - 07:21:57 EDT


We have a 7206 running 11.2(8)P, routing traffic between lots of VLANs.
It's connected with a full duplex trunk to a 2900 switch. The router
uses bridged virtual interfaces for IPX, because 11.2 can't handle the
necessary IPX encapsulation for ISL/VLAN.

Today I tried upgrading the router to 11.3(4), which can support all the
necessary IPX encapsulations natively - the hope was to get rid of all
the BVIs. We have done this with 11.3(3.3) on a couple of routers earlier
with great success.

Unfortunately, 11.3(4) was a total failure. The Fast Ethernet interface
on the 7206 (this is the built in MII port) shows lots of drops and
throttles, and essentially no traffic makes it through the router:

FastEthernet0/0 is up, line protocol is up
  Hardware is DEC21140, address is 00e0.f9a8.9800 (bia 00e0.f9a8.9800)
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255
  Encapsulation ARPA, loopback not set, keepalive not set
  Full-duplex, 100Mb/s, MII
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:00:20
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 76/75, 566 drops
  5 minute input rate 13000 bits/sec, 16 packets/sec
  5 minute output rate 32000 bits/sec, 24 packets/sec
     424 packets input, 37628 bytes, 0 no buffer
     Received 126 broadcasts, 0 runts, 0 giants, 566* throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 watchdog, 0 multicast
     0 input packets with dribble condition detected
     1026 packets output, 72365 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Note that this is *not* the problem with physical address on the MII
transceiver described in http://www.cisco.com/warp/customer/770/38.html.
We have checked that the transceiver is at address 0, and output from
"show cont fa 0/0" is okay:

Interface FastEthernet0/0
Hardware is DEC21140
 dec21140_ds=0x60B0CD34, registers=0x3C018000, ib=0x4B01D100
 rx ring entries=128, tx ring entries=256
 rxring=0x4B01D200, rxr shadow=0x60B0CE28, rx_head=12, rx_tail=0
 txring=0x4B01DA40, txr shadow=0x60B0D050, tx_head=121, tx_tail=121, tx_count=0
 PHY link up
 CSR0=0xFFFA4882, CSR3=0x4B01D200, CSR4=0x4B01DA40, CSR5=0xFC660000
 CSR6=0xE20CA242, CSR7=0xFFFFA261, CSR8=0xFFFE0000, CSR9=0xFFFDD7FF
 CSR11=0xFFFE0000, CSR12=0xFFFFFF98, CSR15=0xFFFFFEC8
 DEC21140 PCI registers:
  bus_no=0, device_no=6
  CFID=0x00091011, CFCS=0x02800006, CFRV=0x02000012, CFLT=0x0000FF00
  CBIO=0xBFFBFE81, CBMA=0x48018000, CFIT=0x00000121, CFDA=0x00008600
 MII registers:
  Register 0x00: 2100 780F 2000 5C00 01E1 0000 0000 0000
  Register 0x08: 0000 0000 0000 0000 0000 0000 0000 0000
  Register 0x10: 0000 0000 0000 0000 0000 0000 8040
  Register 0x18: 8000 0020 0000 1800 A3B9
 throttled=0, enabled=0, disabled=0
 rx_fifo_overflow=0, rx_no_enp=0, rx_discard=0
 tx_underrun_err=0, tx_jabber_timeout=0, tx_carrier_loss=0
 tx_no_carrier=0, tx_late_collision=0, tx_excess_coll=0
 tx_collision_cnt=0, tx_deferred=0, fatal_tx_err=0, tbl_overflow=0
 HW addr filter: 0x60B0D878, ISL Enabled
  Promiscuous mode enabled
  Entry= 0: Addr=0100.0CCC.CCCC
  Entry= 1: Addr=0100.0C00.0000
  Entry= 2: Addr=0900.2B01.0001
  Entry= 3: Addr=0180.C200.0000
  Entry= 4: Addr=FFFF.FFFF.FFFF
  Entry= 5: Addr=FFFF.FFFF.FFFF
  Entry= 6: Addr=FFFF.FFFF.FFFF
  Entry= 7: Addr=FFFF.FFFF.FFFF
  Entry= 8: Addr=FFFF.FFFF.FFFF
  Entry= 9: Addr=FFFF.FFFF.FFFF
  Entry=10: Addr=FFFF.FFFF.FFFF
  Entry=11: Addr=FFFF.FFFF.FFFF
  Entry=12: Addr=FFFF.FFFF.FFFF
  Entry=13: Addr=FFFF.FFFF.FFFF
  Entry=14: Addr=FFFF.FFFF.FFFF
  Entry=15: Addr=00E0.F9A8.9800

It doesn't matter whether we use keepalive on the interface or not. Both
the switch and the router are set to full duplex.

Any good ideas about what could cause this? We had to revert to 11.2(8)P,
which at least is reasonably stable.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no






This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:13 EDT