This chapter starts with a discussion of network performance issues related to routing and using multiple IP routing protocols on a network. Implementing route redistribution between different routing protocols is described, and methods of controlling the routing information sent between these routing protocols are explored, including using route maps, distribute lists, and prefix lists. The chapter concludes with a comprehensive example of controlling routing updates.
Assessing Network Routing Performance Issues
This section discusses common network performance issues related to routing, and solutions to these issues.
Routing Protocol Performance Issues
Common network performance issues related to routing include the following:
-
Excessive routing updates— Excessive routing updates can decrease network performance, because if a Layer 3 switch or a router receives a large number of updates, it must process all of those updates. The size of the CPU utilization spike during this processing depends on the following factors:
-
The size of the routing update: This depends on the routing protocol used, the number of changes being reported, and the number of devices in the autonomous system (AS).
-
The frequency of the updates: This depends on the routing protocol used.
-
The design: The IP addressing plan and use of summarization can affect the number of routing updates sent.
-
The presence of any route maps or filters— Incorrectly configured route maps or filters can cause too much or the wrong data to be sent.
-
The number of routing protocols running in the same autonomous system— This affects the number of routing protocol processes receiving and processing the updates. Routes may also be redistributed between protocols, which can add to the number of updates that a specific protocol must process.
You can configure multiple routing protocols in a single router to connect networks that use different routing protocols. For example, you can run Enhanced Interior Gateway Routing Protocol (EIGRP) on one network, Open Shortest Path First (OSPF) on another network, and exchange routing information between them, in a controlled fashion. In addition, the same router can be connected to an Internet service provider (ISP) and exchange Border Gateway Protocol (BGP) routes with the ISP. As an example, Router R1 in Figure 4-1 runs EIGRP, OSPF, and BGP.
Routing protocols were not designed to interoperate with one another, so each protocol collects different types of information and reacts to topology changes in its own way, resulting in routing update traffic that must be processed by each protocol separately in a different way. For example, Routing Information Protocol (RIP) uses hop count as a metric, and OSPF uses link cost as a metric; these metrics are incompatible and routers exchanging routing information from these protocols must account for these differences. Along with high CPU utilization, more memory resources are needed to maintain all the routing, topology, and database tables in the routers running multiple routing protocols.
Cisco routers allow internetworks using different routing protocols (referred to as routing domains or autonomous systems) to exchange routing information through a feature called route redistribution. Route redistribution is the capability of boundary routers connecting different routing domains to exchange and advertise routing information between those routing domains and is detailed in the “Understanding Route Redistribution” section, later in this chapter.
| Note | The term autonomous system as used here denotes internetworks using different routing protocols. These routing protocols may be Interior Gateway Protocols (IGPs) or Exterior Gateway Protocols (EGPs). This use of the term autonomous system is different from that used for BGP. |
Routing Protocol Performance Solutions
Controlling routing updates involves a variety of solutions, including the following:
-
Design changes, such as limiting the number of routing protocols used.
-
Using passive interfaces, to prevent all updates from a routing protocol from being advertised out of an interface.
-
Route filtering, to block only specific routes from being advertised, such as during redistribution. The following possibilities can be configured to filter routes:
ACLs are usually associated with interfaces and are usually used to control user traffic (data plane traffic) rather than routing protocol traffic (or other control plane traffic). However, routers can have many interfaces, and route information can also be obtained through route redistribution, which does not involve a specific interface. In addition, access lists do not affect traffic originated by the router, so applying one on an interface has no effect on outgoing routing advertisements (but could affect incoming advertisements).
Using route maps, distribute lists, or prefix lists instead of access lists for route filtering gives the administrator greater flexibility in determining just which routes will be permitted and which will be denied.
Route filtering works by regulating the routes that are entered into or advertised out of the routing table.
| Note | Filtering affects link state routing protocols differently than distance vector protocols. For example, distance vector routers advertise and can filter routes from their routing tables. In contrast, link state routers send link-state advertisements (LSAs) and put received information in their link-state database (LSDB), from which they calculate their routing table. Because OSPF routers within the same area must have the same LSDB, LSA filtering for OSPF can be done only between areas. |
Filters can be configured to prevent updates through router interfaces, to control the advertising of routes in routing updates, or to control the processing of routing updates. If filters are not configured correctly or if filters are applied to wrong interfaces, network performance issues may occur.
For example, Figure 4-2 illustrates how inbound filtering is used to control incoming routing update traffic. The process is as follows:
-
A routing update arrives at a router’s interface from a neighboring router. The router stores the packet in the interface buffer and triggers the CPU to make a decision.
-
The router’s CPU checks if there is an incoming filter applied to this interface. If there is no filter, the routing update packet is processed normally.
-
If there is a filter, the router’s CPU checks whether there is an entry for the address in the routing update packet in the filter. If there is no entry, the routing update is dropped.
-
If the entry exists, the router’s CPU processes the routing update packet according to the filter configuration.
Route redistribution is detailed in the next section. Passive interfaces, distribute lists, and prefix lists are all explored later in this chapter.
Understanding a Network with Complex Routing
As a network grows and becomes more complex, the original routing protocol might not be the best choice anymore. For example, routers running RIP periodically send their entire routing tables in their updates. As the network grows larger, the traffic from those updates can slow the network down, such that that a change to a more scalable routing protocol might be necessary. As another example, the network might be using Cisco’s EIGRP and a protocol that supports multiple vendors might be required, or a new policy that specifies a particular routing protocol might be introduced.
The many reasons why a change in routing protocols or running multiple protocols might be required, resulting in a more complex routing environment, include the following:
-
You are migrating from an older IGP to a new IGP. Multiple redistribution boundaries may exist until the new protocol has displaced the old protocol completely. Running multiple routing protocols during a migration is effectively the same as a network that has multiple routing protocols running as part of its design.
-
You want to use another protocol but need to keep the old routing protocol because of the host system’s needs. For example, UNIX host-based routers might run only RIP.
-
Different departments might not want to upgrade their routers to support a new routing protocol.
-
If you have a mixed-router vendor environment, you can use a Cisco-specific routing protocol, such as EIGRP, in the Cisco portion of the network and then use a common standards-based routing protocol, such as OSPF, to communicate with non-Cisco devices.
-
Your network may become larger and more complex because of political and geographic border issues, and as you merge with or are acquired by other organizations.
-
Your organization uses a Layer 3 Multiprotocol Label Switching (MPLS) virtual private network (VPN) service from a service provider that does not use the same IGP as the rest of your network.
Complex networks require careful routing protocol design and traffic optimization solutions, including the following:
The following sections describe redistribution. Route filtering is described in the “Controlling Routing Update Traffic” section, later in this chapter. Summarization is described in Chapter 2, “Configuring the Enhanced Interior Gateway Routing Protocol,” and Chapter 3, “Configuring the Open Shortest Path First Protocol,” for EIGRP and OSPF, respectively.
Understanding Route Redistribution
This section introduces redistribution and some considerations for implementing redistribution, and describes how routes are selected in a redistribution environment.
Redistribution Overview
When multiple routing protocols are running in different parts of the network, hosts in one part of the network might need to reach hosts in the other part. One way to accomplish this is to advertise a default route into each routing protocol, but default routes might not always be the best policy. For example, the network design might not allow default routes, and if there is more than one way to get to a destination network, routers might need information about routes in the other parts of the network to determine the best path to that destination. In addition, if multiple paths exist, a router must have sufficient information to determine a loop-free path to the remote networks.
When any of these situations arise, Cisco routers allow internetworks using different routing protocols (referred to as routing domains or autonomous systems) to exchange routing information through a feature called route redistribution. As mentioned earlier, route redistribution is defined as the capability of boundary routers connecting different routing domains to exchange and advertise routing information between those routing domains (autonomous systems).
Networks may run multiple routing protocols as part of their design, not only as part of a migration. In some cases the same protocol may be used in multiple different domains or autonomous systems within a network. The multiple instances of the protocol are treated no differently than if they were distinct protocols; redistribution is required to exchange routes between them. Thus, redistribution of routing information might be required in many networks.
Network administrators must manage the migration from one routing protocol to another, or to multiple protocols, carefully and thoughtfully. An accurate topology map of the network and an inventory of all network devices are critical for success. When redistributing between routing protocols, the two routing protocols will most likely have different requirements and capabilities, so it is important for network administrators to create a detailed plan before making any routing protocol changes. For example, link-state routing protocols, such as OSPF and Intermediate System-to-Intermediate System (IS-IS), require a hierarchical network structure; network administrators need to decide which routers will reside in the backbone area and how to divide the other routers into areas. Although EIGRP does not require a hierarchical structure, it operates much more effectively within one.
| Note | IS-IS is included in this chapter for completeness, in tables and so forth. However, IS-IS configuration and redistribution are not covered in this book. |
Figure 4-3 shows a sample network migration. This network initially used RIP Version 1 (RIPv1) and is migrating to OSPF, necessitating the following changes:
-
Conversion of the old fixed-length subnet mask (FLSM) addressing scheme to a variable-length subnet mask (VLSM) configuration
-
Use of a hierarchical addressing scheme to facilitate route summarization and make the network more scalable
-
Division of the network from one large area into a transit backbone area and two other areas
Within each autonomous system, the internal routers have complete knowledge of their network. The router that interconnects the autonomous systems is called a boundary router (also called an edge router). The boundary router must be running all the routing protocols between which routes must be exchanged. In most cases, route redistribution must be configured to redistribute routes from one routing protocol to another. The only time redistribution is automatic in IP routing protocols is between Interior Gateway Routing Protocol (IGRP) and EIGRP processes running on the same router and using the same autonomous system number.
| Note | IGRP is no longer supported, as of Cisco IOS Release 12.3. It is included in this chapter for completeness. |
Redistributed Routes
When a router redistributes routes, it propagates routes learned by one routing source into a routing domain that uses a different routing protocol. These redistributed routes could have been learned via a different routing protocol, such as when redistributing between EIGRP and OSPF, or they could have been learned from static routes or by a direct connection to a network. (Routers can redistribute static and connected routes and routes from other routing protocols.)
Redistribution is always performed outbound; the router doing redistribution does not change its own routing table. For example, when redistribution between OSPF and EIGRP is configured, the OSPF process on the boundary router takes the EIGRP routes in the routing table and advertises them as OSPF routes to its OSPF neighbors. Likewise, the EIGRP process on the boundary router takes the OSPF routes in the routing table and advertises them as EIGRP routes to its EIGRP neighbors. With this redistribution, both autonomous systems know about the routes of the other, and each autonomous system can then make informed routing decisions for these networks. The boundary router’s neighbors see the redistributed routes as external routes. In this example, if a packet destined for one of the networks in the OSPF domain arrives from the EIGRP autonomous system, the boundary router must have the OSPF routes for the networks in the OSPF domain in its routing table to be able to forward the traffic.
It is important to note that routes must be in the routing table for them to be redistributed. This requirement might seem self-evident, but it can be a source of confusion. For instance, if a router learns about a network via EIGRP and OSPF, by default only the EIGRP route is put in the routing table because it has a lower administrative distance. Suppose RIP is also running on this router, and you are redistributing OSPF routes into RIP. That network is not redistributed into RIP, because it is placed in the routing table as an EIGRP route, not as an OSPF route.
Figure 4-4 illustrates an autonomous system running OSPF that is connected to an autonomous system running EIGRP. The internal routers within each autonomous system have complete knowledge of their networks, but without redistribution, they do not know about the routes present in the other autonomous system. Router A is the boundary router, and it has active OSPF and EIGRP processes.
Without redistribution, Router A performs ships-in-the-night (SIN) routing: Router A passes OSPF route updates to its OSPF neighbors on the interfaces participating in OSPF, and it passes EIGRP route updates to its EIGRP neighbors on the interfaces participating in EIGRP. Router A does not exchange information between EIGRP and OSPF. If routers in the OSPF routing domain need to learn about the routes in the EIGRP domain, or vice versa, Router A must redistribute routes between EIGRP and OSPF.
Router A learns about network 192.168.5.0 from Router B via the EIGRP routing protocol running on its S0/0/0 interface. After redistribution is configured, Router A redistributes that information to Router C via OSPF on its S0/0/1 interface. Routing information is also passed in the other direction, from OSPF to EIGRP.
The routing table in Router B shows that it has learned about network 172.16.0.0 via EIGRP (as indicated by the D in the routing table) and that the route is external to this autonomous system (as indicated by the EX in the routing table). The routing table in Router C shows that it has learned about network 192.168.5.0 via OSPF (as indicated by the O in the routing table) and that the route is external (type 2) to this autonomous system (as indicated by the E2 in the routing table).
Note that in this example Router A is redistributing routes that are summarized on the network class boundary, to help improve routing table stability and decrease the routing tables’ size. (Recall that EIGRP automatically summarizes on the class boundary, whereas OSPF must be configured to summarize. EIGRP does not automatically summarize redistributed routes though; if they are not already summarized before they are redistributed then summarization must be configured if it is desired.)
| Note | As mentioned in Chapter 1, “Routing Services,” the Cisco IOS documentation for EIGRP says that automatic summarization is now disabled by default. However, testing has confirmed it is still on, at least in some versions of the IOS. Thus, it would be prudent to confirm the auto summary configuration, or to configure it explicitly. |
Redistribution Implementation Considerations
Redistribution of routing information, although powerful, adds to a network’s complexity and increases the potential for routing confusion, so it should be used only when necessary. The key issues that arise when using redistribution are as follows:
-
Routing feedback (loops)— Depending on how you employ redistribution—for example, if more than one boundary router is performing route redistribution—routers might send routing information received from one autonomous system back into that same autonomous system. This feedback is similar to the routing loop problem that occurs with distance vector protocols.
-
Incompatible routing information— Because each routing protocol uses different metrics to determine the best path and because the metric information about a route cannot be translated exactly into a different protocol, path selection using the redistributed route information might not be optimal.
-
Inconsistent convergence times— Different routing protocols converge at different rates. For example, RIP converges more slowly than EIGRP, so if a link goes down, the EIGRP network learns about it before the RIP network.
Good planning is able to solve the majority of issue but additional configuration might be required. Some issues might be solved by changing the administrative distance, manipulating the metrics, and filtering using route maps, distribute lists, and prefix lists. (These topics are all covered in this chapter.)
Understanding why some of these problems might occur requires understanding how Cisco routers select the best path when more than one routing protocol is running and how they convert the metrics used when importing routes from one autonomous system into another. These topics are discussed in the following sections.
Selecting the Best Route in a Redistribution Environment
Recall from Chapter 1 that Cisco routers use the following two parameters to select the best path when they learn two or more routes to the same destination (with the same prefix length) from different routing protocols:
-
Administrative distance— The administrative distance is used to rate a routing protocol’s believability (also called its trustworthiness). Each routing protocol is prioritized in order from most to least believable using a value called the administrative distance. This criterion is the first thing a router uses to determine which routing protocol to believe if more than one protocol provides route information for the same destination.
-
Routing metric— The routing metric is a value representing the path between the local router and the destination network, according to the routing protocol being used. The metric is used to determine the routing protocol’s “best” path to the destination.
Administrative Distance
Table 4-1 lists the default administrative distance of protocols supported by Cisco (this is a copy of Table 1-6). Lower administrative distances are considered more believable (better).
Table 4-1: Default administrative distances of Routing Protocols
Open table as spreadsheet | Route Source | Default Administrative Distance |
| Connected interface | 0 |
| Static route out an interface[1] | 1 |
| Static route to a next-hop address | 1 |
| EIGRP summary route | 5 |
| External BGP | 20 |
| Internal EIGRP | 90 |
| IGRP[2] | 100 |
| OSPF | 110 |
| IS-IS | 115 |
| RIPv1, RIPv2 | 120 |
| EGP[3] | 140 |
| ODR | 160 |
| External EIGRP | 170 |
| Internal BGP | 200 |
| Unreachable | 255 |
| |
When using route redistribution, you might occasionally need to modify a protocol’s administrative distance so that it is preferred. For example, if you want the router to select RIP-learned routes rather than OSPF-learned routes for some specific destination, you can increase the OSPF administrative distance or decrease the RIP administrative distance for the routes to that destination. Modifying the administrative distance is discussed in the section “Using Administrative Distance to Influence the Route-Selection Process,” later in this chapter.
Seed Metrics
When a router advertises a link that is directly connected to one of its interfaces, the initial, or seed metric (also called the default metric) used is derived from the characteristics of that interface, and the metric increments as the routing information is passed to other routers.
For OSPF, the seed metric is based on the interface’s bandwidth. For IS-IS, each interface has a default IS-IS metric of 10. For EIGRP and IGRP, the default seed metric is based on the interface bandwidth and delay. For RIP, the seed metric starts with a hop count of zero and increases in increments from router to router.
When a router is redistributing, the redistributed route must have a metric appropriate for the receiving protocol.
Because redistributed routes are learned from other sources (such as other routing protocols), a boundary router must be capable of translating the metric of the received route from the source routing protocol into the receiving routing protocol. For example, if a boundary router receives a RIP route, the route has hop count as a metric. To redistribute the route into OSPF, the router must translate the hop count into a cost metric that the other OSPF routers will understand.
The seed or default metric is defined during redistribution configuration. After the seed metric for a redistributed route is established, the metric increments normally within the autonomous system. (The exception to this rule is OSPF E2 routes, which hold their initial metric regardless of how far they are propagated across an autonomous system.)
The default-metric router configuration command establishes the seed metric for all redistributed routes. Cisco routers also allow the seed metric to be specified as part of the redistribute command, either with the metric option or by using a route map. These commands are discussed in detail in the section “Configuring Redistribution,” later in this chapter.
When you are redistributing routing information, the seed metric should be set to a value larger than the largest metric within the receiving autonomous system (also called the largest native metric), to help prevent suboptimal routing and routing loops. For example, if RIP routes are being redistributed into OSPF and the highest OSPF metric is 50, the redistributed RIP routes should be assigned an OSPF metric higher than 50.
Default Seed Metrics
Table 4-2 lists the default seed metric value for routes that are redistributed into each IP routing protocol. A metric of infinity tells the router that the route is unreachable and, therefore, should not be advertised. Therefore, when redistributing routes into RIP, IGRP, and EIGRP, you must specify a seed metric; otherwise, the redistributed routes will not be advertised.
Table 4-2: Default Seed Metrics
Open table as spreadsheet | Protocol That Route Is Redistributed Into | Default Seed Metric |
| RIP | 0, which is interpreted as infinity. |
| IGRP/EIGRP | 0, which is interpreted as infinity. |
| OSPF | 20 for all except BGP routes, which have a default seed metric of 1 (all default to type E2). (Note that when redistributing OSPF into OSPF, metrics associated with both intra-area and interarea routes are preserved.) |
| IS-IS | 0. |
| BGP | BGP metric is set to IGP metric value. |
| Note | Redistribution between EIGRP and IGRP with the same autonomous system number is automatic and does not require a metric to be specified. |
For OSPF, the redistributed routes have a default type 2 (E2) metric of 20, except for redistributed BGP routes, which have a default type 2 metric of 1. (Note that when redistributing OSPF into OSPF, metrics associated with both intra-area and interarea routes are preserved.)
For IS-IS, the redistributed routes have a default metric of 0. But unlike RIP, IGRP, or EIGRP, a seed metric of 0 is not treated as unreachable by IS-IS. Configuring a seed metric for redistribution into IS-IS is recommended.
For BGP, the redistributed routes maintain the IGP routing metrics.
Figure 4-5 illustrates an example with an OSPF seed metric of 30 for redistributed RIP routes on Router C. The link cost of the Serial link to Router D is 100. The routes are redistributed as E2 routes, so the cost for networks 172.16.0.0, 172.17.0.0, and 172.18.0.0 in Router D is only the seed metric (30). Notice that the metrics of the three networks in the RIP cloud are irrelevant in the OSPF cloud because the router in the OSPF network (Router D) forwards any traffic for these three networks to the border (redistributing) router, Router C. Router C then forwards the traffic within the RIP network appropriately.
Redistribution Techniques
This section describes one-point and multipoint redistribution techniques, and how to prevent loops in a redistribution environment.
One-Point Redistribution
One-point redistribution has only one router redistributing between two routing protocols. The following two methods of one-point redistribution are available:
-
Two-way redistribution— Redistributes routes between the two routing processes in both directions
-
One-way redistribution— Redistributes only the networks learned from one routing protocol into the other routing protocol; uses a default or static route so that devices in that other part of the network can reach the first part of the network
One-point one-way or two-way redistribution is always safe (in that the network will function correctly) because, there is only one way between routing protocols so routing loops cannot be created.
However, issues can still occur. For example, Figure 4-6 illustrates a network with one-point one-way redistribution. Router R1 running EIGRP is announcing an external route to Routers R2 and R3. Both of these routers are running the two routing protocols OSPF and EIGRP, but the redistribution between EIGRP and OSPF occurs only on Router R2. Router R3 receives routing update information for the external route directly from Router R1 via EIGRP, and via OSPF from Router R2. The administrative distance of OSPF (110) is lower than administrative distance of external EIGRP routes (170), so Router R3 selects the OSPF route. Instead of sending packets directly from Router R3 to Router R1, Router R3 prefers the path via Router R2, resulting in suboptimal routing.
Multipoint Redistribution
Multipoint redistribution has two separate routers running both routing protocols. Two possibilities exist:
Multipoint redistribution is likely to introduce potential routing loops. Even multipoint one-way redistribution is dangerous; multipoint two-way redistribution is highly problematic. Typical problems with multipoint redistribution involve the difference in the administrative distances of the protocols and their incompatible metrics, especially when statically assigned seed metrics are used in redistribution points.
Consider Figure 4-7, with both R2 and R3 redistributing protocol A into protocol B. Multipoint one-way redistribution only works well if
-
The receiving routing protocol supports different administrative distances for internal and external routes. EIGRP, BGP and OSPF do this.
-
The administrative distance of protocol B’s external routes is higher than the administrative distance of protocol A’s routes, so that R2 and R3 will use the appropriate routes to destinations in the protocol A side of the network.
Figure 4-8 illustrates a one-way multipoint redistribution issue. Router R1 from EIGRP is announcing routes, including the external route, to Routers R2 and R3. Both of these routers are running two routing protocols and are redistributing EIGRP into OSPF. Therefore, Routers R2 and R3 receive routing update information for the external route via EIGRP from Router R1 and via OSPF (Router R2 from Router R3, and Router R3 from Router R2). The administrative distance of OSPF (110) is lower than administrative distance of external EIGRP (170), so both Router R2 and Router R3 select the OSPF route. For example, instead of sending packets directly from Router R2 to Router R1, Router R2 prefers the path via Router R3. As a best case, this would be suboptimal routing, but because R3 sends the packet back to R2, a routing loop exists.
Consider Figure 4-9, with both R2 and R3 redistributing protocol A into protocol B, and protocol B into protocol A. Multipoint two-way redistribution difficulties include the following:
-
Suboptimal routing (because only part of the total metric is considered in routing decisions, from the redistribution point onward).
-
Self-sustaining routing loops are possible.
To prevent routing loops in multipoint redistribution scenario the following recommendations should be considered:
-
Insert only internal routes from routing protocol A to B (and vice versa).
-
Tag routes in redistribution points and filter based on these tags when configuring redistribution in the other direction.
-
Propagate metrics from routing protocol A to routing protocol B properly (even though this is not sufficient to prevent loops).
-
Use default routes to avoid having to do two-way redistribution.
Figure 4-10 illustrates a two-way multipoint redistribution issue where the cost of the internal links in routing protocol A is different from the cost of the internal links in routing protocol B. In the figure, it is obvious that the best path between Router R1 and Router R4 is via Router R3, but during redistribution from routing protocol B to routing protocol A, the metric is lost and Router R1 is sending the packets toward Router R4 via Router R2, resulting in suboptimal routing.
Preventing Routing Loops in a Redistribution Environment
The safest way to perform redistribution is to redistribute routes in only one direction, on only one boundary router within the network. (Note, however, that this results in a single point of failure in the network.)
If redistribution must be done in both directions or on multiple boundary routers, the redistribution should be tuned to avoid problems such as suboptimal routing and routing loops.
When discussing redistribution, we use the terms core routing protocol and edge routing protocol. The core routing protocol is the main routing protocol running in the network. During a transition between routing protocols, the core is the new routing protocol and the edge routing protocol is the old routing protocol. In networks that run multiple routing protocols all the time, the core is usually the more advanced routing protocol. Depending on your network design, you may use any of the following redistribution techniques, as illustrated in Figure 4-11:
-
Redistribute a default route from the core autonomous system into the edge autonomous system, and redistribute routes from the edge routing protocols into the core routing protocol. This technique helps prevent route feedback, suboptimal routing, and routing loops.
-
Redistribute multiple static routes about the core autonomous system networks into the edge autonomous system, and redistribute routes from the edge routing protocols into the core routing protocol. This method works if there is only one redistribution point; multiple redistribution points might cause route feedback.
-
Redistribute routes from the core autonomous system into the edge autonomous system with filtering to block out inappropriate routes. For example, when there are multiple boundary routers, routes redistributed from the edge autonomous system at one boundary router should not be redistributed back into the edge autonomous system from the core at another redistribution point.
-
Redistribute all routes from the core autonomous system into the edge autonomous system, and from the edge autonomous system into the core autonomous system, and then modify the administrative distance associated with redistributed routes so that they are not the selected routes when multiple routes exist for the same destination.
Recall that if two routing protocols advertise routes to the same destination, information from the routing protocol with the lowest administrative distance is placed in the routing table. A route redistributed into a routing protocol by default inherits the default administrative distance of that routing protocol.
0 comments
Post a Comment