DIFFERENCE BETWEEN BRIDGING/SWITCHING AND ROUTING....

 There is a fundamental question: “how is bridging different from routing?”. It’s impossible to give a concise answer .
ROUTING-: Routing or routeing is the process of selecting paths in a network along which to send network traffic.
BRIDGING-: Bridging is a forwarding technique used in packet-switched computer networks. Unlike routing, bridging makes no assumptions about where in a network a particular address is located. Instead, it depends on flooding and examination of source addresses in received packet headers to locate unknown devices. Once a device has been located, its location is recorded in a table where the MAC address is stored so as to preclude the need for further broadcasting. The utility of bridging is limited by its dependence on flooding, and is thus only used in local area networks.


                             NOW THE DIFFERENCES BETWEEN THESE TWO--

Design scope. IP was designed to support global packet switching network infrastructure. Ethernet bridging was designed to emulate a single shared cable. Various design decisions made in IP or Ethernet bridging were always skewed by these perspectives: scalability versus transparency.

Forwarding. IP routers forward
IP datagrams according to their IP routing tables and never make multiple copies of the same datagram. They drop datagrams sent to unknown destinations and tell the sending hosts they did so. Bridges have to emulate a shared cable and thus forward frames sent to unknown destinations to all active ports but the one on which the frame was received (flooding). In short, routing is “forwarding based on presumption of knowledge”, bridging is “forwarding by guessing”.

Loop detection. IP (and most other layer-3 protocols) has a hop count in its header. Ethernet header does not have a hop count (neither do most other layer-2 protocols). Using hop count, loops can be detected even when they cannot be prevented (uRPF does a decent job of loop prevention in non-asymmetric networks, but that’s a different story).

Even worse, the forwarding by guessing bridging paradigm can create multiple copies of a looped packet sent to unknown destination. The number of copies grows exponentially with each iteration of the loop, quickly resulting in a total network meltdown.

Multicast. Routers stop multicast or broadcast packets unless they are configured to forward them. Decent multicast implementations allow hosts to register to multicast streams and the routers deliver multicast packets only to those hosts or segments that actually need them.

Transparent bridges have to emulate a shared cable where every station can receive a broadcast or multicast frame. They are thus bound to flood multicast/broadcast frames.

Some layer-2 bridges support IGMP snooping and other mechanisms that should limit the amount of IP multicast propagated in unwanted directions. These measures work only for known (IP) multicast addresses; bridges still have to flood frames sent to unknown multicast destinations.

Most bridges can rate-limit the flooding process, reducing the chances of a single runaway host bringing the whole network to a standstill. Nonetheless, a determined intruder can use the rate-limiting mechanisms for an effective DoS attack where the bogus multicast traffic interferes with crucial protocols like ARP.

Forwarding tables. IP routing tables are built by routers exchanging (somewhat) authoritative information: their connected subnets and their static routes. Bridging tables are built by guessing – by listening to the traffic and extracting source MAC addresses from the frames. The guessed information is never exchanged between the bridges (ESADI in TRILL is an exception, but even ESADI information is not authoritative).

Addressing. Layer-3 addresses are configurable and usually include some topology information, allowing the layer-3 routing to scale. Layer-2 addresses are supposed to be static (hardwired) and are (within a single network) randomly scattered around the network.

Scalability. All layer-3 protocols have some mechanism that aggregates forwarding information, allowing them to scale. The “desktop protocols” (Cisco’s invention, not mine), including AppleTalk, IPX and Banyan Vines performed routing based on networks(cable ranges in Appletalk), which were very similar to fixed-prefix IP subnets. DECnet, CLNS and SNA have areas and perform host-based routing within an area, but still use only area addresses in “long-distance” (inter-area) routing to scale. Classless routing with IP prefixes allows you to build a multi-layer hierarchy.

Transparent bridging forwards frames to randomly scattered layer-2 addresses and thus cannot have a scaling mechanism.

Novel approaches to bridging (TRILL and 802.1ad) introduce a bridging hierarchy (or a bridging/routing hierarchy in case of TRILL), in which inner bridges (provider bridges in 802.1ad) know just the MAC address of edge bridges. VLANs deployed on edge bridges further limit the amount of information a single edge bridge must carry. Still, a single bridged domain cannot scale.

Spoofing. The “forwarding by learning” paradigm makes it extremely easy to spoof a bridged network: send frames with wrong source MAC address. Spoofing a routed network is somewhat harder; you have to hack the routing protocol.

Bridges reduce the risk of spoofing by implementing port security, dynamic ARP inspection and DHCP snooping; workaround measures trying to solve a problem that shouldn’t have existed in the first place. You cannot secure an environment designed to emulate a single shared cable (at least not without breaking some eggs).

Fragmentation. IP was designed to span a multitude of physical media with different characteristics and supports datagram fragmentation and path MTU discovery. Bridging was designed to connect segments with uniform technology, which was fine as long as the maximum Ethernet MTU was constant. Introduction of jumbo frames has created a “somewhat more complex” environment, where bridging between Ethernet segments can fail spectacularly.

Out-of-order packets. Out-of-order packets are a fact of life in any multipath topology (including any layer-3 network). Layer-3 protocols were thus designed to deal with them, either rearranging them (TCP) or dropping them (most UDP applications).

Protocols that pretend the hosts communicate on a shared cable tend to ignore the out-of-order problems; some protocols might even terminate the session when receiving one. SNA was one of those protocols, forcing Cisco to implement FST, which dropped any out-of-order packets. The requirement to deliver packets in order significantly complicates any advanced bridging implementation (for example, TRILL).

Mixed media. IP can (by definition) be used on all data link layer technologies. You can mix-and-match various technologies as needed: Ethernet for access LAN, Gigabit Ethernet with large MTU for data center, HDLC, PPP, Frame Relay or ATM for WAN links. Datagram transport across all the media is always (close to) optimal.

Bridging forces you to use a single layer-2 technology (for example, Ethernet) everywhere and emulate the chosen layer-2 technology across all other media. This requirement leads to baroque architecture used in DSL networks and emulation jumbles like LANE or VPLS.

Cost. Layer-2 switches are almost always cheaper than layer-3 (usually combined layer-2/3) switches. There are numerous reasons for the cost difference, including:

• Mass-market low-end switches are usually simple bridges. Low-cost high-speed bridging silicon is thus readily available.
• MAC address lookup is simpler than IP table lookup and easier to implement in silicon. You need simple CAM (Content Addressable Memory) to perform MAC address lookup and TCAM (Ternary CAM) with additional output logic to perform longest-IP-prefix matching.
• Layer-3 switches are expected to perform IP packet filtering. Implementing access lists in hardware (usually with even larger TCAM) is expensive.

Zero configuration. In their simplest incarnation, the bridges are plug-and-play devices (magically transforming themselves into plug-and-pray devices as the network grows); it’s quite easy to find a perfectly working switch named Switch with no non-default configuration in a badly managed network. Routers always require configuration (at the very minimum, you have to configure IP subnets and IP routing protocols).

However, as soon as VLANs are introduced into the network or you need to fine-tune STP, the zero-configuration benefits are gone.

Equal-cost multipath. Routers can load-balance traffic between equal-cost paths across the network. Bridges can load-balance traffic between parallel bonded links (port channel). Redundant paths in bridged networks are disabled to prevent forwarding loops.

Enhancements to port channel technology (VSS and vPC) allow links connected to multiple switches to be bonded. TRILL (and similar technologies) solves the problem, allowing unrestricted equal-cost multipath.

Security. Packet filters between IP subnets are a standard feature of every decent router, allowing the network designer to segment the network into security zones.

Some layer-2 switches have similar functionality (port ACL), which turns a L2 switch into a layer-3-aware L2 device, increasing configuration and troubleshooting complexity.

Predictability. L3 forwarding tables are modified only by the control plane (routing) protocols based on messages exchanged by the routers, not by the data traffic flow. L2 forwarding tables are modified on-the-fly by the data plane snooping functionality based on source MAC addresses in the frames forwarded by the switch.

Troubleshooting. It’s impossible to troubleshoot a bridged network from an end-host; the network is designed to be invisible. The error reporting mechanisms built into most L3 protocols allow an end-host to trace a path across the network, giving the network operator at least an initial snapshot of the network conditions and a troubleshooting starting point.

End-host mobility. The source MAC address snooping (which makes the bridged networks less predictable) allows instant host mobility – as soon as the host is attached to another network segment and sends a broadcast (a gratuitous ARP is a perfect candidate), all bridges readjust their L2 forwarding tables.

You can implement seamless host mobility in a routed network, but the delay is much higher, as the dissemination of changed information is done by the routing protocol.

Impact of link failure. Link failure in a routed network results in temporary loss of traffic forwarded over that link (until routing protocol convergence). Link failure in a bridged network running STP can impact unrelated parts of the network.

TRILL uses a routing protocol (IS-IS); a network built with TRILL RBridges behaves like a routed network.

Impact of physical errors. Most layer-3 routing protocols detect unidirectional links and wiring errors (which usually result in subnet mismatch errors). The same conditions can easily result in a forwarding loop in a bridged network, unless you use UDLD and bridge assurance.

TRILL and other similar technologies no longer have this problem, as they use a routing protocol inside the network.

Impact of network overload. When a L2 switch is overloaded to the point where it stops sending STP packets (for example, due to data plane overload impacting control plane functionality), remote switches might unblock their ports, resulting in a forwarding loop and a total network meltdown.

When a router stops sending routing protocol hello packets, other routers detect a dead neighbor and recomputed the network topology (not necessarily resulting in a working network, but at least they’re not aggravating the problem).

Bridge assurance solves this issue, as does TRILL.

Size of fault domain. Whole bridged network is a single fault domain (a fault anywhere in the network can impact the rest of it). A fault domain in a routed network is a single subnet.

The fault domain issue is usually related to the behavior of STP, but extends to the forwarding plane as well. A single misbehaving host attached to a bridged network can affect the whole network.