Routing protocols serve one function: To let nearby routers know how to get
to them and the networks they serve. There are two basic types of routing
protocols: distance vector protocols and link state protocols.
The simplest protocols are perhaps those that classify as Distance Vector
protocols. They base their routing decisions on the number of intermediate
routers along a given path. This has the advantage of taking very few resources
but has the disadvantages of not considering bandwidth or the load of the
available link. They also suffer limitations when long distances are present.
The path may be valid but because of the high metric, the routers decide that
the remote host or network is unreachable. In addition, these types of protocols
usually broadcast their entire routing tables at preset intervals. This can take
quite a bit of time and consume considerable bandwidth. Protocols that fall
under this classification are RIP, IGRP, and BGP.
Link State protocols function by maintaining a database of advertisements
they have received from other routers called the link state database. This means
that each router is wholly responsible for determining the best path to a given
location from its point of view and already has an idea of an alternate path, if
any, should the first path become unavailable.
-
I. Configuring RIP
-
The Routing Information Protocol (RIP) is perhaps the simplest of routing
protocols. It functions by broadcasting its entire routing table to all
participating networks once every 60 seconds for IP or once every 90 seconds for
IPX. When a route is heard from a remote router, the metric is increased by one.
This number cannot exceed 15. A metric of 16 describes an unreachable network.
The simplicity of this protocol means that there is very little that the
router must do each update. This allows the processor to perform other tasks. At
the same time, there is no database being maintained. Its all contained in the
routing tables. This simplicity, however, requires increased bandwidth as the
entire routing table must be sent across the network. In a large network, this
can take considerable time. In addition, It is not uncommon for networks to be
more than 15 hops apart. This means that end nodes will not be able to contact
each other because the metrics surpass the "unreachable" point.
Configuration is a 3 step procedure. First, create a RIP process and
determine if any other routing process (such as IGRP or OSPF) is to redistribute
its routes into this one. Second, specify which networks will receive RIP
broadcasts. Third, configure any non-broadcast neighbors.
A sample configuration might look like
router rip
redistribute igrp 1000
network 2.3.4.0
network 4.5.3.0
neighbor 4.5.5.2
neighbor 4.5.5.3
-
II. Configuring IGRP
-
The Interior Gateway Routing Protocol (IGRP) is a dynamic distance-vector
routing protocol designed by Cisco Systems in the mid-1980s. The advantages of
IGRP over RIP include the maximum diameter of the network. Networks over 15 hops
are unreachable in a RIP controlled network. IGRP allows up to 100 hops by
default and can be set to accept paths as far away as 255 hops.
IGRP uses a combination of user-configurable metrics including internetwork
delay, bandwidth, reliability, and load. Unlike RIP, IGRP routes are shared in
proportion to their cost to provide equal or unequal cost load balancing with up
to 4 paths to a given destination. Equal or unequal cost can be specified with a
variance factor. The variance determines how unequal paths can be when
performing load balancing. A variance of 1 (the default) specifies load
balancing only when all paths are of an equal cost. This behavior can be
overridden with the "traffic-share" command. To permit only the path with the
lowest cost to be used, specify "traffic-share min". "traffic-share balanced" is
the default.
Basic IGRP configuration is very similar to that of RIP. An IGRP routing
process must be created on the router and given a list of participating
networks. IGRP also accepts an optional Autonomous System number. When running
IGRP over a non-broadcast network, systems which will accept updates can be
entered individually with the "neighbor" command, as in RIP. Interfaces included
in the range of addresses specified with a network statement that should not
participate in IGRP (an example would be if that interface is managed through
some other protocol such as OSPF), it can be designated passive with the
"passive-interface" statement.
Example configuration:
router igrp 1000
variance 3
network 203.4.22.0
network 204.103.24.0
neighbor 204.103.24.5
neighbor 204.103.24.6
neighbor 204.103.24.7
passive-interface Ethernet4/1
passive-interface Fddi3/0
-
III. Configuring Enhanced IGRP
-
Enhanced IGRP is a redesign by Cisco of IGRP. It is intended to overcome some
of the limitations that became apparent when IGRP was put into heavy use.
Principally, improvements concentrated on the convergance time. Towards that
end, a new convergence algorithm, DUAL (Diffusing Update Algorithm) was
introduced. Among the benefits gained by the new algorithm is a guarantee of
loop-free routing tables where EIGRP is the controlling protocol. EIGRP also
introduces partial updates. This allows fewer routing messages to be exchanged
between routers which, in turn, consume less bandwidth, leaving the data path
free for user data. Partial updates also allow the receiving router to spend
less time recalculating routing tables since routes not included in the update
do not have to be recalculated.
Two key features of EIGRP are support for variable-length subnet masks and
arbitrary route summarization. This allows for the removal of "classfull" routes
in favor of CIDR routes, reducing the size of the routing table as a whole and
allowing for easier maintenance of routing tables. EIGRP is also capable of
automatically summarizing routes into common routes when possible. This feature
can be disabled by specifying "no auto-summary" in the EIGRP configuration.
Additional summarization can be performed within the router configuration on a
per interface basis by placing "ip summary-address eigrp" statements in the
interface configuration commands to advertise a specific aggregate as belonging
to a given autonomous system as shown below.
interface Ethernet0
ip summary-address eigrp 1234 201.200.8.0 255.255.224.0
The result of this command is that advertisements of networks within the
201.200.8.0 block are reduced to a single advertisement of the aggregate block.
So rather than sending routes for 32 class C networks, as RIP would do, a single
advertisement encompassing all 32 networks can be made instead.
Another addition to EIGRP is support for the exchange of hello messages. When
an EIGRP process is started, the router will send out hello packets on all
participating interfaces using multicast packets when appropriate. Once the
router determines which other routers are participating in EIGRP, the process of
exchanging updates can begin. This allows for routers to quickly determine when
new routers are added to the network or when existing routers become
unreachable.
Basic configuration of EIGRP does not differ significantly from that of IGRP
except that the router configuration command requires an EIGRP process ID
instead of the optional autonomous system number.
Like IGRP, EIGRP supports unequal cost load balancing. But because of EIGRP's
rapid convergence, enabling this feature is not only desirable from a traffic
standpoint, when enabled, the other paths are already in use so fall over time
in the event of a failure is minimal. To ease the transition from IGRP to EIGRP,
routes are automatically redistributed between the two protocols.
-
IV. Configuring OSPF
-
The Open Shortest Path First (OSPF) Protocol was designed by the IETF as an
IGP expressly for use with TCP/IP networks belonging to a single Autonomous
System. It is designed as a link state protocol and is scalable to all but the
most complex networks.
OSPF operates by forming adjacencies between routers and creating a
topological database containing information about the state of all the links in
the OSPF network. This information includes weights placed on various interfaces
based on the bandwidth of the link and the type of interface or placed there
manually by the network administrator. The cost of an internal path is
determined by calculating the sum of the cost of traversing each link in the
database. The path with the lowest cost (shortest path) is chosen as the best
route. If there are multiple paths with equal cost, OSPF will load balance
across up to 4 of these paths.
This database is updated whenever an adjacency is formed or dropped. Because
a complete picture of the network is maintained by every router, when an
adjacency drops and the corrosponding link is no longer availible, a new path
can quickly be chosen from information the router already has. However, because
it must hold a complete copy of the topological database, the memory
requirements are quite substantial.
On large networks, the number of links in the database can grow to immense
proportions. In these cases, a single link change can have a significant impact
on every router in the system. A link that is intermittantly availible and
unavailible can lead to high processor use for all routers, diminishing the
performance of the network. OSPF provides a method of segmenting the network
into several areas. These areas act as described above and are connected to a
"backbone" area (area 0). The area boundry routers, rather than propegating
every link state advertizement (LSA) into the backbone, only propegate "summary"
advertizements describing the area they are linked to. This summary
advertizement describes the entire area database in a single message, thus
reducing the computational overhead and memory usage. Dividing the network into
areas also reduces the impact of a single router or interface changing states on
the rest of the network. only the attached area must recalculate the paths
through that router or interface.
Use of stub areas and route summarization between areas can also help to
reduce the number of entries in the topological database and reduce the memory
requirements and CPU requirements for recalculating paths when changes occur in
the network even further. Stub areas do not receive external LSAs (those
injected into OSPF via redistribution from another protocol, such as RIP) and do
not have to maintain any link state records except those within the stub area.
Routers configured with OSPF discover other OSPF routers by multicasting or
unicasting hello packets to all SPF routers (multicast address 224.0.0.5). These
hello packets are used to form and maintain adjacencies between routers.
Adjacencies are formed automatically across point to point links. On
multiaccess networks such as ethernet, a "Designated Router" (DR) is elected.
This router forms adjacencies with all other routers on the multi-access network
and is responsible for synchronizing the topological database. In addition, a
backup designated router (BDR) is also selected. In the event of a failure which
disconnects the DR from the network, the BDR takes over and a new BDR is
elected. This reduces traffic across the network since each router does not have
to form an adjacency with every other router. This also reduces the CPU usage on
all other routers connected to this network when a router becomes unavailable.
Which routers are DR and BDR can be determined with either "show ip ospf
neighbors" or "show ip ospf interface <interface>".
OSPF is enabled by creating an OSPF routing process and specifying a process
ID. Which networks OSPF operates over is controlled by "network" statements (as
in RIP or IGRP). At the same time, these networks are assigned an area number.
Neighbors can be hinted at by using the "neighbor" statement. Note that a
neighbor does not necessarily form an adjacency. The exec command "show ip ospf
neighbor" can be used to determine which routers are viewed as neighbors and the
state of the link (whether they are simple neighbors, adjacent neighbors, BDR,
or DR.) A simple OSPF configuration is shown below.
Interface Ethernet0/0
ip address 1.1.1.1 255.255.255.0
Interface Serial1/2
ip address 1.1.2.1 255.255.255.0
Interface Fddi2/0
ip address 1.1.3.1 255.255.255.0
router ospf 1234
network 1.1.1.0 0.0.0.255 area 1
network 1.1.2.0 0.0.0.255 area 2
network 1.1.3.0 0.0.0.255 area 0
This sequence of commands configures OSPF on the three interfaces listed
assigning Ethernet0/0 to area 1, Serial1/2 to area 2, and Fddi2/0 to the
backbone area (area 0). Note that the network statements require a wildcard mask
and not a network mask.
OSPF also supports variable length subnetting and route sumarization though
it must be configured manualy. Sumarization takes place between areas and into
the OSPF backbone area. Configuration of summary networks is done at area border
routers with the "area <area ID> range <network> <network
mask>" command. Using route sumarization can greatly decrease the size of the
topological database and reduce the amount of recalculation that needs to be
done when a route becomes inaccessible or other topological changes occur. The
backbone area should not be sumarized. If all other areas are summarized
properly, all the backbone area will contain is summary routes.
Similarly, sumarization can be done when another protocol is redistributed
into OSPF with a "summary-address <network> <network mask>"
-
V. Configuring BGP
-
The Border Gateway Protocol (BGP) is another in the family of distance vector
protocols. However, unlike most routing protocols, BGP views its paths in terms
of Autonomous Systems (ASs). An AS is loosely defined as a collection of routers
under common administration. For example, Primenet is one AS, MCI is another,
AT&T a third, and so on. Each of these ASs has their own AS number, which is
used in the BGP exchange. Primenet's AS number (ASN) is 3549, MCI is 3561, and
so forth.
BGP functions by setting up peering sessions with neighboring routers. An
important advantage of BGP over other protocols is the use of TCP to transmit
update messages and maintain peering sessions. Because of this, these sessions
are not intended directly to be a measure of the link integrity, but more to
provide an idea of the health of the neighboring router. If the router becomes
unreachable or stops responding, the peering session will drop and the routes
received over that link will be deleted from the BGP tables and other routers
subsequently informed.
This loss of conectivity can be caused by the router going down due to a
failure or loss of power, a problem with the link the session is transmitting
over, or simply congestion which causes BGP information packets to be dropped.
With the explosion of the internet over the last several years, routers which
experience repeated BGP or EGP neighbor state changes have become more
problematic. This is usually caused by the router rebooting multiple times or by
an intermittant link. Most recently, a cause of such problems has been routers
simply being overwhelemd by update messages and being unable to maintain peering
sessions as a result. The term coined to describe this repeated advertizement
and deletion of routes is "route flap" or a router "flapping". The result is
that neighboring routers (and quite probably routers two or three links
downstream) being overwhelemd with these messages and spending all their time
recalculating paths. The effect of this is that those routers' services are
degraded until stability returns. It can even cause those routers to begin to
"flap" as well as the number of updates goes beyond what that router is capable
of processing, creating a cascade failure. A great deal of research and
development is being done by many companies at a feverish rate to produce
routers capable of handling these updates and many service providers have
instituted policies designed to reduce the size of the routing tables to reduce
flap or to protect themselves from flap by "dampening" routes that flap
repeatedly in a given interval.
A BGP route contains only a few pieces of information. The first is the
network that the route describes. Second, the AS path necessary to get to that
destination. Third, the origin of the route (External BGP or EBGP, Internal BGP
or IBGP, another Interior Gateway Protocol or IGP, or incomplete.) Fourth, the
router ID of the advertizing router, and finally, the BGP next hop address.
BGP provides a simple, yet effective loop detection method. Simply, the AS
path of the learned route is checked against the router's own AS number. If this
number apears anywhere in the path, the route is unusable and is discarded.
There are also a few weights and metrics associated with a BGP route which
are used to aid in the path selection process. The first is litterally known as
a "weight" and is used only by the router which sets it. This weight is not
propegated to other routers. The second is a "local prefference" value. This is
propegated to all routers belonging to a single AS. The last value availible is
a "metric" or "Multi Exit Descriminator" (MED). MEDs are advertized to EBGP
neighbors and is used to hint at the best path into an AS. The MED is reset when
the route is readvertized to a third AS.
The BGP path selection process is straight forward.
- If the next hop is inaccessible, do not consider it.
- Consider larger BGP administrative weights first.
- If the routers have the same weight, consider the route with higher local
preference.
- If the routes have the same local preference, prefer the route that the
local router originated.
- If no route was originated, prefer the shorter autonomous system path.
- If all paths are of the same autonomous system path length, prefer the
lowest origin code (IGP < EGP < INCOMPLETE).
- If origin codes are the same and all the paths are from the same autonomous
system, prefer the path with the lowest Multi Exit Discriminator (MED) metric. A
missing metric is treated as zero.
- If the MEDs are the same, prefer external paths over internal paths.
- If IGP synchronization is disabled and only internal paths remain, prefer
the path through the closest neighbor.
- Prefer the route with the lowest IP address value for the BGP router ID.
BGP configuration begins by creating a BGP process and listing the router's
local ASN. Next, neighbors are listed with their ASNs. A router with the same
ASN is identified as an iBGP peer and those with differing ASNs are eBGP peers.
The following configuration establishes a BGP process with ASN 3549 and creates
an iBGP session with router 1.2.3.4 and an eBGP session to router 2.3.4.5 with
AS number 380.
router bgp 3549
neighbor 1.2.3.4 remote-as 3549
neighbor 2.3.4.5 remote-as 380
Advertizements of reachable networks can be controlled by redistributing
another protocol into BGP or by manualy configuring these networks as in the
following example.
network 1.0.0.0
The class A network 1.0.0.0 is placed in the iBGP routing tables and becomes
eligible for advertizement to eBGP peers with an origin code of "IGP". In
general, this is the prefered method of advertizing BGP networks as
redistribution of other protocols into BGP results in the loss of information
about those networks learned by the IGP and mutual redistribution can lead to
routing loops.
In the normal case, BGP must synchronize with an IGP. This means that a route
learned by an eBGP peer will not be readvertized to another eBGP peer until the
IGP has propegated this route to all routers in the local autonomous system.
This has the effect of making certain that the route is not used before all
routers know about it, resulting in data loss and serving to stabalize the
network somewhat. However, this can slow convergance when routes change and
increase the size of the IGP tables. To disable synchronization, use the BGP "no
synchronization" command. If redistribution is not used, synchronization must be
disabled for BGP to function.
Beginning with BGP version 4, BGP supports CIDR and route summarization.
Summarization is enabled by default and can be disabled using the "no
summarization" command. Routes are summarized by creating aggregate addresses.
This has the effect of advertizing a single supernet for multiple related routes
when possible in addition to the individual routes. Using the "summary-only"
option, these more specific routes can be surpressed.
router A:
router bgp 3549
neighbor 1.2.3.5 remote-as 3549
network 1.2.0.0 mask 255.255.0.0
network 1.3.0.0 mask 255.255.0.0
network 1.1.8.0 mask 255.255.248.0
router B:
router bgp 3549
aggregate address 1.0.0.0 255.0.0.0 summary-only
neighbor 1.2.3.4 remote-as 3549
neighbor 2.3.4.5 remote-as 1111
In the preceding example, router A is configured with one iBGP peer and
begins advertizing 3 subnets of the 1.0.0.0 class A. Router B configures one
iBGP neighbor and one eBGP neighbor and summarizes routes learned from router A
into a single advertizement which is sent to the eBGP peer.
Often, the closest path to a site may not be the best path, either because of
bandwidth limitations or performance problems. The most direct way to prefer one
neighbor's routes over another is to simply filter the advertizements to remove
the unwanted routes. This can be done based on network prefix or AS path.
router bgp 3549
neighbor 1.2.3.4 remote-as 1111
neighbor 1.2.3.4 distribute-list 1 in
neighbor 2.3.4.5 remote-as 2222
neighbor 2.3.4.5 filter-list 7 in
access-list 1 deny 10.0.0.0 0.255.255.255
access-list 1 permit any
ip as-path access-list 7 deny _5555$
ip as-path access-list 7 permit .*
The preceding example prevents neighbor 1.2.3.4 for advertizing that it can
reach the network 10.0.0.0/8 and prevents neighbor 2.3.4.5 from advertizing that
it can reach any path where ASN 5555 is the last ASN in the path. The as-path
regular expressions are documented in the cisco documentation set and follow
general regular expression rules. Note that access lists and route maps (as
illustrated below) can be applied to either inbound or outbound advertizements.
Filtering advertizements is an easy way to determine how you want your
network to route but it has one big drawback: if the primary route is down, the
destination simply becomes unreachable. The filter prevents the secondary route
from ever appearing in the first place. BGP provides two alternative ways of
influencing the path selection process: weights and local prefference values.
router bgp 3549
neighbor 1.2.3.4 remote-as 1111
neighbor 1.2.3.4 weight 300
neighbor 2.3.4.5 remote-as 2222
Configuring weights for all of a neighbor's routes requires no more than an
additional statement in the BGP configuration, specifying the weight that should
be assigned to these routes. If two neighbors advertize that they can reach the
same network, the path with more weight will be selected.
It should be noted that the configured weight is only used by the router that
sets it. If you want every router in your AS to prefer the same path, you can
use a "route map" to set a local preference value. This value will be propegated
to every iBGP peer that receives this route. Routes with no local preference set
receive a local preference of 100. Higher local preferences are selected first.
router bgp 3549
neighbor 1.2.3.4 remote-as 1111
neighbor 1.2.3.4 route-map set-weight in
route-map set-weight permit 10
set local-preference 200
Route maps allow complex filtering to be performed based on multiple
conditions. There can be multiple statements underneath a route-map to alter a
variety of attributes. The routes altered can also be limited by further
filtering the advertizements by using an access-list (prefix or AS path) to
"match" a subset of the routes being processed. It is also possible to apply
multiple policies to the same neighbor. These policies are ordered sequentially
according to the number listed after the "permit" or "deny" statement. The
following example illustrates some of these capabilities.
router bgp 3549
neighbor 1.2.3.4 remote-as 1111
neighbor 1.2.3.4 route-map local-policy in
neighbor 1.2.3.4 distribute-list 25 in
route-map local-policy permit 10
match as-path 1
set weight 300
route-map local-policy permit 20
match ip address 20
set local-preference 125
route-map local-policy permit 30
set as-path prepend 1111
ip as-path access-list 1 deny _350_
ip as-path access-list 1 permit .*
access-list 20 permit 120.10.0.0 0.0.255.255
access-list 20 deny any
This example also demonstrates that it is possible to alter the AS path of a
given route. By prepending the appropriate AS number, it is possible to increase
the path length of a BGP route, making it further away.
One problem with running iBGP is the requirement of BGP for a "full mesh"
within the AS (every router must establish a peering session with every other
router). Clearly, this is not possible in all settings and can create problems
when a great meny peering sessions must be maintained on a single router. There
are ways to reduce the mesh needed to propegate iBGP routes and simplify the
structure of the autonomous system. The first of these is router reflectors.
Normaly, when a route is received from one iBGP speaker, it is not
readvertized to another. Route reflectors provide a way to permit this
occurence. Each client's routes are reflected to every other iBGP router that
the server peers with. The clients are configured as normal iBGP speakers. The
server simply designates clients as such.
router bgp 3549
neighbor 1.2.3.4 remote-as 3549
neighbor 1.2.3.4 route-reflector-client
neighbor 1.2.3.5 remote-as 3549
neighbor 1.2.3.5 route-reflector-client
With such a configuration, peering between 1.2.3.4 and 1.2.3.5 is not
necessary since the route server reflects the routes received by each neighbor
to the other neighbor.
Another method of reducing the iBGP mesh is to create a confederation,
effectively splitting the single AS into several smaller autonomous systems.
These "mini-ASs" must be fully meshed but only require one connection between
themselves and other mini-ASs. Confederations allow the smaller ASs to exchange
routes between themselves as if they were using iBGP (local preference values,
MEDs, etc are all preserved). To the rest of the world, the confederation
appears as a single AS.
router bgp 65501
bgp confederation identifier 3549
bgp confederation peers 65502 65503
neighbor 1.2.3.4 remote-as 65501
neighbor 1.2.3.5 remote-as 65501
neighbor 2.3.4.5 remote-as 65502
neighbor 2.3.4.6 remote-as 65503
neighbor 2.3.4.6 weight 300
neighbor 5.5.5.5 remote-as 1050
neighbor 5.5.5.5 route-map set-preference in
The local router is identified to the confederation as 65501. It is
identified to non-confederation peers as ASN 3549. AS 65502 and 65503 are also
members of this confederation. iBGP connections are configured between this
router and the routers listed as 1.2.3.4 and 1.2.3.5. Peering sessions are
established between this router and the confederation members 65502 and 65503.
There is also an eBGP session established with router 5.5.5.5 with the remote
ASN of 1050. This router will view the peer as AS 3549 and not be aware of
65501, 65502, or 65503. This router sets the local preference for AS 1050 and
passes it to every iBGP peer and the rest of the confederation.
VI. Exchanging Routes Between Protocols
It is entirely possible (and often necessary) to exchange routes learned by
one protocol into another. An example of such a case would be where a network
cannot be managed by a single protocol due to software or hardware limitations.
Such limitations might be due to a lack of adequate memory in the router or a
router that does not support the desired protocol. It might also be the case
that functionality provided by one protocol is not sufficient in a particular
area of the network and another protocl must be left to manage that section. In
order for the rest of the network to know the routes to those other sections and
vice versa, the protocols must exchange routing information.
Assume that a collection of routers only speak RIP but that these routes need
to make their way into EIGRP and the EIGRP routes neet to be injected into RIP.
Redistribution would occur at the boundry router and would look similar to the
example that follows.
router eigrp 10
redistribute rip
router rip
redistribute eigrp 10
The routes that one protocol learns are now visible to the other. But assume
for a momment that the network running RIP only needs to default out to the
network running EIGRP. In this case, the RIp network does not need to see the
eigrp routes and the redistribution is only necessary into EIGRP. This saves
memory on the RIP routers, network bandwidth, calculation time, etc and generaly
makes things run cleaner. It also eliminates one problem with the configuration
shown above. Once the routes from the RIP process are distributed into the EIGRP
process, they become EIGRP routes and are eligigle to be distibuted BACK into
the RIP process. This can create routing loops and destroy the connectivity of
the network. When using such mutual redistribution, careful filtering is
required to avoid such pitfalls. This filtering is set by using a route-map
along with the redistribution statement.
In this example, the RIP network needs to learn the EIGRP routes and send its
routes back. The RIP network manages routes for 10.2.3.0/24 and 10.2.4.0/24. The
EIGRP network routes the rest of the 10.0.0.0/8 network.
router eigrp 10
redistribute rip route-map rip-in
router rip
redistribute eigrp 10 route-map eigrp-in
route-map rip-in permit 10
match ip address 20
route-map eigrp-in permit 10
match ip address 21
access-list 20 permit 10.2.3.0 0.0.0.255
access-list 20 permit 10.2.4.0 0.0.0.255
access-list 21 deny 10.2.3.0 0.0.0.255
access-list 21 deny 10.2.4.0 0.0.0.255
This effectively limits the routes seen by the two processes. This is not the
only method of filtering, however. Assuming the same access lists, the following
two configurations would also work.
router rip
redistribute eigrp 10 metric 2
distribute-list 21 in
router eigrp 10
redistribute rip
default-metric 1000 100 250 100 200
Or
router rip
redistribute eigrp 10
distribute-list 20 out
router eigrp 10
redistribute rip
distribute-list 21 out
These two examples accomplish the same end result as the route-map example
above. In addition, two other features are demonstrated. The first is the
setting of a metric on the inbound routes. The second is a default metric used
when the metric cannot properly be calculated or when information is missing (as
in the redistribution). This information is specific to the protocol and the
command refference guide should be used to determine which values to use.
