Path: utzoo!attcan!uunet!husc6!rutgers!mailrus!cornell!uw-beaver!uoregon!jqj From: jqj@uoregon.uoregon.edu (JQ Johnson) Newsgroups: comp.dcom.lans Subject: Re: What about "brouters"? Message-ID: <2969@uoregon.uoregon.edu> Date: 14 Oct 88 13:49:02 GMT References: <281@fed.FRB.GOV> <25255@bu-cs.BU.EDU> <2944@uoregon.uoregon.edu> Reply-To: jqj@drizzle.UUCP (JQ Johnson) Organization: University of Oregon, Computer Science, Eugene OR Lines: 22 Charles Hedrick describes the situations in which a cisco HyBridge would not function correctly in a complex bridged topology -- basically, one in which the HyBridge was acting as a router for at least one protocol and was in parallel with a bridge. The basic problem with the HyBridge that I see is that it makes understanding and managing your network more complex; you can no longer see your extended Ethernet as an Ethernet, but must now take a protocol-specific view of it and pay more attention to its internal structure. Imagine the complexity if we had an extended Ethernet with several HyBridges, all with different rules as to what kinds of protocols to route, plus perhaps some other bridge that can filter packets based on protocol types! (this suggests that we could regain some simplicity by extending the spanning tree protocol for bridges to include filtering/routing information, so I could automatically disable forwarding of those protocols for which an alternative bridged path exists, and automatically enable routing if no bridged path existed). As I said before, I think the HyBridge is a very neat product. I do think it increases the complexity of what used to be a simple notion -- what IS the extended Ethernet? And I do think we should accept the priority of the RAD advertising that has been using "brouter" for a different sort of product for quite some time.