JROSEN@macc.wisc.edu (Jay Rosenbloom) (05/23/91)
Hello, We have a bunch of Proteon p4200s on an FDDI ring. I was wondering if we'd have any problems adding Cisco AGS+s with FDDI interfaces to this ring. Is anyone using Ciscos and Proteons on the same FDDI network? If so, did you encounter any problems initially. Have there been any ongoing problems related to incompatibility between the two? Thanks, -Jay .............................................................................. Jay Rosenbloom Phone: 608-262-9421 jrosen@macc.wisc.edu Univ. of Wisconsin-Madison Fax: 608-262-4679 jrosen@wiscmac3 Madison Academic Computing Center, 1210 W. Dayton St., Madison, WI 53706
Allen Robel <robel2@mythos.ucs.indiana.edu> (05/23/91)
Hi Jay, One possible source of trouble is bridging. The cisco manual doesn't specifically mention whether they are an encapsulation or translation bridge over FDDI. The manual *does* say this (pp 17-3, November 1990): The transit bridging of Ethernet datagrams across an FDDI is also supported. The term transit refers to the fact that the source or destination of the datagram cannot be on the FDDI ring itself. This implies to me that the cisco is an encapsulating bridge. If this is so, its pretty much guaranteed that it will be incompatible *for bridging* with your Proteons. You may also want to check to see what type of bridging the Proteon supports. If you're not bridging any traffic, you probably won't have any problems (unless there are inherent incompatibilities between the two vendor's FDDI implementations which I doubt in this day and age...). Maybe someone else can speak to this. regards, allen
rwf@cisco.com (Robert W. Fletcher Jr.) (05/23/91)
>> We have a bunch of Proteon p4200s on an FDDI ring. I was wondering if we'd >> have any problems adding Cisco AGS+s with FDDI interfaces to this ring. >> Is anyone using Ciscos and Proteons on the same FDDI network? If so, >> did you encounter any problems initially. Have there been any >> ongoing problems related to incompatibility between the two? I don't know of any customer sites, but we have interoped with Proteon's FDDI implementation several times at ANTC (AMD testing) and at a University of New Hamsphire bake off. Fletcher cisco Systems
BILLW@mathom.cisco.com (WilliamChops Westfield) (05/24/91)
The transit bridging of Ethernet datagrams across
an FDDI is also supported. The term transit refers
to the fact that the source or destination of the
datagram cannot be on the FDDI ring itself.
This implies to me that the cisco is an encapsulating bridge.
Exactly right. "transit bridging" == "encapsulating bridging". Nearly
guaranteed not to interoperate with any other vendor.
Bill Westfield
cisco Systems.
-------William "Chops" Westfield <BILLW@mathom.cisco.com> (05/24/91)
> Exactly right. "transit bridging" == "encapsulating bridging". > Nearly guaranteed not to interoperate with any other vendor. Are you saying that cisco can't ROUTE to/from a node on FDDI, or does it do that as well ? Sigh. Since you are the second person to mis-interpret my remarks, perhaps a public statement is in order... "encapsulation bridging" or "transit bridging" is a scheme whereby you bridge together a bunch of ethernets, using an FDDI ring as the backbone. This is similar to bridging two ethernets across a T1 line, only different. Each ethernet packet is "encapsulated" entirely (including ethernet headers) inside an FDDI packet. The FDDI packet will be given a type code like "cisco transit bridging", flooding might be done by sending packets to the "cisco transit bridging multicast address", and so on. There are currently no standard values for any of these typecodes or addresses, so each vendor has picked their own, and it is doubtfull that they interoperate WHILE DOING TRANSIT BRIDGING. Eventually, there will probably be a standard, and everyone will eventually support it. "transparent bridging" is reaonsably standardized. You take your ethernet, token ring, or FDDI packets, fiddle their header bits, change back and forth (maybe) between "ethernet" and "SNAP" encapsulation, and send the new packet out on the new interface, where it hopefully looks as though it was originated by a host on the same local media. Cisco currently doesn't support transparent bridging to or from FDDI at all - while not conceptually difficult, transparent bridging potentially requires filtering (discarding) FDDI packets at media rate (400k pps or so). This can be done with special hardware, but it's a bit beyond the capability of even the RISCy VLIW buzzword buzzword bitslice processor on cisco's current FDDI card. In addition, the FDDI chipset needs to be able to tell which frames to strip from the ring, even though neither the source nor destination address matches the local address. This capability is not present in the current implementation either (ah, the curse of being first). So transparent bridges ought to interoperate ok, but they aren't common yet. Of course, WE all know that bridging is a terrible idea anyway, and what one really wants to do is route... The cisco should be compatible with all other FDDI routers for any protocol whose format on FDDI has been defined. I think this includes IP, DECNet, Appletalk (phase 2) and CLNS. In addition, there are a set of protocols whose FDDI formats are "obvious" (eg, same as Token Ring, or ethernet typecodes converted to SNAP), and there is a very good chance we inter-operate with any vendor routing those protocols (I think this includes XNS, Novell, Vines, and 3com). There are some whose encapsulation is somewhat strange (Apollo explicitly made their FDDI encapsulation compatible with transparent bridging to ethernet, rather than the more obvious token-ring like encapsulation). Finally, there are a couple protocols done in the obvious way (ether-->SNAP) that you probably can't find another router to do anyway (PUP, Chaos). Summary: A cisco router/bridge should interoperate correctly with any other vendors' devices on an FDDI ring runnin ANY protocol EXCEPT "transit" or "encapsulation" bridging... Bill Westfield cisco Systems. -------