|
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.
|