kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (10/06/88)
In article <Oct.5.22.19.11.1988.27612@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: > [delete all the good design advice that you can't buy at any price, including a discussion about routing and bridging...] > >I understand that you'd feel safer with bridges that could handle most >of the bandwidth of an Ethernet. On the other hand, if they can >really handle 20 to 30%, that may well be good enough. The whole >point of a bridge is to increase overall capacity by separating local >and non-local traffic. You'd hope that even on a 100% loaded >Ethernet, no more than 20 to 30% of the traffic would be going to >destinations off the Ethernet. > cisco is now selling the Hybridge and I expect to see others soon offering similar products. For those not intimately familiar with the Hybridge and the brouter concept behind it: cisco has a MultiChannel Interface (MCI) card that will hold two Ethernet interfaces and two serial port interfaces (running from 2400 bps up to T1 and beyond). The MCI has a CPU and some memory on it. The CPU/memory can do routing and bridging on the card. The MCI card(s) go into a standard Multibus I chassis with a 680x0 CPU card, optional config memory card, and possibly other interface cards of various sorts. The whole kaboodle is a kind of multiprocessor architecture designed to bring very high throughputs to (some) of the packet paths in the "brouter". The throughput is needed to run real internet packet forwarding (like IP, DECnet, XNS, PUP, Appletalk, Chaos, and ISO CLNS/ES-IS) together with bridging software. This is cisco's idea of a brouter. The Hybridge is a small chassis with two slots and two cards; one MCI (limited to two ports only) and the 68020 CPU card. The Hybridge runs all the internet forwarding protocols and the Bridge software. The Hybridge is essentially a two port brouter. You can also run Bridge software on other multiport cisco routers by buying the Bridge software as an extra cost option. [End of marketing regurgitation.] Taking the Hybridge as a kind of "proof of concept" product, I expect to see similar devices from other vendors, so from this point on let me speak of "brouters" as boxes with capability similar to the Hybridge. cisco is claiming 12kpps [I assume minimum size packets] throughput between the two Ethernet interface ports on an MCI. Therefore, the alleged throughput of a Hybridge is 12kpps, a combination of routed and bridged packets. cisco makes no distinction between the throughput of routed versus bridged packets. Accepting these figures as indicative of actual operational performance, is there any reason why a brouter isn't a superior product over a router or a bridge? Prices are similar or less. I would expect to use a brouter to route all protocols that supported internetting, and selectively bridge protocols that were not able to be routed either because the vendor doesn't understand (like that Mass computer company whose president amuses us about twice a year with his outrageous witticisms) or because, like EtherTalk, the protocol isn't yet supported by the brouter vendor. I would expect the hardware performance needed for bridging to help speed up routing and the flexibility to selectively use bridging to temporarily solve problems with unroutable protocols would be far better than either routing or bridging alone. Should we be telling each other: "The router versus bridge wars are over. Buy brouters and make your decisions in software not hardware." ? And, finally, does anyone have first hand knowledge about the actual operational performance of the Hybridge? How do we measure that anyway? (I can't afford a lab full of HP analyzers :-) Please don't flame on me about the "route not bridge" or "bridge not route" dichotomy. I will argue that you have the choice with a brouter and that a software choice is better than a hardware choice. You can always fix your mistakes by hitting a software switch. You can also migrate from an all bridge to a router/bridge configuration much more easily. Please, let's assume for the sake of argument that hardware performance is actually in the range of 10kpps (unless you are going to say that you know that the Hybridge doesn't cut it and that nothing else will either). Dr. Hedrick, what is your opinion? Do you think that brouters have a future? I could see them helping rcd@fed.frb.gov migrate his network to a routing network. Do you? Kent England, Boston University
hedrick@athos.rutgers.edu (Charles Hedrick) (10/07/88)
>Dr. Hedrick, what is your opinion?
Just so we're clear on what is and isn't implemented where with the
cisco Hybridge:
- the MCI card actually has 4 interfaces, not 2. Up to 2
Ethernets and 2 serial lines (each of which will go
to at least T1, and I think I heard 4Mbit/sec mentioned).
There will also be a version later that has 4 serial
lines only.
- much of the work of packet forwarding for both bridge and
router is done in the MCI card. However in the current
incarnation there is some processing done on the 68020
for packets that are routed. (Note the distinction
between protocols that the Hybridge handles as a router
and those that it handles as a bridge.) How much can be done
by the MCI for protocols that are routed depends upon the
protocol and the route. In the release of the software
that I've seen, the very high-speed router performance happens
only for IP, and only when going between interfaces on the
same MCI card. However long term plans are to add fast-switch
support for other protocols and for switching between interfaces
on different MCI cards. I'm not the right one to announce
future cisco products, but we expect to see DECnet and
inter-MCI fast switching very soon.
Testing the performance of such a thing is harder than it sounds. How
many of you have things that can generate or monitor 12Kpps? We
actually do (we have the same equipment cisco uses: a pair of HP
Lanalyzers), but I'm more interested in trying something with real
traffic. I've made some preliminary attempts, but don't have anything
to report yet.
I agree that this approach helps defuse the router/bridge controversy.
It may not completely end it, though.
- the technology for high performance bridges and routers is
essentially identical. That's why the Hybridge is possible.
However if you don't need 12Kpps (and practically speaking,
you probably don't), you may still find less expensive
bridges and routers whose technology isn't the same.
- Administrators still have to decide how to configure them.
This should be done on network architectural grounds,
just as the decision always was done. Of course it's
now easier to change your mind, and mixed strategies are
available that weren't before.
I didn't mention the Hybridge in my reply to the guy at the FRB for
two reasons:
- Although my preference for routers over bridges is well known,
my guess was that simply replacing his bridges with routers,
brouters, or anything else, would probably not help him
with his traffic problem, unless he's having problems with
excessive broadcasts. It might be better for general
architectural reasons, of course.
- If I were doing a network for a Federal Reserve Bank, I probably
would wait until these products had been out for a few months
before buying one. Personally, I'm trying to get up enough
money to get a bunch of MCI cards for Rutgers. But then if my
gateway hangs because of some crazy thing our network does
that cisco has never seen before, I don't have half the banks
in the U.S. go bankrupt. This is not specific advice based on
experience with the MCI (my policy is not to comment on the
reliability of beta test systems), but on general experience
in the industry.
jqj@uoregon.uoregon.edu (JQ Johnson) (10/08/88)
Kent England argues that the cisco HyBridge is the appropriate model for defining a "brouter" i.e. a hybrid bridge-router. Though I agree that the HyBridge is a very nice product (I have one on order), I'm not sure you should call it a "brouter". RAD and others have been using the "brouter" term for some time now for a different beast -- a bridge that does some intelligent routing using only MAC-layer addresses. By comparison, the HyBridge does routing using network-layer addresses. The RAD product's intelligence is, as I recall, limited to traditional packet filtering, creation and regeneration of a spanning tree, and load sharing among multiple MAC-layer paths. One could imagine a very intelligent bridge that did still more; given a protocol that exchanged caches among bridges you could imagine doing true routing using only MAC-layer addresses! By the way, one major problem with the HyBridge model is figuring out how to incorporate such a partial bridge into a spanning tree of bridges. Seems to me the presence of a HyBridge would imply that the spanning tree algorithm would have to be extended to communicate the routing vs. bridging rules so everybody could agree. It would be disasterous to have a routing HyBridge in parallel with an active DEC LANBridge! I'm not convinced that HyBridge works in complex bridged topologies.
hedrick@aramis.rutgers.edu (Charles Hedrick) (10/10/88)
You said that you don't think the cisco HyBridge is a brouter. I
don't know any of the products that you consider brouters, so I'm not
in a wonderful position to make comparisons. But the HyBridge does
routing in two different ways. For some protocols it acts just like
any other router. For others it acts just like any bridge. As far as
I know, there is no interaction between the two types of routing. You
can apparently select which protocols are handled which way. When it
is acting as a bridge, the HyBridge is compatible with either the
proposed IEEE standard spanning tree protocol or the DEC LANbridge.
(You get to choose. In theory they could support both protocols, so
that a HyBridge could connect sets of bridges that use different
protocols, but I don't know whether they've gone that far.) You
should be able to put the HyBridge in the middle of a set of
LANbridges and the routing will all still work. However LANbridges
have network monitoring and control facilities in addition to the
spanning tree algorithms. I have a feeling that the HyBridge does not
implement that, so they aren't completely interchangable with
LANbridges.
There is a protential problem with having a HyBridge in parallel
with a LANbridge, but it's exactly the same as having any router
in parallel with a bridge. Consider the following configuration:
----------------- network 1
| |
HyBridge LANbridge
| |
----------------- network 2
It would work fine if the HyBridge is set up to bridge all protocols.
But if the HyBridge is handling IP as a router, then you're got a
router and a bridge in parallel. Things can get very exciting indeed.
Suppose a host on net 2 sends something to a host on net 1 via the
router. The first time the router gets such a packet, it will issue
an ARP request for the host on net 1. Unfortunately, the bridge will
forward the ARP request to net 2. There will be two responses, one
directly from the host on net 1, and the other from the net 2 side of
the router, which thinks that a host on net 2 is trying to use proxy
ARP. The response from the back end of the router will probably
arrive second, since it has a more complex path. Thus it will
probably be believed, and we'll end up with a circular path. However
this configuration will probably work if you disable proxy ARP on
the router. Note that this problem has nothing to do with the
HyBridge in particular. It will happen any time you have a bridge
in parallel with a router that does proxy ARP.kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (10/10/88)
In article <2944@uoregon.uoregon.edu> jqj@drizzle.UUCP (JQ Johnson) writes: > Though I agree >that the HyBridge is a very nice product (I have one on order), I'm not >sure you should call it a "brouter". RAD and others have been using >the "brouter" term for some time now for a different beast -- > [...] >The RAD product's intelligence is, as I recall, limited to traditional >packet filtering, creation and regeneration of a spanning tree, and >load sharing among multiple MAC-layer paths. The load sharing aspect is the only thing beyond the definition of a IEEE-compliant bridge in the RAD product, so I'm not convinced they deserve the exclusive right to define the generic term "brouter". But one of the things I want to resolve with this audience is what we mean by "brouter". I think brouter means "a box that combines the functionality of a router and a bridge". It also implies that the bridge functionality might be expanded or enhanced by the routing capabilities of this box. It may be a little premature for me to be testing these waters, but I am curious about the direction of the technology and what I will be able to do with a generic "brouter". I am particularly interested in how a vendor like cisco will make multiport brouters work. Will they simply fit them into the IEEE spanning tree model or will we (should we) be able to make them a little smarter, ala the RAD approach for load sharing. I, for one, want to be able to limit the subnets (physical nets) that participate in the bridge protocol. For example, I want to be able to configure bridging of a set of Ethernet types between a limited subset of Ethernets among my twenty or so total. I would not be happy with a brouter that simply has an ON/OFF switch for bridging. I want to be able to apply some limited a priori routing intelligence to the bridging function and I would like to find ways to limit the broadcast scaling problem, if possible, by using the intelligence in a brouter. I want to explore the possibilities opened up by this new breed of hardware/software. Perhaps I should just wait until I get my Hybridge and read the manual and see how far cisco has gotten with this.
jqj@uoregon.uoregon.edu (JQ Johnson) (10/14/88)
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.