In the beginnig, the network bridge (Bridge) was invented to join two or more networks as one.
We'd usually use the word "network segments". Some technologies have limits on delay (eg: coax ethernet) and others have limitations on length (eg: token ring) and the physical signal regeneration from bridging allows some of those limits to start over.
Then Cisco invented the Router, and the Bridge dropped in popularity because Routers are easier to implement and manage.
And because bridges and routers of that era were essentially the same technology, and thus near the same price. So you'd select a router because a routed network is more robust to errors (eg, faulty NIC cards).
Then with many Routers on the network performance dropped due to latency caused by routing and many network engineers realised that they needed
> the bridge to minimize latency. I'd have to disagree there. The two-port bridge never really made a come-back, whereas two-port routers are still useful. Rather the next change was driven by the desire to have a single cabling plant -- unshielded twisted pair -- and the deployment of repeater hubs. Over time as switch ASIC priced dropped those repeater hubs became switching hubs (a switch of course being nothing more than a bridge implemented in ASIC).
Bridges work on layer-two whilst routers work on layer-three. In this view, it is deemed to be less risky
It not the risk but the cost and configuration effort. Ten ports of GbE switch are about $500. 10 ports of GbE router are about $10,000. Switches at a site pretty much all have an identical configuration. Routers are configuration intensive. Also there's the question of multi-protocol support. If you've got a stack of ancient protocols to run then switching (which is L3 protocol-independent) is attractive. When you need to route the usual solution is to run VLANs up to a Linux box or other fine multiprotocol router. The move to transparent layer two firewalls isn't really a switching/routing decision so much as firewall vendors trying to offer a device with a low attack profile (eg, no IP address in the forwarding path) and which is configuration free (as least as far as the networking, not the security policy). Unfortunately, that falls apart when you want the firewall to understand the network topology (such as participate in selection of a fallback route).
and came up with the term transparent bridging.
Transparent bridging is an old notion -- all ethernet bridges are transparent. The concept of 'transparency' is that the neither the transmitting or recieving host need make special arrangements for the bridging to succeed. You can compare this with AX.25 bridging, where each transmitted frame contains a list of bridge addresses for the packet to follow. A transparent firewall is where the insertion of the firewall doesn't alter the IP forwarding path. By not appearing as an IP entity it is difficult to launch a DoS attack against the firewall (not really true, but that's the notion).
There are other ideas around bridges
Probably the major warning is that interfaces of the same bridge should not be connected to the same network segment. This causes a broadcast flood. There is a protocol, IEEE 802.1D "Spanning tree", to prevent these loops. But spanning tree is an insecure protocol, and prone to users doing nasty stuff. A lot of switch ports offer a "port security" feature which downs the port upon seeing two MAC addresses. So you configure host-facing ports with "port security" and bridge-facing ports with "spanning tree". -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html