route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2 destination^ ^mask ^gateway metric^ ^ Interface^ You can see here that you set this via the METRIC option when you add the route. Lower numbers take priority over higher numbers. It can have the metric between 1 to 255. Please do rate for the helpful posts and mark correct answers. (ad=1 metric=0 1/0) for static routes and also standard mention that non valid metric is -1 and not 0. As clearly explained in this thread in Cisco IOS implementation static routes have an admin distance of 1 by default that can be. The static route has the lowest administrative distance (1) of any of the routes; however, its prefix-length is less specific. 192.168.111.0/24 is a more specific route than 192.168.0.0/16. Remember, prefix-length is always considered first. The second RIP route will not be inserted into the routing table, because it has a higher metric (5.
If a routers learns about multiple different paths to the same network from the same routing protocol, a measure called metric is used to decide which route will be placed in the routing table. Just like with the administrative distance, the lower number represents the better route.Wondershare video converter ultimate 5 0 5 download free.
Each routing protocol has its own way to calculate the metric; Routing Information Protocol (RIP) uses hop counts, OSPF uses a parameter called cost, EIGRP uses bandwidth and the delay to compute the metrics, etc. Note that metrics of different routing protocols can not be directly compared – an EIGRP route might have a metric of 4.042.334, while a RIP route can have a metric of 3.
If two routes have the same AD as well as the same metrics, the routing protocol will load-balance to the remote network, meaning that data will be sent down each link.
To understand the importance of routing metrics, consider the following example:
Let’s say that all routers are running RIP. R1 receives two possible routes to the 10.0.0.0/24 network; one going through R2, and one going through R3 and R4. Both routes are RIP routes and have the same administrative distance, so the metric is used to determine the best route. The RIP metric is hop count, which is simply a number of routers between the source and destination. In this case, the route going through R2 will have a metric of one, because only one router is in the path to the 10.0.0.0/24 network. The route going through R3 and R4 will have a metric of two. The first route will be placed in the routing table and used for packets sent to the 10.0.0.0/24 subnet.
In the example above you can see the problem of using hop counts as a routing metric. Imagine if the first path through R2 was the 56 kbps modem link, while the other path is a high speed WAN link. Router R1 would still chose the path going through R2 as the best route, because RIP uses only the hop count as its metric.
Administrative distance (AD) explained
RIP (Routing Information Protocol) overview
Introduction to Route Redistribution
Until there is one routing protocol to rule them all, there is a need to have multiple routing protocols peacefully coexist on the same network. Perhaps Company A runs OSPF, and Company B runs EIGRP, and the two companies merge. Until the newly combined IT staff agrees on a standard routing protocol to use (if they ever do), routes known to OSPF need to be advertised into the portion of the network running EIGRP, and vice versa.
Such a scenario is possible thanks to route redistribution, and that’s the focus of this blog post. Other reasons you might need to perform route redistribution include: different parts of your own company’s network are under different administrative control; you want to advertise routes to your service provider via BGP; or perhaps you want to connect with the network of a business partner. Consider the following basic topology.
In the simple topology show above, we’re wanting OSPF and EIGRP to advertise the routes they know about to one another. This concept is called mutual route redistribution. Since router R2 has one interface in the OSPF autonomous system (AS) and one interface in the EIGRP AS, it bears the responsibility of performing the route redistribution.
Seed Metrics
The primary challenge we run into when redistributing routes between different routing protocols is the different approaches routing protocols use to measure their metrics. For example, OSPF uses a metric of cost, which is based on bandwidth, while EIGRP uses a metric based on bandwidth and delay, by default, but might also consider reliability and/or load (and even use a Maximum Transmission Unit (MTU) value as a tie breaker). The issue isn’t as simple as something like converting currencies between two countries, because in that scenario, there’s a ratio describing the relationship of the two currencies. However, with route redistribution, no such relationship exists. So, what do we do?
We, as administrators, can configure the metric assigned to routes coming in from one AS, which are being redistributed into another AS. If we don’t bother to manually configure a metric to be used for route redistribution, then a seed metric is used. The following table shows the seed metrics used by various routing protocols.
Routing Protocol
Default Seed Metric
RIP
Infinity
EIGRP
Infinity
OSPF
20 (or 1 when redistributing BGP routes)
BGP
Uses the IGP metric value
Based on the above table, we can see that, by default, a route redistributed into OSPF will be assigned a metric of 20, unless the route is being redistributed into OSPF from BGP, in which case the route would be assigned a metric value of 1. Interestingly, both RIP and EIGRP have default seed metrics of infinity, meaning that any route redistributed into those routing protocols will be considered unreachable, by default, and therefore not advertised to any other routers. BGP, however, redistributes a route learned from an interior gateway protocol (IGP) using that route’s original metric.
Basic Configuration Example
Certainly, there’s lots more to consider regarding route redistribution, such as the routing loops that can occur when we have more than one router interconnecting our autonomous systems, or how we selectively filter specific routes from being redistributed, but we’ll get to all that in upcoming blog posts. For now, let’s get an understanding of how to perform a basic route redistribution configuration. Consider the previous topology, this time with network and interface information added:
In this topology, router R2 is learning routes from R1 via OSPF and from R3 via EIGRP, as shown in the following output from the show ip route command issued on R2:
However, neither router R1 nor router R3 has learned any routes, because router R2 is not yet performing route redistribution. This is evidenced in the output of the show ip route command issued on R1 and R3:
Let’s now add a route redistribution configuration to router R2. To reinforce the earlier statement that the seed metric for routes redistributed into EIGRP is infinity, we’ll initially not configure any metrics and let the seed metrics take effect.
The redistribute command was issued under router configuration mode for each routing protocol, and no metric was specified. It’s also interesting to note what when we entered the redistribute eigrp 1 command above, we did not include the subnets keyword in the command, which causes both classful and classfuless networks to be redistributed into OSPF. However, as seen in the output below, the subnets keyword was automatically added for us:
1-255 Distance Metric For This Route
While this behavior of having the subnets keyword automatically added is seen in recent versions of Cisco IOS, some older versions of Cisco IOS do not automatically include the subnets keyword, and you might need to manually add it to your redistribute command.
Let’s now take a look at the IP routing tables on routers R1 and R3 to see what routes they’ve learned (and haven’t learned).
The above output shows us that router R2 successfully redistributed routes known to EIGRP into OSPF, which were then learned by router R1. Notice the redistributed routes known to router R1 have a metric of 20, which is OSPF’s seed metric. However, router R3 did not learn any new routes, because when router R2 redistributed routes into EIGRP, it used EIGRP’s seed metric of infinity (meaning unreachable). As a result, those routes were not advertised to router R3.
To resolve this issue, we need to assign a metric to routes being redistributed into EIGRP. There are three primary ways we can assign a non-default metric to routes being redistributed into a routing protocol.
Set a default metric for all routing protocols being redistributed into a specific routing protocol.
Set a metric as part of the redistribute command.
Set a metric using a route-map.
To illustrate the first option, let’s configure the metric to assign to all routes being redistributed into EIGRP.
Context-sensitive help was used in the above example to show each component of the metric being assigned to routes being redistributed into EIGRP. However, the final command was default-metric 1000000 1 255 1 1500. If we were setting a default metric for OSPF, we could have used a command such as default-metric 30, to assign an OSPF cost of 30 to routes being redistributed into OSPF. However, in this example, we only specified a default metric for EIGRP. Let’s now check out the IP routing table on router R3 to see if OSPF routes have been successfully advertised into EIGRP.
Success! Router R3 has learned routes originating in the OSPF AS. We know the routes originally came from outside the EIGRP AS due to the EX code appearing in each of those routes.
The second option for setting the metric on redistributed routes was to assign the metric as part of the redistribute command, which let’s us specify different metrics for different routing protocols being redistributed into a routing process. To illustrate that approach, let’s remove the previous default-metric and redistribute commands from router R2, and enter a redistribute command that specifies the metric to be assigned.
The third option for setting the metric on redistributed routes was to use a route-map. Route-maps are super powerful and can be used for a variety of configurations. Essentially, they can match specific traffic and set one or more parameters (e.g. a next-hop IP address) for that traffic. In our context though, we’re just going to use a route-map to specify a metric value, and we’ll then apply the route-map to a redistribute command. The following example, shows how we can remove our previous redistribute command from router R2, create a route-map, and then enter a new redistribute command that references our route-map:
In the above example, after removing our existing redistribute command, we created a route-map named SET-METRIC-DEMO. This was a very basic route-map that didn’t need to match any traffic. It was simply used to set a metric. However, in an upcoming blog post, we'll see that a route-map can be used to give us more control over our route redistribution. In our current example, the route-map was then applied to our new redistribute command. Again, this gives us the same result from the perspective of router R3’s IP routing table:
Before we wrap up this first blog post in our Route Redistribution series, let’s once again examine the IP routing table on router R1:
Notice that each of the routes redistributed into OSPF show up in router R1’s IP routing table with an E2 code. However, there’s also the option of having an E1 code, both of which indicate that the route originated from outside the router’s OSPF AS. So, what’s the difference between these two codes?
A code of E2 indicates that a route carries a metric that was assigned by the router performing the redistribution, which is known as an Autonomous System Boundary Router (ASBR). This means that no matter how many additional routers within the OSPF AS we have to cross in order to get back to the ASBR, the metric stays the same as it was when the ASBR redistributed it. When we redistribute routes into OSPF, those routes, by default, are these External Type 2 (E2) routes.
A code of E1 indicates that a route’s metric is made up of the original cost assigned by the ASBR plus the cost required to reach the ASBR. This suggests that an E1 route is generally more accurate, and in fact it is. Although, having a code of E1 doesn’t offer us any advantage in a simple topology like we have, where router R1 only has one path to reach the ASBR (i.e. R2), and where there’s only one way for EIGRP routes to be injected into our OSPF AS (i.e. via router R2).
If we want to redistribute E1 routes into OSPF instead of E2 routes, that can be accomplished with the redistribute command. In the following example, we remove our existing redistribute command for the OSPF routing process on router R2, and then reapply the redistribute command specifying that we want External Type 1 (E1) metrics applied to redistributed routes.
Let’s check out the IP routing table on router R1 to see if things have changed based on this new redistribute command issued on router R2.
In the above output, notice that the routes redistributed into OSPF have a code of E1, instead of the default code of E2. Also, notice that this causes the metric of these routes to be a bit higher. Specifically, router R2 redistributed EIGRP-learned routes into OSPF using OSPF’s seed metric of 20. However, there is an OSPF cost of 1 to get from router R1 to router R2. Therefore, since the redistributed routes were configured as E1 routes, the cost of those routes from the perspective of router R1 is the cost originally assigned by router R1, which was 20, plus the cost for R1 to get to R2, which is 1, for a total cost of 21.
1 255 Distance Metric For This Route 46
Summary
1 255 Distance Metric For This Route Traveled
In this blog post, we considered the need for route redistribution and took a look at a basic configuration. We discussed the impact of a routing protocol’s seed metric (which might be infinity) when performing route redistribution, and we saw three ways to administratively assign a metric to redistributed routes. Finally, we contrasted OSPF’s External Type 1 (E1) and External Type 2 (E2) routes. In an upcoming blog post, we’ll build on this topology and consider how we can selectively filter the routes being redistributed. Then, in yet another blog post, we’ll consider design issues surrounding topologies with multiple points of redistribution between two autonomous systems.
1 255 Distance Metric For This Route 66
I hope you enjoyed this first glimpse into the world of route redistribution. If you did, please help spread the word by sharing this post with others. Here's the link you can share:
Until next time,
Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945