7.3 Route Redistribution
7.3.2 Redistribution overview (con't)
Because using multiple routing protocols typically results in increased administrative complexity and overhead, you may wonder why it is done in the first place. Actually, there are several scenarios in which using multiple routing protocols solves more problems than it creates especially in medium and large-sized networks.

Consider a large, mixed-vendor routing environment in which Cisco routers work alongside other routers. An administrator may create an "all-Cisco" domain, where the advantages of proprietary protocols such as IGRP and EIGRP can be enjoyed. Meanwhile, other areas of the network run a nonproprietary protocol, such as OSPF or RIP, as shown in Figure .

Multiple routing protocols may also be effectively deployed to support legacy UNIX systems that support RIP only. These systems may represent a significant financial investment and may not be readily upgradeable. As shown in Figure , an administrator may elect to run RIP on subnets populated by the UNIX systems but might use a more scalable protocol elsewhere. Also, running multiple routing protocols can be seen as a temporary fix during a prolonged upgrade from older protocols and hardware to newer, more scalable solutions.

On some occasions redistribution is done even when running compatible routing platforms (for example, all Cisco routers running EIGRP). If an organization is exchanging routing information with a domain outside its administrative control, it may choose to configure route redistribution as a means of logically separating the different routing processes, which may have different policies.

Cisco routers support up to 30 dynamic routing processes. This means that a router can run RIP, OSPF, IGRP, IS-IS, EIGRP, IPX RIP, RTMP (AppleTalk), and other protocols simultaneously. Most of these routing protocols allow you to configure multiple processes of the same routing algorithm; RIP is a notable exception. For example, you can define multiple IGRP processes by using different AS numbers, or different OSPF processes by using different process ID numbers, as shown in Figure .

Note that in configuration shown in Figure , RTA's OSPF processes (24 and 46) will not share routing information unless route redistribution is configured. Because each routing process places substantial demands on the router's memory and CPU resources, only boundary routers should run more than one routing process for the same routed protocol, and only when absolutely necessary.