brouter - bridging non routable (layer 3?!) addresses - terminology question

It's actually a term I haven't heard used much lately, but years ago it seemed another one of those buz words people used when they wanted to pretend they had something unique to sell.

If you search around, you will find the simpilistic definition we've seen in the thread, such as here:

formatting link
But then if you try to make sense of that, you quickly discover the definition hardly begins explain what the box must be capable of doing. So you think it through, and look some more. Aha. Here's one that seems much more instructive:

formatting link
Bert

Reply to
Albert Manfredi
Loading thread data ...

but surely whether a packet is routed or bridged depends solely on whether it's for a local comp or a remote comp. If you want to distinguish this based on the particular layer 3 protocol, then you'd have to set absurd restrictions. For example These comps use this layer 3 protocol, so can only send remotely. These comps use that layer 3 protocol, so can only send locally. Or If a comp wants to send locally, they must use this layer 3 protocol And If a comp wants to send remotely, they must use that layer 3 protocol

Furthermore, the logic for the brouter to test if the packet is local or remote is minimal. It'd be something like testing if the Dest MAC matches the MAC for that subnet's router interface(1 test, and Layer

2). That's one MAC it should recognise! the Brouter need only test the Dest MAC against that one. So no reason why testing the Type of the packet(agaisnt a few values) would be an aid, and it does appear very restrictive. Infact, regarding MAC logic, the brouter already implements a lot of it for the bridging, storing all the MACs anyway.
Reply to
q_q_anonymous

All packets meant for the local subnet, in any layer 3 protocol, would be bridged rather than routed. I think Glen is saying that if a brouter knows the layer 3 protocol, any layer 3 protocol, not just IP, packets can either be routed or bridged depending whether the destination is local or remote.

But my point is that a brouter that does not know a particular layer 3 protocol, or a brouter which receives a frame with no layer 3 protocol header of any kind, it's not wise for that brouter to forward this frame beyond the boundaries of the layer 3 protocols it does have knowledge about. It's not a good idea.

A frame addressed to the MAC address of a brouter is not necessarily to be routed. It could be something meant for local consumption by that box. Maybe SNMP, maybe IGMP, maybe ICMP.

Bert

Reply to
Albert Manfredi

(snip)

Some IP routers will also route Appletalk, though some may configure to bridge it, anyway.

Well, that is mostly the job of the person installing it. A LAN router (between two LANs inside an organization) is likely to route such protocols. A WAN router (between the organization and the rest of the world, or specific ports on a larger router) would not. Most ISP probably won't route Appletalk (it doesn't scale so well).

Any nonroutable protocol would be ignored by the ISP router, anyway.

-- glen

Reply to
glen herrmannsfeldt

An IP router will never route AppleTalk. That said, a physical device that incorporates an IP routing function may also incorporate an AppleTalk routing function, but it is the AppleTalk router routing AppleTalk, and the IP router routing IP. What (I think) you meant to say was, "Some devices purchased for their IP routing function can also route AppleTalk, though the administrator may configure the device to bridge AppleTalk instead."

I know that *you* understand this, but the lurkers should learn that a "router" is a *function*, not a device.

Reply to
Rich Seifert

A logical device with a physical implementation. Then again, with the discussion of layer 3 switching and routing in hardware... (where this thread started).

Well, the line between hardware and software has been blurry for a long time, which is where firmware, hard but not too hard, came from.

With programmable logic, it is even less obvious.

There used to be a company called VCC, Virtual Computer Company, which built FPGA based computer hardware with the motto "The software is the Computer", similar to Sun's "The Network is the Computer".

Can big CISCO routers be configure to bridge IP and route Appletalk?

-- glen

Reply to
glen herrmannsfeldt

surely that's a routing issue. not specific to 'brouters'. Any router if faced with an unknown layer 3, cannot route it

So the only thing about brouters seems to be that they bridge or route. 'cos they've got a "switch"(yep, I know, 'Bridge') at each interface.

strange, the whole "bridging non routable and routing routables" seems to be not really specifically a brouter thing. Any router wouldn't route if it doesn't know the layer 3. And would bridge if it's local.

hadn't thought of that

thanks

Reply to
q_q_anonymous

I didn't say anything about hardware vs. software implementations. A router (or anything else) can be built using either, or a combination. In fact, *any* (well, *almost* any) function can be implemented in hardware or software. The tradeoff is higher performance and higher cost (hardware) vs. flexibility and time-to-market (software), among others. Regardless of whether a router is built in one or the other, it is a logical function instantiated in a physical implementation.

[You know you are a network architect when you use words like "instantiation." ;^) ]

For some, the distinction between a routing function implemented in software on a general-purpose CPU and one where the fast-path of the code is implemented in a hardware, finite-state machine, is the distinction between a "router" and a "Layer 3 switch." To me, the line between hardware and software must be chosen on a product-by-product basis, determined by the functions required to be implemented, the performance demanded by the application environment, and the acceptable cost in the target market. I leave the data-sheet naming to the marketing folks.

Reply to
Rich Seifert

(snip)

Yes. Still, with a hardware implementation it is harder to separate the physical and logical functions. A software router isn't a router if you remove the ROM, but for a hardware implementation?

Then again, are microcoded processors hardware or software?

Thanks for reminding me of the difference.

-- glen

Reply to
glen herrmannsfeldt

Granted, the implementation boundaries (e.g., the chip pins) are different from the logical boundaries (e.g., IP routing table lookup function), but that's irrelevant once you have designed the product. It's not like you're going to change the algorithm in the field. That's one of the downsides of hardware implementations; it's harder to make changes.

Software, clearly (to me), although the distinction blurs a bit for a micro-engine with a writeable control store (e.g., the VAX). The original VAX had an internal micro-engine; normally, the microcode that shipped with the unit was the code that produced what was known as the VAX Instruction Set. However, we allowed certain customers (read: those with a lot of money, who wanted a lot of machines to perform some specialized function) to write their own microcode, at least for part of the microstore. That is, they could *create their own hardware instructions* in addition to those in the VAX Instruction Set. I remember Schlumberger (the oil exploration company) implemented some real-time FFT algorithms in microcode for an application that was monitoring a sensor being dropped down into a test well. The code had to do the FFT in real-time, because the sensor was destroyed by heat once it got to a certain depth (this is how it was *supposed* to work). They had to do some part of the analysis in real-time, while the sensor was being dropped, and conventional software wasn't fast enough.

In one version of the VAX (IIRC, the VAX 11/60), there were *two* control stores--one that had the standard instruction set, and a second one that was loaded from an internal 8" (!) floppy disk. That is, the machine had two complete "instruction sets," ready to go. With a single bit-change in a control register, the entire instruction set of the machine would change, and this could be done on an

*instruction-by-instruction basis*! I recall that, for some demo, someone implemented an IBM System/370 instruction set in VAX microcode and loaded it into the second control store. The machine could now execute VAX native code and IBM native code side-by-side. We loaded both VMS and OS/370 (or whatever it was called back then), and had a bank of ASCII and 3270 terminals connected to it. Each set of users thought they were running on "their" machine (i.e., a VAX or an IBM 370). In reality, the VAX was running both, and context-switching between micro-instruction sets. The idea is the same as a machine emulator, but it's much faster because the emulation is in microcode rather than application software.

Also, with a "programmable logic device" such as an FPGA, the hardware/software distinction is also blurry. When it's running, it's hardware, e.g. a finite-state machine. It's just that the configuration of the state machine can be modified under software control, so it has some of the advantages and disadvantages of both.

Reply to
Rich Seifert

i look at it the other way.

when you have a multiprotocol router you choose which protocols to route that you "turn on" routing - everything else is a candidate for bridging.

then you tweak the config by selecting routing per protocol and bridging on each interface

if you have a flexible device you might be able to both bridge and route the same protocol on different portions of the same box - this is common for IP on LAN switches that also route IP, since you might want several ports in the same subnet.

you can bridge IP between some ports and route it to others, in various combinations. Yoou can dice a box into multiple logical routers, each with their own routing table (multi VRF, came from MPLS)

cisco IOS has been able to route appletalk for a long time but it isnt so common any more.

There were also various appletalk / IP tunnel and route / translate across intermediate IP backbone protocols that were popular for a while.....

Reply to
stephen

a packet with a protocol to which you turned on routing may also be a candidate for bridging e.g. when it's going to be bridged 'cos it's going to a comp on the same subnetwork. But I'm sure you knew that, so why do people keep talking like that if they mean something else?!!!

By the way. Rich's point about an IP Router and an Appletalk router, was linguistic and clear. Anybody that disgrees with it hasn't comprehended the simplicity of what he was saying.

Reply to
q_q_anonymous

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.