A common misconception among network administrators is that you should determine the routing protocol you're going to use based on the size of your network. This logic starts with static routing for the smallest networks, followed by Interior Gateway Protocols (IGPs) like OSPF, IS-IS and EIGRP in mid-sized networks and finally an Exterior Gateway Protocol (EGP) like BGP for really big networks. That's a method, but not a particularly good one.
A quick glance will show you that the classifications of routing protocols aren't based on size like "small, medium and large" but rather based on function; exterior and interior, or distance-vector and link-state. This is for good reason. First, OSPF and IS-IS scale very well. Even EIGRP runs some very large corporate backbones, like Cisco's own sizable, internal network. Next, realize that most carriers and ISPs use IS-IS or OSPF on their backbones, and BGP on the edges. Why? Because that's what they were designed to do.
It's a mistake to say, BGP is overkill for a moderately sized network, because it's not really a question of size. It is a question of function. The value of BGP is that everything about it is built around the concept of separating domains of control, appropriately named "Autonomous Systems", so that each can have the policies that suit them without conflicting with each other. Thus, features have evolved around BGP that offer a level of control that cannot be matched by IGPs.
Conversely, the strength of IGPs is rapid, intelligent convergence. These protocols are good at dynamically learning information about the network topology and sharing it with their neighbors with minimal manual configuration.
You should strongly consider using BGP at the edges of your network, not just for internet connections, but for your connections to partners and suppliers, etc. And just like the "Core" layer of the "Core/Distribution/Access" model is designed for high-speed transport, move the intelligence to the edges and let your backbone routing protocol be high-speed, no-frills. Start with this philosophy and the technical components in your design will fall neatly into place, instead of having to force a square protocol into a round network and giving yourself a support headache.
Running multiple protocols in a network does mean a few more design decisions. In the next tip, I'll discuss in more detail how your protocols interact with each other.
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex.
