Routing & Bridging in Cisco Routers

Legacy Bridging
By ‘legacy’ I mean bridging prior to IOS 11.0. The algorithm used was simple: when a packet arrives, check if its protocol is being routed. If so, route the packet (if possible). If not, bridge the packet. If the protocol isn’t enabled on an interface, then drop the packet.
There’s something more required to route the packet. The IP address command, IPX network number command, etc. all serve to ‘turn on’ routing of a protocol on an interface. Without this key command for a routable protocol, the router used to ignore packets from that protocol arriving on the interface, if routing of that protocol is turned on.

This had a nice side-effect, commonly used (or abused). Suppose you wanted to turn on bridging but make sure you weren’t bridging, say, AppleTalk. All you had to do was turn on routing of AppleTalk, but put no cable-range commands on bridged interfaces. This was called ‘filtering by routing’. The alternative was to build a type-code access list and apply it to interfaces, which is probably a cleaner solution (except for doing hexadecimal).

Let’s call those key commands which enable various routing protocols on interfaces ‘protocol enablers’. Here they are:

ip address address subnet-mask
ipx network hex-number
appletalk cable-range cable-range
vines metric optional-metric
decnet cost cost

Configuration of bridging was (and remains) simple:

bridge 1 protocol ieee
interface Ethernet 0
bridge-group 1
interface Ethernet 1
bridge-group 1

Think of the ‘bridge…protocol’ command as creating an external bridge, henceforth to be referred to within that one router as bridge #1. And then the two Ethernet interfaces are ‘plugged into’ the bridge with the ‘bridge-group’ commands. External emphasizes that the bridging operates separately from the rest of the router. The only way to get packets from a routed interface to one of the bridged interfaces is by external cabling.

Concurrent Routing and Bridging (CRB)
Configure as above and you still get the same behavior.
To get CRB, add the command

bridging crb

When we configure this, the router adds another command for us, for any protocol that is being routed on bridge-group interfaces. For example,

bridge 1 route ip

This command says that when an IP address is present on an interface, even one with a bridge-group command, then IP traffic should be routed from and to that interface. Note that when you are routing IP on interfaces with IP addresses, then the IP connectivity may differ from other protocols. Only the bridge-group interfaces without IP addresses do bridging, so for IP purposes they’re the only ones ‘connected to the external bridge’. Similarly for other protocols.

If we omit or take out the ‘bridge 1 route ip‘, then we get pure bridging behavior for IP.

Integrated Routing and Bridging (IRB)

To activate IRB in the router, we configure

bridging irb

We also have to do something else. Recall that we’re thinking of the bridge-group commands as connecting interfaces to an external bridge. If that’s all we want, fine. But if we want the bridge connected to the router, we need to ‘connect it to a router interface’.
No, not physically. Instead, we configure

interface bvi 1
ip address 1.1.1.1 255.0.0.0

That is, we create a Bridge Virtual Interface (BVI). Since the bridged segment is logically one segment, one VLAN, we put the routable protocol information on the BVI, and it applies to all interfaces in the bridge group. By treating the BVI as we would any other interface, we can now route between the bridge group and the routed interfaces in the router.

The other relevant commands we might use are:

bridge 1 route ip
no bridge 1 bridge ip

We use the first of these (substituting the name of the protocol for ‘ip’), to route a protocol when the appropriate ‘protocol enabler’ is present on an interface. The second of these is normally on by default, which is why I show the ‘no’ form of the command. That’s used if we wish to not bridge a certain protocol, even if it can’t be routed on an interface.

Here’s an example. We turn on IRB, and bridge AppleTalk. IP is routed only (note there are IP addresses on all the physical interfaces, as if the bridge-group statements weren’t there). And IPX is both bridged and routed. That is, it is bridged on Ethernets 2 and 3, and routed between this logical segment and Ethernet 1. Note the IPX network numbers are applied to BVI 1, and not to Ethernets 2 and 3.

ipx routing
!
interface Ethernet 1
ip address 1.0.0.1 255.0.0.0
ipx network A001
!
interface Ethernet 2
ip address 2.0.0.1 255.0.0.0
bridge-group 1
!
interface Ethernet 3
ip address 3.0.0.1 255.0.0.0
bridge-group 1
!
interface BVI 1
no ip address
ipx network AAAA
!
bridge irb
bridge 1 protocol ieee
bridge 1 route ipx
bridge 1 route ip
no bridge 1 bridge ip

It is wisest to be consistent with this. Don’t put protocol enablers on bridge-group interfaces unless you’re only routing that protocol. And don’t put a bridge-group on a BVI.

Caution
Plan ahead, and watch out for encapsulations when using BVI with mixed media. The defaults are the usual Ethernet encapsulations. Thus Novell traffic routed to the BVI to be put out the bridge group interfaces might appear as novell_ether encapsulation, sometimes referred to as ‘raw Ethernet’. Think of this as what crosses the connection to the ‘external bridge’. If there is a Token Ring or FDDI interface in the bridge-group, the packet must receive media-translation prior to being transmitted out that interface. Translation alters the encapsulation to ‘raw-Token’ or ‘raw-FDDI’, which may not be what we want. One workaround might be to specify SNAP encapsulation for the BVI. But then we do get SNAP out any Ethernet interfaces.

Other Commands
There are the usual show commands for monitoring bridging. Among them:

show bridge
show span
show bridge group

If you’re finding the question of ‘is it routing or bridging this protocol on this interface’ a tough one to sort out, try:

show interfaces crb
show interfaces irb
show interfaces interface irb

There are also debug commands, which we won’t go into.

Limitations
IRB is not supported on the AGS+ and 7000;
IRB supports transparent bridging only, not source route bridging;
IRB is supported on all media-types except X.25 and ISDN bridged interfaces;
IRB and Concurrent Routing and Bridging (CRB) cannot both operate at the same time.

~ by Safar Safarov on March 1, 2010.