could assume you wanted to redistribute, and assign a standard metric to the learned routes, a better approach is to allow you to decide whether and how routes should be redistributed. Two steps must be taken when redistributing routes. First, a metric must be config- ured. This allows the routing protocol to assign a metric that it understands to the incoming routes. Second, the redistribute command must be added. (The exact commands used for these purposes vary widely between protocols, and they'll be discussed individually in the sections that follow.) One reason to redistribute routes might be the inclusion of a firewall that must par- ticipate in dynamic routing, but cannot use the protocol in use on the network. For example, many firewalls support RIP, but not EIGRP. To dynamically route between an EIGRP router and a RIP-only firewall, you must redistribute between RIP and EIGRP on the router. The best rule to remember when redistributing is to keep it simple. It's easy to get confused when routes are being sent back and forth between routing protocols. Keeping the design as simple as possible will help keep the network manageable. You can create some pretty interesting problems when redistribution isn't working properly. The simpler the design is, the easier it is to troubleshoot. Redistribution is about converting one protocol's routes into a form that another protocol can understand. This is done by assigning new metrics to the routes as they pass into the new protocol. Because the routes must adhere to the metrics of the new protocol, the key to understanding redistribution is understanding metrics. When a protocol redistributes routes from any source, they become external routes in the new protocol. Routes can be redistributed from a limited number of sources: Static routes Routes that have been entered manually into the configuration of the router doing the redistribution can be redistributed into routing protocols. Injecting static routes on one router into a dynamic routing protocol can be a useful 