The above graphic is a visual demonstration of how Redistributing routes works, as we are not taking one route from a routing protocol and placing it into another protocol, we are taking routes from the IP table and placing it into “routing protocol data structures” if you remember that phrase.
What Route Redistribution is at its very core
It is taking routes from the IP Route Table, and putting them into other Routing Domains.
The visual example above demonstrates this, as we aren’t looking at the EIGRP Topology Table or the OSPF LSDB for routes to Redistribute to the IP Route Table, it is exactly the opposite way around. We Redistribute routes from the IP Route Table whether they are Dynamically learned or Connected networks, and then placing them into a Routing Domain / Data Structure.
For example if I go into ospf configuration and type “redistribute eigrp …” its not going to Redistribute every route from the EIGRP Topology table into the OSPF Link-State Database, but it will take the EIGRP Routes from the IP Route Table to Redistribute into the OSPF LSDB.
Lesson #1 – If a Redistributed Route is not showing up, it is unlikely a problem with the Redistribution itself, but with the Route not making it into the IP Route table for multiple reasons (better route was injected, network statement misconfig, etc).
A route must be in the IP Route Table to be Redistributed, if it is not there, it will not be Redistributed anywhere until the underlying issue is fixed!
How to properly configure Metric several ways with Redistribution
The “Seed Metric” is the metric that is assigned to a route when its being Redistributed into another routing protocol / routing domain, that term is often used and good to know.
Every routing protocol uses a different “Metric” by which it defines its best routes to be injected to the IP Route Table, so when injecting Routes between Protocols they need to be assigned a Metric that Protocol both understands and allows them to be injected into their own IP Route Table as intended.
For example for RIPv2, if you put an EIGRP Route into RIP with a max Metric of 15 (hops) and the EIGRP Metric (Bandwidth and Delay) is 4123899, there is going to be issues.
That being said, there are a few different ways to define metric for redistribution:
- Use the “default-metric” – Seems to be only for redistribution into EIGRP
- Use the “metric” command to manually set a metric for Redistributed routes
- Apply a “Route-Map” that manipulates the Metrics among other configs
Also a few default metrics / seed metrics when redistributed into certain protocols:
- If NO metric is hard coded, the original protocols metric will be used!
- RIP and EIGRP default metrics that are considered unreachable in other domains
- OSPF seed metric will be 20, unless it is a BGP Route, which will have a metric of 1
- BGP seed metric will be the same metric of the IGP (Interior Gateway Protocol)
For EIGRP a seed metric does not have to be specified if Redistributing into another EIGRP AS / domain as the original Metric will be preserved, a seed metric isn’t required when Redistributing Static or Connected routes, however other protocols will need a reachable metric defined for that specific protocol.
However two things must be true for any route redistribution to happen:
- The route must be in the “Boundary Router” doing redistributions IP Route Table to be redistributed into other Routing domains
- The destination IP protocol needs a reachable seed metric assigned to the routes being Redistributed into it for them to be used
A couple of Misc subjects I want to touch on quick before moving on
In the command “redistribute eigrp # …” or “redistribute ospf # …” the # value refers to the Process # or AS #, so do not use the OSPF Area # when performing Redistribution unless somehow defined using a Route-Map.
The “redistribute eigrp 100 subnets” command, more specifically the subnets part of that, tells the Boundary Router to Redistribute individual subnets rather than a main subnet that encompasses several individual ones.
An example of this was seen in my Part 1 lab setup, where most routers see their links connecting them to the other two routers under 10.0.0.0/8 as two more specific subnets, if the keyword ‘subnets’ was not used in Redistribution it would not redistribute those ‘subnets’ but rather just the 10.0.0.0/8 major network.
Point being the ‘subnets’ command will probably always want to be added to a redistribute statement, unless there is a reason to intentionally not want to advertise subnets, such as Summary Route Advertisement via Redistribution.
Troubleshooting different the 4 parts of the Redistribution process!
There are 4 main parts that may need to be troubleshot with a Redistribution issue, which I will define here, and the recommend approach to troubleshooting that particular step / target for Redistribution.
Source Routing Protocol – This should be the first step in troubleshooting is verifying that the source routing domain knows of the route via “sh ip eigrp top” / “sh ip ospf database” / “show run | i ip route” / Etc, to verify the source domain contains the route
Route Selection – Redistributed routes must be in the IP Route Table, so after verifying the domain knows of the route, it will need to be verified or configured to be the best possible route to be injected into the IP Route table
Redistribution Configuration – This has everything to do with the “redistribute …” command, you will want to make sure appropriate metrics are configured, “subnets” keyword if necessary, correct AS / Process # specified, any route filtering configured, basically any variable that could be misconfigured / filtering the route in the actual redistribute command line itself “sh run | i redistribute” to view redistribute lines themselves or can also use “sh run | sec router (protocol)” to view entire router process configs which is maybe the better way to go to inspect all config elements
Destination Routing Protocol – If the Route has been successfully Redistributed, verified by reviewing the “Routing Protocol Data Structure” via “show ip eigrp top” / “sh ip ospf data” / Etc to verify the route made it into the route protocol but it is not showing in the IP Route Table troubleshooting how the Destination Protocol treats Redistributed routes will be important.
One example of this would be redistributing into EIGRP, the default AD assigned to External Routes is 170, whereas other Routing Protocols do not treat External Routes different in terms of Administrative Distance.
Troubleshooting Redistribution into RIPv2 / RIPng Protocols
Both protocols have the same limitations and issues, IPv6 versions of Routing Protocols often behaves almost identical to IPv4, except for the small tweaks of IPv6 Multicast utilization and addressing.
With RIPv2 and RIPng the most common issue you will run into is Metric, as RIP uses Hop Count with a Max Metric of 15, this Metric is still a valid route.
A Hop Count / Metric of 16 in RIPv2 or RIPng means it is unreachable!
The “Seed Metric” configured during Redistribution defines how many Hops the destination is from the ABR, so you will want to account for the additional Hops away to the Host PC / Server, to make sure by the time the route is advertised to its gateway device it is not exceeding the max hop count of 15.
Bottom line, watch that seed metric whether in the Redistribute line or in a route-map (as the wrong route-map might even be applied) when troubleshooting!
One major difference between RIPv2 and RIPng to be aware of!
RIPv2 being a classful routing protocol will automatically include local interfaces that are encompassed by its network statements, this is why I actually originally had RIPv2 on the link between R2 and R3 in this Redistribution Topology where iBGP now is:
Though “no auto” allows it to advertise discontiguous networks, it advertised the networks 10.1.13.0/24 (R1-R3) to R2 and 10.1.12.0/24 (R1-R2) to R3, because they fall within the classful network of 10.0.0.0/8 even though the only network statement configured was “network 10.1.23.0” as no mask info can be entered.
RIPng does not have this auto-advertise behavior by default, instead there is a redistribute command special to RIPng that is called “include-connected” which will allow it to perform this classful network advertisement behavior.
OSPF also has its own special command for Redistribution “match”
This “match” sub-command allows to match on a specific type of OSPF route to be redistributed, the different network types being “match (internal/external/nssa)” which Internal = O / IA O, External = O E1, O E2, NSSA = O N1, O N2 routes in the IP Route Table and multiple network types can be defined with the “match” statement.
This “match” command is not specific to OSPF -> RIP, which will be discussed shortly.
Some useful commands for troubleshooting RIP Redistribution:
- “sh ip proto” – Will show which protocols are being Redistributed into RIP
- “sh ip rip database” – Will show both known RIP and Redistributed routes
- “sh ipv6 proto” – Used for RIPng protocol information
- “sh ip route” – To compare IP Route Table to RIP database
- “sh route-map” – To review Route-Maps used in Redistribution
Troubleshooting Redistribution into EIGRP / EIGRP for IPv6
EIGRP is another protocol that is very Metric sensitive when performing Redistribution, because though it uses Bandwidth and Delay as its main Metric, the Seed Metric that will need to be defined must contain all five K Weight values.
This is also because the default seed metric will give the Redistributed routes an “unreachable” metric, so whether in a Route-Map or right on the “redistribute …” line it will need to be defined, for example this is how it theoretically is being configured:
“redistribute ospf 1 metric k1 k2 k3 k4 k5”
K1 – Bandwidth
K2 – Delay
K3 – Reliability
K4 – Load
K5 – MTU
Being that Bandwidth and Delay are the default K Weights turned on, though this can be verified with “sh ip proto” command, and though you will want to be as accurate as possible if there are multiple Redistribution points you may want to make one of those points Delay value higher than the preferred Boundary Routers delay.
Bandwidth probably shouldn’t be tampered with, this # value is mbps, so Gig links will be 1000 / FastEthernet 100 / Etc.
For Redistribution on my home physical lab, using FastEthernet interfaces, I would issue:
router eigrp 100
redistribute ospf 1 metric 100 10 5 255 1500
However if I wanted to configure a second less desired Redistribution point into this EIGRP AS, I would use the following command:
router eigrp 100
redistribute ospf 1 metric 100 1000 5 255 1500
This will leave the Bandwidth value true to the interface, while adding a higher Delay value, making it less preferable and likely not used unless the first point of Redistribution goes down or becomes unavailable for any reason.
EIGRP also has the “match” modifier for OSPF redistribution to define the three different OSPF network types, which can also include a mix of any of the network types.
EIGRP for IPv6 also includes the “include-connected” modifier like RIPng, as it may advertise classful networks as well if configured to do so, say for example if “network 10.0.0.0” with no wildcard mask were entered it will assume that is 10.0.0.0/8 and any interfaces that fall in that range will become EIGRP enabled for that AS.
To watch for this I’d probably review network statements in the actual running config if possible with “sh run | sec router eigrp” which will work for IPv4 or IPv6 router eigrp configuration to show its running config / manual router process configurations, though of course “sh (ip/ipv6) proto” will show you what networks the EIGRP Processes are routing for, but again the running config will show the exact configuration to find possible misconfigurations that may need to be corrected.
Both EIGRP IPv4 and IPv6 change AD of Redistributing Routes to 170!
Internal EIGRP that with the code D in the IP Route Table will have an AD of 90, but Redistributed routes that show as codes D EX in the IP Route Table will have an inherent AD of 170 in the EIGRP Domains IP Route Table.
To change these distances for ALL routes (Internal and External) in an EIGRP Process:
router eigrp 100
distance eigrp 50 100
This will make all Internal routes AD 50 and External (Redistributed routes) AD 100 for this EIGRP AS #, and again effects all routes.
There is a more specific method for changing a single routes AD using an ACL, this is done by first verifying the advertising router with “sh ip eigrp top” and starting with the ACL configuration then tying to a router eigrp # configuration (note this only works for Internal Routes!).
Say the network needed AD adjustment is 192.168.10.0 0.0.0.255 and the advertising router found in the Topology table is 10.1.20.1, the following would be configured:
access-list 55 permit 192.168.10.0 0.0.0.255
router eigrp 100
distance 85 10.1.20.1 0.0.0.0 55
First an ACL is defined for the network, a non-extended will do for this example, ACL 55.
Then in the router EIGRP process, the “distance …” command is being used again, except this time the Internal AD is defined first then from what source it is being applied for (10.1.20.1/32), and finally the ACL 55 is configured at the end to define which networks from that source the AD will be turned to AD 85 for.
^^^Again this is only for Internal Routes, anything External / Redistribution must be done via “distrance eigrp # #” which is all or none, though both distance types can be configured if we are getting extremely granular with EIGRP AD from different sources!
The list of good to know commands for exam day for troubleshooting EIGRP:
- “sh (ip/ipv6) eigrp top” – To view all EIGRP known routes / Topology table
- “sh (ip/ipv6) route x.x.x.x” – This works with either a network # or a Host IP that is a known network in the IP Route Table, gives details of where / how it was learned
- “sh (ip/ipv6) proto” – Full routing protocol information including Redistribution
- “sh (ip/ipv6) eigrp nei” – To see current neighbor adjacency states
- “sh (ip/ipv6) eigrp int (det)” – Important to confirm if EIGRP is running on an interface, but a neighbor adjacency is not forming off that interface!
I say it over and over again, and will say it once more again here, the IPv6 versions of Routing Protocols behave the same as their IPv4 counterparts with just the smallest differences that are required for IPv6 to work how it does.
I will cut this topic in half here, and save OSPF / BGP / Route-Maps for another post
For the sake of keeping these articles as small and concise as possible, I will cut it off here with the Redistribution review / Distance Vector protocol Redistribution, and will pick up with OSPF and BGP in the next article (not sure if I will save Route-Maps for the lab).
Happy almost Monday! 🙂
The DEVNET GRIND! 