Thank you for the bug ID. The term "RND Bridge/Rtr" in this context is acutally a bridge/router device manufactured by a company called RND. Apparently when a RND bridge/router device is installed on a ring with a Cisco router containing a TRIP the TRIP could reset. This happens only if the RND device is configured for something called "SPF-SRE (shortest path first/source route encapsulation)". Apparently, when the device is configured to use this feature it sends out a special frame to a destination address of "c000.0d00.0100" and to "c000.0d00.0000". These are non-bit-specific functional address with more than one bit set. The TRIP was correctly dropping these frames (they should not be passed off the ring since they are functional) but since they were unsual (went against the IEEE 802.5 spec since they are non-bit-specific) the TRIP was taking an unusual long period of time to drop them. If the TRIP is configured for keepalives (by default it is) then it is possible for the keepalive process to fail when the TRIP is dropping these weird frames, therefore the interface resets.
The bug was closed due to the RND device not adherring to the token ring specifications. Possible workarounds would be to use a token ring port adapter in the Cisco router (the various port adapters use a different token ring chipset than the TRIP), have RND resolve the problem since they are at fault in this case, or disable keepalives on the Cisco router.
Hope this helps.
Tim
