Resources Archived Articles Integrated Routing and Bridging
| Integrated Routing and Bridging |
| Saturday, 01 February 1997 21:09 |
IntroductionThe last couple of articles I've enthused over various new features in 11.2. There's another new feature in 11.2 that might be very useful, particularly if you have to migrate from bridging a protocol to routing it. Integrated Routing and Bridging (IRB) allows us to both route and bridge a protocol in the same router, with connectivity between all the interfaces. (Concurrent Routing and Bridging in 11.0 allowed both routing and bridging in the same router, "but never the twain could meet".) IRB also allows multiple router interfaces to be in a common VLAN, with routing between such VLAN's. With routers acting somewhat like switches, it seems like we might expect switches to start acting more like routers. But that's a whole different subject, Cisco futures. IRB currently supports IP, IPX, and AppleTalk, in both fast switching and process switching modes. Legacy BridgingBy "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 costConfiguration of bridging was (and remains) simple: bridge 1 protocol ieee interface Ethernet 0 bridge-group 1 interface Ethernet 1 bridge-group 1Think 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 crbWhen 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 ipThis 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 configurebridging irbWe 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.0That 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 ipWe 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 ipIt 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. CautionPlan 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 CommandsThere are the usual show commands for monitoring bridging. Among them:show bridge show span show bridge groupIf 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 irbThere are also debug commands, which we won't go into. Limitations
Other NotesThere's a Cisco guide titled Designing Networks with Windows Networking , by Rohan Mahy. Search doesn't find it on the CCO Web page, but it's on the CD SE's get. If you're doing large scale Windows 95 or Windows NT, you may want to take a look at this document. (I think I'm hearing that some organizations are seeing increasing morning broadcast storms, as various groups bring in new PC's, all running Windows 95 and set up to browse. The document discusses some things you can do to help yourself.)Netsys Connectivity Tools 3.0 is out. They've now got much of BGP into the model. The Connectivity Tool also now models AppleTalk, DECnet, and Vines connectivity (but not their routing tables, yet). There's an optional module that imports Bay Networks router configurations, for mixed-vendor networks. There's a whole bunch of automated reports with a Scheduler tool. And there's Web reporting and topology browsing capability (a limited subset of the functionality). All-in-all, a nice set of additions. If this sounds interesting, see www.netsystech.com (or www.cisco.com, since Cisco completed its purchase of Netsys).
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/about-us/bios/staff-articles-and-blogs/pete-welcher.html . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This e-mail address is being protected from spambots. You need JavaScript enabled to view it . 02/97 |
