Very Computer

by **Allen Ruet** » Fri, 17 Jun 1994 06:17:55

Is any one else having problems bridging LAT across Cisco 7000/AGS+ FDDI
rings? Bridging LAT seems to work well ethernet, but FDDI interfaces
get/cause ring inits and LAT goes down the tubes.

by **baldw..** » Mon, 20 Jun 1994 00:45:58

>Is any one else having problems bridging LAT across Cisco 7000/AGS+ FDDI
>rings? Bridging LAT seems to work well ethernet, but FDDI interfaces
>get/cause ring inits and LAT goes down the tubes.

Your best resources for LAT isues are Michael Metzler and Michael
Raspuzzi, both with Digital's colorado support center. 800-digital.

If you haven't tried already.

by **Christian Dint** » Mon, 20 Jun 1994 19:52:57

>Subject: Any one else having problems with bridging LAT?
>Date: Wed, 15 Jun 1994 21:17:55 GMT
>Is any one else having problems bridging LAT across Cisco 7000/AGS+ FDDI
>rings? Bridging LAT seems to work well ethernet, but FDDI interfaces
>get/cause ring inits and LAT goes down the tubes.

Dear Allen,

YES, we've HAD this problem as well here on our CISCO-NET!

The problem showed up with a similary configuration,

Ethernet -> AGS+ -> FDDI -> CS7000 on one site the AGS+ over HSSI 8 MB links
to AGS+ again to Ethernet and FDDI with CS700 attached to the FDDI.

Ethernet
|----+--------------------+-------|
AGS+ AGS+
| \ / |
| FDDI +-------------------HSSI
| |
| CS7000
|
+-------------------------------------------HSSI

At the other end of the HSSI mirrored config, GOT IT?

So THE problem has to do with 802.1d, DEC spanning tree and transparent
bridging!
We bridge LAT and other bridged protocol from ethernet over the AGS+
-> HSSI-> AGS+ to another Ethernet. NOW, the CS7000 are sending out FRAGMENTS
ofBPDU's (Bridging Protocol Data Units) which are missinterpreted by the AGS+
inthe form of changing the ROOT Bridge from one of the AGS+ to another one.
Thismesses up all the nice bridge-tree to be recalcultated and flipped for and
back. There is NO configuration HELP, BUT there is allways a BUT, CISCO has
made a BUG-FIX for us. Might be it is allready incorporated with the lates and
greatest SW release.

Overview of our SW rel.:
_/_/_/_/_/_/_/_/_/_/_/_/_/
AGS+'s

GS Software (GS3-K), ExperimentalVersion 9.1(2483) [mmcneali 100]
Copyright (c) 1986-1993 by cisco Systems, Inc.
Compiled Fri 06-May-94 14:16

System Bootstrap, Version 4.6(10), SOFTWARE

RKAR01 uptime is 2 weeks, 6 days, 1 hour, 16 minutes
System restarted by reload
System image file is "HLR-k.Z", booted via flash

CSC4 (68040) processor with 16384K bytes of memory.
X.25 software, Version 2.0, NET2 and BFE compliant.
Bridging software.
1 MCI controller (2 Ethernet, 2 Serial).
1 cBus controller.
Environmental Controller.
2 Ethernet/IEEE 802.3 interfaces.
2 Token Ring/IEEE 802.5 interfaces.
2 Serial network interfaces.
1 HSSI network interface.
1 FDDI network interface.
64K bytes of multibus memory.
64K bytes of non-volatile configuration memory.
4096K bytes of flash memory on MC+ card (via ENVM).
Configuration register is 0x102

CS7000's

GS Software (GS7), Version 9.17(9), RELEASE SOFTWARE
Patchlevel = 9.1(11)
Copyright (c) 1986-1994 by cisco Systems, Inc.
Compiled Wed 20-Apr-94 17:01 by pitoscia

System Bootstrap, Version 4.6(6), SOFTWARE

Current date and time is Fri 6-17-1994 17:32:43
Boot date and time is Sat 5-28-1994 16:21:28
RKAR20 uptime is 2 weeks, 6 days, 1 hour, 11 minutes
System restarted by power-on
System image file is "gs7-917.090", booted via flash

RP1 (68040) processor with 16384K bytes of memory.
X.25 software, Version 2.0, NET2 and BFE compliant.
Bridging software.
1 Switch Processor.
1 TRIP controller (4 Token Ring).
3 FSIP controllers (24 Serial).
4 Token Ring/IEEE 802.5 interfaces.
24 Serial network interfaces.
1 FDDI network interface.
128K bytes of non-volatile configuration memory.
4096K bytes of flash memory on embedded flash (in RP1).
Configuration register is 0x102

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

So, CISCO made a special SW version for us to fix the problem called

HLR-k.Z for the AGS+

HLR means F.Hoffmann-La Roche AG abbreviated HLR

CISCO did NOT explain why the CS7000 FDDI Interfaces are passing the
fragments to the Spanning-tree process, but the FDDI implementation, BASED ON
THE STANDARTS, should NOT pass fragments out of the "Interface Board" trough
the I/O to the MAIN CPU and then to the process's?!?

SOME more things are happening with the FDDI interfaces if two CISCO routers
are attached onto the same FDDI and having DEC bridging (802.1d) running over
them AND one if the router is switching spanning. The second router is
"dropping" down his FDDI interface for a very short moment!
This means the spanning could switch on one site, FDDI reinit and on an other
site the FDDI reinitializes aswell at the same TIME!

At the present we're undergoing a massive change for all CS7000 regarding the
FDDI interfaces. Means, CISCO changes all, ALL, CS7000 FDDI boards, SW and
EEPROMS on our sites (This weekend by the way). So I'm working an'other
weekend (NO end!!) :-))

Hope this helps you further with your problem! Ask CISCO about the BPDU bug.

Kind regards and prosper routing from

Christian

#_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_#
#
# F. Hoffmann-La Roche AG, Switzerland
#
# Christian Dinten, Sr. Network Analyst
# Dept. PSIN / NCC (Network Control Center)

#
# X.400 C=CH;A=ARCOM;P=ROCHE;O=ROCHEBASEL;S=DINTEN;G=CHRISTIAN
# Tel. +41 61 687 20 10
# Fax. +41 61 687 34 10
#_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_#

All statements, names, ideas are my point of opinion and therefore not that of
my employer's.